date:20080323

Hi,

thought I already had suggested this a long time ago, but anyway:

- Create a XPCOM service in JS that exposes the spreadsheet
functionality implemented in JS.

- Create another XPCOM service in python that exposes the needed Sugar
functionality.

Shouldn't this allow you to integrate SocialCalc in any way you wish?
Creating these two components shouldn't be too hard. Please feel free
to ask in this mailing list any doubts you have.

Example of JS service:
http://dev.laptop.org/git?p=sugar;a=tree;f=browser/components/sessionstore;h=8f894b116ad745b0f7bc7c89e4787c89e60a9eb2;hb=309ddec8b769af42f577229bc5e3278c0328f1c4

Good luck,

Tomeu

2008/3/22 Manusheel Gupta [EMAIL PROTECTED]:
FYI

Regards,
Manu

Manusheel Gupta
Technical Consultant and Adviser
One Laptop Per Child Inc.
http://laptop.org

-- Forwarded message --
From: Luke Closs [EMAIL PROTECTED]
Date: Fri, Mar 21, 2008 at 1:27 AM
Subject: Re: hello
To: Joshua McKenty [EMAIL PROTECTED], [EMAIL PROTECTED]

On Thu, Mar 20, 2008 at 10:27 AM, Joshua McKenty [EMAIL PROTECTED] wrote:

Luke,

Good to hear from you. (I thought it was OLPC laptop, though).

What questions have you got?

Joshua

Hey Joshua,

I've cc'd Manu Gupta, who is collaborating with me on this OLPC spreadsheet
activity.

(OLPC is the non-profit organization, XO is the laptop)

So I'm kinda at a standstill on this project b/c I'm not sure how to
proceed technically - so I'm hoping you can help here, based on the
discussion we had at Northern Voice.

As I mentioned in person, I've got events going back and forth between
python and javascript via pyXPCom. This should work okay for most of the
interactions I need to do, except one. (I'm not tied to the EventObserver,
but it seems to get the job done - I'd consider using another mechanism
too). The one thing where events will not work is when we need to save the
spreadsheet. For instance, the user may quit the program, in which case my
python method write_file() will be called, and I need to (synchronously)
tell javascript to calculate the string that should be saved and give it
back, so I can write it to disk. I don't think an event passing model
(asynch) would work in this case.

I've looked into how Javascript could define a XPCom interface, that the
python code could call, but this seems to require additional steps for
compiling that interface, and I'm not sure how I would end up packaging
those into the sugar app.

So basically, I need your help to figure out how my python code can make a
synchronous method call to javascript to calculate and return stuff.

Thoughts?

Cheers,
Luke

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

Re: JS-Python Communication using PyXPCom

2008-03-23 Thread Marco Pesenti Gritti

There are also dbus bindings for javascript which are being developed,
those would be very useful to integrate with the Sugar services.

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

Re: Mini-Conference Proposal: desktop applications

On Sat, Mar 22, 2008 at 1:02 PM, Marco Pesenti Gritti
[EMAIL PROTECTED] wrote:
 Sugar breaks with the standard desktop metaphor by design and doing so
  it introduces incompatibilities at several levels. The barrier between
  activities and standard applications proved to be a critical problem
  in practice. Fortunately most of the current code base is using GNOME
  and freedesktop libraries, formats and semantics. I'd like to present
  an analysys of the points of incompatibility. Discuss how to integrate
  desktop applications, beginning from the user experience requirements.
  Propose solutions and trade-offs to reconcile the incompatibilities in
  the window management and activity launching area.

Things that we do differently and that clash with traditional apps:

- Activities not applications: Traditional applications are more like
tools that can be used to perform several different tasks. A central
point of the Sugar UI is that activities are individual tasks instead
that the user performs with the laptop and that can be stopped,
resumed and shared at any point.

- Sugar shell integration: the sugar shell performs some
functionalities that traditionally were implemented inside each
application. There needs to be some communication between the activity
and shell processes in order to do so.

- Security: activities run in their own space, isolated from the rest
of the software. The security framework tries to give activities all
the capabilities that may be needed, but not the ability to cause harm
to the system or violate the privacy of the kid.

- Small screen: the screen is small so it was decided that activities
would have just one window always maximized. This also matches the
goal of activities like single-tasks.

- Modifiability: source code is interpreted, so the kid can study the
code, modify it, and see the results without more fuss.

Hope that clarifies things a bit,

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

Re: 1789 - sugar does not boot (1788 and 1790 either)

On Sat, Mar 22, 2008 at 7:37 PM, Mark Bauer [EMAIL PROTECTED] wrote:
 I also have had issues with builds 1788 and 1790.  These would also
  not boot.
  I resorted back to 1784 to get it to boot.  With 1788 it looked like
  it was locked up,
  but the power button still puts it in suspend and brings it out
  again.  Ctl alt F1 to
  get to another screen did nothing until pressing suspend again a few
  times.  It is
  like the keyboard isn't generating interrupts, The keystrokes are
  remembered and
  processed eventually by pressing power button several times.  Waited
  until today
  and upgraded to 1790 and it didn't boot either.  Anything else I can
  test to help???

  Thanks,


  Mark



  On Mar 22, 2008, at 12:03 PM, Dennis Gilmore wrote:
   On Saturday 22 March 2008 11:52:47 am Michael Stone wrote:
   Examining
  
 http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html
  
   I suspect kbd-1.12-22 - 1.12-23 since we know that 1.12-23
   (accidentally) contains an html file describing a spanish keyboard
   map
   instead of the map itself.
   does 1788 work for you?  im wondering if libnl 1.1-1.fc7  is to blame.

Yes, the libnl update seems to have broken things.

-bash-3.2# NetworkManager --no-daemon
NetworkManager: info  starting...
NetworkManager: symbol lookup error: NetworkManager: undefined symbol:
nl_handle_alloc_nondefault

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

New joyride build 1793

http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1793

Changes in build 1793 from build: 1790

Size delta: 0.14M

-Calculate 17
+Calculate 19
-Read 44
+Read 45

--- Changes for Calculate 19 from 17 ---
  + Include Gary Martin's icons
  + Power operator for Rationals
  + Fix Decimal operator issues, #6478

--- Changes for Read 45 from 44 ---
  + Save document to DS after download
  + Don't suspend when shared

--
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: 1789 - sugar does not boot (1788 and 1790 either)

2008-03-23 Thread Dennis Gilmore

On Sunday 23 March 2008, Tomeu Vizoso wrote:
   On Mar 22, 2008, at 12:03 PM, Dennis Gilmore wrote:
On Saturday 22 March 2008 11:52:47 am Michael Stone wrote:
Examining
   
  http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html
   
I suspect kbd-1.12-22 - 1.12-23 since we know that 1.12-23
(accidentally) contains an html file describing a spanish keyboard
map
instead of the map itself.
   
does 1788 work for you?  im wondering if libnl 1.1-1.fc7  is to blame.

 Yes, the libnl update seems to have broken things.

 -bash-3.2# NetworkManager --no-daemon
 NetworkManager: info  starting...
 NetworkManager: symbol lookup error: NetworkManager: undefined symbol:
 nl_handle_alloc_nondefault

ive just pulled the libdhcp and libnl updates  so the next joyride build 
should be ok 

Dennis




signature.asc
Description: This is a digitally signed message part.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

New faster build 1793

http://xs-dev.laptop.org/~cscott/olpc/streams/faster/build1793

Changes in build 1793 from build: 1790

Size delta: 0.00M

-Calculate 17
+Calculate 19
-Read 44
+Read 45

--- Changes for Calculate 19 from 17 ---
  + Include Gary Martin's icons
  + Power operator for Rationals
  + Fix Decimal operator issues, #6478

--- Changes for Read 45 from 44 ---
  + Save document to DS after download
  + Don't suspend when shared

--
This mail was automatically generated
See http://dev.laptop.org/~rwh/announcer/faster-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: Mini-Conference Proposal: olpcfs

Hi,

On Fri, Mar 21, 2008 at 5:53 PM, C. Scott Ananian [EMAIL PROTECTED] wrote:
 One major frustration with the existing datastore implementation is
  that is unfriendly to legacy applications: you can't easily use the
  command-line to browse through it, and you can't save a file from an
  unmodified linux application into the journal.  I propose a filesystem
  design, called olpcfs for now, to address this deficiency, and provide
  versioning and synchronization mechanisms needed for the
  next-generation journal.  It plays nicely with the upgrade mechanisms
  and Bitfrost, too!

  More information: (draft) http://wiki.laptop.org/go/Olpcfs

thank you very much for devoting time to this. Some questions for now:

- Do you think that the POSIX API is very much tied to the underlying
implementation or should be discussed separately?

- This POSIX API would be the main way to access the data? Or just one
more way? If so, have you already thought about the main API? Anything
better than D-Bus?

In general, I would like to know first more details about your
motivations for redesigning the DS. Mine are the following:

- add versioned entries and delta-based storage,

- get a saner way of passing files from activity side to the DS-managed side,

- make it more maintainable, perhaps add one lawyer of abstraction so
we can switch later to a different full text engine, metadata storage,
etc,

- increase scalability and raw performance.

Thanks,

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

Mini-Conference Proposal: sugar performance

What I see we can do in the short/medium term:

- Launch python activities in a preinitialized python interpreter, may
save memory too.

- Move datastore and sharing initialization later after the UI has
been launched, the user won't be able to start working sooner, but
will be given a better idea of the launching process (will feel
faster).

- Use composition, so we save some redraws that currently make the UI
to feel sluggish. Also will allow to take previews of hidden windows
and that will improve considerably the switching from one activity to
another. Will take some more memory.

- Datastore: is currently indexing much more information than the
really needed, this slows indexing, searching and retrieving. Also,
the metadata is stored in a pickled dictionary inside a b-tree. Having
to unpickle the whole dictionary for retrieving just a couple of
properties is surprisingly costly.

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

Re: Mini-Conference Proposal: sugar performance

2008-03-23 Thread Gary C Martin

Hi Tomeu,

On 23 Mar 2008, at 17:13, Tomeu Vizoso wrote:

 - Move datastore and sharing initialization later after the UI has
 been launched, the user won't be able to start working sooner, but
 will be given a better idea of the launching process (will feel
 faster).

I think we spoke a little about this a few weeks back. What happens if  
the UI needs access to datastore, metadata, or sharing details to  
actually present it's UI for the task at hand? For example, launching  
Speak activity from the Journal requires the face to be drawn with  
preference data from the datastore (number of eyes, eye shape, mouth  
shape, spoken language).

Currently most UI layout is just done in the activities main __init__  
and this is already a limitation if the activity needs datastore  
information before drawing the UI. If the activity is started from  
Journal, then a read_file() method can catch the data availability and  
draw the required UI. If the activity is started from fresh then there  
is  nothing other than the __init__ call. With Moon activity, I've had  
to put in an (arbitrary 50ms) event timer in my __init__ so I do not  
draw the UI right away. Then, if read_file() is triggered, I remove  
the event timer and draw the UI for the data that just became  
available. If read_file() is not called, or not called within my event  
timer delay, then the timer eventually fires and triggers a default UI  
draw. Not an idea solution.

It would be useful to have 3 methods called during activity set-up:

__init__ # set-up what you can

then either:

 read_file() # for when there is journal data

xor:

clean_start() # for when there is no journal data

Gary

BTW: I've not implemented any form of sharing yet (I have no way to  
reliably test), so don't have any input about shared activity start- 
ups. I do remember seeing at least one ticket kicking about for a  
Write bug, where you could start typing in a shared document before  
the shared data had actually arrived from the other XO, messing up  
document state somewhat...

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

New joyride build 1794

http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1794

Changes in build 1794 from build: 1793

Size delta: 0.00M

-libdhcp 1.24-6.fc7
+libdhcp 1.24-4.fc7
-libnl 1.1-1.fc7
+libnl 1.0-0.10.pre5.4

--- Changes for libdhcp 1.24-4.fc7 from 1.24-6.fc7 ---
  + Update for libnl 1.1
  + Update License tag to GPLv2

--- Changes for libnl 1.0-0.10.pre5.4 from 1.1-1.fc7 ---
  + Update to version 1.1
  + Handle removal of include/linux/ip_mp_alg.h in 2.6.24
  + devel package should require kernel-headers
  + Add dist tag to revision
  + Update to -pre8 + fixes (rh #401761)

--
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: Mini-Conference Proposal: sugar performance

On Sun, Mar 23, 2008 at 7:01 PM, Gary C Martin [EMAIL PROTECTED] wrote:
  On 23 Mar 2008, at 17:13, Tomeu Vizoso wrote:
   - Move datastore and sharing initialization later after the UI has
   been launched, the user won't be able to start working sooner, but
   will be given a better idea of the launching process (will feel
   faster).

  I think we spoke a little about this a few weeks back. What happens if
  the UI needs access to datastore, metadata, or sharing details to
  actually present it's UI for the task at hand? For example, launching
  Speak activity from the Journal requires the face to be drawn with
  preference data from the datastore (number of eyes, eye shape, mouth
  shape, spoken language).

  Currently most UI layout is just done in the activities main __init__
  and this is already a limitation if the activity needs datastore
  information before drawing the UI. If the activity is started from
  Journal, then a read_file() method can catch the data availability and
  draw the required UI. If the activity is started from fresh then there
  is  nothing other than the __init__ call. With Moon activity, I've had
  to put in an (arbitrary 50ms) event timer in my __init__ so I do not
  draw the UI right away. Then, if read_file() is triggered, I remove
  the event timer and draw the UI for the data that just became
  available. If read_file() is not called, or not called within my event
  timer delay, then the timer eventually fires and triggers a default UI
  draw. Not an idea solution.

  It would be useful to have 3 methods called during activity set-up:

 __init__ # set-up what you can

  then either:

  read_file() # for when there is journal data

  xor:

 clean_start() # for when there is no journal data

Well, what I expected from activities is something like what happens
in Read and Write. Both use a quite complex widget as their meat:
Abiword's abiwidget and Evince's view.

Both these widgets can be inserted in the hierarchy and will be drawn
empty. If you set a PDF or ODT document, that document will be
displayed.

Basically, we can summarize this issue as moving things to be async.
If everything is synchronous, the result of the user actions will last
longer to appear on the screen, and the users thinks that nothing is
happening and that something wrong happened.

The idea is that, instead of waiting 5 seconds for the full UI to
appear, the activity window would appear after, say, 3 seconds, half a
second later the document will get loaded, and half a second later the
user will be able to share the activity or invite somebody.

Can your activities do something about this?

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

Re: JS-Python Communication using PyXPCom

On Sun, Mar 23, 2008 at 7:06 PM, Luke Closs [EMAIL PROTECTED] wrote:
 On 23-Mar-08, at 3:03 AM, Tomeu Vizoso wrote:
   thought I already had suggested this a long time ago, but anyway:
  
   - Create a XPCOM service in JS that exposes the spreadsheet
   functionality implemented in JS.
  
   - Create another XPCOM service in python that exposes the needed Sugar
   functionality.
  
   Shouldn't this allow you to integrate SocialCalc in any way you wish?
   Creating these two components shouldn't be too hard. Please feel free
   to ask in this mailing list any doubts you have.
  
   Example of JS service:
   
 http://dev.laptop.org/git?p=sugar;a=tree;f=browser/components/sessionstore;h=8f894b116ad745b0f7bc7c89e4787c89e60a9eb2;hb=309ddec8b769af42f577229bc5e3278c0328f1c4

  Thank you very much for this link, it's exactly the kind of example I
  was looking for.  I may have a followup question or two.

Forgot to mention that perhaps we'll need to add to hulahop a function
for setting the dir from which the components need to be loaded
(probably a subdirectory inside the activity bundle). Should be quite
easy.

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

New faster build 1794

http://xs-dev.laptop.org/~cscott/olpc/streams/faster/build1794

Changes in build 1794 from build: 1793

Size delta: -0.13M

-libdhcp 1.24-6.fc7
+libdhcp 1.24-4.fc7
-libnl 1.1-1.fc7
+libnl 1.0-0.10.pre5.4

--- Changes for libdhcp 1.24-4.fc7 from 1.24-6.fc7 ---
  + Update for libnl 1.1
  + Update License tag to GPLv2

--- Changes for libnl 1.0-0.10.pre5.4 from 1.1-1.fc7 ---
  + Update to version 1.1
  + Handle removal of include/linux/ip_mp_alg.h in 2.6.24
  + devel package should require kernel-headers
  + Add dist tag to revision
  + Update to -pre8 + fixes (rh #401761)

--
This mail was automatically generated
See http://dev.laptop.org/~rwh/announcer/faster-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: Mini-Conference Proposal: sugar performance

2008-03-23 Thread Gary C Martin

On 23 Mar 2008, at 18:32, Tomeu Vizoso wrote:

 The idea is that, instead of waiting 5 seconds for the full UI to
 appear, the activity window would appear after, say, 3 seconds, half a
 second later the document will get loaded, and half a second later the
 user will be able to share the activity or invite somebody.

 Can your activities do something about this?

I have just one activity at the moment, Moon, the difficulty I'd face  
is that I really don't want multiple redraws at start-up for what  
you're calling the document area, it's quite cpu expensive in my case  
(at least a second or so per refresh). And I have a planned activity  
where it may be even worse (a lon/lat tag sharable 3D Earth view).

Currently there is no way an activity can know (in its __init__) if  
read_file() is going to be called, so with your proposed changes, yes  
I can (and do) set-up the default tool bar, a black screen and my text  
panel early, but I'd then need to have my __init__ set-up a timer to  
arbitrarily ~0.5 or more sec, just incase a read_file() call arrives.  
So every fresh launch will twiddle it's fingers for an extra  
unnecessary ~0.5 sec, and if after a Journal launch and the ~0.5 sec  
was not long enough, the user will get a nasty double redraw of the  
main cpu expensive widget refresh, slowing things down even more (and  
looking bad as well).

Letting the activity know data is, or isn't, expected from the Journal  
is the missing feature here. Always having a read_file() xor a  
clean_start() call would resolve this. Other options could be to just  
always call read_file() data or no data and let the activity deal with  
perhaps a file_name = None, but that will likely break some existing  
activities.

Regards,
Gary

P.S. clean_start() is just a stand-in name, sure you'd have a better  
name for it, maybe no_file()? On OS X under Cocoa we have the usual  
init method to get the base things going, and then later an  
awakeFromNib method is called so that an application knows its  
resource files have been dealt with by the runtime – that's when we  
can start parsing preference settings etc and tweaking the UI to  
match. There's even then a final applicationDidFinishLaunching method  
you override to kick things off once the set-up is all over.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: New update.1 build 702

2008-03-23 Thread Ricardo Carrano

Updated from 695 to 702.
No activity icons on the frame...

On Sat, Mar 22, 2008 at 12:17 AM, Build Announcer v2 [EMAIL PROTECTED]
wrote:

 http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/build702http://pilgrim.laptop.org/%7Epilgrim/olpc/streams/update.1/build702

 Changes in build 702 from build: 701

 Size delta: -0.14M

 -kbd 1.12-23.olpc2
 +kbd 1.12-24.olpc2

 --- Changes for kbd 1.12-24.olpc2 from 1.12-23.olpc2 ---
  + get the proper files.  a wget of the the url resulted in a html file
  + not the expected gz file

 --
 This mail was automatically generated
 See 
 http://dev.laptop.org/~rwh/announcer/update.1-pkgs.htmlhttp://dev.laptop.org/%7Erwh/announcer/update.1-pkgs.htmlfor
  aggregate logs
 See 
 http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.htmlhttp://dev.laptop.org/%7Erwh/announcer/joyride_vs_update1.htmlfor
  a comparison
 ___
 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

Fwd: JS-Python Communication using PyXPCom

2008-03-23 Thread Manusheel Gupta

FYI

Luke has been unable to post in the devel lists. The message that he posts
in this mailing list bounces back. Is there a solution to this problem, or
should I ask him to join the devel lists again?


-Manu



-- Forwarded message --
From: Luke Closs [EMAIL PROTECTED]
Date: Mon, Mar 24, 2008 at 12:37 AM
Subject: Re: JS-Python Communication using PyXPCom
To: Tomeu Vizoso [EMAIL PROTECTED]
Cc: Manusheel Gupta [EMAIL PROTECTED], devel@lists.laptop.org, Dan Bricklin
[EMAIL PROTECTED]



On 23-Mar-08, at 11:37 AM, Tomeu Vizoso wrote:
 On Sun, Mar 23, 2008 at 7:06 PM, Luke Closs
 [EMAIL PROTECTED] wrote:
 On 23-Mar-08, at 3:03 AM, Tomeu Vizoso wrote:
 thought I already had suggested this a long time ago, but anyway:

 - Create a XPCOM service in JS that exposes the spreadsheet
 functionality implemented in JS.

 - Create another XPCOM service in python that exposes the needed
 Sugar
 functionality.

 Shouldn't this allow you to integrate SocialCalc in any way you
 wish?
 Creating these two components shouldn't be too hard. Please feel
 free
 to ask in this mailing list any doubts you have.

 Example of JS service:

http://dev.laptop.org/git?p=sugar;a=tree;f=browser/components/sessionstore;h=8f894b116ad745b0f7bc7c89e4787c89e60a9eb2;hb=309ddec8b769af42f577229bc5e3278c0328f1c4

 Thank you very much for this link, it's exactly the kind of example I
 was looking for.  I may have a followup question or two.

 Forgot to mention that perhaps we'll need to add to hulahop a function
 for setting the dir from which the components need to be loaded
 (probably a subdirectory inside the activity bundle). Should be quite
 easy.

Ahh, this was one of the missing pieces I was going to ask about.

So just to clarify, this Hulahop/XPCom approach is not the same as
using XULRunner, correct?

I'm going to try to create a hello world type application to try
creating the XPCom service in Javascript.

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

Re: New faster build 1794

2008-03-23 Thread Gary Oberbrunner

Build Announcer v2 wrote:
 http://xs-dev.laptop.org/~cscott/olpc/streams/faster/build1794

Can't see recent builds with my olpc-update

They try to open rsync://updates.laptop.org/ but there's only one 
faster build there, 1788.  Here's what my rsync sees on a regular 
linux box:

% rsync rsync://updates.laptop.org/
build-649
build-650
build-653
build-656
build-candidate-691
build-candidate-699
build-debian
build-debian-big
build-faster-1778
build-frs
build-joyride-1606
build-joyride-1774
build-joyride-1776
build-joyride-1779
build-joyride-1780
build-joyride-1781
build-joyride-1783
build-joyride-1784
build-joyride-1785
build-joyride-1786
build-joyride-1787
build-joyride-1788
build-joyride-1789
build-joyride-1790
build-joyride-1791
build-ship.2-653
build-ship.2-656
build-update.1-659
build-update.1-690
build-update.1-691
build-update.1-692
build-update.1-693
build-update.1-694
build-update.1-695
build-update.1-696
build-update.1-697
build-update.1-698
build-update.1-699
build-update.1-700
build-update.1-701
build-update.1-702


I don't see the most recent joyrides, and only that one faster.  Am I 
missing something?

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

Re: New faster build 1794

The updates server pulls down builds lazily on request. In other words,
rsync'ing against it only tells you what builds it has _cached_, not
what builds it can provide.

Still, please let us know when you're unable to update to builds with
olpc-update, and file bugs if necessary.

Thanks,

Michael

On Sun, Mar 23, 2008 at 06:36:20PM -0400, Gary Oberbrunner wrote:
 Build Announcer v2 wrote:
  http://xs-dev.laptop.org/~cscott/olpc/streams/faster/build1794
 
 Can't see recent builds with my olpc-update
 
 They try to open rsync://updates.laptop.org/ but there's only one 
 faster build there, 1788.  Here's what my rsync sees on a regular 
 linux box:
 
 % rsync rsync://updates.laptop.org/
 build-649
 build-650
 build-653
 build-656
 build-candidate-691
 build-candidate-699
 build-debian
 build-debian-big
 build-faster-1778
 build-frs
 build-joyride-1606
 build-joyride-1774
 build-joyride-1776
 build-joyride-1779
 build-joyride-1780
 build-joyride-1781
 build-joyride-1783
 build-joyride-1784
 build-joyride-1785
 build-joyride-1786
 build-joyride-1787
 build-joyride-1788
 build-joyride-1789
 build-joyride-1790
 build-joyride-1791
 build-ship.2-653
 build-ship.2-656
 build-update.1-659
 build-update.1-690
 build-update.1-691
 build-update.1-692
 build-update.1-693
 build-update.1-694
 build-update.1-695
 build-update.1-696
 build-update.1-697
 build-update.1-698
 build-update.1-699
 build-update.1-700
 build-update.1-701
 build-update.1-702
 
 
 I don't see the most recent joyrides, and only that one faster.  Am I 
 missing something?
 
 -- Gary Oberbrunner
 ___
 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: New update.1 build 702

On Sun, Mar 23, 2008 at 05:35:28PM -0300, Ricardo Carrano wrote:
 Updated from 695 to 702.
 No activity icons on the frame...

Ricardo,

See 

  http://dev.laptop.org/ticket/6598
  http://lists.laptop.org/pipermail/devel/2008-March/011984.html

for some explanation of what's afoot. 

Also, Chris Ball and the xo-get folks have done some work on scripts for
assembling activity packs and for mass-installing activities on empty
builds. Perhaps their work is of interest?

Michael

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

Re: Core Activities - Bundled Packs discussion

Ixo,

Thanks very much for your excellent start! I'll try to reflect on it
more carefully as soon as I am able.

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

Re: Mini-Conference Proposal: olpcfs

2008-03-23 Thread Martin Langhoff

On Fri, Mar 21, 2008 at 12:53 PM, C. Scott Ananian [EMAIL PROTECTED] wrote:
  More information: (draft) http://wiki.laptop.org/go/Olpcfs

The thinking behind this is *excellent*.

If we make a couple of minor tweaks and we take that as the
description of the goals, then we can implement that, and a ton more
in a couple of days by using real files in the filesystem, a single
file containing the fancy metadata, and committing things into GIT.
Which gets us to the place where we want to be, with 100th the
engineering effort.

The API gets simplified to:

 - a convention of the fact that for each document you are given a
directory - which will get shown as a single item in the UI, a la OSX
with .app bundles

 - in that directory, an optional metadata.yaml (or .xml or whatever)
holds additional metadata.

 - the application can make a save snapshot call to trigger a commit
(mapped to the save document) but this is optional because...

 - when the app exits with a 0 the files get committed

 - when the app exits 0 the files get committed in a specially tagged
commit that indicates abnormal termination - so the journal may later
offer to attempt to open that set of files

 - we can use a readonly FUSE view of the repo or just plain git from
journal to retrieve old version -- but any file retrieved to work on
gets extracted to the real FS

That's the pragmatic pseudo-API. Some technical notes...

 - by virtue of always working with a real FS, we can direct app
developers to use mmap and similar advanced tricks to work efficiently
on data. Supporting mmap is hell if we do our own FUSE implementation,
and we _need_ performance tricks like mmap.

 - by virtue of using a normal FS, it works with tar, zip, rsync,etc.
Every OS that has extended the POSIX basics has had to come up with
its own archiver implementation to handle the extensions (hi Darwin!)

 - the work of the School server with backups is _trivial_ ;-) -- git push

 - it is trivial to implement a sliding window to forget old
commits as the disk gets full, and a longer sliding window on the XS

 - we can tweak our git configuration to work well with the Flash and
jj2fs filesystem

A few advanced tricks will need some tweaking (handling low disk
conditions until we can consolidate packs, packing opportunistically
when we have a power source), but by avoiding the FUSE path we can
save a ton of time which we can use for those purposes.

And then, with the experience of doing this the cheap way, we can
schedule a year or two to write a new FS, and have a go at nailing a
better implementation than Torvalds and his ragtag band of kernel
developers ;-)

cheers,



martin
-- 
 [EMAIL PROTECTED]
 [EMAIL PROTECTED] -- 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: New update.1 build 702

2008-03-23 Thread Kim Quirk

Ricardo,
Use this link to create your customization USB stick:
http://wiki.laptop.org/go/Customization_key#Preparing_the_key:

Chris,
I have pulled together a set of bundles that include the latest version of
each of the activities that shipped with G1G1. I would like people to use
this set of activities in their bundles directory for testing 702 (unless
they have their own customization bundles). How far along is the automated
xo-get? (assuming that is what you are working on). Perhaps we can release
my '702 G1G1 customization' zip for now.

Also, it is a little confusing how we are dealing with the signed and
unsigned versions. I can't get an unsigned version to work off one boot
directory. I have to configure the boot directly to install the OFW and OS;
and then change the boot directory (add the actos.zip and runos.zip) to be
able to install the bundles. Is there some way to make this all work on an
unprotected XO?

Thanks,
Kim


On Sun, Mar 23, 2008 at 7:09 PM, Michael Stone [EMAIL PROTECTED] wrote:

 On Sun, Mar 23, 2008 at 05:35:28PM -0300, Ricardo Carrano wrote:
  Updated from 695 to 702.
  No activity icons on the frame...

 Ricardo,

 See

  http://dev.laptop.org/ticket/6598
  http://lists.laptop.org/pipermail/devel/2008-March/011984.html

 for some explanation of what's afoot.

 Also, Chris Ball and the xo-get folks have done some work on scripts for
 assembling activity packs and for mass-installing activities on empty
 builds. Perhaps their work is of interest?

 Michael

 ___
 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

Mini-Conference Proposal: Suspend/Resume speed

2008-03-23 Thread Richard A. Smith

I propose that for Update.2 we put significant effort into making 
suspend/resume reach its speed target and work correctly on the hardware.

Its close but we are still about 5x slower than the 200ms goal, things 
like SD don't always work after a cycle, and we need to have proper idle 
detection.

This is not to be confused with all the incompatibilities between 
presence and suspend or network apps that don't work when a peer has 
suspended.  Those problems are in a different space.

Those problems certainly need to be solved but trying to solve them on 
top of a suspend/resume implementation that not the final product just 
makes it harder.

-- 
Richard Smith  [EMAIL PROTECTED]
One Laptop Per Child

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

Re: New update.1 build 702

2008-03-23 Thread Chris Ball

Hi Kim,

Chris, I have pulled together a set of bundles that include the
latest version of each of the activities that shipped with G1G1. I
would like people to use this set of activities in their bundles
directory for testing 702 (unless they have their own customization
bundles). How far along is the automated xo-get?  (assuming that is
what you are working on).

I have a script that pulls the latest versions of activities out of the
update.1 repository into a bundles/ directory, and that knows which
activities should be used for a Peru, Mexico or G1G1 customization key.

I'll prepare a zip file of a customization key with the G1G1 activities
on tomorrow, we can see if there are any version discrepencies between
our bundles, and I'll release a G1G1 customization key and the script
tomorrow.  Sound okay?

Thanks,

- Chris.
-- 
Chris Ball   [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: New update.1 build 702

2008-03-23 Thread Kim Quirk

Sounds great!!

Thanks,
Kim

On Sun, Mar 23, 2008 at 10:00 PM, Chris Ball [EMAIL PROTECTED] wrote:

 Hi Kim,

Chris, I have pulled together a set of bundles that include the
latest version of each of the activities that shipped with G1G1. I
would like people to use this set of activities in their bundles
directory for testing 702 (unless they have their own customization
bundles). How far along is the automated xo-get?  (assuming that is
what you are working on).

 I have a script that pulls the latest versions of activities out of the
 update.1 repository into a bundles/ directory, and that knows which
 activities should be used for a Peru, Mexico or G1G1 customization key.

 I'll prepare a zip file of a customization key with the G1G1 activities
 on tomorrow, we can see if there are any version discrepencies between
 our bundles, and I'll release a G1G1 customization key and the script
 tomorrow.  Sound okay?

 Thanks,

 - Chris.
 --
 Chris Ball   [EMAIL PROTECTED]

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

Fixing the Pen Tablet

Folks,

Below are patches to the kernel source code and the xorg-x11-server and
xorg-x11-drv-evdev packages which restore function to the ALPS Pen
Tablet (dlo#5268), which fix the twin clicks bug that plagued previous
approaches (dlo#6079), and which cause X to configure the Pen Tablet in
absolute mode (mapped to the entire screen, dlo#1002) while leaving
Glide Sensor in relative mode (discussion at dlo#4260).

Blake  Michael
From 827d3ab4637a72b9cb0eede4d071234df20cc24c Mon Sep 17 00:00:00 2001
From: Blake Setlow [EMAIL PROTECTED]
Date: Sun, 23 Mar 2008 21:32:07 -0400
Subject: [PATCH] OLPC: psmouse: Make the OLPC/ALPS Pen Tablet and Glide Sensor 
play together.

The Pen Tablet has been disabled for some time [1] because enabling it caused
a twin clicks bug [2]. One minimal way to fix the first bug while avoiding
the second is to enable the Pen Tablet and its buttons while turning off some
of the buttons on the Glide Sensor. We do this and we attempt to explain why
each bit in the PT and GS device structs is set or unset.

This patch was coauthored by Blake Setlow and Michael Stone.

[1]: http://dev.laptop.org/ticket/5628
[2]: http://dev.laptop.org/ticket/6079

Signed-off-by: Michael Stone [EMAIL PROTECTED]
---
 drivers/input/mouse/olpc.c |   54 +++
 1 files changed, 39 insertions(+), 15 deletions(-)

diff --git a/drivers/input/mouse/olpc.c b/drivers/input/mouse/olpc.c
index 9479658..80604bb 100644
--- a/drivers/input/mouse/olpc.c
+++ b/drivers/input/mouse/olpc.c
@@ -3,6 +3,7 @@
  *
  * Copyright (c) 2006 One Laptop Per Child, inc.
  * Authors Zephaniah E. Hull and Andres Salomon [EMAIL PROTECTED]
+ * Authors Blake Setlow [EMAIL PROTECTED]
  *
  * This driver is partly based on the ALPS driver, which is:
  *
@@ -487,21 +488,30 @@ int olpc_init(struct psmouse *psmouse)
goto init_fail;
}
 
-   /*
-* Unset some of the default bits for things we don't have.
-*/
+   /* Mode: our Pen Tablet (PT) should be used in its absolute mode */
dev-evbit[LONG(EV_REL)] = ~BIT(EV_REL);
-   dev-relbit[LONG(REL_X)] = ~(BIT(REL_X) | BIT(REL_Y));
-   dev-keybit[LONG(BTN_MIDDLE)] = ~BIT(BTN_MIDDLE);
-
+   dev-evbit[LONG(EV_ABS)] |= BIT(EV_ABS);
dev-evbit[LONG(EV_KEY)] |= BIT(EV_KEY);
+
+   /* Axes: give us absolute and not relative data. */
+   dev-relbit[LONG(REL_X)] = ~BIT(REL_X);
+   dev-relbit[LONG(REL_Y)] = ~BIT(REL_Y);
+   dev-absbit[LONG(ABS_X)] |= BIT(ABS_X);
+   dev-absbit[LONG(ABS_Y)] |= BIT(ABS_Y);
+   dev-absbit[LONG(ABS_PRESSURE)] |= BIT(ABS_PRESSURE);
+
+   /* Buttons: without BTN_TOUCH but with BTN_TOOL_PEN, evtest reports
+* nothing! */
dev-keybit[LONG(BTN_TOUCH)] |= BIT(BTN_TOUCH);
dev-keybit[LONG(BTN_TOOL_PEN)] |= BIT(BTN_TOOL_PEN);
-   dev-keybit[LONG(BTN_LEFT)] |= BIT(BTN_LEFT) | BIT(BTN_RIGHT);
+   dev-keybit[LONG(BTN_LEFT)] |= BIT(BTN_LEFT);
+   dev-keybit[LONG(BTN_RIGHT)] |= BIT(BTN_RIGHT);
+   dev-keybit[LONG(BTN_MIDDLE)] = ~BIT(BTN_MIDDLE);
 
-   dev-evbit[LONG(EV_ABS)] |= BIT(EV_ABS);
-   input_set_abs_params(dev, ABS_X, 2, 1000, 0, 0);
-   input_set_abs_params(dev, ABS_Y, 0, 717, 0, 0);
+   /* Finally, some magic range numbers governing device output ranges. */
+   input_set_abs_params(dev, ABS_X, 2, 998, 0, 0);
+   input_set_abs_params(dev, ABS_Y, 2, 238, 0, 0);
+   input_set_abs_params(dev, ABS_PRESSURE, 0, 63, 0, 0);
 
snprintf(priv-phys, sizeof(priv-phys),
%s/input1, psmouse-ps2dev.serio-phys);
@@ -512,17 +522,31 @@ int olpc_init(struct psmouse *psmouse)
dev2-id.product = PSMOUSE_OLPC;
dev2-id.version = 0x;
 
+   /* Mode: we want to use the Glide Sensor (GS) in its relative mode, but
+* for some reason, it needs to be in absolute mode (with relative
+* axes) in order for HAL, evdev, and X to be happy. */
+   dev2-evbit[LONG(EV_REL)] = ~BIT(EV_REL);
+   dev2-evbit[LONG(EV_ABS)] |= BIT(EV_ABS);
dev2-evbit[LONG(EV_KEY)] |= BIT(EV_KEY);
+
+   /* Axes: we want relative data for the GS. */
+   dev2-relbit[LONG(REL_X)] |= BIT(REL_X);
+   dev2-relbit[LONG(REL_Y)] |= BIT(REL_Y);
+   dev2-absbit[LONG(ABS_X)] = ~BIT(ABS_X);
+   dev2-absbit[LONG(ABS_Y)] = ~BIT(ABS_Y);
+   dev2-absbit[LONG(ABS_PRESSURE)] = ~BIT(ABS_PRESSURE);
+
+   /* Buttons: We disable some of the GlideSensor buttons to avoid
+* receiving twinned clicks. See http://dev.laptop.org/ticket/6745. */
dev2-keybit[LONG(BTN_TOUCH)] |= BIT(BTN_TOUCH);
dev2-keybit[LONG(BTN_TOOL_FINGER)] |= BIT(BTN_TOOL_FINGER);
-   dev2-keybit[LONG(BTN_LEFT)] |= BIT(BTN_LEFT) | BIT(BTN_RIGHT);
+   dev2-keybit[LONG(BTN_LEFT)] = ~BIT(BTN_LEFT);
+   dev2-keybit[LONG(BTN_RIGHT)] = ~BIT(BTN_RIGHT);
+   dev2-keybit[LONG(BTN_MIDDLE)] = ~BIT(BTN_MIDDLE);
 
-   /* bernie: argh -- needed for hal to see it as a mouse */
-

Re: New faster build 1794

2008-03-23 Thread Gary Oberbrunner

Michael Stone wrote:
 The updates server pulls down builds lazily on request. In other words,
 rsync'ing against it only tells you what builds it has _cached_, not
 what builds it can provide.

ok, makes sense.  Is there anywhere I can go to see what builds are 
actually available?  I tried today to get faster-1795, joyride-1795 and 
a few others I don't remember anymore; the only the one I could get was 
the one already cached (1788 I guess).  Just tried again to get 
faster-1795 and after about 60 sec it times out and says no such build 
exists. -v -v -v doesn't give any more info.  Is it just me?  My XO's 
connection is pretty weak most of the time, but not *that* weak.  I can 
ping updates.laptop.org with no packet loss.

 Still, please let us know when you're unable to update to builds with
 olpc-update, and file bugs if necessary.

It just said it didn't think such a build existed.

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

Re: Nortel LearniT animations (Seth Woodworth)

2008-03-23 Thread Bryan Berry

Edward Cherlin Wrote:
 That might be the quickest strategy, but I don't agree that it is the best.
 
 * Gnash needs funding and developers. Let's do it. Rob Savoye says, as
 I understand it, that more codecs have been cracked but not coded for.
 Rob, can we get the list? Is there a roadmap for implementation? I
 didn't see it in any of the obvious places.

Sugar needs more developers, the XS needs more developers and resources,
this project as a whole needs a lot more resources. 

There are a lot of awesome flash-based modules for magnetism,
electricity, math, and basic science. Flash is pervasive in educational
courseware development. We shouldn't make kids wait until we come up
with a completely free alternative to Flash. 

One aspect of this project is that kids can discover things on their
own. If we have very limited flash support we are limiting what kids can
discover to works that we have transcoded or Gnash fully supports.

OLPC can't bundle flash into their images but they can make it
significantly easier for deployment teams to add it as an .xo bundle
just as we currently add custom activity bundles. 

I agree that the long-term strategy should be to support Gnash and/or
get Adobe to open up their Flash player. But we have pilots running now
and kids that want to learn science, mathematics, English, etc. Let's
not make them wait.

Bryan
Kathmandu

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

New joyride build 1796

http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1796

Changes in build 1796 from build: 1794

Size delta: 0.00M

-libabiword 2.6.0.svn20071127-1
+libabiword 2.6.0.svn20071127-2

--- Changes for libabiword 2.6.0.svn20071127-2 from 2.6.0.svn20071127-1 ---
  + Fix 6170: shared write activity crash on joined machine when changing
  + Fix 5291: Files are written with wrong extension (uwog)

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

New faster build 1796