matplotlib-devel Mailing List for matplotlib (Page 2)

I would like some feedback on a new feature I have developed to control the
length of colorbar extension triangles. This is a feature I have desired
for some time, so that the plots I produce with matplotlib can be more
consistent with those produced from other popular plotting software (e.g.,
IDL). I have added a new keyword argument, extendfrac, to the ColorbarBase
class. This may be set to a scalar, a two-tuple, the string 'auto', or the
string 'default'. The behaviour of this keyword depends on the setting of
the existing spacing keyword argument.
For spacing='uniform' or spacing='proportional':
 extendfrac=None - sets the lengths of both the minimum and maximum
colorbar extension triangles to 0.05 times the interior colorbar length
(the existing hard-coded setting).
 extendfrac='default' - same as None.
 extendfrac=FRACTION - sets the lengths of both the minimum and maximum
colorbar extension triangles to the given fraction of the interior colorbar
length.
For spacing='uniform':
 extendfrac='auto' - sets the lengths of both the minimum and maximum
colorbar extension triangles to be the same as the length of the interior
boxes.
For spacing='proportional':
 extendfrac='auto' - sets the length of the minimum colorbar extension
triangle to the length of the left/bottom-most interior box, and the length
of the maximum colorbar extension triangle to the length of the
right/top-most interior box.
 extendfrac=(FRACTION1, FRACTION2) - as for FRACTION above but the
minimum and maximum extension triangles may be different lengths.
This is quite a small modification actually, but it does change the API for
colorbars. I am wondering if this could be included in matplotlib? I have
set up a fork of matplotlib on Github to implement this feature, if anyone
thinks it is worth it...
Andrew

Thanks. I spent about a day last week working on this as well -- I have 
a local branch for it. When I get the chance, I'll have a look at this 
and compare notes. Submitting a github pull request would be great if 
you're able.
Mike
On 11/15/2011 11:04 AM, jrj...@gm... wrote:
> Hi
>
> Is anyone working on a Gtk3 backend for matplotlib that use the pygobject API?
>
> I could not find any information about how to use the matplotlib with
> Gtk3, so I started to port the Gtk2 backend to the pygobject API, and
> using the cairo backend for renderering.
>
> I'm attaching a tarboll that contains the backend_gtk3.py file and
> some test scripts for embedding a matplotlib figure in Gtk3
> applications using that backend. I think it works alright for the use
> cases that I've been able to test, so it might be a good starting
> point for a Gtk3 backend if there are no other attempts to create such
> a backend already.
>
> Best regards
> Robert
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save 700ドル by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Hi
Is anyone working on a Gtk3 backend for matplotlib that use the pygobject API?
I could not find any information about how to use the matplotlib with
Gtk3, so I started to port the Gtk2 backend to the pygobject API, and
using the cairo backend for renderering.
I'm attaching a tarboll that contains the backend_gtk3.py file and
some test scripts for embedding a matplotlib figure in Gtk3
applications using that backend. I think it works alright for the use
cases that I've been able to test, so it might be a good starting
point for a Gtk3 backend if there are no other attempts to create such
a backend already.
Best regards
Robert

A question that was raised while diagnosing an issue with mpl_connect(). A
user wants to attach a function to multiple events. Apparently, this was
possible in previous versions, but the current version disallows that
through its use of the dictionary that is key'ed by the callback
functions. Do we want to explicitly disallow this, or should we be keying
the dictionary with (action, callback) tuples?
Ben Root

On Sat, Nov 12, 2011 at 6:56 AM, John Hunter <jd...@gm...> wrote:
>
>
> On Nov 12, 2011, at 2:47 AM, Paul Ivanov <piv...@gm...> wrote:
>
> > On Fri, Nov 11, 2011 at 5:40 PM, Benjamin Root <ben...@ou...> wrote:
> >> On Fri, Nov 11, 2011 at 7:19 PM, Benjamin Root <ben...@ou...> wrote:
> >>>
> >>> On Thu, Nov 10, 2011 at 5:52 PM, Paul Ivanov <piv...@gm...>
> wrote:
> >>>>
> >>>> Just wanted to re-ping the list, but include John and Ben directly:
> >>>>
> >>>> can we get the appropriate commit tagged as v1.1.0 in the git repo?
> >>>>
> >>>
> >>> Sure thing. I will add that tag.
> >>>
> >>> Ben Root
> >>>
> >>
> >> The best I can figure is that commit
> >> 0fc9830fe946f6221e9ceff2910cd0c2118b0965 was the last one before the
> release
> >> announcement by John on Oct. 11. There was subsequently a commit on
> that
> >> day to fix ipython links. I can't remember if that happened before or
> after
> >> (I think after).
> >>
> >> Can anybody concur?
> >
> > On my PR to fix those links, John closed it and said he'd add it to
> > the release branch, and they're up on the site, so I'd say that commit
> > made it in. But I don't know if there were others afterward that made
> > it in
> >
>
>
> My memory is that the ipy pull request came just after the tarball, so I
> think you have it right Ben
>
>
Done!
Ben Root

Hi Jeff,
On Mon, Sep 19, 2011 at 17:39, Jeff Whitaker
<Jef...@no...> wrote:
> On 9/18/11 8:49 AM, Sandro Tosi wrote:
>>
>> Hi,
>> when running
>>
>>   python setup.py clean
>>
>> nad2bin is compiled. I've just worked around with the attached patch,
>> so it would be nice if you can integrate it upstream or come up with a
>> better solution.
>>
>> Regards,
>
> Applied your patch to github master. Will be in 1.0.2, which I will release
> soon.
something happened in the middle, and the setup.py released with 1.0.2
still compile nad2bin in clean target; I've applied the following fix:
-if sys.argv[1] != ['sdist','clean']:
+if sys.argv[1] not in ['sdist','clean']:
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Hi Ondrej,
Good things last and take time.
2010年4月13日 Ondrej Certik <on...@ce...>:
> I am now getting the exact same problem with pylab and FEMhub and Mac.
> I used http://sagemath.org/packages/standard/matplotlib-0.99.1.p4.spkg:
It might a different problem than just architecture mismatch. But
maybe I'm getting something wrong and misunderstand you.
Michael, notice that 0.99.1 seems to the last version before your
commit af9954d46e5 which introduces versioning of the fontcache. (It
is not tagged in git, only the commit message reveals it:
8398d9bd2c47.
I cannot see from http://trac.sagemath.org/sage_trac/ticket/7022 what
happened between the sagemath matplotlib-0.99.1.p2.spkg to
matplotlib-0.99.1.p4.spkg (patch 2 => patch 4). But the last post by
jhpalmieri on that page might be related: "[...] But with my computer,
"uname -r" returns "10.2.0", not "10.0.0". [...]" On my system it
returns currently 10.8.0 (I think since it's OS X 10.6.8).
> ondrej@bsd:~/repos/femhub-0.9.9.beta3-mac(master)$ ./femhub
> ----------------------------------------------------------------------
> | FEMhub Version 0.9.9.beta2, Release Date: 2010年04月02日        |
> | Type lab() for the GUI.                      |
> ----------------------------------------------------------------------
> In [1]: import pylab
> /Users/ondrej/repos/femhub-0.9.9.beta3-mac/local/lib/python2.6/site-packages/matplotlib/rcsetup.py:117:
> UserWarning: rcParams key "numerix" is obsolete and has no effect;
> please delete it from your matplotlibrc file
> warnings.warn('rcParams key "numerix" is obsolete and has no effect;\n'
> /Users/ondrej/repos/femhub-0.9.9.beta3-mac/local/bin/sage-sage: line
> 203: 28516 Abort trap       sage-ipython "$@" -i
>
> It's using the "bsd" Mac machine from William, I guess the same as
> John was using above.
>
> Has anybody figured out a solution? Apparently Sage must work on the
> Mac, so it must be something different than just matplotlib?
Can you please check if you do have /Library/Fonts/NISC18030.ttf on
your system and maybe do a ``stat -f "%c"
/Library/Fonts/NISC18030.ttf`` on it? For me, this one generates a
Bus error (32bit) / Abort trap (64bit) on importing matplotlib.figure,
for example. My issue is related to loading that font file I
specified. It might a different font file for you and it might also
be totally unrelated at all :-/
Or maybe you solved the problem in the meantime?
Do you still have this machine? William, assumed he's William Stein,
was the one who posted
http://groups.google.com/group/sage-devel/browse_thread/thread/2c538915abc99946
in 2009, and who was able to partly track it down.
>From the page http://trac.sagemath.org/sage_trac/ticket/7022 I see
that exactly that font file was installed on it (probably).
Thanks,
Friedrich
> Some
> other package, that we have in femhub, but not in Sage, or some
> different version of something. Here is a list of packages that I have
> installed:
>
> ondrej@bsd:~/repos/femhub-0.9.9.beta3-mac(master)$ ./femhub -i
> Currently installed packages:
> blas-20070724
> bzip2-1.0.5
> cmake-2.6.2.p1
> configobj-4.5.3
> cython-0.12.1
> dir-0.1
> docutils-0.5.p0
> femhub-lab-97141eb
> fipy-2.1-eb4aacf
> fortran-20071120.p8
> freetype-2.3.5.p2
> gnutls-2.2.1.p3
> hermes2d-9bbfd39
> ipython-bzr1174
> jinja-1.2.p0
> judy-1.0.5.p1
> lapack-20071123.p1
> libfemhub-78c07cb
> libgcrypt-1.4.3.p2
> libgpg_error-1.6.p2
> libpng-1.2.35.p0
> matplotlib-0.99.1.p4
> mayavi-3.3.1.p2
> mesa-7.4.4.p3
> numpy-1.3.0.p2
> pexpect-2.0.p3
> prereq-0.3
> pygments-0.11.1.p0
> pyparsing-1.5.2
> pysparse-1.1-6301cea
> python-2.6.4.p7
> python_gnutls-1.1.4.p7
> readline-6.0
> sage_scripts-3.4.2
> scipy-0.7.p4
> setuptools-0.6c9.p0
> sfepy-2009.3
> sphinx-0.6.3.p4
> swig-1.3.36
> sympy-5d78c29
> termcap-1.3.1.p1
> twisted-9.0.p2
> vtk-cvs-20090316-minimal.p6
> zlib-1.2.3.p5
Looks ok. But I didn't check it in detail. I think it might be unrelated.

2010年12月21日 Russell E. Owen <ro...@uw...>:
> I built a binary installer for matplotlib trunk rev 8843 (because it
> leaks memory less than 1.0.0 release). I built it the same way I built
> the 1.0.0 binary
> <http://www.astro.washington.edu/users/rowen/BuildingMatplotlibForMac.htm
> l> on Mac OS X 10.4 using python.org Python 2.6.x (where x is probably
> 6).
>
> The binary is available here:
> <http://www.astro.washington.edu/users/rowen/python/matplotlib-1.0.0+svn8
> 843-python.org-py2.6-macosx10.3.dmg>
>
> It work fine on Mac OS X 10.4 and 10.5, but on 10.6 attempting to import
> pylab almost always segfaults (and the few times I've gotten it to work
> on 10.6 I can break it by deleting ~/.fontconfig and ~/.matplotlib and
> running Python again). I've tried it on newly created accounts and it
> segfaults. Another user of Snow Leopard first reported the problem. So
> it's not just me.
>
> I've appended part of a crash log.
>
> I built this binary the same way I built the matplotlib 1.0.0 binary,
> which has no problems.
>
> Any ideas?
Yap; did you make any progress on this?
I found that approximately that time on my machine was the
NISC18030.ttf font installed (I see it from the date of birth) and it
breaks the FontManager of nearly all matplotlibs including the recent
one (from last week).
Friedrich
> -- Russell
>
> Exception Type: EXC_BAD_ACCESS (SIGABRT)
> Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
> Crashed Thread: 0 Dispatch queue: com.apple.main-thread
>
> Application Specific Information:
> abort() called
>
> Thread 0 Crashed: Dispatch queue: com.apple.main-thread
> 0  libSystem.B.dylib        0x90e1b176 __kill + 10
> 1  libSystem.B.dylib        0x90e1b168 kill$UNIX2003 + 32
> 2  libSystem.B.dylib        0x90ead89d raise + 26
> 3  libSystem.B.dylib        0x90ec39bc abort + 93
> 4  org.python.python        0x004e3e99 Py_FatalError + 73
> 5  libSystem.B.dylib        0x90e2046b _sigtramp + 43
> 6  ???               0000000000 0 + 0
> 7  libSystem.B.dylib        0x90e29378
> _Unwind_GetLanguageSpecificData + 24
> 8  libstdc++.6.dylib        0x940c4d86 __gxx_personality_v0 + 120
> 9  libgcc_s.1.dylib        0x0389f476 _Unwind_Backtrace + 278
> 10 libgcc_s.1.dylib        0x0389f890 _Unwind_Resume + 112
> 11 ft2font.so           0x03d5c3a3
> FT2Font::FT2Font(std::string) + 4385
> 12 ft2font.so           0x03d5c805
> ft2font_module::new_ft2font(Py::Tuple const&) + 505
> 13 ft2font.so           0x03dc89c2
> Py::ExtensionModule<ft2font_module>::invoke_method_varargs(void*,
> Py::Tuple const&) + 90
> 14 ft2font.so           0x03d7170c
> method_varargs_call_handler + 342
> 15 org.python.python        0x004bcd25 PyEval_EvalFrameEx + 19429
> 16 org.python.python        0x004bee9d PyEval_EvalCodeEx + 2109
> 17 org.python.python        0x004bcf0c PyEval_EvalFrameEx + 19916
Michael, here you probably have the traceback you asked for (assumed
I'm right with my assumption above) :-)
Friedrich

On Nov 12, 2011, at 2:47 AM, Paul Ivanov <piv...@gm...> wrote:
> On Fri, Nov 11, 2011 at 5:40 PM, Benjamin Root <ben...@ou...> wrote:
>> On Fri, Nov 11, 2011 at 7:19 PM, Benjamin Root <ben...@ou...> wrote:
>>> 
>>> On Thu, Nov 10, 2011 at 5:52 PM, Paul Ivanov <piv...@gm...> wrote:
>>>> 
>>>> Just wanted to re-ping the list, but include John and Ben directly:
>>>> 
>>>> can we get the appropriate commit tagged as v1.1.0 in the git repo?
>>>> 
>>> 
>>> Sure thing. I will add that tag.
>>> 
>>> Ben Root
>>> 
>> 
>> The best I can figure is that commit
>> 0fc9830fe946f6221e9ceff2910cd0c2118b0965 was the last one before the release
>> announcement by John on Oct. 11. There was subsequently a commit on that
>> day to fix ipython links. I can't remember if that happened before or after
>> (I think after).
>> 
>> Can anybody concur?
> 
> On my PR to fix those links, John closed it and said he'd add it to
> the release branch, and they're up on the site, so I'd say that commit
> made it in. But I don't know if there were others afterward that made
> it in
> 
My memory is that the ipy pull request came just after the tarball, so I think you have it right Ben
> 

On Fri, Nov 11, 2011 at 5:40 PM, Benjamin Root <ben...@ou...> wrote:
> On Fri, Nov 11, 2011 at 7:19 PM, Benjamin Root <ben...@ou...> wrote:
>>
>> On Thu, Nov 10, 2011 at 5:52 PM, Paul Ivanov <piv...@gm...> wrote:
>>>
>>> Just wanted to re-ping the list, but include John and Ben directly:
>>>
>>> can we get the appropriate commit tagged as v1.1.0 in the git repo?
>>>
>>
>> Sure thing. I will add that tag.
>>
>> Ben Root
>>
>
> The best I can figure is that commit
> 0fc9830fe946f6221e9ceff2910cd0c2118b0965 was the last one before the release
> announcement by John on Oct. 11. There was subsequently a commit on that
> day to fix ipython links. I can't remember if that happened before or after
> (I think after).
>
> Can anybody concur?
On my PR to fix those links, John closed it and said he'd add it to
the release branch, and they're up on the site, so I'd say that commit
made it in. But I don't know if there were others afterward that made
it in
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

On Fri, Nov 11, 2011 at 7:19 PM, Benjamin Root <ben...@ou...> wrote:
> On Thu, Nov 10, 2011 at 5:52 PM, Paul Ivanov <piv...@gm...> wrote:
>
>> Just wanted to re-ping the list, but include John and Ben directly:
>>
>> can we get the appropriate commit tagged as v1.1.0 in the git repo?
>>
>>
> Sure thing. I will add that tag.
>
> Ben Root
>
>
The best I can figure is that commit
0fc9830fe946f6221e9ceff2910cd0c2118b0965 was the last one before the
release announcement by John on Oct. 11. There was subsequently a commit
on that day to fix ipython links. I can't remember if that happened before
or after (I think after).
Can anybody concur?
Ben Root

On Thu, Nov 10, 2011 at 5:52 PM, Paul Ivanov <piv...@gm...> wrote:
> Just wanted to re-ping the list, but include John and Ben directly:
>
> can we get the appropriate commit tagged as v1.1.0 in the git repo?
>
>
Sure thing. I will add that tag.
Ben Root

On this topic, I have a patch that tells BboxImage whether or not to
always apply interpolation (as is the desire when doing data analysis)
or to apply interpolation only when the image is at a non-native
resolution (as is the desire when using an image to annotate
something).
The pull request is here:
Since we cannot attach files on github, I've attached the test script,
image file that I was using, and the before/after here.
And can the max post size be increased on matplotlib-users, so that
when even smallish images are attached, the messages don't go into
moderation?
On Thu, Oct 13, 2011 at 11:40 AM, Daniel Hyams <dh...@gm...> wrote:
> Ah yes, I forget :/ I was focused on images as being "pure" things that
> should be displayed, and forgot about the image processing angle.
> So would the solution be a keyword argument that tells imshow/BboxImage and
> friends not to interpolate when at native resolution, which is set to the
> current behavior as default?
> If that's not an acceptable solution, I can just leave the patch in my own
> personal code and not worry about any further...I thought that I was fixing
> a bug there :)
>
> I guess the main difference is whether the image is treated as sacred and
> should be displayed perfectly when possible, versus the ability to modify
> the picture on purpose via the interpolations, for whatever reason the user
> wants. Understandably, matplotlib has taken the latter approach, because
> the context has always been (as far as I can tell from the examples)
> displaying the pixels for a scientific purpose. However, when you want to
> display an image for a annotational type purpose, the former approach should
> be taken, in my opinion.
>
>
> On Thu, Oct 13, 2011 at 11:13 AM, John Hunter <jd...@gm...> wrote:
>>
>> On Thu, Oct 13, 2011 at 10:06 AM, Daniel Hyams <dh...@gm...> wrote:
>>
>> > Isn't the purpose of interpolation to handle situations where the image
>> > is
>> > being displayed at a different size than its native resolution? It
>> > seems
>>
>> Not solely, it can also be used to do local average of noisy images to
>> get a smoother view, eg bilinear or bicubic averaging of neighboring
>> pixels.
>
>
>
> --
> Daniel Hyams
> dh...@gm...
>
-- 
Daniel Hyams
dh...@gm...

Just wanted to re-ping the list, but include John and Ben directly:
 can we get the appropriate commit tagged as v1.1.0 in the git repo?
On Thu, Nov 3, 2011 at 2:21 PM, Paul Ivanov <piv...@gm...> wrote:
> I added a note to the release docs about tagging the releases - right
> now, there's no clear way inside git to know what ended up in v1.1.0
> final, without grabbing a tarball and poking around. I'm inlining the
> relevant part of that commit here, so that John/Ben can tag the
> release after the fact.
>
> ---
> For each release candidate as well as for the final release version,
> please `git tag` the commit you will use for packaging like so::
>
>  git tag -a v1.1.0rc1
>
> The `-a` flag will allow you to write a message about the tag, and
> affiliate your name with it. A reasonable tag message would be something
> like ``v1.1.0 Release Candidate 1 (September 24, 2011)``. To tag a
> release after the fact, just track down the commit hash, and::
>
>  git tag -a v1.0.1 a9f3f3a50745
>
> Tags allow developers to quickly checkout different releases by name,
> and also provides source download via zip and tarball on github.
> ---
best,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

2011年10月22日 Eric Firing <ef...@ha...>:
> moved from matplotlib-users:
>
> http://sourceforge.net/mailarchive/forum.php?thread_name=CAN06%3DCx2zgh8YrnF2WRaJ%3D0E8i3ROLdYW4VuurtqKrx3mdkeEg%40mail.gmail.com&forum_name=matplotlib-users
OK
> On 10/22/2011 09:31 AM, Friedrich Romstedt wrote:
>>
>> 2011年10月21日 Friedrich Romstedt<fri...@gm...>:
>> <snippet>
>> 3) Providing a dedicated Filter class, that can be fed to
>> set_filter() instead of set_gray(). This I like best.
>> </snippet>
>>
>> So the filter idea was Ben's idea. I still like idea (3) for the
>> design best. I will check if it is possible to inject the filter code
>> into the renderer framework, since all colour settings arguments
>> somewhen flow into a call into the renderer.
This is apparently a no-go. The backends are too tightly bound to the
C extensions moduled, e.g. aggdraw. E.g. the image drawing method of
the Agg backend is directly assigned in the fashion::
 self.draw_image = self._renderer.draw_image
So no, this will not work this way.
>> Pro: No rcParams
>> addition necessary, no modification of the peculiar colors.py
>> ColorConverter framework necessary, just leaving those things
>> untouched and hence no worries and headaches about them.
So I'll touch it again. I will just check my refactor I did a year
ago on ColorConverter, which was pretty decent, but well, it needs
some check. I would first commit that to my repo, than people who are
interested can test, and then we can go on testing the higher level
functionality.
I think the filters will, instead of signalling colors.colorConveter
via rcParams that some conversion mode is turned on, signal that in
the decorator function simply directly to colors.colorConverter.
There are some open ends, though.
>> No disabling
>> of higher-level caching and at the same time negligible small impact
>> if there is no filter active. Con: I don't know yet if it works. I
>> vaguely remember there were some problems when I checked that
>> possibility last time (with pixmaps or something like that). I think
>> I will find out soon enough.
:-) Apparently I found out the same thing a year ago.
The methodology will be like this: The Artists can store a stack of
filters, and also provide some easy-appetite-wetter .set_gray()
method. When their draw method is decorated with a special decorator,
say @filtered, then the filters will be activated upon entering and
deactivated upon exit. The activation happens via putting the filters
onto the filter stack in the ColorConverter instance. I'm pretty sure
this will work, somehow at least. ;-)
I've run into some strange Bus error compiling the latest matplotlib,
I'll drop another email on the user list probably (since I'm acting
here as a user, I just want to run the tests).
Friedrich

On 11/9/2011 2:00 PM, Arik Raffael Funke wrote:
> Hi Mike,
>
> I managed to get matplotlib to compile and run on Python 3.2.2 on
> Windows though at present there are two problems:
>
> 1. The linker is missing the "/MANIFEST" argument. This means that the
> manifest files are not being created and somehow the module does not
> link the dependencies properly. (Resulting in the problem I described in
> my email earlier today.) Also linking breaks due to the missing manifest
> files.
This is not a matplotlib specific issue. You are using Visual Studio 
2010, which is not officially supported by Python distutils.
>
> I found that a (probably too specific) fix is to modify the function
> "make_extension" in setupext.py: Changing the first line of the function to:
> ext = Extension(*args, extra_link_args=['/MANIFEST'], **kwargs)
>
> I am sure however that the extra arguments must be set depending on the
> compiler chosen - though I do not quite follow the workflow of setup.py...
>
>
> 2. The file containing the visual studio static dependencies
> (http://matplotlib.sourceforge.net/win32_static_vs.tar.gz) still has the
> old tk and tcl versions. It would suffice to add tk85.lib and tcl85.lib
> from a Python3 installation to the package.
I recommend against using that package. It is better to build all 
dependencies with the same compiler and settings that will be used to 
build matplotlib. Up-to-date static libraries for the MS compilers 
supported by Python distutils are at 
<http://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib>
Christoph
>
> Also, the existence of this package is very poorly advertised. It seems
> to be mentionned only in the code of setupext.py. The wiki-page
> http://matplotlib.sourceforge.net/users/installing.html makes no mention
> of it in the setion "Installing from source". It suggests that it is
> necessary to build each of the dependencies oneself.
>
> Apart from this, on the face of it matplotlib seems to work fine on
> Python 3.2.2 on Windows.
>
> Many thanks!!!
> Arik
>
>
> On 09/11/2011 18:24, Michael Droettboom wrote:
> > I just pressed the big green merge button... :)
> >
> > Master should now have all of the Python 3 portability changes. It's
> > passing all tests, and running all examples, but I still wouldn't be
> > surprised if some things broke in the process. Please kick the tires
> > and report bugs. It would be helpful in the bug reports to know whether
> > the bug is only on Python 2 or 3 or both, and whether it is a regression
> > from matplotlib 1.1.x.
> >
> > Cheers,
> > Mike
> >
> >
> ------------------------------------------------------------------------------
> > RSA(R) Conference 2012
> > Save 700ドル by Nov 18
> > Register now
> > http://p.sf.net/sfu/rsa-sfdev2dev1
>
>
>

Hi Mike,
I managed to get matplotlib to compile and run on Python 3.2.2 on 
Windows though at present there are two problems:
1. The linker is missing the "/MANIFEST" argument. This means that the 
manifest files are not being created and somehow the module does not 
link the dependencies properly. (Resulting in the problem I described in 
my email earlier today.) Also linking breaks due to the missing manifest 
files.
I found that a (probably too specific) fix is to modify the function 
"make_extension" in setupext.py: Changing the first line of the function to:
ext = Extension(*args, extra_link_args=['/MANIFEST'], **kwargs)
I am sure however that the extra arguments must be set depending on the 
compiler chosen - though I do not quite follow the workflow of setup.py...
2. The file containing the visual studio static dependencies 
(http://matplotlib.sourceforge.net/win32_static_vs.tar.gz) still has the 
old tk and tcl versions. It would suffice to add tk85.lib and tcl85.lib 
from a Python3 installation to the package.
Also, the existence of this package is very poorly advertised. It seems 
to be mentionned only in the code of setupext.py. The wiki-page 
http://matplotlib.sourceforge.net/users/installing.html makes no mention 
of it in the setion "Installing from source". It suggests that it is 
necessary to build each of the dependencies oneself.
Apart from this, on the face of it matplotlib seems to work fine on 
Python 3.2.2 on Windows.
Many thanks!!!
Arik
On 09/11/2011 18:24, Michael Droettboom wrote:
 > I just pressed the big green merge button... :)
 >
 > Master should now have all of the Python 3 portability changes. It's
 > passing all tests, and running all examples, but I still wouldn't be
 > surprised if some things broke in the process. Please kick the tires
 > and report bugs. It would be helpful in the bug reports to know whether
 > the bug is only on Python 2 or 3 or both, and whether it is a regression
 > from matplotlib 1.1.x.
 >
 > Cheers,
 > Mike
 >
 > 
------------------------------------------------------------------------------
 > RSA(R) Conference 2012
 > Save 700ドル by Nov 18
 > Register now
 > http://p.sf.net/sfu/rsa-sfdev2dev1
-- 
Arik FUNKE
Institut Langevin
ESPCI ParisTech, CNRS UMR 7587, UPMC, UDD, INSERM
10 rue Vauquelin, 75231 PARIS Cedex 05, FRANCE
Tel: +33 1 40 79 45 91; Fax: +33 1 40 79 45 37
E-mail: ari...@es...

I just pressed the big green merge button... :)
Master should now have all of the Python 3 portability changes. It's 
passing all tests, and running all examples, but I still wouldn't be 
surprised if some things broke in the process. Please kick the tires 
and report bugs. It would be helpful in the bug reports to know whether 
the bug is only on Python 2 or 3 or both, and whether it is a regression 
from matplotlib 1.1.x.
Cheers,
Mike

Hello
I have been trying to use the py3k branch but I am having some problems 
I am hoping somebody could help me with; more specifically I am looking 
for a way to statically link matplotlib.
Using
- VC 2010
- python 3.2.2
- the static linking libraries / header files for matplotlib
I have managed to get the py3k branch to build and install.
Unfortunately when I do "import pylab", python complains about missing 
dlls (for each of its dependencies, zlib, freetype, ...). Is there a way 
to link the libraries statically? I would really love to avoid having to 
juggle with dlls.
Many thanks.
Regards,
Arik
PS: As a side note, while building I am getting a lot of errors of the type:
build\temp.win32-3.2\Release\src\ft2font.pyd.manifest : general error 
c1010070: Failed to load and parse the manifest. error: command 'mt.exe' 
failed with exit status 31
I managed to get rid of these by manually creating empty .manifest files 
though I am not sure what effect this might have and whether there is an 
easier way.
-- 
Arik FUNKE
Institut Langevin
ESPCI ParisTech, CNRS UMR 7587, UPMC, UDD, INSERM
10 rue Vauquelin, 75231 PARIS Cedex 05, FRANCE
Tel: +33 1 40 79 45 91; Fax: +33 1 40 79 45 37
E-mail: ari...@es...

On Sun, Nov 6, 2011 at 4:43 PM, Nathaniel Smith <nj...@po...> wrote:
> Hi matplotters,
>
> As any of you subscribed to the numpy-discussion list will have
> probably noticed, there's intense debate going on about how numpy can
> do a better job of handling missing data and masked arrays. Part of
> the problem is that we aren't actually sure what users need these
> features to do. There's one group who just wants R-style "missing
> data", and their needs are pretty straightforward -- they just want a
> magic value that indicates some data point doesn't actually exist. But
> it seems like there's also demand for a more "masked array"-like
> feature, similar to the current numpy.ma, where the mask is
> non-destructive and easily manipulable. No-one seems clear on who
> exactly this should work, though, and there's a lot of disagreement
> about what semantics make sense. (If you want more details, there's a
> wiki page summarizing some of this[1]).
>
> Since you seem to be the biggest users of numpy.ma, it would be really
> helpful if you could explain how you actually use it, so we can make
> sure that whatever we do in numpy-land is actually useful to you!
>
> What does matplotlib use masked arrays for? Is it just a convenient
> way to keep an array and a boolean mask together in one object, or do
> you take advantage of more numpy.ma features? For example, do you
> ever:
> - unmask values?
> - create multiple arrays that share the same storage for their data,
> but have different masks? (i.e., creating a new array with new
> elements masked, but without actually allocating the memory for a full
> array copy)
> - use reduction operations on masked arrays? (e.g., np.sum(masked_arr))
> - use binary operations on masked arrays? (e.g., masked_arr1 +
> masked_arr2)
>
> And while we're at it, any complaints about how numpy.ma works now,
> that a new version might do better?
>
> Thanks in advance,
> -- Nathaniel
>
> [1] https://github.com/njsmith/numpy/wiki/NA-discussion-status
>
>
Hi Nathaniel,
Unfortunately, I can't spend much more time on this topic due to my
dissertation work. I will allow others to elaborate further, if they wish.
But I think I can summarize it a bit.
First, we try our best to respect multiple ways of users specifying missing
data as input to our main plotting functions. Most common are NaNs and
np.mamasks. Given that we try to maintain compatibility with older
versions of
Numpy, we are going to have to build some sort of compatibility mechanism
to unify any representation (NaNs, np.ma, NA(or whatever it will be
called)) under a single abstraction to be used internally. This will
probably be np.ma at first until we can depend on the existence of np.NA.
Second, with functions that have multiple input arrays (pretty much all of
them), a single mask has to be applied to all data (typically a
logical_or'ing of the individual masks). Some other functions such as the
pcolor family of functions have slightly more complicated mask merging.
The most important thing is that we do not modify the user's data, and we
keep copies to a minimum. np.ma works great because we can convert the
arrays into masked_arrays without a copy, and the mask-merging process does
not modify the user's input data. I don't think we were using some of the
more advanced features of np.ma, but I can't be sure of that.
I guess the tricky thing that could occur (and probably should be tested
for) is if the input array is already a masked array and that we aren't
changing the user's pre-existing masks.
Ben Root

Hi matplotters,
As any of you subscribed to the numpy-discussion list will have
probably noticed, there's intense debate going on about how numpy can
do a better job of handling missing data and masked arrays. Part of
the problem is that we aren't actually sure what users need these
features to do. There's one group who just wants R-style "missing
data", and their needs are pretty straightforward -- they just want a
magic value that indicates some data point doesn't actually exist. But
it seems like there's also demand for a more "masked array"-like
feature, similar to the current numpy.ma, where the mask is
non-destructive and easily manipulable. No-one seems clear on who
exactly this should work, though, and there's a lot of disagreement
about what semantics make sense. (If you want more details, there's a
wiki page summarizing some of this[1]).
Since you seem to be the biggest users of numpy.ma, it would be really
helpful if you could explain how you actually use it, so we can make
sure that whatever we do in numpy-land is actually useful to you!
What does matplotlib use masked arrays for? Is it just a convenient
way to keep an array and a boolean mask together in one object, or do
you take advantage of more numpy.ma features? For example, do you
ever:
 - unmask values?
 - create multiple arrays that share the same storage for their data,
but have different masks? (i.e., creating a new array with new
elements masked, but without actually allocating the memory for a full
array copy)
 - use reduction operations on masked arrays? (e.g., np.sum(masked_arr))
 - use binary operations on masked arrays? (e.g., masked_arr1 + masked_arr2)
And while we're at it, any complaints about how numpy.ma works now,
that a new version might do better?
Thanks in advance,
-- Nathaniel
[1] https://github.com/njsmith/numpy/wiki/NA-discussion-status

Hey gang,
as per this discussion:
On Thu, Nov 3, 2011 at 3:40 AM, John Hunter <jd...@gm...> wrote:
> On Nov 2, 2011, at 10:47 PM, Benjamin Root <ben...@ou...> wrote:
>
> So the instruction should be to remind John Hunter to update the entry in
> PyPi? Got it.
>
>
> Even better, it should be:
> 1) update the release notes in the devel docs
> 2) give Ben access to the pypi acct.
I added a note to the release docs about tagging the releases - right
now, there's no clear way inside git to know what ended up in v1.1.0
final, without grabbing a tarball and poking around. I'm inlining the
relevant part of that commit here, so that John/Ben can tag the
release after the fact.
---
For each release candidate as well as for the final release version,
please `git tag` the commit you will use for packaging like so::
 git tag -a v1.1.0rc1
The `-a` flag will allow you to write a message about the tag, and
affiliate your name with it. A reasonable tag message would be something
like ``v1.1.0 Release Candidate 1 (September 24, 2011)``. To tag a
release after the fact, just track down the commit hash, and::
 git tag -a v1.0.1 a9f3f3a50745
Tags allow developers to quickly checkout different releases by name,
and also provides source download via zip and tarball on github.
---
best,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

What version of matplotlib are you using? This appears to be fixed in 
the latest 1.1. If you can let me know what version you're using, 
perhaps it will be easy to provide a patch if you're not able to upgrade 
wholesale.
Mike
On 10/31/2011 11:53 AM, Rachel Anderson wrote:
> Hello,
>
> I've noticed a bug with matplotlib.pyplot.imsave. Say I have an array 
> that is 1000*1000. This works perfectly:
>
> pylab.imsave(outfile,data,format='png',origin='lower')
>
> and I get image1.png.
>
> However, if the array is not a square, say 1000*1500, then the output 
> image is rotated 90 degrees compared to the image it prints out. 
> Example, image2.png.
>
> I tried numpy.rot90(frame) to rotate my data, and though my data did 
> rotate, so did the output frame. Example, image3.png.
>
> If there is a way around this, please let me know. Otherwise, it 
> should be fixed ;)
>
> Cheers,
> Rachel
>
>
> ------------------------------------------------------------------------------
> Get your Android app more play: Bring it to the BlackBerry PlayBook
> in minutes. BlackBerry App World™ now supports Android™ Apps
> for the BlackBerry® PlayBook™. Discover just how easy and simple
> it is! http://p.sf.net/sfu/android-dev2dev
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA