matplotlib-devel Mailing List for matplotlib

John Hunter wrote:
> On Wed, Sep 23, 2009 at 12:56 PM, Andrew Straw <str...@as...> wrote:
> 
>> John Hunter wrote:
>> 
>>> On Wed, Sep 23, 2009 at 12:42 PM, Andrew Straw <str...@as...> wrote:
>>>
>>>
>>> 
>>>> Sorry, I should have been more clear. I was thinking that the
>>>> image_compare() decorator would call the test function multiple times,
>>>> having switched the backend between invocations. Thus, the call to
>>>> savefig() would continue not to explicitly set the extension. I've
>>>> quickly modified the source to reflect my idea, but I haven't had a
>>>> chance to flesh it out or test it. It should show the idea, though. See
>>>> attached.
>>>>
>>>> 
>>> Why not have the decorator pass the extension in to the test funcs --
>>> agg can print to pdf, ps, svg and png
>>>
>>> 
>> I'm not sure what you're suggesting. Presumably if we're driving agg OK
>> to draw .png, it will also draw .pdf OK (or does it have a pdf vector
>> backend independent of the MPL pdf backend that we want to test separately?)
>> 
>
> No, it doesn't have a separate backend, but the backend_agg figure
> canvas savefig method knows how to create FigureCanvasPDF etc to use
> that backend to write the file w/o having to switch the default
> backend with all the attendant hassles. So if you are using *Agg, and
> do
>
> savefig(somefile.pdf)
>
> agg will load the native pdf backend and use it. So I was envisioning
>
> def test_something(ext):
> make_plot
> fig.savefig('myfile.%s'%ext)
>
> and having the decorator pass in the extensions it wants one-by-one
> 
I see. Is there something like
backend_agg.set_default_savefig_extension()? That would achieve both of
our goals. So maybe if it doesn't exist it would be easy to add in?
-Andrew

On Wed, Sep 23, 2009 at 12:56 PM, Andrew Straw <str...@as...> wrote:
> John Hunter wrote:
>> On Wed, Sep 23, 2009 at 12:42 PM, Andrew Straw <str...@as...> wrote:
>>
>>
>>> Sorry, I should have been more clear. I was thinking that the
>>> image_compare() decorator would call the test function multiple times,
>>> having switched the backend between invocations. Thus, the call to
>>> savefig() would continue not to explicitly set the extension. I've
>>> quickly modified the source to reflect my idea, but I haven't had a
>>> chance to flesh it out or test it. It should show the idea, though. See
>>> attached.
>>>
>>
>> Why not have the decorator pass the extension in to the test funcs --
>> agg can print to pdf, ps, svg and png
>>
> I'm not sure what you're suggesting. Presumably if we're driving agg OK
> to draw .png, it will also draw .pdf OK (or does it have a pdf vector
> backend independent of the MPL pdf backend that we want to test separately?)
No, it doesn't have a separate backend, but the backend_agg figure
canvas savefig method knows how to create FigureCanvasPDF etc to use
that backend to write the file w/o having to switch the default
backend with all the attendant hassles. So if you are using *Agg, and
do
 savefig(somefile.pdf)
agg will load the native pdf backend and use it. So I was envisioning
def test_something(ext):
 make_plot
 fig.savefig('myfile.%s'%ext)
and having the decorator pass in the extensions it wants one-by-one
JDH

On Wed, Sep 23, 2009 at 19:21, Michael Droettboom <md...@st...> wrote:
> That file was moved. I think I had a lingering .pyc lying around which is
> why it didn't fail on me.
yeah, here too: I saw it only after cleaning up the svn checkout.
> I have updated conf.py to import it from the
> right place. Hopefully it's working now.
Yeah, it works fine: thanks for the fixes.
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

(reply-all this time, I'm too used to scipy.org's reply-to munging)
On 18-Sep-09, at 9:36 PM, John Hunter wrote:
> On Fri, Sep 18, 2009 at 7:01 PM, Andrew Straw <str...@as...> 
> wrote:
>
>> Maybe the MPL binary was built with a numpy svn version that had API
>> incompatibilities with numpy releases?
>
> I built the python2.6 OSX 0.99.1rc1 binary with the numpy from the
> 1.3.0 dmg installer from the sf site, intentionally not using my local
> numpy from svn since I understand there are some ABI incompatibilities
> between 1.3.0 and 1.4.0svn and I wanted to target the latest release.
> What version are you using David?
Sorry for leaving this thread dangling. I was using the latest numpy 
SVN head, that was probably the issue. I've since built matplotlib 
from source without incident.
David

John Hunter wrote:
> On Wed, Sep 23, 2009 at 12:42 PM, Andrew Straw <str...@as...> wrote:
>
> 
>> Sorry, I should have been more clear. I was thinking that the
>> image_compare() decorator would call the test function multiple times,
>> having switched the backend between invocations. Thus, the call to
>> savefig() would continue not to explicitly set the extension. I've
>> quickly modified the source to reflect my idea, but I haven't had a
>> chance to flesh it out or test it. It should show the idea, though. See
>> attached.
>> 
>
> Why not have the decorator pass the extension in to the test funcs --
> agg can print to pdf, ps, svg and png
> 
I'm not sure what you're suggesting. Presumably if we're driving agg OK
to draw .png, it will also draw .pdf OK (or does it have a pdf vector
backend independent of the MPL pdf backend that we want to test separately?)
I was just thinking it would be easiest to have test functions that look
like:
@image_comparison('my_figure')
def my_figure_test():
 plt.plot([1,2,3],[4,5,6])
 plt.savefig('my_figure')
This could automatically test all backends we have the infrastructure
and the baseline images for. It doesn't force the test writer to worry
about that stuff.
-Andrew

On Wed, Sep 23, 2009 at 12:42 PM, Andrew Straw <str...@as...> wrote:
> Sorry, I should have been more clear. I was thinking that the
> image_compare() decorator would call the test function multiple times,
> having switched the backend between invocations. Thus, the call to
> savefig() would continue not to explicitly set the extension. I've
> quickly modified the source to reflect my idea, but I haven't had a
> chance to flesh it out or test it. It should show the idea, though. See
> attached.
Why not have the decorator pass the extension in to the test funcs --
agg can print to pdf, ps, svg and png

Jouni K. Seppänen wrote:
> John Hunter <jd...@gm...> writes:
>
> 
>>> pyplot.savefig('foo1')
>>> 
>> Take a look at the pyplot "switch_backends" function.
>> 
>
> Yes, that function was on the next line after the part you quoted. :-)
> It calls matplotlib.use with warn=False, but that function ends up doing
> nothing.
>
> 
>> Alternatively, agg knows how to save pdf if given the extension, so we
>> could wire up the testing to use a module level extension set
>> somewhere which could be updated for each backend. This is probably
>> safer and cleaner than switch_backends
>> 
>
> That sounds complicated. How about having the test cases call savefig
> with all the relevant file formats? That doesn't look so nice if the
> test cases end up with a big block of savefig calls, but it has the
> advantage that there is no magic involved and it is very obvious what is
> going on.
> 
Sorry, I should have been more clear. I was thinking that the
image_compare() decorator would call the test function multiple times,
having switched the backend between invocations. Thus, the call to
savefig() would continue not to explicitly set the extension. I've
quickly modified the source to reflect my idea, but I haven't had a
chance to flesh it out or test it. It should show the idea, though. See
attached.
-Andrew

That file was moved. I think I had a lingering .pyc lying around which 
is why it didn't fail on me. I have updated conf.py to import it from 
the right place. Hopefully it's working now.
Cheers,
Mike
On 09/23/2009 10:09 AM, Sandro Tosi wrote:
> On Tue, Sep 22, 2009 at 16:21, Michael Droettboom<md...@st...> wrote:
> 
>> On second look, I think it's the "--small" commandline option that breaks
>> this. I hadn't tested my recent changes to the plot directive with that
>> flag. The new version of make.py in SVN r7815 should fix this.
>> 
> Thanks for your reply! I should have find it myself :)
>
> Anyhow, from a clean checked-out trunk, doc doesn't build:
>
> $ MATPLOTLIBDATA=../lib/matplotlib/mpl-data/
> PYTHONPATH=../build/lib.linux-x86_64-2.5/ ./make.py --small all
> Running Sphinx v0.6.2
> Exception occurred while building, starting debugger:
> Traceback (most recent call last):
> File "/usr/lib/pymodules/python2.5/sphinx/cmdline.py", line 171, in main
> warningiserror, tags)
> File "/usr/lib/pymodules/python2.5/sphinx/application.py", line 94,
> in __init__
> self.config = Config(confdir, CONFIG_FILENAME, confoverrides, self.tags)
> File "/usr/lib/pymodules/python2.5/sphinx/config.py", line 120, in __init__
> execfile(config['__file__'], config)
> File "/home/morph/deb/tmp/matplotlib/doc/conf.py", line 23, in<module>
> import ipython_console_highlighting
> ImportError: No module named ipython_console_highlighting
> 
>> /home/morph/deb/tmp/matplotlib/doc/conf.py(23)<module>()
>> 
> -> import ipython_console_highlighting
>
> indeed
>
> matplotlib/doc$ grep -ri ipython_console_highlighting *
> conf.py:import ipython_console_highlighting
> $
>
> Is that module benn {re.}moved?
>
> Regards,
> 

John Hunter <jd...@gm...> writes:
>>  pyplot.savefig('foo1')
>
> Take a look at the pyplot "switch_backends" function.
Yes, that function was on the next line after the part you quoted. :-)
It calls matplotlib.use with warn=False, but that function ends up doing
nothing.
> Alternatively, agg knows how to save pdf if given the extension, so we
> could wire up the testing to use a module level extension set
> somewhere which could be updated for each backend. This is probably
> safer and cleaner than switch_backends
That sounds complicated. How about having the test cases call savefig
with all the relevant file formats? That doesn't look so nice if the
test cases end up with a big block of savefig calls, but it has the
advantage that there is no magic involved and it is very obvious what is
going on.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On Wed, Sep 23, 2009 at 10:48 AM, Jouni K. Seppänen <jk...@ik...> wrote:
> Andrew Straw <str...@as...> writes:
>
>> Jouni - I don't think this would be hard to add, but I'm swamped at
>> work. If this is an itch you'd like to scratch, feel free to hack away
>> on the image_comparison() function in
>> lib/matplotlib/testing/decorators.py -- it's a pretty straightforward
>> piece of code.
>
> Changing that is probably easy enough, but how should the overall code
> path look?
>
> I was planning to switch backends in matplotlib.test after it runs the
> Agg tests, so that the same test cases could be used to produce pdf
> files (that's why they save files without extensions, right?) but this
> seems to be impossible. The matplotlib.use function is a no-op if
> matplotlib.backends has been imported, regardless of the warn argument.
> For example, the following code produces two png files:
>
>  #!/usr/bin/env python
>  import matplotlib
>
>  matplotlib.use('agg')
>  from matplotlib import pyplot
>  pyplot.plot([3,1,4,1])
>  pyplot.savefig('foo1')
Take a look at the pyplot "switch_backends" function.
Alternatively, agg knows how to save pdf if given the extension, so we
could wire up the testing to use a module level extension set
somewhere which could be updated for each backend. This is probably
safer and cleaner than switch_backends
JDH

Andrew Straw <str...@as...> writes:
> Jouni - I don't think this would be hard to add, but I'm swamped at
> work. If this is an itch you'd like to scratch, feel free to hack away
> on the image_comparison() function in
> lib/matplotlib/testing/decorators.py -- it's a pretty straightforward
> piece of code.
Changing that is probably easy enough, but how should the overall code
path look?
I was planning to switch backends in matplotlib.test after it runs the
Agg tests, so that the same test cases could be used to produce pdf
files (that's why they save files without extensions, right?) but this
seems to be impossible. The matplotlib.use function is a no-op if
matplotlib.backends has been imported, regardless of the warn argument.
For example, the following code produces two png files:
 #!/usr/bin/env python
 import matplotlib
 matplotlib.use('agg')
 from matplotlib import pyplot
 pyplot.plot([3,1,4,1])
 pyplot.savefig('foo1')
 pyplot.switch_backend('pdf')
 pyplot.plot([5,9,2,6])
 pyplot.savefig('foo2')
If you interchange the 'agg' and 'pdf' strings, you get two pdf files.
It looks like the following change to matplotlib/__init__.py would fix
this, but I'm a little doubtful since maybe there was a good reason to
make it like it is:
--- __init__.py	(revision 7815)
+++ __init__.py	(working copy)
@@ -822,8 +822,8 @@
 make the backend switch work (in some cases, eg pure image
 backends) so one can set warn=False to supporess the warnings
 """
- if 'matplotlib.backends' in sys.modules:
- if warn: warnings.warn(_use_error_msg)
+ if 'matplotlib.backends' in sys.modules and warn:
+ warnings.warn(_use_error_msg)
 return
 arg = arg.lower()
 if arg.startswith('module://'):
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Received from John Hunter on Tue, Sep 22, 2009 at 09:57:37PM EDT:
> On Tue, Sep 22, 2009 at 5:38 PM, <jas...@cr...> wrote:
> > I just downloaded 0.99.1 and ran into some problems using it in Sage.
> > Basically, in the tar.gz file, there was a setup.cfg file, which had the
> > following:
> 
> This was a bug in the tarball -- mpl doesn't keep a copy of setup.cfg
> in svn and shouldn't ship with it. We do ship setup.cfg.template
> which you can use to create and customize a setup.cfg, but there
> shouldn't be one by default.
> 
> It's not listed in MANIFEST.in, but apparently when I built the
> tarball I had not done an svn-clean. setup.cfg *was* in my MANIFEST
> (which is autogenerated at build time) on my build machine, but I am
> not sure why it was added since it isn't in MANIFEST.in.
> 
> In any case, I just rebuilt and reuploaded the tarball with no
> setup.cfg from a clean dir
> 
> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.1/
> 
> Thanks for the report.
> 
> JDH
The latest tarball (downloaded as of a few minutes ago) still seems to
contain a setup.cfg file:
$ tar zft matplotlib-0.99.1.tar.gz |grep setup.cfg
matplotlib-0.99.1/setup.cfg
matplotlib-0.99.1/setup.cfg.template
								L.G.

On Wed, Sep 23, 2009 at 8:47 AM, Lev Givon <le...@co...> wrote:
> contain a setup.cfg file:
>
> $ tar zft matplotlib-0.99.1.tar.gz |grep setup.cfg
> matplotlib-0.99.1/setup.cfg
> matplotlib-0.99.1/setup.cfg.template
It seems to depend on which mirror you get the file from. From Voxel,
I see setup.cfg but from "German Research Network (Berlin, Germany) "
I do not see it. We may just need time for the mirrors to update. I
probably should have used a different file name...
JDH

On Tue, Sep 22, 2009 at 16:21, Michael Droettboom <md...@st...> wrote:
> On second look, I think it's the "--small" commandline option that breaks
> this. I hadn't tested my recent changes to the plot directive with that
> flag. The new version of make.py in SVN r7815 should fix this.
Thanks for your reply! I should have find it myself :)
Anyhow, from a clean checked-out trunk, doc doesn't build:
$ MATPLOTLIBDATA=../lib/matplotlib/mpl-data/
PYTHONPATH=../build/lib.linux-x86_64-2.5/ ./make.py --small all
Running Sphinx v0.6.2
Exception occurred while building, starting debugger:
Traceback (most recent call last):
 File "/usr/lib/pymodules/python2.5/sphinx/cmdline.py", line 171, in main
 warningiserror, tags)
 File "/usr/lib/pymodules/python2.5/sphinx/application.py", line 94,
in __init__
 self.config = Config(confdir, CONFIG_FILENAME, confoverrides, self.tags)
 File "/usr/lib/pymodules/python2.5/sphinx/config.py", line 120, in __init__
 execfile(config['__file__'], config)
 File "/home/morph/deb/tmp/matplotlib/doc/conf.py", line 23, in <module>
 import ipython_console_highlighting
ImportError: No module named ipython_console_highlighting
> /home/morph/deb/tmp/matplotlib/doc/conf.py(23)<module>()
-> import ipython_console_highlighting
indeed
matplotlib/doc$ grep -ri ipython_console_highlighting *
conf.py:import ipython_console_highlighting
$
Is that module benn {re.}moved?
Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Jouni K. Seppänen wrote:
> Andrew Straw <str...@as...> writes:
>
> 
>> Michael Droettboom wrote:
>> 
>>> We can probably standardize the version of gs on the buildbot machines, 
>>> but it's been very useful up to now to have tests that can run on a 
>>> variety of developer machines as well. 
>>>
>>> 
>> I understood Jouni's idea to be to save the .pdfs as baseline images --
>> then the same version of gs would be used to generated the rasterized
>> images for the baseline and test result -- the version on your computer.
>> I think this is the way to go (either that or compare the PDFs directly
>> somehow).
>> 
>
> Yes, that's what I meant: we want to test that the PDF file generated by
> the code is "equivalent" to the baseline, and aside from some metadata
> in the files, I think "equivalence" should mean that the files generate
> the same rasterized output on some particular PDF renderer.
>
> I suppose Ghostscript is widespread enough that we can assume that it
> exists in the test environment? Or is there some buildout magic that we
> should add in some file?
> 
We can always use "gs --version" in subprocess.check_call() and if it's
not installed (or if there's some other error with it) just not compare
the pdf output. That way we still test that the pdf generation at least
doesn't raise an exception, and a test pdf is generated for later
inspection if need be.
Jouni - I don't think this would be hard to add, but I'm swamped at
work. If this is an itch you'd like to scratch, feel free to hack away
on the image_comparison() function in
lib/matplotlib/testing/decorators.py -- it's a pretty straightforward
piece of code.
-Andrew

Andrew Straw <str...@as...> writes:
> Michael Droettboom wrote:
>> We can probably standardize the version of gs on the buildbot machines, 
>> but it's been very useful up to now to have tests that can run on a 
>> variety of developer machines as well. 
>>
> I understood Jouni's idea to be to save the .pdfs as baseline images --
> then the same version of gs would be used to generated the rasterized
> images for the baseline and test result -- the version on your computer.
> I think this is the way to go (either that or compare the PDFs directly
> somehow).
Yes, that's what I meant: we want to test that the PDF file generated by
the code is "equivalent" to the baseline, and aside from some metadata
in the files, I think "equivalence" should mean that the files generate
the same rasterized output on some particular PDF renderer.
I suppose Ghostscript is widespread enough that we can assume that it
exists in the test environment? Or is there some buildout magic that we
should add in some file?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On Tue, Sep 22, 2009 at 5:38 PM, <jas...@cr...> wrote:
> I just downloaded 0.99.1 and ran into some problems using it in Sage.
> Basically, in the tar.gz file, there was a setup.cfg file, which had the
> following:
This was a bug in the tarball -- mpl doesn't keep a copy of setup.cfg
in svn and shouldn't ship with it. We do ship setup.cfg.template
which you can use to create and customize a setup.cfg, but there
shouldn't be one by default.
It's not listed in MANIFEST.in, but apparently when I built the
tarball I had not done an svn-clean. setup.cfg *was* in my MANIFEST
(which is autogenerated at build time) on my build machine, but I am
not sure why it was added since it isn't in MANIFEST.in.
In any case, I just rebuilt and reuploaded the tarball with no
setup.cfg from a clean dir
 https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.1/
Thanks for the report.
JDH