Good catch. By design ordering should be preserved, so this needs fixing.
On Saturday, 18 May 2013, Aneesh Dogra wrote:
> Hello list,
>
> I was just looking over some code in bus.js and I noticed that we are
> actually using a stack to prioritize and keep track of our send requests.
> The array w
Hello list,
I was just looking over some code in bus.js and I noticed that we are
actually using a stack to prioritize and keep track of our send requests.
The array which you name as "queue" is actually used as a stack.
Here's what I think is happening:
Suppose I send 3 consecutive requests:
T
Activity Homepage:
http://activities.sugarlabs.org/addon/4082
Sugar Platform:
0.96 - 0.100
Download Now:
http://activities.sugarlabs.org/downloads/file/28572/paint-58.xo
Release notes:
Remove the custom icon used to the the shapes properties button.
Solve the draw of shapes with alpha with big l
http://buildbot.sugarlabs.org/builders/raring-amd64-quick/builds/9/steps/shell_3/logs/stdio
config.py is autogenerated, so lines can be arbitrary long.
Perhaps the simplest fix it just to use --exclude.
We could also consider switching to flake8 to run both pyflakes and pep8
and be able to skip c
2013/5/17 Daniel Narvaez :
> Thanks. That looks great!
>
> I wonder if it would be worth to document the desired visuals and behaviour
> while writing the code. It shouldn't take a lot of time and it could be a
> decent UI spec, useful to testers and designers too. Docco seems right for
> this kind
Thanks. That looks great!
I wonder if it would be worth to document the desired visuals and behaviour
while writing the code. It shouldn't take a lot of time and it could be a
decent UI spec, useful to testers and designers too. Docco seems right for
this kind of stuff and keeping the UI spec in t
2013/5/17 Daniel Narvaez :
> Hello,
>
> I created a bit of a roadmap for 0.100 on github, to give some information
> about the release status and deadlines.
>
> https://github.com/sugarlabs/roadmap/issues/milestones
>
> The milestones has informations about dates/freezes. The issues contains
> info
Ok. Thanks!
Date: Fri, 17 May 2013 14:20:18 +0200
From: dwnarv...@gmail.com
To: alan...@hotmail.com
CC: sugar-devel@lists.sugarlabs.org
Subject: Re: [Sugar-devel] [sugar-build] Command line change
It was an ubuntu/debian bug but the latest virtualenv release works. So I
upgraded and this issue i
Hello,
I created a bit of a roadmap for 0.100 on github, to give some information
about the release status and deadlines.
https://github.com/sugarlabs/roadmap/issues/milestones
The milestones has informations about dates/freezes. The issues contains
information about the new features we are plan
Thanks so much for the well thought feedback, Sean.
On 17 May 2013 18:04, Sean DALY wrote:
> We can't go with 1.0 unless we change the numbering system.
>
> The current system means it will take another decade to get to v3.0. I and
> perhaps others will have far more grey hair by then.
>
Couple
We can't go with 1.0 unless we change the numbering system.
The current system means it will take another decade to get to v3.0. I and
perhaps others will have far more grey hair by then.
I proposed several years ago that the developer version numbers (not to
mention the OLPC OS version numbers)
It seems like we have agreement on going 1.0 so far. Unless someone speak
up I'm going to make that the plan in a couple of days.
On 17 May 2013 15:07, Daniel Narvaez wrote:
> Hello,
>
> we need to decide if we want the next release to be 1.0 or 0.100.
>
> Here is the features we are planning f
On 17 May 2013 15:53, Manuel Quiñones wrote:
> And for the html sugar, we should do full coverage testing.
>
You mean make check enforced 100% coverage? :) I would love it.
You proposed it, so people hate should be directed to you! I did it with a
project I and always felt sort of guilty ab
Nice phrase Alan :)
I agree with all, let's name it 1.0 .
2013/5/17 Alan Kay :
> "Better" and "Perfect" are the enemies of "What Is Needed"
>
>
> From: Walter Bender
> To: Daniel Narvaez ; Sean DALY
> Cc: Sugar Labs Marketing ;
> "sugar-devel@lists.sugarlabs.org
Sorry for not answering yet, I was in doubt.because of the "raising
the bar" consequence.
I really missed unit-testings in Sugar when the GTK3 port was made. I
considered starting doing them at that time, but looked like a lot of
work. Adding testing to an already written system can be a pain.
IMO being a small team makes it an even better idea :) If you get used to
it, I think you write solid new code faster _with_ tests than without.
I disagree we don't have a regression problem. Just think of the settings
stuff that has been broken for months. Also we are scared to refactor stuff
bec
May be I am old fashion, but requesting mandatory automated tests for all
the changes is not a good idea.
We are a small team. And we don't have a problem of regressions.
May be, with the new web api, with the many changes we will have in the
next months,
is a good idea.
Gonzalo
On Fri, May 17,
"Better" and "Perfect" are the enemies of "What Is Needed"
>
> From: Walter Bender
>To: Daniel Narvaez ; Sean DALY
>Cc: Sugar Labs Marketing ;
>"sugar-devel@lists.sugarlabs.org" ; iaep
>
>Sent: Friday, May 17, 2013 6:21 AM
>Subject: Re: [IAEP] [Marketing] Su
Ok, then I would say (1) everything.
Simon
On 05/17/2013 03:23 PM, Daniel Narvaez wrote:
Oh sorry, I suppose I should have made that clear :) I'm talking about
automated tests, we have a few examples of them in the tree
https://github.com/sugarlabs/sugar-toolkit-gtk3/tree/master/tests
https://
I'm happy to provide guidance on this (for as much time free time I have
available for sugar).
On 17 May 2013 15:23, Walter Bender wrote:
> +1 to adding tests to all new features, but some guidance on what
> these tests should look like is necessary.
>
> -walter
>
> On Fri, May 17, 2013 at 9:16
Oh sorry, I suppose I should have made that clear :) I'm talking about
automated tests, we have a few examples of them in the tree
https://github.com/sugarlabs/sugar-toolkit-gtk3/tree/master/tests
https://github.com/sugarlabs/sugar/tree/master/tests
https://github.com/sugarlabs/sugar-build/tree/ma
+1 to adding tests to all new features, but some guidance on what
these tests should look like is necessary.
-walter
On Fri, May 17, 2013 at 9:16 AM, Simon Schampijer wrote:
> How does the test coverage looks like? Human testing or automated tests?
>
> Thanks,
>Simon
>
>
> On 05/17/2013 03:1
Perfection is the enemy of the good.
On Fri, May 17, 2013 at 9:07 AM, Daniel Narvaez wrote:
> Hello,
>
> we need to decide if we want the next release to be 1.0 or 0.100.
>
> Here is the features we are planning for it.
>
> * Develop an HTML5 based toolkit for activities
>
> * Multiple selection
How does the test coverage looks like? Human testing or automated tests?
Thanks,
Simon
On 05/17/2013 03:13 PM, Daniel Narvaez wrote:
Simon, Manuel,
any feedback about this? I see a few possible levels
1 Everything, bugfixes included
2 Every feature patch
3 Every patch to the new html/javas
Hi,
On Fri, May 17 2013, Daniel Narvaez wrote:
> we need to decide if we want the next release to be 1.0 or 0.100.
1.0! It's crazy that we have a project used by millions of people
that's still pre-1.0 seven years later. And the extra press from
calling it 1.0 will be useful to direct people to
Simon, Manuel,
any feedback about this? I see a few possible levels
1 Everything, bugfixes included
2 Every feature patch
3 Every patch to the new html/javascript code
4 Nothing, leave it to the contributor willingness
I'm opposed to 4 :) I tend to think we should do 2, because a lot of new
code
Hello,
we need to decide if we want the next release to be 1.0 or 0.100.
Here is the features we are planning for it.
* Develop an HTML5 based toolkit for activities
* Multiple selection in the Journal
http://wiki.sugarlabs.org/go/Features/Multi_selection
* Enhanced support for 3G modems
http:
It was an ubuntu/debian bug but the latest virtualenv release works. So I
upgraded and this issue is fixed. Waiting for the builds to complete
though...
On 17 May 2013 08:38, Daniel Narvaez wrote:
> The command line changes are mostly a side of the code changes I made to
> make it possible to u
28 matches
Mail list logo
