Re: Record-55 issue was B4 hardware failure (Was: [sugar] Design Question)
On 21 Jul 2008, at 04:13, John Watlington wrote: > Please remember that the B4 is pre-production hardware. > We lengthened the cable between the camera and the motherboard to > improve this problem > in production. Thanks John, that's good to know, glad it was B4 specific. --Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Record-55 issue was B4 hardware failure (Was: [sugar] Design Question)
On Jul 20, 2008, at 11:07 PM, Gary C Martin wrote: > On 20 Jul 2008, at 22:27, John Watlington wrote: > >> Take a look at: >> http://wiki.laptop.org/go/ >> XO_Troubleshooting_AV#Errors_communicating_with_the_camera >> >> The majority of these problems are due to a latch on the flex >> cable connector coming loose. >> If you disassemble the laptop, and find that it was due to another >> source, pleased either >> add it to the guide or let me know. > > Thanks for the pointer. I've now disassembled, detached and > reattached the camera connector and am back up and running. I could > see no visible signs of any damage, though the ribbon from camera > to motherboard did seem perhaps a little short/tight given the > attachment angle. The camera is working in Record and with the > hardware test, however moderate pressure to the right of the screen > near the camera (i.e. as when you rotate/move the screen from that > side) will cause the image to fail or go purple/green as before, > though it is currently returning to normal when pressure is released. > > So, resolved enough for me to help test software that uses the > camera :-) but I'll need to keep an eye on the pressure applied > when adjusting the screen angle. > > --Gary > > P.S. I'll try and think-up something non-committal for the wiki > page about applying and/or avoiding pressure on the right side of > screen as something to investigate if a camera is playing up. Please remember that the B4 is pre-production hardware. We lengthened the cable between the camera and the motherboard to improve this problem in production. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Record-55 issue was B4 hardware failure (Was: [sugar] Design Question)
On 20 Jul 2008, at 22:27, John Watlington wrote: > Take a look at: > http://wiki.laptop.org/go/XO_Troubleshooting_AV#Errors_communicating_with_the_camera > > The majority of these problems are due to a latch on the flex cable > connector coming loose. > If you disassemble the laptop, and find that it was due to another > source, pleased either > add it to the guide or let me know. Thanks for the pointer. I've now disassembled, detached and reattached the camera connector and am back up and running. I could see no visible signs of any damage, though the ribbon from camera to motherboard did seem perhaps a little short/tight given the attachment angle. The camera is working in Record and with the hardware test, however moderate pressure to the right of the screen near the camera (i.e. as when you rotate/move the screen from that side) will cause the image to fail or go purple/green as before, though it is currently returning to normal when pressure is released. So, resolved enough for me to help test software that uses the camera :-) but I'll need to keep an eye on the pressure applied when adjusting the screen angle. --Gary P.S. I'll try and think-up something non-committal for the wiki page about applying and/or avoiding pressure on the right side of screen as something to investigate if a camera is playing up. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
current "olpc-2.6" git tree Makefile minor patch
Hey. I found there is parenthesis mismatching in olpc-2.6/Makefile, which causes "make help" to fall. I figured it out but do have the permission to git commit. Cheers! diff --git a/Makefile b/Makefile index 9652cc5..5d87deb 100644 --- a/Makefile +++ b/Makefile @@ -1236,7 +1236,7 @@ help: echo '') @$(if $(boards), \ $(foreach b, $(boards), \ - printf " %-24s - Quiet Build for %s\\n" $(subst _defconfig,_silentdefconfig,$(b)) $(subst _defconfig,,$(b));) \ + printf " %-24s - Quiet Build for %s\\n" $(subst _defconfig,_silentdefconfig,$(b)) $(subst _defconfig,,$(b));)) @$(if $(board-dirs), \ $(foreach b, $(board-dirs), \ printf " %-16s - Show %s-specific targets\\n" help-$(b) $(b);) \ -- 续本达 Xu, Benda Academic Talent Program on Fundamental Science of Mathematics and Physics, Tsinghua University, Beijing, P.R.China http://learn.tsinghua.edu.cn:8080/2005012177/index.html http://thirsty.phys.tsinghua.edu.cn/MyWiki/heroxbd ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Record-55 issue was B4 hardware failure (Was: [sugar] Design Question)
Take a look at: http://wiki.laptop.org/go/ XO_Troubleshooting_AV#Errors_communicating_with_the_camera The majority of these problems are due to a latch on the flex cable connector coming loose. If you disassemble the laptop, and find that it was due to another source, pleased either add it to the guide or let me know. Cheers, wad On Jul 20, 2008, at 5:40 PM, Gary C Martin wrote: > On 20 Jul 2008, at 13:40, Bobby Powers wrote: > >> On Sat, Jul 19, 2008 at 7:19 AM, Tomeu Vizoso >> <[EMAIL PROTECTED]> wrote: >>> Works quite well here in a MP with last joyride. Just did some light >>> testing, though. >> >> I've also tested it (lightly) on 3 machines running Joyride ~2170. >> >>> Tomeu >>> >>> On Sat, Jul 19, 2008 at 1:06 PM, Walter Bender >>> <[EMAIL PROTECTED] wrote: Not good news. I don't recall that anything should have changed between B4 and the C series that would have impacted Record. I'll have to check it out on more machines... -walter On Sat, Jul 19, 2008 at 1:14 AM, Gary C Martin <[EMAIL PROTECTED]> wrote: > On 19 Jul 2008, at 00:18, Walter Bender wrote: > >> (Now that we have a reasonably stable joyride-with a working >> Record >> activity again-I'll try to get a quick user study pulled >> together in >> Peru on this topic by someone less bias than myself.) > > Hmmm, not convinced Record-55 is working well enough yet > (Joyride-2174), > unless it's just failing on my B4 hardware. I get everything from > a black > feed, to a green/purple stripy feed. Not managed to actually > record anything > with it yet. Doesn't seem to help launching Record first after a > reboot and > with no other activities (think that was one of the open bugs). >> >> just did that (boot then launch record) and it worked alright for me >> (on a MP machine). >> >> bobby > > Thanks for all the feedback. > > OK, after a lot of testing and looking through logs I finally > accidently stumbled on the problem. It seems to be a HW fault on my > B4. Perhaps a dry solder joint, cracked pcb or camera component not > seated correctly. If I squeeze the right side of the screen, just > below the camera lense, Record-55 starts displaying the video image, > sometimes blank, sometimes green/purple, sometimes back to normal. > Managed to successfully recorded a video clip while the image was > good. > > I'm reasonably handy with a soldering iron so I'll open up the unit > and see if I can see the specific cause. Is there a specific place I > should report this HW issue incase it is more than single an unlucky > occurrence? > > --Gary > > > ___ > 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: Report on `views with many icons' profiling
On Sat, 2008-07-19 at 11:49 +0200, Tomeu Vizoso wrote: > This is really awesome, congrats. > thanks ! > 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. for the ring layout: favorite's view -> list view : avg 0.15 sec list view -> favorite's view : avg 0.15 sec for the freeform layout: favorite's view -> list view : avg 0.16 sec list view -> favorite's view : avg 0.85 sec In fact the 170ms value can be lowered but it makes very difficult to see whether both views are always redrawn or if sometimes one of the two is jumped (in the case of the freeform layout the screen is gray blank most of the time). > 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? Yes, 2481 is the number of times the views were switched. I think one can say that there's only one high-level operation: the call to _set_view in HomeBox.py; what happens as a consequence(/`parallel effect') is the firing of expose events and thus all the time that cProfile assigns to cairo and that sysprof shows in geode_drv.so. One thing I noted particularly is that 77% of the time of _set_view time goes to enable_xo_palette in sugar/view/home/favoritesview.py. It seems to me this last function is creating a new palette at every call (re-doing quite a bit of work scattered on various packages). I guess this can be done just once ? For the ring layout case, all the rest looks ok to me or not worth optimizing. > > Can you please try to assess the impact to the user of any slowness we > may have in there? --ring layout -- Perhaps we should ask the kids if they notice too much delay. I don't think so, this `transition' is much faster than those to other views. --freeform layout-- No need to ask ;) > Which are in your opinion the next steps we should > take? - see if all the time in enable_xo_palette can be spared - use box2d for the freeform layout; I guess that any naive algorithm *handling* collision detection would perform worse than box2d and any non naive one (really handling collisions) isn't worth the time. > Thanks, > > Tomeu > > [Sorry about the late replies] > :) thanks, riccardo > 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_freef
Record-55 issue was B4 hardware failure (Was: [sugar] Design Question)
On 20 Jul 2008, at 13:40, Bobby Powers wrote: > On Sat, Jul 19, 2008 at 7:19 AM, Tomeu Vizoso > <[EMAIL PROTECTED]> wrote: >> Works quite well here in a MP with last joyride. Just did some light >> testing, though. > > I've also tested it (lightly) on 3 machines running Joyride ~2170. > >> Tomeu >> >> On Sat, Jul 19, 2008 at 1:06 PM, Walter Bender <[EMAIL PROTECTED] >> > wrote: >>> Not good news. I don't recall that anything should have changed >>> between B4 and the C series that would have impacted Record. I'll >>> have >>> to check it out on more machines... >>> >>> -walter >>> >>> On Sat, Jul 19, 2008 at 1:14 AM, Gary C Martin >>> <[EMAIL PROTECTED]> wrote: On 19 Jul 2008, at 00:18, Walter Bender wrote: > (Now that we have a reasonably stable joyride-with a working > Record > activity again-I'll try to get a quick user study pulled > together in > Peru on this topic by someone less bias than myself.) Hmmm, not convinced Record-55 is working well enough yet (Joyride-2174), unless it's just failing on my B4 hardware. I get everything from a black feed, to a green/purple stripy feed. Not managed to actually record anything with it yet. Doesn't seem to help launching Record first after a reboot and with no other activities (think that was one of the open bugs). > > just did that (boot then launch record) and it worked alright for me > (on a MP machine). > > bobby Thanks for all the feedback. OK, after a lot of testing and looking through logs I finally accidently stumbled on the problem. It seems to be a HW fault on my B4. Perhaps a dry solder joint, cracked pcb or camera component not seated correctly. If I squeeze the right side of the screen, just below the camera lense, Record-55 starts displaying the video image, sometimes blank, sometimes green/purple, sometimes back to normal. Managed to successfully recorded a video clip while the image was good. I'm reasonably handy with a soldering iron so I'll open up the unit and see if I can see the specific cause. Is there a specific place I should report this HW issue incase it is more than single an unlucky occurrence? --Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: LZO support
On Sun, Jul 20, 2008 at 04:38:36PM -0400, Erik Garrison wrote: > How are you producing the test data (test.dat) used by the test? Excuse me. You clearly stated that in your email! > > On Sun, Jul 20, 2008 at 10:57:37AM +0200, NoiseEHC wrote: > > The program needs a test.dat file, I have used "cat */*>test.dat" in > > "/var/lib" which gave me a 22 MB file (the code handles a max of 40 MB). > > The results are consistent with Erik's results. Since ZLIB has a > > compression level parameter, and LZO has different compressor types, I > > will test those as well. > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: LZO support
How are you producing the test data (test.dat) used by the test? On Sun, Jul 20, 2008 at 10:57:37AM +0200, NoiseEHC wrote: > Okay, I have become a little more advanced lately, and was able to > compile the kernel zlib and lzo in userspace (last year I gave up...). > > So here is the code (with results, the lib file is the compiled lzo 2.03): > http://wiki.laptop.org/images/5/5b/Zlibtest5.tar.gz > > Since I did not find any assembly compressor support (only > decompressor), I do not know what did I talked about last time. It could > have been that I have been dreaming about that... > > The program needs a test.dat file, I have used "cat */*>test.dat" in > "/var/lib" which gave me a 22 MB file (the code handles a max of 40 MB). > The results are consistent with Erik's results. Since ZLIB has a > compression level parameter, and LZO has different compressor types, I > will test those as well. > > Now I think that jffs2 (or any other flash filesystem) should use LZO to > store the data, so if the limit is the flash write speed then it could > write twice as fast. Later, when there is ample power in the battery and > no cpu utilization, it should recompress the data either using a better > LZO or by ZLIB (of course only those files which are old enough, so it > would not recompress files which will be modified soon). > > And the results: > started with block size == 4096 > > LZO test > in size: 22987994 > 22987994 -> 11575529 (50.354672%) > 1.96 seconds -> 11.185234 MB/sec > 11575529 -> 22987994 > 0.75 seconds -> 29.230745 MB/sec > compared 22987994 bytes OK > > LZO asm test > in size: 22987994 > 22987994 -> 11575529 (50.354672%) > 1.93 seconds -> 11.359098 MB/sec > 11575529 -> 22987994 > 0.49 seconds -> 44.740936 MB/sec > compared 22987994 bytes OK > > ZLIB test > in size: 22987994 > 22987994 -> 8982973 (39.076802%) > 9.81 seconds -> 2.234767 MB/sec > 8982973 -> 22987994 > 2.75 seconds -> 7.972022 MB/sec > compared 22987994 bytes OK > > > Greg Smith wrote: >> Hi Erik, >> >> Can you design a test case or two to test the performance of these >> compression schemes? >> >> Thanks, >> >> Greg 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: [sugar] Autosave in 8.2.0?
On Sun, Jul 20, 2008 at 5:44 PM, Bert Freudenberg <[EMAIL PROTECTED]> wrote: > Am 17.07.2008 um 07:37 schrieb Bert Freudenberg: > >> 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? >> >> - Bert - > > > Thanks for not answering, and not updating the API doc, and me having > to dig through Sugar patches to find out how this works. Bert, you should know better than others how things are here. We cannot manage to do the things we know that must be done, much less we can do those properly. If I was in any regular job, I would limit myself to do what I can, and do it right. Here we just cannot behave like that. You are right to be frustrated by this situation, but please don't ask us to do more than what is in our hands. If you know anyone who would like to join us in this craziness, please point them to http://www.laptop.org/en/jobs.shtml . Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Autosave in 8.2.0?
On Sun, Jul 20, 2008 at 5:44 PM, Bert Freudenberg <[EMAIL PROTECTED]> wrote: > Thanks for not answering, Hmm? Both Tomeu and me answered. http://lists.laptop.org/pipermail/devel/2008-July/016914.html http://lists.laptop.org/pipermail/devel/2008-July/016951.html > and not updating the API doc, The time I can devote to OLPC is *very* limited these days and I had no time until today to even check this API was working properly... I just finished up the python Activity bits and I have a patch up for review. I will try to update the doc on monday. > and me having > to dig through Sugar patches to find out how this works. > > I updated the doc: > http://wiki.laptop.org/go/Low-level_Activity_API#D-Bus_Methods > === >org.laptop.Activity.SyncData() >Called when the laptop is about to shutdown, reboot, or suspend. The > activity must save its state in the datastore. > === > Apparently this does not send a reason for having to sync - IMHO > suspend is not as severe a reason as impending shutdown/reboot so an > activity might want to choose to not save on suspend if suspends are > as frequent as we anticipate. This code never went in actually... See the mails I referenced. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Autosave in 8.2.0?
Am 17.07.2008 um 07:37 schrieb Bert Freudenberg: > 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? > > - Bert - Thanks for not answering, and not updating the API doc, and me having to dig through Sugar patches to find out how this works. I updated the doc: http://wiki.laptop.org/go/Low-level_Activity_API#D-Bus_Methods === org.laptop.Activity.SyncData() Called when the laptop is about to shutdown, reboot, or suspend. The activity must save its state in the datastore. === Apparently this does not send a reason for having to sync - IMHO suspend is not as severe a reason as impending shutdown/reboot so an activity might want to choose to not save on suspend if suspends are as frequent as we anticipate. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: running speech-dispatcher as non-root using setuid on XO and accompanying security issues
Hi James, The point I was trying to make was that the Sugar API itself could have > removed the burden of setting these options from the developer. > Yes that is indeed what is happening :). And there is no API call involved whatsoeverl with the present design :). Perhaps once the code is released you'll get an idea whats exactly happening. > An Activity could also, using the API, find out what the default values are > without having to look at speechd.conf. > I think it would be useful for the activity developer in certain instances to get the default speech synthesis settings. I'll look into this requirement and see if we can provide some methods through sugar for this purpose. > Or the Sugar Activity base class could automatically start up a speech > client and give the Activity developer simple methods to use it in his > application, or even automatically speech enable any Activity so that for > instance the contents of the control with the focus could be spoken, or > whatever it is that screen readers for the blind do. > Well, the main reason why sugar does not/should not handle requests for speech-synthesis from all Activities is that we will need to re-write a lot of code to handle priorities/serializing speech synth requests from multiple activities/maintaining Activitiy-specific settings (these were issues with the initial DBUS API that we created, and the main reason for shifting to speech-dispatcher). All these features are already available in speech-dispatcher and hence communicating directly with the speech-dispatcher server instead through sugar seems more optimal. Also if Activities had to connect to a client that was started by sugar would mean that sugar will have to provide the Callbacks that are at present returned by speech-dispatcher directly to the Activity. Thats why its best that Activities connect themselves to speech-dispatcher and not communicate through sugar. Automatically speech-enabling an activity is something I will be exploring, however, from initial analysis its not that straight forward. How sugar will "hack" into Activities and pull the data relevant for speech-synth is what needs to be analyzed for this purpose. I understood that the Sugar developers wanted to provide text to speech > support to all Activities, even those written before TTS was available. To > do that you would have to change the Sugar base classes, etc. anyway. > Are you suggesting that just like the Activity Tool bars etc are provided to Sugar Activities primitively, speech-synth should be provided primitively when each Activity starts? Cheers! Hemant ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: experiencing unexpected OLPC behavior from a misplaced click
Hi Mikus, I didn't mean to put you in a difficult position. I assume that if the XO doesn't do what the user expects its a bug (maybe a low priority one). No problem if you don't want to file this one. Can you write a brief blurb in the 8.2.0 release notes to preserve the knowledge. Maybe just text, no bug ID in http://wiki.laptop.org/go/Release_Notes/8.2.0#Notable_Open_Bugs_In_This_Release I'm not trying to push you into anything you are not comfortable with. You're making a great contribution and its making a big difference to the quality of the product! Please keep the comments and work coming, regardless of any communication faux pas on my part. Thanks, Greg S Date: Sat, 19 Jul 2008 14:25:39 -0400 From: Mikus Grinbergs <[EMAIL PROTECTED]> Subject: experiencing unexpected OLPC behavior from a misplaced click To: devel@lists.laptop.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: PlayGo Patches/Commit access
2008/7/20 Andrés Ambrois <[EMAIL PROTECTED]>: > 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 :). Normally I would recommend to move the part of gnugo that can be of interest to embedders to a shared lib and then do python bindings for it. But looks like gnugo already has covered the embedding use case with GTP: http://en.wikipedia.org/wiki/Go_Text_Protocol So that should just work. Good luck, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: LZO support
Okay, I have become a little more advanced lately, and was able to compile the kernel zlib and lzo in userspace (last year I gave up...). So here is the code (with results, the lib file is the compiled lzo 2.03): http://wiki.laptop.org/images/5/5b/Zlibtest5.tar.gz Since I did not find any assembly compressor support (only decompressor), I do not know what did I talked about last time. It could have been that I have been dreaming about that... The program needs a test.dat file, I have used "cat */*>test.dat" in "/var/lib" which gave me a 22 MB file (the code handles a max of 40 MB). The results are consistent with Erik's results. Since ZLIB has a compression level parameter, and LZO has different compressor types, I will test those as well. Now I think that jffs2 (or any other flash filesystem) should use LZO to store the data, so if the limit is the flash write speed then it could write twice as fast. Later, when there is ample power in the battery and no cpu utilization, it should recompress the data either using a better LZO or by ZLIB (of course only those files which are old enough, so it would not recompress files which will be modified soon). And the results: started with block size == 4096 LZO test in size: 22987994 22987994 -> 11575529 (50.354672%) 1.96 seconds -> 11.185234 MB/sec 11575529 -> 22987994 0.75 seconds -> 29.230745 MB/sec compared 22987994 bytes OK LZO asm test in size: 22987994 22987994 -> 11575529 (50.354672%) 1.93 seconds -> 11.359098 MB/sec 11575529 -> 22987994 0.49 seconds -> 44.740936 MB/sec compared 22987994 bytes OK ZLIB test in size: 22987994 22987994 -> 8982973 (39.076802%) 9.81 seconds -> 2.234767 MB/sec 8982973 -> 22987994 2.75 seconds -> 7.972022 MB/sec compared 22987994 bytes OK Greg Smith wrote: > Hi Erik, > > Can you design a test case or two to test the performance of these > compression schemes? > > Thanks, > > Greg 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
