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

[David Abrahams]

Jim Wilson <wilson at afn.org> writes:

> David,
>
> You wrote:
>> FWIW, FLTK has some design problems which make it nearly impossible
>> to
>> wrap safely with any wrapping system.  So if you're seeing crashes,
>> I'm not surprised.  You can read about it in this thread:
>> http://mail.python.org/pipermail/c++-sig/2002-December/003117.html
>
> I *think* I vaguely grasp the concepts in your reference.  Certainly, I'm
> aware of the volitile nature of Python objects (including functions), and
> I sense that  calling an evaporated function rarely produces
> anything useful.

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.

> I can imagine that something deep in the bowels of some Boost
> template library has become upset with "void (*func)(...)", and has
> justifiably decided to issue a long, incomprehensible (to me)
> complaint about it.

Not if, as you described, it's a runtime Abort.  That was a crash,
plain and simple, and as I've tried to suggest I think it's a
FLTK-ish sort of thing having to do with the inability to manage
object lifetimes in a disciplined way.

> I'm not sure why Spitzak chose his simple-minded callback mechanism.
> I can attest that it makes it easy for simple minds (like mine) to
> understand ;) Certainly, the alternative virtual method/override
> that you suggest is also available

It's provided by FLTK?  That's news to me!

>  (although the pertinent method is declared "protected"; I'm not
> sure what impact this might have on a Boost-based Python wrapper).

Only a little; when you wrap the class you just need a using
declaration in your virtual-function-dispatching subclass.

> However, in my ignorance of what I now see may be *future* problems,
> I chose to allow FLTK to sling raw pointers to its heart's content
> and exposed only a more disciplined subset of its interface.  Pyste
> generated a .cpp file without a whimper and either: 1. relied on g++
> to issue incomprehensible diagnostics- once-removed about
> Pyste-generated code not intended for human consumption, or
> 2. relied on Python to issue the even-less-useful diagnostic
> "Abort".

I don't believe that either is the case.  There may in fact be a Pyste
problem, though.


> I think this is a Pyste problem, and I believe Nicodemus would want
> to know about it.
>
> 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.

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