Re: [matplotlib-devel] system fonts not found
On Thu, Sep 25, 2008 at 9:31 AM, Darren Dale <[EMAIL PROTECTED]> wrote:
> I noticed this morning that my Times and Palatino system fonts are not being
> found anymore. I removed my fontManager.cache and ran my script with
> verbose=debug, and it looks like creatFontDict found them, but then findfont
> cant:
I recently fixed another bug related to font finding when an explicit
file name was passed -- I wonder if I broke a normal use case. It's a
simple change shown in the diff below. Could you manually revert on
your end and see if it makes a difference. If so, I'll have to find
another solution to the problem I was fixing.
[EMAIL PROTECTED]:mpl> svn diff lib/matplotlib/font_manager.py -r6097:6098
Index: lib/matplotlib/font_manager.py
===
--- lib/matplotlib/font_manager.py (revision 6097)
+++ lib/matplotlib/font_manager.py (revision 6098)
@@ -955,7 +955,7 @@
fname = prop.get_file()
if fname is not None:
verbose.report('findfont returning %s'%fname, 'debug')
-return fname[0]
+return fname
if fontext == 'afm':
fontdict = self.afmdict
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] spy: ignore zero values in sparse matrix
On Fri, Sep 26, 2008 at 2:36 PM, Tony S Yu <[EMAIL PROTECTED]> wrote: > I guess you could plot sparse all-zero matrices with image mode. My only > hesitation is that sparse arrays tend to be very large and (I imagine) this > would lead to very slow performance. I assumed this was the reason image > mode wasn't adapted to use sparse arrays. > > Actually, now that I think about it: you could plot a trivially small image > and just adjust the coordinates so that they correspond to the original > matrix shape. Is this what you were thinking? This is something I considered, but I was thinking less about the implementation and more about the functionality. I don't want to raise an exception unless the input doesn't make sense. I would rather the user start at a boring image and figure out why it is blank that deal with an exception. > I should note that a dense zero array also fails to plot with spy *if marker > mode is used*. Can you fix this along with spy2? JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Axes.add_line() is oddly slow?
On Tue, Oct 7, 2008 at 9:18 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > According to lsprofcalltree, the slowness appears to be entirely in the > units code by a wide margin -- which is unfortunately code I understand very > little about. The difference in timing before and after adding the line to > the axes appears to be because the unit conversion is not invalidated until > the line has been added to an axes. > > In units.get_converter(), it iterates through every *value* in the data to > see if any of them require unit conversion, and returns the first one it > finds. It seems like if we're passing in a numpy array of numbers (i.e. not > array of objects), then we're pretty much guaranteed from the get-go not to > find a single value that requires unit conversion so we might as well not > look. Am I making the wrong assumption? > > However, for lists, it also seems that, since the code returns the first > converter it finds, maybe it could just look at the first element of the > sequence, rather than the entire sequence. It the first is not in the same > unit as everything else, then the result will be broken anyway. I made this change -- return the converter from the first element -- and added Michael's non-object numpy arrat optimization too. The units code needs some attention, I just haven't been able to get to it... This helps performance considerably -- on backend driver: Before: Backend agg took 1.32 minutes to complete Backend ps took 1.37 minutes to complete Backend pdf took 1.78 minutes to complete Backend template took 0.83 minutes to complete Backend svg took 1.53 minutes to complete After: Backend agg took 1.08 minutes to complete Backend ps took 1.15 minutes to complete Backend pdf took 1.57 minutes to complete Backend template took 0.61 minutes to complete Backend svg took 1.31 minutes to complete Obviously, the results for tests focused on lines with lots of data would be more dramatic. Thanks for these suggestions. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] SF.net SVN: matplotlib:[6166] trunk/matplotlib/lib/matplotlib/units.py
On Tue, Oct 7, 2008 at 11:26 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > This isn't quite what I was suggesting (and seems to be equivalent to > the code as before). In the common case where there are no units in the > data, this will still traverse the entire list. > > I think replacing the whole loop with: > > converter = self.get_converter(iter(x).next()) > > would be even better. (Since lists of data should not be heterogeneous > anyway...) Hmm, I don't see how it would traverse the entire list for thisx in x: converter = self.get_converter( thisx ) return converter since it will return after the first element in the loop. I have no problem with the iter approach, but am not seeing what the problem is with this usage. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] path simplification with nan (or move_to)
On Wed, Oct 8, 2008 at 11:37 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> I figured this out. When this happens, a RuntimeError("Agg rendering
> complexity exceeded") is thrown.
Do you think it is a good idea to put a little helper note in the
exception along the lines of
throw "Agg rendering complexity exceeded; you may want to increase
the cell_block_size in agg_rasterizer_cells_aa.h"
in case someone gets this exception two years from now and none of us
can remember this brilliant fix :-)
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug in legend
On Wed, Oct 8, 2008 at 1:44 PM, David Huard <[EMAIL PROTECTED]> wrote:
> /usr/local/lib64/python2.5/site-packages/matplotlib/legend.pyc in
> __init__(self, parent, handles, labels, loc, numpoints, prop, pad,
> borderpad, markerscale, labelsep, handlelen, handletextsep, axespad, shadow)
> 125 setattr(self,name,value)
> 126 if pad:
> --> 127 warnings.DeprecationWarning("Use 'borderpad' instead of
> 'pad'.")
> 128 # 2008/10/04
> 129 if self.numpoints <= 0:
>
> AttributeError: 'module' object has no attribute 'DeprecationWarning'
I just replaced this with
warnings.warn("Use 'borderpad' instead of 'pad'.", DeprecationWarning)
which is what we have been doing in other parts of the code, so please
give svn 6173 a try.
Thanks,
JDH
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] path simplification with nan (or move_to)
On Wed, Oct 8, 2008 at 8:40 PM, Eric Firing <[EMAIL PROTECTED]> wrote: > Thanks for doing this--it has already helped me in my testing of the > gappy-path simplification support, which I have now committed. As you > suggested earlier, I included in path.py a check for a compatible codes > array. > > The agg limit still can be a problem. It looks like chunking could be added > easily by making the backend_agg draw_path a python method calling the > renderer method; if the path length exceeds some threshold, then subpaths > would be generated and passed to the renderer method. In unrelated news, I am not in favor of the recent change to warn on non-GUI backends when "show" is called. I realize this may sometimes cause head-scratching behavior for some users who call show and no figure pops up, but I think this must be pretty rare. 99% of users have a matplotlibrc which defines a GUI default. AFAIK, the only exceptions to this are 1) when the user has changed the rc (power user, needs no protection) or 2) no GUI was available at build time and the image backend was the default backend chosen (warning more appropriate at build time). If I am missing a use case, let me know. I like the design where the same script can be used to either generate a UI figure or hardcopy depending on an rc settng or a command flag (eg backend driver) and would rather not do the warning. This has been a very infrequent problem for users over the years (a few times at most?) so I am not sure that the annoyance of the warning is justified. If 2) in the choices above is the case you are concerned about, and you want this warning feature in this case, we can add an rc param which is autoset at build time, something like "show.warn = True|False" since the build script is setting the default image backend and can set "show.warn = True" when it sets an image backend by default, otherwise False. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] path simplification with nan (or move_to)
On Thu, Oct 9, 2008 at 6:14 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: >> If 2) in the choices above is the case you are concerned about, and >> you want this warning feature in this case, we can add an rc param >> which is autoset at build time, something like "show.warn = >> True|False" since the build script is setting the default image >> backend and can set "show.warn = True" when it sets an image backend >> by default, otherwise False. >> > > I intended the warning to warn against misconfiguration, so one shouldn't > have to explicitly configure anything to get it... ;) This is mostly academic, since I am happy with your latest changes because I can run backend driver or do > python somefile.py -dAgg and get no warning. But I wasn't suggesting explicit configuration by the user. At build time, mpl looks for a functioning backend in setup.py and if it fails to find one, sets Agg and creates the default matplotlibrc from matplotlibrc.template. In the case where a no GUI was detected, the build script could also set a rc warn-on-show flag. The ubuntu packager, who probably built mpl in an environment with no X11 and got no functioning GUI, would get a rc file with backend Agg and the warn-on-show flag set. But I think we can leave things as they are. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch for scatter plot legend enhancement
On Wed, Oct 8, 2008 at 10:27 PM, Erik Tollerud <[EMAIL PROTECTED]> wrote: > Ah, that makes more sense Jae-Joon - thanks! Jae-Joon -- could you handle this patch submission? Thanks, JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] unexpected behaviour of get_xlim
On Fri, Oct 10, 2008 at 11:31 AM, Gregor Thalhammer <[EMAIL PROTECTED]> wrote: > Is this really an intended behaviour? Wouldn't it be better if > get_xlim() already returns a copy? Or could at least the documentation > be updated to mention this pitfall? I think it should return a copy -- if I don't hear any objections I'll change it. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] can't commit
I am getting this error on a couple of machines when I try to commit [EMAIL PROTECTED]:mpl> svn commit -m 'some more doc mods' svn: Commit failed (details follow): svn: MKACTIVITY of '/svnroot/matplotlib/!svn/act/5726e9f3-f4eb-cc5e-bc97-ffd78106e3fc': 403 Forbidden (https://matplotlib.svn.sourceforge.net) Anyone else seeing this and does anyone have any idea what is wrong? Thanks, JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New doc update
On Wed, Oct 15, 2008 at 8:18 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > The new stylesheet for the docs looks great, John! I just ripped this off hook-line-and-sinker from the sphinx docs, and added the few css bits you created earlier. They do look nice :-) > One extremely minor nit: perhaps the logo is a too large in this > context. On smaller screens, like a 1024x768 laptop, it encompasses > about a third of the usable browser window space. > > Would it be possible to keep it the current size for the main home page, > but use a smaller version for the documentation pages? Or, to the > extreme, just use a small icon-sized logo like in the Python 2.6 docs? I'm happy to do use a smaller logo on the doc pages, but off hand do not know how to do it. I am knee deep in trying to convert the existing docs, because as you probably gathered the sphinx docs will soon entirely replace the existing web pages entirely. So if you could help with this logo change that would be great. Either route (smaller logo or single icon) is fine by me. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] can't commit
On Wed, Oct 15, 2008 at 9:48 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > Yep... just sent a message before seeing this one. The few possible causes > I could find through Google didn't seem relevant. > > Feel free to pile on to this bug report --> > > https://sourceforge.net/tracker/?func=detail&atid=21&aid=2168647&group_id=1 > I did -- and since others are now adding comments that they see the same, it looks like a generic sf problem. Hopefully they will get it sorted out soon. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New doc update
On Wed, Oct 15, 2008 at 10:28 AM, Chris Walker <[EMAIL PROTECTED]> wrote: > > http://matplotlib.sourceforge.net/doc/html/index.html links to > http://matplotlib.sourceforge.net/doc/html/goals.html which doesn't > seem to exist yet. > > I guess this is temporary, but thought it worth pointing out. Thanks -- all bug reports welcome because I may not be aware of them. The goals page is horribly out of date so I am just going to scrap it for now. We can resurrect it later if need be. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New doc update
On Wed, Oct 15, 2008 at 10:17 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: >> I'm happy to do use a smaller logo on the doc pages, but off hand do >> not know how to do it. I am knee deep in trying to convert the >> existing docs, because as you probably gathered the sphinx docs will >> soon entirely replace the existing web pages entirely. So if you >> could help with this logo change that would be great. Either route >> (smaller logo or single icon) is fine by me. I am having problems in that the "matplotlib home" text is getting wrapped with the new icon. Screenshot attached. Are you not seeing this? I may work on a thinner default logo, because I like having the consistency between pages JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New doc update
On Wed, Oct 15, 2008 at 2:22 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > Nope, I'm not seeing this, even when I shrink the window width way down. > > This is Firefox 2.0 on RHEL4. > > Does putting a between matplotlib and home help? I tried this, and it put matplotlib and home together, but on the line below the icon. I tried to make sure there were no spaces between the image and the start of the matplotlib word, but wasn't able to kill the newline firefox 2.0.0.14 on solaris x86 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New doc update
On Wed, Oct 15, 2008 at 2:42 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > Weird. Have to admit I don't understand this HTML stuff very well... ;) Don't worry about it -- I am going to try and revert these changes with a thinner logo. I'll let you know when it's ready for testing. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] new site is live!
I just took the plunge and pushed the beta website live. We are now purely driven off the sphinx living in the doc dir. There is still plenty of material from the old site (stuff from the FAQ, the credits, stuff from the user's guide, goals/known issues) so once again please feel free to contribute. It's much easier now that it is plain rest and sphinx. One area where all developers can easily contribute is by extending the FAQ when we get common questions on the mailing lists. I would also really like to see sections on contours, images and colormaps, colorbars, time series plotting (eg the spectral stuff), collections http://matplotlib.sourceforge.net Let me know if you find any problems. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new site is live!
On Wed, Oct 15, 2008 at 4:04 PM, Andrew Straw <[EMAIL PROTECTED]> wrote: > Dang that looks good. The only glitches that I see are: > > 1) after the ">>> hist(x, 100)""" line in the Python pre-formatted text > box, there's an extra line's worth of vertical space. > > 2) The heading "Plotting commands" overlaps slightly with the top line > of the following table. > > This is on Firefox 3 with Ubuntu 8.04. I'm seeing that too -- added a couple of hacks to fix it JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] navigation toolbar keyboard shortcuts patch
On Thu, Oct 16, 2008 at 9:18 PM, Paul Ivanov <[EMAIL PROTECTED]> wrote: > Hi, > > I'm a big fan of keyboard shortcuts, so I decided to add these guys to > lib/matplotlib/backend_bases.py > > I'm not sure if this is too much, and maybe these should be configurable > down the line, but here's my first stab at it, what do you all think? > > in the same order as they appear in the toolbar: > 'h' or 'r' for Home/Reset > left arrow or 'z' or backspace for Back > right arrow and 'x' for Forward > 'p' for pan axes with right, zoom with left mode toggle > 'o' for z*o*om to rectangle mode toggle > 's' for save > 'z' and 'x' I borrowed from the Opera browser, very handy to for > righties who can have their left hand on the keyboard while using the mouse. Hi Paul, I'm amenable to additional keys, but check out http://matplotlib.sourceforge.net/users/navigation_toolbar.html which details which keys are already in play. Also, with your patch, please submit a patch against the navigation toolbar doc doc/users/navigation_toolbar.rst . Maybe a ReST table that details all of the key bindings? Thanks, JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new site is live!
On Thu, Oct 16, 2008 at 5:10 PM, Darren Dale <[EMAIL PROTECTED]> wrote: > It looks great, really nice work guys. Sorry I havent been able to keep up > with the list recently, unfortunately its unlikely to change for a while. > > I noticed that the PDF download link at > http://matplotlib.sourceforge.net/contents.html is broken. Ahh, thanks for letting me know. It's fixed now (you may need to "refresh"). sf removed shell access to the web directory, so all the reorg and cleanup had to be done over sftp, scp and rsync via ssh, which was a pain, so there are probably a few things that will need to be restored/tweaked. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Re: Patch for scatter plot legend enhancement]
On Thu, Oct 16, 2008 at 9:57 PM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote: > Thanks Manuel. > > Yes, we need rotation value and etc, but my point is, do we need to > update it within the update_from() method? Although my preference is > not to do it, it may not matter much as far as we state what this > method does clearly in the doc. To help clarify the original purpose of "update_from": I wrote this method when writing the original legend implementation so the legend proxy objects could easily copy their style attributes from the underlying objects they were a proxy for (so not every property is copied, eg the xdata for line objects is not copied). So the operating question should be: what properties do I need to copy to make the legend representation of the object. While you are in there, perhaps you could clarify this in the docstrings of the update_from method. Hope this helps, JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] minor fix to animation example
On Thu, Oct 16, 2008 at 9:10 PM, Tony S Yu <[EMAIL PROTECTED]> wrote: > I noticed that one of the animation examples is missing some import > statements. Also, the diff below includes a small change to the shebang line > of another example. Hey Tony, Thanks for the patch, applied to svn r6232. For future patches, could you send a "svn diff" from the matplotlib directory containing setup.py. That way I don't have to think too hard about the patch level, what kind of patch it is etc > cd ~/path/to/mpl/src > svn diff > mypatch.diff Thanks again, JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] artists.rst
On Wed, Oct 15, 2008 at 2:57 PM, Manuel Metz <[EMAIL PROTECTED]> wrote: > I found a few typos in artists.rst. Added a patch (don't want to commit > it, because I'm not actively working on the docs) > > The first sentence of the section "Object containers" also needs to be > fixed (or I don't understand it): > "Now that we know how to inspect set the properties of a given object > we want to configure, we need to now how to get at that object." > > "inspect" or "set" ??? "inspect and set" Thanks for the patch -- I just applied it to svn r6234 JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] creating docs fails
On Sat, Oct 18, 2008 at 8:34 AM, Manuel Metz <[EMAIL PROTECTED]> wrote: > With a clear checkout building the docs fails: > > [...] > Sphinx v0.4.2, building html > trying to load pickled env... not found > building [html]: targets for 348 source files that are out of date > updating environment: 348 added, 0 changed, 0 removed > reading... api/afm_api api/artist_api Exception occurred: > File "/usr/lib/python2.5/shutil.py", line 51, in copyfile >fsrc = open(src, 'rb') > IOError: [Errno 2] No such file or directory: > '../mpl_examples/pylab_examples/findobj_demo.py' > The full traceback has been saved in /tmp/sphinx-err-X12gbJ.log, if you > want to report the issue to the author. > Please also report this if it was a user error, so that a better error > message can be provided next time. > Send reports to [EMAIL PROTECTED] Thanks! > Building HTML failed. I was gettin a similar error on one platform, but not on another, though I was using clean svn dirs for the build in each one. I guessed it might be related to sphinx version I was using for the build, and when I upgraded sphinx to 0.5 (svn HEAD actually) on the broken platform I got a working doc build. Give it a try, JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] WX backend patch
On Mon, Oct 20, 2008 at 7:51 AM, Lee Kamentsky <[EMAIL PROTECTED]> wrote: > Hi all, > I've submitted a patch to > matplotlib/lib/matplotlib/backends/backend_wx.py on the bug tracker > (http://sourceforge.net/tracker2/?func=detail&aid=2166139&group_id=80706&atid=560722 > ). I'd appreciate feedback on it and am looking forward to the > functionality making it into an upcoming release. > > Briefly, the patch fixes a bug when running under Windows and implements > draw_image for the backend. We'll be happy to take a look at this, but since we are trying to figure out whether we should keep backend_ex at all, could you tell us why you prefer or require backend wx over wxagg? Thanks, JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Re]: kwarg "range" in hist
On Mon, Oct 20, 2008 at 9:01 AM, David Huard <[EMAIL PROTECTED]> wrote: > I would oppose any change to histogram calling convention that does not > fix a critical bug. I agree that using a built-in name as an argument is > a bug, but I believe it is the lesser evil compared to asking users to > change their code > again. I think in this case we have to change it, but we can do it gently. Ie, for a release cycle, if we detect "range" in the kwarg case, we'll set the correct kwarg, eg "binrange", issue a warning, but not raise an error. That way users can fairly easily change their code w/o breakage. Whoever does the deprecation should note the date and version of the deprecation warning, so we will know when enough time and releases have passed to remove range entirely. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] WX backend patch
On Mon, Oct 20, 2008 at 10:40 AM, Lee Kamentsky <[EMAIL PROTECTED]> wrote: > Thanks for your reply, John. It's mostly me being naive - my code works > great when I choose WXAgg as my backend. I'll be using that for now. Feel > free to accept / reject or ask for fixes to the patch. OK, thanks. You may want to see this FAQ for more details on the backends http://matplotlib.sourceforge.net/faq/installing_faq.html#what-is-a-backend JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib-devel Digest, Vol 29, Issue 19
On Mon, Oct 20, 2008 at 12:12 PM, Christopher Barker <[EMAIL PROTECTED]> wrote: > Ben North wrote: > >> I tend to use matplotlib over an X connection, Yep, we know this reason. Lee stated he was on a windows box, which doesn't rule out X11 forwarding but makes it less likely, so I was wondering if there was another reason. I went ahead and applied the patch so those of you using native backend wx can test his image support enhancements. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] How to add a new backend?
On Tue, Oct 21, 2008 at 8:04 AM, jason_h <[EMAIL PROTECTED]> wrote:
>
> Hello,
> we want to add a new backend for some specific XML format.
>
> Can I find somewhere a sort of How-To documentation about the required
> steps?
>
> In particular I want to avoid modifying the matplotlib installation which
> resides in system directories which not every user has access to. Is it
> possible to extend the backend base class to a full backend implementation
> located below my home directory, and then have matplotlib use this backend?
>
> How would I tell matplotlib about my new class, and how do I prepare things
> so that a simple
> matplotlib.use('MyXML')
> will plot in our file format?
If you set the backend to "module://my_backend" where my_backend.py is
a backend in your PYTHONPATH, matplotlib will load it and use it.
You can also use the -d flag, eg
> python simple_ploy.py -d file://my_backend
Let us know how it goes!
JDH
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] How to add a new backend?
On Tue, Oct 21, 2008 at 8:40 AM, John Hunter <[EMAIL PROTECTED]> wrote:
> If you set the backend to "module://my_backend" where my_backend.py is
> a backend in your PYTHONPATH, matplotlib will load it and use it.
And yes, I forgot to mention, "use" works as well
import matplotlib
matplotlib.use('module://my_backend')
and the syntax for the -d flag was wrong in my last email (it is
"module://" not "file://"), it should read::
> python simple_ploy.py -d module://my_backend
JDH
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] How to add a new backend?
On Tue, Oct 21, 2008 at 9:14 AM, jason_h <[EMAIL PROTECTED]> wrote:
> Unfortunately that doesn't work for me. I get a "ValueError: Unrecognized
> backend string "module://mybackend"" in rcsetup.py. Any other suggestions?
> Matplotlib ist version 0.98.3.
Hmm, strangely, the rcsetup function was reverted and as you note, is
broken, I just fixed it in svn to respect the flag, and tested with
the use directive and -d, both of which worked for me. If you don't
want to update to svn HEAD, you can edit rcsetup.py on your system and
replace::
validate_backend = ValidateInStrings('backend', all_backends,
ignorecase=True)
with::
_validate_standard_backends = ValidateInStrings('backend',
all_backends, ignorecase=True)
def validate_backend(s):
if s.startswith('module://'): return s
else: return _validate_standard_backends(s)
Should work...
JDH
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] doc build failure?
On Tue, Oct 21, 2008 at 12:52 PM, Eric Firing <[EMAIL PROTECTED]> wrote:
> I did svn up on Sphinx, deleted mpl doc/build, and tried to rebuild the
> docs. The Latex is failing with output ending in
>
> ) (/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty
> (/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty
> (/usr/share/texmf-texlive/tex/latex/graphics/trig.sty)
> (/etc/texmf/tex/latex/config/graphics.cfg)))
> (/usr/share/texmf-texlive/tex/plain/misc/pdfcolor.tex)
> ! Extra \fi.
> l.62 \fi\fi
>
>
> Is anyone else getting this? Is there something else I need to clean
> out in order to make it work now?
Try again, and make sure you reinstall mpl from HEAD? There were a
couple of bugs in the matplotlib.mlab.cohere math string that was
causing an error on my box
C_{xy} = \\frac{|P_{xy}|^2}{P_{xx}P_{yy}}
It looks like I forgot to commit the change (now in r6289).
JDH
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] navigation toolbar keyboard shortcuts patch
On Tue, Oct 21, 2008 at 8:57 PM, Paul Ivanov <[EMAIL PROTECTED]> wrote: > Here's an updated patch: > > I decided to go with 'c' and 'v' for Back and Forward since these keys > are in the same place on most localized keyboard layouts (sorry, dvorak > users) (as JDH pointed out, I could not use 'z' and 'x' because 'x' is > used as a modifier in Pan/Zoom mode) > > I've added a ReST table detailing all of the key bindings as per JDH's > suggestion. Thanks Paul, for the enhancements, and especially for doing the extra work to document the functionality and test the docs. Applied to svn 6291. If you are inclined, we probably need an rc param or something like that to determine which keys mpl responds to since, as we have more of these, we increase the risk that we get in the way of application developers embedding mpl. Eg, in matplotlibrc, one could do toolbar.keys : x, y, c, v, g, f, p, z, control, left, right # with docs describing what key does what So the user could turn off any or all of these. Then in backend_bases, before we issue an event based on a key stroke, we could check this default list to make sure the user wants mpl handling these events. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Error in the pyplot tutorial
On Wed, Oct 22, 2008 at 12:03 PM, Adeodato Simó <[EMAIL PROTECTED]> wrote: > In http://matplotlib.sourceforge.net/users/pyplot_tutorial.html it says: > > | You may be wondering why the x-axis ranges from 0-3 and the y-axis > | from 1-4. > > The axis in the image ranges from 0 to 2 (X) and from 1 to 3 (Y). Thanks, fixed in svn 6309 (but not yet pushed out to the site) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] problems with shared axis
On Mon, Oct 27, 2008 at 4:09 PM, Eric Firing <[EMAIL PROTECTED]> wrote: > None that I know of. It would certainly be nice if we had the release > package-building completely automated; or automated daily svn builds of the > Win and OSX packages. Since I don't work with either Win or OSX, I don't > know how hard this would be to set up. Nightly builds would be excellent -- Charlie, to what extent do you think this is feasible from a scripting perspective? Ie, ignoring the hardware side for a minute, and assuming we had access to a build farm with OS X and win32, how hard would it be to setup a build bot for nightly builds? JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl from svn build failure?
On Mon, Oct 27, 2008 at 8:49 PM, Fernando Perez <[EMAIL PROTECTED]> wrote: > src/_tkagg.cpp: In function 'int PyAggImagePhoto(void*, Tcl_Interp*, > int, char**)': > src/_tkagg.cpp:134: error: no match for 'operator*' in > '*aggRenderer->RendererAgg::renderingBuffer' > error: command 'gcc' failed with exit status 1 > > John, this is on bic, in case you want to have a look. I saw this too, and emailed Michael off list earlier. He committed a significant cleanup earlier of backend agg to reduce the number of heap allocations, and somehow tkagg got out of whack, at least on some platforms. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Native backend for Mac OS X
On Tue, Oct 28, 2008 at 12:24 PM, Eric Bruning <[EMAIL PROTECTED]> wrote: > Nice work ... and an ambitious effort. > > I've gotten it running, and am a bit perplexed by some of the > performance I'm seeing. Specifically, the following bit takes well > over twice as long to run as does WxAgg. Does this align with others' > testing? I haven't had a chance to look at the code yet, but I suspect he hasn't implemented the path collection draw method. If it's not implemented, we fall back on drawing each path separately, which is a lot slower. scatter ultimately triggers a call to Renderer.draw_path_collection which has a default implementation and a specialization in backend_agg. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Event handling example not working
On Wed, Oct 29, 2008 at 4:00 PM, Ryan May <[EMAIL PROTECTED]> wrote: > Here's probably a better question to ask than just to fix the example. > Was it intended that the Rectangle.xy attribute disappear? I couldn't > find it documented in API_CHANGES. It appears that there was just a > change at some point in Michael's transforms work. If it's considered > desirable to have it back, I'll volunteer to whip up a patch to make it > a property. If not, let's just make sure we document this in API_CHANGES. I have no problem with you adding it back in as a convenience property. Can't see the harm. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] legend class with paddings in canvas unit
On Thu, Oct 30, 2008 at 2:59 AM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote:
> Basic idea is to create a new version of the Legend class with a same
> interface to the current one.
> Eric's original suggestion was to use some optional kwarg to choose the
> version.
> But I found this approach does not work well unless we also set the
> meaningful default values in the rc file. For example, the current
> "legend.axespad" in rcsetup.py is 0.02 which is in axes unit. But this
> need to be ~10 (if given in points) or ~0.5 (if given in fraction of
> the font size) in the new class.
I think we should deprectate the axes pad kwarg. If you see it coming
in (not None), make a reasonable points approximation to a pad using
the figure dimensions and axes dimensions and dpi, and issue a warning
padpoints = # compute something here from figsize, axes rect and axespad
warnings.warn("axespad is a deprecated argument to legend. The
new argument is "padpoints" and is in points. Assuming %1.1f
ponts"%padpoints)
That way we won't go crazy supporting 2 versions of something, users'
code won't break initially or fail silently, nd users will have a
clear migration path.
Does that work? Anyone who is using axespad is something of a power
user and will have no problem fixing up their code.
JDH
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] annotation with fancy arrow
On Thu, Oct 30, 2008 at 12:32 AM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote: > John and others, > > I submitted a patch of the fancy arrow I mentioned a while ago. > > http://sourceforge.net/tracker2/?func=detail&aid=2209021&group_id=80706&atid=560722 Hi Jae Joon -- sorry for not responding. I had completely missed this. Reminding us on the mailing list is definitely a good idea because I tend to fall behind quite often. The patch and new example look great. My only requests for changes (or for next time) are stylistic: - when making a significant contribution like this, please add a change to the CHANGELOG, since that is what many people use to see what's new and what we use to make the release notes. I've done this already for this one. - try and document every method using the rest documentation conventions. See http://matplotlib.sourceforge.net/devel/documenting_mpl.html. Since we have been working hard on the website and API docs, the one thing I'd like to ask of you is to make sure all the docstrings are updated including a bit of module level documentation in bezier -- then I will add bezier to the API docs - for triple quoted docstrings, I would like to stick to the format:: def myfunc(args): this is my docstring rather than def myfunc(args): this is my docstring - I renamed bezier_util to bezier (PEP8 style guide advises to avoid underscores and make module names as short as is reasonable), and we should import it with the full name "from matplotlib.bezier import ..." rather than "from bezier import ..." - is using a string for connectionstyle the best choice? Ie, instead of:: connectionstyle="angle,angleA=0,angleB=90,rad=10" would we rather have something like:: connectionstyle=connectionstyle.angle(angleA=0,angleB=90,rad=10) The latter looks more pythonthic and extensible, because if we document the connectionstyle API users can provide their own. These are of course mostly minor stylistic nits, but I want the code to be as uniform as possible. I've committed this to svn r6353, and updated the website, so you can see your examples in the gallery and examples pages: http://matplotlib.sourceforge.net/gallery.html http://matplotlib.sourceforge.net/gallery.html Very nice contribution! JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] SVG clickable images
On Thu, Oct 30, 2008 at 8:10 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> In the specific case of bar(), one may still be forced to manually set
> urls on each Rectangle if one wants those urls to be different. But
> this is no different than the current situation wrt facecolor or any
> other attribute, since bar is not written on top of Collection.
better yet would be to replace the list of rectangles with a patch
collection, do the same for pie, etc. Then a single URL on the
collection would apply to the batch. This would break a fair amount
of code, but we might be able to minimize the pain by providing an
iter interface and a getitem interface to the collection, which warns
and does the right thing. So users who did
# bars was a list of Rectangles, now it is a PatchCollection
for bar in bars:
bar.set_facecolor('red')
would get working code and a warning telling them to just do
bars.set_facecolors instead.
And, yes, the example is *very cool*
JDH
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] annotation with fancy arrow
On Thu, Oct 30, 2008 at 9:28 AM, Darren Dale <[EMAIL PROTECTED]> wrote: > Line 2900 in patches.py is not compatible with python-2.6. "as" is protected > and cannot be used as a variable name. good catch - -fixed in r6355 JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] annotation with fancy arrow
On Fri, Oct 31, 2008 at 5:12 AM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote: > But I guess this can be simplified. > And, I may gather those Connector classes under a single class (or a > module). And same for arrowstyle classes and boxstyle classes. Yes, I think this is the way to go -- uses classes for all of these rather than strings. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Auto backend discovery at start time
On Sat, Nov 1, 2008 at 5:37 AM, Sandro Tosi <[EMAIL PROTECTED]> wrote: > Hello guys! > Following up the discussion Benjiamin and me had about a couple of > bugs in Ubuntu[1] and Debian[2], and what Mike wrote on [1], we'd like > to explore the possibility for you to develop a "backend=Auto" mode, > that can discover automatically at runtime the backend to use from the > ones available (in case of multiple backends, let's use a priority > list [gtk, qt, tk, ...]). This should be fairly easy to implement -- we already do something like this at build time when we choose the default backend to put into the template. FYI, since you are a packager, I jwant to clarify what happens at build time. We have a file called setup.cfg.template which is a template for people who want to override the default behavior. You can copy this to setup.cfg and choose what default backend you want, and the setup program will create an rc configured accordingly. But if someone has not done this, the setup script will look (at build time) for gtk, wx, and tk, and set the backend in order of increasing preference: Agg, TkAgg, WXAgg, GTKAgg. The file matplotlibrc.template is then used to generate the default matplotlibrc, with this backend selected. This matplotlibrc is installed to matplotlib/mpl-data/ and is used as the default config if the user does not override it. As a debian/ubuntu packager, you will probably want to use setup.cfg and set your backend manually. You may want to use TkAgg since in some ways this is the simplest backend to use in the most contexts, primarily because it does not require special threading calls to work interactively in the python shell -- see http://matplotlib.sf.net/installing.html But an "Auto" feature would be useful in other contexts too. One area is when matplotlib is embedded in a GUI IDE matlab-like application. There are several of these that are being worked on in different user interfaces, primarily using the new embeddable ipython, and the concern there is that the user may be using one application which embeds a python shell, and when users import pylab in that shell, the ought not to have to think: "now I am using python in a wx app, so I need to sert wxagg" but in other scenarios, "now I am using pylab in a plain python shell so use tkagg" The auto search algorithm should go something like the following: * if tkinter, wx, gtk or qt has already been imported in sys.modules, use that backend - Gael has already an implementation in the pyplot module using the rc param 'backend_fallback' * if backend = 'auto': try in order of preference :tkagg (most likely to work in most contexts), gtkagg, wxagg, qtagg. This order could easily be configurable * if none of the UIs are available in 'auto' mode, issue a warning and set 'agg' If I were packaging for ubuntu, I would select tkagg as the default, so you don't have to wade into the GNOME vs KDE arena and because it works out of the box in the most contexts and is a pretty small dependency. You could modify the matplotlib runtime so that when the .matplotlib directory is created (the first time mpl is run) it issues a message like Creating config directory ~/.matplotlib. The default user interface toolkit for matplotlib is TkInter via the "TkAgg backend" (see http://matplotlib.sourceforge.net/faq/installing_faq.html#id1). You use other backends, you will need to install additional ubuntu dependencies. For GTKAgg, install python-gtk, for WXAgg, install python-wxgtk, etc..." > Personally, I think we can even attack the problem with a different > solution: continue to ship all the mpl file in the "main" package > (python-matplotlib in Debian & Ubuntu) and then create some "dummy" > packages that simply depends on the python gui bindings (let's call > them python-matplotlib-), each of them providing a virtual > package, let's call it python-matplotlib-backend. If python-matplotlib > depends on python-matplotlib-gtk OR python-matplotlib-backend, any > backend installed can satisfy that dependency (and the default being > gtk). That should work fine, but I advise installing all of mpl and use these dummies only for dependencies. > Both of them has cons: the first poses problem to us for the > packaging, and both does not solve the problem of not choosing a > default (or requiring to specify another package (the backend chosen) > when installing python-matplotlib); moreover, what other packages > depending on python-matplotlib should do after this change (they > expect mpl to Just Work)? Well, if the package that depends on mpl requires for example wx and the wx backend, then it is enough for them to get a full mpl install and handle the wx dependency in their package. They would need to make sure that the right mpl backend is selected when they import mpl, but they can do that with the use directive. > Another solution (that would save the most of the current work done), > almost the same currently used today is: keep
Re: [matplotlib-devel] mlab.psd API
On Wed, Nov 5, 2008 at 4:55 PM, Ryan May <[EMAIL PROTECTED]> wrote: > Hi, > > How much freedom would I (and my colleague) have in changing up some of > the behavior/API of mlab.psd? My current issues with the function: > > 1) Returning one-sided or two-sided depends on whether the data is > complex. I'd like that to be controlled by a keyword parameter (could > take strings, such as 'two-sided' like matlab) Sounds good > > 2) We'd like to add a parameter to control how many points are used for > performing the FFT (automatic zero padding for increased plotting > detail). The obvious name for this would be nfft, but this seems to > conflict with the NFFT parameter. NFFT, confusingly, is used to specify > the blocksize used for averaging. If we can't outright change names > here, I'd love for suggestions on a good way forward. I wrote this function a *long* time ago, so my memory is a little hazy, but I don't find the terminology confusing. The method breaks the sequence into NFFT sized chunks and does an fft on each NFFT length piece, so that is the length of the fft. Perhaps an addition pad argument if you want to zero pad the chunks? I intended to replicate the matlab function when I wrote this, and vaguely recall that I did some close comparisons on the output, but if I am misusing this parameter let me know. Some (possibly dated) matlab docs are here: http://www.mathworks.com/access/helpdesk/help/toolbox/signal/index.html?/access/helpdesk/help/toolbox/signal/periodogram.html > 3) Can we remove the requirement for even NFFT (blocksize)? Sure A while back someone on the list said that the amplitude scaling for psd was of, but I never delved into it. Something you may want to check into while you are poking around in there. http://www.nabble.com/forum/Search.jtp?forum=2906&local=y&query=psd+amplitude JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] logo example plots are wrong
On Sat, Nov 8, 2008 at 5:53 PM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote: > Yes, the script also works for me. > It seems that the version on the web is picking up a wrong font file. I flushed my font caches and rebuilt and the text is looking OK now. It may be that some combination of old font caches with Michael's recent changes to the font finder caused some grief, so everyone working from svn may want to flush the cache. Perhaps we should introduce version tagging on the caches, so these get flushed periodically on upgrades. I pushed the new docs up to the site - thanks for letting me know... Now I really better get back to the wife and kids :-) JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] SF.net SVN: matplotlib:[6385] trunk/matplotlib/lib/matplotlib/cbook.py
On Mon, Nov 10, 2008 at 1:59 PM, Ryan May <[EMAIL PROTECTED]> wrote: >> I am not even sure if the above is the fix we want, but having numpy >> string array elements fail "is_string_like" seems like a fundamentally >> bad thing. we definitely want numpy strings, eg in a record array, to return True here. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Repeating docs
On Tue, Nov 11, 2008 at 1:38 PM, Ryan May <[EMAIL PROTECTED]> wrote: > 1) Have psd(x) call csd(x,x) > 2) Have csd() check if y is x, and if so, avoid doing the extra work. > > Would this be an acceptable solution to reduce code duplication? Sure, that should work fine. > On a separate note, once I get done with these tweaks, are there any > objections to submitting something based on this to scipy? No objections here -- if it were put into numpy though, we could depend on it and avoid the duplication. I would campaign for numpy first, eg np.fft.psd, etc. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Repeating docs
On Tue, Nov 11, 2008 at 10:35 AM, Ryan May <[EMAIL PROTECTED]> wrote: > Hi, > > In tweaking mlab.psd(), I'm noticing there is a lot of overlap between > the keyword args for psd() and csd(). In fact, csd() doesn't document > them itself, but just references psd(). Additionally, the csd() and > psd() Axes methods duplicate these docs, with a few additional > parameters. Would it be a good thing to restructure the duplicated docs > into it's own string that can be incorporated when necessary? Or is > this kind of "monkey patching" of the docs something we're trying to > minimize? No, this is something we are doing more of lately (eg see the contour docs) but the psd, csd, cohere predated this docstring manipulation. So feel free to consolidate. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] legend marker clipping
On Sat, Nov 15, 2008 at 6:50 AM, Jozef Vesely <[EMAIL PROTECTED]> wrote: > legends outside axes display only line without markers. > Somebody forgot to unset clipping. It appears Eric already fixed this in svn: r6127 | efiring | 2008-09-27 19:44:08 -0500 (Sat, 27 Sep 2008) | 4 lines Enhancement to Axes.spy, and bugfixes: figlegend was not plotting markers; plot could not handle empty input arrays. So please give svn a test if you have a chance. Thanks for the patch. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] memory leak
On Fri, Nov 21, 2008 at 4:24 AM, Benoit Zuber <[EMAIL PROTECTED]> wrote: > Hi, > I posted this on maplotlib-users list, but got no reply. I guess that > bugs should rather be reported here... Could you post a *complete* script that demonstrates the leak, eg one that calls the function and does any other cleanup? Does it help to use gc.collect between function calls? JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] memory leak
On Fri, Nov 21, 2008 at 7:04 AM, Benoit Zuber <[EMAIL PROTECTED]> wrote:
>
>> > I posted this on maplotlib-users list, but got no reply. I guess that
>> > bugs should rather be reported here...
>>
>> Could you post a *complete* script that demonstrates the leak, eg one
>> that calls the function and does any other cleanup? Does it help to
>> use gc.collect between function calls?
>
> Thanks for your reply. Here is the complete script (I was running the
> previous one interactively).
> In fact, I realised that the memory leak is not total... I mean that the
> RAM gets loaded during the first two iterations, which correspond to a
> load of 1.9Gb (I have 4Gb RAM in total). Then the RAM usage remains
> absolutely stable.
>
> I then tried to run this script interactively in ipython. Once the
> script ends, the RAM is not released (1.9Gb are still used).
> Nevertheless, when I call fa() once again, the memory load remains the
> same. So this leak does not lead to a crash, which is fine.
>
> Finally if I comment "matplotlib.use('Agg')", then the load is
> increasing during each iteration, saturating the RAM, and starting
> filling up the swap. In this case the output of the script is :
If you comment out agg you are using a gui backend presumably (which
one) and most of these are known to have some leaks, some of which are
beyond our control. Michael has recently made some change to
significantly reduce a gtk leak.
When you say you are working interactively, do you mean from the
python or ipython shell? ipython holds a reference to the names the
main module namespace, which could be preventing a gc cleanup. After
reading your post, I am not clear if you still have a problem or not.
>From the data you posted, it appears that agg is not leaking in your
example.
JDH
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] memory leak
On Fri, Nov 21, 2008 at 7:53 AM, Benoit Zuber <[EMAIL PROTECTED]> wrote: > >> If you comment out agg you are using a gui backend presumably (which >> one) and most of these are known to have some leaks, some of which are >> beyond our control. > > This leak happened without any gui backend when I ran the script from the > csh prompt like that: >> python script.py Well, you are still using some backend, probably a GUI one, even if no figure pops up. You can run your script with --verbose-helpful to see what is happening. >> After >> reading your post, I am not clear if you still have a problem or not.>From >> the data you posted, it appears that agg is not leaking in your >> example. >> > > It is not a problem anymore, using the 'Agg' solved the problem. Great JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Custom-sized and spanning subplots
On Fri, Nov 21, 2008 at 8:08 AM, Stan West <[EMAIL PROTECTED]> wrote: > While I check out the mplsizer toolkit, I'm still interested in any feedback > on my ideas for subplot layout features. Does anyone have any critiques, > concerns, preferences, suggestions, etc., to voice? Thanks. My main comment is to not try and reuse subplot for this. Subplot is a very thin wrapper of Axes, which handles layout on a regular grid. You want your grids to be irregular, so make a new subclass of Axes that acts the way you want. This will be easier than trying to tack extras complexity on top of subplot. We can then expose it to the toplevel with ax = fig.add_your_new_axes(whatever) and to pyplot. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] memory leak
On Fri, Nov 21, 2008 at 8:17 AM, Benoit Zuber <[EMAIL PROTECTED]> wrote: > Sorry, I did not realise it (I suppose, I did not quite know what backend > means, now I checked it on wikipedia ;-) . Running the script with > --verbose-helpful told me that the backend was GTKAgg version 2.10.1 Here is some additional documentation of backends from the mpl perspective: http://matplotlib.sourceforge.net/faq/installing_faq.html#id1 JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] shared axis zoom bug
pan/zoom appears to be broken in the sharex axis demo. If you do a zoom to rect on ax2 or ax3 in examples/pylab_examples/shared_axis_demo.py the event seems to be swallowed, though a zoom in ax1 is respected. I know Eric was recently working on autoscale support for sharex axes r6315 | efiring | 2008-10-23 19:08:58 -0500 (Thu, 23 Oct 2008) | 2 lines Support autoscaling with shared axes And perhaps the current bug is related to the problem Michael wrote about earlier in the thread: "shared axes" bug in matplotlib 0.98 Back when the 0.98 transformations were being written, John and I had a long discussion about whether data limits should be Bbox-like or pair-of-intervals-like, and we ultimately decided to leave things as-is to avoid creating too much newness at once. IMHO, however, the real problem is that the shared axes mechanism doesn't know whether the limits are changing because of autoscaling (in which case the limits should be unioned together), or panning/zooming, in which case the limits need to be replaced. The second problem is probably necessary to fix whether we use Bboxes or not. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] shared axis zoom bug
On Tue, Nov 25, 2008 at 12:16 PM, John Hunter <[EMAIL PROTECTED]> wrote: > pan/zoom appears to be broken in the sharex axis demo. If you do a > zoom to rect on ax2 or ax3 in > examples/pylab_examples/shared_axis_demo.py the event seems to be > swallowed, though a zoom in ax1 is respected. The problem appears to be in the backend_bases NavigationToolbar2.release_zoom method. I have updated svn r6447 with # JDH: I don't know why this is here but I expect to be # able to zoomo on any axis that is shared. This was # breaking zoom-to-rect on shared_axis_demo if the zoom # happened in ax2 or ax3 so i am replacing the continue # with a pass until this is sorted out if a._sharex or a._sharey: #continue pass If anyone knows why the continue was/should be there, speak up! JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] shared axis zoom bug
On Tue, Nov 25, 2008 at 12:28 PM, John Hunter <[EMAIL PROTECTED]> wrote: > On Tue, Nov 25, 2008 at 12:16 PM, John Hunter <[EMAIL PROTECTED]> wrote: >> pan/zoom appears to be broken in the sharex axis demo. If you do a >> zoom to rect on ax2 or ax3 in >> examples/pylab_examples/shared_axis_demo.py the event seems to be >> swallowed, though a zoom in ax1 is respected. > > The problem appears to be in the backend_bases > NavigationToolbar2.release_zoom method. I have updated svn r6447 with > ># JDH: I don't know why this is here but I expect to be ># able to zoomo on any axis that is shared. This was ># breaking zoom-to-rect on shared_axis_demo if the zoom ># happened in ax2 or ax3 so i am replacing the continue ># with a pass until this is sorted out >if a._sharex or a._sharey: >#continue >pass > > If anyone knows why the continue was/should be there, speak up! OK, I think I see where this came in. I did an svnmerge the other day from the branch, and merged in Michael's change: r6365 | mdboom | 2008-11-05 09:15:28 -0600 (Wed, 05 Nov 2008) | 1 line Fix bug in zoom rectangle with twin axes Michael, perhaps you can comment on this bugfix on the branch, and whether this change or something like it should be in the trunk? I see the trunk has some additional logic that the branch does not have: # detect twinx,y axes and avoid double zooming twinx, twiny = False, False if last_a: for la in last_a: if a.get_shared_x_axes().joined(a,la): twinx=True if a.get_shared_y_axes().joined(a,la): twiny=True JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] shared axis zoom bug
On Tue, Nov 25, 2008 at 1:31 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > The trunk has effectively the same fix already in that additional code you > point out. Its purpose is to make sure the zoom happens only once for each > grouping. It could probably be done better, but it does work. OK, thanks for the explanation. I've purged the invalid merge from the trunk. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] wrote a selection bar widget (attached)
On Wed, Nov 26, 2008 at 5:34 AM, Egor Zindy <[EMAIL PROTECTED]> wrote: > Dear matplotlib devels, > > I wrote a selection widget someone else might find useful. The widget is > based on the slider widget.> > Things I implemented: > * blitting (bar still flashes once when clicked on, sorry about that!) > * Horizontal or vertical direction > * Multiple selection bars on a figure > * interaction between two bars to set a range I think this is a useful tool, but I would like to see a few enhancements, some of which you mention below. > Things I struggled with: > * When a bar is dragged towards one of the figure edges too quickly, it gets > stuck in its last recorded position on the graph (that should be the figure > edge). I think the cause of this is when your mouse leaves the axes, the axes stops processing events, so it no longer gets updates to move the bar. I'm not sure what the right solution is though. > * Don't know how to change the mouse pointer when on top of the bar (the <-> > pointer for a vertical bar would be nice) In backend bases there is a cursors enum::: In [5]: import matplotlib.backend_bases as bb In [7]: bb.cursors.HAND Out[7]: 0 In [8]: bb.cursors.MOVE Out[8]: 3 and you can use the canvas toolbar to change the cursor In [11]: fig.canvas.toolbar.set_cursor(bb.cursors.MOVE) > * Don't know how to define a range in pixels around the bar (for grabbing), > so used 0.01 of the full range instead Read the event handling and picking tutorial at http://matplotlib.sourceforge.net/users/event_handling.html if you haven't already. I suggest doing the hit testing in figure rather than data coordinates. So instead of val = event.xdata if val < self.val + self.radius ... do something like the following:: def _update(self, event) # store the line location in pixel space self.linex = event.x def _press(event): if abs(event.x-self.linex)<=5: # 5 pixels # hit! > * Haven't implemented dragging when a bar reaches the other bar (set with > set_barmin or set_barmax) but hasn't reached the limit of its range. > > How to test: > have mplbar.py and test_bar.py in the same directory, launch test_bar.py > > > Hope this all makes sense (somehow I doubt it). And like I said, if you guys > like it or want to adapt it further, please do, the code this is based on is > yours after all! With some additional cleanup along the lines of the above, I would be happy to accept this. Please document every method (I realize some exisint code does not meet this standard but we are trying to improve). Also, please use the rest conventions when documenting new code; the widgets code has not been ported over but a lot has -- see http://matplotlib.sourceforge.net/devel/documenting_mpl.html One feature you may want to consider. I think it would be nice to have color coded ticks, or possibly a static hspan along the regions where the bar can slide. Eg, see the following minor modification to test_bar:: bar1 = mplbar.Bar(ax1,valrange=[10,60],useblit=True, lw=2, color='g') ax1.axvspan(10, 60, ymin=0, ymax=0.05, facecolor='g', alpha=0.2) #range 10 to 60, init value set to 60, use blit, blue bar2 = mplbar.Bar(ax1,valrange=[10,60],valinit=60,useblit=True, lw=2, color='b') ax1.axvspan(10, 60, ymin=0.95, ymax=1.0, facecolor='blue', alpha=0.2) #range 30 to +inf (None = no bound), default set to 30, use blit, horizontal line, red bar3 = mplbar.Bar(ax1,valrange=[30,None],useblit=True, direction='horizontal', lw=2, color='r') ax1.axhspan(30, 2*npts, xmin=0.95, xmax=1.0, facecolor='red', alpha=0.2) Of course the use can always add this, so I am not sure if it is worth building in... but support for something like this via a kwar might be nice, eg Bar(blah, ..., showrange=True, rangespan=[0.95, 1.0]) JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] wrote a selection bar widget (attached)
On Wed, Nov 26, 2008 at 10:41 AM, Drain, Theodore R <[EMAIL PROTECTED]> wrote: > I'm pretty sure this is exactly what's happening. This is also annoying when > you're trying to use a zoom rectangle and want to start at some point in the > plot and drag it to the boundary. We've been planning on putting some time > in to fix this this but just haven't been able to make the time yet. > > I think one possible solution is that anytime the mouse moves outside the > axes, it should get one last event that is at the boundary which would > require tracking which axes the last event was sent in. We haven't tried to > see how hard that is to implement thought... probably fairly easy using a class level attr in the MouseEvent. Another possibility would be to add support for figure_enter_event, figure_leave_event, axes_enter_event, axes_leave_event. The user code would have to separately process the axes_leave_event but this might be the cleanest solution. I am happy to add support for these ... JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] wrote a selection bar widget (attached)
On Wed, Nov 26, 2008 at 10:59 AM, John Hunter <[EMAIL PROTECTED]> wrote: > probably fairly easy using a class level attr in the MouseEvent. > Another possibility would be to add support for figure_enter_event, > figure_leave_event, axes_enter_event, axes_leave_event. The user code > would have to separately process the axes_leave_event but this might > be the cleanest solution. I am happy to add support for these ... I just committed axes/figure enter/leave event notifications, with example in examples/event_handling/figure_axes_enter_leave.py. If you register for a leave event, you will get passed the last event that was in your axes/figure before it left Everything is working well with one caveat -- a figure leave event is only triggered when you enter a new figure, not simply when you leave the figure. This is because I just used the existing mpl LocationEvents to support the new events, and none of these are created when you are not over a canvas. To properly handle the figure leave events, we will need to tap into the underlying GUI leave events. The axes leave events work fine, with the one caveat that if the axes region is [0,0,1,1] you may not see the leave event for the same reason you do not see the figure leave event until you are over another canvas. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] wrote a selection bar widget (attached)
On Wed, Nov 26, 2008 at 11:57 AM, Egor Zindy <[EMAIL PROTECTED]> wrote: > thank you, I'll have to check out the repository to see how I can use the > changes. > > Just a thought: a figure_leave / figure_enter event could be triggered by > comparing the currently held axis with event.inaxes (that's what Slider and > my bar widget do in _update() ). That's exactly how its done. The problem I referred to above (which will not affect your use case since you are leaving the axes) occurs when you want to connect to a figure leave event and move your mouse to a non-mpl window. Then we get no events to compare to the prior. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] help request: wx, tk, qt backend leave event
I recently added support for a figure/axes enter/leave event. The figure enter and axes enter/leave are easy to do with nothing new in the backends, just using the native mpl events. The figure leave event is harder, because when a user leaves a figure and activates another window, mpl gets no events. To correct this, I added a leave_notify_event method to backend_bases.FigureCanvasBase (note this is not an mpl Event) but when called it will trigger a callback to those registered to the figure_leave_event with the last event that occurred in the window. I added support for this in gtk by connecting the the gtk signal 'leave_notify_event' to the mpl backend method leave_notify_event. If you know something about tk, wx or qt event handling, could you add a similar method to the appropriate backend? You can follow the example in backend_gtk. You can test with examples/event_handling/figure_axes_enter_leave.py Thanks, JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] selection bar widget - new version with showrange and push
Hi Egor -- thanks for the update. For future posts on the same theme, could you please respond to the existing thread rather than creating a new one. This makes it easier for people who are following a thread to keep following it, and those ignoring it to keep ignoring it. Importantly, for future generations of googlers and nabblers, it makes it easier to follow a single conversation. If you feel like you earlier post fell on deaf ears because you got no response, its more likely that we fell behind than that we didn't see it, because all of us have threaded news readers. Just "bump" the thread with a polite and gentle "did anyone have a chance to test this?" rather than creating a new thread Comments on the patch inline below. On Fri, Nov 28, 2008 at 8:19 AM, Egor Zindy <[EMAIL PROTECTED]> wrote: > A few things I added this time round: > * showrange keyword (as per John's suggestion) > * push keyword This is a nice enhancement -- could you also add a keyword arg so users can customize the min/max of the span. You've hardcoded [0.99...1], which may be a little tight for some users. Also, it prevents being able to place one span on left, one on right, for multiple bars, etc.. Something like rangelim=[0.99, 1.0] as a kwarg should be fine. > New problems: > * Not sure how to make an axvspan / axhspan span from -inf to value or value > to +inf. I use None in my valrange keyword to indicate that but using None > as an argument in axvspan doesn't help much... This is a bit tricky. Probably the best way to do it is to connect to the xlim_changed and ylim_changed events of the Axes, and update the bar line to encompass the current view limits. > * My push keyword kind of works now (see the example, green line can push > the blue line) but the implementation is a real mess. I might have to > rewrite the blitting (I need a background image with none of the bars so > that I can use that for blitting). I am not seeing any effect of push when I push the green line over to blue in your example; not exactly sure what is supposed to happen. If you set the animated property on all the bar lines, none of them will be rendered on a normal draw, which may help you control the blitting. > Other problems (in my previous posts) still stand: > * there is a toobar.set_cursor() but no toolbar.get_cursor() which would be > interesting to have to set the cursor back to what it should be (rather than > arbitrary POINTER type). You can add a get_cursor method in your next patch -- see below :-) > * more cursor types would be nice (could do with size_ver and size_hor in > http://wiki.openusability.org/guidelines/index.php/Design_and_Layout:Visual_Design:Cursors). > * took a long time to check out matplotlib from SVN, have yet to check the > new events out. I would be happy to accept as many cursor types as you want to add. The trick is that we need to support them across the 4 major user interfaces (tk, wx, gtk, qt). So we shouldn't go crazy with lots of cursor types that we can't support across backends. If you would like to patch backed_bases and one or more of the other user interface backends, we can extend the number of cursors we support. http://wxpython.org/docs/api/wx.Cursor-class.html http://www.pygtk.org/docs/pygtk/class-gdkcursor.html http://doc.trolltech.com/4.4/qcursor.html http://www.tcl.tk/man/tcl8.4/TkCmd/cursors.htm We don't have to support the least common denominator of all these, but it would be nice to support all the cursors that all support, and maybe a few more that one or more don't support but can use a reasonable proxy for. If you are interested in adding support for this in your next patch, that would be great. > * a nice name? (been struggling with that a lot lately!) Is "Bar" OK? or > maybe "SelectionBar"? I am not wild about Bar either -- how about ScalarSelector, which is a fits in fairly well with the existing SpanSelector... When you are ready to submit something for inclusion in mpl, please get a fresh svn checkout (slow or not) and submit a svn diff -- see http://matplotlib.sourceforge.net/faq/howto_faq.html#contributing-howto JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] markersize change
On Sat, Nov 29, 2008 at 3:55 PM, Andrew Straw <[EMAIL PROTECTED]> wrote: > Hi All, > > I have been testing the latest svn matplotlib, which failed to produce > any visible data in some long-standing scripts of mine. :( > > Investigating further, my use of markersize=0.5 combined with the '.' > symbol and the Agg backend caused a complete disappearance of the > markers. I'm attaching example images from 0.93.3 and the most recent > SVN using the attached script. > > I'd be happy to track this down, but I think this might be a no-brainer > for someone on the list. Is this agg only? JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] reimplemented legend class
On Sun, Nov 30, 2008 at 11:53 AM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote:
> I have been working on reimplementation of the legend class, and I
> guess it is mostly done. The biggest change is how each items are
> placed. For this, I made a simple container class("offsetbox.py"),
> which can pack the mpl artists in a similar way as widget packing in
> gtk, tk, etc.
Hi Jae-Joon -- as usual this is great work, and brings one of the
oldest, hairiest, parts of the code into the modern age. I went ahead
and committed this to svn r6461 with some minor spelling corrections,
but I have some minor comments below which may be worth addressing in
a revision.
Aside from the legend enhancement, the important and general piece
here is the offset box, which could become a significant piece of the
low-level infrastructure (eg for axes layout) so I do want to make
sure we get this right. In particular, I'd like Andrew Straw, who has
a toolkit for sizers, and Michael Droettboom, who implemented the
Knuth boxes in support of mathtext, to take a look at the API and
provide some feedback as to whether if it looks sufficient.
I have some minor comments from the read-thru
+self.legendPatch = FancyBboxPatch(
+xy=(0.0, 0.0), width=1., height=1.,
facecolor='w', edgecolor='k',
+mutation_scale=self.fontsize,
)
Should we make this an option that defaults to True, eg fancybox=True,
so those who want an old-style rectangle can still get it?
+largecol = zip(range(0, num_largecol*(nrows+1), (nrows+1)),
+ [nrows+1] * num_largecol)
In general, we encourage the use of cbook.safezip over zip because it
traps hard to find bugs.
+class OffsetBox(martist.Artist):
+"""
+The OffsetBox is a simple container artist. The child artist are meant
+to be drawn at a relative position to its parent.
+"""
+def __init__(self, *kl, **kw):
I would like to stick to a standard *args, **kwargs naming convention
in mpl code
+def set_offset(self, xy):
+"""
+set offset of the container.
+
+Accept : tuple of x,y cooridnate in display units.
Is it worthwhile to allow other coordinate systems for the offsets
(points, data) or would this complicate the code with little benefit?
On a quick read-thru, it looks like we would just need to supply an
optional transform arg and transform the offset if necessary, so the
implementation would be pretty clean. I see that offset can be
callable -- is this the mechanism you intended to handle this case?
+'legend.borderpad' : [0.4, validate_float], # units are fontsize
I think you mean the "value is a fraction of the fontsize". In
general, there are a number of places where it is not clear from the
docstring what the units are (eg in the OffsetBox.set_offset)., so
this could be cleaned up a bit.
+ax1.plot([1], label="multi\nline")
For multi-line|, it appears that we are getting the default "baseline"
vertical alignment but for the legend, 'center' would probably be more
appropriate. Any idea how to get that to work?
Thanks again!
JDH
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] reimplemented legend class
On Mon, Dec 1, 2008 at 6:00 PM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote: > As implementing an optional transformation should be trivial, I'll > just go ahead an work on it. But it seems not clear to me how to > approach this without any specific use case given. In another thread yesterday, someone was asking about a general way to create a shadow effect. It occurred to me that we could probably use the offsetbox for this. One could create an offset box for a given artist that draws the artist offset from the original by 5 points or 5 pixels, in a gray color that creates the appearance of a shadow. Would this be a reasonable use case to test the offset transformation in either points or pixels? JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] help request: wx, tk, qt backend leave event
On Tue, Dec 2, 2008 at 8:34 AM, Gregor Thalhammer <[EMAIL PROTECTED]> wrote: > If a mouse button is pressed while leaving the figure the behaviour is > somewhat strange. First, a figure_leave_event is emitted. Then, further > moving the mouse outside the figure a new figure_enter_event is created. > This is the case since all mouse events, also movements outside the window, > are captured as long as a mouse button is pressed. This is a very convenient > behaviour for panning/zooming. However, when finally releasing the mouse > button no figure_leave_event is triggered. With the GTK backend such an > event is created. > So what should be the desired behaviour? Ahh, I hadn't considered this problem. It arises because I am using mpl location events to trigger the figure enter event. The solution is to use the gui event for the figure enter event too -- basically the gui needs to call the canvas.enter_notify_event. I added your patch and modified gtk to handle the enter_notify_event in svn r6468. Can you update, repatch wx to use it (and Darren qt)? Any takers out their to add support to tk? Thanks, JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] help request: wx, tk, qt backend leave event
On Wed, Dec 3, 2008 at 6:43 AM, Gregor Thalhammer <[EMAIL PROTECTED]> wrote: >> Can you update, repatch wx to use it (and Darren qt)? > > I attached a patch that emits a enter_notify_event if the mouse enters the > figure. Now the example behaves correctly. Thanks Gregor -- just committed this. I don't have any other feedback on the other points you and Darren are discussing yet JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] release? no, this time really I mean it
Despite my occasional recent murmurings to get a release out, which fall by the wayside as more pressing matters arise, I really would like to do a 0.98.4 ASAP. Part of the reason is that there are lots of great features and bug fixes that should be more easily accessible to others (in particular Jae-Joon's fantastic work), part of the reason is that the website gallery is getting farther apart from the last released version, and part of the reason is that I am giving a talk on Dec 12th to the NIPS "machine learning and open source software" (MLOSS) conference. http://mloss.org/software/ John Eaton, of Octave fame, is the other invited speaker to this session, and I want to put our best face forward. I would like to do the release this weekend if Charlie has time (Charlie?). So please get your bugfixes and cleanups in over the next couple of days, and let me know if there are any other critical show-stopper problems or critical bugs that should hold up the release. And if you have any extra time to spend taking out a few bugs on the tracker over the next couple of days, that would be great. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] experimental MPL git mirror online
On Wed, Dec 3, 2008 at 8:12 PM, Andrew Straw <[EMAIL PROTECTED]> wrote: > I just put my git mirror of the matplotlib svn repository online. This > is experimental in nature. Thanks to github for hosting this project. > Anyhow, I added instructions for how to use this (including to interact > with the central svn repository) here: > > http://github.com/astraw/matplotlib/tree/master/README.git > > Note that the initial downloads are about 150 MB in size. Just got an account, but am getting a permission denied on the first command. I tried both with the "git" and "jdh2358" users: home:~> git clone [EMAIL PROTECTED]:astraw/matplotlib.git mpl.git Initialized empty Git repository in /Users/jdhunter/mpl.git/.git/ ERROR: Permission to astraw/matplotlib denied to jdh2358. fatal: The remote end hung up unexpectedly home:~> git clone [EMAIL PROTECTED]:astraw/matplotlib.git mpl.git Initialized empty Git repository in /Users/jdhunter/mpl.git/.git/ Permission denied (publickey). fatal: The remote end hung up unexpectedly JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release? no, this time really I mean it
On Thu, Dec 4, 2008 at 12:38 PM, Charlie Moad <[EMAIL PROTECTED]> wrote: > Works for me. Let's aim for Saturday night so we have Sunday to test > it out. Doable? Great -- everyone please hold off adding any significant features before the release and focus any mpl time you have on outstanding bugs. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] symlog problem
There appears to be a bug in the 3rd subplot of symlog_demo.py because the ticker is generating an OverflowError on my powerbook. The problem is in SymmetricalLogLocator.__call__ when the vmin, vmax = self._transform.transform((vmin, vmax)) call transforms vmin,vmax=[-1,1] to [-3.30039237078e+17,1.0] numdec is set to 3.30039237078e+17. Then the while loop runs until I kill the job:: stride = 1 while numdec/stride+1 > self.numticks: stride += 1 This may have something to do with a platform specific floating point computations, because I am seeing different results on a linux box I am also testing on, but even there the results don't look right. For example, on that box, a 64 bit linux machine, I see [-1,1] transformed to [2.18190930577e-316, 6.90437063896e-310] and numdec=-1 but the example does run w/o crashing. In any case, it looks like there is some non-robust computation going on, and I'm hoping Michael has a quick insight :-) JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] using new in axes.hist
Axes.hist calls np.histogram with the "new" kwarg, which triggers a deprecation warning with svn numpy. Anyone have an opinion on whether this kwarg should be included in the upcoming mpl release? JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] using new in axes.hist
I think the version check is a good idea, so people won't get the annoying warning. Could you add this? Sent from my iPhone On Dec 7, 2008, at 2:22 PM, "Jae-Joon Lee" <[EMAIL PROTECTED]> wrote: > I'm currently using numpy 1.1.1 and np.histogram behave differently > depending on the "new" value. > ubuntu interpid and debian sid has numpy 1.1.1.1 and I presume that > this different behavior is still there. > So, as far as we're going to support numpy 1.1 and later, we may > better not to drop the "new" silently. > We may check the version number of the numpy in the hist() function, > and call np.histogram() accordingly. > > -JJ > > > On Sat, Dec 6, 2008 at 4:33 PM, John Hunter <[EMAIL PROTECTED]> wrote: >> Axes.hist calls np.histogram with the "new" kwarg, which triggers a >> deprecation warning with svn numpy. Anyone have an opinion on >> whether >> this kwarg should be included in the upcoming mpl release? >> >> JDH >> >> --- >> --- >> --- >> - >> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, >> Nevada. >> The future of the web can't happen without you. Join us at MIX09 >> to help >> pave the way to the Next Web now. Learn more and register at >> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ >> ___ >> Matplotlib-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] symlog problem
Unfortunately, today is a crazy day for me so I can't test until late tonight at the earliest. But Charlie, I do think we should hold the release until we resolve this. We should be able to fix and test this by tomorrow afternoon so perhaps Monday night for the release if everything is in order by then and you still have time. Sent from my iPhone On Dec 7, 2008, at 1:55 PM, "Jae-Joon Lee" <[EMAIL PROTECTED]> wrote: > John, > > I can't reproduce the error on my intel macbook. > Anyhow, it seems to me a bug in the code and bugs in numpy. > (I'm using numpy version 1.1.1, and I'm not sure these bugs are fixed > in newer numpy. ) > Can you try the patch below and see if this fix your problem? > > -JJ > > > > Index: lib/matplotlib/scale.py > === > --- lib/matplotlib/scale.py (revision 6487) > +++ lib/matplotlib/scale.py (working copy) > @@ -301,7 +301,8 @@ > self._linadjust = (np.log(linthresh) / self._log_base) / > linthre > > def transform(self, a): > -sign = np.sign(np.asarray(a)) > +a = np.asarray(a) > +sign = np.sign(a) > masked = ma.masked_inside(a, -self.linthresh, > self.linthresh, co False) > log = sign * ma.log(np.abs(masked)) / self._log_base > if masked.mask.any(): > @@ -328,6 +329,7 @@ > self._linadjust = linthresh / (np.log(linthresh) / > self._log_bas > > def transform(self, a): > +a = np.asarray(a) > return np.where(a <= self._log_linthresh, > np.where(a >= -self._log_linthresh, > > > > > > > On Sat, Dec 6, 2008 at 5:09 PM, John Hunter <[EMAIL PROTECTED]> wrote: >> There appears to be a bug in the 3rd subplot of symlog_demo.py >> because >> the ticker is generating an OverflowError on my powerbook. >> >> The problem is in SymmetricalLogLocator.__call__ when the vmin, >> vmax = >> self._transform.transform((vmin, vmax)) call transforms >> vmin,vmax=[-1,1] to [-3.30039237078e+17,1.0] numdec is set to >> 3.30039237078e+17. Then the while loop runs until I kill the job:: >> >> stride = 1 >> while numdec/stride+1 > self.numticks: >> stride += 1 >> >> This may have something to do with a platform specific floating point >> computations, because I am seeing different results on a linux box I >> am also testing on, but even there the results don't look right. For >> example, on that box, a 64 bit linux machine, I see [-1,1] >> transformed >> to [2.18190930577e-316, 6.90437063896e-310] and numdec=-1 but the >> example does run w/o crashing. >> >> In any case, it looks like there is some non-robust computation going >> on, and I'm hoping Michael has a quick insight :-) >> >> JDH >> >> --- >> --- >> --- >> - >> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, >> Nevada. >> The future of the web can't happen without you. Join us at MIX09 >> to help >> pave the way to the Next Web now. Learn more and register at >> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ >> ___ >> Matplotlib-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release? no, this time really I mean it
I am not at my computer so I can't check the maintenace branch changelog, but I know there have been a few bugfixes. Do any of them look significant? How many downloads have we seen on the maintenance branch vs the 98 trunk. My guess is there are not that many users and we could skip a cycle on the branch. Sent from my iPhone On Dec 7, 2008, at 2:46 PM, "Charlie Moad" <[EMAIL PROTECTED]> wrote: > Is there any need for a maintenance release? > > On Thu, Dec 4, 2008 at 1:53 PM, John Hunter <[EMAIL PROTECTED]> wrote: >> On Thu, Dec 4, 2008 at 12:38 PM, Charlie Moad <[EMAIL PROTECTED]> >> wrote: >>> Works for me. Let's aim for Saturday night so we have Sunday to >>> test >>> it out. Doable? >> >> Great -- everyone please hold off adding any significant features >> before the release and focus any mpl time you have on outstanding >> bugs. >> -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] using new in axes.hist
On Sun, Dec 7, 2008 at 2:55 PM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote: > I just committed the change. Although the change is trivial, I didn't > tested it in the numpy 1.2 or the svn version. I tested on numpy svn on a couple of platforms (OS X and linux) and this looks OK from my end. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] symlog problem
On Mon, Dec 8, 2008 at 6:37 AM, Jouni K. Seppänen <[EMAIL PROTECTED]> wrote: > I ran into the same problem independently on an Intel Mac (I didn't read > these messages until now) and came up with the first part of Jae-Joon > Lee's fix. It does fix the problem, at least for me - I suspect the > difference may not actually be in the platform but in the exact version > of numpy (I have 1.1.0). I also committed the other part of the fix. > > This does seem to fix the problem, but I think we should wait for > confirmation from John before releasing the code. This is looking good on my end -- thanks Jae-Joon and Jouni for the patches. JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] image pixel border bug
On Mon, Dec 8, 2008 at 8:16 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > I don't think it's a rendering bug. The entire first row of data is 0.0 and > -0.0, which maps to red. The real solution would be to map 0 and -0.0 to > different colors, but that's insane ;) > > The rendering bug that bothers me, however, is the misalignment of the ticks > to the colors in the color bar. I'm sure it's somehow related to the > pixel-rounding in the Agg backend. I'll see if I can find an obvious fix > for this. If it looks questionable, I'll wait until after the release. Since this would be a bug-fix, I prefer to get it in before the release, if possible:-) So if you have time to look at it, that would be great. Charlie doesn't usually have time during the day to do the builds, so it would be tonight at the earliest, which should give us a little time to test any changes. Thanks, JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New legend borders -- fuzzy???
On Mon, Dec 8, 2008 at 9:13 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > I think Jae-Joon's new figure refactoring is really great, and is a huge > improvement over the old code. > > I do, however, have one concern. Since the legend border is no longer a > simple rectangle, the Agg backend's auto-pixel-alignment routine is no > longer kicking in, and the border ends up looking fairly fuzzy. It's > particularly striking when the axes rectangle is always so clean and > sharp now. As nice as the rounded edges are, the fuzziness makes it > feel like a bit of a regression to me. Aesthetically, I also feel it's > a bit out of place to use rounded corners in one case but not elsewhere > in a document (typical LaTeX templates, for instance, don't use rounded > corners.) > > Should it perhaps be a regular rectangle by default, with rounded > corners as an option? I'm inclined to agree with you -- this could also be an rc option, so those who like the rounding can get them by default. I would be happy to have rectangle by default, with liberal use of rounding in the gallery example code so people can easily find how to turn them on. A legend section for the docs is still on my list of things to do. I'll implement the rc param "legend.fancybox" and make False (rectangle) the default, and we can always change the after default if JJ weighs in. > This may also be an argument for finally making the auto-pixel-alignment > code programmatic, rather than automatic. As it works now, it > automatically pixel-aligns when there are a) no curves and b) only > rectilinear axis-aligned line segments. If the pixel alignment was > instead controlled from Python as a flag, then the legend code could > explicitly say it wants the legend patch to be pixel-aligned, even if it > has rounded corners. But that's perhaps too deep of a change to make > for the impending release and should have to wait for next time. This sounds fairly benign (gc param?) so I could go either way: before or after. JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New legend borders -- fuzzy???
On Mon, Dec 8, 2008 at 9:39 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > The gc param would be the easy part -- I was thinking the difficult would be > going through all the cases and making sure it's doing the right thing, and > making sure axes and ticks etc. still look nice. Though I suppose having > the flag be yes/no/auto (where auto is the current behavior) would be the > easiest route. I wasn't thinking clearly. I was thinking you would be applying the fix only for the legend implementation, but there is no clean way to do this since the backends don't know anything about legends. Yes, doing this for all the artists is definitely too ambitious at this stage of the release. JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New legend borders -- fuzzy???
On Mon, Dec 8, 2008 at 10:49 AM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote: > On the other hand, I think it would also good if we allow a dictionary > for the "fancybox" argument, like "bbox" in text. But maybe not in > this release. I would prefer not to change the meaning of the fancybox once we release it, if we can help it. The best two choices are: * add support now for the dict before the release (handling the rc to accept a dict may require a little extra work) * keeping fancybox as is but adding an optional fancyprops dict later I can go either way, but I am disinclined to intentionally change the semantics of fancybox once we have released it we can help it -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] dashtick.py example broken
On Mon, Dec 8, 2008 at 4:19 PM, Ryan May <[EMAIL PROTECTED]> wrote: > Hi, > > Was just looking through the examples and noticed that > pylab_examples/dashtick.py > does not work here for me on SVN head. > > Traceback (most recent call last): > File "dashtick.py", line 61, in > test_dashticklabel() > File "dashtick.py", line 40, in test_dashticklabel > fontsize=FONTSIZE, > File "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/pyplot.py", > line 162, in setp > ret = _setp(*args, **kwargs) > File "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/artist.py", > line 982, in setp > func = getattr(o,funcName) > AttributeError: 'Text' object has no attribute 'set_dashrotation' > > I'm clueless on this code, so this is just an FYI. TextWithDash is still used on the maintenance branch for tick labels, but no longer on the trunk. I suspect it did not work with the arbitrary projections Michael developed support for and he removed it, but Michael can confirm. The code is poorly maintained, so I am happy to see it no longer in the core tick labeling. I have removed the example from svn. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release? no, this time really I mean it
On Thu, Dec 4, 2008 at 12:38 PM, Charlie Moad <[EMAIL PROTECTED]> wrote: > Works for me. Let's aim for Saturday night so we have Sunday to test > it out. Doable? I've been working on a number of docstring fixes, and several other changes and last-minute bug fixes have been coming in. I think we need to give these a day to settle, so let's hold off until tomorrow before trying to push out the release, so we can do further testing/ Thanks, JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release? no, this time really I mean it
On Mon, Dec 8, 2008 at 5:31 PM, John Hunter <[EMAIL PROTECTED]> wrote: > On Thu, Dec 4, 2008 at 12:38 PM, Charlie Moad <[EMAIL PROTECTED]> wrote: >> Works for me. Let's aim for Saturday night so we have Sunday to test >> it out. Doable? > > I've been working on a number of docstring fixes, and several other > changes and last-minute bug fixes have been coming in. I think we > need to give these a day to settle, so let's hold off until tomorrow > before trying to push out the release, so we can do further testing/ As far as I am concerned, the current head is tested and ready to go. I am at svn r6535 so Charlie, go with that revision number when you do the release, unless you hear otherwise here. If someone has any other fixes that need to go in before he does the release, we will need to do a new round of testing. JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] error in add_subplot
On Wed, Dec 10, 2008 at 12:36 AM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote: > Current SVN (r6540) raise an error for the following code. Arg, bad timing. Charlie released 0.98.4 hours before you found this. Fortunately, the use case, fig = plt.figure() ax = maxes.Subplot(fig, 1, 1, 1) fig.add_subplot(ax) is pretty rare, since most use the fig.add_subplot(111) construction.In fact, we didn't catch this because none of the examples use it in backend_driver. I just added a units/notes_tests.py with this example added to it. Please add other regression tests here as you develop. JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] 98.4 maintenance branch
Since we already have a bug in the 98.4 release, we can anticipate needing to do a bugfix release accumulating all the bugs we fix in the next week (presuming we don't discover any critical bugs which would require us to push out a fix earlier). To make sure we achieve maximal stability, I have created a 98.4 maintenance branch which should only get bugfixes. All other development can proceed apace on the trunk. svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/\ v0_98_4_maint mpl98.4 --username=youruser --password=yourpass Mike, can you advise on the procedure for doing merges from the new branch to the trunk. In particular, what I am confused about is how to inform svn-merge that I want to merge from 98.4 branch and not 91.4 branch. JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] ANN: matplotlib-0.98.4
We have just released a new version of matplotlib, available for download at https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194&release_id=646146 These "what's new" release notes, with graphs and links, are available in html at http://matplotlib.sourceforge.net/users/whats_new.html Thanks to Charlie Moad for testing and preparing the source release, including binaries for OS X and Windows for python 2.4 and 2.5 (2.6 and 3.0 will not be available until numpy is available on those releases). Thanks to the many developers who contributed to this release, with contributions from Jae-Joon Lee, Michael Droettboom, Ryan May, Eric Firing, Manuel Metz, Jouni K. Seppaenen, Jeff Whitaker, Darren Dale, David Kaplan, Michiel de Hoon and many others who submitted patches What new in 0.98.4 == It's been four months since the last matplotlib release, and there are a lot of new features and bug-fixes Legend enhancements Jae-Joon has rewritten the legend class, and added support for multiple columns and rows, as well as fancy box drawing. See http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.legend http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.legend.Legend http://matplotlib.sourceforge.net/examples/pylab_examples/legend_demo3.html Fancy annotations and arrows - Jae-Joon has added lot's of support to annotations for drawing fancy boxes and connectors in annotations. See http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.annotate http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.patches.BoxStyle http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.patches.ArrowStyle http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.patches.ConnectionStyle http://matplotlib.sourceforge.net/examples/pylab_examples/annotation_demo2.html Native OS X backend Michiel de Hoon has provided a native Mac OSX backend that is almost completely implemented in C. The backend can therefore use Quartz directly and, depending on the application, can be orders of magnitude faster than the existing backends. In addition, no third-party libraries are needed other than Python and NumPy. The backend is interactive from the usual terminal application on Mac using regular Python. It hasn't been tested with ipython yet, but in principle it should to work there as well. Set 'backend : macosx' in your matplotlibrc file, or run your script with:: > python myfile.py -dmacosx psd amplitude scaling - Ryan May did a lot of work to rationalize the amplitude scaling of :func:`~matplotlib.pyplot.psd` and friends. The changes should increase MATLAB (TM) compatabililty and increase scaling options. http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.psd http://matplotlib.sourceforge.net/examples/pylab_examples/psd_demo2.html#pylab-examples-psd-demo2 http://matplotlib.sourceforge.net/examples/pylab_examples/psd_demo3.html#pylab-examples-psd-demo3 Fill between -- Added a fill_between function to make it easier to do shaded region plots in the presence of masked data. You can pass an *x* array and a *ylower* and *yupper* array to fill betweem, and an optional *where* argument which is a logical mask where you want to do the filling. See http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.fill_between http://matplotlib.sourceforge.net/examples/pylab_examples/fill_between.html Lots more --- Here are the 0.98.4 notes from the CHANGELOG:: Added mdehoon's native macosx backend from sf patch 2179017 - JDH Removed the prints in the set_*style commands. Return the list of pprinted strings instead - JDH Some of the changes Michael made to improve the output of the property tables in the rest docs broke of made difficult to use some of the interactive doc helpers, eg setp and getp. Having all the rest markup in the ipython shell also confused the docstrings. I added a new rc param docstring.harcopy, to format the docstrings differently for hardcopy and other use. Ther ArtistInspector could use a little refactoring now since there is duplication of effort between the rest out put and the non-rest output - JDH Updated spectral methods (psd, csd, etc.) to scale one-sided densities by a factor of 2 and, optionally, scale all densities by the sampling frequency. This gives better MatLab compatibility. -RM Fixed alignment of ticks in colorbars. -MGD drop the deprecated "new" keyword of np.histogram() for numpy 1.2 or later. -JJL Fixed a bug in svg backend that new_figure_manager() ignores keywords arguments such as figsize, etc. -JJL Fixed a bug that the handlelength of the new legend class set too short when numpoints=1 -JJL A
Re: [matplotlib-devel] 98.4 maintenance branch
On Wed, Dec 10, 2008 at 11:30 AM, Michael Droettboom <[EMAIL PROTECTED]>wrote: > > This will make merging slightly easier, (since the -S parameter is not > required), and it is generally good practice in the long run to not keep > extra branches lying around. I'm happy to make this change, but thought I'd > run it by you first -- it means we're effectively abandoning the 0.91.x > series, or at least saying any bugfixes to it will have to be manually > brought over to 0.98.x. > > Thanks for the notes -- I'l incorporate them into the dev guide. I definitely do not want to abandon the 91 branch. I expect this branch to last a while, perhaps a year. the 98.4 branch is intended to be short lived, order of a week or two, just to fix critical bugs for this release. Or better yet, we keep it alive until the next point release, then kill it and make a new release branch. That way if we ever need to fix a critical bug in the latest release, we can go to the branch w/o having all the testing required on the head. Since the major incompatibility was between 91 and 98, I anticipate that there are some users with a lot of code (eg an axes3d dependency) where moving may never be feasible. JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Status of pylab example loadrec.py
On Wed, Dec 10, 2008 at 3:28 PM, Nils Wagner <[EMAIL PROTECTED]>wrote: > Hi all, > > The example loadrec.py illustrates the usage of > PyExcelerator. > > However it seems PyExcelerator is no longer maintained > > Is it planned to adapt the example wrt xlwt ? > > http://pypi.python.org/pypi/xlwt > True it is no longer maintained, but it does work. We are looking into xlwt (I wasn't aware of it until today when you forwarded the message) JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 98.4 maintenance branch
On Wed, Dec 10, 2008 at 5:43 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > Hmm... Seems Thunderbird butchered my long URLs. > > Anyway, the problem is worse than I thought. Since the branch was created > from trunk/ to branches/v0_98_4_maint/, svnmerge.py will only merge from one > of those to the other. What we really want to be able to do is merge from > branches/v0_98_4_maint/matplotlib to trunk/matplotlib (i.e. source tree to > source tree, not from the whole matplotlib universe to another), so the > branch must be created in the same way. svnmerge does its magic by going > back to find how the branch was created, and if the merging doesn't match > the branch operation, it basically can't do anything. Hope that description > makes sense. > > This means, presently, in order to do a merge, one has to check out the > whole kit-and-caboodle with htdocs, py4science etc., and not just the > matplotlib source tree. > > I would suggest fixing this creating a new branch just from the source > tree, and setting up merging from that to the trunk source tree, and then > retiring or deleting the current v0_98_4_maint branch (if that's possible). Yes, this was just a screwup on my part when I made the branch; be gentle, it was my first time. I agree with your suggestion of just deleting the branch and starting over. Unfortunately, there is a critical bug reported on the users list where is GTKAgg is installed as the default backend on the windows installer (I confirmed this for the win 2.5 win32 egg and assume the problem is in the other win binaries too). Charlie, did you perhaps forget to set the tkagg backend in the setup.cfg config for the windows installer (and make sure the configobj and traits are turned off as Darren mentioned in another thread)? I have deleted the win32 files from the sf release page. Given that the win32 binaries have to be fixed ASAP and that the branch is fubar, it may be in everyone's best interest to simply start over. I've added Michael's font_manager and Jae-Joon's figure/subplot fixes to the trunk at r6559 and bumped the version number to 0.98.5rc. I did another round of testing with these changes (including a nose test for Jae-Joon's problem!) so Charlie if you have time to do another set of binaries we can kill all these birds with one stone an just release 0.98.5 (if you go this route, just remove the rc from the version num and bump to 0.98.5) Or Charlie, if you do not have time for this in the next 24 hours, but do have time to upload new win32 binaries from your existing build dirs with the backend fixed, that is fine too and we can push out a bug fix release with these other non-critical changes next week. If you decide to go this route, you should know that I may have accidentally deleted the python 2.4 os x egg when deleting the win32 binaries, because if there was one there isn't one there now :-( And if your new baby is requiring some attention and you don't have time for either of these, let me know and I will simply hide the 98.4 release until we sort this out. And I'll try and get the maintenance branch right next time :-) -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] rest table in matplotlib.lines.Line2D.set_marker
In response to a question on matplotlib-users, I added some additional documentation for the linestyles and markers in the matplotlib.lines API docs. Specifically, I added a rest table mapping the linestyle/marker to the meaning of the marker. Strangely, the set_linestyle table renders fine http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.lines.Line2D.set_linestyle but the table in set_marker is absent http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.lines.Line2D.set_marker I've tried cleanly building and installing mpl in my src tree, running svn-clean to make sure no cruft is impacting me, but I have not succeeeded in getting the marker table to render. Perhaps a fresh set of eyeballs can spot the problem. I'm pasting the docstrings below:: def set_linestyle(self, linestyle): """ Set the linestyle of the line (also accepts drawstyles) = linestyle description = '-' solid '--' dashed '-.' dash_dot ':' dotted 'None' draw nothing ' ' draw nothing '' draw nothing = .. seealso:: :meth:`set_drawstyle` ACCEPTS: [ '-' | '--' | '-.' | ':' | 'None' | ' ' | '' ] and any drawstyle in combination with a linestyle, e.g. 'steps--'. """ And here is set_marker docstring:: def set_marker(self, marker): """ Set the line marker = == marker description = == '.'point ','pixel 'o'circle 'v'triangle_down '^'triangle_up '<'triangle_left '>'triangle_right '1'tri_down '2'tri_up '3'tri_left '4'tri_right 's'square 'p'pentagon '*'star 'h'hexagon1 'H'hexagon2 '+'plus 'x'x 'D'diamond 'd'thin_diamond '|'vline '_'hline TICKLEFT tickleft TICKRIGHT tickright TICKUP tickup TICKDOWN tickdown CARETLEFT caretleft CARETRIGHT caretright CARETUPcaretup CARETDOWN caretdown 'None' nothing ' 'nothing '' nothing = == ACCEPTS: [ '+' | '*' | ',' | '.' | '1' | '2' | '3' | '4' | '<' | '>' | 'D' | 'H' | '^' | '_' | 'd' | 'h' | 'o' | 'p' | 's' | 'v' | 'x' | '|' | TICKUP | TICKDOWN | TICKLEFT | TICKRIGHT | 'None' | ' ' | '' ] """ -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Status of pylab example loadrec.py
On Wed, Dec 10, 2008 at 4:26 PM, John Hunter <[EMAIL PROTECTED]> wrote: > >> Is it planned to adapt the example wrt xlwt ? >> >> http://pypi.python.org/pypi/xlwt >> > > > True it is no longer maintained, but it does work. We are looking into > xlwt (I wasn't aware of it until today when you forwarded the message) > I've added support for xlwt in svn r6560 -- give it a whirl JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] requesting permission to remove traits and configobj
On Wed, Dec 10, 2008 at 9:20 PM, Darren Dale <[EMAIL PROTECTED]> wrote: > There has been a report at the bugtracker complaining that matplotlib is > overwriting an existing installation of configobj. I had a look at the code > and thought the bug report must be a mistake or windows specific, but I just > saw similar behavior on my linux system. Ignoring for a minute the question of whether we can/should flush configobj/traits, it sounds like the real problem is that setup.cfg is not working like we expect it to. And that is something that should be fixed if is broken. If mpl is installing configobj or traits even if we are telling it not to via setup.cfg, then we have a problem. This is worth knowing, since the last mpl release was broken vis-a-vis the default backend on win32, which *could* be explained by a broken setup.cfg. I would like to simply remove configobj and traits from our repository. They > are only used by the long-neglected experimental traited config package, > which is only of interest to developers who can easily install them as > external dependencies. Is it ok to remove them? If so, should it be done on > all the branches? > > How long are we going to continue to maintain the different branches? It > was so much easier back when we only had to worry about the trunk... > You can remove them from the trunk. They should remain on the 0.91 branch as is (with any known bugs fixed and merged) since that is the point of the branch (stability for those who cannot upgrade -- in principle someone might be depending on the traited config, in practice unlikely). As for the 0.98 branch, it is slated for destruction so no worries. I share your visceral reaction against branches, but my head is starting to override this bodily reaction, as I see the need for them in practice. If we carefully document the best practices and motivations in the developerr's guide, we can use them advantageously. We have a lot of people contributing to mpl, and approaching or just after release time we need some mechanism for stabilizing the tested feature set of the release candidate while allowing other development to proceed, and branches are the natural mechanism for that. That we are starting to use them is a reflection of the fact that we have many more active developers than we ever had before (12 developers contributed between 98.3 and 98.4, it used to be just 3 or 4 at a time). I wouldn't be advocating branches otherwise, because I am an advocate of doing things as simply as possible: "Make everything as simple as possible, but not simpler.". In general, I am in favor of the wildest, wooliest, development process we can afford. I would like to have everyone on the trunk, making releases as often as possible (nightly if we can), with an attitude of "if you break it, just fix it an rerelease it". This model worked fine for us for years, and I think it would continue to work if we have a hyper-active developer or an automated build bot. In the old days, I would release any time I added a new feaure, and if I broke something I would have a new release out in hours. I no longer have the time for that, and we are lucky to have Charlie buildng OS X and win32 binaties and eggs for multiple python versions. When we release broken code, Charlie has to go through the entire test/upload/release cycle again, building for multiple OSs and python versions while taking care of his wife and two babies, so we want to minimize that. At the same time, we have lots of developers pushing code into the mainline. We need some mechanism of balancing the desire of developers to get new code in and the need for the packagers and release manangers to get stable code out. I think the right balance for mpl before a release is to test the HEAD, sign off on it, branch it, let development proceed on the HEAD, and put any release critical bugs and fixes into the branch. When the next release comes up, delete the old branch, and wash-rinse-repeat. We will have in perpetuity one active release branch at a time, which gets important bug fixes and nothing else, and in addition (for a while) a legacy branch (0.91) which is updated once a month or so. I am happy to get input on this. JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 98.4 maintenance branch
On Thu, Dec 11, 2008 at 8:25 AM, Michael Droettboom wrote: >> And I'll try and get the maintenance branch right next time :-) > > All of the above sounds good to me. I will be traveling to my conference starting at noon, so will be in sporadic, light email contact for the next few days. Charlie will look at fixing the builds tonight -- everyone else, please do what you can if something comes up because I would love to have a good set of binaries on line by the time my talk starts at noon tomorrow: http://mloss.org/workshop/nips08/ JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 98.4 maintenance branch
Michael, Will you create the branch and set up the svn merge properties? Thanks Charlie, JDH Sent from my iPhone On Dec 11, 2008, at 7:35 PM, "Charlie Moad" wrote: > 0.98.5 source and bins are posted. Please try them out. John can > announce at his convenience. > > - Charlie > > On Thu, Dec 11, 2008 at 12:15 PM, John Hunter > wrote: >> On Thu, Dec 11, 2008 at 8:25 AM, Michael Droettboom >> wrote: >> >>>> And I'll try and get the maintenance branch right next time :-) >>> >>> All of the above sounds good to me. >> >> I will be traveling to my conference starting at noon, so will be in >> sporadic, light email contact for the next few days. Charlie will >> look at fixing the builds tonight -- everyone else, please do what >> you >> can if something comes up because I would love to have a good set of >> binaries on line by the time my talk starts at noon tomorrow: >> >> http://mloss.org/workshop/nips08/ >> >> JDH >> -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Different behaviour of mathtext and LaTeX rendering
On Fri, Dec 12, 2008 at 2:41 PM, Darren Dale wrote: > What I would prefer is to raise a deprecation warning when an odd number of > dollar signs are encountered, giving people time to learn to escape their $ > and modify their code. I wonder how disruptive this would be to people using > mpl for finance? Well, we used to need lots of dollar signs, but with the market crash and credit crunch, we will probably get by with fewer going forward This is fine with me -- I suspect it is a very rare corner case. JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
