matplotlib-devel Mailing List for matplotlib (Page 4)

On Feb 8, 2015 1:13 AM, "Thomas Caswell" <tca...@gm...> wrote:
>
> Hey all,
>
> To start with, the 2.0 release is pending a choice of new default color
map. I think that when we pick that we should cut 2.0 off of the last
release and then the next minor release turns into 2.1. If we want to do
other breaking changes we will just do a 3.0 when that happens. It makes
sense to me to bundle default color changes as one set of breaking changes
and code API changes as another.
I thought there was going to be a complete overhaul of the default theme?
Has that idea been abandoned?
> - making OO interface easier to use interactively (if interactive,
auto-redraw at sensible time)
>
> - pull the pyplot state machine out of backend_bases and expose the
figure_manager classes
Do either of these mean that it will be possible to use the OO interface
without needing to go through pyplot?

Ah, no I mean the exact opposite!
My proposal is to cut 2.0 off of what ever the current stable release is
(ex, 1.4.3) and then merge that into master. The next minor release would
then be 2.1 and there would be no new 1.Y releases.
Tom
On Sun Feb 08 2015 at 2:04:24 PM Sandro Tosi <mo...@de...> wrote:
> Hi all!
>
> On Sun, Feb 8, 2015 at 12:13 AM, Thomas Caswell <tca...@gm...>
> wrote:
> > Hey all,
> >
> > To start with, the 2.0 release is pending a choice of new default color
> map.
> > I think that when we pick that we should cut 2.0 off of the last release
> and
> > then the next minor release turns into 2.1. If we want to do other
> breaking
> > changes we will just do a 3.0 when that happens. It makes sense to me to
> > bundle default color changes as one set of breaking changes and code API
> > changes as another.
> >
> > Eric made the case in an issue that we should not continue the 1.4.x
> series
> > and start working 1.5.0, which fits well with aiming for a 6month
> scheduled
> > release cycle (minor release in July, bug-fix release in February).
>
> Do I understand correctly you plan to maintain 2 separate development
> lines (like Python with 2.x and 3.x) as 1.5.x and 2.x ?
>
> Cheers,
> --
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
>

Hi all!
On Sun, Feb 8, 2015 at 12:13 AM, Thomas Caswell <tca...@gm...> wrote:
> Hey all,
>
> To start with, the 2.0 release is pending a choice of new default color map.
> I think that when we pick that we should cut 2.0 off of the last release and
> then the next minor release turns into 2.1. If we want to do other breaking
> changes we will just do a 3.0 when that happens. It makes sense to me to
> bundle default color changes as one set of breaking changes and code API
> changes as another.
>
> Eric made the case in an issue that we should not continue the 1.4.x series
> and start working 1.5.0, which fits well with aiming for a 6month scheduled
> release cycle (minor release in July, bug-fix release in February).
Do I understand correctly you plan to maintain 2 separate development
lines (like Python with 2.x and 3.x) as 1.5.x and 2.x ?
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Sat, Feb 7, 2015 at 9:46 PM, Thomas Caswell <tca...@gm...> wrote:
> Well, creating the tarball on GH is a lot easier for us as it happens
> automatically! I don't want to unilaterally change policy so I will create
> the files on SF.
>
> If you want to tracking GH for debian instead of SF I don't think that would
> be a bad idea, but I don't know how much of a hassle that would be for you.
Aaah dont worry about changing things :) I can reroute the tools to
track GH no problem, what I need to know if that's the place where the
next tarballs will be released; if so, I will update the tracking
straight away.
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

I am getting some test failures here and on master in the collections
module.
======================================================================
FAIL: __main__.test_regularpolycollection_rotate.test
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/home/ben/miniconda/lib/python2.7/site-packages/nose/case.py", line
197, in runTest
 self.test(*self.arg)
 File
"/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
line 51, in failer
 result = f(*args, **kwargs)
 File
"/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
line 196, in do_test
 '(RMS %(rms).3f)'%err)
ImageComparisonFailure: images not close:
/home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_rotate.png
vs.
/home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_rotate-expected.png
(RMS 54.618)
======================================================================
FAIL: __main__.test_regularpolycollection_scale.test
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/home/ben/miniconda/lib/python2.7/site-packages/nose/case.py", line
197, in runTest
 self.test(*self.arg)
 File
"/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
line 51, in failer
 result = f(*args, **kwargs)
 File
"/home/ben/.local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py",
line 196, in do_test
 '(RMS %(rms).3f)'%err)
ImageComparisonFailure: images not close:
/home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_scale.png
vs.
/home/ben/Programs/matplotlib/result_images/test_collections/regularpolycollection_scale-expected.png
(RMS 120.828)
----------------------------------------------------------------------
Ran 54 tests in 15.149s
FAILED (failures=2)
The squares in the first test are larger than they should be. I have some
other errors, but they seem to other be floating point errors, or issues
with fonts.
Ben Root
On Sat, Feb 7, 2015 at 4:46 PM, Thomas Caswell <tca...@gm...> wrote:
> Sandro,
>
> Well, creating the tarball on GH is a lot easier for us as it happens
> automatically! I don't want to unilaterally change policy so I will create
> the files on SF.
>
> If you want to tracking GH for debian instead of SF I don't think that
> would be a bad idea, but I don't know how much of a hassle that would be
> for you.
>
> Tom
>
> On Sat Feb 07 2015 at 4:14:36 PM Sandro Tosi <mo...@de...> wrote:
>
>> On Sat, Feb 7, 2015 at 9:05 PM, Thomas Caswell <tca...@gm...>
>> wrote:
>> > Sandro,
>> >
>> > Can you use the tarball from github
>> > (https://github.com/matplotlib/matplotlib/archive/v1.4.3rc1.tar.gz ?)
>>
>> Sure I can, but since all the previous release (even RC) were done one
>> SF, we have our tools to monitor and download new releases pointing to
>> SF: do you plan to switch to GH for releasing tarballs too?
>>
>> Cheers,
>> --
>> Sandro Tosi (aka morph, morpheus, matrixhasu)
>> My website: http://matrixhasu.altervista.org/
>> Me at Debian: http://wiki.debian.org/SandroTosi
>>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Looking at collections.py, it looks like TriMesh might also benefit from
this, as it has specialized code for masking out triangles and determining
the order of the triangle elements.
Ben Root
On Sat, Feb 7, 2015 at 7:18 PM, Benjamin Root <ben...@ou...> wrote:
> Digging through mplot3d (again), I have come to realize that a lot of its
> code in art3d.py could be simplified if we had a way to tell collection
> objects in what order to draw their elements.
>
> My proposal is fairly straight-forward. All collections would have an
> internal _zdraworder attribute that can be anything that can index a numpy
> array: slice(), array of indices, whatever. The draw() methods will then
> iterate over their elements returned by indexing with _zdraworder. This
> will help keep the bookkeeping to a minimum, because everything should be
> sliced/indexed the same way: offsets, verts, facecolors, etc.
>
> The default value will be slice(None), so nothing will change for regular
> collections.
>
> With this, mplot3d can greatly simplify its logic and semantics by
> focusing on projecting and setting the _zdraworder by running np.argsort()
> on the projected depth of the elements. Another advantage is that methods
> like get_facecolors() and set_facecolors() can round-trip in mplot3d (right
> now, get_facecolors() has to return a z-sorted version of the colors for
> drawing).
>
> For now, I imagine keeping this a private attribute, but I could see some
> really fancy tricks in the future such as using boolean indexing to mark
> some elements as visible/invisible, and doing some neat tricks for
> animations.
>
> Thoughts?
> Ben Root
>

Digging through mplot3d (again), I have come to realize that a lot of its
code in art3d.py could be simplified if we had a way to tell collection
objects in what order to draw their elements.
My proposal is fairly straight-forward. All collections would have an
internal _zdraworder attribute that can be anything that can index a numpy
array: slice(), array of indices, whatever. The draw() methods will then
iterate over their elements returned by indexing with _zdraworder. This
will help keep the bookkeeping to a minimum, because everything should be
sliced/indexed the same way: offsets, verts, facecolors, etc.
The default value will be slice(None), so nothing will change for regular
collections.
With this, mplot3d can greatly simplify its logic and semantics by focusing
on projecting and setting the _zdraworder by running np.argsort() on the
projected depth of the elements. Another advantage is that methods like
get_facecolors() and set_facecolors() can round-trip in mplot3d (right now,
get_facecolors() has to return a z-sorted version of the colors for
drawing).
For now, I imagine keeping this a private attribute, but I could see some
really fancy tricks in the future such as using boolean indexing to mark
some elements as visible/invisible, and doing some neat tricks for
animations.
Thoughts?
Ben Root

Hey all,
To start with, the 2.0 release is pending a choice of new default color
map. I think that when we pick that we should cut 2.0 off of the last
release and then the next minor release turns into 2.1. If we want to do
other breaking changes we will just do a 3.0 when that happens. It makes
sense to me to bundle default color changes as one set of breaking changes
and code API changes as another.
Eric made the case in an issue that we should not continue the 1.4.x series
and start working 1.5.0, which fits well with aiming for a 6month scheduled
release cycle (minor release in July, bug-fix release in February).
To this end, I have clean out and close the 1.4.x milestone (most of issues
just got moved 1.5.0) and created a 1.5.0 milestone. I set a target for
1.5.0 to be released at scipy as that seems like a reasonable thing to.
Targeting just after SciPy also makes sense so we have a clear list of
things to work on at the sprints. Thoughts?
My internal list of what we should try to get in for 1.5.0 are:
 - visitor pattern on all artists + recreating figure from it's visited
artists. This gets us a) proper serialization of our figures instead of
going through pickles and b) makes interoperability with plotly/b3/bokeh
easier
 - pyplot overhaul (use decorators, provide decorators as part of public
API)
 - navigation by events (PR #3652 + MEP22)
 - making OO interface easier to use interactively (if interactive,
auto-redraw at sensible time)
 - pull the pyplot state machine out of backend_bases and expose the
figure_manager classes
 - overhaul the website
Anything else people think should be on the list or any protests to this
list?
Tom

Sandro,
Well, creating the tarball on GH is a lot easier for us as it happens
automatically! I don't want to unilaterally change policy so I will create
the files on SF.
If you want to tracking GH for debian instead of SF I don't think that
would be a bad idea, but I don't know how much of a hassle that would be
for you.
Tom
On Sat Feb 07 2015 at 4:14:36 PM Sandro Tosi <mo...@de...> wrote:
> On Sat, Feb 7, 2015 at 9:05 PM, Thomas Caswell <tca...@gm...> wrote:
> > Sandro,
> >
> > Can you use the tarball from github
> > (https://github.com/matplotlib/matplotlib/archive/v1.4.3rc1.tar.gz ?)
>
> Sure I can, but since all the previous release (even RC) were done one
> SF, we have our tools to monitor and download new releases pointing to
> SF: do you plan to switch to GH for releasing tarballs too?
>
> Cheers,
> --
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
>

On Sat, Feb 7, 2015 at 9:05 PM, Thomas Caswell <tca...@gm...> wrote:
> Sandro,
>
> Can you use the tarball from github
> (https://github.com/matplotlib/matplotlib/archive/v1.4.3rc1.tar.gz ?)
Sure I can, but since all the previous release (even RC) were done one
SF, we have our tools to monitor and download new releases pointing to
SF: do you plan to switch to GH for releasing tarballs too?
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Sandro,
Can you use the tarball from github (
https://github.com/matplotlib/matplotlib/archive/v1.4.3rc1.tar.gz ?)
Tom
On Sat Feb 07 2015 at 4:01:01 PM Sandro Tosi <mo...@de...> wrote:
> Hi Thomas,
>
> On Mon, Feb 2, 2015 at 5:37 AM, Thomas Caswell <tca...@gm...> wrote:
> > Evening all,
> >
> > I have tagged the first release candidate for v1.4.3
> > (https://github.com/matplotlib/matplotlib/releases/tag/v1.4.3rc1).
> ...
> > Please kick the tires and give it a try! If there are no major issues,
> the
> > plan is to target 1.4.3 for next weekend.
>
> could you also release a tarball on SF, so I can start updating the
> debian package and give it a spin on our distro?
>
> Cheers,
> --
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
>

Hi Thomas,
On Mon, Feb 2, 2015 at 5:37 AM, Thomas Caswell <tca...@gm...> wrote:
> Evening all,
>
> I have tagged the first release candidate for v1.4.3
> (https://github.com/matplotlib/matplotlib/releases/tag/v1.4.3rc1).
...
> Please kick the tires and give it a try! If there are no major issues, the
> plan is to target 1.4.3 for next weekend.
could you also release a tarball on SF, so I can start updating the
debian package and give it a spin on our distro?
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Thanks for the great work!
On 02 Feb 2015, at 11:58 am, Jens Nielsen <jen...@gm...> wrote:
> I ran the test suite on OSX 10.10 with both python 2.7.8 and 3.4.2 including the tex and QT4 tests that are skipped on Travis. 
> Everything passes as expected.
> 
I’ve tested on OS X 10.9 with Fink Python 3.4.2, 3.3.6, 2.7.9
Ran 4778 tests in 540.937s
OK (KNOWNFAIL=9, SKIP=1)
OK (KNOWNFAIL=8, SKIP=1)
One error with python2.7:
FAILED (KNOWNFAIL=9, SKIP=1, errors=1)
ERROR: matplotlib.tests.test_style.test_use_url
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/sw/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
 self.test(*self.arg)
 File "/scratch.noindex/fink.build/matplotlib-py27-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.9-x86_64-2.7/matplotlib/tests/test_style.py", line 58, in test_use_url
 with style.context('https://gist.github.com/adrn/6590261/raw'):
 File "/sw/lib/python2.7/contextlib.py", line 17, in __enter__
 return self.gen.next()
 File "/scratch.noindex/fink.build/matplotlib-py27-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.9-x86_64-2.7/matplotlib/style/core.py", line 86, in context
 use(name)
 File "/scratch.noindex/fink.build/matplotlib-py27-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.9-x86_64-2.7/matplotlib/style/core.py", line 66, in use
 raise ValueError(msg % style)
ValueError: 'https://gist.github.com/adrn/6590261/raw' not found in the style library and input is not a valid URL or path. See `style.available` for list of available styles.
On 10.10 there are a number of additional errors (I’ve checked the save_animation
errors are not due to permission problems):
ERROR: matplotlib.tests.test_animation.test_save_animation_smoketest('ffmpeg', 'mp4')
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/sw/lib/python3.4/site-packages/nose/case.py", line 198, in runTest
 self.test(*self.arg)
 File "/scratch.noindex/fink.build/matplotlib-py34-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.10-x86_64-3.4/matplotlib/testing/decorators.py", line 110, in wrapped_function
 func(*args, **kwargs)
 File "/scratch.noindex/fink.build/matplotlib-py34-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.10-x86_64-3.4/matplotlib/tests/test_animation.py", line 57, in check_save_animation
 anim.save(F.name, fps=30, writer=writer, bitrate=500)
 File "/scratch.noindex/fink.build/matplotlib-py34-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.10-x86_64-3.4/matplotlib/animation.py", line 767, in save
 writer.grab_frame(**savefig_kwargs)
 File "/scratch.noindex/fink.build/matplotlib-py34-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.10-x86_64-3.4/matplotlib/animation.py", line 222, in grab_frame
 dpi=self.dpi, **savefig_kwargs)
 File "/scratch.noindex/fink.build/matplotlib-py34-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.10-x86_64-3.4/matplotlib/figure.py", line 1476, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File "/scratch.noindex/fink.build/matplotlib-py34-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.10-x86_64-3.4/matplotlib/backend_bases.py", line 2211, in print_figure
 **kwargs)
 File "/scratch.noindex/fink.build/matplotlib-py34-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.10-x86_64-3.4/matplotlib/backends/backend_agg.py", line 513, in print_raw
 renderer._renderer.write_rgba(filename_or_obj)
RuntimeError: Error writing to file
======================================================================
ERROR: matplotlib.tests.test_animation.test_save_animation_smoketest('ffmpeg_file', 'mp4')
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/sw/lib/python3.4/site-packages/nose/case.py", line 198, in runTest
 self.test(*self.arg)
 File "/scratch.noindex/fink.build/matplotlib-py34-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.10-x86_64-3.4/matplotlib/testing/decorators.py", line 110, in wrapped_function
 func(*args, **kwargs)
 File "/scratch.noindex/fink.build/matplotlib-py34-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.10-x86_64-3.4/matplotlib/tests/test_animation.py", line 57, in check_save_animation
 anim.save(F.name, fps=30, writer=writer, bitrate=500)
 File "/scratch.noindex/fink.build/matplotlib-py34-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.10-x86_64-3.4/matplotlib/animation.py", line 767, in save
 writer.grab_frame(**savefig_kwargs)
 File "/sw/lib/python3.4/contextlib.py", line 66, in __exit__
 next(self.gen)
 File "/scratch.noindex/fink.build/matplotlib-py34-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.10-x86_64-3.4/matplotlib/animation.py", line 188, in saving
 self.finish()
 File "/scratch.noindex/fink.build/matplotlib-py34-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.10-x86_64-3.4/matplotlib/animation.py", line 378, in finish
 + ' Try running with --verbose-debug')
RuntimeError: Error creating movie, return code: -5 Try running with --verbose-debug
----------------------------------------------------------------------
Ran 4778 tests in 357.541s
FAILED (KNOWNFAIL=385, SKIP=1, errors=2)
Same with python2.7, plus the same test_use_url error as on 10.9 and these 4 additional ones
(none of them necessarily only appeared with 1.4.3, the package had not been updated since 1.3.1):
======================================================================
ERROR: Failure: AttributeError ('module' object has no attribute 'test_backend_qt4')
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/sw/lib/python2.7/site-packages/nose/loader.py", line 403, in loadTestsFromName
 module = resolve_name(addr.module)
 File "/sw/lib/python2.7/site-packages/nose/util.py", line 321, in resolve_name
 obj = getattr(obj, part)
AttributeError: 'module' object has no attribute 'test_backend_qt4'
======================================================================
ERROR: Failure: AttributeError ('module' object has no attribute 'test_dates')
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/sw/lib/python2.7/site-packages/nose/loader.py", line 403, in loadTestsFromName
 module = resolve_name(addr.module)
 File "/sw/lib/python2.7/site-packages/nose/util.py", line 321, in resolve_name
 obj = getattr(obj, part)
AttributeError: 'module' object has no attribute 'test_dates'
======================================================================
ERROR: Failure: AttributeError ('module' object has no attribute 'test_legend')
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/sw/lib/python2.7/site-packages/nose/loader.py", line 403, in loadTestsFromName
 module = resolve_name(addr.module)
 File "/sw/lib/python2.7/site-packages/nose/util.py", line 321, in resolve_name
 obj = getattr(obj, part)
AttributeError: 'module' object has no attribute 'test_legend'
======================================================================
ERROR: Failure: AttributeError ('module' object has no attribute 'test_patheffects')
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/sw/lib/python2.7/site-packages/nose/loader.py", line 403, in loadTestsFromName
 module = resolve_name(addr.module)
 File "/sw/lib/python2.7/site-packages/nose/util.py", line 321, in resolve_name
 obj = getattr(obj, part)
AttributeError: 'module' object has no attribute 'test_patheffects'
----------------------------------------------------------------------
Ran 4705 tests in 310.629s
FAILED (KNOWNFAIL=372, SKIP=1, errors=7)
Cheers,
					Derek

Awesome work! Full credit to Tom who has driven this release.
The nbagg backend is looking great - some pretty swish new features thanks
to hard work from Steven Silvester and Thomas Caswell!
On 2 February 2015 at 10:58, Jens Nielsen <jen...@gm...> wrote:
> Thanks Tom,
>
> I ran the test suite on OSX 10.10 with both python 2.7.8 and 3.4.2
> including the tex and QT4 tests that are skipped on Travis.
> Everything passes as expected.
>
> Jens
>
> Mon Feb 02 2015 at 5:38:32 AM skrev Thomas Caswell <tca...@gm...>:
>
> Evening all,
>>
>> I have tagged the first release candidate for v1.4.3 (https://github.com/
>> matplotlib/matplotlib/releases/tag/v1.4.3rc1).
>>
>> Although this is a bug-fix release, a fair amount of work has gone into
>> making the nbagg (interactive figures in ipython notebooks) feature
>> complete compared to the other interactive backends.
>>
>> Please kick the tires and give it a try! If there are no major issues,
>> the plan is to target 1.4.3 for next weekend.
>>
>> The mac build has been started and (if I understand how these things
>> work) should be available to install via
>> pip install -f http://wheels.scikit-image.org --pre matplotlib soon.
>>
>> For linux anaconda users, packages for 2.6/2.7 python on my binstar
>> channel (conda install -c https://conda.binstar.org/tacaswell
>> matplotlib). The py3k builds have some issue with invalid syntax in pyqt4,
>> if some knows how to build these, please let me know.
>>
>>
>> Tom
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is
>> your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

May be of interest:
http://www.nature.com/news/programming-pick-up-python-1.16833
We get mention down towards the bottom.
Tom

Hi,
On Mon, Feb 2, 2015 at 2:58 AM, Jens Nielsen <jen...@gm...> wrote:
> Thanks Tom,
>
> I ran the test suite on OSX 10.10 with both python 2.7.8 and 3.4.2 including
> the tex and QT4 tests that are skipped on Travis.
> Everything passes as expected.
I built wheels for OSX testing, via the automated travis builders [1].
Install with:
pip install -f http://wheels.scipy.org -U --pre matplotlib
Scipy ecosystem tests (numpy, scipy, pandas, etc) running against the
rc1 wheel at [2].
Cheers,
Matthew
[1] https://travis-ci.org/MacPython/matplotlib-wheels
[2] https://travis-ci.org/MacPython/scipy-stack-osx-testing

Thanks Tom,
I ran the test suite on OSX 10.10 with both python 2.7.8 and 3.4.2
including the tex and QT4 tests that are skipped on Travis.
Everything passes as expected.
Jens
Mon Feb 02 2015 at 5:38:32 AM skrev Thomas Caswell <tca...@gm...>:
Evening all,
>
> I have tagged the first release candidate for v1.4.3 (https://github.com/
> matplotlib/matplotlib/releases/tag/v1.4.3rc1).
>
> Although this is a bug-fix release, a fair amount of work has gone into
> making the nbagg (interactive figures in ipython notebooks) feature
> complete compared to the other interactive backends.
>
> Please kick the tires and give it a try! If there are no major issues,
> the plan is to target 1.4.3 for next weekend.
>
> The mac build has been started and (if I understand how these things work)
> should be available to install via
> pip install -f http://wheels.scikit-image.org --pre matplotlib soon.
>
> For linux anaconda users, packages for 2.6/2.7 python on my binstar
> channel (conda install -c https://conda.binstar.org/tacaswell
> matplotlib). The py3k builds have some issue with invalid syntax in pyqt4,
> if some knows how to build these, please let me know.
>
>
> Tom
>
>
> ------------------------------------------------------------
> ------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Evening all,
I have tagged the first release candidate for v1.4.3 (
https://github.com/matplotlib/matplotlib/releases/tag/v1.4.3rc1).
Although this is a bug-fix release, a fair amount of work has gone into
making the nbagg (interactive figures in ipython notebooks) feature
complete compared to the other interactive backends.
Please kick the tires and give it a try! If there are no major issues, the
plan is to target 1.4.3 for next weekend.
The mac build has been started and (if I understand how these things work)
should be available to install via
pip install -f http://wheels.scikit-image.org --pre matplotlib soon.
For linux anaconda users, packages for 2.6/2.7 python on my binstar
channel (conda install -c https://conda.binstar.org/tacaswell matplotlib).
The py3k builds have some issue with invalid syntax in pyqt4, if some knows
how to build these, please let me know.
Tom