Re: [matplotlib-devel] 1.2.0 Final tagged and uploaded
On Thu, Nov 8, 2012 at 7:18 PM, Damon McDougall wrote: >> IIRC matplotlib is currently third in the list of libraries most wanted >> by users waiting for Python3 compatibility. I'd guess that many >> scientific users are aware of this wonderful milestone, but to spread >> the news at a minimum I'd put this on the main Python mailing list and > > +1 for this I'm giving the closing keynote at PyCon Canada today, can I announce 1.2.0 offiical with py3 support then? It would be a fitting tribute to John and the amazing work you have all put in moving the project forward! f -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Python-modules-team] Bug#608932: python-matplotlib-doc: "Exception occurred rendering plot"
Hi all, On Mon, Jan 17, 2011 at 11:45 PM, Sandro Tosi wrote: > On Tue, Jan 4, 2011 at 19:11, Jakub Wilk wrote: >> Package: python-matplotlib-doc >> Version: 0.99.3-1 >> Severity: minor >> >> There are several "Exception occurred rendering plot" warnings in the >> generated documentation: >> >> $ cd /usr/share/doc/python-matplotlib-doc/html/ && grep -r 'Exception >> occurred' . I'm not exactly sure how this has fixed itself, but now the above command returns nothing (on 1.2.0 -doc package): $ cd /usr/share/doc/python-matplotlib-doc/html/ && grep -r 'Exception occurred' . $ Hence closing this report. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.2.0 Final tagged and uploaded
On Sunday, November 11, 2012, Fernando Perez wrote: > On Thu, Nov 8, 2012 at 7:18 PM, Damon McDougall > > wrote: > >> IIRC matplotlib is currently third in the list of libraries most wanted > >> by users waiting for Python3 compatibility. I'd guess that many > >> scientific users are aware of this wonderful milestone, but to spread > >> the news at a minimum I'd put this on the main Python mailing list and > > > > +1 for this > > I'm giving the closing keynote at PyCon Canada today, can I announce > 1.2.0 offiical with py3 support then? It would be a fitting tribute > to John and the amazing work you have all put in moving the project > forward! > > f Don't see why not. Thanks for the advertising! Ben Root -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.2.0 Final tagged and uploaded
On Thu, Nov 8, 2012 at 6:18 PM, Michael Droettboom wrote: > Thanks again to everyone for all of their hard work. This release has > been tagged and uploaded. 1.2.0 Debian packages has just landed in Debian experimental! Cheers :) -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.2.0 Final tagged and uploaded
On Sun, Nov 11, 2012 at 11:47 AM, Benjamin Root wrote: > Don't see why not. Thanks for the advertising! OK, so it will be! Thanks again for everyone who made this possible! f -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.2.0 Final tagged and uploaded
On Sun, Nov 11, 2012 at 12:19 PM, Fernando Perez wrote: > On Sun, Nov 11, 2012 at 11:47 AM, Benjamin Root wrote: >> Don't see why not. Thanks for the advertising! > > OK, so it will be! Thanks again for everyone who made this possible! > > f Yeah that's a great idea. Get the word out. -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [PATCH] gtkagg backend leaks gc's.
On Thursday, November 8, 2012, Carl Michal wrote:
> Hello,
>
> I noticed that a program I had that uses canvas.blit() to do animated
> graphs
> with the gtkagg backend was leaking memory.
>
> I tracked this down to gtk gc's being allocated in agg_to_gtk_drawable with
> gdk_gc_new(), but never being destroyed.
>
> The leak can be seen using the 'Animating selected plot elements' example
> from:
>
> http://www.scipy.org/Cookbook/Matplotlib/Animations
>
> (if it is modified to run forever, rather than just 50 plots and also
> changing numerix to numpy). After a few minutes, it is clear from ps that
> the
> memory usage is slowly but steadily climbing.
>
> Patch below (against matplotlib-1.1.1.) fixes it.
>
> Carl
>
> --- _gtkagg.cpp~2012-06-30 12:37:00.0 -0700
> +++ _gtkagg.cpp 2012-11-08 14:30:23.0 -0800
> @@ -121,6 +121,7 @@
> destbuffer,
> deststride);
>
> + gdk_gc_destroy(gc);
> if (needfree)
> {
> delete [] destbuffer;
>
>
>
>
If you are willing, would you like to file a PR against the v1.2.x branch?
Ben Root
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New plot type idea -- EventRaster
On Thu, Sep 27, 2012 at 8:18 PM, Todd wrote: > On Thu, Sep 27, 2012 at 1:44 PM, Todd wrote: >> On Thu, Sep 27, 2012 at 1:12 PM, Damon McDougall >> wrote: >>> Hi Todd, >>> >>> Firstly, thanks for taking the time to crystallise your thoughts in >>> words first. This is one of my bad habits; I tend to rush into things. >>> >>> I have some feedback for you, hopefully we can all work together to >>> get this right. It's difficult when something new gets implemented and >>> someone expects it to do something and the only way to resolve it is >>> to break the calling API. >> >> Where is API broken? >> >>> Anyway, I hope you'll find my comments >>> helpful at the least. I also encourage others to weigh in with >>> opinions and ideas. >> >> Okay, I will discuss the rationale. I will snip out anything you >> agree on for brevity. >> Assuming we go with the name, here is my proposed call signature: EventRaster(x, offset=0, height=1, **kargs) >>> >>> CamelCase is discouraged for method names. Perhaps 'eventraster'? >> >> Fair enough. >> >>> Also, we could also let **kwargs swallow the 'offset' and 'height' >>> keyword arguments. Then the user isn't constrained by which order to >>> put them in. The downside of this approach is that introspection is >>> more difficult. >> >> I don't understand the advantage of this approach. If you use keyword >> arguments, then the order doesn't matter. So with the approach above >> you can use keyword arguments, in which case you can use whatever >> order they want, or you can use positional arguments. On the other >> hand putting it in **kwargs, we lose the ability to use positional >> arguments. So we lose nothing by allowing both positional and keyword >> arguments. It is also easier to implement. >> offset determines the positions of the rows. By default, the first row is placed with the line center y=0, and subsequent rows are placed with the line centers at increasing 1-unit increments. If offset is defined and is a scalar, the first row is placed at the offset, and subsequent rows are placed at increasing 1-unit increments. If offset is an array, it must be a 1D array of the same length as the second dimension of x. In this case each element in offset determines the center of the corresponding row in the plot. >>> >>> How about letting offset be either: a) a scalar, determining the >>> offset of all rows equally; or b) an array, determining the offset of >>> each row individually. >> >> Because people are almost never going to want to have all the lines >> stacked right on top of each other. The plot would be indecipherable >> that way. The defaults are chosen to handle the most common use-cases >> most easily. >> >>> In fact, why plot each row at integer y >>> coordinates? Could we allow for an optional y-coordinate array, each >>> element of which would be the y-coordinate at which to plot a row of >>> lines. Then you wouldn't need offset. >> >> That is exactly what offset does if you pass an array. >> If this is going to be used to implement rug plots, it would need some way to handle columns of horizontal lines in addition to rows of vertical lines. I see two ways to implement this. First is to have to plot types, perhaps HEventRaster and VEventRaster. The first would be as described above, while the second would be similar but everything rotated 90 degrees. Another possibility is to change the call signature to this: EventRaster(x, y=None, offset=0, height=1, **kargs) >>> >>> I think accepting an 'orientation' kwarg, which can take either >>> 'horizontal' or 'vertical', determining the orientation of the lines >>> and reversing the roles of the x and y arrays. >> >> That would work as well. Probably cleaner that way >> The function will return a list of a new collection type I am tentatively calling EventCollection. My thinking would be this would be a subclass of a new collection type called GenericLineCollection, which the current LineCollection would also subclass. They would share things like the color handling and segment handling, however the segment handling will be a "private" method that LineCollection will have a public wrapper for. On the other hand methods to set or add segments will remain private in EventCollection, although there will be a method to return the segments if an artist really wants to manipulate individual segments. >>> >>> Why can't we just use LineCollection? I don't see a good reason to >>> create a new collection class here; the plot is simple. >> >> Explained below. >> The reason for doing it this way is that manipulating individual rows of events should be very common, such as changing their position, color, marker, width, and so on. On the other hand manipulating lines individually should not be as common, although still supported. >>> >>> Fair en
