[matplotlib-devel] Blocker
Hi all, I cannot build matplotlib from svn since last Friday. Any idea ? Nils cc1plus: Warnung: Kommandozeilenoption "-Wstrict-prototypes" ist gültig für Ada/C/ObjC, aber nicht für C++ g++ -pthread -shared build/temp.linux-x86_64-2.5/agg24/src/agg_curves.o build/temp.linux-x86_64-2.5/agg24/src/agg_bezier_arc.o build/temp.linux-x86_64-2.5/agg24/src/agg_trans_affine.o build/temp.linux-x86_64-2.5/agg24/src/agg_vcgen_stroke.o build/temp.linux-x86_64-2.5/CXX/cxx_extensions.o build/temp.linux-x86_64-2.5/CXX/cxxsupport.o build/temp.linux-x86_64-2.5/CXX/IndirectPythonInterface.o build/temp.linux-x86_64-2.5/CXX/cxxextensions.o build/temp.linux-x86_64-2.5/src/path.o -L/usr/local/lib -L/usr/lib -L/usr/local/lib64 -L/usr/lib64 -lpng -lz -lstdc++ -lm -o build/lib.linux-x86_64-2.5/matplotlib/_path.so /usr/bin/ld: cannot find -lpng collect2: ld gab 1 als Ende-Status zurück error: command 'g++' failed with exit status 1 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Blocker
Nils Wagner wrote: > Hi all, > > I cannot build matplotlib from svn since last Friday. > Any idea ? > -L/usr/lib -L/usr/local/lib64 -L/usr/lib64 -lpng -lz > -lstdc++ -lm -o > build/lib.linux-x86_64-2.5/matplotlib/_path.so > /usr/bin/ld: cannot find -lpng Do you have a libpng.so in /usr/lib64 or /usr/local/lib64? My interpretation of the error message is that the linker is not finding it. Eric - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] puzzle: interactive backend case with ipython
While investigating a bug pointed out by Andrew (and one that I had introduced some time ago) I found to my horror that I had also caused another bug: interactive plotting was not working with ipython -pylab. I backed out part of r5420, and that fixed the problem. This temporary fix is to restore the mixed case backend names in the interactive_bk list that is now set in rcsetup.py and imported by backends/__init__.py. I am baffled as to why this is needed at present; I have not been able to figure out why ipython threading seems to get confused when that list has lower case names for gtkagg, qtagg, and wxagg, but not for tkagg or qt4agg. I don't see anywhere in either the ipython or the mpl code that should care about the case of the names in that list, now that I have ensured that comparisons against backend names in mpl (everywhere I could find them--maybe I missed on) are case-insensitive, and get_backend() returns only lower case. rcParams['backend'] can still have mixed case, however. Any suggestions as to what I am missing or where to look? Related question: I just noticed that there is also a config/rcsetup.py. Is there any reason why there has to be so much duplication (and now gradual divergence) between this and the regular rcsetup.py? Is there any reason the traits config system can't use the regular version, maybe with some changes merged in? Eric - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] puzzle: interactive backend case with ipython
On Monday 09 June 2008 03:55:47 Eric Firing wrote: > While investigating a bug pointed out by Andrew (and one that I had > introduced some time ago) I found to my horror that I had also caused > another bug: interactive plotting was not working with ipython -pylab. > I backed out part of r5420, and that fixed the problem. This temporary > fix is to restore the mixed case backend names in the interactive_bk > list that is now set in rcsetup.py and imported by backends/__init__.py. > > I am baffled as to why this is needed at present; I have not been able > to figure out why ipython threading seems to get confused when that list > has lower case names for gtkagg, qtagg, and wxagg, but not for tkagg or > qt4agg. I don't see anywhere in either the ipython or the mpl code that > should care about the case of the names in that list, now that I have > ensured that comparisons against backend names in mpl (everywhere I > could find them--maybe I missed on) are case-insensitive, and > get_backend() returns only lower case. rcParams['backend'] can still > have mixed case, however. > > Any suggestions as to what I am missing or where to look? > > Related question: I just noticed that there is also a config/rcsetup.py. > Is there any reason why there has to be so much duplication (and now > gradual divergence) between this and the regular rcsetup.py? Is there > any reason the traits config system can't use the regular version, maybe > with some changes merged in? We should probably discuss the future of TConfig in mpl at some point. Its been a while since I looked at it, but basically I was trying to isolate that code so it didnt creep into mpl until we were ready. There is lots of duplication in config, if you want to change it to import from rcsetup, its alright with me. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] Python novice stumped by ImportError
On Monday 09 June 2008 01:27:57 Gael Varoquaux wrote: > On Sun, Jun 08, 2008 at 06:13:24PM -0400, Darren Dale wrote: > > Matplotlib's setup scripts are designed to avoid this problem. There are > > three conditions under which we install traits: > > > > 1) Traits is not installed > > 2) A previous version of traits is installed, but it is a version > > installed by matplotlib. I added an "-mpl" to the end of traits > > __version__ string so we can keep track. > > 3) The user explicitly askes for it in setup.cfg > > > > So if matplotlib is overwriting traits when it should not, I want to fix > > it. But I need more information about what is causing it, because I don't > > see how it could happen. > > If Traits is installed after MPL, if I get it right, then the problem > occurs. IIRC, this is the problem I stumbled upon once. I don't see why that would cause a problem. > > I tried this when I first started working with TConfig, and concluded > > that it was not possible because there are too many places where traits > > expects enthought to be a top level package. There were all kind of > > errors, exceptions being raised that were not named as expected, > > extension code that would need to be modified, so we settled on the > > current solution. > > OK. You are right. In nipy I modified enthought.traits and > enthought.etsconfig. This was not a beautiful job, I must admit. Maybe > monkey patching sys.path is the option (it is the way eggs do it) thought > I must admit I hate it, because it puts a lot of magic, that will > take the user by surprise. Anyway, the criteria for monkey-patching > sys.path must be improved, I feel. I also considered modifying sys.patch, this solution was roundly booed. > If I understand things correctly, the current problem can be described > by: > >* User has an old version of ETS, (the one in Enthon 1.0.4, that is a > very old one), his code needs the old version. >* User installs a new version of MPL. >* His code stops working. > > I agree that as you describe things, this should not happen. Maybe I have > gotten wrong the order in which the user did things. I have the feeling > things shouldn't be dependent on the order in which you do the steps > (maybe the test for monkey-patching sys.path should not be at > install time, but at load time). What test? I don't follow. > Maybe the test fails for a very old version of traits. I wanted to have a > quick look at this code, but I can't find it after a quick scan of the > MPL source, and I can't devote much time to this right now. Its a short section in setupext.py (which is in the same directory a setup.py), the function is called check_provide_traits. I think we would rather make traits an external dependency, if it could be easily installed as a separate package by a novice python user. Would it be possible for http://code.enthought.com/projects/traits/ to list specific instructions and links to the downloads? Or to list traits on the Python Package Index? - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] Python novice stumped by ImportError
On Mon, Jun 9, 2008 at 5:41 AM, Darren Dale <[EMAIL PROTECTED]> wrote: > I think we would rather make traits an external dependency, if it could be > easily installed as a separate package by a novice python user. Would it be > possible for http://code.enthought.com/projects/traits/ to list specific > instructions and links to the downloads? Or to list traits on the Python > Package Index? I also agree that we should not install a modified version of traits in the top level namespace. Let's disable all default installs of enthought traits until we work this out. We only need it for the optional rc config and so let's require that someone manually turn it on in setup.cfg if they want it. In particular, let's fix this before the next bugfix release. If we opt to depend on traits for the new rc, we will either need to require and external dependency, figure out a way to install a completely working and compatible version, or do the extra work to install it inside the matplotlib namespace. I prefer 1 or 3, but at this point I think whether we will migrate to the traited rc system is an open question so disabling is the right solution for now. Darren, can you take care of this? JDH - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] puzzle: interactive backend case with ipython
Hi Eric, show() isn't bringing up my plots with r5430 in normal scripts (i.e. not using IPython). -Andrew Eric Firing wrote: > While investigating a bug pointed out by Andrew (and one that I had > introduced some time ago) I found to my horror that I had also caused > another bug: interactive plotting was not working with ipython -pylab. > I backed out part of r5420, and that fixed the problem. This temporary > fix is to restore the mixed case backend names in the interactive_bk > list that is now set in rcsetup.py and imported by backends/__init__.py. > > I am baffled as to why this is needed at present; I have not been able > to figure out why ipython threading seems to get confused when that list > has lower case names for gtkagg, qtagg, and wxagg, but not for tkagg or > qt4agg. I don't see anywhere in either the ipython or the mpl code that > should care about the case of the names in that list, now that I have > ensured that comparisons against backend names in mpl (everywhere I > could find them--maybe I missed on) are case-insensitive, and > get_backend() returns only lower case. rcParams['backend'] can still > have mixed case, however. > > Any suggestions as to what I am missing or where to look? > > Related question: I just noticed that there is also a config/rcsetup.py. > Is there any reason why there has to be so much duplication (and now > gradual divergence) between this and the regular rcsetup.py? Is there > any reason the traits config system can't use the regular version, maybe > with some changes merged in? > > Eric > > - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] High quality downscaling of images
Dear developers,
matplotlib offers high quality interpolation filters which give
excellent results if you scale up an image. However, for downscaling an
image the results are worse. Depending on the precise scaling fine
details (e.g., thin horizontal lines, single pixel points) disappear and
aliasing effects are visible. After studying the source and the docs for
Agg I figured out how to improve this. Agg provides all possibilities,
just use them.
I attached a patch against the current svn version that adds a
'resample' argument to imshow. Additionally, this patch supports a
'image.resample' entry in the rc file. Setting this to false (default),
the behaviour is unchanged.
I also attached a simple test script (test_imshow.py) to show the
difference between image display with and without resampling. To see the
difference it might be necessary to zoom out.
Gregor Thalhammer
Index: src/_image.cpp
===
--- src/_image.cpp (Revision 5430)
+++ src/_image.cpp (Arbeitskopie)
@@ -426,11 +426,22 @@
case HAMMING: filter.calculate(agg::image_filter_hamming(), norm);
break;
case HERMITE: filter.calculate(agg::image_filter_hermite(), norm);
break;
}
- typedef agg::span_image_filter_rgba_2x2 span_gen_type;
- typedef agg::renderer_scanline_aa renderer_type;
- span_gen_type sg(ia, interpolator, filter);
- renderer_type ri(rb, sa, sg);
- agg::render_scanlines(ras, sl, ri);
+ if (resample)
+ {
+ typedef agg::span_image_resample_rgba_affine
span_gen_type;
+ typedef agg::renderer_scanline_aa renderer_type;
+ span_gen_type sg(ia, interpolator, filter);
+ renderer_type ri(rb, sa, sg);
+ agg::render_scanlines(ras, sl, ri);
+ }
+ else
+ {
+ typedef agg::span_image_filter_rgba_2x2 span_gen_type;
+ typedef agg::renderer_scanline_aa renderer_type;
+ span_gen_type sg(ia, interpolator, filter);
+ renderer_type ri(rb, sa, sg);
+ agg::render_scanlines(ras, sl, ri);
+ }
}
break;
case BILINEAR:
@@ -464,11 +475,22 @@
case LANCZOS: filter.calculate(agg::image_filter_lanczos(radius),
norm); break;
case BLACKMAN: filter.calculate(agg::image_filter_blackman(radius),
norm); break;
}
- typedef agg::span_image_filter_rgba span_gen_type;
- typedef agg::renderer_scanline_aa renderer_type;
- span_gen_type sg(ia, interpolator, filter);
- renderer_type ri(rb, sa, sg);
- agg::render_scanlines(ras, sl, ri);
+ if (resample)
+ {
+ typedef agg::span_image_resample_rgba_affine
span_gen_type;
+ typedef agg::renderer_scanline_aa renderer_type;
+ span_gen_type sg(ia, interpolator, filter);
+ renderer_type ri(rb, sa, sg);
+ agg::render_scanlines(ras, sl, ri);
+ }
+ else
+ {
+ typedef agg::span_image_filter_rgba span_gen_type;
+ typedef agg::renderer_scanline_aa renderer_type;
+ span_gen_type sg(ia, interpolator, filter);
+ renderer_type ri(rb, sa, sg);
+ agg::render_scanlines(ras, sl, ri);
+ }
}
break;
@@ -530,6 +552,20 @@
}
+char Image::get_resample__doc__[] =
+"get_resample()\n"
+"\n"
+"Get the resample flag."
+;
+
+Py::Object
+Image::get_resample(const Py::Tuple& args) {
+ _VERBOSE("Image::get_resample");
+
+ args.verify_length(0);
+ return Py::Int((int)resample);
+}
+
char Image::get_size_out__doc__[] =
"numrows, numcols = get_size()\n"
"\n"
@@ -593,6 +629,21 @@
}
+char Image::set_resample__doc__[] =
+"set_resample(boolean)\n"
+"\n"
+"Set the resample flag."
+;
+
+Py::Object
+Image::set_resample(const Py::Tuple& args) {
+ _VERBOSE("Image::set_resample");
+ args.verify_length(1);
+ int flag = Py::Int(args[0]);
+ resample = (bool)flag;
+ return Py::Object();
+}
+
static void write_png_data(png_structp png_ptr, png_bytep data, png_size_t
length) {
PyObject* py_file_obj = (PyObject*)png_get_io_ptr(png_ptr);
PyObject* write_method = PyObject_GetAttrString(py_file_obj, "write");
@@ -752,12 +803,14 @@
add_varargs_method( "buffer_rgba", &Image::buffer_rgba,
Image::buffer_rgba__doc__);
add_varargs_method( "get_aspect", &Image::get_aspect,
Image::get_aspect__doc__);
add_varargs_method( "get_interpolation", &Image::get_interpolation,
Image::get_interpolation__doc__);
+ add_varargs_method( "get_resample", &Image::get_resample,
Image::get_resample__doc__);
add_varargs_method( "get_size", &Image::get_size, Image::get_size__doc__);
add_varargs_method( "get_size_out", &Image::get_size_out,
Image::get_size_out__doc__);
add_varargs_method( "reset_matrix", &Image::reset_matrix,
Image::reset_matrix__doc__);
add_varargs_method( "get_matrix", &Image::get_matrix,
Image::get_matrix__doc__);
Re: [matplotlib-devel] High quality downscaling of images
On Mon, Jun 9, 2008 at 10:18 AM, > I attached a patch against the current svn version that adds a 'resample' > argument to imshow. Additionally, this patch supports a 'image.resample' > entry in the rc file. Setting this to false (default), the behaviour is > unchanged. Hi Gregor -- thanks for sending this. It's something I was aware of in agg but never got around to exposing. I wonder if the resample=True|False is the right approach. It might be nice for imshow to have an 'auto' mode to either resample or interpolate depending on the image dimensions w/ respect to the destination size. Ie, if we are displaying the full image into a small destination, 'auto' would default to resample. If we zoom in sufficiently, the image might be best displayed with interpolation. Is this something you think would be worthwhile and would you like to work on support for this? Also,l I notice the patch exposes span_image_resample_rgba_affine but not span_image_resample_rgba which takes an interpolator template argument. I know very little about this area, but was this a conscious choice or one of expediency? Can you explain the rational? JDH - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] automod doc warnings
Those of you who have been building the docs have probably seen the inscrutable table warnings coming from sphinx. I just got a clue where these are coming from. Look at the table formatting from this ipython session (in case your email client doesn't handle monospace right, the table border at the top is not indented right. Darren, I'll let you take this -- somewhere in the dedent/kwarg table interpolation, some spacing is getting botched. JDH class Arrow(Patch) | An arrow patch | | Method resolution order: | Arrow | Patch | matplotlib.artist.Artist | __builtin__.object | | Methods defined here: | | __init__(self, x, y, dx, dy, width=1.0, **kwargs) | Draws an arrow, starting at (x,y), direction and length | given by (dx,dy) the width of the arrow is scaled by width | | Valid kwargs are: |= == |PropertyDescription |= == |alpha float |animated[True | False] |antialiased or aa [True | False] |clip_boxa matplotlib.transform.Bbox instance |clip_on [True | False] |edgecolor or ec any matplotlib color |facecolor or fc any matplotlib color |figure a matplotlib.figure.Figure instance |fill[True | False] |hatch unknown |label any string |linewidth or lw float |lod [True | False] |transform a matplotlib.transform transformation instance |visible [True | False] |zorder any number |= == - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] Python novice stumped by ImportError
On Monday 09 June 2008 09:52:46 am John Hunter wrote: > On Mon, Jun 9, 2008 at 5:41 AM, Darren Dale <[EMAIL PROTECTED]> wrote: > > I think we would rather make traits an external dependency, if it could > > be easily installed as a separate package by a novice python user. Would > > it be possible for http://code.enthought.com/projects/traits/ to list > > specific instructions and links to the downloads? Or to list traits on > > the Python Package Index? > > I also agree that we should not install a modified version of traits > in the top level namespace. Let's disable all default installs of > enthought traits until we work this out. We only need it for the > optional rc config and so let's require that someone manually turn it > on in setup.cfg if they want it. In particular, let's fix this before > the next bugfix release. If we opt to depend on traits for the new > rc, we will either need to require and external dependency, figure out > a way to install a completely working and compatible version, or do > the extra work to install it inside the matplotlib namespace. I > prefer 1 or 3, but at this point I think whether we will migrate to > the traited rc system is an open question so disabling is the right > solution for now. > > Darren, can you take care of this? Its done. Gael, maybe the following situation caused the trouble: 1) user downloads mpl source 2) builds matplotlib - traits now exists in the temproary build directory 3) installs enthought traits 4) installs matplotlib - traits would not have been built in this case, its already installed on the system, but it still exists in the build directory and gets installed anyway. Seems unlikely, but who knows. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] Python novice stumped by ImportError
On Mon, Jun 09, 2008 at 12:04:58PM -0400, Darren Dale wrote: > Gael, maybe the following situation caused the trouble: > 1) user downloads mpl source > 2) builds matplotlib - traits now exists in the temproary build directory > 3) installs enthought traits > 4) installs matplotlib - traits would not have been built in this case, its > already installed on the system, but it still exists in the build directory > and gets installed anyway. Actually, after looking at the code and thinking a bit more, I think the problem might simply be with different version of traits installed in different directories in the sys.path, with Python's import mechanism picking up the MPL-installed one, rather then the user-installed one. Tricky problems that I see more and more happenning. But I don't have an example box to test this hypothesis, so we are still clueless. Cheers, Gaël - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] Python novice stumped by ImportError
On Mon, Jun 09, 2008 at 06:41:08AM -0400, Darren Dale wrote: > I think we would rather make traits an external dependency, if it could be > easily installed as a separate package by a novice python user. Would it be > possible for http://code.enthought.com/projects/traits/ to list specific > instructions and links to the downloads? Or to list traits on the Python > Package Index? If I get things correctly, having traits on PyPI is planned for the version 3 release, which should happen when the guys at Enthought find time to make it happen. However I cannot speak for them, as I am not employed by Enthought, sitting in Austin (Yet !). I will also be very happy the day this happens. Gaël - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] puzzle: interactive backend case with ipython
Andrew Straw wrote: > Hi Eric, > > show() isn't bringing up my plots with r5430 in normal scripts (i.e. not > using IPython). Sure enough. It seems that in the process of bisecting the svn versions to track down this problem and the original one you reported, things got mixed up in my directory, so that what worked on what I thought was the svn head was actually working on some mongrel. After a fresh checkout with clean build and install, I find that neither plain show nor ipython -pylab is working. Back to the drawing board. I really would like to get everything working with complete case-insensitivity, and lower-case defaults, for the backend names. There is no reason one should have to remember that it is TkAgg, not TKAgg, but GTKAgg, not GtkAgg. Eric > > -Andrew > > Eric Firing wrote: >> While investigating a bug pointed out by Andrew (and one that I had >> introduced some time ago) I found to my horror that I had also caused >> another bug: interactive plotting was not working with ipython -pylab. >> I backed out part of r5420, and that fixed the problem. This temporary >> fix is to restore the mixed case backend names in the interactive_bk >> list that is now set in rcsetup.py and imported by backends/__init__.py. >> >> I am baffled as to why this is needed at present; I have not been able >> to figure out why ipython threading seems to get confused when that list >> has lower case names for gtkagg, qtagg, and wxagg, but not for tkagg or >> qt4agg. I don't see anywhere in either the ipython or the mpl code that >> should care about the case of the names in that list, now that I have >> ensured that comparisons against backend names in mpl (everywhere I >> could find them--maybe I missed on) are case-insensitive, and >> get_backend() returns only lower case. rcParams['backend'] can still >> have mixed case, however. >> >> Any suggestions as to what I am missing or where to look? >> >> Related question: I just noticed that there is also a config/rcsetup.py. >> Is there any reason why there has to be so much duplication (and now >> gradual divergence) between this and the regular rcsetup.py? Is there >> any reason the traits config system can't use the regular version, maybe >> with some changes merged in? >> >> Eric >> >> - >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://sourceforge.net/services/buy/index.php >> ___ >> Matplotlib-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] High quality downscaling of images
John Hunter schrieb: > On Mon, Jun 9, 2008 at 10:18 AM, > > >> I attached a patch against the current svn version that adds a 'resample' >> argument to imshow. Additionally, this patch supports a 'image.resample' >> entry in the rc file. Setting this to false (default), the behaviour is >> unchanged. >> > > Hi Gregor -- thanks for sending this. It's something I was aware of > in agg but never got around to exposing. I wonder if the > resample=True|False is the right approach. It might be nice for > imshow to have an 'auto' mode to either resample or interpolate > depending on the image dimensions w/ respect to the destination size. > Ie, if we are displaying the full image into a small destination, > 'auto' would default to resample. If we zoom in sufficiently, the > image might be best displayed with interpolation. Is this something > you think would be worthwhile and would you like to work on support > for this? > If I understood it correctly, Agg (i.e., span_image_resample_*) already exactly behaves like you proposed. It resamples the image if the scaling is less than 1, otherwise it interpolates. > Also,l I notice the patch exposes span_image_resample_rgba_affine but not > span_image_resample_rgba which takes an interpolator template > argument. I know very little about this area, but was this a > conscious choice or one of expediency? Can you explain the rational? > > I am not an Agg expert. The documentation of Agg is not very exhaustive. I took it from one of the demos. span_image_resample_rgba_affine seems to be faster than span_image_resample_rgba, but it supports affine but no perspective transformations. If I understood it correctly, matplotlib only uses image translation and scaling, not even rotation or shearing. All this is covered by span_image_resample_rgba_affine. Gregor - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] High quality downscaling of images
On Mon, Jun 9, 2008 at 11:45 AM, Gregor Thalhammer > > If I understood it correctly, Agg (i.e., span_image_resample_*) already > exactly behaves like you proposed. It resamples the image if the scaling is > less than 1, otherwise it interpolates. > I am not an Agg expert. The documentation of Agg is not very exhaustive. I > took it from one of the demos. span_image_resample_rgba_affine seems to be > faster than span_image_resample_rgba, but it supports affine but no > perspective transformations. If I understood it correctly, matplotlib only > uses image translation and scaling, not even rotation or shearing. All this > is covered by span_image_resample_rgba_affine. OK, all this sounds reasonable. I've committed the changes to the trunk. Thanks for the explanation and the patch! JDH - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] automod doc warnings
On Monday 09 June 2008 11:48:30 am John Hunter wrote: > Those of you who have been building the docs have probably seen the > inscrutable table warnings coming from sphinx. I just got a clue > where these are coming from. Look at the table formatting from this > ipython session (in case your email client doesn't handle monospace > right, the table border at the top is not indented right. Darren, > I'll let you take this -- somewhere in the dedent/kwarg table > interpolation, some spacing is getting botched. Thanks. I hadn't noticed it before, and had to blow away the build/ to see the error. The artist.kwdocd['Patch'] at the top of patches.py needed a blank line above and below the table, its fixed now. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] puzzle: interactive backend case with ipython
Andrew Straw wrote: > Hi Eric, > > show() isn't bringing up my plots with r5430 in normal scripts (i.e. not > using IPython). Andrew, Please try now, with r5435 or later. There is still the underlying puzzle to be solved before all this can be cleaned up, but I think the basic functionality is back. Eric > > -Andrew > > Eric Firing wrote: >> While investigating a bug pointed out by Andrew (and one that I had >> introduced some time ago) I found to my horror that I had also caused >> another bug: interactive plotting was not working with ipython -pylab. >> I backed out part of r5420, and that fixed the problem. This temporary >> fix is to restore the mixed case backend names in the interactive_bk >> list that is now set in rcsetup.py and imported by backends/__init__.py. >> >> I am baffled as to why this is needed at present; I have not been able >> to figure out why ipython threading seems to get confused when that list >> has lower case names for gtkagg, qtagg, and wxagg, but not for tkagg or >> qt4agg. I don't see anywhere in either the ipython or the mpl code that >> should care about the case of the names in that list, now that I have >> ensured that comparisons against backend names in mpl (everywhere I >> could find them--maybe I missed on) are case-insensitive, and >> get_backend() returns only lower case. rcParams['backend'] can still >> have mixed case, however. >> >> Any suggestions as to what I am missing or where to look? >> >> Related question: I just noticed that there is also a config/rcsetup.py. >> Is there any reason why there has to be so much duplication (and now >> gradual divergence) between this and the regular rcsetup.py? Is there >> any reason the traits config system can't use the regular version, maybe >> with some changes merged in? >> >> Eric >> >> - >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://sourceforge.net/services/buy/index.php >> ___ >> Matplotlib-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] AttributeError: 'FigureCanvasWxAgg' object has no attribute 'SetInitialSize'
On Mon, 09 Jun 2008 07:41:05 -1000 Eric Firing <[EMAIL PROTECTED]> wrote: > Nils Wagner wrote: >> Hi Eric, >> >> I have still some trouble with the following example >>taken from openopt >> >> >> /usr/bin/python -i nlp_3.py >> starting solver ipopt (license: CPL) with problem nlp3 >> [PyIPOPT] Ipopt will use Hessian approximation. >> [PyIPOPT] nele_hess is 0 >> iterobjFunVallog10(maxResidual) >> 0 -1.640e+02 0.81 >> Traceback (most recent call last): >> File "nlp_3.py", line 65, in ? >> r = p.solve(solver) >> File >> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/BaseProblem.py", >> line 236, in solve >> return runProbSolver(self, solvers, *args, **kwargs) >> File >> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/runProbSolver.py", >> line 219, in runProbSolver >> solver(p) >> File >> "/usr/lib/python2.4/site-packages/scikits/openopt/solvers/CoinOr/ipopt_oo.py", >> >> line 70, in __solver__ >> p.iterfcn(p.x0) >> File >> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/BaseProblem.py", >> line 57, in >> self.iterfcn = lambda *args: ooIter(self, *args)# >>this parameter is >> only for OpenOpt developers, not common users >> File >> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/ooIter.py", >> line 78, in ooIter >> for df in p.graphics.drawFuncs: df(p) >> File >> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/ooGraphics.py", >> line 127, in oodraw >> if self.nSubPlots>1: pylab.subplot(self.nSubPlots, >>1, 1) >> File >>"/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", >>line >> 519, in subplot >> fig = gcf() >> File >>"/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", >>line >> 210, in gcf >> return figure() >> File >>"/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", >>line >> 195, in figure >> FigureClass=FigureClass, >> File >> "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wxagg.py", >> line 119, in new_figure_manager >> frame = FigureFrameWxAgg(num, fig) >> File >> "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wx.py", >> line 1237, in __init__ >> self.canvas.SetInitialSize(wx.Size(fig.bbox.width, >>fig.bbox.height)) >> AttributeError: 'FigureCanvasWxAgg' object has no >>attribute >> 'SetInitialSize' >> >> Any idea ? > > No clue. When did it stop working? > > [EMAIL PROTECTED]:~/programs/py/mpl/mpl_trunk/lib/matplotlib$ >rgrep SetInitialSize --include '*.py' . > ./backends/backend_wx.py: >self.canvas.SetInitialSize(wx.Size(fig.bbox.width, >fig.bbox.height)) > ./backends/backend_wx.py: >self.canvas.SetInitialSize(wx.Size(width, height)) > > I can't find anything in the code that defines >SetInitialSize. > I didn't check the example nlp_3.py (from openopt) regularly. So I can't tell you when it stopped. As a workaround I have used another backend in my matplotlibrc CONFIGURATION BEGINS HERE # the default backend; one of GTK GTKAgg GTKCairo FltkAgg QtAgg TkAgg # Agg Cairo GD GDK Paint PS PDF SVG Template #backend : WXAgg backend : TkAgg Cheers, Nils - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] Python novice stumped by ImportError
Darren Dale wrote: > I think we would rather make traits an external dependency, if it could be > easily installed as a separate package by a novice python user. Would it be > possible for http://code.enthought.com/projects/traits/ to list specific > instructions and links to the downloads? Or to list traits on the Python > Package Index? > We have now scheduled resources to finish the ETS refactoring that will allow us to release Traits 3, which means publishing it into PyPI. The effort won't start until next week at the earliest though. Even though I'm a bit gun-shy about doing this, I'd forecast we have Traits 3.0 officially released and on PyPI by the end of June, perhaps a week into July. -- Dave - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] Python novice stumped by ImportError
Gael Varoquaux wrote: On Mon, Jun 09, 2008 at 12:04:58PM -0400, Darren Dale wrote: Gael, maybe the following situation caused the trouble: 1) user downloads mpl source 2) builds matplotlib - traits now exists in the temproary build directory 3) installs enthought traits 4) installs matplotlib - traits would not have been built in this case, its already installed on the system, but it still exists in the build directory and gets installed anyway. Actually, after looking at the code and thinking a bit more, I think the problem might simply be with different version of traits installed in different directories in the sys.path, with Python's import mechanism picking up the MPL-installed one, rather then the user-installed one. Tricky problems that I see more and more happenning. But I don't have an example box to test this hypothesis, so we are still clueless. In my experience, the current method really only falls down for those trying to publish binary distributions who don't realize the potential consequences of this build-time detection, or that there is even a decision being made there about the content of what is being built. Say, perhaps those building EPD. :-) Luckily, once you know what is going on during the build, it's a pretty easy problem to solve. That said, given the upcoming release of Traits 3 this situation may get a little crazier. T2 and T3 are not fully api compatible, though they are very close. So I suspect version numbers are going to play a larger role in the future. Is there anything we can do in the T3 release to make resolution of this upcoming issue easier to deal with for the matplotlib team? One point probably worth mentioning is that, IIRC, we currently rely on T3 being installed with egg meta-data in order to determine an accurate version number. -- Dave - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] Python novice stumped by ImportError
Dave Peterson wrote: > That said, given the upcoming release of Traits 3 this situation may get > a little crazier. T2 and T3 are not fully api compatible, though they > are very close. So I suspect version numbers are going to play a > larger role in the future. Is there anything we can do in the T3 > release to make resolution of this upcoming issue easier to deal with > for the matplotlib team? One point probably worth mentioning is that, > IIRC, we currently rely on T3 being installed with egg meta-data in > order to determine an accurate version number. Whether, or to what extent, mpl starts depending on traits is still open; but if we do depend on it, I think we should simply require T3 as an external dependency. If that requires some slight modifications of Darren's code, which was written for T2, I expect the changes will be easy. Three questions: 1) To what extent would the range of T3 eggs cover the various platforms on which people run mpl? 2) For uncovered cases, should T3 be easy to build and install? 3) My recollection is that setuptools was determined to be causing a hit to the startup time, and mpl is already sluggish in starting up. Is there any more insight or progress on this front? Is there a way to use traits in mpl without increasing the startup time? I gather from the lists that we are still not out of the woods with respect to making mpl (and scipy, even more) easy to install, and ideally easy to build from svn, for nearly all users; I would not want to see us start depending on traits if this will make the present bad situation worse. Thanks. Eric - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] Python novice stumped by ImportError
Eric Firing wrote: > Dave Peterson wrote: > >> That said, given the upcoming release of Traits 3 this situation may >> get a little crazier. T2 and T3 are not fully api compatible, though >> they are very close. So I suspect version numbers are going to play >> a larger role in the future. Is there anything we can do in the T3 >> release to make resolution of this upcoming issue easier to deal with >> for the matplotlib team? One point probably worth mentioning is >> that, IIRC, we currently rely on T3 being installed with egg >> meta-data in order to determine an accurate version number. > > Whether, or to what extent, mpl starts depending on traits is still > open; but if we do depend on it, I think we should simply require T3 > as an external dependency. If that requires some slight modifications > of Darren's code, which was written for T2, I expect the changes will > be easy. > > Three questions: > > 1) To what extent would the range of T3 eggs cover the various > platforms on which people run mpl? Not quite sure on this one as I don't know what platforms are most used by mpl. What I can say is that we've worked very hard to minimize the dependencies Traits has on other things in order to make it as easy as possible for people to install. We'll definitely be uploading a source tarball, which should meet most people's needs, and a Windows binary (since not all users there have a c compiler.) We may or may not put up OS X, and a couple linux distribution, binaries. > 2) For uncovered cases, should T3 be easy to build and install? T3 proper needs a c compiler, gcc seems to work fine. TraitsGUI and the backend projects seem to be pure-python though clearly you'll need libs for the chosen backend. > 3) My recollection is that setuptools was determined to be causing a > hit to the startup time, and mpl is already sluggish in starting up. > Is there any more insight or progress on this front? Is there a way > to use traits in mpl without increasing the startup time? I'm not sure it was setuptools' egg features that were the problem so much as I thought it was the use of namespace packaging we have embedded all over in ETS. I don't see any significant efforts underway at this time that are trying to speed this up, but perhaps I'm just uninformed about any such efforts. I don't see anything on the horizon that would let us remove this from the ETS projects either. The end result is I don't see any way mpl could work around this and still treat Traits as an external dependency. -- Dave - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] AttributeError: 'FigureCanvasWxAgg' object has no attribute 'SetInitialSize'
On Sat, Jun 7, 2008 at 4:36 AM, Nils Wagner <[EMAIL PROTECTED]> wrote: > Hi all, > > I have some trouble with matplotlib's svn version. > Any pointer would be appreciated. > self.canvas.SetInitialSize(wx.Size(fig.bbox.width, > fig.bbox.height)) > AttributeError: 'FigureCanvasWxAgg' object has no > attribute 'SetInitialSize' This came from Stan's patch to fix figure sizing in wx. Nils, could you report your wx version, and Stan, could you see if there is a version problem in the SetInitialSize call? Thanks, JDH - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] Python nov ice stumped by ImportError
On Monday 09 June 2008 04:04:47 pm Dave Peterson wrote: > Eric Firing wrote: > > Dave Peterson wrote: > >> That said, given the upcoming release of Traits 3 this situation may > >> get a little crazier. T2 and T3 are not fully api compatible, though > >> they are very close. So I suspect version numbers are going to play > >> a larger role in the future. Is there anything we can do in the T3 > >> release to make resolution of this upcoming issue easier to deal with > >> for the matplotlib team? One point probably worth mentioning is > >> that, IIRC, we currently rely on T3 being installed with egg > >> meta-data in order to determine an accurate version number. > > > > Whether, or to what extent, mpl starts depending on traits is still > > open; but if we do depend on it, I think we should simply require T3 > > as an external dependency. If that requires some slight modifications > > of Darren's code, which was written for T2, I expect the changes will > > be easy. I think T2->T3 would not be a difficult transition for us. It may not even require any modifications, I seem to remember the traited config stuff just worked with traits3 last time I tried it, I just dont remember when I tried it last. > > Three questions: > > > > 1) To what extent would the range of T3 eggs cover the various > > platforms on which people run mpl? > > Not quite sure on this one as I don't know what platforms are most used > by mpl. What I can say is that we've worked very hard to minimize the > dependencies Traits has on other things in order to make it as easy as > possible for people to install. We'll definitely be uploading a source > tarball, which should meet most people's needs, and a Windows binary > (since not all users there have a c compiler.) We may or may not put up > OS X, and a couple linux distribution, binaries. > > > 2) For uncovered cases, should T3 be easy to build and install? > > T3 proper needs a c compiler, gcc seems to work fine. TraitsGUI and the > backend projects seem to be pure-python though clearly you'll need libs > for the chosen backend. > > > 3) My recollection is that setuptools was determined to be causing a > > hit to the startup time, and mpl is already sluggish in starting up. > > Is there any more insight or progress on this front? Is there a way > > to use traits in mpl without increasing the startup time? > > I'm not sure it was setuptools' egg features that were the problem so > much as I thought it was the use of namespace packaging we have embedded > all over in ETS. I don't see any significant efforts underway at this > time that are trying to speed this up, but perhaps I'm just uninformed > about any such efforts. I don't see anything on the horizon that would > let us remove this from the ETS projects either. The end result is I > don't see any way mpl could work around this and still treat Traits as > an external dependency. Fernando saw a big performance hit due to namespace packaging, but I never saw it. I think we concluded that the presence of large NFS mounts were causing the performance hit in namespace packages that Fernando reported at Scipy last year (Dave, was it you who worked with him?). I did some profiling a while back also, after we added traits to the mpl codebase and stripped out the namespace packaging. We still saw something like a 30% performance hit, which I tracked back to regular expressions being compiled in traits and in configobj. See: http://thread.gmane.org/gmane.comp.python.enthought.devel/10908/focus=10989 Darren - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] Python novice stumped by ImportError
Darren Dale wrote: On Monday 09 June 2008 04:04:47 pm Dave Peterson wrote: Eric Firing wrote: Dave Peterson wrote: That said, given the upcoming release of Traits 3 this situation may get a little crazier. T2 and T3 are not fully api compatible, though they are very close. So I suspect version numbers are going to play a larger role in the future. Is there anything we can do in the T3 release to make resolution of this upcoming issue easier to deal with for the matplotlib team? One point probably worth mentioning is that, IIRC, we currently rely on T3 being installed with egg meta-data in order to determine an accurate version number. Whether, or to what extent, mpl starts depending on traits is still open; but if we do depend on it, I think we should simply require T3 as an external dependency. If that requires some slight modifications of Darren's code, which was written for T2, I expect the changes will be easy. I think T2->T3 would not be a difficult transition for us. It may not even require any modifications, I seem to remember the traited config stuff just worked with traits3 last time I tried it, I just dont remember when I tried it last. Yes, the API breaks are not large at all. They're actually fairly small, the bulk of the effort on T3 was behind the scenes and added functionality. But there are some there so it may not be clear sailing for everyone. Three questions: 1) To what extent would the range of T3 eggs cover the various platforms on which people run mpl? Not quite sure on this one as I don't know what platforms are most used by mpl. What I can say is that we've worked very hard to minimize the dependencies Traits has on other things in order to make it as easy as possible for people to install. We'll definitely be uploading a source tarball, which should meet most people's needs, and a Windows binary (since not all users there have a c compiler.) We may or may not put up OS X, and a couple linux distribution, binaries. 2) For uncovered cases, should T3 be easy to build and install? T3 proper needs a c compiler, gcc seems to work fine. TraitsGUI and the backend projects seem to be pure-python though clearly you'll need libs for the chosen backend. 3) My recollection is that setuptools was determined to be causing a hit to the startup time, and mpl is already sluggish in starting up. Is there any more insight or progress on this front? Is there a way to use traits in mpl without increasing the startup time? I'm not sure it was setuptools' egg features that were the problem so much as I thought it was the use of namespace packaging we have embedded all over in ETS. I don't see any significant efforts underway at this time that are trying to speed this up, but perhaps I'm just uninformed about any such efforts. I don't see anything on the horizon that would let us remove this from the ETS projects either. The end result is I don't see any way mpl could work around this and still treat Traits as an external dependency. Fernando saw a big performance hit due to namespace packaging, but I never saw it. I think we concluded that the presence of large NFS mounts were causing the performance hit in namespace packages that Fernando reported at Scipy last year (Dave, was it you who worked with him?). Yes, he and I sat together in a sprint room at Scipy and refactored Traits code (and everything else using setuptools and namespace packages) until we removed it all, taking timing runs each step of the way. I'd actually be surprised if Fernando was using NSF mounts during this effort, but I don't remember asking. I do remember him pointing out how bad it *would* be for anyone using network drives to suffer through some of the API call counts we saw when using namespace packages. I did some profiling a while back also, after we added traits to the mpl codebase and stripped out the namespace packaging. We still saw something like a 30% performance hit, which I tracked back to regular expressions being compiled in traits and in configobj. See: http://thread.gmane.org/gmane.comp.python.enthought.devel/10908/focus=10989 I didn't intend to start up the root cause discussion again. :-) I only wanted to point out that I hadn't heard of anyone working on improving whatever performance problems exist / existed. -- Dave Darren - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] Python novice stumped by ImportError
On Monday 09 June 2008 6:22:28 pm Dave Peterson wrote: > I didn't intend to start up the root cause discussion again. :-) I only > wanted to point out that I hadn't heard of anyone working on improving > whatever performance problems exist / existed. I just wanted to avoid having a misperception turn into conventional wisdom. We see that enough in political discourse. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] puzzle: interactive backend case with ipython
On Mon, Jun 9, 2008 at 10:16 AM, Eric Firing <[EMAIL PROTECTED]> wrote:
> Please try now, with r5435 or later. There is still the underlying
> puzzle to be solved before all this can be cleaned up, but I think the
> basic functionality is back.
Eric: in Shell,py, around line 1167, you'll find this code:
backends = {'gthread' : 'GTKAgg',
'wthread' : 'WXAgg',
'qthread' : 'QtAgg',
'q4thread' :'Qt4Agg',
'tkthread' :'TkAgg',
}
That is used to SET the rcParams['backend'] value. I don't know if
that can cause issues.
But more importantly, I think the problem you see comes from this code
(just a bit later in the same file):
else:
backend = matplotlib.rcParams['backend']
if backend.startswith('GTK'):
th_mode = 'gthread'
elif backend.startswith('WX'):
th_mode = 'wthread'
elif backend.startswith('Qt4'):
th_mode = 'q4thread'
elif backend.startswith('Qt'):
th_mode = 'qthread'
else:
# Any other backend, use plain Tk
th_mode = 'tkthread'
return mpl_shell[th_mode]
IPython does an explicit check on the names of the backends with that
exact capitalization. I could add a .lower() call to the line that
starts:
backend = matplotlib.rcParams['backend'].lower()
and change the .startswith() calls to do all lowercase checks. Could
you see if that helps? That would make the fix backwards compatible.
Cheers,
f
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] Python novice stumped by ImportError
On Mon, Jun 9, 2008 at 3:22 PM, Dave Peterson <[EMAIL PROTECTED]> wrote: > Yes, he and I sat together in a sprint room at Scipy and refactored Traits > code (and everything else using setuptools and namespace packages) until we > removed it all, taking timing runs each step of the way. I'd actually be > surprised if Fernando was using NSF mounts during this effort, but I don't > remember asking. I do remember him pointing out how bad it *would* be for > anyone using network drives to suffer through some of the API call counts we > saw when using namespace packages. You are correct: I was NOT using an NFS mount, it was all done on my (slow) laptop. We were seeing enormous numbers (tens of thousands) of disc/directory access calls that I was very worried about if said disk was on NFS. Part of this was due to the fact that back at work in Colorado, I *did* have my $HOME on NFS and I'd recalled seeing some slowness here and there, but I never went back to repeat our profiling exercise at work, so I can't provide numbers on that. Cheers, f - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] puzzle: interactive backend case with ipython
Fernando Perez wrote:
On Mon, Jun 9, 2008 at 10:16 AM, Eric Firing <[EMAIL PROTECTED]> wrote:
Please try now, with r5435 or later. There is still the underlying
puzzle to be solved before all this can be cleaned up, but I think the
basic functionality is back.
Eric: in Shell,py, around line 1167, you'll find this code:
backends = {'gthread' : 'GTKAgg',
'wthread' : 'WXAgg',
'qthread' : 'QtAgg',
'q4thread' :'Qt4Agg',
'tkthread' :'TkAgg',
}
That is used to SET the rcParams['backend'] value. I don't know if
that can cause issues.
No, that is OK with old or svn versions of mpl.
But more importantly, I think the problem you see comes from this code
(just a bit later in the same file):
else:
backend = matplotlib.rcParams['backend']
if backend.startswith('GTK'):
th_mode = 'gthread'
elif backend.startswith('WX'):
th_mode = 'wthread'
elif backend.startswith('Qt4'):
th_mode = 'q4thread'
elif backend.startswith('Qt'):
th_mode = 'qthread'
else:
# Any other backend, use plain Tk
th_mode = 'tkthread'
return mpl_shell[th_mode]
Yes, I was looking for this sort of thing but managed to miss it
yesterday. This is where the problem is. The workaround that I have in
mpl svn now is to simply retain the mixed cases (although the input and
checking are completely case-insensitive). My suggested change for
ipython, so that some day mpl would not need to retain the mixed cases,
is in the attached diff against ipython svn. Fairly quick checks
against mpl svn, mpl svn with all lower case, and mpl maintenance branch
indicated that this change would be backwards and forwards compatible,
so long as mpl retains rcsetup.validate_backend().
It also makes it so that you could go to lower case in:
backends = {'gthread' : 'GTKAgg',
'wthread' : 'WXAgg',
'qthread' : 'QtAgg',
'q4thread' :'Qt4Agg',
'tkthread' :'TkAgg',
}
and this should also be backwards and forwards compatible; by using
validate_backend when setting the backend, one ensures that rcParams
gets a form that the particular version of mpl is happy with.
You might be able to use matplotlib.use(backends[th_mode]) to replace
the following in my suggested diff, provided you have not already
performed some magic that would foil the sys.modules checking done by
matplotlib.use():
backend = mrcsetup.validate_backend(backends[th_mode])
matplotlib.rcParams['backend'] = backend
The rationale for using "matplotlib.use" and "matplotlib.get_backend" is
that they can take advantage of validation that is not available when
you directly get and set the rcParams value. On the other hand there is
some appeal in the directness of going straight to/from rcParams.
Anyway, regardless of whether you decide to make any changes in ipython,
thanks for solving the puzzle.
Eric
IPython does an explicit check on the names of the backends with that
exact capitalization. I could add a .lower() call to the line that
starts:
backend = matplotlib.rcParams['backend'].lower()
and change the .startswith() calls to do all lowercase checks. Could
you see if that helps? That would make the fix backwards compatible.
Cheers,
f
Index: IPython/Shell.py
===
--- IPython/Shell.py(revision 3108)
+++ IPython/Shell.py(working copy)
@@ -1154,6 +1154,7 @@
try:
import matplotlib
+import matplotlib.rcsetup as mrcsetup
except ImportError:
error('matplotlib could NOT be imported! Starting normal
IPython.')
return IPShell
@@ -1163,16 +1164,17 @@
# threading backend, else it's auto-selected from the rc file
if special_opts:
th_mode = special_opts.pop()
-matplotlib.rcParams['backend'] = backends[th_mode]
+backend = mrcsetup.validate_backend(backends[th_mode])
+matplotlib.rcParams['backend'] = backend
else:
-backend = matplotlib.rcParams['backend']
-if backend.startswith('GTK'):
+backend = matplotlib.get_backend().lower()
+if backend.startswith('gtk'):
th_mode = 'gthread'
-elif backend.startswith('WX'):
+elif backend.startswith('wx'):
th_mode = 'wthread'
-elif backend.startswith('Qt4'):
+elif backend.startswith('qt4'):
th_mode = 'q4thread'
-elif backend.startswith('Qt'):
+elif backend.startswith('qt'):
th_mode = 'qthread'
else:
# Any other backend, use plain Tk
-
Re: [matplotlib-devel] puzzle: interactive backend case with ipython
On Mon, Jun 9, 2008 at 8:00 PM, Eric Firing <[EMAIL PROTECTED]> wrote: > Anyway, regardless of whether you decide to make any changes in ipython, > thanks for solving the puzzle. Thanks for providing a patch. I'll be mostly offline for a few days, but I'll add the fix in some form (the beauty of bzr...). It will show up in the ipython trunk probably by weekend. Cheers, f - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
