Bee SmaRT

Wow, one blink of an eye and around a year passes! It's been a long time since the last post... you'll have to excuse me, but I find it very hard to make a pause to write here when at the same time I'm facing amazing problems such as the ones Bee poses. I'll try writing here more frequently, I hope I'll have the needed will power to keep doing the exercise. Anyway, in case you were wondering, yes! there's been a whole lot of work done since last year and I'm going show some of the advances in the Smalltalks, which happens to be hosted in Buenos Aires this year. For a while I've been rounding corners of the self-hosted system, implementing missing primitives, working in the debugger, user interface, garbage collection and more. The next posts will describe some of that work, hope to see you soon!

Today marks a key milestone in Bee project: we are realizing Bee main sources and libraries to the public sphere ! Do not get too excited yet. This is stated as a pre-release, because many things are yet missing and as the license is CC-BY-NC (for now). Also, there's no way to browse code like in a complete smalltalk environment, nor to rebuild the kernel. You can consider this as just a small preview of what the system is going to be like internally. There are two kinds of files: SLLs are the binary smalltalk libraries, SMLs contain the source code of their respective libraries. bee.sll is the main executable (it is just an .exe file, you can rename and double-click). In case no arguments are passed, a *REALLY* basic command line interface is shown, where you can enter some Smalltalk code: $> bee Welcome to bee. command line interface is waiting for you > 3+4+5 12 > 3 class SmallInteger > | o | o := Object new. o size 0 If you pass a file, like this: ...

A Smalltalk runtime that is able to execute concurrent sequences of code would be very useful. Seeing the rise of multicore/multiprocessor hardware and the direction the industry is taking, increasing the amount of cores in processors each year, makes us think we should be prepared. The simplest way of making use of multiple cores is to just avoid threads and directly work on multiple processes, connected by some kind of IPC. This is easier because different processes share nothing, except what you explicitly choose. Isolation helps program safety concurrency wise, as two fully separated processes cannot have race conditions between them. Then you would ask, why not just use processes? The main reason is that threads can be lighter and, in some way, more straightforward (as different threads share all their memory and resources). But also the question can be stated conversely, why not threads? Giving the option of using threads would be nice, so why not? There are lots of VMs ...

It's been quite some time since last post, we'be been really busy cooking Bee Smalltalk. You wouldn't believe how much work is needed in order to connect the dots! We continued trying to make libraries load in bee, but we felt that performance was abysmal, library loading was taking ages and tests were ran so slow that they were slowing down the whole development process. In order to measure performance, we ported a bunch of benchmarks to bee. Bee nchmarks The first benchmark we took was the simplest we know: tinyBenchmarks. It consists of a rather simple pair of metrics. The first one estimates bytecode speed and the second one dispatch speed. The bytecode test does a lot of arithmetic (which is executed directly without message sends) and sends only few messages: #new: , #at: , #at:put: . On the other hand, the dispatch test calculates Fibonacci recursively: ^self < 2 ifTrue: [1] ifFalse: [(self - 1) fibonacchi + (self - 2) fibonacchi + ...

We've been working very hard this year. The seed that was planted years ago has been growing underground and we are now starting to see the first leaves pop out. After Smalltalks 2013 we had the chance to stop the ball, have an overview and open to wider perspectives. After some time, we got back to daily work and thought about the current situation and the next steps. We opened this blog to let people know about both the progress of this project and the ideas around it. Now that the year is gone, we'd like to share some overview and vision of the future. We have lot's of stuff going on here and many things almost working that need a last push to get integrated. You know, that 1% boring stuff. We now have this small kernel working with libraries which is the base of the system. We also have a jitter, a garbage collector, and a starting point of a debugger all of them written in Smalltalk , but none of them is plugged yet. So we are asking ourselves, what do we do next,...

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