headers
Manuel Metz | 1 Dec 11:24
Picon
Favicon

Re: Debian Bug report logs - #503148

Sandro Tosi wrote:
> On Mon, Oct 27, 2008 at 15:25, Manuel Metz
<mmetz@...> 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=/
Permalink | Reply | 1 comment |
headers
Sandro Tosi | 1 Dec 11:29
Picon
Favicon

Re: Debian Bug report logs - #503148

Hello!

On Mon, Dec 1, 2008 at 11:24, Manuel Metz <mmetz@...> wrote:
> Sandro Tosi wrote:
>> On Mon, Oct 27, 2008 at 15:25, Manuel Metz
<mmetz@...> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Hunter | 1 Dec 15:53
Picon
Gravatar

Re: reimplemented legend class

On Sun, Nov 30, 2008 at 11:53 AM, Jae-Joon Lee <lee.j.joon@...> 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,
             )
(Continue reading)

Permalink | Reply | 10 comments |
headers
Michael Droettboom | 1 Dec 16:23

Re: 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:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Firing | 1 Dec 19:19
Favicon
Gravatar

Re: 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 jsilva@... 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:
(Continue reading)

Permalink | Reply | 7 comments |
headers
Michael Droettboom | 1 Dec 20:35

Re: 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 jsilva@... 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.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Andrew Straw | 1 Dec 21:03
Picon
Gravatar

Re: reimplemented legend class

John Hunter wrote:
> On Sun, Nov 30, 2008 at 11:53 AM, Jae-Joon Lee <lee.j.joon@...> 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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jae-Joon Lee | 2 Dec 01:00
Picon
Gravatar

Re: 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
(Continue reading)

Permalink | Reply | 8 comments |
headers
Eric Firing | 2 Dec 07:24
Favicon
Gravatar

Re: 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=/
(Continue reading)

Permalink | Reply | 5 comments |
headers
John Hunter | 2 Dec 13:45
Picon
Gravatar

Re: reimplemented legend class

On Mon, Dec 1, 2008 at 6:00 PM, Jae-Joon Lee <lee.j.joon@...> 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=/
Permalink | Reply | 7 comments |

Gmane