Re: [Sugar-devel] Killing activities when memory gets short

[Marco Pesenti Gritti]

On 7 Aug 2010, at 21:08, Tiago Marques  wrote:
> Just killing a random activity is a terrible idea becayse you don't want your 
> product behaving like it's defective; the pop up idea is way more 
> acceptable(and a lot better than having the system randomly behaving like 
> it's crashed). Either way, this is the extremely important use of swap memory 
> that doesn't exist here. I understand your engineering constraints on the 
> hardware but randomly killing activities is poised to confuse users and cause 
> people considering the hardware for deployment to think that you're selling 
> them something defective/baddly manufactured.

As long as activities are saving and restoring properly it could be made pretty 
much transparent to the user. Of course that's easier said then done...

Marco 
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Adding committers on gitorious (was: Re: [PATCH] Remove nbsp chars from the html string before parsing)

[Marco Pesenti Gritti]

On 6 Aug 2010, at 13:35, Tomeu Vizoso  wrote:
> 
>> I was just throwing in the idea here. I will bother you further only
>> once I have a realistic plan in mind (and confidence in the ability to
>> execute it with our limited resources) :)
> 
> Sorry if I sounded harsh, I wanted to explain why some "reforms" are
> not going forward yet even if people agree are necessary.
> 

Oh, no worries, I don't think you sounded harsh at all.

>> 
>> That's actually the other thing I'm planning to look into. Maybe I'm
>> mistake but I feel we are stuck with a review process most of the
>> existing contributors are unhappy with. I can work on a formal
>> proposal and try to reach consensus, if that's what is missing...
> 
> Sounds great, though I have felt that there was a bit of misdirected
> frustration during that conversation.
> 

As in the real problem not being the process but the slow response due to the 
lack of maintainers? 

> If distros drop a platform dependency in the same release where the
> replacement lands (what happens with gnome-python2-desktop in Fedora
> 14), it means that everybody needs to build that dependency until they
> update to that release.
> 
> Moreover, if some distros only include the new dependency at a later
> release (as with Ubuntu Maverick and Gtk3), contributors running one
> of those distros need to build more stuff for longer.

My feeling is that these are a bit of special situations due to the dynamic 
bindings migration and gtk 3, I don't see they happening normally. Also it 
seems like they will hurt in the same way when we actually get to package Sugar 
on these distributions.

> We can reduce the harm by keeping PPA-like repos for the distros that
> need it (what the telepathy guys do for Ubuntu), but then someone
> needs to do that work.

I wouldn't spend resources on this, it's error prone and time consuming.

> In summary, I'm able to see the importance of making as easy as
> possible running latest sugar on all distros, but I'm afraid it's one
> more goal we want to attain but don't know how to resource.

To be clear, my goal is not to support all distro. I think it would be 
reasonable to say that you need the latest Fedora/Debian/Ubuntu to be able to 
build Sugar without messing with dependencies.

I think there is a bit of a chicken and egg problem here. Making it easy to 
start developing Sugar is probably one of the best ways to increase the 
resources we can spend on user visible improvements.

Marco

>> 
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Sugarbot working on latest Sugar

[Tim McNamara]

Is there interest in pushing an updated sugarbot to git.sl.o?

I have spent some time over the last three days getting Sugarbot to run in
sugar-jhbuild. After a few code changes, and lots of reading, I have been
successful.

Some changes that needed to be made from the 0.1 release:
 - a few syntax errors
 - update sugarbot.py to access  jarabe.model.bundleregistry.get_registry,
rather than sugar.shell.registry and update associated methods

Left to do:

Think... Sugarbot's widget identification system worked well when text-based
labels were common place. Recent Sugar versions have moved to a highly
icon-based naming system. Developers will either need to make use
of gtk.Widget.set_name() or another widget identification algorithm will
need to be established.

There are several things under the hood that I think would be useful. I
think some of what I would like to do would be classed as code style
changes, rather than substantive though.

Thoughts & questions welcome.

Tim
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Killing activities when memory gets short

[Martin Langhoff]

On Sat, Aug 7, 2010 at 1:31 PM, Bernie Innocenti  wrote:
> El Sat, 07-08-2010 a las 18:14 +0200, Tomeu Vizoso escribió:
>
>> So we would have a periodic wakeup? The test would be the amount of
>> free memory plus buffers and caches?
>
> A polled design is clearly inferior to a proper notification system, but

I think we can just win big time without polling and without killing.

 - grab the python code from ps_mem.py. We' ll be reading mem usage
from our own processes (w/o rainbow at least) so I suspect no need for
priv operation

 - when the user opens a new activity, poll used/free memory with some
pre-set constants and if warranted send a 'close' signal to the best
candidate (weighed LRU + mem usage score)

 -- depends on closing without asking for a document name...

 - Opportunistic checks on activity switch, view change can complement this.

The above matches what my Android phone does and as a user, works great.

cheers,




m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Lazy Network Neighborhood updates

[Mikus Grinbergs]

>> invitation icons seem to persist long after all invitors/invitees are gone.
>
> is this as 'simple' as removing the notification when the activity id is no 
> longer being
>  shared?  Or would you like the UI to still indicate that you had missed the 
> event/s?

I imagine if someone clicks on an invitation, sees his Activity being
launched, but then fails to make a connection -- that could well be more
frustrating than never seeing evidence of the event/s having happened.

mikus

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Lazy Network Neighborhood updates

[Gary Martin]

Hi Mikus,

On 7 Aug 2010, at 20:01, Mikus Grinbergs  wrote:

>> We already readjust the network neighborhood layout on the fly when we
>> switch view. It's funny to see the access points slide around  :-) 
> 
> Haven't bothered to keep track of the appearance/disappearance of XO and
> AP icons in Neighborhood View - it's hard to figure out whether their
> presence on screen is determined by View updating or by radio reception.
> 
> But something that needs attention is the handling of "invitation icons"
> in Neighborhood view.  I would like such an icon to mean "there exists
> RIGHT NOW someone else with whom I can collaborate".  Instead, these
> icons seem to persist long after all invitors/invitees are gone.

Nice observation. I'm afraid I seem to rarely use invitations when testing, 
though I do test Journal file transfers a reasonable amount — which falls into 
a similar situation. So is this as 'simple' as removing the notification when 
the activity id is no longer being shared? Or would you like the UI to still 
indicate that you had missed the event/s?

--Gary 

> Thanks,  mikus
> ___
> 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] Lazy Network Neighborhood updates

[Mikus Grinbergs]

> We already readjust the network neighborhood layout on the fly when we
> switch view. It's funny to see the access points slide around  :-) 

Haven't bothered to keep track of the appearance/disappearance of XO and
AP icons in Neighborhood View - it's hard to figure out whether their
presence on screen is determined by View updating or by radio reception.

But something that needs attention is the handling of "invitation icons"
in Neighborhood view.  I would like such an icon to mean "there exists
RIGHT NOW someone else with whom I can collaborate".  Instead, these
icons seem to persist long after all invitors/invitees are gone.

Thanks,  mikus

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] touchpad mode selection

[Walter Bender]

On Fri, Aug 6, 2010 at 9:10 AM, Paul Fox  wrote:
> walter -- currently we try at boot time and set the touchpad to
> whichever mode the user last requested.  moving this
> initialization to sugar was one of the last changes you made to
> the sugar code, i think.
>
> but when you were in the office you mentioned that it might be
> preferable to always revert to capacitive (normal) mode at boot
> time, so that the user doesn't get stuck or confused by "pen
> mode" (which is certainly less "discoverable' than normal mode).
>
> the more i think about it, the more i think that's a good idea.
> what do other people (who, hopefully have tried both modes)
> think?
>
>
> paul
> =-
>  paul fox, p...@laptop.org
>

http://bugs.sugarlabs.org/attachment/ticket/2006/0001-touchpad-with-finger-mode-default.patch
defaults to capacitive on boot. It no longer uses the FLAG_FILE and
thus that file is no longer needed by your patch either. Its presence
will not impact the functionality, as far as I know. I've tested this
on 258py. I'd appreciate your doing a quick review just to make sure I
didn't miss anything.

-walter


-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Lazy Network Neighborhood updates

[Bernie Innocenti]

El Sat, 07-08-2010 a las 19:36 +0200, Tomeu Vizoso escribió:
> On a second thought, Sugar should probably only listen to events
> relevants to what is being currently displayed. This would display
> outdated data for a short while and would mean significant rework but
> may be a worthy goal for the future.

We already readjust the network neighborhood layout on the fly when we
switch view. It's funny to see the access points slide around :-)

So, +1 for lazy updates, as long as NM keeps doing its background
scanning even when it's not being queried by the client.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Killing activities when memory gets short

[Bernie Innocenti]

El Sat, 07-08-2010 a las 19:33 +0200, Tomeu Vizoso escribió:
> > BTW, looking at top, it seems that Sugar and other processes wake up
> > quite frequently when the system is supposed to be completely idle. It
> > may be background checks for updates, NetworkManager updates or the
> > presence service. Plus, there are a bunch of cron jobs that run in the
> > background, inclding the ds-backup and olpc-update.
> >
> > All these things drain battery power and cause the UI to become jerky,
> > so we should try to limit them if possible.
> 
> NM is particularly active when there are more than a few APs
> available, wonder if it would be possible to tune it to group updates
> in batches.

That would be a good question for Dan (cc'd :-).

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Killing activities when memory gets short

[Tomeu Vizoso]

On Sat, Aug 7, 2010 at 19:33, Tomeu Vizoso  wrote:
> On Sat, Aug 7, 2010 at 19:31, Bernie Innocenti  wrote:
>> El Sat, 07-08-2010 a las 18:14 +0200, Tomeu Vizoso escribió:
>>
>>> So we would have a periodic wakeup? The test would be the amount of
>>> free memory plus buffers and caches?
>>
>> A polled design is clearly inferior to a proper notification system, but
>> it has the advantage of being simple and not requiring a particular
>> kernel. Once this is done, switching to a better solution should not
>> require extensive changes to the UI code.
>>
>> BTW, looking at top, it seems that Sugar and other processes wake up
>> quite frequently when the system is supposed to be completely idle. It
>> may be background checks for updates, NetworkManager updates or the
>> presence service. Plus, there are a bunch of cron jobs that run in the
>> background, inclding the ds-backup and olpc-update.
>>
>> All these things drain battery power and cause the UI to become jerky,
>> so we should try to limit them if possible.
>
> NM is particularly active when there are more than a few APs
> available, wonder if it would be possible to tune it to group updates
> in batches.

On a second thought, Sugar should probably only listen to events
relevants to what is being currently displayed. This would display
outdated data for a short while and would mean significant rework but
may be a worthy goal for the future.

Regards,

Tomeu

> Regards,
>
> Tomeu
>
>>> > Or, maybe, we could make this a manual process: pop up a notification
>>> > when memory is short and ask which activity should be closed.
>>>
>>> I would just close one of the background activities, the LRU or the biggest 
>>> one.
>>
>> +1.
>>
>> This, however, makes non-sugarized activities more dangerous to deal
>> with. One more reason to demand proper sugarization.
>>
>> --
>>   // Bernie Innocenti - http://codewiz.org/
>>  \X/  Sugar Labs       - http://sugarlabs.org/
>>
>>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Killing activities when memory gets short

[Tomeu Vizoso]

On Sat, Aug 7, 2010 at 19:31, Bernie Innocenti  wrote:
> El Sat, 07-08-2010 a las 18:14 +0200, Tomeu Vizoso escribió:
>
>> So we would have a periodic wakeup? The test would be the amount of
>> free memory plus buffers and caches?
>
> A polled design is clearly inferior to a proper notification system, but
> it has the advantage of being simple and not requiring a particular
> kernel. Once this is done, switching to a better solution should not
> require extensive changes to the UI code.
>
> BTW, looking at top, it seems that Sugar and other processes wake up
> quite frequently when the system is supposed to be completely idle. It
> may be background checks for updates, NetworkManager updates or the
> presence service. Plus, there are a bunch of cron jobs that run in the
> background, inclding the ds-backup and olpc-update.
>
> All these things drain battery power and cause the UI to become jerky,
> so we should try to limit them if possible.

NM is particularly active when there are more than a few APs
available, wonder if it would be possible to tune it to group updates
in batches.

Regards,

Tomeu

>> > Or, maybe, we could make this a manual process: pop up a notification
>> > when memory is short and ask which activity should be closed.
>>
>> I would just close one of the background activities, the LRU or the biggest 
>> one.
>
> +1.
>
> This, however, makes non-sugarized activities more dangerous to deal
> with. One more reason to demand proper sugarization.
>
> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Killing activities when memory gets short

[Bernie Innocenti]

El Sat, 07-08-2010 a las 18:14 +0200, Tomeu Vizoso escribió:

> So we would have a periodic wakeup? The test would be the amount of
> free memory plus buffers and caches?

A polled design is clearly inferior to a proper notification system, but
it has the advantage of being simple and not requiring a particular
kernel. Once this is done, switching to a better solution should not
require extensive changes to the UI code.

BTW, looking at top, it seems that Sugar and other processes wake up
quite frequently when the system is supposed to be completely idle. It
may be background checks for updates, NetworkManager updates or the
presence service. Plus, there are a bunch of cron jobs that run in the
background, inclding the ds-backup and olpc-update.

All these things drain battery power and cause the UI to become jerky,
so we should try to limit them if possible.


> > Or, maybe, we could make this a manual process: pop up a notification
> > when memory is short and ask which activity should be closed.
> 
> I would just close one of the background activities, the LRU or the biggest 
> one.

+1.

This, however, makes non-sugarized activities more dangerous to deal
with. One more reason to demand proper sugarization.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] The Git Community Book

[Frederick Grose]

On Sat, Aug 7, 2010 at 12:01 PM, Tomeu Vizoso  wrote:

> Just wanted to share a link to this book, check out the "gitcasts"!
>

http://www.gitcasts.com/


>
> http://book.git-scm.com/
>
> Regards,
>
> Tomeu
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] MicroSD Card performance variance on XO-1.5

[Tomeu Vizoso]

On Sat, Aug 7, 2010 at 18:11, Bernie Innocenti  wrote:
> [cc += sugar-devel, tch]
>
> El Sat, 07-08-2010 a las 11:27 +0200, Tomeu Vizoso escribió:
>
>> Btw, have read that some notifications about available memory have
>> landed in cgroups in recent kernels. The Sugar shell could listen to
>> those and give a chance to background activities to save their state
>> before killing them, thus avoiding OOM in some (most?) cases.
>
> We could do this even without an advanced reporting mechanism. The
> monitoring code in the CPU & Memory meter could detect memory shortage
> and automatically quit  the least recently used activity.

So we would have a periodic wakeup? The test would be the amount of
free memory plus buffers and caches?

> Or, maybe, we could make this a manual process: pop up a notification
> when memory is short and ask which activity should be closed.

I would just close one of the background activities, the LRU or the biggest one.

Regards,

Tomeu

> A while ago, Tincho has been working on implementing the Freedesktop
> notification protocol in Sugar. This feature didn't make it for
> Dextrose, but perhaps it could be completed in time to be merged into
> 0.90.
>
> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] MicroSD Card performance variance on XO-1.5

[Bernie Innocenti]

[cc += sugar-devel, tch]

El Sat, 07-08-2010 a las 11:27 +0200, Tomeu Vizoso escribió:

> Btw, have read that some notifications about available memory have
> landed in cgroups in recent kernels. The Sugar shell could listen to
> those and give a chance to background activities to save their state
> before killing them, thus avoiding OOM in some (most?) cases.

We could do this even without an advanced reporting mechanism. The
monitoring code in the CPU & Memory meter could detect memory shortage
and automatically quit  the least recently used activity.

Or, maybe, we could make this a manual process: pop up a notification
when memory is short and ask which activity should be closed.

A while ago, Tincho has been working on implementing the Freedesktop
notification protocol in Sugar. This feature didn't make it for
Dextrose, but perhaps it could be completed in time to be merged into
0.90.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] The Git Community Book

[Tomeu Vizoso]

Just wanted to share a link to this book, check out the "gitcasts"!

http://book.git-scm.com/

Regards,

Tomeu
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [REVIEW] adding spiral to Home View

[Gonzalo Odiard]

>
>
> P.S. Random Paint related question. Are you still in the process of tidying
> up the toolbar and paint tools? I'm thinking of spending some time there
> with the main intention of designing and implementing support for the new
> Sugar toolbars. I didn't want to duplicate our effort if you're already
> working in that direction.
>
> I'm not working on this. Is very good if you can do it.

-- 

Gonzalo
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [ASLO] Release Dr. Geo-1008

[Sugar Labs Activities]

Activity Homepage:
http://activities.sugarlabs.org/addon/4323

Sugar Platform:
0.82 - 0.88

Download Now:
http://activities.sugarlabs.org/downloads/file/27005/drgeoii-1008.xo

Release notes:
Important note: On your XO laptop, when you want to quit DrGeo, click in the 
activity background (reduce Dr. Geo's windows if necessary), in the menu choose 
Quit then in the question dialog to save the image, choose No. However, in 
recent Sugar version (0.88) you can save the state of Dr. Geo when choosing Yes


Sugar Labs Activities
http://activities.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [REVIEW] adding spiral to Home View

[Gary Martin]

Hi Gonzaalo,

On 7 Aug 2010, at 02:09, Gonzalo Odiard  wrote:

> 
> - Downloaded a load more activities to try and trigger the spiral, and 
> notices another three svg icons that don't render correctly in the latest F13 
> builds. Scratch, Paint, and Kandid. I'll fix them up and email the activity 
> authors.
> 
> The Paint icon has been corrected. In the next version will be ok (you can  
> check from git if you want)

Fab :)

--Gary

P.S. Random Paint related question. Are you still in the process of tidying up 
the toolbar and paint tools? I'm thinking of spending some time there with the 
main intention of designing and implementing support for the new Sugar 
toolbars. I didn't want to duplicate our effort if you're already working in 
that direction.

> Gonzalo
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel