matplotlib-devel Mailing List for matplotlib (Page 3)

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
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

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.

On 10/9/07, Doug Hellmann <dou...@py...> wrote:
> I'm working on a column about scientific computing tools written in
> Python. I intend to mention matplotlib and give a brief
> description. I would like to include this image: http://
> matplotlib.sourceforge.net/screenshots/contour_small.png as an
> illustration with the text.
>
> I need a contact who can grant me permission to use that image. Can
> someone on this list do that, or point me in the direction of the
> appropriate person?
The contact person is Jeff Whitaker <js...@fa...>. You may
want to use a higher resolution version of the image though. Be sure
to post a link to the article for us if there is a publicly available
version.
Thanks,
JDH

I'm working on a column about scientific computing tools written in 
Python. I intend to mention matplotlib and give a brief 
description. I would like to include this image: http:// 
matplotlib.sourceforge.net/screenshots/contour_small.png as an 
illustration with the text.
I need a contact who can grant me permission to use that image. Can 
someone on this list do that, or point me in the direction of the 
appropriate person?
Thanks,
Doug Hellmann
Technical Editor
Python Magazine

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.
> Also, perhaps the pre-built freetype and libpng static libraries should
> be updated in http://matplotlib.sourceforge.net/win32_static_vs.tar.gz
> to get rid of the "found, but unknown version (no pkg-config)" warnings?
I'm not sure that's possible. What that message means is that it 
couldn't use pkg-config (a standard Unix-y tool for finding build 
requirements) to find those libraries, which also provides the 
matplotlib build with version information. It would be difficult to get 
version information out of the header files otherwise. It's unlikely to 
have pkg-config on Windows, if not using Cygwin or Mingw. We could hide 
those warnings when building with MS Visual Studio, but I actually think 
it's useful to know that pkg-config was not used to find the library. 
We certainly could reword the warning, however, if you have any suggestions.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hmm, that fix was specifically for visual studio. The "#ifdef WIN32"
worked for my build, but possible that is the wrong constant to check
for in visual studio? I'll take a look again.
- Charlie
On 10/5/07, Martin Spacek <sc...@ms...> 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.
>
> Also, perhaps the pre-built freetype and libpng static libraries should
> be updated in http://matplotlib.sourceforge.net/win32_static_vs.tar.gz
> to get rid of the "found, but unknown version (no pkg-config)" warnings?
>
> Cheers,
>
> Martin
>
>
> -------------------------------------------------------------------------
> 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
>

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.
Also, perhaps the pre-built freetype and libpng static libraries should
be updated in http://matplotlib.sourceforge.net/win32_static_vs.tar.gz
to get rid of the "found, but unknown version (no pkg-config)" warnings?
Cheers,
Martin

Eric Firing wrote:
> Ted Drain wrote:
>> John,
>> I think keeping the existing API is probably a good idea. What about 
>> something like this:
>>
>> - Keep xlim and viewlim as they are.
>>
>> - Add xbound() (or maybe a better name) that returns (x1,x2) where x1 
>> < x2.
>>
>> - Add set_xbound(x1,x2) that takes x1<x2, checks the inversion flag, 
>> and then calls set_xlim() w/ the args in the proper order.
> 
> The fundamental object containing the relevant information is the 
> Interval instance. Instead of having a proliferation of flags and 
> functions at the python level, I am thinking about adding a few very 
> simple methods to the Interval object. Maybe
> 
> swap() to reverse the order of the bounds
> increasing() to yield True if val2 >= val1
> 
> Your xbound and set_xbound functionality could also be done this way, as 
> Interval methods.
> 
> 
> Mike, how would this fit in with your reworking of transforms?
I don't anticipate any problems with that approach.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

All,
Based on what everyone has been saying I have submitted an update to axes.py that reverts the get/set xlim/ylim methods to their
original state with their original interface. I have removed the state flag that keeps track of inverted axes.
Currently I have added the method get/set xbound/ybound that handles getting and setting of the upper and lower bounds and will
handle inverted axes. I have made a couple of changes within the Axes class to now call the xbound/ybound methods so that the
handling of inversion is automatic. This at least solves the immediate problems and provides some level of protection by giving a
"safe" method to call when writing methods that deal with axes limits.
Let me know what you think.
--James Evans
> -----Original Message-----
> From: Ted Drain [mailto:ted...@jp...]
> Sent: Thursday, October 04, 2007 2:34 PM
> To: Eric Firing
> Cc: James Evans; John Hunter; matplotlib development list
> Subject: Re: [matplotlib-devel] API additions
> 
> Sounds fine - I don't think we care too much about the "how". I
> talked w/ James and as far as we know, the aspect code is the only
> area that's having a problem right now (James is going to submit a
> patch to that to handle x1>x2 today).
> 
> Since we do these plots all the time, we've just seen a number of
> problems come up as new features get added and people forget that
> x1 > x2 is a possibility. We were just trying to think of ways of
> "future proofing" the new system by making it more obvious that this
> case does show up. It might be able to be handled by some extra
> comments in the existing code so that people who are looking for
> examples would get a reminder that this case has to be handled.
> 
> Ted
> 
> At 02:11 PM 10/4/2007, Eric Firing wrote:
> >Ted Drain wrote:
> > > John,
> > > I think keeping the existing API is probably a good idea. What about
> > > something like this:
> > >
> > > - Keep xlim and viewlim as they are.
> > >
> > > - Add xbound() (or maybe a better name) that returns (x1,x2) where x1 < x2.
> > >
> > > - Add set_xbound(x1,x2) that takes x1<x2, checks the inversion flag, and
> > > then calls set_xlim() w/ the args in the proper order.
> >
> >The fundamental object containing the relevant information is the
> >Interval instance. Instead of having a proliferation of flags and
> >functions at the python level, I am thinking about adding a few very
> >simple methods to the Interval object. Maybe
> >
> >swap() to reverse the order of the bounds
> >increasing() to yield True if val2 >= val1
> >
> >Your xbound and set_xbound functionality could also be done this way, as
> >Interval methods.
> >
> >
> >Mike, how would this fit in with your reworking of transforms?
> >
> >Eric
> >
> > >
> > > - Change the existing axis code that messes w/ bounds (autoscale, aspect
> > > ratio, etc) to use xbound. These algorithm can then be written so
> > > they're independent of the order of x1 and x2 and they won't flip the
> > > bounds back if the inversion flag is set.
> > >
> > > Ted
> >
> >-------------------------------------------------------------------------
> >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
> 
> Ted Drain Jet Propulsion Laboratory ted...@jp...
> 

Sounds fine - I don't think we care too much about the "how". I 
talked w/ James and as far as we know, the aspect code is the only 
area that's having a problem right now (James is going to submit a 
patch to that to handle x1>x2 today).
Since we do these plots all the time, we've just seen a number of 
problems come up as new features get added and people forget that 
x1 > x2 is a possibility. We were just trying to think of ways of 
"future proofing" the new system by making it more obvious that this 
case does show up. It might be able to be handled by some extra 
comments in the existing code so that people who are looking for 
examples would get a reminder that this case has to be handled.
Ted
At 02:11 PM 10/4/2007, Eric Firing wrote:
>Ted Drain wrote:
> > John,
> > I think keeping the existing API is probably a good idea. What about
> > something like this:
> >
> > - Keep xlim and viewlim as they are.
> >
> > - Add xbound() (or maybe a better name) that returns (x1,x2) where x1 < x2.
> >
> > - Add set_xbound(x1,x2) that takes x1<x2, checks the inversion flag, and
> > then calls set_xlim() w/ the args in the proper order.
>
>The fundamental object containing the relevant information is the
>Interval instance. Instead of having a proliferation of flags and
>functions at the python level, I am thinking about adding a few very
>simple methods to the Interval object. Maybe
>
>swap() to reverse the order of the bounds
>increasing() to yield True if val2 >= val1
>
>Your xbound and set_xbound functionality could also be done this way, as
>Interval methods.
>
>
>Mike, how would this fit in with your reworking of transforms?
>
>Eric
>
> >
> > - Change the existing axis code that messes w/ bounds (autoscale, aspect
> > ratio, etc) to use xbound. These algorithm can then be written so
> > they're independent of the order of x1 and x2 and they won't flip the
> > bounds back if the inversion flag is set.
> >
> > Ted
>
>-------------------------------------------------------------------------
>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
Ted Drain Jet Propulsion Laboratory ted...@jp... 

Ted Drain wrote:
> John,
> I think keeping the existing API is probably a good idea. What about 
> something like this:
> 
> - Keep xlim and viewlim as they are.
> 
> - Add xbound() (or maybe a better name) that returns (x1,x2) where x1 < x2.
> 
> - Add set_xbound(x1,x2) that takes x1<x2, checks the inversion flag, and 
> then calls set_xlim() w/ the args in the proper order.
The fundamental object containing the relevant information is the 
Interval instance. Instead of having a proliferation of flags and 
functions at the python level, I am thinking about adding a few very 
simple methods to the Interval object. Maybe
swap() to reverse the order of the bounds
increasing() to yield True if val2 >= val1
Your xbound and set_xbound functionality could also be done this way, as 
Interval methods.
Mike, how would this fit in with your reworking of transforms?
Eric
> 
> - Change the existing axis code that messes w/ bounds (autoscale, aspect 
> ratio, etc) to use xbound. These algorithm can then be written so 
> they're independent of the order of x1 and x2 and they won't flip the 
> bounds back if the inversion flag is set.
> 
> Ted

Ted Drain wrote:
> John,
> I think that the problem isn't doing the inversion - it's keeping it. 
> Calling set_xlim() to invert is fine - but it never seems to stay that 
> way. There is a lot of code (resizing, autoscaling, labelling, etc) 
> that has a tendency to flip the axis back to it's 'un-inverted' state. 
> The idea behind having a flag on the axis itself is so that other code 
> can check that easily to see what the state of the axis is.
> 
> We do a lot of plots that require an inverted axis and we've had tons of 
> problems keeping the axis inverted (which is where the idea for the flag 
> came from). It seems like people forget that this is possible and add 
> code that assumes that xmin < xmax which then ends up flipping the axis 
> back to it's "normal" state (this happens in the aspect ratio code for 
> example).
OK, I found an example with set_aspect(2, adjustable='datalim').
I would still like to see as many specific examples as you can provide.
Eric
> 
> Ted

Ted Drain wrote:
> John,
> I think keeping the existing API is probably a good idea. What about 
> something like this:
> 
> - Keep xlim and viewlim as they are.
> 
> - Add xbound() (or maybe a better name) that returns (x1,x2) where x1 < x2.
> 
> - Add set_xbound(x1,x2) that takes x1<x2, checks the inversion flag, and 
> then calls set_xlim() w/ the args in the proper order.
> 
> - Change the existing axis code that messes w/ bounds (autoscale, aspect 
> ratio, etc) to use xbound. These algorithm can then be written so 
> they're independent of the order of x1 and x2 and they won't flip the 
> bounds back if the inversion flag is set.
I'm not sure whether additional flags and functions are even needed to 
clean up the problems, but they might make it easier. I can take a look 
at this over the weekend. The problems may well be in code I wrote 
(like aspect ratio handling). I would be inclined to try to clean up the 
naming--if what is really meant in the code is "left", not "xmin", then 
that is what it should be called. I don't think fixing that will be too 
big a deal.
Ted, if you can supply some simple examples that illustrate the bugs, 
that would be most helpful. (Apologies if you have already done so and I 
missed it.)
Changing the API is still on the table, but I would rather see first 
whether we can come up with a clean solution using the existing API.
Eric
> 
> Ted
> 
> 
> At 08:05 AM 10/4/2007, John Hunter wrote:
>> On 10/4/07, Ted Drain <ted...@jp...> wrote:
>> > John,
>> > I think that the problem isn't doing the inversion - it's keeping
>> > it. Calling set_xlim() to invert is fine - but it never seems to
>> > stay that way. There is a lot of code (resizing, autoscaling,
>> > labelling, etc) that has a tendency to flip the axis back to it's
>> > 'un-inverted' state. The idea behind having a flag on the axis
>> > itself is so that other code can check that easily to see what the
>> > state of the axis is.
>> >
>>
>> > We do a lot of plots that require an inverted axis and we've had tons
>> > of problems keeping the axis inverted (which is where the idea for
>> > the flag came from). It seems like people forget that this is
>> > possible and add code that assumes that xmin < xmax which then ends
>> > up flipping the axis back to it's "normal" state (this happens in the
>> > aspect ratio code for example).
>>
>> I see -- I missed James' original email describing the motivation for
>> this flag because it was in spam quarantine (I think he posted from a
>> non-subscribed address). As I was just clearing out the spam, I
>> noticed it, and now better understand what you are trying to do. It
>> seems like a reasonable use case.
>>
>> If I am reading this right, there is no way to support this kind of
>> behavior *and* not break existing code. If we want to go this route,
>> I don't mind breaking existing code as long as we do it cleanly. Eg,
>> I think xmin and xmax should always be in order (calls to
>> set_xlim(xmax, xmin) would raise a helpful exception like "call
>> ax.invert_xaxis instead") and we would need to make sure that the
>> viewlim are still reversed per Michael's request. And we would need a
>> clean way to toggle back. In this view:
>>
>> ax.xaxis_invert() # turns inversion on and off
>> ax.get_xlim() # always returns xmin, xmax
>> ax.set_xlim(blah) # requires xmin<xmax
>>
>> and viewlim behave as before.
>>
>> This would also satisfy Eric's point that xmin and xmax are poorly named.
>>
>> The one thing I find potentially confusing about Jame's original post
>> is that set_xlim can be out of order (xmin>xmax) while get_xlim always
>> returns ordered values.
>>
>> For the record, I almost never use inverted axes so we should hear
>> more from those who do....
>>
>> JDH
> 
> Ted Drain Jet Propulsion Laboratory ted...@jp... 
> 

John,
I think keeping the existing API is probably a good idea. What about 
something like this:
- Keep xlim and viewlim as they are.
- Add xbound() (or maybe a better name) that returns (x1,x2) where x1 < x2.
- Add set_xbound(x1,x2) that takes x1<x2, checks the inversion flag, 
and then calls set_xlim() w/ the args in the proper order.
- Change the existing axis code that messes w/ bounds (autoscale, 
aspect ratio, etc) to use xbound. These algorithm can then be 
written so they're independent of the order of x1 and x2 and they 
won't flip the bounds back if the inversion flag is set.
Ted
At 08:05 AM 10/4/2007, John Hunter wrote:
>On 10/4/07, Ted Drain <ted...@jp...> wrote:
> > John,
> > I think that the problem isn't doing the inversion - it's keeping
> > it. Calling set_xlim() to invert is fine - but it never seems to
> > stay that way. There is a lot of code (resizing, autoscaling,
> > labelling, etc) that has a tendency to flip the axis back to it's
> > 'un-inverted' state. The idea behind having a flag on the axis
> > itself is so that other code can check that easily to see what the
> > state of the axis is.
> >
>
> > We do a lot of plots that require an inverted axis and we've had tons
> > of problems keeping the axis inverted (which is where the idea for
> > the flag came from). It seems like people forget that this is
> > possible and add code that assumes that xmin < xmax which then ends
> > up flipping the axis back to it's "normal" state (this happens in the
> > aspect ratio code for example).
>
>I see -- I missed James' original email describing the motivation for
>this flag because it was in spam quarantine (I think he posted from a
>non-subscribed address). As I was just clearing out the spam, I
>noticed it, and now better understand what you are trying to do. It
>seems like a reasonable use case.
>
>If I am reading this right, there is no way to support this kind of
>behavior *and* not break existing code. If we want to go this route,
>I don't mind breaking existing code as long as we do it cleanly. Eg,
>I think xmin and xmax should always be in order (calls to
>set_xlim(xmax, xmin) would raise a helpful exception like "call
>ax.invert_xaxis instead") and we would need to make sure that the
>viewlim are still reversed per Michael's request. And we would need a
>clean way to toggle back. In this view:
>
> ax.xaxis_invert() # turns inversion on and off
> ax.get_xlim() # always returns xmin, xmax
> ax.set_xlim(blah) # requires xmin<xmax
>
>and viewlim behave as before.
>
>This would also satisfy Eric's point that xmin and xmax are poorly named.
>
>The one thing I find potentially confusing about Jame's original post
>is that set_xlim can be out of order (xmin>xmax) while get_xlim always
>returns ordered values.
>
>For the record, I almost never use inverted axes so we should hear
>more from those who do....
>
>JDH
Ted Drain Jet Propulsion Laboratory ted...@jp... 

On 10/4/07, Ted Drain <ted...@jp...> wrote:
> John,
> I think that the problem isn't doing the inversion - it's keeping
> it. Calling set_xlim() to invert is fine - but it never seems to
> stay that way. There is a lot of code (resizing, autoscaling,
> labelling, etc) that has a tendency to flip the axis back to it's
> 'un-inverted' state. The idea behind having a flag on the axis
> itself is so that other code can check that easily to see what the
> state of the axis is.
>
> We do a lot of plots that require an inverted axis and we've had tons
> of problems keeping the axis inverted (which is where the idea for
> the flag came from). It seems like people forget that this is
> possible and add code that assumes that xmin < xmax which then ends
> up flipping the axis back to it's "normal" state (this happens in the
> aspect ratio code for example).
I see -- I missed James' original email describing the motivation for
this flag because it was in spam quarantine (I think he posted from a
non-subscribed address). As I was just clearing out the spam, I
noticed it, and now better understand what you are trying to do. It
seems like a reasonable use case.
If I am reading this right, there is no way to support this kind of
behavior *and* not break existing code. If we want to go this route,
I don't mind breaking existing code as long as we do it cleanly. Eg,
I think xmin and xmax should always be in order (calls to
set_xlim(xmax, xmin) would raise a helpful exception like "call
ax.invert_xaxis instead") and we would need to make sure that the
viewlim are still reversed per Michael's request. And we would need a
clean way to toggle back. In this view:
 ax.xaxis_invert() # turns inversion on and off
 ax.get_xlim() # always returns xmin, xmax
 ax.set_xlim(blah) # requires xmin<xmax
and viewlim behave as before.
This would also satisfy Eric's point that xmin and xmax are poorly named.
The one thing I find potentially confusing about Jame's original post
is that set_xlim can be out of order (xmin>xmax) while get_xlim always
returns ordered values.
For the record, I almost never use inverted axes so we should hear
more from those who do....
JDH

John,
I think that the problem isn't doing the inversion - it's keeping 
it. Calling set_xlim() to invert is fine - but it never seems to 
stay that way. There is a lot of code (resizing, autoscaling, 
labelling, etc) that has a tendency to flip the axis back to it's 
'un-inverted' state. The idea behind having a flag on the axis 
itself is so that other code can check that easily to see what the 
state of the axis is.
We do a lot of plots that require an inverted axis and we've had tons 
of problems keeping the axis inverted (which is where the idea for 
the flag came from). It seems like people forget that this is 
possible and add code that assumes that xmin < xmax which then ends 
up flipping the axis back to it's "normal" state (this happens in the 
aspect ratio code for example).
Ted
At 07:28 AM 10/4/2007, John Hunter wrote:
>On 10/4/07, Michael Droettboom <md...@st...> wrote:
>
> > def invert_xaxis(self, invert=True):
> >
> > "Invert the x-axis if 'invert' is True."
> >
>
>I like this approach over a state flag (I agree with Eric that it
>would be nice to avoid if we can since it complicates communication
>between different parts of the Axes and Axis code). But why do we
>need an invert kwarg. I would imagine that invert_xaxis might work
>like
>
>def invert_xaxis(self):
> left, right = self.get_xlim()
> self.set_xlim(right, left)
>
>then you could toggle back and forth
>
>and xaxis_inverted would work as you propose.
>
>JDH
>
>-------------------------------------------------------------------------
>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
Ted Drain Jet Propulsion Laboratory ted...@jp... 

On 10/4/07, Michael Droettboom <md...@st...> wrote:
> def invert_xaxis(self, invert=True):
>
> "Invert the x-axis if 'invert' is True."
>
I like this approach over a state flag (I agree with Eric that it
would be nice to avoid if we can since it complicates communication
between different parts of the Axes and Axis code). But why do we
need an invert kwarg. I would imagine that invert_xaxis might work
like
def invert_xaxis(self):
 left, right = self.get_xlim()
 self.set_xlim(right, left)
then you could toggle back and forth
and xaxis_inverted would work as you propose.
JDH

On Tue, Oct 02, 2007 at 10:42:13AM -0400, Paul Kienzle wrote:
> As I was building a py2exe distribution of matplotlib, I noticed the
> function get_py2exe_datafiles() in __init__.py that is not noted on
> the FAQ. Before I update the FAQ, can you all tell me your best
> practices recommendations for wrapping matplotlib?
> 
> In particular, is there a way I can store the matplotlib data directly
> in the exe so that install is simply a matter of copying an exe file
> rather than a whole directory?
> 
> Technically this should be feasible --- freetype can load fonts
> from memory or directly from the zip file given the proper driver,
> and the various images should be similarly readable.
For the record, here is what I'm using to wrap matplotlib in py2exe.
Since I'm using the wx backend I've excluded Tkinter. 
Since numerix uses __import__, py2exe wasn't clever enough to find the 
numerix extensions, and had to be listed explicitly. Similarly 
for backends.
I'm not picking up the 14Mb of timezone info that I don't need. Maybe
want packages = ['pytz'] if your applications need it.
I haven't addressed mpl-data yet.
	- Paul
myapp.py
========
import pylab
pylab.plot(range(10),range(10))
pylab.show()
setup.py
========
from distutils.core import setup
import sys, os, py2exe
# data_files: List of datafiles that need to be explicitly included
# e.g., [('target/relative/path', ['file','list'])]
# excludes: List of modules to exclude (takes precedence over includes)
# dll_excludes: List of dlls to exclude
# includes: List of modules to include
# packages: List of packages to include
data_files = []
excludes = [ 'numarray', 'Numeric', 'Tkinter', ]
dll_excludes = [] # dlls to exclude
includes = [ 'matplotlib', 'wx', 'numpy', ]
packages = [] # May want 'wx' in packages if creating a generic environment
# Explicit package rules
if 'matplotlib' in includes:
 import matplotlib
 data_files += matplotlib.get_py2exe_datafiles()
 includes += ['matplotlib.numerix.'+pkg for pkg in
 ['ma','mlab','fft','linear_algebra','npyma','random_array']]
 includes += ['matplotlib.backends.backend_'+pkg for pkg in
 ['wx','wxagg','pdf','ps','svg','agg','agg2','emf']]
# Don't include anything explicitly excluded
includes = [x for x in includes if x not in excludes]
# Include the C/C++ runtime (there should be a way of putting these beside
# the python dll in the executable, but for now I put them in the executable
# directory. Note: the C++ runtime might be in the wx package instead of the
# python directory.
pythonpath = os.path.dirname(sys.executable)
c_runtime = pythonpath+"/MSVCR71.DLL"
cpp_runtime = pythonpath+"/MSVCP71.DLL"
data_files += [('.',[c_runtime,cpp_runtime])]
# End of configuration
py2exe_opts = dict(includes=includes, excludes=excludes,
 skip_archive=0, compressed=1,
 dll_excludes=dll_excludes, packages=packages,
 bundle_files=1, optimize=2)
setup(
 options = dict(py2exe=py2exe_opts),
 windows= ['myapp.py'], # Could be console=, depending on your app
 data_files = data_files,
 #zipfile = None, # Bundle library.zip with the executable
 )

James,
In principle, I'm not against adding a new API for this as long as the 
old one doesn't break.
I just have the usual concerns that callers of get_xlim/get_ylim don't 
break because of this. The things I've tried so far seem to be working, 
but all calls to get_xlim/get_ylim should be tested exhaustively, to 
make sure that none of them depend on xmin > xmax when the axis is inverted.
 From the point of view of the transforms refactoring megabranch I'm 
working on, my only concern is that viewLim stays as-is -- that is, if 
the axis is inverted, then the values in viewLim are also inverted. 
That appears to be how you've kept things in your change -- I'd just 
like to put in my vote for that remaining the case regardless of where 
this discussion about API goes.
There does seem to be one small logic bug in the change. If I invert 
the axis (in the old way), I can't then uninvert it in the old way:
axes().set_xlim(0.5, -0.5)
axes().set_xlim(-0.5, 0.5)
# The x-axis is still inverted
I think we have to keep this API working as-is (as it's a pretty common 
one), even if we extend it with invert_xaxis. One possible solution may 
be to not change set_xlim at all, and make get_xlim, invert_xaxis, and 
xaxis_inverted more dynamic, i.e. don't use a _invertedx flag [untested 
code warning]:
 def get_xlim(self):
	xmin, xmax = self.viewLim.intervalx().get_bounds()
	if xmax < xmin:
		return xmax, xmin
	return xmin, xmax	
 def invert_xaxis(self, invert=True): 
 "Invert the x-axis if 'invert' is True." 
	xmin, xmax = self.viewLim.intervalx().get_bounds()
	if invert:
	 if xmin < xmax:
		self.viewLim.intervalx().set_bounds(xmax, xmin) 			else:
 	 if xmax < xmin:
		self.viewLim.intervalx().set_bounds(xmax, xmin)
 def xaxis_inverted(self): 
 'Returns True if the x-axis is inverted.' 
	xmin, xmax = self.viewLim.intervalx()
	return xmax < xmin	
One very minor point: the function name "invert_xaxis", to me suggests 
that the direction of the axis will "toggle" and that two calls to 
invert_xaxis would restore it to the original state. However, I think 
the function as you designed it is more useful -- perhaps it just needs 
a different name.
I agree with Eric's comment:
 > I also thought the old scheme of xlim(5,0) was elegant; the problem was
 > that there and in related functions the variables should have been
 > called "left" and "right", not "xmin" and "xmax".
But getting out of that situation may be more trouble than it's worth...
Cheers,
Mike
Eric Firing wrote:
> James,
> 
> I see that you have implemented a strategy change in axes.py for 
> inverted axes, with corresponding additions to the API. I don't have 
> strong opinions about the strategy. Keeping track of orientation via a 
> flag is reasonable, although I'm not positive it is better, given that 
> it complicates the API. My first reaction to the new API is at best 
> lukewarm, however, so perhaps it is worth a bit of thrashing out on the 
> list.
> 
> What you have now (and similarly for yaxis):
> 
> + def invert_xaxis(self, invert=True):
> + "Invert the x-axis if 'invert' is True."
> + self._invertedx = invert
> +
> + def xaxis_inverted(self):
> + 'Returns True if the x-axis is inverted.'
> + return self._invertedx
> 
> 
> Some alternatives:
> 
> 1) Attributes (could later be properties or those terrifying traits):
> x_right=True or False
> y_up
> 
> xdir 'right' or 'normal' or True; vs 'left' or 'reversed' or False
> and similarly for ydir
> 
> 2) Getters and setters:
> set_xdir() with values as some selection from above
> ydir() similar
> set_xRight(False)
> yUp(False)
> 
> Matlab uses "xdir", "reversed" etc.
> 
> I like the idea of being more descriptive, with "right"|"left" and 
> "up"|"down", either as values or in the function and/or attribute names.
> 
> I also thought the old scheme of xlim(5,0) was elegant; the problem was 
> that there and in related functions the variables should have been 
> called "left" and "right", not "xmin" and "xmax".
> 
> I could probably come up with more possibilities, but first I want to 
> see whether anyone agrees that this might be a good time to think about 
> API strategy and consistency.
> 
> Eric
> 
> -------------------------------------------------------------------------
> 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

James,
I see that you have implemented a strategy change in axes.py for 
inverted axes, with corresponding additions to the API. I don't have 
strong opinions about the strategy. Keeping track of orientation via a 
flag is reasonable, although I'm not positive it is better, given that 
it complicates the API. My first reaction to the new API is at best 
lukewarm, however, so perhaps it is worth a bit of thrashing out on the 
list.
What you have now (and similarly for yaxis):
+ def invert_xaxis(self, invert=True):
+ "Invert the x-axis if 'invert' is True."
+ self._invertedx = invert
+
+ def xaxis_inverted(self):
+ 'Returns True if the x-axis is inverted.'
+ return self._invertedx
Some alternatives:
1) Attributes (could later be properties or those terrifying traits):
 x_right=True or False
 y_up
 xdir 'right' or 'normal' or True; vs 'left' or 'reversed' or False
and similarly for ydir
2) Getters and setters:
 set_xdir() with values as some selection from above
 ydir() similar
 set_xRight(False)
 yUp(False)
Matlab uses "xdir", "reversed" etc.
I like the idea of being more descriptive, with "right"|"left" and 
"up"|"down", either as values or in the function and/or attribute names.
I also thought the old scheme of xlim(5,0) was elegant; the problem was 
that there and in related functions the variables should have been 
called "left" and "right", not "xmin" and "xmax".
I could probably come up with more possibilities, but first I want to 
see whether anyone agrees that this might be a good time to think about 
API strategy and consistency.
Eric

Darren Dale <dd...@co...> writes:
> In an earlier post you mentioned that transformations of Type-1 fonts
> probably requires a complete type-1 parser. Do you mean matplotlib's
> ft2font is missing some functionality?
I don't think freetype has any support for modifying and outputting
fonts. Actually the transformations are probably just a matter of
locating and modifying the FontMatrix entry in the cleartext part of the
pfb file, but subsetting (to reduce file sizes) is more involved.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On Sunday 30 September 2007 04:16:08 pm Jouni K. Sepp=E4nen wrote:
> It turns out (thanks to Darren for the debug info) that AFM files do not
> exist for all fonts in all current TeX distributions, so I have modified
> the pdf backend to not use them. This loses some information that is
> required by the pdf spec (such as the x-height and stem widths of the
> embedded font) but at least in some tests Preview.app and Adobe Reader
> don't seem to mind.
Jouni, I just ran tex_demo.py, which I modified to yield a pdf. The result=
s=20
are really impressive. In an earlier post you mentioned that transformation=
s=20
of Type-1 fonts probably requires a complete type-1 parser. Do you mean=20
matplotlib's ft2font is missing some functionality?
Darren

Paul Kienzle wrote:
> Technically this should be feasible --- freetype can load fonts
> from memory or directly from the zip file given the proper driver,
> and the various images should be similarly readable.
ttconv will have to be likewise updated (probably to accept a Python 
file-like object). It is currently hardcoded to only accept file paths 
and do its own reading using the C stdlib.
The Cairo backend will also be unable to use fonts this way (but that's 
only a minor change from how it is now -- Cairo can only read fonts from 
normal OS-specific font installation directories anyway.)
Personally, I'd prefer to see the fonts installed in a OS standard place 
-- then matplotlib could use fontconfig effectively on X11 systems and 
Cairo would function like all the other backends. But that probably 
means having a proper installer on Windows/Mac and being a little more 
clever with packaging on Linux.
As for images, you could take the approach suggested by wxPython's img2py:
 http://www.wxpython.org/docs/api/wx.tools.img2py-module.html
There is nothing wx-specific about the concepts there... But I'm not 
sure it's necessary if all of the backends can load images from strings 
anyway.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

As I was building a py2exe distribution of matplotlib, I noticed the
function get_py2exe_datafiles() in __init__.py that is not noted on
the FAQ. Before I update the FAQ, can you all tell me your best
practices recommendations for wrapping matplotlib?
In particular, is there a way I can store the matplotlib data directly
in the exe so that install is simply a matter of copying an exe file
rather than a whole directory?
Technically this should be feasible --- freetype can load fonts
from memory or directly from the zip file given the proper driver,
and the various images should be similarly readable.
	- Paul