On Apr 27, 2013, at 5:26 PM, Nicolas Cellier
<nicolas.cellier.aka.n...@gmail.com> wrote:
> I see that the OCFakeDecompiler which uses the old and horrible (*)
> Decompiler is still in use.
> Though, IRBytecodeDecompiler seems already quite advanced.
The idea actually is to not have a decompiler BC->AST. We have one BC->IR for
manipulating
things on the byte code level (e.g. he new class builder will use it).
BC->IR->BC is working and tested after every commit.
But on the AST level, idea is to have a higher level representation of code
always
available. (compressed ASTs in the long term, compressed source as the
intermediate solution).
Yes, I know that people will be highly skeptical about this.
Up to the point that I even don't expect to convince anyone other than by
actually showing a working
version…
This goes hand-in-hand with the "one file" image: just one .pharo image, no
.sources, no .changes.
(Which real conservative people will not like, either).
We need to see how fast this progresses, if we see that it will not be ready
for 3.0, we should add
a IR->AST decompiler, but I hope the alternative will show that it is not
necessary.
> Could we have a primer on what remains to do on the Opal front?
>
-> debug BC-IR->AST->text mapping more (lots of it working already)
-> debug temp variable lookup in optimized blocks in the debugger (almost
there, too)
-> Go through all the test for the old Compiler and port them to the new.
-> Better compiler API and refactor the whole system to use it
(but keep a backward compatible API at least to some extend)
Marcus
