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/PSD1FAX : (303)497-6449 325 BroadwayBoulder, CO, USA 80305-3328 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] (group) id support for artist
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 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Doc changes
On Wed, Dec 17, 2008 at 10:52 AM, Michael Droettboom 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 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Native backend for Mac OS X
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 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 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 >> >> > -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Native backend for Mac OS X
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 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 > > -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Native backend for Mac OS X
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 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Basemap inclusion of pupynere
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 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Basemap inclusion of pupynere
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/PSD1Email : [email protected] 325 BroadwayOffice : Skaggs Research Cntr 1D-113 Boulder, CO, USA 80303-3328 Web: http://tinyurl.com/5telg -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Doc changes
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 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Basemap inclusion of pupynere
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 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 0.98.5.1 released? (and site outdated)
Hi John, On Wed, Dec 17, 2008 at 12:26, John Hunter wrote: > On Wed, Dec 17, 2008 at 5:14 AM, Sandro Tosi 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 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Basemap inclusion of pupynere
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/PSD1Email : [email protected] 325 BroadwayOffice : Skaggs Research Cntr 1D-113 Boulder, CO, USA 80303-3328 Web: http://tinyurl.com/5telg -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Basemap question for Jeff: different data directory?
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:[email protected]] > Sent: Wednesday, December 17, 2008 5:03 AM > To: Drain, Theodore R > Cc: [email protected] > 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/PSD1FAX : (303)497-6449 > 325 BroadwayBoulder, CO, USA 80305-3328 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Basemap inclusion of pupynere
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 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 0.98.5.1 released? (and site outdated)
On Wed, Dec 17, 2008 at 5:14 AM, Sandro Tosi 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 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Doc changes
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 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 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] 0.98.5.1 released? (and site outdated)
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 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Doc changes
On Wed, Dec 17, 2008 at 22:16, Michael Droettboom 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 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Doc changes
On Wed, Dec 17, 2008 at 3:22 PM, Sandro Tosi wrote: > On Wed, Dec 17, 2008 at 22:16, Michael Droettboom 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 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Doc changes
On Wed, Dec 17, 2008 at 22:25, John Hunter wrote: > 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 do you mean something like the source package + debianization? of course we do! :) you need a "source" line in the /etc/apt/sources.list (something like deb-src ) and then apt-get source in this case matplotlib. > > 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. once you issued that "apt-get source" you'll have a nice "-" dir in . with the upstream tarball uncompress and with the debianization applied. With that, you can do all you can with the upstream source code, or use debian tools to compile the package. I hope I answered your question, -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Doc changes
On Wed, Dec 17, 2008 at 12:25:12PM -0600, John Hunter wrote: > Thanks again, sorry that was such a bear. Hopefully the plot > directive emerges stronger from the carnage. Talking about that, last time I looked, the plot directive, and the other MPL sphinx extension were not in the matplotlib namespace, and thus not importable by other programs. This is a pity, because they can be useful for other projects (I wrote for instance some lecture notes using sphinx to doctest them, and I wanted to use the plot directive). It seems it would be very easy to put them in a matplotlib submodule, and have the sphinx conf.py import from there. Nothing urgent, but if there is no reason no to, I would make me a happy man. Cheers, Gaël -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Doc changes
On Wed, Dec 17, 2008 at 3:57 PM, Gael Varoquaux wrote: > On Wed, Dec 17, 2008 at 12:25:12PM -0600, John Hunter wrote: > Talking about that, last time I looked, the plot directive, and the other > MPL sphinx extension were not in the matplotlib namespace, and thus not > importable by other programs. This is a pity, because they can be useful > for other projects (I wrote for instance some lecture notes using sphinx > to doctest them, and I wanted to use the plot directive). > > It seems it would be very easy to put them in a matplotlib submodule, and > have the sphinx conf.py import from there. Nothing urgent, but if there > is no reason no to, I would make me a happy man. We have provided the sphinx_template2 to serve as a starting point for sphinx projects that want to use the plot, mathmpl, etc, extensions. Unfortunately, we are not doing the best job of keeping the two in sync. Fernando and I have talked of the need to have standard, reusable components for these kinds of things. Perhaps it would be possible to move the guts of some of these into a matplotlib.sphinxext module. Here is the pointer to the sphinx template: http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/py4science/examples/sphinx_template2/ -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
