matplotlib-devel Mailing List for matplotlib (Page 2)

Nice to hear you found a solution. Still, it would nice if the obvious 
way to do it didn't leak memory ;) I thought the memory leak hunting I 
did a few months ago had resolved this, but it wasn't testing exactly 
the same thing -- it was creating figures directly in each iteration, 
not just calling plot. I'll look into this further.
Cheers,
Mike
Darren Dale wrote:
> On Friday 19 October 2007 05:23:38 pm Darren Dale wrote:
>> I'm having some trouble updating a plot window without calling plot. I
>> would like to do something like:
>>
>> ax = axes()
>> lines, = plot([1,2,3], [1,2,3])
>> lines.set_ydata([4,5,6])
>> ax.autoscale_view()
>> ax.draw()
>>
>> The line does get updated, but the axes limits are not updated. I've looked
>> into the Axes.plot code, and as far as I can tell, the above code should
>> work. Can anyone tell me what is the right way to do this?
> 
> I guess I should point out why I can't call plot. I'm rapidly losing physical 
> memory, even when I call ax.hold(False):
> 
> ax = axes() # ipython using 51 MB
> ax.plot(arange(1000000)) # ipython using 81 MB
> ax.hold(False)
> ax.plot(arange(1000000)) # ipython using 138 MB
> ax.plot(arange(1000000)) # ipython using 142 MB
> ax.hold(True)
> ax.plot(arange(1000000)) # ipython using 172 MB
> ax.plot(arange(1000000)) # ipython using 203 MB
> 
> Darren
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> 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 Saturday 20 October 2007 12:42:46 pm John Hunter wrote:
> On 10/20/07, Darren Dale <dar...@co...> wrote:
> > Here is the answer:
> >
> > ax = axes()
> > lines, = plot([1,2,3], [1,2,3])
> > lines.set_ydata([4,5,6])
> > ax.relim()
>
> Yes, you may also want to see if calling gc.collect between your plot
> calls frees up some of your memory.
Thanks for the suggestion. The good news is, it looks like calling gc.collect 
is not necessary when updating the line's ydata and calling relim, 
autoscale_view and draw.
Darren

On 10/20/07, Darren Dale <dar...@co...> wrote:
> Here is the answer:
>
> ax = axes()
> lines, = plot([1,2,3], [1,2,3])
> lines.set_ydata([4,5,6])
> ax.relim()
Yes, you may also want to see if calling gc.collect between your plot
calls frees up some of your memory.
JDH

On Friday 19 October 2007 06:16:14 pm Darren Dale wrote:
> On Friday 19 October 2007 05:23:38 pm Darren Dale wrote:
> > I'm having some trouble updating a plot window without calling plot. I
> > would like to do something like:
> >
> > ax = axes()
> > lines, = plot([1,2,3], [1,2,3])
> > lines.set_ydata([4,5,6])
> > ax.autoscale_view()
> > ax.draw()
> >
> > The line does get updated, but the axes limits are not updated. I've
> > looked into the Axes.plot code, and as far as I can tell, the above code
> > should work. Can anyone tell me what is the right way to do this?
Here is the answer:
ax = axes()
lines, = plot([1,2,3], [1,2,3])
lines.set_ydata([4,5,6])
ax.relim()
ax.autoscale_view()
ax.draw()

On Friday 19 October 2007 05:23:38 pm Darren Dale wrote:
> I'm having some trouble updating a plot window without calling plot. I
> would like to do something like:
>
> ax = axes()
> lines, = plot([1,2,3], [1,2,3])
> lines.set_ydata([4,5,6])
> ax.autoscale_view()
> ax.draw()
>
> The line does get updated, but the axes limits are not updated. I've looked
> into the Axes.plot code, and as far as I can tell, the above code should
> work. Can anyone tell me what is the right way to do this?
I guess I should point out why I can't call plot. I'm rapidly losing physical 
memory, even when I call ax.hold(False):
ax = axes() # ipython using 51 MB
ax.plot(arange(1000000)) # ipython using 81 MB
ax.hold(False)
ax.plot(arange(1000000)) # ipython using 138 MB
ax.plot(arange(1000000)) # ipython using 142 MB
ax.hold(True)
ax.plot(arange(1000000)) # ipython using 172 MB
ax.plot(arange(1000000)) # ipython using 203 MB
Darren

I'm having some trouble updating a plot window without calling plot. I would 
like to do something like:
ax = axes()
lines, = plot([1,2,3], [1,2,3])
lines.set_ydata([4,5,6])
ax.autoscale_view()
ax.draw()
The line does get updated, but the axes limits are not updated. I've looked 
into the Axes.plot code, and as far as I can tell, the above code should 
work. Can anyone tell me what is the right way to do this?
Darren

On Friday 19 October 2007 10:55:24 am John Hunter wrote:
> On 10/19/07, Darren Dale <dar...@co...> wrote:
> > I removed a gsave/grestore pair surrounding RendererPS._draw_ps in
> > svn-3967. It looks like this fixed the problem (graphics state was being
> > lost). I checked contour_demo.py for any unintended side-effects, and
> > didn't find any, but please keep an eye out for strange behavior.
>
> I added this gsave/grestore pair in draw_ps because in a first attempt
> to get Ellipse working properly with axis='auto'. I was using an
> approach inspired by Michael's branch, which is to create a unit
> circle and then apply rotation and scaing transformation to make the
> ellipse. The transformation settings were persistent so I wrapped all
> of the draw_ps in a save/restore block to insulate them.
>
> Then I realized that doing the transformation in PS wreaks all kinds
> of havoc with the linewidth settings, and reverted the code to doing
> the transformations in python, as we have always done. So removing
> the save/restore block should be fine, but file it away in the back of
> your mind that pushing transformations in the current implementation
> may result in unintended weirdness.
Thanks for letting me know. When we first implemented draw_markers in 
backend_ps, we let the postscript interpretter do the transforms. That turned 
out to be a disaster. It took forever for ghostscript to render the images, 
so we went back to doing transforms in mpl.
Darren

On 10/19/07, Darren Dale <dar...@co...> wrote:
> I removed a gsave/grestore pair surrounding RendererPS._draw_ps in svn-3967.
> It looks like this fixed the problem (graphics state was being lost). I
> checked contour_demo.py for any unintended side-effects, and didn't find any,
> but please keep an eye out for strange behavior.
I added this gsave/grestore pair in draw_ps because in a first attempt
to get Ellipse working properly with axis='auto'. I was using an
approach inspired by Michael's branch, which is to create a unit
circle and then apply rotation and scaing transformation to make the
ellipse. The transformation settings were persistent so I wrapped all
of the draw_ps in a save/restore block to insulate them.
Then I realized that doing the transformation in PS wreaks all kinds
of havoc with the linewidth settings, and reverted the code to doing
the transformations in python, as we have always done. So removing
the save/restore block should be fine, but file it away in the back of
your mind that pushing transformations in the current implementation
may result in unintended weirdness.
JDH

On Friday 19 October 2007 03:57:31 am Manuel Metz wrote:
> Now that alpha works with screen output, I recognized a problem with the
> eps output. This is my little test script:
>
> import pylab
>
> x = pylab.npy.arange(0,10)
> pylab.scatter(x,x, s=50, alpha=0.5)
> pylab.scatter(x,x+0.5, facecolor='blue', edgecolor='red', s=50, alpha=0)
>
> pylab.savefig('alpha.png')
> pylab.savefig('alpha.eps')
> pylab.show()
>
> The resulting figures are attached. The problem occurs in the eps output
> where the edgecolors are not correctly reproduced, only the first marker
> symbol has a red edge, the others don't.
I removed a gsave/grestore pair surrounding RendererPS._draw_ps in svn-3967. 
It looks like this fixed the problem (graphics state was being lost). I 
checked contour_demo.py for any unintended side-effects, and didn't find any, 
but please keep an eye out for strange behavior.
Darren

Darren Dale wrote:
> On Friday 19 October 2007 10:20:43 am John Hunter wrote:
>> On 10/19/07, Darren Dale <dar...@co...> wrote:
>>> I don't remember how to find the answer. It looks like scatter() creates
>>> polygons, while plot() uses draw_markers:
>> I see -- scatter uses collections, and the defaut Renderer implements
>> PolygonCollection drawing through draw_polygon. This is correct,
>> because draw_markers assumes homogeneous markers, and scatter
>> implicitly assumes markers which vary in either size or shape (else
>> just use plot).
>>
>> As for the alpha problem, I committed a change yesterday to fix alpha
>> with the facecolor argument to scatter. Are you working off of the
>> latest SVN?
> 
> I am. Here is the eps generated from the script in my previous email. For 
> scatter, alpha=0 causes the markers to not be drawn but not filled. For plot, 
> alpha=0 causes the markers to be drawn and filled.
> 
> Also, scatter does not respect the marker shape when drawing the legend.
I've seen this behavior before too and think that legend definitely 
needs to be fixed for scatter to draw markers with the correct shape 
rather than just colored rectangles ...
Manuel
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Friday 19 October 2007 10:20:43 am John Hunter wrote:
> On 10/19/07, Darren Dale <dar...@co...> wrote:
> > I don't remember how to find the answer. It looks like scatter() creates
> > polygons, while plot() uses draw_markers:
>
> I see -- scatter uses collections, and the defaut Renderer implements
> PolygonCollection drawing through draw_polygon. This is correct,
> because draw_markers assumes homogeneous markers, and scatter
> implicitly assumes markers which vary in either size or shape (else
> just use plot).
>
> As for the alpha problem, I committed a change yesterday to fix alpha
> with the facecolor argument to scatter. Are you working off of the
> latest SVN?
I am. Here is the eps generated from the script in my previous email. For 
scatter, alpha=0 causes the markers to not be drawn but not filled. For plot, 
alpha=0 causes the markers to be drawn and filled.
Also, scatter does not respect the marker shape when drawing the legend.
Darren

On 10/19/07, Darren Dale <dar...@co...> wrote:
> I don't remember how to find the answer. It looks like scatter() creates
> polygons, while plot() uses draw_markers:
I see -- scatter uses collections, and the defaut Renderer implements
PolygonCollection drawing through draw_polygon. This is correct,
because draw_markers assumes homogeneous markers, and scatter
implicitly assumes markers which vary in either size or shape (else
just use plot).
As for the alpha problem, I committed a change yesterday to fix alpha
with the facecolor argument to scatter. Are you working off of the
latest SVN?
JDH

On Friday 19 October 2007 09:21:45 am John Hunter wrote:
> On 10/19/07, Darren Dale <dar...@co...> wrote:
> > A while back I put in quite a bit of effort into enabling draw_markers in
> > the postscript backend. This is an efficient RendererPS function both in
> > terms of speed and file size, but it seems to not be used any more in
> > favor of the less efficient draw_polygon. Does anyone know why?
>
> Which artist is triggering this call?
I don't remember how to find the answer. It looks like scatter() creates 
polygons, while plot() uses draw_markers:
import pylab
x = pylab.npy.arange(0,10)
pylab.scatter(x,x, s=50, alpha=0.5)
pylab.scatter(x,x+0.5, facecolor='blue', edgecolor='red', s=50, alpha=0)
pylab.plot(x,x+1, 'o', mfc='blue', mec='red', ms=8, alpha=0)
pylab.savefig('alpha.png')
pylab.savefig('alpha.eps')
pylab.show()
Comparing the png and eps, it looks like there is some inconsistancy in the 
way scatter and plot ends up dealing with the alpha argument as well.
Darren

On 10/19/07, Darren Dale <dar...@co...> wrote:
> A while back I put in quite a bit of effort into enabling draw_markers in the
> postscript backend. This is an efficient RendererPS function both in terms of
> speed and file size, but it seems to not be used any more in favor of the
> less efficient draw_polygon. Does anyone know why?
Which artist is triggering this call? The RendererPS defines
draw_markers, and this is the test Line2D uses to determine which
function to call:
 self._newstyle = hasattr(renderer, 'draw_markers')
thus newstyle will be True for PS. Then, in the Line2D marker drawing
function, eg
def _draw_square(...):
 if self._newstyle:
 path = agg.path_storage()
 path.move_to(-offset, -offset)
 path.line_to(-offset, offset)
 path.line_to(offset, offset)
 path.line_to(offset, -offset)
 path.end_poly()
 renderer.draw_markers(gc, path, rgbFace, xt, yt,
self.get_transform())
 else:
so my guess is Line2D *is* using draw_markers for backend_ps.
Patches.Polygon and derived will still be using the old draw_polygon,
but there is no speed bottleneck here since one normally just adds a
few Polygon instances manually (else use a Collection). The case we
were trying to optimize with draw_markers was
 ax.plot(x, y, 'o')
and related, where a 10,000 marker plot was triggering 10,000 calls to
draw_polygon, and now triggers one call to draw_markers for backends
that define it.
Note that in Michael's branch, this is mostly moot. He has completely
rewritten the transforms module in python and migrated to a path based
drawing model, overhauling Line2D, Patch and Collections in the
process. His branch is passing 75% or more of the examples and he
is hammering away at the rest -- so far he has been concentrating on
Agg but has recently begun the postscript work. It is will worth a
look, as this will be merged back into the trunk, probably after the
next major release.
svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/transforms
mgd
JDH

A while back I put in quite a bit of effort into enabling draw_markers in the 
postscript backend. This is an efficient RendererPS function both in terms of 
speed and file size, but it seems to not be used any more in favor of the 
less efficient draw_polygon. Does anyone know why?
Darren

There is a minor bug in line 852 in patches.py
 verbose.report('patches.Ellipse renderer .......
This has to be
 mpl.verbose.report('patches.Ellipse renderer .......
Manuel

Now that alpha works with screen output, I recognized a problem with the 
eps output. This is my little test script:
import pylab
x = pylab.npy.arange(0,10)
pylab.scatter(x,x, s=50, alpha=0.5)
pylab.scatter(x,x+0.5, facecolor='blue', edgecolor='red', s=50, alpha=0)
pylab.savefig('alpha.png')
pylab.savefig('alpha.eps')
pylab.show()
The resulting figures are attached. The problem occurs in the eps output 
where the edgecolors are not correctly reproduced, only the first marker 
symbol has a red edge, the others don't.
I used the latest svn for this test.
Manuel
John Hunter wrote:
> On 10/18/07, John Hunter <jd...@gm...> wrote:
> 
>> You should use the "c" argument for scatter -- this controls the facecolor.
>>
>> scatter(x,x+0.5, c='blue', s=50, alpha=0.5)
>>
>> This is a bit of an anachronism from matlab compatibility.
> 
> This is now fixed in svn, so you can use facecolor as well. Note that
> for constant size and color markers, plot will be significantly faster
> 
> ax.plot(x, x+0.5, mfc='blue', alpha=0.5, ms=20)
> 
> JDH

WIN32 worked for the last matplotlib release build I did, but I agree
this patch is harmless. Thanks for looking into it this much.
- Charlie
On 10/16/07, Michael Droettboom <md...@st...> wrote:
> Thanks. Sorry about the syntax errors -- I don't use the preprocessor
> much either.
>
> I think this patch seems reasonable (or at least reasonably harmless),
> so I'll go ahead and commit it.
>
> Cheers,
> Mike
>
> Martin Spacek wrote:
> > Michael Droettboom wrote:
> >> Hmmm... Well, I think we've reached the limit of my MSVC knowledge
> >> (which doesn't go very far.) I presume that for your local copy, you
> >> can just hard code it to :
> >>
> >> #ifdef 1 || WIN32 || _MSC_VER
> >
> > Actually, I just tried that, and it didn't work. Again, I don't really
> > know anything about preprocessing in C, but it seems you can't put more
> > than one MACRO in an #ifdef statement. Instead, it looks like you need
> > to do:
> >
> > #if defined(WIN32) || defined(_MSC_VER)
> >
> > This *does* work for me. So it seems WIN32 isn't defined on my MSVC7.1,
> > but _MSC_VER is (I've discovered that _WIN32 is defined as well).
> > Anyways, I'm not sure if this is the ideal way to have it, but I've
> > attached a patch against the latest rev.
> >
> > Cheers,
> >
> > Martin
> >
> >
> >>
> >> and at least get it working for yourself. But I think someone with
> >> more MSVC experience on this list may have to look into this and have
> >> more to offer.
> >>
> >> Cheers,
> >> Mike
> >>
> >> Martin Spacek wrote:
> >>> Sorry for the delay. I gave that a try, but it didn't help. Seems that
> >>> _MSC_VER is undefined as well...
> >>>
> >>> Martin
> >>>
> >>> Michael Droettboom wrote:
> >>>> Martin Spacek wrote:
> >>>>> It's been a few months since I've updated and compiled from svn. I got
> >>>>> this error today from rev 3926 (in winxp using msvc71):
> >>>>>
> >>>>>> python setup.py build_ext --inplace --force
> >>>>> ============================================================================
> >>>>>
> >>>>> BUILDING MATPLOTLIB
> >>>>> matplotlib: 0.90.1
> >>>>> python: 2.5.1 (r251:54863, Apr 18 2007, 08:51:08)
> >>>>> [MSC
> >>>>> v.1310 32 bit (Intel)]
> >>>>> platform: win32
> >>>>> Windows version: (5, 1, 2600, 2, 'Service Pack 2')
> >>>>>
> >>>>> REQUIRED DEPENDENCIES
> >>>>> numpy: 1.0.4.dev4155
> >>>>> freetype2: found, but unknown version (no pkg-config)
> >>>>>
> >>>>> OPTIONAL DEPENDENCIES
> >>>>> Gtk+: no
> >>>>> * Building for Gtk+ requires pygtk; you
> >>>>> must be
> >>>>> able
> >>>>> * to "import gtk" in your build/install
> >>>>> environment
> >>>>> Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
> >>>>> wxPython: 2.8.4.0
> >>>>> * WxAgg extension not required for wxPython
> >>>>>> = 2.8
> >>>>> Qt: no
> >>>>> Qt4: no
> >>>>> Cairo: no
> >>>>> libpng: found, but unknown version (no pkg-config)
> >>>>>
> >>>>> [Edit setup.cfg to suppress the above messages]
> >>>>> ============================================================================
> >>>>>
> >>>>> running build_ext
> >>>>> No module named msvccompiler in numpy.distutils; trying from distutils
> >>>>> building 'matplotlib.ft2font' extension
> >>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
> >>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
> >>>>> Iwin32_static\include\freetype2 -I.\freetype2
> >>>>> -IC:\bin\Python25\include
> >>>>> -IC:\bin\Python25\PC /Tpsrc/ft2font.cpp /Fobuild
> >>>>> \temp.win32-2.5\Release\src/ft2font.obj
> >>>>> Found executable C:\bin\Microsoft Visual Studio .NET
> >>>>> 2003\Vc7\bin\cl.exe
> >>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
> >>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
> >>>>> Iwin32_static\include\freetype2 -I.\freetype2
> >>>>> -IC:\bin\Python25\include
> >>>>> -IC:\bin\Python25\PC /Tpsrc/mplutils.cpp /Fobuil
> >>>>> d\temp.win32-2.5\Release\src/mplutils.obj
> >>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
> >>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
> >>>>> Iwin32_static\include\freetype2 -I.\freetype2
> >>>>> -IC:\bin\Python25\include
> >>>>> -IC:\bin\Python25\PC /TpCXX\cxxsupport.cxx /Fobu
> >>>>> ild\temp.win32-2.5\Release\CXX\cxxsupport.obj
> >>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
> >>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
> >>>>> Iwin32_static\include\freetype2 -I.\freetype2
> >>>>> -IC:\bin\Python25\include
> >>>>> -IC:\bin\Python25\PC /TpCXX\cxx_extensions.cxx /
> >>>>> Fobuild\temp.win32-2.5\Release\CXX\cxx_extensions.obj
> >>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
> >>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
> >>>>> Iwin32_static\include\freetype2 -I.\freetype2
> >>>>> -IC:\bin\Python25\include
> >>>>> -IC:\bin\Python25\PC /TpCXX\IndirectPythonInterf
> >>>>> ace.cxx
> >>>>> /Fobuild\temp.win32-2.5\Release\CXX\IndirectPythonInterface.obj
> >>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
> >>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
> >>>>> Iwin32_static\include\freetype2 -I.\freetype2
> >>>>> -IC:\bin\Python25\include
> >>>>> -IC:\bin\Python25\PC /TcCXX\cxxextensions.c /Fob
> >>>>> uild\temp.win32-2.5\Release\CXX\cxxextensions.obj
> >>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\link.exe /DLL /nologo
> >>>>> /INCREMENTAL:NO /LIBPATH:win32_static\lib /LIBPAT
> >>>>> H:C:\bin\Python25\libs /LIBPATH:C:\bin\Python25\PCBuild freetype.lib
> >>>>> z.lib /EXPORT:initft2font build\temp.win32-2.5\Rele
> >>>>> ase\src/ft2font.obj build\temp.win32-2.5\Release\src/mplutils.obj
> >>>>> build\temp.win32-2.5\Release\CXX\cxxsupport.obj build\
> >>>>> temp.win32-2.5\Release\CXX\cxx_extensions.obj
> >>>>> build\temp.win32-2.5\Release\CXX\IndirectPythonInterface.obj
> >>>>> build\temp.wi
> >>>>> n32-2.5\Release\CXX\cxxextensions.obj /OUT:lib\matplotlib\ft2font.pyd
> >>>>> /IMPLIB:build\temp.win32-2.5\Release\src\ft2font.l
> >>>>> ib
> >>>>> Found executable C:\bin\Microsoft Visual Studio .NET
> >>>>> 2003\Vc7\bin\link.exe
> >>>>> building 'matplotlib.ttconv' extension
> >>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
> >>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
> >>>>> IC:\bin\Python25\include -IC:\bin\Python25\PC /Tpsrc/_ttconv.cpp
> >>>>> /Fobuild\temp.win32-2.5\Release\src/_ttconv.obj
> >>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
> >>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
> >>>>> IC:\bin\Python25\include -IC:\bin\Python25\PC /Tpttconv/pprdrv_tt.cpp
> >>>>> /Fobuild\temp.win32-2.5\Release\ttconv/pprdrv_tt.o
> >>>>> bj
> >>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
> >>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
> >>>>> IC:\bin\Python25\include -IC:\bin\Python25\PC /Tpttconv/pprdrv_tt2.cpp
> >>>>> /Fobuild\temp.win32-2.5\Release\ttconv/pprdrv_tt2
> >>>>> .obj
> >>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
> >>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
> >>>>> IC:\bin\Python25\include -IC:\bin\Python25\PC /Tpttconv/ttutil.cpp
> >>>>> /Fobuild\temp.win32-2.5\Release\ttconv/ttutil.obj
> >>>>> ttutil.cpp
> >>>>> ttconv\ttutil.cpp(38) : error C3861: 'vsnprintf': identifier not
> >>>>> found,
> >>>>> even with argument-dependent lookup
> >>>>> ttconv\ttutil.cpp(45) : error C3861: 'vsnprintf': identifier not
> >>>>> found,
> >>>>> even with argument-dependent lookup
> >>>>> error: Command "C:\bin\Microsoft Visual Studio .NET
> >>>>> 2003\Vc7\bin\cl.exe
> >>>>> /c /nologo /Ox /MD /W3 /GX /DNDEBUG -Iwin32_stat
> >>>>> ic\include -I. -IC:\bin\Python25\include -IC:\bin\Python25\PC
> >>>>> /Tpttconv/ttutil.cpp /Fobuild\temp.win32-2.5\Release\ttcon
> >>>>> v/ttutil.obj" failed with exit status 2
> >>>>>
> >>>>>
> >>>>>
> >>>>> The latest change for ttutil.cpp was:
> >>>>>
> >>>>> Revision: 3696
> >>>>> Author: cmoad
> >>>>> Date: 5:53:21 AM, Friday, August 10, 2007
> >>>>> Message:
> >>>>> added win32 checks for vsnprintf which is _vsnprintf on windows
> >>>>> ----
> >>>>> Modified : /trunk/matplotlib/ttconv/ttutil.cpp
> >>>>>
> >>>>> So it looks like both the lines that check #ifdef WIN32 are evaluating
> >>>>> as false, even though I'm in win32. I don't know much about C++. As a
> >>>>> hack, replacing vsnprintf with _vsnprintf in the else clauses gives
> >>>>> me a
> >>>>> successful build.
> >>>> Hmm... I wonder if the WIN32 symbol is a Mingw32 thing and not a MS
> >>>> Visual Studio thing. One thing I have seen elsewhere is the use of
> >>>> _MSC_VER to do this. Would you mind trying:
> >>>>
> >>>> #ifdef WIN32 || _MSC_VER
> >>>>
> >>>> instead of
> >>>>
> >>>> #ifdef WIN32
> >>>>
> >>>> (I don't have a MS Visual Studio to test with myself). Maybe one of
> >>>> the Windows guys on this list has another idea as well.
> >>>>
> >>>
> >>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Thanks. Sorry about the syntax errors -- I don't use the preprocessor 
much either.
I think this patch seems reasonable (or at least reasonably harmless), 
so I'll go ahead and commit it.
Cheers,
Mike
Martin Spacek wrote:
> Michael Droettboom wrote:
>> Hmmm... Well, I think we've reached the limit of my MSVC knowledge 
>> (which doesn't go very far.) I presume that for your local copy, you 
>> can just hard code it to :
>>
>> #ifdef 1 || WIN32 || _MSC_VER
> 
> Actually, I just tried that, and it didn't work. Again, I don't really 
> know anything about preprocessing in C, but it seems you can't put more 
> than one MACRO in an #ifdef statement. Instead, it looks like you need 
> to do:
> 
> #if defined(WIN32) || defined(_MSC_VER)
> 
> This *does* work for me. So it seems WIN32 isn't defined on my MSVC7.1, 
> but _MSC_VER is (I've discovered that _WIN32 is defined as well). 
> Anyways, I'm not sure if this is the ideal way to have it, but I've 
> attached a patch against the latest rev.
> 
> Cheers,
> 
> Martin
> 
> 
>>
>> and at least get it working for yourself. But I think someone with 
>> more MSVC experience on this list may have to look into this and have 
>> more to offer.
>>
>> Cheers,
>> Mike
>>
>> Martin Spacek wrote:
>>> Sorry for the delay. I gave that a try, but it didn't help. Seems that
>>> _MSC_VER is undefined as well...
>>>
>>> Martin
>>>
>>> Michael Droettboom wrote:
>>>> Martin Spacek wrote:
>>>>> It's been a few months since I've updated and compiled from svn. I got
>>>>> this error today from rev 3926 (in winxp using msvc71):
>>>>>
>>>>>> python setup.py build_ext --inplace --force
>>>>> ============================================================================ 
>>>>>
>>>>> BUILDING MATPLOTLIB
>>>>> matplotlib: 0.90.1
>>>>> python: 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) 
>>>>> [MSC
>>>>> v.1310 32 bit (Intel)]
>>>>> platform: win32
>>>>> Windows version: (5, 1, 2600, 2, 'Service Pack 2')
>>>>>
>>>>> REQUIRED DEPENDENCIES
>>>>> numpy: 1.0.4.dev4155
>>>>> freetype2: found, but unknown version (no pkg-config)
>>>>>
>>>>> OPTIONAL DEPENDENCIES
>>>>> Gtk+: no
>>>>> * Building for Gtk+ requires pygtk; you 
>>>>> must be
>>>>> able
>>>>> * to "import gtk" in your build/install 
>>>>> environment
>>>>> Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
>>>>> wxPython: 2.8.4.0
>>>>> * WxAgg extension not required for wxPython
>>>>>> = 2.8
>>>>> Qt: no
>>>>> Qt4: no
>>>>> Cairo: no
>>>>> libpng: found, but unknown version (no pkg-config)
>>>>>
>>>>> [Edit setup.cfg to suppress the above messages]
>>>>> ============================================================================ 
>>>>>
>>>>> running build_ext
>>>>> No module named msvccompiler in numpy.distutils; trying from distutils
>>>>> building 'matplotlib.ft2font' extension
>>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>>>> Iwin32_static\include\freetype2 -I.\freetype2 
>>>>> -IC:\bin\Python25\include
>>>>> -IC:\bin\Python25\PC /Tpsrc/ft2font.cpp /Fobuild
>>>>> \temp.win32-2.5\Release\src/ft2font.obj
>>>>> Found executable C:\bin\Microsoft Visual Studio .NET 
>>>>> 2003\Vc7\bin\cl.exe
>>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>>>> Iwin32_static\include\freetype2 -I.\freetype2 
>>>>> -IC:\bin\Python25\include
>>>>> -IC:\bin\Python25\PC /Tpsrc/mplutils.cpp /Fobuil
>>>>> d\temp.win32-2.5\Release\src/mplutils.obj
>>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>>>> Iwin32_static\include\freetype2 -I.\freetype2 
>>>>> -IC:\bin\Python25\include
>>>>> -IC:\bin\Python25\PC /TpCXX\cxxsupport.cxx /Fobu
>>>>> ild\temp.win32-2.5\Release\CXX\cxxsupport.obj
>>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>>>> Iwin32_static\include\freetype2 -I.\freetype2 
>>>>> -IC:\bin\Python25\include
>>>>> -IC:\bin\Python25\PC /TpCXX\cxx_extensions.cxx /
>>>>> Fobuild\temp.win32-2.5\Release\CXX\cxx_extensions.obj
>>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>>>> Iwin32_static\include\freetype2 -I.\freetype2 
>>>>> -IC:\bin\Python25\include
>>>>> -IC:\bin\Python25\PC /TpCXX\IndirectPythonInterf
>>>>> ace.cxx 
>>>>> /Fobuild\temp.win32-2.5\Release\CXX\IndirectPythonInterface.obj
>>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>>>> Iwin32_static\include\freetype2 -I.\freetype2 
>>>>> -IC:\bin\Python25\include
>>>>> -IC:\bin\Python25\PC /TcCXX\cxxextensions.c /Fob
>>>>> uild\temp.win32-2.5\Release\CXX\cxxextensions.obj
>>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\link.exe /DLL /nologo
>>>>> /INCREMENTAL:NO /LIBPATH:win32_static\lib /LIBPAT
>>>>> H:C:\bin\Python25\libs /LIBPATH:C:\bin\Python25\PCBuild freetype.lib
>>>>> z.lib /EXPORT:initft2font build\temp.win32-2.5\Rele
>>>>> ase\src/ft2font.obj build\temp.win32-2.5\Release\src/mplutils.obj
>>>>> build\temp.win32-2.5\Release\CXX\cxxsupport.obj build\
>>>>> temp.win32-2.5\Release\CXX\cxx_extensions.obj
>>>>> build\temp.win32-2.5\Release\CXX\IndirectPythonInterface.obj 
>>>>> build\temp.wi
>>>>> n32-2.5\Release\CXX\cxxextensions.obj /OUT:lib\matplotlib\ft2font.pyd
>>>>> /IMPLIB:build\temp.win32-2.5\Release\src\ft2font.l
>>>>> ib
>>>>> Found executable C:\bin\Microsoft Visual Studio .NET 
>>>>> 2003\Vc7\bin\link.exe
>>>>> building 'matplotlib.ttconv' extension
>>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>>>> IC:\bin\Python25\include -IC:\bin\Python25\PC /Tpsrc/_ttconv.cpp
>>>>> /Fobuild\temp.win32-2.5\Release\src/_ttconv.obj
>>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>>>> IC:\bin\Python25\include -IC:\bin\Python25\PC /Tpttconv/pprdrv_tt.cpp
>>>>> /Fobuild\temp.win32-2.5\Release\ttconv/pprdrv_tt.o
>>>>> bj
>>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>>>> IC:\bin\Python25\include -IC:\bin\Python25\PC /Tpttconv/pprdrv_tt2.cpp
>>>>> /Fobuild\temp.win32-2.5\Release\ttconv/pprdrv_tt2
>>>>> .obj
>>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>>>> IC:\bin\Python25\include -IC:\bin\Python25\PC /Tpttconv/ttutil.cpp
>>>>> /Fobuild\temp.win32-2.5\Release\ttconv/ttutil.obj
>>>>> ttutil.cpp
>>>>> ttconv\ttutil.cpp(38) : error C3861: 'vsnprintf': identifier not 
>>>>> found,
>>>>> even with argument-dependent lookup
>>>>> ttconv\ttutil.cpp(45) : error C3861: 'vsnprintf': identifier not 
>>>>> found,
>>>>> even with argument-dependent lookup
>>>>> error: Command "C:\bin\Microsoft Visual Studio .NET 
>>>>> 2003\Vc7\bin\cl.exe
>>>>> /c /nologo /Ox /MD /W3 /GX /DNDEBUG -Iwin32_stat
>>>>> ic\include -I. -IC:\bin\Python25\include -IC:\bin\Python25\PC
>>>>> /Tpttconv/ttutil.cpp /Fobuild\temp.win32-2.5\Release\ttcon
>>>>> v/ttutil.obj" failed with exit status 2
>>>>>
>>>>>
>>>>>
>>>>> The latest change for ttutil.cpp was:
>>>>>
>>>>> Revision: 3696
>>>>> Author: cmoad
>>>>> Date: 5:53:21 AM, Friday, August 10, 2007
>>>>> Message:
>>>>> added win32 checks for vsnprintf which is _vsnprintf on windows
>>>>> ----
>>>>> Modified : /trunk/matplotlib/ttconv/ttutil.cpp
>>>>>
>>>>> So it looks like both the lines that check #ifdef WIN32 are evaluating
>>>>> as false, even though I'm in win32. I don't know much about C++. As a
>>>>> hack, replacing vsnprintf with _vsnprintf in the else clauses gives 
>>>>> me a
>>>>> successful build.
>>>> Hmm... I wonder if the WIN32 symbol is a Mingw32 thing and not a MS 
>>>> Visual Studio thing. One thing I have seen elsewhere is the use of 
>>>> _MSC_VER to do this. Would you mind trying:
>>>>
>>>> #ifdef WIN32 || _MSC_VER
>>>>
>>>> instead of
>>>>
>>>> #ifdef WIN32
>>>>
>>>> (I don't have a MS Visual Studio to test with myself). Maybe one of 
>>>> the Windows guys on this list has another idea as well.
>>>>
>>>
>>>
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
> Hmmm... Well, I think we've reached the limit of my MSVC knowledge 
> (which doesn't go very far.) I presume that for your local copy, you 
> can just hard code it to :
> 
> #ifdef 1 || WIN32 || _MSC_VER
Actually, I just tried that, and it didn't work. Again, I don't really 
know anything about preprocessing in C, but it seems you can't put more 
than one MACRO in an #ifdef statement. Instead, it looks like you need 
to do:
#if defined(WIN32) || defined(_MSC_VER)
This *does* work for me. So it seems WIN32 isn't defined on my MSVC7.1, 
but _MSC_VER is (I've discovered that _WIN32 is defined as well). 
Anyways, I'm not sure if this is the ideal way to have it, but I've 
attached a patch against the latest rev.
Cheers,
Martin
> 
> and at least get it working for yourself. But I think someone with more 
> MSVC experience on this list may have to look into this and have more to 
> offer.
> 
> Cheers,
> Mike
> 
> Martin Spacek wrote:
>> Sorry for the delay. I gave that a try, but it didn't help. Seems that
>> _MSC_VER is undefined as well...
>>
>> Martin
>>
>> Michael Droettboom wrote:
>>> Martin Spacek wrote:
>>>> It's been a few months since I've updated and compiled from svn. I got
>>>> this error today from rev 3926 (in winxp using msvc71):
>>>>
>>>>> python setup.py build_ext --inplace --force
>>>> ============================================================================ 
>>>>
>>>> BUILDING MATPLOTLIB
>>>> matplotlib: 0.90.1
>>>> python: 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC
>>>> v.1310 32 bit (Intel)]
>>>> platform: win32
>>>> Windows version: (5, 1, 2600, 2, 'Service Pack 2')
>>>>
>>>> REQUIRED DEPENDENCIES
>>>> numpy: 1.0.4.dev4155
>>>> freetype2: found, but unknown version (no pkg-config)
>>>>
>>>> OPTIONAL DEPENDENCIES
>>>> Gtk+: no
>>>> * Building for Gtk+ requires pygtk; you 
>>>> must be
>>>> able
>>>> * to "import gtk" in your build/install 
>>>> environment
>>>> Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
>>>> wxPython: 2.8.4.0
>>>> * WxAgg extension not required for wxPython
>>>>> = 2.8
>>>> Qt: no
>>>> Qt4: no
>>>> Cairo: no
>>>> libpng: found, but unknown version (no pkg-config)
>>>>
>>>> [Edit setup.cfg to suppress the above messages]
>>>> ============================================================================ 
>>>>
>>>> running build_ext
>>>> No module named msvccompiler in numpy.distutils; trying from distutils
>>>> building 'matplotlib.ft2font' extension
>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>>> Iwin32_static\include\freetype2 -I.\freetype2 -IC:\bin\Python25\include
>>>> -IC:\bin\Python25\PC /Tpsrc/ft2font.cpp /Fobuild
>>>> \temp.win32-2.5\Release\src/ft2font.obj
>>>> Found executable C:\bin\Microsoft Visual Studio .NET 
>>>> 2003\Vc7\bin\cl.exe
>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>>> Iwin32_static\include\freetype2 -I.\freetype2 -IC:\bin\Python25\include
>>>> -IC:\bin\Python25\PC /Tpsrc/mplutils.cpp /Fobuil
>>>> d\temp.win32-2.5\Release\src/mplutils.obj
>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>>> Iwin32_static\include\freetype2 -I.\freetype2 -IC:\bin\Python25\include
>>>> -IC:\bin\Python25\PC /TpCXX\cxxsupport.cxx /Fobu
>>>> ild\temp.win32-2.5\Release\CXX\cxxsupport.obj
>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>>> Iwin32_static\include\freetype2 -I.\freetype2 -IC:\bin\Python25\include
>>>> -IC:\bin\Python25\PC /TpCXX\cxx_extensions.cxx /
>>>> Fobuild\temp.win32-2.5\Release\CXX\cxx_extensions.obj
>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>>> Iwin32_static\include\freetype2 -I.\freetype2 -IC:\bin\Python25\include
>>>> -IC:\bin\Python25\PC /TpCXX\IndirectPythonInterf
>>>> ace.cxx /Fobuild\temp.win32-2.5\Release\CXX\IndirectPythonInterface.obj
>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>>> Iwin32_static\include\freetype2 -I.\freetype2 -IC:\bin\Python25\include
>>>> -IC:\bin\Python25\PC /TcCXX\cxxextensions.c /Fob
>>>> uild\temp.win32-2.5\Release\CXX\cxxextensions.obj
>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\link.exe /DLL /nologo
>>>> /INCREMENTAL:NO /LIBPATH:win32_static\lib /LIBPAT
>>>> H:C:\bin\Python25\libs /LIBPATH:C:\bin\Python25\PCBuild freetype.lib
>>>> z.lib /EXPORT:initft2font build\temp.win32-2.5\Rele
>>>> ase\src/ft2font.obj build\temp.win32-2.5\Release\src/mplutils.obj
>>>> build\temp.win32-2.5\Release\CXX\cxxsupport.obj build\
>>>> temp.win32-2.5\Release\CXX\cxx_extensions.obj
>>>> build\temp.win32-2.5\Release\CXX\IndirectPythonInterface.obj 
>>>> build\temp.wi
>>>> n32-2.5\Release\CXX\cxxextensions.obj /OUT:lib\matplotlib\ft2font.pyd
>>>> /IMPLIB:build\temp.win32-2.5\Release\src\ft2font.l
>>>> ib
>>>> Found executable C:\bin\Microsoft Visual Studio .NET 
>>>> 2003\Vc7\bin\link.exe
>>>> building 'matplotlib.ttconv' extension
>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>>> IC:\bin\Python25\include -IC:\bin\Python25\PC /Tpsrc/_ttconv.cpp
>>>> /Fobuild\temp.win32-2.5\Release\src/_ttconv.obj
>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>>> IC:\bin\Python25\include -IC:\bin\Python25\PC /Tpttconv/pprdrv_tt.cpp
>>>> /Fobuild\temp.win32-2.5\Release\ttconv/pprdrv_tt.o
>>>> bj
>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>>> IC:\bin\Python25\include -IC:\bin\Python25\PC /Tpttconv/pprdrv_tt2.cpp
>>>> /Fobuild\temp.win32-2.5\Release\ttconv/pprdrv_tt2
>>>> .obj
>>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>>> IC:\bin\Python25\include -IC:\bin\Python25\PC /Tpttconv/ttutil.cpp
>>>> /Fobuild\temp.win32-2.5\Release\ttconv/ttutil.obj
>>>> ttutil.cpp
>>>> ttconv\ttutil.cpp(38) : error C3861: 'vsnprintf': identifier not found,
>>>> even with argument-dependent lookup
>>>> ttconv\ttutil.cpp(45) : error C3861: 'vsnprintf': identifier not found,
>>>> even with argument-dependent lookup
>>>> error: Command "C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe
>>>> /c /nologo /Ox /MD /W3 /GX /DNDEBUG -Iwin32_stat
>>>> ic\include -I. -IC:\bin\Python25\include -IC:\bin\Python25\PC
>>>> /Tpttconv/ttutil.cpp /Fobuild\temp.win32-2.5\Release\ttcon
>>>> v/ttutil.obj" failed with exit status 2
>>>>
>>>>
>>>>
>>>> The latest change for ttutil.cpp was:
>>>>
>>>> Revision: 3696
>>>> Author: cmoad
>>>> Date: 5:53:21 AM, Friday, August 10, 2007
>>>> Message:
>>>> added win32 checks for vsnprintf which is _vsnprintf on windows
>>>> ----
>>>> Modified : /trunk/matplotlib/ttconv/ttutil.cpp
>>>>
>>>> So it looks like both the lines that check #ifdef WIN32 are evaluating
>>>> as false, even though I'm in win32. I don't know much about C++. As a
>>>> hack, replacing vsnprintf with _vsnprintf in the else clauses gives 
>>>> me a
>>>> successful build.
>>> Hmm... I wonder if the WIN32 symbol is a Mingw32 thing and not a MS 
>>> Visual Studio thing. One thing I have seen elsewhere is the use of 
>>> _MSC_VER to do this. Would you mind trying:
>>>
>>> #ifdef WIN32 || _MSC_VER
>>>
>>> instead of
>>>
>>> #ifdef WIN32
>>>
>>> (I don't have a MS Visual Studio to test with myself). Maybe one of 
>>> the Windows guys on this list has another idea as well.
>>>
>>
>>

Hmmm... Well, I think we've reached the limit of my MSVC knowledge 
(which doesn't go very far.) I presume that for your local copy, you 
can just hard code it to :
	#ifdef 1 || WIN32 || _MSC_VER
and at least get it working for yourself. But I think someone with more 
MSVC experience on this list may have to look into this and have more to 
offer.
Cheers,
Mike
Martin Spacek wrote:
> Sorry for the delay. I gave that a try, but it didn't help. Seems that
> _MSC_VER is undefined as well...
> 
> Martin
> 
> Michael Droettboom wrote:
>> Martin Spacek wrote:
>>> It's been a few months since I've updated and compiled from svn. I got
>>> this error today from rev 3926 (in winxp using msvc71):
>>>
>>>> python setup.py build_ext --inplace --force
>>> ============================================================================ 
>>>
>>> BUILDING MATPLOTLIB
>>> matplotlib: 0.90.1
>>> python: 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC
>>> v.1310 32 bit (Intel)]
>>> platform: win32
>>> Windows version: (5, 1, 2600, 2, 'Service Pack 2')
>>>
>>> REQUIRED DEPENDENCIES
>>> numpy: 1.0.4.dev4155
>>> freetype2: found, but unknown version (no pkg-config)
>>>
>>> OPTIONAL DEPENDENCIES
>>> Gtk+: no
>>> * Building for Gtk+ requires pygtk; you must be
>>> able
>>> * to "import gtk" in your build/install 
>>> environment
>>> Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
>>> wxPython: 2.8.4.0
>>> * WxAgg extension not required for wxPython 
>>>> = 2.8
>>> Qt: no
>>> Qt4: no
>>> Cairo: no
>>> libpng: found, but unknown version (no pkg-config)
>>>
>>> [Edit setup.cfg to suppress the above messages]
>>> ============================================================================ 
>>>
>>> running build_ext
>>> No module named msvccompiler in numpy.distutils; trying from distutils
>>> building 'matplotlib.ft2font' extension
>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>> Iwin32_static\include\freetype2 -I.\freetype2 -IC:\bin\Python25\include
>>> -IC:\bin\Python25\PC /Tpsrc/ft2font.cpp /Fobuild
>>> \temp.win32-2.5\Release\src/ft2font.obj
>>> Found executable C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe
>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>> Iwin32_static\include\freetype2 -I.\freetype2 -IC:\bin\Python25\include
>>> -IC:\bin\Python25\PC /Tpsrc/mplutils.cpp /Fobuil
>>> d\temp.win32-2.5\Release\src/mplutils.obj
>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>> Iwin32_static\include\freetype2 -I.\freetype2 -IC:\bin\Python25\include
>>> -IC:\bin\Python25\PC /TpCXX\cxxsupport.cxx /Fobu
>>> ild\temp.win32-2.5\Release\CXX\cxxsupport.obj
>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>> Iwin32_static\include\freetype2 -I.\freetype2 -IC:\bin\Python25\include
>>> -IC:\bin\Python25\PC /TpCXX\cxx_extensions.cxx /
>>> Fobuild\temp.win32-2.5\Release\CXX\cxx_extensions.obj
>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>> Iwin32_static\include\freetype2 -I.\freetype2 -IC:\bin\Python25\include
>>> -IC:\bin\Python25\PC /TpCXX\IndirectPythonInterf
>>> ace.cxx /Fobuild\temp.win32-2.5\Release\CXX\IndirectPythonInterface.obj
>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>> Iwin32_static\include\freetype2 -I.\freetype2 -IC:\bin\Python25\include
>>> -IC:\bin\Python25\PC /TcCXX\cxxextensions.c /Fob
>>> uild\temp.win32-2.5\Release\CXX\cxxextensions.obj
>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\link.exe /DLL /nologo
>>> /INCREMENTAL:NO /LIBPATH:win32_static\lib /LIBPAT
>>> H:C:\bin\Python25\libs /LIBPATH:C:\bin\Python25\PCBuild freetype.lib
>>> z.lib /EXPORT:initft2font build\temp.win32-2.5\Rele
>>> ase\src/ft2font.obj build\temp.win32-2.5\Release\src/mplutils.obj
>>> build\temp.win32-2.5\Release\CXX\cxxsupport.obj build\
>>> temp.win32-2.5\Release\CXX\cxx_extensions.obj
>>> build\temp.win32-2.5\Release\CXX\IndirectPythonInterface.obj 
>>> build\temp.wi
>>> n32-2.5\Release\CXX\cxxextensions.obj /OUT:lib\matplotlib\ft2font.pyd
>>> /IMPLIB:build\temp.win32-2.5\Release\src\ft2font.l
>>> ib
>>> Found executable C:\bin\Microsoft Visual Studio .NET 
>>> 2003\Vc7\bin\link.exe
>>> building 'matplotlib.ttconv' extension
>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>> IC:\bin\Python25\include -IC:\bin\Python25\PC /Tpsrc/_ttconv.cpp
>>> /Fobuild\temp.win32-2.5\Release\src/_ttconv.obj
>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>> IC:\bin\Python25\include -IC:\bin\Python25\PC /Tpttconv/pprdrv_tt.cpp
>>> /Fobuild\temp.win32-2.5\Release\ttconv/pprdrv_tt.o
>>> bj
>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>> IC:\bin\Python25\include -IC:\bin\Python25\PC /Tpttconv/pprdrv_tt2.cpp
>>> /Fobuild\temp.win32-2.5\Release\ttconv/pprdrv_tt2
>>> .obj
>>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>>> IC:\bin\Python25\include -IC:\bin\Python25\PC /Tpttconv/ttutil.cpp
>>> /Fobuild\temp.win32-2.5\Release\ttconv/ttutil.obj
>>> ttutil.cpp
>>> ttconv\ttutil.cpp(38) : error C3861: 'vsnprintf': identifier not found,
>>> even with argument-dependent lookup
>>> ttconv\ttutil.cpp(45) : error C3861: 'vsnprintf': identifier not found,
>>> even with argument-dependent lookup
>>> error: Command "C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe
>>> /c /nologo /Ox /MD /W3 /GX /DNDEBUG -Iwin32_stat
>>> ic\include -I. -IC:\bin\Python25\include -IC:\bin\Python25\PC
>>> /Tpttconv/ttutil.cpp /Fobuild\temp.win32-2.5\Release\ttcon
>>> v/ttutil.obj" failed with exit status 2
>>>
>>>
>>>
>>> The latest change for ttutil.cpp was:
>>>
>>> Revision: 3696
>>> Author: cmoad
>>> Date: 5:53:21 AM, Friday, August 10, 2007
>>> Message:
>>> added win32 checks for vsnprintf which is _vsnprintf on windows
>>> ----
>>> Modified : /trunk/matplotlib/ttconv/ttutil.cpp
>>>
>>> So it looks like both the lines that check #ifdef WIN32 are evaluating
>>> as false, even though I'm in win32. I don't know much about C++. As a
>>> hack, replacing vsnprintf with _vsnprintf in the else clauses gives me a
>>> successful build.
>> Hmm... I wonder if the WIN32 symbol is a Mingw32 thing and not a MS 
>> Visual Studio thing. One thing I have seen elsewhere is the use of 
>> _MSC_VER to do this. Would you mind trying:
>>
>> #ifdef WIN32 || _MSC_VER
>>
>> instead of
>>
>> #ifdef WIN32
>>
>> (I don't have a MS Visual Studio to test with myself). Maybe one of the 
>> Windows guys on this list has another idea as well.
>>
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> 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

Sorry for the delay. I gave that a try, but it didn't help. Seems that
_MSC_VER is undefined as well...
Martin
Michael Droettboom wrote:
> Martin Spacek wrote:
>> It's been a few months since I've updated and compiled from svn. I got
>> this error today from rev 3926 (in winxp using msvc71):
>>
>>> python setup.py build_ext --inplace --force
>>
>> ============================================================================ 
>>
>> BUILDING MATPLOTLIB
>> matplotlib: 0.90.1
>> python: 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC
>> v.1310 32 bit (Intel)]
>> platform: win32
>> Windows version: (5, 1, 2600, 2, 'Service Pack 2')
>>
>> REQUIRED DEPENDENCIES
>> numpy: 1.0.4.dev4155
>> freetype2: found, but unknown version (no pkg-config)
>>
>> OPTIONAL DEPENDENCIES
>> Gtk+: no
>> * Building for Gtk+ requires pygtk; you must be
>> able
>> * to "import gtk" in your build/install 
>> environment
>> Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
>> wxPython: 2.8.4.0
>> * WxAgg extension not required for wxPython 
>> >= 2.8
>> Qt: no
>> Qt4: no
>> Cairo: no
>> libpng: found, but unknown version (no pkg-config)
>>
>> [Edit setup.cfg to suppress the above messages]
>> ============================================================================ 
>>
>> running build_ext
>> No module named msvccompiler in numpy.distutils; trying from distutils
>> building 'matplotlib.ft2font' extension
>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>> Iwin32_static\include\freetype2 -I.\freetype2 -IC:\bin\Python25\include
>> -IC:\bin\Python25\PC /Tpsrc/ft2font.cpp /Fobuild
>> \temp.win32-2.5\Release\src/ft2font.obj
>> Found executable C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe
>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>> Iwin32_static\include\freetype2 -I.\freetype2 -IC:\bin\Python25\include
>> -IC:\bin\Python25\PC /Tpsrc/mplutils.cpp /Fobuil
>> d\temp.win32-2.5\Release\src/mplutils.obj
>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>> Iwin32_static\include\freetype2 -I.\freetype2 -IC:\bin\Python25\include
>> -IC:\bin\Python25\PC /TpCXX\cxxsupport.cxx /Fobu
>> ild\temp.win32-2.5\Release\CXX\cxxsupport.obj
>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>> Iwin32_static\include\freetype2 -I.\freetype2 -IC:\bin\Python25\include
>> -IC:\bin\Python25\PC /TpCXX\cxx_extensions.cxx /
>> Fobuild\temp.win32-2.5\Release\CXX\cxx_extensions.obj
>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>> Iwin32_static\include\freetype2 -I.\freetype2 -IC:\bin\Python25\include
>> -IC:\bin\Python25\PC /TpCXX\IndirectPythonInterf
>> ace.cxx /Fobuild\temp.win32-2.5\Release\CXX\IndirectPythonInterface.obj
>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>> Iwin32_static\include\freetype2 -I.\freetype2 -IC:\bin\Python25\include
>> -IC:\bin\Python25\PC /TcCXX\cxxextensions.c /Fob
>> uild\temp.win32-2.5\Release\CXX\cxxextensions.obj
>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\link.exe /DLL /nologo
>> /INCREMENTAL:NO /LIBPATH:win32_static\lib /LIBPAT
>> H:C:\bin\Python25\libs /LIBPATH:C:\bin\Python25\PCBuild freetype.lib
>> z.lib /EXPORT:initft2font build\temp.win32-2.5\Rele
>> ase\src/ft2font.obj build\temp.win32-2.5\Release\src/mplutils.obj
>> build\temp.win32-2.5\Release\CXX\cxxsupport.obj build\
>> temp.win32-2.5\Release\CXX\cxx_extensions.obj
>> build\temp.win32-2.5\Release\CXX\IndirectPythonInterface.obj 
>> build\temp.wi
>> n32-2.5\Release\CXX\cxxextensions.obj /OUT:lib\matplotlib\ft2font.pyd
>> /IMPLIB:build\temp.win32-2.5\Release\src\ft2font.l
>> ib
>> Found executable C:\bin\Microsoft Visual Studio .NET 
>> 2003\Vc7\bin\link.exe
>> building 'matplotlib.ttconv' extension
>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>> IC:\bin\Python25\include -IC:\bin\Python25\PC /Tpsrc/_ttconv.cpp
>> /Fobuild\temp.win32-2.5\Release\src/_ttconv.obj
>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>> IC:\bin\Python25\include -IC:\bin\Python25\PC /Tpttconv/pprdrv_tt.cpp
>> /Fobuild\temp.win32-2.5\Release\ttconv/pprdrv_tt.o
>> bj
>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>> IC:\bin\Python25\include -IC:\bin\Python25\PC /Tpttconv/pprdrv_tt2.cpp
>> /Fobuild\temp.win32-2.5\Release\ttconv/pprdrv_tt2
>> .obj
>> C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox
>> /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -
>> IC:\bin\Python25\include -IC:\bin\Python25\PC /Tpttconv/ttutil.cpp
>> /Fobuild\temp.win32-2.5\Release\ttconv/ttutil.obj
>> ttutil.cpp
>> ttconv\ttutil.cpp(38) : error C3861: 'vsnprintf': identifier not found,
>> even with argument-dependent lookup
>> ttconv\ttutil.cpp(45) : error C3861: 'vsnprintf': identifier not found,
>> even with argument-dependent lookup
>> error: Command "C:\bin\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe
>> /c /nologo /Ox /MD /W3 /GX /DNDEBUG -Iwin32_stat
>> ic\include -I. -IC:\bin\Python25\include -IC:\bin\Python25\PC
>> /Tpttconv/ttutil.cpp /Fobuild\temp.win32-2.5\Release\ttcon
>> v/ttutil.obj" failed with exit status 2
>>
>>
>>
>> The latest change for ttutil.cpp was:
>>
>> Revision: 3696
>> Author: cmoad
>> Date: 5:53:21 AM, Friday, August 10, 2007
>> Message:
>> added win32 checks for vsnprintf which is _vsnprintf on windows
>> ----
>> Modified : /trunk/matplotlib/ttconv/ttutil.cpp
>>
>> So it looks like both the lines that check #ifdef WIN32 are evaluating
>> as false, even though I'm in win32. I don't know much about C++. As a
>> hack, replacing vsnprintf with _vsnprintf in the else clauses gives me a
>> successful build.
> 
> Hmm... I wonder if the WIN32 symbol is a Mingw32 thing and not a MS 
> Visual Studio thing. One thing I have seen elsewhere is the use of 
> _MSC_VER to do this. Would you mind trying:
> 
> #ifdef WIN32 || _MSC_VER
> 
> instead of
> 
> #ifdef WIN32
> 
> (I don't have a MS Visual Studio to test with myself). Maybe one of the 
> Windows guys on this list has another idea as well.
> 

John Hunter skrev:
> On 10/11/07, Michael Droettboom <md...@st...> wrote:
>> An an extra data point, the attached script runs for over 1000
>> iterations on Linux. By no means am I suggesting that as a fix ;)
>> ...just a data point for someone on Windows that this is probably
>> Windows-specific.
> 
> I also ran to 1000 on solaris -- make sure your build is clean, eg by
> removing both the "build" subdirectory and the mpl install directory
> when compiling matplotlib. Also, it would be interesting to know if
> you get this problem in the Agg or PS backend, eg when just saving
> figures and not displaying them in a GUI.
> 
My build was done on after deleting build and dist. I usually have 
build/lib-win32-2.4 on my python path, i.e. I do not run the install step.
However I just discovered another thing that may narrow the problem 
down. If I delete the fontManager.cache file I get the crash immidiately 
on startup at the import of pylab, the only information is the same 
messagebox as before.
Keeping the fontManager.cache file I reran the script for different 
backends both with and without the pylab.ion() line in the script.
	ion		ioff
TkAgg	63 (1)		999
WX	390 (2)		999
WXAgg	57 (3)		999
Agg	999		999
(1)
Fatal Python error: PyEval_RestoreThread: NULL tstate
This application has requested the Runtime to terminate it in an unusual 
way.
Please contact the application's support team for more information.
(2)
Traceback (most recent call last):
 File "bugtest-matplotlib.py", line 13, in ?
 pylab.plot(x,sin(random.random()*pi+x*random.random()))
 File 
"c:\python\external\matplotlib\build\lib.win32-2.4\matplotlib\pyplot.py", 
line 1798, in plot
 draw_if_interactive()
 File 
"c:\python\external\matplotlib\build\lib.win32-2.4\matplotlib\backends\backend_wx.py", 
line 1
217, in draw_if_interactive
 figManager.canvas.draw()
 File 
"c:\python\external\matplotlib\build\lib.win32-2.4\matplotlib\backends\backend_wx.py", 
line 9
48, in draw
 self.figure.draw(self.renderer)
 File 
"c:\python\external\matplotlib\build\lib.win32-2.4\matplotlib\figure.py", 
line 612, in draw
 for a in self.axes: a.draw(renderer)
 File 
"c:\python\external\matplotlib\build\lib.win32-2.4\matplotlib\axes.py", 
line 1338, in draw
 a.draw(renderer)
 File 
"c:\python\external\matplotlib\build\lib.win32-2.4\matplotlib\axis.py", 
line 593, in draw
 tick.draw(renderer)
 File 
"c:\python\external\matplotlib\build\lib.win32-2.4\matplotlib\axis.py", 
line 167, in draw
 if self.tick1On: self.tick1line.draw(renderer)
 File 
"c:\python\external\matplotlib\build\lib.win32-2.4\matplotlib\lines.py", 
line 526, in draw
 gc = renderer.new_gc()
 File 
"c:\python\external\matplotlib\build\lib.win32-2.4\matplotlib\backends\backend_wx.py", 
line 3
97, in new_gc
 self.gc.select()
 File 
"c:\python\external\matplotlib\build\lib.win32-2.4\matplotlib\backends\backend_wx.py", 
line 5
16, in select
 self.SelectObject(self.bitmap)
 File "C:\Python24\Lib\site-packages\wx-2.8-msw-unicode\wx\_gdi.py", 
line 4768, in SelectObject
 return _gdi_.MemoryDC_SelectObject(*args, **kwargs)
wx._core.PyAssertionError: C++ assertion "m_refData && 
m_refData->GetRefCount() == 1" failed at ..\.
.\src\common\object.cpp(347) in wxObject::AllocExclusive(): 
wxObject::AllocExclusive() failed.
(3)
No output at all

You're right I'm stuck on windows. I just realised I forgot to say that 
I'm using python 2.4.
/Jörgen
Michael Droettboom skrev:
> An an extra data point, the attached script runs for over 1000 
> iterations on Linux. By no means am I suggesting that as a fix ;) 
> ...just a data point for someone on Windows that this is probably 
> Windows-specific.
> 
> Cheers,
> Mike
> 
> Jörgen Stenarson wrote:
>> Hi,
>>
>> I have a problem with matplotlib crashing with a ref count assertion 
>> error. I see this problem intermittently both when using ipython using 
>> %run to execute plot scripts many times and when embedding a plot in a 
>> Tk application.
>> In both cases I use TkAgg as a backend I have compiled matplotlib 
>> r3933 using mingw32 on windows using the win32_static library.
>>
>> The smallest self contained example I have been able to come up with 
>> is this:
>>
>> import random,time
>> from numpy import pi,arange,sin
>> import pylab
>>
>> pylab.ion()
>> x=arange(0,6*pi,0.1)
>> for i in range(1000):
>> print i
>> pylab.cla()
>> for i in range(1):
>> pylab.plot(x,sin(random.random()*pi+x*random.random()))
>>
>> which when executed generates the following output. Running this 
>> script several times I get the crash after around 60 iterations. On 
>> crash I also a messagebox, see attached png file.
>>
>> Does anyone else see this? What can I do to help narrow down this bug.
>>
>> /Jörgen
>>
>>
>> C:\python>python bugtest-matplotlib.py
>> 0
>> 1
>> 2
>> 3
>> 4
>> 5
>> 6
>> 7
>> 8
>> 9
>> 10
>> 11
>> 12
>> 13
>> 14
>> 15
>> 16
>> 17
>> 18
>> 19
>> 20
>> 21
>> 22
>> 23
>> 24
>> 25
>> 26
>> 27
>> 28
>> 29
>> 30
>> 31
>> 32
>> 33
>> 34
>> 35
>> 36
>> 37
>> 38
>> 39
>> 40
>> 41
>> 42
>> 43
>> 44
>> 45
>> 46
>> 47
>> 48
>> 49
>> 50
>> 51
>> 52
>> 53
>> 54
>> 55
>> 56
>> 57
>> 58
>> 59
>> 60
>> 61
>> 62
>> 63
>> Fatal Python error: PyEval_RestoreThread: NULL tstate
>>
>> This application has requested the Runtime to terminate it in an 
>> unusual way.
>> Please contact the application's support team for more information.
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems? Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

On 10/11/07, Michael Droettboom <md...@st...> wrote:
> An an extra data point, the attached script runs for over 1000
> iterations on Linux. By no means am I suggesting that as a fix ;)
> ...just a data point for someone on Windows that this is probably
> Windows-specific.
I also ran to 1000 on solaris -- make sure your build is clean, eg by
removing both the "build" subdirectory and the mpl install directory
when compiling matplotlib. Also, it would be interesting to know if
you get this problem in the Agg or PS backend, eg when just saving
figures and not displaying them in a GUI.
JDH