June 2014 - Pharo-dev - lists.pharo.org

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

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