matplotlib-devel Mailing List for matplotlib (Page 3)

On Monday 23 January 2006 19:06, Ryan Krauss wrote:
> While the gnuplot approach of outputing an eps file plus a tex file
> that does all the axis labeling is probably lots easier to implement,
> I am nervous that if the tex file ever gets seperated from the eps
> file, I am left with a plot with no axis or tick mark labels - or
> labels that were accidentally editted.  That may not be a big enough
> concern to justify the extra work to parse the dvi, but it is a
> concern of mine.
>
> It may be irrational on my part, but something about a single eps file
> feels cleaner to me than the seperate eps and tex file approach.

Actually, this was what the first incarnation of usetex looked like: a ps file 
and a separate latex file. In fact, it still does that, but I put a lot of 
work into hiding that from the user and making mpl do the extra work behind 
the scenes to deliver a single eps file. I didnt like the idea of having to 
insert an eps file and some latex code on top of it. What if the file is not 
destined for a latex document? I might want to use the image with all the 
fancy markup in a poster created with inkscape or adobe illustrator.

> On 1/23/06, Matt Newville <new...@ca...> wrote:
> > Hi Darren,
> >
> > It may be very different than what you're doing, but the hybrid
> > approach of gnuplot's 'pslatex' terminal device might be worth
> > considering and looking into.  This writes postscript for the graphics
> > part and leaves simple lines (for the axes) and the text as plain
> > latex that overlays the postscript.   I think for mpl, you might want
> > to have all the non-text go into the postscript and all the text go
> > into an accompanying latex file, but the idea is the same.
> >
> > One advantage there is portability, as the output is latex+embedded
> > postscript (using \special).  It also allows pretty fine-grained
> > control on the output, including changing fonts or doing latex things
> > that mpl can't do (and this can all be done after the fact, so that
> > you can create the figure, and then change the fonts).  It does
> > require latex  to create the figure, but this step could be automated,
> > at least to stage of the dvi-with-eps-figure stage.  Getting to ps,
> > pdf, or png would be less easy to automate but may be doable in a
> > portable way.
> >
> > That sounds easier than parsing a dvi file to me.   And postscript
> > backend already exists.
> >
> >
> > --Matt
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> > files for problems?  Stop!  Download the new AJAX search engine that
> > makes searching your log files as easy as surfing the  web.  DOWNLOAD
> > SPLUNK! http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

-- 
Darren S. Dale, Ph.D.
Cornell High Energy Synchrotron Source
Cornell University
200L Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853

dd...@co...
office: (607) 255-9894
fax: (607) 255-9001

While the gnuplot approach of outputing an eps file plus a tex file
that does all the axis labeling is probably lots easier to implement,
I am nervous that if the tex file ever gets seperated from the eps
file, I am left with a plot with no axis or tick mark labels - or
labels that were accidentally editted.  That may not be a big enough
concern to justify the extra work to parse the dvi, but it is a
concern of mine.

It may be irrational on my part, but something about a single eps file
feels cleaner to me than the seperate eps and tex file approach.

Ryan

On 1/23/06, Matt Newville <new...@ca...> wrote:
> Hi Darren,
>
> It may be very different than what you're doing, but the hybrid
> approach of gnuplot's 'pslatex' terminal device might be worth
> considering and looking into.  This writes postscript for the graphics
> part and leaves simple lines (for the axes) and the text as plain
> latex that overlays the postscript.   I think for mpl, you might want
> to have all the non-text go into the postscript and all the text go
> into an accompanying latex file, but the idea is the same.
>
> One advantage there is portability, as the output is latex+embedded
> postscript (using \special).  It also allows pretty fine-grained
> control on the output, including changing fonts or doing latex things
> that mpl can't do (and this can all be done after the fact, so that
> you can create the figure, and then change the fonts).  It does
> require latex  to create the figure, but this step could be automated,
> at least to stage of the dvi-with-eps-figure stage.  Getting to ps,
> pdf, or png would be less easy to automate but may be doable in a
> portable way.
>
> That sounds easier than parsing a dvi file to me.   And postscript
> backend already exists.
>
>
> --Matt
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Darren Dale wrote:
> I would like to ask for some advice from those out there who have experience 
> dealing with fonts and text layout.
> 
> At the end of this message is the output of dvitype, which translates a dvi 
> file (in this case a file typesetting "0.8" in ptmr7t fonts) into human 
> readable output. I have considered writing a dvi parser for mpl, intending to 
> extract the information necessary to render text with mpl's existing font and 
> text support. There is some more information at 
> http://en.wikipedia.org/wiki/DVI_(TeX) and 
> http://www.math.umd.edu/~asnowden/comp-cont/dvi.html#setchar.
> 
> Is this worth pursuing? If I could make it work, mpl's only external 
> dependency would be TeX/LaTeX, even dvipng would not be required.

Quite probably. dvitype is new to me. Doing a DVI interpreter for mpl and Chaco
has been on my list of things to look at for some time. The things stopping me
(besides the density of the DVI standard) was that all of the readable code I
found for interpreting DVI files has been GPLed.

You will need to access the parameters defined in the TeX Font Metric files, I
think. I recommend using tftopl(1) to convert them to a parseable form.

-- 
Robert Kern
rob...@gm...

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter

I would like to ask for some advice from those out there who have experience 
dealing with fonts and text layout.

At the end of this message is the output of dvitype, which translates a dvi 
file (in this case a file typesetting "0.8" in ptmr7t fonts) into human 
readable output. I have considered writing a dvi parser for mpl, intending to 
extract the information necessary to render text with mpl's existing font and 
text support. There is some more information at 
http://en.wikipedia.org/wiki/DVI_(TeX) and 
http://www.math.umd.edu/~asnowden/comp-cont/dvi.html#setchar.

Is this worth pursuing? If I could make it work, mpl's only external 
dependency would be TeX/LaTeX, even dvipng would not be required.

Thanks,
Darren
(I'm sorry to beat this issue into the ground)

$ dvitype 8b85d26da2410f54cd2d70976999b1d8.dvi
This is DVItype, Version 3.6 (Web2C 7.5.5)
Options selected:
  Starting page = *
  Maximum number of pages = 1000000
  Output level = 4 (the works)
  Resolution = 300.00000000 pixels per inch
numerator/denominator=25400000/473628672
magnification=1000;       0.00006334 pixels per DVI unit
' TeX output 2006.01.21:1639'
Postamble starts at byte 144.
maxv=41484288, maxh=26673152, maxstackdepth=3, totalpages=1
Font 14: ptmr7t---loaded at size 655360 DVI units

42: beginning of page 1
87: down4 41484288 v:=0+41484288=41484288, vv:=2628
92: push
level 0:(h=0,v=41484288,w=0,x=0,y=0,z=0,hh=0,vv=2628)
93: down4 -39649280 v:=41484288-39649280=1835008, vv:=116
98: down4 37683200 v:=1835008+37683200=39518208, vv:=2503
103: push
level 1:(h=0,v=39518208,w=0,x=0,y=0,z=0,hh=0,vv=2503)
104: down4 -35389440 v:=39518208-35389440=4128768, vv:=262
109: push
level 2:(h=0,v=4128768,w=0,x=0,y=0,z=0,hh=0,vv=262)
110: right3 5046272 h:=0+5046272=5046272, hh:=320
[ ]
114: fntdef1 14: ptmr7t
136: fntnum14 current font is ptmr7t
137: setchar48 h:=5046272+327680=5373952, hh:=341
138: setchar46 h:=5373952+163840=5537792, hh:=351
139: setchar56 h:=5537792+327680=5865472, hh:=372
[0.8]
140: pop
level 2:(h=0,v=4128768,w=0,x=0,y=0,z=0,hh=0,vv=262)
141: pop
level 1:(h=0,v=39518208,w=0,x=0,y=0,z=0,hh=0,vv=2503)
142: pop
level 0:(h=0,v=41484288,w=0,x=0,y=0,z=0,hh=0,vv=2628)
143: eop

= What's going on? =

The Matplotlib cookbook is hosted at scipy.org. The backend software 
that hosts the website is being changed (from Plone to MoinMoin). This 
morning I converted the matplotlib cookbook, which is hosted at 
scipy.org, for use with the new software. It is available at 
http://new.scipy.org/Wiki/Cookbook/Matplotlib . (This URL to the new 
cookbook will change once the transition is complete.)

Unfortunately in the transition period, there will be 2 copies of the 
cookbook available online:
 1) the shiny new cookbook at currently available at 
http://new.scipy.org/Wiki/Cookbook/Matplotlib
 2) the slow-to-edit and to-be-removed cookbook at 
http://www.scipy.org/wikis/topical_software/MatplotlibCookbook

*Please make any changes to the new cookbook!*

= Further information =

I've been spearheading an effort to move the scipy.org website to 
something more user-friendly. The goals were for the new site to be:
 * more inclusive of the scientific-computing-using-python community 
rather than the those-using-scipy-the-package community
 * easier (faster) for people to edit
 * more visually pleasing. (aka better marketing)

The decision we took was to make the new website based on MoinMoin, the 
wiki engine available at http://moinmoin.wikiwikiweb.de .

= What you can do =

Please review the Matplotlib Cookbook in its new location. If you can 
correct any errors yourself, that would be greatly appreciated. If you 
just drop me an email, that's fine, too -- I'll try to fix it. We'd also 
appreciate any help and suggestions for the entire new website.

Cheers!
Andrew

Ted Drain wrote:
> John & Fernando,
> I think the basic problem can be solved in a number of ways.  Normally a 
> GUI widget will have an initial size and when it is placed in a window, the 
> window will layout around it (or to it's own size).  However, once the 
> window is drawn, changing the size of one or more widget that it contains 
> doesn't mean you're changing the size of the window.
> 
> Here's some ideas for how to fix this:

Thanks for the feedback, Ted.  I hope one of your suggestions can be 
implemented (2 sounds very reasonable). If not, at least I think the 'forward' 
option should then just be removed.  There's no point in exposing a feature 
known to crash all but ONE backend, I think.

Regards,

f

John & Fernando,
I think the basic problem can be solved in a number of ways.  Normally a 
GUI widget will have an initial size and when it is placed in a window, the 
window will layout around it (or to it's own size).  However, once the 
window is drawn, changing the size of one or more widget that it contains 
doesn't mean you're changing the size of the window.

Here's some ideas for how to fix this:

1) Tell people they have to use the resize method on the window object. 
Pro: simple.  Con: not really the API that you want.

2) Write a resize method (but probably don't call it 'resize' because every 
widget system already uses that name) and have it emit a signal 
(callback).  When you construct the window object, connect that signal to a 
resize method (again not called 'resize') on the window object that can 
compute it's correct size based on the new plot size.  This way the plot 
doesn't know who's getting the signal and can remain independent of it's 
container.

3) Explore the different backends and see if there is a way to configure 
the window objects so they dynamically resize when a child widget is 
changed.  I did a quick check through Qt and couldn't find anything for 
this but it might be there.

It seems like 2) would be pretty simple to implement.  In the Qt backend, I 
think you could do this by:

backend_qtagg.py: In FigureCanvasQTAgg.resizeEvent, add an emit call to 
create a new signal.

self.emit( qt.PYSIGNAL( "plotResize" ), ( w, h ) )

backend_qt.py: In FigureManagerQT.__init__, connect that signal to a new 
method resizeFromPlot( w, h ).  This method should contain the code from 
the current __init__ method that resizes the window based on a given plot 
size.

self.connect( self.canvas, PYSIGNAL( "plotResize" ), self.resizeFromPlot )

This should make it so that any size change to the plot will trigger a 
resize on the main window.  There may be a circularity problem but we'd 
have to try it first an see if calling resize on the main window triggers a 
resize in the plot.

Ted

At 10:25 AM 1/22/2006, John Hunter wrote:
> >>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
>
>
>     Fernando> TypeError: resize() takes exactly 2 arguments (3 given)
>
>Yes, this is basically broken on all GUIs except GTK*.  There was a
>fair amount of discussion back in octover on the devel list about how
>to do this right, since basically it requires a child to call a method
>on the parent and we don't know a-priori what the container will be.
>In pylab we can make it work (but haven't yet across backends) because
>we know the parent will be a FigureManager instance, but it would be
>nice to come up with a generic method that works regardless of whether
>you are using mpl in pylab or not.  It's on the slow burner,
>currently.
>
>JDH
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:


    Fernando> TypeError: resize() takes exactly 2 arguments (3 given)

Yes, this is basically broken on all GUIs except GTK*.  There was a
fair amount of discussion back in octover on the devel list about how
to do this right, since basically it requires a child to call a method
on the parent and we don't know a-priori what the container will be.
In pylab we can make it work (but haven't yet across backends) because
we know the parent will be a FigureManager instance, but it would be
nice to come up with a generic method that works regardless of whether
you are using mpl in pylab or not.  It's on the slow burner,
currently.

JDH

In [1]: gcf().set_figsize_inches((8,8),forward=True)
---------------------------------------------------------------------------
exceptions.TypeError                                 Traceback (most recent 
call last)

/home/fperez/code/python/pylab/arrows/<ipython console>

/usr/lib/python2.3/site-packages/matplotlib/figure.py in 
set_figsize_inches(self, *args, **kwargs)
     266             canvasw = w*dpival
     267             canvash = h*dpival
--> 268             self.canvas.resize(int(canvasw), int(canvash))
     269
     270     def get_size_inches(self):

TypeError: resize() takes exactly 2 arguments (3 given)


A quick look at the backends code shows this:

     def resize(self, event):
         width, height = event.width, event.height
         self.toolbar.configure(width=width) # , height=height)

So quite obviously, this doesn't work: it's expecting an event object, and a 
pair of numbers is being passed.

I'm not sure what the proper fix should be here, I don't really know the code 
flow well enough.

I should also note that the gcf().set_figsize_inches((8,8),forward=True) seems 
to produce a different on-screen result per backend (in some it doesn't do 
anything, in Qt it stretches the figure only horizontally, ...)  That code 
seems to be pretty much broken.

I noticed that figure(figsize=(8,8)) seems to work fine, but I'm not sure how 
to programmatically resize an existing figure, given the above problems.

Cheers,

f

Travis,

That sounds like a good solution, thanks.  A change in either or both of 
contour.py and cntr.c will still be needed, because cntr.c is checking 
for Py_None.

If you want to do it, fine; otherwise I can do it this evening or 
tomorrow morning.

Eric

Travis Oliphant wrote:
> Eric Firing wrote:
> 
>>
>> I remember seeing some discussion of this, but I did not pay enough 
>> attention to it.  If it turns out that returning False is a good idea 
>> in general, then I think it will be easy to modify the mpl code to 
>> handle that, and I don't mind doing it.  Just let me know what the 
>> outcome is.
> 
> 
> I've committed a change to matplotlib that should fix this.  Basically, 
> the check is changed to  "mask is not ma.nomask" (defined in numpy and 
> which I defined in the numerix.ma module for numarray and Numeric to be 
> None).
> 
> I think this should fix the problem and be more future-proof.
> 
> -Travis
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Eric Firing wrote:

>
> I remember seeing some discussion of this, but I did not pay enough 
> attention to it.  If it turns out that returning False is a good idea 
> in general, then I think it will be easy to modify the mpl code to 
> handle that, and I don't mind doing it.  Just let me know what the 
> outcome is.

I've committed a change to matplotlib that should fix this.  Basically, 
the check is changed to  "mask is not ma.nomask" (defined in numpy and 
which I defined in the numerix.ma module for numarray and Numeric to be 
None).

I think this should fix the problem and be more future-proof.

-Travis

Travis Oliphant wrote:
> Eric Firing wrote:
> 
>> Darren,
>>
>> I just tried it with  (numpy imported as n)
>> In [23]:n.__version__
>> Out[23]:'0.9.4.1914'
>>
>> and I don't get the error.  Are you using a newer version of numpy?
> 
> 
> 
> This is a problem with masked arrays in the newer version of numpy.  
> Someone is doing a lot of work on masked arrays and probably not aware 
> of their use in matplotlib.   Recently, for example, the return type for 
> no mask was changed from None to False (I'm not sure why...I'm asking 
> him right now).  That is causing the problem because there is a check 
> for None in the matplotlib code (but not for False...).   We'll get this 
> cleared up, thanks for the report...

Travis,

I remember seeing some discussion of this, but I did not pay enough 
attention to it.  If it turns out that returning False is a good idea in 
general, then I think it will be easy to modify the mpl code to handle 
that, and I don't mind doing it.  Just let me know what the outcome is.

Eric

Eric Firing wrote:

> Darren,
>
> I just tried it with  (numpy imported as n)
> In [23]:n.__version__
> Out[23]:'0.9.4.1914'
>
> and I don't get the error.  Are you using a newer version of numpy?


This is a problem with masked arrays in the newer version of numpy.  
Someone is doing a lot of work on masked arrays and probably not aware 
of their use in matplotlib.   Recently, for example, the return type for 
no mask was changed from None to False (I'm not sure why...I'm asking 
him right now).  That is causing the problem because there is a check 
for None in the matplotlib code (but not for False...).   We'll get this 
cleared up, thanks for the report...


-Travis

Darren,

I just tried it with  (numpy imported as n)
In [23]:n.__version__
Out[23]:'0.9.4.1914'

and I don't get the error.  Are you using a newer version of numpy?

Eric

Darren Dale wrote:
> I just updated this morning, and the following script fails:
> 
> import pylab as pl
> pl.plot(xrange(10), xrange(10))
> 
> 
> Here's the traceback:
> 
> ---------------------------------------------------------------------------
> exceptions.ValueError                                Traceback (most recent 
> call last)
> 
> /home/darren/<ipython console>
> 
> /usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/pylab.py 
> in plot(*args, **kwargs)
>    2077 def plot(*args, **kwargs):
>    2078     # allow callers to override the hold state by passing hold=True|
> False
> -> 2079     b = ishold()
>    2080     h = popd(kwargs, 'hold', None)
>    2081     if h is not None:
> 
> /usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/pylab.py 
> in ishold()
>     938     Return the hold status of the current axes
>     939     """
> --> 940     return gca().ishold()
>     941
>     942 def isinteractive():
> 
> /usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/pylab.py 
> in gca(**kwargs)
>     889     """
>     890
> --> 891     ax =  gcf().gca(**kwargs)
>     892     return ax
>     893
> 
> /usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/figure.py 
> in gca(self, **kwargs)
>     613         ax = self._axstack()
>     614         if ax is not None: return ax
> --> 615         return self.add_subplot(111, **kwargs)
>     616
>     617     def sca(self, a):
> 
> /usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/figure.py 
> in add_subplot(self, *args, **kwargs)
>     463                 a = PolarSubplot(self, *args, **kwargs)
>     464             else:
> --> 465                 a = Subplot(self, *args, **kwargs)
>     466
>     467
> 
> /usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/axes.py 
> in __init__(self, fig, *args, **kwargs)
>    4094     def __init__(self, fig, *args, **kwargs):
>    4095         SubplotBase.__init__(self, fig, *args)
> -> 4096         Axes.__init__(self, fig, [self.figLeft, self.figBottom,
>    4097                                   self.figW, self.figH], **kwargs)
>    4098
> 
> /usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/axes.py 
> in __init__(self, fig, rect, axisbg, frameon, sharex, sharey, label, 
> **kwargs)
>     329
>     330         # this call may differ for non-sep axes, eg polar
> --> 331         self._init_axis()
>     332
>     333
> 
> /usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/axes.py 
> in _init_axis(self)
>     358     def _init_axis(self):
>     359         "move this out of __init__ because non-separable axes don't 
> use it"
> --> 360         self.xaxis = XAxis(self)
>     361         self.yaxis = YAxis(self)
>     362
> 
> /usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/axis.py 
> in __init__(self, axes)
>     499         self.minorTicks = []
>     500
> --> 501         self.cla()
>     502
>     503     def cla(self):
> 
> /usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/axis.py 
> in cla(self)
>     522         popall(self.minorTicks)
>     523
> --> 524         self.majorTicks.extend([self._get_tick(major=True)  for i in 
> range(1)])
>     525         self.minorTicks.extend([self._get_tick(major=False) for i in 
> range(1)])
>     526
> 
> /usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/axis.py 
> in _get_tick(self, major)
>     832
>     833     def _get_tick(self, major):
> --> 834         return XTick(self.axes, 0, '', major=major)
>     835
>     836     def _get_label(self):
> 
> /usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/axis.py 
> in __init__(self, axes, loc, label, size, gridOn, tick1On, tick2On, label1On, 
> label2On, major)
>      98
>      99
> --> 100         self.tick1line = self._get_tick1line(loc)
>     101         self.tick2line = self._get_tick2line(loc)
>     102         self.gridline = self._get_gridline(loc)
> 
> /usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/axis.py 
> in _get_tick1line(self, loc)
>     274                     antialiased=False,
>     275                     marker = self._xtickmarkers[0],
> --> 276                     markersize=self._size,
>     277                     )
>     278
> 
> /usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/lines.py 
> in __init__(self, xdata, ydata, linewidth, linestyle, color, marker, 
> markersize, markeredgewidth, markeredgecolor, markerfacecolor, antialiased, 
> dash_capstyle, solid_capstyle, dash_joinstyle, solid_joinstyle, **kwargs)
>     209         self.verticalOffset = None
>     210
> --> 211         self.set_data(xdata, ydata)
>     212
>     213         if not self._lineStyles.has_key(linestyle):
> 
> /usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/lines.py 
> in set_data(self, *args)
>     280             x = ma.masked_array(x, mask=mask).compressed()
>     281             y = ma.masked_array(y, mask=mask).compressed()
> --> 282             self._segments = unmasked_index_ranges(mask)
>     283         else:
>     284             self._segments = None
> 
> /usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/lines.py 
> in unmasked_index_ranges(mask, compressed)
>      67
>      68     '''
> ---> 69     m = concatenate(((1,), mask, (1,)))
>      70     indices = arange(len(mask) + 1)
>      71     mdif = m[1:] - m[:-1]
> 
> ValueError: arrays must have same number of dimensions
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> I just updated this morning, and the following script
    Darren> fails: import pylab as pl pl.plot(xrange(10), xrange(10))

I'm not seeing this with numpy, numarray or Numeric.  My guess is that
it is a numpy incompatibility.  What version are you using?

peds-pc311:~> python test.py --Numeric --verbose-helpful
matplotlib data path /usr/lib/python2.4/site-packages/matplotlib/mpl-data
$HOME=/home/jdhunter
CONFIGDIR=/home/jdhunter/.matplotlib
loaded rc file /home/jdhunter/.matplotlib/matplotlibrc
matplotlib version 0.86.2cvs
verbose.level helpful
interactive is False
platform is linux2
numerix Numeric 24.0b2
font search path ['/usr/lib/python2.4/site-packages/matplotlib/mpl-data']
loaded ttfcache file /home/jdhunter/.matplotlib/ttffont.cache
backend TkAgg version 8.4
peds-pc311:~> python test.py --numarray --verbose-helpful
matplotlib data path /usr/lib/python2.4/site-packages/matplotlib/mpl-data
$HOME=/home/jdhunter
CONFIGDIR=/home/jdhunter/.matplotlib
loaded rc file /home/jdhunter/.matplotlib/matplotlibrc
matplotlib version 0.86.2cvs
verbose.level helpful
interactive is False
platform is linux2
numerix numarray 1.3.3
font search path ['/usr/lib/python2.4/site-packages/matplotlib/mpl-data']
loaded ttfcache file /home/jdhunter/.matplotlib/ttffont.cache
backend TkAgg version 8.4

peds-pc311:~> python test.py --numpy --verbose-helpful
matplotlib data path /usr/lib/python2.4/site-packages/matplotlib/mpl-data
$HOME=/home/jdhunter
CONFIGDIR=/home/jdhunter/.matplotlib
loaded rc file /home/jdhunter/.matplotlib/matplotlibrc
matplotlib version 0.86.2cvs
verbose.level helpful
interactive is False
platform is linux2
numerix numpy 0.9.2
font search path ['/usr/lib/python2.4/site-packages/matplotlib/mpl-data']
loaded ttfcache file /home/jdhunter/.matplotlib/ttffont.cache
backend TkAgg version 8.4
peds-pc311:~> 

I just updated this morning, and the following script fails:

import pylab as pl
pl.plot(xrange(10), xrange(10))


Here's the traceback:

---------------------------------------------------------------------------
exceptions.ValueError                                Traceback (most recent 
call last)

/home/darren/<ipython console>

/usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/pylab.py 
in plot(*args, **kwargs)
   2077 def plot(*args, **kwargs):
   2078     # allow callers to override the hold state by passing hold=True|
False
-> 2079     b = ishold()
   2080     h = popd(kwargs, 'hold', None)
   2081     if h is not None:

/usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/pylab.py 
in ishold()
    938     Return the hold status of the current axes
    939     """
--> 940     return gca().ishold()
    941
    942 def isinteractive():

/usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/pylab.py 
in gca(**kwargs)
    889     """
    890
--> 891     ax =  gcf().gca(**kwargs)
    892     return ax
    893

/usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/figure.py 
in gca(self, **kwargs)
    613         ax = self._axstack()
    614         if ax is not None: return ax
--> 615         return self.add_subplot(111, **kwargs)
    616
    617     def sca(self, a):

/usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/figure.py 
in add_subplot(self, *args, **kwargs)
    463                 a = PolarSubplot(self, *args, **kwargs)
    464             else:
--> 465                 a = Subplot(self, *args, **kwargs)
    466
    467

/usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/axes.py 
in __init__(self, fig, *args, **kwargs)
   4094     def __init__(self, fig, *args, **kwargs):
   4095         SubplotBase.__init__(self, fig, *args)
-> 4096         Axes.__init__(self, fig, [self.figLeft, self.figBottom,
   4097                                   self.figW, self.figH], **kwargs)
   4098

/usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/axes.py 
in __init__(self, fig, rect, axisbg, frameon, sharex, sharey, label, 
**kwargs)
    329
    330         # this call may differ for non-sep axes, eg polar
--> 331         self._init_axis()
    332
    333

/usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/axes.py 
in _init_axis(self)
    358     def _init_axis(self):
    359         "move this out of __init__ because non-separable axes don't 
use it"
--> 360         self.xaxis = XAxis(self)
    361         self.yaxis = YAxis(self)
    362

/usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/axis.py 
in __init__(self, axes)
    499         self.minorTicks = []
    500
--> 501         self.cla()
    502
    503     def cla(self):

/usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/axis.py 
in cla(self)
    522         popall(self.minorTicks)
    523
--> 524         self.majorTicks.extend([self._get_tick(major=True)  for i in 
range(1)])
    525         self.minorTicks.extend([self._get_tick(major=False) for i in 
range(1)])
    526

/usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/axis.py 
in _get_tick(self, major)
    832
    833     def _get_tick(self, major):
--> 834         return XTick(self.axes, 0, '', major=major)
    835
    836     def _get_label(self):

/usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/axis.py 
in __init__(self, axes, loc, label, size, gridOn, tick1On, tick2On, label1On, 
label2On, major)
     98
     99
--> 100         self.tick1line = self._get_tick1line(loc)
    101         self.tick2line = self._get_tick2line(loc)
    102         self.gridline = self._get_gridline(loc)

/usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/axis.py 
in _get_tick1line(self, loc)
    274                     antialiased=False,
    275                     marker = self._xtickmarkers[0],
--> 276                     markersize=self._size,
    277                     )
    278

/usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/lines.py 
in __init__(self, xdata, ydata, linewidth, linestyle, color, marker, 
markersize, markeredgewidth, markeredgecolor, markerfacecolor, antialiased, 
dash_capstyle, solid_capstyle, dash_joinstyle, solid_joinstyle, **kwargs)
    209         self.verticalOffset = None
    210
--> 211         self.set_data(xdata, ydata)
    212
    213         if not self._lineStyles.has_key(linestyle):

/usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/lines.py 
in set_data(self, *args)
    280             x = ma.masked_array(x, mask=mask).compressed()
    281             y = ma.masked_array(y, mask=mask).compressed()
--> 282             self._segments = unmasked_index_ranges(mask)
    283         else:
    284             self._segments = None

/usr/lib64/python2.4/site-packages/matplotlib-0.86.2cvs-py2.4-linux-x86_64.egg/matplotlib/lines.py 
in unmasked_index_ranges(mask, compressed)
     67
     68     '''
---> 69     m = concatenate(((1,), mask, (1,)))
     70     indices = arange(len(mask) + 1)
     71     mdif = m[1:] - m[:-1]

ValueError: arrays must have same number of dimensions

>>>>> "Ryan" == Ryan Krauss <rya...@gm...> writes:

    Ryan> One thing I don't seem to be able to do is make the diff
    Ryan> pick up the matplotlibrc changes.  The following lines need
    Ryan> to be added to make this feature useful:

I don't know if I failed to mention this somewhere else or not, but
this is because the rc is now autogenerated by setup.py from the
matplotlibrc.template file.  So that is where changes like

### Legend
legend.isaxes	:	True
legend.numpoints 	:	4  # the number of points in the legend line
legend.fontsize : 14
legend.pad 	:	0.2 # the fractional whitespace inside the legend border


should go.  I added these and they are no in CVS.

Thanks,
JDH

>>>>> "Jouni" == Jouni K Seppanen <jk...@ik...> writes:

    Jouni> Hi, I just read in another thread that the recommended way
    Jouni> to submit patches is to both post them here and on the
    Jouni> Sourceforge tracker.  Here's one that I had only posted on

It's a good reminder, since I follow the lists more closely than the
sf site....

    Jouni> the tracker a while ago but that still seems to apply
    Jouni> cleanly to current cvs. It fixes a bug in my previous
    Jouni> boxplot patch (division by zero if you only plot one box),
    Jouni> and changes the return value of boxplot so that you can
    Jouni> modify the different parts of the plot separately, as
    Jouni> suggested in John's commentary to David Haas's original
    Jouni> boxplot patch. Here's an example:

OK, committed to CVS.  Thanks!

Checking in lib/matplotlib/axes.py;
/cvsroot/matplotlib/matplotlib/lib/matplotlib/axes.py,v  <--  axes.py
new revision: 1.152; previous revision: 1.151
done


JDH

Hi,

I just read in another thread that the recommended way to submit
patches is to both post them here and on the Sourceforge tracker. 
Here's one that I had only posted on the tracker a while ago but that
still seems to apply cleanly to current cvs. It fixes a bug in my
previous boxplot patch (division by zero if you only plot one box),
and changes the return value of boxplot so that you can modify the
different parts of the plot separately, as suggested in John's
commentary to David Haas's original boxplot patch. Here's an example:

In [1]:boxplot(rand(100,2))
Out[1]:
{'boxes': [<matplotlib.lines.Line2D instance at 0x2deaaa8>,
           <matplotlib.lines.Line2D instance at 0x2deae68>],
 'caps': [<matplotlib.lines.Line2D instance at 0x2deaaf8>,
          <matplotlib.lines.Line2D instance at 0x2deab70>,
          <matplotlib.lines.Line2D instance at 0x2dea8f0>,
          <matplotlib.lines.Line2D instance at 0x2def170>],
 'fliers': [<matplotlib.lines.Line2D instance at 0x2dead00>,
            <matplotlib.lines.Line2D instance at 0x2deab48>,
            <matplotlib.lines.Line2D instance at 0x2def2b0>,
            <matplotlib.lines.Line2D instance at 0x2def148>],
 'medians': [<matplotlib.lines.Line2D instance at 0x2deaa58>,
             <matplotlib.lines.Line2D instance at 0x2def210>],
 'whiskers': [<matplotlib.lines.Line2D instance at 0x2dea8a0>,
              <matplotlib.lines.Line2D instance at 0x2dea9b8>,
              <matplotlib.lines.Line2D instance at 0x2deae90>,
              <matplotlib.lines.Line2D instance at 0x2deafd0>]}

In [2]:setp(Out[1]['medians'], 'linewidth', 3)
Out[2]:[None, None]

The patch also changes the boxplot demo to demonstrate this.

-- 
Jouni

Can you send me a short example that shows the problem?

I'm not able to duplicate it here -- but I'm probably not doing the 
right thing.

John

John Gill wrote:
> I'll take a look -- the legends for scatter plots fix was one of mine.
>
> John
>
> Stefan Kuzminski wrote:
>> I notice that my legend in a scatter plot ( the axis legend ) does not
>> display a graphic indication next to the text ( as it does with line
>> plots ).  The difference seems to be if the first argument to 'legend'
>> is a list of 'Line2D' objects it works ( the legend looks good ) but if
>> the first argument is a list of 'RegularPolyCollection' the legend
>> contains just text and there is no way to know what it is 'legending'
>>
>> Thanks,
>> Stefan 
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam?  Yahoo! Mail has the best spam protection around 
>> http://mail.yahoo.com 
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>> for problems?  Stop!  Download the new AJAX search engine that makes
>> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>   

I'll take a look -- the legends for scatter plots fix was one of mine.

John

Stefan Kuzminski wrote:
> I notice that my legend in a scatter plot ( the axis legend ) does not
> display a graphic indication next to the text ( as it does with line
> plots ).  The difference seems to be if the first argument to 'legend'
> is a list of 'Line2D' objects it works ( the legend looks good ) but if
> the first argument is a list of 'RegularPolyCollection' the legend
> contains just text and there is no way to know what it is 'legending'
>
> Thanks,
> Stefan 
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

I notice that my legend in a scatter plot ( the axis legend ) does not
display a graphic indication next to the text ( as it does with line
plots ).  The difference seems to be if the first argument to 'legend'
is a list of 'Line2D' objects it works ( the legend looks good ) but if
the first argument is a list of 'RegularPolyCollection' the legend
contains just text and there is no way to know what it is 'legending'

Thanks,
Stefan 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Here is my first attempt at patch submission.  This patch aims to make
it possible to set legend properties (like fontsize) in the
matplotlibrc file.

Details:
 added legend options to rc file
To the main __init__.py file I have added lines 769-780
to set default
rc values for legend related parameters. The attached
matplotlibrc
file is just an example of setting the legend parameters.

There are several changes to legend.py:

1. added ,rcParams to the end of line 29:
from matplotlib import verbose, rcParams

2. lines 112-124 set all the defaults for the keyword
arguments to
None as you suggested.

3. changed how the values for things like
self.numpoints are handled
to check if they are none and look them up from
rcParams are you
suggested lines 149-159.

I don't know if there is a way to use kwargs here
instead of the
crude dictionary I set up in this part, but it works.
Let me know if
there is a cleaner way.

4. changed line 161 to check self.isaxes instead of
isaxes, because
isaxes now defaults to None:
if self.isaxes: # parent is an Axes


One thing I don't seem to be able to do is make the diff pick up the
matplotlibrc changes.  The following lines need to be added to make
this feature useful:

### Legend
legend.isaxes=09:=09True
legend.numpoints =09:=094  # the number of points in the legend line
legend.fontsize : 14
legend.pad =09:=090.2 # the fractional whitespace inside the legend border
legend.markerscale =09:=091.0    # the relative size of legend markers vs. =
original
# the following dimensions are in axes coords
legend.labelsep =09:=090.010 # the vertical space between the legend entrie=
s
legend.handlelen =09:=090.05  # the length of the legend lines
legend.handletextsep =09:=090.02 # the space between the legend line and le=
gend text
legend.axespad =09:=090.02       # the border between the axes and legend e=
dge
legend.shadow=09:=09False

Let me know what to do from here.

If it matters, I created the diff from inside the directory
cvs/matplotlib on my computer (I don't know if the default would be
one level up from that for most people or not).

Ryan

John Hunter wrote:
>>>>>>"Ryan" == Ryan Krauss <rya...@gm...> writes:
> 
> 
>     Ryan> Part of the problem is that I don't have much experience
>     Ryan> with cvs/svn beyond checking code out.  That is why I am
>     Ryan> asking for a procedure.  I also don't know if someone needs
>     Ryan> to look at what I have done and make sure I am not a total
>     Ryan> hack (I made some changes to it based on John's feedback).
>     Ryan> I will in no way be offended if someone wants to look over
>     Ryan> my shoulder, and I don't mind tweaking it to follow better
>     Ryan> coding practices or whatever, but I do want to follow it
>     Ryan> through to getting it included.
> 
> The best way is to get a copy of cvs and build your patch with 'cvs
> diff' and then post it here and on the sourceforge patches site.
> 
> And remind us after a week if we fail to take action!

In addition to John's comments, you may want to browse the ipython page on 
this topic (John, feel free to steal it and tweak it to suit your personal taste):

http://projects.scipy.org/ipython/ipython/wiki/DeveloperGuidelines

While some things there may be specific to IPython (I am _much_ more picky 
about detailed changelogs than matplotlib is, for example), the bulk of it is 
generic advice, good for anyone coming to an Open Source Python project.

About the only thing I'd add for mpl would be to make your diffs with 'cvs 
diff -u', since by default CVS doesn't do that (SVN does, so I removed that 
bit of advice yesterday).  One of these days John will see the light of SVN 
and this difference will vanish :)

[ BTW, John, useful little links I found today on SVN, better than what I'd 
seen before]:

https://www.projects.dev2dev.bea.com/scdocs/ddUsingSVN_command-line
http://www.developer.com/open/article.php/10930_3499816_1


I hope this is useful.

Cheers,

f

>>>>> "Ryan" == Ryan Krauss <rya...@gm...> writes:

    Ryan> Part of the problem is that I don't have much experience
    Ryan> with cvs/svn beyond checking code out.  That is why I am
    Ryan> asking for a procedure.  I also don't know if someone needs
    Ryan> to look at what I have done and make sure I am not a total
    Ryan> hack (I made some changes to it based on John's feedback).
    Ryan> I will in no way be offended if someone wants to look over
    Ryan> my shoulder, and I don't mind tweaking it to follow better
    Ryan> coding practices or whatever, but I do want to follow it
    Ryan> through to getting it included.

The best way is to get a copy of cvs and build your patch with 'cvs
diff' and then post it here and on the sourceforge patches site.

And remind us after a week if we fail to take action!

JDH