Re: performance work

[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: New joyride build 2605

[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

[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

New joyride build 2605

[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

[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-multipl

Re: Orphaned font packages

[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: Problems revealed by a report of detailed changes to 8.2.1 tickets.

[C. Scott Ananian]

On Mon, Dec 22, 2008 at 1:57 PM, Ed McNierney  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: Problems revealed by a report of detailed changes to 8.2.1 tickets.

[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  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.

[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

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

[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: olpc-update from 703 to 8.2 wipes out Journal

[Martin Langhoff]

On Wed, Dec 17, 2008 at 2:38 PM, Ties Stuij  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

Re: performance work

[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 
Cc: OLPC Development , 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  > 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: [Server-devel] Fwd: [ejabberd] Fix or workaround for EJAB-731 - shared roster fails to show new user accts

[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 
> 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
>  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: Jabber client activity

[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  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: [Sugar-devel] Jabber client activity

[Morgan Collett]

On Mon, Dec 22, 2008 at 11:52, Tomeu Vizoso  wrote:
> [adding sugar-devel as this is of interest also outside OLPC]
>
> On Sun, Dec 21, 2008 at 23:49, Mildred Ki'Lya  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─ ｍｉｌｄｒｅｄ５９３＠ｏｎｌｉｎｅ．ｆｒ ──
>> │ Jabber, GoogleTalk: 
>> │ Site:   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

[Tomeu Vizoso]

[adding sugar-devel as this is of interest also outside OLPC]

On Sun, Dec 21, 2008 at 23:49, Mildred Ki'Lya  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─ ｍｉｌｄｒｅｄ５９３＠ｏｎｌｉｎｅ．ｆｒ ──
> │ Jabber, GoogleTalk: 
> │ Site:   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: No surprise on memory

[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