- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] How to debug code using DynamicVariable?

by Norbert Hartl

> Am 24.06.2014 um 00:27 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > >> On Mon, Jun 23, 2014 at 3:04 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >> The slice cannot be integrated automatically because there is a modal popping up >> >> Warning: Process should not be redefined. Proceed to store over it. >> >> Not sure what to do. Manual integration? > > Can you not wrap that in "[] valueSupplyingAnswer: true" ? >> Sure. But I can only provide the monticello package and this code needs to go into the build process. Right? I just wanted to say it early. I think the guys know how to treat it. If there is anything I can do.... Norbert >> Norbert >> >>> Am 23.06.2014 um 23:55 schrieb Norbert Hartl <norbert(a)hartl.name>: >>> >>> https://pharo.fogbugz.com/default.asp?13378 >>> >>> Btw. I tested this as well in 3.0 and a backport would be highly appreciated. >>> >>> Norbert >>> >>>> Am 23.06.2014 um 20:08 schrieb stepharo <stepharo(a)free.fr>: >>>> >>>> Thanks Eliot. >>>> Sven, Norbert if you package that nicely (BTW having some tests would be great) we can include that in 4.0 >>>> >>>> Stef >>>>> On 23/6/14 19:29, Eliot Miranda wrote: >>>>> and here are the changes I've just committed to Squeak trunk. >>>>> >>>>> >>>>>> On Mon, Jun 23, 2014 at 10:05 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>>>> Hi Norbert, >>>>>> >>>>>> [ let me try again. never try and get code out too early in the morning ;-) ] >>>>>> >>>>>> it is the debugger that needs fixing, not your code !! :-). The debugger needs to respect process identity. Andreas and I (mostly Andreas) came up with the following changes at Qwaq. Your message is a good reminder that I need to add this to Squeak asap. >>>>>> >>>>>> The idea is for Process to have an additional inst var 'effectiveProcess' that holds the actual process running code. For the most part this is self, but in the debugger we substitute the process being debugged: >>>>>> >>>>>> Process methods for accessing >>>>>> effectiveProcess >>>>>> "effectiveProcess is a mechanism to allow process-faithful debugging. The debugger executes code >>>>>> on behalf of processes, so unless some effort is made the identity of Processor activeProcess is not >>>>>> correctly maintained when debugging code. The debugger uses evaluate:onBehalfOf: to assign the >>>>>> debugged process as the effectiveProcess of the process executing the code, preserving process >>>>>> identity." >>>>>> ^effectiveProcess ifNil: [self] >>>>>> >>>>>> then the relevant methods in Process and processorScheduler defer to effectiveProcess, e.g. >>>>>> >>>>>> ProcessorScheduler methods for process state change >>>>>> terminateActive >>>>>> "Terminate the process that is currently running." >>>>>> >>>>>> activeProcess effectiveProcess terminate >>>>>> >>>>>> and the debugging methods use evaluate:onBehalfOf: to install the process being debugged: >>>>>> >>>>>> Process methods for private >>>>>> evaluate: aBlock onBehalfOf: aProcess >>>>>> "Evaluate aBlock setting effectiveProcess to aProcess. Used >>>>>> in the execution simulation machinery to ensure that >>>>>> Processor activeProcess evaluates correctly when debugging." >>>>>> | oldEffectiveProcess | >>>>>> oldEffectiveProcess := effectiveProcess. >>>>>> effectiveProcess := aProcess. >>>>>> ^aBlock ensure: [effectiveProcess := oldEffectiveProcess] >>>>>> >>>>>> Process methods for changing suspended state >>>>>> step >>>>>> >>>>>> ^Processor activeProcess >>>>>> evaluate: [suspendedContext := suspendedContext step] >>>>>> onBehalfOf: self >>>>>> >>>>>> stepToCallee >>>>>> "Step until top context changes" >>>>>> >>>>>> Processor activeProcess >>>>>> evaluate: >>>>>> [| ctxt | >>>>>> ctxt := suspendedContext. >>>>>> [ctxt == suspendedContext] whileTrue: [ >>>>>> suspendedContext := suspendedContext step]] >>>>>> onBehalfOf: self. >>>>>> ^suspendedContext >>>>>> >>>>>> etc. Changes from a Qwaq image attached. >>>>>> >>>>>> HTH >>>>>> >>>>>> >>>>>> On Mon, Jun 23, 2014 at 4:50 AM, Norbert Hartl <norbert(a)hartl.name> wrote: >>>>>>> In my code I'm using a DynamicVariable to request a context object when needed. Until now I knew the name DynamicVariable only from seaside. There it is called WADynamicVariable and it is an exception. So I blindly assumed the pharo DynamicVariable works the same. >>>>>>> I thought this might be a good optimization not to travel the stack all the time but put in the process. >>>>>>> Now that I am using it I can see the difference. I find it real hard using it because I don't know how to debug/step in code. DynamicVariable is a process specific variable but as soon as a debugger opens it is very likely to be in another process. This makes stepping in method using the DynamicVariable impossible. The only way round is to set break points after the dynamic lookup and step from there. But this feels just wrong. >>>>>>> What would be the best way to have DynamicVariable and be able to debug anything? Or is there a variant that uses the stack instead of the "active" process? >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Norbert >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> best, >>>>>> Eliot >>>>> >>>>> >>>>> >>>>> -- >>>>> best, >>>>> Eliot >>>> >>> >> > > > > -- > best, > Eliot

June 24, 2014

Re: [Pharo-dev] How to debug code using DynamicVariable?

by stepharo

> The slice cannot be integrated automatically because there is a modal > popping up > > > Warning: Process should not be redefined. Proceed to store > over it. > > > Not sure what to do. Manual integration? We will check that :) > > Norbert > > Am 23.06.2014 um 23:55 schrieb Norbert Hartl <norbert(a)hartl.name > <mailto:norbert@hartl.name>>: > >> https://pharo.fogbugz.com/default.asp?13378 >> >> Btw. I tested this as well in 3.0 and a backport would be highly >> appreciated. >> >> Norbert >> >> Am 23.06.2014 um 20:08 schrieb stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>>: >> >>> Thanks Eliot. >>> Sven, Norbert if you package that nicely (BTW having some tests >>> would be great) we can include that in 4.0 >>> >>> Stef >>> On 23/6/14 19:29, Eliot Miranda wrote: >>>> and here are the changes I've just committed to Squeak trunk. >>>> >>>> >>>> On Mon, Jun 23, 2014 at 10:05 AM, Eliot Miranda >>>> <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >>>> >>>> Hi Norbert, >>>> >>>> [ let me try again. never try and get code out too early >>>> in the morning ;-) ] >>>> >>>> it is the debugger that needs fixing, not your code !! :-). >>>> The debugger needs to respect process identity. Andreas and I >>>> (mostly Andreas) came up with the following changes at Qwaq. >>>> Your message is a good reminder that I need to add this to >>>> Squeak asap. >>>> >>>> The idea is for Process to have an additional inst var >>>> 'effectiveProcess' that holds the actual process running code. >>>> For the most part this is self, but in the debugger we >>>> substitute the process being debugged: >>>> >>>> /Process methods for accessing/ >>>> *effectiveProcess* >>>> "effectiveProcess is a mechanism to allow process-faithful >>>> debugging. The debugger executes code >>>> on behalf of processes, so unless some effort is made the >>>> identity of Processor activeProcess is not >>>> correctly maintained when debugging code. The debugger uses >>>> evaluate:onBehalfOf: to assign the >>>> debugged process as the effectiveProcess of the process >>>> executing the code, preserving process >>>> identity." >>>> ^effectiveProcess ifNil: [self] >>>> >>>> then the relevant methods in Process and processorScheduler >>>> defer to effectiveProcess, e.g. >>>> >>>> /ProcessorScheduler methods for process state change/ >>>> *terminateActive* >>>> "Terminate the process that is currently running." >>>> >>>> activeProcess effectiveProcess terminate >>>> >>>> and the debugging methods use evaluate:onBehalfOf: to install >>>> the process being debugged: >>>> >>>> /Process methods for private/ >>>> *evaluate: aBlock onBehalfOf: aProcess* >>>> "Evaluate aBlock setting effectiveProcess to aProcess. Used >>>> in the execution simulation machinery to ensure that >>>> Processor activeProcess evaluates correctly when debugging." >>>> | oldEffectiveProcess | >>>> oldEffectiveProcess := effectiveProcess. >>>> effectiveProcess := aProcess. >>>> ^aBlock ensure: [effectiveProcess := oldEffectiveProcess] >>>> >>>> /Process methods for changing suspended state/ >>>> *step* >>>> >>>> ^Processor activeProcess >>>> evaluate: [suspendedContext := suspendedContext step] >>>> onBehalfOf: self >>>> >>>> *stepToCallee* >>>> "Step until top context changes" >>>> >>>> Processor activeProcess >>>> evaluate: >>>> [| ctxt | >>>> ctxt := suspendedContext. >>>> [ctxt == suspendedContext] whileTrue: [ >>>> suspendedContext := suspendedContext step]] >>>> onBehalfOf: self. >>>> ^suspendedContext >>>> >>>> etc. Changes from a Qwaq image attached. >>>> >>>> HTH >>>> >>>> >>>> On Mon, Jun 23, 2014 at 4:50 AM, Norbert Hartl >>>> <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >>>> >>>> In my code I'm using a DynamicVariable to request a context >>>> object when needed. Until now I knew the name >>>> DynamicVariable only from seaside. There it is called >>>> WADynamicVariable and it is an exception. So I blindly >>>> assumed the pharo DynamicVariable works the same. >>>> I thought this might be a good optimization not to travel >>>> the stack all the time but put in the process. >>>> Now that I am using it I can see the difference. I find it >>>> real hard using it because I don't know how to debug/step >>>> in code. DynamicVariable is a process specific variable but >>>> as soon as a debugger opens it is very likely to be in >>>> another process. This makes stepping in method using the >>>> DynamicVariable impossible. The only way round is to set >>>> break points after the dynamic lookup and step from there. >>>> But this feels just wrong. >>>> What would be the best way to have DynamicVariable and be >>>> able to debug anything? Or is there a variant that uses the >>>> stack instead of the "active" process? >>>> >>>> thanks, >>>> >>>> Norbert >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> best, >>>> Eliot >>>> >>>> >>>> >>>> >>>> -- >>>> best, >>>> Eliot >>> >> >

June 24, 2014

Re: [Pharo-dev] Stepping through with GLORP Proxies

by stepharo

Esteban I would like to know how different are the Glorp proxies from the ones of Mariano. Because we are thinking about to get by default a nice proxy system. Proxies in the sense of object representing one that is not in the system (and not proxies as metaobject or representing an object that is around as in the JS literature). Ideally I would like to unify both. Stef On 23/6/14 20:45, Esteban A. Maringolo wrote: > Eliot, > > I never installed your proposed changes in a Pharo 3 image because > there is a significant change in ContextPart. Your proposed changeset > changes classVars of ContextPart. > > Your proposal: > classVariableNames: 'MaxLengthForASingleDebugLogReport > MaxStackDepthForASingleDebugLogReport PrimitiveFailToken QuickStep > ValueIndex' > > Current vars: > classVariableNames: 'PrimitiveFailToken QuickStep > SpecialPrimitiveSimulators TryNamedPrimitiveTemplateMethod' > > Would you mind adapting your mirror methods changes to work also in > Pharo 3 (and maybe in Pharo 4 too?). > > Esteban A. Maringolo > > > 2014-02-26 14:40 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> Hi Esteban, >> >> find attached. Let me know of any problems. >> >> >> On Wed, Feb 26, 2014 at 8:32 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> >> wrote: >>> Hi Eliot, >>> >>> >>> 2013-11-30 18:30 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>> On Fri, Nov 29, 2013 at 2:22 PM, Esteban A. Maringolo >>>> <emaringolo(a)gmail.com> >>>> wrote: >>>>> 2013/11/29 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>>>> I'll either prepare a change set or submit. It'll get done. >>>>> I can continue stepping into until the change is ready. >>>>> Please make it compatible with Pharo 2 (whatever that means in term of >>>>> code) :) >>>> >>>> OK, the code is now in Squeak trunk. What image should I use to >>>> integrate >>>> into Pharo 2? A url please... >>> I'm coming back late to this. Because the change wasn't integrated in >>> Pharo 2. >>> >>> Do you have the changeset applied to Squeak Trunk? I'd like to reapply >>> it in my Pharo 2 image (at my own risk). >>> Can you send it to may email address? >>> >>> Thank you! >>> >>> Esteban A. Maringolo >>> >> >> >> -- >> best, >> Eliot >

June 24, 2014

Re: [Pharo-dev] is it save to always recompute a TextMorphs extent if the font changed

by stepharo

Hi nicolai this is a couple of weeks were I'm thinking about the way widgets use fonts. It is orthogonal to your mail but related. Most of the system is refering to fonts via a global variable. And to me this is wrong. I would like to experiment with a solution similar to Settings: - 1 Font should be hold by an instance variables of the widgets. The code of the widgets should only refer to this state - 2 Now there is the question of the propagation when we change and there I would do the same as settings: pragma + builder What do the community think? Stef On 23/6/14 22:00, Nicolai Hess wrote: > About issue 13376 Wrong TextMorph extent for ButtonMorphs > <https://pharo.fogbugz.com/default.asp?13376> : > > If you use different fonts as default font and button font, buttons > labels may get truncated. > > One solution would be to always recompute the TextMorphs extent when its > font changes, but I don't know if this is always desirable. > > Otherwise, if we recompute the extent on the creation time of the button, > I am not sure if all buttonlabels have styled text.

June 24, 2014

Re: [Pharo-dev] [ANN] DrGeo 14.07b

by Hilaire Fernandes

http://forum.world.st/BalloonCanvas-drawPolygon-tp4671832.html https://pharo.fogbugz.com/f/cases/7565/BalloonCanvas-drawPolygon Any way we have Athens, no need to bother with Balloon. Sure Athens has many problem, and we need to use it to document the problems and to find fixes or workarounds. Now, I'll really love a newer VM for MacOSX with the Athens circle bugs gone: https://pharo.fogbugz.com/f/cases/13364/Mac-OS-X-and-Windows-VM-with-newer-… Hilaire Le 24/06/2014 07:41, Hilaire Fernandes a Ã©crit : > It is related to Polygon, we have a thread on the forum, search for > "hilaire balloon anti aliased" > > Hilaire > > Le 23/06/2014 11:27, stepharo a Ã©crit : >> Hi hilaire >> >> can you remind us what is broken? and why the squeak version would fix it? >> >> Stef >> >> On 23/6/14 08:50, Hilaire Fernandes wrote: >>> Not at chance with Pharo, part of balloon canvas is broken (see a post >>> of mine about 2 years ago). >>> If you are serious about using it you should fix it or use Squeak. >>> >>> >>> Hilaire >>> >>> Le 23/06/2014 00:11, phil(a)highoctane.be a >>> Ã©crit : >>>>> Ah ok I thought you managed your code on launchpad. >>>>> >>>>> Is Athens the only way to have anti-aliased vector graphics in Pharo ? >>>> I got antialiased graphics with the balloon engine without Athens. >>>> >>>> I'll dig for how. It is somewhere in my first Pharo experiments on >>>> Smalltalkhub. >>>> >>>> Phil >>>> >> >> >> > -- Dr. Geo http://drgeo.eu iStoa - https://launchpad.net/istoa

June 24, 2014

Re: [Pharo-dev] [ANN] DrGeo 14.07b

by Hilaire Fernandes

Right, but in that situation I really have to use the system icon to be consistant, as it is for an user dialog. Hilaire Le 23/06/2014 11:28, stepharo a Ã©crit : > > I think that this is better that DrGeo embeds the resources that it needs. > UITheme is to me a kind of design problem. -- Dr. Geo http://drgeo.eu iStoa - https://launchpad.net/istoa

June 24, 2014

Re: [Pharo-dev] [ANN] DrGeo 14.07b

by Hilaire Fernandes

It is related to Polygon, we have a thread on the forum, search for "hilaire balloon anti aliased" Hilaire Le 23/06/2014 11:27, stepharo a Ã©crit : > Hi hilaire > > can you remind us what is broken? and why the squeak version would fix it? > > Stef > > On 23/6/14 08:50, Hilaire Fernandes wrote: >> Not at chance with Pharo, part of balloon canvas is broken (see a post >> of mine about 2 years ago). >> If you are serious about using it you should fix it or use Squeak. >> >> >> Hilaire >> >> Le 23/06/2014 00:11, phil(a)highoctane.be a >> Ã©crit : >>>> Ah ok I thought you managed your code on launchpad. >>>> >>>> Is Athens the only way to have anti-aliased vector graphics in Pharo ? >>> I got antialiased graphics with the balloon engine without Athens. >>> >>> I'll dig for how. It is somewhere in my first Pharo experiments on >>> Smalltalkhub. >>> >>> Phil >>> > > > -- Dr. Geo http://drgeo.eu iStoa - https://launchpad.net/istoa

June 24, 2014

Re: [Pharo-dev] How to debug code using DynamicVariable?

by Eliot Miranda

On Mon, Jun 23, 2014 at 3:04 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > The slice cannot be integrated automatically because there is a modal > popping up > > Warning: Process should not be redefined. Proceed to store over it. > > Not sure what to do. Manual integration? > Can you not wrap that in "[] valueSupplyingAnswer: true" ? > > Norbert > > Am 23.06.2014 um 23:55 schrieb Norbert Hartl <norbert(a)hartl.name>: > > https://pharo.fogbugz.com/default.asp?13378 > > Btw. I tested this as well in 3.0 and a backport would be highly > appreciated. > > Norbert > > Am 23.06.2014 um 20:08 schrieb stepharo <stepharo(a)free.fr>: > > Thanks Eliot. > Sven, Norbert if you package that nicely (BTW having some tests would be > great) we can include that in 4.0 > > Stef > On 23/6/14 19:29, Eliot Miranda wrote: > > and here are the changes I've just committed to Squeak trunk. > > > On Mon, Jun 23, 2014 at 10:05 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> Hi Norbert, >> >> [ let me try again. never try and get code out too early in the >> morning ;-) ] >> >> it is the debugger that needs fixing, not your code !! :-). The >> debugger needs to respect process identity. Andreas and I (mostly Andreas) >> came up with the following changes at Qwaq. Your message is a good >> reminder that I need to add this to Squeak asap. >> >> The idea is for Process to have an additional inst var >> 'effectiveProcess' that holds the actual process running code. For the >> most part this is self, but in the debugger we substitute the process being >> debugged: >> >> *Process methods for accessing* >> *effectiveProcess* >> "effectiveProcess is a mechanism to allow process-faithful debugging. >> The debugger executes code >> on behalf of processes, so unless some effort is made the identity of >> Processor activeProcess is not >> correctly maintained when debugging code. The debugger uses >> evaluate:onBehalfOf: to assign the >> debugged process as the effectiveProcess of the process executing the >> code, preserving process >> identity." >> ^effectiveProcess ifNil: [self] >> >> then the relevant methods in Process and processorScheduler defer to >> effectiveProcess, e.g. >> >> *ProcessorScheduler methods for process state change* >> *terminateActive* >> "Terminate the process that is currently running." >> >> activeProcess effectiveProcess terminate >> >> and the debugging methods use evaluate:onBehalfOf: to install the >> process being debugged: >> >> *Process methods for private* >> *evaluate: aBlock onBehalfOf: aProcess* >> "Evaluate aBlock setting effectiveProcess to aProcess. Used >> in the execution simulation machinery to ensure that >> Processor activeProcess evaluates correctly when debugging." >> | oldEffectiveProcess | >> oldEffectiveProcess := effectiveProcess. >> effectiveProcess := aProcess. >> ^aBlock ensure: [effectiveProcess := oldEffectiveProcess] >> >> *Process methods for changing suspended state* >> *step* >> >> ^Processor activeProcess >> evaluate: [suspendedContext := suspendedContext step] >> onBehalfOf: self >> >> *stepToCallee* >> "Step until top context changes" >> >> Processor activeProcess >> evaluate: >> [| ctxt | >> ctxt := suspendedContext. >> [ctxt == suspendedContext] whileTrue: [ >> suspendedContext := suspendedContext step]] >> onBehalfOf: self. >> ^suspendedContext >> >> etc. Changes from a Qwaq image attached. >> >> HTH >> >> >> On Mon, Jun 23, 2014 at 4:50 AM, Norbert Hartl <norbert(a)hartl.name> >> wrote: >> >>> In my code I'm using a DynamicVariable to request a context object when >>> needed. Until now I knew the name DynamicVariable only from seaside. There >>> it is called WADynamicVariable and it is an exception. So I blindly assumed >>> the pharo DynamicVariable works the same. >>> I thought this might be a good optimization not to travel the stack all >>> the time but put in the process. >>> Now that I am using it I can see the difference. I find it real hard >>> using it because I don't know how to debug/step in code. DynamicVariable is >>> a process specific variable but as soon as a debugger opens it is very >>> likely to be in another process. This makes stepping in method using the >>> DynamicVariable impossible. The only way round is to set break points after >>> the dynamic lookup and step from there. But this feels just wrong. >>> What would be the best way to have DynamicVariable and be able to debug >>> anything? Or is there a variant that uses the stack instead of the "active" >>> process? >>> >>> thanks, >>> >>> Norbert >>> >>> >>> >> >> >> -- >> best, >> Eliot >> > > > > -- > best, > Eliot > > > > > -- best, Eliot

June 23, 2014

Re: [Pharo-dev] How to debug code using DynamicVariable?

by Norbert Hartl

The slice cannot be integrated automatically because there is a modal popping up Warning: Process should not be redefined. Proceed to store over it. Not sure what to do. Manual integration? Norbert Am 23.06.2014 um 23:55 schrieb Norbert Hartl <norbert(a)hartl.name>: > https://pharo.fogbugz.com/default.asp?13378 > > Btw. I tested this as well in 3.0 and a backport would be highly appreciated. > > Norbert > > Am 23.06.2014 um 20:08 schrieb stepharo <stepharo(a)free.fr>: > >> Thanks Eliot. >> Sven, Norbert if you package that nicely (BTW having some tests would be great) we can include that in 4.0 >> >> Stef >> On 23/6/14 19:29, Eliot Miranda wrote: >>> and here are the changes I've just committed to Squeak trunk. >>> >>> >>> On Mon, Jun 23, 2014 at 10:05 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> Hi Norbert, >>> >>> [ let me try again. never try and get code out too early in the morning ;-) ] >>> >>> it is the debugger that needs fixing, not your code !! :-). The debugger needs to respect process identity. Andreas and I (mostly Andreas) came up with the following changes at Qwaq. Your message is a good reminder that I need to add this to Squeak asap. >>> >>> The idea is for Process to have an additional inst var 'effectiveProcess' that holds the actual process running code. For the most part this is self, but in the debugger we substitute the process being debugged: >>> >>> Process methods for accessing >>> effectiveProcess >>> "effectiveProcess is a mechanism to allow process-faithful debugging. The debugger executes code >>> on behalf of processes, so unless some effort is made the identity of Processor activeProcess is not >>> correctly maintained when debugging code. The debugger uses evaluate:onBehalfOf: to assign the >>> debugged process as the effectiveProcess of the process executing the code, preserving process >>> identity." >>> ^effectiveProcess ifNil: [self] >>> >>> then the relevant methods in Process and processorScheduler defer to effectiveProcess, e.g. >>> >>> ProcessorScheduler methods for process state change >>> terminateActive >>> "Terminate the process that is currently running." >>> >>> activeProcess effectiveProcess terminate >>> >>> and the debugging methods use evaluate:onBehalfOf: to install the process being debugged: >>> >>> Process methods for private >>> evaluate: aBlock onBehalfOf: aProcess >>> "Evaluate aBlock setting effectiveProcess to aProcess. Used >>> in the execution simulation machinery to ensure that >>> Processor activeProcess evaluates correctly when debugging." >>> | oldEffectiveProcess | >>> oldEffectiveProcess := effectiveProcess. >>> effectiveProcess := aProcess. >>> ^aBlock ensure: [effectiveProcess := oldEffectiveProcess] >>> >>> Process methods for changing suspended state >>> step >>> >>> ^Processor activeProcess >>> evaluate: [suspendedContext := suspendedContext step] >>> onBehalfOf: self >>> >>> stepToCallee >>> "Step until top context changes" >>> >>> Processor activeProcess >>> evaluate: >>> [| ctxt | >>> ctxt := suspendedContext. >>> [ctxt == suspendedContext] whileTrue: [ >>> suspendedContext := suspendedContext step]] >>> onBehalfOf: self. >>> ^suspendedContext >>> >>> etc. Changes from a Qwaq image attached. >>> >>> HTH >>> >>> >>> On Mon, Jun 23, 2014 at 4:50 AM, Norbert Hartl <norbert(a)hartl.name> wrote: >>> In my code I'm using a DynamicVariable to request a context object when needed. Until now I knew the name DynamicVariable only from seaside. There it is called WADynamicVariable and it is an exception. So I blindly assumed the pharo DynamicVariable works the same. >>> I thought this might be a good optimization not to travel the stack all the time but put in the process. >>> Now that I am using it I can see the difference. I find it real hard using it because I don't know how to debug/step in code. DynamicVariable is a process specific variable but as soon as a debugger opens it is very likely to be in another process. This makes stepping in method using the DynamicVariable impossible. The only way round is to set break points after the dynamic lookup and step from there. But this feels just wrong. >>> What would be the best way to have DynamicVariable and be able to debug anything? Or is there a variant that uses the stack instead of the "active" process? >>> >>> thanks, >>> >>> Norbert >>> >>> >>> >>> >>> >>> -- >>> best, >>> Eliot >>> >>> >>> >>> -- >>> best, >>> Eliot >> >

June 23, 2014

Re: [Pharo-dev] How to debug code using DynamicVariable?

by Norbert Hartl

https://pharo.fogbugz.com/default.asp?13378 Btw. I tested this as well in 3.0 and a backport would be highly appreciated. Norbert Am 23.06.2014 um 20:08 schrieb stepharo <stepharo(a)free.fr>: > Thanks Eliot. > Sven, Norbert if you package that nicely (BTW having some tests would be great) we can include that in 4.0 > > Stef > On 23/6/14 19:29, Eliot Miranda wrote: >> and here are the changes I've just committed to Squeak trunk. >> >> >> On Mon, Jun 23, 2014 at 10:05 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> Hi Norbert, >> >> [ let me try again. never try and get code out too early in the morning ;-) ] >> >> it is the debugger that needs fixing, not your code !! :-). The debugger needs to respect process identity. Andreas and I (mostly Andreas) came up with the following changes at Qwaq. Your message is a good reminder that I need to add this to Squeak asap. >> >> The idea is for Process to have an additional inst var 'effectiveProcess' that holds the actual process running code. For the most part this is self, but in the debugger we substitute the process being debugged: >> >> Process methods for accessing >> effectiveProcess >> "effectiveProcess is a mechanism to allow process-faithful debugging. The debugger executes code >> on behalf of processes, so unless some effort is made the identity of Processor activeProcess is not >> correctly maintained when debugging code. The debugger uses evaluate:onBehalfOf: to assign the >> debugged process as the effectiveProcess of the process executing the code, preserving process >> identity." >> ^effectiveProcess ifNil: [self] >> >> then the relevant methods in Process and processorScheduler defer to effectiveProcess, e.g. >> >> ProcessorScheduler methods for process state change >> terminateActive >> "Terminate the process that is currently running." >> >> activeProcess effectiveProcess terminate >> >> and the debugging methods use evaluate:onBehalfOf: to install the process being debugged: >> >> Process methods for private >> evaluate: aBlock onBehalfOf: aProcess >> "Evaluate aBlock setting effectiveProcess to aProcess. Used >> in the execution simulation machinery to ensure that >> Processor activeProcess evaluates correctly when debugging." >> | oldEffectiveProcess | >> oldEffectiveProcess := effectiveProcess. >> effectiveProcess := aProcess. >> ^aBlock ensure: [effectiveProcess := oldEffectiveProcess] >> >> Process methods for changing suspended state >> step >> >> ^Processor activeProcess >> evaluate: [suspendedContext := suspendedContext step] >> onBehalfOf: self >> >> stepToCallee >> "Step until top context changes" >> >> Processor activeProcess >> evaluate: >> [| ctxt | >> ctxt := suspendedContext. >> [ctxt == suspendedContext] whileTrue: [ >> suspendedContext := suspendedContext step]] >> onBehalfOf: self. >> ^suspendedContext >> >> etc. Changes from a Qwaq image attached. >> >> HTH >> >> >> On Mon, Jun 23, 2014 at 4:50 AM, Norbert Hartl <norbert(a)hartl.name> wrote: >> In my code I'm using a DynamicVariable to request a context object when needed. Until now I knew the name DynamicVariable only from seaside. There it is called WADynamicVariable and it is an exception. So I blindly assumed the pharo DynamicVariable works the same. >> I thought this might be a good optimization not to travel the stack all the time but put in the process. >> Now that I am using it I can see the difference. I find it real hard using it because I don't know how to debug/step in code. DynamicVariable is a process specific variable but as soon as a debugger opens it is very likely to be in another process. This makes stepping in method using the DynamicVariable impossible. The only way round is to set break points after the dynamic lookup and step from there. But this feels just wrong. >> What would be the best way to have DynamicVariable and be able to debug anything? Or is there a variant that uses the stack instead of the "active" process? >> >> thanks, >> >> Norbert >> >> >> >> >> >> -- >> best, >> Eliot >> >> >> >> -- >> best, >> Eliot >

June 23, 2014