- Pharo-dev - lists.pharo.org

[Pharo-project] Kind of Spreadsheet component for Seaside?

by Friedrich Dominicus

I'm just wondering does anyone have/know about a kind of spreadsheet component/application for Seaside? Any hints are welcome Friedrich

Dec. 10, 2012

Re: [Pharo-project] strange == behavior

by Ben Coman

What downsides would be to doing... Float>>nan ^ NaN copy. Nicolas Cellier wrote: > 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. 10, 2012

Re: [Pharo-project] strange == behavior

by Igor Stasenko

On 9 December 2012 19:34, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > 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! > simply for the reason that associations are part of dictionaries. if you need to use associations outside of dicts, why not just using simple arrays? #(1 2) = #( 1 4) or ask yourself, why then we need a distinct class for associations, if its behavior is same as for collection of 2 elements? Lets then just rewrite Dictionary to use array first / array second instead of association key / value. > 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. > if we follow this, then all comparison methods in system should be implemented to always compare all fields for equality, without exception. Otherwise you risking to confuse people a lot ! :) > Marcus -- Best regards, Igor Stasenko.

Dec. 10, 2012

Re: [Pharo-project] Helping the noobs help out - i.e. fixing the debugger

by Nicolas Cellier

No, old timers are equally upset by false/wrong visual feedback, especially when they remember this used to work 25 years ago ;) Nicolas 2012/12/9 adrians <nmanole(a)gmail.com>: > Hi, > > I'm a Smalltalk newbie and I would like to help fix some simpler issues. For > example, I've recently logged some issues surrounding smart character use. I > set a breakpoint in NECController>>#smartCharacterWithEvent: and proceeded > to debug. > > Now, I understand that for the old-timers stepping through a selector is > straightforward, no matter what help the debugger gives you. For myself, and > likely many other Smalltalk noobs who'd like to help, I need all the help I > can get. One such support is an accurate indication of where the PC is as > you step through a body of code. Currently, in the 2.0 one-click image > (build 20431), things seem quite broken wrt getting accurate visual feedback > of where you are. > > First, as you step over message sends, the highlighted selection is shown in > a totally incorrect spot. Sometimes, just a bit off from where you expect to > be, but sometimes quite a bit off, for example in a block that should not > even be entered. In the selector I mentioned above, the highlighted location > enters the "editor hasSelection ifTrue: []" block when "editor hasSelection" > returns false. > > Second, the PC location highlight is removed when you click somewhere inside > the code. This should never turn off - it's as if you switch the lights off, > for people not familiar with some particular code. I know you can use the > "Where" button to re-establish the highlight, but other than the fact that > you shouldn't have to do this, the highlighted selection is sometimes shown > in the wrong place. > > Third, as you step through code, you would expect that the values of > variables as shown in the bottom right panel of the debugger are accurately > updated as state changes. I've seen cases, relatively frequent, where this > is not so. Current values are shown only after some further advancement > through code. > > There is an old issue tracking debugger selection, > http://code.google.com/p/pharo/issues/detail?id=709 > <http://code.google.com/p/pharo/issues/detail?id=709> , but fixing the > problem seems to have stalled. Additionally, I'm not sure that this > particular issue addresses the third point I made about stale variable > values being shown. > > Could I ask that making the debugger work be made a priority? Of course one > can muddle through some code even with visually broken indicators, but it > should not be so, IMO. The old timers can make the case that there are other > more pressing issues to be addressed, but IMO it makes sense to make the > actual tool used to fix problems as helpful as possible for everyone so that > even non-experts can be productive and lend a helping hand. > > > Cheers, > Adrian > > > > -- > View this message in context: http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 9, 2012

[Pharo-project] Helping the noobs help out - i.e. fixing the debugger

by adrians

Hi, I'm a Smalltalk newbie and I would like to help fix some simpler issues. For example, I've recently logged some issues surrounding smart character use. I set a breakpoint in NECController>>#smartCharacterWithEvent: and proceeded to debug. Now, I understand that for the old-timers stepping through a selector is straightforward, no matter what help the debugger gives you. For myself, and likely many other Smalltalk noobs who'd like to help, I need all the help I can get. One such support is an accurate indication of where the PC is as you step through a body of code. Currently, in the 2.0 one-click image (build 20431), things seem quite broken wrt getting accurate visual feedback of where you are. First, as you step over message sends, the highlighted selection is shown in a totally incorrect spot. Sometimes, just a bit off from where you expect to be, but sometimes quite a bit off, for example in a block that should not even be entered. In the selector I mentioned above, the highlighted location enters the "editor hasSelection ifTrue: []" block when "editor hasSelection" returns false. Second, the PC location highlight is removed when you click somewhere inside the code. This should never turn off - it's as if you switch the lights off, for people not familiar with some particular code. I know you can use the "Where" button to re-establish the highlight, but other than the fact that you shouldn't have to do this, the highlighted selection is sometimes shown in the wrong place. Third, as you step through code, you would expect that the values of variables as shown in the bottom right panel of the debugger are accurately updated as state changes. I've seen cases, relatively frequent, where this is not so. Current values are shown only after some further advancement through code. There is an old issue tracking debugger selection, http://code.google.com/p/pharo/issues/detail?id=709 <http://code.google.com/p/pharo/issues/detail?id=709> , but fixing the problem seems to have stalled. Additionally, I'm not sure that this particular issue addresses the third point I made about stale variable values being shown. Could I ask that making the debugger work be made a priority? Of course one can muddle through some code even with visually broken indicators, but it should not be so, IMO. The old timers can make the case that there are other more pressing issues to be addressed, but IMO it makes sense to make the actual tool used to fix problems as helpful as possible for everyone so that even non-experts can be productive and lend a helping hand. Cheers, Adrian -- View this message in context: http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 9, 2012

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