matplotlib-users Mailing List for matplotlib (Page 4)

On Oct 21, 2005, at 18:32 , Chris Barker wrote:
> Jeff Whitaker wrote:
>
>> Andrea: There are lots of things that would work well - but the 
>> licensing is a problem. GTS is GPL, we need something with a less 
>> restrictive license (more like Python's).
>>
>
> No, it's LGPL, which is much better, but maybe still not OK for 
> mpl. I guess the problem is that mpl is kind of a library of 
> libraries, rather than an application, so it would be awkward to 
> have mixed licenses in it.
>
> -Chris
I suggested GTS exactly because I remembered that it is LGPL, and I 
thought it would had been ok for your needs. But I must admit that I 
know very little about licences.
Andrea

On Thu, Oct 20, 2005 at 06:37:15PM +0200, Nils Wagner wrote:
> cvs -z3=20
> -d:pserver:ano...@cv...:/cvsroot/matplotlib=20
> co -P matplotlib
>=20
> yields
>=20
> cvs [checkout aborted]: end of file from server (consult=20
> above messages if any)
>=20
> How can I resolve this problem ?
>=20
I've gotten that error a few times. The solution I've found is to just=20
keep trying it. Eventually it seems to work. Not sure what the
real problem is.
Regards,
John
--=20
The world is full of people who have never, since childhood, met an
open doorway with an open mind.
 -- E.B. White

Chris and others,
Chris Barker wrote:
> Jeff Whitaker wrote:
> 
>> Andrea: There are lots of things that would work well - but the 
>> licensing is a problem. GTS is GPL, we need something with a less 
>> restrictive license (more like Python's).
> 
> 
> No, it's LGPL, which is much better, but maybe still not OK for mpl. I 
> guess the problem is that mpl is kind of a library of libraries, rather 
> than an application, so it would be awkward to have mixed licenses in it.
> 
I don't understand this. Why can't the mpl license simply say that it 
applies to all components that do not cite other licenses, and then 
leave the reference to the original license in any code such as GTS 
which has another license? This is not a plea for or against GTS or any 
other particular package, but rather an expression of puzzlement and 
frustration that we seem to be finding free software licenses limiting 
instead of liberating.
Eric

Below is a response that I received from Vittorio today regarding problems 
with using the "python-matplotlib" package in Debian stable.
Ken
-------- Original Message --------
Subject: Re: [Matplotlib-users] Newbie and debian user
Date: 2005年10月21日 18:32:21 +0200
From: Vittorio Palmisano <vpa...@gm...>
To: Ken McIvor <mc...@ii...>
References: <434...@ol...> 
<87o...@pe...> 
<f6a...@ii...>
Ken McIvor ha scritto:
> kmcivor@ivory:~$ ldd
> /usr/lib/python2.3/site-packages/matplotlib/backends/_na_backend_gdk.so
> | fgrep pangocairo
> libpangocairo-1.0.so.0 => not found
try to install version 0.82-1, it's build for sarge, look here:
http://anakonda.altervista.org/phpBB2/viewtopic.php?t=12
-- 
/Vittorio Palmisano/
Home Page: http://redclay.altervista.org

I set the matplotlibrc tick.direction to out.
The ticks on the top x-axis and left y-axis appear to begin on the 
inside edge of the frame and thus appear shorter than the other two 
sides which seem to begin on the outside edge of the plot frame.
The minor ticks are almost obscured.
 I am using the default settings for all else in the matplotlibrc.
Running matplotlib 0.84, OS X 10.3.9
This in/out choice is a new feature and perhaps this is a bug.
--Jim 

When I run the example for two scales (two_scales.py), the secondary 
axis - on the right- has ticks for both scales. The primary - on left - 
has the expected one set of ticks.
I did modify the example code as shown below. Instead of calling the 
twinx function of pylab I explicitly took the code from pylab.py. this 
was because I wanted to see exactly what was being done with an intent 
to modify it slightly. In any case it should be completely equivalent 
to the example. When I did run the example unchanged it gave the same 
result.
Is this a bug or something I am missing something ?
Running matplotlib 0.84 on OS X 10.3.9
import pylab
import Numeric
N = Numeric
PL = pylab
ax1 = PL.subplot(111)
t = N.arange(0.01, 10.0, 0.01)
s1 = N.exp(t)
PL.plot(t, s1, 'b-')
PL.xlabel('time (s)')
PL.ylabel('exp')
# turn off the 2nd axes rectangle with frameon kwarg
#ax2 = PL.twinx()
ax = PL.gca()
ax2 = PL.gcf().add_axes(ax.get_position(), sharex=ax, frameon=False)
ax2.yaxis.tick_right()
ax2.yaxis.set_label_position('right')
s2 = N.sin(2*N.pi*t)
PL.plot(t, s2, 'r.')
PL.ylabel('sin')
ax2.yaxis.tick_right()
show()

Jeff Whitaker wrote:
> Andrea: There are lots of things that would work well - but the 
> licensing is a problem. GTS is GPL, we need something with a less 
> restrictive license (more like Python's).
No, it's LGPL, which is much better, but maybe still not OK for mpl. I 
guess the problem is that mpl is kind of a library of libraries, rather 
than an application, so it would be awkward to have mixed licenses in it.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Hello list,
Hello John,
I was able to write the suggested data.py containing all paths for the
desired markers. Everything works fine for the Agg-backends. To be able to
use the non-Agg backends I also tried to find a way to use the markers in
the non-'_newstyle'-way. Unfortunately this did't work as I expected (the
vertices are not shifted to the correct position and behave very strange
when zooming etc.).
The changed lines.py and the data.py are attached.
I also rewrote the plot_points-routine. It now uses the same path_2_vertices
and add_offset_to_vertices as the non-_newstyle method. There everything
works fine.
So there arise two questions:
1) What is wrong with the add_offset_to_vertices etc.?
2) Where can the plot_points be placed?
Nice weekend,
Martin
PS: Sorry for the delay, but I'm only able to spend time on MPL once a week.
-- 
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner 

Hello, I am using scatter function to make markers, and I am confused
about how the sizing works. When I set the size of markers in plot() it
behaves as expected, larger numbers makes larger markers. However for
scatter I set the size to maybe 5 and then increase it to 50, and even
500 and there seems to be a limit on the size of the marker in that the
difference from 5 to 50 is large and from 50 to 500 its not much change.
How does this work? Thanks.
 
axes.scatter(data,array, marker='o', c='g', linewidth=1, edgecolor='k',
alpha=0.5, s=50)
 
 
also, lines seem to plot over markers regardless of the order of the
call to plot() and scatter(). How can I force the markers to draw ontop
of the lines so that I don't see the line beneath it? I'm using WxAgg.
Thanks.
 
Jeff
 
 _____ 
Jeffrey Thomas Peery
SeaMetrics, Inc.
Mechanical Engineer 
Jef...@Se...
253.872.0285 (fax)
253.872.0284 (phone)
 _____ 
 

>>>>> "Handzsuj," == Handzsuj, Thomas <Tho...@dr...> writes:
 Thomas> Hi, I am trying to use matplotlib 0.84 with Python
 Thomas> 2.4.2 on Wondows XP with idle -n. I did this in the
 Thomas> past with the 2.3.5 and some older version of
 Thomas> matplotlib without any problems.
 Thomas> Now I have some problems. I started with a really fresh
 Thomas> installation of Python and added first the Numeric 23.8
 Thomas> module. After that I installed matplotlib 0.84 and
 Thomas> changed the matplotlibrc (tk.pythoninspect : True).
On or around line 451 in font_manager.py, try replacing the part of
the code that loads the fonts with the following block
 try:
 font = ft2font.FT2Font(str(fpath))
 except RuntimeError:
 warnings.warn("Could not open font file %s"%fpath)
 continue
 except UnicodeError:
 warnings.warn("Cannot handle unicode filenames %s"%fpath)
 continue
Here we explictly catch the unicode error and move on.
Before rerunning your code, remove your ttffont.cache
If you don't know where your font cache is, use the windows search
tool to find it. 
JDH

Andrea Riciputi wrote:
> Hi all,
> I'm an absolute lurker here, so forgive me if my suggestions are 
> useless. Anyway, some time ago I've found this library 
> <http://gts.sourceforge.net/> that could be of some help. Or perhaps 
> it's a complete different beast and I'm out of the way to go...
>
> HTH,
> Andrea
>
Andrea: There are lots of things that would work well - but the 
licensing is a problem. GTS is GPL, we need something with a less 
restrictive license (more like Python's).
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/CDC R/CDC1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Hi all,
I'm an absolute lurker here, so forgive me if my suggestions are 
useless. Anyway, some time ago I've found this library <http:// 
gts.sourceforge.net/> that could be of some help. Or perhaps it's a 
complete different beast and I'm out of the way to go...
HTH,
 Andrea

John Hunter wrote:
> I think it is fine and good to put this kind of stuff into matplotlib
> in the meantime while we get the integration and installation issues
> sorted out.
I agree. It's certainly good that there is a home for it somewhere! I'm 
glad to hear that you do have better matplotlib-Scipy integration in 
mind....things are really looking up!
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

So, it appears this is a problem with CUPS and wxPython. I had never
plugged a printer into this fairly new installation of ubuntu. After
doing so and making sure that cups is running, the IPP error went
away. Thanks for all your hard work Ken. Sorry to put you through so
much trouble for this.
Ryan
On 10/20/05, Ken McIvor <mc...@ii...> wrote:
> Ryan Krauss wrote:
> > I am sorry Ken. That is my fault. I ran the command once in my home
> > directory and every other time in a directory that has a matplotlibrc
> > file that specifies wxagg. I have been attaching the file from my
> > home directory because that is where my email attach file dialog takes
> > me first. You are going out of your way to help me and I am making
> > hard on you. I am very sorry.
>
> Don't fret, it happens to everyone from time to time.
>
> Based on the strace output, I believe that the warning is getting generat=
ed
> when trying to start up CUPS (`/etc/cups/client.conf' is opened at line
> 10484), from within lincups, which is loaded by libgnomeprintcups, which =
is
> loaded by libgnomeprint, which is loaded by wxWidgets, which is loaded by
> wxPython (whee!). Do you have a working CUPS installation on your comput=
er?
> If that's not the solution, then I don't know what is; try emailing the
> wxPython-users list.
>
> Ken
>

Hello NG,
> I still think it's worth talking to the author, however. As Robert
> pointed out, these folks are clearly not all that cluefull about open
> source licenses. They may have little idea what they really are
> restricting. As a simple example, someone on the wxPython list has been
> developing a bunch of nifty higher-level widgets, hoping to get them
> included in the wxPython lib. However, he had released them all under
> the GPL, just because he didn't know any better. When someone wrote to
> him, pointing out that his stuff couldn't be used in any non-GPL
> projects, it turns out that wasn't his intent.
Yeah, that's me ;-)
It was not my intent because I am not really interested in licensing
things... I never cared about them, and I used the GPL only because it was
the first thing that came into my mind ;-)
Big mistake.
> I think he's going to
> re-release it all under the wxWidgets license (modified LGPL).
It's done... I have changed all the widgets license to the standard
wxWidgets license. I hope this will work. If it is good enough for wxPython,
so it is for me.
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.virgilio.it/infinity77

Currently only under GTK I have been told by John Hunter.
I will try to implement it under Tkinter.
Hopefully others will tackle the other backends,
Mark
#####
Original message:
Hello,
I would like to resize a matplotlib window from a command in ipython. I
don't want to use the mouse to do this (for different reasons). Do you
know if it's possible to do this?
Thanks
N.

So, turning off the accelerator with wxPygtk2.6 did not solve this problem:
In [2]: wx.VERSION
Out[2]: (2, 6, 1, 1, 'pre')
In [3]: import matplotlib.backends.backend_wxagg
In [4]: matplotlib.backends.backend_wxagg._use_accelerator(False)
In [5]: pylab.figure(1)
** (python:11782): WARNING **: IPP request failed with status 1030
Out[5]: <matplotlib.figure.Figure instance at 0xb52048ec>
Ryan
On 10/20/05, Ken McIvor <mc...@ii...> wrote:
> On Oct 20, 2005, at 11:48 AM, Ryan Krauss wrote:
> > But when I try and turn off the accelerator I get:
> > In [4]: import matplotlib.backends.backend_wxagg
> >
> > In [5]: matplotlib.backends.backend_wxagg._use_accelertor(False)
>
> I misspelled "accelerator" in my earlier email. This should work:
>
> import matplotlib.backends.backend_wxagg
> matplotlib.backends.backend_wxagg._use_accelerator(False)
>
> > Let me know if I can try anything else to trouble shoot this. I know
> > it is really hard for you if you can't recreate the problem.
>
> I'll try to get a Ubuntu machine up and running today. I've been
> meaning to check it out, so this gives me a good excuse.
>
> Ken
>
>

On Oct 20, 2005, at 11:57 AM, Ryan Krauss wrote:
> So, turning off the accelerator with wxPygtk2.6 did not solve this 
> problem
Hmmm... googling around suggests that this error has something to do 
with talking to CUPS. If I had to guess, I'd say that wxWidgets is 
trying to talk to CUPS at startup to initialize the printing subsystem. 
 Could you please email me the output from the following command? It's 
probably going to be too big and verbose to be worth posting to the 
list, so send it to me directly.
$ strace python -c 'import pylab; pylab.figure(1)' > strace.txt 2>&1
Ken

On Oct 19, 2005, at 3:08 AM, Tim Burgess wrote:
> Fatal Python error: Call to API function without first calling 
> import_libnumarray() in Src\_convmodule.c
It looks like someone who was having the same problem got some 
reasonable advice from the numpy-discussion mailing list:
	http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/2852995
 From the posting, it sounds like you need to figure out how to make 
py2exe include all of numarray. I would start out by py2exe-ing a 
short test script that just imports numarray and makes an array, then 
moving on to your full application after you get that working.
> I added import numarray all over the place... a previous post 
> suggested that maybe Wxpython was calling numarray before I was... no 
> I dont think wxpython and numarray ever need each other.
That's not going to fix the problem: the error is referring to a C 
macro/function called `import_numarray' that is apparently supposed to 
be called while numarray is initializing itself. In the email linked 
to above, Todd Miller says that this is indicative of numarray being 
incompletely included by py2exe.
> In my library file you can see that numarray is definitely included - 
> it's there.
All of it? I think you should should probably check that the numarray 
package bundled in the py2exe zip file is identical to the one in 
site-packages (i.e. the number of files is the same).
Ken

On Oct 20, 2005, at 11:20 AM, Ryan Krauss wrote:
> In [1]: import matplotlib.backends.backend_wxagg
> In [2]: matplotlib.backends.backend_wxagg._use_accelertor(False)
<snip>
> Apparently I have managed to build mpl with the wxagg accelerator.
> That seems odd because I started this thread because setup.py was
> complaining about not having wx-config.
Apparently I can't spell this morning either. That should be 
"_use_accelerator()". Sorry! :-/
Ken

cvs -z3=20
-d:pserver:ano...@cv...:/cvsroot/matplotlib=20
co -P matplotlib
yields
cvs [checkout aborted]: end of file from server (consult=20
above messages if any)
How can I resolve this problem ?
Nils

Tim Burgess wrote:
> Hi all,
>
> First thanks to all those who have been helping out - it is really 
> appreciated.
>
> Since I couldnt build numarray - I looked at the new import code in 
> the cvs init module and ripped it off and stuffed it into my numarray 
> installation and then when that didnt work - I jammed it right up 
> front of my application.
>
> It looks like this
>
> def main():
> import numarray.numarrayall
> from numarray.numinclude import version as __version__
>
> # stolen from next numarray version in cvs TjB
>
> import numarray._conv
> import numarray._sort
> import numarray._bytes
> import numarray._ufunc
> import numarray._ufuncBool
> import numarray._ufuncInt8
> import numarray._ufuncUInt8
> import numarray._ufuncInt16
> import numarray._ufuncUInt16
> import numarray._ufuncInt32
> import numarray._ufuncUInt32
> import numarray._ufuncFloat32
> import numarray._ufuncFloat64
> import numarray._ufuncComplex32
> import numarray._ufuncComplex64
> import numarray._ndarray
> import numarray._numarray
> import numarray._chararray
> import numarray._objectarray
> import numarray.memory
> import numarray._converter
> import numarray._operator
> import numarray._numerictype
> import numarray.libnumarray
> import numarray.libnumeric
> import numarray._ufuncInt64
> import numarray._ufuncUInt64
>
> print numarray.__version__
>
> application = BoaApp(0)
>
> Still no go - but a changed error message.... grrr
Well, that's progress anyway.
>
> I get
>
> Traceback (most recent call last):
> File "AEMdaApp.py", line 81, in ?
> File "AEMdaApp.py", line 41, in main
> File "numarray\__init__.pyc", line 42, in ?
> File "numarray\numarrayall.pyc", line 1, in ?
> File "numarray\numerictypes.pyc", line 35, in ?
> File "numarray\numinclude.pyc", line 4, in ?
> File "numarray\_ndarray.pyc", line 9, in ?
> File "numarray\_ndarray.pyc", line 7, in __load
> ImportError: init_ndarray: can't find memory.new_memory
Is numarray.memory actually present in your install directory? Can you 
CD to that directory and import memory by itself?
> then - probably because I was reading the numarray manual this morning 
> - I went to my numarray install and decided to run testall.py
>
> I got
There's two things going on here. (1) This manner of running the 
numarray self-tests isn't recommended since it doesn't work anywhere. 
Read Doc/INSTALL.txt for how to run them. (2) There's bit-rot in 
numarray CVS for windows.
I'm working on the rot now.
> F:\Python24\Lib\site-packages\numarray>\python24\python testall.py
> Testing numarray 1.3.3 on normal Python (2, 4, 1, 'final', 0) on 
> platform win32
> **********************************************************************
> File "F:\python24\lib\site-packages\numarray\numtest.py", line 2843, 
> in cache p
> ss
> Failed example:
> cPickle.loads(cPickle.dumps(arange(5)+1j))
> Exception raised:
> Traceback (most recent call last):
> File "F:\Python24\lib\doctest.py", line 1243, in __run
> compileflags, 1) in test.globs
> File "<doctest cache pass[968]>", line 1, in ?
> PicklingError: Can't pickle <built-in function 
> memory_from_string>: it's no
> the same object as memory.memory_from_string
> **********************************************************************
> File "F:\python24\lib\site-packages\numarray\numtest.py", line 2849, 
> in cache p
> ss
> Failed example:
> p = p.dump(a)
> Exception raised:
> Traceback (most recent call last):
> File "F:\Python24\lib\doctest.py", line 1243, in __run
> compileflags, 1) in test.globs
> File "<doctest cache pass[973]>", line 1, in ?
> PicklingError: Can't pickle <built-in function 
> memory_from_string>: it's no
> the same object as memory.memory_from_string
> **********************************************************************
> File "F:\python24\lib\site-packages\numarray\numtest.py", line 2850, 
> in cache p
> ss
> Failed example:
> p = p.dump(b)
> Exception raised:
>
> and so on for quite some time.
>
> Hmm the message about
> memory.memory_from_string
> and my applications
> ImportError: init_ndarray: can't find memory.new_memory
>
> are these a little related? Am I clutching at straws?
>
> Yet my app runs fine under any ide I wish to use.
>
> WAIT! - my install of numarray is broken....
> I deleted it and reinstalled - still broken
I'm a little confused here. How is numarray installed where your 
application actually works? How is numarray installed where numarray 
does not work? (I was under the impression that you're using a tool to 
build a self-contained installer... which isn't working. I figured your 
development systems have numarray installed independently... which is 
working. What are you doing?)
> I installed on my laptop and tested - broken there too
>
> My legacy python 2.3 and numarray 1.3.3 installation passes all the 
> tests just fine.
>
> Is there a problem with python2.4.1 and numarray 1.3.3?
Nope.
> Could some kind soul build me a numarray windows installer for python 
> 2.4 from cvs - please - so that I can see if that works better with 
> py2exe.
Let me know if you still want this and I'll make one for you.
FYI, MinGW works great for matplotlib but you may have to 
row-your-own-boat when it comes to numarray. As far as I know, there 
are missing glibc dependencies for numarray, particularly IEEE 
exception handling.
Regards,
Todd

>>>>> "Chris" == Chris Barker <Chr...@no...> writes:
 Chris> I still think it's worth talking to the author, however. As
I emailed him yesterday. No response yet though.
 Chris> Another, semi-related, thought: I feel strongly that MPL
 Chris> should focus on being a plotting library, NOT a full blown
 Chris> computational environment. That should be the focus of
 Chris> SciPy. Therefore, code to interpolate unstructured data
 Chris> would be better put into SciPy than MPL. Same licensing
 Chris> issues, of course.
I think all of the mpl math/stats stuff will eventually end up in
scipy as matplotlib becomes more tightly integrated with the new
scipy. I've talked to Travis about that on a number of occasions and
he is pulling some stuff out of mlab already.
I think it is fine and good to put this kind of stuff into matplotlib
in the meantime while we get the integration and installation issues
sorted out.
JDH

Jeff Whitaker wrote:
> Robert: But this refers to modifications made to it "in the same 
> file". The way I read this, if we don't change his source files we 
> can redistribute them any way we want, as long as we leave the CSIRO 
> copyright notices alone.
I think Robert already answered this one: while we cold do that, we 
would then be distributing code with MPL that carried extra 
restrictions, so that MPL users couldn't modify it at will. I agree that 
this is to be avoided.
Perhaps it's time to start a SciPy-extras collection that includes code 
under other, weird licenses.
This would be SO much easier of people throwing their code out on the 
Internet would just use one of the common licensing schemes.
I still think it's worth talking to the author, however. As Robert 
pointed out, these folks are clearly not all that cluefull about open 
source licenses. They may have little idea what they really are 
restricting. As a simple example, someone on the wxPython list has been 
developing a bunch of nifty higher-level widgets, hoping to get them 
included in the wxPython lib. However, he had released them all under 
the GPL, just because he didn't know any better. When someone wrote to 
him, pointing out that his stuff couldn't be used in any non-GPL 
projects, it turns out that wasn't his intent. I think he's going to 
re-release it all under the wxWidgets license (modified LGPL).
However, it looks like this one may be standard CSIRO policy, so the 
author may have no choice, and changing an institutional policy is MUCH 
harder!
Another, semi-related, thought: I feel strongly that MPL should focus on 
being a plotting library, NOT a full blown computational environment. 
That should be the focus of SciPy. Therefore, code to interpolate 
unstructured data would be better put into SciPy than MPL. Same 
licensing issues, of course.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On Oct 20, 2005, at 10:16 AM, Ryan Krauss wrote:
> It really isn't. I can cause the problem with just the line 
> pylab.figure(1).
I'm on a roll today: when I sent that reply I hadn't seen your latest 
email.
Anyways, I have been unable to reproduce this problem under Debian 
sarge (wxPython 2.4). I don't think I have access to a Ubuntu box, but 
I will check to see if the problem also exists under Debian sid 
(wxPython 2.6).
Ken