matplotlib-devel Mailing List for matplotlib

On Wed, Jan 27, 2010 at 6:06 PM, Andrew Straw <str...@as...> wrote:
> I'm +1 on this. We can have then have the buildbot doc builder enable
> this when building the docs. (Which are output at
> http://matplotlib.sourceforge.net/trunk-docs/ and
> http://matplotlib.sourceforge.net/trunk-docs/Matplotlib.pdf , for
> reference .)
Thanks, with your and John's (off-list) approvals, it's committed.
The patch that went in had more docs than what I posted here, but the
code is identical.
Cheers,
f

On Thu, Jan 28, 2010 at 1:03 PM, Eric Firing <ef...@ha...> wrote:
> Ryan May wrote:
>> Unless I completely misunderstand zorder, the contour should be *on
>> top* of the rectangle. Also note that printing the zorder for the
>> contour's collection (a LineCollection object) gives a value of 2,
>> even though the call to contour() specified 5 for the zorder. Looking
>> over the code for contour, the zorder is never mentioned. The reason
>> the LineCollection ends up with a value of 2 is that this is the
>> default for a LineCollection. My question is: is there any reason
>> *not* to use the passed in zorder for contours/filled contours? If
>> this is the proper fix, I'll check it in myself, I just wanted to make
>> sure I'm not missing some special case here.
>
> Ryan,
>
> Certainly it makes sense to support zorder in some fashion, and the simple
> way is as you suggest, with one value per call to contour. It may be best
> to stop there--but I can imagine the next complaint being, "why doesn't
> zorder support a sequence?", and then things get quite a bit more
> complicated.
>
> Anyway, go ahead and put in the simple zorder support; I don't see any
> downside to it.
Will do shortly.
>> As an aside, this is yet another example where it would be nice to
>> know that a keyword argument was not being used. If there's no
>> objections, I'd be willing to change ContourSet to pop arguments off
>> of **kwargs so that it can see if some aren't used and throw an
>> exception if not all are used. On the other hand, this could break
>> existing code that are passing extra/useless kwargs, so maybe a
>> warning would be better?
>
> Careful. Keeping track of which kwargs are used, and making sure they are
> always popped, and don't need to remain in the kwargs dictionary, could get
> tricky. I just added support for the units-related kwargs. I think what
> you suggest will work, and I agree that some error-trapping for kwarg
> accidents (misspelling kwargs, or otherwise trying to use a kwarg that has
> no effect) is a good idea.
>
> This sounds like an area where some general mpl coding guidelines, and quite
> a bit of work to implement them, would be good.
Agreed. After I wrote this, I thought about it some more, and it's
not something you can really do piecemeal due to passing off to base
classes and what not. It's a big usability wart however, like when
accidentally using 'linewidth' instead of 'linewidths' for calling
contour. I'll just leave this as a future improvement.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, Oklahoma, United States

Ryan May wrote:
> Hi,
> 
> I was shown a bug today by a colleague, demonstrated by the following example:
> 
> import numpy as np
> import matplotlib.pyplot as plt
> 
> a = np.zeros([10, 10])
> a[2:6,3:8] = 1
> ls = plt.contour(a, 1, colors='r', linewidths=3, zorder=5)
> print ls.collections[0]l.get_zorder()
> rect = plt.Rectangle([2, 3], 5, 4, zorder=3)
> plt.gca().add_artist(rect)
> plt.show()
> 
> Unless I completely misunderstand zorder, the contour should be *on
> top* of the rectangle. Also note that printing the zorder for the
> contour's collection (a LineCollection object) gives a value of 2,
> even though the call to contour() specified 5 for the zorder. Looking
> over the code for contour, the zorder is never mentioned. The reason
> the LineCollection ends up with a value of 2 is that this is the
> default for a LineCollection. My question is: is there any reason
> *not* to use the passed in zorder for contours/filled contours? If
> this is the proper fix, I'll check it in myself, I just wanted to make
> sure I'm not missing some special case here.
Ryan,
Certainly it makes sense to support zorder in some fashion, and the 
simple way is as you suggest, with one value per call to contour. It 
may be best to stop there--but I can imagine the next complaint being, 
"why doesn't zorder support a sequence?", and then things get quite a 
bit more complicated.
Anyway, go ahead and put in the simple zorder support; I don't see any 
downside to it.
> 
> As an aside, this is yet another example where it would be nice to
> know that a keyword argument was not being used. If there's no
> objections, I'd be willing to change ContourSet to pop arguments off
> of **kwargs so that it can see if some aren't used and throw an
> exception if not all are used. On the other hand, this could break
> existing code that are passing extra/useless kwargs, so maybe a
> warning would be better?
Careful. Keeping track of which kwargs are used, and making sure they 
are always popped, and don't need to remain in the kwargs dictionary, 
could get tricky. I just added support for the units-related kwargs. I 
think what you suggest will work, and I agree that some error-trapping 
for kwarg accidents (misspelling kwargs, or otherwise trying to use a 
kwarg that has no effect) is a good idea.
This sounds like an area where some general mpl coding guidelines, and 
quite a bit of work to implement them, would be good.
Eric
> 
> Ryan
> 

Hi,
I was shown a bug today by a colleague, demonstrated by the following example:
import numpy as np
import matplotlib.pyplot as plt
a = np.zeros([10, 10])
a[2:6,3:8] = 1
ls = plt.contour(a, 1, colors='r', linewidths=3, zorder=5)
print ls.collections[0]l.get_zorder()
rect = plt.Rectangle([2, 3], 5, 4, zorder=3)
plt.gca().add_artist(rect)
plt.show()
Unless I completely misunderstand zorder, the contour should be *on
top* of the rectangle. Also note that printing the zorder for the
contour's collection (a LineCollection object) gives a value of 2,
even though the call to contour() specified 5 for the zorder. Looking
over the code for contour, the zorder is never mentioned. The reason
the LineCollection ends up with a value of 2 is that this is the
default for a LineCollection. My question is: is there any reason
*not* to use the passed in zorder for contours/filled contours? If
this is the proper fix, I'll check it in myself, I just wanted to make
sure I'm not missing some special case here.
As an aside, this is yet another example where it would be nice to
know that a keyword argument was not being used. If there's no
objections, I'd be willing to change ContourSet to pop arguments off
of **kwargs so that it can see if some aren't used and throw an
exception if not all are used. On the other hand, this could break
existing code that are passing extra/useless kwargs, so maybe a
warning would be better?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Thu, Jan 28, 2010 at 2:00 AM, Robert Bradshaw
<rob...@ma...> wrote:
[snip]
> I'm guessing that's the issue, but just to be sure, try using the bare
I still get the error with the super-bare extension module, so
cython's off the hook :-).
> Have you verified that the same C++ compiler and version of libstdc++ is
> being used for everything?
I've tried it two ways; first with everything -- numpy, scipy,
matplotlib -- installed and compiled from svn, and one with them
installed from the latest ubuntu repositories. I also tried it on
both machines I have access to; a 64bit server with gcc 4.3.3 and
python 2.6.2, and a 32bit one with gcc 4.4.1 and python 2.6.4. The
error is the same on both of those. The python version and the gcc
compiler are the two things in common.
> If you did upgrade NumPy, rebuild *everything* of compiled code
> which depends on it.
Yes I did do that, and recompiled everything, but still good to check.
gcc is smelling fishier and fishier (or maybe python 2.6?).
-- Hoyt
++++++++++++++++++++++++++++++++++++++++++++++++
+ Hoyt Koepke
+ University of Washington Department of Statistics
+ http://www.stat.washington.edu/~hoytak/
+ ho...@gm...
++++++++++++++++++++++++++++++++++++++++++

Hoyt Koepke wrote:
> I'm really not sure which mailing list to report this on -- it has got
> to rank up there with one of the most obscure errors of all times. I
> suspect it's an error in gcc's new openmp implementation, gomp, but
> not sure; I can report it there if people think I should.
>
> In gcc 4.4.1, when I compile a completely empty .pyx module in (1) c++
> mode and (2) pass -lgomp to the linker, simply (3) importing that
> empty module causes any subsequent use of matplotlib to segfault the
> program. Changing either (1), (2) or (3) makes the error go away.
>
> I'm using the latest 32bit ubuntu (9.10), python 2.6.4, with the
> latest cython-devel (2820:105c661599c9) and the latest matplotlib from
> svn (8097). In matplotlib, I'm using the qt4agg backend. Everything
> else appears to be working save for this error.
>
> If my main file is simply:
>
> import tests.emptymodule
> import tests.plottest
>
> where emptymodules is a completely empty cython module and plottest is
>
> from matplotlib.pylab import *
>
> figure()
> plot([0,1], [0,1], '-b')
> show()
>
> The program segfaults on the plot() call, with backtrace
>
> (gdb) bt 8
> #0 0x00e03bc7 in __cxa_allocate_exception () from /usr/lib/libstdc++.so.6
> #1 0x0093f282 in py_to_agg_transformation_matrix (obj=0x8223f58,
> errors=false) at src/agg_py_transforms.cpp:20
> #2 0x00946ff3 in _path_module::update_path_extents (this=0x8856098,
> args=...) at src/path.cpp:346
> #3 0x0094e2fd in
> Py::ExtensionModule<_path_module>::invoke_method_varargs (this=<value
> optimized out>, method_def=0x8476e00, args=...)
> at ./CXX/Python2/ExtensionModule.hxx:184
> #4 0x0093ae26 in method_varargs_call_handler
> (_self_and_name_tuple=0x888448c, _args=0x8f052fc) at
> CXX/Python2/cxx_extensions.cxx:1714
> #5 0x080dc0d0 in PyEval_EvalFrameEx ()
> #6 0x080dddf2 in PyEval_EvalCodeEx ()
> #7 0x080dc1b4 in PyEval_EvalFrameEx ()
>
> 
It works for me here, but of course, I have a slightly different system.
gcc-4.3, python 2.5.2, Cython 0.12, and matplotlib SVN 8097.
Have you verified that the same C++ compiler and version of libstdc++ is 
being used for everything?
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I'm really not sure which mailing list to report this on -- it has got
to rank up there with one of the most obscure errors of all times. I
suspect it's an error in gcc's new openmp implementation, gomp, but
not sure; I can report it there if people think I should.
In gcc 4.4.1, when I compile a completely empty .pyx module in (1) c++
mode and (2) pass -lgomp to the linker, simply (3) importing that
empty module causes any subsequent use of matplotlib to segfault the
program. Changing either (1), (2) or (3) makes the error go away.
I'm using the latest 32bit ubuntu (9.10), python 2.6.4, with the
latest cython-devel (2820:105c661599c9) and the latest matplotlib from
svn (8097). In matplotlib, I'm using the qt4agg backend. Everything
else appears to be working save for this error.
If my main file is simply:
import tests.emptymodule
import tests.plottest
where emptymodules is a completely empty cython module and plottest is
from matplotlib.pylab import *
figure()
plot([0,1], [0,1], '-b')
show()
The program segfaults on the plot() call, with backtrace
(gdb) bt 8
#0 0x00e03bc7 in __cxa_allocate_exception () from /usr/lib/libstdc++.so.6
#1 0x0093f282 in py_to_agg_transformation_matrix (obj=0x8223f58,
errors=false) at src/agg_py_transforms.cpp:20
#2 0x00946ff3 in _path_module::update_path_extents (this=0x8856098,
args=...) at src/path.cpp:346
#3 0x0094e2fd in
Py::ExtensionModule<_path_module>::invoke_method_varargs (this=<value
optimized out>, method_def=0x8476e00, args=...)
 at ./CXX/Python2/ExtensionModule.hxx:184
#4 0x0093ae26 in method_varargs_call_handler
(_self_and_name_tuple=0x888448c, _args=0x8f052fc) at
CXX/Python2/cxx_extensions.cxx:1714
#5 0x080dc0d0 in PyEval_EvalFrameEx ()
#6 0x080dddf2 in PyEval_EvalCodeEx ()
#7 0x080dc1b4 in PyEval_EvalFrameEx ()
Other commands like imshow also cause a segfault.
Anyway, I can get by for now without openmp, but I'm curious if anyone
has ideas about this bug. I've attached a tarball with the code that
reproduces it for me; simply run build.sh and run.
Thanks!
-- hoyt
++++++++++++++++++++++++++++++++++++++++++++++++
+ Hoyt Koepke
+ University of Washington Department of Statistics
+ http://www.stat.washington.edu/~hoytak/
+ ho...@gm...
++++++++++++++++++++++++++++++++++++++++++

Fernando Perez wrote:
> Hi all,
>
> would anyone mind if I commit the attached patch?
>
> It's 100% backwards compatible and allows for turning plot directive
> errors into fatal exceptions easily, so one can make sure that docs
> either build correctly or not at all. This is useful for having
> examples be a kind of test suite, in addition to any unit tests a
> codebase may have.
>
> Thanks,
>
> f
> 
I'm +1 on this. We can have then have the buildbot doc builder enable
this when building the docs. (Which are output at
http://matplotlib.sourceforge.net/trunk-docs/ and
http://matplotlib.sourceforge.net/trunk-docs/Matplotlib.pdf , for
reference .)
-Andrew

Hi all,
would anyone mind if I commit the attached patch?
It's 100% backwards compatible and allows for turning plot directive
errors into fatal exceptions easily, so one can make sure that docs
either build correctly or not at all. This is useful for having
examples be a kind of test suite, in addition to any unit tests a
codebase may have.
Thanks,
f