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

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

by Miguel Enrique CobÃ¡ MartÃnez

El jue, 09-09-2010 a las 18:01 +0200, Levente Uzonyi escribiÃ³: > > When should one complain? Never, they should ask for help, maybe file a bug, or better help to fix it and improve the system, but not complain. The contributors and people around Pharo are doing it in their free time for different reasons, but that doesn't means that they are somehow obliged or forced to make the system compatible for everyone and every situation and posible combination of factors, including, time, backward compatibility, API stability, technical support. The code as MIT says, is take it as it is: THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. So if works for you fine. If breaks your code, sorry. If works in this version and the next don't, I feel sorry for you. Of course this isn't what happens regularly in an FOSS project, as the developers are proud to have a system that works correctly in most reasonable situations and they are by their nature very helpful people. But that is just because the good faith of the developers, not their obligation. So, yes, Pharo 1.0 was released and inmediatly Pharo 1.1 was worked out, changing the focus to the new version. If that means that people will have a couple hitches when migrating in order to use the newest changes, then that is a little price to pay (not monetary, but a price nonetheless). The backwards compatibility could be a good thing, but in this little community, we don't have the energy and people to try to do it always. And even if we had them, we don't want to. Neither the big bucks companies. Else, we'll still have 5in drives in our gorgeous Macbook Pro. Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Sept. 9, 2010

Re: [Pharo-project] WebClient License Update

by StÃ©phane Ducasse

BTW andreas I was reading your changes in squeak about fileList -> FileServices and I noticed that there is a bug there is one method missing suffixOf: in FileServices and I sent a notification in squeak-dev so may be you see it. I did not have the time to produce a fix but this is an easy one. Stef On Sep 9, 2010, at 4:27 AM, 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. > > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 9, 2010

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

by StÃ©phane Ducasse

> > > I'm sure they didn't pay for this. > > "Now Squeak/Pharo comes with no warranties, as the license states. So > don't complain because when migrating to a new version *you* must adapt > your code to the new environment. That is expected and nothing to whine > of. If you want that a system runs unchanged for decades, the use a > environment that doesn't change for decades. And remain there, as the > world lets you behind." > > When should one complain? Of course people can complain. Now do you use pharo? And squeak is changing too so where is the difference. Stef

Sept. 9, 2010

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

by StÃ©phane Ducasse

Why are you so aggressive against us? Now if you want status quo why do you even commit in squeak? Now I'm not sure that this is the kind of >>> Isn't Grease dialect dependent by essence ? >>> If Pharo and Squeak diverge, then there will naturally be two versions >>> of Grease... >>> However, for these two messages, I think Pharo core should integrate >>> them and align with Squeak. The question is more whether you need to >>> distinguish Grease-Pharo1_1 from Grease-Pharo1_2 ... >> >> Probably else this means that Pharo and any system is bound to die because >> it does not change. > > The rapid changes and no-backwards-compatibility you prefer and advocate are not essential for a Smalltalk system to "stay alive". Just look at VSE, it didn't change in the last 10 years, and people are still using it. > In constrast Pharo 1.0 was considered abandonware four months after it's release, which caused trouble for some users who didn't think that they'll have to patch their code and rebuild their images to "get" updates/fixes. Pharo1.0 is not abandoned at all. Since 1.0 we got more than 1000 bugs closed. The versions are just a way to have milestones. Now there is no problem you think otherwise Stef

Sept. 9, 2010

Re: [Pharo-project] Cog Segmentation Fault with Pharo 1.1

by GermÃ¡n Arduino

ahh, Thanks Levente, sorry was my fault, I forgot this detail. 2010/9/9 Levente Uzonyi <leves(a)elte.hu>: > On Thu, 9 Sep 2010, GermÃ¡n Arduino wrote: > >> Hi: >> >> I was playing a bit with a stock Pharo 1.1 image, with the only adding >> of the cs NecessaryImageChangesForCogToWork.Pharo1.1. >> >> Then I tried to run TestRunner new runAll (for comparing times against >> the common vm) and get the attached segfault. >> >> I tried with my own compiled cog and also with the downloaded from >> here http://www.mirandabanda.org/files/Cog/VM/VM.r2219/. >> >> My OS is Ubuntu 10.04 64 bits. >> >> Any hint will be appreciated. > > ObjectsAsMethods is not supported, so TestObjectsAsMethods will crash the > VM. > > > Levente > >> >> Cheers. >> >> -- >> ================================================= >> 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 >

Sept. 9, 2010

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

by Levente Uzonyi

On Thu, 9 Sep 2010, Miguel Enrique CobÃ¡ MartÃnez wrote: > El jue, 09-09-2010 a las 16:01 +0200, Levente Uzonyi escribiÃ³: > On Thu, 9 Sep 2010, StÃ©phane Ducasse wrote: > > > > >> Isn't Grease dialect dependent by essence ? > >> If Pharo and Squeak diverge, then there will naturally be two versions > >> of Grease... > >> However, for these two messages, I think Pharo core should integrate > >> them and align with Squeak. The question is more whether you need to > >> distinguish Grease-Pharo1_1 from Grease-Pharo1_2 ... > > > > Probably else this means that Pharo and any system is bound to die because > > it does not change. > > The rapid changes and no-backwards-compatibility you prefer and advocate > are not essential for a Smalltalk system to "stay alive". Just look at > VSE, it didn't change in the last 10 years, and people are still using it. > In constrast Pharo 1.0 was considered abandonware four months after it's > release, which caused trouble for some users who didn't think that they'll > have to patch their code and rebuild their images to "get" updates/fixes. "Yes but they paid support to remain backwards compatible. If I paid support and not get my system running in new versions then I really would be a fool for paying." I'm sure they didn't pay for this. "Now Squeak/Pharo comes with no warranties, as the license states. So don't complain because when migrating to a new version *you* must adapt your code to the new environment. That is expected and nothing to whine of. If you want that a system runs unchanged for decades, the use a environment that doesn't change for decades. And remain there, as the world lets you behind." When should one complain? Levente > > > Levente > > > > > This is why configurations are important. > > > > Stef > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 9, 2010

Re: [Pharo-project] Cog Segmentation Fault with Pharo 1.1

by Levente Uzonyi

On Thu, 9 Sep 2010, GermÃ¡n Arduino wrote: > Hi: > > I was playing a bit with a stock Pharo 1.1 image, with the only adding > of the cs NecessaryImageChangesForCogToWork.Pharo1.1. > > Then I tried to run TestRunner new runAll (for comparing times against > the common vm) and get the attached segfault. > > I tried with my own compiled cog and also with the downloaded from > here http://www.mirandabanda.org/files/Cog/VM/VM.r2219/. > > My OS is Ubuntu 10.04 64 bits. > > Any hint will be appreciated. ObjectsAsMethods is not supported, so TestObjectsAsMethods will crash the VM. Levente > > Cheers. > > -- > ================================================= > GermÃ¡n S. ArduinoÂ <gsa @ arsol.net>Â Â Twitter: garduino > Arduino Software & Web HostingÂ Â http://www.arduinosoftware.com > PasswordsProÂ http://www.passwordspro.com > ================================================= >

Sept. 9, 2010

[Pharo-project] Cog Segmentation Fault with Pharo 1.1

by GermÃ¡n Arduino

Hi: I was playing a bit with a stock Pharo 1.1 image, with the only adding of the cs NecessaryImageChangesForCogToWork.Pharo1.1. Then I tried to run TestRunner new runAll (for comparing times against the common vm) and get the attached segfault. I tried with my own compiled cog and also with the downloaded from here http://www.mirandabanda.org/files/Cog/VM/VM.r2219/. My OS is Ubuntu 10.04 64 bits. Any hint will be appreciated. Cheers. -- ================================================= GermÃ¡n S. ArduinoÂ <gsa @ arsol.net>Â Â Twitter: garduino Arduino Software & Web HostingÂ Â http://www.arduinosoftware.com PasswordsProÂ http://www.passwordspro.com =================================================

Sept. 9, 2010

Re: [Pharo-project] Changing the world menu

by StÃ©phane Ducasse

thanks! Stef On Sep 9, 2010, at 3:35 PM, Hilaire Fernandes wrote: > I have proposed a patch ready for integration to easily change the world > menu > > http://code.google.com/p/pharo/issues/detail?id=2930 > > Hilaire > > Le 09/09/2010 14:36, Alain Plantec a Ã©crit : >> >>>> Yes, what is missing is a way to reset the menuBuilder in the >>>> WorldState so that >>>> it creates a new one. >>> Is it what you are looking for ? >> argh, no, you need to re-create the menuBuilder with the new pragma >> keyword. >> and yes it is missing :( >> >> maybe something like: >> >> setMenuPragmaKeywordTo: aSymbol >> menuBuilder := PragmaMenuBuilder pragmaKeyword: aSymbol model: self >> >> Alain >> >> >>> >>> PasteUpMorph>>resetWorldMenu >>> menuBuilder >>> ifNotNil: [menuBuilder reset] >>> >>> >>> to be used as follow: >>> ---------- >>> World resetWorldMenu >>> ---------- >>> >>> Alain >>>> Marcus >>>> >>>> >>>> -- >>>> Marcus Denker -- http://www.marcusdenker.de >>>> INRIA Lille -- Nord Europe. Team RMoD. >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> > > > -- > Dr. Geo, to discover geometry on Linux, Windows, MAC and XO > http://community.ofset.org/index.php/DrGeo > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 9, 2010

Re: [Pharo-project] Building Cocoa 5.x series plugins, and testing help needed.

by Philippe Marschall

On 08.09.2010 20:42, John M McIntosh wrote: > > On 2010-09-08, at 3:34 AM, Philippe Marschall wrote: >> - #primCountry and #primLanguage seem to answer a three element String >> with the last element being a zero character (I assume a C string), this >> is not so nice. I'm not sure whether this should be fixed in the >> primitive or in the Pharo code. > > The primitive is answering a ISO 639-1 value (2 character) versus the ISO 639-2 value (3 character) > I have to figure out how to get the ISO 639-2 data, but it seems in looking it appears you'll get the 2 character > code versus the 3 character code on other platforms so I'll bet you need to deal with the case of 2 character codes. > The plugin assumes a 3 character value which is why you get the trailing null char. You'll need to deal with it. OK >> - All the primitives seem to totally ignore the locale id and only work >> on the system locale. This makes it a whole lot less useful. > > ? explain ? > > In the primitive I ask for "autoupdatingCurrentLocale" The current logical locale for the current user. The locale is formed from the settings for the current userâs chosen system locale overlaid with any custom settings the user has specified in System Preferences. The object always reflects the current state of the current user's locale settings. (Locale localeID: (LocaleID isoString: 'de-CH')) primCountry I mean, really? It totally ignores the locale id and answers the locale of the user. If that's the intended behavior why not move it to the class side of Locale? That would remove a lot of potential for confusion. The current behavior might make sense for a single classroom EToys image. It's not very helpful in a multiuser application where you want to format numbers and currencies according to the users locale. >> - I'm totally confused by the Current and CurrentPlatform class >> variables. What's the difference? Do we really need both? >> - I'm confused by #isoCountry vs #primCountry and #isoLangauge vs >> #primLanguage. Do we need both? What's the point? Is this what you meant >> which cleanup? > > Yes that would be cleanup.. OK, but see the problem above, #isoCountry comes from the locale id, #primCountry comes from the user locale. > There is also issues withe currency symbol, the logic assumes it's one byte, but it could be a unicode value > if you decide between the international symbol versus localized regional symbol. I think the plugin is flawed > in that respect. Answers 'SFr.' where quite nicely. Cheers Philippe

Sept. 9, 2010