Re: [matplotlib-devel] Debian Bug report logs - #503148
Sandro Tosi wrote: > On Mon, Oct 27, 2008 at 15:25, Manuel Metz <[EMAIL PROTECTED]> wrote: >> Just put the Debian bugreport on the list here. I will look at this. >> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503148 > > Thanks Manuel, and sorry for not forwarding it and being a little bit > "absent" these days > This if fixed now on the trunk in r6459. (Sandro, please note: the patch is not applicable to the version 0.98.3 If you need a patch for the Debian package, please let me know). mm - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Debian Bug report logs - #503148
Hello! On Mon, Dec 1, 2008 at 11:24, Manuel Metz <[EMAIL PROTECTED]> wrote: > Sandro Tosi wrote: >> On Mon, Oct 27, 2008 at 15:25, Manuel Metz <[EMAIL PROTECTED]> wrote: >>> Just put the Debian bugreport on the list here. I will look at this. >>> >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503148 >> >> Thanks Manuel, and sorry for not forwarding it and being a little bit >> "absent" these days >> > > This if fixed now on the trunk in r6459. > > (Sandro, please note: the patch is not applicable to the version 0.98.3 > If you need a patch for the Debian package, please let me know). Nah, I can wait for your next release (that is really soon now, isn't it? :) ). Thanks for the fix, -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi - 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 Matplotlib-devel@lists.sourceforge.net 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] markersize change
Ok. I'll apply this fix to SVN. I'll have to go back and find a better way to do this later. Personally, I think the markers at normal to largish size (5+ pixels in diameter) look too fuzzy without the pixel quantizing. Mike Andrew Straw wrote: > Hi Mike, > > That does fix the issue. Another thing I noticed that is fixed with your > patch: the '.' marks appear like '+' when drawn at a smallish size. > > Thanks, > Andrew > > Michael Droettboom wrote: > >> This might be related to a change I made in the Agg backend to make the >> markers look better by rounding their coordinates to the nearest pixel. >> It certainly made the stock markers at a standard size look better, but >> I suspect as they get smaller, they are converging down to the same >> value, thus having a truly zero-sized marker. >> >> I'm away from a machine with build tools at the moment, so can't >> confirm. Does the attached patch work for you? >> >> Mike >> >> Andrew Straw wrote: >> >>> John Hunter wrote: >>> >>> 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? >>> It doesn't happen with PS or SVG, so I'll say yes. >>> >>> - >>> 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 >>> Matplotlib-devel@lists.sourceforge.net >>> 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 >> Matplotlib-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] transforms bug: axhline with log y scale
Mike,
This is a gentle check--I suspect my original message, below, may have
slipped under the radar.
Eric
Eric Firing wrote:
> Mike (or other transforms afficionados),
>
> The thread "[Matplotlib-users] Bug saving semilogy plots with a axvline"
> started by [EMAIL PROTECTED] pointed to a bug that appears to be deep in
> the transforms code. My head is spinning. The problem seems to be
> related to the propagation of the _invalid attribute in transforms, in
> the case of a mixed data/axes transform such as ashline uses. The
> following one-line change in TransformNode, second line from the bottom,
> works:
>
> def invalidate(self):
> """
> Invalidate this :class:`TransformNode` and all of its
> ancestors. Should be called any time the transform changes.
> """
> # If we are an affine transform being changed, we can set the
> # flag to INVALID_AFFINE_ONLY
> value = (self.is_affine) and self.INVALID_AFFINE or self.INVALID
>
> # Shortcut: If self is already invalid, that means its parents
> # are as well, so we don't need to do anything.
> if self._invalid == value:
> return
>
> if not len(self._parents):
> self._invalid = value
> return
>
> # Invalidate all ancestors of self using pseudo-recursion.
> parent = None
> stack = [self]
> while len(stack):
> root = stack.pop()
> # Stop at subtrees that have already been invalidated
> if root._invalid != value or root.pass_through:
> root._invalid = self.INVALID # value <===
> stack.extend(root._parents.keys())
>
> Now, I know this is the wrong solution, because it defeats all the
> cleverness with the _invalid values; but perhaps it will save you a few
> minutes in finding the right solution.
>
> To reproduce the problem, do this in ipython -pylab:
>
> axhline(5)
> yscale('log')
> ylim(0.5,30)
>
> 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
> Matplotlib-devel@lists.sourceforge.net
> 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] transforms bug: axhline with log y scale
Thanks for the reminder. It wasn't propagating the "non-affine"
invalidation correctly. I think I have a fix in r6465, but please let
me know if you see anything else funny.
Cheers,
Mike
Eric Firing wrote:
> Mike,
>
> This is a gentle check--I suspect my original message, below, may have
> slipped under the radar.
>
> Eric
>
> Eric Firing wrote:
>> Mike (or other transforms afficionados),
>>
>> The thread "[Matplotlib-users] Bug saving semilogy plots with a
>> axvline" started by [EMAIL PROTECTED] pointed to a bug that appears to
>> be deep in the transforms code. My head is spinning. The problem
>> seems to be related to the propagation of the _invalid attribute in
>> transforms, in the case of a mixed data/axes transform such as
>> ashline uses. The following one-line change in TransformNode, second
>> line from the bottom, works:
>>
>> def invalidate(self):
>> """
>> Invalidate this :class:`TransformNode` and all of its
>> ancestors. Should be called any time the transform changes.
>> """
>> # If we are an affine transform being changed, we can set the
>> # flag to INVALID_AFFINE_ONLY
>> value = (self.is_affine) and self.INVALID_AFFINE or
>> self.INVALID
>>
>> # Shortcut: If self is already invalid, that means its parents
>> # are as well, so we don't need to do anything.
>> if self._invalid == value:
>> return
>>
>> if not len(self._parents):
>> self._invalid = value
>> return
>>
>> # Invalidate all ancestors of self using pseudo-recursion.
>> parent = None
>> stack = [self]
>> while len(stack):
>> root = stack.pop()
>> # Stop at subtrees that have already been invalidated
>> if root._invalid != value or root.pass_through:
>> root._invalid = self.INVALID # value <===
>> stack.extend(root._parents.keys())
>>
>> Now, I know this is the wrong solution, because it defeats all the
>> cleverness with the _invalid values; but perhaps it will save you a
>> few minutes in finding the right solution.
>>
>> To reproduce the problem, do this in ipython -pylab:
>>
>> axhline(5)
>> yscale('log')
>> ylim(0.5,30)
>>
>> 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
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] reimplemented legend class
John Hunter wrote:
> 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.
>
Hi Jae-Joon and John,
The MPL sizer toolkits looks entirely unaffected by these changes, and
the demo looks very convincing. So from my perspective this would be a
benefit to have in assuming that the issues John raises can be dealt with.
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] reimplemented legend class
Thanks John, I'll work on the revisions. > > +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? > My original intention with the OffsetBox was to only support the translation in the display coordinates. VPacker and HPacker even doesn't use the transformation explicitly. One of the reason for this was that the size of the Text objects does not depends on the transformation. I guess in most cases, children will have a fixed offset relative to their parent container. Introducing an arbitrary transformation between the child and the parent may make things complicated. On the other hand, the top most container may have its own transformation. In the use case I considered (legend), the size of the box is only known at the drawing time and the offset of the box needs to be calculated on the fly (e.g., using the size of the box and the anchor point). The reason that the offset can be a callable object is to support such situation. 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. > > +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? > We may do it by adjusting the baseline of the multi-line text. In the current implementation, the baseline of the multi-line text is set to the baseline of the first line. It may not give the perfect center-align, but will give a reasonable results. The other way is to treat the multiline text separately during the packing. But this will need more work as the current Packer class does not know whether its child is multi-line text or not. I'll see what I can do. 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] transforms bug: axhline with log y scale
Michael Droettboom wrote: > Thanks for the reminder. It wasn't propagating the "non-affine" > invalidation correctly. I think I have a fix in r6465, but please let > me know if you see anything else funny. > > Cheers, > Mike Mike, It looks like that helps, fixing the window resize behavior, but zooming and panning still do not work in the original example given by João Silva: import matplotlib.pyplot as pl import numpy as np x = np.linspace(0.0,1.0,100) pl.semilogy(x,x**2) pl.axvline(x=0.5,ls='--',color='k') pl.show() 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
