- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Seaside?

by Keith Hodges

Lukas Renggli wrote: >>> If you want Seaside 2.9 you should use <http://builder.seaside.st/>. >>> >> Yes - but the builder ONLY allows to create a script for an ALPHA >> release (Seaside 2.9.0-alpha2). >> > > Yes. > > >> The script in ScriptLoader always loaded the NEWEST packages >> so people, who want to help extending and fixing Seaside could >> easily load it. It should also make sure that the latest "hot" >> Seaside stuff is working in Pharo. >> > > This cannot work: > > 1. Installer initializes packages in random order. > What do you mean? Keith

Feb. 5, 2009

[Pharo-project] [ANN] Pier 1.1

by Tudor Girba

Hi, Release 1.1 of Pier is now available: www.piercms.com/install What's new: - Several bug fixes - New syntax constructs - New and whiter stylesheet - Pharo inside www.piercms.com also received a face lift, and it got some new documentation. Have fun and tell us what you think. Doru and Lukas

Feb. 5, 2009

Re: [Pharo-project] Renaming instance variable

by StÃ©phane Ducasse

Thanks! Stef On Feb 4, 2009, at 9:24 PM, David RÃ¶thlisberger wrote: > > >> The problem is that when you code in the core then you should not >> have >> the other packages loaded >> or they should saved in the pharo repository. >> >> Damien could you modify the scriptloader to use the universe to >> load RB? > > I modified it. > > The reason why this method exists is that people can use it to test > latest > experimental features committed to OB (that's why it's named > 'Alpha') that are not > (yet) available in Universe. > I changed the script to load everything from Universe except all OB > packages. > I think that should be fair enough. > > The adapted ScriptLoader is in PharoInbox. > (I also adapted #loadSuperOB ...). > > > David > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 4, 2009

Re: [Pharo-project] A step by step tutorial about Traits

by StÃ©phane Ducasse

Hilaire have a look at CollectionsTest there are really simple example of traits. In 5 minutes you should get that: You have a trait TRemoveTest Trait named: #TRemoveTest uses: {} category: 'CollectionsTests-Abstract' easy TRemoveTest>>testRemoveElementFromEmpty "self debug: #testRemoveElementFromEmpty" self should: [self empty remove: self nonEmpty anyOne] raise: Error Easy self empty is undefined and it will return an empty collection self nonEmpty and nonEmpty one testRemoveElementThatExists "self debug: #testRemoveElementThatExists" | el res | el := self nonEmpty anyOne. self shouldnt: [res := self nonEmpty remove: el ] raise: Error. self assert: res == el testRemoveElementReallyRemovesElement "self debug: #testRemoveElementReallyRemovesElement" | size | size := self nonEmpty size. self nonEmpty remove: self nonEmpty anyOne. self assert: (size -1) = self nonEmpty size OK now you use the trait in a class For example Object subclass: #MySetTest uses: TRemoveTest instanceVariableNames: 'full empty You define setUp full := Set new add: 5 ; add: 6 ;yourself empty := Set new. nonEmpty ^ full empty ^ empty This is it!!!!! You can reuse your traits in another Test. Now if you do not like a trait method you can remove it or redefine it in your class DONE!!! Stef

Feb. 4, 2009

Re: [Pharo-project] About Preference Flow: was Re: MonticelloChangesDialog

by StÃ©phane Ducasse

Sorry gary you lost me. I do not get change informee. On Feb 4, 2009, at 5:50 PM, Gary Chambers wrote: > Looking at the changeInformee code in Preferences/Preference, the > informee > still has to query the preference > to pick up any changes as it stands... If I understand correctly I think not. The flow is only from the Preference to the tools and after the tools only refers to its internal state (which represents a state in his own preference). Stef > > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Wednesday, February 04, 2009 2:50 PM > Subject: Re: [Pharo-project] About Preference Flow: was Re: > MonticelloChangesDialog > > > > On Feb 4, 2009, at 1:11 PM, Gary Chambers wrote: > >> Ceratainly possible. You'd want a discovery mechanism for a new >> Preference >> Browser also, otherwise who would know what the preferences are. > > no because you still define the preference in the Preference class > it just pushes the right value in MyTool and MyTool does not have to > query Preference > at runtime. > >> The method flow would still be similar, unless you had some >> redirection to >> alternate classes or methods or blocks... > > No. We use the preference when we select it. Then MyTool uses what has > been pushed > to it. and in particular it does not query at runtime preference. > So Preference becomes a removal layer on top of the system and not > something > referenced by every method flow. > >> So, in new scheme (no dependency on Preferences) the doSomething >> might be: >> >> self class shouldUseNewDiffTool >> ifTrue: [kjlhkjhjkh ] >> ifFalse: [nkjhkjkjhkj] > > Yes in mytool I deal the way I want about my preference since they are > local to me. > I do not involve preference. Preference is just a handy facade > grouping all the preferences > and an entry point to set the preferences in the tools. > >> >> >> and >> MyTool class>>preferences >> >> would answer something suitable for a preference browser. > > Could be but the package could also install the preferences in the > preferences class > > Stef >> >> >> Regards, Gary. >> >> ----- Original Message ----- >> From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Wednesday, February 04, 2009 7:58 AM >> Subject: [Pharo-project] About Preference Flow: was Re: Monticello >> ChangesDialog >> >> >>> Gary >>> >>> I have a request about the way we use preference. And this is kind >>> of >>> really really important if we want to >>> stop having spaghetti code. >>> >>> Instead of having the current situation ie >>> >>> MyTool>>doSomething >>> >>> .... >>> Preferences useNewDiffTool >>> ifTrue: [kjlhkjhjkh ] >>> ifFalse: [nkjhkjkjhkj] >>> >>> >>> and not been able to remove the preferences (or that the preference >>> is >>> just a configuration layer). >>> >>> I would like to have the preference made that way >>> >>> MyTool class>>useNewDiff >>> >>> MyTool class>> useOldDiff >>> >>> **NO REFERENCE TO PREFERENCE IN THE METHOD FLOW!!!! >>> >>> >>> Preferences useNewDiffTool >>> MyTool useNewDiff >>> >>> I really think that we can do it that way and this way we would >>> have a >>> much more object-oriented system >>> Do you think that this is possible with polymorph? >>> I think so. >>> >>> Stef >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 4, 2009

Re: [Pharo-project] About Preference Flow: was Re: MonticelloChangesDialog

by StÃ©phane Ducasse

Yes this would be much better. stef On Feb 4, 2009, at 5:57 PM, Lukas Renggli wrote: > Why not use pragmas on accessors of the class side that would be > picked up by the preference browser? Then all state would be local to > the affected code. > > Something along these lines: > > MCMonticelloBrowser>>showAdvanceDiffTool: aBoolean > <preference: 'Show advanced diff tool' group: 'Monticello' type: > #Boolean> > > advancedDiffTool := aBoolean > > > Lukas > > On Wed, Feb 4, 2009 at 5:50 PM, Gary Chambers <gazzaguru2(a)btinternet.com > > wrote: >> Looking at the changeInformee code in Preferences/Preference, the >> informee >> still has to query the preference >> to pick up any changes as it stands... >> >> ----- Original Message ----- >> From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Wednesday, February 04, 2009 2:50 PM >> Subject: Re: [Pharo-project] About Preference Flow: was Re: >> MonticelloChangesDialog >> >> >> >> On Feb 4, 2009, at 1:11 PM, Gary Chambers wrote: >> >>> Ceratainly possible. You'd want a discovery mechanism for a new >>> Preference >>> Browser also, otherwise who would know what the preferences are. >> >> no because you still define the preference in the Preference class >> it just pushes the right value in MyTool and MyTool does not have to >> query Preference >> at runtime. >> >>> The method flow would still be similar, unless you had some >>> redirection to >>> alternate classes or methods or blocks... >> >> No. We use the preference when we select it. Then MyTool uses what >> has >> been pushed >> to it. and in particular it does not query at runtime preference. >> So Preference becomes a removal layer on top of the system and not >> something >> referenced by every method flow. >> >>> So, in new scheme (no dependency on Preferences) the doSomething >>> might be: >>> >>> self class shouldUseNewDiffTool >>> ifTrue: [kjlhkjhjkh ] >>> ifFalse: [nkjhkjkjhkj] >> >> Yes in mytool I deal the way I want about my preference since they >> are >> local to me. >> I do not involve preference. Preference is just a handy facade >> grouping all the preferences >> and an entry point to set the preferences in the tools. >> >>> >>> >>> and >>> MyTool class>>preferences >>> >>> would answer something suitable for a preference browser. >> >> Could be but the package could also install the preferences in the >> preferences class >> >> Stef >>> >>> >>> Regards, Gary. >>> >>> ----- Original Message ----- >>> From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> >>> To: <Pharo-project(a)lists.gforge.inria.fr> >>> Sent: Wednesday, February 04, 2009 7:58 AM >>> Subject: [Pharo-project] About Preference Flow: was Re: Monticello >>> ChangesDialog >>> >>> >>>> Gary >>>> >>>> I have a request about the way we use preference. And this is >>>> kind of >>>> really really important if we want to >>>> stop having spaghetti code. >>>> >>>> Instead of having the current situation ie >>>> >>>> MyTool>>doSomething >>>> >>>> .... >>>> Preferences useNewDiffTool >>>> ifTrue: [kjlhkjhjkh ] >>>> ifFalse: [nkjhkjkjhkj] >>>> >>>> >>>> and not been able to remove the preferences (or that the preference >>>> is >>>> just a configuration layer). >>>> >>>> I would like to have the preference made that way >>>> >>>> MyTool class>>useNewDiff >>>> >>>> MyTool class>> useOldDiff >>>> >>>> **NO REFERENCE TO PREFERENCE IN THE METHOD FLOW!!!! >>>> >>>> >>>> Preferences useNewDiffTool >>>> MyTool useNewDiff >>>> >>>> I really think that we can do it that way and this way we would >>>> have a >>>> much more object-oriented system >>>> Do you think that this is possible with polymorph? >>>> I think so. >>>> >>>> Stef >>>> >>>> _______________________________________________ >>>> 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 >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 4, 2009

Re: [Pharo-project] Renaming instance variable

by David RÃ¶thlisberger

> The problem is that when you code in the core then you should not have > the other packages loaded > or they should saved in the pharo repository. > > Damien could you modify the scriptloader to use the universe to load RB? I modified it. The reason why this method exists is that people can use it to test latest experimental features committed to OB (that's why it's named 'Alpha') that are not (yet) available in Universe. I changed the script to load everything from Universe except all OB packages. I think that should be fair enough. The adapted ScriptLoader is in PharoInbox. (I also adapted #loadSuperOB ...). David

Feb. 4, 2009

Re: [Pharo-project] renaming a method category

by David RÃ¶thlisberger

Hi Alex, > When I try to rename a method category, I get a DNU: > OBMethodCategoryNode>>setName: thanks for letting me know, I fixed this in the latest version. The fix is also available in Universe. David

Feb. 4, 2009

Re: [Pharo-project] colored list items ?

by David RÃ¶thlisberger

When using OmniBrowser, you also get extensions to LazyListMorph and PluggableListMorph (in classes prefixed with 'OB') that also support coloring of list items even when not using Polymoprh. In case you need this. OmniBrowser itself directly supports coloring of list items in the model by letting nodes answer a #backgroundColor. Cheers, David > On 4 Feb 2009, at 18:48, Gary Chambers wrote: > >> It is possible when using Polymorph's MorphListMorph... >> Using translucent colours helps to keep the selection highlight >> visible. >> >> The standard lists don't represent each item as a morph nor do they >> hold any >> extra state for each line. >> >> Regards, Gary. >> >> ----- Original Message ----- >> From: "Alexandre Bergel" <Alexandre.Bergel(a)inria.fr> >> To: "Pharo Mailing List" <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Wednesday, February 04, 2009 5:23 PM >> Subject: [Pharo-project] colored list items ? >> >> >>> Hi! >>> >>> Is there a way to get list items colored? one background color for >>> each line/item. >>> It may be interesting to extend the debugger to assign a color per >>> class or something... >>> >>> 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 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

Feb. 4, 2009

Re: [Pharo-project] A step by step tutorial about Traits

by Hilaire Fernandes

I understand the idea and need of traits, probably as any OOP developper. What I need is just a kickstart guide, something very practical. Damien, your document is 35pp, I don't have time to read it now. I will look at it later. thanks for the indication. Hilaire 2009/2/4 Alexandre Bergel <alexandre(a)bergel.eu>: > I spent 30 seconds on this scenario, so maybe it is a bit flaky, but > nevertheless it should convey the idea. > > Have a look at the classes FileStreamTest, FileDirectoryTest, > DosFileDirectoryTests, and MacFileDirectoryTest. Glancing at these > classes I can say that: > - DosFileDirectoryTests tests many features of fileDirectory. > - MacFileDirectoryTest tests very few > - FileDirectoryTest has a few tests > - FileStreamTest is almost empty > > I am not expert in files, but I suspect that a common "behavior" must > be shared among these 4 classes. For example, file existence, what you > write in a file is what you read afterward, ... > > Assuming that these 4 classes should cover these "behaviors", I would > therefore affirm that some test classes are incomplete. Making these 4 > classes cover the behavior will probably generate code duplication. > And Inheritance may be not that well adapted (again, I haven't though > a lot about it). > > However, with traits the solution will be quite easy: > - Create a new trait. For example, TExistingFileTest, that defines a > method testExists. You can inspire yourself from FileDirectoryTest > - Make this test used by these 4 classes. > - The tricky think is to define the right "fixture". A fixture is the > code necessary by a test class to test the domain it is related to. > > Cheers, > Alexandre > > > > On 4 Feb 2009, at 17:54, Hilaire Fernandes wrote: > >> Okay. >> I look at several papers about traits, and all the ones I saw need a >> few time to digest and >> I am also more or less in a hurry right now. >> >> About looking at the code and trying, which canonical examples can you >> suggest to look at? >> >> Hilaire >> >> >> 2009/2/4 Alexandre Bergel <alexandre(a)bergel.eu>: >>> I am not aware of such a tutorial. >>> The best is probably to use it. Note that I provided a refactoring >>> "move methods into a new traits" that may help. Just give a try and >>> ask questions :-) >>> >>> We are planning to write such tutorial, but resources (especially >>> time) are quite scarce these days (which is not necessarily a bad >>> thing by the way) >>> >>> Alexandre >>> >>> >>> On 4 Feb 2009, at 17:38, Hilaire Fernandes wrote: >>> >>>> Hi, >>>> >>>> Can someone suggest me a nice traits tutorial to quickly start with >>>> it? >>>> >>>> Thanks >>>> >>>> Hilaire >>>> >>>> -- >>>> http://blog.ofset.org/hilaire >>>> >>>> _______________________________________________ >>>> 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 >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> http://blog.ofset.org/hilaire >> >> _______________________________________________ >> 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- http://blog.ofset.org/hilaire

Feb. 4, 2009