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

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by Igor Stasenko

2009/11/1 Lukas Renggli <renggli(a)gmail.com>: >> In current core image, Announcements is quite small (just around 10 >> methods totally) and i doubt it provides enough >> flexibility which would not require adding & reinventing additional >> useful stuff on top of it. > > I have used these announcements in many large projects and I never > needed to add anything. In fact, I would even vote to remove > AnnouncementSet as I never used it or saw it used anywhere. Initially, > I found it cool because the same trick is applied in the Exception > hierarchy. Major projects like OmniBrowser (and to some extent also > Seaside) use an even smaller subset of the functionality provided in > the core package. > > The only thing that is maybe missing are weak announcements. I guess > that could be useful, if Pharo provided a solid implementation of weak > objects. > Announcements is just another implementation of observer pattern. And given that its quite simple to (re)implement by own, obviously, the question is, why anyone would want to use Announcements instead of making own? If Announcements provides more wide functionality in addition to observer pattern - then yes, you could say: it is better because in addition you have this and that. But if it so stripped to bare-bones, then where the benefits to use exactly Announcements? > Lukas > > -- > 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 > -- Best regards, Igor Stasenko AKA sig.

Oct. 31, 2009

Re: [Pharo-project] [update 1.1] #11020

by Nicolas Cellier

OK, I see I a regression of http://bugs.squeak.org/view.php?id=6695 Float storeStringBase: does not store the radix Good thing to have tests :) I merge the two fixes in PharoInbox/Kernel-nice.454 Nicolas 2009/10/31 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > What is RPackage ? > It seems to cause a failure during upgrade > > 2009/10/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> nicolas >> >> could you check because I have some tests that fail on Float. >> >> stef >> On Oct 31, 2009, at 8:49 PM, StÃ©phane Ducasse wrote: >> >>> 11020 >>> ----- >>> >>> - Issue 1387: Mantis 7409 arcTan: has a specific implementation near >>> zero and negativeZero >>> Â Â Â Test and patch for http://code.google.com/p/pharo/issues/detail?id=1387 >>> http://bugs.squeak.org/view.php?id=7409 >>> Â Â Â make arcTan: behave like libm atan2 near zero and negativeZero >>> >>> - Â Issue 1390: Â Â Â Â Print literals exactly when decompiled >>> >>> - Â Issue 1388: Â Â Â Â FixedIdentitySet #arraySize has no senders >>> >>> - Issue 1331: DNU upon file-in of changeset >>> >>> >>> 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 >> >

Oct. 31, 2009

Re: [Pharo-project] [update 1.1] #11020

by Nicolas Cellier

What is RPackage ? It seems to cause a failure during upgrade 2009/10/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > nicolas > > could you check because I have some tests that fail on Float. > > stef > On Oct 31, 2009, at 8:49 PM, StÃ©phane Ducasse wrote: > >> 11020 >> ----- >> >> - Issue 1387: Mantis 7409 arcTan: has a specific implementation near >> zero and negativeZero >> Â Â Â Test and patch for http://code.google.com/p/pharo/issues/detail?id=1387 >> http://bugs.squeak.org/view.php?id=7409 >> Â Â Â make arcTan: behave like libm atan2 near zero and negativeZero >> >> - Â Issue 1390: Â Â Â Â Print literals exactly when decompiled >> >> - Â Issue 1388: Â Â Â Â FixedIdentitySet #arraySize has no senders >> >> - Issue 1331: DNU upon file-in of changeset >> >> >> 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 >

Oct. 31, 2009

Re: [Pharo-project] Author = TestRunner

by Henrik Sperre Johansen

It happens for instance if you click one of the failing tests after intially running tests, then fix the bug in the debugger that pops up. (i.e., you're comitting changes while the test is being run). Cheers, Henry On 31.10.2009 18:31, Adrian Lienhard wrote: > If I understand you correctly, the author is permanently set to > 'TestRunner' after running tests? > > Do you know which tests cause the problem? Reverting to the original > author is done in an ensure block, so I don't see how that can go > wrong right now. > > Adrian > > On Oct 29, 2009, at 20:57 , StÃ©phane Ducasse wrote: > > >> apparently there is a bad interaction between the test runner and the >> author >> because from time to time I get author = TestRunner >> Probably the runner code is not robust enough in case of failure >> capture or something like that. >> >> >> runCase >> Author >> useAuthor: 'TestRunner' >> during: [ >> [self setUp. >> self performTest] >> ensure: [ >> self tearDown. >> self cleanUpInstanceVariables ] ] >> >> _______________________________________________ >> 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 > > >

Oct. 31, 2009

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by Lukas Renggli

> In current core image, Announcements is quite small (just around 10 > methods totally) and i doubt it provides enough > flexibility which would not require adding & reinventing additional > useful stuff on top of it. I have used these announcements in many large projects and I never needed to add anything. In fact, I would even vote to remove AnnouncementSet as I never used it or saw it used anywhere. Initially, I found it cool because the same trick is applied in the Exception hierarchy. Major projects like OmniBrowser (and to some extent also Seaside) use an even smaller subset of the functionality provided in the core package. The only thing that is maybe missing are weak announcements. I guess that could be useful, if Pharo provided a solid implementation of weak objects. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 31, 2009

Re: [Pharo-project] Bitten by MethodReference

by StÃ©phane Ducasse

this is why in 1.0 I started to make sure that we could have CM and MR polymorphic at least to access information: methodClass selector Stef On Oct 31, 2009, at 10:17 PM, Igor Stasenko wrote: > 2009/10/31 Adrian Lienhard <adi(a)netstyle.ch>: >> I think that a main reason for using MethodReference was to be able >> to >> capture the class in which a method is installed and the method's >> selector. Before method properties were introduced, a method did not >> know its class and selector and hence all classes had to be searched >> to find this out (the method was named #who returning an array with >> the class and selector ;)). >> >> I don't see any reason why MethodReference would still be useful as >> you can just reference a CompiledMethod directly. >> > > The MethodReference abstraction, useful for tools, which > don't need to go deep into CompiledMethod's details and just need to > present a source code. > With careful implementation, we can use same tools for browsing > methods installed in system, > as well as MC packages or files on disk, or remote object memory. > Without such abstraction, tools will be limited only for presenting > currently existing classes & methods installed in system. > > So generally, it is good thing. But in current form it having > shortcomings, which need to be fixed. > >> Adrian >> >> On Oct 31, 2009, at 13:59 , Igor Stasenko wrote: >> >>> 2009/10/29 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> Hi >>>> >>>> just to share a ugly design point with MethodReference >>>> >>>> MethodReference are created using >>>> >>>> MethodReference class: aClass symbol: aSymbol >>>> >>>> however they store the class ***name*** >>>> >>>> and after when you query the class using either actualClass or >>>> methodClass >>>> you get the class that is in Smalltalk. >>>> >>>> So if like me you copied the class then you will get another >>>> version >>>> of your class >>>> even if this is the right one you use to create the >>>> MethodReference.... >>>> >>>> One of these days we will have to check that >>>> >>> >>> Yes, i wondering myself, what is the point to reference the >>> methods in >>> such style. >>> The way, how actual class & its method get resolved makes it >>> impossible to reference a method in >>> arbitrary class object, especially one which is not installed into >>> system dictionary. >>> >>> I think its lacking additional form of indirection, which should >>> be an >>> environment object who is responsible for >>> delivering the method's source code along with resolving the class >>> by >>> its name. Without such indirection, i see no point in having a >>> MethodReference per se, >>> because you can always do the same thing by yourself , i.e. >>> (Smalltalk >>> at: #SomeClass) methodDict at: #someSelector. >>> Without that, i see no point why i would want to use it, because it >>> always points to same thing, no matter where i using the >>> MethodReference. >>> >>>> Stef >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 31, 2009

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by StÃ©phane Ducasse

I think that Axa needs a good cleaning brush. So let us see what we can get. Stef On Oct 31, 2009, at 10:23 PM, Igor Stasenko wrote: > 2009/10/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> This could be a possibility now I think that this is nice that people >> get a chance to check it and discuss. >> > > yes, please decide. :) Because from that decision, we could then plan > a new system-change annoucements layer > + package system. > In current core image, Announcements is quite small (just around 10 > methods totally) and i doubt it provides enough > flexibility which would not require adding & reinventing additional > useful stuff on top of it. > > >> Stef >> >> On Oct 31, 2009, at 10:02 PM, Igor Stasenko wrote: >> >>> AXAnnouncements is pretty small and accompanied with tests. >>> So why not integrate it + removing 'AX' prefix because, as decided >>> previously, >>> it should be in Pharo core? >>> >>> 2009/10/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> what would be good is to have a small discussion on the key and >>>> minimal features that could be added to Announcements, >>>> add some tests and code. >>>> >>>> Stef >>>> On Oct 31, 2009, at 5:17 PM, StÃ©phane Ducasse wrote: >>>> >>>>> Levente >>>>> >>>>> what I would really love :) >>>>> is if you could provide some extensions to the new version based >>>>> on >>>>> your experience. >>>>> I think that Announcements are a bit limited right now. Then the >>>>> core >>>>> would be enhanced and we >>>>> could clarified the license. >>>>> >>>>> Stef >>>>> >>>>> On Oct 30, 2009, at 1:25 AM, Levente Uzonyi wrote: >>>>> >>>>>> Hi! >>>>>> >>>>>> Just to make things clear, AXAnnouncements >>>>>> - is not "a port of the original announcement implementation" >>>>>> - is (more or less) based on Vassili Bykov's blog >>>>>> (http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?searchCategory=Ann… >>>>>> ) >>>>>> just like the Announcements package in Pharo >>>>>> - is released under the MIT license (http://www.squeaksource.com/AXAnnouncements.html >>>>>> ). >>>>>> We implemented the framework as the blog entries came out and >>>>>> integrated >>>>>> it into our rudimentary ajax framework (that's where the AX >>>>>> prefix >>>>>> came >>>>>> from). Later we abandoned the ajax framework but found >>>>>> announcements >>>>>> really useful (especially with seaside components), so we >>>>>> extracted >>>>>> the >>>>>> code and moved it to squeaksource. Our ajax framework demo was >>>>>> available >>>>>> at http://axdemo.seasidehosting.st/. >>>>>> >>>>>> For a quick comparison: AXAnnouncements is bloated and has lower >>>>>> code >>>>>> quality than Announcements, but it implements more features, like >>>>>> suspension and interception of announcements, weak subscriptions >>>>>> and >>>>>> allows different base class for the announcements hierarchy per >>>>>> announcer. >>>>>> >>>>>> Cheers, >>>>>> Levente >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 31, 2009

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by Igor Stasenko

2009/10/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > This could be a possibility now I think that this is nice that people > get a chance to check it and discuss. > yes, please decide. :) Because from that decision, we could then plan a new system-change annoucements layer + package system. In current core image, Announcements is quite small (just around 10 methods totally) and i doubt it provides enough flexibility which would not require adding & reinventing additional useful stuff on top of it. > Stef > > On Oct 31, 2009, at 10:02 PM, Igor Stasenko wrote: > >> AXAnnouncements is pretty small and accompanied with tests. >> So why not integrate it + removing 'AX' prefix because, as decided >> previously, >> it should be in Pharo core? >> >> 2009/10/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> what would be good is to have a small discussion on the key and >>> minimal features that could be added to Announcements, >>> add some tests and code. >>> >>> Stef >>> On Oct 31, 2009, at 5:17 PM, StÃ©phane Ducasse wrote: >>> >>>> Levente >>>> >>>> what I would really love :) >>>> is if you could provide some extensions to the new version based on >>>> your experience. >>>> I think that Announcements are a bit limited right now. Then the >>>> core >>>> would be enhanced and we >>>> could clarified the license. >>>> >>>> Stef >>>> >>>> On Oct 30, 2009, at 1:25 AM, Levente Uzonyi wrote: >>>> >>>>> Hi! >>>>> >>>>> Just to make things clear, AXAnnouncements >>>>> - is not "a port of the original announcement implementation" >>>>> - is (more or less) based on Vassili Bykov's blog >>>>> Â (http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?searchCategory=Ann… >>>>> ) >>>>> Â just like the Announcements package in Pharo >>>>> - is released under the MIT license (http://www.squeaksource.com/AXAnnouncements.html >>>>> ). >>>>> We implemented the framework as the blog entries came out and >>>>> integrated >>>>> it into our rudimentary ajax framework (that's where the AX prefix >>>>> came >>>>> from). Later we abandoned the ajax framework but found >>>>> announcements >>>>> really useful (especially with seaside components), so we extracted >>>>> the >>>>> code and moved it to squeaksource. Our ajax framework demo was >>>>> available >>>>> at http://axdemo.seasidehosting.st/. >>>>> >>>>> For a quick comparison: AXAnnouncements is bloated and has lower >>>>> code >>>>> quality than Announcements, but it implements more features, like >>>>> suspension and interception of announcements, weak subscriptions >>>>> and >>>>> allows different base class for the announcements hierarchy per >>>>> announcer. >>>>> >>>>> Cheers, >>>>> Levente >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Oct. 31, 2009

Re: [Pharo-project] Bitten by MethodReference

by Igor Stasenko

2009/10/31 Adrian Lienhard <adi(a)netstyle.ch>: > I think that a main reason for using MethodReference was to be able to > capture the class in which a method is installed and the method's > selector. Before method properties were introduced, a method did not > know its class and selector and hence all classes had to be searched > to find this out (the method was named #who returning an array with > the class and selector ;)). > > I don't see any reason why MethodReference would still be useful as > you can just reference a CompiledMethod directly. > The MethodReference abstraction, useful for tools, which don't need to go deep into CompiledMethod's details and just need to present a source code. With careful implementation, we can use same tools for browsing methods installed in system, as well as MC packages or files on disk, or remote object memory. Without such abstraction, tools will be limited only for presenting currently existing classes & methods installed in system. So generally, it is good thing. But in current form it having shortcomings, which need to be fixed. > Adrian > > On Oct 31, 2009, at 13:59 , Igor Stasenko wrote: > >> 2009/10/29 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> Hi >>> >>> just to share a ugly design point with MethodReference >>> >>> MethodReference are created using >>> >>> MethodReference class: aClass symbol: aSymbol >>> >>> however they store the class ***name*** >>> >>> and after when you query the class using either actualClass or >>> methodClass >>> you get the class that is in Smalltalk. >>> >>> So if like me you copied the class then you will get another version >>> of your class >>> even if this is the right one you use to create the >>> MethodReference.... >>> >>> One of these days we will have to check that >>> >> >> Yes, i wondering myself, what is the point to reference the methods in >> such style. >> The way, how actual class & its method get resolved makes it >> impossible to reference a method in >> arbitrary class object, especially one which is not installed into >> system dictionary. >> >> I think its lacking additional form of indirection, which should be an >> environment object who is responsible for >> delivering the method's source code along with resolving the class by >> its name. Without such indirection, i see no point in having a >> MethodReference per se, >> because you can always do the same thing by yourself , i.e. (Smalltalk >> at: #SomeClass) methodDict at: #someSelector. >> Without that, i see no point why i would want to use it, because it >> always points to same thing, no matter where i using the >> MethodReference. >> >>> Stef >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Oct. 31, 2009

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by StÃ©phane Ducasse

This could be a possibility now I think that this is nice that people get a chance to check it and discuss. Stef On Oct 31, 2009, at 10:02 PM, Igor Stasenko wrote: > AXAnnouncements is pretty small and accompanied with tests. > So why not integrate it + removing 'AX' prefix because, as decided > previously, > it should be in Pharo core? > > 2009/10/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> what would be good is to have a small discussion on the key and >> minimal features that could be added to Announcements, >> add some tests and code. >> >> Stef >> On Oct 31, 2009, at 5:17 PM, StÃ©phane Ducasse wrote: >> >>> Levente >>> >>> what I would really love :) >>> is if you could provide some extensions to the new version based on >>> your experience. >>> I think that Announcements are a bit limited right now. Then the >>> core >>> would be enhanced and we >>> could clarified the license. >>> >>> Stef >>> >>> On Oct 30, 2009, at 1:25 AM, Levente Uzonyi wrote: >>> >>>> Hi! >>>> >>>> Just to make things clear, AXAnnouncements >>>> - is not "a port of the original announcement implementation" >>>> - is (more or less) based on Vassili Bykov's blog >>>> (http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?searchCategory=Ann… >>>> ) >>>> just like the Announcements package in Pharo >>>> - is released under the MIT license (http://www.squeaksource.com/AXAnnouncements.html >>>> ). >>>> We implemented the framework as the blog entries came out and >>>> integrated >>>> it into our rudimentary ajax framework (that's where the AX prefix >>>> came >>>> from). Later we abandoned the ajax framework but found >>>> announcements >>>> really useful (especially with seaside components), so we extracted >>>> the >>>> code and moved it to squeaksource. Our ajax framework demo was >>>> available >>>> at http://axdemo.seasidehosting.st/. >>>> >>>> For a quick comparison: AXAnnouncements is bloated and has lower >>>> code >>>> quality than Announcements, but it implements more features, like >>>> suspension and interception of announcements, weak subscriptions >>>> and >>>> allows different base class for the announcements hierarchy per >>>> announcer. >>>> >>>> Cheers, >>>> Levente >>>> >>>> _______________________________________________ >>>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 31, 2009