Smalltalk › Pharo › Pharo Smalltalk Developers

Fwd: break point

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

Stéphane Ducasse

Fwd: break point

>
> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Marcus Denker-4

Re: Fwd: break point

Yes...

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

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 :-)

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
> [hidden email]
> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Eliot Miranda-2

Re: Fwd: break point

Hi Marcus,

On Tue, Aug 17, 2010 at 12:10 PM, Marcus Denker <[hidden email]> wrote:

Yes...

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

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.

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?

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
> [hidden email]
> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stéphane Ducasse

Re: Fwd: break point

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/Wissant-C-te-d-Opale.jpg

http://www.google.fr/images?client=safari&rls=en&q=cap+blanc+nez&oe=UTF-8&redir_esc=&um=1&ie=UTF-8&source=univ&ei=MOZqTO_FGoL78AaUueXoBA&sa=X&oi=image_result_group&ct=title&resnum=4&ved=0CDEQsAQwAw

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
> > [hidden email]
> > 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stéphane Ducasse

Re: Fwd: break point

In reply to this post by Marcus Denker-4

> 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.

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

Mariano Martinez Peck

Re: Fwd: break point

On Tue, Aug 17, 2010 at 9:49 PM, Stéphane Ducasse <[hidden email]> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Marcus Denker-4

Re: Fwd: break point

In reply to this post by Eliot Miranda-2

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.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Marcus Denker-4

Re: Fwd: break point

In reply to this post by Stéphane Ducasse

On Aug 17, 2010, at 9:43 PM, Stéphane Ducasse wrote:
>
> 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/Wissant-C-te-d-Opale.jpg
>
> http://www.google.fr/images?client=safari&rls=en&q=cap+blanc+nez&oe=UTF-8&redir_esc=&um=1&ie=UTF-8&source=univ&ei=MOZqTO_FGoL78AaUueXoBA&sa=X&oi=image_result_group&ct=title&resnum=4&ved=0CDEQsAQwAw
>
> Now we just need the summer to get back in less than a year :)

And here summer often is on a Tuesday, as the saying goes.
But it's really nice, the cap blac nez with good weather.

Ah, and the brainstorming for the name went like this (shortened): Compiler. Translator? Hmm. It does have many Visitors. Maybe Louvre?
No... closer to the region. :-)

Marcus

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Tim Mackinnon

Re: Fwd: break point

In reply to this post by Marcus Denker-4

> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stéphane Ducasse

Re: Fwd: break point

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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project