Re: No surprise on memory

2008-12-22 Thread Artem Bityutskiy
Jim Gettys wrote:
 Note that I'm not advocating in favor of soldered NAND - in fact I've 
 been one of the leading proponents of migrating to an SD-based storage 
 solution.  I'm just pointing out that, if you're willing to buy an SD 
 card now (which is necessary for the SD-based swap solution), then you 
 are probably willing to buy one later.

 Soldered down SD, however may be an intermediate point; may fewer wires
 than a conventional chip.

There is eMMC for purposes like this, even.


-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Jabber client activity

2008-12-22 Thread Tomeu Vizoso
[adding sugar-devel as this is of interest also outside OLPC]

On Sun, Dec 21, 2008 at 23:49, Mildred Ki'Lya ml.mildred...@gmail.com wrote:
 Hello everyone,

 I'm new here, and I came interested in the OLPC project because it's a
 wonderful computer, very well integrated, and I just had one via the
 European G1G1 project. And now, I thought I could contribute :)

 I wanted to know if there was any project of creating an activity that
 would be a jabber client. If so, could I help, where is it? And if not,
 perhaps I should start one.

Actually, having Chat working as a regular IM client would be very
interesting and may not be a very big project. The only missing piece
is being able to add contacts to your roster other than through the
mesh view.

I think the idea is to add a palette option somewhere that allows you
to type or paste a contact ID so it will appear in your friends view.
Then you would get presence notification, the ability to chat and
transfer files, and with some extra work, a/v conversations.

If someone would like to jump on this challenge, it's there waiting for you!

Regards,

Tomeu

 I just tried to run gajim in sugar,  but it seems because the $HOME gets
 defined in a sandboxed environment that is erased each time, so I can't
 keep the configuration :/ On the other hand, I think that writing from
 scratch a jabber client would require much work, and time I don't really
 have. What do you think is appropriate?

 Thanks :)


 Mildred

 --
 Mildred Ki'Lya
 �q─ mildred593@online.fr ──
 │ Jabber, GoogleTalk: mild...@jabber.fr
 │ Site: http://ki.lya.online.fr  GPG ID: 9A7D 2E2B
 │ Fingerprint: 197C A7E6 645B 4299 6D37 684B 6F9D A8D6 9A7D 2E2B

 ___
 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-devel] Jabber client activity

2008-12-22 Thread Morgan Collett
On Mon, Dec 22, 2008 at 11:52, Tomeu Vizoso to...@sugarlabs.org wrote:
 [adding sugar-devel as this is of interest also outside OLPC]

 On Sun, Dec 21, 2008 at 23:49, Mildred Ki'Lya ml.mildred...@gmail.com wrote:
 Hello everyone,

 I'm new here, and I came interested in the OLPC project because it's a
 wonderful computer, very well integrated, and I just had one via the
 European G1G1 project. And now, I thought I could contribute :)

 I wanted to know if there was any project of creating an activity that
 would be a jabber client. If so, could I help, where is it? And if not,
 perhaps I should start one.

 Actually, having Chat working as a regular IM client would be very
 interesting and may not be a very big project. The only missing piece
 is being able to add contacts to your roster other than through the
 mesh view.

Chat is at least a partial IM client, with Neighborhood View as a
graphical buddy list. It all runs on Jabber, but only has partial
interoperability with non-Sugar Jabber clients.

With the current stable version of Sugar (0.82 in OLPC 8.2.0) you
cannot see non-Sugar clients in Neighborhood View, but that was an
issue which we have subsequently fixed, and in OLPC 9.1.0 or Sugar
0.84 you will see non-Sugar IM clients as buddies in Neighborhood
View.

If a non-Sugar client finds a Sugar user (XO or other) on a Jabber
server and sends them an IM, it will show up in Sugar as a
notification on the screen corner for a few seconds, and then be
visible as a Chat invitation in the frame. (A better notification
system in Sugar will improve its visibility when it happens...)
Accepting the invitation opens Chat with a one-to-one connection to
the message sender.

Regular use of Chat as a shared activity creates a Jabber MUC (multi
user chat room).

The missing piece at this stage is allowing the Sugar system to
initiate a one-to-one Chat with a non-Sugar IM client on the Jabber
server, perhaps through Neighborhood View.

 I think the idea is to add a palette option somewhere that allows you
 to type or paste a contact ID so it will appear in your friends view.
 Then you would get presence notification, the ability to chat and
 transfer files, and with some extra work, a/v conversations.

If you can search for users on the server with Gadget, then OLPC 9.1.0
and Sugar 0.84 will have the ability to: See non-Sugar IM clients as
buddies, friend them so they will show up again on Neighborhood View
in future, and search for them on the server.

Perhaps we just need to ensure that the search can be by JID even if
it's by nick for the regular use case.

Regards
Morgan

 If someone would like to jump on this challenge, it's there waiting for you!

 Regards,

 Tomeu

 I just tried to run gajim in sugar,  but it seems because the $HOME gets
 defined in a sandboxed environment that is erased each time, so I can't
 keep the configuration :/ On the other hand, I think that writing from
 scratch a jabber client would require much work, and time I don't really
 have. What do you think is appropriate?

 Thanks :)


 Mildred

 --
 Mildred Ki'Lya
 �q─ mildred593@online.fr ──
 │ Jabber, GoogleTalk: mild...@jabber.fr
 │ Site: http://ki.lya.online.fr  GPG ID: 9A7D 2E2B
 │ Fingerprint: 197C A7E6 645B 4299 6D37 684B 6F9D A8D6 9A7D 2E2B

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


 ___
 Sugar-devel mailing list
 sugar-de...@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel


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


Re: Jabber client activity

2008-12-22 Thread Guillaume Desmottes
Le lundi 22 décembre 2008 à 10:52 +0100, Tomeu Vizoso a écrit :
 [adding sugar-devel as this is of interest also outside OLPC]
 
 On Sun, Dec 21, 2008 at 23:49, Mildred Ki'Lya ml.mildred...@gmail.com wrote:
  Hello everyone,
 
  I'm new here, and I came interested in the OLPC project because it's a
  wonderful computer, very well integrated, and I just had one via the
  European G1G1 project. And now, I thought I could contribute :)
 
  I wanted to know if there was any project of creating an activity that
  would be a jabber client. If so, could I help, where is it? And if not,
  perhaps I should start one.
 
 Actually, having Chat working as a regular IM client would be very
 interesting and may not be a very big project. The only missing piece
 is being able to add contacts to your roster other than through the
 mesh view.

Sugar *is* a jabber client, not only Chat but the whole sugar/sucrose.
Chat is used to chat (!) with your contacts, the mesh view is your buddy
list and VideoChat is suppose to be used for... audio/video chat.
The Telepathy framework offers you the possibility to split the
different features of your client (roster, chat, audio chat, logger,
etc) into different applications.

One big missing piece is the ability to add contacts by entering their
jid and UI to accept/decline friend requests. This is
https://dev.laptop.org/ticket/8841

Another one is the ability to run more than one account/connection. Main
problem here is the UI. How should we display that? Tabbed mesh views
maybe?

Once this is done, you'll be able to use your normal IM accounts on
Sugar and be able to chat with them using Chat, send them files using
journal object sharing and call them with VideoChat.

Actually, as Sugar is using Telepathy, it's much more than a Jabber
client. By being a real Telepathy client, it could become a IRC, MSN,
SIP (or whatever protocol) client!
I talked about that during one of my Sugarcamp conf:
http://people.collabora.co.uk/~cassidy/talks/sugar-camp-futur-of-collab.pdf

We'll be happy to help any contributor interested in working on this.
Just come and say hi on #sugar or #telepathy.
But *please*, let's not waste time and resources on implementing a gajim
or pidgin activity. We already have an existing flexible and performant
IM framework; we just need to integrate it properly in Sugar to offer a
rocking user experience.


G.

 I think the idea is to add a palette option somewhere that allows you
 to type or paste a contact ID so it will appear in your friends view.
 Then you would get presence notification, the ability to chat and
 transfer files, and with some extra work, a/v conversations.
 
 If someone would like to jump on this challenge, it's there waiting for you!


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


Re: [Server-devel] Fwd: [ejabberd] Fix or workaround for EJAB-731 - shared roster fails to show new user accts

2008-12-22 Thread Guillaume Desmottes
Le samedi 20 décembre 2008 à 18:13 -0200, Martin Langhoff a écrit :
 Hi Guillaume,
 
Hi Martin,

 Badlop has posted a new patch that I want to test. It conflicts with a
 patch you've introduced to our build,
 recent_online_and_rearby_groups_updated.diff -- two questions
 
  - Do we need this patch to interop with 8.2 correctly? What does it do?

IIRC, this patch introduced new type of shared roster: @online@,
@recent@ and @nea...@. Vanilla ejabberd only supports @a...@.

  - Have you tested vanilla ejabberd for the bugs reported in EJAB-730/731?

Yes. That's why I always mention @all@ instead of @online@ in the
reports, but the problems were the same.

 In the short term, I'm building an rpm to test here - with lop's
 patch, and without yours. Have made any attempt at a merge - but can
 try if you tell me it's needed. (Not that I know much erlang or
 ejabberd internals, but getting there. Help welcome.)
 

I think if things are working fine with this patch using the @all@
shared roster, there is good chance that fixes @online@ as well.


G.

 cheers,
 
 
 m
 
 -- Forwarded message --
 From: Martin Langhoff martin.langh...@gmail.com
 Date: Sat, Dec 20, 2008 at 6:09 PM
 Subject: Re: [ejabberd] Fix or workaround for EJAB-731 - shared roster
 fails to show new user accts
 To: ejabb...@jabber.ru
 
 
 On Sat, Dec 20, 2008 at 11:20 AM, Martin Langhoff
 martin.langh...@gmail.com wrote:
  - is there an altrnative workaround, something to force ejabberd to
  re-scan its list of users without a restart?
 
  Yes, check
  https://support.process-one.net/browse/EJAB-731
  That new patch for ejabberd 2.0.2 fixes this and other problems
  related to Shared Roster. There is a comment at the bottom of the page
  with explanation of the changes.
 
  If you try the patch, please tell me if all seems to work correctly.
 
  Right - following that discussion, you are saying that the patch that
  fixed EJAB-71 should fix it, correct? But we are seeing the problem on
 
 I misread initially - thinking of the discussion in EJAB-730, that
 points to EJAB-71. I've now seen the new patch and I've built a new
 rpm with it. Will be testing tomorrow or Monday.
 
 cheers,
 
 
 
 m
 --
  martin.langh...@gmail.com
  mar...@laptop.org -- School Server Architect
  - ask interesting questions
  - don't get distracted with shiny stuff  - working code first
  - http://wiki.laptop.org/go/User:Martinlanghoff
 
 
 

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


Re: performance work

2008-12-22 Thread Greg Smith
Hi Jordan,

Looks like we made a little more progress on graphics benchmarking. See 
Neil's results below.

I updated the feature page with the test results so far:
http://wiki.laptop.org/go/Feature_roadmap/General_UI_sluggishness

What's next?

Do we know enough now to target a particular section of the code for 
optimization?

Thanks,

Greg S

***

Subject: Re: performance work
To: Wade Brainerd wad...@gmail.com
Cc: OLPC Development devel@lists.laptop.org, g...@laptop.org
Message-ID: 494e16aa.3070...@skierpage.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Wade Brainerd wrote:
On Tue, Dec 16, 2008 at 7:08 PM, Neil Graham l...@screamingduck.com

   Is there a build of cairo that can produce a log of what calls 
are used
   in typical XO use?

http://www.cairographics.org/FAQ/#performance_concerns says
Cairo provides a cairo-trace utility (currently only available from the
git development tree, but is planned for inclusion with Cairo 1.10)
(I think Joyride builds include Cairo 1.8.0, latest released Cairo is 1.8.6)

   Some good ways to find out are located here:
  
   http://wiki.laptop.org/go/Performance_tuning

I mentioned this.

--
=S

**
Neil said:
  I recommend running the Cairo benchmarks on the XO again with
  acceleration turned off in the X driver. This will give you a good
  indication of which operations are being accelerated and which are not.

Done.

http://screamingduck.com/Cruft/cairo_benchmark_XO_NoAccel.txt


At a cursory glance it looks like an overall improvement without
acceleration except for lines-xlib, add-xlib and over-xlib

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


Re: olpc-update from 703 to 8.2 wipes out Journal

2008-12-22 Thread Martin Langhoff
On Wed, Dec 17, 2008 at 2:38 PM, Ties Stuij cjst...@gmail.com wrote:
 I updated an XO from 703 to 8.2 with the latest olpc-update, and to my
 disappointment the journal content was wiped. Is this to be expected?

It shouldn't wipe the Journal, but if the new Journal code finds an
error when dealing with the journal data it will _keep_ the old
journal, but put it aside, and create a new empty journal.

In other words, the Jounral view may not be showing your data, but the
files aren't lost if you care about them. Look into your
~/.sugar/default directory, and you'll see both the old and new
journal directories (datastore and datastore-$timestamp.

It'd be interesting to rename the old journal dir back to 'datastore'
and restart sugar. It will probably find the same error again, but now
you have a chance to capture the log and share it in this list, so we
can help diagnose what happened there.

cheers,



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Problems revealed by a report of detailed changes to 8.2.1 tickets.

2008-12-22 Thread Michael Stone
Ed,

I made http://dev.laptop.org/report/39?TIME=80 in the image of one
of my old 8.2.0 reports. (TIME is the number of seconds of history that
you want to view so that URL shows you all changes to tickets with
milestone 8.2.1 made in the last 9-10 days).

At the time of this writing, over the past week, 7 out of 16 tickets
have been updated, primarily by Deepak and Scott with some additional
questions and discussion from Sayamindu, Bert, and Simon.

I know that I find this degree of recorded progress less than
satisfactory. Do you feel the same way? If so, you need to know that I
feel neither empowered nor requested to push this along as fast as it
can go. (Does anyone else feel similarly?)

Consequently, if you want my full potential contribution to 8.2.1 to be
realized, I strongly suggest that you, as 8.2.1 release manager, would
do well to provide me with better and more regular instruction, e.g. by 

   * assigning some 8.2.1 tickets to me, (I have none)

   * by requesting me to choose some tickets that I can handle,

   * by _promptly and regularly_ checking in with all of the people in
 the critical path to release to find and remove obstacles to their
 work,

   * or by delegating the responsibility and authority to do these things
 to someone else if that's the best way to get the job done.

To summarize, Trac suggests to me that people are either not reporting
their work or are stuck, perhaps because of deadlock, contention,
starvation, challenge, or distraction. How are you going to solve the
problem?

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


Re: Problems revealed by a report of detailed changes to 8.2.1 tickets.

2008-12-22 Thread Michael Stone
On Mon, Dec 22, 2008 at 01:57:56PM -0500, Ed McNierney wrote:
 Michael -

 Are we able to promptly and regularly generate 8.2.1 builds that reflect 
 the work being done? 

For basic testing purposes, yes. Scott's weekend report indicated that
he set up a 'staging' build stream on xs-dev. You can see its output at:

   http://xs-dev.laptop.org/~cscott/xo-1/streams/staging/

Input is provided hourly via the d.l.o package dropbox or via the
local.8.2.1 and koji.dist-olpc3-testing branches of mock.l.o/repos.

   (P.S. - Scott -- you need to push the pilgrim configuration off of
   xs-dev up to pilgrim's main repo.)

True 8.2.1 builds, being under full change control, require trained
manual intervention to create, e.g. by cscott, dsd, or me. 
  
 From last week's reports I get the impression that various bits of
 progress are being made, but we've had no 8.2.1 builds since the first
 one.

What stimulus is supposed to prompt the creation of such a build?
Since some people have refused to follow the workflow I helped write
for 8.2.0 and since you have not reported on the outcome of your
scheduled conversations with those people, it is not at all obvious
how to proceed.

 Please let me know if there is anything I can do to assist. 

In my opinion, more active shepherding of changes and people by the
release manager is clearly called for. For example have you:

   a) clearly broadcast what ticket workflow you are using? 
   b) set any deadlines for the completion of any pending work?
   c) publicly poked people for status updates, or
   d) successfully synchronized people on the status and needs of 8.2.1
  by either email or IRC meetings?

Is there some reason why you feel that none of these forcing functions
is necessary to the release effort or some other commitment that
prevents you from carrying them out?

 If there is anything you (or anyone else) can do to ensure that bug  
 fixes can quickly get into a build for testing, that would be very  
 helpful and an excellent assignment. 

I spent a long time thinking about this remark and about my reaction to
it. On the basis of that reflection, I need to apologize in advance that
my patience has has worn so thin... my reply may be harsher than it
needs to be. It consists of two responses, one outward-facing public
response and one inward-facing critical response.

Outward response: 
Sure, happy to help. I'll go poke the necessary people.

Inward response: 
This remark is unacceptably vague. In order to be the
release manager, you're supposed to know or to be able to figure out
what needs to be done in order to make the release happen. Moreover,
while I'm happy to help with many tasks, I don't really enjoy feeling
like I'm prompting you.  

Example: if 8.2.1 builds concern you, why did you not make more noise
about them last week? (e.g. by sending mail to devel@ or filing a ticket
asking about them.)

Does your process for getting the release unstuck actually consist of
waiting for me to send you questions, then asking me or Scott to fill in
the details of the segment of the critical path that lies immediately
ahead?

 Thanks.

You're welcome.

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


Re: Problems revealed by a report of detailed changes to 8.2.1 tickets.

2008-12-22 Thread Ed McNierney
Michael -

Are we able to promptly and regularly generate 8.2.1 builds that  
reflect the work being done?  From last week's reports I get the  
impression that various bits of progress are being made, but we've had  
no 8.2.1 builds since the first one.

If there is anything you (or anyone else) can do to ensure that bug  
fixes can quickly get into a build for testing, that would be very  
helpful and an excellent assignment.  Please let me know if there is  
anything I can do to assist.  Thanks.

  - Ed

On Dec 22, 2008, at 1:39 PM, Michael Stone mich...@laptop.org wrote:

 Ed,

 I made http://dev.laptop.org/report/39?TIME=80 in the image of one
 of my old 8.2.0 reports. (TIME is the number of seconds of history  
 that
 you want to view so that URL shows you all changes to tickets with
 milestone 8.2.1 made in the last 9-10 days).

 At the time of this writing, over the past week, 7 out of 16 tickets
 have been updated, primarily by Deepak and Scott with some additional
 questions and discussion from Sayamindu, Bert, and Simon.

 I know that I find this degree of recorded progress less than
 satisfactory. Do you feel the same way? If so, you need to know that I
 feel neither empowered nor requested to push this along as fast as it
 can go. (Does anyone else feel similarly?)

 Consequently, if you want my full potential contribution to 8.2.1 to  
 be
 realized, I strongly suggest that you, as 8.2.1 release manager, would
 do well to provide me with better and more regular instruction, e.g.  
 by
  * assigning some 8.2.1 tickets to me, (I have none)

  * by requesting me to choose some tickets that I can handle,

  * by _promptly and regularly_ checking in with all of the people in
the critical path to release to find and remove obstacles to their
work,

  * or by delegating the responsibility and authority to do these  
 things
to someone else if that's the best way to get the job done.

 To summarize, Trac suggests to me that people are either not reporting
 their work or are stuck, perhaps because of deadlock, contention,
 starvation, challenge, or distraction. How are you going to solve the
 problem?

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


Re: Problems revealed by a report of detailed changes to 8.2.1 tickets.

2008-12-22 Thread C. Scott Ananian
On Mon, Dec 22, 2008 at 1:57 PM, Ed McNierney edmcnier...@gmail.com wrote:
 Are we able to promptly and regularly generate 8.2.1 builds that
 reflect the work being done?

Yes.  All completed work should be packaged and put in
public_rpms/staging for testing, with an appropriate changelog.
Staging builds are automatically generated (every three hours) if/when
new packages are added.

Most fixed bugs are not yet included in the staging builds.  I've
gone through most bugs in
  http://dev.laptop.org/report/38
and either packaged/added them to staging myself, or pinged the bug
owner to do so.  Once we get everything included and tested in a
staging build, we can make release candidate quality builds easily
from the contents of the staging repository.  That process mostly
involves testing strategy: do we want to wait until all the bugs are
fixed to make an RC build, or try to generate a series of RC builds
which fix only one thing at a time, or something else.  I'm lazy, I'd
prefer the first option.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Orphaned font packages

2008-12-22 Thread Nicolas Mailhot
Le dimanche 21 décembre 2008 à 07:40 -0500, Bernie Innocenti a écrit :
 Hello,

Hello,

 I've just converted these two packages to the new font packaging
 guidelines, but then I realized I didn't make an ideal maintainer
 because I don't use them and I can't even read those languages :-)

Actually, repoquery found 159 packages with TrueType, OpenType or Type1
fonts in them in rawhide, and you're one of the first packagers to
respond to the resulting bug mass bombing, so I don't think anyone can
complain of your maintainership.

You're doing great, really.

-- 
Nicolas Mailhot


signature.asc
Description: Ceci est une partie de message numériquement signée
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: performance work

2008-12-22 Thread Jordan Crouse
Greg Smith wrote:
 Hi Jordan,
 
 Looks like we made a little more progress on graphics benchmarking. See 
 Neil's results below.
 
 I updated the feature page with the test results so far:
 http://wiki.laptop.org/go/Feature_roadmap/General_UI_sluggishness
 
 What's next?
 
 Do we know enough now to target a particular section of the code for 
 optimization?
 

I ran the raw data through a script, and came up with a nice little 
summary of where we stand.  My first general observation is that the 
numbers are skewed due to system activity - recall that X runs in user 
space, so it is subject to be preempted by the kernel.  I think that the 
obviously high numbers in many of the results are due to NAND or 
wireless interrupts (example):

6: 2261923 (5.25 ms)
7: 16690761 (38.73 ms)
8: 2306919 (5.35 ms)

You might want to re-acquire the numbers with wireless turned off and 
the system in a very quiet state.  If you want to be extra careful, you 
can run the benchmarks in an empty X server (no sugar) and save the 
results to a ramfs backed directory to avoid NAND.  You probably don't 
have to get _that_ extreme, but I don't want you to spend much time 
trying to investigate a path only to find out that the numbers are wrong 
due to a few writes().  In the results below, I tried to mitigate the 
damage somewhat by removing the highest and lowest value.

The list below is sorted by delta between accel and un-accel, with the 
worse tests on top (i.e - the ones where accel is actually hurting 
you) - these are good candidates to be looked at.  There are three 
reasons why unaccel would be faster then accel - 1) a bug in the accel 
code, 2) The accel path requires reading from video memory (which is 
very slow), and 3) the accel path doesn't punt to unaccel early enough.

The first two on the list (textpath-xlib and texturedtext-xlib) toss up 
a huge red flag - I am guessing we are probably seeing a bug in the driver.

All of the upsample and downsample entries are interesting, because the 
driver should be kicking back to the unaccelerated path - I'm guessing
that 3) might be in effect here - though 73 ms is a long time.

Most of the operations between 1ms and -1ms are probably going down the 
unaccelerated path.  Most everything in there probably should be 
unaccelerated, with the possible exception of the 'over' operations - 
those are the easiest for the GPU to accelerate and the most heavily 
used, so you probably want to take a look at those.

As before, I encourage you to investigate which operation are heavily 
used - if you don't use textured text very much, then optimizing it 
would be heavily on the geek points, but not very useful in the long haul.

Jordan
Test AccelNoaccel   Delta
--
textpath-xlib-textpath   1562.60  1345.12  217.48
texturedtext-xlib-texturedtext   315.61   140.54   175.07
downsample-nearest-xlib-512x512-redsquar 106.37   33.25 73.12
downsample-bilinear-xlib-512x512-redsqua 96.5735.22 61.35
downsample-bilinear-xlib-512x512-primros 83.3634.81 48.56
downsample-nearest-xlib-512x512-lenna78.1829.83 48.35
downsample-bilinear-xlib-512x512-lenna   83.9136.32 47.59
downsample-nearest-xlib-512x512-primrose 77.4930.06 47.43
upsample-nearest-xlib-48x48-todo 86.2360.14 26.09
upsample-bilinear-xlib-48x48-brokenlock  242.52   216.4926.03
upsample-bilinear-xlib-48x48-script  237.69   211.7025.98
upsample-bilinear-xlib-48x48-mail234.40   208.4325.97
upsample-bilinear-xlib-48x48-todo239.85   213.9425.91
upsample-nearest-xlib-48x48-script   81.6757.02 24.65
upsample-nearest-xlib-48x48-mail 78.9954.42 24.57
upsample-nearest-xlib-48x48-brokenlock   86.1861.73 24.45
upsample-nearest-48x48-script61.9557.46  4.49
downsample-bilinear-512x512-redsquare11.247.77   3.47
solidtext-xlib-solidtext 11.709.51   2.19
textpath-textpath1081.14  1079.371.78
texturedtext-texturedtext112.33   111.79 0.54
upsample-bilinear-48x48-todo 224.06   223.68 0.37
upsample-nearest-48x48-brokenlock64.4664.16  0.30
upsample-bilinear-48x48-brokenlock   226.51   226.25 0.26
downsample-nearest-512x512-redsquare 2.43 2.23   0.19
gradients-linear-gradients-linear107.39   107.30 0.09
over-640x480-empty   15.6815.61  0.07
over-640x480-opaque  20.1920.12  0.07
add-640x480-opaque   20.7720.73  0.04
upsample-nearest-48x48-todo  60.7560.71  0.04
add-640x480-transparentshapes20.7920.78  0.02
add-640x480-shapes   20.7620.74  0.02
multiple-clip-rectangles-multiple clip r 1.23  

New joyride build 2605

2008-12-22 Thread Build Announcer v2
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2605

Changes in build 2605 from build: 2604

Size delta: -1.97M

-libertas-usb8388-firmware 2:5.110.22.p18-1.olpc2
+libertas-usb8388-firmware 2:5.110.22.p23-1.olpc3
-nash 6.0.71-2.fc10
+nash 6.0.71-3.fc10
-sugar-artwork 0.83.1-2.20081211git3fe6ebe6a8.olpc4
+sugar-artwork 0.83.2-1.olpc4
-sugar 0.83.3-2.20081211git78c54da36b.olpc4
+sugar 0.83.4-2.olpc4
-sugar-base 0.83.1-1.olpc4
+sugar-base 0.83.2-2.olpc4
-sugar-datastore 0.83.0-1.olpc4
+sugar-datastore 0.83.1-1.olpc4
-sugar-presence-service 0.83.1-2.olpc4
+sugar-presence-service 0.83.2-1.olpc4
-sugar-toolkit 0.83.2-1.20081209git054aaf8590.olpc4
+sugar-toolkit 0.83.3-2.olpc4
-gsm 1.0.12-6.fc9
-libao 0.8.8-5.fc10
-libsamplerate 0.1.4-1.fc10
-libtool-ltdl 1.5.26-4.fc10
-mozplugger 1.10.1-3.fc10
-sox 14.1.0-5.20081105cvs.fc10

--- Changes for sugar-artwork 0.83.2-1.olpc4 from 
0.83.1-2.20081211git3fe6ebe6a8.olpc4 ---
  + New icon for the wired network

--- Changes for sugar 0.83.4-2.olpc4 from 0.83.3-2.20081211git78c54da36b.olpc4 
---
  + new download url
  + Fix language parsing on Gentoo and ALTLinux #81 (alsroot)
  + Change the FRAME_POSITION_RELATIVE to follow eben's spec
  + exec sugar-session
  + Add wired device icon for the frame
  + Only show wireless device in the frame when connecting/connected
  + Use jabber.sugarlabs.org by default
  + Only create a keydialog for the activating connection
  + CanvasPulsingIcon: Don't begin pulse loop on resume if not pulsing
  + Use g_timeout_add_seconds() for power efficiency
  + Add the journal button to the volumes toolbar in the journal
  + Remove jarabe/model/volume.py and use gio instead
  + First try at restoring removable devices support in the journal
  + make the image viewer activity the default one for iamges

--- Changes for sugar-toolkit 0.83.3-2.olpc4 from 
0.83.2-1.20081209git054aaf8590.olpc4 ---
  + new download url
  + Fix palette highlighting on tray icons. Patch by benzea, style tweaks by 
marcopg
  + Rework palette state logic. Fix #42
  + Use g_timeout_add_seconds() for power efficiency
  + Add colors to icons in menu items
  + Add accelerator support to menu items
  + Simplify activity bundle installation
  + Dont pop down the palette when a submenu opens

--
This mail was automatically generated
See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs
See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a 
comparison
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: performance work

2008-12-22 Thread Jordan Crouse
Greg Smith wrote:
 Hi Jordan,
 
 Looks like we made a little more progress on graphics benchmarking. See 
 Neil's results below.
 
 I updated the feature page with the test results so far:
 http://wiki.laptop.org/go/Feature_roadmap/General_UI_sluggishness
 
 What's next?
 
 Do we know enough now to target a particular section of the code for 
 optimization?

My previous email was pretty long, so I thought I would answer this last 
question separately.   I can help guide you with the operations that are 
slower with acceleration.   There may be other optimizations to be had 
within cairo or elsewhere in the X world, but I'll have to leave those 
to  people who understand that code better.

The majority of the operations will probably be composite operations. 
You will want to instrument the three composite hooks in the X driver 
and their sub-functions:  lx_check_composite, lx_prepare_composite, and 
lx_do_composite (in lx_exa.c).

lx_check_composite is the function where EXA checks to see if we are 
willing to do the operation at all - most of the acceleration rejects 
should happen here. lx_prepare_composite is where we store the 
information we need for the ensuing composite operation(s) - we can also 
bail out here, but there is an incremental cost in leading EXA further 
down the primrose path before rejecting it.  lx_do_composite() obviously 
is where the operation happens.  You will want to concentrate on these 
functions - instrument the code to figure out why we accept or reject an 
operation and why we take so long in rejecting certain operations. 
Profiling these functions may also help you figure out where we are 
spending our time.

So, in short - become one with the ErrorF() and good luck... :)

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


Re: New joyride build 2605

2008-12-22 Thread Mikus Grinbergs
 +sugar-base 0.83.2-2.olpc4

Good to see this up-leveled -- the previous version of this package 
as distributed in Joyride was more than a month old.

However, that still leaves several packages which appear to be more 
recent in 'olpc3' than in 'olpc4'.  Output of 'yum check-update' :

| pyabiword.i386   0.6.1-4.olpc3
| python-telepathy.noarch  0.15.3-1.olpc3
| sugar-journal.noarch 100-1.olpc3
| xorg-x11-drv-evdev.i386  2.0.8-1.fc9

mikus

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


Re: performance work

2008-12-22 Thread Neil Graham
On Mon, 2008-12-22 at 15:36 -0700, Jordan Crouse wrote:

 You might want to re-acquire the numbers with wireless turned off and 
 the system in a very quiet state.  If you want to be extra careful, you 
 can run the benchmarks in an empty X server (no sugar) and save the 
 results to a ramfs backed directory to avoid NAND. 


The XO Numbers were recorded from a fairly inactive state.  Wireless was
active but there shouldn't have been any traffic.  I did launch X with
just an xterm, so sugar shouldn't be in play at all.  I didn't think of
the speed of nand writes however.


  2) The accel path requires reading from video memory (which is 
 very slow)

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. 

There's a separate 2 meg for DCON memory, but I was under the impression
that was just to remember the last frame.

Do I have that all wrong?   



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


Re: [Server-devel] Collaboration unreliable 0.5

2008-12-22 Thread Martin Langhoff
On Sun, Dec 21, 2008 at 7:05 AM, David Leeming
leem...@pipolfastaem.gov.sb wrote:
 - 0.5 version downloaded on 19/11/08 (note if there is an update this might
 be significant, it is difficult to download 500MB in this region)

You can update with yum, enabling the olpcxs-updates repo, like

  yum --enablerepo=olpcxs-updates update

should download under a MB of RPMs data. The latest xs-config
available for updates has some changes that will require that you
remove a file - /etc/udev/rules.d/70-persistent-net.rules -- otherwise
the networkign will be messed up.

 CONNECTED BUT NOT YET REGISTERED

 I repeated a test three times: reboot and wait 5 minutes, check
 neighbourhood view, run olpc-netstatus and check eJabberd Wed Admin for
 stats, then try sharing Memorise activity and Video Chat (which requires
 registration). After each test I checked again the netstatus

 Results (all 3 tests):
 - All four XOs connect to the server on rebooting
 - Neighbourhood views become fully populated on all four XOs within 3
 minutes.
 - olpc-netstatus has Telepathy=salut, Jabber=(blank), XOs=5,
 Essid=olpc-mesh, Channel=1, School=school.oceania.org, Config=School Mesh
 - eJabberd Admin  Stats shows one user (admin) and no online users
 - Sharing is working with Memorize (even though no XOs registered)!!!
 - Sharing not working with Video Chat (Telepathy error - as expected)
 - Netstatus remains stable throughout the tests as above

Cool - that's getting internet connectivity from the XS, but nothing
else. Ejabberd is not involved...

 I now registered and rebooted all the four XOs and tried same tests (without
 rebooting the server / without restarting eJabberd)

 CONNECTED AND REGISTERED - eJABBERD NOT RESTARTED

 Test as above, but I gave it more time (up to 20 mins)

 Results (3 tests)
 - All XOs connect after rebooting
 - Neighbourhood view does NOT become populated
 - olpc-netstatus (after 15 mins) on all XOs has Telepathy=gabble,
 Jabber=school.oceania.org (not scholserver.oceania.org) XOs=2 (i.e. that XO
 and the XS only), Essid=olpc-mesh, Channel=1, School=school.oceania.org,
 Config=School Mesh
 - eJabberd Admin  Stats shows five users (inc admin) and 4 online users
 - Sharing does NOT work with Memorize (no icon in neighbourhood view on the
 other XOs, cannot invite as no XOs in view)
 - Video Chat starts OK but no other XO running it can be seen, so sharing
 NOT working

I get the same thing. To avoid re-installing the XS to re-test the
just registered scenario you can

 - go with a webbrowser to the ejabberd admin panel, go into the
'schoolserver' vhost listed there and delete all the users registered

 - restart ejabberd

 - restart the laptops

 CONNECTED AND REGISTERED - eJABBERD RESTARTED

 No different from above

if after registration and first reboot on the XO, you restart ejabberd
and you restart the XOs once more, they'll see eachother -- if you
have created the 'Online' shared roster! This works well here.

cheers,


m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel


Re: [Server-devel] Fwd: [ejabberd] Fix or workaround for EJAB-731 - shared roster fails to show new user accts

2008-12-22 Thread Martin Langhoff
On Mon, Dec 22, 2008 at 9:30 AM, Guillaume Desmottes
guillaume.desmot...@collabora.co.uk wrote:
  - Do we need this patch to interop with 8.2 correctly? What does it do?

 IIRC, this patch introduced new type of shared roster: @online@,
 @recent@ and @nea...@. Vanilla ejabberd only supports @a...@.

Ah, so it's the old patch, reapplied. I'd like to learn more about
it, are there any notes on how it works...anywhere? Who's the original
author?

  - Have you tested vanilla ejabberd for the bugs reported in EJAB-730/731?

 Yes. That's why I always mention @all@ instead of @online@ in the
 reports, but the problems were the same.

Thanks for confirming...

 I think if things are working fine with this patch using the @all@
 shared roster, there is good chance that fixes @online@ as well.

Ok. I'll try with @all@, and then see if I can merge...



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel