matplotlib-devel Mailing List for matplotlib (Page 6)

On Thu, 10 Feb 2011 17:34:32 -0500, Darren Dale wrote:
[clip]
> Unfortunately, I am getting exactly the same results: the matplotlib/
> directory is missing in the earliest history. I've tried adding
> --use-cvs and --keep-trivial-imports, to no avail. I've tried checking
> out a working copy of the cvs repo (setting CVSROOT to point to the
> directory I created using rsync), and I *thought* the right way to
> inspect the r7 working directory is to do "cvs update -R -r 7", but
> thats not right. So I'm currently having trouble determining whether the
> history even exists in CVS. Anybody have a longer memory than I do? How
> can I get cvs to perform this basic operation?

Maybe you can try skipping SVN altogether (needs "git-cvs" package on 
Ubuntu):

export CVSROOT=/rsynced/directory
test -d "$CVSROOT/CVSROOT" || echo "Wrong cvsroot..."
mkdir imported
cd imported
git cvsimport matplotlib

This at least shows some files in the first revisions. You can probably 
then just graft the two histories together at a suitable point.

Apparently, it also needs some use of "git filter-branch" to get rid of 
the top-level matplotlib/ directory.

-- 
Pauli Virtanen

On Sat, Jan 29, 2011 at 9:00 AM, Darren Dale <dsd...@gm...> wrote:
> On Sat, Jan 29, 2011 at 3:35 AM, Andrew Straw <str...@as...> wrote:
>> On 29-Jan-11 01:08, John Hunter wrote:
>>>
>>>> cvs -z3 -d:pserver:ano...@cv...:/cvsroot/matplotlib co
>>>> -P matplotlib
>>>
>>> cvs [checkout aborted]: connect to
>>> cvs.sourceforge.net(216.34.181.96):2401 failed: Connection refused
>>>
>>> Amazing how fragile digital data is!
>>
>> SF may simply have turned off CVS for now:
>> http://sourceforge.net/blog/sourceforge-net-attack/
>
> Thanks Andrew.
>
> As much as I would like to push the git repos to github today, I think
> it is worth waiting. When SF CVS comes back up, I can attempt to
> convert the CVS repository to SVN, verify that the data has been
> preserved, and convert r1:540 to git. Then I can convert the master
> svn repo starting at r541, and graft the result onto the older
> history. When the resulting repo is postprocessed to clean it up and
> reduce the size, the graft would be made permanent (is actually
> incorporated into the history, as opposed to being a reference in
> .git/info/grafts).

Sourceforge just enabled enough access to get a copy of the cvs
repository by doing:

rsync -av matplotlib.cvs.sourceforge.net::cvsroot/matplotlib/* .

So, if I have the cvs repo in a local directory called "mpl.cvs", then I can do:

cvs2svn --encoding=utf_8 -s mpl.svn mpl.cvs

Unfortunately, I am getting exactly the same results: the matplotlib/
directory is missing in the earliest history. I've tried adding
--use-cvs and --keep-trivial-imports, to no avail. I've tried checking
out a working copy of the cvs repo (setting CVSROOT to point to the
directory I created using rsync), and I *thought* the right way to
inspect the r7 working directory is to do "cvs update -R -r 7", but
thats not right. So I'm currently having trouble determining whether
the history even exists in CVS. Anybody have a longer memory than I
do? How can I get cvs to perform this basic operation?

Darren

Hi Uri,

On Wed, Feb 9, 2011 at 12:13 PM, Uri Laserson <las...@mi...> wrote:
>
> I wrote a bit of code for plotting streamgraphs with MPL (e.g.,
> http://goo.gl/7sjcR).

Fantastic, many thanks!  For anyone who is willing to shepherd this
through inclusion in MPL, I *strongly* recommend they read the paper
in the link above, titled:

“Stacked Graphs – Geometry & Aesthetics” by Lee Byron & Martin Wattenberg.
PDF link: http://www.leebyron.com/else/streamgraph/download.php?file=stackedgraphs_byron_wattenberg.pdf

In fact, I'm sure anyone who's intrested enough in data viz to be on
this list would tremendously enjoy the paper, it's a really good
piece.

> It is available on my GitHub page here:
> http://goo.gl/qGGPS
> What is the best way for me to integrate it into MPL?

Unfortunately I'm too swamped to fully help you move this through, but
a few pointers now so to get you going, and hopefully another core dev
can pitch in...

- For mpl inclusion, your code needs to be explicitly BSD licensed,
and should mention that the original code it's based on (if you read
any of the implementation) was also BSD licensed (which it is, as per
this file: https://github.com/leebyron/streamgraph_generator/blob/master/COPYRIGHT).

- I read your implementation and it looks very nice and concise,
excellent job.  After reading the paper, I was just wondering if this
problem might not benefit from a bit of object orientation...

I'm just thinking out loud here, and I actually tend to always favor
holding of on the OO until a more decoupled, functional approach shows
its limitations.  So perhaps your take is just fine for now.  But what
I'm thinking about is that the Streamgraph construction has a number
of moving parts:

* the optimization formulation to select g_0.
* the colormap choices, which can be fairly sophisticated.
* the sorting of the time series and their assignment on the stream stack.

It might be more convenient to bundle all these into an object that
exposes the already implemented options and can be extended to other
algorithms.  This is a case where I'm thinking of going OO not because
of inheritance, but simply as a way of grouping related functions and
data in a way that's easier to pass around in more complex codes.

In fact, a good solution might be to keep a number of standalone
functions and offer a wrapper object that exposes an OO interface.
For simple cases people could just call the function with some data,
but for more complex development using (and possibly extending) the
object would be cleaner.

In any case, I hope this feedback is useful, and I look forward to
streamgraphs in MPL!  Sorry that I won't be able to work on the
review/merge itself in the future; as interested as I was by the paper
(many thanks for bringing it to our attention), I'm already neglecting
other things far too much :)

Regards,

f

Maybe someone has already done this?  (Thanks to whomever it was!)

It looks like the download links all point to 1.0.1 now.

Mike

On 02/10/2011 02:12 AM, Paul Ivanov wrote:
> I'm guessing only the admins can change this (or at least I
> didn't find a way to do it myself on the sourceforge site) but
> the link at the top of the download page still points to 1.0.0
>
> "Loking for the latest version? Download matplotlib-1.0.0.tar.gz"
>
> This actually affects all of the direct download links that are
> scattered about (the one on the project summary page, for example)
>
> Can someone with the privileges points it to 1.0.1?
>
> best,
>    
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>    


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On 02/09/2011 09:23 PM, Marshall Ward wrote:
> Hello, first time poster,

Marshall,

Welcome!  I'm sorry my first reply was a bit curt, especially 
considering that you are offering a patch. We do appreciate 
contributions.  A little discussion may be required as to the future 
strategy for keyboard shortcuts, but thank you for getting started.

Eric

>
> I've made a patch to add a keyboard shortcut to close plot windows with
> the 'q' key (patchfile attached, in case it is of interest to the
> matplotlib team). But as I was finishing it up, I noticed that there was
> already something similar in the code, commented out (even using the
> same key!):
>
>          #if event.key == 'q':
>          #    self.destroy() # how cruel to have to destroy oneself!
>          #    return
>
> I didn't implement it this way (I used self.close() and tried to emulate
> the other key commands), but I wondered if this was an indication that
> adding a keyboard shortcut for close() was a bad idea for any reason.
>
> Also, is it possible to a custom keyboard shortcut for particular
> backends? For example, I'd like for "command-w" to close plotting
> windows for the mac os x backend. Would this be added to backend_macosx.py?
>
> Finally, I noticed that on OS X, the plots used to be the active window
> once they were created (1.0.0, possibly earlier), but now they appear
> behind my terminal window when created (1.0.1). Is this a setting in
> backend_macosx.py, or somewhere else?
>
> Thanks for your time, and the wonderful plotting library,
> Marshall
>
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 02/09/2011 09:23 PM, Marshall Ward wrote:
> Hello, first time poster,
>
> I've made a patch to add a keyboard shortcut to close plot windows with
> the 'q' key (patchfile attached, in case it is of interest to the
> matplotlib team). But as I was finishing it up, I noticed that there was
> already something similar in the code, commented out (even using the
> same key!):
>
>          #if event.key == 'q':
>          #    self.destroy() # how cruel to have to destroy oneself!
>          #    return
>
> I didn't implement it this way (I used self.close() and tried to emulate
> the other key commands), but I wondered if this was an indication that
> adding a keyboard shortcut for close() was a bad idea for any reason.

In my opinion, having it enabled by default is a horrible idea--it is 
too easy to hit it accidentally, and when one does so, the consequence 
is too damaging.  The present default-enabled shortcuts are bad enough; 
I am tempted to change the defaults--but maybe more people would be 
displeased than pleased by that change.

>
> Also, is it possible to a custom keyboard shortcut for particular
> backends? For example, I'd like for "command-w" to close plotting
> windows for the mac os x backend. Would this be added to backend_macosx.py?
>


My dim recollection is that we don't presently have support for anything 
other than the normal keys.  I don't know what is involved in adding it.

I hope Michiel de Hoon can reply regarding backend_macosx specifics.

> Finally, I noticed that on OS X, the plots used to be the active window
> once they were created (1.0.0, possibly earlier), but now they appear
> behind my terminal window when created (1.0.1). Is this a setting in
> backend_macosx.py, or somewhere else?
>

I'm pretty sure that if it is within mpl, it would be in backend_macosx. 
  It is not the sort of thing I would expect to have changed, though. 
Again, Michiel de Hoon may be able to shed light on this.

Eric

> Thanks for your time, and the wonderful plotting library,
> Marshall
>

I'm guessing only the admins can change this (or at least I
didn't find a way to do it myself on the sourceforge site) but
the link at the top of the download page still points to 1.0.0

"Loking for the latest version? Download matplotlib-1.0.0.tar.gz"

This actually affects all of the direct download links that are
scattered about (the one on the project summary page, for example) 

Can someone with the privileges points it to 1.0.1?

best,
-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

Hi all,

I wrote a bit of code for plotting streamgraphs with MPL (e.g.,
http://goo.gl/7sjcR).

It is available on my GitHub page here:
http://goo.gl/qGGPS

What is the best way for me to integrate it into MPL?

Uri


...................................................................................
Uri Laserson
Graduate Student, Biomedical Engineering
Harvard-MIT Division of Health Sciences and Technology
M +1 917 742 8019
las...@mi...

On Tue, Jan 18, 2011 at 11:18 PM, Eric Firing <ef...@ha...> wrote:
>
> 2) Interactive backends, to be fully useful, need to be be supported by
> ipython.

As long as the event loop handling of pyside is similar to pyqt's one,
it might just work already.

But even if it doesn't, from the IPython side we are *very* interested
in pyside, and actually just a few days ago we got full Pyside support
contributed by the author of our new Qt console:

https://github.com/ipython/ipython/pull/259

It's not merged yet, but the code is ready (reviews from experts
welcome).  So from our side, consider pyside to be high priority.

Cheers,

f

On 2/7/11 10:30 PM, Benjamin Root wrote:
>
> The behavior in gtk and other backends is the designed/intended
> behavior.  macosx backend is actually the odd-man out because it was
> coded to only work in one of those modes.
>
> Maybe we should emit a warning when macosx backend is used when
> interactive=False in order to dispel misunderstanding?

possibly, but maybe adding a blurb about OSX, and maybe the blocking 
behavior to the documentation here: 
http://matplotlib.sourceforge.net/users/shell.html and maybe to the 
dostrings of ion(), ioff() would be good.

M

On Mon, Feb 7, 2011 at 9:17 PM, Mike Kaufman <mc...@gm...> wrote:

> On 2/7/11 9:28 PM, Eric Firing wrote:
>
> >>> Which backend are you using and using which OS?
> >>
> >> Good question. Snow Leopard and the MacOSX backend. If I use the Gtk
> >
> > This is a known bug in the MacOSX backend.
> >
> >> backend this bug does _not_ occur (though I have to use the plt.show()
> >> command to bring up the window --- which hangs the shell...)
> >
> > It should simply block until the window is closed; is this what you mean?
>
> Yes I do, although I'm not sure why it should block: I may want to add
> additional plots to the window --- though I do notice that if
> isinteractive=True, then the window doesn't block. It makes sense I
> guess, but not really intuitive, especially not coming from the
> behaviour of the OSX backend.
>
> M
>
>
The behavior in gtk and other backends is the designed/intended behavior.
macosx backend is actually the odd-man out because it was coded to only work
in one of those modes.

Maybe we should emit a warning when macosx backend is used when
interactive=False in order to dispel misunderstanding?

Ben Root

On 2/7/11 9:28 PM, Eric Firing wrote:

>>> Which backend are you using and using which OS?
>>
>> Good question. Snow Leopard and the MacOSX backend. If I use the Gtk
>
> This is a known bug in the MacOSX backend.
>
>> backend this bug does _not_ occur (though I have to use the plt.show()
>> command to bring up the window --- which hangs the shell...)
>
> It should simply block until the window is closed; is this what you mean?

Yes I do, although I'm not sure why it should block: I may want to add 
additional plots to the window --- though I do notice that if 
isinteractive=True, then the window doesn't block. It makes sense I 
guess, but not really intuitive, especially not coming from the 
behaviour of the OSX backend.

M

On 02/07/2011 04:13 PM, Mike Kaufman wrote:
> On 2/7/11 9:02 PM, Benjamin Root wrote:
>> On Mon, Feb 7, 2011 at 7:20 PM, Mike Kaufman<mc...@gm...
>> <mailto:mc...@gm...>>  wrote:
>>
>>
>>      using a recent svn (r8900), I've noticed that after starting from a
>>      regular python shell:
>>
>>       >>>  import matplotlib.pyplot as plt
>>       >>>  plt.isinteractive()
>>      False
>>       >>>  plt.plot([1,2,3],[1,3,2])
>>      [<matplotlib.lines.Line2D object at 0x114e7a090>]
>>       >>>  plt.plot([1,2,3],[1,2,3])
>>      [<matplotlib.lines.Line2D object at 0x114e7a590>]
>>      # plt.draw() is not required, the figure pops up
>>      # and both plots are shown
>>       >>>  plt.xlim(1,2)
>>      (1, 2)
>>      # again this works immediately no draw() required
>>       >>>  plt.xlabel('aaa')
>>      <matplotlib.text.Text object at 0x1033a2290>
>>      # ditto, no draw() required
>>
>>      but if the axes methods are used, then interactive status is honored:
>>
>>       >>>  plt.gca().set_xlabel('bbb')
>>      <matplotlib.text.Text object at 0x1033a2290>
>>       >>>  plt.gca().plot([1,2,3],[3,2,1])
>>      [<matplotlib.lines.Line2D object at 0x114e7cf90>]
>>       >>>  plt.gca().set_xlim(1,3)
>>      (1, 3)
>>      # all these require a plt.draw() to show up...
>>
>>      I think that this is a misfeature, but maybe this is desired behavior?
>>
>>      M
>>
>>
>> Which backend are you using and using which OS?
>
> Good question. Snow Leopard and the MacOSX backend. If I use the Gtk

This is a known bug in the MacOSX backend.

> backend this bug does _not_ occur (though I have to use the plt.show()
> command to bring up the window --- which hangs the shell...)

It should simply block until the window is closed; is this what you mean?

Eric

>
> M
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 2/7/11 9:02 PM, Benjamin Root wrote:
> On Mon, Feb 7, 2011 at 7:20 PM, Mike Kaufman <mc...@gm...
> <mailto:mc...@gm...>> wrote:
>
>
>     using a recent svn (r8900), I've noticed that after starting from a
>     regular python shell:
>
>      >>> import matplotlib.pyplot as plt
>      >>> plt.isinteractive()
>     False
>      >>> plt.plot([1,2,3],[1,3,2])
>     [<matplotlib.lines.Line2D object at 0x114e7a090>]
>      >>> plt.plot([1,2,3],[1,2,3])
>     [<matplotlib.lines.Line2D object at 0x114e7a590>]
>     # plt.draw() is not required, the figure pops up
>     # and both plots are shown
>      >>> plt.xlim(1,2)
>     (1, 2)
>     # again this works immediately no draw() required
>      >>> plt.xlabel('aaa')
>     <matplotlib.text.Text object at 0x1033a2290>
>     # ditto, no draw() required
>
>     but if the axes methods are used, then interactive status is honored:
>
>      >>> plt.gca().set_xlabel('bbb')
>     <matplotlib.text.Text object at 0x1033a2290>
>      >>> plt.gca().plot([1,2,3],[3,2,1])
>     [<matplotlib.lines.Line2D object at 0x114e7cf90>]
>      >>> plt.gca().set_xlim(1,3)
>     (1, 3)
>     # all these require a plt.draw() to show up...
>
>     I think that this is a misfeature, but maybe this is desired behavior?
>
>     M
>
>
> Which backend are you using and using which OS?

Good question. Snow Leopard and the MacOSX backend. If I use the Gtk 
backend this bug does _not_ occur (though I have to use the plt.show() 
command to bring up the window --- which hangs the shell...)

M

On Mon, Feb 7, 2011 at 7:20 PM, Mike Kaufman <mc...@gm...> wrote:

>
> using a recent svn (r8900), I've noticed that after starting from a
> regular python shell:
>
>  >>> import matplotlib.pyplot as plt
>  >>> plt.isinteractive()
> False
>  >>> plt.plot([1,2,3],[1,3,2])
> [<matplotlib.lines.Line2D object at 0x114e7a090>]
>  >>> plt.plot([1,2,3],[1,2,3])
> [<matplotlib.lines.Line2D object at 0x114e7a590>]
> # plt.draw() is not required, the figure pops up
> # and both plots are shown
>  >>> plt.xlim(1,2)
> (1, 2)
> # again this works immediately no draw() required
>  >>> plt.xlabel('aaa')
> <matplotlib.text.Text object at 0x1033a2290>
> # ditto, no draw() required
>
> but if the axes methods are used, then interactive status is honored:
>
>  >>> plt.gca().set_xlabel('bbb')
> <matplotlib.text.Text object at 0x1033a2290>
>  >>> plt.gca().plot([1,2,3],[3,2,1])
> [<matplotlib.lines.Line2D object at 0x114e7cf90>]
>  >>> plt.gca().set_xlim(1,3)
> (1, 3)
> # all these require a plt.draw() to show up...
>
> I think that this is a misfeature, but maybe this is desired behavior?
>
> M
>
>
Which backend are you using and using which OS?

Ben Root

using a recent svn (r8900), I've noticed that after starting from a 
regular python shell:

 >>> import matplotlib.pyplot as plt
 >>> plt.isinteractive()
False
 >>> plt.plot([1,2,3],[1,3,2])
[<matplotlib.lines.Line2D object at 0x114e7a090>]
 >>> plt.plot([1,2,3],[1,2,3])
[<matplotlib.lines.Line2D object at 0x114e7a590>]
# plt.draw() is not required, the figure pops up
# and both plots are shown
 >>> plt.xlim(1,2)
(1, 2)
# again this works immediately no draw() required
 >>> plt.xlabel('aaa')
<matplotlib.text.Text object at 0x1033a2290>
# ditto, no draw() required

but if the axes methods are used, then interactive status is honored:

 >>> plt.gca().set_xlabel('bbb')
<matplotlib.text.Text object at 0x1033a2290>
 >>> plt.gca().plot([1,2,3],[3,2,1])
[<matplotlib.lines.Line2D object at 0x114e7cf90>]
 >>> plt.gca().set_xlim(1,3)
(1, 3)
# all these require a plt.draw() to show up...

I think that this is a misfeature, but maybe this is desired behavior?

M

On Mon, Feb 7, 2011 at 5:41 PM, John Hunter <jd...@gm...> wrote:
> On Feb 7, 2011, at 3:17 PM, Andrew Straw <str...@as...> wrote:
>
>> On 07-Feb-11 17:13, Darren Dale wrote:
>>> The git migration is still on hold, pending the return of CVS service
>>> at sourceforge. According to someone on the sourceforge IRC channel,
>>> CVS is estimated to return this week, but it might slip to next week.
>>
>> Thanks for the update.
>>
>> At some point, one could get tarballs of the entire version control
>> history from SF. I wonder if it would (still) be possible to simply
>> download a tarball of the CVS history. I tried looking around a bit, but
>> couldn't find them. Several years ago, I remember they used to be more
>> prominent, but then, as of a year or two ago, they moved to a much less
>> visible location. They were still available, but a bit trickier to find.
>> Anyhow, I think it's worth a few days more wait to try to get the
>> (almost) pre-history of MPL into git.
>>
>
> Responding by phone so I have limited ability to tinker, but take a look at this link. Should be able to guess the mpl URL from this info if the haven't reoranized
>
> http://www.python.org/dev/peps/pep-0347/#downloading-the-cvs-repository

This is a really helpful link, thanks John.

On Sun, Feb 6, 2011 at 2:02 PM, Eric Firing <ef...@ha...> wrote:

> On 02/06/2011 08:11 AM, Benjamin Root wrote:
> [...]
> >
> > Something I just noticed while looking at the x|ylim() functions.  The
> > code for xscale() and yscale() are acting like it returns something, but
> > they don't.  Is this a bug?  The documentation doesn't claim that it
> > returns anything.
>
> Ben,
>
> Like ax.xscale etc, it returns None.
>
> It's not exactly a bug--the behavior is correct and matches the
> documentation--but the code is misleading and less concise than it could
> be.  Having noticed it, you might as well clean it up.  The code would
> be clearer without the use of "ret" and "return", though the end effect
> will be no different.
>
> Eric
>
>
Done in the development branch in r8957

Ben Root

On Feb 7, 2011, at 3:17 PM, Andrew Straw <str...@as...> wrote:

> On 07-Feb-11 17:13, Darren Dale wrote:
>> The git migration is still on hold, pending the return of CVS service
>> at sourceforge. According to someone on the sourceforge IRC channel,
>> CVS is estimated to return this week, but it might slip to next week.
> 
> Thanks for the update.
> 
> At some point, one could get tarballs of the entire version control 
> history from SF. I wonder if it would (still) be possible to simply 
> download a tarball of the CVS history. I tried looking around a bit, but 
> couldn't find them. Several years ago, I remember they used to be more 
> prominent, but then, as of a year or two ago, they moved to a much less 
> visible location. They were still available, but a bit trickier to find. 
> Anyhow, I think it's worth a few days more wait to try to get the 
> (almost) pre-history of MPL into git.
> 

Responding by phone so I have limited ability to tinker, but take a look at this link. Should be able to guess the mpl URL from this info if the haven't reoranized

http://www.python.org/dev/peps/pep-0347/#downloading-the-cvs-repository



> -Andrew
> 
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 07-Feb-11 17:13, Darren Dale wrote:
> The git migration is still on hold, pending the return of CVS service
> at sourceforge. According to someone on the sourceforge IRC channel,
> CVS is estimated to return this week, but it might slip to next week.

Thanks for the update.

At some point, one could get tarballs of the entire version control 
history from SF. I wonder if it would (still) be possible to simply 
download a tarball of the CVS history. I tried looking around a bit, but 
couldn't find them. Several years ago, I remember they used to be more 
prominent, but then, as of a year or two ago, they moved to a much less 
visible location. They were still available, but a bit trickier to find. 
Anyhow, I think it's worth a few days more wait to try to get the 
(almost) pre-history of MPL into git.

-Andrew

The git migration is still on hold, pending the return of CVS service
at sourceforge. According to someone on the sourceforge IRC channel,
CVS is estimated to return this week, but it might slip to next week.

Darren

One of the things that bugs me about axes.hist is that with
histtype='step' the automatic legend style is an empty box, instead of
a line, as I would expect. This behaviour doesn't seem to make sense,
because it seems a line would be much more appropriate for this case.
Example is attached for the code:

import matplotlib.pyplot as plt
plt.hist([0,1,1,2,2,2], [0,1,2,3], histtype='step', label="histtype='step'")
plt.legend()
plt.show()

I can get around this by using proxy Line2D objects in building the
legend, but as this is an extremely common operation for me (the
common style of histograms in my field is equivalent to step) this
becomes messy and annoying. I'd rather not have to roll my own
histogram drawing function, as it would be almost entirely duplicating
the axes hist code, and don't know another way to get what I want. I
understand that the way of setting Legend styles is something that has
been looked at recently, but don't know the timescale for any changes.

The cause of this is the fact that in axes.py::7799 (current SVN
head), in axes.hist, patch objects are always created, even for the
line-based step style. I searched the tracker briefly, and couldn't
find this mentioned before. I therefore have a few questions:

- Is this intended behaviour, that I am just not understanding the
requirement for?
- Would changing this to create (and thus return) Line2D's instead of
Patch's for this histtype be a horrible breaking of the return
interface?

I've attached a patch that makes the simple change of swapping out the
call to .fill for .plot (only the function is changed here, not yet
the documentation), and it appears to work but I haven't tested
exhaustively.

Thoughts?

Nick

On 02/06/2011 08:11 AM, Benjamin Root wrote:
[...]
>
> Something I just noticed while looking at the x|ylim() functions.  The
> code for xscale() and yscale() are acting like it returns something, but
> they don't.  Is this a bug?  The documentation doesn't claim that it
> returns anything.

Ben,

Like ax.xscale etc, it returns None.

It's not exactly a bug--the behavior is correct and matches the 
documentation--but the code is misleading and less concise than it could 
be.  Having noticed it, you might as well clean it up.  The code would 
be clearer without the use of "ret" and "return", though the end effect 
will be no different.

Eric


>
> Ben Root
>

On Sun, Feb 6, 2011 at 11:52 AM, Eric Firing <ef...@ha...> wrote:

> On 02/06/2011 06:59 AM, Mike Kaufman wrote:
> >
> > The help for xlim() says:
> >
> >       Set/Get the xlimits of the current axes::
> >
> >         xmin, xmax = xlim()   # return the current xlim
> >         xlim( (xmin, xmax) )  # set the xlim to xmin, xmax
> >         xlim( xmin, xmax )    # set the xlim to xmin, xmax
> >
> >
> > but it also has the unexpected behavior of turning off autoscaling if
> used:
> >
> > -----
> > import matplotlib.pyplot as plt
> >
> > plt.clf()
> > ax = plt.subplot(211)
> > plt.draw()
> > print 'autoscale X on: ',ax._autoscaleXon,' xlim: ',plt.xlim()
> > ax.plot([0,.5,1,1.5,2],[0,1,0,1,0])
> > plt.draw()
> > print 'autoscale X on: ',ax._autoscaleXon,' xlim: ',ax.get_xlim(),'\n'
> >
> > ax = plt.subplot(212)
> > plt.draw()
> > print 'autoscale X on: ',ax._autoscaleXon,' xlim: ',ax.get_xlim()
> > plt.plot([0,.5,1,1.5,2],[0,1,0,1,0])
> > plt.draw()
> > print 'autoscale X on: ',ax._autoscaleXon,' xlim: ',ax.get_xlim(),'\n'
> > -----
> >
> > returns:
> >
> >   >>>  import xlim_unautoscale
> > autoscale X on:  True  xlim:  (0.0, 1.0)
> > autoscale X on:  False  xlim:  (0.0, 1.0)
> >
> > autoscale X on:  True  xlim:  (0.0, 1.0)
> > autoscale X on:  True  xlim:  (0.0, 2.0)
> >
> >
> > I assume that this is because xlim() calls set_xlim() which has
> > auto=False as a default keyword...
> >
> > expected behavior: xlim() should behave exactly like get_xlim()
> > ditto for ylim()
>
> I agree, so I have fixed this in the maintenance branch and in the trunk.
>
> Eric
>
>
Something I just noticed while looking at the x|ylim() functions.  The code
for xscale() and yscale() are acting like it returns something, but they
don't.  Is this a bug?  The documentation doesn't claim that it returns
anything.

Ben Root

On 02/06/2011 06:59 AM, Mike Kaufman wrote:
>
> The help for xlim() says:
>
>       Set/Get the xlimits of the current axes::
>
>         xmin, xmax = xlim()   # return the current xlim
>         xlim( (xmin, xmax) )  # set the xlim to xmin, xmax
>         xlim( xmin, xmax )    # set the xlim to xmin, xmax
>
>
> but it also has the unexpected behavior of turning off autoscaling if used:
>
> -----
> import matplotlib.pyplot as plt
>
> plt.clf()
> ax = plt.subplot(211)
> plt.draw()
> print 'autoscale X on: ',ax._autoscaleXon,' xlim: ',plt.xlim()
> ax.plot([0,.5,1,1.5,2],[0,1,0,1,0])
> plt.draw()
> print 'autoscale X on: ',ax._autoscaleXon,' xlim: ',ax.get_xlim(),'\n'
>
> ax = plt.subplot(212)
> plt.draw()
> print 'autoscale X on: ',ax._autoscaleXon,' xlim: ',ax.get_xlim()
> plt.plot([0,.5,1,1.5,2],[0,1,0,1,0])
> plt.draw()
> print 'autoscale X on: ',ax._autoscaleXon,' xlim: ',ax.get_xlim(),'\n'
> -----
>
> returns:
>
>   >>>  import xlim_unautoscale
> autoscale X on:  True  xlim:  (0.0, 1.0)
> autoscale X on:  False  xlim:  (0.0, 1.0)
>
> autoscale X on:  True  xlim:  (0.0, 1.0)
> autoscale X on:  True  xlim:  (0.0, 2.0)
>
>
> I assume that this is because xlim() calls set_xlim() which has
> auto=False as a default keyword...
>
> expected behavior: xlim() should behave exactly like get_xlim()
> ditto for ylim()

I agree, so I have fixed this in the maintenance branch and in the trunk.

Eric

>
> M
>
> ------------------------------------------------------------------------------
> The modern datacenter depends on network connectivity to access resources
> and provide services. The best practices for maximizing a physical server's
> connectivity to a physical network are well understood - see how these
> rules translate into the virtual world?
> http://p.sf.net/sfu/oracle-sfdevnlfb
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel