matplotlib-devel Mailing List for matplotlib

On Thursday 29 November 2007 03:34:19 pm John Hunter wrote:
> For the 0.91 release, I have updated the web site, which had become
> woefully out of date. In addition to some 91 specific things like
> "what's new", credits and updating a bunch of links to point to
> pyplot, I also cleaned out some dead wood (removed numeric and
> numarray references, cleaned up installing and backends to an extent).
> I think a lot more needs to be done to get the site fully modernized
> (eg installing could use a lot more work, goals needs to be
> modernized), but if you see something egregious or otherwise in need
> of attention, let me know, because on these kinds of things it is good
> to strike when the iron is hot.
>
> Also, it has been a long time since I updated the credits page, so
> this too is very stale. If you are not mentioned there and would like
> to be, or if I have left out some significant contributions that you
> would like to see there, please drop me a blurb and I'll update it.
Not to be a glory hog, but I spent a fair bit of time on backend_ps and 
backend_qt*. It seems like Eric's fingerprints can be found all over 
matplotlib, but I dont have a suggestion for what to add to his nugget.
Darren

On Nov 29, 2007 4:02 PM, Ludwig Schwardt <lud...@gm...> wrote:
> I'm glad you liked my Tk patch! Along the same line, I patched axes3d.py to
> allow the creation of non-interactive 3D plots.
OK, since noone else is maintaining this package right now, what you
say goes :-)
Committed in r4509
JDH

On Nov 29, 2007 2:30 PM, Michael Droettboom <md...@st...> wrote:
> There are some Gtk-specific functions at the bottom of mlab.py. It
> tries to "import gtk" and then will either define them or not.
Ahh, I hadn't considered import time in the try/except block. In
light of this, we probably will want to put them in another module. I
was inclined to something like matplotlib.gui.gtktools, but tere is
an analogous problem with mlab.rec2excel which conditionally imports
pyExcelerator (you probably did not notice it in your timing since it
wasn't installed). Perhaps matplotlib.external or
matplotlib.optional as top-level packages for both (and related).
Something like
matplotlib.optional.exceltools
matplotlib.optional.gtktools
This will serve the dual purpose of cleaning mlab and making Jarrod's
job a bit easier when he decides what to bring over to scipy.
JDH

For the 0.91 release, I have updated the web site, which had become
woefully out of date. In addition to some 91 specific things like
"what's new", credits and updating a bunch of links to point to
pyplot, I also cleaned out some dead wood (removed numeric and
numarray references, cleaned up installing and backends to an extent).
 I think a lot more needs to be done to get the site fully modernized
(eg installing could use a lot more work, goals needs to be
modernized), but if you see something egregious or otherwise in need
of attention, let me know, because on these kinds of things it is good
to strike when the iron is hot.
Also, it has been a long time since I updated the credits page, so
this too is very stale. If you are not mentioned there and would like
to be, or if I have left out some significant contributions that you
would like to see there, please drop me a blurb and I'll update it.
JDH

There are some Gtk-specific functions at the bottom of mlab.py. It 
tries to "import gtk" and then will either define them or not.
On one of my recent profiling fests, I noticed that this "import gtk" 
(if gtk is installed, and running with some non-Gtk backend) accounts 
for between 1-2% of the total running time over all the examples in 
backend_driver.py. Not a huge amount, but it seems like it might be a 
good idea to avoid importing something as large as gtk unless we 
actually need to.
We can either import gtk "on demand", when one of these gtk-related 
functions is called, or perhaps better yet move this to another module, 
that would only be imported when needed. In light of recent 
pylab.py/mlab.py refactorings, are there any opinions on this?
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Nov 29, 2007 2:14 PM, Michael Droettboom <md...@st...> wrote:
> This seems like a good idea to me, and it works for me (I can build mpl
> with the TkAgg extension from a console with X completely shutdown on
> RHEL4...).
I tested in my normal X11 enabled solaris build environment and in a
remote no X linux session and it went through fine. I can test on OX
X tonight.
> John -- does the timing for this work with you release plans?
Yep -- since we probably will be waiting until next week to get 91.1
out, this will give us ample opportunity to hit obvious problems with
this patch.
JDH

Ah! I see you just applied it yourself, John.
Consider the question answered!
(And again, thanks for the patch, Ludwig.)
Cheers,
Mike
Michael Droettboom wrote:
> This seems like a good idea to me, and it works for me (I can build mpl 
> with the TkAgg extension from a console with X completely shutdown on 
> RHEL4...).
> 
> John -- does the timing for this work with you release plans? (It 
> probably needs some testing in a bunch of different environments.) If 
> so, I'm happy to commit this.
> 
> Cheers,
> Mike
> 
> James Amundson wrote:
>> On 2007年11月29日 18:13:39 +0200
>> Ludwig Schwardt <lud...@gm...> wrote:
>>
>>> I've reworked the Tcl/Tk checking code in setupext.py (see attached
>>> patch). It is now possible to build matplotlib with Tk support without
>>> requiring a running X server. This is useful for doing autobuilds
>>> (e.g. as done by Debian) and for building a package on one machine to
>>> be installed and used on another.
>>>
>>> This seems to be an old issue... (see matplotlib-devel, "building
>>> matplotlib without X-server connection," 11 Nov 2004)
>> I would like to register my strong support for this patch. The bug in
>> question also prevents one from doing "python setup.py bdist_rpm" on
>> rpm-based systems. I recently tried to debug this myself and got as far
>> as identifying exactly the problem Ludwig describes, but ran out of
>> time/energy before coming up with the fix. I am very grateful to Ludwig
>> for having fixed the problem. I hope his patch will go in soon.
>>
>> --Jim Amundson
>>
>>
>> -------------------------------------------------------------------------
>> SF.Net email is sponsored by: The Future of Linux Business White Paper
>> from Novell. From the desktop to the data center, Linux is going
>> mainstream. Let it simplify your IT future.
>> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Nov 29, 2007 10:13 AM, Ludwig Schwardt <lud...@gm...> wrote:
> Hi,
>
> Is there any chance that the patch I submitted on 31 October on this
> list could still make it into 0.91.0?
91.0 is already out, but I just committed it so it will make it in for 91.1.
> On an aside, what is the best way to submit patches to mpl? Via the
> bug-tracker, or as attached files or direct in-line in mpl-devel
> mails?
I advise posting here first -- more developers read this list so it is
more likely to get prompt attention. If it doesn't, put it up on the
sf site and send a reminder here with a link to the patch. That way
it will be there when some developer goes to catch up on patches.
Thanks,
JDH\

This seems like a good idea to me, and it works for me (I can build mpl 
with the TkAgg extension from a console with X completely shutdown on 
RHEL4...).
John -- does the timing for this work with you release plans? (It 
probably needs some testing in a bunch of different environments.) If 
so, I'm happy to commit this.
Cheers,
Mike
James Amundson wrote:
> On 2007年11月29日 18:13:39 +0200
> Ludwig Schwardt <lud...@gm...> wrote:
> 
>> I've reworked the Tcl/Tk checking code in setupext.py (see attached
>> patch). It is now possible to build matplotlib with Tk support without
>> requiring a running X server. This is useful for doing autobuilds
>> (e.g. as done by Debian) and for building a package on one machine to
>> be installed and used on another.
>>
>> This seems to be an old issue... (see matplotlib-devel, "building
>> matplotlib without X-server connection," 11 Nov 2004)
> 
> I would like to register my strong support for this patch. The bug in
> question also prevents one from doing "python setup.py bdist_rpm" on
> rpm-based systems. I recently tried to debug this myself and got as far
> as identifying exactly the problem Ludwig describes, but ran out of
> time/energy before coming up with the fix. I am very grateful to Ludwig
> for having fixed the problem. I hope his patch will go in soon.
> 
> --Jim Amundson
> 
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On 2007年11月29日 18:13:39 +0200
Ludwig Schwardt <lud...@gm...> wrote:
> I've reworked the Tcl/Tk checking code in setupext.py (see attached
> patch). It is now possible to build matplotlib with Tk support without
> requiring a running X server. This is useful for doing autobuilds
> (e.g. as done by Debian) and for building a package on one machine to
> be installed and used on another.
> 
> This seems to be an old issue... (see matplotlib-devel, "building
> matplotlib without X-server connection," 11 Nov 2004)
I would like to register my strong support for this patch. The bug in
question also prevents one from doing "python setup.py bdist_rpm" on
rpm-based systems. I recently tried to debug this myself and got as far
as identifying exactly the problem Ludwig describes, but ran out of
time/energy before coming up with the fix. I am very grateful to Ludwig
for having fixed the problem. I hope his patch will go in soon.
--Jim Amundson

matplotlib-0.91.0: Added additional include paths for aix5 to 
setupext.py.
freetype-2.3.5 because the system one was compiled old and compiled 
32-bit; did have to make one patch.
AIX 5.3
I'm not using gcc, because the project I'm trying to help uses an 
xlc-compiled Python. (I did read somewhere that someone was successful
compiling matplotlib using gcc.) 
xlc does not seem to give a version number readily.
Lila
On 2007年11月29日, John Hunter wrote:
> Does anyone have any thoughts on this? Lila, can you provide
> matplotlib, gcc and AIX version/platform info?
> 
> 
> ---------- Forwarded message ----------
> From: ch...@ll... <ch...@ol...>
> Date: Nov 29, 2007 11:49 AM
> Subject: problem compiling matplotlib on AIX
> To: jd...@gm...
> 
> 
> John,
> 
> I thought I'd go back and look at AIX again.
> Any hints on the following errors?
> 
> running build_ext
> building 'matplotlib.ft2font' extension
> xlc -q64 -DNDEBUG -O -I/usr/apps/link/include -I/usr/local/include
> -I/usr/include -I. -I/usr/apps/link/include/freetype2
> -I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2
> -I/usr/gapps/python/aix_5_64_fed/opt-2.5/include/python2.5 -c
> src/ft2font.cpp -o build/temp.aix-5.3-2.5/src/ft2font.o
> "/usr/vacpp/include/xlocinfo.h", line 140.23: 1540-0040 (S) The text
> "_Ptr" is unexpected. "__xlocale_ptr" may be undeclared or ambiguous.
> "/usr/vacpp/include/xlocinfo.h", line 149.23: 1540-0040 (S) The text
> "_Ptr" is unexpected. "__xlocale_ptr" may be undeclared or ambiguous.
> "/usr/vacpp/include/xlocinfo.h", line 161.23: 1540-0040 (S) The text
> "_Ptr" is unexpected. "__xlocale_ptr" may be undeclared or ambiguous.
> "/usr/vacpp/include/xlocale", line 455.22: 1540-0138 (S) The undefined
> template "codecvt" must not be explicitly instantiated.
> "/usr/vacpp/include/xlocale", line 456.22: 1540-0138 (S) The undefined
> template "codecvt" must not be explicitly instantiated.
> "/usr/vacpp/include/xlocale", line 760.21: 1540-0138 (S) The undefined
> template "ctype" must not be explicitly instantiated.
> "/usr/vacpp/include/xlocale", line 768.14: 1540-0120 (S) The out-of-line
> member definition "std::ctype<wchar_t>" of an explicit specialization
> should not use a template prefix.
> "./CXX/Objects.hxx", line 1653.96: 1540-0140 (S) The text "&" is
> unexpected. "SeqBase<T>::iterator" may be undeclared, ambiguous, or may
> require "typename" qualification.
> "./CXX/Objects.hxx", line 1654.96: 1540-0140 (S) The text "&" is
> unexpected. "SeqBase<T>::iterator" may be undeclared, ambiguous, or may
> require "typename" qualification.
> "./CXX/Objects.hxx", line 1655.96: 1540-0140 (S) The text "&" is
> unexpected. "SeqBase<T>::iterator" may be undeclared, ambiguous, or may
> require "typename" qualification.
> "./CXX/Objects.hxx", line 1656.96: 1540-0140 (S) The text "&" is
> unexpected. "SeqBase<T>::iterator" may be undeclared, ambiguous, or may
> require "typename" qualification.
> "./CXX/Objects.hxx", line 1657.96: 1540-0140 (S) The text "&" is
> unexpected. "SeqBase<T>::iterator" may be undeclared, ambiguous, or may
> require "typename" qualification.
> "./CXX/Objects.hxx", line 1658.96: 1540-0140 (S) The text "&" is
> unexpected. "SeqBase<T>::iterator" may be undeclared, ambiguous, or may
> require "typename" qualification.
> "./CXX/Objects.hxx", line 1660.102: 1540-0140 (S) The text "&" is
> unexpected. "SeqBase<T>::const_iterator" may be undeclared, ambiguous, or
> may require "typename" qualification.
> "./CXX/Objects.hxx", line 1661.102: 1540-0140 (S) The text "&" is
> unexpected. "SeqBase<T>::const_iterator" may be undeclared, ambiguous, or
> may require "typename" qualification.
> "./CXX/Objects.hxx", line 1662.102: 1540-0140 (S) The text "&" is
> unexpected. "SeqBase<T>::const_iterator" may be undeclared, ambiguous, or
> may require "typename" qualification.
> "./CXX/Objects.hxx", line 1663.102: 1540-0140 (S) The text "&" is
> unexpected. "SeqBase<T>::const_iterator" may be undeclared, ambiguous, or
> may require "typename" qualification.
> ...
> 
> "./CXX/Objects.hxx", line 2702.102: 1540-0140 (S) The text "&" is
> unexpected. "MapBase<T>::const_iterator" may be undeclared, ambiguous, or
> may require "typename" qualification.
> "src/ft2font.cpp", line 951.27: 1540-0274 (S) The name lookup for "__cos"
> did not find a declaration.
> "src/ft2font.cpp", line 952.27: 1540-0274 (S) The name lookup for "__sin"
> did not find a declaration.
> error: command 'xlc' failed with exit status 1
> 
> 
> Thanks,
> Lila
> 
> --
> Lila Chase
> lc...@ll...
> 925-422-4086
> 
-- 
Lila Chase
lc...@ll...
925-422-4086

Does anyone have any thoughts on this? Lila, can you provide
matplotlib, gcc and AIX version/platform info?
---------- Forwarded message ----------
From: ch...@ll... <ch...@ol...>
Date: Nov 29, 2007 11:49 AM
Subject: problem compiling matplotlib on AIX
To: jd...@gm...
John,
I thought I'd go back and look at AIX again.
Any hints on the following errors?
running build_ext
building 'matplotlib.ft2font' extension
xlc -q64 -DNDEBUG -O -I/usr/apps/link/include -I/usr/local/include
-I/usr/include -I. -I/usr/apps/link/include/freetype2
-I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2
-I/usr/gapps/python/aix_5_64_fed/opt-2.5/include/python2.5 -c
src/ft2font.cpp -o build/temp.aix-5.3-2.5/src/ft2font.o
"/usr/vacpp/include/xlocinfo.h", line 140.23: 1540-0040 (S) The text
"_Ptr" is unexpected. "__xlocale_ptr" may be undeclared or ambiguous.
"/usr/vacpp/include/xlocinfo.h", line 149.23: 1540-0040 (S) The text
"_Ptr" is unexpected. "__xlocale_ptr" may be undeclared or ambiguous.
"/usr/vacpp/include/xlocinfo.h", line 161.23: 1540-0040 (S) The text
"_Ptr" is unexpected. "__xlocale_ptr" may be undeclared or ambiguous.
"/usr/vacpp/include/xlocale", line 455.22: 1540-0138 (S) The undefined
template "codecvt" must not be explicitly instantiated.
"/usr/vacpp/include/xlocale", line 456.22: 1540-0138 (S) The undefined
template "codecvt" must not be explicitly instantiated.
"/usr/vacpp/include/xlocale", line 760.21: 1540-0138 (S) The undefined
template "ctype" must not be explicitly instantiated.
"/usr/vacpp/include/xlocale", line 768.14: 1540-0120 (S) The out-of-line
member definition "std::ctype<wchar_t>" of an explicit specialization
should not use a template prefix.
"./CXX/Objects.hxx", line 1653.96: 1540-0140 (S) The text "&" is
unexpected. "SeqBase<T>::iterator" may be undeclared, ambiguous, or may
require "typename" qualification.
"./CXX/Objects.hxx", line 1654.96: 1540-0140 (S) The text "&" is
unexpected. "SeqBase<T>::iterator" may be undeclared, ambiguous, or may
require "typename" qualification.
"./CXX/Objects.hxx", line 1655.96: 1540-0140 (S) The text "&" is
unexpected. "SeqBase<T>::iterator" may be undeclared, ambiguous, or may
require "typename" qualification.
"./CXX/Objects.hxx", line 1656.96: 1540-0140 (S) The text "&" is
unexpected. "SeqBase<T>::iterator" may be undeclared, ambiguous, or may
require "typename" qualification.
"./CXX/Objects.hxx", line 1657.96: 1540-0140 (S) The text "&" is
unexpected. "SeqBase<T>::iterator" may be undeclared, ambiguous, or may
require "typename" qualification.
"./CXX/Objects.hxx", line 1658.96: 1540-0140 (S) The text "&" is
unexpected. "SeqBase<T>::iterator" may be undeclared, ambiguous, or may
require "typename" qualification.
"./CXX/Objects.hxx", line 1660.102: 1540-0140 (S) The text "&" is
unexpected. "SeqBase<T>::const_iterator" may be undeclared, ambiguous, or
may require "typename" qualification.
"./CXX/Objects.hxx", line 1661.102: 1540-0140 (S) The text "&" is
unexpected. "SeqBase<T>::const_iterator" may be undeclared, ambiguous, or
may require "typename" qualification.
"./CXX/Objects.hxx", line 1662.102: 1540-0140 (S) The text "&" is
unexpected. "SeqBase<T>::const_iterator" may be undeclared, ambiguous, or
may require "typename" qualification.
"./CXX/Objects.hxx", line 1663.102: 1540-0140 (S) The text "&" is
unexpected. "SeqBase<T>::const_iterator" may be undeclared, ambiguous, or
may require "typename" qualification.
...
"./CXX/Objects.hxx", line 2702.102: 1540-0140 (S) The text "&" is
unexpected. "MapBase<T>::const_iterator" may be undeclared, ambiguous, or
may require "typename" qualification.
"src/ft2font.cpp", line 951.27: 1540-0274 (S) The name lookup for "__cos"
did not find a declaration.
"src/ft2font.cpp", line 952.27: 1540-0274 (S) The name lookup for "__sin"
did not find a declaration.
error: command 'xlc' failed with exit status 1
Thanks,
Lila
--
Lila Chase
lc...@ll...
925-422-4086

Hi,
Is there any chance that the patch I submitted on 31 October on this
list could still make it into 0.91.0?
On an aside, what is the best way to submit patches to mpl? Via the
bug-tracker, or as attached files or direct in-line in mpl-devel
mails?
To refresh your memory on the patch:
I've reworked the Tcl/Tk checking code in setupext.py (see attached
patch). It is now possible to build matplotlib with Tk support without
requiring a running X server. This is useful for doing autobuilds
(e.g. as done by Debian) and for building a package on one machine to
be installed and used on another.
This seems to be an old issue... (see matplotlib-devel, "building
matplotlib without X-server connection," 11 Nov 2004)
The patch also fixes a potential hang, which happens when I try to
build the latest matplotlib on Debian Etch with Python 2.4, on a
system with libtk8.4-dev installed but no running X server. The build
should have continued without TkAgg support, but it hangs. The hang
occurs because the Tcl/Tk checking code calls Tkinter.Tk() multiple
times, which is not a good idea. In fact, just running the following
snippet hangs the interpreter in this scenario:
import Tkinter
tk = Tkinter.Tk()
tk = Tkinter.Tk()
The patch applies to setupext.py in revision r4501. I checked it with
matplotlib r4064, using Python 2.4 on Debian Etch, and Python 2.5 on
Mac OS X 10.4.10. It hasn't been checked on Python 2.3 or on
Windows.
Regards,
Ludwig

On Nov 29, 2007 7:34 AM, hjc520070 <jia...@16...> wrote:
>
> I just want to show a matplotlib.image.AxesImage on a figure. But It can't
> work properly. Can somebody help me? The code are following: when I run it
> , It just show a white figure. But I Set it cm.Greens .It doesn't work .
AxesImage is not meant to be instantiated directly, but to be created
via ax.imshow, so I suggest you do that. imshow will return and
AxesImage instance to you. But it looks like your problem is you did
not add the image to the axes via ax.images.append.
For future reference, this type of question is probably best directed
to matplotlib-users, since the devel list is for matplotlib
development rather than usage.
Thanks,
JDH

I just want to show a matplotlib.image.AxesImage on a figure. But It can't
work properly. Can somebody help me? The code are following: when I run it
, It just show a white figure. But I Set it cm.Greens .It doesn't work .
Why?
# -*- coding:gb2312 -*- 
import matplotlib
matplotlib.use("WXAgg")
matplotlib.interactive(True)
from matplotlib.backends.backend_wx import FigureCanvasWx
from matplotlib.figure import Figure
from matplotlib.axes import Subplot
from numpy import *
import wx
class ShowPlot():
 def __init__(self,Frame):
 delta = 0.025
 x = arange(-2.0, 2.0, delta)
 y = arange(-2.0, 2.0, delta)
 X, Y = meshgrid(x, y)
 Z1 = bivariate_normal(X, Y, 1.0, 1.0, 0.0, 0.0)
 Z2 = bivariate_normal(X, Y, 1.5, 0.5, 1, 1)
 Z = 10.0 * (Z2 - Z1) 
 levels = arange(-1.2, 1.6, 0.2) 
 self.fig = Figure((6,6), 70)
 self.canvas = FigureCanvasWx(Frame, -1, self.fig)
 self.axe=self.fig.add_axes([0.1, 0.1, 0.8, 0.8])
 
i=matplotlib.image.AxesImage(self.axe,data=Z,interpolation='bilinear',
origin='lower',cmap=cm.Greens, extent=(-2,2,-2,2))
app = wx.PySimpleApp()
f=wx.Frame(None,size=(600,600))
f.Show(True)
ShowPlot(f)
app.MainLoop()
-- 
View this message in context: http://www.nabble.com/matplotlib.image.AxesImage-can%27t-work.-tf4897267.html#a14025951
Sent from the matplotlib - devel mailing list archive at Nabble.com.

On Nov 28, 2007 9:21 PM, John Hunter <jd...@gm...> wrote:
> On Nov 28, 2007 7:55 PM, Charles Moad <cw...@gm...> wrote:
> > So should I bother with binary releases for 0.91.0? I assume you
> > meant 0.91.1 below as well.
>
> Yes, I meant 91.1 and yes, we should go ahead with the binary
> releases. The only way we can find any bugs in the current release,
> including any problems we may see with the binaries, is to put out
> 91.0 in full bloom.
Alternatively, if it is not much more work since you haven't built the
binaries to get the latest snapshot with Michael's fix and just
release it as 91.1 now, that would be great too. I just think we need
to get a full release out so people can and will test on a variety of
systems before we can assume that the important bugs are out.
JDH

On Nov 28, 2007 7:55 PM, Charles Moad <cw...@gm...> wrote:
> So should I bother with binary releases for 0.91.0? I assume you
> meant 0.91.1 below as well.
Yes, I meant 91.1 and yes, we should go ahead with the binary
releases. The only way we can find any bugs in the current release,
including any problems we may see with the binaries, is to put out
91.0 in full bloom. Since it has been a long time since we did a
release, and a lot of work has gone in in the interim, we can
anticipate some bugs in the first week and hopefully we can sort them
out pretty quickly and pt out a stable bugfix release next week. Now
if only your baby will let you get some real work done :-)
JDH

So should I bother with binary releases for 0.91.0? I assume you 
meant 0.91.1 below as well.
- Charlie
On Nov 28, 2007, at 3:34 PM, John Hunter wrote:
> On Nov 28, 2007 2:21 PM, Michael Droettboom <md...@st...> wrote:
>> I suppose this was bound to happen...
>>
>> The released version has a bug that prevents using the (serif) STIX
>> fonts. Entirely my fault for not checking all font possibilities 
>> after
>> a recent change.
>>
>> r4492 fixes this bug.
>>
>> Let me know how you want to proceed... I'm happy to help cutting
>> another release if we decide to do that.
>
> I think we should wait until we've had a chance to collect a few bugs
> first... We'll announce on mpl-users, and after a few days to give
> bugs a chance to filter in, we'll cut 90.1, and then announce to a
> wider audience, eg python-list.
>
> JDH
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel