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

Re: [Pharo-project] Preference refactoring again

by Alain Plantec

Alain Plantec a Ã©crit : >> Perhaps the PreferenceValue could hold the types/description too to >> help tools... >> >> FreeTypeSettings class>>monitorTypeLCD >> <preference> >> ^ MonitorTypeLCD ifNil: [ >> MonitorTypeLCD := PreferenceValue >> name: 'LCD monitor type' >> type: #Boolean >> value: false >> default: false >> decsription: 'Use of a LCD...'] >> > could be ok for me, anyway what do you think of: > > FreeTypeSettings class>>monitorTypeLCD > <preference: 'LCD monitor type' type: #Boolean decsription: 'Use of a > LCD...'> > ^ MonitorTypeLCD ifNil: [ MonitorTypeLCD := PreferenceValue value: > false default: false] > > Name, type and description are only useful from PreferenceBrowser point > of view (preference helper) > whereas a PreferenceValue is concerned by its value and its default. > or simply : FreeTypeSettings class>>monitorTypeLCD <preference:'LCD monitor type' type:#Boolean decsription:'Use of a LCD...'> ^ MonitorTypeLCD ifNil: [MonitorTypeLCD := PreferenceValue default:false]

March 2, 2009

Re: [Pharo-project] Preference refactoring again

by Alain Plantec

Gary Chambers a Ã©crit : > In that case perhaps the setter should expect a PreferenceValue or > native and internally store > one after setting its value. > > Not quite clear what should be stored in the class var from the code > snippet. > > Perhaps the following is simpler if the PreferenceValue does the > handling: > > FreeTypeSettings class>>monitorTypeLCD > <preference: 'LCD monitor type' type: #Boolean defaultValue: false > description: 'Use of a LCD...'> > ^ MonitorTypeLCD > ifNil: [MonitorTypeLCD := PreferenceValue value: false] > > Then to get is > > FreeTypeSettings monitorTypeLCD value > > and to set is > > FreeTypeSettings monitorTypeLCD value: true yes, it is better > > the PreferenceValue handles the notifications... > > FreeTypeSettings class>>initialize > self monitorStyleLCD when: #valueChanged send: > #monitorTypeLCDPreferenceChanged: to: self > > PreferenceValue>>value: anObject > realValue ~= anObject > ifTrue: [realValue := anObject. > self triggerEvent: #valueChanged with: anObject] cool, better again happy to learn :) > > Tools can just pick up the pragma and not have to worry about setters, > "location" etc. ok > Perhaps the PreferenceValue could hold the types/description too to > help tools... > > FreeTypeSettings class>>monitorTypeLCD > <preference> > ^ MonitorTypeLCD ifNil: [ > MonitorTypeLCD := PreferenceValue > name: 'LCD monitor type' > type: #Boolean > value: false > default: false > decsription: 'Use of a LCD...'] could be ok for me, anyway what do you think of: FreeTypeSettings class>>monitorTypeLCD <preference: 'LCD monitor type' type: #Boolean decsription: 'Use of a LCD...'> ^ MonitorTypeLCD ifNil: [ MonitorTypeLCD := PreferenceValue value: false default: false] Name, type and description are only useful from PreferenceBrowser point of view (preference helper) whereas a PreferenceValue is concerned by its value and its default. > > Here the pragma is a simple marker to identify the selector as a > preference returner. > > Of course, deliberately overwriting the class var directly will mean > that notification subscribers will become disassociated... If I well understand, I consider this as a bad pratice which should be detected by a lint rule. so, it is not a problem for me Cheers Alain > > > Simpler the better perhaps though. > > Regards, Gary > > ----- Original Message ----- From: "Alain Plantec" <beranger22(a)gmail.com> > To: "Gary Chambers" <gazzaguru2(a)btinternet.com> > Sent: Monday, March 02, 2009 11:05 AM > Subject: Re: [Pharo-project] Preference refactoring again > > >> 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

March 2, 2009

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

by StÃ©phane Ducasse

I'm realizing that the second approach (creating an empty class and filling it up) does not help to really curve out functionality since sometimes you cannot exercise easily On Mar 2, 2009, at 12:24 PM, StÃ©phane Ducasse wrote: > Now I get something somehow working with > > copyMethod: sel from: aClass > > | category | > Transcript show: 'Does not understand ', sel asString ; cr. > category := (aClass organization categoryOfElement: sel). > self class compile: (aClass sourceCodeAt: sel) classified: category. > Transcript show: 'recompiled', sel asString ; cr. > > > doesNotUnderstand: aMessage > > | sel | > sel := aMessage selector. > (Morph selectors includes: sel) > ifTrue: [^ self copyMethod: sel from: Morph]. > (Object selectors includes: sel) > ifTrue: [ self copyMethod: sel from: Object]. > ^ aMessage sentTo: self. > > I still would like to understand why the previous approach (alain- > based) does not work with Morph > so I will continue my little journey. > > stef > > _______________________________________________ > 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] Website

by Alexandre Bergel

Hi All, The download section of the website is rather incomplete. > http://www.pharo-project.org/download I added a while ago a couple of sentences in the download section on the google website. Maybe the pharo-project.org web administrator could cut&paste it. I could accessory do it, however I do not have an access to the cmsbox. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 2, 2009

Re: [Pharo-project] A point a.k.a excuse to you

by Keith Hodges

> > I believe you are correct, but not everybody sees Pharo that > way. Edgar and Keith in particular, sometimes see it as > non-appreciation of their work, which is similar in spirit, but > not as well managed. > Matthew, My response to pharo is based upon the ironic situation. I say for 3.11 "Lets promote a process to enable integration and sharing of the contributions of the community, accross the diverse range of images that we use" Pharo team says "Lets go off and do our own thing", and Edgar says the same. I find this totally ironic and sad, since you couldn't create more fragmentation of the main squeak protagonists if you tried. Now of course the whole point of the tools we have been working on, for 3.11 Bob etc, is to allow diversification, so we should welcome all of pharos efforts and innovations, and any like it. You seem puzzled as to why I don't appreciate pharo. The problem arises when no-sharing is done of the fundamental components that make the sharing possible. For example SUnit needs to be a common piece. It has to be there is no option. So if you do a fork and within your fork you fork your own version of SUnit, you are snubbing the rest of the community, and any possibility of working with the rest of the community, either by ignorance or on purpose. This has to be a managed policy decision, from the top. It is precisely because the pharo project is not managed and planned with any such principles in mind, that I stress my point, and will continue to do so. It took me 25 years to understand that I had been hacking code for 25 years! I did a large test driven project, following some XP principles, and realised that it is possible to plan, and to release professionally developed code. I know the difference between hacked up code and a planned managed process. To be honest I prefer the hacking approach for first iterations, and most of my squeak work has been hacked up due to time constraints. Rio, planned as a replacement for FileDirectory is now two years old! It is managed by tests, and reached perhaps 70% of the way there just this weekend, in terms of professionality. The current 170+ tests should be reviewed, code coverage and feature coverage checked, and the regression suite needs to be run automated on at least three platforms. I am saying that it takes a lot of effort to make a new module without hacking, and that module once defined should be potentially adoptable by all Smalltalks. (Rio is a bit squeak specific at present). In reference to recent discussions about Preferences how am I going to write any common code between pharo and squeak, if the preferences api is different, between squeak and pharo? Note that the tools and preference system can be as different as you like, but the API has to be common at some level for any sharing to be possible. We either keep the same api we have, or design a new one, and provide a basic specification that can be implemented in both environments. What we cant accept is any proposals or discussion about such an important API without appreciating that it will be expected to support code that comes from both environments. The fact that 'Author' exists only as a global in the Pharo environment and prevents code which uses it from loading in squeak is all the proof I need that the pharo process needs a rethink. cheers Keith

March 2, 2009

Re: [Pharo-project] Preference refactoring again

by Geert

Alain Plantec wrote: > > The pragma you see in ... > I can't seem to find a lot of info on the "pragmas" people are referring to, what are they exactly, when or what should they be used for, how do they work ...? Maybe another one for the book Stef :) -- View this message in context: http://n2.nabble.com/Preference-refactoring-again-tp2403814p2408738.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 2, 2009

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

by Gary Chambers

In Polymorph-ToolBuilder-gvc.6 on SqueakSource. Regards, Gary ----- Original Message ----- From: "Gary Chambers" <gazzaguru2(a)btinternet.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, March 02, 2009 10:43 AM Subject: Re: [Pharo-project] UIManager>>request: does notsendProvideAnswerNotification anymore > 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 > > > _______________________________________________ > 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] What are the ERROR messages in the Transcript Window in 10243?

by Rob Rothwell

Ok...thanks! Rob On Mon, Mar 2, 2009 at 4:00 AM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > On Sun, Mar 1, 2009 at 5:22 PM, Rob Rothwell <r.j.rothwell(a)gmail.com> > wrote: > > Should I post an issue? > > No, it's already fixed. Please update OB-Enhancements or wait for the > next pharo-dev. > > -- > 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

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

by StÃ©phane Ducasse

Now I get something somehow working with copyMethod: sel from: aClass | category | Transcript show: 'Does not understand ', sel asString ; cr. category := (aClass organization categoryOfElement: sel). self class compile: (aClass sourceCodeAt: sel) classified: category. Transcript show: 'recompiled', sel asString ; cr. doesNotUnderstand: aMessage | sel | sel := aMessage selector. (Morph selectors includes: sel) ifTrue: [^ self copyMethod: sel from: Morph]. (Object selectors includes: sel) ifTrue: [ self copyMethod: sel from: Object]. ^ aMessage sentTo: self. I still would like to understand why the previous approach (alain- based) does not work with Morph so I will continue my little journey. stef

March 2, 2009

Re: [Pharo-project] ProcessSpecific update

by Damien Cassou

On Mon, Mar 2, 2009 at 12:11 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Can you give us more information? Please use http://code.google.com/p/pharo/issues/detail?id=623 to precise the issue. -- Damien Cassou http://damiencassou.seasidehosting.st

March 2, 2009