[Newbies] FFI versus BASH

[David T. Lewis]

Bert, that's the clearest and best explanation I've ever read. You should
put it on the swiki for future reference.

Dave

On Tue, Jan 04, 2011 at 12:55:43PM +0100, Bert Freudenberg wrote:
> You retracted the question, but since I already started writing an answer it might still be valuable to some who don't know about FFI ...
> 
> On 01.01.2011, at 21:17, Chris Cunnington wrote:
> 
> > I have a question that I imagine is going to reveal a big gap in my knowledge. Oh well.
> > 
> > I have a framework such as QuickTime that I want to send a message to. In Sophie I can execute some code in a Workspace and it will go to the FFI, send a message to the QT framework, and then return. But I can't do that in BASH.
> > 
> > To send a message to the library, I'd need to write a text file, compile, and then execute. Then the response comes back into the Terminal. Why can't I just enter Carbon functions in the shell and do what Workspace/FFI does?
> > 
> > Or, does FFI compile on the fly and then de-compile to put an answer in Workspace?
> > 
> > The real question here, I think, is what is a message in Linux? Is it a stream of bits with meta data?
> > 
> > A message is being sent to the library, but I don't grok what that message is. Any help would be greatly appreciated,
> 
> There is no message sent to the library. "Messages" are concepts used in high-level languages.
> 
> FFI mitigates between the high level of Smalltalk and the low level of system libraries. Those libraries just contain machine code which has no notion of "messages".
> 
> Instead of sending a message to an object (which the object can choose to act upon or ignore) it "calls a function" in the library. This instructs the CPU to execute code at a certain position in memory (the library code) before "returning" to the code it was executing before (the VM code). The first job of FFI is to locate the library given its name, and load it into memory.
> 
> The library code expects arguments in certain memory cells, and it's the FFI's job to write the data from Squeak objects into those locations. Similarly, once the function is done, the FFI fetches the result data and converts it to Squeak objects.
> 
> This has to be done just right because there is no sane error handling in these low levels of machine code. The usual results of mistakes is the whole application crashing, rather than getting a friendly pink exception notifier.
> 
> There is a safer way than FFI of calling into library functions from Squeak, namely writing plugins. A plugin (also called "VM module") usually checks all the parameters and if they don't fit, or something else goes wrong, it simply "fails the primitive", but cleanly returns to the Squeak world. Back there you typically get a "primitive failure" error window. That's way better than a crash.
> 
> A plugin is not only safer, but also more efficient than FFI. And it can hide platform differences, so that the Squeak code does not have to worry about on which platform it is running, as long as the plugin provides the same interface to the platform facilities.
> 
> FFI is still attractive to many because writing a plugin means having to set up additional tools (compilers etc) whereas FFI has no additional dependencies. This makes it look deceptively simple, all you do is writing Squeak code after all. But you need to think in low-level C anyway, so it's not actually simpler. And what you get is a quick-and-dirty solution, instead of the Right Thing.
> 
> - Bert -
> 
> _______________________________________________
> Beginners mailing list
> Beginners at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/beginners