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