On Mon, Jun 23, 2014 at 3:04 PM, Norbert Hartl <[email protected]> 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 <[email protected]>: > > 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 <[email protected]>: > > 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 <[email protected]> > 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 <[email protected]> >> 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
