December 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Browsing hierarchy in 2.0

by Nicolas Cellier

Oups, I just saw the Hierarchy button ! 2012/12/9 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > How do I browse hierarchy: for example that of Array? > I know I can type Array browseHierarchy, select it and doIt, but I > mean efficiently... > > Nicolas

Dec. 9, 2012

[Pharo-project] Browsing hierarchy in 2.0

by Nicolas Cellier

How do I browse hierarchy: for example that of Array? I know I can type Array browseHierarchy, select it and doIt, but I mean efficiently... Nicolas

Dec. 9, 2012

Re: [Pharo-project] strange == behavior

by Nicolas Cellier

Ah, my mistake, modifying LookupKey does nothing to Association we should move the == test in Associaiton itself... 2012/12/9 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > No, it's just a fast test, because if objects are == they also are = > (except Float nan). > However, if they are ~~ they still can be =. > > If you look at SequenceableCollection>>= otherCollection > "Answer true if the receiver is equivalent to the otherCollection. > First test for identity, then rule out different species and sizes of > collections. As a last resort, examine each element of the receiver > and the otherCollection." > > self == otherCollection ifTrue: [^ true]. > self species == otherCollection species ifFalse: [^ false]. > ^ self hasEqualElements: otherCollection > > We could do the same with Association... > LookupKey>>= aLookupKey > > self == aLookupKey ifTrue: [^ true]. > self species = aLookupKey species > ifTrue: [^key = aLookupKey key] > ifFalse: [^false] > > Note that this has side effect for the sole object I know not equal to itself: > > | a | > a := {Float nan}. > a = a. "is true" > a = {Float nan }. "is false" > > | a | > a := #x -> Float nan. > a = a. "is currently false but would be true after LookupKey change" > a = #x -> Float nan. "false even after LookupKey change, true after > Ciprian fix, but should it?" > > Nicolas > > 2012/12/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> 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

No, it's just a fast test, because if objects are == they also are = (except Float nan). However, if they are ~~ they still can be =. If you look at SequenceableCollection>>= otherCollection "Answer true if the receiver is equivalent to the otherCollection. First test for identity, then rule out different species and sizes of collections. As a last resort, examine each element of the receiver and the otherCollection." self == otherCollection ifTrue: [^ true]. self species == otherCollection species ifFalse: [^ false]. ^ self hasEqualElements: otherCollection We could do the same with Association... LookupKey>>= aLookupKey self == aLookupKey ifTrue: [^ true]. self species = aLookupKey species ifTrue: [^key = aLookupKey key] ifFalse: [^false] Note that this has side effect for the sole object I know not equal to itself: | a | a := {Float nan}. a = a. "is true" a = {Float nan }. "is false" | a | a := #x -> Float nan. a = a. "is currently false but would be true after LookupKey change" a = #x -> Float nan. "false even after LookupKey change, true after Ciprian fix, but should it?" Nicolas 2012/12/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > 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] eating some obsolete dog food

by Nicolas Cellier

Finally, FALSE INFORMATION, sorry... switching to correct VM DID NOT SOLVE MY PROBLEM... It must be that I took a different path second time I tried... Here is a recipe to re-create the problem: 1) Download a fresh image 2) Open a TestRunner 3) Run the CompilerTests I then get the bogus Dialog behavior... Strange thing, if I interrupt with cmd+. then select and execute code for AuthorNameRequest defaultAction, the second dialog box works... I don't want to dig further, raising some notification to invoke a dialog sounds weird, and soon on the stack you find this awfull method: MorphicUIManager>>modalMorph which scans thisContext send stack... Hmmm encapsulation they said... Superpowers for evil? Nicolas 2012/12/8 Ben Coman <btc(a)openinworld.com>: > Nicolas Cellier wrote: >> >> This is a long time since I did not contribute to Pharo, so I tried >> with something easy... >> http://code.google.com/p/pharo/issues/detail?id=7108 >> >> I downloaded latest successful build, >> Pharo2.0a >> Latest update: #20433 >> >> Then I updated the 5 methods from a MC merge, and... >> Err... I cannot type my initials ^H^H^H^H^H^H^H^H full name >> The dialog insists on selecting any letter I type and next letter will >> override the previous one. >> I finally published anonymously, that does not matter... >> >> But you know the impact of a first bad UI impression... >> It would ruin tons of efforts I know you spent cleaning the >> infrastructure. >> I believe such cleaning is very ambitious and rarely rewarding in the >> short term... >> But I'd really like to be more supportive, it's so essential for >> building the future. >> >> So before ranting loud, I digged a bit further: could it be this >> warning I had at startup about obsolete VM, yes that was it! >> So if you are episodic user like me : >> >> ******** DON'T FORGET TO DOWNLOAD A PHARO SPECIFIC VM ************* >> >> I already spent way more time on this than I wished, hope my mistake >> helps someone else. >> ( over-estimating pharo planned obsolescence period is indeed a >> mistake ;) why would the VM be handled differently ? ) >> >> Last thing, maybe you should insist on the download page that 2.0 >> REQUIRES a pharo specific VM. >> Not sure I would have read it, but then it would be entirely my fault. >> >> Nicolas >> >> >> > > Or... for 2.0 Beta and 2.0 Release provide only a one-click package. If > anyone wants just the image, they can get it from the CI server. >

Dec. 9, 2012

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