kicad-developers team mailing list archive
Mailing list archive
Re: Python-a-mingw-us Windows Debug Scripting Builds
On Aug 31, 2013 5:35 PM, "Brian Sidebotham" <brian.sidebotham@xxxxxxxxx>
> On 31 August 2013 21:39, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
>> On 08/31/2013 03:00 PM, Brian Sidebotham wrote:
>> >>> Q:
>> > >>
>> > >> (i) Does anyone see any output from the PyErr_Print() calls?
>> > Try using a tool like Debug Viewer available from Microsoft. If
>> > PyErr_Print() is anything like wxLogXXX(), on Windows the output
>> > to the OutputDebugString() function which does not end up on
>> > You can find the debug viewer here:
>> > http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx
>> > You must run the debug viewer as Administrator in order to see the
>> > debugging strings.
>> > GDB reports OutputDebugString() too on Windows. For example, I see
output from the
>> > wxLogXXX() function that reports setting the KISYSMOD environment
variable. I suspect
>> > PyErr_Print() just pipes to stderr or stdout.
>> > Thanks,
>> > Brian.
>> Look at the source code. Start with line 1057 of pythonrun.c. That
takes you to
>> PyErr_PrintEx(), line 1151.
>> hook = PySys_GetObject("excepthook")
>> It seems you have to install a "excepthook" someplace before calling
>> least somebody or something does.
> Hi Dick,
> I believe excepthook is simply set by the originating Exception. If it's
not set there there's nothing to print; In fact the Python API manual says
if you call PyErr_Print() without there having been an error it would
result in a fatal error!
> On Windows, the failure for the scripting console is:
> Traceback (most recent call last):
> File "<string>", line 2, in <module>
8, in <module>
> import crust
15, in <module>
> import editwindow
line 8, in <module>
> from wx import stc
> File "D:\launchpad-dev\kicad-winbuilder\kicad\bin\pylib\wx\stc.py",
line 10, in <module>
> import _stc
> ImportError: DLL load failed on
specified module could not be found.
The dll loader for windows returns a string. I would printf that message
in python.dll. it may hold more info than what you have now.
If that *.pyd file needs to in turn also dynamically link to something
below it in the stack, and those dlls are not findable, then it can look
like the failure is with the pyd, when in fact its with an unfindable
dependency. Findable is somewhat dynamic. It depents on environment
variable (s). PATH right? Maybe the debugger is causing the change in
findability, because it temporarily sets an environment variable
> But I can assure you that this file is good and does work. I can step
through the code surrounding the script console generation and then it
works okay, only occasionally will it fail with the same message.
> I can run up python normally and run pretty much the same code as an
example and see and use the PyCrust interactive scripting console. So I've
no idea why it's complaining.
> Best Regards,