Re: [matplotlib-devel] problem with draw method in svn version?
On Thu, Jul 30, 2009 at 9:49 PM, Jae-Joon Lee wrote: > I guess this is related with the decorator introduced by rasterization > support. While most of the artist seems to explicitly require the renderer > instance as the second argument of the draw method, the draw method in the > Axes class have default value of None. The easiest fix seems to let the > decorator returns the method with renderer=None as in the Axes. By the way, > Jonathan, I guess the easiest workaround for you is to modify your code so > that it explicitly gives the renderer argument. I think the best approach is to use canvas draw rather than artist draw ax.figure.canvas.draw() JDH -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] pyplot.rgrids returns wrong values?
On Thu, Jul 30, 2009 at 10:01 AM, Tony Yu wrote:
> 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:
>
Doesn't pyplot.rgrids need to be fixed too:
def rgrids(*args, **kwargs):
"""
Set/Get the radial locations of the gridlines and ticklabels on a
polar plot.
call signatures::
lines, labels = rgrids()
lines, labels = rgrids(radii, labels=None, angle=22.5, **kwargs)
When called with no arguments, :func:`rgrid` simply returns the
tuple (*lines*, *labels*), where *lines* is an array of radial
gridlines (:class:`~matplotlib.lines.Line2D` instances) and
*labels* is an array of tick labels
(:class:`~matplotlib.text.Text` instances). When called with
arguments, the labels will appear at the specified radial
distances and angles.
*labels*, if not *None*, is a len(*radii*) list of strings of the
labels to use at each angle.
If *labels* is None, the rformatter will be used
Examples::
# set the locations of the radial gridlines and labels
lines, labels = rgrids( (0.25, 0.5, 1.0) )
# set the locations and labels of the radial gridlines and labels
lines, labels = rgrids( (0.25, 0.5, 1.0), ('Tom', 'Dick', 'Harry' )
"""
ax = gca()
if not isinstance(ax, PolarAxes):
raise RuntimeError('rgrids only defined for polar axes')
if len(args)==0:
lines = ax.yaxis.get_ticklines()
labels = ax.yaxis.get_ticklabels()
else:
Should
lines = ax.yaxis.get_ticklines()
be
lines = ax.yaxis.get_gridlines()
I'm going to make both these changes in svn , but I'd like you to confirm this.
JDH
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] pyplot.rgrids returns wrong values?
Sorry for sending this twice, John; I forgot to copy the list.
On Jul 31, 2009, at 9:14 AM, John Hunter wrote:
On Thu, Jul 30, 2009 at 10:01 AM, Tony Yu wrote:
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:
Doesn't pyplot.rgrids need to be fixed too:
def rgrids(*args, **kwargs):
"""
[Snip]
Should
lines = ax.yaxis.get_ticklines()
be
lines = ax.yaxis.get_gridlines()
I'm going to make both these changes in svn , but I'd like you to
confirm this.
Yes, that's correct. I called `rgrids` with arguments so I completely
missed that call to `get_ticklines`. However, I think there's a typo
in svn: yaxis.gridlines is called instead of yaxis.get_gridlines().
-T
Index: lib/matplotlib/pyplot.py
===
--- lib/matplotlib/pyplot.py(revision 7313)
+++ lib/matplotlib/pyplot.py(working copy)
@@ -1102,7 +1102,7 @@
if not isinstance(ax, PolarAxes):
raise RuntimeError('rgrids only defined for polar axes')
if len(args)==0:
-lines = ax.yaxis.gridlines()
+lines = ax.yaxis.get_gridlines()
labels = ax.yaxis.get_ticklabels()
else:
lines, labels = ax.set_rgrids(*args, **kwargs)
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 0.99 release candidate this weekend
On Thu, Jul 30, 2009 at 9:46 AM, John Hunter wrote: > 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 Michael, if you have time today, would you make the 0.99 release branch, update doc/devel/coding_guide.rst with instructions on how to check out the branch (basically just change the version numbers so people are pointed to the current branch), and paste those instructions here so developers can easily grab the release branch? Thanks, JDH -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] pyplot.rgrids returns wrong values?
On Fri, Jul 31, 2009 at 8:25 AM, Tony Yu wrote: > Yes, that's correct. I called `rgrids` with arguments so I completely missed > that call to `get_ticklines`. However, I think there's a typo in svn: > yaxis.gridlines is called instead of yaxis.get_gridlines(). Oops, thanks for catching that. Fixed in svn -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] 0.99.x maintenance branch created
A 0.99 branch has been created at: https://matplotlib.svn.sf.net/svnroot/matplotlib/branches/v0_99_maint This is where the first 0.99.0.rc1 release candidate and binary releases will be made from this weekend. All potentially disruptive or experimental changes should be made only to the trunk. *All bug fixes should be made to the branch, and then merged into the trunk.* You will need to have svnmerge.py installed. The workflow for this is as follows: 1. Check out the branch, if you haven't already: svn co https://matplotlib.svn.sf.net/svnroot/matplotlib/branches/v0_99_maint mpl99 2. Make/test bugfixes on your working copy of this branch 3. Commit your changes on this branch 4. 'cd' to your working copy of the trunk 5. Merge the changes from the branch into the trunk: svnmerge.py merge -S v0_99_maint 6. Resolve any conflicts, install, and test the merge. 7. Commit the merged changes to the trunk: svn commit -F svnmerge-commit-message.txt Let me know if you have any questions. Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] example data in example code
In some examples, I have been moving example functions and data into a
module, so that they can be run from anywhere. Many other examples
still rely on a relative path in the examples dir. Eg, I go to the
gallery and download the source for the axes grid toolkit example
simple_rgb.py, and try to run it from my desktop, I get the error "no
module names demo_image". While I know how to get the data, a naive
user will not. So in some examples I have been adopting the approach,
eg in examples/pylab_examples/scatter_demo2.py
import matplotlib
datafile = matplotlib.get_example_data('goog.npy')
These examples will run anywhere mpl is installed. Another approach
would to write a version of get_example_data that checks locally for a
datafile, and if it is not where you expect to be, attempt a
urlretrieve as a temp file.
The gallery is becoming the goto place for most users of the website,
and I would like as many examples as possible to run after a simple
download to the desktop . I am sensitive to packagers who may not
want to ship large amounts of data w/ the main library, so we may want
to minimize the amount we ship in mpl-data which
matplotlib.get_example_data uses, but it may be a good idea to setup a
new svn directory at the top level (mpl_data) and write a urllib
enabled matplotlib.get_example_data that fetches it from the repo if
it can't find it locally.
JDH
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Better pyplot wrappers
On Wed, Jul 22, 2009 at 8:15 AM, Jouni K. Seppänen wrote:
> I finally committed the "boilerplate" variant. It seems to pass the
> tests in pylab_examples, but now might be a good time for everyone to
> take a look to see if I have broken anything.
There is one problem, but I am not sure what the workaround is yet.
The doc strings in rest are broken, eg compare the pyplot Line2D
properties with the Axes equivalent:
http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.loglog
vs
http://matplotlib.sourceforge.net/api/axes_api.html#matplotlib.axes.Axes.loglog
Both use the artist.kwdocs inspector to autogenerate the tables.
There is a rc param in doc/matplotlibrc which we use to force rest
formatting
docstring.hardcopy : True # set this when you want to generate
hardcopy docstring
which is False by default for src installs and True when we build the
docs. Then in matplotlib.artist, we do
def kwdoc(a):
hardcopy = matplotlib.rcParams['docstring.hardcopy']
if hardcopy:
return '\n'.join(ArtistInspector(a).pprint_setters_rest(leadingspace=2))
else:
return '\n'.join(ArtistInspector(a).pprint_setters(leadingspace=2))
to format rest when making hardcopy.
Then we we interpolate into the docstring at runtime::
# from Axes.loglog
def loglog(self, *args, **kwargs):
"""
...snip
The remaining valid kwargs are
:class:`~matplotlib.lines.Line2D` properties:
%(Line2D)s
**Example:**
.. plot:: mpl_examples/pylab_examples/log_demo.py
"""
...snip
return l
loglog.__doc__ = cbook.dedent(loglog.__doc__) % martist.kwdocd
we get plain text when hardcopy is False and rest when it is True.
Thus we have the best of both worlds from the interactive shell and on
the website and PDF.
It looks like you are interpolating the strings in in boilerplate,
when they should be left to be interpolated *at runtime* as we do in
the other modules. Ie, it appears you are doing runtime interpolating
when you generate pyplot.py from boilerplate.py. In the old version,
the interpolation of pyplot doc strings were deferred
until runtime, eg from older pyplot.py::
# This function was autogenerated by boilerplate.py. Do not edit as
# changes will be lost
def loglog(*args, **kwargs):
# allow callers to override the hold state by passing hold=True|False
b = ishold()
h = kwargs.pop('hold', None)
if h is not None:
hold(h)
try:
ret = gca().loglog(*args, **kwargs)
draw_if_interactive()
except:
hold(b)
raise
hold(b)
return ret
if Axes.loglog.__doc__ is not None:
loglog.__doc__ = dedent(Axes.loglog.__doc__) + """
Additional kwargs: hold = [True|False] overrides default hold state"""
Is there a way to preserve this in the new boilerplate configuration?
JDH
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] example data in example code
On Fri, Jul 31, 2009 at 1:10 PM, John Hunter wrote:
> The gallery is becoming the goto place for most users of the website,
> and I would like as many examples as possible to run after a simple
> download to the desktop . I am sensitive to packagers who may not
> want to ship large amounts of data w/ the main library, so we may want
> to minimize the amount we ship in mpl-data which
> matplotlib.get_example_data uses, but it may be a good idea to setup a
> new svn directory at the top level (mpl_data) and write a urllib
> enabled matplotlib.get_example_data that fetches it from the repo if
> it can't find it locally.
OK, I committed a first pass at this to HEAD. I created a new svn
directory called mpl_data
svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/mpl_data
and a cbook.get_mpl_data function, as used in this example::
import matplotlib.cbook as cbook
import matplotlib.pyplot as plt
fname = cbook.get_mpl_data('lena.png', asfileobj=False)
print 'fname', fname
im = plt.imread(fname)
plt.imshow(im)
plt.show()
The function will check ~/.matplotlib/mpl_data and fetch it using
urllib from svn HEAD if it is not there, caching in the process. It
would be nice to support an svn revision (w/o relying on svn) as I
note in this comment in get_mpl_data:
# TODO: how to handle stale data in the cache that has been
# updated from svn -- is there a clean http way to get the current
# revision number that will not leave us at the mercy of html
# changes at sf?
If others agree w/ the basic concept, we should port as many data
requiring examples over, removing data from examples/data and
lib/matplotlib/mpl-data/example as we go. This will result in smaller
tarballs and binaries, and make the examples more portable.
JDH
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] curvelinear coordinate support in axes_grid and a possible refactoring of mpl.
John Hunter wrote: > On Thu, Jul 30, 2009 at 1:56 PM, Jae-Joon Lee 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. > I'll be there, too. I think an MPL sprint would be very good. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
