Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

[Jeff Whitaker]

  On 8/30/10 1:21 AM, Fernando Perez wrote:
> Hi Eric,
>
> On Sat, Aug 28, 2010 at 4:27 PM, Eric Firing  wrote:
>> Impressive--but I don't think I understand why one would want plots rendered
>> inline rather than in separate windows.

Fernando:  I've got ipython-newkernal ipythonqt working on my mac - how 
do I tell it to switch between external plot windows and inline plots?  
External windows seems to be the default...

-Jeff

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] clf(), Axes3D and add_subplot

[Eric Firing]

On 09/04/2010 05:50 PM, Benjamin Root wrote:
> On Sat, Sep 4, 2010 at 3:20 AM, Jae-Joon Lee  > wrote:
>
> On Fri, Sep 3, 2010 at 4:14 AM, Benjamin Root  > wrote:
>  > I think there are multiple issues here.  Primarially, there is
> the issue
>  > that Axes3D is attaching itself to a figure.  However, in the
> interest of
>  > backwards-compatibility, we can't just fix this outright.  There
> is also the
>  > issue that there are multiple places in the Figure class that are
> adding
>  > axes to the figure object.  Ideally, shouldn't we have a single
> function
>  > that performs proper checks and adds an axes?  Then that function
> should be
>  > used in the other class functions to perform this action.  In my
> opinion,
>  > there is too much duplicated code here.
>
> While I agree that we need to do something with the duplicated code, I
> think our priority should be fixing a bug.
> The easiest solution (that is backward compatible) seems to be
> registering an Axes class that does not add itself to the figure.
> For example,
>
> class Axes3DBase(Axes):
> # All of the original Axes3D stuff, but do not add itself to the
> figure during the initialization
>
> class Axes3D(Axes3DBase):
> def __init__(self, ...)
> Axes3DBase.__init__(self, ...)
> self.fig.add_axes(self)
>
> # And register Axes3DBase instead of Axes3D
> import matplotlib.projections as proj
> proj.projection_registry.register(Axes3DBase)
>
> Regards,
>
> -JJ
>
>
>
> Hmm, that actually would solve the problem at hand.  What I am concerned
> about is having others use this as a way to solve other issues with
> Axes3D that we then can't get rid of it.
>
> My vote is that your approach be use as a last resort.  I doubt this bug
> is time-critical, and I rather see the problems in Figure be correctly
> addressed.

I agree.

I went ahead and committed a fix to the trunk, svn 8681, and closed the 
ticket.  Please review the changeset.  It can always be reverted or 
modified as needed.  The changeset solves the Axes3D problem by blocking 
double-addition of an Axes to a Figure.  It does this entirely in 
figure.py, plus a small change in artist.py.  It consolidates the 
tracking of Axes instances, eliminating _seen and turning .axes into a 
property.  Unfortunately, it causes a net increase in LOC.

There is still much duplication between add_axes and add_subplot which I 
did not try to address at all.  I don't know whether it is worth trying 
to factor out the commonality, or whether that would reduce readability.

Eric

>
> Ben Root
>
>
>
> --
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
>
>
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] clf(), Axes3D and add_subplot

[Benjamin Root]

On Sun, Sep 5, 2010 at 2:53 PM, Eric Firing  wrote:

> On 09/04/2010 05:50 PM, Benjamin Root wrote:
> > On Sat, Sep 4, 2010 at 3:20 AM, Jae-Joon Lee  > > wrote:
> >
> > On Fri, Sep 3, 2010 at 4:14 AM, Benjamin Root  > > wrote:
> >  > I think there are multiple issues here.  Primarially, there is
> > the issue
> >  > that Axes3D is attaching itself to a figure.  However, in the
> > interest of
> >  > backwards-compatibility, we can't just fix this outright.  There
> > is also the
> >  > issue that there are multiple places in the Figure class that are
> > adding
> >  > axes to the figure object.  Ideally, shouldn't we have a single
> > function
> >  > that performs proper checks and adds an axes?  Then that function
> > should be
> >  > used in the other class functions to perform this action.  In my
> > opinion,
> >  > there is too much duplicated code here.
> >
> > While I agree that we need to do something with the duplicated code,
> I
> > think our priority should be fixing a bug.
> > The easiest solution (that is backward compatible) seems to be
> > registering an Axes class that does not add itself to the figure.
> > For example,
> >
> > class Axes3DBase(Axes):
> > # All of the original Axes3D stuff, but do not add itself to the
> > figure during the initialization
> >
> > class Axes3D(Axes3DBase):
> > def __init__(self, ...)
> > Axes3DBase.__init__(self, ...)
> > self.fig.add_axes(self)
> >
> > # And register Axes3DBase instead of Axes3D
> > import matplotlib.projections as proj
> > proj.projection_registry.register(Axes3DBase)
> >
> > Regards,
> >
> > -JJ
> >
> >
> >
> > Hmm, that actually would solve the problem at hand.  What I am concerned
> > about is having others use this as a way to solve other issues with
> > Axes3D that we then can't get rid of it.
> >
> > My vote is that your approach be use as a last resort.  I doubt this bug
> > is time-critical, and I rather see the problems in Figure be correctly
> > addressed.
>
> I agree.
>
> I went ahead and committed a fix to the trunk, svn 8681, and closed the
> ticket.  Please review the changeset.  It can always be reverted or
> modified as needed.  The changeset solves the Axes3D problem by blocking
> double-addition of an Axes to a Figure.  It does this entirely in
> figure.py, plus a small change in artist.py.  It consolidates the
> tracking of Axes instances, eliminating _seen and turning .axes into a
> property.  Unfortunately, it causes a net increase in LOC.
>
> There is still much duplication between add_axes and add_subplot which I
> did not try to address at all.  I don't know whether it is worth trying
> to factor out the commonality, or whether that would reduce readability.
>
> Eric
>
>
Eric,

Looking through the changeset, everything seems fine to me.  My only
question is that it seemed, to me at least, that it was possible to add an
axes to a figure without adding a key.  Was this an invalid operation or
not?  If not, how does the AxesStack handle axes without a key?

Thanks,
Ben Root
--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

[Fernando Perez]

Hi Jeff,

On Sun, Sep 5, 2010 at 10:18 AM, Jeff Whitaker  wrote:
>
> Fernando:  I've got ipython-newkernal ipythonqt working on my mac - how do I
> tell it to switch between external plot windows and inline plots?  External
> windows seems to be the default...

if you start it with --rich, it will use inline plots.  I'll try to
improve the code so that *both* are possible simultaneously:
interactive external windows for zooming and panning, and a function
loaded into the user's namespace, similar to show(), that would
instead embed them inline.

Cheers,

f

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] clf(), Axes3D and add_subplot

[Eric Firing]

On 09/05/2010 11:06 AM, Benjamin Root wrote:
> On Sun, Sep 5, 2010 at 2:53 PM, Eric Firing  > wrote:
>
> On 09/04/2010 05:50 PM, Benjamin Root wrote:
>  > On Sat, Sep 4, 2010 at 3:20 AM, Jae-Joon Lee
> mailto:lee.j.j...@gmail.com>
>  > >> wrote:
>  >
>  > On Fri, Sep 3, 2010 at 4:14 AM, Benjamin Root
> mailto:ben.r...@ou.edu>
>  > >> wrote:
>  > > I think there are multiple issues here.  Primarially, there is
>  > the issue
>  > > that Axes3D is attaching itself to a figure.  However, in the
>  > interest of
>  > > backwards-compatibility, we can't just fix this outright.  There
>  > is also the
>  > > issue that there are multiple places in the Figure class that are
>  > adding
>  > > axes to the figure object.  Ideally, shouldn't we have a single
>  > function
>  > > that performs proper checks and adds an axes?  Then that function
>  > should be
>  > > used in the other class functions to perform this action.  In my
>  > opinion,
>  > > there is too much duplicated code here.
>  >
>  > While I agree that we need to do something with the
> duplicated code, I
>  > think our priority should be fixing a bug.
>  > The easiest solution (that is backward compatible) seems to be
>  > registering an Axes class that does not add itself to the figure.
>  > For example,
>  >
>  > class Axes3DBase(Axes):
>  > # All of the original Axes3D stuff, but do not add itself
> to the
>  > figure during the initialization
>  >
>  > class Axes3D(Axes3DBase):
>  > def __init__(self, ...)
>  > Axes3DBase.__init__(self, ...)
>  > self.fig.add_axes(self)
>  >
>  > # And register Axes3DBase instead of Axes3D
>  > import matplotlib.projections as proj
>  > proj.projection_registry.register(Axes3DBase)
>  >
>  > Regards,
>  >
>  > -JJ
>  >
>  >
>  >
>  > Hmm, that actually would solve the problem at hand.  What I am
> concerned
>  > about is having others use this as a way to solve other issues with
>  > Axes3D that we then can't get rid of it.
>  >
>  > My vote is that your approach be use as a last resort.  I doubt
> this bug
>  > is time-critical, and I rather see the problems in Figure be
> correctly
>  > addressed.
>
> I agree.
>
> I went ahead and committed a fix to the trunk, svn 8681, and closed the
> ticket.  Please review the changeset.  It can always be reverted or
> modified as needed.  The changeset solves the Axes3D problem by blocking
> double-addition of an Axes to a Figure.  It does this entirely in
> figure.py, plus a small change in artist.py.  It consolidates the
> tracking of Axes instances, eliminating _seen and turning .axes into a
> property.  Unfortunately, it causes a net increase in LOC.
>
> There is still much duplication between add_axes and add_subplot which I
> did not try to address at all.  I don't know whether it is worth trying
> to factor out the commonality, or whether that would reduce readability.
>
> Eric
>
>
> Eric,
>
> Looking through the changeset, everything seems fine to me.  My only
> question is that it seemed, to me at least, that it was possible to add
> an axes to a figure without adding a key.  Was this an invalid operation
> or not?  If not, how does the AxesStack handle axes without a key?

Ben,

I think that it aught not be possible to add an axes without a key--but 
it looks like it is possible at present via add_subplot.  I will try to 
fix that.

Eric

>
> Thanks,
> Ben Root
>


--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

[Jeff Whitaker]

  On 9/5/10 3:15 PM, Fernando Perez wrote:
> Hi Jeff,
>
> On Sun, Sep 5, 2010 at 10:18 AM, Jeff Whitaker  wrote:
>> Fernando:  I've got ipython-newkernal ipythonqt working on my mac - how do I
>> tell it to switch between external plot windows and inline plots?  External
>> windows seems to be the default...
> if you start it with --rich, it will use inline plots.  I'll try to
> improve the code so that *both* are possible simultaneously:
> interactive external windows for zooming and panning, and a function
> loaded into the user's namespace, similar to show(), that would
> instead embed them inline.
>
> Cheers,
>
> f
Fernando:  That works, but it seems like I have to run show() to make 
the plot appear inline.  draw() doesn't do it.  Is this the expected 
behavior?

-Jeff

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

[Fernando Perez]

Hi Jeff,

On Sun, Sep 5, 2010 at 5:25 PM, Jeff Whitaker  wrote:
> Fernando:  That works, but it seems like I have to run show() to make the
> plot appear inline.  draw() doesn't do it.  Is this the expected behavior?
>

Yes, currently it is, because the show() you're running is actually
*our* show() which we've overwritten to do the svg transport.

The interface to all of this is very new and completely experimental,
so we're more than happy to take suggestions/ideas/code on how to make
it work better.

Regards,

f

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] clf(), Axes3D and add_subplot

[Eric Firing]

On 09/05/2010 11:06 AM, Benjamin Root wrote:
> On Sun, Sep 5, 2010 at 2:53 PM, Eric Firing  > wrote:
>
> On 09/04/2010 05:50 PM, Benjamin Root wrote:
>  > On Sat, Sep 4, 2010 at 3:20 AM, Jae-Joon Lee
> mailto:lee.j.j...@gmail.com>
>  > >> wrote:
>  >
>  > On Fri, Sep 3, 2010 at 4:14 AM, Benjamin Root
> mailto:ben.r...@ou.edu>
>  > >> wrote:
>  > > I think there are multiple issues here.  Primarially, there is
>  > the issue
>  > > that Axes3D is attaching itself to a figure.  However, in the
>  > interest of
>  > > backwards-compatibility, we can't just fix this outright.  There
>  > is also the
>  > > issue that there are multiple places in the Figure class that are
>  > adding
>  > > axes to the figure object.  Ideally, shouldn't we have a single
>  > function
>  > > that performs proper checks and adds an axes?  Then that function
>  > should be
>  > > used in the other class functions to perform this action.  In my
>  > opinion,
>  > > there is too much duplicated code here.
>  >
>  > While I agree that we need to do something with the
> duplicated code, I
>  > think our priority should be fixing a bug.
>  > The easiest solution (that is backward compatible) seems to be
>  > registering an Axes class that does not add itself to the figure.
>  > For example,
>  >
>  > class Axes3DBase(Axes):
>  > # All of the original Axes3D stuff, but do not add itself
> to the
>  > figure during the initialization
>  >
>  > class Axes3D(Axes3DBase):
>  > def __init__(self, ...)
>  > Axes3DBase.__init__(self, ...)
>  > self.fig.add_axes(self)
>  >
>  > # And register Axes3DBase instead of Axes3D
>  > import matplotlib.projections as proj
>  > proj.projection_registry.register(Axes3DBase)
>  >
>  > Regards,
>  >
>  > -JJ
>  >
>  >
>  >
>  > Hmm, that actually would solve the problem at hand.  What I am
> concerned
>  > about is having others use this as a way to solve other issues with
>  > Axes3D that we then can't get rid of it.
>  >
>  > My vote is that your approach be use as a last resort.  I doubt
> this bug
>  > is time-critical, and I rather see the problems in Figure be
> correctly
>  > addressed.
>
> I agree.
>
> I went ahead and committed a fix to the trunk, svn 8681, and closed the
> ticket.  Please review the changeset.  It can always be reverted or
> modified as needed.  The changeset solves the Axes3D problem by blocking
> double-addition of an Axes to a Figure.  It does this entirely in
> figure.py, plus a small change in artist.py.  It consolidates the
> tracking of Axes instances, eliminating _seen and turning .axes into a
> property.  Unfortunately, it causes a net increase in LOC.
>
> There is still much duplication between add_axes and add_subplot which I
> did not try to address at all.  I don't know whether it is worth trying
> to factor out the commonality, or whether that would reduce readability.
>
> Eric
>
>
> Eric,
>
> Looking through the changeset, everything seems fine to me.  My only
> question is that it seemed, to me at least, that it was possible to add
> an axes to a figure without adding a key.  Was this an invalid operation
> or not?  If not, how does the AxesStack handle axes without a key?

Ben,

It might have been OK already, but I tweaked things a bit to ensure a 
key would be available, and I added a check for duplicate keys.  Can you 
find a way to make it fail with legitimate code?  As before, it passes 
backend_driver.py, but that certainly doesn't exercise all the 
possibilities.

Eric

>
> Thanks,
> Ben Root
>


--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] clf(), Axes3D and add_subplot

[Benjamin Root]

On Sun, Sep 5, 2010 at 9:16 PM, Eric Firing  wrote:

> On 09/05/2010 11:06 AM, Benjamin Root wrote:
>
>> On Sun, Sep 5, 2010 at 2:53 PM, Eric Firing > > wrote:
>>
>>On 09/04/2010 05:50 PM, Benjamin Root wrote:
>> > On Sat, Sep 4, 2010 at 3:20 AM, Jae-Joon Lee
>>mailto:lee.j.j...@gmail.com>
>> > >> wrote:
>> >
>> > On Fri, Sep 3, 2010 at 4:14 AM, Benjamin Root
>>mailto:ben.r...@ou.edu>
>> > >> wrote:
>> > > I think there are multiple issues here.  Primarially, there is
>> > the issue
>> > > that Axes3D is attaching itself to a figure.  However, in the
>> > interest of
>> > > backwards-compatibility, we can't just fix this outright.  There
>> > is also the
>> > > issue that there are multiple places in the Figure class that are
>> > adding
>> > > axes to the figure object.  Ideally, shouldn't we have a single
>> > function
>> > > that performs proper checks and adds an axes?  Then that function
>> > should be
>> > > used in the other class functions to perform this action.  In my
>> > opinion,
>> > > there is too much duplicated code here.
>> >
>> > While I agree that we need to do something with the
>>duplicated code, I
>> > think our priority should be fixing a bug.
>> > The easiest solution (that is backward compatible) seems to be
>> > registering an Axes class that does not add itself to the
>> figure.
>> > For example,
>> >
>> > class Axes3DBase(Axes):
>> > # All of the original Axes3D stuff, but do not add itself
>>to the
>> > figure during the initialization
>> >
>> > class Axes3D(Axes3DBase):
>> > def __init__(self, ...)
>> > Axes3DBase.__init__(self, ...)
>> > self.fig.add_axes(self)
>> >
>> > # And register Axes3DBase instead of Axes3D
>> > import matplotlib.projections as proj
>> > proj.projection_registry.register(Axes3DBase)
>> >
>> > Regards,
>> >
>> > -JJ
>> >
>> >
>> >
>> > Hmm, that actually would solve the problem at hand.  What I am
>>concerned
>> > about is having others use this as a way to solve other issues with
>> > Axes3D that we then can't get rid of it.
>> >
>> > My vote is that your approach be use as a last resort.  I doubt
>>this bug
>> > is time-critical, and I rather see the problems in Figure be
>>correctly
>> > addressed.
>>
>>I agree.
>>
>>I went ahead and committed a fix to the trunk, svn 8681, and closed the
>>ticket.  Please review the changeset.  It can always be reverted or
>>modified as needed.  The changeset solves the Axes3D problem by
>> blocking
>>double-addition of an Axes to a Figure.  It does this entirely in
>>figure.py, plus a small change in artist.py.  It consolidates the
>>tracking of Axes instances, eliminating _seen and turning .axes into a
>>property.  Unfortunately, it causes a net increase in LOC.
>>
>>There is still much duplication between add_axes and add_subplot which
>> I
>>did not try to address at all.  I don't know whether it is worth trying
>>to factor out the commonality, or whether that would reduce
>> readability.
>>
>>Eric
>>
>>
>> Eric,
>>
>> Looking through the changeset, everything seems fine to me.  My only
>> question is that it seemed, to me at least, that it was possible to add
>> an axes to a figure without adding a key.  Was this an invalid operation
>> or not?  If not, how does the AxesStack handle axes without a key?
>>
>
> Ben,
>
> It might have been OK already, but I tweaked things a bit to ensure a key
> would be available, and I added a check for duplicate keys.  Can you find a
> way to make it fail with legitimate code?  As before, it passes
> backend_driver.py, but that certainly doesn't exercise all the
> possibilities.
>
> Eric
>
>
Code mayhem?  I'll see what I can do!

Ben Root
--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel