matplotlib-devel Mailing List for matplotlib

Am Montag, den 05.10.2009, 13:36 -1000 schrieb Eric Firing:
> Benjamin Drung wrote:
> > Am Montag, den 05.10.2009, 12:50 -1000 schrieb Eric Firing:
> >> Benjamin Drung wrote:
> >>> Hi,
> >>>
> >>> setupext.py contains a basedir directory. Please add there
> >>> 'linux2-alpha', 'linux2-hppa', 'linux2-mips', 'linux2-sparc',
> >>> 'gnukfreebsd7', 'gnukfreebsd8'.
> >>>
> >>> It would be nice, if matplotlib had an option to disable '/usr/local'.
> >>> This would be useful for distributions.
> >>>
> >>> The Debian patch attached (does both).
> >> I'm not sure I understand this.  The patch seems to remove /usr/local 
> >> from the list.  Why do you want to do this?  I am assuming the original 
> >> idea was that if a user wants to build a version of a library and put it 
> >> in /usr/local, then that is what mpl should use; if it is not found 
> >> there, then use the distro version in /usr.  This seems to me like the 
> >> right strategy, so I am reluctant to apply your patch as-is.
> > 
> > Ok, attached a patch which adds support for other architectures.
> 
> Applied, thank you.

Thanks.

> > The Debian/Ubuntu package should be build against the distro versions of
> > the libraries. The Debian/Ubuntu package should not link to packages
> > in /usr/local. Therefore we want to disable it for building the package.
> > 
> > It would be nice, if you can add an --disable-usr-local for distro
> > maintainers. With this option set, '/usr/local' will be stripped from
> > basedir.
> 
> It looks like it would be very easy to add this as an option to be set 
> in setup.cfg; is this adequate?

Yes, that's equivalent.

> I don't know how to do it easily via a command-line option because those 
> options are processed by distutils.core.setup(), so as far as I can see, 
> they are not directly available to setup.py or setupext.py, short of 
> adding our own layer of command-line processing.

Implement what you like more.

Benjamin Drung wrote:
> Am Montag, den 05.10.2009, 12:50 -1000 schrieb Eric Firing:
>> Benjamin Drung wrote:
>>> Hi,
>>>
>>> setupext.py contains a basedir directory. Please add there
>>> 'linux2-alpha', 'linux2-hppa', 'linux2-mips', 'linux2-sparc',
>>> 'gnukfreebsd7', 'gnukfreebsd8'.
>>>
>>> It would be nice, if matplotlib had an option to disable '/usr/local'.
>>> This would be useful for distributions.
>>>
>>> The Debian patch attached (does both).
>> I'm not sure I understand this.  The patch seems to remove /usr/local 
>> from the list.  Why do you want to do this?  I am assuming the original 
>> idea was that if a user wants to build a version of a library and put it 
>> in /usr/local, then that is what mpl should use; if it is not found 
>> there, then use the distro version in /usr.  This seems to me like the 
>> right strategy, so I am reluctant to apply your patch as-is.
> 
> Ok, attached a patch which adds support for other architectures.

Applied, thank you.

> 
> The Debian/Ubuntu package should be build against the distro versions of
> the libraries. The Debian/Ubuntu package should not link to packages
> in /usr/local. Therefore we want to disable it for building the package.
> 
> It would be nice, if you can add an --disable-usr-local for distro
> maintainers. With this option set, '/usr/local' will be stripped from
> basedir.

It looks like it would be very easy to add this as an option to be set 
in setup.cfg; is this adequate?

I don't know how to do it easily via a command-line option because those 
options are processed by distutils.core.setup(), so as far as I can see, 
they are not directly available to setup.py or setupext.py, short of 
adding our own layer of command-line processing.

Eric


> 
> Cheers,
> Benjamin
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Am Montag, den 05.10.2009, 12:50 -1000 schrieb Eric Firing:
> Benjamin Drung wrote:
> > Hi,
> > 
> > setupext.py contains a basedir directory. Please add there
> > 'linux2-alpha', 'linux2-hppa', 'linux2-mips', 'linux2-sparc',
> > 'gnukfreebsd7', 'gnukfreebsd8'.
> > 
> > It would be nice, if matplotlib had an option to disable '/usr/local'.
> > This would be useful for distributions.
> > 
> > The Debian patch attached (does both).
> 
> I'm not sure I understand this.  The patch seems to remove /usr/local 
> from the list.  Why do you want to do this?  I am assuming the original 
> idea was that if a user wants to build a version of a library and put it 
> in /usr/local, then that is what mpl should use; if it is not found 
> there, then use the distro version in /usr.  This seems to me like the 
> right strategy, so I am reluctant to apply your patch as-is.

Ok, attached a patch which adds support for other architectures.

The Debian/Ubuntu package should be build against the distro versions of
the libraries. The Debian/Ubuntu package should not link to packages
in /usr/local. Therefore we want to disable it for building the package.

It would be nice, if you can add an --disable-usr-local for distro
maintainers. With this option set, '/usr/local' will be stripped from
basedir.

Cheers,
Benjamin

Benjamin Drung wrote:
> Hi,
> 
> setupext.py contains a basedir directory. Please add there
> 'linux2-alpha', 'linux2-hppa', 'linux2-mips', 'linux2-sparc',
> 'gnukfreebsd7', 'gnukfreebsd8'.
> 
> It would be nice, if matplotlib had an option to disable '/usr/local'.
> This would be useful for distributions.
> 
> The Debian patch attached (does both).

I'm not sure I understand this.  The patch seems to remove /usr/local 
from the list.  Why do you want to do this?  I am assuming the original 
idea was that if a user wants to build a version of a library and put it 
in /usr/local, then that is what mpl should use; if it is not found 
there, then use the distro version in /usr.  This seems to me like the 
right strategy, so I am reluctant to apply your patch as-is.

Eric

> 
> Cheers,
> Benjamin
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi,

Guess the correct directory in Debian/Ubuntu fails. Replacing all tcl by
tk does not lead to a correct directory:
/usr/share/tcltk/tcl8.5 -> /usr/share/tktk/tk8.5
The correct directory is /usr/share/tcltk/tk8.5
A patch is attached.

Cheers,
Benjamin

Hi,

setupext.py contains a basedir directory. Please add there
'linux2-alpha', 'linux2-hppa', 'linux2-mips', 'linux2-sparc',
'gnukfreebsd7', 'gnukfreebsd8'.

It would be nice, if matplotlib had an option to disable '/usr/local'.
This would be useful for distributions.

The Debian patch attached (does both).

Cheers,
Benjamin

Hi,

"doc/make.py clean" runs svn-clean. Running svn-clean outside the svn
repository does not clean anything. So "doc/make.py clean" does not work
in the Debian/Ubuntu package. Please remove the generated files directly
and do not relay on svn. In our package we run these commands:

rm -rf doc/build doc/examples
rm -f doc/mpl_examples/api/*.png
rm -f doc/mpl_examples/pylab_examples/*.png
rm -f doc/mpl_examples/pylab_examples/*.pdf
rm -f doc/mpl_examples/units/*.png
rm -f doc/pyplots/tex_demo.png
rm -f doc/_static/matplotlibrc
rm -f doc/_templates/gallery.html

Cheers,
Benjamin

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