[matplotlib-devel] git migration

2011-02-07 Thread Darren Dale 
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

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git migration

2011-02-07 Thread Andrew Straw 
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 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git migration

2011-02-07 Thread John Hunter 




On Feb 7, 2011, at 3:17 PM, Andrew Straw  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
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] xlim() turns off autoscaling

2011-02-07 Thread Benjamin Root 
On Sun, Feb 6, 2011 at 2:02 PM, Eric Firing  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
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git migration

2011-02-07 Thread Darren Dale 
On Mon, Feb 7, 2011 at 5:41 PM, John Hunter  wrote:
> On Feb 7, 2011, at 3:17 PM, Andrew Straw  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.

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] pyplot commands appear to ignore interactive status

2011-02-07 Thread Mike Kaufman 

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])
[]
 >>> plt.plot([1,2,3],[1,2,3])
[]
# 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')

# ditto, no draw() required

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

 >>> plt.gca().set_xlabel('bbb')

 >>> plt.gca().plot([1,2,3],[3,2,1])
[]
 >>> 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



--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] pyplot commands appear to ignore interactive status

2011-02-07 Thread Benjamin Root 
On Mon, Feb 7, 2011 at 7:20 PM, Mike Kaufman  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])
> []
>  >>> plt.plot([1,2,3],[1,2,3])
> []
> # 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')
> 
> # ditto, no draw() required
>
> but if the axes methods are used, then interactive status is honored:
>
>  >>> plt.gca().set_xlabel('bbb')
> 
>  >>> plt.gca().plot([1,2,3],[3,2,1])
> []
>  >>> 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
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] pyplot commands appear to ignore interactive status

2011-02-07 Thread Mike Kaufman 
On 2/7/11 9:02 PM, Benjamin Root wrote:
> On Mon, Feb 7, 2011 at 7:20 PM, Mike Kaufman  > 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])
> []
>  >>> plt.plot([1,2,3],[1,2,3])
> []
> # 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')
> 
> # ditto, no draw() required
>
> but if the axes methods are used, then interactive status is honored:
>
>  >>> plt.gca().set_xlabel('bbb')
> 
>  >>> plt.gca().plot([1,2,3],[3,2,1])
> []
>  >>> 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

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] pyplot commands appear to ignore interactive status

2011-02-07 Thread Eric Firing 
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> >  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])
>>  []
>>   >>>  plt.plot([1,2,3],[1,2,3])
>>  []
>>  # 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')
>>  
>>  # ditto, no draw() required
>>
>>  but if the axes methods are used, then interactive status is honored:
>>
>>   >>>  plt.gca().set_xlabel('bbb')
>>  
>>   >>>  plt.gca().plot([1,2,3],[3,2,1])
>>  []
>>   >>>  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
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] pyplot commands appear to ignore interactive status

2011-02-07 Thread Mike Kaufman 
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 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] pyplot commands appear to ignore interactive status

2011-02-07 Thread Benjamin Root 
On Mon, Feb 7, 2011 at 9:17 PM, Mike Kaufman  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
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] pyplot commands appear to ignore interactive status

2011-02-07 Thread Mike Kaufman 
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


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel