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.den...@inria.fr> > > 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 >
