matplotlib-devel Mailing List for matplotlib

Hi,
as per recent sphinx (I got 1.0.6 where, and with 1.0.1 it worked
fine), the image 'formats' is loaded as a unicode object, and so it's
no more a str as previously identified in
lib/matplotlib/sphinxext/plot_directive.py: the attached patch make
the doc be buildable again with 1.0.6 and should be backportable.
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Hi all,
Using the last 1.0.1 matplotlib version,sometimes exporting paths to
polygons gives wrong results like here (paths come from a
tricontourset) :
In [94]: path
Out[94]:
Path([[ 172.0079229 -43.79390934]
 [ 171.97660793 -43.785 ]
 [ 171.96206864 -43.78273625]
 [ 171.959 -43.78114859]
 ...
 [ 171.593 -44.00678244]
 [ 171.64906502 -44.01 ]
 [ 171.654 -44.01077106]
 [ 171.7068607 -44.0160044 ]], [1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 2 2
 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2])
In [95]: path.vertices.shape
Out[95]: (210, 2)
but to_polygons gives another result :
In [98]: path.to_polygons()
Out[98]:
[array([[ 172.0079229 , -43.79390934],
 [ 171.86039224, -43.65 ],
 [ 172.081 , -43.54450289],
 [ 172.386 , -43.57010293],
 [ 172.60631978, -43.67753099],
 [ 172.59231502, -43.71219961],
 [ 172.325 , -43.78095532],
 [ 172.02 , -43.79497729]]),
 array([[ 171.715 , -44.0160044 ],
 [ 173.02676111, -43.92 ],
 [ 172.935 , -43.53340591],
 [ 171.40281884, -43.70029758],
 [ 171.37760645, -43.94389688],
 [ 171.54044973, -44.0037666 ],
 [ 171.7068607 , -44.0160044 ],
 [ 171.7068607 , -44.0160044 ]])]
Cheers
-- 
Lionel Roubeyrie
lio...@gm...
http://youarealegend.blogspot.com

Hi,
Jakub spotted this problem with mpl and new sphinx:
On Tue, Jan 4, 2011 at 20:47, Jakub Wilk <jw...@de...> wrote:
> In Sphinx 1.0, ":param" field can accept up to 2 whitespace-separated
> arguments. Unforunately, this new feature breaks a bit documentation of some
> stuff in the mpl_toolkits.axes_grid.axes_divider module, which is using
> spaces for its own purpose:
>
> $ grep -E -r 'param [^ ]* [^ ]*:' .
> ./lib/mpl_toolkits/axes_grid/axes_divider.py:    :param nx, nx1:
> Integers specifying the column-position of the
> ./lib/mpl_toolkits/axes_grid/axes_divider.py:    :param ny, ny1: same as
> nx and nx1, but for row positions.
> ./lib/mpl_toolkits/axes_grid/axes_divider.py:    :param nx, nx1:
> Integers specifying the column-position of the
> ./lib/mpl_toolkits/axes_grid/axes_divider.py:    :param ny, ny1: same as
> nx and nx1, but for row positions.
> ./lib/mpl_toolkits/axes_grid/axes_divider.py:    :param nx, nx1:
> Integers specifying the column-position of the
> ./lib/mpl_toolkits/axes_grid/axes_divider.py:    :param ny, ny1: same as
> nx and nx1, but for row positions.
>
> [0] See bottom of:
> http://sphinx.pocoo.org/domains.html#info-field-lists
That generates pages like this:
locate(nx, ny, nx1=None, ny1=None, renderer=None)¶
 Parameters:	
 * nx1 (nx,) – Integers specifying the column-position of the
cell. When nx1 is None, a single nx-th column is specified. Otherwise
location of columns spanning between nx to nx1 (but excluding nx1-th
column) is specified.
 * ny1 (ny,) – same as nx and nx1, but for row positions.
With the attached patch, I removed the space between those arguments,
but at least it generates a correct list even tho it's a bit visually
unpleasant.
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On 01/13/2011 09:08 AM, Benjamin Root wrote:
> A fellow student approached me today wanting to know if matplotlib was
> able to produce a certain kind of 3d plot where a filled contour was
> placed on one of the axes panels. I knew it was possible with regular
> contours, but was surprised when I realized that the same feature wasn't
> available for contourf. So I wrote a patch to add that feature (and
> clean up a few documentation-related things). I also added an example
> script with examples/mplot3d/contourf3d_demo2.py.
>
> This is the image produced by the example:
> http://dl.dropbox.com/u/7325604/newcontourf3d.png
Nice! Thank you!
On a related note, a considerable fraction of the mpl bug tickets on 
sourceforge are for mplot3d. For a while I was assigning them to 
Reinier Heeres, but I think he has been unable to get to them. I 
suspect some are actually quite simple to fix, and others may already 
have been fixed by work you have been doing on mplot3d. If you get a 
chance, please look through them and close any that can be closed. If 
there are any that you think you will be able to address, but not 
immediately, please assign them to yourself.
Thanks.
Eric
>
> This was committed in r8915.
>
> Enjoy!
> Ben Root

A fellow student approached me today wanting to know if matplotlib was able
to produce a certain kind of 3d plot where a filled contour was placed on
one of the axes panels. I knew it was possible with regular contours, but
was surprised when I realized that the same feature wasn't available for
contourf. So I wrote a patch to add that feature (and clean up a few
documentation-related things). I also added an example script with
examples/mplot3d/contourf3d_demo2.py.
This is the image produced by the example:
http://dl.dropbox.com/u/7325604/newcontourf3d.png
This was committed in r8915.
Enjoy!
Ben Root

Hi!
There is an example using ct.raw but it's not included in the
'sourcedata' tarball:
/home/morph/deb/build-area/matplotlib-1.0.1/build/lib.linux-x86_64-2.6/matplotlib/sphinxext/plot_directive.py:322:
PlotWarning: Exception running plot
/home/morph/deb/build-area/matplotlib-1.0.1/doc/mpl_examples/pylab_examples/image_demo2.py
Traceback (most recent call last):
 File "/home/morph/deb/build-area/matplotlib-1.0.1/build/lib.linux-x86_64-2.6/matplotlib/sphinxext/plot_directive.py",
line 319, in render_figures
 run_code(plot_path, function_name, plot_code, context=context)
 File "/home/morph/deb/build-area/matplotlib-1.0.1/build/lib.linux-x86_64-2.6/matplotlib/sphinxext/plot_directive.py",
line 230, in run_code
 "__plot__", fd, fname, ('py', 'r', imp.PY_SOURCE))
 File "image_demo2.py", line 9, in <module>
IOError: [Errno 2] No such file or directory:
'/home/morph/deb/build-area/matplotlib-1.0.1/sampledata/ct.raw'
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Wed, Jan 12, 2011 at 12:56 PM, Eric Firing <ef...@ha...> wrote:
> On 01/12/2011 07:20 AM, Benjamin Root wrote:
> > On Tue, Jan 11, 2011 at 3:13 PM, John Hunter <jd...@gm...
> > <mailto:jd...@gm...>> wrote:
> >
> > On Mon, Jan 10, 2011 at 6:45 PM, Benjamin Root <ben...@ou...
> > <mailto:ben...@ou...>> wrote:
> > > John,
> > >
> > > Just to clarify, have we officially released 1.0.1, or are we
> > still in the
> > > RC phase? If we haven't released yet, what is the deadline for
> final
> > > patches for 1.0.1?
> > >
> >
> > 1.0.1 is final but I held off on the announcement until Russel got
> the
> > OSX builds uploaded (which he did yesterday, but I still haven't
> > gotten to the announcement). If there are significant problems (eg
> > the 3D stuff you reported or other issues) I have no problem pushing
> > out 1.0.2 quickly.
> >
> > JDH
> >
> >
> > John,
> >
> > I am fine with letting 1.0.1 go out as is (unless we can't live with the
> > documentation typos that has shown up). I am also hesistant about
> > putting out yet another bug-fix release because there will be distros
> > that will have 1.0.0, 1.0.1, and then possibly others with 1.0.2, which
> > would turn into a maintenance nightmare. Instead, let's just let those
> > package maintainers keep up with the patches to 1.0.1.
> >
> > This also raises a question. When putting out maintenance patches, are
> > we going to have to patch 1.0.0 and 1.0.1?
> >
> > I think what happened with 1.0.1 is that while there were some clear
> > goals (solidification of the backend codes and getting the no-download
> > doc feature working), it also became a bit of a free-for-all for
> > receiving other patches (I am guilty of this). Personally, I lost sight
> > of the point of the RCs and that is to seek out and squash only the
> > show-stopper bugs. Any other patches should not go in.
> >
> > Looking forward, I think there are a couple of things that we can do for
> > the next release (1.1.0?) that would be greatly beneficial. First, I
> > think having a clear and firm (but not set-in-stone) release date is
> > important. Second, release candidates should probably be made available
> > for a couple of weeks. Third, I think when it comes time for a release,
> > there should be at least one or two other developers agreeing on the
> > release (the purpose of this is to give a last-chance for any
> > objections, and to share the responsibility of the release). Last,
> > there should probably be clearer goals/milestones for the releases.
> >
> > I would appreciate any thoughts/comments on this. We can start up a new
> > thread if it is more appropriate.
> >
> > Ben Root
> >
>
> Ben,
>
> It sounds like what you are talking about is more like the way numpy has
> been working, complete with a release manager. Would you be willing and
> able to take on that role, along with all the other excellent work you
> have been doing? It would be a big step forward for mpl, I think.
>
> Eric
>
>
I agree, I think that is the direction MPL needs to go. We are
feature-packed, but still have a lot of rough edges. The prospect of being
a release manager is great, but it will depend on when we plan to release if
I will have enough time to devote to that.
Ben Root

On Wed, Jan 12, 2011 at 1:09 PM, Sandro Tosi <mo...@de...> wrote:
> On Wed, Jan 12, 2011 at 18:20, Benjamin Root <ben...@ou...> wrote:
> > I am fine with letting 1.0.1 go out as is (unless we can't live with the
>
> is already out: look at SF download page to see how many have downloaded
> it.
>
> > documentation typos that has shown up). I am also hesistant about
> putting
> > out yet another bug-fix release because there will be distros that will
> have
> > 1.0.0, 1.0.1, and then possibly others with 1.0.2, which would turn into
> a
> > maintenance nightmare. Instead, let's just let those package maintainers
> > keep up with the patches to 1.0.1.
> >
> > This also raises a question. When putting out maintenance patches, are
> we
> > going to have to patch 1.0.0 and 1.0.1?
>
> If you're saying you want to publish another tarball with version
> 1.0.1 that has different contents of the current one, than with my
> distro package maintainer and programmer hats on I say "you should
> not". If you have published (and not advertised, ok) something, you
> cannot re-publish the same version but with something "different" in
> it. Just go with 1.0.2, distros have (usually) the latest version and
> you are free to release patches in the HEAD of your development tree:
> it's a distro package maintainer evaluate if this patches are to be
> backported to the distro version, if the version cannot be bring
> up-to-date with the latest release.
>
> Cheers,
>
I believe we are actually in agreement, but perhaps I wasn't clear enough.
The maintenance patches that I speak of are committed in the v1_0_maint
branch of the svn repo. The tarball still has the original code from the
release point regardless of what patches have been committed since then.
Package maintainers can choose to cherry-pick those patches or even track
that maintenance branch for their own packaging purposes. The point is that
new features should not be added (unless absolutely necessary) and that old
features are not removed on that branch.
Please see our coding guide under "Committing Changes" (particularly the
last bullet):
> Keep the maintenance branch (0.91) the latest release branch (eg 0.98.4)
> and trunk in sync where it makes sense. If there is a bug on both that needs
> fixing, use svnmerge.py <http://www.orcaware.com/svn/wiki/Svnmerge.py> to
> keep them in sync.
>
So, back to the issue regarding whether to put out a 1.0.2 or not. We will
always be wanting to patch things (lord knows there are enough bugs...) and
at some point we have to say "it is good enough". Right now, my only major
qualm with the current 1.0.1 release has been the documentation (by the way,
the Coding Guide page looks terrible on my small screen). Code-wise, I am
willing to accept it as is and start focusing on 1.1.0.
Ben Root

On Wed, Jan 12, 2011 at 23:59, Sandro Tosi <mo...@de...> wrote:
> Hello MPL Devs,
>
> On Tue, Jan 4, 2011 at 20:13, Jakub Wilk <jw...@de...> wrote:
>> Package: python-matplotlib-doc
>> Version: 0.99.3-1
>> Severity: glitch
>> User: pyt...@li...
>> Usertags: sphinx1.0
>> Tags: patch
>>
>> See the attached patch.
>
> Jakub wrote a patch that fix the link from draw_markers() in
> api_change to its documentation. It's exploited when using sphinx1.x,
> I'm forwarding the patch to let it be applied upstream.
Now with attachment :)
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi