matplotlib-devel Mailing List for matplotlib

Hi,
Yes, good point. But for the time being, I have enough space on my web 
page and uses my own CVS server ... it just reduces the "management" 
overhead, since I can control everything easily on my own.
For the plugin idea, I will let it to you guys ... I'm too new to make a 
comment on this ;-)
BR,
Michel
Andrew Straw wrote:
> John Hunter wrote:
> 
>> That said, I would always be happy to include a (mostly) full featured
>> backend for a format a large number of users want. Short of that, I
>> think distributing it through another channel, or making a sandbox in
>> the mpl distribution, 
>> 
> FWIW, Jeff Whitaker 's basemap and my mplsizer (wx-like sizer
> implementation for mpl) live in the "toolkits" directory of the mpl
> svubversion tree. I think that partially-implemented backends could also
> happily live there.
>
> It's also feasible to allow runtime discovery of backends through the
> use of setuptools' plugins (to name one route). I understand completely,
> however, that there may be a resistance to adding a dependency on
> setuptools.
>
>
> 

Hi,
First, my apologies for being pretty rude by storming in the mailing 
list without even introducing myself ;-) and by doing so now, it will 
answer partly your questions on my intentions concerning the Visio 
backend. I'm a researcher in the Nokia Research center (yeah, the mobile 
phone thing) and I'm currently working for a standardization alliance. 
There, I lead the modeling of a quite complex network-like system. One 
very important goal is to have a platform independent simulation engine, 
which means that the library used to visualize the simulation results 
has to be platform independent too. Since many companies are involved, 
it's pretty important to be tool agnostic: in practice it means we try 
to reuse open source software as much as possible. So I searched quite 
some time to find an appropriate library for us and matplotlib was by 
far the best I could find given our requirements. Specially so that I 
have scripted a big part of the simulation engine (written in C++) by 
using python, so perfect match ;-)
Since standardization means also writing specifications, documents, 
reports, etc. and the tools we use are Microsoft based, Visio is the de 
facto tool for all drawings, schema, graphics, etc. put in the 
specification or any other documents. So in fact, Visio can do much more 
than just flowcharts: it's equivalent in Unix world would be something 
like Dia I think. In this standardization context, I need to have a 
fully featured backend and in a very short time even: I can't afford to 
wait 6 months to have it done. 
I completely understand your point about having a high threshold when 
talking of bringing in yet another backend ;-): it's a good and healthy 
attitude to keep the quality of the package high. And indeed, the visio 
backend supports aligned rotated text (even if I still have a small bug 
to correct). But I have to admit that I didn't think about the mathtext 
so far, I have to look if it's possible at all to support it and how it 
could be done. For the support of images, it doesn't support it yet, but 
it shouldn't be a problem. I don't know what you mean by "collections" 
... sorry. I'm pretty new to matplotlib and don't know all the goodies yet.
My idea to judge the "maturity" of the backend is pretty simple: I will 
take all the examples you have made for matplotlib and see how many the 
backend can correctly draw in Visio. Based on this, decision can be made 
to include it in the "main stream" of matplotlib or leave it as an 
offspring. Both solutions are fine by me. So my conclusion is to say 
that I will continue the development of the Visio backend as an 
offspring. If later people agrees that it adds a value to bring the 
Visio backend in the main distribution of matplotlib, I will be happy to 
do just that.
BR,
Michel
John Hunter wrote:
>>>>>> "HamletG" == HamletG <ha...@ha...> writes:
>>>>>> 
>
> HamletG> Hi, It doesn't seem that there is much interest in a
> HamletG> Visio backend ;-) I saw John saying that the list of
> HamletG> contributors was already huge, etc. so I put up my own
> HamletG> "local" version of matplotlib, so I can continue easily
> HamletG> working on the Visio backend.
>
> HamletG> If you are curious about the progress, you can have a
> HamletG> look at http://www.hamletg.org/wiki/index.php/Matplotlib
>
> Sorry for the silence on this -- I confess I had never heard of Visio
> before your earlier post and did a little looking on the microsoft web
> site. It looked to me more like a flow chart application than a
> graphing tool -- is that correct?
>
> It is not an issue of a list of contributors -- I would love to have a
> huge list -- it is more an issue of a proliferation of backends. We
> have too many, and most are incomplete, so my threshold is getting
> higher for what I would like to see in the main distribution, because
> often what happens is a developer adds just the features they need and
> leave it at that and we have backends that are only partially
> functional and poorly maintained. I prefer to see a few core backends
> that target the most popular GUIs and image formats. Does you backend
> support properly aligned rotated text, mathtext, images, collections
> or images? These are the features most people leave out because they
> are harder to implement. When we want to make any change to the
> backend API we have to port these to all the backends and it is
> usually me or one of a couple of developers to do this since the
> original developer may have moved on.
>
> That said, I would always be happy to include a (mostly) full featured
> backend for a format a large number of users want. Short of that, I
> think distributing it through another channel, or making a sandbox in
> the mpl distribution, with pointers to the source on the website will
> suffice. If you'd like to send a blurb for the website pointing to
> your code I'll include it, or if you think given the above that the
> Visio backend should be in the main distribution I'm happy to hear the
> argument. I don't use Windows so I am not really in tune with that
> side of the development world, and am happy to be educated.
>
> JDH
>
>
>
>
> 

John Hunter wrote:
> That said, I would always be happy to include a (mostly) full featured
> backend for a format a large number of users want. Short of that, I
> think distributing it through another channel, or making a sandbox in
> the mpl distribution, 
FWIW, Jeff Whitaker 's basemap and my mplsizer (wx-like sizer
implementation for mpl) live in the "toolkits" directory of the mpl
svubversion tree. I think that partially-implemented backends could also
happily live there.
It's also feasible to allow runtime discovery of backends through the
use of setuptools' plugins (to name one route). I understand completely,
however, that there may be a resistance to adding a dependency on
setuptools.

>>>>> "HamletG" == HamletG <ha...@ha...> writes:
 HamletG> Hi, It doesn't seem that there is much interest in a
 HamletG> Visio backend ;-) I saw John saying that the list of
 HamletG> contributors was already huge, etc. so I put up my own
 HamletG> "local" version of matplotlib, so I can continue easily
 HamletG> working on the Visio backend.
 HamletG> If you are curious about the progress, you can have a
 HamletG> look at http://www.hamletg.org/wiki/index.php/Matplotlib
Sorry for the silence on this -- I confess I had never heard of Visio
before your earlier post and did a little looking on the microsoft web
site. It looked to me more like a flow chart application than a
graphing tool -- is that correct?
It is not an issue of a list of contributors -- I would love to have a
huge list -- it is more an issue of a proliferation of backends. We
have too many, and most are incomplete, so my threshold is getting
higher for what I would like to see in the main distribution, because
often what happens is a developer adds just the features they need and
leave it at that and we have backends that are only partially
functional and poorly maintained. I prefer to see a few core backends
that target the most popular GUIs and image formats. Does you backend
support properly aligned rotated text, mathtext, images, collections
or images? These are the features most people leave out because they
are harder to implement. When we want to make any change to the
backend API we have to port these to all the backends and it is
usually me or one of a couple of developers to do this since the
original developer may have moved on.
That said, I would always be happy to include a (mostly) full featured
backend for a format a large number of users want. Short of that, I
think distributing it through another channel, or making a sandbox in
the mpl distribution, with pointers to the source on the website will
suffice. If you'd like to send a blurb for the website pointing to
your code I'll include it, or if you think given the above that the
Visio backend should be in the main distribution I'm happy to hear the
argument. I don't use Windows so I am not really in tune with that
side of the development world, and am happy to be educated.
JDH

Hi,
It doesn't seem that there is much interest in a Visio backend ;-) I saw
John saying that the list of contributors was already huge, etc. so I
put up my own "local" version of matplotlib, so I can continue easily
working on the Visio backend.
If you are curious about the progress, you can have a look at
http://www.hamletg.org/wiki/index.php/Matplotlib
BR,
Michel

>>>>> "John" == John Hunter <jdh...@ac...> writes:
 John> If your patch doesn't make it in within 48 hours please post
 John> here with a complaint.
OK, I committed it. In addition to the files you modified, you should
consider CHANGELOG and API_CHANGES. The former for non-trivial
commits, the latter for API_CHANGES. With this commit, I made an
entry to CHANGELOG. 
Many thanks,
JDH

>>>>> "Tim" == Tim Leslie <tim...@gm...> writes:
 Tim> John, I was wondering if I have svn write access. I seem to
 Tim> recall I had it a year or two ago, but I can't find any
 Tim> evidence to back this up, so maybe I'm mistaken. Could you
 Tim> check for me?
I don't see you on the devel list. A few months ago I purged everyone
who had not made a commit in a year or so and maybe you were removed
then (and posted here to this effect). In general, I don't mind
adding people and certainly welcome the relief of not having to manage
patches, but the devel list had grown to long. Why don't we manage
this submission through the existing devels, and if the patches become
fast and furious, I'm more than happy to (re)add you.
If your patch doesn't make it in within 48 hours please post here with
a complaint.
JKDH

On 12/20/06, John Hunter <jdh...@ac...> wrote:
> >>>>> "Tim" == Tim Leslie <tim...@gm...> writes:
> Tim> colormaps. My question is, how should the output of
> Tim> boilerplate.py be included into pylab.py? Should I just cut
> Tim> and paste the output, or is there some automagic tool for
> Tim> doing it?
>
> Yep, just cut the stuff below
>
> ### Do not edit below this point
>
> and paste in the boilerplate output.
Thanks, that all seems to have worked fine. I've attached the patch
with this email.
John, I was wondering if I have svn write access. I seem to recall I
had it a year or two ago, but I can't find any evidence to back this
up, so maybe I'm mistaken. Could you check for me?
Cheers,
Tim
>
> JDH
>

>>>>> "Tim" == Tim Leslie <tim...@gm...> writes:
 Tim> When running examples/dynamic_demo I get a segfault with the
 Tim> following backtrace. Does anyone have any thoughts on what
 Tim> might be causing this? I'm using python 2.4 .4c1 and the
 Tim> latest svn version of mpl/numpy/scipy.
Look at the first few lines of dynamic_demo.py
#!/usr/bin/env python
import pygtk
pygtk.require('2.0')
import gtk
It is using gtk explicitly. Your output indicates you are using ewx
 Tim> wxEventLoop::Run () from /usr/lib/libwx_gtk2u_core-2.6.so.0
 Tim> #12 0x00002b042968411b in wxAppBase::MainLoop () from
 Tim> /usr/lib/libwx_gtk2u_core-2.6.so.0 #13 0x00002b0428c88487 in
 Tim> wxPyApp::MainLoop () from
 Tim> /usr/lib/python2.4/site-packages/wx-2.6-gtk2-unicode/wx/_core_.so
 Tim> #14 0x00002b0428ce928f in wxPyFileSystemHandler::FindFirst ()
Maybe you are mixing backends and GUI mainloops. Make sure your
backend and GUI agree -- eg examples/dynamic_demo_wx.py
JDH

>>>>> "Tim" == Tim Leslie <tim...@gm...> writes:
 Tim> colormaps. My question is, how should the output of
 Tim> boilerplate.py be included into pylab.py? Should I just cut
 Tim> and paste the output, or is there some automagic tool for
 Tim> doing it?
Yep, just cut the stuff below
### Do not edit below this point
and paste in the boilerplate output.
JDH

When running examples/dynamic_demo I get a segfault with the following
backtrace. Does anyone have any thoughts on what might be causing
this? I'm using python 2.4 .4c1 and the latest svn version of
mpl/numpy/scipy.
Cheers,
Tim
#0 0x00000000004be54f in PyFrame_New ()
#1 0x0000000000476004 in PyEval_EvalCodeEx ()
#2 0x00000000004bf233 in PyClassMethod_New ()
#3 0x0000000000413bf0 in PyObject_Call ()
#4 0x000000000046faf1 in PyEval_CallObjectWithKeywords ()
#5 0x00002b041ffb412f in init_gobject () from
/var/lib/python-support/python2.4/gtk-2.0/gobject/_gobject.so
#6 0x00002b042035218b in g_source_get_current_time () from
/usr/lib/libglib-2.0.so.0
#7 0x00002b0420351c84 in g_main_context_dispatch () from
/usr/lib/libglib-2.0.so.0
#8 0x00002b0420354acd in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#9 0x00002b0420354dda in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#10 0x00002b0420a645f3 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#11 0x00002b04295fb601 in wxEventLoop::Run () from
/usr/lib/libwx_gtk2u_core-2.6.so.0
#12 0x00002b042968411b in wxAppBase::MainLoop () from
/usr/lib/libwx_gtk2u_core-2.6.so.0
#13 0x00002b0428c88487 in wxPyApp::MainLoop () from
/usr/lib/python2.4/site-packages/wx-2.6-gtk2-unicode/wx/_core_.so
#14 0x00002b0428ce928f in wxPyFileSystemHandler::FindFirst ()
 from /usr/lib/python2.4/site-packages/wx-2.6-gtk2-unicode/wx/_core_.so
#15 0x0000000000413bf0 in PyObject_Call ()
#16 0x0000000000473fd0 in PyEval_EvalFrame ()
#17 0x00000000004767d6 in PyEval_EvalCodeEx ()
#18 0x00000000004bf233 in PyClassMethod_New ()
#19 0x0000000000413bf0 in PyObject_Call ()
#20 0x0000000000419930 in PyClass_IsSubclass ()
#21 0x0000000000413bf0 in PyObject_Call ()
#22 0x0000000000472619 in PyEval_EvalFrame ()
#23 0x0000000000475546 in PyEval_EvalFrame ()
#24 0x00000000004767d6 in PyEval_EvalCodeEx ()
#25 0x0000000000474a5a in PyEval_EvalFrame ()
#26 0x00000000004767d6 in PyEval_EvalCodeEx ()
#27 0x0000000000476882 in PyEval_EvalCode ()
#28 0x000000000049b1e2 in PyRun_FileExFlags ()
#29 0x000000000049b3e0 in PyRun_SimpleFileExFlags ()
#30 0x0000000000410b9a in Py_Main ()
#31 0x00002b041fd400c4 in __libc_start_main () from /lib/libc.so.6
#32 0x0000000000410079 in _start ()

Hi All,
As part of nipy[1] we have a spectral colormap which we use and would
like to include it upstream as part of matplotlib. I'm working on a
patch but before I submit it, I need some advice on how boilerplate.py
should be used. I've made the required additions to _cm.py, pylab.py
and boilerplate.py and when I run boilerplate.py it generates a
spectral() function as it does for all the other colormaps. My
question is, how should the output of boilerplate.py be included into
pylab.py? Should I just cut and paste the output, or is there some
automagic tool for doing it?
Cheers,
Tim Leslie
[1] http://neuroimaging.scipy.org/

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> John, What is your present thinking with respect to
 Eric> timetable and strategy for dropping Numeric and numarray
 Eric> support?
Sorry for the delay getting back -- I've been on vacation for a few
days and just returned.
I'm more or less ready to do it, pending Perry's comments. I'd like
to make sure his group is ready vis-a-vis Travis' comment, that as
long as they have numpy installed and the array interface they can use
mpl transparently with numarray.
When we are ready to do this, we have to coordinate the release with
the site-documentation, so we have a news flash and upgrade all the
numerix docs, tutorial, etc... We should also do one or two releases
with a numerix deprecation warning.
JDH

Hi folks-
I'd like to report a possible way for OS X mpl users to use Apple's freetype2
(in their X11), to see if there are any problems with it I may need to be
aware of, and if not, to offer it as a possible solution to others installing
mpl from source on OS X.
The basic issue is that Apple's X11 installs a version of freetype2 under
/usr/X11R6/ which might be usable by mpl, and which can conflict with other
copies users might install to build mpl.
With Panther (10.3), I followed mpl build instructions and installed
freetype2. I tried two different methods: using i-Installer, and directly
from source (into /usr/local/). Both approaches worked fine with mpl.
However, using either version led to problems with other X11 software I tried
to install. The issues I remember had to do with GTK (i.e., installing PyGTK
and an unrelated GTK app, geda, from source). There were troublesome issues
having to do with freetype2 and some other X11 libs. According to some
anecdotal reports I found online, it appears Apple did something strange to
the freetype version (at least in Panther versions of X11), so gcc/ld would
link against it even if a more recent version was in /usr/local/, but then
there would be freetype issues at runtime. My eventual solution involved
removing various parts of Apple's X11, and putting links in /usr/X11R6/ to the
new installs in /usr/local/. (I have a script to do this, if anyone needs
it.)
This was such a headache that when I just upgraded to Tiger (10.4; a clean
install), I thought I'd see if mpl could be installed using the freetype2 in
Apple's X11. (I also did not install zlib, since 10.4 includes it in
/usr/lib/.) To do so, I had to modify "add_ft2font_flags" in setupext.py,
adding this to the top:
 # Added to provide access to Apple's freetype2 when their X11 is installed
 if sys.platform=='darwin':
 # Add paths to Apple's X11R6.
 module.library_dirs.extend(
 ['/usr/X11R6/lib'])
 module.include_dirs.extend(
 ['/usr/X11R6/include'])
(Also, the docstring is incorrect and should be fixed to refer to freetype2
rather than gd.) With this change, mpl built without any errors, and as far
as I can tell so far, is working just fine. I've come across a few missing
font/font replacement warnings, but I don't know whether installing a new
freetype2 would have avoided these.
If anyone can see a problem with this procedure, please let me know.
Otherwise, it means that Tiger users who have installed Apple's X11 need to
install just one library (libpng) before installing mpl, so long as the above
change is made to setupext.py. I don't know if the change would have any
ramifications for those who don't install X11 or who do install it and *also*
install freetype2 in /usr/local/. If no problems are anticipated, perhaps
the change can be incorporated into mpl.
Thanks for any feedback on this.
-Tom
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

Hi all,
Based on the GTK console bundled with The Gimp I developed some
time ago a kind of pylab console that display figures inline.
I cleanified the code which is now available at:
http://www.loria.fr/~rougier/pub/Software/pylab
A screenshot is available at:
http://www.loria.fr/~rougier/pub/Screenshots/pylab-screenshot.png
Any comments/requests are welcome.
Nicolas Rougier.

Eric Firing wrote:
> What is your present thinking with respect to timetable and strategy for 
> dropping Numeric and numarray support?
+1 for dropping them in future versions.
As John so eloquently pointed out recently, MPL is faced with a great 
challenge in supporting so many python versions, backends, etc. This in 
one place we can simplify.
In theory, MPL can use numpy internally, and still get data passed to it 
from Numeric and numarray with the array protocol, so you wouldn't be 
completely abandoning users stuck with the older packages.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Eric Firing wrote:
> John,
>
> What is your present thinking with respect to timetable and strategy for 
> dropping Numeric and numarray support?
> 
With respect to this question it should be remembered that the array 
interface will still allow those using numarray/Numeric to use 
matplotlib. It's just that they will have to also install NumPy.
At the NIPS conference last week, the author of CVXOPT was there and it 
was interesting to see that he had no problems using matplotlib for the 
array object they came up with for CVXOPT because of the array interface.
So, it seem to me that encouraging people to download NumPy in order to 
use matplotlib is actually a good thing even if they don't convert all 
their legacy code immediately.
I suppose the only group left out will be those who refuse to update 
their Numeric installation to use Numeric > 23.8
-Travis

John,
What is your present thinking with respect to timetable and strategy for 
dropping Numeric and numarray support?
Thanks.
Eric

Hi,
Can we customize legends block on a pie chart? Currently there is a box which has my for 4 lables with colors each one row. I don't wants left and right borders and some other formatting? OR Can we put legends out of box like in the bottom horizontly 3 in a row? Please help !
thanks n regards
-Aalok
 				
---------------------------------
 Find out what India is talking about on - Yahoo! Answers India 
 Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW

>>>>> "Aalok" == Aalok kapoor <aal...@ya...> writes:
 Aalok> Hi, How can we plot pie charts with the round circle of pie
 Aalok> with the same color as of pie piece, e.g if pie piece color
 Aalok> is red the egge of the same pie piece should be red.
 Aalok> Please help!
How about something like
slices, texts = pie(...)
for slice in slices:
 slice.set_edgecolor(slice.get_facecolor())
JDH

Hi,
How can we plot pie charts with the round circle of pie with the same color as of pie piece, e.g if pie piece color is red the egge of the same pie piece should be red.
Please help!
thanks n regards,
-Aalok
 				
---------------------------------
 Find out what India is talking about on - Yahoo! Answers India 
 Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW

Hi guys,
I'm currently doing a Visio backend and I was wondering if there would 
be interest to add it to the "official" Matplotlib distribution. I plan 
to 2 two versions:
1. Using Visio COM Automation, so you need to have Visio installed. It's 
already in pretty good shape
2. Creating directly an XML file following the Visio schema. I haven't 
started it yet.
If interest, let me know.
BR,
HamletG

David,
I went ahead and added the linewidth kwarg to bar and barh in svn, and 
did a little bit of other cleaning up at the same time.
Eric
David Huard wrote:
> Thanks a lot for the quick answer,
> 
> I think it would be cleaner to add the linewidth argument, since most 
> users expect the default to be a black boundary.

On Fri, Dec 08, 2006 at 01:54:56PM -0600, Glen W. Mabey wrote:
> On Fri, Dec 08, 2006 at 01:44:03PM -0600, John Hunter wrote:
> > >>>>> "Glen" == Glen W Mabey <Gle...@sw...> writes:
> > 
> > Glen> Hello, I've just switched to Python 2.5 and at the same time
> > Glen> upgraded to numpy 1.0.1 with today's svn matplotlib, using
> > Glen> the QtAgg backend (PyQt3 3.17). This is on an AMD64
> > Glen> (Opteron) machine.
> > 
> > Glen> I get a segfault after these operations:
> > 
> > Glen> In [1]:import numpy as N In [2]:specgram( N.random.randn(
> > Glen> 256*500 ) ) Segmentation fault (core dumped)
> > 
> > 1) Are you sure that matplotlib's numerix setting is numpy?
> 
> Yep. It has been for a long time.
> 
> > 2) Did you do a *clean* build of mpl: ie 
> > > sudo rm -rf build
> > > sudo python setup.py install
> 
> I'm pretty sure it was clean, because I upgraded to the svn version at
> the same time. I'm rebuilding it now, though, just to make sure, and
> I'll post if there is any difference in result.
Okay, it's just my fault. Turns out there is only a segfault when I
include a patch I'm working on ...
Thanks again,
Glen

On Fri, Dec 08, 2006 at 01:44:03PM -0600, John Hunter wrote:
> >>>>> "Glen" == Glen W Mabey <Gle...@sw...> writes:
> 
> Glen> Hello, I've just switched to Python 2.5 and at the same time
> Glen> upgraded to numpy 1.0.1 with today's svn matplotlib, using
> Glen> the QtAgg backend (PyQt3 3.17). This is on an AMD64
> Glen> (Opteron) machine.
> 
> Glen> I get a segfault after these operations:
> 
> Glen> In [1]:import numpy as N In [2]:specgram( N.random.randn(
> Glen> 256*500 ) ) Segmentation fault (core dumped)
> 
> 1) Are you sure that matplotlib's numerix setting is numpy?
Yep. It has been for a long time.
> 2) Did you do a *clean* build of mpl: ie 
> > sudo rm -rf build
> > sudo python setup.py install
I'm pretty sure it was clean, because I upgraded to the svn version at
the same time. I'm rebuilding it now, though, just to make sure, and
I'll post if there is any difference in result.
Thanks for your suggestions.
Glen