Hi Marcus,

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.

Now the BreakPointmanager can remove all BreakPoints, all for a class and things like that easily. it knows if there is one. CompiledMethod has #hasBreakpoint. Setting breakpoints does not invalidate code (as opposed to self halt).

So there is everything to make a nice UI for it...

One thing it badly needs is a "browse breakpointed methods" or "list breakpointed methods"

The model is a bit limited. Only break on entry, no probes and so on. But it works. The limitations are mostly because everything else is hard to do with the bad model we have in the current system of doing structural reflection below method granularity...

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?

Opale compiler framework :) Opale is from cote d'opale and its lovely cap blanc nez and dunes :) http://a10.idata.over-blog.com/672x463/0/41/15/99/Entre-ciel-et-terre/Wissan... http://www.google.fr/images?client=safari&rls=en&q=cap+blanc+nez&oe=UTF-8&re... Now we just need the summer to get back in less than a year :)

best Eliot

Marcus

On Aug 17, 2010, at 8:56 PM, Stéphane Ducasse wrote:

...

...

In CodeHolder apparently there is support for breakpoint. Does anybody know how this works? Stef

toggleBreakOnEntry "Install or uninstall a halt-on-entry breakpoint"

| selectedMethod | self selectedClassOrMetaClass isNil ifTrue:[^self]. selectedMethod := self selectedClassOrMetaClass >> self selectedMessageName. selectedMethod hasBreakpoint ifTrue: [BreakpointManager unInstall: selectedMethod] ifFalse: [BreakpointManager installInClass: self selectedClassOrMetaClass selector: self selectedMessageName].

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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.

On Tue, Aug 17, 2010 at 9:49 PM, Stéphane Ducasse <stephane.ducasse@inria.fr

wrote:

...

Yes...

I was guilty of harvesting that for 3.7 or 3.6... (Squeak that is).

nobody is guilty (we are not in religious stuff).

...

In the Old Browser, you have an entry "toggle break on entry". What this does is that it compiles a new version of the method (it uses a bit a

strange

...

way of doing that using the old AST...). This version has a self break at the beginning, yet points to the old source so you don't see it.

Now the BreakPointmanager can remove all BreakPoints, all for a class and things like that easily. it knows if there is one. CompiledMethod has #hasBreakpoint. Setting breakpoints does not invalidate code (as opposed to self halt).

So there is everything to make a nice UI for it...

The model is a bit limited. Only break on entry, no probes and so on. But it works. The limitations are mostly because everything else is hard to do with the bad model we have in the current system of doing structural reflection below method granularity...

We should add a nice UI for it *and* soon we can do oh so much better much easier :-)

May be lukas can get inspired and provide some break points support for OB :) For CodeHolder may be somebody else wants to have a look.

But promise me that after putting a breakpoint I won't see my package as dirty ;)

Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

We will have them :) Marcus shows me Opal today and probably in 1.3 we will have really nice compiler and all nice bytecode manipulation framework (like bytesurgeon). So we will have simple break points and after cool one. Stef On Aug 18, 2010, at 9:02 PM, TimM wrote:

...

I was guilty of harvesting that for 3.7 or 3.6... (Squeak that is).

Thanks for trying to get it in, it would be so nice if we could have easy ui breakpoints like other smalltalks and languages.

I remain hopeful from your other comments though.

Tim

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project