matplotlib-devel Mailing List for matplotlib (Page 2)

On Wed, Dec 17, 2008 at 3:22 PM, Sandro Tosi <mo...@de...> wrote:
> On Wed, Dec 17, 2008 at 22:16, Michael Droettboom <md...@st...> wrote:
>> Ok. Based on your success report, I'll go ahead and merge this to trunk.
>>
>> Sandro: please let me know if these changes break anything in your package
>> build scripts.
>
> I'll do as soon as we will have sphinx 0.5.1 packages (we're working
> on it just now).
>
> Let me thank you again for your prompt responsiveness.
Sandro -- do you distribute something like a matplotlib-devel, so that
people who want to compile mpl, and build the docs, could do so
themselves with a simple
 > apt-get install python-matplotlib-devel
 > cd ~/path/to/mpl/docs
 > python make.py html latex
That would be nice, because it would make it easier for users and
developers to contribute to the docs and test their changes. Right
now there is something of a barrier to entry for people who want to
contribute to the docs.
JDH

On Wed, Dec 17, 2008 at 22:16, Michael Droettboom <md...@st...> wrote:
> Ok. Based on your success report, I'll go ahead and merge this to trunk.
>
> Sandro: please let me know if these changes break anything in your package
> build scripts.
I'll do as soon as we will have sphinx 0.5.1 packages (we're working
on it just now).
Let me thank you again for your prompt responsiveness.
Cheers,
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Ok. Based on your success report, I'll go ahead and merge this to trunk.
Sandro: please let me know if these changes break anything in your 
package build scripts.
Mike
John Hunter wrote:
> On Wed, Dec 17, 2008 at 10:52 AM, Michael Droettboom <md...@st...> wrote:
>
> 
>> SUMMARY: Since so much has changed in the doc build, I need help testing
>> it in other environments -- particularly because LaTeX docs have never
>> built on my machine. I've done this on the branch, so the Debian guys
>> can run with it, but it's a little risky, due to the depth of cuts I had
>> to make. I've tested successfully with Sphinx 0.5.1 and docutils 0.5.
>> Please clean your checkout and then build for yourself and let me know
>> if you see anything funny.
>>
>> DETAILS:
>>
>> You can now do
>>
>> python make.py --small html
>>
>> which will only generate low-res PNGs for the html build. "--small" has
>> no effect for pdf build.
>> 
>
> Very nice -- it seems like you've solved some of the unneeded rebuild
> problems we had been having too, because successive calls to make html
> seem to go much faster now.
>
> 
>> gen_gallery now runs in a sphinx callback (env-updated) after all the
>> input files have been parsed, (and all the plots have been generated),
>> but right before the html or latex is written out. This eliminates the
>> need to run the build multiple times, and the need to have an
>> autogenerated file (doc/_templates/gallery.html) in SVN. The thumbnail
>> downsampling is now done as part of this step, rather than as part of
>> plot_directive, since it isn't needed for LaTeX builds.
>> 
>
> I have built the pdf on a linux environment and the html on a linux
> and os x environment, so it is looking good. I've built with and w/o
> the --small
>
> 
>> Lastly, since files are in many different places, the Sourceforge site
>> should probably be cleaned (if it isn't automatically already) to ensure
>> we don't go over quota.
>> 
>
> Will do -- some time ago I emailed the sf support people and asked for
> a quota increase, and they replied that there wasn't really a quota
> anymore, but I will clean it so we minimize our footprint. And it
> they ever do get anxious about the size we consume, we can always go
> --small :-)
>
> Thanks again, sorry that was such a bear. Hopefully the plot
> directive emerges stronger from the carnage.
>
> JDH
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Jeff Whitaker wrote:
> Ryan May wrote:
>> On a related note, is there any reason that Basemap/pyshapelib 
>> couldn't use a system copy of shapelib? Right now, Gentoo's patching 
>> the setup.py to do this. I was curious if we could move that upstream.
> I know it's silly at some level to have multiple copies, but if basemap 
> installs it's own (which doesn't conflict with the system copy) at least 
> I'm sure it's going to work. For me, it means I have to spend less time 
> helping folks figure out why they can't open shapefiles. It's a quite a 
> bit harder to check if a C library works from within python code than it 
> is a python package.
> 
> Bottom line - it could be done, but I don't think it's worth it. 
> Shapelib is tiny anyway.
Fine by me. I just thought I'd see what could be done. It sounds like it'd be a 
maintainance pain for you. So long as you don't go messing with setup.py's 
handling of shapelib too often, Gentoo should be fine as it already has a patch. :)
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Ryan May wrote:
> Jeff Whitaker wrote:
>> Ryan May wrote:
>>> Jeff,
>>>
>>> Would it be a lot of work for basemap to use the system copy of 
>>> pupynere if it's installed, instead of installing its own copy? 
>>> (like what's already done for dap and httplib2)
>>>
>>> Ryan
>>>
>>> 
>>
>> Ryan: The basemap version is modified to automatically unpack scaled 
>> short integers into floats using the add_offset and scale_factor 
>> variable attributes. It also automatically turns data with missing 
>> values into masked arrays.
>> Is having two versions causing you any problems?
>> "import pupynere" should give you the system copy. You'd have to 
>> "from mpl_toolkits.basemap import pupynere" to get the Basemap version.
>
> Good to know. It's not that it's a big deal for me (it's one python 
> file after all), I just noticed that Gentoo's ebuild is blowing it 
> away and just requiring/installing mainline pupynere. From a purist 
> standpoint, I don't like having multiple copies of the same code 
> hanging around, but I'm not about to lose sleep over it. It might 
> make your job easier if you could convince Roberto to take those 
> changes upstream. :) 
Ryan: That's a good idea - I will contact Roberto.
> It sounds to me, however, that I need to file a Gentoo bug.
>
> I will say that pupynere seems to be spreading, but not in a good 
> way. There's the standalone version. Then there's your tweaked 
> version. And there's a (now out-dated) copy in scipy.
>
> On a related note, is there any reason that Basemap/pyshapelib 
> couldn't use a system copy of shapelib? Right now, Gentoo's patching 
> the setup.py to do this. I was curious if we could move that upstream.
I know it's silly at some level to have multiple copies, but if basemap 
installs it's own (which doesn't conflict with the system copy) at least 
I'm sure it's going to work. For me, it means I have to spend less time 
helping folks figure out why they can't open shapefiles. It's a quite a 
bit harder to check if a C library works from within python code than it 
is a python package.
Bottom line - it could be done, but I don't think it's worth it. 
Shapelib is tiny anyway. 
-Jeff
>
> Ryan
>
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Jeff Whitaker wrote:
> Ryan May wrote:
>> Jeff,
>>
>> Would it be a lot of work for basemap to use the system copy of 
>> pupynere if it's installed, instead of installing its own copy? (like 
>> what's already done for dap and httplib2)
>>
>> Ryan
>>
>> 
> 
> Ryan: The basemap version is modified to automatically unpack scaled 
> short integers into floats using the add_offset and scale_factor 
> variable attributes. It also automatically turns data with missing 
> values into masked arrays.
> Is having two versions causing you any problems?
> "import pupynere" should give you the system copy. You'd have to "from 
> mpl_toolkits.basemap import pupynere" to get the Basemap version.
Good to know. It's not that it's a big deal for me (it's one python file after 
all), I just noticed that Gentoo's ebuild is blowing it away and just 
requiring/installing mainline pupynere. From a purist standpoint, I don't like 
having multiple copies of the same code hanging around, but I'm not about to lose 
sleep over it. It might make your job easier if you could convince Roberto to 
take those changes upstream. :) It sounds to me, however, that I need to file a 
Gentoo bug.
I will say that pupynere seems to be spreading, but not in a good way. There's 
the standalone version. Then there's your tweaked version. And there's a (now 
out-dated) copy in scipy.
On a related note, is there any reason that Basemap/pyshapelib couldn't use a 
system copy of shapelib? Right now, Gentoo's patching the setup.py to do this. 
I was curious if we could move that upstream.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Ryan May wrote:
> Jeff,
>
> Would it be a lot of work for basemap to use the system copy of pupynere if it's 
> installed, instead of installing its own copy? (like what's already done for dap 
> and httplib2)
>
> Ryan
>
> 
Ryan: The basemap version is modified to automatically unpack scaled 
short integers into floats using the add_offset and scale_factor 
variable attributes. It also automatically turns data with missing 
values into masked arrays. 
Is having two versions causing you any problems? 
"import pupynere" should give you the system copy. You'd have to "from 
mpl_toolkits.basemap import pupynere" to get the Basemap version.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Jeff,
Would it be a lot of work for basemap to use the system copy of pupynere if it's 
installed, instead of installing its own copy? (like what's already done for dap 
and httplib2)
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Wed, Dec 17, 2008 at 10:52 AM, Michael Droettboom <md...@st...> wrote:
> SUMMARY: Since so much has changed in the doc build, I need help testing
> it in other environments -- particularly because LaTeX docs have never
> built on my machine. I've done this on the branch, so the Debian guys
> can run with it, but it's a little risky, due to the depth of cuts I had
> to make. I've tested successfully with Sphinx 0.5.1 and docutils 0.5.
> Please clean your checkout and then build for yourself and let me know
> if you see anything funny.
>
> DETAILS:
>
> You can now do
>
> python make.py --small html
>
> which will only generate low-res PNGs for the html build. "--small" has
> no effect for pdf build.
Very nice -- it seems like you've solved some of the unneeded rebuild
problems we had been having too, because successive calls to make html
seem to go much faster now.
> gen_gallery now runs in a sphinx callback (env-updated) after all the
> input files have been parsed, (and all the plots have been generated),
> but right before the html or latex is written out. This eliminates the
> need to run the build multiple times, and the need to have an
> autogenerated file (doc/_templates/gallery.html) in SVN. The thumbnail
> downsampling is now done as part of this step, rather than as part of
> plot_directive, since it isn't needed for LaTeX builds.
I have built the pdf on a linux environment and the html on a linux
and os x environment, so it is looking good. I've built with and w/o
the --small
> Lastly, since files are in many different places, the Sourceforge site
> should probably be cleaned (if it isn't automatically already) to ensure
> we don't go over quota.
Will do -- some time ago I emailed the sf support people and asked for
a quota increase, and they replied that there wasn't really a quota
anymore, but I will clean it so we minimize our footprint. And it
they ever do get anxious about the size we consume, we can always go
--small :-)
Thanks again, sorry that was such a bear. Hopefully the plot
directive emerges stronger from the carnage.
JDH

Hi Michiel,
+1 to Chris Barker's request for information on where Agg makes extra
calls to draw(). The 20% speedup in scatter performance is nice, and
is clearly related to Agg.
Any idea why the pcolormesh example is so much slower in Mac OS X than TkAgg?
Thanks for your continued work on this.
-Eric
On Wed, Dec 17, 2008 at 5:52 AM, John Hunter <jd...@gm...> wrote:
> Hi Michiel,
>
> This looks great -- in particular I am intrigued by the final timing
> results which show your backend 12 times faster than tkagg. I am not
> sure where this speedup is coming from -- do you have some ideas?
> Because you are creating lots-o-subplots in that example, there is a
> lot of overhead at the python layer (many axes, many ticks, etc) so I
> don't see how a faster backend could generate such a significant
> improvement. What kind of timings do you see if you issue a plot
> rather than bar call in that example? One thing about bar in
> particular is that we draw lots of separate rectangles, each with thie
> own gc, and it has been on my wishlist for some time to do this as a
> collection. If you are handling gc creation, etc, in C, that may
> account for a big part of the difference.
>
> Since the new macosx backend was released in 0.98.5, I also need to
> decide whether this patch belongs on the branch, and hence will get
> pushed out as early as today in a bugfix release when some changes JJ
> and Michael are working on are ready, or the trunk, in which case it
> could be months. In favor of the trunk: this is more of a feature
> enhancement than a bugfix, and patches to the branch should be
> bugfixes with an eye to stability of the released code, though a good
> argument could be made that this is a bugfix. In favor of the branch:
> it is brand new code advertised as beta in 0.98.5 and so it is
> unlikely that anyone is using it seriously yet, and since it is beta,
> we should get as much of it out there ASAP so folks can test and pound
> on it. I'm in favor of branch, but I wanted to bring this up here
> since we are fairly new to the branch/trunk release maintenance game
> and want to get some input and provide some color about which patches
> should go where, especially in gray areas like this.
>
> JDH
>
>
> On Tue, Dec 16, 2008 at 6:08 PM, Michiel de Hoon <mjl...@ya...> wrote:
>> Dear all,
>>
>> I have now implemented the draw_path_collection, draw_quad_mesh, and draw_markers methods in the Mac OS X native backend (see patch 2179017 at
>> http://sourceforge.net/tracker/?func=detail&atid=560722&aid=2179017&group_id=80706). Some timings are below. In terms of raw drawing speed, the native backend can be either faster or slower than agg. On the other hand, the native backend can be considerably faster if the agg backend uses many calls to draw(); the native backend can avoid these superfluous because it has complete control over the event loop (see the third example below).
>> # Timings in seconds
>> # n Mac OS X TkAgg
>> # 2 2 6
>> # 3 3 23
>> # 4 5 66
>>
>>
>

Jae-Joon Lee wrote:
> John and others,
> 
> I just committed a small patch that add gid(group id) as a property of
> the Artist.
> And also some small changes here and there, so that the svg backend
> use this gid as the ID of each element. To do this, I slightly changed
> the calling convention of the open_group() methods in Backends class.
> I have mentioned about this some time ago, and these changes are meant
> to be useful for some postprocessing of the svg fie
> 
> http://www.nabble.com/Re%3A-SVG-clickable-images-p20241569.html
> 
> I added two example, which apply gaussian blurring filter (for
> dropshadow) and some lighting effects to the svg files created with
> MPL. I added them under "examples/misc" because the examples are SVG
> specific. Let me know if there is any other suitable place.
> 
> Note that the svg filter is not supported by all the svg renderer.
> Inkscape is the best open source tool that I know of which supports
> svg filter. The lighting filters (used svg_filter_pie.py) work fine
> with inkscape. Gaussian blurring (svg_filter_line.py) is also
> supported by firefox.
Wow. Very nice work, those look great.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

John Hunter wrote:
> Hi Michiel,
> 
> This looks great -- in particular I am intrigued by the final timing
> results which show your backend 12 times faster than tkagg. I am not
> sure where this speedup is coming from -- do you have some ideas?
> Because you are creating lots-o-subplots in that example, there is a
> lot of overhead at the python layer (many axes, many ticks, etc) so I
> don't see how a faster backend could generate such a significant
> improvement. What kind of timings do you see if you issue a plot
> rather than bar call in that example? One thing about bar in
> particular is that we draw lots of separate rectangles, each with thie
> own gc, and it has been on my wishlist for some time to do this as a
> collection. If you are handling gc creation, etc, in C, that may
> account for a big part of the difference.
> 
> Since the new macosx backend was released in 0.98.5, I also need to
> decide whether this patch belongs on the branch, and hence will get
> pushed out as early as today in a bugfix release when some changes JJ
> and Michael are working on are ready, or the trunk, in which case it
> could be months. In favor of the trunk: this is more of a feature
> enhancement than a bugfix, and patches to the branch should be
> bugfixes with an eye to stability of the released code, though a good
> argument could be made that this is a bugfix. In favor of the branch:
> it is brand new code advertised as beta in 0.98.5 and so it is
> unlikely that anyone is using it seriously yet, and since it is beta,
> we should get as much of it out there ASAP so folks can test and pound
> on it. I'm in favor of branch, but I wanted to bring this up here
> since we are fairly new to the branch/trunk release maintenance game
> and want to get some input and provide some color about which patches
> should go where, especially in gray areas like this.
I'm +1 on going ahead and putting this on the branch, for the reasons you mentioned.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

I've been working on Debian's (Sandro Tosi's) request to produce a 
smaller doc tree... If only I had known how much work was involved 
before I started!
SUMMARY: Since so much has changed in the doc build, I need help testing 
it in other environments -- particularly because LaTeX docs have never 
built on my machine. I've done this on the branch, so the Debian guys 
can run with it, but it's a little risky, due to the depth of cuts I had 
to make. I've tested successfully with Sphinx 0.5.1 and docutils 0.5. 
Please clean your checkout and then build for yourself and let me know 
if you see anything funny.
DETAILS:
You can now do
 python make.py --small html
which will only generate low-res PNGs for the html build. "--small" has 
no effect for pdf build.
The payoff here is that the html tree goes from 109MB to 49MB.
There have been some fundamental changes to how files are staged in the 
doc build. Rather than dumping everything in _static and then having 
Sphinx copy them over for us, our various extensions now either a) put 
the files directly into the build tree under build/html/_images or 
build/html/pyplot_directive, or b) stage things in 
build/pyplot_directive, and then copy to the build tree as needed. The 
exception is the _static/examples directory (generated by gen_rst.py), 
since they will require some major work to know where the build 
directory is.
The plot_directive always builds all three versions of every plot (png, 
hires.png, pdf) into build/pyplot_directive. Depending on a user 
setting, only some of these may be copied to the output directory. The 
reason for this is so that switching between html and pdf builds works, 
and we don't get hundreds of false warnings from sphinx about missing 
files. It took a while to arrive and that procedure... ;)
gen_gallery now runs in a sphinx callback (env-updated) after all the 
input files have been parsed, (and all the plots have been generated), 
but right before the html or latex is written out. This eliminates the 
need to run the build multiple times, and the need to have an 
autogenerated file (doc/_templates/gallery.html) in SVN. The thumbnail 
downsampling is now done as part of this step, rather than as part of 
plot_directive, since it isn't needed for LaTeX builds.
Something similar should be done for the examples, I just haven't gotten 
around to it yet.
Lastly, since files are in many different places, the Sourceforge site 
should probably be cleaned (if it isn't automatically already) to ensure 
we don't go over quota.
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Nope - no windows users (yet - but we'll test it first if we ever have to deliver there).
That will work perfectly - Thanks!!!
Ted
> -----Original Message-----
> From: Jeff Whitaker [mailto:js...@fa...]
> Sent: Wednesday, December 17, 2008 5:03 AM
> To: Drain, Theodore R
> Cc: mat...@li...
> Subject: Re: [matplotlib-devel] Basemap question for Jeff: different
> data directory?
>
> Drain, Theodore R wrote:
> > Jeff,
> > Is it possible to install the basemap data into a different
> directory?
> >
> > I'm trying to set up a tool delivery layout for our users that allows
> me to rapidly update packages that tend to change. We have a core set
> of software that our code is built on and it's a lot of work for us to
> update that and test it on every platform. What I'm doing is
> separating out the packages of that core set that we generally need to
> update at a higher rate (currently that's matplotlib and sphinx)
> because they're under more active development.
> >
> > The largest piece (by an order of magnitude) of these active tools is
> the basemap data. What I'd really like to do is install the basemap
> data with the core set of tools and then tell basemap where it's
> located instead of having to redeliver this large chunk of unchanging
> data every time we do a bug fix update to MPL. Perhaps by setting an
> environment variable that takes precedence over the default location?
> >
> > Any thoughts? I could put a patch together for it if you think it's
> worthwhile.
> >
> > Thanks,
> > Ted
> >
> > -
>
> Ted: I've changed Basemap to look for it's data in BASEMAPDATA, and if
> that env var is not set to use the default location (svn revision
> 6646). Will that work for you? Do you also want an option in
> setup.py
> to not install the data?
>
> I'm a bit worried that this won't work in Windows - do you have Windows
> users?
>
> -Jeff
>
> --
> Jeffrey S. Whitaker Phone : (303)497-6313
> NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
> 325 Broadway Boulder, CO, USA 80305-3328

Drain, Theodore R wrote:
> Jeff,
> Is it possible to install the basemap data into a different directory?
>
> I'm trying to set up a tool delivery layout for our users that allows me to rapidly update packages that tend to change. We have a core set of software that our code is built on and it's a lot of work for us to update that and test it on every platform. What I'm doing is separating out the packages of that core set that we generally need to update at a higher rate (currently that's matplotlib and sphinx) because they're under more active development.
>
> The largest piece (by an order of magnitude) of these active tools is the basemap data. What I'd really like to do is install the basemap data with the core set of tools and then tell basemap where it's located instead of having to redeliver this large chunk of unchanging data every time we do a bug fix update to MPL. Perhaps by setting an environment variable that takes precedence over the default location?
>
> Any thoughts? I could put a patch together for it if you think it's worthwhile.
>
> Thanks,
> Ted
>
> -
Ted: I've changed Basemap to look for it's data in BASEMAPDATA, and if 
that env var is not set to use the default location (svn revision 
6646). Will that work for you? Do you also want an option in setup.py 
to not install the data?
I'm a bit worried that this won't work in Windows - do you have Windows 
users?
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

Hi John,
On Wed, Dec 17, 2008 at 12:26, John Hunter <jd...@gm...> wrote:
> On Wed, Dec 17, 2008 at 5:14 AM, Sandro Tosi <mo...@de...> wrote:
>> Hi all,
>> I see pypi feed that mpl 0.98.5.1 is released, but I see no announce
>> on mpl mls: is it the one to use or it's a "temporary" snapshot? I
>> still see no changelog entry about reduced doc size (and I still
>> haven't build the package) so maybe I still hold the upload in debian,
>> but I'd like to hear from you.
>>
>> Additionally, http://matplotlib.sourceforge.net/users/whats_new.html
>> still has 0.98.4 as last changelog entry.
>>
>> Sorry for being so boring lately :) and thanks for your work,
>
> We had some critical bugs to get fixed so we pushed out a bugfix
> release yesterday. I talked with Michael offlist and he is working
> hard on the plot directive size problem, but it was harrier than
> anticipated, so we are simply going to do 98.5.2 when he is done. I
Thanks! I really appreciate your attention and responsiveness to our
"poor" packagers needs :D
> opted not to harass the list with yet another announcement, and did
> not want you and other packagers to waste time on this one, since I
> knew another release was coming down the pipeline when he gets his
> changes in.
That's great! I'll be waiting for it to come.
Cheers,
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Wed, Dec 17, 2008 at 5:14 AM, Sandro Tosi <mo...@de...> wrote:
> Hi all,
> I see pypi feed that mpl 0.98.5.1 is released, but I see no announce
> on mpl mls: is it the one to use or it's a "temporary" snapshot? I
> still see no changelog entry about reduced doc size (and I still
> haven't build the package) so maybe I still hold the upload in debian,
> but I'd like to hear from you.
>
> Additionally, http://matplotlib.sourceforge.net/users/whats_new.html
> still has 0.98.4 as last changelog entry.
>
> Sorry for being so boring lately :) and thanks for your work,
We had some critical bugs to get fixed so we pushed out a bugfix
release yesterday. I talked with Michael offlist and he is working
hard on the plot directive size problem, but it was harrier than
anticipated, so we are simply going to do 98.5.2 when he is done. I
opted not to harass the list with yet another announcement, and did
not want you and other packagers to waste time on this one, since I
knew another release was coming down the pipeline when he gets his
changes in.
JDH

Hi all,
I see pypi feed that mpl 0.98.5.1 is released, but I see no announce
on mpl mls: is it the one to use or it's a "temporary" snapshot? I
still see no changelog entry about reduced doc size (and I still
haven't build the package) so maybe I still hold the upload in debian,
but I'd like to hear from you.
Additionally, http://matplotlib.sourceforge.net/users/whats_new.html
still has 0.98.4 as last changelog entry.
Sorry for being so boring lately :) and thanks for your work,
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Hi Michiel,
This looks great -- in particular I am intrigued by the final timing
results which show your backend 12 times faster than tkagg. I am not
sure where this speedup is coming from -- do you have some ideas?
Because you are creating lots-o-subplots in that example, there is a
lot of overhead at the python layer (many axes, many ticks, etc) so I
don't see how a faster backend could generate such a significant
improvement. What kind of timings do you see if you issue a plot
rather than bar call in that example? One thing about bar in
particular is that we draw lots of separate rectangles, each with thie
own gc, and it has been on my wishlist for some time to do this as a
collection. If you are handling gc creation, etc, in C, that may
account for a big part of the difference.
Since the new macosx backend was released in 0.98.5, I also need to
decide whether this patch belongs on the branch, and hence will get
pushed out as early as today in a bugfix release when some changes JJ
and Michael are working on are ready, or the trunk, in which case it
could be months. In favor of the trunk: this is more of a feature
enhancement than a bugfix, and patches to the branch should be
bugfixes with an eye to stability of the released code, though a good
argument could be made that this is a bugfix. In favor of the branch:
it is brand new code advertised as beta in 0.98.5 and so it is
unlikely that anyone is using it seriously yet, and since it is beta,
we should get as much of it out there ASAP so folks can test and pound
on it. I'm in favor of branch, but I wanted to bring this up here
since we are fairly new to the branch/trunk release maintenance game
and want to get some input and provide some color about which patches
should go where, especially in gray areas like this.
JDH
On Tue, Dec 16, 2008 at 6:08 PM, Michiel de Hoon <mjl...@ya...> wrote:
> Dear all,
>
> I have now implemented the draw_path_collection, draw_quad_mesh, and draw_markers methods in the Mac OS X native backend (see patch 2179017 at
> http://sourceforge.net/tracker/?func=detail&atid=560722&aid=2179017&group_id=80706). Some timings are below. In terms of raw drawing speed, the native backend can be either faster or slower than agg. On the other hand, the native backend can be considerably faster if the agg backend uses many calls to draw(); the native backend can avoid these superfluous because it has complete control over the event loop (see the third example below).
> # Timings in seconds
> # n Mac OS X TkAgg
> # 2 2 6
> # 3 3 23
> # 4 5 66
>
>

John and others,
I just committed a small patch that add gid(group id) as a property of
the Artist.
And also some small changes here and there, so that the svg backend
use this gid as the ID of each element. To do this, I slightly changed
the calling convention of the open_group() methods in Backends class.
I have mentioned about this some time ago, and these changes are meant
to be useful for some postprocessing of the svg fie
http://www.nabble.com/Re%3A-SVG-clickable-images-p20241569.html
I added two example, which apply gaussian blurring filter (for
dropshadow) and some lighting effects to the svg files created with
MPL. I added them under "examples/misc" because the examples are SVG
specific. Let me know if there is any other suitable place.
Note that the svg filter is not supported by all the svg renderer.
Inkscape is the best open source tool that I know of which supports
svg filter. The lighting filters (used svg_filter_pie.py) work fine
with inkscape. Gaussian blurring (svg_filter_line.py) is also
supported by firefox.
Regards,
-JJ

Hello,
I'm thinking about slightly modifying the draw() method of the Axes
class, so that user can optionally
calculate the position of the axes at drawing time. It may be
considered as a general version of the apply_aspect() method.
For example, instead of "self.apply_aspect()" call in the draw
function, we may put something like below.
if self._axes_locator:
 self._axes_locator(self, renderer)
else:
 self.apply_aspect()
where self._axes_locator is a (user-supplied) callable object which
takes the axes itself and the renderer as arguments.
I have been running a similar version of this, and I found it quite
helpful especially when drawing images. Here are a few of my use
cases.
 * colorbar (or any kind of axes) whose location is adjusted to match
the image location (which is calculated on the fly with apply_aspect).
 * grid of images (of same size) with fixed space between them.
I guess the needed change is not significant and I don't think it will
interfere with other things of Axes class.
So, how do others think?
Regards,
-JJ

Dear all,
I have now implemented the draw_path_collection, draw_quad_mesh, and draw_markers methods in the Mac OS X native backend (see patch 2179017 at
http://sourceforge.net/tracker/?func=detail&atid=560722&aid=2179017&group_id=80706). Some timings are below. In terms of raw drawing speed, the native backend can be either faster or slower than agg. On the other hand, the native backend can be considerably faster if the agg backend uses many calls to draw(); the native backend can avoid these superfluous because it has complete control over the event loop (see the third example below).
Best,
--Michiel.
# Scatter plot
n = 1e6
import matplotlib.pyplot as plt
f=plt.figure()
import numpy as np
x=np.arange(n)
y=np.sin(x)
ax=f.add_subplot(111)
plt.scatter(x,y,c=x**2.0)
# Time in seconds
# n 100,000 1,000,000 2,000,000 3,000,000
# MacOSX 6 45 92 140
# WxAgg 7 56 112 172
# TkAgg 9 56 113 172
# GtkAgg 7 55 111 173
# Quad mesh
import numpy as np
from matplotlib.pyplot import figure, show, savefig
from matplotlib import cm, colors
from numpy import ma
n = 1000
x = np.cos(np.linspace(-1.5,1.5,n))
y = np.linspace(-1.5,1.5,n*2)
X,Y = np.meshgrid(x,y);
Qx = np.sin(Y**2) - np.cos(X)
Qz = np.sin(Y) + np.sin(X)
Qx = (Qx + 1.1)
Z = np.sqrt(X**2 + Y**3)/5;
Z = (Z - Z.min()) / (Z.max() - Z.min())
# The color array can include masked values:
Zm = ma.masked_where(np.fabs(Qz) < 0.5*np.amax(Qz), Z)
fig = figure()
ax = fig.add_subplot(111)
ax.set_axis_bgcolor("#bdb76b")
ax.pcolormesh(Qx,Qz,Z)
show()
# Timings in seconds
# n Mac OS X TkAgg
# 500 6 6
# 1000 23 7
# 2000 138 40
# Subplots
from pylab import *
figure()
x=np.arange(20)
y=1+x**2
n = 4
for i in range(n*n):
 subplot(n,n,i+1)
 bar(x,y,log=True)
 xlim(-5,25)
 ylim(1,1e4)
# Timings in seconds
# n Mac OS X TkAgg
# 2 2 6
# 3 3 23
# 4 5 66
--- On Tue, 10/28/08, Michiel de Hoon <mjl...@ya...> wrote:
> --- On Tue, 10/28/08, John Hunter <jd...@gm...>
> wrote:
> > I haven't had a chance to look at the code yet,
> > but I suspect he hasn't implemented the 
> > path collection draw method. If it's not
> > implemented, we fall back on drawing each path
> > separately, which is a lot slower. scatter ultimately 
> > triggers a call to Renderer.draw_path_collection
> > which has a default implementation and a specialization
> > in backend_agg.
>
> Good point. Indeed I was not aware of the
> draw_path_collection method and I have not implemented it. I
> will implement this method and report back with the timings
> for Eric's example.
 

On Tue, Dec 16, 2008 at 10:57 PM, Sandro Tosi <mo...@de...> wrote:
> Hello Darren,
>
> On Tue, Dec 16, 2008 at 16:03, Darren Dale <dsd...@gm...> wrote:
>> It seems like the documentation should be a separately installable package
>> as far as package managers are concerned.
>
> We already have separate the doc from other mpl parts, to be precise
> we have these pkgs:
>
> python-matplotlib - the real module - 2.3M
> python-matplotlib-data - data pkg - 1.1M
> python-matplotlib-dbg - debug symbols - 11M
> python-matplotlib-doc - documentation - 87M
>
> So reducing -doc package is something I'd like to archive, before
> upload the package into Debian archive.
Thanks Sandro for working on it. Btw, having some form of the gallery
as a Debian package would be useful, I was missing this recently, when
I was hacking without an internet connection.
Ondrej

On Tue, Dec 16, 2008 at 15:10, Michael Droettboom <md...@st...> wrote:
> One question to ask is whether we need both the .pdf and .html manuals, or
> whether that could be broken up into two packages. That seems like an easy
> one if that fits Debian policies (which I know nothing about) -- and
> wouldn't degrade the documentation experience at all.
Well, if you're talking about Matplotlib.pdf, the whole manual in pdf
format, then maybe it doesn't worth: we already have a separate
package for documentation, so I think that all doc should be there
(with an adequate size :) ).
> Is there any way to transparently gzip compress the html files (as I believe
> Debian does with manpages)?
sadly, the compression of manpage is handled directly by "man"
executable, that uncompress and pipe the manpage into a PAGER. html
pages are rendered by web browser, and in case of local documentation,
the pages are read from local disk (so so web server to
"uncompress"-on-the-fly).
> Another option would be to not generate the high-res png and pdf examples.
> (Either or both).
that would be great. while pdf images are not that useful (at least
from my pov: I'm browsing web pages, I don't want to spawn a pdf
viewer to look at an image) hires could be "dropped" because even
"normal-res" images seems to give a clear idea of the power of mpl.
> Just removing them after the fact won't work, since one
> would end up with broken links from the docs. We would also have to change
> the html to not include those links. It should be fairly simple to provide
> an option to the doc build system to do this, and I'm happy to implement
> that if we all agree that's the direction to take.
FWIW, I really like to see such an option :)
> Beyond that, we'd be looking at selectively including certain examples,
> which I worry would add additional maintenance burden if there's too much
> divergence between the "full" and "small" manuals. I think that road should
> be a last resort.
If the size it's reasonable, then I would like to generate all the
examples, because... well, I like them! :)
Cheers,
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Hello Darren,
On Tue, Dec 16, 2008 at 16:03, Darren Dale <dsd...@gm...> wrote:
> It seems like the documentation should be a separately installable package
> as far as package managers are concerned.
We already have separate the doc from other mpl parts, to be precise
we have these pkgs:
python-matplotlib - the real module - 2.3M
python-matplotlib-data - data pkg - 1.1M
python-matplotlib-dbg - debug symbols - 11M
python-matplotlib-doc - documentation - 87M
So reducing -doc package is something I'd like to archive, before
upload the package into Debian archive.
Cheers,
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi