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

Re: [Pharo-dev] Handling keyboard eventsâ¦

by Stephan Eggermont

This pull request might be relevant: https://github.com/pharo-project/pharo-vm/pull/49

June 24, 2014

Re: [Pharo-dev] SystemWindow instances can't be garbage-collected

by Max Leske

On 24.06.2014, at 15:30, Max Leske <maxleske(a)gmail.com> wrote: > For documentation purposes, this is what I found to be necessary to really clean all window instances. Note that this only works reliably when invoked from a non-UI process (e.g. via WAKom). > > > cleanupWindows > "in general: the gabage collector seems to be unable to resolve all circular dependencies with weak pointers. > This forces us to explicitly remove the weak pointers to enable garbage colltection. > It also seems to be a problem to invoke the cleanup from within a UI process (e.g. from a workspace). > Ergo: > - when invoked from a workspace not all instances may be garbage collected > - when invoked from a non UI process (e.g. WAKom) all instances should have been collected > - performning a manual garbage collection after having invoked this code from a workspace will > (usually) remove the pending instances (new process context)" > | count | > count := 1. > self > cleanupEvents; I forgot: #cleanupEvents is simply âEventManager cleanUp: trueâ > cleanupWorkspaces; > cleanupSystemWindows. > [ Smalltalk garbageCollect. count := count + 1 ] doWhileFalse: [ > SystemWindow allSubInstances isEmpty or: [ count > 5 "arbitrary number" ] ] > > cleanupWorkspaces > PluggableTextMorph allSubInstances do: [ :each | each > hasUnacceptedEdits: false; > askBeforeDiscardingEdits: false; > myDependents: nil ] > > cleanupSystemWindows > [ [ SystemWindow allSubInstances do: [ :window | > window > makeClosable; > delete ] ] > on: Error > do: [ :ex | > "may get here because we're trying to delete a window which has been deleted already." > ex return ]. > Smalltalk garbageCollect. > "already deleted but still hanging aroung (also see #cleanupEvents and #cleanupWorkspaces)" > SystemWindow allSubInstances > select: [ :e | e model isNil and: [ e owner isNil ] ] > thenDo: [ :e | > "clean some known places where references can prevent GC" > UITheme current focusIndicator: nil. > ActiveHand mouseOverHandler initialize. > ActiveHand keyboardFocus: nil. > World cleanseStepList. > "e.g. Workspace has a dependents array wich can point to the window" > (PointerFinder pointersTo: e) do: [ :p | > p class = DependentsArray ifTrue: [ > "the first pointer is the 'main' pointer in about 99% of the cases" > (PointerFinder pointersTo: p) first removeDependent: e ] ] ] > ] on: Error do: [ "ignoreâ ] > > > On 21.06.2014, at 23:11, Max Leske <maxleske(a)gmail.com> wrote: > >> Found the problem, documenting it here in case anybody else ever needs this (remember, this is 1.1.1). >> >> Open a debugger (e.g. by evaluating 1/0), then click into the lower right workspace and type something. OCompletion will now have added an entry to the EventManager actionMap with a ContextVariablesInspector instance as the key. There seems to be a cycle there that canât be resolved by the garbage collector, since I wasnât able to find any non weak global pointers (an OContext is referenced by an MessageSend in the action map. The OContext references a morph which is connected to the SystemWindow. Some of those morphs reference the ContextVariablesInspector as their model). >> Anyhow, it should be safe to send EventManager>>cleanUp: with argument true (actionMaps and their contents get recreated on demand), which will release those entries and allow the garbage collector to collect the SystemWindows, other morphs and the Debugger instances. >> >> Note that this is probably not an issue in later versions (e.g. 3.0 doesnât include EventManager anymore) but it might be relevant for later 1.x versions. >> >> Max >> >> >> On 21.06.2014, at 20:44, Max Leske <maxleske(a)gmail.com> wrote: >> >>> >>> On 21.06.2014, at 18:53, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>>> >>>> On 21 Jun 2014, at 17:36, kilon alios <kilon.alios(a)gmail.com> wrote: >>>> >>>>> First off: >>>>> <rant>why do we have an IRC channel if nobody seems to be listening??</rant> >>>>> >>>>> too small community for an irc channel. My experience with irc is that 90-99% of people logged in at least are idle. For its size #pharo is quite active actually. >>>>> >>>> >>>> I am IRC when at work (and not forgetting to start the IRC client). But often when people ask questions it is exactly the wrong moment in time. >>>> I just *canât* instantly drop what I am doing an tend to the IRC channelâ¦ I really wonder how people do itâ¦ do they really stop their work right in the >>>> miiddle to answer questions? How are they productive? >>> >>> I fully agree. I was just momentarily pissed off :) >>> >>>> >>>> Marcus >>>> >>> >> >

June 24, 2014

Re: [Pharo-dev] SystemWindow instances can't be garbage-collected

by Max Leske

For documentation purposes, this is what I found to be necessary to really clean all window instances. Note that this only works reliably when invoked from a non-UI process (e.g. via WAKom). cleanupWindows "in general: the gabage collector seems to be unable to resolve all circular dependencies with weak pointers. This forces us to explicitly remove the weak pointers to enable garbage colltection. It also seems to be a problem to invoke the cleanup from within a UI process (e.g. from a workspace). Ergo: - when invoked from a workspace not all instances may be garbage collected - when invoked from a non UI process (e.g. WAKom) all instances should have been collected - performning a manual garbage collection after having invoked this code from a workspace will (usually) remove the pending instances (new process context)" | count | count := 1. self cleanupEvents; cleanupWorkspaces; cleanupSystemWindows. [ Smalltalk garbageCollect. count := count + 1 ] doWhileFalse: [ SystemWindow allSubInstances isEmpty or: [ count > 5 "arbitrary number" ] ] cleanupWorkspaces PluggableTextMorph allSubInstances do: [ :each | each hasUnacceptedEdits: false; askBeforeDiscardingEdits: false; myDependents: nil ] cleanupSystemWindows [ [ SystemWindow allSubInstances do: [ :window | window makeClosable; delete ] ] on: Error do: [ :ex | "may get here because we're trying to delete a window which has been deleted already." ex return ]. Smalltalk garbageCollect. "already deleted but still hanging aroung (also see #cleanupEvents and #cleanupWorkspaces)" SystemWindow allSubInstances select: [ :e | e model isNil and: [ e owner isNil ] ] thenDo: [ :e | "clean some known places where references can prevent GC" UITheme current focusIndicator: nil. ActiveHand mouseOverHandler initialize. ActiveHand keyboardFocus: nil. World cleanseStepList. "e.g. Workspace has a dependents array wich can point to the window" (PointerFinder pointersTo: e) do: [ :p | p class = DependentsArray ifTrue: [ "the first pointer is the 'main' pointer in about 99% of the cases" (PointerFinder pointersTo: p) first removeDependent: e ] ] ] ] on: Error do: [ "ignoreâ ] On 21.06.2014, at 23:11, Max Leske <maxleske(a)gmail.com> wrote: > Found the problem, documenting it here in case anybody else ever needs this (remember, this is 1.1.1). > > Open a debugger (e.g. by evaluating 1/0), then click into the lower right workspace and type something. OCompletion will now have added an entry to the EventManager actionMap with a ContextVariablesInspector instance as the key. There seems to be a cycle there that canât be resolved by the garbage collector, since I wasnât able to find any non weak global pointers (an OContext is referenced by an MessageSend in the action map. The OContext references a morph which is connected to the SystemWindow. Some of those morphs reference the ContextVariablesInspector as their model). > Anyhow, it should be safe to send EventManager>>cleanUp: with argument true (actionMaps and their contents get recreated on demand), which will release those entries and allow the garbage collector to collect the SystemWindows, other morphs and the Debugger instances. > > Note that this is probably not an issue in later versions (e.g. 3.0 doesnât include EventManager anymore) but it might be relevant for later 1.x versions. > > Max > > > On 21.06.2014, at 20:44, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 21.06.2014, at 18:53, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> >>> On 21 Jun 2014, at 17:36, kilon alios <kilon.alios(a)gmail.com> wrote: >>> >>>> First off: >>>> <rant>why do we have an IRC channel if nobody seems to be listening??</rant> >>>> >>>> too small community for an irc channel. My experience with irc is that 90-99% of people logged in at least are idle. For its size #pharo is quite active actually. >>>> >>> >>> I am IRC when at work (and not forgetting to start the IRC client). But often when people ask questions it is exactly the wrong moment in time. >>> I just *canât* instantly drop what I am doing an tend to the IRC channelâ¦ I really wonder how people do itâ¦ do they really stop their work right in the >>> miiddle to answer questions? How are they productive? >> >> I fully agree. I was just momentarily pissed off :) >> >>> >>> Marcus >>> >> >

June 24, 2014

Re: [Pharo-dev] Handling keyboard eventsâ¦

by Yuriy Tymchuk

Wow, thanks, Guillermo, itâs working. Uko On 24 Jun 2014, at 12:49, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Actually in latest Pharo keyboard events are extended to get the pressed key: > > key > ^Smalltalk os keyForValue: keyValue > > I tested it in windows, mac and unix some time ago and it used to work :) > > On Tue, Jun 24, 2014 at 10:18 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > On Tue, Jun 24, 2014 at 10:07 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi everyone, > > sorry, if Iâm annoying with this question, but is there a way to handle keyboard events (on mac) in a normal way? Because keyUp and keyDown do not have any information about the key itself. I know that itâs a long story also related with vm but maybe someone made some hacks to solve this problem? > > Cheers > Uko > > The logic is in sqSqueakOSXApplication+events.m > > Now, I do not have the latest version but it is true that keyUp and keyDown are not handled very nicely there. > > KeyDown doesn't seem to have any code (but one could set something there as the code is available). KeyUp has something. > > I do not know why things are done this way. There may be side effects in the VM if one changes the way things are... > > Good luck. > > (void) recordCharEvent:(NSString *) unicodeString fromView: (NSView<sqSqueakOSXView> *) mainView { > sqKeyboardEvent evt; > unichar unicode; > unsigned char macRomanCharacter; > NSInteger i; > NSRange picker; > NSUInteger totaLength; > > evt.type = EventTypeKeyboard; > evt.timeStamp = (int) ioMSecs(); > picker.location = 0; > picker.length = 1; > totaLength = [unicodeString length]; > for (i=0;i < totaLength;i++) { > > > unicode = [unicodeString characterAtIndex: i]; > > if ([mainView lastSeenKeyBoardStrokeDetails]) { > evt.modifiers = [self translateCocoaModifiersToSqueakModifiers: [[mainView lastSeenKeyBoardStrokeDetails] modifierFlags]]; > evt.charCode = [[mainView lastSeenKeyBoardStrokeDetails] keyCode]; > } else { > evt.modifiers = 0; > evt.charCode = 0; > } > > if ((evt.modifiers & CommandKeyBit) && (evt.modifiers & ShiftKeyBit)) { /* command and shift */ > if ((unicode >= 97) && (unicode <= 122)) { > /* convert ascii code of command-shift-letter to upper case */ > unicode = unicode - 32; > } > } > > NSString *lookupString = [[NSString alloc] initWithCharacters: &unicode length: 1]; > [lookupString getBytes: &macRomanCharacter maxLength: 1 usedLength: NULL encoding: NSMacOSRomanStringEncoding > options: 0 range: picker remainingRange: NULL]; > [lookupString release]; > > evt.pressCode = EventKeyDown; > unsigned short keyCodeRemembered = evt.charCode; > evt.utf32Code = 0; > evt.reserved1 = 0; > evt.windowIndex = (int)[[mainView windowLogic] windowIndex]; > [self pushEventToQueue: (sqInputEvent *)&evt]; > > evt.charCode = macRomanCharacter; > evt.pressCode = EventKeyChar; > evt.modifiers = evt.modifiers; > evt.utf32Code = unicode; > > [self pushEventToQueue: (sqInputEvent *) &evt]; > > if (i > 1 || ![mainView lastSeenKeyBoardStrokeDetails]) { > evt.pressCode = EventKeyUp; > evt.charCode = keyCodeRemembered; > evt.utf32Code = 0; > [self pushEventToQueue: (sqInputEvent *) &evt]; > } > } > > interpreterProxy->signalSemaphoreWithIndex(gDelegateApp.squeakApplication.inputSemaphoreIndex); > > } > > --Phil > >

June 24, 2014

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

by Esteban Lorenzano

On 24 Jun 2014, at 09:58, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Hi Stef, > > 2014-06-24 3:18 GMT-03:00 stepharo <stepharo(a)free.fr>: >> Esteban >> >> I would like to know how different are the Glorp proxies from the ones of >> Mariano. >> Because we are thinking about to get by default a nice proxy system. >> Proxies in the sense of object representing one that is not in the system >> (and not proxies >> as metaobject or representing an object that is around as in the JS >> literature). Ideally I would like >> to unify both. > > There's nothing much special about GLORP proxies, and maybe Mariano > knows better. > They have a common superclass named "AbstractProxy" (no NS), and they > work more like "remote references" than anything else. > > They are true proxies, it is, they hold a reference to the realobject, > but no #become is involved in the process. > Also proxies can "release" the referenced object and materialize it > back when needed (according to the proxy strategy). > > Proxy>>#class returns Proxy, but Proxy>>#isKindOf: aClass returns > whether the referenced class is aClass (it is, aProxy isKindOf: Proxy > "false"), #= and #hash causes materialization of the referenced > object. > > Other than that I couldn't find anything else, it's a classical proxy, > with some ORM related stuff. yeah, thatâs why I said is not a problem of GLORP proxies but about our treatment of proxies in general :) Esteban > > Regards! >

June 24, 2014

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

by Esteban A. Maringolo

Hi Stef, 2014-06-24 3:18 GMT-03:00 stepharo <stepharo(a)free.fr>: > Esteban > > I would like to know how different are the Glorp proxies from the ones of > Mariano. > Because we are thinking about to get by default a nice proxy system. > Proxies in the sense of object representing one that is not in the system > (and not proxies > as metaobject or representing an object that is around as in the JS > literature). Ideally I would like > to unify both. There's nothing much special about GLORP proxies, and maybe Mariano knows better. They have a common superclass named "AbstractProxy" (no NS), and they work more like "remote references" than anything else. They are true proxies, it is, they hold a reference to the realobject, but no #become is involved in the process. Also proxies can "release" the referenced object and materialize it back when needed (according to the proxy strategy). Proxy>>#class returns Proxy, but Proxy>>#isKindOf: aClass returns whether the referenced class is aClass (it is, aProxy isKindOf: Proxy "false"), #= and #hash causes materialization of the referenced object. Other than that I couldn't find anything else, it's a classical proxy, with some ORM related stuff. Regards!

June 24, 2014

Re: [Pharo-dev] Handling keyboard eventsâ¦

by Guillermo Polito

Actually in latest Pharo keyboard events are extended to get the pressed key: key ^Smalltalk os keyForValue: keyValue I tested it in windows, mac and unix some time ago and it used to work :) On Tue, Jun 24, 2014 at 10:18 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > On Tue, Jun 24, 2014 at 10:07 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > wrote: > >> Hi everyone, >> >> sorry, if Iâm annoying with this question, but is there a way to handle >> keyboard events (on mac) in a normal way? Because keyUp and keyDown do not >> have any information about the key itself. I know that itâs a long story >> also related with vm but maybe someone made some hacks to solve this >> problem? >> >> Cheers >> Uko >> > > The logic is in sqSqueakOSXApplication+events.m > > Now, I do not have the latest version but it is true that keyUp and > keyDown are not handled very nicely there. > > KeyDown doesn't seem to have any code (but one could set something there > as the code is available). KeyUp has something. > > I do not know why things are done this way. There may be side effects in > the VM if one changes the way things are... > > Good luck. > > (void) recordCharEvent:(NSString *) unicodeString fromView: > (NSView<sqSqueakOSXView> *) mainView { > sqKeyboardEvent evt; > unichar unicode; > unsigned char macRomanCharacter; > NSInteger i; > NSRange picker; > NSUInteger totaLength; > evt.type = EventTypeKeyboard; > evt.timeStamp = (int) ioMSecs(); > picker.location = 0; > picker.length = 1; > totaLength = [unicodeString length]; > for (i=0;i < totaLength;i++) { > unicode = [unicodeString characterAtIndex: i]; > if ([mainView lastSeenKeyBoardStrokeDetails]) { > evt.modifiers = [self translateCocoaModifiersToSqueakModifiers: [[mainView > lastSeenKeyBoardStrokeDetails] modifierFlags]]; > evt.charCode = [[mainView lastSeenKeyBoardStrokeDetails] keyCode]; > } else { > evt.modifiers = 0; > evt.charCode = 0; > } > if ((evt.modifiers & CommandKeyBit) && (evt.modifiers & ShiftKeyBit)) { > /* command and shift */ > if ((unicode >= 97) && (unicode <= 122)) { > /* convert ascii code of command-shift-letter to upper case */ > unicode = unicode - 32; > } > } > NSString *lookupString = [[NSString alloc] initWithCharacters: &unicode > length: 1]; > [lookupString getBytes: &macRomanCharacter maxLength: 1 usedLength: NULL > encoding: NSMacOSRomanStringEncoding > options: 0 range: picker remainingRange: NULL]; > [lookupString release]; > evt.pressCode = EventKeyDown; > unsigned short keyCodeRemembered = evt.charCode; > evt.utf32Code = 0; > evt.reserved1 = 0; > evt.windowIndex = (int)[[mainView windowLogic] windowIndex]; > [self pushEventToQueue: (sqInputEvent *)&evt]; > evt.charCode = macRomanCharacter; > evt.pressCode = EventKeyChar; > evt.modifiers = evt.modifiers; > evt.utf32Code = unicode; > [self pushEventToQueue: (sqInputEvent *) &evt]; > if (i > 1 || ![mainView lastSeenKeyBoardStrokeDetails]) { > evt.pressCode = EventKeyUp; > evt.charCode = keyCodeRemembered; > evt.utf32Code = 0; > [self pushEventToQueue: (sqInputEvent *) &evt]; > } > } > > interpreterProxy->signalSemaphoreWithIndex(gDelegateApp.squeakApplication.inputSemaphoreIndex); > > } > > --Phil > >

June 24, 2014

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

by Norbert Hartl

Am 24.06.2014 um 08:19 schrieb stepharo <stepharo(a)free.fr>: > >> 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? > > We will check that :) > Marcus already integrated it. Thanks! norbert >> >> 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 24, 2014

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

by stepharo

On 24/6/14 08:19, stepharo 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? > > We will check that :) > >> >> Norbert >> >> Am 23.06.2014 um 23:55 schrieb Norbert Hartl <norbert(a)hartl.name >> <mailto:norbert@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 >>> <mailto:stepharo@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 <mailto:eliot.miranda@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 <mailto:norbert@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 24, 2014

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

by stepharo

On 24/6/14 08:18, stepharo wrote: > Esteban > > I would like to know how different are the Glorp proxies from the ones > of Mariano. > Because we are thinking about to get by default a nice proxy system. > Proxies in the sense of object representing one that is not in the > system (and not proxies > as metaobject or representing an object that is around as in the JS > literature). Ideally I would like > to unify both. > > Stef > > On 23/6/14 20:45, Esteban A. Maringolo wrote: >> Eliot, >> >> 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. >> >> Your proposal: >> classVariableNames: 'MaxLengthForASingleDebugLogReport >> MaxStackDepthForASingleDebugLogReport PrimitiveFailToken QuickStep >> ValueIndex' >> >> Current vars: >> classVariableNames: 'PrimitiveFailToken QuickStep >> SpecialPrimitiveSimulators TryNamedPrimitiveTemplateMethod' >> >> Would you mind adapting your mirror methods changes to work also in >> Pharo 3 (and maybe in Pharo 4 too?). >> >> Esteban A. Maringolo >> >> >> 2014-02-26 14:40 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>> Hi Esteban, >>> >>> find attached. Let me know of any problems. >>> >>> >>> On Wed, Feb 26, 2014 at 8:32 AM, Esteban A. Maringolo >>> <emaringolo(a)gmail.com> >>> wrote: >>>> Hi Eliot, >>>> >>>> >>>> 2013-11-30 18:30 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>>> On Fri, Nov 29, 2013 at 2:22 PM, Esteban A. Maringolo >>>>> <emaringolo(a)gmail.com> >>>>> wrote: >>>>>> 2013/11/29 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>>>>> I'll either prepare a change set or submit. It'll get done. >>>>>> I can continue stepping into until the change is ready. >>>>>> Please make it compatible with Pharo 2 (whatever that means in >>>>>> term of >>>>>> code) :) >>>>> >>>>> OK, the code is now in Squeak trunk. What image should I use to >>>>> integrate >>>>> into Pharo 2? A url please... >>>> I'm coming back late to this. Because the change wasn't integrated in >>>> Pharo 2. >>>> >>>> Do you have the changeset applied to Squeak Trunk? I'd like to reapply >>>> it in my Pharo 2 image (at my own risk). >>>> Can you send it to may email address? >>>> >>>> Thank you! >>>> >>>> Esteban A. Maringolo >>>> >>> >>> >>> -- >>> best, >>> Eliot >> >

June 24, 2014