I'm doing the final preparation for the 0.15 release. There's a Linux VM and a Windows VM built so far. The Windows VM lacks freetype but should otherwise be OK, a proper Windows VM with Freetype would be nice especially as these VMs have Eliot's closure bytecodes in them.. I'll build an image in the next few days. The code on SqueakSource should be very close to the actual release code.

There's no Mac VM. It would be nice if someone built one.

I may add full method inlining in the next release, or at least an initial implementation. Inlining is a fairly simple feature except for blocks and de-optimisation. The problem with blocks is they can be accessed from external contexts so need to exist and can be returned to which complicates inlining them. The problem with de-optimisation is almost another blocks problem as de-optimisation needs to be thought about a little more carefully when de-optimising a method context may impact the execution of the block.

The solution is probably to create contexts for both blocks and methods that create blocks. It'll make the inlined block situation a little slower but will make it possible to de-optimise one context at a time without risking crashes. Block contexts can always be removed if they're inlined from creation to execution, i.e. for the entire loop. The exact block inlining design doesn't need to be decided yet, it can wait until after the simple case of inlining a method into another method is implemented and debugged.

Starting on full method inlining is a departure from plan. 0.15 looks solid enough to enable easy debugging of blocks. The original plan was to continue tuning for a 1.0 before adding full method inlining. the advantage of adding full method inlining now is it's a key part of the original design and will provide a large performance impact both in performance gains and also in changing relative costs.

Bryce