headers
Jim Gettys | 1 Feb 04:11
Favicon
Gravatar

What's left for Update.1

For comment and discussion, here are the showstoppers I know of for
getting Update.1 finished.  If you think there are others, please speak
up now (and modify the subject line to start another thread).

Activity developers: note we'll be asking you to upload updated
activities to pick up all the recent flurry of translation work very
soon.

 1 - wireless firmware and driver support 
		(to fix problems with WEP and WPA)
 2 - q2d11 OFW - to fix battery problems
 3 - update activities to pick up translation work, Spanish 
	in particular, but not missing other languages we may need.
 4 - UI fix for registration with the school server.
http://dev.laptop.org/ticket/6136
 5 - switch to gabble from salut at school.
 6 -testing and fixing anything critical!

If we don't want to hold up an RC2 to pick up translation, then we
should anticipate an RC4 might be necessary (as we may have issues that
come up with updated activities).

4 - we previously (without Dave Woodhouse being available to add to the
discussion) thought we could/should punt #6135 and release note.
However, talking with him about what we should really fix given his
experience in Mongolia, the lack of positive confirmation that the
laptop actually was registered is a real issue.  The teachers are not
familiar with English (or computers), and the subtlety of a menu entry
going away isn't good enough.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Yoshiki Ohshima | 2 Feb 08:09
Gravatar

Re: Using Matplotlib in Measure Activity

At Thu, 31 Jan 2008 12:38:01 -0500,
Benjamin M. Schwartz wrote:
> 
> On Thu, 2008-01-31 at 01:32 -0500, Arjun Sarwal wrote:
> > For some time I have been thinking about extending the functionality
> > of Measure Activity into a tool that also allows for graphical
> > analysis of data acquired not just from sensors/mic but data acquired
> > from any source. 
> > (1) A standard format for data sets.
> > (2) To allow for a variety of multiple views, representations and
> > basically allowing more control over the way data is represented
> 
> What you are describing is precisely the plotter component of any
> standard spreadsheet.  In my experience, plotting data  is by far the
> most common use of spreadsheets by children.  I would welcome such an
> Activity, and indeed, there is an effort to provide a spreadsheet for
> OLPC.
> 
> I do not think is makes sense to merge measurement of signals with data
> analysis.  I would suggest that "Measure Signals" and "Process Data"
> should be separate activities, with an easy Keep-Resume path between
> them.

  Really?  What happens if a kid want to see real-time data in
different way(s)?  If there is an oscilloscope that is only able to
show data from 10 seconds ago or such, it would be useless.

  Let us say we write an equivalent thing of Measure in Etoys.  Then,
kids can make their own graphing tool interactively.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marco Pesenti Gritti | 2 Feb 10:55
Picon

Use disttag when building packages

Hello,

please use disttag when building packages in koji. For example:

Version: 0.75.11
Release: 1%{?dist}

It makes it easier to distinguish OLPC specific packages and allows to
build the same packages also for Fedora.

Thanks,
Marco
Permalink | Reply | 0 comments |
headers
Morgan Collett | 2 Feb 14:31
Picon

Gabble vs Salut (Re: What's left for Update.1)

Jim Gettys wrote:

> I think we need to seriously discuss about possibly/probably being
> update.1 fodder is the "kids arrive at school in the morning" problem.
> 
> 5 - Use of mesh in large, crowded environments
> If everyone arrives at school running local link and resumed quickly,
> the network might melt from mdns mesh traffic's interaction with the
> mesh's implementation of mutlicast.  We've upped the multicast bitrate
> for multicast as a band aid, until we can dynamically adjust the
> bitrate.  But the fundamental issue comes that in large, dense school
> environments, can't expect multicast to scale far enough, and should be
> using unicast to a presence server (jabber in our current case) to
> handle this problem.
> 
> Dave Woodhouse has suggested may be to try to get a response to the
> school server's anycast address, and if we get a response from a school
> server, switch from Salut to Gabble for presence service automatically.

Rob logged #6299 about this (presence service should disable salut in
the presence of school servers on mesh). We should try the schoolserver
before enabling Salut.

He proposed an algorithm and some open questions regarding timeouts. We
need some feedback on those, and more info on the anycast address.

> Another temporary solution would be to have Ohm ask NM to reconnect if
> the machine is suspended for more than some interval, say, 30 minutes.

Possibly related: I logged #6304 regarding my MP XO not being able to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Walter Bender | 2 Feb 19:30
Favicon

[Community-news] OLPC News 2008-02-02

1. Active antennae: Another 90 prototype active antennae should be
available in a couple of weeks, followed shortly by a large shipment
of pre-build antennae scheduled to arrive in three or four weeks. The
initial run will be used mostly for field testing, with the majority
of the units going to Uruguay. They will be labeled as "engineering
samples—not for sale." We now have an update procedure for the
prototype antennae that allows them to stay connected to a server.
(These had been built with firmware that placed them in stand-alone
mesh-repeater mode too quickly, thus requiring them to be connected
only after a server is up and running.) See
http://wiki.laptop.org/go/Active_Antenna_Reprogramming.

2. Firmware: Mitch Bradley fixed a problem with OFW reading JFFS2
images (Ticket #6291) encountered when using the multicast update
method. (This was one of the bugs uncovered by David Woodhouse in
Mongolia last week.)

3. School server: Power continues to concern us. John Watlington
realized that the off-the-shelf server prototype he was looking at for
rural environments actually came with a 19VDC power supply, not a
12VDC one. While 12V supplies are available, they don't work well with
unregulated 12V input. With such a 12V supply, the server prototype
required around 16W while idling, and up to 26W when running three
meshes and doing heavy disk accesses. The current power consumption
requires four hours of pumping on a Weza to keep the server operating
for an eight hour day! We will also have to greatly improve the power
consumption when the machine is idle to have any hope of the servers
being left running when the schools aren't in session.

4. Embedded controller: Q2D10 had some battery charging regressions,
(Continue reading)

Permalink | Reply | 0 comments |
headers
C. Scott Ananian | 2 Feb 19:39
Favicon
Gravatar

Re: What's left for Update.1

On Jan 31, 2008 10:11 PM, Jim Gettys <jg <at> laptop.org> wrote:
>  2 - q2d11 OFW - to fix battery problems

We'll need a q2d12 to fix #6291, or plan for a update.1.1 for
deployments like Mongolia where we need to multicast-update large
groups of machines.

>  4 - UI fix for registration with the school server.
> http://dev.laptop.org/ticket/6136
>  5 - switch to gabble from salut at school.

Both of these might be candidates for an update.1.1, since they
involve code we don't even have in hand yet.

> mesh's implementation of mutlicast.  We've upped the multicast bitrate
> for multicast as a band aid, until we can dynamically adjust the
> bitrate.  But the fundamental issue comes that in large, dense school

No, the multicast bitrate fix is not included in Update.1 candidates;
Michalis indicated that it was not appropriate for general deployment,
since it greatly increases the multicast error rates in non-crowded
meshes.  There's a mesh TTL hack which was discussed and is also not
present in the current update.1 candidate; there's some disagreement
about it.

Considering the current state of our 'dense mesh' work, I would
strongly encourage that all of these issues be targetted to
update.1.1, so that we do not delay update.1 for other users any
longer than necessary.
 --scott
(Continue reading)

Permalink | Reply | 1 comment |
headers
Walter Bender | 2 Feb 20:10
Favicon

Re: [sugar] What's left for Update.1

I agree. We shouldn't hold up Update.1 on issues we don't already have
resolutions in hand for. Now is the time for testing, not further
changes.

-walter

On 2/2/08, C. Scott Ananian <cscott <at> laptop.org> wrote:
> On Jan 31, 2008 10:11 PM, Jim Gettys <jg <at> laptop.org> wrote:
> >  2 - q2d11 OFW - to fix battery problems
>
> We'll need a q2d12 to fix #6291, or plan for a update.1.1 for
> deployments like Mongolia where we need to multicast-update large
> groups of machines.
>
> >  4 - UI fix for registration with the school server.
> > http://dev.laptop.org/ticket/6136
> >  5 - switch to gabble from salut at school.
>
> Both of these might be candidates for an update.1.1, since they
> involve code we don't even have in hand yet.
>
> > mesh's implementation of mutlicast.  We've upped the multicast bitrate
> > for multicast as a band aid, until we can dynamically adjust the
> > bitrate.  But the fundamental issue comes that in large, dense school
>
> No, the multicast bitrate fix is not included in Update.1 candidates;
> Michalis indicated that it was not appropriate for general deployment,
> since it greatly increases the multicast error rates in non-crowded
> meshes.  There's a mesh TTL hack which was discussed and is also not
> present in the current update.1 candidate; there's some disagreement
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sayamindu Dasgupta | 2 Feb 20:45
Picon
Gravatar

Fontconfig Bug (#6046) [WAS: Re: What's left for Update.1]

Hi,

On Feb 1, 2008 8:41 AM, Jim Gettys <jg <at> laptop.org> wrote:
> For comment and discussion, here are the showstoppers I know of for
> getting Update.1 finished.  If you think there are others, please speak
> up now (and modify the subject line to start another thread).
>
> Activity developers: note we'll be asking you to upload updated
> activities to pick up all the recent flurry of translation work very
> soon.
>
>  1 - wireless firmware and driver support
>                 (to fix problems with WEP and WPA)
>  2 - q2d11 OFW - to fix battery problems
>  3 - update activities to pick up translation work, Spanish
>         in particular, but not missing other languages we may need.
>  4 - UI fix for registration with the school server.
> http://dev.laptop.org/ticket/6136
>  5 - switch to gabble from salut at school.
>  6 -testing and fixing anything critical!
>

I think it would be a good idea to get the fix for issue #6046 (browse
is slow after update from ship.2 to update.1 or joyride) in Update.1,
since this particular bug makes Browse virtually unuseable for 3-4
hours after an upgrade from Ship.2.
The changes I made to fontconfig are minimal
(http://dev.laptop.org/attachment/ticket/6046/FcConfigUptoDate_fix.patch)
and a package (already in koji) has appeared in the joyride builds.
I'll probably request for an approval for inclusion into Update1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hemant Goyal | 2 Feb 20:49
Picon

Some programming problems wrt XO and speech synthesis

Hi,

These are a few issues I want to tackle with respect to speech-synthesis on the XO:
  1. Provide a Play button on the top right corner of the sugar shell. (How can i integrate the button there?)
  2. When the user clicks it becomes a resume button. (Where do i write code for handling these clicks? Any specific files of sugar?)
  3. When the button is clicked the text on the clipboard is sent through the speech-dispatcher for speech synthesis. (I 'll simply use the gtk clipboard api for this)
  4. If the user hovers on the button for long, a palette appears exposing the speech synthesis parameters. It has sliders for changing rate,pitch and volume and a drop down box for choosing the voice.
  5. These configuration settings must be stored in some place on the XO so that they can be retrieved when the XO reboots, or the palette is shown again.
  6. How can I automate the process of connecting to the speech-dispatcher when the XO boots, and load all the configuration settings?
  7. When the palette disappears the new settings are stored in some location so that they can be retrieved when the xo reboots or the palette pops up again.
I have opened a ticket for inclusion of speech-dispatcher on the XO and hope the request will be accepted soon: http://dev.laptop.org/ticket/6284

I am afraid I dont have much experience with programming to solve the above problems. Any ideas would be great pointers!

Thanks!
--
Hemant
_______________________________________________
Sugar mailing list
Sugar <at> lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Permalink | Reply | 2 comments |
headers
Benjamin M. Schwartz | 3 Feb 21:42
Picon

DBus-python and signals with changing types


I would like to create a simple D-Bus signal of the form

    @dbus.service.signal(dbus_interface=self.IFACE)
    def send(self, message):
        return

However, I do not know the type signature of "message" ahead of time.  I also do
not know whether the user wants byte_arrays=True, etc.  I would like to set
these parameters each time send() is called.  How can I do this?

The only way that I have thought of is to do:

def send(self, message, signature=None, byte_arrays=True):
    self._sig = signature
    self._ba = byte_arrays
    self._actual_send(message)

@dbus.service.signal(dbus_interface=self.IFACE, signature=self._sig,
byte_arrays=self._ba)
def _actual_send(self, message):
    return

Will this work?  Is it threadsafe (I think not)? Is there a better way?

--Ben
Permalink | Reply | 4 comments |

Gmane