Bee SmaRT

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 wand

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,