Re: Can't find shared library libusb

[Tomeu Vizoso]

On Fri, Oct 15, 2010 at 21:24, Emiliano Pastorino
 wrote:
> Hi everyone,
>
> I'm trying to use libusb, but I'm getting this behaviour in python:
>
>>> from ctypes.util import find_library
>>> find_library('usb')
>>>
> (returned None)

What about "find_library('usb-1.0')"?

It's probably good that you need to specify the version in this case
because the API between 0.1 and 1.0 is likely to have changed. This is
because there's no libusb.so symlink.

Regards,

Tomeu

> The strange thing is that in another XO, same build (802), it does find the
> library:
>>> from ctypes.util import find_library
>>> find_library('usb')
>>> 'libusb-0.1-so.4'
> Both XO have this file in /usr/lib, but the first one won't find it.
> Nevertheless, it finds other libraries under /usr/lib.
>
> I've checked /etc/ld.so.conf and it's the same for both XO.
> I'm using the same version of libusb and libusb-devel, and they were
> installed with yum.
> Any tips?
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Memory leak in Sugar -- how to dump Py data structures?

[Tomeu Vizoso]

On Thu, Oct 7, 2010 at 22:01, Tim McNamara  wrote:
> On 8 October 2010 03:34, Martin Langhoff  wrote:
>>
>> See http://dev.laptop.org/ticket/10386 for details. The sugar-session
>> process in 10.1.2 grows slowly...
>>
>> There's some form of leak somewhere. Maybe we are triggerin a real
>> python leak, maybe we have reference loops. How do we trace this?
>
> This post seems pretty good [1]. It cites a tool that creates an object
> graph that visually represents what is happening in memory.[2]
>
> [1] http://www.lshift.net/blog/2008/11/14/tracing-python-memory-leaks
> [2] http://mg.pov.lt/blog/python-object-graphs.html

Those are good links, in this case I suspect those icons, or any other
object referenced inside a cycle that also contains an AP icon, are
listening for a signal in a longer-lived object, which prevents the
whole cycle to be freed. We need to either disconnect from that signal
when the icon is no longer needed, or use a weak reference.

I will be looking at a similar issue in the next few days but in 0.90,
I will know by then.

Regards,

Tomeu

> ___
> 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: Empty list view

[Tomeu Vizoso]

On Wed, Sep 29, 2010 at 13:17, javed khan  wrote:
> thanks man
> i fixed it
> there is a patch for the sugar 0.84
> https://crank.laptop.org/attachment/ticket/10372/0001-If-the-string-does-not-contain-a-conversion-specifie.patch
> i change the line 228 for util.py
> from elapsed_units) % elapsed_units
> to elapsed_units)

Hi,

I'm just forwarding this to the list to let people know that Javed has
found a solution.

Regards,

Tomeu

> On Wed, Sep 29, 2010 at 3:40 PM, Tomeu Vizoso  wrote:
>>
>> On Wed, Sep 29, 2010 at 13:03, javed khan  wrote:
>> > here is the log
>>
>> Seems to be an issue with localization:
>>
>> /usr/lib/python2.5/site-packages/sugar/util.py in
>> timestamp_to_elapsed_string(timestamp=dbus.Double(1285751109.0,
>> variant_level=1), max_levels=2)
>>    226
>>    227             time_period += _ngettext(name_singular, name_plural,
>> --> 228                                      elapsed_units) %
>> elapsed_units
>>        elapsed_units = 1
>>    229
>>    230             elapsed_seconds -= elapsed_units * factor
>>
>> TypeError: not all arguments converted during string formatting
>>
>> Simon and the rest of the Sugar OLPC team are aware of the issue and
>> have a fix coming, though not sure if for 0.82.
>>
>> Regards,
>>
>> Tomeu
>>
>> >
>> > On Wed, Sep 29, 2010 at 3:19 PM, Tomeu Vizoso 
>> > wrote:
>> >>
>> >> On Wed, Sep 29, 2010 at 12:44, javed khan 
>> >> wrote:
>> >> > Hi All
>> >> >
>> >> > when i click on the list view i could not find any activity there.
>> >> > the language setting is set to Pashto Afghanistan (LANG="ps_AF.utf8")
>> >> > the sugar version is 0.82.1
>> >> >
>> >> > any suggetion
>> >>
>> >> Can you attach ~/.sugar/default/logs/shell.log?
>> >>
>> >> Thanks,
>> >>
>> >> Tomeu
>> >>
>> >> > Regards
>> >> >
>> >> > --
>> >> > Javid Alam
>> >> > Software Developer and Technical support Officer OLPC
>> >> > Ministry of Education
>> >> > Kabul Afghanistan
>> >> > contact: +93(0)798123451
>> >> > alternative email: javid.a...@moe.gov.af
>> >> >
>> >> > ___
>> >> > Devel mailing list
>> >> > Devel@lists.laptop.org
>> >> > http://lists.laptop.org/listinfo/devel
>> >> >
>> >> >
>> >
>> >
>> >
>> > --
>> > Javid Alam
>> > Software Developer and Technical support Officer OLPC
>> > Ministry of Education
>> > Kabul Afghanistan
>> > contact: +93(0)798123451
>> > alternative email: javid.a...@moe.gov.af
>> >
>
>
>
> --
> Javid Alam
> Software Developer and Technical support Officer OLPC
> Ministry of Education
> Kabul Afghanistan
> contact: +93(0)798123451
> alternative email: javid.a...@moe.gov.af
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Empty list view

[Tomeu Vizoso]

On Wed, Sep 29, 2010 at 13:03, javed khan  wrote:
> here is the log

Seems to be an issue with localization:

/usr/lib/python2.5/site-packages/sugar/util.py in
timestamp_to_elapsed_string(timestamp=dbus.Double(1285751109.0,
variant_level=1), max_levels=2)
226
227 time_period += _ngettext(name_singular, name_plural,
--> 228  elapsed_units) % elapsed_units
elapsed_units = 1
229
230 elapsed_seconds -= elapsed_units * factor

TypeError: not all arguments converted during string formatting

Simon and the rest of the Sugar OLPC team are aware of the issue and
have a fix coming, though not sure if for 0.82.

Regards,

Tomeu

>
> On Wed, Sep 29, 2010 at 3:19 PM, Tomeu Vizoso  wrote:
>>
>> On Wed, Sep 29, 2010 at 12:44, javed khan  wrote:
>> > Hi All
>> >
>> > when i click on the list view i could not find any activity there.
>> > the language setting is set to Pashto Afghanistan (LANG="ps_AF.utf8")
>> > the sugar version is 0.82.1
>> >
>> > any suggetion
>>
>> Can you attach ~/.sugar/default/logs/shell.log?
>>
>> Thanks,
>>
>> Tomeu
>>
>> > Regards
>> >
>> > --
>> > Javid Alam
>> > Software Developer and Technical support Officer OLPC
>> > Ministry of Education
>> > Kabul Afghanistan
>> > contact: +93(0)798123451
>> > alternative email: javid.a...@moe.gov.af
>> >
>> > ___
>> > Devel mailing list
>> > Devel@lists.laptop.org
>> > http://lists.laptop.org/listinfo/devel
>> >
>> >
>
>
>
> --
> Javid Alam
> Software Developer and Technical support Officer OLPC
> Ministry of Education
> Kabul Afghanistan
> contact: +93(0)798123451
> alternative email: javid.a...@moe.gov.af
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Empty list view

[Tomeu Vizoso]

On Wed, Sep 29, 2010 at 12:44, javed khan  wrote:
> Hi All
>
> when i click on the list view i could not find any activity there.
> the language setting is set to Pashto Afghanistan (LANG="ps_AF.utf8")
> the sugar version is 0.82.1
>
> any suggetion

Can you attach ~/.sugar/default/logs/shell.log?

Thanks,

Tomeu

> Regards
>
> --
> Javid Alam
> Software Developer and Technical support Officer OLPC
> Ministry of Education
> Kabul Afghanistan
> contact: +93(0)798123451
> alternative email: javid.a...@moe.gov.af
>
> ___
> 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: #10363 NORM 10.1.3: Auto-Suspend gets in the way when sharing over Salut

[Tomeu Vizoso]

On Tue, Sep 28, 2010 at 21:43, Gonzalo Odiard  wrote:
> We have this code in many places, I found it in the Distance activity and
> bitfrost updater.
> May be is a good idea inhibit suspend when is displayed the neighborhood
> view also.
> Can we have a unique class like PowerManager or anything like that?

Good with me if that's the way to go from the POV of the systems
people, would be great if it could be implemented in Sugar in terms of
org.freedesktop.UPower, so we don't need to maintain two or more
backends.

Regards,

Tomeu

> Regards
>
> Gonzalo
>
>
> On Thu, Sep 16, 2010 at 8:23 PM, James Cameron  wrote:
>>
>> On Thu, Sep 16, 2010 at 05:38:29PM -0400, Martin Langhoff wrote:
>> > 2 - hack the Tubes/Telepathy stack to _prevent sleep_ while an actual
>> > collaboration session is running
>>
>> This might help.  Once an activity is shared, the laptop stays awake
>> until the activity is stopped.
>>
>> (sugar-toolkit.git)
>> --- a/src/sugar/activity/activity.py
>> +++ b/src/sugar/activity/activity.py
>> @@ -916,6 +916,14 @@ class Activity(Window, gtk.Container):
>>         self._share_id = self._pservice.connect("activity-shared",
>>                                                 self.__share_cb)
>>         self._pservice.share_activity(self, private=private)
>> +        # inhibit suspend during sharing
>> +        path = '/var/run/powerd-inhibit-suspend/%s' % os.getpid()
>> +        try:
>> +            fd = open(path, 'w')
>> +        except IOError:
>> +            pass
>> +        else:
>> +            fd.close()
>>
>>     def _show_keep_failed_dialog(self):
>>         alert = Alert()
>>
>> --
>> James Cameron
>> http://quozl.linux.org.au/
>> ___
>> Devel mailing list
>> Devel@lists.laptop.org
>> http://lists.laptop.org/listinfo/devel
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Introduction

[Tomeu Vizoso]

On Tue, Sep 28, 2010 at 12:46, Steven Parrish  wrote:
> Some of you may have already heard that I have accepted a position
> with ActivityCentral to be the project manager for Dextrose.  It feels
> like I have come full circle as I started out as a volunteer
> maintaining the "F11 for the XO-1" builds for the past 18 months.
> That work was very rewarding and I was glad to see OLPC step in and
> release official builds based on my work.  The "F11 for the XO-1" was
> also a starting point for the original Dextrose system, which Bernie
> Innocenti brought to fruition.
>
> Now we will be taking the original Dextrose and expanding upon it.
> Dextrose2 will be the result.  Based on Fedora11 and Sugar 0.88 it
> will strive for stability, while providing deployments with a
> customizable product.  I have already started creating builds for the
> new system with additional language support, and they can be found at
> http://wiki.sugarlabs.org/go/Dextrose .  The builds will be for both
> the XO-1 and XO-1.5 and will be available both with Gnome and without.
>
> We have a team of developers at SEETA who will be working on this with
> us.  Many of them are already known to the community and more will
> become known as they join the effort.
>
> I have already started going over the outstanding issues and know that
> with everyone's help we can make Dextrose the Premier system for XO
> deployments.
>
> The issues that need to be worked on can be found at:
>
> http://bugs.sugarlabs.org/query?status=accepted&status=assigned&status=new&status=reopened&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&keywords=$love
>
> and
>
> http://bugs.sugarlabs.org/query?status=accepted&status=assigned&status=new&status=reopened&order=priority&col=id&col=summary&col=component&col=status&col=type&col=priority&col=milestone&keywords=$extrose
>
> If you are already working on any of these tickets please send me a
> quick note as to which tickets you are working on and what the status
> is.
>
> I look forward to working with everyone.

I'm very happy to read this, look forward to work further with you.

It would be very helpful if any new contributors could take the time
to present themselves and their plans as you have done.

Regards,

Tomeu

> Steven Parrish
> smparr...@gmail.com
> ___
> 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: activity help

[Tomeu Vizoso]

On Mon, Sep 27, 2010 at 06:45, javed khan  wrote:
> Hi Guys
>
> i have few questions
>
> 1. can we create a shortcut for a library bundle in the favorite view ?

The support for content bundles has changed a lot in every version of
Sugar and it also can have regressed as the consensus seem to be to
create activities that bundle the content as you are proposing below.

> 2. i created an activity which display html the code is
>

[activity code snipped]

> this html file also contain some pdf file. the html files are working fine
> but when i click on a pdf file nothing happens.
> is it possible to view the pdf in this activity?

I would investigate using the in-browse pdf viewer that Sayamindu developed.

Regards,

Tomeu

> Regards
> --
> Javid Alam
> Software Developer and Technical support Officer OLPC
> Ministry of Education
> Kabul Afghanistan
> contact: +93(0)798123451
> alternative email: javid.a...@moe.gov.af
>
> ___
> 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: #10363 NORM 10.1.3: Auto-Suspend gets in the way when sharing over Salut

[Tomeu Vizoso]

On Fri, Sep 24, 2010 at 09:12, Simon Schampijer  wrote:
> On 09/23/2010 03:30 PM, Tomeu Vizoso wrote:
>> On Mon, Sep 20, 2010 at 12:56, Paul Fox  wrote:
>>> tomeu wrote:
>>>   >  On Thu, Sep 16, 2010 at 23:38, Martin Langhoff
>>>   >    wrote:
>>>   >  >  On Thu, Sep 16, 2010 at 5:05 AM, Tomeu 
>>> Vizoso  wrote:
>>>   >  >>  So the problem is that if you had to resync all state for each 
>>> machine
>>>   >  >>  every time they wake up, you would use lots of bandwidth with the
>>>   >  >  (...)
>>>   >  >>  Another issue with this is that you not only want to resync 
>>> presence,
>>>   >  >>  but shared activities also would need to resync their state.
>>>   >  >
>>>   >  >  Correct. My notes on the bug are probably unreadable -- it was late
>>>   >  >  last night, apologies.
>>>   >  >
>>>   >  >  What I mean to say is that we could
>>>   >  >
>>>   >  >  1 - explore the interaction between sleep timeouts and Salut resync
>>>   >  >  frequency for presence
>>>   >  >
>>>   >  >  2 - hack the Tubes/Telepathy stack to _prevent sleep_ while an 
>>> actual
>>>   >  >  collaboration session is running
>>>   >  >
>>>   >  >  I think #1 needs to be done regardless, as it'll improve behaviour
>>>   >  >  even if/when we our networking/suspend issues sorted. And some of 
>>> the
>>>   >  >  issues in network/suspend interaction won't be easy to resolve.
>>>   >
>>>   >  I doubt there's much that can be done in Salut about it, should be
>>>   >  instead done inside Avahi. I would see how mDNS works, then look for
>>>   >  opportunities of tuning knobs in Avahi to speed up rediscovery:
>>>   >
>>>   >  http://tools.ietf.org/html/draft-ietf-dnsext-mdns-47
>>>   >
>>>   >  I'm going to ask around in case somebody has already thought of it and
>>>   >  can provide a shortcut.
>>>
>>> the laptop knows how long it was suspended, and this information could
>>> be made available to a resume hook (which almost exists, but not
>>> quite, in powerd) if it would be useful.  i.e., a a post-resume script
>>> could decide whether to kick the protocols to do something differently,
>>> if that was needed.
>>
>> Paul, what do you think about powerd implementing org.freedesktop.UPower ?
>>
>> http://upower.freedesktop.org/docs/UPower.html
>>
>> Regards,
>>
>> Tomeu
>
> UPower is available in Fedora >= 13 AFAIK. We are still stuck at the
> moment with F11. So, that road is meant as Future possibilities, right?

Not really, powerd could implement the same DBus interface. You would
need to backport something for Avahi to use it, though.

Regards,

Tomeu

> Regards,
>    Simon
> ___
> 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: #10363 NORM 10.1.3: Auto-Suspend gets in the way when sharing over Salut

[Tomeu Vizoso]

On Thu, Sep 23, 2010 at 15:30, Tomeu Vizoso  wrote:
> On Mon, Sep 20, 2010 at 12:56, Paul Fox  wrote:
>> tomeu wrote:
>>  > On Thu, Sep 16, 2010 at 23:38, Martin Langhoff
>>  >  wrote:
>>  > > On Thu, Sep 16, 2010 at 5:05 AM, Tomeu Vizoso  
>> wrote:
>>  > >> So the problem is that if you had to resync all state for each machine
>>  > >> every time they wake up, you would use lots of bandwidth with the
>>  > > (...)
>>  > >> Another issue with this is that you not only want to resync presence,
>>  > >> but shared activities also would need to resync their state.
>>  > >
>>  > > Correct. My notes on the bug are probably unreadable -- it was late
>>  > > last night, apologies.
>>  > >
>>  > > What I mean to say is that we could
>>  > >
>>  > > 1 - explore the interaction between sleep timeouts and Salut resync
>>  > > frequency for presence
>>  > >
>>  > > 2 - hack the Tubes/Telepathy stack to _prevent sleep_ while an actual
>>  > > collaboration session is running
>>  > >
>>  > > I think #1 needs to be done regardless, as it'll improve behaviour
>>  > > even if/when we our networking/suspend issues sorted. And some of the
>>  > > issues in network/suspend interaction won't be easy to resolve.
>>  >
>>  > I doubt there's much that can be done in Salut about it, should be
>>  > instead done inside Avahi. I would see how mDNS works, then look for
>>  > opportunities of tuning knobs in Avahi to speed up rediscovery:
>>  >
>>  > http://tools.ietf.org/html/draft-ietf-dnsext-mdns-47
>>  >
>>  > I'm going to ask around in case somebody has already thought of it and
>>  > can provide a shortcut.
>>
>> the laptop knows how long it was suspended, and this information could
>> be made available to a resume hook (which almost exists, but not
>> quite, in powerd) if it would be useful.  i.e., a a post-resume script
>> could decide whether to kick the protocols to do something differently,
>> if that was needed.
>
> Paul, what do you think about powerd implementing org.freedesktop.UPower ?
>
> http://upower.freedesktop.org/docs/UPower.html

If so, Lennart could be interested in accepting a patch that makes
Avahi listen for Resuming() and that implements the wake-up behavior
as specified in
http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt .

After a quick read, looks like it would involve querying the network
with the QU bit set so the other nodes can send unicast replies
instead of multicast, thus saving bandwidth.

Regards,

Tomeu

> Regards,
>
> Tomeu
>
>> paul
>> =-
>>  paul fox, p...@laptop.org
>>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: #10363 NORM 10.1.3: Auto-Suspend gets in the way when sharing over Salut

[Tomeu Vizoso]

On Mon, Sep 20, 2010 at 12:56, Paul Fox  wrote:
> tomeu wrote:
>  > On Thu, Sep 16, 2010 at 23:38, Martin Langhoff
>  >  wrote:
>  > > On Thu, Sep 16, 2010 at 5:05 AM, Tomeu Vizoso  
> wrote:
>  > >> So the problem is that if you had to resync all state for each machine
>  > >> every time they wake up, you would use lots of bandwidth with the
>  > > (...)
>  > >> Another issue with this is that you not only want to resync presence,
>  > >> but shared activities also would need to resync their state.
>  > >
>  > > Correct. My notes on the bug are probably unreadable -- it was late
>  > > last night, apologies.
>  > >
>  > > What I mean to say is that we could
>  > >
>  > > 1 - explore the interaction between sleep timeouts and Salut resync
>  > > frequency for presence
>  > >
>  > > 2 - hack the Tubes/Telepathy stack to _prevent sleep_ while an actual
>  > > collaboration session is running
>  > >
>  > > I think #1 needs to be done regardless, as it'll improve behaviour
>  > > even if/when we our networking/suspend issues sorted. And some of the
>  > > issues in network/suspend interaction won't be easy to resolve.
>  >
>  > I doubt there's much that can be done in Salut about it, should be
>  > instead done inside Avahi. I would see how mDNS works, then look for
>  > opportunities of tuning knobs in Avahi to speed up rediscovery:
>  >
>  > http://tools.ietf.org/html/draft-ietf-dnsext-mdns-47
>  >
>  > I'm going to ask around in case somebody has already thought of it and
>  > can provide a shortcut.
>
> the laptop knows how long it was suspended, and this information could
> be made available to a resume hook (which almost exists, but not
> quite, in powerd) if it would be useful.  i.e., a a post-resume script
> could decide whether to kick the protocols to do something differently,
> if that was needed.

Paul, what do you think about powerd implementing org.freedesktop.UPower ?

http://upower.freedesktop.org/docs/UPower.html

Regards,

Tomeu

> paul
> =-
>  paul fox, p...@laptop.org
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: #10363 NORM 10.1.3: Auto-Suspend gets in the way when sharing over Salut

[Tomeu Vizoso]

On Mon, Sep 20, 2010 at 12:56, Paul Fox  wrote:
> tomeu wrote:
>  > On Thu, Sep 16, 2010 at 23:38, Martin Langhoff
>  >  wrote:
>  > > On Thu, Sep 16, 2010 at 5:05 AM, Tomeu Vizoso  
> wrote:
>  > >> So the problem is that if you had to resync all state for each machine
>  > >> every time they wake up, you would use lots of bandwidth with the
>  > > (...)
>  > >> Another issue with this is that you not only want to resync presence,
>  > >> but shared activities also would need to resync their state.
>  > >
>  > > Correct. My notes on the bug are probably unreadable -- it was late
>  > > last night, apologies.
>  > >
>  > > What I mean to say is that we could
>  > >
>  > > 1 - explore the interaction between sleep timeouts and Salut resync
>  > > frequency for presence
>  > >
>  > > 2 - hack the Tubes/Telepathy stack to _prevent sleep_ while an actual
>  > > collaboration session is running
>  > >
>  > > I think #1 needs to be done regardless, as it'll improve behaviour
>  > > even if/when we our networking/suspend issues sorted. And some of the
>  > > issues in network/suspend interaction won't be easy to resolve.
>  >
>  > I doubt there's much that can be done in Salut about it, should be
>  > instead done inside Avahi. I would see how mDNS works, then look for
>  > opportunities of tuning knobs in Avahi to speed up rediscovery:
>  >
>  > http://tools.ietf.org/html/draft-ietf-dnsext-mdns-47
>  >
>  > I'm going to ask around in case somebody has already thought of it and
>  > can provide a shortcut.
>
> the laptop knows how long it was suspended, and this information could
> be made available to a resume hook (which almost exists, but not
> quite, in powerd) if it would be useful.  i.e., a a post-resume script
> could decide whether to kick the protocols to do something differently,
> if that was needed.

Pinged Lennart in #fedora-desktop and he said that if avahi isn't
trying harder to update its state after resuming it's because there
isn't a decent hook for that in Linux yet.

I couldn't get from him any other useful information, but maybe this
is a chance to explore ways in which Avahi can update itself faster
after sleep? If there's interest, I think this should be moved to the
avahi list.

Regards,

Tomeu

> paul
> =-
>  paul fox, p...@laptop.org
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Sugar on Tablet - On Screen Keyboard

[Tomeu Vizoso]

On Tue, Sep 21, 2010 at 06:56, Narendra Sisodiya
 wrote:
> Is anybody working on Onscreen Keyboard or related stuff on Sugar ?
> also what is the current status and how I can contribute.
> We got some success to bring Sugar on ARM tablets[1]. now we are
> exploring more. need suggestion too

Hi, Sayamindu posted recently about his work porting the Meego
on-screen keyboard to Sugar. Search the archives of this list or
sugar-devel's.

Regards,

Tomeu

>
> [1] - 
> http://blog.narendrasisodiya.com/2010/09/fedora-12-olpc-sugar-on-arm.html
> --
> ┌─┐
> │    Narendra Sisodiya
> │    http://narendrasisodiya.com
> └─┘
> ___
> 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: #10363 NORM 10.1.3: Auto-Suspend gets in the way when sharing over Salut

[Tomeu Vizoso]

On Thu, Sep 16, 2010 at 23:38, Martin Langhoff
 wrote:
> On Thu, Sep 16, 2010 at 5:05 AM, Tomeu Vizoso  wrote:
>> So the problem is that if you had to resync all state for each machine
>> every time they wake up, you would use lots of bandwidth with the
> (...)
>> Another issue with this is that you not only want to resync presence,
>> but shared activities also would need to resync their state.
>
> Correct. My notes on the bug are probably unreadable -- it was late
> last night, apologies.
>
> What I mean to say is that we could
>
> 1 - explore the interaction between sleep timeouts and Salut resync
> frequency for presence
>
> 2 - hack the Tubes/Telepathy stack to _prevent sleep_ while an actual
> collaboration session is running
>
> I think #1 needs to be done regardless, as it'll improve behaviour
> even if/when we our networking/suspend issues sorted. And some of the
> issues in network/suspend interaction won't be easy to resolve.

I doubt there's much that can be done in Salut about it, should be
instead done inside Avahi. I would see how mDNS works, then look for
opportunities of tuning knobs in Avahi to speed up rediscovery:

http://tools.ietf.org/html/draft-ietf-dnsext-mdns-47

I'm going to ask around in case somebody has already thought of it and
can provide a shortcut.

Regards,

Tomeu

> 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: #10363 NORM 10.1.3: Auto-Suspend gets in the way when sharing over Salut

[Tomeu Vizoso]

On Thu, Sep 16, 2010 at 19:06, Richard A. Smith  wrote:
> On 09/16/2010 05:05 AM, Tomeu Vizoso wrote:
>
>> So the problem is that if you had to resync all state for each machine
>> every time they wake up, you would use lots of bandwidth with the
>> power consumption associated, so much that it may not have been worth
>> sleeping.
>
> Hmmm... /me has questions about this.  Care to give me your breakdown of
> what power you think you are using?
>
> Going in to suspend saves approx 3-4 Watts.  Even if you only suspended
> for 1 second generating enough WLAN traffic to use 3-4 watts _above_
> what you are already using for idle.  I'm not sure that is what would
> happen.

Sorry, I wasn't clear. I wasn't referring to the case when a laptop
wakes up and gets its collaboration state from a server, but to the
server-less case in which getting that state means querying all other
accessible nodes, thus waking them up.

The effect of a single laptop coming out from suspend would mean
reducing the total time that the network is sleeping, and the more
laptops in the network, the less time they can sleep and the more
often they have to update their whole state.

If we let the other laptops sleep, then from the optic of the user the
representation of the network is probably equally confusing as it is
now.

Frankly, I think I'm a newcomer to this discussion so it's quite
probable that I'm missing something. I would though leave Salut out
from this for now and focus on how mDNS could work in this
semi-connected use case.

Just for the sake of looking at what others have done in a similar
situation, Apple implemented Sleep Proxies:
http://en.wikipedia.org/wiki/Sleep_Proxy_Service But seems to have
been dropped from the last IETF draft.

Regards,

Tomeu

> --
> Richard A. Smith  
> One Laptop per Child
> ___
> 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: #10363 NORM 10.1.3: Auto-Suspend gets in the way when sharing over Salut

[Tomeu Vizoso]

On Thu, Sep 16, 2010 at 11:05, Tomeu Vizoso  wrote:
> On Wed, Sep 15, 2010 at 18:50, Zarro Boogs per Child
>  wrote:
>> #10363: Auto-Suspend gets in the way when sharing over Salut
>> ---+
>>           Reporter:  erikos           |       Owner:  erikos
>>               Type:  defect           |      Status:  new
>>           Priority:  normal           |   Milestone:  10.1.3
>>          Component:  telepathy-salut  |     Version:  Development build as 
>> of this date
>>         Resolution:                   |    Keywords:
>>        Next_action:  diagnose         |    Verified:  0
>> Deployment_affected:                   |   Blockedby:
>>           Blocking:                   |
>> ---+
>> Changes (by martin.langhoff):
>>
>>  * cc: greenfeld, tomeu (added)
>>
>>
>> Comment:
>>
>>  Was discussing this with Sam earlier.
>>
>>  Is there any workaround we can apply -- seems like Salut or the much
>>  maligned Presence Service has some regular event that re-syncs the nodes,
>>  can we make it more often? (Sam suggested this earlier though I didn't
>>  understand what he meant initially.)
>>
>>  Maybe Tomeu can give us a hint on whether such an event exists and what it
>>  is called so we can tune it? He'll have info on whether ths is likely to
>>  be an issue on 0.90 or not...
>
> Bringing this to de...@l.o where we are already discussing this issue.
>
> So the problem is that if you had to resync all state for each machine
> every time they wake up, you would use lots of bandwidth with the
> power consumption associated, so much that it may not have been worth
> sleeping.
>
> Another issue with this is that you not only want to resync presence,
> but shared activities also would need to resync their state. Which
> cannot be done without activity-level support which we don't have. It
> would also cause more traffic and power consumption in the network as
> a whole.

Forgot to mention that for gabble, you can tell some servers that you
are going to sleep and it will queue the presence updates for when you
wake up. So you won't be awoke by presence updates, just by direct
IM'ing.

This is right now implemented only in Google's XMPP server, but
there's quite a bit of a chance we could persuade the Prosody hackers
to implement something similar:

http://mail.jabber.org/pipermail/summit/2010-February/000528.html

Telepathy has already done some advances on an interface for such optimizations:

http://telepathy.freedesktop.org/spec/Connection_Interface_Power_Saving.html

Regards,

Tomeu

> Regards,
>
> Tomeu
>
>> --
>> Ticket URL: <http://dev.laptop.org/ticket/10363#comment:5>
>> One Laptop Per Child <http://laptop.org/>
>> OLPC bug tracking system
>>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: #10363 NORM 10.1.3: Auto-Suspend gets in the way when sharing over Salut

[Tomeu Vizoso]

On Wed, Sep 15, 2010 at 18:50, Zarro Boogs per Child
 wrote:
> #10363: Auto-Suspend gets in the way when sharing over Salut
> ---+
>           Reporter:  erikos           |       Owner:  erikos
>               Type:  defect           |      Status:  new
>           Priority:  normal           |   Milestone:  10.1.3
>          Component:  telepathy-salut  |     Version:  Development build as of 
> this date
>         Resolution:                   |    Keywords:
>        Next_action:  diagnose         |    Verified:  0
> Deployment_affected:                   |   Blockedby:
>           Blocking:                   |
> ---+
> Changes (by martin.langhoff):
>
>  * cc: greenfeld, tomeu (added)
>
>
> Comment:
>
>  Was discussing this with Sam earlier.
>
>  Is there any workaround we can apply -- seems like Salut or the much
>  maligned Presence Service has some regular event that re-syncs the nodes,
>  can we make it more often? (Sam suggested this earlier though I didn't
>  understand what he meant initially.)
>
>  Maybe Tomeu can give us a hint on whether such an event exists and what it
>  is called so we can tune it? He'll have info on whether ths is likely to
>  be an issue on 0.90 or not...

Bringing this to de...@l.o where we are already discussing this issue.

So the problem is that if you had to resync all state for each machine
every time they wake up, you would use lots of bandwidth with the
power consumption associated, so much that it may not have been worth
sleeping.

Another issue with this is that you not only want to resync presence,
but shared activities also would need to resync their state. Which
cannot be done without activity-level support which we don't have. It
would also cause more traffic and power consumption in the network as
a whole.

Regards,

Tomeu

> --
> Ticket URL: 
> One Laptop Per Child 
> OLPC bug tracking system
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Bad interaction between sleep timeouts and Salut?

[Tomeu Vizoso]

On Thu, Sep 16, 2010 at 05:26, James Cameron  wrote:
> On Wed, Sep 15, 2010 at 08:04:25PM -0400, Martin Langhoff wrote:
>> I am curious -- what is the frequency of "presence broadcasts" when
>> Salut is used? Where is it set?
>
> Three minutes.  Perhaps KEEPALIVE_TIMEOUT in
> gibber-r-multicast-causal-transport.c

So Salut is an implementation of XEP-0174: Serverless Messaging:

http://xmpp.org/extensions/xep-0174.html

In this section of the document is an overview of the different
components used by this protocol:

http://xmpp.org/extensions/xep-0174.html#howitworks

As you can see, basic presence is done with multicast DNS/DNS-SD and
Salut uses Avahi for that.

Gibber is a library internal to Salut that implements the other part
of the protocol: XMPP message passing between nodes.

With that in mind, what I would do next is to try to isolate the
problems within either Avahi or Gibber, that will reduce significantly
the amount of code we need to care about and will be useful in further
debugging and tuning. avahi-browse and avahi-discover are useful tools
for monitoring the state of Avahi, so if you could reproduce the same
issues there, then we could rule out a big chunk of code.

If that's the case, then these two functions in Salut would be most
relevant, the first announces a DNS service for the buddy and the
other does the same for shared activities:

http://git.collabora.co.uk/?p=telepathy-salut.git;a=blob;f=src/salut-avahi-self.c;h=dab2c78247c84bfba7b693251e6ac3703648eb13;hb=HEAD#l220

http://git.collabora.co.uk/?p=telepathy-salut.git;a=blob;f=src/salut-avahi-olpc-activity.c;h=2a3681aca7568d1c8bf4ce97b161f79c11ef6165;hb=HEAD#l157

Assuming the problem is in the Avahi level, we should make sure that
the system is coming out from suspend when the radio receives
multicast activity directed to us so Avahi can properly update its
internal state and also for activities using clique (multi-user chat
rooms on server-less XMPP). A couple more of references:

http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt
http://telepathy.freedesktop.org/wiki/Clique

With Gabble we should see similar effects if the machine is not
resuming when the Jabber server sends us updates.

Regards,

Tomeu

>> With current 10.1.2 using salut over ad-hoc the neighbourhood view
>> never stabilises, and it's very apparent that it's because nodes go to
>> sleep too quickly (before they see others, before they are seen). And
>> when awake, they take a long time to regain a good view of what's out
>> there.
>>
>> If we can experiment with the timeouts (knowing where the knobs are)
>> maybe we can find out...
>>
>> (Tomeu, I bother you because I suspect you'd know... hope it's not an
>> annoyance...)
>
> http://git.collabora.co.uk/?p=telepathy-salut.git;a=blob;f=lib/gibber/gibber-r-multicast-causal-transport.c;h=3cdb2a8d3b88de473ee473da3af15e280d355c26;hb=HEAD
>
> Salut over ad-hoc seems to use multicast packets, according to my
> tcpdump, so this source file appears relevant.
>
> The timers are specified there as constants, without configurable
> settings.  So if you don't mind fiddling with them and recompiling, it
> should be possible to improve the situation, at the expense of increased
> wireless traffic.
>
> Might also detect resume, evaluate time interval lost, and expire the
> timer sooner.
>
> --
> James Cameron
> http://quozl.linux.org.au/
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: question about bad cairo performance on the olpc xo

[Tomeu Vizoso]

On Fri, Sep 3, 2010 at 07:49, Erik Blankinship  wrote:
> I need help understanding why I am getting very poor frame rates when I use
> pycairo to move a large image around the screen on an olpc XO.  When I use
> pycairo to draw a rectangle of the same size on an XO, I get great
> performance!  This is confusing to me because in my experience on other
> platforms, redrawing vector graphics is much, much slower than blitzing
> bitmaps to the screen.
> Is there something particular about the XO hardware, its software stack, or
> cairo which retards the performance of displaying images?

I would run sysprof (or any other system-wide profiler) and see which
process and what code is taking most CPU.

Regards,

Tomeu

> The same test
> case runs fine on my desktop machine.
> Thank you!  Below is testing code and here is a link if you'd like to try it
> yourself in the gnome desktop on an XO (the same performance problems also
> occur when run as part of a sugar activity):
> http://alumni.media.mit.edu/~erikb/tmp/test.zip
> software notes: click to change the rectangle paint mode.   Green is a cairo
> vector rectangle.  Red-1 is a cairo image surface created by loading a png.
>  Blue is a cairo generated image_surface.  Red-1 is a gdk pixbuf created by
> loading a png.
>
>
> import gtk, gobject
>
> import cairo
>
> class DragTest( gtk.DrawingArea ):
>
>     __gsignals__ = {
>         "expose-event": "override",
>         "on-mouse-move": (gobject.SIGNAL_RUN_LAST, gobject.TYPE_NONE,
> (gobject.TYPE_PYOBJECT,)),
>         "on-mouse-down": (gobject.SIGNAL_RUN_LAST, gobject.TYPE_NONE,
> (gobject.TYPE_PYOBJECT,)),
>     }
>
>     def __init__(self):
>         gtk.DrawingArea.__init__(self)
>         self.set_events(gtk.gdk.POINTER_MOTION_MASK |
> gtk.gdk.BUTTON_PRESS_MASK)
>         self.connect("motion_notify_event", self.__on_mouse_move)
>         self.connect("button_press_event", self.__on_button_press)
>
>         self.box_w = 1210
>         self.box_h = 910
>
>         self.box_type = 0
>         self.box_x = 0
>         self.box_y = 0
>         self.cairo_img = cairo.ImageSurface( cairo.FORMAT_ARGB32,
> self.box_w, self.box_h )
>         ctx = cairo.Context( self.cairo_img )
>         ctx.set_source_rgb( 0, 0, 1 )
>         ctx.rectangle( 0, 0, self.box_w, self.box_h )
>         ctx.fill( )
>
>         self.cairo_file_img = cairo.ImageSurface.create_from_png( "bg.png" )
>
>         self.pixbuf = gtk.gdk.pixbuf_new_from_file( "bg.png" )
>
>
>     def __on_mouse_move(self, area, event):
>         self.box_x, self.box_y, mods = self.get_window().get_pointer()
>         self.queue_draw( )
>
>     def __on_button_press(self, area, event):
>         self.box_type += 1
>         if (self.box_type > 3):
>             self.box_type = 0
>         self.queue_draw( )
>
>
>     def do_expose_event(self, event):
>         context = self.window.cairo_create()
>
>         # clip to the visible part
>         context.rectangle(event.area.x, event.area.y,
>                           event.area.width, event.area.height)
>         context.clip()
>
>         if (self.box_type == 0):
>             context.set_source_rgb( 0, 1, 0 )
>
>         elif (self.box_type == 1):
>             context.set_source_surface( self.cairo_file_img, self.box_x,
> self.box_y )
>
>         elif (self.box_type == 2):
>             context.set_source_surface( self.cairo_img, self.box_x,
> self.box_y )
>
>         elif (self.box_type == 3):
>             context.set_source_pixbuf( self.pixbuf, self.box_x, self.box_y )
>
>
>         context.rectangle( self.box_x, self.box_y, self.box_w, self.box_h )
>         context.fill( )
>
>
> window = gtk.Window()
> window.set_size_request( 1210, 910 )
> window.connect( "delete_event", lambda *args: gtk.main_quit() )
> window.add( DragTest() )
> window.show_all()
> gtk.main()
>
>
>
> ___
> 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: Initial F14 developers-only release for XO and XO-1.5

[Tomeu Vizoso]

This is awesome news, kudos to Daniel.

On Wed, Sep 1, 2010 at 08:49, pbrobin...@gmail.com  wrote:
> Hey Daniel,
>
> Yippee! I suspect the sugar starting issues is the same one we're
> seeing in SoaS for F-14.

Hmm, I had some trouble on mainstream F-14 booting both Sugar and
GNOME (actually, even logging into the console was failing) but
booting with enforce=0 fixed it until an update fixed it for good.

Is it something different?

At this point I'm booting into Sugar from gdm without problems.

Regards,

Tomeu

> I'm very busy until Sunday but i hope to have
> at least some time to be able to look at that problem and help you out
> where possibly as no doubt both SoaS and the builds for the XO will
> share a lot of common problems.
>
> With the kernel nearing a recent release is there any plans to get a
> chunk of the kernel patches upstream to ease on going maintenance?
>
> As always ping me if there's anywhere specific I can be of assistance
> in upstream Fedora.
>
> Peter
>
> On Wed, Sep 1, 2010 at 6:22 AM, Daniel Drake  wrote:
>> Hi,
>>
>> After seeing the community help significantly with F11-on-XO
>> development, I'm wondering if we can do something similar for a future
>> release. So, I've taken the first few steps in getting OLPC's
>> technologies rebased on Fedora 14 and Linux v2.6.35.
>>
>> The result has lots of problems, but I figure that publishing the work
>> so far is the first step in getting things fixed.
>>
>> Things are in such an early stage that I'm labelling this as a
>> developers-only release. To name a few: Sugar crashes all the time,
>> the XO-1.5 camera doesn't work, there are some funky graphics bugs on
>> XO-1, no power management, DCON doesn't work right on either laptop,
>> desktop switching lands you at a blank screen.
>>
>> For now, please don't file bugs unless you include patches. And, to
>> take 1 bite at a time out of this huge task, lets ignore all but the
>> biggest sugar issues for now because there is plenty of OS work to be
>> done first. (or alternatively lets take sugar issues directly to SL
>> trac)
>>
>> And the links:
>> 2.6.35 kernel is in git://dev.laptop.org/olpc-2.6 branch olpc-2.6.35
>> OS build is done from 'f14' branch of olpc-os-builder
>> First released images are at http://build.laptop.org/F14/os1/
>> Trac is at http://dev.laptop.org/milestone/F14 (basically my immediate
>> TODO), please don't file tickets unless you include patches in these
>> early days
>>
>> Note: I haven't tested those exact images (since Chris @ OLPC built
>> them), so boot-testing them can be the first task for someone. I have
>> been working from the same codebases making local images successfully,
>> so they will probably work (to the extent that things are working).
>>
>> At this point this is all something put together by me in my spare
>> time. It's not known if or when OLPC would start working on an
>> official release from these efforts. But I figure that if we get
>> things properly stabilized and all the work is done cleanly, we'll
>> find one way or another to get this in the hands of deployments.
>>
>> Daniel
>> ___
>> 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
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Default unlock key ring (Fedora 11 + Gnome 2.26.3 + Apps)

[Tomeu Vizoso]

On Mon, Aug 23, 2010 at 23:08, Hernan Pachas  wrote:
>
> Dear friends,
> How I can unlock the default ring keys.
> I need never ask the system keys, because End users are children.
> It should be noted that the system runs on the XO laptop, the program
> "OLPC."
> Your help will be very important for the deployment of  500k laptops OLPC.
> Operating system Fedora + Gnome  + App

Hi Hernan,

don't remember how exactly I did it a while ago, but this page helped
me figure it out:

http://live.gnome.org/GnomeKeyring/Pam

Regards,

Tomeu

> ---Hernan
> ___
> 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: git help needed for 2.6.34 kernel branch revival

[Tomeu Vizoso]

On Thu, Aug 19, 2010 at 18:01, Martin Langhoff
 wrote:
> On Thu, Aug 19, 2010 at 11:53 AM, Daniel Drake  wrote:
>> Thanks for the advice. This is effectively the "399 patches" approach
>> I mentioned.
>
> Yes indeed. I couldn't tell if you knew about using format-patch and
> am separately -
>
>> For the 2.6.31 to 2.6.34 move, no rebasing happened. The 2.6.34 kernel
>> tree was simply merged into the 2.6.31.6 + olpc tree.
>> I think this was a mistake, given that 2.6.34 doesn't logically follow
>> on from 2.6.31.6.
>
> Yeah. Ugly mistake.
>
>>  And we should put more effort into upstreaming so that the
>> amount of rebasing work is not so great each time.
>
> Always true. Helps when you have a kernel hacker around. We've lost ours :-/
>
> Any kernel hacker reading this should look at:
> http://www.laptop.org/en/utility/people/opportunities.shtml ...

Considered asking Corbet to put some kind of plug in LWN?

May also help attending any of the several kernel
conf/summit/gettogethers around Boston.

Regards,

Tomeu

>
> 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
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: strange behavior of 'rm'

[Tomeu Vizoso]

On Sat, Aug 14, 2010 at 03:56, James Cameron  wrote:
> I'm mystified too.  But it doesn't happen when I try it on os851 on
> XO-1.5 ...
>
> 1.  the file can be deleted by user olpc in Terminal and stays deleted
> until Sugar restart, (an rm -f works, then an rm -f fails with "No such
> file or directory),
>
> 2.  the file can be deleted by user root in text console and stays
> deleted until Sugar restart.

Some git grep turned out this:

def _write_favorites_file(self):
path = env.get_profile_path('favorite_activities')
favorites_data = {'defaults-mtime': self._last_defaults_mtime,
  'favorites': self._favorite_bundles}
simplejson.dump(favorites_data, open(path, 'w'), indent=1)

I know this seems counter-intuitive to lots of engineers, but reading
code actually ends up saving time.

Regards,

Tomeu

> --
> James Cameron
> http://quozl.linux.org.au/
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Killing activities when memory gets short

[Tomeu Vizoso]

2010/8/11 NoiseEHC :
>
>> We used to do that, the problem is that we don't control our platform
>> as Google controls Android and you need to make sure that resources
>> that need to be specific of each child process aren't shared (dbus and
>> X connections, etc).
>>
>> I'm personally more interested in reducing the amount of resources we
>> need to start activities (which is quite insane right now), but
>> sharing more of those resources sounds like a good idea to me.
>>
>
> Since I spent quite a bit of time analyzing the Python runtime here is my
> conclusion, maybe it will make wasting all that time less painful.
>
> First, most of the memory consumed by an activity is the process heap. While
> the Python runtime and native libraries are shared among processes, the heap
> is not. Even if you fork processes it will not work because reference
> counting will dirty the shared pages

This would hold true if a significant part of the stuff loaded during
startup was actually ever referenced. This is not the case in Sugar,
so you indeed can get quite some savings from the prefork trick.

But of course, the right fix here is not sharing that memory, but not
require it in the first place if we don't need it.

One example is to stop compiling regular expressions eagerly, as
mentioned in http://www.mail-archive.com/su...@lists.laptop.org/msg06957.html
. There are several other situations that once fixed would give us
wins in the order of hundreds of milliseconds with the corresponding
wins in memory usage, such as importing modules that are never used.

The move from PyGtk to introspection will mean we stop loading several
dozens of classes that we never end up using, but there's lots to win
in the Python std library as well.

Regards,

Tomeu

> and my instinct tells me that just
> loading a Python source file will reference almost all the shared pages
> because they are mostly used to store already loaded modules. What I finally
> did not do is to actually check the hypothesis that most of the heap is
> filled by strings which are the identifiers in the loaded Python modules. My
> goal was to somehow make identifiers constants and just readonly-mmap them
> into the process (replace the pathetic .pyc loading mechanism). Note that my
> plan was just a little subset of the .jar -> .dex converter.
>
> Second, Python has a special memory manager which works with buckets so
> there are separate heaps for different object sizes. Somehow this special
> memory manager is turned off in release mode and it uses the standard C heap
> for some reason. Either it is a bug or just it turned out to be faster (more
> work was put into glibc) I do not know, but handling the linked free list
> can dirty shared pages as well or I am just mistaken...
>
> Third, the fact that Python is a dynamic language does not help any
> prefetching or memory sharing. I am not too convicted either that this
> dynamic nature is used at all in the Sugar codebase but you know I cannot
> program in Python and frankly I do not feel the need to learn another
> language. Just now, at my age of 34, I finally gave up and learned LISP
> (more specifically clojure) and I hope that it will be the last programming
> language I will have to learn (other than assembly languages of course)...
> :) Now this point is interesting because if you thought that the Dalvik VM
> could run the Sugar codebase via Jython then it just will not work. The
> Dalvik VM just cannot load .jar files and Jython just generates them on the
> fly because of the dynamic nature of Python.
>
> Fourth, moving Python (theoretically) to a GC environment (instead of
> reference counting) also would not work if the GC is compacting because it
> would also dirty the shared pages. So a mark and sweep nonmoving GC with
> separately stored "visited" bits is the only feasible solution. Now guess
> what the Dalvik VM does?
> For more info (45 min + questions):
> http://www.youtube.com/watch?v=ptjedOZEXPM
>
> So *my* conclusion is that solving this sharing problem is *very* hard. I am
> not sure that simply translating all activities from Python to Java would
> take more time.
>
> Another interesting thing is that meantime the unladen-swallow project
> progresses (just more slowly than planned). Their plan is to make it the
> default Python runtime so if it will happen (I cannot comment on that) then
> the Python VM will use even more memory (though it will be faster) so Sugar
> will be even less interesting on the myriad of low spec cheap ARM tablets
> which will flood the market soon.
>
> I think that is all I can say about this subject so I just finish it here.
>
>
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: cairo has now 16bit surfaces (was Fwd: rendering-cleanup)

[Tomeu Vizoso]

On Mon, Aug 9, 2010 at 15:48, Bernie Innocenti  wrote:
> El Sat, 07-08-2010 a las 12:14 -0400, Bernie Innocenti escribió:
>> El Sat, 07-08-2010 a las 11:25 +0200, Tomeu Vizoso escribió:
>> > > I'd expect well-written code to call cairo_surface_create_similar()
>> > > whenever possible, but there might be hot-spots in our software stack
>> > > that assume 32bpp.
>> >
>> > Have given a look to gtk+ and the xlib backend of cairo and seems to
>> > me that we are safe. We just need Maltose to come quickly to XO-1 :)
>>
>> ... or backport the new cairo to Fedora 11. The Cairo ABI is supposed to
>> be 100% backwards compatible, and I've successfully rebuilt 1.8 with no
>> issues.
>
> Building cairo-1.9.14 and pixman-0.18 went smooth on Fedora 11. They
> also seem to work fine on the XO.
>
> However, I did not notice any visible improvement. In case someone wants
> to try it out and run some benchmarks, I've uploaded the rpms here:
>
>  http://people.sugarlabs.org/bernie/olpc/cairo-1.9/

Simplest may be modifying the shell to repeat in a loop some drawing
(sliding the frame in and out, cycling through the zoom levels, etc)
then using a system-wide profiler such as sysprof to see where time is
being spent.

Regards,

Tomeu

> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Killing activities when memory gets short

[Tomeu Vizoso]

On Mon, Aug 9, 2010 at 15:47, Lucian Branescu  wrote:
> On 9 August 2010 14:44, NoiseEHC  wrote:
>>
>>> Sugar has a similar mechanism. From the Low-level Activity API docs:
>>>
>>> org.laptop.Activity.SetActive(b: active)
>>> Activate or passivate an activity. This is sent when switching activities, 
>>> there is only one active activity at a time, all others are passive. A 
>>> passive activity must immediately release resources like sound, camera etc. 
>>> Also it should prepare for being killed without warning at any time in the 
>>> future (see OOM) by auto-saving to the datastore.
>>>
>>> The issue is that it's hard to estimate how many Sugar activities actually 
>>> do this, because until now they usually have not been killed (*). Might be 
>>> an interesting test - just randomly kill activities from Terminal and see 
>>> if they resume correctly ...
>>>
>>> Maybe "good" activities could "volunteer" to be shut down first. Or "bad" 
>>> activities would have to "beg" to live a little longer. Might just take an 
>>> entry in the activity.info file.
>>>
>>
>> It will not work, because the application startup time is horrible on
>> the XO. The Dalvik VM goes a lng way to have fast application
>> startup and to share most of the memory among applications (the Zygote
>> process does this). Actually that was the exact thing I tried to do with
>> the Python VM. Just at the exact time when I started to hack Python I
>> have seen the Google I/O video about the Dalvik VM and thought that
>> duplicating that work would have been a waste of time. So if you wanna
>> fix the Python VM, good luck, but you know it is already been coded...
>> :) Without fast activity startup, killing activities will be a horrible
>> user experience. Maybe not that bad as a totally unresponsive XO though.
>
> It wouldn't be a duplication of efforts since Dalvik does not run
> Python and it is unlikely that it ever will. Perhaps a simple fork
> zygote for python wouldn't be that hard to accomplish in the sugar
> shell.

We used to do that, the problem is that we don't control our platform
as Google controls Android and you need to make sure that resources
that need to be specific of each child process aren't shared (dbus and
X connections, etc).

I'm personally more interested in reducing the amount of resources we
need to start activities (which is quite insane right now), but
sharing more of those resources sounds like a good idea to me.

Regards,

Tomeu

>>
>>> (*) Apple seems to have foreseen this "developer psychology" issue and 
>>> actually killed all apps in the first three iterations of its iOS. So apps 
>>> had to implement this state saving if the user was to be able to continue 
>>> after leaving an app. Would be interesting to know how many Android apps 
>>> actually implement it.
>>>
>>
>> All of them. If an Android application does not implement it correctly
>> then there will be big problems while switching apps and while
>> navigating among application screens.
> ___
> 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: OLPC 10.1.2 Release Candidate 1

[Tomeu Vizoso]

On Mon, Aug 9, 2010 at 02:16, James Cameron  wrote:
> On Sun, Aug 08, 2010 at 09:41:32AM -0700, Yioryos Asprobounitis wrote:
>> Wifi "disappearing" after switching back and forth from sugar to gnome.
>
> I've not tried to track down the original problem report that you are
> referring to, but Sugar and GNOME manage connection to an access point
> without reference to each other, so switching between the desktop
> environments will certainly cause one of the following:
>
> 1.  loss of association and then reassociation within about 35 seconds,
> (because NetworkManager is told to disconnect as one desktop wraps up,
> and then told to connect as the other desktop starts up),
>
> 2.  loss of association and no reassociation (the other desktop hasn't
> been told to trust the access point).

Just a heads up that this is in its way to be fixed for NM 0.9 (and
we'll need to adapt to API changes again):

http://live.gnome.org/NetworkManager/RemovingUserSettings

Regards,

Tomeu

>> This happened to me too and I thought was an issue with the
>> olpc-update I did at the time. I then clean installed and since then
>> works fine but something must be there.
>
> My guess is that you weren't aware of the separate storage for trusted
> or known access points.  Once you've selected an access point in both
> desktops, it will appear to work as you expect.
>
> This is a Sugar enhancement request.
> http://bugs.sugarlabs.org/ticket/1884
> (use system settings instead of user settings for NetworkManager)
>
> --
> James Cameron
> http://quozl.linux.org.au/
> ___
> olpc mailing list
> o...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/olpc
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Killing activities when memory gets short

[Tomeu Vizoso]

On Sun, Aug 8, 2010 at 18:11, Martin Langhoff  wrote:
> Hi Tomeu,
>
> in general, I think we are saying the same thing :-)

My impression as well.

> With one exception -- OOM happens because memory is allocated.
> Sugar-shell cannot (and I say should not) try to arbitrage in there.
> If we try to do it from sugar-shell, all we can do is poll. If we poll
> infrequently, we won't catch them, if we poll frequently, we'll burn
> battery, introduce random lags... and still not catch many.

Well, we certainly should not poll, I started this thread because
recent kernels have a mechanism for getting notified when a certain
threshold of free memory is reached (see below).

> When the shell is in the bg, IMHO it should be as "dormant" as possible.

Sounds a worthy goal.

> There are some opportunities for the shell to step-in in a friendly
> manner -- activity open, activity switch, I propose that those events
> are a natural place; and if a delay happens there is not very
> disruptive for users. Between those events checking for low-mem and
> seeding the OOM killer to catch runaways, we'll have something.

Yeah, oomadj would be updated on activity open and switch if we go that way.

> I don't know of there's a way to ask the OOM killer to run a process
> on a lower threshold -- or send a signal to an existing one, that'd
> make more sense :-) . If it does, we could have a tight C process
> listening there of OOM "warnings" and sending friendly "close now plz"
> dbus signals.

The kernel docs linked here mention such a mechanism:

http://lists.sugarlabs.org/archive/sugar-devel/2010-August/025851.html

Regards,

Tomeu

> 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: [Sugar-devel] Killing activities when memory gets short

[Tomeu Vizoso]

On Sun, Aug 8, 2010 at 17:42, Martin Langhoff  wrote:
> On Sun, Aug 8, 2010 at 9:33 AM, Tomeu Vizoso  wrote:
>>> Can't we just _close it nicely_?
>>
>> When you are about to get into OOM?
>
> Early on so we avoid OOM for most cases. Right now our OOM use cases
> have nothing to do with misbehaved activities.
>
> Once you're in "about to get into OOM", sugar-shell is unlikely to get
> many cycles (and python is a bad lang to try handling this). If you
> can seed the OOM scores of the process early on, you have a chance
> that OOM will kill a reasonably "correct" one. (Not sure what the
> state of play is with seeding the OOM scores from userland).

I tried to make clear before that by all means I think we should give
the user and activities the chance to do what is best early on.

>> point we should have given the activities and/or the user the option
>> to avoid this situation.
>
> I think it's the only thing we can reasonably do. And [if possible],
> seed OOM scores.
>
> When things get tight, only the kernel has a standing chance to run code.

Well, the shell would kill activities before we get that tight. But I
agree that if if we can use OOM scores to have the kernel kill the
less bad thing, that sounds better.

Regards,

Tomeu

> 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: [Sugar-devel] Killing activities when memory gets short

[Tomeu Vizoso]

On Sun, Aug 8, 2010 at 15:15, Martin Langhoff  wrote:
> On Sun, Aug 8, 2010 at 4:01 AM, Tomeu Vizoso  wrote:
>> I tihnk I have been sloppy with my words, so let me clarify two things:
>>
>> - killing processes should be done only to avoid OOM (because
>> currently the kernel kills the wrong thing most of the time).
>
> Can't we just _close it nicely_?

When you are about to get into OOM? Don't think so because it's very
probable that the kernel will block or kill something randomly before
the activity or the user react. But as I said, before we reach this
point we should have given the activities and/or the user the option
to avoid this situation.

Regards,

Tomeu

> I have extremely rarely seen a Sugar app not closing. Sugar shell can
> decide it's a good idea to close an activity because too many are open
> and system is under memory pressure.
>
> Sugar apps auto-save, so closing nicely should work very nicely...
>
> 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: Killing activities when memory gets short

[Tomeu Vizoso]

On Sat, Aug 7, 2010 at 22:08, Tiago Marques  wrote:
> Hi all,
>
> On Sat, Aug 7, 2010 at 6:31 PM, Bernie Innocenti  wrote:
>>
>> El Sat, 07-08-2010 a las 18:14 +0200, Tomeu Vizoso escribió:
>>
>> > So we would have a periodic wakeup? The test would be the amount of
>> > free memory plus buffers and caches?
>>
>> A polled design is clearly inferior to a proper notification system, but
>> it has the advantage of being simple and not requiring a particular
>> kernel. Once this is done, switching to a better solution should not
>> require extensive changes to the UI code.
>>
>> BTW, looking at top, it seems that Sugar and other processes wake up
>> quite frequently when the system is supposed to be completely idle. It
>> may be background checks for updates, NetworkManager updates or the
>> presence service. Plus, there are a bunch of cron jobs that run in the
>> background, inclding the ds-backup and olpc-update.
>>
>> All these things drain battery power and cause the UI to become jerky,
>> so we should try to limit them if possible.
>>
>>
>> > > Or, maybe, we could make this a manual process: pop up a notification
>> > > when memory is short and ask which activity should be closed.
>> >
>> > I would just close one of the background activities, the LRU or the
>> > biggest one.
>>
>> +1.
>
> Just killing a random activity is a terrible idea becayse you don't want
> your product behaving like it's defective; the pop up idea is way more
> acceptable(and a lot better than having the system randomly behaving like
> it's crashed). Either way, this is the extremely important use of swap
> memory that doesn't exist here. I understand your engineering constraints on
> the hardware but randomly killing activities is poised to confuse users and
> cause people considering the hardware for deployment to think that you're
> selling them something defective/baddly manufactured.

I tihnk I have been sloppy with my words, so let me clarify two things:

- killing processes should be done only to avoid OOM (because
currently the kernel kills the wrong thing most of the time).

- before the need for killing arises, we can do a myriad of things to
prepare the user for what is coming and maybe to avoid it (some good
ideas have already been posted in this thread).

Regards,

Tomeu

> Best regards,
> Tiago Marques
>
>>
>> This, however, makes non-sugarized activities more dangerous to deal
>> with. One more reason to demand proper sugarization.
>>
>> --
>>   // Bernie Innocenti - http://codewiz.org/
>>  \X/  Sugar Labs       - http://sugarlabs.org/
>>
>> ___
>> 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: Killing activities when memory gets short

[Tomeu Vizoso]

On Sat, Aug 7, 2010 at 19:33, Tomeu Vizoso  wrote:
> On Sat, Aug 7, 2010 at 19:31, Bernie Innocenti  wrote:
>> El Sat, 07-08-2010 a las 18:14 +0200, Tomeu Vizoso escribió:
>>
>>> So we would have a periodic wakeup? The test would be the amount of
>>> free memory plus buffers and caches?
>>
>> A polled design is clearly inferior to a proper notification system, but
>> it has the advantage of being simple and not requiring a particular
>> kernel. Once this is done, switching to a better solution should not
>> require extensive changes to the UI code.
>>
>> BTW, looking at top, it seems that Sugar and other processes wake up
>> quite frequently when the system is supposed to be completely idle. It
>> may be background checks for updates, NetworkManager updates or the
>> presence service. Plus, there are a bunch of cron jobs that run in the
>> background, inclding the ds-backup and olpc-update.
>>
>> All these things drain battery power and cause the UI to become jerky,
>> so we should try to limit them if possible.
>
> NM is particularly active when there are more than a few APs
> available, wonder if it would be possible to tune it to group updates
> in batches.

On a second thought, Sugar should probably only listen to events
relevants to what is being currently displayed. This would display
outdated data for a short while and would mean significant rework but
may be a worthy goal for the future.

Regards,

Tomeu

> Regards,
>
> Tomeu
>
>>> > Or, maybe, we could make this a manual process: pop up a notification
>>> > when memory is short and ask which activity should be closed.
>>>
>>> I would just close one of the background activities, the LRU or the biggest 
>>> one.
>>
>> +1.
>>
>> This, however, makes non-sugarized activities more dangerous to deal
>> with. One more reason to demand proper sugarization.
>>
>> --
>>   // Bernie Innocenti - http://codewiz.org/
>>  \X/  Sugar Labs       - http://sugarlabs.org/
>>
>>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Killing activities when memory gets short

[Tomeu Vizoso]

On Sat, Aug 7, 2010 at 19:31, Bernie Innocenti  wrote:
> El Sat, 07-08-2010 a las 18:14 +0200, Tomeu Vizoso escribió:
>
>> So we would have a periodic wakeup? The test would be the amount of
>> free memory plus buffers and caches?
>
> A polled design is clearly inferior to a proper notification system, but
> it has the advantage of being simple and not requiring a particular
> kernel. Once this is done, switching to a better solution should not
> require extensive changes to the UI code.
>
> BTW, looking at top, it seems that Sugar and other processes wake up
> quite frequently when the system is supposed to be completely idle. It
> may be background checks for updates, NetworkManager updates or the
> presence service. Plus, there are a bunch of cron jobs that run in the
> background, inclding the ds-backup and olpc-update.
>
> All these things drain battery power and cause the UI to become jerky,
> so we should try to limit them if possible.

NM is particularly active when there are more than a few APs
available, wonder if it would be possible to tune it to group updates
in batches.

Regards,

Tomeu

>> > Or, maybe, we could make this a manual process: pop up a notification
>> > when memory is short and ask which activity should be closed.
>>
>> I would just close one of the background activities, the LRU or the biggest 
>> one.
>
> +1.
>
> This, however, makes non-sugarized activities more dangerous to deal
> with. One more reason to demand proper sugarization.
>
> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: cairo has now 16bit surfaces (was Fwd: rendering-cleanup)

[Tomeu Vizoso]

On Sat, Aug 7, 2010 at 18:14, Bernie Innocenti  wrote:
> El Sat, 07-08-2010 a las 11:25 +0200, Tomeu Vizoso escribió:
>> > I'd expect well-written code to call cairo_surface_create_similar()
>> > whenever possible, but there might be hot-spots in our software stack
>> > that assume 32bpp.
>>
>> Have given a look to gtk+ and the xlib backend of cairo and seems to
>> me that we are safe. We just need Maltose to come quickly to XO-1 :)
>
> ... or backport the new cairo to Fedora 11. The Cairo ABI is supposed to
> be 100% backwards compatible, and I've successfully rebuilt 1.8 with no
> issues.

Sounds good, if that gives problems we can consider backporting just that patch.

If the small patch below is really what was needed, I'm going to feel
quite stupid:

http://cgit.freedesktop.org/cairo/commit/?id=022291be1cbddf4f6722f0bf76ebda6922780276

Regards,

Tomeu

> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
> ___
> 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: MicroSD Card performance variance on XO-1.5

[Tomeu Vizoso]

On Sat, Aug 7, 2010 at 18:11, Bernie Innocenti  wrote:
> [cc += sugar-devel, tch]
>
> El Sat, 07-08-2010 a las 11:27 +0200, Tomeu Vizoso escribió:
>
>> Btw, have read that some notifications about available memory have
>> landed in cgroups in recent kernels. The Sugar shell could listen to
>> those and give a chance to background activities to save their state
>> before killing them, thus avoiding OOM in some (most?) cases.
>
> We could do this even without an advanced reporting mechanism. The
> monitoring code in the CPU & Memory meter could detect memory shortage
> and automatically quit  the least recently used activity.

So we would have a periodic wakeup? The test would be the amount of
free memory plus buffers and caches?

> Or, maybe, we could make this a manual process: pop up a notification
> when memory is short and ask which activity should be closed.

I would just close one of the background activities, the LRU or the biggest one.

Regards,

Tomeu

> A while ago, Tincho has been working on implementing the Freedesktop
> notification protocol in Sugar. This feature didn't make it for
> Dextrose, but perhaps it could be completed in time to be merged into
> 0.90.
>
> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: MicroSD Card performance variance on XO-1.5

[Tomeu Vizoso]

On Sat, Aug 7, 2010 at 02:52, Bernie Innocenti  wrote:
> El Fri, 06-08-2010 a las 18:50 +0200, Tomeu Vizoso escribió:
>> > I also think our vm.dirty_* settings are wrong and likely causing our
>> > current fill-buffer-and-stutter behaviour. We are using the defaults
>> > and those are for spinning harddrives, with a significant cost to
>> > spinning up the disk on a laptop -- hence long expire_centisecs and
>> > writeback_centisecs and the assumption that once you've started
>> > writing, it'll be written out fast. We have zero seek costs, zero
>> > "spin disk up" costs, but slowish writes -- we have to start writing
>> > buffers out ASAP.
>>
>> I had also had the impression for some time that some knobs in the
>> kernel could have been better tuned for the XO-1 and the actual
>> workload.
>
> That was also my gut feeling.
>
> Swappiness also seems to be set too high. We should probably let the OOM
> killer kick in before the machine becomes totally unresponsive.

Btw, have read that some notifications about available memory have
landed in cgroups in recent kernels. The Sugar shell could listen to
those and give a chance to background activities to save their state
before killing them, thus avoiding OOM in some (most?) cases.

Regards,

Tomeu

> Tuning the VM knobs is no joke. We could proceed by applying some
> reasonable changes early in the next development cycle, then sit back
> and wait for users to tell us their overall impression of using the
> system as usual.
>
> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: cairo has now 16bit surfaces (was Fwd: rendering-cleanup)

[Tomeu Vizoso]

On Sat, Aug 7, 2010 at 02:20, Bernie Innocenti  wrote:
> El Tue, 03-08-2010 a las 16:26 +0200, Tomeu Vizoso escribió:
>> This means that graphic operations would be considerably faster on the
>> XO-1 because to date we are rendering to 24bit surfaces that the X
>> server has to convert to 16bit every time.
>
> Fantastic news!
>
> In order to benefit in Sugar, do you think we'd have to wait until 16bit
> surface support is propagated to GTK, libsrvg, hippocanvas, etc?
>
> I'd expect well-written code to call cairo_surface_create_similar()
> whenever possible, but there might be hot-spots in our software stack
> that assume 32bpp.

Have given a look to gtk+ and the xlib backend of cairo and seems to
me that we are safe. We just need Maltose to come quickly to XO-1 :)

Regards,

Tomeu

> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
> ___
> 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: MicroSD Card performance variance on XO-1.5

[Tomeu Vizoso]

On Fri, Aug 6, 2010 at 18:43, Martin Langhoff  wrote:
> On Fri, Aug 6, 2010 at 12:30 PM, Richard A. Smith  wrote:
>> Whats the qualifications on that?  I assume its raw RGB video?
>
> No, it's compressed vid + uncompressed audio to be stitched later.
>
> I have a confession to make: Many years ago I worked in video mixing
> with mid-range gear (avid and media100, I *don't* miss you) and with
> cheapskates PC-based rigs (which where hell on wheels compared to avid
> and media100).
>
> My take is that our CPU is perfectly capable of capturing and
> compressing vid and audio and putting it down to disk, even on a
> 2MB/s-capable disk, helped a bit by (limited) linux kernel buffering.
> Most importantly, we need to capture audio + vid together, or at least
> timestamp them together. Otherwise drift is inevitable.
>
> I also think our vm.dirty_* settings are wrong and likely causing our
> current fill-buffer-and-stutter behaviour. We are using the defaults
> and those are for spinning harddrives, with a significant cost to
> spinning up the disk on a laptop -- hence long expire_centisecs and
> writeback_centisecs and the assumption that once you've started
> writing, it'll be written out fast. We have zero seek costs, zero
> "spin disk up" costs, but slowish writes -- we have to start writing
> buffers out ASAP.

I had also had the impression for some time that some knobs in the
kernel could have been better tuned for the XO-1 and the actual
workload.

Regards,

Tomeu

> But that's my (naive?) take. I haven't delved into the gstreamer madness.
>
>
> 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
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

cairo has now 16bit surfaces (was Fwd: rendering-cleanup)

[Tomeu Vizoso]

This means that graphic operations would be considerably faster on the
XO-1 because to date we are rendering to 24bit surfaces that the X
server has to convert to 16bit every time.

Regards,

Tomeu

-- Forwarded message --
From: Soeren Sandmann 
Date: Tue, Aug 3, 2010 at 15:22
Subject: Re: rendering-cleanup
To: Yasushi SHOJI 
Cc: gtk-devel-l...@gnome.org


Yasushi SHOJI  writes:

> I'm for one wandering how to port my application to gtk+ 3.0.  My
> problem is that the current gdk pixbuf nor cairo does not have a
> client side pixel buffer other than RGB888 or RGBA.

Note that cairo 1.10 (which GTK+ 3.0 will depend on, as I understand),
has a client side 565 buffer: CAIRO_FORMAT_RGB16_565.


Soren
___
gtk-devel-list mailing list
gtk-devel-l...@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [IAEP] Announce: OLPC software strategy.

[Tomeu Vizoso]

On Thu, Jul 8, 2010 at 00:01, Chris Ball  wrote:
> Hi,
>
> Now that the 10.1.1 release for XO-1.5 is out, it's a good time to
> talk about OLPC's software strategy for the future.  We've got a few
> announcements to make:
>
> XO-1:
> =
>
> OLPC wasn't planning to make a Fedora 11 release of the XO-1 OS, but
> a group of volunteers including Steven Parrish, Bernie Innocenti,
> Paraguay Educa and Daniel Drake stepped up and produced Fedora 11 XO-1
> builds that follow the OLPC 10.1.1 work.  I'm happy to announce that
> we're planning on releasing an OLPC-signed version of that work, and
> that this release will happen alongside the next XO-1.5 point release
> in the coming weeks.  So, OLPC release 10.1.2 will be available for
> both XO-1 and XO-1.5 at the same time, and will contain Sugar 0.84,
> GNOME 2.26 and Fedora 11.  We think that offering this fully
> interoperable software stack between XO-1 and XO-1.5 laptops will
> greatly aid deployments, and we're very thankful to everyone who has
> enabled us to be able to turn this XO-1 work into a supported release!
>
> To prepare for this XO-1 release, we've started working on fixing
> some of the remaining bugs in the community F11/XO-1 builds.  Paul Fox
> recently solved a problem with suspend/resume and wifi in the F11/XO-1
> kernel, which was the largest blocker for a supported release.  We'll
> continue to work on the remaining bugs, particularly the ones that
> OLPC is uniquely positioned to help with.
>
> The first development builds for this release will be published later
> this week.
>
> XO-1.5:
> ===
>
> We'll be continuing to work on XO-1.5 improvements, incorporating
> fixes to the "Known Problems" section of the 10.1.1 release notes¹
> into the 10.1.2 release.
>
> XO-1.75 and beyond:
> ===
>
> XO-1.75 software development is underway.  Today we're announcing
> that we're planning on using Fedora as the base distribution for the
> XO-1.75.  This wasn't an obvious decision -- ARM is not a release
> architecture in Fedora, and so we're committing to help out with that
> port.  Our reasons for choosing Fedora even though ARM work is needed
> were that we don't want to force our deployments to learn a new
> distribution and re-write any customizations they've written, we want
> to reuse the packaging work that's already been done in Fedora for
> OLPC and Sugar packages, and we want to continue our collaboration
> with the Fedora community who we're getting to know and work with
> well.
>
> We've started to help with Fedora ARM by adding five new build
> machines (lent to OLPC by Marvell; thanks!) to the Fedora ARM koji
> build farm, and we have Fedora 12 and Sugar 0.86 running on early 1.75
> development boards.  We'd prefer to use Fedora 13 for the XO-1.75, but
> it hasn't been built for ARM yet -- if anyone's interested in helping
> out with this or other Fedora ARM work, please check out the Fedora
> ARM page on the Fedora Wiki².  We're also interested in hiring ARM and
> Fedora developers to help with this; if you're interested in learning
> more, please send an e-mail to jobs-engineer...@laptop.org.
>
> We'll also be continuing to use Open Firmware on the XO-1.75, and
> Mitch Bradley has an ARM port of OFW running on our development boards
> already.
>
> EC-1.75 open source EC code:
> 
>
> OLPC is proud to announce that the XO-1.75 embedded controller will
> have an open codebase (with a small exception, see below).  After much
> behind-the-scenes effort, EnE has agreed to provide us with a public
> version of the KB3930 datasheet and is allowing our new code to be
> made public.
>
> The code is not available yet due to a few chunks of proprietary code
> that need to be purged and some other reformatting.  A much more
> detailed announcement will be provided once the new code is pushed to
> a public repository.  The code will be licensed under the GPL with a
> special exception for OLPC use.
>
> The exception is because EnE has not released the low-level details on
> the PS/2 interface in the KB3930, so there will be some code that is
> not available -- relative to the codebase this is a very small amount
> of code.  The GPL licensing exception will allow for linking against
> this closed code.  We're going to investigate ways to move away from
> this code in the future.  (As far as we're aware, this will make the
> XO-1.75 the first laptop with open embedded controller code!)
>
> Multi-touch Sugar:
> ==
>
> We've begun working on modifications to Sugar to enable touchscreen
> and multitouch use (the XO-1.75 will have a touchscreen, as will
> future OLPC tablets based on its design), and we'll continue to do so.
> The first outcome from this work is Sayamindu Dasgupta's port of the
> Meego Virtual Keyboard³ to Sugar -- you can see a screencast of it in
> action here⁴.
>
> It's an exciting time for software development at OLPC.  Many thanks
> for all of your support and efforts!

Re: [Sugar-devel] UI experiments: pop-up menus and hot corners

[Tomeu Vizoso]

On Wed, Jul 7, 2010 at 01:39, Bernie Innocenti  wrote:
> On Tue, 2010-07-06 at 20:06 +0100, Gary Martin wrote:
>
>> Activity start-up times are significantly better than they used to be,
>> so no specific bug that I'm aware of, was just hopeful of any
>> opportunities to further improve performance
>
> On F11-0.88, I often see long startup times. I have some non-conclusive
> clues to think on:
>
> 1) using top from the console, I see the CPU split (50%/50%) between
> sugar-session and the loading activity

The shell cpu usage looks very bad, I will do some profiling.

> 2) activities using 0sugar seem to take forever to run
>
> 3) Browse and Record are amongst the worst offenders

Browse I can believe it's because of mozilla, but Record??

If someone would like to profile I will be glad to give some pointers.

Regards,

Tomeu

> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] UI experiments: pop-up menus and hot corners

[Tomeu Vizoso]

On Tue, Jul 6, 2010 at 12:38, Marco Pesenti Gritti  wrote:
> On 6 Jul 2010, at 04:26, Gary Martin  wrote:
>
>> Pre-rendering is tricky as both stroke/fill colour, and image size are 
>> variable.
>
> I think Benjamin had this more or less working at some point, I don't 
> remember why we didn't land it.

The results on the XO-1 weren't conclusive AFAIR (cc'ing Benjamin).

Regards,

Tomeu

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

Re: [Sugar-devel] UI experiments: pop-up menus and hot corners

[Tomeu Vizoso]

On Tue, Jul 6, 2010 at 22:00, Mikus Grinbergs  wrote:
>> Activity start-up times are significantly better than they used to be, so no 
>> specific bug
>> that I'm aware of, was just hopeful of any opportunities to further improve 
>> performance
>
> It's my impression that activity start-up times are affected by the
> "size" (by that I mean "memory usage") of the activity.  If on the XO-1
> I start up a large activity (e.g., Help, TamTamSynth, etc) for the first
> time, it takes a number of seconds for me to see the activity's own
> screen.  Smaller activities (e.g., Bounce, Arithmetic) seem to start
> more quickly.

The no. 1 factor in python activities is generally the number of
modules imported, which could be seen related to the amount of
functionality it provides. It also implies more memory usage.

Would be interesting to test with newer python releases if it has
improved there.

Regards,

Tomeu

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

Re: [Sugar-devel] UI experiments: pop-up menus and hot corners

[Tomeu Vizoso]

On Tue, Jul 6, 2010 at 05:26, Gary Martin  wrote:
> On 6 Jul 2010, at 03:33, Bernie Innocenti wrote:
>
>> On Mon, 2010-07-05 at 17:34 +0100, Gary Martin wrote:
>>
>>> Just showing the name under the pulsing icon might be a useful extra,
>>> but ideally the launch time should be as short as possible so might
>>> look odd briefly flashing up the text (the pulse animation is meant to
>>> be a transition, just unfortunate that most startups are still more
>>> than a second or three).
>>
>> Who would be interested in working on startup optimization?
>
> Well happy to help test, but seems above my technical water line.
>
> Wade experimented (and there are patches in trac I think) with a pulse 
> animation effect that was quicker to transition but then paused slightly at 
> max/min. Seem to remember it took another ~couple of seconds off startup, but 
> never made it through to a release (was part of his work on the activity 
> startup failure message that did thankfully land).
>
>> Besides Tomeu's ongoing work on PyGI, I think we could gain a lot by
>> shaving off huge modules such as numpy and sharing pre-rendered svg
>> icons in some memory-mappable cache file.
>
> I didn't think any of Glucose used numpy? I thought it was there for Fructose 
> (Activities) only if they needed. FWIW I have a couple of Activity projects 
> that would use numpy but I'm not there yet.
>
> Pre-rendering is tricky as both stroke/fill colour, and image size are 
> variable.
>
> I was hopeful after seeing Mart Raudsepp's email a week ago to the dev list 
> about Cairo's slow rendering on XO hardware (and possible future 
> improvements), but Wade pointed out the pulsing animation is currently a 
> Hipocanvas thing.

It was the case some time ago that Hippo would decide to request a
full screen redraw at every pulse, but it was fixed to be smarter
about what needs being redrawn. Or are we talking about another bug in
Hippo?

Regards,

Tomeu

> Regards,
> --Gary
>
>> --
>>   // Bernie Innocenti - http://codewiz.org/
>> \X/  Sugar Labs       - http://sugarlabs.org/
>>
>
> ___
> 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: NetworkManager time sync

[Tomeu Vizoso]

On 07/04/2010 12:59 AM, Bernie Innocenti wrote:
> Dan,
>
> we don't have any way to synchronize the clock on the XO... I'd rather
> avoid running ntp all the time as it wastes 2MB of RSS. Does
> NetworkManager provide a service to automatically call ntpdate when the
> interface goes up?

You mean a script placed in /etc/NetworkManager/dispatcher.d/ ?

Regards,

Tomeu

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

Re: [Sugar-devel] MANIFEST pointlessness

[Tomeu Vizoso]

On Mon, Jul 5, 2010 at 16:04, Bernie Innocenti  wrote:
> On Mon, 2010-07-05 at 15:13 +0200, Tomeu Vizoso wrote:
>
>> Would be good to have some way of tracking what needs to be solved
>> before we can do the switch. Two questions off the top of my head are
>> how first-time activity authors are going to package their software
>
> Now they do:
>
>  ./setup.py fix_manifest
>  ./setup.py dist_xo
>
> When we remove the manifest thing, they could do:
>
>  ./setup.py dist_xo
>
>
> None of the activities I have seen so far store a manually generated
> MANIFEST in git. In case they'd need to exclude some files, hopefully
> setup.py would provide extensibility hooks.
>
> Actually, I've never seen a setup.py containing anything else than the
> two lines of copy-pasted code (plus the usual dozen lines of legal
> crap). Activities which need to build binaries, such as Physics, require
> a manual build step.
>
> This confirms my theory that the xo bundle format is so easy to use just
> because it doesn't do any of the things that a packaging system needs to
> do. Currently, setup.py is just a glorified "zip -r".
>
>
>> and also what those people will have to do to modify an activity
>> installed in their system. (But maybe not discuss these in this
>> thread?).
>
> Currently, upgrading an activity causes the new files to be merged with
> the old ones. This is clearly a bug that should be fixed.
>
> The MANIFEST doesn't play any role in activity installation. The version
> of Sugar shipped in F11-0.88 contains a patch that removes all this code
> and it is functionally identical from the user's point of view, apart
> from not logging warnings when the MANIFEST contains inconsistencies.

Sorry about the confusion, these questions were about the move from xo
bundles to packages :(

Regards,

Tomeu

> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] MANIFEST pointlessness

[Tomeu Vizoso]

On Sat, Jul 3, 2010 at 16:32, Bernie Innocenti  wrote:
> El Fri, 02-07-2010 a las 15:54 +1000, James Cameron escribió:
>
>> A fascinating meaning of the word MANIFEST that I had not previously
>> encountered.  That sounds like an INVENTORY.
>>
>> What's the point of a file that is automatically generated?
>
> None, this is why I removed it.
>
> IIRC, the original plan was to make the MANIFEST contain hashes, so it
> could be used for integrity checking and to update activities by
> downloading only deltas.
>
> In 3 years, nobody ever got around to implement any of these advanced
> features... And in case anyone ever did, the current MANIFEST format
> would have to be redesigned anyway.
>
> To simplify the life of activity authors, we should simply remove any
> mention of it from the documentation and maybe teach setup.py to
> generate bundles out of git ls-files.

Maybe Gary and/or Wade can give the opinion of the Activity Team on this?

> Meanwhile, SoaS, USR and the new ARM-based XO laptop are pressing hard
> for switching from xo bundles to a full-featured packaging system, which
> would also solve the problem that the MANIFEST was supposed to address.

Would be good to have some way of tracking what needs to be solved
before we can do the switch. Two questions off the top of my head are
how first-time activity authors are going to package their software
and also what those people will have to do to modify an activity
installed in their system. (But maybe not discuss these in this
thread?).

Regards,

Tomeu

> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
> ___
> 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: [Sugar-devel] Restoring the journal from an 0.82 image

[Tomeu Vizoso]

On Fri, Jul 2, 2010 at 01:50, Luis Michelena  wrote:
> I have reflashed my XO (bettie given by Erik Garrison after his layout from
> olpc) with the 0.88 beta image(I have another, but has the Uruguayan ofw
> keys), and I'm amazed by the improvements.
>
> But I'd would like to restore the 0.82 journal to the new configuration, is
> the journal format in 0.82 compatible with 0.88?, to try to backport the
> backup/restore scripts to the 0.82?
> At the moment, I'm loop(mtdblock and block2mtd ) mounting the 0.82 image,
> but I haven't figured out how to copy the journal.

Hi Luis,

if you replace ~/.sugar/default/datastore with the contents of the
0.82 journal it should update it to the new DS format on reboot.

If it doesn't, it is a very important bug to report.

Thanks,

Tomeu

> Thanx,
> Luis
>
>
>
> ___
> 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: [Sugar-devel] Quickly for Sugar

[Tomeu Vizoso]

On Tue, Jun 22, 2010 at 19:59, Sameer Verma  wrote:
> I was looking at Jono Bacon's article (cc'd) in the latest Linux
> Journal (http://www.linuxjournal.com) and was wondering if anyone has
> looked into Quickly in the Sugar context. Quickly essentially ties in
> various tools to allow for an easier workflow for "opportunistic
> programmers". It pulls in Glade, Python, gedit etc.

I certainly think that there's big overlap with what we have been
doing in Sugar.

Regards,

Tomeu

> Quickly: https://wiki.ubuntu.com/Quickly
>
> cheers,
> Sameer
> --
> Dr. Sameer Verma, Ph.D.
> Associate Professor, Information Systems
> Director, Campus Business Solutions
> San Francisco State University
> http://verma.sfsu.edu/
> http://opensource.sfsu.edu/
> http://cbs.sfsu.edu/
> http://is.sfsu.edu/
> ___
> 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: [Sugar-devel] Removing 'share' option from activites that don't know how to share

[Tomeu Vizoso]

On Thu, Jun 24, 2010 at 22:23, Gary Martin  wrote:
> On 24 Jun 2010, at 16:20, Martin Langhoff  wrote:
>
>
> Talking with the Perú team a few days ago about F11/S0.84 (both on
> xo-1.5 and xo-1)
>
> Teachers and testers were very confused with the 'share' option in
> activities where sharing does nothing, or is seriously buggy. To avoid
> confusing users, they are looking into removing the 'share' option
> from most activities.
>
> This is practical and executive for them short-term; of course the
> right fix is for activities do call up the 'share' option only where
> actual sharing code exists and is known to work...
>
> What is the right fix? Do we want a list of activities where it should
> be removed, and prod the maintainers, and only file bugs for those
> that don't respond soonish?
>
> Making a list of the offenders and posting would be a start, but remember to
> state the release you are targeting/testing. Here's a likely large chunk of
> the problem...
> For Sugar 0.86 and above the new toolbars will disable the sharing UI with:
>     self.max_participants = 1
> For Sugar 0.82 the trick was:
>     activity_toolbar = toolbox.get_activity_toolbar()
>     activity_toolbar.share.props.visible = False
> For Sugar 0.84 the trick seems to be:
>     activity_toolbar = toolbox.get_activity_toolbar()
>     activity_toolbar.share.hide()
> I've not noticed an elegant way to detect Sugar versions other than try:
> except: clauses around some newer modules, with fallback to 0.82 code.
> Anyone point to a specific activity doing this type of thing nicely?

In python it's favoured to check if the API you want to use is
available with hasattr().

FWIW, I think this should go upstream as is of obvious interest for
all our users. Has Peru someone who can take care of this or should we
try to find someone else?

Regards,

Tomeu

> Regards,
> --Gary
>
> (The above would be an informal copy of the "mass bug filing" protocol
> @ Debian.)
>
>
> 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
> ___
> 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
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [IAEP] F11-0.88 os260py

[Tomeu Vizoso]

On Fri, Jun 18, 2010 at 05:26, Bernie Innocenti  wrote:
> This is the an interim release of Sugar 0.88 + GNOME series for XO-1.
> Please refer to this page for the current status and download
> instructions:
>
>  http://wiki.sugarlabs.org/go/Deployment_Team/Sugar-0.88
>
>
> With this build, all the major regression relative to 0.84 are fixed.
> The switch to Metacity resulted in a few hard issues on Fedora 11. There
> are still several smaller bugs to work on.
>
> All the new features planned for this cycle are now merged, with the
> notable exception of collections support for the activity updater, which
> urgently needs a volunteer. At this point, it seems too late for the
> much anticipated resurrection of Rainbow. Maybe next time.
>
> There may still be time to merge and stabilize a couple of minor
> features, such as a button in the Network control panel to re-register
> with the schoolserver.
>
>
> == Changes relative to the previous release (os258py) ==
>
>  * Integrate journal backup and restore to USB (esteban, tch)
>
>  * Integrate function for mounting a GNOME Documents folder in
>   the journal. Still presents some rough edges. (jasg)
>
>  * Pull latest OS updates from upstream (fedora)
>
>
> == Bugs fixed in this release ==
>
>  * Make ALT-TAB work. It was caused by a bug with XUngrabKey()
>   in the old Xorg server of Fedora 11, but we worked it around
>   in Metacity. We spent a lot of time to figure it out!
>   (tch, bernie)
>
>  * Fix windows staying in frame after startup. It turned out to be
>   a libwnck bug, solved by upgrading it to a more recent version
>   (aa, bernie)

Excellent integration work! Before, it used to be the upstream
developers who had to also debug on Fedora and sometimes on other
distros, and as you said, it often takes a lot of time.

It's great that this work has moved downstream!

>  * Fix fonts too big in all activities. This was a fallout of us
>   temporarily disabling sugar-settings-manager, due to another
>   bug (jasg).
>
>  * CTRL-C/CTRL-V don't work in Turtle Blocks
>   (walter)
>
>  * Sugar sometimes restart. My fault: I included in the build an
>   experimental Geode driver to check if it would now be safe to
>   re-enable some EXA acceleration. It wasn't. (bernie).
>
>
> == Known bugs ==
>
> We still have a bunch of less serious issues requiring attention:
>
>  * Activity updater needs to support microformat and collections
>
>  * Sometimes pulsing launch icon is delayed or absent (scheduling
>   issue? Sometimes I can see Sugar eating up 50% of the CPU when
>   starting an activity)

If you can reproduce it, it would be great to gather some profile data
during activity launch with this:

## Before launching ##
profiler = cProfile.Profile()
profiler.enable()

## After launch ##
profiler.disable()
profiler.dump_stats('/tmp/profile')

It should tell what's Sugar up to.

Cheers,

Tomeu

>  * Font in Write is small and text does not fill the screen width.
>   Sugar 0.82 and 0.84 used "Dejavu Sans", 0.88 uses "Times New Roman",
>   which is smaller. (someone take it? pretty please?)
>
>  * Disconnects from network on power save. This is a long-standing
>   kernel bug. In 0.84, we "fixed" it by disabling power management.
>
>  * Social Calc contains a race condition that makes it fail to
>   start. Frankly, I would just ditch it, but teachers seem to like
>   it very much
>
>  * More GNOME lock-down. See the thread with subject "GNOME and
>   protecting Sugar" on sugar-de...@.
>
> Thanks to anyone who could help us fixing these problems.
>
> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
>
>
> ___
> IAEP -- It's An Education Project (not a laptop project!)
> i...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Anyone playing with Ubuntu on XO-1.5?

[Tomeu Vizoso]

On Mon, Jun 14, 2010 at 19:17, David Farning  wrote:
> On Mon, Jun 14, 2010 at 11:53 AM, Tomeu Vizoso  wrote:
>> On Mon, Jun 14, 2010 at 18:33, David Farning  wrote:
>>> On Mon, Jun 14, 2010 at 11:06 AM, Martin Langhoff
>>>  wrote:
>>>> [ Put aside the tinfoil hats (there's no Ubuntu conspiracy) and the
>>>> distro flames (no, I don't want to know which one is better). ]
>>>>
>>>> Curious minds want to know...
>>>
>>> At this point Sugar on Ubuntu is unusable broken.  Activity Central
>>> has signed a 12 month contract with Seeta.in to create and maintain
>>> Ubuntu on Sugar.  I hope that by Aug we will have a usable set of
>>> packages which can be test on the XO-1.5.
>>>
>>> As all ways, community support is appreciated.  A working Sugar on
>>> Ubuntu is just one of several protects which I feel need to be nudged
>>> into moving forward and I am just 'putting my money where my mouth
>>> is' to make it happen.
>>
>> I know the work you are sponsoring must be costing you lots, but if
>> you could sponsor someone to attend the next UDS, I think it will pay
>> off greatly.
>
> +1. Canonical has offer to sponsor two developer to the next UDS:)
>
>> I have to confess than in the Maverick UDS there was a blueprint about
>> Sugar but I messed the schedule up and attended something else instead
>> :(
>>
>> But once you get there, and if you can find the right person, you can
>> have a much better upstream-downstream conversation than most people
>> think.
>
> Phase one is improving the relationship with Debian and establishing
> credibility:)  As a summer internship LukeF is acting as a tour guide
> to Debian and Ubuntu.
>
> For phase two, I hope that we can show up at the next UDS with a
> working product (show me the code) and a skill team for developers and
> maintainers.

Sounds like a good strategy.

Btw, about hulahop and pyxpcom, Micah Gersten told me at the UDS that
they would love to have pyxpcom working on Ubuntu but that they need
first to take care of some infrastructure issues.

In a few weeks, it may be possible to package hulahop for Maverick and
backport it to an older release.

But of course, a PPA might be good enough for the moment.

Regards,

Tomeu

> david
>
>> https://blueprints.launchpad.net/ubuntu/+spec/community-maverick-edubuntu-packages
>>
>> Regards,
>>
>> Tomeu
>>
>>> david
>>>
>>>> Have you installed, or tried to install vanilla(ish) Ubuntu on an
>>>> XO-1.5? If yes, which version? What install process? Did it work?
>>>> Drivers missing our outdated? Did you have to grab custom packages?
>>>> (which ones?)
>>>>
>>>> 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
>>>>
>>> ___
>>> 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: Anyone playing with Ubuntu on XO-1.5?

[Tomeu Vizoso]

On Mon, Jun 14, 2010 at 18:33, David Farning  wrote:
> On Mon, Jun 14, 2010 at 11:06 AM, Martin Langhoff
>  wrote:
>> [ Put aside the tinfoil hats (there's no Ubuntu conspiracy) and the
>> distro flames (no, I don't want to know which one is better). ]
>>
>> Curious minds want to know...
>
> At this point Sugar on Ubuntu is unusable broken.  Activity Central
> has signed a 12 month contract with Seeta.in to create and maintain
> Ubuntu on Sugar.  I hope that by Aug we will have a usable set of
> packages which can be test on the XO-1.5.
>
> As all ways, community support is appreciated.  A working Sugar on
> Ubuntu is just one of several protects which I feel need to be nudged
> into moving forward and I am just 'putting my money where my mouth
> is' to make it happen.

I know the work you are sponsoring must be costing you lots, but if
you could sponsor someone to attend the next UDS, I think it will pay
off greatly.

I have to confess than in the Maverick UDS there was a blueprint about
Sugar but I messed the schedule up and attended something else instead
:(

But once you get there, and if you can find the right person, you can
have a much better upstream-downstream conversation than most people
think.

https://blueprints.launchpad.net/ubuntu/+spec/community-maverick-edubuntu-packages

Regards,

Tomeu

> david
>
>> Have you installed, or tried to install vanilla(ish) Ubuntu on an
>> XO-1.5? If yes, which version? What install process? Did it work?
>> Drivers missing our outdated? Did you have to grab custom packages?
>> (which ones?)
>>
>> 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
>>
> ___
> 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: [IAEP] ANNOUNCE: F11-0.88 Alpha2 (os258py)

[Tomeu Vizoso]

On Sat, Jun 12, 2010 at 20:03, Bernie Innocenti  wrote:
> This is the Alpha2 milestone of our Sugar 0.88 series for XO.
> Please refer to this page for the current status and download
> instructions:
>
>  http://wiki.sugarlabs.org/go/Deployment_Team/Sugar-0.88_Notes
>
> Surprise surprise! We now have parallel builds for both the XO-1 and the
> XO-1.5!
>
> I'll make an effort to keep the releases synchronized so people can test
> on both platforms, but at this time we have no resources to work on
> platform specific bugs affecting the XO-1.5.
>
>
> == Changes relative to the previous release (os240py) ==
>
>  * Include Sugar 0.88.1 packages (pbrobinson)
>
>  * Rebase unmerged patches on top of 0.88.1 and shave off a few
>   which are no longer needed. The queue is still very long, help
>   is needed to upstream as many as possible before release
>
>  * Disabled the hot corners for the frame, as requested by
>   participants of the OLPC Realness Summit. I'm not convinced
>   this is really a gain, but let's first see how many people
>   ask to revert this change (tch, bernie)
>
>  * Disable sshd startup to save time/memory (bernie)
>
>  * add IRC and SIP protocols to Empathy client (bernie)
>
>  * Include the Words activity (bernie)
>
>  * Add a few small content bundles (bernie)
>
>  * Pull latest OS updates from upstream (fedora)
>
>
> == Bugs fixed in this release ==
>
>  * xulrunner 1.9.2, attempting to fix font size problems (bernie)
>   http://bugs.sugarlabs.org/ticket/2018
>
>  * Prevent double-clicks on entries in the journal from opening
>   2-3 instances of the same activity (tch)
>
>  * Rework code to read name widget in the activity toolbar,
>   although there are still ways to fool it (bernie)
>   http://bugs.sugarlabs.org/ticket/1948
>
>  * Fix font size in Terminal (jasg)
>
>  * Fix layout of Record UI, although with a temporary kludge (m_anish)
>
>  * Reconnect to last AP on startup (erikos)
>   http://bugs.sugarlabs.org/ticket/1883
>
>  * Fix the nefarious 1-dot boot hang bug (dsd, bernie)
>
>  * Make search box in library homepage narrower so it doesn't overflow
>   (bernie)
>
>  * Avoid duplicated mesh icons in neighborhood view (tch)
>
>  * Proper Geode video driver fix for the "black boxes on buttons"
>   bug in GNOME. Note, (frank_huang)
>   https://bugs.freedesktop.org/show_bug.cgi?id=15700
>   http://dev.laptop.org/ticket/10076
>
>   NOTE: for safety, I have not yet removed the MigrationHeuristic
>   option in xorg.conf. Please, try testing without it.
>
>
> == Known bugs ==
>
> We still have a bunch of serious regressions still open:
>
>  * ALT-TAB does not switch between apps (tch, quozl, bernie)
>
>  * Activities sometimes start and remain in window. Window
>   appears at least briefly on all launches. (aa?)
>
>  * Pulsing launch icon is delayed or absent; occasional "activity
>   failed to start" message then the activity starts (tch)
>
>  * Measure sometimes locks up on recording, quitting from frame
>   then brings up metacity dialog "activity is not responding"
>   (I could never reproduce this myself)
>
>  * Font in Write is small and text does not fill the screen width (jasg)
>
>  * Browse: sometimes clicking links in frames creates tabs
>   (need someone to look at this. aa?)
>
>  * Turtle Blocks: ctrl-c ctrl-v sometimes do not work (walter)
>
>  * Sugar sometimes restarts; only seen 3 times, twice clicking on
>   journal and once deleting a journal entry
>   (can't reproduce this, maybe a geode driver bug. Next time please
>   check /var/log/Xorg.0.log.old and other logs)
>
> All the above bugs seem quite hard. Any help fixing them would be
> greatly appreciated.
>
>
> == How to help testing ==
>
> Feedback from the entire community is very appreciated, although we're
> not planning any further releases of the Sugar 0.84 series.
>
> Bugs affecting upstream components are better filed in their respective
> trackers:
>
>  * Sugar and activities: http://bugs.sugarlabs.org/
>  * Fedora 11: http://bugzilla.redhat.com/
>  * Drivers and OLPC OS customizations: http://dev.laptop.org/
>  * Paraguay-specific bugs: http://trac.paraguayeduca.org/
>
> If you're unsure where a bug belongs to, use the Paragauy Educa tracker.
> Please, always assign these bugs to "Carlos", who will keep our status
> summary updated.
>
>
> == Acknowledgments ==
>
> I wish to thank Paraguay Educa and Activity Central for providing
> essential engineering resources to make this effort possible.

Indeed, this is awesome work!

Keep it up,

Tomeu

> I also appreciate the expertise and support of many dedicated community
> developers and testers.
>
> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
>
> ___
> IAEP -- It's An Education Project (not a laptop project!)
> i...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>
___
Devel mailing list
Devel@lists.lapto

Re: [Sugar-devel] Multitouch in Fedora

[Tomeu Vizoso]

On Wed, Jun 9, 2010 at 22:18, Peter Robinson  wrote:
> Hi,
>
> I know people were wondering about multitouch. In the last couple of
> days there's a couple of posts regarding Multitouch in fedora for
> those that are interested.
>
> http://www.j5live.com/2010/06/09/multitouch-working-in-fedora/
>
> http://blogs.gnome.org/carlosg/2010/06/09/getting-multitouch-to-just-work/

I asked around yesterday and as far as I could see nobody were
planning any specific work on (multi-)touch with Gtk+. As the
companies doing Linux products with that capability had gone with Qt.

But just now have come across this news:

http://infoworld.com/d/mobilize/canonical-developing-ubuntu-os-tablets-778

I guess they are talking about something related to Unity, which is
Canonical's UX of choice for netbooks. Unity was supposed at the UDS
to sit in a similar place to GNOME Shell so it will most probably be
using multi touch with Gtk+.

If anybody has more details in how this impacts OLPC and Sugar, it
would be great if they could share.

Regards,

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

Re: [Tecnologia] Adaptación de cargador múltiple, by CATS.

[Tomeu Vizoso]

2010/6/3 Bernie Innocenti :
> El Mon, 31-05-2010 a las 11:14 +0200, Tomeu Vizoso escribió:
>
>> I would also like to know how this relates to the charger developed by
>> Uruguay's LATU and by OLPC.
>
> I don't know anything about their design.
>
> This one is really a hack done by hooking into the 12V rail of a common
> PC power supply. The advantage is that it costs close to nothing and
> it's easily reproducible everywhere.

Looks similar to what I saw in Montevideo, maybe the two teams could
improve their solutions if they shared their feedback?

Regards,

Tomeu

> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Testing] os240py - collaboration over wireless

[Tomeu Vizoso]

On Mon, May 31, 2010 at 15:35, Mikus Grinbergs  wrote:
>> I can only think of two reasons for sharing not working in mesh but
>> presence yes:
>>
>> - network congestion,
>
> In my case, there appear to be no other radio signals present.  If there
> is network congestion, the XOs are generating it themselves.

Would be good to be able to rule that out, but I don't think that's
too probable in your case.

>> - different link-local address setup,
>
> What I found interesting (by hovering over the respective icons in
> Frame), was that the SAME IP-address was assigned when connecting to the
> ad-hoc wireless network as had been assigned (before there was an ad-hoc
> network) when connecting using the mesh icons in Neighborhood View.
>
>>
>> - firewall settings.
>
> In my case, I'm connecting XO-to-XO.  There is no firewall.

I was referring to the local firewall, would be good to be able to
rule out that the iptables firewall wasn't configured correctly on
these images (has happened before).

Regards,

Tomeu

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

Re: [Testing] os240py - collaboration over wireless

[Tomeu Vizoso]

On Mon, May 31, 2010 at 07:03, James Cameron  wrote:
> I've reproduced "no sharing" over mesh on os240py.
>
> Activity sharing works via access point.
>
> Activity sharing works via "Create new wireless network" aka ad-hoc.

I can only think of two reasons for sharing not working in mesh but
presence yes:

- network congestion,

- different link-local address setup,

- firewall settings.

Debug logs for telepathy-salut and the output of /var/log/messages
would help diagnosing this.

Regards,

Tomeu

> --
> James Cameron
> http://quozl.linux.org.au/
> ___
> 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: [Tecnologia] Adaptación de cargador múltiple, by CATS.

[Tomeu Vizoso]

2010/5/30 Bernie Innocenti :
> El Wed, 12-05-2010 a las 16:49 -0400, Fernando Luis González Arriola
> escribió:
>> Hoy, con el esfuerzo de todo el TEAM, pudimos lograr hacer (o mejor
>> dicho adaptar) un mega cargador, que se puede utilizar tranquilamente
>> hasta con 9 equipos a la vez (quizás más), aquí van las fotos.
>
> Fernando, it would be great if we could describe this project in detail
> for the Paraguay Educa wiki.
>
> I think we should have:
>
>  - some of the photos you attached
>
>  - photos of the internals, showing how the wires are soldered
>
>  - a description of the wiring
>
>  - specs of the PC power supply
>
>  - tell how many laptops you could charge
>
>  - warnings and special notes
>
> Then, someone could translate it to English and publish it on
> wiki.laptop.org. It would be good publicity for CATS :-)

I would also like to know how this relates to the charger developed by
Uruguay's LATU and by OLPC.

Congratulations!

Tomeu

> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] ANNOUNCE: Sugar 0.88 for the XO-1

[Tomeu Vizoso]

On Tue, May 25, 2010 at 23:12, Peter Robinson  wrote:
> On Tue, May 25, 2010 at 9:23 PM, Bernie Innocenti  wrote:
>> El Tue, 25-05-2010 a las 19:16 +0100, Peter Robinson escribió:
>>
>>> Is F-11 still the base OS for this?
>>
>> Unfortunately, this build is still based on Fedora 11.
>>
>> Fedora 13 dropped support for the Geode processor, so it's not an
>> option. Upgrading to Fedora 12 would be possible, but there are unsolved
>> issues with the Geode video driver (jnettlet is working on it).
>
> That's not entirely true. The was no changes in CPU support from F-12
> to F-13. What has happened was a change in gcc which causes issues
> with F-13 on geode processors. There's a bit missing from gcc for
> geode support that would need to be added. dsd and cjb know more of
> the details.

I'm happy to hear this. F14 may bring interesting changes for the XO1,
can we hope that support for the Geode won't have been dropped by
then?

Thanks,

Tomeu

>> Considering the potential for hard to fix regressions, I felt that
>> upgrading to Fedora 12 was probably not worth the effort. Instead, I've
>> back-ported some useful things from Fedora 13: metacity-2.30,
>> xulrunner-1.9.2.3 and usb_modeswitch-1.1.2.
>>
>> Someone could try rebasing the builds on Fedora 12 in parallel with us.
>> If the result turns out to be very stable, we could consider switching.
>> All this would probably have happen before the first beta, so there's
>> not much time.
>
> If there's demand for it and its considered a 'good thing' I would
> consider pushing sugar 0.88 back to F-12. Not guaranteed, but its
> something that could be considered.
>
> Peter
> ___
> 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: compiz F11

[Tomeu Vizoso]

On Tue, May 25, 2010 at 20:52, Bernie Innocenti  wrote:
> El Tue, 25-05-2010 a las 12:46 -0300, Esteban Arias escribió:
>> It is posible install compiz on laptop xo to magnifier and zoom
>> desktop?
>
> Unfortunately, Compiz won't run on the XO-1 because it requires OpenGL.
>
> For accessibility purposes, you could use the magnifier of Orca:
>
>  http://live.gnome.org/Orca
>
>
> To make window transitions smoother, we could use a composing window
> manager which does not require OpenGL. Sugar 0.88 uses Metacity which
> supports composition.
>
> Probably worth trying, but it may very well turn out that composing huge
> windows (1200x900x16) ends up eating too much video memory on the Geode
> LX.

If the Sugar shell composited and uncomposited the windows, it could
do a better job at minimizing memory usage than any other component in
the system. Look for a recent thread in this mailing list called "The
All-Singing, All-Dancing XCompMGR".

Regards,

Tomeu

> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] New XO-1.5 10.2.0 build 125 - control panel

[Tomeu Vizoso]

On Sat, May 22, 2010 at 14:11, Bernie Innocenti  wrote:
> El Fri, 21-05-2010 a las 23:01 -0700, Yioryos Asprobounitis escribió:
>> Simple and quite effective :-)
>> Changing MAX_COLUMNS to 4 in 
>> /usr/lib/python2.6/site-packages/jarabe/controlpanel/gui.py did the trick.
>> And still has space for (just) one more control.
>
> Yes, but this is not general enough. It only happens to work for the
> 1200x900 display used by the XO-1 and XO-1.5. It would break even there
> if we change the font size or translate to a language with longer words.

Following the grid system that we should be using for layout, columns
would have a size expressed in whole cell units and a fixed number of
columns would work everywhere, though for wide screens there would be
some waste.

http://wiki.sugarlabs.org/go/Human_Interface_Guidelines/The_Sugar_Interface/Layout_Guidelines

About text, I'm afraid we cannot do anything else than let them wrap
if are too long, and just scroll vertically as needed.

Regards,

Tomeu

> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
> ___
> 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: Educational XHTML Editor Educational Game Maker

[Tomeu Vizoso]

On Thu, May 20, 2010 at 19:50, Mike Dawson  wrote:
> Dear David,
>
> Thanks for your email.  Will definitely try and put together an .xo
> activity for the version of eXe learning as it is now - should work.
>
> As a tool for the teachers and publishing to the school server -
> indeed would be nice and would be possible.  eXe can indeed make
> potential content producers far more productive.  I would rather stick
> with those junior officers in deployments and hire them rather than
> loading the job onto already overloaded teachers (or at least they are
> in our case).
>
> I guess one of the points of using eXe is that when you create content
> it is not tied to any specific platform - it will run on an android
> phone, web browser on any other computer etc.
>
> What you can expect is a compatibility drive.  It would be possible to
> make it export files to .xol for adding to the library automatically
> or indeed to making an activity .xo file directly from exe learning.
> You can also expect additional learning interaction formats to be
> added.
>
> I could definitely use help with pushing eXe further into the
> community - documentation, wikis tutorials etc. would be most useful
> indeed.   The more people using it and providing testimonials the
> better.  And what really matters is the more people creating
> interactive educational content - the better!

Hi, does it relate in any way with karma.js?

http://karmaeducation.org/

Regards,

Tomeu

> Regards,
>
> -Mike
>
> On 20 May 2010 04:01, David Leeming  wrote:
>> Mike,
>>
>> I have followed eXe Learning since it started, developed by Wayne Mackintosh
>> who later on, of course, created the WikiEducator and is a leading champion
>> of OERs. I can instantly see that eXe Learning if installed on the XOs would
>> be a very useful tool. Very easy to train teachers to become productive
>> quickly, compared with, say, online wiki work, which is not always an option
>> (yes we can install mediawiki on the XS but I think eXe Learning has
>> specific advantages in some areas). It is very well targeted technology,
>> thinking of the OLPC deployments in which I have been involved. As an
>> example, in a distance learning programme here in Solomons in 2007 we
>> converted examples of teacher training resources into online format using
>> eXe Learning, in order to demonstrate simple first steps in e-learning to
>> the Ministry. A junior officer with only basic office computing skills was
>> able to migrate the entire RTC teacher training manuals to online with
>> limited supervision - and she enjoyed it too!
>>
>> Of course, the resources produced with eXe Learning are HTML based which are
>> easy to install in public folders on the XS. eXe Learning can also output
>> SCORMs which can be loaded into the XS's Moodle as appropriate.
>>
>> If we had access to an eXe Learning activity I would immediately incorporate
>> it into the teacher training that we do in Pacific Islands deployments.
>> Empowering teachers to create and share resources is always a key component
>> of Level 2/3 training, linked to curriculum integration. OERs have massive
>> potential for the Pacific. Educators have repeatedly called for more
>> regionally relevant and localisable curriculum related content, and
>> empowerment of front line teachers to create OERs is the way to scalability
>> - freeing up the dependence on overworked curriculum departments locked into
>> traditional closed authoring approaches with long term donor programmes.
>> Resources created with eXe Learning by teachers with XOs will therefore have
>> a wide currency beyond the OLPC project areas which are still only small
>> scale. They can be shared and used freely.
>>
>> So, I will watch this thread carefully. I would like to help, if not as an
>> active team member on the coding, in other ways. What is the status of this,
>> can we expect an eXe Learning project for Sugar and the XO?
>>
>> One requirement would be to be able to create a resource using the "eXe
>> Learning" activity, name and save in journal, then to be able to upload it
>> to the server so that it is installed as a public folder (or via "site
>> files" etc) but without any difficult command line work needed on the
>> server. So needs to be coordined with XS-devel.
>>
>> David Leeming
>> Honiara, Solomon Islands
>>
>>
>> -Original Message-
>> From: devel-boun...@lists.laptop.org [mailto:devel-boun...@lists.laptop.org]
>> On Behalf Of Mike Dawson
>> Sent: Tuesday, 18 May 2010 6:53 a.m.
>> To: olpc-open; Developers List
>> Subject: Educational XHTML Editor Educational Game Maker
>>
>> Dear List,
>>
>> One of the greatest challenges here in deployments has been to create
>> sufficient curriculum *interactive* educational content.  Though
>> Scratch and Etoys are great for simulators for many common educational
>> interaction formats (e.g. assemble objects, click in place according
>> to hint in order, memory match, hangman, sorting items etc) using su

Re: The All-Singing, All-Dancing XCompMGR

[Tomeu Vizoso]

On Mon, May 3, 2010 at 15:34, Jon Nettleton  wrote:
>>> We could reuse the work done in Sugar 0.86 when we moved to metacity
>>> from matchbox. Or just use metacity which is also a compositing
>>> windowm manager.
>>
>> Or mutter which is the replacement to metacity for gnome 3 so should
>> be a reasonably easy swap from metacity and is used by gnome-shell and
>> moblin/(meego).
>>
>
> Unfortunately we cannot switch to mutter as that only uses Clutter as
> the compositing backend.  I know this because I am the person that
> patched the XRender compositing engine out of the source :-(  This
> means that mutter requires a 3-d accelerated graphics card.  This may
> be possible for the VX855 XO 1.5's but I don't think the XO1's would
> be able to handle this requirement.  The ARM based chips might be able
> to with Clutter using the OpenGL ES backend but I am pretty sure
> nobody has tested this yet.
>
> Metacity is definitely an option, but any enhancements done to it
> would need to be maintained in an OLPC/Sugar specific branch.
> Choosing this option would definitely need some time invested into
> running down some memory leaks and optimizing the engine.  Compositing
> in metacity was always an afterthought and never 100% got the love it
> needed to be used full time.  All this is fixable, just won't be done
> by the GNOME guys.

Ah, forgot to mention that if we are thinking seriously about using
composition, the best place to do composition management may be the
Sugar Shell, as it knows quit a bit about the window management but
also some Sugar-specific stuff. It could be as simple as redirecting
every top level window, but we could do tricks such as only keeping
redirected the root window and the last 2 activities that had the
focus, if we want to reduce memory usage.

I had at some point code to do this but it was some years ago and
would take a bit finding it. I remember I was calling some of these
calls through ctypes: http://linux.die.net/man/3/xcomposite Maybe just
XCompositeRedirectSubwindows and XCompositeUnredirectSubwindows.

Regards,

Tomeu

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

Re: The All-Singing, All-Dancing XCompMGR

[Tomeu Vizoso]

On Fri, Apr 30, 2010 at 22:35, Jon Nettleton  wrote:
>> I think our next steps should be to:
>>
>>  * quantify the memory difference (both total and per-window) against
>>   not running xcompmgr.  We were already running with the composite X
>>   extension on, so I think the increase may be small.
>>
>>  * work out whether we think the "frame pieces" drop shadow, and drop
>>   shadow in general, are an improvement -- we should ask the Sugar
>>   Design Team for their opinion on this too.
>>
>> Jon N, any opinions from the openchrome end on turning on xcompmgr?
>>
>
> Currently compositing on the VX855 with openchrome would work, but is
> extemely inefficient.  The openchrome support for the VX855 only
> supports XAA until we get DRI and DMA sorted out.  Compositing on XAA
> is really inefficient as only System Memory to VRAM actions are
> accelerated by the RENDER extension.
>
> Overall compositing is visually a nice improvement, but almost always
> at a cost of CPU and power.  I also think xcompmgr is not the right
> piece of software.  It is really old and missing a lot of the love
> needed for a good compositing manager to work seamlessly.  Mainly it
> is missing un-redirecting fullscreen windows and overlays causing
> video playback to be quite expensive, and OpenGL to be unreliable.
>
> Back when Thomas first wrote EXA support for the openchrome we found
> that the bare minimum you needed for descent compositing performance
> was 64MB of video ram.  This is doable but we also have to realize we
> are at a disadvantage because we run at a relative high resolution
> 1200x900.
>
> If we were going the compositing route I would probably suggest the
> project look into using a simple compositing window manager like XFWM
> from the XFCE project.  Their code was originally an import of
> xcompmgr, but they have done a great job improving it over the years.
> But I think that is another conversation entirely.

We could reuse the work done in Sugar 0.86 when we moved to metacity
from matchbox. Or just use metacity which is also a compositing
windowm manager.

Regards,

Tomeu

> Jon
> ___
> 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: Hulahop browser screen width XO1.0 vs XO1.5

[Tomeu Vizoso]

On Fri, Apr 23, 2010 at 01:18, George Hunt  wrote:
> No, I don't think it is a widget, gtk problem -- since I could change the
> CSS to correct the problem.
>
> I wrote a javascript fragment:
>
> document.write('width:' + window.screen.width + " height:" +
> window.screen.height);
>
> On XO1.0 I got a response: "width:840 height:634" and on XO1.5 I got
> "width:1200 height:900"
>
> If this is a known situation, and it is desired for some good reason, I'm
> sure people like me can live with it.  Otherwise I think the rendering
> engine on 1.0 and 1.5 should come up with similar defaults -- and
> considering our installed base-- it should be compatible 800x600.
>
> Persuant to Seth's suggestion, I've discovered that it is possible to write
> CSS using percentages rather than absolute pixel dimensions, and circumvent
> haveing to make a decision in javascript based upon reported screen
> dimension, and load separate CSS pages.
>
> Somebody has cleaned up the webview widget.  I'm having to work around a
> problem in build 802 that is fixed in F11 -- In the earlier build the widget
> controled it's own visibility by doing 'self.web_view.get_toplevel().hide()'
> which made it much more difficult to incorporate in at activity that wanted
> to use other widgets as well.
>
> Who's maintaining Hulahop/webview?

As per http://wiki.sugarlabs.org/go/Development_Team/Release/Modules#hulahop
hulahop is unmaintained, any help is welcome.

Regards,

Tomeu

> George
>
>
> On Thu, Apr 22, 2010 at 1:39 PM, Tomeu Vizoso  wrote:
>>
>> On Mon, Apr 19, 2010 at 04:27, George Hunt  wrote:
>> > Hi again,
>> >
>> > My activity uses Hulahop Browser for its help system.  The default
>> > browser
>> > on the XO`1.0 seems set up for 800x600.   The CSS width specs  on the
>> > functioning HELP activity add up to 800 px wide and everything works out
>> > ok.
>> >
>> > But on F11 XO1.5, the same help activity only renders about 2/3 full
>> > screen.
>> > And I'm experiencing similar problems rendering my help pages between
>> > 1.0
>> > and 1.5.
>> >
>> > On F11, I believe the default screen width sensed by the xulrunner
>> > engine is
>> > the 1200x900,   the actual screen size.
>> >
>> > I'm pretty sure there's a way to ask the gecko engine to render on a
>> > 800x600
>> > screen, or alternatively to ask gecko on the XO1.0 to render on a
>> > 1200x900
>> > surface.
>> >
>> > But I don't know XUL well and I feel I'd be wasting my time learning
>> > about
>> > how to set up gecko, if someone already knows how to solve this one.
>> > I'd be
>> > willing to modify HELP activity, once we I find an acceptable solution.
>>
>> Hmm, is the problem that the html content doesn't cover the whole
>> hulahop area, or that the hulahop widget doesn't fill the whole
>> screen?
>>
>> If the former, it's a matter of html. If the latter, hulahop is a
>> normal gtk widget and you should use the gtk api to make what you
>> want. Hulahop should behave the same as a gtk.Button in this regard,
>>
>> HTH,
>>
>> Tomeu
>>
>> > George
>> >
>> > ___
>> > 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: Hulahop browser screen width XO1.0 vs XO1.5

[Tomeu Vizoso]

On Mon, Apr 19, 2010 at 04:27, George Hunt  wrote:
> Hi again,
>
> My activity uses Hulahop Browser for its help system.  The default browser
> on the XO`1.0 seems set up for 800x600.   The CSS width specs  on the
> functioning HELP activity add up to 800 px wide and everything works out ok.
>
> But on F11 XO1.5, the same help activity only renders about 2/3 full screen.
> And I'm experiencing similar problems rendering my help pages between 1.0
> and 1.5.
>
> On F11, I believe the default screen width sensed by the xulrunner engine is
> the 1200x900,   the actual screen size.
>
> I'm pretty sure there's a way to ask the gecko engine to render on a 800x600
> screen, or alternatively to ask gecko on the XO1.0 to render on a 1200x900
> surface.
>
> But I don't know XUL well and I feel I'd be wasting my time learning about
> how to set up gecko, if someone already knows how to solve this one.  I'd be
> willing to modify HELP activity, once we I find an acceptable solution.

Hmm, is the problem that the html content doesn't cover the whole
hulahop area, or that the hulahop widget doesn't fill the whole
screen?

If the former, it's a matter of html. If the latter, hulahop is a
normal gtk widget and you should use the gtk api to make what you
want. Hulahop should behave the same as a gtk.Button in this regard,

HTH,

Tomeu

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

Re: [Sugar-devel] Flash activities?

[Tomeu Vizoso]

On Tue, Apr 13, 2010 at 10:59, Rafael Enrique Ortiz Guerrero
 wrote:
> Hi Esteban
>
> Take a look at the eatboom activity, it's an sketch to develop
> activities based on .swf files, thanks to  the work of tomeu and
> wadeb.
>
> http://activities.sugarlabs.org/en-US/sugar/addon/4225
>
>
> i use it to make
>
> http://people.sugarlabs.org/rafael/CuerpoHumano-1.xo

Some more info:

http://blog.tomeuvizoso.net/2009/04/embed-flash-movies-with-gnash-in-your.html

Would be good if you could get in contact with the OLE Nepal team
about this, they tried to use Flash as a platform for activity
development but dropped it for HTML5 instead. I'm adding Bryan Berry
to CC and here you have some links about it:

http://karmaeducation.org/
http://www.olpcnews.com/software/applications/karma_the_code_less_teach_more.html
http://karma.sugarlabs.org/

Regards,

Tomeu

>
> hth.
> Rafael Ortiz
>
>
>
> On Tue, Apr 13, 2010 at 9:02 AM, Esteban Arias
>  wrote:
>> Hi,
>>
>> exist some study for adobe FLASH on sugar 0.82 and XO 1.0 ?
>> requirements? considerations to develop activities?
>>
>> thanks
>> Esteban.
>>
>> ___
>> Sugar-devel mailing list
>> sugar-de...@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-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

[Server-devel] Fwd: [SoaS] wireless connection school server

[Tomeu Vizoso]

[Forwarding to the XS list]

-- Forwarded message --
From: David Leeming 
Date: Sun, Mar 28, 2010 at 23:02
Subject: [SoaS] wireless connection school server
To: SoaS 


Not sure if this is an SOAS or XS question or both!



I am trying out a mixed environment with XO-1s and SOAS.



The XOs are connected and registered on an XS with v 0.6. They connect
to a default network 172.18.0.0 wirelessly.



I have one PC netbook running SOAS 2 Blueberry. I can connect
wirelessly but it gives me a different network 10.42.xxx.xxx (or
close). The wireless icon on the SOAS shows me “connected to the
school server” but I can’t access any resources or register etc.



I then found I can do a wired connection, which works fine. It
connects on the default 172.18.0.0 network and I can access the XS
Moodle home page – which requires a username/password. It won’t let me
in or register the SOAS netbook until I created a user account using
the admin XO. I had to manually input the server qualified name in the
control panel of the SOAS netbook, and then I was able to register and
collaborate with the XOs (i.e. with the SOAS on a wired connection and
the XOs wireless).



Is this correct or have I missed an easier way?



What would I see if I had 2 or more computers running SOAS, connecting
wirelessly? Should they be receiving IP addresses in the default range
(172.18.0.0) or the other range I was observing (10.42.xxx.xxx)?





David Leeming

In PNG

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

Re: [Sugar-devel] Journal Backup/Restore UI

[Tomeu Vizoso]

On Mon, Mar 29, 2010 at 14:26, Bernie Innocenti  wrote:
> On Mon, 2010-03-29 at 10:14 +0200, Martin Langhoff wrote:
>> On Mon, Mar 29, 2010 at 2:22 AM, Bernie Innocenti  wrote:
>> > However, it looks like it would take a couple of months of effort to get
>>
>> I think you are overengineering this.
>>
>>  - Single-file restore is well solved by Moodle's backup/restore UI + Browse
>>
>>  - As you found out, librsync isn't what you want... just rsync _all_
>> of it, and then inject each entry using copy-to-journal. It doesn't
>> fix the disk usage problem, but it sure solves the "restart datastore"
>> and the associated issue that you are deleting whatever new was in the
>> Journal. You are not "restoring".
>
> Ok, how about:
>
>  - an initial rsync with no destination to list what's available
>
>  - rsync one file at a time + copy-to-journal.
>
> There's still the possibility that one very large file would make the
> entire process fail.
>
> Does the datastore support creating entries with no data and writing the
> data at a later time? I don't know much about the datastore design, but
> I got that we use uuids as keys, not hashes of the content.

Yup.

We do use hashes but only internally for detecting duplicates.

http://wiki.sugarlabs.org/go/Development_Team/Datastore_Rewrite

Regards,

Tomeu

>
>> Stoopid question: can't you 'FUSE'-mount the XS directory with sshfs
>> and then use copy-to-journal? Latency will make that a tad slower, but
>> the local-diskspace issue is gone.
>
> Very good idea.
>
>
> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] unable to share Activities on XO-1.5

[Tomeu Vizoso]

Hi,

On Mon, Mar 29, 2010 at 09:37, Christoph Derndorfer
 wrote:
> Out of cursiosity:
> Has anyone done real and actual testing of collaboration on XO-1.5s with
> the/a current operating system version? Particularly testing that goes
> beyond 2 or 3 XO-1.5s...
> I was certainly very surprised to hear about the issues that Adam and the
> rest of the DC Book Sprint team encountered when trying to take these
> screenshots for the "collaboration" section of the guide.
> Last but not least: Can we expect collaboration between XO-1s with 802 and
> XO-1.5s with whatever OS it will be shipped with to generally work? Or are
> there any major differences in the collaboration stack inbetween those two
> versions that could cause issues?

No known changes in the stack that could cause incompatibilities, but
different versions of an activity could be incompatible.

Regards,

Tomeu

> Thanks,
> Christoph
> --
> Christoph Derndorfer
> co-editor, olpcnews
> url: www.olpcnews.com
> e-mail: christ...@olpcnews.com
>
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Journal Backup/Restore UI

[Tomeu Vizoso]

I'm a bit confused, is the problem reliable full restore with limited
local space or the DS having the xapian DB open while the copy
happens? Or both?

Thanks,

Tomeu

On Fri, Mar 26, 2010 at 00:51, Bernie Innocenti  wrote:
> In Paraguay, we started discussing the topic of improving backup and
> restore procedures. Let's compare notes with a wider audience.
>
> We started from an existing backup/restore procedure written by Daniel
> Drake one year ago. It's meant to be invoked from the Terminal and uses
> a transactional approach:
>
> 1) the technician runs a script to restore the journal from the school
> server into a temporary directory while Sugar is still running;
>
> 2) then, you restart Sugar (by killing the sugar-shell process);
>
> 3) on startup, the olpc-session script notices the temporary directory
>    and replaces the datastore with it almost atomically.
>
> The problem with this approach was that it only works as long as there's
> a enough free space in the filesystem, which is rarely the case with
> laptops that are actually in use. Transactional behavior would be good
> to have, but I don't see how we could implement it reliably. Even an
> rsync in-place would have to be done with --delete-before to ensure it
> works all the time.
>
> This opens the question of how we stop the datastore from accessing the
> journal and mess it up while we're still updating it. We're currently
> doing it quite a gross way: kill the datastore process before beginning
> the restore, then restart Sugar:
>
>  http://trac.paraguayeduca.org/browser/scripts/os-modifications/diario-restaurar
>
> We'll thoroughly test this new kludge tomorrow. I'm confident it will
> work, but it's a shame that users need to call tech support in order to
> restore a backup.
>
> Perhaps it's time to add integrated backup/restore functionality to the
> datastore itself, with a nice UI in the Journal or in the control panel.
> The underlying mechanism could be as simple as the one we're testing
> now, but with proper synchronization with the datastore and no need to
> restart Sugar.
>
> Shall we go on and write a feature page, targeting 0.90? If it's done as
> a control panel item, it may be sufficiently self-contained to backport
> it all the way back to 0.84.
>
> For the time being, I might add the backup and restore scripts to
> olpc-utils. Or, better, create a new sugar-utils package for these
> things that are generally useful on any platform.
>
> Suggestions?
>
> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
> ___
> 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

Fwd: [Sur] XO para ciegos y disminuidos visuales.

[Tomeu Vizoso]

Hi John,

was wondering if you were already aware of this request from the field.

Regards,

Tomeu

-- Forwarded message --
From: Rafael Enrique Ortiz Guerrero 
Date: 2010/3/26
Subject: Re: [Sur] XO para ciegos y disminuidos visuales.
To: "OLPC para usuarios, docentes, voluntarios y administradores"



2010/3/25 Walter Bender :
> 2010/3/25 Walter Alan Mirwald :
>> El teclado qwerty de las computadoras o celulares usualmente viene con 3
>> teclas marcada para el uso de personas ciegas o con disminución visual, la
>> letra F, la letra J, y 5 del teclado numérico. Me parece importante ver la
>> posibilidad de modificar el teclado de las XO pues no están marcadas. Eso
>> ayudaría  a las personas C y DV ubicarse rápidamente en el teclado.
>>
>
> F y J tienen protuberancias en el teclado XO. Pero tal vez son
> demasiado sutiles.

Estoy de acuerdo estas marcas son solo ''puntos'' en las XO, en
laptops normales son mas apreciables.



> -walter
>
>>
>> Me interesa conocer mas de los proyectos educativos, desarrollo de softh y
>> actividades para sujetos con necesidades educativas especiales Por favor.
>> Gracias.
>>
>>
>>
>> Walter Mirwald
>>
>> La Rioja - Argentina
>>
>> profeespecialwal...@hotmail.com
>>
>>
>>
>>
>>
>> 
>> Tu Hotmail guarda el borrador que estás escribiendo para que no pierdas tu
>> mensaje. Conocé cómo
>> ___
>> Lista olpc-Sur
>> olpc-...@lists.laptop.org
>> http://lists.laptop.org/listinfo/olpc-sur
>>
>>
>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> ___
> Lista olpc-Sur
> olpc-...@lists.laptop.org
> http://lists.laptop.org/listinfo/olpc-sur
>
___
Lista olpc-Sur
olpc-...@lists.laptop.org
http://lists.laptop.org/listinfo/olpc-sur
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: To Gnome or not to Gnome

[Tomeu Vizoso]

On Fri, Mar 26, 2010 at 13:04, Bernie Innocenti  wrote:
> On Fri, 2010-03-26 at 03:47 -0700, Yioryos Asprobounitis wrote:
>> > You mean the blacked out GTK buttons and corrupt graphics
>> > in some web pages? We have a temporary workaround for these now!
>>
>> No, actually I was referring to an XO-1.5 bug (#10084)
>
> Ah, it's a different one. Yesterday I closed #7830 and #10076, though
> with a temporary work-around.
>
> The ultimate fix for all these bugs would have been a complete
> refactoring of the geode driver. Last time I looked at that codebase, it
> was full of magic numbers, with no bounds checking in some cases. We're
> very lucky if it works so well :-)
>
>
>> > Sounds right, but I'm not sure *who* is going to put their
>> > time into it.
>>
>> What about "Gnome people". I would guess they will not be indifferent
>> to the OLPC/XO. Couldn't they be "formally" asked for support?
>> (I know is upstream but...)
>
> Do you have good contacts within the Gnome community?

We could talk about this with the GNOME Foundation's board, they have
interest in pushing GNOME in developing countries. But the most they
could do (AFAIK) is motivating contributors to give some attention to
the issues we care about, but not more.

If anybody wants to take ownership of this area, I can give contacts
and introduce them to the board.

Regards,

Tomeu

> I reported only one bug in the Gnome bug tracker, but so far nobody
> replied:
>
>  https://bugzilla.gnome.org/show_bug.cgi?id=613852
>
> In this case, we're using current software which is shipped also by
> Fedora 12 and Karmic.
>
> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
> ___
> olpc mailing list
> o...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/olpc
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Adobe Flash 10.1 + AIR 2.0 on the XO

[Tomeu Vizoso]

On Wed, Mar 24, 2010 at 15:42, Gabriel Eirea  wrote:
> Hello, interesting thread.
>
>> FYI: One of our largest deployments and two other smaller deployments have
>> received approval to ship Adobe Flash in their builds.
>
> In Uruguay, Ceibal started shipping Adobe Flash with their official
> build at the beginning of 2009.
>
> My personal observation is that this came from a high demand on two
> fronts: kids and teachers complaining about youtube and online games
> on one side, and local companies used to develop web pages and such
> that wanted to create content but only had resources to do it in flash
> and complained about gnash being too restrictive on the other side.
>
> As far as I can see, the results are mixed. Playing youtube videos and
> other online music/video players is a big hit. However, the flash
> player performance in the XO is very bad,

An older release of Flash used to be good enough for youtube:

http://dev.laptop.org/ticket/5408

Apparently, they removed Xv support at some point.

Regards,

Tomeu

> kids complain that they
> can't play most of the games because characters move very slowly, etc.
> Local companies didn't add much to the content pool and all they can
> do in terms of business plan is get some government agency give them
> money for delivering a message. You can see some examples in:
>
> http://www.ceibal.edu.uy/index.php?option=com_content&view=article&id=216&Itemid=75
>
> My suggestion would be to use whatever contacts you may have at Adobe
> to communicate that:
>
> 1) they have to improve the player's performance on the XO
> 2) they have to make developers tools available for the XO
> 3) they have to develop a sugar wrapper to run swf files as activities
>
> and if they do that, flash may be a viable alternative for
> deployments. Otherwise it would never be.
>
> All this, IMHO.
>
> Regards,
>
> Gabriel
> ___
> 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: Adobe Flash 10.1 + AIR 2.0 on the XO

[Tomeu Vizoso]

On Wed, Mar 24, 2010 at 15:19, Bert Freudenberg  wrote:
> On 24.03.2010, at 14:12, Reuben K. Caron wrote:
>>
>>
>> On Mar 24, 2010, at 12:44 AM, Chris Ball wrote:
>>>
>>> 2) it is nowhere near possible to properly edit Flash content in a GUI
>>>  on an XO because the software to do so does not exist, and suffers
>>>  from a complex and underspecified set of compatibility requirements.
>>
>> I'll refrain from listing the software on the XO that is nowhere near
>> possible to edit on the XO because either the source code is not
>> available or the XO does not meet the technical requirements to run
>> necessary software.
>
> And how is being imperfect an argument for giving up ones ideas?
>
> Besides, all source code for all applications is available. As much of Sugar 
> as possible was coded in Python, not the least to allow tinkering. The Etoys 
> activity even comes with a full Smalltalk IDE (you know, the one that 
> inspired countless other IDEs including Eclipse). That's the direction we 
> prefer to explore. But even then we don't prevent others from exploring other 
> directions.

In case it brings anything to this discussion, some months ago I spent
quite a bit of days from my time in making easier to create content
for Sugar with Flash, and ultimately failed because I didn't had the
money to pay for the tools that would have allowed me to debug the
Flash content:

http://blog.tomeuvizoso.net/2009/04/embed-flash-movies-with-gnash-in-your.html

If anybody wants more examples of people who tried to do Flash content
and failed, talk with the OLE Nepal guys, who invested several
people-years in creating Flash content and are now rewriting it in
HTML5:

http://karmaeducation.org/

I'm not saying that Flash is "bad", just that every technology has
their trade-offs and sometimes you need to get your feet wet before
you can tell if its appropriate for your use case or not.

Regards,

Tomeu

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

Re: [Sugar-devel] [IAEP] Children want Sugar 0.84, for the wrong reason

[Tomeu Vizoso]

On Mon, Mar 22, 2010 at 11:51, Bernie Innocenti  wrote:
> On Mon, 2010-03-15 at 16:03 -0500, Martin Langhoff wrote:
>> Agreed. You can do what you are doing (run a school on newish sw, get
>> a tight feedback & bugfix loop) when someone like you is there.
> [...]
>> Yes -- but we gotta remember that it's productive (specially for
>> Sugar) because you are there. You can turn their frustration into
>> valuable info (and bugfixes). Without you, it's just frustration.
>
> Indeed :-(
>
> I'm trying to get everyone on IRC and mailing lists before I leave. In
> Nepal it worked, but here the language barrier is higher.
>
> I told everyone that Spanish is welcome in bug reports, blog posts and
> for chatting on #sugar. Many of our core developers speak Spanish
> fluently, so they could bridge information to the others.
>
> Admittedly, it's not working: people come to IRC, they see that everyone
> speaks English, and shy away. I don't believe in breaking the community
> apart in many per-language ghettos, but Spanish probably has enough
> critical mass to justify a #sugar-es (or #olpc-es) channel.

I have invested efforts in the past in that direction, but they
haven't taken off. We have sugar-desarrollo and we used to have a
channel as well, but haven't seen much use.

If we had a deployment team, we could try to make a push so that
people from different deployments talk together in an open space...

Regards,

Tomeu

>> That's a good idea -- try to work in a school with "latest" Sugar late
>> in the previous school year, to incorporate stuff for the wider
>> deployment in the over-summer-holidas upgrade.
>>
>> (And actually we have a late-starting deployment in La Rioja, which is
>> on-time to take advantage of that work.)
>
> Cool! A lot of stuff is moving forward here:
>
> * This Monday we'll have another meeting with the "formadores" to help
>   them file complete and understandable bug reports without the need
>   for us to go on-site.
>
> * We're now tracking the remaining bugs here:
>   http://wiki.paraguayeduca.org/index.php/Devel/Builds/Todo
>
> * Two more developers of the Paraguay Educa technical team are learning
>   to create OS builds. Next week, they'll start helping out with
>   activities.
>
> * The formadores (teacher trainers) got used to the differences
>   in the new software release and are no longer diffident.
>
>
>> That's truly a good question. I'll say "the teams closest to the
>> deployments". "Distant" upstreams (kernel, udev, Fedora) don't care
>> directly about our end users. OLPC/SLers are passionate about children
>> learning.
> [...]
>> Yep - that and combine it with working with a few schools on recent
>> releases, with a developer on-site -- like you, Simon and others are
>> doing.
>
> Yes, we definitely need more errant developers! Since there's a limited
> amount of core developers in OLPC and SL, in the future we may want to
> encourage deployments to exchange developers. The Paraguayan team now
> employs hackers with two years of experience. The same is probably true
> in Uruguay.
>
> It would be great if one of them could travel to the fledgling
> Argentinian deployment and help them build capacity locally. A
> decentralized model of international collaboration would solve the
> scalability problem.
>
>
>> In practice, it probably means we'll be answering questions about any
>> release for about 1.5 to 2 years after the release date.
>
> Interestingly, Mark Shuttleworth has recently argued for a 2 years cycle
> synchronized across all the enterprise distributions:
>
>  http://www.markshuttleworth.com/archives/290
>
> If his proposal acquires enough momentum within the community, it would
> make sense for us to synchronize with it, solving the issue of being
> left behind by the rest of the development community.
>
>
>> N. I'm not so crazy. But we have to fit in the school's
>> 1-year-cycle, have time to stabilise, etc. Small deployments have more
>> flexibility, and when someone like you is literally on site you can go
>> wild... (take advantage of that!) but for the thousands of other
>> schools an LTS
>
> Testing and stabilize a new version of Fedora and Sugar on the XO could
> be done with as little as a few thousand students in a small town, with
> just 1-2 developers on site.
>
> After we're done with Sugar 0.84, I'll try to repeat the development
> cycle for Sugar 0.88 and Fedora 12, starting with few adventurous
> volunteers such as the Scratcheros.
>
> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
>
> ___
> 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: [IAEP] Sugar Labs Accepted as GSoC 2010 Organisation

[Tomeu Vizoso]

On Thu, Mar 18, 2010 at 21:39, Tim McNamara  wrote:
> Chris -
> You must have known something! Sugar Labs is part of the fold. [1]
> Thanks all for helping me along. Now the real fun starts :)

Congratulations and good luck!

Tomeu

> Tim
> @timClicks
>
> [1] http://socghop.appspot.com/gsoc/program/accepted_orgs/google/gsoc2010
> On 13 March 2010 12:11, Chris Ball  wrote:
>>
>> Hi Tim,
>>
>>   > Sugar Labs application for Google Summer of Code 2010 has been
>>   > accepted.
>>
>> Wow, that was quick.  Many congrats and thanks!
>>
>>   > I'm not sure exactly on the politics of the situation, but my
>>   > personal feeling is that we should be quite encouraging of
>>   > supporting OLPC projects.
>>
>> That sounds great; I'd be happy to chat more about this.
>>
>> - Chris.
>> --
>> Chris Ball   
>> One Laptop Per Child
>
>
> ___
> IAEP -- It's An Education Project (not a laptop project!)
> i...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Problem importing hulahop.webview() in sugar emulator

[Tomeu Vizoso]

On Fri, Feb 26, 2010 at 20:56, vijit singh  wrote:
> Hello Tomeu,
> Thank You once again for your guidance. Surely I will keep on posting the
> updates. I was also confused about the use of the statement-
> hulahop.startup(os.path.join(env.get_profile_path(), 'gecko'))
> What is the significance of hulahop.startup? It surely seems to be imp.
> since the absence of this line results into an error.
> Also, gecko folder seems to be containing paths to different xulrunner
> files. Does including the same gecko folder (as is used in sugar) into the
> socialcalc package which we will make for fedora, and referring to this
> folder through the hulahop.startup statement work on fedora as well?
Hi Vijit,

if you look at the source code, you can see it's the path to the
profile directory:

http://git.sugarlabs.org/projects/hulahop/repos/mainline/blobs/master/python/__init__.py#line41

https://wiki.mozilla.org/XULRunner#User_Profiles

 Kindly
> give some pointers.
> Regards,
> VIJIT
> On Fri, Feb 26, 2010 at 8:21 PM, Tomeu Vizoso  wrote:
>>
>> 2010/2/23 vijit singh :
>> > Hello Tomeu,
>> > I tried installing hulahop again as you suggested on fedora-11 and it
>> > got installed properly. Now, the socialcalc and the browse activity are
>> > running as well. Thank you for your guidance.
>> > Also wished to discuss that we are planning to port SocialCalc on
>> > various linux distros starting from Fedora. The first approach which we are
>> > considering is by using a pygtk based root-level window to embed
>> > hulahop.webview widget in quite a similar fashion as it has been done in
>> > Sugar currently. Do you think it would be a feasible approach? Is there any
>> > other approach which you suggest would be better? Kindly give some pointers
>> > on the issue.
>>
>> This is the approach that I would recommend. Please keep us posted!
>>
>> Regards,
>>
>> Tomeu
>>
>> > Regards,
>> > VIJIT
>> >
>> >
>> > On Tue, Feb 16, 2010 at 12:29 AM, Tomeu Vizoso 
>> > wrote:
>> >>
>> >> On Mon, Feb 15, 2010 at 18:56, Vijit Singh  wrote:
>> >> > Hello Tomeu and Aleskey,
>> >> > Thank you for your replies. I will test your suggestions in a day or
>> >> > two and
>> >> > will let you know about the results since I have been out of town and
>> >> > hence
>> >> > unable to access net since the last 2 days.
>> >> >
>> >> > On Sun, Feb 14, 2010 at 1:14 AM, Tomeu Vizoso 
>> >> > wrote:
>> >> >>
>> >> >> On Fri, Feb 12, 2010 at 23:36, vijit singh
>> >> >> 
>> >> >> wrote:
>> >> >> > Hello everyone,
>> >> >> > SocialCalc is based upon the use of hulahop.webview widget. While
>> >> >> > trying
>> >> >> > to
>> >> >> > run socialcalc on sugar emulator running on Fedora and Ubuntu,
>> >> >> > error
>> >> >> > saying
>> >> >> > "No module hulahop" was occurring. So, we tried installing hulahop
>> >> >> > on
>> >> >> > these
>> >> >> > linux distributions.
>> >> >> > 1. Firstly we tried with ubuntu-8.10, here are the exact steps
>> >> >> > taken-
>> >> >> >
>> >> >> >  xulrunner was pre-installed. And then I
>> >> >> > installed python-support.deb
>> >> >> > and
>> >> >> > libxul0d.deb which are pre-requistie packages for python-xpcom
>> >> >> > package
>> >> >> > (other pre-requistie packages were already installed). Then i
>> >> >> > installed
>> >> >> > python-xpcom. And then I installed python-hulahop and hulahop.
>> >> >> >
>> >> >> > Downlaod links for these packages are as follows:-
>> >> >> >
>> >> >> > http://packages.ubuntu.com/en/intrepid/python/python-xpcom
>> >> >> > http://packages.ubuntu.com/en/intrepid/hulahop
>> >> >> > http://packages.ubuntu.com/en/intrepid/python-hulahop
>> >> >> > Now, though hulahop was getting imported but while using
>> >> >> > hulahop.webview, an
>> >> >> > error saying "hulahop has no attribute webview" occured. However,
>> >> >> >

Re: [Sugar-devel] Problem importing hulahop.webview() in sugar emulator

[Tomeu Vizoso]

2010/2/23 vijit singh :
> Hello Tomeu,
> I tried installing hulahop again as you suggested on fedora-11 and it got 
> installed properly. Now, the socialcalc and the browse activity are running 
> as well. Thank you for your guidance.
> Also wished to discuss that we are planning to port SocialCalc on various 
> linux distros starting from Fedora. The first approach which we are 
> considering is by using a pygtk based root-level window to embed 
> hulahop.webview widget in quite a similar fashion as it has been done in 
> Sugar currently. Do you think it would be a feasible approach? Is there any 
> other approach which you suggest would be better? Kindly give some pointers 
> on the issue.

This is the approach that I would recommend. Please keep us posted!

Regards,

Tomeu

> Regards,
> VIJIT
>
>
> On Tue, Feb 16, 2010 at 12:29 AM, Tomeu Vizoso  wrote:
>>
>> On Mon, Feb 15, 2010 at 18:56, Vijit Singh  wrote:
>> > Hello Tomeu and Aleskey,
>> > Thank you for your replies. I will test your suggestions in a day or two 
>> > and
>> > will let you know about the results since I have been out of town and hence
>> > unable to access net since the last 2 days.
>> >
>> > On Sun, Feb 14, 2010 at 1:14 AM, Tomeu Vizoso  
>> > wrote:
>> >>
>> >> On Fri, Feb 12, 2010 at 23:36, vijit singh 
>> >> wrote:
>> >> > Hello everyone,
>> >> > SocialCalc is based upon the use of hulahop.webview widget. While trying
>> >> > to
>> >> > run socialcalc on sugar emulator running on Fedora and Ubuntu, error
>> >> > saying
>> >> > "No module hulahop" was occurring. So, we tried installing hulahop on
>> >> > these
>> >> > linux distributions.
>> >> > 1. Firstly we tried with ubuntu-8.10, here are the exact steps taken-
>> >> >
>> >> >  xulrunner was pre-installed. And then I installed python-support.deb
>> >> > and
>> >> > libxul0d.deb which are pre-requistie packages for python-xpcom package
>> >> > (other pre-requistie packages were already installed). Then i installed
>> >> > python-xpcom. And then I installed python-hulahop and hulahop.
>> >> >
>> >> > Downlaod links for these packages are as follows:-
>> >> >
>> >> > http://packages.ubuntu.com/en/intrepid/python/python-xpcom
>> >> > http://packages.ubuntu.com/en/intrepid/hulahop
>> >> > http://packages.ubuntu.com/en/intrepid/python-hulahop
>> >> > Now, though hulahop was getting imported but while using
>> >> > hulahop.webview, an
>> >> > error saying "hulahop has no attribute webview" occured. However, when
>> >> > we
>> >> > checked the hulahop folder, there was a file named webview.py, so this
>> >> > problem might be because of some kind of wrongly set library paths.
>> >> > 2. Then we tried it with ubuntu-9.10, with similar steps but got the
>> >> > same
>> >> > result.
>> >> > 3. Then we tried it with fedora-11-
>> >> > Installed hulahop and then xpcom from the following
>> >> >
>> >> > link- http://www.rpmfind.net/linux/RPM/mandriva/2009.1/i586/media/main/release/python-xpcom-1.9.0.8-1mdv2009.1.i586.html
>> >>
>> >> This is a Mandriva package. I recommend using the tools available in
>> >> each distro for installing software. In Fedora it would be: "yum
>> >> install hulahop"
>> >
>> > We tried yum install hulahop but it said no package named hulahop, our 
>> > first
>> > approach on fedora was to use yum and on ubuntu was to use apt get, but 
>> > both
>> > gave the same results.
>>
>> In Fedora 11, this is the ouput of yum search hulahop:
>>
>> [to...@zviratko ~]$ yum search hulahop
>> Loaded plugins: fastestmirror, presto, refresh-packagekit
>> === Matched: hulahop 
>> ===
>> hulahop.i586 : A pygtk widget for embedding mozilla
>>
>> Are you sure you wrote the name of the package correctly?
>>
>> Regards,
>>
>> Tomeu
>>
>> > Regards,
>> > VIJIT
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Test request: Overwhelm chat

[Tomeu Vizoso]

On Fri, Feb 12, 2010 at 12:54, Martin Langhoff
 wrote:
> Long time ago, we've seen Chat.xo get slower and slower as messages
> pile up. It didn't seem to be a network issue, but a "draw it on the
> screen" or perhaps on the scrollable canvas.
>
> Here is the original bug report. It was done with an XS, and the
> networking side (wifi, XS) was not saturated. It just seemed like Chat
> could not handle the traffic for purely "local" reasons.
>
> Does this still happen on SoaS Strawberry? Blueberry? Latest?

I don't think there have been changes in Chat in this direction.

I can give directions for profiling if someone is interested in
looking at this? Maybe someone from an OLPC deployment?

Regards,

Tomeu

> This one is easy to test with a few XOs or SoaS machines and
> hiperactive testers... It will probably be more visible on XO-1s
> because the CPU and GPU are fairly limited in performance.
>
> (I ask Strawberry because that's the Sugar that gets deployed on XO-1.5s ;-) )
>
>
>
> 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
> ___
> 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: [SoaS] Using SoaS Blueberry to emulate OLPC F11 builds

[Tomeu Vizoso]

On Wed, Feb 10, 2010 at 15:15, Reuben K. Caron  wrote:
>
> On Feb 9, 2010, at 5:22 PM, Martin Langhoff wrote:
>
>> On Tue, Feb 9, 2010 at 11:10 PM, Reuben K. Caron 
>> wrote:
>>> 2.2 GB
>>
>> Cool.
>>
>> BTW, I just reviewed the src for olpc-switch-desktop and I think that
>> if you just
>>
>>  ln -s /home/liveuser /home/olpc
>>
>> before installing the rpm, it'll just work. (You can remove &
>> reinstall for example).
>
> That doesn't work. Running olpc-session as dsd mentions does overlay
> the sugar-ui on top of Gnome.

I haven't followed this thread in all its complexity, but what about
running sugar-emulator from GNOME?

Regards,

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

Re: [Sugar-devel] Problem importing hulahop.webview() in sugar emulator

[Tomeu Vizoso]

On Mon, Feb 15, 2010 at 18:56, Vijit Singh  wrote:
> Hello Tomeu and Aleskey,
> Thank you for your replies. I will test your suggestions in a day or two and
> will let you know about the results since I have been out of town and hence
> unable to access net since the last 2 days.
>
> On Sun, Feb 14, 2010 at 1:14 AM, Tomeu Vizoso  wrote:
>>
>> On Fri, Feb 12, 2010 at 23:36, vijit singh 
>> wrote:
>> > Hello everyone,
>> > SocialCalc is based upon the use of hulahop.webview widget. While trying
>> > to
>> > run socialcalc on sugar emulator running on Fedora and Ubuntu, error
>> > saying
>> > "No module hulahop" was occurring. So, we tried installing hulahop on
>> > these
>> > linux distributions.
>> > 1. Firstly we tried with ubuntu-8.10, here are the exact steps taken-
>> >
>> >  xulrunner was pre-installed. And then I installed python-support.deb
>> > and
>> > libxul0d.deb which are pre-requistie packages for python-xpcom package
>> > (other pre-requistie packages were already installed). Then i installed
>> > python-xpcom. And then I installed python-hulahop and hulahop.
>> >
>> > Downlaod links for these packages are as follows:-
>> >
>> > http://packages.ubuntu.com/en/intrepid/python/python-xpcom
>> > http://packages.ubuntu.com/en/intrepid/hulahop
>> > http://packages.ubuntu.com/en/intrepid/python-hulahop
>> > Now, though hulahop was getting imported but while using
>> > hulahop.webview, an
>> > error saying "hulahop has no attribute webview" occured. However, when
>> > we
>> > checked the hulahop folder, there was a file named webview.py, so this
>> > problem might be because of some kind of wrongly set library paths.
>> > 2. Then we tried it with ubuntu-9.10, with similar steps but got the
>> > same
>> > result.
>> > 3. Then we tried it with fedora-11-
>> > Installed hulahop and then xpcom from the following
>> >
>> > link- http://www.rpmfind.net/linux/RPM/mandriva/2009.1/i586/media/main/release/python-xpcom-1.9.0.8-1mdv2009.1.i586.html
>>
>> This is a Mandriva package. I recommend using the tools available in
>> each distro for installing software. In Fedora it would be: "yum
>> install hulahop"
>
> We tried yum install hulahop but it said no package named hulahop, our first
> approach on fedora was to use yum and on ubuntu was to use apt get, but both
> gave the same results.

In Fedora 11, this is the ouput of yum search hulahop:

[to...@zviratko ~]$ yum search hulahop
Loaded plugins: fastestmirror, presto, refresh-packagekit
=== Matched: hulahop ===
hulahop.i586 : A pygtk widget for embedding mozilla

Are you sure you wrote the name of the package correctly?

Regards,

Tomeu

> Regards,
> VIJIT
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Problem importing hulahop.webview() in sugar emulator

[Tomeu Vizoso]

On Fri, Feb 12, 2010 at 23:36, vijit singh  wrote:
> Hello everyone,
> SocialCalc is based upon the use of hulahop.webview widget. While trying to
> run socialcalc on sugar emulator running on Fedora and Ubuntu, error saying
> "No module hulahop" was occurring. So, we tried installing hulahop on these
> linux distributions.
> 1. Firstly we tried with ubuntu-8.10, here are the exact steps taken-
>
>  xulrunner was pre-installed. And then I installed python-support.deb and
> libxul0d.deb which are pre-requistie packages for python-xpcom package
> (other pre-requistie packages were already installed). Then i installed
> python-xpcom. And then I installed python-hulahop and hulahop.
>
> Downlaod links for these packages are as follows:-
>
> http://packages.ubuntu.com/en/intrepid/python/python-xpcom
> http://packages.ubuntu.com/en/intrepid/hulahop
> http://packages.ubuntu.com/en/intrepid/python-hulahop
> Now, though hulahop was getting imported but while using hulahop.webview, an
> error saying "hulahop has no attribute webview" occured. However, when we
> checked the hulahop folder, there was a file named webview.py, so this
> problem might be because of some kind of wrongly set library paths.
> 2. Then we tried it with ubuntu-9.10, with similar steps but got the same
> result.
> 3. Then we tried it with fedora-11-
> Installed hulahop and then xpcom from the following
> link- http://www.rpmfind.net/linux/RPM/mandriva/2009.1/i586/media/main/release/python-xpcom-1.9.0.8-1mdv2009.1.i586.html

This is a Mandriva package. I recommend using the tools available in
each distro for installing software. In Fedora it would be: "yum
install hulahop"

> Now, when we tried to use hulahop.webview, the following error
> occured- http://pastebin.be/23452. though hulahop was getting imported
> properly in this case as well.
> Could someone please guide us about what are right steps in case we are
> wrong somewhere. Also has anyone been able to use
> hulahop.webview  successfully on linux distros before?

Sugar's Browse is known to run in all those distros (and many more),
though in the Ubuntu case I think you need to use PPAs as explained
in:

http://wiki.sugarlabs.org/go/Community/Distributions/Ubuntu

Regards,

Tomeu

> Regards,
> VIJIT
>
>
>
>
>
>
>
> ___
> 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: [Sugar-devel] Serious screen distortion using firefox 3.5 and 3.6

[Tomeu Vizoso]

On Tue, Jan 26, 2010 at 11:24, Bryan Berry  wrote:
> I run firefox 3.6 and 3.5 on gnome on my desktop w/ no such issue.
> I should try SoaS and see if I have the same problem. Can u recommend a
> particular SoAS release for me to test?
> I fear that firefox now runs some of the rendering in a separate thread, one
> that gets starved on the XO's limited single-core CPU

Hmm, I still think that doing the test on firefox on gnome on xo1
would tell us quite a bit. Maybe one of the people testing the f11
builds would like to give it a try? I'm cc'ing fedora-olpc and OLPC's
devel ml.

I would expect you to find the same bug on SoaS-on-XO1.

Regards,

Tomeu

> On Tue, Jan 26, 2010 at 3:59 PM, Tomeu Vizoso  wrote:
>>
>> On Tue, Jan 26, 2010 at 07:01, Bryan Berry  wrote:
>> > I have tested firefox 3.5 and 3.6 on the XO with Sugar version
>> > sugar-0.81.7-1.
>> > I see significant distortion of png images
>> > I also had this issue w/ os10 (0.84? 0.86?)
>>
>> I think os10 also has gnome, can you see if firefox on gnome also has
>> this problem?
>>
>> Thanks,
>>
>> Tomeu
>>
>> > http://dev.laptop.org/~smparrish/XO-1/builds/OS10/
>> > http://trac.sugarlabs.org/attachment/ticket/1689/firefox-3-6-blur1.png
>> > http://trac.sugarlabs.org/attachment/ticket/1689/firefox-3-6-blur2.png
>> > http://trac.sugarlabs.org/attachment/ticket/1689/karma-template1.png
>> > I have already created a ticket on the issue
>> > http://trac.sugarlabs.org/attachment/ticket/1689
>> > ___
>> > 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: [Sugar-devel] New release of F11 for the XO-1 - Build11

[Tomeu Vizoso]

Hi, just a clarification:

On Tue, Jan 12, 2010 at 21:41, Yuan Chao  wrote:
> On Mon, Jan 11, 2010 at 3:50 AM, Stanley Sokolow  
> wrote:
>
>> 2GB SD card in my XO, and I have Firefox on it.   I installed the ePubReader
>> plug-in for Firefox.   This runs nicely and allows you to view eBooks in
>> ePub format, which is the up-and-coming open format for books.   You can
> This comes back to an old issue: though the browser activity on XO is based on
> xulRunner, which is of the same engine as Firefox, it doesn't support
> plug-ins. I recall
> there were some efforts been done, but not sure what's the latest progress?

Browse does support all plugins that Firefox supports. What you might
be meaning is extensions (addons). Depending on what extends a
particular extension, it can work in Browse. If the extension extends
mechanics not specific to Firefox (such as Google Gears) then it will
work in Browse as well. If it extends functionality only in Firefox,
then it won't work in Browse.

Some info on extensions:
http://blog.tomeuvizoso.net/2009/05/installing-mozilla-addons-in-sugars.html

> There were some efforts to use webkit as Browser activity back-end,
> also no progress
> afterwards?

My understanding is that every time that work on a Webkit backend has
restarted, the measured benefits haven't been so big because all the
major browser are playing catch up with each other.

If someone could clearly articulate the benefits of switching to
webkit, maybe we could do it one day.

Regards,

Tomeu


> BTW, with the rotation bug fixed, I noticed that the Browser (and
> Firefox) activity do
> respect the screen orientation such that the cursor keys are
> "rotated". It's also a bit
> un-natural that the game buttons doesn't rotate the page up/down mappings.
> However, for 90 and 270 degree orientation, the cursor key mapping are
> in wrong parity,
> while it's correct for 0 and 180 degree. Where should I issue this
> bug? system or activity?
>
> BTW, have you tried 'yum install fbreader'?
>
>
>> On Sun, Jan 10, 2010 at 5:14 PM, rihowa...@gmail.com 
>> wrote:
>>>
>>> Some quick observations on  F11 for the XO-1 - Build11.
>>>
>>> ...
>>
>>  
>>>
>>> Gnome Desktop mode:
>>> In previous builds Midori was used as the web browser in gnome now Firefox
>>> is being pulled in.  Is this an intentional change or a side effect of
>>> changing the build system?  Midori is general considered to use less
>>> resources than Firefox.
>>
>>
>> ___
>> Devel mailing list
>> Devel@lists.laptop.org
>> http://lists.laptop.org/listinfo/devel
>>
>>
>
>
>
> --
> Best regards,
> Yuan Chao
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Shutdown proces on F9 (8.2.x builds)... who kills X.org?

[Tomeu Vizoso]

On Mon, Jan 11, 2010 at 12:46, Martin Langhoff
 wrote:
> With the help of Mikus, a specific shutdown bug has been narrowed
> down, and I think it's a race with the X.org server needing a little
> bit longer to shut down cleanly.
>
> More details on the bug itself at http://dev.laptop.org/ticket/9943
> ("Shutdown process stops in text console when USB keyboard in use").
>
> But it is not clear to me who is killing X.org in these builds. I am a
> bit old fashioned (ie: I first look at rc6.d) but probably hal, udev,
> hot/cold plug et al are the murderours characters.
>
> (It is a low priority bug as it's fairly specific in the steps to
> trigger it -- but fixing bugs is what we're here for... help welcome)

In case you end up trying to trace this yourself, this systemtap
script has been useful for me in a similar situation:

http://sourceware.org/systemtap/examples/process/sigkill.stp

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] New release of F11 for the XO-1 - Build11

[Tomeu Vizoso]

On Mon, Jan 11, 2010 at 03:50, Stanley Sokolow  wrote:
> My thoughts about Firefox.   Even if it uses more resources than Midori,
> it's worth the extra bytes.   I am running Xubuntu (Teapot edition) from a
> 2GB SD card in my XO, and I have Firefox on it.   I installed the ePubReader
> plug-in for Firefox.   This runs nicely and allows you to view eBooks in
> ePub format, which is the up-and-coming open format for books.   You can
> get  free ePub eBooks from several free sites, including books.google.com,
> www.feedbooks.com/publicdomain, and gutenberg.org.  Project Gutenberg plain
> text files can be read on the XO in Sugar using the Read ETexts activity,
> but that activity says "Read Etexts is similar to the original Read
> activity, but instead of PDFs this activity works with the plain text files
> created for Project Gutenberg."    Plain text versions are inferior to the
> nicely formatted ePub books.

Just for the record, it's the Read activity which supports ePub files.

http://sayamindu.randomink.org/ramblings/2009/06/18/read-and-epub-and-beyond/

Regards,

Tomeu

> To get the ePubReader plugin, all you do is go
> to "Tools > Add-ons > Get Add-ons" in Firefox and search for ePubReader.
> It even updates itself when new releases of the plug-in come out.
>
> Xubuntu doesn't use Gnome, but instead uses Xfce the light-weight window
> manager.  I would rather give up Gnome's bulk than leave out Firefox.
>
> One thing little annoying thing about using the ePubReader on my XO system
> -- the directional buttons next to the screen don't work (aren't recognized)
> so I can't turn the screen into tablet mode and still be able to navigate
> page turns.   Does anyone know an easy way to map these keys into up, down,
> forward, and backward keys?   It's been a long time since I played around
> with keymapping in Linux.
>
> Stan Sokolow
>
> 
>
> On Sun, Jan 10, 2010 at 5:14 PM, rihowa...@gmail.com 
> wrote:
>>
>> Some quick observations on  F11 for the XO-1 - Build11.
>>
>> ...
>
>  
>>
>> Gnome Desktop mode:
>> In previous builds Midori was used as the web browser in gnome now Firefox
>> is being pulled in.  Is this an intentional change or a side effect of
>> changing the build system?  Midori is general considered to use less
>> resources than Firefox.
>
>
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: #9965 NORM Not Tri: calculate support for arabic numbers in the interface

[Tomeu Vizoso]

On Sat, Jan 9, 2010 at 06:36, javed khan  wrote:
> thanks for the quick replay
> i tired to register at http://bugs.sugarlabs.org but failed to some reason.
> I will try some other time to register their and then i will create a
> ticket.

Hi Javed, there was a problem with logging into bugs.sugarlabs.org but
has been solved earlier today.

Regards,

Tomeu

> On Thu, Jan 7, 2010 at 11:27 PM, Zarro Boogs per Child
>  wrote:
>>
>> #9965: calculate support for arabic numbers in the interface
>>
>> +---
>>           Reporter:  javedkhan     |       Owner:
>>               Type:  defect        |      Status:  new
>>           Priority:  normal        |   Milestone:  Not Triaged
>>          Component:  not assigned  |     Version:  not specified
>>         Resolution:                |    Keywords:
>>        Next_action:  never set     |    Verified:  0
>> Deployment_affected:                |   Blockedby:
>>           Blocking:                |
>>
>> +---
>>
>> Comment(by garycmartin):
>>
>>  Yea, should be reasonable to add. Just had a quick look at the UI code
>> and
>>  the number button strings are not currently exposed for translation. I
>>  think the bigger issue though is that the numerical output results will
>>  also need parsing/converting – I guess this is feasible as long as we are
>>  just talking simple character for character replacements. If you'd like
>> me
>>  to take a more serious look could you open a ticket on
>>  http://bugs.sugarlabs.org for the Calculate component and assign it to me
>>  (garycmartin), most activity development is upstream at Sugar Labs.
>>
>> --
>> Ticket URL: 
>> One Laptop Per Child 
>> OLPC bug tracking system
>
>
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: sugar equivalent of uname?

[Tomeu Vizoso]

On Sun, Jan 3, 2010 at 15:52, Mikus Grinbergs  wrote:
>> the portable way is to use jarabe.config.version for >=0.84
>> and assume 0.82 if that's not present.
>
> When running on an XO, how does one access 'jarabe.config.version' ?
>
> It would be nice if the sugar version could be determined from within a
> batch script.  But I looked (in >=0.84 builds) for a file by that name,
> or for a file with that content, and came up empty.

Should be something like this (don't have a XO around right now):

$ python -c "from jarabe import config; print config.version"

You can also grep the file jarabe/config.py.

Regards,

Tomeu

> Thanks for your attention,  mikus
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Some testing notes for OS10 for the XO-1

[Tomeu Vizoso]

Hi James,

happy to know you want to work on this. See this thread:

http://lists.laptop.org/pipermail/devel/2009-December/thread.html#26938

Regards,

Tomeu

On Sun, Jan 3, 2010 at 02:40, James Smith  wrote:
> All seems to work pretty well. except powermanagement. I'm running os10 
> updated today with kernel, modules, firmware from 12/28 . the default setup 
> with powerd gives the previously described problem, losing keyboard and mouse 
> upon wakeup. ohmd gives similar results. pm-suspend ends immediately prior to 
> actually suspending to ram after blanking screen and disconnecting wireless. 
> The keyboard but not the mouse is almost always lost when using pm-suspend. 
> Suspend with hal directly from the command line gives the same results:
> dbus-send --system --print-reply --dest=org.freedesktop.Hal \
>  /org/freedesktop/Hal/devices/computer \
>  org.freedesktop.Hal.Device.SystemPowerManagement.Suspend \
>  int32:0
> Why does this command not work? More importantly, why does powerd work 
> (except for the wakeup problems)? I'm guessing it doesn't use hal or dbus at 
> all. I'd like to help work on this problem but I don't know much about 
> power-management and I don't really know how to test it further. Is there a 
> place where os10 development issues are tracked or is it just this mailing 
> list?
>
> james
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: sugar equivalent of uname?

[Tomeu Vizoso]

On Sun, Jan 3, 2010 at 00:04, George Hunt  wrote:
> Thanks,
>
> the rpm solution works on at least builds 767, 802, and 1.5 FC11 backported
> to XO1.0.
>
> I'l go with that .

Good that's enough for you. For the sake of people who read the
archives, the portable way is to use jarabe.config.version for >=0.84
and assume 0.82 if that's not present.

But in most situations is better to check for capabilities instead of versions.

Regards,

Tomeu

> George
>
> On Sat, Jan 2, 2010 at 5:37 PM, Peter Robinson  wrote:
>>
>> On Sat, Jan 2, 2010 at 9:09 PM, George Hunt  wrote:
>> > I've spent all morning googling to find the documentation of how to
>> > determine which sugar build I'm running under -- without success.
>> >
>> > If someone could point me in the right direction, I'd really appreciate
>> > it.
>>
>> You can go into the control panel and its lists it there or you can do
>> 'rpm -q sugar'
>>
>> Peter
>
>
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [IAEP] Need Live CD to take to Argentina

[Tomeu Vizoso]

On Tue, Dec 29, 2009 at 11:52, Martin Langhoff
 wrote:
> On Tue, Dec 29, 2009 at 10:32 AM, Tomeu Vizoso  wrote:
>> You got some good replies already, but you may want to consider
>> contacting Gustavo Ibarra or Gonzalo Odiard (cc'ed) who are pushing
>> Sugar in Argentina.
>
> My thoughts exactly.
>
> Also -- if you're going to be in Buenos Aires, it is worthwhile to
> cross over to Uruguay. Colonia del Sacramento is a gorgeous city,
> there is a direct ferry from Buenos Aires harbour, and is of course
> Ceibal territory.
>
> I grew up in BA, and spent a lot of time in Colonia and its
> surroundings. Thoroughly recommended.

We could fund Sugar development by partnering with a travel agency and
organizing visits to OLPC schools :p

Regards,

Tomeu

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



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [IAEP] Need Live CD to take to Argentina

[Tomeu Vizoso]

On Tue, Dec 29, 2009 at 00:47, Caryl Bigenho  wrote:
> H All i...
>
> Did this ever get implemented? If so where do I find it? Are there any
> special instructions I need to make and use the live CD? Can a usb stick be
> used for file storage?
>
> http://wiki.sugarlabs.org/go/0.84/Sugar_LiveCD
>
> I would like to be able to take several copies with me to give to a tech
> person at an elementary school in Buenos Aires when I go there in
> mid-January.

You got some good replies already, but you may want to consider
contacting Gustavo Ibarra or Gonzalo Odiard (cc'ed) who are pushing
Sugar in Argentina.

Regards,

Tomeu

> Thanks,
>
> Caryl
>
> ___
> IAEP -- It's An Education Project (not a laptop project!)
> i...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Ticket 8104

[Tomeu Vizoso]

On Wed, Dec 23, 2009 at 17:33, Cecilia Abalde
 wrote:
> Hi,
> I have a question about the patch in ticket 8104.
> to which version of networkmanager was done?

Hi Cecilia,

I'm forwarding our email to the devel mailing list at OLPC because
NetworkManager is a component that belongs to the distro, not to
Sugar. In case of doubt, you are of course welcome to ask here again.

Regards,

Tomeu

> thank you
> regards
>
> Cecilia
>
> ___
> Sugar-devel mailing list
> sugar-de...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XO-3 official

[Tomeu Vizoso]

On Wed, Dec 23, 2009 at 14:57, Rafael Enrique Ortiz Guerrero
 wrote:
> Hi All.
>
> 8-ghz processor ?.

I guess it's better to rely on the info here, if you need to:

http://www.businesswire.com/portal/site/home/permalink/?ndmViewId=news_view&newsId=20091222005779&newsLang=en

Regards,

Tomeu

>
> Rafael Ortiz
>
>
>
> On Tue, Dec 22, 2009 at 4:23 PM, Benjamin M. Schwartz
>  wrote:
>> http://www.forbes.com/2009/12/22/tablet-computer-negroponte-technology-cio-network-olpc.html
>>
>> "It aims to make its tablet PC highly durable, all plastic, waterproof,
>> half the thickness of an iPhone and use less than a watt of power, despite
>> an 8-gigaherz processor. The price: an unprecedented $75."
>>
>> Well, that's cool.
>>
>> Deciphering OLPC press releases sometimes feels like I'm playing chess
>> with Picasso, and he keeps breaking the rules, and I can't tell whether
>> this is some kind of art or he's just cheating.
>>
>> --Ben
>>
>>
>> ___
>> 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
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: possible progress on XO-1 camera issues

[Tomeu Vizoso]

On Wed, Dec 23, 2009 at 02:42, James Cameron  wrote:
> On Tue, Dec 22, 2009 at 09:42:54PM -0300, Raul Gutierrez Segales wrote:
>> Is it cheating to change the screen depth? I change it to 24 bpp and now
>> cheese and totem work. Changes to /etc/X11/xorg.conf:
>
> That's odd.  We changed the screen depth quite a bit with XO-1.5
> development, I wonder if those changes accidentally reached XO-1
> development builds?
>
> (For XO-1.5 we needed the firmware, the kernel, and X to all agree on
> depth so that suspend and resume would work nicely).

My best guess right now is that something that was able to return a
16bpp surface is failing to do so in F11, but is manifesting itself as
absurd dimensions because the caller code is not checking for that
specific failure.

Regards,

Tomeu

> --
> James Cameron
> http://quozl.linux.org.au/
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: possible progress on XO-1 camera issues

[Tomeu Vizoso]

Hmm, it's a bit hard to read with so many details, can you run it
again without -v --leak-check=full --show-reachable=yes ? Those are
useful when looking for memory leaks.

I would expect that valgrind would complain when the uninitialized
values get read.

Thanks,

Tomeu

On Mon, Dec 21, 2009 at 20:13, crodas  wrote:
> Hi there,
> On Sat, 19 Dec 2009 12:06:41 +0000, Tomeu Vizoso 
> wrote:
>> On Sat, Dec 19, 2009 at 07:00, John Gilmore  wrote:
>>>> #10 0xb67fae59 in gst_xvimagesink_xvimage_put (xvimagesink=0x8364160)
>>>>     at xvimagesink.c:864
>>>>         src = {x = 134867456, y = 140758336, w = -1259457208, h = 1}
>>>>         dst = {x = 137730309, y = 3, w = 0, h = 137691184}
>>>>         result = {x = 0, y = 0, w = 322, h = 241}
>>>>         draw_border = 322
>>>>         __PRETTY_FUNCTION__ = "gst_xvimagesink_xvimage_put"
>>>>
>>>> The src.w value is in the same range as the Xlib function addresses;
>>>> -1259457208 is 0x4B11CAB8 and as can be seen from the call frame #9
>>>> the XSync function is at 0x4b0eccf7.  The other values seem
>>>> irrational.  This may be evidence that the stack has been corrupted
>>>> somewhere else, or the values not initialised.
>>>
>>> Just to rule out going too far down a blind alley...
>>>
>>> Try adding a printf of these values to the code there, rather than or
>>> in addition to using GDB.  GDB may not be 100% reliable when accessing
>>> variables from optimized code.  (I used to maintain GDB, and I worked
>>> very hard to make it never lie to you, but that precept hasn't always
>>> been followed in the intervening decade, and optimizations have also
>>> gotten a lot more complicated.)
>>>
>>> Or try compiling that code without -O and see if that changes either
>>> its behavior, or what the debugger reports.
>>
>> At this point is when I would run totem in valgrind, I can help
>> interpreting the output if it's not clear.
>>
>> # yum install valgrind
>> $ valgrind totem
> I hope it helps,
>
> http://oficina.paraguayeduca.org/~crodas/valgrind-debug.txt
>
> cheers,
>
>>
>> Regards,
>>
>> Tomeu
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

powerd or ohm?

[Tomeu Vizoso]

Hi,

I think f11 for the XO 1.5 uses ohmd but from a recent message from
Paul I think the images for the XO-1 are configured to use powerd or
at least doesn't start ohmd by default.

Steve, is there any plan on this?

Thanks,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: possible progress on XO-1 camera issues

[Tomeu Vizoso]

On Sat, Dec 19, 2009 at 07:00, John Gilmore  wrote:
>> #10 0xb67fae59 in gst_xvimagesink_xvimage_put (xvimagesink=0x8364160)
>>     at xvimagesink.c:864
>>         src = {x = 134867456, y = 140758336, w = -1259457208, h = 1}
>>         dst = {x = 137730309, y = 3, w = 0, h = 137691184}
>>         result = {x = 0, y = 0, w = 322, h = 241}
>>         draw_border = 322
>>         __PRETTY_FUNCTION__ = "gst_xvimagesink_xvimage_put"
>>
>> The src.w value is in the same range as the Xlib function addresses;
>> -1259457208 is 0x4B11CAB8 and as can be seen from the call frame #9
>> the XSync function is at 0x4b0eccf7.  The other values seem
>> irrational.  This may be evidence that the stack has been corrupted
>> somewhere else, or the values not initialised.
>
> Just to rule out going too far down a blind alley...
>
> Try adding a printf of these values to the code there, rather than or
> in addition to using GDB.  GDB may not be 100% reliable when accessing
> variables from optimized code.  (I used to maintain GDB, and I worked
> very hard to make it never lie to you, but that precept hasn't always
> been followed in the intervening decade, and optimizations have also
> gotten a lot more complicated.)
>
> Or try compiling that code without -O and see if that changes either
> its behavior, or what the debugger reports.

At this point is when I would run totem in valgrind, I can help
interpreting the output if it's not clear.

# yum install valgrind
$ valgrind totem

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel