[Vm-dev] RE: To FFI or not to FFI

[Casimiro de Almeida Barreto]

 Em 03-10-2010 12:50, Schwab,Wilhelm K escreveu:
>  
> Bert,
>
> In saying that "port the vm and everything just works" you appear to be ignoring that the plugins have to be ported too.  Whether one tweaks and debugs(!!) Smalltalk or C, there will be things to port and fix.  I for one would much rather work out the details of a stubborn platform dependency in readily changed and debugged Smalltalk than C hidden away in the vm.
>
> Where I get worried is with an apparent general desire to do everything in Smalltalk when a shared library might be/is the answer.
Besides the need to port plugins, there's no literature easily available
for developing plugins. So, in many instances when people is not able to
write plugins or don't have time to do so, FFI comes just in hand.

Msier Cassou wrote some nice books on squeak/pharo... could enhance
adding a chapter on how to develop plugins (perhaps with help of VM people).

CdAB
> Bill
>
>
>
> Bert Freudenberg bert at freudenbergs.de
> Fri Oct 1 14:31:52 UTC 2010
> We are not talking about optional add-ons. For that, yes, FFI is the quick-and-dirty solution, go ahead and have fun wrapping every library on the planet.
>
> What I am objecting to is the zealous quest to move core functionality out of proper plugins to the image, be it using FFI or Alien or any other generic callout mechanism.
>
> Being able to take an image and run it anywhere without having to worry about the platform is a Good Thing. Once John ported the Squeak VM to iOS, Etoys *just worked*. That's the power our VM abstraction gives us.
>
> Also, the whole Squeak sandbox security model depends on the VM being able to prevent code in the image to do damage. There is no way to do that if you let the image use FFI. Do you want my Etoys project to wipe out your hard disk? I didn't think so.
>
> There is another benefit to plugins that encapsulate platform capabilities: Once the interface has been written, you only need to know C, not so much Smalltalk, to port it to another platform. If the primitive interface has been well-designed this is much easier than doing it in Smalltalk. Plus, it is much simpler to get help from platform experts if they can see the C code.
>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20101003/9c5bf3ac/signature.pgp