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

Re: [Pharo-project] Another finalization concern: error handling

by Igor Stasenko

On 11 October 2010 21:07, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > As a friend here: when did I say I'd remove all? Â Remove and process one at a time. Â I will admit to having a bias toward doing this with a single executor per object, but even if multiples turn out to have value (need to hunt down and read Levente's description of that), the same idea should apply. > Removing and processing one at a time could do the job, but it will be very inefficient (especially on VMs which not support new finalization). Because: - you have to enter critical section for scanning valueDictionary - you then have to leave critical section for sending a single #finalize - then you should start over and look for next element with nil key (if any) So, as i said, devil in details. > Bill > -- Best regards, Igor Stasenko AKA sig.

Oct. 11, 2010

Re: [Pharo-project] Xtreams port to Squeak - second wave

by mkobetic＠gmail.com

"Sven Van Caekenberghe"<sven(a)beta9.be> wrote: > I tried to follow your different releases in Pharo 1.1.1, right now I have 433 tests, 3 failures (#testReadWriteLargeAmount), 11 errors (#..base64 and #..multipleBufferSize). If will send you the report. > > I have been trying some of the examples from the doc pages (google code project), this simple one still fails: > > ((1 to: 10) reading collecting: [:x | x * x]) rest Ah, that's because of the use of #cull: like semantics with exception handlers in some places, mostly ... on: Incomplete do: #count. We can certainly replace all those with regular block style. > The readline example is using the non-existing #slicer: method, this simpler version seems to work: > > |text| > text := 'line1\line2\line3\line4' withCRs reading. > text := text ender: [ :char | char = Character cr ]. > text collect: [ :line | line rest ]. > > That is a documentation bug though. Hm, odd, this is fixed in the package comments, but looks like I failed to regenerate the project pages properly. I'll review the comments again and update the site. Thanks!

Oct. 11, 2010

Re: [Pharo-project] how to get the diff on commit on the pharo source?

by Levente Uzonyi

On Mon, 11 Oct 2010, Lukas Renggli wrote: > It is not the mailing list that is the problem, it is the > squeaksource.com server that is. It takes several minutes to calculate > a simple diff of a single version and that just kills responsiveness > at the current rate of commits. That seems to be a really high number. I just compared a version of the CollectionTests package in Squeak 4.2 with a Pharo version. The two are totally different, there are 2002 changes. Parsing both packages and creating the diffs takes less than a second with Cog. So it's probably less than 3 seconds with the standard VM. And this is an edge case. Levente > > Lukas > > On 11 October 2010 18:01, Alexandre Bergel <alexandre(a)bergel.eu> wrote: >> Maybe on a separate mailing list. >> >> Cheers, >> Alexandre >> >> >> On 11 Oct 2010, at 12:49, StÃ©phane Ducasse wrote: >> >>> I would really like to have the same behavior than the squeak system ie having the source modification >>> send to the list. I could not see how to set it up on Â squeaksource. >>> May be this is not the same version running. >>> >>> Stef >>> _______________________________________________ >>> 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 >> > > > > -- > Lukas Renggli > 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. 11, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Schwab,Wilhelm K

Sig, As a friend here: when did I say I'd remove all? Remove and process one at a time. I will admit to having a bias toward doing this with a single executor per object, but even if multiples turn out to have value (need to hunt down and read Levente's description of that), the same idea should apply. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Monday, October 11, 2010 1:39 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Another finalization concern: error handling On 11 October 2010 20:04, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Understood, but are they all that different? The ones that were served ahead of the error should stay that way (proper recording of same is what needs attention), and those yet to be served, if it's done well, should be ready for the new thread to handle. Just something to consider. > Devil is always in details. The problem can be illustrated by following: | todoList | todoList := collection select: [ some criteria ]. collection removeAllFoundIn: todoList. todoList do: [ :each | each doSomething ]. now, if inside of #doSomething you got an error, a loop is interrupted, and if you restart the process, your todoList temp is gone, since it is local to particular context, which will be discarded. You also can't restore todoList by rescanning a collection, since you removed all elements, which met your criteria. > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Monday, October 11, 2010 1:02 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Another finalization concern: error handling > > On 11 October 2010 19:28, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> The Dolphin approach is to restart any of the finalizer, main, timer, idler threads (I *think* there is one more in a baseline image) any time they quit; an #ensure: block forks a new thread of the type that terminated. That way, whether they are taken down by an error doing what they are supposed to do or just by a stray #terminate or mistake with an attached debugger, the system rolls onward intact. >> > > If it would be only about restarting, then its a piece of cake. > We should make sure that all finalizations detected prior to error, > did not get lost and are able to proceed as if nothing happens, > except a single one, which failed with error. > >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] >> Sent: Monday, October 11, 2010 12:14 PM >> To: Pharo-project(a)lists.gforge.inria.fr; The general-purpose Squeak developers list >> Subject: Re: [Pharo-project] Another finalization concern: error handling >> >> Meanwhile, i'll try to implement two test cases for WeakRegistryTest. >> >> One, should cover following: >> >> coll := OrderedCollection new. >> obj := Object new. >> wrapper := WeakArray with: obj. >> coll add: wrapper. >> >> obj toFinalizeSend: #remove: to: coll with: wrapper. >> obj toFinalizeSend: #remove: to: coll with: wrapper. >> obj toFinalizeSend: #remove: to: coll with: wrapper. >> obj toFinalizeSend: #remove: to: coll with: wrapper. >> >> obj := nil. >> Smalltalk garbageCollect. >> >> i.e somehow, user should be notified that there is an error during finalization. >> >> And second test case is to make sure that if one finalizer unable to >> complete due to error, >> the other ones (and finalization process itself) should continue >> running, skipping over errorneous finalizer. >> >> -- >> 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 > > _______________________________________________ > 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. 11, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Igor Stasenko

On 11 October 2010 20:04, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Understood, but are they all that different? Â The ones that were served ahead of the error should stay that way (proper recording of same is what needs attention), and those yet to be served, if it's done well, should be ready for the new thread to handle. Â Just something to consider. > Devil is always in details. The problem can be illustrated by following: | todoList | todoList := collection select: [ some criteria ]. collection removeAllFoundIn: todoList. todoList do: [ :each | each doSomething ]. now, if inside of #doSomething you got an error, a loop is interrupted, and if you restart the process, your todoList temp is gone, since it is local to particular context, which will be discarded. You also can't restore todoList by rescanning a collection, since you removed all elements, which met your criteria. > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Monday, October 11, 2010 1:02 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Another finalization concern: error handling > > On 11 October 2010 19:28, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> The Dolphin approach is to restart any of the finalizer, main, timer, idler threads (I *think* there is one more in a baseline image) any time they quit; an #ensure: block forks a new thread of the type that terminated. Â That way, whether they are taken down by an error doing what they are supposed to do or just by a stray #terminate or mistake with an attached debugger, the system rolls onward intact. >> > > If it would be only about restarting, then its a piece of cake. > We should make sure that all finalizations detected prior to error, > did not get lost and are able to proceed as if nothing happens, > except a single one, which failed with error. > >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] >> Sent: Monday, October 11, 2010 12:14 PM >> To: Pharo-project(a)lists.gforge.inria.fr; The general-purpose Squeak developers list >> Subject: Re: [Pharo-project] Another finalization concern: error handling >> >> Meanwhile, i'll try to implement two test cases for WeakRegistryTest. >> >> One, should cover following: >> >> coll := OrderedCollection new. >> obj := Object new. >> wrapper := WeakArray with: obj. >> coll add: wrapper. >> >> obj toFinalizeSend: #remove: to: coll with: wrapper. >> obj toFinalizeSend: #remove: to: coll with: wrapper. >> obj toFinalizeSend: #remove: to: coll with: wrapper. >> obj toFinalizeSend: #remove: to: coll with: wrapper. >> >> obj := nil. >> Smalltalk garbageCollect. >> >> i.e somehow, user should be notified that there is an error during finalization. >> >> And second test case is to make sure that if one finalizer unable to >> complete due to error, >> the other ones (and finalization process itself) should continue >> running, skipping over errorneous finalizer. >> >> -- >> 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 > > _______________________________________________ > 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. 11, 2010

[Pharo-project] R: R: R: R: Problem with inspector

by morod

IÂm sorry but something may be wrong. My Pharo.image NewInspector installed System settings I tried again and the result has not changed Thanks again for your patience Morod Da: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di Frederic Pluquet Inviato: lunedÃ¬ 11 ottobre 2010 00:23 A: Pharo-project(a)lists.gforge.inria.fr Oggetto: Re: [Pharo-project] R: R: R: Problem with inspector It's really strange. It works perfectly here. Step by step: - Download the last image of Pharo - Go to Monticello and load the last package of NewInspector - Go to System > Settings > Debugging > NewInspector - Check the options - Open a new inspector on an object The new children must appear. FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet 2010/10/10 morod <morod(a)tiscali.it> Thanks for your interest, I have done what was suggested, but nothing has changed. Morod Da: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di Frederic Pluquet Inviato: domenica 10 ottobre 2010 17:00 A: Pharo-project(a)lists.gforge.inria.fr Oggetto: Re: [Pharo-project] R: R: Problem with inspector If you load the last version of NewInspector (posted this morning), you go to the Settings Browser (System > Settings in the World menu), expand "Debugging" > "NewInspector" and check the options you want. FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet 2010/10/10 morod <morod(a)tiscali.it> Hello, How can I switch from the two different versions of tool ÂInspectorÂ Best regards Morod Da: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di Frederic Pluquet Inviato: sabato 9 ottobre 2010 14:08 A: Pharo-project(a)lists.gforge.inria.fr Oggetto: Re: [Pharo-project] R: Problem with inspector Hello, It's the NewInspector on both pictures but two different versions of this tool. In the old version, the class and the methods were displayed for each inspected object. In the current version, there are not displayed (because the community prefers less children for each object). FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet 2010/10/8 morod <morod(a)tiscali.it> Hi Mariano I tried it with multiple images and the behavior is the same with all the images. Sent the sample is made with: Pharo-1.1-11411 Latest update: #11411 The first one is my image and the second is taken from the book ÂPharo by ExampleÂ Thanks again Morod Da: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di Mariano Martinez Peck Inviato: venerdÃ¬ 8 ottobre 2010 21:43 A: Pharo-project(a)lists.gforge.inria.fr Oggetto: Re: [Pharo-project] Problem with inspector Hi morod, and welcome to Pharo! Which Pharo image are you exactly using? (the name of the zip, the image file or go to System -> About) The first one is your image, right ? and the second one? where is it from ? The difference is that the first image is using the "old" traditional inspector, while the second picture is using another inspector, which is called "NewInspector", which provides more information. Cheers Mariano 2010/10/8 morod <morod(a)tiscali.it> Hi iÂm new to smalltalk and Pharo and my inspector show Errore. Il nome file non Ã¨ specificato. instead of Errore. Il nome file non Ã¨ specificato. Why? Thanks _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2010

[Pharo-project] License question

by Schwab,Wilhelm K

Stef, Let's go forward in time. NativeBoost, Alien or FFI provide callbacks, I do some adaptation on my end, and out comes a pretty capable wrapper for the GNU Scientific Library. That sentence trivializes a LOT of work :( Details aside, is the wrapper code itself affected by GPL, or is it merely something unrelated that happens to invoke GSL if the latter is present on a system? What implications would that have for putting the wrapper in the inbox? This won't happen next week or next month, but depending on how easy it is to get going with callbacks, it shouldn't be years either. Bill

Oct. 11, 2010

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

by Nicolas Cellier

2010/10/11 Levente Uzonyi <leves(a)elte.hu>: > On Mon, 11 Oct 2010, Lukas Renggli wrote: > >>> Object>>value >>> Â Â Â Â ^self >>> >>> What actually shown here is a use of duck typing, because any object, >>> which implemets #value, could be safely passed >>> as argument to #ifTrue:ifFalse: message. >>> It is well consistent with language design. >> >> Magritte implemented Symbol>>#value: for a while before any Smalltalk >> had this is their standard library. I must admit that I liked it in >> the beginning, but in the long run I realized that ... >> >> 1. It is not easily understandable for newbies. > > That's true. > Well, it depends. Very newbies can understand it because they trust the words. My son did. More advanced newbies can wonder how the hell this could work eventually, because they can differentiate a regular message and a literal #symbol. It's true that writing code is another matter. Why and when to use a block a message or a Symbol ? Maybe a newbie could be tempted to write: x > 1 and: #even. which currently does not work. >> 2. It quickly leads to very unreadable, hard to understand and hard to >> refactor code. >> 3. It is very limiting in itself and quickly leads to other hacks >> (like to replace sort blocks). > > That "hack" is really cool IMO. The code is easily understood by anyone: > > #(4 1 3 5 2) sort: #<=. > >> 4. #value and friends should be only understood by objects that can be >> evaluated (certainly not by Object). A symbol (name) by itself cannot >> be evaluated. >> >> I eventually removed Symbol>>#value: for good. Re-occuring questions >> in the mailing list disappeared. > > That's strange, because Symbol >> #value: was added to Squeak in 2006 during > the developement of 3.9. > > > Levente > >> >> Therefor I strongly suggest to remove #value, #value:, and friends >> from all objects that are not self-evaluable. BlockClosure and >> MessageSend are self-evaluable. Only there it makes sense. >> >> If people are too lazy to create a block where something >> self-evaluable is needed they should use a programming language >> designed for cryptic code. Creating a block closure in Smalltalk is >> concise and makes clear what happens easily. A symbol does not, you >> need to exactly understand how this dispatches with various objects. >> >> Lukas >> >> >> -- >> Lukas Renggli >> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 11, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Schwab,Wilhelm K

Sig, Understood, but are they all that different? The ones that were served ahead of the error should stay that way (proper recording of same is what needs attention), and those yet to be served, if it's done well, should be ready for the new thread to handle. Just something to consider. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Monday, October 11, 2010 1:02 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Another finalization concern: error handling On 11 October 2010 19:28, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > The Dolphin approach is to restart any of the finalizer, main, timer, idler threads (I *think* there is one more in a baseline image) any time they quit; an #ensure: block forks a new thread of the type that terminated. That way, whether they are taken down by an error doing what they are supposed to do or just by a stray #terminate or mistake with an attached debugger, the system rolls onward intact. > If it would be only about restarting, then its a piece of cake. We should make sure that all finalizations detected prior to error, did not get lost and are able to proceed as if nothing happens, except a single one, which failed with error. > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Monday, October 11, 2010 12:14 PM > To: Pharo-project(a)lists.gforge.inria.fr; The general-purpose Squeak developers list > Subject: Re: [Pharo-project] Another finalization concern: error handling > > Meanwhile, i'll try to implement two test cases for WeakRegistryTest. > > One, should cover following: > > coll := OrderedCollection new. > obj := Object new. > wrapper := WeakArray with: obj. > coll add: wrapper. > > obj toFinalizeSend: #remove: to: coll with: wrapper. > obj toFinalizeSend: #remove: to: coll with: wrapper. > obj toFinalizeSend: #remove: to: coll with: wrapper. > obj toFinalizeSend: #remove: to: coll with: wrapper. > > obj := nil. > Smalltalk garbageCollect. > > i.e somehow, user should be notified that there is an error during finalization. > > And second test case is to make sure that if one finalizer unable to > complete due to error, > the other ones (and finalization process itself) should continue > running, skipping over errorneous finalizer. > > -- > 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. 11, 2010

Re: [Pharo-project] how to get the diff on commit on the pharo source?

by Lukas Renggli

It is not the mailing list that is the problem, it is the squeaksource.com server that is. It takes several minutes to calculate a simple diff of a single version and that just kills responsiveness at the current rate of commits. Lukas On 11 October 2010 18:01, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > Maybe on a separate mailing list. > > Cheers, > Alexandre > > > On 11 Oct 2010, at 12:49, StÃ©phane Ducasse wrote: > >> I would really like to have the same behavior than the squeak system ie having the source modification >> send to the list. I could not see how to set it up on Â squeaksource. >> May be this is not the same version running. >> >> Stef >> _______________________________________________ >> 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 > -- Lukas Renggli www.lukas-renggli.ch

Oct. 11, 2010