kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

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.

Best Regards,

Brian.