- Pharo-dev - lists.pharo.org

Re: [Pharo-project] strange == behavior

by StÃ©phane Ducasse

On Dec 9, 2012, at 7:59 PM, Nicolas Cellier wrote: > Also note that some implementors of = start with verifying == first, some not. > I would solve this differently by checking self == anObject in super > (LookupKey). BTW in that case should not be LookupKey be called IdentityLookupKey > > Nicolas > > 2012/12/9 Ciprian Teodorov <ciprian.teodorov(a)gmail.com>: >> As for the = method in Association (besides perverted side effects) I think >> that my code is at least logical. >> >> If the keys are equal and the values hold absolutely the same object then it >> means the two associations are equal. If the values are not (object >> identity) equal then, and only then we should compare them with = >> >> BTW this agrees with the point raised by Markus about comparing only keys >> ((1 -> 2) key = (1 -> 4) key). >> >> >> On Sun, Dec 9, 2012 at 7:41 PM, Ciprian Teodorov >> <ciprian.teodorov(a)gmail.com> wrote: >>> >>> Hi guys, >>> >>> I agree that = can cause these kind of issues... But I found strange that >>> == does too. IMHO i was hoping that object identity won't be tricked into >>> this kind of loops, especially since it works on first evaluation... >>> >>> Maybe the solution I have found is shallow (modifying the association =). >>> But I think that the issue still holds. Maybe the problem is somewhere in >>> the way the workspace implicit variables are handled or stored, if they will >>> be stored in an identity dictionary maybe there won't be a problem. I don't >>> know. >>> >>> On Sun, Dec 9, 2012 at 7:24 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> >>>> some years ago, its been a long discussion on squeak mailing list about >>>> that.. >>>> imo association should compare keys. not values. >>>> >>>> But self-referencing data structures is and will be a problem. And >>>> there is no easy solution: >>>> >>>> a := Array new: 1. >>>> a at:1 put: a. >>>> >>>> a = a >>>> >>>> On 9 December 2012 17:20, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> I am not pro, see my comments in the issue tracker. >>>>> >>>>> For example, >>>>> >>>>> | a | >>>>> a := Association key: #foo. >>>>> (a value: (Array with: a)) = (a value: (Array with: a)). >>>>> >>>>> would still loop. >>>>> >>>>> Loops like that cannot be prevented locally. >>>>> >>>>> See my other mail about prevent stack overflow. >>>>> >>>>> On 09 Dec 2012, at 16:32, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>>>> wrote: >>>>> >>>>>> Hi guys >>>>>> >>>>>> what is the impact on method =? >>>>>> Any ideas? >>>>>> >>>>>> Stef >>>>>> On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote: >>>>>> >>>>>>> It seems that this issue can be fixed by modifying the = method in >>>>>>> Association. >>>>>>> >>>>>>> Association>>= anAssociation >>>>>>> ^ super = anAssociation >>>>>>> and: [ >>>>>>> value == anAssociation value >>>>>>> ifTrue: [ true ] >>>>>>> ifFalse: [ value = anAssociation value ] >>>>>>> ] >>>>>>> >>>>>>> Cheers... >>>>>>> >>>>>>> On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean(a)yahoo.com> >>>>>>> wrote: >>>>>>> Same behavior in Squeak 4.2 btw >>>>>>> >>>>>>> ----------------- >>>>>>> Benoit St-Jean >>>>>>> Yahoo! Messenger: bstjean >>>>>>> A standpoint is an intellectual horizon of radius zero. >>>>>>> (Albert Einstein) >>>>>>> From: Ciprian Teodorov <ciprian.teodorov(a)gmail.com> >>>>>>> To: Pharo-project(a)lists.gforge.inria.fr >>>>>>> Sent: Saturday, December 8, 2012 11:11:44 AM >>>>>>> Subject: Re: [Pharo-project] strange == behavior >>>>>>> >>>>>>> by the way, we have the same thing in 1.0, 1.1, 1.3. >>>>>>> >>>>>>> On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov >>>>>>> <ciprian.teodorov(a)gmail.com> wrote: >>>>>>> Hi guys, >>>>>>> >>>>>>> Playing with some recursive data-structure I have found some strange >>>>>>> piece of behavior in Pharo. >>>>>>> >>>>>>> If in an workspace we try to evaluate: >>>>>>> >>>>>>> a := Association new. >>>>>>> a key: 3. >>>>>>> a value: a. >>>>>>> a == a value. >>>>>>> >>>>>>> the first time we get "true", the second we get an infinite loop... >>>>>>> >>>>>>> A simple workaround is to declare "a": >>>>>>> >>>>>>> |a| >>>>>>> a := Association new. >>>>>>> a key: 3. >>>>>>> a value: a. >>>>>>> a == a value. >>>>>>> >>>>>>> My question now is: Is this a bug or a feature ? >>>>>>> By the way the same thing happens in 1.4 and 2.0 equally. >>>>>>> >>>>>>> By the way, in Pharo 2.0 doing cmd + . erases the lines selected in >>>>>>> the workspace replacing them by "." >>>>>>> >>>>>>> Cheers, >>>>>>> -- >>>>>>> Dr. Ciprian TEODOROV >>>>>>> IngÃ©nieur DÃ©veloppement CAO >>>>>>> >>>>>>> tÃ©l : 06 08 54 73 48 >>>>>>> mail : ciprian.teodorov(a)gmail.com >>>>>>> www.teodorov.ro >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Dr. Ciprian TEODOROV >>>>>>> IngÃ©nieur DÃ©veloppement CAO >>>>>>> >>>>>>> tÃ©l : 06 08 54 73 48 >>>>>>> mail : ciprian.teodorov(a)gmail.com >>>>>>> www.teodorov.ro >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Dr. Ciprian TEODOROV >>>>>>> IngÃ©nieur DÃ©veloppement CAO >>>>>>> >>>>>>> tÃ©l : 06 08 54 73 48 >>>>>>> mail : ciprian.teodorov(a)gmail.com >>>>>>> www.teodorov.ro >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >>> >>> -- >>> Dr. Ciprian TEODOROV >>> IngÃ©nieur DÃ©veloppement CAO >>> >>> tÃ©l : 06 08 54 73 48 >>> mail : ciprian.teodorov(a)gmail.com >>> www.teodorov.ro >> >> >> >> >> -- >> Dr. Ciprian TEODOROV >> IngÃ©nieur DÃ©veloppement CAO >> >> tÃ©l : 06 08 54 73 48 >> mail : ciprian.teodorov(a)gmail.com >> www.teodorov.ro >

Dec. 9, 2012

Re: [Pharo-project] strange == behavior

by Nicolas Cellier

Also note that some implementors of = start with verifying == first, some not. I would solve this differently by checking self == anObject in super (LookupKey). Nicolas 2012/12/9 Ciprian Teodorov <ciprian.teodorov(a)gmail.com>: > As for the = method in Association (besides perverted side effects) I think > that my code is at least logical. > > If the keys are equal and the values hold absolutely the same object then it > means the two associations are equal. If the values are not (object > identity) equal then, and only then we should compare them with = > > BTW this agrees with the point raised by Markus about comparing only keys > ((1 -> 2) key = (1 -> 4) key). > > > On Sun, Dec 9, 2012 at 7:41 PM, Ciprian Teodorov > <ciprian.teodorov(a)gmail.com> wrote: >> >> Hi guys, >> >> I agree that = can cause these kind of issues... But I found strange that >> == does too. IMHO i was hoping that object identity won't be tricked into >> this kind of loops, especially since it works on first evaluation... >> >> Maybe the solution I have found is shallow (modifying the association =). >> But I think that the issue still holds. Maybe the problem is somewhere in >> the way the workspace implicit variables are handled or stored, if they will >> be stored in an identity dictionary maybe there won't be a problem. I don't >> know. >> >> On Sun, Dec 9, 2012 at 7:24 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> some years ago, its been a long discussion on squeak mailing list about >>> that.. >>> imo association should compare keys. not values. >>> >>> But self-referencing data structures is and will be a problem. And >>> there is no easy solution: >>> >>> a := Array new: 1. >>> a at:1 put: a. >>> >>> a = a >>> >>> On 9 December 2012 17:20, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> > I am not pro, see my comments in the issue tracker. >>> > >>> > For example, >>> > >>> > | a | >>> > a := Association key: #foo. >>> > (a value: (Array with: a)) = (a value: (Array with: a)). >>> > >>> > would still loop. >>> > >>> > Loops like that cannot be prevented locally. >>> > >>> > See my other mail about prevent stack overflow. >>> > >>> > On 09 Dec 2012, at 16:32, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> > wrote: >>> > >>> >> Hi guys >>> >> >>> >> what is the impact on method =? >>> >> Any ideas? >>> >> >>> >> Stef >>> >> On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote: >>> >> >>> >>> It seems that this issue can be fixed by modifying the = method in >>> >>> Association. >>> >>> >>> >>> Association>>= anAssociation >>> >>> ^ super = anAssociation >>> >>> and: [ >>> >>> value == anAssociation value >>> >>> ifTrue: [ true ] >>> >>> ifFalse: [ value = anAssociation value ] >>> >>> ] >>> >>> >>> >>> Cheers... >>> >>> >>> >>> On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean(a)yahoo.com> >>> >>> wrote: >>> >>> Same behavior in Squeak 4.2 btw >>> >>> >>> >>> ----------------- >>> >>> Benoit St-Jean >>> >>> Yahoo! Messenger: bstjean >>> >>> A standpoint is an intellectual horizon of radius zero. >>> >>> (Albert Einstein) >>> >>> From: Ciprian Teodorov <ciprian.teodorov(a)gmail.com> >>> >>> To: Pharo-project(a)lists.gforge.inria.fr >>> >>> Sent: Saturday, December 8, 2012 11:11:44 AM >>> >>> Subject: Re: [Pharo-project] strange == behavior >>> >>> >>> >>> by the way, we have the same thing in 1.0, 1.1, 1.3. >>> >>> >>> >>> On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov >>> >>> <ciprian.teodorov(a)gmail.com> wrote: >>> >>> Hi guys, >>> >>> >>> >>> Playing with some recursive data-structure I have found some strange >>> >>> piece of behavior in Pharo. >>> >>> >>> >>> If in an workspace we try to evaluate: >>> >>> >>> >>> a := Association new. >>> >>> a key: 3. >>> >>> a value: a. >>> >>> a == a value. >>> >>> >>> >>> the first time we get "true", the second we get an infinite loop... >>> >>> >>> >>> A simple workaround is to declare "a": >>> >>> >>> >>> |a| >>> >>> a := Association new. >>> >>> a key: 3. >>> >>> a value: a. >>> >>> a == a value. >>> >>> >>> >>> My question now is: Is this a bug or a feature ? >>> >>> By the way the same thing happens in 1.4 and 2.0 equally. >>> >>> >>> >>> By the way, in Pharo 2.0 doing cmd + . erases the lines selected in >>> >>> the workspace replacing them by "." >>> >>> >>> >>> Cheers, >>> >>> -- >>> >>> Dr. Ciprian TEODOROV >>> >>> IngÃ©nieur DÃ©veloppement CAO >>> >>> >>> >>> tÃ©l : 06 08 54 73 48 >>> >>> mail : ciprian.teodorov(a)gmail.com >>> >>> www.teodorov.ro >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Dr. Ciprian TEODOROV >>> >>> IngÃ©nieur DÃ©veloppement CAO >>> >>> >>> >>> tÃ©l : 06 08 54 73 48 >>> >>> mail : ciprian.teodorov(a)gmail.com >>> >>> www.teodorov.ro >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Dr. Ciprian TEODOROV >>> >>> IngÃ©nieur DÃ©veloppement CAO >>> >>> >>> >>> tÃ©l : 06 08 54 73 48 >>> >>> mail : ciprian.teodorov(a)gmail.com >>> >>> www.teodorov.ro >>> >> >>> >> >>> > >>> > >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> >> -- >> Dr. Ciprian TEODOROV >> IngÃ©nieur DÃ©veloppement CAO >> >> tÃ©l : 06 08 54 73 48 >> mail : ciprian.teodorov(a)gmail.com >> www.teodorov.ro > > > > > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro

Dec. 9, 2012

Re: [Pharo-project] strange == behavior

by Ciprian Teodorov

As for the = method in Association (besides perverted side effects) I think that my code is at least logical. If the keys are equal and the values hold absolutely the same object then it means the two associations are equal. If the values are not (object identity) equal then, and only then we should compare them with = BTW this agrees with the point raised by Markus about comparing only keys ((1 -> 2) key = (1 -> 4) key). On Sun, Dec 9, 2012 at 7:41 PM, Ciprian Teodorov <ciprian.teodorov(a)gmail.com > wrote: > Hi guys, > > I agree that = can cause these kind of issues... But I found strange that > == does too. IMHO i was hoping that object identity won't be tricked into > this kind of loops, especially since it works on first evaluation... > > Maybe the solution I have found is shallow (modifying the association =). > But I think that the issue still holds. Maybe the problem is somewhere in > the way the workspace implicit variables are handled or stored, if they > will be stored in an identity dictionary maybe there won't be a problem. I > don't know. > > On Sun, Dec 9, 2012 at 7:24 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> some years ago, its been a long discussion on squeak mailing list about >> that.. >> imo association should compare keys. not values. >> >> But self-referencing data structures is and will be a problem. And >> there is no easy solution: >> >> a := Array new: 1. >> a at:1 put: a. >> >> a = a >> >> On 9 December 2012 17:20, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> > I am not pro, see my comments in the issue tracker. >> > >> > For example, >> > >> > | a | >> > a := Association key: #foo. >> > (a value: (Array with: a)) = (a value: (Array with: a)). >> > >> > would still loop. >> > >> > Loops like that cannot be prevented locally. >> > >> > See my other mail about prevent stack overflow. >> > >> > On 09 Dec 2012, at 16:32, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >> > >> >> Hi guys >> >> >> >> what is the impact on method =? >> >> Any ideas? >> >> >> >> Stef >> >> On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote: >> >> >> >>> It seems that this issue can be fixed by modifying the = method in >> Association. >> >>> >> >>> Association>>= anAssociation >> >>> ^ super = anAssociation >> >>> and: [ >> >>> value == anAssociation value >> >>> ifTrue: [ true ] >> >>> ifFalse: [ value = anAssociation value ] >> ] >> >>> >> >>> Cheers... >> >>> >> >>> On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean(a)yahoo.com> >> wrote: >> >>> Same behavior in Squeak 4.2 btw >> >>> >> >>> ----------------- >> >>> Benoit St-Jean >> >>> Yahoo! Messenger: bstjean >> >>> A standpoint is an intellectual horizon of radius zero. >> >>> (Albert Einstein) >> >>> From: Ciprian Teodorov <ciprian.teodorov(a)gmail.com> >> >>> To: Pharo-project(a)lists.gforge.inria.fr >> >>> Sent: Saturday, December 8, 2012 11:11:44 AM >> >>> Subject: Re: [Pharo-project] strange == behavior >> >>> >> >>> by the way, we have the same thing in 1.0, 1.1, 1.3. >> >>> >> >>> On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov < >> ciprian.teodorov(a)gmail.com> wrote: >> >>> Hi guys, >> >>> >> >>> Playing with some recursive data-structure I have found some strange >> piece of behavior in Pharo. >> >>> >> >>> If in an workspace we try to evaluate: >> >>> >> >>> a := Association new. >> >>> a key: 3. >> >>> a value: a. >> >>> a == a value. >> >>> >> >>> the first time we get "true", the second we get an infinite loop... >> >>> >> >>> A simple workaround is to declare "a": >> >>> >> >>> |a| >> >>> a := Association new. >> >>> a key: 3. >> >>> a value: a. >> >>> a == a value. >> >>> >> >>> My question now is: Is this a bug or a feature ? >> >>> By the way the same thing happens in 1.4 and 2.0 equally. >> >>> >> >>> By the way, in Pharo 2.0 doing cmd + . erases the lines selected in >> the workspace replacing them by "." >> >>> >> >>> Cheers, >> >>> -- >> >>> Dr. Ciprian TEODOROV >> >>> IngÃ©nieur DÃ©veloppement CAO >> >>> >> >>> tÃ©l : 06 08 54 73 48 >> >>> mail : ciprian.teodorov(a)gmail.com >> >>> www.teodorov.ro >> >>> >> >>> >> >>> >> >>> -- >> >>> Dr. Ciprian TEODOROV >> >>> IngÃ©nieur DÃ©veloppement CAO >> >>> >> >>> tÃ©l : 06 08 54 73 48 >> >>> mail : ciprian.teodorov(a)gmail.com >> >>> www.teodorov.ro >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Dr. Ciprian TEODOROV >> >>> IngÃ©nieur DÃ©veloppement CAO >> >>> >> >>> tÃ©l : 06 08 54 73 48 >> >>> mail : ciprian.teodorov(a)gmail.com >> >>> www.teodorov.ro >> >> >> >> >> > >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> > > > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Dec. 9, 2012

Re: [Pharo-project] strange == behavior

by Ciprian Teodorov

Hi guys, I agree that = can cause these kind of issues... But I found strange that == does too. IMHO i was hoping that object identity won't be tricked into this kind of loops, especially since it works on first evaluation... Maybe the solution I have found is shallow (modifying the association =). But I think that the issue still holds. Maybe the problem is somewhere in the way the workspace implicit variables are handled or stored, if they will be stored in an identity dictionary maybe there won't be a problem. I don't know. On Sun, Dec 9, 2012 at 7:24 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > some years ago, its been a long discussion on squeak mailing list about > that.. > imo association should compare keys. not values. > > But self-referencing data structures is and will be a problem. And > there is no easy solution: > > a := Array new: 1. > a at:1 put: a. > > a = a > > On 9 December 2012 17:20, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I am not pro, see my comments in the issue tracker. > > > > For example, > > > > | a | > > a := Association key: #foo. > > (a value: (Array with: a)) = (a value: (Array with: a)). > > > > would still loop. > > > > Loops like that cannot be prevented locally. > > > > See my other mail about prevent stack overflow. > > > > On 09 Dec 2012, at 16:32, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > >> Hi guys > >> > >> what is the impact on method =? > >> Any ideas? > >> > >> Stef > >> On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote: > >> > >>> It seems that this issue can be fixed by modifying the = method in > Association. > >>> > >>> Association>>= anAssociation > >>> ^ super = anAssociation > >>> and: [ > >>> value == anAssociation value > >>> ifTrue: [ true ] > >>> ifFalse: [ value = anAssociation value ] ] > >>> > >>> Cheers... > >>> > >>> On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean(a)yahoo.com> > wrote: > >>> Same behavior in Squeak 4.2 btw > >>> > >>> ----------------- > >>> Benoit St-Jean > >>> Yahoo! Messenger: bstjean > >>> A standpoint is an intellectual horizon of radius zero. > >>> (Albert Einstein) > >>> From: Ciprian Teodorov <ciprian.teodorov(a)gmail.com> > >>> To: Pharo-project(a)lists.gforge.inria.fr > >>> Sent: Saturday, December 8, 2012 11:11:44 AM > >>> Subject: Re: [Pharo-project] strange == behavior > >>> > >>> by the way, we have the same thing in 1.0, 1.1, 1.3. > >>> > >>> On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov < > ciprian.teodorov(a)gmail.com> wrote: > >>> Hi guys, > >>> > >>> Playing with some recursive data-structure I have found some strange > piece of behavior in Pharo. > >>> > >>> If in an workspace we try to evaluate: > >>> > >>> a := Association new. > >>> a key: 3. > >>> a value: a. > >>> a == a value. > >>> > >>> the first time we get "true", the second we get an infinite loop... > >>> > >>> A simple workaround is to declare "a": > >>> > >>> |a| > >>> a := Association new. > >>> a key: 3. > >>> a value: a. > >>> a == a value. > >>> > >>> My question now is: Is this a bug or a feature ? > >>> By the way the same thing happens in 1.4 and 2.0 equally. > >>> > >>> By the way, in Pharo 2.0 doing cmd + . erases the lines selected in > the workspace replacing them by "." > >>> > >>> Cheers, > >>> -- > >>> Dr. Ciprian TEODOROV > >>> IngÃ©nieur DÃ©veloppement CAO > >>> > >>> tÃ©l : 06 08 54 73 48 > >>> mail : ciprian.teodorov(a)gmail.com > >>> www.teodorov.ro > >>> > >>> > >>> > >>> -- > >>> Dr. Ciprian TEODOROV > >>> IngÃ©nieur DÃ©veloppement CAO > >>> > >>> tÃ©l : 06 08 54 73 48 > >>> mail : ciprian.teodorov(a)gmail.com > >>> www.teodorov.ro > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> Dr. Ciprian TEODOROV > >>> IngÃ©nieur DÃ©veloppement CAO > >>> > >>> tÃ©l : 06 08 54 73 48 > >>> mail : ciprian.teodorov(a)gmail.com > >>> www.teodorov.ro > >> > >> > > > > > > > > -- > Best regards, > Igor Stasenko. > > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Dec. 9, 2012

Re: [Pharo-project] strange == behavior

by Marcus Denker

On Dec 9, 2012, at 7:24 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > some years ago, its been a long discussion on squeak mailing list about that.. > imo association should compare keys. not values. > But it's not very clear why? Why should (1 -> 2) = (1 -> 4) be true? They are not the same! If you want to compare keys, you can easily write (1 -> 2) key = (1 -> 4) key and the people reading the code will directly understand what your intention is. Marcus > But self-referencing data structures is and will be a problem. And > there is no easy solution: > > a := Array new: 1. > a at:1 put: a. > > a = a > > On 9 December 2012 17:20, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> I am not pro, see my comments in the issue tracker. >> >> For example, >> >> | a | >> a := Association key: #foo. >> (a value: (Array with: a)) = (a value: (Array with: a)). >> >> would still loop. >> >> Loops like that cannot be prevented locally. >> >> See my other mail about prevent stack overflow. >> >> On 09 Dec 2012, at 16:32, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> Hi guys >>> >>> what is the impact on method =? >>> Any ideas? >>> >>> Stef >>> On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote: >>> >>>> It seems that this issue can be fixed by modifying the = method in Association. >>>> >>>> Association>>= anAssociation >>>> ^ super = anAssociation >>>> and: [ >>>> value == anAssociation value >>>> ifTrue: [ true ] >>>> ifFalse: [ value = anAssociation value ] ] >>>> >>>> Cheers... >>>> >>>> On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean(a)yahoo.com> wrote: >>>> Same behavior in Squeak 4.2 btw >>>> >>>> ----------------- >>>> Benoit St-Jean >>>> Yahoo! Messenger: bstjean >>>> A standpoint is an intellectual horizon of radius zero. >>>> (Albert Einstein) >>>> From: Ciprian Teodorov <ciprian.teodorov(a)gmail.com> >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Sent: Saturday, December 8, 2012 11:11:44 AM >>>> Subject: Re: [Pharo-project] strange == behavior >>>> >>>> by the way, we have the same thing in 1.0, 1.1, 1.3. >>>> >>>> On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: >>>> Hi guys, >>>> >>>> Playing with some recursive data-structure I have found some strange piece of behavior in Pharo. >>>> >>>> If in an workspace we try to evaluate: >>>> >>>> a := Association new. >>>> a key: 3. >>>> a value: a. >>>> a == a value. >>>> >>>> the first time we get "true", the second we get an infinite loop... >>>> >>>> A simple workaround is to declare "a": >>>> >>>> |a| >>>> a := Association new. >>>> a key: 3. >>>> a value: a. >>>> a == a value. >>>> >>>> My question now is: Is this a bug or a feature ? >>>> By the way the same thing happens in 1.4 and 2.0 equally. >>>> >>>> By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "." >>>> >>>> Cheers, >>>> -- >>>> Dr. Ciprian TEODOROV >>>> IngÃ©nieur DÃ©veloppement CAO >>>> >>>> tÃ©l : 06 08 54 73 48 >>>> mail : ciprian.teodorov(a)gmail.com >>>> www.teodorov.ro >>>> >>>> >>>> >>>> -- >>>> Dr. Ciprian TEODOROV >>>> IngÃ©nieur DÃ©veloppement CAO >>>> >>>> tÃ©l : 06 08 54 73 48 >>>> mail : ciprian.teodorov(a)gmail.com >>>> www.teodorov.ro >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Dr. Ciprian TEODOROV >>>> IngÃ©nieur DÃ©veloppement CAO >>>> >>>> tÃ©l : 06 08 54 73 48 >>>> mail : ciprian.teodorov(a)gmail.com >>>> www.teodorov.ro >>> >>> >> >> > > > > -- > Best regards, > Igor Stasenko. >

Dec. 9, 2012

Re: [Pharo-project] strange == behavior

by Igor Stasenko

some years ago, its been a long discussion on squeak mailing list about that.. imo association should compare keys. not values. But self-referencing data structures is and will be a problem. And there is no easy solution: a := Array new: 1. a at:1 put: a. a = a On 9 December 2012 17:20, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I am not pro, see my comments in the issue tracker. > > For example, > > | a | > a := Association key: #foo. > (a value: (Array with: a)) = (a value: (Array with: a)). > > would still loop. > > Loops like that cannot be prevented locally. > > See my other mail about prevent stack overflow. > > On 09 Dec 2012, at 16:32, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Hi guys >> >> what is the impact on method =? >> Any ideas? >> >> Stef >> On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote: >> >>> It seems that this issue can be fixed by modifying the = method in Association. >>> >>> Association>>= anAssociation >>> ^ super = anAssociation >>> and: [ >>> value == anAssociation value >>> ifTrue: [ true ] >>> ifFalse: [ value = anAssociation value ] ] >>> >>> Cheers... >>> >>> On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean(a)yahoo.com> wrote: >>> Same behavior in Squeak 4.2 btw >>> >>> ----------------- >>> Benoit St-Jean >>> Yahoo! Messenger: bstjean >>> A standpoint is an intellectual horizon of radius zero. >>> (Albert Einstein) >>> From: Ciprian Teodorov <ciprian.teodorov(a)gmail.com> >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Sent: Saturday, December 8, 2012 11:11:44 AM >>> Subject: Re: [Pharo-project] strange == behavior >>> >>> by the way, we have the same thing in 1.0, 1.1, 1.3. >>> >>> On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: >>> Hi guys, >>> >>> Playing with some recursive data-structure I have found some strange piece of behavior in Pharo. >>> >>> If in an workspace we try to evaluate: >>> >>> a := Association new. >>> a key: 3. >>> a value: a. >>> a == a value. >>> >>> the first time we get "true", the second we get an infinite loop... >>> >>> A simple workaround is to declare "a": >>> >>> |a| >>> a := Association new. >>> a key: 3. >>> a value: a. >>> a == a value. >>> >>> My question now is: Is this a bug or a feature ? >>> By the way the same thing happens in 1.4 and 2.0 equally. >>> >>> By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "." >>> >>> Cheers, >>> -- >>> Dr. Ciprian TEODOROV >>> IngÃ©nieur DÃ©veloppement CAO >>> >>> tÃ©l : 06 08 54 73 48 >>> mail : ciprian.teodorov(a)gmail.com >>> www.teodorov.ro >>> >>> >>> >>> -- >>> Dr. Ciprian TEODOROV >>> IngÃ©nieur DÃ©veloppement CAO >>> >>> tÃ©l : 06 08 54 73 48 >>> mail : ciprian.teodorov(a)gmail.com >>> www.teodorov.ro >>> >>> >>> >>> >>> >>> -- >>> Dr. Ciprian TEODOROV >>> IngÃ©nieur DÃ©veloppement CAO >>> >>> tÃ©l : 06 08 54 73 48 >>> mail : ciprian.teodorov(a)gmail.com >>> www.teodorov.ro >> >> > > -- Best regards, Igor Stasenko.

Dec. 9, 2012

Re: [Pharo-project] strange == behavior

by Sven Van Caekenberghe

I am not pro, see my comments in the issue tracker. For example, | a | a := Association key: #foo. (a value: (Array with: a)) = (a value: (Array with: a)). would still loop. Loops like that cannot be prevented locally. See my other mail about prevent stack overflow. On 09 Dec 2012, at 16:32, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > what is the impact on method =? > Any ideas? > > Stef > On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote: > >> It seems that this issue can be fixed by modifying the = method in Association. >> >> Association>>= anAssociation >> ^ super = anAssociation >> and: [ >> value == anAssociation value >> ifTrue: [ true ] >> ifFalse: [ value = anAssociation value ] ] >> >> Cheers... >> >> On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean(a)yahoo.com> wrote: >> Same behavior in Squeak 4.2 btw >> >> ----------------- >> Benoit St-Jean >> Yahoo! Messenger: bstjean >> A standpoint is an intellectual horizon of radius zero. >> (Albert Einstein) >> From: Ciprian Teodorov <ciprian.teodorov(a)gmail.com> >> To: Pharo-project(a)lists.gforge.inria.fr >> Sent: Saturday, December 8, 2012 11:11:44 AM >> Subject: Re: [Pharo-project] strange == behavior >> >> by the way, we have the same thing in 1.0, 1.1, 1.3. >> >> On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: >> Hi guys, >> >> Playing with some recursive data-structure I have found some strange piece of behavior in Pharo. >> >> If in an workspace we try to evaluate: >> >> a := Association new. >> a key: 3. >> a value: a. >> a == a value. >> >> the first time we get "true", the second we get an infinite loop... >> >> A simple workaround is to declare "a": >> >> |a| >> a := Association new. >> a key: 3. >> a value: a. >> a == a value. >> >> My question now is: Is this a bug or a feature ? >> By the way the same thing happens in 1.4 and 2.0 equally. >> >> By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "." >> >> Cheers, >> -- >> Dr. Ciprian TEODOROV >> IngÃ©nieur DÃ©veloppement CAO >> >> tÃ©l : 06 08 54 73 48 >> mail : ciprian.teodorov(a)gmail.com >> www.teodorov.ro >> >> >> >> -- >> Dr. Ciprian TEODOROV >> IngÃ©nieur DÃ©veloppement CAO >> >> tÃ©l : 06 08 54 73 48 >> mail : ciprian.teodorov(a)gmail.com >> www.teodorov.ro >> >> >> >> >> >> -- >> Dr. Ciprian TEODOROV >> IngÃ©nieur DÃ©veloppement CAO >> >> tÃ©l : 06 08 54 73 48 >> mail : ciprian.teodorov(a)gmail.com >> www.teodorov.ro > >

Dec. 9, 2012

Re: [Pharo-project] strange == behavior

by Nicolas Cellier

The sole impact I can't think of is (#x -> Float nan) = (#x -> Float nan) Nicolas 2012/12/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi guys > > what is the impact on method =? > Any ideas? > > Stef > On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote: > >> It seems that this issue can be fixed by modifying the = method in Association. >> >> Association>>= anAssociation >> ^ super = anAssociation >> and: [ >> value == anAssociation value >> ifTrue: [ true ] >> ifFalse: [ value = anAssociation value ] ] >> >> Cheers... >> >> On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean(a)yahoo.com> wrote: >> Same behavior in Squeak 4.2 btw >> >> ----------------- >> Benoit St-Jean >> Yahoo! Messenger: bstjean >> A standpoint is an intellectual horizon of radius zero. >> (Albert Einstein) >> From: Ciprian Teodorov <ciprian.teodorov(a)gmail.com> >> To: Pharo-project(a)lists.gforge.inria.fr >> Sent: Saturday, December 8, 2012 11:11:44 AM >> Subject: Re: [Pharo-project] strange == behavior >> >> by the way, we have the same thing in 1.0, 1.1, 1.3. >> >> On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: >> Hi guys, >> >> Playing with some recursive data-structure I have found some strange piece of behavior in Pharo. >> >> If in an workspace we try to evaluate: >> >> a := Association new. >> a key: 3. >> a value: a. >> a == a value. >> >> the first time we get "true", the second we get an infinite loop... >> >> A simple workaround is to declare "a": >> >> |a| >> a := Association new. >> a key: 3. >> a value: a. >> a == a value. >> >> My question now is: Is this a bug or a feature ? >> By the way the same thing happens in 1.4 and 2.0 equally. >> >> By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "." >> >> Cheers, >> -- >> Dr. Ciprian TEODOROV >> IngÃ©nieur DÃ©veloppement CAO >> >> tÃ©l : 06 08 54 73 48 >> mail : ciprian.teodorov(a)gmail.com >> www.teodorov.ro >> >> >> >> -- >> Dr. Ciprian TEODOROV >> IngÃ©nieur DÃ©veloppement CAO >> >> tÃ©l : 06 08 54 73 48 >> mail : ciprian.teodorov(a)gmail.com >> www.teodorov.ro >> >> >> >> >> >> -- >> Dr. Ciprian TEODOROV >> IngÃ©nieur DÃ©veloppement CAO >> >> tÃ©l : 06 08 54 73 48 >> mail : ciprian.teodorov(a)gmail.com >> www.teodorov.ro > >

Dec. 9, 2012

Re: [Pharo-project] strange == behavior

by StÃ©phane Ducasse

Hi guys what is the impact on method =? Any ideas? Stef On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov wrote: > It seems that this issue can be fixed by modifying the = method in Association. > > Association>>= anAssociation > ^ super = anAssociation > and: [ > value == anAssociation value > ifTrue: [ true ] > ifFalse: [ value = anAssociation value ] ] > > Cheers... > > On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean(a)yahoo.com> wrote: > Same behavior in Squeak 4.2 btw > > ----------------- > Benoit St-Jean > Yahoo! Messenger: bstjean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > From: Ciprian Teodorov <ciprian.teodorov(a)gmail.com> > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Saturday, December 8, 2012 11:11:44 AM > Subject: Re: [Pharo-project] strange == behavior > > by the way, we have the same thing in 1.0, 1.1, 1.3. > > On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > Hi guys, > > Playing with some recursive data-structure I have found some strange piece of behavior in Pharo. > > If in an workspace we try to evaluate: > > a := Association new. > a key: 3. > a value: a. > a == a value. > > the first time we get "true", the second we get an infinite loop... > > A simple workaround is to declare "a": > > |a| > a := Association new. > a key: 3. > a value: a. > a == a value. > > My question now is: Is this a bug or a feature ? > By the way the same thing happens in 1.4 and 2.0 equally. > > By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "." > > Cheers, > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro > > > > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro > > > > > > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro

Dec. 9, 2012

[Pharo-project] Protecting against stack overflow ?

by Sven Van Caekenberghe

Hi, Would it be possible to build some kind of protection against stack overflow ? This is actually the most common situation for loop/cycle that either results in an unusable image or a crash. Interrupting with CMD-. is not always possible. A possible solution could be to just limit the stack size and throw an exception. For example, in LispWorks, it goes like this: CL-USER 5 > (defun foo () (cons (random 100) (foo))) FOO CL-USER 6 > (foo) Stack overflow (stack size 48128). 1 (continue) Extend stack by 50%. 2 (abort) Return to level 0. 3 Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. CL-USER 7 : 1 > :bq ERROR <- RUNTIME:BAD-ARGS-OR-STACK <- LENGTH <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- EVAL <- CAPI::CAPI-TOP-LEVEL-FUNCTION <- CAPI::INTERACTIVE-PANE-TOP-LOOP <- MP::PROCESS-SG-FUNCTION Obviously, this is possible, the question is, can it be done easily and without paying an unbearable performance price ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 9, 2012