On Apr 27, 2013, at 6:42 PM, Nicolas Cellier
<nicolas.cellier.aka.n...@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
