Re: [Sugar-devel] Proposal of dotted activity version number

[Simon Schampijer]

On 10/22/2010 07:00 PM, Simon Schampijer wrote:

On 10/07/2010 06:39 PM, Daniel Drake wrote:

On 4 October 2010 15:27, Gonzalo Odiard wrote:

What do others think about this approach? Packagers?


A clearer way to discuss this would be to just send a patch. That way
there is no doubt over the details of the implementation that you are
proposing.

Daniel


Hi Daniel,

that is what the current implementation looks like:

http://bugs.sugarlabs.org/attachment/ticket/2425/normalized_version.patch

Hope this helps,
Simon


I have been giving the patches another go and made some smaller fixes 
for error handling. I have tested them as well to make sure there are no 
regressions. I give them my ok.


http://bugs.sugarlabs.org/attachment/ticket/2425/0001-Adopt-to-new-numbering-scheme-2425.patch

http://bugs.sugarlabs.org/attachment/ticket/2425/0001-Add-new-numbering-scheme-2425.patch

Comments?

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

Re: [Sugar-devel] Proposal of dotted activity version number

[C. Scott Ananian]

On Thu, Oct 28, 2010 at 3:58 PM, Simon Schampijer  wrote:
> I have been giving the patches another go and made some smaller fixes for
> error handling. I have tested them as well to make sure there are no
> regressions. I give them my ok.
>
> http://bugs.sugarlabs.org/attachment/ticket/2425/0001-Adopt-to-new-numbering-scheme-2425.patch
>
> http://bugs.sugarlabs.org/attachment/ticket/2425/0001-Add-new-numbering-scheme-2425.patch

Where's the documentation?  Does this code correspond to a concrete
proposal?  Or do we expect contributors to reverse engineer the
version scheme from pydoc sugar.bundle.bundleversion?
  --scott

-- 
                         ( http://cscott.net/ )
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [RELEASE] sugar-presence-service-0.84.3

[Simon Schampijer]

== Source ==

http://download.sugarlabs.org/sources/sucrose/glucose/sugar-presence-service/sugar-presence-service-0.84.3.tar.bz2

== News ==

* Release 0.84.3 (Simon Schampijer)
* Remove shared activity from the neighborhood view when no members left #10308 
(Simon Schampijer)
* Deal with unicode nick names #889 (moved patch from rpm into reprository) 
(Simon Schampijer)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [RELEASE] sugar-0.84.24

[Simon Schampijer]

== Source ==

http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.84.24.tar.bz2

== News ==

* Release 0.84.24 (Simon Schampijer)
* Disable start option for entries that can't be opened #8733 (Mukul Gupta)
* Cleanup temporary files on startup #10301 (Simon Schampijer)
* Adjust Sucrose version number (Simon Schampijer)
* restore sugar-launch by bundle id substring, fixes #897 (James Cameron)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [RELEASE] sugar-artwork-0.84.4

[Simon Schampijer]

== Source ==

http://download.sugarlabs.org/sources/sucrose/glucose/sugar-artwork/sugar-artwork-0.84.4.tar.bz2

== News ==

* Release 0.84.4 (Simon Schampijer)
* New go-home icon, needed by Browse (Gary C Martin)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[Martin Dengler]

On Wed, Oct 27, 2010 at 11:15:01PM +0530, Anurag Chowdhury wrote:
> I carried out the same benchmark test, which I earlier conducted on an
> XO-1.5 , on a X0-1 .

Please tell us what the test is/was.  How many times did you run it?
How did you make sure nothing else interfered with the system cpu and
memory while you were running it?

> And I have attached the log files obtained in both the cases. [...]
> the consecutive times taken for the rendering of the frames on the
> XO-1 were much larger as compared to that on a XO-1.5.

I compared the means and standard deviations for the numbers in the
lines having "seconds taken to update frame" and I don't understand
how you came to that "very much larger" conclusion:

$ (~/src/stddev.py < ~/tmp/xo15  ; ~/src/stddev.py < ~/tmp/xo10) | \
~/tmp/compare_means.py
for 'seconds taken to update frame':
XO 1.0 mean was 0.021002, XO 1.5 mean was 0.014994
...change in speed was -28.605292%

You can find the data from your logs (I had to remove some numbers
that were split across the stderr output that was mixed in with your
logging) and the scripts mentioned at:

http://www.martindengler.com/tmp/sl.o-2080

Please, can you do more than wave your hands to help us understand the
effect of what you've done?  You want to affect a key part of the
system for a lot of people.  It's a bit frustrating to hear talk of
"very much larger" speed without actually knowing how and what you're
measuring.

> Regards,
> --Anurag

Martin


pgpR6fHNtvgKQ.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Olpc Os builder error

[javed khan]

Hi All

when running the olpc-os-builder i got the following (i am using fedora 11
in virtual box)

  Installing: totem-mozplugin  # [605/605]

authconfig: Authentication module /lib/security/pam_fprintd.so is missing.
Authentication process might not work correctly.
authconfig: Authentication module /lib/security/pam_pkcs11.so is missing.
Authentication process might not work correctly.
Failed to write selinux configuration.
Removing password for user root.
passwd: Success
error reading information on service exim: No such file or directory
error reading information on service livesys: No such file or directory
error reading information on service livesys-late: No such file or directory
error reading information on service portreserve: No such file or directory
Executing code generated by kspost:base/kspost.10.core.inc...
Removing password for user olpc.
passwd: Success
Executing code generated by kspost:base/kspost.10.strip_locale.sh...
Executing code generated by kspost:base/kspost.10.version_number.sh...
Executing code generated by kspost:sugar/kspost.50.gconf.inc...
Executing code generated by kspost:sugar/kspost.50.misc.inc...
Executing code generated by kspost:xo1/kspost.50.xo1-tweaks.inc...
Executing code generated by kspost:sugar/kspost.51.favoritesview.sh...
Executing code generated by kspost:x11/kspost.60.misc.inc...
Executing code generated by kspost:x11/kspost.99.gconf-normalize.inc...
e2fsck 1.41.4 (27-Jan-2009)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
os28: 29649/131072 files (1.4% non-contiguous), 191200/524288 blocks
e2fsck 1.41.4 (27-Jan-2009)
Backing up journal inode block information.

Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

os28: * FILE SYSTEM WAS MODIFIED *
os28: 29649/49152 files (1.5% non-contiguous), 185802/185802 blocks
/usr/lib/python2.6/site-packages/imgcreate/errors.py:40: DeprecationWarning:
BaseException.message has been deprecated as of Python 2.6
  return str(self.message)
ERROR:root:Error creating Live CD : fsck returned an error!
 * Caught error, cleanup and then bail out.
 * Running part cleanup base cleanup.50.cleanup.sh...
 * Running part cleanup buildnr_from_file cleanup.50.write_buildnr.sh...
ERROR: Failure in BuildStage: module base, part build.40.imagecreate.py,
error code 1

Help me guys

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

Re: [Sugar-devel] an ardent proposal to bring *LOVE* back into Sugar Labs

[Walter Bender]

Would someone please translate this message into Spanish for the Sur
list? Gracias.

---

Further comment on Adam's ardent proposal to bring *LOVE* back into Sugar Labs:

On Thu, Oct 28, 2010 at 1:42 AM, Holt  wrote:
[snip]
> Yes, I'm paraphrasing, Walter please speak for yourself :)

While the deadlines for applying to be a candidate and for receiving a
ballot had been posted to the wiki and mailing lists, there has been
some confusion about the dates of the election itself. The Oversight
Board had been under the impression that it was to be held in October.
The Election Committee was planning on holding it in November.

* Arguably, there has been inadequate communication to the community
about many aspects of the election and certainly there has not been an
aggressive get-out-the-vote campaign.
* Further, we have one additional opening on the Oversight Board due
to Tomeu's departure.

For both of these reasons, the Oversight Board recommends extending
the period of registering as a candidate and registering as a member
(in order to be eligible to vote in the election) until then end of
the day (EST), 1 November 2010. The Election Committee has agreed to
these changes conditional on (1) we also delay the election itself for
two weeks in order to provide sufficient time to prepare the ballots;
and (2) there is consensus among the community regarding these
changes.

To sum up, unless there is push-back from the community:

* The election will be held from 14–20 November 2010. Ballots will be
sent by email to all Sugar Labs members.
* To be eligible for voting in this election, you must become a member
of Sugar Labs by 1 November 2010. Send email to memb...@sugarlabs.org
in order to added to our membership list.
* You may still 'throw your hat into the ring' by adding your name to
the candidates list in the wiki
[http://wiki.sugarlabs.org/go/Oversight_Board/2010-2011-candidates] or
by sending email to me or Luke (chair of the Election Committee) by 1
November 2010.

[snip]

Make your voice heard: become a member; become a candidate; vote.

-walter

---
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Research: 0.84 Launcher Cost

[Dipankar Patro]

Hello James,

I was going through the discussion over the bug #2080 handled currently by
Anurag.

I too was thinking of replacing the animation algo, which currently is sine
function.
I was having some questions in mind after looking at your research.
"When launcher is disabled, the time saving is more, as compared to SVG
complexity."

If we are not for removing animation, then why not use a simple integer
based algorithm instead of a floating based sine algorithm. In terms of
graphics, integer based algorithms (Bresenham, Mid-point, etc) work faster
than floating point based.

If we can use a 'Busy-Cursor' then its fine.
But if we still want to continue with the animation, why not change the
algorithm for the animation that is done?

Regards,
Dipankar

On Thu, Oct 28, 2010 at 9:04 AM, James Cameron  wrote:

> Earlier in the context of SL#2080 patch review, I had said "the
> launcher is stealing CPU cycles from the startup of the activity, the
> task run queue shows this during a launch.  I wonder if activities
> might start up faster if there was no launcher, just a busy cursor."
>
> Looks like activities would start faster; between one and four seconds,
> mostly depending on the activity, and slightly depending on the icon
> complexity.
>
> Details below.
>
> --
>
> Research: will activities start faster if there is no launcher?
>
> Method: using an XO-1, freshly installed with Sugar 0.84.22, as part
> of OLPC OS 10.1.2 build os852, test the startup time of three
> activities (Memorize, Moon and Chat), remove the launcher, retest,
> subtract.
>
> The launcher is implemented by source file launcher.py in
> /usr/lib/python2.6/site-packages/jarabe/view/ ... the modification
> made is attached as a patch.
>
> The times were captured with a stopwatch.  The timing began when "Start"
> was selected from the list view, and ended once the activity had
> completed display of the UI.
>
> Result:
>
> a.  unmodified launcher.py
>
> Memorize-34 9.43s, 9.56s, 9.51s
> Moon-11 11.58s, 11.60s, 11.65s
> Chat-65 6.65s, 6.54s, 6.59s
>
> b.  modified launcher.py (black background, no animation),
>
> Memorize-34 7.60s, 7.63s, 7.60s
> Moon-11 7.78s, 7.78s, 7.95s
> Chat-65 5.04s, 4.93s, 4.88s
>
> c.  calculated cost of launcher
>
> Memorize-34 1.89s
> Moon-11 3.73s
> Chat-65 1.64s
>
> Diagnosis: removing the launcher animation saved between one and four
> seconds of startup time.  The saving was greatest for the Moon activity.
>
> --
>
> Research: determine if the SVG icon for the Moon activity contributes
> to the delay.
>
> Method: swap the icons, restart Sugar, retest only Chat activity with
> Moon icon.
>
> Result:
>
> a.  unmodified launcher.py
>
> Chat-65 7.83s, 7.59s, 7.62s
>
> b.  modified launcher.py (black background, no animation),
>
> Chat-65 4.99s, 4.87s, 4.90s
>
> c.  calculated cost of launcher
>
> Chat-65 2.75s (greater than previous)
>
> d.  calculated cost of moon icon over chat icon
>
> Chat-65 1.09s
>
> Diagnosis: the degree of saving has a little to do with the SVG icon
> complexity.  The degree of saving has much to do with the mix of
> operations performed by the activity during startup.
>
> --
>
> So, between 23 and 92 wasted days of looking at the launcher across
> two million laptops.  Good time to think and plan, kids.
>
> --
> James Cameron
> http://quozl.linux.org.au/
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [DESIGN] Share 3G connection

[Martin Abente]

Hello amigos,

I have started working on the Dextrose TODO (deployment's wishlist) [1], and
the "share 3G connection" item is a popular and beneficial feature to be
implemented on dextrose with high hopes for upstreaming :). I invite
everyone interested in this feature [2] to give me his feedback, so I can
soon start the implementation stage.

Saludos,
Martin (tch) Abente

1. http://wiki.sugarlabs.org/go/Dextrose/TODO
2. http://wiki.sugarlabs.org/go/Features/3G_Support/Share
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] an ardent proposal to bring *LOVE* back into Sugar Labs

[Caroline Meeks]

Great idea! I can host parties at my new T Accessible house in Arlington if
that helps.

On Thu, Oct 28, 2010 at 1:42 AM, Holt  wrote:

> (1) In-person meetings in between Bostonian
> http://wiki.sugarlabs.org/go/Oversight_Board members and Sugar/OLPC Local
> Lab Boston, quasimonthly.  Community is neither a buzzword, nor a fantasy,
> with Sugar Labs' only 4 active board members now living in Boston today.
>  Community is the 132 volunteer members of
> http://lists.laptop.org/listinfo/olpc_boston who want to particitepate in
> Sugar/OLPC but our promise withers, when accomplished teachers and
> volunteers willing to pull their weight, simply don't -- as too many of us
> are unintentionally hiding behind our IRC koolaid, yep myself guilty as
> charged :)  So it's time to throw a few parties.  And get over a couple of
> our antisocial hangups, at all levels of our organizing.  As our 130+ person
> high-energy http://olpcSF.org/summit this past weekend proved far beyond a
> shadow of a doubt.  As SF's own amazing hackerspace (
> http://noisebridge.net) reminded us all late into the night before.
>  Sustainable volunteerism == bringing people together in a physical space,
> even in Boston!  Like others have already done globally here:
> http://wiki.sugarlabs.org/go/Local_Labs .  I made this happen last week in
> San Francisco for almost 10 valiant-but-poor-volunteers, by lining them up
> with other more well-off volunteers, using peer2peer donations instead of
> bureaucratic budget molasses.  Next year we can do this for 20 volunteers
> instead of 10, if we bring ourselves together.  Meantime: I, Walter, Bernie
> and CJB (etc) can do our Boston and Global community a gigantic favor if we
> Get Out More right here at home :)  Learning (i.e. healthy) communities live
> or die based on the Rhythm their members create -- physical bonds feed
> online bonds and vice versa.  Let us begin now.  Progress beckons: Walter,
> Bernie & I will meet all together Thurs (tomorrow) for the first time in
> about a year, to discuss our breakthrough community catapult in SF, even
> before SF's Mayor issued his proclamation:
> http://blog.laptop.org/2010/10/22/october-23-is-olpc-day-in-sf/
>
> (2) Democracy does NOT grow on trees, or in the back of stale legalistic
> texts.  It is the worst form of governance, if we believe Churchill, and
> accordingly I and Sugar Labs' Oversight Board have been negligent in not
> getting folks fired up about the current election process, failing to
> bringing strong awareness around precise key election dates, even
> understanding it ourselves!  I personally consider both to be constitutional
> duty: the cleanest elections happen when we enable get-out-the-vote
> mobilizations of all kind, enabling expression and reflection AKA learning.
>  Disturbing evidence I've uncovered in the past 24hrs is that board members
> themselves I've spoken to privately remain confused about
> nomination/election dates, confused about duration of terms, confused about
> lame duck/impeachment/replacement/re-invitation procedures for the several
> absentee board members already gone.  Pity our rank+file volunteer just
> trying to get some work done, or get fired up about our so-sweet
> possibilities!  Now drowning in this unadvertised/undecided election
> machinery-- No more!  I suggest we start with Informed Consent, meaning
> strong advance awareness of all deadlines and voting times -- that we
> hopefully all together agree to publicize very directly off:
>
>http://google.com/search?q=sugar+labs+election
>
> (3) One specific proposal around strengthening awareness of Sugar Labs'
> election clearly, widely and far more passionately, with all dates clearly
> layed out, right off the uniquely memorable page above -- was advanced by
> Luke Faraone (administering the election) earlier this evening.  Walter
> Bender says he would agree to support Luke's proposal to extend registration
> (welcoming quality candidates & eligible voters both) until something like
> Nov 10th 23:59 EST, if the election itself was delayed until approximately
> Nov 14-27, IF our broad community and board agrees this will all deepen our
> Participative process, strengthen who we are, illustrate our shared
> sacrifice -- and most importantly: waken our family and friends to our
> cause.  Yes, I'm paraphrasing, Walter please speak for yourself :)   In any
> case, for me clearness-in-democracy is non-negotiable, as is our blessed
> responsibility to stay young, Meaningfully open (Lovable too please!) while
> at last growing up as a 2008-2012 organization, as this election will now
> decide.  I support Luke's above thoughtful proposal and hope others will
> too, enhancing it ideally if you can, but most important all speaking our
> consciences towards deciding quickly and carefully, however we proceed.
>
> (4) First kill all the lawyers (but please Shakespeare DO read our "SFC
> by-laws" at
> http://wiki.sugarlabs.org/go/Sugar_Labs/SFC-SugarLabs

Re: [Sugar-devel] [IAEP] an ardent proposal to bring *LOVE* back into Sugar Labs

[Holt]

Let's do it, conveniently right by Alewife's Red Line subway stop:

I will help cater -- thanks so much for your devotion to the cause Caroline.


On 10/28/2010 11:30 AM, Caroline Meeks wrote:
Great idea! I can host parties at my new T Accessible house in 
Arlington if that helps.


On Thu, Oct 28, 2010 at 1:42 AM, Holt > wrote:


(1) In-person meetings in between Bostonian
http://wiki.sugarlabs.org/go/Oversight_Board members and
Sugar/OLPC Local Lab Boston, quasimonthly.  Community is neither a
buzzword, nor a fantasy, with Sugar Labs' only 4 active board
members now living in Boston today.  Community is the 132
volunteer members of http://lists.laptop.org/listinfo/olpc_boston
who want to particitepate in Sugar/OLPC but our promise withers,
when accomplished teachers and volunteers willing to pull their
weight, simply don't -- as too many of us are unintentionally
hiding behind our IRC koolaid, yep myself guilty as charged :)  So
it's time to throw a few parties.  And get over a couple of our
antisocial hangups, at all levels of our organizing.  As our 130+
person high-energy http://olpcSF.org/summit this past weekend
proved far beyond a shadow of a doubt.  As SF's own amazing
hackerspace (http://noisebridge.net) reminded us all late into the
night before.  Sustainable volunteerism == bringing people
together in a physical space, even in Boston!  Like others have
already done globally here:
http://wiki.sugarlabs.org/go/Local_Labs .  I made this happen last
week in San Francisco for almost 10 valiant-but-poor-volunteers,
by lining them up with other more well-off volunteers, using
peer2peer donations instead of bureaucratic budget molasses.  Next
year we can do this for 20 volunteers instead of 10, if we bring
ourselves together.  Meantime: I, Walter, Bernie and CJB (etc) can
do our Boston and Global community a gigantic favor if we Get Out
More right here at home :)  Learning (i.e. healthy) communities
live or die based on the Rhythm their members create -- physical
bonds feed online bonds and vice versa.  Let us begin now.
 Progress beckons: Walter, Bernie & I will meet all together Thurs
(tomorrow) for the first time in about a year, to discuss our
breakthrough community catapult in SF, even before SF's Mayor
issued his proclamation:
http://blog.laptop.org/2010/10/22/october-23-is-olpc-day-in-sf/

(2) Democracy does NOT grow on trees, or in the back of stale
legalistic texts.  It is the worst form of governance, if we
believe Churchill, and accordingly I and Sugar Labs' Oversight
Board have been negligent in not getting folks fired up about the
current election process, failing to bringing strong awareness
around precise key election dates, even understanding it
ourselves!  I personally consider both to be constitutional duty:
the cleanest elections happen when we enable get-out-the-vote
mobilizations of all kind, enabling expression and reflection AKA
learning.  Disturbing evidence I've uncovered in the past 24hrs is
that board members themselves I've spoken to privately remain
confused about nomination/election dates, confused about duration
of terms, confused about lame
duck/impeachment/replacement/re-invitation procedures for the
several absentee board members already gone.  Pity our rank+file
volunteer just trying to get some work done, or get fired up about
our so-sweet possibilities!  Now drowning in this
unadvertised/undecided election machinery-- No more!  I suggest we
start with Informed Consent, meaning strong advance awareness of
all deadlines and voting times -- that we hopefully all together
agree to publicize very directly off:

http://google.com/search?q=sugar+labs+election

(3) One specific proposal around strengthening awareness of Sugar
Labs' election clearly, widely and far more passionately, with all
dates clearly layed out, right off the uniquely memorable page
above -- was advanced by Luke Faraone (administering the election)
earlier this evening.  Walter Bender says he would agree to
support Luke's proposal to extend registration (welcoming quality
candidates & eligible voters both) until something like Nov 10th
23:59 EST, if the election itself was delayed until approximately
Nov 14-27, IF our broad community and board agrees this will all
deepen our Participative process, strengthen who we are,
illustrate our shared sacrifice -- and most importantly: waken our
family and friends to our cause.  Yes, I'm paraphrasing, Walter
please speak for yourself :)   In any case, for me
clearness-in-democracy is non-negotiable, as is our blessed
responsibility to stay young, Meaningfully open (Lovable too
please!) while at last growing up as a 2008-2012 organization, as
this election 

[Sugar-devel] [ANNOUNCEMENT] Roadmap to OLPC 10.1.3 release

[Simon Schampijer]

Hi,

I am happy to announce the following:

=About=
There will be another Fedora 11 / Sugar 0.84 based release for the XO-1, 
the XO-1.5 and the XO-1.5 HS (High School) laptop. This will be a bug 
fix release that incorporates feedback from the field and from testers.


=Schedule=
The release is scheduled for the 15th of December 2010, a release 
candidate will be available the 1. of December 2010.


=Builds=
The current builds for the XO-1 and XO-1.5 can be found at [1], new 
builds will be announced on the lists. Changes are as well listed in the 
announce file in the appropriate directory (e.g. see [2] for the current 
351 build).


=Testing=
For feedback please use the olpc bug tracker [3]. The builds have debug 
logs enabled during the development process (Sugar, activities and the 
telepathy components), please attach them to the tickets accordingly.


=Team=
The OLPC Association team is providing the framework for this effort. 
Martin is the link to the field, Sam our QA engineer, the activity 
improvements are managed by Gonzalo and Simon is doing Sugar work and 
builds.


=Known issues=
Currently doing an 'olpc-update' to update to the 10.1.3 build is not 
yet possible, but we will have that fixed soon.


Regards,
   Simon

[1] http://build.laptop.org/10.1.3/
[2] http://build.laptop.org/10.1.3/xo-1/os351/announce
[3] http://dev.laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[Anurag Chowdhury]

I have attached the pulsingicon.py file in which I placed the
benchmark script to test the time taken by update function everytime
it is called.
I used the time.time() function to measure the time taken to process
the update step.

And If you may compare the odd steps of both logs i.e the numbers in
the lines having "seconds taken to update frame" appearing at the odd
steps
(3rd ,5th ,7th.entries) and similarily compare  the even steps
you may find the average time taken on XO-1.5 to run the update
function was nearly 50% faster.



On Thu, Oct 28, 2010 at 3:01 PM, Martin Dengler
 wrote:
>
> On Wed, Oct 27, 2010 at 11:15:01PM +0530, Anurag Chowdhury wrote:
> > I carried out the same benchmark test, which I earlier conducted on an
> > XO-1.5 , on a X0-1 .
>
> Please tell us what the test is/was.  How many times did you run it?
> How did you make sure nothing else interfered with the system cpu and
> memory while you were running it?
>
> > And I have attached the log files obtained in both the cases. [...]
> > the consecutive times taken for the rendering of the frames on the
> > XO-1 were much larger as compared to that on a XO-1.5.
>
> I compared the means and standard deviations for the numbers in the
> lines having "seconds taken to update frame" and I don't understand
> how you came to that "very much larger" conclusion:
>
> $ (~/src/stddev.py < ~/tmp/xo15  ; ~/src/stddev.py < ~/tmp/xo10) | \
> ~/tmp/compare_means.py
> for 'seconds taken to update frame':
> XO 1.0 mean was 0.021002, XO 1.5 mean was 0.014994
> ...change in speed was -28.605292%
>
> You can find the data from your logs (I had to remove some numbers
> that were split across the stderr output that was mixed in with your
> logging) and the scripts mentioned at:
>
> http://www.martindengler.com/tmp/sl.o-2080
>
> Please, can you do more than wave your hands to help us understand the
> effect of what you've done?  You want to affect a key part of the
> system for a lot of people.  It's a bit frustrating to hear talk of
> "very much larger" speed without actually knowing how and what you're
> measuring.
>
> > Regards,
> > --Anurag
>
> Martin


pulsingicon.py
Description: Binary data
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Write: changing the default insert image mode

[Gonzalo Odiard]

I was testing changing the default mode inserting a image in Write
from floating to in-place.
It enable insert a image inside a table, and I think is more usable.
Is the default mode in Abiword too.
If the user want insert a floating image, i added a checkbox to the
palette of the insert image button.
Can anybody check with users and provide feedback?

Gonzalo

To test it, you can apply the following patch:

>From 7a5a40818e0fdc73dc7ac5b89ade1b278f300f46 Mon Sep 17 00:00:00 2001
From: Gonzalo Odiard 
Date: Thu, 28 Oct 2010 12:27:21 -0300
Subject: [PATCH] Write: Change the default method of insert images to
in place instead of floating
 and add a checkbox to enable the user to select the method

---
 toolbar.py |   16 +++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/toolbar.py b/toolbar.py
index 701d8be..d84abf7 100644
--- a/toolbar.py
+++ b/toolbar.py
@@ -253,15 +253,29 @@ class InsertToolbar(gtk.Toolbar):
 self._image_id = image.connect('clicked', self._image_cb)
 self.insert(image, -1)

+palette = image.get_palette()
+content_box = gtk.VBox()
+palette.set_content(content_box)
+image_floating_checkbutton = gtk.CheckButton(_('Floating'))
+image_floating_checkbutton.connect('toggled',
+self._image_floating_checkbutton_toggled_cb)
+content_box.pack_start(image_floating_checkbutton)
+content_box.show_all()
+self.floating_image = False
+
 self.show_all()

 self._abiword_canvas.connect('table-state', self._isTable_cb)
 #self._abiword_canvas.connect('image-selected',
self._image_selected_cb)

+def _image_floating_checkbutton_toggled_cb(self, checkbutton):
+logging.error('Floating image is Active: %s', checkbutton.get_active())
+self.floating_image = checkbutton.get_active()
+
 def _image_cb(self, button):
 def cb(object):
 logging.debug('ObjectChooser: %r' % object)
-self._abiword_canvas.insert_image(object.file_path, True)
+self._abiword_canvas.insert_image(object.file_path,
self.floating_image)
 chooser.pick(parent=self._abiword_canvas.get_toplevel(),
what=chooser.IMAGE, cb=cb)

 def _table_cb(self, abi, rows, cols):
-- 
1.7.2.3
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] an ardent proposal to bring *LOVE* back into Sugar Labs

[Holt]

Walter right next to me here at OLPC in Cambridge, MA wants to clarify 
the dates below before they are republished, getting them closer to 
Luke's original Nov 10 and Nov 14-27 suggestions as he and Luke see fit 
-- thanks for holding the presses etc until Walter finds a computer and 
clarifies :)



On 10/28/2010 8:24 AM, Walter Bender wrote:

Would someone please translate this message into Spanish for the Sur
list? Gracias.

---

Further comment on Adam's ardent proposal to bring *LOVE* back into Sugar Labs:

On Thu, Oct 28, 2010 at 1:42 AM, Holt  wrote:
[snip]

Yes, I'm paraphrasing, Walter please speak for yourself :)

While the deadlines for applying to be a candidate and for receiving a
ballot had been posted to the wiki and mailing lists, there has been
some confusion about the dates of the election itself. The Oversight
Board had been under the impression that it was to be held in October.
The Election Committee was planning on holding it in November.

* Arguably, there has been inadequate communication to the community
about many aspects of the election and certainly there has not been an
aggressive get-out-the-vote campaign.
* Further, we have one additional opening on the Oversight Board due
to Tomeu's departure.

For both of these reasons, the Oversight Board recommends extending
the period of registering as a candidate and registering as a member
(in order to be eligible to vote in the election) until then end of
the day (EST), 1 November 2010. The Election Committee has agreed to
these changes conditional on (1) we also delay the election itself for
two weeks in order to provide sufficient time to prepare the ballots;
and (2) there is consensus among the community regarding these
changes.

To sum up, unless there is push-back from the community:

* The election will be held from 14–20 November 2010. Ballots will be
sent by email to all Sugar Labs members.
* To be eligible for voting in this election, you must become a member
of Sugar Labs by 1 November 2010. Send email to memb...@sugarlabs.org
in order to added to our membership list.
* You may still 'throw your hat into the ring' by adding your name to
the candidates list in the wiki
[http://wiki.sugarlabs.org/go/Oversight_Board/2010-2011-candidates] or
by sending email to me or Luke (chair of the Election Committee) by 1
November 2010.

[snip]

Make your voice heard: become a member; become a candidate; vote.

-walter

---
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
IAEP -- It's An Education Project (not a laptop project!)
i...@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

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

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[Martin Dengler]

I'm sorry to harp on this, but I hope you can see it actually takes
quite some effort to communicate this stuff well...

On Thu, Oct 28, 2010 at 09:27:18PM +0530, Anurag Chowdhury wrote:
> I have attached the pulsingicon.py file

Thanks - very useful to understand what you're timing.

> in which I placed the benchmark script

which benchmark script?!  Another file you should include.

 to test the time taken by update function everytime
> it is called.
> I used the time.time() function to measure the time taken to process
> the update step.

There is a better way: use cProfile and gprof2dot.py.  You will get
graphs (and of course the raw data) like this:

http://www.martindengler.com/tmp/sl.o-2080/pulsingicon.py-stats-graph.png

...and then you could show us before and after your change on the XO
1.0 and XO 1.5.  Normally the relative time is most interesting, but
since we are also interested in the absolute running time I patched
gprof2dot.py to show that, and you can see the total time (in seconds)
consumed by each graph node and its subtree as the second-to-last
number shown in the node.

You can find the pulsingicon.py changes and the instructions I used to
make that in:
http://www.martindengler.com/tmp/sl.o-2080/README.txt

> And If you may compare the odd steps of both logs i.e the numbers in
> the lines having "seconds taken to update frame" appearing at the odd
> steps
> (3rd ,5th ,7th.entries) and similarily compare  the even steps
> you may find the average time taken on XO-1.5 to run the update
> function was nearly 50% faster.

Odd steps?  Even steps?  Sounds scary.  Why?

Martin


pgpZ0cw23UFYi.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[Gonzalo Odiard]

I think the problem is the code is rendering the svg icon every time
the color is changed.
There are not cache or cairo operation used to avoid this.

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

[Sugar-devel] [PATCH v2 Paint Activity] Fixed aspect ratio mode for Shape tools (OLPC#3705)

[Ayush Goyal]

Added fixed aspect ratio mode for line,ellipse and rectangle tool using Shift
key as mask or using a keep aspect ratio checkbox from palette.This allows
drawing of straight lines & 45 degree lines from line tool,circle from
ellipse tool and square from rectangle tool

Signed-off-by: Ayush Goyal 
---
 Area.py|   40 +++-
 toolbox.py |   11 +++
 2 files changed, 50 insertions(+), 1 deletions(-)
 v1->v2:Added checkbox for keep aspect in shape menu palette

diff --git a/Area.py b/Area.py
index ba06758..db84e65 100644
--- a/Area.py
+++ b/Area.py
@@ -173,6 +173,10 @@ class Area(gtk.DrawingArea):
 self.last = []
 self.rainbow_counter = 0
 self.keep_aspect_ratio = False
+self.keep_ratio = {
+'line': False,
+'rectangle': False,
+'ellipse': False}
 
 self.font = pango.FontDescription('Sans 9')
 self._set_selection_bounds(0, 0, 0, 0)
@@ -411,6 +415,13 @@ class Area(gtk.DrawingArea):
 self.x_cursor, self.y_cursor = int(x), int(y)
 
 coords = int(x), int(y)
+if self.tool['name'] in ['rectangle', 'ellipse', 'line']:
+if (state & gtk.gdk.SHIFT_MASK) or \
+self.keep_ratio[self.tool['name']]:
+if self.tool['name'] in ['rectangle', 'ellipse']:
+coords = self._keep_selection_ratio(coords)
+elif self.tool['name'] == 'line':
+coords = self._keep_line_ratio(coords)
 
 if state & gtk.gdk.BUTTON1_MASK and self.pixmap != None:
 if self.tool['name'] == 'pencil':
@@ -530,11 +541,19 @@ class Area(gtk.DrawingArea):
 @param  event -- GdkEvent
 """
 coords = int(event.x), int(event.y)
+if self.tool['name'] in ['rectangle', 'ellipse', 'line']:
+if (event.state & gtk.gdk.SHIFT_MASK) or \
+self.keep_ratio[self.tool['name']]:
+if self.tool['name'] in ['rectangle', 'ellipse']:
+coords = self._keep_selection_ratio(coords)
+if self.tool['name'] == 'line':
+coords = self._keep_line_ratio(coords)
+
 width, height = self.window.get_size()
 if self.desenha or self.sel_get_out:
 if self.tool['name'] == 'line':
 self.pixmap.draw_line(self.gc_line, self.oldx, self.oldy,
-int(event.x), int(event.y))
+coords[0], coords[1])
 widget.queue_draw()
 self.enableUndo(widget)
 
@@ -1411,3 +1430,22 @@ class Area(gtk.DrawingArea):
 
 return (self.oldx + sign(dx) * size,
 self.oldy + sign(dy) * size)
+
+def _keep_line_ratio(self, coords):
+
+def sign(x):
+return x and x / abs(x) or 0
+
+dx = int(coords[0]) - self.oldx
+dy = int(coords[1]) - self.oldy
+size = max(abs(dx), abs(dy))
+
+if abs(dx) > 0.5 * size and abs(dy) > 0.5 * size:
+return (self.oldx + sign(dx) * size,
+   self.oldy + sign(dy) * size)
+elif abs(dx) < 0.5 * size and abs(dy) > 0.5 * size:
+return (self.oldx,
+   self.oldy + sign(dy) * size)
+elif abs(dx) > 0.5 * size and abs(dy) < 0.5 * size:
+return (self.oldx + sign(dx) * size,
+   self.oldy)
diff --git a/toolbox.py b/toolbox.py
index 3c8ab92..e8569c8 100644
--- a/toolbox.py
+++ b/toolbox.py
@@ -855,6 +855,10 @@ class ShapesToolbar(gtk.Toolbar):
 tool['fill'] = checkbutton.get_active()
 self.set_tool(tool=tool)
 
+def _on_keep_aspect_checkbutton_toggled(self, checkbutton, tool):
+self._activity.area.keep_ratio[tool['name']] = checkbutton.get_active()
+self.set_tool(tool=tool)
+
 def _configure_palette_shape_ellipse(self):
 logging.debug('Creating palette to shape ellipse')
 self._create_simple_palette(self._shape_ellipse, self._SHAPE_ELLIPSE)
@@ -960,6 +964,13 @@ class ShapesToolbar(gtk.Toolbar):
 palette.content_box = gtk.VBox()
 palette.set_content(palette.content_box)
 
+if tool['name'] in ['rectangle', 'ellipse', 'line']:
+keep_aspect_checkbutton = gtk.CheckButton(_('Keep Aspect'))
+ratio = self._activity.area.keep_ratio[tool['name']]
+keep_aspect_checkbutton.set_active(ratio)
+keep_aspect_checkbutton.connect('toggled',
+self._on_keep_aspect_checkbutton_toggled, tool)
+palette.content_box.pack_start(keep_aspect_checkbutton)
 # Fill option
 if not line_size_only:
 fill_checkbutton = gtk.CheckButton(_('Fill'))
-- 
1.7.1

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

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[Anurag Chowdhury]

Certainly that seems to me as a possible reason behind this issue ,
but in the present state we need to decide exactly on what future we
want for this pulsing icon i.e. keep it , improve it or replace it.

On Fri, Oct 29, 2010 at 12:14 AM, Gonzalo Odiard  wrote:
> I think the problem is the code is rendering the svg icon every time
> the color is changed.
> There are not cache or cairo operation used to avoid this.
>
> Gonzalo
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[Anurag Chowdhury]

On Thu, Oct 28, 2010 at 11:12 PM, Martin Dengler
 wrote:
> I'm sorry to harp on this, but I hope you can see it actually takes
> quite some effort to communicate this stuff well...
>
> On Thu, Oct 28, 2010 at 09:27:18PM +0530, Anurag Chowdhury wrote:
>> I have attached the pulsingicon.py file
>
> Thanks - very useful to understand what you're timing.
>
>> in which I placed the benchmark script
>
> which benchmark script?!  Another file you should include.
>
No , Its just my lingo . I meant no other file and benchmark script
only meant the time.time() function used to get time taken to update
frame.
>  to test the time taken by update function everytime
>> it is called.
>> I used the time.time() function to measure the time taken to process
>> the update step.
>
> There is a better way: use cProfile and gprof2dot.py.  You will get
> graphs (and of course the raw data) like this:
>
Thanks and I appreciate the pointers., but I did it this way as I
wanted it simple and to the point. :)
> http://www.martindengler.com/tmp/sl.o-2080/pulsingicon.py-stats-graph.png
>
> ...and then you could show us before and after your change on the XO
> 1.0 and XO 1.5.  Normally the relative time is most interesting, but
> since we are also interested in the absolute running time I patched
> gprof2dot.py to show that, and you can see the total time (in seconds)
> consumed by each graph node and its subtree as the second-to-last
> number shown in the node.
>
> You can find the pulsingicon.py changes and the instructions I used to
> make that in:
> http://www.martindengler.com/tmp/sl.o-2080/README.txt
>
>> And If you may compare the odd steps of both logs i.e the numbers in
>> the lines having "seconds taken to update frame" appearing at the odd
>> steps
>> (3rd ,5th ,7th.entries) and similarily compare  the even steps
>> you may find the average time taken on XO-1.5 to run the update
>> function was nearly 50% faster.
>
> Odd steps?  Even steps?  Sounds scary.  Why?
>
Sorry for the confusion. What  I meant to say by frames renders at odd
steps was 1st frame, 3rd frame , 5th frame.so on, similarily
for even frames.
> Martin
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[James Cameron]

On Thu, Oct 28, 2010 at 03:44:37PM -0300, Gonzalo Odiard wrote:
> I think the problem is the code is rendering the svg icon every time
> the color is changed.  There are not cache or cairo operation used to
> avoid this.

I agree.  Martin Dengler's stats graph confirms it.

Anurag is proposing skipping the paint after the first rendering.  It
remains a puzzle to me why the first frame rendering takes so much
longer than the remaining frames.

In Netrek when I faced this kind of problem, I solved it by
pre-rendering a reduced number of frames, or at least caching the
rendered frames.

The frame rate is 10 Hz.  The _phase is continually incremented, and the
level is set using:

self._level = (math.sin(self._phase) + 1) / 2

The first two seconds uses these levels:

0.50
0.920735
0.954649
0.570560
0.121599
0.020538
0.360292
0.828493
0.994679
0.706059
0.227989
0.05
0.231714
0.710084
0.995304
0.825144
0.356048
0.019301
0.124506
0.574939

Now if these were filtered to a reduced set of levels, the rendered
images could be cached and re-used.

N = 10
self._level = int(math.sin(self._phase) + 1) / 2 * N) / N

However, this moves the problem from CPU cycle cost to memory cost.

-- 
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[James Cameron]

On Thu, Oct 28, 2010 at 06:42:53PM +0100, Martin Dengler wrote:
> http://www.martindengler.com/tmp/sl.o-2080/pulsingicon.py-stats-graph.png

Nice.  A question on interpretation ... is the number of renderings
consistent with the number of __pulse_cb callbacks?

Looking at the bright green costly part of the graph, only the call
counts:

__pulse_cb 80x
__update 84x
{
__set_stroke_color 40x (implies get_pulsing is false half the time)
__set_fill_color 40x
}
_emit_paint_needed_icon_area 83x
get_surface 199x
render_cairo 90x

I'm puzzled as to why (a) set_stroke_color is only being called 40
times, yet (b) render_cairo is being called 90 times.  As if there is a
doubling.

-- 
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Research: 0.84 Launcher Cost

[James Cameron]

G'day Dipanker,

My research was not intended to propose a design change.  I'm happy with
how the launcher appears, and I think it adds considerable value to the
learning experience of the child.  I'm slightly not happy with delaying
the startup of an activity, and I see that as a defect.

I don't believe the use of floating point is costly.  GTK+ uses floating
point extensively.  The time spent computing the sine function (in
__pulse_cb) is minimal compared to the rendering time (render_cairo).

A precalculated fix sine table could reduce the cost of the sine
function, if it were a problem, which it is not.

Reducing the amount of rendering may help, and that was what I proposed
in the patch thread just now.  But again, there's a drawback of caching.

Activity startup time is more of a concern to me.

You might wish to propose to the design team a configuration option that
will suppress the launcher so as to improve startup time.  I don't plan
to propose that.

-- 
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[Gary Martin]

On 28 Oct 2010, at 00:17, James Cameron  wrote:

> On Wed, Oct 27, 2010 at 11:15:01PM +0530, Anurag Chowdhury wrote:
>> I carried out the same benchmark test, which I earlier conducted on an
>> XO-1.5, on a XO-1.  And I have attached the log files obtained in both
>> the cases.
> 
> I have reviewed them.  Can you show me the patch you used for benchmark
> test?  I re-read the code from launcher.py, pulsingicon.py in sugar.git,
> down to icon.py in sugar-toolkit.git, but wasn't able to figure out
> where you might have added that benchmark timing.  Without it, I don't
> understand what you are measuring, and so I don't understand the result.
> 
>> And found my assertion of XO-1.5 being a faster system in parameters
>> of the pulsing icon rendering also i found out the delay of the first
>> frame to be nearly 1.5 secs on XO-1 as compared to 0.8 secs on XO-1.5.
>> also the consecutive times taken for the rendering of the frames on
>> the XO-1 were much larger as compared to that on a XO-1.5. 
> 
> Yes, it seems to be a CPU task, not a graphics task, that you have
> removed by your proposed patch.
> 
>> Hence, the above taken log results verify that XO-1.5 has better
>> system performance in case of graphic rendering than XO-1.
> 
> Graphics rendering, yes.  Graphics performance, no.  I'm so sorry, all
> this time I thought you were talking about graphics performance, but now
> I see you are addressing a graphics rendering issue.
> 
>> And shipping the update function call for the first frame reduces the
>> delay by nearly 1.5secs on an XO-1 and by 0.8 secs on XO-1.5.
> 
> So Bernie's questions in the bug spark my curiosity as well ... why is
> it that the first frame is slower to render than the other frames?

Have been tinkering here also. My best guess so far is that it is the zoom PLUS 
pulse effect precessing that is snagging things up, but I'm still trying to 
nail it down for sure. Using the Distance dolphin SVG (fairly detailed) on an 
XO-1 F14 0.90 build I see a launch delay of 4sec drop to 1sec (an eye ball test 
from home view activity icon click to first draw of the SVG). Now the patch 
needs work**, and is likely a quick fix for a deeper animatior issue, but it 
does do what Anurag has been saying it does.

**FWIW I'd use a Boolean flag _skip_first_update, rather than an int counter 
(also the test for >2 should have been either >=2 or just >1), and there's no 
need to calculate the phase and level until you are updating so those can go 
inside the test. 

> (An unrelated side-issue ... the launcher is stealing CPU cycles from
> the startup of the activity, the task run queue shows this during a
> launch.  I wonder if activities might start up faster if there was no
> launcher, just a busy cursor.)

The main issue was that kids quickly start clicking (and did!) on other visible 
buttons/activities, quickly stalling out the whole system through impatience. 
The fullscreen launcher was designed to remove this case given our multi second 
launch times.

Regards,
--Gary 

> -- 
> James Cameron
> http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[James Cameron]

On Fri, Oct 29, 2010 at 01:36:08AM +0100, Gary Martin wrote:
> The main issue was that kids quickly start clicking (and did!) on
> other visible buttons/activities, quickly stalling out the whole
> system through impatience. The fullscreen launcher was designed to
> remove this case given our multi second launch times.

Good point.  If launcher animation becomes a configuration item, I would
prefer it to be replaced with a blank static launcher.  Not leave the
activity ring or the journal visible.

-- 
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Research: 0.84 Launcher Cost

[Gary Martin]

On 28 Oct 2010, at 04:34, James Cameron  wrote:

> Earlier in the context of SL#2080 patch review, I had said "the
> launcher is stealing CPU cycles from the startup of the activity, the
> task run queue shows this during a launch.  I wonder if activities
> might start up faster if there was no launcher, just a busy cursor."
> 
> Looks like activities would start faster; between one and four seconds,
> mostly depending on the activity, and slightly depending on the icon
> complexity.
> 
> Details below.
> 
> --
> 
> Research: will activities start faster if there is no launcher?
> 
> Method: using an XO-1, freshly installed with Sugar 0.84.22, as part
> of OLPC OS 10.1.2 build os852, test the startup time of three
> activities (Memorize, Moon and Chat), remove the launcher, retest,
> subtract.
> 
> The launcher is implemented by source file launcher.py in
> /usr/lib/python2.6/site-packages/jarabe/view/ ... the modification
> made is attached as a patch.
> 
> The times were captured with a stopwatch.  The timing began when "Start"
> was selected from the list view, and ended once the activity had
> completed display of the UI.
> 
> Result:
> 
> a.  unmodified launcher.py
> 
> Memorize-34 9.43s, 9.56s, 9.51s
> Moon-11 11.58s, 11.60s, 11.65s
> Chat-65 6.65s, 6.54s, 6.59s
> 
> b.  modified launcher.py (black background, no animation),
> 
> Memorize-34 7.60s, 7.63s, 7.60s
> Moon-11 7.78s, 7.78s, 7.95s
> Chat-65 5.04s, 4.93s, 4.88s
> 
> c.  calculated cost of launcher
> 
> Memorize-34 1.89s
> Moon-11 3.73s
> Chat-65 1.64s
> 
> Diagnosis: removing the launcher animation saved between one and four
> seconds of startup time.  The saving was greatest for the Moon activity.

Agreed, when Wade was working on this a year back or so, we came to the same 
estimate of about 4 sec for the launcher (should be in the mail list archives 
somewhere). I mentioned in a previous email that Wade managed to shave ~2 sec 
off this by pausing at the peek and trough of the pulse sine wave. However this 
did not land in time, so this is still 2sec up for grabs if some one wants to 
tweak and add pulse delays... You might even find Wade's patches for this ready 
to go if you go digging - I seem to remember the only reason it didn't land was 
a lack of time to test the change (was just Wade and me testing I think).

--Gary  

> --
> 
> Research: determine if the SVG icon for the Moon activity contributes
> to the delay.
> 
> Method: swap the icons, restart Sugar, retest only Chat activity with
> Moon icon.
> 
> Result:
> 
> a.  unmodified launcher.py
> 
> Chat-65 7.83s, 7.59s, 7.62s
> 
> b.  modified launcher.py (black background, no animation),
> 
> Chat-65 4.99s, 4.87s, 4.90s
> 
> c.  calculated cost of launcher
> 
> Chat-65 2.75s (greater than previous)
> 
> d.  calculated cost of moon icon over chat icon
> 
> Chat-65 1.09s
> 
> Diagnosis: the degree of saving has a little to do with the SVG icon
> complexity.  The degree of saving has much to do with the mix of
> operations performed by the activity during startup.
> 
> --
> 
> So, between 23 and 92 wasted days of looking at the launcher across
> two million laptops.  Good time to think and plan, kids.
> 
> -- 
> James Cameron
> http://quozl.linux.org.au/
> 
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] fix network disconnect and discard history

[James Cameron]

On Thu, Oct 28, 2010 at 04:11:35PM -0200, Esteban Arias wrote:
> I press "discard history" and shell.logs shows: [...]
>   File "/usr/lib/python2.6/site-packages/jarabe/model/network.py", line 506, 
> in clear_wifi_connections
> if conn.type == NM_CONNECTION_TYPE_802_11_WIRELESS:
> AttributeError: 'NMSettingsConnection' object has no attribute 'type'
> 
> If I switch "conn.type" to "conn._settings.connection" runs ok.

It should be conn._settings.connection.type.

You replied quoting an earlier patch of mine from 2010-05-25.  The most
recent patch (without the fix you just provided) is in the ticket #1673
and is marked "for uruguay consensus".  It remains out-of-tree, still.
Not enough interest in the fix.  "discard history" still does nothing in
HEAD.

The patch that was accepted into sucrose-0.84 was simpler; it discarded
GSM connections as well as wireless 802.11 connections, by not checking
the connection type:

def clear_connections(self):
for connection in self.connections.values():
connection.Removed()
self.connections = {}

-- 
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Research: 0.84 Launcher Cost

[James Cameron]

On Fri, Oct 29, 2010 at 02:41:48AM +0100, Gary Martin wrote:
> On 28 Oct 2010, at 04:34, James Cameron  wrote:
> > Diagnosis: removing the launcher animation saved between one and
> > four seconds of startup time.  The saving was greatest for the Moon
> > activity.
> 
> Agreed, when Wade was working on this a year back or so, we came to
> the same estimate of about 4 sec for the launcher (should be in the
> mail list archives somewhere).  I mentioned in a previous email that
> Wade managed to shave ~2 sec off this by pausing at the peek and
> trough of the pulse sine wave. However this did not land in time, so
> this is still 2sec up for grabs if some one wants to tweak and add
> pulse delays... You might even find Wade's patches for this ready to
> go if you go digging - I seem to remember the only reason it didn't
> land was a lack of time to test the change (was just Wade and me
> testing I think).

Ah, right, it's all been tried before then.  No worries.

-- 
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[Martin Dengler]

On Fri, Oct 29, 2010 at 05:26:40AM +0530, Anurag Chowdhury wrote:
> On Thu, Oct 28, 2010 at 11:12 PM, Martin Dengler
>  wrote:
> >  to test the time taken by update function everytime
> >> it is called.
> >> I used the time.time() function to measure the time taken to process
> >> the update step.
> >
> > There is a better way: use cProfile and gprof2dot.py.  You will get
> > graphs (and of course the raw data) like this:
> >
> Thanks and I appreciate the pointers., but I did it this way as I
> wanted it simple and to the point. :)

Well, it's simple, but it's not very useful or convincing.

> >> And If you may compare the odd steps of both logs i.e the numbers in
> >> the lines having "seconds taken to update frame" appearing at the odd
> >> steps
> >> (3rd ,5th ,7th.entries) and similarily compare  the even steps
> >> you may find the average time taken on XO-1.5 to run the update
> >> function was nearly 50% faster.
> >
> > Odd steps?  Even steps?  Sounds scary.  Why?
> >
> Sorry for the confusion. What  I meant to say by frames renders at odd
> steps was 1st frame, 3rd frame , 5th frame.so on, similarily
> for even frames.

I understood that.  The question is: Why?

Martin


pgpSLEy57BECB.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[Martin Dengler]

On Fri, Oct 29, 2010 at 05:26:33AM +0530, Anurag Chowdhury wrote:
> On Fri, Oct 29, 2010 at 12:14 AM, Gonzalo Odiard  wrote:
> > I think the problem is the code is rendering the svg icon every time
> > the color is changed.
> > There are not cache or cairo operation used to avoid this.
> >
> > Gonzalo
>
> Certainly that seems to me as a possible reason behind this issue ,
> but in the present state we need to decide exactly on what future we
> want for this pulsing icon i.e. keep it , improve it or replace it.

I guess that's why Gonzalo raised the point.  It's usually better to
fix the problem than to fix a symptom.

Martin


pgpcLPu88cNPl.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[Martin Dengler]

On Fri, Oct 29, 2010 at 11:05:45AM +1100, James Cameron wrote:
> On Thu, Oct 28, 2010 at 06:42:53PM +0100, Martin Dengler wrote:
> > http://www.martindengler.com/tmp/sl.o-2080/pulsingicon.py-stats-graph.png
> 
> Nice.  A question on interpretation ... is the number of renderings
> consistent with the number of __pulse_cb callbacks?

Yes...

> Looking at the bright green costly part of the graph, only the call
> counts:
> 
> __pulse_cb 80x
> __update 84x
> {
> __set_stroke_color 40x (implies get_pulsing is false half the time)
> __set_fill_color 40x
> }
> _emit_paint_needed_icon_area 83x
> get_surface 199x
> render_cairo 90x
> 
> I'm puzzled as to why (a) set_stroke_color is only being called 40
> times, yet (b) render_cairo is being called 90 times.  As if there is a
> doubling.

...because both set of 40x calls to __set_stroke_color and
__set_fill_color are causing _emit_paint_needed_icon_area to be
called[1,2], which call get_surface, which call render_cairo.  That
seems like doubling to me :).  Perhaps (OTTOMH) a flag in icon.py
_emit_paint_needed_icon_area which prevents it from actually emitting
if, well, it hasn't been paint()ed yet?

I'm also not sure why the icon is set as "sensitive", or whether "if
sensitive:"[3] is the right test.

Martin

1. 
http://cgit.sugarlabs.org/sugar-toolkit/mainline/tree/src/sugar/graphics/icon.py#n654
2. 
http://cgit.sugarlabs.org/sugar-toolkit/mainline/tree/src/sugar/graphics/icon.py#n685
3. 
http://cgit.sugarlabs.org/sugar-toolkit/mainline/tree/src/sugar/graphics/icon.py#n296


pgp1Y9HlqXFEN.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Dextrose] [PATCH v3] Reduction in the time taken for loading of the menu (SL#1169)

[Bernie Innocenti]

[cc += fgrose,m_stone]

On Wed, 2010-10-27 at 06:19 +0100, Martin Dengler wrote: 
> On Wed, Oct 27, 2010 at 06:05:58AM +0530, Manusheel Gupta wrote:
> > Are we ready to commit this patch?
> 
> Well, it's only a year after there were some quite significant
> discussions about it:
> http://lists.sugarlabs.org/archive/sugar-devel/2009-October/020141.html
> 
> There were many concerns.  Have they all been addressed?  Perhaps just
> nobody can be bothered to object again?

Well, a big change since last year is that now we've actually tested
this UI change for several months with a large number of real users.
The last adjustments proposed by Frederick Grose weren't actually
tested in a classroom, but it was well justified and lays somewhere
between the old and the new timings.

In order to test this change, we had to actually apply the patch to a
release build before we knew whether or not it was an improvement.
There's no other way! Very few developers have this luxury, so the
requirement to test each UI change beforehand should be dropped unless
we want to halt development.

For the future, I'd like to propose that we review UI changes using the
same criteria of any other code change. That is, by applying the
maintainer's best judgment upfront and testing the best we can
afterwards.

Establishing a tighter feedback loop with users is a problem that can be
solved separately with the help of deployments.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/



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

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[Samuel Greenfeld]

I was wondering about this as well.

I am more of a backend programmer, but the most obvious thing that 
stands out to me is that Sugar activities do not seem to regularly 
change their launch icons.  They are not like system tray or Sugar frame 
icons which alter themselves to tell us information.


Pardon me if I missed the back story here (I've read most of this 
thread, and glanced at the source code) but why do we see the need to 
render the animation on the fly, if that is indeed what is going on?  We 
may not want activities to package their own animations which could vary 
widely in design, but nothing should stop Sugar from pre-rendering 
animations for all past used/anticipated screen sizes on the first 
download/run of an activity (maybe as an SVG animation, or for speed at 
the screen's current resolution/color depth), or any of the OS builders 
from generating them for commonly expected screen sizes presuming full 
color depth.


The major drawbacks to this are adding code complexity, as well as a 
bias against Sugar on a Stick & CD/DVD-based users; the former may 
encounter a variety of different computers, while the latter has no 
permanent storage.  But I would hope that rendering at first run (or in 
an idle detecting process) would take care of them.



Also, I don't know how things are nowadays, but it seems like most Sugar 
activity icons are essentially tristate in nature (stroke color, fill 
color, and the background mask).  While you may or may not be able to 
play off of this with hardware color palette rotation anymore, there has 
still got to be somewhere where you can use this to your advantage.




On 10/28/10 22:35, Martin Dengler wrote:

On Fri, Oct 29, 2010 at 05:26:33AM +0530, Anurag Chowdhury wrote:

On Fri, Oct 29, 2010 at 12:14 AM, Gonzalo Odiard  wrote:

I think the problem is the code is rendering the svg icon every time
the color is changed.
There are not cache or cairo operation used to avoid this.

Gonzalo

Certainly that seems to me as a possible reason behind this issue ,
but in the present state we need to decide exactly on what future we
want for this pulsing icon i.e. keep it , improve it or replace it.

I guess that's why Gonzalo raised the point.  It's usually better to
fix the problem than to fix a symptom.

Martin


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


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

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[James Cameron]

G'day Samuel,

Yes, I think you're right, pre-rendering, either to RAM or to a file on
disk, would likely speed things considerably.

I suggest rendering 12 views at linear levels, then switching between
them using varying timing rather than fixed timing.  The visual effect
would not appear to be different.

As for which deployment to optimise for, I'd choose the one with the
most active users.  Are there at least two million Sugar on a Stick
users yet?  ;-)  I'm biased.

-- 
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] broken playback in record and jukebox

[Erik Blankinship]

On Sun, Oct 24, 2010 at 9:47 PM, Erik Blankinship wrote:

> On Sun, Oct 24, 2010 at 9:38 PM, James Cameron  wrote:
>
>> On Fri, Oct 22, 2010 at 03:31:23PM -0400, Erik Blankinship wrote:
>> > If I pause a video in either the record or jukebox activities and wait
>> > about 20 seconds, then just moving the mouse causes the video to go
>> > blank!   Or I can wait about 80 seconds and the video will go blank on
>> > its own.
>>
>> Is Automatic Power Management (My Settings, Power) enabled?
>>
>
> Yes, it is on.
>
>
>> Does the power LED blink?
>
>
> Not that I have noticed.
>


Anyone else have a suggestion where the bug might be?  Where are bugs like
these filed now?  Is this OLPC or sugar?

Not being able to reliably unpause video seems like a bad bug to me.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] broken playback in record and jukebox

[James Cameron]

On Fri, Oct 29, 2010 at 01:41:56AM -0400, Erik Blankinship wrote:
> On Sun, Oct 24, 2010 at 9:47 PM, Erik Blankinship wrote:
> > On Sun, Oct 24, 2010 at 9:38 PM, James Cameron wrote:
> > > On Fri, Oct 22, 2010 at 03:31:23PM -0400, Erik Blankinship wrote:
> > > > If I pause a video in either the record or jukebox activities
> > > > and wait about 20 seconds, then just moving the mouse causes the
> > > > video to go blank!  Or I can wait about 80 seconds and the video
> > > > will go blank on its own.
> > >
> > > Is Automatic Power Management (My Settings, Power) enabled?
> >
> > Yes, it is on.
> >
> > > Does the power LED blink?
> >
> > Not that I have noticed.  
> 
> Anyone else have a suggestion where the bug might be?   Where are bugs
> like these filed now?   Is this OLPC or sugar?

I suggest the bug may be due to a conflict between Automatic Power
Management and the XV component of the X server.  Bugs like these are
reported on http://dev.laptop.org/ ... and nothing that you've said so
far makes me think the bug is specific to Sugar, so
de...@lists.laptop.org may be a more suitable mailing list.  Especially
once you've tested to see if Automatic Power Management being off fixes
the problem.

> Not being able to reliably unpause video seems like a bad bug to me.

It doesn't seem bad to me yet, it sounds quite normal, even though it
should be fixed.

-- 
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel