2007/12/19, Andreas Raab <andreas.raab at gmx.de>:
> 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.

I'll have a look at it. It can be that the ones on SqueakSource are newer.

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

I wasn't talking about compilation speed. What's really limiting for
bigger projects is not the speed of the compiler but PackageInfo which
makes Monticello slow. I was talking about execution speed.

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

The NewCompiler images from Marcus do this since a long time ago. See
the Recompiler class.

> and perhaps even bytecode-identically.

Nah, NewCompiler in certain circumstances generates marginally more
efficient bytecode.

> 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 ;-)

The one that's causing so much trouble in Seaside? The that gives you
this cool C++ feeling bugs where you spend two hours trying to find
out why your block arguments are all messed up and you think you went
crazy? And then suddenly you add a lot of #fixTemps everywhere until
it works?

Cheers
Philippe

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