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

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

Re: [Pharo-project] Running SqueakSource on pharo

by Marco D'Ambros

I see... Is there an image somewhere with SqueakSource loaded? The ones I found on the web were actually broken links :( cheers Marco On Feb 4, 2009, at 7:05 PM, Lukas Renggli wrote: > I don't know who put SqueakSource on Package Universe? > > SqueakSource is using a very old version of Seaside that is certainly > not available from Package Universe. So I wonder how this is supposed > to work? > > Lukas > > On Wed, Feb 4, 2009 at 7:03 PM, Marco D'Ambros > <marco.dambros(a)lu.unisi.ch> wrote: >> Hi, >> it seems to me that the root seaside class for squeaksource is >> SSFrame. >> I tried to evaluate >> SSFrame registerAsApplication: 'ss' >> and then go on: http://localhost:8888/seaside/ss/ >> but i get the exception: >> MessageNotUnderstood: WASession>>relativePathFor: >> any idea? >> thanks >> Marco >> >> On Feb 4, 2009, at 3:25 PM, Marco D'Ambros wrote: >> >> Hi, >> >> I am trying to run SqueakSource with Pharo. Using the pharo-dev >> image, >> I got squeksource with universe. >> Then I initialize the SSRepository with the default repository and it >> worked. >> What I am not able to do is to make squeaksource available on the >> web. >> I did not find any class sending the message #registerAsApplication >> and I dunno which class is the main component which should be >> registered to seaside. >> >> thanks and cheers >> Marco >> >> _______________________________________________ >> 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] Running SqueakSource on pharo

by Lukas Renggli

I don't know who put SqueakSource on Package Universe? SqueakSource is using a very old version of Seaside that is certainly not available from Package Universe. So I wonder how this is supposed to work? Lukas On Wed, Feb 4, 2009 at 7:03 PM, Marco D'Ambros <marco.dambros(a)lu.unisi.ch> wrote: > Hi, > it seems to me that the root seaside class for squeaksource is SSFrame. > I tried to evaluate > SSFrame registerAsApplication: 'ss' > and then go on: http://localhost:8888/seaside/ss/ > but i get the exception: > MessageNotUnderstood: WASession>>relativePathFor: > any idea? > thanks > Marco > > On Feb 4, 2009, at 3:25 PM, Marco D'Ambros wrote: > > Hi, > > I am trying to run SqueakSource with Pharo. Using the pharo-dev image, > I got squeksource with universe. > Then I initialize the SSRepository with the default repository and it > worked. > What I am not able to do is to make squeaksource available on the web. > I did not find any class sending the message #registerAsApplication > and I dunno which class is the main component which should be > registered to seaside. > > thanks and cheers > Marco > > _______________________________________________ > 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] Running SqueakSource on pharo

by Marco D'Ambros

Hi, it seems to me that the root seaside class for squeaksource is SSFrame. I tried to evaluate SSFrame registerAsApplication: 'ss' and then go on: http://localhost:8888/seaside/ss/ but i get the exception: MessageNotUnderstood: WASession>>relativePathFor: any idea? thanks Marco On Feb 4, 2009, at 3:25 PM, Marco D'Ambros wrote: > Hi, > > I am trying to run SqueakSource with Pharo. Using the pharo-dev image, > I got squeksource with universe. > Then I initialize the SSRepository with the default repository and it > worked. > What I am not able to do is to make squeaksource available on the web. > I did not find any class sending the message #registerAsApplication > and I dunno which class is the main component which should be > registered to seaside. > > thanks and cheers > Marco > > _______________________________________________ > 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] colored list items ?

by Alexandre Bergel

Thanks Gary, Alexandre 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 4, 2009