March 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3704 in pharo: remove FakeClassPool adopt: and its senders

by pharo＠googlecode.com

Comment #2 on issue 3704 by stephane...(a)gmail.com: remove FakeClassPool adopt: and its senders http://code.google.com/p/pharo/issues/detail?id=3704 Name: Morphic-nice.519 Author: nice Time: 14 February 2011, 10:22:53.154 pm UUID: d83915ed-3966-4301-9439-0f94337843b6 Ancestors: Morphic-mtf.518 Get rid of FakeClassPool adopt: RATIONALE: 1) this is useless A FakeClassPool instance is used only in case of a nil #doItReceiver, so it is always adopting nil and does not pass any pool of interest. 2) this is useless For a long time, the Compiler no longer needs a FakeClassPool instance in order to access the class and shared variables. Anyway, it was not a nice feature to use a global variable to pass states to the Compiler, was it ? =============== Diff against Morphic-mtf.518 =============== Item was changed: ----- Method: SmalltalkEditor>>tallySelection (in category 'do-its') ----- tallySelection "Treat the current selection as an expression; evaluate it and return the time took for this evaluation" | result rcvr ctxt valueAsString v | self lineSelectAndEmptyCheck: [^ -1]. (model respondsTo: #doItReceiver) + ifTrue: [ rcvr := model doItReceiver. - ifTrue: [FakeClassPool adopt: model selectedClass. "Include model pool vars if any" - rcvr := model doItReceiver. ctxt := model doItContext] ifFalse: [rcvr := ctxt := nil]. result := [ | cm | cm := rcvr class evaluatorClass new compiledMethodFor: self selectionAsStream in: ctxt to: rcvr notifying: self ifFail: [FakeClassPool adopt: nil. ^ #failedDoit] logged: false. Time millisecondsToRun: [v := cm valueWithReceiver: rcvr arguments: #() ]. ] on: OutOfScopeNotification do: [ :ex | ex resume: true]. - FakeClassPool adopt: nil. "We do not want to have large result displayed" valueAsString := v printString. (valueAsString size > 30) ifTrue: [valueAsString := (valueAsString copyFrom: 1 to: 30), '...']. PopUpMenu inform: 'Time to compile and execute: ', result printString, 'ms res: ', valueAsString. ! Item was changed: ----- Method: TextEditor>>debugIt (in category 'do-its') ----- debugIt | method receiver context | (model respondsTo: #doItReceiver) ifTrue: + [receiver := model doItReceiver. - [FakeClassPool adopt: model selectedClass. - receiver := model doItReceiver. context := model doItContext] ifFalse: [receiver := context := nil]. self lineSelectAndEmptyCheck: [^self]. method := self compileSelectionFor: receiver in: context. method notNil ifTrue: + [self debug: method receiver: receiver in: context].! - [self debug: method receiver: receiver in: context]. - FakeClassPool adopt: nil! Item was changed: ----- Method: TextEditor>>evaluateSelection (in category 'do-its') ----- evaluateSelection "Treat the current selection as an expression; evaluate it and return the result" | result rcvr ctxt | self lineSelectAndEmptyCheck: [^ '']. (model respondsTo: #doItReceiver) + ifTrue: [ rcvr := model doItReceiver. - ifTrue: [FakeClassPool adopt: model selectedClass. "Include model pool vars if any" - rcvr := model doItReceiver. ctxt := model doItContext] ifFalse: [rcvr := ctxt := nil]. result := [ rcvr class evaluatorClass new evaluate: self selectionAsStream in: ctxt to: rcvr notifying: self ifFail: [FakeClassPool adopt: nil. ^ #failedDoit] logged: true. ] on: OutOfScopeNotification do: [ :ex | ex resume: true]. - FakeClassPool adopt: nil. ^ result!

March 1, 2011

[Pharo-project] Issue 3770 in pharo: Gradient fills failure

by pharo＠googlecode.com

Status: Accepted Owner: siguc...(a)gmail.com New issue 3770 by siguc...(a)gmail.com: Gradient fills failure http://code.google.com/p/pharo/issues/detail?id=3770 Modifications to Morphic gradients fail in current versions of Squeak (and Pharo). Using the halo menu to change the first or last color of a morph doesn't work. Despite changes to these colors, the initial gradient remains. I've traced the problem to false hits in GradientFillStyle's LRUCache. LRUCache acts similar to a dictionary. It uses a key and it's hash to store and retrieve values. GradientFillStyle uses uses its colorRamp--a mutable array of associations--as the key to the cache, for instance: {0.0->Color white. 1.0->Color red}. Subsequent modifications to colorRamp also changes the key IN the cache. This can result in false hits. This fault has always been present. Recent changes to the hash calculation in Associations increased its frequency. Association hash has been simplified to return the key. As a result all gradients created from the user interface have the same hash. Since the the lookup == the key and the hashes are the same, false hits are inevitable. To illustrate the problem execute the script below. The first two changes are done using the classes colorRamp modification function. Rather than modifying, the last change replaces colorRamp with a new one. Clearly the first item in the pixelRamp should change when the first color changes. gradient := GradientFillStyle new colorRamp: {0.0->Color red. 1.0->Color white}. Transcript << 'first item for: '; << gradient colorRamp printString; space; << gradient pixelRamp first; cr; flush. gradient firstColor: Color green forMorph: nil hand: nil. Transcript << 'first item for: '; << gradient colorRamp printString; space; << gradient pixelRamp first; cr; flush. gradient firstColor: Color yellow forMorph: nil hand: nil. Transcript << 'first item for: '; << gradient colorRamp printString; space; << gradient pixelRamp first; cr; flush. Transcript show: 'Now replace with a new colorRamp'; cr. newRamp := gradient colorRamp deepCopy. newRamp first value: Color black. gradient colorRamp: newRamp. Transcript << 'first item for: '; << gradient colorRamp printString; space; << gradient pixelRamp first; cr; flush. Results: first item for: {0.0->Color red . 1.0->Color white} 4294901760 first item for: {0.0->Color green . 1.0->Color white} 4294901760 first item for: {0.0->Color yellow . 1.0->Color white} 4294901760 Now replace with a new colorRamp first item for: {0.0->Color black . 1.0->Color white} 4278190081 What's the best way to fix this? Handing out your internals seems ill advised. I think GradientFillStyle should pass a deepCopy of colorRamp to LRUCache. Another solution is for LRUCache to make a deepCopy itself. This would provide protection for all users of LRUCache...provided that deepCopy will always be sufficient. Glen -- View this message in context: http://forum.world.st/Gradient-Fills-Failures-tp3330016p3330016.html Sent from the Squeak - Dev mailing list archive at Nabble.com.

March 1, 2011

Re: [Pharo-project] Mac VM 5.7b3 (21.0) Beeper primitiveBeep does not beep anymore

by Esteban Lorenzano

yes... I just checked. I will collect all of this "absentees" to adding them as soon as possible. Please, keep reporting :) best, Esteban El 01/03/2011, a las 2:34p.m., Igor Stasenko escribiÃ³: > On 1 March 2011 18:18, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >> On Mar 1, 2011, at 4:49 39PM, StÃ©phane Ducasse wrote: >> >> Hi >> >> Could we have the primitiveBeep beeping again? >> What was the reason to disable it? >> >> Stef >> >> >> Prolly a missing prim in vm (surely the case if you do Beeper primitiveBeep >> and hear nothing), otherwise you have sound disabled. >> Can check that using: >> SoundService soundEnabled >> Btw, you changed >> DummySoundSystem class >> #initialize >> SoundService register: self. >> Why? >> This kinda breaks playing anything but beeps with the DummySoundSystem, as >> all the play.... methods are instance-side, as well as beeps played with the >> BaseSoundSystem loaded, as: >> Beeper >> #beep >> SoundService default new beep >> does not work anymore when the default is an instance as it used to be, and >> still is with BaseSoundSystem. >> Cheers, >> Henry >> >> > What i found is that ioBeep() for Objective-C VM variant is currently empty > > > -- > Best regards, > Igor Stasenko AKA sig. >

March 1, 2011

Re: [Pharo-project] Mac VM 5.7b3 (21.0) Beeper primitiveBeep does not beep anymore

by Igor Stasenko

On 1 March 2011 18:18, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Mar 1, 2011, at 4:49 39PM, StÃ©phane Ducasse wrote: > > Hi > > Could we have the primitiveBeep beeping again? > What was the reason to disable it? > > Stef > > > Prolly a missing prim in vm (surely the case if you do Beeper primitiveBeep > and hear nothing), otherwise you have sound disabled. > Can check that using: > SoundService soundEnabled > Btw, you changed > DummySoundSystem class >> #initialize > SoundService register: self. > Why? > This kinda breaks playing anything but beeps with the DummySoundSystem, as > all the play.... methods are instance-side, as well as beeps played with the > BaseSoundSystem loaded, as: > Beeper >> #beep > SoundService default new beep > does not work anymore when the default is an instance as it used to be, and > still is with BaseSoundSystem. > Cheers, > Henry > > What i found is that ioBeep() for Objective-C VM variant is currently empty -- Best regards, Igor Stasenko AKA sig.

March 1, 2011

Re: [Pharo-project] Mac VM 5.7b3 (21.0) Beeper primitiveBeep does not beep anymore

by Henrik Johansen

On Mar 1, 2011, at 4:49 39PM, StÃ©phane Ducasse wrote: > Hi > > Could we have the primitiveBeep beeping again? > What was the reason to disable it? > > Stef Prolly a missing prim in vm (surely the case if you do Beeper primitiveBeep and hear nothing), otherwise you have sound disabled. Can check that using: SoundService soundEnabled Btw, you changed DummySoundSystem class >> #initialize SoundService register: self. Why? This kinda breaks playing anything but beeps with the DummySoundSystem, as all the play.... methods are instance-side, as well as beeps played with the BaseSoundSystem loaded, as: Beeper >> #beep SoundService default new beep does not work anymore when the default is an instance as it used to be, and still is with BaseSoundSystem. Cheers, Henry

March 1, 2011

Re: [Pharo-project] Mac VM 5.7b3 (21.0) Beeper primitiveBeep does not beep anymore

by Mariano Martinez Peck

I works here in VM: Mac OS - intel - 1066 - Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.46] Croquet Cog 3.0.0 Image: Pharo1.2beta [Latest update: #12281] On Tue, Mar 1, 2011 at 4:49 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Hi > > Could we have the primitiveBeep beeping again? > What was the reason to disable it? > > Stef > >

March 1, 2011

[Pharo-project] Mac VM 5.7b3 (21.0) Beeper primitiveBeep does not beep anymore

by StÃ©phane Ducasse

Hi Could we have the primitiveBeep beeping again? What was the reason to disable it? Stef

March 1, 2011

Re: [Pharo-project] Issue 3737 in pharo: Behavior>>allSubclasses comment does not match actual implementation

by pharo＠googlecode.com

Comment #3 on issue 3737 by marianopeck: Behavior>>allSubclasses comment does not match actual implementation http://code.google.com/p/pharo/issues/detail?id=3737 nooo I wanted him to do it ;)

March 1, 2011

[Pharo-project] Issue 3769 in pharo: Printing an object depends on #isKindOf:

by pharo＠googlecode.com

Status: Accepted Owner: Benjamin...(a)gmail.com New issue 3769 by Benjamin...(a)gmail.com: Printing an object depends on #isKindOf: http://code.google.com/p/pharo/issues/detail?id=3769 Due to the method: SmalltalkEditor>>#printIt "Treat the current text selection as an expression; evaluate it. Insert the description of the result of evaluation after the selection and then make this description the new text selection." | result | result := self evaluateSelection. ((result isKindOf: FakeClassPool) or: [result == #failedDoit]) ifTrue: [morph flash] ifFalse: [self afterSelectionInsertAndSelect: result printString] So when trying to print an object which is an instance of a class which directly inherits from ProtoObject, it raises an error

March 1, 2011

[Pharo-project] [update 1.3] #13068

by stephane ducasse

13068 ----- Issue 3648: A "Stratified" proxy in smalltalk Stef

March 1, 2011