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/