matplotlib-devel Mailing List for matplotlib

Great, thanks for checking that in.
It looks like images/*.png didn't make it in.
John Hunter wrote:
> On 2/12/07, Andrew Straw <str...@as...> wrote:
>
> 
>> So, I sent the patch file to John, who'll hopefully commit it if he
>> approves. To paraphrase Robert Kern, "Working code ends all arguments".
>> So, since this was the nested way, and the biggest reason against it was
>> that it require code change, well, I changed the code, and perhaps the
>> arguments are ended?
>>
>> Because I did change a fair amount of data_path -using code, it'd be
>> good to exercise all your favorite font and image finding sections of
>> code. The bits I tried worked for me, of course, but no guarantees...
>> 
>
> OK, with a sledgehammer and a prayer, I got it in. I got the same
> error you did, and then had to physically remove mpl-data and it's
> contents from svn and commit, restore everything in the new order and
> commit again. It compiled, installed and ran, passing the tests I
> threw at it.
>
> I only ran about half of backend driver before I grew impatient, so
> others may want to do some additional testing. I copied your note
> from CHANGELOG to API_CHANGES.
>
> I suggest flushing your old mpl-data in site-packages/matplotlib as
> well as your ~/.matplotlib/ttffont.cache file before testing.
>
> Thanks for settling the argument!
>
> JDH
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

On 2/12/07, Martin Spacek <sc...@ms...> wrote:
> Looking through colors.py, I noticed that most of the grey cnames use
> the spelling 'gray' (the US standard I think), although 'lightgrey'
> shows up as a valid name, while 'lightgray' does not. After looking
> around the web a bit for what the correct html names are, I found most
> sites display 'gray' and 'grey' as synonymous, for all the different
> intensities (darkslate, light, dim, etc).
>
> So, here's a patch that does the same, allowing ColorConverter to accept
> both spellings for all the intensities.
>
Thanks for the suggestion -- I did this automagically with
# add british equivs
for k, v in cnames.items():
 if k.find('gray')>=0:
 k = k.replace('gray', 'grey')
 cnames[k] = v
Note that in pylab, you can get some extra information by doing
>>> help(colors)
colors()
 This is a do nothing function to provide you with help on how
 matplotlib handles colors.
 Commands which take color arguments can use several formats to
 specify the colors. For the basic builtin colors, you can use a
 single letter
 b : blue
 g : green
 r : red
 c : cyan
 m : magenta
 y : yellow
 k : black
 w : white
 For a greater range of colors, you have two options. You can
 specify the color using an html hex string, as in
 color = '#eeefff'
 or you can pass an R,G,B tuple, where each of R,G,B are in the
 range [0,1].
 You can also use any legal html name for a color, like 'red',
 'burlywood' and 'chartreuse'
 The example below creates a subplot with a dark
 slate gray background
 subplot(111, axisbg=(0.1843, 0.3098, 0.3098))
 Here is an example that creates a pale turqoise title
 title('Is this the best color?', color='#afeeee')

On 2/12/07, Andrew Straw <str...@as...> wrote:
> So, I sent the patch file to John, who'll hopefully commit it if he
> approves. To paraphrase Robert Kern, "Working code ends all arguments".
> So, since this was the nested way, and the biggest reason against it was
> that it require code change, well, I changed the code, and perhaps the
> arguments are ended?
>
> Because I did change a fair amount of data_path -using code, it'd be
> good to exercise all your favorite font and image finding sections of
> code. The bits I tried worked for me, of course, but no guarantees...
OK, with a sledgehammer and a prayer, I got it in. I got the same
error you did, and then had to physically remove mpl-data and it's
contents from svn and commit, restore everything in the new order and
commit again. It compiled, installed and ran, passing the tests I
threw at it.
I only ran about half of backend driver before I grew impatient, so
others may want to do some additional testing. I copied your note
from CHANGELOG to API_CHANGES.
I suggest flushing your old mpl-data in site-packages/matplotlib as
well as your ~/.matplotlib/ttffont.cache file before testing.
Thanks for settling the argument!
JDH

Looking through colors.py, I noticed that most of the grey cnames use 
the spelling 'gray' (the US standard I think), although 'lightgrey' 
shows up as a valid name, while 'lightgray' does not. After looking 
around the web a bit for what the correct html names are, I found most 
sites display 'gray' and 'grey' as synonymous, for all the different 
intensities (darkslate, light, dim, etc).
So, here's a patch that does the same, allowing ColorConverter to accept 
both spellings for all the intensities.
Also, just thought I'd point out that, only after using MPL for many 
months have I finally noticed that commands like plot() accept 'color' 
as a kwarg, which allows far more than just the basic 8 or so single 
character color names. What a great feature! I only discovered it 
because I had grown annoyed by the lack of an easy way to make stuff 
grey. Perhaps the color kwarg and the fact that it takes html names, hex 
values, and rgb tuples should be mentioned more explicitly in the 
docstrings for some of the more common plotting commands?
Cheers,
Martin

Thanks for tackling this.
On 2/12/07, Andrew Straw <str...@as...> wrote:
> Charlie Moad wrote:
> >> Although my understanding of setup* is minimal, I agree; I think that
> >> keeping some organization in the data will be helpful. It looks like
> >> get_data_path() is not called in many places, so if that is essentially
> >> what has to be fixed, it should not be very difficult. It might be
> >> facilitated by making _get_data_path() accept *args, a set of
> >> subdirectories to be appended.
> >>
> >
> > I think the way to go is what Andrew typed:
> >
> > os.path.join( mpl.get_data_dir(), 'gui', 'blah.glade' )
> >
> OK, I just implemented this nested idea and it appears to work.
>
> I tried to commit it to SVN, but SF's servers were giving me some talk
> about permissions... Sigh.
>
> So, I sent the patch file to John, who'll hopefully commit it if he
> approves. To paraphrase Robert Kern, "Working code ends all arguments".
> So, since this was the nested way, and the biggest reason against it was
> that it require code change, well, I changed the code, and perhaps the
> arguments are ended?
>
> Because I did change a fair amount of data_path -using code, it'd be
> good to exercise all your favorite font and image finding sections of
> code. The bits I tried worked for me, of course, but no guarantees...
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Charlie Moad wrote:
>> Although my understanding of setup* is minimal, I agree; I think that
>> keeping some organization in the data will be helpful. It looks like
>> get_data_path() is not called in many places, so if that is essentially
>> what has to be fixed, it should not be very difficult. It might be
>> facilitated by making _get_data_path() accept *args, a set of
>> subdirectories to be appended.
>> 
>
> I think the way to go is what Andrew typed:
>
> os.path.join( mpl.get_data_dir(), 'gui', 'blah.glade' )
> 
OK, I just implemented this nested idea and it appears to work.
I tried to commit it to SVN, but SF's servers were giving me some talk 
about permissions... Sigh.
So, I sent the patch file to John, who'll hopefully commit it if he 
approves. To paraphrase Robert Kern, "Working code ends all arguments". 
So, since this was the nested way, and the biggest reason against it was 
that it require code change, well, I changed the code, and perhaps the 
arguments are ended?
Because I did change a fair amount of data_path -using code, it'd be 
good to exercise all your favorite font and image finding sections of 
code. The bits I tried worked for me, of course, but no guarantees...

> Although my understanding of setup* is minimal, I agree; I think that
> keeping some organization in the data will be helpful. It looks like
> get_data_path() is not called in many places, so if that is essentially
> what has to be fixed, it should not be very difficult. It might be
> facilitated by making _get_data_path() accept *args, a set of
> subdirectories to be appended.
I think the way to go is what Andrew typed:
os.path.join( mpl.get_data_dir(), 'gui', 'blah.glade' )

Looking in detail at the contents of the mpl-directory, I notice that
A) the gui/ subdirectory off the main MPL source direcotry (the one with 
setup.py) does not exist in SVN
B) the file "lineprops.glade" referenced by 
backends/backend_gtk/DialogLineprops.py
does not exist in SVN
Is it safe to remove references to these things?
-Andrew

Charlie Moad wrote:
>> Well, another option is to maintain a sub-directory structure when
>> creating mpl-data in the source package. The downside is that this will
>> introduce code changes all over the code -- for example, code that
>> previously asked for "os.path.join( mpl.get_data_dir(), 'blah.glade' )"
>> would have to be converted to "os.path.join( mpl.get_data_dir(), 'gui',
>> 'blah.glade' )".
> 
> I think we should maintain a clean tree and make the code changes. I
> bet it would only take one person a diligent hour or two to fix all
> the occurrences as mentioned above. Maybe we could split up the work?
> I would be willing to update the "backends" folder.
Although my understanding of setup* is minimal, I agree; I think that 
keeping some organization in the data will be helpful. It looks like 
get_data_path() is not called in many places, so if that is essentially 
what has to be fixed, it should not be very difficult. It might be 
facilitated by making _get_data_path() accept *args, a set of 
subdirectories to be appended.
Eric

> Well, another option is to maintain a sub-directory structure when
> creating mpl-data in the source package. The downside is that this will
> introduce code changes all over the code -- for example, code that
> previously asked for "os.path.join( mpl.get_data_dir(), 'blah.glade' )"
> would have to be converted to "os.path.join( mpl.get_data_dir(), 'gui',
> 'blah.glade' )".
I think we should maintain a clean tree and make the code changes. I
bet it would only take one person a diligent hour or two to fix all
the occurrences as mentioned above. Maybe we could split up the work?
 I would be willing to update the "backends" folder.
- Charlie

On 2/12/07, John Hunter <jd...@gm...> wrote:
> OK, I see, so the problem was we had to flatten everything and mix all
> these datatypes together? eggs can't handle the existing directory
> structure in the mpl-data? It would clearly be better if it could,
> because dumping all the data files together isn't terribly elegant, so
> I think it would be useful for some egghead to verify this and see if
> there isn't a way to have the best of all worlds. I haven't used eggs
> so can't say anything intelligent, except that I'm happy to defer to
> those who know more about it and let's get it setup that that work
> properly with mpl-data for eggs and and regular old-fashioned mpl
> installs. If this means that we do have to flatten the data directory
> structure, so be it. That's why god gave us 'ls *.EXT '
I think this should work even with distutils alone, without setuptools.
In order to not flatten everything, one solution is to simply create
subfolders in mpl-data.
We could have those folders:
/lib/matplotlib/mpl-data/fonts/afm
/lib/matplotlib/mpl-data/fonts/ttf
/lib/matplotlib/mpl-data/images
-- Nicolas

John Hunter wrote:
> On 2/12/07, Charlie Moad <cw...@gm...> wrote:
>
>> You're changing positions on me now, John! ;)
>
> It's better that way -- that way I can be right both times :-) Or is
> it wrong both times? hmmm...
>
>> I asked about moving everything into the module, but you didn't want
>> to mix the fonts/images/etc, so I made the install merge the data into
>> a folder. I would love to be able to run "setup develop" as well.
>
> OK, I see, so the problem was we had to flatten everything and mix all
> these datatypes together? eggs can't handle the existing directory
> structure in the mpl-data? It would clearly be better if it could,
> because dumping all the data files together isn't terribly elegant, so
> I think it would be useful for some egghead to verify this and see if
> there isn't a way to have the best of all worlds. I haven't used eggs
> so can't say anything intelligent, except that I'm happy to defer to
> those who know more about it and let's get it setup that that work
> properly with mpl-data for eggs and and regular old-fashioned mpl
> installs. If this means that we do have to flatten the data directory
> structure, so be it. That's why god gave us 'ls *.EXT '
Well, another option is to maintain a sub-directory structure when 
creating mpl-data in the source package. The downside is that this will 
introduce code changes all over the code -- for example, code that 
previously asked for "os.path.join( mpl.get_data_dir(), 'blah.glade' )" 
would have to be converted to "os.path.join( mpl.get_data_dir(), 'gui', 
'blah.glade' )".
So, the low energy, low probability-of-breakage approach is indeed to 
pile everything into mpl-data and make judicious use of "ls *.ext". This 
is what we install in site-packages anyway, so it can't be that bad, 
right? :)
-Andrew

On 2/12/07, Andrew Straw <str...@as...> wrote:
> IMO, the way to fix it is to move all the data into
> lib/matplotlib/mpl-data to start with. If we did that, all the shuffling
> that setup.py does would be unnecessary and using setuptools' develop
> mode would work out-of-the-box. I'd be happy to move these files in the
> svn repository if people agree this is a good idea.
Me too, I'm +1 on that. This way, in development mode, we can run
matplotlib just by adding directory "lib" to the PYTHONPATH, even if
using standard distutils without setuptools.
NG

On 2/12/07, Charlie Moad <cw...@gm...> wrote:
> You're changing positions on me now, John! ;)
It's better that way -- that way I can be right both times :-) Or is
it wrong both times? hmmm...
> I asked about moving everything into the module, but you didn't want
> to mix the fonts/images/etc, so I made the install merge the data into
> a folder. I would love to be able to run "setup develop" as well.
OK, I see, so the problem was we had to flatten everything and mix all
these datatypes together? eggs can't handle the existing directory
structure in the mpl-data? It would clearly be better if it could,
because dumping all the data files together isn't terribly elegant, so
I think it would be useful for some egghead to verify this and see if
there isn't a way to have the best of all worlds. I haven't used eggs
so can't say anything intelligent, except that I'm happy to defer to
those who know more about it and let's get it setup that that work
properly with mpl-data for eggs and and regular old-fashioned mpl
installs. If this means that we do have to flatten the data directory
structure, so be it. That's why god gave us 'ls *.EXT '
JDH

On 2/12/07, John Hunter <jd...@gm...> wrote:
> On 2/12/07, Andrew Straw <str...@as...> wrote:
> > IMO, the way to fix it is to move all the data into
> > lib/matplotlib/mpl-data to start with. If we did that, all the shuffling
> > that setup.py does would be unnecessary and using setuptools' develop
> > mode would work out-of-the-box. I'd be happy to move these files in the
> > svn repository if people agree this is a good idea.
>
> I'm +1 on that. For some reason, I thought we had already decided to
> do that when we moved to support setuptool in the first place.
You're changing positions on me now, John! ;)
I asked about moving everything into the module, but you didn't want
to mix the fonts/images/etc, so I made the install merge the data into
a folder. I would love to be able to run "setup develop" as well.
- Charlie

On 2/12/07, Andrew Straw <str...@as...> wrote:
> IMO, the way to fix it is to move all the data into
> lib/matplotlib/mpl-data to start with. If we did that, all the shuffling
> that setup.py does would be unnecessary and using setuptools' develop
> mode would work out-of-the-box. I'd be happy to move these files in the
> svn repository if people agree this is a good idea.
I'm +1 on that. For some reason, I thought we had already decided to
do that when we moved to support setuptool in the first place.
JDH

John Hunter wrote:
> I am inclined to consider ripping out the __init__ stuff into a
> "config" module or something like that. 
+1

Jouni K. Seppänen wrote:
> "Nicolas Grilly" <nic...@ga...> writes:
>
> 
>> When you are working on matplotlib, after a checkout from the SVN
>> repository, which method do you use to compile extensions without
>> re-building and re-installing everything each time?
>> 
>
> I use "python setupegg.py develop", which I think does the same thing
> as build_ext --inplace. I have made a symbolic link for the mpl-data
> subdirectory. (Perhaps some setuptools wizard can tell us how to fix
> setupegg.py so that mpl-data gets installed in-place?)
IMO, the way to fix it is to move all the data into
lib/matplotlib/mpl-data to start with. If we did that, all the shuffling
that setup.py does would be unnecessary and using setuptools' develop
mode would work out-of-the-box. I'd be happy to move these files in the
svn repository if people agree this is a good idea.
-Andrew

"Nicolas Grilly" <nic...@ga...> writes:
> When you are working on matplotlib, after a checkout from the SVN
> repository, which method do you use to compile extensions without
> re-building and re-installing everything each time?
I use "python setupegg.py develop", which I think does the same thing
as build_ext --inplace. I have made a symbolic link for the mpl-data
subdirectory. (Perhaps some setuptools wizard can tell us how to fix
setupegg.py so that mpl-data gets installed in-place?)
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On 2/11/07, Nicolas Grilly <nic...@ga...> wrote:
> When you are working on matplotlib, after a checkout from the SVN
> repository, which method do you use to compile extensions without
> re-building and re-installing everything each time?
I rebuild and reinstall each time. Since only the changed files are
built, this usually goes fairly quickly after a svn update. If you
ware working on extension code, it can get slow if you are building
the numpy, Numeric and numarray extensions each time. You can
manually override the NUMERIX list in setup.py to just build one of
the array extensions while developing, which should cut your compile
times.
JDH

Hello all,
When you are working on matplotlib, after a checkout from the SVN
repository, which method do you use to compile extensions without
re-building and re-installing everything each time?
For now, I use this method:
- I checkout matplotlib in directory c:\projects\matplotlib.
- I add c:\projects\matplotlib\lib to my PYTHONPATH.
- I use the command "python setup.py build_ext --inplace" each time I
modify a C/C++ file.
- Without anything else, I can use matplotlib in my scripts.
The problem:
This method builds smoothly my extensions (.pyd files) alongside my
Python files (.py files). But I have no directory
c:\projects\matplotlib\lib\matplotlib\mpl-data, like in a standard
installation. As a workaround, I've created it manually by copying
files from directory fonts and images.
My question:
Matplotlib's developers, how do you proceed on your own computer?
Thanks a lot for your answers,
Nicolas Grilly