- Pharo-dev - lists.pharo.org

Re: [Pharo-project] WebClient License Update

by Philippe Marschall

On 09.09.2010 04:27, Andreas Raab wrote: > Phillipe wrote: >> Did you change your position towards #squeakToUtf8 and string >> concatenation (I didn't follow the entire previous thread)? > > Implicitly yes, That's fine. > but let's discuss this. Personal coding styles are a matter of taste, no way we ever reach a consensus (the discussion that will go nowhere has already started). > You're saying you want WebClient > "without overrides" but is this really what you mean? The only reason > these methods are marked overrides is so that they don't kill your > system if the methods themselves get added to the system at some point. > For example, Grease currently adds extension methods for > Collection>>sorted but these methods are already in Squeak and while > nothing harmful happens if you load Grease, unloading it will destroy > several methods. As a consequence it is vastly advantageous to mark > methods as overrides if they have even the slightest possibility to > conflict (but of course if you'd rather have them straightforward > extensions, I have no problems with that). We need to fix that, thanks for pointing that out. > As for integrating the changes itself, I think that we're talking two > very different issues here. I suspect that the only objection to > #squeakToUtf8 and #utf8ToSqueak is that they have "Squeak" in their > name. I don't think you'd have any objection if they would've been > called #utf8Encoded and #utf8Decoded. Which, honestly, is a childish > attitude from my point of view. > > For string concatenation on the other hand, we're basically talking > about dispersing a whole load of FUD about all the things that "may" go > wrong. Fact is, nothing actually *does* go wrong with the change, but > the change does fix situations that are *very* difficult to handle > otherwise. One of the unfortunate realities of string concatenation is > that it's very often used around error messages and logging, often in > corner cases that aren't well tested, like: > > <some impossible condition> ifTrue:[ > self log: 'Found impossible condition: ', foo. > ]. > > The problem with these uses is that it's quite easy to forget some > asString, or #printString (for example, if you generally had expected > foo to be a string but in the impossible condition it's actually nil) > and when you hit the condition your logging screws up and instead of > getting informed about the impossible condition the program quits due to > the error. In fact, I'm willing to bet that there's at least one bug in > Pharo and/or Seaside which is the result of erroneous string > concatenation of this kind. It's just very easy to get wrong. > > The other relevant bit about this change is that it's entirely > type-safe. I.e., the return type does not depend on the argument, the > return type is always a string. That means that the change does *not* > introduce failures down the road due to type violations. It *does* mean > that if you have a bug in your code you might print "a SomethingOrOther" > when you didn't mean to, but unless you're the kind of person who > believes that a program that doesn't raise an error must be obviously > correct, this makes little difference. The only difference it makes is > that your program will not abort when the *intention* is so utterly > obvious. > > Put differently, the change adds nothing but robustness to the system. > There is really no data to back up the FUD about all the changes that > "may" go wrong, but from my experience there is ample evidence to show > that logging and error handling involving string concatenation is highly > susceptible to this kind of problem and generally not very well tested > and difficult to QA. And the major use of string concatenation is right > in these areas. > > Last but not least, programming is about efficiency. Why would you waste > your time in typing 'The result is: ', x printString" when you could > just type "'The result is: ', x" and spare the time to write all the > extra characters? Do you realize how much time you've wasted sprinkling > all those #printString and #asString around WebClient? Cheers Philippe

Sept. 9, 2010

Re: [Pharo-project] WebClient License Update

by Douglas Brebner

On 09/09/2010 03:27, Andreas Raab wrote: > For string concatenation on the other hand, we're basically talking > about dispersing a whole load of FUD about all the things that "may" > go wrong. Fact is, nothing actually *does* go wrong with the change, > but the change does fix situations that are *very* difficult to handle > otherwise. One of the unfortunate realities of string concatenation is > that it's very often used around error messages and logging, often in > corner cases that aren't well tested, like: > > <some impossible condition> ifTrue:[ > self log: 'Found impossible condition: ', foo. > ]. > I'm not sure how important this is considered in Squeak/Pharo, especially in this context, but isn't this sort of output string manipulation a definite no-no from an i18n viewpoint?

Sept. 9, 2010

Re: [Pharo-project] WebClient License Update

by Henrik Johansen

On Sep 9, 2010, at 4:27 50AM, Andreas Raab wrote: > Phillipe wrote: > > Did you change your position towards #squeakToUtf8 and string > > concatenation (I didn't follow the entire previous thread)? > > Implicitly yes, but let's discuss this. You're saying you want WebClient "without overrides" but is this really what you mean? The only reason these methods are marked overrides is so that they don't kill your system if the methods themselves get added to the system at some point. For example, Grease currently adds extension methods for Collection>>sorted but these methods are already in Squeak and while nothing harmful happens if you load Grease, unloading it will destroy several methods. As a consequence it is vastly advantageous to mark methods as overrides if they have even the slightest possibility to conflict (but of course if you'd rather have them straightforward extensions, I have no problems with that). > > As for integrating the changes itself, I think that we're talking two very different issues here. I suspect that the only objection to #squeakToUtf8 and #utf8ToSqueak is that they have "Squeak" in their name. I don't think you'd have any objection if they would've been called #utf8Encoded and #utf8Decoded. Which, honestly, is a childish attitude from my point of view. Yeesh. I can only speak for myself, but my objection to the methods is more that I don't think knowing how to change its contents to a specific encoding should be the responsibility of the String class. Yes, there are plenty of other comparable delegations of responsibility, but in this case it is easily avoided. Sure though, it's a bit faster in some cases than the alternatives using convertToWithConverter:, or convertToEncoding: (at least with a symbol -> converter cache added), but with the general improvements to UTF8TextConverter the speedup is no longer measured in the orders of magnitudes, where it might feel worth it (to me). > > For string concatenation on the other hand, we're basically talking about dispersing a whole load of FUD about all the things that "may" go wrong. Fact is, nothing actually *does* go wrong with the change, but the change does fix situations that are *very* difficult to handle otherwise. One of the unfortunate realities of string concatenation is that it's very often used around error messages and logging, often in corner cases that aren't well tested, like: > > <some impossible condition> ifTrue:[ > self log: 'Found impossible condition: ', foo. > ]. > > The problem with these uses is that it's quite easy to forget some asString, or #printString (for example, if you generally had expected foo to be a string but in the impossible condition it's actually nil) and when you hit the condition your logging screws up and instead of getting informed about the impossible condition the program quits due to the error. In fact, I'm willing to bet that there's at least one bug in Pharo and/or Seaside which is the result of erroneous string concatenation of this kind. It's just very easy to get wrong. > > The other relevant bit about this change is that it's entirely type-safe. I.e., the return type does not depend on the argument, the return type is always a string. That means that the change does *not* introduce failures down the road due to type violations. It *does* mean that if you have a bug in your code you might print "a SomethingOrOther" when you didn't mean to, but unless you're the kind of person who believes that a program that doesn't raise an error must be obviously correct, this makes little difference. The only difference it makes is that your program will not abort when the *intention* is so utterly obvious. > > Put differently, the change adds nothing but robustness to the system. There is really no data to back up the FUD about all the changes that "may" go wrong, but from my experience there is ample evidence to show that logging and error handling involving string concatenation is highly susceptible to this kind of problem and generally not very well tested and difficult to QA. And the major use of string concatenation is right in these areas. While I see some value in your arguments, in addition to Pharo, at least the VW, GST and ST-X dialects, plus the ANSI standard, do not allow it. IE, if you want to write your code the least bit portable, you include the ugly as/printString sends. Cheers, Henry

Sept. 9, 2010

Re: [Pharo-project] WebClient License Update

by Miguel Enrique CobÃ¡ MartÃnez

El miÃ©, 08-09-2010 a las 19:27 -0700, Andreas Raab escribiÃ³: It is amazing how square-minded you are. All this diatribe was nothing but to defend the current state of the code you write. > Phillipe wrote: > > Did you change your position towards #squeakToUtf8 and string > > concatenation (I didn't follow the entire previous thread)? > Implicitly yes, but let's discuss this. You're saying you want WebClient > "without overrides" but is this really what you mean? The only reason > these methods are marked overrides is so that they don't kill your > system if the methods themselves get added to the system at some point. > For example, Grease currently adds extension methods for > Collection>>sorted but these methods are already in Squeak and while > nothing harmful happens if you load Grease, unloading it will destroy > several methods. As a consequence it is vastly advantageous to mark > methods as overrides if they have even the slightest possibility to > conflict (but of course if you'd rather have them straightforward > extensions, I have no problems with that). So now overrides are encouraged? > > As for integrating the changes itself, I think that we're talking two > very different issues here. I suspect that the only objection to > #squeakToUtf8 and #utf8ToSqueak is that they have "Squeak" in their > name. I don't think you'd have any objection if they would've been > called #utf8Encoded and #utf8Decoded. Which, honestly, is a childish > attitude from my point of view. > Well then lets rename withBlanksTrimmed to, lets say, windowsWithBlankTrimmed, or maybe lispWithBlankTrimmed, or better yet, asdfAsdfASDF. The name must be right, no matter what you personally think. > For string concatenation on the other hand, we're basically talking > about dispersing a whole load of FUD about all the things that "may" go > wrong. Fact is, nothing actually *does* go wrong with the change, but > the change does fix situations that are *very* difficult to handle > otherwise. One of the unfortunate realities of string concatenation is > that it's very often used around error messages and logging, often in > corner cases that aren't well tested, like: > > <some impossible condition> ifTrue:[ > self log: 'Found impossible condition: ', foo. > ]. > Maybe in practice happens. That is not a excuse to put the burden in the environment and let the software that relies in wrong code remain unfixed. If some package hits the error, the right thing is to fix the package, not to put trash in the environment just in case. This promotes mean software > The problem with these uses is that it's quite easy to forget some > asString, or #printString (for example, if you generally had expected > foo to be a string but in the impossible condition it's actually nil) > and when you hit the condition your logging screws up and instead of > getting informed about the impossible condition the program quits due to > the error. In fact, I'm willing to bet that there's at least one bug in > Pharo and/or Seaside which is the result of erroneous string > concatenation of this kind. It's just very easy to get wrong. Idem. If that is the case, then Seaside must be corrected. > > The other relevant bit about this change is that it's entirely > type-safe. I.e., the return type does not depend on the argument, the > return type is always a string. That means that the change does *not* > introduce failures down the road due to type violations. It *does* mean > that if you have a bug in your code you might print "a SomethingOrOther" > when you didn't mean to, but unless you're the kind of person who > believes that a program that doesn't raise an error must be obviously > correct, this makes little difference. The only difference it makes is > that your program will not abort when the *intention* is so utterly obvious. > Wrong, I prefer it abort loudly so I now that there is something wrong in the package and I can fix it, not hide it because the environment somehow worked around it. > Put differently, the change adds nothing but robustness to the system. > There is really no data to back up the FUD about all the changes that > "may" go wrong, but from my experience there is ample evidence to show > that logging and error handling involving string concatenation is highly > susceptible to this kind of problem and generally not very well tested > and difficult to QA. And the major use of string concatenation is right > in these areas. So your experience is real data to back up your claims but others isn't. BS! > > Last but not least, programming is about efficiency. Umm, wasn't Smalltalk about intention-reveling code. Wasn't adviced everytime that premature optimization is evil. Since when Smalltalk was about efficiency. Isn't C programming. > Why would you waste > your time in typing 'The result is: ', x printString" when you could > just type "'The result is: ', x" and spare the time to write all the > extra characters? Do you realize how much time you've wasted sprinkling > all those #printString and #asString around WebClient? So, if you are tagging the effort that they put in modifying WebClient as wasted time, then I think there is nothing to discuss between the possible contributors and you. This is not a dialog or a discussion is an intransigent monologe. -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Sept. 9, 2010

Re: [Pharo-project] WebClient License Update

by Andreas Raab

Phillipe wrote: > Did you change your position towards #squeakToUtf8 and string > concatenation (I didn't follow the entire previous thread)? Implicitly yes, but let's discuss this. You're saying you want WebClient "without overrides" but is this really what you mean? The only reason these methods are marked overrides is so that they don't kill your system if the methods themselves get added to the system at some point. For example, Grease currently adds extension methods for Collection>>sorted but these methods are already in Squeak and while nothing harmful happens if you load Grease, unloading it will destroy several methods. As a consequence it is vastly advantageous to mark methods as overrides if they have even the slightest possibility to conflict (but of course if you'd rather have them straightforward extensions, I have no problems with that). As for integrating the changes itself, I think that we're talking two very different issues here. I suspect that the only objection to #squeakToUtf8 and #utf8ToSqueak is that they have "Squeak" in their name. I don't think you'd have any objection if they would've been called #utf8Encoded and #utf8Decoded. Which, honestly, is a childish attitude from my point of view. For string concatenation on the other hand, we're basically talking about dispersing a whole load of FUD about all the things that "may" go wrong. Fact is, nothing actually *does* go wrong with the change, but the change does fix situations that are *very* difficult to handle otherwise. One of the unfortunate realities of string concatenation is that it's very often used around error messages and logging, often in corner cases that aren't well tested, like: <some impossible condition> ifTrue:[ self log: 'Found impossible condition: ', foo. ]. The problem with these uses is that it's quite easy to forget some asString, or #printString (for example, if you generally had expected foo to be a string but in the impossible condition it's actually nil) and when you hit the condition your logging screws up and instead of getting informed about the impossible condition the program quits due to the error. In fact, I'm willing to bet that there's at least one bug in Pharo and/or Seaside which is the result of erroneous string concatenation of this kind. It's just very easy to get wrong. The other relevant bit about this change is that it's entirely type-safe. I.e., the return type does not depend on the argument, the return type is always a string. That means that the change does *not* introduce failures down the road due to type violations. It *does* mean that if you have a bug in your code you might print "a SomethingOrOther" when you didn't mean to, but unless you're the kind of person who believes that a program that doesn't raise an error must be obviously correct, this makes little difference. The only difference it makes is that your program will not abort when the *intention* is so utterly obvious. Put differently, the change adds nothing but robustness to the system. There is really no data to back up the FUD about all the changes that "may" go wrong, but from my experience there is ample evidence to show that logging and error handling involving string concatenation is highly susceptible to this kind of problem and generally not very well tested and difficult to QA. And the major use of string concatenation is right in these areas. Last but not least, programming is about efficiency. Why would you waste your time in typing 'The result is: ', x printString" when you could just type "'The result is: ', x" and spare the time to write all the extra characters? Do you realize how much time you've wasted sprinkling all those #printString and #asString around WebClient? Cheers, - Andreas

Sept. 9, 2010

Re: [Pharo-project] simpleLog in pharo?

by GÃ¶ran Krampe

Hi! On 09/09/2010 01:18 AM, Schwab,Wilhelm K wrote: > GÃ¶ran, > > I think before we adopt anything, it should have the "left running" scenario addressed in some way. Pharo is supposed to be robust. > That mean losing the silent failures, and doing so in a way that the new information does not bring the system to its knees. First - I did not bring this up, so feel free to fix any flaws you see/find :). The code base is very small. Secondly - my impression of Pharo so far is not really "robust", and don't get me wrong here - it is not criticism, but my feeling every time I have used Pharo is that it is smack full of new stuff (completion, OB browsers etc etc) which quite often seems to break and also makes it painful to develop on my old trusty kinda slow Dell laptop. It seems to me that "progress" (new shiny stuff!) has been put in favor of robustness, which probably is why Pharo is attractive to a lot of people. Perhaps Pharo changed focus for next release? Sorry for that little rant, don't really "mean" anything with it, just curious to see if I am the only one with this feeling. > On Windows, OutputDebugString() is probably good enough. Since I am doing everything I can to ditch said platform, I might not be the best person to ask. Certainly, it is where I would go for a live view, and a file-based log would then cover everything else - I think. > > On Linux, you mention lots of tools: any recommendations? No :). But there are lots of syslog related tools, just google it. :) regards, GÃ¶ran

Sept. 8, 2010

Re: [Pharo-project] simpleLog in pharo?

by Schwab,Wilhelm K

GÃ¶ran, I think before we adopt anything, it should have the "left running" scenario addressed in some way. Pharo is supposed to be robust. That mean losing the silent failures, and doing so in a way that the new information does not bring the system to its knees. On Windows, OutputDebugString() is probably good enough. Since I am doing everything I can to ditch said platform, I might not be the best person to ask. Certainly, it is where I would go for a live view, and a file-based log would then cover everything else - I think. On Linux, you mention lots of tools: any recommendations? Thanks! Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of GÃ¶ran Krampe [goran(a)krampe.se] Sent: Wednesday, September 08, 2010 6:57 PM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] simpleLog in pharo? On 09/08/2010 10:50 PM, Schwab,Wilhelm K wrote: > You mention something for viewing the log in-image. Dumb question: can it be left running and safely forgotten, or does it suffer > under high load? Is there a way to view the log from outside of a running image? The latter is less important in proportion > to the robustness of the in-image viewer. One thing that I often miss is DebugView; it would be really nice to find an equivalent on Linux. > > Bill SimpleLog has a LogMorph, I didn't write it but it registers itself as an emitter. Not sure what it does if it is "left running" :) It could probably use a "max backlog" or something, if it doesn't have that already. Viewing the log from outside: There are two "ways". First there is a logfile emitter - which writes to a log file and also does log file rotation after a max size etc. So you could always "tail" that file. Second is to use the syslog emitter - which IMHO is the best. That emitter uses syslog UDP standard messages to the local syslog port and then - on a normal linux box - your stuff will end up in the system log. From there you have TONS of tools. regards, GÃ¶ran _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 8, 2010

Re: [Pharo-project] [squeak-dev] How to install Glorp

by GermÃ¡n Arduino

Thanks Mariano, it worked ok now! Cheers. GermÃ¡n. 2010/9/8 Mariano Martinez Peck <marianopeck(a)gmail.com>: > In pharo: > > > Gofer new > Â Â Â squeaksource: 'MetacelloRepository'; > Â Â Â package: 'ConfigurationOfGlorpDBX'; > Â Â Â load. > > and then > > > (ConfigurationOfGlorpDBX project version: '1.2') load > will install SqueakDBX as the database driver and Glorp-SqueakDBXDriver > > > (ConfigurationOfGlorpDBX project version: '1.2') load: 'GlorpSqueakDBX Pool' > > will install SqueakDBX as the database driver and a Glorp-SqueakDBXDriver > that acts as a connection pool :)Â Â Â Â (altought this only works in 1.0 right > now) > > > (ConfigurationOfGlorpDBX project version: '1.2') load: 'All with PostgreSQL > native' > will install the native postgresql driver > > Cheers > > Mariano > > BTW: you can find more info here (but it is outdated): > http://www.squeakdbx.org/GLORP%20integration > > > On Thu, Sep 9, 2010 at 12:19 AM, GermÃ¡n Arduino <garduino(a)gmail.com> wrote: >> >> Hi Squeakers and Pharoers: >> >> Even when I saw several mails about the topic, I failed to install >> Glorp properly, on Squeak (4.1) and also on Pharo (4.1). >> >> No matter what method I try, or which Glorp .mcz, I allways get the >> attached error, referencing some weird oracle thing. >> >> I'm new to Glorp, I might be forgetting something obvious, but in any >> case, any help is appreciated >> >> Thanks. >> >> >> -- >> ================================================= >> GermÃ¡n S. ArduinoÂ <gsa @ arsol.net>Â Â Twitter: garduino >> Arduino Software & Web HostingÂ Â http://www.arduinosoftware.com >> PasswordsProÂ http://www.passwordspro.com >> ================================================= >> >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- ================================================= GermÃ¡n S. ArduinoÂ <gsa @ arsol.net>Â Â Twitter: garduino Arduino Software & Web HostingÂ Â http://www.arduinosoftware.com PasswordsProÂ http://www.passwordspro.com =================================================

Sept. 8, 2010

Re: [Pharo-project] simpleLog in pharo?

by GÃ¶ran Krampe

On 09/08/2010 10:50 PM, Schwab,Wilhelm K wrote: > You mention something for viewing the log in-image. Dumb question: can it be left running and safely forgotten, or does it suffer > under high load? Is there a way to view the log from outside of a running image? The latter is less important in proportion > to the robustness of the in-image viewer. One thing that I often miss is DebugView; it would be really nice to find an equivalent on Linux. > > Bill SimpleLog has a LogMorph, I didn't write it but it registers itself as an emitter. Not sure what it does if it is "left running" :) It could probably use a "max backlog" or something, if it doesn't have that already. Viewing the log from outside: There are two "ways". First there is a logfile emitter - which writes to a log file and also does log file rotation after a max size etc. So you could always "tail" that file. Second is to use the syslog emitter - which IMHO is the best. That emitter uses syslog UDP standard messages to the local syslog port and then - on a normal linux box - your stuff will end up in the system log. From there you have TONS of tools. regards, GÃ¶ran

Sept. 8, 2010

Re: [Pharo-project] A thought about the fear of not knowing

by Christoph Budzinski

Kudos to you, it's always nice to see when programmers try to take the fear out of the equasion :) I think the terms experts and gurus should be completely abolished. It just strucks fear into the hearts of new programmers. What the heck is a guru? Or an expert? Someone who learnt a few nice little tricks over the years? Or knows a few kinks of a system? Well, I say nay! If there's a kink in a system it should be fixed, it shouldn't be a feeding ground for experts. And if someone knows a neat little trick, like a really fast implementation of an algorithm, what good is that when you actually don't need the speed in that place but think that readable code for example is much more important to you, so that maybe other people can understand and modify it. Implementing something is always a tradeoff between speed, stability, security and readability. There is not one perfect fits all solution to any one problem, which is why I don't think that experience really helps as much as people tend to believe. The most important thing for a programmer in my humble opinion is that he is good at learning. That includes being patient and persistent, being able to research things by using cryptic programmer's documentation and articles you find on Google. If you try long enough, you can make your implementation as fast, as stable, as secure or as readable as you need. The most important thing is to get it working, then you can think about making it better. And that is one huuuuge strength of Pharo. The refactoring tools are awesome. There really is no need to fear doing something horribly wrong since you can refactor everything to your hearts content until it's just the way you want it to be semi-automagically. Experience can also really hinder you as a programmer. If you always do the same thing again because it worked good in the past, you will never find a better way of doing things. If everyone did that, we would still be in the stone age. "Why do I need a metal hammer when a stone hammer works just fine?" The only valid term I can think of would be a "specialist". I have no idea how to write a device driver for example. That's something where experience is really helpful. But just because someone is really good at making device drivers doesn't mean he's good at making a game for example. So, he's not an expert programmer by any means, he's a specialist. You wouldn't let a dentist do brain surgery on you, would you? I don't think you can be an expert programmer. Programming is just too vast a topic. Computers are a second world. You can model the whole world in a computer. And just like you can't be an expert at every job on earth, you can't be a "computer expert". It's just not possible with our brain's limited capacity. Chris On Wed, Sep 8, 2010 at 10:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hi Pharoers, lurkers, users > > We repeat all over the same: we welcome you to participate and while we are > cool and welcoming, you feel > "oh I cannot, I do not know, this is complex..." > You look at us like Gurus, but let us be clear, we are not, we are just > common people that have a debugger, > kids in the bed and good music in the background (for me Cool Jazz or > Thrash Metal). > Of course some parts of the system are ugly, buggy, britlle, messy... but > less and less, more and more good abstractions are taking life > AND!!!! > First, we are all learners and newbie on something (at least the > mortal among us) but to learn > we should start somewhere > Second, start small > - we tag some bug entries as easy, give a try. > - put a break point in the code > - write a test > - do something fun > > You will not fail, why? because either you do not find anything and > there is no problem but you will > learn something and you can pass to the next one. > Or you find something and you got it :) > > We did that with marcus when we were squeak harvesters. There were a lot of > things we could not get > but we pass to the next. :) > > Now I browse bugs bugs and bugs and I can tell you that 85% of the bugs are > terribly stupid. Even more. > So focus on these ones :) > > Pharo is the system we (you and us) will build. > > Stef > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 8, 2010