matplotlib-devel Mailing List for matplotlib

On Thu, Jul 30, 2009 at 1:56 PM, Jae-Joon Lee<lee...@gm...> wrote:
>
> ps. Are we having a sprint during the scipy conference by the way? I
> may join remotely.
I'll definitely be there Sat and Sun, so having you join in remotely
would be great. I haven't organized any official topics yet, but we
have plenty to do so I think we'll just look at the skills and
interests of those joining live or virtually and hammer away.
JDH

Hello,
I recently committed a support for a curvelinear grid in the axes_grid
toolkit. What it does for you is to draw a ticks and grid appropriate
for a curvelinear coordinate system, as in the example below.
http://matplotlib.sourceforge.net/_images/demo_floating_axis1.png
The main motivation behind this work was to display astronomical
images with matplotlib. However, I included this in the axes_grid
toolkit hoping that this could be also useful in other fields.
The reason I'm posting this email is related to a possible refactoring
of the matplolib, that John once mentioned, to better support the
ticks and spines. To support the curvelinear grid, I had to create a
customized Axes class, and I believe that some of my effort overlaps
with the refactoring that John mentioned. In the linked document
below, I tried to describe the changes I made for this.
http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/users/axislines.html
I guess some of my idea or implementation may be considered to be a
part of the refactoring (if it ever happens :) ). Or, at least, I hope
that the issues I had with mpl's current Axes implementation are
reflected in the refactoring efforts.
Well, I just wanted to toss around some ideas and hear what others think.
Regards,
-JJ
 ps. Are we having a sprint during the scipy conference by the way? I
may join remotely.

Sorry for reposting, but the original may have been overlooked since 
it was buried deep in a matplotlib-users thread.
Currently, `pyplot.rgrids` is returning tick lines instead of grid 
lines. My guess is that this is a typo, but there may be a compelling 
reason to return the tick lines. If it is a typo, here's a patch:
Index: lib/matplotlib/projections/polar.py
===================================================================
--- lib/matplotlib/projections/polar.py	(revision 7300)
+++ lib/matplotlib/projections/polar.py	(working copy)
@@ -397,7 +397,7 @@
 self._r_label2_position.clear().translate(angle, -self._rpad 
* rmax)
 for t in self.yaxis.get_ticklabels():
 t.update(kwargs)
- return self.yaxis.get_ticklines(), self.yaxis.get_ticklabels()
+ return self.yaxis.get_gridlines(), self.yaxis.get_ticklabels()
 set_rgrids.__doc__ = cbook.dedent(set_rgrids.__doc__) % kwdocd

Sorry I fell behind and did not get a release out earlier as I
intended. I am going to take another stab this weekend so we can have
something by scipy. Please commit anything you need to before the
release, and I will ask Michael to create the release branch tomorrow.
 There will still be ample time for testing and fixing stuff from the
release branch, but this will be done on the branch rather than the
trunk. Tentative schedule:
 * branch tomorrow
 * src candidate Sunday
 * win32 and osx binaries for testing monday
 * official release late next week
JDH

Him
On 30 Jul 2009, at 02:27, John Hunter wrote:
> Isn't this a bit backwards? The point of the GSOC project is to make
> the mathtext project available as a smaller, lighter, more widely
> accessible project. If it depends on mpl, what have we achieved
> except complexity? Don't we want the ft2font and png to be provided
> by mathtext, and let mpl depend on it to get the stuff there?
> Admittedly, mathtex may not be the right name (mpltext?) but
> conceptually it seems like we want the low level stuff in mathtex. Or
> am I missing your point here?
I should have made myself clearer. Mathtex will attempt to firstly 
import its own versions of FT2Font and friends. Should this fail it 
will then attempt to import those in matplotlib. So yes, mathtex still 
has all of the required dependencies, nothing has changed there.
This means that if you have matplotlib installed you can use/install 
mathtex without compiling a single C-code extension. It also means 
that when matplotlib wishes to install mathtex it only need bother 
with copying over .py files -- the same way it does for pytz.
> You can punt on the setup/dependency issue for now. In the branch,
> you can assume mathtex exists and is installed. We can worry about
> how to handle the setup and distribution issues once we have the
> package organization rationalized. A simple set of install
> instructions for developers with very explicit commands to check out
> the branch, install the deps, and test would help us test as you
> progress.
Okay, I'll revert to the previous way of doing so (cd'ing to the 
directory where mathtex is checked out and running setup.py there).
Regards, Freddie.

Hello,
I just compiled matplotlib using svn. Previously I was using a ubuntu package (version 0.98.3). I
decided to use the svn version to have mplot3d available.
Everything seem to work well but now when I start one of my python program that use matplotlib, I
have problem with the axes draw method (a problem that I had not with the version 0.98.3).
Here is the traceback.
---------------------------------------------------------------------------------------------------
Exception in Tkinter callback
Traceback (most recent call last):
 File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1417, in __call__
 return self.func(*args)
 File "./sg.py", line 1420, in <lambda>
 bInvEns = Tix.Button(bt,text='Calculer',command=lambda : self.CSInvEns(self.cfr,self.gffr))
 File "./sg.py", line 3267, in CSInvEns
 gffr.psaddData_m(u,xmin,xmax,pmin,pmax)
 File "./sg.py", line 3451, in psaddData_m
 self.psDraw(xmin,xmax,pmin,pmax)
 File "./sg.py", line 3526, in psDraw
 self.aps.draw()
TypeError: draw_wrapper() takes at least 2 arguments (1 given)
----------------------------------------------------------------------------------------------------
self.aps is an axes instance. I looked at the doc and effectively the draw method take two arguments
(the artist - which is self.aps - and the renderer - which I don't know what it is).
I suspect that prior to installing the svn version, with the 0.98.3 version, these two arguments
were given automatically to the draw method, but now it is no more the case.
As it could also be a bug (but I don't think so) I post it here. I join the log of the compilation
and the log of a test run (resp. build.out and run.out).
If you have any idea or comment, thank you in advance for sharing it with me.
Jonathan

On Wed, Jul 29, 2009 at 4:32 PM, Freddie Witherden<fr...@wi...> wrote:
> After thinking about the problem a little bit I have gone for the following
> solution. I added support for mathtex to use the wrappers provided by
> matplotlib for FT2Font and _png. It is likely we will want to keep them in
> sync anyway -- so that should not be an issue.
Isn't this a bit backwards? The point of the GSOC project is to make
the mathtext project available as a smaller, lighter, more widely
accessible project. If it depends on mpl, what have we achieved
except complexity? Don't we want the ft2font and png to be provided
by mathtext, and let mpl depend on it to get the stuff there?
Admittedly, mathtex may not be the right name (mpltext?) but
conceptually it seems like we want the low level stuff in mathtex. Or
am I missing your point here?
> However, I am having trouble working around the fact that mathtex is two
> levels deep (lib/mathtex/mathtex). I can either get the setup.py file to
> install either just the setup* stuff from mathtex or install mathtex as
> mathtex/mathtex. Not sure how to work around this.
You can punt on the setup/dependency issue for now. In the branch,
you can assume mathtex exists and is installed. We can worry about
how to handle the setup and distribution issues once we have the
package organization rationalized. A simple set of install
instructions for developers with very explicit commands to check out
the branch, install the deps, and test would help us test as you
progress.
JDH

On Wed, Jul 29, 2009 at 5:05 PM, Robert Kern<rob...@gm...> wrote:
> Furthermore, you could put numpy in there, too. Maybe even recipes for
> downloading and building the C dependencies for those who need it. Basically, by
> freeing yourself from the shackles of distutils, you can make the
> "new-to-Python-just-give-me-matplotlib" experience much less painful while
> improving the situation for downstream packagers like Linux distributions, EPD,
> and python(x,y) at the same time.
For linux, unix and os x src installs, this is imminently viable. We
already have a start on this in the mpl/releases dir to autofetch the
deps and build them, but this is for the lower level deps, like
freetype, png and zlib. We could easily extend the approach to pytz
and dateutil, and provide some enhancements (remove make, use python
instead, have some sort of configure file support). The bugaboo is
the win32 installer and OSX binary. If we don't build this stuff in,
suddenly the dependency list grows from "just install numpy" to
"install pytz, dateutil, numpy and mathtext" which is a very different
picture. As I alluded to in my earlier post, I assume there is some
way to build smart windows installers (eg along the lines of the ETS
install tool or native win32 solutions) but this is a question of
manpower. None of our core developers are primarily win32 users, and
we often struggle to get anyone to even test a win32 release
candidate, much less do the heavy lifting to build a smart installer.
The ETS and PythonXY solutions have gotten so good that maybe I should
just give up worrying making life easy for win32 users, since these
solutions already satisfy the needs of someone who wants it to work
with one or two clicks. I already aggressively point them to these
solutions on our installing page. But windows users still make up
about half of our known installations, so I don't want to be cavalier
in dismissing the importance of making it easy for them.