matplotlib-devel Mailing List for matplotlib (Page 5)

JJ,
> I just wanted to raise a question of whether we let Axes3D add itself
> to its parent (although this is not a bug anymore). If you and others
> feel okay about it, then that's completely fine with me also.
It sounds like a valid point, worth addressing, but it is one I will 
leave to you, Ben, and Reinier to sort out.
Eric

On Thu, Sep 9, 2010 at 4:13 AM, Eric Firing <ef...@ha...> wrote:
> I don't think I understand the point you are making here--is it that the
> Axes3D is a lone anomaly?
>
Yes.
And I feel that Axes3D better not add itself to the figure during the
instance initialization. Just a different view of the current bug.
> The main purpose of the changes I made was to clarify the tracking of axes
> by having them internally listed in only one data structure instead of
> always having to add or remove them from three separate structures. Fixing
> the 3D bug was a side-effect. Whether the changes I made were a net
> improvement, or a good design, remains debatable. Criticisms and
> suggestions for improvement or replacement are welcome.
>
I think this is what need to be done and I think you did it right
(thank you for your effort).
I just wanted to raise a question of whether we let Axes3D add itself
to its parent (although this is not a bug anymore). If you and others
feel okay about it, then that's completely fine with me also.
Regards,
-JJ

On Thu, Sep 9, 2010 at 9:38 AM, Eric Firing <ef...@ha...> wrote:
> Fixed in 8693.
>
Thanks!
-JJ

On 09/07/2010 10:27 PM, Jae-Joon Lee wrote:
> Eric,
>
> The drawing order of multiple axes in a same figure depends on the
> order of "axes". And this has been the order that axes is added to the
> figure (given that they have same zorder value). However, the current
> implementation does not preserve this order.
Fixed in 8693.
Eric

On Wed, Sep 8, 2010 at 12:57 PM, Jouni K. Seppänen <jk...@ik...> wrote:
>> 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.
I think mpl complies with this spirit of this clause: no nation on the
restricted list could reasonably use mpl in an encryption/decryption
effort. As for Jouni's explicit question: potentially copying some
encrypted font data but not encrypting or decrypting it, I think that
does not qualify as "otherwise use encryption of any kind" though I
suppose this is open to interpretation. If we ever receive a
reasonable request from the justice department asking us to
cease-and-desist, we would certainly comply with that.
So I suggest leaving the export controls turned off, as Eric has done.
 Thanks for the head's up Matthew (I thought we had already taken care
of this ...)
JDH

On 09/07/2010 10:27 PM, Jae-Joon Lee wrote:
> Eric,
>
> The drawing order of multiple axes in a same figure depends on the
> order of "axes". And this has been the order that axes is added to the
> figure (given that they have same zorder value). However, the current
> implementation does not preserve this order.
>
> For example,
>
>
> ax1 = axes([0.1, 0.1, 0.5, 0.5])
> ax2 = axes([0.4, 0.4, 0.5, 0.5])
>
> draw() # ax2 on top of ax1
>
>
> sca(ax1)
> draw() # ax2 underneath ax1
>
> For some artist that spans multiple axes (e.g., an arrow connecting
> two points in different axes), the drawing order of the axes is
> important. We may manually adjust the zorder. Still. I think it is
> better if Figure.axes preserves the order that axes are added.
Thanks for pointing this out. I will look into a modification to 
preserve that order. Probably it will involve storing a third element 
in each tuple, and sorting on that when generating the axes list.
>
> I believe this bug also affects the maintenance branch. Are you
> planning to propagate this changes to the maint. branch also?
No, my thinking is that the change I made is a bit too extensive for 
inclusion in the maintenance branch, and the priority for fixing the 
somewhat obscure 3D bug in that branch is low--especially given that the 
3D code has many bugs (most of the current bugs on the tracker) and will 
most likely be reworked in the trunk over time.
>
> Besides, I think none of the matplotlib artist add itself to its
> parent during the initialization. And, I think this is more of the
> design choice, i.e., the artist instance is added to its parent
> "after" the initialization. Anyhow, such distinction may not very
> practical in the current implementation and I'm completely okay with
> your changes (except the issues above).
I don't think I understand the point you are making here--is it that the 
Axes3D is a lone anomaly?
The main purpose of the changes I made was to clarify the tracking of 
axes by having them internally listed in only one data structure instead 
of always having to add or remove them from three separate structures. 
Fixing the 3D bug was a side-effect. Whether the changes I made were a 
net improvement, or a good design, remains debatable. Criticisms and 
suggestions for improvement or replacement are welcome.
Eric
>
> Regards,
>
> -JJ

Eric Firing <efiring@...> writes:
> 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.
I don't know whether lib/matplotlib/type1font.py meets this test. It
is needed by the usetex support for at least the pdf backend.
Owing to a former business model of Adobe, Type-1 fonts are
encrypted. The algorithm and encryption key are now widely known (and
Adobe distributes a technical note disclosing them), but it is still
an encryption algorithm.
The current version of type1font.py does not decrypt fonts, but it
accesses the encrypted part of a font and can be used to copy it in
the output postscript or pdf file. That could fall under "otherwise
use" as far as I understand (English is not my first language, and
legalese far less).
I have had some plans of adding Type-1 font subsetting support, which
I believe requires including the encryption algorithm.
Jouni

On 09/06/2010 02:34 PM, Eric Firing wrote:
> 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.
> 
What about the path simplification or contouring source code? I would 
think that kind of intense code obfuscation would count as encryption... ;)
<for the lawyers, the above is a joke>
Mike
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

I believe I have a fix in r8691 (both branch and trunk).
Cheers,
Mike
On 09/03/2010 03:31 PM, Eric Firing wrote:
> On 09/03/2010 09:14 AM, Tony S Yu wrote:
> 
>> On Sep 3, 2010, at 10:23 AM, Sébastien Barthélemy wrote:
>>
>> 
>>> CC to matplotlib-devel& matplotlib-users
>>>
>>> 2010年9月3日 Tony S Yu<ts...@gm...>:
>>> 
>>>> On Sep 3, 2010, at 4:33 AM, Sébastien Barthélemy wrote:
>>>>
>>>> 
>>>>> Hello,
>>>>>
>>>>> While using sage [1], I got problems drawing a line: for some reason,
>>>>> the points with negative coordinates are not plotted (or are plotted
>>>>> on top of others due to an offset problem and thus I cannot see them).
>>>>> I can only reproduce the bug with specific data sets.
>>>>>
>>>>> [1] www.sagemath.org
>>>>>
>>>>> I think I could track down the bug to matplotlib, which sage uses to
>>>>> render 2d plots.
>>>>>
>>>>> I included a sage script which generates the data set (in a pickle
>>>>> file), and a python script which draws the faulty line.
>>>>>
>>>>> Usage is :
>>>>>
>>>>> $ sage generate_data.sage
>>>>> $ python test_mpl.py
>>>>>
>>>>> I also included the pickled data, thus you don't need sage at all.
>>>>> I use matplotlib 1.0.0 for python 2.6 on mac os (as provided by macport).
>>>>>
>>>>> Could somebody here confirm the problem, and give me a hint about what
>>>>> is going on?
>>>>> 
>>>> I can confirm the issue.
>>>> 
>>> Great, thank you. I filed a bug:
>>> https://sourceforge.net/tracker/?func=detail&aid=3058804&group_id=80706&atid=560720
>>>
>>> 
>>>> This appears to be a drawing bug: when I pan the drawing so that the negative data touches the edge of the axes frame, the rest of the line is drawn. So the line object is being created, but for some reason it's not being drawn correctly.
>>>>
>>>> The bug is really finicky: if I plot starting from the 3rd value of your data (i.e. slice xdata, ydata with [2:]), the line is drawn completely. The strange thing is that the first 100 or so data points defines the exact same point, so there's noting special about those first two points. (but this overlaying of data may be related to the bug)
>>>>
>>>> I've reproduced the issue on TkAgg, Qt4Agg, and MacOSX backends, so maybe the bug is in backend_bases. (Note: unlike Agg backends, MacOSX backend doesn't show line even after panning the plot)
>>>>
>>>> I don't really know how to debug drawing errors like this; so this is as far as can get.
>>>> 
>> I'm not sure if I should respond to this email or the bug report, but since I made the claim here, I'll correct myself here: The bug is not in the drawing code as I had suggested.
>>
>> The bug is related to path simplification. If you turn off path simplification (e.g. plt.rc('path', simplify=False), the line is drawn in its entirety. This also explains why the bug disappeared when I trimmed the first two points: path simplification is triggered from data sets with atleast 128 points (your data has 129, so trimming two points turned off path simplification).
>>
>> I just wanted to correct my earlier comments.
>>
>> 
> Tony,
>
> Thanks--it's in a comment added to the bug report. Also, this is the
> same problem as reported earlier by Jens Nie. The bug is in
> path_converters.h. I think I found part of it, but a real solution may
> require more than a changed line or two, and I can't spend more time on
> it at the moment. Mike D. could figure it out quickly, but I think he
> is not available right now.
>
> Eric
>
> 
>> -T
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> Mat...@li...
>> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

When you press Ctrl-., the client prompts you to make sure that you
really want to restart the kernel. Your work is not at risk from a
careless key press.
Evan
On Wed, Sep 8, 2010 at 9:58 AM, Nathaniel Smith <nj...@po...> wrote:
> On Wed, Sep 8, 2010 at 12:12 AM, Fernando Perez <fpe...@gm...> wrote:
>> ps - tip: Ctrl-. restarts the kernel
>
> Tangentially... please make this something that's a little harder to
> hit by accident, like Ctrl-Alt-. or a menu item or something? My
> ipython's regularly hold state that would take a few CPU-days to
> reconstruct.
>
> (Sorry for the off-topic.)
>
> -- Nathaniel
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Wed, Sep 8, 2010 at 12:12 AM, Fernando Perez <fpe...@gm...> wrote:
> ps - tip: Ctrl-. restarts the kernel
Tangentially... please make this something that's a little harder to
hit by accident, like Ctrl-Alt-. or a menu item or something? My
ipython's regularly hold state that would take a few CPU-days to
reconstruct.
(Sorry for the off-topic.)
-- Nathaniel

Eric,
The drawing order of multiple axes in a same figure depends on the
order of "axes". And this has been the order that axes is added to the
figure (given that they have same zorder value). However, the current
implementation does not preserve this order.
For example,
ax1 = axes([0.1, 0.1, 0.5, 0.5])
ax2 = axes([0.4, 0.4, 0.5, 0.5])
draw() # ax2 on top of ax1
sca(ax1)
draw() # ax2 underneath ax1
For some artist that spans multiple axes (e.g., an arrow connecting
two points in different axes), the drawing order of the axes is
important. We may manually adjust the zorder. Still. I think it is
better if Figure.axes preserves the order that axes are added.
I believe this bug also affects the maintenance branch. Are you
planning to propagate this changes to the maint. branch also?
Besides, I think none of the matplotlib artist add itself to its
parent during the initialization. And, I think this is more of the
design choice, i.e., the artist instance is added to its parent
"after" the initialization. Anyhow, such distinction may not very
practical in the current implementation and I'm completely okay with
your changes (except the issues above).
Regards,
-JJ

Hi Jeff,
On Mon, Sep 6, 2010 at 6:27 AM, Jeff Whitaker <js...@fa...> wrote:
> 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.
>
Of course! When is the patch coming? ;)
Yes, that will be the obvious first thing everybody will want. And it
shouldn't be too hard to write, either. In fact, if we store the svg
payloads in a dict keyed by input line number kernel-side, it would be
pretty easy to write a little function that will take a session and
will generate a reST document with figures and all, with .. image::
directives.
BTW, in my branch (fperez/newkernel) it's already working with inline
figures not needing a show() call at all, and a 'paste()' function to
paste any figure inline if you use one of the gui backends. We should
have it merged in a day or two.
Cheers,
f
ps - tip: Ctrl-. restarts the kernel, and Ctrl-L clears the screen.
So it's quick to get a fresh state, but keeping all your input history
you've been typing client-side unmodified. We're starting to get the
benefits of the two-process model...

On 09/07/2010 11:07 AM, Fernando Perez wrote:
> Hi Eric,
>
> On Tue, Sep 7, 2010 at 1:31 PM, Eric Firing<ef...@ha...> wrote:
>>
>> I have been doing a little testing with ipython 0.10 versus
>> ipython-newkernel, both modes, and with mpl svn versus your guisupport.
>> There are so many possible modes of operation and combinations of
>> versions and backends that all this will take some time to sort out.
>>
>> Can you give me simple examples of what does *not* work correctly when
>> you use mpl *svn* with ipython-newkernel, in either or both of the
>> console or gui modes, but *does* work with your guisupport version?
>
> Thanks for your testing, Eric.
>
> With matplotlib *alone*, I can't find a way to crash/lock/whatever the
> combo of matplotlib(svn)+ipython-newkernel.
>
> The reason, i believe, is that guisupport.py is available in ipython
> itself, and it goes out of its way to avoid creating a second main qt
> app, letting matplotlib create it. Since that main app is alive all
> the time, there's only one app and one event loop and life is good.
> But if I were to open another library that uses Qt and makes a new
> main qApp unconditionally, we'd have problems.
>
> Brian and Evan have recently just added the guisupport.py patch to
> Enthought's ETS, so that now it probably will be pretty hard to
> actually see the problem: if both ipython and ets go out of their way
> to avoid the nested main app issue, mpl can get away with making one
> unconditionally and things will probably work OK.
>
> But the idea is for all of us (ipython, ets, mpl, etc) to agree on a
> collaborative protocol with a simple api: check for one special
> '_in_event_loop' flag in the main toolkit before making one. That
> will make it easier to have interactive code that uses Wx or Qt from
> more than one library coexisting in the same process.
Fernando,
There are two parts to guisupport: ensure a single main app, and ensure 
no more than one call to the mainloop. The first makes perfect sense, 
and cannot cause any problems that I can see. The second one is the one 
that I think may be both unnecessary and undesirable. The reason is 
that the gui toolkit mainloop functions or methods are designed for 
nested calls. This permits blocking within a running mainloop, and 
allows show() to block when pyplot is not in interactive mode. This is 
what is lost with the guisupport mods. Some changes to mainloop logic 
may well be needed, but I don't think that prohibiting nested calls to 
the underlying toolkit mainloop function is necessary or desirable.
Eric
>
> I'll let Brian fill in with more details when he has some
> availability, but I think that's the gist of it.
>
> Regards,
>
> f

Hi Eric,
On Tue, Sep 7, 2010 at 1:31 PM, Eric Firing <ef...@ha...> wrote:
>
> I have been doing a little testing with ipython 0.10 versus
> ipython-newkernel, both modes, and with mpl svn versus your guisupport.
> There are so many possible modes of operation and combinations of
> versions and backends that all this will take some time to sort out.
>
> Can you give me simple examples of what does *not* work correctly when
> you use mpl *svn* with ipython-newkernel, in either or both of the
> console or gui modes, but *does* work with your guisupport version?
Thanks for your testing, Eric.
With matplotlib *alone*, I can't find a way to crash/lock/whatever the
combo of matplotlib(svn)+ipython-newkernel.
The reason, i believe, is that guisupport.py is available in ipython
itself, and it goes out of its way to avoid creating a second main qt
app, letting matplotlib create it. Since that main app is alive all
the time, there's only one app and one event loop and life is good.
But if I were to open another library that uses Qt and makes a new
main qApp unconditionally, we'd have problems.
Brian and Evan have recently just added the guisupport.py patch to
Enthought's ETS, so that now it probably will be pretty hard to
actually see the problem: if both ipython and ets go out of their way
to avoid the nested main app issue, mpl can get away with making one
unconditionally and things will probably work OK.
But the idea is for all of us (ipython, ets, mpl, etc) to agree on a
collaborative protocol with a simple api: check for one special
'_in_event_loop' flag in the main toolkit before making one. That
will make it easier to have interactive code that uses Wx or Qt from
more than one library coexisting in the same process.
I'll let Brian fill in with more details when he has some
availability, but I think that's the gist of it.
Regards,
f

On 09/03/2010 12:37 PM, Brian Granger wrote:
> Hello all,
>
> I would like to submit the following branch on github for review and
> merging into matplotlib trunk:
>
> http://github.com/ellisonbg/matplotlib/commits/guisupport
>
> This branch implements the logic needed for the qt4 and wx backends to
> fully work with the upcoming IPython 0.11 release. In our testing we
> have run many of the mpl examples (including the new animation
> examples) in both qt4/wx in both the terminal based IPython and the
> new IPython Qt GUI. For background on these changes please see this
> thread:
>
> http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTik2SNtXMaezCc0UiMnCYg6LxwEL1eN9YASnmOua%40mail.gmail.com&forum_name=matplotlib-devel
>
> It is important to note that we have not updated the other matplotlib
> backends (gtk, tk, etc.) to have this logic. This is mainly because
> we know almost nothing about these toolkits and could really use some
> help from folks who are experts at the respective toolkits. We have
> done some minimal testing and these other backends do work for simple
> examples in the terminal IPython, but they won't work in all cases and
> will definitely not work in the new IPython Qt based GUI.
>
> We would love feedback and help testing as these changes are
> significant (even though only a few lines of code). To test this
> stuff you will need to grab the following IPython development branch:
>
> http://github.com/ipython/ipython/tree/newkernel
>
> You should be able to run the examples in regular ipython:
>
> ipython --pylab qt4|wx
>
> Or the new GUI
>
> ipythonqt --pylab qt4|wx
Brian, Fernando,
I have been doing a little testing with ipython 0.10 versus 
ipython-newkernel, both modes, and with mpl svn versus your guisupport. 
There are so many possible modes of operation and combinations of 
versions and backends that all this will take some time to sort out.
Can you give me simple examples of what does *not* work correctly when 
you use mpl *svn* with ipython-newkernel, in either or both of the 
console or gui modes, but *does* work with your guisupport version?
Thanks.
Eric
>
> Cheers,
>
> Brian
>

On Tue, Sep 7, 2010 at 10:09 AM, John Porter <jp...@ca...> wrote:
> I was checking the performance of the GtkAgg and Qt4Agg backends and noticed
> that the Qt4Agg backend calls canvas.draw 3 times for every pylab.show()
> The three calls are:
> backend_qt4.py::65
>  manager.window.show()->resizeEvent->draw
> backend_qt4.py::71
> figManager.canvas.draw()
> backend_qtagg4.py::69
>  FigureCanvasQTAgg.paintEvent -> FigureCanvasAgg.draw(self)
> show() in backend_qt4.py includes the extra call to figManager.canvas.draw
> compared to the gtk backend. It doesn't seem to be necessary.
> There is a 'replot' flag in the canvas.draw function in FigureCanvasQTAgg
> which looks as though it should be True in order to prevent the extra draw
> in paintEvent.
What mpl version are you using?

I was checking the performance of the GtkAgg and Qt4Agg backends and noticed
that the Qt4Agg backend calls canvas.draw 3 times for every pylab.show()
The three calls are:
backend_qt4.py::65
 manager.window.show()->resizeEvent->draw
backend_qt4.py::71
 figManager.canvas.draw()
backend_qtagg4.py::69
 FigureCanvasQTAgg.paintEvent -> FigureCanvasAgg.draw(self)
show() in backend_qt4.py includes the extra call to figManager.canvas.draw
compared to the gtk backend. It doesn't seem to be necessary.
There is a 'replot' flag in the canvas.draw function in FigureCanvasQTAgg
which looks as though it should be True in order to prevent the extra draw
in paintEvent.
John

Hello,
I'm the author of DreamPie - a new graphical Python shell (
http://dreampie.sourceforge.net ).
I worked to make it work nicely with matplotlib, but I would like to
make it work even better.
Currently, if you import matplotlib in DreamPie and it is in
non-interactive mode, DreamPie suggests that you switch to interactive
mode. After you do that, everything works fine, because I made
DreamPie support handling events of Tkinter, GTK and QT when it's
idle.
I thought that it might be even nicer if DreamPie would automatically
switch matplotlib to interactive mode when it's detected, instead of
asking the user to find the right configuration file and edit it.
I asked people at matplotlib-users for their opinion, and Eric Firing
said that non-interactive mode is useful when running matplotlib
scripts.
I looked at http://matplotlib.sourceforge.net/users/shell.html and saw
that ipython's pylab mode provides a run command that runs a script in
non-interactive mode.
I wonder: could such a function be added to the pylab module? Then I
think it would be fine if DreamPie automatically switched to
interactive mode. (I can write this function if you like)
Do you have any other suggestions on how to make DreamPie more
matplotlib-friendly? Do you think that after these changes DreamPie
can be recommended as a matplotlib-friendly shell?
Thanks,
Noam

Hi folks,
I've just implemented support in ipython for simultaneous use of the
interactive mpl gui backends along with inlined figures, as I had
suggested to Eric things could work.
But I'm seeing two little glitches, illustrated here:
http://fperez.org/tmp/mpl_svg_bug.png
The white console on the right is IPython, the mpl window was my only
open figure.
The code I ran was:
x=rand(1000)
plot (x) # this pops up the normal gui, I tested Qt4Agg and GTKAgg
paste() # this pasted the open figure into the IPython console.
At this point, the plot in the window got that funny size, with the
x-labels double-drawn. It seems as if the figure got re-drawn over
the previous canvas, at a different size. If I resize the window, the
problem goes away, but if I don't resize it, it persists through new
plot/draw operations.
The second problem... I then zoomed the interactive window and issued
paste again, getting the plot in the bottom right of the figure:
paste()
And here the bug seems to be related to clipping: while the window
clips OK, the SVG seems not to.
Is this a fundamental limitation of the SVG backend?
For IPython we can also switch to pngs if that turns out to work
better, but I figured I'd report these...
All this was done with current mpl from trunk.
Cheers,
f

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