- Pharo-dev - lists.pharo.org

[Pharo-project] OSProcess error in 1.3

by Sean P. DeNigris

With the latest OSProcess package from SqS, when I save the image, I get: 2 May 2012 1:20:30 am VM: Mac OS - intel - 1073 - Croquet Closure Cog VM [CoInterpreter VMMaker-oscog-EstebanLorenzano.155] 21.0 Image: Pharo1.3 [Latest update: #13320] UndefinedObject(Object)>>doesNotUnderstand: #wait Receiver: nil Arguments and temporary variables: aMessage: wait exception: MessageNotUnderstood: receiver of "wait" is nil resumeValue: nil Receiver's instance variables: nil [[event wait. processSynchronizationDelay wait. self changed: #childProcessStatus] repeat. nil] in UnixOSProcessAccessor>>grimReaperProcess Receiver: a UnixOSProcessAccessor on pid 22740 Arguments and temporary variables: event: nil processSynchronizationDelay: a Delay(20 msecs) Receiver's instance variables: dependents: a DependentsArray(a UnixProcess with pid 22740) sessionIdentifier: #[104 195 160 79] canObtainSessionIdentifierFromPlugin: true hasTestEof: nil grimReaper: a Process in MorphicUIManager>>openDebuggerOn:context:label:content...etc... sigChldSemaphore: nil Weird... -- View this message in context: http://forum.world.st/OSProcess-error-in-1-3-tp4602389.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 2, 2012

[Pharo-project] Nautilus shows different code than rest of system

by Sean P. DeNigris

I know someone mentioned this before, but I can't find the thread. I accepted method code in Nautilus. The little orange triangle disappeared, the new code even showed when I navigated away and came back to the method. But the system was still using the old version of the method, as proved by both failing tests, and that the old code was shown in other tools, like the implementors. I don't know how to reproduce it, but it's a really nasty bug!! Pharo1.4 Latest update: #14439 Nautilus installed via: Gofer it url: 'http://ss3.gemstone.com/ss/Nautilus'; package: 'ConfigurationOfNautilus'; load. (Smalltalk at: #ConfigurationOfNautilus) perform: #loadRelease Sean p.s. I tried to piece the details together as accurately as possible, but I was playing with this image for a while before I figured out what was going on, so some details (e.g. how Nautilus was installed may not be 100%) -- View this message in context: http://forum.world.st/Nautilus-shows-different-code-than-rest-of-system-tp4… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 2, 2012

Re: [Pharo-project] Nautilus question

by Francisco Garau

This one is with a Darker Blue which looks quite acceptable to me.. On 30 April 2012 20:07, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com>wrote: > With blue, it render like that: > > For me it looks strange, but it's probably because I am used to the bold > version :) > > By the way, a setting is a good thing :) > > > Ben > > On Apr 30, 2012, at 8:59 PM, Mariano Martinez Peck wrote: > > I also think bold is too much ;) > (sorry for not suggesting anything better) > > On Mon, Apr 30, 2012 at 7:03 PM, Francisco Garau < > francisco.garau(a)gmail.com> wrote: > >> It is showing the class side methods in bold. Is that intentional? >> >> Can we change it to something else? Blue, maybe -- but not bold! Is hard >> to read... >> >> - Francisco >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > >

May 2, 2012

Re: [Pharo-project] [newbies] How can I diagnose kinetic scrolling screen flicker?

by Chris Muller

Ensuring your drawOn: is fast is crucial for good frame-rate. Try profiling all processes, that should reveal something.. On Tue, May 1, 2012 at 6:24 AM, Martin Drautzburg <Martin.Drautzburg(a)web.de> wrote: > Hello all, > > in my (first) pharo programm, I have a pane with apx 100 Morphs. The pane can > be zoomed and scrolled Â both vertically and horizontally. The horizontal > scrolling means scrolling time and is self-written. I implemented some sort of > kinetic scrolling using the mouse wheel, where a scroll destination is set and > in a step method I halve the distance to the destination with each step. > > This looks kind of nice, but not nice enough. Scrolling is not as smooth as I > had hoped. Sometimes there is a delay between the wheel move and the display > actually showing some motion. Also I have the impression, that not all parts > of the pane are redrawn at the same time. Morphs which are exactly below each > other, appear minimally skewed during the scroll. > > Strange enough the zooming, which has to do about the same underlying geometry > calculations is a lot more snappy (but not kinetic). Likewise the vertical > scrolling which used a StandardScrollPane appears Â more snappy. > > I looks like using a stepper is the root of the problem. I just could not > figure out where the time goes. I put a MessageTally into the step method, > only to find out, that doing 1000 steps takes less than a second. So the > problem must be elsewehere. > > Any ideas would be much appreciated. > > > -- > Martin >

May 1, 2012

Re: [Pharo-project] [Vm-dev] Re: [squeak-dev] Re: problem with tempNamed: in Pharo 2.0

by Eliot Miranda

On Tue, May 1, 2012 at 1:53 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > > >>> >>>> But tempNames is fundamentally broken for closures. >>>> >>> >>> Just to avoid confusing, #tempNames itself looks correct: >>> >>> tempNames >>> "Answer a SequenceableCollection of the names of the receiver's >>> temporary >>> variables, which are strings." >>> >>> ^ self debuggerMap tempNamesForContext: self >>> >> >> Yes. That's for ContextPart. But it doesn't work for CompiledMethod, >> since temps may differ between a method and its blocks. >> >> > > Right, but weren't we always talking about Contexts? Because #tempNames > of CompiledMethod is different than the thing of contexts, isn't it? It is > related to the method trailer. In fact, I have just checked Squeak 4.3 and > CompiledMethod does not even implement #tempNames. The implementation in > Pharo is: > > CompiledMethod >> #tempNames > self holdsTempNames ifFalse: [^#()]. > ^self tempNamesString subStrings: ' ' > > how would it be the correct implementation then? > I don't think there is one. Perhaps answering a set of all temp names, but that's not very useful. > > Thanks > > -- > Mariano > http://marianopeck.wordpress.com > > > > > -- best, Eliot

May 1, 2012

[Pharo-project] browsing versions of a method

by Francisco Garau

Hi - I've noticed we have a new way of showing diffs between two versions of a method. Very nice! But it would be more useful if the user had the choice of which two versions to compare. For example, if I maje 10 changes to method Date>>today I would like to compare my first and last versions... Cheers, Francisco

May 1, 2012

Re: [Pharo-project] Method Wrappers and the Debugger

by Sean P. DeNigris

Sean P. DeNigris wrote > > I'm going to take a look at the other MethodWrapper implementation, which > I think creates CompiledMethods, so maybe that will fare better... > Indeed, the MethodWrappers on SqS (see http://forum.world.st/MethodWrappers-td3829576.html#a4601624) allows one to step over the wrapper in the debugger. Stepping in fails, but I expected that, and it's not so important to simulate the stub in the debugger... Sean -- View this message in context: http://forum.world.st/Method-Wrappers-and-the-Debugger-tp4601773p4601880.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 1, 2012

[Pharo-project] Method Wrappers and the Debugger

by Sean P. DeNigris

I'm writing a test double library similar to Ruby's rspec. The first signs of life can be downloaded via: Gofer new squeaksource: 'BDDExtensions'; package: 'Mock'; load. One of the features is to partially stub a class, so one could have e.g. DateAndTime>>#now return a canned value. It's easy enough to implement, but the wheels fall off in the debugger, where the VM quits and leaves no log on the last line of the following snippet. In a workspace, I just get a DNU, described in the comment: startTime := DateAndTime now. DateAndTime stub: #now andReturn: startTime. "DoIt this last line... works great. Debug this last line... DateAndTime class(Object)>>doesNotUnderstand: 224@116. It originally ran into Object>>at: error not indexable until I implemented at: and forwarded it to the original CompiledMethod" DateAndTime now. The ObjectAsMethodWrapper approach has a similar limitation: wrapper := ObjectAsMethodWrapper installOn: DateAndTime class selector: #now. "Debugging this line leads to 'Error: Instances of ObjectAsMethodWrapper are not indexable'" DateAndTime now. I'm going to take a look at the other MethodWrapper implementation, which I think creates CompiledMethods, so maybe that will fare better... Any other ideas? Thanks. Sean -- View this message in context: http://forum.world.st/Method-Wrappers-and-the-Debugger-tp4601773.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 1, 2012

Re: [Pharo-project] [Vm-dev] Re: [squeak-dev] Re: problem with tempNamed: in Pharo 2.0

by Mariano Martinez Peck

> >> >>> But tempNames is fundamentally broken for closures. >>> >> >> Just to avoid confusing, #tempNames itself looks correct: >> >> tempNames >> "Answer a SequenceableCollection of the names of the receiver's >> temporary >> variables, which are strings." >> >> ^ self debuggerMap tempNamesForContext: self >> > > Yes. That's for ContextPart. But it doesn't work for CompiledMethod, > since temps may differ between a method and its blocks. > > Right, but weren't we always talking about Contexts? Because #tempNames of CompiledMethod is different than the thing of contexts, isn't it? It is related to the method trailer. In fact, I have just checked Squeak 4.3 and CompiledMethod does not even implement #tempNames. The implementation in Pharo is: CompiledMethod >> #tempNames self holdsTempNames ifFalse: [^#()]. ^self tempNamesString subStrings: ' ' how would it be the correct implementation then? Thanks -- Mariano http://marianopeck.wordpress.com

May 1, 2012

Re: [Pharo-project] [Vm-dev] Re: [squeak-dev] Re: problem with tempNamed: in Pharo 2.0

by Eliot Miranda

On Tue, May 1, 2012 at 1:12 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > > > > On Tue, May 1, 2012 at 9:29 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> >> >> On Tue, May 1, 2012 at 9:13 AM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> >>> >>> On Tue, May 1, 2012 at 6:09 PM, Mariano Martinez Peck < >>> marianopeck(a)gmail.com> wrote: >>> >>>> Hi guys. I noticed stef did this issue: >>>> http://code.google.com/p/pharo/issues/detail?id=5642 >>>> However, now I have the following test that fails in Pharo 2.0 but >>>> works fine in 1.4: >>>> >>>> | string context | >>>> string := 'test'. >>>> context := [self class. string asUppercase] asContext. >>>> self assert: (context tempNamed: 'string') = 'test' >>>> >>>> the current implementation of #tempNamed: is: >>>> >>>> tempNamed: aName >>>> "Returns the value of the temporaries, aName." >>>> "Implementation notes: temporary initialization in blocks simply >>>> uses pushNil to allocate and initialize each temp. So if one inspects >>>> [|a|a:=2] and sends it self method symbolic you get: >>>> >>>> 13 <8F 00 00 05> closureNumCopied: 0 numArgs: 0 bytes 17 to 21 >>>> 17 <73> pushConstant: nil >>>> 18 <77> pushConstant: 2 >>>> 19 <81 40> storeIntoTemp: 0 >>>> 21 <7D> blockReturn >>>> 22 <7C> returnTop >>>> >>>> And when we check self asContext pc we get 17, which is *before* >>>> the nil is pushed. Therefore we should pay attention when querying a >>>> temporary if the temporary allocation was executed." >>>> >>>> | index | >>>> index := (self tempNames indexOf: aName). >>>> ^ index >= stackp >>>> >>> >>> >>> Maybe the solution is to use #> rather than #>= ? >>> >> >> right. >> > > Ok, so I will integrate that as a first version. > > >> But tempNames is fundamentally broken for closures. >> > > Just to avoid confusing, #tempNames itself looks correct: > > tempNames > "Answer a SequenceableCollection of the names of the receiver's > temporary > variables, which are strings." > > ^ self debuggerMap tempNamesForContext: self > Yes. That's for ContextPart. But it doesn't work for CompiledMethod, since temps may differ between a method and its blocks. > > >> It does not answer temps in indirection vectors. That is the whole point >> of schematicTempNamesString; it gives the topology of temps in a method. >> e.g. (where => means printIt returns...) >> >> (Collection>>#inject:into:) methodNode schematicTempNamesString => >> 'thisValue binaryBlock (nextValue)[each binaryBlock (nextValue)]' >> >> This says that >> a) at method level there are three temps, thisValue, binaryBlock and an >> indirection vector, and in the indirection vector is one temp named >> nextValue. >> b) in the block in inject:into: there are three temps, each (the >> argument), binaryBlock and an indirection vector, and in that indirection >> vector is a temp named nextValue. >> >> This is all orchestrated by DebuggerMethodMap, so that >> >> aContext method debuggerMap tempNamesForContext: aContext >> > > So #tempNames implementation is correct? > Yes. > > >> >> answers a list of the flattened temp names in a context (flattening out >> indirection vectors) and for the above would answer either #('thisValue' >> 'binaryBlock' 'nextValue') or #('each' 'binaryBlock' 'nextValue'), and >> >> | map | >> map := aContext method debuggerMap. >> map namedTempAt: ((map tempNamesForContext: aContext) indexOf: >> aTempName) in: aContext >> >> gets the temp from the unflattened temps in a context. This is how the >> debugger accesses temp names. >> >> So you need to throw away the broken tempName: implementation and use >> DebuggerMethodMap or some parse over schematicTempNamesString, because >> *with closures temps are not simply at contiguous offsets on the stack*. >> Make sense? >> > > Actually, we do have: > > namedTempAt: index > "Answer the value of the temp at index in the receiver's sequence of > tempNames." > ^self debuggerMap namedTempAt: index in: self > > and > > namedTempAt: index put: aValue > "Set the value of the temp at index in the receiver's sequence of > tempNames. > (Note that if the value is a copied value it is also set out along > the lexical chain, > but alas not in along the lexical chain.)." > ^self debuggerMap namedTempAt: index put: aValue in: self > > so, if I understand correctly all we need to do is to fix tempNamed: and > tempNamedPut: so that the delegate to namedTempAt: and namedTempPut: rather > than to tempAt: and tempAtPut: ? > Yes. Now, one good way to understand this is through examples. inject:into: is >> the canonical simple example I've used for years. But we can find more >> complex examples that may help. So this query looks for all methods that >> contain a bytecode to create an indirection vector with 2 or more elements: >> >> SystemNavigation new browseAllSelect: >> [:m| | is | >> is := InstructionStream on: m. >> is scanFor: [:b| b = 138 and: [is followingByte between: 2 and: 127]]] >> >> and the simplest example in a trunk 4.3 image I find is: >> >> Bag>>sum >> "Faster than the superclass implementation when you hold many instances >> of the same value (which you probably do, otherwise you wouldn't be using a >> Bag)." >> | sum first | >> first := true. >> contents keysAndValuesDo: [ :value :count | >> first >> ifTrue: [ sum := value * count. first := false ] >> ifFalse: [ sum := sum + (value * count) ] ]. >> first ifTrue: [ self errorEmptyCollection ]. >> ^sum >> >> which needs a two-element indirection vector because the block [ :value >> :count |...] assigns to both sum and first. Hence >> >> (Bag>>#sum) methodNode schematicTempNamesString => '(sum >> first)[value count (sum first)]' >> >> So in an activation of Bag>>sum the value of first is (sumContext tempAt: >> 1) at: 2 (cuz tempAt: 1 is the indirection vector represented as (sum >> first) in schematic temps, and first is the second element. But in an >> activation of the block in Bag>>sum the value of first is (sumBlockContext >> tempAt: 3) at: 2. >> >> >> I can keep repeating myself until I'm blue in the face, but y'all have to >> put in the effort to understand this simple scheme. Temps that are >> modified after they are closed-over end up in indirection vectors. >> >> > > Thanks, I am trying to undersand and fix it :) > > >> >>> >>> >>>> ifTrue: [ nil] >>>> ifFalse: [self tempAt: (self tempNames indexOf: aName)] >>>> >>>> >>>> and previously it was: >>>> >>>> tempNamed: aName >>>> ^self tempAt: (self tempNames indexOf: aName) >>>> >>>> >>>> ideas? >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> -- >> best, >> Eliot >> > -- > Mariano > http://marianopeck.wordpress.com -- best, Eliot

May 1, 2012