matplotlib-devel Mailing List for matplotlib

Hi,
>> That's because Sourceforge runs an opt-out blocking policy. If y'all
>> agree that there's no reason to block matplotlib downloads from Cuba,
>> China etc, would someone mind setting the 'this is not a cryptographic
>> program' setting in the sourceforge interface?
>
> Done.
>
> The relevant option in "export controls" is
>
> This project does NOT incorporate, access, call upon, or otherwise use
> encryption of any kind, including, but not limited to, open source
> algorithms and/or calls to encryption in the operating system or
> underlying platform.
Thanks very much ;)
Matthew

On 09/06/2010 06:25 AM, Matthew Brett wrote:
> Hi,
>
> Sorry to ask, but would y'all mind unblocking matlplotlib downloads from Cuba?
>
> I just tried the download from here in Havana, and got:
>
> 403 Error – Forbidden
>
> Your request is being denied as it appears to be coming from a
> location banned by our Terms of Use.
>
> That's because Sourceforge runs an opt-out blocking policy. If y'all
> agree that there's no reason to block matplotlib downloads from Cuba,
> China etc, would someone mind setting the 'this is not a cryptographic
> program' setting in the sourceforge interface?
Done.
The relevant option in "export controls" is
This project does NOT incorporate, access, call upon, or otherwise use 
encryption of any kind, including, but not limited to, open source 
algorithms and/or calls to encryption in the operating system or 
underlying platform.
As far as I can see, mpl passes this test.
Eric
>
> Thanks a lot,
>
> Matthew

Hi,
Sorry to ask, but would y'all mind unblocking matlplotlib downloads from Cuba?
I just tried the download from here in Havana, and got:
403 Error – Forbidden
Your request is being denied as it appears to be coming from a
location banned by our Terms of Use.
That's because Sourceforge runs an opt-out blocking policy. If y'all
agree that there's no reason to block matplotlib downloads from Cuba,
China etc, would someone mind setting the 'this is not a cryptographic
program' setting in the sourceforge interface?
Thanks a lot,
Matthew

 On 9/5/10 6:32 PM, Fernando Perez wrote:
> Hi Jeff,
>
> On Sun, Sep 5, 2010 at 5:25 PM, Jeff Whitaker<js...@fa...> 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
Fernando: Got it, thanks. Sounds reasonable to me. Just playing with 
it a bit, one thing I found myself looking for was a way to save the 
entire session (inline figures included) to html.
-Jeff

On Sun, Sep 5, 2010 at 9:16 PM, Eric Firing <ef...@ha...> wrote:
> On 09/05/2010 11:06 AM, Benjamin Root wrote:
>
>> On Sun, Sep 5, 2010 at 2:53 PM, Eric Firing <ef...@ha...
>> <mailto:ef...@ha...>> wrote:
>>
>> On 09/04/2010 05:50 PM, Benjamin Root wrote:
>> > On Sat, Sep 4, 2010 at 3:20 AM, Jae-Joon Lee
>> <lee...@gm... <mailto:lee...@gm...>
>> > <mailto:lee...@gm... <mailto:lee...@gm...>>> wrote:
>> >
>> > On Fri, Sep 3, 2010 at 4:14 AM, Benjamin Root
>> <ben...@ou... <mailto:ben...@ou...>
>> > <mailto:ben...@ou... <mailto:ben...@ou...>>> 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

On 09/05/2010 11:06 AM, Benjamin Root wrote:
> On Sun, Sep 5, 2010 at 2:53 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
> On 09/04/2010 05:50 PM, Benjamin Root wrote:
> > On Sat, Sep 4, 2010 at 3:20 AM, Jae-Joon Lee
> <lee...@gm... <mailto:lee...@gm...>
> > <mailto:lee...@gm... <mailto:lee...@gm...>>> wrote:
> >
> > On Fri, Sep 3, 2010 at 4:14 AM, Benjamin Root
> <ben...@ou... <mailto:ben...@ou...>
> > <mailto:ben...@ou... <mailto:ben...@ou...>>> 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
>

Hi Jeff,
On Sun, Sep 5, 2010 at 5:25 PM, Jeff Whitaker <js...@fa...> 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

 On 9/5/10 3:15 PM, Fernando Perez wrote:
> Hi Jeff,
>
> On Sun, Sep 5, 2010 at 10:18 AM, Jeff Whitaker<js...@fa...> 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