Stephen Walton wrote:

In my ongoing struggles with FC4, I now find that the Fedora developers have put Numeric 23.7 into the core as python-numeric and built pygtk2 against it, so the latter has a dependency on the former.

I think this is a bad idea unless the core developers are going to include ATLAS and build Numeric against it. After all, this community and the Scipy one have gone to great lengths to optimize ATLAS and build Numeric and numarray (and presumably the new scipy core) against it. But I'm probably not going to convince the Redhat folks on my own.

So, questions are: can someone more familiar with pygtk2 than me tell me what parts of it depend on Numeric and why? Can we start a campaign to put ATLAS into Fedora Core if Numeric is going to be there too?

It's for returning a Numeric array from a pixbuf. Strictly speaking, it's optional, but it looks like the package maintainers decided to compile it in for FC4. Can you make an RPM of python-numeric compiled against ATLAS and install it yourself? Or can you install Numeric yourself and make a dummy package to tell RPM that yes, indeed, Numeric is installed? I'm terribly unfamiliar with Fedora and RPM; I've always prefered Debian. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter

Robert Kern wrote:

Stephen Walton wrote:

...

So, questions are: can someone more familiar with pygtk2 than me tell me what parts of it depend on Numeric and why? Can we start a campaign to put ATLAS into Fedora Core if Numeric is going to be there too?

It's for returning a Numeric array from a pixbuf.

This is a Darn Good example of why we need the new array protocol. Let's make sure to make sure it gets used as widely as possible. -Chris

Greg Ewing wrote:

Chris Barker wrote:

...

This is a Darn Good example of why we need the new array protocol.

I came across another one the other day when working on pygui. I wanted to use glReadPixels to read data into a buffer belonging to an NSBitmapImageRep, but PyOpenGL's glReadPixels can only read data into an existing memory block if it's a Numeric array, and PyObjC doesn't know anything about Numeric...

I've taken the liberty of adding these to a new Wiki page. Let's record these "Oh I wish everyone used the array protocol" moments when we come across them. http://www.scipy.org/wikis/featurerequests/ArrayInterfaceUseCases/ This will probably migrate to the Trac instance for scipy whenever that comes about. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter

Fernando Perez wrote:

Robert Kern wrote:

...

Can you make an RPM of python-numeric compiled against ATLAS and install it yourself?

You can. In fact, Numeric builds out of the box with

python bdist_rpm,

though the package name comes out to be named 'Numeric', but that should not be a problem, since the setup.cfg file reads:

[bdist_rpm] provides=python-numeric, python-numeric-devel build_script=rpm_build.sh install_script=rpm_install.sh

which means that the python-numeric dependency should be satisfied.

Yes, it is, and I sort of found that out myself. Yum is much smarter about this than RPM apparently; if I do rpm -U Numeric-23.8-i386.rpm rpm refuses to replace python-numeric-23.7 as distributed with FC4, but "yum install Numeric" when pointed at my local repo works fine. As does "rpm -i --force" of course. There is at least a verbal commitment at bugzilla.redhat.com from Redhat to migrate pygtk2 to the new array object when it comes out.