On Apr 21, 2010, at 9:06 AM, Stéphane Ducasse wrote:
>
> On Apr 21, 2010, at 12:09 AM, Eliot Miranda wrote:
>
>> Hi All,
>>
>> 2010/4/20 John M McIntosh <john...@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.
>
> 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. :)
anything/everything hopefully :)
>
>> (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
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> --
>> ===========================================================================
>> John M. McIntosh <john...@smalltalkconsulting.com> Twitter: squeaker68882
>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
>> ===========================================================================
>>
>>
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
