Re: [Sugar-devel] Killing activities when memory gets short
2010/8/11 NoiseEHC noise...@freemail.hu: We used to do that, the problem is that we don't control our platform as Google controls Android and you need to make sure that resources that need to be specific of each child process aren't shared (dbus and X connections, etc). I'm personally more interested in reducing the amount of resources we need to start activities (which is quite insane right now), but sharing more of those resources sounds like a good idea to me. Since I spent quite a bit of time analyzing the Python runtime here is my conclusion, maybe it will make wasting all that time less painful. First, most of the memory consumed by an activity is the process heap. While the Python runtime and native libraries are shared among processes, the heap is not. Even if you fork processes it will not work because reference counting will dirty the shared pages This would hold true if a significant part of the stuff loaded during startup was actually ever referenced. This is not the case in Sugar, so you indeed can get quite some savings from the prefork trick. But of course, the right fix here is not sharing that memory, but not require it in the first place if we don't need it. One example is to stop compiling regular expressions eagerly, as mentioned in http://www.mail-archive.com/su...@lists.laptop.org/msg06957.html . There are several other situations that once fixed would give us wins in the order of hundreds of milliseconds with the corresponding wins in memory usage, such as importing modules that are never used. The move from PyGtk to introspection will mean we stop loading several dozens of classes that we never end up using, but there's lots to win in the Python std library as well. Regards, Tomeu and my instinct tells me that just loading a Python source file will reference almost all the shared pages because they are mostly used to store already loaded modules. What I finally did not do is to actually check the hypothesis that most of the heap is filled by strings which are the identifiers in the loaded Python modules. My goal was to somehow make identifiers constants and just readonly-mmap them into the process (replace the pathetic .pyc loading mechanism). Note that my plan was just a little subset of the .jar - .dex converter. Second, Python has a special memory manager which works with buckets so there are separate heaps for different object sizes. Somehow this special memory manager is turned off in release mode and it uses the standard C heap for some reason. Either it is a bug or just it turned out to be faster (more work was put into glibc) I do not know, but handling the linked free list can dirty shared pages as well or I am just mistaken... Third, the fact that Python is a dynamic language does not help any prefetching or memory sharing. I am not too convicted either that this dynamic nature is used at all in the Sugar codebase but you know I cannot program in Python and frankly I do not feel the need to learn another language. Just now, at my age of 34, I finally gave up and learned LISP (more specifically clojure) and I hope that it will be the last programming language I will have to learn (other than assembly languages of course)... :) Now this point is interesting because if you thought that the Dalvik VM could run the Sugar codebase via Jython then it just will not work. The Dalvik VM just cannot load .jar files and Jython just generates them on the fly because of the dynamic nature of Python. Fourth, moving Python (theoretically) to a GC environment (instead of reference counting) also would not work if the GC is compacting because it would also dirty the shared pages. So a mark and sweep nonmoving GC with separately stored visited bits is the only feasible solution. Now guess what the Dalvik VM does? For more info (45 min + questions): http://www.youtube.com/watch?v=ptjedOZEXPM So *my* conclusion is that solving this sharing problem is *very* hard. I am not sure that simply translating all activities from Python to Java would take more time. Another interesting thing is that meantime the unladen-swallow project progresses (just more slowly than planned). Their plan is to make it the default Python runtime so if it will happen (I cannot comment on that) then the Python VM will use even more memory (though it will be faster) so Sugar will be even less interesting on the myriad of low spec cheap ARM tablets which will flood the market soon. I think that is all I can say about this subject so I just finish it here. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] mapping activity with OpenStreetMaps
Hi, one more excellent thing coming from NZ: http://nzjrs.github.com/osm-gps-map/ Anybody up for doing an activity that uses it? Should be a matter of placing the widget inside the canvas and connecting some buttons to call some methods on it. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse-115 stops when pop-up tab closes
On Wed, Aug 11, 2010 at 06:39, James Cameron qu...@laptop.org wrote: On Wed, Aug 11, 2010 at 12:24:43AM +, Christoph Derndorfer wrote: cairo-1.8.8-1.fc11.i586 [...] Traceback (most recent call last): [...] File /usr/lib/python2.6/site-packages/sugar/activity/activity.py, line 600, in save preview = self.get_preview() File /usr/lib/python2.6/site-packages/sugar/activity/activity.py, line 548, in get_preview width, height = pixmap.get_size() AttributeError: 'NoneType' object has no attribute 'get_size' If this is the error that is killing Browse-115, it appears to be a problem with get_preview in Sugar. What version of Sugar is it? Current HEAD presumes the pixmap returned by get_snapshot will have a method get_size. If it does not, an exception will result. Those exceptions shouldn't terminate the process because PyGtk's main loop handles them. Unhandled exceptions will only stop a process during startup, before the main loop starts running. Regards, Tomeu -- James Cameron http://quozl.linux.org.au/ ___ 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] [PATCH] Remove bitmap icon handling from s-p-s
On Wed, Aug 11, 2010 at 00:38, Bernie Innocenti ber...@codewiz.org wrote:
This patch gets rid of some almost-dead code in sugar-presence-service
for handling bitmap avatars.
The idea is that the PS is going to disappear soon. Do we really want
to make such cleanups given that?
Regards,
Tomeu
Signed-off-by: Bernie Innocenti ber...@codewiz.org
---
src/buddy.py | 63 +
1 files changed, 2 insertions(+), 61 deletions(-)
diff --git a/src/buddy.py b/src/buddy.py
index d81952e..4335f2d 100644
--- a/src/buddy.py
+++ b/src/buddy.py
@@ -69,37 +69,6 @@ def _buddy_icon_save_cb(buf, data):
data[0] += buf
return True
-def _get_buddy_icon_at_size(icon, maxw, maxh, maxsize):
-# FIXME Do not import gtk in the presence service,
-# it uses a lot of memory and slow down startup.
-# loader = gtk.gdk.PixbufLoader()
-# loader.write(icon)
-# loader.close()
-# unscaled_pixbuf = loader.get_pixbuf()
-# del loader
-#
-# pixbuf = unscaled_pixbuf.scale_simple(maxw, maxh,
gtk.gdk.INTERP_BILINEAR)
-# del unscaled_pixbuf
-#
-# data = []
-# quality = 90
-# img_size = maxsize + 1
-# while img_size maxsize:
-# data = []
-# pixbuf.save_to_callback(_buddy_icon_save_cb, jpeg,
-# {quality:%d % quality}, data)
-# quality -= 10
-# img_size = len(data[0])
-# del pixbuf
-#
-# if img_size maxsize:
-# data = []
-# raise RuntimeError(could not size image less than %d bytes %
maxsize)
-#
-# return str(data[0])
-
- return
-
class Buddy(ExportedGObject):
Person on the network (tracks properties and shared activites)
@@ -212,20 +181,9 @@ class Buddy(ExportedGObject):
_logger.debug(Invalid init property '%s'; ignoring... % key)
del kwargs[key]
- # Set icon after superclass init, because it sends DBus and GObject
- # signals when set
- icon_data = None
- if kwargs.has_key(_PROP_ICON):
- icon_data = kwargs[_PROP_ICON]
- del kwargs[_PROP_ICON]
-
ExportedGObject.__init__(self, bus, self._object_path,
gobject_properties=kwargs)
- if icon_data is not None:
- self._icon = str(icon_data)
- self.IconChanged(self._icon)
-
def __repr__(self):
return 'ps.buddy.Buddy %s' % (self._nick or u'').encode('utf-8')
@@ -893,17 +851,6 @@ class GenericOwner(Buddy):
if maxsize 0 and size maxsize:
size = maxsize
- if 1:
- # FIXME: Avatars have been disabled for Trial-2 due to
performance
- # issues in the avatar cache. Revisit this afterwards
- pass
- else:
- img_data = _get_buddy_icon_at_size(icon_data, width, height,
size)
- conn[CONN_INTERFACE_AVATARS].SetAvatar(img_data, image/jpeg,
- reply_handler=set_self_avatar_cb,
- error_handler=lambda e:
- _logger.warning('Error setting avatar: %s', e))
-
def _property_changed(self, changed_props):
for tp in self._handles.iterkeys():
@@ -963,8 +910,7 @@ class ShellOwner(GenericOwner):
bus -- a connection to the D-Bus session bus
Retrieves initial property values from the profile
- module. Loads the buddy icon from file as well.
- XXX note: no error handling on that
+ module.
calls GenericOwner.__init__
@@ -981,14 +927,9 @@ class ShellOwner(GenericOwner):
if not isinstance(nick, unicode):
nick = unicode(nick, 'utf-8')
- icon_file = os.path.join(env.get_profile_path(), buddy-icon.jpg)
- f = open(icon_file, r)
- icon = f.read()
- f.close()
-
GenericOwner.__init__(self, ps, bus,
'keyid/' + psutils.pubkey_to_keyid(key),
- key=key, nick=nick, color=color, icon=icon,
key_hash=key_hash,
+ key=key, nick=nick, color=color, key_hash=key_hash,
tags=tags)
# Ask to get notifications on Owner object property changes in the
--
1.7.2.1
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse-115 stops when pop-up tab closes
This exception doesn't seem related to the cairo bug. I'll try to reproduce it on my XO. Please file a bug report if you haven't already. Cairo version: cairo-1.8.8-1.fc11.i586 Traceback (most recent call last): File /usr/lib/python2.6/site-packages/gtk-2.0/gobject/__init__.py, line 108, in obj_set_property prop.setter(self, value) File /usr/lib/python2.6/site-packages/sugar/activity/activity.py, line 365, in set_active self.save() File /usr/lib/python2.6/site-packages/sugar/activity/activity.py, line 600, in save preview = self.get_preview() File /usr/lib/python2.6/site-packages/sugar/activity/activity.py, line 548, in get_preview width, height = pixmap.get_size() AttributeError: 'NoneType' object has no attribute 'get_size' ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] code submitted for review should have been tested
Hi, any code contributor is expecting that their patches will be tested by the reviewer? If that is the case, we should make more clear in the review process that patches should have been tested _before_ they are submitted for acceptance. Because of this specific commit, file transfers have been broken since early this year and it's obvious that this code wasn't tested at all: http://git.sugarlabs.org/projects/sugar/repos/mainline/commits/11828796 Given the current poor state of our testing efforts, committers should be extra careful about this. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Remove bitmap icon handling from s-p-s
On Wed, Aug 11, 2010 at 5:02 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote:
On Wed, Aug 11, 2010 at 00:38, Bernie Innocenti ber...@codewiz.org wrote:
This patch gets rid of some almost-dead code in sugar-presence-service
for handling bitmap avatars.
The idea is that the PS is going to disappear soon. Do we really want
to make such cleanups given that?
There is a good chance that sugar .84 and sugar .88 code will be
around for awhile due to olpc and paraguayeduca basing releases on
them.
The question then becomes -- who should make and maintain those cleanups?
david
Regards,
Tomeu
Signed-off-by: Bernie Innocenti ber...@codewiz.org
---
src/buddy.py | 63
+
1 files changed, 2 insertions(+), 61 deletions(-)
diff --git a/src/buddy.py b/src/buddy.py
index d81952e..4335f2d 100644
--- a/src/buddy.py
+++ b/src/buddy.py
@@ -69,37 +69,6 @@ def _buddy_icon_save_cb(buf, data):
data[0] += buf
return True
-def _get_buddy_icon_at_size(icon, maxw, maxh, maxsize):
-# FIXME Do not import gtk in the presence service,
-# it uses a lot of memory and slow down startup.
-# loader = gtk.gdk.PixbufLoader()
-# loader.write(icon)
-# loader.close()
-# unscaled_pixbuf = loader.get_pixbuf()
-# del loader
-#
-# pixbuf = unscaled_pixbuf.scale_simple(maxw, maxh,
gtk.gdk.INTERP_BILINEAR)
-# del unscaled_pixbuf
-#
-# data = []
-# quality = 90
-# img_size = maxsize + 1
-# while img_size maxsize:
-# data = []
-# pixbuf.save_to_callback(_buddy_icon_save_cb, jpeg,
-# {quality:%d % quality}, data)
-# quality -= 10
-# img_size = len(data[0])
-# del pixbuf
-#
-# if img_size maxsize:
-# data = []
-# raise RuntimeError(could not size image less than %d bytes %
maxsize)
-#
-# return str(data[0])
-
- return
-
class Buddy(ExportedGObject):
Person on the network (tracks properties and shared activites)
@@ -212,20 +181,9 @@ class Buddy(ExportedGObject):
_logger.debug(Invalid init property '%s'; ignoring... %
key)
del kwargs[key]
- # Set icon after superclass init, because it sends DBus and GObject
- # signals when set
- icon_data = None
- if kwargs.has_key(_PROP_ICON):
- icon_data = kwargs[_PROP_ICON]
- del kwargs[_PROP_ICON]
-
ExportedGObject.__init__(self, bus, self._object_path,
gobject_properties=kwargs)
- if icon_data is not None:
- self._icon = str(icon_data)
- self.IconChanged(self._icon)
-
def __repr__(self):
return 'ps.buddy.Buddy %s' % (self._nick or u'').encode('utf-8')
@@ -893,17 +851,6 @@ class GenericOwner(Buddy):
if maxsize 0 and size maxsize:
size = maxsize
- if 1:
- # FIXME: Avatars have been disabled for Trial-2 due to
performance
- # issues in the avatar cache. Revisit this afterwards
- pass
- else:
- img_data = _get_buddy_icon_at_size(icon_data, width, height,
size)
- conn[CONN_INTERFACE_AVATARS].SetAvatar(img_data, image/jpeg,
- reply_handler=set_self_avatar_cb,
- error_handler=lambda e:
- _logger.warning('Error setting avatar: %s', e))
-
def _property_changed(self, changed_props):
for tp in self._handles.iterkeys():
@@ -963,8 +910,7 @@ class ShellOwner(GenericOwner):
bus -- a connection to the D-Bus session bus
Retrieves initial property values from the profile
- module. Loads the buddy icon from file as well.
- XXX note: no error handling on that
+ module.
calls GenericOwner.__init__
@@ -981,14 +927,9 @@ class ShellOwner(GenericOwner):
if not isinstance(nick, unicode):
nick = unicode(nick, 'utf-8')
- icon_file = os.path.join(env.get_profile_path(), buddy-icon.jpg)
- f = open(icon_file, r)
- icon = f.read()
- f.close()
-
GenericOwner.__init__(self, ps, bus,
'keyid/' + psutils.pubkey_to_keyid(key),
- key=key, nick=nick, color=color, icon=icon,
key_hash=key_hash,
+ key=key, nick=nick, color=color, key_hash=key_hash,
tags=tags)
# Ask to get notifications on Owner object property changes in the
--
1.7.2.1
___
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] Sugarbot working on latest Sugar
Excerpts from Tim McNamara's message of Sun Aug 08 02:06:21 +0200 2010: Is there interest in pushing an updated sugarbot to git.sl.o? Sure, go ahead! If you need commit rights, please write to systems@ and I'll transfer the project to you. The original author, a GSoC student, has already stated having no interest to work on it any further. 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. Great! And thanks for working on this. Automated UI testing is our most pressing need right now (IMO at least). It enables faster, easier and better testing of code changes (including upstream changes). 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. I don't have time to answer more in-depth, but one thing I'd like to point out is that Gnome is using dogtail for UI testing which seems to be rather similar to SugarBot so we might want to use that instead. IIRC it even comes with some tools to make writing tests easier (a macro recorder thingie and a widget tree exploration GUI). As much as I'd hate to see a GSoC project being never put into real use, the advantage of having someone else maintain the code is rather important for now. But maybe we can reuse some code or ideas from SugarBot to make it easier to write test cases for activities? Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugarbot working on latest Sugar
On Wed, Aug 11, 2010 at 17:17, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: Excerpts from Tim McNamara's message of Sun Aug 08 02:06:21 +0200 2010: Is there interest in pushing an updated sugarbot to git.sl.o? Sure, go ahead! If you need commit rights, please write to systems@ and I'll transfer the project to you. The original author, a GSoC student, has already stated having no interest to work on it any further. 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. Great! And thanks for working on this. Automated UI testing is our most pressing need right now (IMO at least). It enables faster, easier and better testing of code changes (including upstream changes). 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. I don't have time to answer more in-depth, but one thing I'd like to point out is that Gnome is using dogtail for UI testing which seems to be rather similar to SugarBot so we might want to use that instead. IIRC it even comes with some tools to make writing tests easier (a macro recorder thingie and a widget tree exploration GUI). As much as I'd hate to see a GSoC project being never put into real use, the advantage of having someone else maintain the code is rather important for now. But maybe we can reuse some code or ideas from SugarBot to make it easier to write test cases for activities? The biggest difference between dogtail and sugarbot is how they discover the widgets. Dogtail uses AT-SPI and sugarbot uses the introspection features in Python. We anyway need to make Sugar work under AT-SPI because of accessibility so would be good to see movement in that area. Regards, Tomeu Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ ___ 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
[Sugar-devel] [FEATURE] Remove Presence Service
Hi, have just entered a new feature page for the removal of the Presence Service, which is being proposed as a feature for 0.90. In the page you have links to previous discussions and to the bigger plans. http://wiki.sugarlabs.org/go/Features/Remove_Presence_Service Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Remove bitmap icon handling from s-p-s
On Wed, Aug 11, 2010 at 13:28, David Farning dfarn...@gmail.com wrote:
On Wed, Aug 11, 2010 at 5:02 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote:
On Wed, Aug 11, 2010 at 00:38, Bernie Innocenti ber...@codewiz.org wrote:
This patch gets rid of some almost-dead code in sugar-presence-service
for handling bitmap avatars.
The idea is that the PS is going to disappear soon. Do we really want
to make such cleanups given that?
There is a good chance that sugar .84 and sugar .88 code will be
around for awhile due to olpc and paraguayeduca basing releases on
them.
Even then, I'm not sure cleanups make much sense in stable branches,
because what you want there is stability and a cleanup is not going to
give you that.
I don't particularly care if this goes in or not, just don't see the point.
The question then becomes -- who should make and maintain those cleanups?
I guess the branch maintainers?
Regards,
Tomeu
david
Regards,
Tomeu
Signed-off-by: Bernie Innocenti ber...@codewiz.org
---
src/buddy.py | 63
+
1 files changed, 2 insertions(+), 61 deletions(-)
diff --git a/src/buddy.py b/src/buddy.py
index d81952e..4335f2d 100644
--- a/src/buddy.py
+++ b/src/buddy.py
@@ -69,37 +69,6 @@ def _buddy_icon_save_cb(buf, data):
data[0] += buf
return True
-def _get_buddy_icon_at_size(icon, maxw, maxh, maxsize):
-# FIXME Do not import gtk in the presence service,
-# it uses a lot of memory and slow down startup.
-# loader = gtk.gdk.PixbufLoader()
-# loader.write(icon)
-# loader.close()
-# unscaled_pixbuf = loader.get_pixbuf()
-# del loader
-#
-# pixbuf = unscaled_pixbuf.scale_simple(maxw, maxh,
gtk.gdk.INTERP_BILINEAR)
-# del unscaled_pixbuf
-#
-# data = []
-# quality = 90
-# img_size = maxsize + 1
-# while img_size maxsize:
-# data = []
-# pixbuf.save_to_callback(_buddy_icon_save_cb, jpeg,
-# {quality:%d % quality}, data)
-# quality -= 10
-# img_size = len(data[0])
-# del pixbuf
-#
-# if img_size maxsize:
-# data = []
-# raise RuntimeError(could not size image less than %d bytes %
maxsize)
-#
-# return str(data[0])
-
- return
-
class Buddy(ExportedGObject):
Person on the network (tracks properties and shared activites)
@@ -212,20 +181,9 @@ class Buddy(ExportedGObject):
_logger.debug(Invalid init property '%s'; ignoring... %
key)
del kwargs[key]
- # Set icon after superclass init, because it sends DBus and GObject
- # signals when set
- icon_data = None
- if kwargs.has_key(_PROP_ICON):
- icon_data = kwargs[_PROP_ICON]
- del kwargs[_PROP_ICON]
-
ExportedGObject.__init__(self, bus, self._object_path,
gobject_properties=kwargs)
- if icon_data is not None:
- self._icon = str(icon_data)
- self.IconChanged(self._icon)
-
def __repr__(self):
return 'ps.buddy.Buddy %s' % (self._nick or u'').encode('utf-8')
@@ -893,17 +851,6 @@ class GenericOwner(Buddy):
if maxsize 0 and size maxsize:
size = maxsize
- if 1:
- # FIXME: Avatars have been disabled for Trial-2 due to
performance
- # issues in the avatar cache. Revisit this afterwards
- pass
- else:
- img_data = _get_buddy_icon_at_size(icon_data, width, height,
size)
- conn[CONN_INTERFACE_AVATARS].SetAvatar(img_data, image/jpeg,
- reply_handler=set_self_avatar_cb,
- error_handler=lambda e:
- _logger.warning('Error setting avatar: %s', e))
-
def _property_changed(self, changed_props):
for tp in self._handles.iterkeys():
@@ -963,8 +910,7 @@ class ShellOwner(GenericOwner):
bus -- a connection to the D-Bus session bus
Retrieves initial property values from the profile
- module. Loads the buddy icon from file as well.
- XXX note: no error handling on that
+ module.
calls GenericOwner.__init__
@@ -981,14 +927,9 @@ class ShellOwner(GenericOwner):
if not isinstance(nick, unicode):
nick = unicode(nick, 'utf-8')
- icon_file = os.path.join(env.get_profile_path(), buddy-icon.jpg)
- f = open(icon_file, r)
- icon = f.read()
- f.close()
-
GenericOwner.__init__(self, ps, bus,
'keyid/' + psutils.pubkey_to_keyid(key),
- key=key, nick=nick, color=color, icon=icon,
key_hash=key_hash,
+ key=key, nick=nick, color=color, key_hash=key_hash,
tags=tags)
# Ask to get notifications on Owner object property changes in the
--
1.7.2.1
Re: [Sugar-devel] Killing activities when memory gets short
Hi James, On 11 Aug 2010, at 04:05, James Cameron wrote: On Tue, Aug 10, 2010 at 05:48:00PM -0700, John Gilmore wrote: ... and was also unsuccessful in convincing OLPC to prelink the shared libraries before shipping a release, thus allowing read-only pages to not get dirtied with shared library linkage relocations. 10.1.2 release candidate os851 has prelink before shipping, it's done in the builder. Out of curiosity, just been testing two XO-1s side by side one os850 and one os851. Rough observations (repeated about 12 times): - resuming/starting a sequence of activities after another reliably gets to 9 simultaneous activities (Terminal, Calculate, Log, Pippy, Implode, Chat, Moon, Paint, Memorize) - the tenth activity I happened to be testing, Turtle Blocks, usually triggered an OOM hang of some kind - the OOM hang was usually Turtle Blocks failing to launch. Failed launch would consist of the pulsing startup window, then hanging at a mainly dark grey screen with some partial toolbar light grey fill, non-responsive UI for ~30 seconds to a number of minutes (possibly 5 or 10min), finally you'd be dropped back at the last activity you had successfully launched (Memorize in my test cases). - on three occasions os851 successfully started Turtle Blocks - on one occasion os850 successfully started Turtle Blocks, however on one occasion resuming Turtle Blocks os850 managed to trigger an OOM kill of the Sugar shell resulting in all resumed activities dying and being dropped back at the home fav ring view. - as Turtle Blocks seems a little more memory intensive than some other activities, I tried a few others as the tenth and onward test case. Write as no. ten usually was fine and Distance as eleven. Then trying Maze, or Speak as no. twelve would trigger OOM and the activity would be killed (after some delay, as noted above). - on one occasion trying to start Maze in os850 as activity no. twelve, managed to trigger an OOM kill of the Sugar shell. So, not significant results over just 12 cycles for each XO-1 (need finer grained testing rather than 'number of activities'). Both exhibited long UI lockup's when launching an activity while resources were already maxed out, usually resulting with the activity in question being killed; but os850 did trigger OOM to kill the Sugar shell twice, bringing down all activities with it, where as os851 didn't. --Gary P.S. of corse you'll now tell me os850 was also pre-linked (I couldn't see anything about it in the build notes for either os850 or os851), and I'll look silly for trying to test for a difference, confirming my results were non significant ;-) -- James Cameron http://quozl.linux.org.au/ ___ 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] Killing activities when memory gets short
gary wrote: P.S. of corse you'll now tell me os850 was also pre-linked (I couldn't see anything about it in the build notes for either os850 or os851), and I'll look silly for trying to test for a difference, confirming my results were non significant ;-) that's exactly right. :-) pre-linking has been in the builds for some time, i believe. paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] mapping activity with OpenStreetMaps
On Wed, Aug 11, 2010 at 4:51 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: Hi, one more excellent thing coming from NZ: http://nzjrs.github.com/osm-gps-map/ Anybody up for doing an activity that uses it? Should be a matter of placing the widget inside the canvas and connecting some buttons to call some methods on it. Erik and Bahktiar had written a nice mapping activity for Sugar a few years back. It would be worthwhile dusting off. (See http://wiki.laptop.org/go/Map_%28activity%29) -walter -walter Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.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
On 11 Aug 2010, at 18:42, Paul Fox p...@laptop.org wrote: gary wrote: P.S. of corse you'll now tell me os850 was also pre-linked (I couldn't see anything about it in the build notes for either os850 or os851), and I'll look silly for trying to test for a difference, confirming my results were non significant ;-) that's exactly right. :-) pre-linking has been in the builds for some time, i believe. Lol! :-) At least it's nice to know that the usual OOM behaviour is that the just launched activity is the one that gets it in the neck, most of the time. Pity about the lockup that usually happens before the kill, is it possible to make the OOM happen at a higher free mem threshold? --Gary paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] mapping activity with OpenStreetMaps
Far more up-to-date is: CMU volunteer Nick Doiron's very latest Map Activity here -- with 5 offline MapPacks to date for Rwanda, Ghana, Uganda, Peru, Haiti -- priceless in developing countries with weak Internet: http://wiki.laptop.org/go/User:Ndoiron/OfflineMap Walter Bender wrote: On Wed, Aug 11, 2010 at 4:51 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: Hi, one more excellent thing coming from NZ: http://nzjrs.github.com/osm-gps-map/ Anybody up for doing an activity that uses it? Should be a matter of placing the widget inside the canvas and connecting some buttons to call some methods on it. Erik and Bahktiar had written a nice mapping activity for Sugar a few years back. It would be worthwhile dusting off. (See http://wiki.laptop.org/go/Map_%28activity%29) -walter -walter Regards, Tomeu ___ 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
[Sugar-devel] Unit integration testing - tools discussion
I would like to start a thread on unit integration testing. I have two main questions: 1) Where should tests be located 2) Which testing framework to use Some options for 1: - every Sugar project decides for itself - root/tests in each project - a meta project that houses tests for several/all Sugar projects Some options for 2: - unittest - nose - py.test My preferences: 1: root/tests for each project 2: py.test - primarily because it supports distributed testing, that will make support for alternate Python versions much easier (if we have test sufficient coverage) Regards, Tim. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugarbot working on latest Sugar
On 12 August 2010 03:17, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.orgwrote: Excerpts from Tim McNamara's message of Sun Aug 08 02:06:21 +0200 2010: Is there interest in pushing an updated sugarbot to git.sl.o? Sure, go ahead! If you need commit rights, please write to systems@ and I'll transfer the project to you. The original author, a GSoC student, has already stated having no interest to work on it any further. Sugarbot repo is currently reserved for the IRC bot. I'll think of a new name for the Sugarbot testing project start a new project from the GSoC SVN. Affination is one of the processes in raw sugar processing. What about that? 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. Great! And thanks for working on this. Automated UI testing is our most pressing need right now (IMO at least). It enables faster, easier and better testing of code changes (including upstream changes). [snip] I don't have time to answer more in-depth, but one thing I'd like to point out is that Gnome is using dogtail for UI testing which seems to be rather similar to SugarBot so we might want to use that instead. I would like to use Sugarbot during a transition phase. Two reasons: 1) Things should work with it now. To support Dogtail (or LDTP), Sugar's components will need to support AT-STI. I don't know how hard that will be. 2) Test scripts written for Sugarbot are be almost identical to scripts written for Dogtail. Therefore, testers' time taken to build scripts for Sugarbot will not be wasted. I'm not sure how Dogtail works under the hood. The project was initially dismissed by the Sugarbot author as being too hard to look into during GSoC.[1] [1] http://gsoc-sugarbot.blogspot.com/2008/05/dissecting-guitest.html ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Speak-17
Activity Homepage: http://activities.sugarlabs.org/addon/4038 Sugar Platform: 0.82 - 0.88 Download Now: http://activities.sugarlabs.org/downloads/file/27008/speak-17.xo Release notes: * Get rid of smart bundles.. and look ahead for smart packaging system 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] Fwd: Speak.Activity v16 on Build 802 - Problem
On Mon, Aug 09, 2010 at 10:19:23AM -0500, Rafael Enrique Ortiz Guerrero wrote: Forwarding this to sugar-devel -- Forwarded message -- From: Tony Rizos tri...@pacbell.net Date: Sun, Aug 8, 2010 at 9:44 PM Subject: Speak.Activity v16 on Build 802 - Problem To: de...@lists.laptop.org Hi, I upgraded my OLPC XO from Build 656 to 802. Having not used the XO for the last 2 years, I was pleased with the changes. I am planning to give it to my niece who asked if she could have it. All works well except the Speak activity. After running correctly the first time, it will not start up on subsequent attempts. I thought this may have been caused by my attempt to install Skype when the problem seemed to have started. I erased Speak and reinstalled it with no luck. I first tried going back to 656 and upgrading again to 802. No luck. I should say I also tried Speak v9 which worked with no problems whatsoever. The problem is associated with the Speak v16 activity that comes with 802. I asked the forums if anyone had seen this problem and was recommended to do a no-fail update. After wiping the XO clean and installing 802, Speak v16 seemed to work again with no problems. However, when I closed it and restarted it, I got an error and would not start. I then erased it and reinstalled it. It started up okay with no problems but I get the same result when I close it and restart it. The error detail included the following messages: gst-plugins-based failed to resolve due to Unknown gstreamer failed to resolve due to Unknown gst-plugins-good failed to resolve due to Unknown Processed: 1; skipped: 0 Cancelled Is there a problem with Speak v16? Have you seen this problem before? Is there any more information I can provide? Can this be fixed? Heh, these are remains of my expriments with smart bundles, Try this one http://activities.sugarlabs.org/en-US/sugar/addon/4038. Thanx, Tony ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] code submitted for review should have been tested
On Wed, Aug 11, 2010 at 12:22:00PM +0200, Tomeu Vizoso wrote: any code contributor is expecting that their patches will be tested by the reviewer? I don't think a reviewer should be expected to test patches as part of a review process, but if they choose to test then they should indicate this in their review comments. In the sign-off method of patch review, there's a tag Tested-by which is different to Reviewed-by. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Remove bitmap icon handling from s-p-s
On Wed, Aug 11, 2010 at 11:02:26AM +0200, Tomeu Vizoso wrote: The idea is that the PS is going to disappear soon. Do we really want to make such cleanups given that? I don't think unimplemented future plans are an acceptable justification for refusal of a patch. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Unit integration testing - tools discussion
On 12 August 2010 13:30, James Cameron qu...@laptop.org wrote: 2) Which testing framework to use Whatever the test developer and activity developer can agree on. I don't know enough about the options to choose. (p.s. I'm aware of your work on Sugarbot. While this is fantastic, I'm worried that a test that depends on Sugarbot might end up not being used because Sugarbot is unavailable on the platform, or a later version is needed.) Oh, I was mainly talking about unit testing. Something like Sugarbot / dogtail is more suited to larger-scale testing. I see the choice here between derivatives of Kent Beck's SUnit and some of the newer testing frameworks. In Python, this would be the unittest* module. The other two options I listed were nose [1] py.test[2] tests. There are other possibilities, such as zope.testing. In my opinion, nose py.test make writing tests much simpler. I personally prefer py.test because of some of its additional capabilities, such as being able to send tests to other cores/machines via ssh with a command line switch. I think nose has a greater popularity primarily because it has a better website with friendlier documentation. Tim * From Py 2.7, that is depreciated in favour of unittest2. [1] http://somethingaboutorange.com/mrl/projects/nose/0.11.2/ [2] http://codespeak.net/py/dist/test/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
