VisualWorks

Currently I'm working on Faish, a Prolog variant. Eventually I'll need a reasonable user interface, and to package the result for people to install. Therefore, I'm planning to move from Squeak to VisualWorks, as I would be pretty ashamed to expect "end-users" to use Morphic. I could use GtkSqueak (having some experience with that), but that's plan B for now as I'd need to spend time repairing and updating GtkSqueak.

Cincom: you're doing it wrong!

1. You guys make it really hard to get to the software.
2. My first attempt did not work; the email never arrived.
3. WTF - a .iso file!? I just want the Linux VM and whatever image your Smalltalk uses. Plus I'm seriously not going to write it to a CD.

So now I wait for the eventual completion of a flippen 514MiB download, which probably includes a heap of stuff I don't even want.

I also tried moving to Pharo 1.4. Pharo: you're still not good.

1. I wanted to use ToolBuilder. It's not in the image. That's okay; I'll install it from a version I was working on before.
2. Monticello had a fit. Some classes in the .mcz file declare instance variables that already exist in superclasses. Instead of a recoverable error message, I get some exception and a debugger.
3. I try it again. This time, the image seizes up when loading the package. I press alt-.. The VM quits to the shell (!?).
4. Eventually I manage to get it loaded by various magical incantations. I then open some other window and I get an emergency evaluator (obviously something I did broke Morphic, which is standard behaviour).

Obviously, ToolBuilder needs fixing, but how does one fix a package if you can't even load it?

THIS is the reason I was working on SecureSqueak, and my latest work (unfortunately stagnant now) was working on remedying this:

1. You should always be able to load a package, even if it is broken.
2. Loading a package should not affect the usability of the rest of your image.
3. The UI should never freeze up. Never, unless the hardware has failed.

Slitaz Linux

Lately I've been looking for a distribution of Linux for the sole purpose of running Squeak / Pharo. Essentially it would be a single-application installation of Linux; only the Squeak VM would be running and nothing else is really needed.

Slitaz Linux is a Linux distro which is in total 30MB, which includes the LXDE desktop environment (my favourite) and a credible number of applications. I find that downright impressive. It runs entirely in RAM meaning that it is *very* responsive.

My Laptop is a Dell C640 from the 18th century; I replaced the hard disk with a CompactFlash card and installed Slitaz on it. I customized Slitaz by removing applications I wouldn't use, added Xorg for my hardware and generated a 20MB image. I also installed a "big" version of Slitaz as well which mounts the CF card for the root filesystem so I can run gcc etc.

Now I have a Squeak development machine with a 30 second boot time and insane reactivity.

There were issues. I needed to rebuild the Squeak VM without OpenGL support (because Slitaz doesn't include those libraries, and Squeak won't start without them). For future reference, I needed to install (from memory) gcc, binutils, linux-headers, cmake and xorg-dev. I also needed to modify the VM source to properly include dirent.h somewhere.

Class format

I want to add more instance variables to Class. How difficult is this? Pretty. I suspect that for vanilla Squeak or Pharo, you'd need to carefully remake every single Metaclass instance and Class instance. For me, my Packages architecture means I only need to recompile my own private Metaclasses and all its instances which can be done safely.

Before I started though, I wanted to see what happened if I did something wrong: what happens if I add the extra variables to Class, but instances and subclasses of Class (i.e. every single class and class class) were not updated?

Classes in the Squeak VM have three variables very important variables which are referenced directly by the VM: superclass, format and methodDictionary. The format describes the nature of instances: are they normal/variable/words/bytes/weak, and how many instance variables does each instance have. "format" is a bit-field, so you need to wrangle bits to modify it.

What I'm going to test is what the VM does if I'm not careful and forget to update an instance of Class somewhere to be big enough to store my extra instance variables:

1. Make a class, e.g. "TestVMCrash", with three instance variables, and a method, e.g. >>third, which sets the third instance variable.
2. Get the format of that class: "TestVMCrash format", which returns 136 for me (which means "normal class, 3 instvars").
3. Reduce the number of instance variables in TestVMCrash to 2.
4. Make an instance and try to set the third, now non-existent, instance variable.

So after making the class, I reduce the number of instance variables:

ClassBuilder new computeFormat: #normal instSize: 2 forSuper: Object ccIndex: 0

" returns 134 "

TestVMCrash setFormat: 134. "The class now has only two instvars"

Now:

o := TestVMCrash new.

" o will have 2 instance varables, but here we try to set an non-existant third: "

o third.

This causes the VM to behave badly. The first time I tried, it crashed with a SEGFAULT. The second time, it froze. The VM barged ahead and corrupted the image, so there are no checks on invalid instance variable accesses.

In conclusion, I need to be very careful when adding instance variables to Class, and back up my image often.

Now, where was I?

A year has passed since I last worked on SecureSqueak. Babies do that to you. So now, I ask myself: what was I doing!?

It appears I was trying to set up a completely independent class hierarchy / object graph with no dependencies on Squeak's classes. In other words, my own Class, Metaclass, Object and so forth, all in a Namespaced environment rather than in the SystemDictionary (known colloquially as the "Smalltalk" global object).

This is trickier than it seems. All of the above need to live "in" a Package object. As an object, it is therefore an instance of the Package class, which has Class, Object and so forth as superclasses. So these (Class, Object, etc) all need to be made first... but then these classes in turn need to be in a Package (called "Kernel"). Thus, we have a chicken-and-egg problem. We need an instance of Package, which is an instance of a class inside itself (and further, compiled by a compiler which is in another instance of Package).

My solution is to file out the core packages using my current tools: Kernel, SourceCode, Compiler, Namespaces, NamespaceTools, etc. Then I do this:

1. File in (but do not compile) the Kernel package, using the existing compiler and a custom filing code.
2. Make the new Metaclass singularity by hand.
3. Compile the Kernel package using whatever compiler is available, using the new Metaclasses.
   
4. File in and compile all other dependencies using the resulting Kernel. These will all be discarded once the second kernel is built.
   
5. File in the Kernel source code again into a separate PackageSource, this time using the new Kernel (above) for the Object, Class etc classes.
   
6. Now, do a whole lot of "special case" handling on the new second Kernel, using and sacrificing bits from the first, to make the new Kernel completely self-contained. This is quite a complex step so I'll spare the details.
   

Thus is born a set of objects with no links whatsoever to any Class in the SystemDictionary.

SqueakOS the cheaters way

Cold boot to Squeak under 6 seconds? Possible. I haven't actually automated it yet, but it is possible as described below.

Tiny Core Linux is a mini Linux distribution that is, before boot, only two files. One is the Linux kernel. The other is the entire filesystem which is loaded into RAM. These two files are packaged up into a bootable .iso image for burning to a CD, although you can put them on any bootable medium and boot them using grub. You can put these files on an existing Linux partition on your hard disk, for example. The "tiny" version is 10MB and has a graphical interface and package manager! The "micro" version is 6MB and is only a command line. They boot really fast.

Now, the micro version can be used to run Squeak:

1. Boot it up using one of the "vga=" command line parameters to get a working framebuffer. You could use grub to persist this setting.
   
2. Get Squeak into the filesystem somehow. I used wget to fetch an image and the Linux VM from ftp://ftp.squeak.org/. A more permanent option would be mounting an existing filesystem.
   
3. Become root (sudo su) to run Squeak, or fix the permissions on /dev/input/mice.
4. Run squeak: "bin/squeak -vm-display-fbdev".

This is not quite as cool as SqueakNOS, but it is a practical, easy and stable way of running Squeak as if it were the OS with good hardware support and a filesystem.

Squeak vs Pharo

How does Squeak compare to Pharo?

Well, people will have different experiences. Some will find the features of Pharo appealing. Pharo comes with a huge range of developer tools: syntax highlighting, autocompletion, code refactoring tools and a whole lot of smaller enhancements that people might like.

Pharo looks nicer than Squeak. They've dared to change the menus around, in my opinion, for the better. They've taken a lot of inspiration ("blatently copied") from the Macintosh UI. They've also changed much of the interaction with the user, although the whole UI still freezes up whenever the image is doing something (please, learn to use multi-threading! It isn't hard!).

I've been living on Pharo for the last 6 months because I wanted to use and modify the NewCompiler. I've gone back to Squeak. Why? Pharo is too slow. I have a Celeron clocked at 1.7GHz. Pharo's debugger takes forever to appear when something goes wrong. The browser is very laggy to type into. The UI in general looks like a Porshe, but certainly doesn't perform like one.

The deal-breaker for me was that Pharo couldn't load a Monticello package I wrote. Pharo would freeze up, and alt-. would not recover it. Apparently this has been fixed in the later releases.

So I'm back in Squeak. It's still slow like Squeak is, but at least the debugger comes up in a reasonable amount of time.

Dammit, Nethack!

I have been a bit... distracted lately by a certain chaotic elven wizard with a penchant for Yendorian amulets. I'll be back into SecureSqueak shortly.