matplotlib-devel Mailing List for matplotlib (Page 4)

Jouni K. Seppänen <jk...@ik...> 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.
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) 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.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Michael Droettboom <md...@st...>
writes:
> Unfortunately, it doesn't seem to be running the new test at all. If I 
> put "assert False" at the top of the test, and even that doesn't fail. 
> If I remove the "image_comparison" decorator, however, the test will 
> fail. Maybe this is because the baseline image doesn't exist yet?
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,
to avoid causing spurious failures when a test is not even meant to be
run for all backends. I guess this should be done in some other way, and
perhaps the usual case is to test all backends for which the output can
be compared.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

I went to create a new image comparison test related to the hatching bug 
reported this morning.
I added my test to the bottom of test_simplification.py, and ran all the 
tests as follows:
 python -c "import matplotlib; matplotlib.test()"
Unfortunately, it doesn't seem to be running the new test at all. If I 
put "assert False" at the top of the test, and even that doesn't fail. 
If I remove the "image_comparison" decorator, however, the test will 
fail. Maybe this is because the baseline image doesn't exist yet? In 
the past, I've just run the tests, got a mismatch (because no baseline 
existed), and copied the current image to the baseline image and checked 
that in.
Am I using the wrong workflow, or is this a bug?
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,
I wanted to be able to select a rectangular region from the graph as 
one part of a script so I combined BlockingInput and 
RectangleSelector to create BlockingRectangleSelector, and the pylab 
style interface function, ginput_rect
This serves my immediate needs and I'm unlikely to develop it further.
Before adding it to matplotlib a couple of changes are needed::
* Other kinds of selectors, such as span, line and lasso should be 
possible
* Selectors such as RectangularSelector can be added to a set of axes 
but not removed. Removing them requires unhooking the mpl_connect 
callbacks, but the cid is not being saved.
* The graph wasn't always drawn before selection in ipython or before 
a subsequent show() so I forced it with explicit draw_idle() calls. 
This may lead to unnecessary redraws.
- Paul

I'm having some regression issues with 0.99.1.1 compared to 0.98.5.3 in 
"blocking_input.py".
I'm using pylab.clabel(...,manual=True) expecting my figure to ask me to 
input the locations of the contour labels. All was fine in 0.98.5.3, it 
does not seem to work with 0.99.1.1.
After some investigations I found:
1. With rev 7591, the button1, button2, and button3 methods in the 
BlockingMouseInput class have been renamed to mouse_event_add, 
mouse_event_stop, and mouse_event_stop. To date, these changes have not 
been made to BlockingContourLabeler which still has the button1 and 
button2 method that are in charge of actually adding and removing the 
new labels, and that are never called.
Replacing button1 by mouse_event_add and button3 by mouse_event_pop 
seems to return the "manually add contour label" functionality.
2. After that change, I get a crash on mouse_button_stop in 
BlockingMouseInput on line 196:
TypeError: stop_event_loop() takes exactly 1 argument (2 given)
After confirmation from the docuemntation that stoip_event_loop() should 
indeed not take any argument I would fix line 196 with:
 < self.fig.canvas.stop_event_loop(event)
 > self.fig.canvas.stop_event_loop()
-Julien

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
>> 
>> 
> 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"
> 
Yes, I have exactly the same problem - cloning through ssh is ok, though
(although it does not help you much). I already tried to remove/refork
the repo from you (I thought the problem may have been caused by
astraw/matplotlib being a new repo), to no end.
I wish git would improve their network support...
> 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.)
> 
I will,
David

>> 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
import numpy
import pylab
#Create a NxN image
N=100
(x,y) = numpy.indices((N,N))
x -= N/2
y -= N/2
r = numpy.sqrt(x**2+y**2-x*y)
#Create a contour plot at N/4 and extract both the clip path and transform
c=pylab.contour(r,[N/4])
clipPath = c.collections[0].get_paths()[0]
clipTransform = c.collections[0].get_transform()
#Plot the image clipped by the contour
pylab.imshow(r, clip_path=(clipPath,clipTransform))
pylab.show()

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:
> 
> 1. On line 622 of artist.py, v is now the tuple (Path,Transform) and 
> should be apply to func with apply(func,v). Hence the following 
> suggested change:
> 
> for k,v in props.items():
> func = getattr(self, 'set_'+k, None)
> if func is None or not callable(func):
> raise AttributeError('Unknown property %s'%k)
> < func(v)
> > if type(v) is tuple:
> > apply(func,v)
> else:
> func(v)
apply is deprecated. The block above could be written in one line as
 func(*tuple(v))
Eric
> changed = True
> 
> 2. On line 6278 of axes.py, im.set_clip_path(self.patch) should not 
> overwrite the clip path if already set. Hence the following suggested 
> change:
> 
> im.set_data(X)
> im.set_alpha(alpha)
> self._set_artist_props(im)
> < im.set_clip_path(self.patch)
> > if not im._clipon:
> > im.set_clip_path(self.patch)
> #if norm is None and shape is None:
> # im.set_clim(vmin, vmax)
> if vmin is not None or vmax is not None:
> im.set_clim(vmin, vmax)
> else:
> im.autoscale_None()
> im.set_url(url)
> 
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

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:
1. On line 622 of artist.py, v is now the tuple (Path,Transform) and 
should be apply to func with apply(func,v). Hence the following 
suggested change:
 for k,v in props.items():
 func = getattr(self, 'set_'+k, None)
 if func is None or not callable(func):
 raise AttributeError('Unknown property %s'%k)
< func(v)
 > if type(v) is tuple:
 > apply(func,v)
 else:
 func(v)
 changed = True
2. On line 6278 of axes.py, im.set_clip_path(self.patch) should not 
overwrite the clip path if already set. Hence the following suggested 
change:
 im.set_data(X)
 im.set_alpha(alpha)
 self._set_artist_props(im)
< im.set_clip_path(self.patch)
 > if not im._clipon:
 > im.set_clip_path(self.patch)
 #if norm is None and shape is None:
 # im.set_clim(vmin, vmax)
 if vmin is not None or vmax is not None:
 im.set_clim(vmin, vmax)
 else:
 im.autoscale_None()
 im.set_url(url)

Hi Mike,
thanks. Your Python implementation looks good. I will test it, when it
is official released and we package that release for Debian/Ubuntu. I
will let you know, if there is something missing or not working.
Otherwise all will be fine.
Cheers,
Benjamin
Am Dienstag, den 06.10.2009, 10:09 -0400 schrieb Michael Droettboom:
> I have committed your suggestion to SVN r7849 (0.99 branch) and r7850 
> (trunk). It does exactly what you listed, but using Python functions 
> rather than system calls. Please test in your environment and let me 
> know if it's adequate when you get a chance.
> 
> Mike
> 
> Benjamin Drung wrote:
> > 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

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

I have committed your suggestion to SVN r7849 (0.99 branch) and r7850 
(trunk). It does exactly what you listed, but using Python functions 
rather than system calls. Please test in your environment and let me 
know if it's adequate when you get a chance.
Mike
Benjamin Drung wrote:
> 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
>
>
> ------------------------------------------------------------------------------
> 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
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Here it is.
On Tue, Oct 6, 2009 at 12:19 PM, Jeff Whitaker <js...@fa...> wrote:
> Stephane Raynaud wrote:
>>
>> Hi Jeff,
>>
>> how about allowing units to be set as meters when calling
>> Basemap.drawmapscale ?
>> And maybe adding the keyword "format" for formatting numeric values.
>> That would be interesting when plotting maps with small area.
>>
>> Thanks.
>>
>>
>
> Stephane: I don't use the drawmapscale function very much (it was
> contributed by another user). If you would like to submit a patch, I'd be
> happy to test it and then commit it.
> -Jeff
>
-- 
Stephane Raynaud

Stephane Raynaud wrote:
> Hi Jeff,
>
> how about allowing units to be set as meters when calling Basemap.drawmapscale ?
> And maybe adding the keyword "format" for formatting numeric values.
> That would be interesting when plotting maps with small area.
>
> Thanks.
>
> 
Stephane: I don't use the drawmapscale function very much (it was 
contributed by another user). If you would like to submit a patch, I'd 
be happy to test it and then commit it. 
-Jeff

Hi Jeff,
how about allowing units to be set as meters when calling Basemap.drawmapscale ?
And maybe adding the keyword "format" for formatting numeric values.
That would be interesting when plotting maps with small area.
Thanks.
-- 
Stephane Raynaud

Phillip M. Feldman wrote:
> Hello Eric-
> 
> I'd like to understand the reason why you object to piecewise-constant 
> colormaps. I have found these to be useful for some types of plots. 
It is a crude and indirect way of achieving a result that can be 
achieved precisely and directly using ListedColormap and BoundaryNorm, 
or possibly a subclass. The problem is that discretization is being 
done at the wrong stage.
Suppose you have data in the range 1.5 to 2.5, and you want the low 
third of that range to be red, the middle green, and the upper blue. If 
you use LinearSegmentedColormap and one of your functions to make a 
discrete map, then you will have divided your interval of length 1 into 
256 segments, which does not allow you to specify exactly 1.5 + 1.0/3 as 
a transition point. You have only 8 bits of precision available.
What does allow you to specify the transitions exactly (to within the 
limits of double precision) is this:
cmap = ListedColormap(['r','g','b'])
norm = BoundaryNorm([1.5+1.0/3, 1.5+2.0/3], cmap.N)
Simple, readable, flexible: choose any boundaries you like, specify the 
colors any way you like, including pulling them out of an existing 
colormap. Efficient: the cmap lookup table has only as many entries as 
it needs, and the index into that table is calculated directly in a 
single step.
Now if you need autoscaling, with the boundaries calculated from vmin 
and vmax, then this can be done by subclassing BoundaryNorm. In both 
cases, after using this cmap and norm for a mappable, passing that 
mappable to colorbar will yield a reasonable result, because colorbar 
has special code to handle the BoundaryNorm.
> Also, the functionality to create piecewise-constant colormaps is 
> already provided by LinearSegmentedColormap, so "the cat is already out 
> of the bag", so to speak.. (I created my functions mainly because I 
LinearSegmentedColormap is very general, so yes, it can be used for this.
> found the LinearSegmentedColormap interface painful to use. Since then, 
That painfulness is exactly the reason why John Hunter added the 
from_list method 8 months ago (I forgot it had been there that long), 
and Reinier recently made it more flexible.
> I have found ways to produce the plots that I need with the existing 
> functions; some of the code isn't very pretty, but this is a secondary 
> consideration).
You are always welcome to use functions like that in your own code; if 
they help you, that's fine.
Whenever possible, we want to make it easy for users to plot with pretty 
code, so if you believe you can't, then either you are not seeing a nice 
way to do something, or there really is no nice way. In the latter 
case, an addition or improvement to mpl code may be in order. And in 
the former case, improvements in documentation and/or examples may be 
needed.
> 
> Eric/Reinier/all:
> 
> Is there some way to find out what development tasks are underway so 
> that duplication of effort can be avoided? If there were a list of 
> tasks with associated names and target dates, this would be very 
> useful. (Perhaps something like this already exists, but I have not 
> been able to find it).
> 
No, we operate in a very informal way. Big changes, and sometimes 
medium and smaller ones, are generally discussed on one of the lists, 
and that discussion indicates if anyone is actually working on the 
change. Some smaller and medium changes are simply done when a bee gets 
under someone's bonnet, leading to a burst of activity. I think most of 
us have at least short mental lists of things we would like to do, or to 
see done. All of us are severely constrained by time.
> Also, it seems as though the HTML documentation is sometimes quite 
> different from the doc strings. I've found the HTML easier to read 
> because of color, italics, etc., but the content of the doc strings is 
> sometimes better and/or quite different. It would be great if these 
> could be harmonized.
The API html docs are built automatically from the docstrings; the rest 
of the docs are written manually, and that does tend to lag.
Eric
> 
> Thanks!
> 
> Phillip
> 
> Eric Firing wrote:
>> 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.
>>>>
> 

Hello Eric-
I'd like to understand the reason why you object to piecewise-constant 
colormaps. I have found these to be useful for some types of plots. 
Also, the functionality to create piecewise-constant colormaps is 
already provided by LinearSegmentedColormap, so "the cat is already out 
of the bag", so to speak.. (I created my functions mainly because I 
found the LinearSegmentedColormap interface painful to use. Since then, 
I have found ways to produce the plots that I need with the existing 
functions; some of the code isn't very pretty, but this is a secondary 
consideration).
Eric/Reinier/all:
Is there some way to find out what development tasks are underway so 
that duplication of effort can be avoided? If there were a list of 
tasks with associated names and target dates, this would be very 
useful. (Perhaps something like this already exists, but I have not 
been able to find it).
Also, it seems as though the HTML documentation is sometimes quite 
different from the doc strings. I've found the HTML easier to read 
because of color, italics, etc., but the content of the doc strings is 
sometimes better and/or quite different. It would be great if these 
could be harmonized.
Thanks!
Phillip
Eric Firing wrote:
> 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.
>>>

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