Mark Hammond wrote:
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... -- Greg -- http://mail.python.org/mailman/listinfo/python-list
