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@lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/beginners _______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
