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

Re: [Pharo-project] What are the ERROR messages in the Transcript Window in 10243?

by Rob Rothwell

Should I post an issue? Thank your, Rob On Sun, Mar 1, 2009 at 7:54 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Seems a problem in OB: OBDBSuperSend sends #superSenderSelectors, > which is not implemented. > > Adrian > > On Feb 28, 2009, at 19:06 , Rob Rothwell wrote: > > > Maybe I just wasn't able to follow the conversation properly, but if > > you > > open a Transcript in 10243 (dev) and, say, search for the class > > "Morph," you > > will get: > > > > ERROR: Morph class>>overridesSelectors > > ERROR: Morph class>>superSenderSelectors > > ERROR: Morph class>>conflictsSelectors > > ERROR: Morph class>>overridesSelectors > > ERROR: Morph class>>superSenderSelectors > > ERROR: Morph class>>conflictsSelectors > > > > In fact, anytime you do anything (save a method, etc...), it seems > > you get > > these messages, and yet things seem to be working. > > > > Rob > > _______________________________________________ > > 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 1, 2009

Re: [Pharo-project] changing default font

by Rob Rothwell

And if you get tired of setting your fonts individually, you can set them all at once: font := LogicalFont familyName: 'Andika Basic' pointSize: 10. codeFont := LogicalFont familyName: 'DejaVu Sans Mono' pointSize: 9. Preferences setListFontTo: font. Preferences setMenuFontTo: font. Preferences setCodeFontTo: codeFont. Preferences setButtonFontTo: font. Preferences setSystemFontTo: font. font := LogicalFont familyName: 'Andika Basic' pointSize: 11. Preferences setWindowTitleFontTo: font. Just replace the font names with those of your choice! Rob On Sun, Mar 1, 2009 at 10:56 AM, Sebastian Sastre <ssastre(a)seaswork.com>wrote: > It suddendly started to work, I think it was SqueakFFIPrims.dll that was > missing > > cheers, > sebastian > > > > -----Mensaje original----- > > De: pharo-project-bounces(a)lists.gforge.inria.fr > > [mailto:pharo-project-bounces@lists.gforge.inria.fr] En > > nombre de Sebastian Sastre > > Enviado el: Sunday, March 01, 2009 12:06 > > Para: Pharo-project(a)lists.gforge.inria.fr > > Asunto: [Pharo-project] changing default font > > > > hi there, > > sorry for the noob question but I see pharo has freetype in > > the image but it's > > only accuny font among options. Shouldn't freetype read the > > fonts on the system > > and offer those too? > > thanks, > > sebastian > > > > > > _______________________________________________ > > 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 1, 2009

Re: [Pharo-project] changing default font

by Sebastian Sastre

It suddendly started to work, I think it was SqueakFFIPrims.dll that was missing cheers, sebastian > -----Mensaje original----- > De: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] En > nombre de Sebastian Sastre > Enviado el: Sunday, March 01, 2009 12:06 > Para: Pharo-project(a)lists.gforge.inria.fr > Asunto: [Pharo-project] changing default font > > hi there, > sorry for the noob question but I see pharo has freetype in > the image but it's > only accuny font among options. Shouldn't freetype read the > fonts on the system > and offer those too? > thanks, > sebastian > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 1, 2009

[Pharo-project] changing default font

by Sebastian Sastre

hi there, sorry for the noob question but I see pharo has freetype in the image but it's only accuny font among options. Shouldn't freetype read the fonts on the system and offer those too? thanks, sebastian

March 1, 2009

Re: [Pharo-project] Fwd: [ANN] 10245

by Norbert Hartl

Bill, On Sun, 2009-03-01 at 09:23 -0500, Schwab,Wilhelm K wrote: > Norbert, > > I agree re aliases, but only to a point. When trying to be compatible with other dialects, the aliases spare many other users from independently having to add them. When it is reasonable, I have no problem with it. This is another example of how nice it would be to have Dolphin's ability to apply multiple categories to a method; aliases can be flagged as such. Then they can be tested and maintained rather than having myriad ad hoc attempts to fill a gap between dialects. > > We have seen some complaints about lack of backward compatibility with Squeak. I have no desire to be hostile, but Pharo is the cleaning that Squeak has needed for several years; there will be side effects. If Pharo becomes what I think it will, there will be a time when things get back-ported to Squeak from Pharo. > > The difference is on one of purpose and degree. Are we trying desperately to fix Squeak and yet ensure that all of Pharo's improvements work perfectly on it? I consider that unlikely to work. If we are instead providing a few methods here or there that eliminate small incompatibilities, it is probably appropriate to add them and categorize them appropriately. > I agree. Coming from AXAnnouncements I already had to exchange when:do: with subscribe:do:. I'm just wondering why there are then three sets of these methods. Having VW compatibility is good. But then I should consider deprecating one of the others. Where does subscribe:do: come from? Norbert > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Norbert Hartl > Sent: Sunday, March 01, 2009 8:13 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Fwd: [ANN] 10245 > > On Sun, 2009-03-01 at 10:47 +0100, Tudor Girba wrote: > > I copied it to the repository of Lukas as well. > > > > Does anyone actually see a reason for not having the when:do: method > > in as an alias to on:do:? I do not see it. > > > Because then there is > > on:do: > subscribe:do: > when:do: > > with all for: and send:to: variants. > > Counting the methods, the aliases are then on par with the > methods provided. It is 6:6. Honestly I don't like having > even another alias. > > my 2 cents > > Norbert > > > > On 1 Mar 2009, at 10:19, StÃ©phane Ducasse wrote: > > > > > Where? > > > It was not on lukas source and in the pharo inbox > > > Then there is the question to be sure if we want it. > > > > > > > > > On Mar 1, 2009, at 9:56 AM, Tudor Girba wrote: > > > > > >> Hi Stef, > > >> > > >>> Some more happy people :) > > >>> > > >>> - Announcements-lr.10 from souce.lukas-renggli.ch > > >>> Is when:do: not missing for compatibility with VW? > > >> > > >> I published a new version containing when:do: Announcements-tg.11. > > >> > > >> Cheers, > > >> Doru > > >> > > >> > > >>> > > >>> - Polymorph > > >>> Fix for button for currently selected window in tasklist not being > > >>> differentiated when using Watery 2 theme. > > >>> > > >>> - ContextPart argument > > >>> > > >>> - merged Issue 608: saveAsNewVersion uses deprecated method > > >>> > > >>> - Issue 614: > > >>> MessageTally broken when invoked from non-GUI process (e.g., in > > >>> Seaside code) > > >>> > > >>> > > >>> Now we should really kill more items for the milestone 1.0. > > >>> > > >>> Stef (now breakfast :) > > >>> > > >>> _______________________________________________ > > >>> Pharo-project mailing list > > >>> Pharo-project(a)lists.gforge.inria.fr > > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >> > > >> -- > > >> www.tudorgirba.com > > >> > > >> "Yesterday is a fact. > > >> Tomorrow is a possibility. > > >> Today is a challenge." > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> 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 > > > > -- > > www.tudorgirba.com > > > > "Be rather willing to give than demanding to get." > > > > > > > > > > _______________________________________________ > > 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

March 1, 2009

[Pharo-project] Swazoo 2.2 released

by Janko MivÅ¡ek

Dear Smalltalkers, After one year I'm glad to announce a new release 2.2 of Swazoo Smalltalk Web Server, currently just for Squeak and VisualWorks. What is new? * upload streaming 30 times better for large file uploads * additional improvements of streamed upload performance, as a result of a nice "competition" with GÃ¶ran Krampe doing the same on the Commance * two important classes renamed to avoid namespace clashes: Site to SwazooSite, Resource to SwazooResource * more reliable post data parsing * more and better tests * benchmarking support added. Detailed release notes: http://www.swazoo.org/release-notes-2.2.html Download page: http://www.swazoo.org/download.html Special thanks to Paolo Bonzini, Lautaro FernÃ¡ndez, Julian Fitzell, GÃ¶ran Krampe, Philippe Marschall and Stefan Schmiedl for your valuable inputs to this release! Best regards Janko MivÅ¡ek Swazoo maintainer

March 1, 2009

Re: [Pharo-project] Preference refactoring again

by Alain Plantec

StÃ©phane your previous question makes me think of a better solution with requires only one mandatory class and which makes use of standard event notification (without PreferenceCollector). I've joined 4 packages : - PrefCore contains PreferenceValue which is now the only mandatory class. 2 packages for testing: - PrefProvider contains PrefProvider class which declares some preferences - PrefUser contains PrefChangeListener (try PrefChangeListener test). 1 package for UI: - PrefTool contains PreferenceCollector and PreferenceDefinition. They are optional. Code below do not makes use of PreferenceCollector anymore: PrefChangeListener>>initialize super initialize. gradientLook := PrefProvider gradientButtonLook value. "reading of the preference value" "Using of standard event notification engine" PrefProvider when: #gradientButtonLook send: #gradientButtonLookIsNow: to: self. PrefProvider when: #gradientButtonLook send: #gradientLook: to: self. Now, the preference system only need PreferenceValue. PreferenceCollector and PreferenceDefinition are optional and can be brought by a preference supporting tool (UI). Previous version implied a dependency from PrefChangeListener to PreferenceCollector which was bad. PrefChangeListener>>initialize super initialize. gradientLook := PrefProvider gradientButtonLook value. PreferenceCollector whenChanged: #gradientButtonLook inClass: PrefProvider notify: self using: #gradientButtonLookIsNow: . PreferenceCollector whenChanged: #gradientButtonLook inClass: PrefProvider notify: self using: #gradientLook: alain StÃ©phane Ducasse a Ã©crit : > > sounds cool. > > For me the most important aspect is that preferenceCollector (our > > current preference class should be a removable layer on top > > of the system that are declaring preference. > > > > Is is correct that > > > > PreferenceCollector whenChanged: #gradientButtonLook inClass: > > PrefProvider notify: self using: #gradientButtonLookIsNow: . > > > > means that PrefProvider will receive the message > > gradientButtonLookIsNow: > no, but see the code below: ----------- PrefListener>>initialize super initialize. PreferenceCollector whenChanged: #gradientButtonLook inClass: PrefProvider notify: self using: #gradientButtonLookIsNow: . ----------- it means that a PrefListener instance will receive the #gradientButtonLookIsNow: message each time the preference #gradientButtonLook defined in class PrefProvider is changed. PrefListener and PrefProvider represent can be any class in the system. So, in order to read a preference value an object get it from the provider class by message sending, the provider is a class in a package which defines preferences (no need for PreferenceCollector to get the preference value). > > > > This way we can push preference to the tools > yes > > and thety do not have to query the information in the Collector at > > run-time > yes, Each package have its own preference set in it represented by a set of methods with pragma. When such a package is loaded, its preferences are automatically stored by PreferenceCollector. When a package is removed, its preferences are automatically removed from PreferenceCollector. PreferenceCollector is only here for supporting tools (cool UI ...) and for change notifications. > > (hence we could remove Preference and have a more OO design). > I guess yes. > > > > Sorry not to reply earlier (I was breaking yet another wall in our > > "kitchen") > bon courage :) alain > > > > Stef > > > > > > On Mar 1, 2009, at 10:05 AM, Alain Plantec wrote: > > > >> >> Hi all, >> >> >> >> joined Zoo package is a attempt to translate in code what we >> >> discussed here before about preference refactoring. >> >> >> >> The framework is made of 3 classes: PreferenceCollector, >> >> PreferenceDefinition and PreferenceValue. >> >> In Zoo there are also 2 classes for testing: PrefProvider and >> >> PrefChangeListener. >> >> PrefProvider class declares some preferences and PrefChangeListener >> >> is here to test preference change notification. >> >> >> >> PrefChangeListener>>initialize >> >> super initialize. >> >> PreferenceCollector whenChanged: #gradientButtonLook inClass: >> >> PrefProvider notify: self using: #gradientButtonLookIsNow: . >> >> PreferenceCollector whenChanged: #gradientButtonLook inClass: >> >> PrefProvider notify: self using: #gradientLook: >> >> >> >> PrefChangeListener class>>test >> >> "self test" >> >> PrefChangeListener new inspect. >> >> PrefProvider gradientButtonLook: PrefProvider gradientButtonLook >> >> value not. >> >> PrefProvider gradientButtonLook: PrefProvider gradientButtonLook >> >> value not. >> >> PrefProvider gradientButtonLook: PrefProvider gradientButtonLook >> >> value not. >> >> >> >> >> >> From PreferenceCollector comment: >> >> -------------------------------------- >> >> A PreferenceCollector automatically collects all preferences. >> >> A preference is represented by a PreferenceDefinition. >> >> All PreferenceDefinition are stored in the preferences instance >> >> variable. >> >> >> >> Instance Variables >> >> preferences: OrderedCollection of PreferenceDefinition >> >> >> >> preferences >> >> - contains all PreferenceDefinition which are automatically built >> >> from pragma found in preference getters >> >> >> >> >> >> ADDING A PREFERENCE >> >> PreferenceCollector makes use of the SystemChangeNotifier in order to >> >> automate the adding, the removing and the updating of preferences. >> >> See #PreferenceCollector>>event: to see how preferences update is >> >> implemented. >> >> >> >> Editing a new method with a preference pragma or inserting a >> >> preference pragma in an existing method are >> >> the two ways for preference definition adding. >> >> The only way to remove a preference definition is to remove the >> >> corresponding method. >> >> >> >> Example of a "blackAndWhite" preference. >> >> Methods below are defined by the preference provider >> >> APreferencePrivider class. >> >> Note that the value stored in BlackAndWhite class variable is an >> >> instance of PreferenceValue. >> >> In this example, the default value is directly given with the pragma: >> >> ------------- >> >> APreferencePrivider class>>blackAndWhite >> >> <preference: 'Use black and white' type: #Boolean set: >> >> #blackAndWhite: defaultValue: false description: 'Use black and white'> >> >> ^ BlackAndWhite >> >> ifNil: [BlackAndWhite := PreferenceValue value: false location: >> >> self selector: #blackAndWhite] >> >> >> >> APreferencePrivider class>>blackAndWhite: aBoolean >> >> self blackAndWhite value: aBoolean >> >> ------------- >> >> >> >> If a default value can't be specified in the pragma, another way >> >> consists in using a selector which >> >> represents the message to send to the class in order to get the >> >> default value: >> >> >> >> ------------- >> >> APreferencePrivider class>>standardFont >> >> <preference: 'The default system font' type: #LogicalFont set: >> >> #standardFont: default: #defaultStandardFont description: 'The >> >> default system font'> >> >> ^ StandardFont >> >> ifNil: [StandardFont := PreferenceValue value: self >> >> defaultStandardFont location: self selector: #standardFont] >> >> >> >> APreferencePrivider class>>standardFont: aFont >> >> self standardFont value: aFont >> >> APreferencePrivider class>>defaultStandardFont >> >> ^ LogicalFont >> >> familyName: 'Arial' >> >> fallbackFamilyNames: nil >> >> pointSize: 12 >> >> stretchValue: 5 >> >> weightValue: 400 >> >> slantValue: 0 >> >> ------------- >> >> >> >> LISTENING TO A PREFERENCE VALUE CHANGE >> >> Any object can register itself as a preference value change listener. >> >> See #PreferenceCollector class>>whenChanged: inClass:notify:using:. >> >> >> >> Each time a preference value is changed, #preference: >> >> inClass:changedWith: is sent to the PreferenceCollector class. >> >> >> >> Example of code a listener can implement in order to be notified each >> >> time a gradientButtonLook preference defined by a PrefProvider class >> >> is changed. >> >> In this example, the listener ask to be notified by a send of >> >> #gradientButtonLookIsNow: message. >> >> The argument given to gradientButtonLookIsNow: is the new preference >> >> value. >> >> ------------- >> >> .... >> >> PreferenceCollector whenChanged: #gradientButtonLook inClass: >> >> PrefProvider notify: self using: #gradientButtonLookIsNow:. >> >> .... >> >> ------------- >> >> >> >> What do you think ? >> >> >> >> cheers >> >> Alain >> >> >> >> >> >> <Zoo-alain_plantec.10.mcz>_______________________________________________ >> >> >> >> 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 alain

March 1, 2009

Re: [Pharo-project] Fwd: [ANN] 10245

by Schwab,Wilhelm K

Norbert, I agree re aliases, but only to a point. When trying to be compatible with other dialects, the aliases spare many other users from independently having to add them. When it is reasonable, I have no problem with it. This is another example of how nice it would be to have Dolphin's ability to apply multiple categories to a method; aliases can be flagged as such. Then they can be tested and maintained rather than having myriad ad hoc attempts to fill a gap between dialects. We have seen some complaints about lack of backward compatibility with Squeak. I have no desire to be hostile, but Pharo is the cleaning that Squeak has needed for several years; there will be side effects. If Pharo becomes what I think it will, there will be a time when things get back-ported to Squeak from Pharo. The difference is on one of purpose and degree. Are we trying desperately to fix Squeak and yet ensure that all of Pharo's improvements work perfectly on it? I consider that unlikely to work. If we are instead providing a few methods here or there that eliminate small incompatibilities, it is probably appropriate to add them and categorize them appropriately. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Norbert Hartl Sent: Sunday, March 01, 2009 8:13 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Fwd: [ANN] 10245 On Sun, 2009-03-01 at 10:47 +0100, Tudor Girba wrote: > I copied it to the repository of Lukas as well. > > Does anyone actually see a reason for not having the when:do: method > in as an alias to on:do:? I do not see it. > Because then there is on:do: subscribe:do: when:do: with all for: and send:to: variants. Counting the methods, the aliases are then on par with the methods provided. It is 6:6. Honestly I don't like having even another alias. my 2 cents Norbert > > On 1 Mar 2009, at 10:19, StÃ©phane Ducasse wrote: > > > Where? > > It was not on lukas source and in the pharo inbox > > Then there is the question to be sure if we want it. > > > > > > On Mar 1, 2009, at 9:56 AM, Tudor Girba wrote: > > > >> Hi Stef, > >> > >>> Some more happy people :) > >>> > >>> - Announcements-lr.10 from souce.lukas-renggli.ch > >>> Is when:do: not missing for compatibility with VW? > >> > >> I published a new version containing when:do: Announcements-tg.11. > >> > >> Cheers, > >> Doru > >> > >> > >>> > >>> - Polymorph > >>> Fix for button for currently selected window in tasklist not being > >>> differentiated when using Watery 2 theme. > >>> > >>> - ContextPart argument > >>> > >>> - merged Issue 608: saveAsNewVersion uses deprecated method > >>> > >>> - Issue 614: > >>> MessageTally broken when invoked from non-GUI process (e.g., in > >>> Seaside code) > >>> > >>> > >>> Now we should really kill more items for the milestone 1.0. > >>> > >>> Stef (now breakfast :) > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> -- > >> www.tudorgirba.com > >> > >> "Yesterday is a fact. > >> Tomorrow is a possibility. > >> Today is a challenge." > >> > >> > >> > >> > >> _______________________________________________ > >> 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 > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > > > _______________________________________________ > 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 1, 2009

Re: [Pharo-project] Fwd: [ANN] 10245

by StÃ©phane Ducasse

On Mar 1, 2009, at 10:47 AM, Tudor Girba wrote: > I copied it to the repository of Lukas as well. I did not see it when I did the release. > > > Does anyone actually see a reason for not having the when:do: method > in as an alias to on:do:? I do not see it. > > Cheers, > Doru > > > On 1 Mar 2009, at 10:19, StÃ©phane Ducasse wrote: > >> Where? >> It was not on lukas source and in the pharo inbox >> Then there is the question to be sure if we want it. >> >> >> On Mar 1, 2009, at 9:56 AM, Tudor Girba wrote: >> >>> Hi Stef, >>> >>>> Some more happy people :) >>>> >>>> - Announcements-lr.10 from souce.lukas-renggli.ch >>>> Is when:do: not missing for compatibility with VW? >>> >>> I published a new version containing when:do: Announcements-tg.11. >>> >>> Cheers, >>> Doru >>> >>> >>>> >>>> - Polymorph >>>> Fix for button for currently selected window in tasklist not being >>>> differentiated when using Watery 2 theme. >>>> >>>> - ContextPart argument >>>> >>>> - merged Issue 608: saveAsNewVersion uses deprecated method >>>> >>>> - Issue 614: >>>> MessageTally broken when invoked from non-GUI process (e.g., in >>>> Seaside code) >>>> >>>> >>>> Now we should really kill more items for the milestone 1.0. >>>> >>>> Stef (now breakfast :) >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> -- >>> www.tudorgirba.com >>> >>> "Yesterday is a fact. >>> Tomorrow is a possibility. >>> Today is a challenge." >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 1, 2009

Re: [Pharo-project] Fwd: [ANN] 10245

by Norbert Hartl

On Sun, 2009-03-01 at 10:47 +0100, Tudor Girba wrote: > I copied it to the repository of Lukas as well. > > Does anyone actually see a reason for not having the when:do: method > in as an alias to on:do:? I do not see it. > Because then there is on:do: subscribe:do: when:do: with all for: and send:to: variants. Counting the methods, the aliases are then on par with the methods provided. It is 6:6. Honestly I don't like having even another alias. my 2 cents Norbert > > On 1 Mar 2009, at 10:19, StÃ©phane Ducasse wrote: > > > Where? > > It was not on lukas source and in the pharo inbox > > Then there is the question to be sure if we want it. > > > > > > On Mar 1, 2009, at 9:56 AM, Tudor Girba wrote: > > > >> Hi Stef, > >> > >>> Some more happy people :) > >>> > >>> - Announcements-lr.10 from souce.lukas-renggli.ch > >>> Is when:do: not missing for compatibility with VW? > >> > >> I published a new version containing when:do: Announcements-tg.11. > >> > >> Cheers, > >> Doru > >> > >> > >>> > >>> - Polymorph > >>> Fix for button for currently selected window in tasklist not being > >>> differentiated when using Watery 2 theme. > >>> > >>> - ContextPart argument > >>> > >>> - merged Issue 608: saveAsNewVersion uses deprecated method > >>> > >>> - Issue 614: > >>> MessageTally broken when invoked from non-GUI process (e.g., in > >>> Seaside code) > >>> > >>> > >>> Now we should really kill more items for the milestone 1.0. > >>> > >>> Stef (now breakfast :) > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> -- > >> www.tudorgirba.com > >> > >> "Yesterday is a fact. > >> Tomorrow is a possibility. > >> Today is a challenge." > >> > >> > >> > >> > >> _______________________________________________ > >> 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 > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 1, 2009