matplotlib-devel Mailing List for matplotlib

Hello,
This is fairly minor, but I'd wonder if you'd consider including it.
It adds an optional Fc parameter to the specgram method of the Axes
class, and makes the calculation of the extent a bit more efficient.
Also, a quick fix for mlab.py.
Thank you,
Glen Mabey

On Tuesday 13 November 2007 09:30:52 am John Hunter wrote:
> On Nov 13, 2007 8:01 AM, Darren Dale <dar...@co...> wrote:
> > On Monday 12 November 2007 06:39:28 pm Darren Dale wrote:
> > > On Monday 12 November 2007 05:52:55 pm John Hunter wrote:
> > > > On Nov 12, 2007 4:09 PM, Darren Dale <dar...@co...> 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 setup.cfg.template for the
> > > > > details.
> > > >
> > > > I just did a clean build and it went through -- a good start! I
> > > > tried enabling the new config with by setting NEWCONFIG = True in
> > > > __init__.py, and also enabled in setup.cfg
> >
> > I altered mplconfig to create a matplotlib.conf.template file, which gets
> > read and modified at build time like we do with matplotlibrc.template.
> > It's not as elegant as using the config package machinery to create the
> > default config file at build time, but I think this will serve our needs.
> > Devs still need to execute mplconfig.py when we make changes that would
> > affect the default config file.
> >
> > I also updated the selection of the default backend at build time:
> >
> > SVG -> Agg -> TkAgg -> WXAgg -> GTK -> GTKAagg -> selection in setup.cfg
>
> I'm not sure we need GTK in that pipeline, since its future status is
> in question and I think we'd rather have someone on tkagg or wxagg
> than plain vanilla gtk.
Done.
> I think in the autogen of matplotlib.conf, there are a few things you
> could do to make the file much more readable.
>
> * for the enumeration of options, print
>
> # 'bilinear' or 'nearest' or 'bicubic' or 'spline16' or 'spline36' or
> 'hanni # ng' or 'hamming' or 'hermite' or 'kaiser' or 'quadric' or 'catrom'
> or 'gau # ssian' or 'bessel' or 'mitchell' or 'sinc' or 'lanczos' or
> 'blackman'
>
> like
>
> # bilinear | nearest | bicubic | spline16 ....
That is a good suggestion. However, most of the formatting is done under the 
hood, by the Traits package itself. It looks like the logic is spread out 
over traits code so it won't be easy to subclass and override the default 
behavior.
However, when we define our own trait handlers, like we do with BackendHandler 
and BoolHandler, we define an "info" method which controls the formatting. If 
we end up committing to using Traits, and we started adding more complex 
validation and notification, etc., I think that would be the time to add 
additional TraitHandlers to improve the formatting.
> * For floating point numbers, use a str converter rather than a repr
> converter, eg '%s'
>
> In [4]: '%s'%0.1
> Out[4]: '0.1'
>
> In [5]: '%r'%0.1
> Out[5]: '0.10000000000000001'
This is also dictated by Traits.
I'll have to think some more about formatting. Right now, its not obvious to 
me that there is a simple solution, aside from defining TraitHandlers.
> * I think your wrap algorithm is breaking in the middle of words. You
> might look at cbook.wrap
>
> In [15]: s = 'A regular expression used to determine the amount of
> space to remove. It looks for the first sequence of spaces
> immediately following the first newline, or at the beginning of the
> string.'
>
> In [16]: print cbook.wrap('', s, 76)
> A regular expression used to determine the amount of space to remove. 
> It looks for the first sequence of spaces immediately following the first
> newline, or at the beginning of the string.
Thank you for noticing this, and for pointing out the solution in cbook. I 
updated tconfig in our repository and in ipython1.
Darren

On Nov 13, 2007 8:01 AM, Darren Dale <dar...@co...> wrote:
> On Monday 12 November 2007 06:39:28 pm Darren Dale wrote:
> > On Monday 12 November 2007 05:52:55 pm John Hunter wrote:
> > > On Nov 12, 2007 4:09 PM, Darren Dale <dar...@co...> 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 setup.cfg.template for the details.
> > >
> > > I just did a clean build and it went through -- a good start! I tried
> > > enabling the new config with by setting NEWCONFIG = True in
> > > __init__.py, and also enabled in setup.cfg
>
> I altered mplconfig to create a matplotlib.conf.template file, which gets read
> and modified at build time like we do with matplotlibrc.template. It's not as
> elegant as using the config package machinery to create the default config
> file at build time, but I think this will serve our needs. Devs still need to
> execute mplconfig.py when we make changes that would affect the default
> config file.
>
> I also updated the selection of the default backend at build time:
>
> SVG -> Agg -> TkAgg -> WXAgg -> GTK -> GTKAagg -> selection in setup.cfg
I'm not sure we need GTK in that pipeline, since its future status is
in question and I think we'd rather have someone on tkagg or wxagg
than plain vanilla gtk.
I think in the autogen of matplotlib.conf, there are a few things you
could do to make the file much more readable.
* for the enumeration of options, print
 # 'bilinear' or 'nearest' or 'bicubic' or 'spline16' or 'spline36' or 'hanni
 # ng' or 'hamming' or 'hermite' or 'kaiser' or 'quadric' or 'catrom' or 'gau
 # ssian' or 'bessel' or 'mitchell' or 'sinc' or 'lanczos' or 'blackman'
 like
 # bilinear | nearest | bicubic | spline16 ....
* For floating point numbers, use a str converter rather than a repr
converter, eg '%s'
 In [4]: '%s'%0.1
 Out[4]: '0.1'
 In [5]: '%r'%0.1
 Out[5]: '0.10000000000000001'
* I think your wrap algorithm is breaking in the middle of words. You
might look at cbook.wrap
 In [15]: s = 'A regular expression used to determine the amount of
space to remove. It looks for the first sequence of spaces
immediately following the first newline, or at the beginning of the
string.'
 In [16]: print cbook.wrap('', s, 76)
 A regular expression used to determine the amount of space to remove. It
 looks for the first sequence of spaces immediately following the first
 newline, or at the beginning of the string.
JDH

On Monday 12 November 2007 06:39:28 pm Darren Dale wrote:
> On Monday 12 November 2007 05:52:55 pm John Hunter wrote:
> > On Nov 12, 2007 4:09 PM, Darren Dale <dar...@co...> 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 setup.cfg.template for the details.
> >
> > I just did a clean build and it went through -- a good start! I tried
> > enabling the new config with by setting NEWCONFIG = True in
> > __init__.py, and also enabled in setup.cfg
I altered mplconfig to create a matplotlib.conf.template file, which gets read 
and modified at build time like we do with matplotlibrc.template. It's not as 
elegant as using the config package machinery to create the default config 
file at build time, but I think this will serve our needs. Devs still need to 
execute mplconfig.py when we make changes that would affect the default 
config file.
I also updated the selection of the default backend at build time:
SVG -> Agg -> TkAgg -> WXAgg -> GTK -> GTKAagg -> selection in setup.cfg
committed in svn-4242.
Darren

On Nov 4, 2007 1:06 PM, Boyd Waters <bw...@nr...> 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 libpng12_la-png.lo -MD -MP -MF
.deps/libpng12_la-png.Tpo -c png.c -fno-common -DPIC -o
.libs/libpng12_la-png.o
gcc-4.0: -E, -S, -save-temps and -M options are not allowed with
multiple -arch flags
But, following your suggestion, I built everything with :
 536 export ARCHFLAGS="-arch i386"
 537 export MACOSX_DEPLOYMENT_TARGET=10.5
 538 export CFLAGS="-arch i386"
 543 export LDFLAGS="-arch i386"
 546 export CXXFLAGS="-arch i386"
but am still getting a failure. command history and build output
below. It appears the failure is happening at link time when the
build tries to link. The code at
http://mail.python.org/pipermail/python-checkins/2006-June/054322.html
suggests that both platforms are being unconditionally added in the
ARCHLIST but I am not sure if that is relevant here. In any case, if
I could fix the libpng problem above, I wouldn't have to worry about
it.
============================================================================
BUILDING MATPLOTLIB
 matplotlib: 0.90.1
 python: 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1
 (Apple Computer, Inc. build 5341)]
 platform: darwin
REQUIRED DEPENDENCIES
 numpy: 1.0.4.dev4380
 freetype2: found, but unknown version (no pkg-config)
OPTIONAL BACKEND DEPENDENCIES
 Gtk+: no
 * Building for Gtk+ requires pygtk; you must be able
 * to "import gtk" in your build/install environment
 Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
 wxPython: 2.8.3.0
 * WxAgg extension not required for wxPython >= 2.8
 Qt: no
 Qt4: no
 Cairo: no
 libpng: found, but unknown version (no pkg-config)
OPTIONAL DATE/TIMEZONE DEPENDENCIES
 datetime: present, version unknown
 dateutil: matplotlib will provide
 pytz: matplotlib will provide
OPTIONAL USETEX DEPENDENCIES
 dvipng: no
 ghostscript: /bin/sh: gs: command not found
 latex: no
EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
 configobj: matplotlib will provide
 enthought.traits: matplotlib will provide
[Edit setup.cfg to suppress the above messages]
============================================================================
running build
running build_py
copying lib/matplotlib/mpl-data/matplotlibrc ->
build/lib.macosx-10.5-i386-2.5/matplotlib/mpl-data
running build_ext
building 'matplotlib.backends._tkagg' extension
C compiler: gcc -DNDEBUG -g -O3 -arch i386
compile options: '-I/System/Library/Frameworks/Tcl.framework/Headers
-I/System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders
-I/System/Library/Frameworks/Tk.framework/Headers
-I/System/Library/Frameworks/Tk.framework/Versions/Current/PrivateHeaders
-I/usr/local/include -I/usr/include -I. -Isrc -Iswig -Iagg23/include
-I. -I/usr/local/include -I/usr/include -I.
-I/System/Library/Frameworks/Tcl.framework/Headers/freetype2
-I/System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders/freetype2
-I/System/Library/Frameworks/Tk.framework/Headers/freetype2
-I/System/Library/Frameworks/Tk.framework/Versions/Current/PrivateHeaders/freetype2
-I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2
-Isrc/freetype2 -Iswig/freetype2 -Iagg23/include/freetype2
-I./freetype2 -I/usr/local/include/freetype2 -I/usr/include/freetype2
-I./freetype2 -I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5
-c'
extra options: '-framework Tcl -framework Tk'
g++ -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g
-bundle -undefined dynamic_lookup -arch i386 -arch i386
build/temp.macosx-10.5-i386-2.5/src/_tkagg.o
build/temp.macosx-10.5-i386-2.5/CXX/cxx_extensions.o
build/temp.macosx-10.5-i386-2.5/CXX/cxxsupport.o
build/temp.macosx-10.5-i386-2.5/CXX/IndirectPythonInterface.o
build/temp.macosx-10.5-i386-2.5/CXX/cxxextensions.o -L/usr/local/lib
-L/usr/lib -L/usr/local/lib -L/usr/lib -lpng -lz -lstdc++ -lm
-lfreetype -lz -lstdc++ -lm -o
build/lib.macosx-10.5-i386-2.5/matplotlib/backends/_tkagg.so
-framework Tcl -framework Tk
ld: warning in build/temp.macosx-10.5-i386-2.5/src/_tkagg.o, file is
not of required architecture
ld: warning in build/temp.macosx-10.5-i386-2.5/CXX/cxx_extensions.o,
file is not of required architecture
ld: warning in build/temp.macosx-10.5-i386-2.5/CXX/cxxsupport.o, file
is not of required architecture
ld: warning in build/temp.macosx-10.5-i386-2.5/CXX/IndirectPythonInterface.o,
file is not of required architecture
ld: warning in build/temp.macosx-10.5-i386-2.5/CXX/cxxextensions.o,
file is not of required architecture
ld: warning in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libpng.dylib,
file is not of required architecture
ld: warning in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libfreetype.dylib,
file is not of required architecture
ld: in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libPng.dylib,
file is not of required architecture for architecture ppc
collect2: ld returned 1 exit status
lipo: can't open input file:
/var/folders/qT/qTRms9cJHNqoYnbs9+TwVk+++TI/-Tmp-//ccnIc3Eg.out (No
such file or directory)
ld: warning in build/temp.macosx-10.5-i386-2.5/src/_tkagg.o, file is
not of required architecture
ld: warning in build/temp.macosx-10.5-i386-2.5/CXX/cxx_extensions.o,
file is not of required architecture
ld: warning in build/temp.macosx-10.5-i386-2.5/CXX/cxxsupport.o, file
is not of required architecture
ld: warning in build/temp.macosx-10.5-i386-2.5/CXX/IndirectPythonInterface.o,
file is not of required architecture
ld: warning in build/temp.macosx-10.5-i386-2.5/CXX/cxxextensions.o,
file is not of required architecture
ld: warning in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libpng.dylib,
file is not of required architecture
ld: warning in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libfreetype.dylib,
file is not of required architecture
ld: in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libPng.dylib,
file is not of required architecture for architecture ppc
collect2: ld returned 1 exit status
lipo: can't open input file:
/var/folders/qT/qTRms9cJHNqoYnbs9+TwVk+++TI/-Tmp-//ccnIc3Eg.out (No
such file or directory)
error: Command "g++ -arch i386 -arch ppc -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -g -bundle -undefined dynamic_lookup
-arch i386 -arch i386 build/temp.macosx-10.5-i386-2.5/src/_tkagg.o
build/temp.macosx-10.5-i386-2.5/CXX/cxx_extensions.o
build/temp.macosx-10.5-i386-2.5/CXX/cxxsupport.o
build/temp.macosx-10.5-i386-2.5/CXX/IndirectPythonInterface.o
build/temp.macosx-10.5-i386-2.5/CXX/cxxextensions.o -L/usr/local/lib
-L/usr/lib -L/usr/local/lib -L/usr/lib -lpng -lz -lstdc++ -lm
-lfreetype -lz -lstdc++ -lm -o
build/lib.macosx-10.5-i386-2.5/matplotlib/backends/_tkagg.so
-framework Tcl -framework Tk" failed with exit status 1

On Nov 12, 2007 1:19 PM, John Hunter <jd...@gm...> wrote:
> On Nov 12, 2007 12:15 PM, Eric Firing <ef...@ha...> 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, should all of these be exposed in the pylab namespace?
> > Do we have or need any quality-control standards for these functions?
> > Is there a point in exposing more of mlab now than we have in the past?
> > Probably so, but we might want to be conservative about it.
>
> One could argue that everything there belongs somewhere else: the load
> and save and record array loaders and saves belong in scipy.io, the
> numerical codes belong in scipy or numpy or some sandbox, some of the
> stuff could just be scrapped as a relic of the past. I don't have a
> bone to pick with that argument, but I do have a practical concern: I
> am not a numpy/scipy committer and don't really have the time to
> become one and it is easier for me to put them into mpl (where I
> understand the code organization, build process, commit protocol,
> tests, etc much better) than to go through a numpy or scipy patch
> development and submission process.
>
> I am more than happy for any of this code to end up there and be
> pulled from mpl. In the past, I've offered this to Travis and he has
> taken me up on it for some functions, and the same goes for any other
> user or developer who has strong feelings on how these codes should be
> organized. Having taught several courses of "scientific computing for
> python" I am certainly aware of and sympathetic to the complaint that
> it is difficult to know where to find stuff in the support packages
> for scientific computing. I am all in favor of getting as much useful
> stuff into numpy and scipy and organized and documented -- it's just
> not likely to be me who is the one doing it, just from a time
> standpoint. So I currently tend to use cbook and mlab as a place for
> code I develop that is generally useful and is not available in numpy
> or scipy.
Hey John,
I am willing to commit to helping migrating the relevant mlab code
over to SciPy (or NumPy). The next release of SciPy
(http://projects.scipy.org/scipy/scipy/milestone/0.7) may be pushed
back a little, but it should be out by February at the latest. One of
the things I had been planning to work on for this release was going
over the various scipy.io code anyway.
I probably won't get a chance to take a close look at things until
December, but I thought I would mention it in case it has any impact
on your own plans.
Thanks,
-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/