matplotlib-devel Mailing List for matplotlib

Hi all,
First, I would like to congratulate you for your work on Matplotlib. I 
am using Matplotlib widgets in all my current projects, embedded in PyQt 
graphical user interfaces.
As you may know, PyQt 4.4.2 has been released a few days ago.
And I found out a performance bug when embedding a Matplotlib 0.91.2 
canvas in a PyQt 4.4.2 object: the pan/zoom feature is very slow (with 
PyQt 4.3.3, and the exact same scripts, pan/zoom is real-time).
I am posting this in PyQt mailing-list too, but I guess that you could 
have more ideas on that matter (Matplotlib widgets may not be used very 
often in PyQt).
Thanks for your help!
Regards,
Pierre Raybaut

On Friday 30 May 2008 10:51:50 am John Hunter wrote:
> On Fri, May 30, 2008 at 9:12 AM, Michael Droettboom <md...@st...> wrote:
> > FYI: I have a little time today to do some documentation work myself
> > today. I've been doing some minor edits (mostly formatting things) on the
> > developer docs, and then was going to hit up the user docs. Does that
> > step on your toes / duplicate effort? Anywhere where you think I would
> > be more useful?
I am planning on converting docstrings this weekend. We should keep everyone 
posted of what we are working on though, with so much to do, it would be a 
shame to duplicate effort.
Perhaps we should temporarily copy the users guide and htdocs into the doc 
directory on the trunk. When someone is working on converting a section in 
the users guide or an html file, he can add his name to the top of the file, 
and then delete the file when done. That way we slowly delete the old docs 
and can be sure we converted everything.
> Three areas that you are the residing expert on are fonts, mathtext
> and transformations, so user's guide chapters on these would be great.
>
> In addition, one place where we can all make small, frequent
> contributions is in the new faq section. Much of the stuff on the web
> is out of date. When we answer questions on the mailing list that
> recur, with 5 minutes of extra work, could put an entry in the FAQ
> (user interface specific stuff, font stuff, install problems, seg
> faults, web app server...).
Sounds good.

On Fri, May 30, 2008 at 9:12 AM, Michael Droettboom <md...@st...> wrote:
> FYI: I have a little time today to do some documentation work myself today.
> I've been doing some minor edits (mostly formatting things) on the
> developer docs, and then was going to hit up the user docs. Does that step
> on your toes / duplicate effort? Anywhere where you think I would be more
> useful?
Three areas that you are the residing expert on are fonts, mathtext
and transformations, so user's guide chapters on these would be great.
In addition, one place where we can all make small, frequent
contributions is in the new faq section. Much of the stuff on the web
is out of date. When we answer questions on the mailing list that
recur, with 5 minutes of extra work, could put an entry in the FAQ
(user interface specific stuff, font stuff, install problems, seg
faults, web app server...).

Hi,
John Hunter wrote:
> I've done a fair amount of testing on the branch (0.91.3),
> particularly looking at all the PDF and SVG output from backend
> driver, and these backends are in the best shape I've ever seen them.
> [...]
> I think we should take a crack at fixing these since the branch is
> otherwise in such good shape that we could perhaps go a long time w/o
> another maintenance release.
Before the branches and releases are all frozen for the foreseeable
future, I might mention a minor but long-lived bug that has been
around since at least the end of 2006... Please excuse me if this is
old news, as I haven't checked the archives recently for any progress
on this. I've noticed that the bug is still around in r5314 of trunk.
On Mac OS X (both Tiger and Leopard), there is a small misalignment
between grid lines and tick marks on the standard plot (as well as
loglog and semilog) with the PS backend. I did not check which one of
the lines is in the correct place. The problem does not occur with the
PDF backend.
I attach a ps and pdf file produced by the following snippet:
import pylab as pl
pl.plot([1,2,3,4,5])
pl.grid()
pl.savefig('grid_misaligned_with_ticks.ps')
pl.savefig('grid_misaligned_with_ticks.pdf')
The pdf file is fine, but the ps file shows a misalignment. To view
this in Mac OS X, I used Preview (which converts the PS to PDF first).
To eliminate Preview as the problem, I also saved the file as an EPS
and used epstopdf from MacTeX to convert it for Preview. Viewed on
Linux with acroread, the PS file produced on the Mac also shows
misalignment (I haven't verified this recently).
The same code snippet produces no problems on Linux.
I realise this might not be a problem with matplotlib itself, but I'm
just curious if anyone picked it up and whether it is fixable before
the next release.
Thanks!
Ludwig

Done.
On Fri, May 30, 2008 at 10:06 AM, John Hunter <jd...@gm...> wrote:
> On Thu, May 29, 2008 at 11:11 PM, Charlie Moad <cw...@gm...> wrote:
>> I went ahead and called it 0.98.0. I am getting a parallels image
>> updated so I can do the windows builds, but it is getting late. I
>> will get those cranked out tomorrow. The source and mac builds are up
>> though. I got two internal compiler errors on the 0.98.0 build, which
>> I fixed by replacing -O3 with -Os on those two commands only. I also
>> updated the MANIFEST.in file to include agg24 instead of agg23.
>
> Hey Charlie -- thanks for getting these two releases out. I think we
> should probably hide them, though, until the windows binaries are up,
> since it will confuse windows users who follow the link to the latest
> releases but find no binaries. So if you are more than a few hours
> away from putting up the windows installers, let's hide these until
> they are ready.
>
> Thanks,
> JDH
>

Darren Dale wrote:
> On Thursday 29 May 2008 10:59:40 am Michael Droettboom wrote:
> 
>> Darren Dale wrote:
>> 
>>> I'm sorry, I just don't understand how to use this.
>>> 
>
> And I'm also sorry for my mild panic attack yesterday. I had way too many 
> things coming at me all at once. Things are back to normal today.
> 
I know I've been there, and I completely understand. Sorry I was trying 
to "teach to fish" rather than just "giving you a bloody fish, already" 
in the midst of that... ;)
> 
>> I can do the merge for you.
>>
>> [mdroe@wonkabar matplotlib]$ svn update
>> U lib/matplotlib/ticker.py
>> U CHANGELOG
>> Updated to revision 5299.
>> [mdroe@wonkabar matplotlib]$ svnmerge merge
>> U CHANGELOG
>> C lib/matplotlib/texmanager.py
>> C lib/matplotlib/backends/backend_svg.py
>>
>> property 'svnmerge-integrated' set on '.'
>>
>> # We don't want to merge backend_svg.py -- we just want what's currently
>> on the trunk
>> [mdroe@wonkabar matplotlib]$ cp
>> lib/matplotlib/backends/backend_svg.py.working
>> lib/matplotlib/backends/backend_svg.py
>>
>> # Manually resolve texmanager.py
>> [mdroe@wonkabar matplotlib]$ emacs -nw lib/matplotlib/texmanager.py
>>
>> # Mark everything as resolved
>> [mdroe@wonkabar matplotlib]$ svn -R resolved .
>> Resolved conflicted state of 'lib/matplotlib/backends/backend_svg.py'
>>
>> # Commit
>> [mdroe@wonkabar matplotlib]$ svn commit -F svnmerge-commit-message.txt
>> Sending .
>> Sending CHANGELOG
>> Sending lib/matplotlib/texmanager.py
>> Transmitting file data ..
>> Committed revision 5300.
>> [mdroe@wonkabar matplotlib]$
>> 
>
> Thanks for posting this. I'll take a sweep through the bug tracker this 
> weekend, and see if I can do this myself. I'll be working on documentation 
> this weekend, I'll add a section on merging to the documentation once I can 
> do it on my own.
> 
There is a little blurb on merging already in the coding guidelines, but 
it would be great to have it expanded by someone while it's still a 
fresh experience.
FYI: I have a little time today to do some documentation work myself 
today. I've been doing some minor edits (mostly formatting things) on 
the developer docs, and then was going to hit up the user docs. Does 
that step on your toes / duplicate effort? Anywhere where you think I 
would be more useful?
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Thu, May 29, 2008 at 11:11 PM, Charlie Moad <cw...@gm...> wrote:
> I went ahead and called it 0.98.0. I am getting a parallels image
> updated so I can do the windows builds, but it is getting late. I
> will get those cranked out tomorrow. The source and mac builds are up
> though. I got two internal compiler errors on the 0.98.0 build, which
> I fixed by replacing -O3 with -Os on those two commands only. I also
> updated the MANIFEST.in file to include agg24 instead of agg23.
Hey Charlie -- thanks for getting these two releases out. I think we
should probably hide them, though, until the windows binaries are up,
since it will confuse windows users who follow the link to the latest
releases but find no binaries. So if you are more than a few hours
away from putting up the windows installers, let's hide these until
they are ready.
Thanks,
JDH

On Thursday 29 May 2008 10:59:40 am Michael Droettboom wrote:
> Darren Dale wrote:
> > I'm sorry, I just don't understand how to use this.
And I'm also sorry for my mild panic attack yesterday. I had way too many 
things coming at me all at once. Things are back to normal today.
> I can do the merge for you.
>
> [mdroe@wonkabar matplotlib]$ svn update
> U lib/matplotlib/ticker.py
> U CHANGELOG
> Updated to revision 5299.
> [mdroe@wonkabar matplotlib]$ svnmerge merge
> U CHANGELOG
> C lib/matplotlib/texmanager.py
> C lib/matplotlib/backends/backend_svg.py
>
> property 'svnmerge-integrated' set on '.'
>
> # We don't want to merge backend_svg.py -- we just want what's currently
> on the trunk
> [mdroe@wonkabar matplotlib]$ cp
> lib/matplotlib/backends/backend_svg.py.working
> lib/matplotlib/backends/backend_svg.py
>
> # Manually resolve texmanager.py
> [mdroe@wonkabar matplotlib]$ emacs -nw lib/matplotlib/texmanager.py
>
> # Mark everything as resolved
> [mdroe@wonkabar matplotlib]$ svn -R resolved .
> Resolved conflicted state of 'lib/matplotlib/backends/backend_svg.py'
>
> # Commit
> [mdroe@wonkabar matplotlib]$ svn commit -F svnmerge-commit-message.txt
> Sending .
> Sending CHANGELOG
> Sending lib/matplotlib/texmanager.py
> Transmitting file data ..
> Committed revision 5300.
> [mdroe@wonkabar matplotlib]$
Thanks for posting this. I'll take a sweep through the bug tracker this 
weekend, and see if I can do this myself. I'll be working on documentation 
this weekend, I'll add a section on merging to the documentation once I can 
do it on my own.
Darren

 Yeah. I am totally updated with 10.5.3 and the latest dev tools.
 They have been talked about for a while on the list, but I just
wanted to record what I ran into during the builds. I'll reproduce
those errors after I get the windows builds done tonight and shoot
them this way.
- Charlie
On Fri, May 30, 2008 at 8:19 AM, Michael Droettboom <md...@st...> wrote:
> Were the internal compiler errors on the Mac? Can you share them? It would
> be nice to work around these in a cleaner way if possible.
>
> Cheers,
> Mike
>
> Charlie Moad wrote:
>>
>> I went ahead and called it 0.98.0. I am getting a parallels image
>> updated so I can do the windows builds, but it is getting late. I
>> will get those cranked out tomorrow. The source and mac builds are up
>> though. I got two internal compiler errors on the 0.98.0 build, which
>> I fixed by replacing -O3 with -Os on those two commands only. I also
>> updated the MANIFEST.in file to include agg24 instead of agg23.
>>
>> - Charlie
>>
>> On Thu, May 29, 2008 at 10:06 PM, John Hunter <jd...@gm...> wrote:
>>
>>>
>>> On Thu, May 29, 2008 at 5:44 PM, Charlie Moad <cw...@gm...> wrote:
>>>
>>>>
>>>> Just to confirm, I should use the version tag, "0.98pre"?
>>>>
>>>
>>> My preference is to call it 0.98.0 unless Michael is feeling extra
>>> cautious. In which case we can call it 0.98pre or 0.98rc1 or whatever
>>> ...
>>>
>>> JDH
>>>
>>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>

Were the internal compiler errors on the Mac? Can you share them? It 
would be nice to work around these in a cleaner way if possible.
Cheers,
Mike
Charlie Moad wrote:
> I went ahead and called it 0.98.0. I am getting a parallels image
> updated so I can do the windows builds, but it is getting late. I
> will get those cranked out tomorrow. The source and mac builds are up
> though. I got two internal compiler errors on the 0.98.0 build, which
> I fixed by replacing -O3 with -Os on those two commands only. I also
> updated the MANIFEST.in file to include agg24 instead of agg23.
>
> - Charlie
>
> On Thu, May 29, 2008 at 10:06 PM, John Hunter <jd...@gm...> wrote:
> 
>> On Thu, May 29, 2008 at 5:44 PM, Charlie Moad <cw...@gm...> wrote:
>> 
>>> Just to confirm, I should use the version tag, "0.98pre"?
>>> 
>> My preference is to call it 0.98.0 unless Michael is feeling extra
>> cautious. In which case we can call it 0.98pre or 0.98rc1 or whatever
>> ...
>>
>> JDH
>>
>> 
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I went ahead and called it 0.98.0. I am getting a parallels image
updated so I can do the windows builds, but it is getting late. I
will get those cranked out tomorrow. The source and mac builds are up
though. I got two internal compiler errors on the 0.98.0 build, which
I fixed by replacing -O3 with -Os on those two commands only. I also
updated the MANIFEST.in file to include agg24 instead of agg23.
- Charlie
On Thu, May 29, 2008 at 10:06 PM, John Hunter <jd...@gm...> wrote:
> On Thu, May 29, 2008 at 5:44 PM, Charlie Moad <cw...@gm...> wrote:
>> Just to confirm, I should use the version tag, "0.98pre"?
>
> My preference is to call it 0.98.0 unless Michael is feeling extra
> cautious. In which case we can call it 0.98pre or 0.98rc1 or whatever
> ...
>
> JDH
>

On Thu, May 29, 2008 at 5:44 PM, Charlie Moad <cw...@gm...> wrote:
> Just to confirm, I should use the version tag, "0.98pre"?
My preference is to call it 0.98.0 unless Michael is feeling extra
cautious. In which case we can call it 0.98pre or 0.98rc1 or whatever
...
JDH

Michael Droettboom wrote:
> John Hunter wrote:
> 
>> On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <md...@st...> wrote:
>>
>> 
>> 
>>> Minor point: On my machine at least, I don't have to manually clean up the
>>> conflict files -- they are removed for me on the next commit. Those files
>>> are really just for reference. If you use a SVN frontend for diffing (such
>>> as psvn.el or meld) they are largely unnecessary.
>>> 
>>> 
>> On my machine I do need to manually purge these -- svn commit will
>> fail with a message like
>>
>> johnh@flag:mpl> svn commit -F svnmerge-commit-message.txt
>> svn: Commit failed (details follow):
>> svn: Aborting commit:
>> '/home/titan/johnh/python/svn/matplotlib.trunk/matplotlib/lib/matplotlib/image.py'
>> remains in conflict
>>
>>
>> even if I have manually edited out all the conflicts. 
>> 
> Oh -- it appears that "svn resolved" is what does this, not "svn 
> commit". I didn't realise that just deleting the files was enough and 
> have always used "svn resolved" as a matter of course. The convenient 
> thing about "svn resolved" is you can do "svn -R resolved ." to resolve 
> the whole tree once you're sure you're done.
> 
>> I then need to do
>>
>> johnh@flag:mpl> rm lib/matplotlib/image.py.*
>>
>> Maybe one of your emacs modes is helping you out behind the scenes?
>> Can you send me your emacs configs for svn?
>> 
>> 
>
> I use psvn.el, which is far easier to use IMHO than the built-in 
> pcl-svn. You can get it here -- I haven't set any customizations on it.
> 
I lied. There is one keyboard mapping I added that I've found pretty 
useful:
(global-set-key (kbd "s-s") 'svn-status-switch-to-status-buffer)
(define-key svn-status-mode-map (kbd "s-s") 'svn-status-bury-buffer)
This lets me toggle between the file I'm editing and the svn-status 
buffer using "Super-s" (Windows key-s). Makes it very convenient to 
edit a file, check the differences against the repository, and check 
them in.
Cheers,
Mike

John Hunter wrote:
> On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <md...@st...> wrote:
>
> 
>> Minor point: On my machine at least, I don't have to manually clean up the
>> conflict files -- they are removed for me on the next commit. Those files
>> are really just for reference. If you use a SVN frontend for diffing (such
>> as psvn.el or meld) they are largely unnecessary.
>> 
>
> On my machine I do need to manually purge these -- svn commit will
> fail with a message like
>
> johnh@flag:mpl> svn commit -F svnmerge-commit-message.txt
> svn: Commit failed (details follow):
> svn: Aborting commit:
> '/home/titan/johnh/python/svn/matplotlib.trunk/matplotlib/lib/matplotlib/image.py'
> remains in conflict
>
>
> even if I have manually edited out all the conflicts. 
Oh -- it appears that "svn resolved" is what does this, not "svn 
commit". I didn't realise that just deleting the files was enough and 
have always used "svn resolved" as a matter of course. The convenient 
thing about "svn resolved" is you can do "svn -R resolved ." to resolve 
the whole tree once you're sure you're done.
> I then need to do
>
> johnh@flag:mpl> rm lib/matplotlib/image.py.*
>
> Maybe one of your emacs modes is helping you out behind the scenes?
> Can you send me your emacs configs for svn?
> 
I use psvn.el, which is far easier to use IMHO than the built-in 
pcl-svn. You can get it here -- I haven't set any customizations on it.
http://www.xsteve.at/prg/vc_svn/
My favorite feature is the integration with ediff -- press 'E' in the 
svn-status buffer and it brings up an ediff session between your working 
copy and the SVN revision it came from.
Cheers,
Mike