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

Re: [Pharo-project] [MC] Adding a constraint when declaring a required package

by StÃ©phane Ducasse

I lukas I see that you group together all the tests and I would prefer to have test associate with the package they test. stef On Oct 12, 2008, at 11:46 AM, Lukas Renggli wrote: >> In Visualworks there is no dash convention, which is much better... > > This might be interesting in the context of discussion: > > We documented the package naming conventions for Seaside 2.9 here: > > http://code.google.com/p/seaside/wiki/PackageNaming > > The complete list of packages is documented here: > > http://code.google.com/p/seaside/wiki/LoadOrder > > When following these conventions there are no conflicts. The dashes > are there to separate the different concerns of the name. We don't use > meta-packages (-All), because every developer has a different set of > packages anyway. > > Cheers, > Lukas > > > > >> >> Cheers, >> 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 >> > > > > -- > 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 >

Oct. 12, 2008

Re: [Pharo-project] [MC] Adding a constraint when declaring a required package

by StÃ©phane Ducasse

The problem is that you cannot forbid that now. Or do you? what is the impact of forbidden that now on existing code? Stef On Oct 12, 2008, at 11:19 AM, Alexandre Bergel wrote: > Let me put it in another way. > Is there a situation where a package named MyPackage should require > another package MyPackage-Foo. > As we experienced, this evil dependency brings inconsistencies when > saving MyPackage. > > What would it a nice way to prevent such situation ? > >> I imagine that this is to avoid mistake like >> Moose >> Moose-X >> Moose-Y >> >> and that people do it >> Moose-All >> Moose-X >> Moose-Y > > Even these situations are not clean. > We should have > MooseAll > MooseX > MooseY > > I do not see a reason to have a - within the name. this is just a character as any other. So I would not do anything special with it. > > > If you have 3 class categories: > Moose > Moose-X > Moose-Y > > It means that the package Moose contains Moose-X and Moose-Y > definitions > > In Visualworks there is no dash convention, which is much better... > > Cheers, > 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 >

Oct. 12, 2008

Re: [Pharo-project] Pharo image size: 10.9MB

by Alexandre Bergel

Excellent Adrian. For String, a similar expression does it: ByteString allInstances asSortedCollection: [ :e1 :e2 | e1 size >= e2 size ] ByteString allInstances inject: 0 into: [:sum :el | sum + el size] The total amount of strings is 1,533,483 bytes Interesting: (ByteString allInstances select: [:s | s = '']) size ==> 601 Cheers, Alexandre On 11 Oct 2008, at 21:20, StÃ©phane Ducasse wrote: > excellent! > I would be also curious about the size of the strings. > And yes > - we need to have a cleanup process as proposed/examplified by keith > > For the default fonts: do we have a process to reload the non > default fonts? > > Stef > > On Oct 11, 2008, at 8:11 PM, Adrian Lienhard wrote: > >> I've been looking into how the current 13.4MB a Pharo image uses >> are spent... I expected that at least half of it is used by classes >> (compiled methods). But this is not the case. Actually, only about >> 1/4th are classes. As it turned out, almost the same amount of >> memory is used by forms (actually bitmaps)! >> >> If you want to know which are the largest 10 forms try this: >> >> (Form allInstances asSortedCollection: [ :e1 :e2 | e1 bits size >= >> e2 bits size ]) from: 1 to: 10 do: [ :each | each asMorph >> openInWorld ] >> >> ...among which for example are 4 different color pickers. In total >> there are around 450 forms, most from EToys. I've manually traced >> down where the larger forms come from and have cleaned up those >> that were possible (many are only referenced by caches). The number >> of forms is at 320 now. >> >> In the process I produced the script below, which among other stuff >> removes all but the default font. Also, it actually removes the >> flaps from the system instead of only hiding them. Here a history >> of image sizes: >> >> Squeak 3.9: 15.6 MB >> Pharo 10091: 13.4MB (before cleanup) >> Pharo 10091: 10.9MB (after cleanup) >> >> Main conclusion: the system needs cleanup not only of the code >> (where the mess is more directly visible), but also of the object >> memory. Furthermore, I expect removing EToys will have an nice >> impact on the image size. Also removing Sound will release some >> memory because of sound samples. >> >> If anybody has suggestions to further reduce the image size (<10MB >> would be a nice target for the first release...), please let me know. >> >> Cheers, >> Adrian >> >> >> >> Preferences setDefaultFonts: #( >> (setSystemFontTo: 'Accuny' 10) >> (setListFontTo: 'Accuny' 10) >> (setMenuFontTo: 'Accuny' 10) >> (setFlapsFontTo: 'Accuny' 12) >> (setEToysFontTo: 'Accuny' 10) >> (setPaintBoxButtonFontTo: 'Accuny' 10) >> (setWindowTitleFontTo: 'Accuny' 15) >> (setBalloonHelpFontTo: 'Accuny' 10) >> (setCodeFontTo: 'Accuny' 10) >> (setButtonFontTo: 'Accuny' 8)). >> TextConstants associations do: [ :association | >> ((association value isKindOf: TextStyle) >> and: [ association key ~= #Accuny ] >> and: [ (TextStyle defaultFamilyNames includes: association key) >> not ]) >> ifTrue: [ TextConstants removeKey: association key ]]. >> TextConstants at: #DefaultFixedTextStyle put: (TextConstants at: >> #Accuny). >> >> (Flaps classPool at: #SharedFlapTabs) removeAllSuchThat: [ :each | >> (#(Tools Pharo) includes: each labelString) not ]. >> NaturalLanguageFormTranslator classPool at: #CachedTranslations >> put: nil. >> NaturalLanguageTranslator resetCaches. >> PartsBin clearThumbnailCache. >> PaintBoxMorph initialize. >> PaintBoxMorph classPool at: #ColorChart put: nil; at: #Prototype >> put: nil. >> Utilities classPool at: #ScrapsBook put: nil. >> Project allInstancesDo: [ :each | each setThumbnail: nil ]. >> InternalThreadNavigationMorph clearThumbnailCache. >> ScriptingSystem stripGraphicsForExternalRelease. >> ProjectHistory currentHistory initialize. >> Utilities zapUpdateDownloader. >> Smalltalk forgetDoIts. >> Behavior flushObsoleteSubclasses. >> CommandHistory allInstancesDo: #initialize. >> ScriptLoader new cleaningCS. >> RequiredSelectors initialize. >> ProvidedSelectors initialize. >> LocalSends initialize. >> SendCaches initializeAllInstances. >> Utilities cleanseOtherworldlySteppers. >> Smalltalk organization removeEmptyCategories. >> SystemBrowser removeObsolete. >> TheWorldMenu removeObsolete. >> AppRegistry removeObsolete. >> FileServices removeObsolete. >> SystemNavigation default obsoleteBehaviors. >> MCFileBasedRepository flushAllCaches. >> MCDefinition clearInstances. >> Undeclared removeUnreferencedKeys. >> Smalltalk flushClassNameCache. >> 3 timesRepeat: [ Smalltalk garbageCollect. Symbol >> compactSymbolTable ]. >> Set rehashAllSets. >> Smalltalk garbageCollect. >> >> >> ___________________ >> http://www.adrian-lienhard.ch/ >> >> _______________________________________________ >> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 12, 2008

Re: [Pharo-project] [MC] Adding a constraint when declaring a required package

by Alexandre Bergel

It makes sense. But in that setting, creating a package named 'Seaside' and beginning to add some Seaside-... packages as required would be disastrous. No? But maybe I am missing something here... Cheers, Alexandre On 12 Oct 2008, at 11:46, Lukas Renggli wrote: >> In Visualworks there is no dash convention, which is much better... > > This might be interesting in the context of discussion: > > We documented the package naming conventions for Seaside 2.9 here: > > http://code.google.com/p/seaside/wiki/PackageNaming > > The complete list of packages is documented here: > > http://code.google.com/p/seaside/wiki/LoadOrder > > When following these conventions there are no conflicts. The dashes > are there to separate the different concerns of the name. We don't use > meta-packages (-All), because every developer has a different set of > packages anyway. > > Cheers, > Lukas > > > > >> >> Cheers, >> 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 >> > > > > -- > 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 12, 2008

Re: [Pharo-project] History and SUnit

by Alexandre Bergel

Thanks for your feedback. >> Result is displayed in the Transcript. Sorry to not have said it >> before. > > oh, I see. Yes, this seems to be a really useful feature! > What is the difference between storing the result via the "History" > button vs. "Store result into classes". Then also the results of > "show diff" and "Show Progress" are almost the same. I guess this > is to make it possible to store the results with the code. It seems > to me that this could be simplified... It is probably not well done. But the idea is to have two granularities of history: - one during the session: a programmer can see its progress since its last run - one persistent: a programmer can see its progress since the last commit The History button actually save the result in the TestRunner, and not in the classes. It means that if you close your testrunner, you loose your history. 'Store result into classes' creates methods in the test cases that contains the results when you stored it. It is therefore persistent. >> We though first about opening a workspace with the result inside, >> but I did not find an easy way to do it. So, for now, it prints in >> the Transcript. > > If you want to open a workspace you can do it like this: Workspace > new contents: 'foo'; openLabel: 'SUnit Progress' Excellent, the change is waiting in PharoInbox. SUnitGUI-AlexandreBergel.13 > I think the feature should be more intuitive so that a user can > figure out how it works just by trying it out. Wouldn't the > following 2 actions be sufficient for most cases: 'Remember Result', > 'Compare Result'? You would always only remember one result and no > diff selection and history deleting would be necessary. The > usability would increase because you would go down from 8 possible > user actions to 2. It makes sense. I do not have problem to remove the 'history' button, and to keep (and rename) 'Remember Result', 'Compare Result'. I was just wondering whether having a local in time history and a persistent one would make sense. We could only keep the latter. Cheers, Alexandre > > >> Cheers, >> Alexandre >> >>> >>> On Oct 1, 2008, at 16:56 , Alexandre Bergel wrote: >>> >>>> Dear list, >>>> >>>> In PharoInbox Gwenael and I put an extension of SUnit that >>>> records results when running a set of test. >>>> Feel free to suggest improvement.... >>>> >>>> Open a TestRunner to enjoy its 'History' button. >>>> >>>> Cheers, >>>> 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 >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 12, 2008

Re: [Pharo-project] [MC] Adding a constraint when declaring a required package

by Lukas Renggli

> In Visualworks there is no dash convention, which is much better... This might be interesting in the context of discussion: We documented the package naming conventions for Seaside 2.9 here: http://code.google.com/p/seaside/wiki/PackageNaming The complete list of packages is documented here: http://code.google.com/p/seaside/wiki/LoadOrder When following these conventions there are no conflicts. The dashes are there to separate the different concerns of the name. We don't use meta-packages (-All), because every developer has a different set of packages anyway. Cheers, Lukas > > Cheers, > 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 > -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 12, 2008

Re: [Pharo-project] [MC] Adding a constraint when declaring a required package

by Alexandre Bergel

Let me put it in another way. Is there a situation where a package named MyPackage should require another package MyPackage-Foo. As we experienced, this evil dependency brings inconsistencies when saving MyPackage. What would it a nice way to prevent such situation ? > I imagine that this is to avoid mistake like > Moose > Moose-X > Moose-Y > > and that people do it > Moose-All > Moose-X > Moose-Y Even these situations are not clean. We should have MooseAll MooseX MooseY I do not see a reason to have a - within the name. If you have 3 class categories: Moose Moose-X Moose-Y It means that the package Moose contains Moose-X and Moose-Y definitions In Visualworks there is no dash convention, which is much better... Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 12, 2008

Re: [Pharo-project] [MC] Adding a constraint when declaring a required package

by StÃ©phane Ducasse

Alex I imagine that this is to avoid mistake like Moose Moose-X Moose-Y and that people do it Moose-All Moose-X Moose-Y If this is what you have in mind how would it work from a process point of view 1- I create Moose 2- I create Moose-XXX -> wanring 3- remove/rename Moose -> Moose-All then be able to create Moose-XXX This scenario would be realllllly important because we can really screw up MC packges with overlapping packages Scenario 2 1 - I have Moose 2- I load Moose-XXX PS: if you want to have feedback from people, they should not know what you are implying in advance like me. On Oct 11, 2008, at 12:19 PM, Alexandre Bergel wrote: > Maybe we should forbid a package XXX-YYY to be required for a > package named XXX > What do you think? > A simple check will do it... > > Cheers, > 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 >

Oct. 12, 2008

Re: [Pharo-project] History and SUnit

by StÃ©phane Ducasse

good feedback. This means that soon we will also be able to run test server and systematically and easily know if we made progress or not. Now we may face the problem that running the tests make the packages dirty. Stef > Hi Alex, > > On Oct 10, 2008, at 13:25 , Alexandre Bergel wrote: > >>> I tried your extension and have the following questions/problems: >>> - when I first run all the tests in the system, I get 4 failures >>> (as expected) but the bar on top stays green where it should be >>> yellow (it worked before) >> >> that's strange. I run all the test, and it turns yellow saying: >> "10 October 2008 1:07:37 pm 2286 run, 2279 passes, 4 expected >> failures, 3 failures, 0 errors, 0 unexpected passes" > > ok, I downloaded a fresh image and updated to 10091 and now it also > works for me. > >>> - I don't understand the "Progress" feature. What I did is run the >>> tests, then "Store results", then I fixed a failing test, then >>> "Run Failures", then "Show progress". But nothing happens. Maybe I >>> did something wrong? >> >> Result is displayed in the Transcript. Sorry to not have said it >> before. > > oh, I see. Yes, this seems to be a really useful feature! > What is the difference between storing the result via the "History" > button vs. "Store result into classes". Then also the results of > "show diff" and "Show Progress" are almost the same. I guess this > is to make it possible to store the results with the code. It seems > to me that this could be simplified... > >> We though first about opening a workspace with the result inside, >> but I did not find an easy way to do it. So, for now, it prints in >> the Transcript. > > If you want to open a workspace you can do it like this: Workspace > new contents: 'foo'; openLabel: 'SUnit Progress' > > I think the feature should be more intuitive so that a user can > figure out how it works just by trying it out. Wouldn't the > following 2 actions be sufficient for most cases: 'Remember Result', > 'Compare Result'? You would always only remember one result and no > diff selection and history deleting would be necessary. The > usability would increase because you would go down from 8 possible > user actions to 2. > > Cheers, > Adrian > > > >> Cheers, >> Alexandre >> >>> >>> On Oct 1, 2008, at 16:56 , Alexandre Bergel wrote: >>> >>>> Dear list, >>>> >>>> In PharoInbox Gwenael and I put an extension of SUnit that >>>> records results when running a set of test. >>>> Feel free to suggest improvement.... >>>> >>>> Open a TestRunner to enjoy its 'History' button. >>>> >>>> Cheers, >>>> 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 >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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. 12, 2008

Re: [Pharo-project] History and SUnit

by Adrian Lienhard

Hi Alex, On Oct 10, 2008, at 13:25 , Alexandre Bergel wrote: >> I tried your extension and have the following questions/problems: >> - when I first run all the tests in the system, I get 4 failures >> (as expected) but the bar on top stays green where it should be >> yellow (it worked before) > > that's strange. I run all the test, and it turns yellow saying: > "10 October 2008 1:07:37 pm 2286 run, 2279 passes, 4 expected > failures, 3 failures, 0 errors, 0 unexpected passes" ok, I downloaded a fresh image and updated to 10091 and now it also works for me. >> - I don't understand the "Progress" feature. What I did is run the >> tests, then "Store results", then I fixed a failing test, then "Run >> Failures", then "Show progress". But nothing happens. Maybe I did >> something wrong? > > Result is displayed in the Transcript. Sorry to not have said it > before. oh, I see. Yes, this seems to be a really useful feature! What is the difference between storing the result via the "History" button vs. "Store result into classes". Then also the results of "show diff" and "Show Progress" are almost the same. I guess this is to make it possible to store the results with the code. It seems to me that this could be simplified... > We though first about opening a workspace with the result inside, > but I did not find an easy way to do it. So, for now, it prints in > the Transcript. If you want to open a workspace you can do it like this: Workspace new contents: 'foo'; openLabel: 'SUnit Progress' I think the feature should be more intuitive so that a user can figure out how it works just by trying it out. Wouldn't the following 2 actions be sufficient for most cases: 'Remember Result', 'Compare Result'? You would always only remember one result and no diff selection and history deleting would be necessary. The usability would increase because you would go down from 8 possible user actions to 2. Cheers, Adrian > Cheers, > Alexandre > >> >> On Oct 1, 2008, at 16:56 , Alexandre Bergel wrote: >> >>> Dear list, >>> >>> In PharoInbox Gwenael and I put an extension of SUnit that records >>> results when running a set of test. >>> Feel free to suggest improvement.... >>> >>> Open a TestRunner to enjoy its 'History' button. >>> >>> Cheers, >>> 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2008