matplotlib-devel Mailing List for matplotlib (Page 5)

Reinier Heeres wrote:
> Hi Philip, all,
> 
> This work seems to overlap a lot with the recent color map changes I
> committed (http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/colors.py?r1=7488&r2=7620),
> except for the piece-wise constant color maps.
Exactly. And I don't think piece-wise constant maps are a good idea, so 
I oppose including a function to make them.
> 
> Of course we should avoid duplicate code and work, so perhaps we can
> narrow it down to the piece-wise constant part? Please let me know
> what you think. We should definitely add a few examples of how to use
> this new code, as it might not be that clear directly. Basically the
> following is the idea:
> 
> import numpy as np
> import matplotlib.colors as mcol
> import matplotlib.pyplot as plt
> 
> stop = mcol.LinearSegmentedColormap.from_list('stop', ['green',
> 'orange', 'red'])
> # or: stop = mcol.LinearSegmentedColormap.from_list('stop', [(0,
> 'green'), (0.2, 'orange'), (1, 'red')])
from_list could have an API more like Phillip's, with an optional 
argument for the transition points instead of using the sequence of 
pairs. I'm not sure whether this is an improvement or not, but it has 
some appeal to me.
One might also argue that instead of being a static method, from_list 
should be renamed as a free-standing factory function in the colors 
namespace. Or that such an alias be created.
Eric
> 
> x = np.arange(100)
> y = x.reshape((5,20))
> plt.imshow(y, cmap=stop)
> plt.show()
> 
> Beside that, I think in no part of MPL we depend on scipy explicitly,
> so it would be good to get rid of that. Also, your use of isinstance
> should be replaced by the more generic functions in cbook.py (e.g.
> is_string_like, is_numlike).
> 
> Regards,
> Reinier
> 
> On Sun, Oct 4, 2009 at 4:34 AM, Dr. Phillip M. Feldman
> <pfe...@ve...> wrote:
>> "Create patch" worked. Thanks! The output is attached.
>>
>> http://www.nabble.com/file/p25734649/colors.py.diff colors.py.diff
>>
>>
>>> From: Dr. Phillip M. Feldman [mailto:pfe...@ve...]
>>> Sent: Thursday, October 01, 2009 20:45
>>>
>>> Unfortunately, I'm on a Windows system, and it appears that I
>>> must use SVN's GUI interface, which does not provide a
>>> mechanism for saving the diff to a file.
>> Which GUI are you using? If TortoiseSVN, you right-click on the modified
>> file
>> and select "Create patch..." from the TortoiseSVN menu.
>> --
>> View this message in context: http://www.nabble.com/proposed-change-to-colors.py-tp25691605p25734649.html
>> Sent from the matplotlib - devel mailing list archive at Nabble.com.
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry&reg; 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&#45;12, 2009. Register now&#33;
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
> 
> 
> 

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

On Fri, Oct 2, 2009 at 12:27 AM, Andrew Straw <str...@as...> wrote:
> 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.)
The OSX build bot has been down ever since the build machine was
upgraded to 10.6. Unfortunately, this has triggered some build and
runtime problems for mpl that I haven't been able to crack yet.

Hi Philip, all,
This work seems to overlap a lot with the recent color map changes I
committed (http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/colors.py?r1=7488&r2=7620),
except for the piece-wise constant color maps.
Of course we should avoid duplicate code and work, so perhaps we can
narrow it down to the piece-wise constant part? Please let me know
what you think. We should definitely add a few examples of how to use
this new code, as it might not be that clear directly. Basically the
following is the idea:
import numpy as np
import matplotlib.colors as mcol
import matplotlib.pyplot as plt
stop = mcol.LinearSegmentedColormap.from_list('stop', ['green',
'orange', 'red'])
# or: stop = mcol.LinearSegmentedColormap.from_list('stop', [(0,
'green'), (0.2, 'orange'), (1, 'red')])
x = np.arange(100)
y = x.reshape((5,20))
plt.imshow(y, cmap=stop)
plt.show()
Beside that, I think in no part of MPL we depend on scipy explicitly,
so it would be good to get rid of that. Also, your use of isinstance
should be replaced by the more generic functions in cbook.py (e.g.
is_string_like, is_numlike).
Regards,
Reinier
On Sun, Oct 4, 2009 at 4:34 AM, Dr. Phillip M. Feldman
<pfe...@ve...> wrote:
>
> "Create patch" worked. Thanks! The output is attached.
>
> http://www.nabble.com/file/p25734649/colors.py.diff colors.py.diff
>
>
>> From: Dr. Phillip M. Feldman [mailto:pfe...@ve...]
>> Sent: Thursday, October 01, 2009 20:45
>>
>> Unfortunately, I'm on a Windows system, and it appears that I
>> must use SVN's GUI interface, which does not provide a
>> mechanism for saving the diff to a file.
>
> Which GUI are you using? If TortoiseSVN, you right-click on the modified
> file
> and select "Create patch..." from the TortoiseSVN menu.
> --
> View this message in context: http://www.nabble.com/proposed-change-to-colors.py-tp25691605p25734649.html
> Sent from the matplotlib - devel mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; 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&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-- 
Reinier Heeres
Tel: +31 6 10852639

Andrew Straw wrote:
> 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. 
It took ~ 10 hours on a 4 years-old machine :)
> If this does import reasonably, would it be a real pain for
> you to rebase again?
Not really, I export the branch with format-patch and import with git
am, so it takes me less time than writing this very sentence :)
>> 
>> 
> 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.
> 
Yes, that's the main point of the numpy/scipy mirrors - Pauli did the
work with his git-svn-automirror (which is something you may want to
look at if you want an automatic mirror).
cheers,
David

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

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

Thank you for reporting.
I guess this was a simple oversight.
This should be fixed in the maint. branch and the trunk.
Meanwhile, you may manually set the remove method.
im = ax.imshow(...)
im._remove_method = lambda a: ax.images.remove(a)
Regards,
-JJ
On Thu, Oct 1, 2009 at 3:56 AM, Martin Teichmann
<mar...@mb...> wrote:
> Hello List,
>
> Normally, something added to axes in
> a plot can later be removed by
> saying element.remove(). All but
> images, for example plotted with imshow,
> since they lack a _remove_method.
>
> Is that a bug or a feature?
>
> Greetings
>
> Martin Teichmann
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; 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&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

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

Andrew Straw <str...@as...> 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
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

"Create patch" worked. Thanks! The output is attached.
http://www.nabble.com/file/p25734649/colors.py.diff colors.py.diff 
> From: Dr. Phillip M. Feldman [mailto:pfe...@ve...] 
> Sent: Thursday, October 01, 2009 20:45
> 
> Unfortunately, I'm on a Windows system, and it appears that I 
> must use SVN's GUI interface, which does not provide a 
> mechanism for saving the diff to a file.
Which GUI are you using? If TortoiseSVN, you right-click on the modified
file
and select "Create patch..." from the TortoiseSVN menu.
-- 
View this message in context: http://www.nabble.com/proposed-change-to-colors.py-tp25691605p25734649.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Reinier and others,
I just added a PathPatch3D class in mplot3d.art3d.
It is a slight variation of Patch3D that respect the codes the bezier
curve (I believe Patch3D does not).
An example is also added as pathpatch3d_demo.py, with a screenshot below.
http://dl.getdropbox.com/u/178748/mpl/pathpatch3d_demo.png
It will be appreciated if Reinier of others review the code (the patch
is quite small).
My original intention was to have an option for the labels (including
ticklabels) look as if they are in the particular plane of axes (as
partly demonstrated in my example). But I won't be able to work on it
soon.
Regards,
-JJ

> From: Dr. Phillip M. Feldman [mailto:pfe...@ve...] 
> Sent: Thursday, October 01, 2009 20:45
> 
> Unfortunately, I'm on a Windows system, and it appears that I 
> must use SVN's GUI interface, which does not provide a 
> mechanism for saving the diff to a file.
Which GUI are you using? If TortoiseSVN, you right-click on the modified file
and select "Create patch..." from the TortoiseSVN menu.

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

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

David Cournapeau wrote:
> Hi Andrew,
> 
> Andrew Straw wrote:
>> 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.)
>> 
David,
I'm interested also--especially if it would eventually help solve some 
of the build problems that crop up. (I already use scons in another 
context, and that helps make me receptive to numscons.)
> 
> It should work on any distro. I have not tested this really hard yet,
> though - but it already works better for me than the current setupext.py
> (I may miss something, but the detection fails horribly on my machine,
> especially for libs not installed in /usr).
> 
> There are some configurations which are not supported yet (wxpython <
> 2.8, tkagg, and win32 + mac os x backends), but it should be relatively
> easy to add support for it, except maybe for mac os x backend because of
> objective c because numscons does not handle objective C yet (my focus
> is windows ATM, but if supporting every configuration is a condition for
> the patch to be included, I am willing to work on it).
Judging from list traffic, building on OS X now causes even more pain 
and suffering than building on Windows. I suppose that is partly 
because so few people try to build on Windows.
> 
>> looks pretty unintrusive to me -- I can't see why it would hurt to
>> include it direct into MPL.
> 
> The patch could be made smaller and more robust if I were allowed to do
> some basic refactoring to share configuration data between setup.py and
> setupscons.py: either fixing setup.py so that it uses a __main__ and
> does not execute the whole distutils dance at import time, or as I
> usually do in other projects, putting metadata in a separate file.
I don't do much with the build system, but from the sidelines I would 
encourage you to propose what looks sensible to you.
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?
Eric
> 
> cheers,
> 
> David
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; 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&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Andrew Straw wrote:
> 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.
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,
cheers,
David

Hi Andrew,
Andrew Straw wrote:
> 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 should work on any distro. I have not tested this really hard yet,
though - but it already works better for me than the current setupext.py
(I may miss something, but the detection fails horribly on my machine,
especially for libs not installed in /usr).
There are some configurations which are not supported yet (wxpython <
2.8, tkagg, and win32 + mac os x backends), but it should be relatively
easy to add support for it, except maybe for mac os x backend because of
objective c because numscons does not handle objective C yet (my focus
is windows ATM, but if supporting every configuration is a condition for
the patch to be included, I am willing to work on it).
> looks pretty unintrusive to me -- I can't see why it would hurt to
> include it direct into MPL.
The patch could be made smaller and more robust if I were allowed to do
some basic refactoring to share configuration data between setup.py and
setupscons.py: either fixing setup.py so that it uses a __main__ and
does not execute the whole distutils dance at import time, or as I
usually do in other projects, putting metadata in a separate file.
cheers,
David

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

Jouni K. Seppänen wrote:
> Jouni K. Seppänen <jk...@ik...> 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

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

Hello Ryan-
Unfortunately, I'm on a Windows system, and it appears that I must use SVN's
GUI interface, which does not provide a mechanism for saving the diff to a
file.
Phillip
<snip>
svn diff > filename
Ryan
-- 
View this message in context: http://www.nabble.com/proposed-change-to-colors.py-tp25691605p25708920.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Hello List,
Normally, something added to axes in
a plot can later be removed by
saying element.remove(). All but
images, for example plotted with imshow,
since they lack a _remove_method.
Is that a bug or a feature?
Greetings
Martin Teichmann

On Wed, Sep 30, 2009 at 7:47 PM, Dr. Phillip M. Feldman
<pfe...@ve...> wrote:
>
> I've added three function defs at the end of colors.py. The revised
> colors.py is attached. (I haven't been able to figure out how to make SVN
> save the diff to a file). http://www.nabble.com/file/p25691605/colors.py
> colors.py
svn diff > filename
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

I've added three function defs at the end of colors.py. The revised
colors.py is attached. (I haven't been able to figure out how to make SVN
save the diff to a file). http://www.nabble.com/file/p25691605/colors.py
colors.py 
-- 
View this message in context: http://www.nabble.com/proposed-change-to-colors.py-tp25691605p25691605.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.