[C++-sig] Re: Pyste-generated extentsion Aborts Python

[David Abrahams]

Jim Wilson <wilson at afn.org> writes:

> David,
>
>  > 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
> contracts.

If you don't guarantee very much, it's easy to meet expectations
<wink>.

> 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
> about.
>
> 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; 

Me neither.

> I flunked out of Purdue.  I had to Google "nullary function" to
> discover it was a function with no parameters.  

So sorry.

> 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
> maintain.

That would be delicious.  Do let us know how things turn out.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com