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
(2) |
2
(3) |
3
(7) |
4
(8) |
5
(10) |
6
(4) |
7
|
8
|
9
(13) |
10
(1) |
11
(10) |
12
(4) |
13
|
14
|
15
|
16
(1) |
17
|
18
(3) |
19
(7) |
20
|
21
(4) |
22
|
23
(14) |
24
(5) |
25
(3) |
26
(3) |
27
(8) |
28
(1) |
29
(3) |
30
(2) |
31
(3) |
|
|
|
|
That fixes it for me. Thanks a lot for the quick fixes! Ryan On Wed, Mar 4, 2009 at 2:53 PM, Michael Droettboom <md...@st...> wrote: > I was rounding where I should have been truncating. I think this is fixed > now in SVN. > > Mike > > Ryan May wrote: > >> On Wed, Mar 4, 2009 at 12:16 PM, Michael Droettboom <md...@st...<mailto: >> md...@st...>> wrote: >> >> The 'regular' font stuff just isn't very well tested yet. I think >> I have a fix in SVN now. >> >> >> Thanks for the quick fix, it got rid of my errors. However, I'm seeing a >> little more of the funky font baseline that you had fixed. My original >> script doesn't show any problem, but I've attached an image produced with >> the mathtext_demo.py. Notice the odd baseline for versus in the title and >> sin in the equation on the graph. Thoughts? >> >> Ryan >> >> -- >> Ryan May >> Graduate Research Assistant >> School of Meteorology >> University of Oklahoma >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------ >> >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, >> CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the >> Enterprise >> -Strategies to boost innovation and cut costs with open source >> participation >> -Receive a 600ドル discount off the registration fee with the source code: >> SFAD >> http://p.sf.net/sfu/XcvMzF8H >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> > > -- > Michael Droettboom > Science Software Branch > Operations and Engineering Division > Space Telescope Science Institute > Operated by AURA for NASA > > -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from: Norman Oklahoma United States.
I was rounding where I should have been truncating. I think this is fixed now in SVN. Mike Ryan May wrote: > On Wed, Mar 4, 2009 at 12:16 PM, Michael Droettboom <md...@st... > <mailto:md...@st...>> wrote: > > The 'regular' font stuff just isn't very well tested yet. I think > I have a fix in SVN now. > > > Thanks for the quick fix, it got rid of my errors. However, I'm > seeing a little more of the funky font baseline that you had fixed. > My original script doesn't show any problem, but I've attached an > image produced with the mathtext_demo.py. Notice the odd baseline for > versus in the title and sin in the equation on the graph. Thoughts? > > Ryan > > -- > Ryan May > Graduate Research Assistant > School of Meteorology > University of Oklahoma > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a 600ドル discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > ------------------------------------------------------------------------ > > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
The 'regular' font stuff just isn't very well tested yet. I think I have a fix in SVN now. Mike Ryan May wrote: > Mike (or anyone else), > > I've been using the following combination of settings: > > mathtext.fontset : stixsans > mathtext.default : regular > > I've noticed this crashes when I run scripts that include mathtext > with \rm{} commands. In fact, I get a massive traceback with this > configuration when running the mathtext_examples.py. Here's the last > few lines: > > File > "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/pyparsing.py", > line 950, in _parseNoCache > tokens = fn( instring, tokensStart, retTokens ) > File > "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py", > line 2381, in symbol > return [Hlist( [self._make_space(0.2), > File > "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py", > line 2351, in _make_space > state.font, rcParams['mathtext.default'], 'm', state.fontsize, > state.dpi) > File > "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py", > line 446, in get_metrics > info = self._get_info(font, font_class, sym, fontsize, dpi) > File > "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py", > line 579, in _get_info > self._get_glyph(fontname, font_class, sym, fontsize) > File > "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py", > line 812, in _get_glyph > fontname, font_class, uniindex) > File > "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py", > line 919, in _map_virtual_font > mapping = mapping[font_class] > KeyError: 'regular' > > Is this a supported configuration? I know that I personally like the > look of the text with these two settings. Thoughts? > > Ryan > > -- > Ryan May > Graduate Research Assistant > School of Meteorology > University of Oklahoma > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a 600ドル discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > ------------------------------------------------------------------------ > > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
Mike (or anyone else), I've been using the following combination of settings: mathtext.fontset : stixsans mathtext.default : regular I've noticed this crashes when I run scripts that include mathtext with \rm{} commands. In fact, I get a massive traceback with this configuration when running the mathtext_examples.py. Here's the last few lines: File "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/pyparsing.py", line 950, in _parseNoCache tokens = fn( instring, tokensStart, retTokens ) File "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py", line 2381, in symbol return [Hlist( [self._make_space(0.2), File "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py", line 2351, in _make_space state.font, rcParams['mathtext.default'], 'm', state.fontsize, state.dpi) File "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py", line 446, in get_metrics info = self._get_info(font, font_class, sym, fontsize, dpi) File "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py", line 579, in _get_info self._get_glyph(fontname, font_class, sym, fontsize) File "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py", line 812, in _get_glyph fontname, font_class, uniindex) File "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py", line 919, in _map_virtual_font mapping = mapping[font_class] KeyError: 'regular' Is this a supported configuration? I know that I personally like the look of the text with these two settings. Thoughts? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma
Great. I applied your patch and pushed it to the web repository. I agree, that some more serious refactoring might be good. I have been leaving comments throughout the code with my thoughts on this. Cheers, Jon. On Wed, Mar 4, 2009 at 4:53 AM, Reinier Heeres <re...@he...> wrote: > Hi all, > > I was also a bit disappointed about the fact that 3d plotting support > was dropped. I'm happy to help out to get it going again, so here's a > patch to get surface plotting working; I'm busy with the contour plots > as well. > (We might want to do some code refactoring as well when it's functional). > > Regards, > Reinier > > On Wed, Mar 4, 2009 at 5:01 AM, Rob Clewley <rob...@gm...> wrote: >> On Tue, Mar 3, 2009 at 11:39 AM, John Hunter <jd...@gm...> wrote: >> >>> Well, it is painfully slow, since it does everything in software, and there >>> are some corner cases where the zorder clipping is broken in the presence of >>> alpha transparency, and it doesn't do lighting, shadows, etc.... But it >>> does do enough for basic stuff, so we would be happy if you could resurrect >>> it cleanly enough for a toolkit. >>> >> >> I'd just like to add that having a *bare minimum* 3D capability in mpl >> is extremely useful to me -- i.e. being to visualize 3D data as a >> point cloud or a wireframe mesh. While teaching with python and doing >> numerical experiments in my research it's invaluable to be able to >> throw together a wholly non-publication quality 3D plot to get a quick >> idea of what's going on. I would imagine that others who use mpl >> professionally (and not necessarily only for public consumption) would >> agree on the value of maintaining this bare minimum even if there is >> no short- or medium-term expectation that it will develop into >> anything more sophisticated. >> >> Cheers, >> Rob >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >> -Strategies to boost innovation and cut costs with open source participation >> -Receive a 600ドル discount off the registration fee with the source code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > > > -- > Reinier Heeres > Waalstraat 17 > 2515 XK Den Haag > The Netherlands > > Tel: +31 6 10852639 > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a 600ドル discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > >
Hi all, I was also a bit disappointed about the fact that 3d plotting support was dropped. I'm happy to help out to get it going again, so here's a patch to get surface plotting working; I'm busy with the contour plots as well. (We might want to do some code refactoring as well when it's functional). Regards, Reinier On Wed, Mar 4, 2009 at 5:01 AM, Rob Clewley <rob...@gm...> wrote: > On Tue, Mar 3, 2009 at 11:39 AM, John Hunter <jd...@gm...> wrote: > >> Well, it is painfully slow, since it does everything in software, and there >> are some corner cases where the zorder clipping is broken in the presence of >> alpha transparency, and it doesn't do lighting, shadows, etc.... But it >> does do enough for basic stuff, so we would be happy if you could resurrect >> it cleanly enough for a toolkit. >> > > I'd just like to add that having a *bare minimum* 3D capability in mpl > is extremely useful to me -- i.e. being to visualize 3D data as a > point cloud or a wireframe mesh. While teaching with python and doing > numerical experiments in my research it's invaluable to be able to > throw together a wholly non-publication quality 3D plot to get a quick > idea of what's going on. I would imagine that others who use mpl > professionally (and not necessarily only for public consumption) would > agree on the value of maintaining this bare minimum even if there is > no short- or medium-term expectation that it will develop into > anything more sophisticated. > > Cheers, > Rob > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a 600ドル discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Reinier Heeres Waalstraat 17 2515 XK Den Haag The Netherlands Tel: +31 6 10852639
On Tue, Mar 3, 2009 at 11:39 AM, John Hunter <jd...@gm...> wrote: > Well, it is painfully slow, since it does everything in software, and there > are some corner cases where the zorder clipping is broken in the presence of > alpha transparency, and it doesn't do lighting, shadows, etc.... But it > does do enough for basic stuff, so we would be happy if you could resurrect > it cleanly enough for a toolkit. > I'd just like to add that having a *bare minimum* 3D capability in mpl is extremely useful to me -- i.e. being to visualize 3D data as a point cloud or a wireframe mesh. While teaching with python and doing numerical experiments in my research it's invaluable to be able to throw together a wholly non-publication quality 3D plot to get a quick idea of what's going on. I would imagine that others who use mpl professionally (and not necessarily only for public consumption) would agree on the value of maintaining this bare minimum even if there is no short- or medium-term expectation that it will develop into anything more sophisticated. Cheers, Rob