I would say that "easy way" depends entirely on what you are trying to 
accomplish. For example, as part of my learning how to use NativeBoost, 
I created a partial interface to the various GNU multi-precision math 
libraries. These are consistently faster than using Squeak's own 
built-in libraries for many uses, including the Mandelbrot set generator 
I've mentioned before. Squeak doens't even HAVE a multi-precision float 
class, nor a multi-precision complex number class, and my preliminary 
testing suggests that past a certain precision-size, even the 
VeryLargeInteger class is always slower for every operation than using 
the GNU libraries, even though there is greater overhead in evoking the 
NativeBoost FFI.

Both Andreas Raab and Igor Stasenko have created automated ways of 
generating the FFI methods for OpenGL, and either technique could be 
used with some modification, to automate generating interfaces for 
different libraries.

The question becomes one of portability: the older FFI techniques are 
compatible with older platforms and VMs. NativeBOost only works with x86 
architectures and a specially modified CogVM. Both require that external 
libraries be used which aren't going to be available on every platform 
for which Squeak can be ported.

The tradeoffs are many and very complicated and there's no 
one-size-fits-all answer to the question of FFI vs plugin, Old School 
FFI vs NativeBoost.


Cheers.

L.






On 8/18/12 2:53 PM, David T. Lewis wrote:
> On Sat, Aug 18, 2012 at 08:19:34AM +0100, dimitris chloupis wrote:
>
> Hi Dimitris,
>
> Skip to the bottom for the important part, how to build plugins.
>
> But first I will try to answer your questions.
>
>> Why coders prefer FFIs ??
>>
> Some people prefer FFIs because it allows the interface to be done
> without using compilers or building VMs, and because it is not necessary
> to distribute a compiled plugin to provide the platform interface.
>
> Some people may prefer using an FFI because they think it will save
> time. They are usually wrong. Unfortunately, by the time they figure
> this out, they will have wasted a lot of time trying to do things the
> "easy way", and never bothered to invest a few hours to learn how to
> do it more reliably with a plugin.
>
>> For example I am a python coder, ctypes which is the FFI cpython comes with has seen an explosion the last years . The most suprising is the conversion of pyOpeng from C extenstion to ctypes libraries even though that has slow down the library 2-3x times. The reason behind that move is not hard to guess. Much easier to maintain. FFIs remove one importan element from the equation and pretty much why people avoid using C in the first place. Compiling and building. Thus making FFIs ideals for the fast changing libraries , be able to change things on the fly and not have to suffer the slow downs of the C compiler.?
>>
> Yes, an FFI is very adaptable because all changes can be done in the image,
> and that is a good thing. However, relying on the compiler is only a
> problem if you are waiting for someone *else* to compile it for you.
> If you are willing to learn to do it for yourself, it is actually very
> fast and easy to make updates. And if you do most of your work in Smalltalk
> (aka "slang"), you will manage it with the same version control and tools
> that you use for all the rest of your Smalltalk work.
>
> You will find that you have far better support for debugging and profiling
> when you use a plugin, because you can use the platform debuggers and other
> tools directly. Also (and this is a really big thing in practice), you
> have the benefits of strong type checking provided by the C compiler when
> you build the interface as a plugin rather than directing your calls through
> an FFI interface.
>
>> I have taken a look at VM plugins, glanced through some tutorials, if I am not mistaken Slang is used to produce C code that then is compiled in a form that can be loaded by the VM is a primitive. The like an FFI call , you just use the primitive to execute the action.?
>>
> Yes, that's right.
>
>> I am definetly interested , and if you have any link I am more than welcome them, my only hesitation is buidling C files . I am the type of coder that likes to moves one line of code (or several ) per time and always make sure by testing that I dont code garbage. One of the reason I decided to convert from python to squeak was because I felt that it was easier to "live code" in this enviroment. I fear that a VM plugin might cut short this experience. Please correct me If I am mistaken.?
>>
> See below for instructions that should help get you started. My explanation
> assumes you are using unix/Linux, so please let me know if you are on
> Windows or Mac or something else.
>
>> Saying that I have installed with ease CroquetGL and the opengl example seems to run fine, (exampletex fails but that is to be expected , have not tried the fix yet).?
>>
>> If VM plugins are more stable, reliable and what the squeak community prefers I have no issues going down that route.?
>>
> You will probably not get a consensus from the community. I am giving you
> an opinion based on my own personal experience.
>
> OK, with that out of the way, here is what you should do:
>
> Allow about two hours to work through these instructions for the first time.
> If you are using Linux or Unix, you can follow the steps exactly. If you
> use another platform, just do the things you can, and you will still be able
> to get an idea of how things works. Here are the steps to follow:
>
> Prepare tools. On Linux, install dev tools, libraries of interest, and Subversion.
>
> Get a copy of the platform sources. Do this in the same directory in which
> you will be running your Squeak image. On Linux:
>
>    $ svn co http://squeakvm.org/svn/squeak/trunk/platforms
>
> Any recent Squeak image will work for building VMs, but I like to work with
> an updated trunk image, like this:
>
>    world -> open... -> morphic project
>    (enter the project)
>    [menu bar] Tools -> Preferences
>    (select category Monticello. change Update URL from http://source.squeak.org/squeak43 to http://source.squeak.org/trunk.
>      accept the change (<ctl> s). click save button)
>    world -> help... -> update code from server
>    (wait for update process to complete, then save your image)
>
> Install VMMaker. This is the trunk version for an interpreter VM. Do it this way
> to get started so that you will be able to see your generated C code in a browser.
>
>    world -> open... Squeak Map Catalog
>    in the Squeak Map browser, click Update
>    select package VMMaker, version "head"
>    click Install
>    (wait for installation to complete)
>
>    In a workspace, evaluate "VMMaker initialize". This will activate the Slang browsing tools.
>    (note: in the future, you can evaluate "VMMaker updateFromServer" to keep your VMMaker up to date)
>
> Now have a look at some plugins.
>
> Open a browser on UnixOSProcessPlugin>>primitiveGetUid. This is a simple
> primitive call that links to the getuid() function in the C runtime library,
> and answers your uid when the primitive is called. This is how the primitive
> looks in Smalltalk. There is no C support code required, just the Smalltalk
> code that you see here.
>
> While looking at the primitiveGetUid method, click the "source" button on
> the browser, then select either "translate inlined C". You will now see
> the C code for the primitive.
>
> Explore a few more primitives and other methods, and have a look at other
> plugins, looking at both the Smalltalk source code and the generated C code.
>
> Now point your browser at B3DAcceleratorPlugin. This is a 3D graphics support
> plugin that uses GL. It was written by Andreas Raab, a distinguished Squeak
> guru and expert in graphics and VM programming. Andreas is less active on the
> list that he once was, but I'm sure he will chime it and offer some guidance
> once in a while. For now though, just treat this as a non-trivial example of
> interfacing to GL with a plugin.
>
> Last but not least: Build a VM. This will be a minimal configuration with
> only a few plugins, but it is enough to get you started. If you are able to
> do this successfully, then you have everything you need in order to start
> making your own plugins.
>
>    world -> open... -> VMMaker
>    click the the "Help" button and spend a few minutes reading it.
>    click the "Entire" button to generate VM source code.
>    This will translate the Smalltalk VM and plugin source code into C source
>      files, which will be stored in the directory src along side your platforms
>      directory. The platforms directory should contain all of the sources that
>      you downloaded with Subversion, the the src directory will contain the generated sources from Smalltalk.
>
> Now open a terminal window. Compile your VM as follows:
>
>    $ mkdir build
>    $ cd build
>    $ ../platforms/unix/cmake/configure --src=../src --without-gl
>    $ make
>
> If you want to install your new VM, do a "make install".
>
> HTH,
> Dave
>
>
>


-- 
Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner).
https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all