[matplotlib-devel] building matplotlib-0.99.1.1.tar.gz on Mac OS X 10.6.1 (Snow Leopard)

2009-10-12 Thread Daniel Huff
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

2009-10-12 Thread Michael Droettboom
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 
import matplotlib.pyplot as plt
  File 
"/wonkabar/data1/builds/matplotlib/build/lib.linux-i686-2.5/matplotlib/pyplot.py",
 
line 6, in 
from matplotlib import docstring
  File 
"/wonkabar/data1/builds/matplotlib/build/lib.linux-i686-2.5/matplotlib/docstring.py",
 
line 1, in 
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

2009-10-12 Thread Andrew Straw
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)
> 
> 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

2009-10-12 Thread Andrew Straw
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=7870&r2=7869&pathrev=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] Comparing pdf output in tests

2009-10-12 Thread Andrew Straw
Jouni K. Seppänen wrote:
> I am thinking about adding pdf comparison ability to compare_images. One
> simple way to do this would be to convert pdf files to pngs using
> Ghostscript: if we store reference pdf files, and both the reference
> file and the result of the test are converted using with exactly the
> same version of gs, there should be no font-rendering or antialiasing
> mismatches.
>
> Can we assume that all test computers will have some version of
> Ghostscript installed and callable as "gs"?
>
>   
Hi Jouni,

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.

-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

2009-10-12 Thread Andrew Straw
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

--
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

2009-10-12 Thread Michael Droettboom
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

2009-10-12 Thread Jouni K . Seppänen
Andrew Straw  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] Problem adding a new test

2009-10-12 Thread Jouni K . Seppänen
Andrew Straw  writes:

> 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?

How about keeping them gzipped? If you gzip an svg file and name it
something.svgz, inkscape seems to open it fine.

-- 
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

2009-10-12 Thread Andrew Straw
Jouni K. Seppänen wrote:
> Andrew Straw  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