[Vm-dev] Re: [Pharo-project] FFI in 1.1

[Eliot Miranda]

Hi All,

2010/4/20 John M McIntosh <johnmci at smalltalkconsulting.com>

> Well I asked for it...
>
> (a) you can get graphic cut/copy/paste of complex data on the macintosh and
> windows.
>
> (b) I'd rather have people learn FFI & Alien so they can build their own
> api to Rome, Pango, & Curl instead of waiting on about 4 people in the world
> to get around to building and distributing *official* plugins .
>

I agree with this, but I also understand the security and modularity
concerns of those who want to deploy without FFI and with plugins only.  I
think it might be worth-while, and would certainly be feasible and fun, to
write an automatic plugin generator, e.g. above David's SmartSyntaxPlugin,
that would take a set of FFI methods and shrink-wrap them into a plugin.  So
the natural development cycle for plugins could become prototype and extend
using the FFI and deploy via the generator and a plugin compilation step.
 That would be analogous to the approach taken to produce the VM itself.

I hope this approach would make it easier for people to produce plugins,
since more of the gubbins <http://www.thefreedictionary.com/gubbins> would
be hidden.  That might be naive given complications with mapping object and
memory references across the boundary, but it might also be an easier way to
integrate things like Andreas' proposed handle
framework<http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/004106.html>
.


> (c) When your curl, rome, etc FFI call freaks and toasts your image why you
> can do debugging, versus relying on a handful of people in the world to
> grind thru some compiler, gnu debug session to figure out why that register
> move results in a fatal Virtual memory page fault.
>

Certainly we got some good mileage out of catching external errors in FFI
calls and returning these as primitive error codes. Basically it helps you
find which FFI calls cause crashes, because the system will typically stay
up long enough for you to open the debugger and identify which FFI call
failed and what its arguments were.  Why the call failed isn't so easy.  The
errr codes are an address and some OS-specific exception identifier. One
then either has to think hard (infer from the args why the call might fail)
or decamp to a low-level debugger, rerun the call and use any additional
info it provides to debug the call.

This is easy to add to the current VM which already has fatal signal
handlers and primitive error codes.  The FFI must set a flag "in FFI call"
(clearing on callback, resetting on return from callback) which is tested in
the fatal signal handlers and cause the exception info to be squirrelled
away and the FFI call to fail.  If the VM has enough state to take a
callback it typically has enough state to cause the current FFI callout to
fail and from the fatal signal handler longjmp to somewhere that can
continue execution through the primitive failure.  (and if it doesn't now,
it can be made to, and not on every FFI call either, e.g. the interpreter
can call setjmp prior to entering the interpreter loop, Cog does this to be
able to switch between native code and interpreted code)

2¢

Eliot

>
>
> On 2010-04-19, at 11:41 PM, Torsten Bergmann wrote:
>
> >> I wouldn't include neither FFI or Alien FFI in neither PharoCore or
> PharoDev
> >> image.
> >
> > +1
> >
> >> That's only my opinion.
> >
> > Maybe Stef should tell us more about why he thinks it should be included.
> >
> > Bye
> > T.
> >
> > --
> > GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
> >
> > _______________________________________________
> > Pharo-project mailing list
> > Pharo-project at lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> ===========================================================================
> John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:
>  squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100420/be80a895/attachment.htm