Re: [matplotlib-devel] Bug when embedding Matplotlib 0.91.2 in PyQt 4.4.2
Hi Pierre, On Friday 30 May 2008 5:21:01 pm Pierre Raybaut wrote: > First, I would like to congratulate you for your work on Matplotlib. I > am using Matplotlib widgets in all my current projects, embedded in PyQt > graphical user interfaces. > > As you may know, PyQt 4.4.2 has been released a few days ago. > And I found out a performance bug when embedding a Matplotlib 0.91.2 > canvas in a PyQt 4.4.2 object: the pan/zoom feature is very slow (with > PyQt 4.3.3, and the exact same scripts, pan/zoom is real-time). Would it be possible to post some benchmarks, something a little more concrete, like specifically what calls are taking the most time, and how they compare for the different versions of PyQt? > I am posting this in PyQt mailing-list too, but I guess that you could > have more ideas on that matter (Matplotlib widgets may not be used very > often in PyQt). Please don't do that. Its not fair to the people who volunteer their time on open source projects to try to draw so many people into the problem before the problem is understood. Cheers, Darren - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] future of mpl documentation
I'll be working on converting docstrings to rest this weekend. Should any of this be done on the branch? Or should we just focus on the trunk? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new release?
Sorry for the delay but I am running into windows/gtk problems. I am getting linking errors for "_gdk_draw_rgb_32_image" and two other gdk symbols. I can't seem to find which lib they are in either. I installed "gtk-dev-2.12.9-win32-2.exe". Do we target a specific version of gtk? I am thinking I might have to fall back to an older version. - Charlie On Fri, May 30, 2008 at 10:06 AM, John Hunter <[EMAIL PROTECTED]> wrote: > On Thu, May 29, 2008 at 11:11 PM, Charlie Moad <[EMAIL PROTECTED]> wrote: >> I went ahead and called it 0.98.0. I am getting a parallels image >> updated so I can do the windows builds, but it is getting late. I >> will get those cranked out tomorrow. The source and mac builds are up >> though. I got two internal compiler errors on the 0.98.0 build, which >> I fixed by replacing -O3 with -Os on those two commands only. I also >> updated the MANIFEST.in file to include agg24 instead of agg23. > > Hey Charlie -- thanks for getting these two releases out. I think we > should probably hide them, though, until the windows binaries are up, > since it will confuse windows users who follow the link to the latest > releases but find no binaries. So if you are more than a few hours > away from putting up the windows installers, let's hide these until > they are ready. > > Thanks, > JDH > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new release?
On Sat, May 31, 2008 at 9:47 AM, Charlie Moad <[EMAIL PROTECTED]> wrote: > Sorry for the delay but I am running into windows/gtk problems. I am > getting linking errors for "_gdk_draw_rgb_32_image" and two other gdk > symbols. I can't seem to find which lib they are in either. I > installed "gtk-dev-2.12.9-win32-2.exe". Do we target a specific > version of gtk? I am thinking I might have to fall back to an older We are not targeting a specific gtk version and I am not sure that we need to be supporting gtk in win32 anymore. I used to distribute a gtk app on win32 that needed mpl (pbrain) but I am not sure anyone is actively using this anymore (it is part of nipy now). We could do a test build w/o gtk and see if anyone complains, or simply revert back to the last gtk version that worked for you. In any case, I don't think you should burn a lot of time on it. If you can get a gtk enabled win32 build, great. If not, just disable gtk support. Our goal is to get rid of as much gui dependent extension code as possible anyhow. I think we've concluded that we can't get rid of the tkagg extension, but for the rest of the GUIs we should be able to use python buffer objects. Perhaps this will provide some impetus to develop a pure pygtk enabled gtkagg. JDH - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new release?
Rolling gtk and pygtk back to 2.10 worked. https://sourceforge.net/project/showfiles.php?group_id=80706 I may be a little rusty on the builds, so please give them a try before the announcement. - Charlie On Sat, May 31, 2008 at 12:31 PM, John Hunter <[EMAIL PROTECTED]> wrote: > On Sat, May 31, 2008 at 9:47 AM, Charlie Moad <[EMAIL PROTECTED]> wrote: >> Sorry for the delay but I am running into windows/gtk problems. I am >> getting linking errors for "_gdk_draw_rgb_32_image" and two other gdk >> symbols. I can't seem to find which lib they are in either. I >> installed "gtk-dev-2.12.9-win32-2.exe". Do we target a specific >> version of gtk? I am thinking I might have to fall back to an older > > We are not targeting a specific gtk version and I am not sure that we > need to be supporting gtk in win32 anymore. I used to distribute a > gtk app on win32 that needed mpl (pbrain) but I am not sure anyone is > actively using this anymore (it is part of nipy now). We could do a > test build w/o gtk and see if anyone complains, or simply revert back > to the last gtk version that worked for you. > > In any case, I don't think you should burn a lot of time on it. If > you can get a gtk enabled win32 build, great. If not, just disable > gtk support. Our goal is to get rid of as much gui dependent > extension code as possible anyhow. I think we've concluded that we > can't get rid of the tkagg extension, but for the rest of the GUIs we > should be able to use python buffer objects. Perhaps this will > provide some impetus to develop a pure pygtk enabled gtkagg. > > JDH > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] future of mpl documentation
On Sat, May 31, 2008 at 9:19 AM, Darren Dale <[EMAIL PROTECTED]> wrote: > I'll be working on converting docstrings to rest this weekend. Should any of > this be done on the branch? Or should we just focus on the trunk? As far as I am concerned, the documentation effort is for the trunk. The only reason to do them on the branch too is to make merges of other code changes easier, which may be a compelling reason. If the docstrings get far out of whack, it may make merging other changes very painful. But at the same time, I don't want the burden of trying to keep the two in sync stopping you from getting the work done that you need to do. Maybe you can try it and see how hard it is, and if proves to be too much of an impediment, just concentrate on the trunk. Michael, any advice here? JDH - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] future of mpl documentation
On Saturday 31 May 2008 12:36:11 pm John Hunter wrote: > On Sat, May 31, 2008 at 9:19 AM, Darren Dale <[EMAIL PROTECTED]> wrote: > > I'll be working on converting docstrings to rest this weekend. Should any > > of this be done on the branch? Or should we just focus on the trunk? > > As far as I am concerned, the documentation effort is for the trunk. I would really prefer to concentrate on the trunk. There's enough work as it is. Darren - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] future of mpl documentation
On Friday 23 May 2008 7:54:27 pm John Hunter wrote:
> On Fri, May 23, 2008 at 6:14 PM, Darren Dale <[EMAIL PROTECTED]>
> wrote
>
> > I have to break here for the weekend, I'll be back monday afternoon.
> > Leave some for me! (although I'll owe doughnut to whoever can fix the
> > arrow docstring).
>
> I'll claim that doughnut.
When was the last time you received one in the mail?
(more at the end...)
> This is a bit complicated. The problem is that we have to do the
> interpolation into the patch doc strings at class definition time (eg
> for Patch and Rectangle), but we can't use the object inspector and
> doc string generator artist.kwdoc to automatically generate them until
> *after* they are defined. So we have a bit of a race condition. The
> solution, which is not terribly elegant, is to define the string for
> the *classes* manually with the setting at the top of
> matplotlib.patches:
>
> artist.kwdocd['Patch'] = """\
> alpha: float
> animated: [True | False]
> antiali
>
> We interpolate this into the class docstrings. Once the classes are
> defined, we can introspect the class and auto generate the strings for
> use in *methods* that operate on class instances. At the bottom of
> patches:
>
> artist.kwdocd['Patch'] = patchdoc = artist.kwdoc(Patch)
>
> artist.kwdocd['Patch'] = patchdoc = artist.kwdoc(Patch)
> for k in ('Rectangle', 'Circle', 'RegularPolygon', 'Polygon',
> 'Wedge', 'Arrow',
> 'FancyArrow', 'YAArrow', 'CirclePolygon', 'Ellipse'):
> artist.kwdocd[k] = patchdoc
>
> so the changes you make in the kwdocd dict will affect the classes in
> matplotlib.patches, bu will not affect the docstrings in the plotting
> functions, eg matplotlib.axes.Axes.arrow, which will use the
> auto-generated version from artist.kwdoc. So you need to make your
> changes in two places: in the kwdocd dict at the top of patches, as
> you did before, *and* in the artist.kwdoc function which
> auto-generates the property tables. If this function returns rest
> tables, you will be in good shape. It is not good design to have to
> make the changes in two places, but when we implemented this we could
> not find a way to do the class doc string interpolation after the
> class was defined, but we still wanted to use the autogenerated docs
> where possible (eg in methods that handle artists like the plotting
> methods) since the auto-generated stuff is more likely to remain
> current.
>
> Maybe an entry in the developer's guide is warranted
Thanks for the detailed explanation. I'm tagging the message so I can remember
to include it in the developers guide. Now that I understand it, it wasn't
too difficult to reformat the output into a ReST table. Onwards!
Darren
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] future of mpl documentation
On Saturday 31 May 2008 4:14:39 pm Darren Dale wrote: > On Saturday 31 May 2008 12:36:11 pm John Hunter wrote: > > On Sat, May 31, 2008 at 9:19 AM, Darren Dale <[EMAIL PROTECTED]> > > wrote: > > > I'll be working on converting docstrings to rest this weekend. Should > > > any of this be done on the branch? Or should we just focus on the > > > trunk? > > > > As far as I am concerned, the documentation effort is for the trunk. > > I would really prefer to concentrate on the trunk. There's enough work as > it is. I made some pretty good progress today. I found the source of that error that was causing sphinx to fail without a helpfull message, there was a * in the contour documentation. pyplot_api is about halfway converted, there are only 60 warnings reported by sphinx for pyplot. I just realized, though, that I should probably be striving to conform with the standard that the numpy and scipy folks put together: http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines and http://svn.scipy.org/svn/numpy/trunk/numpy/doc/example.py . Any comments? I think I have been relying too heavily on tables for the keyword arguments. Darren - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] future of mpl documentation
Hey folks,
I'm super excited about this, so I decided to give it a quick test run
with current trunk SVN. Running ./make.py in the doc/ directory
worked for a while, and then stalled at:
Sphinx v0.3, building latex
trying to load pickled env... done
building [latex]: all documents
updating environment: 0 added, 0 changed, 0 removed
processing Matplotlib.tex... index users/index users/pyplot_tutorial
users/mathtext users/navigation_toolbar users/customizing
users/artists users/event_handling faq/index faq/installing_faq
faq/troubleshooting_faq faq/howto_faq devel/index devel/coding_guide
devel/documenting_mpl devel/add_new_projection api/index
api/artist_api api/pyplot_api
resolving references...
writing... Exception occurred:
File
"/home/fperez/usr/local/lib/python2.5/site-packages/Sphinx-0.3-py2.5.egg/sphinx/latexwriter.py",
line 479, in visit_entry
raise NotImplementedError('Column or row spanning cells are '
NotImplementedError: Column or row spanning cells are not implemented.
The full traceback has been saved in /tmp/sphinx-err-l_Oadi.log, if
you want to report the issue to the author.
Please also report this if it was a user error, so that a better error
message can be provided next time.
Send reports to [EMAIL PROTECTED] Thanks!
This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
%&-line parsing enabled.
entering extended mode
! I can't find file `Matplotlib.tex'.
<*> Matplotlib.tex
Please type another input file name:
I don't know if you are so in the middle of things that you'd rather
not get bug reports on this for a while. If that's the case I'll wait
until the dust settles a bit.
In any case, many thanks for pushing this doc effort forward! The
overall usability of the combined tools, in a few months, is going to
really be massively improved thanks to all this common focus on
sphinx-based docs.
Cheers,
f
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] future of mpl documentation
On Mon, May 26, 2008 at 1:50 PM, Tony Yu <[EMAIL PROTECTED]> wrote: > I played around with the script, but in the process I ended up rewriting it > a bunch. I'm sure I've violated come coding guidelines along the way; my > apologies. And I made several changes -- mainly to simplify the logo. My wife thought it looked busy, and she has better taste than I do, so I stripped it down a bunch and added the many small subplots as a sidebar on the right. Let me know what you think and don't be shy about being critical despite Darren's kind sensitivities. I don't take pride in my graphic design abilities and so will happily make changes See http://matplotlib.sf.net for the new logo(s) and the attached for the stripped down script. JDH <>- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] future of mpl documentation
On Sat, May 31, 2008 at 3:19 PM, Darren Dale <[EMAIL PROTECTED]> wrote: Darren> I have to break here for the weekend, I'll be back monday afternoon. Darren> Leave some for me! (although I'll owe doughnut to whoever can fix the Darren> arrow docstring). John> I'll claim that doughnut. Darren> When was the last time you received one in the mail? Well, I remember the last time quite clearly, when Perry sent me a doughnut in the mail from Maryland to settle a "dollars-to doughnuts" bet. Unfortunately, I can't remember the subject of the bet right now (Perry?), though I kept the doughnut in my freezer, in the addressed envelope, for many months as a souvenir. JDH - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] future of mpl documentation
On Sat, May 31, 2008 at 9:01 PM, Fernando Perez <[EMAIL PROTECTED]> wrote:
> I don't know if you are so in the middle of things that you'd rather
> not get bug reports on this for a while. If that's the case I'll wait
> until the dust settles a bit.
Well, we definitely want our docs to build so we're happy to get the
feedback -- sometimes it's a simple matter of a dev forgetting to
commit a critical file. I am getting this error too. It appears to
be a bug in the pyplot docstrings -- Darren, perhaps you haven't
committed all you recent changes? But if I remove entirely the pyplot
api doc which is causing this problem, I get lots of other errors
along the lines of those shown below. Is this a latex or sphinxext
config error?
[8 <./pyplot_formatstr.png> <./pyplot_three.png>] [9] [10]
[11 <./pyplot_two_s
ubplots.png>]
[12 <./pyplot_text.png>] [13]
[14]
Chapter 2.
[15] [16]
! Undefined control sequence.
\mathbb
l.954 \end{tabulary}
?
! Undefined control sequence.
\mathcircled
l.954 \end{tabulary}
...and lots more like this
JDH
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] future of mpl documentation
On Sat, May 31, 2008 at 7:50 PM, Darren Dale <[EMAIL PROTECTED]> wrote: > I just realized, though, that I should probably be striving to conform with > the standard that the numpy and scipy folks put together: > http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines and > http://svn.scipy.org/svn/numpy/trunk/numpy/doc/example.py . Any comments? I > think I have been relying too heavily on tables for the keyword arguments. I think that following their guidelines is a good idea for the most part, but we needn't adhere to them religiously. For one thing, matplotlib uses *a lot* more keyword args than either numpy or scipy, and what works for them for kwargs may not be best for us. In particular, if we use the format they suggest, I'm afraid our docstrings will simply take up too much space. For example, see http://mentat.za.net/numpy/refguide/functions.xhtml#all-a-axis-none-out-none . What if we formatted all the Line2d kwargs that way? It seems a bit bloated in terms of vertical space for the number of kwargs we need to handle, and so a ReST table may in fact be better. We want our documentation to be mostly consistent to aid the folks trying to put together bits and pieces of documentation from several projects to write in-house docs (which incorporate local docs) or books, but I'm not sure we need our doc formatting to be entirely consistent at the API level. JDH - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] future of mpl documentation
On Saturday 31 May 2008 10:19:47 pm John Hunter wrote: > On Sat, May 31, 2008 at 9:01 PM, Fernando Perez <[EMAIL PROTECTED]> wrote: > > I don't know if you are so in the middle of things that you'd rather > > not get bug reports on this for a while. If that's the case I'll wait > > until the dust settles a bit. > > Well, we definitely want our docs to build so we're happy to get the > feedback -- sometimes it's a simple matter of a dev forgetting to > commit a critical file. I am getting this error too. It appears to > be a bug in the pyplot docstrings -- Darren, perhaps you haven't > committed all you recent changes? All my changes had already been committed. I had only been creating html (./make.py html) and it looks like some of the tables I have been creating dont agree with latex. I'll fix it tomorrow, but in the meantime, please just make html. > But if I remove entirely the pyplot > api doc which is causing this problem, I get lots of other errors > along the lines of those shown below. Is this a latex or sphinxext > config error? Not sure, I'll look into it on Sunday as well. Cheers, Darren - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] future of mpl documentation
On May 31, 2008, at 10:30 PM, John Hunter wrote: > > And I made several changes -- mainly to simplify the logo. My wife > thought it looked busy, and she has better taste than I do, so I > stripped it down a bunch and added the many small subplots as a > sidebar on the right. I agree, the stripped down logo looks much better. > Let me know what you think and don't be shy > about being critical despite Darren's kind sensitivities. I don't > take pride in my graphic design abilities and so will happily make > changes > > See http://matplotlib.sf.net for the new logo(s) and the attached for > the stripped down script. I like the new color scheme on the website. Since you asked for criticism, though, I'm not a fan of the blue "matplotlib" in the logo (on the website, the attached logo is actually different). I think black or a dark gray looks better (color=[0.2, 0.2, 0.2]). Or, if you prefer blue, something less like the default hyperlink color (e.g. color=[.1,.1,.5]). My 2 cents. BTW, I noticed that website is a little old (pure HTML, no CSS). If you're ever interested in redesigning the website (nothing fancy, mainly just moving to CSS), I'd be happy to help out. -Tony > JDH > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] future of mpl documentation
On Sat, May 31, 2008 at 11:27 PM, Tony Yu <[EMAIL PROTECTED]> wrote: > I like the new color scheme on the website. Since you asked for criticism, > though, I'm not a fan of the blue "matplotlib" in the logo (on the website, > the attached logo is actually different). I think black or a dark gray looks > better (color=[0.2, 0.2, 0.2]). Or, if you prefer blue, something less like > the default hyperlink color (e.g. color=[.1,.1,.5]). My 2 cents. I agree -- I had already reverted to black (hit refresh). But if you think some other shade of dark gray or blue/gray is better let me know. > BTW, I noticed that website is a little old (pure HTML, no CSS). If you're > ever interested in redesigning the website (nothing fancy, mainly just > moving to CSS), I'd be happy to help out. We're definitely interested. Try checking out the htdocs svn repository. Admittedly we do things in our own special way (eg the YAPTU template engine), but if we could improve the look-and-feel that would be great. None of us have any special powers in the website-design department. Even better, as part of our new trunk documentation effort, we have moved to a sphinx based documentation system (in the doc subdir of svn trunk). If you could figure out a way to hook custom CSSandr mpl figures/screenshots or any other snazzy features into the base sphinx build system, that would be a big help since we hope to jettison the somewhat anachronistic website build system n the not-too-distant-future. JDH - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
