Re: [Sugar-devel] Web activity example that uses html5 canvas

[Manuel Quiñones]

Excellent Gary, thanks a lot.

If you can describe the bugs or add tickets, I'll be happy to help.

2013/5/11 Gary Martin :
> Hey Manuel,
>
> On 11 May 2013, at 00:47, Manuel Quiñones  wrote:
>
>> Oh, we should release it then.  Can you, Gary?
>
> Yes but need to fix the 'drag hands' bugs – can't have it reading out 
> occasional incorrect times to kids due to lack of precision/rounding errors 
> ;) Lets see if I can make progress this weekend and make a release.
>
> Regards,
> --Gary
>
>> 2013/5/10 James Cameron :
>>> On Wed, May 01, 2013 at 10:55:51AM +1000, James Cameron wrote:
 Summary: this Clock activity consumes significantly less CPU on XO-4
 and XO-1 when implemented in Javascript.
>>>
>>> Myth busted.  See new results in context below.
>>>
 On Tue, Apr 30, 2013 at 08:42:18PM -0300, Manuel Qui?ones wrote:
> 2013/4/30 James Cameron :
>> On Tue, Apr 30, 2013 at 08:58:50AM -0300, Manuel Qui?ones wrote:
>>> Should work on other browsers now:
>>>
>>> http://manuq.github.io/clockjs/
>>
>> Agreed, works well, reasonably low CPU utilisation.  Thanks.
>
> Excellent.  Thanks for checking the CPU consumption.

 Here's a more detailed check.  Method is to run only the activity
 under test, and use the serial port to run the Linux top command
 configured for a 30 second sample time.

 --

 On XO-4 using 13.1.0:

 - using Javascript, the Browse-149 process consumes 7.5% CPU, and the
  X process 3.2% CPU.  Total of 10.7% CPU.

 - not using Javascript, the Clock-12 process consumes 2.7% CPU, and
  the X process 13.2% CPU.  Total of 15.9% CPU.
>>>
>>> Clock-12.5 process consumes 0.6%, and the X process 2.0%, a total of
>>> 2.6%.
>>>
 --

 On XO-1 using 13.2.0, build 32004o0,

 - using Javascript, the Browse-149.2 process consumes 9.8%, the X
  process 7.4%, a total of 17.2%,

 - not using Javascript, the Clock-12 process consumes 10.4% and X
  process consumes 18.4%, a total of 30.8%.
>>>
>>> Clock-12.5 process consumes 1.5%, and the X process 3.6%, a total of
>>> 5.1%.
>>>

 --

 On XO-1 using 11.3.0, build 883,

 - using Javascript, the Browse 129.1 does not render the script,

 - not using Javascript, the Clock-6 consumes 7.0%, and X consumed
  9.0%, a total of 16%.
>>>
>>> Test not repeated.
>>>
>>> --
>>> James Cameron
>>> http://quozl.linux.org.au/
>>
>>
>>
>> --
>> .. manuq ..
>



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

[Sugar-devel] New sugar-html-datastore module

[Daniel Narvaez]

I pushed a very initial implementation of the datastore javascript API.

I submitted several patches for the existing components to make that
actually work.

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

Re: [Sugar-devel] Github issue tracking

[William Orr]

Simon Schampijer 
May 11, 2013 11:55 AM
Am 11.05.2013 um 16:45 schrieb Daniel Drake:


On Sat, May 11, 2013 at 4:15 AM, Daniel Narvaez  wrote:

https://github.com/sugarlabs/sugar-toolkit-gtk3/issues/27

We should probably  decide if we want to keep using trac instead and if so
turn the issue tracker on github off.

Last time we discussed it, the idea was to keep using trac to not depend too
much on closed source github. What are people thoughts these days?

I would prefer to stay with trac, to avoid a split/migration, to keep
the info on the tickets directly under our control, and to keep with
our open source ideals.

Daniel


I wanted to give it a try to see how it works at least, going through the 
process with this ticket. I am not opposed to stay with trac though.

Simon



___
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
Daniel Drake 
May 11, 2013 10:45 AM

I would prefer to stay with trac, to avoid a split/migration, to keep
the info on the tickets directly under our control, and to keep with
our open source ideals.

Daniel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Daniel Narvaez 
May 11, 2013 6:15 AM
Hello,

I noticed people have started to report issues on github.

https://github.com/sugarlabs/sugar-toolkit-gtk3/issues/27

We should probably  decide if we want to keep using trac instead and 
if so turn the issue tracker on github off.


Last time we discussed it, the idea was to keep using trac to not 
depend too much on closed source github. What are people thoughts 
these days?


Personally I like github issue tracking a lot, though I see the point 
about it being closed source and I imagine a migration would be a bit 
of a pain.


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

Hello,

Sticking with a privately controlled bug tracker is probably a good 
idea. However, trac really needs to be cleaned up, as there are a ton of 
3-5 year old bugs floating around that have long since been fixed. I've 
started closing the few I can't reproduce in scm.


As a new contributor, I initially had gotten the impression that no one 
used trac, and I was discouraged from reporting/fixing bugs there.


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

Re: [Sugar-devel] Github issue tracking

[Simon Schampijer]

Am 11.05.2013 um 16:45 schrieb Daniel Drake :

> On Sat, May 11, 2013 at 4:15 AM, Daniel Narvaez  wrote:
>> https://github.com/sugarlabs/sugar-toolkit-gtk3/issues/27
>> 
>> We should probably  decide if we want to keep using trac instead and if so
>> turn the issue tracker on github off.
>> 
>> Last time we discussed it, the idea was to keep using trac to not depend too
>> much on closed source github. What are people thoughts these days?
> 
> I would prefer to stay with trac, to avoid a split/migration, to keep
> the info on the tickets directly under our control, and to keep with
> our open source ideals.
> 
> Daniel

I wanted to give it a try to see how it works at least, going through the 
process with this ticket. I am not opposed to stay with trac though.

Simon


> ___
> 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] Web activity example that uses html5 canvas

[Gary Martin]

Hey Manuel,

On 11 May 2013, at 00:47, Manuel Quiñones  wrote:

> Oh, we should release it then.  Can you, Gary?

Yes but need to fix the 'drag hands' bugs – can't have it reading out 
occasional incorrect times to kids due to lack of precision/rounding errors ;) 
Lets see if I can make progress this weekend and make a release.

Regards,
--Gary

> 2013/5/10 James Cameron :
>> On Wed, May 01, 2013 at 10:55:51AM +1000, James Cameron wrote:
>>> Summary: this Clock activity consumes significantly less CPU on XO-4
>>> and XO-1 when implemented in Javascript.
>> 
>> Myth busted.  See new results in context below.
>> 
>>> On Tue, Apr 30, 2013 at 08:42:18PM -0300, Manuel Qui?ones wrote:
 2013/4/30 James Cameron :
> On Tue, Apr 30, 2013 at 08:58:50AM -0300, Manuel Qui?ones wrote:
>> Should work on other browsers now:
>> 
>> http://manuq.github.io/clockjs/
> 
> Agreed, works well, reasonably low CPU utilisation.  Thanks.
 
 Excellent.  Thanks for checking the CPU consumption.
>>> 
>>> Here's a more detailed check.  Method is to run only the activity
>>> under test, and use the serial port to run the Linux top command
>>> configured for a 30 second sample time.
>>> 
>>> --
>>> 
>>> On XO-4 using 13.1.0:
>>> 
>>> - using Javascript, the Browse-149 process consumes 7.5% CPU, and the
>>>  X process 3.2% CPU.  Total of 10.7% CPU.
>>> 
>>> - not using Javascript, the Clock-12 process consumes 2.7% CPU, and
>>>  the X process 13.2% CPU.  Total of 15.9% CPU.
>> 
>> Clock-12.5 process consumes 0.6%, and the X process 2.0%, a total of
>> 2.6%.
>> 
>>> --
>>> 
>>> On XO-1 using 13.2.0, build 32004o0,
>>> 
>>> - using Javascript, the Browse-149.2 process consumes 9.8%, the X
>>>  process 7.4%, a total of 17.2%,
>>> 
>>> - not using Javascript, the Clock-12 process consumes 10.4% and X
>>>  process consumes 18.4%, a total of 30.8%.
>> 
>> Clock-12.5 process consumes 1.5%, and the X process 3.6%, a total of
>> 5.1%.
>> 
>>> 
>>> --
>>> 
>>> On XO-1 using 11.3.0, build 883,
>>> 
>>> - using Javascript, the Browse 129.1 does not render the script,
>>> 
>>> - not using Javascript, the Clock-6 consumes 7.0%, and X consumed
>>>  9.0%, a total of 16%.
>> 
>> Test not repeated.
>> 
>> --
>> James Cameron
>> http://quozl.linux.org.au/
> 
> 
> 
> -- 
> .. manuq ..

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

Re: [Sugar-devel] Github issue tracking

[Daniel Drake]

On Sat, May 11, 2013 at 4:15 AM, Daniel Narvaez  wrote:
> https://github.com/sugarlabs/sugar-toolkit-gtk3/issues/27
>
> We should probably  decide if we want to keep using trac instead and if so
> turn the issue tracker on github off.
>
> Last time we discussed it, the idea was to keep using trac to not depend too
> much on closed source github. What are people thoughts these days?

I would prefer to stay with trac, to avoid a split/migration, to keep
the info on the tickets directly under our control, and to keep with
our open source ideals.

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

[Sugar-devel] Github issue tracking

[Daniel Narvaez]

Hello,

I noticed people have started to report issues on github.

https://github.com/sugarlabs/sugar-toolkit-gtk3/issues/27

We should probably  decide if we want to keep using trac instead and if so
turn the issue tracker on github off.

Last time we discussed it, the idea was to keep using trac to not depend
too much on closed source github. What are people thoughts these days?

Personally I like github issue tracking a lot, though I see the point about
it being closed source and I imagine a migration would be a bit of a pain.

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

Re: [Sugar-devel] sugar-build new dependency

[Daniel Narvaez]

On 11 May 2013 05:54, Alan Jhonn Aguiar Schwyn  wrote:

> >>Do you get the same error if you make build again?
>
> Yes.
>
>
Try this

make shell
cd source/webkitgtk
V=1 make

That should give more verbose output, let's see if there is something
useful in there.

>> Do you have free disk space? The error is not very useful :(
>
> A lot.. hundreds of gb..
>
> Another problem: the "volo" fails when I compile.. I just found that in
> my home appears a tmp folder with some files of "volo", maybe there
> are a error on the build path??
> I attach a .tar.gz with all files..
>

The tmp dir is normal, it's just the npm temporary directory. How does volo
fail to build? (the logs from make bug-report would be useful).
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel