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.