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

Re: [Pharo-project] colored list items ?

by Gary Chambers

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

Feb. 4, 2009

[Pharo-project] colored list items ?

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 4, 2009

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

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 4, 2009

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

by Damien Cassou

On Wed, Feb 4, 2009 at 5:54 PM, Hilaire Fernandes <hilaire(a)ofset.org> wrote: > About looking at the code and trying, which canonical examples can you > suggest to look at? There is no canonical example. I would start with Nile (availble from Universe) because it is documented (http://www.iam.unibe.ch/~scg/Archive/Papers/Cass08a-NileNewKernel-ComputerL…) and not too complicated. -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 4, 2009

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

by Lukas Renggli

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

Feb. 4, 2009

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

by Hilaire Fernandes

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

Feb. 4, 2009

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

by Gary Chambers

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

Feb. 4, 2009

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

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 4, 2009

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

by Hilaire Fernandes

Hi, Can someone suggest me a nice traits tutorial to quickly start with it? Thanks Hilaire -- http://blog.ofset.org/hilaire

Feb. 4, 2009

Re: [Pharo-project] About Preference Flow: was Re: Monticello ChangesDialog

by StÃ©phane Ducasse

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 >

Feb. 4, 2009