Bee SmaRT

The last days we've been working on integrating the code for loading libraries. This code required us to take deep breath, do a lot of diving and a bit of surgery here and there. So the whole changeset was done, but in our process, we had to split it in small pieces with tests before it could be integrated.  As this was going to take some time we thought it was also a good moment to take a break and introduce some long overdue refactorings. Happily, these days we have most of this tiresome work done. With the kernel in our hand and a library to load, we did some basic tests. One of the first things that got our attention was that the kernel was too big, our bee.exe kernel was 8.290.816 bytes long. You may think it's not that much but we were expecting -and would be comfortable with- something much smaller, in the order of 2 to 3 MB (the kernel library with just the objects and the bytecodes, without native code or all the PE (Windows executable format) tables is only 788.76...

For the last weeks we worked on libraries loading, and now it's working (even if we still have to fix some small issues). You may not notice how awesome this is, so let me explain how we work and how we were doing some things until now. All (most) of our development is test driven. We think a feature, we write a test and we run it. When you are running a test for something as basic as bootstrap, message lookup, or a primitive, things get a bit different. Such kinds of things are part of the kernel, and in order to test them we write an executable kernel file (bee.exe). This file has an entry point that performs basic initialization and then looks at command line arguments to know what to do. From our host image, our test generates the file, executes it, and looks for the return value. A 1 return value is considered success, and a 0 is an error. Of course, debugging at this stage is done with native debuggers. This worked so fine for the first baby steps of the kernel, that we wr...

I think the strongest design principle behind Bee Smalltalk is minimality. Bee works with a small kernel made of objects (SKernel), and other libraries (also made of objects). SKernel is very much minimal, it just contains basic objects (like the meta hierarchy, collections, streams, FFI and basic OS interaction), and knows how to load more libraries. To understand this, think of a method closure, which is a set of methods that only send messages whose implementations are inside this same set. Other libraries, on the other side, are similar to the SKernel, but they are only partial method closures, as they depend on themselves and also on SKernel or methods already loaded by other libraries. To be able execute code for these methods, their bytecodes are already nativized and included in SKernel. This is done with NativeCode objects, which include a ByteArray with the actual encoded x86 instructions, and are, as every other required object, included in the library itself. SKern...

We are looking forward to the Smalltalks , there are plenty of interesting talks this year. And even better than that, there's going to be a lot of people discussing new ideas and projects, a really good opportunity to find out what's going on in Smalltalk world. Of course, we are very excited to show our work too. Javi B did an excellent job on the slides and I think the talk is going to be great. There are lots of things to show this time and the future shows even more promising, with a huge amount of interesting things to work on. We are opening this blog to show a bit more what's going on under the hood on Bee development. Stay tuned, and be prepared to visit VM devs' Disneyland.