After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 397544 - Numeric is no longer maintained
Numeric is no longer maintained
Status: RESOLVED FIXED
Product: pygtk
Classification: Bindings
Component: gdk
Git Master
Other All
: Normal enhancement
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2007-01-17 08:32 UTC by Steve Chaplin
Modified: 2009-04-07 18:56 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
patch to replace Numeric with numpy (5.89 KB, patch)
2008-05-28 12:39 UTC, Rémi Cardona
none Details | Review
Patch updated against svn trunk (2.72 KB, patch)
2009-02-14 22:57 UTC, Josselin Mouette
needs-work Details | Review
Patch for SVN trunk that works when numpy is not here (3.63 KB, patch)
2009-02-15 12:14 UTC, Josselin Mouette
committed Details | Review
patch to address warning (359 bytes, patch)
2009-04-06 18:43 UTC, Brian Cameron
committed Details | Review

Description Steve Chaplin 2007-01-17 08:32:42 UTC
gtk.gdk.Pixbuf.get_pixels_array provides optional support for Numeric python.

However, the last version of Numeric was released in Nov 2005 and it is no
longer maintained. Numeric users should migrate to numpy - the replacement for
Numeric.

  http://numpy.scipy.org/

Apparently, from the webpage:
Numeric C-code can be easily ported to NumPy using "numpy/oldnumeric.h"
Comment 1 Santiago M. Mola 2007-07-17 17:23:37 UTC
There are porting hints and a patch for pygtk at http://www.scipy.org/Porting_to_NumPy

Dropping numeric support is definately needed, since numeric is broken on amd64 with Python 2.5. Gentoo Linux is dropping numeric support and trying to port or remove (which, of course, is not an option with pygtk) all packages depending on it. You can expect more distros following this path in the future.
Comment 2 Luis Medinas 2007-07-17 21:27:40 UTC
Agreed... there's no point to support a deprecated library so pygtk should migrate to numpy or develop a specific library for pygtk.
Comment 3 Brian Cameron 2007-11-02 01:43:45 UTC
Can this go upstream?
Comment 4 Martin Renold 2008-03-26 20:20:10 UTC
FYI I'm coding a tricky workaround for this bug in my application. Please?
Comment 5 Rémi Cardona 2008-05-28 06:53:47 UTC
Ping, what's the status on this? There's a patch in Gentoo's bugzilla, can it be reviewed?

https://bugs.gentoo.org/attachment.cgi?id=125297&action=view

Thanks
Comment 6 Johan (not receiving bugmail) Dahlin 2008-05-28 12:29:47 UTC
(In reply to comment #5)
> Ping, what's the status on this? There's a patch in Gentoo's bugzilla, can it
> be reviewed?
> 
> https://bugs.gentoo.org/attachment.cgi?id=125297&action=view

Can you attach that patch to this bugzilla, please?
Comment 7 Rémi Cardona 2008-05-28 12:39:14 UTC
Created attachment 111653 [details] [review]
patch to replace Numeric with numpy

Here's the patch. Disclaimer, I'm just forwarding the patch written by fellow gentoo dev Ali Polatel.
Comment 8 Johan (not receiving bugmail) Dahlin 2008-05-28 13:00:45 UTC
(In reply to comment #7)
> Created an attachment (id=111653) [edit]
> patch to replace Numeric with numpy
> 
> Here's the patch. Disclaimer, I'm just forwarding the patch written by fellow
> gentoo dev Ali Polatel.
> 

I think this patch looks good, I'm slightly concerned that switching from Numeric to numpy in one go will not provide a smooth migration though.
I'd rather support both during a transition period, can I patch be provided for that?
Comment 9 Rémi Cardona 2008-05-28 13:49:44 UTC
(In reply to comment #8)
> I think this patch looks good, I'm slightly concerned that switching from
> Numeric to numpy in one go will not provide a smooth migration though.
> I'd rather support both during a transition period, can I patch be provided for
> that?

Our resident python expert (who wrote the patch) tells me that Numeric is dead and hasn't been updated in over a year. From the numpy homepage :

"Maintenance has ceased for Numeric, and users should transisition to NumPy as quickly as possible."

But of course, it's your call :)
Comment 10 Johan (not receiving bugmail) Dahlin 2008-05-28 14:07:31 UTC
> Our resident python expert (who wrote the patch) tells me that Numeric is dead
> and hasn't been updated in over a year. From the numpy homepage :
>
> "Maintenance has ceased for Numeric, and users should transisition to NumPy as
> quickly as possible."

That I do not question, I believe you that it is dead.
However, lots of people do have Numeric installed on their machines, most pygtk packages for Linux distributions depends on Numeric, so thus they have it installed. Applications using PyGTK & Numeric together will break, which is not acceptable.

What I think is reasonable is:
- Add conditional support for Numpy in PyGTK
- Deprecate Numeric support

wait a couple of releases

- Remove Numeric support

I just don't want to do all these three items in the same release for the reasons mentioned above


Comment 11 Rémi Cardona 2008-05-28 14:23:09 UTC
Then maybe this needs to be coordinated with other gnome/python packages so that it all happens at the same time. Could it be done and tested in time for Gnome 2.24 and then completely removed for 2.26 ? Maybe it could all be done for 2.24 ?

Thanks
Comment 12 Johan (not receiving bugmail) Dahlin 2008-05-28 14:31:28 UTC
No, it cannot be done just for 2.24. It's not just about GNOME, there are other applications apart from GNOME using PyGTK. 

From PyGTK point of view gnome/python applications are no different from any others, they need all need to be updated.
Comment 13 Gustavo Carneiro 2008-05-28 14:42:48 UTC
IMHO I think it should not be too bad to just migrate to numpy for the next pygtk _major_ release.  Just don't do it in a bugfix release, that would be bad karma :-/

Of course I agree with Johan, a transition phase where both numpy numeric would be accepted (giving precedence to numpy) would be ideal, but it does require more work.  Conditional compiling is never easy to code... :P
Comment 14 Matthew Barnes 2008-08-25 17:48:41 UTC
Ping: Is a transition to numpy in the cards for pygtk 2.13?

Asking because the OLPC guys are clamoring for this:
http://bugzilla.redhat.com/show_bug.cgi?id=459822
Comment 15 Martin Renold 2008-10-25 15:15:24 UTC
For the record, this is my current workaround. It's a swiged c++ header which creates a numpy wrapper around the old numeric data:

http://svn.gna.org/viewcvs/mypaint/trunk/lib/gdkpixbuf2numpy.hpp?rev=90&view=auto
Comment 16 Peter Robinson 2008-11-20 13:49:13 UTC
Any update on this? The last release of numeric was over 3 years ago. There's also patches for a number of things that use(d) numeric including pygtk that's on the link in comment #1
Comment 17 Kamil Kisiel 2008-12-10 19:05:42 UTC
For what it's worth, Debian has a patched version in experimental that uses Numpy instead of Numeric:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478452
Comment 18 Josselin Mouette 2008-12-10 19:29:14 UTC
(In reply to comment #17)
> For what it's worth, Debian has a patched version in experimental that uses
> Numpy

The patch can be found in our patch tracking system, but you’ll see it’s almost the same as the one from Gentoo.
Comment 19 Peter Robinson 2009-02-10 12:22:05 UTC
Is there a status update on this? Is it due to be fixed in time for gnome 2.26?
Comment 20 Gian Mario Tagliaretti 2009-02-14 17:21:29 UTC
If we can have a patch that applies cleanly against trunk I will push it for 2.15/2.16. We now have to close this one.
Comment 21 Josselin Mouette 2009-02-14 22:57:58 UTC
Created attachment 128739 [details] [review]
Patch updated against svn trunk

Here you go.
Comment 22 Gian Mario Tagliaretti 2009-02-15 09:00:07 UTC
Sorry but if numpy isn't found:

checking for GDK target... x11
Traceback (most recent call last):
  • File "<string>", line 1 in <module>
ImportError: No module named numpy
checking for numpy/arrayobject.h... no

Everything will be broken:

atk.c:16911: error: ‘ATK_TYPE_STATE_SET’ undeclared (first use in this function)
atk.c:16913: error: ‘ATK_TYPE_UTIL’ undeclared (first use in this function)
make[2]: *** [atk_la-atk.lo] Error 1
make[2]: Leaving directory `/home/gianmt/Repos/pygtk'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/gianmt/Repos/pygtk'
make: *** [all] Error 2
Comment 23 Josselin Mouette 2009-02-15 12:14:58 UTC
Created attachment 128767 [details] [review]
Patch for SVN trunk that works when numpy is not here

Here is another attempt (and this time, I also tried without numpy installed).
Comment 24 Gian Mario Tagliaretti 2009-02-21 18:52:30 UTC
Josselin thanks for the updates patch, it applies and works correctly in both cases, with and without numpy.

I didn't investigate at all this warning:

gdkpixbuf.override: In function ‘have_numpy’:
gdkpixbuf.override:78: warning: ‘return’ with no value, in function returning non-void

I guess something is changed in the numpy init function?
Comment 25 Peter Robinson 2009-04-05 09:38:05 UTC
Is there any progress in getting this merged?
Comment 26 Gian Mario Tagliaretti 2009-04-05 09:54:36 UTC
It's ready to be merged, but I have no time to look at that warning, help appreciated.
Comment 27 Brian Cameron 2009-04-06 18:16:56 UTC
The problem is that "import_array" is a macro which calls return.  The 
"have_numpy" function returns a value, so this causes a problem.

Replacing the line in gdkpixbuf.override so that "is_array();" is changed
to "is_array1(1);" fixes the problem.

Note from the numpy code, is_array1 allows you to return a value you specify
on error.  You can also specify a message to display if you use import_array2.
Here is the #defines from the NumPy code:

./code_generators/generate_numpy_api.py:
#define import_array() {if (_import_array() < 0) {PyErr_Print(); PyErr_SetString(PyExc_ImportError, "numpy.core.multiarray failed to import"); return; } }
#define import_array1(ret) {if (_import_array() < 0) {PyErr_Print(); PyErr_SetString(PyExc_ImportError, "numpy.core.multiarray failed to import"); return ret; } }
#define import_array2(msg, ret) {if (_import_array() < 0) {PyErr_Print(); PyErr_SetString(PyExc_ImportError, msg); return ret; } }

So this should be an easy fix if you want to get rid of the warning.
Comment 28 Brian Cameron 2009-04-06 18:43:56 UTC
Created attachment 132211 [details] [review]
patch to address warning


Attached patch deals with the warning.  It affects a file not in the previous patch.
Comment 29 Peter Robinson 2009-04-07 08:24:45 UTC
This is great. Thanks every one. What release will this hit, and is it scheduled yet?
Comment 30 Gian Mario Tagliaretti 2009-04-07 18:56:34 UTC
(In reply to comment #29)
> This is great. Thanks every one. What release will this hit, and is it
> scheduled yet?
> 

I plan in a few days to release pygtk-2.15.0 since I've already added GTK+ 2.16 API to trunk.