[matplotlib-devel] idea for a matplotlib figure contest (in memoriam John Hunter)

[Andrew Straw]

Hi all,

Shocked by news of John Hunter's untimely severe health problems and now 
death, I have been thinking about what we could do as a community to 1) 
fuel matplotlib to further heights and 2) give everyone, but especially 
John's family, some appreciation for how wide, and ongoing, his impact 
is. To those ends, I envision an MPL figure contest.

I have a lot of ideas about the shape such a contest could take (it 
could be an annual event, have multiple categories, have corporate 
sponsored prizes, and so on). Ultimately, however, I simply don't have 
the time to organize the contest myself. I do see this as an ideal 
project for someone who wants to contribute to the MPL community without 
necessarily requiring in-depth technical skills. Consequently, I'm 
floating this idea here, and I hope someone in the community can run 
with it. You would certainly have figure submissions from my lab!

Best regards,
Andrew

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git migration

[Andrew Straw]

On 07-Feb-11 17:13, Darren Dale wrote:
> The git migration is still on hold, pending the return of CVS service
> at sourceforge. According to someone on the sourceforge IRC channel,
> CVS is estimated to return this week, but it might slip to next week.

Thanks for the update.

At some point, one could get tarballs of the entire version control 
history from SF. I wonder if it would (still) be possible to simply 
download a tarball of the CVS history. I tried looking around a bit, but 
couldn't find them. Several years ago, I remember they used to be more 
prominent, but then, as of a year or two ago, they moved to a much less 
visible location. They were still available, but a bit trickier to find. 
Anyhow, I think it's worth a few days more wait to try to get the 
(almost) pre-history of MPL into git.

-Andrew

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] svn ancient history broken

[Andrew Straw]

On 29-Jan-11 01:08, John Hunter wrote:
>
>> cvs -z3 -d:pserver:anonym...@cvs.sourceforge.net:/cvsroot/matplotlib co -P 
>> matplotlib
> cvs [checkout aborted]: connect to
> cvs.sourceforge.net(216.34.181.96):2401 failed: Connection refused
>
> Amazing how fragile digital data is!

SF may simply have turned off CVS for now: 
http://sourceforge.net/blog/sourceforge-net-attack/

--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git-svn matplotlib mirror

[Andrew Straw]

On 23-Jan-11 04:05, John Hunter wrote:
>
> Darren
> if you are ready to "flip the switch" and make an official github repo
> under this organization, go for it.  Once we get the trunk active,
> we'll worry about the rest, like migrating the release branch.  Of
> course, if Andrew as the original force to move to github, has any
> comments or concerns, we're certainly receptive to them.  But we have
> a recent release out, the buildbot is broken currently anyhow, and
> this looks like a perfect time to make the move.

+1.

And for what it's worth, I keep nagging the IT people at my new employer 
to set me up the virtual machines for the new buildslaves...

-Andrew


--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Release schedule for version 1.0.1?

[Andrew Straw]

On 10/23/2010 04:59, John Hunter wrote:
> I would be happy to do a release early next week.  Is anyone aware of
> any show stopper bugs that need to be fixed first?

I think we should really get the build bot to all green again before 
doing a release. Currently, the last that happened was October 4: 
http://mpl-buildbot.code.astraw.com/waterfall

--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Projections - custom_projection_example.py

[Andrew Straw]

  On 10/2/2010 8:33 PM, Mitchell Jon Stanton-Cook wrote:
> Hello,
>
> I have been trying to modify the custom projection example
> (http://matplotlib.sourceforge.net/examples/api/custom_projection_example.html)
> to plot a Sanson Flamsteed Projection (Sinusoidal projection).

Dear Mitchell,

Can you use the 'sinu' projection in basemap? E.g. 
basemap/examples/contour_demo.py figure 1.

-Andrew


--
Virtualization is moving to the mainstream and overtaking non-virtualized
environment for deploying applications. Does it make network security 
easier or more difficult to achieve? Read this whitepaper to separate the 
two and get a better understanding.
http://p.sf.net/sfu/hp-phase2-d2d
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Sample data: a proposal

[Andrew Straw]

On 09/12/2010 07:10 AM, Jouni K. Seppänen wrote:
> A while ago there was a discussion [1] about how using the
> get_sample_data function in building the documentation is a problem for
> Debian packagers. Let me see if I understand the goals of
> get_sample_data correctly:
>
> * we want to enable users to run examples they find in the gallery
>without downloading extra files;
>
> * we don't want to package all the sample data with matplotlib, either
>because it is too large, or because it changes more often than we
>release new versions.
>

* Also, we want to have the sample data not to be in the same version 
control repository as MPL proper so that when we download the MPL source 
code itself, we don't get the sample data. (This is one of the sticking 
points for a move to git.)

> Here's what I suggest:
>
> 1. Package the sample data in a separate zip file that users can
> download and expand in e.g. ~/.matplotlib/sample_data if they like.
> This file could be released more often than matplotlib, if needed.
> Debian can use this as one source file and package it as a separate
> deb file.
>
> 2. Make get_sample_data look first in the place where the zip file could
> have been expanded, and only if the required file is not found, try
> to obtain it from the web. Add an option to disable the network
> access. This is different from what we do now, because now
> get_sample_data always tries to check if there is a newer version
> available, which apparently doesn't work reliably on unconnected
> computers.
>
> 3. To make this work, agree that sample data files are immutable: if a
> new version is needed, it needs to have a new name (and thus the
> examples using it need to be updated). The files have not been
> changed a lot [2], so I don't think this is very much of a burden.
>
> What do you think?
>
>

#1 and #2 seem reasonable to me.

I don't like #3 -- for the same reasons as we want to separate the rest 
of the sample data (smaller download, smaller repository, and separation 
of code and non-essential data), I think the test comparison images 
should be with the sample data. Having to deal with renames in the tests 
would be annoying. Two alternative ideas to handle for the  versioning 
issue: A) Add a .py file in the main source repository with is a list of 
sample data filenames and checksums. If a sample data file doesn't 
exist, or its checksum is wrong, it can be downloaded. B) The source 
file could simply have the same data version number required and the 
sample data itself could be versioned.

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] OK to delete methods?

[Andrew Straw]

On 8/21/10 12:08 PM, Eric Firing wrote:
> Mike, John, or anyone else who works directly with Ticks:
>
> I think you are the only ones who have worked with the code I suggest 
> changing as in the attached diff.  It looks to me like the three *Tick 
> methods, set_view_interval(), get_minpos(), get_data_interval(), are 
> unused and unlikely ever to have been or to be used.  I particularly 
> object to the first of these because I don't think a Tick has any 
> business changing the view interval.  The other two look like clutter, 
> harmless except insofar as they make it harder to understand the code. 
> If some projection actually does end up needing the functionality in 
> any of these methods, it is still available via *Tick.axes.xaxis.* etc.
>
> Am I missing something?  If not, I will commit this to the trunk.  
> This is a case where I think immediate surgery is better than a 
> deprecation process.
Hi Eric,

In general I'm all for it - simplicity is good. Just make sure that it 
doesn't break the spine placement code (e.g. 
examples/pylab_demo/spine_placement_demo.py ) -- I remember those method 
names from the time when I was working on the spines. I don't remember 
any deep issues, but it's long enough ago now that I don't remember the 
details.

Thanks,
Andrew

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] macos x backend not functioning in trunk

[Andrew Straw]

Eric Firing wrote:
> On 08/17/2010 06:36 AM, Jeff Whitaker wrote:
>   
>> I'm guessing some of Eric's recent changes to alpha handling in paths
>> require modifications to the MacOS X backend?
>> 
>
> Correct.  I'll fix it.
>   

I see the Mac OS X buildbot is back online now, so perhaps we could add
some unit tests that run on that backend? (I don't know the mac backend
at all -- is it possible for it to save output, or even to run without
access to the graphics system?)

-Andrew

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] path unit_* methods: CLOSEPOLY?

[Andrew Straw]

Michael Droettboom wrote:
> On 08/14/2010 07:22 PM, Eric Firing wrote:
>   
>> Mike,
>>
>> Is there any reason why the Path.unit_* methods shouldn't include the 
>> codes, so that they can all have CLOSEPOLY?  Or shouldn't they at 
>> least have a kwarg to allow that as an option?  In working on patch 
>> drawing via bar(), I noticed that the rectangle outline is not closing 
>> properly, with the same rounded join as at the other 3 corners.  It 
>> isn't apparent unless you set a large linewidth.
>>
>> Or is there a better way to ensure that polygons close correctly?
>> 
>
> I don't think there's a better way.  The renderer can't assume CLOSEPOLY 
> at the end, obviously, because it may in fact by a line and not a filled 
> shape.
>
> I think this was left out just as shorthand (not having a codes array 
> makes things a little faster, too), but I think for correctness the 
> unit_* methods should have explicit codes arrays with CLOSEPOLYs.  I'll 
> go ahead and fix this.
>
> Mike
>
>   

Hi Mike, all the buildbots have errors with the
matplotlib.tests.test_simplification.test_hatch test on r8639 that
weren't there in r8635, and I think it's due to the code you committed.
Could you have a look?

(Don't worry about the doc build errors -- I think that's a bug with the
recent Sphinx 1.0.2 release, for which I have filed a report at
http://bitbucket.org/birkenfeld/sphinx/issue/501 for.)

(I was proud of all the green on the buildbot -- hopefully it won't turn
me into a chronic nag!)

-Andrew


--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] buildbots shouldn't be giving false alarms now

[Andrew Straw]

On 8/1/10 7:11 PM, Eric Firing wrote:

On 07/31/2010 08:51 PM, Andrew Straw wrote:
   

Hi MPL devs,

I think I've fixed a long-standing issue we've had with the buildbot
where sometimes a false alarm was issued when two tests stepped on each
others' toes. Specifically, I've fixed up the MPL buildbot environment
on the virtual machine that runs both the Python 2.4 and 2.5 tests so
that these tests are run from different MPLCONFIGDIRs.
 

Andrew et al,

https://sourceforge.net/tracker/?func=detail&aid=2856125&group_id=80706&atid=560720

Please see my comment in the above bug ticket.  I'm curious about three
things:

1) Would the solution I suggested in that comment also have worked?  If
so, would it be more robust against future changes in the buildbot, or
the creation of new buildbots?  Or was I misunderstanding where the
buildbot code comes from, and how it works?
   

Your comment on the tracker was:


Having two buildbot processes
accessing, and potentially writing to, the same cache file(s) partly
defeats the purpose of the buildbot: testing independent builds
independently, on a variety of systems.


The fact that we have two simultaneous build/test cycles happening on 
one test system is simply a result of the way I configured the buildbot. 
(I'm running a Python 2.4 and Python 2.5 interpreter simultaneously on 
the same machine.) I wouldn't call it a failure of the buildbot software 
at all.


The solution you proposed in the comment was close to what I 
implemented. The difference is I didn't use tempfile.mkdtemp but just 
fixed the value per buildbot slave.



2) Can the bug be closed now?

   

Yes, I closed it.


So, from now on, all emails from the buildbot should be taken seriously.
 

3) What about the failure that occurred after your 8609 commit?
If you look at the log, that was because there was trouble downloading 
pygments. (I should disable networking on the build slaves, but 
haven't...) The next build didn't have that issue.



   It
looks like the scons build is not being run, but it's last failure (in
November) is still triggering the email.  Correct?
   
No, the buildbot is currently configured only to send a single email on 
the transition from OK -> failure for a given slave. So there was one 
email sent about this, but shouldn't be any more.


So, again,  we can take all emails from the buildbot seriously.
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] buildbots shouldn't be giving false alarms now

[Andrew Straw]

Hi MPL devs,

I think I've fixed a long-standing issue we've had with the buildbot 
where sometimes a false alarm was issued when two tests stepped on each 
others' toes. Specifically, I've fixed up the MPL buildbot environment 
on the virtual machine that runs both the Python 2.4 and 2.5 tests so 
that these tests are run from different MPLCONFIGDIRs.

So, from now on, all emails from the buildbot should be taken seriously.


As a reminder, you can see the buildbot waterfall output at:
http://mpl-buildbot.code.astraw.com/waterfall

You can sign up for the buildbot mailing list at:
https://lists.sourceforge.net/lists/listinfo/matplotlib-buildbot

And the main MPL buildbot page is:
http://mpl-buildbot.code.astraw.com

-Andrew


--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] question about svnmerge

[Andrew Straw]

On 7/20/10 8:06 PM, Fernando Perez wrote:
> On Tue, Jul 20, 2010 at 7:43 PM, John Hunter  wrote:
>
>> The major issues I am aware of are:
>>
>> * what do to about all the various subdirs of the mpl trunk
>> (trunk/toolkits/basemap, trunk/sample_data, etc..).  An svn commit to
>> one tags all with a unique revision number.  In git, how do we
>> synchronize between them?  Putting them all in the same tree would be
>> monolithic and require huge checkouts.  Unlike svn, in git it is
>> difficult/impossible to check out just a subdir (eg trunk/matplotlb)
>> and also commit to it.  So we might end up having to informally
>> synchronize parts of the trunk.  Eg, basemap rXXX requires mpl rYYY in
>> the CHANGELOG or release notes.
>>  
> Probably using a common tag across repos would be the easiest.  Any
> time you want a known 'sync point', you tag all the relevant repos
> with the same tag.  It then becomes very simple to write a little
> script that will update checkout a bunch of repos sitting in the same
> parent directory (each as its own dir, of course) at a common tag.
> You can make up a convention for these special tags so that they are
> always named with a given pattern (you could even use r if you
> wanted).
>
We could also make a meta repository that uses git submodules (somewhat 
akin to svn externals). Each commit in a repo that links to submodules 
specifies a specific revision of the submodule repo, so this meta 
repository would be a fairly natural way of linking across several 
repositories at specific revisions. That being said, a convention to 
simply use the standard git tags would also work fine, and wouldn't 
require people to learn git submodules. So, it's really a question of 
sticking to a convention (that has a lesser learning curve) or using a 
new set of commands that would more or less do exactly what we want, but 
would have to be learned. I'm agnostic on the issue.


>> * organizational stuff: how do we handle the notion of the central
>> repo?  Now that github support "organizations" this should be
>> relatively easy.  Andrew and I registered a matplotlib user acct at
>> github and created a gmail acct mplgithub as a central administrator
>> (matplot...@gmail.com was taken, the bastards).  Email me offlist if
>> you are interested in obtaining the passwd for the github or gmail
>> admin accts -- but you should probably coordinate with Andrew who is
>> our point person as soon as he re-emerges.
>>  
> No need. Organizations let you designate more than one 'owner', so you
> can mark more than one person with full admin privileges without
> having to give out the password around.  I recently converted the
> extra ipython account to an organization, added Brian Granger as a
> second 'owner', and that's it.  You can then make as many teams and
> repos as you want within an organization.  The github org model is
> fairly simple but very effective (much nicer than how launchpad uses
> teams).
>
I went ahead and switched our github.com/matplotlib account into an 
organization when github announced organization support a few weeks ago. 
Just now I added the jdh2358 and fperez users into the matplotlib 
owner's team.

(And I'm trying to re-emerge, I promise...)


>> * porting the buildbot to work w/ github commits
>>  
I should be able to handle that fairly easily. I do it for my other 
projects. (Bigger on my buildbot priority list is stopping the annoying 
occasional config directory multi-process conflict.


>> * related: porting the trunkdocs build to work with github commits
>>  
As this is run by the buildbot, it should be taken care of with the above.


For me, the main remaining issue is how do we want to pull the svn repo 
into git? Right now, the unofficial git repo at 
github.com/astraw/matplotlib is too big for my likes because it has a 
lot of stuff besides the matplotlib source code and its history. Before 
moving to an official git repository, I think we should prune down the 
main repository to just the source code files, their history, and no 
binary files. But then that leaves the question of what to do with the 
binary files.

-Andrew

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [PATCH] doc/make.py clean don't fail if directories are missing

[Andrew Straw]

On 07/01/2010 10:24 AM, Sandro Tosi wrote:
> Hello,
> while preparing a test debian pacakge with mpl 1.0rc1, I noticed
> doc/make.py clean fails if the directories to remove are missing.
>
> The simple attached patch (svn diff against tr...@8480) resolves it;
>   

Thanks, committed as r8481.


--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] doc build failure

[Andrew Straw]

John Hunter wrote:
> On Sun, Jun 20, 2010 at 7:56 PM, Jae-Joon Lee  wrote:
>   
>> The issue was related with the change in Sphinx v1.0b2, which I think
>> I fixed in r8447.
>> At least, the html are built fine and uploaded fine.
>>
>> However, the link to trunk-docs still does not work.
>>
>> http://matplotlib.sourceforge.net/trunk-docs/
>>
>> Can someone check what's wrong?
>> 
>
> Andrew, any chance you can look at this before tomorrow AM?  We are
> putting out a 1.0 release candidate ahead of scipy, and Michael is
> giving a "what's new" talk tomorrow, and it would be nice if he could
> illustrate some stuff in the gallery of the trunk-docs

I believe I fixed the issue in svn r8477.

Now, to fix the false alarm warnings that the buildbot give out so we
catch this earlier.

Hi to all at the SciPy conference -- I'm sorry I'll miss it this year.

-Andrew

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] web gui

[Andrew Straw]

Hi Ondrej,

If I was in your shoes, the first thing I'd do is emit your data to plot
as a json object and then plot that data using javascript with one of
the libraries you've listed. Then, after gaining some familiarity with
Python->json->javascript I'd think about how such an MPL backend might
work. A usecase I could imagine is some Django app that uses MPL to plot
stuff into a javascript canvas element complete with zooming and so on.

I think there are a lot of open questions in this domain... For example,
presumably one doesn't want the server involved when the client browser
zooms. But then if you implement something that allows the client
browser to zoom without the server MPL process, you're no longer using
the normal MPL callback system. So, interactivity would probably be
different than in the traditional backends.

You could also start with the svg backend, as browsers do render svg.

-Andrew

Ondrej Certik wrote:
> Hi,
>
> could someone please point me to the latest status of the web gui?
>
> I am now in LLNL and I don't have a root access to my computer
> (running rhel5), and there is no Tk, nor Tkinter Python modules. I
> have installed femhub, so I have the whole python stack, but I don't
> have any gui. Mpl can save figures to a file, so at least something.
> But I am missing the zoom feature.
>
> I found the following cool libraries:
>
> http://www.sencha.com/
> http://raphaeljs.com/
> http://g.raphaeljs.com/
>
> that work perfectly in my browser (FF3). So I wondered how hard it
> would be to use them as an mpl backend? All I need, I think, is just
> simple plotting, and zoom (+pan).
>
> I could adapt for example:
>
> lib/matplotlib/backends/backend_tkagg.py
>
> but it seems quite involved. Is there some simple thing, that would
> "just work" for me, that I could start adapting for the web gui? I
> would imagine that show() would launch a web server and tell the user
> to go to localhost:8080 or something and then the gui would be in the
> browser. The browser can even be opened automatically.
>
> Ondrej
>
> --
> ThinkGeek and WIRED's GeekDad team up for the Ultimate 
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
> lucky parental unit.  See the prize list and enter to win: 
> http://p.sf.net/sfu/thinkgeek-promo
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   


--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Upcoming Debian stable releaseand matplotlib new release(s)

[Andrew Straw]

On Sat, 29 May 2010 12:28:40 -1000, Eric Firing  wrote:

> 3) Is it really a good idea to delay the release until the we make the
> github transition?  Given how long it has been since a release, and the
> possibility that there will be some turbulence until we have had some
> experience with github, I think it would be better to release first and
> transition immediately afterwards.

I've had unanticipated time commitments come up that have limited the time I 
have available for work on MPL. I had been planning spending some time to 
facilitate a switch to git but now can't see where the time will come from (in 
the next several weeks at least). Therefore I think making a release before any 
VCS switch is a good idea.

-Andrew



--

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

Re: [matplotlib-devel] Proposal for Broken Axes

[Andrew Straw]

John Hunter wrote:
> On Mon, Mar 15, 2010 at 3:16 PM, klukas  wrote:
>   
>> It's my understanding that there is no built-in method for generating a
>> "broken axis" (where you skip over some range of values, indicating this
>> with some graphical mark).  I wanted to do this, so I've put together a
>> function which seems to be fairly robust, and I thought I might propose it
>> as a starting point if there's interest in having a built-in facility for
>> broken axes.
>>
>> 
> This is a nice start of an oft requested feature, and we are
> definitely interested.  It is enabled by the spine contribution of
> Andrew, so you can turn off the upper and lower spines between the
> break, so it is nice to see some unintended benefits of his
> refactoring.
>
>
> An alternative implementation could craft a custom transform using
> some custom artists for spines, but this might be a good bit harder.
> Do you have an opinion Andrew on this approach?
>   

John, I'm attaching a helper function I wrote to do just this.
Unfortunately, I don't have time to attempt to merge this into MPL right
now...

On Mon, Mar 15, 2010 at 3:16 PM, klukas  wrote:

> The only real problems here is that you need to
> explicitly plot things on both the upper and lower axes, and then I haven't
> figured out how to push out the y-axis label of the main axes object so it
> doesn't overlap with the tick labels of the upper and lower axes.  So, I
> instead moved the y-labels of the upper and lower axes so that they appear
> at the center of the axis, but this is problematic.  Any thoughts on how to
> do that part better?

klukas, I'm afraid I don't understand your issue... Can you explain using it 
differently?

-Andrew

def add_spine_break(ax,spine_name,
data_loc, data_shift_amount=5, data_width=10,
axes_shift_amount = 0.05,
axis='y'):
"""draw a white parallelogram patch over the axis line at data_loc"""
import matplotlib.path as mpath
import matplotlib.patches as mpatches

t = ax.spines[spine_name].get_transform()
axes_coords = [-axes_shift_amount, axes_shift_amount,
   axes_shift_amount,
   -axes_shift_amount]
data_coords = [ data_loc-data_shift_amount, data_loc+data_shift_amount,
data_loc+data_shift_amount+data_width,
data_loc-data_shift_amount+data_width ]

if axis=='y':
xs = axes_coords
ys = data_coords
elif axis=='x':
xs = data_coords
ys = axes_coords
else:
raise ValueError('unknown axis: %s'%axis)

result = {}
if 1: # white patch
verts = []
for xi,yi in zip(xs,ys):
verts.append( (xi,yi) )
verts.append( (0,0) )
codes = [mpath.Path.MOVETO] + \
[mpath.Path.LINETO]*(len(verts)-2) + \
[mpath.Path.CLOSEPOLY]
path = mpath.Path( verts, codes )
patch = mpatches.PathPatch(path,edgecolor='none',facecolor='w')
ax.add_artist(patch)

patch.set_clip_on(False)
patch.set_transform(t)
patch.set_zorder(100)
result['white_patch']=patch

if 1: # black lines
verts = []
for xi,yi in zip(xs,ys):
verts.append( (xi,yi) )
codes = [mpath.Path.MOVETO] + \
[mpath.Path.LINETO] + \
[mpath.Path.MOVETO] + \
[mpath.Path.LINETO]
path = mpath.Path( verts, codes )
patch = mpatches.PathPatch(path,edgecolor='k',facecolor='none')
ax.add_artist(patch)

patch.set_clip_on(False)
patch.set_transform(t)
patch.set_zorder(101)
result['black_lines']=patch
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git migration

[Andrew Straw]

Eric Firing wrote:
> All,
>
> I think the git migration deserves its own thread on the devel list, so 
> here is a start.
>   
To the uninitiated - a decision is being made that MPL is moving to git
and github. We hope that this move will foster greater contributions
from the community and a blurring of the line between MPL committers and
users.

The decision process happened off-list to keep the flames and
bike-shedding minimal. Several of the core developers were consulted and
we all agreed that a move to a DVCS was desirable and inevitable. We did
not unanimously agree that git was best, but it was preferred by most
developers over mercurial/bitbucket, the other serious contender, and
neither camp voiced strong objections to the other system.



> The full svn repo includes much more than just matplotlib: also course, 
> htdocs, py4science, sample_data, sampledoc_tut, scipy06, toolkits, and 
> users_guide.  Before moving matplotlib, I think we should have a clear 
> plan as to how these other parts are going to be handled.  Will some or 
> all remain as the active parts of the svn repo, with matplotlib somehow 
> marked as invalid?  Will some or all get their own github repos? My 
> primary interest here is toolkits/basemap, but I am sure other good 
> stuff is in there.
>   
This is a good point. My preferred option is that we jettison all the
stuff that is not going to be shipped with MPL 1.0 from the git repo.
(More correctly - we build a git repo without that stuff ever going in.)
We can keep the old svn tree around and migrate the other projects to
git as desired. I think this is what's present in
http://github.com/astraw/matplotlib . Or am I missing something?

Another issue is whether to use github's Issue's system over
SourceForge's tracker. Personally, I'm in favor of moving the issue
tracking to github, but I think we should take stock of how we use the
tracker as see if github's features will support that.

> Before the transition, it would be good to have a pointers to the 
> simplest possible docs illustrating typical workflows after the 
> transition; maybe one for present developers with svn access, and 
> another for occasional contributors.
>   
I agree. I think the best learning material is from github. See
http://help.github.com/ and http://learn.github.com/ , for example. To
get to the "a ha" feeling, I highly recommend "Git from the bottom up"
by John Wiegley, available from
http://ftp.newartisans.com/pub/git.from.bottom.up.pdf . This latter is
what it took for me to come to a real understanding of git. Git was
designed from the data structures and plumbing up, and that the rest
("porcelain" in git parlance) came later and was less the focus of
initial development. Hence, the history is that git had a rougher UI
from the start and other DVCSs having nicer UIs but less stable and fast
repository formats. (Understanding the git model of the universe was key
to me becoming really fluent in git, but according to my office mate,
it's absolutely not necessary to use git for daily tasks. )


> Does it makes sense to retain the entire history in the new github repo, 
> or would it be just as well to start from a later point so as to reduce 
> the size?  The entire history could still be available in a separate 
> read-only repo, or fossilized in svn on sourceforge, or in my hg mirror. 
>   (Andrew's repo, at just under 200MB, is not prohibitively large by any 
> means, but it is a bit hefty.)
>   
I can see advantages either way, but I'm in favor keeping it. Tons of
MPL is undercommented, and seeing the history is extremely useful when
spelunking.

-Andrew

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
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]

John Hunter wrote:
> Andrew, the failure is on the font cache again -- is this the race
> condition you've mentioned in the past?
>
> matplotlib.tests.test_mathtext.test_mathtext_stixsans ... ok
> Failure: IOError ([Errno 2] No such file or directory:
> '/home/mpl-chslave/.matplotlib/fontList.cache') ... ERROR
>
> "/home/mpl-chslave/slave-py24/build_test_py24/build/PYmpl/lib/python2.4/site-packages/matplotlib/font_manager.py",
> line 942, in pickle_dump
> fh = open(filename, 'w')
> IOError: [Errno 2] No such file or directory:
> '/home/mpl-chslave/.matplotlib/fontList.cache'

John, yes, this is the multiprocess race condition. I don't think the
issue is buildbot specific, but I can see that the use case may be rare
in which one process deletes the MPL directory after another had already
determined it is present. Nevertheless, I think it's something that
could happen in other circumstances, and I'm not sure the fontlist cache
file itself is multiprocess safe (I'm not saying it isn't -- I haven't
looked).

It does appear that a locking based solution is possible in a
cross-platform way, as sqlite says they do it in "Can multiple
applications or multiple instances of the same application access a
single database file at the same time?" at http://www.sqlite.org/faq.html .

I could put the builds in different user accounts so that the buildbot
wouldn't unintentionally continue to be hit with this bug. We could also
make a test case that starts multiple processes simultaneously using
subprocess to exercise the bug and mark it as known failing -- that way
we at least don't forget that it's an issue.

All that being said -- I don't mind the occasional buildbot failure
message -- it tells me that the buildbot is running and testing stuff.
One can always quickly re-fire the failed test manually from the
buildbot webpage to determine if this was the problem.

-Andrew

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] problem with logic determining version numbers?

[Andrew Straw]

Nadia Dencheva wrote:
> Hi MPL developers,
>
> I use an older matplotlib version but this code is the same in SVN, so I 
> thought
> I'll mention it.
>
> ImportError: numpy 1.1 or later is required; you have 2.0.0.dev8107
Thanks Nadia. Fixed in svn r8128.

-Andrew


--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Display Interactive plots on a web page?

[Andrew Straw]

Brian32 wrote:
> Hello,
>
> I am currently displaying plots on a web page using matplotlib by creating
> .png files.  I would like have the ability for people to have access to the
> interactive plot feature (Zoom,Save) when they look at the plots on the web
> page.  I do not care if the plot is a pop up or if is directly on the web
> page.  At this point I just want the interactive feature available.  I am
> assuming that the end user that clicks on a web link will already have
> python/matplotlib installed.  Does anyone know if this is even possible?  If
> it is I would love to see an example of this.  
>
> Thanks in advance,
> Brian 
>   
I think you might be interesting in something like a javascript charting
library. This webpage lists some interesting options:
http://www.alsonkemp.com/tools/highcharts-javascript-charting-library/

--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Boxplots with Bootstrapped Intervals

[Andrew Straw]

phob...@geosyntec.com wrote:
>> phob...@geosyntec.com wrote:
>> 
>>> Hey folks,
>>>
>>> I recently modified the Axes method boxplot so that the confidence
>>>   
>> intervals around the mean are computed not with a static formula, but by
>> bootstrapping the median as many times as the user specifies. Also, I
>> commented out the lines that prevent the boxplots from folding around the
>> hinges (but that's obviously minor and in the current SVN if I'm not
>> mistaken).
>> 
>>> Is this something that would be worth including in matplotlib? I've
>>>   
>> never contributed to a project like this before and my code is probably
>> pretty sloppy by MPL standards. I'm not really sure what's appropriate to
>> contribute and what's not.
>> 
>
>
>   
>> -Original Message-
>> From: Andrew Straw [mailto:straw...@astraw.com]
>> Sent: Wednesday, February 10, 2010 2:20 PM
>> To: Paul Hobson
>> Cc: matplotlib-devel@lists.sourceforge.net
>> Subject: Re: [matplotlib-devel] Boxplots with Bootstrapped Intervals
>> ...
>> I think the best thing to do is to post the patch so that it can be
>> reviewed. Sending the output of "svn diff" as an attachment to this
>> email list would be easy from our end. (A github based submission --
>> fork the repo and push your commits -- would also work well for me, but
>> I'm not sure about the other MPL devs.)
>> 
>
> Andrew,
>
> Thanks for the reply. At the risk of embarrassment, I'm going to admit that 
> I'm not at all familiar with SVN other than I know that it's version control 
> software. Nonetheless I gave it a shot.
>
> I guess I should add that I didn't account for the fact that the user might 
> want to have the CIs output with the other boxplot properties. Shouldn't be 
> too hard to add in though. Also, I'm using the percentile method -- meaning 
> that after I get my "normal" distribution of medians, I simply use mlab's 
> percentile function to get the 2.5th and 97.5th percentile of that 
> distribution. The other method (bias-corrected and accelerated) was too 
> complex for me to code up quickly without using Rpy2, and that just seemed 
> silly.
>   
Hi Paul,

I committed a modified version of your code in r8127. This new code is
backwards compatible in the sense that it doesn't change anything for
existing uses of boxplot, but allows use of the bootstrapped approach by
specifying "notch=1" and "bootstrap=N" where N is the number of
resampling steps.

Thanks,
Andrew

--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Boxplots with Bootstrapped Intervals

[Andrew Straw]

phob...@geosyntec.com wrote:
> Hey folks,
>
> I recently modified the Axes method boxplot so that the confidence intervals 
> around the mean are computed not with a static formula, but by bootstrapping 
> the median as many times as the user specifies. Also, I commented out the 
> lines that prevent the boxplots from folding around the hinges (but that's 
> obviously minor and in the current SVN if I'm not mistaken). 
>
> Is this something that would be worth including in matplotlib? I've never 
> contributed to a project like this before and my code is probably pretty 
> sloppy by MPL standards. I'm not really sure what's appropriate to contribute 
> and what's not.
>   

Hi Paul,

This sounds interesting.

I think the best thing to do is to post the patch so that it can be
reviewed. Sending the output of "svn diff" as an attachment to this
email list would be easy from our end. (A github based submission --
fork the repo and push your commits -- would also work well for me, but
I'm not sure about the other MPL devs.)

-Andrew

--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] A small improvement to plot directive

[Andrew Straw]

Fernando Perez wrote:
> Hi all,
>
> would anyone mind if I commit the attached patch?
>
> It's 100% backwards compatible and allows for turning plot directive
> errors into fatal exceptions easily, so one can make sure that docs
> either build correctly or not at all.  This is useful for having
> examples be a kind of test suite, in addition to any unit tests a
> codebase may have.
>
> Thanks,
>
> f
>   

I'm +1 on this. We can have then have the buildbot doc builder enable
this when building the docs. (Which are output at
http://matplotlib.sourceforge.net/trunk-docs/ and
http://matplotlib.sourceforge.net/trunk-docs/Matplotlib.pdf , for
reference .)

-Andrew

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] missing projections

[Andrew Straw]

Jeff Whitaker wrote:
> Dr. Phillip M. Feldman wrote:
>   
>> Basemap offers many projections, but is missing two of the most useful ones:
>>
>> - For satellite applications, it would be helpful to have a "camera"
>> projection, i.e., a projection that shows the Earth as viewed from a
>> specified point in space.  This would be a generalization of the current
>> geostationary projection.
>>   
>> 
>
> Philip:  Don't think the proj4 lib supports this.
>   
I think it's already in there -- see nsper, for near sided perspective.

-Andrew

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Tracker patch #2924245

[Andrew Straw]

Neil Crighton wrote:
> Hi,
>
> I posted a patch that makes some small changes to minor tick autoscaling:
>
> http://sourceforge.net/tracker/?
> func=detail&aid=2924245&group_id=80706&atid=560722
>
> If someone could check it's ok and apply it, that would be great.
>   
I can't see the harm, so I applied this in r8082. Also, the patch did
two things. The second thing, "don't create minor ticks on top of
existing major ticks", I pulled out into a second patch and applied in
r8083.

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Pgfplots (TikZ) backend: implementation strategy

[Andrew Straw]

Nico Schlömer wrote:
> Hey, and is there any sort of matplotlib market place where I could
> put the file for general bashing/downloading once it can do more than
> a sin-plot?
>   
Well, github is my suggestion. If it's a patchset of the MPL source, 
then fork the MPL repository at http://github.com/astraw/matplotlib . If 
it's a standalone thing, just create a new project. Github makes this 
kind of sharing easy at all levels from casual one-off events to close 
collaboration.

-Andrew

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] building of latex docs failing at barb_demo.pdf

[Andrew Straw]

Michael Droettboom wrote:
> Cleaning the docs first seems to have fixed it.
>
> Is there a way to download the build products (i.e. the PDF file 
> produced)?
That, and testing for doc build failures, is the point, although I 
managed to screw up the uploading until now. However, I believe I have 
fixed this and we should now have auto-built docs from svn trunk at:

http://matplotlib.sourceforge.net/trunk-docs
http://matplotlib.sourceforge.net/trunk-docs/Matplotlib.pdf

Perhaps we should link these from somewhere. And the URLs can certainly 
be changed without much difficulty.

Thanks for finding the clean step issue -- I thought the buildbot 
software automatically cleaned the working directory on every build, but 
obviously I thought wrong.

-Andrew

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] building of latex docs failing at barb_demo.pdf

[Andrew Straw]

Hi,

With the recent regression fixed in Pygments, the doc auto-builder is
closer to completing successfully. However, there's a new bug. The build
ends with:

LaTeX Warning: File `/home/mpl-chslave/slave-py25/build_docs/build/doc/build/pl
ot_directive/mpl_examples/pylab_examples/barb_demo.pdf' not found on input line
 28650.


!pdfTeX error: pdflatex (file /home/mpl-chslave/slave-py25/build_docs/build/doc
/build/plot_directive/mpl_examples/pylab_examples/barb_demo.pdf): cannot find i
mage file
 ==> Fatal error occurred, no output PDF file produced!


Anyone have a clue what is going on here?

Feel free to check in the attempted solution and the buildbot will
automatically try it. (See the "
Ubuntu
8.04, Python 2.5, amd64 (docs)" column at
http://mpl-buildbot.code.astraw.com/waterfall )

Waiting for this will take up to 20 minutes before the build is
triggered (10 minute polling on the svn repo, and a 10 minute timeout
before any build is started in case another commit comes in). So you can
also force a build by clicking the column title ("Ubuntu 8.04, Python
2.5, amd64 (docs)" and then clicking the "Force Build" button.

It will be great to get the buildbot automatically building the svn docs
successfully.

-Andrew

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] docs are now built after every commit & sphinx latex output error

[Andrew Straw]

Andrew Straw wrote:
> Andrew Straw wrote:
>   
>> In fact, does anyone know what could be wrong? The last lines of the
>> LaTeX output are below.
>>   
>> 
> OK, this cropped up on another buildbot for another project of mine --
> it looks with a Sphinx dependency, Pygments 1.2.1 (just released), there
> is some issue that wasn't there with Pygments 1.1.1. I'll try to isolate
> the issue and report it to the appropriate tracker, but at this point I
> don't think it's an MPL issue.
>   
For the record, I reported it here:
http://dev.pocoo.org/projects/pygments/ticket/463

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] docs are now built after every commit & sphinx latex output error

[Andrew Straw]

Andrew Straw wrote:
> In fact, does anyone know what could be wrong? The last lines of the
> LaTeX output are below.
>   
OK, this cropped up on another buildbot for another project of mine --
it looks with a Sphinx dependency, Pygments 1.2.1 (just released), there
is some issue that wasn't there with Pygments 1.1.1. I'll try to isolate
the issue and report it to the appropriate tracker, but at this point I
don't think it's an MPL issue.

-Andrew

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [SciPy-dev] [Numpy-discussion] Announcing toydist, improving distribution and packaging situation

[Andrew Straw]

David Cournapeau wrote:
> On Sat, Jan 2, 2010 at 4:58 PM, Gael Varoquaux
>  wrote:
>   
>> On Sat, Jan 02, 2010 at 11:32:00AM +0900, David Cournapeau wrote:
>> 
>>> [snip]
>>>   - supporting different variants of the same package in the
>>> dependency graph at install time
>>>   
>>> [snip]
>>>   
>>> The second issue is more challenging. It complicates the dependency
>>> handling quite a bit, and may cause difficult situations to happen at
>>> dependency resolution time. This becomes particularly messy if you mix
>>> packages you build yourself with packages grabbed from a repository. I
>>> wonder if there is a simpler solution which would give a similar
>>> feature set.
>>>   
>> AFAICT, in Debian, the same feature is given via virtual packages: you
>> would have:
>> 
>
> I don't think virtual-packages entirely fix the issue. AFAIK, virtual
> packages have two uses:
>  - handle dependencies where several packages may resolve one
> particular dependency in an equivalent way (one good example is
> LAPACK: both liblapack and libatlas provides the lapack feature)
>  - closer to this discussion, you can build several variants of the
> same package, and each variant would resolve the dependency on a
> virtual package handling the commonalities. For example, say we have
> two numpy packages, one built with lapack (python-numpy-full), the
> other without (python-numpy-core). What happens when a package foo
> depends on numpy-full, but numpy-core is installed ?
When you type "apt-get install my_new_package", the version resolution
system will tell you that apt-get will remove python-numpy-core and will
install python-numpy-full in the act of installing my_new_package.
>  AFAICS, this can
> only work as long as the set containing every variant can be ordered
> (in the conventional set ordering sense), and the dependency can be
> satisfied by the smallest one.
>   
Typically, the dependencies only depend on the smallest subset of what
they require (if they don't need lapack, they'd only depend on
python-numpy-core in your example), but yes, if there's an unsatisfiable
condition, then apt-get will raise an error and abort. In practice, this
system seems to work quite well, IMO.

Anyhow, here's the full Debian documentation:
http://www.debian.org/doc/debian-policy/ch-relationships.html

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] docs are now built after every commit & sphinx latex output error

[Andrew Straw]

Hi all,

I added a recipe for to build a copy of the documentation after every
svn commit. The results may be seen at
http://matplotlib.sourceforge.net/trunk-docs/ (we can change the
location easily if desired).

This is just the result of another buildbot recipe, so any troubles that
crop up when building the docs should trigger an email on the
matplotlib-buildbot mailing list. For now, this is disabled because
compiling the latex document is failing. (Our buildbot is configured to
send email only on the first failure.)

In fact, does anyone know what could be wrong? The last lines of the
LaTeX output are below.

Happy New Year!

-Andrew

Package Fancyhdr Warning: \headheight is too small (12.0pt):
 Make it at least 13.5pt.
 We now make it that large for the rest of the document.
 This may cause the page layout to be inconsistent, however.

[4]
Chapter 2.
(/usr/share/texmf-texlive/tex/latex/txfonts/ot1txr.fd)
(/usr/share/texmf-texlive/tex/latex/txfonts/utxsya.fd)
(/usr/share/texmf-texlive/tex/latex/txfonts/utxsyb.fd)
(/usr/share/texmf-texlive/tex/latex/txfonts/utxmia.fd)
(/usr/share/texmf-texlive/tex/latex/txfonts/utxsyc.fd)
! Undefined control sequence.
 johnh\PYGZat
[]flag:\textasciitilde []\textgreater [] ipython
-pylab
l.260 ...asciitild...@textgreater[] ipython -pylab

?
! Emergency stop.
 johnh\PYGZat
[]flag:\textasciitilde []\textgreater [] ipython
-pylab
l.260 ...asciitild...@textgreater[] ipython -pylab

!  ==> Fatal error occurred, no output PDF file produced!
Transcript written on Matplotlib.log.

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Announcing toydist, improving distribution and packaging situation

[Andrew Straw]

Stefan Schwarzburg wrote:
> Hi,
> I would like to add a comment from the user perspective:
>
> - the main reason why I'm not satisfied with pypi/distutils/etc. and
> why I will not be satisfied with toydist (with the features you
> listed), is that they break my installation (debian/ubuntu). The main
> advantage of these kinds of linux is their packaging system. So even
> if there is a way to query if a python package is installed, I will
> need three or more commands to check if it really is there (toydist,
> distutils, aptitude and other packages installed by hand).

I am interested in adapting stdeb ( http://github.com/astraw/stdeb ) to
handle toydist distributions. Nevertheless, the goals of toydist seem
mostly unrelated to your issue with the exception that toydist will
hopefully make generating .deb packages easier and more robust.

See http://github.com/astraw/stdeb/issues#issue/16 for a wishlist item
that I think would solve your issue. In that ticket, I give the steps
required to solve the issue -- I don't think it looks too hard, and
patches will be reviewed with a goal of producing something that gets
merged.

-Andrew

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] auto range limits for spines: please kick the tires

[Andrew Straw]

Gary Ruben wrote:
> This looks nice Andrew,
> I haven't tried it, but I wonder whether it's possible to add a 
> keyword arg to suppress the 0's at the origin which are cut through by 
> the axes in the zeroed case (and/or possibly shift the 0 on the 
> horizontal axis left). The same thing is happening in the (1,2) case 
> on the vertical axis.
Hi Gary,

John also suggested something like this. I don't think it's impossible, 
but it's outside the scope of the work I have done and beyond my 
immediate familiarity with the code base. I think it would involve 
looking at the tick label bounding boxes, finding overlaps, and then 
deciding which label was less important and removing it. I don't think 
it would be impossible, and maybe not even hard, but I haven't 
investigated at all. Thanks for keeping it on the queue.

-Andrew

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] boxplot notch

[Andrew Straw]

Andrew Straw wrote:
> Also, I think that formula is only for normally distributed data. Which, 
> especially if you're using boxplots, medians, and quartiles, may not be 
> a valid assumption.
>
> Maybe we should at least raise a warning when someone uses notch=1. The 
> current implementation seems dubious, at best, IMO.
>   

(I sent the previous version of this email a bit too early -- this is
slightly edited for clarity.)

I read the following reference:

McGill, R., Tukey, J.W., and Larsen, W.A. (1978) "Variations of
Boxplots", The American Statistician, 32:12-16.

McGill et al. have an entire section devoted to "Choice of Notch Size",
starting with:

"In notched box plots, one is, of course, faced with the question of how
best to determine the widths of the notches. Many methods, both
classical and non-parametric, might be considered. None will likely be
best in all cases."

They then describe a suggestion based on the Gaussian-based asymptotic
approximation (Kendall and Stuart, 1967). Here the standard deviation of
the median is given by

s = 1.25*R / (1.35 * sqrt(N))

where R is the interquartile range and N is the number of observations.

Using this value for s, the notch around each median should be M +/- Cs
where C is a constant. To summarize this section of their paper, values
of C  between 1.386 and 1.96 could be justified depending on the
standard deviations, and they choose C=1.7 empirically as preferable and
ultimately give the full equation for notches to be

M +/-  1.7* (1.25*R / (1.35 * sqrt(N)))

But they end the section with:

"Clearly, a variety of other choices, such as a single less conservative
value (<1.7) or one dependent upon the data (chosen to compromise over
the range of the ratios of the spreads involved), are possible and may
be preferable in certain cases."

The thing not done in this article is to display outliers -- they refer
the reader to "schematic plots" in Tukey's 1977 book titled Exploratory
Data Analysis (Addison-Wesley). In the version of boxplots described in
this paper, the whiskers go to the data extremes.


--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] boxplot notch

[Andrew Straw]

Andrew Straw wrote:
> Also, I think that formula is only for normally distributed data. Which, 
> especially if you're using boxplots, medians, and quartiles, may not be 
> a valid assumption.
>
> Maybe we should at least raise a warning when someone uses notch=1. The 
> current implementation seems dubious, at best, IMO.
>   

I read the following reference:

McGill, R., Tukey, J.W., and Larsen, W.A. (1978) "Variations of Boxplots", The 
American Statistician, 32:12-16.



McGill et al. have an entire section devoted to "Choice of Notch Size",
starting with:

"In notched box plots, one is, of course, faced with the question of how
best to determine the widths of the notches. Many methods, both
classical and non-parametric, might be considered. None will likely be
best in all cases."

They then describe a suggestion based on the Gaussian-based asymptotic
appoximation (Kendall and Stuart, 1967) given by

s = 1.25*R / (1.35 * sqrt(N))

And the notch around each median should be M +/- Cs where C is a
constant and R is the interquartile range. It seems any value between
1.386 and 1.96 could be justified depending on the standard deviations,
and they choose C=1.7 empirically as preferable and ultimately give the
full equation for notches to be

M +/-  1.7* (1.25*R / (1.35 * sqrt(N)))

But they end the section with:

"Clearly, a variety of other choices, such as a single less conservative
value (<1.7) or one dependent upon the data (chosen to compromise over
the range of the ratios of the spreads involved), are possible and may
be preferable in certain cases."

The thing not done in this article is to display outliers -- they refer
the reader to "schematic plots" in Tukey's 1977 book titled Exploratory
Data Analysis (Addison-Wesley). In the version of boxplots described in
this paper, the whiskers go to the data extremes.



--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
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]

John Hunter wrote:
> On Fri, Aug 7, 2009 at 11:54 AM, Andrew Straw wrote:
>
>   
>>> 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.
>> 
>
> One thing you want with range frames is to have the length of the
> spine equal the span of your dataset.  Can we currently or with not
> too much effort define the line segment of the spine to be in data
> coords?  
This is implemented in r8044.

> Then we could make the axes as wide as we want with the ylim
> to maintain the clipping region, but the spine would cover just the
> span of the data (or whatever the user specified) rather than always
> being ymin...ymax if it is defined as 0..1 in axes coords.
>   
Currently, if you want to limit the spine range, you'll have to call
spine.set_bounds(low,high) manually. I think one would almost always
want the spine endpoints at tick locations, so perhaps a better default
behavior than we now have is that in any case in which the spines are
not forming an old-style axes frame, they are automatically limited to
the outermost ticks. I haven't implemented that, but I don't think it
would be too hard to build on top of what I just committed.

-Andrew

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] boxplot notch

[Andrew Straw]

Pierre GM wrote:
> On Dec 18, 2009, at 10:34 PM, Andrew Straw wrote:
>   
>> Fernando Perez wrote:
>> 
>>> On Fri, Dec 18, 2009 at 2:28 PM, Andrew Straw  wrote:
>>>
>>>   
>>>> (This still leaves open the question of what the notches actually _are_...)
>>>>
>>>> 
>>> No idea.  I'd still leave the code instead written as
>>>
>>> notch_max = med + (iq/2) * (pi/np.sqrt(row))
>>>
>>>   
>> Further searching turned this up: 
>> http://seismo.berkeley.edu/~kirchner/eps_120/Toolkits/Toolkit_01.pdf
>>
>> It says that
>>
>> median +/- 1.57 * (iq / sqrt(n)) is the median, plus or minus its standard 
>> error.
>>
>>
>> I can't find any further support for this notion, though.
>> 
>
>
> Looks like the std error of the median is (1.253*std error of the 
> mean=1.253*std dev/sqrt(nb of obs)).
> The 1.57 looks like it's 1.253^2, but I wouldn't bet anything on it...
>
>   
Also, I think that formula is only for normally distributed data. Which, 
especially if you're using boxplots, medians, and quartiles, may not be 
a valid assumption.

Maybe we should at least raise a warning when someone uses notch=1. The 
current implementation seems dubious, at best, IMO.

-Andrew

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] boxplot notch

[Andrew Straw]

Fernando Perez wrote:
> On Fri, Dec 18, 2009 at 2:28 PM, Andrew Straw  wrote:
>   
>> (This still leaves open the question of what the notches actually _are_...)
>> 
>
> No idea.  I'd still leave the code instead written as
>
> notch_max = med + (iq/2) * (pi/np.sqrt(row))
>   
Further searching turned this up: 
http://seismo.berkeley.edu/~kirchner/eps_120/Toolkits/Toolkit_01.pdf

It says that

median +/- 1.57 * (iq / sqrt(n)) is the median, plus or minus its standard 
error.


I can't find any further support for this notion, though.

I've decided not to use notches on my own plots, so I'm leaving this 
issue for now...

-Andrew

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] should mlab.prctile(x,50) == np.median(x)?

[Andrew Straw]

Andrew Straw wrote:
> The following (uncommitted) test currently fails. The reason is that 
> mlab.prctile(x,50) doesn't handle even length sequences according to the 
> numpy and wikipedia convention for the definition of median. Do we agree 
> that it should pass?
>   
I'll take the silence as +0. Therefore, I committed the test in r8038 
and the bugfix in r8039.

-Andrew


--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] boxplot notch

[Andrew Straw]

Fernando Perez wrote:
> Note that the code below does:
>
> if notch_max > q3:
> notch_max = q3
> if notch_min < q1:
> notch_min = q1
>
> though matlab explicitly states in:
>
> http://www.mathworks.com/access/helpdesk/help/toolbox/stats/boxplot.html
>
> that
>
> """
> Interval endpoints are the extremes of the notches or the centers of
> the triangular markers. When the sample size is small, notches may
> extend beyond the end of the box.
> """
>
> So it seems to me that the more principled thing to do would be to
> leave those notch markers outside the box if they land there, because
> that's a warning of the robustness of the estimation. Clipping them to
> q1/q3 is effectively hiding a problem...
>
>   
I agree. I disabled the boxplot notch shortening in r8040.

(This still leaves open the question of what the notches actually _are_...)

-Andrew

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] imshow without resampling in the ps backend.

[Andrew Straw]

Jae-Joon Lee wrote:
> What I have in my mind is to extend the "extent" keyword of the imshow
> and make it optionally take a tuple of 6 numbers, which are (x1,
> x_lrc, x2, y1, y_lrc, y2).
> x1, x2, y1, y2 are same as the original "extent", and the (x_lrc,
> y_lrc) represent the coordinate of the lower-right corner of the
> image.
>   
It's not clear to me if this proposal lets one specify any arbitrary 
affine transformation. Does it?
> Any thought?
>   
In general -- very nice. Thanks.

In specific, I think the way you have already implemented things is 
sufficient. I think if a user can write a little helper function (as in 
your demo) to avoid a dumbed-down API being part of MPL, that would be 
best. Anyone specifying their own affine transform is probably going to 
want a pretty precise level of control, anyway. (Of course if your 
extent keyword proposal is already a general purpose API, then please 
ignore this comment.)

-Andrew


--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] imshow without resampling in the ps backend.

[Andrew Straw]

Jae-Joon Lee wrote:
> On Wed, Dec 16, 2009 at 12:59 PM, Jouni K. Seppänen  wrote:
>   
>> While the backend API is being changed, would it be similarly easy to
>> support arbitrary affine transformations? It would make the API more
>> symmetric, since many other draw_* methods take an affine
>> transformation, and I guess at least the PS and PDF backends could
>> easily support this.
>>
>> 
>
> Yes, supporting arbitrary affine transform would not be difficult. On
> the other hand, I'm not sure if that feature is practically useful,
> assuming that other rasterizing backend won't implement it. I'll think
> about it.
I second the notion that affine transformations on images would be 
useful. There are a lot of things one can do with this, such as make 
pseudo-perspective projections of texture-mapped rectangles. This is 
exactly one of the things that I routinely do in Inkscape.

I'm reasonably sure Cairo supports arbitrary affine transformations when 
drawing image data -- I don't know about Agg.

-Andrew

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] boxplot notch

[Andrew Straw]

Hi,

I've been reading about box plots and examining the source code for 
boxplot() lately. While there doesn't seem to be a convention about what 
the notch specifies, I can't find any justification (or text describing) 
what exactly the MPL notch is. The source code is:

   # get median and quartiles
   q1, med, q3 = mlab.prctile(d,[25,50,75])
   iq = q3 - q1

   notch_max = med + 1.57*iq/np.sqrt(row)
   notch_min = med - 1.57*iq/np.sqrt(row)

Is this code actually calculating a meaningful value? If so, what?

The original commit was r1098, which doesn't offer a useful comment 
either (only "aaplied several sf patches" ... looking through the SF bug 
tracker, I couldn't find anything relevant from before the commit date 
of 2005-03-28).



--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] should mlab.prctile(x,50) == np.median(x)?

[Andrew Straw]

The following (uncommitted) test currently fails. The reason is that 
mlab.prctile(x,50) doesn't handle even length sequences according to the 
numpy and wikipedia convention for the definition of median. Do we agree 
that it should pass?

Not only would I commit the test, but I also have a fix to make it pass, 
derived from scipy.stats.scoreatpercentile().

This would affect boxplot, if not more.

def test_prctile():
 # test odd lengths
 x=[1,2,3]
 assert mlab.prctile(x,50)==np.median(x)

 # test even lengths
 x=[1,2,3,4]
 assert mlab.prctile(x,50)==np.median(x)

 # derived from email sent by jason-sage to MPL-user on 20090914
 ob1=[1,1,2,2,1,2,4,3,2,2,2,3,4,5,6,7,8,9,7,6,4,5,5]
 p = [75]
 expected = [5.5]

 # test vectorized
 actual = mlab.prctile(ob1,p)
 assert np.allclose( expected, actual )

 # test scalar
 for pi, expectedi in zip(p,expected):
 actuali = mlab.prctile(ob1,pi)
 assert np.allclose( expectedi, actuali )

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Z-Order Sorting

[Andrew Straw]

Jae-Joon Lee wrote:
> The recent zorder-related  changes broke the some of the rasterization
> feature, and I just committed a fix.
Thanks Jae-Joon.

Is it easy to turn this into a test so that it never unintentionally 
crops up again?

Thanks,
Andrew

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] mysterious test_axes/fill_units failure; buildbot images back online

[Andrew Straw]

Andrew Straw wrote:
> I'm a little mystified as to the actual cause, but it 
> again looks like some freetype problem. Mike, do you think it could 
> somehow be related to your recent font work?
>
>   
OK, in the absence of a fix, I just checked in the images that were 
being generated. They didn't look too bad -- probably just a weird 
freetype font hinting difference between the original and re-generated 
images.

Anyhow, now all the tests are passing again, and therefore we shouldn't 
have any more severe bugs like that in r7985 creeping in unnoticed. I 
take this as evidence that it's good to fix (or disable) minor failing 
tests right away so they don't obscure more severe failures.

--
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] [PATCH] experimental numscons support in matplotlib

[Andrew Straw]

Tony S Yu wrote:
>
> On Nov 30, 2009, at 4:34 AM, Andrew Straw wrote:
>> However, with svn r7985, the trunk fails to find the tests. This is so
>> weird. There's nothing in that commit that I can see that should cause
>> the failure, but it seems repeatable. r7984 doesn't have it and r7985
>> does. And it appears to be more or less the issue that the scons branch
>> had. Sigh.
>
> Could this failure be related to the bug filed by Christoph Gohlke 
> (see tracker 
> <http://sourceforge.net/tracker/?func=detail&aid=2903596&group_id=80706&atid=560720>)?
>  
> The change corresponds to r7985 and affects setupext.py. I'm not sure 
> if the numscons build uses setupext.py, but it may be worth checking out.
Thanks Tony (and Christoph) -- this fixed it.

I wonder why I wasn't getting a more severe error on linux? This might 
offer a clue as to the testing weirdness we've been experiencing lately.

Anyhow, I got the tests passing on the buildbots again so that we should 
immediately be notified upon new failures. I think we need to work hard 
to keep the buildbots green so we can catch things like this.

-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] [PATCH] experimental numscons support in matplotlib

[Andrew Straw]

David Cournapeau wrote:
> Andrew Straw wrote:
>   
>>   I looked a little further, and it depends on the directory that the
>> tests are run from -- if I manually log into the build slave, I can
>> get the tests to run (in fact, one segfaults) if I try from a
>> different working directory. Anyhow, now that I have a handle on it, I
>> think I can probably get it working... Give me a couple days.
>> 
>
> great.
>   
Well, now the scons branch tests run properly (until they hit a segfault 
on matplotlib.tests.test_axes.test_basic_annotate)

However, with svn r7985, the trunk fails to find the tests. This is so 
weird. There's nothing in that commit that I can see that should cause 
the failure, but it seems repeatable. r7984 doesn't have it and r7985 
does. And it appears to be more or less the issue that the scons branch 
had. Sigh.

Don't forget to pass on your sourceforge username to John to get svn 
commit access. I think the scons build option should get merged into the 
trunk.

-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] [PATCH] experimental numscons support in matplotlib

[Andrew Straw]

David Cournapeau wrote:
> Andrew Straw wrote:
>   
>> Michael Droettboom wrote:
>> 
>>> I know it's been a while since you announced this, but I'm just
>>> looking into this now.  
>>>   
>> Also, I got some ways in making the buildbot build with numscons, but
>> I stopped at a bug where it looked like the matplotlib.tests.* modules
>> were not getting installed:
>>
>> http://mpl-buildbot.code.astraw.com/builders/Ubuntu%208.04%2C%20Python%202.5%2C%20amd64%2C%20scons/builds/13/steps/test/logs/stdio
>>
>>
>> 
>
> I will look at it. I would like to get some kind of automated testing
> for matplotlib on windows 64 (which is built using the numscons build),
> so I have the incentive :)
>   
I looked a little further, and it depends on the directory that the 
tests are run from -- if I manually log into the build slave, I can get 
the tests to run (in fact, one segfaults) if I try from a different 
working directory. Anyhow, now that I have a handle on it, I think I can 
probably get it working... Give me a couple days.

win64 builds wold be great.
>   
>> I haven't had a chance to debug this further, but I'm open to ideas.
>> Also, this branch is building from a git repository (a mirror of
>> David's which I can't clone normally, for some reason), for what it's
>> worth.
>> 
>
> I don't know why I have those problems either. Do you think it would be
> possible to just apply the patch suite to trunk in svn once we fix the
> test issue ? Since the patches do not touch the existing source tree
> (except for a few bugs on windows I can split up if required), it would
> be more practical to have all this in svn.
>   
As far as I'm concerned, that would be fine.

Is PyMODINIT_FUNC pulled in from Python.h?

Also, would you like svn commit access? That may just make things easier 
-- John, what do you think? I think we can trust David. :)

-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] [PATCH] experimental numscons support in matplotlib

[Andrew Straw]

Michael Droettboom wrote:
> I know it's been a while since you announced this, but I'm just looking 
> into this now.  

Also, I got some ways in making the buildbot build with numscons, but I 
stopped at a bug where it looked like the matplotlib.tests.* modules 
were not getting installed:

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

I haven't had a chance to debug this further, but I'm open to ideas. 
Also, this branch is building from a git repository (a mirror of David's 
which I can't clone normally, for some reason), for what it's worth.


> 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),
>>
>> cheers,
>>
>> David
>>
>> --
>> 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
>>   
>> 
>
>   


--
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] mysterious test_axes/fill_units failure; buildbot images back online

[Andrew Straw]

Hi All,

I just spent an hour or two tracking down some problems with the 
buildbot test images that crept in unnoticed with the pdf backend 
testing. I think I now fixed all the issues with the buildbot testing, 
which required a few changes to the MPL source and a few on the buildbot 
server to build the image overview pages correctly. Anyhow, the image 
failure overview page is back to displaying useful information at 
http://mpl.code.astraw.com/overview.html

All this was prompted by a buildbot failure that occurred starting at 
r7958 or r7959, although these changes seem unlikely to be the cause of 
the issue. So, I'm a little mystified as to the actual cause, but it 
again looks like some freetype problem. Mike, do you think it could 
somehow be related to your recent font 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

Re: [matplotlib-devel] imshow zorder (patch for review)

[Andrew Straw]

>
> On Wed, Nov 11, 2009 at 7:12 PM, Andrew Straw  wrote:
>   
>> > I had a patch waiting in the wings for that, but I wanted to see the dust
>> > settle before committing it. I think the dust is officially settled, so
>> > please commit yours or else I'll commit mine.
>> >
>> 
>
> Please go ahead.
>   
Will do.


>> By the way, I just encountered some zorder issue with the new patch.
>> The thing is, zorder=1 for Images seems to high.
>> For example, patches also have zorders=1. So, if I draw an image, and
>> add some patches (which I often do to indicate regions of interests),
>> the patches are drawn before images and become invisible. This happens
>> because images are appended to dsu list after all other artists.
>>
>> 
>
> The other thing I noticed by quickly going through axes.py is that
> when _axisbelow==True, the zorders of xaxis and yaxis is set to 0.5,
> which is lower than images. While the doc say
>
>   *axisbelow*draw the grids and ticks below the other
>  artists
>
> I don't think one wants to draw axis (grid+ticks) even below images.
>
> Well, there should be a few ways to fix this, but how others think
> about reducing the Image's zorder to 0?

I'm fine with the default Image's zorder at 0 -- I'm explicitly setting 
it for the cases I'm interested in anyway, and I think that would give 
better consistency with the old way. Also, I think this is better and 
more explicit than just inserting them at the beginning of the dsu list 
and relying on a stable sort to keep them drawn below various patches, 
which is how I interpreted your meaning for that approach.

I'll check in this change, too.

-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] imshow zorder (patch for review)

[Andrew Straw]

Jae-Joon Lee wrote:
> I also committed a small patch that makes zorders respected among
> images (not with other artists) for noncomposit backends.
>   
That looks fine to me. Thanks.
> Anyhow, can we get rid of the second items in the "dsu" list? My guess
> is that this is to make the sort stable, but python sort is already
> stable, isn't it?
>   
I had a patch waiting in the wings for that, but I wanted to see the 
dust settle before committing it. I think the dust is officially 
settled, so please commit yours or else I'll commit mine.

-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] imshow zorder (patch for review)

[Andrew Straw]

Andrew Straw wrote:
> John Hunter wrote:
>   
>> On Mon, Nov 9, 2009 at 10:21 AM, Andrew Straw  wrote:
>>   
>> 
>>> Hi All,
>>>
>>> I have addressed what I think is a long-standing wart: zorder is mostly
>>> ignored for imshow(). (See e.g.
>>> http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314
>>> ) The question is whether I should apply the attached patch.
>>> 
I went ahead and committed this patch to the trunk in r7950.

Here's the CHANGELOG entry:

2009-11-10 Single images, and all images in renderers with
   option_image_nocomposite (i.e. agg, macosx and the svg
   backend when rcParams['svg.image_noscale'] is True), are
   now drawn respecting the zorder relative to other
   artists. (Note that there may now be inconsistencies across
   backends when more than one image is drawn at varying
   zorders, but this change introduces correct behavior for
   the backends in which it's easy to do so.)

Jae Joon raised a couple of concerns:

1) the patch would introduces inconsistent behavior between backends -- 
namely that PS and other backends, when given more than one image, would 
"composite" (or rasterize) all images and stick them underneath 
everything else. Agg would have proper zordering between images and 
other artists.

2) there is doubt about the utility of such functionality. Jae-Joon says 
"I think it is often sufficient if we draw images at the bottom but 
respect zorders among images".

As for #1, it seems to me this is simply a bug/limitation with the 
compositing functionality (e.g. the PS backend). The SVG backend has the 
possibility to turn compositing on or off based on the svg.image_noscale 
rcParam, and perhaps other backends could grow something similar. I 
can't see why this patch -- that specifically solves the bug/limitation 
in the backends where its easily possible -- should be held back due to 
this.

As for #2, perhaps my use case will be convincing -- I'm trying to draw 
reconstructions of various experimental setups, and the easiest way to 
do this is to create texture-mapped rectangles in which I can control 
the zorder -- a single texture may need to be over some artists but 
under others. Perhaps there's an easier way to achieve this, but I'm not 
aware of it.

Jae Joon has also stated that he's OK with the patch, so I went ahead 
and committed it. In light of all this, please let me know if you still 
have concerns, and hopefully they can be addressed. In the worst case, 
we can back this patch out.

-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] imshow zorder (patch for review)

[Andrew Straw]

Jae-Joon Lee wrote:
> On Mon, Nov 9, 2009 at 12:44 PM, Eric Firing  wrote:
>   
>> PS backend already does things differently from others because it doesn't
>> handle alpha, correct?  Does the patch make this situation any worse?
>>
>> 
>
> When there are multiple Images and render.option_image_nocomposite()
> is false (as in the ps backend ), the images are composited
> (rasterized) into a single image before it is passed to the backend.
> So, AS FAR AS the images are concerned, I think the ps backend does
> handle alpha correctly and the results are consistent between
> backends.
>
> And with the Andrew's patch, and if there are non-image artists
> between two images, the results can be different. For example, those
> non-image artists can be obscured by the foreground image in the agg
> backend, but will always show up in the ps backend.
> So, I think this is somewhat different issue than alpha being ignored
> in the ps backend.
>   
What's the motivation of the ps backend "compositing" (rasterizing to a 
single bitmap) multiple images? It seems it will, by design, preclude 
the use of non-image artists between two images. I guess the motivation 
is to reduce output file size. Maybe Axes.draw() should disable 
compositing in the scenario where a non-image artist is sandwiched by 
image artists and suffer the increased file size.

-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] imshow zorder (patch for review)

[Andrew Straw]

John Hunter wrote:
> On Mon, Nov 9, 2009 at 10:21 AM, Andrew Straw  wrote:
>   
>> Hi All,
>>
>> I have addressed what I think is a long-standing wart: zorder is mostly
>> ignored for imshow(). (See e.g.
>> http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314
>> ) The question is whether I should apply the attached patch.
>> 
>
> Will this help with the OP's original "wart", which was the inability
> to add multiple images and move one to the top with zorder.  Your
> patch is only applied when len(images)<=1 or
> renderer.option_image_nocomposite(), both of which will be False when
> using Agg with multiple images, no?
>   
OK, sorry I linked to a motivating example that actually wasn't exactly 
the same as the use case I have -- I want a single image to play well 
with other artists' zorder. This patch does handle that scenario. I 
simply was too quick choosing this example out of the email history to 
justify the patch.

So now the question for me is what is this option_image_nocomposite is 
so that I can generalize the patch to both when it's True and False. 
 From the emails here, (my only knowledge on it so far) it seems it has 
something to do with the capabilities of the renderer rather than a 
run-time option selected by the user. I'll dig a little deeper into this 
option and see if my patch can deal with other cases, too. Stay tuned...

-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] imshow zorder (patch for review)

[Andrew Straw]

Hi All,

I have addressed what I think is a long-standing wart: zorder is mostly 
ignored for imshow(). (See e.g. 
http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314 
) The question is whether I should apply the attached patch.


The worry is that someone is relying on the old behavior of images being 
underneath everything else. To a degree, this could be achieved by 
having the default image zorder be lower than everything else. 
Currently, imshow() creates images with zorder 1, which is pretty low on 
the hierarchy, but there may be something lower. (The artist base class 
default is 0, but the Line2D class bumps it to 2.) All tests pass with 
the change, and manual inspection of several of the pylab_examples don't 
show any difference before and after the patch.


-Andrew
diff --git a/lib/matplotlib/axes.py b/lib/matplotlib/axes.py
index f628134..d23d1ce 100644
--- a/lib/matplotlib/axes.py
+++ b/lib/matplotlib/axes.py
@@ -1721,7 +1721,8 @@ class Axes(martist.Artist):
 
 if len(self.images)<=1 or renderer.option_image_nocomposite():
 for im in self.images:
-im.draw(renderer)
+dsu.append( (im.zorder, len(dsu), im) )
+dsu.sort() # re-sort with images now
 else:
 # make a composite image blending alpha
 # list of (mimage.Image, ox, oy)
--
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] Comparing pdf output in tests

[Andrew Straw]

Jouni K. Seppänen wrote:
> Andrew Straw  writes:
>
>   
>> Sorry for not noticing this earlier, but I'm looking in the baseline 
>> image directory, and I see a bunch of *_pdf.png files. I guess these 
>> have been convered to png from pdf on the tester's machine. Do you think 
>> it makes more sense to have the .pdf files in the test repo and convert 
>> to png at test run time? This way we don't become dependent on gs 
>> rendering quirks or differences across pdf renderers. Maybe the files 
>> are also smaller.
>> 
>
> That's exactly how it works now, isn't it? You are seeing the *_pdf.png
> files because those get produced while running the tests from the *.pdf
> files, and they are not checked into the svn repository.
>   
Sorry for the false alarm. My image browser was showing the .png and
.svg files, but not the .pdfs for some reason. I assumed it was showing
all the files in the directory, which lead to this false conclusion.

-Andrew

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Problem adding a new test

[Andrew Straw]

Michael Droettboom wrote:
> I've committed support for comparing SVG files using Inkscape and 
> verifying them against the official SVG DTD using xmllint. 
I just noticed the test_axes/hexbin_extent.svg baseline image is more 
than 5 MB. I wonder if we can somehow simplify the svg generated to 
reduce the file size or if we should perhaps just not do the svg 
extension on this test?

-Andrew

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

[Andrew Straw]

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

Sorry for not noticing this earlier, but I'm looking in the baseline 
image directory, and I see a bunch of *_pdf.png files. I guess these 
have been convered to png from pdf on the tester's machine. Do you think 
it makes more sense to have the .pdf files in the test repo and convert 
to png at test run time? This way we don't become dependent on gs 
rendering quirks or differences across pdf renderers. Maybe the files 
are also smaller.

-Andrew

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 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
>> 
>
> Hi Andrew,
> Please try the following. It's a script that clips an NxN image based on 
> its contour.
> Thanks,
> -Julien
>   
Hi Julien,

I made a couple fixes to MPL 0.99 maintenance branch and then added a 
modified version your example in the tests. See 
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/tests/test_axes.py?r1=7870&r2=7869&pathrev=7870

You should be able to use this approach to do what you were originally 
after.

My actual fixes to MPL were in r7866 and r7867. I had to take a slightly 
different approach than your suggestion. The approach I implemented 
based on your initial patch doesn't access private variables or change 
the way calling setters methods works.

-Andrew

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Problem adding a new test

[Andrew Straw]

Michael Droettboom wrote:
> I've committed support for comparing SVG files using Inkscape and 
> verifying them against the official SVG DTD using xmllint.
>   
Man, are we standards compliant around here or what? :) Cool.

> Michael Droettboom wrote:
>   
>> Andrew Straw wrote:
>>   
>> 
>>> Done in r7863. To make use of it, do something like the following patch
>>> (and don't forget to delete the baseline .pdf files from the repository):
>>>
>>> -...@image_comparison(baseline_images=['simplify_curve'])
>>> +...@image_comparison(baseline_images=['simplify_curve'],extensions=['png'])
>>>   
>>> 
>>>   
>> Great!
>>   
>> 
> This is a nice feature.  However, in hindsight, I may not use it right 
> away -- I actually found a bug in the SVG backend using one of the tests 
> I assumed would only affect the Agg backend.  :)
>   
I think it's good not to use the feature very much. I've already found 
it handy when developing against a test -- you only need to generate 
that test's image once.

> A couple more comments about the test framework -- which has already 
> paid for itself ten times over.  In Numpy (and a number of local Python 
> projects), I can 'cd' to the tests directory and do something like:
>
>nosetests test_simplification.py:test_hatch_simplify
>
> and run on particular test, or a single file of tests.  It's a huge time 
> saver when trying to fix a bug.  However, with matplotlib I get:
>
>  > nosetests test_simplification.py
> E
> ==
> ERROR: Failure: ImportError (cannot import name cbook)
> 
> I suspect this is something peculiar to how matplotlib gets imported.
>   

Yes, it would be very nice, I absolutely agree. I'm not sure what's 
going on, either, but I agree that it would be nice to fix. See below 
for an idea.


> Also, I have a quad-core machine, so I put this in my .noserc, which 
> will run tests in parallel:
>
>[nosetests]
>processes=4
>
> Unfortunately, due to however matplotlib is delegating to nose, this 
> doesn't seem to get picked up.
>
> I don't know if I'll get a chance to look at these things right away, 
> but thought I'd share in case the solutions are obvious to anyone else 
> (which I know isn't good form, but hey... ;)
>   
My guess is that this may actually be related to the first issue. On 
this second issue, though, I have a specific idea -- in order for MPL to 
pickup the nose plugin, I had to do the song and dance in test() of 
matplotlib/__init__.py in which I create a nose.config.Config instance. 
I suspect this is why your processes argument isn't getting through -- 
we're completely bypassing any local nose config and creating ours 
programattically. I'm definitely not in favor the big song and dance, so 
if you can rip it out and still get the plugin to load, that would be super.

Once that is figured out, presumably the direct call to "nosetests 
test_simplification.py:test_hatch_simplify" will also load the nose 
plugins and thus not exhibit weird behavior when a known failure is 
encountered.

I almost certainly won't get a chance to look at these right away, so if 
anyone wants to go spelunking in the nose/mpl interaction, feel free.

-Andrew

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [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
>   
OK, I managed to clone your repo -- I cloned mine, then added yours as a
remote, fetched it, and pushed the results to a new branch on my github
repo: http://github.com/astraw/matplotlib/tree/dev/cournapeau-scons-build

But having done that, now I'm having trouble building. Calling with
"python setupscons.py install", I get:

Traceback (most recent call last):
  File "setupscons.py", line 232, in 
setup_package()
  File "setupscons.py", line 228, in setup_package
configuration=configuration)
  File "/usr/lib/python2.6/dist-packages/numpy/distutils/core.py", line
150, in setup
config = configuration()
  File "setupscons.py", line 197, in configuration
config.add_sconscript('SConstruct', package_path='lib/matplotlib')
TypeError: add_sconscript() got an unexpected keyword argument
'package_path'

What version of numpy do I need for this? I might have to build a new
chroot, since I want the Ubuntu Hardy chroot I'm currently using to
stick with Hardy's default numpy installation.

-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

[matplotlib-devel] towards a poor man's texture map in mplot3d

[Andrew Straw]

Hi,

I'm trying to get something like texture mapping to work. (I don't need
anything fancy transforms between texel location and image location,
though. I'm happy to specify just a 2D grid of pixel colors that appear
onto a rectangle positioned in 3D space.)

Given that, I made a demo based on pcolor which I think should do the
job with a little work. I based this mainly on
examples/mplot3d/pathpatch3d_demo.py, which is pretty close to this.
Here's my

http://github.com/astraw/matplotlib/blob/dev/straw-poormans-texture/examples/mplot3d/poor_mans_texture_map.py

Right now, though, running this results in the following traceback:

$ python poor_mans_texture_map.py
Traceback (most recent call last):
  File "poor_mans_texture_map.py", line 21, in 
art3d.patch_collection_2d_to_3d(s, zdir="x")
  File
"/usr/local/lib/python2.6/dist-packages/mpl_toolkits/mplot3d/art3d.py",
line 301, in patch_collection_2d_to_3d
col.set_3d_properties(zs, zdir)
  File
"/usr/local/lib/python2.6/dist-packages/mpl_toolkits/mplot3d/art3d.py",
line 279, in set_3d_properties
xs, ys = zip(*self.get_offsets())
ValueError: need more than 0 values to unpack

Reinier -- can you comment on how the patch offsets are supposed to be
interpreted as x,y values in this context? From the docstring at
lib/matplotlib/collections.py, I read "*offsets* and *transOffset* are
used to translate the patch after rendering (default no offsets)". It's
not immediately clear to me how the offsets should then be resulting in
X,Y values for 3D plotting. Or is something else entirely going on here?
I'm happy to do some leg-work here if you point me in the right direction.

-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

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] 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] [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] 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:
> 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] [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]

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]

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]

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

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]

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]

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]

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

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]

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

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

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

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

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