- Pharo-dev - lists.pharo.org

Re: [Pharo-project] 1.2 vision

by laurent laffont

> > > >**Yes** I really want to come up with a pragma and to annotate tests to > >populate the help. > > I remember that we talked about this. Can you point me to the > thread in the archive? > http://forum.world.st/Help-System-tp2134021p2134048.html http://forum.world.st/Help-System-tp2134021p2135947.html http://forum.world.st/Help-System-tp2134021p2135948.html Laurent > > Stef wrote > >We should also clean the package naming structure > >XXX > >... > > Either we get real packages or XXX will include anything > from #(XXX-Core, XXX-Test-Core, > XXX-Foo, XXX-Test-Foo) > > I would also vote to alphabetize the class and method > categories before doing a release. > > > GermÃ¡n wrote: > >disable programmer facilities (as was talked in the thread of some time > ago) > > I started with this, see ImageLocker-Core-tbn.1.mcz > in http://squeaksource.com/PharoGoodies/ > > Feel free to help here. > > > Bye > Torsten > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 30, 2010

[Pharo-project] 1.2 vision

by Torsten Bergmann

Laurent wrote: >+ More HelpSystem. +1, we should continue to populate "Pharo-Project-Help" package on squeaksource.com/HelpSystem since it is used during the pharo-dev build. It should at least point to the available online books, ... And we should find the time to integrate Scamper. >+ MetacelloRepository GUI, newbies struggle to find a package, must be e +1 Stef wrote >**Yes** I really want to come up with a pragma and to annotate tests to >populate the help. I remember that we talked about this. Can you point me to the thread in the archive? Stef wrote >We should also clean the package naming structure >XXX >... Either we get real packages or XXX will include anything from #(XXX-Core, XXX-Test-Core, XXX-Foo, XXX-Test-Foo) I would also vote to alphabetize the class and method categories before doing a release. GermÃ¡n wrote: >disable programmer facilities (as was talked in the thread of some time ago) I started with this, see ImageLocker-Core-tbn.1.mcz in http://squeaksource.com/PharoGoodies/ Feel free to help here. Bye Torsten -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

June 30, 2010

Re: [Pharo-project] Strange behavior (bug) of wrapping text with TTFont (russian text) in TextMorph

by Denis Kudriashov

I found solution. I comment line of code in scanning loop in MultiCharacterScanner>>scanMultiCharactersFrom: startIndex to: stopIndex in: sourceString rightX: rightX stopConditions: stops kern: kernDelta ... "encoding ~= startEncoding ifTrue: [lastIndex := lastIndex - 1. ^ stops endOfRun]." ... Without this commenting scanning process not register breakage at space when scanning russian text. (because encoding is differ from startEncoding. Encoding for space is 0 but for startEncoding is leadingChar of not ascii russian text). I dont now meaning of this code line. But now I have correct wrapping behavior. I know that multilingual package have many newly versions. All containes that strange code line. I open Issue http://code.google.com/p/pharo/issues/detail?id=2608 30 Ð¸ÑÐ½Ñ 2010 Ð³. 9:55:37 UTC+4 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ dionisiydk <dionisiydk(a)gmail.com>Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > No. #isSeparator message not used for wrapping. Wrapping logic implemented > in MultiCompositionScanner and dont use #isSeparator > > 2010/6/30 Igor Stasenko <siguctua(a)gmail.com> > >> 2010/6/30 Denis Kudriashov <dionisiydk(a)gmail.com>: >> > I use Pharo 1.1 rc2 10.06 >> > >> > I found strange behavior of wrapping text with TTFont (russian text) in >> > TextMorph. >> > >> > I dont know how to reproduce it. But I see it in my application. >> > >> > I have prototype button with TextMorph as it label. And I do many of: >> > >> > aPanel add: prototype veryDeepCopy contentsWrapped: someRussianText. >> > >> > And I see that text on label dont wrapped by words. It is wrapped only >> by >> > label bounds. And words in text became break. >> > Example. I expect >> > >> i think it wraps text based on #isSeparator test. >> And any russian (as well as any other non-ascii characters), afaik is >> treated as separators. >> That's why it wraps on any letter. >> >> > "one two >> > three" >> > >> > But I see >> > >> > "one two th >> > ree >> > " >> > >> > Its work correct for english text. But for russian not. >> > >> > And I cant reproduce it by execution code separetelly from my >> application >> > (aPanel add: prototype veryDeepCopy contentsWrapped: someRussianText). >> > >> > I try many experiments with debuger and inspector. But I cant fix that. >> > Wrapping text code is not simple. >> > Maybe somebody tell me what place I need learn/inspect for fixing this >> bug? >> > >> > And I found that If I insert char by keyboard at the end of word "two" >> (see >> > example) text wrapped correctly: >> > "one twoNEW >> > three >> > " >> > >> > And this behavior correct in Pharo 1.0. >> > >> > >> > >> > >> > _______________________________________________ >> > 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 >> > >

June 30, 2010

Re: [Pharo-project] Strange behavior (bug) of wrapping text with TTFont (russian text) in TextMorph

by Denis Kudriashov

No. #isSeparator message not used for wrapping. Wrapping logic implemented in MultiCompositionScanner and dont use #isSeparator 2010/6/30 Igor Stasenko <siguctua(a)gmail.com> > 2010/6/30 Denis Kudriashov <dionisiydk(a)gmail.com>: > > I use Pharo 1.1 rc2 10.06 > > > > I found strange behavior of wrapping text with TTFont (russian text) in > > TextMorph. > > > > I dont know how to reproduce it. But I see it in my application. > > > > I have prototype button with TextMorph as it label. And I do many of: > > > > aPanel add: prototype veryDeepCopy contentsWrapped: someRussianText. > > > > And I see that text on label dont wrapped by words. It is wrapped only by > > label bounds. And words in text became break. > > Example. I expect > > > i think it wraps text based on #isSeparator test. > And any russian (as well as any other non-ascii characters), afaik is > treated as separators. > That's why it wraps on any letter. > > > "one two > > three" > > > > But I see > > > > "one two th > > ree > > " > > > > Its work correct for english text. But for russian not. > > > > And I cant reproduce it by execution code separetelly from my application > > (aPanel add: prototype veryDeepCopy contentsWrapped: someRussianText). > > > > I try many experiments with debuger and inspector. But I cant fix that. > > Wrapping text code is not simple. > > Maybe somebody tell me what place I need learn/inspect for fixing this > bug? > > > > And I found that If I insert char by keyboard at the end of word "two" > (see > > example) text wrapped correctly: > > "one twoNEW > > three > > " > > > > And this behavior correct in Pharo 1.0. > > > > > > > > > > _______________________________________________ > > 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 >

June 30, 2010

Re: [Pharo-project] 1.2 vision

by Schwab,Wilhelm K

Eliot, It sounds as though you have the right idea. Here's hoping you are able to release it. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Eliot Miranda Sent: Tuesday, June 29, 2010 4:01 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.2 vision On Tue, Jun 29, 2010 at 12:23 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: On Jun 29, 2010, at 6:15 PM, Schwab,Wilhelm K wrote: > Stef, > > It all sounds great. I probably care less about Alien than I do about what it is supposed to do well: callbacks. We need callbacks, and we need to be able to do callbacks that return double. That can come from Alien, Native Boost, or a plugin that makes FFI able to handle callbacks. Callbacks should not come at a cost of making every call harder to do, which **might** be the case with Alien. the only way to make progress on this front is to propose some code. > It would also be nice to have an analog to Dolphin's overlapped calls (calls made on a separate thread that block only the calling Smalltalk process, and not the entire image). I think that eliot is working on threaded something for Cog We have a functional prototype that does overlapped calls. Its a multi-threaded VM based on David Simmons' ideas that allows only one thread to execute Smalltalk at any one time. Again I can't say anything either way as to when or whether this will be released. But we did finally release Cog , so at least there's a precedent :) > > SSL would also be nice. Overlapped calls would greatly simplify creating it, as then one could safely use OpenSSL's blocking calls on separate threads. The alternative is to do non-blocking calls, which is considerably more work than letting the OS handle the multi-tasking. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of StÃ©phane Ducasse > Sent: Sunday, June 27, 2010 3:32 AM > To: Pharo Development > Subject: [Pharo-project] 1.2 vision > > Hi all > > Of course we will integrate changes and changes and improvements.... now I believe that it would be nice to build a common vision. Here what I would like to get in 1.2. > > Now it does not mean that this is a definitive list and that we will have the energy to do all but like that you know that you can put energy do build this common vision :) > > - better infrastructure for integrating rb composite queries into the system > The idea is to introduce a superclass on top of systemDictionary and to define there an API that > is compatible with the one of RB (and potentially modified the one of RB) > > - another step towards using announcement for system notification > > - better tools for dev > > - have a look at the RB change model so that we could get a real undo and changes > > - clean Monticello so that package logic stays in package so that we can plug RPackage into the system. > Right now this looks too brittle to do anything > > - make sure that we can have RPackage on the side of PakageInfo (we got really nice benchmark) > > - New Compiler in beta > > - Helvetia hooks > > - ROME API > > - Sophie Event Hierarchy > > - Define some architectural action to get the system more modular > > - Hudson infrastructure > > - metacello to manage core > > - metacelloRepository for 1.0/1.1/1.2 > Gofer > > - squeak collection optimisation? > > - Alien > > Open points: > > - What do we do with ToolBuilder? Not clear to me. > > - What should be done at the level of polymorph? > - What should be done a the level of Pluggable**** > can we use the fact that we have now block closure to get it better. > > As you guess it will not come simply but this is important that we all head towards a common understanding > > > Stef > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:Pharo-project@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<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 30, 2010

Re: [Pharo-project] 1.2 vision

by Schwab,Wilhelm K

Stef, There are places where I can help; writing a callback framework is probably not one of them. But my point is that if, as has been hinted in a few places, Alien gives us callbacks and makes the ordinary things hard, then we might not have not bought much in the process. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Tuesday, June 29, 2010 2:23 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.2 vision On Jun 29, 2010, at 6:15 PM, Schwab,Wilhelm K wrote: > Stef, > > It all sounds great. I probably care less about Alien than I do about what it is supposed to do well: callbacks. We need callbacks, and we need to be able to do callbacks that return double. That can come from Alien, Native Boost, or a plugin that makes FFI able to handle callbacks. Callbacks should not come at a cost of making every call harder to do, which **might** be the case with Alien. the only way to make progress on this front is to propose some code. > It would also be nice to have an analog to Dolphin's overlapped calls (calls made on a separate thread that block only the calling Smalltalk process, and not the entire image). I think that eliot is working on threaded something for Cog > > SSL would also be nice. Overlapped calls would greatly simplify creating it, as then one could safely use OpenSSL's blocking calls on separate threads. The alternative is to do non-blocking calls, which is considerably more work than letting the OS handle the multi-tasking. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > StÃ©phane Ducasse > Sent: Sunday, June 27, 2010 3:32 AM > To: Pharo Development > Subject: [Pharo-project] 1.2 vision > > Hi all > > Of course we will integrate changes and changes and improvements.... now I believe that it would be nice to build a common vision. Here what I would like to get in 1.2. > > Now it does not mean that this is a definitive list and that we will > have the energy to do all but like that you know that you can put > energy do build this common vision :) > > - better infrastructure for integrating rb composite queries into the system > The idea is to introduce a superclass on top of systemDictionary and to define there an API that > is compatible with the one of RB (and potentially modified the one > of RB) > > - another step towards using announcement for system notification > > - better tools for dev > > - have a look at the RB change model so that we could get a real undo > and changes > > - clean Monticello so that package logic stays in package so that we can plug RPackage into the system. > Right now this looks too brittle to do anything > > - make sure that we can have RPackage on the side of PakageInfo (we > got really nice benchmark) > > - New Compiler in beta > > - Helvetia hooks > > - ROME API > > - Sophie Event Hierarchy > > - Define some architectural action to get the system more modular > > - Hudson infrastructure > > - metacello to manage core > > - metacelloRepository for 1.0/1.1/1.2 > Gofer > > - squeak collection optimisation? > > - Alien > > Open points: > > - What do we do with ToolBuilder? Not clear to me. > > - What should be done at the level of polymorph? > - What should be done a the level of Pluggable**** > can we use the fact that we have now block closure to get it better. > > As you guess it will not come simply but this is important that we all > head towards a common understanding > > > 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

June 30, 2010

Re: [Pharo-project] Strange behavior (bug) of wrapping text with TTFont (russian text) in TextMorph

by Igor Stasenko

2010/6/30 Denis Kudriashov <dionisiydk(a)gmail.com>: > I use Pharo 1.1 rc2 10.06 > > I found strange behavior of wrapping text with TTFont (russian text) in > TextMorph. > > I dont know how to reproduce it. But I see it in my application. > > I have prototype button with TextMorph as it label. And I do many of: > > aPanel add: prototype veryDeepCopy contentsWrapped: someRussianText. > > And I see that text on label dont wrapped by words. It is wrapped only by > label bounds. And words in text became break. > Example. I expect > i think it wraps text based on #isSeparator test. And any russian (as well as any other non-ascii characters), afaik is treated as separators. That's why it wraps on any letter. > "one two > three" > > But I see > > "one two th > ree > " > > Its work correct for english text. But for russian not. > > And I cant reproduce it by execution code separetelly from my application > (aPanel add: prototype veryDeepCopy contentsWrapped: someRussianText). > > I try many experiments with debuger and inspector. But I cant fix that. > Wrapping text code is not simple. > Maybe somebody tell me what place I need learn/inspect for fixing this bug? > > And I found that If I insert char by keyboard at the end of word "two" (see > example) text wrapped correctly: > "one twoNEW > three > " > > And this behavior correct in Pharo 1.0. > > > > > _______________________________________________ > 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.

June 30, 2010

Re: [Pharo-project] 1.2 vision

by GermÃ¡n Arduino

Hi: Between the dev tools I think that a complete shrink and disable programmer facilities (as was talked in the thread of some time ago) will be useful to people using Pharo for business. Cheers. 2010/6/27 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi all > > Of course we will integrate changes and changes and improvements.... now I believe that it would be nice to build a common > vision. Here what I would like to get in 1.2. > > Now it does not mean that this is a definitive list and that we will have the energy to do all but like > that you know that you can put energy do build this common vision :) > > Â Â Â Â - better infrastructure for integrating rb composite queries into the system > Â Â Â Â Â Â Â Â The idea is to introduce a superclass on top of systemDictionary and to define there an API that > Â Â Â Â Â Â Â Â is compatible with the one of RB (and potentially modified the one of RB) > > Â Â Â Â - another step towards using announcement for system notification > > Â Â Â Â - better tools for dev > > Â Â Â Â - have a look at the RB change model so that we could get a real undo and changes > > Â Â Â Â - clean Monticello so that package logic stays in package so that we can plug RPackage into the system. > Â Â Â Â Right now this looks too brittle to do anything > > Â Â Â Â - make sure that we can have RPackage on the side of PakageInfo (we got really nice benchmark) > > Â Â Â Â - New Compiler in beta > > Â Â Â Â - Helvetia hooks > > Â Â Â Â - ROME API > > Â Â Â Â - Sophie Event Hierarchy > > Â Â Â Â - Define some architectural action to get the system more modular > > Â Â Â Â - Hudson infrastructure > > Â Â Â Â - metacello to manage core > > Â Â Â Â - metacelloRepository for 1.0/1.1/1.2 > Â Â Â Â Â Â Â Â Gofer > > Â Â Â Â - squeak collection optimisation? > > Â Â Â Â - Alien > > Open points: > > Â Â Â Â - What do we do with ToolBuilder? Not clear to me. > > Â Â Â Â - What should be done at the level of polymorph? > Â Â Â Â Â Â Â Â - What should be done a the level of Pluggable**** > Â Â Â Â Â Â Â Â Â Â Â Â can we use the fact that we have now block closure to get it better. > > As you guess it will not come simply but this is important that we all head towards a common understanding > > > Stef > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 29, 2010

[Pharo-project] Strange behavior (bug) of wrapping text with TTFont (russian text) in TextMorph

by Denis Kudriashov

I use Pharo 1.1 rc2 10.06 I found strange behavior of wrapping text with TTFont (russian text) in TextMorph. I dont know how to reproduce it. But I see it in my application. I have prototype button with TextMorph as it label. And I do many of: aPanel add: prototype veryDeepCopy contentsWrapped: someRussianText. And I see that text on label dont wrapped by words. It is wrapped only by label bounds. And words in text became break. Example. I expect "one two three" But I see "one two th ree " Its work correct for english text. But for russian not. And I cant reproduce it by execution code separetelly from my application (aPanel add: prototype veryDeepCopy contentsWrapped: someRussianText). I try many experiments with debuger and inspector. But I cant fix that. Wrapping text code is not simple. Maybe somebody tell me what place I need learn/inspect for fixing this bug? And I found that If I insert char by keyboard at the end of word "two" (see example) text wrapped correctly: "one twoNEW three " And this behavior correct in Pharo 1.0.

June 29, 2010

Re: [Pharo-project] 1.2 vision

by Eliot Miranda

On Tue, Jun 29, 2010 at 12:23 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > On Jun 29, 2010, at 6:15 PM, Schwab,Wilhelm K wrote: > > > Stef, > > > > It all sounds great. I probably care less about Alien than I do about > what it is supposed to do well: callbacks. We need callbacks, and we need > to be able to do callbacks that return double. That can come from Alien, > Native Boost, or a plugin that makes FFI able to handle callbacks. > Callbacks should not come at a cost of making every call harder to do, > which **might** be the case with Alien. > > the only way to make progress on this front is to propose some code. > > > It would also be nice to have an analog to Dolphin's overlapped calls > (calls made on a separate thread that block only the calling Smalltalk > process, and not the entire image). > > I think that eliot is working on threaded something for Cog > We have a functional prototype that does overlapped calls. Its a multi-threaded VM based on David Simmons' ideas that allows only one thread to execute Smalltalk at any one time. Again I can't say anything either way as to when or whether this will be released. But we did finally release Cog , so at least there's a precedent :) > > > SSL would also be nice. Overlapped calls would greatly simplify creating > it, as then one could safely use OpenSSL's blocking calls on separate > threads. The alternative is to do non-blocking calls, which is considerably > more work than letting the OS handle the multi-tasking. > > > > Bill > > > > > > > > -----Original Message----- > > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse > > Sent: Sunday, June 27, 2010 3:32 AM > > To: Pharo Development > > Subject: [Pharo-project] 1.2 vision > > > > Hi all > > > > Of course we will integrate changes and changes and improvements.... now > I believe that it would be nice to build a common vision. Here what I would > like to get in 1.2. > > > > Now it does not mean that this is a definitive list and that we will have > the energy to do all but like that you know that you can put energy do build > this common vision :) > > > > - better infrastructure for integrating rb composite queries into > the system > > The idea is to introduce a superclass on top of > systemDictionary and to define there an API that > > is compatible with the one of RB (and potentially modified > the one of RB) > > > > - another step towards using announcement for system notification > > > > - better tools for dev > > > > - have a look at the RB change model so that we could get a real > undo and changes > > > > - clean Monticello so that package logic stays in package so that > we can plug RPackage into the system. > > Right now this looks too brittle to do anything > > > > - make sure that we can have RPackage on the side of PakageInfo (we > got really nice benchmark) > > > > - New Compiler in beta > > > > - Helvetia hooks > > > > - ROME API > > > > - Sophie Event Hierarchy > > > > - Define some architectural action to get the system more modular > > > > - Hudson infrastructure > > > > - metacello to manage core > > > > - metacelloRepository for 1.0/1.1/1.2 > > Gofer > > > > - squeak collection optimisation? > > > > - Alien > > > > Open points: > > > > - What do we do with ToolBuilder? Not clear to me. > > > > - What should be done at the level of polymorph? > > - What should be done a the level of Pluggable**** > > can we use the fact that we have now block closure > to get it better. > > > > As you guess it will not come simply but this is important that we all > head towards a common understanding > > > > > > 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 >

June 29, 2010