Re: [matplotlib-devel] SF.net SVN: matplotlib: [3744] trunk/matplotlib/lib/matplotlib
Perhaps the difference is below the noise floor? I was focusing only on startup time by running lsprofcalltree over a script containing only "import pylab". In that context, dedent was the largest contributor to startup time (other than stuff in the stdlib and numpy) before this change. But I would imagine that that over the total time of backend_driver.py and actually doing stuff like, say, *plotting* is fairly insignificant. Cheers, Mike Eric Firing wrote: > Mike, > > After a quick test, I am puzzled: running "backend_driver.py Template" > takes 0.49 minutes on my machine before and after this change, so the > dedenting time must have been less than I thought. > > Eric > > [EMAIL PROTECTED] wrote: >> Revision: 3744 >> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=3744&view=rev >> Author: mdboom >> Date: 2007-08-28 12:17:21 -0700 (Tue, 28 Aug 2007) >> >> Log Message: >> --- >> Use regular expressions to do dedenting. This is ~15X faster than the >> old implementation. dedent accounted for around 30% of the time spent >> in "import pylab", so was probably worthy of optimization, even if this >> regex approach is less clear. The results are identical to the old >> implementation, with the exception of a single docstring (in >> backend_bases.py) that needed to be fixed. > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] matplotlib installation error
Hi, I have been having problems trying to install matplotlib properly on our server. Our environment is Debian 4.1.1-21, Python2.4 , and I have installed all the required modules (numpy, Numeric etc). I originally tried installing matplotlib from source, but the build was unsuccessful. I was getting this error when I tried building matplotlib-0.90.1: python setup.py build building for GTK requires pygtk; you must be able to "import gtk" in your build/install environment TKAgg requires TkInter running build running build_py copying lib/matplotlib/mpl-data/matplotlibrc -> build/lib.linux-x86_64-2.3/matplotlib/mpl-data running build_ext building 'matplotlib.backends._na_backend_agg' extension c++ -pthread -shared build/temp.linux-x86_64-2.3/agg23/src/agg_trans_affine.o build/temp.linux-x86_64-2.3/agg23/src/agg_path_storage.o build/temp.linux-x86_64-2.3/agg23/src/agg_bezier_arc.o build/temp.linux-x86_64-2.3/agg23/src/agg_curves.o build/temp.linux-x86_64-2.3/agg23/src/agg_vcgen_dash.o build/temp.linux-x86_64-2.3/agg23/src/agg_vcgen_stroke.o build/temp.linux-x86_64-2.3/agg23/src/agg_rasterizer_scanline_aa.o build/temp.linux-x86_64-2.3/agg23/src/agg_image_filters.o build/temp.linux-x86_64-2.3/src/_image.o build/temp.linux-x86_64-2.3/src/ft2font.o build/temp.linux-x86_64-2.3/src/mplutils.o build/temp.linux-x86_64-2.3/CXX/IndirectPythonInterface.o build/temp.linux-x86_64-2.3/CXX/cxx_extensions.o build/temp.linux-x86_64-2.3/CXX/cxxsupport.o build/temp.linux-x86_64-2.3/CXX/cxxextensions.o build/temp.linux-x86_64-2.3/src/_na_backend_agg.o -L/usr/local/lib -L/usr/lib -L/usr/lib64 -L/usr/local/lib -L/usr/lib -L/usr/lib64 -lpng -lz -lstdc++ -lm -lfreetype -lz -lstdc++ -lm -o build/lib.linux-x86_64-2.3/matplotlib/backends/_na_backend_agg.so /usr/bin/ld: /usr/local/lib/libpng.a(png.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libpng.a: could not read symbols: Bad value collect2: ld returned 1 exit status error: command 'c++' failed with exit status 1 So I tried installing matplotlib from distribution (ie. using apt-get install python-matplotlib), thinking it may work instead of me trying to manually install it. The distribution installs matplotlib-0.87.7, which is older than the current version available by source. And it seemed to compile fine without any errors. However, when I try to import pylab using python command line, I get this error: import matplotlib import pylab Traceback (most recent call last): File "", line 1, in ? File "pylab.py", line 1, in ? from matplotlib.pylab import * File "matplotlib/pylab.py", line 197, in ? import cm File "matplotlib/cm.py", line 5, in ? import colors File "matplotlib/colors.py", line 33, in ? from numerix import array, arange, take, put, Float, Int, where, \ File "matplotlib/numerix/__init__.py", line 75, in ? from _sp_imports import nx, infinity, rand, randn, isnan, all, any File "matplotlib/numerix/_sp_imports.py", line 9, in ? from numpy import Int8, UInt8, \ ImportError: cannot import name Int8 I think this Debian distribution of matplotlib (which is older than the current release) is incompatible with the current version of numpy/Numeric that I have installed, but I'm not sure. I would rather have the latest matplotlib vesrion installed (version 0.90.1), but I can't seem to get it to even build properly. I'm stumped and I'm hoping someone has an idea why I might be getting this error, and how I can get around it. Please let me know if you need more information if it helps understand the problem better. Thanks in advance, best, Hardeep - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib installation error
Hardeep Nahal <[EMAIL PROTECTED]> writes: > /usr/bin/ld: /usr/local/lib/libpng.a(png.o): relocation R_X86_64_32 > against `a local symbol' can not be used when making a shared object; > recompile with -fPIC That sounds like your libpng library is broken. Since it is in /usr/local/lib, it is probably not provided by Debian but installed by yourself. Doesn't Debian provide libpng? > ImportError: cannot import name Int8 > > I think this Debian distribution of matplotlib (which is older than > the current release) is incompatible with the current version of > numpy/Numeric that I have installed, but I'm not sure. Yes. I think there was a period when you had to match versions of numpy and matplotlib quite closely. Modern numpy does not have Int8, so you cannot use that version of matplotlib with that version of numpy. -- Jouni K. Seppänen http://www.iki.fi/jks - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib installation error
On Aug 29, 2007, at 1:59 PM, Hardeep Nahal wrote: > > build/temp.linux-x86_64-2.3/src/_na_backend_agg.o -L/usr/local/lib > -L/usr/lib -L/usr/lib64 -L/usr/local/lib -L/usr/lib -L/usr/lib64 -lpng > -lz -lstdc++ -lm -lfreetype -lz -lstdc++ -lm -o > build/lib.linux-x86_64-2.3/matplotlib/backends/_na_backend_agg.so > /usr/bin/ld: /usr/local/lib/libpng.a(png.o): relocation R_X86_64_32 > against `a local symbol' can not be used when making a shared object; > recompile with -fPIC > /usr/local/lib/libpng.a: could not read symbols: Bad value > collect2: ld returned 1 exit status > error: command 'c++' failed with exit status 1 You need to either recompile libpng so it builds a shared library or delete `/usr/local/lib/libpng.a' so gcc picks up the default version provided by Debian. > I think this Debian distribution of matplotlib (which is older than > the current release) is incompatible with the current version of > numpy/Numeric that I have installed, but I'm not sure. I would rather > have the latest matplotlib vesrion installed (version 0.90.1), but I > can't seem to get it to even build properly. Did you install your own copy of numpy or are you using the one that comes with Debian? If you're using the one that comes with Debian, I'll try to reproduce the problem and file a bug report. Ken - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Mathtext improvements (merging into trunk)
On 8/21/07, Michael Droettboom <[EMAIL PROTECTED]> wrote: > Darren Dale wrote: > >> I'm concerned about consistency and/or redundancy between this and the > >> new markup kwarg. I don't know whether or not "usetex" being > >> "all-or-nothing" is desirable. But we could meet in the middle by doing > >> one of the following: > >> > >>a) only send text to LaTeX for rendering when text.usetex=True and > >> markup="tex". (Which makes usetex=True behave a little more like > >> usetex=False). > > > > This seems like a bad idea. If I want to use tex as my text layout engine, > > now > > I have two settings to keep track of. We'll get lots of posts asking why > > latex is not being used when usetex is True. > > I agree with this point. My counter-worry is that people may be > surprised when their dollar signs behave differently when usetex is on > or off. Maybe people don't change that setting all that often in > practice, though... We could (and I'm not necessarily advocate this), > pre-process the string sent to LaTeX when usetex is True and markup == > 'plain', so that the dollar signs are escaped (and will appear as dollar > signs in the output). > > >>b) add another value to markup, to render text with LaTeX. (If we > >> do, I would suggest changing the kwarg to "text_renderer" and having the > >> values be "normal", "mathtext" and "latex" or something) > > > > This seems reasonable. Although, if we make it so latex can be used to > > layout > > some text but not others, I worry that we will get no end of posts > > complaining about how the latex fonts dont match the mathtext or normal > > fonts. > > Agreed. > > >>c) make markup="tex" be all-or-nothing as well (that is, keep the > >> rcParam, but drop the kwarg.) With this flag, you're basically saying > >> "I know how to deal with $'s". > >> > >> b) is probably the most flexible (maybe too flexible, as I can't see why > >> one would want to use all three types of rendering in the same plot). > >> a) and b) would break backward compatibility with 0.90.1, while c) would > >> not. > >> > >> Any thoughts? > > > > I think b) fits best. Maybe backward compatibility can be maintained. usetex > > would be deprecated, and would set the text_renderer rcParam to latex when > > True. > > That seems like a good approach, if we go with option b). > > > Or does 0.90.1 already have the markup kwarg? > > The markup kwarg is only a couple weeks old. > > > Again, there must be a > > way. The new validation mechanism in rcParams (not traits, the stuff I did > > right before traits) could probably provide a route for transition without > > actually breaking anything. > > Good point. > > > I am pretty busy this week at work, and will be > > on vacation for 11 days starting August 24, just letting you know. > > Thanks. I don't think there's a huge rush to decide this (the > implementation should be straightforward no matter what we decide). But > it would make sense to sort this out before the next release. Sorry to jump in late on this discussion again -- I was just trying to use the new mathtext and ran into this use case ax.plot(something, label=r'$\alpha=1'$) ax.legend() Paul mentioned earlier in his objection to the markup kwarg that legend would be a problem, and there will probably be other cases too. I suggested once before that we adopt something like the following rule: if a string has one dollar sign, treat it as plain text. If it has more that one unquoted dollar sign, treat it as TeX, and use mathtext or usetex depending on rc. I know Eric objected that this kind of complexity can make things unpleasant and lead to some difficult to debug oddities, but I think this is a case where convenience trumps complexity. I would like the rescind my earlier vote (now that I am trying to actually use this stuff for real work) and support mathtext w/o kwark markup. To support the use case above with svn, will I need to get the text instances back from the legend and set the markup property on them? JDH - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib installation error
Yes, I think my libpng library was corrupt, but when I tried reinstalling, it still wouldn't work. So I deleted it, as Ken suggested, and it worked. I think it wasn't finding the default libpng, and was going straight to the corrupted version. I spent the whole day trying to figure this out! ;P , so thank you very much Ken and Jouni for your suggestions. It appears the matplotlib and numpy packages that come with Debian are incompatible. But I installed matplotlib 0.90.1 and numpy 1.0.3-2 on my own, and after fixing that libpng error, they appear to be compatible. Hardeep Quoting Ken McIvor <[EMAIL PROTECTED]>: > On Aug 29, 2007, at 1:59 PM, Hardeep Nahal wrote: >> >> build/temp.linux-x86_64-2.3/src/_na_backend_agg.o -L/usr/local/lib >> -L/usr/lib -L/usr/lib64 -L/usr/local/lib -L/usr/lib -L/usr/lib64 -lpng >> -lz -lstdc++ -lm -lfreetype -lz -lstdc++ -lm -o >> build/lib.linux-x86_64-2.3/matplotlib/backends/_na_backend_agg.so >> /usr/bin/ld: /usr/local/lib/libpng.a(png.o): relocation R_X86_64_32 >> against `a local symbol' can not be used when making a shared object; >> recompile with -fPIC >> /usr/local/lib/libpng.a: could not read symbols: Bad value >> collect2: ld returned 1 exit status >> error: command 'c++' failed with exit status 1 > > You need to either recompile libpng so it builds a shared library or > delete `/usr/local/lib/libpng.a' so gcc picks up the default version > provided by Debian. > >> I think this Debian distribution of matplotlib (which is older than >> the current release) is incompatible with the current version of >> numpy/Numeric that I have installed, but I'm not sure. I would rather >> have the latest matplotlib vesrion installed (version 0.90.1), but I >> can't seem to get it to even build properly. > > Did you install your own copy of numpy or are you using the one that > comes with Debian? If you're using the one that comes with Debian, > I'll try to reproduce the problem and file a bug report. > > Ken - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
