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

Re: [Pharo-project] [Moose-dev] Collection>>difference: behaviour in 1.4 (was Re: Jenkins build is still unstable: moose-latest-dev #972 )

by Tudor Girba

Excellent hunting! I think this is a conceptual bug in the current Pharo implementation. Anyway, I fixed it now (and added a comment): MOAbstractGraphLayout>>childrenFor: aNode except: aNodeCollection ^(self childrenFor: aNode) reject: [:each | aNodeCollection includes: each] "we are explicitly not using the default Collection>>difference: behavior here because we want to preserve the order of the collection" Thanks, Doru On 16 May 2012, at 18:22, 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, >>>>>>> >>>>>>> admin(a)moosetechnology.org >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> See <http://hudson.moosetechnology.org/job/moose-latest-dev/972/> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Moose-dev mailing list >>>>>>>> >>>>>>>> >>>>>>>> Moose-dev(a)iam.unibe.ch >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> >>>>>> Moose-dev(a)iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> >>>>> Moose-dev(a)iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> >>>>> >>>> -- >>>> >>>> www.tudorgirba.com >>>> >>>> >>>> "Don't give to get. Just give." >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> >>>> Moose-dev(a)iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> >>>> >>> _______________________________________________ >>> Moose-dev mailing list >>> >>> Moose-dev(a)iam.unibe.ch >>> 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 >> >> Moose-dev(a)iam.unibe.ch >> 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 moose-dev(a)iam.unibe.ch 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! ! > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "We cannot reach the flow of things unless we let go."

May 16, 2012

Re: [Pharo-project] Are we losing method versions?

by Guillermo Polito

Isn't the .changes somehow shrinked before every release? That should explain that. On Wed, May 16, 2012 at 8:16 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > For DateAndTime class>>#readFrom: ... > > In Pharo 1.0, only one version: 'PeterHugossonMiller 9/3/2009 01:10' > In Pharo 1.2.2, two versions, minus the one from 1.0: "#('SeanDeNigris > 8/5/2010 15:51' 'StephaneDucasse 4/24/2010 12:46')" > In Pharo 2.0, only the last version from 1.2.2 remains: 'SeanDeNigris > 8/5/2010 15:51' > > -- > View this message in context: > http://forum.world.st/Are-we-losing-method-versions-tp4630520.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

May 16, 2012

[Pharo-project] Are we losing method versions?

by Sean P. DeNigris

For DateAndTime class>>#readFrom: ... In Pharo 1.0, only one version: 'PeterHugossonMiller 9/3/2009 01:10' In Pharo 1.2.2, two versions, minus the one from 1.0: "#('SeanDeNigris 8/5/2010 15:51' 'StephaneDucasse 4/24/2010 12:46')" In Pharo 2.0, only the last version from 1.2.2 remains: 'SeanDeNigris 8/5/2010 15:51' -- View this message in context: http://forum.world.st/Are-we-losing-method-versions-tp4630520.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 16, 2012

Re: [Pharo-project] User questions

by Guillermo Polito

On Wed, May 16, 2012 at 7:01 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > I think the options we identified are: > * StackOverflow > * dedicated site > - we seem not to fit stackexchange's guidelines > - our own hosted site, possibly like http://ask.rascal-mpl.org/questions/ > * Users mailing list > > The disadvantage of the users list vs. the other options is that the domain > model is much weaker for questions/answers e.g. was it answered? does the > community think it's a good answer? > > On the question of internal/external. I guess the big tradeoff is the > visibility of something like SO (where the outside world will see the > energy > of Pharo's Smalltalk revival) vs. keeping control of the content. > > Of the two options available this second, which do we prefer to get started > - SO, or the users list? > I like SO, but the most important is the discipline. Every time a non-bleedingedge-dev question is sent to the list, we should encourage people to treat it in the corresponding place instead of answer it :). > > Sean > > -- > View this message in context: > http://forum.world.st/User-questions-tp4630513.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

May 16, 2012

[Pharo-project] User questions

by Sean P. DeNigris

I think the options we identified are: * StackOverflow * dedicated site - we seem not to fit stackexchange's guidelines - our own hosted site, possibly like http://ask.rascal-mpl.org/questions/ * Users mailing list The disadvantage of the users list vs. the other options is that the domain model is much weaker for questions/answers e.g. was it answered? does the community think it's a good answer? On the question of internal/external. I guess the big tradeoff is the visibility of something like SO (where the outside world will see the energy of Pharo's Smalltalk revival) vs. keeping control of the content. Of the two options available this second, which do we prefer to get started - SO, or the users list? Sean -- View this message in context: http://forum.world.st/User-questions-tp4630513.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 16, 2012

Re: [Pharo-project] Pharo is exploding

by Pavel Krivanek

On Wed, May 16, 2012 at 5:51 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > StÃ©phane Ducasse wrote >> >> And can we have a private developer mailing-list :) >> > > What the heck are you guys talking about?! Everyone take a deep breath... > Here's the reality: > Â One person who is > Â Â a) not here to defend himself, and > Â Â b) (allegedly) not using Pharo > Â (allegedly) made an off-list comment that some developers (allegedly, > possibly including himself) may find it jarring that in a year, one could > find an unrecognizable latest version of Pharo. This, by the way, is true, > even if it may not change our vision or plans. It may be unrecognizable. > And, some developers *may* find that unsatisfactory. As we've already > established, people do not like change. > > Now, none of this seems like a reason for all this fuss. It's wasting our > time and energy, which is already at capacity making Pharo the system of our > dreams. Specifically, I think a private developers list would hurt Pharo > both psychologically and physically - we want as many eyes on the issues at > hand as possible. > > Finally, the SO/separate-stackexchange-site/dev/users issue is a separate > thing. If we're going to talk about mailing list discipline, let's stop > hijacking people's threads. Well said. I'm sorry for initiating this direction of discussion and my apologies to GermÃ¡n that he may be seen now in wrong light. I do not like the idea of the next separate mainling list. Remember huge amount of Squeak mailing lists in past. >From my point of view Pharo finally starts to do real changes. Till now it mainly focused on necessary cleanup of the system and a lot of small changes. And there is no wonder that now we want everything we prayed for as soon as possible. I understand that the tempo may be too fast for some people to follow and as a person that is taking care of Pharo Kernel I know the frustration it can sometimes bring. But it is an extreme case and normal developer should have much less amount of problems. -- Pavel > In closing: > * Let's all get back to work. People will react emotionally to the massive > progress (change) of Pharo. Duly noted, but it's in the damn manifesto ("Not > backward compatible" [1]). > * Maybe we can improve our communication process, both for the devs and > users. Let's discuss that. > > [1] http://code.google.com/p/pharo/ > > -- > View this message in context: http://forum.world.st/Pharo-is-exploding-tp4630233p4630489.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

May 16, 2012

Re: [Pharo-project] [update 2.0] #20076

by Sean P. DeNigris

EstebanLM wrote > > MC Speedup > Hooray! -- View this message in context: http://forum.world.st/update-2-0-20076-tp4630502p4630505.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 16, 2012

[Pharo-project] [update 2.0] #20076

by Esteban Lorenzano

20076 ----- Issue 5669: MC Speedup http://code.google.com/p/pharo/issues/detail?id=5669

May 16, 2012

Re: [Pharo-project] Pharo is exploding

by Esteban Lorenzano

Hi, Yeah... but there is a point somewhere there: we need to improve our communication efforts... we need to start thinking as a "growing community" (because that's what I *feel* it is happening). So... which changes would be valuable? I think a developers blog is a good idea (I think we can try to keep it, and we can also ask some non-Lille stablished developers to also talk about what their are doing for Pharo... we are after all an Open Source project, when not everybody lives here, I can think in several names, but you all know them :) Also, I would like to move user questions to: users list or stackoverflow... Why? because that's the purpose of that list ;) So, this list will continue being like now, for the unstable development, but ppl can have a "safe" place where to ask about the stable version. Well... probably something like that would help to easy the development... I will try to start blogging about upcoming changes for Pharo 2.0 (and motives, what can you expect, etc.) right after PharoConf... lets hope that will help a little (not sure, if we take my english level into account, he). best, Esteban On May 16, 2012, at 5:51 PM, Sean P. DeNigris wrote: > > StÃ©phane Ducasse wrote >> >> And can we have a private developer mailing-list :) >> > > What the heck are you guys talking about?! Everyone take a deep breath... > Here's the reality: > One person who is > a) not here to defend himself, and > b) (allegedly) not using Pharo > (allegedly) made an off-list comment that some developers (allegedly, > possibly including himself) may find it jarring that in a year, one could > find an unrecognizable latest version of Pharo. This, by the way, is true, > even if it may not change our vision or plans. It may be unrecognizable. > And, some developers *may* find that unsatisfactory. As we've already > established, people do not like change. > > Now, none of this seems like a reason for all this fuss. It's wasting our > time and energy, which is already at capacity making Pharo the system of our > dreams. Specifically, I think a private developers list would hurt Pharo > both psychologically and physically - we want as many eyes on the issues at > hand as possible. > > Finally, the SO/separate-stackexchange-site/dev/users issue is a separate > thing. If we're going to talk about mailing list discipline, let's stop > hijacking people's threads. > > In closing: > * Let's all get back to work. People will react emotionally to the massive > progress (change) of Pharo. Duly noted, but it's in the damn manifesto ("Not > backward compatible" [1]). > * Maybe we can improve our communication process, both for the devs and > users. Let's discuss that. > > [1] http://code.google.com/p/pharo/ > > -- > View this message in context: http://forum.world.st/Pharo-is-exploding-tp4630233p4630489.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

May 16, 2012

[Pharo-project] Collection>>difference: behaviour in 1.4 (was [Moose-dev] Re: Jenkins build is still unstable: moose-latest-dev #972 )

by Ben Coman

'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 moose-dev(a)iam.unibe.ch 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! !

May 16, 2012