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
(4) |
2
(3) |
3
(12) |
4
(8) |
5
(10) |
6
(21) |
7
(25) |
8
(3) |
9
(3) |
10
(4) |
11
(6) |
12
(20) |
13
(32) |
14
(15) |
15
(4) |
16
(2) |
17
(4) |
18
(2) |
19
(3) |
20
(3) |
21
(7) |
22
(16) |
23
(2) |
24
(14) |
25
(11) |
26
(4) |
27
(2) |
28
(3) |
29
(5) |
30
(26) |
31
(18) |
|
|
|
|
|
Gökhan Sever <gok...@gm...> writes: > Get this tiny error: I committed your patch; thanks! -- Jouni K. Seppänen http://www.iki.fi/jks
John Hunter <jd...@gm...> writes: > # TODO: how to handle stale data in the cache that has been > # updated from svn -- is there a clean http way to get the current > # revision number that will not leave us at the mercy of html > # changes at sf? The mod_dav_svn server sends an ETag header that happens to contain the revision number where the file was last modified, and a Last-Modified header that contains the date of that revision. The clean http way to make use of these is to make a conditional request - I hacked up a processor class for urllib2 that does this, and checked it in. -- Jouni K. Seppänen http://www.iki.fi/jks
On Tue, Aug 4, 2009 at 11:17 AM, Josh Hemann<jh...@vn...> wrote: > > So, I just downloaded 0.99 rc1 and wanted to play with axesgrid examples and > got the results you reported below in your example. I am in fact naive, and > its not clear to me how to get around this problem of the demo_image module > not being found. What is the solution? The solution is to get the examples directory and run it from there, where it will have the example data. Although I added support for having auto-fetched data in svn, we haven't ported the examples over to use it yet. If you have svn you can grab the examples dir with svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib/examples mpl_examples and then run the examples in their directory, eg examples/axes_grid. Then they should be able to see their data. JDH
Hi, On 4 Aug 2009, at 14:12, Michael Droettboom wrote: > However, after doing that I run into another error importing mathtex > from mathtext_demo.py: > >> >>> from mathtex.mathtex_main import Mathtex >> Traceback (most recent call last): >> File "<stdin>", line 1, in <module> >> File "/home/mdroe/usr/lib/python2.5/site-packages/mathtex/ >> mathtex_main.py", line 2, in <module> >> from mathtex.parser import MathtexParser >> File "/home/mdroe/usr/lib/python2.5/site-packages/mathtex/ >> parser.py", line 7, in <module> >> from mathtex.boxmodel import * >> File "/home/mdroe/usr/lib/python2.5/site-packages/mathtex/ >> boxmodel.py", line 4, in <module> >> from mathtex.fonts import * >> File "/home/mdroe/usr/lib/python2.5/site-packages/mathtex/ >> fonts.py", line 5, in <module> >> from mathtex.ft2font import FT2Font, KERNING_DEFAULT >> ImportError: No module named ft2font > It looks like it's still looking for ft2font inside of mathtex, > which, of course, isn't there in the context of building in inside > of matplotlib. I thought you said that mathtex would use the > ft2font from matplotlib if it were available -- maybe I > misunderstood what you meant. fonts.py seemed to slip the net, somehow, and will not try to fallback on matplotlib. Easy to fix. > These sorts of installation issues are hard to test given that > installs don't clean up after themselves. Personally, I use > virtualenv to create "clean" python environments, then install > matplotlib in it, and then try running examples in that > environment. It's real fast to just blitz the environment and > create a new one each time for this kind of testing. Yes, I've been bitten by that several times now. I'll look into virtualenv, might save me some headaches. > I was able to work around this (by installing mathtex directly), but > I ran into the following because I have "mathtext.fontset" set up > "stixsans" in my matplotlibrc: I, for some reason, never ported stixsans over. Again easy to do and shouldn't take long. The stix and bakoma fonts currently work and unicode support is in mathtex, just needs some support code in matplotlib. > But I don't know if it matters to do this until the matplotlib/ > mathtex branch is merged back into the trunk. It is probably wroth doing it as soon as mathtex has a couple of stable releases behind it. >> There is a slight performance penalty associated with using mathtex >> -- due to each expression being parsed twice -- where matplotlib >> caches parsed expressions. If this is a problem let me know and >> I'll work on something. >> > It would be great to preserve the caching behavior, even if that > lives in the matplotlib side and not in the mathtex project itself. > Where it matters is with interactive panning and zooming: if the > tick labels use math, as in a log plot for example, they can get re- > renderered many times. I recall benchmarking it at the time I did > the big math re-write, and it was definitely worth worrying about at > the time, though I can't find my notes. If you benchmark and come > to a different conclusion (because things have become faster in > other ways) just let us know. It is probably easiest if I add it to the Mathtex class itself. Parsing is currently the biggest bottle-neck even with packrat parsing enabled. I did try zooming around the mathtext demo plot and found there to be quite a lot of lag, so it does seem worth it. Overall I think the best plan of action is to add caching support and stixsans into mathtex, fix the error with imports and then release version 0.2 of mathtex. Then matplotlib can be updated (and set to pull 0.2 from subversion). Regards, Freddie.
So, I just downloaded 0.99 rc1 and wanted to play with axesgrid examples and got the results you reported below in your example. I am in fact naive, and its not clear to me how to get around this problem of the demo_image module not being found. What is the solution? Thanks, Josh John Hunter-4 wrote: > > In some examples, I have been moving example functions and data into a > module, so that they can be run from anywhere. Many other examples > still rely on a relative path in the examples dir. Eg, I go to the > gallery and download the source for the axes grid toolkit example > simple_rgb.py, and try to run it from my desktop, I get the error "no > module names demo_image". While I know how to get the data, a naive > user will not. So in some examples I have been adopting the approach, > eg in examples/pylab_examples/scatter_demo2.py > > import matplotlib > datafile = matplotlib.get_example_data('goog.npy') > > These examples will run anywhere mpl is installed. Another approach > would to write a version of get_example_data that checks locally for a > datafile, and if it is not where you expect to be, attempt a > urlretrieve as a temp file. > > The gallery is becoming the goto place for most users of the website, > and I would like as many examples as possible to run after a simple > download to the desktop . I am sensitive to packagers who may not > want to ship large amounts of data w/ the main library, so we may want > to minimize the amount we ship in mpl-data which > matplotlib.get_example_data uses, but it may be a good idea to setup a > new svn directory at the top level (mpl_data) and write a urllib > enabled matplotlib.get_example_data that fetches it from the repo if > it can't find it locally. > > JDH > ----- Josh Hemann Statistical Advisor http://www.vni.com/ Visual Numerics jh...@vn... | P 720.407.4214 | F 720.407.4199 -- View this message in context: http://www.nabble.com/example-data-in-example-code-tp24760754p24811726.html Sent from the matplotlib - devel mailing list archive at Nabble.com.
Freddie Witherden wrote: > Hi, > > On 3 Aug 2009, at 17:39, Michael Droettboom wrote: > >> Is there an additional step to install mathtex? I thought the goal >> was to make "python setup.py install" work out of the box. >> > > This was the goal and I got quite close to achieving it. This latter > parts of this thread deal with the specific issues (relating to the > directory structure chosen) http://sourceforge.net/mailarchive/forum.php?thread_name=A97F3AC6-1434-4E6D-AF39-9DBD4653BCB4%40witherden.org&forum_name=matplotlib-devel > > So I was advised by John to just assume mathtex is installed. > Thankfully this is not hard to do -- and is covered in the INSTALL > file. It is basically a case of changing to lib/mathtext and running > python setup.py build && python setup.py install. > Sorry, I let that message slide through. I know John may not be, but I'm really concerned about the build being anything more than "python setup.py install" -- it's going to be hard for packagers and hard for end users. This problem is actually rather straightforward to solve using the "package_dir" mapping in distutils. See here: http://docs.python.org/distutils/setupscript.html#listing-whole-packages By adding {'mathtex': 'lib/mathtex/mathtex'} to package_dir, it all seems to work as desired. I've committed this change on the branch so you can see what I mean. However, after doing that I run into another error importing mathtex from mathtext_demo.py: > >>> from mathtex.mathtex_main import Mathtex > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > File > "/home/mdroe/usr/lib/python2.5/site-packages/mathtex/mathtex_main.py", > line 2, in <module> > from mathtex.parser import MathtexParser > File > "/home/mdroe/usr/lib/python2.5/site-packages/mathtex/parser.py", line > 7, in <module> > from mathtex.boxmodel import * > File > "/home/mdroe/usr/lib/python2.5/site-packages/mathtex/boxmodel.py", > line 4, in <module> > from mathtex.fonts import * > File "/home/mdroe/usr/lib/python2.5/site-packages/mathtex/fonts.py", > line 5, in <module> > from mathtex.ft2font import FT2Font, KERNING_DEFAULT > ImportError: No module named ft2font It looks like it's still looking for ft2font inside of mathtex, which, of course, isn't there in the context of building in inside of matplotlib. I thought you said that mathtex would use the ft2font from matplotlib if it were available -- maybe I misunderstood what you meant. These sorts of installation issues are hard to test given that installs don't clean up after themselves. Personally, I use virtualenv to create "clean" python environments, then install matplotlib in it, and then try running examples in that environment. It's real fast to just blitz the environment and create a new one each time for this kind of testing. I was able to work around this (by installing mathtex directly), but I ran into the following because I have "mathtext.fontset" set up "stixsans" in my matplotlibrc: > python mathtext_demo.py Traceback (most recent call last): File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py", line 352, in expose_event self._render_figure(self._pixmap, w, h) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py", line 75, in _render_figure FigureCanvasAgg.draw(self) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", line 327, in draw self.figure.draw(self.renderer) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/artist.py", line 46, in draw_wrapper draw(artist, renderer, *kl) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 774, in draw for a in self.axes: a.draw(renderer) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/artist.py", line 46, in draw_wrapper draw(artist, renderer, *kl) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 1721, in draw a.draw(renderer) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/artist.py", line 46, in draw_wrapper draw(artist, renderer, *kl) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/axis.py", line 757, in draw self.label.draw(renderer) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/text.py", line 515, in draw bbox, info = self._get_layout(renderer) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/text.py", line 279, in _get_layout clean_line, self._fontproperties, ismath=ismath) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", line 169, in get_text_width_height_descent self.dpi, rcParams['mathtext.default']) File "/home/mdroe/usr/lib/python2.5/site-packages/mathtex/mathtex_main.py", line 30, in __init__ fontset = self.fontset_mapping[fontset](default_style) KeyError: 'stixsans' > /home/mdroe/usr/lib/python2.5/site-packages/mathtex/mathtex_main.py(30)__init__() -> fontset = self.fontset_mapping[fontset](default_style) I haven't looked into this further, but it would be nice not to change the font selection API of matplotlib unless there's a good reason. > The branch handles the checking out of mathtex from its svn repo > (svn:externals) and any system that can build matplotlib can also > build mathtex. Currently the HEAD revision is checked out. This is > easy to change. > That's good for now while everything is in flux. Eventually, we may want to pin it to a particular revision so that updates of mathtex into matplotlib are explicitly tested. The Subversion manual makes a good argument for this: "You should seriously consider using explicit revision numbers in all of your externals definitions. Doing so means that you get to decide when to pull down a different snapshot of external information, and exactly which snapshot to pull. Besides avoiding the surprise of getting changes to third-party repositories that you might not have any control over, using explicit revision numbers also means that as you backdate your working copy to a previous revision, your externals definitions will also revert to the way they looked in that previous revision, which in turn means that the external working copies will be updated to match the way /they/ looked back when your repository was at that previous revision. For software projects, this could be the difference between a successful and a failed build of an older snapshot of your complex codebase." But I don't know if it matters to do this until the matplotlib/mathtex branch is merged back into the trunk. > There is a slight performance penalty associated with using mathtex -- > due to each expression being parsed twice -- where matplotlib caches > parsed expressions. If this is a problem let me know and I'll work on > something. > It would be great to preserve the caching behavior, even if that lives in the matplotlib side and not in the mathtex project itself. Where it matters is with interactive panning and zooming: if the tick labels use math, as in a log plot for example, they can get re-renderered many times. I recall benchmarking it at the time I did the big math re-write, and it was definitely worth worrying about at the time, though I can't find my notes. If you benchmark and come to a different conclusion (because things have become faster in other ways) just let us know. Cheers, Mike > Regards, Freddie. > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > 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
Hello, Thank you for your answer. When I explicitly give None as renderer argument, everything work well. Now I guess the question is why the default value is not used by the method? By the way, rasterization support wasn't introduced earlier than the 0.98.3 version? Regards, Jonathan Jae-Joon Lee a écrit : > I guess this is related with the decorator introduced by rasterization support. > While most of the artist seems to explicitly require the renderer > instance as the second argument of the draw method, the draw method in > the Axes class have default value of None. > The easiest fix seems to let the decorator returns the method with > renderer=None as in the Axes. > > By the way, Jonathan, I guess the easiest workaround for you is to > modify your code so that it explicitly gives the renderer argument. As > you see the default value for renderer is None. Just call it as > draw(None). > > Regards, > > -JJ >