matplotlib-devel Mailing List for matplotlib

On 01.07.2012, at 12:17AM, Sandro Tosi wrote:
>> 
>> Just out of curiosity, what is the mismatch? (I believe you, I just
>> know very little about the debian process).
> 
> These are the rules: http://release.debian.org/wheezy/freeze_policy.html
> 
> And none of the rules match this situation. RC2 will be :)
What about the very last one?
"For packages which missed the freeze only for reasons outside of the control of the maintainers, we might be generous, but you need to contact us on your own, and you need to contact us soon."
Cheers,
					Derek

On Sun, Jul 1, 2012 at 12:08 AM, Fernando Perez <fpe...@gm...> wrote:
> On Sat, Jun 30, 2012 at 3:07 PM, Sandro Tosi <mo...@de...> wrote:
>> It's probably a nomenclature difference: it's a "freeze exception" so
>> asking to overrule the freeze in place and allow a package to enter
>> testing, but it must match basic rules, but in this case they are not
>> matched.
>
> Just out of curiosity, what is the mismatch? (I believe you, I just
> know very little about the debian process).
These are the rules: http://release.debian.org/wheezy/freeze_policy.html
And none of the rules match this situation. RC2 will be :)
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Sat, Jun 30, 2012 at 3:07 PM, Sandro Tosi <mo...@de...> wrote:
> It's probably a nomenclature difference: it's a "freeze exception" so
> asking to overrule the freeze in place and allow a package to enter
> testing, but it must match basic rules, but in this case they are not
> matched.
Just out of curiosity, what is the mismatch? (I believe you, I just
know very little about the debian process).
f

On Sun, Jul 1, 2012 at 12:04 AM, John Hunter <jd...@gm...> wrote:
> But I thought this is exactly when an *exception* is needed: when one
> doesn't match the rules.
It's probably a nomenclature difference: it's a "freeze exception" so
asking to overrule the freeze in place and allow a package to enter
testing, but it must match basic rules, but in this case they are not
matched.
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Jun 30, 2012, at 4:35 PM, Sandro Tosi <mo...@de...> wrote
> 
> I've just reviewed the rules, and sadly realized the final mpl release
> doesn't match them, so it's not worth asking for the exception.
>> 
But I thought this is exactly when an *exception* is needed: when one doesn't match the rules. 

Hello,
On Sat, Jun 30, 2012 at 10:54 PM, John Hunter <jd...@gm...> wrote:
> Yeah, the diff Sandro is referring to for us is just between rc2 and final. Hopefully he can argue that since r1.1.1-rc2 is already in, they can accept this minor diff to final.
I've just reviewed the rules, and sadly realized the final mpl release
doesn't match them, so it's not worth asking for the exception.
> If not,Sandro, is there any reason you can't just ship rc2 into debian? It's essentially the same thing.
Oh sure, wheezy will release with RC2 - it's just my personal taste to
release with the last version :)
cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Sat, Jun 30, 2012 at 1:54 PM, John Hunter <jd...@gm...> wrote:
> Yeah, the diff Sandro is referring to for us is just between rc2 and final. Hopefully he can argue that since r1.1.1-rc2 is already in, they can accept this minor diff to final.
In our case unfortunately we didn't have time to cut an RC, so our
diff beta1-HEAD was way too big. We just had to push through the
work. Let's just say that my wife was not amused with my Friday night
being a non-stop IRC marathon with Min "because we really need to get
in before debian freeze tonight!!!" :)
f

On Jun 30, 2012, at 3:46 PM, Fernando Perez <fperez.net@
> 
> Wow, I guess it paid off for us to stay up until 2am last night to get
> IPython in... Our diff was enormous so we would have not been allowed
> in at al. Whew :)
Yeah, the diff Sandro is referring to for us is just between rc2 and final. Hopefully he can argue that since r1.1.1-rc2 is already in, they can accept this minor diff to final. 
If not,Sandro, is there any reason you can't just ship rc2 into debian? It's essentially the same thing. 

On Jun 30, 2012, at 3:42 PM, Sandro Tosi <mo...@de...> wrote:
> Hello John,
> thanks for your effort! but...
> 
> 
> ... we're already too late for the Debian freeze :( the diff is quite
> small, so I'll ask for a freeze exception.
Ouch. Sorry for the screwup. Good luck with the exception request: all that we added were minor bugfixes from the release candidate rc2 that you already uploaded.
 Keep us posted. 

On Sat, Jun 30, 2012 at 1:42 PM, Sandro Tosi <mo...@de...> wrote:
> ... we're already too late for the Debian freeze :( the diff is quite
> small, so I'll ask for a freeze exception.
Wow, I guess it paid off for us to stay up until 2am last night to get
IPython in... Our diff was enormous so we would have not been allowed
in at al. Whew :)
I hope they'll grant the exception for mpl...
Cheers,
f

Hello John,
thanks for your effort! but...
On Sat, Jun 30, 2012 at 9:55 PM, John Hunter <jd...@gm...> wrote:
> OK, the v1.1.1 tarball is up
> at https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.1
> and this is now the download folder the main site points to. I'm leaving up
> the rc2 binaries til Russell and Christoph can build v1.1.1 binaries and we
> get them uploaded. Sandro, if you're around, you are good to go for
> including this in debian, hopefully squeaking in under the freeze (sorry for
> the last minute push).
... we're already too late for the Debian freeze :( the diff is quite
small, so I'll ask for a freeze exception.
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On 6/30/2012 12:55 PM, John Hunter wrote:
>
>
> On Sat, Jun 30, 2012 at 2:40 PM, Fernando Perez <fpe...@gm...
> <mailto:fpe...@gm...>> wrote:
>
> On Sat, Jun 30, 2012 at 11:46 AM, John Hunter <jd...@gm...
> <mailto:jd...@gm...>> wrote:
> > Well, looks like we better get moving then ;-)
>
> Go MPL! It would be great to have matching releases of IPython and
> MPL, just in time for the Debian freeze and SciPy 2012 :)
>
>
> OK, the v1.1.1 tarball is up at
> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.1
> and this is now the download folder the main site points to. I'm
> leaving up the rc2 binaries til Russell and Christoph can build v1.1.1
> binaries and we get them uploaded. Sandro, if you're around, you are
> good to go for including this in debian, hopefully squeaking in under
> the freeze (sorry for the last minute push).
>
> I will hold off on the users and announce list emails til the updated
> binaries are up.
>
> Tagged: git tag v1.1.1 7e47149a7b05f8e5cf1cc899a7e4e7c90dd4244f
>
> Thanks to all!
> JDH
Here are the Windows installers, built against numpy 1.6.2. Sorry, I can 
not upload them to SF. There seems to be some permission problems that 
the SF admins would need to fix manually.
<http://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib>
Christoph

On Sat, Jun 30, 2012 at 12:55 PM, John Hunter <jd...@gm...> wrote:
> OK, the v1.1.1 tarball is up
> at https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.1
> and this is now the download folder the main site points to. I'm leaving up
> the rc2 binaries til Russell and Christoph can build v1.1.1 binaries and we
> get them uploaded. Sandro, if you're around, you are good to go for
> including this in debian, hopefully squeaking in under the freeze (sorry for
> the last minute push).
>
> I will hold off on the users and announce list emails til the updated
> binaries are up.
>
> Tagged: git tag v1.1.1 7e47149a7b05f8e5cf1cc899a7e4e7c90dd4244f
>
> Thanks to all!
Awesome, congrats!

On Sat, Jun 30, 2012 at 2:40 PM, Fernando Perez <fpe...@gm...>wrote:
> On Sat, Jun 30, 2012 at 11:46 AM, John Hunter <jd...@gm...> wrote:
> > Well, looks like we better get moving then ;-)
>
> Go MPL! It would be great to have matching releases of IPython and
> MPL, just in time for the Debian freeze and SciPy 2012 :)
>
>
OK, the v1.1.1 tarball is up at
https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.1
and this is now the download folder the main site points to. I'm leaving
up the rc2 binaries til Russell and Christoph can build v1.1.1 binaries and
we get them uploaded. Sandro, if you're around, you are good to go for
including this in debian, hopefully squeaking in under the freeze (sorry
for the last minute push).
I will hold off on the users and announce list emails til the updated
binaries are up.
Tagged: git tag v1.1.1 7e47149a7b05f8e5cf1cc899a7e4e7c90dd4244f
Thanks to all!
JDH

On Sat, Jun 30, 2012 at 11:46 AM, John Hunter <jd...@gm...> wrote:
> Well, looks like we better get moving then ;-)
Go MPL! It would be great to have matching releases of IPython and
MPL, just in time for the Debian freeze and SciPy 2012 :)
Cheers,
f

Well, looks like we better get moving then ;-). I have some time today to
do this (sorry for dropping out last week). The only PR I see that perhaps
should go in is https://github.com/matplotlib/matplotlib/pull/961
Anything I'm missing? I'm going to start testing this for the final
release and will put something out later today Sandro.
On Thu, Jun 21, 2012 at 1:01 PM, Sandro Tosi <mo...@de...> wrote:
> Hi all,
>
> On Sat, Jun 9, 2012 at 11:14 PM, John Hunter <jd...@gm...> wrote:
> > I just uploaded the v1.1.1rc2 tarballs to the sourceforge site
>
> Is there a timeline for the final release? The Debian freeze is
> announced for June 30th.
>
> Cheers,
> --
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
>

Hi!
Thanks for the answer! I think the linestyle and the color settings are 
ok. error bars that are not just lines look very ugly, i would not even 
dare to make dashed or dotted ones. the color of the error bars can be 
set separately with elinecolor while the default is to use the color of 
the markers.
Cheers,
Hans
On 06/22/2012 02:58 PM, Benjamin Root wrote:
>
> On Fri, Jun 22, 2012 at 5:58 AM, Hans Dembinski <han...@ki...
> <mailto:han...@ki...>> wrote:
>
> Hi again,
>
> I send this patch to the mailing list two weeks ago and did not get
> any response. If you reject it, could you please explain why or how
> I should improve?
>
> Best regards.
>
>
>
> Our apologies, there aren't that many of us. I see that you followed
> our documentation for submitting a patch:
>
> http://matplotlib.sourceforge.net/devel/gitwash/patching.html
>
> Looking at your patch, I think it makes sense to do what you did. I
> only wonder if there are any other properties that should be taken care
> of here? Color? Linestyle? etc?
>
> Thoughts?
>
> Cheers!
> Ben Root
>
> Note to self: we need to update the docs to describe how to do Pull
> Requests on GitHub.
>

Please also report these issues to Ubuntu.
If its significant enough it we can fix this issue in the package. But
we can't fix what we don't know about.
The option of updating the rc to the future final 1.1.1 is also open if
the bug fixed are worth it.

I'm having a tough time figuring this out: Saving an animation seems to
hang when using `streamplot`. The exact same animation runs without issue
when calling show.
On my system, the example below hangs consistently at frame 173. However,
the number of saved frames (before hanging) varies with density of stream
lines (i.e. number of line segments in streamplot): More frames saved for
lower density.
Seems to be a memory or file-size issue, but
 * Memory use doesn't seem to grow. (this suggests that ffmpeg adds
frames to disk as opposed to memory.)
 * Saving the animation up to the frame just before it hangs gives modest
(~1MB) videos.
Maybe this is a limitation of `ffmpeg`?
Can someone confirm that the example hangs on their system? (Somehow, I
often run into bugs that are not reproducible.)
In case this is system dependent:
* OSX 10.6
* Python 2.6.1 (system install)
* matplotlib master
* ffmpeg 0.10
Simple plots seem to work fine, but I should probably try to reproduce
using something other than streamplot (maybe create the equivalent number
of line and arrow collections).
-Tony
#~~~ Example
import numpy as np
import matplotlib.pyplot as plt
import matplotlib.animation as animation
fig, ax = plt.subplots()
# do nothing function that prints frame
def update(frame_num):
 print frame_num
 return []
Y, X = np.mgrid[:1:100j, :1:100j]
U = np.ones_like(X)
V = np.ones_like(X)
ax.streamplot(X, Y, U, V, density=1)
ani = animation.FuncAnimation(fig, update, save_count=500)
# save hangs at frame 173 (this probably varies by system, if it's
reproducible).
ani.save('animation.avi')
# show animates all frames w/o issue.
#plt.show()

On Fri, Jun 22, 2012 at 5:58 AM, Hans Dembinski <han...@ki...>wrote:
> Hi again,
>
> I send this patch to the mailing list two weeks ago and did not get any
> response. If you reject it, could you please explain why or how I should
> improve?
>
> Best regards.
>
>
>
Our apologies, there aren't that many of us. I see that you followed our
documentation for submitting a patch:
http://matplotlib.sourceforge.net/devel/gitwash/patching.html
Looking at your patch, I think it makes sense to do what you did. I only
wonder if there are any other properties that should be taken care of
here? Color? Linestyle? etc?
Thoughts?
Cheers!
Ben Root
Note to self: we need to update the docs to describe how to do Pull
Requests on GitHub.

Hi again,
I send this patch to the mailing list two weeks ago and did not get any 
response. If you reject it, could you please explain why or how I should 
improve?
Best regards.
-------- Original Message --------
Subject: Patch for errorbar, alpha kw did not apply to lines and cap markers
Date: 2012年6月06日 17:57:31 +0200
From: Hans Dembinski <han...@ki...>
To: mat...@li...
Hi matplotlib developers,
this is my first commit to matplotlib. I am using it heavily in a
scientific context. I followed the How-to and send you an according
patch for what I consider a bug. If it doesn't make sense, please be
lenient with me for now, since it my first time. : )
As described in the subject line, I made the alpha keyword in the
errorbar command act also on the error bars and not only on the markers.
The previous behaviour seemed inconsistent.
Cheers,
Hans

In article <4FD...@ha...>,
 Eric Firing <ef...@ha...> wrote:
> If you have expertise in python package building on OS X, including more 
> than one method and more than one OS X version, please see 
> https://github.com/matplotlib/matplotlib/issues/168.
> 
> Eric
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
I have commented and include the suggested change to setupext.py. I'm 
strongly in favor.
-- Russell

Hi all,
On Sat, Jun 9, 2012 at 11:14 PM, John Hunter <jd...@gm...> wrote:
> I just uploaded the v1.1.1rc2 tarballs to the sourceforge site
Is there a timeline for the final release? The Debian freeze is
announced for June 30th.
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

If you have expertise in python package building on OS X, including more 
than one method and more than one OS X version, please see 
https://github.com/matplotlib/matplotlib/issues/168.
Eric

On Thu, Jun 14, 2012 at 4:12 PM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Thu, Jun 14, 2012 at 11:08 AM, tcb <the...@gm...> wrote:
>
>> Hi,
>>
>> I'm trying to plot a grid of images with no spaces in between them and I
>> have problems with the snapping. The grid is computed in data coordinates
>> and the positions of the images are determined by the extents parameter
>>
>> ax.imshow(read_png(filename), extent=extent, snap=True)
>>
>>
>> The images and extents are always the same size and each image starts
>> where the last finished
>>
>> (x0, x0+dx, y0, y0+dy)
>> (x0+dx, x0+2*dx, y0, y0+dy)
>> etc...
>>
>>
>> but it seems something happens in the backend (both QT4 and GTKAgg) and
>> pixel seams are visible between the images at various zoom levels.
>>
>> It seems the ImageGrid was developed to fix this kind of problem, but I'm
>> not sure I can adapt my plot to use ImageGrid. I want to draw stuff over my
>> images and I need to position them in data coordinates.
>>
>> I've tried the snap=True parameter to imshow and it doesn't seem to
>> affect the output.
>>
>> Does anyone have a simple solution to this problem which eliminates the
>> seams?
>>
>> thanks,
>>
>>
>>
> Could you try out the latest version of matplotlib from the master
> branch? There have been some work in this area in the past few months. I
> don't know if any of that work went into the recently announced v1.1.1-rc2.
>
> Ben Root
>
>
hi,
I'm using the latest version from git.
Any idea what patches are part of that work? or even which
classes/functions were touched?
thanks,