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 <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 >> >
