On Aug 17, 2010, at 9:37 PM, Eliot Miranda wrote:
At least in Squeak 4.1. one can see the fact its break-pointed in the debugger because the method in the debugger is decompiled.
Of course it's far from nice anyway... showing the break context, no breakpoint visibly shown in the debugger... I honestly don't remember what was changed. And why the debugger would show decompied code? All this mapping source-offset to bytecode offset is horribly complex in the debugger...
We should add a nice UI for it *and* soon we can do oh so much better much easier :-)
Tell me more, tell me more, was it love at first sight?? What are you cooking up?
The first step will be un-spectacular... but I just realized that it should quite simple to add real breakpoints with the Opal Compiler framework using bytesurgen or even RB-AST transformations. In the current Debugger, that is. e.g. using bytecode level manipulations: Debugger knows the bytecode-offsets of selected code, the bytecode representation bytesurgen works on knows these offsets too (either when decompiled from bc or after code-gen). So one can easily extend Bytesurgeon to do something like "add bytecode described by the following smalltalk code (which is a probe) before the bytecodes that encode the source offsets X". Of course we need to take care with source-bc mapping for the debugger... So what I really want to do is to get rid of bytecode completely as a user-visible artefact. The Persephone/ Reflectivity stuff has shown that this simplifies everything *a lot*. Helvetia is the other example. Lukas has a Debugger that directly works on RB AST trees. With stepping and all. And the RB tree can be annotated. And we can put meaning on these annotations (see Reflectivity) in the sense of "before executing the node, execute this block" But looking into that is the step after. One step at a time... first finishing the Opal Compiler. Then Bytesurgeon, then ByteSurgeon using a Helvetia DSL... What Opal will bring is: Parser to RB-AST (from Helvetia, scannerless, composable, great). Or optionally RBParser (faster). Then a Semantic checker that does all the ugly closure analysis in a far less ugly way (maintainable, understandable for people non-Eliot...) while *not destroying the AST* . A Backend that allows for a very simple code-gen visitor. And there is a evaluating visitor for the AST as another nice tool for the tool-chest. Then a back-end that allows bytecode-level manipulation to be done relatively high-level (aka bytsurgeon). We will see... one step at a time. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
