August 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fwd: break point

by StÃ©phane Ducasse

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/Wissa… http://www.google.fr/images?client=safari&rls=en&q=cap+blanc+nez&oe=UTF-8&r… 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(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 17, 2010

Re: [Pharo-project] Fwd: break point

by Eliot Miranda

Hi Marcus, On Tue, Aug 17, 2010 at 12:10 PM, Marcus Denker <marcus.denker(a)inria.fr>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 > > Pharo-project(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 17, 2010

[Pharo-project] About changes

by StÃ©phane Ducasse

Hi guys I'm slowly going over the changes proposed by guillermo to remove ParagraphEditor (thansk guillermo). Now I think that this is important that we do not remove instance creation methods or method deprecated too fast. This is important that we let a chance to people to migrate. This is why we will remove the deprecate method of 1.1 when we will start 1.3 and not when we started 1.2. Stef

Aug. 17, 2010

Re: [Pharo-project] Load OB in Pharo 1.2

by StÃ©phane Ducasse

On Aug 17, 2010, at 8:28 PM, Lukas Renggli wrote: > Removing them is cool, but there should be a grace period where they > are deprecated. But how? We could let the subclass empty in this case (is it what you mean) but when we are doing refactoring like changing iv it may not work. We could not really let the classes in the system. I have the impression that having branch at the tool level is something that we cannot avoid. > Now I had to duplicate the whole class in OB with a > uniue name. ?? > > On Tuesday, August 17, 2010, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: >> Sorry, that was Stef and I at Camp Smalltalk. Did feel good to be rid of XYZPlus classes though ;-) >> >> Regards, Gary >> >> ----- Original Message ----- From: "Lukas Renggli" <renggli(a)gmail.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Tuesday, August 17, 2010 7:07 PM >> Subject: Re: [Pharo-project] Load OB in Pharo 1.2 >> >> >> On Tuesday, August 17, 2010, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >> On Aug 17, 2010, at 7:31 PM, Lukas Renggli wrote: >> >> >> Thanks Lukas. I wasn't who remove that class neither who didn't deprecated. >> I am just trying to start building Dev images from now...otherwise, we will >> have to wait a lot of time once the core is released. >> >> >> I think there must be a delay between the release of the core and the >> non-core images. I don't see how that can otherwise work. Of course it >> makes sense to have some incremental adaption already upfront ... >> >> >> Hmm... one thing is clear: I want to use Refactoring and especially the >> Code Critique tool on 1.2. So I need to somehow load it. >> >> >> Yeah that make sense, but I cannot maintain code that I can't use. >> >> Lukas >> >> >> >> (2 pages of philosophical ramblings deleted... I should start a blog..) >> >> Marcus >> >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 17, 2010

Re: [Pharo-project] Fwd: break point

by Marcus Denker

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 > Pharo-project(a)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.

Aug. 17, 2010

Re: [Pharo-project] Load OB in Pharo 1.2

by StÃ©phane Ducasse

> >>> >>> (2 pages of philosophical ramblings deleted... I should start a blog..) >> >> >> No >> rambling blog are boring :) > > No need to read it... maybe I could just write them and then delete them? > Would help, too. Yes people call that catharsis :) It is good to express stuff. I delete also mails I would like to send :) Stef

Aug. 17, 2010

Re: [Pharo-project] Should I be able to hang my pharo 1.1 image so easily?

by StÃ©phane Ducasse

thanks for reporting that. do you have a case that we could reproduce or have an image people could access? Stef On Aug 17, 2010, at 8:30 PM, Panu Suominen wrote: > I think I have the same problem. It does not actually jam the image > right away but makes it really slow which renders it unusable. After a > while memory runs out and it crashes. Have not seen this many times > thou. It would help if there was a key sequence which would suspend > other than UI process. > > -- > Panu > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 17, 2010

[Pharo-project] Fwd: break point

by StÃ©phane Ducasse

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

Aug. 17, 2010

Re: [Pharo-project] Load OB in Pharo 1.2

by Marcus Denker

On Aug 17, 2010, at 8:07 PM, Lukas Renggli wrote: > On Tuesday, August 17, 2010, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On Aug 17, 2010, at 7:31 PM, Lukas Renggli wrote: >> >>>> Thanks Lukas. I wasn't who remove that class neither who didn't deprecated. >>>> I am just trying to start building Dev images from now...otherwise, we will >>>> have to wait a lot of time once the core is released. >>> >>> I think there must be a delay between the release of the core and the >>> non-core images. I don't see how that can otherwise work. Of course it >>> makes sense to have some incremental adaption already upfront ... >> >> Hmm... one thing is clear: I want to use Refactoring and especially the >> Code Critique tool on 1.2. So I need to somehow load it. > > Yeah that make sense, but I cannot maintain code that I can't use. > So I guess I should maintain a branch for 1.2... I really want to use it. And we need at some point to think about what to do for the browser. do we really maintain two? Even if OB is not "the browser to end all browsers", isn't it good enough to replace the old one for now? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Aug. 17, 2010

Re: [Pharo-project] Load OB in Pharo 1.2

by Marcus Denker

On Aug 17, 2010, at 8:08 PM, StÃ©phane Ducasse wrote: >> >> (2 pages of philosophical ramblings deleted... I should start a blog..) > > > No > rambling blog are boring :) No need to read it... maybe I could just write them and then delete them? Would help, too. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Aug. 17, 2010