Remove numpy usage from the shell

[marco]

It's using a lot of memory and slowing down startup.

[marco]

Not well tested nor reviewed yet. Let's first decide on the approach.

[bernie]

In all loops:

56 for (i = rect->x; i < rect->x + rect->width; i++) { 57 for (k = rect->y; i < rect->y + rect->width; i++) {

The second line s/k/i/g and s/width/height/.

Also, swap the inner and outer loop. This hopefully lets the compiler simplify the calculations for the array subscriptions to a linear increment.

[bernie]

Please also update sugar.spec to remove the dependency on numpy

[bernie]

28 void 
29 sugar_grid_setup(SugarGrid *grid, gint width, gint height) 
30 { 
31    g_free(grid->weights); 
32    
33    grid->weights = g_new0(guchar, width * height);

Why the g_free() on (possibly) uninitialized memory?

[marco]

To handle multiple setup calls (we don't do it at the moment but...). g_free is NULL safe, do you see cases where it could be uninitialized? It's set to NULL in _init.

[cscott]

Let's be sure we test non-US locales to ensure #5559 doesn't regress.

http://dev.laptop.org/git?p=sugar;a=blob;f=src/main.py;h=1ccfbb83070db9bd1c4bde3fbd15ecaffbe2e210;hb=sucrose-0.82#l20

[marco]

<benzea> ok, looks all good to me

[marco]

I tested it pretty heavily while hunting down the leaks and it seem to behave well. The only problem is a warning on setup(). It doesn't hurt I think, but we should fix it.

[marco]

Ok, this had a least a couple of reviews, so I'm going to push it. The warning is caused by SpreadLayout passing a float, will fix that in sugar.

[marco]

sugar-0.82.7-1.olpc3 and sugar-toolkit-0.82.8-2.olpc3

[mstone]

Approved.

[marco]

Code changes:

http://dev.laptop.org/git?p=sugar;a=commit;h=d17caca472fdfffbbec8ba529c46c909dfd77325 http://dev.laptop.org/git?p=sugar-toolkit;a=commit;h=e622c4ec993082d69bf49e542e17574dc1ccefc8

[cscott]

Please test build 761 resulting from build-repo commit b7c11be9.

[mchua]

Is there a test case we can use to see (from the user side) whether the patch has had the desired effect? I'm lost on how to check for this other than "open up the source on the XO, make sure the sugar-grid code's in there and the numpy code isn't".

[marco]

You can either use ps_mem or free to measure memory, and compare before/after the change.

http://sugarlabs.org/go/DevelopmentTeam/Profiling

and

http://lists.laptop.org/pipermail/devel/2008-September/019301.html

[mchua]

From IRC:

<marcopg> mchua_: I would apply this patch (reversed) 
http://dev.laptop.org/attachment/ticket/8372/numpy-sugar.patch 
and test both after and before on a clean 763

|Test case|

1. clean-install 763 on an XO; boot it up.
2. On that XO, measure memory usage. See http://wiki.laptop.org/go/Measuring_memory_usage.
3. download the numpy patch: (In a terminal) wget http://dev.laptop.org/attachment/ticket/8372/numpy-sugar.patch
4. reverse the patch, patch -p0 -R < ./numpy-sugar.patch. You will now have an XO running 763 but (hopefully) with this particular bug reintroduced.
5. Measure memory usage again.

Test passes if the clean-installed XO (1st time measuring memory usage) has better memory stats than the patch-reversed XO (2nd time measuring memory usage).

[bernie]

This has been done long ago.