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/
_
-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
htt
On Thu, Feb 19, 2009 at 6:14 PM, Michael Stone 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?
I think you (p
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 g
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 automatic
On Thu, Feb 19, 2009 at 10:08 PM, Simon Schampijer 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 there.
I'm rebasin
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 ins
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
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 w
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
2009/2/19 Martin Langhoff :
> On Fri, Feb 20, 2009 at 1:34 AM, Daniel Drake 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 be good for sharing with others...
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 OLP
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
>> p
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 p
On Thu, 19 Feb 2009, Bobby Powers wrote:
> On Thu, Feb 19, 2009 at 1:22 PM, 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 image
Bobby Powers wrote:
> On Thu, Feb 19, 2009 at 1:56 PM, Wade Brainerd 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)
>> {
>>
On Fri, Feb 20, 2009 at 1:34 AM, Daniel Drake 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. I am not sure
On Thu, Feb 19, 2009 at 1:56 PM, Wade Brainerd 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 = *cur++;
>
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 wrote:
> RLE (run length encoding) compresses sequences of identical pixels ("runs")
> as value/count pairs.
> So abbccc would be st
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++ =
Bobby Powers wrote:
> On Thu, Feb 19, 2009 at 1:22 PM, 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
>> u
2009/2/19 Wade Brainerd :
> On Thu, Feb 19, 2009 at 1:22 PM, 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
On Thu, Feb 19, 2009 at 1:22 PM, 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
On Thu, Feb 19, 2009 at 1:22 PM, 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 cod
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
>
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 unc
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 interact
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 wi
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 collab
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 deployment
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
think
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
>> 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
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'
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
Martin Langhoff wrote:
> On Thu, Feb 19, 2009 at 7:20 PM, Simon Schampijer wrote:
>> Martin Langhoff wrote:
>>> On Tue, Feb 17, 2009 at 11:03 AM, Simon Schampijer
>>> wrote:
Well, your call - using the schoolserver url then?
>>> The fqdn from backup server or jabber server. Either will do un
On Thu, Feb 19, 2009 at 05:44, Gary C Martin 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 Sucrose 0.83.x.
Rega
Cool!
Bobby Powers wrote:
> On Wed, Feb 11, 2009 at 2:01 AM, Mitch Bradley 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? I'd like
38 matches
Mail list logo
