matplotlib-devel Mailing List for matplotlib

John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> 
> 
> Eric> Correct. I found and fixed one clear bug, but now it is
> Eric> tripping somewhere else. I'll track it down.
> 
> It would be nice to collect these torture test scripts in a subdir of
> unit with a torture_driver routine. More poorman's unit testing....
> 
> Charlie, feel free to contribute your zeros bar as exhibit A.
Good idea.
I found and fixed the second bug (what a difference "<" vs "<=" can 
make!) and svn now passes this test.
Eric

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> Correct. I found and fixed one clear bug, but now it is
 Eric> tripping somewhere else. I'll track it down.
It would be nice to collect these torture test scripts in a subdir of
unit with a torture_driver routine. More poorman's unit testing....
Charlie, feel free to contribute your zeros bar as exhibit A.
JDH

John Hunter wrote:
>>>>>>"Charlie" == Charlie Moad <cw...@gm...> writes:
> 
> 
> Charlie> This might not be related, but since when did bar charts
> Charlie> of zero break?
> 
> Charlie> bar(arange(10), zeros(10))
> 
> I think this is related to Eric's MaxNLocator support code.
Correct. I found and fixed one clear bug, but now it is tripping 
somewhere else. I'll track it down.
Eric

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
 Charlie> This might not be related, but since when did bar charts
 Charlie> of zero break?
 Charlie> bar(arange(10), zeros(10))
I think this is related to Eric's MaxNLocator support code.
JDH

On 3/20/06, Darren Dale <dd...@co...> wrote:
> On Monday 20 March 2006 17:57, John Hunter wrote:
> > >>>>> "Darren" =3D=3D Darren Dale <dd...@co...> writes:
> >
> > Darren> I havent modified extension code before, and this change
> > Darren> would affect all the *agg backends, so I dont want to
> > Darren> commit before checking.
> >
> > Here is a quick checklist of things to consider before committing Agg
> > changes
> >
> > 1) makes a plot that you can interact with
>
> check
>
> > 2) passes backend_driver.py screening for Agg
>
> check
>
> > 3) passes unit/memleak_hawaii3.py with no appreciable memory leak
>
> Average memory consumed per loop: -0.1637k bytes (? thats odd.)
>
> > 4) does something useful....
>
> It helped me procrastinate, that's sort of useful.
>
> > If it satisfies these, in my view it is suitable for public consumption=
.
>
> As of svn 2181, if you use a *Agg backend or the postscript backend with =
the
> new API, the following script will yield a gap in the line, see attached.=
 I
> guess we need to decide if this is desireable behavior in general, I thin=
k it
> is pretty useful myself.
>
> a=3Darange(21, dtype=3D'd')
> a[10]=3Dnan
> plot(a, '-o')
> savefig('nan_masked.png')
>
This might not be related, but since when did bar charts of zero break?
bar(arange(10), zeros(10))
I have animation code, and this has been the starter code for a long
time. In the last few days this has broke though with a
ZeroDivisionError in ticker.py.
- Charlie

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> My implementation of draw_lines is not compatible with
 Darren> draw_line_collection. I'm masking draw_markers in CVS
 Darren> until I get the problem sorted out.
I thought my backend_bases patch would fix this -- I'll take another
look.
JDH

All,
I think that aspect ratio handling in svn is now usable; I have checked 
simple uses of the pylab axis() function, together with interactive 
resizing, pan, and zoom of images, simple plots, and ganged plots. I 
have tried to keep the pylab interface pretty much unchanged for now; 
but if people have ideas as to how it could be improved, I would be 
happy to consider them. Personally, I find some of the options 
unintuitive. Maybe we could find better names than 'equal' and 
'scaled', for example. Even with the docstrings, I have a hard time 
keeping track of which is supposed to do what.
Jeff, I haven't forgotten your patch to add anchoring options, but I 
still want to think about it in a slightly larger context; one way or 
another it will be done soon.
Eric

On Tuesday 21 March 2006 19:10, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
> Darren> The problem is in draw_line_collection, and it looks
> Darren> complicated.
>
> OK, I just committed a "fix" for this problem. There is no elegant
> way to do it in backend bases because of the way collections use
> offsets and offset transforms. So I just hacked it up to do the
> transformations as before and pass an identity transform off to the
> backend in using the newstyle API. Another argument for implementing
> the methods in the backends....for a rainy day.
My implementation of draw_lines is not compatible with draw_line_collection. 
I'm masking draw_markers in CVS until I get the problem sorted out.

On Wednesday 22 March 2006 09:49, Darren Dale wrote:
> On Tuesday 21 March 2006 18:53, John Hunter wrote:
> > >>>>> "Darren" == Darren Dale <dd...@co...> writes:
> >
> > Darren> The reason is that TextWithDash has a Text object
> > Darren> attribute and delegates most of its methods to that object
> > Darren> via __getattr__ and __setattr__. Can anyone tell me why
> > Darren> this approach was favored over deriving TextWithDash from
> > Darren> Text?
> >
> > I think __getattr__ and __setattr__ are mostly evil since they lead to
> > hard to debug code and break things like tab completion in ipython and
> > object inspection. I'm +1 for refactoring TextWiithDashes to use
> > inheritance or otherwise expose the attributes directly.
>
> OK, I refactored TextWithDash, and my changes passed backend_driver.py.
> setp(axes().get_yticklabels()) gives a comprehensive list as of svn 2206.
> The old TextWithDash is still there, but masked, just in case.
Strike that, John found a bug that was exposed by dashtick. I reverted back to 
the old behavior.

On Tuesday 21 March 2006 18:25, you wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
> Darren> However, the transform is not being passed to draw_lines,
> Darren> and so the method works as if the old API were being
> Darren> used. Is this a bug? Shouldn't the transform be provided
> Darren> to draw_lines when using the new API?
>
> Yes, it should be passed. I recommend removing the transform=None
> functionality to *require* the transform be passed. If it is not,
> then an exception will be raised and it will be easy to track down the
> errant call.
I committed this change to svn. I'll leave it up to you whether to change it 
back for an actual release.
Darren

On Tuesday 21 March 2006 18:53, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
> Darren> The reason is that TextWithDash has a Text object
> Darren> attribute and delegates most of its methods to that object
> Darren> via __getattr__ and __setattr__. Can anyone tell me why
> Darren> this approach was favored over deriving TextWithDash from
> Darren> Text?
>
> I think __getattr__ and __setattr__ are mostly evil since they lead to
> hard to debug code and break things like tab completion in ipython and
> object inspection. I'm +1 for refactoring TextWiithDashes to use
> inheritance or otherwise expose the attributes directly.
OK, I refactored TextWithDash, and my changes passed backend_driver.py. 
setp(axes().get_yticklabels()) gives a comprehensive list as of svn 2206. The 
old TextWithDash is still there, but masked, just in case.
Darren

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> The problem is in draw_line_collection, and it looks
 Darren> complicated.
OK, I just committed a "fix" for this problem. There is no elegant
way to do it in backend bases because of the way collections use
offsets and offset transforms. So I just hacked it up to do the
transformations as before and pass an identity transform off to the
backend in using the newstyle API. Another argument for implementing
the methods in the backends....for a rainy day.
JDH