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

Re: [Pharo-project] Debugging with morphic

by Alexandre Bergel

Thanks Bill, Reading your post was indeed useful Alexandre On 14 Feb 2009, at 21:37, Schwab,Wilhelm K wrote: > Gary, Alexandre, > > I have long advocated an approach to this in the Dolphin community - > not sure how many people have really adopted it, but the same ideas > should work here. Gary just hit a big part of it - set yourself up > to do something dangerous (don't do it yet), save, then try it. If > it blows up, learn what you can, close, and try again. > > In Dolphin, the debate surrounds view subclasses. I submit that > most of them are unnecessary, as an image presenter can do the job. > There are exceptions, but probably not many with a little > creativity. The trick then is to generate code that draws on a > canvas. Start out with a bitmap that you do not even expect to > display. The debugger says hello, and no real harm is done. When > the notifiers cease, it's time to actually look at the image. More > fun, and perhaps some iteration, but nothing bad really happens. > Once it runs and is correct, it can go into a standard presenter. > The alternative of making a view puts the system increases risk > unless one protects the drawing to ensure the view ends up in a sane > state. > > Another thing that can be very helpful is a class called Once. It > can be #reset and is used something like (if there is interest I can > look for it) > > Once do:[ > self halt. > ]. > > with the predictable result - one pass through the offending code > halts, the rest go merrily onward until a Once reset occurs. > > Here's hoping that was worth the time you wasted reading it :) > > Bill > > > ---- > Wilhelm K. Schwab, Ph.D. > bschwab AT anest DOT ufl DOT edu > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr > ] On Behalf Of Gary Chambers [gazzaguru2(a)btinternet.com] > Sent: Saturday, February 14, 2009 2:03 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Debugging with morphic > > More often than not the emergency evaluator can save you from having > to > reload changes... > Otherwise, save often after careful consideration and before likely > dangerous changes. Not a huge hassle to relaunch and load the last > changes > either though. > > Regards, Gary > > ----- Original Message ----- > From: "Alexandre Bergel" <alexandre(a)bergel.eu> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, February 14, 2009 6:29 PM > Subject: Re: [Pharo-project] Debugging with morphic > > >> I was just wondering how you guys debug your morphic programming. >> There is probably something wrong in the way I do. I cannot imagine >> people have been doing some morphic for so long without having a >> simple way to debug it. >> >> Cheers, >> Alexandre >> >> >> On 14 Feb 2009, at 18:26, Gary Chambers wrote: >> >>> I'm sure I can come up with something... you obvioulsy want some >>> kind of >>> debugger if an error occurs. >>> The taskbar works effectively synchronously with the display and >>> should >>> handle self inflicted errors. >>> Other display errors *should* get managed by the #errorOnDraw thing, >>> but not >>> always it would seem. >>> >>> Regards, Gary >>> >>> ----- Original Message ----- >>> From: "Alexandre Bergel" <Alexandre.Bergel(a)inria.fr> >>> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> >>> Sent: Saturday, February 14, 2009 4:53 PM >>> Subject: [Pharo-project] Debugging with morphic >>> >>> >>>> Hi All (and especially the Pinesoft crew), >>>> >>>> When an error is triggered by a displayOn: method, the bottom bar >>>> is >>>> being filled with debugger windows. It then become hardly >>>> debuggable. >>>> Ideally, the system should not display a window if an error is >>>> triggered in the displayOn. >>>> >>>> Do you have any recommandation/conviention/enhancement to prevent >>>> the >>>> image to hang when an error is signaled in a displayOn. This is >>>> really >>>> annoying. >>>> >>>> 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 > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 15, 2009

[Pharo-project] EventSensor>>createMouseEvent

by Igor Stasenko

Hi, i found this method used only in two places in my image: Rectangle>>newRectFrom: Rectangle>>newRectButtonPressedDo: i think it could be candidate for removal along with #newRect's Still, i think it is useful to create graphics primitives based on user input. But i think that Rectangle is inappropriate place for it, where it hard-wiring with many globals and Morpic framework. -- Best regards, Igor Stasenko AKA sig.

Feb. 15, 2009

Re: [Pharo-project] Boring confirmation message...

by Alexandre Bergel

Wow... I did not know that thanks Igor Alexandre On 14 Feb 2009, at 21:48, Igor Stasenko wrote: > 2009/2/14 Alexandre Bergel <Alexandre.Bergel(a)inria.fr>: >> Hi All, >> >> Often, I do a print-it in a debugger or browser. For some mysterious >> reason, I subsequently press the delete key that erases what was just >> print. Some changes occurred therefore. When I then select another >> method (or frame if I am in a debugger), a confirmation whether I >> want >> to save my changes is done. I find this very boring. Am i the only >> one ? >> >> A simple check whether the textual content has been modified would >> prevent this stupid question. >> > pressing Alt-l in a text morph will restore it contents back to > original, and clear 'modified' flag. > I using it often to avoid answering this question. :) > >> 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 >> > > > > -- > 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 14, 2009

Re: [Pharo-project] Boring confirmation message...

by Igor Stasenko

2009/2/14 Alexandre Bergel <Alexandre.Bergel(a)inria.fr>: > Hi All, > > Often, I do a print-it in a debugger or browser. For some mysterious > reason, I subsequently press the delete key that erases what was just > print. Some changes occurred therefore. When I then select another > method (or frame if I am in a debugger), a confirmation whether I want > to save my changes is done. I find this very boring. Am i the only one ? > > A simple check whether the textual content has been modified would > prevent this stupid question. > pressing Alt-l in a text morph will restore it contents back to original, and clear 'modified' flag. I using it often to avoid answering this question. :) > 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 > -- Best regards, Igor Stasenko AKA sig.

Feb. 14, 2009

Re: [Pharo-project] Debugging with morphic

by Igor Stasenko

2009/2/14 Gary Chambers <gazzaguru2(a)btinternet.com>: > More often than not the emergency evaluator can save you from having to > reload changes... > Otherwise, save often after careful consideration and before likely > dangerous changes. Not a huge hassle to relaunch and load the last changes > either though. > I think its one of biggest issue for newcomers who trying to implement new or improve current UI. Some cases is relatively easy to debug, when you playing with morphs for instance. But it you getting deeper into Canvas & Balloon rendering , the cost of error it very high - in most cases you have to restart image. One of the good things about having multiple host windows, that you can open debugger in separate host window and debug UI in second one by stepping through most low-level methods, which perform drawing. This would make debugging graphics & UI much easier. That's what i like to be made possible. > Regards, Gary > > ----- Original Message ----- > From: "Alexandre Bergel" <alexandre(a)bergel.eu> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, February 14, 2009 6:29 PM > Subject: Re: [Pharo-project] Debugging with morphic > > >>I was just wondering how you guys debug your morphic programming. >> There is probably something wrong in the way I do. I cannot imagine >> people have been doing some morphic for so long without having a >> simple way to debug it. >> >> Cheers, >> Alexandre >> >> >> On 14 Feb 2009, at 18:26, Gary Chambers wrote: >> >>> I'm sure I can come up with something... you obvioulsy want some >>> kind of >>> debugger if an error occurs. >>> The taskbar works effectively synchronously with the display and >>> should >>> handle self inflicted errors. >>> Other display errors *should* get managed by the #errorOnDraw thing, >>> but not >>> always it would seem. >>> >>> Regards, Gary >>> >>> ----- Original Message ----- >>> From: "Alexandre Bergel" <Alexandre.Bergel(a)inria.fr> >>> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> >>> Sent: Saturday, February 14, 2009 4:53 PM >>> Subject: [Pharo-project] Debugging with morphic >>> >>> >>>> Hi All (and especially the Pinesoft crew), >>>> >>>> When an error is triggered by a displayOn: method, the bottom bar is >>>> being filled with debugger windows. It then become hardly debuggable. >>>> Ideally, the system should not display a window if an error is >>>> triggered in the displayOn. >>>> >>>> Do you have any recommandation/conviention/enhancement to prevent the >>>> image to hang when an error is signaled in a displayOn. This is >>>> really >>>> annoying. >>>> >>>> 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 > -- Best regards, Igor Stasenko AKA sig.

Feb. 14, 2009

Re: [Pharo-project] Debugging with morphic

by Schwab,Wilhelm K

Gary, Alexandre, I have long advocated an approach to this in the Dolphin community - not sure how many people have really adopted it, but the same ideas should work here. Gary just hit a big part of it - set yourself up to do something dangerous (don't do it yet), save, then try it. If it blows up, learn what you can, close, and try again. In Dolphin, the debate surrounds view subclasses. I submit that most of them are unnecessary, as an image presenter can do the job. There are exceptions, but probably not many with a little creativity. The trick then is to generate code that draws on a canvas. Start out with a bitmap that you do not even expect to display. The debugger says hello, and no real harm is done. When the notifiers cease, it's time to actually look at the image. More fun, and perhaps some iteration, but nothing bad really happens. Once it runs and is correct, it can go into a standard presenter. The alternative of making a view puts the system increases risk unless one protects the drawing to ensure the view ends up in a sane state. Another thing that can be very helpful is a class called Once. It can be #reset and is used something like (if there is interest I can look for it) Once do:[ self halt. ]. with the predictable result - one pass through the offending code halts, the rest go merrily onward until a Once reset occurs. Here's hoping that was worth the time you wasted reading it :) Bill ---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Gary Chambers [gazzaguru2(a)btinternet.com] Sent: Saturday, February 14, 2009 2:03 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Debugging with morphic More often than not the emergency evaluator can save you from having to reload changes... Otherwise, save often after careful consideration and before likely dangerous changes. Not a huge hassle to relaunch and load the last changes either though. Regards, Gary ----- Original Message ----- From: "Alexandre Bergel" <alexandre(a)bergel.eu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Saturday, February 14, 2009 6:29 PM Subject: Re: [Pharo-project] Debugging with morphic >I was just wondering how you guys debug your morphic programming. > There is probably something wrong in the way I do. I cannot imagine > people have been doing some morphic for so long without having a > simple way to debug it. > > Cheers, > Alexandre > > > On 14 Feb 2009, at 18:26, Gary Chambers wrote: > >> I'm sure I can come up with something... you obvioulsy want some >> kind of >> debugger if an error occurs. >> The taskbar works effectively synchronously with the display and >> should >> handle self inflicted errors. >> Other display errors *should* get managed by the #errorOnDraw thing, >> but not >> always it would seem. >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Alexandre Bergel" <Alexandre.Bergel(a)inria.fr> >> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Saturday, February 14, 2009 4:53 PM >> Subject: [Pharo-project] Debugging with morphic >> >> >>> Hi All (and especially the Pinesoft crew), >>> >>> When an error is triggered by a displayOn: method, the bottom bar is >>> being filled with debugger windows. It then become hardly debuggable. >>> Ideally, the system should not display a window if an error is >>> triggered in the displayOn. >>> >>> Do you have any recommandation/conviention/enhancement to prevent the >>> image to hang when an error is signaled in a displayOn. This is >>> really >>> annoying. >>> >>> 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

Feb. 14, 2009

Re: [Pharo-project] Boring confirmation message...

by Schwab,Wilhelm K

Alexandre, There is a preference for confirm on close or something like that - I think. Your test for change in value is an interesting idea, but I am often willing/expecting to toss whatever I type into an inspector. I very much want the system to warn me if I am about to discard code in the debugger or browser source pane, and certainly in workspaces. Bill ---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Alexandre Bergel [Alexandre.Bergel(a)inria.fr] Sent: Saturday, February 14, 2009 2:09 PM To: Pharo Development Subject: [Pharo-project] Boring confirmation message... Hi All, Often, I do a print-it in a debugger or browser. For some mysterious reason, I subsequently press the delete key that erases what was just print. Some changes occurred therefore. When I then select another method (or frame if I am in a debugger), a confirmation whether I want to save my changes is done. I find this very boring. Am i the only one ? A simple check whether the textual content has been modified would prevent this stupid question. 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

Feb. 14, 2009

[Pharo-project] Boring confirmation message...

by Alexandre Bergel

Hi All, Often, I do a print-it in a debugger or browser. For some mysterious reason, I subsequently press the delete key that erases what was just print. Some changes occurred therefore. When I then select another method (or frame if I am in a debugger), a confirmation whether I want to save my changes is done. I find this very boring. Am i the only one ? A simple check whether the textual content has been modified would prevent this stupid question. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 14, 2009

Re: [Pharo-project] Debugging with morphic

by Gary Chambers

More often than not the emergency evaluator can save you from having to reload changes... Otherwise, save often after careful consideration and before likely dangerous changes. Not a huge hassle to relaunch and load the last changes either though. Regards, Gary ----- Original Message ----- From: "Alexandre Bergel" <alexandre(a)bergel.eu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Saturday, February 14, 2009 6:29 PM Subject: Re: [Pharo-project] Debugging with morphic >I was just wondering how you guys debug your morphic programming. > There is probably something wrong in the way I do. I cannot imagine > people have been doing some morphic for so long without having a > simple way to debug it. > > Cheers, > Alexandre > > > On 14 Feb 2009, at 18:26, Gary Chambers wrote: > >> I'm sure I can come up with something... you obvioulsy want some >> kind of >> debugger if an error occurs. >> The taskbar works effectively synchronously with the display and >> should >> handle self inflicted errors. >> Other display errors *should* get managed by the #errorOnDraw thing, >> but not >> always it would seem. >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Alexandre Bergel" <Alexandre.Bergel(a)inria.fr> >> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Saturday, February 14, 2009 4:53 PM >> Subject: [Pharo-project] Debugging with morphic >> >> >>> Hi All (and especially the Pinesoft crew), >>> >>> When an error is triggered by a displayOn: method, the bottom bar is >>> being filled with debugger windows. It then become hardly debuggable. >>> Ideally, the system should not display a window if an error is >>> triggered in the displayOn. >>> >>> Do you have any recommandation/conviention/enhancement to prevent the >>> image to hang when an error is signaled in a displayOn. This is >>> really >>> annoying. >>> >>> 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

Feb. 14, 2009

Re: [Pharo-project] Sends unknown message to global

by Gary Chambers

Thanks. Spotted and refactored. Regards, Gary ----- Original Message ----- From: "Lukas Renggli" <renggli(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Saturday, February 14, 2009 5:55 PM Subject: Re: [Pharo-project] Sends unknown message to global >> I do not know >> It would be good if lukas could improve the quality of the report of >> SmallLint. > > If you select the rule and click on browse, it lists all the > occurences and also highlights the offending code. > > 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

Feb. 14, 2009