matplotlib-devel Mailing List for matplotlib

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.