On Wed, Mar 11, 2009 at 4:13 PM, Daniel Drake wrote:
> 2009/3/1 Bobby Powers :
> > I can't seem to get ul-warning to come up properly, so if anyone can
> > tell me what I'm doing wrong that would be great. I've got it to work
> > by manually placing some symlinks in /etc/rc0.d and /etc/rc6.d, bu
2009/3/1 Bobby Powers :
> I can't seem to get ul-warning to come up properly, so if anyone can
> tell me what I'm doing wrong that would be great. I've got it to work
> by manually placing some symlinks in /etc/rc0.d and /etc/rc6.d, but
> neither Scott's nor my chkconfig comments seem to work.
He
Hi Bobby,
On 1 Mar 2009, at 21:44, Bobby Powers wrote:
> I've fixed a few issues, packaged up bootanim-2.3-1, and (finally)
> actually ran some benchmarks. Results (all times in seconds):
>
> fresh os801, from pressing the power button to appearance of sugar's
> prompt for name screen
> 80
> 79
On Sun, Mar 01, 2009 at 04:44:01PM -0500, Bobby Powers wrote:
> I can't seem to get ul-warning to come up properly, so if anyone can
> tell me what I'm doing wrong that would be great.
What actually goes wrong? Is ul-warning executed?
--
James Cameronmailto:qu...@us.netrek.org http://qu
On 1 Mar 2009, at 21:44, Bobby Powers wrote:
> I've fixed a few issues, packaged up bootanim-2.3-1, and (finally)
> actually ran some benchmarks. Results (all times in seconds):
>
> fresh os801, from pressing the power button to appearance of sugar's
> prompt for name screen
> 80
> 79
> 78
>
> wi
I've fixed a few issues, packaged up bootanim-2.3-1, and (finally)
actually ran some benchmarks. Results (all times in seconds):
fresh os801, from pressing the power button to appearance of sugar's
prompt for name screen
80
79
78
with rhgb-client renamed so that init can't find it:
69
68
and wi
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
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, 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 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
>> 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'
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
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 to recreate the
tests. It sounds like you did
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.
With boot animation, OS build 7 (an older 8.2.1 candidate) takes 60
seconds from first dot (indicating OFW transfer to Linux) to Sugar
"prompt for your
27 matches
Mail list logo
