Re: [matplotlib-devel] Comparing pdf output in tests
On Wed, Sep 23, 2009 at 12:42 PM, Andrew Straw straw...@astraw.com wrote: Sorry, I should have been more clear. I was thinking that the image_compare() decorator would call the test function multiple times, having switched the backend between invocations. Thus, the call to savefig() would continue not to explicitly set the extension. I've quickly modified the source to reflect my idea, but I haven't had a chance to flesh it out or test it. It should show the idea, though. See attached. Why not have the decorator pass the extension in to the test funcs -- agg can print to pdf, ps, svg and png -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Comparing pdf output in tests
On Wed, Sep 23, 2009 at 12:56 PM, Andrew Straw straw...@astraw.com wrote:
John Hunter wrote:
On Wed, Sep 23, 2009 at 12:42 PM, Andrew Straw straw...@astraw.com wrote:
Sorry, I should have been more clear. I was thinking that the
image_compare() decorator would call the test function multiple times,
having switched the backend between invocations. Thus, the call to
savefig() would continue not to explicitly set the extension. I've
quickly modified the source to reflect my idea, but I haven't had a
chance to flesh it out or test it. It should show the idea, though. See
attached.
Why not have the decorator pass the extension in to the test funcs --
agg can print to pdf, ps, svg and png
I'm not sure what you're suggesting. Presumably if we're driving agg OK
to draw .png, it will also draw .pdf OK (or does it have a pdf vector
backend independent of the MPL pdf backend that we want to test separately?)
No, it doesn't have a separate backend, but the backend_agg figure
canvas savefig method knows how to create FigureCanvasPDF etc to use
that backend to write the file w/o having to switch the default
backend with all the attendant hassles. So if you are using *Agg, and
do
savefig(somefile.pdf)
agg will load the native pdf backend and use it. So I was envisioning
def test_something(ext):
make_plot
fig.savefig('myfile.%s'%ext)
and having the decorator pass in the extensions it wants one-by-one
JDH
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Fwd: OS X 10.6 port
in case anyone has some suggestions, I'm forwarding this from the sage list -- Forwarded message -- From: William Stein wst...@gmail.com Date: Sun, Sep 27, 2009 at 10:51 PM Subject: OS X 10.6 port To: sage-devel sage-de...@googlegroups.com, John Hunter jdh2...@gmail.com Hi, I spent several hours yesterday trying to get matplotlib for Sage to work on OS X 10.6. On my laptop everything works perfectly, but on another test machine (bsd.math) the workaround from my laptop doesn't work. So at this point Sage still does not support OS X 10.6. The problem is in matplotlib's C++ wrapper for freetype2. It's a Python extension module implemented directly in C++, and it simply doesn't work correctly at all. For example, whenever it tries to raise a Python exception, it just terminates Python with 11713 Abort trap sage-ipython $@ -i I'm cc'ing John Hunter -- author of matplotlib, in case he has any advice to share. In particular, he has an account on bsd.math.washington.edu and build tests matplotlib there, so I'm curious if he has any issues with that. Note that Sage builds freetype from source, which could be relevant. I will try updating freetype in Sage (our version is slightly out of date), and also checking if there is some sort of conflict with a system-wide freetype. My worry is that Matplotlib has some weird custom C++ code for writing extensions that maybe uses signals or something to raise exceptions, and it is just broken when used with OS X 10.6. Hopefully this is not that the case, and something special to Sage is happening. William -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [sage-devel] OS X 10.6 port
On Mon, Sep 28, 2009 at 4:47 AM, Dr. David Kirkby david.kir...@onetel.net wrote: William Stein wrote: Hi, I spent several hours yesterday trying to get matplotlib for Sage to work on OS X 10.6. On my laptop everything works perfectly, but on another test machine (bsd.math) the workaround from my laptop doesn't work. So at this point Sage still does not support OS X 10.6. Just to add (which I've also CC'ed to John), mathplotlib (at least the version in Sage), is not respecting CXX properly. I specified CC as the Sun C compiler, and CXX as the Sun C++ compiler. The code then tries to build a C++ file (src/ft2font.cpp) with the Sun C compiler, which fails. /opt/xxxsunstudio12.1/bin/cc -DNDEBUG -O -xcode=pic32 -DPY_ARRAYAUNIQUE_SYMBOL=MPL_ARRAY_API -I/export/home/drkirkby/sage/gcc32/sage-4.1.2.alpha2/local/lib/python2.6/site-packages/numpy/core/include -I/usr/sfw/include -I/usr/sfw/include/freetype2 -I/usr/local/include -I. -I/export/home/drkirkby/sage/gcc32/sage-4.1.2.alpha2/local/include/ -I/export/home/drkirkby/sage/gcc32/sage-4.1.2.alpha2/local/include/python2.6 -c src/ft2font.cpp -o build/temp.solaris-2.10-sun4u-2.6/src/ft2font.o cc: No valid input files specified, no output generated error: command '/opt/xxxsunstudio12.1/bin/cc' failed with exit status 1 I've not looked at this in detail, so it could be a Sage-specific issue. I forwarded the original message on to matplotlib-devel. It would be helpful if when replying to this message or any in this thread if we CC the matplotlib-devel mailing list. I'm the list moderator so I can approve these messages and you won't need to subscribe. I don't have any immediate answers for you now, but hopefully we can come up with some. JDH -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [sage-devel] OS X 10.6 port
On Mon, Sep 28, 2009 at 11:14 AM, John Hunter jdh2...@gmail.com wrote: But even simple tests are failing with:: jdh2...@bsd:~ LD_LIBRARY_PATH=~/devtest/lib/ PYTHONPATH=~/devtest/lib/python2.6/site-packages/ /usr/bin/python -c 'import matplotlib; matplotlib.use(Agg); from matplotlib.pyplot import *; plot([1,2,3]); savefig(test)' Traceback (most recent call last): File string, line 1, in module File /Users/jdh2358/devtest//lib/python2.6/site-packages/matplotlib/pyplot.py, line 7, in module from matplotlib.figure import Figure, figaspect File /Users/jdh2358/devtest//lib/python2.6/site-packages/matplotlib/figure.py, line 16, in module import artist File /Users/jdh2358/devtest//lib/python2.6/site-packages/matplotlib/artist.py, line 6, in module from transforms import Bbox, IdentityTransform, TransformedBbox, TransformedPath File /Users/jdh2358/devtest//lib/python2.6/site-packages/matplotlib/transforms.py, line 34, in module from matplotlib._path import affine_transform ImportError: /Users/jdh2358/devtest/lib/python2.6/site-packages/matplotlib/_path.so: no appropriate 64-bit architecture (see man python for running in 32-bit mode) I'm attaching my build output in case anyone sees anything that might be triggering this 32bit/64bit problem (see attached for full output). I did not rebuild numpy and this may be the problem since the failure is in the _path module. I'll give that a try next Same issue with numpy HEAD -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Comparing pdf output in tests
On Fri, Oct 2, 2009 at 12:27 AM, Andrew Straw straw...@astraw.com wrote: I just installed gs on one of the buildbots -- so at least the .pdf generation should get tested on one machine. (The one running the py24 and py25 tests.) The OSX build bot has been down ever since the build machine was upgraded to 10.6. Unfortunately, this has triggered some build and runtime problems for mpl that I haven't been able to crack yet. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] AutoDateFormatter/AutoDateLocator
On Wed, Oct 14, 2009 at 2:16 PM, Ryan May rma...@gmail.com wrote: Hi, Anybody know what the status of AutoDateLocator/AutoDateFormatter in matplotlib.dates are? They work and seem reasonably well documented. However, they do not show up in our online docs: http://matplotlib.sourceforge.net/api/dates_api.html They show up in the inheritance graph, but are not mentioned elsewhere in the page and in fact have no link from the image. They're also not present in the __all__ in the dates module. If this is just an oversight, what do I need to do to make the classes show up in the docs? Most likely this is just due to an oversight in the __all__ so just add it there in the branch and it should get picked up next time we build the docs JDH -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] AutoDateFormatter/AutoDateLocator
On Wed, Oct 14, 2009 at 3:47 PM, Ryan May rma...@gmail.com wrote: On Wed, Oct 14, 2009 at 3:08 PM, John Hunter jdh2...@gmail.com wrote: Most likely this is just due to an oversight in the __all__ so just add it there in the branch and it should get picked up next time we build the docs Done. I also added them to the module-level docstring. Along these lines, I was trying to make use of AutoDateLocator, and as far as I can tell, there's no way to customize its behavior right now. So when trying to use this for doing major and minor ticks, there's no difference. It looks like in the get_locator() method of AutoDateLocator, numticks is used to control what types of ticking (yearly, monthly) is used. Would it make sense to have this as an attribute of self so that the user can tweak it? Or maybe go to: 1) minticks (instead of numticks) which specifies a minimum number of ticks that are desired, to select yearly, monthly, etc. 2) maxticks, which specifies a maximum number of ticks, which can be used to calculate the interval (every N'th month). Right now, the rules for selecting this are hard coded. I'm interested in hacking this up. But since you wrote the code, I want to make sure that going this direction makes sense to you. I don't have a strong opinion on this -- making it more customizable is a good thing -- this came up at scipy as well, where I contributed a patch to make the AutoDateFormatter a little more customizable by exposing a scaled dictionary mapping the scale to a format string. As long as the extension to the AutoDateLocator preserves the core functionality, I say have at it. JDH -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] Source tarball should not include setup.cfg (was: 0.99.1.1 build attempts to import non-existing wx)
On Wed, Oct 28, 2009 at 1:09 AM, Jouni K. Seppänen j...@iki.fi wrote: This is because the distribution includes a setup.cfg file by mistake. Deleting setup.cfg should allow the autodetection logic to disable building wxagg. This is bug #2871530 on Sourceforge: https://sourceforge.net/tracker/?func=detailaid=2871530group_id=80706atid=560720 I suggest we release a 0.99.1.2, possibly with just this bug fixed, since this problem keeps being reported on the mailing lists. My OSX build machine died recently so would take some time. Perhaps we should just upload a 0.99.1.1 tarball only to the sf site? Earlier I tried deleting 0.99.1 and reuploading, and it apparently worked on the one mirror I tested, but clearly it did not propagate through. JDH -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Layout of subplots in output
2009/11/1 Stéfan van der Walt ste...@sun.ac.za: 2009/10/31 Eric Firing efir...@hawaii.edu: You forgot the attachment. I hate it when that happens -- here it is! Hey Stéfan, To avoid the overlap on the titles and ticks, you will want to play with the font size of the ticks and title, but most importantly the subplots_adjust parameters hspace and wspace. If using a suptitle, you may also want to adjust top. Eg, # you can also click on the subplots adjust toolbar icon to play with the # settings to get something that looks right and then hard code this fig.subplots_adjust(hspace=0.4, wspace=0.4) for ax in ax1, ax2, ax3, ax4: ax.title.set_fontsize(11) for label in ax.get_xticklabels() + ax.get_yticklabels)(): label.set_fontsize(9) You can also use rc parameters to control the defaults: http://matplotlib.sourceforge.net/users/customizing.html JDH -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Closing paths in PolyCollection
On Mon, Nov 2, 2009 at 4:59 PM, Matthew West mw...@illinois.edu wrote: Hi, The PolyCollection class currently closes the path for each polygon by adding a last point the same as the first point. This means that the line joins will be different on this point. I've submitted a patch to make PolyCollection use Path.CLOSEPOLY to close the path, which makes the line joins on the stroking correct. See https://sourceforge.net/tracker/?func=detailaid=2890979group_id=80706atid=560722 There is also a small test script and the current and expected output attached to the above tracker entry. Please let me know if there is some other way this should be fixed. Project Admin Hide I attempted to apply this but it triggered three regression test failures -- this may be simply because the regression test is expecting a different number of verts in the simplification tests, but I am going to assign this to Michael, who wrote the tests, so he can update the tests and the patch at the same time For future patches, if possible, please submit an svn diff as these are easier to apply. Thanks, JDH == FAIL: matplotlib.tests.test_simplification.test_noise -- Traceback (most recent call last): File /opt/app/g++lib6/python-2.4.5/lib/python2.4/site-packages/nose-0.10.4-py2.4.egg/nose/case.py, line 182, in runTest self.test(*self.arg) File /home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/tests/test_simplification.py, line 72, in test_noise assert len(simplified) == 2675 AssertionError == FAIL: matplotlib.tests.test_simplification.test_sine_plus_noise -- Traceback (most recent call last): File /opt/app/g++lib6/python-2.4.5/lib/python2.4/site-packages/nose-0.10.4-py2.4.egg/nose/case.py, line 182, in runTest self.test(*self.arg) File /home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/tests/test_simplification.py, line 89, in test_sine_plus_noise assert len(simplified) == 628 AssertionError == FAIL: matplotlib.tests.test_simplification.test_start_with_moveto -- Traceback (most recent call last): File /opt/app/g++lib6/python-2.4.5/lib/python2.4/site-packages/nose-0.10.4-py2.4.egg/nose/case.py, line 182, in runTest self.test(*self.arg) File /home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/tests/test_simplification.py, line 166, in test_start_with_moveto assert segs[0][1] == Path.MOVETO AssertionError -- Ran 107 tests in 74.927s FAILED (KNOWNFAIL=34, errors=3, failures=3) -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Layout of subplots in output
2009/11/3 Stéfan van der Walt ste...@sun.ac.za: Hi JJ 2009/11/2 Jae-Joon Lee lee.j.j...@gmail.com: I now think this is not the dpi issue. Can you check the size of your figure in mac os X backend, after the plot is drawn? print f.get_size_inches() 8x6 inch is the default. It says [4, 2.52], so I think you are right! So, my recommendation is to use smaller dpi for screen display (default is something like 80), and increase the dpi when saving the figure (savefig has a dpi parameter). This fixes the problem. Now, why does the MacOSX end do this when none of the others do? Thanks for helping me track this down! Perhaps you can file a bug report on the tracker so Michiel can look into it? Thanks, JDH -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] imshow zorder (patch for review)
On Mon, Nov 9, 2009 at 10:21 AM, Andrew Straw straw...@astraw.com wrote: Hi All, I have addressed what I think is a long-standing wart: zorder is mostly ignored for imshow(). (See e.g. http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314 ) The question is whether I should apply the attached patch. Will this help with the OP's original wart, which was the inability to add multiple images and move one to the top with zorder. Your patch is only applied when len(images)=1 or renderer.option_image_nocomposite(), both of which will be False when using Agg with multiple images, no? JDH -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] imshow zorder (patch for review)
On Mon, Nov 9, 2009 at 12:12 PM, Jae-Joon Lee lee.j.j...@gmail.com wrote: On Mon, Nov 9, 2009 at 1:01 PM, John Hunter jdh2...@gmail.com wrote: Your patch is only applied when len(images)=1 or renderer.option_image_nocomposite(), both of which will be False when using Agg with multiple images, no? I believe renderer.option_image_nocomposite() is True for the agg backend. So, it will work with agg. Ahh, you're right. Thanks. JDH -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] imshow zorder (patch for review)
On Mon, Nov 9, 2009 at 12:16 PM, Andrew Straw straw...@astraw.com wrote: So now the question for me is what is this option_image_nocomposite is so that I can generalize the patch to both when it's True and False. From the The compositing is in support of things like pylab_examples/layer_images.py, where two images, possibly of different sizes, are composited together -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Failed build: src/_macosx.m:1:25: error: Cocoa/Cocoa.h: No such file or directory
On Mon, Nov 9, 2009 at 1:29 PM, Leonid Petrov m...@lpetrov.net wrote: Hi, matplotlibers, I tried to compile matplotlib0.99.1.1 against Python-2.6.4, numpy-1.3.0, libpng-1.2.40, freetype-2.3.11 with the following command: python setup.py install --prefix=/opt64 comp.log I got building 'matplotlib.backends._macosx' extension /opt64/bin/gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/opt64/include -I/opt64/include/wx-2.8 -I/opt64/lib/wx/include/gtk2-ansi-release-2.8 -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -I/opt64/lib/python2.6/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/opt64/lib/python2.6/site-packages/numpy/core/include -Isrc -Iagg24/include -I. -I/opt64/include/python2.6 -c src/_macosx.m -o build/temp.linux-x86_64-2.6/src/_macosx.o src/_macosx.m:1:25: error: Cocoa/Cocoa.h: No such file or directory src/_macosx.m:2:53: error: ApplicationServices/ApplicationServices.h: No such file or directory src/_macosx.m:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'style' I checked, I have neither Cocoa.h , nor ApplicationServices.h in my system ( Linux 2.6.28-16-generic #55-Ubuntu SMP ). I have no idea to which package headers Cocoa.h and ApplicationServices.h belong. Which additional source packages, not mentioned in http://matplotlib.sourceforge.net/users/installing.html, should I download and compile in order to build matplotli For some reason mpl is trying to build the macosx backend (for OSX) even though you are on linux. Please do a clean build (rm -rf build) and capture all stdout and stderr into a file when rebuilding and post it. Also see if you have a setup.cfg file in your mpl dir next to setup.py and post it. Finally, where did you get the mpl src from? JDH -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Failed build: src/_macosx.m:1:25: error: Cocoa/Cocoa.h: No such file or directory
On Mon, Nov 9, 2009 at 3:08 PM, Leonid Petrov m...@lpetrov.net wrote: Hi, John, I got mpl from http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.1/matplotlib-0.99.1.1.tar.gz/download /d1/incoming md5sum matplotlib-0.99.1.1.tar.gz bd0894dd924eb5bec84c42d26041a544 matplotlib-0.99.1.1.tar.gz I removed source code of matplotlib-0.99.1.1 from my previous attempt to install it and did it again. cd /d1/dist tar -zxf /d1/incoming/matplotlib-0.99.1.1.tar.gz cd matplotlib-0.99.1.1/ python setup.py install --prefix=/opt64 matplotlib-0.99.1.1_comp.log gzip matplotlib-0.99.1.1_comp.log cp matplotlib-0.99.1.1_comp.log.gz /pub/ cp setup.cfg /pub/matplotlib-0.99.1.1_comp.log.gz cp /d1/incoming/matplotlib-0.99.1.1.tar.gz /pub/ You can get them from ftp://71.178.13.84/matplotlib-0.99.1.1_comp.log ftp://71.178.13.84/matplotlib-0.99.1.1.tar.gz ftp://71.178.13.84/matplotlib-0.99.1.1_setup.cfg But stop, stop, stop... I looked at setup.cfg and found there at line 58 macosx = True Glad you found the fix -- I'm just uploaded a new tarball now with the setup.cfg removed. JDH -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 3D Axes scatter : no possibility to vary color/size of markers
On Thu, Nov 19, 2009 at 6:02 AM, Ensitof ensieta.le...@gmail.com wrote: I got the same problem and posted my question in this forum http://www.developpez.net/forums/d836964/autres-langages/python-zope/calcul-scientifique/matplotlib-scatter3d-colorisation-fonction-z/ (here) a few days ago... My question receives a lot of visits but no reaction however I think it may be an important information for people wanting to use matplotlib efficiently. Please let me know if you can find anything about it :confused: Even if everything works perfect with 2D scatter I can't solve this issue with scatter3D. Knowing that's it's a bug should already be a nice answer... Please file a bug on the tracker and I will assign it to Reinier http://sourceforge.net/tracker/?atid=560720group_id=80706func=browse Thanks, JDH -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [PATCH] experimental numscons support in matplotlib
On Wed, Nov 25, 2009 at 10:52 AM, Andrew Straw straw...@astraw.com wrote: Also, would you like svn commit access? That may just make things easier -- John, what do you think? I think we can trust David. :) Absolutely -- send me an svn login and I can add him to the list of committers if he wants to, else we can manage his patches. JDH -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [PATCH] experimental numscons support in matplotlib
On Wed, Nov 25, 2009 at 10:57 AM, John Hunter jdh2...@gmail.com wrote: On Wed, Nov 25, 2009 at 10:52 AM, Andrew Straw straw...@astraw.com wrote: Also, would you like svn commit access? That may just make things easier -- John, what do you think? I think we can trust David. :) Absolutely -- send me an svn login and I can add him to the list of committers if he wants to, else we can manage his patches. svn login means sourceforge id JDH -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Z-Order Sorting
On Tue, Dec 1, 2009 at 6:21 PM, Eric Firing efir...@hawaii.edu wrote: This is easy to fix by using the key kwarg (added in python 2.4) of the sort method, because python uses a stable sort. It looks like it only needs to be fixed in Axes.draw, because Figure.draw has never paid any attention to zorder anyway. I'll do it now. It does now in svn HEAD -- I just added this yesterday. JDH -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] matplotlib book -- free copy for developers
Packt is offering a free copy of Sandro Tosi's new book Matplotlib for Python Developers to matplotlib developers, and has generously offered to donate 2% of book sales to the mpl project. If you are an svn committer and would like a copy of the book, send me your name and shipping address offlist and I will pass it on to the publisher. http://www.amazon.com/Matplotlib-Python-Developers-Sandro-Tosi/dp/1847197906/ref=sr_1_1?ie=UTF8s=booksqid=1260986058sr=8-1 JDH -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] notes on Windows 7 cygwin 1.7 installation
On Sun, Dec 20, 2009 at 4:19 PM, Glen Nixon glen.ni...@gmail.com wrote: Hi all. With some effort, I've managed to get matplotlib-0.99.1.1 with cygwin 1.7 (beta) on Windows 7. Since Google didn't turn up any instructions specifically addressing the problems I had, maybe these notes will be helpful to others. FYI, we have a Makefile in release/win32/ in the svn repo which we use for building mpl under cygwin. Haven't tried it under Windows 7, but ideally we like to codify all the Windows/Cygwin specific build info in a Makefile to smooth the path for the next person. So you may want to try this and/or submit patches against it if you have time. Thanks, JDH -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] auto range limits for spines: please kick the tires
On Mon, Dec 21, 2009 at 3:46 PM, Andrew Straw straw...@astraw.com wrote: John also suggested something like this. I don't think it's impossible, but it's outside the scope of the work I have done and beyond my immediate familiarity with the code base. I think it would involve looking at the tick label bounding boxes, finding overlaps, and then deciding which label was less important and removing it. I don't think it would be impossible, and maybe not even hard, but I haven't investigated at all. Thanks for keeping it on the queue. One easy-ish approach would be to do this at the Axes layer, which knows all the Axis contained within. We could have some property like hide_tick_overlaps and have a zorder on the axis, so if an axis is above another, and any of the lower axis ticks overlap any of the above ticks, then the lower ticks would be rendered invisible giving the user some control of which get shown. This would probably need to be a draw time operation, with something like a before_draw_hook handling the visibility and an after_draw_hook restoring the default visibility. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] doc build problem with axes_grid
On Sat, Jan 2, 2010 at 12:34 AM, Eric Firing efir...@hawaii.edu wrote: Jae-Joon Lee wrote: The error happens because of the *.rst files under doc/examples that are not in sync with examples/*.py. Removing that directory (doc/examples) will solve the problem (the directory will be repopulated when you run make.py again). Here is a related link. http://old.nabble.com/python-make.py-html-failure-tt26894350.html Thank you for the quick response. That was it, exactly. There are still some example script failures, but nothing that stops the build in its tracks. Maybe we need something like python make.py clean? Yes, if the generated files can't all land in the build directory (as would seem preferable), then the next-best thing would be to have make.py able to do a thorough cleaning. I just do svn-clean whenever I have a problem http://svn.collab.net/repos/svn/trunk/contrib/client-side/svn-clean JDH -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Enhancement to matplotlib's PyQt4 backend
On Sun, Jan 3, 2010 at 2:41 PM, Gökhan Sever gokhanse...@gmail.com wrote: You seemed like forgetting to check-in the qt4_editor_options.svg, because I get file not found error: I[2]: Cannot open file '.../matplotlib/lib/matplotlib/mpl-data/images/qt4_editor_options.svg', because: No such file or directory Oops, just added. Thanks for the head's up. JDH -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] define color cycle in matplotlibrc
On Sun, Jan 3, 2010 at 2:39 PM, Eric Firing efir...@hawaii.edu wrote: 1) Should the the color_cycle be in the axes group? Although it affects lines, it is defined only at the Axes level, and affects only lines drawn by plot. Alternative: since it affects only plot, should there be a new plot group to make that explicit, so it would be rcParams['plot.color_cycle']? I think it is better to do at the Axes level, because even if plot is the only command to do this now, I could imagine others commands wanting to use it (fill_between, bar?). I have had people asking me just for access to the list so they could use it for some purpose or another, so having the list easily accessible is desirable. 2) It was pointed out that there is a strange connection between the color cycle and the lines.color rcParam. This connection looks to me like a bit of legacy that can be dropped with little risk of pain in user land, since the default would still be to have the initial color in the cycle (blue) be the same as the default lines.color (blue). The proposed difference is that setting lines.color would have no effect on the color_cycle, and vice-versa. John, I think the present connection dates all the way back to your work around svn r500 or so; please tell me if there is some compelling reason to keep it. It appears to me that breaking the connection would make both the code and the actual mpl behavior simpler and less surprising, with no loss of useful functionality. I think deprecating lines.color and making the first element of the cycle be the default color makes the most sense. 3) Would it make sense to add color_cycle to the Axes API, so that it can be set directly for a given axes as an alternative to going through the rc mechanism? Right now it can be set via a function, but must be set before Axes creation; this doesn't make sense to me. It would make more sense as an Axes property that could be set at any time, and would apply to subsequent calls to plot. It might be best to make this a class level attribute, that way people can tweak it globally or at the instance level, and have access to the list *before* the Axes instance is created. The downside of this is it falls outside of the usual properties pattern that people can access via the normal introspection facilities. The linestyles cycle question is as you say a good bit harder, and would best be served by having some sort of configurable color scheme, where one could set grayscale or something like that to get default black/white/gray colors and styles for the cycle. JDH -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] define color cycle in matplotlibrc
On Sun, Jan 3, 2010 at 3:54 PM, Eric Firing efir...@hawaii.edu wrote: The only problem is that lines.color is the default for LineCollection and Line2D, both of which are fairly separate from Axes, so having them default to rcParams['axes.color_cycle'][0] seems a little odd. Yes, I was worrying about the same thing while cooking dinner :-) A line can be added to a Figure or an Axes, so perhaps the default color should not come from there. What about a module level attribute matplotlib.colors.cycle by an rc param colors.cycle and then the default Line2D and LineCollection color can default to matplotlib.colors.cycle[0]. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Enhancement to matplotlib's PyQt4 backend
On Mon, Jan 11, 2010 at 11:53 AM, Gökhan Sever gokhanse...@gmail.com wrote: On Mon, Jan 11, 2010 at 11:09 AM, Pierre Raybaut cont...@pythonxy.com wrote: John, Following to your last commit on added qt4_editor dialog (rev 8064), here is a significant (but simple) improvement adding an Apply button to the option dialog box (very convenient) -- suggested by Gökhan. (attached diff files should patch formlayout.py and figureoptions.py as in rev. 8064) One minor update: After patching these two files, just change the 'options.svg' in figureoptions.py to qt4_editor_options.svg to suppress the icon not found error message. Hey Gökhan, if you could just create an svn diff with the original patches applied and your changes it will be easiest for me to apply that way. JDH -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] problems with svnmerge
I just committed Ariel's csd changes to the 99 branch, and when I attempted to merge I first got a failure and now the branch is not showing up in the available branches. Any ideas? The branch was listed on a 'svnmerge.py merge' command *before* the failure. jdhun...@uqbar:mpl svnmerge.py merge /home/jdhunter/dev/bin/svnmerge.py:71: DeprecationWarning: The popen2 module is deprecated. Use the subprocess module. import sys, os, getopt, re, types, tempfile, time, popen2, locale svnmerge: multiple sources found. Explicit source argument (-S/--source) required. The merge sources available are: /branches/v0_99_maint /branches/mathtex jdhun...@uqbar:mpl svnmerge.py merge -Sv0_99_maint /home/jdhunter/dev/bin/svnmerge.py:71: DeprecationWarning: The popen2 module is deprecated. Use the subprocess module. import sys, os, getopt, re, types, tempfile, time, popen2, locale property 'svnmerge-integrated' set on '.' svnmerge: command execution failed (exit code: 1) svn --non-interactive propdel svnmerge-blocked . svn: Attempting to delete nonexistent property 'svnmerge-blocked' jdhun...@uqbar:mpl svnmerge.py merge -Sv0_99_maint /home/jdhunter/dev/bin/svnmerge.py:71: DeprecationWarning: The popen2 module is deprecated. Use the subprocess module. import sys, os, getopt, re, types, tempfile, time, popen2, locale svnmerge: v0_99_maint is neither a valid URL, nor an unambiguous substring of a repository path, nor a working directory jdhun...@uqbar:mpl svnmerge.py merge /home/jdhunter/dev/bin/svnmerge.py:71: DeprecationWarning: The popen2 module is deprecated. Use the subprocess module. import sys, os, getopt, re, types, tempfile, time, popen2, locale svnmerge: multiple sources found. Explicit source argument (-S/--source) required. The merge sources available are: /branches/v0_91_maint /branches/mathtex /branches/v0_98_5_maint -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Spelling errors in the documentation
On Tue, Feb 16, 2010 at 3:51 AM, Philipp Bender li...@rootiniert.de wrote: Hi, because Wayne Watson complained in -users repeatedly about spelling errors without fixing or really pointing us to them I tried to find some in the chapter he mentioned and fixed them. Because I am not a native speaker I hope I did not correct already correct things. I attached the diff file. Please watch it _only_ if you have the time left, it's *really* no big thing. Thanks Phillip for taking the time to convert this doc bug report from the users list into a proper patch. Many of the usages of axes that Wayne flagged as incorrect in his original report are actually correct, so some of the patch is not correct but I understand you were just converting his report into a usable patch. But there were a couple of fixes in the patch that were worth applying so I made these in svn HEAD. PS: Sphinx is great, good decision! Yes, it's been great. We've developed a number of extensions, notably the ipython and plot directives, that make writing documentation very natural and easy, and overall I've been very happy with sphinx. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Wed, Feb 17, 2010 at 8:29 PM, Fernando Perez fperez@gmail.com wrote: On Wed, Feb 17, 2010 at 7:27 PM, David Warde-Farley d...@cs.toronto.edu wrote: An effusive yes, yes, good god yes! from this mpl-devel lurker. Thanks, that's two good pluses. Any suggestions on name changes, or other fixes to make? Otherwise, once I find a free minute I'll put it in. I think the name figsubplots or fig_subplots is better because you are creating Subplot instances. Alternatively, you might want to consider simply subplots which returns just the list of subplots: the figure can always be accessed as an attribute of the Subplot instance:: ax1, ax2, ax2, ax4 = subplots(2,2) fig = ax1.figure Not sure that this is better; just a thought. Should it go into pyplot directly, or elsewhere and imported from pyplot to expose it at the top-level? (I'm not overly familiar with the layout of the whole library). pyplots is the right place for it since it is implicitly creating a current figure and the only place where that magic happens is in pyplot. I'm also trying to show my students how *they* can improve their tools; e.g. earlier this week a homework problem I wrote up led me to a useful sympy patch that was quickly upstreamed: This is a worthy goal.One use case I would like to see supported is the sharex/sharey args:: ax1 = fig.add_subplot(211) ax2 = fig.add_subplot(212, sharex=ax1) If there is not an easy way to specify the shared axes with figaxes or whatever it is called, I would not use it too often, because my common case is multiple rows of subplots with a common x-axis. One thing that will be nicer with the suggested patch is it makes it easier to change a script where the subplot layout goes from 211 to 311 to 411 (this happens to me all the time as I find I want to plot more stuff for a give time series). I have to change all the 311, 312, 313 to 411, 412, 413, and with your patch it would be a simple change in one line from:: ax1, ax2, ax3 = subplots(3,1) to:: ax1, ax2, ax3, ax4 = subplots(4,1) Perhaps the solution to my sharex conundrum is to support an axes number, eg ax1, ax2, ax3, ax4 = subplots(4,1, sharex=1) so all the subplots would have sharex with ax1. JDH JDH -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Wed, Feb 17, 2010 at 10:50 PM, Fernando Perez fperez@gmail.com wrote: This is a worthy goal. One use case I would like to see supported is the sharex/sharey args:: Sheesh, some people really want everything :) Yes, you should know better by now than to propose a minor enhancement Another thought about the interface. How about *just* returning the figure instance, and let the users simply index into the axes list. Then they can have their 0 based indexing because it is a python list:: fig = fig_subplot((2,1), sharex=1) fig.axes[0].plot(...) fig.axes[1].scatter(...) mpl is creating this axes list anyway I'm also fine with your implementation -- just a suggestion. One other thing: I don't think a tuple is best for the axes dimensionality. We always require two and exactly two shape arguments (numrows, numcols) so we don't need the flexibility of the tuple in the way that numpy.zeros does. And it is easier to type:: fig_subplot(2, 1, sharex=1) than:: fig_subplot((2,1), sharex=1) As the world master of keystroke efficiency, I would think you would appreciate the savings! But again, if you prefer the tuple, I don't have a problem with it. It does have the advantage of visually suggesting a single shape argument. JDH -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch submission - rectangle selector button select
On Tue, Feb 23, 2010 at 10:22 AM, Ben Axelrod baxel...@coroware.com wrote: Here is a patch for a new feature for the rectangle selector. it allows the user to specify which mouse button or buttons to use for the rectangle selection. Also included in the diff is a one line change to the rectangle_selector example code to demonstrate the use of the feature. Thanks, committed this. Renamed useBtn to simply button. JDH -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration
On Tue, Mar 2, 2010 at 11:41 PM, Eric Firing efir...@hawaii.edu wrote: Andrew Straw wrote: [...] This is a good point. My preferred option is that we jettison all the stuff that is not going to be shipped with MPL 1.0 from the git repo. (More correctly - we build a git repo without that stuff ever going in.) We can keep the old svn tree around and migrate the other projects to git as desired. I think this is what's present in http://github.com/astraw/matplotlib . Or am I missing something? No, that is what you have, and I agree that this strategy makes sense. I just wanted to make sure everyone understood, and make the plan explicit. It looks like Andrew has trunk/matplotlib. There is other stuff in trunk that definitely should not be migrated, and some stuff that needs consideration. * trunk/py4science, which is a project Fernando and I have been working on for several years but is not specific to mpl (it only uses mpl). We will eventually migrate this into it's own repo, but this is not an mpl project and should not be migrated. * trunk/course - looks like a very old and no longer used py4science dir. Should probably be simply deleted and not frozen *trunk/htdocs - the old mpl site docs. Should live somewhere for archival purposes in case there is a useful code snippet in there, but certainly does not need to be in git or the new repo. It could live frozen in the sf repo. * trunk/sampledata - this is important. The mpl trunk examples use this to pull example data. We will need to migrate this -- we could leave it in sf svn, but it might be preferable to have one version control system. Whatever we do here, we will need to update matplotlib.cbook.get_sample_data to work with the new system. Definitely an argument for getting all this migration sorted out before a trunk release. * trunk/sampledoc_tut - this is the source code for the http://matplotlib.sf.net/sampledoc tutorial which shows how to build mpl like sites using sphinx and associated extensions. Related to mpl in that it uses the plot directive etc, but is by no means integral. I can eventually port this to a new repo if there is any reason to. * trunk/scipy06 should probably be deleted * trunk/toolkits - should probably be migrated (Andrew you have not migrated this right?). One nice thing about having the toolkits in the same svn repo as the main codebase was for revision tagging, so basemap svn commits are synched with a trunk/matplotlib state. How should we proceed with the toolkits repo? Jeff? * trunk/users_guide - the old latex source for the mpl user's guide. Deprecated but should not be deleted. Same treatment as trunk/htdocs above. If we end up migratinga the toolkits to git/github (pending Jeff's comments) we may want to branch the stuff in trunk we want to keep for archival purposes (htdocs, users_guide) and clean as much stuff out of trunk as possible to avoid confusion for people browsing the trunk (and put a README in there explaining what and where stuff is). I think the plan is to keep trunk/matplotlib as a tracking repo, so that commits to the git master are pushed to the svn repo, so casual users who are running from svn HEAD will not be affected by the migration. Is this your understanding, Andrew? Does it makes sense to retain the entire history in the new github repo, or would it be just as well to start from a later point so as to reduce the size? The entire history could still be available in a separate read-only repo, or fossilized in svn on sourceforge, or in my hg mirror. (Andrew's repo, at just under 200MB, is not prohibitively large by any means, but it is a bit hefty.) I can see advantages either way, but I'm in favor keeping it. Tons of MPL is undercommented, and seeing the history is extremely useful when spelunking. I am strongly in favor of keeping the entire commit history of trunk/matplotlib. While the repo is large now, most of the size comes from data and regression test images, and the early history is largely code so will not add much incremental size. I suppose one of the downsides of git is since you have to get the *entire* history on one checkout, you end up with a bunch of stuff you are unlikely to ever need, like data that was once in the repo but has now been removed (eg the stuff we migrated to sampledata). Not sure if there is an easy solution here. JDH -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration
On Wed, Mar 3, 2010 at 8:29 AM, william ratcliff william.ratcl...@gmail.com wrote: I don't want to get into a flame war over this, but if Sourceforge was pressured into this and is having complaints and google has the same problem, how does Github get around it? Are they incorporated in the US or outside? If this is likely to become a problem, is there another service that can be used with git besides github that would not eventually be subject to such constraints? Sorry, I'm just ignorant about such matters. github has it's offices in the US and so they may change their policy on this in the future if they feel the heat from the long arm of the US law. Currently they do not appear to enforce export restrictions. Here is a helpful summary of different open source hosting facilities and their features and policies: http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities On Jan 25th, 2010, SF implemented a ban enforcing US export restrictions. http://sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law/ But on Feb 7th, 2010, they lifted the blanket ban and now project admins can impose the restriction if they are distributing restricted technologies, which seems like a good compromise. http://sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law/ Looks like the wikipedia site I linked above is out of date w/ respect to sourceforge. As far as I know, mpl is not distributing any restricted technologies -- we do make extensive use of message digest functions like md5 for caching, but these do not appear to be covered (eg, see http://www.fourmilab.ch/md5). So it would be preferable to be on a host that does not implement blanket restrictions. github does not currently, and if they change their policy going forward we may elect to move. Given that sourceforge has found a way to distribute compliant code to restricted countries, and github currently does not impose restrictions, I'm cautiously optimistic that a subsequent move will not be necessary. JDH -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] favicon submission
On Wed, Mar 3, 2010 at 9:33 AM, Ben Axelrod baxel...@coroware.com wrote: I am a big fan of favicons. I think MPL should definitely have one for the impending 1.0 release. So I made one for you. To use, simply place this file in the top level web directory. That is usually all that is required. But some browsers prefer if you put: link rel=shortcut icon href=favicon.ico in the header of the html pages. Cool -- we're live http://matplotlib.sourceforge.net/ (may need to refresh) Thanks! JDH -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] favicon submission
On Wed, Mar 3, 2010 at 11:16 AM, John Hunter jdh2...@gmail.com wrote: On Wed, Mar 3, 2010 at 9:33 AM, Ben Axelrod baxel...@coroware.com wrote: I am a big fan of favicons. I think MPL should definitely have one for the impending 1.0 release. So I made one for you. To use, simply place this file in the top level web directory. That is usually all that is required. But some browsers prefer if you put: link rel=shortcut icon href=favicon.ico in the header of the html pages. Cool -- we're live http://matplotlib.sourceforge.net/ (may need to refresh) If you want to work on this a bit more, I suggest * make the circle boundary of the polar plot fill the entire square of the icon (no dead white space) * user fewer and larger shaded areas, with strong colors. At the size the icon is rendered at in the browser, the features are very indistinct JDH -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug in julian2num()/num2julian()?
2010/3/4 Günter Lichtenberg guenter.lichtenb...@dlr.de: Hi I think there is a bug in the conversion routines jul2num() and num2jul(). I tried to define a date axis for satellite data. The time is measured in a modified Julian Date (JD). So reading in the data and then doing Hi Günter, Thanks for digging into this. Could you file a report on the bug tracker http://sourceforge.net/tracker/?group_id=80706atid=560720 Thanks, JDH -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Contouring unstructured triangular grids
On Mon, Mar 15, 2010 at 12:37 PM, Ian Thomas ianthoma...@googlemail.com wrote: Before going ahead with this I wished to ascertain how much interest there was for this functionality as I don't want to spend time doing something that isn't wanted or needed. I'm definitely interested, but I defer to Eric as the ultimate arbiter of all things contour related. I'm not concerned about the C++, we depend on plenty of that and std C++ won't increase the compile or distribution burden. I am a little concerned about the hand wrapped python part because of the possibilities of introducing memory leaks and difficulties it may pose in the matplotlib 2-3 transition. We use CXX mostly to expose our C++ (eg see src/ft2font.cpp or src/_backend_agg.cpp) and I'm hopeful that this will ease our transition to python3 since CXX6 supports python3. It would probably be beneficial, but by no means required, to use CXX to expose the C++ part to python so take a look if you are inclined. I'm also a bit concerned by the maintenance aspect, since this is a fairly sophisticated piece of code. We'd be looking for a commitment to support it if we include it in mpl. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Proposal for Broken Axes
On Mon, Mar 15, 2010 at 3:16 PM, klukas klu...@wisc.edu wrote: It's my understanding that there is no built-in method for generating a broken axis (where you skip over some range of values, indicating this with some graphical mark). I wanted to do this, so I've put together a function which seems to be fairly robust, and I thought I might propose it as a starting point if there's interest in having a built-in facility for broken axes. Please let me know if this is not the appropriate place to be submitting this suggestion. This is a nice start of an oft requested feature, and we are definitely interested. It is enabled by the spine contribution of Andrew, so you can turn off the upper and lower spines between the break, so it is nice to see some unintended benefits of his refactoring. From a usability standpoint, one thing we try to do is make pyplot a thin wrapper around functionality that exists in the API proper in matplotlib.figure, matplotlib.axes, etc. Functionally and in terms of implementation, this broken axes implementation is in the style of twinx which makes two axes for plotting on different scales http://matplotlib.sourceforge.net/examples/api/two_scales.html http://matplotlib.sourceforge.net/api/axes_api.html#matplotlib.axes.Axes.twinx http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.twinx What would be great is if you could refactor the basic functionality into a matplotlib.Axes.breaky method (and possibly breakx but most people request a broken y axis), which would resize the self axes and return the broken compliment which could be plotted onto. Then you could provide a thin pyplot wrapper much like pyplot.twinx, so that pyplot as well as API users could benefit. Finally, an svn patch which provided an example and patches to axes.py and pyplot.py would be most helpful. http://matplotlib.sourceforge.net/faq/howto_faq.html#submit-a-patch An alternative implementation could craft a custom transform using some custom artists for spines, but this might be a good bit harder. Do you have an opinion Andrew on this approach? JDH -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Thu, Mar 18, 2010 at 1:38 PM, Christopher Barker chris.bar...@noaa.gov wrote: I think the only two options should be scalar or 2-d array, it seems a bit much to have a 1-d array option as well. I disagree here -- if you are 2,1 or 1,2 rows x cols, 1D indexing is natural. This is also the most common use case so the most important to get right. If you aren't doing multiple subplots, a plain ol subplot(111) may be preferred to fig_subplots anyhow. JDH -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Thu, Mar 18, 2010 at 2:24 PM, Christopher Barker chris.bar...@noaa.gov wrote: John Hunter wrote: I think the only two options should be scalar or 2-d array, it seems a bit much to have a 1-d array option as well. I disagree here -- if you are 2,1 or 1,2 rows x cols, 1D indexing is natural. This is also the most common use case so the most important to get right. OK, but then how do you handle the fact that you might get a 0-d, 1-d or 2-d result? Eric's squeeze flag would result in that. Having squeeze1d and squeeze2d flags seems a bit much. squeeze configured with a kwarg seems like a good compromise. As long as the behavior is well documented it shouldn't pose any problems. And we still have access to fig.axes in the same format is has always been in. JDH -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Thu, Mar 18, 2010 at 7:46 PM, Fernando Perez fperez@gmail.com wrote: On Thu, Mar 18, 2010 at 3:49 PM, Christopher Barker chris.bar...@noaa.gov wrote: Good solution, and thanks for working on this! Thanks. I have one more question on this feature. I personally think that this should be the way to use mpl in general when scripting, and the way I want to teach, because it's easy and short while encouraging access to more robust patterns (figure/axes handing instead of the stateful pyplot). For this reason, I think the name should be really well chosen, and I'm not convinced fig_subplot is a very good one. I know naming discussions can be annoying, but if this ends up being the most popular/common entry point for making plots, it may be worth spending a moment on picking it right. Ideas (I'm *awful* at naming)? - plot_array? - plots? - subplots? - parray? - plotarr? - something actually good from someone else? I'll finish the patch tonight, we can always fix the name later as it's a trivial search/replace on fig_subplots - new_great_name. I also think the name should be changed, and there should be an entry in the matplotlib.figure.Figure API. One additional suggestion is subarray and matplotlib.pyplot.subarray would be a thin wrapper to matplotlib.figure.Figure.add_subarray. The former would return (fig, axarray) using gcf() to get the current figure, and the latter would simply create the subarray and return it. The would break a bit with the pyplot axes and subplot commands that only return the Axes and Subplot instances (and not the implicit Figure instance created/used) but I can live with that because part of the goal here is to give easy access to axes and figure creation so the user can get in the habit of using the API directly for most things. As for the other name suggestions, I like subplots. JDH -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Mon, Mar 22, 2010 at 11:50 AM, Jörgen Stenarson jorgen.stenar...@bostream.nu wrote: Would it be possible to put the draw in the ipython_prompt hook. That way it is always called after you have done something. I like this approach better, because one problem with doing it in the mpl Artist layer is that one artist setter may call another, and trigger a series of calls to draw for what is only a single draw at the interactive prompt. ipython knows when an interactive call is made, and can issue a draw. The trick will be to manage something like a needdraw flag for all mpl figures, which is set when any property contained in that fiugure changed and flushed when any call to draw is made. If we maintain this flag on all mpl setters and flush it after all mpl draws, the ipython prompt hook could check the flag and draw if needed when interactive is True. Not sure it is worth the effort, since like JJ I tend to mostly use the pyplot functions when working from the interactive shell and don't mind calling draw when using the API. I don't think API usage should be encouraged for the interactive prompt -- but I don't think it should be discouraged either -- it's just that in practice most experienced users use the state machine in this case because it is less typing and we needn't be pedantic, even when teaching wink. JDH -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New generic timers
On Tue, Apr 20, 2010 at 3:26 PM, Ryan May rma...@gmail.com wrote: Hi, Continuing the spurt of (independent) development that's been going on lately, I committed support for generic timers. There's a base class TimerBase that provides the basic API for a timer (start, stop, controlling the interval, adding callbacks, etc.), and each GUI backend subclasses this to wrap around their toolkit's native timer classes. I added a method to each backend's canvas object to facilitate creating a backend-specific timer without having to know what backend was running. So far, I'm quite happy with how it turned out, but I'm curious to hear feedback. Specifically: 1) Anything missing in the basic TimerBase API? You might want to pass the argument as keywords on from the add_timerr, so you can do timer = fig.canvas.new_timer(interval=100, callbacks=[(update_title, ax)]) or something like that... Or support a single callback object. Speaking of callbacks, do you know about cbook.CallbackRegistry? It would be nice to standardize on a single interface for handling callbacks so users and developers can manipulate it directly. We use this elsewhere in support of mpl event handling and the toolbar so it is fairly robust. 2) Is adding new_timer() the canvas a good way to go? I needed a way to get to backend-specific classes without actually knowing what backend I'm running (and without calling _pylab_helpers or pyplot.get_backend()). Figure.canvas seemed to be just about the only way to go about this. It also makes some sense, because in the case of Wx and Tk, an actual widget is required to hook up the timer. I've added an example in: examples/event_handling/timers.py This just makes a plot with a title that is continually (100 ms) updating with the current time including milliseconds. It does a good job of showing the ease with which such interactive updates can be done now. In fact, this could probably be used to update and simplify the existing animation demos. However, I'm already finishing up a more complete animation framework based on this, which should simplify some of those even further. At that point, I'll probably update the examples. Looking forward to seeing it -- thanks! JDH -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Upcoming Debian stable release and matplotlib new release(s)
On Thu, Apr 22, 2010 at 4:40 PM, Sandro Tosi mo...@debian.org wrote: Hello all, in some time (let's say a couple of months, maybe more) Debian will enter the freeze period, where no new upstream releases are accepted, in order to prepare the best stable release we can :) In the past months I see many changes are accumulated in the SVN but no new release are done. I don't know if you've already discussed about releasing mpl, but it would be nice if we can have something before the freeze, so to have a quite-update mpl in squeeze. From my POV, I'll provide all the support needed, so if there something I can do just tell me :) Hey Sandro, thanks for the head's up. We would like to get a 1.0 release out and there are two roadbumps we have to navigate first. We'd like to transition our VCS to git, and this impacts our release schedule because of the get_sample_data support in the trunk which currently pulls the data from svn but would have to be refactored to pull from hit and we'd like to make the transition before we do a release. Andrew, who is handling the git transition, has been very tied up of late, but thinks he'll have some time in early May. The other issue is my dead OSX build box -- I have access to a 64bit python 2.6 platform for builds for OSX, but currently no other platforms/versions so I have to sink some time into this for a release, though this is not a show stopper as we could do a release with incomplete binary support for OSX. So keep our feet to the fire and make sure we don't fall too far behind so we can get something out before the freeze, hopefully far enough before the freeze that we can get at least one bugfix release out... JDH -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] amplitude of peaks not shown correctly
On Sun, Apr 25, 2010 at 1:09 PM, Miguel de Val Borro miguel.de...@gmail.com wrote: Hello, The amplitude of sharp peaks is not shown correctly when several plots are stitched together and the x scale becomes very large. I have noticed this problem with the pdf and png backends in the attached script. This is a known bug which is fixed in svn. You need to set path.simplify : False in your matplotlibrc http://matplotlib.sourceforge.net/users/customizing.html -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Axis children exclude offset text
On Wed, May 19, 2010 at 11:29 AM, Stan West stan.w...@nrl.navy.mil wrote: Hi, developers. While trying to set the properties of all text in a figure, I noticed that the offset text of each axis was not being returned by get_children(), so the offset text wasn't receiving the new properties. I opened a tracker with a demonstration and suggested trivial patch at http://sourceforge.net/tracker/?func=detailatid=560720aid=3001208group_id=80706. Thank you for your continued work on matplotlib. Thanks for the patch -- applied to branch and trunk. JDH -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Removing lines leaks memory
On Fri, May 28, 2010 at 3:18 AM, Pearu Peterson pe...@cens.ioc.ee wrote: Hi, In an application that updates a plot with new experimental data, say, every second and the experiment can last hours, I have tried two approaches: 1) clear axes and plot new experimental data - this is slow and takes too much cpu resources. 2) remove lines and plot new experimental data - this is fast enough but unfortunately there seems to be a memory leakage, the application runs out of memory. Here follows a simple script that demonstrates the leakage problem: # import numpy from numpy.testing.utils import memusage import matplotlib.pyplot as plt x = range (1000) axes1 = plt.figure().add_subplot( 111 ) y = numpy.random.rand (len (x)) while 1: if 1: # leakage for line in axes1.lines: if line.get_label ()=='data': line.remove() else: # no leak, but slow axes1.clear() axes1.plot(x, y, 'b', label='data') print memusage (), len (axes1.lines) #eof When running the script, the memory usage is increasing by 132 kbytes per iteration, that is, with an hour this example application will consume 464MB RAM while no new data has been generated. In real application this effect will be even worse. So, I am looking for an advice how to avoid this memory leakage without clearing axes. Hey Pearu -- thanks for the report. We'll try and track down and fix this leak. In the interim, would an acceptable work around for you be to *reuse* an existing line by calling set_data on it. That way you wouldn't have to do the add/remove that is causing your leak. Have you confirmed this leak on various backends (eg Agg, PDF, PS)? -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Removing lines leaks memory
On Fri, May 28, 2010 at 1:04 PM, Pearu Peterson pe...@cens.ioc.ee wrote: Regarding reusing existing line --- I have understood that this will work only if the length of the line data does not change. This is not correct -- you can change the line length with calls to set_data In my case the data grows as more data points are acquired and I have not figured out how to make axes to set new limits after changing the line data. ax.relim() Cheers, JDH -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Removing lines leaks memory
On Fri, May 28, 2010 at 1:37 PM, Pearu Peterson pe...@cens.ioc.ee wrote: While the new data is plotted correctly, the plot shows fixed axes from the first plot call. What I am doing wrong? ax.relim() causes the data limits to be updated based on the current objects it contains, ax.autoscale_view() causes the view limits to be updated based on the data limits, and fig.canvas.draw() forces a redraw. JDH -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Upcoming Debian stable release and matplotlib new release(s)
On Sun, May 30, 2010 at 5:18 AM, Jouni K. Seppänen j...@iki.fi wrote: I agree that there should be a release before the transition. I was initially reluctant to do a release before the transition because of the get_sample_data issue. I was worried that some 1.x releases would point to the sf site and some to the github site. I am less concerned about that now because we can simply keep the old data on the sf site and so releases pointing to it will continue to work for the vast majority of examples, and because Jouni has verified that the same code works on sf and github modulo a url change. I will invest some time in the upcoming week getting ready for the release. We can target a release candidate for testing a week from now. Everyone who has some free time should tackle outstanding bugs on the tracker. I am aware of a compile problem on solaris with CXX6 that we now use, so I will see if I can make some progress on that. JDH -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Upcoming Debian stable release and matplotlib new release(s)
On Sun, May 30, 2010 at 12:05 PM, Eric Firing efir...@hawaii.edu wrote: Do you have in mind a dual release--maintenance branch and trunk--or is v0_99_maint abandoned with no release? Another option would be to make a 99 release ASAP and delay the 1.0. I do want to put out one last maintenance branch release -- I put up an rc some time ago and heard no problems so it is good to go. I will do it this weekend. JDH -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Passing errorbar width arguments to bar/barh ?
On Wed, Jun 2, 2010 at 8:01 AM, John Hunter jdh2...@gmail.com wrote: While this is certainly a bug that needs to be fixed (and Eric is right that these functions are heavily overworked and hairy), there is a better workaround than the one you tried. From the errorbar docstring: Ignore me :-) I had a temporary mental failure and see that this won't help you since you are calling bar and when bar is called with the xerr/yerr args the errorbar return values aren't passed back up. And my solution wasn't correct anyhow, since the third argument returned from errorbar is a *list* of LineCollection instances, not a LineCollection instance. Shutting up JDH -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Passing errorbar width arguments to bar/barh ?
On Wed, Jun 2, 2010 at 9:48 AM, Benjamin Root ben.r...@ou.edu wrote: I am curious as to why bar() should even be acting like errorbar(). As a user, I would expect bar() to do bar graphs and errorbar() to do error bar graphs. Is there some sort of use-case that I am missing where it makes sense to generate errorbars from a bar() function? Some of this stuff is just really old (circa 2003). When you have just a few users and someone sends you a patch, you tend to accept it :-) First we had bar, then we had errorbar, and someone wanted the convenience of easily adding errorbars to bar plots. Over time, these conveniences have grown into a fairly complex interface (xerr, yerr, asymmetric errors). So it has grown more organically than by design and some rationalization and normalization of functionality would be a good thing. We have to balance that with the downsides of code breakage, however. JDH -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] RuntimeError: Could not open facefile
On Thu, Jun 3, 2010 at 2:41 PM, Benjamin Root ben.r...@ou.edu wrote: Hello, I am getting this runtime error for some of my plotting scripts ever since I did a clean build and install of matplotlib from the svn repo: [snip] File /home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/text.py, line 524, in draw bbox, info = self._get_layout(renderer) File /home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/text.py, line 298, in _get_layout ismath=False) File /home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/backends/backend_gdk.py, line 309, in get_text_width_height_descent layout, inkRect, logicalRect = self._get_pango_layout(s, prop) File /home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/backends/backend_gdk.py, line 283, in _get_pango_layout font_str = '%s, %s %i' % (prop.get_name(), prop.get_style(), size,) File /home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/font_manager.py, line 742, in get_name return ft2font.FT2Font(str(findfont(self))).family_name RuntimeError: Could not open facefile /home/bvr/Programs/matplotlib/lib/matplotlib/mpl-data/fonts/ttf/Vera.ttf; Cannot_Open_Resource The file exists, and is certainly read-able. The program Fonty Python even checked and said that the fonts in that folder were valid, and displayed samples. Looking back at discussion threads before, this error has come up before back in 2007: http://www.mail-archive.com/matplotlib-us...@lists.sourceforge.net/msg05229.html Any thoughts? Just a shot in the dark, but does it help to flush the font cache in your .matplotlib dir? rm -rf ~/.matplotlib/font*.cache JDH -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Building matplotlib on OS X
On Mon, Jun 7, 2010 at 10:26 AM, Michael Hearne mhea...@usgs.gov wrote: I've had several problems with building on OS X in the past, and was just notified that a bug I opened about it has closed. Eric Firing suggested that I re-open the bug if it is still a problem. It is still a problem, but I can't seem to figure out how to re-open my bug report, so I'll report it again here with an update on the procedures I followed. First, I downloaded a fresh copy of matplotlib source: svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib matplotlib Then, following the instructions I found in README.osx: PREFIX=/Users/mhearne/build make -f make.osx fetch deps mpl_install I then moved my current matplotlib (one from Enthought) aside: cd /Library/Frameworks/EPD64.framework/Versions/Current/lib/python2.6/site-packages sudo mv matplotlib matplotlib.old I then used setup.py to install matplotlib: sudo /Library/Frameworks/EPD64.framework/Versions/Current/bin/python setup.py install You do not want to do this last step. The mpl_install in the make command will handle the install. This last step may be building against different libs, which is probably why you are seeing the ft2font import link problem. Note that the install will be put into $PREFIX/lib/python.6/site-packages so the PREFIX should be your installation target, not your build target. Ie, it looks like you are not setting the PREFIX according to the intent. I suggest something like sudo PREFIX=/Library/Frameworks/EPD64.framework/Versions/Current/ make -f deps mpl_install for your current file hierarchy. Alternatively, you can do PREFIX=/Users/mhearne/build make -f make binaries and then use the binary installers that are built to do the site wide install. JDH -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Building matplotlib on OS X
On Mon, Jun 7, 2010 at 4:13 PM, Michael Hearne mhea...@usgs.gov wrote: John - I followed your advice, and tried the build/install step again after downloading a completely fresh svn copy of the source: svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib matplotlib cd matplotlib sudo PREFIX=/Library/Frameworks/EPD64.framework/Versions/Current/ make -f make.osx fetch deps mpl_install It successfully compiled and installed matplotlib in my site-packages directory. However, I still see this in ipython: from matplotlib import ft2font --- ImportError Traceback (most recent call last) /Users/mhearne/ipython console in module() ImportError: dlopen(/Library/Frameworks/EPD64.framework/Versions/6.0.0/lib/python2.6/site-packages/matplotlib/ft2font.so, 2): Symbol not found: _FT_Attach_File Referenced from: /Library/Frameworks/EPD64.framework/Versions/6.0.0/lib/python2.6/site-packages/matplotlib/ft2font.so Expected in: flat namespace in /Library/Frameworks/EPD64.framework/Versions/6.0.0/lib/python2.6/site-packages/matplotlib/ft2font.so Am I missing some other step? One possibility is that the path from the traceback /Library/Frameworks/EPD64.framework/Versions/6.0.0/lib/python2.6/site-packages is not the same as your PREFIX PREFIX=/Library/Frameworks/EPD64.framework/Versions/Current/ unless Current is a symlink to 6.0.0 which it very well may be. Can you confirm? If you are getting different versions, you'll need to set your PYTHONPATH. Alternatively, we may need to set your LD_LIBRARY_PATH or similar to find the libs we built. They should be in $PREFIX/lib. You can use otool to see what the linker is finding in your current environment otool -L /Library/Frameworks/EPD64.framework/Versions/Current/lib/python2.6/site-packages/matplotlib/ft2font.so There may be another way -- you can set your prefix to something like PREFIX=~/tmpbuild and then build as before but do 'make binaries' rather than 'make mpl_install'. Then use the binary installer to do the system install. This may get you a build with the support libs statically linked in, though I am not sure about this. Sorry this is such a pain -- I keep trying to make a build script that works for people but it obviously isn't there yet. JDH -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Building matplotlib on OS X
On Tue, Jun 8, 2010 at 2:49 PM, Friedrich Romstedt friedrichromst...@gmail.com wrote: Hi Michael, may it be that you used different compilers for compiling your FreeType2 and your matplotlib? [CC=gcc-4.2] It's nearly impossible to tell afterwards from the libraries. I was able to compile matplotlib (not the svn though) on OS X Snow Leopard /without/ using the make.osx script. One has to apply some changes, but not large ones. John, I have the slight impression that you constantly try to ignore me, can you give a good reason, then I will be satisfied. Fixing the _png.cpp issue for libpng 1.4 would be a good start to make matplotlib compilable without the effort of make.osx. Sorry, I wasn't intentionally ignoring you. I don't have as much time as I'd like on the mpl mailing list so I sometimes dart in and out. If there is some thread or two or three where you would like me to comment or have some patches that need attention, please point me to them. Frequently, threads and contributions get left behind. Usually, the slight is not intentional but just due to bandwidth constraints. It happens enough that we have a FAQ :-) http://matplotlib.sourceforge.net/faq/howto_faq.html#contributing-howto JDH -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] savefig options doc inconsistency
On Wed, Jun 9, 2010 at 8:17 PM, Jason Grout jason-s...@creativetrax.com wrote: In the call signature of savefig found here: http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.savefig it doesn't list the bbox_inches and pad_inches options, though they are listed in the list below the signature. Thanks -- fixed in svn 8404 JDH -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] repeated calls to show() are now OK?
On Fri, Jun 11, 2010 at 2:56 PM, Eric Firing efir...@hawaii.edu wrote: Is it time for us to change our documentation, and officially support the use of multiple calls to show()? If we can do it, I think it would remove one of the main stumbling blocks for newcomers. I don't have a problem allowing/supporting it, but it may be tricky if we expect it to have the same blocking/non-blocking behavior across backends. Ie, for the script that does for i in range(10): plt.plot(np.random.rand(10), 'o') plt.show() many users expect that to be blocking on each call to show and the script to continue after closing each figure. My guess is that different backends on different platforms might show different behavior -- some may block, others not. I haven't looked at your changes yet, but what is your opinion on this issue? JDH -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] web gui
On Wed, Jun 16, 2010 at 6:33 PM, william ratcliff william.ratcl...@gmail.com wrote: I have a student here trying to make a webapp for data reduction. To add interactivity, we've been using the FLOT package, and may later consider protovis. We had thought about making a javascript backend for MPL, but to just get something running, we went with FLOT for the time being...We're using EXTJS as the web framework (it's a bit heavy, but has a rich widget toolkit and documentation). We use Django on the backend and Orbited to deal with some communications between the browser and the server (for example if we get new data from an instrument and want to update it on the server and update plots that are viewing that data..). Over the next couple of weeks (with the arrival of another student), we will be working more with the plotting aspect of the project (adding legends, zooming, etc). Also, for other parts of the app, we're just using the HTML5 canvas...I'd be happy to work on making the plotting addons as generic as possible so they can be used outside of our problem domain. What I'm not sure is whether one wants to truly use MPL as a backend, or rather to use the MPL philosophy of a javascript package. If anyone is interested in working on an html5 backend, we have a prototype here thanks to a GSOC applicant from last year http://bitbucket.org/sanxiyn/matplotlib-canvas/ JDH -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] doc build failure
On Jun 29, 2010, at 5:08 PM, Andrew Straw straw...@astraw.com wrote: John Hunter wrote: On Sun, Jun 20, 2010 at 7:56 PM, However, the link to trunk-docs still does not work. http://matplotlib.sourceforge.net/trunk-docs/ I believe I fixed the issue in svn r8477. Now, to fix the false alarm warnings that the buildbot give out so we catch this earlier. Hi to all at the SciPy conference -- I'm sorry I'll miss it this year. Well the site is up so that is the acid test. Michael, you can refer to this for gallery screenshots and examples. You may also want to provide the link along with the rc announcement for those who want docs and examples. Your 2 min talk is growing :-) Thanks for the quick fix, Andrew. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] should set_xlim turn off x autoscaling?
On Tue, Jun 29, 2010 at 8:42 PM, Eric Firing efir...@hawaii.edu wrote: You may well be right about this. In any case, I suspect no change will occur prior to the 1.0 release. I'm +1 on making the proposed change prior to mpl 1.0 (ie now). Call to set_xlim should turn off autoscaling for the x-axis on subsequent plot calls. There may be some breakage in arcane corner cases, but they will be exceptionally rare and easy to work around, and 1.0 is the perfect time to introduce such breakages. JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Typo in mplconf
On Sun, Jul 4, 2010 at 4:46 PM, Benjamin Root ben.r...@ou.edu wrote: Hello, I came across a typo in mplconfig.py that results in an error when processing the matplotlib configurations. Attached is a patch. I can apply this patch because it is a simple fix, but the larger question is whether we want to distribute/support the traited config at all. It seems like this development branch is mostly abandoned. Any comments Darren, or others? But in any case as long as we *do* currently have it it is good to fix these bugs, so thanks for the patch. JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] axes3d button-check fix
On Sun, Jul 4, 2010 at 4:56 PM, Benjamin Root ben.r...@ou.edu wrote: While I don't think this has caused any problems yet, I have noticed a discrepancy in how a button-click test was being done versus other checks in the same file. It also makes more sense to check against a compiled list of buttons instead of using a hard-coding value. Attached is a patch Applied to 8493, thanks! JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Help with blitting bug with subplots and markers
On Sat, Jul 3, 2010 at 11:53 AM, Ryan May rma...@gmail.com wrote: On Sat, Jul 3, 2010 at 1:11 AM, Ryan May rma...@gmail.com wrote: Alright, before I go to bed, I found the following line in src/_backend_agg.cpp at line 709 (in draw_markers()) makes all the difference: set_clipbox(gc.cliprect, rendererBase); Commenting out this line fixes my problem. I'm not sure why it's a problem, (maybe a missing restore to previous state somewhere?). I'll look into this tomorrow, but it would probably be a lot easier with someone familiar with the code. Following up again, it seems like the problem is that draw_marker is calling set_clipbox() on the rendererBase instead of theRasterizer, which is done at 7 other places in the code (as opposed to only one other location for rendererBase). Since rendererBase is used for restore_region, this makes sense as to why it would fix my problem. I can confirm making the change fixes my problem and doesn't cause any other issues in my (admittedly brief so far) testing. (If this isn't the proper fix, an alternative is to call rendererBase.reset_clipping(true), but I really think this is working around the issue). Can someone more familiar with the agg backend weigh in here? I'm pretty comfortable with the fix, but don't want to be responsible for breaking pretty much all of matplotlib. Does marker clipping still work with the proposed change? The only thing that is special about marker drawing is we use cached marker rasters to make drawing many of them efficient, but I don't recall anymore whether this required special clipping treatment. JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Triplot function problems
On Mon, Jul 5, 2010 at 4:36 AM, Alberto Azevedo a...@netcabo.pt wrote: I'm really sorry for my comment, it was not my intention to offend anyone. You are absolutely right about that, therefore I would like to apologize to all developers, in particular to you, for my comment regarding the matlab comparison. The only thing I can promise is that won't happen again... sorry!!! Speaking for myself , I did not find your comment offensive. It is true we are an all-volunteer organization and do not strive to duplicate matlab, but I took your comment to mean that the plotting could be done efficiently as evidenced by matlab, so there was no algorithmic reason it should be as slow as it is. Those kinds of comments, phrased gently and constructively, are generally welcome. The tri functionality is quite new, not yet in any released versions of mpl but that is soon to change, and often users have to pound on new functionality for a while to shake out inefficiencies As Ian noted, anywhere we use a long list of Line2D objects (or calls to plot in a loop) is prone to be very slow, and we should be able to get substantial performance improvements using a collection. Cheers, JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Triplot function problems
On Mon, Jul 5, 2010 at 3:17 AM, Ian Thomas ianthoma...@googlemail.com wrote: Yes, it does indeed take a long time for large grids. The bottleneck is line 51 in lib/matplotlib/tri/triplot - I use the plot command which creates a separate Line2D object for each edge in the triangulation, and there can be a lot of edges. There is an obvious improvement of replacing this with a single LineCollection object, but it would require some manipulation of the line styles, colours, etc that the plot command does and I don't yet understand it sufficiently. This could be made much faster using a compound Path for the edges and a single call to plot for the markers on the flattened array of vertices. You would retain the generality of all the mpl markers in this case, since you would be using plot for the verticies, but might lose some of the generality of the line styles since we don't have a class LinePath like we do in matplotlib.patches.PathPatch (eg see http://matplotlib.sourceforge.net/examples/api/compound_path.html). It would be nice to see an analogue or PathPatch matplotlib.lines.LinePath that exposes the relevant bits of the Line2D interface (set_linestyle) etc, but you can get most of this by setting facecolor='None' in the PathPatch. In practice, you almost always want a solid line for the edges I suspect. In a nutshell, you could still support the plot format string but manually pass it to Axes._process_plot_format. Use the returned results to set the properties on a single call to plot for the flattened array of vertex markers, and a single compound PathPatch with no facecolor for the edges (or you could support the facecolor if you want). Since PathPatch already supports linestyle, edgecolor and linewidth, it should work. And Paths support masks, so you should be able to integrate the masking but I am not sure about this part since I haven't delved deeply enough into the tri code to see how masking is applied. JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] branching for 1.0
On Tue, Jul 6, 2010 at 9:46 AM, Michael Pearce michaelppea...@gmail.com wrote: Sorry, this is the first email I've received on the matter. I only subscribed to the list today though.\ No worries, I was referring to Michael Droettboom :-) -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] branching for 1.0
On Tue, Jul 6, 2010 at 8:43 AM, John Hunter jdh2...@gmail.com wrote: On Mon, Jul 5, 2010 at 5:31 PM, John Hunter jdh2...@gmail.com wrote: If you're not available Michael, let me know or I will infer by your silence and try and make the branch myself from your instructions in the developers guide. I'm going top infer by your silence Michael that you may be on vacation so I am going to proceed with making the release branch. Fingers crossed. I think I followed the instructions pretty closely, but merge tracking still appears to be breaking. We had problems with this on the 99 main branch and Michael was at a loss to fix them. The branch is created and you can check out and commit to it, but merge tracking is breaking. The branch does not show up in when you call 'svnmerge.py merge' even after doing svnmerge.py init https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v1_0_maint OR svnmerge.py init https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v1_0_maint --force and then committing. I am going to proceed with the release from the branch, but merge tracking maybe FUBAR for a while. We can fall back on svn merge I suppose if MGD can't figure out what is wrong with this. You can get the maintenance branch from: svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v1_0_maint mpl1 JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] branching for 1.0
On Tue, Jul 6, 2010 at 10:34 AM, Michael Droettboom md...@stsci.edu wrote: Did you run this from a working copy of the trunk? That worked for me. (A merge init always has a from and a to, where the to is implied by the current working copy). I believe (though a little testing) that merging from the branch to the trunk is now working. I first ran it from trunk/matplotlib, and then thought maybe you meant trunk trunk, so I deleted the branch, recreated it, and did the svnmerge init from trunk. I'll test after your changes -- if I recall correctly we've been optimistic before only to see the merge tracking disappear. It appears to be working, though, so you clearly sprinkled your magic pixie dust on it. Thanks for taking a look. JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Adding more image format support...
On Tue, Jul 6, 2010 at 2:07 PM, Michael Droettboom md...@stsci.edu wrote: We've had some requests from internal users here at STScI to make it easier to save JPEG files directly from matplotlib. We currently support JPEG saving from the Gtk* and Wx* backends (because those libraries come with JPEG saving support), but not in the Tk backend that most of our users use. One solution to this may be to add an optional dependency on PIL, and if found save JPEG files (and maybe some of the other esoteric formats PIL supports). The work done a couple of years back to manage the supported file types should make this pretty easy. While adding a hard dependency on PIL is probably not a good idea, are there any objections to making it a soft dependency? No objections from me -- we already optionally use it in imread. JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] nasty import behavior
On Thu, Jul 8, 2010 at 9:16 AM, Neal Becker ndbeck...@gmail.com wrote:
Thanks for the info, but I still think this is rude behavior for a python
module, and believe it would be a good thing to fix it.
Generally we try and make it easy for the user to express their
intention rather than guess what they are trying to do. So you can
set your backend in an rc file
http://matplotlib.sourceforge.net/users/customizing.html
or harcode it in your script (before importing pylab/pyplot)
import matplotlib
matplotlib.use('Agg')
Or you can run your script from the command line with the -d flag
python myscript.py -dAgg # will generate PNG, no GUI
python myscript.py -dGTKAgg # will popup a GTK GUI
python myscript.py -dTKAgg # will popup a Tkinter GUI
This is convenient because the same script, unmodified, can either be
used in a headless or a GUI environment.
We support 6 user interface toolkits across 4 or more operating
systems and many UI, python and OS versions. We basically decided it
is too hard to guess what a user is trying to do across these
environments (embedding in apps, web app servers, headless scripts
generating PNG, working interactively from the shell), so we try to
make it easy for them to express their preferences.
If you have concrete suggestions on how we might accurately do this
detection in these scenarios, feel free to contribute, but a solution
that works for one environment, windowing system, or user interface
toolkit is of limited use.
See also
http://matplotlib.sourceforge.net/faq/installing_faq.html#what-is-a-backend
JDH
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Segfault in _path.so plugin when importing matplotlib in Chaco script
On Thu, Jul 8, 2010 at 11:13 AM, Tony S Yu tsy...@gmail.com wrote: The recent nasty import behavior thread motivated me to post an issue I've been having with matplotlib and chaco. (I've posted to the Chaco list previously, without much luck.) If I import matplotlib and chaco at the same time, I get a segmentation fault in the _path.so plugin. Below is a simple script that segfaults on my computer. I should note that this is installation dependent; someone on the Chaco list only had the issue with certain versions of Python. Just for reference, I'm on OS X 10.6, Python 2.6.1, and matplotlib/chaco trunk. -Tony P.S. In reality, there's no reason to import matplotlib when using Chaco, but I have some helper modules with some tangled imports (i.e. need to be refactored). First question -- are you compiling both yourself and are they compiled against the same version of numpy. If not, I suspect we are seeing a numpy version conflict. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] dvipng error with usetex
I am not a usetex user, but in testing mpl on a linux box I got a new error for dvipng. I hadn't seen this on this box before (it used to work there) but I am not suspecting an mpl bug at this point, rather a bug on the system. I don't really know, but others have reported similar dvipng bugs unrelated to mpl on ubuntu so I suspect the problem lies there. I am posting it here as a warning to others, and also in case anyone has any idea how to fix, debug or diagnose it. I would like to fix it because this is my primary machine for building and testing and updating the docs, so I'd like to have usetex working. If you google glibc detected *** dvipng: free(): invalid pointer there are a number of but reports And now the bug, using the mpl 1.0.0 release jdhun...@uqbar:pylab_examples dvipng --version This is dvipng 1.11 Copyright 2002-2008 Jan-Ake Larsson dvipng 1.11 kpathsea version 3.5.4 Compiled with Freetype 2.3.5 Using libft 2.3.11 Copyright (C) 2002-2008 Jan-Ake Larsson. There is NO warranty. You may redistribute this software under the terms of the GNU Lesser General Public License version 3, see the COPYING file in the dvipng distribution or http://www.gnu.org/licenses/. jdhun...@uqbar:pylab_examples uname -a Linux uqbar 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 08:03:28 UTC 2010 x86_64 GNU/Linux jdhun...@uqbar:pylab_examples PYTHONPATH=~/dev/lib/python2.6/site-packages/ python tex_demo.py --debug-annoying -dAgg *** glibc detected *** dvipng: free(): invalid pointer: 0x01b365b1 *** === Backtrace: = /lib/libc.so.6(+0x775b6)[0x7fe691b7e5b6] /lib/libc.so.6(cfree+0x73)[0x7fe691b84e53] dvipng[0x41480b] dvipng[0x414a6a] dvipng[0x412296] dvipng[0x4071ce] dvipng[0x405908] dvipng[0x405a6c] dvipng[0x40298c] /lib/libc.so.6(__libc_start_main+0xfd)[0x7fe691b25c4d] dvipng[0x402859] === Memory map: 0040-00422000 r-xp 08:05 6390264 /home/jdhunter/dev/bin/dvipng 00621000-00623000 rw-p 00021000 08:05 6390264 /home/jdhunter/dev/bin/dvipng 00623000-00627000 rw-p 00:00 0 01965000-01b6 rw-p 00:00 0 [heap] 7fe68c00-7fe68c021000 rw-p 00:00 0 7fe68c021000-7fe69000 ---p 00:00 0 7fe6904fd000-7fe690513000 r-xp 08:02 5160983 /lib/libgcc_s.so.1 7fe690513000-7fe690712000 ---p 00016000 08:02 5160983 /lib/libgcc_s.so.1 7fe690712000-7fe690713000 r--p 00015000 08:02 5160983 /lib/libgcc_s.so.1 7fe690713000-7fe690714000 rw-p 00016000 08:02 5160983 /lib/libgcc_s.so.1 7fe690714000-7fe690719000 r-xp 08:02 1433640 /usr/lib/libXdmcp.so.6.0.0 7fe690719000-7fe690918000 ---p 5000 08:02 1433640 /usr/lib/libXdmcp.so.6.0.0 7fe690918000-7fe690919000 r--p 4000 08:02 1433640 /usr/lib/libXdmcp.so.6.0.0 7fe690919000-7fe69091a000 rw-p 5000 08:02 1433640 /usr/lib/libXdmcp.so.6.0.0 7fe69091a000-7fe69091c000 r-xp 08:02 2787952 /usr/lib/libXau.so.6.0.0 7fe69091c000-7fe690b1c000 ---p 2000 08:02 2787952 /usr/lib/libXau.so.6.0.0 7fe690b1c000-7fe690b1d000 r--p 2000 08:02 2787952 /usr/lib/libXau.so.6.0.0 7fe690b1d000-7fe690b1e000 rw-p 3000 08:02 2787952 /usr/lib/libXau.so.6.0.0 7fe690b1e000-7fe690b44000 r-xp 08:02 5161212 /lib/libexpat.so.1.5.2 7fe690b44000-7fe690d44000 ---p 00026000 08:02 5161212 /lib/libexpat.so.1.5.2 7fe690d44000-7fe690d46000 r--p 00026000 08:02 5161212 /lib/libexpat.so.1.5.2 7fe690d46000-7fe690d47000 rw-p 00028000 08:02 5161212 /lib/libexpat.so.1.5.2 7fe690d47000-7fe690d49000 r-xp 08:02 5163771 /lib/libdl-2.11.1.so 7fe690d49000-7fe690f49000 ---p 2000 08:02 5163771 /lib/libdl-2.11.1.so 7fe690f49000-7fe690f4a000 r--p 2000 08:02 5163771 /lib/libdl-2.11.1.so 7fe690f4a000-7fe690f4b000 rw-p 3000 08:02 5163771 /lib/libdl-2.11.1.so 7fe690f4b000-7fe690f66000 r-xp 08:02 2788524 /usr/lib/libxcb.so.1.1.0 7fe690f66000-7fe691165000 ---p 0001b000 08:02 2788524 /usr/lib/libxcb.so.1.1.0 7fe691165000-7fe691166000 r--p 0001a000 08:02 2788524 /usr/lib/libxcb.so.1.1.0 7fe691166000-7fe691167000 rw-p 0001b000 08:02 2788524 /usr/lib/libxcb.so.1.1.0 7fe691167000-7fe69119a000 r-xp 08:02 2786757 /usr/lib/libfontconfig.so.1.4.4 7fe69119a000-7fe69139a000 ---p 00033000 08:02 2786757 /usr/lib/libfontconfig.so.1.4.4 7fe69139a000-7fe69139b000 r--p 00033000 08:02 2786757 /usr/lib/libfontconfig.so.1.4.4 7fe69139b000-7fe69139c000 rw-p 00034000 08:02 2786757 /usr/lib/libfontconfig.so.1.4.4 7fe69139c000-7fe6913bf000 r-xp 08:02 2791065 /usr/lib/libjpeg.so.62.0.0 7fe6913bf000-7fe6915be000 ---p 00023000 08:02 2791065 /usr/lib/libjpeg.so.62.0.0 7fe6915be000-7fe6915bf000 r--p 00022000 08:02 2791065 /usr/lib/libjpeg.so.62.0.0 7fe6915bf000-7fe6915c rw-p 00023000 08:02 2791065 /usr/lib/libjpeg.so.62.0.0 7fe6915c-7fe6916f1000 r-xp 08:02 2789161 /usr/lib/libX11.so.6.3.0 7fe6916f1000-7fe6918f1000 ---p 00131000 08:02 2789161 /usr/lib/libX11.so.6.3.0
Re: [matplotlib-devel] New Animation Class
On Fri, Jul 9, 2010 at 5:22 PM, Ryan May rma...@gmail.com wrote: I've been hard at work over the last couple of months putting together a set of classes that simplifies the creation of animations in matplotlib. This started when I resurrected some old code for Very nice -- people are going to really like this. I've had several requests personally to add something like this so thanks for doing it :-) Some rapid fire comments, in no particular order * on recent ubuntu linux with gtkagg, dynamic_image has a one pixel bug on the right side if blit=True. I suspect this has nothing to do with your package and everything to do with gtkagg blitting code having an off-by-one error somewhere. I added this to the tracker: https://sourceforge.net/tracker/?func=detailaid=3027636group_id=80706atid=560720 * this is completely un-thought out, but could we define a subclass of TimedAnimation to work like an iterator so users could do the natural thing : line, = ax.plot(something) for frame in SomeTimedAnimation(fig, blit=True): line.set_data(mydata) frame.update() or something along those lines * when you integrate this into trunk, I would like to see widgets.py upgraded to use it. This is not a requirement and I would be happy to help with it, but it is a good way to push on the new API and expand the test cases. * I am happy to see this pushed into trunk at any time. I would not push it into the branch, but we can do a 1.1 trunk release as soon as we are ready (release early, release often). Putting it in the trunk will facilitate testing and other developer contributions. But if you'd rather leave it in github for a while, I have no problem with that either. * you hardcode the artist visible state True/False in ArtistAnimation, which overrides any settings the users may be trying to control. Not sure if this is a problem, but it's something to think about. When you set False in ArtistAnimation._init_draw, should you first store the current state so you can restore the userland settings? You comment that maybe you should be integrating with the animated property. This is essentially what this is for, if animated is set it should not be used in drawing the background. Not sure if this matters since it may be sensible to assume they are handing you control of visibility in ArtistAnimation, just throwing it out there. * in Animation.save, why do you set blit=False? When making movies, shouldn't we also depend on the efficiencies of blit? Or was the idea: blit is buggy so for production movies turn it off cause I'm willing to sacrifice performance for quality? If so, I'd rather try an fix the bugsor expose blit as a kwarg. * a tutorial for the site docs would be awesome. It's one of the big missing pieces in the docs, so this would be a good time to add it. * when you include animation.py in the trunk, would you write the examples as import matplotlib.animation as animation ani = animation.FuncAnimation(fig, ...) per the style guidelines in the coding guide. * let's preserve the old gui specific examples in a subdir of examples/animation, so people who need bare metal control will still have examples to follow. You can add a README in that dir suggesting the use of the new API unless necessary. Nice work. JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] ContourSet not an Artist?
On Fri, Jul 9, 2010 at 9:59 PM, Eric Firing efir...@hawaii.edu wrote: On 07/09/2010 11:45 AM, Ryan May wrote: Hi, I just noticed that ContourSet only inherits ScalarMappable and ContourLabeller, neither of which is an Artist subclass, which means ContourSet is not an Artist. (And is why it does not have a remove() method). Anyone have any idea why and if we should correct that? I'm not sure what the ramifications would be. It's just historical. Should every plotting command return an Artist, simple or compound? If so, I suspect contouring is not the only thing that will need refactoring. I haven't investigated what would be required. Ryan, was there a particular use case in which you found that CS was not an Artist to be a limitation, or were you just asking out of curiosity? JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Fwd: [Numpy-discussion] ANN: Numpy runs on Python 3
On Sat, Jul 10, 2010 at 4:13 PM, Ryan May rma...@gmail.com wrote: both, specifically check_for_tk(). Here we catch the actual exception object and use it to print an error message. If anyone has a suggestion (not print the error? Look at the exception stack?), I'd love to be able to commit these so that at least setup.py runs. You might want to paste cbook.exception_to_str into setupext.py and use that to get the error message. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] How to exclude some examples to be built for doc?
On Mon, Jul 19, 2010 at 5:22 PM, Eric Firing efir...@hawaii.edu wrote: It would be OK to retain some examples with live downloading, but they should not be required for doc generation or for basic testing of mpl. They don't contribute anything essential to either. The primary motivation for the get_sample_data code arose from my observation that the gallery had become extremely popular, and appeared to be the way most people learned/experimented with mpl. I wanted some way to make it easy for a user to download and run any example from the gallery. One could say, grab this tarball or zipfile and unpack it before running this example, but getting the relative paths right, especially on windows, is difficult for new users. I completely agree that we can and should support a mechanism for users / distributors who want to circumvent the download phase. One could have an rc param sampledata.localonly that would check the mpl config dir for a sample_data dir (which is where it looks already) and forgo all the revision control stuff: if the file is there load it, else raise. Or we could support a special MPLSAMPLEDATA env var which could point to a dir or even a tar/zip file. Then one could get a svn co of sample_data, zip it up when going out to sea or packaging mpl, and configure mpl, presumably via the rc mechanism or env vars to use the hardcopy. JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] question about svnmerge
Yes, but there is a *lot* more involved in making the transition than just creating a git replica of the svn trunk. Granted, and I'm probably forgetting many of them. So it is probably a good idea for us to enumerate them here as a checklist when we do migrate. The major issues I am aware of are: * what do to about all the various subdirs of the mpl trunk (trunk/toolkits/basemap, trunk/sample_data, etc..). An svn commit to one tags all with a unique revision number. In git, how do we synchronize between them? Putting them all in the same tree would be monolithic and require huge checkouts. Unlike svn, in git it is difficult/impossible to check out just a subdir (eg trunk/matplotlb) and also commit to it. So we might end up having to informally synchronize parts of the trunk. Eg, basemap rXXX requires mpl rYYY in the CHANGELOG or release notes. * we have to port the sample_data handling. Jouni has shown that the viewvc ETags in sf and github work the same way, so this should be a minor hurdle. * organizational stuff: how do we handle the notion of the central repo? Now that github support organizations this should be relatively easy. Andrew and I registered a matplotlib user acct at github and created a gmail acct mplgithub as a central administrator (matplot...@gmail.com was taken, the bastards). Email me offlist if you are interested in obtaining the passwd for the github or gmail admin accts -- but you should probably coordinate with Andrew who is our point person as soon as he re-emerges. * porting the buildbot to work w/ github commits * related: porting the trunkdocs build to work with github commits * how to handle the svn tree at sf -- should it mirror the new github tree or remain stale or simply removed? Please add to the list other issues that need to be handled. Of all these, I'm only concerned philosophically with the first. The others are matters of time and work as people make the transition to the new server. The first seems like a true potential workflow impediment for those who run off svn/git HEAD and analogues. JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] question about svnmerge
On Wed, Jul 21, 2010 at 5:38 AM, Andrew Straw straw...@astraw.com wrote: I should be able to handle that fairly easily. I do it for my other projects. (Bigger on my buildbot priority list is stopping the annoying occasional config directory multi-process conflict. This should just take a couple of minutes. Just set MPLCONFIGDIR to be a unique dir for each buildbot on the shell line that runs the tests. JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] tight subplot parameters
On Wed, Jul 21, 2010 at 10:09 PM, Tony S Yu tsy...@gmail.com wrote: Wow, I don't see that at all. I'm on OS X, mpl svn HEAD (r8567), and Qt4Agg. I don't have GTK installed, so unfortunately, I can't really do a proper comparison. Here's the output I get from your modified script. I get something similar with TkAgg (unfortunately, I get an AttributeError with the macosx backend). Works on my system for tkagg and qtagg4, so the bug appears gtkagg specific. Must be something in the draw vs window realized and sized pipeline. It appears you are getting some bogus size info.Wonder if connecting to the draw_event might help here (longshot) or if any any of Eric's recent work on show is impacting th behavior here. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] tight subplot parameters
On Thu, Jul 22, 2010 at 7:40 AM, Michiel de Hoon mjldeh...@yahoo.com wrote: Is a backend required to implement a get_renderer method? I only see it implemented in backend_agg.py, and it's missing in backend_bases.py, backend_template.py, backend_cairo.py, and in the macosx backend. If you want to try your code with the macosx backend, you can use fig.canvas.renderer instead of fig.canvas.get_renderer(). According to backend_bases.FigureCanvas, a renderer attr is not guaranteed either. The Agg* backends rely on get_renderer so that they can get a properly sized renderer on figure resizes, dpi changes, etc. We could handle this on the agg side with a property, or require all canvases to supply get renderer. The tricky bit is that renderers may not be available until draw time for some backends, and thus may not have proper size information if accessed too early (this is probably at the heart of the gtk bug we are seeing). It is probably a good idea to settle on something so developers can get access to the renderer in a consistent state, and this might require support a raise_event which one could connect to and get the figure as soon as it is raised (which would be triggered on canvas creation for non gui backends presumably and after the window is raised for gui backends). In the callback, accessing canvas.renderer or canvas.get_renderer would return a renderer with proper sizing. JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] tight subplot parameters
On Thu, Jul 22, 2010 at 8:57 AM, Tony S Yu tsyu80@ According to backend_bases.FigureCanvas, a renderer attr is not guaranteed either. The Agg* backends rely on get_renderer so that they can get a properly sized renderer on figure resizes, dpi changes, etc. We could handle this on the agg side with a property, or require all canvases to supply get renderer. No, this won't work because the sizing information depends on the GUI window size. Agg adapts the renderer to the GUI window size. So in GTKAgg we are using the Agg renderer, but GTK is determining the window size when it is raised. We try to get GTK to produce a canvas of a fixed size, but cannot guarantee it so we reset the renderer size in necessary when the canvas is raised. JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug in 'weights' in axes.hist
On Thu, Jul 29, 2010 at 6:17 PM, Benjamin Root ben.r...@ou.edu wrote:
As a side-note, it looks like various files that have been changed due to
svnmerge.py are still showing themselves as having their properties
modified. Is this ok?
Yes, for some reason some of the files, like axes3d examples, are
always tagged with property changes on svn merges. It's a nuisance.
but harmless. In the handling of weights vs x, I notice in some
places we call np.array and others np.asarray. Shouldn't we be using
asarray in all of these cases, eg
Index: lib/matplotlib/axes.py
===
--- lib/matplotlib/axes.py (revision 8606)
+++ lib/matplotlib/axes.py (working copy)
@@ -7401,11 +7401,13 @@
**kwargs):
call signature::
+
+ def hist(x, bins=10, range=None, normed=False, weights=None,
+ cumulative=False, bottom=None, histtype='bar', align='mid',
+ orientation='vertical', rwidth=None, log=False,
+ color=None, label=None,
+ **kwargs):
- hist(x, bins=10, range=None, normed=False, cumulative=False,
- bottom=None, histtype='bar', align='mid',
- orientation='vertical', rwidth=None, log=False, **kwargs)
-
Compute and draw the histogram of *x*. The return value is a
tuple (*n*, *bins*, *patches*) or ([*n0*, *n1*, ...], *bins*,
[*patches0*, *patches1*,...]) if the input contains multiple
@@ -7567,7 +7569,7 @@
'this looks transposed (shape is %d x %d)' % x.shape[::-1])
else:
# multiple hist with data of different length
-x = [np.array(xi) for xi in x]
+x = [np.asarray(xi) for xi in x]
nx = len(x) # number of datasets
@@ -7582,7 +7584,7 @@
# We need to do to 'weights' what was done to 'x'
if weights is not None:
if isinstance(weights, np.ndarray) or not iterable(weights[0]) :
-w = np.array(weights)
+w = np.asarray(weights)
if w.ndim == 2:
w = w.T
elif w.ndim == 1:
@@ -7590,7 +7592,7 @@
else:
raise ValueError(weights must be 1D or 2D)
else:
-w = [np.array(wi) for wi in weights]
+w = [np.asarray(wi) for wi in weights]
if len(w) != nx:
raise ValueError('weights should have the same shape as x')
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Toolbar Icon qt4_editor_options
On Tue, Aug 3, 2010 at 3:29 PM, Friedrich Romstedt friedrichromst...@gmail.com wrote: 2010/8/3 Sebastian Voigt sebastian.vo...@mailbox.tu-dresden.de: I've seen that NavigationToolbar2QT uses a mixture of svg and png icons. All icons except the qt4_editor_options icon are provided in svg as well as png format. Can you add a png version of this icon? I prepared a png 64x64 version of the icon using Inkscape. See attachment. Our other pngs for icons are 24x24. Can you provide on in that size? JDH -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] show() blocks script execution for TkAgg from ipython -pylab
On Wed, Aug 11, 2010 at 12:35 PM, Eric Firing efir...@hawaii.edu wrote: John et al., Is this a reasonable time to put out 1.0.1? There have been quite a few bugfixes and other cleanups since 1.0. Most likely the biggest problem with 1.0 is my error in the tk show(), which you tripped over, and which prompted the thread below. I've been meaning to ask you the same thing :-). We probably need to have a go at the bug tracker before 1.0.1, but I am happy to do a bugfix release as soon as we are ready. Or perhaps we should be a little more aggressive on our numbering. Ie, bugfix releases could be 1.1.0 and 1.0.1, a micro release would be for installer fixes and the like. major numbers: significant new features, minor API breakage minor numbers: significant bugfixes and near guaranteed API compat micro: minor bugfixes, API compat I think 1.0 understates the maturity of the project so we may want to get to 2.0 in less than 10 years :-) JDH -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] developer policy question
On Thu, Aug 12, 2010 at 2:34 PM, Benjamin Root ben.r...@ou.edu wrote: I am currently working to patch something in colors.py and I am coming across a lot of older style code and code that duplicates functionality that can be found in cbook.py (particularly the type-checking functions). Is there a standing rule that code that we come across should get updated or adapted to use the functions in cbook.py? Or is it the other way around and that we should be avoiding cbook.py? You should be using as much centralized functionality (eg cbook) as possible and clean-ups are welcome. Just make sure if you remove a func that may be outward facing (eg a duplicate function from colors.py) that you deprecate it with a warning and note it in the log, and that the regression tests are passing. Thanks for the efforts! JDH -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] developer policy question
On Fri, Aug 13, 2010 at 12:53 PM, Benjamin Root ben.r...@ou.edu wrote: Where are the difference images saved to? Or do I have to pass an option to matplotlib.test() to generate those? I only have a directory FYI, the code is in lib/matplotlib/testing/compare.py, and the diff images on failure are placed in, for example, ./result_images/test_axes/failed-diff-pcolormesh.png I am not seeing failures on an ubuntu linux box I just tested on. JDH -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] developer policy question
On Fri, Aug 13, 2010 at 1:26 PM, Benjamin Root ben.r...@ou.edu wrote:
Found it. It is solid black.
Not quite:
In [95]: im =
imread('/home/titan/johnh/Downloads/failed-diff-pcolormesh.png').ravel()
In [96]: im.max()
Out[96]: 0.039215688
In [97]: im.min()
Out[97]: 0.0
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] developer policy question
On Fri, Aug 13, 2010 at 1:34 PM, John Hunter jdh2...@gmail.com wrote:
On Fri, Aug 13, 2010 at 1:26 PM, Benjamin Root ben.r...@ou.edu wrote:
Found it. It is solid black.
Not quite:
In [95]: im =
imread('/home/titan/johnh/Downloads/failed-diff-pcolormesh.png').ravel()
In [96]: im.max()
Out[96]: 0.039215688
In [97]: im.min()
Out[97]: 0.0
Probably we should increase the threshold as Eric suggested, but I
wonder if the different test results we are getting could be due to
PIL version.
In [6]: import Image
In [7]: Image.VERSION
Out[7]: '1.1.7'
JDH
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OK to delete methods?
On Sat, Aug 21, 2010 at 2:08 PM, Eric Firing efir...@hawaii.edu wrote: Mike, John, or anyone else who works directly with Ticks: I think you are the only ones who have worked with the code I suggest changing as in the attached diff. It looks to me like the three *Tick methods, set_view_interval(), get_minpos(), get_data_interval(), are unused and unlikely ever to have been or to be used. I particularly object to the first of these because I don't think a Tick has any business changing the view interval. The other two look like clutter, harmless except insofar as they make it harder to understand the code. If some projection actually does end up needing the functionality in any of these methods, it is still available via *Tick.axes.xaxis.* etc. Am I missing something? If not, I will commit this to the trunk. This is a case where I think immediate surgery is better than a deprecation process. I'm OK with removing them, and I don't feel strongly about deprecation with a helpful suggestion or radical mastectomy, though the former seems a little gentler. This should go into the trunk only since it is API breaking. JDH -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Fwd: wrong PDF on matplotlib web site?
I've updated the PDF on the main docs page http://matplotlib.sourceforge.net/contents.html Direct link: http://matplotlib.sf.net/Matplotlib.pdf JDH On Wed, Aug 25, 2010 at 11:01 AM, Michael Droettboom md...@stsci.eduwrote: Original Message Subject: wrong PDF on matplotlib web site? Date: Wed, 25 Aug 2010 10:32:03 -0400 From: Joe Harrington j...@physics.ucf.edu j...@physics.ucf.edu Reply-To: j...@physics.ucf.edu To: Michael Droettboom md...@stsci.edu md...@stsci.edu CC: j...@physics.ucf.edu Hi Michael, I just noticed that the User Guide PDF on the Matplotlib web site says 0.99.3, even though the page it's downloaded from says 1.0.0. Also, there's no main Download link, just the one in News. Just FYI, do as you will, and thanks for all you do on Matplotlib! --jh-- -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Unblock matplotlib sourceforge?
On Wed, Sep 8, 2010 at 12:57 PM, Jouni K. Seppänen j...@iki.fi wrote: This project does NOT incorporate, access, call upon, or otherwise use encryption of any kind, including, but not limited to, open source algorithms and/or calls to encryption in the operating system or underlying platform. I think mpl complies with this spirit of this clause: no nation on the restricted list could reasonably use mpl in an encryption/decryption effort. As for Jouni's explicit question: potentially copying some encrypted font data but not encrypting or decrypting it, I think that does not qualify as otherwise use encryption of any kind though I suppose this is open to interpretation. If we ever receive a reasonable request from the justice department asking us to cease-and-desist, we would certainly comply with that. So I suggest leaving the export controls turned off, as Eric has done. Thanks for the head's up Matthew (I thought we had already taken care of this ...) JDH -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Sample data: a proposal
On Sun, Sep 12, 2010 at 10:30 AM, Andrew Straw straw...@astraw.com wrote: #1 and #2 seem reasonable to me. I don't like #3 -- for the same reasons as we want to separate the rest I agree with Andrew here -- we don't want to hamstring our ability to change the data just because some people would rather take a version in place of the latest version. If we have an rc option sampledata.fetch : False then the sampledata function would only look in the sample data dir, get the file if available, raise otherwise. If fetch is True, it would always go the web first and check for the latest, get it and cache it. Then the packagers could download the tarball, unpack it, and not worry about mpl trying to check for a more recent version. JDH -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] IPython (new) + matplotlib report: happy news
On Mon, Sep 13, 2010 at 4:10 PM, Brian Granger elliso...@gmail.com wrote: One small request: is it possible/easy to add to the MPL examples a little 'copy to clipboard' button or link? Now that one can copy/paste wholesale examples into an interactive session to explore them, it feels annoying to have to highlight the whole text box and then do Ctrl-C or menu-copy. It would be really nice to have a one-click 'copy to clipboard'... But I have no idea if that's easy or hard in HTML... +1 to this! On a quick googling, there are some IE only Javascript examples to do this. Apparently you can enable them in firefox but it requires a significant amount of about:config hackery (http://www.febooti.com/support/website-help/website-javascript-copy-clipboard.html). How about this as an alternative: on my box, I can drag the source code link from the browser into my terminal, which by default pastes the URL of the referenced *.py into the terminal. If run supported a -w (web) option, or automatically detected that the URL starts with http, it could do a web run of the file. Of course, you may want the source code pasted in for illustrative purposes... To support this, you could add a -u (url) option to paste which assumes the input is a url, fetches it, and pastes the contents into ipython. So you could type paste -u and then drag the link into the terminal, and it would fetch it and paste the code into an input block. JDH -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] ANN: ThinWrap and ReMap
On Mon, Sep 13, 2010 at 4:27 PM, Benjamin Root ben.r...@ou.edu wrote: Just reping-ing this. I haven't heard anything negative and got a few positive comments off-list. I haven't committed this yet because I am concerned about the implications of my changes to cm.py, colors.py and contour.py. However, if I don't hear any concerns over the next couple of days, shall I assume that it is ok to go ahead and commit? I haven't looked closely at this yet, but at a glance it feels like a heavy-weight solution to what should be a simple problem. Can we not just have a to_grayscale method of the colormap? Also, I second Friedrich's concern/question about the ThinWrap approach -- what is the argument for wrapping vs deriving? JDH -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] ANN: ThinWrap and ReMap
On Wed, Sep 15, 2010 at 11:31 AM, Benjamin Root ben.r...@ou.edu wrote: But, what would the to_grayscale method produce? And what about other possible transformations? Should we add other functions as well to invert, brighten, darken, etc? Maybe another approach would be to have the Colormap class have an attribute function called transform that would, by default, be just a function that returns the input rgba array. Then, one could assign different transformation functions that would be used in the __call__ function of the colormap? to_grayscale would return a colormap instance. If the colormap also had a darken or invert (if people think this is useful), they could also be colormap methods. Then you could chain imshow(..., cmap=cm.jet.to_grayscale().darken()) KDJ -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
