matplotlib-devel Mailing List for matplotlib

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...