matplotlib-devel Mailing List for matplotlib (Page 4)

On Sun, May 25, 2008 at 11:50 AM, Tony Yu <ts...@gm...> wrote:

> I must admit, I was a little worried when you suggested adding a big
> equation in the background, but I think you did a good job of making it look
> nice. Unfortunately, I get an error when I try to run the logo2 script:

I'm not wed to it, so just experiment.

> AttributeError: 'NoneType' object has no attribute 'get_ticklabels'
> module body in logo2.py at line 23
> for label in ax.get_xticklabels() + ax.get_yticklabels():
> If I comment-out that for-block, I run into another error:
> NotImplementedError: xlim not meaningful for polar axes
> module body in logo2.py at line 43
> ax.set_xlim(-2*sigma, 2*sigma)
> I'm guessing the first error is a trunk vs. v0_91_maint issue? Is the second

You need to be on the trunk and I think I was a commit behind -- try it now.

We will probably want to set the various ticklabel and title sizes to
something really small using rc

import matplotlib
matplotlib.rcParams['xtick.labelsize']  = 6

so that we can tweak all these in one place at the top of the script.

JDH

On May 25, 2008, at 12:13 PM, John Hunter wrote:
>
> I played around with this a bit this morning -- it may be too busy for
> your OS X sensibilities, but let me know if you think think this is an
> approach wotrh pursuing.  I've added the mathtext background and a few
> axes and there are a few more axes to do.  In svn as
> examples/api/logo2.py

I must admit, I was a little worried when you suggested adding a big  
equation in the background, but I think you did a good job of making  
it look nice. Unfortunately, I get an error when I try to run the  
logo2 script:

AttributeError: 'NoneType' object has no attribute 'get_ticklabels'

module body in logo2.py at line 23
for label in ax.get_xticklabels() + ax.get_yticklabels():

If I comment-out that for-block, I run into another error:

NotImplementedError: xlim not meaningful for polar axes

module body in logo2.py at line 43
ax.set_xlim(-2*sigma, 2*sigma)

I'm guessing the first error is a trunk vs. v0_91_maint issue? Is the  
second a naming error in the commit? Maybe axhist.set_xlim instead of  
ax.set_xlim?

Overall I really like the new logo, but I'd like play around with it a  
bit for kicks.

Thanks!
-Tony

On Sun, May 25, 2008 at 8:18 AM, John Hunter <jd...@gm...> wrote:

> Also, the banner should be generated as  a matplotlib figure rather
> than put together in inkscape or something like that.  How did you
> make this -- if is code, please post so we can play along.  If not,
> see if you can write the logo example by laying out the axes just so.

I played around with this a bit this morning -- it may be too busy for
your OS X sensibilities, but let me know if you think think this is an
approach wotrh pursuing.  I've added the mathtext background and a few
axes and there are a few more axes to do.  In svn as
examples/api/logo2.py

JDH

import numpy as np
import matplotlib.pyplot as plt
import matplotlib.cm as cm
import matplotlib.mlab as mlab

axalpha = 0.05
figcolor = '#FFFFCC'
dpi = 80
fig = plt.figure(figsize=(8, 2),dpi=dpi)
fig.figurePatch.set_edgecolor(figcolor)
fig.figurePatch.set_facecolor(figcolor)

# the polar bar plot
ax = fig.add_axes([0.05, 0.05, 0.2, 01], polar=True)
ax.axesPatch.set_alpha(axalpha)
N = 20
theta = np.arange(0.0, 2*np.pi, 2*np.pi/N)
radii = 10*np.random.rand(N)
width = np.pi/4*np.random.rand(N)
bars = ax.bar(theta, radii, width=width, bottom=0.0)
for r,bar in zip(radii, bars):
    bar.set_facecolor( cm.jet(r/10.))
    bar.set_alpha(0.5)

for label in ax.get_xticklabels() + ax.get_yticklabels():
    label.set_visible(False)


# the histogram
axhist = fig.add_axes([0.275, 0.075, 0.2, 0.4])
axhist.axesPatch.set_alpha(axalpha)
mu, sigma = 100, 15
x = mu + sigma*np.random.randn(10000)

# the histogram of the data
n, bins, patches = axhist.hist(x, 50, normed=1, facecolor='green',
edgecolor='green', alpha=0.75)


y = mlab.normpdf( bins, mu, sigma)
l = axhist.plot(bins, y, 'r', lw=1)

axhist.set_title('Density of IQ',fontsize=6)
axhist.set_xlabel('IQ', fontsize=6)
axhist.set_ylabel('P(IQ)', fontsize=6)
ax.set_xlim(-2*sigma, 2*sigma)
for label in axhist.get_xticklabels() + axhist.get_yticklabels():
    label.set_visible(False)


axback = fig.add_axes([0., 0., 1., 1.])

#the math background
tex = r"$W^{3\beta}_{\delta_1 \rho_1 \sigma_2} = U^{3\beta}_{\delta_1
\rho_1} + \frac{1}{8 \pi 2} \int^{\alpha_2}_{\alpha_2} d
\alpha^\prime_2 \left[\frac{ U^{2\beta}_{\delta_1 \rho_1} -
\alpha^\prime_2U^{1\beta}_{\rho_1 \sigma_2} }{U^{0\beta}_{\rho_1
\sigma_2}}\right]$"
axback.text(0.5, 0.5, tex,
            transform=axback.transAxes, color="0.5", alpha=0.5, fontsize=40,
            ha='center', va='center')
axback.set_axis_off()

# the matplotlib title
axback.text(0.3, 0.95, 'matplotlib', color='black', fontsize=75,
           ha='left', va='top', alpha=1.0,
           transform=axback.transAxes)


fig.savefig('logo2.png', facecolor=figcolor, edgecolor=figcolor, dpi=dpi)
plt.show()

On Sat, May 24, 2008 at 11:21 PM, Tony Yu <ts...@gm...> wrote:

> I don't know if you were planning to accept submissions, but here's a logo
> with some of my favorite plots from examples.zip:

Submissions are extremely welcome, and I like the approach.  I think
you might experiment with another font for the main text, and try to
incorporate some display of mathtext since this is a real selling
point.  We also need one version that is no wider that 200 pages for
the sphinx navigation toolbar, so we will need to be judicious for
that one.  But the one for the web page can be much larger, and I like
this as  start.  Is there anything we can do with the background to
make it a little more interesting?  A very large equation that spans
most of the background but is so light in color (a gray with a low
alpha) that it very faint?

Also, the banner should be generated as  a matplotlib figure rather
than put together in inkscape or something like that.  How did you
make this -- if is code, please post so we can play along.  If not,
see if you can write the logo example by laying out the axes just so.

JDH

On May 23, 2008, at 4:34 PM, John Hunter wrote:

> On Fri, May 23, 2008 at 3:31 PM, Darren Dale  
> <dar...@co...> wrote:
>
>> commit yout customizing.txt?
>
> done.
>
> I just discovered l
>
>
>    # The name of an image file (within the static path) to place at  
> the top of
>    # the sidebar.
>    #html_logo = 'logo.png'
>
> so I have to get to work creating a new cool mpl figure for the logo.
> Our old banner is so 70s.

I don't know if you were planning to accept submissions, but here's a  
logo with some of my favorite plots from examples.zip:

On Sat, May 24, 2008 at 6:02 PM, Olle Engdegård <ol...@fy...> wrote:

> I very much miss the 'l' shortcut for toggling log/lin y-scale in the
> trunk! I use it a lot.
>
> I suggest restoring it with something like
>
> if self.get_yscale() is ("log" or "linear"):
>    self.toggle_log_lineary()
> else: pass
>
> I think most of time most people use log or linear scales.


This seems reasonable, but when I tried to implement it it looked like
the nan mask for the simple_plot.py example was sticky, eg when I
toggled back to linear the negative values were still masked.  I tried
a simpler example still (all positive y data) and got something very
strange: the plotted y values appear to change on a toggle from log
and back to linear:

In [18]: import matplotlib.pyplot as plt

In [19]: plt.close('all')

In [20]: ax = plt.subplot(111)

In [21]: ax.plot(np.random.rand(20))
Out[21]: [<matplotlib.lines.Line2D object at 0x123082f0>]

In [22]: ax.set_yscale('linear'); ax.figure.canvas.draw()

In [23]: ax.set_yscale('log'); ax.figure.canvas.draw()

In [24]: ax.set_yscale('linear'); ax.figure.canvas.draw()  # the y
data are now plotted differently


I am not sure what is going on yet, but I'm sure Michael will chime in
since I think we are seeing some funkiness in the new transforms and
path infrastructure.


> The new hist() function looks really good, I especially welcome the "step"
> mode. A couple of comments:
>
> The latest svn incarnation doesn't allow for log scale in step-mode
> (unless you set it manually).
>
> Also, I think the step-mode should have fill=False as default, otherwise
> it does not look that much different from bar-mode. The nice thing about
> step histograms is that you can put several of them in the same plot while
> keeping it intelligible!

Manuel is the developer behind these nice new changes to hist --
hopefully he can help you here.


JDH

On Sat, May 24, 2008 at 6:29 PM, Tony Yu <ts...@gm...> wrote:

> I think this is what you're asking for, but I may have done the diff from
> the wrong directory.

I think the last one was a plain-ol-diff and this one is a svn diff so
it is better. I have applied it and committed it.  FYI, I  normally do
the svn diff at the same level that the setup.py resides in, but it is
easy enough to correct for,

> One last thing: is there some sort of tutorial for beginners who *may* want
> to contribute. Like a "Getting Started" page for developers. I have tons of
> questions, but I don't want to spam this list. For example: I checked out
> the maintenance version of MPL but the build and install set everything up
> in a new/separate directory. This means my subversion working copy is
> separate from the installed copy (what actually gets imported).

In the svn trunk, there are a few documents in docs/devel (you need a
fesh checkout to find it) that contain coding style guidelines, but
they are rather incomplete.  We are in the process of a documentation
push, so we hope to add to these.  Your questions are welcome, just
batch them into just one or a few emails rather than a ton of
individual ones.  Perhaps one of your first projects can to write the
"getting_started.rst"  for the developer's guide as you learn the
ropes.  We can all pitch in with answers to your questions...  In my
experience, one of the best time to write introductory documentation
is when you are learning something he first time, because the more
seasoned developers have trouble approaching the subject from the
perspective of a beginner.

JDH

On May 23, 2008, at 7:05 PM, John Hunter wrote:
>
> Could I ask you to submit a svn diff of the maintenance branch -- this
> will be easier for me to apply.  simoply make your changes in the
> branch and then do
>
>> svn diff > my.patch
>
> and send that.

I think this is what you're asking for, but I may have done the diff  
from the wrong directory.

Hi,

I very much miss the 'l' shortcut for toggling log/lin y-scale in the 
trunk! I use it a lot.

I suggest restoring it with something like

if self.get_yscale() is ("log" or "linear"):
    self.toggle_log_lineary()
else: pass

I think most of time most people use log or linear scales.

The new hist() function looks really good, I especially welcome the "step" 
mode. A couple of comments:

The latest svn incarnation doesn't allow for log scale in step-mode 
(unless you set it manually).

Also, I think the step-mode should have fill=False as default, otherwise 
it does not look that much different from bar-mode. The nice thing about 
step histograms is that you can put several of them in the same plot while 
keeping it intelligible!


Cheers,
/Olle

I just reorganized the docs directory, now called "docs".  I thought
it would be easier to get a totally clean start, and the project is
early enough that I don't think losing version history is too
important.  Basically, once we learned we needed to build everything
at once to get the links working, all of the stuff Darren initially
set up and then changed on my request was basically right so I
reverted to a similar organization.  Actually, I checked out the
python docs and tried to follow their model as closely as possible,
including the use of the rst extension.  Since ipython, numpy and
scipy are moving or have moved to a sphinx documentation system, the
more we all follow the same conventions the easier it will be to mix
and match documents, build books out of them, etc...

Every subdoc project has a index.rst file and several other rst files
(since python uses rst I figures we should too).  The subdoc dirs are
"users", "devel", and "api".  I created some symlinks in the top level
"docs" directory in case we need to refer to mpl-data or the examples
subdir in the rst documents w/o having to have crazy relative paths
that may change.  This is explained in the documenting_mpl.rst file.

Let me know if you have any problems...

JDH

John,

Thank you!

Eric


John Hunter wrote:

> It appears the hist call is killing it (comment out that one line and
> it runs fine).

On Fri, May 23, 2008 at 6:14 PM, Darren Dale <dar...@co...> wrote
> I have to break here for the weekend, I'll be back monday afternoon. Leave
> some for me! (although I'll owe doughnut to whoever can fix the arrow
> docstring).

I'll claim that doughnut.

This is a bit complicated.  The problem is that we have to do the
interpolation into the patch doc strings at class definition time (eg
for Patch and Rectangle), but we can't use the object inspector and
doc string generator artist.kwdoc to automatically generate them until
*after* they are defined.  So we have a bit of a race condition.  The
solution, which is not terribly elegant, is to define the string for
the *classes* manually with the setting at the top of
matplotlib.patches:

  artist.kwdocd['Patch'] = """\
          alpha: float
          animated: [True | False]
          antiali

We interpolate this into the class docstrings.  Once the classes are
defined, we can introspect the class and auto generate the strings for
use in *methods* that operate on class instances.  At the bottom of
patches:

    artist.kwdocd['Patch'] = patchdoc = artist.kwdoc(Patch)

    artist.kwdocd['Patch'] = patchdoc = artist.kwdoc(Patch)
    for k in ('Rectangle', 'Circle', 'RegularPolygon', 'Polygon',
'Wedge', 'Arrow',
              'FancyArrow', 'YAArrow', 'CirclePolygon', 'Ellipse'):
        artist.kwdocd[k] = patchdoc

so the changes you make in the kwdocd dict will affect the classes in
matplotlib.patches, bu will not affect the docstrings in the plotting
functions, eg matplotlib.axes.Axes.arrow, which will use the
auto-generated version from artist.kwdoc.  So you need to make your
changes in two places:  in the kwdocd dict at the top of patches, as
you did before, *and* in the artist.kwdoc function which
auto-generates the property tables.  If this function returns rest
tables, you will be in good shape.  It is not good design to have to
make the changes in two places, but when we implemented this we could
not find a way to do the class doc string interpolation after the
class was defined, but we still wanted to use the autogenerated docs
where possible (eg in methods that handle artists like the plotting
methods) since the auto-generated stuff is more likely to remain
current.

Maybe an entry in the developer's guide is warranted....

Enjoy your vacation.

JDH

On Fri, May 23, 2008 at 5:50 PM, Eric Firing <ef...@ha...> wrote:
> With all the commits coming in, I thought I would try running
> backend_driver.py Template to make sure things were still working.  When
> it got to mri_with_eeg, it stopped, initially cpu use was pegged, then
> my feisty box went into swap hell.  It took about 5 minutes to extract
> it; Ctrl-Cing the python process was not enough.
>
> Anyone have any idea what might have gone wrong?  I also tried running
> mri_with_eeg standalone, with gtkAgg backend, and it again ran away.  I
> stopped it before it rendered the machine completely unresponsive.

It appears the hist call is killing it (comment out that one line and
it runs fine).

Manuel recently made some changes to hist to support 2D arrays: a
nsamples x nvariables array will generate nvariables different
histograms lined up side by side.  In mir_with_eeg, the image data is
going into hist  with shape (1, 28399) so it is trying to do 28399
histograms with one element each.  I added some logic to handle this
case:

        x = np.asarray(x).copy()
        if len(x.shape)==2 and min(x.shape)==1:
            x.shape = max(x.shape),

        if len(x.shape)==2 and x.shape[0]<x.shape[1]:
            warnings.warn('2D hist should be nsamples x nvariables;
this looks transposed')

mri_with_eeg is working fine again in svn.

Manuel -- sorry I haven't gotten time to comment on the hist changes
but I think this is a very nice addition so thanks for adding it.
Just a reminder: when you make changes, it is good habit to run the
backend_driver.py example which may catch something you forgot to
test.  BTW - the new examples in histogram_demo_extended.py look
great.

JDH

On Friday 23 May 2008 6:06:30 pm Eric Firing wrote:
> >     xcorr(*args, **kwargs)
> >         XCORR(x, y, normed=False, detrend=mlab.detrend_none,
> > usevlines=False, **kwargs):
>
> Sorry I'm not helping yet, but while you are in the middle of all this,
> please ditch the ugly and misleading Matlab-style capitalization of the
> function names.
>
> Thanks for all the work and amazing progress.

Some of these docstrings are *really* hard to trace. Where does pyplot.arrow 
get its docstring? It looks like it comes from axes.arrow, which gets a bit 
from patches.FancyArrow, which gets a bit from patches.Patch, which gets a 
bit from artist.kwdocd['Patch'] at the top of patches.py. However, I have 
completely rewritten artist.kwdocd['Patch']:

artist.kwdocd['Patch'] = """

        =================   ==============================================
        Property            Description
        =================   ==============================================
        alpha               float
        animated            [True | False]
        antialiased or aa   [True | False]
        clip_box            a matplotlib.transform.Bbox instance
        clip_on             [True | False]
        edgecolor or ec     any matplotlib color
        facecolor or fc     any matplotlib color
        figure              a matplotlib.figure.Figure instance
        fill                [True | False]
        hatch               unknown
        label               any string
        linewidth or lw     float
        lod                 [True | False]
        transform           a matplotlib.transform transformation instance
        visible             [True | False]
        zorder              any number
        =================   ==============================================

        """

but the change has not propagated up to pyplot.arrow.

I have to break here for the weekend, I'll be back monday afternoon. Leave 
some for me! (although I'll owe doughnut to whoever can fix the arrow 
docstring).

Darren

On Fri, May 23, 2008 at 4:59 PM, Tony Yu <ts...@gm...> wrote:

> As you can tell, I'm not an experienced programmer. In any case, I've
> attached a patch of "backend_wx.py" for the v0_91_maint branch. I didn't
> know if I was supposed to do something with the filepaths in the patch
> before sending it.

Hey Tony -- thanks for the patch -- it looks like you rapidly are
becoming a developer :-)

Could I ask you to submit a svn diff of the maintenance branch -- this
will be easier for me to apply.  simoply make your changes in the
branch and then do

> svn diff > my.patch

and send that.

I think your icons look nice, but I was surprised that they were
grayscale.  Is this a minimalist aesthetic?

Also, please keep all replies on list rather than to me personally
because someone else could be the one to ultimately handle the patch.

JDH

With all the commits coming in, I thought I would try running 
backend_driver.py Template to make sure things were still working.  When 
it got to mri_with_eeg, it stopped, initially cpu use was pegged, then 
my feisty box went into swap hell.  It took about 5 minutes to extract 
it; Ctrl-Cing the python process was not enough.

Anyone have any idea what might have gone wrong?  I also tried running 
mri_with_eeg standalone, with gtkAgg backend, and it again ran away.  I 
stopped it before it rendered the machine completely unresponsive.

Eric

>     xcorr(*args, **kwargs)
>         XCORR(x, y, normed=False, detrend=mlab.detrend_none,
> usevlines=False, **kwargs):

Sorry I'm not helping yet, but while you are in the middle of all this, 
please ditch the ugly and misleading Matlab-style capitalization of the 
function names.

Thanks for all the work and amazing progress.

Eric

On May 23, 2008, at 4:47 PM, John Hunter wrote:

> On Fri, May 23, 2008 at 2:00 PM, Tony Yu <ts...@gm...> wrote:
>> Hi,
>>
>> I apologize if this isn't the right forum for this email; I'm not
>> actually a matplotlib developer.
>>
>> I was trying to use custom icons for the mpl Wx backend, but the
>> version of mpl I was using had a _load_bitmap method that only read
>> xpm bitmaps. This requirement is enforced by the wx.BITMAP_TYPE_XPM
>> flag on:
>>
>> line 1398 of backend_wx.py in trunk
>> line 1458 of backend_wx.py in v0_91_maint
>>
>> The default flag wx.BITMAP_TYPE_ANY allows wx to autodetect the
>> format. Deleting the wx. BITMAP_TYPE_XPM argument allows me to change
>> to toolbar icons to png files. I noticed that the trunk and
>> v0_91_maint versions of mpl have a _load_pngicon method to load png
>> icons. This additional method seems unnecessary (or am I missing
>> something) if the offending argument is deleted.
>
> We made these changes recently on the advice of a user, but I am no wx
> guru.  If you can post a patch that behaves properly and uses the png
> icons (the xpms don't render properly on some platforms). that would
> be great.

I'd like to try, but I've never contributed to a software project so  
submitting a patch seems pretty daunting. I'll have to read up on how  
to do this.

>
>
>> One final note: I made some new icons for the toolbars of the plot
>> windows. I'm not sure if many people would be interested in them  
>> since
>> I've made them following a OS X aesthetic (also, I replaced the home
>> icon with a reload icon because that made more sense to me). In any
>> case, I'd like to make these available as an alternative, but I'm not
>> sure where to post them.
>
> post them here as a small screenshot or just attach the icons.  They
> can't be that large.  I'm the list moderator so I can approve it if
> there is a problem.  What I'd really like to see is a patch that
> allows users to customize the toolbar, eg by adding buttons, removing
> buttons, or changing the icons.  This is not easy, especially across
> the user interfaces.  Our toolbars would need to expose some common
> api for this...

Here are the pngs:

On Friday 23 May 2008 04:57:24 pm John Hunter wrote:
> On Fri, May 23, 2008 at 3:47 PM, Darren Dale <dar...@co...> 
wrote:
> >> so I have to get to work creating a new cool mpl figure for the logo.
> >> Our old banner is so 70s.
> >
> > I wasn't going to say it... but yeah. :)
>
> Thanks for your sensitivity :-)

haha! I hope you stick with your eeg, its just the colorscheme and fonts that 
are outdated.

> I made that a long time ago when I was 
> really proud that I could set the font size on text!
>
> > I think we need to set a policy on how we are going to handle code in
> > docstrings. There are lots of places where indentation and asterisks are
> > causing trouble. Should examples be codeblocks (::) or doctests (>>>)? I
> > think inlines should just be `` quoted, like:
> >
> > data are plotted as ``plot(lags, c, **kwargs)``
>
> Works for me -- we should prefer code blocks whether than inlines just
> because they are more readable w/o the quotes, but if we need inlines
> in some cases we'll use 'em
>
> > Here is an example from axes.Axes:
> >
> > def xcorr(self, x, y, normed=False, detrend=mlab.detrend_none,
> >    usevlines=False, maxlags=None, **kwargs):
> >    """
> >    XCORR(x, y, normed=False, detrend=mlab.detrend_none, usevlines=False,
> >        **kwargs):a
> >
> > Can we eliminate the call signature? I think this is only necessary for
> > extension code, the call signature will already be displayed by sphinx
> > and by pythons interactive help.
>
> Unfortunately, I think we need it.  pyplot xcorr is just a *args,
> **kwargs pass though to Axes.xcorr, so if you do help pyplot.xcorr you
> won't see the signature, which is why we manually copy the signature
> in axes.py.

Oh, right.

>     In [89]: help pyplot.xcorr
>     Help on function xcorr in module matplotlib.pyplot:
>
>     xcorr(*args, **kwargs)
>         XCORR(x, y, normed=False, detrend=mlab.detrend_none,
> usevlines=False, **kwargs):
>
>         Plot the cross correlation between x and y.  If normed=True,
>         normalize the data but the cross correlation at 0-th lag.  x
>         and y are detrended by the detrend callable (default no
>         normalization.  x and y must be equal length
>
> We could use a codeblock in axes.py
>     def xcorr(self, x, y, normed=False, detrend=mlab.detrend_none,
> usevlines=False,
>               maxlags=None, **kwargs):
>         """
>         pyplot signature:
>
>             xcorr(x, y, normed=False, detrend=mlab.detrend_none,
> usevlines=False, **kwargs):
>
>         Plot the cross correlation between x and y.  If normed=True,
>         normalize the data but the cross correlation at 0-th lag.  x
>         and y are detrended by the detrend callable (default no

How about Use:, or Usage: or Signature:? Most of these exist outside of 
pyplot.

On Fri, May 23, 2008 at 3:47 PM, Darren Dale <dar...@co...> wrote:

>> so I have to get to work creating a new cool mpl figure for the logo.
>> Our old banner is so 70s.
>
> I wasn't going to say it... but yeah. :)

Thanks for your sensitivity :-) I made that a long time ago when I was
really proud that I could set the font size on text!

> I think we need to set a policy on how we are going to handle code in
> docstrings. There are lots of places where indentation and asterisks are
> causing trouble. Should examples be codeblocks (::) or doctests (>>>)? I
> think inlines should just be `` quoted, like:
>
> data are plotted as ``plot(lags, c, **kwargs)``

Works for me -- we should prefer code blocks whether than inlines just
because they are more readable w/o the quotes, but if we need inlines
in some cases we'll use 'em

> Here is an example from axes.Axes:
>
> def xcorr(self, x, y, normed=False, detrend=mlab.detrend_none,
>    usevlines=False, maxlags=None, **kwargs):
>    """
>    XCORR(x, y, normed=False, detrend=mlab.detrend_none, usevlines=False,
>        **kwargs):a
>
> Can we eliminate the call signature? I think this is only necessary for
> extension code, the call signature will already be displayed by sphinx and by
> pythons interactive help.

Unfortunately, I think we need it.  pyplot xcorr is just a *args,
**kwargs pass though to Axes.xcorr, so if you do help pyplot.xcorr you
won't see the signature, which is why we manually copy the signature
in axes.py.


    In [89]: help pyplot.xcorr
    Help on function xcorr in module matplotlib.pyplot:

    xcorr(*args, **kwargs)
        XCORR(x, y, normed=False, detrend=mlab.detrend_none,
usevlines=False, **kwargs):

        Plot the cross correlation between x and y.  If normed=True,
        normalize the data but the cross correlation at 0-th lag.  x
        and y are detrended by the detrend callable (default no
        normalization.  x and y must be equal length

We could use a codeblock in axes.py
    def xcorr(self, x, y, normed=False, detrend=mlab.detrend_none,
usevlines=False,
              maxlags=None, **kwargs):
        """
        pyplot signature:

            xcorr(x, y, normed=False, detrend=mlab.detrend_none,
usevlines=False, **kwargs):

        Plot the cross correlation between x and y.  If normed=True,
        normalize the data but the cross correlation at 0-th lag.  x
        and y are detrended by the detrend callable (default no


> Regarding the crazy pyplot error, I'm doing it the slow, painful way,
> including a few members at a time in the members list and fixing the errors
> that arise.

Ugg, I don't envy you.  Perhaps a message to the maintainer about the
need for some verbose context in these error messages would be more
expeditious.  We have a lot of these to do.

Another feature I'd like to see is a macro location parameter.  Eg

    define location:`mplexamples` = ../../examples/pyplot

and then later be able to refer to that

    .. literalinclude:: location:`mplexamples`/simple_plot.py

with whatever syntax is appropriate so as we reorganize we don't have
to keep fixing the relative path structure.  Eg, I am including icons
from mpl/data/images in the navigation toolbar section....

JDH

On Fri, May 23, 2008 at 2:00 PM, Tony Yu <ts...@gm...> wrote:
> Hi,
>
> I apologize if this isn't the right forum for this email; I'm not
> actually a matplotlib developer.
>
> I was trying to use custom icons for the mpl Wx backend, but the
> version of mpl I was using had a _load_bitmap method that only read
> xpm bitmaps. This requirement is enforced by the wx.BITMAP_TYPE_XPM
> flag on:
>
> line 1398 of backend_wx.py in trunk
> line 1458 of backend_wx.py in v0_91_maint
>
> The default flag wx.BITMAP_TYPE_ANY allows wx to autodetect the
> format. Deleting the wx. BITMAP_TYPE_XPM argument allows me to change
> to toolbar icons to png files. I noticed that the trunk and
> v0_91_maint versions of mpl have a _load_pngicon method to load png
> icons. This additional method seems unnecessary (or am I missing
> something) if the offending argument is deleted.

We made these changes recently on the advice of a user, but I am no wx
guru.  If you can post a patch that behaves properly and uses the png
icons (the xpms don't render properly on some platforms). that would
be great.

> One final note: I made some new icons for the toolbars of the plot
> windows. I'm not sure if many people would be interested in them since
> I've made them following a OS X aesthetic (also, I replaced the home
> icon with a reload icon because that made more sense to me). In any
> case, I'd like to make these available as an alternative, but I'm not
> sure where to post them.

post them here as a small screenshot or just attach the icons.  They
can't be that large.  I'm the list moderator so I can approve it if
there is a problem.  What I'd really like to see is a patch that
allows users to customize the toolbar, eg by adding buttons, removing
buttons, or changing the icons.  This is not easy, especially across
the user interfaces.  Our toolbars would need to expose some common
api for this...

JDH

On Friday 23 May 2008 04:34:11 pm John Hunter wrote:
> On Fri, May 23, 2008 at 3:31 PM, Darren Dale <dar...@co...> 
wrote:
> > commit yout customizing.txt?
>
> done.
>
> I just discovered l
>
>
>     # The name of an image file (within the static path) to place at the
> top of # the sidebar.
>     #html_logo = 'logo.png'
>
> so I have to get to work creating a new cool mpl figure for the logo.
> Our old banner is so 70s.

I wasn't going to say it... but yeah. :)

I think we need to set a policy on how we are going to handle code in 
docstrings. There are lots of places where indentation and asterisks are 
causing trouble. Should examples be codeblocks (::) or doctests (>>>)? I 
think inlines should just be `` quoted, like:

data are plotted as ``plot(lags, c, **kwargs)``

Here is an example from axes.Axes:

def xcorr(self, x, y, normed=False, detrend=mlab.detrend_none,        
    usevlines=False, maxlags=None, **kwargs):
    """
    XCORR(x, y, normed=False, detrend=mlab.detrend_none, usevlines=False, 
        **kwargs):a 

Can we eliminate the call signature? I think this is only necessary for 
extension code, the call signature will already be displayed by sphinx and by 
pythons interactive help.


Regarding the crazy pyplot error, I'm doing it the slow, painful way, 
including a few members at a time in the members list and fixing the errors 
that arise.

Darren

On Fri, May 23, 2008 at 3:31 PM, Darren Dale <dar...@co...> wrote:

> commit yout customizing.txt?

done.

I just discovered l


    # The name of an image file (within the static path) to place at the top of
    # the sidebar.
    #html_logo = 'logo.png'

so I have to get to work creating a new cool mpl figure for the logo.
Our old banner is so 70s.

JDH

On Friday 23 May 2008 04:12:51 pm John Hunter wrote:
> On Fri, May 23, 2008 at 3:00 PM, Darren Dale <dar...@co...> 
wrote:
> > On Friday 23 May 2008 03:02:55 pm John Hunter wrote:
> >> On Fri, May 23, 2008 at 9:54 AM, John Hunter <jd...@gm...> wrote:
> >> > It certainly would make the docs more useful to be able to link to the
> >> > class and function references.  Argg.  I guess I'll just have to give
> >> > up my desire to have clean ASCII here, since most people are going to
> >> > read this on the web or as PDF so we should target that.  One
> >> > question: suppose we use class:`Line2D` and include the reference docs
> >> > in a single build, eg for the web site and a master PDF, but we want
> >> > to provide on some occasions a lighter PDF, eg just a few of the docs
> >> > w/o the reference.  Will sphinx be somewhat smart and just format the
> >> > class:`Line2D` as monospace when it cannot find the references?
> >>
> >> I've been experimenting with including the api docs in the same build
> >> to see if I could get linking to work, eg links in the pyplot tutorial
> >> to matplotlib.lines.Line2D.  I know if we go this route some more
> >> reorganization will be needed, so we should figure that out and get
> >> our commits in and then freeze while Darren does the reorg.
> >
> > I was able to get the linking to work, as I posted in my last message,
> > but forgot to address a reorg. I'm happy to do it, but I will be out of
> > town and away from a computer Saturday morning through Monday afternoon.
> > If we decide to include the api in the users guide (I think it is worth
> > considering), I can do it when I get back.
>
> OK, sounds good.
>
> I tried including the pyplot reference docs but it is croaking on the
> docstrings there.  I suppose  some of them have some invalid rest.
> Unfortunately the line numbers don't make a lot of sense
>
>    updating environment: 17 added, 0 changed, 0 removed
>     reading... add_new_projection api api_artists api_introduction
> api_pyplot reST markup error:
>    
> /home/titan/johnh/python/svn/matplotlib.trunk/matplotlib/doc/users_guide/ap
>i_pyplot.txt:1127: (SEVERE/4) Unexpected section title or transition.
>
>     ****************
>
>
> since api_pyplt.txt is just a small file which does:
>
>     *****************
>     matplotlib.pyplot
>     *****************
>
>     :mod:`matplotlib.pyplot`
>
>     =============================
>
>     .. automodule:: matplotlib.pyplot
>
>     :members:
>     :undoc-members:
>
> Have you had any success in figuring out how to know what is causing
> these kinds of errors, ie where to go in the module docs to fix them?

No, I was just having a look at that myself. Usually it gives you a little 
more to go on, like these which are now fixed except for the last one:

WARNING: <docstring of matplotlib.artist.ArtistInspector.get_aliases>:4: 
(ERROR/3) Unexpected indentation.
WARNING: <docstring of matplotlib.lines.unmasked_index_ranges>:17: (ERROR/3) 
Unexpected indentation.
WARNING: <docstring of matplotlib.lines.unmasked_index_ranges>:25: (ERROR/3) 
Unexpected indentation.
WARNING: /usr/local/src/matplotlib/matplotlib/doc/users_guide/users_guide.txt:7: 
(WARNING/2) toctree references unknown document u'customizing'

Could you commit yout customizing.txt?

On Fri, May 23, 2008 at 3:00 PM, Darren Dale <dar...@co...> wrote:
> On Friday 23 May 2008 03:02:55 pm John Hunter wrote:
>> On Fri, May 23, 2008 at 9:54 AM, John Hunter <jd...@gm...> wrote:
>> > It certainly would make the docs more useful to be able to link to the
>> > class and function references.  Argg.  I guess I'll just have to give
>> > up my desire to have clean ASCII here, since most people are going to
>> > read this on the web or as PDF so we should target that.  One
>> > question: suppose we use class:`Line2D` and include the reference docs
>> > in a single build, eg for the web site and a master PDF, but we want
>> > to provide on some occasions a lighter PDF, eg just a few of the docs
>> > w/o the reference.  Will sphinx be somewhat smart and just format the
>> > class:`Line2D` as monospace when it cannot find the references?
>>
>> I've been experimenting with including the api docs in the same build
>> to see if I could get linking to work, eg links in the pyplot tutorial
>> to matplotlib.lines.Line2D.  I know if we go this route some more
>> reorganization will be needed, so we should figure that out and get
>> our commits in and then freeze while Darren does the reorg.
>
> I was able to get the linking to work, as I posted in my last message, but
> forgot to address a reorg. I'm happy to do it, but I will be out of town and
> away from a computer Saturday morning through Monday afternoon. If we decide
> to include the api in the users guide (I think it is worth considering), I
> can do it when I get back.

OK, sounds good.

I tried including the pyplot reference docs but it is croaking on the
docstrings there.  I suppose  some of them have some invalid rest.
Unfortunately the line numbers don't make a lot of sense

   updating environment: 17 added, 0 changed, 0 removed
    reading... add_new_projection api api_artists api_introduction
api_pyplot reST markup error:
    /home/titan/johnh/python/svn/matplotlib.trunk/matplotlib/doc/users_guide/api_pyplot.txt:1127:
(SEVERE/4) Unexpected section title or transition.

    ****************


since api_pyplt.txt is just a small file which does:

    *****************
    matplotlib.pyplot
    *****************

    :mod:`matplotlib.pyplot`
    =============================

    .. automodule:: matplotlib.pyplot
    :members:
    :undoc-members:

Have you had any success in figuring out how to know what is causing
these kinds of errors, ie where to go in the module docs to fix them?

JDH