On Nov 4, 2007 1:06 PM, Boyd Waters <[EMAIL PROTECTED]> wrote:
> I believe that "generic" autoconf would pick up CFLAGS:
>
> CFLAGS="-arch ppc -arch i386"
Worked for zlib and freetype, but failed for libpng with:
gcc -DHAVE_CONFIG_H -I. -I. -I. -DPNG_CONFIGURE_LIBPNG -arch ppc
-arch i386 -MT li
On Nov 12, 2007 1:19 PM, John Hunter <[EMAIL PROTECTED]> wrote:
> On Nov 12, 2007 12:15 PM, Eric Firing <[EMAIL PROTECTED]> wrote:
> > On a more strategic note: what do you see as the future of mlab, and its
> > place in pylab? Should mlab contain every neat function we can think
> > of, and if so
On Monday 12 November 2007 05:52:55 pm John Hunter wrote:
> On Nov 12, 2007 4:09 PM, Darren Dale <[EMAIL PROTECTED]> wrote:
> > I have been updating the logic in our setup.py and setupext.py files, so
> > all of the build options are now exposed in setup.cfg. This should make
> > it easier for anyo
On Nov 12, 2007 4:09 PM, Darren Dale <[EMAIL PROTECTED]> wrote:
> I have been updating the logic in our setup.py and setupext.py files, so all
> of the build options are now exposed in setup.cfg. This should make it easier
> for anyone wishing to distribute matplotlib, like package managers. See
>
I have been updating the logic in our setup.py and setupext.py files, so all
of the build options are now exposed in setup.cfg. This should make it easier
for anyone wishing to distribute matplotlib, like package managers. See
setup.cfg.template for the details.
There are a few changes. The ext
On Nov 12, 2007 12:15 PM, Eric Firing <[EMAIL PROTECTED]> wrote:
> In your list, "load" is duplicated.
Thanks, purged.
> On a more strategic note: what do you see as the future of mlab, and its
> place in pylab? Should mlab contain every neat function we can think
> of, and if so, should all of
Michael Droettboom wrote:
> John Hunter wrote:
>> On Nov 9, 2007 1:12 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>>
>>> I've committed my changes on the transforms branch so you can play with
>>> it -- I'm holding off on changing the trunk due to the pending release.
>>> But if everyone agre
John,
In your list, "load" is duplicated.
It would be nice if numpy.rank could be deprecated, since it seems to be
an alias for ndim (which is more descriptive and less ambiguous). We
could avoid the name clash by using "matrixrank" for the mlab version.
I suggest that for every name that con
