Re: XOs with no sound

2008-12-31 Thread Philipp Kocher
Alsa keeps the values in memory and writes it into the 
/etc/alsa/asound.state file during shutdown. The file has a new 
timestamp, so someone is writing into it at least.

Sorry my master asound.state file was working but not standard. I have 
now 5 values that are different between a standard XO (build 767) and a 
no sound XO

Master Mono Playback Switch: is false should be true (line 50)
Master Mono Playback Volume: is 0 should be 28 (line 61)
PCM Playback Switch: is false:false should be true:true (line 178)
PCM Playback Volume: is 0:0 should be 22:22 (line 190)
Capture Volume: is 0:0 should be 15:15 (line 287)

I hope that helps.

Regards,
Philipp

James Cameron wrote:
 On Wed, Dec 31, 2008 at 09:22:17AM +0700, Philipp Kocher wrote:
 It seems like always the same 7 values are wrong.
 
 Which 7 values?
 
 1. Copy /etc/alsa/asound.state of a healthy XO to USB flash drive
 
 Okay, so it is in /etc/alsa on those builds?  Are you sure that file is
 in use?  On the build I'm using, there is a file in
 /etc/alsa/asound.state that is not updated, as well as one in
 /etc/asound.state .  (I would have thought /var would have been more
 appropriate).
 
 Your process has two steps and requires a working XO.  I think it is
 even simpler to
 
   alsactl -f /dev/null restore
 
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XOs with no sound

2008-12-31 Thread James Cameron
On Wed, Dec 31, 2008 at 03:52:05PM +0700, Philipp Kocher wrote:
 Alsa keeps the values in memory and writes it into the  
 /etc/alsa/asound.state file during shutdown. The file has a new  
 timestamp, so someone is writing into it at least.

Okay, that must be a build 767 thing.  Recent development builds use
/etc/asound.state only.  I've checked only the development builds at
this stage.

 Master Mono Playback Switch: is false should be true (line 50)
 Master Mono Playback Volume: is 0 should be 28 (line 61)

These two should have no effect.  I've tested that they have no effect
on audio playback.  The method I used was to temporarily install the OSS
module, and run a background process writing noise to the output.  Thus:

modprobe snd-pcm-oss
dd if=/dev/urandom of=/dev/dsp 

While this is running I then manipulated the controls using alsamixer.
The Master Mono Playback controls did nothing.

(Incidentally, the volume control keys on the keyboard changed the
Master control only, not the Master Mono control, and not the PCM
control.)

 PCM Playback Switch: is false:false should be true:true (line 178)

In false:false state, this switch prevents all sound output from
activities and applications.  The noise test above fell silent.

 PCM Playback Volume: is 0:0 should be 22:22 (line 190)

In 0:0 state, the audio is less loud, but not eliminated.  The noise
test continued to generate audio, but I needed to set the Master control
(not the Master Mono control) to at least 50%.

 Capture Volume: is 0:0 should be 15:15 (line 287)

In this state, the noise test audio is unchanged.  This would affect
sound capture using microphone though.

 I hope that helps.

Yes, it does.  It shows the immediate cause of the problem was that the
PCM Playback Switch was turned off.  That the Capture control was also
changed is interesting.

I've searched the installed activities on a development build here for
references to the amixer command.  The only activity that I've found it
used in is Measure.

Measure.activity/toolbar_side.py ... changes the Capture control.

Measure.activity/audiograb.py ... changes the PCM Playback Switch.

Is Measure being used?  Can you reproduce the symptom on a working XO by
asking for a shutdown while Measure is running?  What version of Measure
is being used?

Version 20 of Measure attempts to restore PCM to 70 on quit.  Does the
symptom clear if Measure is started and then quit?

-- 
James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: New joyride build 2613

2008-12-31 Thread Morgan Collett
On Tue, Dec 30, 2008 at 21:42, Mikus Grinbergs mi...@bga.com wrote:
 -sugar 0.83.4-2.olpc4
 +sugar 0.83.3-1.olpc4

 What was wrong with sugar 0.83.4 ?

I also wonder why sugar and sugar-toolkit were reverted.

 Why not start putting 0.84 in Joyride ?

0.84 will only be released in early March:
http://sugarlabs.org/go/DevelopmentTeam/Release/Roadmap

0.83.x is a series of unstable or developer builds leading up to the
0.84 stable release.

Regards
Morgan
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: performance work

2008-12-31 Thread Neil Graham
On Tue, 2008-12-30 at 20:41 -0700, Jordan Crouse wrote:
  I'm curious as to why reads from video memory are so slow,  On standard
  video cards it's slow because there is quite a division between the CPU
  and the video memory,  but on the geode isn't the video memory shared in
  the same SDRAM as Main memory. 
 
 It is, in that they share the same physical RAM chips, but they are 
 controlled by different entities - one is managed by the system memory 
 controller and the other is handled by the GPU.   At start up time, the 
 memory is carved up by the firmware, and after the top of system RAM is 
 established, video and system memory behave for all intents and purposes 
 like separate components.  Put simply, there is no way to directly 
 address video memory from the system memory.  Access to the video memory 
 has to happen via PCI cycles, and for obvious reasons the active video 
 region has the cache disabled, accounting for relatively slow readback.

That makes my brain melt, you can't address it even though it's on the
same chip!?!  Even as far back as the PCjr the deal was that sharing
video memory cost some performance due to taking turns with cycles but
it gave some back with easy access to the memory for all.   Has the
geode cunningly managed to provide a system that combines all the
disadvantages of separate memory with all the disadvantages of shared?

One wonders what would happen if you wired some lines to the chips so
that the memory appeared in two places,  would you get access to the ram
(with the usual 'you pays your money, you takes your chances' caveats
about coherency)

I'm not a hardware person, but that all just seems odd.

 That said, the read from memory performance is still worse  then you
 might expect - I never really got a good answer from
 the silicon guys as to why. 
 
being hit with the full sdram latency every access maybe?

Is it feasible to try with caches enabled and require the software to
flush as needed.
 


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


anonymous gray activity circles

2008-12-31 Thread Tony Anderson
I believe that these circles result from the activity initiating a new 
top-level window. Sugar provides an activity with a window. It is 
expected that the activity will pack it's widgets into a vbox in that 
window. Imported activities naturally create a top-level window.

Tony


Message: 3
Date: Tue, 30 Dec 2008 21:37:47 -0500
From: Chris Marshall jns-cmarsh...@comcast.net
Subject: Re: anonymous gray activity circles
To: g...@laptop.org
Cc: OLPC Development devel@lists.laptop.org
Message-ID: 495adafb.40...@comcast.net
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Greg Smith wrote:
   Hi Chris,
  
   Unless someone else has seen this, I think we need more detail on 
how to
   reproduce it.

os767 and Firefox-6 activity
start firefox
click on a file link to download
exit firefox after
left a gray circle

(Actually, it almost always leaves behind one
or more circles but I have not done exhaustive
testing to determine how many or under what
conditions.  It would be easier to start from
an understanding of how the circle gets there
to begin with (what is being used to trigger
the circle's appearance)...

--Chris

   Can you write down the steps it takes to get a gray activity circle?
   Include the version of XO software you are running:
   http://wiki.laptop.org/go/What_release_am_I_running%3F
  
   It may be that you are double clicking to start an activity. That can
   cause a second activity instance to try and start then fail and 
leave an
   icon in the frame. That's the only thing that comes to mind without 
more
   detail.
  
   Thanks,
  
   Greg S
  
   *
  
   From: jns-cmarsh...@comcast.net
   Subject: anonymous gray activity circles
   To: devel@lists.laptop.org
  
   Is there a way to prevent the
   anonymous gray activity circles
   in the frame?  Some X apps
   seem to accumulate circles with
   no way i have been able to
   determine to remove dead ones.
   I tried to google the list but was
   not able to generate useful links.
  
   --Chris


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: performance work

2008-12-31 Thread Jordan Crouse
Neil Graham wrote:
 On Tue, 2008-12-30 at 20:41 -0700, Jordan Crouse wrote:
 I'm curious as to why reads from video memory are so slow,  On standard
 video cards it's slow because there is quite a division between the CPU
 and the video memory,  but on the geode isn't the video memory shared in
 the same SDRAM as Main memory. 
 It is, in that they share the same physical RAM chips, but they are 
 controlled by different entities - one is managed by the system memory 
 controller and the other is handled by the GPU.   At start up time, the 
 memory is carved up by the firmware, and after the top of system RAM is 
 established, video and system memory behave for all intents and purposes 
 like separate components.  Put simply, there is no way to directly 
 address video memory from the system memory.  Access to the video memory 
 has to happen via PCI cycles, and for obvious reasons the active video 
 region has the cache disabled, accounting for relatively slow readback.
 
 That makes my brain melt, you can't address it even though it's on the
 same chip!?!  Even as far back as the PCjr the deal was that sharing
 video memory cost some performance due to taking turns with cycles but
 it gave some back with easy access to the memory for all.   Has the
 geode cunningly managed to provide a system that combines all the
 disadvantages of separate memory with all the disadvantages of shared?
 
 One wonders what would happen if you wired some lines to the chips so
 that the memory appeared in two places,  would you get access to the ram
 (with the usual 'you pays your money, you takes your chances' caveats
 about coherency)
 
 I'm not a hardware person, but that all just seems odd.

You are missing the point - this model wasn't designed so that the 
system could somehow sneakily address video memory, it was designed so 
that the system designer could eliminate the need for the added cost, 
expense and real estate for a separate bank of memory chips.  See also
http://en.wikipedia.org/wiki/Shared_Memory_Architecture.

 That said, the read from memory performance is still worse  then you
 might expect - I never really got a good answer from
 the silicon guys as to why. 

 being hit with the full sdram latency every access maybe?
 
 Is it feasible to try with caches enabled and require the software to
 flush as needed.

Ask around - I don't think that you'll find anybody too keen on having 
the X server execute a cache invalidate a half dozen times a second.

Anyway, you are getting distracted and solving the wrong problem.  You 
should be more concerned about limiting the number of times that the X 
server reads from video memory rather then worrying about how fast the 
read is.

If I can rant for a second (and this isn't targeted at Neil 
specifically, but just in general), but this is another in a list of 
more or less hard constraints that the current XO design has. 
Throughout the history of the project, it seems to me that developers 
have been more biased toward trying to eliminate those constraints 
rather then making the software work in spite of them.  The processor is 
too slow - everybody immediately wants to overclock.  There is too 
little memory - enter a few dozen schemes for compressing it or swaping it.

The XO platform has limitations, most of which were introduced by choice 
for power or cost reasons.  The limitations are clearly documented and 
were known by all, at least when the project started.  The understanding 
was that the software would have to be adjusted to fit the hardware, not 
the other way around.  Over time, we seem to have lost that understanding.

Software engineering is hard - software engineering for resource 
restrained systems is even harder.  In this day and age geeks like us 
have been accustomed to always having the latest and greatest hardware 
at our fingertips, and so the software that we write is also for the 
latest and greatest.  And so, when confronted with a system such as the 
XO, our first instinct is to just plop our software on it and watch it 
go.  That attitude is further re-enforced by the fact that the Geode is 
x86 based - just like our desktops.  It should just work, right?  We 
know better - or at least, we should know better.

The solution to the performance problems is good old fashioned elbow 
grease.  We have to take our software that is naturally biased toward 
the year 2007 and make it work for the year 1995.  Thats going to 
involve fixing bugs in the drivers, but also re-thinking how the 
software works - and finding situations where the software might be 
inadvertently doing the wrong thing. Let me give you an example - as 
recently as X 1.5, operations involving an a8 alpha mask worked like this:

* Draw a 1x1 rectangle in video memory containing the source color for 
the operation
* Read the source color from video memory
* Perform the mask operation with the source color

This isn't smart for any kind of processor or GPU, running at 2 Ghz or 

1cc network outage

2008-12-31 Thread Henry Edward Hardy
We had an interruption in network services at 1cc from about 10:30 am to
11:15 am this morning. This affected the reverse proxy server serving the
wiki as well as phone and network services at 1cc.

--HH.

-- 
We've heard that a million monkeys at a million keyboards could produce the
complete works of Shakespeare; now, thanks to the Internet, we know that is
not true.
-- Robert Wilensky, 1996
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


9.1.0 meeting - 2PM US ET Today 12/31

2008-12-31 Thread Greg Smith
Hi All,

I'll be on IRC freenode.net #olpc-meeting at 2PM US ET today.

Minutes of last weeks meeting and this weeks agenda are here:
http://lists.laptop.org/pipermail/devel/2008-December/022085.html

We can table the agenda and call it a year unless there are updates or 
other comments.

Happy New Year everyone.

We are a phenomenal engineering team and community network of experts in 
every aspect of life and learning.

What a great year!

Let's do it again next year.

Thanks,

Greg S
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: performance work

2008-12-31 Thread Michael Stone
On Wed, Dec 31, 2008 at 09:20:27AM -0700, Jordan Crouse wrote:
The solution to the performance problems is good old fashioned elbow 
grease These are the sorts of things that we need to find and
squash - and yes, it will be very time consuming and a little boring.

Several anecdotes for your amusement and reflection:

* When was the last time someone posted to devel asking: what is the
   right algorithm or datastructure for task ?

* When was the last time someone publicly analyzed the upper or lower
   bounds on the bandwidth, latency, or quantity of messages necessary to
   accomplish task ?

* When was the last time that you published a performance goal for your
   software? Did you hit it? Did anyone notice?

Michael

P.S. - Charles Leiserson once remarked that performance is like a
currency which programmers trade for (all) other worthwhile things like
schedule targets, scope of features, other resource consumption, various
kinds of security, etc [1]. This suggests that one would do better to
ask for performance or  but not both. Think of Blizzard.

[1] http://www.catonmat.net/blog/mit-introduction-to-algorithms-part-one/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: performance work

2008-12-31 Thread Greg Smith
Hi All,

Great thread. I don't know the history but I completely agree with 
Jordan. A dedicated team of engineers takes at least two years of 
software to optimize available resources.

The main memory - video memory debate is age old. Until someone builds a 
better programming language and architecture for addressing the DCON 
frame buffer directly we need to optimize the architecture we have.

Moore's law is against us but we have 500,000 units in the field and can 
more than double that in 12 months (Moore be damned :-). Nail this 
problem quickly and we gain an industry-wide edge.

I collected related performance threads in the specification section here:
http://wiki.laptop.org/go/Feature_roadmap/General_UI_sluggishness

Did I miss instructions on how to determine which Cairo benchmarks are 
being called most often by sugar?

Can someone report how often the top 10 offenders below are called by 
using Sugar:
http://wiki.laptop.org/go/Feature_roadmap/General_UI_sluggishness#Test_data_comparison

Ask if its not clear. First steps may be documented here: 
http://wiki.laptop.org/go/Performance_tuning#Other

Our development bottleneck could be X-Windows (and Cairo) people. Can 
someone send an e-mail to the right list and ask for help?

Jordan told us which X functions he thinks will pay off. See 
http://wiki.laptop.org/go/Feature_roadmap/General_UI_sluggishness#X_optimization_suggestions

That's not asking for new functions, just calling well know ones. I'm 
optimistic compositing hooks will be a huge win

Thanks,

Greg S

 Date: Wed, 31 Dec 2008 09:20:27 -0700
 From: Jordan Crouse jor...@cosmicpenguin.net
 Subject: Re: performance work
 To: l...@screamingduck.com
 Cc: devel@lists.laptop.org, g...@laptop.org
 Message-ID: 495b9bcb.2010...@cosmicpenguin.net
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 
 Neil Graham wrote:
 On Tue, 2008-12-30 at 20:41 -0700, Jordan Crouse wrote:
 I'm curious as to why reads from video memory are so slow,  On standard
 video cards it's slow because there is quite a division between the CPU
 and the video memory,  but on the geode isn't the video memory shared in
 the same SDRAM as Main memory. 
 It is, in that they share the same physical RAM chips, but they are 
 controlled by different entities - one is managed by the system memory 
 controller and the other is handled by the GPU.   At start up time, the 
 memory is carved up by the firmware, and after the top of system RAM is 
 established, video and system memory behave for all intents and purposes 
 like separate components.  Put simply, there is no way to directly 
 address video memory from the system memory.  Access to the video memory 
 has to happen via PCI cycles, and for obvious reasons the active video 
 region has the cache disabled, accounting for relatively slow readback.
 That makes my brain melt, you can't address it even though it's on the
 same chip!?!  Even as far back as the PCjr the deal was that sharing
 video memory cost some performance due to taking turns with cycles but
 it gave some back with easy access to the memory for all.   Has the
 geode cunningly managed to provide a system that combines all the
 disadvantages of separate memory with all the disadvantages of shared?

 One wonders what would happen if you wired some lines to the chips so
 that the memory appeared in two places,  would you get access to the ram
 (with the usual 'you pays your money, you takes your chances' caveats
 about coherency)

 I'm not a hardware person, but that all just seems odd.
 
 You are missing the point - this model wasn't designed so that the 
 system could somehow sneakily address video memory, it was designed so 
 that the system designer could eliminate the need for the added cost, 
 expense and real estate for a separate bank of memory chips.  See also
 http://en.wikipedia.org/wiki/Shared_Memory_Architecture.
 
 That said, the read from memory performance is still worse  then you
 might expect - I never really got a good answer from
 the silicon guys as to why. 

 being hit with the full sdram latency every access maybe?

 Is it feasible to try with caches enabled and require the software to
 flush as needed.
 
 Ask around - I don't think that you'll find anybody too keen on having 
 the X server execute a cache invalidate a half dozen times a second.
 
 Anyway, you are getting distracted and solving the wrong problem.  You 
 should be more concerned about limiting the number of times that the X 
 server reads from video memory rather then worrying about how fast the 
 read is.
 
 If I can rant for a second (and this isn't targeted at Neil 
 specifically, but just in general), but this is another in a list of 
 more or less hard constraints that the current XO design has. 
 Throughout the history of the project, it seems to me that developers 
 have been more biased toward trying to eliminate those constraints 
 rather then making the software work in spite of them.  The processor is 
 

Re: performance work

2008-12-31 Thread Wade Brainerd
I agree with Jordan.  You just have to sit down and do the work to optimize
the code, either finding the fastest path through hardware and software
stack.
I've rewritten Bounce twice now for performance just to hold on to 20fps on
the XO.  Colors! has been through many performance iterations as well
(compare v1 and v13 with large brushes).  I've just had my hat handed to me
by Cairo for Typing Turtle as well (with the hand display enabled, you can
type about 1WPM).  So I'm looking forward to rewriting my keyboard rendering
to deal with that.

If you have an issue with the performance of the XO, just spend the time by
yourself to analyze it and fix it, talking about it accomplishes nothing.
 If you find a solution that would help others, post it.

-Wade
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: performance work

2008-12-31 Thread Greg Smith
Hi All,

Answering two e-mails on one pass.

I agree, its hard work.

Wade,

I believe this thread is about optimizing the XO OS and GUI. That's why 
I call the requirement General_UI_sluggishness.

Optimizing applications is yet another challenge. I'm all for people 
doing that hard work and documenting it so the next person doesn't have 
to re-invent the wheel. Your performance URL is already posted to the 
page in the tools section. Let me know if you have any other links 
(GIT URLs?) or e-mails I should make easily accessible.

Michael,

The performance goal I worked out with Eben is on the page already. It 
could be better but its a start.

Lots of people have noticed.

Neil and Jordan analyzed which Cairo calls are causing the most trouble 
and how long they take.  I also broke John's suggestions in to general 
areas: http://wiki.laptop.org/go/Feature_roadmap/General_UI_sluggishness

Could use more editing (e.g. swap suggestions may belong in memory, file 
read/write caching should be added etc.).

You're just scratcing the surface with BW, latency and messages. CPU 
cycles, process priority, caching, bottleneck definition, instruction 
sets and compilers, word/block/sector size usage, and if you're really 
hard core rows and columns are all optimizable.

If you have an algorithm improvement to offer, I'm all ears.

When we have a critical mass of time from professional engineers we can 
improve performance. Until then it waits and the users wait too.

Let's build on what we have, we're making progress.

Thanks,

Greg S



On Wed, Dec 31, 2008 at 09:20:27AM -0700, Jordan Crouse wrote:
  The solution to the performance problems is good old fashioned elbow 
grease These are the sorts of things that we need to find and
  squash - and yes, it will be very time consuming and a little boring.

Several anecdotes for your amusement and reflection:

* When was the last time someone posted to devel asking: what is the
   right algorithm or datastructure for task ?

* When was the last time someone publicly analyzed the upper or lower
   bounds on the bandwidth, latency, or quantity of messages necessary to
   accomplish task ?

* When was the last time that you published a performance goal for your
   software? Did you hit it? Did anyone notice?

Michael

P.S. - Charles Leiserson once remarked that performance is like a
currency which programmers trade for (all) other worthwhile things like
schedule targets, scope of features, other resource consumption, various
kinds of security, etc [1]. This suggests that one would do better to
ask for performance or  but not both. Think of Blizzard.

[1] http://www.catonmat.net/blog/mit-introduction-to-algorithms-part-one/

Wade Brainerd wrote:
 I agree with Jordan.  You just have to sit down and do the work to optimize
 the code, either finding the fastest path through hardware and software
 stack.
 I've rewritten Bounce twice now for performance just to hold on to 20fps on
 the XO.  Colors! has been through many performance iterations as well
 (compare v1 and v13 with large brushes).  I've just had my hat handed to me
 by Cairo for Typing Turtle as well (with the hand display enabled, you can
 type about 1WPM).  So I'm looking forward to rewriting my keyboard rendering
 to deal with that.
 
 If you have an issue with the performance of the XO, just spend the time by
 yourself to analyze it and fix it, talking about it accomplishes nothing.
  If you find a solution that would help others, post it.
 
 -Wade
 
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: performance work

2008-12-31 Thread Wade Brainerd
Hi Greg,
I think there's actually a lot of overlap between activity performance work
and OS performance work.

The bottlenecks I encountered and resolved were in PyGTK, Cairo, the Python
interpreter, librsvg, etc.  These are the many of the same libraries which
are believed to cause sluggishness in the core UI.

Unfortunately, most of my performance success was had by replacing the
aforementioned libraries with custom C++ extension modules.  Each time I
remove some Cairo code and replace it with custom C++ code, the activity
gets faster.  I wouldn't advocate the Sugar developers take that approach :)

-Wade

On Wed, Dec 31, 2008 at 4:01 PM, Greg Smith gregsmitho...@gmail.com wrote:

 Hi All,

 Answering two e-mails on one pass.

 I agree, its hard work.

 Wade,

 I believe this thread is about optimizing the XO OS and GUI. That's why I
 call the requirement General_UI_sluggishness.

 Optimizing applications is yet another challenge. I'm all for people doing
 that hard work and documenting it so the next person doesn't have to
 re-invent the wheel. Your performance URL is already posted to the page in
 the tools section. Let me know if you have any other links (GIT URLs?) or
 e-mails I should make easily accessible.

 Michael,

 The performance goal I worked out with Eben is on the page already. It
 could be better but its a start.

 Lots of people have noticed.

 Neil and Jordan analyzed which Cairo calls are causing the most trouble and
 how long they take.  I also broke John's suggestions in to general areas:
 http://wiki.laptop.org/go/Feature_roadmap/General_UI_sluggishness

 Could use more editing (e.g. swap suggestions may belong in memory, file
 read/write caching should be added etc.).

 You're just scratcing the surface with BW, latency and messages. CPU
 cycles, process priority, caching, bottleneck definition, instruction sets
 and compilers, word/block/sector size usage, and if you're really hard core
 rows and columns are all optimizable.

 If you have an algorithm improvement to offer, I'm all ears.

 When we have a critical mass of time from professional engineers we can
 improve performance. Until then it waits and the users wait too.

 Let's build on what we have, we're making progress.

 Thanks,

 Greg S

 

 On Wed, Dec 31, 2008 at 09:20:27AM -0700, Jordan Crouse wrote:
  The solution to the performance problems is good old fashioned elbow
 grease These are the sorts of things that we need to find and
  squash - and yes, it will be very time consuming and a little boring.

 Several anecdotes for your amusement and reflection:

 * When was the last time someone posted to devel asking: what is the
  right algorithm or datastructure for task ?

 * When was the last time someone publicly analyzed the upper or lower
  bounds on the bandwidth, latency, or quantity of messages necessary to
  accomplish task ?

 * When was the last time that you published a performance goal for your
  software? Did you hit it? Did anyone notice?

 Michael

 P.S. - Charles Leiserson once remarked that performance is like a
 currency which programmers trade for (all) other worthwhile things like
 schedule targets, scope of features, other resource consumption, various
 kinds of security, etc [1]. This suggests that one would do better to
 ask for performance or  but not both. Think of Blizzard.

 [1] http://www.catonmat.net/blog/mit-introduction-to-algorithms-part-one/

 Wade Brainerd wrote:

 I agree with Jordan.  You just have to sit down and do the work to
 optimize
 the code, either finding the fastest path through hardware and software
 stack.
 I've rewritten Bounce twice now for performance just to hold on to 20fps
 on
 the XO.  Colors! has been through many performance iterations as well
 (compare v1 and v13 with large brushes).  I've just had my hat handed to
 me
 by Cairo for Typing Turtle as well (with the hand display enabled, you can
 type about 1WPM).  So I'm looking forward to rewriting my keyboard
 rendering
 to deal with that.

 If you have an issue with the performance of the XO, just spend the time
 by
 yourself to analyze it and fix it, talking about it accomplishes nothing.
  If you find a solution that would help others, post it.

 -Wade


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: performance work

2008-12-31 Thread Mikus Grinbergs
What I find discouraging is mentally comparing the responsiveness 
in use of F10-based Joyride builds against what I remember (perhaps 
mistakenly) of responsiveness with Ship.2 builds.  [I don't 
currently have a Ship.2 system on hand for direct comparison.]

Examples of my (non-performance) experience with recent Joyrides :

  -  I use an external USB keyboard.  In Terminal, I type in a short 
command and press enter.  It can take more than half a second (or 
even longer) for the cursor to move from the line it was on (where I 
typed) to the start of a new screen line.

  -  I click on an Activity icon in Home View or Journal.  Up to TWO 
seconds later, the XO begins showing (and pulsing) the screen that 
is supposed to indicate Activity being launched.  [The only way I 
can get 'instant' response from the XO is to elicit the drop-down 
palette from the Activity icon, then click in that palette on Start 
(if in Home View) or on Resume (if in Journal).  Having done so, the 
vanishing of that palette is satisfyingly responsive.  (Of course, 
if I were to miss the palette entirely due to my shaky hands when 
I click, the palette vanishes without the Activity being launched.)]

mikus

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Installing Flash on the OLPC

2008-12-31 Thread genesee

Dear =S Page,

As the social analog of town drunk on this list, I am flattered as hell to
be lumped in with the smart set!

¬°Gracias!
   genesee


S Page-2 wrote:
 
 you're just making the smart smarter still.
 

-- 
View this message in context: 
http://n2.nabble.com/Installing-Flash-on-the-OLPC-tp2088845p2098061.html
Sent from the Software development mailing list archive at Nabble.com.

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Flash wiki entries

2008-12-31 Thread Carlos Nazareno
 gently Many more people are going to read
 http://wiki.laptop.org/go/Adobe_Flash page than follow this mailing
 list.  Your effect on XO users by only answering problems here is
 limited, you're just making the smart smarter still.

 Just in time for New Year's resolutions:  edit the wiki page first.

Hey Skier! Your wish is my command :)

Just did a massive update to the Adobe Flash page, hope to update the
main Flash Player and Gnash pages as well soon, pending spare time off
work.

I hope this doesn't offend anyone, but I de-emphasized Webkinz.com
with the newer edits because the old Adobe Flash entry looked like a
massive Webkinz advertisement :P

Can I resurrect the Gnash/Gstreamer thread here? I sure could use help
with getting mp3 sound working on Gstreamer in so we can put a
step-by-step entry for people who are not as well-versed in Linux
(that includes me!) on how to get sound working at
http://wiki.laptop.org/go/Gnash

The old thread here was left unresolved and hanging and I still
haven't gotten Gnash sound/Gstreamer mp3 working on the XO 8.2.0.

It's been suggested at the Gnash dev mailing list that alternative
sound codecs such as AMR be used instead by authors (I used it before
for a Flash Lite game because MP3 playback wasn't supported on some
phones) but frankly this is wishful thinking as almost every single
.SWF out there is published with MP3 sound.

Anyway, for the benefit of the folks who prefer to use Gnash to Adobe
Flash, it would be really great if we could outline that sound howto
on the Gnash wiki entry :)

 Anyway, why does this wiki page tell you to enter
   sudo su -
 when every other page I've seen says
   su -  (or su -l)
 ? `sudo su -` seems redundant.

Fixed it.

Happy New Year, all!

-Naz

-- 
Carlos Nazareno
http://www.object404.com
--
interactive media specialist
zen graffiti studios
http://www.zengraffiti.com
--
Philippine Flash ActionScripters
http://www.phlashers.com
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Server-devel] XS 0.5.1-dev03 with ejabberd goodness, kernel bling, Access Point workingness... looking for xmas testers

2008-12-31 Thread Anna
2008/12/31 David Leeming leem...@pipolfastaem.gov.sb


 I want to do a new install but can you let me know if I can install Samba
 and how to set up access to a shared folder on a Windows PC on the LAN as I
 have a large content collection and it takes ages to copy it all again by
 flash drive. Or maybe there is a better way to do it.

I was curious about that, too, so I looked into other alternatives as Samba
can sometimes be a pain to configure.  It's also yet another service to run
on the XS.

I found an sshfs utility for Windows called Dokan.  And it's free for
non-commercial purposes!  This might make more sense than fooling with
Samba, especially if you only have one Windows machine to deal with.

The Dokan library and Doken SSHFS packages are at
http://dokan-dev.net/en/download/.  I also had to install the Microsoft
Visual C++ package mentioned on that site, the .NET Framework (which was 55
MB), and Windows Installer 3.1.

There's a nice GUI to enter in your ssh login info and mount points.  I
connected and now /home/anna on the XS is mounted read/write on N: on an XP
machine.

Anna Schoolfield
Birmingham
___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel