- Pharo-dev - lists.pharo.org

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

by Norbert Hartl

Am 23.06.2014 um 23:20 schrieb Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > > > > 2014-06-23 22:50 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > > > > 2014-06-23 22:38 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > > Hmmm, > > I'm trying to write a test for it and I wonder why > > testDynamicVariableAccessFromDifferentProcess > | process sem1 result | > > sem1 := Semaphore new. > process := [ > TestDynamicVariable > value: 123 > during: [ sem1 wait ] ] fork. > > Processor activeProcess > evaluate: [ result := TestDynamicVariable value ] > onBehalfOf: process. > sem1 signal. > self assert: result = 123 > > does not work. The variable accessing is in > > DynamicVariable>>#value: anObject during: aBlock > | p oldValue | > p := Processor activeProcess. > oldValue := (p psValueAt: index) ifNil: [ self default ]. > ^ [ > p psValueAt: index put: anObject. > aBlock value ] ensure: [ p psValueAt: index put: oldValue ] > > Any ideas? > > But what happens when you immediately fork, are you sure the forked process immediately pre-empts the activeProcess? > What if you introduce Processor activeProcess yield after the fork? > > > Ah, I just tried, it's Processor yield. > > [Transcript cr; show: 'A' ] fork. > Processor yield. > Transcript cr; show: 'B' . > > produces the required transcripting order. > Without yielding, B comes before A. > I knew it was something simple I forgot. Thank you very much, Norbert > > > Norbert > > Am 23.06.2014 um 21:29 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> >> >> On Mon, Jun 23, 2014 at 12:05 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >> Hi Eliot, >> >> thank you very much. I imported your changes in a pharo 3 image and it works awesome. So I'm preparing a slice for pharo. >> >> Thanks again, a very annoying problem seems to be solved, >> >> glad to hear it, and thanks for your prompting me as it's now in Squeak trunk too. >> >> >> Norbert >> >> Am 23.06.2014 um 19:29 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: >> >>> 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 >>> <trunk4.6EffectiveProcessMethods.st> >> >> >> >> >> -- >> best, >> Eliot > > >

June 23, 2014

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

by Nicolas Cellier

2014-06-23 22:50 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > > 2014-06-23 22:38 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > > Hmmm, >> >> I'm trying to write a test for it and I wonder why >> >> testDynamicVariableAccessFromDifferentProcess >> | process sem1 result | >> sem1 := Semaphore new. >> process := [ >> TestDynamicVariable >> value: 123 >> during: [ sem1 wait ] ] fork. >> Processor activeProcess >> evaluate: [ result := TestDynamicVariable value ] >> onBehalfOf: process. >> sem1 signal. >> self assert: result = 123 >> >> does not work. The variable accessing is in >> >> DynamicVariable>>#value: anObject during: aBlock >> | p oldValue | >> p := Processor activeProcess. >> oldValue := (p psValueAt: index) ifNil: [ self default ]. >> ^ [ >> p psValueAt: index put: anObject. >> aBlock value ] ensure: [ p psValueAt: index put: oldValue ] >> >> Any ideas? >> > > But what happens when you immediately fork, are you sure the forked > process immediately pre-empts the activeProcess? > What if you introduce Processor activeProcess yield after the fork? > > Ah, I just tried, it's Processor yield. [Transcript cr; show: 'A' ] fork. Processor yield. Transcript cr; show: 'B' . produces the required transcripting order. Without yielding, B comes before A. > >> > Norbert >> >> Am 23.06.2014 um 21:29 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> >> >> >> On Mon, Jun 23, 2014 at 12:05 PM, Norbert Hartl <norbert(a)hartl.name> >> wrote: >> >>> Hi Eliot, >>> >>> thank you very much. I imported your changes in a pharo 3 image and it >>> works awesome. So I'm preparing a slice for pharo. >>> >>> Thanks again, a very annoying problem seems to be solved, >>> >> >> glad to hear it, and thanks for your prompting me as it's now in Squeak >> trunk too. >> >> >>> >>> Norbert >>> >>> Am 23.06.2014 um 19:29 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: >>> >>> 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 >>> <trunk4.6EffectiveProcessMethods.st >>> <http://trunk4.6effectiveprocessmethods.st/>> >>> >>> >>> >> >> >> -- >> best, >> Eliot >> >> >> >

June 23, 2014

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

by Eliot Miranda

Hi Chris, On Jun 23, 2014, at 2:05 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > What specific problem are you having debugging? Stepping Through a > block which about to send message to a Proxy? It seems like I should > be having the same problem with Magma proxies.. I know sometimes I > would get a "Simulation" error while stepping Through (which would > blow up a debugging session) but that may have been caused by > something else because I don't remember seeing even that in a while.. > > I may be doing something different in my Proxy-reification process > than Glorp which lets it work even without using mirror primitives > (unless I'm using them without knowing it -- I'm not sure how they > work or even what they are)..? > If you're using squeak 4.4 ish or later you're already using them. They're simply access to objects without sending messages and are used by the debugger to make sure eg inst vars are accessed without sending messages which will have weird effects if debugging proxy code. > On Mon, Jun 23, 2014 at 3:16 PM, Esteban A. Maringolo > <emaringolo(a)gmail.com> wrote: >> 2014-06-23 16:59 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>> sad, but understandable. >>> in any case, it is a work for the pharo *community*, not for the consortium. >>> things that would help: >>> - an entry in the issue tracker >>> - an explanation of the use case needed to solve >>> - a pointer to Eliot modifications in squeak so the one who will do the job can take a look >> >> I added an entry to the issue tracker: >> https://pharo.fogbugz.com/f/cases/13377/Mirror-primitives-in-Debugger >> >> Which also refers back to this post, possibly causing an infinite recursion :) >> >>>> I hope somebody from Pharo with enough internals knowledge will pick this up. >>>> >>>> GLORP is the only ORM we have in Pharo 3, and debugging objects being >>>> mapped can get really nasty. >> >>> any other ORM you would do would use also proxies, so you would have the same problem :) >> >> I know, but that doesn't make my statement false. :) >> >>> is not a problem of GLORP but a problem in our support for proxies. >> >> What else uses this kind of proxies? >> >> >> Regards! >> >> Esteban A. Maringolo >

June 23, 2014

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

by Chris Muller

What specific problem are you having debugging? Stepping Through a block which about to send message to a Proxy? It seems like I should be having the same problem with Magma proxies.. I know sometimes I would get a "Simulation" error while stepping Through (which would blow up a debugging session) but that may have been caused by something else because I don't remember seeing even that in a while.. I may be doing something different in my Proxy-reification process than Glorp which lets it work even without using mirror primitives (unless I'm using them without knowing it -- I'm not sure how they work or even what they are)..? On Mon, Jun 23, 2014 at 3:16 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2014-06-23 16:59 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> sad, but understandable. >> in any case, it is a work for the pharo *community*, not for the consortium. >> things that would help: >> - an entry in the issue tracker >> - an explanation of the use case needed to solve >> - a pointer to Eliot modifications in squeak so the one who will do the job can take a look > > I added an entry to the issue tracker: > https://pharo.fogbugz.com/f/cases/13377/Mirror-primitives-in-Debugger > > Which also refers back to this post, possibly causing an infinite recursion :) > >>> I hope somebody from Pharo with enough internals knowledge will pick this up. >>> >>> GLORP is the only ORM we have in Pharo 3, and debugging objects being >>> mapped can get really nasty. > >> any other ORM you would do would use also proxies, so you would have the same problem :) > > I know, but that doesn't make my statement false. :) > >> is not a problem of GLORP but a problem in our support for proxies. > > What else uses this kind of proxies? > > > Regards! > > Esteban A. Maringolo >

June 23, 2014

Spec Button Shortcut Indication

by Sven Van Caekenberghe

Hi, The following looks different in my Dark Theme image vs a Standard image (same version #30848): ButtonModel new label: 'Click Me'; shortcut: $C asShortcut; action: [ self inform: 'OK, you clicked me !' ]; openWithSpec. The difference is the C that is underlined. Is this intentional ? Is there a way to have a shortcut, but not the underlining ? Thx, Sven

June 23, 2014

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

by Nicolas Cellier

2014-06-23 22:38 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > Hmmm, > > I'm trying to write a test for it and I wonder why > > testDynamicVariableAccessFromDifferentProcess > | process sem1 result | > sem1 := Semaphore new. > process := [ > TestDynamicVariable > value: 123 > during: [ sem1 wait ] ] fork. > Processor activeProcess > evaluate: [ result := TestDynamicVariable value ] > onBehalfOf: process. > sem1 signal. > self assert: result = 123 > > does not work. The variable accessing is in > > DynamicVariable>>#value: anObject during: aBlock > | p oldValue | > p := Processor activeProcess. > oldValue := (p psValueAt: index) ifNil: [ self default ]. > ^ [ > p psValueAt: index put: anObject. > aBlock value ] ensure: [ p psValueAt: index put: oldValue ] > > Any ideas? > But what happens when you immediately fork, are you sure the forked process immediately pre-empts the activeProcess? What if you introduce Processor activeProcess yield after the fork? > > Norbert > > Am 23.06.2014 um 21:29 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > > On Mon, Jun 23, 2014 at 12:05 PM, Norbert Hartl <norbert(a)hartl.name> > wrote: > >> Hi Eliot, >> >> thank you very much. I imported your changes in a pharo 3 image and it >> works awesome. So I'm preparing a slice for pharo. >> >> Thanks again, a very annoying problem seems to be solved, >> > > glad to hear it, and thanks for your prompting me as it's now in Squeak > trunk too. > > >> >> Norbert >> >> Am 23.06.2014 um 19:29 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> 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 >> <trunk4.6EffectiveProcessMethods.st >> <http://trunk4.6effectiveprocessmethods.st/>> >> >> >> > > > -- > best, > Eliot > > >

June 23, 2014

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

by Norbert Hartl

Hmmm, I'm trying to write a test for it and I wonder why testDynamicVariableAccessFromDifferentProcess | process sem1 result | sem1 := Semaphore new. process := [ TestDynamicVariable value: 123 during: [ sem1 wait ] ] fork. Processor activeProcess evaluate: [ result := TestDynamicVariable value ] onBehalfOf: process. sem1 signal. self assert: result = 123 does not work. The variable accessing is in DynamicVariable>>#value: anObject during: aBlock | p oldValue | p := Processor activeProcess. oldValue := (p psValueAt: index) ifNil: [ self default ]. ^ [ p psValueAt: index put: anObject. aBlock value ] ensure: [ p psValueAt: index put: oldValue ] Any ideas? Norbert Am 23.06.2014 um 21:29 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > On Mon, Jun 23, 2014 at 12:05 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Hi Eliot, > > thank you very much. I imported your changes in a pharo 3 image and it works awesome. So I'm preparing a slice for pharo. > > Thanks again, a very annoying problem seems to be solved, > > glad to hear it, and thanks for your prompting me as it's now in Squeak trunk too. > > > Norbert > > Am 23.06.2014 um 19:29 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: > >> 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 >> <trunk4.6EffectiveProcessMethods.st> > > > > > -- > best, > Eliot

June 23, 2014

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

by Esteban A. Maringolo

2014-06-23 16:59 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > sad, but understandable. > in any case, it is a work for the pharo *community*, not for the consortium. > things that would help: > - an entry in the issue tracker > - an explanation of the use case needed to solve > - a pointer to Eliot modifications in squeak so the one who will do the job can take a look I added an entry to the issue tracker: https://pharo.fogbugz.com/f/cases/13377/Mirror-primitives-in-Debugger Which also refers back to this post, possibly causing an infinite recursion :) >> I hope somebody from Pharo with enough internals knowledge will pick this up. >> >> GLORP is the only ORM we have in Pharo 3, and debugging objects being >> mapped can get really nasty. > any other ORM you would do would use also proxies, so you would have the same problem :) I know, but that doesn't make my statement false. :) > is not a problem of GLORP but a problem in our support for proxies. What else uses this kind of proxies? Regards! Esteban A. Maringolo

June 23, 2014

is it save to always recompute a TextMorphs extent if the font changed

by Nicolai Hess

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 23, 2014

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

by Esteban Lorenzano

On 23 Jun 2014, at 16:49, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2014-06-23 16:28 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> Hi Esteban, > >>> 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. > >>> Would you mind adapting your mirror methods changes to work also in >>> Pharo 3 (and maybe in Pharo 4 too?). > >> I'm sorry Esteban, but that is work for the Pharo consortium to do. My time >> is limited and I use Squeak. > > That's totally understandable. sad, but understandable. in any case, it is a work for the pharo *community*, not for the consortium. things that would help: - an entry in the issue tracker - an explanation of the use case needed to solve - a pointer to Eliot modifications in squeak so the one who will do the job can take a look > > I hope somebody from Pharo with enough internals knowledge will pick this up. > > GLORP is the only ORM we have in Pharo 3, and debugging objects being > mapped can get really nasty. any other ORM you would do would use also proxies, so you would have the same problem :) is not a problem of GLORP but a problem in our support for proxies. Esteban > > Regards! > > Esteban A. Maringolo >

June 23, 2014