Have read through the various threads such as "How to do the ubiquitous home button?", do we still do it by implementing WAComponent#clearDelegate? Also, are there any consequences to sending #call: to a component multiple times? ie. I have a navigation bar with several links where each of them does a #call: to show the respective component. I'm trying to use the home link to, well, go back to home. Comments?
Yar Hwee Boon wrote:
Have read through the various threads such as "How to do the ubiquitous home button?", do we still do it by implementing WAComponent#clearDelegate? Also, are there any consequences to sending #call: to a component multiple times? ie. I have a navigation bar with several links where each of them does a #call: to show the respective component. I'm trying to use the home link to, well, go back to home. Comments?
I'm in the same boat. Until recently I haven't worried about it but now I can see the long delegation chains building up over time and session sizes are growing quickly as users navigate around. So, I don't have an answer but I anxiously await the feedback of others on this topic as well.
BTW, I don't see clearDelegate or even anything similar in 2.5b5.
David
On Oct 19, 2004, at 3:27 PM, C. David Shaffer wrote:
Yar Hwee Boon wrote:
Have read through the various threads such as "How to do the ubiquitous home button?", do we still do it by implementing WAComponent#clearDelegate? Also, are there any consequences to sending #call: to a component multiple times? ie. I have a navigation bar with several links where each of them does a #call: to show the respective component. I'm trying to use the home link to, well, go back to home. Comments?
I'm in the same boat. Until recently I haven't worried about it but now I can see the long delegation chains building up over time and session sizes are growing quickly as users navigate around. So, I don't have an answer but I anxiously await the feedback of others on this topic as well.
BTW, I don't see clearDelegate or even anything similar in 2.5b5.
I've just posted http://beta4.com/mc/seaside/Seaside2.5b5-avi.4.mcz , which includes a WAComponent>>home method that acts much like #clearDelegate. Note, however, that this may not solve your session size problem - I think I've found a memory leak to do with continuations in 2.5 that wasn't there in 2.3, that will cause sessions to grow much bigger than they ought to. As far as I know this is the last bug that needs fixing before taking 2.5 out of beta, though of course I'd love to hear about any others. It's a nasty one, though, and I don't think I'll have time to do anything about it until the weekend at best.
BTW, David, anything further to report on your testing framework? Are you using it successfully?
Avi
On Tue, 19 Oct 2004 16:01:47 +0200, Avi Bryant avi@beta4.com wrote:
I've just posted http://beta4.com/mc/seaside/Seaside2.5b5-avi.4.mcz ,
Slightly OT: what's the proper way to make this version accessible in Monticello? Copy the file directly to the local SM directory, ie. H:\progs\squeak\sm\cache\packages\4o0oeyavg19me3y905b6ekjht\13\ ? Or to my own repository? Or something else? Thanks.
On Oct 19, 2004, at 4:21 PM, Yar Hwee Boon wrote:
On Tue, 19 Oct 2004 16:01:47 +0200, Avi Bryant avi@beta4.com wrote:
I've just posted http://beta4.com/mc/seaside/Seaside2.5b5-avi.4.mcz ,
Slightly OT: what's the proper way to make this version accessible in Monticello? Copy the file directly to the local SM directory, ie. H:\progs\squeak\sm\cache\packages\4o0oeyavg19me3y905b6ekjht\13\ ? Or to my own repository? Or something else? Thanks.
Lots of ways. The simplest is probably to hit the +Repository button on the Monticello browser, choose HTTP as the repository type, and then put in 'http://beta4.com/mc/seaside' as the URL. Or, you could save it to disk, find it in the file loader, and hit Load (or Open if you don't want to load it immediately). Or, sure, throw it in your repository.
Avi
On Tue, 19 Oct 2004, Avi Bryant wrote:
size problem - I think I've found a memory leak to do with continuations in 2.5 that wasn't there in 2.3, that will cause sessions to grow much bigger than they ought to. As far as I know this is the last bug that needs fixing before taking 2.5 out of beta, though of course I'd love to hear about any others. It's a nasty one, though, and I don't think I'll have time to do anything about it until the weekend at best.
Aha! That's why my production image suddenly eats 150+mb ram compared to about 40mb in 2.3. Well the machine has 1gig so no hurry from my side :-)
On Oct 19, 2004, at 7:32 PM, radoslav hodnicak wrote:
On Tue, 19 Oct 2004, Avi Bryant wrote:
size problem - I think I've found a memory leak to do with continuations in 2.5 that wasn't there in 2.3, that will cause sessions to grow much bigger than they ought to. As far as I know this is the last bug that needs fixing before taking 2.5 out of beta, though of course I'd love to hear about any others. It's a nasty one, though, and I don't think I'll have time to do anything about it until the weekend at best.
Aha! That's why my production image suddenly eats 150+mb ram compared to about 40mb in 2.3. Well the machine has 1gig so no hurry from my side :-)
So, after looking into this, I can't find a leak after all. It may be that the overhead of 2.5 is for some reason much higher than for 2.3 (which I'll have to fix), but in all of my experiments, you can keep creating sessions or keep using a single session for as long as you want and memory usage is fairly flat. Has this also been your experience, or does it just keep growing? David, I know you also said something about memory usage being higher for you now?
As a more general question, how are people feeling about the recent betas of 2.5? I've been using it pretty heavily and it's been fine, and don't know of any unresolved bugs, so it may be time to release this thing.
Avi
Avi Bryant wrote:
So, after looking into this, I can't find a leak after all. It may be that the overhead of 2.5 is for some reason much higher than for 2.3 (which I'll have to fix), but in all of my experiments, you can keep creating sessions or keep using a single session for as long as you want and memory usage is fairly flat. Has this also been your experience, or does it just keep growing? David, I know you also said something about memory usage being higher for you now?
Avi,
Yes, what I think I was saying was the retention of a long delegation chain was chewing up memory. Not in hoards but certainly noticeable. That is, in my original app I would use call: for almost every form of link navigation. In most cases no answer was expected so I came to discover that this wasn't the correct pattern. The problem was more noticable lately since some of my views tended to hold onto some rather large objects (maybe I should have followed the MVC "observe the model" pattern?). I still haven't redone things to clear the delegates so it must not be too bad :-)
I don't have any indication that there is a leak w/ regards to session expiration.
As a more general question, how are people feeling about the recent betas of 2.5? I've been using it pretty heavily and it's been fine, and don't know of any unresolved bugs, so it may be time to release this thing.
Solid enough for my use. Thanks Avi!
David
On Fri, 5 Nov 2004, Avi Bryant wrote:
So, after looking into this, I can't find a leak after all. It may be that the overhead of 2.5 is for some reason much higher than for 2.3 (which I'll have to fix), but in all of my experiments, you can keep creating sessions or keep using a single session for as long as you want and memory usage is fairly flat. Has this also been your experience, or does it just keep growing? David, I know you also said something about memory usage being higher for you now?
Well it can be that squeak simply isn't giving the memory back, if I stop wakom and release all handlers and do GC, the image still eats 160mb ram.
As a more general question, how are people feeling about the recent betas of 2.5? I've been using it pretty heavily and it's been fine, and don't know of any unresolved bugs, so it may be time to release this thing.
Yeah I run it in production too and so far no problems
rado (awaiting a message about a horrible crash right after finishing the above sentence)
One thing I've noticed (in development images mostly) is that the Monticello cache can grow quite large. I've reset this cache and garbage collected to bring 100MB images down to 15MB.
Cheers, Andrew
radoslav hodnicak wrote:
On Fri, 5 Nov 2004, Avi Bryant wrote:
So, after looking into this, I can't find a leak after all. It may be that the overhead of 2.5 is for some reason much higher than for 2.3 (which I'll have to fix), but in all of my experiments, you can keep creating sessions or keep using a single session for as long as you want and memory usage is fairly flat. Has this also been your experience, or does it just keep growing? David, I know you also said something about memory usage being higher for you now?
Well it can be that squeak simply isn't giving the memory back, if I stop wakom and release all handlers and do GC, the image still eats 160mb ram.
As a more general question, how are people feeling about the recent betas of 2.5? I've been using it pretty heavily and it's been fine, and don't know of any unresolved bugs, so it may be time to release this thing.
Yeah I run it in production too and so far no problems
rado (awaiting a message about a horrible crash right after finishing the above sentence)
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
Avi Bryant wrote:
BTW, David, anything further to report on your testing framework? Are you using it successfully?
Our semester started in August so I haven't done much with it since then. I did make several improvements since my first "release" and I continue to use it successfully for several component sets. I have a student doing his senior project with Seaside and he has promised to test thoroughly...that should help point out problems.
I recently ran into a problem with the new initialization mechanism. From memory...one of my tests requires that I manually create the instance of the application to be tested (I forget why at the moment). The problem is that the session access in initializeDecoration doesn't happen in the context with the session bound correctly (it happens in my test case's context). So, for the immediate future I hope to deal with that and (from my TODO list):
. clean up the threading hoops I have to jump through to get tests to run without deadlocking . have live test cases in the history view so you can manually walk through them . display the request that was submitted in the history view (so you can see what form values were supplied) . support limited remote test cases (ones that don't directly access the component) . port to VW
I'm going to reply to Roger's post about SmallHttpUnit since there seems to be some overlap in these two works despite my tight integration with Seaside.
David
On Tue, 19 Oct 2004 16:01:47 +0200, Avi Bryant avi@beta4.com wrote:
Yar Hwee Boon wrote:
Have read through the various threads such as "How to do the ubiquitous home button?", do we still do it by implementing WAComponent#clearDelegate? Also, are there any consequences to sending #call: to a component multiple times? ie. I have a navigation
snipped.
size problem - I think I've found a memory leak to do with continuations in 2.5 that wasn't there in 2.3, that will cause sessions to grow much bigger than they ought to. As far as I know this is the last bug that needs fixing before taking 2.5 out of beta, though of course I'd love to hear about any others. It's a nasty one, though, and I don't think I'll have time to do anything about it until the weekend at best.
Are you saying it is OK to send #call: to a component multiple times?
On Oct 20, 2004, at 10:24 AM, Yar Hwee Boon wrote:
Are you saying it is OK to send #call: to a component multiple times?
Yes, it's ok, in that it will work. You may want to send it #home before sending it #call: the second time, depending I guess on what you want to have happen when the second #call: answers - do you want to be back at the original component, or at what it had previously called? The calls will work like a stack - you can push a new one on, but when that's over you'll be back into the previous one unless you clear it first.
On Wed, 20 Oct 2004 11:58:30 +0200, Avi Bryant avi@beta4.com wrote:
On Oct 20, 2004, at 10:24 AM, Yar Hwee Boon wrote:
Are you saying it is OK to send #call: to a component multiple times?
Yes, it's ok, in that it will work. You may want to send it #home before sending it #call: the second time, depending I guess on what you want to have happen when the second #call: answers - do you want to be back at the original component, or at what it had previously called? The calls will work like a stack - you can push a new one on, but when that's over you'll be back into the previous one unless you clear it first.
It's a navigation bar where there's links to several different "screens". I wouldn't be #answer:-ing from those calls. I take it that, I should send #home before a second (or third, etc) #call then.
On Oct 20, 2004, at 12:13 PM, Yar Hwee Boon wrote:
It's a navigation bar where there's links to several different "screens". I wouldn't be #answer:-ing from those calls. I take it that, I should send #home before a second (or third, etc) #call then.
If you're not #answer:-ing, why are you #call:-ing?
This is something that I need to find a way to emphasize better, in the Seaside documentation or the examples: there's no reason to overuse #call:. If your navigation bar is a way of switching between a set of components, why not model it that way? Take the tab component (WASimpleNavigation) as an example: have a collection of the components, and have your #renderContentOn: simply pick the right one and render it. The links in the nav bar just switch which component is currently chosen (using a 'selected' inst var or some such). You could quite easily build an entire Seaside app without ever using #call:/answer:, and there's really no reason to incur that overhead unless you need to.
Avi
On Wed, 20 Oct 2004 12:29:27 +0200, Avi Bryant avi@beta4.com wrote:
On Oct 20, 2004, at 12:13 PM, Yar Hwee Boon wrote:
It's a navigation bar where there's links to several different "screens". I wouldn't be #answer:-ing from those calls. I take it that, I should send #home before a second (or third, etc) #call then.
If you're not #answer:-ing, why are you #call:-ing?
Aaargh.. it never occurred to me to swap the components. I guess with the hammer in my hand.. everything looks like its begging for #call-#answer. Thanks for clearing that up.
This is something that I need to find a way to emphasize better, in the Seaside documentation or the examples: there's no reason to overuse
My guess is my question and your answer here in the archives is a good starting point. I don't remember anyone talking about this when I read through the archives. Maybe the Store example can be modified to add a simple example of this?
On Wed, 20 Oct 2004 18:39:34 +0800, Yar Hwee Boon hboon@motionobj.com wrote:
On Wed, 20 Oct 2004 12:29:27 +0200, Avi Bryant avi@beta4.com wrote:
On Oct 20, 2004, at 12:13 PM, Yar Hwee Boon wrote:
It's a navigation bar where there's links to several different "screens". I wouldn't be #answer:-ing from those calls. I take it that, I should send #home before a second (or third, etc) #call then.
If you're not #answer:-ing, why are you #call:-ing?
Aaargh.. it never occurred to me to swap the components. I guess with the hammer in my hand.. everything looks like its begging for #call-#answer. Thanks for clearing that up.
After studying WASimpleNavigation, and thinking through for a while, I realise that I may still need to use #call:. An example would be: one of the options is to show a forum. After browsing through the forum for a while (#call-ing other components to show different topics, replies, etc), and the user clicks another option, say Profile. At this point, if he tries to go back to Forum, he should see the "first page" of the forum again rather than the last state. So.. in this case, does it look like I really need #call without #answer:? I think that WASimpleNavigation mirrors how a "tab control" works,whereas what I have is more like a simple HTML link.
"Yar" == Yar Hwee Boon hboon@motionobj.com writes:
Yar> After studying WASimpleNavigation, and thinking through for a Yar> while, I realise that I may still need to use #call:. An example Yar> would be: one of the options is to show a forum. After browsing Yar> through the forum for a while (#call-ing other components to show Yar> different topics, replies, etc), and the user clicks another Yar> option, say Profile. At this point, if he tries to go back to Yar> Forum, he should see the "first page" of the forum again rather Yar> than the last state.
Why not send the forum a #reInit message or something like that? (you can hook that in your navigation bar #selectionChanged message)
Sam
On Oct 20, 2004, at 1:25 PM, Yar Hwee Boon wrote:
After studying WASimpleNavigation, and thinking through for a while, I realise that I may still need to use #call:. An example would be: one of the options is to show a forum. After browsing through the forum for a while (#call-ing other components to show different topics, replies, etc), and the user clicks another option, say Profile. At this point, if he tries to go back to Forum, he should see the "first page" of the forum again rather than the last state. So.. in this case, does it look like I really need #call without #answer:? I think that WASimpleNavigation mirrors how a "tab control" works,whereas what I have is more like a simple HTML link.
I think you just want to be creating a new instance of the Forum every time they click the forum link, and setting that as the selected component.
"Avi" == Avi Bryant avi@beta4.com writes:
Avi> Take the tab component (WASimpleNavigation) as an example
By the way, I just had a look at it. What is the purpose of #selectedController? (it looks like it refers to a non-existent controllers instance variable)
Sam
On Oct 20, 2004, at 12:50 PM, Samuel Tardieu wrote:
"Avi" == Avi Bryant avi@beta4.com writes:
Avi> Take the tab component (WASimpleNavigation) as an example
By the way, I just had a look at it. What is the purpose of #selectedController? (it looks like it refers to a non-existent controllers instance variable)
Yup, that's cruft. Delete it.
Try to use goto: it works well. This code was posted by avi a lon time ago
goto: aController " I should also point out the methods #willCall and #willAnswer on WAComponent (actually its superclass, WAController). By default these return true. If you know, however, that your component either never sends #call: or never sends #answer:, you can override them to return false and Seaside will make the appropiate optimizations. So that, for example, making a #call: to a component that has #willAnswer returning false is effectively a #goto:. By avi@beta4.com " delegate contents: aController
Yar Hwee Boon ha scritto in data 20/10/2004 12.13:
On Wed, 20 Oct 2004 11:58:30 +0200, Avi Bryant avi@beta4.com wrote:
On Oct 20, 2004, at 10:24 AM, Yar Hwee Boon wrote:
Are you saying it is OK to send #call: to a component multiple times?
Yes, it's ok, in that it will work. You may want to send it #home before sending it #call: the second time, depending I guess on what you want to have happen when the second #call: answers - do you want to be back at the original component, or at what it had previously called? The calls will work like a stack - you can push a new one on, but when that's over you'll be back into the previous one unless you clear it first.
It's a navigation bar where there's links to several different "screens". I wouldn't be #answer:-ing from those calls. I take it that, I should send #home before a second (or third, etc) #call then.
On Wed, 20 Oct 2004 12:32:53 +0200, Giovanni Giorgi jj@objectsroot.com wrote:
Try to use goto: it works well.
Thanks. In the light of Avi's reply (of not using #call) in this case, is there any example where #goto: is appropriate?
Avi Bryant ha scritto in data 20/10/2004 13.18:
On Oct 20, 2004, at 12:32 PM, Giovanni Giorgi wrote:
Try to use goto: it works well. This code was posted by avi a lon time ago
Yes, and only works on Seaside 2.3 :).
Oppps :( Are you saying it doesn't work in the new version seaside? And what we must use instead? (This news sounds terrible after I have written a lot of code using it :P )
On Oct 20, 2004, at 3:12 PM, Giovanni Giorgi wrote:
Avi Bryant ha scritto in data 20/10/2004 13.18:
On Oct 20, 2004, at 12:32 PM, Giovanni Giorgi wrote:
Try to use goto: it works well. This code was posted by avi a lon time ago
Yes, and only works on Seaside 2.3 :).
Oppps :( Are you saying it doesn't work in the new version seaside? And what we must use instead? (This news sounds terrible after I have written a lot of code using it :P )
Sorry, I didn't mean to alarm you, I was just posting in a hurry. Let me try to make up for that.
In Seaside 2.5, the simplest way of replacing a component visually with another is using #show:. This is effectively the same thing as #goto:, so your old code would work fine if you did:
WAComponent>>goto: otherComponent self show: otherComponent
There is also #show:onAnswer:, which takes a block that will be triggered when the other component sends #answer: -
self show: yesNoDialog onAnswer: [:bool | bool ifTrue: [...] ifFalse: [...]]
This then gets combined with continuation capture to provide the more familar #call:
(self call: yesNoDialog) ifTrue: [...] ifFalse: [...]
seaside@lists.squeakfoundation.org
-
Andrew Catton -
Avi Bryant -
C. David Shaffer -
Giovanni Giorgi -
radoslav hodnicak -
Samuel Tardieu -
Yar Hwee Boon