kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On Sep 2, 2013 4:35 AM, "Brian Sidebotham" <brian.sidebotham@xxxxxxxxx>
wrote:
>
> On 1 September 2013 02:37, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
>>
>>
>> On Aug 31, 2013 5:35 PM, "Brian Sidebotham" <brian.sidebotham@xxxxxxxxx>
wrote:
>> >
>> > 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 is sent
>> >> >     to the OutputDebugString() function which does not end up on
stdout.
>> >> >     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.
>> >>
>> >>
>> >>
>> >> 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
PyErr_Print(), at
>> >> least somebody or something does.
>> >>
>> >> Dick
>> >>
>> >
>> > 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>
>> >   File
"D:\launchpad-dev\kicad-winbuilder\kicad\bin\pylib\wx\py\__init__.py", line
8, in <module>
>> >     import crust
>> >   File
"D:\launchpad-dev\kicad-winbuilder\kicad\bin\pylib\wx\py\crust.py", line
15, in <module>
>> >     import editwindow
>> >   File
"D:\launchpad-dev\kicad-winbuilder\kicad\bin\pylib\wx\py\editwindow.py",
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
file:'D:\launchpad-dev\kicad-winbuilder\kicad\bin\pylib\wx\_stc_d.pyd'. The
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
differently.
>
>
> Thanks for the information Dick, I'll start looking into this as soon as
I can. Hopefully some time will pop up later in the week.
>
> I've used depends to check what dependencies _stc_d.pyd has as they are
all fulfilled in the environment the process is being run and they are all
satisfied. But I don't see what else can really change so I don't think it
can be ruled out. You're right, it's the PATH environment variable that
controls the search path, although the current working directory always
takes precedence, it is essentially prepended to the PATH search list.
>

The os system call to do a dll loading can take either a fully qualified
path to the dll needing loading, or it can take only a filename.  In the
latter case, the path augmentation comes from the environment variable
PATH, and maybe registry info as an alternative.

Python from what I remember uses fullpath argument to os dll loader.  But
the boundary below that does not, path augmentation is needed.  So finfing
dlls with a pyd extension uses one form of path augmentation, loading a
fill by filename only requires a different form, done by the os call itself.

The os dll loader call returns a string on error.  You need to add a printf
in your python build to print this string IMO.


> Best Regards,
>
> Brian.