Cool!
Bobby Powers wrote:
On Wed, Feb 11, 2009 at 2:01 AM, Mitch Bradley w...@laptop.org wrote:
I just measured the time taken by the boot animation by the simple
technique of renaming /usr/bin/rhgb-client so the initscripts can't find it.
how did you measure exactly? stopwatch?
On Thu, Feb 19, 2009 at 05:44, Gary C Martin g...@garycmartin.com wrote:
Actually that raises a question, did Gadget make it in to the 8.2.1
build? Or is this still a future maybe? I take it it is/would be a
Sugar future feature/dependancy?
It was not included in 8.2.1. It's implemented in
Martin Langhoff wrote:
On Thu, Feb 19, 2009 at 7:20 PM, Simon Schampijer si...@schampijer.de wrote:
Martin Langhoff wrote:
On Tue, Feb 17, 2009 at 11:03 AM, Simon Schampijer si...@schampijer.de
wrote:
Well, your call - using the schoolserver url then?
The fqdn from backup server or jabber
Some more progress. I had used libsugarize.so from this link
http://www.catmoran.com/olpc/libsugarize.so to sugarise my activity. When I
first started developing the activity, it wouldn't run on the XO unless I
preloaded this so. On a hunch I removed this preload and now my application
launches on
mitch wrote:
Bobby Powers wrote:
- its designed to be as light as possible, using syscalls instead of
libc functions as much as possible (the only thing we use libc for is
string comparison, which could be replaced with a local function).
while its written like this, I haven't worked
I just measured the time taken by the boot animation by the simple
technique of renaming /usr/bin/rhgb-client so the initscripts can't find it.
how did you measure exactly? stopwatch? I'd like to recreate the
tests. It sounds like you did this on a freshly flashed system?
There were a
Wade,
I found out about schoolserver.media.mit.edu from the Wiki, and I got it
set up successfully. It looks like a lot of stuff is better documented
on the Wiki than it was in my pre-basement-flood days. I'll try to look
there first in the future. I'm going to try to get Hello Mesh working
Gary,
I only have one XO. I do all my development work on a couple of Fedora
10 boxes running Sugar. These two boxes are connected to the same
router using Ethernet cables. It has been my experience that the only
way they can collaborate is through the jabber server, and that makes me
Hi all.
Thank you Michael and Pia for this..
I have to say that although these questions and concerns are indeed needed ,
they are only counting one side of the history, like asking what would be
the best for OLPC to give or the resources that OLPC can give..this is bad
centered,
OLPC
On 19.02.2009, at 16:32, James Simmons wrote:
Gary,
I only have one XO. I do all my development work on a couple of
Fedora
10 boxes running Sugar. These two boxes are connected to the same
router using Ethernet cables. It has been my experience that the only
way they can collaborate
Tony,
It looks like every day I make some progress. I finally figured out
that the reason text to speech was not pausing between sentences and
paragraphs was that I was stripping all the punctuation out of the text
before sending it on to espeak. I have to create an XML document marked
up
Hey there,
I think you're in fairly undocumented territory trying to develop a real
activity using libsugarize.so. But to your credit, you seem to have a
pretty good understanding of how the X protocol works (beyond mine anyway!).
Have you seen this page before? It describes how Sugar interacts
I'd suggest just uncompressing the various image files and re-timing
as a start. The initial implementation was uncompressed, but people
complained about space usage on the emulator images (which are
uncompressed). The current code supports both uncompressed and
compressed image formats. For
C. Scott Ananian wrote:
I'd suggest just uncompressing the various image files and re-timing
as a start. The initial implementation was uncompressed, but people
complained about space usage on the emulator images (which are
uncompressed). The current code supports both uncompressed and
On Thu, Feb 19, 2009 at 1:22 PM, C. Scott Ananian csc...@laptop.org wrote:
I'd suggest just uncompressing the various image files and re-timing
as a start. The initial implementation was uncompressed, but people
complained about space usage on the emulator images (which are
uncompressed).
On Thu, Feb 19, 2009 at 1:22 PM, C. Scott Ananian csc...@laptop.org wrote:
I'd suggest just uncompressing the various image files and re-timing
as a start. The initial implementation was uncompressed, but people
complained about space usage on the emulator images (which are
uncompressed).
2009/2/19 Wade Brainerd wad...@gmail.com:
On Thu, Feb 19, 2009 at 1:22 PM, C. Scott Ananian csc...@laptop.org wrote:
I'd suggest just uncompressing the various image files and re-timing
as a start. The initial implementation was uncompressed, but people
complained about space usage on the
RLE (run length encoding) compresses sequences of identical pixels (runs)
as value/count pairs.
So abbccc would be stored as 1a 10b 3c.
The decompressor looks like:
while (cur end)
{
unsigned short count = *cur++;
unsigned short value = *cur++;
while (count--)
*dest++ =
Oh, and you can feed one of the 565 files through my 'rle.c' program to see
the compression ratio firsthand.
On Thu, Feb 19, 2009 at 1:56 PM, Wade Brainerd wad...@gmail.com wrote:
RLE (run length encoding) compresses sequences of identical pixels (runs)
as value/count pairs.
So abbccc
On Thu, Feb 19, 2009 at 1:56 PM, Wade Brainerd wad...@gmail.com wrote:
RLE (run length encoding) compresses sequences of identical pixels (runs)
as value/count pairs.
So abbccc would be stored as 1a 10b 3c.
The decompressor looks like:
while (cur end)
{
unsigned short count =
On Fri, Feb 20, 2009 at 1:34 AM, Daniel Drake d...@laptop.org wrote:
Which bits did you think were missing?
Quite a few bits. Happy to discuss over the phone or to draft more
formal notes (that'd take a bit longer).
Michael seems keen on working with us on developing this into an XS
feature.
Bobby Powers wrote:
On Thu, Feb 19, 2009 at 1:56 PM, Wade Brainerd wad...@gmail.com wrote:
RLE (run length encoding) compresses sequences of identical pixels (runs)
as value/count pairs.
So abbccc would be stored as 1a 10b 3c.
The decompressor looks like:
while (cur end)
{
da...@lang.hm wrote:
if you have the diff of the images, do you need to read from the
framebuffer at all? since you know what you put there, and know what
you want to change, can't you just write your changed information to
the right place?
The framebuffer in this case is serving as
On Thu, 19 Feb 2009, Mitch Bradley wrote:
da...@lang.hm wrote:
if you have the diff of the images, do you need to read from the
framebuffer at all? since you know what you put there, and know what you
want to change, can't you just write your changed information to the right
place?
On Feb 18, 2009 at 10:24 PM, John Watlington wrote:
I don't see how a non-profit can do this, as requires financing at
risk, and
staffing for uncertain demand.Let me know when you have the capital.
Absolutely true and I'm not sure the capital would be enough. Its
difficult to imagine OLPC
2009/2/19 Martin Langhoff martin.langh...@gmail.com:
On Fri, Feb 20, 2009 at 1:34 AM, Daniel Drake d...@laptop.org wrote:
Which bits did you think were missing?
Quite a few bits. Happy to discuss over the phone or to draft more
formal notes (that'd take a bit longer).
More formal notes would
da...@lang.hm wrote:
right, but why read the current framebuffer? you don't touch most of
it, you aren't going to do anything different based on what's there
(you are just going to overlay your new info there) so all you really
need to do is to write the parts tha need to change.
You
On Thu, 19 Feb 2009, Robert D. Fadel wrote:
On Feb 18, 2009 at 10:24 PM, John Watlington wrote:
I don't see how a non-profit can do this, as requires financing at
risk, and
staffing for uncertain demand.Let me know when you have the capital.
Absolutely true and I'm not sure the capital
On Thu, 19 Feb 2009, Mitch Bradley wrote:
da...@lang.hm wrote:
right, but why read the current framebuffer? you don't touch most of it,
you aren't going to do anything different based on what's there (you are
just going to overlay your new info there) so all you really need to do is
to
da...@lang.hm wrote:
d) compile the delta set into the client program.
That works, but
1) It requires more work from the VM system on each invocation of the
client program, which is now 1.x MB instead of 4K.
2) If a deployment wants to change the image set, it needs a compiler
toolchain
On Thu, Feb 19, 2009 at 10:08 PM, Simon Schampijer si...@schampijer.de wrote:
Ok, I pushed to browse git master now. Do you have a way to test if it is
working fine against a schoolserver or should I create you the 0.82 xo
bundle?
I have a git checkout - but on the 8.2.x so master won't work
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2657
Changes in build 2657 from build: 2656
Size delta: 0.00M
-olpc-update 2.17-1
+olpc-update 2.18-1
--- Changes for olpc-update 2.18-1 from 2.17-1 ---
+ Support multiple keys
+ Support multiple keys
--
This mail was
http://xs-dev.laptop.org/~cscott/xo-1/streams/staging/build33
Changes in build 33 from build: 32
Size delta: 0.00M
-olpc-update 2.17-1
+olpc-update 2.18-1
--- Changes for olpc-update 2.18-1 from 2.17-1 ---
+ Support multiple keys
+ Support multiple keys
--
This mail was automatically
On Thu, Feb 19, 2009 at 6:14 PM, Michael Stone mich...@laptop.org wrote:
6. Questions:
* Does this analysis hold water?
Seems to make sense, and looks like the strategies are quite rational.
* Is there anything we could spend our time on which would yield a
greater return on investment?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have been testing libtheora-1.0 on a MP XO. On build 767, using F9's
gcc-4.3, I compiled libtheora with CFLAGS=-march=geode. I tested
encode, with the command
time encoder_example -v 1 coastguard_cif.y4m /dev/null
using the test video from
On Fri, Feb 20, 2009 at 12:28:42AM -0500, Benjamin M. Schwartz wrote:
GCC 4.3 evidently does not do a very good job of optimizing for geode.
What percentage of CPU time was spent in libtheora?
--
James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/
2009/2/18 Martin Langhoff martin.langh...@gmail.com:
the original plan was to rig all that from the anti-theft proto. On
the server side, there's a lot of work to do to make that happen. On
the laptop side, it's unclear. For many months my emails to cscott on
the matter went unanswered, I
37 matches
Mail list logo
