Re: [matplotlib-devel] patch for adding manual label location selection to clabel
Hi, I have finally committed a changeset for moving the "event loop" stuff into the backends. I have hopefully found a compromise that will please most. Since this is close to release date, I suggest that everyone who can give it a look (r5831) and if there is any problem, just role the changes back and release with the old code. My compromise was the following: 1) In FigureCanvasBase, create start/stop_event_loop that raise errors. I kept these names instead of wait_start wait_stop because I think things like start_event_loop is used in other programming contexts to denote the same things. In the documentation string, I tried to make it clear that this is not the overall GUI event loop. If people aren't happy, changing is a fairly simple find and replace. 2) In FigureCanvasBase, I also created start/stop_event_loop_default. These do the standard time.sleep thing. start_event_loop_default throws a deprecated warning saying it should be replaced by a gui specific version. Once we have the gui specific versions, I still think we should keep this function around as this code is very simple and straightforward and is likely to work on almost anything. For example, if we ever had a problem with a backend, we could always use this till a fix was found. 3) In cocoagg, fltkagg, gtk, qt, qt4, and tkagg, I implemented fall-through functions for start/stop_event_loop that simply call the default versions. 4) In WX, I used the code submitted by Paul, but was unable to check it because when I tried to use the WX backend, I got an error about no GraphicsContext (below). This looks bad. I am using wxPython: 2.6.3.2. Again, any problem with this, just role the changes back until after the release. Cheers, David Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 1035, in _onPaint self.draw(repaint=False) File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 903, in draw self.figure.draw(self.renderer) File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 724, in draw if self.frameon: self.patch.draw(renderer) File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line 257, in draw gc = renderer.new_gc() File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 360, in new_gc self.gc = GraphicsContextWx(self.bitmap, self) File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 457, in __init__ gfx_ctx = wx.GraphicsContext.Create(dc) : 'module' object has no attribute 'GraphicsContext' -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - 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] clabel improvements
Hi, I committed the changes to clabel (r5830). For the attribute renaming, I think we can safely rename most of them. In my opinion, the only ones that users might use are .cl, .cl_xy and .cl_cvalues. The clabel function creates these just before finishing from their more appropriately named versions. This should provide enough backward compatibility for a release or two. And yes, isvector is different from iterable. For example: In [81]: cbook.isvector( array([3,4,5,6]).reshape(1,1,1,4) ) Out[81]: True In [82]: cbook.isvector( array([3,4,5,6]).reshape(1,1,2,2) ) Out[82]: False This function is probably more useful in matlab since it has no shape way to distinguish vectors from 2D matrices, but still it doesn't hurt to have it around. Cheers, David On Wed, 2008-07-23 at 08:08 -1000, Eric Firing wrote: > John Hunter wrote: > > On Wed, Jul 23, 2008 at 6:21 AM, David Kaplan <[EMAIL PROTECTED]> wrote: > >> Hi, > >> > >> Well, I now know more than I ever wanted to about clabel. I decided to > >> improve a bit on the inlining and ended up rewriting it. For automatic > >> label placement, I basically use the existing algorithm for determining > >> label location, but have replaced existing code for determining the > >> angle of rotation and the amount of the contour to take off for inlining > >> with new code. This new code is based on using pixel-space distances > >> along the contour. This allows one to (1) get nice balanced inlining > >> with the same amount of space on either side of the label, and (2) to > >> vary the amount of space you want around the label. It also should deal > >> better with labels located near contour edges and labels covering the > >> entire contour. > > It all sounds like much-needed improvement. > > >> > >> Along the way, I renamed all ContourLabeler specific attributes to > >> something like .labelAttribute. This makes the namespace cleaner in my > >> mind, but might break existing user code that does things directly with > >> ContourLabeler attributes. > > > > Eric, do you have any sense of whether people would use this directly? > > I think the probability that anyone is doing this is low, but it would > be nice to ask on the users mailing list. > > > Since this is a point release, I want to minimize API breakage, so at > > least keep the old attrs around for this cycle. Eg, in Axes I > > recently renamed axesPatch to simply patch as follows: > > > > # the patch draws the background of the axes. we want this to > > # be below the other artists; the axesPatch name is deprecated > > self.patch = self.axesPatch = self._gen_axes_patch() > > > > we don't have an easy way to catch deprecated usage w/o some property > > or getattr magic. If you want to add getter properties for the > > deprecated attrs which warn and point to the new, that would be ideal. > > In general, yes, but in this case I think it would be better to go with > your simpler method above, of making duplicate names. It reduces the > code clutter and the chance of introducing last-minute errors. The > mailing list and API_CHANGES can be used to notify users of the upcoming > deprecation. If there is an outcry, indicating wide use of the > attributes, then properties can be introduced later to smooth the > deprecation process. But I predict there will be hardly a peep. > > > > > > >> I also added a few new functions to cbook. One does simple linear > >> interpolation (in addition to an existing cbook function that is similar > >> but a bit different). Others do things with vector lengths. I also > Maybe explain in the docstring or a comment why this version is needed? > >> added a function called isvector that is identical to a Matlab function > Maybe use try/except to return False if the test fails? If the input is > a string, or None, for example? Whether to do this depends on what the > use case is. > >> of the same name. If desired, I can move this to mlab.py, but for the > >> moment it is in cbook.py because most of the is? functions are there. > > > > That's fine. Is this different from "iterable" > > > >> On an aside, I noted that mlab.norm uses cut-and-paste documentation > >> from Matlab. Is this wise? > > > > No, please rewrite the docstring. Some of mlab was borrowed form > > other people's codes, and I was unaware of this. > > norm is one of the things we should not have at all; ours should be > deprecated in favor of numpy.linalg.norm. It would be good to have a > linear algebra guru look at this to see whether a straight substitution > with deprecation warning would work, or whether there are significant > differences. If something close to a substitution will work, then the > docstring in mlab can be replaced with a reference to the numpy > function. And then in some future release, it will all be deleted. > > > > >> I have tested all the changes against the existing pylab_examples and > >> things work fine. Nonet
Re: [matplotlib-devel] clabel improvements
On Thu, Jul 24, 2008 at 7:31 AM, David Kaplan <[EMAIL PROTECTED]> wrote: > I committed the changes to clabel (r5830). Hey David -- thanks for these fixes. I noticed a couple of things I want to comment on * avoid the ternary operator, as in # Figure out label rotation. rotation,nlc = cs.calc_label_rot_and_inline( slc, imin, lw, lc if self.inline else [], self.inline_spacing ) since this requires python2.5. I replaced this, and a similar construct in contour.py, so please make sure I did the right thing * avoid needless *args, **kwargs usage. We do this all the time in pylab and to a lesser extent in axes.py because we are passing the function call on to another layer. In that case, at least document the proper signature as the first line in the docstring. But unless we need it, avoid it, eg in def start_event_loop(self,*args,**kwargs): """ Start an event loop. This is used to start a blocking event loop so that interactive f If you want to give the user who is using a known UI that supports extra args, do it like def func(self, timeout, **kwargs): and pass the kwargs through, but at lease require the known args and kwargs in the main signature. * Using an empty list in a python kwarg as the default is a gotcha, as in def calc_label_rot_and_inline( self, slc, ind, lw, lc=[], spacing=5 ): The reason is that if the function mutates the list, this often leads to unintended consequences as the list is module level and thus shared between instances and method calls. The standard idiom for mutable (lists and dicts) keyword args s def func(x=None): if x is None: x = [] I have fixed this in contour.py 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] clabel improvements
Hi, I made the suggested fixes. Comments below: On Thu, 2008-07-24 at 08:38 -0500, John Hunter wrote: > On Thu, Jul 24, 2008 at 7:31 AM, David Kaplan <[EMAIL PROTECTED]> wrote: > > > I committed the changes to clabel (r5830). > > Hey David -- thanks for these fixes. I noticed a couple of things I > want to comment on > > * avoid the ternary operator, as in > > # Figure out label rotation. > rotation,nlc = cs.calc_label_rot_and_inline( > slc, imin, lw, lc if self.inline else [], > self.inline_spacing ) > > since this requires python2.5. I replaced this, and a similar > construct in contour.py, so please make sure I did the right thing > The reason I used this was that I saw the following line in contour.py (line 325): lc = [tuple(l) for l in linecontour] Doesn't this also require 2.5 or is the if different than the for? Should this also be changed? > * avoid needless *args, **kwargs usage. We do this all the time in > pylab and to a lesser extent in axes.py because we are passing the > function call on to another layer. In that case, at least document > the proper signature as the first line in the docstring. But unless > we need it, avoid it, eg in I removed all this arbitrary argument stuff. I was thinking that if we ever invented a better mouse trap, this would let us automatically pass that on to GUI's we haven't written specific functions for yet. But we are unlikely to invent a better mouse trap. > > * Using an empty list in a python kwarg as the default is a gotcha, as in > > def calc_label_rot_and_inline( self, slc, ind, lw, lc=[], spacing=5 ): > > The reason is that if the function mutates the list, this often leads > to unintended consequences as the list is module level and thus shared > between instances and method calls. The standard idiom for mutable > (lists and dicts) keyword args s > > def func(x=None): > if x is None: x = [] > > I have fixed this in contour.py > I don't really understand how this can be a problem, but it probably isn't that important unless you feel like enlightening me. Cheers, David > JDH -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - 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 adding manual label location selection to clabel
On Thu, Jul 24, 2008 at 12:12:21PM +0200, David Kaplan wrote: > 4) In WX, I used the code submitted by Paul, but was unable to check it > because when I tried to use the WX backend, I got an error about no > GraphicsContext (below). This looks bad. I am using wxPython: 2.6.3.2. Does wx work for you without the change? I suspect not... I posted a fix to make the wx backend work for me with examples/pylab_examples/ginput_demo.py and wx 2.8.3. One issue I didn't address properly is what happens when the user exits by closing the window. Currently it raises an error when ginput requests draw. - Paul - 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] Wind Barbs Full Patch
On Wed, Jul 23, 2008 at 10:05 PM, Ryan May <[EMAIL PROTECTED]> wrote: > Ok, it fixes the problem if I pass dpi=72 to savefig(). Curiously, > passing dpi=72 to Figure() does not have the same effect. So now how do I That is because "savefig" has its own dpi, which overrides the figure dpi. Tee ideas is that you typically want a different dpi for the UI window and for the harcopy > fix it? I'm really not sure what's going wrong here. If I had to guess, > it's a problem between figure size being in inches while I'm drawing in > pixels (still don't know how that works, because there's no way those barbs > are 9 pixels long). I'm not familiar enough with the windbarb code to know where the "9 pixel" thing that is bothering you is creeping in, I'm just saying that using an identity transform means you are drawing in canvas (pixel) space and not accounting for dpi. The Figure instance has a "dpi_scale_transform" that is designed to handle dpi scaling, and updates itself when the figure dpi is changed so you don't have to handle the callbacks. Take a look at this and see if you can incorporate it. If you have troubles, Michael or I can advise further. If you clarify the "9 pixel" problem that is bothering you, I may be able to help more sooner... 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] patch for adding manual label location selection to clabel
Hi, No, it doesn't appear to work with or without my changes. Also, it looks to me like the following code is now misplaced in backend_wx.py: # Event binding code changed after version 2.5 if wx.VERSION_STRING >= '2.5': def bind(actor,event,action,**kw): actor.Bind(event,action,**kw) else: def bind(actor,event,action,id=None): if id is not None: event(actor, id, action) else: event(actor,action) It now appears after some functions not in the class. Is this OK? Also, I noticed that this defines bind, while elsewhere in the class self.Bind is used. Is this correct? If so, should these other references perhaps take advantage of your abstraction? Cheers, David On Thu, 2008-07-24 at 11:02 -0400, Paul Kienzle wrote: > On Thu, Jul 24, 2008 at 12:12:21PM +0200, David Kaplan wrote: > > 4) In WX, I used the code submitted by Paul, but was unable to check it > > because when I tried to use the WX backend, I got an error about no > > GraphicsContext (below). This looks bad. I am using wxPython: 2.6.3.2. > > Does wx work for you without the change? I suspect not... > > I posted a fix to make the wx backend work for me with > examples/pylab_examples/ginput_demo.py and wx 2.8.3. > > One issue I didn't address properly is what happens when the user > exits by closing the window. Currently it raises an error when > ginput requests draw. > > - Paul -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - 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] clabel improvements
On Thu, Jul 24, 2008 at 9:32 AM, David Kaplan <[EMAIL PROTECTED]> wrote: >> * avoid the ternary operator, as in >> >> # Figure out label rotation. >> rotation,nlc = cs.calc_label_rot_and_inline( >> slc, imin, lw, lc if self.inline else [], >> self.inline_spacing ) >> >> since this requires python2.5. I replaced this, and a similar >> construct in contour.py, so please make sure I did the right thing >> > > The reason I used this was that I saw the following line in contour.py > (line 325): > > lc = [tuple(l) for l in linecontour] > > Doesn't this also require 2.5 or is the if different than the for? > Should this also be changed? No, this (a list comprehension) is fine. The problem is the ternary operator " lc if self.inline else []" which is not supported in python 2.4. I believe all the python 2.5isms have been removed. >> def func(x=None): >> if x is None: x = [] >> >> I have fixed this in contour.py >> > > I don't really understand how this can be a problem, but it probably > isn't that important unless you feel like enlightening me. See for example http://www.velocityreviews.com/forums/t350126-default-argument-to-init.html - 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 adding manual label location selection to clabel
On Thu, Jul 24, 2008 at 05:14:42PM +0200, David Kaplan wrote: > Hi, > > No, it doesn't appear to work with or without my changes. Also, it > looks to me like the following code is now misplaced in backend_wx.py: > > # Event binding code changed after version 2.5 > if wx.VERSION_STRING >= '2.5': > def bind(actor,event,action,**kw): > actor.Bind(event,action,**kw) > else: > def bind(actor,event,action,id=None): > if id is not None: > event(actor, id, action) > else: > event(actor,action) > > It now appears after some functions not in the class. Is this OK? This code is not part of any class. Anyway, I moved it to the top of the file. > Also, I noticed that this defines bind, while elsewhere in the class > self.Bind is used. Is this correct? If so, should these other > references perhaps take advantage of your abstraction? I've committed a change so that all functions now use bind(self, wx.EVT, callback, id=id) rather than if wx.VERSION_STRING >= '2.5': self.Bind(wx.EVT,callback,id=id) else: wx.EVT(self, id, callback) I'm not set up to test against wx < 2.5, though given its age and the small user base of matplotlib wx, I'm not sure that it is relevant anymore. - Paul - 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] doc warnings
There are a number of documentation warnings -- at lease some of these are because doc strings in the api docs are non-compliant. If you've been working on any of these functions, please take a moment to try and bring them up to snuff (I suspect one or more of these is mine, but I'm pasting them all here). WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/axes.py:docstring of matplotlib.axes.Axes.acorr:36: (ERROR/3) Unexpected indentation. WARNING: :0: (ERROR/3) Unexpected indentation. WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backend_bases.py:docstring of matplotlib.backend_bases.FigureCanvasBase.start_event_loop_default:15: (WARNING/2) Literal block expected; none found. WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backend_bases.py:docstring of matplotlib.backend_bases.FigureCanvasBase.stop_event_loop_default:8: (WARNING/2) Literal block expected; none found. WARNING: /home/jdhunter/mpl/doc/api/cbook_api.rst:9: (WARNING/2) error while formatting signature for matplotlib.cbook.Xlator: arg is not a Python function WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/cbook.py:docstring of matplotlib.cbook.distances_along_curve:6: (WARNING/2) Literal block expected; none found. WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/cbook.py:docstring of matplotlib.cbook.is_closed_polygon:8: (WARNING/2) Literal block expected; none found. WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/cbook.py:docstring of matplotlib.cbook.less_simple_linear_interpolation:14: (WARNING/2) Literal block expected; none found. WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/cbook.py:docstring of matplotlib.cbook.path_length:6: (WARNING/2) Literal block expected; none found. WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/cbook.py:docstring of matplotlib.cbook.vector_lengths:8: (WARNING/2) Literal block expected; none found. WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/figure.py:docstring of matplotlib.figure.Figure.text:37: (WARNING/2) Inline strong start-string without end-string. WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/pyplot.py:docstring of matplotlib.pyplot.acorr:55: (ERROR/3) Unexpected indentation. WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/pyplot.py:docstring of matplotlib.pyplot.annotate:15: (ERROR/3) Unexpected indentation. WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/pyplot.py:docstring of matplotlib.pyplot.gca:2: (WARNING/2) Inline strong start-string without end-string. - 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] preparing for 0.98.3 and 0.91.5
I'd like to try and get 98.3 and 91.5 out tomorrow or Saturday -- if the weekday doesn't work for you Charlie we might do a source release on Friday or Saturday (for Sandro/debian) and you can get the build out over the weekend (if you have time). Obviously a lot of work has gone into these releases, and a lot recently, so it is important to test on what platforms you can. Currently backend driver and memleak hawaii are passing on my platform, and I have managed to at least lightly test most of the critical GUI backends (Tk, WX, GTK, Qt and QT4) on at least one platform and for some backends a couple. The contouring code has had the most recent significant changes, so if you have limited time hit that the hardest. Charlie, let me know what your time frame is Sandro, here is a release candidate tarball for you to test with: http://matplotlib.sourceforge.net/tmp/matplotlib-0.98.3rc1.tar.gz 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
[matplotlib-devel] scipy 2008 sprints
Hello, Anyone planning to attend post-SciPy2008 code sprints? Some projects I'm interested in: support for units (px, pt/in/cm/mm, em/ex/, %axis/%figure) style sheet editor (needs backend support for forms and menus) canvas interface for interactive plotting applications - Paul - 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] Wind Barbs Full Patch
John Hunter wrote: > On Wed, Jul 23, 2008 at 10:05 PM, Ryan May <[EMAIL PROTECTED]> wrote: > >> Ok, it fixes the problem if I pass dpi=72 to savefig(). Curiously, >> passing dpi=72 to Figure() does not have the same effect. So now how do I > > That is because "savefig" has its own dpi, which overrides the figure > dpi. Tee ideas is that you typically want a different dpi for the UI > window and for the harcopy > >> fix it? I'm really not sure what's going wrong here. If I had to guess, >> it's a problem between figure size being in inches while I'm drawing in >> pixels (still don't know how that works, because there's no way those barbs >> are 9 pixels long). > > I'm not familiar enough with the windbarb code to know where the "9 > pixel" thing that is bothering you is creeping in, I'm just saying > that using an identity transform means you are drawing in canvas > (pixel) space and not accounting for dpi. The Figure instance has a > "dpi_scale_transform" that is designed to handle dpi scaling, and > updates itself when the figure dpi is changed so you don't have to > handle the callbacks. Take a look at this and see if you can > incorporate it. If you have troubles, Michael or I can advise > further. > > If you clarify the "9 pixel" problem that is bothering you, I may be > able to help more sooner... Part of the problem is the horrible and misleading sizes arg in PolyCollections, probably a hangover (yes, a headache) from supporting a Matlab-compatible argument in scatter. I can try to straighten this out and clarify the situation after the release, not before. I will add an alternative kwarg to scatter at the same time, and hope the old usage gradually dies out. Eric > > 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 - 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] preparing for 0.98.3 and 0.91.5
I am out on town for a meeting until Sunday evening. I unfortunately won't be able to act until Monday at the earliest. Cutting the source release sounds like a good plan. - Charlie On Thu, Jul 24, 2008 at 3:17 PM, John Hunter <[EMAIL PROTECTED]> wrote: > I'd like to try and get 98.3 and 91.5 out tomorrow or Saturday -- if > the weekday doesn't work for you Charlie we might do a source release > on Friday or Saturday (for Sandro/debian) and you can get the build > out over the weekend (if you have time). Obviously a lot of work has > gone into these releases, and a lot recently, so it is important to > test on what platforms you can. Currently backend driver and memleak > hawaii are passing on my platform, and I have managed to at least > lightly test most of the critical GUI backends (Tk, WX, GTK, Qt and > QT4) on at least one platform and for some backends a couple. > > The contouring code has had the most recent significant changes, so if > you have limited time hit that the hardest. > > Charlie, let me know what your time frame is > > Sandro, here is a release candidate tarball for you to test with: > http://matplotlib.sourceforge.net/tmp/matplotlib-0.98.3rc1.tar.gz > > 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] preparing for 0.98.3 and 0.91.5
On Thu, Jul 24, 2008 at 02:17:19PM -0500, John Hunter wrote: > I'd like to try and get 98.3 and 91.5 out tomorrow or Saturday -- if > the weekday doesn't work for you Charlie we might do a source release > on Friday or Saturday (for Sandro/debian) and you can get the build > out over the weekend (if you have time). Obviously a lot of work has > gone into these releases, and a lot recently, so it is important to > test on what platforms you can. Currently backend driver and memleak > hawaii are passing on my platform, and I have managed to at least > lightly test most of the critical GUI backends (Tk, WX, GTK, Qt and > QT4) on at least one platform and for some backends a couple. Testing hawaii on my machine, I saw the following error: Traceback (most recent call last): File "memleak_hawaii3.py", line 13, in rand = np.mlab.rand AttributeError: 'module' object has no attribute 'mlab' I replaced mlab with random and it now works. Running, I get a leak of about 5.6 KiB per loop. I'm using matplotlib svn, macos 10.4, numpy 1.1.0 I also fixed some of the lesser used examples. I'm not going to try to fix examples/units. examples/animation/anim.py doesn't update on my wxagg backend (wx 2.8.3). - Paul - 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] preparing for 0.98.3 and 0.91.5
On Thu, Jul 24, 2008 at 4:20 PM, Paul Kienzle <[EMAIL PROTECTED]> wrote:
> Testing hawaii on my machine, I saw the following error:
>
> Traceback (most recent call last):
>File "memleak_hawaii3.py", line 13, in
> rand = np.mlab.rand
> AttributeError: 'module' object has no attribute 'mlab'
>
> I replaced mlab with random and it now works.
Sorry, I had fixed that locally and forgotten to commit. Committed now.
> Running, I get a leak of about 5.6 KiB per loop.
> I'm using matplotlib svn, macos 10.4, numpy 1.1.0
I'm not seeing this w/ PDF or Agg in linux... what backend are you
using (the file had set use('PDF') so I assume you are using that.
> I also fixed some of the lesser used examples. I'm not going to try to
> fix examples/units. examples/animation/anim.py doesn't update on my
> wxagg backend (wx 2.8.3).
Thanks for the fixes. This mode of animation works on tk, but not
really for the GUI backends, and is discouraged on the cookbook page.
We probably should update the example to use Tkagg and discourage this
usage on other GUIs.
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] preparing for 0.98.3 and 0.91.5
John Hunter wrote:
> On Thu, Jul 24, 2008 at 4:20 PM, Paul Kienzle <[EMAIL PROTECTED]> wrote:
>
>> Testing hawaii on my machine, I saw the following error:
>>
>> Traceback (most recent call last):
>>File "memleak_hawaii3.py", line 13, in
>> rand = np.mlab.rand
>> AttributeError: 'module' object has no attribute 'mlab'
>>
>> I replaced mlab with random and it now works.
>
> Sorry, I had fixed that locally and forgotten to commit. Committed now.
>
>> Running, I get a leak of about 5.6 KiB per loop.
>> I'm using matplotlib svn, macos 10.4, numpy 1.1.0
>
> I'm not seeing this w/ PDF or Agg in linux... what backend are you
> using (the file had set use('PDF') so I assume you are using that.
Ubuntu hardy, numpy svn, mpl svn, memleak_hawaii3.py with default pdf
output:
399 12710
400 12710
Average memory consumed per loop: 0.8706k bytes
Eric
-
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] preparing for 0.98.3 and 0.91.5
On Thu, Jul 24, 2008 at 4:20 PM, Paul Kienzle <[EMAIL PROTECTED]> wrote: > I also fixed some of the lesser used examples. I'm not going to try to > fix examples/units. examples/animation/anim.py doesn't update on my > wxagg backend (wx 2.8.3). I fixed a few of the units examples that were trivial. The others were already broken on the trunk so it is not a regression, and I will hold off on anything more significant pending the units api/design doc we were discussing earlier. I also added the working examples to the backend_driver so at least we will not regress further in the meantime... 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] preparing for 0.98.3 and 0.91.5
On Thu, Jul 24, 2008 at 04:28:00PM -0500, John Hunter wrote:
> On Thu, Jul 24, 2008 at 4:20 PM, Paul Kienzle <[EMAIL PROTECTED]> wrote:
> > Running, I get a leak of about 5.6 KiB per loop.
> > I'm using matplotlib svn, macos 10.4, numpy 1.1.0
>
> I'm not seeing this w/ PDF or Agg in linux... what backend are you
> using (the file had set use('PDF') so I assume you are using that.
PDF.
> Thanks for the fixes. This mode of animation works on tk, but not
> really for the GUI backends, and is discouraged on the cookbook page.
> We probably should update the example to use Tkagg and discourage this
> usage on other GUIs.
The examples are a great learning resource. They should not
include deprecated patterns. I suggest removing it.
- Paul
-
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] preparing for 0.98.3 and 0.91.5
On Thu, Jul 24, 2008 at 5:16 PM, Paul Kienzle <[EMAIL PROTECTED]> wrote: > PDF. OK, correction, I am seeing this too. I cheated and didn't let the test run to the end. It looked like the memory was flat-lining so I moved on the Agg test (which is not leaking on my completed tests). > The examples are a great learning resource. They should not > include deprecated patterns. I suggest removing it. Will do -- I'll just rewrite it into the suggested pattern and rename it accordingly (eg simple_anim_tk.py, 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] preparing for 0.98.3 and 0.91.5
Eric Firing wrote:
> John Hunter wrote:
>> On Thu, Jul 24, 2008 at 4:20 PM, Paul Kienzle <[EMAIL PROTECTED]> wrote:
>>
>>> Running, I get a leak of about 5.6 KiB per loop.
>>> I'm using matplotlib svn, macos 10.4, numpy 1.1.0
>> I'm not seeing this w/ PDF or Agg in linux... what backend are you
>> using (the file had set use('PDF') so I assume you are using that.
>
> Ubuntu hardy, numpy svn, mpl svn, memleak_hawaii3.py with default pdf
> output:
> 399 12710
> 400 12710
> Average memory consumed per loop: 0.8706k bytes
And with agg backend:
399 12285
400 12285
Average memory consumed per loop: 0.1244k bytes
With ps backend:
399 12206
400 12206
Average memory consumed per loop: 0.1343k bytes
Eric
-
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] wx scroll wheel
Hi, I added support for scroll wheel events in wx. This includes a new attribute event.step since the wx mouse wheel event reports larger steps when scrolling faster. I don't see how to check step in gtk, so I set step to +1 and -1 for up and down. Can someone with gtk please run the following to make sure I didn't break anything: examples/pylab_examples/image_slices_viewer.py Thanks, - Paul - 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 scroll wheel
On Thu, Jul 24, 2008 at 5:45 PM, Paul Kienzle <[EMAIL PROTECTED]> wrote: > Hi, > > I added support for scroll wheel events in wx. This includes > a new attribute event.step since the wx mouse wheel event > reports larger steps when scrolling faster. I don't see > how to check step in gtk, so I set step to +1 and -1 for up > and down. > > Can someone with gtk please run the following to make sure > I didn't break anything: > >examples/pylab_examples/image_slices_viewer.py Works fine for me here... 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] Really minor changes
I noticed a couple of really minor typos as shown below: Index: matplotlib/lib/matplotlib/axis.py === --- matplotlib/lib/matplotlib/axis.py (revision 5860) +++ matplotlib/lib/matplotlib/axis.py (working copy) @@ -147,7 +147,7 @@ """ self._pad = val -def get_pad(self, val): +def get_pad(self): 'Get the value of the tick label pad in points' return self._pad Index: matplotlib/examples/event_handling/lasso_demo.py === --- matplotlib/examples/event_handling/lasso_demo.py(revision 5860) +++ matplotlib/examples/event_handling/lasso_demo.py(working copy) @@ -69,7 +69,7 @@ # acquire a lock on the widget drawing self.canvas.widgetlock(self.lasso) -if 0: +if __name__ == '__main__': data = [Datum(*xy) for xy in rand(100, 2)] - 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] clipping tick lines
Hey, I noticed today, while working on my skewT, that you can't tell the axis objects to clip their ticklines. If you want to set clipping on each individual tickline. I saw that the code is there in the relevant classes, but the lines to set clipping are disabled in set_clip_path() or _set_artist_props(). My SVN foo is failing me right now, so I can't find anything to tell me why these changes were made. Anyone have any ideas? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - 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] clipping tick lines
Ryan May wrote: > Hey, > > I noticed today, while working on my skewT, that you can't tell the axis > objects to clip their ticklines. If you want to set clipping on each > individual tickline. I saw that the code is there in the relevant > classes, but the lines to set clipping are disabled in set_clip_path() > or _set_artist_props(). My SVN foo is failing me right now, so I can't > find anything to tell me why these changes were made. Does this link work for you? (Sometimes sourceforge is painfully slow, sometimes bits of it seem to simply go away.) http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/ I find the browser view quite helpful for finding out which changes were made when, and by whom. To find out why, one must often ask or go to the mailing list archive. > > Anyone have any ideas? I don't, but it appears that the set_clip_path method was introduced in 4817 by Mike D., complete with the commented-out lines. http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/axis.py?annotate=5651 http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/axis.py?view=diff&r1=4816&r2=4817 > > Ryan > - 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] clipping tick lines
Eric Firing wrote: > Ryan May wrote: >> Hey, >> >> I noticed today, while working on my skewT, that you can't tell the >> axis objects to clip their ticklines. If you want to set clipping on >> each individual tickline. I saw that the code is there in the >> relevant classes, but the lines to set clipping are disabled in >> set_clip_path() or _set_artist_props(). My SVN foo is failing me >> right now, so I can't find anything to tell me why these changes were >> made. > > Does this link work for you? (Sometimes sourceforge is painfully slow, > sometimes bits of it seem to simply go away.) > > http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/ > > > I find the browser view quite helpful for finding out which changes were > made when, and by whom. To find out why, one must often ask or go to > the mailing list archive. Typical. I find it quite useful too, which is why I tried going there earlier today. SF had turned off Viewvc due to the server load it was causing. Now of course when you go to it, it's on :) >> Anyone have any ideas? > > I don't, but it appears that the set_clip_path method was introduced in > 4817 by Mike D., complete with the commented-out lines. > http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/axis.py?annotate=5651 > > > http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/axis.py?view=diff&r1=4816&r2=4817 > Alright. Mike? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - 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] scipy 2008 sprints
Paul Kienzle wrote: > Hello, > > Anyone planning to attend post-SciPy2008 code sprints? > > Some projects I'm interested in: > > support for units (px, pt/in/cm/mm, em/ex/, %axis/%figure) > style sheet editor (needs backend support for forms and menus) > canvas interface for interactive plotting applications > > - Paul I'll be there the whole week, Monday-Sunday. I'm good to help out where I can. My personal goal is to get some work on OpenGL going, but that's less sprinty and more by myself kind of stuff (unless someone else is interested). Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - 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 scroll wheel
Paul Kienzle wrote: > Hi, > > I added support for scroll wheel events in wx. This includes > a new attribute event.step since the wx mouse wheel event > reports larger steps when scrolling faster. I don't see > how to check step in gtk, so I set step to +1 and -1 for up > and down. > > Can someone with gtk please run the following to make sure > I didn't break anything: > > examples/pylab_examples/image_slices_viewer.py > > Works for me. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - 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] scipy 2008 sprints
On Thu, Jul 24, 2008 at 12:25 PM, Paul Kienzle <[EMAIL PROTECTED]> wrote: > canvas interface for interactive plotting applications The Chaco devs (in particular Peter Wang) will be there, so it would be worthwhile having a detailed conversation with him on this matter, as this is definitely Chaco's strong suit and I'm sure he'd have a lot of good ideas on the matter. Who knows, we might even inch a bit closer towards that mythical mpl/chaco unification :) Cheers, f - 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] clabel improvements
David Kaplan wrote:
>> * Using an empty list in a python kwarg as the default is a gotcha, as in
>>
>> def calc_label_rot_and_inline( self, slc, ind, lw, lc=[], spacing=5 ):
>>
>> The reason is that if the function mutates the list, this often leads
>> to unintended consequences as the list is module level and thus shared
>> between instances and method calls. The standard idiom for mutable
>> (lists and dicts) keyword args s
>>
>> def func(x=None):
>> if x is None: x = []
>>
>> I have fixed this in contour.py
>>
>
> I don't really understand how this can be a problem, but it probably
> isn't that important unless you feel like enlightening me.
The default value for the function is created when the interpreter
executes the define statement. Thus, if you were to do something that
modifies the list inplace, like append(), the default argument will
retain those changes. For instance, try this:
def foo(l=[]):
l.append('foo')
print l
foo()
foo()
foo(['bar'])
foo()
Ryan
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
-
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] clipping tick lines
Eric Firing wrote: >> Anyone have any ideas? > > I don't, but it appears that the set_clip_path method was introduced in > 4817 by Mike D., complete with the commented-out lines. > http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/axis.py?annotate=5651 > > > http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/axis.py?view=diff&r1=4816&r2=4817 > Uncommenting them doesn't seem to break anything and it solves my problem as well. I guess there could be performance impacts so I'll wait for Mike to weigh in. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - 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] Bug in Quiverkey
Hi, This is probably best directed to Eric, but to anyone who knows how quiver works with regard to units: QuiverKey right now is failing if coordinates="inches". There are a couple of non-defined variables accesses in there, and it just doesn't look right. The offending part of the if chain starts at line 292 of quiver.py. I'm not familiar enough with how this code works to try and fix it. None of the example code seems to exercise the coordinates parameter of quiverkey, just the units parameter for quiver. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - 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] Wind Barbs Full Patch
Eric Firing wrote: > John Hunter wrote: >> On Wed, Jul 23, 2008 at 10:05 PM, Ryan May <[EMAIL PROTECTED]> wrote: >> >>> Ok, it fixes the problem if I pass dpi=72 to savefig(). >>> Curiously, >>> passing dpi=72 to Figure() does not have the same effect. So now how >>> do I >> >> That is because "savefig" has its own dpi, which overrides the figure >> dpi. Tee ideas is that you typically want a different dpi for the UI >> window and for the harcopy >> >>> fix it? I'm really not sure what's going wrong here. If I had to >>> guess, >>> it's a problem between figure size being in inches while I'm drawing in >>> pixels (still don't know how that works, because there's no way those >>> barbs >>> are 9 pixels long). >> >> I'm not familiar enough with the windbarb code to know where the "9 >> pixel" thing that is bothering you is creeping in, I'm just saying >> that using an identity transform means you are drawing in canvas >> (pixel) space and not accounting for dpi. The Figure instance has a >> "dpi_scale_transform" that is designed to handle dpi scaling, and >> updates itself when the figure dpi is changed so you don't have to >> handle the callbacks. Take a look at this and see if you can >> incorporate it. If you have troubles, Michael or I can advise >> further. >> >> If you clarify the "9 pixel" problem that is bothering you, I may be >> able to help more sooner... > > Part of the problem is the horrible and misleading sizes arg in > PolyCollections, probably a hangover (yes, a headache) from supporting a > Matlab-compatible argument in scatter. I can try to straighten this out > and clarify the situation after the release, not before. I will add an > alternative kwarg to scatter at the same time, and hope the old usage > gradually dies out. That might be part of it, I'm not sure. My problem is that I have length set to 7 in the code. That implies that when I draw, the distance along the y-axis between where I start and where I end is 7 units (which is then rotated). What gets shown on my screen (when the BarbCollection transform is set to IdentityTransform()) is not possibly 7 pixels long. My gnome-panel bar is 22 pixels high, and that looks like a pretty good fit to how long things are actually in the figure I see on screen. This is at my default figure dpi of 72. What else is confusing is how that relates to DPI. When I change the figure's dpi, using set_dpi, (and redraw), I get physically *bigger* barbs. To me, if I'm actually specifying pixels, there's no way that they should get bigger when I change the DPI. Then I also can't figure out what the PS backend is doing. If PS is hardcoded to 72 DPI, why does passing dpi=72 to savefig() have any effect? I found the fig.dpi_scale_trans. However, this then makes things too big on the on screen figure when I use this as the tranform for the BarbCollection. Thoughts? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - 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] Wind Barbs Full Patch
On Thu, Jul 24, 2008 at 10:00 PM, Ryan May <[EMAIL PROTECTED]> wrote: > What else is confusing is how that relates to DPI. When I change the > figure's dpi, using set_dpi, (and redraw), I get physically *bigger* barbs. > To me, if I'm actually specifying pixels, there's no way that they should > get bigger when I change the DPI. When you increase the dpi, the canvas gets bigger (inches*dpi equals canvas size in pixels). If you are drawing in pixels, and not scaling, the barbs should look smaller, since they are a smaller proportion of the canvas size. So if this explanation is right, the barbs will look smaller with larger dpi. > Then I also can't figure out what the PS backend is doing. If PS is > hardcoded to 72 DPI, why does passing dpi=72 to savefig() have any effect? ps should be unaffected, but dpi dependent backends will. By setting the dpi to be 72, it should make the *other* backend look like the ps backend and the ps backend should be unaffected. 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] Bug in Quiverkey
Ryan May wrote: > Hi, > > This is probably best directed to Eric, but to anyone who knows how > quiver works with regard to units: QuiverKey right now is failing if > coordinates="inches". There are a couple of non-defined variables > accesses in there, and it just doesn't look right. The offending part > of the if chain starts at line 292 of quiver.py. I'm not familiar > enough with how this code works to try and fix it. None of the example > code seems to exercise the coordinates parameter of quiverkey, just the > units parameter for quiver. > > Ryan > Fixed in 5865, after stripping whitespace in the previous commit. Eric - 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] Wind Barbs Full Patch
John Hunter wrote: > On Thu, Jul 24, 2008 at 10:00 PM, Ryan May <[EMAIL PROTECTED]> wrote: > >> What else is confusing is how that relates to DPI. When I change the >> figure's dpi, using set_dpi, (and redraw), I get physically *bigger* barbs. >> To me, if I'm actually specifying pixels, there's no way that they should >> get bigger when I change the DPI. Ryan, I think you are giving the length in points (sort of, because of the bizarre size kwarg), not pixels. So you are right--the barbs are not 7 pixels long. The translation from points to pixels for the Agg backend depends on the dpi, as John says below. > > When you increase the dpi, the canvas gets bigger (inches*dpi equals > canvas size in pixels). If you are drawing in pixels, and not > scaling, the barbs should look smaller, since they are a smaller > proportion of the canvas size. So if this explanation is right, the > barbs will look smaller with larger dpi. > >> Then I also can't figure out what the PS backend is doing. If PS is >> hardcoded to 72 DPI, why does passing dpi=72 to savefig() have any effect? > > ps should be unaffected, but dpi dependent backends will. By setting > the dpi to be 72, it should make the *other* backend look like the ps > backend and the ps backend should be unaffected. I don't think so, unless I am misunderstanding your phrase "make the *other* backend look like the ps backend". If you pass 72 dpi to the Agg backend, you will get a relatively small number of pixels, and when you display it at natural size on the screen, it will be tiny--only a little more than half-size on my laptop screen, for example. Whereas, if the ps renderer knows the screen dpi, then it will display full-size. > > 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] "plot" plots too many markers when projection="hammer" is used.
Hi, While playing a little bit with "custom_projection_example.py", I found that "plot" command with projection="hammer" plots too many markers. For example, subplot(111, projection="hammer") grid(True) p = plot([-1, 1, 1], [-1, -1, 1], "o") show() plots more than 100 circles, instead of 3. And I presume that this is a bug not a feature. This seems to be because the draw() method of the Line2D class uses self._transformed_path for plotting Markers, but number of vertices in the _transformed_path increases in the curved coordinate system as in the example. A patch to fix this is attached. It defines a new property "self._transformed_path_mark" in the recache() method as follows tr = self.get_transform() self._transformed_path = TransformedPath(self._path, tr) self._transformed_path_mark = Path(tr.transform_non_affine(self._path.vertices)) and draw() method uses this for plotting markers. tpath, affine = self._transformed_path_mark, \ self.get_transform().get_affine() As I'm not 100% sure about how the transform things work, I may have missed something. But I got correct results for cases I tried. So I hope this patch is reviewed and applied. Regards, -JJ - 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] "plot" plots too many markers when projection="hammer" is used.
I forgot to attach the patch. -JJ On Fri, Jul 25, 2008 at 2:39 AM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote: > Hi, > > While playing a little bit with "custom_projection_example.py", I > found that "plot" command with projection="hammer" plots too many > markers. > > For example, > >subplot(111, projection="hammer") >grid(True) >p = plot([-1, 1, 1], [-1, -1, 1], "o") >show() > > plots more than 100 circles, instead of 3. And I presume that this is > a bug not a feature. > This seems to be because the draw() method of the Line2D class uses > self._transformed_path for plotting Markers, but number of vertices > in the _transformed_path increases in the curved coordinate system as > in the example. > > A patch to fix this is attached. It defines a new property > "self._transformed_path_mark" in the recache() method as follows > >tr = self.get_transform() >self._transformed_path = TransformedPath(self._path, tr) >self._transformed_path_mark = > Path(tr.transform_non_affine(self._path.vertices)) > > > and draw() method uses this for plotting markers. > >tpath, affine = self._transformed_path_mark, \ >self.get_transform().get_affine() > > As I'm not 100% sure about how the transform things work, I may have > missed something. But I got correct results for cases I tried. > So I hope this patch is reviewed and applied. > > Regards, > > -JJ > mpl_line2d.patch Description: Binary data - 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
