matplotlib-devel Mailing List for matplotlib (Page 7)

On Nov 14, 2007 1:24 PM, Michael Droettboom <md...@st...> wrote:
> Coincidentally, I just noticed this myself, and fixed it (and renamed it
> to is_writable_file_like). There will be (once I commit), and handful
> of places that use it.
By the way, your changes to make all the backends support writing to
file-like objects is really nice. This is a *long* standing request,
particularly for web application developers, and will be very useful.
I was never able to figure out how to trick libpng into doing what I
wanted.
JDH

John Hunter wrote:
>> At the same time, I notice that cbook.is_file_like is identical to
>> is_string_like. This seems worse than useless to me. If we are going
>> to have "is_file_like" then it should do something like check for read
>> and write methods.
> 
> This looks like a bug. No other part of the code even calls it, so I
> removed it and noted it in API CHANGES
Coincidentally, I just noticed this myself, and fixed it (and renamed it 
to is_writable_file_like). There will be (once I commit), and handful 
of places that use it.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Nov 14, 2007 12:57 PM, Eric Firing <ef...@ha...> wrote:
> step_demo is failing because of this:
>
> In [4]:xx = numpy.ma.ones((2,3))
>
> In [5]:xx + ''
> Out[5]:array(NotImplemented)
>
A couple of days ago I was cleaning up references to Numeric and
numarray, and came across this
def is_string_like(obj):
 if hasattr(obj, 'shape'): return 0 # this is a workaround
 # for a bug in numeric<23.1
 try: obj + ''
 except (TypeError, ValueError): return 0
 return 1
Since we were no longer supporting Numeric, I figured this was
obsolete, and removed the hasattr check. It looks like we need it
still, so I readded it to svn
> Or, maybe there are places where we need to be using
> isinstance(x, (str, unicode))
> instead. Are there really cases where we need to detect something that
> is not a subclass of str or unicode, but that we can and should still
> treat as a string?
Yes, this comes up occasionally for people who have custom string
classes. With the exception of my recent "fix", it has been quite
robust.
> At the same time, I notice that cbook.is_file_like is identical to
> is_string_like. This seems worse than useless to me. If we are going
> to have "is_file_like" then it should do something like check for read
> and write methods.
This looks like a bug. No other part of the code even calls it, so I
removed it and noted it in API CHANGES
JDH

step_demo is failing because of this:
In [4]:xx = numpy.ma.ones((2,3))
In [5]:xx + ''
Out[5]:array(NotImplemented)
which makes cbook.is_string_like(xx) return True. This is a pitfall of 
duck-typing--sometimes something that quacks like duck is not a duck at all.
I can get back to this later, but maybe someone else can quickly think 
of a better non-hackish duck-typing test to use in is_string_like.
Or, maybe there are places where we need to be using
isinstance(x, (str, unicode))
instead. Are there really cases where we need to detect something that 
is not a subclass of str or unicode, but that we can and should still 
treat as a string?
At the same time, I notice that cbook.is_file_like is identical to 
is_string_like. This seems worse than useless to me. If we are going 
to have "is_file_like" then it should do something like check for read 
and write methods.
Eric

On Wed, Nov 14, 2007 at 08:59:15AM -0600, John Hunter wrote:
> Glen, this looks fairly benign (the center frequency bit) so I am
> happy to add it, but could I trouble you to make similar patch the
> other spectral methods as well (eg psd, csd and cohere) for the sake
> of consistency in the API?
Relax, patch attached.
Also, I am getting an error in numerix/__init__.py when it gets imported
by a script that is run by apache. Apparently, sys.argv has length 0,
so "del a" on line 38 fails.
Thanks,
Glen

On Nov 12, 2007 8:35 PM, Jarrod Millman <mi...@be...> wrote:
> 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, for the offer. I did another read-through of the mlab
stuff and it doesn't look like an unreasonable amount of work since a
lot of it is already deprecated. Some of it is geometry, like tests
whether segments intersect and that kind of thing, and belong in mpl
but probably another module. psd and csd will be needed to support
the plotting functions, so they will have to be in numpy or maptlotlib
since we don't rely on scipy. Some of the io stuff can go into scipy
or numpy. We'll reconvene in December when you have more time...
JDH

On Nov 14, 2007 8:00 AM, Michael Droettboom <md...@st...> wrote:
> I'll defer to others with more experience with specgram to assess the
> rest of your patch.
Glen, this looks fairly benign (the center frequency bit) so I am
happy to add it, but could I trouble you to make similar patch the
other spectral methods as well (eg psd, csd and cohere) for the sake
of consistency in the API?
JDH

The fix for mlab.py is obviously necessary, so I've committed it to SVN.
I'll defer to others with more experience with specgram to assess the 
rest of your patch.
Cheers,
Mike
Glen W. Mabey wrote:
> 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
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Thanks. This has been committed in SVN revision 4267, and will likely 
make it into the upcoming release.
Cheers,
Mike
Michael Zell wrote:
> Hi,
> 
> whenever I clicked the "save"-button in a plot in my TkAgg and pressed 
> "cancel" in the file dialog, I got the error message
> 
> Exception in Tkinter callback
> Traceback (most recent call last):
> File "lib-tk/Tkinter.py", line 1406, in __call__
> return self.func(*args)
> File 
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py", 
> line 641, in save_figure
> bname, fext = os.path.splitext(fname)
> File "posixpath.py", line 92, in splitext
> i = p.rfind('.')
> AttributeError: 'tuple' object has no attribute 'rfind'
> 
> This obviously happened because tkFileDialog.asksaveasfilename returned 
> an empty tupel rather than an empty string, when the user cancels the 
> file dialog. I fixed it by replacing the line
> 
> if fname == "":
> 
> by
> 
> if fname == "" or fname == ():
> 
> in the file backend_tkagg.py.
> 
> Thank you,
> Michael Zell
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,
whenever I clicked the "save"-button in a plot in my TkAgg and pressed 
"cancel" in the file dialog, I got the error message
Exception in Tkinter callback
Traceback (most recent call last):
 File "lib-tk/Tkinter.py", line 1406, in __call__
 return self.func(*args)
 File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py", 
line 641, in save_figure
 bname, fext = os.path.splitext(fname)
 File "posixpath.py", line 92, in splitext
 i = p.rfind('.')
AttributeError: 'tuple' object has no attribute 'rfind'
This obviously happened because tkFileDialog.asksaveasfilename returned 
an empty tupel rather than an empty string, when the user cancels the 
file dialog. I fixed it by replacing the line
if fname == "":
by
if fname == "" or fname == ():
in the file backend_tkagg.py.
Thank you,
Michael Zell

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/

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 was going to mask the NEWCONFIG stuff for the upcoming release, including 
providing the following packages:
> ## Experimental config package support:
> enthought.traits = True
> configobj = True
>
> I pulled my matplotlibrc file from ~/.matplotlib and dropped in a copy
> of site-packages/matplotlib/mpl-data/matplotlib.conf into
> ~/.matplotlib, and then tried to run simple_plot.py with
> --verbose-helpful. Here is the error I got:
[...]
> matplotlib.config.tconfig.TConfigInvalidKeyError: In config defined in
> file: '/home/titan/johnh/.matplotlib/matplotlib.conf'
> Error processing section: text
> These subsections are invalid : ['math']
> Valid subsection names : ['latex']
This is unrelated to the changes in the setup scripts.
It looks like config.mplconfig has been changed. The section name now is 
mathtext, not text.math. It is not possible to autocreate the matplotlib.conf 
files at build time, without requiring configobj and enthought.traits as 
external dependencies. Instead, the developers should get in the habit of 
running mplconfig.py as a script whenever we make changes to mplconfig, in 
order to update the default config file (I just did so). This should also be 
done immediately before any release that includes the new config package.
> I am attaching my setup.cfg as well as ~/.matplotlib/matplotlib.conf.
> I haven't made any changes to the [text] section that I know of....
>
> Note there is also the somewhat confusing line in the verbose output
>
> loaded rc file
> /home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/mpl-data/matpl
>otlibrc
When the config package encounters a matplotlibrc file but not a 
matplotlib.conf file, it reads the rc file and creates a .conf file. The 
message must have been printed during that process.
> One other minor suggestion: you probably want to include the VERBOSE
> setting from setup.py in the cfg file. One of the things we want to
> get to here is to allow developers to tweak their local config w/o
> risking compromising the svn repository. I am frequently guilty of
> this: I may tweak some variable in setup.py to get the build I need,
> and then forget to unset it when I commit. If everything in the build
> is configurable from a file that doesn't live in svn, we won't have
> this problem. In the same vein, if you can make setup.cfg handle the
> NEWCONFIG setting, this would be ideal. I realize this is tricky
> because at runtime you don't know which config file to read until you
> have your config, so don't worry about it if it is too tricky. One
> possibility while we are in development testing phase would be assume
> NEWCONFIG if ~/.matplotlib/matplotlib.conf exists.
Done. The last option is disabling compilation of the image extension module. 
Should that still be optional?
Darren

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
## Experimental config package support:
enthought.traits = True
configobj = True
I pulled my matplotlibrc file from ~/.matplotlib and dropped in a copy
of site-packages/matplotlib/mpl-data/matplotlib.conf into
~/.matplotlib, and then tried to run simple_plot.py with
--verbose-helpful. Here is the error I got:
johnh@flag:examples> python simple_plot.py --verbose-helpful
$HOME=/home/titan/johnh
CONFIGDIR=/home/titan/johnh/.matplotlib
matplotlib data path
/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/mpl-data
loaded rc file /home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/mpl-data/matplotlibrc
$HOME=/home/titan/johnh
CONFIGDIR=/home/titan/johnh/.matplotlib
matplotlib data path
/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/mpl-data
loaded rc file /home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/mpl-data/matplotlibrc
Traceback (most recent call last):
 File "simple_plot.py", line 6, in ?
 from pylab import *
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/pylab.py",
line 1, in ?
 from matplotlib.pylab import *
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/__init__.py",
line 714, in ?
 from config import rcParams, rcdefaults
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/config/__init__.py",
line 10, in ? from mplconfig import rcParams, mplConfig,
save_config, rcdefaults
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/config/mplconfig.py",
line 488, in ?
 filePriority=True)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/config/tconfig.py",
line 561, in __init__
 self.tconf = configClass(self.fconfCombined,monitor=monitor)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/config/tconfig.py",
line 425, in __init__
 section = v(sec_config,self,monitor=monitor)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/config/tconfig.py",
line 400, in __init__
 raise TConfigInvalidKeyError(m)
matplotlib.config.tconfig.TConfigInvalidKeyError: In config defined in
file: '/home/titan/johnh/.matplotlib/matplotlib.conf'
Error processing section: text
These subsections are invalid : ['math']
Valid subsection names : ['latex']
I am attaching my setup.cfg as well as ~/.matplotlib/matplotlib.conf.
I haven't made any changes to the [text] section that I know of....
Note there is also the somewhat confusing line in the verbose output
loaded rc file /home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/mpl-data/matplotlibrc
Thoughts?
One other minor suggestion: you probably want to include the VERBOSE
setting from setup.py in the cfg file. One of the things we want to
get to here is to allow developers to tweak their local config w/o
risking compromising the svn repository. I am frequently guilty of
this: I may tweak some variable in setup.py to get the build I need,
and then forget to unset it when I commit. If everything in the build
is configurable from a file that doesn't live in svn, we won't have
this problem. In the same vein, if you can make setup.cfg handle the
NEWCONFIG setting, this would be ideal. I realize this is tricky
because at runtime you don't know which config file to read until you
have your config, so don't worry about it if it is too tricky. One
possibility while we are in development testing phase would be assume
NEWCONFIG if ~/.matplotlib/matplotlib.conf exists.
JDH
JDH

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 external packages kept in lib/ now report "-mpl" 
in their versions. Past version provided by matplotlib will be identified and 
updated on future installs. It is also possible to disable the installation 
of these external packages, details are listed in setup.cfg.template.
Finally, building of extension modules like gtkagg and gdk can be enabled, 
disabled, or attempted regardless of missing dependencies, in which case the 
build will fail with a meaningful error message.
Please upgrade your svn repository and report any problems, so they dont show 
up after cutting the next release.
Thanks,
Darren

On Nov 12, 2007 12:15 PM, Eric Firing <ef...@ha...> 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 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.
Generally I use cbook as a repository of general purpose helper
functions and classes. mlab started life as a repository of matlab
compatible functions to supplement those in Numeric's MLab and it has
morphed into something a bit looser than that: something like a cbook
for stuff with numerical content.
Some of the code that started life in mlab has been moved over into
numpy (polyfit, polyval, ...) and is now deprecated, some of it serves
the plotting functions (cohere, psd, hist, ...), some of it provides a
matlab-like function that clashes with a numpy function of the same
name (load), some of it is just helper code written primarily by
Fernando, me and others that didn't have a better home( eg, Fernando's
code lived in ipython for a while and then he contributed it to mlab)
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.
Since we are making good progress with cleaning up the namespaces
inside mpl and in the examples and in the import layer (eg pyplot), I
am happy to *minimize* the contribution of mlab to the pylab
namespace. In my scripts I get only "figure", "close" and "show" from
pylab anyway so it won't affect me. If we want to stick to the
original view of mlab as a repository of matlab-like functions not in
scipy or numpy, we can prune the stuff it provides to pylab
significantly. I'm also happy to split stuff out of mlab into a
different module for clarity if you or others think that would be
useful ( I did that originally adding the rec* functions to
"recutils", but reverted thinking it would be preferable to add to an
existing module than create another one)
As for tests and quality control, I'm open to suggestions. For most
things, I tend to write an example and add it to the backend driver,
which is a test on "still runs" but generally not "runs correctly".
Certainly more unit tests would be welcome.
JDH

Michael Droettboom wrote:
> John Hunter wrote:
>> On Nov 9, 2007 1:12 PM, Michael Droettboom <md...@st...> 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 agrees on the way to expose this, it would be nice to
>>> merge this over to trunk before the release.
>>
>> Am I right in assuming that the only thing we lose in this approach is
>> faceting (which Eric hates but others may care about)? Since it is
>> orders of magnitudes faster, we could have a pcolor_faceted which
>> pcolor calls the old function if shading='faceted'. Of course the two
>> functions would return different types (image vs patch collection)
>> which is potentially a bit confusing.... We could play with adding
>> faceting to images....
> 
> pcolor can draw an arbitrary quadmesh (see quadmesh_demo.py, which uses 
> pcolor), where the edges of the quadrilaterals are not necessarily 
> parallel to the x or y axes. The NonUniformImage stuff requires that 
> the quadrilaterals are axis-aligned rectangles. To put it another way, 
> the X and Y arrays (that define the mesh) can be 2-dimensional for 
> pcolor, but only 1-dimensional for (the new) imshow.
> 
> pcolormesh, AFAICT, is more-or-less functionally equivalent to pcolor, 
> but uses optimized quadmesh drawing under the hood, rather than a 
> PolyCollection. (Though the comments hint at subtle differences related 
> to masking.)
> 
> But you are right -- NonUniformImage does not support outlining each 
> quadrilateral -- though that may not be hard to add if needed.
> 
> The difference in return types is perhaps an argument for 
> NonUniformImages going in imshow, not pcolor. (I was thinking only of 
> ease of implementation...)
> 
> Cheers,
> Mike
> 
Mike,
I have looked at NonUniformImage and found that although in the 
extension code it is called "pcolor", it is not doing the right thing 
for pcolor; and I think not quite the right thing for anything 
"image-like" either. For the latter, the problem is that it 
extrapolates the edges out indefinitely. I can't think of any 
circumstance in which this would be desirable. For the former, which is 
the application that really interests me, this extrapolation is one 
problem, but worse than that, it does not allow easy specification of 
the rectangle *boundaries*, which is what pcolor really needs. So, it 
is a strange hybrid.
I thought I might simply make a modified version to do what pcolor 
really needs, but between general distraction and floundering in C++ I 
have not succeeded, although it looks like it should be very 
easy--especially for someone comfortable with C++ and Agg, which I am 
not. So, if you can get to it, that would be great. If not, I can 
probably do it within a week or two.
The pcolor variant of the nonuniform image code should accept as X and Y 
vectors giving the *boundaries* of the rectangles, so they should have 
lengths 1 greater than the corresponding dimensions of the color array. 
 Any pixels that are not within the rectangles should be given the 
background color, so this needs to be passed in as well, just as it is 
for the regular image initializer.
I will discuss higher level API questions later.
Eric

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 conflicts with a numpy name, the 
docstring should make this explicit.
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.
I am copying this to the devel list; it seems worth wider exposure.
Eric
John Hunter wrote:
> On Nov 9, 2007 12:09 AM, Eric Firing <ef...@ha...> wrote:
> 
>>> from pyplot import *
>>> from matplotlib.mlab import *
>> for mlab I would be inclined to use an explicit list for the sake of
>> documentation and clarity, if nothing else.
> 
> One of my colleagues using svn just got bitten because she was using
> pylab load and save, which have slightly different semantics than
> numpy's. In particular, we have an optional converter dictionary. It
> would be nice to reconcile these (Travis has already borrowed a fair
> amount from mlab which is why so many funcs are deprecated).
> 
> Here is my candidate list, which I will commit shortly but let me know
> if you have a problem with any of it:
> 
> from matplotlib.mlab import load, window_hanning, window_none, conv,
> detrend, demean, \
> detrend_mean, detrend_none, detrend_linear, entropy, normpdf, levypdf, \
> find, longest_contiguous_ones, longest_ones, prepca, prctile,
> prctile_rank, \
> center_matrix, rk4, bivariate_normal, get_xyz_where,
> get_sparse_matrix, dist, \
> dist_point_to_segment, segments_intersect, fftsurr, liaupunov, movavg, \
> save, load, slopes, stineman_interp, inside_poly, poly_below,
> poly_between, exp_safe, \
> amap, rms_flat, l1norm, l2norm, norm_flat, frange,
> diagonal_matrix, identity, \
> base_repr, binary_repr, log2, ispower2, fromfunction_kw, rem,
> norm, orth, rank, sqrtm,\
> mfuncC, approx_real, rec_append_field, rec_drop_fields, rec_join,
> csv2rec, rec2csv

On Sunday 11 November 2007 7:08:38 pm Andrew Straw wrote:
> Eric Firing wrote:
> > Darren Dale wrote:
> >> 3) We can not include traits-3 without either adding setuptools as an
> >> external dependency (which is already true for python-2.3 users) or
> >> monkey-patching distutils. traits-3 includes some pyrex code, which
> >> standard distutils does not recognize.
> >
> > Is it a viable alternative to add pyrex as an external dependency?
> > Pyrex.Distutils makes it easy to use pyrex modules via otherwise
> > standard setup.py scripts. And pyrex itself is pure python, very easy
> > to install.
>
> We can also just package the .c file built by Pyrex whenever the
> developer changes the .pyx file. That way, there is no further
> infrastructure to include. On the other hand, as Darren suggested later,
> one can do what setuptools' build_ext command does without setuptools
> (if an extension source ends in .pyx, call pyrexc on it. If pyrexc is
> not available, skip that step. In both cases, then compile the .c file
> with the c compiler.) Darren, if you're still having trouble with this,
> I can dig up the old code I had that did this (I switched to setuptools
> for this, and other stuff, a long time ago).
Thanks for the offer. For now, I think it is best that we use traits-2.6, 
which doesnt have any pyrex code. Once traits-3 stabilizes and is released, 
I'll try what you have suggested.
Darren

Eric Firing wrote:
> Darren Dale wrote:
> 
>
>> 3) We can not include traits-3 without either adding setuptools as an external 
>> dependency (which is already true for python-2.3 users) or monkey-patching 
>> distutils. traits-3 includes some pyrex code, which standard distutils does 
>> not recognize.
>> 
>
> Is it a viable alternative to add pyrex as an external dependency? 
> Pyrex.Distutils makes it easy to use pyrex modules via otherwise 
> standard setup.py scripts. And pyrex itself is pure python, very easy 
> to install.
> 
We can also just package the .c file built by Pyrex whenever the 
developer changes the .pyx file. That way, there is no further 
infrastructure to include. On the other hand, as Darren suggested later, 
one can do what setuptools' build_ext command does without setuptools 
(if an extension source ends in .pyx, call pyrexc on it. If pyrexc is 
not available, skip that step. In both cases, then compile the .c file 
with the c compiler.) Darren, if you're still having trouble with this, 
I can dig up the old code I had that did this (I switched to setuptools 
for this, and other stuff, a long time ago).

Hello,
I was using the "configure subplots" dialog a lot recently to precisely 
resize my plots, and I noticed that often when I changed a slider only 
slightly (say by 1 pixel), the numeric value displayed next to the 
slider wouldn't change, because its precision was too low. So, I 
modified the code to display 3 decimal places instead of just 2. Now, 
every change to the slider always causes a visible change in the 
displayed subplot param value. This makes it easy to precisely set your 
subplot params to be the same as other plots, using the gui.
I've attached the short patch.
I've only tested this in wxagg under win32. It's possible that on 
another platform there might be less space to display the extra digit, 
and it might get cut off, but I think that's unlikely.
Cheers,
Martin