matplotlib-users Mailing List for matplotlib (Page 6)

I first opened GMail instead Google Reader and you show it to me first :D
I don't know half of those projection but I guess I would choose Plate Cartee :D

Cheers


On Mon, Nov 14, 2011 at 3:28 PM, Michael Droettboom <md...@st...> wrote:
> Sorry for the slightly OT post, but I thought all of the basemap-using
> geoprojection heads on this list would get a kick out of today's XKCD:
>
> http://xkcd.com/977/
>
> Mike
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

Thanks for the (two!) fast answers on the list. So there is hope :) I'll take a look at the fink internals, I guess. 
best wishes
Volker

On Nov 14, 2011, at 5:15 PM, Jeff Blackburne wrote:

> 
> On Nov 14, 2011, at 10:20 AM, Volker Blum wrote:
> 
>> ... just wanted to report this problem.
>> 
>> At the heart of the issue is the decision to have too many dependencies in matplotlib (which is why I am posting here). That, although viewed as good style, leads to an installation process that is, ultimately, practically impossible - except by buying a prepackaged solution. (which is possible but probably not the original intention)
>> 
>> What ultimately thwarts my installation attempts is the dependency on TeX. While a good thing in principle, most packaging tools do not realize that there is already a working TeX distribution there from another source, and will only accept their own - which, in the case of debian/fink, can no longer be postinstalled. It appears that I would have to uninstall and reinstall my entire pre-existing setup just to get matplotlib to work.
>> 
>> Has anyone seen this problem before? Is there a workaround?
>> 
>> best wishes
>> Volker Blum
> 
> Hi Volker,
> 
> I have installed matplotlib with Fink. I had a similar issue, because I didn't need to GTKAgg backend and didn't want to install all of the GTK+ packages that were required. I ended up making my own fink package called matplotlib-py27-nogtk by editing the matplotlib-py.info and matplotlib-py.patch files in my /sw/fink/10.6/unstable/main/finkinfo/sci directory, to remove the dependencies and turn off the GTK+ check in setup.py, respectively. I put the resulting files in /sw/fink/10.6/local/main/finkinfo. You could try something like that, although it's kind of messy.
> 
> There may also be a "virtual" fink package for TeX that doesn't install anything, but counts as a proxy for a previous installation. If this is true, it's a much better solution that what I did.
> 
> I hope this helps. If you need more info, I suspect that your question is actually better suited for the fink-users list.
> 
> Good luck,
> Jeff
> 

On Nov 14, 2011, at 10:20 AM, Volker Blum wrote:

> ... just wanted to report this problem.
> 
> At the heart of the issue is the decision to have too many dependencies in matplotlib (which is why I am posting here). That, although viewed as good style, leads to an installation process that is, ultimately, practically impossible - except by buying a prepackaged solution. (which is possible but probably not the original intention)
> 
> What ultimately thwarts my installation attempts is the dependency on TeX. While a good thing in principle, most packaging tools do not realize that there is already a working TeX distribution there from another source, and will only accept their own - which, in the case of debian/fink, can no longer be postinstalled. It appears that I would have to uninstall and reinstall my entire pre-existing setup just to get matplotlib to work.
> 
> Has anyone seen this problem before? Is there a workaround?
> 
> best wishes
> Volker Blum

Hi Volker,

I have installed matplotlib with Fink. I had a similar issue, because I didn't need to GTKAgg backend and didn't want to install all of the GTK+ packages that were required. I ended up making my own fink package called matplotlib-py27-nogtk by editing the matplotlib-py.info and matplotlib-py.patch files in my /sw/fink/10.6/unstable/main/finkinfo/sci directory, to remove the dependencies and turn off the GTK+ check in setup.py, respectively. I put the resulting files in /sw/fink/10.6/local/main/finkinfo. You could try something like that, although it's kind of messy.

There may also be a "virtual" fink package for TeX that doesn't install anything, but counts as a proxy for a previous installation. If this is true, it's a much better solution that what I did.

I hope this helps. If you need more info, I suspect that your question is actually better suited for the fink-users list.

Good luck,
Jeff

On Mon, Nov 14, 2011 at 9:20 AM, Volker Blum <bl...@fh...> wrote:

> ... just wanted to report this problem.
>
> At the heart of the issue is the decision to have too many dependencies in
> matplotlib (which is why I am posting here). That, although viewed as good
> style, leads to an installation process that is, ultimately, practically
> impossible - except by buying a prepackaged solution. (which is possible
> but probably not the original intention)
>
> What ultimately thwarts my installation attempts is the dependency on TeX.
> While a good thing in principle, most packaging tools do not realize that
> there is already a working TeX distribution there from another source, and
> will only accept their own - which, in the case of debian/fink, can no
> longer be postinstalled. It appears that I would have to uninstall and
> reinstall my entire pre-existing setup just to get matplotlib to work.
>
> Has anyone seen this problem before? Is there a workaround?
>
> best wishes
> Volker Blum
>
>
That is just bad packaging.  TeX is not a dependency, but optional.  Heck,
it isn't even listed in the "Build Requirements" page:
http://matplotlib.sourceforge.net/users/installing.html#build-requirements

Matplotlib can work just fine without TeX, you just wouldn't be able to set
usetex=True in some places.

Ben Root

... just wanted to report this problem.

At the heart of the issue is the decision to have too many dependencies in matplotlib (which is why I am posting here). That, although viewed as good style, leads to an installation process that is, ultimately, practically impossible - except by buying a prepackaged solution. (which is possible but probably not the original intention)

What ultimately thwarts my installation attempts is the dependency on TeX. While a good thing in principle, most packaging tools do not realize that there is already a working TeX distribution there from another source, and will only accept their own - which, in the case of debian/fink, can no longer be postinstalled. It appears that I would have to uninstall and reinstall my entire pre-existing setup just to get matplotlib to work.

Has anyone seen this problem before? Is there a workaround?

best wishes
Volker Blum

Sorry for the slightly OT post, but I thought all of the basemap-using 
geoprojection heads on this list would get a kick out of today's XKCD:

http://xkcd.com/977/

Mike

I'm not sure what MAMP is.  Usually this problem is because matplotlib 
is trying to import a GUI toolkit and the windowing environment is not 
available from the web server.  Try setting the matplotlib backend to 
"Agg", by putting this at the top of the file:

    import matplotlib
    matplotlib.use("Agg")

Mike

On 11/14/2011 05:13 AM, Paul de Beurs wrote:
> Hey,
>
> I work with Mac OSX 10.7.2
> I have a probleem. From the IDLE this little program works fine:
> #!/usr/bin/python
> import numpy
> import matplotlib
> print "Content-Type: text/plain\n"
> print matplotlib.__version__
>
> The output is:
> Content-Type: text/plain
>
> 1.1.0
>
> Starting this program from MAMP gives me:  Internal Server Error
>
> First I change the program into:
> #!/usr/bin/python
> import numpy
> import matplotlib
> print "Content-Type: text/plain\n"
> print 'No error'
>
> But starting this program from MAMP also gives me:  Internal Server Error
>
> Now I change my program into:
> #!/usr/bin/python
> import numpy
> ##import matplotlib
> print "Content-Type: text/plain\n"
> print 'No error'
>
> Now starting this program from MAMP gives me:  No error
>
> So the import of mapplotlib causes this troubles. I don't have these 
> problems with the import of numpy.
>
> Can someone help me with this problem?
>
>
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

This looks like a bug for the IPython folks.  If you make a file 
containing only "import gtk" and "%run" that file, one gets the same error.

Mike

On 11/13/2011 10:30 PM, Alejandro Weinstein wrote:
> Hi:
>
> I just installed matplolib from source code, and Ipython using pip, in
> Ubuntu 11.10.
>
> When I run this code
>
> ########### foo.py ############
> import matplotlib.pyplot as plt
> plt.plot([1,2,3,4])
> plt.ylabel('some numbers')
> plt.show()
> ##############################
>
> in ipython, I get the following warning:
>
> In [1]: %run foo.py
> /usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:54: Warning:
> ignoring sys.argv: it must be a list of strings
>    _gtk.init_check()
>
> Other than the warning the plot looks OK.
>
> Also, if I type each sentence in ipython, I don't get the warning. I
> don't get a warning if I use the standard python interpreter either
> (as in $ python foo.py).
>
> Any clue about this? Should I report this in the Ipython mailing list?
>
> I am running Ipython 0.11 and matplotlib 1.2.x.
>
> Alejandro
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

2011/11/14 Michael Droettboom <md...@st...>:
> Thanks for all the time you've devoted to this.  It does look like possibly
> some kind of compiler bug.  The font loads and renders fine on Linux, for
> what it's worth (just as a data point).
>
> To confirm this theory: if you move NISC1803.ttf somewhere temporary, delete
> ~/.matplotlibrc/fontList.cache and then import matplotlib, do you get the
> crash?  That at least confirms that loading this font file triggers the bug
> (wherever the bug may be).  Test with matplotlib 1.1.0 or git master so we
> have a sense of the current behavior.

Hi Mike,

the following fonts on my system are offending:

/Library/Fonts/NISC18030.ttf
/Library/Fonts/AppleMyungjo.ttf
/Library/Fonts/Gungseouche.ttf

With these fonts made unfindable by matplotlib (:file:`*.ttf_`) it
exits cleanly.

I will provide with a patch to matplotlib for an rc setting
"fonts.bus-error : ...", e.g. ``fonts.bus-error : NISC18030.ttf,
AppleMyungjo.ttf, Gungseouche.ttf`` in the next days.

It was clear from the beginning (well, from the point I got a handle
on it), that loading the font makes the 2009 matplotlib crash.  The
only question unanswered is where the codepath is that triggers this
compiler bug (I think the compiler but hypothesis is not disproven and
works well atm).  If the code path is in ft2font.cpp, we could (you
could) reformulate ft2font.cpp in an equivalent way with the exception
that it is not equivalent in crashing.  You might want to augment
ft2font.cpp by printf() or something to see if the crash appears
inside a call to libfreetype or if all those calls return cleanly.

To my understanding, since recompiling ft2font.so without
MACOSX_DEPLOYMENT_TARGET different from 10.6 helps, ft2font.cpp should
be the culprit resp. victim.  The only alternative I'm seeing would be
that it has to to do with the load mechanism of the dylib, but I deem
this rather unlikely.  Well, unlikely is not the best word in this
context, since all this things here were pretty unlikely.

If the codepath is in libfreetype this would be an issue for their list. ...

Friedrich

We should also update the checks for the version of Numpy.  Expect a 
pull request about this shortly.

Mike

On 11/12/2011 10:59 PM, Benjamin Root wrote:
>
>
> On Saturday, November 12, 2011, John Ladasky 
> <joh...@sb... <mailto:joh...@sb...>> wrote:
> > On Sat, 2011-11-12 at 20:08 -0600, Warren Weckesser wrote:
> >
> >> By any chance do you have a file called 'numpy.py' in the directory
> >> where you ran this?  If so, rename that file and try again.
> >
> > Hi, Warren,
> >
> > No, there is no file named "numpy.py" in the directory with my test
> > programs, or anywhere on my file system, for that matter.
> >
> >
> >
> > And here's a question that I've received off the list-serv, which the
> > author CC'ed to the list and thus should appear here soon:
> >
> > On Sat, 2011-11-12 at 20:03 -0600, Benjamin Root wrote:
> >
> >> Looks like mpl truly can't be used with older version of numpy.  Which
> > version are you using?
> >>
> >> Ben Root
> >
> > Hi Ben,
> >
> > Well, you made me look.  My numpy version is a few revisions behind.  I
> > have 1.3.0, and they're up to 1.6.1, which I just downloaded.  Still,
> > this page...
> >
> > 
> http://matplotlib.sourceforge.net/users/installing.html#build-requirements
> >
> > ...says that numpy 1.1 or later should work.
> >
> >
> >
> > Thanks to you both for your suggestions, I hope to figure this out.
> >
> >
>
> The doc page is wrong.  There was suspicions of this recently with 
> nextafter(), but no one knew when it was introduced in numpy.  Now we 
> know and I will update the page accordingly.
>
> Ben Root
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On 11/13/2011 10:03 AM, Goyo wrote:
> 2011/11/7 Anton Daitche<a.d...@go...>:
>
>> Do you remember the name of the thread? I would like to understand the
>> details on this.
> I can't find it right now but I guess Michael's answer helps you.
>
>> I also would like to find out if i can force the renderer to do exact
>> drawing (at some computational cost).
> Do you mean using an interactive backend? You can try gtkcairo and wx.
> I think they have their own issues though.
>
Or, as I suggested, use scatter() instead of plot().

Mike

Thanks for all the time you've devoted to this.  It does look like 
possibly some kind of compiler bug.  The font loads and renders fine on 
Linux, for what it's worth (just as a data point).

To confirm this theory: if you move NISC1803.ttf somewhere temporary, 
delete ~/.matplotlibrc/fontList.cache and then import matplotlib, do you 
get the crash?  That at least confirms that loading this font file 
triggers the bug (wherever the bug may be).  Test with matplotlib 1.1.0 
or git master so we have a sense of the current behavior.

Mike

On 11/13/2011 06:05 PM, Friedrich Romstedt wrote:
> 2011/11/12 Friedrich Romstedt<fri...@gm...>:
>> $ stat -f "...." /Library/Fonts/NISC18030.ttf
>> Last accessed or modified: 1321107464 = 12 Nov 2011
>> Last changed: 1264652963 = 28 Jan 2010
>> Time of Birth: 1292365840 = 14 Dec 2010
> The file might have been created earlier; the date 14 Dec 2010 is the
> day where I reinstalled my Mac after a HDD crash from backup.
>
> I have checked if I have backups older than that on one of the Time
> Machine disks but that is negative.  But since Time Machine uses
> hardlinks to link the files between different backups the file backed
> up in the oldest backup from 27 Dec 2010 might have still the date of
> birth we're looking for.  Assumed it didn't issue a completely new
> backup after restoring from the old one.
>
> I'm interested in this because I wonder how I ever got a working fontcache.
>
> It might be that I compiled matplotlib first differently, with
> python.org Python, hence gcc-4.0, and if we assume that it works under
> gcc-4.0, I would have ended up with a proper fontcache, and was free
> to compile with gcc-4.2 + 10.5 deployment target.  Then the fontcache
> lived on all that years since Mid 2009 untouched.  Until now, where it
> attempted to recreate it, with the gcc-4.2 + 10.5 targeted matplotlib,
> failing on that.
>
> I guess that the NISC18030.ttf in the backup has the date of birth of
> the first backup ever, meaning that it was probably present from the
> very beginning.  This is suggested by the posts back to 2005, where
> the file existed on that ``bsd`` machine of William Stein, iirc.  I
> strongly believe I just got a working intermediate matplotlib, which
> created the everlasting (or not) fontcache.

Hey,

I work with Mac OSX 10.7.2
I have a probleem. From the IDLE this little program works fine:
#!/usr/bin/python
import numpy
import matplotlib
print "Content-Type: text/plain\n"
print matplotlib.__version__

The output is:
Content-Type: text/plain

1.1.0

Starting this program from MAMP gives me:  Internal Server Error

First I change the program into:
#!/usr/bin/python
import numpy
import matplotlib
print "Content-Type: text/plain\n"
print 'No error'

But starting this program from MAMP also gives me:  Internal Server Error

Now I change my program into:
#!/usr/bin/python
import numpy
##import matplotlib
print "Content-Type: text/plain\n"
print 'No error'

Now starting this program from MAMP gives me:  No error

So the import of mapplotlib causes this troubles. I don't have these
problems with the import of numpy.

Can someone help me with this problem?

On 13 November 2011 19:10, Daniel Welling <dan...@gm...> wrote:

> I am interested in accessing Triangulation objections that are created by
> MPL for tricontour-type plots.  The docs for MPL routines that use
> triangulation objects refer to documentation, but none exists in the MPL
> online docs.  Does anyone have docs/info on using these objects?  Having
> access to them would be great.
>

The easiest way to find out about Triangulation objects is to look at the
source code on github:
https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/tri/triangulation.py

The class and __init__ descriptions should contain all the information you
need.

Ian

Hi,

I'm using a slider widget from matplotlib and I've been trying to
update just the slider bar using blit for faster animation because if
I use draw() for the whole canvas it is too slow. I got the bar to
animate faster using this method (though it doesn't look perfect), but
I can't figure out how to draw the slider value that shows up next to
the slider. Any help would be greatly appreciated. My code for the
slider is something like this:

import pylab as p
from matplotlib.widgets import Slider

axsigma  = p.axes([0.25, 0.10, 0.65, 0.03], axisbg=axcolor)
slider1 = Slider (axsigma, 'Sigma',0.20, 18,
valinit=s0,dragging=True,  fc='blue')

canvas1=axsigma.figure.canvas

def update (val):
    canvas1.blit(axsigma.bbox)

slider1.on_changed(update)




Thanks,

Eli Lyons

Hi all,

This is my first time setting up matplotlib.

I'm on OS X Lion 10.7 (build 11A511s, so no updates done to the initial
release of OS X Lion).

I am using virtualenv and pip to do the installation.

I'm aware of the incompatibility with libpng 1.5, so I didn't just run "pip
install matplotlib"... instead...

I tried running this from inside the virtualenv:

"pip install -e git+
https://github.com/matplotlib/matplotlib#egg=matplotlib-dev"

Looks like it starts installing, but then I get this error:

/Users/myusername/.virtualenvs/nltk/lib/python2.7/site-packages/numpy/core/include/numpy/__multiarray_api.h:1532:
warning: ‘int _import_array()’ defined but not used

lipo: can't open input file:
/var/folders/wy/s1jr354d4xx7dk0lpdpbpsbc0000gn/T//ccfNUhyq.out (No such
file or directory)

error: command 'llvm-gcc-4.2' failed with exit status 1

----------------------------------------
Command /Users/sameerfx/.virtualenvs/nltk/bin/python -c "import setuptools;
__file__='/Users/sameerfx/.virtualenvs/nltk/src/matplotlib/setup.py';
exec(compile(open(__file__).read().replace('\r\n', '\n'), __file__,
'exec'))" develop --no-deps failed with error code 1
Storing complete log in /Users/sameerfx/.pip/pip.log

Hi:

I just installed matplolib from source code, and Ipython using pip, in
Ubuntu 11.10.

When I run this code

########### foo.py ############
import matplotlib.pyplot as plt
plt.plot([1,2,3,4])
plt.ylabel('some numbers')
plt.show()
##############################

in ipython, I get the following warning:

In [1]: %run foo.py
/usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:54: Warning:
ignoring sys.argv: it must be a list of strings
  _gtk.init_check()

Other than the warning the plot looks OK.

Also, if I type each sentence in ipython, I don't get the warning. I
don't get a warning if I use the standard python interpreter either
(as in $ python foo.py).

Any clue about this? Should I report this in the Ipython mailing list?

I am running Ipython 0.11 and matplotlib 1.2.x.

Alejandro

On Sun, Nov 13, 2011 at 4:37 PM, klo uo <kl...@gm...> wrote:

> I think that paths needed to be passed to CPP/LDFLAGS like this:
>
> CPPFLAGS=-I/usr/include/hdf LDFLAGS=-L/usr/lib ./configure --enable-hdf4
> && make
>
> then also package is dependent on latest hdf5 to be build (1.8.7), so
> installing it globally would break possible dependencies in any
> packaging system, and lastly it's just pain to build it if it's worth
>
>
> On Sun, Nov 13, 2011 at 10:12 PM, Gökhan Sever <gok...@gm...>
> wrote:
> > When I remove hdf4 part from config, it builds successfully. Any ideas?
>

This one still fails with the same error. I will make a clean Fedora 16
installation in the near future, then I will test these on the new system.
Firstly, hoping that F16 will provide these packages already built :) Those
-fPIC errors were killing me while building PyNIO...

-- 
Gökhan

It's not "official", but just idiomatic, I suppose ;)

http://en.wikipedia.org/wiki/Monkey_patch

http://paulirish.com/2010/duck-punching-with-jquery/


>
> Is that an official term? I have done things like this before, but never had
> a word for it.
>
> Ben Root
>



-- 
Daniel Hyams
dh...@gm...

I think that paths needed to be passed to CPP/LDFLAGS like this:

CPPFLAGS=-I/usr/include/hdf LDFLAGS=-L/usr/lib ./configure --enable-hdf4 && make

then also package is dependent on latest hdf5 to be build (1.8.7), so
installing it globally would break possible dependencies in any
packaging system, and lastly it's just pain to build it if it's worth


On Sun, Nov 13, 2011 at 10:12 PM, Gökhan Sever <gok...@gm...> wrote:
> When I remove hdf4 part from config, it builds successfully. Any ideas?

2011/11/12 Friedrich Romstedt <fri...@gm...>:
> $ stat -f "...." /Library/Fonts/NISC18030.ttf
> Last accessed or modified: 1321107464 = 12 Nov 2011
> Last changed: 1264652963 = 28 Jan 2010
> Time of Birth: 1292365840 = 14 Dec 2010

The file might have been created earlier; the date 14 Dec 2010 is the
day where I reinstalled my Mac after a HDD crash from backup.

I have checked if I have backups older than that on one of the Time
Machine disks but that is negative.  But since Time Machine uses
hardlinks to link the files between different backups the file backed
up in the oldest backup from 27 Dec 2010 might have still the date of
birth we're looking for.  Assumed it didn't issue a completely new
backup after restoring from the old one.

I'm interested in this because I wonder how I ever got a working fontcache.

It might be that I compiled matplotlib first differently, with
python.org Python, hence gcc-4.0, and if we assume that it works under
gcc-4.0, I would have ended up with a proper fontcache, and was free
to compile with gcc-4.2 + 10.5 deployment target.  Then the fontcache
lived on all that years since Mid 2009 untouched.  Until now, where it
attempted to recreate it, with the gcc-4.2 + 10.5 targeted matplotlib,
failing on that.

I guess that the NISC18030.ttf in the backup has the date of birth of
the first backup ever, meaning that it was probably present from the
very beginning.  This is suggested by the posts back to 2005, where
the file existed on that ``bsd`` machine of William Stein, iirc.  I
strongly believe I just got a working intermediate matplotlib, which
created the everlasting (or not) fontcache.

Friedrich

On Sunday, November 13, 2011, Daniel Hyams <dh...@gm...> wrote:
>>
>> OK, types is a new part of the Python library for me, I'll have to go
>> learn about it.  It looks like you basically just subclassed the
>> QuadContourSet object through a back door, by giving it the missing
>> method.
>
> It's not a subclass, it's just a "monkey patch".  I personally like
> "duck punching", because even just reading the term makes me laugh:
> "If it walks like a duck and quacks like a duck, it's a duck; or if it
> does not walk or talk like a duck, punch it until it does".  In this
> case, we're punching the QuadContourSet until it behaves like an
> Artist.  It's a useful technique for experimenting, and can be used as
> a patching technique in the interim until it is fixed properly.  You
> never want to write code like this on a regular basis, however.
>
>
>> Your patch solves one of two animation problems, and I offer a
>> suggestion about how to fix the second (with questions).
>>
>> The program gets as far as ani.save() on line 29 without generating any
>> errors. An MP4 file showing animated contours is written to disk.  The
>> origin of the contour plot is in the lower left, versus the upper left
>> of the original imshow() call, but that's expected.
>>
>> When you get to plt.show() on line 31, however:
>>
>> Traceback (most recent call last):
>>  File
>>
"/usr/local/lib/python2.6/dist-packages/matplotlib/backends/backend_gtk.py",
line 127, in _on_timer
>>    TimerBase._on_timer(self)
>>  File
>> "/usr/local/lib/python2.6/dist-packages/matplotlib/backend_bases.py",
>> line 1091, in _on_timer
>>    ret = func(*args, **kwargs)
>>  File "/usr/local/lib/python2.6/dist-packages/matplotlib/animation.py",
>> line 317, in _step
>>    still_going = Animation._step(self, *args)
>>  File "/usr/local/lib/python2.6/dist-packages/matplotlib/animation.py",
>> line 179, in _step
>>    self._draw_next_frame(framedata, self._blit)
>>  File "/usr/local/lib/python2.6/dist-packages/matplotlib/animation.py",
>> line 199, in _draw_next_frame
>>    self._post_draw(framedata, blit)
>>  File "/usr/local/lib/python2.6/dist-packages/matplotlib/animation.py",
>> line 222, in _post_draw
>>    self._blit_draw(self._drawn_artists, self._blit_cache)
>>  File "/usr/local/lib/python2.6/dist-packages/matplotlib/animation.py",
>> line 236, in _blit_draw
>>    bg_cache[a.axes] = a.figure.canvas.copy_from_bbox(a.axes.bbox)
>> AttributeError: QuadContourSet instance has no attribute 'figure'
>
> It looks like just one more duck punch is needed; just set
>
> im.figure = fig
>
> after the setting of im.axes.  QuadContourSet should really call
> a.get_axes() and a.get_figure() instead of using the attributes
> directly; doing so would allow any object that implements the proper
> interfaces to work, artist or no.
>
>> Is this error occurring because there is no bit-mapped representation of
>> a contour object?
>
> It's not really that, it's just that the animation class expects to be
> given a list of Artists to work with (the original author can correct
> me if I'm wrong), and that's not what it is being given, because a
> QuadContourSet is not an Artist.  But you can duck punch it until it
> acts like one :D
>
> IMO, there are quite a few things in matplotlib that are a little
> inconsistent in this way.
>

"duck-punching"

Is that an official term? I have done things like this before, but never
had a word for it.

Ben Root

>
> OK, types is a new part of the Python library for me, I'll have to go
> learn about it.  It looks like you basically just subclassed the
> QuadContourSet object through a back door, by giving it the missing
> method.

It's not a subclass, it's just a "monkey patch".  I personally like
"duck punching", because even just reading the term makes me laugh:
"If it walks like a duck and quacks like a duck, it's a duck; or if it
does not walk or talk like a duck, punch it until it does".  In this
case, we're punching the QuadContourSet until it behaves like an
Artist.  It's a useful technique for experimenting, and can be used as
a patching technique in the interim until it is fixed properly.  You
never want to write code like this on a regular basis, however.


> Your patch solves one of two animation problems, and I offer a
> suggestion about how to fix the second (with questions).
>
> The program gets as far as ani.save() on line 29 without generating any
> errors. An MP4 file showing animated contours is written to disk.  The
> origin of the contour plot is in the lower left, versus the upper left
> of the original imshow() call, but that's expected.
>
> When you get to plt.show() on line 31, however:
>
> Traceback (most recent call last):
>  File
> "/usr/local/lib/python2.6/dist-packages/matplotlib/backends/backend_gtk.py", line 127, in _on_timer
>    TimerBase._on_timer(self)
>  File
> "/usr/local/lib/python2.6/dist-packages/matplotlib/backend_bases.py",
> line 1091, in _on_timer
>    ret = func(*args, **kwargs)
>  File "/usr/local/lib/python2.6/dist-packages/matplotlib/animation.py",
> line 317, in _step
>    still_going = Animation._step(self, *args)
>  File "/usr/local/lib/python2.6/dist-packages/matplotlib/animation.py",
> line 179, in _step
>    self._draw_next_frame(framedata, self._blit)
>  File "/usr/local/lib/python2.6/dist-packages/matplotlib/animation.py",
> line 199, in _draw_next_frame
>    self._post_draw(framedata, blit)
>  File "/usr/local/lib/python2.6/dist-packages/matplotlib/animation.py",
> line 222, in _post_draw
>    self._blit_draw(self._drawn_artists, self._blit_cache)
>  File "/usr/local/lib/python2.6/dist-packages/matplotlib/animation.py",
> line 236, in _blit_draw
>    bg_cache[a.axes] = a.figure.canvas.copy_from_bbox(a.axes.bbox)
> AttributeError: QuadContourSet instance has no attribute 'figure'

It looks like just one more duck punch is needed; just set

im.figure = fig

after the setting of im.axes.  QuadContourSet should really call
a.get_axes() and a.get_figure() instead of using the attributes
directly; doing so would allow any object that implements the proper
interfaces to work, artist or no.

> Is this error occurring because there is no bit-mapped representation of
> a contour object?

It's not really that, it's just that the animation class expects to be
given a list of Artists to work with (the original author can correct
me if I'm wrong), and that's not what it is being given, because a
QuadContourSet is not an Artist.  But you can duck punch it until it
acts like one :D

IMO, there are quite a few things in matplotlib that are a little
inconsistent in this way.

-- 
Daniel Hyams
dh...@gm...

On Sun, 2011-11-13 at 13:26 -0500, Daniel Hyams wrote:
> Oops; my sentence should have read "is *not* derived from an artist".

Yes, I was wondering about that.  I was actually looking though the
artist.py and contour.py source code when your message came in.


On Sunday, November 13, 2011, Daniel Hyams <dh...@gm...> wrote:
> The following monkey patch fixes it in the example script (obviously,
> it does not fix the underlying problem; for QuadContourSet to be
> usable in this context, it needs to obey the artist interface).
> Hopefully, it will be enough to get you up and running.  Just add the
> four lines between contour call and the appending of the output of
> contour() into the list "ims", and also put an "import types" at the
> top.

OK, types is a new part of the Python library for me, I'll have to go
learn about it.  It looks like you basically just subclassed the
QuadContourSet object through a back door, by giving it the missing
method.

Your patch solves one of two animation problems, and I offer a
suggestion about how to fix the second (with questions).  

The program gets as far as ani.save() on line 29 without generating any
errors. An MP4 file showing animated contours is written to disk.  The
origin of the contour plot is in the lower left, versus the upper left
of the original imshow() call, but that's expected.

When you get to plt.show() on line 31, however:

Traceback (most recent call last):
  File
"/usr/local/lib/python2.6/dist-packages/matplotlib/backends/backend_gtk.py", line 127, in _on_timer
    TimerBase._on_timer(self)
  File
"/usr/local/lib/python2.6/dist-packages/matplotlib/backend_bases.py",
line 1091, in _on_timer
    ret = func(*args, **kwargs)
  File "/usr/local/lib/python2.6/dist-packages/matplotlib/animation.py",
line 317, in _step
    still_going = Animation._step(self, *args)
  File "/usr/local/lib/python2.6/dist-packages/matplotlib/animation.py",
line 179, in _step
    self._draw_next_frame(framedata, self._blit)
  File "/usr/local/lib/python2.6/dist-packages/matplotlib/animation.py",
line 199, in _draw_next_frame
    self._post_draw(framedata, blit)
  File "/usr/local/lib/python2.6/dist-packages/matplotlib/animation.py",
line 222, in _post_draw
    self._blit_draw(self._drawn_artists, self._blit_cache)
  File "/usr/local/lib/python2.6/dist-packages/matplotlib/animation.py",
line 236, in _blit_draw
    bg_cache[a.axes] = a.figure.canvas.copy_from_bbox(a.axes.bbox)
AttributeError: QuadContourSet instance has no attribute 'figure'


Since the error was occurring inside blit_draw, I tried altering the
animation.ArtistAnimation() call on line 27, letting blit default to
False.  This resulted in a successful on-screen rendering, as well as a
saved file on the disk.  Mission accomplished!  Though perhaps at the
sacrifice of some speed.

Is this error occurring because there is no bit-mapped representation of
a contour object?  If so, what should matplotlib do?  Make the user be
aware that blit cannot be used with contour objects, as I just learned?
Or, alternately, make sure that animations respond intelligently to the
objects passed to them?

Many thanks again to everyone who is working through this with me!

On Sun, Nov 13, 2011 at 12:57 PM, Jeff Whitaker <js...@fa...> wrote:
>
> Gökhan:  netcdf4-python can read hdf5-eos files, and even hdf4-eos files
> if the netcdf C lib is built with hdf4 support.
>
> -Jeff
>

I can't build netcdf4 C libraries with HDF4 support.

[gsever@ccn hdf-4.2.6]$ ./configure --prefix=/usr/local
 --includedir=/usr/local/ --with-zlib=/usr/local --with-jpeg=/usr/local
--disable-fortran --with-szip=/usr/local/ CFLAGS=-fPIC

I can't build HDF4 without disabling the fortran support. Then trying to
build netcdf4 with HDF4:

[gsever@ccn netcdf-4.1.3]$ ./configure --prefix=/usr/local/netcdf4
--enable-netcdf-4 --with-hdf5=/usr/local/ --enable-shared --enable-hdf4
--with-hdf4=/usr/local/

Fails:

Making all in ncgen3
make[2]: Entering directory `/home/gsever/Downloads/netcdf-4.1.3/ncgen3'
/bin/sh ../libtool --tag=CC   --mode=link gcc  -g -O2   -o ncgen3 main.o
load.o escapes.o getfill.o init.o genlib.o ncgentab.o
../liblib/libnetcdf.la -lhdf5_hl -lhdf5 -lm -lz -lcurl
libtool: link: gcc -g -O2 -o .libs/ncgen3 main.o load.o escapes.o getfill.o
init.o genlib.o ncgentab.o  ../liblib/.libs/libnetcdf.so -lhdf5_hl -lhdf5
-lm -lz -lcurl -Wl,-rpath -Wl,/usr/local/netcdf4/lib
../liblib/.libs/libnetcdf.so: undefined reference to `SDstart'
../liblib/.libs/libnetcdf.so: undefined reference to `SDend'
../liblib/.libs/libnetcdf.so: undefined reference to `SDattrinfo'
../liblib/.libs/libnetcdf.so: undefined reference to `SDfileinfo'
../liblib/.libs/libnetcdf.so: undefined reference to `SDreadattr'
../liblib/.libs/libnetcdf.so: undefined reference to `SDselect'
../liblib/.libs/libnetcdf.so: undefined reference to `SDreaddata'
../liblib/.libs/libnetcdf.so: undefined reference to `SDdiminfo'
../liblib/.libs/libnetcdf.so: undefined reference to `SDgetfillvalue'
../liblib/.libs/libnetcdf.so: undefined reference to `SDgetinfo'
../liblib/.libs/libnetcdf.so: undefined reference to `SDgetdimid'
collect2: ld returned 1 exit status
make[2]: *** [ncgen3] Error 1
make[2]: Leaving directory `/home/gsever/Downloads/netcdf-4.1.3/ncgen3'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/gsever/Downloads/netcdf-4.1.3'
make: *** [all] Error 2

When I remove hdf4 part from config, it builds successfully. Any ideas?