You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(33) |
Dec
(20) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(7) |
Feb
(44) |
Mar
(51) |
Apr
(43) |
May
(43) |
Jun
(36) |
Jul
(61) |
Aug
(44) |
Sep
(25) |
Oct
(82) |
Nov
(97) |
Dec
(47) |
2005 |
Jan
(77) |
Feb
(143) |
Mar
(42) |
Apr
(31) |
May
(93) |
Jun
(93) |
Jul
(35) |
Aug
(78) |
Sep
(56) |
Oct
(44) |
Nov
(72) |
Dec
(75) |
2006 |
Jan
(116) |
Feb
(99) |
Mar
(181) |
Apr
(171) |
May
(112) |
Jun
(86) |
Jul
(91) |
Aug
(111) |
Sep
(77) |
Oct
(72) |
Nov
(57) |
Dec
(51) |
2007 |
Jan
(64) |
Feb
(116) |
Mar
(70) |
Apr
(74) |
May
(53) |
Jun
(40) |
Jul
(519) |
Aug
(151) |
Sep
(132) |
Oct
(74) |
Nov
(282) |
Dec
(190) |
2008 |
Jan
(141) |
Feb
(67) |
Mar
(69) |
Apr
(96) |
May
(227) |
Jun
(404) |
Jul
(399) |
Aug
(96) |
Sep
(120) |
Oct
(205) |
Nov
(126) |
Dec
(261) |
2009 |
Jan
(136) |
Feb
(136) |
Mar
(119) |
Apr
(124) |
May
(155) |
Jun
(98) |
Jul
(136) |
Aug
(292) |
Sep
(174) |
Oct
(126) |
Nov
(126) |
Dec
(79) |
2010 |
Jan
(109) |
Feb
(83) |
Mar
(139) |
Apr
(91) |
May
(79) |
Jun
(164) |
Jul
(184) |
Aug
(146) |
Sep
(163) |
Oct
(128) |
Nov
(70) |
Dec
(73) |
2011 |
Jan
(235) |
Feb
(165) |
Mar
(147) |
Apr
(86) |
May
(74) |
Jun
(118) |
Jul
(65) |
Aug
(75) |
Sep
(162) |
Oct
(94) |
Nov
(48) |
Dec
(44) |
2012 |
Jan
(49) |
Feb
(40) |
Mar
(88) |
Apr
(35) |
May
(52) |
Jun
(69) |
Jul
(90) |
Aug
(123) |
Sep
(112) |
Oct
(120) |
Nov
(105) |
Dec
(116) |
2013 |
Jan
(76) |
Feb
(26) |
Mar
(78) |
Apr
(43) |
May
(61) |
Jun
(53) |
Jul
(147) |
Aug
(85) |
Sep
(83) |
Oct
(122) |
Nov
(18) |
Dec
(27) |
2014 |
Jan
(58) |
Feb
(25) |
Mar
(49) |
Apr
(17) |
May
(29) |
Jun
(39) |
Jul
(53) |
Aug
(52) |
Sep
(35) |
Oct
(47) |
Nov
(110) |
Dec
(27) |
2015 |
Jan
(50) |
Feb
(93) |
Mar
(96) |
Apr
(30) |
May
(55) |
Jun
(83) |
Jul
(44) |
Aug
(8) |
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(1) |
2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
|
1
(7) |
2
(5) |
3
(3) |
4
|
5
(1) |
6
(4) |
7
(1) |
8
(6) |
9
(2) |
10
(13) |
11
(1) |
12
|
13
(5) |
14
(1) |
15
(3) |
16
(1) |
17
(9) |
18
(1) |
19
(6) |
20
|
21
(2) |
22
(1) |
23
(2) |
24
(15) |
25
(1) |
26
(5) |
27
(6) |
28
(6) |
29
(5) |
30
(10) |
31
(1) |
|
Hello, while updating Basemap package in Debian, I noticed that lib/mpl_toolkits/basemap/pyproj.py could use the same BASEMAPDATA variable handling as of lib/mpl_toolkits/basemap/__init__.py , so I'm applying a patch like this: Index: basemap-1.0.5+dfsg/lib/mpl_toolkits/basemap/pyproj.py =================================================================== --- basemap-1.0.5+dfsg.orig/lib/mpl_toolkits/basemap/pyproj.py 2012年08月06日 19:26:00.000000000 +0200 +++ basemap-1.0.5+dfsg/lib/mpl_toolkits/basemap/pyproj.py 2012年08月10日 21:49:42.941275370 +0200 @@ -236,10 +236,14 @@ "sphere": {'a':6370997.0,'b':6370997.0,'description':"Normal Sphere"}, } -pyproj_datadir = os.sep.join([os.path.dirname(__file__), 'data']) -if not os.path.isdir(pyproj_datadir): - msg="proj data directory not found. Expecting it at: %s"%pyproj_datadir - raise IOError(msg) +# check to see if environment variable BASEMAPDATA set to a directory, +# and if so look for the data there. +if 'BASEMAPDATA' in os.environ: + pyproj_datadir = os.environ['BASEMAPDATA'] + if not os.path.isdir(pyproj_datadir): + raise RuntimeError('Path in environment BASEMAPDATA not a directory') +else: + pyproj_datadir = '/usr/share/basemap/data' set_datapath(pyproj_datadir) Maybe you can consider applying it upstream too (except for the part of setting it to '/usr/share/basemap/data' in case no variable is passed, it's a Debian specific change). Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
On Fri, Aug 10, 2012 at 1:00 PM, Michael Droettboom <md...@st...> wrote: > That is the end goal. I'm talking simply about the static webpage hosting > here. If I recall correctly, I think the space limitations on github used > to be a problem for us, which is why we haven't used it as the canonical web > hosting. But that doesn't seem to be a problem anymore. I was mostly > hoping that anyone involved in the decision to not go with github's web > hosting at the time could remember any other downsides. Glad to hear that! The github folks have been very flexible in their application of the quotas and have always said that any OSS project that has a legitimate need for additional space will always be granted. They just don't want github to become somebody's picture/music/movie backup system for free, that's all. I have never seen them actually enforce the limits on any OSS project, but I'd be happy to put you in touch directly with someone there if you want a more direct clarification on this. Best, f
On 08/10/2012 03:45 PM, Fernando Perez wrote: > On Fri, Aug 10, 2012 at 7:26 AM, Michael Droettboom <md...@st...> wrote: >> Supporting existing links to matplotlib.sourceforge.net is of course >> very important, and I would put whatever redirects we need to keep those >> working in any event. > Actually, why not move all the official domain machinery to > matplotlib.org? That is the end goal. I'm talking simply about the static webpage hosting here. If I recall correctly, I think the space limitations on github used to be a problem for us, which is why we haven't used it as the canonical web hosting. But that doesn't seem to be a problem anymore. I was mostly hoping that anyone involved in the decision to not go with github's web hosting at the time could remember any other downsides. > That can be managed with the github tools, and > github/pypi can be used for downloads with a far simpler workflow than > the particular incarnation of UX hell that is sourceforge's upload > system... I plan to move to github for downloads as well. > > We've been doing that for a while with ipython since we moved to > ipython.org, and we've been very happy. With suitable redirects in > place, no google rank will be lost nor will users be confused, and > gradually everyone's bookmarks and habits will transition to mpl.org. > > If you guys want to do that and run into any issues, we (ipython) will > be happy to share how it works for us and help out. > Thanks. Will do. Mike
On Fri, Aug 10, 2012 at 7:26 AM, Michael Droettboom <md...@st...> wrote: > Supporting existing links to matplotlib.sourceforge.net is of course > very important, and I would put whatever redirects we need to keep those > working in any event. Actually, why not move all the official domain machinery to matplotlib.org? That can be managed with the github tools, and github/pypi can be used for downloads with a far simpler workflow than the particular incarnation of UX hell that is sourceforge's upload system... We've been doing that for a while with ipython since we moved to ipython.org, and we've been very happy. With suitable redirects in place, no google rank will be lost nor will users be confused, and gradually everyone's bookmarks and habits will transition to mpl.org. If you guys want to do that and run into any issues, we (ipython) will be happy to share how it works for us and help out. Just a thought... f
----- Forwarded message from Damon McDougall <dam...@gm...> ----- > Date: 2012年8月10日 12:47:22 +0100 > From: Damon McDougall <dam...@gm...> > To: satish maurya <mau...@gm...> > Cc: mat...@li... > Subject: Re: [Matplotlib-users] help me Velocity depth plot in matplotlib > > On Fri, Aug 10, 2012 at 02:09:39PM +0530, satish maurya wrote: > > Dear All, > > > > I want to stairs plot (similar in matlab) matplotlib > > First i want for i data-set then multiple data-set super impose on that. > > I attach the figure it's showing velocity-depth stairs plots for > > superimpose (like hold on in matlab) > > large data-set. > > can anybody tell me how to plot that. > > > > I'm not sure I understand what you're asking. Are you asking how to make > a stairplot, or are you asking how to make *multiple* plots on one set > of axes? > > If your question is the former, matplotlib does not currently have a > stairplot implementation, but it wouldn't be hard to use the usual > plot() function to achieve the desired effect: > > Before: > > x = arange(0, 10, 1) > y = x * (10.0 - x) > plot(x, y) > > After: > > x = arange(0, 10, 1) > x_m = x - 0.5 # left-hand midpoints > x_p = x + 0.5 # right-hand midpoints > y = x * (10.0 - x) > x_all = dstack((x_m, x, x_p)).flatten() > y_all = dstack((y, y, y)).flatten() > plot(x_all, y_all) > > If your question is the latter, you can toggle the hold state just by > calling > > hold() > > Hope this helps. > > > > > see the figure > > > > Thank you > > > > -- > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > *Satish Maurya* > > *Research Scholar* > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > -- > Damon McDougall > http://damon-is-a-geek.com > B2.39 > Mathematics Institute > University of Warwick > Coventry > West Midlands > CV4 7AL > United Kingdom ----- End forwarded message ----- I have put in a PR regarding this, since this feature exists in Matlab. This brings the plotting interface of matplotlib more in line with that of Matlab. You can view the request at: https://github.com/matplotlib/matplotlib/pull/1068 Feedback welcome. Best, Damon -- Damon McDougall http://damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom
On 08/10/2012 10:49 AM, Phil Elson wrote: > Great! Are we going to be able to move away from using the sourceforge > mailing list too? I haven't given that much thought. Are there much better free alternatives to justify the disruption? > > Presumably these infrastructure costs get covered via the donations > that mpl receives rather than coming out of your pocket Michael? We're working out the details, but, yes, domain name registration is certainly, IMHO, a valid use of those funds. > > I think getting hold of matplotlib.org is a really good idea. Thanks > for doing that! You're welcome! Mike > > > > On 10 August 2012 15:28, Michael Droettboom <md...@st...> wrote: >> I have registered matplotlib.org. It currently just points to >> matplotlib.sourceforge.net, but it will allow us to have a consistent >> URL that isn't dependent on any particular host going forward. >> >> Mike >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> As far as I can see the github docs are as up-to-date as the > souceforge ones. Scrub that statement. My browser cache needed clearing. On 10 August 2012 15:44, Phil Elson <pel...@gm...> wrote: > I wasn't involved at the time, but was it because > matplotlib.github.com is slower? > > As far as I can see the github docs are as up-to-date as the > souceforge ones. (although reading the commit log on the docs repo > doesn't seem to agree with that statement) > > All in all, sounds promising. > > On 10 August 2012 15:26, Michael Droettboom <md...@st...> wrote: >> I know we had experimented with moving the main documentation website to >> matplotlib.github.com a while ago (and in fact there's still an old >> version of the docs sitting there). I can't remember the reason we >> chose to remain at matplotlib.sourceforge.net and searching the mailing >> list archive isn't helping jog my memory there. >> >> I'd like to move to github's hosting if possible because rsyncing to >> sourceforge is slow as molasses and doesn't always work reliably. >> >> Supporting existing links to matplotlib.sourceforge.net is of course >> very important, and I would put whatever redirects we need to keep those >> working in any event. >> >> Mike >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Great! Are we going to be able to move away from using the sourceforge mailing list too? Presumably these infrastructure costs get covered via the donations that mpl receives rather than coming out of your pocket Michael? I think getting hold of matplotlib.org is a really good idea. Thanks for doing that! On 10 August 2012 15:28, Michael Droettboom <md...@st...> wrote: > I have registered matplotlib.org. It currently just points to > matplotlib.sourceforge.net, but it will allow us to have a consistent > URL that isn't dependent on any particular host going forward. > > Mike > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
I wasn't involved at the time, but was it because matplotlib.github.com is slower? As far as I can see the github docs are as up-to-date as the souceforge ones. (although reading the commit log on the docs repo doesn't seem to agree with that statement) All in all, sounds promising. On 10 August 2012 15:26, Michael Droettboom <md...@st...> wrote: > I know we had experimented with moving the main documentation website to > matplotlib.github.com a while ago (and in fact there's still an old > version of the docs sitting there). I can't remember the reason we > chose to remain at matplotlib.sourceforge.net and searching the mailing > list archive isn't helping jog my memory there. > > I'd like to move to github's hosting if possible because rsyncing to > sourceforge is slow as molasses and doesn't always work reliably. > > Supporting existing links to matplotlib.sourceforge.net is of course > very important, and I would put whatever redirects we need to keep those > working in any event. > > Mike > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
I have registered matplotlib.org. It currently just points to matplotlib.sourceforge.net, but it will allow us to have a consistent URL that isn't dependent on any particular host going forward. Mike
I know we had experimented with moving the main documentation website to matplotlib.github.com a while ago (and in fact there's still an old version of the docs sitting there). I can't remember the reason we chose to remain at matplotlib.sourceforge.net and searching the mailing list archive isn't helping jog my memory there. I'd like to move to github's hosting if possible because rsyncing to sourceforge is slow as molasses and doesn't always work reliably. Supporting existing links to matplotlib.sourceforge.net is of course very important, and I would put whatever redirects we need to keep those working in any event. Mike
Hi Ludwig, You are right, it didn't work on the MacOSX backend either. I didn't notice since the backend doesn't support blitting, so I never tried it. In any case, it is exactly the same problem as in Qt4Agg, with exactly the same fix: In lib/matplotlib/backends/backend_macosx.py, add the last line to the "resize()" method of class "FigureCanvasMac": def resize(self, width, height): self.renderer.set_width_height(width, height) dpi = self.figure.dpi width /= dpi height /= dpi self.figure.set_size_inches(width, height) FigureCanvasBase.resize_event(self) Then it works. Cheers, Stefan -- View this message in context: http://matplotlib.1069221.n5.nabble.com/Matplotlib-Qt4Agg-backend-ignores-resize-event-tp29298p38468.html Sent from the matplotlib - devel mailing list archive at Nabble.com.
Hi, I noticed that when using tight_layout, the figure padding changes for different figure.dpi settings. This is caused by an error in when converting from points to inches. A point is always 1/72 inch and does not depend on the dots per inches. This is the patch for fixing the conversion: Diff https://github.com/pwuertz/matplotlib/commit/6edc3d9b04cc6b29475916cc25d5433e7b49b2d2 Pull request https://github.com/matplotlib/matplotlib/pull/1065 -- View this message in context: http://matplotlib.1069221.n5.nabble.com/Patch-fixed-conversion-from-pt-to-inch-in-tight-layout-tp38467.html Sent from the matplotlib - devel mailing list archive at Nabble.com.