matplotlib-devel Mailing List for matplotlib (Page 5)

On Fri, Feb 6, 2009 at 3:03 PM, Ryan May <rm...@gm...> wrote:
>
>
> On Fri, Feb 6, 2009 at 4:48 PM, Andrew Straw <str...@as...> wrote:
>>
>> Ryan May wrote:
>> > On Fri, Feb 6, 2009 at 3:27 PM, Andrew Straw <str...@as...
>> > <mailto:str...@as...>> wrote:
>> >
>> > Patrick,
>> >
>> > Can you see if adding "#include <stdint.h>" at the top of
>> > src/path.cpp
>> > will do the job?
>> >
>> > I'm not super-optimistic, though -- I think this is defined by the
>> > C99
>> > standard, which I'm not sure Microsoft supports.
>> >
>> >
>> > Well, we're also talking about C++ here and not C, so C99 does not
>> > apply. A quick googling around seems to indicate that some of the
>> > open source compilers support such a type, but it not standardized by
>> > C++.
>> There is no <stdint.h> or the type is not defined in stdint.h?
>>
>> Maybe as a workaround you could use mingw...
>
> I meant that uint8_t is not a standardized C++ type. If that's the case,
> wouldn't it be better to tweak the code to use something standard rather
> than just use a compiler that supports the non-standard type? Especially
> given that the official Python 2.5 build uses this compiler?
Please stick with standard types.
And MSVC 2005 and higher do have C99 support, it is just unfortunate
that it is not complete.
> Ryan
Cheers,
Michael
> --
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code
> to
> build responsive, highly engaging applications that combine the power of
> local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

On Fri, Feb 6, 2009 at 4:48 PM, Andrew Straw <str...@as...> wrote:
> Ryan May wrote:
> > On Fri, Feb 6, 2009 at 3:27 PM, Andrew Straw <str...@as...
> > <mailto:str...@as...>> wrote:
> >
> > Patrick,
> >
> > Can you see if adding "#include <stdint.h>" at the top of
> src/path.cpp
> > will do the job?
> >
> > I'm not super-optimistic, though -- I think this is defined by the
> C99
> > standard, which I'm not sure Microsoft supports.
> >
> >
> > Well, we're also talking about C++ here and not C, so C99 does not
> > apply. A quick googling around seems to indicate that some of the
> > open source compilers support such a type, but it not standardized by
> C++.
> There is no <stdint.h> or the type is not defined in stdint.h?
>
> Maybe as a workaround you could use mingw...
>
I meant that uint8_t is not a standardized C++ type. If that's the case,
wouldn't it be better to tweak the code to use something standard rather
than just use a compiler that supports the non-standard type? Especially
given that the official Python 2.5 build uses this compiler?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Ryan May wrote:
> On Fri, Feb 6, 2009 at 3:27 PM, Andrew Straw <str...@as...
> <mailto:str...@as...>> wrote:
>
> Patrick,
>
> Can you see if adding "#include <stdint.h>" at the top of src/path.cpp
> will do the job?
>
> I'm not super-optimistic, though -- I think this is defined by the C99
> standard, which I'm not sure Microsoft supports.
>
>
> Well, we're also talking about C++ here and not C, so C99 does not
> apply. A quick googling around seems to indicate that some of the
> open source compilers support such a type, but it not standardized by C++.
There is no <stdint.h> or the type is not defined in stdint.h?
Maybe as a workaround you could use mingw...

On Fri, Feb 6, 2009 at 3:27 PM, Andrew Straw <str...@as...> wrote:
> Patrick,
>
> Can you see if adding "#include <stdint.h>" at the top of src/path.cpp
> will do the job?
>
> I'm not super-optimistic, though -- I think this is defined by the C99
> standard, which I'm not sure Microsoft supports.
>
Well, we're also talking about C++ here and not C, so C99 does not apply. A
quick googling around seems to indicate that some of the open source
compilers support such a type, but it not standardized by C++.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Patrick,
Can you see if adding "#include <stdint.h>" at the top of src/path.cpp
will do the job?
I'm not super-optimistic, though -- I think this is defined by the C99
standard, which I'm not sure Microsoft supports.
-Andrew
Patrick Marsh wrote:
> Greetings,
>
> I have previously been able to build matplotlib on my Windows Vista
> machine using both Python25 and Python26. However, after my latest
> update to SVN, I'm no longer able to build matplotlib on my Windows
> machine (but am with my gentoo box). Below is the output from the
> build log using Python25 (which failed). Ryan May and I did a little
> digging we're thinking that either MSVC doesn't like uint8_t, or it
> needs some missing header that isn't already included so that it knows
> what unit8_t is.
>
> Has anyone else encountered this problem, and if so, has anyone overcome this?
>
>
> ============================================================================
> BUILDING MATPLOTLIB
> matplotlib: 0.98.6svn
> python: 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC
> v.1310 32 bit (Intel)]
> platform: win32
> Windows version: (6, 0, 6001, 2, 'Service Pack 1')
>
> REQUIRED DEPENDENCIES
> numpy: 1.3.0.dev6338
> freetype2: found, but unknown version (no pkg-config)
>
> OPTIONAL BACKEND DEPENDENCIES
> libpng: found, but unknown version (no pkg-config)
> Tkinter: Tkinter: 67737, Tk: 8.4, Tcl: 8.4
> wxPython: 2.8.9.1
> * WxAgg extension not required for wxPython >= 2.8
> Gtk+: no
> * Building for Gtk+ requires pygtk; you must be able
> * to "import gtk" in your build/install environment
> Mac OS X native: no
> Qt: no
> Qt4: no
> Cairo: no
>
> OPTIONAL DATE/TIMEZONE DEPENDENCIES
> datetime: present, version unknown
> dateutil: matplotlib will provide
> pytz: 2008c
>
> OPTIONAL USETEX DEPENDENCIES
> dvipng: no
> ghostscript: no
> latex: no
> pdftops: no
>
> [Edit setup.cfg to suppress the above messages]
> ============================================================================
> pymods ['pylab']
> packages ['matplotlib', 'matplotlib.backends',
> 'matplotlib.projections', 'mpl_toolkits', 'matplotlib.numerix',
> 'matplotlib.numerix.mlab', 'matplotlib.numerix.ma',
> 'matplotlib.numerix.npyma', 'matplotlib.numerix.linear_algebra',
> 'matplotlib.numerix.random_array', 'matplotlib.numerix.fft',
> 'matplotlib.delaunay', 'pytz', 'dateutil', 'dateutil/zoneinfo']
> running build
> running build_py
> copying lib\matplotlib\mpl-data\matplotlibrc ->
> build\lib.win32-2.5\matplotlib\mpl-data
> copying lib\matplotlib\mpl-data\matplotlib.conf ->
> build\lib.win32-2.5\matplotlib\mpl-data
> running build_ext
> building 'matplotlib._path' extension
> D:\Program Files\Microsoft Visual Studio 2003\bin\cl.exe /c /nologo
> /Ox /MD /W3 /GX /DNDEBUG
> -ID:\Python25\lib\site-packages\numpy\core\include
> -Iwin32_static\include -I.
> -ID:\Python25\lib\site-packages\numpy\core\include -Isrc
> -Iagg24/include -I. -ID:\Python25\include -ID:\Python25\PC
> /Tpsrc/path.cpp /Fobuild\temp.win32-2.5\Release\src/path.obj
> path.cpp
> src\path.cpp(356) : warning C4800: 'long' : forcing value to bool
> 'true' or 'false' (performance warning)
> src\path.cpp(566) : warning C4800: 'long' : forcing value to bool
> 'true' or 'false' (performance warning)
> src\path.cpp(867) : warning C4800: 'long' : forcing value to bool
> 'true' or 'false' (performance warning)
> src\path.cpp(1209) : error C2065: 'uint8_t' : undeclared identifier
> src\path.cpp(1209) : error C2955: 'std::vector' : use of class
> template requires template argument list
> D:\Program Files\Microsoft Visual Studio
> 2003\include\vector(896) : see declaration of 'std::vector'
> src\path.cpp(1209) : error C2955: 'std::vector' : use of class
> template requires template argument list
> D:\Program Files\Microsoft Visual Studio
> 2003\include\vector(896) : see declaration of 'std::vector'
> src\path.cpp(1226) : error C3861: 'uint8_t': identifier not found,
> even with argument-dependent lookup
> src\path.cpp(1226) : error C2955: 'std::vector' : use of class
> template requires template argument list
> D:\Program Files\Microsoft Visual Studio
> 2003\include\vector(896) : see declaration of 'std::vector'
> src\path.cpp(1226) : error C2955: 'std::vector' : use of class
> template requires template argument list
> D:\Program Files\Microsoft Visual Studio
> 2003\include\vector(896) : see declaration of 'std::vector'
> src\path.cpp(1241) : error C2662: 'std::vector<_Ty,_Ax>::reserve' :
> cannot convert 'this' pointer from 'std::vector' to
> 'std::vector<_Ty,_Ax> &'
> Reason: cannot convert from 'std::vector' to 'std::vector<_Ty,_Ax>'
> Conversion requires a second user-defined-conversion operator
> or constructor
> src\path.cpp(1310) : error C3861: 'uint8_t': identifier not found,
> even with argument-dependent lookup
> src\path.cpp(1310) : error C2955: 'std::vector' : use of class
> template requires template argument list
> D:\Program Files\Microsoft Visual Studio
> 2003\include\vector(896) : see declaration of 'std::vector'
> src\path.cpp(1310) : error C2955: 'std::vector' : use of class
> template requires template argument list
> D:\Program Files\Microsoft Visual Studio
> 2003\include\vector(896) : see declaration of 'std::vector'
> src\path.cpp(1310) : error C2133: 'codes' : unknown size
> src\path.cpp(1310) : error C2512: 'std::vector' : no appropriate
> default constructor available
> src\path.cpp(1310) : error C2262: 'codes' : cannot be destroyed
> src\path.cpp(1313) : error C3861: 'codes': identifier not found, even
> with argument-dependent lookup
> src\path.cpp(1315) : error C2662: 'std::vector<_Ty,_Ax>::size' :
> cannot convert 'this' pointer from 'std::vector' to 'const
> std::vector<_Ty,_Ax> &'
> Reason: cannot convert from 'std::vector' to 'const
> std::vector<_Ty,_Ax>'
> Conversion requires a second user-defined-conversion operator
> or constructor
> src\path.cpp(1315) : error C3861: 'codes': identifier not found, even
> with argument-dependent lookup
> src\path.cpp(1337) : error C2070: ''unknown-type'': illegal sizeof operand
> src\path.cpp(1337) : error C3861: 'codes': identifier not found, even
> with argument-dependent lookup
> src\path.cpp(1337) : error C3861: 'uint8_t': identifier not found,
> even with argument-dependent lookup error: command '"D:\Program
> Files\Microsoft Visual Studio 2003\bin\cl.exe"' failed with exit
> status 2
>
>
> 

Greetings,
I have previously been able to build matplotlib on my Windows Vista
machine using both Python25 and Python26. However, after my latest
update to SVN, I'm no longer able to build matplotlib on my Windows
machine (but am with my gentoo box). Below is the output from the
build log using Python25 (which failed). Ryan May and I did a little
digging we're thinking that either MSVC doesn't like uint8_t, or it
needs some missing header that isn't already included so that it knows
what unit8_t is.
Has anyone else encountered this problem, and if so, has anyone overcome this?
============================================================================
BUILDING MATPLOTLIB
 matplotlib: 0.98.6svn
 python: 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC
 v.1310 32 bit (Intel)]
 platform: win32
 Windows version: (6, 0, 6001, 2, 'Service Pack 1')
REQUIRED DEPENDENCIES
 numpy: 1.3.0.dev6338
 freetype2: found, but unknown version (no pkg-config)
OPTIONAL BACKEND DEPENDENCIES
 libpng: found, but unknown version (no pkg-config)
 Tkinter: Tkinter: 67737, Tk: 8.4, Tcl: 8.4
 wxPython: 2.8.9.1
 * WxAgg extension not required for wxPython >= 2.8
 Gtk+: no
 * Building for Gtk+ requires pygtk; you must be able
 * to "import gtk" in your build/install environment
 Mac OS X native: no
 Qt: no
 Qt4: no
 Cairo: no
OPTIONAL DATE/TIMEZONE DEPENDENCIES
 datetime: present, version unknown
 dateutil: matplotlib will provide
 pytz: 2008c
OPTIONAL USETEX DEPENDENCIES
 dvipng: no
 ghostscript: no
 latex: no
 pdftops: no
[Edit setup.cfg to suppress the above messages]
============================================================================
pymods ['pylab']
packages ['matplotlib', 'matplotlib.backends',
'matplotlib.projections', 'mpl_toolkits', 'matplotlib.numerix',
'matplotlib.numerix.mlab', 'matplotlib.numerix.ma',
'matplotlib.numerix.npyma', 'matplotlib.numerix.linear_algebra',
'matplotlib.numerix.random_array', 'matplotlib.numerix.fft',
'matplotlib.delaunay', 'pytz', 'dateutil', 'dateutil/zoneinfo']
running build
running build_py
copying lib\matplotlib\mpl-data\matplotlibrc ->
build\lib.win32-2.5\matplotlib\mpl-data
copying lib\matplotlib\mpl-data\matplotlib.conf ->
build\lib.win32-2.5\matplotlib\mpl-data
running build_ext
building 'matplotlib._path' extension
D:\Program Files\Microsoft Visual Studio 2003\bin\cl.exe /c /nologo
/Ox /MD /W3 /GX /DNDEBUG
-ID:\Python25\lib\site-packages\numpy\core\include
-Iwin32_static\include -I.
-ID:\Python25\lib\site-packages\numpy\core\include -Isrc
-Iagg24/include -I. -ID:\Python25\include -ID:\Python25\PC
/Tpsrc/path.cpp /Fobuild\temp.win32-2.5\Release\src/path.obj
path.cpp
src\path.cpp(356) : warning C4800: 'long' : forcing value to bool
'true' or 'false' (performance warning)
src\path.cpp(566) : warning C4800: 'long' : forcing value to bool
'true' or 'false' (performance warning)
src\path.cpp(867) : warning C4800: 'long' : forcing value to bool
'true' or 'false' (performance warning)
src\path.cpp(1209) : error C2065: 'uint8_t' : undeclared identifier
src\path.cpp(1209) : error C2955: 'std::vector' : use of class
template requires template argument list
 D:\Program Files\Microsoft Visual Studio
2003\include\vector(896) : see declaration of 'std::vector'
src\path.cpp(1209) : error C2955: 'std::vector' : use of class
template requires template argument list
 D:\Program Files\Microsoft Visual Studio
2003\include\vector(896) : see declaration of 'std::vector'
src\path.cpp(1226) : error C3861: 'uint8_t': identifier not found,
even with argument-dependent lookup
src\path.cpp(1226) : error C2955: 'std::vector' : use of class
template requires template argument list
 D:\Program Files\Microsoft Visual Studio
2003\include\vector(896) : see declaration of 'std::vector'
src\path.cpp(1226) : error C2955: 'std::vector' : use of class
template requires template argument list
 D:\Program Files\Microsoft Visual Studio
2003\include\vector(896) : see declaration of 'std::vector'
src\path.cpp(1241) : error C2662: 'std::vector<_Ty,_Ax>::reserve' :
cannot convert 'this' pointer from 'std::vector' to
'std::vector<_Ty,_Ax> &'
 Reason: cannot convert from 'std::vector' to 'std::vector<_Ty,_Ax>'
 Conversion requires a second user-defined-conversion operator
or constructor
src\path.cpp(1310) : error C3861: 'uint8_t': identifier not found,
even with argument-dependent lookup
src\path.cpp(1310) : error C2955: 'std::vector' : use of class
template requires template argument list
 D:\Program Files\Microsoft Visual Studio
2003\include\vector(896) : see declaration of 'std::vector'
src\path.cpp(1310) : error C2955: 'std::vector' : use of class
template requires template argument list
 D:\Program Files\Microsoft Visual Studio
2003\include\vector(896) : see declaration of 'std::vector'
src\path.cpp(1310) : error C2133: 'codes' : unknown size
src\path.cpp(1310) : error C2512: 'std::vector' : no appropriate
default constructor available
src\path.cpp(1310) : error C2262: 'codes' : cannot be destroyed
src\path.cpp(1313) : error C3861: 'codes': identifier not found, even
with argument-dependent lookup
src\path.cpp(1315) : error C2662: 'std::vector<_Ty,_Ax>::size' :
cannot convert 'this' pointer from 'std::vector' to 'const
std::vector<_Ty,_Ax> &'
 Reason: cannot convert from 'std::vector' to 'const
std::vector<_Ty,_Ax>'
 Conversion requires a second user-defined-conversion operator
or constructor
src\path.cpp(1315) : error C3861: 'codes': identifier not found, even
with argument-dependent lookup
src\path.cpp(1337) : error C2070: ''unknown-type'': illegal sizeof operand
src\path.cpp(1337) : error C3861: 'codes': identifier not found, even
with argument-dependent lookup
src\path.cpp(1337) : error C3861: 'uint8_t': identifier not found,
even with argument-dependent lookup error: command '"D:\Program
Files\Microsoft Visual Studio 2003\bin\cl.exe"' failed with exit
status 2
-- 
Patrick Marsh
Graduate Research Assistant
School of Meteorology
University of Oklahoma
http://www.patricktmarsh.com

Sandro Tosi wrote:
> Hi all!
> Attached a very simple patch to show "matplotlib.patches" correctly in
> the docpage above.
Checked in on the trunk and maintainance branch, so it should get picked up
whenever John pushes new docs to the website. Thanks for catching this.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi all!
Attached a very simple patch to show "matplotlib.patches" correctly in
the docpage above.
Thanks for considering,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Andrew Straw wrote:
> For the past month or two, I've been experimenting with using git to
> interact with the MPL subversion repository. The bottom line is that I I
> haven't been able to create any kind of one-to-one mapping between git
> branches and svnmerge.py branches. As we're using svnmerge.py on top of
> subversion to manage the trunk and release branches, I see this as a
> pretty fatal flaw.
> 
I basically agree with Andrew, but I want to elaborate on this point for 
those who haven't been trying this stuff out for themselves.
I documented how to use svn maintenance branches from git, and this is 
in the matplotlib source, but doesn't seem to have pushed out to the 
sourceforge site. This might be due to the automatic doc updating being 
turned off recently -- I haven't followed that thread closely. Because 
of this, I don't know if Andrew's comments aren't taking that into 
account... he could have reached the same conclusion either way... :)
It is possible to work on maintenance branches from git, but I haven't 
figured out a way to do the merging without svnmerge.py. I've worked 
this way for a while, and yes it's kludgy, but not too bad. I just keep 
a SVN checkout of the trunk around specifically for running 
svnmerge.py. So there is a one-to-one mapping between svn branches and 
git branches, it's just not a bidirectional one-to-one mapping, and 
unfortunately any advantages to git's merging tools are useless in that 
situation. But, honestly, I haven't really missed them.
> So, while I can use git to interact with the trunk (and create and use
> my own feature branches locally using git), and while using git is very
> nice for browsing history or bisecting the revision in which a bug
> cropped up, I think I've reached a point where I don't think interaction
> with svnmerge.py's branches is going to work without investing more time
> than I'm willing to give into understanding (and possibly improving)
> git-svn.
> 
My own gut feeling is that while a pure DVCS environment might be nice 
someday, the compromises of git-svn makes the whole thing sort of +0 for 
me. I can't say that I've felt much more productive using it over raw 
svn/svnmerge.py with matplotlib. So I, too, am giving it a pass for 
now, but for slightly different reasons.
> So, therefore, I'd say the issue of using a distributed version control
> system for MPL has not reached any real conclusion. Thus, we may want to
> visit this issue at some point. Perhaps once Python and/or numpy have
> made decisions. The Python-dev team seems to be working this out right
> now: http://www.python.org/dev/peps/pep-0374/
> 
I like the approach the PEP (Brett Cannon) is taking. I think it makes 
a lot of sense to let those dedicated and smart core Python folks do 
some trailblazing for us :)
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

For the past month or two, I've been experimenting with using git to
interact with the MPL subversion repository. The bottom line is that I I
haven't been able to create any kind of one-to-one mapping between git
branches and svnmerge.py branches. As we're using svnmerge.py on top of
subversion to manage the trunk and release branches, I see this as a
pretty fatal flaw.
So, while I can use git to interact with the trunk (and create and use
my own feature branches locally using git), and while using git is very
nice for browsing history or bisecting the revision in which a bug
cropped up, I think I've reached a point where I don't think interaction
with svnmerge.py's branches is going to work without investing more time
than I'm willing to give into understanding (and possibly improving)
git-svn.
So, therefore, I'd say the issue of using a distributed version control
system for MPL has not reached any real conclusion. Thus, we may want to
visit this issue at some point. Perhaps once Python and/or numpy have
made decisions. The Python-dev team seems to be working this out right
now: http://www.python.org/dev/peps/pep-0374/
-Andrew

On Wed, Feb 4, 2009 at 17:08, Jayson Barr <jb...@nm...> wrote:
> 2). If the Tk/Tcl libraries were installed from source instead of
> using the binaries you suggested installing, then it will just use the
> wrong system Framework anyway. I bet people using macports and other
> unix-like package managers on mac end up submitting a lot of bug
> reports over this.
It did for MacPorts, there where a lot of strange segfaults reported.
I have since hacked round this to force it to link against the
MacPorts provided Tcl/Tk
http://trac.macports.org/browser/trunk/dports/python/py25-matplotlib/files/patch-setupext.py.diff
Its messy but it works.
Cheers
Adam

I should also add that the reason it won't find my tclConfig.sh and
tkConfig.sh files is because they were configured/installed with the
--prefix option, but with the information from Python this is easily
resolvable.
Jayson
On Wed, Feb 4, 2009 at 3:08 PM, Jayson Barr <jb...@nm...> wrote:
> Hello,
>
> I was having trouble getting matplotlib to link to the correct Tcl and
> Tk, and as a result uncovered what I would call a bug, or at least
> unpredictable behavior.
>
> Basically, I have a custom Tcl/Tk installation, and I setup python to
> correctly find them, so I have the expectation that Matplotlib would
> use the same Tk. It can be pretty easily figured out just by
> importing Tkinter. Anyway, I looked through the matplotlib
> setupext.py and discovered that there is a function that does this,
> and correctly: query_tcltk
>
> anyway, the logic in the setupext file is such that if the
> sys.platform is 'darwin' then it will look for a Framework first
> (maybe only), and since there is always an ancient system version of
> Tcl and Tk, it will always pick those before anywhere else.
>
> The system frameworks are not complete, and I know you all recommend
> installing a binary with everything in it. Unfortunately, I did not
> have this option for unimportant reasons.
>
> Either way, I do believe that it is a bug that it does not choose the
> Tk that is being used by Python or at least trying to before using
> other available libraries and frameworks. This is easy enough for me
> to fix just for myself and at work, but I believe that you all should
> consider using Python's Tk for these reasons:
> 1). If python was installed from source, this is the one that the
> user configured python to use, and therefore is the one they trust.
> 2). If the Tk/Tcl libraries were installed from source instead of
> using the binaries you suggested installing, then it will just use the
> wrong system Framework anyway. I bet people using macports and other
> unix-like package managers on mac end up submitting a lot of bug
> reports over this.
> 3). It is just more predictable and sustainable if modules set Python
> as their standard base. Besides, it isn't much work as you already
> wrote a function to find the correct tcl and tk.
> 4). I don't mind helping write the patch. I am only worried about
> not knowing the intricacies of all the random supported platforms that
> you all look out for. For example: I know jack about Windows linking.
> Either way, I'll update it if you have someone look at it. I'll work
> on it sometimes this week when I'm not too busy at work and send it
> in.
>
> Anyway,
> I am hoping that I convinced you all, and look forward to helping fix this.
>
> Have a great rest-of-the-week!
> Jayson
>

Hello,
I was having trouble getting matplotlib to link to the correct Tcl and
Tk, and as a result uncovered what I would call a bug, or at least
unpredictable behavior.
Basically, I have a custom Tcl/Tk installation, and I setup python to
correctly find them, so I have the expectation that Matplotlib would
use the same Tk. It can be pretty easily figured out just by
importing Tkinter. Anyway, I looked through the matplotlib
setupext.py and discovered that there is a function that does this,
and correctly: query_tcltk
anyway, the logic in the setupext file is such that if the
sys.platform is 'darwin' then it will look for a Framework first
(maybe only), and since there is always an ancient system version of
Tcl and Tk, it will always pick those before anywhere else.
The system frameworks are not complete, and I know you all recommend
installing a binary with everything in it. Unfortunately, I did not
have this option for unimportant reasons.
Either way, I do believe that it is a bug that it does not choose the
Tk that is being used by Python or at least trying to before using
other available libraries and frameworks. This is easy enough for me
to fix just for myself and at work, but I believe that you all should
consider using Python's Tk for these reasons:
1). If python was installed from source, this is the one that the
user configured python to use, and therefore is the one they trust.
2). If the Tk/Tcl libraries were installed from source instead of
using the binaries you suggested installing, then it will just use the
wrong system Framework anyway. I bet people using macports and other
unix-like package managers on mac end up submitting a lot of bug
reports over this.
3). It is just more predictable and sustainable if modules set Python
as their standard base. Besides, it isn't much work as you already
wrote a function to find the correct tcl and tk.
4). I don't mind helping write the patch. I am only worried about
not knowing the intricacies of all the random supported platforms that
you all look out for. For example: I know jack about Windows linking.
 Either way, I'll update it if you have someone look at it. I'll work
on it sometimes this week when I'm not too busy at work and send it
in.
Anyway,
I am hoping that I convinced you all, and look forward to helping fix this.
Have a great rest-of-the-week!
Jayson

Another vote here for changing resolution=1 to be the default. It seems strange to plot values on a line plot and not have the values connected. At least in my area, every polar plot of real-world data we make needs to set this flag to 1 or the wrong plot is created.
Ted
> -----Original Message-----
> From: Michael Droettboom [mailto:md...@st...]
> Sent: Monday, February 02, 2009 8:28 AM
> To: James Evans; matplotlib development list
> Subject: Re: [matplotlib-devel] FW: Polar Plot Design Issues
>
> You can get this behavior you are asking for by passing "resolution=1"
> to polar. (This has been there for ages, but unfortunately wasn't
> documented until recently). We can consider making 1 the default.
>
> There are cases in which the automatic interpolation is useful, but in
> the present implementation the onus is on the user to avoid this "going
> the long way" problem.
>
> Mike
>
> James Evans wrote:
> > Michael,
> >
> > John said you were the one to go to for this one. I was wondering if
> you had any comments about the following?
> >
> > --James Evans
> >
> >
> >> All,
> >>
> >> While looking over the polar plot code I came across the following
> issue: When plotting something
> >> like 'polar( [2*pi/180, 358*pi/180], [2.0, 1.0] )' the plotted line
> will actually wrap around the
> >> origin of the plot before reaching its destination. Initially I
> thought that this was correct
> >> behavior. The line numerically passed through all angles between 2
> and 358 degrees in a linear
> >> fashion. However after consulting several colleagues and text books
> I believe that the behavior is
> >> actually wrong.
> >>
> >> It is my understanding that for polar plots there is no linear
> mapping of the axes as it is currently
> >> implemented. Rather for a simple two-point line defined in polar
> coordinates, the line should
> >> essentially take the direct route. This is highlighted by the two-
> point equation of a line for polar
> >> plots:
> >>
> >> r = ( r1*r2*sin(t2-t1) ) / ( (r1*sin(t-t1)) - (r2*sin(t-t2)) )
> >>
> >> If you were to plug in the two points given above, then increment
> theta (t) from 2 degrees to 358
> >> degrees, then convert to Cartesian cords, and plot the results, you
> will get the correct line that
> >> directly crosses the zero degree line and not one that wraps around
> the origin.
> >>
> >> Is the polar plot function implemented this way on purpose? Which
> way should it really be
> >> implemented?
> >>
> >
> >
>
> --
> 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:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.0.233 / Virus Database: 270.10.17/1931 - Release Date:
> 02/02/09 19:21:00

Hi Michael,
[Cc'ing nipy-dev, where we ran into the problem. Docs should look
fine now, if you rebuild mpl]
On Wed, Feb 4, 2009 at 7:42 AM, Michael Droettboom <md...@st...> wrote:
> There was both a parser bug (where accents were taking precedence over
> symbols), and a mapping bug (where ldots was mapped to the wrong Unicode
> code point). Both of these should now be fixed on the branch and trunk.
> Let me know if you see any further problems.
Many thanks, it all looks good now.
Cheers,
f
> Mike
>
> Fernando Perez wrote:
>>
>> Howdy,
>>
>> the attached screenshot shows the output in matplotlib of:
>>
>> In [18]: plot([1,2])
>> Out[18]: [<matplotlib.lines.Line2D object at 0x2c4e4d0>]
>>
>> In [19]: title(r'$a+b+\dots+\dot{s}+\ldots$')
>> Out[19]: <matplotlib.text.Text object at 0x2c3b090>
>>
>> along with the PostScript that Latex produces for the same equation.
>> There are two bugs, I think:
>>
>> - \dots --> \dot{s} by matplotlib
>> - \ldots rendered by MPL centered vertically, while in latex those are
>> 'lower' dots.
>>
>> Should I open an SF ticket for this, or is it a quick fix?
>>
>> Cheers,
>>
>> f

There was both a parser bug (where accents were taking precedence over 
symbols), and a mapping bug (where ldots was mapped to the wrong Unicode 
code point). Both of these should now be fixed on the branch and 
trunk. Let me know if you see any further problems.
Mike
Fernando Perez wrote:
> Howdy,
>
> the attached screenshot shows the output in matplotlib of:
>
> In [18]: plot([1,2])
> Out[18]: [<matplotlib.lines.Line2D object at 0x2c4e4d0>]
>
> In [19]: title(r'$a+b+\dots+\dot{s}+\ldots$')
> Out[19]: <matplotlib.text.Text object at 0x2c3b090>
>
> along with the PostScript that Latex produces for the same equation.
> There are two bugs, I think:
>
> - \dots --> \dot{s} by matplotlib
> - \ldots rendered by MPL centered vertically, while in latex those are
> 'lower' dots.
>
> Should I open an SF ticket for this, or is it a quick fix?
>
> Cheers,
>
> f
> 
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Howdy,
the attached screenshot shows the output in matplotlib of:
In [18]: plot([1,2])
Out[18]: [<matplotlib.lines.Line2D object at 0x2c4e4d0>]
In [19]: title(r'$a+b+\dots+\dot{s}+\ldots$')
Out[19]: <matplotlib.text.Text object at 0x2c3b090>
along with the PostScript that Latex produces for the same equation.
There are two bugs, I think:
- \dots --> \dot{s} by matplotlib
- \ldots rendered by MPL centered vertically, while in latex those are
'lower' dots.
Should I open an SF ticket for this, or is it a quick fix?
Cheers,
f

All,
I have just submitted the following two additions to the code:
1) Added ability to have X and Y Axis autoscale independently. This is handled by the addition of the following methods to Axes:
 -- Axes.get_autoscalex_on() / Axes.set_autoscalex_on( bool )
 -- Axes.get_autoscaley_on() / Axes.set_autoscaley_on( bool )
 The original method of Axes.set_autoscale_on( bool ) will set the auto scale for the x and y axes to be the same (thus keeping
its functionality exactly the same). The method Axes.get_autoscale_on() currently acts exactly as the original in that it returns
True is the x and y axes are both auto scaling (since the original behavior was that both axes had the same flag). This can be
changed however so that it returns True if either axis has auto scaling enabled.
2) Fixed a bug where any user specified formatter, locator, of axis labels would get overwritten if anything tickled the unit
handling code after they were set. In order to facilitate this I added the following methods to Axis:
 -- Axis.get_label_text() / Axis.get_label_text( str )
 Essentially user-specified explicit values will take precedence over any "default" or "smart" generated values.
--James Evans

Sorry -- that was caused by my moving of C++ code around yesterday. 
Please update and try again. You may need to remove your build 
directory and do a full rebuild.
Cheers,
Mike
Nils Wagner wrote:
> Hi all,
>
> I am using latest svn.
> My script worked until last week. If I run it now
>
> matplotlib version 0.98.6svn
> verbose.level helpful
> interactive is False
> units is False
> platform is linux2
> Using fontManager instance from 
> /data/home/nwagner/.matplotlib/fontList.cache
> Traceback (most recent call last):
> File "read_csv.py", line 2, in <module>
> from pylab import plot, show,subplot, xlabel, ylabel, 
> savefig, legend, connect, close
> File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/pylab.py", 
> line 1, in <module>
> from matplotlib.pylab import *
> File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pylab.py", 
> line 253, in <module>
> from matplotlib.pyplot import *
> File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyplot.py", 
> line 75, in <module>
> new_figure_manager, draw_if_interactive, show = 
> pylab_setup()
> File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/backends/__init__.py", 
> line 25, in pylab_setup
> globals(),locals(),[backend_name])
> File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py", 
> line 8, in <module>
> import tkagg # Paint image to Tk 
> photo blitter extension
> File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/backends/tkagg.py", 
> line 1, in <module>
> import _tkagg
> ImportError: 
> /data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/backends/_tkagg.so: 
> undefined symbol: _Z15py_convert_bboxP7_objectRdS1_S1_S1_
>
> Any idea ?
>
> Nils
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-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 all,
I am using latest svn.
My script worked until last week. If I run it now
matplotlib version 0.98.6svn
verbose.level helpful
interactive is False
units is False
platform is linux2
Using fontManager instance from 
/data/home/nwagner/.matplotlib/fontList.cache
Traceback (most recent call last):
 File "read_csv.py", line 2, in <module>
 from pylab import plot, show,subplot, xlabel, ylabel, 
savefig, legend, connect, close
 File 
"/data/home/nwagner/local/lib/python2.5/site-packages/pylab.py", 
line 1, in <module>
 from matplotlib.pylab import *
 File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pylab.py", 
line 253, in <module>
 from matplotlib.pyplot import *
 File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyplot.py", 
line 75, in <module>
 new_figure_manager, draw_if_interactive, show = 
pylab_setup()
 File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/backends/__init__.py", 
line 25, in pylab_setup
 globals(),locals(),[backend_name])
 File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py", 
line 8, in <module>
 import tkagg # Paint image to Tk 
photo blitter extension
 File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/backends/tkagg.py", 
line 1, in <module>
 import _tkagg
ImportError: 
/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/backends/_tkagg.so: 
undefined symbol: _Z15py_convert_bboxP7_objectRdS1_S1_S1_
Any idea ?
Nils

Ok. Thanks for the information. That does do exactly what I would expect. I would place my vote for having this be the default
behavior since this is what it means to say "go from point A to B" on a polar plot.
--James
> -----Original Message-----
> From: Michael Droettboom [mailto:md...@st...]
> Sent: Monday, February 02, 2009 8:28 AM
> To: James Evans; matplotlib development list
> Subject: Re: FW: Polar Plot Design Issues
> 
> You can get this behavior you are asking for by passing "resolution=1"
> to polar. (This has been there for ages, but unfortunately wasn't
> documented until recently). We can consider making 1 the default.
> 
> There are cases in which the automatic interpolation is useful, but in
> the present implementation the onus is on the user to avoid this "going
> the long way" problem.
> 
> Mike
> 
> James Evans wrote:
> > Michael,
> >
> > John said you were the one to go to for this one. I was wondering if you had any comments about the
> following?
> >
> > --James Evans
> >
> >
> >> All,
> >>
> >> While looking over the polar plot code I came across the following issue: When plotting something
> >> like 'polar( [2*pi/180, 358*pi/180], [2.0, 1.0] )' the plotted line will actually wrap around the
> >> origin of the plot before reaching its destination. Initially I thought that this was correct
> >> behavior. The line numerically passed through all angles between 2 and 358 degrees in a linear
> >> fashion. However after consulting several colleagues and text books I believe that the behavior is
> >> actually wrong.
> >>
> >> It is my understanding that for polar plots there is no linear mapping of the axes as it is
> currently
> >> implemented. Rather for a simple two-point line defined in polar coordinates, the line should
> >> essentially take the direct route. This is highlighted by the two-point equation of a line for
> polar
> >> plots:
> >>
> >> r = ( r1*r2*sin(t2-t1) ) / ( (r1*sin(t-t1)) - (r2*sin(t-t2)) )
> >>
> >> If you were to plug in the two points given above, then increment theta (t) from 2 degrees to 358
> >> degrees, then convert to Cartesian cords, and plot the results, you will get the correct line that
> >> directly crosses the zero degree line and not one that wraps around the origin.
> >>
> >> Is the polar plot function implemented this way on purpose? Which way should it really be
> >> implemented?
> >>
> >
> >
> 
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA

Michael Droettboom wrote:
> There seems to have been an indentation error there.
> 
> Please update and try again now.
> 
All seems to be fine now, thanks.
João Silva

On Mon, Feb 02, 2009 at 03:47:32PM +0000, Chris Walker wrote:
> One of the things I liked about Gael's article was its discussion of
> threading - separating the gui from the calculations from the data
> acquisition.
Thanks. Be aware that this is a rats nest, though, as threading is the
best way to reveal all the subtleties of an event loop, and the various
race conditions that you can have with it. The strong model/view
separation that is implicit in Traits allows to hide the code making the
view thread-safe in the Traits code updating implicitly the view. You can
build these constraints in your multi-threaded application (I believe I
touch a couple of words on this in my tutorial), but you have to be aware
of the problems and the good patterns to answer them.
To sum up, I am not saying this is uninteresting, on the contrary, I am
just saying that such text is hard to write (which makes a good text even
more interesting).
My 2 cents,
Gaël

There seems to have been an indentation error there.
Please update and try again now.
Thanks,
Mike
João Luís Silva wrote:
> Michael Droettboom wrote:
>> Thanks for narrowing this down. I have (hopefully) fixed this in r6864.
>>
>
> It did fix my previous examples. However it broke the other form of 
> markevery, a 2-int tuple. From the set_markevery docs:
>
> Set the markevery property to subsample the plot when using
> markers. Eg if ``markevery=5``, every 5-th marker will be
> plotted. *every* can be
>
> None
> Every point will be plotted
>
> an integer N
> Every N-th marker will be plotted starting with marker 0
>
> A length-2 tuple of integers
> every=(start, N) will start at point start and plot every 
> N-th marker
>
>
> ACCEPTS: None | integer | (startind, stride)
>
>
> I don't know if the tuple version ever worked, for I couldn't figure 
> it out, but if it is to remain it now breaks mpl with:
>
> [...]
> File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 
> 1658, in draw
> a.draw(renderer)
> File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 
> 521, in draw
> markerFunc(renderer, gc, subsampled, affine.frozen())
> UnboundLocalError: local variable 'subsampled' referenced before 
> assignment
>
>
> Example script:
> ----------------------------------
> import matplotlib.pyplot as pl
> import numpy as np
>
> pl.plot(np.arange(100.0),np.arange(100.0),marker="+",markevery=(50,5))
> pl.show()
> ----------------------------------
>
> I don't know what is the purpose and how to make the tuple version 
> work. Maybe John can shed some light into this?
>
> João Silva
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
> Thanks for narrowing this down. I have (hopefully) fixed this in r6864.
> 
It did fix my previous examples. However it broke the other form of 
markevery, a 2-int tuple. From the set_markevery docs:
 Set the markevery property to subsample the plot when using
 markers. Eg if ``markevery=5``, every 5-th marker will be
 plotted. *every* can be
 None
 Every point will be plotted
 an integer N
 Every N-th marker will be plotted starting with marker 0
 A length-2 tuple of integers
 every=(start, N) will start at point start and plot every 
N-th marker
 ACCEPTS: None | integer | (startind, stride)
I don't know if the tuple version ever worked, for I couldn't figure it 
out, but if it is to remain it now breaks mpl with:
[...]
 File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 
1658, in draw
 a.draw(renderer)
 File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 
521, in draw
 markerFunc(renderer, gc, subsampled, affine.frozen())
UnboundLocalError: local variable 'subsampled' referenced before assignment
Example script:
----------------------------------
import matplotlib.pyplot as pl
import numpy as np
pl.plot(np.arange(100.0),np.arange(100.0),marker="+",markevery=(50,5))
pl.show()
----------------------------------
I don't know what is the purpose and how to make the tuple version work. 
Maybe John can shed some light into this?
João Silva