Michael Droettboom wrote: > I've committed support for comparing SVG files using Inkscape and > verifying them against the official SVG DTD using xmllint. > Man, are we standards compliant around here or what? :) Cool.
> Michael Droettboom wrote: > >> Andrew Straw wrote: >> >> >>> Done in r7863. To make use of it, do something like the following patch >>> (and don't forget to delete the baseline .pdf files from the repository): >>> >>> -...@image_comparison(baseline_images=['simplify_curve']) >>> +...@image_comparison(baseline_images=['simplify_curve'],extensions=['png']) >>> >>> >>> >> Great! >> >> > This is a nice feature. However, in hindsight, I may not use it right > away -- I actually found a bug in the SVG backend using one of the tests > I assumed would only affect the Agg backend. :) > I think it's good not to use the feature very much. I've already found it handy when developing against a test -- you only need to generate that test's image once. > A couple more comments about the test framework -- which has already > paid for itself ten times over. In Numpy (and a number of local Python > projects), I can 'cd' to the tests directory and do something like: > > nosetests test_simplification.py:test_hatch_simplify > > and run on particular test, or a single file of tests. It's a huge time > saver when trying to fix a bug. However, with matplotlib I get: > > > nosetests test_simplification.py > E > ====================================================================== > ERROR: Failure: ImportError (cannot import name cbook) > <snip> > I suspect this is something peculiar to how matplotlib gets imported. > Yes, it would be very nice, I absolutely agree. I'm not sure what's going on, either, but I agree that it would be nice to fix. See below for an idea. > Also, I have a quad-core machine, so I put this in my .noserc, which > will run tests in parallel: > > [nosetests] > processes=4 > > Unfortunately, due to however matplotlib is delegating to nose, this > doesn't seem to get picked up. > > I don't know if I'll get a chance to look at these things right away, > but thought I'd share in case the solutions are obvious to anyone else > (which I know isn't good form, but hey... ;) > My guess is that this may actually be related to the first issue. On this second issue, though, I have a specific idea -- in order for MPL to pickup the nose plugin, I had to do the song and dance in test() of matplotlib/__init__.py in which I create a nose.config.Config instance. I suspect this is why your processes argument isn't getting through -- we're completely bypassing any local nose config and creating ours programattically. I'm definitely not in favor the big song and dance, so if you can rip it out and still get the plugin to load, that would be super. Once that is figured out, presumably the direct call to "nosetests test_simplification.py:test_hatch_simplify" will also load the nose plugins and thus not exhibit weird behavior when a known failure is encountered. I almost certainly won't get a chance to look at these right away, so if anyone wants to go spelunking in the nose/mpl interaction, feel free. -Andrew ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
