matplotlib-devel Mailing List for matplotlib

On Thu, 2004年07月22日 at 12:50, John Hunter wrote:
> >>>>> "Todd" == Todd Miller <jm...@st...> writes:
> 
> Todd> Hi John,
> Todd> Just... gasping... my... way... across... the... finish... line... now.
> 
> Todd> Toolbar2 is operational for TkAgg and I really like it.
> 
> Good to hear.
> 
> Open question is how to handle multiple axes. I've considered:
> 
> 1) all or one checkbox
> 
> 2) just reuse old system (menu select) - but how do we deal with
> active in menu vs active via mouse. I find the old way
> a bit cumbersome
> 
> 3) allow user to select multiple axes with the mouse - maybe make
> the selected axes have thicker borders to indicate selection.
> Hold down CTRL to select multiple active axes.
SHIFT? (Don't know if it's even possible, just thought that's what is
usually done for a multiple select.)
> 
> 4) navigation only applies to axes under point (what we have now in
> toolbar2)
> 
> I'm inclined to 1 or 4. Users would have the option of toolbar :
> classic if they really need the multiple axes feature. 1 may be the
> best compromise.
For this afternoon, I'm going for 4. :-) 
> 
> Todd> I changed backend bases a little but don't think it breaks
> Todd> anything. I deleted the "button" parameter from a number of
> Todd> Toolbar2 methods, but since "button" wasn't used and was
> Todd> followed by *args, I don't think it hurts.
> 
> Agreed. Vestigial from gtk.
> 
> Todd> Is now a good time to commit? Do you want to see a tarball
> Todd> first?
> 
> Fire when ready. The world waits with bated breath....
The world can stop waiting... it's here!

>>>>> "Todd" == Todd Miller <jm...@st...> writes:
 Todd> Hi John,
 Todd> Just... gasping... my... way... across... the... finish... line... now.
 Todd> Toolbar2 is operational for TkAgg and I really like it.
Good to hear.
Open question is how to handle multiple axes. I've considered:
 1) all or one checkbox
 2) just reuse old system (menu select) - but how do we deal with
 active in menu vs active via mouse. I find the old way
 a bit cumbersome
 3) allow user to select multiple axes with the mouse - maybe make
 the selected axes have thicker borders to indicate selection.
 Hold down CTRL to select multiple active axes.
 4) navigation only applies to axes under point (what we have now in
 toolbar2)
I'm inclined to 1 or 4. Users would have the option of toolbar :
classic if they really need the multiple axes feature. 1 may be the
best compromise.
 Todd> I changed backend bases a little but don't think it breaks
 Todd> anything. I deleted the "button" parameter from a number of
 Todd> Toolbar2 methods, but since "button" wasn't used and was
 Todd> followed by *args, I don't think it hurts.
Agreed. Vestigial from gtk.
 Todd> Is now a good time to commit? Do you want to see a tarball
 Todd> first?
Fire when ready. The world waits with bated breath....
JDH

>>>>> "Malte" == Malte Marquarding <Mal...@cs...> writes:
 Malte> Hi , I can't build matplotlib-0.60.2 under woody.
 Malte> woody doesn't come with th latest freetype-dev It has
 Malte> version '2.0.9'
 Malte> ps And don't tell me not to use woody - our sys admins like
 Malte> to have a retro feeling.
There's no need to upgrade the operating system, but you will need to
upgrade freetype. I recommend freetype 2.1.9 - 2.1.7 is required by
matplotlib, but 2.1.9 fixes some bugs.
With debian, a simple
 > sudo apt-get install freetype freetype-dev 
should do the trick.
If your sysadmins won't do this for you, you can always compile a
version in your home dir.
Have you tried installing matplotlib via debian:
http://matplotlib.sourceforge.net/installing.html#Debian? There was a
recent thread on matplotlib-users regarding the debian apt install -
http://sourceforge.net/mailarchive/message.php?msg_id=8961454.
JDH

Last night hayden (jo...@on...) sent me a patch in which he
identified and fixed two leaks in _backend_agg.cpp, one in the
write_png method and one elsewhere. Spurred on by his successes, I
tracked down and fixed some additional leaks in the _transforms and
ft2font modules.
Using units/memleak_hawaii3.py in CVS for test script, on typical runs
creating hundreds of random, complex figures, I get anywhere from -5
up to 40 bytes per figure. Since this range is sometimes negative, it
may reflect statistical fluctuation. This number is down from 400
bytes per figure in 0.60.2 (and 24K in 0.54.2) and is getting into the
"manageably small" range. Of course, there is always the possibility
of a leak in an untested area, but I'm encouraged....
Lessons for developers (and me):
 * in pycxx extension code, you almost always want to return
 Py::asObject rather than Py::Object. One exception is returning
 None as Py::Object(). This caused several leaks in the ft2font
 module.
 * Never incref where you meant to decref! This was the cause of the
 leak in the _transforms module, which had escaped my earlier unit
 tests because I wasn't unit testing the leak of binary operations
 of lazy values. In the BinOp class, I was incref-ing in the
 destructor. Very bad...
 * Use freetype 2.1.9 since this fixes some leaks in earlier
 versions.
JDH