Re: [sugar] Question about clipboard service
On Fri, Jul 18, 2008 at 10:29 PM, Faisal Anwar [EMAIL PROTECTED] wrote: Hi, I'm playing around with the clipboard package on sugar and had a quick question. So, the clipboardservice.py file shows some basic api for getting and setting objects on the clipboard through the dbus. However, the add_object and get_object methods (and their variants) rely on knowing an object_id in order to retrieve something from the clipboard. Typically, a clipboard has some stack like structure where you can automatically retrieve the last thing copied to the clipboard without necessarily knowing its internal id. This would seem especially important fo passing things to other activities, which can't reasonably figure out the object_id created when something is saved to the clipboard by another activity. Does anyone know how to just retrieve the last item saved to the clipboard and also get a list of the last N items saved to the clipboard? Also, the gtk.Clipboard framework allows access to several different clipboards that have slightly different purposes. Is there similar functionality available through sugar/dbus or would one go directly to the gtk implementation? Hi Faisal, we haven't reached any agreement yet about exposing a different clipboard API than the one in gtk+ (that wraps around the different clipboard-related specs used in X). In other words, nobody other than the shell should directly use the clipboard service and this will probably disappear in the future. Activity authors should the use the clipboard functionality as exposed by their toolkits (gtk+) or implement themselves those specs (as etoys has done). Can you add this note somewhere in the almanac? Thanks, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: wxWidgets under Sugar?
On Sat, Jul 19, 2008 at 12:14 AM, Brian Harvey [EMAIL PROTECTED] wrote: Has anyone already gotten wxWidgets to work with Sugar? If so, that would save me a lot of duplicated effort -- right now, any wxWidgets program I try to run immediately seg faults. Thanks. (This is to help in getting Berkeley Logo running on the XO.) Hi Brian, just did 'yum install audacity' in joyride-2181 and it worked fine, audacity is a wxGTK app. I saw that yum installed the package compat-wxGTK26, maybe you are missing that one? If you still cannot put it to work, please paste the error message you get, if any. Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Autosave in 8.2.0?
On Thu, Jul 17, 2008 at 4:37 PM, Bert Freudenberg [EMAIL PROTECTED] wrote: Am 17.07.2008 um 00:10 schrieb Tomeu Vizoso: Marco has added a session manager to Sugar (in 8.2.0) that takes care of telling activities to save their work because the system is being shut down. Haven't verified if this is complete and working. Have you, Marco? If so, this would also take care of the case where kids shut down before closing all running activities first. How does this work from an activity's pov? A python activity using the Sugar API does nothing, the save() method will be called as required. The rest of the activities would use http://www.xfree.org/current/xsmp.pdf to note when are expected to save their data, hopefully using a wrapper around the protocol like the one in GNOME: http://library.gnome.org/devel/libgnomeui/unstable/GnomeClient.html I think that Freedesktop people are moving to a D-Bus based protocol, but don't the status of it. Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Report on `views with many icons' profiling
This is really awesome, congrats. I would like to know how much time takes every switch (including the redraw), is that 130ms and 170ms? Looks like it should be more to me. Also, would like to see as well a top-down analysis, which are the top 3-5 high level operations that take most CPU? Are they executed more often than what would be strictly needed? I see in kcachegrind that _views_switch_...() was called 2481 times, this means that your script switched that many times? Can you please try to assess the impact to the user of any slowness we may have in there? Which are in your opinion the next steps we should take? Thanks, Tomeu [Sorry about the late replies] On Thu, Jul 17, 2008 at 7:43 PM, riccardo [EMAIL PROTECTED] wrote: Hi, Problem: slow switching between views with many icons Test-case: the test consist of switching between the favorites view and the list view. Test were ran once with the ring layout in the favorite view and once with the freeform layout; the xo had 25 activities installed all checked as `favorite'. The action of switching was automated with a timer with period 130ms when the ring layout was selected and 170ms in the case of the freeform layout (as the minimum values permitting complete redraw of the views). Note that there is a noticeable delay when switching to the favorites views when the selected layout is freeform. --- RING layout --- The following tab. and fig. show cpu time usage of the processes taking more cpu time while running the test: (tot% us+sy) - (partial% us+sy) : cmdline - 63.6 : python /usr/bin/sugar-shell 91.2- 27.5 : /usr/bin/X :0 -fp built-ins... 99.5- 8.2 : picker -t30 http://dev.laptop.org/~rlucchese/views/favorites_ring-list/picker.stats.svg (http://dev.laptop.org/~rlucchese/views/favorites_ring-list/picker.stats ) They were obtained by running: $ picker -t30 $ grapher -c3 --- FREEFORM layout --- (tot% us+sy) - (partial% us+sy) : cmdline - 82. : python /usr/bin/sugar-shell 91.6- 9.5 : /usr/bin/X :0 -fp built-ins... 99.4- 7.7 : picker -t30 http://dev.laptop.org/~rlucchese/views/favorites_freeform-list/picker.stats.svg (http://dev.laptop.org/~rlucchese/views/favorites_freeform-list/picker.stats ) ! sugar-shell is taking 20% more cpu time than in the ring layout case. cProfile statistics (KCacheGrind format) for sugar-shell: --- RING layout --- http://dev.laptop.org/~rlucchese/views/favorites_ring-list/cProfile-shell Ordering by function's self-time: % func name 35.6 : cairo.Context.paint 3.9: gtk.Container.add 2. : sugar.graphics.palette.do_paint_below_children 1.9: __setitem__ sugar.util -- 57% Well, this isn't unexpected. But it's interesting when looking at sysprof results (below). --- FREEFORM layout --- http://dev.laptop.org/~rlucchese/views/favorites_freeform-list/cProfile-shell Ordering by function's self-time: % func name 21.6 : _add_weight in sugar/shell/view/home/grid.py 21.5 : _remove_weight in sugar/shell/view/home/grid.py 10.6 : cairo.Context.paint 8.1: __setitem__ sugar.util 5.7: _compute_weight in sugar/shell/view/home/grid.py -- 57.5% ! Box2D would perform better ;) Sysprof results. Well, in sysprof there are many nested levels, so it is much more clear to just look at it. --- RING layout --- http://dev.laptop.org/~rlucchese/views/favorites_ring-list/sysprof.data - most of self-time is spent in the kernel and in X/X-modules. - time spent in the kernel is due to python and X, respectively 60%-40%. - time spent `in X' goes mostly to the geode driver, and then, to Xorg itself and the libexa module. --- FREEFORM layout --- http://dev.laptop.org/~rlucchese/views/favorites_freeform-list/sysprof.data Notes for the ring layout are valid also here. There are two (new) entries in this case and they are taking more time than the X geode module: python's numpy/core/multiarray.so and numpy/core/umath.so. This is in relation with the algorithm used in the freeform layout to avoid icons collisions. thanks, riccardo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Write needs your help (was Re: Programming environments on the XO)
On Fri, Jul 18, 2008 at 12:11 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 4:51 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Yes, I agree that this is a goal that makes a lot of sense. Unfortunately, my experience says that the approach you are suggesting won't be less work than what we are doing right now, because the software components you mentioned aren't so easily malleable as you seem to think. Your argument might be correct for Abiword (I haven't look at the code) but are completely off-base for Firefox, which is based on a very sophisticated XUL/Javascript/XML based extensibility framework, with far better developer support than we currently have for Python. Well, with our current model, you can develop extensions in C++, JS and python in the same way you would do it for firefox or any other xulrunner-based app. And you can use those extensions as well in any of those apps if it makes any sense. So I think in this regard we are doing things as you are asking. About using XUL instead of the usual pygtk-based activity stuff, I really cannot see how it would help us. I don't see any advantage but see lots of code that would need to be rewritten. Can you enumerate the advantages you see by moving to use the XUL stuff? I guess you are suggesting to do something similar to Songbird. Thanks, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Re: Faster Launch of Activities
On Wed, Jul 16, 2008 at 11:13 AM, riccardo [EMAIL PROTECTED] wrote:
On Tue, 2008-07-15 at 11:47 +0200, riccardo wrote:
On Tue, 2008-07-15 at 05:01 -0400, Greg Smith wrote:
description?
It would be useful to see a comparison of build 656 v 703 v 708 v
latest
joyride. That's a lot so just 703 (last release image) vs latest
Joyride
would the top priority.
I'm not instrumenting the code but using a stopwatch so timings are a
bit rough.
The test:
- reboot the machine
- wait that jfss2_gcd_mtd0 finishes hogging the cpu
(around 50 secs from when the shell is displayed)
- go to the listview
(*)
- for every activity (one at time), from the drop menu-start and take
the time until the full window redrawn
- do it again from point (*) if you want to see the difference between
first startup and 'warm' startup
I also use to gather stats with Picker while doing the test, to see
what processes are taking more cpu time; it also helps to catch
conditions where activities are fully redrawn at time x but really are
fully loaded at x+20sec (easy to see in etoys and browse).
Are both first and second launch timings needed ?
Michael,
What is the latest version of Joyride that people should be testing?
I re-read your status e-mail July 12 and didn't see it in there:
http://lists.laptop.org/pipermail/devel/2008-July/016457.html
I didn't click on all the links so let me know if I missed it
somewhere.
Could anybody confirm the following points please ?
- builds numbers
As Greg said, comparing 703 with latest joyride may be the most
interesting thing to do.
- if it's ok to take those timings as explained above
What about the following:
- add logging.debug('TIME launch starts') at
activitieslist.ActivityEntry.__icon_button_release_event_cb
- add logging.debug('TIME launch finished') at activity.Activity.__canvas_map_cb
If we really want to take in account the redraw time (not sure myself
if it's worth), you could override Activity.do_expose_event() and move
the launch finished print after the call to the parent finishes.
Something like grep -h TIME logs/* | sort -n should give you a way to
see how much time took every launch.
Sounds good?
Tomeu
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Quick tabbing profiling (was Re: Report on `activities switching' profiling)
2008/7/18 Benjamin Berg [EMAIL PROTECTED]: Hello, On Fri, 2008-07-18 at 12:51 -0400, Eben Eliason wrote: Can someone make sense of this for me? Ben, do you see anything we can optimize here? I've noticed while quick-tabbing on my XO that the gray selection box doesn't usually update as I switch, so I can't tell where I am. If I pause long enough to see the selection move, I also get the redraw of the whole activity, slowing me down and defeating the purpose. Outch. It is right that the activities are saving their state all the time. I forgot about the messages send to the activities. Which means that the activities are active even though the window is not raised. We may need a more complicated scheme to keep track of the activities during tabbing. Much more complicated? Perhaps we should have a TabbingContext class to keep track of these things, so we don't add too much complexity to classes like Shell and ShellModel? How bad is this issue from the user point of view? In my opinion, if we can land one important feature like this on one milestone, and improve its performance on the next one, that's quite probably the best we can do with the available resources. If we optimize too late in the release cycle, we may introduce too many bugs and greatly affect the stability of the whole product. Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
pacing oneself
The visual speed of operation of palette opening/closing on the screen is noticeably slower on the OLPC than on a workstation. When the OLPC user fails to slow down with his actions, unintended consequences can result. Was working (Joyride 2177) in Terminal with a removable storage device. Issued an 'umount' command - it was rejected with device is busy. Went to the Journal, selected that device's icon, and (rapidly) invoked the pop-up palette to unmount that device. But (being spastic, and not pausing to make sure where the cursor was positioned) I had managed to click on the 'base' of the palette instead of on the 'Unmount' entry. Not realizing what had happened, what I *did* notice was the XO becoming extremely unresponsive. Went (took a long time) back to Terminal, and issued 'top'. It showed Journal taking 100% of the available CPU cycles. Decided to wait out whatever was going on. After two minutes or so, the high Journal usage stopped. Went over to Journal, and *now* I saw what I had done - Journal was showing me the files on that device. [Apparently it had taken Journal a couple of minutes to scan that device.] Switched what the Journal was showing to normal, clicked (more carefully) on the 'Unmount' of the removable device, and all was back to what was supposed to be. I am *not* posting for help. But I *do* wish to point out that (particularly when dissimilar functions are visually adjacent -- e.g., unmount vs. show), failure to 'pace oneself' on the OLPC can bring on the unexpected. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Quick tabbing profiling (was Re: Report on `activities switching' profiling)
On Sat, 2008-07-19 at 12:18 +0200, Tomeu Vizoso wrote: 2008/7/18 Benjamin Berg [EMAIL PROTECTED]: We may need a more complicated scheme to keep track of the activities during tabbing. Much more complicated? Perhaps we should have a TabbingContext class to keep track of these things, so we don't add too much complexity to classes like Shell and ShellModel? The current code assumes that one can just switch the active Activity right away, but only raise the window on a delay. This does not work. I already had some code in my first series of patches that would keep track of a tabbing-activity separately from the active-activity (in the HomeModel). This, together with some other changes, will be needed to fix the issue. How bad is this issue from the user point of view? Tabbing is still better than it was before my patches landed. But I do expect that fixing this will be nice improvement in in tabbing experience. In my opinion, if we can land one important feature like this on one milestone, and improve its performance on the next one, that's quite probably the best we can do with the available resources. If we optimize too late in the release cycle, we may introduce too many bugs and greatly affect the stability of the whole product. Of course, destabilising sugar should not be an option. I am planning to look into this at the end of next week. So I hope to have a patch by Friday or Saturday. Benjamin signature.asc Description: This is a digitally signed message part ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW sad face doesn't say why
Scott wrote (regarding me booting with the wrong develop.sig on an SD card): Do you normally use a developer key in order to boot -- ie, are you running a joyride build on BB? Is the root problem here, perhaps, that after OFW finds a develop.sig on the SD card which doesn't work, it doesn't continue to look in other places (like NAND)? Yes, I am running a joyride build on that system. This whole business of what indicators need to be placed where is a complete mystery to me. That is why I use a permanent SD card, with my develop.sig on that card -- then if I need to re-flash NAND I don't have to worry about who/how puts a develop.sig file in NAND. [Yes, there was the correct develop.sig for that system in NAND; only the SD card (looked at first by OFW) had the incorrect one.] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW sad face doesn't say why
Mitch wrote: If you hold down the check key while booting, the firmware will give additional information about the boot progress, in both iconic and textual form. I did not realize that. Now that I went searching for this, saw it mentioned in the wiki on the 'XO_Troubleshooting_PowerOn' page. And yes, with the check key pressed, the firmware did print trying sd:\security\devel.sig and some sort of invalid message. [These stand out from the other texts if one KNOWS to look for them.] [I haven't been using chatty (check key held) mode for booting -- but I've been seeing icons-drawn-by-firmware anyway.] I WISH there was a comprehensive description accessible of the __iconic__ information shown by the boot process. For instance, for me the green 'olpc' icon disappears from the firmware display whenever I have a SD card plugged in (but then I normally *would* see an orange 'SD card' icon). I seem to get the additional red? 'plugin' icon whenever I have an USB stick or an ethernet adapter plugged in. And I have only vague notions about what the various symbols (that can appear underneath an icon) are trying to tell me. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Devel Digest, Vol 29, Issue 120
Forgive my interjection. http://forum.laptop.org is already set up as a forum. While there seem to be more users over at the olpcnews forum, this one is still used for suggestions/help/news, etc. -j -- Message: 4 Date: Fri, 18 Jul 2008 21:31:24 -0400 From: Eben Eliason [EMAIL PROTECTED] Subject: Re: URL and Integration To: Noah Kantrowitz [EMAIL PROTECTED], Adam Holt [EMAIL PROTECTED] Cc: devel@lists.laptop.org, Jonah Saltzman [EMAIL PROTECTED], Sugar List [EMAIL PROTECTED], [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 On the other hand, maybe what we need more is a forum space. We have the wiki, and we have the bug system, but we don't have an interactive space where people can ask questions and help each other find solutions. I think this was one of the goals you had in mind for the site, and I think a forum might be a more appropriate manifestation of that. If that's something we seriously want to do (forum.laptop.org, or similar?), we should research some available open source solutions and choose one which would best suit our needs. There would still be a fair bit of work involved in setting it up and theming it appropriately, as well as need for moderation and such, but over time that kind of administration could be handled largely by community. Such an initiative could also benefit the support folks by providing a more self-sustaining method for people to ask and answer questions. - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Question about clipboard service
I can't tell from your wording if you are implying that we will or will not be creating some custom wrappers for the clipboard service. I think we absolutely need them to accomplish several critical clipboard issues (among them, specifying icons, colors, titles, and previews for clippings). In fact, getting this API working effectively is high on my list of priorities for 9.1 - Eben On Sat, Jul 19, 2008 at 4:19 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Fri, Jul 18, 2008 at 10:29 PM, Faisal Anwar [EMAIL PROTECTED] wrote: Hi, I'm playing around with the clipboard package on sugar and had a quick question. So, the clipboardservice.py file shows some basic api for getting and setting objects on the clipboard through the dbus. However, the add_object and get_object methods (and their variants) rely on knowing an object_id in order to retrieve something from the clipboard. Typically, a clipboard has some stack like structure where you can automatically retrieve the last thing copied to the clipboard without necessarily knowing its internal id. This would seem especially important fo passing things to other activities, which can't reasonably figure out the object_id created when something is saved to the clipboard by another activity. Does anyone know how to just retrieve the last item saved to the clipboard and also get a list of the last N items saved to the clipboard? Also, the gtk.Clipboard framework allows access to several different clipboards that have slightly different purposes. Is there similar functionality available through sugar/dbus or would one go directly to the gtk implementation? Hi Faisal, we haven't reached any agreement yet about exposing a different clipboard API than the one in gtk+ (that wraps around the different clipboard-related specs used in X). In other words, nobody other than the shell should directly use the clipboard service and this will probably disappear in the future. Activity authors should the use the clipboard functionality as exposed by their toolkits (gtk+) or implement themselves those specs (as etoys has done). Can you add this note somewhere in the almanac? Thanks, Tomeu ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Question about clipboard service
Well, we can add some sugar API around the gtk clipboard stuff, but I'm not sure there's a lot of value in there, as the gtk+ API is already quite high level. The problem here is how do we extend the existing X specs to deliver the experience we aim for. Last we talked about it, Marco was opposed to use the X selection targets to pass titles and icons around. Eben, now is a good moment to start talking about it, can you summarize what is missing from the clipboard and try to list all that we want to do but the current spec doesn't allow to? Thanks, Tomeu On Sat, Jul 19, 2008 at 5:01 PM, Eben Eliason [EMAIL PROTECTED] wrote: I can't tell from your wording if you are implying that we will or will not be creating some custom wrappers for the clipboard service. I think we absolutely need them to accomplish several critical clipboard issues (among them, specifying icons, colors, titles, and previews for clippings). In fact, getting this API working effectively is high on my list of priorities for 9.1 - Eben On Sat, Jul 19, 2008 at 4:19 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Fri, Jul 18, 2008 at 10:29 PM, Faisal Anwar [EMAIL PROTECTED] wrote: Hi, I'm playing around with the clipboard package on sugar and had a quick question. So, the clipboardservice.py file shows some basic api for getting and setting objects on the clipboard through the dbus. However, the add_object and get_object methods (and their variants) rely on knowing an object_id in order to retrieve something from the clipboard. Typically, a clipboard has some stack like structure where you can automatically retrieve the last thing copied to the clipboard without necessarily knowing its internal id. This would seem especially important fo passing things to other activities, which can't reasonably figure out the object_id created when something is saved to the clipboard by another activity. Does anyone know how to just retrieve the last item saved to the clipboard and also get a list of the last N items saved to the clipboard? Also, the gtk.Clipboard framework allows access to several different clipboards that have slightly different purposes. Is there similar functionality available through sugar/dbus or would one go directly to the gtk implementation? Hi Faisal, we haven't reached any agreement yet about exposing a different clipboard API than the one in gtk+ (that wraps around the different clipboard-related specs used in X). In other words, nobody other than the shell should directly use the clipboard service and this will probably disappear in the future. Activity authors should the use the clipboard functionality as exposed by their toolkits (gtk+) or implement themselves those specs (as etoys has done). Can you add this note somewhere in the almanac? Thanks, Tomeu ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SMS messaging
On Thu, Jul 17, 2008 at 03:44:45PM -0400, Ankur Verma wrote: Hello, I am able to receive SMS text messages through a mobile phone intended to be attached to school server. I need to forward this message to a specific XO connected on the jabber server. At this moment, I have the message in the format XO_name:SMS_Message. My plan is: 1. Get information (Unfriendly Jabber ID? or Nick?) about all the XOs connected. 2. Compare against the XO_name in message. 3. Send SMS_message to it in the form of XMPP message. - message received by sms service (for local addressing) - service uses message header (characters prior to ':') to do local routing - message is sent to that xo So this is sms - jabber - xo. Do you also wish to implement xo - jabber - sms? Kindly tell me how should I proceed? I will appreciate any pointers/alternative approaches from your side. You should investigate: http://www.ejabberd.im/mod_sms http://www.dp.uz.gov.ua/o.palij/mod_sms/ I am reading this very loosely and quickly, but it appears that this ejabberd module can integrate ejabber with an sms-smtp transport service located at (e.g.) sms.exampligratia.net in order to provide sms functionality. Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Joyride and microphone
I recently upgraded to Joyride and am having trouble with the microphone. In the powerup selftest the microphone works, but the level of the playback is much lower than the powerup chime or the sound sweep test. The microphone does not work in Record or Measure. Version particulars: Firmware q2d16 Joyride 2137 Record 55 Measure 17 Is this a software issue or did my mic die? Things were working before I upgraded to Joyride. Anything I can do to check? If this is a software issue are there libraries or versions I need to change? I'd prefer not to have to go back to 708 just to check this issue out. Thanks Bob ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Devel Digest, Vol 29, Issue 122
Hi Mikus, Can you file a bug on this (dev.laptop.org) and include steps to reproduce and test? Mark the milestone 8.2.0 and priority High (may be triaged higher if it affects a lot of cases). My impression is its a design improvement (e.g. hour glass cursor) we should target for 9.1.0 but we can spend 10 minutes reviewing it in a bug scrub meeting first. Thanks, Greg S ** Date: Sat, 19 Jul 2008 05:32:16 -0400 From: Mikus Grinbergs [EMAIL PROTECTED] Subject: pacing oneself To: [EMAIL PROTECTED], devel@lists.laptop.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed The visual speed of operation of palette opening/closing on the screen is noticeably slower on the OLPC than on a workstation. When the OLPC user fails to slow down with his actions, unintended consequences can result. Was working (Joyride 2177) in Terminal with a removable storage device. Issued an 'umount' command - it was rejected with device is busy. Went to the Journal, selected that device's icon, and (rapidly) invoked the pop-up palette to unmount that device. But (being spastic, and not pausing to make sure where the cursor was positioned) I had managed to click on the 'base' of the palette instead of on the 'Unmount' entry. Not realizing what had happened, what I *did* notice was the XO becoming extremely unresponsive. Went (took a long time) back to Terminal, and issued 'top'. It showed Journal taking 100% of the available CPU cycles. Decided to wait out whatever was going on. After two minutes or so, the high Journal usage stopped. Went over to Journal, and *now* I saw what I had done - Journal was showing me the files on that device. [Apparently it had taken Journal a couple of minutes to scan that device.] Switched what the Journal was showing to normal, clicked (more carefully) on the 'Unmount' of the removable device, and all was back to what was supposed to be. I am *not* posting for help. But I *do* wish to point out that (particularly when dissimilar functions are visually adjacent -- e.g., unmount vs. show), failure to 'pace oneself' on the OLPC can bring on the unexpected. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW sad face doesn't say why
On Sat, Jul 19, 2008 at 5:52 AM, Mikus Grinbergs [EMAIL PROTECTED] wrote: Yes, I am running a joyride build on that system. This whole business of what indicators need to be placed where is a complete mystery to me. That is why I use a permanent SD card, with my develop.sig on that card -- then if I need to re-flash NAND I don't have to worry about who/how puts a develop.sig file in NAND. [Yes, there was the correct develop.sig for that system in NAND; only the SD card (looked at first by OFW) had the incorrect one.] Mitch, it looks like the real issue here, then, is that OFW doesn't continue to look for develop.sig on other devices once it's found one which doesn't work. If it had, then the presence of a bogus develop.sig on SD wouldn't have preventing OFW from finding the correct develop.sig on NAND and booting the system correctly. That sounds like a bug we can fix. (Mikus: the info you're looking for is http://wiki.laptop.org/go/Startup_Diagnosis ) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: NAND out of space crash (was Display warnings in sugar (Emiliano Pastorino))
Hi All, Emiliano has an elegant workaround but crashing the XO on NAND full (to un-recoverable state?) is a heinous bug that affects essentially all users. If someone has the bug ID handy can you send it out and mark it a blocker for 8.2.0 (priority = blocker and keyword includes blocks:8.2.0)? Can I get a design proposal (no re-partitioning please!), scoping and lead engineer on it ASAP? If you have to stop working on something else to do this, let me know what will drop and I'll help weigh the consequences. Thanks, Greg S [EMAIL PROTECTED] wrote: Date: Thu, 17 Jul 2008 15:44:56 -0400 From: C. Scott Ananian [EMAIL PROTECTED] Subject: Re: [sugar] Display warnings in sugar To: Tomeu Vizoso [EMAIL PROTECTED] Cc: devel@lists.laptop.org, Eben Eliason [EMAIL PROTECTED], [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 17, 2008 at 5:21 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 2:27 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: I hope our alert system will use the freedesktop.org standard: http://www.galago-project.org/specs/notification/index.php It is widely used in Gnome, and when I last reviewed it seems to be a solid and capable spec. The interfaces in that spec look quite good, although perhaps would benefit from a simpler, alternative API that also abstracts the D-Bus stuff. Perhaps rainbow should do some rate limiting or permissions checking, not sure. Sure, wrap the actual DBus calls with a simplied sugar/python method if you like, but *please* let's implement a listener for that API so that unmodified applications can interact sensibly with Sugar, and so that our system tools activities can interoperate with non-Sugar window managers. Similarly, we should really implement that standard freedesktop.org startup notification spec, so we can get sensible notifications and icons for 'ordinary' applications. --scott ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SMS messaging
Hi Erik, Thanks for your help. However, I wish to implement jabber-xo part in sms-jabber-xo for which I will need the list of XOs on server to do local routing to specific XO. Thanks Ankur Verma On Sat, Jul 19, 2008 at 11:19 AM, Erik Garrison [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 03:44:45PM -0400, Ankur Verma wrote: Hello, I am able to receive SMS text messages through a mobile phone intended to be attached to school server. I need to forward this message to a specific XO connected on the jabber server. At this moment, I have the message in the format XO_name:SMS_Message. My plan is: 1. Get information (Unfriendly Jabber ID? or Nick?) about all the XOs connected. 2. Compare against the XO_name in message. 3. Send SMS_message to it in the form of XMPP message. - message received by sms service (for local addressing) - service uses message header (characters prior to ':') to do local routing - message is sent to that xo So this is sms - jabber - xo. Do you also wish to implement xo - jabber - sms? Kindly tell me how should I proceed? I will appreciate any pointers/alternative approaches from your side. You should investigate: http://www.ejabberd.im/mod_sms http://www.dp.uz.gov.ua/o.palij/mod_sms/ I am reading this very loosely and quickly, but it appears that this ejabberd module can integrate ejabber with an sms-smtp transport service located at (e.g.) sms.exampligratia.net in order to provide sms functionality. Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: electricity table (Google Docs)
Please don't use information from Potenco, there are too many complications with their design. They assume that the battery being charged can accept all the power their device outputs. If using the crank from Freeplay, It can charge the laptop at 17W (given the user is willing to crank fast). John On Jul 18, 2008, at 9:09 PM, Edward Cherlin wrote: 2008/7/18 [EMAIL PROTECTED]: I've shared a document with you called electricity table: http://spreadsheets.google.com/ccc?key=p6DRYWvC0_wbHL1- bzt-3Mw[EMAIL PROTECTED]t=808765302247483981guest It's not an attachment -- it's stored online at Google Docs. To open this document, just click the link above. Hi guys! I was also wondering if you could give me feedback on this table. The table shows how much kWh is needed a year to power a xo based on different scenarios. If you think I should add or change anything please let me know. Thanks a lot! Mia I don't understand your calculations. Your table labels the power column in kWh, which is the wrong unit. It should be W, so that you get Wh when multiplying by hours. Thus, for example, if we have 6 W ( roughly the power used by a single XO) for 5 hours a day for 365 days annually, it comes to 10950 Wh or 10.9 kWh. You also don't give a formula for power generation time. The Potenco site gives this information: A minute of pulling the PCG generates enough energy for: * 20 minutes of talk time on a mobile phone * 1 hour of ultrabright LED flashlight use * 3 hours play time on an iPod Shuffle (about one pull per song) If one minute of pulling gives one hour of use, this comes to 5 minutes a day in the case I considered above, and similarly for the other possibilities given, from 2 minutes to 15 minutes daily. Your table, unaccountably, gives well over an hour of pulling daily. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ The best way to predict the future is to invent it.--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: NAND out of space crash (was Display warnings in sugar (Emiliano Pastorino))
On Sat, Jul 19, 2008 at 11:47:21AM -0400, Greg Smith wrote: Hi All, Emiliano has an elegant workaround but crashing the XO on NAND full (to un-recoverable state?) is a heinous bug that affects essentially all users. If someone has the bug ID handy can you send it out and mark it a blocker for 8.2.0 (priority = blocker and keyword includes blocks:8.2.0)? Can I get a design proposal (no re-partitioning please!), scoping and lead engineer on it ASAP? If you have to stop working on something else to do this, let me know what will drop and I'll help weigh the consequences. My impression is that the long-term benefits of partitioning mean that it's worthwhile to devote effort to it. Are we not going to work on partitioning in the future? In addition to a more solid solution to the NAND fillup issue, we get the opportunity to improve system performance and upgrade procedures. Partitioning will allow us to test out LZO data compression for the XO's filesystems (excluding /boot and /security). We would expect a significant i/o performance boost from the use of LZO. Additionally, partitioning would improve OFW-level system updates (e.g. copy-nand) by making it far simpler for the update procedure to leave user data intact. That said there are obviously a lot of troubles with partitioning. Updating an existing system to a partitioned one without mashing user data is a major issue. Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: NAND out of space crash (was Display warnings in sugar (Emiliano Pastorino))
On Sat, Jul 19, 2008 at 12:58:13PM -0400, Benjamin M. Schwartz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Erik Garrison wrote:
| On Sat, Jul 19, 2008 at 11:47:21AM -0400, Greg Smith wrote:
| Hi All,
|
| Emiliano has an elegant workaround but crashing the XO on NAND full (to
| un-recoverable state?) is a heinous bug that affects essentially all users.
|
| If someone has the bug ID handy can you send it out and mark it a
| blocker for 8.2.0 (priority = blocker and keyword includes blocks:8.2.0)?
|
| Can I get a design proposal (no re-partitioning please!), scoping and
| lead engineer on it ASAP?
|
| If you have to stop working on something else to do this, let me know
| what will drop and I'll help weigh the consequences.
|
| My impression is that the long-term benefits of partitioning mean that
| it's worthwhile to devote effort to it. Are we not going to work on
| partitioning in the future?
Adding partitioning does not automatically solve the NAND fillup problem.
~ The fundamental issue is that Sugar tries to write files on boot, and
fails to boot if it cannot write those files.
The correct solution is to make sure that Sugar can boot even if it cannot
write files. This change is needed in order to enable booting on full
NAND, whether or not partitioning is used to separate system and user
files. In short, these issues, while related, are largely decoupled, and
can be attacked separately.
You are absolutely correct.
Partitioning can be used to isolate the system filesystem(s) from the
effects of user-level data creation, and thus mitigate the risk of
fillup of a partition yielding an unbootable system. However, the
solution is wholly ineffectual wrt. the fillup issue until we ensure
Sugar only needs to write to the partition which we are confident will
have space. If we are going to check all the file write requirements of
the Sugar shell, we might as well implement the far better solution of
enabling Sugar to boot without writing anything.
Below is a patch to Sugar which resolves the only python-side case of a
file write during startup which I was able to find.
I couldn't find reference to the configuration variables saved in
_save_session_info elsewhere in the sugar repository. If these
variables are pulled from the config file after Sugar startup, then this
patch is a bad idea on its own.
diff --git a/src/main.py b/src/main.py
index b1ecc93..1899438 100644
--- a/src/main.py
+++ b/src/main.py
@@ -55,15 +55,19 @@ def _save_session_info():
#do not rely on it
#
session_info_file = os.path.join(env.get_profile_path(), session.info)
-f = open(session_info_file, w)
+try:
+f = open(session_info_file, w)
+
+cp = ConfigParser()
+cp.add_section('Session')
+cp.set('Session', 'dbus_address',
os.environ['DBUS_SESSION_BUS_ADDRESS'])
+cp.set('Session', 'display', gtk.gdk.display_get_default().get_name())
+cp.write(f)
-cp = ConfigParser()
-cp.add_section('Session')
-cp.set('Session', 'dbus_address', os.environ['DBUS_SESSION_BUS_ADDRESS'])
-cp.set('Session', 'display', gtk.gdk.display_get_default().get_name())
-cp.write(f)
+f.close()
+except IOError, (errno, sterror):
+logger.error(Could not open session_info_file. %s % sterror)
-f.close()
def _setup_translations():
locale_path = os.path.join(config.prefix, 'share', 'locale')
diff --git a/src/main.py b/src/main.py
index b1ecc93..1899438 100644
--- a/src/main.py
+++ b/src/main.py
@@ -55,15 +55,19 @@ def _save_session_info():
#do not rely on it
#
session_info_file = os.path.join(env.get_profile_path(), session.info)
-f = open(session_info_file, w)
+try:
+f = open(session_info_file, w)
+
+cp = ConfigParser()
+cp.add_section('Session')
+cp.set('Session', 'dbus_address', os.environ['DBUS_SESSION_BUS_ADDRESS'])
+cp.set('Session', 'display', gtk.gdk.display_get_default().get_name())
+cp.write(f)
-cp = ConfigParser()
-cp.add_section('Session')
-cp.set('Session', 'dbus_address', os.environ['DBUS_SESSION_BUS_ADDRESS'])
-cp.set('Session', 'display', gtk.gdk.display_get_default().get_name())
-cp.write(f)
+f.close()
+except IOError, (errno, sterror):
+logger.error(Could not open session_info_file. %s % sterror)
-f.close()
def _setup_translations():
locale_path = os.path.join(config.prefix, 'share', 'locale')
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: URL and Integration
On Fri, Jul 18, 2008 at 09:31:24PM -0400, Eben Eliason wrote: On the other hand, maybe what we need more is a forum space. You do realize that both forum.laptop.org and the OLPCNews forum have been up and running for months (years?) with thousands of replies? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] URL and Integration
/me feels silly. =) On Sat, Jul 19, 2008 at 2:04 PM, Michael Stone [EMAIL PROTECTED] wrote: On Fri, Jul 18, 2008 at 09:31:24PM -0400, Eben Eliason wrote: On the other hand, maybe what we need more is a forum space. You do realize that both forum.laptop.org and the OLPCNews forum have been up and running for months (years?) with thousands of replies? Michael ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
experiencing unexpected OLPC behavior from a misplaced click
I posted about an experience I had, where I was surprised to find that my OLPC had become unresponsive. My reason for posting was to alert others that surprises may be lurking for OLPC users. Greg, you quoted my post, and wrote: Can you file a bug on this (dev.laptop.org) and include steps to reproduce and test? I am put into a difficult position when I see comments like this. If I am prevented from doing something by the current behavior of the OLPC, and would like that behavior changed to allow me to go ahead and do the thing I wanted, *then* I will write a ticket. But here is a case where I did not wait long enough for the OLPC to draw a pop-up palette, and did not make sure that the cursor was correctly positioned on the appropriate entry in that palette, before I 'clicked'. In other words, it was __I__ who misbehaved. It is my intention to *not* write a ticket on this. Aside from the __user's__ behavior needing to be corrected, I'm not sure what else would be ticketable ?? It might help impatient users if palettes (e.g., in the Journal screen) were 'instantaneous' instead of 'slow' -- but I imagine the graphics speed is established by the OLPC processing capability (low power draw is imperative) and the overall Sugar GUI 'Look_And_Feel' design -- and can't be changed. I see nothing in this particular situation for which writing a ticket would improve matters. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: NAND out of space crash (was Display warnings in sugar (Emiliano Pastorino))
disclaimer.
The attached patch is untested and likely insufficient to solve this
problem.
On Sat, Jul 19, 2008 at 01:39:20PM -0400, Erik Garrison wrote:
On Sat, Jul 19, 2008 at 12:58:13PM -0400, Benjamin M. Schwartz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Erik Garrison wrote:
| On Sat, Jul 19, 2008 at 11:47:21AM -0400, Greg Smith wrote:
| Hi All,
|
| Emiliano has an elegant workaround but crashing the XO on NAND full (to
| un-recoverable state?) is a heinous bug that affects essentially all
users.
|
| If someone has the bug ID handy can you send it out and mark it a
| blocker for 8.2.0 (priority = blocker and keyword includes blocks:8.2.0)?
|
| Can I get a design proposal (no re-partitioning please!), scoping and
| lead engineer on it ASAP?
|
| If you have to stop working on something else to do this, let me know
| what will drop and I'll help weigh the consequences.
|
| My impression is that the long-term benefits of partitioning mean that
| it's worthwhile to devote effort to it. Are we not going to work on
| partitioning in the future?
Adding partitioning does not automatically solve the NAND fillup problem.
~ The fundamental issue is that Sugar tries to write files on boot, and
fails to boot if it cannot write those files.
The correct solution is to make sure that Sugar can boot even if it cannot
write files. This change is needed in order to enable booting on full
NAND, whether or not partitioning is used to separate system and user
files. In short, these issues, while related, are largely decoupled, and
can be attacked separately.
You are absolutely correct.
Partitioning can be used to isolate the system filesystem(s) from the
effects of user-level data creation, and thus mitigate the risk of
fillup of a partition yielding an unbootable system. However, the
solution is wholly ineffectual wrt. the fillup issue until we ensure
Sugar only needs to write to the partition which we are confident will
have space. If we are going to check all the file write requirements of
the Sugar shell, we might as well implement the far better solution of
enabling Sugar to boot without writing anything.
Below is a patch to Sugar which resolves the only python-side case of a
file write during startup which I was able to find.
I couldn't find reference to the configuration variables saved in
_save_session_info elsewhere in the sugar repository. If these
variables are pulled from the config file after Sugar startup, then this
patch is a bad idea on its own.
diff --git a/src/main.py b/src/main.py
index b1ecc93..1899438 100644
--- a/src/main.py
+++ b/src/main.py
@@ -55,15 +55,19 @@ def _save_session_info():
#do not rely on it
#
session_info_file = os.path.join(env.get_profile_path(), session.info)
-f = open(session_info_file, w)
+try:
+f = open(session_info_file, w)
+
+cp = ConfigParser()
+cp.add_section('Session')
+cp.set('Session', 'dbus_address',
os.environ['DBUS_SESSION_BUS_ADDRESS'])
+cp.set('Session', 'display',
gtk.gdk.display_get_default().get_name())
+cp.write(f)
-cp = ConfigParser()
-cp.add_section('Session')
-cp.set('Session', 'dbus_address', os.environ['DBUS_SESSION_BUS_ADDRESS'])
-cp.set('Session', 'display', gtk.gdk.display_get_default().get_name())
-cp.write(f)
+f.close()
+except IOError, (errno, sterror):
+logger.error(Could not open session_info_file. %s % sterror)
-f.close()
def _setup_translations():
locale_path = os.path.join(config.prefix, 'share', 'locale')
diff --git a/src/main.py b/src/main.py
index b1ecc93..1899438 100644
--- a/src/main.py
+++ b/src/main.py
@@ -55,15 +55,19 @@ def _save_session_info():
#do not rely on it
#
session_info_file = os.path.join(env.get_profile_path(), session.info)
-f = open(session_info_file, w)
+try:
+f = open(session_info_file, w)
+
+cp = ConfigParser()
+cp.add_section('Session')
+cp.set('Session', 'dbus_address',
os.environ['DBUS_SESSION_BUS_ADDRESS'])
+cp.set('Session', 'display',
gtk.gdk.display_get_default().get_name())
+cp.write(f)
-cp = ConfigParser()
-cp.add_section('Session')
-cp.set('Session', 'dbus_address', os.environ['DBUS_SESSION_BUS_ADDRESS'])
-cp.set('Session', 'display', gtk.gdk.display_get_default().get_name())
-cp.write(f)
+f.close()
+except IOError, (errno, sterror):
+logger.error(Could not open session_info_file. %s % sterror)
-f.close()
def _setup_translations():
locale_path = os.path.join(config.prefix, 'share', 'locale')
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Code name for 9.1.0 ([EMAIL PROTECTED])
greg wrote: I know that downgrade is hard. The great thing is that the XO supports that very elegantly right now! I don't want to lose that. It saved me once when I upgraded to joyride image without a developer key (doh!) and was locked out. but don't confuse saving yourself with a robust procedure that's guaranteed to leave your former environment in a fully useable/functional condition. i don't think that's what we have, or will have, in the foreseeable future. paul Thanks, Greg S greg wrote: Hi Martin, We need keep that capability of upgrade from anywhere to anywhere if at all possible! That is a huge benefit for our customers and for our managing the scope of testing. Even if we can just keep that from any 70x forward it will be a big help. I know we hope 8.2.0 is rock solid but it may not be so we need an option to downgrade safely. downgrade is _very_ difficult to get right. it's a worthy goal, but given our testing resources, and the natural concentration of both developers and testers on the upgrade scenario, i wouldn't promise downgrade. (and from what cscott has said to me every time i mutter under my breath about upgrade oddness, i'm under the impression that the boot to previous version is really only a failsafe mechanism to keep the box running until your upgrade is successful, and isn't intended as a true downgrade. correct me if i'm wrong, scott.) paul ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Write needs your help (was Re: Programming environments on the XO)
For Firefox, that means (for example) that we can use upstreams Awesome Bar instead of reimplementing our own url completion. For abiword, it means acknowledging that a lot of our initial Tubes port was/is simply unnecessary now that we have a stream-based collaboration mechanism, and we can/should be able to strip down Write as a consequence. Iirc, the collaboration code in Write itself is already tiny these days. Or did I miss something spectacular that changes the way collaboration on the XO works? Marc ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: experiencing unexpected OLPC behavior from a misplaced click
On Sat, Jul 19, 2008 at 2:25 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote: But here is a case where I did not wait long enough for the OLPC to draw a pop-up palette, and did not make sure that the cursor was correctly positioned on the appropriate entry in that palette, before I 'clicked'. In other words, it was __I__ who misbehaved. It is my intention to *not* write a ticket on this. Aside from the __user's__ behavior needing to be corrected, I'm not sure what else would be ticketable ?? One of the core principles of usability in design is that it's never the __user's__ fault, as much as they might think it is. Bad design is usually the reason that user's make incorrect decisions/actions. We have an interface-design component, which you could file a ticket for in order to alert us of a problem with the experience of using Sugar. If, on the other hand, you think it's strictly an issue in the time it takes to draw the palette, then perhaps we should be working to optimize that code path some. Specific examples of particularly slow behavior give us places to dive in for profiling. It might help impatient users if palettes (e.g., in the Journal screen) were 'instantaneous' instead of 'slow' -- but I imagine the graphics speed is established by the OLPC processing capability (low power draw is imperative) and the overall Sugar GUI 'Look_And_Feel' design -- and can't be changed. I see nothing in this particular situation for which writing a ticket would improve matters. That said, do you indeed mean that the palette was drawn slowly, or simply that the customary delay on revealing the primary/secondary palettes is too long? These are two very different things. Of note, you can now (almost everywhere...soon truly everywhere...) right-click on a button/object to instantly reveal it's full palette, just like us with standard desktop experience are used to doing to invoke contextual menus. This trick might help in either case. - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Programming environments on the XO
On Thu, 2008-07-17 at 21:41 -0400, Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Sevior wrote: | Hi Folks, | Just so you know. The only reason for #7447 is because we | haven't put the UI in to enable it. I would like an additional control for background color. Eben, what do you think? | I'm not sure different colors for different users is such a good idea | though. The document will quickly become a mess. Though if the kids | want to do this they can. Have you used Gobby? It's the shared editor that people at OLPC _actually_ use, and having per-user background colors is among its key features. Not sure if I read this correctly, but are you implying that Write's collaboration is not used, but Gobby's is? If so, is there any particular collaboration issue/bug that needs my attention? Marc ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Write needs your help (was Re: [sugar] Programming environments on the XO)
On Thu, 2008-07-17 at 10:16 +0200, Tomeu Vizoso wrote: On Thu, Jul 17, 2008 at 8:01 AM, Bobby Powers [EMAIL PROTECTED] wrote: Marc is a bit of a perfectionist so I'm not sure how usable 95% of the work is and whether it could be finished by simply using it and providing bug reports as needed would be. Is this something the community could help with? I know myself and maybe another person or two who would be willing to help if it was clear what else needed to be done. There is 1 issue in abiword's layout engine that prevents this from being finished. Martin and I discussed it on IRC, and we might have a way to do it. It needs some more explicit designing before we should implement it though. As for me being a perfectionist: I don't want to allow hacks in the code that fix a particular problem now, but will haunt us in the future :) Martin and Marc will know better about the syntax highlighting stuff, but if you can help with the very important activity that Write is, please consider properly packaging pyabiword for fedora (and other distros): http://fedoraproject.org/wiki/PackageMaintainers/WishList#OLPC_Wishlist We are using a _really_ old prerelease tarball of abiword: 2.6.0.svn20071127 . The Abi guys have already released 2.6.4 :/ I'm working on pushing proper packages in Fedora as we speak. It could take a few days before it's finished as this is all spare time work. AbiSource Corporation employees (read: me) can be hired though *hint* :-) Marc ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Programming environments on the XO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 J.M. Maurer wrote: | Have you used Gobby? It's the shared editor that people at OLPC | _actually_ use, and having per-user background colors is among its key | features. | | Not sure if I read this correctly, but are you implying that Write's | collaboration is not used, but Gobby's is? Yes. OLPC developers may have been using Write for collaborative document authoring, but I am not aware of it. I am aware of several occasions on which Gobby has been used for this purpose, for example for preparing minutes for a meeting on IRC. | If so, is there any | particular collaboration issue/bug that needs my attention? Not a bug. There are two issues: 1. To the best of my knowledge, Write's collaboration system does not interoperate with any application that is available on non-Sugar desktops. ~ Thus, in order to make use of Write, all participants must have an XO, emulator, or sugar-jhbuild running. I do not see this as a significant obstacle in a Rwandan elementary school, but in the diverse environments of OLPC volunteers, we cannot assume that everyone has easy access to a Sugar instance. In my view, the ultimate solution to this is to push our Telepathy-based collaboration stack upstream into the standard Linux desktop environments. ~ Until then, we should come up with a streamlined Sugar emulator that makes it easy to run an Activity like Write under any standard Linux desktop. 2. Sugar collaboration over the internet requires a specialized Jabber server. It has proven difficult to set up such a server at all, and impossible to set up a server that can be made public without collapsing under the load. Hopefully, after the Gadget work is complete, we will begin to see reliable public collaboration servers appear. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiCZHkACgkQUJT6e6HFtqSjfQCfaoF+5IbBo6aFsRFwX5LV6jOb vmoAoIZ/VhpLCcygbI1eHQa2jjzLo99k =DkVL -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
PlayGo Patches/Commit access
Hello all!
I've recently started learning python and sugar programming and, while
trying to be useful in the meantime, have been tinkering around with the
PlayGo activity.
I have a few patches that add basic scorekeeping, error messages
(like: There already is a stone there!), and small code cleanup. I'd like
to start tackling bigger problems (like collaboration) in the future.
However, cjb told me on #sugar the best way to get this commited is having
commit access to the git repo. I couldn't find a Commit access application
in the wiki, so I'm using part of the project hosting application here :) :
1. Project name : PlayGo
2. Existing website, if any : http://wiki.laptop.org/go/PlayGo
3. One-line description : A Go game activity
6. Committer list:
Username Full name SSH2 key URLE-mail
-
--
#1 aa Andrés Ambrois http://aambrois.homeip.net/site/files/id_rsa.pub
[EMAIL PROTECTED]
11. Translation
[X] Set up the laptop.org Pootle server to allow translation commits to be
made
12. Notes/comments: The project already is on the git repository:
http://dev.laptop.org/git?p=projects/PlayGo;a=summary . But I couldn't find
it in the pootle server. It'd be great to have it added.
Also, I'm Uruguayan so I'll take care of the spanish translation :). If anyone
needs any help with Spanish, I'm usually around at #olpc :D
--
-Andrés
signature.asc
Description: This is a digitally signed message part.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [sugar] Programming environments on the XO
On Sat, 2008-07-19 at 18:02 -0400, Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 J.M. Maurer wrote: | Have you used Gobby? It's the shared editor that people at OLPC | _actually_ use, and having per-user background colors is among its key | features. | | Not sure if I read this correctly, but are you implying that Write's | collaboration is not used, but Gobby's is? Yes. OLPC developers may have been using Write for collaborative document authoring, but I am not aware of it. I am aware of several occasions on which Gobby has been used for this purpose, for example for preparing minutes for a meeting on IRC. But does this hold for kids as well? After all, they are the primary audience for Write. | If so, is there any | particular collaboration issue/bug that needs my attention? Not a bug. There are two issues: 1. To the best of my knowledge, Write's collaboration system does not interoperate with any application that is available on non-Sugar desktops. Well, the AbiCollab plugin existed before Write did, so making Write 'interoperate' with AbiWord would be trivial (in fact, they are exactly the same). ~ Thus, in order to make use of Write, all participants must have an XO, emulator, or sugar-jhbuild running. I do not see this as a significant obstacle in a Rwandan elementary school, but in the diverse environments of OLPC volunteers, we cannot assume that everyone has easy access to a Sugar instance. In my view, the ultimate solution to this is to push our Telepathy-based collaboration stack upstream into the standard Linux desktop environments. ~ Until then, we should come up with a streamlined Sugar emulator that makes it easy to run an Activity like Write under any standard Linux desktop. There is no technical reason at all that Write could not be made to collaborate with normal AbiWord's. Technically, it already works. There is just no UI that currently exposes it. One could for example add a UI that would allow Write to use abicollab.net's service. This way normal AbiWord users could interoperate trivially with Write, on a global scale. This already works *now*, and has been built from the ground up to scale. Millions of users should be no problem at all for the service. What I'm trying to say: Write's collaboration protocol is *exactly* the same as AbiWord's protocol. 2. Sugar collaboration over the internet requires a specialized Jabber server. It has proven difficult to set up such a server at all, and impossible to set up a server that can be made public without collapsing under the load. Hopefully, after the Gadget work is complete, we will begin to see reliable public collaboration servers appear. I've always been of the opinion that using Jabber for this sort of thing was a bad choice. That's why we don't depend on it anymore. Marc - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiCZHkACgkQUJT6e6HFtqSjfQCfaoF+5IbBo6aFsRFwX5LV6jOb vmoAoIZ/VhpLCcygbI1eHQa2jjzLo99k =DkVL -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW sad face doesn't say why
C. Scott Ananian wrote: On Sat, Jul 19, 2008 at 5:52 AM, Mikus Grinbergs [EMAIL PROTECTED] wrote: Yes, I am running a joyride build on that system. This whole business of what indicators need to be placed where is a complete mystery to me. That is why I use a permanent SD card, with my develop.sig on that card -- then if I need to re-flash NAND I don't have to worry about who/how puts a develop.sig file in NAND. [Yes, there was the correct develop.sig for that system in NAND; only the SD card (looked at first by OFW) had the incorrect one.] Mitch, it looks like the real issue here, then, is that OFW doesn't continue to look for develop.sig on other devices once it's found one which doesn't work. If it had, then the presence of a bogus develop.sig on SD wouldn't have preventing OFW from finding the correct develop.sig on NAND and booting the system correctly. I had come to the same conclusion. That sounds like a bug we can fix. (Mikus: the info you're looking for is http://wiki.laptop.org/go/Startup_Diagnosis ) --scott ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW sad face doesn't say why
While Startup_Diagnosis was the repository for that information in the past, the relevant bits for the vast majority of users/repairpeople have been moved to XO_Troubleshooting_PowerOn and I stopped linking to Startup_Diagnosis (which was left as a developer resource.) Much thanks to the authors of Startup_Diagnosis. Cheers, wad On Jul 19, 2008, at 10:45 AM, C. Scott Ananian wrote: On Sat, Jul 19, 2008 at 5:52 AM, Mikus Grinbergs [EMAIL PROTECTED] wrote: Yes, I am running a joyride build on that system. This whole business of what indicators need to be placed where is a complete mystery to me. That is why I use a permanent SD card, with my develop.sig on that card -- then if I need to re-flash NAND I don't have to worry about who/how puts a develop.sig file in NAND. [Yes, there was the correct develop.sig for that system in NAND; only the SD card (looked at first by OFW) had the incorrect one.] Mitch, it looks like the real issue here, then, is that OFW doesn't continue to look for develop.sig on other devices once it's found one which doesn't work. If it had, then the presence of a bogus develop.sig on SD wouldn't have preventing OFW from finding the correct develop.sig on NAND and booting the system correctly. That sounds like a bug we can fix. (Mikus: the info you're looking for is http://wiki.laptop.org/go/Startup_Diagnosis ) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Autosave in 8.2.0?
Tomeu Vizoso wrote: I think that Freedesktop people are moving to a D-Bus based protocol, but don't the status of it. It's actually just GNOME for now... but I'm keeping an eye on it and will add support for that protocol as soon as it's agreed/implemented. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: PlayGo Patches/Commit access
Andrés,
Go is one of my favorite games, so I'm excited to see that someone has
picked up development again! It requires such balance between aggressiveness
and defense, as well as local play vs spreading out on the board - I think
it's a great game for kids to learn. I look forward to trying out a new
version, and I agree that collaboration is an important problem to tackle
soon. Adding GnuGo (http://www.gnu.org/software/gnugo/) support would be a
great addition too. It would be nice to support GnuGo and collaboration over
the same networking framework, but I don't know enough about the
collaboration framework and Bitfrost to know if this is a possibility. GnuGo
generally runs as it's own process and communicates over GTP (
http://www.gnu.org/software/gnugo/gnugo_19.html#SEC196).
It seems there's a lack of documentation for people like yourself who want
to pick up development on an existing activity. Most people who want shell
access to dev.laptop.org also want to host a new activity. I wasn't able to
find anything on the wiki about requesting shell access. Maybe putting a
blurb on the wiki about who to contact would be helpful.
Nate
2008/7/19 Andrés Ambrois [EMAIL PROTECTED]:
Hello all!
I've recently started learning python and sugar programming and, while
trying to be useful in the meantime, have been tinkering around with the
PlayGo activity.
I have a few patches that add basic scorekeeping, error messages
(like: There already is a stone there!), and small code cleanup. I'd like
to start tackling bigger problems (like collaboration) in the future.
However, cjb told me on #sugar the best way to get this commited is having
commit access to the git repo. I couldn't find a Commit access
application
in the wiki, so I'm using part of the project hosting application here :) :
1. Project name : PlayGo
2. Existing website, if any : http://wiki.laptop.org/go/PlayGo
3. One-line description : A Go game activity
6. Committer list:
Username Full name SSH2 key URLE-mail
-
--
#1 aa Andrés Ambrois http://aambrois.homeip.net/site/files/id_rsa.pub
[EMAIL PROTECTED]
11. Translation
[X] Set up the laptop.org Pootle server to allow translation commits to
be
made
12. Notes/comments: The project already is on the git repository:
http://dev.laptop.org/git?p=projects/PlayGo;a=summary . But I couldn't
find
it in the pootle server. It'd be great to have it added.
Also, I'm Uruguayan so I'll take care of the spanish translation :). If
anyone
needs any help with Spanish, I'm usually around at #olpc :D
--
-Andrés
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: OFW sad face doesn't say why
mystery to me. That is why I use a permanent SD card, with my develop.sig on that card -- then if I need to re-flash NAND I don't have to worry about who/how puts a develop.sig file in NAND. Back near Christmas, I put text into the Activation and Developer Keys page recommending that people use the simple and straightforward disable-security command to put their devkey into the boot flash (not the NAND) to avoid all future trouble about keys or security crap, no matter how much you re-flash your NAND. But a certain former security wizard at OLPC removed that recommendation from the Wiki page, thus leading to your current troubles. It's sad watching a good team continue idiotic wrestling with how much cost, trouble, fragility and end-user hassle they can insert into a system that's required by its software licenses and its own philosophy to be wide open to alteration by its users. While Startup_Diagnosis was the repository for that information in the past, the relevant bits for the vast majority of users/repairpeople have been moved to XO_Troubleshooting_PowerOn and I stopped linking to Startup_Diagnosis (which was left as a developer resource.) The other day I added a link to Startup_Diagnosis from XO_Troubleshooting_Guide. The XO_ stuff seemed to be *very* hardware oriented, i.e. if you didn't have a soldering iron in your hand, with the laptop guts opened and a raft of nearby spare parts, it just wasn't useful. I went to the olpc-sf physical meeting today, and tried to help a woman update her XO to something later than the G1G1 650 that she received in January. Someone had showed her yum update but that didn't actually improve anything in the UI or activities. She was at the level that's having trouble remembering to put the space in between su and -l. I absolutely failed to upgrade her -- I couldn't use any automated means like olpc-update, because it required the (%*$[EMAIL PROTECTED](@ USB-only activity upgrade, and it isn't documented what release number you can safely feed the damn thing if you don't have an Activity upgrade pack handy. I followed all the instructions on the Activity upgrade pack, and it failed on me (the un-debuggable secure update script failed to mount my USB stick and panicked, even though in a normal boot, the Journal mounts the same stick as /dev/sda1. Hasn't the author heard of the Python try statement?). Result: She's still running 650, and we'll chat again in a month at the next olpc-sf meeting. Morals: don't assume that your Wiki readers know anything more than the English language (or their native language). And don't make five different ways to upgrade your *(%*%^$ product, each of which only does a third of the job and either depends upon or wipes out what the other ones do. Much thanks to the authors of Startup_Diagnosis. You're welcome. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: PlayGo Patches/Commit access
On Saturday 19 July 2008 21:25:55 Nate Ridderman wrote: Andr�s, Go is one of my favorite games, so I'm excited to see that someone has picked up development again! It requires such balance between aggressiveness and defense, as well as local play vs spreading out on the board - I think it's a great game for kids to learn. I look forward to trying out a new version, and I agree that collaboration is an important problem to tackle soon. Adding GnuGo (http://www.gnu.org/software/gnugo/) support would be a great addition too. It would be nice to support GnuGo and collaboration over the same networking framework, but I don't know enough about the collaboration framework and Bitfrost to know if this is a possibility. GnuGo generally runs as it's own process and communicates over GTP ( http://www.gnu.org/software/gnugo/gnugo_19.html#SEC196). It seems there's a lack of documentation for people like yourself who want to pick up development on an existing activity. Most people who want shell access to dev.laptop.org also want to host a new activity. I wasn't able to find anything on the wiki about requesting shell access. Maybe putting a blurb on the wiki about who to contact would be helpful. Nate Dear Nate, Thanks for your interest! I also like Go a lot, even though I'm very bad at it! :P. I also think it's a great game for kids, most strong go players start very young, and a lot turn pro before age 15. GnuGo integration is certainly the way to go (no pun intended XD), maybe we can use a local gnugo instance speaking GTP with the Activity, for what I see, it shouldn't be too hard. The standard API for sharing (Telepathy tubes) can be used by the host to tell the other player what's going on. I'm just thinking out loud here, as I yet have to delve into the sharing API. Maybe one of the experts here can give us some pointers :). -- -Andrés signature.asc Description: This is a digitally signed message part. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: PlayGo Patches/Commit access
2008/7/19 Andrés Ambrois [EMAIL PROTECTED]:
Hello all!
I've recently started learning python and sugar programming and, while
trying to be useful in the meantime, have been tinkering around with the
PlayGo activity.
Thanks. I wrote to the American Go Association when we started this
project, and they wrote back, We can't tell you how excited we are.
They put a note in their e-mail newsletter about us. When we can take
our software to one of their events, we can talk about getting
assorted game records and go literature into a library content bundle.
I was a 6-kyu player in my youth, according to the teachers in my
school in Korea, where I was a Peace Corps Volunteer. I learned at a
chess club when I was eleven. If I had had access to the literature
available now, I am sure I would have made amateur dan. I am delighted
to see children getting opportunities I didn't have back then, and
being able to help get even more opportunities to way more children.
I can read the Korean and Japanese go literature a little, and I can
provide pointers to a lot of on-line resources.
The Hip-Hop Chess Federation is also interested in our work, as is
International Chess Master Josh Waitzkin, author of The Art of
Learning. Walter Bender started discussions with his book and chess
tutorial software publishers about Free licenses on versions of the
book and software.
I have literature and contacts for a great many more games. We aren't
going to run out of programming exercises for a very long time.
I have a few patches that add basic scorekeeping,
Do you mean scoring at the very end of a game, or scoring games in
matches, or what? Can your code estimate who is ahead in a game?
error messages
(like: There already is a stone there!), and small code cleanup.
Is there a ko rule implemented? Can we get all of the different rule
sets as options (Japan, China, Korea, Ing)?
I'd like
to start tackling bigger problems (like collaboration) in the future.
However, cjb told me on #sugar the best way to get this commited is having
commit access to the git repo. I couldn't find a Commit access application
in the wiki,
Yes, we are very bad at these management issues. Nobody is in charge,
and as far as we can tell, nobody in management notices when nobody is
in charge. %-[
As I understand it, the project manager is supposed to give
participants git access. When a project manager abandons a project, it
often happens that nobody does anything about it.
so I'm using part of the project hosting application here :) :
Exactly right, under the circumstances.
1. Project name : PlayGo
2. Existing website, if any : http://wiki.laptop.org/go/PlayGo
3. One-line description : A Go game activity
6. Committer list:
Username Full name SSH2 key URLE-mail
-
--
#1 aa Andrés Ambrois http://aambrois.homeip.net/site/files/id_rsa.pub
[EMAIL PROTECTED]
11. Translation
[X] Set up the laptop.org Pootle server to allow translation commits to be
made
12. Notes/comments: The project already is on the git repository:
http://dev.laptop.org/git?p=projects/PlayGo;a=summary . But I couldn't find
it in the pootle server. It'd be great to have it added.
Also, I'm Uruguayan so I'll take care of the spanish translation :). If anyone
needs any help with Spanish, I'm usually around at #olpc :D
--
-Andrés
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
--
Edward Cherlin
End Poverty at a Profit by teaching children business
http://www.EarthTreasury.org/
The best way to predict the future is to invent it.--Alan Kay
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
[Server-devel] patched bundles for EduBlog
Hi EduBlog team, have uploaded new 656 bundles for Write and Browse that should be able to respectively import images and upload files regardless of how many files are in the journal: http://dev.laptop.org/~tomeu/Write-54.xo http://dev.laptop.org/~tomeu/Browse-77.xo Note that these bundles shouldn't be installed in any build newer than 656. Please test them and tell me how well they work. About deploying this, I don't know what's the best way, as the activity updating capabilities of 656 seem to be quite weak, for saying something. For testing this, I unzipped the bundles in ~/Activities and then deleted the old bundles in /usr/share/activities. Note that this required root. Perhaps we should change the names and icons and tell the users which ones are the good ones? Regards, Tomeu ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] patched bundles for EduBlog
On Sun, Jul 20, 2008 at 6:39 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: have uploaded new 656 bundles for Write and Browse that should be able to respectively import images and upload files regardless of how many files are in the journal: Cool - thanks! http://dev.laptop.org/~tomeu/Write-54.xo http://dev.laptop.org/~tomeu/Browse-77.xo Note that these bundles shouldn't be installed in any build newer than 656. Please test them and tell me how well they work. About deploying this, I don't know what's the best way, as the activity updating capabilities of 656 seem to be quite weak, for saying something. They Uy team has update scripts on the XOs that poll a central server for updates. I guess it will be for them to deploy the updates to the XOs with a build newer than 656 (IIRC some may have older builds atm). For testing this, I unzipped the bundles in ~/Activities and then deleted the old bundles in /usr/share/activities. Note that this required root. Perhaps we should change the names and icons and tell the users which ones are the good ones? I think assuming that the activities are updated - eitherby tech-savvy users (G1G1, beta testers, devs) or by the regional team is reasonable. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
