- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Is it possible to setup Russian fonts in Pharo + Cog VM?

by Eliot Miranda

On Mon, Feb 28, 2011 at 7:33 PM, Dennis Schetinin <chaetal(a)gmail.com> wrote: > AFAIK, Cog VM does not allow to use system fonts. What makes you think that? Cog should be the same as the standard VM. At Teleplace, for example, they use Cog with the NativeFontPlugin without problems. > But still, is there a way to install fonts (of any type) with support for > Russian symbols? â¦ Better without too much efforts like manually assigning > offsets for each character :) > What's the way to do this on the standard VM and how does this approach fail on the Cog VM? best, Eliot > -- > Dennis Schetinin >

March 1, 2011

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

by pharo＠googlecode.com

Comment #1 on issue 3769 by nicolas....(a)gmail.com: Printing an object depends on #isKindOf: http://code.google.com/p/pharo/issues/detail?id=3769 Anyway, you'll have to remove references to FakeClassPool. See #3704

March 1, 2011

[Pharo-project] Issue 3771 in pharo: avoid proposing a menu when nil is the doItReceiver of an interactive evaluation,

by pharo＠googlecode.com

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])!

March 1, 2011

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

by pharo＠googlecode.com

Updates: Status: Fixed Comment #3 on issue 3704 by stephane...(a)gmail.com: remove FakeClassPool adopt: and its senders http://code.google.com/p/pharo/issues/detail?id=3704 (No comment was entered for this change.) Attachments: fullnameproblem.1.cs 1.2 KB

March 1, 2011

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