[sugar] A Hello World that does it all?

Sat Mar 15 12:59:38 EDT 2008

sugar-request at lists.laptop.org schrieb:
> Message: 6
> Date: Thu, 13 Mar 2008 08:40:36 -0700
> From: Kent Loobey <kent at uoregon.edu>
> Subject: Re: [sugar] A Hello World that does it all?
> To: "Tomeu Vizoso" <tomeu at tomeuvizoso.net>
> Cc: sugar at lists.laptop.org
> Message-ID: <200803130840.36982.kent at uoregon.edu>
> Content-Type: text/plain;  charset="iso-8859-1"
>
> On Thursday 13 March 2008 4:08:28 am you wrote:
>   
>> On Sat, Mar 8, 2008 at 10:33 PM, Kent Loobey <kent at uoregon.edu> wrote:
>>     
>>> Is there a "Hello World" python example that includes all of the basic
>>>  XO/Sugar necessities, i.e., journalling, building, file storage,
>>> whatever?
>>>       
>> Don't think so, if you are interested in completing the existing
>> content in the wiki, feel free to ask any questions in this mailing
>> list.
>>     
>
> My problem with updating wikies is stated clearly by Paul Fox's email "icon 
> assistance/validation" posted 2008-03-11 7:55 pm.
>
> "figuring out how to structure the icon "by documentation" isn't
> all that easy, either -- even though there are no fewer than 5
> pages which describe parts of the process and guidelines."
>
> I find this to be a serious problem for me as well.  I don't know which wiki 
> to update.  The XO has a large number of elements that need to be done 
> correctly before an activity is read for dispersal into the wilds.
>
> My idea is to create a hello-world like activity that demonstrates a minimal 
> activity that covers all of the bases.  I am plugging away on it as we speak.  
> I call it "OpenWorld.activity".  :-)
>
>   
>>>  I am assuming that there are two ways to go with python at this point,
>>>  OLPCGames and OLPCGTK.  Is this right or are there other options?
>>>       
>> Well, in principle you could use PyQT or whatever other toolkit or
>> libraries, but OLPC is currently putting more effort in PyGTK and
>> PyGames. If you use any library not included in the platform, you will
>> have to ship it inside your activity bundle.
>>     
>
> I decided to start with PyGTK since it seemed to me that the example would be 
> a little clearer to follow than it would be in PyGames.
>
> This is going to help me have a base for later projects that I want to 
> develop.  I will want to make what I learn available to others but I have yet 
> to work that out.  I would like a single wiki that tells me what I need to 
> know to develop an activity but I don't see how that can happen.
>   

This is exactly what we're trying to do with the OLPC Austria 'Activity 
Handbook'

http://www.olpcaustria.org/mediawiki/index.php/Activity_handbook

Cheers,
Christoph

> So that is what I am doing.  Maybe others can tell me a better way to proceed.
>
>   
>> Hope it helps,
>>
>> Tomeu
>>     
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 13 Mar 2008 11:47:28 -0400
> From: "Benjamin M. Schwartz" <bmschwar at fas.harvard.edu>
> Subject: Re: [sugar] Memory allocation indicators
> To: Kent Loobey <kent at uoregon.edu>
> Cc: bens at alum.mit.edu, Sugar Mailing List <sugar at lists.laptop.org>
> Message-ID: <47D94C90.4050102 at fas.harvard.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Kent Loobey wrote:
> | On Wednesday 12 March 2008 10:51:15 pm Benjamin M. Schwartz wrote:
> |>  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.
>
> Users would quickly get a feel for how much "ring space" each activity
> takes, since the amount of space is shown at runtime.  If launching failed
> with a not-enough-memory error, people would get the picture very quickly.
>
> |
> | I do think indicating how many activities they have running of the total
> | number they can run is VERY useful.
>
> The total number of Browse instances you can run is about 3.  The total
> number of Terminal instances you can run is probably 20 or more.
>
> |
> |> 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 was specifically referring to per-user memory limits.  Since Rainbow
> creates a new, independent user for each Activity instance, all the
> standard Linux per-user accounting can easily be activated.  These
> standard kernel-level tools include limits on amount of memory used,
> number of processes, amount of disk space, number of inodes, minimum
> process priority level, etc.
>
> |> 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.
>
> "Paging" is handled at the kernel level.  Yes, Activities could indicate
> ahead of time how much memory they require.  That is precisely the
> proposal I was discussing.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFH2UyQUJT6e6HFtqQRAq7TAJ9ll6Os3Z1BDq9jzjgW3/oWRXQT4QCbBdWz
> +qhkyNFm2pA+xyFAMTg/b+0=
> =nPjL
> -----END PGP SIGNATURE-----
>
>
> ------------------------------
>
> _______________________________________________
> Sugar mailing list
> Sugar at lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
>
>
> End of Sugar Digest, Vol 21, Issue 27
> *************************************
>
>