May 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] #nsWriteStream

by Damien Cassou

On Thu, Apr 26, 2012 at 10:31 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > From http://code.google.com/p/pharo/wiki/CodeSnippets : > Â Â MCWorkingCopy allManagers flatCollect: [:e | e repositoryGroup > repositories]. > -> error: Array DNU #nsWriteStream looks like the code has changed to use #asSet. #nsWriteStream creates a Nile stream and it doesn't work if Nile is not loaded. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

May 2, 2012

Re: [Pharo-project] browsing versions of a method

by Mariano Martinez Peck

On Wed, May 2, 2012 at 1:00 AM, Francisco Garau <francisco.garau(a)gmail.com>wrote: > Hi - I've noticed we have a new way of showing diffs between two versions > of a method. Very nice! yes, I did it with Ben in the sprint ;) > > But it would be more useful if the user had the choice of which two > versions to compare. > > You can right click a version and you have the option "Compare to current" and "compare to version..." The problem is that they have not been fixed with the nice diff so it opens an ugly popup diff. > For example, if I maje 10 changes to method Date>>today I would like to > compare my first and last versions... > > Cheers, > Francisco > -- Mariano http://marianopeck.wordpress.com

May 2, 2012

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

by Mariano Martinez Peck

> > >> 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 I was thinking, what happens with the rest of the senders of tempAt: and tempAtPut: ? do I need to do something with them? Thanks -- Mariano http://marianopeck.wordpress.com

May 2, 2012

[Pharo-project] [update 2.0] #20037

by Marcus Denker

20037 ----- Issue 5763: ProtoObject>>#~~ cleanup http://code.google.com/p/pharo/issues/detail?id=5763 Issue 5743: Cannot load editions of class side methods http://code.google.com/p/pharo/issues/detail?id=5743 Issue 2063: NumberTest http://code.google.com/p/pharo/issues/detail?id=2063 -- Marcus Denker -- http://marcusdenker.de

May 2, 2012

[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