Hi Tudor, It looks like replacing:
GLMMorphicListingRenderer>>#actOnUpdatedPresentation: anAnnouncement treeMorph model updateRoots
with:
GLMMorphicListingRenderer>>#actOnUpdatedPresentation: anAnnouncement anAnnouncement presentation suspendAllWhile: [ treeMorph model updateRoots ]
makes sense (I was having a lot of updates when updating on a list who was being "transmited" by a tree presentation)
what do you think? can I commit this?
cheers, Esteban
Hi Esteban,
Interesting.
Before doing this, I would like to understand a bit more the implications. So, could you tell us: - are tests still green after the change? (I guess so, but you never know :)) - what are the announcements that go to the presentation when you send updateRoots? - what is an estimation of the performance increase in your case?
Cheers, Doru
On 17 Jun 2011, at 14:41, Esteban Lorenzano wrote:
Hi Tudor, It looks like replacing:
GLMMorphicListingRenderer>>#actOnUpdatedPresentation: anAnnouncement treeMorph model updateRoots
with:
GLMMorphicListingRenderer>>#actOnUpdatedPresentation: anAnnouncement anAnnouncement presentation suspendAllWhile: [ treeMorph model updateRoots ]
makes sense (I was having a lot of updates when updating on a list who was being "transmited" by a tree presentation)
what do you think? can I commit this?
cheers, Esteban _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"What we can governs what we wish."
Hi,
El 17/06/2011, a las 10:22a.m., Tudor Girba escribió:
Hi Esteban,
Interesting.
Before doing this, I would like to understand a bit more the implications. So, could you tell us:
- are tests still green after the change? (I guess so, but you never know :))
the tests:
288 run, 278 passes, 4 expected failures, 1 failures, 5 errors, 0 unexpected passes Failures: GLMFinderMorphicTest>>#testDefaultFixedSizePanes
Errors: GLMBrowserTest>>#testUnregisterAnnouncements GLMBrowserTest>>#testUnregisterAnnouncementsWhenRemovingPane GLMBrowserTest>>#testUnregisterAnnouncementsWhenUpdatingPane GLMBrowserTest>>#testUnregisterAnnouncementsWhenUpdatingPaneWithTwoAnnouncers GLMFinderTest>>#testUnregisterAnnouncementsWhenRemovingPane
- what are the announcements that go to the presentation when you send updateRoots?
I don't know :)
- what is an estimation of the performance increase in your case?
well... I noticed the problem because I have this browser: "a tree transmits to a list". I have an action who triggers an announcement who triggers an update on list (it is a filter, but with a form, not the text input glamour provides). The update was being called 1+tree nodes deep opened (yes, that annoying), so the displayValue for the list was being calculated at least 2 times (and usually 4 times, because the way the tree is used) and it was a large list... so it was taking a lot of time... and multiplied by 2-4 times.
Cheers, Doru
On 17 Jun 2011, at 14:41, Esteban Lorenzano wrote:
Hi Tudor, It looks like replacing:
GLMMorphicListingRenderer>>#actOnUpdatedPresentation: anAnnouncement treeMorph model updateRoots
with:
GLMMorphicListingRenderer>>#actOnUpdatedPresentation: anAnnouncement anAnnouncement presentation suspendAllWhile: [ treeMorph model updateRoots ]
makes sense (I was having a lot of updates when updating on a list who was being "transmited" by a tree presentation)
what do you think? can I commit this?
cheers, Esteban _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"What we can governs what we wish."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Esteban,
I found a source of the problem related to not resetting announcements when copying panes. Perhaps this affects your issue as well.
Could you try again?
I would also be very interested in knowing how to reproduce your problem. Could you describe a small scenario (maybe a small example and tell me where I should put the halt :))?
Cheers, Doru
On 17 Jun 2011, at 15:41, Esteban Lorenzano wrote:
Hi,
El 17/06/2011, a las 10:22a.m., Tudor Girba escribió:
Hi Esteban,
Interesting.
Before doing this, I would like to understand a bit more the implications. So, could you tell us:
- are tests still green after the change? (I guess so, but you never know :))
the tests:
288 run, 278 passes, 4 expected failures, 1 failures, 5 errors, 0 unexpected passes Failures: GLMFinderMorphicTest>>#testDefaultFixedSizePanes
Errors: GLMBrowserTest>>#testUnregisterAnnouncements GLMBrowserTest>>#testUnregisterAnnouncementsWhenRemovingPane GLMBrowserTest>>#testUnregisterAnnouncementsWhenUpdatingPane GLMBrowserTest>>#testUnregisterAnnouncementsWhenUpdatingPaneWithTwoAnnouncers GLMFinderTest>>#testUnregisterAnnouncementsWhenRemovingPane
- what are the announcements that go to the presentation when you send updateRoots?
I don't know :)
- what is an estimation of the performance increase in your case?
well... I noticed the problem because I have this browser: "a tree transmits to a list". I have an action who triggers an announcement who triggers an update on list (it is a filter, but with a form, not the text input glamour provides). The update was being called 1+tree nodes deep opened (yes, that annoying), so the displayValue for the list was being calculated at least 2 times (and usually 4 times, because the way the tree is used) and it was a large list... so it was taking a lot of time... and multiplied by 2-4 times.
Cheers, Doru
On 17 Jun 2011, at 14:41, Esteban Lorenzano wrote:
Hi Tudor, It looks like replacing:
GLMMorphicListingRenderer>>#actOnUpdatedPresentation: anAnnouncement treeMorph model updateRoots
with:
GLMMorphicListingRenderer>>#actOnUpdatedPresentation: anAnnouncement anAnnouncement presentation suspendAllWhile: [ treeMorph model updateRoots ]
makes sense (I was having a lot of updates when updating on a list who was being "transmited" by a tree presentation)
what do you think? can I commit this?
cheers, Esteban _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"What we can governs what we wish."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Being happy is a matter of choice."
-
Esteban Lorenzano -
Tudor Girba