matplotlib-users Mailing List for matplotlib (Page 8)

>>>>> "Humufr" == Humufr <hu...@ya...> writes:
 Humufr> Hi, when I wrote a script like:
 Humufr> import numarray image = numarray.ones((30,30))
 Humufr> from pylab import * matshow(image) show()
 Humufr> I obtain an error message:
 Humufr> Traceback (most recent call last): File "test.py", line 6,
 Humufr> in ? matshow(image) File
 Humufr> "/usr/lib/python2.4/site-packages/matplotlib/pylab.py",
 Humufr> line 1647, in matshow w,h = figaspect(arr) File
 Humufr> "/usr/lib/python2.4/site-packages/matplotlib/figure.py",
 Humufr> line 480, in figaspect nr,nc = arr.shape[:2]
 Humufr> AttributeError: 'module' object has no attribute 'shape'
 Humufr> if I'm call pylab before to create the numarray array it's
 Humufr> ok:
It looks like your numerix setting is your .matplotlibrc file may be
Numeric, and you are trying to pass a Numeric array. Make sure that
the rc setting agrees with the actual array type used. To insure
this, we recommend that you use matplotlib.numerix to import the array
object and methods, rather than explicitly importing numarray
directly. matplotlib numerix, and by extension the pylab module,
already provide the proper array packages based on your rc setting.
Please see several FAQs on this issue regarding rc and numerix.
JDH

>>>>> "matthew" == matthew arnison <ma...@ca...> writes:
 matthew> To make a long story short, _winreg is failing to deal
 matthew> with some Japanese font registry keys, and throwing the
 matthew> WindowsError (ErrNo 234). A good workaround is to add a
 matthew> "try / except WindowsError: pass" around the
 matthew> _winreg.EnumValue() stanza inside the for loop. From my
 matthew> testing, for a system with 93 fonts, this should skip the
 matthew> 3 troublesome fonts and catalog the rest.
 matthew> My apologies that I cannot provide a patch or a simple
 matthew> test case at this time, but I hope this report is useful.
Hi Matthew -- thanks for your efforts on this. I have to honestly say
that I don't have a lot of time to work on this bug -- I don't know
enough about Japanese fonts or the windows registry. None of the
other matplotlib developers seem to have taken up the banner either.
If you can provide a patch that fixes or works around the bug, I'd be
very happy to include it. I could work figure out the appropriate
patch by reading your email closely, but I don't have a good
environment to test it, so it would be more efficient if you simply
submitted a patch that has your try/except workaround until we can
come up with something better.
Thanks!
JDH

Hi,
A few months back I gave a little report to matplotlib-users on using 
matplotlib on Japanese Windows. There were several issues that I managed 
to find workarounds for.
I wanted to give an update on the font_manager.py bug. This bug is still 
in matplotlib (as of CVS earlier today) and causes a matplotlib import 
to throw a WindowsError exception (ErrNo 234). This has happened to me 
on every Windows 2000 Japanese PC I've tried it on, including PCs which 
had a pretty fresh installs of Win2K. (It may also happen on Japanese 
WinXP, I haven't tried it.)
In other words, it's a showstopper. And it happens even without py2exe.
A bit of google searching turned up a couple of *.jp blogs mentioning 
the error.
The workaround I suggested last Novemeber works (see my message quoted 
below), but it's a bit of a kludge. I dug a bit into the bug today and 
discovered it's actually a side-effect of what appears to be a Microsoft 
Win32 API registry bug.
_winreg uses RegQueryInfoKey to ask for the maximum length of all the 
subkeys in the fonts registry key. Then _winreg creates a buffer of that 
length (plus 1 for NULL termination) and uses RegEnumValue to grab the 
subkey, but for some fonts Windows returns ERROR_MORE_DATA (234) 
indicating that the buffer size is too small. There are at least 3 fonts 
that trigger it, which seem to be standard on Japanese Win2k.
To make a long story short, _winreg is failing to deal with some 
Japanese font registry keys, and throwing the WindowsError (ErrNo 234). 
A good workaround is to add a "try / except WindowsError: pass" around 
the _winreg.EnumValue() stanza inside the for loop. From my testing, for 
a system with 93 fonts, this should skip the 3 troublesome fonts and 
catalog the rest.
My apologies that I cannot provide a patch or a simple test case at this 
time, but I hope this report is useful.
Cheers,
Matthew.
p.s. It may be there are ways to work around this bug in _winreg, which 
I think would be the better place to do it. E.g. by using RegEnumValue 
to query the subkey size instead of RegQueryInfoKey. But I haven't 
isolated a simple test case yet, apart from "import matplotlib" on 
Japanese Win2k.
Here is the code fragment:
MSFontDirectories = [
 r'SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts',
 r'SOFTWARE\Microsoft\Windows\CurrentVersion\Fonts']
...
def win32InstalledFonts(directory=None, fontext='ttf'):
 """Search for fonts in the specified font directory, or use the
system directories if none given. A list of TrueType fonts are
returned by default with AFM fonts as an option.
"""
 import _winreg
 if directory is None:
 directory = win32FontDirectory()
 key, items = None, {}
 for fontdir in MSFontDirectories:
 try:
 local = _winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, fontdir)
 except OSError:
 continue
 if not local:
 return glob.glob(os.path.join(directory, '*.'+fontext))
 try:
 for j in range(_winreg.QueryInfoKey(local)[1]):
 key, direc, any = _winreg.EnumValue( local, j)
 if not os.path.dirname(direc):
 direc = os.path.join(directory, direc)
 direc = os.path.abspath(direc).lower()
 if direc[-4:] == '.'+fontext:
 items[direc] = 1
 return items.keys()
 finally:
 _winreg.CloseKey(local)
 return None
On 1/11/2004 3:32 PM, matthew arnison wrote:
> I thought I'd mention some small isuues I found with using py2exe to deploy matplotlib 0.63.2 on Japanese Windows 2000.
> 
 > [...snip...]
 >
> * font_manager.py throws an exception, I suspect to do with Japanese font names or font directory names:
> 
> File "c:\Python23\lib\site-packages\matplotlib\font_manager.py", line 111, in
> win32InstalledFonts
> key, direc, any = _winreg.EnumValue( local, j)
> WindowsError: [Errno 234]
> 
> from this site:
> 
> http://www.google.com.au/search?q=cache:B8BlgKwVYxcJ:www.cubelab.com/ymasuda/python/index_jp.html+matplotlib+local+None+windowserror&hl=en
> 
> I found a workaround to add
> 
> local = None
> 
> at line 107 of font_manager.py to give this:
> 
> for fontdir in MSFontDirectories:
> try:
> local = _winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, fontdir)
> except OSError:
> continue
> 
> local = None
> 
> if not local:
> return glob.glob(os.path.join(directory, '*.'+fontext))

Hi, I'm very new to matplotlib and python. I'm using TkAgg and IDLE -n, and 
trying to make a dynamic display for data acquisition. However, when I try 
to use the toolbar or move the plot window while "running" everything 
freezes. Any fixes?
Thanks,
C.D.

Dear John,
You win: I thought I had done a clean install, but apparently I didn't. 
After a
rm -rf of site-packages/matplotlib, and a re-install everything worked fine.
So: no bug.
Thanks,
Arnold
Quoting John Hunter <jdh...@ac...>:
>>>>>> "Arnold" == Arnold Moene <arn...@wu...> writes:
>
> Arnold> Dear all, The following simple script gives an error on
> Arnold> matplotlib-0.72.1: # Start script from pylab import * from
> Arnold> Numeric import *
>
> Arnold> x=arange(0.1,10,0.1) y=sin(x)
>
> Arnold> grid() plot(x,y) savefig('foo.eps') # end script
>
> Arnold> The error disappears when I remove the grid() switch.
>
> I cannot replicate this bug with 0.72.1 or matplotlib CVS. Could you
> rm -rf site-packages/matplotlib, reinstall, and run your script with
> --verbose-helpful? If you still get the error, send the output of the
> run so I can use the extra diagnostic information.
>
> Thanks,
> JDH
>
-- 
------------------------------------------------------------------------
Arnold F. Moene NEW tel: +31 (0)317 482604
Meteorology and Air Quality Group fax: +31 (0)317 482811
Wageningen University e-mail: Arn...@wu...
Duivendaal 2 url: http://www.met.wau.nl
6701 AP Wageningen
The Netherlands
------------------------------------------------------------------------
Openoffice.org - Freedom at work
Firefox - The browser you can trust (www.mozilla.org)
------------------------------------------------------------------------

1) Running the dash_control.py example I get the
following error message (the problem is present on
both linux and windows installations):
Traceback (most recent call last):
 File "/usr/lib/python2.3/lib-tk/Tkinter.py", line
1345, in __call__
 return self.func(*args)
 File
"/home/camp/s991416/lib/python/matplotlib/backends/backend_tkagg.py",
line 140, in resize
 self.show()
 File
"/home/camp/s991416/lib/python/matplotlib/backends/backend_tkagg.py",
line 143, in draw
 FigureCanvasAgg.draw(self)
 File
"/home/camp/s991416/lib/python/matplotlib/backends/backend_agg.py",
line319, in draw
 self.figure.draw(self.renderer)
 File
"/home/camp/s991416/lib/python/matplotlib/figure.py",
line 338, in draw
 for a in self.axes: a.draw(renderer)
 File
"/home/camp/s991416/lib/python/matplotlib/axes.py",
line 1296, in draw
 a.draw(renderer)
 File
"/home/camp/s991416/lib/python/matplotlib/lines.py",
line 283, in draw
 lineFunc(renderer, gc, xt, yt)
 File
"/home/camp/s991416/lib/python/matplotlib/lines.py",
line 543, in _draw_dashed
 renderer.draw_lines(gc, xt, yt, self._transform)
TypeError: CXX: type error.
2) And when using savefig I get :
Traceback (most recent call last):
 File "dash_control.py", line 13, in ?
 savefig('dash_control')
 File
"/home/camp/s991416/lib/python/matplotlib/pylab.py",
line 763, in savefig
 try: ret = fig.savefig(*args, **kwargs)
 File
"/home/camp/s991416/lib/python/matplotlib/figure.py",
line 455, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File
"/home/camp/s991416/lib/python/matplotlib/backends/backend_tkagg.py",
line 161, in print_figure
 agg.print_figure(filename, dpi, facecolor,
edgecolor, orientation)
 File
"/home/camp/s991416/lib/python/matplotlib/backends/backend_agg.py",
line370, in print_figure
 self.draw()
 File
"/home/camp/s991416/lib/python/matplotlib/backends/backend_agg.py",
line319, in draw
 self.figure.draw(self.renderer)
 File
"/home/camp/s991416/lib/python/matplotlib/figure.py",
line 338, in draw
 for a in self.axes: a.draw(renderer)
 File
"/home/camp/s991416/lib/python/matplotlib/axes.py",
line 1296, in draw
 a.draw(renderer)
 File
"/home/camp/s991416/lib/python/matplotlib/lines.py",
line 283, in draw
 lineFunc(renderer, gc, xt, yt)
 File
"/home/camp/s991416/lib/python/matplotlib/lines.py",
line 543, in _draw_dashed
 renderer.draw_lines(gc, xt, yt, self._transform)
	
		
__________________________________ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/

>>>>> "Arnold" == Arnold Moene <arn...@wu...> writes:
 Arnold> Dear all, The following simple script gives an error on
 Arnold> matplotlib-0.72.1: # Start script from pylab import * from
 Arnold> Numeric import *
 Arnold> x=arange(0.1,10,0.1) y=sin(x)
 Arnold> grid() plot(x,y) savefig('foo.eps') # end script
 Arnold> The error disappears when I remove the grid() switch.
I cannot replicate this bug with 0.72.1 or matplotlib CVS. Could you
rm -rf site-packages/matplotlib, reinstall, and run your script with
--verbose-helpful? If you still get the error, send the output of the
run so I can use the extra diagnostic information.
Thanks,
JDH

Stephen Walton wrote:
> Hi, All,
> 
> A week or so ago, I posted to matplotlib-users about a problem with 
> bdist_rpm. I'd asked about python 2.3 on Fedora Core 1.
> 
> It turns out there are two problems. One is that even if one has 
> python2.3 and python2.2 installed, bdist_rpm always calls the 
> interpreter named 'python', which is 2.2 on FC1. The other problem is 
You need to 'fix' the python version to be called inside the actual rpm build. 
 From the ipython release script:
# A 2.4-specific RPM, where we must use the --fix-python option to ensure that
# the resulting RPM is really built with 2.4 (so things go to
# lib/python2.4/...)
python2.4 ./setup.py bdist_rpm --release=py24 --fix-python
> that in bdist_rpm.py there is a set of lines near line 307 which tests 
> if the number of generated RPM files is 1. This fails because all of 
> matplotlib, numeric, numarray and scipy generate a debuginfo RPM when 
> one does 'python setup.py bdist_rpm'. (Why the RPM count doesn't fail 
> with Python 2.3 on FC3 is beyond me, but nevermind.) The patch is at
This problem has been fixed in recent 2.3 and 2.4. 2.2 still has it.
Best,
f

On Thu, 3 Mar 2005, Stephen Walton wrote:
> Hi, All,
>
> A week or so ago, I posted to matplotlib-users about a problem with 
> bdist_rpm. I'd asked about python 2.3 on Fedora Core 1.
>
> It turns out there are two problems. One is that even if one has python2.3 
> and python2.2 installed, bdist_rpm always calls the interpreter named 
> 'python', which is 2.2 on FC1.
Using `bdist_rpm --fix-python` should take care of this issue.
Pearu

Stephen Walton wrote:
> [bdist_rpm] still fails with Numeric 23.6 however for reasons I'm 
> still checking into;
Posted too soon; this problem is fixed at Numeric 23.7.

Hi, All,
A week or so ago, I posted to matplotlib-users about a problem with 
bdist_rpm. I'd asked about python 2.3 on Fedora Core 1.
It turns out there are two problems. One is that even if one has 
python2.3 and python2.2 installed, bdist_rpm always calls the 
interpreter named 'python', which is 2.2 on FC1. The other problem is 
that in bdist_rpm.py there is a set of lines near line 307 which tests 
if the number of generated RPM files is 1. This fails because all of 
matplotlib, numeric, numarray and scipy generate a debuginfo RPM when 
one does 'python setup.py bdist_rpm'. (Why the RPM count doesn't fail 
with Python 2.3 on FC3 is beyond me, but nevermind.) The patch is at
http://opensvn.csie.org/pyvault/rpms/trunk/python23/python-2.3.4-distutils-bdist-rpm.patch
and I have verified that after applying this patch to 
/usr/lib/python2.2/distutils/command/bdist_rpm.py on FC1 that 'python 
setup.py bdist_rpm' works for numarray 1.2.2, scipy current CVS, and 
matplotlib 0.72 (after changing setup.py for python2.2 as documented in 
the latter). It still fails with Numeric 23.6 however for reasons I'm 
still checking into; the failed "setup.py bdist_rpm" claims that 
arraytypes.c doesn't exist.
Steve Walton

I don't know if it could help, but with matplotlib 0.71, the version 
I've installed, the error doesn't occur.
HTH,
 Andrea.
On 3 Mar 2005, at 16:14, Arnold Moene wrote:
> Dear all,
>
> The following simple script gives an error on matplotlib-0.72.1:
> # Start script
> from pylab import *
> from Numeric import *
>
> x=arange(0.1,10,0.1)
> y=sin(x)
>
> grid()
> plot(x,y)
> savefig('foo.eps')
> # end script

Dear all,
The following simple script gives an error on matplotlib-0.72.1:
# Start script
from pylab import *
from Numeric import *
x=arange(0.1,10,0.1)
y=sin(x)
grid()
plot(x,y)
savefig('foo.eps')
# end script
The error disappears when I remove the grid() switch.
The error message is:
 File "foo.py", line 10, in ?
 savefig('foo.eps')
 File "/usr/lib/python2.3/site-packages/matplotlib/pylab.py", line 763,
in savefig
 try: ret = fig.savefig(*args, **kwargs)
 File "/usr/lib/python2.3/site-packages/matplotlib/figure.py", line
455, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py",
line 646, in print_figure
 self.figure.draw(renderer)
 File "/usr/lib/python2.3/site-packages/matplotlib/figure.py", line
338, in draw
 for a in self.axes: a.draw(renderer)
 File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 1281,
in draw
 self.xaxis.draw(renderer)
 File "/usr/lib/python2.3/site-packages/matplotlib/axis.py", line 523,
in draw
 tick.draw(renderer)
 File "/usr/lib/python2.3/site-packages/matplotlib/axis.py", line 135,
in draw
 if midPoint and self.gridOn: self.gridline.draw(renderer)
 File "/usr/lib/python2.3/site-packages/matplotlib/lines.py", line 283,
in draw
 lineFunc(renderer, gc, xt, yt)
 File "/usr/lib/python2.3/site-packages/matplotlib/lines.py", line 569,
in _draw_dotted
 renderer.draw_lines(gc, xt, yt)
 File
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py",
line 355, in draw_lines
 self._draw_lines(gc,to_draw)
 File
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py",
line 338, in _draw_lines
 self._draw_ps("\n".join(ps), gc, None)
 File
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py",
line 453, in _draw_ps
 self.set_linewidth(gc.get_linewidth())
 File
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py",
line 114, in set_linewidth
 self._pswriter.write("%1.3f setlinewidth\n"%linewidth)
TypeError: float argument required
The error disappears (or at least is no longer visible) when I replace 
line 113 in backend_ps.py by:
self._pswriter.write("%1.3f setlinewidth\n"%float(linewidth))
I hope someone can make a thorough fix. At the moment I can live with my 
workaround.
Cheers, Arnold
-- 
------------------------------------------------------------------------
Arnold F. Moene NEW tel: +31 (0)317 482604
Meteorology and Air Quality Group fax: +31 (0)317 482811
Wageningen University e-mail: Arnold.Moene at wur.nl
Duivendaal 2 url: http://www.met.wau.nl
6701 AP Wageningen
The Netherlands
------------------------------------------------------------------------
Openoffice.org - Freedom at work
Firefox - The browser you can trust (www.mozilla.org)
------------------------------------------------------------------------

Hi,
when I wrote a script like:
import numarray
image = numarray.ones((30,30))
from pylab import *
matshow(image)
show()
I obtain an error message:
Traceback (most recent call last):
 File "test.py", line 6, in ?
 matshow(image)
 File "/usr/lib/python2.4/site-packages/matplotlib/pylab.py", line 
1647, in matshow
 w,h = figaspect(arr)
 File "/usr/lib/python2.4/site-packages/matplotlib/figure.py", line 
480, in figaspect
 nr,nc = arr.shape[:2]
AttributeError: 'module' object has no attribute 'shape'
if I'm call pylab before to create the numarray array it's ok:
from pylab import *
import numarray
image = numarray.ones((30,30))
matshow(image)
show()
just to let you know.
N.

Dear all,
Perhaps this idea appears strange to some, but in my field (atmospheric
turbulence) it is a common problem: I want to plot data with a log-axis (say
the x-axis) with both positive and negative numbers for x. This implies that I
want to zoom in on small values of |x|. The way to do this, is to define a
'gap' around zero in which no data exist, or are ignored. So if my x-data would
range
from -10 to -0.01 and from 0.01 to 10, the x-axis would look like:
|-------|-------|-------|-------|-------|------|
-10 -1 -0.1 +/-0.01 0.1 1 10
There are few (if any) plotting programs that can do this, but it would make
life a lot easier for me. By now I have hacked my own pylab script to do this,
but it has many limitations. To do it properly, it should be done on a somewhat
lower level in the code, I suppose. The idea is to split the data into either 2
(semilogx and semilogy) or 4 quadrants (loglog) and to plot the data in each
quadrant seperately. If the lower limit of the x-axis (or y-axis) is taken
positive, a normal semilogx (or semilogy) plot is recovered.
More people that need/like this? Any volunteers who know what they are doing (in
terms of low-level pylab coding)?
Regards,
Arnold
-- 
------------------------------------------------------------------------
Arnold F. Moene NEW tel: +31 (0)317 482604
Meteorology and Air Quality Group fax: +31 (0)317 482811
Wageningen University e-mail: Arnold.Moene at wur.nl
Duivendaal 2 url: http://www.met.wau.nl
6701 AP Wageningen
The Netherlands
------------------------------------------------------------------------
Openoffice.org - Freedom at work
Firefox - The browser you can trust (www.mozilla.org)
------------------------------------------------------------------------

>>>>> "David" == David Fugate <df...@uc...> writes:
 John> add_base_flags(module) before the call to
 John> ext_modules.append(module) in both the Numeric and numarray
 John> sections. Ditto for the build_contour function in
 John> setupext.py. 
 David> BTW A new identical problem appeared which was easily fixed
 David> by doing the same thing to the build_contour function.
Which is why I said "Ditto for the build_contour function in
setupext.py" <wink>
Glad it helped -- thanks for the report and persevering!
JDH

John Hunter wrote:
> No, it looks like we are doing something wrong. I can't believe it
> has not been reported in the umpteen mpl releases that have had this
> problem....
> 
> build_transforms needs to call
> 
> add_base_flags(module)
> 
> before the call to 
> 
> ext_modules.append(module)
> 
> in both the Numeric and numarray sections. Ditto for the
> build_contour function in setupext.py.
> 
> Hope this helps! Let me know...
> 
> JDH
Yes, this fixed it! Thank you.
David
BTW
A new identical problem appeared which was easily fixed by doing the 
same thing to the build_contour function.
-- 
There are 10 types of people in the world. Those that understand binary 
and those that don't.

>>>>> "kristen" == kristen kaasbjerg <co...@ya...> writes:
 kristen> Hi again Working with legend I've encountered another
 kristen> problem. Changing the fontsize in a legend seems to be a
 kristen> little harder than first assumed. Is there an easy way to
 kristen> do this??
http://matplotlib.sf.net/examples/legend_demo.py shows you how to
customize the legend text font size. The examples directory is really
an indispensable tool in learning matplotlib. If you are using the
source distribution, the examples directory is included. If you are
using a binary distribution, a zip file is found here
http://matplotlib.sourceforge.net/matplotlib_examples_0.72.zip
The relevant code fragment from legend_demo.py is
 ltext = leg.get_texts() # all the text.Text instance in the legend
 set(ltext, fontsize='small') # the legend text fontsize
JDH

kristen kaasbjerg wrote:
> Hi again
> Working with legend I've encountered another problem.
> Changing the fontsize in a legend seems to be a little
> harder than first assumed. Is there an easy way to do
> this??
 From the mailing list a couple of days ago...
You need to pass in a FontProperties instance that specifies the size you want:
prop = FontProperties(size="x-small')
size - Either an absolute value of xx-small, x-small, small,
 medium, large, x-large, xx-large; or a relative value
 of smaller or larger; or an absolute font size, e.g. 12;
 or scalable
i.e. lgnd = ax.legend((lines, labels, prop = FontProperties(size="x-small'), 
..other_params_as_required)
Robert
PS This looks like something to add to my 'Getting Started' document....

Hi again
Working with legend I've encountered another problem.
Changing the fontsize in a legend seems to be a little
harder than first assumed. Is there an easy way to do
this??
Kristen
	
		
__________________________________ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/

>>>>> "David" == David Fugate <df...@uc...> writes:
 David> Just looking at the output it appears as if the changes
 David> made to basedir (i.e., 'linux2') in setupext.py are not
 David> having any sort of effect (hence the error message about
 David> numarray/arrayobject.h not existing). Is there something
 David> blatantly wrong I'm doing? Any help would be greatly
 David> appreciated.
No, it looks like we are doing something wrong. I can't believe it
has not been reported in the umpteen mpl releases that have had this
problem....
build_transforms needs to call
 add_base_flags(module)
before the call to 
 ext_modules.append(module)
in both the Numeric and numarray sections. Ditto for the
build_contour function in setupext.py.
Hope this helps! Let me know...
JDH

Hi, I'm new to using matplotlib and am having some problems installing 
the software package. Basically my setup is:
* Redhat 9.0
* gcc 3.3
* Python 2.4 (installed in a non-standard location)
* freetype 2.1.9 and numarray 1.2.2 also installed in a non-standard 
location.
Following the instructions on the matplotlib homepage, I:
1. Substitute:
	'linux2' : [
with:
	'linux2' : [os.environ['ACSROOT'], os.environ['PYTHON_ROOT']
within matplotlib-0.72.1/setupext.py. The ACSROOT environment variable 
is where numarray is installed and the numarray headers can be found in 
$ACSROOT/include/numarray/.
2. Set BUILD_AGG=1
3. Run the command 'python setup.py build' which gives output that looks 
correct until gcc is executed:
	running build_ext
	building 'matplotlib._na_transforms' extension
	creating build/temp.linux-i686-2.4
	creating build/temp.linux-i686-2.4/src
	creating build/temp.linux-i686-2.4/CXX
	gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes 
-pipe -D_POSIX_THREADS -D_POSIX_THREAD_SAFE_FUNCTIONS -D_REENTRANT 
-DACE_HAS_AIO_CALLS -fcheck-new -Wall -fPIC -g -DDEBUG -O -DCCS_LIGHT 
-fPIC -Isrc -I. -I/alma/ACS-4.0/Python/include/python2.4 -c 
src/_na_transforms.cpp -o build/temp.linux-i686-2.4/src/_na_transforms.o 
-DNUMARRAY=1
	In file included from /alma/ACS-4.0/Python/include/python2.4/Python.h:8,
	 from CXX/Objects.hxx:9,
	 from CXX/Extensions.hxx:18,
	 from src/_transforms.h:12,
	 from src/_na_transforms.cpp:2:
	/alma/ACS-4.0/Python/include/python2.4/pyconfig.h:835:1: warning: 
"_POSIX_C_SOURCE" redefined
	In file included from 
/alma/ACS-4.0/gnu/include/c++/3.3/i386-redhat-linux/bits/os_defines.h:39,
	 from 
/alma/ACS-4.0/gnu/include/c++/3.3/i386-redhat-linux/bits/c++config.h:35,
	 from /alma/ACS-4.0/gnu/include/c++/3.3/functional:53,
	 from src/_na_transforms.cpp:1:
	/usr/include/features.h:131:1: warning: this is the location of the 
previous definition
	src/_na_transforms.cpp:6:35: numarray/arrayobject.h: No such file or 
directory
	...
Just looking at the output it appears as if the changes made to basedir 
(i.e., 'linux2') in setupext.py are not having any sort of effect (hence 
the error message about numarray/arrayobject.h not existing). Is there 
something blatantly wrong I'm doing? Any help would be greatly appreciated.
Thanks in advance,
David Fugate

John Hunter wrote:
>>>>>>"Robert" == Robert Leftwich <ro...@le...> writes:
> 
> 
> Robert> The good news is that it is a huge improvement, but the
> Robert> bad news is that I'm still getting a GPF, just a lot less
> Robert> often :-( Try bumping the minimal test loop up to 5k, it
> Robert> failed at 3057 for me.
> 
> Bet you had to wait a while for that one. 
Not on the new laptop!
 > Maybe you should use
> the full test script. At lease you'll fail faster :-)
Yep, using the real data, it fails pretty quickly.
> 
> 
> What happens if you comment out this line in text.py
> 
> self.cached[key] = ret
> 
> and this line in backend_agg.py
> 
> _fontd[key] = font
It's worse, the minimal test fails at 4!, but the real data takes 180 or so.
> 
> We have a linux/unix specific script for testing for memory leaks in
> the mpl src distro unit/memleak_hawaii3.py. You may want to adapt
> something like this for windows xp so we can get firm numbers on how
> much is leaking per figure. 
I'll attempt this when time permits, possibly late today, but sometime later 
this week is more likely.
Robert

>>>>> "Robert" == Robert Leftwich <ro...@le...> writes:
 Robert> John Hunter wrote:
 >> gc.collect() Should cure what ails you!
 >> 
 Robert> The good news is that it is a huge improvement, but the
 Robert> bad news is that I'm still getting a GPF, just a lot less
 Robert> often :-( Try bumping the minimal test loop up to 5k, it
 Robert> failed at 3057 for me.
Bet you had to wait a while for that one. Maybe you should use
the full test script. At lease you'll fail faster :-)
matplotlib does some caching in various places for efficiency which
will slowly eat memory. We need to add some automated means to clear
this cache but we don't have it yet.
What happens if you comment out this line in text.py
 self.cached[key] = ret
and this line in backend_agg.py
 _fontd[key] = font
We have a linux/unix specific script for testing for memory leaks in
the mpl src distro unit/memleak_hawaii3.py. You may want to adapt
something like this for windows xp so we can get firm numbers on how
much is leaking per figure. See also
http://matplotlib.sourceforge.net/faq.html#LEAKS. Todd Miller knows a
clever way of getting python to report how may object references it
has a hold of, but I can't remember the magic command right now.
With matplotlib CVS on linux, that script is reporting no detectable
leak. But your script may be exposing a leak not covered by that
one.
JDH

John Hunter wrote:
> 
> gc.collect()
> 
> Should cure what ails you!
> 
The good news is that it is a huge improvement, but the bad news is that I'm 
still getting a GPF, just a lot less often :-( Try bumping the minimal test loop 
up to 5k, it failed at 3057 for me.
Robert