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

[Pharo-project] Feature Request: Strict Compiler / Monticello Mode

by Philippe Marschall

Hi It seems like we unintentionally introduced an override for Collection >> #sorted in Grease. That puts in a hard place because we can't simply remove it from Grease. Because if you do that everybody who updates looses the method and potentially breaks his image. Yeah, I see that the real fix you be for Monticello to restore the old method but that hasn't happened in years. Monticello / the compiler already warns about a lot of less important things. Now I know adding an additional preference for that is ugly and I'd welcome and better/nicer solution. Cheers Philippe

Sept. 9, 2010

[Pharo-project] [update 1.2] #12127

by stephane ducasse

12127 ----- - 2920 and 2921: Some little recategorizations with Gabriela Arevalo, Gabriel Barbuto, Nicolas Paez and Martin Dias. Stef

Sept. 9, 2010

[Pharo-project] [update 1.1] #11413

by Marcus Denker

11413 ----- Issue 1068: Mac: Quit from host menu not working anymore Issue 2844: String>>#numArgs is broken Issue 2711: SmartRefStream (and hence also ImageSegment) are broken due to missing #convertToCurrentVersion:refStream: -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Sept. 9, 2010

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