matplotlib-devel Mailing List for matplotlib

Hi,

My research is in computational fluid dynamics (specifically, the
meteorologies of planetary atmospheres).  Working contour and vector plots
in matplotlib would make it possible for me to make 2D meteorological maps
of atmospheric layers, etc.

I noticed for the first time in the goals page that contour plots are
being worked on, apparently by STSci.  I have been considering
implementing these two plot types as sets of line collections, but now
that I know contour plots are being worked on, and vector plots are
simpler to implement (in 2D), I will work on making vector plots.  The
mathematics is fairly straightforward.  I just need to learn how to use
the class library.

About contour plots, however, I have a couple of questions.  How is it
being implemented?  I was about to try to write a marching squares
contouring routine, although it might have been painfully slow in Python.
Does anyone have experience with this?

Cheers,
Curtis

Hey John,

I've added code to ipython to wrap use() to prevent users from switching 
backends interactively, since this will instantly crash things badly.  It's a 
nice example of how python's dynamic nature allows you to tweak a module from 
the outside, without having to poke at its source.  I now see could have done 
this for the show() problem as well, since it's essentially the same logic, so 
I shouldn't really have bothered you with source changes to the backends. 
Well, at least it was done in a generic way and not slapping code all over 
many files...

With this safety in place, I tried running ALL the examples in 0.63 to see how 
we fare.  I compiled some notes along the way, here they are for your (and 
other user's) reference.

I think we're doing pretty good, except that people can always kill themselves 
by running true WX/GTK apps via @run.  IPython is really not made for this, it 
can only handle gracefully show() calls from pure matplotlib scripts, not 
full-blown GUI apps.  But I think we have a very reasonable environment at 
this point for most usage cases.

Cheers,

f

#############################################################################

matplotlib examples under iypthon -pylab
----------------------------------------

I ran all the examples in mpl 0.63 with ipython (CVS from Sept 29/04, post
0.6.4.rc1).  This was done using 'run foo.py', to see how robust this is.
Most examples run fine, and leave ipython usable afterwards.  Those listed
below had some type of problem.

Platform notes: Fedora core 2, python 2.3.3, Numeric 23.5, matplotlib 0.63
compiled only with Numeric (no numarray) support.

// These don't run with LANG==de_DE.UTF-8, but are OK with en_US.UTF-8
run date_demo_convert.py
run date_demo1.py
run date_demo2.py
run date_demo_rrule.py
run finance_demo.py

// these two run but segfault on exit under ipython.  They run OK from a cmd line.
run dynamic_demo_wx.py      # this one runs, segfaults on exit
run dynamic_image_wxagg.py  # this one runs, segfaults on exit

// OK with GTKAgg backend. It needs a use('GTKAgg') call to be safe for other
backends.
run dynamic_image_gtkagg.py #

// these are OK with gtkagg, but they segfault wxagg.  The segfault happens
from a normal command line as well (no ipython).

run system_monitor.py
run dynamic_demo.py

// these block ipython/pylab - any embedded true Wx/gtk stuff will kill 
ipython badly. What should we do here?

run print_stdout.py
run object_picker.py
run embedding_in_gtk2.py
run embedding_in_gtk.py
run embedding_in_tk.py
run embedding_in_wx.py
run embedding_in_wx2.py
run embedding_in_wx3.py
run embedding_in_wx4.py
run mpl_with_glade.py

// other errors (not ipython related)


****run ftface_props.py
---------------------------------------------------------------------------
SystemError                               Traceback (most recent call last)

/home/fperez/code/python/pylab/examples/ftface_props.py
      68 print 'Mult. masters :', font.style_flags & 
FT_FACE_FLAG_MULTIPLE_MASTERS != 0
      69 print 'Glyph names   :', font.style_flags & FT_FACE_FLAG_GLYPH_NAMES 
      != 0
      70
---> 71 font.jdh = 'hi'
      72 print dir(font)

SystemError: error return without exception set
WARNING: Failure executing file: <ftface_props.py>



****run movie_demo.py:
with WX backend it doesn't make the .png frames at all
with WXAgg, it runs fine but fails to make the movie:
...
Saving frame _tmp049.png
Making movie animation.mpg - this make take a while
sh: line 1: mpeg2encode: command not found
convert: Delegate failed (mpeg2encode "%i" "%o").
convert: Delegate failed (mpeg2encode "%i" "%o") [No such file or directory].

Symlinking mpeg2encode to mpeg2enc (the real binary) doesn't help, a different
error comes back.

I got it to work by commenting out the convert call and reverting to the
mencoder one.  Great!



****run vertical_ticklabels.py

---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)

/home/fperez/code/python/pylab/examples/vertical_ticklabels.py
       3
       4 plot([1,2,3,4], [1,4,9,16])
       5 xticks([1,2,3,4], ['Frogs', 'Hogs', 'Bogs', 'Slogs'])
----> 6 set(t, 'rotation', 'vertical')
       7 show()

NameError: name 't' is not defined
WARNING: Failure executing file: <vertical_ticklabels.py>

John Hunter schrieb:

> Are the levels indicated above sufficient to cover the spectrum?  

They sound reasonable, though I'd almost prefer a numerical value (0-4) 
instead of the names.  Minor nit, though, feel free to ignore.

> What should the default be (either error or helpful)?  

Error.  Good command line tools stay silent when successful (I'm paraphrasing 
some well-known unix quote I don't have at hand)

> Should we add a command line flag to allow the user to override the
> default level for easy access to debug info?

Yes.

Good job.

f

I added a Verbose class to matplotlib.__init__ and some verbose
options to rc.  Quoting from rc

    # Set the verbose flags.  This controls how much information
    # matplotlib gives you at runtime and where it goes.  Ther verbosity
    # levels are: silent, error, helpful, debug, debug-annoying.  At the
    # error level, you will only get error messages.  Any level is
    # inclusive of all the levels below it.  Ie, if your setting is
    # helpful, you'll also get all the error messages.  If you setting is
    # debug, you'll get all the error and helpful messages.  It is not
    # recommended to make your setting silent because you will not even
    # get error messages.  When submitting problems to the mailing-list,
    # please set verbose to helpful or debug and paste the output into
    # your report.
    #
    #
    # The fileo gives the destination for any calls to verbose.report.
    # The erro gives the destination for any calls to
    # verbose.report_error.  These objects can a filename, sys.stderr, or
    # sys.stdout.  
    #
    # You can access the verbose instance in your code
    #   from matplotlib import verbose.
    verbose.level  : helpful     # one of silent, error, helpful, debug, debug-annoying
    verbose.fileo  : sys.stdout  # a log filename, sys.stdout or sys.stderr
    verbose.erro   : sys.stderr  # a log filename, sys.stdout or sys.stderr

In matplotlib code, you should no longer print to stdout or stderr;
rather you should do

    verbose.report('some message')
    verbose.report_error('some error message')

    #only report at debug levels or higher
    verbose.report('some message', 'debug')  

I haven't migrated all the matplotlib code yet, but I've gotten a
start.  I've made some changes to the code base already so that
typical causes of user problems are reported in the helpful mode.  Eg,

    hunter:~/python/projects/matplotlib> python examples/simple_plot.py -dWXAgg
    loaded rc file /hunter/jdhunter/python/projects/matplotlib/.matplotlibrc
    verbose.level helpful
    interactive False
    matplotlib version 0.63.4
    numerix Numeric 23.5
    font search path ['/usr/local/share/matplotlib']
    loaded ttfcache file /home/jdhunter/.ttffont.cache
    matplotlib data path /usr/local/share/matplotlib
    backend WXAgg version 2.4.2.4u


Backend authors, please set the string backend_version.  The default
is 'unknown'.  Eg in wx

    backend_version = wx.VERSION_STRING

Are the levels indicated above sufficient to cover the spectrum?  

What should the default be (either error or helpful)?  

Should we add a command line flag to allow the user to override the
default level for easy access to debug info?

Let me know if you have any comments or problems with the design or
implementation.

JDH

What's new in matplotlib-0.63.0

  Announce notes with links available at
  http://matplotlib.sf.net/whats_new.html

  * image interpolation works properly.  I think I have finally and
    for real this time fixed the image interpolation / edge effect
    bug.  It turns out there was a bug in antigrain (very unusual!)
    that was just found, fixed, and released.  I've incorporated the
    latest release into matplotlib, and after talking with the Maxim
    implemented a solution in matplotlib which fixes the edge problem
    w/o the view lim hack used previously.  Basically, I pad the edges
    of the input image.  This is described in more detail in the new
    examples/image_interp.py.  There is still an occasional off by 1
    rounding problem that causes a 1 pixel error (this is independent
    of the interpolation/edge bug).  

  * The dates handling is rewritten from the ground up, and now
    requires python2.3.  It makes extensive use of dateutil for date
    ticking.  All of your old date code will break, but it's an easy
    port.  In particular, note that the date tick location
    constructors now have a different meaning.  See
    http://matplotlib.sf.net/API_CHANGES,
    http://matplotlib.sf.net/matplotlib.dates.html, the updated date
    demos in examples/ and the new dates tutorial at
    http://matplotlib.sf.net/tutorial.html#dates.

  * setup.py now automatically detects Numeric, numarray or both, and
    compiles in the appropriate extension code.  Thus you can use
    matplotlib with either or both packages and still get the optimal
    performance.  So it is no longer necessary to set NUMERIX in
    setup.py, but it is necessary to have the extensions you want
    compiled available at the time you compile matplotlib.  The win32
    build is for numarray 1.1.

  * new functions xlim, ylim, xticks and yticks to make setting axis
    limits, tick locations and labels more natural and elegant.

  * Reorganized all python library code to lib/ subdir

  * Added print to file handle for backend agg; see
    examples/print_stdout.py.  Useful for webapp servers who want to
    print to a pipe.

  * x and y coords are printed in the toolbar on nouse motion in
    backends gtk* and tkagg (not implemented yet in wx*). You can set
    the axis attributes ax.fmt_xdata and ax.fmt_ydata with callable
    functions to control the formatting of the reported coords
    (default uses the major tick formatter).  See
    examples/coords_report.py and examples/date_demo1.py.

  * Added axhline, axvline, axhspan and axvspan for plotting lines and
    rectangles (spans) in mixed data/axes coords.  This is useful if
    for example, you want to provide a threshold line or range where
    the x range spans the axes (0-1 in axes coords) and the y range is
    given in data units.  See example/axhspan_demo.py.


Downloads at https://sourceforge.net/projects/matplotlib/

JDH

Hello:

Is anyone working on an Aquaterm backend for Mac OS X? (I did a search 
for Aquaterm on this list and didn't find anything.) If you haven't 
heard of Aquaterm, see:

http://aquaterm.sourceforge.net/index.shtml?page=a3

It is a standard Gnuplot terminal for Mac OS X. I believe that all the 
appropriate pieces are in place for a matplotlib backend: Aquaterm 
communicates via Distributed Objects, which can be accessed, I believe, 
by the newest revision of PyObjC. I've looked at an example Aquaterm 
adapter written in C and it looks accessible. Anyone else thinking 
about this?

Tom


http://kornack.com
Fundamental Symmetries Lab, Princeton University
609-716-7259 (h), 609-933-2186 (m), 609-258-0702 (w), 609-258-1625 (f)
Thomas Kornack, 157 North Post Road, Princeton Junction, NJ 08550-5009

>>>>> "Ingo" =3D=3D Ingo L=FCtkebohle <ilu...@gm...> writes:

    Ingo> Hi, a patch to compile the agg2 subdir with gcc 3.4 is on
    Ingo> sourceforge.

    Ingo> Background: The stricter template member-access checks in
    Ingo> gcc 3.4 break compilation of some agg2 headers.  The problem
    Ingo> occurs when a class derives from a templatized class and
    Ingo> access members of the base class.  Previously, the name of
    Ingo> the member was sufficient.  Now, access to members of the
    Ingo> base class has to be qualified with "this".

    Ingo> [I sent this mail earlier, with the patch attached, but it
    Ingo> never arrived.  Maybe mailman didn't like the attachment.
    Ingo> Sorry of you get duplicates.].

Sorry for the patch troubles.  matplotlib cvs has already upgraded to
agg22, which among other things is fixed to handle gcc 3.4.  I don't
have access to gcc 3.4 currently, so am unable to test matplotlib
compilation with agg22 with that version.

Could you give it a try and let me know?

Thanks!
JDH

Hi,

a patch to compile the agg2 subdir with gcc 3.4 is on sourceforge.

Background:  The stricter template member-access checks in gcc 3.4
break compilation of some agg2 headers.  The problem occurs when a
class derives from a templatized class and access members of the base
class.  Previously, the name of the member was sufficient.  Now,
access to members of the base class has to be qualified with "this".

[I sent this mail earlier, with the patch attached, but it never
arrived.  Maybe mailman didn't like the attachment.  Sorry of you get
duplicates.].

Ingo

>>>>> "thane" ==   <th...@ma...> writes:

    thane> I've got an alpha version of a .NET backend up and running
    thane> for matplotlib (http://matplotlib.sourceforge.net/ ).  It
    thane> was just intended to be "proof-of-concept" code, but it
    thane> works.

I'm certainly interested.  I don't know a lot about .Net.  Is your
backend an image backend or GUI one?  If the latter, are you using agg
for rendering ala tkagg, gtkagg, etc, or native .Net drawing?
Inquiring minds want to know.

    thane> This back end is targeted for anyone using PythonNet (see
    thane> http://www.zope.org/Members/Brian/PythonNet/index_html ).
    thane> It should also be compatible with IronPython (see
    thane> http://ironpython.com/) once the standard libraries and
    thane> Numarray (or Numeric) are available for the IronPython
    thane> release.

    thane> If there is any interest, please respond to this post and
    thane> I'll go through the trouble of adding it to the project (at
    thane> this point I don't know how to do this, so any guidance
    thane> here would be appreciated).

The standard procedure for submitting a backend is to send it to the
dev list, where I and other matplotlib developers can take it for a
test drive and submit feedback.

I'd be happy to give it a try.  If you have any extra instructions for
.Net dummies, please send them along with the code.

Cheers!
JDH


 

    thane> --Thane

 

    thane> Thane Plummer, Ph.D.

    thane> CEO Magna Capital, LLC

    thane> (520) 760-4957

    thane> (520) 405-2277 (cell)

    thane>  <mailto:th...@ma...> th...@ma...

    thane>  <http://www.magna-capital.com> www.magna-capital.com

 

 

I've got an alpha version of a .NET backend up and running for matplotlib
(http://matplotlib.sourceforge.net/ ).  It was just intended to be
"proof-of-concept" code, but it works.

 

This back end is targeted for anyone using PythonNet (see
http://www.zope.org/Members/Brian/PythonNet/index_html ).  It should also be
compatible with IronPython (see http://ironpython.com/) once the standard
libraries and Numarray (or Numeric) are available for the IronPython
release.

 

If there is any interest, please respond to this post and I'll go through
the trouble of adding it to the project (at this point I don't know how to
do this, so any guidance here would be appreciated).

 

--Thane

 

Thane Plummer, Ph.D.

CEO Magna Capital, LLC

(520) 760-4957

(520) 405-2277 (cell)

 <mailto:th...@ma...> th...@ma...

 <http://www.magna-capital.com> www.magna-capital.com 

 

 

On Sep 24, 2004, at 10:59 AM, John Hunter wrote:
>
> The other core features that would be nice to have but aren't
> absolutely critical are polar and contour.  I believe the stsci folks
> are working on contour.
>
Off and on, but indeed we are working on implementing contour plots.

Perry

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> My argument is that most other software I've looked at does
    Steve> this and it seems to work OK. I guess the reasons are that
    Steve> - it makes software packages smaller - you only need to
    Steve> directly download one copy of a package and do not
    Steve> indirectly download multiple copies of the same package.  -
    Steve> you can end up with multiple versions of a package. And
    Steve> later you may try to recall - which package x did I use to
    Steve> install package y?  - the software package that includes
    Steve> other packages needs to make sure it keeps up to date with
    Steve> with the included packages and does not install old
    Steve> versions.

Hi Steve,

Those are reasonable arguments.  I'm still convinced that it is better
to err on the side of simplifying the install, though.  matplotlib has
been distributing some of it's prereqs for some time (agg, pyparsing)
and not others (Numeric/numarray, freetype, libpng).  I try to balance
the likelihood the user already has the package on their system, the
additional ease/complexity of installation and coding, and package
size.  On balance, I decided to add pytz and dateutil to the
matplotlib src distro - I won't however, overwrite existing installs.

In the past we've included things (fontutils, ttfquery) that were
eventually removed because we found or wrote better replacements.  So
the matplotlib package size tends to fluctuate up and down a bit.
Currently, with src, fonts, icons, examples, example data, and add-on
packages, the src dist comes to 1.6M.  I can live with that.

    Steve> As a way to encourage more users how about working towards
    Steve> moving from the development status of version 0.62.4 "4 -
    Steve> Beta" to 1.0.0 "5 - Production/Stable".  What's the
    Steve> criteria for this step?  My understanding is that it does
    Steve> not mean that all desired features are implemented or
    Steve> complete, it just means that the software is stable, and
    Steve> matplotlib seems to be pretty stable already.

I'm amenable.  Do you know of instances where people aren't using
matplotlib due to it's version number or development status flag?

My working plan is to be mostly 2D feature complete for 1.0, but I am
not wed to this.  As you say, 1.0 really just implies some stability
rather than feature set.

The only thing off the top of my head that must be added before 1.0 is
a Users Guide - I should be done with this already, but alas...
Should be done in a month (I said that last month) I also think it
would also be nice to have a more streamlined, sophisticated configure
process.

The other core features that would be nice to have but aren't
absolutely critical are polar and contour.  I believe the stsci folks
are working on contour.

As for stability, there will probably be a significant refactoring of
the renderer drawing API at some point.  But I don't think this
precludes a 1.0 release.  As long as the matlab interface and OO
Figure/Axes/Text/Line/Patch interface is stable, and it largely is
discussed on the user's list), then I don't think it would break any
existing code to refactor the drawing model down the road.  As far as
I know, noone is directly using the renderer API, and I've never
advertised it.

JDH

>>>>> "Patrik" == Patrik Simons <pat...@ne...> writes:

    Patrik> Here's a proposed patch for the caching problem in
    Patrik> text.py.  (I'm sending it before someone actually adds
    Patrik> matplotlib.text.Text.cached = {} to, e.g.,
    Patrik> matlab.close(). Oh, the horror :-)

What happened when you put it there?

It's not clear to me where to me where that misplaced zero is coming
from.  Since the two figures are identical in size, I would think the
cached location of '0' from the first iteration of the loop would be
suitable for the second iteration.  Do you understand how this is
failing?

The main reason for the cache was for efficiency in animated plots.
Eg, if you are just updating the data in a plot and then redrawing,
you don't want to do all the number crunching for text layout.  With
rotated text and matrix operations to get the layout right, this can
get expensive.

I read over your patch.  I wonder if a simpler and cleaner solution
might just be to move the cached into the __init__ method.  Ie, make
it instance specific.  This would still provide the cache efficiency
for animated plots, but should fix the problem  you encountered.
It might also be less mind-bending than the solution you posted, at
least at this hour of the morning :-)

But I *would* like to understand how the current situation is
failing.  I note that it does not occur if you replace figure(1) with
figure(i+1).

JDH

Here's a proposed patch for the caching problem in text.py.
(I'm sending it before someone actually adds
matplotlib.text.Text.cached = {}
to, e.g., matlab.close(). Oh, the horror :-)

-- 
Patrik

Hi there,

matplotlib.text.Text._get_layout(self, renderer) caches
its return value in the dictionary matplotlib.text.Text.cached.
Since it is never emptied, it causes problems when one
creates many figures.

Below, t0.png is ok but t1.png has the vertical tick label 0 in the
wrong place.

import matplotlib
matplotlib.use('Agg')
from matplotlib.matlab import *

y = [[100, 250], [10, 25]]

for i in range(2):
    figure(1)
    bar([0,1], y[i])
    savefig('t%d.png' % i)
    # Uncomment to fix
    #matplotlib.text.Text.cached = {}
    close('all')

-- 
Patrik

John Hunter wrote:

>>>>>>"Steve" == Steve Chaplin <ste...@ya...> writes:
>>>>>>            
>>>>>>
>
>    Steve> My view is that a software package should not distribute
>    Steve> and install its own dependencies.  I think matplotlib
>    Steve> should have a list of dependencies (Python 2.2+, Numeric or
>    Steve> numarray, ...) which it requires before it attempts an
>    Steve> install, and a list of optional dependencies (pytz,
>    Steve> dateutil, ...) which matplotlib supports if it finds they
>    Steve> are already installed.
>
>What's your argument for this?
>
>My motivation to include them is mainly to simplify the install
>process, to have some control over versioning, and to simplify the
>coding process.  
>
I agree with JDH on this one.  Including extra pure-Python packages is 
not likely to cause (m)any problems:

1) on systems where people do lots of "python setup.py install" the 
definitive list of installed packages is the contents of site-packages
2) on systems with real package managers (e.g. Debian), this is for the 
package maintainer to worry about. those extra packages should be made 
package-level dependencies and not in the matplotlib.deb itself. (this 
assumes people on these systems are using the package manager.  if not, 
see point #1)
3) on Windows, you want to double click something that just works.

(In fact, by this reasoning, there's nothing against including mixed 
C/Python packages, either.)

On Tue, 2004-09-21 at 19:44, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> 
>     Steve> My view is that a software package should not distribute
>     Steve> and install its own dependencies.  I think matplotlib
>     Steve> should have a list of dependencies (Python 2.2+, Numeric or
>     Steve> numarray, ...) which it requires before it attempts an
>     Steve> install, and a list of optional dependencies (pytz,
>     Steve> dateutil, ...) which matplotlib supports if it finds they
>     Steve> are already installed.
> 
> What's your argument for this?
My argument is that most other software I've looked at does this and it
seems to work OK. I guess the reasons are that
- it makes software packages smaller
- you only need to directly download one copy of a package and do not
indirectly download multiple copies of the same package.
- you can end up with multiple versions of a package. And later you may
try to recall - which package x did I use to install package y?
- the software package that includes other packages needs to make sure
it keeps up to date with with the included packages and does not install
old versions.

> My motivation to include them is mainly to simplify the install
> process, to have some control over versioning, and to simplify the
> coding process.  Since these are pure python packages, they present no
Yes, this is an advantage of including everything, and a disadvantage
for minimal packages.

> Does your opinion change for the win32 installer?  In that case, we
> also include freetype, libpng, zlib.  I guarantee the numbers of win32
> users would drop significantly if they had to install these extra
> packages.  Neither dateutil nor pytz distribute a win32 installer.
> dateutil doesn't include a zip file (only a tar.bz file).  So win32
> users would first have to get bunzip2, and then tar, figure out how to
> use them, install, etc, just to get matplotlib date support.
Win32 could be a special case.

As a way to encourage more users how about working towards moving from
the development status of version 0.62.4 "4 - Beta" to 1.0.0 "5 -
Production/Stable".
What's the criteria for this step?
My understanding is that it does not mean that all desired features are
implemented or complete, it just means that the software is stable, and
matplotlib seems to be pretty stable already.

Regards,
Steve

On Tuesday 21 September 2004 11:54 am, Steve Chaplin wrote:
> My view is that a software package should not distribute and install its
> own dependencies.
> I think matplotlib should have a list of dependencies (Python 2.2+,
> Numeric or numarray, ...) which it requires before it attempts an
> install, and a list of optional dependencies (pytz, dateutil, ...) which
> matplotlib supports if it finds they are already installed.


I second that.

-- 

Darren Dale

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> My view is that a software package should not distribute
    Steve> and install its own dependencies.  I think matplotlib
    Steve> should have a list of dependencies (Python 2.2+, Numeric or
    Steve> numarray, ...) which it requires before it attempts an
    Steve> install, and a list of optional dependencies (pytz,
    Steve> dateutil, ...) which matplotlib supports if it finds they
    Steve> are already installed.

What's your argument for this?

My motivation to include them is mainly to simplify the install
process, to have some control over versioning, and to simplify the
coding process.  Since these are pure python packages, they present no
extra installation overhead for matplotlib and the only downside I see
is potential package bloat.  Both of these packages combined add 200k
to the src distro.  The coding burden is reduced, if for example I
know pytz is included, because I don't have to do a lot of conditional
stuff throughout the code where that module is used.

Does your opinion change for the win32 installer?  In that case, we
also include freetype, libpng, zlib.  I guarantee the numbers of win32
users would drop significantly if they had to install these extra
packages.  Neither dateutil nor pytz distribute a win32 installer.
dateutil doesn't include a zip file (only a tar.bz file).  So win32
users would first have to get bunzip2, and then tar, figure out how to
use them, install, etc, just to get matplotlib date support.

Basically, my goal is to maximize the likelihood that someone can use
matplotlib even if they haven't RTFM.  I wish they would read the
install instructions and dependencies, but I think that is only about
half of the users.  If we can set it up so that most things work out
of the box on a standard python setup - and I think having
Numeric/numarray) is fairly standard for most potential matplotlib
users.  

On a related note, Todd just added a fix in CVS that autodetects
numerix at build time and builds in Numeric and/or numarray.  It would
probably be a good idea to have an rc template and write the actual rc
file depending on what the autodetect finds in setup.py.  Eg, if setup
finds Tkinter and numarray but not pygtk and Numeric, there's not much
sense in using the default backend : GTKAgg and numerix : Numeric in
rc.  Paul did something like this for the license, so that the license
file was automatically built with the correct version number at build
time.


JDH

My view is that a software package should not distribute and install its
own dependencies. 
I think matplotlib should have a list of dependencies (Python 2.2+,
Numeric or numarray, ...) which it requires before it attempts an
install, and a list of optional dependencies (pytz, dateutil, ...) which
matplotlib supports if it finds they are already installed.

Regards,
Steve

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:

    Paul> Should I assume that the installed packages would have the
    Paul> same structure, i.e. lib/python2.3/site-packages/matplotlib/
    Paul> ? If yes, then I see no problem with this proposal.

Yes, the install paths would be unaffected.

JDH

John Hunter wrote:

>Many new users have been bitten by trying to run matplotlib from the
>matplotlib src dir, only to get an inscrutable error about not being
>able to find some extension code, as described in this FAQ
>http://matplotlib.sourceforge.net/faq.html#WRONGDIR.
>
>Recently, I've added pytz and dateutil for improved timezone and date
>ticking to the src distro.  I want to conditionally install these
>packages with matplotlib, only if the user hasn't installed them
>already.  So in setup.py, I do for example
>
>try: import dateutil
>except ImportError:
>    packages.append('dateutil')
>
>
>But I was bitten by the same bug.  Because dateutil was in the
>matplotlib root dir, it was imported successfully and not installed.
>
>My proposal is to move all the python library code into a lib subdir,
>which currently would look like
>
>  lib\matplotlib
>  lib\pytz
>  lib\dateutil
>
>and use package_dir = {'': 'lib'} in setup.py, which would fix both
>problems.
>
>Of course, I'll have to submit an admin request to sourceforge just to
>get the old dirs purged.  Sure would be nice if CVS supported basic
>rename and delete operations on directories.
>
>Comments, suggestions, objections...
>  
>
Should I assume that the installed packages would have the same 
structure, i.e. lib/python2.3/site-packages/matplotlib/ ? If yes, then I 
see no problem with this proposal.

 -- Paul

-- 
Paul Barrett, PhD      Space Telescope Science Institute
Phone: 410-338-4475    ESS/Science Software Branch
FAX:   410-338-4767    Baltimore, MD 21218

Many new users have been bitten by trying to run matplotlib from the
matplotlib src dir, only to get an inscrutable error about not being
able to find some extension code, as described in this FAQ
http://matplotlib.sourceforge.net/faq.html#WRONGDIR.

Recently, I've added pytz and dateutil for improved timezone and date
ticking to the src distro.  I want to conditionally install these
packages with matplotlib, only if the user hasn't installed them
already.  So in setup.py, I do for example

try: import dateutil
except ImportError:
    packages.append('dateutil')


But I was bitten by the same bug.  Because dateutil was in the
matplotlib root dir, it was imported successfully and not installed.

My proposal is to move all the python library code into a lib subdir,
which currently would look like

  lib\matplotlib
  lib\pytz
  lib\dateutil

and use package_dir = {'': 'lib'} in setup.py, which would fix both
problems.

Of course, I'll have to submit an admin request to sourceforge just to
get the old dirs purged.  Sure would be nice if CVS supported basic
rename and delete operations on directories.

Comments, suggestions, objections...

JDH

Hi,

I think I might have noticed an off by one bug in the pcolor and
pcolor_classic functions.  To replicate the problem:

from matplotlib.matlab import *
import Numeric
pcolor(Numeric.transpose(rand(2,2)))

** Note that although this is a 2x2 matrix the pcolor plot is rendered
   with only 1 square.  This problem scales.  The dimensions of the pcolor
   plots are always 1 less than they should be.

Changing line 1306 in axes.py  (I'm running the debian package ver. 0.61.0-2)

from:
  X, Y = meshgrid(arange(numCols), arange(numRows) )

to:
  X, Y = meshgrid(arange(numCols+1), arange(numRows+1) )

And I think similar change can fix pcolor_classic too.

This fixes the off-by-one problem when plotting arrays.   I haven't
thoroughly tested this, but I think it works in all cases.

  --chris.

PS.  Thanks for the nice work on matplotlib.

----------------------
Christopher Hart
Caltech Biology

In the generated documentation ( the doc string ) for scatter,
'octagon' is mispelled 'octogon'.   

S

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com