[C++-sig] Re: Pyste-generated extentsion Aborts Python
dave at boost-consulting.com
Sat Jul 5 04:12:35 CEST 2003
Jim Wilson <wilson at afn.org> writes:
> > The problems in my reference have much more to do with the volatile
> > nature of whatever's at the end of your C++ void* than with the
> > volatile nature of Python objects. At least the latter have
> > destructors which can be hooked.
> Then, I misunderstood completely. I can certainly see a problem if
> some FLTK Widget wasn't informed of the demise of its "callback" or
> its associated "data". I can further understand there would be hell
> to pay if FLTK arbitrarily delete'd something without communicating
> the fact to the Python wrapper.
> As I admitted elsewhere, I am not a Pythonista; I am only a sympathizer.
> My experience with FLTK has only been with C++, and only pidjin C++ at
> that, but I have been quite pleased with the way FLTK upholds its
If you don't guarantee very much, it's easy to meet expectations
> Now, it may be FLTK programs/data data tend to be small enough to
> elude thrashing pointers, while Python data (with the interpreter)
> tend to obesity thus becoming easy targets for those same pointers.
Maybe. I won't speculate.
> > [Overridable virtual methods] provided by FLTK? That's news to me!
> You and I are likely on different planes of understanding . Too many
> ()'s in a row make my eyes water, so this may not be what you were talking
> FLTK's "Fl_Widget" is the base class for almost everything in FLTK;
> it provides a unary virtual method "void handle(int)" to receive events
> intended for the Widget.
Well, OK, but I meant that instead of passing around unbundled
function pointers + void*s for additional data it would be better to
pass a pointer to an object with a virtual destructor and invocation
function, so that destruction could do something intelligent.
> ("Nullary" sounds LISPish to me. I didn't graduate MIT;
> I flunked out of Purdue. I had to Google "nullary function" to
> discover it was a function with no parameters.
> I would be quite content with such a function. I could then use
> (subclassed) Widget methods to extract any information the parameter
> might have conveyed.)
> >> For what it's worth, I can cause pyFLTK's SWIG-generated wrapper issue a
> >> somewhat related diagnostic: "Segmentation fault" .
> > Probably the same FLTK-ish sort of thing I referred to just now.
> Could be, but I didn't give FLTK too much chance to lob any pointers with
> the pin pulled out. FYE, here is the interactive Python:
> >>> from fltk import Fl,Fl_Window,Fl_Button # SWIGed, not Boosted
> >>> w = Fl_Window(300,200) # Create a little window
> >>> Fl_Button(100,75,100,50,"Click Here") # Pay no attention to the man ...
> <C Fl_Button instance at _40981b08_p_Fl_Button>
> >>> w.show # Oops! I meant w.show()
> <bound method Fl_Window.show of <C Fl_Window instance at _60b62008_p_Fl_Window>>
> >>> w.show()
> Segmentation fault
Hard to tell much from that.
> PyFLTK is just as new as Pyste. To my eye, SWIG specs are quite
> complicated. I suspect something is amiss a little higher than
> FLTK. I undertook my little experiment in hopes that I could
> convince the pyFLTK guys of my assertion that a Boost.python
> extension would be smaller than a SWIG based one.
That would be interesting, if so. I've already had reports that
they're faster (to my great surprise).
> If Pyste delivers on its promise, it *certainly* would be easier to
That would be delicious. Do let us know how things turn out.
More information about the Cplusplus-sig