On Sat, Jul 22, 2006 at 08:03:54AM -0400, M. Levinson wrote: > Included below is a minor reworking of the Python scripting backend to > address four issues: > > 1. Errors (including informative tracebacks) are now presented by calling > the report_scripting_error() function in src/scripting/scripting.c. > > Also, a trivial change to report_scripting_error(): When it needs to > resort to calling usrerror() it should sleep for a moment, just as > alert_lua_error() does, so the user will have enough time to notice the > error before the screen is cleared. > > 2. Several functions in src/scripting/python/hooks.c were leaking references > because Py_None's reference count needs to be decremented when we're > finished with it (just like most other Python objects). > > 3. The pDict pointer could potentially be compared to NULL even if it was > uninitialized. And just to err on the side of paranoia, pDict's reference > count should be incremented to make sure the Python interpreter won't > garbage-collect the object while it's still in use.
AFAIK global variables are by default initialized by zeroes, pDict was initialized to NULL in that case. > > 4. ./configure --with-python didn't work because the Python tests were > trying an incorrect library name and didn't produce all the necessary > compiler and linker flags. (Also, they were setting CFLAGS where CPPFLAGS > is probably more appropriate.) > > Note that newer versions of python will come with a convenient > python-config script; relying on that would have made the tests > simpler, but the more verbose tests that I've provided have one > advantage: They're likely to work with older Python versions as well. > > While I was in the neighborhood, I also rearranged the Python tests in > configure.in to look somewhat like the SEE and Guile tests for ease of > future maintenance. It's still pretty ugly, but at least now it's a bit > more consistent. :-) > > With these changes, ./configure --with-python now works for me, as do the > Python hooks I've tried (but testing the configure script on more diverse > platforms would be desirable). > > I hope this is helpful. Thanks so much for all your terrific work on Elinks! Thanks! Applied all but the configure.in part. Could you send configure.in diff against current GIT version? If you know Python could you say why $ valgrind elinks shows a lot of errors in the Python part of code? -- Witek _______________________________________________ elinks-dev mailing list [email protected] http://linuxfromscratch.org/mailman/listinfo/elinks-dev
