>> If Squeak is going to make it bigtime, it's VM has to stop sucking.
>

> Again, not the first time you say that. You should remind me of some 
> actual improvements you contributed to the Squeak VM, which might 
> give a tiny bit of substance to your rants.


A bit over a year ago, I had gone through every method in the VM to try
to minimize the number of memory accesses it makes. -- and reduce the
size of the generated source file. During the last attempt, I had cut
the 650k interp.c by 100k!

I had made significant progress and had learned a great deal about how
the actual objects are implemented.

Unfortunately, my HD died and It took me all summer to save up for a new
one.

I tried to resume my work but the current version at the time wouldn't
build on my new setup. I was able to use Ian's vm but not one I
generated myself.

Currently, I attempt to build a new VM with the current SVN sources and
Squeak-Map VM. (Or the Squeak Map VM with any available sources!) every
two weeks. I have not succeded yet therefore I complain. =\

The archive of the VM-developer's list contains a large number of these
complaints.

Once I get these sources operational again, I will use the opportunity
to review the plugin code because it is even more neglected than the VM
itself.

>> Ideally, ffi can be overhauled into an efficient means for calling
>> external libraries
>
> [... lots snipped ...]

> How in particular do you think we could improve the efficiency of FFI?


I am studying the issues.

>> FFI does have its limitations on UNIX, meaning that the VM will  have to
>> be restarted to upgrade to new versions of libraries.
>
> Last time I checked you could simply unload the library, which will 
> get reloaded the next time you issue a function call.


I don't recall ever seeing that done on Unix...
The linker is 100% undocumented anyway...