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 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 som

Re: [matplotlib-devel] Upcoming Debian stable release and matplotlib new release(s)

On Sun, May 30, 2010 at 12:05 PM, Eric Firing 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

Re: [matplotlib-devel] Upcoming Debian stable release and matplotlib new release(s)

On Sun, May 30, 2010 at 1:15 PM, John Hunter wrote: > On Sun, May 30, 2010 at 12:05 PM, Eric Firing 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 A

Re: [matplotlib-devel] Passing errorbar width arguments to bar/barh ?

On Tue, Jun 1, 2010 at 6:17 PM, Fernando Perez wrote: > Hi all, > > I just spent some time digging through the matplotlib code, and I see > that the errorbar line width argument isn't passed through to the > underlying call.  In axis.bar, we have this code: > >        if xerr is not None or yerr i

Re: [matplotlib-devel] Passing errorbar width arguments to bar/barh ?

On Wed, Jun 2, 2010 at 8:01 AM, John Hunter 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

Re: [matplotlib-devel] Some keys generate tracebacks in the GTK backend

On Wed, Jun 2, 2010 at 8:28 AM, Tony S Yu wrote: > > On Jun 1, 2010, at 8:59 AM, João Luís Silva wrote: > > Hi, > > Pressing tab, the "Windows" key or the right click key (and maybe > others) on a plot with the GTKAgg or GTK backend causes the following > traceback: Thanks Tony, committed to svn

Re: [matplotlib-devel] Passing errorbar width arguments to bar/barh ?

On Wed, Jun 2, 2010 at 9:48 AM, Benjamin Root 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 genera

Re: [matplotlib-devel] Upcoming Debian stable release and matplotlib new release(s)

On Wed, Jun 2, 2010 at 12:34 PM, Tom Holroyd (NIH/NIMH) [E] wrote: > > > John Hunter wrote: >> >> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.3 > > I'm running Fedora 13, and it mostly works but the config output says that >

Re: [matplotlib-devel] RuntimeError: Could not open facefile

On Thu, Jun 3, 2010 at 2:41 PM, Benjamin Root 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

Re: [matplotlib-devel] Building matplotlib on OS X

On Mon, Jun 7, 2010 at 10:26 AM, Michael Hearne 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

Re: [matplotlib-devel] Building matplotlib on OS X

On Mon, Jun 7, 2010 at 4:13 PM, Michael Hearne 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

Re: [matplotlib-devel] Building matplotlib on OS X

On Tue, Jun 8, 2010 at 2:49 PM, Friedrich Romstedt 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 s

Re: [matplotlib-devel] savefig options doc inconsistency

On Wed, Jun 9, 2010 at 8:17 PM, Jason Grout 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 signatu

Re: [matplotlib-devel] repeated calls to show() are now OK?

On Fri, Jun 11, 2010 at 2:56 PM, Eric Firing 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/supportin

Re: [matplotlib-devel] web gui

On Wed, Jun 16, 2010 at 6:33 PM, william ratcliff 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 s

Re: [matplotlib-devel] doc build failure

On Sun, Jun 20, 2010 at 7:56 PM, Jae-Joon Lee wrote: > The issue was related with the change in Sphinx v1.0b2, which I think > I fixed in r8447. > At least, the html are built fine and uploaded fine. > > However, the link to trunk-docs still does not work. > > http://matplotlib.sourceforge.net/tru

Re: [matplotlib-devel] doc build failure

On Jun 29, 2010, at 5:08 PM, Andrew Straw 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/ >>> >> &

Re: [matplotlib-devel] should set_xlim turn off x autoscaling?

On Tue, Jun 29, 2010 at 8:42 PM, Eric Firing 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 subseque

Re: [matplotlib-devel] Typo in mplconf

On Sun, Jul 4, 2010 at 4:46 PM, Benjamin Root 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 d

Re: [matplotlib-devel] axes3d button-check fix

On Sun, Jul 4, 2010 at 4:56 PM, Benjamin Root 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 inst

Re: [matplotlib-devel] Help with blitting bug with subplots and markers

On Sat, Jul 3, 2010 at 11:53 AM, Ryan May wrote: > On Sat, Jul 3, 2010 at 1:11 AM, Ryan May 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); >> >>

Re: [matplotlib-devel] Triplot function problems

On Mon, Jul 5, 2010 at 4:36 AM, Alberto Azevedo 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

Re: [matplotlib-devel] Triplot function problems

On Mon, Jul 5, 2010 at 3:17 AM, Ian Thomas 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 edg

[matplotlib-devel] branching for 1.0

Although there are many active issues that are undergoing constant work, none of these seem release critical and we can continue to improve them on the branch and trunk as need be. Eric, who has been doing the lion's share of the work managing, fixing and closing bugs, feels like we are ready to g

Re: [matplotlib-devel] subplotting 3d figures

On Sat, Jul 3, 2010 at 1:51 AM, Benjamin Root wrote: > Hello all, > > I have always been a bit troubled with how Axes3D object is a bit of a > 2nd-class citizen in matplotlib.  In particular, it is very common to create > a new axes using .add_subplot() or .gca(), but you can't do that with > Axes

Re: [matplotlib-devel] branching for 1.0

On Mon, Jul 5, 2010 at 5:31 PM, John Hunter 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

Re: [matplotlib-devel] branching for 1.0

On Tue, Jul 6, 2010 at 9:46 AM, Michael Pearce 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 :-) --

Re: [matplotlib-devel] branching for 1.0

On Tue, Jul 6, 2010 at 8:43 AM, John Hunter wrote: > On Mon, Jul 5, 2010 at 5:31 PM, John Hunter 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 develo

Re: [matplotlib-devel] branching for 1.0

On Tue, Jul 6, 2010 at 10:34 AM, Michael Droettboom 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

Re: [matplotlib-devel] Adding more image format support...

On Tue, Jul 6, 2010 at 2:07 PM, Michael Droettboom 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

Re: [matplotlib-devel] nasty import behavior

On Thu, Jul 8, 2010 at 9:16 AM, Neal Becker 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

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 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

[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 unr

Re: [matplotlib-devel] Segfault in _path.so plugin when importing matplotlib in Chaco script

On Thu, Jul 8, 2010 at 1:25 PM, Tony S Yu wrote: > > On Jul 8, 2010, at 12:27 PM, Michael Droettboom wrote: > > Can you get a gdb backtrace? > > Mike > > Ignore my last email. The crash occurs here: > #--- > Continuing. > Reading symbols for shared libraries . done > Reading symbols for shared lib

Re: [matplotlib-devel] New Animation Class

On Fri, Jul 9, 2010 at 5:22 PM, Ryan May 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

Re: [matplotlib-devel] ContourSet not an Artist?

On Fri, Jul 9, 2010 at 9:59 PM, Eric Firing 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

Re: [matplotlib-devel] Fwd: [Numpy-discussion] ANN: Numpy runs on Python 3

On Sat, Jul 10, 2010 at 4:13 PM, Ryan May 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

Re: [matplotlib-devel] Fwd: [Numpy-discussion] ANN: Numpy runs on Python 3

On Sat, Jul 10, 2010 at 9:38 PM, Ryan May wrote: > 2.6.  With Python 3.1, I get a compile failure with src/ft2font.cpp, > which isn't surprising. I'm a little surprised ft2font is failing, since it is a CXX module, and I recently upgraded our CXX from v5 to v6 mainly because v6 is supposed to be

Re: [matplotlib-devel] How to exclude some examples to be built for doc?

On Mon, Jul 19, 2010 at 5:22 PM, Eric Firing 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_dat

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

Re: [matplotlib-devel] question about svnmerge

On Wed, Jul 21, 2010 at 5:38 AM, Andrew Straw 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.

Re: [matplotlib-devel] tight subplot parameters

On Wed, Jul 21, 2010 at 10:09 PM, Tony S Yu 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

Re: [matplotlib-devel] tight subplot parameters

On Thu, Jul 22, 2010 at 7:40 AM, Michiel de Hoon 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

Re: [matplotlib-devel] tight subplot parameters

On Thu, Jul 22, 2010 at 8:57 AM, Tony S Yu > 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 sid

Re: [matplotlib-devel] Bug in 'weights' in axes.hist

On Thu, Jul 29, 2010 at 6:17 PM, Benjamin Root 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 alway

Re: [matplotlib-devel] Toolbar Icon qt4_editor_options

On Tue, Aug 3, 2010 at 3:29 PM, Friedrich Romstedt wrote: > 2010/8/3 Sebastian Voigt : >> I've seen that NavigationToolbar2QT uses a mixture of svg and png icons. >> All icons except the icon are provided in svg as >> well as png format. Can you add a png version of this icon? > > I prepared a pn

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 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 prom

Re: [matplotlib-devel] [Matplotlib-users] show() blocks script execution for TkAgg from ipython -pylab

On Wed, Aug 11, 2010 at 1:32 PM, Benjamin Root wrote: > Couldn't we just do what Google does and put a "Beta" label on everything? > > "Matplotlib Beta" > > Sounds almost like a planet or something... That used to be my attitude. Turns out there are a lot of legitimate users who cannot (due to c

Re: [matplotlib-devel] developer policy question

On Thu, Aug 12, 2010 at 2:34 PM, Benjamin Root 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 standin

Re: [matplotlib-devel] developer policy question

On Fri, Aug 13, 2010 at 12:53 PM, Benjamin Root 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 i

Re: [matplotlib-devel] developer policy question

On Fri, Aug 13, 2010 at 1:26 PM, Benjamin Root 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 ---

Re: [matplotlib-devel] developer policy question

On Fri, Aug 13, 2010 at 1:34 PM, John Hunter wrote: > On Fri, Aug 13, 2010 at 1:26 PM, Benjamin Root wrote: >> Found it.  It is solid black. > > Not quite: > In [95]: im = > imread('/home/titan/johnh/Downloads/failed-diff-pcolormesh.png').ravel() > > In

Re: [matplotlib-devel] OK to delete methods?

On Sat, Aug 21, 2010 at 2:08 PM, Eric Firing 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_min

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 wrote: > > Original Message Subject: wrong PDF on matplotlib web > site

Re: [matplotlib-devel] Unblock matplotlib sourceforge?

On Wed, Sep 8, 2010 at 12:57 PM, Jouni K. Seppänen 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

Re: [matplotlib-devel] Sample data: a proposal

On Sun, Sep 12, 2010 at 10:30 AM, Andrew Straw 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 v

Re: [matplotlib-devel] [IPython-dev] IPython (new) + matplotlib report: happy news

On Mon, Sep 13, 2010 at 4:10 PM, Brian Granger 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 t

Re: [matplotlib-devel] ANN: ThinWrap and ReMap

On Mon, Sep 13, 2010 at 4:27 PM, Benjamin Root 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,

Re: [matplotlib-devel] ANN: ThinWrap and ReMap

On Wed, Sep 15, 2010 at 11:31 AM, Benjamin Root 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 h

Re: [matplotlib-devel] compiling on Solaris (and going against the python API)

On Fri, Sep 17, 2010 at 3:04 AM, Eric Firing wrote: > Before making that change, I verified that at least on my linux system, > Python.h defines those two variables the same way that features.h does, > so the redefinition would be harmless if we did not undefine the > variables. I don't think we

Re: [matplotlib-devel] Better to compile Python and libraries from source? If so, what version?

On Wed, Sep 22, 2010 at 2:15 PM, Jeremy Lounds wrote: > I have another question for the group... > > I saw in the archives someone else who was getting the error I am now > running in to now. He said he solved it by recompiling from sources. I > was wondering what version of Python is optimal for

Re: [matplotlib-devel] Toolbar button for relimiting

On Mon, Sep 27, 2010 at 1:57 PM, Benjamin Root wrote: > Second, irregardless of whether this button is included or not, there have > been app developers who have added buttons to the toolbar for their own > use.  Can these developers count on that real estate to always be free?  Can > we definiti

Re: [matplotlib-devel] Toolbar button for relimiting

> Here are my reasons to add the button, just to add to the discussion: > I've written two applications so far that embed matplotlib, and in both > I felt that the relimit button was missing: In one, there are always > lines added and removed and I often need to reset the plot limits, and > in the

Re: [matplotlib-devel] Yahoo historical quotes

On Tue, Oct 12, 2010 at 10:55 AM, Keith Goodman wrote: > Thanks for the code. I added matplotlib's yahoo historical quote code > to my labeled array package, la. While doing so I noticed a couple of > possible bugs: > > - The doc string for parse_yahoo_historical says that the volume is > adjusted

Re: [matplotlib-devel] Yahoo historical quotes

On Tue, Oct 12, 2010 at 11:47 AM, Keith Goodman wrote: > Well, then perhaps the doc string needs tweaking? > >    *adjusted* >      If True (default) replace open, close, high, low, and volume with >      their adjusted values. >      The adjustment is by a scale factor, S = adjusted_close/close.

Re: [matplotlib-devel] Qt SVG clipping bug (it's NOT a matplotlib bug)- Qt won't fix...

On Thu, Oct 14, 2010 at 7:49 AM, Michael Droettboom wrote: > I haven't had a chance to look at the new Qt shell in ipython yet -- but > is it necessary to go through a file?  Perhaps writing a native Qt4 I believe the motivation here is in the separation of the ipython kernel process from the sh

Re: [matplotlib-devel] Bug (?) in fill_between

On Wed, Oct 20, 2010 at 8:43 AM, Giovanni Plantageneto wrote: > Hi, > > I think I found a bug in the command fill_between(). > If I try to make a fill_between plot on an x-axis that spans both negative > and positive values (and only in that case), I have some funny results. > I attach the code t

Re: [matplotlib-devel] Release schedule for version 1.0.1?

On Fri, Oct 22, 2010 at 7:16 PM, Michael Droettboom wrote: >  On 10/22/2010 05:45 PM, Russell E. Owen wrote: >> I'm curious when the next release of matplotlib is due. >> >> My application is suffering badly from the issue that an incorrect font >> cache will cause matplotlib to fail (the applicat

Re: [matplotlib-devel] how to submit a patch?

On Mon, Oct 25, 2010 at 6:53 AM, Kynn Jones wrote: >> diff -u figure.py.orig figure.py > patchname.diff > > OK, got that part.  Thanks.  But where do I send the patch? Actually, we recommend submitting an svn diff. Details at: http://matplotlib.sourceforge.net/faq/howto_faq.html#submit-a-pat

Re: [matplotlib-devel] Release schedule for version 1.0.1?

On Mon, Oct 25, 2010 at 3:41 PM, Daniel Hyams wrote: > It doesn't really insist on it right?  There are MATPLOTLIBDIR and > MPLCONFIGDIR environment variables.  The former is for the location of > mpl-data, and is not really documented well (that I could find, anyway, but > I found it in the sour

Re: [matplotlib-devel] Release schedule for version 1.0.1?

On Mon, Oct 25, 2010 at 4:09 PM, Daniel Hyams wrote: > Right, I was referring specifically to MATPLOTLIBDIR ;) > > I was just pleased as punch to find it in the source code, documented or no > :) I'm guessing you mean MATPLOTLIBDATA ? And you're right, it isn't documented (yet)... JDH ---

Re: [matplotlib-devel] Release schedule for version 1.0.1?

On Thu, Oct 28, 2010 at 9:05 AM, Benjamin Root wrote: > Just as a quick question that I would like to throw out.  It isn't a bug, > but rather an aesthetics issue that I caused for the version 1.0 release. > > With allowing 3d plots to be made subplottable, the margins for the plot > area became

Re: [matplotlib-devel] Release schedule for version 1.0.1?

On Thu, Oct 28, 2010 at 1:11 PM, Christopher Barker wrote: > On 10/25/10 1:41 PM, Daniel Hyams wrote: >> It doesn't really insist on it right?  There are MATPLOTLIBDIR and >> MPLCONFIGDIR environment variables. > >> You can set these env variables within your code, before import of >> matplotlib v

Re: [matplotlib-devel] Release schedule for version 1.0.1?

On Thu, Oct 28, 2010 at 2:46 PM, Russell E. Owen wrote: > It's an interesting question. You can't call a matplotlib function to do > it because it has to happen before matplotlib is loaded. I suppose there > could be a configuration package to perform the operation. This is basically what we alr

[matplotlib-devel] demo text path failing

Appears to be branch and trunk jo...@udesktop191:pylab_examples> python demo_text_path.py Traceback (most recent call last): File "demo_text_path.py", line 71, in ? transform=IdentityTransform()) File "demo_text_path.py", line 27, in __init__ mpatches.PathPatch.__init__(self, path, **k

Re: [matplotlib-devel] Matplotlib 1.0.1 release schedule (again)

On Mon, Nov 8, 2010 at 1:29 PM, Sandro Tosi wrote: > What's the plan about 1.0.1? is it going to be release soon? will it > include the sample_data dir in the released tarball, so that we can > set examples.download = False, and examples.directory = > "/sample_data" inside the tarball? that w

Re: [matplotlib-devel] plot directive, thank you and a question

On Mon, Nov 8, 2010 at 6:55 PM, Matthew Brett wrote: > First - thank you - it makes my heart very glad to be able to do this: > > .. plot:: >    :include-source: > >    import matplotlib.pyplot as plt >    plt.plot(range(10)) >    plt.show() > > Here's my question.   This is already a huge step fo

[matplotlib-devel] gtkagg w/o extension code

We are getting seg faults on our Solaris platform at work when we use the blit API in GTKAgg. This has been going on for a while, and I don't know if it is in our pygtk version, or what. The line that is causing the crash is in src/_gtkagg.cpp GdkDrawable *drawable = GDK_DRAWABLE(py_drawable->

Re: [matplotlib-devel] gtkagg w/o extension code

On Tue, Nov 9, 2010 at 2:25 PM, John Hunter wrote: > Attached also is the example code I am using to test.  Strangely, the > agg buffer seems to be updating internally but the gtk window is only > updating when I hover my mouse over it, and then only once until I > activate anothe

Re: [matplotlib-devel] gtkagg w/o extension code

On Tue, Nov 9, 2010 at 3:48 PM, Eric Firing wrote: > On 11/09/2010 11:03 AM, John Hunter wrote: > Based on a very superficial look, I suspect we could eliminate > pixbuf_get_pixels_array by using the function > http://www.pygtk.org/docs/pygtk/class-gdkpixbuf.html#function-gdk--pix

Re: [matplotlib-devel] gtkagg w/o extension code

On Tue, Nov 9, 2010 at 7:57 PM, Benjamin Root wrote: > I gave your latest patch a try and I noticed something odd while doing the > animation examples.  I don't know if this is a result of my special desktop > configuration.  I am using Ubuntu Netbook Remix, which uses Maxiumus to > automatically

Re: [matplotlib-devel] Inclusion in RHEL6

On Wed, Nov 10, 2010 at 10:09 PM, Benjamin Root wrote: > FYI, > > I was just looking through the package list for the newly released RHEL 6. > matplotlib version 0.99.1.2 has been included, along with numpy 1.3 and > python 2.6.5.  I did not see scipy and ipython, however. > > Congrats for fiinall

Re: [matplotlib-devel] How to decouple non-GUI stuff from the GUI?

On Thu, Nov 18, 2010 at 4:11 PM, Kynn Jones wrote: > On Wed, Nov 17, 2010 at 6:33 PM, Benjamin Root wrote: > >> As an additional note, if you are having difficulty compiling for MacOS X, >> why not just ask for help with that? > > Just to keep from ranting like a lunatic, basically.  The experien

Re: [matplotlib-devel] How to decouple non-GUI stuff from the GUI?

On Fri, Nov 19, 2010 at 9:10 AM, Kynn Jones wrote: > On Wed, Nov 17, 2010 at 6:30 PM, Michiel de Hoon wrote: > >> In principle the non-interactive mode can also be implemented in this >> backend. If that would solve your problem, could you open a bug report for >> it? >> >> > How??? I feel so i

Re: [matplotlib-devel] How to decouple non-GUI stuff from the GUI?

On Fri, Nov 19, 2010 at 9:10 AM, Kynn Jones wrote: > > > When I read your message about implementing the non-GUI mode, it turns this > simple picture completely on its head, which tells me that matplotlib's > architecture is, at this point, beyond my comprehension.  One of the reasons > for loo

Re: [matplotlib-devel] Building documentation and matplotlibrc

On Sun, Dec 5, 2010 at 3:14 PM, Ben Gamari wrote: >> I am not intimately familiar with the doc build system, but the way that >> the "html" function in make.py copies matplotlibrc from mpl-data to >> _static, I suspect that it is trying to ensure that that particular file >> is used. >> > Anyone

Re: [matplotlib-devel] Building documentation and matplotlibrc

On Thu, Dec 9, 2010 at 12:34 PM, Ben Gamari wrote: > Regardless, after making the necessary changes to use absolute paths > (after painfully realizing that the MATPLOTLIB environment variable > expects the directory of the desired matplotlibrc, not the file path; > documentation would have been n

Re: [matplotlib-devel] Building documentation and matplotlibrc

On Thu, Dec 9, 2010 at 1:12 PM, Ben Gamari wrote: > It seems that this may have been broken from the beginning. After > noticing that my changes were not taking effect, I added some debug > output and found that sphinx was changing the current working directory > (every example gets built with it

Re: [matplotlib-devel] Building documentation and matplotlibrc

On Thu, Dec 9, 2010 at 1:52 PM, Ben Gamari wrote: > Any idea why my debugging messages are ineffective? Or, even better, any > idea why setting the examples.download in doc/matplotlibrc isn't being > reflected in rc_params? I'll examine this more closely in about 30 > minutes once I make it to th

Re: [matplotlib-devel] PATCH: fix libpng URLs for OS X makefile

On Fri, Dec 31, 2010 at 9:54 AM, Friedrich Romstedt < [email protected]> wrote: > > Also, not everyone has X11 installed (or does everyone now?) > > > One can opt X11 out at installation time IIRC. But it's a rare case I > believe. > > I don't know what the situation is now, but the l

Re: [matplotlib-devel] PATCH: fix libpng URLs for OS X makefile

On Fri, Dec 31, 2010 at 10:00 AM, Friedrich Romstedt < [email protected]> wrote: > > I've been meaning to publish my installation instructions for > > numpy/scipy/matplotlib/ipython on Snow Leopard somewhere for quite a > > while, but that will have to wait for another day... I've tried

Re: [matplotlib-devel] 1.0.1 release

On Sat, Jan 1, 2011 at 9:14 PM, Ben Gamari wrote: > On Sat, 18 Dec 2010 06:41:43 -0500, Ben Gamari wrote: > > Hey all, > > > > Can we please have a 1.0.1 release? It would be really nice to finally > > have official 1.0 packages for ubuntu/debian. > > > Pretty please with sugar on top? > > Sorry

[matplotlib-devel] matplotlib 1.0.1rc available for testing, building

We are long overdue on getting a bugfix release of 1.0.0 out, so I have uploaded an rc for testing at https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1/ Christoph and Russell -- if you have time could you build win32 and OSX binaries for testing as well. I don't belie

Re: [matplotlib-devel] matplotlib 1.0.1rc available for testing, building

On Sun, Jan 2, 2011 at 4:25 PM, Sandro Tosi wrote: > > > > https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1/ > > > Maybe I just missed them, but I can't find in the tarball the data > files needed to run the examples without internet connection. I > thought it was dec

Re: [matplotlib-devel] trunk rev 8843 crash on Snow Leopard

On Mon, Dec 20, 2010 at 6:31 PM, Russell E. Owen wrote: > I built a binary installer for matplotlib trunk rev 8843 (because it > leaks memory less than 1.0.0 release). I built it the same way I built > the 1.0.0 binary >

[matplotlib-devel] purging the developer list

It's the annual new year's developer purge, designed to keep the list of official developers in sync with the people who are currently committing. The rule of thumb is that someone who has not committed in the last year is purged. As always, I am happy to reinstate anyone on request, so just email

Re: [matplotlib-devel] matplotlib 1.0.1rc available for testing, building

On Sun, Jan 2, 2011 at 11:52 AM, John Hunter wrote: > > > In sf, we used to be able to tag a file as the preferred file for a given > OS, but in the new file manager interface I no longer see a way to do this, > so that for example the rc files don't show up as the defaul

Re: [matplotlib-devel] matplotlib 1.0.1rc has an outdated pytz

On Mon, Jan 3, 2011 at 2:00 PM, Russell Owen wrote: > matplotlib 1.0.1rc has pytz 2010h but the current version is 2010o. > (dateutil is current at 1.5). > > Should I report this as a bug or is this email sufficient? > email is sufficient. I'm inclined to fix this for the trunk (targeting a 1.

Re: [matplotlib-devel] matplotlib 1.0.1rc available for testing, building

On Mon, Jan 3, 2011 at 1:57 PM, Russell Owen wrote: > The news: > - The Mac binary installer for python.org Python 2.6 works on my Mac OS X > 10.4 and 10.5 machines (both Intel). However, it segfaults on my 10.6 > machine if there is no existing ~/.matplotlib and ~/.fontconfig. If others > could

Re: [matplotlib-devel] matplotlib 1.0.1rc has an outdated pytz

On Mon, Jan 3, 2011 at 2:19 PM, Christoph Gohlke wrote: > > These packages should be kept up-to-date if possible. There is an old > bug report that was closed. > > < > http://sourceforge.net/tracker/index.php?func=detail&aid=3009273&group_id=80706&atid=560720 > > > Since the version is out of d

<    1   2   3   4   5   6   7   8   9   10   >