matplotlib-devel Mailing List for matplotlib (Page 2)

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:

    Charlie> Before I bang my head against the wall I figured I would
    Charlie> check the list.  I have a script that uses the radio
    Charlie> button widget in a TkAgg.  This worked not too long ago,
    Charlie> but now it is not responding to clicks with the latest
    Charlie> matplotlib.  Has there been changes recently to the TkAgg
    Charlie> backend that would affect this?

It doesn't look like it:

peds-pc311:~/mpl> svn log lib/matplotlib/backends/backend_tkagg.py
------------------------------------------------------------------------
r2139 | dsdale | 2006-03-11 18:11:40 -0600 (Sat, 11 Mar 2006) | 7
lines

added **kwargs to all backend_*.print_figure
methods to provide papertype kwarg to backend_ps

fixed landscape orientation for usetex option

added subprocess module from python-2.4

------------------------------------------------------------------------
r1889 | cmoad | 2005-11-30 14:05:05 -0600 (Wed, 30 Nov 2005) | 2 lines

assume png on no extension save

------------------------------------------------------------------------
r1591 | cmoad | 2005-08-08 09:46:47 -0500 (Mon, 08 Aug 2005) | 2 lines

almost have tkagg blitting working

------------------------------------------------------------------------
r1586 | jdh2358 | 2005-08-05 11:13:26 -0500 (Fri, 05 Aug 2005) | 2
lines

small cursor fix

------------------------------------------------------------------------
r1584 | cmoad | 2005-08-04 14:13:08 -0500 (Thu, 04 Aug 2005) | 2 lines

Added blit to FigureCanvasTkAgg, but it does not account for the bbox
yet.



Maybe it is a tk version problem?

JDH

Before I bang my head against the wall I figured I would check the
list.  I have a script that uses the radio button widget in a TkAgg.=20
This worked not too long ago, but now it is not responding to clicks
with the latest matplotlib.  Has there been changes recently to the
TkAgg backend that would affect this?

Thanks
- Charlie

Although I will apply a simple bugfix for this, it brings up a question 
I have wanted to ask for some time:

Would it not make more sense for the backends to simply not stroke the 
patch boundaries if one specifies 'None' as the edgecolor?  As it is, 
when we don't actually need edges, the backend is doing twice the work 
it needs to; and in the case of postscript, outputting a file twice as 
large as necessary (apart from the constant overhead).  In addition, 
unnecessary boundary lines may make patches slightly larger than 
intended.  An alternative way to say that we don't want edges drawn 
would be to specify zero width, and then let the backends interpret this 
as "do not draw" rather than "draw minimum width".  This behavior could 
be added one backend at a time with little disruption, I suspect.

Eric

Darren Dale <dd...@co...> writes:

>> > OK, I refactored TextWithDash, and my changes passed backend_driver.py.
>> > setp(axes().get_yticklabels()) gives a comprehensive list as of svn 2206.
>
> I fixed the bug John pointed out, and unmasked the refactored version of 
> TextWithDash in svn 2226. 

Yes, 'size' is listed in the output now. However, now it seems that
there are too many things listed: 

    label: any string
    text: string

The commands setp(gca().get_yticklabels()[0], 'label', 'foo') and
setp(..., 'text', 'foo') do nothing. Of course, the right way to
modify the tick labels is to call gca().set_yticklabels(['foo',...]) 
(or setp(gca(), 'yticklabels', ['foo',...])) which does quite some
magic to change the label text (e.g., the Axis object's major
formatter is changed into FixedFormatter(ticklabels)). Having 'label'
and 'text' listed in the setp output could mislead people.

However, if you draw a TextWithDash yourself, you _can_ change the
text with setp, and indeed the docstring claims that TextWithDash is
"intended to be a drop-in replacement for Text". E.g., the following
works: t=text(1,1,'foo',withdash=True); setp(t,'text', 'bar'); 
So it wouldn't be right to simply remove set_text from TextWithDash,
which would otherwise have been my suggestion.

-- 
Jouni

On Wednesday 22 March 2006 14:24, Darren Dale wrote:
> 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.

I fixed the bug John pointed out, and unmasked the refactored version of 
TextWithDash in svn 2226. 

Darren

On 3/22/06, Eric Firing <ef...@ha...> wrote:
> 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.

Hi,
I think it would be nice if pylab "semantics" were kept close to matlab.
Maybe for instance axis('scaled') could be renamed to axis('image'), and
use similar wording as mathworks documentation in the docstrings?

http://www.mathworks.com/access/helpdesk/help/techdoc/ref/axis.html

Helge

On Wednesday 22 March 2006 2:38 pm, Darren Dale wrote:
> 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.

Game on!

The new API is functional again in the postscript backend. All the bugs I am 
aware of have been cleared. I'm holding off on a note to the CHANGELOG until 
we go a few days without bug reports.

Darren

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

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> The problem is in draw_line_collection, and it looks
    Darren> complicated.


I wrote that mess :-)  This is the baseclass method for backends that
do not implement draw line collection.  I will fix it for the new
API.  You may want to look over the draw_*_collection methods in
backend bases and see if there are any significant performance boosts
to be had by implementing them in backend_ps.  If you need more
distraction, that is :-)

JDH

>>>>> "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.

JDH

On Tuesday 21 March 2006 18:25, John Hunter 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.

The problem is in draw_line_collection, and it looks complicated.

Here is a bug report related to the output of setp(axes().get_yticklabels()), 
the complaint is that you can set the size but size is not listed.
 
https://sourceforge.net/tracker/index.php?func=detail&aid=1357969&group_id=80706&atid=560720

The reason is that TextWithDash has a Text object attribute and delegates most 
of its methods to that object via __getattr__ and __setattr__. Can anyone 
tell me why this approach was favored over deriving TextWithDash from Text?

Thanks, 
Darren

>>>>> "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.

JDH

On 18/03/06, John Hunter <jdh...@ac...> wrote:
>
>     Jose>   The usual trick in rpms it to require a nest X to test for
>     Jose> pygtk.
>
> I'm not sure I understand this.  We have the following
>
> if BUILD_GTK:
>     try:
>         import gtk
>     except ImportError:
>         print 'GTK requires pygtk'
>         BUILD_GTK=3D0
>     except RuntimeError:
>         print 'pygtk present but import failed'
>
>
> The ImportError is designed to catch the case where pygtk is not
> present and the RuntimeError is designed to warn but not fail if X is
> not present.  I'll do some testing tonight to see if I can isolate
> where this is failing.

  I see what you mean. It makes sense. :-)
  I was talking about using xnest to make that code pass the test.
Clearly your approach is more appropriate. :-)

> JDH

--
Jos=E9 Ab=EDlio