Re: [Sugar-devel] Browse-115 stops when pop-up tab closes
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. -- 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] Killing activities when memory gets short
On 11 Aug 2010, at 01:56, Lucian Branescu wrote: > 2010/8/10 NoiseEHC : >> >>> 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 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. > > The PyPy project has a fully-featured python 2.5 interpreter that has > much lower memory usage and a proper GC (so less dirty pages). They > also have an x86 JIT which makes it much faster than CPython, at the > cost of a bit of memory (still less than CPython). The only issue > right now is extension support: ctypes is fully supported, but > C/Python extension support is not complete by far. FWIW I experimented with PyPy a month or so back to see how fast my self organising map code would run. Needed to make a some code/module changes to get it to work, but it ran about twice as fast. I didn't check if memory usage had improved. --Gary > As for Jython on Android, Jython has a Java bytecode JIT. It should be > entirely possible to write a dalvik backend to this JIT. > > So not only would rewriting everything to Java be a huge step > backwards, but it would also be more work. > ___ > 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 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. -- 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] Killing activities when memory gets short
2010/8/10 NoiseEHC : > >> 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 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. The PyPy project has a fully-featured python 2.5 interpreter that has much lower memory usage and a proper GC (so less dirty pages). They also have an x86 JIT which makes it much faster than CPython, at the cost of a bit of memory (still less than CPython). The only issue right now is extension support: ctypes is fully supported, but C/Python extension support is not complete by far. As for Jython on Android, Jython has a Java bytecode JIT. It should be entirely possible to write a dalvik backend to this JIT. So not only would rewriting everything to Java be a huge step backwards, but it would also be more work. ___ 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 Tue, Aug 10, 2010 at 8:37 PM, Lucian Branescu wrote: > Yes, it is a bug. > > It has been observed that under certain versions of cairo, Browse with tabs > crashes. V115 checks for this and disables tabs if such a version is > detected. It's possible that other versions of cairo are problematic, too. > > Please attach Browse's log and report your cairo version, I'll check it out > tomorrow. > See below. Thanks, Christoph --- Cairo version: cairo-1.8.8-1.fc11.i586 Browse log: /home/olpc/Activities/Browse.activity/webactivity.py:26: DeprecationWarning: the sha module is deprecated; use the hashlib module instead import sha returning /home/olpc/.sugar/default/org.laptop.WebActivity/data/gecko/prefs.js for key NS_APP_PREFS_50_FILE 1281485529.468977 WARNING root: .has_key() is deprecated, use 'in' 1281485530.215058 WARNING root: No gtk.AccelGroup in the top level window. 1281485530.254288 WARNING root: No gtk.AccelGroup in the top level window. 1281485530.462426 WARNING root: No gtk.AccelGroup in the top level window. 1281485530.506957 WARNING root: No gtk.AccelGroup in the top level window. 1281485530.566313 WARNING root: No gtk.AccelGroup in the top level window. 1281485530.592393 WARNING root: No gtk.AccelGroup in the top level window. /usr/lib/xulrunner-1.9.1/python/xpcom/__init__.py:54: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6 self.message = message ** (sugar-activity:3013): DEBUG: Got client ID "1097f2008c4ca8dc512814855338048470018290001" ** (sugar-activity:3013): DEBUG: Setting initial properties ** (sugar-activity:3013): DEBUG: Received SaveYourself(SmSaveLocal, !Shutdown, SmInteractStyleNone, !Fast) in state idle ** (sugar-activity:3013): DEBUG: Sending SaveYourselfDone(True) for initial SaveYourself ** (sugar-activity:3013): DEBUG: Received SaveComplete message in state save-yourself-done /home/olpc/Activities/Browse.activity/webtoolbar.py:69: GtkWarning: gtk_entry_set_text: assertion `text != NULL' failed self.props.text = text 1281485792.947926 WARNING root: No gtk.AccelGroup in the top level window. 1281485793.015581 WARNING root: No gtk.AccelGroup in the top level window. 1281485793.018288 WARNING root: No gtk.AccelGroup in the top level window. 1281485793.172707 WARNING root: No gtk.AccelGroup in the top level window. 1281485793.175616 WARNING root: No gtk.AccelGroup in the top level window. 1281485793.178127 WARNING root: No gtk.AccelGroup in the top level window. /usr/lib/python2.6/site-packages/hulahop/webview.py:56: Warning: invalid uninstantiatable type `(null)' in cast to `GtkWidget' self.web_view.get_toplevel().destroy() /usr/lib/python2.6/site-packages/hulahop/webview.py:56: GtkWarning: gtk_widget_hide: assertion `GTK_IS_WIDGET (widget)' failed self.web_view.get_toplevel().destroy() /usr/lib/python2.6/site-packages/hulahop/webview.py:56: GtkWarning: gtk_widget_destroy: assertion `GTK_IS_WIDGET (widget)' failed self.web_view.get_toplevel().destroy() /usr/lib/python2.6/site-packages/hulahop/webview.py:56: GtkWarning: gdk_x11_visual_get_xvisual: assertion `visual != NULL' failed self.web_view.get_toplevel().destroy() Traceback (most recent call last): File "/home/olpc/Activities/Browse.activity/webtoolbar.py", line 438, in _reload_session_history for menu_item in palette.menu.get_children(): AttributeError: 'NoneType' object has no attribute 'menu' 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' -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Remove bitmap icon handling from s-p-s
This patch gets rid of some almost-dead code in sugar-presence-service
for handling bitmap avatars.
Signed-off-by: Bernie Innocenti
---
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 '' % (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] [PATCH] Remove buddy-icon.jpg handling
All this code from 2006 was supposed to create a bitmap version of the
buddy icon for use by the presence service. However, JPEG avatars were
disabled very early in Sugar's history due to performance
considerations, rendering all this code useless a long time ago.
I noticed this cleanup opportunity just because a laptop was no longer
booting due to a corrupted buddy-icon.jpg. (How did it get corrupt since
it's read-only after the first boot? This is still a mystery of JFFS2
and flash ECC).
This patch depends on a corresponding cleanup in sugar-presence-service.
Signed-off-by: Bernie Innocenti
---
src/jarabe/intro/Makefile.am |4
src/jarabe/intro/default-picture.png | Bin 10442 -> 0 bytes
src/jarabe/intro/window.py |9 +
src/jarabe/model/owner.py| 19 +--
4 files changed, 2 insertions(+), 30 deletions(-)
delete mode 100644 src/jarabe/intro/default-picture.png
diff --git a/src/jarabe/intro/Makefile.am b/src/jarabe/intro/Makefile.am
index a9fb96b..2ea7cea 100644
--- a/src/jarabe/intro/Makefile.am
+++ b/src/jarabe/intro/Makefile.am
@@ -1,7 +1,3 @@
-imagedir = $(pythondir)/jarabe/intro
-image_DATA = default-picture.png
-
-EXTRA_DIST = $(conf_DATA) $(image_DATA)
sugardir = $(pythondir)/jarabe/intro
sugar_PYTHON = \
__init__.py \
diff --git a/src/jarabe/intro/default-picture.png
b/src/jarabe/intro/default-picture.png
deleted file mode 100644
index
e26b9b0114e992c22509da03a4e9d0e0847928e4..
GIT binary patch
literal 0
HcmV?d1
literal 10442
zcmbt)cRbbM`+nmnqo_m~QDo)vt...@hj%ap_tjg*6tyubj!i_i<4|TuRdxy6z...@#ueix(HYW5>>_swmt&c...@~|_(qbR
zfWJH>xW>T`GG`S7H~4&r_M>OXx%*xt
zzsdanqeyg...@12mc;ymY6UYiWQsT3ojw+uVSVS0LPM>rL$2vn{rVe}j4v<`uM8ZP
zKQxphRr>UlTuVpp^V5N_d__3~Vr}o)O4Ftx&5AVR_3JBhCjJB6Y%SxfKVJWIea8}~
z#&zsT{F7&z$BvQG9y^91`R|V>rpJlD5r16O|L+gthw$5fulb)l{tuV_-|zU}AD-6O
z#d45yu}o...@l6@cfH%3mYiI}c=cnGS|8m94<4Y=Bky&&H8nLI931Z5yQi+MPC*gQ
zbjwFyU*COs%s^3*B#E*$S0($dJxTfs+-75Alb4qV|B5+|<>u!)~
zq...@ee1oan~aoji5asq`nm|~O(9e=zMBQB(O+g6{taiv
zY6##+t*aBO^h7gmJ(+BLa~d^2-%_sLIBi|cmDeG!Lb98rzm$;rv>9ULqkaEE28
zsi`SN(&NpVPW`(0=?sN5%gvjk&CN4A>vOJnRQM&ni4QKUT_Pk1io^Jr7y-wz4{K|#
z5=LT9PAkL1`n(C@;d|iGL3Cic(juO1i)6=ukah%1_NLQCII5;>lQRno%
zF74JW;~R0bG&b~lmx_w`qvs...@u1nncfpqyjg=<$kOfX?k32ABOy*L8=j`7qVmCYhP>e({C{_CrXxktqj6cjL^hQ1rlnp7_i2+?jgv...@tkk!`r;^EcObYgt!U*PZG-O`HMFQbIyPWc)^4Z0z&kU}^8Q
z=Z7pOo?exbV)UhMI6)%zczF!cy1$r^sTi&lak+QEP8W^7agKCe4EDm(M6K_sQ>TVA
z)j...@zx`g0e2w)*pz(CJig#jDQzsS)`3v>!+CKxr
zA3xr*G!$cH&9dl-?>#!yynp|`jSbf(7hINCUhWRlAbgsEo}Sm}LrG#c)BI><@w;~%
zoejkgYQrKUn;l_i1g=q...@^!>8|uXHy3I2LFe8*+>Tyfe?QJ{s7UzqP#_;YEV=Ay
zO2%{v*X=)3Fmdsn=i8>X_xAdezl~RUEJ1|BI8s_p?5kI=zJAq^Wc8Lxt*op(qetlL
za~&=*6F$v+)AP*DOARL!U&qAAtzV?|_1zP77-{u%Fg7-}iPF&4Zs~$ZdXuI7v9qnS
z644oE#<1u6vMEwxzJ2>vR#i=PRlnzcSy|c...@w4qw@_YbcK;|{!D&e-bc^h^qYJz
z;h...@iucj+u9ed@PPMfKoeMrgciYW8AVAtv06v}W%~Fnwi*r{(8yK{;Nitl%e3^lP
z...@8*a;AipAm1RRd?zdZp43YGh66aSIW)dW*8DBw)pf-_xbdUjB7Ia4wja|rpGba
z?$!...@joq$h!hh@*0wp(zX_tl?h5VN&e7js}m...@}yw&sB1rL{MB#_g1&UB&i8=
z?JlvVZ506IsPyc=(3x;7{5rild~p1D1BO=C(6E~AaHPMc0-<=Ps;X+Z171wZ!&4Z4
z8M(V8k86EmDn}u^J}v6)%kg5?ibPUUa&7y=?k$...@r8ytkpuubvn6ho*ele5?k;{
z9;s7h8W$hmu8VUVuL}AXFOrAHChBWvXWVO#qP)Dej*cv$GDzV6j1ZQ9nwnaYb!INC
zsnY3tj(4Trt^@>%K84l$Smm>EBdhw0SW0=hFqYNAW5-*zBt36|kLr6GU-oK0;Vfu<;B9tg`%3V+$7-mvHgnggYdXP3rTR$;qo6dW;AJh5q_Xf=Pwr
zIJT=*IhrX&Ch$RUKHAt=^XP%NpEUEoBx#ynW!J{0?!D_{+yRt$cABc)oDE=r`oaZkN+vPKX2>p^{ZE9
zI9!tV+5GqK2a8RPmd9^mrw2_V#v(
zEBn*?H*UGjegzCltW(a(&W=k;8ZCX)(k*?Mr5p{lYHfX;f`S5I%FfQt!^7j|<7Im@
zGuTMcQ1bffEv2sNfBFh*Pst?ZwK$O1*w}a~c-2eF(9rPGrAvH#eE074YoGPq{hJpV
zsi~?;)=%i^>swn}qnB`f`~Lln)o$07iCU=PNn%bHkkuYbgHZbd7frs``aWL!*#;5*
z{rh*WJ5B75IN-N@@R>w...@v&PS%)GmUTFeC-4>gv?wK^pb13vzNq{dfPSr>ARcD)sgC
zK~dE;G*mB9D>STR5_tIh*)#c*n)^Bjdf0xzBUjf}(I6OQ46CyA?o0#m!6B5P3Yn*=
znD~7({QVEu)Z>u`WzT2hR$y~R0}P>cbYAKs*#i(~&qjK$&ypc9(E%|!*DsI-HGU~D
z12`%yEZqCM(4VDD<>9dr9mU1V+XY3nt?gsLfzP95H#1Ai__(-...@uwt9hyam*~skp4$
zJ<-)?06>V-r}uVtfb2|tk}r9Z_;_UkN)A#|vI=V4YIM%KcbBeQx#jZXbKpT>-u)`m
z1`O~H+NkR^aR8q4^YebI&6kxl6ebtd!ou3y+b{7wc~*~h...@e?_ynzasm&-...@ai
z_PckuvTqO%6|?km...@hq&%7r1BAqB;x+-)rs;SjRIq`s%yB&CF~BRzc@@(#**z5UM|_5Ph&7I7lGy7+1OPZT?=v
z$yK>8yo!zeJ7ru087S^Ht5Mc1wlMAbQRZkL7amR#rLpsLC6{>z)tz=hn1?1ul2?`jlq...@mm$8f-@kcewr-uQS>RQsgt_}#
zT*1i5DDCIK8K;H=IN7zZX}YhgD}Vd8t*x!JQ6+Q0c1E5F*CTYI3K#1^OK=H{jxNl&o11MXYqHrF*Wg8ulPCZtI~Osu%5=*yijvGJ+;6...@+
z;w>Oty>}NE7lESi3kwhQ^mwh$b{_0)F-v*LR)~e1W$=WF)bkCWfKJK&zVXtXwp6&OzEa`3yp`SF#sfMK<
z!P`N-Suk-hqcx7k%b...@ls{e9a?yjblm0f4lsx<|m?fxRl$*SEE`
zu_{M>o(ePN!oyQMmj)weO##=Q%JzKXGpmKYR`8&9cXhf&L(j7HH5<3E=sHV1dAwpP0B=W_J?E#we(r17ulOEjc*~b}h
zXeFEa_~%05o&b...@a#0-gbnggzqdarp6hht-rnb6k0y%?d`stvshknxduegytn{^9
zLSqmG=qWijKUf$IjWa1RK=?b|;u){...@s7s_7?fr|-?el=k243H%A5Iyq^Iu{;Z#
zOhDjH#ZY;8xluzi...@g!zjdy?$cks>;*{P9R=EfkDI$`RKF}pXxswH#~0mI0#r)q
zJ&ocWA0Ho0byn~ny0b!m...@l?;`))awp?T2dFYXj_hTXk$$Hmh#N2u)m`>=&<
zAV+tFVbQaN>_...@j-v<6JY-^;D8u4`0|F4o5ZW6Wo=(z%tYiq7KB|S{H2H7Fm;?9a
Re: [Sugar-devel] Killing activities when memory gets short
> 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 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
Re: [Sugar-devel] Browse-115 stops when pop-up tab closes
Yes, it is a bug. It has been observed that under certain versions of cairo, Browse with tabs crashes. V115 checks for this and disables tabs if such a version is detected. It's possible that other versions of cairo are problematic, too. Please attach Browse's log and report your cairo version, I'll check it out tomorrow. On 10 Aug 2010 21:33, "Chris Ball" wrote: Hi, > I have been consistently able to reproduce this on my XO-1 > running build 353pyg and Brows... Quitting the entire activity in response to (presumably) a javascript statement can only be a bug, in my opinion. Thanks, - Chris. -- Chris Ball One Laptop Per Child ___ 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] Browse-115 stops when pop-up tab closes
Hi, > I have been consistently able to reproduce this on my XO-1 > running build 353pyg and Browse-115. Seeing that I haven't found > a entry on the OLPC and SugarLabs bug trackers nor any > discussions here on the list I was wondering whether that webmail > system is to blame or if this is indeed a bug. Quitting the entire activity in response to (presumably) a javascript statement can only be a bug, in my opinion. Thanks, - Chris. -- Chris Ball One Laptop Per Child ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Browse-115 stops when pop-up tab closes
Hi all, my university's webmail system (Horde) uses a popup for composing e-mail which Browse-115 correctly displays in a tab. However upon sending the e-mail not just the composition tab is closed but the whole Browse activity quits. I have been consistently able to reproduce this on my XO-1 running build 353pyg and Browse-115. Seeing that I haven't found a entry on the OLPC and SugarLabs bug trackers nor any discussions here on the list I was wondering whether that webmail system is to blame or if this is indeed a bug. Thanks, Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Feature and API/ABI Freeze approaching
On Tue, Aug 10, 2010 at 2:51 PM, Simon Schampijer wrote: > On 08/10/2010 08:31 PM, Walter Bender wrote: >> >> On Tue, Aug 10, 2010 at 2:11 PM, Simon Schampijer >> wrote: >>> >>> Dear Sugar community, >>> >>> the Feature Freeze for Sucrose 0.90 is approaching. It will be due next >>> Monday, the 16th of August [1]. >> >> I am still hoping to figure out how to get "write to Journal at any >> time" feature [1] done in time for the freeze... it will be touch and >> go as I still have a major blocker in getting the shell to know about >> the object_id... Stay tuned. >> >> -walter >> >> [1] http://wiki.sugarlabs.org/go/Features/Write_to_journal_anytime >> > > Great. Walter did you consider that design [1]? I liked it quite a lot > (should have some initial code sitting somewhere too). > > Regards, > Simon > > [1] http://wiki.sugarlabs.org/go/File:Description.png > I liked that design too, but it requires adding a button to the toolbar, which I would like to avoid. I'm going down a different path, which is to add a menu item to the Frame (same as with View Source). -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
Re: [Sugar-devel] [ANNOUNCE] Feature and API/ABI Freeze approaching
On 08/10/2010 08:31 PM, Walter Bender wrote: > On Tue, Aug 10, 2010 at 2:11 PM, Simon Schampijer wrote: >> Dear Sugar community, >> >> the Feature Freeze for Sucrose 0.90 is approaching. It will be due next >> Monday, the 16th of August [1]. > > I am still hoping to figure out how to get "write to Journal at any > time" feature [1] done in time for the freeze... it will be touch and > go as I still have a major blocker in getting the shell to know about > the object_id... Stay tuned. > > -walter > > [1] http://wiki.sugarlabs.org/go/Features/Write_to_journal_anytime > Great. Walter did you consider that design [1]? I liked it quite a lot (should have some initial code sitting somewhere too). Regards, Simon [1] http://wiki.sugarlabs.org/go/File:Description.png ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Feature and API/ABI Freeze approaching
On Tue, Aug 10, 2010 at 2:11 PM, Simon Schampijer wrote: > Dear Sugar community, > > the Feature Freeze for Sucrose 0.90 is approaching. It will be due next > Monday, the 16th of August [1]. I am still hoping to figure out how to get "write to Journal at any time" feature [1] done in time for the freeze... it will be touch and go as I still have a major blocker in getting the shell to know about the object_id... Stay tuned. -walter [1] http://wiki.sugarlabs.org/go/Features/Write_to_journal_anytime > > If a feature you are working on is not listed at the 0.90 Feature page > and you want to propose it for inclusion please do so *now* following > the Feature Policy [3]. Please have in mind that you have to land your > code by Feature Freeze and that it has to go through the review process [4]. > > If your Feature is not ready for this release, you should not worry too > much, there will be another release in 6 months. Please make sure to > propose it as early as possible. > > Regards, > Simon > > [1] http://wiki.sugarlabs.org/go/0.90/Roadmap#Schedule > [2] http://wiki.sugarlabs.org/go/0.90/Feature_List > [3] http://wiki.sugarlabs.org/go/Features/Policy > [4] http://wiki.sugarlabs.org/go/Development_Team/Code_Review > ___ > 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
[Sugar-devel] [ANNOUNCE] Feature and API/ABI Freeze approaching
Dear Sugar community, the Feature Freeze for Sucrose 0.90 is approaching. It will be due next Monday, the 16th of August [1]. If a feature you are working on is not listed at the 0.90 Feature page and you want to propose it for inclusion please do so *now* following the Feature Policy [3]. Please have in mind that you have to land your code by Feature Freeze and that it has to go through the review process [4]. If your Feature is not ready for this release, you should not worry too much, there will be another release in 6 months. Please make sure to propose it as early as possible. Regards, Simon [1] http://wiki.sugarlabs.org/go/0.90/Roadmap#Schedule [2] http://wiki.sugarlabs.org/go/0.90/Feature_List [3] http://wiki.sugarlabs.org/go/Features/Policy [4] http://wiki.sugarlabs.org/go/Development_Team/Code_Review ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Sugar Digest 2010-08-10
==Sugar Digest== 1. Since the early days of One Laptop per Child I spent a lot of energy combating the accusations that OLPC's plan is to give hardware to children, sit back, and wait for miracles to happen. The sustained efforts of the Sugar community and the enormous investment in support made by the various deployment teams around the world are tangible evidence that we do not waiting for miracles – rather we are doing the hard work to ensure that the opportunity to learn is made available to every child. It is therefore disheartening to hear Nicholas Negroponte once again say "You can, you actually can" [give a kid a laptop connected to the Internet and walk away]. [http://news.cnet.com/8301-13860_3-20012926-56.html] While there is much evidence to suggest that the informal time spent with computing is valuable, we have a lot of work ahead of us in order to bridge the gulf between using a computer and using a computer for learning. While the much-hyped Whole-in-the-Wall Project demonstrated that children can learn to use computers without any instruction, if we want them to engage with "powerful ideas", we must offer them more and better contexts for learning – on their own, among their peers, and under the guidance of a mentor. 2. I was on a short holiday last week, but I did have time to have some fun reworking the Sugar Home View so that we can better support more Activities (and perhaps eventually content). You can see some sketches here: [http://wiki.sugarlabs.org/go/Features/Spiral_Home_View#Detailed_Description]. While there are many ideas kicking around about how we might improve the Home View, including making it a normal Sugar Activity and further integrating it into the Journal, I am hoping that this one change will be complete in time to meet the looming feature freeze for 0.90. 3. Hilaire Fernandes announced the release 10.08 of the DrGeo Activity [http://blog.ofset.org/hilaire/index.php?post/drgeo-xo-10.08-release]. For those of you have never used it, DrGeo is a great tool for exploring advanced concepts in geometry. ===In the community=== 4. There was an education mini-summit [http://teachingopensource.org/index.php/LinuxCon_2010] at LinuxCon in Boston. It was heavily geared towards Sugar with talks about Sugar in RHEL 6 (Sebastian Dziallas) and Sugar on Ubuntu (Ian Daniher). There was a very nice talk about using Inkscape in middle school by Máirín Duffy of Red Hat employee. Alas, I missed both Karlie Robinson talk on her Beginner Guide to FLOSS education and David Trask's update on the Maine 1-to-1 computing initiative. 5. Constructionism 2010 - Paris [http://www.aup.fr/news/special_events/constructionism2010.htm] begins 16 August at the American University of Paris. ===Sugar Labs=== Gary Martin has generated SOMs from the past few weeks of discussion on the IAEP mailing list. http://wiki.sugarlabs.org/go/File:2010-July-24-30-som.jpg| (25 emails) http://wiki.sugarlabs.org/go/File:2010-Jul-31-Aug-6-som.jpg (44 emails) Visit http://planet.sugarlabs.org for more updates about Sugar and Sugar deployments. -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
