Bee SmaRT

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. SKernel c