matplotlib-devel Mailing List for matplotlib

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