Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI
Hi Jeff, On Mon, Sep 6, 2010 at 6:27 AM, Jeff Whitaker jsw...@fastmail.fm 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 fperez@gmail.com 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 n...@pobox.com wrote: On Wed, Sep 8, 2010 at 12:12 AM, Fernando Perez fperez@gmail.com 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 Yutsy...@gmail.com:
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=detailaid=3058804group_id=80706atid=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.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Unblock matplotlib sourceforge?
Eric Firing efir...@... 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] Unblock matplotlib sourceforge?
On Wed, Sep 8, 2010 at 12:57 PM, Jouni K. Seppänen j...@iki.fi 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 efir...@hawaii.edu 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 efir...@hawaii.edu 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 efir...@hawaii.edu 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
