Philippe Marschall wrote:
> The compiler itself works and can be loaded into 3.9 without problems.

Unfortunately, I can't confirm the "working without problems" part in 
3.9. For testing the speed I was copying class Object and it barfed 
halfways through in #copyTwoLevel in a perfectly valid expression:

class isVariable ifTrue:[
   index _ self basicSize.
   [index > 0] whileTrue:[
     newObject basicAt: index put: (self basicAt: index) shallowCopy.
     index _ index - 1]"xxxxx Argument expected ->xxxxx"].

(note: you can just select the expression in a workspace and doIt if you 
have compileUseNewCompiler enabled; it'll complain right away) This is 
very strange and the error message makes little sense to me - I tried 
adding a period because perhaps it was expecting a message to the block 
but that doesn't do it. Has anyone tried to simply recompile the 
entirety of 3.9 to see if that works or not? I've been using 
3.9-final-7067 for my test with the latest published Squeakmap releases 
for AST and NewCompiler. If there is a better version to use, please let 
me know.

[BTW, there are many other obscure errors that happen when I simply 
remove the offending code and continue to compile. Ultimately it appears 
to die somewhere unrelated at first glance but since this only happens 
when using compileUseNewCompiler I'm pretty sure it's related to some 
NewCompiler issues]

> Error messages are much improved and unlike your standard SmaCC error
> messages. Performance is lower. There is a lot of work going on in the
> decompiler and I don't know the exact state of this.

Nice to hear about the error messages. I hadn't tried the compiler in a 
while but the above really shows that error messages really have greatly 
improved.

Concerning speed: When doing an [Object2 compileAll] timeToRun (Object2 
being the partial copy of class Object that NewCompiler was able to hand 
me) I ended up with 1444 msecs for Compiler and 4020 msecs for 
NewCompiler. Unless I'm mistaken this is an improvement over the last 
version I tried which was roughly 4x slower (this is still 2.8x slower 
but it's a definitive improvement).

> You should ask Marcus about what the current status exactly is. Or Klaus.

It would be a big step if it were possible to recompile Squeak 
successfully and perhaps even bytecode-identically. Being able to 
generate an identical version of the method would allow people to 
trivially verify the correct functioning of NewCompiler.

>> And, do you know of any energy focused on improving the existing alternatives?
> 
> What alternatives?

The compiler that's actually being used. The one that's 3x faster ;-) If 
NewCompiler worked properly I'd be actually quite tempted to just adopt 
the closure solution to the current compiler since it's smaller, faster, 
and well-established.

Cheers,
   - Andreas