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

Re: [Pharo-project] ('a' == 'a') == true ?

by Johan Brichau

On 27 Sep 2010, at 12:34, Igor Stasenko wrote: > Why waiting for sprint? I guess I thought the solution was more intricate than that :-) > Implement > > String>>literalEqueal: anObject > > ^ self == anObject > > and then you have > 'aaa' == 'aaa' -> false Thanks for pointing that out to me, Igor! I created an issue for it (3006) and will see later this week if it is a good idea to change the implementation of #literalEqual: to be less liberal. Johan

Sept. 27, 2010

Re: [Pharo-project] ('a' == 'a') == true ?

by GÃ¶ran Krampe

Hi all! This issue is listed as a "newbie trap" on this page, search for "newbie trap": http://wiki.squeak.org/squeak/3644 ...and there is another cool one just above, which goes like this: "This one actually is borrowed from Leandro Caniglia. He challenged me yesterday to figure out why the method SmallInteger>>gcd: actually works. The challenge can also be expressed like this: Evaluate this code below and figure out why n=5. One could ask oneself if the assignment (m := n) is performed after or before the evaluation of the expression? If it is done before - then n should become 4 right? (2 + 2) And if it is done after then it should become 6... (3 + 3) Gurus: don't spoil it for the newbies ok? Let them chew on it for a while... :-)" | m n | n := 2. m := 3. n := m + (m := n)

Sept. 27, 2010

Re: [Pharo-project] ('a' == 'a') == true ?

by Igor Stasenko

On 27 September 2010 13:34, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 27 September 2010 12:51, Johan Brichau <johan(a)inceptive.be> wrote: >> >> On 27 Sep 2010, at 11:28, Igor Stasenko wrote: >> >>> On 27 September 2010 11:54, Johan Brichau <johan(a)inceptive.be> wrote: >>>> >>>> On 27 Sep 2010, at 10:38, Lukas Renggli wrote: >>>> >>>>>> Am I wrong? >>>>> >>>>> Yes, almost always one should probably use #= instead of #==. >>>> >>>> I will add that to the exercise :-) >>>> The exercise actually makes students aware of the difference between strings and symbols (which should be pointer-equal) >>>> >>> >>> I think you can avoid using 'equal' word when describing a #== comparison. >>> It can be explained as 'test whether comparands are same object or not' >>> while #= is test whether two objects equal or not. >> >> Yes, this is exactly what the exercise is doing. >> I want them to be aware that equal _symbols_ are the same objects, but that equal _strings_ are not, which is why I let them evaluate: >> >> a := #foobar. >> b := #foobar. >> a == b. >> >> a := 'foobar'. >> b := 'foobar'. >> a == b >> >> The problem is that evaluating the second snippet also yields true in Pharo/Squeak, so I cannot illustrate it using these snippets (which works fine in Visualworks, btw). >> >> Yes, this is a compiler optimization and, yes, people should use #= instead of #== normally. But imho the optimization yields a wrong semantics, which is why I posted the email. >> >> I have absolutely no clue if it can be changed (I am not familiar with the compiler implementation *at all*), but I would be happy to look over the shoulder of an experienced compiler hacker during the next sprint to learn ;-) >> > Why waiting for sprint? > > Implement > > String>>literalEqueal: anObject > oops. sorry for typo , a right selector is #literalEqual: > Â ^ self == anObject > > and then you have > 'aaa' == 'aaa' Â -> false > > :) > >> cheers >> Johan >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Sept. 27, 2010

Re: [Pharo-project] ('a' == 'a') == true ?

by Igor Stasenko

On 27 September 2010 12:51, Johan Brichau <johan(a)inceptive.be> wrote: > > On 27 Sep 2010, at 11:28, Igor Stasenko wrote: > >> On 27 September 2010 11:54, Johan Brichau <johan(a)inceptive.be> wrote: >>> >>> On 27 Sep 2010, at 10:38, Lukas Renggli wrote: >>> >>>>> Am I wrong? >>>> >>>> Yes, almost always one should probably use #= instead of #==. >>> >>> I will add that to the exercise :-) >>> The exercise actually makes students aware of the difference between strings and symbols (which should be pointer-equal) >>> >> >> I think you can avoid using 'equal' word when describing a #== comparison. >> It can be explained as 'test whether comparands are same object or not' >> while #= is test whether two objects equal or not. > > Yes, this is exactly what the exercise is doing. > I want them to be aware that equal _symbols_ are the same objects, but that equal _strings_ are not, which is why I let them evaluate: > > a := #foobar. > b := #foobar. > a == b. > > a := 'foobar'. > b := 'foobar'. > a == b > > The problem is that evaluating the second snippet also yields true in Pharo/Squeak, so I cannot illustrate it using these snippets (which works fine in Visualworks, btw). > > Yes, this is a compiler optimization and, yes, people should use #= instead of #== normally. But imho the optimization yields a wrong semantics, which is why I posted the email. > > I have absolutely no clue if it can be changed (I am not familiar with the compiler implementation *at all*), but I would be happy to look over the shoulder of an experienced compiler hacker during the next sprint to learn ;-) > Why waiting for sprint? Implement String>>literalEqueal: anObject ^ self == anObject and then you have 'aaa' == 'aaa' -> false :) > cheers > Johan > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 27, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by Hannes Hirzel

On 9/24/10, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Hannes Hirzel-2 wrote: >> >> Conclusion: It might be worthwile to find out more how Juan has pruned >> Morphic in Cuis and if it is still valuable for use, document that and >> put it to use in Squeak and Pharo. >> > Cool, I've started this as well. Let's keep the list posted if we come up > with anything. > > Sean Yes, for a start, here are some very simple metrics. --Hannes metrics ^HelpTopic title: 'Metrics' contents: ' http://www.squeak.org/ Squeak 4.1 Morph allSubclasses size 323 http://ftp.squeak.org/trunk/ Squeak4.2-alpha-10382 Morph allSubclasses size 330 Squeak4.2-alpha-10548 Morph allSubclasses size 330 http://pharo-project.org/pharo-download/release-1-1 Pharo 1.1 Morph allSubclasses size 282 http://www.jvuletich.org/Cuis/Index.html (Description) http://www.jvuletich.org/Cuis (Download) Cuis 2.7 Morph allSubclasses size 57 Cuis 2.6 Morph allSubclasses size 56 ' -------------------------------------------------------------------------------------------------------------------- The form is a page of a help book which you get when you do for example CustomHelp subclass: #NotesOnMorphicByHannesHirzel instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Morphic-Help'

Sept. 27, 2010

Re: [Pharo-project] ('a' == 'a') == true ?

by Johan Brichau

On 27 Sep 2010, at 11:28, Igor Stasenko wrote: > On 27 September 2010 11:54, Johan Brichau <johan(a)inceptive.be> wrote: >> >> On 27 Sep 2010, at 10:38, Lukas Renggli wrote: >> >>>> Am I wrong? >>> >>> Yes, almost always one should probably use #= instead of #==. >> >> I will add that to the exercise :-) >> The exercise actually makes students aware of the difference between strings and symbols (which should be pointer-equal) >> > > I think you can avoid using 'equal' word when describing a #== comparison. > It can be explained as 'test whether comparands are same object or not' > while #= is test whether two objects equal or not. Yes, this is exactly what the exercise is doing. I want them to be aware that equal _symbols_ are the same objects, but that equal _strings_ are not, which is why I let them evaluate: a := #foobar. b := #foobar. a == b. a := 'foobar'. b := 'foobar'. a == b The problem is that evaluating the second snippet also yields true in Pharo/Squeak, so I cannot illustrate it using these snippets (which works fine in Visualworks, btw). Yes, this is a compiler optimization and, yes, people should use #= instead of #== normally. But imho the optimization yields a wrong semantics, which is why I posted the email. I have absolutely no clue if it can be changed (I am not familiar with the compiler implementation *at all*), but I would be happy to look over the shoulder of an experienced compiler hacker during the next sprint to learn ;-) cheers Johan

Sept. 27, 2010

Re: [Pharo-project] ('a' == 'a') == true ?

by Igor Stasenko

On 27 September 2010 11:54, Johan Brichau <johan(a)inceptive.be> wrote: > > On 27 Sep 2010, at 10:38, Lukas Renggli wrote: > >>> Am I wrong? >> >> Yes, almost always one should probably use #= instead of #==. > > I will add that to the exercise :-) > The exercise actually makes students aware of the difference between strings and symbols (which should be pointer-equal) > I think you can avoid using 'equal' word when describing a #== comparison. It can be explained as 'test whether comparands are same object or not' while #= is test whether two objects equal or not. Also keep in mind that #== optimized by compiler. So , even if you override it in some class, it won't behave differently. And #=, of course, can be implemented in any way you like. One of interesting example: = anObject ^ false saying 'i am not equal to anything' :) > Johan > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 27, 2010

Re: [Pharo-project] which Shout repository should we use?

by Mariano Martinez Peck

On Sun, Sep 26, 2010 at 1:46 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > I thought I pushed my changes all to the official repos, no? > yep....sorry for the noise. Thanks lukas > > Lukas > > 2010/9/26 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Lukas if we will use "your" Shout repository for the Dev images....I > think > > it would be nice (and not difficult to do) to have them in its own > > repository and not in "unsorted". > > > > Thanks > > > > mariano > > > > On Tue, Aug 17, 2010 at 10:03 AM, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr> wrote: > >> > >> > Yes, that's good enough. My question was more general than this > >> > particular situation. I wanted to discuss which repository Pharo > official > >> > images should use. > >> > >> why can't we use a configurationOfXX based on a pharoShout folder > >> With Gofer we can script the pull from repositories. > >> > >> > > >> > Cheers, > >> > Doru > >> > > >> > > >> > > >> > On 16 Aug 2010, at 18:25, Lukas Renggli wrote: > >> > > >> > 2010/8/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> > > >> > > >> > On Sun, Aug 15, 2010 at 6:21 PM, StÃ©phane Ducasse > >> > <stephane.ducasse(a)inria.fr> wrote: > >> > > >> > this is a good question. > >> > for now I would just update the configuration to point for the repo of > >> > lukas :) > >> > > >> > But now for example, I need to remove the style instVar in > >> > PluggableShoutMorph because in Pharo 1.2 it has already such instVar. > >> > But I don't know if I can commit or if Lukas would integrate such > change > >> > in > >> > his repo beacuse that will break Shout to load in Pharo 1.1 (the image > >> > he > >> > uses) > >> > > >> > I will fix it as soon as the PharoCore 1.2 release candidate is out > >> > and I am able to use the image. > >> > > >> > so... lukas what do you think we should do? > >> > > >> > So either fix it in Pharo or create your own 'temporary' version of > >> > Shout in the repository where you keep all the versions for building > >> > the images. > >> > > >> > Lukas > >> > > >> > -- > >> > Lukas Renggli > >> > www.lukas-renggli.ch > >> > > >> > _______________________________________________ > >> > Pharo-project mailing list > >> > Pharo-project(a)lists.gforge.inria.fr > >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > >> > -- > >> > www.tudorgirba.com > >> > > >> > "We cannot reach the flow of things unless we let go." > >> > > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > 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 > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 27, 2010

Re: [Pharo-project] ('a' == 'a') == true ?

by Johan Brichau

On 27 Sep 2010, at 10:38, Lukas Renggli wrote: >> Am I wrong? > > Yes, almost always one should probably use #= instead of #==. I will add that to the exercise :-) The exercise actually makes students aware of the difference between strings and symbols (which should be pointer-equal) Johan

Sept. 27, 2010

Re: [Pharo-project] ('a' == 'a') == true ?

by Tobias Pape

Am 2010-09-27 um 10:32 schrieb Johan Brichau: > I convinced the teacher who will be taking over my Smalltalk courses at UCLouvain (starting this week) to use Pharo :-) > One of the introductory exercises in these courses shows the difference between '==' and '='. However, in Pharo (&Squeak) the following goes wrong imho: > > 'a' == 'a' -> true > $a asString == $a asString -> false > > It seems that when you evaluate the expression, the (semantically identical) strings are represented as the same literal in the compiled block. > For example, try to evaluate the following code by evaluating each statement in a separate doit. Then do it again as a single block... > > |a b| > a := 'a'. > b := 'a'. > a == b inspect > > > Do I make it an issue? Is there already an issue? (did not find one) > Am I wrong? I think this is a compiler optimization, as strings in general are immutable if created via literal notation (afaik). Remember that most operations on strings create copies of the original string. It gets even more interesting: Look at doit1.png I've referenced to 'abs' four times in the doit, nevertheless, there is only one literal stored. When i execute the second line, i operate with the #at:put: directly on that literal (doit2.png). hence, the method does not return 'abs' but 'ads' (as you can see by the 'stack top' in doit3.png) HTH, So Long, -Tobias

Sept. 27, 2010