- Pharo-dev - lists.pharo.org

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

by John M McIntosh

On 2010-09-09, at 8:21 AM, Philippe Marschall wrote: >> 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 Ok I've placed a LocalePlugin 2.1b1.bundle.zip on the server. It has a minor fix where I did the length calculation in UTF8 then asked for the data in MacRoman. Must not write email when tired. It's the currency decimal and grouping separators that are fixed as 1 byte. Also currency uses the international symbol(s) in UTF8 versus the regional value which might be different and at some different point in the unicode chart. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Sept. 9, 2010

Re: [Pharo-project] CompiledMethod

by Mariano Martinez Peck

Hi Benjamin. Yes, this is a known "problem". Check http://forum.world.st/problem-with-CompiledMethod-equality-tt2221276.html#a… 2010/9/9 Eliot Miranda <eliot.miranda(a)gmail.com> > > > 2010/9/9 Benjamin Van Ryseghem <benjamin.vanryseghem(a)gmail.com> > > Hi everybody, >> >> >> I wonder if it's normal than two different methods can have the same >> CompiledMethod ? >> >> By example : >> >> Class >> foo >> 'foo' >> >> and >> >> Class >> foo2 >> 'foo' >> >> If I evaluate (Class methodDict at: #foo) = (Class methodDict at: #foo2), >> it answers true. >> >> Maybe the CompiledMethod >> = should test the source ? >> > > There are many definitions of method equality. If you ant to test the > source you can test the source, (C >> #foo) getSourceFromFile asString = (C > >> #foo2) getSourceFromFile asString. You can test the decompilation of a > method (C>>#foo) decompileString = (C>>#foo2) decompileString. > > The current definition tests whether the bytecodes and literals are the > same, not the selector or the source code. That's a useful definition, but > not the only one. It is close to the decompile version but faster, and is > useful in e.g. testing whether the compiler has changed, since if on > recompiling a method is still = the compiler is producing the same bytecode > for a compilation. That's what I use it for and it's an important use. > > cheers > Eliot > > >> >> >> Ben >> >> _______________________________________________ >> 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 >

Sept. 9, 2010

Re: [Pharo-project] DateAndTimeTest failures

by StÃ©phane Ducasse

Thanks Pavel I have been thinking a lot about you recently. I started to create a lot of bug entries remodularisation (and I got trapped by time - today an obligatory meeting starting a 12h on account certification :) and ended up at 17h :) I will continue and I saw to nicolas and gabriel how they can help going over your issues and the new ones I'm creating. Stef On Sep 9, 2010, at 6:30 PM, Pavel Krivanek wrote: > Hi, > > I tried to fix DateAndTimeTest failures, see > http://code.google.com/p/pharo/issues/detail?id=2936 > > The patch adds methods clearOffset and withoutOffset to DateAndTime. > > Cheers, > -- Pavel > > _______________________________________________ > 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] simpleLog in pharo?

by Schwab,Wilhelm K

GÃ¶ran, Re "left running," while it is not my intention to throw up the knee-jerk "NO" that has been so common in other projects, I do think we should demand a torture test of any logging system that we adopt. If it can't be started and safely forgotten, it isn't ready. Is the code base small because it is simple and elegant (good) or because it is missing a lot of functionality to let it pass the set and forget test? I don't know the answer, but the question must be asked, and my vote is to adopt only after the answer is favorable. Your observation about new tools is well taken. Your experience on an old laptop is very interesting. If you really want to watch a struggle, compare Pharo to Dolphin running across a remote desktop connection. I am no Morphic expert, but it makes me wonder just how much of the screen is being redrawn and whether a lot of that could be avoided. Good performance on modest hardware is of value. You mention "shiny new stuff," but that is largely in the IDE or parallel systems (e.g. Nile, Ocean). The alternative is to continue to languish with Squeak's streams, sockets, file system, etc. Parts of Squeak are the way they are because they predate structured exception handling. Pharo is catching up on 15 years of refactoring to take advantage of 25 years of advancing technology. There will be some instability along the way, but the released versions have been pretty good so far. No doubt we can and should do better as Pharo evolves. 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 7:34 PM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] simpleLog in pharo? 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 _______________________________________________ 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] CompiledMethod

by Eliot Miranda

2010/9/9 Benjamin Van Ryseghem <benjamin.vanryseghem(a)gmail.com> > Hi everybody, > > > I wonder if it's normal than two different methods can have the same > CompiledMethod ? > > By example : > > Class >> foo > 'foo' > > and > > Class >> foo2 > 'foo' > > If I evaluate (Class methodDict at: #foo) = (Class methodDict at: #foo2), > it answers true. > > Maybe the CompiledMethod >> = should test the source ? > There are many definitions of method equality. If you ant to test the source you can test the source, (C >> #foo) getSourceFromFile asString = (C >> #foo2) getSourceFromFile asString. You can test the decompilation of a method (C>>#foo) decompileString = (C>>#foo2) decompileString. The current definition tests whether the bytecodes and literals are the same, not the selector or the source code. That's a useful definition, but not the only one. It is close to the decompile version but faster, and is useful in e.g. testing whether the compiler has changed, since if on recompiling a method is still = the compiler is producing the same bytecode for a compilation. That's what I use it for and it's an important use. cheers Eliot > > > Ben > > _______________________________________________ > 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

[Pharo-project] CompiledMethod

by Benjamin Van Ryseghem

Hi everybody, I wonder if it's normal than two different methods can have the same CompiledMethod ? By example : Class >> foo 'foo' and Class >> foo2 'foo' If I evaluate (Class methodDict at: #foo) = (Class methodDict at: #foo2), it answers true. Maybe the CompiledMethod >> = should test the source ? Ben

Sept. 9, 2010

[Pharo-project] DateAndTimeTest failures

by Pavel Krivanek

Hi, I tried to fix DateAndTimeTest failures, see http://code.google.com/p/pharo/issues/detail?id=2936 The patch adds methods clearOffset and withoutOffset to DateAndTime. Cheers, -- Pavel

Sept. 9, 2010

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