can you open a bug entry?
Stef
On May 16, 2012, at 6:22 PM, Ben Coman wrote:
> This discussion originates from Mondrian on Moose 4.7 where layouts which
> previously were exactly reproducible now randomly alternate between two
> arrangements. I have cross-posted since upstream behaviour of
> Collection>>difference: has changed between Pharo 1.3 and 1.4.
>
> The issue in Mondrian has been isolated so that it can be observed using the
> attached changeset 'isolate-unstable-972.2.cs' against a fresh Moose 4.7
> image downloaded a few moments ago.
> After loading the cs, open a Transcript and then <Generate> the following
> script in Modrian Easel a dozen times.
> view shape label.
> view nodes: #(1 2 3 4 ).
> view edgesFromAssociations: { 1 -> 2. 1 ->3 . 3 -> 4}.
> view treeLayout
>
> At some point you will see a change in the order that nodes are drawn between
> runs as reflected in lines B2 and A2 shown below...
> ------------------------------RUN 1
> B1>an OrderedCollection(a MONode model: 2 a MONode model: 3)
> B2>an OrderedCollection(a MONode model: 3 a MONode model: 2)
> A2>a MONode model: 1
> A2>a MONode model: 3
> A2>a MONode model: 4
> A2>a MONode model: 2
> ------------------------------RUN 2
> B1>an OrderedCollection(a MONode model: 2 a MONode model: 3)
> B2>an OrderedCollection(a MONode model: 2 a MONode model: 3)
> A2>a MONode model: 1
> A2>a MONode model: 2
> A2>a MONode model: 3
> A2>a MONode model: 4
> ------------------------------END
>
>
> The cause of this is a change in behaviour of Collection>>#difference:
> between Pharo 1.3 & 1.4. This can be observed by executing the following in
> Workspace...
> 20 timesRepeat:
> [
> one := TextMorph new newContents: '1'.
> two := TextMorph new newContents: '2'.
> collection := (OrderedCollection with: one with: two).
> diff := collection difference: OrderedCollection new.
> Transcript crShow: diff first text, diff second text.
> ]
>
> In Pharo 1.3 the result never deviates from '12'.
> In Pharo 1.4 the result is sometimes '21'.
>
> Pharo 1.3 has...
> Collection>>difference: aCollection
> "Answer the set theoretic difference of two collections."
> ^ self reject: [:each | aCollection includes: each]
>
> Pharo 1.4 has...
> Collection>>difference: aCollection
> "Answer the set theoretic difference of two collections."
> | set|
> set := self asSet.
> aCollection do: [ :each|
> set remove: each ifAbsent: []].
> ^ self species withAll: set asArray
>
>
> Your thoughts?
>
> cheers -ben
>
>
> Tudor Girba wrote:
>> Could it be a Pharo issue, because I think it happened since we moved to
>> Pharo 1.4.
>>
>> Doru
>>
>>
>> On 15 May 2012, at 21:51, Alexandre Bergel wrote:
>>
>>
>>
>>> Well… this happens since the changes in the collection hierarchy a few
>>> weeks ago.
>>> The tree layout should indeed preserver the order. I spent some time but I
>>> could not see where the problem came from. I should spent some more time on
>>> this.
>>>
>>> Alexandre
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel
>>> http://www.bergel.eu
>>>
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>> On May 13, 2012, at 11:21 PM, Tudor Girba wrote:
>>>
>>>
>>>
>>>> Thanks, Alex.
>>>>
>>>> But, it is not good in this case to fix the tests because the rendering
>>>> should remain the same :(.
>>>>
>>>> For example, in the MetaBrowser I rely on the fact that the tree rendering
>>>> remains the same to highlight the currently selected property.
>>>>
>>>> We need to investigate this issue closer because it is an important bug.
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>> On 14 May 2012, at 04:04, Alexandre Bergel wrote:
>>>>
>>>>
>>>>
>>>>>>> I've seen you committed in the Mondrian rep about the rubber band drag
>>>>>>> and drop facilities. This is indeed an interesting feature. However, I
>>>>>>> feel a bit more work is necessary. Here are my suggestions:
>>>>>>> - can you make sure all the Mondrian tests are green. Apparently
>>>>>>> MORoot>>resetFormCacheResursively disappeared.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Do you mean MONode>>resetFormCacheResursively which was renamed in
>>>>>> Mondrian-Core-AlexandreBergel.79 ?
>>>>>> I've searched back a few Mondrian-Core mcz files and not found
>>>>>> MORoot>>resetFormCacheResursively.
>>>>>> I fixed a few remaining references to this in Mondrian-Core-BenComan.80
>>>>>> et al.
>>>>>>
>>>>>>
>>>>>>
>>>>> Ok, I've produced a new version of Mondrian that includes your changes.
>>>>>
>>>>>
>>>>>
>>>>>> I fixed MOLayoutTest>>testTreeLayout failure in
>>>>>> Mondrian-Tests-BenComan.101.
>>>>>> There is one remaining failure that I can't work out. TestRunner cannot
>>>>>> open a debugger on it and after inserting 'self halt' it steps through
>>>>>> to the end of the method without a failure. Makes no sense to me. I
>>>>>> need to leave this one to others.
>>>>>>
>>>>>>
>>>>>>
>>>>> The tree layout seems to randomly order the nodes. Type the following
>>>>> script in an easel:
>>>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>>>>> view shape rectangle withText.
>>>>> view nodes: #(1 2 3 4 ).
>>>>> view edgesFromAssociations: { 1 -> 2. 1 ->3 . 3 -> 4}.
>>>>> view treeLayout
>>>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>>>>>
>>>>> Times to times it produces:
>>>>> <Screen Shot 2012-05-13 at 10.02.08 PM.png>
>>>>>
>>>>> times to times it produces:
>>>>> <Screen Shot 2012-05-13 at 10.02.16 PM.png>
>>>>>
>>>>> A few weeks ago, it had always produced the same rendering, and tests had
>>>>> been written accordingly. Now it varies, so tests have to be adjusted. I
>>>>> fixed this.
>>>>> The test is now green.
>>>>>
>>>>>
>>>>>>> - add new tests that capture your change of MOCanvas>>mouseUp: ,
>>>>>>> MOCanvas>>mouseOver:, and possibly for MOCanvas>>drawOn:. Those methods
>>>>>>> are central to Mondrian, they need to be robust.
>>>>>>>
>>>>>>>
>>>>>> I will now start thinking about some tests for these.
>>>>>>
>>>>>>
>>>>>>
>>>>> Cool!
>>>>>
>>>>> Alexandre
>>>>>
>>>>>
>>>>>
>>>>>>> Let me know how it goes. Currently the tests of Mondrian are yellow.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Alexandre
>>>>>>>
>>>>>>>
>>>>>>> On 8 May 2012, at 16:42,
>>>>>>>
>>>>>>> [email protected]
>>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> See <http://hudson.moosetechnology.org/job/moose-latest-dev/972/>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Moose-dev mailing list
>>>>>>>>
>>>>>>>>
>>>>>>>> [email protected]
>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>>
>>>>>> [email protected]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>>
>>>>> [email protected]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>>
>>>>>
>>>> --
>>>>
>>>> www.tudorgirba.com
>>>>
>>>>
>>>> "Don't give to get. Just give."
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>>
>>>> [email protected]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>>
>>> [email protected]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>>
>>
>> --
>>
>> www.tudorgirba.com
>>
>>
>> Innovation comes in least expected form.
>> That is, if it is expected, it already happened.
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>>
>> [email protected]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>>
>>
>
> 'From Pharo1.4 of 18 April 2012 [Latest update: #14438] on 16 May 2012 at
> 11:15:20 pm'!
>
> !MOAbstractRegularTreeLayout methodsFor: 'hook' stamp: 'BenComan 5/16/2012
> 23:14'!
> doExecute: node
> | rootNodes btcdebug|
> alreadyLayoutedNodes := OrderedCollection new.
> rootNodes := self rootNodesFor: node nodes.
> nodesByLayer := OrderedCollection new.
>
> self flag: #btcdebug.
> "Regarding [email protected] emails 'Jenkins build is
> still unstable: moose-latest-dev #972'
> To isolate the issue, open a Transcript then generate the
> following in Mondrian Easel twenty times
> view shape label.
> view nodes: #(1 2 3 4 ).
> view edgesFromAssociations: { 1 -> 2. 1 ->3 . 3 -> 4}.
> view treeLayout.
> "
> btcdebug := rootNodes first.
> Transcript cr; crShow: '------------------------------'.
> Transcript crShow: 'B1>', (self childrenFor: btcdebug)
> asString.
> Transcript crShow: 'B2>', (self computeChildrenFor: btcdebug)
> asString.
>
> self
> layout: rootNodes
> atPoint: self leftGap @ self topGap
> atLayer: 1.
> self isLayered ifTrue: [
> self rearrangeByLayers: node ]! !
>
>
> !MOAbstractVerticalTreeLayout methodsFor: 'hook-private' stamp: 'BenComan
> 5/16/2012 23:02'!
> layout: aNodeCollection atPoint: aPoint atLayer: aNumber
> | treeSize childrenPosition x y middleOfTree |
> aNodeCollection isEmpty ifTrue: [ ^ 0 ].
> x := aPoint x.
> y := aPoint y.
> alreadyLayoutedNodes addAll: aNodeCollection.
> self atLayer: aNumber add: aNodeCollection.
> aNodeCollection do: [ :each |
> self flag: #btcdebug. Transcript crShow: 'A2>', each asString.
> childrenPosition := y + each height + self verticalGap.
> treeSize := each width
> max: (self layout: (self computeChildrenFor: each)
> atPoint: x @ childrenPosition atLayer: aNumber + 1).
> middleOfTree := x + (treeSize / 2.0) - (each width / 2.0).
> each translateTo: middleOfTree @ y.
> x := x + treeSize + self horizontalGap ].
> ^ x - aPoint x - self horizontalGap! !
>
