SourceForge logo
SourceForge logo
Menu

matplotlib-devel — matplotlib developers

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)





Showing 7 results of 7

From: Jouni K. S. <jk...@ik...> - 2009年08月04日 19:52:04
Gökhan Sever <gok...@gm...> writes:
> Get this tiny error:
I committed your patch; thanks!
-- 
Jouni K. Seppänen
http://www.iki.fi/jks
From: Jouni K. S. <jk...@ik...> - 2009年08月04日 19:46:06
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
From: John H. <jd...@gm...> - 2009年08月04日 17:06:11
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
From: Freddie W. <fr...@wi...> - 2009年08月04日 17:04:19
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.
From: Josh H. <jh...@vn...> - 2009年08月04日 16:18:01
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.
From: Michael D. <md...@st...> - 2009年08月04日 13:13:21
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
From: Jonathan D. <jon...@ho...> - 2009年08月04日 09:34:13
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
> 
1 message has been excluded from this view by a project administrator.

Showing 7 results of 7

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X





Briefly describe the problem (required):
Upload screenshot of ad (required):
Select a file, or drag & drop file here.
Screenshot instructions:

Click URL instructions:
Right-click on the ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)

More information about our ad policies

Ad destination/click URL:

AltStyle によって変換されたページ (->オリジナル) /