On Apr 27, 2013, at 8:00 PM, Nicolas Cellier <nicolas.cellier.aka.n...@gmail.com> wrote:
> 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. I agree, we have been discussing (and I do not like much the idea to have the changes inside the image as objects because now we have a nice literal object parser/writer and making sure that we can never lose source code is cool). In any case we are working on a new change format recording more high-level entity (such refactoring). We looked again at the model that veronica did, and Ezequiel and we looked again at DeltaStreams. We should digest all that and come up with a new alternate changes model file. I was about to contact goran to see if he wants to participate/ read a paper but we should write the paper first :) > 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 >
