Mark said:
What problems specifically? The only practical problems you should see
will arise if you try and pass a "FILE *", or allocate memory you then
ask python to free (or vice-versa) - both should be avoidable though...
It concerns a Ruby plugin for Sketchup that embeds a Python
interpreter and acts as a bridge between Ruby and Python.
I'm using Sketchup 7 which uses msvcrt80.dll, and includes
a Ruby dll which is presumably also linked against that
crt.
I've made some progress on the issue. One problem turned out to
be a result of allocating something with ruby_xmalloc() and
freeing it with free(), which was easy to fix.
Another one seemed to be something to do with trying to use
a global var that points to the current Ruby stack frame. I
don't really know what was happening, but I found another way
of doing things that sidestepped the issue.
I've now got it working, at first sight anyhow, using Python 2.3.
But it doesn't work properly with Python 2.5. The problem
appears to be related to compiling .py files to .pyc. The
first time I run it and try to import a module, a .pyc is
generated, but then a crash occurs when trying to call one
of the functions imported from it. If I run it a second time,
with the previously generated .pyc in place, it runs successfully.
Which makes me think it may be some kind of FILE * problem,
but I'm not sure what, since all the stdio operations on
the files concerned should be getting done by Python.
To add insult to injury, it's proving to be very difficult
to debug, because Sketchup seems to crash all on its own
when run under gdb on Windows, even when I don't load any
of my code. So I can't get a traceback of where the crash
is occurring.
There's one possibility I just thought of -- Python may
be trying to write something to stdout or stderr, in which
case it will probably be using the wrong crt to do it.
Something to look into after I've got some sleep...
