- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Preference refactoring again

by Alain Plantec

Gary Chambers a Ã©crit : Hi Gary, > Looks good. Is there really a need for a PreferenceValue class though? > > I'm concerned that the getter returns a different kind of object to > that expected by the setter... yes, ok FreeTypeSettings class>>monitorTypeLCD <preference: 'LCD monitor type' type: #Boolean set: #monitorTypeLCD: defaultValue: false description: 'Use of a LCD...'> ^ (MonitorTypeLCD ifNil: [MonitorTypeLCD := PreferenceValue value: false location: self selector: #monitorTypeLCD]) value > For any preference tool the presence of the pragma is sufficient to > get/set the native value and, assuming always class-side, support > event triggering for changes. I'm not sure to understand. you suggest a solution like this ? : FreeTypeSettings class>>monitorTypeLCD: aBoolean monitorTypeLCD := aBoolean. self triggerEvent: #monitorTypeLCD with: aBoolean Of course, then you do not need PreferenceValue. But I prefer PreferenceValue solution because it encapsulates the triggerEvent, the developper do not have to deal with it and it is more evolutive (it is easy to change the way events are triggered or to change the notification framework). regarding the pragma use, I see it as only useful from supporting tools (PreferencesBrowser...). but maybe I'm wrong, let me know. Cheers Alain > > Regards, Gary > > ----- Original Message ----- From: "Alain Plantec" > <alain.plantec(a)free.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, March 02, 2009 8:41 AM > Subject: Re: [Pharo-project] Preference refactoring again > > > Geert a Ã©crit : >> Hi Alain, this sounds very interesting. > thanks >> I have never been a big fan of the >> current "Preference Browser". > The main problem with current preference system is that it makes uses of > globals (declared in the class side of Preferences) and that a lot of > packages depend on it. > The main goal of the refactoring is to make preferences local to the > packages in which they are declared. > Current preference browser is not that bad and could be reused. >> I am now trying to grasp (still learning >> here) how this new "Pharo Preference Mechanism" works.It would be >> great if >> the mechanism could be explained in detail in something like the new >> Pharo >> By Example manual :) >> > Each preference is stored by a PreferenceValue instance and each time a > PreferenceValue is updated (with a #value: message sent) an event is > sent to the class which defines the preference. The event sending is > standard: > PreferenceValue>>value: anObject > realValue ~= anObject > ifTrue: [realValue := anObject. > location triggerEvent: selector with: anObject] > > realValue is the instance variable wich stores current preference value. > location is the class which declares the preference > selector is the selector of the preference (i.e. #gradientButtonLook) > > So my proposition is to declare a preference locally. Let's take the > example of freetype monitorTypeLCD preference. > If we implement it the way it is now, as a boolean, it could be: > --------------- > FreeTypeSettings class>>monitorTypeLCD > <preference: 'LCD monitor type' type: #Boolean set: #monitorTypeLCD: > defaultValue: false description: 'Use of a LCD...'> > ^ MonitorTypeLCD > ifNil: [MonitorTypeLCD := PreferenceValue value: false location: > self selector: #monitorTypeLCD] > > FreeTypeSettings class>>monitorTypeLCD: aBoolean > self monitorTypeLCD value: hintingFull > > FreeTypeSettings class>>initialize > FreeTypeSettings when: #monitorTypeLCD send: > #monitorTypeLCDPreferenceChanged: to: self. > > FreeTypeSettings class>>monitorTypeLCDPreferenceChanged: aBoolean > self current monitorTypeLCDPreferenceChanged: aBoolean > ------------- > The pragma you see in FreeTypeSettings class>>monitorTypeLCD in only > here for UI tools such as PreferenceBrowser. > > If a client object needs monitorTypeLCD value, it asks directly to its > provider which is FreeTypeSettings class: > ... > useLCD := FreeTypeSettings monitorTypeLCD value. > ... > > but note that such a preference should be set as a choice between two > values #LCD or #CRT... > > hope things are a little bit clearer now. > alain >> >> Alain Plantec wrote: >> >>> I've joined 4 packages : >>> - PrefCore contains PreferenceValue which is now the only mandatory >>> class. >>> >>> 2 packages for testing: >>> - PrefProvider contains PrefProvider class which declares some >>> preferences >>> - PrefUser contains PrefChangeListener (try PrefChangeListener test). >>> >>> 1 package for UI: >>> - PrefTool contains PreferenceCollector and PreferenceDefinition. They >>> are optional. >>> >>> >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

March 2, 2009

Re: [Pharo-project] Dynamic dead code alpha version

by StÃ©phane Ducasse

>> > ...or use objects as methods or method wrappers. I did a quick > experiment with the package > > http://www.squeaksource.com/ObjectsAsMethodsWrap.html > > from Markus GÃ¤lli. Just had to fix the send of #removeSeletorSimply: > with #removeSelectorSilently: to make it work (@Markus, could you add > this or give me write access?). > > ((PackageInfo named: 'Morphic') classes gather: [ :each | > ObjectAsOneTimeMethodWrapper installOnClass: each ]) inspect > > gets you a collection of wrapper objects which you can ask #executed. > I opened all tools and menus in the image and got 2100 methods > executed out of 6518. Cool I was doing because I thought that may be I could get a problem with superclass method :) doesNotUnderstand: aMessage | sel | sel := aMessage selector. (Morph selectors includes: sel) ifTrue: [^ self copyMethod: aMessage from: Morph]. (Object selectors includes: sel) ifTrue: [ self copyMethod: aMessage from: Object]. ^ aMessage sentTo: self. copyMethod: sel from: aClass | category | Transcript show: 'Does not understand ', sel ; cr. category := (aClass organization categoryOfElement: sel). self class compile: (aClass sourceCodeAt: sel) classified: category. Transcript show: 'recompiled', sel printString ; cr. Stef

March 2, 2009

Re: [Pharo-project] Seaside working on Pharo

by Adrian Lienhard

On Mar 2, 2009, at 11:41 , Damien Cassou wrote: > Unfortunately, this crashed my unix VM 2 times with the following > message: > > squeak: /home/piumarta/squeak/platforms/unix/vm/sqUnixMemory.c:172: > uxGrowMemoryBy: Assertion `newDelta >= 0' failed. > Aborted Looks like http://bugs.squeak.org/view.php?id=6667 The problem is known for more than 2 years [1], but as far as I understand the fix has not been integrated in the unix VM yet. See also http://www.nabble.com/newDelta-%3E0-failed-in-sqUnixMemory----Was-Re:--Phar… Cheers, Adrian [1] http://www.nabble.com/An-issue-with-Slang,-the-interpreter---the-VM,-and-a-…

March 2, 2009

Re: [Pharo-project] split/join

by CÃ©drick BÃ©ler

> What is split/join? I guess: #(1 2 3) joinWith: ', ' -> '1, 2, 3' '1:2:3' splitOn: $: -> #(1 2 3) It's more a perl shard no ? :) Cheers, -- CÃ©drick

March 2, 2009

Re: [Pharo-project] UIManager>>request: does not sendProvideAnswerNotification anymore

by Gary Chambers

Indeed this is the case with Polymorph. I'll see what I can do. Regards, Gary ----- Original Message ----- From: "Damien Cassou" <damien.cassou(a)gmail.com> To: "Gary Chambers" <gary(a)pinesoft.co.uk>; "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> Sent: Monday, March 02, 2009 10:35 AM Subject: [Pharo-project] UIManager>>request: does not sendProvideAnswerNotification anymore > Hi, > > it seems that calling #request: does not trigger a > ProvideAnswerNotification. This notification is used by > #valueSuppressingMessages:supplyingAnswers: to automatically fill text > requests. > > Can somebody check that? > > [UIManager default request: 'Please choose a username for\the > application ' withCRs , 'config' printString] > valueSuppressingMessages: Array new supplyingAnswers: > (Array with: (Array with: '.*username.*' with: 'admin')) > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 2, 2009

[Pharo-project] Seaside working on Pharo

by Damien Cassou

Hi, I've just written a small Installer-based script to install Seaside2.8 into Pharo image. Load the latest ScriptLoader from PharoInbox and do: ScriptLoader loadSeaside Unfortunately, this crashed my unix VM 2 times with the following message: squeak: /home/piumarta/squeak/platforms/unix/vm/sqUnixMemory.c:172: uxGrowMemoryBy: Assertion `newDelta >= 0' failed. Aborted Sometimes it works though. To make it work more reliably, I pass '-memory 512m' to the VM. -- Damien Cassou http://damiencassou.seasidehosting.st

March 2, 2009

Re: [Pharo-project] Preference refactoring again

by Gary Chambers

Looks good. Is there really a need for a PreferenceValue class though? I'm concerned that the getter returns a different kind of object to that expected by the setter... For any preference tool the presence of the pragma is sufficient to get/set the native value and, assuming always class-side, support event triggering for changes. Regards, Gary ----- Original Message ----- From: "Alain Plantec" <alain.plantec(a)free.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, March 02, 2009 8:41 AM Subject: Re: [Pharo-project] Preference refactoring again Geert a Ã©crit : > Hi Alain, this sounds very interesting. thanks > I have never been a big fan of the > current "Preference Browser". The main problem with current preference system is that it makes uses of globals (declared in the class side of Preferences) and that a lot of packages depend on it. The main goal of the refactoring is to make preferences local to the packages in which they are declared. Current preference browser is not that bad and could be reused. > I am now trying to grasp (still learning > here) how this new "Pharo Preference Mechanism" works.It would be great if > the mechanism could be explained in detail in something like the new Pharo > By Example manual :) > Each preference is stored by a PreferenceValue instance and each time a PreferenceValue is updated (with a #value: message sent) an event is sent to the class which defines the preference. The event sending is standard: PreferenceValue>>value: anObject realValue ~= anObject ifTrue: [realValue := anObject. location triggerEvent: selector with: anObject] realValue is the instance variable wich stores current preference value. location is the class which declares the preference selector is the selector of the preference (i.e. #gradientButtonLook) So my proposition is to declare a preference locally. Let's take the example of freetype monitorTypeLCD preference. If we implement it the way it is now, as a boolean, it could be: --------------- FreeTypeSettings class>>monitorTypeLCD <preference: 'LCD monitor type' type: #Boolean set: #monitorTypeLCD: defaultValue: false description: 'Use of a LCD...'> ^ MonitorTypeLCD ifNil: [MonitorTypeLCD := PreferenceValue value: false location: self selector: #monitorTypeLCD] FreeTypeSettings class>>monitorTypeLCD: aBoolean self monitorTypeLCD value: hintingFull FreeTypeSettings class>>initialize FreeTypeSettings when: #monitorTypeLCD send: #monitorTypeLCDPreferenceChanged: to: self. FreeTypeSettings class>>monitorTypeLCDPreferenceChanged: aBoolean self current monitorTypeLCDPreferenceChanged: aBoolean ------------- The pragma you see in FreeTypeSettings class>>monitorTypeLCD in only here for UI tools such as PreferenceBrowser. If a client object needs monitorTypeLCD value, it asks directly to its provider which is FreeTypeSettings class: ... useLCD := FreeTypeSettings monitorTypeLCD value. ... but note that such a preference should be set as a choice between two values #LCD or #CRT... hope things are a little bit clearer now. alain > > Alain Plantec wrote: > >> I've joined 4 packages : >> - PrefCore contains PreferenceValue which is now the only mandatory >> class. >> >> 2 packages for testing: >> - PrefProvider contains PrefProvider class which declares some >> preferences >> - PrefUser contains PrefChangeListener (try PrefChangeListener test). >> >> 1 package for UI: >> - PrefTool contains PreferenceCollector and PreferenceDefinition. They >> are optional. >> >> > > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 2, 2009

[Pharo-project] UIManager>>request: does not send ProvideAnswerNotification anymore

by Damien Cassou

Hi, it seems that calling #request: does not trigger a ProvideAnswerNotification. This notification is used by #valueSuppressingMessages:supplyingAnswers: to automatically fill text requests. Can somebody check that? [UIManager default request: 'Please choose a username for\the application ' withCRs , 'config' printString] valueSuppressingMessages: Array new supplyingAnswers: (Array with: (Array with: '.*username.*' with: 'admin')) -- Damien Cassou http://damiencassou.seasidehosting.st

March 2, 2009

[Pharo-project] ProcessSpecific update

by Keith Hodges

You guys will need to include the overrides from the latest Process-Specific package as found in squeaksource/Logging. This switches in the correct process environment when stepping in the debugger Keith

March 2, 2009

[Pharo-project] sender implementeur in Menu of texts

by StÃ©phane Ducasse

Hi is it me or we cannot see the implementors and senders in the text menu? Stef

March 2, 2009