Re: [matplotlib-devel] Unit-Test Structure Submitted
On Wed, Feb 18, 2009 at 2:43 PM, James Evans jreva...@earthlink.net wrote: All, I have just submitted a first-cut at a unit-test harness. The unit-tests do require the use of the 'nose' python module. Everything has been placed in the 'test' directory off of the root trunk branch. There is a README file with lots of information on how to use it. This is in addition to a few test cases already bundled in (they make great examples)! The idea is that whenever somebody adds a new feature or makes a change they update/add the appropriate test case and re-run the harness to make sure nothing is broken. There is most definitely room for improvement with this, but it gives a starting point from which discussions and modifications can take place. Any questions or comments? What is the naming convention for the test harness? I see filenames_with_underscores, camelCase, CapWords, and it looks like all the methods in MplTestCase are camelCase, whereas mpl uses only names_with_underscores. Although it would probably be a lot of busy work to convert at this point, I think it would be a good idea to follow the existing mpl naming conventions. Darren -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug in xlim or savefig or hist?
I take this back -- I hadn't read your initial bug very carefully. If Inkscape is rendering the SVG correctly, but it's PDF output is not correct, then that seems like an Inkscape bug or a PDF viewer bug -- there's not too much we could do on the matplotlib end. When you say you see it in WXAgg, WX, GTKAgg etc., do you mean you see it in the interactive window, or just this behavior when you save an SVG, load it in Inkscape and then output a PDF? In the latter case, the SVG output from all backends (except Cairo) follows the same code path so should be identical. Does directly outputting PDF from matplotlib work for you ? -- (it works here) Mike Michael Droettboom wrote: I see it with 0.98.5.x, but not with SVN trunk. I'll look into this further and see what I can determine. Mike Olle Engdegård wrote: On Wed, 18 Feb 2009, Joshua Lippai wrote: Interesting. I can't reproduce your result using either the MacOSX or WXAgg backend. Which backend are you using, and does the problem persist if you use a different one? Hmm, I see it in at least WXAgg, WX, GTKAgg ... /Olle -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net 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 -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug in xlim or savefig or hist?
Sorry for not being clear enough. I see this only when exporting to svg, importing it to Inkscape and then saving as pdf there. Never interactively. And never if exporting directly to pdf from matplotlib. It could very well be a bug in Inkscape, but matplotlib is still saving data that should not be there, this is what I wanted to point out. And I take it back that it doesn't show in Inkscape, it was just hidden from view. The extra bars are there. /Olle On Thu, 19 Feb 2009, Michael Droettboom wrote: I take this back -- I hadn't read your initial bug very carefully. If Inkscape is rendering the SVG correctly, but it's PDF output is not correct, then that seems like an Inkscape bug or a PDF viewer bug -- there's not too much we could do on the matplotlib end. When you say you see it in WXAgg, WX, GTKAgg etc., do you mean you see it in the interactive window, or just this behavior when you save an SVG, load it in Inkscape and then output a PDF? In the latter case, the SVG output from all backends (except Cairo) follows the same code path so should be identical. Does directly outputting PDF from matplotlib work for you ? -- (it works here) Mike Michael Droettboom wrote: I see it with 0.98.5.x, but not with SVN trunk. I'll look into this further and see what I can determine. Mike Olle Engdegård wrote: On Wed, 18 Feb 2009, Joshua Lippai wrote: Interesting. I can't reproduce your result using either the MacOSX or WXAgg backend. Which backend are you using, and does the problem persist if you use a different one? Hmm, I see it in at least WXAgg, WX, GTKAgg ... /Olle -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net 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 -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] path simplification can decrease the smoothness of data plots a
a writes: Michael Droettboom md...@... writes: Thanks for the pointers. The original simplification code was written by John Hunter (I believe), and I don't know if it was designed by him also or is a replication of something published elsewhere. So I take no credit for and have little knowledge of its original goals. I'm not sure on everything it does, but it seems to do clipping and removes line segments where the change in slope is less than some limit. There are probably better algorithms out there, but this one works surprisingly well and is fast and simple. I think it should be a requirement that it returns points which are a subset of the original points- with the change you've made it does this, right? Oh Hey! I'm the one who originally wrote the path simplification code. I'd have thought it would be gone by now, but I am very happy it turned out to be useful. I made it up in order to plot a very large set of noisy data I had. The goal was to simplify two types of plots at once: Smooth curves, as well as very noisy data where many lines are 'on top' of each other. (eg plot(rand(10)) ). I noticed both could be taken care of by checking for changes in slope. An important goal (for me) was making sure that the min/max span of the points plotted was preserved. (so that eg plot(rand(1000)) spans from the lowest to highest point in the data (ie ~ 0 to 1) for any zoom factor). I'm not sure if this property survived...: If you do plot(rand(1000)) with the latest matplotlib and gradually zoom out on the x axis, you can see the top/bottom tips of the plotted line flickering in height, which is what I was trying to avoid. I forget whether I actually got it as I wanted it though, maybe I gave up. Allan -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Sphinx custom extension mess, and patches
Gael Varoquaux schrieb:
Hi all,
Sorry for the multiple posting, this concerns various groups, and I'd
rather the information not be lost.
While working on getting our in-lab library ready to be merged with NiPy,
I ran into some sort of 'sphinx extension mess' where various sphinx
extension would have side effects on each other, and most important, the
extensions did not work with sphinx trunk.
Which is of course kind of my fault, because I keep changing the API :)
But it must also be said that during 0.x, I tend to view cleanliness and
good code as more important than 100% backwards compatibility.
I got the side effects to be limited by cleaning up the generated code
from autosummary before each run: I added the following code in my
sphinx conf.py:
# Hack: run the autosummary generation script
import shutil
if os.path.exists('generated'):
shutil.rmtree('generated')
os.system('%s sphinxext/autosummary_generate.py -o generated *.rst' %
sys.executable)
I am attaching a diff of all the modifications I made to get the various
extensions to work. I hope you can use it to get your various extensions
working on sphinx trunk quicker. For the NiPy guys, I will be committing
these changes in the fff2 tree soon, and we can go over this at the
sprint.
This does raise a problem: this extension code is all over the place, in
various repository. Some of the code cannot live in the sphinx repo, as
it introduces dependencies. However, as the extensions are not importable
from Python (I can't do 'from matplotlib.sphinxext import mathmpl'), the
different projects using them end up copying them in their repo, and thus
there are several versions floating around not updated. Some of the
extensions would do not add externa dependencies to sphinx. These should
be pushed into sphinx, with tests. That way as sphinx evolves, they do
not break.
I'm all for it. In the case of autosummary, I'm guilty of not getting it
in sooner. This will change soon. In other cases, I don't even know of
the extension, probably because those who write it deem it as too
project-specific to contribute it.
I don't ask for too much if an extension is contributed, so by all means
do at least post about your extensions!
Georg
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Sphinx custom extension mess, and patches
Michael Droettboom schrieb: Gael, You raise a very good point about the duplication of code around. As a case in point, the patches you provided no longer apply to the canonical (or at least original) versions of the plugins that began life in matplotlib. Recent versions of Sphinx have a proper extension API, so that try ... except importing is no longer necessary. For mathmpl.py --- I will move that into the matplotlib installed code tree, so, as you suggest, from matplotlib.sphinxext import mathmpl will work. Obviously, that won't really provide traction until the next release of matplotlib. And it relies on only_directive.py, so I will probably have to put that in matplotlib as well for now, though that is a reasonable candidate for inclusion in Sphinx. The only is so trivial that it will, in this or a more extended form, certainly be part of 0.6, which will not come out later than Feb 31 ;) I have submitted inheritance_diagram.py to Sphinx already. There didn't seem to be much interest, and there were some details (particularly how it deals with files), that weren't the Sphinx way, and there few documents and/or examples etc. at the time about how to do it right. Someone else ended up re-engineering it to use pygraphviz which felt pretty heavy weight to me. So the thing kind of stalled. But it's probably worth another push. The mails are still in my look at it again folder. I kind of agree that using pygraphviz is counterproductive, since many systems have graphviz but no so many, I suspect, pygraphviz. Is the current version of the inheritance_diagram.py the one in matplotlib? cheers, Georg -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug in xlim or savefig or hist?
On Thu, 19 Feb 2009, Michael Droettboom wrote: The drawing and then clipping is normal behavior. All of the backend formats have the ability to clip out arbitrary regions for drawing, so we take advantage of that rather than doing our own geometric clipping algorithm. The latter is a great deal of work to get right. It sounds like the Inkscape PDF export is not exporting the clipping path correctly, which may actually be related to the version of Cairo Inkscape is using. In any case, there's not much we can do here. I see, thanks for explaining. This is actually the Inkscape bug https://bugs.launchpad.net/inkscape/+bug/168800 with one of the comments suggesting to learn from Matplotlib how to export clipping to pdf with Cairo. It is supposedly fixed in Inkscape svn trunk. /Olle -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Rasterized artists have wrong transform
I just updated to the latest svn, and unveiled a bug that's evident
when using mixed-mode rendering in the PDF backend. I'm suspect I'm
the only one running my patch that enables set_rasterized on a
per-artist basis, so I'm the only one that's seeing it. :) Artists
that are left in vector mode are plotted correctly, while artists that
are rasterized are squished down toward the lower left corner of the
axes.
Looking at the svn log, I suspect it's the changes to the path
simplification code (r6847) doing something funky at the transforms
level. Is that the right place to start looking? Any tips on how to
track this down?
Thanks,
Eric
Sample code to reproduce the problem:
import numpy
from matplotlib.pyplot import subplot, get_cmap, scatter, colorbar, show
basecolors = get_cmap('gist_yarg')
colormap, normer = basecolors, None #LogNorm()
x = y = c = numpy.arange(10) +1
dummy = scatter(x,y,c=c,cmap=colormap)#, norm=normer)
cbar = colorbar(dummy)#, spacing='proportional',ticks=isolevels.levels)
dummy.set_rasterized(True)
dummy.figure.savefig('raster_test.pdf')
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
