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

Re: [Pharo-project] impossible to move window :)

by StÃ©phane Ducasse

apparently when I take the latest beta I cannot move windows. So I will probably check and if necessary rollback stef On May 19, 2010, at 7:32 PM, Mariano Martinez Peck wrote: > I can. In 11367 > > On Wed, May 19, 2010 at 6:50 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > is it me or the latest beta introduced a nice behavior that make sure that you > cannot move windows anymore? > > 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

May 19, 2010

Re: [Pharo-project] Bug? ParagraphEditor do-its are not following the expected method lookup

by Carla F. Griggio

Not the cs, I have an st. It's in the first email of this thread. I also attached a cs with a possible fix. On Wed, May 19, 2010 at 4:35 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Yes this is an important bug > do you have the cs of your little example? > > Stef > > On May 19, 2010, at 9:17 PM, Carla F. Griggio wrote: > > > Just reproducing it would be helpful :O a friend of mine already > > tested the code I attatched and saw the same problem. > > > > If you recall having a class with a method sending a message to super, > > and a sublclass inheriting that method, you can try to reproduce it > > there too debugging that message on an instance of the subclass. > > > > It's not easy to explain with words, that's why I made a little > > package of code to illustrate the situation. > > > > The thing is that when printing the evaluation of a selected bunch of > > code inside a debugger window (paragraphEditor?), if the code you're > > evaluating is a message to super, and the class of the object you're > > debugging is inheriting the method you're debugging, the printed > > result will be wrong. In other words, the method lookup fails. > > > > This doesn't happen with normal excution of code (thank God!). > > > > I think this is an important bug, seeing those wrong results when > > debugging can be very confusing. I spent hours feeling stupid last > > Monday while debugging because I trusted those wrong results and > > couldn't see where I was doing something wrong :P > > > > Cheers! > > Carla > > > > On Wednesday, May 19, 2010, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > >> Hi Carla. I would like to help you, but I have no idea. I could > reproduce it. > >> > >> Maybe Lukas, Igor, Eliot etc can help you. I have no idea. > >> > >> Cheers > >> > >> Mariano > >> > >> 2010/5/18 Carla F. Griggio <carla.griggio(a)gmail.com> > >> Hi everybody! > >> Well, maybe you are already aware of this... maybe not. I tried to find > an issue about this and unless I didn't think of the right keywords, it's > not there. > >> > >> > >> > >> I was debugging a template method and sudenly I found myself spending > ours trying to find out why I got different results when printing the result > of a message sent to super and when steping into that message and printing > the (same) result there. > >> > >> > >> > >> Imagine this simple situation (I attatch the complete code and some > tests so you can reproduce this): > >> AverageTotalization inherits from > Totalization.WeightedAverageTotalization inherits from AverageTotalization. > >> > >> > >> > >> Totalization>>total > >> > >> ^self summatory > >> > >> > >> > >> > >> > >> AverageTotalization>>total > >> > >> ^(super total) / self denominator > >> > >> > >> > >> > >> > >> AverageTotalization>> denominator > >> > >> ^values size > >> > >> > >> > >> > >> WeightedAverageTotalization>> denominator > >> > >> "Weights is a dictionary" > >> > >> ^self weights values sum > >> > >> > >> > >> > >> If I debug aWeightedAverateTotalization total and try to print super > total in the debugger ParagraphEditor, I'll get this result: > >> > >> > >> > >> (self summatory / self denominator) > >> > >> > >> instead of just: > >> self summatory > >> This only happens when I print or inspect or other do-its in the > debugger window. The method lookup works OK when just > _______________________________________________ > >> 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 >

May 19, 2010

Re: [Pharo-project] Fwd: Re: Decoding bug with XMLParser ?

by StÃ©phane Ducasse

ok may be you should have said that before :) Now how this can be done? changing the EncodedCharSets? > initialize > > self allSubclassesDo: [:each | each initialize]. > > EncodedCharSets := Array new: 256. > > EncodedCharSets at: 0+1 put: Unicode "Latin1Environment". > EncodedCharSets at: 1+1 put: JISX0208. > EncodedCharSets at: 2+1 put: GB2312. > EncodedCharSets at: 3+1 put: KSX1001. > EncodedCharSets at: 4+1 put: JISX0208. Then I do not understand because EncodedCharSets at: 0+1 put: Unicode seems to me that this is already the case but may be I'm not looking at the right place. What are the implications? What will we break. Stef On May 19, 2010, at 9:06 PM, Philippe Marschall wrote: > On 19.05.2010 19:35, StÃ©phane Ducasse wrote: >>>> >>>> >>> >>> Currently the semantics in Pharo are >>> 0: Latin 1 >>> 255: Unicode >>> >>> which is fun because the first 255 characters are interned and you >>> therefore can't change their leadingChar. So if you're using Unicode, >>> you're forced to mix leachingChars. >> >> so what do you suggest to have unicode as zero? > > Yes, the decision of Squeak 4.1 to make Unicode leadingChar 0 is an > improvement. > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 19, 2010

Re: [Pharo-project] UUID on ubuntu 10.04

by StÃ©phane Ducasse

thanks probably the seaside one click does not have the latest vm Stef On May 19, 2010, at 9:02 PM, David T. Lewis wrote: > That is exactly how it works: > > UUID>>primMakeUUID > <primitive: 'primitiveMakeUUID' module: 'UUIDPlugin'> > UUIDGenerator default generateBytes: self forVersion: 4. > > > I added this to the Mantis issue: > > To summarize: The bug exists in some versions of libuuid on some Linux > distributions. The workaround is to compile the plugin internal. The > latest versions of Unix VM have the plugin compiled internally, although > some users may still experience problems if they have a leftover external > plugin from a prior installation. > > If you experience this problem, then get the latest Unix VM and delete > any existing copies of the external plugin. > > Resolved in latest Unix VMs. The UUID plugin must be compiled internally > to avoid a bug in some versions of libuuid. > > Hopefully this is an accurate summary. > > Dave > > On Wed, May 19, 2010 at 06:15:32PM +0200, St?phane Ducasse wrote: >> I'm not sure that it is resolved. It would be good to make sure that the system does not crash >> even without reporting a log. May be having a stupid UUID generator as a fallback would be good. >> >> Stef >> >>> Thanks, I marked the issue as resolved and summarized the status here: >>> >>> http://bugs.squeak.org/view.php?id=7358 >>> >>> Dave >>> >>> On Wed, May 19, 2010 at 09:42:28AM +0200, St?phane Ducasse wrote: >>>> Apparently the student reinstalled her ubuntu from scratch (no incremental installation) and the vm did not crash >>>> anymore. >>>> >>>> Stef >>>> >>>> On May 17, 2010, at 9:16 PM, St?phane Ducasse wrote: >>>> >>>>> I asked the student to try. >>>>> >>>>> Stef >>>>> >>>>> On May 17, 2010, at 9:06 PM, laurent laffont wrote: >>>>> >>>>>> On ArchLinux I have the problem when UUID is built external. Official 4.0.3.2202 Unix VM binaries on http://squeakvm.org/unix/ works well for me (UUID is internal). >>>>>> >>>>>> Can you try with this one click image I made once (uses 4.0.3.2202 binaries) http://lolgzs.free.fr/pharo/Pharo-1.0-OneClick.zip >>>>>> >>>>>> Laurent Laffont >>>>>> >>>>>> http://pharocasts.blogspot.com/ >>>>>> http://magaloma.blogspot.com/ >>>>>> >>>>>> >>>>>> On Mon, May 17, 2010 at 8:24 PM, St?phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>>> I can confirm that this is exactly the same trace than the one reported by laurent (no debug file). >>>>>> >>>>>> Stef >>>>>> On May 17, 2010, at 7:51 PM, David T. Lewis wrote: >>>>>> >>>>>>> On Mon, May 17, 2010 at 07:38:59PM +0200, St?phane Ducasse wrote: >>>>>>>> Hi guys >>>>>>>> >>>>>>>> I took seaside the latest one click image and when I have to save a MC package >>>>>>>> I get a core dump with UUID new:... >>>>>>>> I checke the so.UUIDplugin is there and I do not understand. >>>>>>>> Can somebody with a Ubuntu give a try to save something using MC and the latest seaside one click. >>>>>>> >>>>>>> Hi Stef, >>>>>>> >>>>>>> This issue is being tracked here: http://bugs.squeak.org/view.php?id=7358 >>>>>>> >>>>>>> It is not clear to me if the issue is resolved in the Ian's latest VM >>>>>>> build, so if you or anyone else can confirm the UUID crash happening >>>>>>> with this VM, that would be helpful to clarify. >>>>>>> >>>>>>> Dave >>> >>> _______________________________________________ >>> 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

May 19, 2010

Re: [Pharo-project] NetNameResolver in Pharo 1.1

by StÃ©phane Ducasse

MIguel which version of 1.1 because we rollback the changes so normally we should have now the same as in 1.0 Stef On May 19, 2010, at 8:48 PM, Miguel Enrique CobÃ¡ Martinez wrote: > El sÃ¡b, 08-05-2010 a las 17:54 +0200, Lukas Renggli escribiÃ³: >> In Pharo 1.0 there were some problems with the network stack (namely >> the NetNameResolver) and the IP6 code was reverted shortly before >> release, see the following issue for details: >> >> http://code.google.com/p/pharo/issues/detail?id=1884 >> >> Today I was checking with Stef for the presence of these problems in >> Pharo 1.1, but we could not reproduce neither on Mac, Windows nor >> Linux. Does anybody have problems with the following expressions in >> Pharo 1.1? >> >> NetNameResolver localHostAddress. >> NetNameResolver addressForName: 'www.yahoo.com'. >> >> Or are we doing the wrong thing to reproduce? >> >> Lukas > > Sorry for arriving late to the party :). > I tried the doits from the problem on Pharo 1.0 in a Pharo Core 11364 > image. I got some error, although not as severe as in Pharo 1.0. > > I added an issue for this > > http://code.google.com/p/pharo/issues/detail?id=2444 > > Now, I'm going to test with Magma to see if some other error shows > > Cheers > -- > 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

May 19, 2010

Re: [Pharo-project] Bug? ParagraphEditor do-its are not following the expected method lookup

by StÃ©phane Ducasse

Yes this is an important bug do you have the cs of your little example? Stef On May 19, 2010, at 9:17 PM, Carla F. Griggio wrote: > Just reproducing it would be helpful :O a friend of mine already > tested the code I attatched and saw the same problem. > > If you recall having a class with a method sending a message to super, > and a sublclass inheriting that method, you can try to reproduce it > there too debugging that message on an instance of the subclass. > > It's not easy to explain with words, that's why I made a little > package of code to illustrate the situation. > > The thing is that when printing the evaluation of a selected bunch of > code inside a debugger window (paragraphEditor?), if the code you're > evaluating is a message to super, and the class of the object you're > debugging is inheriting the method you're debugging, the printed > result will be wrong. In other words, the method lookup fails. > > This doesn't happen with normal excution of code (thank God!). > > I think this is an important bug, seeing those wrong results when > debugging can be very confusing. I spent hours feeling stupid last > Monday while debugging because I trusted those wrong results and > couldn't see where I was doing something wrong :P > > Cheers! > Carla > > On Wednesday, May 19, 2010, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> Hi Carla. I would like to help you, but I have no idea. I could reproduce it. >> >> Maybe Lukas, Igor, Eliot etc can help you. I have no idea. >> >> Cheers >> >> Mariano >> >> 2010/5/18 Carla F. Griggio <carla.griggio(a)gmail.com> >> Hi everybody! >> Well, maybe you are already aware of this... maybe not. I tried to find an issue about this and unless I didn't think of the right keywords, it's not there. >> >> >> >> I was debugging a template method and sudenly I found myself spending ours trying to find out why I got different results when printing the result of a message sent to super and when steping into that message and printing the (same) result there. >> >> >> >> Imagine this simple situation (I attatch the complete code and some tests so you can reproduce this): >> AverageTotalization inherits from Totalization.WeightedAverageTotalization inherits from AverageTotalization. >> >> >> >> Totalization>>total >> >> ^self summatory >> >> >> >> >> >> AverageTotalization>>total >> >> ^(super total) / self denominator >> >> >> >> >> >> AverageTotalization>> denominator >> >> ^values size >> >> >> >> >> WeightedAverageTotalization>> denominator >> >> "Weights is a dictionary" >> >> ^self weights values sum >> >> >> >> >> If I debug aWeightedAverateTotalization total and try to print super total in the debugger ParagraphEditor, I'll get this result: >> >> >> >> (self summatory / self denominator) >> >> >> instead of just: >> self summatory >> This only happens when I print or inspect or other do-its in the debugger window. The method lookup works OK when just _______________________________________________ >> 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

May 19, 2010

Re: [Pharo-project] Bug? ParagraphEditor do-its are not following the expected method lookup

by Carla F. Griggio

Just reproducing it would be helpful :O a friend of mine already tested the code I attatched and saw the same problem. If you recall having a class with a method sending a message to super, and a sublclass inheriting that method, you can try to reproduce it there too debugging that message on an instance of the subclass. It's not easy to explain with words, that's why I made a little package of code to illustrate the situation. The thing is that when printing the evaluation of a selected bunch of code inside a debugger window (paragraphEditor?), if the code you're evaluating is a message to super, and the class of the object you're debugging is inheriting the method you're debugging, the printed result will be wrong. In other words, the method lookup fails. This doesn't happen with normal excution of code (thank God!). I think this is an important bug, seeing those wrong results when debugging can be very confusing. I spent hours feeling stupid last Monday while debugging because I trusted those wrong results and couldn't see where I was doing something wrong :P Cheers! Carla On Wednesday, May 19, 2010, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi Carla. I would like to help you, but I have no idea. I could reproduce it. > > Maybe Lukas, Igor, Eliot etc can help you. I have no idea. > > Cheers > > Mariano > > 2010/5/18 Carla F. Griggio <carla.griggio(a)gmail.com> > Hi everybody! > Well, maybe you are already aware of this... maybe not. I tried to find an issue about this and unless I didn't think of the right keywords, it's not there. > > > > I was debugging a template method and sudenly I found myself spending ours trying to find out why I got different results when printing the result of a message sent to super and when steping into that message and printing the (same) result there. > > > > Imagine this simple situation (I attatch the complete code and some tests so you can reproduce this): > AverageTotalization inherits from Totalization.WeightedAverageTotalization inherits from AverageTotalization. > > > > Totalization>>total > > ^self summatory > > > > > > AverageTotalization>>total > > Â Â Â Â Â ^(super total) / self denominator > > > > > > AverageTotalization>> denominator > > Â Â Â Â Â ^values size > > > > > WeightedAverageTotalization>> denominator > > "Weights is a dictionary" > > ^self weights values sum > > > > > If I debug aWeightedAverateTotalization totalÂ Â and try to print super total in the debugger ParagraphEditor, I'll get this result: > > > > (self summatory / self denominator) > > > instead of just: > self summatory > This only happens when I print or inspect or other do-its in the debugger window. The method lookup works OK when just _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

May 19, 2010

Re: [Pharo-project] Fwd: Re: Decoding bug with XMLParser ?

by Philippe Marschall

On 19.05.2010 19:35, StÃ©phane Ducasse wrote: >>> >>> >> >> Currently the semantics in Pharo are >> 0: Latin 1 >> 255: Unicode >> >> which is fun because the first 255 characters are interned and you >> therefore can't change their leadingChar. So if you're using Unicode, >> you're forced to mix leachingChars. > > so what do you suggest to have unicode as zero? Yes, the decision of Squeak 4.1 to make Unicode leadingChar 0 is an improvement. Cheers Philippe

May 19, 2010

Re: [Pharo-project] UUID on ubuntu 10.04

by David T. Lewis

That is exactly how it works: UUID>>primMakeUUID <primitive: 'primitiveMakeUUID' module: 'UUIDPlugin'> UUIDGenerator default generateBytes: self forVersion: 4. I added this to the Mantis issue: To summarize: The bug exists in some versions of libuuid on some Linux distributions. The workaround is to compile the plugin internal. The latest versions of Unix VM have the plugin compiled internally, although some users may still experience problems if they have a leftover external plugin from a prior installation. If you experience this problem, then get the latest Unix VM and delete any existing copies of the external plugin. Resolved in latest Unix VMs. The UUID plugin must be compiled internally to avoid a bug in some versions of libuuid. Hopefully this is an accurate summary. Dave On Wed, May 19, 2010 at 06:15:32PM +0200, St?phane Ducasse wrote: > I'm not sure that it is resolved. It would be good to make sure that the system does not crash > even without reporting a log. May be having a stupid UUID generator as a fallback would be good. > > Stef > > > Thanks, I marked the issue as resolved and summarized the status here: > > > > http://bugs.squeak.org/view.php?id=7358 > > > > Dave > > > > On Wed, May 19, 2010 at 09:42:28AM +0200, St?phane Ducasse wrote: > >> Apparently the student reinstalled her ubuntu from scratch (no incremental installation) and the vm did not crash > >> anymore. > >> > >> Stef > >> > >> On May 17, 2010, at 9:16 PM, St?phane Ducasse wrote: > >> > >>> I asked the student to try. > >>> > >>> Stef > >>> > >>> On May 17, 2010, at 9:06 PM, laurent laffont wrote: > >>> > >>>> On ArchLinux I have the problem when UUID is built external. Official 4.0.3.2202 Unix VM binaries on http://squeakvm.org/unix/ works well for me (UUID is internal). > >>>> > >>>> Can you try with this one click image I made once (uses 4.0.3.2202 binaries) http://lolgzs.free.fr/pharo/Pharo-1.0-OneClick.zip > >>>> > >>>> Laurent Laffont > >>>> > >>>> http://pharocasts.blogspot.com/ > >>>> http://magaloma.blogspot.com/ > >>>> > >>>> > >>>> On Mon, May 17, 2010 at 8:24 PM, St?phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >>>> I can confirm that this is exactly the same trace than the one reported by laurent (no debug file). > >>>> > >>>> Stef > >>>> On May 17, 2010, at 7:51 PM, David T. Lewis wrote: > >>>> > >>>>> On Mon, May 17, 2010 at 07:38:59PM +0200, St?phane Ducasse wrote: > >>>>>> Hi guys > >>>>>> > >>>>>> I took seaside the latest one click image and when I have to save a MC package > >>>>>> I get a core dump with UUID new:... > >>>>>> I checke the so.UUIDplugin is there and I do not understand. > >>>>>> Can somebody with a Ubuntu give a try to save something using MC and the latest seaside one click. > >>>>> > >>>>> Hi Stef, > >>>>> > >>>>> This issue is being tracked here: http://bugs.squeak.org/view.php?id=7358 > >>>>> > >>>>> It is not clear to me if the issue is resolved in the Ian's latest VM > >>>>> build, so if you or anyone else can confirm the UUID crash happening > >>>>> with this VM, that would be helpful to clarify. > >>>>> > >>>>> Dave > > > > _______________________________________________ > > 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

May 19, 2010

Re: [Pharo-project] NetNameResolver in Pharo 1.1

by Miguel Enrique CobÃ¡ Martinez

El sÃ¡b, 08-05-2010 a las 17:54 +0200, Lukas Renggli escribiÃ³: > In Pharo 1.0 there were some problems with the network stack (namely > the NetNameResolver) and the IP6 code was reverted shortly before > release, see the following issue for details: > > http://code.google.com/p/pharo/issues/detail?id=1884 > > Today I was checking with Stef for the presence of these problems in > Pharo 1.1, but we could not reproduce neither on Mac, Windows nor > Linux. Does anybody have problems with the following expressions in > Pharo 1.1? > > NetNameResolver localHostAddress. > NetNameResolver addressForName: 'www.yahoo.com'. > > Or are we doing the wrong thing to reproduce? > > Lukas Sorry for arriving late to the party :). I tried the doits from the problem on Pharo 1.0 in a Pharo Core 11364 image. I got some error, although not as severe as in Pharo 1.0. I added an issue for this http://code.google.com/p/pharo/issues/detail?id=2444 Now, I'm going to test with Magma to see if some other error shows Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

May 19, 2010