Hi,
Something strange to me: '2' = '2'. -> true (OK) (2 asString) = (2 asString). -> true (OK) (2 asString) == (2 asString). -> false (OK)
'2' == '2'. -> true ????? Laurent
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
this is because of an optimisation
string inside the same methods are reused. if you want to show that string are different than symbol use two methods returning the same strings On Jan 17, 2010, at 6:30 PM, laurent laffont wrote: > Hi, > > Something strange to me: > > '2' = '2'. -> true (OK) > (2 asString) = (2 asString). -> true (OK) > > (2 asString) == (2 asString). -> false (OK) > '2' == '2'. -> true ????? > > Laurent > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
I think the same happens in Java. It is a VM optimization.
Compare "Something" == "Something" true On Sun, Jan 17, 2010 at 6:33 PM, Stéphane Ducasse <[hidden email]> wrote: this is because of an optimisation _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Stéphane Ducasse
On Sun, Jan 17, 2010 at 6:33 PM, Stéphane Ducasse <[hidden email]> wrote: this is because of an optimisation OK if you want to show that string are different than symbol use two methods Hey !! Telepathy power ? You've used the force ? You master the Wakfu ? Laurent
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by laurent laffont
On Jan 17, 2010, at 6:30 PM, laurent laffont wrote: > Hi, > > Something strange to me: > > '2' = '2'. -> true (OK) > (2 asString) = (2 asString). -> true (OK) > > (2 asString) == (2 asString). -> false (OK) > '2' == '2'. -> true ????? > Yes, the same string in the same method points to the same entry in the literalframe. Which explains why this method works: strange 'hello world' isString ifTrue: ['hello world' become: {0}]. 'hello world' at: 1 put: ('hello world' at:1) + 1 . ^'hello world' at: 1. Put this method in Object, than print multiple times: Object new strange :-) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
One of my first bug in st80 was
strange ^('foo' writeStream) nextPutAll: '-bar'; contents. At that time, writing pastEnd did use become: But if you really have time to pick an immutability bit in Newspeak, we don't have to care anymore. Nicolas 2010/1/17 Marcus Denker <[hidden email]>: > > On Jan 17, 2010, at 6:30 PM, laurent laffont wrote: > >> Hi, >> >> Something strange to me: >> >> '2' = '2'. -> true (OK) >> (2 asString) = (2 asString). -> true (OK) >> >> (2 asString) == (2 asString). -> false (OK) >> '2' == '2'. -> true ????? >> > > Yes, the same string in the same method points to the same entry in the literalframe. > > Which explains why this method works: > > strange > 'hello world' isString ifTrue: ['hello world' become: {0}]. > 'hello world' at: 1 put: ('hello world' at:1) + 1 . > ^'hello world' at: 1. > > Put this method in Object, than print multiple times: > > Object new strange > > :-) > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Jan 17, 2010, at 6:57 PM, Nicolas Cellier wrote: > But if you really have time to pick an immutability bit in Newspeak, > we don't have to care anymore. > Hmm... the code below should even work with immutable strings. I *never* touch the string! I do not even manipulate the literal array via #at:put:... I just become the pointer to an Array generated with {}, which would not be immutable... So I wonder if the immutability solved the problem. (immutable literals do solve many other bugs when the object itself gets modified...). >> strange >> 'hello world' isString ifTrue: ['hello world' become: {0}]. >> 'hello world' at: 1 put: ('hello world' at:1) + 1 . >> ^'hello world' at: 1. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
2010/1/17 Marcus Denker <[hidden email]>:
> > On Jan 17, 2010, at 6:57 PM, Nicolas Cellier wrote: >> But if you really have time to pick an immutability bit in Newspeak, >> we don't have to care anymore. >> > Hmm... the code below should even work with immutable strings. I *never* touch > the string! I do not even manipulate the literal array via #at:put:... > > I just become the pointer to an Array generated with {}, which would not > be immutable... > > So I wonder if the immutability solved the problem. (immutable literals > do solve many other bugs when the object itself gets modified...). > I extrapolated a bit... In VW, this leads to an immutability error: ('abc' become: #(1 2 3)) at: 1 Nicolas >>> strange >>> 'hello world' isString ifTrue: ['hello world' become: {0}]. >>> 'hello world' at: 1 put: ('hello world' at:1) + 1 . >>> ^'hello world' at: 1. > > > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Nicolas Cellier
On Sun, 17 Jan 2010, Nicolas Cellier wrote:
> One of my first bug in st80 was > > strange > ^('foo' writeStream) nextPutAll: '-bar'; contents. > > At that time, writing pastEnd did use become: > > But if you really have time to pick an immutability bit in Newspeak, > we don't have to care anymore. If I had a free bit in the object header, I'd use it for extending the identity hash instead of useless things like immutability. IMO it was a mistake to add immutability for literals in other smalltalks only to avoid possible errors generated by the broken stream/collection semantics. Levente > > Nicolas > > 2010/1/17 Marcus Denker <[hidden email]>: >> >> On Jan 17, 2010, at 6:30 PM, laurent laffont wrote: >> >>> Hi, >>> >>> Something strange to me: >>> >>> '2' = '2'. -> true (OK) >>> (2 asString) = (2 asString). -> true (OK) >>> >>> (2 asString) == (2 asString). -> false (OK) >>> '2' == '2'. -> true ????? >>> >> >> Yes, the same string in the same method points to the same entry in the literalframe. >> >> Which explains why this method works: >> >> strange >> 'hello world' isString ifTrue: ['hello world' become: {0}]. >> 'hello world' at: 1 put: ('hello world' at:1) + 1 . >> ^'hello world' at: 1. >> >> Put this method in Object, than print multiple times: >> >> Object new strange >> >> :-) >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Levente Uzonyi wrote:
> On Sun, 17 Jan 2010, Nicolas Cellier wrote: > >> One of my first bug in st80 was >> >> strange >> ^('foo' writeStream) nextPutAll: '-bar'; contents. >> >> At that time, writing pastEnd did use become: >> >> But if you really have time to pick an immutability bit in Newspeak, >> we don't have to care anymore. > > If I had a free bit in the object header, I'd use it for extending the > identity hash instead of useless things like immutability. IMO it was a > mistake to add immutability for literals in other smalltalks only to > avoid possible errors generated by the broken stream/collection semantics. Literal immutability and other object immutability is only one use of the so-called "immutability" bit. In reality, this bit is a "track modifications" bit, and I find the other uses much more valuable. Regards, -Martin _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Sun, 17 Jan 2010, Martin McClure wrote:
> Levente Uzonyi wrote: >> On Sun, 17 Jan 2010, Nicolas Cellier wrote: >> >>> One of my first bug in st80 was >>> >>> strange >>> ^('foo' writeStream) nextPutAll: '-bar'; contents. >>> >>> At that time, writing pastEnd did use become: >>> >>> But if you really have time to pick an immutability bit in Newspeak, >>> we don't have to care anymore. >> >> If I had a free bit in the object header, I'd use it for extending the >> identity hash instead of useless things like immutability. IMO it was a >> mistake to add immutability for literals in other smalltalks only to >> avoid possible errors generated by the broken stream/collection semantics. > > Literal immutability and other object immutability is only one use of > the so-called "immutability" bit. In reality, this bit is a "track http://www.cincomsmalltalk.com/blog/blogView?entry=3232889180 > modifications" bit, and I find the other uses much more valuable. I wonder how that works. Levente > > Regards, > > -Martin > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
2010/1/17 Levente Uzonyi <[hidden email]>:
> On Sun, 17 Jan 2010, Martin McClure wrote: > >> Levente Uzonyi wrote: >>> On Sun, 17 Jan 2010, Nicolas Cellier wrote: >>> >>>> One of my first bug in st80 was >>>> >>>> strange >>>> ^('foo' writeStream) nextPutAll: '-bar'; contents. >>>> >>>> At that time, writing pastEnd did use become: >>>> >>>> But if you really have time to pick an immutability bit in Newspeak, >>>> we don't have to care anymore. >>> >>> If I had a free bit in the object header, I'd use it for extending the >>> identity hash instead of useless things like immutability. IMO it was a >>> mistake to add immutability for literals in other smalltalks only to >>> avoid possible errors generated by the broken stream/collection semantics. >> >> Literal immutability and other object immutability is only one use of >> the so-called "immutability" bit. In reality, this bit is a "track > > http://www.cincomsmalltalk.com/blog/blogView?entry=3232889180 > Sure, object databases are more interesting applications, since you generally make such mistake only once. As a beginner, I put a halt in the method once identified as the source of the problem, and did not understand my mistake at first shot since it started working again (being recompiled). The good thing is that it helped me learning some Smalltalk superpowers faster :). Nicolas >> modifications" bit, and I find the other uses much more valuable. > > I wonder how that works. > > > Levente > >> >> Regards, >> >> -Martin >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Nicolas Cellier wrote:
> > Sure, object databases are more interesting applications, since you > generally make such mistake only once. > As a beginner, I put a halt in the method once identified as the > source of the problem, and did not understand my mistake at first shot > since it started working again (being recompiled). The good thing is > that it helped me learning some Smalltalk superpowers faster :). Yes, I love the way that you can come to understand Smalltalk through debugging it. Modification tracking is good for more than just object databases. Object-relational mapping, distributed object systems, debugging, analysis, probably more -- all benefit from being able to tell when an object is modified, and all care at a different level of abstraction from the application itself, so it's better if you don't have to put the modification-detection code in the application code. Regards, -Martin _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |