> Am 24.06.2014 um 00:27 schrieb Eliot Miranda <eliot.mira...@gmail.com>: > > > > >> On Mon, Jun 23, 2014 at 3:04 PM, Norbert Hartl <norb...@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 <norb...@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 <steph...@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.mira...@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 <norb...@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
