[sugar] Memory allocation indicators

[Kent Loobey]

On Wednesday 12 March 2008 10:51:15 pm Benjamin M. Schwartz wrote:
> The original inspiration for the Activity Ring was that the Ring could
> serve both to indicate which activities were running and how much memory
> they were using.  This was considered important in order to provide
> feedback to prevent users from attempting to open many activities at once.
> ~ Typical Windows users have difficulty keeping track of which programs
> they have open, and so wind up having many programs open simultaneously,
> causing swapping even on machines with a great deal of memory.  This
> problem is perhaps even worse on Mac OS X.  Since the original XO design
> only had 128 MB of RAM, it was considered crucial that the UI provide
> feedback to prevent an Out Of Memory situation.
>
> With the Ring now being abandoned entirely, the UI will no longer contain
> an indicator of memory usage.  The amount of memory is now 256 MB.  The
> question is: do users need  to know how memory is being used, and if so,
> what sort of indicator is appropriate?

As a rule of thumb you shouldn't tell a user anything that you will not let 
them do something about.  So in this case unless you are going to list the 
memory demand of all of the activities they could optionally start next there 
is no point in telling them how much memory they are allready using.

I do think indicating how many activities they have running of the total 
number they can run is VERY useful.

>
> Also, it would be easy for Rainbow to enforce a pre-set hard limit on
> memory usage for each Activity separately.  

Does Python support activity segment overlays?

> I think that this is very 
> interesting, since it would allow us to ensure that OOM never happens, by
> only launching an activity if all activities could still max out their
> quota afterwards.  However, this reduces the functionality of the system,
> by limiting the number of running activities to the worst-case scenario.

Hmm, one could divide the total available memory into pages (say 16KB each).  
Then each activity could specify the number of pages it needs to run.  You 
could then use that number to inform decisions.