Hi All, 2010/4/20 John M McIntosh <[hidden email]> Well I asked for it... 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 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.
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 21.04.2010, at 00:09, Eliot Miranda wrote: > Hi All, > > 2010/4/20 John M McIntosh <[hidden email]> >> Well I asked for it... >> >> (a) you can get graphic cut/copy/paste of complex data on the macintosh and windows. Linux too. Etoys on the OLPC does images and rich text copy/pasting just fine. Not sure what that has to do with FFI though? ExtendedClipboard is a plugin. Seems I missed some earlier discussion ... - Bert - |
On 4/20/2010 3:37 PM, Bert Freudenberg wrote: > > On 21.04.2010, at 00:09, Eliot Miranda wrote: >> Hi All, >> >> 2010/4/20 John M McIntosh<[hidden email]> >>> Well I asked for it... >>> >>> (a) you can get graphic cut/copy/paste of complex data on the macintosh and windows. > > Linux too. Etoys on the OLPC does images and rich text copy/pasting just fine. Not sure what that has to do with FFI though? ExtendedClipboard is a plugin. Seems I missed some earlier discussion ... Where is ExtendedClipboardPlugin? I've never seen it. Cheers, - Andreas |
mmm, yes from Sophie but see platforms/Mac OS/plugins/ClipboardExtended On 2010-04-20, at 9:24 PM, Andreas Raab wrote: > On 4/20/2010 3:37 PM, Bert Freudenberg wrote: >> >> On 21.04.2010, at 00:09, Eliot Miranda wrote: >>> Hi All, >>> >>> 2010/4/20 John M McIntosh<[hidden email]> >>>> Well I asked for it... >>>> >>>> (a) you can get graphic cut/copy/paste of complex data on the macintosh and windows. >> >> Linux too. Etoys on the OLPC does images and rich text copy/pasting just fine. Not sure what that has to do with FFI though? ExtendedClipboard is a plugin. Seems I missed some earlier discussion ... > > Where is ExtendedClipboardPlugin? I've never seen it. > > Cheers, > - Andreas =========================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== smime.p7s (3K) Download Attachment |
In reply to this post by Eliot Miranda-2
On Tue, Apr 20, 2010 at 03:09:01PM -0700, Eliot Miranda wrote: > > 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. For the record, the SmartSyntaxPlugin (which was originally named TestInterpreterPlugin in earlier images) is apparently the work of Stephan Rudlof (sr) and Andrew C. Greenberg (acg), and dates back to about 1999 or so. Dave |
Free forum by Nabble | Edit this page |