- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Website

by Adrian Lienhard

Hi Alex, I copied the links over to the web page (http://www.pharo-project.org/download ). I suggest that we remove them on the wiki and link to that page (except for the links that are specific to the development of Pharo, that is, the "Pharo from scratch" links), so that we don't need to maintain two sets of links. Cheers, Adrian On Mar 2, 2009, at 13:10 , Alexandre Bergel wrote: > 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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] loadOBApha

by Alexandre Bergel

Thanks Damien for letting us know. Anyone can provide an update? Cheers, Alexandre On 2 Mar 2009, at 15:40, Damien Cassou wrote: > On Mon, Mar 2, 2009 at 2:53 PM, Alexandre Bergel > <Alexandre.Bergel(a)inria.fr> wrote: >> It seems that the RB is not loaded with loadOBAlpha >> >> Anything changed with the following universe definition? > > I fixed #loadOBAlpha, but it went to PharoTreatedInbox instead of > going to Pharo, I don't know why. > > -- > 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 2, 2009

Re: [Pharo-project] split/join

by Alexandre Bergel

Thanks, Alexandre On 2 Mar 2009, at 11:48, CÃ©drick BÃ©ler wrote: >> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 2, 2009

Re: [Pharo-project] loadOBApha

by Damien Cassou

On Mon, Mar 2, 2009 at 2:53 PM, Alexandre Bergel <Alexandre.Bergel(a)inria.fr> wrote: > It seems that the RB is not loaded with loadOBAlpha > > Anything changed with the following universe definition? I fixed #loadOBAlpha, but it went to PharoTreatedInbox instead of going to Pharo, I don't know why. -- Damien Cassou http://damiencassou.seasidehosting.st

March 2, 2009

[Pharo-project] loadOBApha

by Alexandre Bergel

Dear List, It seems that the RB is not loaded with loadOBAlpha Anything changed with the following universe definition? self new universalInstaller universe update; addPackage: 'Shout'; addPackage: 'AST'; addPackage: 'Refactoring Core'; install. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 2, 2009

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

by Damien Cassou

Thank you very much Gary. On Mon, Mar 2, 2009 at 12:27 PM, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Cassou http://damiencassou.seasidehosting.st

March 2, 2009

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

by StÃ©phane Ducasse

I traced a bit my problem (using the approach of alain: DNU recompiling methods and recompiling the methods) on Morph, what is strange is that I could install some methods but from time to time it blocks my image. I have the impression that this is related to the UI event (I closed all windows and remov dockingsbar from the methods that I instrument but it still freezes in a non really reproduceable manner. Is there a higher priority thread refreshing everything.... I still do not understand why if the DNU reinstall the old methods, the system blocks. Building hypotheses is then difficult because I have no tool to verify them. Stef

March 2, 2009

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