matplotlib-devel Mailing List for matplotlib (Page 5)

On Sat, Sep 12, 2009 at 11:12 PM, Fernando Perez <fpe...@gm...> wrote:

> Here's a diff against current trunk to play with this idea.

Updated patch that handles correctly more than one option (I think the
bug was even in the original, not sure).

Cheers,

f

On Sat, Sep 12, 2009 at 8:29 PM, Fernando Perez <fpe...@gm...> wrote:

> Before I dive into the code too far, I figured I'd ask the experts.

Too late for that, common sense has never been my forte.

Here's a diff against current trunk to play with this idea.

WARNING: Please note that this is NOT meant to be applied for mpl yet!!!

I've actually modified the plot directive and renamed it to 'figplot',
so we can experiment a little to better understand things.  The point
is that this now lets us write reST of this type:

.. figplot:: code/make_figure_brainx.py
   :width: 3.6 in

   **Example from fMRI data:** In the graph presented, the nodes represent the
   areas of the brain described in Figure 1. Nodes are labeled accordingly and
   etc...

The text block is then passed as a caption to latex.

I renamed it because there's a bit of a conflict with the current
'plot' directive, which allows a filename *or* a content block, but in
that case the content block is meant to be the source code, as
illustrated in sampledoc:

http://matplotlib.sourceforge.net/sampledoc/extensions.html#inserting-matplotlib-plots

Since I'm not sure if we can find a clean solution to:

- path to script: goes into arg list
- inlined (multiline) code: goes into content block
- inlined (possibly multiline) caption: goes into content block

I put this version so we can start experimenting.  This does what
Ariel and I need, but I hope over time we can figure out a good
long-term solution.


Speaking of sphinx for books, as I've mentioned before to John, the
last big problem is being able to cross-reference arbitrary text
elements like you can in latex, be they chapters or sections or
whatever, and get a number or something that's meaningful in print.

I looked around, and apparently it's on the main docutils todo list:

http://docutils.sourceforge.net/docs/dev/todo.html#object-numbering-and-object-references

I hope we don't have to be the ones fixing that one...

Cheers,

f

Hi folks,

if one were to say, think of writing something like a book (or a
paper) using sphinx and plots generated from python scripts, the plot
directive would be extremely useful.  But as best as I can tell, it
generates at the end of the day 'image' directives, where as for
including figures in latex-produced PDF with captions and labels one
can later refer to, the plain sphinx 'figure' directive appears to be
more appropriate.  As we can read here:

http://docutils.sourceforge.net/docs/ref/rst/directives.html#images

Their signatures are:

Image
Directive Type:	"image"
Doctree Element:	image
Directive Arguments:	One, required (image URI).
Directive Options:	Possible.
Directive Content:	None.

Figure
Directive Type:	"figure"
Doctree Elements:	figure, image, caption, legend
Directive Arguments:	One, required (image URI).
Directive Options:	Possible.
Directive Content:	Interpreted as the figure caption and an optional legend.

A key difference is that image takes no content, while figure accepts
content and uses it for the figure caption.

Would it be possible/sensible to switch the plot directive to be a
superset of 'figure' instead of 'image'?

Before I dive into the code too far, I figured I'd ask the experts.

Thanks!

f

On Thu, Sep 10, 2009 at 8:08 PM, John Hunter <jd...@gm...> wrote:
> We've had a significant number of bug-fixes in the release branch, so
> this weekend I'm going to try and put out a release candidate for
> 0.99.1, and perhaps this will be the last release of this branch but
> time will tell.  I'll build the tarball and OSX binaries for the
> release candidate, and perhaps Christoph can build the win32 binaries
> for testing.  If all goes well we can proceed with the release later
> next week.

I've uploaded the 0.99.1 release candidate to the drop.io site, with a
tarball and OSX eggs and dmg files for python 2.5 and 2.6.  Christoph,
if you could now make the win32 binaries (not sure what to do abut the
numpy/64bit problem but we can at least build the others) I'll send
out a call for testing on the user list.

  http://drop.io/xortel1

Andrew, I also edited the make.osx file I use on the buildbot and
added a new target called "binaries" to ease the process of making the
nightly builds and to also incorporate all the fixes we discovered at
the scipy script which may have caused linking problems in the old
binaries I was building.  I may need to install additional stuff on
sage buildbot (in particular bdist_mpkg) to make this work, but we are
a step closer to the nightly builds.

Thanks,
JDH

Thinking about 1.0....

Has anyone looked at the new gui integration stuff in the IPython trunk?

Cheers,

Brian

On Thu, Sep 10, 2009 at 6:08 PM, John Hunter <jd...@gm...> wrote:

> We've had a significant number of bug-fixes in the release branch, so
> this weekend I'm going to try and put out a release candidate for
> 0.99.1, and perhaps this will be the last release of this branch but
> time will tell.  I'll build the tarball and OSX binaries for the
> release candidate, and perhaps Christoph can build the win32 binaries
> for testing.  If all goes well we can proceed with the release later
> next week.
>
> So please take some time to work though bugs and patches on the sf
> site -- if 0.99.1 is stable enough, we can live with that until we get
> the 1.0 trunk out with the new docstrings, testing, etc...
>
>  http://sourceforge.net/tracker/?group_id=80706&atid=560720
>  http://sourceforge.net/tracker/?group_id=80706&atid=560722
>
> JDH
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Thu, Sep 10, 2009 at 8:50 PM, Brian Granger <ell...@gm...> wrote:
> Thinking about 1.0....
>
> Has anyone looked at the new gui integration stuff in the IPython trunk?

No -- this was on the list for the scipy sprint but we didn't get to
it.  We should reserve some time one weekend for a virtual sprint,
where we can hammer this out.  Fernando will be visiting in October,
but we may want to make progress before then...

JDH

We've had a significant number of bug-fixes in the release branch, so
this weekend I'm going to try and put out a release candidate for
0.99.1, and perhaps this will be the last release of this branch but
time will tell.  I'll build the tarball and OSX binaries for the
release candidate, and perhaps Christoph can build the win32 binaries
for testing.  If all goes well we can proceed with the release later
next week.

So please take some time to work though bugs and patches on the sf
site -- if 0.99.1 is stable enough, we can live with that until we get
the 1.0 trunk out with the new docstrings, testing, etc...

  http://sourceforge.net/tracker/?group_id=80706&atid=560720
  http://sourceforge.net/tracker/?group_id=80706&atid=560722

JDH

In article <49F...@cs...>,
 Farhan Sheikh <fa...@cs...> wrote:

> Dear all,
> 
> i have python 2.6 running on my mac osx 10.5, however when installing  
> the binary file provided, it says i need to have python 2.6 on my  
> machine. i dont understand why this is happening as when open a new  
> terminal and type 'python', python version 2.6.2 is the version that  
> is run. My supervisor also had a look at this and could not figure it  
> out. He linked python 2.6 with the python command but the install file  
> still did not recognise python 2.6.
> 
> anybody have the same issue? or know of how to fix this issue?
> 
> is there a.tar.gz version so i can build via terminal?
> 
> Thank You
> 
> Farhan

I think that the official Mac binary installer wants Python 2.6.x to be 
a framework build in /Library/Frameworks (e.g. as you would get by 
installing the Mac python at python.org). Unfortunately, there are many 
other pythons, including fink, MacPorts and Apple's preinstalled version 
(which is 2.5.something on MacOS X 10.5, so that's not the problem).

So which python do you have? One way to find out: in Terminal type 
"which python" and tell us the results.

-- Russell

Dear all,

i have python 2.6 running on my mac osx 10.5, however when installing  
the binary file provided, it says i need to have python 2.6 on my  
machine. i dont understand why this is happening as when open a new  
terminal and type 'python', python version 2.6.2 is the version that  
is run. My supervisor also had a look at this and could not figure it  
out. He linked python 2.6 with the python command but the install file  
still did not recognise python 2.6.

anybody have the same issue? or know of how to fix this issue?

is there a.tar.gz version so i can build via terminal?

Thank You

Farhan

-- 
Academic Excellence at the Heart of Scotland.
The University of Stirling is a charity registered in Scotland, 
 number SC 011159.

On 9-Sep-09, at 7:42 AM, Darren Dale wrote:

> I don't think so, there is no extension code associated with the qt
> backend. What platform are you using? Ubuntu/debian, by chance?

Huh, very strange then. I'm running Mac OS X 10.5.7.

Finally got back to this this morning. I realized that I was using
/usr/local as my prefix, and hence my problem with the gfortran
libgcc.

Another important step was to make sure I had removed all previous
results of builds, installs, etc. in the source directory, install
path, site-packages, etc.

The following command works fine, with no modifications to John's
build script and none to the Python framework Makefile.
PREFIX=/usr/local/pydev make -f make.osx fetch deps mpl_install

Thanks to all for their help as I fumbled through this.

-Eric


On Tue, Aug 25, 2009 at 10:19 PM, John Hunter<jd...@gm...> wrote:
> On Tue, Aug 25, 2009 at 9:04 PM, Eric Bruning<eri...@gm...> wrote:
>> Hi Ariel,
>>
>> Thanks for the suggestion. Combining John's new makefile with the
>> changes to the Python.framework Makefile yielded:
>> distutils.errors.DistutilsPlatformError: $MACOSX_DEPLOYMENT_TARGET
>> mismatch: now "10.4" but "10.5" during configure.
>
> What if you edit the mak.osx file and use 10.5 for the
> MACOSX_DEPLOYMENT_TARGET -- I had set it to 10.4 for building the
> installers, but there is no need for that when building from src for a
> local install.
>
> What if you simply remove all references to MACOSX_DEPLOYMENT_TARGET
> in the make.osx file?  Does that work for you?
>

On Tue, Sep 8, 2009 at 11:12 PM, David Warde-Farley<dw...@cs...> wrote:
> Hi Darren,
>
> On 8-Sep-09, at 7:16 PM, Darren Dale wrote:
>
>> I would be very surprised if this is due to the backend. More likely a
>> mismatch between sip and pyqt versions.
>
>
> I actually grabbed both of them yesterday from riverbankcomputing.co.uk,
> PyQt-4.5.4 and sip-4.8.2. Is it possible that the backend is disagreeing
> with these because it was built against an older version? (I'm using
> matplotlib binary releases)

I don't think so, there is no extension code associated with the qt
backend. What platform are you using? Ubuntu/debian, by chance?

Hi Darren,

On 8-Sep-09, at 7:16 PM, Darren Dale wrote:

> I would be very surprised if this is due to the backend. More likely a
> mismatch between sip and pyqt versions.


I actually grabbed both of them yesterday from  
riverbankcomputing.co.uk, PyQt-4.5.4 and sip-4.8.2. Is it possible  
that the backend is disagreeing with these because it was built  
against an older version? (I'm using matplotlib binary releases)

Regards,

David

On Tue, Sep 8, 2009 at 5:57 PM, David Warde-Farley<dw...@cs...> wrote:
> Howdy,
>
> The Qt4 backend appears to be broken in the Mac py2.6 binaries, using
> OS X 10.5.7 and the latest version of the Qt SDK from qt.nokia.com. I
> don't have the machine handy right this second but using plot() from
> an IPython interpreter with my backend set to Qt4Agg causes a hard
> crash for me every single time.
>
> I should note that TraitsBackendQt seems to work fine, so at least
> PyQt doesn't (on the surface) appear to be at the root of it.
>
> I'm wondering if it's a peculiarity of my system. Can anyone reproduce
> this? (this is an Intel Mac, by the way)

I would be very surprised if this is due to the backend. More likely a
mismatch between sip and pyqt versions.

Howdy,

The Qt4 backend appears to be broken in the Mac py2.6 binaries, using  
OS X 10.5.7 and the latest version of the Qt SDK from qt.nokia.com. I  
don't have the machine handy right this second but using plot() from  
an IPython interpreter with my backend set to Qt4Agg causes a hard  
crash for me every single time.

I should note that TraitsBackendQt seems to work fine, so at least  
PyQt doesn't (on the surface) appear to be at the root of it.

I'm wondering if it's a peculiarity of my system. Can anyone reproduce  
this? (this is an Intel Mac, by the way)

David

You also may need to do:

plt.interactive(True)

Cheers,

Brian

On Tue, Sep 8, 2009 at 12:45 PM, Gökhan Sever <gok...@gm...> wrote:

> Hello,
>
> The thread switches will be gone by the release of the new IPython. I am
> assuming that some extra work needs to be done on both sides in preparation
> to the new release. See the following test cases:
>
>
> ### This one locks the IPython unless the figure window is killed. If you
> do an additional plt.show() without a figure is up then you get a complete
> lock-up of the shell.
>
> I[1]: import matplotlib.pyplot as plt
>
> I[2]: %gui qt
>
> I[3]: plt.plot(range(10))
> O[3]: [<matplotlib.lines.Line2D object at 0xab2686c>]
>
> I[4]: plt.show()
>
>
>
>
> ### The following cannot resolve that issue
>
> I[5]: %gui   #disable event loops
>
> I[6]: %gui -a qt
> O[6]: <PyQt4.QtGui.QApplication object at 0xaa477ac>
>
> I[7]: plt.plot(range(10))
> O[7]: [<matplotlib.lines.Line2D object at 0xaf237ac>]
>
> I[8]: plt.show()
>
>
>
> ### In a new IPython, these lines work --no locking after plt.show() "-a"
> makes the difference.
>
> I[1]: import matplotlib.pyplot as plt
>
> I[2]: %gui -a qt
> O[2]: <PyQt4.QtGui.QApplication object at 0x8fdceac>
>
> I[3]: plt.plot(range(10))
> O[3]: [<matplotlib.lines.Line2D object at 0x9a2c84c>]
>
> I[4]: plt.show()
>
>
>
>
> ================================================================================
> Platform     :
> Linux-2.6.29.6-217.2.3.fc11.i686.PAE-i686-with-fedora-11-Leonidas
> Python       : ('CPython', 'tags/r26', '66714')
> IPython      : 0.11.bzr.r1205
> NumPy       : 1.4.0.dev
> Matplotlib   : 1.0.svn
>
> ================================================================================
>
> --
> Gökhan
>
> _______________________________________________
> IPython-dev mailing list
> IPy...@sc...
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>

Hey Gokhan,

thanks for the summary.

On Tue, Sep 8, 2009 at 12:45 PM, Gökhan Sever <gok...@gm...> wrote:
> ### In a new IPython, these lines work --no locking after plt.show() "-a"
> makes the difference.
>
> I[1]: import matplotlib.pyplot as plt
>
> I[2]: %gui -a qt
> O[2]: <PyQt4.QtGui.QApplication object at 0x8fdceac>
>
> I[3]: plt.plot(range(10))
> O[3]: [<matplotlib.lines.Line2D object at 0x9a2c84c>]
>
> I[4]: plt.show()

If you do

plt.ion()

right after you import it, then you don't need to do 'show'
explicitely anymore. Basically what today's '-pylab' does is:

- a bunch of imports
- the equivalent of %gui, but uglier and at startup
- do plt.ion() for you
- patch %run a little so it does ioff() before starting up and ion() at the end.

As you can see, even now with trunk in the state of upheaval it is,
you can get almost all of this back with this snippet.  This is pretty
much what we'll make available built-in when the dust settles (with
the 'import *' being optional, as they are today):

%gui -a qt

import numpy as np
import matplotlib.pyplot as plt
import matplotlib.pylab as pylab
import matplotlib.mlab as mlab

from numpy import *
from matplotlib.pyplot import *

plt.ion()


### END CODE

Cheers,

f

Hello,

The thread switches will be gone by the release of the new IPython. I am
assuming that some extra work needs to be done on both sides in preparation
to the new release. See the following test cases:


### This one locks the IPython unless the figure window is killed. If you do
an additional plt.show() without a figure is up then you get a complete
lock-up of the shell.

I[1]: import matplotlib.pyplot as plt

I[2]: %gui qt

I[3]: plt.plot(range(10))
O[3]: [<matplotlib.lines.Line2D object at 0xab2686c>]

I[4]: plt.show()




### The following cannot resolve that issue

I[5]: %gui   #disable event loops

I[6]: %gui -a qt
O[6]: <PyQt4.QtGui.QApplication object at 0xaa477ac>

I[7]: plt.plot(range(10))
O[7]: [<matplotlib.lines.Line2D object at 0xaf237ac>]

I[8]: plt.show()



### In a new IPython, these lines work --no locking after plt.show() "-a"
makes the difference.

I[1]: import matplotlib.pyplot as plt

I[2]: %gui -a qt
O[2]: <PyQt4.QtGui.QApplication object at 0x8fdceac>

I[3]: plt.plot(range(10))
O[3]: [<matplotlib.lines.Line2D object at 0x9a2c84c>]

I[4]: plt.show()



================================================================================
Platform     :
Linux-2.6.29.6-217.2.3.fc11.i686.PAE-i686-with-fedora-11-Leonidas
Python       : ('CPython', 'tags/r26', '66714')
IPython      : 0.11.bzr.r1205
NumPy       : 1.4.0.dev
Matplotlib   : 1.0.svn
================================================================================

-- 
Gökhan

John Hunter wrote:
> On Tue, Sep 8, 2009 at 12:34 PM, Andrew Straw<str...@as...> wrote:
>   
>> Michael Droettboom wrote:
>>     
>>> More information after another build iteration.
>>>
>>> The two tests that failed after updating to the unhinted images were
>>> subtests of tests that were failing earlier.  If a single test
>>> function outputs multiple images, image comparison stops after the
>>> first mismatched image.  So there's nothing peculiar about these
>>> tests, it's just that the system wasn't saying they were failing
>>> before since they were short-circuited by earlier failures.  I wonder
>>> if it's possible to run through all the images and batch up all the
>>> failures together, so we don't have these "hidden" failures -- might
>>> mean fewer iterations with the buildbots down the road.
>>>       
>> Ahh, good point. I can collect the failures in the image_comparison()
>> decorator and raise one failure that describes all the failed images.
>> Right now the loop that iterates over the images raises an exception on
>> the first failure, which clearly breaks out of the loop. I'd added it to
>> the nascent TODO list, which I'll check into the repo next to
>> _buildbot_test.py.
>>     
>
> Should I hold off on committing the other formatter baselines until
> you have made these changes so you can test, or do you want me to go
> ahead and commit the rest of these now?
>   
Go ahead -- please don't wait for me. I have many means of causing image
comparison failures when the time comes. :)

-Andrew

On Tue, Sep 8, 2009 at 12:34 PM, Andrew Straw<str...@as...> wrote:
> Michael Droettboom wrote:
>> More information after another build iteration.
>>
>> The two tests that failed after updating to the unhinted images were
>> subtests of tests that were failing earlier.  If a single test
>> function outputs multiple images, image comparison stops after the
>> first mismatched image.  So there's nothing peculiar about these
>> tests, it's just that the system wasn't saying they were failing
>> before since they were short-circuited by earlier failures.  I wonder
>> if it's possible to run through all the images and batch up all the
>> failures together, so we don't have these "hidden" failures -- might
>> mean fewer iterations with the buildbots down the road.
> Ahh, good point. I can collect the failures in the image_comparison()
> decorator and raise one failure that describes all the failed images.
> Right now the loop that iterates over the images raises an exception on
> the first failure, which clearly breaks out of the loop. I'd added it to
> the nascent TODO list, which I'll check into the repo next to
> _buildbot_test.py.

Should I hold off on committing the other formatter baselines until
you have made these changes so you can test, or do you want me to go
ahead and commit the rest of these now?

John Hunter wrote:
> I wrote a script at scipy when Andrew and I worked on this to
> recursively move known good actuals into the baselines directory, with
> some yes/no prompting, but it looks like it did not survive the test
> code migration, so we may want to develop something to replace it.
Yes, we do. But I think we should hold off a bit until I get a slightly
better output image hierarchy established. (See my other post for more
detailed thoughts -- our emails crossed in the ether.)

-Andrew

Michael Droettboom wrote:
> More information after another build iteration.
>
> The two tests that failed after updating to the unhinted images were
> subtests of tests that were failing earlier.  If a single test
> function outputs multiple images, image comparison stops after the
> first mismatched image.  So there's nothing peculiar about these
> tests, it's just that the system wasn't saying they were failing
> before since they were short-circuited by earlier failures.  I wonder
> if it's possible to run through all the images and batch up all the
> failures together, so we don't have these "hidden" failures -- might
> mean fewer iterations with the buildbots down the road.
Ahh, good point. I can collect the failures in the image_comparison()
decorator and raise one failure that describes all the failed images.
Right now the loop that iterates over the images raises an exception on
the first failure, which clearly breaks out of the loop. I'd added it to
the nascent TODO list, which I'll check into the repo next to
_buildbot_test.py.
>
> Good news is this does point to having the font problem licked.
Very good news indeed.

More information after another build iteration.

The two tests that failed after updating to the unhinted images were 
subtests of tests that were failing earlier.  If a single test function 
outputs multiple images, image comparison stops after the first 
mismatched image.  So there's nothing peculiar about these tests, it's 
just that the system wasn't saying they were failing before since they 
were short-circuited by earlier failures.  I wonder if it's possible to 
run through all the images and batch up all the failures together, so we 
don't have these "hidden" failures -- might mean fewer iterations with 
the buildbots down the road.

Good news is this does point to having the font problem licked.

Mike

On 09/08/2009 12:47 PM, Michael Droettboom wrote:
> Interesting result.  I pulled all of the new "actual" files from the 21
> failing tests on the buildbots to my local machine and all of those
> tests now pass for me.  Good.  Interestingly, there are still two tests
> failing on my machine which did not fail on the buildbots, so I can't
> grab the buildbots' new output.  Could this just be a thresholding issue
> for the tolerance value? I'm a little wary of "polluting" the baseline
> images with images from my machine which doesn't have our "standard"
> version of Freetype, so I'll leave those out of SVN for now, but will go
> ahead and commit the new baseline images from the buildbots.  Assuming
> these two mystery failures are resolved by pulling new images from the
> buildbots, I think this experiment with turning of hinting is a success.
>
> As an aside, is there an easy way to update the baselines I'm missing?
> At the moment, I'm copying each result file to the correct folder under
> tests/baseline_images, but it takes me a while because I don't know the
> heirarchy by heart and there are 22 failures.  I was expecting to just
> manually verify everything was ok and then "cp *.png" from my scratch
> tests folder to baseline_images and let SVN take care of which files had
> actually changed.  This is just the naive feedback of a new set of eyes:
> it's extremely useful and powerful what you've put together here.
>
> Mike
>
> On 09/08/2009 12:06 PM, Andrew Straw wrote:
>    
>> Michael Droettboom wrote:
>>
>>      
>>> Doing so, my results are even *less* in agreement with the baseline, but
>>> the real question is whether my results are in agreement with those on
>>> the buildbot machines with this change to forcibly turn hinting off.  I
>>> should no pretty quickly when the buildbots start complaining in a few
>>> minutes and I can look at the results ;)
>>>
>>>
>>>        
>> Yes, even though the waterfall is showing green (for the next 2 minutes
>> until my buildbot script bugfix gets run), it's pretty clear from the
>> image failure page that disabling hinting introduced changes to the
>> generated figure appearance. It will be interesting to see if, after
>> checking in the newly generated actual images as the new baseline, the
>> tests start passing on your machine with the newer freetype.
>>
>> In a footnote to myself, I think the ImageComparisonFailure exception
>> should tell nose that the test failed, not that there was an error.
>>
>> -Andrew
>>
>>      
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>    

On Tue, Sep 8, 2009 at 11:47 AM, Michael Droettboom<md...@st...> wrote:
> Interesting result.  I pulled all of the new "actual" files from the 21
> failing tests on the buildbots to my local machine and all of those tests
> now pass for me.  Good.  Interestingly, there are still two tests failing on
> my machine which did not fail on the buildbots, so I can't grab the
> buildbots' new output.  Could this just be a thresholding issue for the
> tolerance value? I'm a little wary of "polluting" the baseline images with
> images from my machine which doesn't have our "standard" version of
> Freetype, so I'll leave those out of SVN for now, but will go ahead and
> commit the new baseline images from the buildbots.  Assuming these two
> mystery failures are resolved by pulling new images from the buildbots, I
> think this experiment with turning of hinting is a success.
>


Are these two images you are referring to the formatter_ticker_002.png
and polar_wrap_360.png failures?  I just committed those from the
actual output on the sage buildbot.  But I am curious why you couldn't
pull these down from the buildbot, eg

  http://mpl.code.astraw.com/hardy-py24-amd64-chroot/formatter_ticker_002/actual.png
  http://mpl.code.astraw.com/hardy-py24-amd64-chroot/polar_wrap_360/actual.gif

> As an aside, is there an easy way to update the baselines I'm missing?  At
> the moment, I'm copying each result file to the correct folder under
> tests/baseline_images, but it takes me a while because I don't know the
> heirarchy by heart and there are 22 failures.  I was expecting to just
> manually verify everything was ok and then "cp *.png" from my scratch tests
> folder to baseline_images and let SVN take care of which files had actually
> changed.  This is just the naive feedback of a new set of eyes: it's
> extremely useful and powerful what you've put together here.

I wrote a script at scipy when Andrew and I worked on this to
recursively move known good actuals into the baselines directory, with
some yes/no prompting, but it looks like it did not survive the test
code migration, so we may want to develop something to replace it.

JDH

Michael Droettboom wrote:
> Interesting result.  I pulled all of the new "actual" files from the 21 
> failing tests on the buildbots to my local machine and all of those 
> tests now pass for me.  Good.  Interestingly, there are still two tests 
> failing on my machine which did not fail on the buildbots, so I can't 
> grab the buildbots' new output.
Well, if they're not failing on the buildbots, that means the baseline
in svn can't be too different than what they generate. But it's a good
point that we want the actual output of the buildbots regardless of
whether the test failed.
>   Could this just be a thresholding issue 
> for the tolerance value? I'm a little wary of "polluting" the baseline 
> images with images from my machine which doesn't have our "standard" 
> version of Freetype, so I'll leave those out of SVN for now, but will go 
> ahead and commit the new baseline images from the buildbots.
Looking at the 2 images failing on the buildbots, I'm reasonably sure
they were generated by James Evans when he created the first test
infrastructure. So I say go ahead an check in the actual images
generated by the buildbots. (Or did you recently re-upload those images?)
>   Assuming 
> these two mystery failures are resolved by pulling new images from the 
> buildbots, I think this experiment with turning of hinting is a success.
>   
Yes, I think so, too. I was going to suggest getting on the freetype
email list to ask them about their opinion on what we're doing.
> As an aside, is there an easy way to update the baselines I'm missing?  
> At the moment, I'm copying each result file to the correct folder under 
> tests/baseline_images, but it takes me a while because I don't know the 
> heirarchy by heart and there are 22 failures.  I was expecting to just 
> manually verify everything was ok and then "cp *.png" from my scratch 
> tests folder to baseline_images and let SVN take care of which files had 
> actually changed.
Unfortunately, there's no easy baseline update yet. John wrote one for
the old test infrastructure, but I ended up dropping that in the
switchover to the simplified infrastructure. The reason was that the
image comparison mechanism, and the directories to which they were
saved, changed, and thus his script would have require a re-working.
Given that I don't consider the current mechanism for this particularly
good, I was hesitant to invest the effort to port over support for a
crappy layout.

(The trouble with the current actual/baseline/diff result gathering
mechanism is that it uses the filesystem as a means for communication
withing the nose test running process in addition to communication with
the buildbot process through hard-coded assumptions about paths and
filenames. If the only concern was within nose, we could presumably
re-work some the old MplNoseTester plugin to handle the new case, but
given the buildbot consideration it gets more difficult to get these
frameworks talking through supported API calls. Thus, although the
hardcoded path and filename stuff is a hack, it will require some
serious nose and buildbot learning to figure out how to do it the
"right" way. So I'm all for sticking with the hack right now, and making
a bit nicer by doing things like having a better directory hierarchy
layout for the actual result images.)
>   This is just the naive feedback of a new set of eyes: 
> it's extremely useful and powerful what you've put together here.
>   
Thanks for the feedback.

The goal is that Joe Dev would think it's easy and useful and thus start
using it. Tests should be simple to write and run so that we actually do
that. Like I wrote earlier, by keeping the tests themselves simple and
clean, I hope we can improve the testing infrastructure mostly
independently of changes to the tests themselves.

-Andrew