[matplotlib-devel] building matplotlib-0.99.1.1.tar.gz on Mac OS X 10.6.1 (Snow Leopard)
Hello, With the caveat that I have not closely followed this mail list, I thought I would offer an alternate build method than what seems to be the preferred method for building matplotlib on Mac OS X. I tried to skim through recent mailing list posts to see if anything like this had been done, and did not immediately find anything. Forgive me if I'm repeating! As of Mac OS X 10.6.1, if you have X11 installed, you can build and use matplotlib without downloading anything else. (Unfortunately I have not yet had the opportunity to try this procedure out on a Leopard system.) First, I created a new setup.cfg on full auto: $ diff setup.cfg.template setup.cfg 25,26c25,26 #pytz = False #dateutil = False --- pytz = auto dateutil = auto 53,57c53,57 #gtk = False #gtkagg = False #tkagg = False #wxagg = False #macosx = False --- gtk = auto gtkagg = auto tkagg = auto wxagg = auto macosx = auto Then, I altered setupext.py so that the darwin config works like other operating systems. The difference is that I'm telling the script to look in /usr/X11, where freetype and libpng can be found on Mac OS X 10.6.1. $ diff setupext.py.orig setupext.py 53,54c53,54 '_darwin' : ['/sw/lib/freetype2', '/sw/lib/freetype219', '/usr/ local', '/usr', '/sw'], --- # '_darwin' : ['/sw/lib/freetype2', '/sw/lib/freetype219', '/ usr/local', # '/usr', '/sw'], 60c60 'darwin' : [], --- 'darwin' : ['/usr', '/usr/X11',], Then, I run: $ sudo python setupegg.py install And matplotlib builds as a universal binary and installs an egg into / Library/Python/2.6/site-packages/ The setup process detects the included numpy 1.2.1 and freetype2 (unknown version*), and also detects libpng (unknown version*), Tkinter 67083, Tk 8.5, and Tcl 8.5. * freetype is 2.3.9; see /usr/X11/include/freetype2/freetype/freetype.h * libpng is 1.2.35; see /usr/X11/include/libpng12/png.h On a 64-bit system in the default configuration (like both of mine), there is no 64-bit version of the wxPython libraries to load, and so it is not detected. However, if I do: $ export VERSIONER_PYTHON_PREFER_32_BIT=yes ### see the python man page Then the setup process detects wxPython 2.8.8.1. I filed a bug with Apple about the lack of a 64-bit wxPython library, and it is Apple Problem ID # 7294359, in case anyone cares. The setup process does not detect Gtk+, Qt(4), or Cairo, because these are not included with Mac OS X (that I know of). Hope this is helpful! -Dan Huff ps -- As an aside, I create edit ~/.pydistutils.cfg to allow an install for a per-user install as follows: $ cat ~/.pydistutils.cfg [install] install_lib = $HOME/Library/Python/$py_version_short/site-packages install_scripts = $HOME/usr/local/bin $ mkdir -p ~/Library/Python/2.6/site-packages $ python setupegg.py install This allows for more isolated testing in a sandbox user account. (end aside) -- 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
Re: [matplotlib-devel] Problem adding a new test
I've committed support for comparing SVG files using Inkscape and verifying them against the official SVG DTD using xmllint. 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. :) 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) -- Traceback (most recent call last): File /wonkabar/data1/usr/lib/python2.5/site-packages/nose-0.11.1-py2.5.egg/nose/loader.py, line 379, in loadTestsFromName addr.filename, addr.module) File /wonkabar/data1/usr/lib/python2.5/site-packages/nose-0.11.1-py2.5.egg/nose/importer.py, line 39, in importFromPath return self.importFromDir(dir_path, fqname) File /wonkabar/data1/usr/lib/python2.5/site-packages/nose-0.11.1-py2.5.egg/nose/importer.py, line 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File /wonkabar/data1/builds/matplotlib/build/lib.linux-i686-2.5/matplotlib/tests/test_simplification.py, line 4, in module import matplotlib.pyplot as plt File /wonkabar/data1/builds/matplotlib/build/lib.linux-i686-2.5/matplotlib/pyplot.py, line 6, in module from matplotlib import docstring File /wonkabar/data1/builds/matplotlib/build/lib.linux-i686-2.5/matplotlib/docstring.py, line 1, in module from matplotlib import cbook ImportError: cannot import name cbook -- Ran 1 test in 0.009s FAILED (errors=1) I suspect this is something peculiar to how matplotlib gets imported. 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... ;) Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA -- 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
Re: [matplotlib-devel] Problem adding a new test
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
Re: [matplotlib-devel] pylab.imshow() does not handle clip_path properly
Gellule Xg wrote: This is a bug report for matplotlib version 0.99.1.1 The clip_path keyword of imshow() does not work when setting it to (Path, Transform) for two reasons: Hi, Thanks for the report. Do you have a simple test script that we can use to see the problem and then fix it? We will then use this as the basis to create a test function to make sure the issue never crops up again. -Andrew Hi Andrew, Please try the following. It's a script that clips an NxN image based on its contour. Thanks, -Julien Hi Julien, I made a couple fixes to MPL 0.99 maintenance branch and then added a modified version your example in the tests. See http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/tests/test_axes.py?r1=7870r2=7869pathrev=7870 You should be able to use this approach to do what you were originally after. My actual fixes to MPL were in r7866 and r7867. I had to take a slightly different approach than your suggestion. The approach I implemented based on your initial patch doesn't access private variables or change the way calling setters methods works. -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
Re: [matplotlib-devel] Problem adding a new test
I suspect for that one we can just do without it. It isn't really testing anything SVG-specific. Mike Andrew Straw wrote: Michael Droettboom wrote: I've committed support for comparing SVG files using Inkscape and verifying them against the official SVG DTD using xmllint. I just noticed the test_axes/hexbin_extent.svg baseline image is more than 5 MB. I wonder if we can somehow simplify the svg generated to reduce the file size or if we should perhaps just not do the svg extension on this test? -Andrew -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA -- 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
Re: [matplotlib-devel] Comparing pdf output in tests
Andrew Straw straw...@astraw.com writes: Sorry for not noticing this earlier, but I'm looking in the baseline image directory, and I see a bunch of *_pdf.png files. I guess these have been convered to png from pdf on the tester's machine. Do you think it makes more sense to have the .pdf files in the test repo and convert to png at test run time? This way we don't become dependent on gs rendering quirks or differences across pdf renderers. Maybe the files are also smaller. That's exactly how it works now, isn't it? You are seeing the *_pdf.png files because those get produced while running the tests from the *.pdf files, and they are not checked into the svn repository. -- Jouni K. Seppänen http://www.iki.fi/jks -- 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
Re: [matplotlib-devel] Comparing pdf output in tests
Jouni K. Seppänen wrote: Andrew Straw straw...@astraw.com writes: Sorry for not noticing this earlier, but I'm looking in the baseline image directory, and I see a bunch of *_pdf.png files. I guess these have been convered to png from pdf on the tester's machine. Do you think it makes more sense to have the .pdf files in the test repo and convert to png at test run time? This way we don't become dependent on gs rendering quirks or differences across pdf renderers. Maybe the files are also smaller. That's exactly how it works now, isn't it? You are seeing the *_pdf.png files because those get produced while running the tests from the *.pdf files, and they are not checked into the svn repository. Sorry for the false alarm. My image browser was showing the .png and .svg files, but not the .pdfs for some reason. I assumed it was showing all the files in the directory, which lead to this false conclusion. -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
