matplotlib-devel Mailing List for matplotlib

There was some discussion about CocoaAgg in a bug report today that 
reminded me it's probably time to clean up our backend house again, so 
I've filed a meta-issue and milestoned it for 1.3.x.
https://github.com/matplotlib/matplotlib/issues/1961
Mike

Hans,
If you submit it as a Pull Request, we can comment in-line with the code.
For the most part, things look fine except for some whitespace errors.
Ben Root
On Wed, Apr 17, 2013 at 9:29 AM, Hans Dembinski <han...@ki...>wrote:
> Hi all,
>
> I have written a patch in order to set the length of cap lines in
> errorbar plots via rcParams. I would like to see this feature in the
> master branch.
>
> Please review my code
>
> https://github.com/HDembinski/matplotlib/compare/capsize-default
>
> Regards,
> Hans
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi all,
I have written a patch in order to set the length of cap lines in 
errorbar plots via rcParams. I would like to see this feature in the 
master branch.
Please review my code
https://github.com/HDembinski/matplotlib/compare/capsize-default
Regards,
Hans

Hi,
Le 16/04/2013 15:41, Detlef Maurel (IKP) a écrit :
> this works for me, too. Strange... I get the problem with the attached
> dataset using the command
>
> hist(loadtxt("data.txt"),bins=300,histtype="step") 
Indeed, I could reproduce your problem using your specific dataset.
The automated selection of ylim is not working as expected, and I don't
know why !
best,
Pierre

Hi Michiel,
On 16.04.2013, at 12:03AM, Michiel de Hoon <mjl...@ya...> wrote:
> Can you perhaps ask the Fink developers to provide a framework installation of Python? Most matplotlib users who ran into framework-related bugs were Fink users.
I've already looked for that in the list archives and it seems this topic comes up about once a
year when some other package broke with the non-framework build. Changing the build does
not seem a particular problem, but was always declined as it would mean all (or a large number)
of the other Python-dependent packages would have to be fixed at the same time.
But I can of course bring this up for discussion again pointing out that the macosx backend support
is going to be discontinued.
Cheers,
						Derek

On 16.04.2013 14:58, Pierre Haessig wrote:
> Hi,
>
> Le 16/04/2013 12:14, Detlef Maurel (IKP) a écrit :
>> there seems to be a bug in in pyplot.hist when using histtype="step".
>>
>> I am plotting the attached data to a histogram (see 1.png). In this
>> case I set the limits on the y axis manually.
>>
>> When I don't do this (let the hist function choose the limits), I get
>> the picture in the file 2.png. Only the highest bin is drawn. To be
>> exact, ymin=second highest value, ymax=highest value.
> Can you also send a minimal code that reproduces the bug. I just tried a
> hist(x, histtype='step') command, with x being a random vector and it
> works fine.
>
this works for me, too. Strange... I get the problem with the attached 
dataset using the command
hist(loadtxt("data.txt"),bins=300,histtype="step")
When I plot only a subset of the data (first/second/third/... thousand 
numbers),
the histogram looks fine. It seems it gets wrong when more than roughly 
2000 numbers are used.
I will try to dig more into this and let you know if I find something.
cheers
Detlef

Hi,
Le 16/04/2013 12:14, Detlef Maurel (IKP) a écrit :
> there seems to be a bug in in pyplot.hist when using histtype="step".
>
> I am plotting the attached data to a histogram (see 1.png). In this
> case I set the limits on the y axis manually.
>
> When I don't do this (let the hist function choose the limits), I get
> the picture in the file 2.png. Only the highest bin is drawn. To be
> exact, ymin=second highest value, ymax=highest value. 
Can you also send a minimal code that reproduces the bug. I just tried a
hist(x, histtype='step') command, with x being a random vector and it
works fine.
best,
Pierre

Hi all,
there seems to be a bug in in pyplot.hist when using histtype="step".
I am plotting the attached data to a histogram (see 1.png). In this case 
I set the limits on the y axis manually.
When I don't do this (let the hist function choose the limits), I get 
the picture in the file 2.png. Only the highest bin is drawn. To be 
exact, ymin=second highest value, ymax=highest value.
To solve this, I suggest the patch in the attachment.
I also removed the for loop here, because I don't see why 0 height bins 
should be filtered out (but this is just a suggestion).
cheers,
Detlef Maurel

Hi Derek,
Can you perhaps ask the Fink developers to provide a framework installation of Python? Most matplotlib users who ran into framework-related bugs were Fink users.
Best,
-Michiel.
--- On Mon, 4/15/13, Derek Homeier <de...@as...> wrote:
> From: Derek Homeier <de...@as...>
> Subject: Re: [matplotlib-devel] Planning for 1.3.0
> To: "matplotlib development list" <mat...@li...>
> Date: Monday, April 15, 2013, 11:00 AM
> Hi Michiel,
> 
> On 15.04.2013, at 6:03AM, Michiel de Hoon <mjl...@ya...>
> wrote:
> 
> > --- On Sun, 4/14/13, Derek Homeier <de...@as...>
> wrote:
> >> Of course if there are any other possible negative
> effects
> >> besides the window handling, I'd take your point.
> > 
> > Several bugs have been reported in the past that turned
> out to be due to Python not being installed as a framework.
> For example, the file selection window when saving a figure
> doesn't respond. This has been a major hassle, since each of
> those bug reports take time to investigate before realizing
> that it is due to the Python installation.
> 
> OK, that is a valid reason! I vaguely remember some problems
> with that in the past,
> though haven't experienced any of that in a long time (just
> tested 'Save File', and I've
> been regularly using 'Configure Subplots'). But this is
> probably a case where a
> Warning might not keep all users from filing a bug. :-(
> The QT4Agg backend has its ups as well, though there still
> seem to be some quirks,
> too (e.g. the zoom rectangle only shows up with the left and
> lower border); I will probably
> become a fan of the line configuration tool that allows you
> to switch back to linear from a
> log axis scale (in the command line there seems to be no
> return from plt.semilogy() or
> plt.loglog())!
> 
> Cheers,
>      
>      
> Derek
> 
> 
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of
> advanced
> analytics on semi-structured data. The platform includes
> APIs for building
> apps and a phenomenal toolset for data science. Developers
> can use
> our toolset for easy data analysis & visualization. Get
> a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Hi Mike, Ryan,
Thanks for your comments. I have made a pull request; see:
https://github.com/matplotlib/matplotlib/pull/1907
Best,
-Michiel
--- On Mon, 4/15/13, Michael Droettboom <md...@st...> wrote:
> From: Michael Droettboom <md...@st...>
> Subject: Re: [matplotlib-devel] Timers independent of canvases
> To: mat...@li...
> Date: Monday, April 15, 2013, 10:56 AM
> Thanks for doing this. This
> looks like quite an improvement!
> 
> Why don't you go ahead and make a pull request. I
> think on the whole 
> the idea is sound, I just have a few minor comments that can
> probably be 
> dealt with more efficiently in a PR.
> 
> Mike
> 
> On 04/12/2013 10:32 PM, Michiel de Hoon wrote:
> > Dear all,
> >
> > The animation code in matplotlib relies on timers to
> update the animated figures. Currently a new timer is
> created by calling new_timer on a canvas, as in
> >
> >>>> f = pylab.figure()
> >>>> timer = f.canvas.new_timer()
> > This seems a bit of a wrinkle. For example, you may
> want to associate a timer with multiple figures, or with no
> figure at all; also you may want to continue using a timer
> after a particular figure is closed.
> >
> > I would therefore propose to make timers independent of
> canvases. Something like this:
> >
> >>>> from matplotlib import events
> >>>> timer = events.Timer()
> > This has the additional advantage of making the
> different backends more similar to each other; in the
> current implementation some backends rely on the canvas when
> making a timer, while others ignore it.
> >
> > I have made a branch on github that does exactly this;
> see
> > https://github.com/mdehoon/matplotlib/tree/Timer
> > I have verified that the animation examples still work
> correctly with all backends.
> >
> > Any comments/suggestions/criticisms? If this seems a
> good idea, I can make a pull request.
> >
> > Best,
> > -Michiel.
> >
> >
> ------------------------------------------------------------------------------
> > Precog is a next-generation analytics platform capable
> of advanced
> > analytics on semi-structured data. The platform
> includes APIs for building
> > apps and a phenomenal toolset for data science.
> Developers can use
> > our toolset for easy data analysis & visualization.
> Get a free account!
> > http://www2.precog.com/precogplatform/slashdotnewsletter
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of
> advanced
> analytics on semi-structured data. The platform includes
> APIs for building
> apps and a phenomenal toolset for data science. Developers
> can use
> our toolset for easy data analysis & visualization. Get
> a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Hi Michiel,
On 15.04.2013, at 6:03AM, Michiel de Hoon <mjl...@ya...> wrote:
> --- On Sun, 4/14/13, Derek Homeier <de...@as...> wrote:
>> Of course if there are any other possible negative effects
>> besides the window handling, I'd take your point.
> 
> Several bugs have been reported in the past that turned out to be due to Python not being installed as a framework. For example, the file selection window when saving a figure doesn't respond. This has been a major hassle, since each of those bug reports take time to investigate before realizing that it is due to the Python installation.
OK, that is a valid reason! I vaguely remember some problems with that in the past,
though haven't experienced any of that in a long time (just tested 'Save File', and I've
been regularly using 'Configure Subplots'). But this is probably a case where a
Warning might not keep all users from filing a bug. :-(
The QT4Agg backend has its ups as well, though there still seem to be some quirks,
too (e.g. the zoom rectangle only shows up with the left and lower border); I will probably
become a fan of the line configuration tool that allows you to switch back to linear from a
log axis scale (in the command line there seems to be no return from plt.semilogy() or
plt.loglog())!
Cheers,
						Derek

Thanks for doing this. This looks like quite an improvement!
Why don't you go ahead and make a pull request. I think on the whole 
the idea is sound, I just have a few minor comments that can probably be 
dealt with more efficiently in a PR.
Mike
On 04/12/2013 10:32 PM, Michiel de Hoon wrote:
> Dear all,
>
> The animation code in matplotlib relies on timers to update the animated figures. Currently a new timer is created by calling new_timer on a canvas, as in
>
>>>> f = pylab.figure()
>>>> timer = f.canvas.new_timer()
> This seems a bit of a wrinkle. For example, you may want to associate a timer with multiple figures, or with no figure at all; also you may want to continue using a timer after a particular figure is closed.
>
> I would therefore propose to make timers independent of canvases. Something like this:
>
>>>> from matplotlib import events
>>>> timer = events.Timer()
> This has the additional advantage of making the different backends more similar to each other; in the current implementation some backends rely on the canvas when making a timer, while others ignore it.
>
> I have made a branch on github that does exactly this; see
> https://github.com/mdehoon/matplotlib/tree/Timer
> I have verified that the animation examples still work correctly with all backends.
>
> Any comments/suggestions/criticisms? If this seems a good idea, I can make a pull request.
>
> Best,
> -Michiel.
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

No opposition here. The "rationale" behind the original location was:
1) Easy way to make it properly dependent on the backend
2) Easy way to get a handle on a widget when necessary (for Tk and Wx IIRC)
However, these were reasons of ease of implementation (aka. laziness) on my
part, no real technical reasons that I recall (clearly, since your branch
works).
So, +1.
Ryan
On Fri, Apr 12, 2013 at 9:32 PM, Michiel de Hoon <mjl...@ya...>wrote:
> Dear all,
>
> The animation code in matplotlib relies on timers to update the animated
> figures. Currently a new timer is created by calling new_timer on a canvas,
> as in
>
> >>> f = pylab.figure()
> >>> timer = f.canvas.new_timer()
>
> This seems a bit of a wrinkle. For example, you may want to associate a
> timer with multiple figures, or with no figure at all; also you may want to
> continue using a timer after a particular figure is closed.
>
> I would therefore propose to make timers independent of canvases.
> Something like this:
>
> >>> from matplotlib import events
> >>> timer = events.Timer()
>
> This has the additional advantage of making the different backends more
> similar to each other; in the current implementation some backends rely on
> the canvas when making a timer, while others ignore it.
>
> I have made a branch on github that does exactly this; see
> https://github.com/mdehoon/matplotlib/tree/Timer
> I have verified that the animation examples still work correctly with all
> backends.
>
> Any comments/suggestions/criticisms? If this seems a good idea, I can make
> a pull request.
>
> Best,
> -Michiel.
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi Derek,
--- On Sun, 4/14/13, Derek Homeier <de...@as...> wrote:
> Of course if there are any other possible negative effects
> besides the window handling, I'd take your point.
Several bugs have been reported in the past that turned out to be due to Python not being installed as a framework. For example, the file selection window when saving a figure doesn't respond. This has been a major hassle, since each of those bug reports take time to investigate before realizing that it is due to the Python installation.
Best,
-Michiel.

Hi Michiel,
> This RuntimeError is there for a reason: If your Python is not installed as a framework, the backend will not work correctly (and if you ignore the RuntimeError, you won't know if any problems you encounter are real bugs, or simply due to your Python not being installed as a framework).
I have used the MacOSX backend ever since I started working with Python,
and there only was a warning for the last 3 years or so. Other than my plot
windows evading the control of Exposé/Application switcher I have never
noticed any problems with this. Thus my request in my initial post to leave it
as a mere warning, since I'd think people can switch on their own decision
if they do not like the interaction (or lack thereof) with the window manager.
Otherwise I would have to grudgingly switch to another backend (seems now
that I could live with QT4Agg-Quartz or the like though), since installation as
as framework is not an option with Fink.
Of course if there are any other possible negative effects besides the window
handling, I'd take your point.
Best,
						Derek

Hi Derek,
--- On Sun, 4/14/13, Derek Homeier <de...@as...> wrote:
> The RuntimeError was enforced by the #ifdef
> WITH_NEXT_FRAMEWORK check that
> does not allow to use the backend at all, so I had to change
> this to a RuntimeWarning
> to be able to test the backend in the 1.3 branch.
This RuntimeError is there for a reason: If your Python is not installed as a framework, the backend will not work correctly (and if you ignore the RuntimeError, you won't know if any problems you encounter are real bugs, or simply due to your Python not being installed as a framework).
Best,
-Michiel

Hi Michiel,
> That is good to hear.
> The slowdown was caused by the performance of Quartz itself, but it depends strongly on the line width. In your example, the plot appears immediately if you use linewidth=0.9, but (with matplotlib 1.2.1) takes minutes to appear if you use linewidth=1.0. The change in set_dpi caused the line width actually used for drawing to increase slightly. The increase was very small, but big enough to trigger the ultraslow behavior of Quartz. As I mentioned, we solved this by breaking up the path into many subpaths, which solved the problem (without having to change set_dpi back).
> Anyway, if I understand your mail correctly, the problem has been fixed in HEAD. Is the 1.3 branch also OK now? In your first post you mentioned that there was some RuntimeError.
I saw a couple of warnings with Friday's checkout on 10.8, but the current one seems to
work fine (now on 10.7 however...). I've run the full test suite and only had three failures
in test_font_styles (basically all created fonts look like 'light'/'condensed').
The same with python3.2 after I upgraded pyparsing, only at the end of 'setup.py install'
there was an additional error, but this did not seem to affect the install (appended below).
The RuntimeError was enforced by the #ifdef WITH_NEXT_FRAMEWORK check that
does not allow to use the backend at all, so I had to change this to a RuntimeWarning
to be able to test the backend in the 1.3 branch.
Cheers,
					Derek
--
Processing matplotlib-1.3.x-py3.2-macosx-10.7-x86_64.egg
creating /Users/derek/lib/python3.2/site-packages/matplotlib-1.3.x-py3.2-macosx-10.7-x86_64.egg
Extracting matplotlib-1.3.x-py3.2-macosx-10.7-x86_64.egg to /Users/derek/lib/python3.2/site-packages
Adding matplotlib 1.3.x to easy-install.pth file
Installed /Users/derek/lib/python3.2/site-packages/matplotlib-1.3.x-py3.2-macosx-10.7-x86_64.egg
Processing dependencies for matplotlib==1.3.x
Traceback (most recent call last):
 File "setup.py", line 228, in <module>
 'KnownFailure = matplotlib.testing.noseclasses:KnownFailure'
 File "/sw/lib/python3.2/distutils/core.py", line 148, in setup
 dist.run_commands()
 File "/sw/lib/python3.2/distutils/dist.py", line 917, in run_commands
 self.run_command(cmd)
 File "/sw/lib/python3.2/distutils/dist.py", line 936, in run_command
 cmd_obj.run()
 File "/sw/lib/python3.2/site-packages/setuptools/command/install.py", line 73, in run
 self.do_egg_install()
 File "/sw/lib/python3.2/site-packages/setuptools/command/install.py", line 101, in do_egg_install
 cmd.run()
 File "/sw/lib/python3.2/site-packages/setuptools/command/easy_install.py", line 358, in run
 self.easy_install(spec, not self.no_deps)
 File "/sw/lib/python3.2/site-packages/setuptools/command/easy_install.py", line 582, in easy_install
 return self.install_item(None, spec, tmpdir, deps, True)
 File "/sw/lib/python3.2/site-packages/setuptools/command/easy_install.py", line 634, in install_item
 self.process_distribution(spec, dist, deps)
 File "/sw/lib/python3.2/site-packages/setuptools/command/easy_install.py", line 686, in process_distribution
 [requirement], self.local_index, self.easy_install
 File "/sw/lib/python3.2/site-packages/pkg_resources.py", line 586, in resolve
 dist = best[req.key] = env.best_match(req, self, installer)
 File "/sw/lib/python3.2/site-packages/pkg_resources.py", line 829, in best_match
 for dist in self[req.key]:
 File "/sw/lib/python3.2/site-packages/pkg_resources.py", line 799, in __getitem__
 _sort_dists(dists)
 File "/sw/lib/python3.2/site-packages/pkg_resources.py", line 2613, in _sort_dists
 tmp.sort()
TypeError: unorderable types: NoneType() < str()

Hi Derek,
That is good to hear.
The slowdown was caused by the performance of Quartz itself, but it depends strongly on the line width. In your example, the plot appears immediately if you use linewidth=0.9, but (with matplotlib 1.2.1) takes minutes to appear if you use linewidth=1.0. The change in set_dpi caused the line width actually used for drawing to increase slightly. The increase was very small, but big enough to trigger the ultraslow behavior of Quartz. As I mentioned, we solved this by breaking up the path into many subpaths, which solved the problem (without having to change set_dpi back).
Anyway, if I understand your mail correctly, the problem has been fixed in HEAD. Is the 1.3 branch also OK now? In your first post you mentioned that there was some RuntimeError.
Best,
-Michiel.
--- On Sat, 4/13/13, Derek Homeier <de...@as...> wrote:
> From: Derek Homeier <de...@as...>
> Subject: Re: [matplotlib-devel] Planning for 1.3.0
> To: "matplotlib development list" <mat...@li...>
> Date: Saturday, April 13, 2013, 9:03 AM
> Hi Michiel,
> 
> On 13.04.2013, at 1:30AM, Michiel de Hoon wrote:
> 
> > The slow speed for long paths like the one in your
> example was due to a limitation to Quartz itself. This was
> solved by breaking the path up into subpaths of up to 100
> points. But you mentioned that releases before 1.2 were not
> slow (and I verified this with matplotlib 1.1.1), suggesting
> that something else is going on. Can you check which change
> between 1.1.1 and 1.2 is causing the slowdown for your
> example?
> 
> It's the passing of set_dpi (commit 6533674) - that's still
> unchanged in master,
> but I don't see any speed penalty compared to 1.1.1 any
> more. I don't know if
> the change you mentioned above completely fixed this or just
> made up for it
> by speeding it up otherwise...
> I have just merged all updates to backend_maxosx.py and
> _macosx.m back
> into 1.2.1, and this seems to solve the issue and passes all
> tests as well.
> 
> Cheers,
>      
>     Derek
> 
> 
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of
> advanced
> analytics on semi-structured data. The platform includes
> APIs for building
> apps and a phenomenal toolset for data science. Developers
> can use
> our toolset for easy data analysis & visualization. Get
> a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Hi Michiel,
On 13.04.2013, at 1:30AM, Michiel de Hoon wrote:
> The slow speed for long paths like the one in your example was due to a limitation to Quartz itself. This was solved by breaking the path up into subpaths of up to 100 points. But you mentioned that releases before 1.2 were not slow (and I verified this with matplotlib 1.1.1), suggesting that something else is going on. Can you check which change between 1.1.1 and 1.2 is causing the slowdown for your example?
It's the passing of set_dpi (commit 6533674) - that's still unchanged in master,
but I don't see any speed penalty compared to 1.1.1 any more. I don't know if
the change you mentioned above completely fixed this or just made up for it
by speeding it up otherwise...
I have just merged all updates to backend_maxosx.py and _macosx.m back
into 1.2.1, and this seems to solve the issue and passes all tests as well.
Cheers,
					Derek

Dear all,
The animation code in matplotlib relies on timers to update the animated figures. Currently a new timer is created by calling new_timer on a canvas, as in
>>> f = pylab.figure()
>>> timer = f.canvas.new_timer()
This seems a bit of a wrinkle. For example, you may want to associate a timer with multiple figures, or with no figure at all; also you may want to continue using a timer after a particular figure is closed.
I would therefore propose to make timers independent of canvases. Something like this:
>>> from matplotlib import events
>>> timer = events.Timer()
This has the additional advantage of making the different backends more similar to each other; in the current implementation some backends rely on the canvas when making a timer, while others ignore it.
I have made a branch on github that does exactly this; see
https://github.com/mdehoon/matplotlib/tree/Timer
I have verified that the animation examples still work correctly with all backends.
Any comments/suggestions/criticisms? If this seems a good idea, I can make a pull request.
Best,
-Michiel.

http://blogs.hbr.org/cs/2013/04/the_science_of_what_we_do_and_dont_know_about_data_visualization.html

Hi Derek,
The slow speed for long paths like the one in your example was due to a limitation to Quartz itself. This was solved by breaking the path up into subpaths of up to 100 points. But you mentioned that releases before 1.2 were not slow (and I verified this with matplotlib 1.1.1), suggesting that something else is going on. Can you check which change between 1.1.1 and 1.2 is causing the slowdown for your example?
Best,
-Michiel.
--- On Fri, 4/12/13, Derek Homeier <de...@as...> wrote:
> From: Derek Homeier <de...@as...>
> Subject: Re: [matplotlib-devel] Planning for 1.3.0
> To: "mat...@li... list" <mat...@li...>
> Date: Friday, April 12, 2013, 5:16 PM
> On 11.04.2013, at 6:38PM, Michael
> Droettboom <md...@st...>
> wrote:
> 
> > Congrats to everyone on a successful 1.2.1 -- there was
> a relatively 
> > small influx of bug reports following it -- perhaps a
> sign of improving 
> > quality?
> 
> Thanks and congratulations to everyone involved as well;
> I've built 1.2.1 on MacOS X with fink for 
> Python2.6-3.2 without any failures in the test suite!
> I did run into a problem though that has actually existed
> since the first 1.2 release - with the MacOSX
> backend line plots of somewhat larger arrays with
> significant "high-frequency" power had extremely
> degraded, e.g. something like
> 
> x = np.linspace(0,10,1.e6)
> y =
> np.cos(x)+0.2*np.sin(x*3.e3)+0.1*np.cos(x*4.e4)*np.random.rand(1.e6)
> plt.plot(x, y)
> 
> would display within less than 2 seconds with 1.1.1, but
> with 1.2.x you literally have to wait minutes,
> and it takes similarly long to zoom in as long as you have a
> substantial part of the line in the window.
> 
> I found in the current HEAD (9e477b3) this has finally been
> fixed - thanks for that as well, whatever
> the problem was, but now in the 1.3 branch the _macosx
> backend has been altogether disabled!
> I verified after removing that RuntimeError from _macosx.m
> that the backend still works and is indeed
> up to its old speed; but if that change stays in, it won't
> be usable from non-framework Python installs
> like the fink ones. 
> Personally, I am aware of the problems with the missing
> window manager control, and occasionally
> am annoyed by hunting for a plot window that has sneaked
> somewhere underneath other windows,
> but with that in mind I still prefer the MacOSX backend to
> any of the others, and I would suggest to
> leave it at a warning rather than an error, so users can
> still decide for themselves if they want to put
> up with the possible troubles.
> 
> Cheers,
>      
>      
>   Derek
> 
> 
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of
> advanced
> analytics on semi-structured data. The platform includes
> APIs for building
> apps and a phenomenal toolset for data science. Developers
> can use
> our toolset for easy data analysis & visualization. Get
> a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

On 11.04.2013, at 6:38PM, Michael Droettboom <md...@st...> wrote:
> Congrats to everyone on a successful 1.2.1 -- there was a relatively 
> small influx of bug reports following it -- perhaps a sign of improving 
> quality?
Thanks and congratulations to everyone involved as well; I've built 1.2.1 on MacOS X with fink for 
Python2.6-3.2 without any failures in the test suite!
I did run into a problem though that has actually existed since the first 1.2 release - with the MacOSX
backend line plots of somewhat larger arrays with significant "high-frequency" power had extremely
degraded, e.g. something like
x = np.linspace(0,10,1.e6)
y = np.cos(x)+0.2*np.sin(x*3.e3)+0.1*np.cos(x*4.e4)*np.random.rand(1.e6)
plt.plot(x, y)
would display within less than 2 seconds with 1.1.1, but with 1.2.x you literally have to wait minutes,
and it takes similarly long to zoom in as long as you have a substantial part of the line in the window.
I found in the current HEAD (9e477b3) this has finally been fixed - thanks for that as well, whatever
the problem was, but now in the 1.3 branch the _macosx backend has been altogether disabled!
I verified after removing that RuntimeError from _macosx.m that the backend still works and is indeed
up to its old speed; but if that change stays in, it won't be usable from non-framework Python installs
like the fink ones. 
Personally, I am aware of the problems with the missing window manager control, and occasionally
am annoyed by hunting for a plot window that has sneaked somewhere underneath other windows,
but with that in mind I still prefer the MacOSX backend to any of the others, and I would suggest to
leave it at a warning rather than an error, so users can still decide for themselves if they want to put
up with the possible troubles.
Cheers,
							Derek

Great news! A lot of fantastic work has been done by a whole host of people
to go into this release. It's exciting stuff!
May 27th sounds like a sensible target to me. As you know, I'm an advocate
of releasing often - the more frequently we make a release, the less we
will have the "impending release rush" that can really hamper the whole
release process.
Cheers,
On 11 April 2013 17:38, Michael Droettboom <md...@st...> wrote:
> Congrats to everyone on a successful 1.2.1 -- there was a relatively
> small influx of bug reports following it -- perhaps a sign of improving
> quality?
>
> In any event, as Phil Elson likes to repeatedly point out (<wink>), we
> have a great deal of awesome new features in master that it would be
> great to get out. As for time frame, I think if we aim for a 1.3.0rc1
> of May 27, that's within a good time frame to get something out in time
> for Scipy. That will put us about 8 months past 1.2.0, which is not far
> off from my eventual goal of 6 month releases once things get
> streamlined. We can, of course, adjust the date as necessary as we go
> along.
>
> So... let the bug triaging begin! As there are lot of new features in
> the queue, I think it's important to distinguish the "nice to have" from
> the "must have". I've created a new milestone "1.3.x blocker" that we
> should use for critical bugs that should hold up the release. All other
> new features that are looking close to ready for 1.3.x should be
> milestoned 1.3.x, and as we get closer, we can punt those on to 1.4.x.
> Simple bugs that apply to 1.2.x as well as master should be milestoned
> as "1.2.x" and merged onto the "v1.2.x" branch (as we've been doing), as
> I still think we should reserve the right to make another 1.2.2 bugfix
> release if necessary.
>
> There are a couple major ongoing projects that I think we'll need to get
> to a steady interim state before we can make another release.
>
> MEP10: Documentation
>
> We already have a number of improved docstrings, and better
> organization throughout. I don't think we need to finish all of this
> work before the next release, but we should get it back into shape so
> that the doc build has fewer warnings (#1896) and the LaTeX build works
> again (#1836).
>
> MEP12: Reorganize and cleanup examples
>
> Again, I think a lot of great work has already been done, and we
> don't necessarily have to wait until it's done.
>
> For both of the above, it would be nice to divide the work up so the
> leaders of those projects are less individually burdened. Nelle and
> Tony, if you know of any critical blockers or loose ends that should be
> tied up before a release should be made, please make issues for them and
> milestone them as "1.3.x blocker".
>
> Cheers,
> Mike
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Congrats to everyone on a successful 1.2.1 -- there was a relatively 
small influx of bug reports following it -- perhaps a sign of improving 
quality?
In any event, as Phil Elson likes to repeatedly point out (<wink>), we 
have a great deal of awesome new features in master that it would be 
great to get out. As for time frame, I think if we aim for a 1.3.0rc1 
of May 27, that's within a good time frame to get something out in time 
for Scipy. That will put us about 8 months past 1.2.0, which is not far 
off from my eventual goal of 6 month releases once things get 
streamlined. We can, of course, adjust the date as necessary as we go 
along.
So... let the bug triaging begin! As there are lot of new features in 
the queue, I think it's important to distinguish the "nice to have" from 
the "must have". I've created a new milestone "1.3.x blocker" that we 
should use for critical bugs that should hold up the release. All other 
new features that are looking close to ready for 1.3.x should be 
milestoned 1.3.x, and as we get closer, we can punt those on to 1.4.x. 
Simple bugs that apply to 1.2.x as well as master should be milestoned 
as "1.2.x" and merged onto the "v1.2.x" branch (as we've been doing), as 
I still think we should reserve the right to make another 1.2.2 bugfix 
release if necessary.
There are a couple major ongoing projects that I think we'll need to get 
to a steady interim state before we can make another release.
 MEP10: Documentation
 We already have a number of improved docstrings, and better 
organization throughout. I don't think we need to finish all of this 
work before the next release, but we should get it back into shape so 
that the doc build has fewer warnings (#1896) and the LaTeX build works 
again (#1836).
 MEP12: Reorganize and cleanup examples
 Again, I think a lot of great work has already been done, and we 
don't necessarily have to wait until it's done.
For both of the above, it would be nice to divide the work up so the 
leaders of those projects are less individually burdened. Nelle and 
Tony, if you know of any critical blockers or loose ends that should be 
tied up before a release should be made, please make issues for them and 
milestone them as "1.3.x blocker".
Cheers,
Mike