Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI
Hi Jeff, On Mon, Sep 6, 2010 at 6:27 AM, Jeff Whitaker 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... -- 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, 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 -- 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
On Wed, Sep 8, 2010 at 12:12 AM, Fernando Perez 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI
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 wrote: > On Wed, Sep 8, 2010 at 12:12 AM, Fernando Perez 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 > 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] [Matplotlib-users] bug? line misses points with negative coordinates
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:
>>>
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
>> 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
>
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
--
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.
Re: [matplotlib-devel] Unblock matplotlib sourceforge?
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... ;) Mike -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA -- 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] Unblock matplotlib sourceforge?
Eric Firing 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 -- 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
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 -- 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] Unblock matplotlib sourceforge?
On Wed, Sep 8, 2010 at 12:57 PM, Jouni K. Seppänen 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 -- 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
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 -- 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
On Thu, Sep 9, 2010 at 9:38 AM, Eric Firing wrote: > Fixed in 8693. > Thanks! -JJ -- 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
On Thu, Sep 9, 2010 at 4:13 AM, Eric Firing 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 -- 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
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 -- 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
On Wed, Sep 8, 2010 at 8:06 PM, Eric Firing wrote: > 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 > I agree that Axes3D should not add itself to the Figure object anymore. The original implementation made sense, but now, it is merely legacy cruft that will need to be eliminated appropriately over time. There are probably a few minor issues I have before moving forward with a complete deprecation of the old method of creating a 3d axes (namely the subplot margins might be too big), but I will leave that to another thread. Thanks for the patches! 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
