matplotlib-users Mailing List for matplotlib (Page 9)

On Dec 5, 2007 12:53 PM, Jonathan King <ki...@mi...> wrote:
> i am having trouble installing matplotlib from source and thought i
> would post my issue here.
> i download matplotlib version 0.91.0

It looks possibly like a numpy problem (you have a pretty old version installed)

> /usr/lib/python2.3/site-packages/numpy/core/include/numpy/ufuncobject.h:9:
> error: 'intp' has not been declared

Consider first upgrading to the latest numpy.

JDH

i am having trouble installing matplotlib from source and thought i 
would post my issue here.
i download matplotlib version 0.91.0

i am using a version of scientific linux, so i can't use rpm packages 
for some packages
# uname -a
Linux labcalx 2.6.23.8 #1 Fri Nov 23 10:54:41 EST 2007 i686 i686 i386 
GNU/Linux

i verified that i had the following packages installed via rpm:
matplotlib core: zlib, zlib-devel, libpng, libpng-devel, freetype, 
freetype-devel, freetype-utils
• gtk backend: gtk2-devel, gtk+-devel, pygtk2, glib-devel, pygtk2-devel, 
gnome-libs-devel, pygtk2-libglade
• tk backend: tcl, tk, tkinter (and tk-devel)

the wxpython package is not available on rpm for me (at least not that i 
can find) so i downloaded the source. that also seemed to compile and 
install fine. the libraries are in /usr/local/lib and that path is 
referenced in file
/etc/ld.so.conf.d/wx.conf
the ldconfig command seemed to find this okay and that looks like it 
should work.

as per the user install guide, i downloaded setuptools-0.6c7-py2.3.egg 
without any trouble

here is my output from the build command:
# python setup.py build
============================================================================
BUILDING MATPLOTLIB
matplotlib: 0.91.0
python: 2.3.4 (#1, Oct 9 2006, 18:22:22) [GCC 3.4.5
20051201 (Red Hat 3.4.5-2)]
platform: linux2

REQUIRED DEPENDENCIES
numpy: 0.9.8
freetype2: 9.7.3

OPTIONAL BACKEND DEPENDENCIES
libpng: 1.2.7
Tkinter: Tkinter: 1.177, Tk: 8.4, Tcl: 8.4
wxPython: no
* wxPython not found
Gtk+: gtk+: 2.4.13, glib: 2.4.7, pygtk: 2.4.0, pygobject:
[pre-pygobject]
Qt: no
Qt4: no
Cairo: no

OPTIONAL DATE/TIMEZONE DEPENDENCIES
datetime: present, version unknown
dateutil: matplotlib will provide
pytz: matplotlib will provide

OPTIONAL USETEX DEPENDENCIES
dvipng: no
ghostscript: 7.07
latex: 3.14159
pdftops: 3.00

EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
configobj: matplotlib will provide
enthought.traits: matplotlib will provide

[Edit setup.cfg to suppress the above messages]
============================================================================
running build
running build_py
copying lib/matplotlib/mpl-data/matplotlibrc -> 
build/lib.linux-i686-2.3/matplotlib/mpl-data
copying lib/matplotlib/mpl-data/matplotlib.conf -> 
build/lib.linux-i686-2.3/matplotlib/mpl-data
running build_ext
building 'matplotlib.backends._backend_agg' extension
g++4 options: '-fno-strict-aliasing -DNDEBUG -O2 -g -pipe -m32 
-march=i386 -mtune=pentium4 -D_GNU_SOURCE -fPIC -fPIC'
creating build/temp.linux-i686-2.3
creating build/temp.linux-i686-2.3/agg23
creating build/temp.linux-i686-2.3/agg23/src
creating build/temp.linux-i686-2.3/src
creating build/temp.linux-i686-2.3/CXX
compile options: '-I/usr/lib/python2.3/site-packages/numpy/core/include 
-I/usr/include/libpng12 -I/usr/local/include -I/usr/include -I. -Isrc 
-Iswig -Iagg23/include -I. -I/usr/include/freetype2 -I/usr/local/include 
-I/usr/include -I. -I/usr/include/python2.3 -c'
g++4: src/_image.cpp
In file included from /usr/include/python2.3/Python.h:8,
from src/_image.cpp:7:
/usr/include/python2.3/pyconfig.h:850:1: warning: "_POSIX_C_SOURCE" 
redefined
In file included from 
/usr/include/c++/3.4.3/i386-redhat-linux/bits/os_defines.h:39,
from /usr/include/c++/3.4.3/i386-redhat-linux/bits/c++config.h:35,
from /usr/include/c++/3.4.3/iostream:44,
from src/_image.cpp:1:
/usr/include/features.h:150:1: warning: this is the location of the 
previous definition
g++4: agg23/src/agg_rasterizer_scanline_aa.cpp
g++4: CXX/IndirectPythonInterface.cxx
In file included from /usr/include/python2.3/Python.h:8,
from ./CXX/WrapPython.h:47,
from ./CXX/IndirectPythonInterface.hxx:41,
from CXX/IndirectPythonInterface.cxx:38:
/usr/include/python2.3/pyconfig.h:850:1: warning: "_POSIX_C_SOURCE" 
redefined
In file included from /usr/include/sys/time.h:22,
from ./CXX/WrapPython.h:43,
from ./CXX/IndirectPythonInterface.hxx:41,
from CXX/IndirectPythonInterface.cxx:38:
/usr/include/features.h:150:1: warning: this is the location of the 
previous definition
g++4: src/backend_agg.cpp
In file included from /usr/include/python2.3/Python.h:8,
from ./CXX/WrapPython.h:47,
from ./CXX/Extensions.hxx:48,
from src/ft2font.h:18,
from src/backend_agg.cpp:24:
/usr/include/python2.3/pyconfig.h:850:1: warning: "_POSIX_C_SOURCE" 
redefined
In file included from 
/usr/include/c++/3.4.3/i386-redhat-linux/bits/os_defines.h:39,
from /usr/include/c++/3.4.3/i386-redhat-linux/bits/c++config.h:35,
from /usr/include/c++/3.4.3/iostream:44,
from src/backend_agg.cpp:4:
/usr/include/features.h:150:1: warning: this is the location of the 
previous definition
/usr/lib/python2.3/site-packages/numpy/core/include/numpy/ufuncobject.h:9: 
error: 'intp' has not been declared
/usr/lib/python2.3/site-packages/numpy/core/include/numpy/ufuncobject.h:9: 
error: 'intp' has not been declared
In file included from /usr/include/python2.3/Python.h:8,
from ./CXX/WrapPython.h:47,
from ./CXX/Extensions.hxx:48,
from src/ft2font.h:18,
from src/backend_agg.cpp:24:
/usr/include/python2.3/pyconfig.h:850:1: warning: "_POSIX_C_SOURCE" 
redefined
In file included from 
/usr/include/c++/3.4.3/i386-redhat-linux/bits/os_defines.h:39,
from /usr/include/c++/3.4.3/i386-redhat-linux/bits/c++config.h:35,
from /usr/include/c++/3.4.3/iostream:44,
from src/backend_agg.cpp:4:
/usr/include/features.h:150:1: warning: this is the location of the 
previous definition
/usr/lib/python2.3/site-packages/numpy/core/include/numpy/ufuncobject.h:9: 
error: 'intp' has not been declared
/usr/lib/python2.3/site-packages/numpy/core/include/numpy/ufuncobject.h:9: 
error: 'intp' has not been declared
error: Command "g++4 -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -m32 
-march=i386 -mtune=pentium4 -D_GNU_SOURCE -fPIC -fPIC 
-I/usr/lib/python2.3/site-packages/numpy/core/include 
-I/usr/include/libpng12 -I/usr/local/include -I/usr/include -I. -Isrc 
-Iswig -Iagg23/include -I. -I/usr/include/freetype2 -I/usr/local/include 
-I/usr/include -I. -I/usr/include/python2.3 -c src/backend_agg.cpp -o 
build/temp.linux-i686-2.3/src/backend_agg.o" failed with exit status 1

i tried different compilers (3.4.6 and 4.1.0), all of which failed with 
the same 'intp' has not been declared issue.

i thought it was a problem with wx, so i edited setup.cfg to auto
Gtk = True
Gtkagg = True
Tkagg = True
Wxagg = False

that cleared up the wx problem, but it _still_ won't compile.

edited setup.cfg to a few different backends (gtk, gtkagg, tkagg) and 
they all fail.
even setting the backend=Svg in the setup.cfg fails.

any suggestions???? thanks!

hi,

I think the new 0.91.1 has some kind of file handle leak at least when 
using python 2.4, tkagg, and within ipython. Using process explorer to 
look at filehandles opened by python then I get about 25 new open 
handles to vera.ttf per %run of the following script.

from pylab import *

figure(1)
clf()
title("jj")
figure(2)
clf()
title("jj")


However if I close("all") between %runs then all the open handles are 
closed.

I tried the same thing with 0.90.1 and then I only get 2 handles for the 
same script and no increase on subsequent calls with or without 
close("all").

/Jörgen

Thanks for the background Barry.

I was asking because I have a bit of image processing/analysis code
(numpy/mpl/pil) that I would like to build a GUI front-end for. As I
am a recent convert to the osx world, I thought it would be very slick
to be able to do this with the xcode/IB tools. Since this is not
high-priority work right now, I'll stick with wx for now. I will be
interested to see how your Quartz backend comes along.

Barry Wark wrote:
> We (at my work) are just starting to think about writing a more direct  
> Quartz backend for mpl. A native backend would let a matplotlib view  
> participate in newer Cocoa technologies, such as resolution  
> independence and CoreAnimation (it's possible with the current backend  
> method, but not quite as flexible).

I'm curious what Cocoa and CoreAnimation might enable...

If you are looking into writing a Quartz rendering backend, you may want 
to start with the matplotlib transforms branch (which should become the 
trunk shortly, once the 0.91 release bugs get shaken out.)  The number 
of methods that a backend writer must provide has been greatly reduced 
on that branch.

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Dec 5, 2007 11:55 AM, Barry Wark <bar...@gm...> wrote:
> Stephen,
>
> The CocoaAgg backend is not supported in IPython.

Though we'd love to support it, were a few patches to land our way :)

Cheers,

f

Stephen,

The CocoaAgg backend is not supported in IPython. You can use it in  
the non-interactive form (i.e. with a pylab.show() but you will have  
to close the window in order to return control to the IPython shell).  
It is possible to embed an MPL plot in a Cocoa application using the  
same trick as the CocoaAgg backend (rendering the plot using the Agg  
backend and then turning the rasterized bitmap into and  
NSBitmapImageRep and then displaying it in an NSImageView). I've  
posted previously about a py2app plugin which does just that and has  
an IB palette, but I haven't had time to update the IB palette to use  
the IB 3 plugin API yet. It uses Cocoa Bindings to provide data to the  
plot. I'm happy to send it to you as is, or you can wait until it's IB  
3 ready.

We (at my work) are just starting to think about writing a more direct  
Quartz backend for mpl. A native backend would let a matplotlib view  
participate in newer Cocoa technologies, such as resolution  
independence and CoreAnimation (it's possible with the current backend  
method, but not quite as flexible). This will make embedding easier,  
but will not solve the IPython issues. For now, one of the other  
backends, such as WXAgg or TkAgg is probably the better bet on OS X.

barry

On Dec 5, 2007, at 7:37 AM, Stephen Uhlhorn wrote:

> I was just wondering what the status of the CocoaAgg backend is since
> there is not much info available.
>
> Can it be used interactively w/ipython?
>
> Can it be used to embed mpl in a cocoa app and take advantage of all
> the xcode/interface builder stuff in OS X?
>
> Thanks-
> -stephen
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Matplotlib-users mailing list
> Matplotlib-users@lists.s

Chris,

I appologize for cryptic language and quickly written emails leading  
you astray. I've included the diff of backend_cocoaagg.py (which has  
also been sent to the mpl devs) which seems to work for me.

Barry

It works for me on Linux with matplotlib 0.91.1, and Cairo 1.4.0.

What version of matplotlib and Cairo are you using?  It sounds like it 
may be pulling in the wrong fonts.  Can you please send the contents of 
your matplotlibrc file, and also set "verbose.level" to "debug-annoying" 
and send the output?

Cheers,
Mike

Brian Baughman wrote:
> Hello all,
> 
> I am trying to get a setup where I can have an interactive environment  
> and output to PDF files as needed.  I currently have this setup  
> working in OS X 10.5 without problems.  However, I cannot get a  
> similar setup working on linux.  The best I have been able to do is by  
> using GTKCairo but it has a problem with rendering numbers in math  
> mode. Specifically when I put a number, say "-3.1415", into a string  
> the decimal is converted to a : and the "-" is turned into an "i".   
> Below is an example that gives this error:
> import numpy
> from pylab import *
> x = numpy.arange(1,100,1)
> e1=-1.8
> e2=-2.1
> y = x**2
> z = x**-2
> f = figure(num=1)
> f.clear()
> ax = f.add_subplot(111)
> p = ax.plot(x,y)
> p1 = ax.plot(x,z)
> title('This works -2.1 but this doesnot $-2.1$')
> legend((p[0],p1[0]),(r'$x^{%.2g}$'%(e1),r'$x^{%.2g}$'%(e2)))
> draw()
> savefig('test.pdf')
> 
> The output looks fine in GTKAgg but then I get an error on glib.
> 
> Anyone have any ideas on how to get it working?
> 
> Regards,
> Brian
> 
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

At 10:03 AM -0800 2007-12-05, Christopher Barker wrote:
>Russell E Owen wrote:
>>At 10:08 AM -0500 2007-12-05, Stephen Uhlhorn wrote:
>>>Just for my edification, why can't the egg version be linked
>>>against/include a different Tcl/Tk?
>>
>>If you mean why can't it be built that way in the first place, I 
>>don't know. The guy who builds it apparently doesn't read this list,
>
>Sure he does (if you mean the matplotlib list), and he did ask about 
>it right before this release. Maybe that was asked on 
>matplotlib-devel though (I filter them to the same place).

It was on matploblib-devel. I'll start skimming that newsgroup.

>>I suspect the official egg can somehow be patched, but I find it 
>>easier to just build my own and put that on pythonmac.
>
>Ideally, there would be only one binary version, and it would work 
>with either Tcl/Tk. Is that possible? or is this like the old wx 
>situation, where it  can only be run with the same version it is 
>built against. Arrggg! I hope not.

The version I build *can* be used with the built in Tcl/Tk. The 
version Charlie Moad builds cannot be used with TkAgg and a 3rd party 
Tcl/Tk -- it not only won't use the library, but it also acts flaky. 
Older versions crashed. 0.91.1 doesn't crash, but import of pylab 
fails with a traceback.

For some reason it seems to be necessary to have a 3rd party Tcl/Tk 
installed when building matplotlib. It seems a shame. Tkinter in 
Python 2.4 was the same way, but that got fixed in Python 2.5 (I 
don't whether the installer got fixed or whether whoever builds Mac 
Python 2.5 installed a 3rd party Tcl/Tk).

>If there really do need to be two, then they should be labeled 
>somehow, and both be up on python mac.

Since there don't need to be two versions this is not necessary.

However, Charlie Moad appears to be willing to start building a 
version that works with 3rd party Tcl/Tk. I really hope that happens.

-- Russell

Hello all,

I am trying to get a setup where I can have an interactive environment  
and output to PDF files as needed.  I currently have this setup  
working in OS X 10.5 without problems.  However, I cannot get a  
similar setup working on linux.  The best I have been able to do is by  
using GTKCairo but it has a problem with rendering numbers in math  
mode. Specifically when I put a number, say "-3.1415", into a string  
the decimal is converted to a : and the "-" is turned into an "i".   
Below is an example that gives this error:
import numpy
from pylab import *
x = numpy.arange(1,100,1)
e1=-1.8
e2=-2.1
y = x**2
z = x**-2
f = figure(num=1)
f.clear()
ax = f.add_subplot(111)
p = ax.plot(x,y)
p1 = ax.plot(x,z)
title('This works -2.1 but this doesnot $-2.1$')
legend((p[0],p1[0]),(r'$x^{%.2g}$'%(e1),r'$x^{%.2g}$'%(e2)))
draw()
savefig('test.pdf')

The output looks fine in GTKAgg but then I get an error on glib.

Anyone have any ideas on how to get it working?

Regards,
Brian

Russell E Owen wrote:
> At 10:08 AM -0500 2007-12-05, Stephen Uhlhorn wrote:
>> Just for my edification, why can't the egg version be linked
>> against/include a different Tcl/Tk?
> 
> If you mean why can't it be built that way in the first place, I 
> don't know. The guy who builds it apparently doesn't read this list, 

Sure he does (if you mean the matplotlib list), and he did ask about it 
right before this release. Maybe that was asked on matplotlib-devel 
though (I filter them to the same place).

> I suspect the official egg can somehow be patched, but I find it 
> easier to just build my own and put that on pythonmac.

Ideally, there would be only one binary version, and it would work with 
either Tcl/Tk. Is that possible? or is this like the old wx situation, 
where it  can only be run with the same version it is built against. 
Arrggg! I hope not.

If there really do need to be two, then they should be labeled somehow, 
and both be up on python mac.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

I primarily follow the dev list, but you've caught my eye. ;)

So to be clear, you would just like me to install some other tcl/tk
before I do the "official" matplotlib osx binaries.  What package
should I be installing and where should I get it from.  As long as it
still works with the bundled tck/tk I would have no problems doing
this.

Thanks,
- Charlie

On Dec 5, 2007 12:01 PM, Russell E Owen <ro...@ce...> wrote:
> At 10:08 AM -0500 2007-12-05, Stephen Uhlhorn wrote:
> >On Dec 4, 2007 5:14 PM, Russell E. Owen <ro...@ce...> wrote:
> >
> >>  If you use Tcl/Tk and use a current version (instead of the ancient
> >>  version that is built in) then use the packages at pythonmac. I just
> >>  built 0.91.1 today and it should show up there soon. Meanwhile you can
> >>  get it from here:
> >>  <http://www.astro.washington.edu/rowen/pythoninstallers/>
> >>
> >>  I hope that someday the official Mac egg version will work with 3rd
> >>  party Tcl/Tk but no version I've tried has -- including 0.91.1.
> >
> >Does this mean that the only difference between the egg and pythonmac
> >version is how it's linked against Tcl/Tk?
>
> I suspect you are right. But I only build the pythonmac version, not
> the official version, so I don't know for sure. I build my version
> using:
> <http://www.astro.washington.edu/rowen/BuildingMatplotlibForMac.html>.
> I don't do anything special, but I do have a 3rd party Tcl/Tk
> installed before I build and that seems to make all the difference.
>
> >Just for my edification, why can't the egg version be linked
> >against/include a different Tcl/Tk?
>
> If you mean why can't it be built that way in the first place, I
> don't know. The guy who builds it apparently doesn't read this list,
> and I understand he's on some mailing list that I don't subscribe to.
>
> I suspect the official egg can somehow be patched, but I find it
> easier to just build my own and put that on pythonmac.
>
> -- Russell
>
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

John Hunter wrote:
> You cannot import pylab and use the FigureCanvasWx at the same time.
> Please follow the lead of examples/embedding_in_wx*.py if you want to
> use matplotlib in a wxpython GUI.

or use wxmpl:

http://agni.phys.iit.edu/~kmcivor/wxmpl/

By the way, couldn't that be distributed with Matplotlib? Maybe in 
toolkits, if not the main distro.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

I feel we're getting a tad bit off topic from my original inquiry. Does
anyone have an answer for me? Thanks.

On Dec 5, 2007 8:42 AM, massimo sandal <mas...@un...> wrote:

> rex ha scritto:
> > massimo sandal <mas...@un...> [2007-12-04 09:18]:
> >> On a related note, I *hate* that hitting "reply" uses the mail address
> >> of the parent poster, instead than that of the mailing list. The scipy
> >> and the gentoo mailing list (two other examples I know) behave more
> >> properly. Is this a sourceforge quirk?
> >
> > The list follows RFC 2822. The Reply-To header is intended to be
> > created by the originator of the message. List software that
> > overwrites the Reply-To header destroys the function it's intended
> > for.
> >
> > There's an excellent essay on this at:
> >
> > http://woozle.org/~neale/papers/reply-to-still-harmful<http://woozle.org/%7Eneale/papers/reply-to-still-harmful>
> >
> > Mailman implements RFC 2369, which is intended to address this
> > issue. If you want replies to go to the list, I suggest that you
> > use a mail client that follows RFC 2369. If you choose to use old
> > software that doesn't recognize the List-Post header, please don't
> > complain about software that follows RFC standards.
>
> Thanks for the article. I read it, and I must say I disagree. This is
> the tricky part:
>
> "Your list software is not "the author of the message", so it must not
> set or in any way meddle with the Reply-To header. "
>
> That's what I think is wrong. When interacting with a mailing list, I
> assume I'm not interacting just with you or others. I'm receiving mails
> *from the ML* and sending mails *to the ML*. Not receiving mails from
> Alice and sending mails to Bob.
>
> In other words: A ML, in my experience, is not different from a public
> forum. When I hit "reply" on a forum, the post goes on the forum, not on
> the mailbox of the previous poster.
>
> I'm all for standards and for consistent behaviour and I understand the
> logic behind that article; what the authors of the RFC got wrong, in my
> opinion, it considering a mailing list just as a gigantic CC: by
> disconnected people instead than of a forum-like object. The fact both
> use the mail protocol doesn't change the fact they're different objects.
>
> But of course that's only a philosophical problem. Thanks to the article
> I also discovered that "reply to all" sends mail both to the ML and the
> original sender (Never bothered to try, my fault). Although I find it a
> little funny.
>
> m.
>
> --
> Massimo Sandal
> University of Bologna
> Department of Biochemistry "G.Moruzzi"
>
> snail mail:
> Via Irnerio 48, 40126 Bologna, Italy
>
> email:
> mas...@un...
>
> tel: +39-051-2094388
> fax: +39-051-2094387
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

At 10:08 AM -0500 2007-12-05, Stephen Uhlhorn wrote:
>On Dec 4, 2007 5:14 PM, Russell E. Owen <ro...@ce...> wrote:
>
>>  If you use Tcl/Tk and use a current version (instead of the ancient
>>  version that is built in) then use the packages at pythonmac. I just
>>  built 0.91.1 today and it should show up there soon. Meanwhile you can
>>  get it from here:
>>  <http://www.astro.washington.edu/rowen/pythoninstallers/>
>>
>>  I hope that someday the official Mac egg version will work with 3rd
>>  party Tcl/Tk but no version I've tried has -- including 0.91.1.
>
>Does this mean that the only difference between the egg and pythonmac
>version is how it's linked against Tcl/Tk?

I suspect you are right. But I only build the pythonmac version, not 
the official version, so I don't know for sure. I build my version 
using:
<http://www.astro.washington.edu/rowen/BuildingMatplotlibForMac.html>. 
I don't do anything special, but I do have a 3rd party Tcl/Tk 
installed before I build and that seems to make all the difference.

>Just for my edification, why can't the egg version be linked
>against/include a different Tcl/Tk?

If you mean why can't it be built that way in the first place, I 
don't know. The guy who builds it apparently doesn't read this list, 
and I understand he's on some mailing list that I don't subscribe to.

I suspect the official egg can somehow be patched, but I find it 
easier to just build my own and put that on pythonmac.

-- Russell

Michael Hearne wrote:
> Does anyone here have any experience converting GMT color palettes 
> into pylab colormaps?  I took a stab at it, and the results are not 
> really what I expected.
>
> GMT, for the unfamiliar, is a scientific plotting/mapping package that 
> I'm doing my best to rid myself of.  If you've never heard of it, then 
> you can probably ignore this message.
>
> Here's my attempt at bringing in a GMT color palette:
>
> #!/usr/bin/python
>
> from pylab import *
>
> #GMT color palette - Colors are specified by a RGB triplet with each 
> value in the range
> #0-255.  The palette below specifies that a data value between 1 and 2 
> will be assigned a color
> #linearly interpreted between the colors (255,255,255) and (191,204,255).
>
> # 0       255     255     255     1       255     255     255
> # 1       255     255     255     2       191     204     255
> # 2       191     204     255     3       160     230     255
> # 3       160     230     255     4       128     255     255
> # 4       128     255     255     5       122     255     147
> # 5       122     255     147     6       255     255     0
> # 6       255     255     0       7       255     200     0
> # 7       255     200     0       8       255     145     0
> # 8       255     145     0       9       255     0       0
> # 9       255     0       0       10      200     0       0
> # 10      200     0       0       13      128     0       0
>
> cdict = {'red': ((0.0,1.00,1.0),
>                  (0.1,1.00,0.75),
>                  (0.2,0.75,0.63),
>                  (0.3,0.63,0.50),
>                  (0.4,0.50,0.48),
>                  (0.5,0.48,1.00),
>                  (0.6,1.00,1.00),
>                  (0.7,1.00,1.00),
>                  (0.8,1.00,1.00),
>                  (0.9,1.00,0.78),
>                  (1.0,0.78,0.50)),
>          'green': ((0.0,1.00,1.00),
>                    (0.1,1.00,0.80),
>                    (0.2,0.80,0.90),
>                    (0.3,0.90,1.00),
>                    (0.4,1.00,1.00),
>                    (0.5,1.00,1.00),
>                    (0.6,1.00,0.78),
>                    (0.7,0.78,0.57),
>                    (0.8,0.57,0.00),
>                    (0.9,0.00,0.00),
>                    (1.0,0.00,0.00)),
>          'blue': ((0.0,1.00,1.00),
>                   (0.1,1.00,1.00),
>                   (0.2,1.00,1.00),
>                   (0.3,1.00,1.00),
>                   (0.4,1.00,0.58),
>                   (0.5,0.58,0.00),
>                   (0.6,0.00,0.00),
>                   (0.7,0.00,0.00),
>                   (0.8,0.00,0.00),
>                   (0.9,0.00,0.00),
>                   (1.0,0.00,0.00))}
>          
> my_cmap = matplotlib.colors.LinearSegmentedColormap('my_colormap',cdict)
> pcolor(rand(10,10),cmap=my_cmap)
> colorbar()
> savefig('colormap.png')
>
Michael:  The basemap toolkit includes the GMT colormaps.  To access 
them, import cm from the basemap namespace (from 
matplotlib.toolkits.basemap import cm).  The names are prefixed with 'GMT_'.

-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

Does anyone here have any experience converting GMT color palettes  
into pylab colormaps?  I took a stab at it, and the results are not  
really what I expected.

GMT, for the unfamiliar, is a scientific plotting/mapping package  
that I'm doing my best to rid myself of.  If you've never heard of  
it, then you can probably ignore this message.

Here's my attempt at bringing in a GMT color palette:

#!/usr/bin/python

from pylab import *

#GMT color palette - Colors are specified by a RGB triplet with each  
value in the range
#0-255.  The palette below specifies that a data value between 1 and  
2 will be assigned a color
#linearly interpreted between the colors (255,255,255) and  
(191,204,255).

# 0       255     255     255     1       255     255     255
# 1       255     255     255     2       191     204     255
# 2       191     204     255     3       160     230     255
# 3       160     230     255     4       128     255     255
# 4       128     255     255     5       122     255     147
# 5       122     255     147     6       255     255     0
# 6       255     255     0       7       255     200     0
# 7       255     200     0       8       255     145     0
# 8       255     145     0       9       255     0       0
# 9       255     0       0       10      200     0       0
# 10      200     0       0       13      128     0       0

cdict = {'red': ((0.0,1.00,1.0),
                  (0.1,1.00,0.75),
                  (0.2,0.75,0.63),
                  (0.3,0.63,0.50),
                  (0.4,0.50,0.48),
                  (0.5,0.48,1.00),
                  (0.6,1.00,1.00),
                  (0.7,1.00,1.00),
                  (0.8,1.00,1.00),
                  (0.9,1.00,0.78),
                  (1.0,0.78,0.50)),
          'green': ((0.0,1.00,1.00),
                    (0.1,1.00,0.80),
                    (0.2,0.80,0.90),
                    (0.3,0.90,1.00),
                    (0.4,1.00,1.00),
                    (0.5,1.00,1.00),
                    (0.6,1.00,0.78),
                    (0.7,0.78,0.57),
                    (0.8,0.57,0.00),
                    (0.9,0.00,0.00),
                    (1.0,0.00,0.00)),
          'blue': ((0.0,1.00,1.00),
                   (0.1,1.00,1.00),
                   (0.2,1.00,1.00),
                   (0.3,1.00,1.00),
                   (0.4,1.00,0.58),
                   (0.5,0.58,0.00),
                   (0.6,0.00,0.00),
                   (0.7,0.00,0.00),
                   (0.8,0.00,0.00),
                   (0.9,0.00,0.00),
                   (1.0,0.00,0.00))}

my_cmap = matplotlib.colors.LinearSegmentedColormap('my_colormap',cdict)
pcolor(rand(10,10),cmap=my_cmap)
colorbar()
savefig('colormap.png')





------------------------------------------------------
Michael Hearne
mh...@us...
(303) 273-8620
USGS National Earthquake Information Center
1711 Illinois St. Golden CO 80401
Senior Software Engineer
Synergetics, Inc.
------------------------------------------------------

On Dec 5, 2007 8:37 AM, Stephen Uhlhorn <ste...@gm...> wrote:
> I was just wondering what the status of the CocoaAgg backend is since
> there is not much info available.
>
> Can it be used interactively w/ipython?

I don't know for a fact, but the answer is probalby no.  Each GUI
backend requires an explicit implementation in ipython, since they all
have their own threading/callback/timer quirks (even qt3 and qt4 are
different).  Thus far, we don't have one for Cocoa.  It may 'just
work', but I don't know that, so if you find that it doesn't, and
decide to dig in to implement the support, by all means send it our
way!  The file to look at for inspiration is:

http://projects.scipy.org/ipython/ipython/browser/ipython/trunk/IPython/Shell.py

Cheers,

f

I was just wondering what the status of the CocoaAgg backend is since
there is not much info available.

Can it be used interactively w/ipython?

Can it be used to embed mpl in a cocoa app and take advantage of all
the xcode/interface builder stuff in OS X?

Thanks-
-stephen

On Dec 5, 2007 6:38 AM, S=F8ren Nielsen <sor...@gm...> wrot=
e:
> Hi,
>
> Is it possible to expand the colorcycle that matplotlib uses by default?
>
> in axes.py, class _process_plot_var_args, def _clear_color_cycle(self) It
> seems that self.colors are hardcoded to be self.colors =3D
> ['b','g','r','c','m','y','k'] ... is there a way to extend this? (Without
> changing the matplotlib code directly) I want to be able to extend it by =
ex.
> dashed lines or others.. i sometimes have a large number of plots to do, =
and
> the 7 default plot colors are not enough...
>
> I know I could manually make a handler in my program to handle the colors
> when I plot... but it would seem nicer if I could just pass a list of plo=
t
> colors to matplotlib.

I just made a chance in svn to expose the default color list.  Here is
an ipython session that shows how to use it:

In [1]: import matplotlib.axes as mplaxes

In [2]: x, y =3D rand(2,100)

In [3]: plot(x, y, 2*x, 2*y)
Out[3]:
[<matplotlib.lines.Line2D instance at 0x8f2dc8c>,
 <matplotlib.lines.Line2D instance at 0x8f2dd6c>]

In [4]: mplaxes._process_plot_var_args.defaultColors =3D ['red',
'darkslategray', 'wheat']

In [5]: clf()

In [6]: plot(x, y, 2*x, 2*y)

Darren, we might want to expose this in the matplotlib.conf, but
perhaps is it a rare enough request that it is enough to let people
tweak it manually when needed.  The only thing that is a bit ugly is
that Axes._process_plot_var_args has the leading underscore indicating
it should not be used outside of mpl, but this is easy enough to
remedy...

JDH

On Dec 5, 2007 8:58 AM, Jos=E9 G=F3mez-Dans <jgo...@gm...> wrote:

> Mmmm... I was just wondering whether compiling the new 0.91.1 version mig=
ht
> make the problem go away? I am currently running 0.90.1.

Unlikely, we haven't changed anything in that code.  One thing you can
do, it is fairly labor intensive, is to paste the toolbar code from
backend_gtk into your script and slowly start hacking away at it to
see which gtk call is causing your problems.  I don't see an easier
way.

Alternatively, you could get tkagg, qtagg or wxagg installed.  If you
want to stick with gtk, I can provide a sample script for you that
defines the toolbar inline so you can hack on it.

JDH

On Dec 4, 2007 5:14 PM, Russell E. Owen <ro...@ce...> wrote:

> If you use Tcl/Tk and use a current version (instead of the ancient
> version that is built in) then use the packages at pythonmac. I just
> built 0.91.1 today and it should show up there soon. Meanwhile you can
> get it from here:
> <http://www.astro.washington.edu/rowen/pythoninstallers/>
>
> I hope that someday the official Mac egg version will work with 3rd
> party Tcl/Tk but no version I've tried has -- including 0.91.1.

Does this mean that the only difference between the egg and pythonmac
version is how it's linked against Tcl/Tk?

Just for my edification, why can't the egg version be linked
against/include a different Tcl/Tk?

Thanks-
-stephen

On Tuesday 04 December 2007 16:16:06 Jos=E9 G=F3mez-Dans wrote:
> On Tuesday 04 December 2007 16:05:33 John Hunter wrote:
> > On Dec 4, 2007 10:00 AM, Jos=E9 G=F3mez-Dans <jgo...@gm...> wro=
te:
> > Hmm, the plot thickens.  How about embedding_in_gtk2.py -- this add the
> > toolbar
>
> This does indeed slow things down. The minimal script that reproduces this
> behaviour is the following (the delay appears round about the definition =
of
> toolbar):
[...]

Mmmm... I was just wondering whether compiling the new 0.91.1 version might=
=20
make the problem go away? I am currently running 0.90.1.

Thanks,
J

On Sunday 02 December 2007 06:55:01 am hjc520070 wrote:
> Xavier Gnata wrote:
> > Hi,
> >
> > Quoting  matplotlib/__init__.py :
> >
> > def checkdep_ghostscript():
> >     try:
> >         if sys.platform =3D=3D 'win32':
> >             command =3D 'gswin32c -v'
> >         else:
> >             command =3D 'gs -v'
> >         stdin, stdout =3D os.popen4(command)
> >         line =3D stdout.readlines()[0]
> >         v =3D line.split()[2]
> >         vtest =3D '.'.join(v.split('.')[:2]) # deal with version numbers
> > like '7.07.1'
> >         float(vtest)
> >         return vtest
> >     except (IndexError, ValueError):
> >         return None
> >
> > It fails on debian sid because 'gs -v' returns "GPL Ghostscript SVN
> > PRE-RELEASE 8.61 (2007-08-02)\n"
> >
> > Anyway, the parser will be ugly because it has to deal with version
> > numbers like '7.07.1'.
> > Should I propose a trivial patch to get thinks working on debian sid ?
> >
> > Xavier
> > ps :Why is there no standard way (like -v or --version) on *unix to get
> > the version *number*?? Only the version number. Why :(
> >
> > --
> > ############################################
> > Xavier Gnata
> > CRAL - Observatoire de Lyon
> > 9, avenue Charles Andr=C3=A9
> > 69561 Saint Genis Laval cedex
> > Phone: +33 4 78 86 85 28
> > Fax: +33 4 78 86 83 86
> > E-mail: gn...@ob...
> > ############################################
> >
> >
> > -----------------------------------------------------------------------=
=2D-
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
> Yeah , I did face the same problem . My code is following:
> There seems to be something wrong in "ax.imshow(im)", I can't get the
> answer , Can sb help me .

The imshow documentation says "X may be a float array, a uint8 array or a P=
IL=20
image", but you are passing it an AxesImage instance, which wont work.=20

> The error message"ValueError: need more than 0 values to unpack"
> Thank you .
>
> # -*- coding:gb2312 -*-
> import wx
> from pylab import *
> from matplotlib.backends.backend_wx import FigureCanvasWx
> from matplotlib.figure import Figure
> from matplotlib.axes import *
> from numpy import *
>
> #-------------------------------------------------------------
> x=3Darray(range(0,100))
> y=3Darray(range(0,100))
> z=3Drand(100,100)
> figure(1)
> im=3Dimshow(z, interpolation=3D'bilinear', origin=3D'lower',cmap=3Dcm.gra=
y,
> extent=3D(0,100,0,100))
> levels =3D arange(0.3, 0.4, 0.9)
> contour(x,y,z,levels,origin=3D'lower',linewidths=3D2,extent=3D(0,100,0,10=
0))
>
>
> fig=3Dfigure(2)
> ax =3D fig.add_subplot(111)
> ax.imshow(im)
> ax.set_xlim(0,3)
> ax.set_ylim(0,2)
> show()