On Apr 21, 2010, at 12:09 AM, Eliot Miranda wrote: > Hi All, > > 2010/4/20 John M McIntosh <[email protected]> > 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.
Thanks this is good to get a vision in that area. We go in that direction now this is more a problem of knwoledge than will so we will work on making the VM knowledge more spread in the community. > > I hope this approach would make it easier for people to produce plugins, > since more of the 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. Sounds good. I do not get anything but trying to learn. :) > (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) well when will we get more Cog improvements in the vm? > > 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 > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > =========================================================================== > John M. McIntosh <[email protected]> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
