matplotlib-devel Mailing List for matplotlib

On Tuesday 29 August 2006 15:49, Darren Dale wrote:
> On Tuesday 29 August 2006 13:01, Will Lee wrote:
> > I need to apply the attached patch in order to get the setup.py script to
> > run. I'm using python 2.4.3 with matplotlib-0.87.4. If I do not apply
> > this patch, I got the following. It seems like there's a change in tk's
> > getvar implementation. The tk.getvar('tcl_library") returns an
> > _tkinter.Tcl_Obj instead of a string.
>
> What OS? It returns a string on linux with python-2.4.3 and tk-8.4.13.
I applied your patch, tested the build process on my own machine (still ok) 
and commited it to svn. Thanks for the report.
Darren

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
 Charlie> Sounds good. Two open windows issues that aren't
 Charlie> showstoppers are: 1) Inclusion of msvcp71.dll? 2)
 Charlie> Building against wxpython unicode or ansii? (until we
 Charlie> move to pure python blitting)
Since it is a point release, I don't think we should change the way we
build against wx, since that is libel to confuse and piss off folks
who've just made the switch to unicode wx for 87.4. I don't have
enough insight into the msvcp71.dll issues to comment.
JDH

On 8/29/06, John Hunter <jdh...@ac...> wrote:
> >>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
> >> Travis, would you care to comment?
>
> Charlie> He made a comment on the numpy list. We can shoot for a
> Charlie> mpl release by the end of the week. Are there any
> Charlie> lingering issues?
>
> Apparently numpy 1.05b is due out over the weekend, so we can
> coordinate with that release. As soon as Travis puts it up, Charlie
> you can put out mpl 0.87.5 after a quick test of backend_driver which
> is currently passing with svn numpy.
Sounds good. Two open windows issues that aren't showstoppers are:
1) Inclusion of msvcp71.dll?
2) Building against wxpython unicode or ansii? (until we move to pure
python blitting)

On Tuesday 29 August 2006 13:01, Will Lee wrote:
> I need to apply the attached patch in order to get the setup.py script to
> run. I'm using python 2.4.3 with matplotlib-0.87.4. If I do not apply
> this patch, I got the following. It seems like there's a change in tk's
> getvar implementation. The tk.getvar('tcl_library") returns an
> _tkinter.Tcl_Obj instead of a string.
What OS? It returns a string on linux with python-2.4.3 and tk-8.4.13.

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
 >> Travis, would you care to comment?
 Charlie> He made a comment on the numpy list. We can shoot for a
 Charlie> mpl release by the end of the week. Are there any
 Charlie> lingering issues?
Apparently numpy 1.05b is due out over the weekend, so we can
coordinate with that release. As soon as Travis puts it up, Charlie
you can put out mpl 0.87.5 after a quick test of backend_driver which
is currently passing with svn numpy.
JDH

On Tuesday 29 August 2006 15:21, Charlie Moad wrote:
> We can shoot for a mpl release by the end of the week. Are there any 
> lingering issues? 
There is this tk unicode nonsense in setupext.py.
I was hoping to get these build warnings taken care of on Linux (see my recent 
post), but its not important.

On 8/29/06, Darren Dale <dd...@co...> wrote:
> On Tuesday 29 August 2006 14:07, Charlie Moad wrote:
> > On 8/29/06, Darren Dale <dd...@co...> wrote:
> > > On Monday 14 August 2006 17:48, John Hunter wrote:
> > > > >>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
> > > >
> > > > Charlie> Numpy 1.0b2 was released last night and Travis hopes this
> > > > Charlie> will remain binary compatible with numpy 1.0. Are there
> > > > Charlie> any objections to a minor release bump? I could do this
> > > > Charlie> an soon as tomorrow.
> > > >
> > > > Let's shoot for Tuesday evening, in advance of scipy. I'm going to
> > > > make one more attempt before then to get the damned widget lock
> > > > working right....
> > >
> > > I hate to raise this issue again, but what is the status of the next
> > > release?
> >
> > Seeing numpy b3 and then b4 has made me hesitate. I posted a snapshot
> > to the user list a while back just in case anyone wanted it. Have
> > these minor releases been breaking the c-api?
>
> I think b4 included the improved support for migrating from numarray. I'm not
> sure it would have effected an mpl release.
>
> Travis, would you care to comment?
He made a comment on the numpy list. We can shoot for a mpl release
by the end of the week. Are there any lingering issues?
- Charlie

On Tuesday 29 August 2006 14:07, Charlie Moad wrote:
> On 8/29/06, Darren Dale <dd...@co...> wrote:
> > On Monday 14 August 2006 17:48, John Hunter wrote:
> > > >>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
> > >
> > > Charlie> Numpy 1.0b2 was released last night and Travis hopes this
> > > Charlie> will remain binary compatible with numpy 1.0. Are there
> > > Charlie> any objections to a minor release bump? I could do this
> > > Charlie> an soon as tomorrow.
> > >
> > > Let's shoot for Tuesday evening, in advance of scipy. I'm going to
> > > make one more attempt before then to get the damned widget lock
> > > working right....
> >
> > I hate to raise this issue again, but what is the status of the next
> > release?
>
> Seeing numpy b3 and then b4 has made me hesitate. I posted a snapshot
> to the user list a while back just in case anyone wanted it. Have
> these minor releases been breaking the c-api?
I think b4 included the improved support for migrating from numarray. I'm not 
sure it would have effected an mpl release. 
Travis, would you care to comment?

On 8/29/06, Darren Dale <dd...@co...> wrote:
> On Monday 14 August 2006 17:48, John Hunter wrote:
> > >>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
> >
> > Charlie> Numpy 1.0b2 was released last night and Travis hopes this
> > Charlie> will remain binary compatible with numpy 1.0. Are there
> > Charlie> any objections to a minor release bump? I could do this
> > Charlie> an soon as tomorrow.
> >
> > Let's shoot for Tuesday evening, in advance of scipy. I'm going to
> > make one more attempt before then to get the damned widget lock
> > working right....
>
> I hate to raise this issue again, but what is the status of the next release?
Seeing numpy b3 and then b4 has made me hesitate. I posted a snapshot
to the user list a while back just in case anyone wanted it. Have
these minor releases been breaking the c-api?
- Charlie

On Monday 14 August 2006 17:48, John Hunter wrote:
> >>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
>
> Charlie> Numpy 1.0b2 was released last night and Travis hopes this
> Charlie> will remain binary compatible with numpy 1.0. Are there
> Charlie> any objections to a minor release bump? I could do this
> Charlie> an soon as tomorrow.
>
> Let's shoot for Tuesday evening, in advance of scipy. I'm going to
> make one more attempt before then to get the damned widget lock
> working right....
I hate to raise this issue again, but what is the status of the next release?

On Sunday 27 August 2006 22:09, Eric Firing wrote:
> Darren Dale wrote:
> > A while back, I put some effort into rendering an offset ticklabel, which
> > allowed the user to do something like
> >
> > plot(linspace(100000100, 100000200, 100))
> >
> > and the plot would look like a plot from 0 to 100, with a "+100000100"
> > rendered in a new label near the far end of the axis. This doesnt work
> > quite as well as it used to, because the axes autoscaling is setting the
> > plot range to something like the average plus and minus 6%. I have tried
> > tracing the source of this change, but I can't find it. It might be
> > buried in the _transforms extension code, and I've never been able to
> > wrap my head around mpl's transforms.
> >
> > Does anyone know why autoscaling is defaulting to this +-6% range? Does
> > it have to be this way? I'm trying to improve the scalar formatter
> > (supporting engineering notation, cleaning up the code).
>
> Yes. It is not a +-6% range in general, rather it is an adjustment that
> is made if the range is very small. The relevant method in Locator is:
>
> def nonsingular(self, vmin, vmax, expander=0.001, tiny=1e-6):
> if vmax < vmin:
> vmin, vmax = vmax, vmin
> if vmax - vmin <= max(abs(vmin), abs(vmax)) * tiny:
> if vmin==0.0:
> vmin -= 1
> vmax += 1
> else:
> vmin -= expander*abs(vmin)
> vmax += expander*abs(vmax)
> return vmin, vmax
>
> I know I did it this way for a reason, but I don't remember exactly what
> it was--whether it was because of problems with zooming when the zoom
> range gets too small (this was definitely a big problem), or because of
> problems with the rest of the locator code, or because it seemed to me
> to be roughly the desired behavior in most cases. Maybe it was all of
> the above. Certainly, something like this is needed--I think you will
> find that things go bad rapidly if vmin gets too close to vmax. I put
> in the "expander" and "tiny" kwargs in case of future need, but only
> expander is non-default (e.g., 0.05) in other parts of ticker.py, and
> neither kwarg is presently exposed to the user. That could be changed.
I don't understand, I spent a lot of time making the scalarformatter work with 
precisely this scenario (zooming in on extremely small ranges), and it was 
working very well. I don't know of any circumstance where there was a 
problem, maybe you could be more specific about the big problems you 
encountered.
Darren