thats why I still program in text files and use gdb for debugging. They are fast and reliable, that's what you need for algorithms anyway. And who cares about abstractions.

I like your style

Unless you regularly updated and worked on the latest 2.0 beta this is news ;). You have a complete list of images here http://pharo.gforge.inria.fr/ci/image/20/ including release dates.

During the beta update process it might happen that one or another update fails. Usually that should not happen though.

I did system updates, eventually got (mostly)everything loaded (after a few re-trys), but then the image wouldn't save.

So: it only took me a minute or two to fileOut my application packages and reload them and data into a new image. I should have done this in he first place :-(

or use http://smalltalkhub.com in the first place :)

Yep I can only agree with you, and there is some communication issue for the matter of the image/vm downloads.

Some measures have been taken especially if you run from the commandline use the zeroconf scripts from http://files.pharo.org/scripts. However still some issue remain that are currently not nice!

- no full 64bit support (will be addressed but with a 32bit image format this isn't that straight forward) - missing warning to install 32bit libs under linux (workaround on the way) - proper packaging (rpm / deb) which installs the dependencies is missing (also, there are some attempts there) - you have to explicitly tell the VM to run headless or not (I honestly don't know why! :D)

All in all you caught us, we mostly develop on mac, however our test infrastructure is running on linux hence imperatively Pharo has to run under linux. Yet there is some need for proper explanations, installation requirements!

Pharo has quite a decent set of command-line tools at hand for a Smalltalk (see also http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/late...). As for FFI we're about to fully integrate NativeBoost into the system which already provides decent FFI interaction on all X86 platforms: https://code.google.com/p/nativeboost/. The VM we use features a JIT, albeit not highly elaborate, it gives decent speedups. Besides that there is some research of mine going on, on how to implement the JIT native code generate at language side, which would give us the Smalltalk-level control over that piece.

Wonderful!

(I didn't ask about Pharo, I complained about promoting Pharo by dissing other Smalltalk implementations.)

What you don't know Kent Beck!! :D and yes even to me that quote is rather meaningless :P. I'll try to get the at least the ALT text updated.

Nope, even though it is ready for 2.0 it was not included in the release. If you are more interested you can have a look at the prepared jenkins images https://ci.inria.fr/rmod/job/Opal/ .

What was new in the compiler?

Cleanups and a modern implementation with proper separation of the compiler toolchain. Additionally they introduced a nice new IR representation to do more sophisticated changes. All in all it does not come with fancy new features but a more solid and clean codebase.

And we're eager to top this in the following years ;)

Yes seaside is still in active development and there is progress on getting a nice configuration working on Pharo 2.0. Until then you can use our manual build from https://ci.inria.fr/pharo-contribution/job/Seaside-2.0/ to test it.

It isn't fully functional, is it? The image from the CI opens with an STDOUT error.

What's missing to have a "nice" (working?) configuration for Pharo 2.0?

Seaside works, yet it has not been officially release for 2.0 hence we rely on a gofer script to load all dependencies. What error? I doubt it's related to seaside. And for the configuration we mostly need somebody to do it :) since the seaside config is pretty big on its own you got to be careful when changing things for a new release.