Re: [Sugar-devel] Fwd: Activity startup idea
On Tue, Feb 24, 2009 at 03:38, Wade Brainerd wad...@gmail.com wrote: On Mon, Feb 23, 2009 at 5:57 PM, Luke Faraone l...@faraone.cc wrote: On Mon, Feb 23, 2009 at 5:46 PM, Carol Farlow Lerche c...@msbit.com wrote: Spend a few hours in a kindergarten classroom. It doesn't work to prevent repeated launching of activities and ultimately a need to reboot. Is there anything sugar can do in this regard? Would this activity starting logic work: * If no activity instances are running, start it. * If an instance has been started already but the process has not yet signaled on the dbus that it is running, ie drawing windows etc. for the user, switch to that instance * If an instance has been started and is running, start a new instance. (*or* send a start new instance request to the existing instance, which allows us to save the overhead of loading up another python process) * Reap all instances still in the starting state for more than X seconds that have not explictly requested this functionality to be disabled nor signaled via the dbus that they are still active What about watching system resources and refusing to start a new activity when there isn't enough RAM available to launch it? It should be pretty straightforward to add a required_memory field to activity.info - it would be a simple, approximate high water mark memory usage for a given activity. The default could be determined by analyzing the basic activities - maybe 20mb would be good? Are we sure this is a good experience for our users? I remember that in the old MacOS times, I found a bit tiring to have to go to the applications' info panel to lower the memory limits so the app could launch. The problem I see is that both the available memory in the system and the consumed memory by a single activity are complex to measure and much more to anticipate, so we probably won't get good enough estimations to put in the activity.info. Regards, Tomeu Just seems like we should be attacking the problem by attacking the problem. Cheers, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Activity startup idea
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomeu Vizoso wrote: The problem I see is that both the available memory in the system and the consumed memory by a single activity are complex to measure and much more to anticipate, so we probably won't get good enough estimations to put in the activity.info. I agree that this is a very hard problem, unlikely to be solved, but I've been thinking a bit about it anyway. The problem, as you say, is requiring authors to estimate the usage in activity.info. What if, instead, Sugar automatically estimated the memory usage of each activity based on past performance? Last year I wrote up an algorithm for predicting how much power each Activity will use, using only measurements of the system's total power usage.[1] What I realized is, the math problem is the same for estimating the memory usage of each Activity, knowing only the total memory usage. In fact, we can probably do much better than that, since we have many good, accurate tools for reporting memory usage, like pmap.[2] The deep problem, as others have noted, is that the maximum memory usage of many programs varies widely depending on the input data, and is therefore extremely difficult to predict. I think we can find a middle ground, a conservative, minimalist approach to proactive memory management. The policy is: Sugar should not allow* the user to start an Activity that is unlikely to finish starting. To implement this, Sugar should measure the memory usage of each activity immediately after startup, before the Activity is provided with any input data. This memory usage should be relatively consistent for each activity, depending only on system parameters (like screen resolution and architecture) and on shared libraries (mostly meaning which other activities are open). Here's a pseudocode snippet to indicate the simplest possible implementation: def try_to_launch(some_activity): if (some_activity not in mem_usage database) or (mem_usage_database[some_activity] available_memory()): m1 = available_memory() launch(some_activity) m2 = available_memory() if m2 - m1 mem_usage_database[some_activity]: mem_usage_database[some_activity] = m2 - m1 return SUCCESS else: return INSUFFICIENT_MEMORY This launcher prevents launching an activity if, in order to launch successfully, the activity would have to use less memory on startup than it has ever used before. Over time, we can upgrade this algorithm to use advanced heuristics, including knowledge of how different activities interact with regard to memory usage. This approach alone will never lead to the complete absence of OOM conditions, but it should allow us to make them much less likely without impairing the user experience. - --Ben [1] http://wiki.laptop.org/go/Per-Activity_Power_Usage [2] http://virtualthreads.blogspot.com/2006/02/understanding-memory-usage-on-linux.html *: At least, the launcher icons should change to indicate that they are not recommended. Unfortunately, they're already gray, so we'll have to think of something else... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm1RxMACgkQUJT6e6HFtqT5wgCeOijnNlIwen7RX3tTlB65zM1c 1k0AnR8jnSND79R3Lx+Z0dntMJ+uhAAy =jyUy -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Activity startup idea
On Mon, Mar 9, 2009 at 9:56 AM, Gary C Martin g...@garycmartin.com wrote: On 9 Mar 2009, at 13:28, Tomeu Vizoso wrote: On Tue, Feb 24, 2009 at 03:38, Wade Brainerd wad...@gmail.com wrote: What about watching system resources and refusing to start a new activity when there isn't enough RAM available to launch it? It should be pretty straightforward to add a required_memory field to activity.info - it would be a simple, approximate high water mark memory usage for a given activity. The default could be determined by analyzing the basic activities - maybe 20mb would be good? Are we sure this is a good experience for our users? I remember that in the old MacOS times, I found a bit tiring to have to go to the applications' info panel to lower the memory limits so the app could launch. Yea, that was rather a frequent support call back in my early Adobe days :-) Set it too low and they can't open some document, to high and they can't run the other couple of applications they needed open at the same time to work. Even a warning alert would be better than nothing. Your computer is too low on memory to start this activity. Are you sure you want to start Browse? It happens to me at least once every couple of days on build 767...first the UI freezes, then the trackpad stops responding, and if I'm lucky I can manage to Ctrl-Alt-F1 and kill Browse before having to just hard power off. And that's just with GMail (in Browse), a Terminal, and Typing Turtle (which is admittedly a memory hog due to all the cached key graphics). Also, I think we should really consider implementing that kernel OOM watch feature. Activities save their state when you tab away from them, so in a lot of cases it's safe to just kill background activities. Best, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Activity startup idea
On Mon, Mar 9, 2009 at 17:52, Wade Brainerd wad...@gmail.com wrote: On Mon, Mar 9, 2009 at 9:56 AM, Gary C Martin g...@garycmartin.com wrote: On 9 Mar 2009, at 13:28, Tomeu Vizoso wrote: On Tue, Feb 24, 2009 at 03:38, Wade Brainerd wad...@gmail.com wrote: What about watching system resources and refusing to start a new activity when there isn't enough RAM available to launch it? It should be pretty straightforward to add a required_memory field to activity.info - it would be a simple, approximate high water mark memory usage for a given activity. The default could be determined by analyzing the basic activities - maybe 20mb would be good? Are we sure this is a good experience for our users? I remember that in the old MacOS times, I found a bit tiring to have to go to the applications' info panel to lower the memory limits so the app could launch. Yea, that was rather a frequent support call back in my early Adobe days :-) Set it too low and they can't open some document, to high and they can't run the other couple of applications they needed open at the same time to work. Even a warning alert would be better than nothing. Your computer is too low on memory to start this activity. Are you sure you want to start Browse? This I like more than refusing to start the activity. And Ben's suggestion about being the shell to calculate it is interesting. It happens to me at least once every couple of days on build 767...first the UI freezes, then the trackpad stops responding, and if I'm lucky I can manage to Ctrl-Alt-F1 and kill Browse before having to just hard power off. And that's just with GMail (in Browse), a Terminal, and Typing Turtle (which is admittedly a memory hog due to all the cached key graphics). Wonder if compcache would help you there? Also, I think we should really consider implementing that kernel OOM watch feature. Activities save their state when you tab away from them, so in a lot of cases it's safe to just kill background activities. Yes, I like this scenario. If we can give a low kill priority to the shell, wm, X, etc and to the activity in the foreground and a high kill priority to the activities in the bg, I think that stability will get much better. But in that case we need to provide a good way to explain to the user that a background activity was killed and why. Thanks, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Activity startup idea
On Mon, Mar 9, 2009 at 1:19 PM, Eben Eliason e...@laptop.org wrote: On Mon, Mar 9, 2009 at 1:10 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Mon, Mar 9, 2009 at 17:52, Wade Brainerd wad...@gmail.com wrote: On Mon, Mar 9, 2009 at 9:56 AM, Gary C Martin g...@garycmartin.com wrote: On 9 Mar 2009, at 13:28, Tomeu Vizoso wrote: On Tue, Feb 24, 2009 at 03:38, Wade Brainerd wad...@gmail.com wrote: What about watching system resources and refusing to start a new activity when there isn't enough RAM available to launch it? It should be pretty straightforward to add a required_memory field to activity.info - it would be a simple, approximate high water mark memory usage for a given activity. The default could be determined by analyzing the basic activities - maybe 20mb would be good? Are we sure this is a good experience for our users? I remember that in the old MacOS times, I found a bit tiring to have to go to the applications' info panel to lower the memory limits so the app could launch. Yea, that was rather a frequent support call back in my early Adobe days :-) Set it too low and they can't open some document, to high and they can't run the other couple of applications they needed open at the same time to work. Even a warning alert would be better than nothing. Your computer is too low on memory to start this activity. Are you sure you want to start Browse? This I like more than refusing to start the activity. And Ben's suggestion about being the shell to calculate it is interesting. Alerts were a consideration behind the new fullscreen launcher approach, actually. At the time, we wanted a nice way to indicate failure of an activity to launch, and our answer to that was a message beneath the icon in the launcher, buttons as necessary, and a notification from the activity when the alert appeared. For a launch failure we could provide (Give up) (Show logs) (Try again) options, for instance. In the memory case, we can have a memory warning message with (Cancel) and (Launch Anyway) options. Also, I think we should really consider implementing that kernel OOM watch feature. Activities save their state when you tab away from them, so in a lot of cases it's safe to just kill background activities. Yes, I like this scenario. If we can give a low kill priority to the shell, wm, X, etc and to the activity in the foreground and a high kill priority to the activities in the bg, I think that stability will get much better. But in that case we need to provide a good way to explain to the user that a background activity was killed and why. This sounds like another good use for the launcher. What if the activity didn't just go away completely? Instead, we could kill the activity, but replace it with the launcher again, with a colored icon representing the instance which was closed (instead of the pulsing one at launch). It could indicate that the activity was paused due to memory concerns, and that clicking the icon will resume the activity. We could also have (Stop) and (Resume) buttons, of course. Excellent ideas. I like how in this proposal the frame icon won't just disappear when the activity is killed. It's also great that the information about what happened is available immediately when you next try to switch back to the activity. Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Activity startup idea
On 23 Feb 2009, at 20:46, Wade Brainerd wrote: Opening up a conversation with Eben about the activity startup animation. The pulsing, scaling icon appears to slow down activity startup, at least on slow hardware like the XO. I suggested replacing the pulsing icon with a static one, and surrounding it with dots at a rate of 1 per second. Eben suggests an alternative, replacing the pulsing one with a blinking icon. It strikes me that the two could possibly be combined. To be honest, I like the idea of static icon with 'clock' dots appearing as an alternative. Now I do like the current pulsing (there to prevent impatient random clicking on other UI slowing things down even more), but if no one can code the pulsing lean enough, given the XO hardware, then we perhaps need to move on. --Gary Anyone else want to weigh in? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Activity startup idea
The pulsing doesn't prevent random clicking. On Mon, Feb 23, 2009 at 2:26 PM, Gary C Martin g...@garycmartin.com wrote: On 23 Feb 2009, at 20:46, Wade Brainerd wrote: Opening up a conversation with Eben about the activity startup animation. The pulsing, scaling icon appears to slow down activity startup, at least on slow hardware like the XO. I suggested replacing the pulsing icon with a static one, and surrounding it with dots at a rate of 1 per second. Eben suggests an alternative, replacing the pulsing one with a blinking icon. It strikes me that the two could possibly be combined. To be honest, I like the idea of static icon with 'clock' dots appearing as an alternative. Now I do like the current pulsing (there to prevent impatient random clicking on other UI slowing things down even more), but if no one can code the pulsing lean enough, given the XO hardware, then we perhaps need to move on. --Gary Anyone else want to weigh in? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- It is difficult to get a man to understand something, when his salary depends upon his not understanding it. -- Upton Sinclair ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Activity startup idea
On Mon, Feb 23, 2009 at 5:30 PM, Carol Farlow Lerche c...@msbit.com wrote: The pulsing doesn't prevent random clicking. I thought it was to be as a don't worry, we're working symbol, thus letting the user know that their last click _did_ cause the activity to load. The issue is that after a few seconds there is no visual feedback provided to the user; they have no way of knowing whether their activity is *truly* loading or has failed to start, since sugar does not reap zombie activities in non-joyride builds. (Although I'm not sure how that will work with Sugar on other platforms) -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Activity startup idea
Spend a few hours in a kindergarten classroom. It doesn't work to prevent repeated launching of activities and ultimately a need to reboot. On Mon, Feb 23, 2009 at 2:39 PM, Luke Faraone l...@faraone.cc wrote: On Mon, Feb 23, 2009 at 5:30 PM, Carol Farlow Lerche c...@msbit.com wrote: The pulsing doesn't prevent random clicking. I thought it was to be as a don't worry, we're working symbol, thus letting the user know that their last click _did_ cause the activity to load. The issue is that after a few seconds there is no visual feedback provided to the user; they have no way of knowing whether their activity is *truly* loading or has failed to start, since sugar does not reap zombie activities in non-joyride builds. (Although I'm not sure how that will work with Sugar on other platforms) -- Luke Faraone http://luke.faraone.cc -- It is difficult to get a man to understand something, when his salary depends upon his not understanding it. -- Upton Sinclair ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Activity startup idea
On Mon, Feb 23, 2009 at 5:46 PM, Carol Farlow Lerche c...@msbit.com wrote: Spend a few hours in a kindergarten classroom. It doesn't work to prevent repeated launching of activities and ultimately a need to reboot. Is there anything sugar can do in this regard? Would this activity starting logic work: * If no activity instances are running, start it. * If an instance has been started already but the process has not yet signaled on the dbus that it is running, ie drawing windows etc. for the user, switch to that instance * If an instance has been started and is running, start a new instance. (*or* send a start new instance request to the existing instance, which allows us to save the overhead of loading up another python process) * Reap all instances still in the starting state for more than X seconds that have not explictly requested this functionality to be disabled nor signaled via the dbus that they are still active -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Activity startup idea
Luke Faraone wrote: On Mon, Feb 23, 2009 at 5:46 PM, Carol Farlow Lerche c...@msbit.com wrote: Spend a few hours in a kindergarten classroom. It doesn't work to prevent repeated launching of activities and ultimately a need to reboot. Is there anything sugar can do in this regard? In 0.84, clicking an icon in the home view for an activity that is already running will simply switch to the running instance. It will still be possible to have multiple instances open, by selecting new instance from a dropdown menu, but multiple instances will not be created without a deliberate conscious choice. I expect that this will dramatically reduce the incidence of the effect that Carol describes. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Activity startup idea
On 23 Feb 2009, at 22:30, Carol Farlow Lerche wrote: The pulsing doesn't prevent random clicking. Please elaborate! I'm on the edge of my chair here!! This is just the kind of feedback needed!!! With my 7, 10 and 11yr old nieces and nephew, the main reason I observed for multiple activity instances were: a) not being able to find the Stop on an activity, they were 'done' and wanted a fresh start... b) it was easier to find the home view and just launch a new activity instance. They did **clearly** want things to start sooner, but did not independently discover the hot corners; there fore had nothing to click on while their first choice (slowly) started up (other wise I'm sure there would have been multiple simultaneous activity launches and all the pain that entails). --Gary P.S I've used up my pling quota for the next few emails, apologies for any offence. On Mon, Feb 23, 2009 at 2:26 PM, Gary C Martin g...@garycmartin.com wrote: On 23 Feb 2009, at 20:46, Wade Brainerd wrote: Opening up a conversation with Eben about the activity startup animation. The pulsing, scaling icon appears to slow down activity startup, at least on slow hardware like the XO. I suggested replacing the pulsing icon with a static one, and surrounding it with dots at a rate of 1 per second. Eben suggests an alternative, replacing the pulsing one with a blinking icon. It strikes me that the two could possibly be combined. To be honest, I like the idea of static icon with 'clock' dots appearing as an alternative. Now I do like the current pulsing (there to prevent impatient random clicking on other UI slowing things down even more), but if no one can code the pulsing lean enough, given the XO hardware, then we perhaps need to move on. --Gary Anyone else want to weigh in? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- It is difficult to get a man to understand something, when his salary depends upon his not understanding it. -- Upton Sinclair ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Activity startup idea
On Mon, Feb 23, 2009 at 5:57 PM, Luke Faraone l...@faraone.cc wrote: On Mon, Feb 23, 2009 at 5:46 PM, Carol Farlow Lerche c...@msbit.comwrote: Spend a few hours in a kindergarten classroom. It doesn't work to prevent repeated launching of activities and ultimately a need to reboot. Is there anything sugar can do in this regard? Would this activity starting logic work: * If no activity instances are running, start it. * If an instance has been started already but the process has not yet signaled on the dbus that it is running, ie drawing windows etc. for the user, switch to that instance * If an instance has been started and is running, start a new instance. (*or* send a start new instance request to the existing instance, which allows us to save the overhead of loading up another python process) * Reap all instances still in the starting state for more than X seconds that have not explictly requested this functionality to be disabled nor signaled via the dbus that they are still active What about watching system resources and refusing to start a new activity when there isn't enough RAM available to launch it? It should be pretty straightforward to add a required_memory field to activity.info - it would be a simple, approximate high water mark memory usage for a given activity. The default could be determined by analyzing the basic activities - maybe 20mb would be good? Just seems like we should be attacking the problem by attacking the problem. Cheers, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
