Right, if you embed source along with CompiledMethod (to handle the case when the CompiledMethod has been replaced but one of its block of code is still used), then you don't need Decompiler in the first place.

Nonetheless, I would remove the .sources but not the .changes. The .changes is not only a source code repository (that feature can go away if you want), it's before all a change log, an insurance to retrieve some change when everything else failed (image crashed or worse corrupted image won't restart). You can make the insurance optional if you want, but please continue to provide an equivalent service. A change file is the most simple thing that could possibly work IMO. But this is another thread.

Concerning the temp mapping, I agree, we should not compete with Eliot, he's very tough at tedious tasks, our only weapon is lazyness, lazyness often leads to efficiency ;) I'm curious to check how you handled this complex part with AST when I'll have more time to dig.

2013/4/27 Marcus Denker <marcus.denker@inria.fr>

On Apr 27, 2013, at 6:42 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:

> Thanks Marcus.
> I'm among the skepticals concerning the AST, but I'd like to be proven wrong, because AST level would certainly simplify things a lot.
> My main reserve is that interruption can occur at BC level, so for debugging purpose, what are your plans?
> Will you move the PC at some AST node boundary (if it is possible given side effects of some BC)?
>

For the Debugger, everything stays as it is (until Pharo 4 or so)� if you look at it, the current Debugger never decompiles if there is source available.
It *compiles* to get
        -> the mapping BC -> text
        -> the information how temporary variables in the byte code are actually related to temps in the source.
            (this is very complex, temps can be e.g. stored on the heap if they are written to in a closure, and when they are just
             read they have a different offset in each closure they are in. Conversely, some temps  in the byte code are used
            to store the array that hold the variables that are on the heap�)

The old compiler recorded mappings while compiling that where encoded� quite complex, at least for my tiny brain.

So the new just keeps the AST annotated with all the needed infos, this is much easier to debug (and we do have the
memory these days, and as we cache the AST, it's even fast).

So the debugger needs the compiler. The decompiler now exists just to make text so that we can call the compiler
in the case there is no .sources. The debugger *always* compiles to get the mappings, as soon as there is source code
the decompiler will never be used. (and even if the decompiler is used, the compiler is called right after on it's results so
one can record the mappings).

So if you make sure there is always source-code (or a representation with the right amount of meta data), you don't need the decompiler.

So at the start it will be the  source code. And yes, this takes memory. But  we are in 2013 and if we have one thing than it's memory.
(the $25 Raspi comes with 256MB, the $35 with 512MB�).

We could have shipped 2.0 with 8MB of useless Monticello meta data and nobody would have even realized it. (like we
have now megabytes of fonts in the image�). Yet the source is special� I really wonder why.

(And yes, there should be solutions to not need unused data in main memory and solutions to share across multiple images
data that is the same� but for all kinds of stuff, not just source code).

        Marcus