Re: [matplotlib-devel] new site is live!

[Andrew Straw]

Dang that looks good. The only glitches that I see are:

1) after the ">>> hist(x, 100)""" line in the Python pre-formatted text
box, there's an extra line's worth of vertical space.

2) The heading "Plotting commands" overlaps slightly with the top line
of the following table.

This is on Firefox 3 with Ubuntu 8.04.

-Andrew


John Hunter wrote:
> I just took the plunge and pushed the beta website live.  We are now
> purely driven off the sphinx living in the doc dir.
> 
> There is still plenty of material from the old site (stuff from the
> FAQ, the credits, stuff from the user's guide, goals/known issues) so
> once again please feel free to contribute.  It's much easier now that
> it is plain rest and sphinx.  One area where all developers can easily
> contribute is by extending the FAQ when we get common questions on the
> mailing lists.  I would also really like to see sections on contours,
> images and colormaps, colorbars, time series plotting (eg the spectral
> stuff), collections
> 
>   http://matplotlib.sourceforge.net
> 
> Let me know if you find any problems.
> 
> JDH
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Repeating docs

[Andrew Straw]

Ryan May wrote:
> John Hunter wrote:
>   
>> On Tue, Nov 11, 2008 at 1:38 PM, Ryan May <[EMAIL PROTECTED]> wrote:
>>
>> 
>>> 1) Have psd(x) call csd(x,x)
>>> 2) Have csd() check if y is x, and if so, avoid doing the extra work.
>>>
>>> Would this be an acceptable solution to reduce code duplication?
>>>   
>> Sure, that should work fine.
>> 
>
> Ok, I noticed that specgram() duplicated much of the same code, so I
> factored it all out and made a _spectral_helper() function, which pretty
> much implements a cross-spectrogram.  csd() and specgram() use this, and
> then psd still calls csd().  Now all of the spectral analysis stuff is
> using the same computational code base.
>
>   
>>> On a separate note, once I get done with these tweaks, are there any
>>> objections to submitting something based on this to scipy?
>>>   
>> No objections here -- if it were put into numpy though, we could
>> depend on it and avoid the duplication.  I would campaign for numpy
>> first, eg np.fft.psd, etc.
>> 
>
> I agree it'd be better for us if it went to numpy, but I've gotten the
> sense that they're not really receptive to adding things like this now.
> I'll give it a try, but I sense that scipy.signal would end up being a
> more likely home.  That wouldn't help us with duplication, but would
> help the community at large.  It's always bugged me that I can't just
> grab a psd() function from my general computing packages. (In my
> opinion, anything in mlab that doesn't involve plotting should really
> exist in a more general package.)
There's an interesting case to be made here for modules shared between
packages at the version-control-system and bug tracking level (e.g. in a
DVCS type system) but installed in separate namespaces and shipped
independently when it was time for source and binary distributions of
the package to be made. There'd be duplication at the install and
distribution level, but at least not at the source level. I'd guess the
linux packagers would also find a way to reduce duplication at those
other levels, too, for their systems.

It seems to me that this would reduce a lot of the developer angst about
having multiple sources for the same things, while still making things
easy on the users.

However, I don't know any VCS that would facilitate such a thing...

-Andrew

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Custom-sized and spanning subplots

[Andrew Straw]

Hi Stan,

You may want to have a look at the mplsizer MPL toolkit I wrote a long
time ago and have failed to properly advertise or maintain. But, it does
much of what you propose by emulating wx sizers for matplotlib. Anyhow,
this is available by svn checkout from
https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/toolkits/mplsizer

I'd be happy if you wanted to take over the project and push it forward,
but I also understand if you have other implementation ideas. (The wx
API is not to everyone's taste, for one thing.)

-Andrew

Stan West wrote:
> Hello, all. I'd like to add to matplotlib facilities for (a)
> conveniently specifying the relative sizes of subplots, and (b) creating
> subplots that span cells of the subplot grid. For example, to obtain a
> column of three subplots with the last one 50% taller than the other
> two, the user would provide [1, 1, 1.5] as a row size parameter, and
> matplotlib would calculate the appropriate axes positions. An example of
> spanning using the current machinery is the mri_with_eeg
> 
> example. Are these features of interest?
> 
> The calculation code was easy to write, but I'd like input on how it can
> best be implemented and accessed by users. One issue is where the
> relative sizes should be stored. Presently, while figures hold
> information about the margins around and between their subplots, as far
> as I can tell they are unaware of any grid structure among their
> subplots (although they do track as keys the arguments to add_subplot).
> Grid dimensions are instead stored with each axes along with the
> position of the axes within the grid. (The fact that the grid dimensions
> need not agree among all of the axes in a figure allows for layouts like
> mri_with_eeg. However, pushing that too far can yield unattractive
> results: The axes specified by "subplot(2, 2, 1); subplot(2, 4, 5);
> subplot(2, 4, 6)" are misaligned unless wspace = 0, a consequence of how
> the wspace parameter is interpreted. A new spanning mechanism should
> yield aligned axes.)
> 
> A second issue is that the numbers of rows and columns are
> overdetermined, being specified explicitly by the arguments to subplot
> and implicitly by the lengths of the lists containing the custom sizes.
> 
> Considering those issues, I thought of a few possible approaches for
> specifying custom row and column sizes:
> 
> A. Store the row and column sizes in the instance of
> figure.SubplotParams held in the figure's subplotpars attribute. User
> code would look something like the following, using an example kwarg
> row_sizes:
> 
> fig = figure(subplotpars=mpl.figure.SubplotParams(row_sizes=[1, 1,
> 1.5]))
> fig.add_subplot(3, 1, 1)  # etc.
> fig.subplots_adjust(row_sizes=[1, 1, 3])  # resize the subplots
> 
> There would be corresponding pyplot functionality. This approach allows
> the user to manage the sizes at the figure level (which I consider
> convenient), but only one set of sizes is accommodated. One way to
> handle the overspecified grid dimensions is a conflict-resolution
> scheme. For example, in axes.SubplotBase.update_params, if the number of
> rows (originating in the subplot call) matches the length of the
> figure's row specifier, then honor the custom row sizes, and likewise
> for columns. Otherwise, either (a) raise an error, or (b) fall back to
> using equal rows (or columns) but send a message to verbose.report at
> some debug level. If no custom sizes are specified, then everything
> operates as now and no errors nor verbose.report messages will be
> generated. Because the numbers of rows and columns are stored with the
> axes, each axes would handle the conflict resolution independently of
> the other axes. Another scheme (which I like better) would introduce
> alternative subplot syntax such as add_subplot(row, col), where row and
> col are numbered Python-style from 0. That form would cause the subplot
> to inherit the numbers of rows and columns and the custom sizes in
> fig.subplotpars, whereas the current forms would use only equally-sized
> subplots. The new form also relieves the user of constructing the
> Matlab-style single subplot number.
> 
> B. Instead of the above, associate the size information with the axes.
> User code might resemble
> 
> fig = figure()
> fig.add_subplot(2, 2, 1, col_sizes=[3, 1])  # ++ ++
> fig.add_subplot(2, 2, 2, col_sizes=[3, 1])  # ++ ++
> fig.add_subplot(2, 2, 3, col_sizes=[1, 3])  # ++ ++
> fig.add_subplot(2, 2, 4, col_sizes=[1, 3])  # ++ ++
> 
> This continues the current ability to create different grids (different
> numbers of rows and columns, only now with different row and column
> sizes) within the same figure, but they're managed at the axes level.
> Resizing in this approach would need to be performed with each affected
> axes, or a figure-level method could walk the child axes (possibly
> c

[matplotlib-devel] any git clones of the MPL svn repo out there?

[Andrew Straw]

Since using git for some time on several projects (including projects
with a central svn repository), it's been hard to go back to the
universally slow web-based subversion history browsers and the absence
of 'git bisect'. Thus, I'm thinking about cloning the MPL SVN history
into a git repo, but I wonder if anyone has already done this? Are there
any git clones of the MPL svn repo out there?

Thanks,
Andrew

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] markersize change

[Andrew Straw]

John Hunter wrote:
> On Sat, Nov 29, 2008 at 3:55 PM, Andrew Straw <[EMAIL PROTECTED]> wrote:
>> Hi All,
>>
>> I have been testing the latest svn matplotlib, which failed to produce
>> any visible data in some long-standing scripts of mine. :(
>>
>> Investigating further, my use of markersize=0.5 combined with the '.'
>> symbol and the Agg backend caused a complete disappearance of the
>> markers. I'm attaching example images from 0.93.3 and the most recent
>> SVN using the attached script.
>>
>> I'd be happy to track this down, but I think this might be a no-brainer
>> for someone on the list.
> 
> Is this agg only?

It doesn't happen with PS or SVG, so I'll say yes.

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] markersize change

[Andrew Straw]

Hi Mike,

That does fix the issue. Another thing I noticed that is fixed with your
patch: the '.' marks appear like '+' when drawn at a smallish size.

Thanks,
Andrew

Michael Droettboom wrote:
> This might be related to a change I made in the Agg backend to make the
> markers look better by rounding their coordinates to the nearest pixel. 
> It certainly made the stock markers at a standard size look better, but
> I suspect as they get smaller, they are converging down to the same
> value, thus having a truly zero-sized marker.
> 
> I'm away from a machine with build tools at the moment, so can't
> confirm.  Does the attached patch work for you?
> 
> Mike
> 
> Andrew Straw wrote:
>> John Hunter wrote:
>>  
>>> On Sat, Nov 29, 2008 at 3:55 PM, Andrew Straw <[EMAIL PROTECTED]>
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I have been testing the latest svn matplotlib, which failed to produce
>>>> any visible data in some long-standing scripts of mine. :(
>>>>
>>>> Investigating further, my use of markersize=0.5 combined with the '.'
>>>> symbol and the Agg backend caused a complete disappearance of the
>>>> markers. I'm attaching example images from 0.93.3 and the most recent
>>>> SVN using the attached script.
>>>>
>>>> I'd be happy to track this down, but I think this might be a no-brainer
>>>> for someone on the list.
>>>>   
>>> Is this agg only?
>>> 
>>
>> It doesn't happen with PS or SVG, so I'll say yes.
>>
>> -
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>   
> 
> 
> 
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
> 
> 
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] any git clones of the MPL svn repo out there?

[Andrew Straw]

I used rsync to mirror the entire SVN repo locally and then using "git
svn clone" to import it (which took about 12 hours on a 2.5 GHz Core 2
machine, even with the local SVN mirror).

I haven't been able to clone the new git repo such that the 2nd git copy
would not need to do "git svn fetch" on the entire repository. Thus, it
seems that putting my git svn mirror in a publicly accessible location
isn't actually going to save anyone the pain of letting git call
subversion a bazillion times to import all history. (At least not
without me understanding things like
http://utsl.gen.nz/talks/git-svn/intro.html#howto-track-rebuildmeta )

I'll plan to use my local git repository to interact with the MPL svn
repo, but I don't plan to publish my git repo unless I figure out how to
set it up so it's actually useful. Until or unless that happens, here's
how I cloned the MPL repo:

# Directories
MPL_RSYNC_DIR="/mnt/workdisk/tmp/matplotlib-svn-rsync"
MPL_GIT_DIR="/mnt/workdisk/tmp/matplotlib"

# Copy the svn repo history locally
mkdir -p $MPL_RSYNC_DIR
cd $MPL_RSYNC_DIR
rsync -av matplotlib.svn.sourceforge.net::svn/matplotlib/* .

# Import into git
mkdir -p $MPL_GIT_DIR
cd $MPL_GIT_DIR
git svn clone --trunk=trunk/matplotlib --tags=tags \
 file://$MPL_RSYNC_DIR

At this point, you should have a shiny new git MPL repo in $MPL_GIT_DIR
suitable for use with git, including two of my favorites, git bisect and
gitk. However, to update from svn without going through the rsync
intermediate and to commit directly to the svn repo, you need to do the
equivalent of "svn switch --relocate" to point your git repo at the
SourceForge svn https URL rather than your local rsync copy. I'm at the
mercy of my google searching skills here because I don't understand how
git-svn works, but I followed the recipe at
http://www.ciaran-lee.com/articles/6 . Here it is modified to be
specific for this case:

* In the [svn-remote "svn"] section of $MPL_GIT_DIR/.git/config, change
the url to https://matplotlib.svn.sourceforge.net/svnroot/matplotlib
(but note the old file:/// URL -- you'll need that in a minute).

* (I think a commit has to have been made to the SourceForge SVN repo
for this next step to work. Somewhere in this recipe this has to happen,
and I forgot exactly where.)

* Run "git svn fetch" in $MPL_GIT_DIR

* Change the svn-remote url back to the original file:///

* Run "git svn rebase -l" to do a local rebase (with the changes that
came in with the last fetch operation)

* Change svn-remote url back to the new url.

* "git svn rebase" and "git svn dcommit" should now work.

Finally, a couple URLs that are useful for git-svn interaction:

* http://andy.delcambre.com/2008/3/4/git-svn-workflow
* http://git.or.cz/course/svn.html

And the man page:

* http://www.kernel.org/pub/software/scm/git/docs/git-svn.html

Note that I'd actually suggest getting moderately comfortable with pure
git before attempting to do git/svn juggling. I suggest playing with the
sympy git repository: git clone git://git.sympy.org/sympy.git

Michael Droettboom wrote:
> I don't know of any, but if you create one let us know.  I'd be 
> interested in playing with such a thing.  I'm ready to see what all the 
> fuss is about... ;)
> 
> Mike
> 
> Andrew Straw wrote:
>> Since using git for some time on several projects (including projects
>> with a central svn repository), it's been hard to go back to the
>> universally slow web-based subversion history browsers and the absence
>> of 'git bisect'. Thus, I'm thinking about cloning the MPL SVN history
>> into a git repo, but I wonder if anyone has already done this? Are there
>> any git clones of the MPL svn repo out there?
>>
>> Thanks,
>> Andrew
>>
>> -
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>   
> 
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/red

Re: [matplotlib-devel] reimplemented legend class

[Andrew Straw]

John Hunter wrote:
> On Sun, Nov 30, 2008 at 11:53 AM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote:
>
>   
>> I have been working on reimplementation of the legend class, and I
>> guess it is mostly done. The biggest change is how each items are
>> placed. For this, I made a simple container class("offsetbox.py"),
>> which can pack the mpl artists in a similar way as widget packing in
>> gtk, tk, etc.
>> 
>
> Hi Jae-Joon -- as usual this is great work, and brings one of the
> oldest, hairiest, parts of the code into the modern age.  I went ahead
> and committed this to svn r6461 with some minor spelling corrections,
> but I have some minor comments below which may be worth addressing in
> a revision.
>
> Aside from the legend enhancement, the important and general piece
> here is the offset box, which  could become a significant piece of the
> low-level infrastructure (eg for axes layout)  so I do want to make
> sure we get this right.  In particular, I'd like Andrew Straw, who has
> a toolkit for sizers, and Michael Droettboom, who implemented the
> Knuth boxes in support of mathtext, to take a look at the API and
> provide some feedback as to whether if it looks sufficient.
>   
Hi Jae-Joon and John,

The MPL sizer toolkits looks entirely unaffected by these changes, and
the demo looks very convincing. So from my perspective this would be a
benefit to have in assuming that the issues John raises can be dealt with.

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] experimental MPL git mirror online

[Andrew Straw]

I just put my git mirror of the matplotlib svn repository online. This
is experimental in nature. Thanks to github for hosting this project.
Anyhow, I added instructions for how to use this (including to interact
with the central svn repository) here:

http://github.com/astraw/matplotlib/tree/master/README.git

Note that the initial downloads are about 150 MB in size.

I have not actually used git in collaboration with others save through
the svn interface, so I don't have experience with some aspects of git,
particularly collaborating branching/merging/pushing etc. For
single-user use, however, I've been finding all that stuff very nice.
One thing particularly useful is the ability to clean up history before
committing changes to a central subversion repository.

Anyhow, thanks to Ondrej for the critical clue for how to make this work.

-Andrew

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] experimental MPL git mirror online

[Andrew Straw]

Hi John,

Michael just wrote me that he got the same error. I think that perhaps I
need to assign write permissions even to read using the "personal" URL.
For now, can you try the public clone URL
git://github.com/astraw/matplotlib.git instead? I will attempt to sort
this out... (And of course give you and Michael and anyone else write
permissions if need be.) I'm new to git in a multi-developer context and
 git-svn may add another layer here, so please bear with me.

-Andrew

John Hunter wrote:
> On Wed, Dec 3, 2008 at 8:12 PM, Andrew Straw <[EMAIL PROTECTED]> wrote:
>> I just put my git mirror of the matplotlib svn repository online. This
>> is experimental in nature. Thanks to github for hosting this project.
>> Anyhow, I added instructions for how to use this (including to interact
>> with the central svn repository) here:
>>
>> http://github.com/astraw/matplotlib/tree/master/README.git
>>
>> Note that the initial downloads are about 150 MB in size.
> 
> 
> Just got an account, but am getting a permission denied on the first
> command.  I tried both with the "git" and "jdh2358" users:
> 
> home:~> git clone [EMAIL PROTECTED]:astraw/matplotlib.git mpl.git
> Initialized empty Git repository in /Users/jdhunter/mpl.git/.git/
> ERROR: Permission to astraw/matplotlib denied to jdh2358.
> fatal: The remote end hung up unexpectedly
> home:~> git clone [EMAIL PROTECTED]:astraw/matplotlib.git mpl.git
> Initialized empty Git repository in /Users/jdhunter/mpl.git/.git/
> Permission denied (publickey).
> fatal: The remote end hung up unexpectedly
> 
> JDH


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] experimental MPL git mirror online

[Andrew Straw]

I updated the documentation to hopefully address the issue that John
(and Michael) had. I also moved the git documentation to a section in
doc/faq/installing_faq.rst.

And I noticed that github does automatic parsing of rst files. Check
this out -- Sweet! :)
http://github.com/astraw/matplotlib/tree/master/doc/faq/installing_faq.rst#install-from-git

Note that there is a section called "A note about git write access"
which outlines an issue we may want to address, but probably only after
some familiarity with the issues involved. For now, for me, even a
one-way sync of the svn repo is a huge win for looking at history
locally and doing "git bisect". (And "one-way sync" doesn't give justice
to the ease of committing to the svn repository from git.)

-Andrew


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Status of pylab example loadrec.py

[Andrew Straw]

Hi Nils. I think I fixed the issue causing the traceback with r6563. Can
you please update and try again with text.usetex enabled?

My guess is that you don't have dvipng installed, which was causing the
detection check to throw a traceback rather than return a value
signifying undetected. So, enabling usetex should again trigger the
check, but hopefully this time it will fail gracefully rather than crashing.

-Andrew

Nils Wagner wrote:
> On Thu, 11 Dec 2008 09:13:02 +0100
>   "Nils Wagner"  wrote:
>> On Wed, 10 Dec 2008 21:11:12 -0600
>>  "John Hunter"  wrote:
>>> On Wed, Dec 10, 2008 at 4:26 PM, John Hunter 
>>>  wrote:
>>>
> Is it planned to adapt the example wrt xlwt ?
>
> http://pypi.python.org/pypi/xlwt
>

 True it is no longer maintained, but it does work.  We 
 are looking into
 xlwt (I wasn't aware of it until today when you 
 forwarded the message)

>>> I've added support for xlwt in svn r6560  -- give it a 
>>> whirl
>>>
>>> JDH
>> Hi John,
>>
>> I have upgraded to r6561.
>>
>> python test.py --verbose-helpful
>> $HOME=/data/home/nwagner
>> CONFIGDIR=/data/home/nwagner/.matplotlib
>> matplotlib data path 
>> /data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/mpl-data
>> loaded rc file 
>> /data/home/nwagner/.matplotlib/matplotlibrc
>> Traceback (most recent call last):
>>   File "test.py", line 1, in 
>> import matplotlib.mlab as mlab
>>   File 
>> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py",
>>  
>> line 700, in 
>> rcParams['text.usetex'] = 
>> checkdep_usetex(rcParams['text.usetex'])
>>   File 
>> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py",
>>  
>> line 367, in checkdep_usetex
>> dvipng_v = checkdep_dvipng()
>>   File 
>> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py",
>>  
>> line 261, in checkdep_dvipng
>> stderr=subprocess.PIPE)
>>   File 
>> "/data/home/nwagner/local/lib/python2.5/subprocess.py", 
>> line 593, in __init__
>> errread, errwrite)
>>   File 
>> "/data/home/nwagner/local/lib/python2.5/subprocess.py", 
>> line 1079, in _execute_child
>> raise child_exception
>> OSError: [Errno 2] No such file or directory
>>  
>>
>> Any idea ?
>>
>> Nils
>>
>   
> Works for me if I disable text.usetex in 
> ~/.matplotlib/matplotlibrc, but for what reason ?
> 
> 
> ### LaTeX customizations. See 
> http://www.scipy.org/Wiki/Cookbook/Matplotlib/UsingTex
> #text.usetex : True   # use latex for all text 
> handling. The following fonts
> 
> Nils
> 
> --
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] requesting permission to remove traits and configobj

[Andrew Straw]

Michael Droettboom wrote:
> Darren Dale wrote:
>   
>> Having worked with bzr and launchpad for a few months now, I wonder if 
>> we might consider such an approach in the future. I know there has 
>> been some experimentation with a git repository, is git supported on 
>> windows now?
>> 
> I'm not sold that bzr/hg/git makes things simpler for this development 
> model.
My thought is that matplotlib.sourceforge.net is a centralized website
making centralized, official releases and other  centralized facilities.
Thus, it seems to me that a centralized, official version control branch
is an entirely reasonable thing to have. svn provides a
least-common-denominator for this job, and I don't see the reasons to
shift to bzr/hg/git as sufficiently strong to merit such a shift. In
particular, the svn model is pretty darn simple, and therefore easy to
interface with (whether you're a human or a computer program).

Of course, part of why I think this way is that git seems to be working
pretty well for inter-operation with the official svn repository. My
experimental repository, described at
http://matplotlib.sourceforge.net/faq/installing_faq.html#install-from-git
, is nicely allowing me to browse history locally, do git bisect,
maintain my own branches, commit back to the svn repository when
desired, and so on. I think there *may* be some impedance mis-matching
if we tried to really map git branches on svnmerge branches, but right
now that hasn't been an issue I've pursued.

As far as git on Windows: I think there's some kind of msys git and also
the cygwin approach. Not using windows much, though, I'm not sure. I did
hear that Microsoft just started using github for ironruby, so
presumably something works for them.


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git questions

[Andrew Straw]

Hi Michael,

The main issue is that we can't use git "normally" because the main
history will be kept with svn. Thus, there's going to be a lot of
history rewriting going on through the rebase command. (These
complications are obviously not the ideal scenario for git newbies...)
Rather than answer your questions directly, I'll walk you through how I
do things. (This is not tried on the MPL svn repo, but some a private
svn repo. I don't see any fundamental differences, though. So this
should work.)

(Hopefully this will be cut-and-pasteable ReST, which could go in the
docs somewhere):

Making a git feature branch and committing to svn trunk
---

Start with a virgin tree in sync with the svn trunk on the git branch
"master"::

  git checkout master
  git svn rebase

To create a new, local branch called "whizbang-branch"::

  git checkout -b whizbang-branch

Do make commits to the local branch::

  # hack on a bunch of files
  git add bunch of files
  git commit -m "modified a bunch of files"
  # repeat this as necessary

Now, go back to the master branch and append the history of your branch
to the master branch, which will end up as the svn trunk::

  git checkout master
  git svn rebase # Ensure we have most recent svn
  git rebase whizbang-branch # Append whizbang changes to master branch
  git svn dcommit -n # Check that this will apply to svn
  git svn dcommit # Actually apply to svn

Finally, you may want to continue working on your whizbang-branch, so
rebase it to the new master::

  git checkout whizbang-branch
  git rebase master

Michael Droettboom wrote:
> This is mostly for Andrew Straw, but thought anyone else experimenting
> with git may be interested.  I'm going through some real newbie pains
> here, and I don't think what I'm doing is all that advanced.
> 
> So, I've had a local git repository cloned from github (as per Andrew's
> instructions), made a branch, started hacking, all is well.  Now, I
> would like to update my master branch from SVN to get some of the recent
> changes others have been making.
> 
> Following the instructions in the FAQ,
> 
>  git svn rebase
> 
> actually results in a number of conflicts in files I didn't touch.  I
> shouldn't have to resolve this conflicts, right?  'git status' shows no
> local changes, nothing staged -- nothing that should conflict.
> 
> It turns out, if I do
> 
>   git pull
> 
> then,
> 
>   git svn rebase
> 
> all is well.
> 
> Any idea why?  Should I add that to the instructions in the FAQ?
> 
> Now, here's where I'm really stumped.  I finished my experimental
> branch, and I would like to commit it back to SVN.
> 
> This is what I did, with comments preceded by '#'
> 
> # Go back to the master branch
>> git checkout master
> # Merge in experimental
>> git merge experimental
> # Ok -- looks good: experimental new feature is integrated, there were
> no conflicts
> # However...
>> git svn dcommit
> Committing to
> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib
> ...
> Merge conflict during commit: File or directory
> 'doc/users/whats_new.rst' is out of date; try updating: resource out of
> date; try updating at /home/mdroe/usr/libexec/git-core//git-svn line 467
> # 1) I didn't change that file, why should I care
> # 2) I don't know who to update it
>> git pull
> Already up-to-date.
>> git svn rebase
> First, rewinding head to replay your work on top of it...
> Applying: more doc adds
> /home/mdroe/builds/matplotlib.git/.git/rebase-apply/patch:14: trailing
> whitespace.
> a lot of new features and bug-fixes. warning: 1 line adds whitespace
> errors.
> Applying: added some docs for linestyles and markers
> Applying: Remove trailing whitespace.
> Applying: figure/subplot and font_manager bugfixes
> Applying: added support for xlwt in exceltools
> Applying: fixed a typo in whats_new_98_4_legend.py
> Applying: fixed typo in Line2D.set_marker doc.
> Applying: /matplotlib/__init__.py: catch OSError when calling subprocess.
> Applying: more doc adds
> /home/mdroe/builds/matplotlib.git/.git/rebase-apply/patch:14: trailing
> whitespace.
> a lot of new features and bug-fixes. error: patch failed:
> doc/users/whats_new.rst:10
> error: doc/users/whats_new.rst: patch does not apply
> Using index info to reconstruct a base tree...
> :14: trailing whitespace.
> a lot of new features and bug-fixes. warning: 1 line adds whitespace
> errors.
> Falling back to patching base and 3-way merge...
> No changes -- Patch already applied.
> Applying: added some docs for linestyles and markers
> erro

Re: [matplotlib-devel] git questions

[Andrew Straw]

Andrew Straw wrote:

I realize I may have ignored an important question.

> Michael Droettboom wrote:

>> Now I feel stuck.  How do I "undo" the merge from experimental to master?

To do that, I actually delete the master branch with "git branch -D
master" and then re-create a new one with "git checkout -b master
028a0df8" (where I've identified commit 028a0df8 as where I want the new
master to be).

Note that before deleting the master branch, it's probably wise to
create a branch, which will probably be deleted momentarily, as a
reference to this location in case you need to get back to it. Do so
with "git checkout -b tmp/old-master". When everything is done, use "git
branch -D tmp/old-master" to delete it.

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] requesting permission to remove traits and configobj

[Andrew Straw]

I have also developed some image-based unit tests to compare MPL output,
and I completely agree that getting something like this into MPL is a
very good idea. As Ted writes, the hard part is defining "close" for
images. Minor changes to, for example, agg pixel alignment, cause the
tests to fail when they have low tolerances. So, such tests are a bit
more interactive than plain old unit tests when something changes, but I
think that's worth the pain.

Prabhu Ramachandran has also done similar things for mayavi2 using VTK's
image comparison (see compare_image_with_saved_image in
https://svn.enthought.com/enthought/browser/Mayavi/trunk/integrationtests/mayavi/common.py
).

I'm attaching the code I use to compare images as a starting point -- it
currently uses scipy to load the images, but this could surely be worked
around.

-Andrew

Drain, Theodore R wrote:
> John,
> 
> One thing that would help w/ a rapid delivery/response cycle would be
> more comprehensive tests.They would let other developers try out
> various ideas and see what breaks before you release it.
> 
>  
> 
> We’ve implemented an automated approach where we run an MPL script using
> Agg, save the output image and then compare it against a “good” image
> that someone looked at.  We use PIL to do the compare and if it’s close
> (that’s the hard part), then the test passes.  If it’s not, someone
> looks at the two images to see if the difference is benign.  Something
> similar to this could be done (if you’re not already) for the MPL
> examples to make sure that changes don’t cause plotting problems in
> other areas. 
> 
>  
> 
> Having this kind of system is also a great driver for people to expand
> it.  For example – we really care about unit processing support
> everywhere.  Every once in awhile, we find a change that someone submits
> that breaks unit support.  So once of the tasks we‘re going to work on
> next year is to build a set of automated test cases that try and hit
> every plot function with units which can then run on every release.  If
> there were a simple to use MPL standard test system like this, other
> people might contribute more tests as a way of insuring that the things
> they care about stay working through various changes.
> 
>  
> 
> It would also be nice to have a test system for unit testing of
> components.  A lot of the code that does different transformations,
> symbol and color mapping, etc etc could be unit tested without the need
> for actually drawing anything.  If there was a standard location, style,
> and system, people could slowly add to the tests over time.  You can
> also consider requiring some level of unit test for newly submitted code
> where ever it’s possible.
> 
>  
> 
> Just some thoughts…
> 
> Ted
> 
>  
> 
> *From:* John Hunter [mailto:jdh2...@gmail.com]
> *Sent:* Wednesday, December 10, 2008 8:10 PM
> *To:* Darren Dale
> *Cc:* matplotlib-devel@lists.sourceforge.net
> *Subject:* Re: [matplotlib-devel] requesting permission to remove traits
> and configobj
> 
>  
> 
>  
> 
> On Wed, Dec 10, 2008 at 9:20 PM, Darren Dale  > wrote:
> 
> There has been a report at the bugtracker complaining that matplotlib is
> overwriting an existing installation of configobj. I had a look at the
> code and thought the bug report must be a mistake or windows specific,
> but I just saw similar behavior on my linux system.
> 
> 
> Ignoring for a minute the question of whether we can/should flush
> configobj/traits, it sounds like the real problem is that setup.cfg is
> not working like we expect it to.  And that is something that should be
> fixed if is broken.  If mpl is installing configobj or traits even if we
> are telling it not to via setup.cfg, then we have a problem.   This is
> worth knowing, since the last mpl release was broken vis-a-vis the
> default backend on win32, which *could* be explained by a broken setup.cfg.
> 
> I would like to simply remove configobj and traits from our
> repository. They are only used by the long-neglected experimental
> traited config package, which is only of interest to developers who
> can easily install them as external dependencies. Is it ok to remove
> them? If so, should it be done on all the branches?
> 
> How long are we going to continue to maintain the different
> branches? It was so much easier back when we only had to worry about
> the trunk...
> 
> 
> You can remove them from the trunk.  They should remain on the 0.91
> branch as is (with any known bugs fixed and merged) since that is the
> point of the branch (stability for those who cannot upgrade -- in
> principle someone might be depending on the traited config, in practice
> unlikely).  As for the 0.98 branch, it is slated for destruction so no
> worries.  I share your visceral reaction against branches, but my head
> is starting to override this bodily reaction, as I see the need for them
> in practice.  If we carefully document the best practi

Re: [matplotlib-devel] git questions

[Andrew Straw]

Hi Mike,

I have not imported the branches. ( IIRC, this was there were several
that weren't MPL but other parts of the repo such as py4science,
toolkits and so on).  It may be possible to add just the 0.98.5
maintenance branch without the others, but I won't have a chance
immediately to play around with that.

To add all the branches to your git repo, you might be able to add
something like "branches = branches/*:refs/remotes/branches/*" to the
[svn-remote "svn"] section of .git/config and re-do "git svn fetch"...
This will grab all the branches over all svn history, which will, I
think, pull in py4science and toolkits branches... And I guess the
download time from svn will be extremely long... In that case it's
probably better to rsync from sourceforge's server to a local disk and
do the git svn checkout that way making a whole new git repo.

It may be worth attempting to talk to some real git/svn gurus at this
point about tracking (only one or a couple) svn branches with git
branches. So far, I've only dealt with the trunk in my git/svn
interoperation experience.

-Andrew

Michael Droettboom wrote:
> Thanks.  I've incorporated your docs into the developer documentation.
> 
> My next experiment will be to see if I can track the 0.98.5 maintenance 
> branch with git.  SVN tags/* show up as available remote branches, but 
> not branches/*, which leaves me a bit stumped?  If you've done this and 
> there's a quick answer, let me know, otherwise I'll do a little digging 
> to see if it's possible.
> 
> Mike
> 
> Andrew Straw wrote:
>> Hi Michael,
>>
>> The main issue is that we can't use git "normally" because the main
>> history will be kept with svn. Thus, there's going to be a lot of
>> history rewriting going on through the rebase command. (These
>> complications are obviously not the ideal scenario for git newbies...)
>> Rather than answer your questions directly, I'll walk you through how I
>> do things. (This is not tried on the MPL svn repo, but some a private
>> svn repo. I don't see any fundamental differences, though. So this
>> should work.)
>>
>> (Hopefully this will be cut-and-pasteable ReST, which could go in the
>> docs somewhere):
>>
>> Making a git feature branch and committing to svn trunk
>> ---
>>
>> Start with a virgin tree in sync with the svn trunk on the git branch
>> "master"::
>>
>>   git checkout master
>>   git svn rebase
>>
>> To create a new, local branch called "whizbang-branch"::
>>
>>   git checkout -b whizbang-branch
>>
>> Do make commits to the local branch::
>>
>>   # hack on a bunch of files
>>   git add bunch of files
>>   git commit -m "modified a bunch of files"
>>   # repeat this as necessary
>>
>> Now, go back to the master branch and append the history of your branch
>> to the master branch, which will end up as the svn trunk::
>>
>>   git checkout master
>>   git svn rebase # Ensure we have most recent svn
>>   git rebase whizbang-branch # Append whizbang changes to master branch
>>   git svn dcommit -n # Check that this will apply to svn
>>   git svn dcommit # Actually apply to svn
>>
>> Finally, you may want to continue working on your whizbang-branch, so
>> rebase it to the new master::
>>
>>   git checkout whizbang-branch
>>   git rebase master
>>
>> Michael Droettboom wrote:
>>   
>>> This is mostly for Andrew Straw, but thought anyone else experimenting
>>> with git may be interested.  I'm going through some real newbie pains
>>> here, and I don't think what I'm doing is all that advanced.
>>>
>>> So, I've had a local git repository cloned from github (as per Andrew's
>>> instructions), made a branch, started hacking, all is well.  Now, I
>>> would like to update my master branch from SVN to get some of the recent
>>> changes others have been making.
>>>
>>> Following the instructions in the FAQ,
>>>
>>>  git svn rebase
>>>
>>> actually results in a number of conflicts in files I didn't touch.  I
>>> shouldn't have to resolve this conflicts, right?  'git status' shows no
>>> local changes, nothing staged -- nothing that should conflict.
>>>
>>> It turns out, if I do
>>>
>>>   git pull
>>>
>>> then,
>>>
>>>   git svn rebase
>>>
>>> all is well.
>>>
>

Re: [matplotlib-devel] What would you like to see in a book about Matplotlib?

[Andrew Straw]

Hi Sandro,

It's great news that a book may come out on MPL.

Speaking as an aspiring university professor in neuroscience, I would
like to see something that could be used as a resource for undergraduate
students just learning Python and MPL. Due to this perspective, I think
such a book would cover both numpy and MPL. The emphasis could clearly
by on MPL, but basic numpy idioms and concepts should also be taught. I
think an example-driven approach would be very useful -- something like
an undergraduate laboratory experiment where students measure and plot
raw values and compute histograms and statistics (e.g. mean and std).
More advanced sections might perform statistical comparisons of
different treatments (e.g. using chi squared, KS and/or T tests), do
linear least squares fitting (with np.linalg.lstsq), and possibly
non-linear curve fitting using something like scipy.optimize.fmin.

That's my self-serving $0.02, since you asked! :)

You may also want to speak with John Hunter and Fernando Perez about the
possibility of collaborating -- they've already done some work towards a
book, too.

Andrew

Sandro Tosi wrote:
> Hello and Happy 2009!
> 
> I received the interesting proposal to author a book on Matplotlib,
> the powerful 2D plotting library for Python.
> 
> While preparing the arguments list, I'd like to hear even your
> opinion, because different points-of-view will lead to a better
> product.
> 
> Some basic question I'd like to ask are:
> 
> - what are you using matplotlib for?
> - what are the things you like the most of matplotlib, that you want
> to give emphasis to? And why?
> - what are the (basic) things that, when you were beginning to use
> matplotlib, you wanted to see grouped up but couldn't find?
> - what would you like to see in a book about matplotlib?
> - what are some those advanced feature that made you yell "WOW!!" ?
> - what are the things you'd like to explore of matplotlib and never
> had time to do?
> 
> Your suggestions are really appreciated :) And wish me good luck!
> 
> Cheers,


--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git questions

[Andrew Straw]

Hi Mike, This sounds like good news. I am swamped right now, but I hope
to get the git mirror on github up-to-date early next week when work is
a little less busy.

John (or any developer with SF admin capabilities), if we could set up
some kind of auto-notification on SVN commits, I could possibly set up a
script to update the git repo. The thing I've seen so far is to go to
the Sourceforge project page and under "Admin" selection "Subversion"
then at the bottom in the "Hooks" section, change the entry to
"ciabot_svn.py - Send commit stats to cia.navi.cx". If you  could do
that, from there I will attempt to take things to auto-update the git
mirror.

-Andrew

Michael Droettboom wrote:
> I have successfully used the git mirror to commit changes to the 
> maintenance branch.  I've updated the matplotlib developer docs to 
> describe how to do it (not that bad really), though it takes a while 
> given the v0_98_4 "oops" branch ;)  I have yet to figure out all the 
> loop-de-loops required to merge from the maintenance branch to the trunk 
> in git and then push that all back to SVN (should be possible, but may 
> not play well with svnmerge, anyway).  The good news is that, as always, 
> svnmerge still works for that purpose.
> 
> Mike
> 
> Michael Droettboom wrote:
>> Thanks.  These are really helpful pointers.  For me, this is the one 
>> missing piece that would help me use git full-time, particularly with 
>> the way matplotlib and other projects I work on are laid out in SVN.  So 
>> I'm pretty motivated to figure this out.
>>
>> I'll certainly share any findings in this regard.
>>
>> Cheers,
>> Mike
>>
>> Andrew Straw wrote:
>>   
>>> Hi Mike,
>>>
>>> I have not imported the branches. ( IIRC, this was there were several
>>> that weren't MPL but other parts of the repo such as py4science,
>>> toolkits and so on).  It may be possible to add just the 0.98.5
>>> maintenance branch without the others, but I won't have a chance
>>> immediately to play around with that.
>>>
>>> To add all the branches to your git repo, you might be able to add
>>> something like "branches = branches/*:refs/remotes/branches/*" to the
>>> [svn-remote "svn"] section of .git/config and re-do "git svn fetch"...
>>> This will grab all the branches over all svn history, which will, I
>>> think, pull in py4science and toolkits branches... And I guess the
>>> download time from svn will be extremely long... In that case it's
>>> probably better to rsync from sourceforge's server to a local disk and
>>> do the git svn checkout that way making a whole new git repo.
>>>
>>> It may be worth attempting to talk to some real git/svn gurus at this
>>> point about tracking (only one or a couple) svn branches with git
>>> branches. So far, I've only dealt with the trunk in my git/svn
>>> interoperation experience.
>>>
>>> -Andrew
>>>
>>> Michael Droettboom wrote:
>>>   
>>> 
>>>> Thanks.  I've incorporated your docs into the developer documentation.
>>>>
>>>> My next experiment will be to see if I can track the 0.98.5 maintenance 
>>>> branch with git.  SVN tags/* show up as available remote branches, but 
>>>> not branches/*, which leaves me a bit stumped?  If you've done this and 
>>>> there's a quick answer, let me know, otherwise I'll do a little digging 
>>>> to see if it's possible.
>>>>
>>>> Mike
>>>>
>>>> Andrew Straw wrote:
>>>> 
>>>>   
>>>>> Hi Michael,
>>>>>
>>>>> The main issue is that we can't use git "normally" because the main
>>>>> history will be kept with svn. Thus, there's going to be a lot of
>>>>> history rewriting going on through the rebase command. (These
>>>>> complications are obviously not the ideal scenario for git newbies...)
>>>>> Rather than answer your questions directly, I'll walk you through how I
>>>>> do things. (This is not tried on the MPL svn repo, but some a private
>>>>> svn repo. I don't see any fundamental differences, though. So this
>>>>> should work.)
>>>>>
>>>>> (Hopefully this will be cut-and-pasteable ReST, which could go in the
>>>>> docs somewhere):
>>>>>
>>>>> Making a git feature bra

Re: [matplotlib-devel] [Numpy-discussion] Singular Matrix problem with Matplitlib in Numpy (Windows - AMD64)

[Andrew Straw]

John Hunter wrote:
> Andrew, since you are the original author of the isnan port, could you
> patch the branch and the trunk to take care of this?

Done in r6791 and r6792.

Sorry for the trouble.

Now I just hope we don't get a problem with "long long", although now if
_ISOC99_SOURCE is defined, we'll preferentially use "int64_t" out of
, so I should think this is more portable on sane platforms.

This one of many reasons why I stick to Python...
-Andrew

> 
> JDH
> 
> On Fri, Jan 16, 2009 at 8:07 AM, George  wrote:
>> Hello.
>>
>> I am terribly sorry. I was mistaken last night. I had the latest Matplotlib
>> version 0.98.5.2 and I thought the bug was fixed but it hasn't. Let me 
>> explain.
>>
>> In the file MPL_isnan.h line 26 there is a declaration:
>>
>> typedef long int MPL_Int64
>>
>> This is fine for Linux 64-bit, but NOT for Windows XP 64-bit! For Windows the
>> declaration should be:
>>
>> typedef long longMPL_Int64
>>
>> This bug has caused me a LOT of late nights and last night was one of them. 
>> The
>> declaration is correct for Linux 64-bit and I guess Matplotlib was developed 
>> on
>> Linux because of this declaration. That is also why I thought the bug was 
>> fixed
>> but this morning I realised that I was looking at the wrong console.
>>
>> So, in summary. For Matplotlib 0.98.5.2 and Numpy 1.2.1 to work without any
>> problems. This means compiling and using Numpy and Matplotlib on Windows XP
>> 64-bit using AMD 64-bit compile environment, change line 26 in the file
>> MPL_isnan.h from long int to long long.\
>>
>> I also previously suggested switching MKL and ACML etc. but with this change
>> everything is fine. One can choose any math library and it works.
>>
>> Writing a small test application using sizeof on different platforms 
>> highlights
>> the problem.
>>
>> Thanks.
>>
>> George.
>>
>>
>> ___
>> Numpy-discussion mailing list
>> numpy-discuss...@scipy.org
>> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>>
> 


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Numpy-discussion] Singular Matrix problem with Matplitlib in Numpy (Windows - AMD64)

[Andrew Straw]

Hmm, I tried "svnmerge.py avail" from the branch after committing to the
trunk. I see now that I should have committed to the branch first (which
seems an inversion to me). Duly noted for the future, though.

Still working on seamless git-svn and svnmerge.py integration,
Andrew

John Hunter wrote:
> On Fri, Jan 16, 2009 at 12:38 PM, Andrew Straw  wrote:
>> John Hunter wrote:
>>> Andrew, since you are the original author of the isnan port, could you
>>> patch the branch and the trunk to take care of this?
>> Done in r6791 and r6792.
>>
>> Sorry for the trouble.
>>
>> Now I just hope we don't get a problem with "long long", although now if
>> _ISOC99_SOURCE is defined, we'll preferentially use "int64_t" out of
>> , so I should think this is more portable on sane platforms.
>>
>> This one of many reasons why I stick to Python...
> 
> Thanks Andrew for applying this, and Georg, I forgot to mention in my
> last post thanks especially for tracking down this nasty bug.  Andrew,
> for future reference, when fixing a bug on the branch, it is best to
> svnmerge it onto the rather than committing it separately since
> subsequent merges will bring it over an confuse the commit log.
> Instructions at
> 
>   http://matplotlib.sourceforge.net/devel/coding_guide.html#using-svnmerge
> 
> Thanks again!
> JDH
> 


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] status update on using git to interact with MPL svn repo

[Andrew Straw]

For the past month or two, I've been experimenting with using git to
interact with the MPL subversion repository. The bottom line is that I I
haven't been able to create any kind of one-to-one mapping between git
branches and svnmerge.py branches. As we're using svnmerge.py on top of
subversion to manage the trunk and release branches, I see this as a
pretty fatal flaw.

So, while I can use git to interact with the trunk (and create and use
my own feature branches locally using git), and while using git is very
nice for browsing history or bisecting the revision in which a bug
cropped up, I think I've reached a point where I don't think interaction
with svnmerge.py's branches is going to work without investing more time
than I'm willing to give into understanding (and possibly improving)
git-svn.

So, therefore, I'd say the issue of using a distributed version control
system for MPL has not reached any real conclusion. Thus, we may want to
visit this issue at some point. Perhaps once Python and/or numpy have
made decisions. The Python-dev team seems to be working this out right
now: http://www.python.org/dev/peps/pep-0374/

-Andrew

--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Build Failure on Windows using Python25

[Andrew Straw]

Patrick,

Can you see if adding "#include " at the top of src/path.cpp
will do the job?

I'm not super-optimistic, though -- I think this is defined by the C99
standard, which I'm not sure Microsoft supports.

-Andrew

Patrick Marsh wrote:
> Greetings,
>
> I have previously been able to build matplotlib on my Windows Vista
> machine using both Python25 and Python26.  However, after my latest
> update to SVN, I'm no longer able to build matplotlib on my Windows
> machine (but am with my gentoo box).  Below is the output from the
> build log using Python25 (which failed).  Ryan May and I did a little
> digging we're thinking that either MSVC doesn't like uint8_t, or it
> needs some missing header that isn't already included so that it knows
> what unit8_t is.
>
> Has anyone else encountered this problem, and if so, has anyone overcome this?
>
>
> 
> BUILDING MATPLOTLIB
> matplotlib: 0.98.6svn
> python: 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC
> v.1310 32 bit (Intel)]
>   platform: win32
>Windows version: (6, 0, 6001, 2, 'Service Pack 1')
>
> REQUIRED DEPENDENCIES
>  numpy: 1.3.0.dev6338
>  freetype2: found, but unknown version (no pkg-config)
>
> OPTIONAL BACKEND DEPENDENCIES
> libpng: found, but unknown version (no pkg-config)
>Tkinter: Tkinter: 67737, Tk: 8.4, Tcl: 8.4
>   wxPython: 2.8.9.1
> * WxAgg extension not required for wxPython >= 2.8
>   Gtk+: no
> * Building for Gtk+ requires pygtk; you must be able
> * to "import gtk" in your build/install environment
>Mac OS X native: no
> Qt: no
>Qt4: no
>  Cairo: no
>
> OPTIONAL DATE/TIMEZONE DEPENDENCIES
>   datetime: present, version unknown
>   dateutil: matplotlib will provide
>   pytz: 2008c
>
> OPTIONAL USETEX DEPENDENCIES
> dvipng: no
>ghostscript: no
>  latex: no
>pdftops: no
>
> [Edit setup.cfg to suppress the above messages]
> 
> pymods ['pylab']
> packages ['matplotlib', 'matplotlib.backends',
> 'matplotlib.projections', 'mpl_toolkits', 'matplotlib.numerix',
> 'matplotlib.numerix.mlab', 'matplotlib.numerix.ma',
> 'matplotlib.numerix.npyma', 'matplotlib.numerix.linear_algebra',
> 'matplotlib.numerix.random_array', 'matplotlib.numerix.fft',
> 'matplotlib.delaunay', 'pytz', 'dateutil', 'dateutil/zoneinfo']
> running build
> running build_py
> copying lib\matplotlib\mpl-data\matplotlibrc ->
> build\lib.win32-2.5\matplotlib\mpl-data
> copying lib\matplotlib\mpl-data\matplotlib.conf ->
> build\lib.win32-2.5\matplotlib\mpl-data
> running build_ext
> building 'matplotlib._path' extension
> D:\Program Files\Microsoft Visual Studio 2003\bin\cl.exe /c /nologo
> /Ox /MD /W3 /GX /DNDEBUG
> -ID:\Python25\lib\site-packages\numpy\core\include
> -Iwin32_static\include -I.
> -ID:\Python25\lib\site-packages\numpy\core\include -Isrc
> -Iagg24/include -I. -ID:\Python25\include -ID:\Python25\PC
> /Tpsrc/path.cpp /Fobuild\temp.win32-2.5\Release\src/path.obj
> path.cpp
> src\path.cpp(356) : warning C4800: 'long' : forcing value to bool
> 'true' or 'false' (performance warning)
> src\path.cpp(566) : warning C4800: 'long' : forcing value to bool
> 'true' or 'false' (performance warning)
> src\path.cpp(867) : warning C4800: 'long' : forcing value to bool
> 'true' or 'false' (performance warning)
> src\path.cpp(1209) : error C2065: 'uint8_t' : undeclared identifier
> src\path.cpp(1209) : error C2955: 'std::vector' : use of class
> template requires template argument list
> D:\Program Files\Microsoft Visual Studio
> 2003\include\vector(896) : see declaration of 'std::vector'
> src\path.cpp(1209) : error C2955: 'std::vector' : use of class
> template requires template argument list
> D:\Program Files\Microsoft Visual Studio
> 2003\include\vector(896) : see declaration of 'std::vector'
> src\path.cpp(1226) : error C3861: 'uint8_t': identifier not found,
> even with argument-dependent lookup
> src\path.cpp(1226) : error C2955: 'std::vector' : use of class
> template requires template argument list
> D:\Program Files\Microsoft Visual Studio
> 2003\include\vector(896) : see declaration of 'std::vector'
> src\path.cpp(1226) : error C2955: 'std::vector' : use of class
> template requires template argument list
> D:\Program Files\Microsoft Visual Studio
> 2003\include\vector(896) : see declaration of 'std::vector'
> src\path.cpp(1241) : error C2662: 'std::vector<_Ty,_Ax>::reserve' :
> cannot convert 'this' pointer from 'std::vector' to
> 'std::vector<_Ty,_Ax> &'
> Reason: cannot convert from 'std::vect

Re: [matplotlib-devel] Build Failure on Windows using Python25

[Andrew Straw]

Ryan May wrote:
> On Fri, Feb 6, 2009 at 3:27 PM, Andrew Straw  <mailto:straw...@astraw.com>> wrote:
>
> Patrick,
>
> Can you see if adding "#include " at the top of src/path.cpp
> will do the job?
>
> I'm not super-optimistic, though -- I think this is defined by the C99
> standard, which I'm not sure Microsoft supports.
>
>
> Well, we're also talking about C++ here and not C, so C99 does not
> apply.  A quick googling around seems to indicate that some of the
> open source compilers support such a type, but it not standardized by C++.
There is no  or the type is not defined in stdint.h?

Maybe as a workaround you could use mingw...

--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] imsave function

[Andrew Straw]

Hi Gary, I have a couple comments:

1) No need for:

+ax = fig.add_subplot(111)
+ax.set_axis_off()

2) It's probably best to have maximum compatibility with imshow().
Therefore, use vmin=None and vmax=None as keyword arguments (rather than
clims).

Otherwise, I tested and it works for me.

-Andrew

Gary Ruben wrote:
> Hi,
> 
> I've attached a patch against the mpl head in response to John's
> suggestion and helpful pointers on the users list. This adds a new
> function imsave to complement imread in the image module. I've also
> exposed it in the pyplot interface.
> If this is presumptuous, feel free to remove it from the patch or ask me
> to remove it. This is my first contribution to matplotlib for a while
> and my first attempt at a patch like this.
> 
> Because I don't build matplotlib from source, I've done what testing I
> can without fully rebuilding matplotlib. I'd be reluctant to have this
> patch applied without someone else checking it first. It's pretty simple
> so applying it locally and running the demo file should be a good enough
> test.
> 
> thanks,
> Gary Ruben
> 
> 
> 
> 
> --
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> 
> 
> 
> 
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] imsave function

[Andrew Straw]

Gary, this looks fine to me. Do you have commit access? If not, I'll be
happy to check it in for you.

-Andrew

Gary Ruben wrote:
> Thanks for the quick test and comments Andrew. I've made your suggested
> changes and attached a new patch.
> 
> Gary
> 
> Andrew Straw wrote:
>> Hi Gary, I have a couple comments:
>>
>> 1) No need for:
>>
>> +ax = fig.add_subplot(111)
>> +ax.set_axis_off()
>>
>> 2) It's probably best to have maximum compatibility with imshow().
>> Therefore, use vmin=None and vmax=None as keyword arguments (rather than
>> clims).
>>
>> Otherwise, I tested and it works for me.
>>
>> -Andrew
> 
> 
> 
> 
> --
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> 
> 
> 
> 
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] imsave function

[Andrew Straw]

Gary Ruben wrote:
> Hi Andrew,
> 
> I don't have commit access. If you would check it in, that would be great.

Committed to the trunk in r6899... Thanks!

And, sheesh, SourceForge's SVN server is slooow today for me, although
it seems to have finally improved.

--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] File format for plots

[Andrew Straw]

Eric Firing wrote:
> Sandro Tosi wrote:
>> Hi Sam,
>>
>> On Wed, Feb 25, 2009 at 09:35, sam tygier  wrote:
>>> I think this topic has come up before, but i don't think anything has
>>> resulted from it.
>>>
> Correct, because the capability would require a *lot* of work to 
> implement, and most of us don't see a compelling need; we believe that a 
> better practice is to structure one's work so that plotting is separated 
> from data (result) generation in any cases where the latter is highly 
> time-consuming.

One nice benefit, however, would be that the data could be shipped to
another interpreter for plotting without worrying about threads/GIL/etc.
So, having an MPL-native plot description would be useful. But, I agree,
it would be a lot of work.

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] interactive property editor

[Andrew Straw]

Paul Kienzle wrote:
> On Mar 12, 2009, at 9:49 AM, Michael Droettboom wrote:
>
>   
>> We've done some experiments with Enthought Traits at various times to
>> address this issue.  There were always various obstacles to making it
>> work, but it may be worth another look.  Traits has its nice auto- 
>> built
>> property editors (that may address your request), but it would also
>> address one of my long-standing niggles that properties of graphs are
>> often checked far too late and the error messages presented to the  
>> user
>> are very obscured because of it.
>>
>> Of course, all that is a major undertaking -- basically rewriting all
>> the getters and setters on the artist classes to use traits -- but I
>> could see it having quite the payoff in the end.
>>
>> 
>
> I'm not sure if traits can do it.
>   
Why not? Everything you describe below screams "traits" to me.
> I would like to see CSS-like properties, so that when I change the  
> font size on the graph, the title, which is size +2, and the legend  
> which is size -1 also get updated.  I can imagine changing the font  
> for an axes, for a figure or for all figures.  The latter should be  
> stored in a resource file so it doesn't have to be done every  
> session.  Properties which are not set should look up their values  
> elsewhere; if the property of some object has been specialized, then  
> it should not change when the figure properties are set. Properties  
> for printed figures may be different from properties of figures on  
> the screen, e.g., because the printer is monochrome.
>
> Eventually I would like interactive editing of properties by point  
> and click.  Particularly for plotted data the question will be  
> whether the change applies to the data point only, to its line, or to  
> all lines on the graph, to all graphs on the figure, or to all  
> figures, depending on the property.  Doing this without cluttering  
> the UI will be a challenge.
>   


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] release strategy, and the role of v0_98_5_maint

[Andrew Straw]

John Hunter wrote:
> In general, only very clear bugfixes which are unlikely to result in
> "surprise" breakages should go in.  The _png patch, though a bug fix,
> has more of the feel of a feature enhancement, and given its
> complexity, should probably not go in to the branch unless someone
> makes a compelling case (though I am very excited to see it go in to
> the trunk).
>   
OK, I wasn't sure about it when I put it in. Shall I back it out?

> We are not that far away, at least for src snapshots, os x binaries,
> and the docs.  The windows binary would take some work, as would a
> linux binary, eg a debian package.
FWIW, the Debian packagers will want to make their own .debs from the
source package.

Also note that the Windows binaries may take more effort than normal --
Python 2.6 is built with a different MS compiler than before.

--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] OpenGL backend and pyglet expertiments

[Andrew Straw]

Nicolas Rougier wrote:
> 
> I read the thread about mplot3d and the work that has been done by  
> Jonathan Taylor. I wonder if an OpenGL backend is necessary at all.  
> Jonathan's work seems to be great for simple 3D plotting while  the  
> mayavi mlab module is here for more "serious" rendering.  I think I  
> will concentrate my efforts on a simple GL terminal for IPython with  
> embedded visualization capability. As for sympy (and because it uses  
> pyglet), I guess the integration should be straight forward.
> 
> Last version of the ipython GL terminal is on launchpad:
>https://launchpad.net/glipy

Hi Nicolas, I haven't tried your glipy terminal, but it looks very
interesting.

The main issue with an OpenGL backend for MPL is simply that a naive
implementation is going to look ugly when compared, pixel-by-pixel,
against the Agg or cairo backends to generate bitmaps. Agg and cairo are
very good at drawing anti-aliased lines, whereas one must jump through
hoops to get consumer OpenGL cards to render lines well.

Here's an idea -- an OpenGLAgg backend that actually uses Agg for all
the rendering, but blits the results to an OpenGL texture for display.
Thus, the backend would really just be glue between the existing Agg
backend and pyglet.

-Andrew

--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] OpenGL backend and pyglet expertiments

[Andrew Straw]

Nicolas Rougier wrote:
> 
> What I do generally to have "nice" OpenGL output is to render  
> screenshots at high resolution and then use something like gimp to  
> resize them. I agree that it is far from optimal but it's pretty  
> decent for a scientific paper. Other solutions are vector rendering of  
> scene (using gl2ps for example) or the texture anti-aliasing technique  
> (http://homepage.mac.com/arekkusu/bugs/invariance/TexAA.html).

Yes. That is why I said a "naive" implementation.

> But, beside rendering issue, I think an OpenGL backend could be useful  
> for experiments involving very fast rendering of large arrays. Using  
> OpenGL texture, you can render 1000x1000 arrays with continuous update  
> of data (on recent machines).

Yes. I wrote a module pygarrayimage for just that:
http://code.astraw.com/projects/motmot/pygarrayimage.html

BTW, my ideas were meant more as "how to wedge MPL quickly into glipy
with a minimum of work" rather than "a talented programmer with one year
of free time to come up with the coolest scientific workflow GUI" variety.

-Andrew

--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] release strategy, and the role of v0_98_5_maint

[Andrew Straw]

Charlie Moad wrote:
> I am running into an error when importing matplotlib though.  I'll
> poke around but would appreciate extra eyes.
> 
> ImportError: DLL load failed: The specified procedure could not be found.

Hi Charlie, we've been batting this one around on MPL-users for a little
while... still no resolution though. See the thread started by Lorenzo
Di Gregorio "matplotlib._path failed on windows build for Python 2.6".

-Andrew

--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] traits?

[Andrew Straw]

I've been hacking away at adding support for "dropped spines" to MPL
(e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 ) and
have come to the conclusion that there is a fundamental issue in the
code base that the traits package has solved -- many values that depend
on other values with complicated stuff that happens when one of the
parent values changes. For example, the location of the text from the
xaxis depends on the padding value in addition to the xaxis location.
Now I'm trying to add another element to the mix -- namely an axis spine
that can change location -- and things are going to spiral into a
(further) collection of special-cased updates unless there's some
reworking of the infrastructure.

So, the question is, should I attempt to use traits for this? I guess
that I won't have the time to re-write the entire code base to use
traits, but I'd like make a stab a stab at dropped spine support with
the knowledge that, should I be successful, there's at least a chance we
would again ship traits with MPL. I imagine we could incrementally move
more and more to traits if I'm successful, particularly now that we have
the beginnings of a unit test infrastructure (thanks James!).

-Andrew

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] attempting to enable buildbot

[Andrew Straw]

Hi all,

I am attempting to get a collective.buildbot service working on the
Matplotlib trunk (branches could be enabled in the future) and James
Evans' test suite. Right there are errors that prevent the test suite
from even being run. I'll attempt to work through these, and you can
check progress on the nascent buildbot display here:

http://mpl-buildbot.code.astraw.com

(If the DNS update hasn't propagated to your DNS server yet, you can go
directly to http://code.astraw.com:8092/ )

In the meantime, please forgive a couple extra files I committed
(bootstrap.py and buildout.cfg) that are designed to get matplotlib to
adhere to buildout package standards.

Assuming I can get this working, I'll attempt to recruit further
buildslaves. In the interest of piquing your interest in running a
buildslave on your favorite platform(s), here is the contents of my
buildout.cfg file containing all of the configuration necessary. It's
pretty simple:

[buildout]
parts = ubuntu-hardy-amd64

[ubuntu-hardy-amd64]
recipe = collective.buildbot:slave
host = mpl-buildbot.code.astraw.com
port = 8090
password = 

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] attempting to enable buildbot

[Andrew Straw]

Andrew Straw wrote:
> Hi all,
> 
> I am attempting to get a collective.buildbot service working on the
> Matplotlib trunk (branches could be enabled in the future) and James
> Evans' test suite. Right there are errors that prevent the test suite
> from even being run. I'll attempt to work through these, and you can
> check progress on the nascent buildbot display here:
> 
> http://mpl-buildbot.code.astraw.com

OK, the tests are now actually running, although most of the tests are
failing, which is worse than when I run the tests manually. :(

If anyone wants to attempt to get the tests passing, the buildmaster
should be configured to trigger a build on an svn commit (it is supposed
to poll the svn server every 10 minutes). You can also trigger a build
attempt by clicking the "Force Build" button after following the builder
link in the Web GUI (I may have to disable this if the load gets too high.)

Let's see if we can get all the tests passing and if this buildbot
approach looks sustainable -- if so, I'd like to get some more build
slaves into the mix and make MPL a good continuous integration citizen.
I don't think the buildbot master will take many resources on my server,
so I'm happy to host it there. I could put it under a different domain
name, too -- that may be desirable for marketing reasons.

-Andrew

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] attempting to enable buildbot

[Andrew Straw]

Andrew Straw wrote:
>> I am attempting to get a collective.buildbot service working on the
>> Matplotlib trunk (branches could be enabled in the future) and James
>> Evans' test suite. Right there are errors that prevent the test suite
>> from even being run.

I believe I have enabled the unit test to properly run on the buildbot,
but it requires a patch to the buildout recipe (pbp.recipe.noserunner)
that runs the tests. I sent the patch to the author of
pbp.recipe.noserunner, so hopefully a new release will appear shortly
and I can take Ryan on John up on their offers of buildslaves, which
I'll coordinate off-list when the time is right.

In the meantime, the essential part of the pbp.recipe.noserunner patch is:

diff -r 8e8141beee8d
packages/pbp.recipe.noserunner/pbp/recipe/noserunner/__init__.py
--- a/packages/pbp.recipe.noserunner/pbp/recipe/noserunner/__init__.py
Wed May 13 12:03:55 2009 +0200
+++ b/packages/pbp.recipe.noserunner/pbp/recipe/noserunner/__init__.py
Wed May 20 15:08:27 2009 -0700
@@ -61,6 +61,13 @@
 if initialization_section:
 initialization += initialization_section

+plugins = options.get('plugins', '')
+plugins = [plugin.strip() for plugin in plugins.split('\n') if
plugin.strip() != '']
+
+if len(plugins):
+plugin_str = ','.join( plugins )
+defaults += ", plugins=[%s]"%plugin_str
+
 dest.extend(zc.buildout.easy_install.scripts(
 [(options['script'], 'nose', 'main')],
 ws, options['executable'],

If you've applied that, you'll have to add to the "develop" section of
the buildout file the line "/path/to/pbp.recipe.noserunner" (in addition
to the "."). From there, it's standard zc.buildout recipes in the MPL dir:

python bootstrap.py # create bin/buildout
bin/buildout # build MPL and create bin/test
bin/test # run the unit tests

Since these are the steps that the buildbot follows, this should also
work on the build slaves once we no longer need the custom
pbp.recipe.noserunner. If it looks like it'll be a while before a new
pbp.recipe.noserunner is released, I think we could temporarily host a
patched version and direct buildout to it with the find-links option.

-Andrew

--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] attempting to enable buildbot

[Andrew Straw]

The tests now seem to be running OK. There are some failures due to
image comparison mismatch, but I think we should attempt to track these
down as a team -- hopefully running on more computers than just mine and
with James' input. To see the latest test results, click on the "stdio"
link for each run of the "test" box in the waterfall display
http://mpl-buildbot.code.astraw.com/waterfall .

It would be nice if the buildbot web GUI would easily let us see, for
failed image-based tests, the baseline, output, and difference image,
but that's not implemented (as far as I know). It would probably be
possible to add something like this to the MplNosePlugin to do this with
relatively little pain, although the display would be easiest via a
pastebin or something rather than hooking back into a patched buildbot
framework that supported test images.

John Hunter wrote:
> On Wed, May 20, 2009 at 3:48 AM, Andrew Straw  wrote:
> 
>> Let's see if we can get all the tests passing and if this buildbot
>> approach looks sustainable -- if so, I'd like to get some more build
>> slaves into the mix and make MPL a good continuous integration citizen.
>> I don't think the buildbot master will take many resources on my server,
> 
> The sage project has given us access to a network accessible
> persistent OSX box, so I will try and get that setup with the buildbot
> infrastructure.  I'm not yet familiar with the buildbot project or
> approach, so I have some learning to do, so if you have a cheatsheet
> or docs thaty you think are particularly handy, send them along
> (otherwise I'll just make my way through the site docs)

OK, here's what you do::

  # (Make a username you want to run this buildslave as.
  # Become that user. Change into a new directory e.g. $HOME/builbot)

  curl http://astraw.com/mpl/bootstrap-py.txt > bootstrap.py
  curl http://astraw.com/mpl/buildout-example.cfg > buildout.cfg

  # Edit buildout.cfg according the instructions in the file. Send me
  # the values you added.

  # python bootstrap.py
  # bin/buildout

Once you've been added to the build master:

  # bin/ start

And that should be it.

For now we can start/stop builds by clicking the "force build" button in
the buildmaster web GUI. SVN polling doesn't seem to be working yet...
I'll look into that when I have time. Ditto for building binaries and
uploading them somewhere.

-Andrew

--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] radial grids broken on polar?

[Andrew Straw]

John Hunter wrote:
> When plotting the polar demo, I am not getting radial grids on the
> trunk (but I am getting them on the branch).  Any ideas?

git bisect let me narrow it down to r7100 in a few minutes. (I'm back to
using git to interact with MPL svn again.  Just don't ask me to deal
with the svn branches! :)

Author: efiring 
Date:   Wed May 13 19:59:16 2009 +

Experimental clipping of Line _transformed_path to speed zoom and pan.

This can be modified to work with x monotonically decreasing, but
for a first try it works only with x monotonically increasing.
The intention is to greatly speed up zooming and panning into
a small segment of a very long time series (e.g., 10^6 points)
without incurring any significant speed penalty in other situations.

git bisect start
# bad: [e4c9c46ab1909c05323da28c057c8d64fc6d44a8] add example of dropped
spines
git bisect bad e4c9c46ab1909c05323da28c057c8d64fc6d44a8
# good: [bdf5bb3116a6d58d49b0d7a98e8dab5d9dacd1da] removed extraneous
savefig calls from examples
git bisect good bdf5bb3116a6d58d49b0d7a98e8dab5d9dacd1da
# bad: [f36409e021d030fa22515d4d9362a2c657e3df3e] applied Michiel's sf
patch 2792742 to speed up Cairo and macosx collections
git bisect bad f36409e021d030fa22515d4d9362a2c657e3df3e
# good: [6d21b5b655f045d9edf759037e3a67ca51f89d08] updates to doc
git bisect good 6d21b5b655f045d9edf759037e3a67ca51f89d08
# bad: [d7a5aecdbf274227e98ad4ac4257435d2e37156d] Fixed bugs in quiver
affecting angles passed in as a sequence
git bisect bad d7a5aecdbf274227e98ad4ac4257435d2e37156d
# bad: [736a4f9804e01d0d5b738f869444709496e34c56] psfrag in backend_ps
now uses baseline-alignment when preview.sty is used
git bisect bad 736a4f9804e01d0d5b738f869444709496e34c56
# bad: [86e1487f9718db26c86867a2711aac5410bd828d] Experimental clipping
of Line _transformed_path to speed zoom and pan.
git bisect bad 86e1487f9718db26c86867a2711aac5410bd828d

--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] radial grids broken on polar?

[Andrew Straw]

Andrew Straw wrote:
> John Hunter wrote:
>> When plotting the polar demo, I am not getting radial grids on the
>> trunk (but I am getting them on the branch).  Any ideas?
> 
> git bisect let me narrow it down to r7100 in a few minutes. (I'm back to
> using git to interact with MPL svn again.  Just don't ask me to deal
> with the svn branches! :)

Hmm, it seems my git mirror of the svn repo is bad... For some reason
git thinks r7100 comes after r6550, so there are a few commits in there
that seem to have been lumped with r7100!

Oh, wait, now I remember doing "git svn fetch -r 7100:HEAD" at some
point. I'll have to remedy this...

--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] dropped spine support

[Andrew Straw]

John Hunter wrote:
> On Thu, May 21, 2009 at 10:08 PM, Jae-Joon Lee  wrote:
>
>   
>> 2) Axes.frame
>>  Is it okay to simply  drop this attribute? Any code that access this
>> attribute will raise an exception. For example, some of my code in
>> mpl_toolkits.axes_grid access this attribute, although a fix would be
>> very trivial.
>> 
>
> We can drop it - there never was a documented reference to it, no
> public method, etc, so it is safely considered mostly  "internal
> code", and in the global scheme is comparatively new code (and on a
> quick grepping did not see any examples using it in the pylab_examples
> or api dirs).  I don't think it will impact many users, and anyone who
> was trying to manipulate the frame directly can easily update their
> code.  We should just have a little transition cheatsheet in the
> API_CHANGES section describing the removal.
>
> We *could* override getattr and raise a suitable warning pointing to
> the spine docs, if people think that is needed, but overriding getattr
> often leads to unintentional bugs.
>   
Based on Jae-Joon's comment, I was thinking of making .frame a property
that raised an Error describing to get .spines instead... That avoids
the getattr issues, but I think depends on Artist being a new style class.

(Thanks to all for the responses... I'm acting on them and will
incorporate most or all of the suggestions.)

-Andrew

--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] transform question

[Andrew Straw]

Hi MPL transform gurus (aka Mike),

I'm trying to close on this "dropped spine" thing, and I have a question
I think you could save me some time on.

I need to get a transform that will be combined with the normal xaxis
transform to shift the spine and associated ticks and tick labels by
some amount. For my first incarnation, I used something like

mtransforms.ScaledTranslation(offset_x,offset_y,self.figure.dpi_scale_trans)

This is fine when I new the offset in points directly. However, now I'd
like to support offsetting the spine to the center of the Axes. So, for
this case, I'd like to calculate the offset transform required to take
axes coordinate 0 and translate it to 0.5. Thus, I think I need
something like

mtransforms.ScaledTranslation(0.5, 0, self.axes.transAxes)

Unfortunately, that's clearly not working. So, is there a quick fix for
this?

Note that, as I've implemented things, the easiest path is that the new
transform is a translation combined with the existing xaxis transform
(using "get_xaxis_transform() + my_new_transform"). Other methods may be
possible, but I think they'll be a lot more work.

Thanks,
Andrew

--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] arbitrary spine locations in svn trunk

[Andrew Straw]

I've gone ahead and committed my arbitrary spine location implementation
to the trunk (svn r7144). I'd appreciate it if you could kick the tires.
To get you started, try the new demo:
examples/pylab_examples/spine_placement_demo.py

I believe I addressed all the issues raised with the patch I emailed the
list last week and I tried to avoid any breakage. Thanks to all who
commented -- you made this a better implementation.

Note that Axes.frame no longer exists, and I made a note of this in
api_changes.rst and a hopefully carefully worded AttributeError will be
raised if you try to access it.

Also, as excercised by the demo, in addition to support for a offset of
spines specified in points, one may specify spine placement in both axes
and data coordinates. Here is the docstring for Spine.set_position:

"""
set the position of the spine

Spine position is specified by a 2 tuple of (position type,
amount). The position types are:

* 'outward' : place the spine out from the data area by the
  specified number of points. (Negative values specify placing the
  spine inward.)

* 'axes' : place the spine at the specified Axes coordinate (from
  0.0-1.0).

* 'data' : place the spine at the specified data coordinate.

Additionally, shorthand notations define a special positions:

* 'center' -> ('axes',0.5)
* 'zero' -> ('data', 0.0)
"""

As always, please let me know of any suggestions or comments.

-Andrew

--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] arbitrary spine locations in svn trunk

[Andrew Straw]

Andrew Straw wrote:
> I believe I addressed all the issues raised with the patch I emailed the
> list last week and I tried to avoid any breakage. Thanks to all who
> commented -- you made this a better implementation.

Upon further reflection, I realize I didn't add any Axes convenience 
methods as Eric suggested. This is simply due to a lack of time -- not a 
lack of enthusiasm.

-Andrew

--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] doc build failures

[Andrew Straw]

John Hunter wrote:
> I was just updating the site docs and a few examples are failing to
> build.  Some of these are easy pickens, so if you have a quick fix,
> please put it in, and reply here when you've fixed one to avoid
> duplication of effort.

If you can coerce the recipe I sent this list on May 20 for running the
unit tests to run these as well, we'll see these sooner. Furthermore,
I've been busy with the spines, but I think we should check in new
baseline images in the test suite so that the builtbot waterfall goes green.

-Andrew

--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] arbitrary spine locations in svn trunk

[Andrew Straw]

Thanks everyone for the feedback. I have made Spine subclass Patch in
svn r7170, which I just committed.  This resulted in a slight API
change, but addresses most of the more substantial points raised.

The slight API change is that spine.set_color() is now
spine.set_edgecolor().

More below.

> On Thu, May 28, 2009 at 9:18 PM, John Hunter  wrote:
>> You do an isinstance(arg, basestring) to check for string input.
>> Typically, we encourage cbook.is_string_like to have a central point
>> of maintenance and consistency for these checks.

fixed in r7169

>> Also, in the example, you appear to turn off a spine by setting the
>> color to 'none'.  My thought it would be more natural to use the
>> "visible" artist property here (or at least support both)

I think this is addressed naturally by the new "Spine is a Patch" behavior.

>> Also, I think the class of strings representing "no color" in mpl is
>> larger -- it should also include self.color.lower()=='none' and the
>> empty string, which I've included in the example code.

Same for this. Now there's a single point of failure in the Patch.draw()
method.

Jae-Joon Lee wrote:
> The zorder of the spine artists is set to 0 by default.
> I notice that you're changing the zorder of its artist attribute, but
> note that it has no effect as what matter is the zorder of the spine
> itself.

Again, I think this is dealt with by the "Spine is a Patch" patch.

> As a related issue to what John mentioned, I think one option you can
> do is to derive the Spine class itself from a real artist class,
> rather than the base "Artist". With this, you don't need to implement
> all other set/get method, e.g., color, etc. For example, you may
> derive it from the Patch class. Note that while the Patch class is
> intended for closed path, you can stroke a straight line with it.

Good idea -- done! :)

 >  * cla() does not reset spines (positions, color, etc). I think it is
> better to be reset, since all other things are. For example, cla()
> resets visibility of ticks, etc.

Nice catch. Fixed in r7168.

> * better support for log scale.

I see the issue here, but I haven't had a chance to fix it. To be
honest, I'm surprised there aren't more of these types of issues...
You're welcome to take a look if you're so inclined -- it'll probably be
a few days before I have a chance to look at it.

--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] arbitrary spine locations in svn trunk

[Andrew Straw]

Eric Firing wrote:
> Andrew Straw wrote:
>> The slight API change is that spine.set_color() is now
>> spine.set_edgecolor().
> 
> But spine.set_color() is much more natural and easy to remember, so 
> maybe it can be restored:

Good idea. I just re-added Spine.set_color() and changed the example back.

-Andrew

--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Better pyplot wrappers

[Andrew Straw]

Jouni K. Seppänen wrote:

> I coded up what I think is an improvement, but since it has a lot of
> potential to break something and release time is near, I didn't commit
> my changes into svn. I tried playing around with git, to see if it is
> useful for communicating patches. 

I think it's useful.

> Any git gurus out there: is this the "right" way for using git to discuss
> patches, or am I missing something?

Yes, as much as there is one... My git mirror isn't automatically synced
so often falls behind a bit - as it was when you did this (I have just
now updated, though). Furthermore, I recently discovered that I
collapsed a bunch of svn commits into a single big git commit (the git
repo's idea of svn r7100 contains a lot more than the real svn r7100).
So, the branch currently labeled "master" in my github repository should
not become the cannonical git repository. (Of course, it will be very
easy to label the correct branch -- when it gets made -- "master".)

Anyhow, now that I've pushed up a more recent master, assuming you want
to apply your work onto that, you could either rebase your commits onto
the master -- thus ignoring the true historical state you developed them
against -- or merge the master branch -- causing the history to be more
complicated, as it's no longer linear.

And now that we're talking about this, Eric, as the only MPL dev that I
know who prefers Hg over git, have you seen
http://github.com/blog/439-hg-git-mercurial-plugin and would you be
willing to try it out? I'd be very interested to know if it could make a
git central repo work seamlessly for both Hg and git clients.

--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Better pyplot wrappers

[Andrew Straw]

Eric Firing wrote:
>
>>> And now that we're talking about this, Eric, as the only MPL dev that I
>>> know who prefers Hg over git, have you seen
>>> http://github.com/blog/439-hg-git-mercurial-plugin and would you be
>>> willing to try it out? I'd be very interested to know if it could
>>> make a
>>> git central repo work seamlessly for both Hg and git clients.
>>
>> I had not seen it until you mentioned it above.  Now I downloaded it,
>> enabled it, and tried to make a clone of Jouni's repo.  Hit an
>> exception.  It's probably because I am using a newer version of hg
>> than what hg-git is being developed with.  This will take a little
>> time to sort out.
>
> OK, I was able to clone successfully by switching to the last released
> version of hg.  More testing later.
Great.

I would suggest not attempting to judge on a crazy git-hg-svn triangle
-- git/svn itself is enough pain I wouldn't recommend it to anyone.
Hopefully git/hg is better. (In other words, if there's a project you're
interested that is exclusively git based, it may be best to play around
with that than rather than using hg to interact with my git mirror of
the MPL svn repo.)

BTW, I have no reason to disagree with you that learning hg is easier
than learning git. I haven't used Hg for anything complicated, but it
was certainly no trouble for me to do basic stuff with. I'm glad to read
about their bookmarks extension, which apparently makes hg able to
branch more like git rather than copying the entire repository.

-Andrew

--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] crazy ideas for MPL

[Andrew Straw]

Gael Varoquaux wrote:
> On Wed, Jul 01, 2009 at 08:39:30AM -0500, John Hunter wrote:
>   
>> Anyone interested?  And if so, feel free to suggest topics or weigh in
>> on some I listed.
>> 
>
> Actually, I have something I would like to discuss, but never really
> could pull myself together to do it. I don't have time right now, but I
> am still going to jot down the ideas.
>
> The axes and figure paradigm inherited from matlab works well for simple
> things, but when I want to more complex layouts, I actually end up
> struggling with calls to axes with numerical parameters to adjust. In
> addition, if I have a function that creates a plot with multiple axes,
> like the figure on:
> http://neuroimaging.scipy.org/site/doc/manual/html/neurospin/activation_map.html
> I may want to reuse that function to create more complex figures,
> stacking several of these views, with possibly other plots.
>
> It seems to me having a level of granularity between the figure, and the
> axes would help me a lot achieving these goals. I haven't had time to
> hash out an API, or even solid concepts. For people who know LaTeX well,
> let me draw an analogy: the figure is the page, the axis is the
> character, what we are lacking in a 'minipage'. I would like a container
> that can be stacked into a figure, and that can either hold axes, or
> similar containers. That way, I could specify subplot, or axis relative
> to this container, rather than relative to the whole figure, and it makes
> it really easy for me to insert figures in larger figures.
>
> One possible API would be 'subfigure', which would have a signature
> similar to 'axes', but of course things would need to be thought a bit
> more in detail: do we want clf to erase the figure and not the subfigure?
> I believe so. Do we want subplot to divide the subfigure, rather than the
> figure? I believe so too. How do we go back to full figure without
> erasing the subfigures it contains? I think subfigure(None) might work.
> How do I select a subfigure I already created? Maybe by passing it a
> subfigure instance, like the way axes work.
>
> Also, Chaco has the notion of containers, in which you can stack plots or
> other containers. They have an additional feature which is that they
> enable you to stack plot (these would be axes, in matplotlib terms) and
> do an automatic layout of the plots. Very handy to have an extensible
> canvas to display information on. Some sparse documentation:
> http://code.enthought.com/projects/chaco/docs/html/api/containers.html
>
> I have been trying to find time to think about this for more than a year,
> and haven't. This is why I am sending unfinished thoughts. I do believe
> more thinking has to be done, and the subfigure proposition may not hold
> at all. Also, I fear I do not have time to implement this.
>   
I also have some not very fleshed out thoughts: my main feeling about
MPL is that there's just too much layout happening to keep using the
non-systematic delegation/notification "system" currently in place while
allowing the devs to maintain their sanity and day jobs. I don't mean to
disparage MPL -- it is quite a fantastic piece of code -- but there is a
lack of abstraction of layout hierarchies and layout dependencies that
makes development difficult.

Therefore, I'd suggest that before adding on too many more nice
features, we revisit the core layout and delegation system -- in the end
it will make everything much easier. So, perhaps a useful thing would be
for as many MPL devs as possible to sit together and discuss how we
could do this. My thought right now would be to investigate the use of
traits to codify the layout abstractions.

Any effort like this will also obviously benefit from having an
extensive test suite. I think all that's needed to get the tests at
http://mpl-buildbot.code.astraw.com/waterfall to pass is that someone
checks in new images made with the current MPL. I'd like to do this, but
I'm really short on time at the moment. So, please, someone -- beat me
to it -- it won't be hard!

Those are my 2 cents. Hope to see you all at SciPy 2009!

-Andrew

--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] crazy ideas for MPL

[Andrew Straw]

Erik Tollerud wrote:
> Personally, I think traits must be kept out of MPL, for three main reasons:
>   
As these comments are in respose to my email, let me again state the 
main point of my email:

My main feeling about MPL is that there's just too much layout happening to 
keep using the non-systematic delegation/notification "system" currently in 
place while allowing the devs to maintain their sanity and day jobs. [...]  
Therefore, I'd suggest that before adding on too many more nice features, we 
revisit the core layout and delegation system -- in the end it will make 
everything much easier. So, perhaps a useful thing would be for as many MPL 
devs as possible to sit together and discuss how we could do this.

Thus, I was suggesting traits as a means to an end (a saner core), and not 
something for its own sake.

> 1. As Eric Bruning points out, while traits is a very powerful tool,
> it also closes a lot of doors by forcing everything to be written in a
> trait-like fashion for it to play nice with everything else.  While
> this is great for many applications, I think it does not necessarily
> belong everywhere, particularly given a tendancy to quickly snowball
> in complexity (not to mention any new people that want to contribute
> code have an extra thick manual to read).
>   
I wasn't proposing to touch the user API for MPL. I think we'd be silly 
to do that.
> 2. Installation of traits or traitsgui should not be a necessity for
> MPL... perhaps this will change in the future, but it's currently a
> far bigger task to get traits and traits UI working on an arbitrary
> system than it is to get MPL up and running (at least, that's been my
> experience in a number of different settings).
>   
Well, I don't think we need traits UI, and I don't imagine traits itself 
is hard to build, although I could be wrong (I always use the 
Ubuntu/Debian packages).
> 3. Chaco - my general mindset on this is that Chaco is great for
> plotting any and everything in a traits gui, but MPL is much better
> for the quickcalculations and plots that I make every day as a
> scientist.  When a critical mass is reached it becomes better to
> integrate a tool into a GUI app, MPL becomes more difficult to manage
> and chaco is a better tool.  But I think it makes a lot of sense to
> leverage MPL most as the wonderful "quick-and-dirty" command-line
> interactive plotting environment that it is rather than making it
> application-centric, which is where I can envision it going as soon as
> it has to run with traits.
>
> Now a great idea would be to include optional support for things like
> setting configuration files from a traits interface - I know I've seen
> talk of doing this for matplotlibrc at some point, and I'd definitely
> use that.  Simlarly, some sort of traits-level extension to support
> more interactive plots and better layout seems like it could be done
> without requiring the core to use traits.
>   
OK, but these don't address my main concern that the core layout of MPL 
is an unwieldy beast.

Anyhow, as I'm way too busy to think about any real coding on MPL's core 
right now, this is just cheap talk...

-Andrew

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] curvelinear coordinate support in axes_grid and a possible refactoring of mpl.

[Andrew Straw]

John Hunter wrote:
> On Thu, Jul 30, 2009 at 1:56 PM, Jae-Joon Lee wrote:
>
>   
>>  ps. Are we having a sprint during the scipy conference by the way? I
>> may join remotely.
>> 
>
> I'll definitely be there Sat and Sun, so having you join in remotely
> would be great.  I haven't organized any official topics yet, but we
> have plenty to do so I think we'll just look at the skills and
> interests of those joining live or virtually and hammer away.
>   

I'll be there, too. I think an MPL sprint would be very good.

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] New spines capabilities question

[Andrew Straw]

Brian Granger wrote:
>  
>
> I think this happens in all mpl graphs, you just don't see it.  The
> axis limits are set to -2..2, and the sine is draw from -2..2.  The
> linewidth extends beyond 2, so it is clipped by the axes clipping to
> the bounding rectangle.  Normally you don't see this, because visually
> it is under the surrounding axes black edge.  
>
>
> Yes, I saw that it looks like it happens under the axes clipping.
>
>  
>
> You can either set the
> ylimits wider:
>
>   ax.set_ylim(-2.1, 2.1)
>
>
> But would this also make the spine have the larger limits?  Basically, 
> I want know if the spines can be used to create Tufte-style 
> range-frames.  Am I correct in thinking that these spines provide that?
Although I don't have a precise definition of "Tufte-style range 
frame"to go by, I think my intention was to do exactly what you're after.

I don't know how hard it would be to automatically increase the clipping 
box size by the size (line width or marker size, including edge width) 
of any artists on the border -- I imagine it may require querying 
backends in a way they don't currently support. I'll talk about this 
with John at SciPy 09.

>   Or is there another way to get a range-frame?
>  
>
> or turn clipping off
>
>  ax.plot(x,y, clip_on=False)
>
>
> This looks hopeful and I will give it a shot.
That's what I've been doing.

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] not clipping objects in a plot

[Andrew Straw]

jason-s...@creativetrax.com wrote:
> On this thread:
>
> http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/msg05383.html
>
> clip_on was a suggested way of getting around the clipping that happens 
> at the edge of a frame.  In the Sage project, we are always setting the 
> limits on the axes via set_xlim and set_ylim.  Is there any way to get 
> the lines and circles that pass across the edge of the usual clip 
> boundary to still be drawn, even if we have set the xlim and ylim of the 
> axis?
>
> Basically (using an example from the gallery), is there a way to get the 
> scatter plot circles below not clipped, while still having the y-axis 
> only go from -2 to 2?  If not, is there a way to easily calculate the 
> protrusion of the various objects, like the circles below, so we know 
> how much to adjust the axes to just include the circles?
>   
Another idea would be to disable clipping specifically for any markers
at xlim[0] <= markerx <= xlim[1].

I'll talk about this with John and other interested parties at the SciPy
conference (will you be there?) and hopefully address this issue during
the sprint, where I'm planning to work on MPL.

-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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] buildbot status

[Andrew Straw]

Hi All,

At the SciPy 09 sprints I worked with John Hunter on our automated build
and test infrastructure. It's still not *quite* there, but I thought I'd
point out a few things at this stage. (Much of this email is
more-or-less a status update for John.)

0. We have automated tests now running triggered by SVN commits. Most of
the image comparison tests are running and passing, but there are a few
failures. One seems to be a real bug that has cropped up since James
Evans generated the baseline image suite. Another seems to have been
fixed in that time. The rest seem to be a font rendering issue that is
still unresolved.

Real bug?:
http://mpl.code.astraw.com/#test-matplotlib-testaxes-formatter-ticker-005

Fixed?:
http://mpl.code.astraw.com/#test-plots-testpolar-polar-wrap-180

1. The buildbot waterfall display is online at
http://mpl-buildbot.code.astraw.com/waterfall

2. A number of tests are failing because of font placement and/or font
anti-aliasing. (The baseline images seem to have slightly different font
images than generated ones, and generated ones are different on Mac OS X
and Ubuntu.) I think John is going to have an attempt at allowing font
anti-aliasing to be disabled. We'll see if that fixes it. The bug is
filed at
https://sourceforge.net/tracker/?func=detail&aid=2843243&group_id=80706&atid=560720


3. I've figured out how to get the buildslaves to upload to the
buildmaster. It turns out this is supported in buildbot. (See
http://djmitche.github.com/buildbot/docs/0.7.10/#Transferring-Files )

4. I have made use of the upload ability to gather the rendered,
baseline, and absdiff images in the case of failed tests. Right now,
with the help of a simple  script to generate static html pages via rst,
I'm publishing these onto http://mpl.code.astraw.com/ . (We could use a
similar mechanism to publish nightly builds.) I'd like to make links in
the appropriate place in the buildbot output to the image comparison
pages, but I have not dug into the buildbot sources to figure out how to
do that.

5. John (or other devs), I can give you login access to the buildmaster
on my VPS if you send me an ssh public key to use for that purpose.

6. The buildslave that John installed on the Sage project's Mac machine
seems to be failing to resolve the hostname
`matplotlib.svn.sourceforge.net', and thus can no longer build because
it can't pull down svn commits. John--do you have any idea what's going
on here?

Hopefully, we'll have all this sorted out soon.

-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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] buildbot status

[Andrew Straw]

Andrew Straw wrote:
> I'm publishing these onto http://mpl.code.astraw.com/
Which I have now actually created a DNS entry for. If you tried and got
an error like "Address not found, can't find the server at
mpl.code.astraw.com", you should have better luck in a few minutes/hours
as the name propagates around DNS. For the impatient unix users, you can
add the line "67.223.235.187   mpl.code.astraw.com" to your /etc/hosts
to bypass the DNS lookup and hardcode the address.

-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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] MPL testing: the last failing test on the buildbot and future ideas

[Andrew Straw]

Hi,

I'm hoping to elicit the help of a developer who can fix the last
remaining failing test on the Mac buildslave. In a nutshell, there looks
to be a regression with the interaction between Axes.autoscale_view()
and the xunits kwarg of Axes.plot(). I have posted a bug report at
https://sourceforge.net/tracker/?func=detail&aid=2846058&group_id=80706&atid=560720



I'd like to ask for a bit of help fixing this one, because I'd then like
to work on a few more things, which I think will be easier (mentally, at
least), if we have all tests passing on at least one platform.

* borrow (and maybe extend) scipy's known failing test decorator so that
known issues don't elicit test failures. (E.g. font placement
differences between Ubuntu and Mac OS X. see
https://sourceforge.net/tracker/?func=detail&aid=2843243&group_id=80706&atid=560720
for more info.)

* automatically send notifications to somewhere (to where?) when tests
start failing

* write documentation for developers and patch submitters describing how
to write unit tests for MPL -- both image based and more traditional kinds.

* get my Windows virtual machine doing this same dance

* automatically upload daily builds of binaries for Win and Mac

* adding more machines to the buildbot system

Of course, I'm happy to help if anyone wants to contribute to these or
other ideas. I plan to slowly chip away at this stuff over the coming
weeks and months.

-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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] semilogx and semilogy don't reset linear scale

[Andrew Straw]

Eric Firing wrote:
> Tony S Yu wrote:
>   
>> Did this email ever appear on list? I didn't see it after sending my  
>> original post, but I found it on the Sourceforge mail archives. I'm  
>> trying a different email address as an experiment.
>> 
>
> Tony,
>
> It did appear the first time, but I guess everyone who saw it figured 
> someone else would deal with it.
>   
>> In any case, any comments on the patch?
>> 
>
> Looks reasonable to me.  I will apply it.
>   
I think this caused the test_matplotlib.TestAxes.empty_datetime test to
fail. You can see the result at
http://mpl.code.astraw.com/mac-osx-x86-sage/test_matplotlib.TestAxes.empty_datetime/overview.html

Specifically, it looks like the farthest left xticklabel is no longer
getting displayed. Personally, I think it looks better this way, but now
that the test suite is coming online, we will finally start noticing
little things like this.

Eric, if you think the new image is OK, can you download it from
http://mpl.code.astraw.com/mac-osx-x86-sage/test_matplotlib.TestAxes.empty_datetime/actual.gif
and then check it into
test/test_matplotlib/baseline/TestAxes/empty_datetime.png

In fact, I just checked in a KnownFail test decorator heavily based on
numpy's implementation, so once this test starts passing, the Mac OS X
buildslave should have all the tests returning success or knownfail.

Thanks,
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] semilogx and semilogy don't reset linear scale

[Andrew Straw]

Eric Firing wrote:
>> Specifically, it looks like the farthest left xticklabel is no longer
>> getting displayed. Personally, I think it looks better this way, but now
>> that the test suite is coming online, we will finally start noticing
>> little things like this.
> 
> I agree that the newer version, without the first label, is better--but
> I can't imagine how the change to semilogx and semilogy could make a
> difference like this.  It must be something else.

Well, if you look at

http://mpl-buildbot.code.astraw.com/builders/build%20and%20test%3A%20Mac%20OS%20X%20x86%20(sage%20buildslave)/builds/34/steps/test/logs/stdio

versus

http://mpl-buildbot.code.astraw.com/builders/build%20and%20test%3A%20Mac%20OS%20X%20x86%20(sage%20buildslave)/builds/35/steps/test/logs/stdio

that's where the difference happened, thus leading to my assertion. What
changed between those two builds was r7585. Perhaps something else is
responsible, though...

>>
>> Eric, if you think the new image is OK, can you download it from
>> http://mpl.code.astraw.com/mac-osx-x86-sage/test_matplotlib.TestAxes.empty_datetime/actual.gif
>>
>> and then check it into
>> test/test_matplotlib/baseline/TestAxes/empty_datetime.png
> 
> Done (with *.png, not actual.gif).

Ahh yes, good catch. Thanks for correcting this.

> 
> Eric
> 
>>
>> In fact, I just checked in a KnownFail test decorator heavily based on
>> numpy's implementation, so once this test starts passing, the Mac OS X
>> buildslave should have all the tests returning success or knownfail.

And look -- a buildslave is not failing!
http://mpl-buildbot.code.astraw.com/waterfall

-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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] semilogx and semilogy don't reset linear scale

[Andrew Straw]

Jouni K. Seppänen wrote:
> Eric Firing  writes:
>
>   
>> Andrew Straw wrote:
>> 
>>> Eric Firing wrote:
>>>   
>>>>> Specifically, it looks like the farthest left xticklabel is no longer
>>>>> getting displayed. Personally, I think it looks better this way, but now
>>>>> that the test suite is coming online, we will finally start noticing
>>>>> little things like this.
>>>>>   
>>>> I agree that the newer version, without the first label, is better--but
>>>> I can't imagine how the change to semilogx and semilogy could make a
>>>> difference like this.  It must be something else.
>>>> 
>>> Well, if you look at
>>> http://mpl-buildbot.code.astraw.com/builders/build%20and%20test%3A%20Mac%20OS%20X%20x86%20(sage%20buildslave)/builds/34/steps/test/logs/stdio
>>> versus
>>> http://mpl-buildbot.code.astraw.com/builders/build%20and%20test%3A%20Mac%20OS%20X%20x86%20(sage%20buildslave)/builds/35/steps/test/logs/stdio
>>>
>>> that's where the difference happened, thus leading to my assertion. What
>>> changed between those two builds was r7585. Perhaps something else is
>>> responsible, though...
>>>   
>> 7584 was the Tony's change on the branch; 7585 was the svnmerge to the 
>> trunk, which pulled in earlier changes that had not been merged yet. The 
>> others were just documentation, though, so I am still mystified.  Oh, well.
>> 
>
> If I'm reading the waterfall display correctly, it looks like my commit
> 7597 changed the result again. I only touched documentation and
> docstrings... have you tried running the buildbot several times on the
> same sources?
>   

Curiouser and curiouser...

No, I hadn't considered that it might be non-deterministic. However,
looking at the absdiff image of test_matplotlib.TestAxes.empty_datetime,
this is a totally different failure than we were seeing with Eric's
patch. I should probably start archiving the results of the failed
images so we can go back in time looking at these things.

I'm going to ponder this for a while.

-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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] buildbot font discrepancies

[Andrew Straw]

John Hunter wrote:
> On Sun, Aug 30, 2009 at 4:17 PM, John Hunter wrote:
>> According to RobK, you can reconfigure your ubuntu system to turn
>> these off.  He suggests:
>>
>>  To use autohinting, use the hint in this post, or just run the
>> following command:
>>
>>  sudo dpkg-reconfigure fontconfig-config
>>
>>  then choose “autohinter”, then choose “always”, then choose “no”
> 
> If that doesn't work, this guy has more involved instructions on how
> to rebuild ubuntu libfreetype and disable the bytecode patch
> 
> http://ubuntuforums.org/showthread.php?t=84359

OK, I disabled all Ubuntu patches to libfreetype and recompiled and
re-installed it. Unfortunately, I'm still getting the same failures.

Then I additionally installed fontconfig-config and did the
dpkg-reconfigure fontconfig-config step, setting everything to "Never".
Same failures.

These font errors make me unhappy. I think we should test some very
simple pure libfreetype C program outputs generated on the various
machines. I've just been playing with ftview, but that doesn't seem to
have a command-line interface to save directly to a file.

-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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] buildbot font discrepancies

[Andrew Straw]

Michael Droettboom wrote:
> You can also turn hinting off at runtime by passing a flag to freetype.  
> matplotlib currently exposes this flag in the FT2Font extension, but we 
> don't really expose the option to the user.  It would be simple enough 
> to make it an rcParam, though, which could then be set to "no hinting" 
> by the test infrastructure just to rule out some of these moving parts.  
> Of course, this doesn't rule out differences between different version 
> numbers of freetype.
>   
I think that, for now, we're going have the buildslaves run the same
version of freetype and have hinting disabled at freetype compile time.
(Right now we're at freetype 2.3.5.) If you want to go ahead and add a
"disable hinting" rcParam, it may come in handy in the future, but I
don't think it's a high priority right now given that we have to ensure
freetype version and thus will probably be compiling by hand it for any
buildslave.
> Another thing to look into might be some sort of fuzzy or perceptual 
> diffing approach.  Freddie Witheren (our GSoC student) has been looking 
> into pdiff (http://pdiff.sf.net) for testing mathtex.  I don't know what 
> the current status of that is.  In general, I think I prefer the goal of 
> exact determinism, but if this becomes a recurring problem down the 
> road, it may be easier to just try to "gloss over" these minor font 
> differences.
>   
The image difference approach we're currently using doesn't search for
an exact duplication but just that the error is under some threshold. I
haven't looked at the algorithm, but the printout says "RMS error". Now
that all the tests are passing, I'm going to direct my energies to
expanding the test infrastructure, especially making it easy for other
devs to write tests.

We may have to revisit these issues if, once we get a greater diversity,
the buildslaves start failing again.

-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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] spines with 'axes' positions show in wrong place?

[Andrew Straw]

jason-s...@creativetrax.com wrote:
> Do the right and top spines display correctly when the position is set 
> using 'axes' coordinates?
>   
Jason,

This looks like a bug. I'll look into it. Please ping me in a few days
if you haven't heard back.

-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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Current recommended method for Windows builds?

[Andrew Straw]

Stan West wrote:
> Greetings.  I had previously succeeded at building matplotlib in Windows XP
> using Visual Studio 2003.  (Thanks to Charlie Moad for much guidance!)  I'm
> now running Win7RC and want to set up builds in that OS for Python 2.5.  I
> read in the messages of May 28 about the release build script at
> trunk/matplotlib/release/win32 in SVN.  So, I'm wondering whether to (a) build
> as I did previously, with VS2003 or mingw using trunk/matplotlib/setup.py and
> dependencies in win32_static, or (b) build with mingw using
> trunk/matplotlib/release/win32/Makefile and dependencies installed there.
> What approach is recommended currently?
>
> Regarding (a), I saw Charlie's message of Apr. 10 about an updated
> win32_static.zip file, but requests for
> http://matplotlib.sourceforge.net/win32_static.zip and win32_static_vs.zip
> yield 404s, while win32_static.tar.gz and win32_static_vs.tar.gz date
> internally from 2005 and 2006, respectively.  Is the newer archive available?
>
> Regarding (b), would I still install ActiveTCL to \Tcl and the GTK dev package
> to \GTK, as in approach (a)?
>   

Hi Stan,

(This is unfortunately not an answer to your questions.)

I am interested in getting the buildbot infrastructure to build
automatic nightly binaries for Windows (XP was my thought, but 7 would
also be good). If you you'd be willing to perform the work to automate
build and installation from the svn repo on either your own machine or a
virtual machine running in my linux box (presuming I could get Windows 7
running in VirtualBox), you could itch your own scratch as well as help
the MPL community.

The basic idea is that the buildbot triggers a script (or scripts) on
the buildslave machine. In particular, I have written
test/_buildbot_install.py and test/_buildbot_test.py to sequentially
install (to a virtualenv) and test MPL. Right now these are only tested
on Ubuntu, but I wrote them to be cross platform. John Hunter wrote
test/_buildbot_mac_sage.sh to do the same steps on a Mac, but it's very
installation-specific. The buildmaster simply calls these scripts,
failing if the exit code is non-zero.

It is still on my TODO list to build binaries and upload to a server,
but I think this will be pretty trivial once the first part is worked out.

Regardless of whether you can help with the buildbot automation part, if
you take notes about what you did, I'm sure it will help whomever comes
after you in the process.

-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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Current recommended method for Windows builds?

[Andrew Straw]

Andrew Straw wrote:
> I am interested in getting the buildbot infrastructure to build
> automatic nightly binaries for Windows (XP was my thought, but 7 would
> also be good). If you you'd be willing to perform the work to automate
> build and installation from the svn repo on either your own machine or a
> virtual machine running in my linux box (presuming I could get Windows 7
> running in VirtualBox)
Hmm, it seems MS disabled Windows 7 RC downloads. So I'm unable to
create such a virtual machine.

-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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] [Fwd: Re: [Numpy-discussion] snow leopard issues with numpy]

[Andrew Straw]

It looks like we may be on the hook for some c++ ABI breakage with
Apple's latest OS (Snow Leopard). See the attached email forwarded from
the numpy mailing list.

-Andrew
--- Begin Message ---
On Fri, Sep 4, 2009 at 1:49 AM, Charles R
Harris wrote:
>
>
> On Thu, Sep 3, 2009 at 10:39 AM, Robert Kern  wrote:
>>
>> On Thu, Sep 3, 2009 at 11:13, Charles R Harris
>> wrote:
>> >
>> >
>> > On Thu, Sep 3, 2009 at 10:02 AM, Wolfgang Kerzendorf
>> >  wrote:
>> >>
>> >> I just installed numpy and scipy (both svn) on OS X 10.6 and just got
>> >> scipy to work with Robert Kern's help. Playing around with numpy I got
>> >> the following segfault:
>> >> http://pastebin.com/m35220dbf
>> >> I hope someone can make sense of it. Thanks in advance
>> >>      Wolfgang
>> >
>> > I'm going to guess it is a python problem. Which version of python do
>> > you
>> > have and where did it come from?
>>
>> Or a matplotlib problem. _path.so is theirs.
>>
>
> Likely, then. I had to recompile matplotlib from svn when I upgraded to
> Fedora 11.

Looks like C++ code, and snow leopard has gcc 4.2, which is likely to
have some subtle ABI incompatibilities with 4.0 (the one from
leopoard). So yes, a matplotlib rebuild would be the first thing to
try.

cheers,

David
___
NumPy-Discussion mailing list
numpy-discuss...@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
--- End Message ---
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Matplotlib-buildbot] buildbot failure in matplotlib on Ubuntu 8.04, Python 2.4, amd64

[Andrew Straw]

mpl-buildmas...@code.astraw.com wrote:
> STATUS: Failure
> revision: 7635 ( 
> http://matplotlib.svn.sourceforge.net/matplotlib/?view=rev&rev=7635 )
>   

I just installed dvipng on the test machines, which I think will make
them pass this test next time.

But it looks from the traceback

http://mpl-buildbot.code.astraw.com/builders/Ubuntu%208.04%2C%20Python%202.5%2C%20amd64/builds/78/steps/test/logs/stdio

that the new textpath module is importing texmanager, which will fail if
dvipng is not installed. Will this cause similar breakage on people's
machines if we they don't have dvipng installed?

Should I remove dvipng from the buildslaves to check for this kind of
thing in the future, or should I keep it installed so we can test
functionality that uses it?

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Matplotlib-buildbot] buildbot failure in matplotlib on Ubuntu 8.04, Python 2.4, amd64

[Andrew Straw]

Jae-Joon Lee wrote:
> On Fri, Sep 4, 2009 at 4:10 PM, Jae-Joon Lee wrote:
>   
>> Yes, this should be my fault. I didn't expect that importing a
>> texmager would raise an exception. I'll fix it soon.
>>
>> 
>
> I just committed a changeset that I think would fix this (the
> textpath.py imports texmanager only when required). But I couldn't
> test it as I don't have a machine w/o dvipng at this time.
>   
OK, I added a buildslave without dvipng and the latest svn passes.
Thanks Jae-Joon.

Chalk another one up for the buildbot -- even with only 17 tests, we're
catching a lot of interesting things. Still to be resolved is the empty
datetime issue:
https://sourceforge.net/tracker/?func=detail&aid=2850075&group_id=80706&atid=560720

-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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] spines with 'axes' positions show in wrong place?

[Andrew Straw]

jason-s...@creativetrax.com wrote:
> https://sourceforge.net/tracker/?func=detail&aid=2852168&group_id=80706&atid=560720
>   
I fixed this in svn r7638. Thanks for the report.

Can a dev merge r7638 from the v0_99_maint branch into the trunk? I'm
having a hard time figuring out svnmerge and I really don't feel like
fighting it right now. (I read the docs at
http://matplotlib.sourceforge.net/devel/coding_guide.html#using-svnmerge
but I still can't get it to work.)

-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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] new simplified tests; location of test baseline images

[Andrew Straw]

Today I committed to svn a simplified testing infrastructure, which I've
committed to matplotlib/testing/*. A few sample tests are in
matplotlib/tests/*. I also wrote some docs, which are now in the
developer coding guide. See that (
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/doc/devel/coding_guide.rst?revision=7654&view=markup
, starting at line 675) for information about how to write tests.

Now, I have a question. As currently written, the baseline (a.k.a.
expected) images are stored in the sample_data directory and
matplotlib.cbook.get_sample_data() downloads the images. However, I
suspect that the Mac Sage buildslave doesn't like to download stuff 
while not in an interactive login. (Remember the initial problems
running tests on that machine?) That's probably a good indication that
we probably don't want to require network access to run the tests. So,
the next question is whether we want to install baseline images with
standard MPL installs so that any user can run the full test suite? That
would be my preference, as it would be the simplest and most robust to
implement, but it comes at the cost of using additional disk space.
Otherwise, I'm open to suggestions.

(John, to confirm my suspicions about the network access issue, could
you ssh into the Sage Mac and run test/_buildbot_mac_sage.sh by hand to
see if that eliminates the bus error we're getting when run from the
buildbot?)

-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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] new simplified tests; location of test baseline images

[Andrew Straw]

Andrew Straw wrote:
> Today I committed to svn a simplified testing infrastructure, which I've
> committed to matplotlib/testing/*. A few sample tests are in
> matplotlib/tests/*. I also wrote some docs, which are now in the
> developer coding guide. See that (
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/doc/devel/coding_guide.rst?revision=7654&view=markup
> , starting at line 675) for information about how to write tests.
>   
I should also say that I plan to migrate the existing tests to this new
simplified architecture. You can get your testing feet wet by joining
the fun.

-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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] new simplified tests; location of test baseline images

[Andrew Straw]

John Hunter wrote:
> I was able to run the buildbot mac script when logged into sage with::
>   
So it seems the bus error on Mac is due to networking (DNS lookups)
being broken in non-interactive logins. This is a pain for the
get_sample_data() approach. (Although I suspect we could work around it
by giving the IP address of the svn repo just like we did for the main
MPL checkout. In this case, however, the IP address would be hardcoded
into cbook.)
> I am not sure I want to distribute the baseline images with the main
> mpl distribution, but I am open to considering it.  As the number of
> tests and baseline images grows, which hopefully will happen soon,
> this could potentially become large -- the reason I added
> get_sampledata in the first place was to get the distribution size
> down.  We could add support to get_sampledata to use an environment
> variable for the cache directory.  Then I could do an svn checkout of
> the sample_data tree and svn up this dir in my buildbot script.  If I
> point the sample data environment var to this directory, it would have
> the latest data for the buildbot and would not need to make an http
> request (it is odd though that svn checkouts on the sage buildbot work
> fine even when not interactively logged in but http requests
> apparently do not).
>   

After letting the implications settle a bit, I think I'm in favor of
baseline images living in the matplotlib svn trunk so that they're
always in sync with the test scripts and available to those who have
done svn checkouts. Another important consideration is that this
approach plays will with branching the repo.

Just because they'd be in the main repository directory, though, doesn't
mean that we have to ship source or binaries with them in place --
that's a decision that could be discussed when release day gets closer.
Many of these images will be .pngs with large regions of white, so
they're relatively small files. But, I agree, hopefully there will be a
lot of tests and thus a lot of images, which will add up. As far as the
linux packaging goes -- the packagers can decide how to ship their own
binaries, but I'm sure they'd appreciate a mechanism for shipping the
test image data separately from the main binary package. This could
cause us to come up with a nice mechanism which we enable when building
Mac and Windows binary packages. As for the source packages, I think I'd
tend toward including the test images for more or less the same reasons
as including them in the svn trunk.

Also, we could set it up such that we skip image_comparison tests if the
baseline images weren't available (or simply not compare the results).

> If you think the sample_data w/ support for local svn checkouts is the
> way to go for the baseline data and images, let me know.  I would like
> to utilize a subdir, eg, sample_data/baseline, if we go this route, to
> keep the top-level directory a bit cleaner for user data.   We could
> also release a tarball of the sample_data/baseline directory with each
> release, so people who want to untar, set the environment var and test
> could do so.
>   
OK, I will move them to a new subdir if we decide to keep the
sample_data approach. I thought I read a preference to keep sample_data
flat, and I wasn't sure about Windows path names.
> I am not sure this is the right approach by any means, just putting it
> up for consideration.  One disadvantage of the sample_data approach is
> that it would probably work well with HEAD but not with releases,
> because as the baseline images changes, it becomes difficult to test
> existing releases against it, which may be assuming a prior baseline.
> This is why I mentioned releasing the baseline images too, but it does
> raise the barrier for doing tests.
>   
Likewise, I'm not sure my idea is best, either, but I think it plays
best with version control, which IMO is a substantial benefit.

> I should have some time today to play as well.  One thing I would like
> to do is to continue the clean up on naming conventions to make them
> compliant with the coding guide.  Thanks for your efforts so far on
> this -- one thing left to do here that I can see is to rename the
> modules to test_axes.py rather than TestAxes.py, etc..., and to finish
> renaming the methods which use the wrong convention, eg
> TestAxes.TestAxes.tearDown should be test_axes.TestAxes.tear_down
> (module_lower_under.ClassMixedUpper.method_lower_under).
I think we should forget about subclassing unittest.TestCase and simply
use flat functions as our tests. In particular, we should drop setUp and
tearDown altogether (which IIRC have to be named what they are because
they're a subclass of unittest.TestCase and override baseclass methods).
If we need any setup and teardown functionality, let's make a new
decorator to support it.

Then, I think the tests in test/test_matplotlib/TestAxes.py should go
into lib/matplotlib/tests/test_axes.py and each test should be it's own
function at module level, su

Re: [matplotlib-devel] new simplified tests; location of test baseline images

[Andrew Straw]

John Hunter wrote:
> On Sun, Sep 6, 2009 at 3:44 PM, John Hunter wrote:
>   
>> I am working on this stuff now and am near a solution for the empty
>> datetime bug which is cleaner and more general.  I'll populate tests
>> for this stuff so just let me know where to put the baselines.
>> 
>
> Hey Andrew -- I finally got the new date tests working.  Just run
> lib/matplotlib/tests/test_dates.py to generate the new baseline images
> and add them wherever you want them to go.  Or if you'd rather I add
> them create the baseline images dirs in svn and I'll add/commit them.
> But I'll be offline for a bit so go ahead and add them if you want.
>   
OK, great, we now have several examples of tests in matplotlib.tests,
and they seem to be passing on the buildbot slaves now.

I added the images to lib/matplotlib/tests/baseline_images.

I also removed ".png" from the filenames in anticipation of auto-backend
selection and comparison of other formats. (However, that's not
something I plan to implement any time soon.)

We now have 26 tests running on the buildbots and 11 with the plain
"import matplotlib; matplotlib.test()", which tests only the new
simplified tests. That means there are 15 tests left in the original
testing infrastructure that remain to be ported over, which I don't
think will be too hard now that I ported over JPL's units stuff into
matplotlib.testing.jpl_units and test_matplotlib/TestAxes.py to
matplotlib.tests.test_axes.py.

-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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] test_image

[Andrew Straw]

John Hunter wrote:
> I must be missing something obvious, but I tried to add a new module
> to lib/matplotlib/tests called test_image, which has a single method
> so far, test_image_interps.  I added the standard decorator and
> baseline image, and I can see it being installed in the stdio on the
> sage buildbot
>
> http://mpl-buildbot.code.astraw.com/builders/Mac%20OS%20X%2C%20Python%202.6%2C%20x86/builds/109/steps/test/logs/stdio
>
> but I do not see an additional test being run (I still get the usual
> 26 tests).  Is there another step to getting this to be picked up by
> the test harness?
>   
As described in the "Creating a new module in matplotlib.tests" of the 
developer coding guide (see line 780 of 
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/doc/devel/coding_guide.rst?revision=7664&view=markup
 
):

Let's say you've added a new module named 
``matplotlib.tests.test_whizbang_features``.  To add this module to the 
list of default tests, append its name to ``default_test_modules`` in 
:file:`lib/matplotlib/__init__.py`.


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Nose tests: Font mismatch

[Andrew Straw]

John Hunter wrote:
> Perhaps with hinting turned off this won't be necessary.  Ie, maybe we
> can get more agreement across a wide range of freetype versions w/o
> hinting.  Are you planning on committing the unhinted baselines?
I have a presentation to give tomorrow, so I'd just as soon let you and
Michael fight the flood of red that is about to occur! :)

But I can step up again later in the week for with more time. In the
meantime, why don't I just keep my eye on my email inbox but stay out of
the code and baseline images for the most part?

-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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Nose tests: Font mismatch

[Andrew Straw]

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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Nose tests: Font mismatch

[Andrew Straw]

Michael Droettboom wrote:
> On 09/08/2009 10:24 AM, John Hunter wrote:
>   
>> On Tue, Sep 8, 2009 at 8:54 AM, Michael Droettboom  wrote:
>>
>> 
>>> I've been only skimming the surface of the discussion about the new test
>>> framework up until now.
>>>
>>> Just got around to trying it, and every comparison failed because it was
>>> selecting a different font than that used in the baseline images.  (My
>>> matplotlibrc customizes the fonts).
>>>
>>> It seems we should probably force "font.family" to "Bitstream Vera Sans"
>>> when running the tests.  Adding "rcParam['font.family'] = 'Bitstream Vera
>>> Sans'" to the "test" function seems to do the trick, but I'll let Andrew
>>> make the final call about whether that's the right change.  Perhaps we
>>> should (as with the documentation build) provide a stock matplotlibrc
>>> specifically for testing, since there will be other things like this?  Of
>>> course, all of these options cause matplotlib.test() to have rcParam
>>> side-effects.  Probably not worth addressing now, but perhaps worth noting.
>>>  
>>>   
>> We do have a matplotlibrc file in the "test" dir (the dir that lives
>> next to setup.py, not lib/matplotlib/tests.  This is where we run the
>> buildbot tests from.  It might be a good idea to set the font
>> explicitly in the test code itself so people can run the tests from
>> any dir, but I'll leave it to Andrew to weigh in on that.
>>
>> 
> Sure.  If we *don't* decide to set it in the code, we should perhaps add 
> a line suggesting to "run the tests from lib/matplotlib/tests" in the 
> documentation.  An even better solution might be to forcibly load the 
> matplotlibrc in that directory (even if it's an install directory) when 
> the tests are run.
>   
While the default test usage should probably set as much as possible to 
ensure things are identical, we also want to be able to test other code 
paths, so I think I'll add some kind of kwarg to matplotlib.test() to 
handle non-testing-default rcParams. I think setting lots of things, 
including the font, explicitly in the default case is a good idea.

Question for the rcParams experts: Can we save a copy of it so that we 
can restore its state after matplotlib.test() is done? (It's just a 
dictionary, right?)
>>
>> 
>>> I am also still getting 6 image comparison failures due to hinting
>>> differences (I've attached one of the diffs as an example).  Since I haven't
>>> been following closely, what's the status on that?  Should we be seeing
>>> these as failures?  What type of hinting are the baseline images produced
>>> with?
>>>  
>>>   
>> We ended up deciding to do identical source builds of freetype to make
>> sure there were no version differences or freetype configuration
>> differences.  We are using freetype 2.3.5 with the default
>> configuration.  We have seen other versions, eg 2.3.7, even in the
>> default configuration, give rise to different font renderings, as you
>> are seeing.  This will make testing hard for plain-ol-users, since it
>> is a lot to ask them to install a special version of freetype for
>> testing.  The alternative, which we discussed before, is to expose the
>> unhinted option to the frontend, and do all testing with unhinted
>> text.
>>
>> 
> I just committed a change to add a "text.hinting" rcParam (which is 
> currently only followed by the Agg backend, though it might make sense 
> for Cairo and macosx to also obey it).  This param is then forcibly set 
> to False when the tests are run.
>
> 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 ;)
>   
I think we compiled freetype with no hinting as a configuration option, 
so I don't anticipate a failure.

Of course, now I look at the waterfall display, see a bunch of green, 
think "this looks suspicious" (what does that say about my 
personality?), click the log of the stdio of the "test" components and 
see a whole bunch of errors. It seems when I switched over to the 
matplotlib.test() call for running the tests, I forgot to set the exit 
code. Let me do that right now. Expect a flood of buildbot errors in the 
near future...

> Hopefully we can find a way for Joe Developer to run these tests without 
> a custom build of freetype.
>   
Yes, I completely agree. In the matplotlib.testing.image_comparison() 
decorator, we right now have only a single image comparison algorithm 
based on RMS error. Perhaps we could try the perceptual difference code 
you linked to? Also, maybe we could simply turn font rendering off 
completely for a majority of the tests? Or maybe the tests should be run 
with and without text drawn, with much lower error tolerances when 
there's no text?

The nic

Re: [matplotlib-devel] Nose tests: Font mismatch

[Andrew Straw]

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

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Nose tests: Font mismatch

[Andrew Straw]

John Hunter wrote:
> On Tue, Sep 8, 2009 at 12:34 PM, Andrew Straw 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


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Nose tests: Font mismatch

[Andrew Straw]

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

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Nose tests: Font mismatch

[Andrew Straw]

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.

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] problem plotting log (works with 0.98.5.3)

[Andrew Straw]

Michael Droettboom wrote:
> Yes -- a bug was introduced where non-finite values were no longer being 
> ignored by the data extents finder.  This has now been fixed on the 
> 0.99.x branch (r7774) and the trunk.
>   
Hi Mike,

This would seem like something useful to write a test for to make sure
these regressions don't slip in in the future. Would it be easy to write
a test (image based or non image based)? If so, would you mind doing it
and checking it into the trunk? You can look at
lib/matplotlib/tests/test_axes.py and lib/matplotlib/tests/test_basic.py
for examples.

Also, apologies about the buildbot master being down last night and this
morning. It's back online now.

-Andrew

--
Come build with us! The BlackBerry® 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/devconf
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] regression on polar plot - does not "circle" with 0.99.x

[Andrew Straw]

Michael Droettboom wrote:
> Thanks.  The subslicing optimization added in 0.99 was truncating the 
> polar path.  Subslicing has been made more "cautious" now and will only 
> be applied when the axes are rectilinear and non-logarithmic.
>
> Interestingly, there was already a test in the test framework for this 
> bug, but the baseline image was wrong :)
I see you fixed that, too -- thanks. I can't remember the history of
this one particular test -- I think maybe I inherited it without a test
image or perhaps I just over-enthusiastically copied a broken image
without realizing it as such.

These unit tests have already shown their worth I think (fixing
non-deterministic layout, getting a grip on freetype, etc.), and their
value in preventing mistakes and regressions from creeping in is hard to
perceive but I think is also very real. As more and more tests are added
(and broken baseline images and test cases are fixed), the number of
regressions will almost certainly drop.

-Andrew

--
Come build with us! The BlackBerry® 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/devconf
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] plt.figure() causes crash on OS X 10.5.7, Py26 binaries

[Andrew Straw]

David Warde-Farley wrote:
> On 18-Sep-09, at 6:42 PM, David Warde-Farley wrote:
>   
>>   File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
>> python2.6/site-packages/ipython-0.10-py2.6.egg/IPython/Shell.py", line
>> 627, in __init__
>> user_ns,user_global_ns,b2 =
>> self._matplotlib_config(name,user_ns,user_global_ns)
>>   File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
>> python2.6/site-packages/ipython-0.10-py2.6.egg/IPython/Shell.py", line
>> 556, in _matplotlib_config
>> import matplotlib.pylab as pylab
>>   File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
>> python2.6/site-packages/matplotlib/pylab.py", line 206, in 
>> from matplotlib import mpl  # pulls in most modules
>>   File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
>> python2.6/site-packages/matplotlib/mpl.py", line 1, in 
>> from matplotlib import artist
>>   File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
>> python2.6/site-packages/matplotlib/artist.py", line 5, in 
>> from transforms import Bbox, IdentityTransform, TransformedBbox,
>> TransformedPath
>>   File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
>> python2.6/site-packages/matplotlib/transforms.py", line 34, in  
>> 
>> from matplotlib._path import affine_transform
>> ImportError: numpy.core.multiarray failed to import
>> 
>
> Looking a little harder at this (after downloading the source) I'm  
> positively at a loss, since multiarray doesn't seem to be explicitly  
> imported anywhere in matplotlib. Furthermore, importing  
> numpy.core.multiarray from ipython works just fine.
>
> Moreover, I just built matplotlib-0.99.1rc1 from source and the  
> problem doesn't manifest. _Weird_. Any idea what's going on?
>   
Maybe the MPL binary was built with a numpy svn version that had API
incompatibilities with numpy releases?



--
Come build with us! The BlackBerry® 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/devconf
___
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]

Michael Droettboom wrote:
> 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"?
>>   
>> 
> 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 don't know how different the output will be from different versions of 
> gs -- maybe we should just try it and see.  I have a pretty old version 
> of gs on my RHEL4 box (7.07).  If you want me to send you a png of a 
> particular pdf to directly compare with yours before you even start with 
> the test infrastructure, I'm happy to do that.
>   
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).

Anyhow, allowing the test infrastructure to support testing multiple
backends is why I removed file extensions from the test image name in
the first place, so anything along these lines should hopefully be quite
doable. We could add a keyword arg to the image comparison decorator
that specified which image formats to test. Alternatively, it could
perform comparisons based on the presence baseline images of known
extensions.

-Andrew

--
Come build with us! The BlackBerry® 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/devconf
___
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]

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

--
Come build with us! The BlackBerry® 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/devconf
___
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]

Jouni K. Seppänen wrote:
> John Hunter  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
diff --git a/lib/matplotlib/testing/decorators.py b/lib/matplotlib/testing/decorators.py
index 6363663..53b276b 100644
--- a/lib/matplotlib/testing/decorators.py
+++ b/lib/matplotlib/testing/decorators.py
@@ -48,42 +48,50 @@ def image_comparison(baseline_images=None):
 raise ValueError('baseline_images must be specified')
 def compare_images_decorator(func):
 def decorated_compare_images(*args,**kwargs):
-result = func(*args,**kwargs)
-extension = '.png' # TODO: test more backends
-for fname in baseline_images:
-# FIXME: place "actual", or current images, images in
-# a more reasonable location than the current
-# directory. Also, perhaps put them in sub-directory
-# according to the name of the test module like the
-# baseline images.
-actual = fname + extension
 
-# compute filename for baseline image
-module_name = func.__module__
-if module_name=='__main__':
-# FIXME: this won't work for nested packages in matplotlib.tests
-import warnings
-warnings.warn('test module run as script. guessing baseline image locations')
-script_name = sys.argv[0]
-basedir = os.path.abspath(os.path.dirname(script_name))
-subdir = os.path.splitext(os.path.split(script_name)[1])[0]
-else:
-mods = module_name.split('.')
-assert mods.pop(0)=='matplotlib'
-assert mods.pop(0)=='tests'
-subdir = os.path.join(*mods)
-basedir = os.path.dirname(matplotlib.tests.__file__)
-baseline_dir = os.path.join(basedir,'baseline_images',subdir)
-expected = os.path.join(baseline_dir,fname) + extension
+# compute baseline image directory
+module_name = func.__module__
+if module_name=='__main__':
+# FIXME: this won't work for nested packages in matplotlib.tests
+import warnings
+warnings.warn('test module run as script. guessing baseline image locations')
+script_name = sys.argv[0]
+basedir = os.path.abspath(os.path.dirname(script_name))
+subdir = os.path.splitext(os.path.split(script_name)[1])[0]
+else:
+mods = module_name.split('.')
+assert mods.pop(0)=='matplotlib'
+assert mods.pop(0)=='tests'
+subdir = os.path.join(*mods)
+basedir = os.path.dirname(matplotlib.tests.__file__)
+baseline_dir = os.path.join(basedir,'baseline_images',subdir)
 
-# compare the images
-tol=1e-3 # default tolerance
-err = compare_images( expected, actual, tol,
-  in_decorator=True )
-if err:
-raise ImageComparisonFailure(
-'images not close: %(actual)s vs. %(expected)s '
-'(RMS %(rms).3f)'%err)
-return result
+for extension in ['.png', '.pdf']:
+switch_backends_somehow(extension) # FIXME: implement this
+last_result = func(*args,**kwargs) # actually call the test function
+for fname in baseline_images:
+# FIXME: place "actual", or current images, images in
+# a more reasonable location than the current
+  

Re: [matplotlib-devel] Comparing pdf output in tests

[Andrew Straw]

John Hunter wrote:
> On Wed, Sep 23, 2009 at 12:42 PM, Andrew Straw  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

--
Come build with us! The BlackBerry® 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/devconf
___
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]

John Hunter wrote:
> On Wed, Sep 23, 2009 at 12:56 PM, Andrew Straw  wrote:
>   
>> John Hunter wrote:
>> 
>>> On Wed, Sep 23, 2009 at 12:42 PM, Andrew Straw  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

--
Come build with us! The BlackBerry® 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/devconf
___
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]

Jouni K. Seppänen wrote:
> Jouni K. Seppänen  writes:
>
>   
>> I committed something based on this, and a new rc parameter
>> savefig.extension that sets the filename extension when you call savefig
>> with a bare filename. The pdf tests seem to be working, at least for me,
>> but I am sure that the code can be improved.
>> 
>
> The buildbot was getting errors, since the build environments don't have
> gs. I changed the tests so that this isn't an error. It might be better
> to make it a known fail, but is it possible for the image comparison
> decorator to turn one test function into several cases? I.e., the png
> case could be pass/fail, and the pdf case a known fail if there is no
> Ghostscript.
>   
Hi Jouni,

I just installed gs on one of the buildbots -- so at least the .pdf
generation should get tested on one machine. (The one running the py24
and py25 tests.)

As far as the decorator turning one test in into multiple tests out --
it may be possible. Nose does this automatically for tests like:

def check_sum(func):
a = 10; b = 20
assert a+b == func(a,b)

def test_sum():
for func in [np.add, pylab.add]:
yield check_sum, func

This test function is a generator that nose will then generate two test
cases out of. So, perhaps the image_comparison decorator could be
changed to become a generator? I'm not 100% sure it will work, but I
don't see why it won't. If it does work, I think this is a good idea.

-Andrew

--
Come build with us! The BlackBerry® 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/devconf
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [PATCH] experimental numscons support in matplotlib

[Andrew Straw]

David Cournapeau wrote:
> Hi,
> 
> I don't know if that's of any interest for matplotlib developers,
> but I added scripts to build matplotlib with numscons:
> 
> http://github.com/cournape/matplotlib/tree/scons_build
> 
> Not every configuration is supported yet, but I can successfully build
> matplotlib on Linux with gtk or wx backends. It only adds 3 files + one
> configuration example, and does not touch any other file.
> 
> The advantage of numscons over distutils is automatic dependency
> handling (no need to rm -rf build to get accurate build), easy compiler
> flags customization, parallel build, etc... There are some instructions
> in setupscons.py.
> 
> It is still experimental (I have not implemented check for QT, as well
> as windows, macosx and qt backends), but it seems to work well. I will
> add mac os x and windows backends soon (I started this to debug issues
> on 64 bits version of matplotlib),

Dear David,

It certainly is of interest to me. When I get a little time (maybe this
weekend), I'd like to try it. Specifically, I'd like to setup a buildbot
that would automatically build and run the test suite with it. Along
those lines, is there any reason why it shouldn't work with Ubuntu Hardy
amd64 (8.04) and Python 2.5? Or should I try another distro? (I'll be
setting up a chroot.)

It looks pretty unintrusive to me -- I can't see why it would hurt to
include it direct into MPL.

-Andrew

--
Come build with us! The BlackBerry® 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/devconf
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [PATCH] experimental numscons support in matplotlib

[Andrew Straw]

David Cournapeau wrote:
> I have a question about git as well, actually - I could not update the
> svn metadata, unfortunately, by using git-svn rebase -l (I used your
> branch on github and the instructions on matplotlib website). It gives
> me an awful lot of merging errors, which seems to indicate that git-svn
> is confused about the current state,
I have trouble with that too. :(

Do you have notes on how you setup the numpy git repo? I was never able
to figure out the way to make a good git clone that could be shared with
others.

-Andrew

--
Come build with us! The BlackBerry® 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/devconf
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [PATCH] experimental numscons support in matplotlib

[Andrew Straw]

Eric Firing wrote:
> The only concern that occurs to me with respect to including both
> setup.py and setupscons.py is that when a module is added or removed,
> it means figuring out what to do with two systems instead of one.  So
> the question is, will it make it easier or significantly harder for
> most of us to maintain mpl?
Well, given that the plan is to add a buildbot that runs the scons
builder, I think we should find out pretty quickly if forgetting to add
the hypothetical new module causes breakage. (Especially since you'll be
writing tests for it, right? ;)

-Andrew

--
Come build with us! The BlackBerry® 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/devconf
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [PATCH] experimental numscons support in matplotlib

[Andrew Straw]

Andrew Straw wrote:
> David Cournapeau wrote:
>   
>> I have a question about git as well, actually - I could not update the
>> svn metadata, unfortunately, by using git-svn rebase -l (I used your
>> branch on github and the instructions on matplotlib website). It gives
>> me an awful lot of merging errors, which seems to indicate that git-svn
>> is confused about the current state,
>> 
> I have trouble with that too. :(
>
> Do you have notes on how you setup the numpy git repo? I was never able
> to figure out the way to make a good git clone that could be shared with
> others.
OK, I think I fixed the git mirror. The good news is that things should
work just like your scipy svn git mirror. The bad news is that I moved
the master branch to "old-master-broken-svn-import", so you'll probably
have to rebase all your changes. The new git branch to base off is
"trunk", which is a mirror of the svn trunk. MPL's svn layout doesn't
follow the standard svn repository, so I haven't mirrored other branches
(yet). I'll update the MPL dev docs soon.

Please let me know if you're having any more trouble.

-Andrew

--
Come build with us! The BlackBerry® 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/devconf
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [PATCH] experimental numscons support in matplotlib

[Andrew Straw]

David Cournapeau wrote:
> Andrew Straw wrote:
>   
>> Andrew Straw wrote:
>>   
>> 
>>> David Cournapeau wrote:
>>>   
>>> 
>>>   
>>>> I have a question about git as well, actually - I could not update the
>>>> svn metadata, unfortunately, by using git-svn rebase -l (I used your
>>>> branch on github and the instructions on matplotlib website). It gives
>>>> me an awful lot of merging errors, which seems to indicate that git-svn
>>>> is confused about the current state,
>>>> 
>>>>   
>>>> 
>>> I have trouble with that too. :(
>>>
>>> Do you have notes on how you setup the numpy git repo? I was never able
>>> to figure out the way to make a good git clone that could be shared with
>>> others.
>>> 
>>>   
>> OK, I think I fixed the git mirror. The good news is that things should
>> work just like your scipy svn git mirror. The bad news is that I moved
>> the master branch to "old-master-broken-svn-import", so you'll probably
>> have to rebase all your changes. The new git branch to base off is
>> "trunk", which is a mirror of the svn trunk. MPL's svn layout doesn't
>> follow the standard svn repository, so I haven't mirrored other branches
>> (yet). I'll update the MPL dev docs soon.
>>   
>> 
>
> FWIW, I have tried importing the whole svn repo, and the repo got might
> big (~700 Mb) - I guess because of all the things in trunk but not in
> trunk/matplotlib.
>   
OK, I'm rebuilding a repo with the branches and tags myself as we speak.
It's been going over 2 hours on a local rsync on a screaming fast
computer. If this does import reasonably, would it be a real pain for
you to rebase again? (I'm still not sure it will be a reasonable idea --
I'll have to look at the size of the git repo, I think.)
>   
>> Great
>> Please let me know if you're having any more trouble.
>>   
>> 
>
> I have deleted my old repo and redid a fork on github - I have not tried
> rebasing on top of svn changes, but I updated the scons_build branch anyway.
>   
OK. Actually, the trigger that started all my git work is that something
broke with the old import anyway. Git thought one of the more recent svn
commits was parented to a commit months ago, so everything was broken
anyway. The new import is much better -- for the first time I managed to
be able to share the svn meta data across git clones.

-Andrew

--
Come build with us! The BlackBerry® 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/devconf
___
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]

Jouni K. Seppänen wrote:
> Andrew Straw  writes:
>
>   
>> This test function is a generator that nose will then generate two test
>> cases out of. So, perhaps the image_comparison decorator could be
>> changed to become a generator? I'm not 100% sure it will work, but I
>> don't see why it won't. If it does work, I think this is a good idea.
>> 
>
> It seems to have worked. The build slave with gs shows 65 tests with 2
> known failures, and the one without gs shows 30 known failures:
>
> http://mpl-buildbot.code.astraw.com/builders/Ubuntu%208.04%2C%20Python%202.5%2C%20amd64/builds/167/steps/test/logs/stdio
> http://mpl-buildbot.code.astraw.com/builders/Ubuntu%208.04%2C%20Python%202.5%2C%20amd64%2C%20no%20dvipng%2C%20no%20latex/builds/91/steps/test/logs/stdio
>
>   
Great -- I think this is nice from a test-writer perspective, and I
think it tests just what we want to test -- the appearance of the pdfs.
I think this idea could be easily extended to the ps format and, if
inkscape was installed, we could use the --export-png option to test svg.

Thanks,
Andrew

--
Come build with us! The BlackBerry® 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/devconf
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [PATCH] experimental numscons support in matplotlib

[Andrew Straw]

David Cournapeau wrote:
> Hi,
>
> I don't know if that's of any interest for matplotlib developers,
> but I added scripts to build matplotlib with numscons:
>
> http://github.com/cournape/matplotlib/tree/scons_build
>   
Hi David,

I'm trying to download your git repository, but I'm having trouble
cloning it.

Can you do this? "git clone git://github.com/cournape/matplotlib.git"

For me, I get an error:

$ git clone git://github.com/cournape/matplotlib.git
Initialized empty Git repository in /home/astraw/tmp/mpl/matplotlib/.git/
fatal: The remote end hung up unexpectedly

This has been happening for 2 days now.

If it's not working for you, can you file a support ticket with github?
(Or just delete your old repo and start a new one on github, preferably
forking from the astraw/matplotlib.git repo.)

-Andrew

--
Come build with us! The BlackBerry® 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/devconf
___
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

[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


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

[Andrew Straw]

Jouni K. Seppänen wrote:
> Jouni K. Seppänen  writes:
>
>   
>> Oh, right. My fault: when I implemented the pdf comparison, I made it
>> run the test for only those formats for which a baseline image exists,
>> 
>
> I committed a change to make it run both png and pdf tests all the time.
>   

Thanks for the fix, Jouni. (My svn commit was rejected because you did
exactly the same thing as me.)

> When we add new formats (comparing postscript files could easily be done
> using the same ghostscript command as used for pdf files, and some svg
> renderer could also be added)

"inkscape input.svg --export-png=output.png" works very well as an svg
renderer.

>  and new tests, we'll have to think about
> if we want to run all tests on all backends, since the amount of data in
> the repository will start growing pretty fast.
>   
As far as the test data -- I agree this is an issue. One point in favor
of the status quo is that it's really nice to have the test data
included with the source code so there are no configuration hassles. I'm
not sure how well the buildbot infrastructure would cope with anything
else. For example, to my knowledge, there is no Buildbot precedent to
automatically pull from two branches to execute a single test run. But
in general I think this does bear thinking about.

-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

[Andrew Straw]

Michael Droettboom wrote:

>> "inkscape input.svg --export-png=output.png" works very well as an svg
>> renderer.
>>   
> I'd also like to run SVG through xmllint against the SVG schema as 
> another sanity check.  I may get to this if I can find the time.

That'd be great. I just installed inkscape and xmllint on the non-bare
buildslave machine.

>> As far as the test data -- I agree this is an issue. One point in favor
>> of the status quo is that it's really nice to have the test data
>> included with the source code so there are no configuration hassles. I'm
>> not sure how well the buildbot infrastructure would cope with anything
>> else. For example, to my knowledge, there is no Buildbot precedent to
>> automatically pull from two branches to execute a single test run. But
>> in general I think this does bear thinking about.
>>   
> An easy improvement may be having an extra kwarg on the image_comparison 
> decorator to select a subset of backends.  For example, many of the ones 
> in test_simplification.py only apply to the Agg backend.

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'])

> While I'm sharing my wish list out loud, I think it would also be highly 
> cool to get the native Mac OS backend in the buildbot tests, as that's 
> one I can't test easily myself.

That would require the Mac OS X buildslave to start working again too,
as I assume the backend actually requires the OS. And that would require
building on Snow Leopard to work, as I understand it.

-Andrew
>From d6ae15c5495930963d2d124bf3fc70e8bc6f80a9 Mon Sep 17 00:00:00 2001
From: Andrew Straw 
Date: Fri, 9 Oct 2009 10:38:09 -0700
Subject: [PATCH] don't test simplification

---
 .../test_simplification/simplify_curve.pdf |  Bin 1235 -> 0 bytes
 lib/matplotlib/tests/test_simplification.py|2 +-
 2 files changed, 1 insertions(+), 1 deletions(-)
 delete mode 100644 lib/matplotlib/tests/baseline_images/test_simplification/simplify_curve.pdf

diff --git a/lib/matplotlib/tests/baseline_images/test_simplification/simplify_curve.pdf b/lib/matplotlib/tests/baseline_images/test_simplification/simplify_curve.pdf
deleted file mode 100644
index b179d7b5542ed8c05d203a14f9dd9f354a3175a4..
GIT binary patch
literal 0
HcmV?d1

literal 1235
zcmZuxOK1~O6z!&dW?mFA<>YU9L$V53YjFX_}|CeFN;C>BJp
zn<8$l3Q~2`j|&mBD2UKap+Yw<#EJ+-5D~?N7W}_ANt>8Bo0*)s_rCMF6IUV{-;2F|
z!8Q9DW*!R|l...@?7slt4wsj...@j_osl&PE~)lDO+
zQUYz!4xcE7#jr2v!#>$Bdql}Citcs+B`i}L&JYXQ3Mwt;O`6x!P}H)j...@yvtvpUeRlh7<*ul(qacf)n>1q^%{h>*y...@h)|#9wheea%{b?lmgef2=j...@o~w
zILRbN<4iUwQ9wNfCbzqCk5ukGkOCAd(E~}!CCcRi$w5`qjT{8ah^ZfpEX^Z-+>exnpu9...@a?n`ui!ak$sykNNT
z...@8q)b;xQgZTrET%-Wo&AQ$ouHi>5RnHU4`TyxLvL=*Q6e*_3O?5tqq<)?-zqp4s
SRW0f`7z&33mn+s67ybe;ab=wV

diff --git a/lib/matplotlib/tests/test_simplification.py b/lib/matplotlib/tests/test_simplification.py
index f7dcf3c..bb574fc 100644
--- a/lib/matplotlib/tests/test_simplification.py
+++ b/lib/matplotlib/tests/test_simplification.py
@@ -89,7 +89,7 @@ def test_sine_plus_noise():
 
 assert len(simplified) == 279
 
-...@image_comparison(baseline_images=['simplify_curve'])
+...@image_comparison(baseline_images=['simplify_curve'], extensions=['png'])
 def test_simplify_curve():
 pp1 = patches.PathPatch(
 Path([(0, 0), (1, 0), (1, 1), (nan, 1), (0, 0), (2, 0), (2, 2), (0, 0)],
-- 
1.6.1.2

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