- Pharo-dev - lists.pharo.org

[Pharo-project] Mac VM 5.7b3 (21.0) Beeper primitiveBeep does not beep anymore
by StÃ©phane Ducasse March 1, 2011

March 1, 2011

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

5 7

[Pharo-project] Issue 3691 in pharo: Cleaning by comparing SimpleMorphic and Morphic
by pharo＠googlecode.com March 1, 2011

March 1, 2011

Status: Accepted Owner: stephane...(a)gmail.com New issue 3691 by stephane...(a)gmail.com: Cleaning by comparing SimpleMorphic and Morphic http://code.google.com/p/pharo/issues/detail?id=3691 I did several cleans by comparing SimpleMorphic Canavs and FormCanvas Attachments: CanvasCleaning.2.cs 36.9 KB

1 5

[Pharo-project] Issue 3704 in pharo: remove FakeClassPool adopt: and its senders
by pharo＠googlecode.com March 1, 2011

March 1, 2011

Status: Accepted Owner: nicolas....(a)gmail.com Labels: Difficulty-Easy New issue 3704 by nicolas....(a)gmail.com: remove FakeClassPool adopt: and its senders http://code.google.com/p/pharo/issues/detail?id=3704 As developped on following link, this message is useless http://article.gmane.org/gmane.comp.lang.smalltalk.squeak.general/154929 The job is easy: if you see a sender of FakeClassPool adopt: then just remove it. This is part of a larger plan, remove FakeClassPool itself since it's sole use is to flash a TextEditor when self is returned from a nil doItReceiver. See also http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-February/157518… for a possible Comment Of The Day ;)

1 5

[Pharo-project] Issue 3737 in pharo: Behavior>>allSubclasses comment does not match actual implementation
by pharo＠googlecode.com March 1, 2011

March 1, 2011

Status: New Owner: ---- New issue 3737 by vonbecm...(a)gmail.com: Behavior>>allSubclasses comment does not match actual implementation http://code.google.com/p/pharo/issues/detail?id=3737 Pharo image: Pharo-core Pharo core version: Pharo1.2rc2 Latest update: #12324 Steps to reproduce: 1. Browse Class Behavior 2. select message allSubclasses 3. message's comment says "Answer a Set of the receiver's and the receiver's descendent's subclasses. " when actually it returns a OrderedCollection. Attachments: PharoScreenshot.1.png 138 KB

1 4

[Pharo-project] doing an update now...
by StÃ©phane Ducasse March 1, 2011

March 1, 2011

1 0

[Pharo-project] [COTDC] 21 - DictionaryInspector
by laurent laffont March 1, 2011

March 1, 2011

Today: DictionaryInspector Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent - Oups forgot it yesterday

3 3

[Pharo-project] Issue 3771 in pharo: avoid proposing a menu when nil is the doItReceiver of an interactive evaluation,
by pharo＠googlecode.com March 1, 2011

March 1, 2011

Status: FixedWaitingToBePharoed Owner: stephane...(a)gmail.com New issue 3771 by stephane...(a)gmail.com: avoid proposing a menu when nil is the doItReceiver of an interactive evaluation, http://code.google.com/p/pharo/issues/detail?id=3771 Name: Compiler-nice.187 Author: nice Time: 4 February 2011, 10:17:14.337 pm UUID: 71dd94ed-3fc7-49e0-b180-fb04be82bc29 Ancestors: Compiler-nice.184 In case nil is the doItReceiver of an interactive evaluation, avoid proposing a menu that would add an inst var to UndefinedObject. =============== Diff against Compiler-nice.184 =============== Item was added: + ----- Method: Parser>>canDeclareInstanceVariable (in category 'error correction') ----- + canDeclareInstanceVariable + ^encoder classEncoding ~~ UndefinedObject! Item was changed: ----- Method: UndeclaredVariable>>openMenuIn: (in category 'as yet unclassified') ----- openMenuIn: aBlock | alternatives labels actions lines caption choice | alternatives := parser possibleVariablesFor: name. labels := OrderedCollection new. actions := OrderedCollection new. lines := OrderedCollection new. name first isLowercase ifTrue: [labels add: 'declare method temp'. actions add: [parser declareTemp: name at: #method]. labels add: 'declare block-local temp'. actions add: [parser declareTemp: name at: #block]. + parser canDeclareClassVariable + ifTrue: + [labels add: 'declare instance'. + actions add: [parser declareInstVar: name]]] - labels add: 'declare instance'. - actions add: [parser declareInstVar: name]] ifFalse: [labels add: 'define new class'. actions add: [parser defineClass: name]. labels add: 'declare global'. actions add: [parser declareGlobal: name]. parser canDeclareClassVariable ifTrue: [labels add: 'declare class variable'. actions add: [parser declareClassVar: name]]]. lines add: labels size. alternatives do: [:each | labels add: each. actions add: [parser substituteVariable: each atInterval: interval]]. lines add: labels size. labels add: 'cancel'. caption := 'Unknown variable: ' , name , ' please correct, or cancel:'. choice := aBlock value: labels value: lines value: caption. self resume: (actions at: choice ifAbsent: [nil])!

1 0

[Pharo-project] Issue 3770 in pharo: Gradient fills failure
by pharo＠googlecode.com March 1, 2011

March 1, 2011

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.

1 0

[Pharo-project] [update 1.3] #13068
by stephane ducasse March 1, 2011

March 1, 2011

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

1 0

[Pharo-project] Issue 3648 in pharo: A "Stratified" proxy in smalltalk
by pharo＠googlecode.com March 1, 2011

March 1, 2011

Status: Started Owner: siguc...(a)gmail.com Labels: Type-RequestForEnhancement New issue 3648 by siguc...(a)gmail.com: A "Stratified" proxy in smalltalk http://code.google.com/p/pharo/issues/detail?id=3648 This is an implementation of A "Stratified" proxy in smalltalk. Note: The category/package name should be changed before integrating into image. Attachments: StratifiedProxy.st 5.5 KB StratifiedProxy-Tests.st 719 bytes

1 6