From l.widdershoven at fz-juelich.de Fri Nov 1 06:59:33 2002 From: l.widdershoven at fz-juelich.de (Leon Widdershoven) Date: Fri, 1 Nov 2002 12:59:33 +0100 Subject: [SciPy-user] Compiling with weave and g++ 3.2 Message-ID: <200211011259.33445.l.widdershoven@fz-juelich.de> Hi, I wrote some code using weave.inline, and this code would not compile due to random_access_iterator: no such class. I read that this has been an issue, but could not find an answer. I have in the mean time found a way to compile the code: in Config.hxx I changed STANDARD_LIBRARY_HAS_ITERATOR_TRAITS 1 to STANDARD_LIBRARY_HAS_ITERATOR_TRAITS 0 I Don't know what it does, but at least my code runs again. Regards, Leon Widdershoven From steven.robbins at videotron.ca Fri Nov 1 17:34:29 2002 From: steven.robbins at videotron.ca (Steve M. Robbins) Date: Fri, 01 Nov 2002 17:34:29 -0500 Subject: [SciPy-user] Debian package(s)? In-Reply-To: <20021028202754.GC6246@jowls.lairds.com> References: <20021028202754.GC6246@jowls.lairds.com> Message-ID: <20021101223428.GN7658@nyongwa.montreal.qc.ca> On Mon, Oct 28, 2002 at 03:27:54PM -0500, Kyler Laird wrote: > Will SciPy be a Debian package soon? I'd like to > have some people start using it. I guess that Joe Reinhardt is best-placed to answer that. [c.f. http://bugs.debian.org/126037] The latest build on his web page is a CVS snapshot of 2002-07-24. However, it's built using python 2.1 and so it doesn't install on a recent "sid" box. I'm guessing that one hold-up is that scipy 0.2 hasn't been officially released. Joe? -S From kyari_bundi at lycos.com Sat Nov 2 12:21:20 2002 From: kyari_bundi at lycos.com (BUNDI KYARI) Date: Sat, 02 Nov 2002 12:21:20 Subject: [SciPy-user] Urgent Assistance Message-ID: <20021102113031.8493C3EAD9@www.scipy.com> FROM:BUNDI KYARI. TEL: E-mail: kyaribundi at netscape.net AMSTERDAM THE NETHERLANDS. Dear sir, compliment of the day, I am BUNDI KYARI, The son of late General Kubwa Kyari of the Democratic Republic of Congo. My father was a General in the Congolese Army. In his position (My father) with the office of the presidentcy during the regime of Laurent Kabila, he was assigned on a secret mission to source and acquire arms internationally in order to strengthen the Government forces against the rebels, which already had the support of Rwandan and Uganda Army. Meanwhile, he was still negotiating for the purchase of the arms, he received on the 16th January 2001 news of the assassination of Laurent Kabila which force him to call off the assignment and deposited the sum of US$12.5M, Packed in a diplomatic case in a private security company in the Amsterdam, the Netherlands, though he registered the content as precious stones while the real content is (US12.5M) meant for the purchase of arms for the Congolese Army. My father went home for the funeral of the late president, but on his arrival he was arrested, detained and tortured, unfortunately my father suffer cardiac arrest and died on the 17th of March 2001. However, on one of our numerous visits, my mother and I paid him while in prison, my father was able to reveal this secret to me and advice that i should proceed to the Netherlands to claim the money, he handed me all the relevant documents that will enable me claim the box from the security company. Already, I have made my first visit to the security company and the availability of this box have been confirmed. On our arrival in the Netherlands few months ago, we sought for political asylum; which was granted. My mother and I are making frantic effort on the best way to handle this money. We sought advice from an attorney who advised that we must seek for a trustworthy foreign business partner whom this money could be transferred into his/her (company"s) account This we view as the best option because our refugee status dose not permit us to operate a bank account, hence we seek your assistance and hope you could be trusted. I got your contact from the commercial section of the congolese embassy in Belgium.Meanwhile, I sincerely ask for your assistance to get this money through your account, Your share for assisting us will be 25% of the total sum, 5% will be use for upsetting all the expenses incurred in the course of concluding this venture and the remaining 70% that will be for me and my family. Also you stand to gain from any investment you might introduce us into after the conclusion of the transfer. Please keep this confidential until we finalize and get this money into your account for security reasons. This is my e-mail address you can reach me: kyaribundi at netscape.net Thanks and GOD bless MR, BUNDI KYARI. From nmarais at hertz.ee.sun.ac.za Sat Nov 2 19:24:12 2002 From: nmarais at hertz.ee.sun.ac.za (Neilen) Date: 03 Nov 2002 02:24:12 +0200 Subject: [SciPy-user] Getting postscript out of gplt Message-ID: <1036283052.32195.205.camel@stoomtrein> Hi. I'm trying to get some postscript output of a gplt plot. Is there somewhere I can find more documentation on the gplt.output function? basically, I want the plot to be black and white, with a white background. I tried replacing the png example from the plotting tutorial with ps, eps and postscript, to no avail. Thanks Neilen -- all we are waiting for is something worth waiting for --- KMFDM From nmarais at hertz.ee.sun.ac.za Sat Nov 2 19:35:16 2002 From: nmarais at hertz.ee.sun.ac.za (Neilen) Date: 03 Nov 2002 02:35:16 +0200 Subject: [SciPy-user] Getting postscript out of gplt In-Reply-To: <1036283052.32195.205.camel@stoomtrein> References: <1036283052.32195.205.camel@stoomtrein> Message-ID: <1036283716.30153.209.camel@stoomtrein> OK, I found it :) Just for the archives, the command is gplt.output("filname", "postscript eps"). The format seems to correspond to "set termimal xxx" command in gnuplot. Cheers Neilen On Sun, 2002-11-03 at 02:24, Neilen wrote: > Hi. > > I'm trying to get some postscript output of a gplt plot. Is there > somewhere I can find more documentation on the gplt.output function? > basically, I want the plot to be black and white, with a white > background. I tried replacing the png example from the plotting > tutorial with ps, eps and postscript, to no avail. > > Thanks > Neilen > -- > all we are waiting for is something worth waiting for > --- KMFDM > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user -- all we are waiting for is something worth waiting for --- KMFDM From nmarais at hertz.ee.sun.ac.za Sat Nov 2 19:54:56 2002 From: nmarais at hertz.ee.sun.ac.za (Neilen) Date: 03 Nov 2002 02:54:56 +0200 Subject: [SciPy-user] Including LaTeX commands in the output of a gplt plot Message-ID: <1036284896.30153.212.camel@stoomtrein> Hi. I have, since my last mail, also found out that I can get output straight into LaTeX. Sweet. Now, it would be even more fantastic if I can include \whatever command in the titles. It seems gplt strips off the \. Is there any way this may be done? Thanks Neilen -- all we are waiting for is something worth waiting for --- KMFDM From skip at pobox.com Fri Nov 1 19:54:28 2002 From: skip at pobox.com (Skip Montanaro) Date: Fri, 1 Nov 2002 18:54:28 -0600 Subject: [SciPy-user] Debian package(s)? In-Reply-To: <20021101223428.GN7658@nyongwa.montreal.qc.ca> References: <20021028202754.GC6246@jowls.lairds.com> <20021101223428.GN7658@nyongwa.montreal.qc.ca> Message-ID: <15811.8772.728335.271062@montanaro.dyndns.org> >> Will SciPy be a Debian package soon? I'd like to >> have some people start using it. Steve> I guess that Joe Reinhardt is best-placed to answer that. Steve> [c.f. http://bugs.debian.org/126037] SciPy is available from Fink (the project to make many open source packages available on MacOSX), which uses Debian's packaging mechanism. Fink's at http://fink.sf.net/ Skip From nmarais at hertz.ee.sun.ac.za Sun Nov 3 12:12:41 2002 From: nmarais at hertz.ee.sun.ac.za (Neilen) Date: 03 Nov 2002 19:12:41 +0200 Subject: [SciPy-user] Vector plot using gplt Message-ID: <1036343561.32195.217.camel@stoomtrein> Hi I'd like to do a vector plot of a 2D field. If I remember correctly, the matlab quiver() command would have made this easy. Looking at the gnuplot manual, I see it has a "set arrow" command, which looks like it might help me. Is there any way I can talk to gnuplot on the level where I can do set command from scipy? Or are there any other (easier?) possibilities? Thanks Neilen -- all we are waiting for is something worth waiting for --- KMFDM From J.Ferguson at dta.mil.nz Sun Nov 3 16:11:39 2002 From: J.Ferguson at dta.mil.nz (John A Ferguson) Date: Mon, 4 Nov 2002 10:11:39 +1300 Subject: [SciPy-user] signal.iirdesign throws a TypeError on Win32, any idea why, or what I'm doing wrong ? Message-ID: <005801c2837d$99aa7130$b9680cca@dse.govt.nz> My Setup is binary installs as follows onto Win2K SP3: Python-2.2.2.exe win32all-148.exe wxPythonWIN32-2.3.3.1-Py22.exe Numeric-22.0.win32-py2.2.exe SciPy-0.2.0_alpha_145.4398.win32-py2.2.exe Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from scipy import signal >>> signal.iirdesign(0.2, 0.3, 3, 40) Traceback (most recent call last): File "", line 1, in ? File "C:\Python22\Lib\site-packages\scipy\signal\filter_design.py", line 378, in iirdesign return iirfilter(N, Wn, rp=gpass, rs=gstop, analog=analog, btype=btype, ftyp e=ftype, output=output) File "C:\Python22\Lib\site-packages\scipy\signal\filter_design.py", line 448, in iirfilter z, p, k = typefunc(N, rp, rs) File "C:\Python22\Lib\site-packages\scipy\signal\filter_design.py", line 1052, in ellipap disp=0) File "C:\Python22\Lib\site-packages\scipy\optimize\optimize.py", line 145, in fmin fsim[0] = apply(func,(x0,)+args) File "C:\Python22\Lib\site-packages\scipy\signal\filter_design.py", line 1016, in kratio k = special.ellipk([m,1-m]) TypeError: bad argument type for built-in operation >>> From mike_sorich at hotmail.com Sun Nov 3 20:49:08 2002 From: mike_sorich at hotmail.com (Michael Sorich) Date: Mon, 4 Nov 2002 12:19:08 +1030 Subject: [SciPy-user] Way to get values which are the same on two arrays Message-ID: <000401c283a4$5d593dc0$8205120a@MikesLaptop> Hi Jos?, I remember reading your question last week. Coincidently, I have just written a function to find the intersection of 2 sets (using a histogram function) for my own work. I'm not sure if it is the most efficient method, but it seems to work. from Numeric import * def histogram(a, bins): """counts the number of values in a that fall into each of the bins in bin""" n = searchsorted(sort(a),bins) n = concatenate([n,[len(a)]]) return asarray(n[1:]-n[:-1]) def intersection(a,b): """takes two 1D arrays and returns an array of values that are in both arrays""" if a.typecode() != 'l' or b.typecode() != 'l': raise ValueError, "arrays must be of type Int" #make bins from intersection of ranges minab = max([minimum.reduce(a),minimum.reduce(b)]) maxab = min([maximum.reduce(a),maximum.reduce(b)]) # -> If either set is empty, or their ranges don't intersect if maxab < minab or maxab < 0: return None bins = arange(minab,maxab+1) return minab+nonzero(logical_and(histogram(a,bins),histogram(b,bins))) if __name__ == '__main__': a = array([1,2,3,4,6]) b = array([4,5,6,1,7]) print intersection(a,b) Hope this helps, Michael Sorich PhD Student School of Pharmaceutical, Molecular and Biomedical Sciences University of South Australia Email: michael.sorich at postgrads.unisa.edu.au mike_sorich at hotmail.com -------------------------------- Hi, I seem to remember a Numerical function that could produce the list of values (or array positions) which are common to two arrays. In other words: a1=[1,2,3,9,10] a2=[1,4,9,10] result is [1,9,10]. Browsing through the Numerical docs doesn't refresh my memory, so any kind souls? many thanks, Jos? -- Jos? L G?mez Dans PhD student Tel: +44 114 222 5582 Radar & Communications Group FAX; +44 870 132 2990 Department of Electronic Engineering University of Sheffield UK --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.408 / Virus Database: 230 - Release Date: 24/10/2002 From nwagner at mecha.uni-stuttgart.de Mon Nov 4 06:34:36 2002 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Mon, 04 Nov 2002 12:34:36 +0100 Subject: [SciPy-user] ODE solver's in scipy Message-ID: <3DC65B4C.48F6BCB8@mecha.uni-stuttgart.de> Hi, How can I solve the following ODE in scipy A(t,z) \dot{z} = f(z), z(0) = z_0 where A is a real matrix depending on t and z; \dot denotes derivative with respect to time t. Nils From kern at caltech.edu Mon Nov 4 06:37:31 2002 From: kern at caltech.edu (Robert Kern) Date: Mon, 4 Nov 2002 03:37:31 -0800 Subject: [SciPy-user] ODE solver's in scipy In-Reply-To: <3DC65B4C.48F6BCB8@mecha.uni-stuttgart.de> References: <3DC65B4C.48F6BCB8@mecha.uni-stuttgart.de> Message-ID: <20021104113731.GA10246@taliesen.caltech.edu> On Mon, Nov 04, 2002 at 12:34:36PM +0100, Nils Wagner wrote: > Hi, > > How can I solve the following ODE in scipy > > A(t,z) \dot{z} = f(z), z(0) = z_0 > > where A is a real matrix depending on t and z; > \dot denotes derivative with respect to time t. from scipy import linalg, integrate def A(t,z): ... def f(z): ... def F(z, t): return linalg.solve(A(t,z), f(z)) t = arange(0, 100, 0.1) # or whatever z0 = array([...]) z = integrate.odeint(F, z0, t) -- Robert Kern Ruddock House President kern at caltech.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From nwagner at mecha.uni-stuttgart.de Mon Nov 4 07:51:19 2002 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Mon, 04 Nov 2002 13:51:19 +0100 Subject: [SciPy-user] ODE solver's in scipy References: <3DC65B4C.48F6BCB8@mecha.uni-stuttgart.de> <20021104113731.GA10246@taliesen.caltech.edu> Message-ID: <3DC66D47.ECCB2F7A@mecha.uni-stuttgart.de> Robert Kern schrieb: > > On Mon, Nov 04, 2002 at 12:34:36PM +0100, Nils Wagner wrote: > > Hi, > > > > How can I solve the following ODE in scipy > > > > A(t,z) \dot{z} = f(z), z(0) = z_0 > > > > where A is a real matrix depending on t and z; > > \dot denotes derivative with respect to time t. > > from scipy import linalg, integrate > > def A(t,z): > ... > > def f(z): > ... > > def F(z, t): > return linalg.solve(A(t,z), f(z)) > > t = arange(0, 100, 0.1) # or whatever > z0 = array([...]) > > z = integrate.odeint(F, z0, t) > Thank you for your prompt reply. I have tried to transfer your suggestion to my problem. However, I get some errors. Traceback (most recent call last): File "ivp.py", line 46, in F return linalg.solve(A(P, Pl, M, K, t,z), f(P, M, K, z)) File "ivp.py", line 37, in A A[0:n,0:n] = (1.0-t)*(K[0:n,0:n]-z[n]*M[0:n,0:n])+t*P[0:n,0:n] TypeError: unsubscriptable object odepack.error: Error occured while calling the Python function named F So, what has to be amended in my program ivp.py ? Nils > -- > Robert Kern > Ruddock House President > kern at caltech.edu > > "In the fields of hell where the grass grows high > Are the graves of dreams allowed to die." > -- Richard Harter > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user -------------- next part -------------- from scipy import * from scipy import linalg, integrate # # A homotopy method for a nonlinear eigenvalue problem # # h = (1-t) [K x-lambda M x] + t P(lambda) x = 0 # 0.5*(x^T x -1) = 0 # n = 3 # # Linear eigenvalue problem : K x = lambda M x # K = array(([1.0,-1.0,0.0], [-1.0,2.0,-1.0], [0.0,-1.0,2.0])) # M = array(([2.0,1.0,0.0], [1.0,4.0,1.0], [0.0,1.0,4.0]))/6.0 # w, vr = linalg.eig(K,M) def P(t,z): P = array(([z[n]/tan(z[n]),-z[n]/sin(z[n]),0.0], [-z[n]/sin(z[n]),2.0*z[n]/tan(z[n]),-z[n]/sin(z[n])], [0.0,-z[n]/sin(z[n]),2.0*z[n]/tan(z[n])])) def Pl(t,z): Pl = array(([cos(z[n])-z[n],z[n]*cos(z[n])-sin(z[n]),0.0], [z[n]*cos(z[n])-sin(z[n]),2.0*(cos(z[n])-z[n]),z[n]*cos(z[n])-sin(z[n])], [0.0,z[n]*cos(z[n])-sin(z[n]),2.0*(cos(z[n])-z[n])]))/sin(z[n])**2 def A(P, Pl, M, K, t,z): A = zeros((n+1,n+1),Float) A[0:n,0:n] = (1.0-t)*(K[0:n,0:n]-z[n]*M[0:n,0:n])+t*P[0:n,0:n] A[n:0,n] = -(1-t)*dot(M,z[0:n])+t*dot(Pl,z[0:n]) A[n:0,n] = z[0:n] def f(P, M, K, z): f = zeros(n+1,Float) f[0:n] = dot(K,z[0:n])-z[n]*dot(M,z[0:n])-dot(P,z[0:n]) def F(z, t): return linalg.solve(A(P, Pl, M, K, t,z), f(P, M, K, z)) t = arange(0, 0.1, 0.05) # or whatever z0=zeros(n+1,Float) z0[0:n] = vr[:,0] z0[n] = abs(w[0]) print z0 z = integrate.odeint(F, z0, t) print 'Eigenvector',vr[:,0] print 'Eigenvalue',w[0] print z From kern at caltech.edu Mon Nov 4 08:24:11 2002 From: kern at caltech.edu (Robert Kern) Date: Mon, 4 Nov 2002 05:24:11 -0800 Subject: [SciPy-user] ODE solver's in scipy In-Reply-To: <3DC66D47.ECCB2F7A@mecha.uni-stuttgart.de> References: <3DC65B4C.48F6BCB8@mecha.uni-stuttgart.de> <20021104113731.GA10246@taliesen.caltech.edu> <3DC66D47.ECCB2F7A@mecha.uni-stuttgart.de> Message-ID: <20021104132411.GA14220@taliesen.caltech.edu> On Mon, Nov 04, 2002 at 01:51:19PM +0100, Nils Wagner wrote: [snip] > Traceback (most recent call last): > File "ivp.py", line 46, in F > return linalg.solve(A(P, Pl, M, K, t,z), f(P, M, K, z)) > File "ivp.py", line 37, in A > A[0:n,0:n] = (1.0-t)*(K[0:n,0:n]-z[n]*M[0:n,0:n])+t*P[0:n,0:n] > TypeError: unsubscriptable object > odepack.error: Error occured while calling the Python function named F > > So, what has to be amended in my program ivp.py ? First, you must return values from functions, not assign values to the name of the function. Incorrect: def A(): A = zeros(...) Correct: def A(): return zeros(...) or def A(): tmp = zeros(...) tmp[n,:] = ... return tmp Secondly, I don't think you are indexing correctly in A(). A[0:n,0:n] references the whole array, not just the diagonal. To reference a diagonal, A.flat[0:n:n+1] works if A is still contiguous. (Side-question to everybody else: Is there a convenience function somewhere in Numeric or scipy_base that allows setting the k-diagonal of a matrix? A.flat[0:n:n+1]?) Third, (this is what's causing the exception) you aren't actually calling P(t,z) and Pl(t,z) so Python is trying to index a function. I've attached my modifications. By the way, is z[n] supposed to change? Because the return value of F() has n elements, not n+1. I'm surprised the code runs, but it does. If it doesn't change, then you shouldn't have to recalculate P or Pl all the time. I have to hit the sack now, so I'll try to get back to this tomorrow. > Nils -- Robert Kern Ruddock House President kern at caltech.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter -------------- next part -------------- from scipy import * from scipy import linalg, integrate n = 3 # # Linear eigenvalue problem : K x = lambda M x # K = array(([1.0,-1.0,0.0], [-1.0,2.0,-1.0], [0.0,-1.0,2.0])) # M = array(([2.0,1.0,0.0], [1.0,4.0,1.0], [0.0,1.0,4.0]))/6.0 # w, vr = linalg.eig(K,M) def P(t,z): return array(([z[n]/tan(z[n]),-z[n]/sin(z[n]),0.0], [-z[n]/sin(z[n]),2.0*z[n]/tan(z[n]),-z[n]/sin(z[n])], [0.0,-z[n]/sin(z[n]),2.0*z[n]/tan(z[n])])) def Pl(t,z): return array(([cos(z[n])-z[n],z[n]*cos(z[n])-sin(z[n]),0.0], [z[n]*cos(z[n])-sin(z[n]),2.0*(cos(z[n])-z[n]),z[n]*cos(z[n])-sin(z[n])], [0.0,z[n]*cos(z[n])-sin(z[n]),2.0*(cos(z[n])-z[n])]))/sin(z[n])**2 def A(P, Pl, M, K, t,z): tmp = zeros((n,n),Float) tmp.flat[0:n:n+1] = (1.0-t)*(K.flat[0:n:n+1]-z[n]*M.flat[0:n:n+1])+t*P.flat[0:n:n+1] tmp[0:n,n-1] = -(1-t)*dot(M,z[:n])+t*dot(Pl,z[:n]) tmp[n-1,0:n] = z[:n] return tmp def f(P, M, K, t, z): tmp = dot(K,z[:n])-z[n]*dot(M,z[:n])-dot(P,z[:n]) tmp[n-1] = 0.0 return tmp def F(z, t): p = P(t,z) pl = Pl(t,z) x = linalg.solve(A(p, pl, M, K, t, z), f(p, M, K, t, z)) return x t = arange(0, 0.1, 0.05) # or whatever z0=zeros(n+1,Float) z0[0:n] = vr[:,0] z0[n] = abs(w[0]) print z0 z = integrate.odeint(F, z0, t) print z From nwagner at mecha.uni-stuttgart.de Mon Nov 4 08:44:04 2002 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Mon, 04 Nov 2002 14:44:04 +0100 Subject: [SciPy-user] ODE solver's in scipy References: <3DC65B4C.48F6BCB8@mecha.uni-stuttgart.de> <20021104113731.GA10246@taliesen.caltech.edu> <3DC66D47.ECCB2F7A@mecha.uni-stuttgart.de> <20021104132411.GA14220@taliesen.caltech.edu> Message-ID: <3DC679A4.89116DCF@mecha.uni-stuttgart.de> Robert Kern schrieb: > > On Mon, Nov 04, 2002 at 01:51:19PM +0100, Nils Wagner wrote: > > [snip] > > > Traceback (most recent call last): > > File "ivp.py", line 46, in F > > return linalg.solve(A(P, Pl, M, K, t,z), f(P, M, K, z)) > > File "ivp.py", line 37, in A > > A[0:n,0:n] = (1.0-t)*(K[0:n,0:n]-z[n]*M[0:n,0:n])+t*P[0:n,0:n] > > TypeError: unsubscriptable object > > odepack.error: Error occured while calling the Python function named F > > > > So, what has to be amended in my program ivp.py ? > > First, you must return values from functions, not assign values to the > name of the function. > > Incorrect: > > def A(): > A = zeros(...) > > Correct: > > def A(): > return zeros(...) > > or > > def A(): > tmp = zeros(...) > tmp[n,:] = ... > return tmp > > Secondly, I don't think you are indexing correctly in A(). A[0:n,0:n] > references the whole array, not just the diagonal. > > To reference a diagonal, A.flat[0:n:n+1] works if A is still contiguous. > > (Side-question to everybody else: Is there a convenience function > somewhere in Numeric or scipy_base that allows setting the k-diagonal of > a matrix? A.flat[0:n:n+1]?) > > Third, (this is what's causing the exception) you aren't actually > calling P(t,z) and Pl(t,z) so Python is trying to index a function. > > I've attached my modifications. By the way, is z[n] supposed to change? > Because the return value of F() has n elements, not n+1. I'm surprised > the code runs, but it does. If it doesn't change, then you shouldn't > have to recalculate P or Pl all the time. > > I have to hit the sack now, so I'll try to get back to this tomorrow. > > > Nils > > -- Actually, A is a so-called bordered matrix. A = [A_11 a_12; a_21 0] where A_11 = (1-t)*(K-lambda*M)+ t*P a_12 = -(1-t)*M*x + t*Pl*x s_21 = x^T s_22 = 0 The first elements of z should contain the time-varying eigenvector x(t) The last element of z should be the eigenvalue, which varies with time, that is lambda=lambda(t). Nils > Robert Kern > Ruddock House President > kern at caltech.edu > > "In the fields of hell where the grass grows high > Are the graves of dreams allowed to die." > -- Richard Harter > > ------------------------------------------------------------------------ > > ivp_kern.pyName: ivp_kern.py > Type: Plain Text (text/plain) From jmr at engineering.uiowa.edu Mon Nov 4 08:32:14 2002 From: jmr at engineering.uiowa.edu (Joe Reinhardt) Date: Mon, 04 Nov 2002 07:32:14 -0600 Subject: [SciPy-user] Debian package(s)? In-Reply-To: <20021101223428.GN7658@nyongwa.montreal.qc.ca> ("Steve M. Robbins"'s message of "Fri, 01 Nov 2002 17:34:29 -0500") References: <20021028202754.GC6246@jowls.lairds.com> <20021101223428.GN7658@nyongwa.montreal.qc.ca> Message-ID: <87of95795t.fsf@phantom.ecn.uiowa.edu> The hold up is my fault - I use scipy for my own work, but need something that is reasonably stable. I had trouble tracking the frequent changes to CVS and deciding when to take a snapshot for packaging. scipy depends on f2py, which is not in debian. Also, scipy won't build with the atlas that is distributed with debian. Thus, this makes it difficult for me to build without first rebuilding atlas. And because of the atlas dependency, I don't think scipy can make it into the main distribution until atlas is updated. (This situation may have changed, since I haven't built scipy since July.) My current (very old, but stable) snapshot (source and deb) is at http://people.debian.org/~jmr. If someone has the time and energy to update this for debian, please go ahead and take it over. - Joe "Steve M. Robbins" writes: > On Mon, Oct 28, 2002 at 03:27:54PM -0500, Kyler Laird wrote: >> Will SciPy be a Debian package soon? I'd like to >> have some people start using it. > > I guess that Joe Reinhardt is best-placed to answer that. > [c.f. http://bugs.debian.org/126037] > > The latest build on his web page is a CVS snapshot of 2002-07-24. > However, it's built using python 2.1 and so it doesn't install on a > recent "sid" box. > > I'm guessing that one hold-up is that scipy 0.2 hasn't > been officially released. Joe? > > -S > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > From produced2many2002 at yahoo.com Mon Nov 4 14:08:14 2002 From: produced2many2002 at yahoo.com (produced2many2002 at yahoo.com) Date: pon, 4 stu 2002 16:22:52 Subject: [SciPy-user] A job for you !!! Message-ID: <20021104190814.913D83EAD4@www.scipy.com> Hi! We are offering you a possibility to use your free time and make some money over the internet. This is a global business with warranty. As this is a serious business we expect from our candidates the following: - minimum 18 years of age - desire for team work If you are interested you can find more information about this job on Page http://bestbussines4you.5u.com/main.html or http://www.geocities.com/miso_blazevic/online_bussines.html Application is absolutely free and it doesn?t obligate you for anything and you can quit whenever you like. This is a simple way for you to familiarize yourself with a job we are offering and to decide if this is for you. Some of our members already make more then $1500 monthly and there is no limit because income isn?t fixed and raises with every month depending on how much time you put in. No, you don?t have to sell or buy anything. Nobody here is trying to double-cross you. This is a very serious job. I believe you won?t be disappointed. I hope we will work together. If you have any questions or the page doesn't work please contact on this address blazevic_m at hotmail.com Miso Blazevic You've received this message only once and if this doesn't interest you I apologize and I won't inform you any more. From pearu at cens.ioc.ee Mon Nov 4 15:01:19 2002 From: pearu at cens.ioc.ee (pearu at cens.ioc.ee) Date: Mon, 04 Nov 2002 22:01:19 +0200 (EET) Subject: [SciPy-user] Debian package(s)? In-Reply-To: <87of95795t.fsf@phantom.ecn.uiowa.edu> References: <20021028202754.GC6246@jowls.lairds.com> <20021101223428.GN7658@nyongwa.montreal.qc.ca> <87of95795t.fsf@phantom.ecn.uiowa.edu> Message-ID: <1036440079.3dc6d20fa6dfc@cens.ioc.ee> Quoting Joe Reinhardt : > > The hold up is my fault - I use scipy for my own work, but need > something that is reasonably stable. I had trouble tracking the > frequent changes to CVS and deciding when to take a snapshot for > packaging. > > scipy depends on f2py, which is not in debian. As Skip mentioned already, both f2py and scipy have been packed under Fink using debian tools. So, it\'s possible. > Also, scipy won\'t > build with the atlas that is distributed with debian. Thus, this > makes it difficult for me to build without first rebuilding atlas. > And because of the atlas dependency, I don\'t think scipy can make it > into the main distribution until atlas is updated. (This situation > may have changed, since I haven\'t built scipy since July.) This situation is changed indeed. Now Scipy builds with debian atlas without problems. See scipy/INSTALL.txt for additional notes about debian support. > My current (very old, but stable) snapshot (source and deb) is at > http://people.debian.org/~jmr. If someone has the time and energy to > update this for debian, please go ahead and take it over. I will but may be not in the coming month. Pearu From stephen.walton at csun.edu Mon Nov 4 17:53:19 2002 From: stephen.walton at csun.edu (Stephen Walton) Date: 04 Nov 2002 14:53:19 -0800 Subject: [SciPy-user] Absoft Compiler In-Reply-To: <20021104190814.913D83EAD4@www.scipy.com> References: <20021104190814.913D83EAD4@www.scipy.com> Message-ID: <1036450400.18890.10.camel@sunspot> Well, a mere four months after the SciPy conference in Pasadena (thanks all!), I have finally built SciPy. I include the output of some of the diagnostic commands after my signature, but to summarize: I built LAPACK, ATLAS, and SciPy from source using the Absoft F77 compiler v4.6 and gcc v3.2 on RedHat 8.0. scipy.test(level=1) fails with the following error: Traceback (most recent call last): File "/usr/lib/python2.2/site-packages/scipy/stats/tests/test_morestats.py", line 30, in check_basic assert_almost_equal(w,0.90047299861907959,7) File "/usr/lib/python2.2/site-packages/scipy_test/testing.py", line 335, in assert_almost_equal assert round(abs(desired - actual),decimal) == 0, msg AssertionError: Items are not equal: DESIRED: 0.90047299861907959 ACTUAL: 0.90047270059585571 There are a couple of additional problems: the SciPy install didn't detect that I have the fftw libraries installed (from the RPM), and the test suite complains up near the top about the lack of a test_matfuncs module. -- Stephen Walton, Professor of Physics and Astronomy, California State University, Northridge stephen.walton at csun.edu Script started on Mon Nov 4 14:46:40 200 hector:~> python -c 'import os,sys;print os.name,sys.platform' posix linux2 hector:~> uname -a Linux hector 2.4.18-17.8.0 #1 Tue Oct 8 11:48:09 EDT 2002 i686 athlon i386 GNU/Linux hector:~> gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --host=i386-redhat-linux --with-system-zlib --enable-__cxa_atexit Thread model: posix gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7) hector:~> python -c 'import sys;print sys.version' 2.2.1 (#1, Aug 30 2002, 12:15:30) [GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] hector:~> python -c 'import Numeric;print Numeric.__version__' 22.0 hector:~> f2py -v 2.23.190-1369 hector:~> cd /local/swalton/src/scipy/linalg hector:/local/swalton/src/scipy/linalg> python setup_atlas_version.py build_ext --inplace --force atlas_info: FOUND: libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/local/lib/atlas'] running build_ext building 'atlas_version' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.2 -c /local/swalton/src/scipy/linalg/atlas_version.c -o build/temp.linux-i686-2.2/atlas_version.o gcc -shared build/temp.linux-i686-2.2/atlas_version.o -L/usr/local/lib/atlas -latlas -o atlas_version.so hector:/local/swalton/src/scipy/linalg> python -c 'import atlas_version' ATLAS version 3.4.1 built by swalton on Mon Nov 4 11:44:16 PST 2002: UNAME : Linux hector 2.4.18-17.8.0 #1 Tue Oct 8 11:48:09 EDT 2002 i686 athlon i386 GNU/Linux INSTFLG : MMDEF : /local/swalton/src/ATLAS/CONFIG/ARCHS/ATHLON/gcc/gemm ARCHDEF : /local/swalton/src/ATLAS/CONFIG/ARCHS/ATHLON/gcc/misc F2CDEFS : -DAdd_ -DStringSunStyle CACHEEDGE: 131072 F77 : /usr/absoft/bin/f77, version F77FLAGS : -O CC : /usr/bin/gcc, version gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) CC FLAGS : -fomit-frame-pointer -O3 -funroll-all-loops MCC : /usr/bin/gcc, version gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) MCCFLAGS : -fomit-frame-pointer -O hector:/local/swalton/src/scipy/linalg> python scipy_distutils/system_info.py python: can't open file 'scipy_distutils/system_info.py' hector:/local/swalton/src/scipy> python scipy_distutils/command/build_flib.py Absoft 4.6 Gnu 3.2 hector:/local/swalton/src/scipy> python scipy_distutils/command/build_flib.py44Dlcd /local/swalton/src/scipy/28Dpython scipy_distutils/command/build_flib.py21Dsystem_info.pyK atlas_info: FOUND: libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/local/lib/atlas'] blas_info: NOT AVAILABLE blas_src_info: NOT AVAILABLE dfftw_info: NOT AVAILABLE dfftw_threads_info: NOT AVAILABLE djbfft_info: NOT AVAILABLE fftw_info: NOT AVAILABLE fftw_threads_info: NOT AVAILABLE lapack_info: NOT AVAILABLE lapack_src_info: NOT AVAILABLE sfftw_info: NOT AVAILABLE sfftw_threads_info: NOT AVAILABLE x11_info: FOUND: libraries = ['X11'] library_dirs = ['/usr/X11R6/lib'] include_dirs = ['/usr/X11R6/include'] hector:/local/swalton/src/scipy> exit exit Script done on Mon Nov 4 14:49:40 200 From oliphant at ee.byu.edu Mon Nov 4 20:11:21 2002 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Mon, 4 Nov 2002 18:11:21 -0700 (MST) Subject: [SciPy-user] Absoft Compiler In-Reply-To: <1036450400.18890.10.camel@sunspot> Message-ID: > Well, a mere four months after the SciPy conference in Pasadena (thanks > all!), I have finally built SciPy. I include the output of some of the > diagnostic commands after my signature, but to summarize: I built > LAPACK, ATLAS, and SciPy from source using the Absoft F77 compiler v4.6 > and gcc v3.2 on RedHat 8.0. scipy.test(level=1) fails with the > following error: > > Traceback (most recent call last): > File > "/usr/lib/python2.2/site-packages/scipy/stats/tests/test_morestats.py", > line 30, in check_basic > assert_almost_equal(w,0.90047299861907959,7) > File "/usr/lib/python2.2/site-packages/scipy_test/testing.py", line > 335, in assert_almost_equal > assert round(abs(desired - actual),decimal) == 0, msg > AssertionError: > Items are not equal: > DESIRED: 0.90047299861907959 > ACTUAL: 0.90047270059585571 > Congradulations. This error should be ignored. Basically, we are requiring too many matching digits (the routine uses single-precision and we should only be interested in 6 significant digits). This is changed. > There are a couple of additional problems: the SciPy install didn't > detect that I have the fftw libraries installed (from the RPM), and the > test suite complains up near the top about the lack of a test_matfuncs > module. There is a site.cfg file where this information can be placed if it is in an unusual location. Welcome to the group.... -Travis O. From Subscriber_Services78057 at skybest.com Tue Nov 5 10:46:32 2002 From: Subscriber_Services78057 at skybest.com (WALL STREET BULLETIN…..46972) Date: Tue, 5 Nov 2002 09:46:32 -0600 Subject: [SciPy-user] NEW STOCK PICK: NVHG - LAST PICK UP 300%......................................................................................................................................................................................................... pgwm Message-ID: <20021105155550.0D88A3EAD9@www.scipy.com> An HTML attachment was scrubbed... URL: From pearu at cens.ioc.ee Tue Nov 5 13:53:37 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Tue, 5 Nov 2002 20:53:37 +0200 (EET) Subject: Detecting fftw (was Re: [SciPy-user] Absoft Compiler) In-Reply-To: Message-ID: On Mon, 4 Nov 2002, Travis Oliphant wrote: > > There are a couple of additional problems: the SciPy install didn't > > detect that I have the fftw libraries installed (from the RPM), and the > > test suite complains up near the top about the lack of a test_matfuncs > > module. > > There is a site.cfg file where this information can be placed if it is in > an unusual location. > > Welcome to the group.... Hmm, I would like that people would not need to use site.cfg if they are using system defaults. Could someone send information where RPM packed fftw libraries and include files are installed? The current system_info.py assumes that one of the following file groups exists: libfftw.a, librfftw.a, fftw.h, rfftw.h or libdfftw.a, libdrfftw.a, dfftw.h, drfftw.h (in proper lib/include directories, of course) How fftw installation in Redhat based systems differs from this setup? Pearu From gvermeul at grenoble.cnrs.fr Wed Nov 6 03:37:44 2002 From: gvermeul at grenoble.cnrs.fr (Gerard Vermeulen) Date: Wed, 6 Nov 2002 09:37:44 +0100 Subject: Detecting fftw (was Re: [SciPy-user] Absoft Compiler) In-Reply-To: References: Message-ID: <20021106083744.GA4082@venus.grenoble.cnrs.fr> On Tue, Nov 05, 2002 at 08:53:37PM +0200, Pearu Peterson wrote: > > On Mon, 4 Nov 2002, Travis Oliphant wrote: > > > > There are a couple of additional problems: the SciPy install didn't > > > detect that I have the fftw libraries installed (from the RPM), and the > > > test suite complains up near the top about the lack of a test_matfuncs > > > module. > > > > There is a site.cfg file where this information can be placed if it is in > > an unusual location. > > > > Welcome to the group.... > > Hmm, I would like that people would not need to use site.cfg if they are > using system defaults. > Could someone send information where RPM packed fftw libraries and > include files are installed? > > The current system_info.py assumes that one of the following file groups > exists: > libfftw.a, librfftw.a, fftw.h, rfftw.h > or > libdfftw.a, libdrfftw.a, dfftw.h, drfftw.h > (in proper lib/include directories, of course) > > How fftw installation in Redhat based systems differs from this setup? > > Pearu > On my Mandrake-8.2 the RPM for fftw consists of a 'user' package and a 'devel' package. To rebuild SciPy the 'devel' package is needed (this may be also the case on other distro's). The relevant files for the rpm packages are: [packer at venus packer]$ rpm -ql fftw | grep lib /usr/lib/libfftw.so.2 /usr/lib/libfftw.so.2.0.5 /usr/lib/libfftw_threads.so.2 /usr/lib/libfftw_threads.so.2.0.5 /usr/lib/librfftw.so.2 /usr/lib/librfftw.so.2.0.5 /usr/lib/librfftw_threads.so.2 /usr/lib/librfftw_threads.so.2.0.5 /usr/lib/libsfftw.so.2 /usr/lib/libsfftw.so.2.0.5 /usr/lib/libsfftw_threads.so.2 /usr/lib/libsfftw_threads.so.2.0.5 /usr/lib/libsrfftw.so.2 /usr/lib/libsrfftw.so.2.0.5 /usr/lib/libsrfftw_threads.so.2 /usr/lib/libsrfftw_threads.so.2.0.5 [packer at venus packer]$ [packer at venus packer]$ rpm -ql fftw-devel | grep lib /usr/lib/libfftw.a /usr/lib/libfftw.la /usr/lib/libfftw.so /usr/lib/libfftw_threads.a /usr/lib/libfftw_threads.la /usr/lib/libfftw_threads.so /usr/lib/librfftw.a /usr/lib/librfftw.la /usr/lib/librfftw.so /usr/lib/librfftw_threads.a /usr/lib/librfftw_threads.la /usr/lib/librfftw_threads.so /usr/lib/libsfftw.a /usr/lib/libsfftw.la /usr/lib/libsfftw.so /usr/lib/libsfftw_threads.a /usr/lib/libsfftw_threads.la /usr/lib/libsfftw_threads.so /usr/lib/libsrfftw.a /usr/lib/libsrfftw.la /usr/lib/libsrfftw.so /usr/lib/libsrfftw_threads.a /usr/lib/libsrfftw_threads.la /usr/lib/libsrfftw_threads.so [packer at venus packer]$ [packer at venus packer]$ rpm -ql fftw-devel | grep include /usr/include/fftw.h /usr/include/fftw_threads.h /usr/include/rfftw.h /usr/include/rfftw_threads.h /usr/include/sfftw.h /usr/include/sfftw_threads.h /usr/include/srfftw.h /usr/include/srfftw_threads.h [packer at venus packer]$ Regards -- Gerard From nwagner at mecha.uni-stuttgart.de Wed Nov 6 10:44:31 2002 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Wed, 06 Nov 2002 16:44:31 +0100 Subject: [SciPy-user] [Fwd: About coordinated efforts on scientific software.] Message-ID: <3DC938DF.304D080E@mecha.uni-stuttgart.de> -------------- next part -------------- An embedded message was scrubbed... From: Brian Gough Subject: RE: About coordinated efforts on scientific software. Date: Wed, 6 Nov 2002 15:34:56 +0000 (GMT) Size: 2864 URL: From Jean-Baptiste.cazier at decode.is Wed Nov 6 11:27:43 2002 From: Jean-Baptiste.cazier at decode.is (Jean-Baptiste Cazier) Date: Wed, 6 Nov 2002 16:27:43 +0000 Subject: [SciPy-user] Newbie on plot and grid Message-ID: <20021106162743.7786b9ff.Jean-Baptiste.cazier@decode.is> S?l ! I recently discovered scipy which seems to be able to fit my needs: I want to plot 2D contour file correpsonding to a X,Y,Z array However I have RH7.2 ie python 1.5.2 I installed python2-2, numpy rpm packages and the Scipy tarball that I put in /usr/lib/python2-2/site-package ~ $ rpm -qa |grep -i py pygnome-libglade-1.4.1-3 python-devel-1.5.2-35 python2-2.2.1-1 python-1.5.2-35 PyXML-0.6.5-4 pygtk-0.6.8-3 pygtk-libglade-0.6.8-3 rpm-python-4.0.3-1.03 wxPythonGTK-py2.2-2.3.3.1-1 python-numpy-21.0-4 pygnome-1.4.1-3 python-xmlrpc-1.5.0-1 /usr/lib/python2.2/site-packages]# ls Numeric Numeric.pth README gui_thread scipy scipy_base scipy_distutils wxPython I have 2 problems (at least): If I try to get gplt I get plenty of warnings: >>> from scipy import gplt /usr/lib/python2.2/site-packages/scipy_base/__init__.py:97: RuntimeWarning: Python C API version mismatch for module fastumath: This Python has API version 1011, module fastumath has version 1010. import scipy_base.fastumath /usr/lib/python2.2/site-packages/scipy/special/special.py:5: RuntimeWarning: Python C API version mismatch for module cephes: This Python has API version 1011, module cephes has version 1010. from cephes import * /usr/lib/python2.2/site-packages/scipy/special/special.py:10: RuntimeWarning: Python C API version mismatch for module specfun: This Python has API version 1011, module specfun has version 1010. import specfun /usr/lib/python2.2/site-packages/scipy/linalg/lapack.py:13: RuntimeWarning: Python C API version mismatch for module flapack: This Python has API version 1011, module flapack has version 1010. try: import flapack /usr/lib/python2.2/site-packages/scipy/linalg/lapack.py:16: RuntimeWarning: Python C API version mismatch for module clapack: This Python has API version 1011, module clapack has version 1010. import clapack /usr/lib/python2.2/site-packages/scipy/linalg/flinalg.py:13: RuntimeWarning: Python C API version mismatch for module _flinalg: This Python has API version 1011, module _flinalg has version 1010. import _flinalg /usr/lib/python2.2/site-packages/scipy/linalg/basic.py:17: RuntimeWarning: Python C API version mismatch for module calc_lwork: This Python has API version 1011, module calc_lwork has version 1010. import calc_lwork /usr/lib/python2.2/site-packages/scipy/linalg/blas.py:13: RuntimeWarning: Python C API version mismatch for module fblas: This Python has API version 1011, module fblas has version 1010. try: import fblas /usr/lib/python2.2/site-packages/scipy/linalg/blas.py:16: RuntimeWarning: Python C API version mismatch for module cblas: This Python has API version 1011, module cblas has version 1010. import cblas /usr/lib/python2.2/site-packages/scipy/io/__init__.py:20: RuntimeWarning: Python C API version mismatch for module numpyio: This Python has API version 1011, module numpyio has version 1010. from numpyio import packbits, unpackbits, bswap, fread, fwrite, \ /usr/lib/python2.2/site-packages/scipy/stats/rv.py:3: RuntimeWarning: Python C API version mismatch for module rand: This Python has API version 1011, module rand has version 1010. import rand /usr/lib/python2.2/site-packages/scipy/fftpack/fft.py:21: RuntimeWarning: Python C API version mismatch for module fftpack: This Python has API version 1011, module fftpack has version 1010. import Numeric, fftpack, copy /usr/lib/python2.2/site-packages/scipy/optimize/minpack.py:1: RuntimeWarning: Python C API version mismatch for module _minpack: This Python has API version 1011, module _minpack has version 1010. import _minpack /usr/lib/python2.2/site-packages/scipy/optimize/zeros.py:1: RuntimeWarning: Python C API version mismatch for module _zeros: This Python has API version 1011, module _zeros has version 1010. import _zeros /usr/lib/python2.2/site-packages/scipy/integrate/odepack.py:5: RuntimeWarning: Python C API version mismatch for module _odepack: This Python has API version 1011, module _odepack has version 1010. import _odepack /usr/lib/python2.2/site-packages/scipy/integrate/quadpack.py:4: RuntimeWarning: Python C API version mismatch for module _quadpack: This Python has API version 1011, module _quadpack has version 1010. import _quadpack /usr/lib/python2.2/site-packages/scipy/integrate/ode.py:240: RuntimeWarning: Python C API version mismatch for module vode: This Python has API version 1011, module vode has version 1010. import vode as _vode /usr/lib/python2.2/site-packages/scipy/signal/__init__.py:67: RuntimeWarning: Python C API version mismatch for module sigtools: This Python has API version 1011, module sigtools has version 1010. import sigtools /usr/lib/python2.2/site-packages/scipy/signal/bsplines.py:5: RuntimeWarning: Python C API version mismatch for module spline: This Python has API version 1011, module spline has version 1010. from spline import * # C-modules /usr/lib/python2.2/site-packages/scipy/interpolate/fitpack.py:34: RuntimeWarning: Python C API version mismatch for module _fitpack: This Python has API version 1011, module _fitpack has version 1010. import _fitpack /usr/lib/python2.2/site-packages/scipy/xplt/gist.py:7: RuntimeWarning: Python C API version mismatch for module gistC: This Python has API version 1011, module gistC has version 1010. from gistC import * >>> I try to run the following script without any success: >>> # Define function over sparse 20x20 grid >>> x,y = grid[-1:1:20L,-1:1:20L] >>> z = (x+y)*exp(-6.0*(x*x+y*y)) >>> xplt.plot3(x,y,z,shade=1,palette='rainbow') >>> xplt.title3("Sparsely sampled function.") >>> xplt.eps("2d_func") After the first line I get: ~ $ python2 Python 2.2.1 (#1, Apr 9 2002, 13:10:27) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> x,y = grid[-1:1:20L,-1:1:20L] Traceback (most recent call last): File "", line 1, in ? NameError: name 'grid' is not defined >>> Which package should I download ? What is wrong ? Any help would be appreciated Takk Kve?ja JB -- ----------------------------- Jean-Baptiste.Cazier at decode.is Department of Statistics deCODE genetics Sturlugata,8 570 2930 101 Reykjav?k From stephen.walton at csun.edu Wed Nov 6 13:23:43 2002 From: stephen.walton at csun.edu (Stephen Walton) Date: 06 Nov 2002 10:23:43 -0800 Subject: Detecting fftw (was Re: [SciPy-user] Absoft Compiler) In-Reply-To: <20021106083744.GA4082@venus.grenoble.cnrs.fr> References: <20021106083744.GA4082@venus.grenoble.cnrs.fr> Message-ID: <1036607023.21586.39.camel@sunspot> On Wed, 2002-11-06 at 00:37, Gerard Vermeulen wrote: > On my Mandrake-8.2 the RPM for fftw consists of a 'user' package and > a 'devel' package. To rebuild SciPy the 'devel' package is needed (this may > be also the case on other distro's). This appears to be also the case on RedHat, and my thanks to Gerard. I did not in fact have the fftw-devel RPM installed here. However...since I didn't want to delete and re-create my CVS-checked-out scipy source tree (I have a somewhat slow link), I did a 'python setup.py clean' followed by 'build build_flib'. As far as I can tell, this still did not pick up fftw; a 'grep fft' on the output of the build command showed that it built fftpack and dfftpack from source, apparently taking no notice of fftw. This probably means that the 'clean' command didn't clean up enough. -- Stephen Walton, Professor of Physics and Astronomy, California State University, Northridge stephen.walton at csun.edu From pearu at cens.ioc.ee Wed Nov 6 14:55:58 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Wed, 6 Nov 2002 21:55:58 +0200 (EET) Subject: Detecting fftw (was Re: [SciPy-user] Absoft Compiler) In-Reply-To: <1036607023.21586.39.camel@sunspot> Message-ID: On 6 Nov 2002, Stephen Walton wrote: > On Wed, 2002-11-06 at 00:37, Gerard Vermeulen wrote: > > > On my Mandrake-8.2 the RPM for fftw consists of a 'user' package and > > a 'devel' package. To rebuild SciPy the 'devel' package is needed (this may > > be also the case on other distro's). > > This appears to be also the case on RedHat, and my thanks to Gerard. I > did not in fact have the fftw-devel RPM installed here. However...since > I didn't want to delete and re-create my CVS-checked-out scipy source > tree (I have a somewhat slow link), I did a 'python setup.py clean' > followed by 'build build_flib'. rm -rf build would be the most reliable way to clean up scipy source tree. > As far as I can tell, this still did not pick up fftw; > a 'grep fft' on the output of the build command > showed that it built fftpack and dfftpack from source, apparently taking > no notice of fftw. This probably means that the 'clean' command didn't > clean up enough. Actually the current fftpack module does not use fftw library by default. If you are really interested in FFT stuff, then see fftpack2 http://cens.ioc.ee/~pearu/misc/fftpack2-0.2.tar.gz that will replace the current fftpack module in SciPy as soon as I get a chance to commit it to the SciPy CVS tree. The fftpack2 module will take full advantage of fftw library whenever it is available. And to check if scipy picks up fftw, run python scipy_distutils/system_info.py Pearu From oliphant at ee.byu.edu Wed Nov 6 14:56:02 2002 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Wed, 6 Nov 2002 12:56:02 -0700 (MST) Subject: [SciPy-user] Newbie on plot and grid In-Reply-To: <20021106162743.7786b9ff.Jean-Baptiste.cazier@decode.is> Message-ID: > S?l ! > > I recently discovered scipy which seems to be able to fit my needs: > I want to plot 2D contour file correpsonding to a X,Y,Z array > > However I have RH7.2 ie python 1.5.2 > > I installed python2-2, numpy rpm packages > and the Scipy tarball that I put in /usr/lib/python2-2/site-package > ~ $ rpm -qa |grep -i py > pygnome-libglade-1.4.1-3 > python-devel-1.5.2-35 > python2-2.2.1-1 > python-1.5.2-35 > PyXML-0.6.5-4 > pygtk-0.6.8-3 > pygtk-libglade-0.6.8-3 > rpm-python-4.0.3-1.03 > wxPythonGTK-py2.2-2.3.3.1-1 > python-numpy-21.0-4 > pygnome-1.4.1-3 > python-xmlrpc-1.5.0-1 > > /usr/lib/python2.2/site-packages]# ls > Numeric Numeric.pth README gui_thread scipy scipy_base scipy_distutils wxPython > > > I have 2 problems (at least): > > If I try to get gplt I get plenty of warnings: > >>> from scipy import gplt > /usr/lib/python2.2/site-packages/scipy_base/__init__.py:97: RuntimeWarning: Python C API version mismatch for module fastumath: This Python has API version 1011, module fastumath has version 1010. > import scipy_base.fastumath > /usr/lib/python2.2/site-packages/scipy/special/special.py:5: RuntimeWarning: Python C API version mismatch for module cephes: This Python has API version 1011, module cephes has version 1010. > from cephes import * > /usr/lib/python2.2/site-packages/scipy/special/special.py:10: RuntimeWarning: Python C API version mismatch for module specfun: This Python has API version 1011, module specfun has version 1010. > import specfun > /usr/lib/python2.2/site-packages/scipy/linalg/lapack.py:13: RuntimeWarning: Python C API version mismatch for module flapack: This Python has API version 1011, module flapack has version 1010. > try: import flapack > /usr/lib/python2.2/site-packages/scipy/linalg/lapack.py:16: RuntimeWarning: Python C API version mismatch for module clapack: This Python has API version 1011, module clapack has version 1010. > import clapack > /usr/lib/python2.2/site-packages/scipy/linalg/flinalg.py:13: RuntimeWarning: Python C API version mismatch for module _flinalg: This Python has API version 1011, module _flinalg has version 1010. > import _flinalg > /usr/lib/python2.2/site-packages/scipy/linalg/basic.py:17: RuntimeWarning: Python C API version mismatch for module calc_lwork: This Python has API version 1011, module calc_lwork has version 1010. > import calc_lwork > /usr/lib/python2.2/site-packages/scipy/linalg/blas.py:13: RuntimeWarning: Python C API version mismatch for module fblas: This Python has API version 1011, module fblas has version 1010. > try: import fblas > /usr/lib/python2.2/site-packages/scipy/linalg/blas.py:16: RuntimeWarning: Python C API version mismatch for module cblas: This Python has API version 1011, module cblas has version 1010. > import cblas > /usr/lib/python2.2/site-packages/scipy/io/__init__.py:20: RuntimeWarning: Python C API version mismatch for module numpyio: This Python has API version 1011, module numpyio has version 1010. > from numpyio import packbits, unpackbits, bswap, fread, fwrite, \ > /usr/lib/python2.2/site-packages/scipy/stats/rv.py:3: RuntimeWarning: Python C API version mismatch for module rand: This Python has API version 1011, module rand has version 1010. > import rand > /usr/lib/python2.2/site-packages/scipy/fftpack/fft.py:21: RuntimeWarning: Python C API version mismatch for module fftpack: This Python has API version 1011, module fftpack has version 1010. > import Numeric, fftpack, copy > /usr/lib/python2.2/site-packages/scipy/optimize/minpack.py:1: RuntimeWarning: Python C API version mismatch for module _minpack: This Python has API version 1011, module _minpack has version 1010. > import _minpack > /usr/lib/python2.2/site-packages/scipy/optimize/zeros.py:1: RuntimeWarning: Python C API version mismatch for module _zeros: This Python has API version 1011, module _zeros has version 1010. > import _zeros > /usr/lib/python2.2/site-packages/scipy/integrate/odepack.py:5: RuntimeWarning: Python C API version mismatch for module _odepack: This Python has API version 1011, module _odepack has version 1010. > import _odepack > /usr/lib/python2.2/site-packages/scipy/integrate/quadpack.py:4: RuntimeWarning: Python C API version mismatch for module _quadpack: This Python has API version 1011, module _quadpack has version 1010. > import _quadpack > /usr/lib/python2.2/site-packages/scipy/integrate/ode.py:240: RuntimeWarning: Python C API version mismatch for module vode: This Python has API version 1011, module vode has version 1010. > import vode as _vode > /usr/lib/python2.2/site-packages/scipy/signal/__init__.py:67: RuntimeWarning: Python C API version mismatch for module sigtools: This Python has API version 1011, module sigtools has version 1010. > import sigtools > /usr/lib/python2.2/site-packages/scipy/signal/bsplines.py:5: RuntimeWarning: Python C API version mismatch for module spline: This Python has API version 1011, module spline has version 1010. > from spline import * # C-modules > /usr/lib/python2.2/site-packages/scipy/interpolate/fitpack.py:34: RuntimeWarning: Python C API version mismatch for module _fitpack: This Python has API version 1011, module _fitpack has version 1010. > import _fitpack > /usr/lib/python2.2/site-packages/scipy/xplt/gist.py:7: RuntimeWarning: Python C API version mismatch for module gistC: This Python has API version 1011, module gistC has version 1010. > from gistC import * > >>> > > > > I try to run the following script without any success: > >>> # Define function over sparse 20x20 grid > >>> x,y = grid[-1:1:20L,-1:1:20L] > >>> z = (x+y)*exp(-6.0*(x*x+y*y)) > >>> xplt.plot3(x,y,z,shade=1,palette='rainbow') > >>> xplt.title3("Sparsely sampled function.") > >>> xplt.eps("2d_func") > grid is obsolete. Use mgrid (we need to update the docs). -Travis O. From nwagner at mecha.uni-stuttgart.de Thu Nov 7 05:10:57 2002 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Thu, 07 Nov 2002 11:10:57 +0100 Subject: [SciPy-user] Xlib: unexpected async reply (sequence 0x84)! Message-ID: <3DCA3C31.A472B1D9@mecha.uni-stuttgart.de> Hi, I try to visualize the results of odeint using import gui_thread from scipy import plt plt.plot(t,l) However, the program gets stuck with Xlib: unexpected async reply (sequence 0x84)! What is the reason for that ? Nils From nwagner at mecha.uni-stuttgart.de Thu Nov 7 05:17:48 2002 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Thu, 07 Nov 2002 11:17:48 +0100 Subject: [SciPy-user] Complex ODE's in scipy Message-ID: <3DCA3DCC.2FE8B9C8@mecha.uni-stuttgart.de> Hi, How can I integrate complex ODE's in scipy ? I guess I have to double the order of the ODE with respect to real and imaginary part. But, Is it also possible to treat it directly in the complex plane ? odeint(func, y0, t, args=(), Dfun=None, col_deriv=0, full_output=0, ml=None, mu=None, rtol=None, atol=None, tcrit=None, h0=0.0, hmax=0.0, hmin=0.0, ixpr=0, mxstep=0, mxhnil=0, mxordn=12, mxords=5, printmessg=0) Integrate a system of ordinary differential equations. Description: Solve a system of ordinary differential equations Using lsoda from the FORTRAN library odepack. Solves the initial value problem for stiff or non-stiff systems of first order ode-s: dy/dt = func(y,t0,...) where y can be a vector. Inputs: func -- func(y,t0,...) computes the derivative of y at t0. y0 -- initial condition on y (can be a vector). t -- a sequence of time points for which to solve for y. The intial value point should be the first element of this sequence. args -- extra arguments to pass to function. Dfun -- the gradient (Jacobian) of func (same input signature as func). col_deriv -- non-zero implies that Dfun defines derivatives down columns (faster), otherwise Dfun should define derivatives across rows. full_output -- non-zero to return a dictionary of optional outputs as the second output. printmessg -- print the convergence message. Nils From nwagner at mecha.uni-stuttgart.de Thu Nov 7 05:51:29 2002 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Thu, 07 Nov 2002 11:51:29 +0100 Subject: [SciPy-user] Redirect the output of gplt.plot plt.plot into an eps-file Message-ID: <3DCA45B1.7D771942@mecha.uni-stuttgart.de> Hi, How can I redirect the output of both plt.plot(t,l) and gplt.plot(t,y) into an eps-file ? Nils From prabhu at aero.iitm.ernet.in Thu Nov 7 12:03:21 2002 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Thu, 7 Nov 2002 22:33:21 +0530 Subject: [SciPy-user] Xlib: unexpected async reply (sequence 0x84)! In-Reply-To: <3DCA3C31.A472B1D9@mecha.uni-stuttgart.de> References: <3DCA3C31.A472B1D9@mecha.uni-stuttgart.de> Message-ID: <15818.40153.221858.836832@monster.linux.in> >>>>> "NW" == Nils Wagner writes: NW> Hi, I try to visualize the results of odeint using import NW> gui_thread from scipy import plt plt.plot(t,l) NW> However, the program gets stuck with Did you wait till you got the >>> after you typed import gui_thread? If that message was not seen, then you imported another module that had already imported wxPython. This will trigger the async errors. cheers, prabhu From wagner.nils at vdi.de Thu Nov 7 17:42:35 2002 From: wagner.nils at vdi.de (Nils Wagner) Date: Thu, 07 Nov 2002 23:42:35 +0100 Subject: [SciPy-user] Xlib: unexpected async reply =?iso-8859-1?q?=28sequence?= =?iso-8859-1?q?_0x84=29!?= In-Reply-To: <15818.40153.221858.836832@monster.linux.in> Message-ID: <20021107225208.147093EACE@www.scipy.com> ------------------- >>>>> "NW" == Nils Wagner writes: NW> Hi, I try to visualize the results of odeint using import NW> gui_thread from scipy import plt plt.plot(t,l) NW> However, the program gets stuck with Did you wait till you got the >>> after you typed import gui_thread? If that message was not seen, then you imported another module that had already imported wxPython. This will trigger the async errors. cheers, prabhu Yes. I run python in interactive mode i.e. python -i Nils _______________________________________________ SciPy-user mailing list SciPy-user at scipy.net http://www.scipy.net/mailman/listinfo/scipy-user From nwagner at mecha.uni-stuttgart.de Fri Nov 8 05:04:27 2002 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Fri, 08 Nov 2002 11:04:27 +0100 Subject: [SciPy-user] gplt and multiple windows Message-ID: <3DCB8C2B.EABEE01A@mecha.uni-stuttgart.de> Hi, Is it possible to plot curves in two different "windows" using gplt.plot(t,y) ? Nils From nwagner at mecha.uni-stuttgart.de Fri Nov 8 05:12:59 2002 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Fri, 08 Nov 2002 11:12:59 +0100 Subject: [SciPy-user] Singular points in integrate.odeint Message-ID: <3DCB8E2B.FA666591@mecha.uni-stuttgart.de> Hi, How can I tackle singular points in integrate.odeint The rhs of my autonomous ODE \dot{y} = f(y)/g(y) becomes singular at certain points y*, that is g(y*) = 0. Any suggestion ? Nils From nmarais at hertz.ee.sun.ac.za Fri Nov 8 13:31:05 2002 From: nmarais at hertz.ee.sun.ac.za (Neilen) Date: 08 Nov 2002 20:31:05 +0200 Subject: [SciPy-user] Redirect the output of gplt.plot plt.plot into an eps-file In-Reply-To: <3DCA45B1.7D771942@mecha.uni-stuttgart.de> References: <3DCA45B1.7D771942@mecha.uni-stuttgart.de> Message-ID: <1036780265.31712.62.camel@stoomtrein> Hi Nils On Thu, 2002-11-07 at 12:51, Nils Wagner wrote: > Hi, > > How can I redirect the output of both plt.plot(t,l) and gplt.plot(t,y) > into an eps-file ? Try gplt.output. The "format string" is the same as the output driver line for gnuplot. Read the gnuplot manual for that... Its a pretty hefty manual, but if you search for output, or something like that, you get everything you need in no time. Cheers Neilen > > > Nils > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user -- You know its kind of tragic we live in the new world but we've lost the magic -- Battery 9 From nmarais at hertz.ee.sun.ac.za Fri Nov 8 13:34:24 2002 From: nmarais at hertz.ee.sun.ac.za (Neilen) Date: 08 Nov 2002 20:34:24 +0200 Subject: [SciPy-user] gplt and multiple windows In-Reply-To: <3DCB8C2B.EABEE01A@mecha.uni-stuttgart.de> References: <3DCB8C2B.EABEE01A@mecha.uni-stuttgart.de> Message-ID: <1036780464.6806.66.camel@stoomtrein> Hi Nils On Fri, 2002-11-08 at 12:04, Nils Wagner wrote: > Hi, > > Is it possible to plot curves in two different "windows" using > gplt.plot(t,y) ? Its slightly involved, since there is no simple figure(n), where n is some number analog of the Matlab behaviour. What you need to do is: Create a new gnuplot figure with gplt.figure() Save ther figure handle, like plot1=gplt.current() Do so for how ever many windows you want. When you want to activate a particular plot, you say gplt.figure(plot1), or whichsoever one it might be. Cheers Neilen > > Nils > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user -- You know its kind of tragic we live in the new world but we've lost the magic -- Battery 9 From rhawkin2 at earthlink.net Sun Nov 10 16:54:36 2002 From: rhawkin2 at earthlink.net (rhawkin2) Date: 10 Nov 2002 13:54:36 -0800 Subject: [SciPy-user] integrate.quad memory leak in linux2 binary? Message-ID: <1036965277.2141.104.camel@localhost.localdomain> Hello, The ScipPy binary for linux2 [1] seems to have a memory leak in integrate.quad. I've attached a short example [2] that illustrates the problem: running the example and monitoring it with 'top' shows the example to increase in memory usage over time. It appears that the fix to this memory leak [3] went into CVS on Aug. 8 which is one day after the linux2 binaries were posted. Is there a simple way to get the post-fix version of this routine for linux2? Thanks, Ray [1] SciPy-0.2.0_alpha_105.3699.linux2_py2.2.tar.gz [2] Example: #!/usr/bin/python2.2 from scipy import * from scipy.integrate import quad # ******************************************************** def prob(x): return exp(-x) # ******************************************************** for i in range(100000): result = quad(prob,0.0,5.0) [3] http://scipy.net/cgi-bin/viewcvsx.cgi/scipy/integrate/__quadpack.h From oliphant.travis at ieee.org Mon Nov 11 03:43:39 2002 From: oliphant.travis at ieee.org (Travis Oliphant) Date: 11 Nov 2002 01:43:39 -0700 Subject: [SciPy-user] integrate.quad memory leak in linux2 binary? In-Reply-To: <1036965277.2141.104.camel@localhost.localdomain> References: <1036965277.2141.104.camel@localhost.localdomain> Message-ID: <1037004220.6884.5.camel@travis.local.net> On Sun, 2002-11-10 at 14:54, rhawkin2 wrote: > Hello, > > The ScipPy binary for linux2 [1] seems to have a memory leak in > integrate.quad. I've attached a short example [2] that illustrates the > problem: running the example and monitoring it with 'top' shows the > example to increase in memory usage over time. It appears that the fix > to this memory leak [3] went into CVS on Aug. 8 which is one day after > the linux2 binaries were posted. Is there a simple way to get the > post-fix version of this routine for linux2? Yes, this has been fixed. You could try getting the source and compiling. If you can download a pre-compiled atlas, it should not be that difficult to compile SciPy on linux. -Travis O. From mike_sorich at hotmail.com Wed Nov 13 18:56:44 2002 From: mike_sorich at hotmail.com (Michael Sorich) Date: Thu, 14 Nov 2002 10:26:44 +1030 Subject: [SciPy-user] weave with SGI/IRIX Message-ID: <000c01c28b70$51edeb60$8205120a@MikesLaptop> Hi, I am trying to get weave to work on a SGI Octane2 running IRIX 6.5, python-2.1.1 and gcc 3.0.4. I have installed weave 0.2.3. When I run weave.test() I get a lot of errors (see attachment), mainly concerning unresolved symbols. Does anyone know what is going on here and how to fix it? Has anyone successfully used weave on an SGI? I have installed a number of extensions (eg NumPy) using gcc, so I am pretty sure that it is working OK. Thanks Michael Sorich PhD Student School of Pharmaceutical, Molecular and Biomedical Sciences University of South Australia Email: michael.sorich at postgrads.unisa.edu.au mike_sorich at hotmail.com --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.408 / Virus Database: 230 - Release Date: 24/10/2002 -------------- next part -------------- A non-text attachment was scrubbed... Name: errors.txt Type: application/octet-stream Size: 22541 bytes Desc: not available URL: From steven.robbins at videotron.ca Wed Nov 13 19:39:52 2002 From: steven.robbins at videotron.ca (Steve M. Robbins) Date: Wed, 13 Nov 2002 19:39:52 -0500 Subject: [SciPy-user] weave with SGI/IRIX In-Reply-To: <000c01c28b70$51edeb60$8205120a@MikesLaptop> References: <000c01c28b70$51edeb60$8205120a@MikesLaptop> Message-ID: <20021114003952.GA5825@riemann.nyongwa.montreal.qc.ca> On Thu, Nov 14, 2002 at 10:26:44AM +1030, Michael Sorich wrote: > Hi, > > I am trying to get weave to work on a SGI Octane2 running IRIX 6.5, > python-2.1.1 and gcc 3.0.4. I have installed weave 0.2.3. > > When I run weave.test() I get a lot of errors (see attachment), mainly > concerning unresolved symbols. Does anyone know what is going on here > and how to fix it? Has anyone successfully used weave on an SGI? I believe that weave 0.2.3 only works with GCC 2.9x. Check back in the scipy-user archives (late August) for a thread with the subject "weave and compilers other than GCC 2.95?". I was using CVS weave. I understand that the weave code in CVS has changed a lot since then, though I haven't tried it. That may be your best hope. Regards, -Steve From andrew.straw at adelaide.edu.au Thu Nov 14 01:01:09 2002 From: andrew.straw at adelaide.edu.au (Andrew Straw) Date: Thu, 14 Nov 2002 16:31:09 +1030 Subject: [SciPy-user] Mac OS X question: using Apple's vecLib Message-ID: <785AA750-F796-11D6-AFDA-00039311EA24@adelaide.edu.au> It appears that Apple has given Mac OS X (10.2) a pre-installed LAPACK in the vecLib framework. (See http://developer.apple.com/techpubs/macosx/ReleaseNotes/vecLib.html ) Apparently, this is a c version of the library (clapack). Is there any reason why scipy shouldn't use the clapack installed with Mac OS X 10.2 rather than ATLAS/LAPACK installed from sources as suggested in the scipy docs? If not, I may try to create a patch for scipy to use Apple's pre-installed library. Cheers! Andrew From rhawkin2 at earthlink.net Wed Nov 13 19:59:13 2002 From: rhawkin2 at earthlink.net (rhawkin2) Date: 13 Nov 2002 16:59:13 -0800 Subject: [SciPy-user] scipy.test(level=1) fails: undefined symbol: clapack_sgesv Message-ID: <1037235554.10171.45.camel@localhost.localdomain> Hello, Build from CVS went OK and scipy loads fine, but I got the following error on the scipy.test(level=1) command: ====================================================================== ERROR: check_add_function_ordered (test_catalog.test_catalog) ---------------------------------------------------------------------- Traceback (most recent call last): File "/tmp/SciPyTest/linux2/lib/python2.2/site-packages/scipy/weave/tests/test_catalog.py", line 308, in check_add_function_ordered File "/tmp/SciPyTest/linux2/lib/python2.2/site-packages/scipy/weave/catalog.py", line 575, in add_function File "/tmp/SciPyTest/linux2/lib/python2.2/site-packages/scipy/weave/catalog.py", line 615, in add_function_persistent File "/tmp/SciPyTest/linux2/lib/python2.2/site-packages/scipy/weave/catalog.py", line 66, in getmodule File "/usr/lib/python2.2/site-packages/scipy_distutils/misc_util.py", line 44, in __getattr__ raise self._info[0],self._info[1] ImportError: /usr/lib/python2.2/site-packages/scipy/linalg/clapack.so: undefined symbol: clapack_sgesv ---------------------------------------------------------------------- Ran 692 tests in 5.020s FAILED (errors=1) This looks familiar, but seemed to cause problems in the past at the "import scipy" level. Suggestions for dealing with this would be most appreciated. Troubleshooting info appended below. Thanks, Ray 1) Platform information: python2.2 -c 'import os,sys;print os.name,sys.platform' posix linux2 uname -a Linux localhost.localdomain 2.4.18-17.7.x #1 Tue Oct 8 13:33:14 EDT 2002 i686 unknown RH Linux 7.3 2) Compiler information: gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113) g77 --version GNU Fortran 0.5.26 20000731 (Red Hat Linux 7.3 2.96-113) 3) Python version: python2.2 -c 'import sys;print sys.version' 2.2 (#1, Apr 12 2002, 15:29:57) [GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-109)] 4) Python Numeric version: python2.2 -c 'import Numeric;print Numeric.__version__' 21.3 5) f2py version: f2py -v doesn't work. Unpacking the file F2PY-2-latest.tar.gz gave a directory titled F2PY-2.23.190-1369. 6) ATLAS version: 3.4.1 python -c 'import atlas_version' ... WARNING: Python C API version mismatch for module atlas_version: This Python has API version 1007, module atlas_version has version 1011. 7) More output: python2.2 scipy_distutils/system_info.py atlas_info: FOUND: libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/lib'] include_dirs = ['/usr/include'] blas_info: FOUND: libraries = ['blas'] library_dirs = ['/usr/lib'] blas_src_info: NOT AVAILABLE dfftw_info: NOT AVAILABLE dfftw_threads_info: NOT AVAILABLE djbfft_info: NOT AVAILABLE fftw_info: NOT AVAILABLE fftw_threads_info: NOT AVAILABLE lapack_info: FOUND: libraries = ['lapack'] library_dirs = ['/usr/lib'] lapack_src_info: NOT AVAILABLE sfftw_info: NOT AVAILABLE sfftw_threads_info: NOT AVAILABLE sfftw_threads_info: NOT AVAILABLE x11_info: FOUND: libraries = ['X11'] library_dirs = ['/usr/X11R6/lib'] include_dirs = ['/usr/X11R6/include'] python2.2 scipy_distutils/command/build_flib.py Gnu 0.5.26 8) Output to stdout of the SciPy installation command. There was no stderr output. atlas_info: FOUND: libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/lib'] include_dirs = ['/usr/include'] /usr/bin/python2.2 /incoming/scipy/scipy/scipy/linalg/setup_atlas_version.py build_ext --inplace --force /usr/bin/python2.2 -c "import atlas_version" ATLAS version 3.4.1 ### Little Endian detected #### x11_info: FOUND: libraries = ['X11'] library_dirs = ['/usr/X11R6/lib'] include_dirs = ['/usr/X11R6/include'] ### Little Endian detected #### SciPy Version 0.2.0_alpha_145.4426 running install running build running build_py not copying /incoming/scipy/scipy/scipy/__cvs_version__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/__init__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/common.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/helper.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/helpmod.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/pilutil.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/proc.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_tempfile.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_version.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/setup_scipy.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/sync.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/tests/test_basic.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/tests/test_basic1a.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/tests/test_common.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/io/__init__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/io/array_import.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/io/data_store.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/io/dumb_shelve.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/io/dumbdbm_patched.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/io/mio.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/io/pickler.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/io/setup_io.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/io/tests/testio.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/linalg/__init__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/linalg/basic.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/linalg/blas.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/linalg/decomp.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/linalg/flinalg.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/linalg/interface_gen.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/linalg/lapack.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/linalg/matfuncs.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/linalg/setup_atlas_version.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/linalg/setup_linalg.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/linalg/tests/test_basic.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/linalg/tests/test_blas.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/linalg/tests/test_decomp.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/linalg/tests/test_fblas.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/linalg/tests/test_lapack.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/special/__init__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/special/gendoc.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/special/orthogonal.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/special/setup_special.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/special/special.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/special/tests/Test.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/special/tests/test_cephes.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/signal/__init__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/signal/bsplines.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/signal/filter_design.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/signal/ltisys.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/signal/setup_signal.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/signal/signaltools.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/stats/__init__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/stats/distributions.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/stats/morestats.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/stats/pstat.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/stats/rv.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/stats/rv2.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/stats/setup_stats.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/stats/stats.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/stats/tests/test_distributions.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/stats/tests/test_morestats.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/stats/tests/test_stats.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/interpolate/__init__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/interpolate/common_routines.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/interpolate/fitpack.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/interpolate/interpolate.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/interpolate/setup_interpolate.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/integrate/__init__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/integrate/common_routines.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/integrate/ode.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/integrate/odepack.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/integrate/quadpack.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/integrate/quadrature.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/integrate/setup_integrate.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/optimize/__init__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/optimize/anneal.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/optimize/common_routines.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/optimize/minpack.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/optimize/optimize.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/optimize/setup_optimize.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/optimize/zeros.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/optimize/tests/test_zeros.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/cluster/__init__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/cluster/setup_cluster.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/cluster/vq.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/cluster/tests/vq_test.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/cow/__init__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/cow/cow.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/cow/herd.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/cow/setup_cow.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/cow/sync_cluster.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/ga/__init__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/ga/algorithm.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/ga/examples.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/ga/ga_gnm.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/ga/ga_list.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/ga/ga_util.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/ga/gene.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/ga/genome.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/ga/language.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/ga/parallel_pop.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/ga/population.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/ga/scaling.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/ga/selection.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/ga/setup_ga.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/ga/tree.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/ga/tree_opt.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/fftpack/__init__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/fftpack/fft.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/fftpack/setup_fftpack.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/plt/__init__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/plt/colormap.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/plt/dumb_shelve.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/plt/dumbdbm_patched.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/plt/interface.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/plt/plot_objects.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/plt/plot_utility.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/plt/setup_plt.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/plt/wxplt.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/gplt/__init__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/gplt/interface.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/gplt/new_plot.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/gplt/pyPlot.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/gplt/setup_gplt.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/GistPlotter.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/Graphics.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/Mplot.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/NarPlotter.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/__init__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/animation2d.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/berts.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/cellarray.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/colorbar.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/curve.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/demo5.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/ezplot.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/eztest.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/gist.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/gist3dhelp.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/gistdemohigh.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/gistdemolow.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/gistmeshtest.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/gisttest2d.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/gisttest3d.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/graftest2d.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/graftypes.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/graph.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/graph2d.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/graph3d.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/helpmod.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/lines.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/mesh3d.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/meshtest.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/movie.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/nicks.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/pl3d.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/plane.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/plwf.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/polymap.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/quadmesh.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/region.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/setup_xplt.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/shapetest.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/slice3.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/sphereisos.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/surface.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/surftest3d.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/surftest4d.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/twograftest2d.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/write_style.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/yorick.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/gui_thread/__init__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/gui_thread/examples.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/gui_thread/gui_thread_guts.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/gui_thread/main.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/gui_thread/setup_gui_thread.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/gui_thread/tests/test_gui_thread.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_base/__cvs_version__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_base/__init__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_base/function_base.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_base/index_tricks.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_base/limits.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_base/matrix_base.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_base/polynomial.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_base/scimath.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_base/scipy_base_version.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_base/setup_scipy_base.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_base/shape_base.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_base/type_check.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_base/tests/test_function_base.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_base/tests/test_index_tricks.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_base/tests/test_limits.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_base/tests/test_matrix_base.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_base/tests/test_shape_base.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_base/tests/test_type_check.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_distutils/__cvs_version__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_distutils/__init__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_distutils/core.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_distutils/dist.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_distutils/extension.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_distutils/lib2def.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_distutils/line_endings.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_distutils/mingw32_support.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_distutils/misc_util.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_distutils/scipy_distutils_version.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_distutils/setup_scipy_distutils.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_distutils/system_info.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_distutils/command/__init__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_distutils/command/build.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_distutils/command/build_clib.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_distutils/command/build_ext.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_distutils/command/build_flib.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_distutils/command/build_py.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_distutils/command/cpuinfo.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_distutils/command/install.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_distutils/command/install_data.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_distutils/command/install_headers.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_distutils/command/run_f2py.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_distutils/command/sdist.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_test/__cvs_version__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_test/__init__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_test/auto_test.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_test/logging.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_test/scipy_test_version.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_test/setup_scipy_test.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/scipy_test/testing.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/__init__.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/accelerate_tools.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/ast_tools.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/base_info.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/base_spec.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz_spec.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz_tools.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/build_tools.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/bytecodecompiler.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/c_spec.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/catalog.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/common_info.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/converters.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/dumb_shelve.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/dumbdbm_patched.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/ext_tools.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/inline_tools.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/setup_weave.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/size_check.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/slice_handler.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/standard_array_spec.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/vtk_spec.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/wx_spec.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/scxx_timings.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_ast_tools.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_blitz_tools.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_build_tools.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_c_spec.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_catalog.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_ext_tools.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_inline_tools.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_scxx.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_scxx_dict.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_scxx_object.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_scxx_sequence.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_size_check.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_slice_handler.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_standard_array_spec.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_wx_spec.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/weave_test_utils.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/scxx_timings.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_ast_tools.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_blitz_tools.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_build_tools.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_c_spec.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_catalog.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_ext_tools.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_inline_tools.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_scxx.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_scxx_dict.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_scxx_object.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_scxx_sequence.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_size_check.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_slice_handler.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_standard_array_spec.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/test_wx_spec.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/tests/weave_test_utils.py (output up-to-date) running build_clib building 'c_misc' library skipping /incoming/scipy/scipy/scipy/special/c_misc/besselpoly.c (build/temp.linux-i686-2.2/besselpoly.o up-to-date) skipping build/temp.linux-i686-2.2/libc_misc.a (up-to-date) ranlib build/temp.linux-i686-2.2/libc_misc.a building 'cephes' library skipping /incoming/scipy/scipy/scipy/special/cephes/airy.c (build/temp.linux-i686-2.2/airy.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/bdtr.c (build/temp.linux-i686-2.2/bdtr.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/beta.c (build/temp.linux-i686-2.2/beta.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/btdtr.c (build/temp.linux-i686-2.2/btdtr.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/cbrt.c (build/temp.linux-i686-2.2/cbrt.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/chbevl.c (build/temp.linux-i686-2.2/chbevl.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/chdtr.c (build/temp.linux-i686-2.2/chdtr.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/const.c (build/temp.linux-i686-2.2/const.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/cpmul.c (build/temp.linux-i686-2.2/cpmul.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/dawsn.c (build/temp.linux-i686-2.2/dawsn.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/ellie.c (build/temp.linux-i686-2.2/ellie.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/ellik.c (build/temp.linux-i686-2.2/ellik.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/ellpe.c (build/temp.linux-i686-2.2/ellpe.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/ellpj.c (build/temp.linux-i686-2.2/ellpj.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/ellpk.c (build/temp.linux-i686-2.2/ellpk.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/euclid.c (build/temp.linux-i686-2.2/euclid.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/exp10.c (build/temp.linux-i686-2.2/exp10.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/exp2.c (build/temp.linux-i686-2.2/exp2.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/expn.c (build/temp.linux-i686-2.2/expn.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/fabs.c (build/temp.linux-i686-2.2/fabs.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/fdtr.c (build/temp.linux-i686-2.2/fdtr.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/fresnl.c (build/temp.linux-i686-2.2/fresnl.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/gamma.c (build/temp.linux-i686-2.2/gamma.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/gdtr.c (build/temp.linux-i686-2.2/gdtr.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/gels.c (build/temp.linux-i686-2.2/gels.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/hyp2f1.c (build/temp.linux-i686-2.2/hyp2f1.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/hyperg.c (build/temp.linux-i686-2.2/hyperg.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/i0.c (build/temp.linux-i686-2.2/i0.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/i1.c (build/temp.linux-i686-2.2/i1.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/igam.c (build/temp.linux-i686-2.2/igam.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/igami.c (build/temp.linux-i686-2.2/igami.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/incbet.c (build/temp.linux-i686-2.2/incbet.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/incbi.c (build/temp.linux-i686-2.2/incbi.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/isnan.c (build/temp.linux-i686-2.2/isnan.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/iv.c (build/temp.linux-i686-2.2/iv.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/j0.c (build/temp.linux-i686-2.2/j0.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/j1.c (build/temp.linux-i686-2.2/j1.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/jn.c (build/temp.linux-i686-2.2/jn.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/jv.c (build/temp.linux-i686-2.2/jv.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/k0.c (build/temp.linux-i686-2.2/k0.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/k1.c (build/temp.linux-i686-2.2/k1.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/kn.c (build/temp.linux-i686-2.2/kn.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/kolmogorov.c (build/temp.linux-i686-2.2/kolmogorov.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/mmmpy.c (build/temp.linux-i686-2.2/mmmpy.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/mtherr.c (build/temp.linux-i686-2.2/mtherr.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/mtransp.c (build/temp.linux-i686-2.2/mtransp.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/mvmpy.c (build/temp.linux-i686-2.2/mvmpy.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/nbdtr.c (build/temp.linux-i686-2.2/nbdtr.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/ndtr.c (build/temp.linux-i686-2.2/ndtr.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/ndtri.c (build/temp.linux-i686-2.2/ndtri.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/pdtr.c (build/temp.linux-i686-2.2/pdtr.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/polevl.c (build/temp.linux-i686-2.2/polevl.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/polmisc.c (build/temp.linux-i686-2.2/polmisc.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/polrt.c (build/temp.linux-i686-2.2/polrt.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/polyn.c (build/temp.linux-i686-2.2/polyn.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/powi.c (build/temp.linux-i686-2.2/powi.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/psi.c (build/temp.linux-i686-2.2/psi.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/rgamma.c (build/temp.linux-i686-2.2/rgamma.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/round.c (build/temp.linux-i686-2.2/round.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/setprec.c (build/temp.linux-i686-2.2/setprec.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/shichi.c (build/temp.linux-i686-2.2/shichi.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/sici.c (build/temp.linux-i686-2.2/sici.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/simpsn.c (build/temp.linux-i686-2.2/simpsn.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/simq.c (build/temp.linux-i686-2.2/simq.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/sincos.c (build/temp.linux-i686-2.2/sincos.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/sindg.c (build/temp.linux-i686-2.2/sindg.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/spence.c (build/temp.linux-i686-2.2/spence.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/stdtr.c (build/temp.linux-i686-2.2/stdtr.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/struve.c (build/temp.linux-i686-2.2/struve.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/tandg.c (build/temp.linux-i686-2.2/tandg.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/tukey.c (build/temp.linux-i686-2.2/tukey.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/unity.c (build/temp.linux-i686-2.2/unity.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/yn.c (build/temp.linux-i686-2.2/yn.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/zeta.c (build/temp.linux-i686-2.2/zeta.o up-to-date) skipping /incoming/scipy/scipy/scipy/special/cephes/zetac.c (build/temp.linux-i686-2.2/zetac.o up-to-date) skipping build/temp.linux-i686-2.2/libcephes.a (up-to-date) ranlib build/temp.linux-i686-2.2/libcephes.a building 'rootfind' library skipping /incoming/scipy/scipy/scipy/optimize/Zeros/bisect.c (build/temp.linux-i686-2.2/bisect.o up-to-date) skipping /incoming/scipy/scipy/scipy/optimize/Zeros/brenth.c (build/temp.linux-i686-2.2/brenth.o up-to-date) skipping /incoming/scipy/scipy/scipy/optimize/Zeros/brentq.c (build/temp.linux-i686-2.2/brentq.o up-to-date) skipping /incoming/scipy/scipy/scipy/optimize/Zeros/ridder.c (build/temp.linux-i686-2.2/ridder.o up-to-date) skipping build/temp.linux-i686-2.2/librootfind.a (up-to-date) ranlib build/temp.linux-i686-2.2/librootfind.a building 'gist' library skipping /incoming/scipy/scipy/scipy/xplt/gist/dispas.c (build/temp.linux-i686-2.2/dispas.o up-to-date) skipping /incoming/scipy/scipy/scipy/xplt/gist/cgm.c (build/temp.linux-i686-2.2/cgm.o up-to-date) skipping /incoming/scipy/scipy/scipy/xplt/gist/clip.c (build/temp.linux-i686-2.2/clip.o up-to-date) skipping /incoming/scipy/scipy/scipy/xplt/gist/dispat.c (build/temp.linux-i686-2.2/dispat.o up-to-date) skipping /incoming/scipy/scipy/scipy/xplt/gist/dispax.c (build/temp.linux-i686-2.2/dispax.o up-to-date) skipping /incoming/scipy/scipy/scipy/xplt/gist/draw.c (build/temp.linux-i686-2.2/draw.o up-to-date) skipping /incoming/scipy/scipy/scipy/xplt/gist/draw0.c (build/temp.linux-i686-2.2/draw0.o up-to-date) skipping /incoming/scipy/scipy/scipy/xplt/gist/engine.c (build/temp.linux-i686-2.2/engine.o up-to-date) skipping /incoming/scipy/scipy/scipy/xplt/gist/gcntr.c (build/temp.linux-i686-2.2/gcntr.o up-to-date) skipping /incoming/scipy/scipy/scipy/xplt/gist/gist.c (build/temp.linux-i686-2.2/gist.o up-to-date) skipping /incoming/scipy/scipy/scipy/xplt/gist/gread.c (build/temp.linux-i686-2.2/gread.o up-to-date) skipping /incoming/scipy/scipy/scipy/xplt/gist/gtext.c (build/temp.linux-i686-2.2/gtext.o up-to-date) skipping /incoming/scipy/scipy/scipy/xplt/gist/hlevel.c (build/temp.linux-i686-2.2/hlevel.o up-to-date) skipping /incoming/scipy/scipy/scipy/xplt/gist/host.c (build/temp.linux-i686-2.2/host.o up-to-date) skipping /incoming/scipy/scipy/scipy/xplt/gist/osys.c (build/temp.linux-i686-2.2/osys.o up-to-date) skipping /incoming/scipy/scipy/scipy/xplt/gist/ps.c (build/temp.linux-i686-2.2/ps.o up-to-date) skipping /incoming/scipy/scipy/scipy/xplt/gist/tick.c (build/temp.linux-i686-2.2/tick.o up-to-date) skipping /incoming/scipy/scipy/scipy/xplt/gist/tick60.c (build/temp.linux-i686-2.2/tick60.o up-to-date) skipping /incoming/scipy/scipy/scipy/xplt/gist/xbasic.c (build/temp.linux-i686-2.2/xbasic.o up-to-date) skipping /incoming/scipy/scipy/scipy/xplt/gist/xfancy.c (build/temp.linux-i686-2.2/xfancy.o up-to-date) skipping /incoming/scipy/scipy/scipy/xplt/gist/xfont.c (build/temp.linux-i686-2.2/xfont.o up-to-date) skipping /incoming/scipy/scipy/scipy/xplt/gist/xicky.c (build/temp.linux-i686-2.2/xicky.o up-to-date) skipping build/temp.linux-i686-2.2/libgist.a (up-to-date) ranlib build/temp.linux-i686-2.2/libgist.a running run_f2py using F2PY 2.23.190-1369 using F2PY 2.23.190-1369 using F2PY 2.23.190-1369 using F2PY 2.23.190-1369 using F2PY 2.23.190-1369 using F2PY 2.23.190-1369 using F2PY 2.23.190-1369 using F2PY 2.23.190-1369 using F2PY 2.23.190-1369 using F2PY 2.23.190-1369 using F2PY 2.23.190-1369 using F2PY 2.23.190-1369 using F2PY 2.23.190-1369 using F2PY 2.23.190-1369 using F2PY 2.23.190-1369 using F2PY 2.23.190-1369 using F2PY 2.23.190-1369 using F2PY 2.23.190-1369 using F2PY 2.23.190-1369 using F2PY 2.23.190-1369 using F2PY 2.23.190-1369 using F2PY 2.23.190-1369 using F2PY 2.23.190-1369 using F2PY 2.23.190-1369 running build_flib running find_fortran_compiler detecting Absoft Fortran compiler... f77 -V -c /tmp/__dummy.f -o /tmp/__dummy.o 256: f77: invalid version number format detecting SGI Fortran compiler... f77 -version 256: f77: unrecognized option `-version' detecting Sun Fortran compiler... f90 -V 32512: sh: f90: command not found detecting Intel Fortran compiler... ifc -FI -V -c /tmp/__dummy.f -o /tmp/__dummy.o 32512: sh: ifc: command not found detecting Itanium Fortran compiler... efc -FI -V -c /tmp/__dummy.f -o /tmp/__dummy.o 32512: sh: efc: command not found detecting NAG Fortran compiler... f95 -V 32512: sh: f95: command not found detecting Compaq Fortran compiler... fort -V 32512: sh: fort: command not found detecting Digital Fortran compiler... DF /what 32512: sh: DF: command not found detecting VAST Fortran compiler... vf90 -v 32512: sh: vf90: command not found f90 +version 32512: sh: f90: command not found detecting F Fortran compiler... F -V 32512: sh: F: command not found running gnu_fortran_compiler.find_lib_directories g77 -v detecting Gnu Fortran compiler... g77 --version found GNU Fortran 0.5.26 20000731 (Red Hat Linux 7.3 2.96-113) using Gnu 0.5.26 Fortran compiler building 'mach' library ar -cur build/temp.linux-i686-2.2/libmach.a build/temp.linux-i686-2.2/d1mach.o build/temp.linux-i686-2.2/i1mach.o build/temp.linux-i686-2.2/r1mach.o build/temp.linux-i686-2.2/xerror.o ranlib build/temp.linux-i686-2.2/libmach.a building 'amos' library ar -cur build/temp.linux-i686-2.2/libamos.a build/temp.linux-i686-2.2/dgamln.o build/temp.linux-i686-2.2/dsclmr.o build/temp.linux-i686-2.2/fdump.o build/temp.linux-i686-2.2/zabs.o build/temp.linux-i686-2.2/zacai.o build/temp.linux-i686-2.2/zacon.o build/temp.linux-i686-2.2/zairy.o build/temp.linux-i686-2.2/zasyi.o build/temp.linux-i686-2.2/zbesh.o build/temp.linux-i686-2.2/zbesi.o build/temp.linux-i686-2.2/zbesj.o build/temp.linux-i686-2.2/zbesk.o build/temp.linux-i686-2.2/zbesy.o build/temp.linux-i686-2.2/zbinu.o build/temp.linux-i686-2.2/zbiry.o build/temp.linux-i686-2.2/zbknu.o build/temp.linux-i686-2.2/zbuni.o build/temp.linux-i686-2.2/zbunk.o build/temp.linux-i686-2.2/zdiv.o build/temp.linux-i686-2.2/zexp.o build/temp.linux-i686-2.2/zkscl.o build/temp.linux-i686-2.2/zlog.o build/temp.linux-i686-2.2/zmlri.o build/temp.linux-i686-2.2/zmlt.o build/temp.linux-i686-2.2/zrati.o build/temp.linux-i686-2.2/zs1s2.o build/temp.linux-i686-2.2/zseri.o build/temp.linux-i686-2.2/zshch.o build/temp.linux-i686-2.2/zsqrt.o build/temp.linux-i686-2.2/zuchk.o build/temp.linux-i686-2.2/zunhj.o build/temp.linux-i686-2.2/zuni1.o build/temp.linux-i686-2.2/zuni2.o build/temp.linux-i686-2.2/zunik.o build/temp.linux-i686-2.2/zunk1.o build/temp.linux-i686-2.2/zunk2.o build/temp.linux-i686-2.2/zuoik.o build/temp.linux-i686-2.2/zwrsk.o ranlib build/temp.linux-i686-2.2/libamos.a building 'toms' library ar -cur build/temp.linux-i686-2.2/libtoms.a build/temp.linux-i686-2.2/wofz.o ranlib build/temp.linux-i686-2.2/libtoms.a building 'cdf' library ar -cur build/temp.linux-i686-2.2/libcdf.a build/temp.linux-i686-2.2/algdiv.o build/temp.linux-i686-2.2/alngam.o build/temp.linux-i686-2.2/alnrel.o build/temp.linux-i686-2.2/apser.o build/temp.linux-i686-2.2/basym.o build/temp.linux-i686-2.2/bcorr.o build/temp.linux-i686-2.2/betaln.o build/temp.linux-i686-2.2/bfrac.o build/temp.linux-i686-2.2/bgrat.o build/temp.linux-i686-2.2/bpser.o build/temp.linux-i686-2.2/bratio.o build/temp.linux-i686-2.2/brcmp1.o build/temp.linux-i686-2.2/brcomp.o build/temp.linux-i686-2.2/bup.o build/temp.linux-i686-2.2/cdfbet.o build/temp.linux-i686-2.2/cdfbin.o build/temp.linux-i686-2.2/cdfchi.o build/temp.linux-i686-2.2/cdfchn.o build/temp.linux-i686-2.2/cdff.o build/temp.linux-i686-2.2/cdffnc.o build/temp.linux-i686-2.2/cdfgam.o build/temp.linux-i686-2.2/cdfnbn.o build/temp.linux-i686-2.2/cdfnor.o build/temp.linux-i686-2.2/cdfpoi.o build/temp.linux-i686-2.2/cdft.o build/temp.linux-i686-2.2/cdftnc.o build/temp.linux-i686-2.2/cumbet.o build/temp.linux-i686-2.2/cumbin.o build/temp.linux-i686-2.2/cumchi.o build/temp.linux-i686-2.2/cumchn.o build/temp.linux-i686-2.2/cumf.o build/temp.linux-i686-2.2/cumfnc.o build/temp.linux-i686-2.2/cumgam.o build/temp.linux-i686-2.2/cumnbn.o build/temp.linux-i686-2.2/cumnor.o build/temp.linux-i686-2.2/cumpoi.o build/temp.linux-i686-2.2/cumt.o build/temp.linux-i686-2.2/cumtnc.o build/temp.linux-i686-2.2/devlpl.o build/temp.linux-i686-2.2/dinvnr.o build/temp.linux-i686-2.2/dinvr.o build/temp.linux-i686-2.2/dt1.o build/temp.linux-i686-2.2/dzror.o build/temp.linux-i686-2.2/erf.o build/temp.linux-i686-2.2/erfc1.o build/temp.linux-i686-2.2/esum.o build/temp.linux-i686-2.2/exparg.o build/temp.linux-i686-2.2/fpser.o build/temp.linux-i686-2.2/gam1.o build/temp.linux-i686-2.2/gaminv.o build/temp.linux-i686-2.2/gamln.o build/temp.linux-i686-2.2/gamln1.o build/temp.linux-i686-2.2/gamma_fort.o build/temp.linux-i686-2.2/grat1.o build/temp.linux-i686-2.2/gratio.o build/temp.linux-i686-2.2/gsumln.o build/temp.linux-i686-2.2/ipmpar.o build/temp.linux-i686-2.2/psi_fort.o build/temp.linux-i686-2.2/rcomp.o build/temp.linux-i686-2.2/rexp.o build/temp.linux-i686-2.2/rlog.o build/temp.linux-i686-2.2/rlog1.o build/temp.linux-i686-2.2/spmpar.o build/temp.linux-i686-2.2/stvaln.o ranlib build/temp.linux-i686-2.2/libcdf.a building 'specfun' library ar -cur build/temp.linux-i686-2.2/libspecfun.a build/temp.linux-i686-2.2/specfun.o ranlib build/temp.linux-i686-2.2/libspecfun.a building 'statlib' library ar -cur build/temp.linux-i686-2.2/libstatlib.a build/temp.linux-i686-2.2/ansari.o build/temp.linux-i686-2.2/spearman.o build/temp.linux-i686-2.2/swilk.o ranlib build/temp.linux-i686-2.2/libstatlib.a building 'fitpack' library ar -cur build/temp.linux-i686-2.2/libfitpack.a build/temp.linux-i686-2.2/bispev.o build/temp.linux-i686-2.2/clocur.o build/temp.linux-i686-2.2/cocosp.o build/temp.linux-i686-2.2/concon.o build/temp.linux-i686-2.2/concur.o build/temp.linux-i686-2.2/cualde.o build/temp.linux-i686-2.2/curev.o build/temp.linux-i686-2.2/curfit.o build/temp.linux-i686-2.2/dblint.o build/temp.linux-i686-2.2/evapol.o build/temp.linux-i686-2.2/fourco.o build/temp.linux-i686-2.2/fpader.o build/temp.linux-i686-2.2/fpadno.o build/temp.linux-i686-2.2/fpadpo.o build/temp.linux-i686-2.2/fpback.o build/temp.linux-i686-2.2/fpbacp.o build/temp.linux-i686-2.2/fpbfout.o build/temp.linux-i686-2.2/fpbisp.o build/temp.linux-i686-2.2/fpbspl.o build/temp.linux-i686-2.2/fpchec.o build/temp.linux-i686-2.2/fpched.o build/temp.linux-i686-2.2/fpchep.o build/temp.linux-i686-2.2/fpclos.o build/temp.linux-i686-2.2/fpcoco.o build/temp.linux-i686-2.2/fpcons.o build/temp.linux-i686-2.2/fpcosp.o build/temp.linux-i686-2.2/fpcsin.o build/temp.linux-i686-2.2/fpcurf.o build/temp.linux-i686-2.2/fpcuro.o build/temp.linux-i686-2.2/fpcyt1.o build/temp.linux-i686-2.2/fpcyt2.o build/temp.linux-i686-2.2/fpdeno.o build/temp.linux-i686-2.2/fpdisc.o build/temp.linux-i686-2.2/fpfrno.o build/temp.linux-i686-2.2/fpgivs.o build/temp.linux-i686-2.2/fpgrdi.o build/temp.linux-i686-2.2/fpgrpa.o build/temp.linux-i686-2.2/fpgrre.o build/temp.linux-i686-2.2/fpgrsp.o build/temp.linux-i686-2.2/fpinst.o build/temp.linux-i686-2.2/fpintb.o build/temp.linux-i686-2.2/fpknot.o build/temp.linux-i686-2.2/fpopdi.o build/temp.linux-i686-2.2/fpopsp.o build/temp.linux-i686-2.2/fporde.o build/temp.linux-i686-2.2/fppara.o build/temp.linux-i686-2.2/fppasu.o build/temp.linux-i686-2.2/fpperi.o build/temp.linux-i686-2.2/fppocu.o build/temp.linux-i686-2.2/fppogr.o build/temp.linux-i686-2.2/fppola.o build/temp.linux-i686-2.2/fprank.o build/temp.linux-i686-2.2/fprati.o build/temp.linux-i686-2.2/fpregr.o build/temp.linux-i686-2.2/fprota.o build/temp.linux-i686-2.2/fprppo.o build/temp.linux-i686-2.2/fprpsp.o build/temp.linux-i686-2.2/fpseno.o build/temp.linux-i686-2.2/fpspgr.o build/temp.linux-i686-2.2/fpsphe.o build/temp.linux-i686-2.2/fpsuev.o build/temp.linux-i686-2.2/fpsurf.o build/temp.linux-i686-2.2/fpsysy.o build/temp.linux-i686-2.2/fptrnp.o build/temp.linux-i686-2.2/fptrpe.o build/temp.linux-i686-2.2/insert.o build/temp.linux-i686-2.2/parcur.o build/temp.linux-i686-2.2/parder.o build/temp.linux-i686-2.2/parsur.o build/temp.linux-i686-2.2/percur.o build/temp.linux-i686-2.2/pogrid.o build/temp.linux-i686-2.2/polar.o build/temp.linux-i686-2.2/profil.o build/temp.linux-i686-2.2/regrid.o build/temp.linux-i686-2.2/spalde.o build/temp.linux-i686-2.2/spgrid.o build/temp.linux-i686-2.2/sphere.o build/temp.linux-i686-2.2/splder.o build/temp.linux-i686-2.2/splev.o build/temp.linux-i686-2.2/splint.o build/temp.linux-i686-2.2/sproot.o build/temp.linux-i686-2.2/surev.o build/temp.linux-i686-2.2/surfit.o ranlib build/temp.linux-i686-2.2/libfitpack.a building 'quadpack' library ar -cur build/temp.linux-i686-2.2/libquadpack.a build/temp.linux-i686-2.2/dqag.o build/temp.linux-i686-2.2/dqagie.o build/temp.linux-i686-2.2/dqage.o build/temp.linux-i686-2.2/dqagi.o build/temp.linux-i686-2.2/dqagpe.o build/temp.linux-i686-2.2/dqagp.o build/temp.linux-i686-2.2/dqagse.o build/temp.linux-i686-2.2/dqags.o build/temp.linux-i686-2.2/dqawce.o build/temp.linux-i686-2.2/dqawc.o build/temp.linux-i686-2.2/dqawfe.o build/temp.linux-i686-2.2/dqawf.o build/temp.linux-i686-2.2/dqawoe.o build/temp.linux-i686-2.2/dqawo.o build/temp.linux-i686-2.2/dqawse.o build/temp.linux-i686-2.2/dqaws.o build/temp.linux-i686-2.2/dqc25c.o build/temp.linux-i686-2.2/dqc25f.o build/temp.linux-i686-2.2/dqc25s.o build/temp.linux-i686-2.2/dqcheb.o build/temp.linux-i686-2.2/dqelg.o build/temp.linux-i686-2.2/dqk15.o build/temp.linux-i686-2.2/dqk15i.o build/temp.linux-i686-2.2/dqk15w.o build/temp.linux-i686-2.2/dqk21.o build/temp.linux-i686-2.2/dqk31.o build/temp.linux-i686-2.2/dqk41.o build/temp.linux-i686-2.2/dqk51.o build/temp.linux-i686-2.2/dqk61.o build/temp.linux-i686-2.2/dqmomo.o build/temp.linux-i686-2.2/dqng.o build/temp.linux-i686-2.2/dqpsrt.o build/temp.linux-i686-2.2/dqwgtc.o build/temp.linux-i686-2.2/dqwgtf.o build/temp.linux-i686-2.2/dqwgts.o ranlib build/temp.linux-i686-2.2/libquadpack.a building 'odepack' library ar -cur build/temp.linux-i686-2.2/libodepack.a build/temp.linux-i686-2.2/adjlr.o build/temp.linux-i686-2.2/aigbt.o build/temp.linux-i686-2.2/ainvg.o build/temp.linux-i686-2.2/blkdta000.o build/temp.linux-i686-2.2/bnorm.o build/temp.linux-i686-2.2/cdrv.o build/temp.linux-i686-2.2/cfode.o build/temp.linux-i686-2.2/cntnzu.o build/temp.linux-i686-2.2/ddasrt.o build/temp.linux-i686-2.2/ddassl.o build/temp.linux-i686-2.2/decbt.o build/temp.linux-i686-2.2/ewset.o build/temp.linux-i686-2.2/fnorm.o build/temp.linux-i686-2.2/intdy.o build/temp.linux-i686-2.2/iprep.o build/temp.linux-i686-2.2/jgroup.o build/temp.linux-i686-2.2/lsoda.o build/temp.linux-i686-2.2/lsodar.o build/temp.linux-i686-2.2/lsode.o build/temp.linux-i686-2.2/lsodes.o build/temp.linux-i686-2.2/lsodi.o build/temp.linux-i686-2.2/lsoibt.o build/temp.linux-i686-2.2/md.o build/temp.linux-i686-2.2/mdi.o build/temp.linux-i686-2.2/mdm.o build/temp.linux-i686-2.2/mdp.o build/temp.linux-i686-2.2/mdu.o build/temp.linux-i686-2.2/nnfc.o build/temp.linux-i686-2.2/nnsc.o build/temp.linux-i686-2.2/nntc.o build/temp.linux-i686-2.2/nroc.o build/temp.linux-i686-2.2/nsfc.o build/temp.linux-i686-2.2/odrv.o build/temp.linux-i686-2.2/pjibt.o build/temp.linux-i686-2.2/prep.o build/temp.linux-i686-2.2/prepj.o build/temp.linux-i686-2.2/prepji.o build/temp.linux-i686-2.2/prja.o build/temp.linux-i686-2.2/prjs.o build/temp.linux-i686-2.2/rchek.o build/temp.linux-i686-2.2/roots.o build/temp.linux-i686-2.2/slsbt.o build/temp.linux-i686-2.2/slss.o build/temp.linux-i686-2.2/solbt.o build/temp.linux-i686-2.2/solsy.o build/temp.linux-i686-2.2/srcar.o build/temp.linux-i686-2.2/srcma.o build/temp.linux-i686-2.2/srcms.o build/temp.linux-i686-2.2/srcom.o build/temp.linux-i686-2.2/sro.o build/temp.linux-i686-2.2/stoda.o build/temp.linux-i686-2.2/stode.o build/temp.linux-i686-2.2/stodi.o build/temp.linux-i686-2.2/vmnorm.o build/temp.linux-i686-2.2/vnorm.o build/temp.linux-i686-2.2/vode.o build/temp.linux-i686-2.2/xerrwv.o build/temp.linux-i686-2.2/xsetf.o build/temp.linux-i686-2.2/xsetun.o ranlib build/temp.linux-i686-2.2/libodepack.a building 'linpack_lite' library ar -cur build/temp.linux-i686-2.2/liblinpack_lite.a build/temp.linux-i686-2.2/dgbfa.o build/temp.linux-i686-2.2/dgbsl.o build/temp.linux-i686-2.2/dgefa.o build/temp.linux-i686-2.2/dgesl.o build/temp.linux-i686-2.2/dgtsl.o ranlib build/temp.linux-i686-2.2/liblinpack_lite.a building 'mach' library ar -cur build/temp.linux-i686-2.2/libmach.a build/temp.linux-i686-2.2/d1mach.o build/temp.linux-i686-2.2/i1mach.o build/temp.linux-i686-2.2/r1mach.o build/temp.linux-i686-2.2/xerror.o ranlib build/temp.linux-i686-2.2/libmach.a building 'minpack' library ar -cur build/temp.linux-i686-2.2/libminpack.a build/temp.linux-i686-2.2/chkder.o build/temp.linux-i686-2.2/dogleg.o build/temp.linux-i686-2.2/dpmpar.o build/temp.linux-i686-2.2/enorm.o build/temp.linux-i686-2.2/fdjac1.o build/temp.linux-i686-2.2/fdjac2.o build/temp.linux-i686-2.2/hybrd.o build/temp.linux-i686-2.2/hybrd1.o build/temp.linux-i686-2.2/hybrj.o build/temp.linux-i686-2.2/hybrj1.o build/temp.linux-i686-2.2/lmder.o build/temp.linux-i686-2.2/lmder1.o build/temp.linux-i686-2.2/lmdif.o build/temp.linux-i686-2.2/lmdif1.o build/temp.linux-i686-2.2/lmpar.o build/temp.linux-i686-2.2/lmstr.o build/temp.linux-i686-2.2/lmstr1.o build/temp.linux-i686-2.2/qform.o build/temp.linux-i686-2.2/qrfac.o build/temp.linux-i686-2.2/qrsolv.o build/temp.linux-i686-2.2/r1mpyq.o build/temp.linux-i686-2.2/r1updt.o build/temp.linux-i686-2.2/rwupdt.o ranlib build/temp.linux-i686-2.2/libminpack.a building 'fftpack' library ar -cur build/temp.linux-i686-2.2/libfftpack.a build/temp.linux-i686-2.2/cfftb1.o build/temp.linux-i686-2.2/cfftb.o build/temp.linux-i686-2.2/cfftf1.o build/temp.linux-i686-2.2/cfftf.o build/temp.linux-i686-2.2/cffti1.o build/temp.linux-i686-2.2/cffti.o build/temp.linux-i686-2.2/rfftb1.o build/temp.linux-i686-2.2/cosqb.o build/temp.linux-i686-2.2/cosqf.o build/temp.linux-i686-2.2/cosqi.o build/temp.linux-i686-2.2/cost.o build/temp.linux-i686-2.2/costi.o build/temp.linux-i686-2.2/rfftb.o build/temp.linux-i686-2.2/rfftf1.o build/temp.linux-i686-2.2/rfftf.o build/temp.linux-i686-2.2/rffti1.o build/temp.linux-i686-2.2/rffti.o build/temp.linux-i686-2.2/sinqb.o build/temp.linux-i686-2.2/sinqf.o build/temp.linux-i686-2.2/sinqi.o build/temp.linux-i686-2.2/sint.o build/temp.linux-i686-2.2/sint1.o build/temp.linux-i686-2.2/sinti.o ranlib build/temp.linux-i686-2.2/libfftpack.a building 'dfftpack' library ar -cur build/temp.linux-i686-2.2/libdfftpack.a build/temp.linux-i686-2.2/dcosqb.o build/temp.linux-i686-2.2/dcosqf.o build/temp.linux-i686-2.2/dcosqi.o build/temp.linux-i686-2.2/dcost.o build/temp.linux-i686-2.2/dcosti.o build/temp.linux-i686-2.2/dfftb.o build/temp.linux-i686-2.2/dfftb1.o build/temp.linux-i686-2.2/dfftf.o build/temp.linux-i686-2.2/dfftf1.o build/temp.linux-i686-2.2/dffti.o build/temp.linux-i686-2.2/dffti1.o build/temp.linux-i686-2.2/dsinqb.o build/temp.linux-i686-2.2/dsinqf.o build/temp.linux-i686-2.2/dsinqi.o build/temp.linux-i686-2.2/dsint.o build/temp.linux-i686-2.2/dsint1.o build/temp.linux-i686-2.2/dsinti.o build/temp.linux-i686-2.2/zfftb.o build/temp.linux-i686-2.2/zfftb1.o build/temp.linux-i686-2.2/zfftf.o build/temp.linux-i686-2.2/zfftf1.o build/temp.linux-i686-2.2/zffti.o build/temp.linux-i686-2.2/zffti1.o ranlib build/temp.linux-i686-2.2/libdfftpack.a building 'fblas' library ar -cur build/temp.linux-i686-2.2/libfblas.a build/temp.linux-i686-2.2/fblaswrap.o ranlib build/temp.linux-i686-2.2/libfblas.a building '_flinalg' library ar -cur build/temp.linux-i686-2.2/lib_flinalg.a build/temp.linux-i686-2.2/det.o build/temp.linux-i686-2.2/lu.o ranlib build/temp.linux-i686-2.2/lib_flinalg.a building 'calc_lwork' library ar -cur build/temp.linux-i686-2.2/libcalc_lwork.a build/temp.linux-i686-2.2/calc_lwork.o ranlib build/temp.linux-i686-2.2/libcalc_lwork.a running build_ext skipping 'scipy.io.numpyio' extension (up-to-date) replacing linker_so 'gcc -shared' with 'g77 -shared' skipping 'scipy.linalg.fblas' extension (up-to-date) restoring linker_so 'gcc -shared' replacing linker_so 'gcc -shared' with 'g77 -shared' skipping 'scipy.linalg.flapack' extension (up-to-date) restoring linker_so 'gcc -shared' replacing linker_so 'gcc -shared' with 'g77 -shared' skipping 'scipy.linalg.cblas' extension (up-to-date) restoring linker_so 'gcc -shared' replacing linker_so 'gcc -shared' with 'g77 -shared' skipping 'scipy.linalg.clapack' extension (up-to-date) restoring linker_so 'gcc -shared' replacing linker_so 'gcc -shared' with 'g77 -shared' skipping 'scipy.linalg._flinalg' extension (up-to-date) restoring linker_so 'gcc -shared' replacing linker_so 'gcc -shared' with 'g77 -shared' skipping 'scipy.linalg.calc_lwork' extension (up-to-date) restoring linker_so 'gcc -shared' replacing linker_so 'gcc -shared' with 'g77 -shared' skipping 'scipy.special.cephes' extension (up-to-date) restoring linker_so 'gcc -shared' replacing linker_so 'gcc -shared' with 'g77 -shared' skipping 'scipy.special.specfun' extension (up-to-date) restoring linker_so 'gcc -shared' skipping 'scipy.signal.sigtools' extension (up-to-date) skipping 'scipy.signal.spline' extension (up-to-date) skipping 'scipy.stats.rand' extension (up-to-date) replacing linker_so 'gcc -shared' with 'g77 -shared' skipping 'scipy.stats.statlib' extension (up-to-date) restoring linker_so 'gcc -shared' replacing linker_so 'gcc -shared' with 'g77 -shared' skipping 'scipy.interpolate._fitpack' extension (up-to-date) restoring linker_so 'gcc -shared' replacing linker_so 'gcc -shared' with 'g77 -shared' skipping 'scipy.integrate._quadpack' extension (up-to-date) restoring linker_so 'gcc -shared' replacing linker_so 'gcc -shared' with 'g77 -shared' skipping 'scipy.integrate._odepack' extension (up-to-date) restoring linker_so 'gcc -shared' replacing linker_so 'gcc -shared' with 'g77 -shared' skipping 'scipy.integrate.vode' extension (up-to-date) restoring linker_so 'gcc -shared' replacing linker_so 'gcc -shared' with 'g77 -shared' skipping 'scipy.optimize._minpack' extension (up-to-date) restoring linker_so 'gcc -shared' skipping 'scipy.optimize._zeros' extension (up-to-date) skipping 'scipy.cluster._vq' extension (up-to-date) replacing linker_so 'gcc -shared' with 'g77 -shared' skipping 'scipy.fftpack.fftpack' extension (up-to-date) restoring linker_so 'gcc -shared' skipping 'scipy.xplt.gistC' extension (up-to-date) skipping 'scipy_base.fastumath' extension (up-to-date) skipping 'scipy_base._compiled_base' extension (up-to-date) running install_lib not copying build/lib.linux-i686-2.2/scipy/__cvs_version__.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/__init__.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/common.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/helper.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/helpmod.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/pilutil.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/proc.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/scipy_tempfile.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/scipy_version.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/setup_scipy.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/sync.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/tests/test_basic.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/tests/test_basic1a.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/tests/test_common.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/io/__init__.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/io/array_import.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/io/data_store.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/io/dumb_shelve.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/io/dumbdbm_patched.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/io/mio.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/io/pickler.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/io/setup_io.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/io/tests/testio.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/io/numpyio.so (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/linalg/__init__.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/linalg/basic.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/linalg/blas.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/linalg/decomp.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/linalg/flinalg.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/linalg/interface_gen.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/linalg/lapack.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/linalg/matfuncs.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/linalg/setup_atlas_version.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/linalg/setup_linalg.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/linalg/tests/test_basic.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/linalg/tests/test_blas.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/linalg/tests/test_decomp.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/linalg/tests/test_fblas.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/linalg/tests/test_lapack.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/linalg/fblas.so (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/linalg/flapack.so (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/linalg/cblas.so (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/linalg/clapack.so (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/linalg/_flinalg.so (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/linalg/calc_lwork.so (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/special/__init__.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/special/gendoc.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/special/orthogonal.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/special/setup_special.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/special/special.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/special/tests/Test.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/special/tests/test_cephes.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/special/cephes.so (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/special/specfun.so (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/signal/__init__.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/signal/bsplines.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/signal/filter_design.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/signal/ltisys.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/signal/setup_signal.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/signal/signaltools.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/signal/sigtools.so (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/signal/spline.so (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/stats/__init__.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/stats/distributions.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/stats/morestats.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/stats/pstat.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/stats/rv.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/stats/rv2.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/stats/setup_stats.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/stats/stats.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/stats/tests/test_distributions.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/stats/tests/test_morestats.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/stats/tests/test_stats.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/stats/rand.so (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/stats/statlib.so (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/interpolate/__init__.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/interpolate/common_routines.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/interpolate/fitpack.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/interpolate/interpolate.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/interpolate/setup_interpolate.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/interpolate/_fitpack.so (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/integrate/__init__.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/integrate/common_routines.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/integrate/ode.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/integrate/odepack.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/integrate/quadpack.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/integrate/quadrature.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/integrate/setup_integrate.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/integrate/_quadpack.so (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/integrate/_odepack.so (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/integrate/vode.so (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/optimize/__init__.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/optimize/anneal.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/optimize/common_routines.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/optimize/minpack.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/optimize/optimize.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/optimize/setup_optimize.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/optimize/zeros.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/optimize/tests/test_zeros.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/optimize/_minpack.so (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/optimize/_zeros.so (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/cluster/__init__.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/cluster/setup_cluster.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/cluster/vq.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/cluster/tests/vq_test.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/cluster/_vq.so (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/cow/__init__.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/cow/cow.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/cow/herd.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/cow/setup_cow.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/cow/sync_cluster.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/ga/__init__.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/ga/algorithm.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/ga/examples.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/ga/ga_gnm.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/ga/ga_list.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/ga/ga_util.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/ga/gene.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/ga/genome.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/ga/language.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/ga/parallel_pop.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/ga/population.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/ga/scaling.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/ga/selection.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/ga/setup_ga.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/ga/tree.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/ga/tree_opt.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/fftpack/__init__.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/fftpack/fft.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/fftpack/setup_fftpack.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/fftpack/fftpack.so (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/plt/__init__.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/plt/colormap.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/plt/dumb_shelve.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/plt/dumbdbm_patched.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/plt/interface.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/plt/plot_objects.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/plt/plot_utility.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/plt/setup_plt.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/plt/wxplt.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/gplt/__init__.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/gplt/interface.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/gplt/new_plot.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/gplt/pyPlot.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/gplt/setup_gplt.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/GistPlotter.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/Graphics.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/Mplot.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/NarPlotter.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/__init__.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/animation2d.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/berts.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/cellarray.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/colorbar.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/curve.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/demo5.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/ezplot.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/eztest.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/gist.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/gist3dhelp.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/gistdemohigh.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/gistdemolow.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/gistmeshtest.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/gisttest2d.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/gisttest3d.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/graftest2d.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/graftypes.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/graph.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/graph2d.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/graph3d.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/helpmod.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/lines.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/mesh3d.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/meshtest.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/movie.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/nicks.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/pl3d.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/plane.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/plwf.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/polymap.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/quadmesh.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/region.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/setup_xplt.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/shapetest.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/slice3.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/sphereisos.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/surface.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/surftest3d.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/surftest4d.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/twograftest2d.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/write_style.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/yorick.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy/xplt/gistC.so (output up-to-date) not copying build/lib.linux-i686-2.2/gui_thread/__init__.py (output up-to-date) not copying build/lib.linux-i686-2.2/gui_thread/examples.py (output up-to-date) not copying build/lib.linux-i686-2.2/gui_thread/gui_thread_guts.py (output up-to-date) not copying build/lib.linux-i686-2.2/gui_thread/main.py (output up-to-date) not copying build/lib.linux-i686-2.2/gui_thread/setup_gui_thread.py (output up-to-date) not copying build/lib.linux-i686-2.2/gui_thread/tests/test_gui_thread.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_base/__cvs_version__.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_base/__init__.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_base/function_base.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_base/index_tricks.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_base/limits.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_base/matrix_base.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_base/polynomial.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_base/scimath.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_base/scipy_base_version.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_base/setup_scipy_base.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_base/shape_base.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_base/type_check.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_base/tests/test_function_base.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_base/tests/test_index_tricks.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_base/tests/test_limits.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_base/tests/test_matrix_base.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_base/tests/test_shape_base.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_base/tests/test_type_check.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_base/fastumath.so (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_base/_compiled_base.so (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_distutils/__cvs_version__.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_distutils/__init__.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_distutils/core.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_distutils/dist.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_distutils/extension.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_distutils/lib2def.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_distutils/line_endings.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_distutils/mingw32_support.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_distutils/misc_util.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_distutils/scipy_distutils_version.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_distutils/setup_scipy_distutils.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_distutils/system_info.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_distutils/command/__init__.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_distutils/command/build.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_distutils/command/build_clib.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_distutils/command/build_ext.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_distutils/command/build_flib.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_distutils/command/build_py.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_distutils/command/cpuinfo.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_distutils/command/install.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_distutils/command/install_data.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_distutils/command/install_headers.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_distutils/command/run_f2py.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_distutils/command/sdist.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_test/__cvs_version__.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_test/__init__.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_test/auto_test.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_test/logging.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_test/scipy_test_version.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_test/setup_scipy_test.py (output up-to-date) not copying build/lib.linux-i686-2.2/scipy_test/testing.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/__init__.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/accelerate_tools.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/ast_tools.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/base_info.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/base_spec.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/blitz_spec.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/blitz_tools.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/build_tools.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/bytecodecompiler.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/c_spec.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/catalog.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/common_info.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/converters.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/dumb_shelve.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/dumbdbm_patched.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/ext_tools.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/inline_tools.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/setup_weave.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/size_check.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/slice_handler.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/standard_array_spec.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/vtk_spec.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/wx_spec.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/tests/scxx_timings.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/tests/test_ast_tools.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/tests/test_blitz_tools.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/tests/test_build_tools.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/tests/test_c_spec.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/tests/test_catalog.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/tests/test_ext_tools.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/tests/test_inline_tools.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/tests/test_scxx.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/tests/test_scxx_dict.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/tests/test_scxx_object.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/tests/test_scxx_sequence.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/tests/test_size_check.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/tests/test_slice_handler.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/tests/test_standard_array_spec.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/tests/test_wx_spec.py (output up-to-date) not copying build/lib.linux-i686-2.2/weave/tests/weave_test_utils.py (output up-to-date) skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/__cvs_version__.py to __cvs_version__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/__init__.py to __init__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/common.py to common.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/helper.py to helper.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/helpmod.py to helpmod.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/pilutil.py to pilutil.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/proc.py to proc.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/scipy_tempfile.py to scipy_tempfile.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/scipy_version.py to scipy_version.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/setup_scipy.py to setup_scipy.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/sync.py to sync.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/tests/test_basic.py to test_basic.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/tests/test_basic1a.py to test_basic1a.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/tests/test_common.py to test_common.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/io/__init__.py to __init__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/io/array_import.py to array_import.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/io/data_store.py to data_store.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/io/dumb_shelve.py to dumb_shelve.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/io/dumbdbm_patched.py to dumbdbm_patched.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/io/mio.py to mio.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/io/pickler.py to pickler.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/io/setup_io.py to setup_io.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/io/tests/testio.py to testio.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/linalg/__init__.py to __init__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/linalg/basic.py to basic.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/linalg/blas.py to blas.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/linalg/decomp.py to decomp.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/linalg/flinalg.py to flinalg.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/linalg/interface_gen.py to interface_gen.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/linalg/lapack.py to lapack.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/linalg/matfuncs.py to matfuncs.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/linalg/setup_atlas_version.py to setup_atlas_version.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/linalg/setup_linalg.py to setup_linalg.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/linalg/tests/test_basic.py to test_basic.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/linalg/tests/test_blas.py to test_blas.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/linalg/tests/test_decomp.py to test_decomp.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/linalg/tests/test_fblas.py to test_fblas.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/linalg/tests/test_lapack.py to test_lapack.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/special/__init__.py to __init__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/special/gendoc.py to gendoc.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/special/orthogonal.py to orthogonal.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/special/setup_special.py to setup_special.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/special/special.py to special.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/special/tests/Test.py to Test.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/special/tests/test_cephes.py to test_cephes.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/signal/__init__.py to __init__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/signal/bsplines.py to bsplines.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/signal/filter_design.py to filter_design.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/signal/ltisys.py to ltisys.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/signal/setup_signal.py to setup_signal.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/signal/signaltools.py to signaltools.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/stats/__init__.py to __init__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/stats/distributions.py to distributions.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/stats/morestats.py to morestats.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/stats/pstat.py to pstat.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/stats/rv.py to rv.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/stats/rv2.py to rv2.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/stats/setup_stats.py to setup_stats.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/stats/stats.py to stats.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/stats/tests/test_distributions.py to test_distributions.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/stats/tests/test_morestats.py to test_morestats.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/stats/tests/test_stats.py to test_stats.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/interpolate/__init__.py to __init__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/interpolate/common_routines.py to common_routines.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/interpolate/fitpack.py to fitpack.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/interpolate/interpolate.py to interpolate.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/interpolate/setup_interpolate.py to setup_interpolate.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/integrate/__init__.py to __init__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/integrate/common_routines.py to common_routines.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/integrate/ode.py to ode.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/integrate/odepack.py to odepack.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/integrate/quadpack.py to quadpack.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/integrate/quadrature.py to quadrature.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/integrate/setup_integrate.py to setup_integrate.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/optimize/__init__.py to __init__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/optimize/anneal.py to anneal.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/optimize/common_routines.py to common_routines.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/optimize/minpack.py to minpack.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/optimize/optimize.py to optimize.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/optimize/setup_optimize.py to setup_optimize.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/optimize/zeros.py to zeros.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/optimize/tests/test_zeros.py to test_zeros.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/cluster/__init__.py to __init__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/cluster/setup_cluster.py to setup_cluster.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/cluster/vq.py to vq.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/cluster/tests/vq_test.py to vq_test.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/cow/__init__.py to __init__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/cow/cow.py to cow.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/cow/herd.py to herd.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/cow/setup_cow.py to setup_cow.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/cow/sync_cluster.py to sync_cluster.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/ga/__init__.py to __init__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/ga/algorithm.py to algorithm.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/ga/examples.py to examples.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/ga/ga_gnm.py to ga_gnm.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/ga/ga_list.py to ga_list.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/ga/ga_util.py to ga_util.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/ga/gene.py to gene.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/ga/genome.py to genome.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/ga/language.py to language.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/ga/parallel_pop.py to parallel_pop.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/ga/population.py to population.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/ga/scaling.py to scaling.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/ga/selection.py to selection.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/ga/setup_ga.py to setup_ga.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/ga/tree.py to tree.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/ga/tree_opt.py to tree_opt.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/fftpack/__init__.py to __init__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/fftpack/fft.py to fft.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/fftpack/setup_fftpack.py to setup_fftpack.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/plt/__init__.py to __init__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/plt/colormap.py to colormap.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/plt/dumb_shelve.py to dumb_shelve.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/plt/dumbdbm_patched.py to dumbdbm_patched.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/plt/interface.py to interface.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/plt/plot_objects.py to plot_objects.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/plt/plot_utility.py to plot_utility.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/plt/setup_plt.py to setup_plt.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/plt/wxplt.py to wxplt.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/gplt/__init__.py to __init__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/gplt/interface.py to interface.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/gplt/new_plot.py to new_plot.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/gplt/pyPlot.py to pyPlot.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/gplt/setup_gplt.py to setup_gplt.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/GistPlotter.py to GistPlotter.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/Graphics.py to Graphics.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/Mplot.py to Mplot.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/NarPlotter.py to NarPlotter.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/__init__.py to __init__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/animation2d.py to animation2d.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/berts.py to berts.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/cellarray.py to cellarray.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/colorbar.py to colorbar.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/curve.py to curve.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/demo5.py to demo5.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/ezplot.py to ezplot.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/eztest.py to eztest.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/gist.py to gist.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/gist3dhelp.py to gist3dhelp.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/gistdemohigh.py to gistdemohigh.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/gistdemolow.py to gistdemolow.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/gistmeshtest.py to gistmeshtest.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/gisttest2d.py to gisttest2d.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/gisttest3d.py to gisttest3d.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/graftest2d.py to graftest2d.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/graftypes.py to graftypes.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/graph.py to graph.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/graph2d.py to graph2d.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/graph3d.py to graph3d.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/helpmod.py to helpmod.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/lines.py to lines.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/mesh3d.py to mesh3d.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/meshtest.py to meshtest.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/movie.py to movie.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/nicks.py to nicks.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/pl3d.py to pl3d.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/plane.py to plane.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/plwf.py to plwf.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/polymap.py to polymap.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/quadmesh.py to quadmesh.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/region.py to region.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/setup_xplt.py to setup_xplt.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/shapetest.py to shapetest.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/slice3.py to slice3.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/sphereisos.py to sphereisos.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/surface.py to surface.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/surftest3d.py to surftest3d.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/surftest4d.py to surftest4d.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/twograftest2d.py to twograftest2d.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/write_style.py to write_style.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy/xplt/yorick.py to yorick.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/gui_thread/__init__.py to __init__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/gui_thread/examples.py to examples.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/gui_thread/gui_thread_guts.py to gui_thread_guts.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/gui_thread/main.py to main.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/gui_thread/setup_gui_thread.py to setup_gui_thread.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/gui_thread/tests/test_gui_thread.py to test_gui_thread.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_base/__cvs_version__.py to __cvs_version__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_base/__init__.py to __init__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_base/function_base.py to function_base.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_base/index_tricks.py to index_tricks.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_base/limits.py to limits.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_base/matrix_base.py to matrix_base.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_base/polynomial.py to polynomial.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_base/scimath.py to scimath.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_base/scipy_base_version.py to scipy_base_version.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_base/setup_scipy_base.py to setup_scipy_base.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_base/shape_base.py to shape_base.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_base/type_check.py to type_check.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_base/tests/test_function_base.py to test_function_base.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_base/tests/test_index_tricks.py to test_index_tricks.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_base/tests/test_limits.py to test_limits.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_base/tests/test_matrix_base.py to test_matrix_base.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_base/tests/test_shape_base.py to test_shape_base.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_base/tests/test_type_check.py to test_type_check.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_distutils/__cvs_version__.py to __cvs_version__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_distutils/__init__.py to __init__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_distutils/core.py to core.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_distutils/dist.py to dist.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_distutils/extension.py to extension.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_distutils/lib2def.py to lib2def.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_distutils/line_endings.py to line_endings.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_distutils/mingw32_support.py to mingw32_support.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_distutils/misc_util.py to misc_util.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_distutils/scipy_distutils_version.py to scipy_distutils_version.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_distutils/setup_scipy_distutils.py to setup_scipy_distutils.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_distutils/system_info.py to system_info.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_distutils/command/__init__.py to __init__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_distutils/command/build.py to build.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_distutils/command/build_clib.py to build_clib.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_distutils/command/build_ext.py to build_ext.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_distutils/command/build_flib.py to build_flib.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_distutils/command/build_py.py to build_py.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_distutils/command/cpuinfo.py to cpuinfo.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_distutils/command/install.py to install.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_distutils/command/install_data.py to install_data.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_distutils/command/install_headers.py to install_headers.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_distutils/command/run_f2py.py to run_f2py.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_distutils/command/sdist.py to sdist.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_test/__cvs_version__.py to __cvs_version__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_test/__init__.py to __init__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_test/auto_test.py to auto_test.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_test/logging.py to logging.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_test/scipy_test_version.py to scipy_test_version.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_test/setup_scipy_test.py to setup_scipy_test.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/scipy_test/testing.py to testing.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/__init__.py to __init__.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/accelerate_tools.py to accelerate_tools.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/ast_tools.py to ast_tools.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/base_info.py to base_info.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/base_spec.py to base_spec.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/blitz_spec.py to blitz_spec.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/blitz_tools.py to blitz_tools.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/build_tools.py to build_tools.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/bytecodecompiler.py to bytecodecompiler.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/c_spec.py to c_spec.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/catalog.py to catalog.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/common_info.py to common_info.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/converters.py to converters.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/dumb_shelve.py to dumb_shelve.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/dumbdbm_patched.py to dumbdbm_patched.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/ext_tools.py to ext_tools.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/inline_tools.py to inline_tools.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/setup_weave.py to setup_weave.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/size_check.py to size_check.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/slice_handler.py to slice_handler.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/standard_array_spec.py to standard_array_spec.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/vtk_spec.py to vtk_spec.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/wx_spec.py to wx_spec.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/tests/scxx_timings.py to scxx_timings.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/tests/test_ast_tools.py to test_ast_tools.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/tests/test_blitz_tools.py to test_blitz_tools.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/tests/test_build_tools.py to test_build_tools.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/tests/test_c_spec.py to test_c_spec.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/tests/test_catalog.py to test_catalog.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/tests/test_ext_tools.py to test_ext_tools.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/tests/test_inline_tools.py to test_inline_tools.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/tests/test_scxx.py to test_scxx.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/tests/test_scxx_dict.py to test_scxx_dict.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/tests/test_scxx_object.py to test_scxx_object.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/tests/test_scxx_sequence.py to test_scxx_sequence.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/tests/test_size_check.py to test_size_check.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/tests/test_slice_handler.py to test_slice_handler.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/tests/test_standard_array_spec.py to test_standard_array_spec.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/tests/test_wx_spec.py to test_wx_spec.pyc skipping byte-compilation of /usr/lib/python2.2/site-packages/weave/tests/weave_test_utils.py to weave_test_utils.pyc running install_data hhhhhhhhhhhheeeeeeeeeeerrrrrrrrrrrreeeeeeeeeeeee not copying /incoming/scipy/scipy/scipy/plt/lena.dat (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/axes.gs (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/biglabel.gs (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/boxed.gs (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/boxed2.gs (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/framed.gs (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/im4x3.gs (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/im8x3.gs (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/image.gs (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/l_nobox.gs (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/nobox.gs (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/plot4x2.gs (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/slides.gs (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/vg.gs (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/vgbox.gs (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/work.gs (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/work2.gs (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/z_nobox.gs (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/z_work.gs (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/earth.gp (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/gray.gp (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/heat.gp (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/ncar.gp (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/rainbow.gp (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/redblue.gp (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/spectrum.gp (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/stern.gp (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/yarg.gp (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/ps.ps (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/pscom.ps (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/gist.help (output up-to-date) not copying /incoming/scipy/scipy/scipy/xplt/help.help (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/scxx/README.txt (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/scxx/dict.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/scxx/list.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/scxx/notes.txt (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/scxx/number.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/scxx/object.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/scxx/scxx.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/scxx/sequence.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/scxx/str.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/scxx/tuple.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/scxx/weave_imp.cpp (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/MAT-NOTE.gz (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/Makefile.am (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/Makefile.in (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/applics.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array-impl.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array-old.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/bench.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/bench.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/benchext.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/benchext.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/blitz.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/bzdebug.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/compiler.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/config-ICL.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/config-KCC.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/config-SC4.0.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/config-SGi.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/config-g++2.7.2.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/config-mwerks.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/config-xlC.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/config.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/etbase.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/extremum.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/funcs.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/indexexpr.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/limits-hack.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/listinit.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/matbops.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/matdiag.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/matexpr.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/matgen.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/mathf2.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/mathfunc.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/matltri.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/matref.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/matrix.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/matrix.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/matsymm.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/mattoep.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/matuops.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/matutri.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/memblock.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/memblock.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/minmax.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/mstruct.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/numinquire.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/numtrait.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/ops.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/prettyprint.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/promote-old.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/promote.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/rand-dunif.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/rand-mt.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/rand-normal.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/rand-tt800.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/rand-uniform.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/random.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/randref.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/range.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/reduce.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/shapecheck.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/tau.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/timer.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/tiny.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/tinymat.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/tinymatexpr.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/tinymatio.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/tinyvec-et.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/tinyvec.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/tinyvec.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/tinyvecio.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/tinyveciter.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/traversal.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/traversal.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/tuning.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/tvcross.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/tvecglobs.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/update.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vecaccum.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vecall.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vecany.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vecbfn.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vecbops.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/veccount.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vecdelta.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vecdot.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vecexpr.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vecexprwrap.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vecglobs.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vecglobs.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vecio.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/veciter.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vecmax.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vecmin.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vecnorm.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vecnorm1.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vecpick.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vecpick.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vecpickio.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vecpickiter.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vecsum.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vector-et.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vector.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vector.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vecuops.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vecwhere.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/vecwhere.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/wrap-climits.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/zero.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/zero.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/Makefile.am (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/Makefile.in (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/asexpr.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/bops.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/cartesian.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/cgsolve.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/complex.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/convolve.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/convolve.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/cycle.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/domain.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/et.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/eval.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/expr.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/fastiter.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/funcs.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/functorExpr.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/geometry.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/indirect.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/interlace.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/io.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/iter.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/map.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/methods.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/misc.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/multi.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/newbops.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/newet-macros.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/newet.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/ops.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/ops.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/reduce.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/reduce.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/resize.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/shape.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/slice.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/slicing.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/stencil-et.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/stencil.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/stencil.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/stencilops.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/stencils.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/stencils.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/storage.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/uops.cc (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/where.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/array/zip.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/meta/Makefile.am (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/meta/Makefile.in (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/meta/dot.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/meta/matassign.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/meta/matmat.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/meta/matvec.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/meta/metaprog.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/meta/product.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/meta/sum.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/blitz-20001213/blitz/meta/vecassign.h (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/swig/swigptr.c (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/doc/tutorial.html (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/examples/binary_search.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/examples/cast_copy_transpose.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/examples/dict_sort.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/examples/fibonacci.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/examples/functional.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/examples/increment_example.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/examples/md5_speed.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/examples/object.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/examples/print_example.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/examples/py_none.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/examples/ramp.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/examples/ramp2.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/examples/support_code_example.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/examples/tuple_return.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/examples/vq.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/examples/wx_example.py (output up-to-date) not copying /incoming/scipy/scipy/scipy/weave/examples/wx_speed.py (output up-to-date) From pearu at cens.ioc.ee Thu Nov 14 03:28:40 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Thu, 14 Nov 2002 10:28:40 +0200 (EET) Subject: [SciPy-user] scipy.test(level=1) fails: undefined symbol: clapack_sgesv In-Reply-To: <1037235554.10171.45.camel@localhost.localdomain> Message-ID: On 13 Nov 2002, rhawkin2 wrote: > Hello, > > Build from CVS went OK and scipy loads fine, but I got the following > error on the scipy.test(level=1) command: > > ====================================================================== > ERROR: check_add_function_ordered (test_catalog.test_catalog) > ---------------------------------------------------------------------- ... > ImportError: /usr/lib/python2.2/site-packages/scipy/linalg/clapack.so: > undefined symbol: clapack_sgesv ... > 5) f2py version: > f2py -v doesn't work. Unpacking the file F2PY-2-latest.tar.gz gave a > directory titled F2PY-2.23.190-1369. It should work. So, could you give more details here? Let me play a little detective here. You seem to have both Python 1.5.x and Python 2.2 installed. When you installed f2py, did you use Python 1.5.x? That is, the command python setup.py install ? You should install f2py using Python 2.2 instead. So, the correct installation command would be python2.2 setup.py install and getting the version of f2py reads then f2py2.2 -v > 8) Output to stdout of the SciPy installation command. There was no > stderr output. This output is not very useful as nothing is done here. Could you remove the build directory and send the stdout/stderr messages of the scipy building command (exactly this command that follows build/ removal, all subsequent building commands may lack some information)? You can send these messages directly to me as there is no need to float the scipy-users mailing list with these huge messages.. (but first resolve the f2py issue, of course). HTH, Pearu From pearu at cens.ioc.ee Thu Nov 14 03:47:11 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Thu, 14 Nov 2002 10:47:11 +0200 (EET) Subject: [SciPy-user] Mac OS X question: using Apple's vecLib In-Reply-To: <785AA750-F796-11D6-AFDA-00039311EA24@adelaide.edu.au> Message-ID: On Thu, 14 Nov 2002, Andrew Straw wrote: > It appears that Apple has given Mac OS X (10.2) a pre-installed LAPACK > in the vecLib framework. (See > http://developer.apple.com/techpubs/macosx/ReleaseNotes/vecLib.html ) > Apparently, this is a c version of the library (clapack). > > Is there any reason why scipy shouldn't use the clapack installed with > Mac OS X 10.2 rather than ATLAS/LAPACK installed from sources as > suggested in the scipy docs? The only reason is that ATLAS/LAPACK would be upto 10 times faster than CLAPACK. > If not, I may try to create a patch for scipy to use Apple's > pre-installed library. Though I would recommend getting ATLAS/LAPACK to work on Mac OS X as the patch for CLAPACK may not be trivial, mostly because "there is a difference in the definition of a two-dimensional array in Fortran and C". This requires that all 2-dimensional arguments in linalg/lapack.pyf must have intent(c) attribute. Adding these attributes is simple but detecting when this attribute is acctually needed, is probably not. Pearu From rhawkin2 at earthlink.net Thu Nov 14 09:30:46 2002 From: rhawkin2 at earthlink.net (Ray) Date: Thu, 14 Nov 2002 06:30:46 -0800 Subject: [SciPy-user] import scipy fails - cannot find liblapack.so.3 Message-ID: Hello, After a comparatively uneventful, though long (4 hours to build ATLAS on a 1.1 GHz Celeron), build from LAPACK and ATLAS tar-files and scipy CVS (Nov 12 update), I got the following message when I tried to import scipy: Python 2.2 (#1, Apr 12 2002, 15:29:57) [GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-109)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import scipy exceptions.ImportError: liblapack.so.3: cannot open shared object file: No such file or directory Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/site-packages/scipy/__init__.py", line 49, in ? import special, io, linalg, stats, fftpack File "/usr/lib/python2.2/site-packages/scipy/linalg/__init__.py", line 42, in ? from basic import * File "/usr/lib/python2.2/site-packages/scipy/linalg/basic.py", line 17, in ? import calc_lwork ImportError: liblapack.so.3: cannot open shared object file: No such file or directory >>> Would appreciate suggestions on how to fix this. Build details and some output are given below. Thanks, Ray 1) Build followed the INSTALL.txt in scipy CVS. lapack.tgz and atlas3.4.1.tar.gz were used. 2) python2.2 scipy_distutils/system_info.py atlas_info: FOUND: libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/local/lib/atlas'] blas_info: NOT AVAILABLE blas_src_info: NOT AVAILABLE dfftw_info: NOT AVAILABLE dfftw_threads_info: NOT AVAILABLE djbfft_info: NOT AVAILABLE fftw_info: NOT AVAILABLE fftw_threads_info: NOT AVAILABLE lapack_info: NOT AVAILABLE lapack_src_info: NOT AVAILABLE sfftw_info: NOT AVAILABLE sfftw_threads_info: NOT AVAILABLE x11_info: FOUND: libraries = ['X11'] library_dirs = ['/usr/X11R6/lib'] include_dirs = ['/usr/X11R6/include'] 3) ls -l /usr/local/lib/atlas/lib{atlas,cblas,f77blas,lapack}.* -rw-r--r-- 1 root root 5596040 Nov 13 10:40 /usr/local/lib/atlas/libatlas.a -rw-r--r-- 1 root root 292104 Nov 13 10:22 /usr/local/lib/atlas/libcblas.a -rw-r--r-- 1 root root 355802 Nov 13 10:41 /usr/local/lib/atlas/libf77blas.a -rw-r--r-- 1 root root 5835672 Nov 13 11:25 /usr/local/lib/atlas/liblapack.a From pearu at cens.ioc.ee Thu Nov 14 11:16:42 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Thu, 14 Nov 2002 18:16:42 +0200 (EET) Subject: [SciPy-user] import scipy fails - cannot find liblapack.so.3 In-Reply-To: Message-ID: On Thu, 14 Nov 2002, Ray wrote: > Hello, > > After a comparatively uneventful, though long (4 hours to build ATLAS on > a 1.1 GHz Celeron), Hmm, in PII 400MHz it takes much less time (about 45min) to build ATLAS (when I follow instructions in scipy/INSTALL.txt). > >>> import scipy > exceptions.ImportError: liblapack.so.3: cannot open shared object file: > No such file or directory > Would appreciate suggestions on how to fix this. Build details and some > output are given below. When importing lapack, it is seems that lapack is picked up from from /usr/lib, not from /usr/local/lib/atlas. If that is the case, then there are several ways to fix it: 1) Define LD_LIBRARY_PATH=/usr/local/lib/atlas 2) Put /usr/local/lib/atlas to /etc/ld.so.conf and run ldconfig You can use ldd to check the dependencies of shared libraries. E.g. ldd path/to/linalg/flapack.so etc. Pearu From falted at openlc.org Thu Nov 14 12:36:13 2002 From: falted at openlc.org (Francesc Alted) Date: Thu, 14 Nov 2002 18:36:13 +0100 Subject: [SciPy-user] Debian package(s)? In-Reply-To: <87of95795t.fsf@phantom.ecn.uiowa.edu> References: <20021028202754.GC6246@jowls.lairds.com> <20021101223428.GN7658@nyongwa.montreal.qc.ca> <87of95795t.fsf@phantom.ecn.uiowa.edu> Message-ID: <20021114173613.GA970@openlc.org> On Mon, Nov 04, 2002 at 07:32:14AM -0600, Joe Reinhardt wrote: > scipy depends on f2py, which is not in debian. Also, scipy won't > build with the atlas that is distributed with debian. Thus, this > makes it difficult for me to build without first rebuilding atlas. > And because of the atlas dependency, I don't think scipy can make it > into the main distribution until atlas is updated. (This situation > may have changed, since I haven't built scipy since July.) Yes, this has changed. Pearu solved this (at least in CVS) some weeks ago. > > My current (very old, but stable) snapshot (source and deb) is at > http://people.debian.org/~jmr. If someone has the time and energy to > update this for debian, please go ahead and take it over. > I have some practice making Debian packages. If anybody else can afford doing that, maybe I can. Cheers, -- Francesc Alted PGP KeyID: 0x61C8C11F Scientific aplications developer Public PGP key available: http://www.openlc.org/falted_at_openlc.asc Key fingerprint = 1518 38FE 3A3D 8BE8 24A0 3E5B 1328 32CC 61C8 C11F From pearu at cens.ioc.ee Thu Nov 14 12:46:37 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Thu, 14 Nov 2002 19:46:37 +0200 (EET) Subject: [SciPy-user] Debian package(s)? In-Reply-To: <20021114173613.GA970@openlc.org> Message-ID: On Thu, 14 Nov 2002, Francesc Alted wrote: > On Mon, Nov 04, 2002 at 07:32:14AM -0600, Joe Reinhardt wrote: > > > My current (very old, but stable) snapshot (source and deb) is at > > http://people.debian.org/~jmr. If someone has the time and energy to > > update this for debian, please go ahead and take it over. > > > > I have some practice making Debian packages. If anybody else can afford > doing that, maybe I can. That would be really great! Btw, are you also Debian developer? Thanks, Pearu From falted at openlc.org Thu Nov 14 13:10:33 2002 From: falted at openlc.org (Francesc Alted) Date: Thu, 14 Nov 2002 19:10:33 +0100 Subject: [SciPy-user] Debian package(s)? In-Reply-To: References: <20021114173613.GA970@openlc.org> Message-ID: <20021114181033.GB970@openlc.org> On Thu, Nov 14, 2002 at 07:46:37PM +0200, Pearu Peterson wrote: > Btw, are you also Debian developer? Actually no. I've tried to become a developer, but I had no luck to find a sponsor with time enough to guide me in that process. So, I propose to try to package scipy, say, during next week, and then send it to Joe Reinhardt for inspection and possible inclusion in Debian. Is that ok? -- Francesc Alted PGP KeyID: 0x61C8C11F Scientific aplications developer Public PGP key available: http://www.openlc.org/falted_at_openlc.asc Key fingerprint = 1518 38FE 3A3D 8BE8 24A0 3E5B 1328 32CC 61C8 C11F From steven.robbins at videotron.ca Thu Nov 14 13:53:11 2002 From: steven.robbins at videotron.ca (Steve M. Robbins) Date: Thu, 14 Nov 2002 13:53:11 -0500 Subject: [SciPy-user] Debian package(s)? In-Reply-To: <20021114181033.GB970@openlc.org> References: <20021114173613.GA970@openlc.org> <20021114181033.GB970@openlc.org> Message-ID: <20021114185311.GD5825@riemann.nyongwa.montreal.qc.ca> On Thu, Nov 14, 2002 at 07:10:33PM +0100, Francesc Alted wrote: > On Thu, Nov 14, 2002 at 07:46:37PM +0200, Pearu Peterson wrote: > > Btw, are you also Debian developer? > > Actually no. I've tried to become a developer, but I had no luck to find a > sponsor with time enough to guide me in that process. > > So, I propose to try to package scipy, say, during next week, and then send > it to Joe Reinhardt for inspection and possible inclusion in Debian. > > Is that ok? That sounds OK. Is it the consensus of the developers that CVS scipy is ready to be released? I'm also a Debian developer with strong interest in seeing f2py and scipy in debian. My time & interest in scipy waxes and wanes, however. I'm not heavily using scipy at the moment, which is why I didn't immediately volunteer to maintain the package for debian. I would be willing to help out a group packaging effort, though. -Steve From pearu at cens.ioc.ee Thu Nov 14 13:57:20 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Thu, 14 Nov 2002 20:57:20 +0200 (EET) Subject: [SciPy-user] Debian package(s)? In-Reply-To: <20021114181033.GB970@openlc.org> Message-ID: On Thu, 14 Nov 2002, Francesc Alted wrote: > On Thu, Nov 14, 2002 at 07:46:37PM +0200, Pearu Peterson wrote: > > Btw, are you also Debian developer? > > Actually no. I've tried to become a developer, but I had no luck to find a > sponsor with time enough to guide me in that process. > > So, I propose to try to package scipy, say, during next week, and then send > it to Joe Reinhardt for inspection and possible inclusion in Debian. > > Is that ok? I guess it depends on Joe. My experience with debian packages is based on only using Debian and sometimes installing few deb packages manually (with apt-get or dselect). However, I have noticed that few debianized packages either in their tar-ball or in their CVS contain debian/ directory containing necessary files for creating deb-files. I was hoping that we could maintain this directory inside scipy CVS repository so that debian packaging burden will be more distributed among developers. The same applies also for chaco and f2py. Pearu From pearu at cens.ioc.ee Thu Nov 14 14:06:21 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Thu, 14 Nov 2002 21:06:21 +0200 (EET) Subject: [SciPy-user] Debian package(s)? In-Reply-To: <20021114185311.GD5825@riemann.nyongwa.montreal.qc.ca> Message-ID: On Thu, 14 Nov 2002, Steve M. Robbins wrote: > Is it the consensus of the developers that CVS scipy is ready > to be released? The target date for SciPy 0.2 release is "before Christmas, 2002". I guess it takes some time to stabilize Debian packaging hooks, so there is no harm to start scipy debianization now. There will be only one large change in SciPy CVS before its 0.2 release. This is replacing fftpack with fftpack2 and I plan to apply this change by the end of this week (probably tomorrow). Otherwise SciPy CVS is quite stable with respect to Debian. > I'm also a Debian developer with strong interest in seeing f2py and > scipy in debian. My time & interest in scipy waxes and wanes, > however. I'm not heavily using scipy at the moment, which is why I > didn't immediately volunteer to maintain the package for debian. I > would be willing to help out a group packaging effort, though. Very good! Thanks, Pearu From falted at openlc.org Thu Nov 14 14:43:22 2002 From: falted at openlc.org (Francesc Alted) Date: Thu, 14 Nov 2002 20:43:22 +0100 Subject: [SciPy-user] Debian package(s)? In-Reply-To: References: <20021114181033.GB970@openlc.org> Message-ID: <20021114194322.GB5104@openlc.org> On Thu, Nov 14, 2002 at 08:57:20PM +0200, Pearu Peterson wrote: > However, I have noticed that few debianized packages either in their > tar-ball or in their CVS contain debian/ directory containing necessary > files for creating deb-files. I was hoping that we could maintain this > directory inside scipy CVS repository so that debian packaging burden will > be more distributed among developers. The same applies also for chaco and > f2py. That could be nice, but have in mind that it is always the Debian developer who has to decide the correct debian scripts. So, including a debian/ directory in distribution could be a bit of a mess if developer decides to change something. Maybe Steve can give his opinion on that. Anyway, if "before Christmas 2002" is a tentative date for releasing scipy 0.2, let's start working right now in debian package to be able to publish it at the same time than 0.2 announce (testing well the debian package would consume a few weeks). -- Francesc Alted PGP KeyID: 0x61C8C11F Scientific aplications developer Public PGP key available: http://www.openlc.org/falted_at_openlc.asc Key fingerprint = 1518 38FE 3A3D 8BE8 24A0 3E5B 1328 32CC 61C8 C11F From rhawkin2 at earthlink.net Thu Nov 14 15:49:29 2002 From: rhawkin2 at earthlink.net (Ray) Date: Thu, 14 Nov 2002 12:49:29 -0800 Subject: [SciPy-user] import scipy fails - cannot find liblapack.so.3 Message-ID: Thanks for the quick reply Pearu, Interesting that your ATLAS 'make install' runs so fast. I didn't time my attempt to build on an 800 MHz PentuimIII at home, but it also seemed like hours. I'll check that. Meanwhile, thanks for the suggestions, but I'm afraid I don't quite understand them: >If that is the case, then there are several ways to fix it: >1) Define > LD_LIBRARY_PATH=/usr/local/lib/atlas >2) Put /usr/local/lib/atlas to > /etc/ld.so.conf > and run ldconfig Is the definition done at the command line? What do you mean by "Put" in item 2. >You can use ldd to check the dependencies of >shared libraries. >E.g. > ldd path/to/linalg/flapack.so >etc. Looked in the /scipy/linalg file and only have the following flapack files: flapack.pyf flapack_user_routines.pyf Just for grins, I looked around on to see where liblapack.so.3 might be: I cannot find it anywhere on my system. Looking at RPM distros it seems like there should be some *.so files in addition to the *.a files. Sorry for the confusion. Ray From steven.robbins at videotron.ca Thu Nov 14 16:42:58 2002 From: steven.robbins at videotron.ca (Steve M. Robbins) Date: Thu, 14 Nov 2002 16:42:58 -0500 Subject: [SciPy-user] Debian package(s)? In-Reply-To: <20021114194322.GB5104@openlc.org> References: <20021114181033.GB970@openlc.org> <20021114194322.GB5104@openlc.org> Message-ID: <20021114214258.GE5825@riemann.nyongwa.montreal.qc.ca> On Thu, Nov 14, 2002 at 08:43:22PM +0100, Francesc Alted wrote: > On Thu, Nov 14, 2002 at 08:57:20PM +0200, Pearu Peterson wrote: > > However, I have noticed that few debianized packages either in their > > tar-ball or in their CVS contain debian/ directory containing necessary > > files for creating deb-files. I was hoping that we could maintain this > > directory inside scipy CVS repository so that debian packaging burden will > > be more distributed among developers. The same applies also for chaco and > > f2py. > > That could be nice, but have in mind that it is always the Debian developer > who has to decide the correct debian scripts. So, including a debian/ > directory in distribution could be a bit of a mess if developer decides to > change something. Maybe Steve can give his opinion on that. Having the debian directory in upstream CVS can be useful for those who don't want to use packages from the debian servers. However, as Francesc alluded to, the upstream debian directory could diverge from what appears in the "official" debian package, which reduces its value, somewhat. There are a variety of reasons for the divergence. Often, especially when the debian maintainer is not one of the upstream developers, it just bit-rots. Sometimes (rarely) there is outright disagreement about what to put in there, e.g. for the dependencies. Having debian in the upstream CVS works best when the debian maintainer has write access to it. I do this for one package I maintain. When this issue comes up on the debian mailing lists, the concensus opinion is that it is not usually helpful, and sometimes it is a nuisance. > Anyway, if "before Christmas 2002" is a tentative date for releasing scipy > 0.2, let's start working right now in debian package to be able to publish > it at the same time than 0.2 announce (testing well the debian package would > consume a few weeks). Sounds good. Don't forget f2py. Scipy will need to build-depend on it, so it needs to be packaged first. We had a discussion about f2py, scipy, and "scipy_distutils" back in August, starting at: http://www.scipy.org/site_content/mailman?fn=scipy-dev/2002-August/001109.html Unless things have changed recently, the problem is that both f2py and scipy want to install scipy_distutils. I think the suggestion was that f2py sources should build the scipy_distutils package, and that scipy should not. This might need some fiddling in debian/rules to prevent scipy from installing it. I'm a little muddled now as to when and how the scipy_distutils gets used. I think that f2py uses those files at runtime. So they have to be installed when building scipy (i.e. when running f2py). But I recall someone claiming that scipy doesn't need the distutils at runtime. (?) -Steve From pearu at cens.ioc.ee Thu Nov 14 16:44:44 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Thu, 14 Nov 2002 23:44:44 +0200 (EET) Subject: [SciPy-user] import scipy fails - cannot find liblapack.so.3 In-Reply-To: Message-ID: On Thu, 14 Nov 2002, Ray wrote: > Thanks for the quick reply Pearu, > > Interesting that your ATLAS 'make install' runs so fast. I didn't time my > attempt to build on an 800 MHz PentuimIII at home, but it also seemed like > hours. I'll check that. > > Meanwhile, thanks for the suggestions, but I'm afraid I don't quite understand > them: > > >If that is the case, then there are several ways to fix it: > >1) Define > > LD_LIBRARY_PATH=/usr/local/lib/atlas This is the approach that I would use as it is more flexible for playing around with shared libraries. Anyway, what I meant here was that you can add the following line LD_LIBRARY_PATH=/usr/local/lib/atlas:$LD_LIBRARY_PATH to .bashrc file (or some other dot-file that your favorite shell uses). This will ensure that shared libraries are searched first from /usr/local/lib/atlas and then from other locations. > >2) Put /usr/local/lib/atlas to > > /etc/ld.so.conf > > and run ldconfig > > Is the definition done at the command line? > What do you mean by "Put" in item 2. I meant Insert. This is another way (may be more appropiate one than 1. in your case) to define the shared library search path. ldconfig should be run as root, of course. See man pages for more information. > >You can use ldd to check the dependencies of >shared libraries. > >E.g. > > ldd path/to/linalg/flapack.so > >etc. > > Looked in the /scipy/linalg file and only have the following flapack files: > > flapack.pyf flapack_user_routines.pyf You should find flapack.so from build/lib-????/scipy/linalg directory. > Just for grins, I looked around on to see where liblapack.so.3 might be: I > cannot find it anywhere on my system. Looking at RPM distros it seems like > there should be some *.so files in addition to the *.a files. > > Sorry for the confusion. No problem. Actually suggestion for adding /usr/local/lib/atlas to the shared library search path still holds. You dont need lapack or blas RPMS if you have already compiled ATLAS with complete LAPACK. Regards, Pearu From pearu at cens.ioc.ee Thu Nov 14 18:13:24 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Fri, 15 Nov 2002 01:13:24 +0200 (EET) Subject: [SciPy-user] Debian package(s) In-Reply-To: <20021114214258.GE5825@riemann.nyongwa.montreal.qc.ca> Message-ID: On Thu, 14 Nov 2002, Steve M. Robbins wrote: > On Thu, Nov 14, 2002 at 08:43:22PM +0100, Francesc Alted wrote: > > That could be nice, but have in mind that it is always the Debian developer > > who has to decide the correct debian scripts. So, including a debian/ > > directory in distribution could be a bit of a mess if developer decides to > > change something. Maybe Steve can give his opinion on that. > > Having the debian directory in upstream CVS can be useful for those > who don't want to use packages from the debian servers. > > However, as Francesc alluded to, the upstream debian directory could > diverge from what appears in the "official" debian package, which > reduces its value, somewhat. There are a variety of reasons for the > divergence. Often, especially when the debian maintainer is not one > of the upstream developers, it just bit-rots. This "bit-rots" is exactly why I thought why it would be preferable if debian/ directory would be under the control of SciPy CVS. I think that SciPy will change in future quite a bit so that debian/ scripts written today will probably need active maintainence also in future. If someone is willing to do that, then either way (having debian/ in Scipy CVS or not) is fine with me. > > Anyway, if "before Christmas 2002" is a tentative date for releasing scipy > > 0.2, let's start working right now in debian package to be able to publish > > it at the same time than 0.2 announce (testing well the debian package would > > consume a few weeks). > > Sounds good. Don't forget f2py. Scipy will need to build-depend on > it, so it needs to be packaged first. > > We had a discussion about f2py, scipy, and "scipy_distutils" back > in August, starting at: > http://www.scipy.org/site_content/mailman?fn=scipy-dev/2002-August/001109.html > > Unless things have changed recently, the problem is that both f2py and > scipy want to install scipy_distutils. I think the suggestion was > that f2py sources should build the scipy_distutils package, and that > scipy should not. This might need some fiddling in debian/rules to > prevent scipy from installing it. > > I'm a little muddled now as to when and how the scipy_distutils gets > used. I think that f2py uses those files at runtime. So they have to > be installed when building scipy (i.e. when running f2py). But I > recall someone claiming that scipy doesn't need the distutils at > runtime. (?) Here follows some hard facts that set few restrictions for packaging the related tools: 1) f2py install does not require scipy_distutils. f2py ships and installs scipy_distutils only for the convinience of f2py users (that may not be scipy users). 2) Usage of f2py requires scipy_distutils installed. 3) scipy install requires f2py and also scipy_distutils, but the later needs not to be installed as the scipy setup.py script finds it in the current directory, and also f2py would use that. 4) Usage of scipy does not require scipy_distutils nor f2py, at least not currently. It is difficult to say what would be the most appropiate way to debianize scipy and tools without trying something out first. Anyway, may I suggest the following policy as a starting point: 1) scipy_distutils build dependencies: python-dev testing dependencies: scipy_test (not implemented, will it ever be?) runtime dependencies: python-dev 2) f2py2e build dependencies: python-dev testing dependecies: scipy_test, scipy_distutils, Numeric runtime dependencies: scipy_distutils, Numeric 3) scipy build dependencies: scipy_distutils, f2py2e, atlas2-headers, atlas2-base atlas2-base-dev testing dependecies: scipy_test, Numeric, atlas2-base runtime dependencies: scipy_base, Numeric, atlas2-base 4) scipy_base build dependencies: scipy_distutils, Numeric testing dependecies: scipy_test, Numeric runtime dependencies: python, Numeric 5) scipy_test build dependencies: scipy_distutils testing dependecies: python, Numeric runtime dependencies: python, Numeric Notes: * There is a possible chicken-egg problem with scipy_test and scipy_distutils. One way to solve it by introducing some super-package that contains both scipy_test and scipy_distutils. * scipy_base is for those who wish to install only few modules from scipy separately. However, as a first instance, scipy_base could be installed under scipy, or with scipy_test and scipy_distutils in this super-package. * There are also weave and chaco packages. Currently weave is installed both as a separate module and as a submodule of scipy. I would suggest dropping the latter. Eric, what do you think? And I am not sure how far chaco is. Is it anywhere ready to be released with scipy 0.2? * "Testing dependencies" means that it should work both when the package is installed and imported to python, or not installed but run inside the source directory. HTH, Pearu From andrew.straw at adelaide.edu.au Thu Nov 14 20:16:04 2002 From: andrew.straw at adelaide.edu.au (Andrew Straw) Date: Fri, 15 Nov 2002 11:46:04 +1030 Subject: [SciPy-user] Mac OS X question: using Apple's vecLib In-Reply-To: Message-ID: On Thursday, November 14, 2002, at 07:17 PM, Pearu Peterson wrote: > On Thu, 14 Nov 2002, Andrew Straw wrote: > >> It appears that Apple has given Mac OS X (10.2) a pre-installed LAPACK >> in the vecLib framework. (See >> http://developer.apple.com/techpubs/macosx/ReleaseNotes/vecLib.html ) >> Apparently, this is a c version of the library (clapack). >> >> Is there any reason why scipy shouldn't use the clapack installed with >> Mac OS X 10.2 rather than ATLAS/LAPACK installed from sources as >> suggested in the scipy docs? > > The only reason is that ATLAS/LAPACK would be upto 10 times faster than > CLAPACK. My impression (although it's not stated explicitly from the webpage I posted above) was that Apple's CLAPACK in vecLib would be optimized for the platform, although perhaps not to the level of ATLAS. >> If not, I may try to create a patch for scipy to use Apple's >> pre-installed library. > > Though I would recommend getting ATLAS/LAPACK to work on Mac OS X as > the patch for CLAPACK may not be trivial, mostly because "there is a > difference in the definition of a two-dimensional array in Fortran and > C". This requires that all 2-dimensional arguments in linalg/lapack.pyf > must have intent(c) attribute. Adding these attributes is simple but > detecting when this attribute is acctually needed, is probably not. That looks like the killer for me... Cheers! Andrew From Ralf_Ahlbrink at web.de Fri Nov 15 09:06:22 2002 From: Ralf_Ahlbrink at web.de (RA) Date: Fri, 15 Nov 2002 15:06:22 +0100 Subject: [SciPy-user] Debian package(s)? -- and RPM Message-ID: <200211151506.22502.Ralf_Ahlbrink@web.de> Hi! I've just read the ml archive, because I want to contribute some packages (scipy and f2py), both RPM (Mdk 9.0) and DEB (woody). I've got some experience with RPM and I'll also submit these packages to cooker (just updated yesterday, with custom atlas ). For debian, well, the debs evolved from joe r. packages. They were updated a few weeks ago (build with atlas-base). I hope, that they can be at least a starting point. So, how could I upload the stuff? Ralf. From Ralf_Ahlbrink at web.de Fri Nov 15 09:26:45 2002 From: Ralf_Ahlbrink at web.de (RA) Date: Fri, 15 Nov 2002 15:26:45 +0100 Subject: [SciPy-user] scipy.test output Message-ID: <200211151526.45075.Ralf_Ahlbrink@web.de> I want to analyze and store the output of scipy.test(). But it's a mixture of stdout and stderr, and the output after redirection via shell (2>&1) is in the wrong order. I also tried 'import sys; sys.stderr = sys.stdout' before 'import scipy; scipy.test()" without success. Any hint? From pearu at cens.ioc.ee Fri Nov 15 09:51:37 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Fri, 15 Nov 2002 16:51:37 +0200 (EET) Subject: [SciPy-user] scipy.test output In-Reply-To: <200211151526.45075.Ralf_Ahlbrink@web.de> Message-ID: On Fri, 15 Nov 2002, RA wrote: > I want to analyze and store the output of scipy.test(). > But it's a mixture of stdout and stderr, and the output after redirection via > shell (2>&1) is in the wrong order. > I also tried 'import sys; sys.stderr = sys.stdout' before 'import scipy; > scipy.test()" without success. > Any hint? sys.stderr = sys.stdout would not work because some of the messages may come from Fortran that are impossible to catch from Python. Use script to get the desired result: $ script scipy_test.log $ python -c 'import scipy;scipy.test(1)' $ ^D $ less scipy_test.log Pearu From Ralf_Ahlbrink at web.de Fri Nov 15 11:01:32 2002 From: Ralf_Ahlbrink at web.de (RA) Date: Fri, 15 Nov 2002 17:01:32 +0100 Subject: [SciPy-user] scipy.test output In-Reply-To: References: Message-ID: <200211151701.32876.Ralf_Ahlbrink@web.de> On Freitag, 15. November 2002 15:51:15, Pearu Peterson wrote: > On Fri, 15 Nov 2002, RA wrote: > > I want to analyze and store the output of scipy.test(). > > But it's a mixture of stdout and stderr, and the output after redirection > > via shell (2>&1) is in the wrong order. > > I also tried 'import sys; sys.stderr = sys.stdout' before 'import scipy; > > scipy.test()" without success. > > Any hint? > > sys.stderr = sys.stdout would not work because some of the messages > may come from Fortran that are impossible to catch from Python. bummer! > > Use script to get the desired result: > > $ script scipy_test.log > $ python -c 'import scipy;scipy.test(1)' > $ ^D > $ less scipy_test.log > > Pearu It's not straight forward. But it works. Thanks, Ralf. > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From eric at enthought.com Fri Nov 15 12:27:14 2002 From: eric at enthought.com (eric jones) Date: Fri, 15 Nov 2002 11:27:14 -0600 Subject: [SciPy-user] Debian package(s)? In-Reply-To: <20021114214258.GE5825@riemann.nyongwa.montreal.qc.ca> Message-ID: <005001c28ccc$3ff17140$8901a8c0@ERICDESKTOP> > On Thu, Nov 14, 2002 at 08:43:22PM +0100, Francesc Alted wrote: > > On Thu, Nov 14, 2002 at 08:57:20PM +0200, Pearu Peterson wrote: > > > However, I have noticed that few debianized packages either in their > > > tar-ball or in their CVS contain debian/ directory containing > necessary > > > files for creating deb-files. I was hoping that we could maintain this > > > directory inside scipy CVS repository so that debian packaging burden > will > > > be more distributed among developers. The same applies also for chaco > and > > > f2py. > > > > That could be nice, but have in mind that it is always the Debian > developer > > who has to decide the correct debian scripts. So, including a debian/ > > directory in distribution could be a bit of a mess if developer decides > to > > change something. Maybe Steve can give his opinion on that. > > Having the debian directory in upstream CVS can be useful for those > who don't want to use packages from the debian servers. > > However, as Francesc alluded to, the upstream debian directory could > diverge from what appears in the "official" debian package, which > reduces its value, somewhat. There are a variety of reasons for the > divergence. Often, especially when the debian maintainer is not one > of the upstream developers, it just bit-rots. Sometimes (rarely) > there is outright disagreement about what to put in there, e.g. for > the dependencies. > > Having debian in the upstream CVS works best when the debian > maintainer has write access to it. I do this for one package I > maintain. When this issue comes up on the debian mailing lists, the > concensus opinion is that it is not usually helpful, and sometimes it > is a nuisance. > > > > Anyway, if "before Christmas 2002" is a tentative date for releasing > scipy > > 0.2, let's start working right now in debian package to be able to > publish > > it at the same time than 0.2 announce (testing well the debian package > would > > consume a few weeks). > > Sounds good. Don't forget f2py. Scipy will need to build-depend on > it, so it needs to be packaged first. > > We had a discussion about f2py, scipy, and "scipy_distutils" back > in August, starting at: > http://www.scipy.org/site_content/mailman?fn=scipy-dev/2002- > August/001109.html > > Unless things have changed recently, the problem is that both f2py and > scipy want to install scipy_distutils. I think the suggestion was > that f2py sources should build the scipy_distutils package, and that > scipy should not. This might need some fiddling in debian/rules to > prevent scipy from installing it. > > I'm a little muddled now as to when and how the scipy_distutils gets > used. I think that f2py uses those files at runtime. So they have to > be installed when building scipy (i.e. when running f2py). But I > recall someone claiming that scipy doesn't need the distutils at > runtime. (?) scipy_distutils gets used by other things now besides scipy such as weave and I think Chaco is using it. It gets bundled automatically by weave's setup.py into the weave distribution. Rolling scipy_distutils into f2py will make f2py a dependency for weave -- not desirable. But then neither is the current setup. We have three low level packages now: scipy_base, scipy_distutils, and scipy_test. Gui_thread might fall into this group also. A lot of other packages will depend on one or more of these -- f2py, scipy, weave, chaco, etc. It sounding like we really need to bundle the first three (or four) packages into a separate package (scipy_core?) to ease the issues with debian packages, rpm's etc. scipy_core could then be listed as a dependency by the other packages. The only thing that makes me hesitate about this is that f2py is currently pure python. If we make it depend on scipy_core, the scipy_base module does have some C modules in it that people will have to build. Since f2py really doesn't need any part of scipy_base, this dependency is a result of how things are packaged. To get around this, we could package scipy_distutils and scipy_test together and leave scipy_base in the scipy package. Then f2py would only have pure python modules as dependencies. Pearu (and others), is this a big win for you, or would you rather bundle all of them together as a single file? I'm thinking the windows package will continue to be a single click-install bundle with everything in it. eric From pearu at cens.ioc.ee Fri Nov 15 13:13:49 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Fri, 15 Nov 2002 20:13:49 +0200 (EET) Subject: [SciPy-user] Debian package(s)? In-Reply-To: <005001c28ccc$3ff17140$8901a8c0@ERICDESKTOP> Message-ID: On Fri, 15 Nov 2002, eric jones wrote: > > > > I'm a little muddled now as to when and how the scipy_distutils gets > > used. I think that f2py uses those files at runtime. So they have to > > be installed when building scipy (i.e. when running f2py). But I > > recall someone claiming that scipy doesn't need the distutils at > > runtime. (?) > > scipy_distutils gets used by other things now besides scipy such as > weave and I think Chaco is using it. It gets bundled automatically by > weave's setup.py into the weave distribution. Rolling scipy_distutils > into f2py will make f2py a dependency for weave -- not desirable. But > then neither is the current setup. I agree with both conclusions. > We have three low level packages now: scipy_base, scipy_distutils, and > scipy_test. Gui_thread might fall into this group also. A lot of other > packages will depend on one or more of these -- f2py, scipy, weave, > chaco, etc. It sounding like we really need to bundle the first three > (or four) packages into a separate package (scipy_core?) to ease the > issues with debian packages, rpm's etc. scipy_core could then be listed > as a dependency by the other packages. > > The only thing that makes me hesitate about this is that f2py is > currently pure python. If we make it depend on scipy_core, the > scipy_base module does have some C modules in it that people will have > to build. Since f2py really doesn't need any part of scipy_base, this > dependency is a result of how things are packaged. To get around this, > we could package scipy_distutils and scipy_test together and leave > scipy_base in the scipy package. Then f2py would only have pure python > modules as dependencies. Pearu (and others), is this a big win for you, > or would you rather bundle all of them together as a single file? I would like to keep f2py a separate package for purely f2py users (the number of such users is not small). So, I like the first option (that also more or less coincides with the proposal in my last mail). To summarize explicitly: 1) scipy_distutils and scipy_test are bundled to scipy_core 2) scipy_base stays in scipy (at least for the time being) 3) The following packages are stand-alone and all depend on scipy_core: scipy, weave, f2py2e, chaco, etc. 4) scipy depends also on weave, f2py2e, chaco(?in future), etc. > I'm thinking the windows package will continue to be a single > click-install bundle with everything in it. Yes. Everything above applies only for non-windows systems. Pearu From eric at enthought.com Fri Nov 15 13:33:07 2002 From: eric at enthought.com (eric jones) Date: Fri, 15 Nov 2002 12:33:07 -0600 Subject: [SciPy-user] Debian package(s) In-Reply-To: Message-ID: <005101c28cd5$7432bc80$8901a8c0@ERICDESKTOP> > On Thu, 14 Nov 2002, Steve M. Robbins wrote: > > > On Thu, Nov 14, 2002 at 08:43:22PM +0100, Francesc Alted wrote: > > > That could be nice, but have in mind that it is always the Debian > developer > > > who has to decide the correct debian scripts. So, including a debian/ > > > directory in distribution could be a bit of a mess if developer > decides to > > > change something. Maybe Steve can give his opinion on that. > > > > Having the debian directory in upstream CVS can be useful for those > > who don't want to use packages from the debian servers. > > > > However, as Francesc alluded to, the upstream debian directory could > > diverge from what appears in the "official" debian package, which > > reduces its value, somewhat. There are a variety of reasons for the > > divergence. Often, especially when the debian maintainer is not one > > of the upstream developers, it just bit-rots. > > This "bit-rots" is exactly why I thought why it would be preferable if > debian/ directory would be under the control of SciPy CVS. > I think that SciPy will change in future quite a bit so that debian/ > scripts written today will probably need active maintainence also in > future. If someone is willing to do that, then either way (having > debian/ in Scipy CVS or not) is fine with me. > > > > Anyway, if "before Christmas 2002" is a tentative date for releasing > scipy > > > 0.2, let's start working right now in debian package to be able to > publish > > > it at the same time than 0.2 announce (testing well the debian package > would > > > consume a few weeks). > > > > Sounds good. Don't forget f2py. Scipy will need to build-depend on > > it, so it needs to be packaged first. > > > > We had a discussion about f2py, scipy, and "scipy_distutils" back > > in August, starting at: > > http://www.scipy.org/site_content/mailman?fn=scipy-dev/2002- > August/001109.html > > > > Unless things have changed recently, the problem is that both f2py and > > scipy want to install scipy_distutils. I think the suggestion was > > that f2py sources should build the scipy_distutils package, and that > > scipy should not. This might need some fiddling in debian/rules to > > prevent scipy from installing it. > > > > I'm a little muddled now as to when and how the scipy_distutils gets > > used. I think that f2py uses those files at runtime. So they have to > > be installed when building scipy (i.e. when running f2py). But I > > recall someone claiming that scipy doesn't need the distutils at > > runtime. (?) > > Here follows some hard facts that set few restrictions for packaging the > related tools: > > 1) f2py install does not require scipy_distutils. f2py ships and installs > scipy_distutils only for the convinience of f2py users (that may not be > scipy users). > 2) Usage of f2py requires scipy_distutils installed. > 3) scipy install requires f2py and also scipy_distutils, but the later > needs not to be installed as the scipy setup.py script finds it in the > current directory, and also f2py would use that. > 4) Usage of scipy does not require scipy_distutils nor f2py, at least not > currently. > > It is difficult to say what would be the most appropiate way to debianize > scipy and tools without trying something out first. Anyway, may I suggest > the following policy as a starting point: > > 1) scipy_distutils > build dependencies: python-dev > testing dependencies: scipy_test (not implemented, will it ever be?) Not sure. I'm inclined not to spend a huge amount of time here, and instead write unit tests for "scipy_distutils, the next generation." At some point in the near future, we need to discuss whether to re-architect distutils and scipy_distutils. I have some ideas along these lines and some folks at LLNL that I've talked with do also. It would be a large effort, but SCons might handle a large portion of the effort. All that to say, I doubt I will spend any time on tests for it... > runtime dependencies: python-dev > > 2) f2py2e > build dependencies: python-dev > testing dependecies: scipy_test, scipy_distutils, Numeric > runtime dependencies: scipy_distutils, Numeric > > 3) scipy > build dependencies: scipy_distutils, f2py2e, atlas2-headers, atlas2-base > atlas2-base-dev > testing dependecies: scipy_test, Numeric, atlas2-base > runtime dependencies: scipy_base, Numeric, atlas2-base > > 4) scipy_base > build dependencies: scipy_distutils, Numeric > testing dependecies: scipy_test, Numeric > runtime dependencies: python, Numeric > > 5) scipy_test > build dependencies: scipy_distutils > testing dependecies: python, Numeric > runtime dependencies: python, Numeric > > Notes: > * There is a possible chicken-egg problem with scipy_test and > scipy_distutils. One way to solve it by introducing some > super-package that contains both scipy_test and scipy_distutils. That sounds fine. In reality, scipy_test has a single module (testing.py) that needs to stay in the distribution. We made this a package early on to work around distutils quirks that made it difficult to send it out as its own module. The other main file (auto_test.py) in scipy_test is not actively developed, so it could be stripped out if we wanted to. And logging.py was included because auto_test.py depends on it. It will be included in the standard library in Python 2.3. hmm. Then again, scipy_test may grow in the future, and having it as a package makes this much easier. So, we're back to having scipy_test and scipy_distutils as a "super package." > * scipy_base is for those who wish to install only few modules from scipy > separately. However, as a first instance, scipy_base could be > installed under scipy, or with scipy_test and scipy_distutils in this > super-package. It "feels" like scipy_base should be bundled with scipy_test and scipy_distutils to me. As I mentioned in a previous mail, this makes f2py rely on an extension module. If this doesn't sound like a big deal, I say we do this. > * There are also weave and chaco packages. Currently weave is installed > both as a separate module and as a submodule of scipy. I would suggest > dropping the latter. Eric, what do you think? I have already done that in my code. So yes weave should only be installed as a stand-alone package. SciPy's setup.py should be changed to install it as stand-alone instead of as a submodule. > And I am not sure how far chaco is. Is it anywhere ready to be released > with scipy 0.2? I think this is possible. It currently has a whole host of dependencies, wxPython, TkInter, PyOpenGL, ReportLab, Numeric, weave, and maybe others. I'm thinking the weave dependency will disappear in the future. Also, if you only want to use it with wxPython, then you don't need PyOpenGL, TkInter or ReportLab. So, the dependencies are not hard and fast. I don't think the rpm and debian packages account for this sort of thing. After a little more thought, lets just try to get SciPy-0.2 out on its own. Chaco is looking good, but there are installation issues, etc. to work out, and I wouldn't want to hold up SciPy because of them. We might shoot for integrating them in the 0.3 release, but it also might be worth keeping Chaco separate. It will be useful, for example, to someone who just wants to run a graph generating web server. It be easier for these folks to install Chaco alone instead of having to install SciPy ( with ATLAS, etc.) > * "Testing dependencies" means that it should work both when the package > is installed and imported to python, or not installed but run inside the > source directory. eric From eric at enthought.com Fri Nov 15 13:37:48 2002 From: eric at enthought.com (eric jones) Date: Fri, 15 Nov 2002 12:37:48 -0600 Subject: [SciPy-user] Debian package(s)? In-Reply-To: Message-ID: <006001c28cd6$1bf77f50$8901a8c0@ERICDESKTOP> > -----Original Message----- > From: scipy-user-admin at scipy.net [mailto:scipy-user-admin at scipy.net] On > Behalf Of Pearu Peterson > Sent: Friday, November 15, 2002 12:14 PM > To: scipy-user at scipy.net > Subject: RE: [SciPy-user] Debian package(s)? > > On Fri, 15 Nov 2002, eric jones wrote: > > > > > > > I'm a little muddled now as to when and how the scipy_distutils gets > > > used. I think that f2py uses those files at runtime. So they have to > > > be installed when building scipy (i.e. when running f2py). But I > > > recall someone claiming that scipy doesn't need the distutils at > > > runtime. (?) > > > > scipy_distutils gets used by other things now besides scipy such as > > weave and I think Chaco is using it. It gets bundled automatically by > > weave's setup.py into the weave distribution. Rolling scipy_distutils > > into f2py will make f2py a dependency for weave -- not desirable. But > > then neither is the current setup. > > I agree with both conclusions. > > > We have three low level packages now: scipy_base, scipy_distutils, and > > scipy_test. Gui_thread might fall into this group also. A lot of other > > packages will depend on one or more of these -- f2py, scipy, weave, > > chaco, etc. It sounding like we really need to bundle the first three > > (or four) packages into a separate package (scipy_core?) to ease the > > issues with debian packages, rpm's etc. scipy_core could then be listed > > as a dependency by the other packages. > > > > The only thing that makes me hesitate about this is that f2py is > > currently pure python. If we make it depend on scipy_core, the > > scipy_base module does have some C modules in it that people will have > > to build. Since f2py really doesn't need any part of scipy_base, this > > dependency is a result of how things are packaged. To get around this, > > we could package scipy_distutils and scipy_test together and leave > > scipy_base in the scipy package. Then f2py would only have pure python > > modules as dependencies. Pearu (and others), is this a big win for you, > > or would you rather bundle all of them together as a single file? > > I would like to keep f2py a separate package for purely f2py users (the > number of such users is not small). > > So, I like the first option (that also more or less coincides with the > proposal in my last mail). To summarize explicitly: > > 1) scipy_distutils and scipy_test are bundled to scipy_core > 2) scipy_base stays in scipy (at least for the time being) > 3) The following packages are stand-alone and all depend on scipy_core: > scipy, weave, f2py2e, chaco, etc. > 4) scipy depends also on weave, f2py2e, chaco(?in future), etc. This sounds good. This really doesn't change the CVS tree much does it? We just need to change the way distributions are created. Eric From fonnesbeck at linuxmail.org Fri Nov 15 14:37:02 2002 From: fonnesbeck at linuxmail.org (Christopher Fonnesbeck) Date: Sat, 16 Nov 2002 03:37:02 +0800 Subject: [SciPy-user] Weave on W2K problems Message-ID: <20021115193702.23856.qmail@linuxmail.org> I am trying to set up weave/scipy on a very fast machine, unfortunately running W2K, rather than *NIX, and am having a couple of problems with weave. First, although the scipy binary puts its weave components in $PYTHONHOME\Lib\site-packages as I would expect, the full weave binary puts its stuff in $PYTHONHOME. Second, though I have the cygwin gcc compiler (with g++ also) installed and listed first on my user path, I get the following error claiming g++ cannot be found. ====================================================================== ERROR: result[1:-1,1:-1] = (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1] ---------------------------------------------------------------------- Traceback (most recent call last): File "T:\Python22\Lib\site-packages\weave\tests\test_blitz_tools.py", line 150, in check_5point_avg_2d self.generic_2d(expr) File "T:\Python22\Lib\site-packages\weave\tests\test_blitz_tools.py", line 124, in generic_2d mod_location) File "T:\Python22\Lib\site-packages\weave\tests\test_blitz_tools.py", line 80, in generic_test blitz_tools.blitz(expr,arg_dict,{},verbose=0) #, File "T:\Python22\Lib\site-packages\weave\blitz_tools.py", line 72, in blitz type_converters = converters.blitz, File "T:\Python22\Lib\site-packages\weave\inline_tools.py", line 439, in compile_function verbose=verbose, **kw) File "T:\Python22\Lib\site-packages\weave\ext_tools.py", line 332, in compile verbose = verbose, **kw) File "T:\Python22\Lib\site-packages\weave\build_tools.py", line 221, in build_extension setup(name = module_name, ext_modules = [ext],verbose=verb) File "T:\Python22\lib\distutils\core.py", line 157, in setup raise SystemExit, "error: " + str(msg) CompileError: error: command 'g++' failed: No such file or directory ---------------------------------------------------------------------- Ran 184 tests in 250.797s FAILED (errors=1) I need this stuff to work in order to make my dynamic optimizations run faster, so any assistance is most welcome. Thanks, Chris Fonnesbeck -- ______________________________________________ http://www.linuxmail.org/ Now with POP3/IMAP access for only US$19.95/yr Powered by Outblaze From eric at enthought.com Fri Nov 15 17:31:29 2002 From: eric at enthought.com (eric jones) Date: Fri, 15 Nov 2002 16:31:29 -0600 Subject: [SciPy-user] Weave on W2K problems In-Reply-To: <20021115193702.23856.qmail@linuxmail.org> Message-ID: <008201c28cf6$c0afdef0$8901a8c0@ERICDESKTOP> Hey Chris, > I am trying to set up weave/scipy on a very fast machine, unfortunately > running W2K, rather than *NIX, and am having a couple of problems with > weave. First, although the scipy binary puts its weave components in > $PYTHONHOME\Lib\site-packages as I would expect, the full weave binary > puts its stuff in $PYTHONHOME. This may be because the standalone version was built with 2.1.3 and I believe it defaulted to putting things in $PYTHONHOME on windows distributions. This was corrected in Python2.2 (which is used to build SciPy). > Second, though I have the cygwin gcc > compiler (with g++ also) installed and listed first on my user path, I get > the following error claiming g++ cannot be found. > > ====================================================================== > ERROR: result[1:-1,1:-1] = (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1] > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "T:\Python22\Lib\site-packages\weave\tests\test_blitz_tools.py", > line 150, in check_5point_avg_2d > self.generic_2d(expr) > File "T:\Python22\Lib\site-packages\weave\tests\test_blitz_tools.py", > line 124, in generic_2d > mod_location) > File "T:\Python22\Lib\site-packages\weave\tests\test_blitz_tools.py", > line 80, in generic_test > blitz_tools.blitz(expr,arg_dict,{},verbose=0) #, > File "T:\Python22\Lib\site-packages\weave\blitz_tools.py", line 72, in > blitz > type_converters = converters.blitz, > File "T:\Python22\Lib\site-packages\weave\inline_tools.py", line 439, in > compile_function > verbose=verbose, **kw) > File "T:\Python22\Lib\site-packages\weave\ext_tools.py", line 332, in > compile > verbose = verbose, **kw) > File "T:\Python22\Lib\site-packages\weave\build_tools.py", line 221, in > build_extension > setup(name = module_name, ext_modules = [ext],verbose=verb) > File "T:\Python22\lib\distutils\core.py", line 157, in setup > raise SystemExit, "error: " + str(msg) > CompileError: error: command 'g++' failed: No such file or directory > > ---------------------------------------------------------------------- > Ran 184 tests in 250.797s > > FAILED (errors=1) > > > I need this stuff to work in order to make my dynamic optimizations run > faster, so any assistance is most welcome. It looks like all the weave tests passed accept for the one blitz test. If your not planning on using blitz, then I think you may be OK. I just tried running weave with my cygwin installation with: ---------------------------------------------------------------------- Ran 184 tests in 74.055s FAILED (failures=1, errors=22) The blitz() test failed but not like yours. I actually got incorrect results. The 22 errors were all of the MSC++ tests failing because they couldn't find the C++ file they were asked to compile: sc_abccabed66f253b594f63a36ae4b0cdb0.cpp fatal error C1083: Cannot open source file: '/cygdrive/c/DOCUME~1/eric/LOCALS~1/ Temp/@1336.2/sc_abccabed66f253b594f63a36ae4b0cdb0.cpp': No such file or directory E I'll have to explore these. As for the error of not finding g++, I don't know why it is happening. If it is in the path and you can execute the following: eric at ERICDESKTOP ~/wrk $ python Python 2.2.1 (#1, Jun 25 2002, 10:55:46) [GCC 2.95.3-5 (cygwin special)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.system('g++') g++: No input files 256 weave shouldn't complain -- especially since it appears to be finding it in many of the other 184 tests. Hope something here helps, eric > > Thanks, > Chris Fonnesbeck > -- > ______________________________________________ > http://www.linuxmail.org/ > Now with POP3/IMAP access for only US$19.95/yr > > Powered by Outblaze > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From fonnesbeck at linuxmail.org Fri Nov 15 18:42:33 2002 From: fonnesbeck at linuxmail.org (Christopher Fonnesbeck) Date: Sat, 16 Nov 2002 07:42:33 +0800 Subject: [SciPy-user] Weave on W2K problems Message-ID: <20021115234233.28003.qmail@linuxmail.org> Thanks for the reply, > It looks like all the weave tests passed accept for the one blitz test. > If your not planning on using blitz, then I think you may be OK. > I do need blitz, beacause all my stuff is inline ... :( > > The blitz() test failed but not like yours. I actually got incorrect > results. The 22 errors were all of the MSC++ tests failing because they > couldn't find the C++ file they were asked to compile: > > sc_abccabed66f253b594f63a36ae4b0cdb0.cpp > fatal error C1083: Cannot open source file: > '/cygdrive/c/DOCUME~1/eric/LOCALS~1/ > Temp/@1336.2/sc_abccabed66f253b594f63a36ae4b0cdb0.cpp': No such file or > directory > E > > I'll have to explore these. > > As for the error of not finding g++, I don't know why it is happening. > If it is in the path and you can execute the following: > > eric at ERICDESKTOP ~/wrk > $ python > Python 2.2.1 (#1, Jun 25 2002, 10:55:46) > [GCC 2.95.3-5 (cygwin special)] on cygwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import os > >>> os.system('g++') > g++: No input files > 256 > > weave shouldn't complain -- especially since it appears to be finding it > in many of the other 184 tests. > > Hope something here helps, > eric > I got the same output as you when running os.system('g++'), and yet the same test error occurs ... -- ______________________________________________ http://www.linuxmail.org/ Now with POP3/IMAP access for only US$19.95/yr Powered by Outblaze From fonnesbeck at linuxmail.org Fri Nov 15 18:48:12 2002 From: fonnesbeck at linuxmail.org (Christopher Fonnesbeck) Date: Sat, 16 Nov 2002 07:48:12 +0800 Subject: [SciPy-user] Weave on W2K problems -- more clues Message-ID: <20021115234812.1050.qmail@linuxmail.org> I also get the following in the test output: WARNING: failed to build import library for gcc. Linking will fail. Ewarning: specified build_dir '_bad_path_' does not exist or is not writable. Trying default locations Not sure if that helps with respect to the g++ problems ----- Original Message ----- From: "eric jones" Date: Fri, 15 Nov 2002 16:31:29 -0600 To: Subject: RE: [SciPy-user] Weave on W2K problems > Hey Chris, > > > I am trying to set up weave/scipy on a very fast machine, > unfortunately > > running W2K, rather than *NIX, and am having a couple of problems with > > weave. First, although the scipy binary puts its weave components in > > $PYTHONHOME\Lib\site-packages as I would expect, the full weave binary > > puts its stuff in $PYTHONHOME. > > This may be because the standalone version was built with 2.1.3 and I > believe it defaulted to putting things in $PYTHONHOME on windows > distributions. This was corrected in Python2.2 (which is used to build > SciPy). > > > Second, though I have the cygwin gcc > > compiler (with g++ also) installed and listed first on my user path, I > get > > the following error claiming g++ cannot be found. > > > > ====================================================================== > > ERROR: result[1:-1,1:-1] = (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1] > > ---------------------------------------------------------------------- > > Traceback (most recent call last): > > File > "T:\Python22\Lib\site-packages\weave\tests\test_blitz_tools.py", > > line 150, in check_5point_avg_2d > > self.generic_2d(expr) > > File > "T:\Python22\Lib\site-packages\weave\tests\test_blitz_tools.py", > > line 124, in generic_2d > > mod_location) > > File > "T:\Python22\Lib\site-packages\weave\tests\test_blitz_tools.py", > > line 80, in generic_test > > blitz_tools.blitz(expr,arg_dict,{},verbose=0) #, > > File "T:\Python22\Lib\site-packages\weave\blitz_tools.py", line 72, > in > > blitz > > type_converters = converters.blitz, > > File "T:\Python22\Lib\site-packages\weave\inline_tools.py", line > 439, in > > compile_function > > verbose=verbose, **kw) > > File "T:\Python22\Lib\site-packages\weave\ext_tools.py", line 332, > in > > compile > > verbose = verbose, **kw) > > File "T:\Python22\Lib\site-packages\weave\build_tools.py", line 221, > in > > build_extension > > setup(name = module_name, ext_modules = [ext],verbose=verb) > > File "T:\Python22\lib\distutils\core.py", line 157, in setup > > raise SystemExit, "error: " + str(msg) > > CompileError: error: command 'g++' failed: No such file or directory > > > > ---------------------------------------------------------------------- > > Ran 184 tests in 250.797s > > > > FAILED (errors=1) > > > > > > I need this stuff to work in order to make my dynamic optimizations > run > > faster, so any assistance is most welcome. > > It looks like all the weave tests passed accept for the one blitz test. > If your not planning on using blitz, then I think you may be OK. > > I just tried running weave with my cygwin installation with: > > ---------------------------------------------------------------------- > Ran 184 tests in 74.055s > > FAILED (failures=1, errors=22) > > The blitz() test failed but not like yours. I actually got incorrect > results. The 22 errors were all of the MSC++ tests failing because they > couldn't find the C++ file they were asked to compile: > > sc_abccabed66f253b594f63a36ae4b0cdb0.cpp > fatal error C1083: Cannot open source file: > '/cygdrive/c/DOCUME~1/eric/LOCALS~1/ > Temp/@1336.2/sc_abccabed66f253b594f63a36ae4b0cdb0.cpp': No such file or > directory > E > > I'll have to explore these. > > As for the error of not finding g++, I don't know why it is happening. > If it is in the path and you can execute the following: > > eric at ERICDESKTOP ~/wrk > $ python > Python 2.2.1 (#1, Jun 25 2002, 10:55:46) > [GCC 2.95.3-5 (cygwin special)] on cygwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import os > >>> os.system('g++') > g++: No input files > 256 > > weave shouldn't complain -- especially since it appears to be finding it > in many of the other 184 tests. > > Hope something here helps, > eric > > > > > > > > Thanks, > > Chris Fonnesbeck > > -- > > ______________________________________________ > > http://www.linuxmail.org/ > > Now with POP3/IMAP access for only US$19.95/yr > > > > Powered by Outblaze > > _______________________________________________ > > SciPy-user mailing list > > SciPy-user at scipy.net > > http://www.scipy.net/mailman/listinfo/scipy-user > > > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > -- ______________________________________________ http://www.linuxmail.org/ Now with POP3/IMAP access for only US$19.95/yr Powered by Outblaze From jmr at engineering.uiowa.edu Fri Nov 15 23:28:22 2002 From: jmr at engineering.uiowa.edu (Joe Reinhardt) Date: Fri, 15 Nov 2002 22:28:22 -0600 Subject: [SciPy-user] Debian package(s)? In-Reply-To: <20021114181033.GB970@openlc.org> (Francesc Alted's message of "Thu, 14 Nov 2002 19:10:33 +0100") References: <20021114173613.GA970@openlc.org> <20021114181033.GB970@openlc.org> Message-ID: <87k7jem93t.fsf@phantom.ecn.uiowa.edu> Francesc Alted writes: > So, I propose to try to package scipy, say, during next week, and then send > it to Joe Reinhardt for inspection and possible inclusion in Debian. That would be great. I would be happy to help however I can. - Joe From falted at openlc.org Mon Nov 18 05:57:31 2002 From: falted at openlc.org (Francesc Alted) Date: Mon, 18 Nov 2002 11:57:31 +0100 Subject: [SciPy-user] Debian package(s)? -- and RPM In-Reply-To: <200211151506.22502.Ralf_Ahlbrink@web.de> References: <200211151506.22502.Ralf_Ahlbrink@web.de> Message-ID: <20021118105731.GB1883@openlc.org> On Fri, Nov 15, 2002 at 03:06:22PM +0100, RA wrote: > > I've just read the ml archive, because I want to contribute some packages > (scipy and f2py), both RPM (Mdk 9.0) and DEB (woody). > I've got some experience with RPM and I'll also submit these packages to > cooker (just updated yesterday, with custom atlas ). > For debian, well, the debs evolved from joe r. packages. They were updated a > few weeks ago (build with atlas-base). I hope, that they can be at least a > starting point. > So, how could I upload the stuff? Ok. If you have a debian package candidate for both scipy and f2py, I suggest to first send them to Joe Reinhart, and if he founds the packages are ok, put them in a public place in order to be tested by debian scipy users (for example, myself). Please, when building the new packages, have in mind all the suggestions from Pearu and Eric. Good luck, and if you need any help, just say it! -- Francesc Alted PGP KeyID: 0x61C8C11F Scientific aplications developer Public PGP key available: http://www.openlc.org/falted_at_openlc.asc Key fingerprint = 1518 38FE 3A3D 8BE8 24A0 3E5B 1328 32CC 61C8 C11F From Ralf_Ahlbrink at web.de Mon Nov 18 08:28:15 2002 From: Ralf_Ahlbrink at web.de (RA) Date: Mon, 18 Nov 2002 14:28:15 +0100 Subject: [SciPy-user] Debian package(s)? -- and RPM In-Reply-To: <20021118105731.GB1883@openlc.org> References: <200211151506.22502.Ralf_Ahlbrink@web.de> <20021118105731.GB1883@openlc.org> Message-ID: <200211181428.15623.Ralf_Ahlbrink@web.de> On Montag, 18. November 2002 11:57:11, Francesc Alted wrote: > On Fri, Nov 15, 2002 at 03:06:22PM +0100, RA wrote: > > I've just read the ml archive, because I want to contribute some packages > > (scipy and f2py), both RPM (Mdk 9.0) and DEB (woody). > > I've got some experience with RPM and I'll also submit these packages to > > cooker (just updated yesterday, with custom atlas ). > > For debian, well, the debs evolved from joe r. packages. They were > > updated a few weeks ago (build with atlas-base). I hope, that they can be > > at least a starting point. > > So, how could I upload the stuff? > > Ok. If you have a debian package candidate for both scipy and f2py, I > suggest to first send them to Joe Reinhart, and if he founds the packages > are ok, put them in a public place in order to be tested by debian scipy > users (for example, myself). I've got two packages for now: f2py (scipy_distutils omitted), and scipy with all parts except chacko. I could work this evening on the splitting of scipy (see below). Furthermore, I used python2.2 explicitely. I believe, that for woody, one has to provide both, python- and python2.2- packages -- correct? So, that would be another todo. I guess, only after these modifications Joe wants to have these debs... > > Please, when building the new packages, have in mind all the suggestions > from Pearu and Eric. Just to make sure: ### Pearu's summary ### 1) scipy_distutils and scipy_test are bundled to scipy_core 2) scipy_base stays in scipy (at least for the time being) 3) The following packages are stand-alone and all depend on scipy_core: scipy, weave, f2py2e, chaco, etc. 4) scipy depends also on weave, f2py2e, chaco(?in future), etc. ### This _could_ mean: 'python<>' and 'python2.2<>' debs: '-scipy-core' -- see 1) '-scipy' (scipy & scipy_base), '-weave' , '-chaco' -- see 2) & 3) '-f2py' (stand-alone), '-f2py2e' or '-f2py-base' (scipy_distutils omitted) Comments? > > Good luck, and if you need any help, just say it! Okay, regarding the Debian packaging, I will do. And -- as I mentioned before -- I would like to upload some RPMs, and I could also upload the Debian packages in the present state. For that, I would like to use my member page (RalfA) of scipy.org. Is this okay? Ralf. From pearu at cens.ioc.ee Mon Nov 18 09:14:10 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Mon, 18 Nov 2002 16:14:10 +0200 (EET) Subject: [SciPy-user] Debian package(s)? -- and RPM In-Reply-To: <200211181428.15623.Ralf_Ahlbrink@web.de> Message-ID: On Mon, 18 Nov 2002, RA wrote: > Just to make sure: > > ### Pearu's summary ### > 1) scipy_distutils and scipy_test are bundled to scipy_core > 2) scipy_base stays in scipy (at least for the time being) > 3) The following packages are stand-alone and all depend on scipy_core: > scipy, weave, f2py2e, chaco, etc. > 4) scipy depends also on weave, f2py2e, chaco(?in future), etc. > ### > > This _could_ mean: > > 'python<>' and 'python2.2<>' debs: > > '-scipy-core' -- see 1) > '-scipy' (scipy & scipy_base), '-weave' , '-chaco' -- see 2) & 3) > '-f2py' (stand-alone), '-f2py2e' or '-f2py-base' (scipy_distutils omitted) > > Comments? Do you mean: python-f2py (stand-alone) contains f2py2e and scipy_distutils and python-f2py2e contains f2py2e only ? Hmm, (i) isn't there a conflict then between python-f2py and python-scipy-core if both contain scipy_distutils? And (ii) python-f2py2e will loose part of its functionality ("f2py -c ..." stuff) if it cannot use scipy_distutils (in fact, f2py will probably complain about it). I think you can treat f2py similarly to '-scipy', '-weave', or '-chaco' (packaging should be then easier). All they depend on scipy-core and the only difference is that f2py comes with a script 'f2py'. If you need certain changes to scipy or f2py2e setup.py scripts that will ease deb or rpm packaging, let us know. Pearu From Ralf_Ahlbrink at web.de Mon Nov 18 10:05:52 2002 From: Ralf_Ahlbrink at web.de (RA) Date: Mon, 18 Nov 2002 16:05:52 +0100 Subject: [SciPy-user] Debian package(s)? -- and RPM In-Reply-To: References: Message-ID: <200211181605.52315.Ralf_Ahlbrink@web.de> On Montag, 18. November 2002 15:14:15, Pearu Peterson wrote: > > Do you mean: > python-f2py (stand-alone) contains f2py2e and scipy_distutils > and > python-f2py2e contains f2py2e only > ? Yes. > Hmm, (i) isn't there a conflict then between python-f2py > and python-scipy-core if both contain scipy_distutils? You would only install '-f2py', if '-scipy-core' is not installed. They exclude each other. And, like you already said, -f2py2e (or call it '-f2py-scipy' ??) needs '-scipy-core'. > And (ii) python-f2py2e will loose part of its functionality ("f2py -c > ..." stuff) if it cannot use scipy_distutils (in fact, f2py will probably > complain about it). Therefore, you need the above mentioned dependency on '-scipy-core'. > > I think you can treat f2py similarly to '-scipy', '-weave', or '-chaco' > (packaging should be then easier). All they depend on scipy-core and the > only difference is that f2py comes with a script 'f2py'. So, you mean, only _one_ '-f2py' package, with script-file and f2py2e directory? This would be indeed the simplest version. If someone wants to use f2py, but not scipy, he/she has to install scipy-core. Then scipy_test is also there and not needed, but: So what? It's a question about 273 kByte. If that matters, one has to split scipy-core or use the above listed two f2py packages... > > If you need certain changes to scipy or f2py2e setup.py scripts that will > ease deb or rpm packaging, let us know. Fine. > > Pearu Ralf. > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From pearu at cens.ioc.ee Mon Nov 18 10:37:24 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Mon, 18 Nov 2002 17:37:24 +0200 (EET) Subject: [SciPy-user] Debian package(s)? -- and RPM In-Reply-To: <200211181605.52315.Ralf_Ahlbrink@web.de> Message-ID: On Mon, 18 Nov 2002, RA wrote: > > I think you can treat f2py similarly to '-scipy', '-weave', or '-chaco' > > (packaging should be then easier). All they depend on scipy-core and the > > only difference is that f2py comes with a script 'f2py'. > > So, you mean, only _one_ '-f2py' package, with script-file and f2py2e > directory? Yes, exactly. > This would be indeed the simplest version. If someone wants to use > f2py, but not scipy, he/she has to install scipy-core. Yes, that was the point. I thought that debian packaging system takes care of such dependencies so that scipy-core will be selected automatically when one selects f2py, right? > Then scipy_test is also there and not needed, but: So what? It's a question > about 273 kByte. If that matters, one has to split scipy-core or use the > above listed two f2py packages... It is true that f2py *currently* does not use scipy_test but it *will* in near future (when I implement more f2py unittests). So, it is ok that f2py depends on scipy_test now. Pearu From Ralf_Ahlbrink at web.de Mon Nov 18 10:45:23 2002 From: Ralf_Ahlbrink at web.de (RA) Date: Mon, 18 Nov 2002 16:45:23 +0100 Subject: [SciPy-user] Debian package(s)? -- and RPM In-Reply-To: References: Message-ID: <200211181645.23871.Ralf_Ahlbrink@web.de> On Montag, 18. November 2002 16:37:16, Pearu Peterson wrote: > On Mon, 18 Nov 2002, RA wrote: > > > I think you can treat f2py similarly to '-scipy', '-weave', or '-chaco' > > > (packaging should be then easier). All they depend on scipy-core and > > > the only difference is that f2py comes with a script 'f2py'. > > > > So, you mean, only _one_ '-f2py' package, with script-file and f2py2e > > directory? > > Yes, exactly. > > > This would be indeed the simplest version. If someone wants to use > > f2py, but not scipy, he/she has to install scipy-core. > > Yes, that was the point. > > I thought that debian packaging system takes care of such dependencies so > that scipy-core will be selected automatically when one selects f2py, > right? > > > Then scipy_test is also there and not needed, but: So what? It's a > > question about 273 kByte. If that matters, one has to split scipy-core or > > use the above listed two f2py packages... > > It is true that f2py *currently* does not use scipy_test but it *will* in > near future (when I implement more f2py unittests). So, it is ok that f2py > depends on scipy_test now. No questions anymore ;-) > > Pearu > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From steven.robbins at videotron.ca Mon Nov 18 11:50:35 2002 From: steven.robbins at videotron.ca (Steve M. Robbins) Date: Mon, 18 Nov 2002 11:50:35 -0500 Subject: [SciPy-user] Debian package(s)? -- and RPM In-Reply-To: References: <200211181605.52315.Ralf_Ahlbrink@web.de> Message-ID: <20021118165035.GC15023@riemann.nyongwa.montreal.qc.ca> On Mon, Nov 18, 2002 at 05:37:24PM +0200, Pearu Peterson wrote: > > On Mon, 18 Nov 2002, RA wrote: > > > > I think you can treat f2py similarly to '-scipy', '-weave', or '-chaco' > > > (packaging should be then easier). All they depend on scipy-core and the > > > only difference is that f2py comes with a script 'f2py'. > > > > So, you mean, only _one_ '-f2py' package, with script-file and f2py2e > > directory? > > Yes, exactly. > > > This would be indeed the simplest version. If someone wants to use > > f2py, but not scipy, he/she has to install scipy-core. > > Yes, that was the point. > > I thought that debian packaging system takes care of such dependencies so > that scipy-core will be selected automatically when one selects f2py, > right? Yes. I'm a little curious on one point. How do you bootstrap all this on a pristine system? My understanding is that "scipy" needs "f2py" to build, while the latter depends on having "scipy-core" installed. But "scipy" and "scipy-core" are both in the same CVS tree, aren't they? Are multiple tarballs generated from that tree? What is the set of source tar balls and in what order do you build them? -S From pearu at cens.ioc.ee Mon Nov 18 12:15:03 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Mon, 18 Nov 2002 19:15:03 +0200 (EET) Subject: [SciPy-user] Debian package(s)? -- and RPM In-Reply-To: <20021118165035.GC15023@riemann.nyongwa.montreal.qc.ca> Message-ID: On Mon, 18 Nov 2002, Steve M. Robbins wrote: > I'm a little curious on one point. How do you bootstrap all this on a > pristine system? My understanding is that "scipy" needs "f2py" to build, > while the latter depends on having "scipy-core" installed. But "scipy" and > "scipy-core" are both in the same CVS tree, aren't they? Are multiple > tarballs generated from that tree? What is the set of source tar balls > and in what order do you build them? I don't know what is pristine system but (scipy/f2py2e) setup.py files can be modified so that they generate the required tarballs even if various packages are in the same CVS tree. My initial idea of the tarballs would be as follows (with the corresponding building order and TODO bits): scipy_core-???.tar.gz - contains scipy_test and scipy_distutils, need to introduce scipy/setup_scipy_core.py f2py2e-???.tar.gz - contains f2py2e (without scipy_distutils), need to modify f2py2e/setup.py scipy-???.tar.gz - contains scipy tree without scipy_test and scipy_distutils directories, need to modify scipy/setup_scipy.py Pearu From steven.robbins at videotron.ca Mon Nov 18 12:31:12 2002 From: steven.robbins at videotron.ca (Steve M. Robbins) Date: Mon, 18 Nov 2002 12:31:12 -0500 Subject: [SciPy-user] Debian package(s)? -- and RPM In-Reply-To: References: <20021118165035.GC15023@riemann.nyongwa.montreal.qc.ca> Message-ID: <20021118173112.GD15023@riemann.nyongwa.montreal.qc.ca> On Mon, Nov 18, 2002 at 07:15:03PM +0200, Pearu Peterson wrote: > > On Mon, 18 Nov 2002, Steve M. Robbins wrote: > > > I'm a little curious on one point. How do you bootstrap all this on a > > pristine system? My understanding is that "scipy" needs "f2py" to build, > > while the latter depends on having "scipy-core" installed. But "scipy" and > > "scipy-core" are both in the same CVS tree, aren't they? Are multiple > > tarballs generated from that tree? What is the set of source tar balls > > and in what order do you build them? > > I don't know what is pristine system I simply meant a system with neither f2py nor any scipy stuff installed. > but (scipy/f2py2e) setup.py files can > be modified so that they generate the required tarballs even if various > packages are in the same CVS tree. My initial idea of the tarballs would > be as follows (with the corresponding building order and TODO bits): > > scipy_core-???.tar.gz - contains scipy_test and scipy_distutils, > need to introduce scipy/setup_scipy_core.py > f2py2e-???.tar.gz - contains f2py2e (without scipy_distutils), > need to modify f2py2e/setup.py > scipy-???.tar.gz - contains scipy tree without scipy_test and > scipy_distutils directories, > need to modify scipy/setup_scipy.py That looks good to me. -S From Ralf_Ahlbrink at web.de Mon Nov 18 12:32:16 2002 From: Ralf_Ahlbrink at web.de (RA) Date: Mon, 18 Nov 2002 18:32:16 +0100 Subject: [SciPy-user] Debian package(s)? -- and RPM In-Reply-To: <20021118165035.GC15023@riemann.nyongwa.montreal.qc.ca> References: <200211181605.52315.Ralf_Ahlbrink@web.de> <20021118165035.GC15023@riemann.nyongwa.montreal.qc.ca> Message-ID: <200211181832.16382.Ralf_Ahlbrink@web.de> On Montag, 18. November 2002 17:50:17, Steve M. Robbins wrote: > On Mon, Nov 18, 2002 at 05:37:24PM +0200, Pearu Peterson wrote: > > On Mon, 18 Nov 2002, RA wrote: > > > > I think you can treat f2py similarly to '-scipy', '-weave', or > > > > '-chaco' (packaging should be then easier). All they depend on > > > > scipy-core and the only difference is that f2py comes with a script > > > > 'f2py'. > > > > > > So, you mean, only _one_ '-f2py' package, with script-file and f2py2e > > > directory? > > > > Yes, exactly. > > > > > This would be indeed the simplest version. If someone wants to use > > > f2py, but not scipy, he/she has to install scipy-core. > > > > Yes, that was the point. > > > > I thought that debian packaging system takes care of such dependencies so > > that scipy-core will be selected automatically when one selects f2py, > > right? > > Yes. > > > I'm a little curious on one point. How do you bootstrap all this on a > pristine system? My understanding is that "scipy" needs "f2py" to build, > while the latter depends on having "scipy-core" installed. But "scipy" and > "scipy-core" are both in the same CVS tree, aren't they? Are multiple > tarballs generated from that tree? What is the set of source tar balls > and in what order do you build them? I'm just building new RPMs with scipy-core splitted. Yes, now I have to use two tarballs. And I created a setup-core.py: ########## #!/usr/bin/env python """ setup-core.py for installing the 'core' of scipy Usage: python setup.py build/install """ import os,sys from scipy_version import scipy_version from distutils.core import setup if __name__ == "__main__": print 'SciPy Version %s (core)', scipy_version setup (name = "SciPy (core)", version = scipy_version, maintainer = "SciPy Developers", maintainer_email = "scipy-dev at scipy.org", description = "Scientific Algorithms Library for Python", license = "SciPy License (BSD Style)", url = "http://www.scipy.org", packages=['scipy_distutils', 'scipy_distutils.command', 'scipy_test'], package_dir = {'scipy_distutils':'scipy_distutils', 'scipy_test':'scipy_test', }, ) ######### Life was easier with only one scipy-package... > > -S > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From Ralf_Ahlbrink at web.de Mon Nov 18 13:44:53 2002 From: Ralf_Ahlbrink at web.de (RA) Date: Mon, 18 Nov 2002 19:44:53 +0100 Subject: [SciPy-user] RPMs for Mandrake 9.0 Message-ID: <200211181944.53855.Ralf_Ahlbrink@web.de> If you want to test: http://www.scipy.org/Members/RalfA/packages/Mandrake-9.0-RPM/python-f2py-2.23.190.1369-1ra.src.rpm http://www.scipy.org/Members/RalfA/packages/Mandrake-9.0-RPM/python-scipy-core-0.2.0_alpha_150.4447-1ra.src.rpm http://www.scipy.org/Members/RalfA/packages/Mandrake-9.0-RPM/python-scipy-0.2.0_alpha_150.4447-1ra.src.rpm To build a custom atlas (semiautomaticaly): http://www.scipy.org/Members/RalfA/packages/Mandrake-9.0-RPM/atlas.spec http://www.scipy.org/Members/RalfA/packages/Mandrake-9.0-RPM/atlas3.3.15-config.patch.bz2 You need the source package from math-atlas.sourceforge.net From eric at enthought.com Mon Nov 18 14:57:37 2002 From: eric at enthought.com (eric jones) Date: Mon, 18 Nov 2002 13:57:37 -0600 Subject: [SciPy-user] Weave on W2K problems -- more clues In-Reply-To: <20021115234812.1050.qmail@linuxmail.org> Message-ID: <000801c28f3c$c1448c60$8901a8c0@ERICDESKTOP> > > I also get the following in the test output: > > WARNING: failed to build import library for gcc. Linking will fail. Looking at build_tools.py, I think this is associated with the use of cygwin instead of mingw. Mingw has a tool called "dlltool" that is used in converting the python22.lib to a libpython22.a file. It doesn't look like cygwin has the same tools. Can you use mingw instead of cygwin and see if it solves your problems? You'll need to use the version based on 2.95.3 (mingw1.1 I believe), as weave doesn't work with the latest version. > E > warning: specified build_dir '_bad_path_' does not exist or is not > writable. Trying default locations This warning is supposed to happen -- it is part of a unit test. > > Not sure if that helps with respect to the g++ problems Hopefully moving to mingw fixes your problems. Good luck, Eric > > > > ----- Original Message ----- > From: "eric jones" > Date: Fri, 15 Nov 2002 16:31:29 -0600 > To: > Subject: RE: [SciPy-user] Weave on W2K problems > > > > Hey Chris, > > > > > I am trying to set up weave/scipy on a very fast machine, > > unfortunately > > > running W2K, rather than *NIX, and am having a couple of problems with > > > weave. First, although the scipy binary puts its weave components in > > > $PYTHONHOME\Lib\site-packages as I would expect, the full weave binary > > > puts its stuff in $PYTHONHOME. > > > > This may be because the standalone version was built with 2.1.3 and I > > believe it defaulted to putting things in $PYTHONHOME on windows > > distributions. This was corrected in Python2.2 (which is used to build > > SciPy). > > > > > Second, though I have the cygwin gcc > > > compiler (with g++ also) installed and listed first on my user path, I > > get > > > the following error claiming g++ cannot be found. > > > > > > ====================================================================== > > > ERROR: result[1:-1,1:-1] = (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1] > > > ---------------------------------------------------------------------- > > > Traceback (most recent call last): > > > File > > "T:\Python22\Lib\site-packages\weave\tests\test_blitz_tools.py", > > > line 150, in check_5point_avg_2d > > > self.generic_2d(expr) > > > File > > "T:\Python22\Lib\site-packages\weave\tests\test_blitz_tools.py", > > > line 124, in generic_2d > > > mod_location) > > > File > > "T:\Python22\Lib\site-packages\weave\tests\test_blitz_tools.py", > > > line 80, in generic_test > > > blitz_tools.blitz(expr,arg_dict,{},verbose=0) #, > > > File "T:\Python22\Lib\site-packages\weave\blitz_tools.py", line 72, > > in > > > blitz > > > type_converters = converters.blitz, > > > File "T:\Python22\Lib\site-packages\weave\inline_tools.py", line > > 439, in > > > compile_function > > > verbose=verbose, **kw) > > > File "T:\Python22\Lib\site-packages\weave\ext_tools.py", line 332, > > in > > > compile > > > verbose = verbose, **kw) > > > File "T:\Python22\Lib\site-packages\weave\build_tools.py", line 221, > > in > > > build_extension > > > setup(name = module_name, ext_modules = [ext],verbose=verb) > > > File "T:\Python22\lib\distutils\core.py", line 157, in setup > > > raise SystemExit, "error: " + str(msg) > > > CompileError: error: command 'g++' failed: No such file or directory > > > > > > ---------------------------------------------------------------------- > > > Ran 184 tests in 250.797s > > > > > > FAILED (errors=1) > > > > > > > > > I need this stuff to work in order to make my dynamic optimizations > > run > > > faster, so any assistance is most welcome. > > > > It looks like all the weave tests passed accept for the one blitz test. > > If your not planning on using blitz, then I think you may be OK. > > > > I just tried running weave with my cygwin installation with: > > > > ---------------------------------------------------------------------- > > Ran 184 tests in 74.055s > > > > FAILED (failures=1, errors=22) > > > > The blitz() test failed but not like yours. I actually got incorrect > > results. The 22 errors were all of the MSC++ tests failing because they > > couldn't find the C++ file they were asked to compile: > > > > sc_abccabed66f253b594f63a36ae4b0cdb0.cpp > > fatal error C1083: Cannot open source file: > > '/cygdrive/c/DOCUME~1/eric/LOCALS~1/ > > Temp/@1336.2/sc_abccabed66f253b594f63a36ae4b0cdb0.cpp': No such file or > > directory > > E > > > > I'll have to explore these. > > > > As for the error of not finding g++, I don't know why it is happening. > > If it is in the path and you can execute the following: > > > > eric at ERICDESKTOP ~/wrk > > $ python > > Python 2.2.1 (#1, Jun 25 2002, 10:55:46) > > [GCC 2.95.3-5 (cygwin special)] on cygwin > > Type "help", "copyright", "credits" or "license" for more information. > > >>> import os > > >>> os.system('g++') > > g++: No input files > > 256 > > > > weave shouldn't complain -- especially since it appears to be finding it > > in many of the other 184 tests. > > > > Hope something here helps, > > eric > > > > > > > > > > > > > > Thanks, > > > Chris Fonnesbeck > > > -- > > > ______________________________________________ > > > http://www.linuxmail.org/ > > > Now with POP3/IMAP access for only US$19.95/yr > > > > > > Powered by Outblaze > > > _______________________________________________ > > > SciPy-user mailing list > > > SciPy-user at scipy.net > > > http://www.scipy.net/mailman/listinfo/scipy-user > > > > > > > > _______________________________________________ > > SciPy-user mailing list > > SciPy-user at scipy.net > > http://www.scipy.net/mailman/listinfo/scipy-user > > > > -- > ______________________________________________ > http://www.linuxmail.org/ > Now with POP3/IMAP access for only US$19.95/yr > > Powered by Outblaze > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From turner at lanl.gov Mon Nov 18 15:49:20 2002 From: turner at lanl.gov (John A. Turner) Date: Mon, 18 Nov 2002 13:49:20 -0700 Subject: [SciPy-user] Weave on W2K problems -- more clues References: <000801c28f3c$c1448c60$8901a8c0@ERICDESKTOP> Message-ID: <3DD95250.B68A814B@lanl.gov> eric jones wrote: > Looking at build_tools.py, I think this is associated with the use of > cygwin instead of mingw. Mingw has a tool called "dlltool" that is used > in converting the python22.lib to a libpython22.a file. It doesn't look > like cygwin has the same tools. cygwin does include dlltool: ~$ which dlltool /usr/bin/dlltool ~$ dlltool --version GNU dlltool 2.13.90 20021108 not sure which pkg it's in... -John A. Turner Los Alamos National Lab Advanced Scientific Simulation, CCS-2 From fonnesbeck at linuxmail.org Mon Nov 18 16:43:29 2002 From: fonnesbeck at linuxmail.org (Christopher Fonnesbeck) Date: Tue, 19 Nov 2002 05:43:29 +0800 Subject: [SciPy-user] Weave on W2K problems -- more clues Message-ID: <20021118214330.15661.qmail@linuxmail.org> Thanks this is helping. I have loaded MinGW, and it now seems to find g++, but the problem it has is with dllwrap. Even though dllwrap is in the MinGW bin directory, I get the following: ====================================================================== ERROR: result[1:-1,1:-1] = (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1] ---------------------------------------------------------------------- Traceback (most recent call last): File "T:\Python22\Lib\site-packages\weave\tests\test_blitz_tools.py", line 150, in check_5point_avg_2d self.generic_2d(expr) File "T:\Python22\Lib\site-packages\weave\tests\test_blitz_tools.py", line 124, in generic_2d mod_location) File "T:\Python22\Lib\site-packages\weave\tests\test_blitz_tools.py", line 80, in generic_test blitz_tools.blitz(expr,arg_dict,{},verbose=0) #, File "T:\Python22\Lib\site-packages\weave\blitz_tools.py", line 72, in blitz type_converters = converters.blitz, File "T:\Python22\Lib\site-packages\weave\inline_tools.py", line 439, in compile_function verbose=verbose, **kw) File "T:\Python22\Lib\site-packages\weave\ext_tools.py", line 332, in compile verbose = verbose, **kw) File "T:\Python22\Lib\site-packages\weave\build_tools.py", line 221, in build_extension setup(name = module_name, ext_modules = [ext],verbose=verb) File "T:\Python22\lib\distutils\core.py", line 157, in setup raise SystemExit, "error: " + str(msg) CompileError: error: command 'dllwrap' failed with exit status 1 and os.system('dllwrap') confirms that dllwrap is there and functioning. Thanks. ChrisF ----- Original Message ----- From: "eric jones" Date: Mon, 18 Nov 2002 13:57:37 -0600 To: Subject: RE: [SciPy-user] Weave on W2K problems -- more clues > > > > I also get the following in the test output: > > > > WARNING: failed to build import library for gcc. Linking will fail. > > Looking at build_tools.py, I think this is associated with the use of > cygwin instead of mingw. Mingw has a tool called "dlltool" that is used > in converting the python22.lib to a libpython22.a file. It doesn't look > like cygwin has the same tools. > > Can you use mingw instead of cygwin and see if it solves your problems? > You'll need to use the version based on 2.95.3 (mingw1.1 I believe), as > weave doesn't work with the latest version. > > > E > > warning: specified build_dir '_bad_path_' does not exist or is not > > writable. Trying default locations > > This warning is supposed to happen -- it is part of a unit test. > > > > > Not sure if that helps with respect to the g++ problems > > Hopefully moving to mingw fixes your problems. > > Good luck, > Eric > > > > > > > > > ----- Original Message ----- > > From: "eric jones" > > Date: Fri, 15 Nov 2002 16:31:29 -0600 > > To: > > Subject: RE: [SciPy-user] Weave on W2K problems > > > > > > > Hey Chris, > > > > > > > I am trying to set up weave/scipy on a very fast machine, > > > unfortunately > > > > running W2K, rather than *NIX, and am having a couple of problems > with > > > > weave. First, although the scipy binary puts its weave components > in > > > > $PYTHONHOME\Lib\site-packages as I would expect, the full weave > binary > > > > puts its stuff in $PYTHONHOME. > > > > > > This may be because the standalone version was built with 2.1.3 and > I > > > believe it defaulted to putting things in $PYTHONHOME on windows > > > distributions. This was corrected in Python2.2 (which is used to > build > > > SciPy). > > > > > > > Second, though I have the cygwin gcc > > > > compiler (with g++ also) installed and listed first on my user > path, I > > > get > > > > the following error claiming g++ cannot be found. > > > > > > > > > ====================================================================== > > > > ERROR: result[1:-1,1:-1] = (b[1:-1,1:-1] + b[2:,1:-1] + > b[:-2,1:-1] > > > > > ---------------------------------------------------------------------- > > > > Traceback (most recent call last): > > > > File > > > "T:\Python22\Lib\site-packages\weave\tests\test_blitz_tools.py", > > > > line 150, in check_5point_avg_2d > > > > self.generic_2d(expr) > > > > File > > > "T:\Python22\Lib\site-packages\weave\tests\test_blitz_tools.py", > > > > line 124, in generic_2d > > > > mod_location) > > > > File > > > "T:\Python22\Lib\site-packages\weave\tests\test_blitz_tools.py", > > > > line 80, in generic_test > > > > blitz_tools.blitz(expr,arg_dict,{},verbose=0) #, > > > > File "T:\Python22\Lib\site-packages\weave\blitz_tools.py", line > 72, > > > in > > > > blitz > > > > type_converters = converters.blitz, > > > > File "T:\Python22\Lib\site-packages\weave\inline_tools.py", line > > > 439, in > > > > compile_function > > > > verbose=verbose, **kw) > > > > File "T:\Python22\Lib\site-packages\weave\ext_tools.py", line > 332, > > > in > > > > compile > > > > verbose = verbose, **kw) > > > > File "T:\Python22\Lib\site-packages\weave\build_tools.py", line > 221, > > > in > > > > build_extension > > > > setup(name = module_name, ext_modules = [ext],verbose=verb) > > > > File "T:\Python22\lib\distutils\core.py", line 157, in setup > > > > raise SystemExit, "error: " + str(msg) > > > > CompileError: error: command 'g++' failed: No such file or > directory > > > > > > > > > ---------------------------------------------------------------------- > > > > Ran 184 tests in 250.797s > > > > > > > > FAILED (errors=1) > > > > > > > > > > > > I need this stuff to work in order to make my dynamic > optimizations > > > run > > > > faster, so any assistance is most welcome. > > > > > > It looks like all the weave tests passed accept for the one blitz > test. > > > If your not planning on using blitz, then I think you may be OK. > > > > > > I just tried running weave with my cygwin installation with: > > > > > > > ---------------------------------------------------------------------- > > > Ran 184 tests in 74.055s > > > > > > FAILED (failures=1, errors=22) > > > > > > The blitz() test failed but not like yours. I actually got > incorrect > > > results. The 22 errors were all of the MSC++ tests failing because > they > > > couldn't find the C++ file they were asked to compile: > > > > > > sc_abccabed66f253b594f63a36ae4b0cdb0.cpp > > > fatal error C1083: Cannot open source file: > > > '/cygdrive/c/DOCUME~1/eric/LOCALS~1/ > > > Temp/@1336.2/sc_abccabed66f253b594f63a36ae4b0cdb0.cpp': No such file > or > > > directory > > > E > > > > > > I'll have to explore these. > > > > > > As for the error of not finding g++, I don't know why it is > happening. > > > If it is in the path and you can execute the following: > > > > > > eric at ERICDESKTOP ~/wrk > > > $ python > > > Python 2.2.1 (#1, Jun 25 2002, 10:55:46) > > > [GCC 2.95.3-5 (cygwin special)] on cygwin > > > Type "help", "copyright", "credits" or "license" for more > information. > > > >>> import os > > > >>> os.system('g++') > > > g++: No input files > > > 256 > > > > > > weave shouldn't complain -- especially since it appears to be > finding it > > > in many of the other 184 tests. > > > > > > Hope something here helps, > > > eric > > > > > > > > > > > > > > > > > > > > Thanks, > > > > Chris Fonnesbeck > > > > -- > > > > ______________________________________________ > > > > http://www.linuxmail.org/ > > > > Now with POP3/IMAP access for only US$19.95/yr > > > > > > > > Powered by Outblaze > > > > _______________________________________________ > > > > SciPy-user mailing list > > > > SciPy-user at scipy.net > > > > http://www.scipy.net/mailman/listinfo/scipy-user > > > > > > > > > > > > _______________________________________________ > > > SciPy-user mailing list > > > SciPy-user at scipy.net > > > http://www.scipy.net/mailman/listinfo/scipy-user > > > > > > > -- > > ______________________________________________ > > http://www.linuxmail.org/ > > Now with POP3/IMAP access for only US$19.95/yr > > > > Powered by Outblaze > > _______________________________________________ > > SciPy-user mailing list > > SciPy-user at scipy.net > > http://www.scipy.net/mailman/listinfo/scipy-user > > > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > -- ______________________________________________ http://www.linuxmail.org/ Now with POP3/IMAP access for only US$19.95/yr Powered by Outblaze From doug at idsia.ch Tue Nov 19 11:33:29 2002 From: doug at idsia.ch (Douglas Eck) Date: Tue, 19 Nov 2002 17:33:29 +0100 Subject: [SciPy-user] Problem with plt on debian sid box Message-ID: <3DDA67D9.3040805@idsia.ch> I am running a debian sid box. I downloaded from CVS today and did a build and generated no errors, but plt doesn't work. >>> from scipy import plt >>> plt.plot([1,2,3,4,5]) It imports without error and even gives me a wxFrame object. But nothing ever appears on the screen. It doesn't seem to be a window manager permissions problem. I can quit python and run a windowed program. Maybe a problem linking against wxpython? Any hints on how to troubleshoot this? A more broad question. Is anyone using plt, or doing upkeep on it? If not, I'll just bag it and use wxPlotCanvas directly. Regards, Doug Eck From falted at openlc.org Tue Nov 19 14:30:43 2002 From: falted at openlc.org (Francesc Alted) Date: Tue, 19 Nov 2002 20:30:43 +0100 Subject: [SciPy-user] [ANN] PyTables 0.2 is out Message-ID: <20021119193043.GD994@openlc.org> Hi, PyTables 0.2 is out. I think it would be interesting for people on this list. Also, if this is considered interesting (and think so), I'm ready to work for its inclusion in scipy. What's new ----------- - Numerical Python arrays supported! - Much improved documentation - Programming API almost stable - Improved navegability across the object tree - Added more unit tests (there are almost 50) - Dropped HDF5_HL dependency (a tailored version is included in sources now) - License changed from LGPL to BSD What is ------- The goal of PyTables is to enable the end user to manipulate easily scientific data tables and Numerical Python objects (new in 0.2!) in a persistent hierarchical structure. The foundation of the underlying hierachical data organization is the excellent HDF5 library (http://hdf.ncsa.uiuc.edu/HDF5). Right now, PyTables provides limited support of all the HDF5 functions, but I hope to add the more interesting ones (for PyTables needs) in the near future. Nonetheless, this package is not intended to serve as a complete wrapper for the entire HDF5 API. A table is defined as a collection of records whose values are stored in fixed-length fields. All records have the same structure and all values in each field have the same data type. The terms "fixed-length" and strict "data types" seems to be quite a strange requirement for an interpreted language like Python, but they serve a useful function if the goal is to save very large quantities of data (such as is generated by many scientifc applications, for example) in an efficient manner that reduces demand on CPU time and I/O. In order to emulate records (C structs in HDF5) in Python, PyTables implements a special metaclass that detects errors in field assignments as well as range overflows. PyTables also provides a powerful interface to process table data. Quite a bit effort has been invested to make browsing the hierarchical data structure a pleasant experience. PyTables implements just three (orthogonal) easy-to-use methods for browsing. What is HDF5? ------------- For those people who know nothing about HDF5, it is is a general purpose library and file format for storing scientific data made at NCSA. HDF5 can store two primary objects: datasets and groups. A dataset is essentially a multidimensional array of data elements, and a group is a structure for organizing objects in an HDF5 file. Using these two basic constructs, one can create and store almost any kind of scientific data structure, such as images, arrays of vectors, and structured and unstructured grids. You can also mix and match them in HDF5 files according to your needs. How fast is it? --------------- Despite to be an alpha version and that there is lot of room for improvements (it's still CPU bounded!), PyTables can read and write tables quite fast. But, if you want some (very preliminary) figures (just to know orders of magnitude), in a AMD Athlon at 900 it can currently read from 40000 up to 60000 records/s and write from 5000 up to 13000 records/s. Raw data speed in read mode ranges from 1 MB/s up to 2 MB/s, and it drops to the 200 KB/s - 600 KB/s range for writes. Go to http://pytables.sf.net/bench.html for a somewhat more detailed description of this small (and synthetic) benchmark. Anyway, this is only the beginning (premature optimization is the root of all evils, you know ;-). Platforms --------- I'm using Linux as the main development platform, but PyTables should be easy to compile/install on other UNIX machines. Thanks to Scott Prater, this package has passed all the tests on a UltraSparc platform with Solaris 7. It also compiles and passes all the tests on a SGI Origin2000 with MIPS R12000 processors and running IRIX 6.5. If you are using Windows and you get the library to work, please let me know. An example? ----------- At the bottom of this message there is some code (less that 100 lines and only less than half being real code) that shows basic capabilities of PyTables. Web site -------- Go to the PyTables web site for more details: http://pytables.sf.net/ Final note ---------- This is second alpha release, and probably last alpha, so it is still time if you want to suggest some API addition/change or addition/change of any useful missing capability. Let me know of any bugs, suggestions, gripes, kudos, etc. you may have. -- Francesc Alted falted at openlc.org *-*-*-**-*-*-**-*-*-**-*-*- Small code example *-*-*-**-*-*-**-*-*-**-*-*-* """Small but almost complete example showing the PyTables mode of use. As a result of execution, a 'tutorial1.h5' file is created. You can look at it with whatever HDF5 generic utility, like h5ls, h5dump or h5view. """ import sys from Numeric import * from tables import * #'-**-**-**-**-**-**- user record definition -**-**-**-**-**-**-**-' # Define a user record to characterize some kind of particles class Particle(IsRecord): name = '16s' # 16-character String idnumber = 'Q' # unsigned long long (i.e. 64-bit integer) TDCcount = 'B' # unsigned byte ADCcount = 'H' # unsigned short integer grid_i = 'i' # integer grid_j = 'i' # integer pressure = 'f' # float (single-precision) energy = 'd' # double (double-precision) print print '-**-**-**-**-**-**- file creation -**-**-**-**-**-**-**-' # The name of our HDF5 filename filename = "tutorial1.h5" print "Creating file:", filename # Open a file in "w"rite mode h5file = openFile(filename, mode = "w", title = "Test file") print print '-**-**-**-**-**-**- group an table creation -**-**-**-**-**-**-**-' # Create a new group under "/" (root) group = h5file.createGroup("/", 'detector', 'Detector information') print "Group '/detector' created" # Create one table on it table = h5file.createTable(group, 'readout', Particle(), "Readout example") print "Table '/detector/readout' created" # Get a shortcut to the record object in table particle = table.record # Fill the table with 10 particles for i in xrange(10): # First, assign the values to the Particle record particle.name = 'Particle: %6d' % (i) particle.TDCcount = i % 256 particle.ADCcount = (i * 256) % (1 << 16) particle.grid_i = i particle.grid_j = 10 - i particle.pressure = float(i*i) particle.energy = float(particle.pressure ** 4) particle.idnumber = i * (2 ** 34) # This exceeds long integer range # Insert a new particle record table.appendAsRecord(particle) # Flush the buffers for table table.flush() print print '-**-**-**-**-**-**- table data reading & selection -**-**-**-**-**-' # Read actual data from table. We are interested in collecting pressure values # on entries where TDCcount field is greater than 3 and pressure less than 50 pressure = [ x.pressure for x in table.readAsRecords() if x.TDCcount > 3 and x.pressure < 50 ] print "Last record read:" print x print "Field pressure elements satisfying the cuts ==>", pressure # Read also the names with the same cuts names = [ x.name for x in table.readAsRecords() if x.TDCcount > 3 and x.pressure < 50 ] print print '-**-**-**-**-**-**- array object creation -**-**-**-**-**-**-**-' print "Creating a new group called '/columns' to hold new arrays" gcolumns = h5file.createGroup(h5file.root, "columns", "Pressure and Name") print "Creating a Numeric array called 'pressure' under '/columns' group" h5file.createArray(gcolumns, 'pressure', array(pressure), "Pressure column selection") print "Creating another Numeric array called 'name' under '/columns' group" h5file.createArray('/columns', 'name', array(names), "Name column selection") # Close the file h5file.close() print "File '"+filename+"' created" -- Francesc Alted PGP KeyID: 0x61C8C11F Scientific aplications developer Public PGP key available: http://www.openlc.org/falted_at_openlc.asc Key fingerprint = 1518 38FE 3A3D 8BE8 24A0 3E5B 1328 32CC 61C8 C11F From pearu at cens.ioc.ee Tue Nov 19 15:26:51 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Tue, 19 Nov 2002 22:26:51 +0200 (EET) Subject: [SciPy-user] Problem with plt on debian sid box In-Reply-To: <3DDA67D9.3040805@idsia.ch> Message-ID: On Tue, 19 Nov 2002, Douglas Eck wrote: > I am running a debian sid box. > > I downloaded from CVS today and did a build and generated no > errors, but plt doesn't work. > > >>> from scipy import plt > >>> plt.plot([1,2,3,4,5]) > > > It imports without error and even gives me a wxFrame object. But > nothing ever appears on the screen. It doesn't seem to be a window > manager permissions problem. I can quit python and run a windowed program. You need to import gui_thread before importing scipy.plt: >>> import gui_thread >>> >>> from scipy import plt >>> plt.plot([1,2,3,4,5]) >>> > A more broad question. Is anyone using plt, or doing upkeep > on it? If not, I'll just bag it and use wxPlotCanvas directly. I am not sure. But chaco will probably replace plt,gplt,xplt modules in future. Pearu From oliphant at ee.byu.edu Tue Nov 19 16:19:45 2002 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Tue, 19 Nov 2002 14:19:45 -0700 (MST) Subject: [SciPy-user] [ANN] PyTables 0.2 is out In-Reply-To: <20021119193043.GD994@openlc.org> Message-ID: > Hi, > > PyTables 0.2 is out. I think it would be interesting for people on this > list. Also, if this is considered interesting (and think so), I'm ready to > work for its inclusion in scipy. > This is a definite possibility. It could factor in nicely into the io subpackage. Why don't you look to see how it could fit in there. I could help you integrate it into the current structure. -Travis O. From wagner.nils at vdi.de Tue Nov 19 16:24:17 2002 From: wagner.nils at vdi.de (Nils Wagner) Date: Tue, 19 Nov 2002 22:24:17 +0100 Subject: [SciPy-user] TypeError: =?iso-8859-1?q?compile=28=29?= argument 1 must be string without null bytes, not string Message-ID: <20021119213448.EED833EACE@www.scipy.com> Hi, I have some trouble with installing scipy on SuSE 8.1. Traceback (most recent call last): File "setup.py", line 127, in ? install_package() File "setup.py", line 117, in install_package url = "http://www.scipy.org", File "scipy_distutils/core.py", line 42, in setup return old_setup(**new_attr) File "/usr/lib/python2.1/distutils/core.py", line 138, in setup dist.run_commands() File "/usr/lib/python2.1/distutils/dist.py", line 899, in run_commands self.run_command(cmd) File "/usr/lib/python2.1/distutils/dist.py", line 919, in run_command cmd_obj.run() File "/usr/lib/python2.1/distutils/command/install.py", line 484, in run self.run_command(cmd_name) File "/usr/lib/python2.1/distutils/cmd.py", line 328, in run_command self.distribution.run_command(command) File "/usr/lib/python2.1/distutils/dist.py", line 919, in run_command cmd_obj.run() File "/usr/lib/python2.1/distutils/command/install_lib.py", line 93, in run self.byte_compile(outfiles) File "/usr/lib/python2.1/distutils/command/install_lib.py", line 130, in byte_ compile verbose=self.verbose, dry_run=self.dry_run) File "/var/tmp/python21-2.1.3-build/usr/lib/python2.1/distutils/util.py", line 439, in byte_compile File "/usr/lib/python2.1/py_compile.py", line 62, in compile codeobject = __builtin__.compile(codestring, dfile or file, 'exec') TypeError: compile() argument 1 must be string without null bytes, not string Any idea ? Nils From dmorrill at enthought.com Tue Nov 19 18:10:12 2002 From: dmorrill at enthought.com (David C. Morrill) Date: Tue, 19 Nov 2002 17:10:12 -0600 Subject: [SciPy-user] Tkinter/OpenGL version of Chaco/Kiva status and request for help Message-ID: <002801c29020$cffd9190$6501a8c0@Dave> First the good news: The Tkinter/OpenGL based version of Chaco/Kiva is very near completion. The major remaining work items are: 1) Convert Eric's wxPython based FreeType Kiva code to work with the OpenGL based version of Kiva. 2) Improve overall performance dramatically. Some people voiced a concern that the wxPython based version of Chaco seems a little slow. Well, compared to the current OpenGL version, it hums like a well oiled machine :-( Hence the request for help... Most of the performance issues with the OpenGL version of Chaco have to do with interactive operations, like drawing the cursor crosshair lines or the graph and axis selection regions. In the wxPython version, we maintain an off-screen bitmap of the PlotWindow contents and either xor the cursor or selection regions into the screen or blit the off-screen bitmap onto the screen (e.g. to refresh the window when a region of the PlotWindow is exposed). Being fairly inexperienced with OpenGL I have not been able to find a way to do something equivalent in OpenGL: - The OpenGL 'overlay' buffers do not appear to be supported by the version of 'togl' supplied with the current PyOpenGL package. - Trying to do a glReadPixels(...) call to read the contents of the OpenGL buffer seems to take about a second on a >1 GHz processor (hardly useful for interactive work). So the question is: Does anyone know how to efficiently 'rubberband' things in OpenGL? If the asnwer is to use the overlay buffer, does anyone know how to get it to work with a Tkinter based OpenGL widget? Thanks in advance for any help... Dave Morrill -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at idsia.ch Wed Nov 20 02:20:46 2002 From: doug at idsia.ch (Douglas Eck) Date: Wed, 20 Nov 2002 08:20:46 +0100 Subject: [SciPy-user] Problem with plt on debian sid box References: Message-ID: <3DDB37CE.50102@idsia.ch> Thansk Pearu. Incredibly stupid of me. I'd been using plt for months and when I reworked my code I forgot about the gui_thread. Cheers, Doug Pearu Peterson wrote: >On Tue, 19 Nov 2002, Douglas Eck wrote: > > > >>I am running a debian sid box. >> >>I downloaded from CVS today and did a build and generated no >>errors, but plt doesn't work. >> >> >>> from scipy import plt >> >>> plt.plot([1,2,3,4,5]) >> >> >>It imports without error and even gives me a wxFrame object. But >>nothing ever appears on the screen. It doesn't seem to be a window >>manager permissions problem. I can quit python and run a windowed program. >> >> > >You need to import gui_thread before importing scipy.plt: > > > >>>>import gui_thread >>>> >>>>from scipy import plt >>>>plt.plot([1,2,3,4,5]) >>>> >>>> > > > > > > >>A more broad question. Is anyone using plt, or doing upkeep >>on it? If not, I'll just bag it and use wxPlotCanvas directly. >> >> > >I am not sure. But chaco will probably replace plt,gplt,xplt modules in >future. > >Pearu > > >_______________________________________________ >SciPy-user mailing list >SciPy-user at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-user > > > From Ralf_Ahlbrink at web.de Wed Nov 20 05:29:21 2002 From: Ralf_Ahlbrink at web.de (RA) Date: Wed, 20 Nov 2002 11:29:21 +0100 Subject: [SciPy-user] Debian package(s) -- preliminary Message-ID: <200211201129.21109.Ralf_Ahlbrink@web.de> See: http://www.scipy.org/Members/RalfA/packages/Debian-woody-DEB/ or fetch them directly: http://www.scipy.org/Members/RalfA/packages/Debian-woody-DEB/f2py/python-f2py_2.23.190.1369-1.diff.gz http://www.scipy.org/Members/RalfA/packages/Debian-woody-DEB/f2py/python-f2py_2.23.190.1369-1.dsc http://www.scipy.org/Members/RalfA/packages/Debian-woody-DEB/f2py/python-f2py_2.23.190.1369.orig.tar.gz http://www.scipy.org/Members/RalfA/packages/Debian-woody-DEB/scipy-core/python-scipy-core_0.2.0.4.259-1.diff.gz http://www.scipy.org/Members/RalfA/packages/Debian-woody-DEB/scipy-core/python-scipy-core_0.2.0.4.259-1.dsc http://www.scipy.org/Members/RalfA/packages/Debian-woody-DEB/scipy-core/python-scipy-core_0.2.0.4.259.orig.tar.gz http://www.scipy.org/Members/RalfA/packages/Debian-woody-DEB/scipy-main/python-scipy_0.2.0.151.4452-1.diff.gz http://www.scipy.org/Members/RalfA/packages/Debian-woody-DEB/scipy-main/python-scipy_0.2.0.151.4452-1.dsc http://www.scipy.org/Members/RalfA/packages/Debian-woody-DEB/scipy-main/python-scipy_0.2.0.151.4452.orig.tar.gz Problems & ToDo: 1) altas is not necessarily needed, but if the packager used it , it should be added to "Depends"-list for python2.[1,2]-scipy. I intuitively tried "Suggests:" in the first (Source) part of debian/control -- beginner's mistake... 2) python2.[1,2]-weave (or call it -scipy-weave ?) is still missing -- and has to be added to "Depends" for python2.[1,2]-scipy. Probably, I'll do it this evening. As for scipy and scipy-core I used the (new) setup_.py script for creation of the source dist, but for weave I got weave-???.tar.gz. setup_weave.py provides no version info?! 3) You'll find more ... Ralf. From falted at openlc.org Wed Nov 20 07:33:08 2002 From: falted at openlc.org (Francesc Alted) Date: Wed, 20 Nov 2002 13:33:08 +0100 Subject: [SciPy-user] [ANN] PyTables 0.2 is out In-Reply-To: References: <20021119193043.GD994@openlc.org> Message-ID: <20021120123308.GF1327@openlc.org> On Tue, Nov 19, 2002 at 02:19:45PM -0700, Travis Oliphant wrote: > > This is a definite possibility. It could factor in nicely into the io > subpackage. Why don't you look to see how it could fit in there. I > could help you integrate it into the current structure. > Ok. I've been browsing the several modules documentation in io subpackage, but I see that they are loosely related. Is there any preferred version for the user?. Anyway, I think PyTables can be easily included therein because I don't see any (hard) I/O dependency on scipy right now. But problem could be that PyTables *requires* python2.2. How can this affect to scipy functionality? Is scipy requiring python backward compatibility until which version?. It also requires HDF5 libraries. We should check if NCSA is willing to accept including HDF5 in scipy, although I do not forsee any problem as far as they are using a liberal BSD license. Maybe (I just don't know) it would be better to wait until scipy 0.3 or when python2.2 be a more standarized platform? Or PyTables can be included right now and make several binary packages depending on the python version used?. Cheers, -- Francesc Alted PGP KeyID: 0x61C8C11F Scientific aplications developer Public PGP key available: http://www.openlc.org/falted_at_openlc.asc Key fingerprint = 1518 38FE 3A3D 8BE8 24A0 3E5B 1328 32CC 61C8 C11F From Ralf_Ahlbrink at web.de Wed Nov 20 08:40:44 2002 From: Ralf_Ahlbrink at web.de (RA) Date: Wed, 20 Nov 2002 14:40:44 +0100 Subject: [SciPy-user] Debian package(s) -- preliminary In-Reply-To: <200211201129.21109.Ralf_Ahlbrink@web.de> References: <200211201129.21109.Ralf_Ahlbrink@web.de> Message-ID: <200211201440.44892.Ralf_Ahlbrink@web.de> I've now seen Pearu's email in scipy-dev archive about the new setup procedure -- and subscribed to the ml ;-) . I hope, that I already used setup_.py correctly. > > 2) python2.[1,2]-weave (or call it -scipy-weave ?) is still missing -- and > has to be added to "Depends" for python2.[1,2]-scipy. Probably, I'll do it > this evening. > As for scipy and scipy-core I used the (new) setup_.py script > for creation of the source dist, but for weave I got weave-???.tar.gz. > setup_weave.py provides no version info?! > So, weave versioning pb is known. About the naming: Something like 'python-scipy_core' is forbidden for Debian packages (because, I believe, '_' initiate the version number). Something like '_alpha_' makes problems, too. Ralf. From gregc at cgl.ucsf.edu Wed Nov 20 13:28:15 2002 From: gregc at cgl.ucsf.edu (Greg Couch) Date: Wed, 20 Nov 2002 10:28:15 -0800 (PST) Subject: [SciPy-user] Tkinter/OpenGL version of Chaco/Kiva status and request for help Message-ID: Just thought I'd clear up some of the OpenGL/Togl/Tk issues in your post. Togl's overlay buffers need to be supported by the graphics card. Most PC graphics cards do not support overlay planes. You need a "workstation" card, such as a NVidia Quadro, a 3dLabs Wildcat, or an ATI FireGL card. glReadPixels is slow because graphics cards vendors say there is no incentive to make it fast. Talk to your vendor. OpenGL rubberbanding is best done with glLogicOp(GL_XOR). Tcl/Tk is slow compared to WxWindows. If you want GUI speed, go back to WxPython. OpenGL is same speed whether you are using WxWindows' wxGLCanvas or Tk's Togl. Hope this helps, Greg Couch UCSF Computer Graphics Lab From doug at idsia.ch Thu Nov 21 03:43:56 2002 From: doug at idsia.ch (Douglas Eck) Date: Thu, 21 Nov 2002 09:43:56 +0100 Subject: [SciPy-user] plt.plot and other wxPython stuff Message-ID: <3DDC9CCC.6000206@idsia.ch> Hello all, this is just a bit of information because I've seen similar postings in the archives. A couple of general questions at the end. I'm trying to use plt.plot in a python app which uses other wxPython stuff. I find that it is very hard to get things to play nicely. In short, if I don't import gui_thread then things go wrong. For example I get this error; >>> plt.axis([0,1,-100,2323]) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/site-packages/scipy/plt/interface.py", line 178, in axis x_ticks = _active.x_axis.ticks AttributeError: axis_window instance has no attribute 'ticks' But if I do import gui_thread, I get lots of strange behavior such as no window at all appearing or sometimes this: Xlib: unexpected async reply (sequence 0x61)! Why bother? Because as I see it, plt.plot is the best all-purpose scientific plotting code around right now for python. Though it can be a bit slow, it works, it's zoomable and, best of all, it generates decent postscript. What I would like to do is strip out the core of plot.plt and use it in a more general setting. Namely I would like to make a scipyPlotCanvas() similar to the wxPlotCanvas() [used to build scipy.plt I believe]. Then I could just drop the canvas into my app. I would be responsible for threading issues, negating the need for gui_thread. I make no promises about having time to do this. But if I do get something working I will post back. Also, pointers are gladly accepted. E.g. is chaco to the point where I could use it? I'm a research scientist with one simple need: a good, flexible plotting canvas for my python front end. Regards, Doug Eck == Dr. Douglas Eck www.idsia.ch/~doug From falted at openlc.org Thu Nov 21 04:49:24 2002 From: falted at openlc.org (Francesc Alted) Date: Thu, 21 Nov 2002 10:49:24 +0100 Subject: [SciPy-user] plt.plot and other wxPython stuff In-Reply-To: <3DDC9CCC.6000206@idsia.ch> References: <3DDC9CCC.6000206@idsia.ch> Message-ID: <20021121094924.GA1876@openlc.org> On Thu, Nov 21, 2002 at 09:43:56AM +0100, Douglas Eck wrote: > > What I would like to do is strip out the core of plot.plt and use it in > a more general setting. Namely I would like to make a > scipyPlotCanvas() similar to the wxPlotCanvas() [used to build scipy.plt > I believe]. Then I could just drop the canvas into my app. I would be > responsible for threading issues, negating the need for gui_thread. > > I make no promises about having time to do this. But if I do get > something working I will post back. Also, pointers are gladly accepted. Before spending effort on this, have a try at PyQwt (http://gerard.vermeulen.free.fr), which besides to offer zoom and postscript output, is *very* fast. You may want also have a look at: http://kmatplot.sourceforge.net/ Both requires the Qt toolkit (which is not necessarily a drawback!) Cheers, -- Francesc Alted PGP KeyID: 0x61C8C11F Scientific aplications developer Public PGP key available: http://www.openlc.org/falted_at_openlc.asc Key fingerprint = 1518 38FE 3A3D 8BE8 24A0 3E5B 1328 32CC 61C8 C11F From doug at idsia.ch Thu Nov 21 05:04:34 2002 From: doug at idsia.ch (Douglas Eck) Date: Thu, 21 Nov 2002 11:04:34 +0100 Subject: [SciPy-user] plt.plot and other wxPython stuff References: <3DDC9CCC.6000206@idsia.ch> <20021121094924.GA1876@openlc.org> Message-ID: <3DDCAFB2.1070007@idsia.ch> Thanks. It looks excellent. . . I'll give it a try. Francesc Alted wrote: >On Thu, Nov 21, 2002 at 09:43:56AM +0100, Douglas Eck wrote: > > >>What I would like to do is strip out the core of plot.plt and use it in >>a more general setting. Namely I would like to make a >>scipyPlotCanvas() similar to the wxPlotCanvas() [used to build scipy.plt >>I believe]. Then I could just drop the canvas into my app. I would be >>responsible for threading issues, negating the need for gui_thread. >> >>I make no promises about having time to do this. But if I do get >>something working I will post back. Also, pointers are gladly accepted. >> >> > >Before spending effort on this, have a try at PyQwt >(http://gerard.vermeulen.free.fr), which besides to offer zoom and >postscript output, is *very* fast. > >You may want also have a look at: http://kmatplot.sourceforge.net/ > >Both requires the Qt toolkit (which is not necessarily a drawback!) > >Cheers, > > > From prabhu at aero.iitm.ernet.in Thu Nov 21 07:10:56 2002 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Thu, 21 Nov 2002 17:40:56 +0530 Subject: [SciPy-user] plt.plot and other wxPython stuff In-Reply-To: <3DDC9CCC.6000206@idsia.ch> References: <3DDC9CCC.6000206@idsia.ch> Message-ID: <15836.52560.521114.800278@monster.linux.in> >>>>> "DE" == Douglas Eck writes: [snip] DE> What I would like to do is strip out the core of plot.plt and DE> use it in a more general setting. Namely I would like to make DE> a scipyPlotCanvas() similar to the wxPlotCanvas() [used to DE> build scipy.plt I believe]. Then I could just drop the canvas DE> into my app. I would be responsible for threading issues, DE> negating the need for gui_thread. plt is not based on wxPlotCanvas and its very easy to use directly from wxPython. I think this post might be of some use: http://www.scipy.org/site_content/mailman?fn=scipy-user/2002-August/000527.html HTH, prabhu From doug at idsia.ch Thu Nov 21 07:36:33 2002 From: doug at idsia.ch (Douglas Eck) Date: Thu, 21 Nov 2002 13:36:33 +0100 Subject: [SciPy-user] plt.plot and other wxPython stuff References: <3DDC9CCC.6000206@idsia.ch> <15836.52560.521114.800278@monster.linux.in> Message-ID: <3DDCD351.6060604@idsia.ch> Unbelievably easy. Thanks much. It's exactly what I wanted. Prabhu Ramachandran wrote: >>>>>>"DE" == Douglas Eck writes: >>>>>> >>>>>> > >[snip] > > DE> What I would like to do is strip out the core of plot.plt and > DE> use it in a more general setting. Namely I would like to make > DE> a scipyPlotCanvas() similar to the wxPlotCanvas() [used to > DE> build scipy.plt I believe]. Then I could just drop the canvas > DE> into my app. I would be responsible for threading issues, > DE> negating the need for gui_thread. > >plt is not based on wxPlotCanvas and its very easy to use directly >from wxPython. I think this post might be of some use: > >http://www.scipy.org/site_content/mailman?fn=scipy-user/2002-August/000527.html > >HTH, >prabhu >_______________________________________________ >SciPy-user mailing list >SciPy-user at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-user > > > From sugino at brandeis.edu Thu Nov 21 14:00:38 2002 From: sugino at brandeis.edu (Ken Sugino) Date: Thu, 21 Nov 2002 14:00:38 -0500 Subject: [SciPy-user] plt.plot and other wxPython stuff In-Reply-To: <3DDC9CCC.6000206@idsia.ch> References: <3DDC9CCC.6000206@idsia.ch> Message-ID: <20021121140038.085f3b98.sugino@brandeis.edu> Hi all, Douglas Eck wrote: > plt.plot is the best all-purpose > scientific plotting code around right now for python. I agreee with Douglas. I've been using scipy mostly for its plt package for a couple of months now and I feel it is the most "practical" interactive plotting package for python. I use line plotting and image display most frequently and there just isn't other good packages which can handle both. But scipy/plt is still not satisfactory: - it doesn't handle nan/inf in an appropriate way, (like matlab or R does) - its image zooming is slow and memory demanding (once killed my linux box) Those were making scipy/plt a little bit "impractical", so I did some modifications, which I attached to this email. I hope someone maintaining plt package will look at them and either incorporate or reimplement them. Ken P.S. Is there anyone planning to implement multiple plots in a window for plt package? "subplot" in matlab is good enough for me, but R's layout function is really flexible and seems to be a good model to imitate. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: plot-mod.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: zoom-mod.txt URL: From juniorfm at kbonet..com.br Thu Nov 21 15:33:55 2002 From: juniorfm at kbonet..com.br (CERTIDƠES) Date: Thu, 21 Nov 2002 18:33:55 -0200 Subject: [SciPy-user] DESCONTINUADOS & OVERSTOCK Message-ID: <20021121204411.2537B3EAE4@www.scipy.com> COMPRAMOS PRODUTOS DESCONTINUADOS,OVERSTOCK, SUCATAS, BIG-BAG'S, MAQUINAS, EQUIPAMENTOS,PRODUTOS QUIMICOS E FARMACEUTICOS,PLASTICOS (PVC,PP,POLIETILENO,POLICARBONATO,ABS E ETC...)METAIS (ALUMINIO COBRE E ETC..) E SUCATAS EM GERAL. VISITE NOSSA PAGINA : http://www.descontinuados-overstock.com.br ATENCIOSAMENTE FRANCISCO 11- 65115217 / 8 /5335 From eric at enthought.com Thu Nov 21 16:11:46 2002 From: eric at enthought.com (eric jones) Date: Thu, 21 Nov 2002 15:11:46 -0600 Subject: [SciPy-user] plt.plot and other wxPython stuff In-Reply-To: <20021121140038.085f3b98.sugino@brandeis.edu> Message-ID: <000001c291a2$9c666180$8901a8c0@ERICDESKTOP> > Hi all, > > Douglas Eck wrote: > > plt.plot is the best all-purpose > > scientific plotting code around right now for python. > > I agreee with Douglas. I've been using scipy mostly for its plt package > for > a couple of months now and I feel it is the most "practical" interactive > plotting package for python. I use line plotting and image display most > frequently and there just isn't other good packages which can handle both. > > But scipy/plt is still not satisfactory: > - it doesn't handle nan/inf in an appropriate way, (like matlab or R > does) > - its image zooming is slow and memory demanding (once killed my linux > box) > > Those were making scipy/plt a little bit "impractical", so I did some > modifications, which I attached to this email. I hope someone maintaining > plt package will look at them and either incorporate or reimplement them. Thanks. These sound like nice additions. I'll take a look. > P.S. Is there anyone planning to implement multiple plots in a window for > plt package? "subplot" in matlab is good enough for me, but R's layout > function is really flexible and seems to be a good model to imitate. Chaco already handles this and quite a bit of other stuff (including NaN support). It is extremely flexible also, allowing for arbitrary nesting of plot groups. Chaco will become the replacement for plt at some point (probably SciPy 0.3). In the mean time, we'll try to update plt with features like yours. eric From perry at stsci.edu Thu Nov 21 17:34:06 2002 From: perry at stsci.edu (Perry Greenfield) Date: Thu, 21 Nov 2002 17:34:06 -0500 Subject: [SciPy-user] FW: Vector orientation (pedantry?) Message-ID: Since Stephen was unable to post this directly, he asked me to do so for him -- Perry -----Original Message----- From: Stephen Walton [mailto:stephen.walton at csun.edu] Sent: Thursday, November 21, 2002 2:02 PM To: scipy-user at scipy.net Subject: Vector orientation (pedantry?) This is probably a historical thing but I had to ask. MATLAB distinguishes between row and column vectors, so that the inner (dot) and outer products are a simple matter of switching the order of multiplication. Numeric forces one to use outerproduct(); matrixmultiply() always returns the inner product of two vectors whether they are row, column, or a mixture. MATLAB is mathematically correct, in my opinion. How much pain would it cause for matrixmultiply() to return the inner product for a row times a column vector and the outer product for a column times a row and get rid of outerproduct() altogether? Along the same lines, shouldn't transpose() applied to a row vector yield a column vector and vice versa? Don't shout at me---I'm just asking :-) -- Stephen Walton, Professor, Dept. of Physics & Astronomy, Cal State Northridge stephen.walton at csun.edu From dmorrill at enthought.com Thu Nov 21 18:26:20 2002 From: dmorrill at enthought.com (David C. Morrill) Date: Thu, 21 Nov 2002 17:26:20 -0600 Subject: [SciPy-user] Tkinter/OpenGL version of Chaco/Kiva status follow-up Message-ID: <009501c291b5$65f77720$6501a8c0@Dave> I just wanted to update everyone on the results of my recent request for help... With the kind help of both Perry Greenfield and especially Greg Couch, I have been able to resolve all of the major performance bottlenecks in the Tkinter/OpenGL Chaco/Kiva code. Yeah! The net result is that the OpenGL version now performs comparably to the wxPython version. While neither version is as fast as we (and users) would like, we think we know how to go after the remaining performance issues. However, we will probably wait until the code has matured a little more before doing any further optimization work. I just wanted to thank Perry and Greg for helping me with some nuances of OpenGL that had eluded and baffled me previously. Thanks a lot guys!!! Dave Morrill From motocng at cq114.com.cn Thu Nov 21 19:40:36 2002 From: motocng at cq114.com.cn (Ms.huang) Date: Fri, 22 Nov 2002 08:40:36 +0800 Subject: [SciPy-user] China Motorcycle Message-ID: <20021122004933.914C13EAE4@www.scipy.com> Dear Sir We fetch your name through our internet. Last month, Our Group ( Chongqing Yingxiang motorcycle group Co.Ltd)'s breach company had set up one JV with Korean Hyosung Motors & Machinery Inc Our Group manufacture and distributes various whole motorcycle units (displacement ranging from 48cc to 250cc, including two-wheel motorcycle three-wheel motorcycle and four-wheel motorcycle, for carrying goods and taking passengers) and accessories especially main accessories of motorcycle, such as engine (including crankcase, crankshaft connecting rod, carburetor, engine cylinder head, cylinder body, clutch, piston and piston rings), frame, fuel tank, shock absorber, disk brake, panels, wheel hub and so on. So far, they have sold very well to markets in many countries and areas around Asia, Africa and Latin America, meanwhile, we establish service spots and sub-factories around there. We would now like to market the motorcycles and spare parts directly in your country. We would appreciate your advise on whether your company would be interested in acting as a distributor in the your country or if you have any recommendations on any other your country??s associates who might also be interested. For further information about our products, kindly please visit our web page: http://www.cq114.com.cn/English/production/jiaotongys/moto/motozhanshi/YX/YX50QT-2.htm We look forward to your reply. Yours sincerely, Huang(Ms.Sales Manager) Fax: 86-23-67732102 E-mail: motocng at cq114.com.cn a67747005 at cta.cq.cn From andrew.straw at adelaide.edu.au Fri Nov 22 00:10:26 2002 From: andrew.straw at adelaide.edu.au (Andrew Straw) Date: Fri, 22 Nov 2002 15:40:26 +1030 Subject: [SciPy-user] building SciPy on Mac OS X Message-ID: Hi, I'm trying to install SciPy on my Mac OS X 10.2.2 box. After following INSTALL.txt to install the prerequisites, I run "python setup.py build" which fails at the following command: cc -Wl,-F. -Wl,-flat_namespace,-U,_environ -bundle -framework Python build/temp.darwin-6.2-Power_Macintosh-2.2/fortranobject.o build/temp.darwin-6.2-Power_Macintosh-2.2/fblasmodule.o -L/usr/local/lib/atlas -Lbuild/temp.darwin-6.2-Power_Macintosh-2.2 -Lbuild/temp.darwin-6.2-Power_Macintosh-2.2 -lfblas -llapack -lf77blas -lcblas -latlas -lc_misc -lcephes -lrootfind -lg2c -o build/lib.darwin-6.2-Power_Macintosh-2.2/scipy/linalg/fblas.so ld: Undefined symbols: _atl_f77wrap_caxpy__ _atl_f77wrap_ccopy__ _atl_f77wrap_cgemm__ _atl_f77wrap_cgemv__ _atl_f77wrap_chemv__ _atl_f77wrap_crotg__ _atl_f77wrap_cscal__ _atl_f77wrap_csscal__ _atl_f77wrap_cswap__ ... snip ... I don't know where those symbols are (or should be defined), nor am I a library file expert-- does anyone know where these symbols are defined and how I can get SciPy to build? Perhaps the errors above are related to the following: I used the instructions in INSTALL.txt to compile LAPACK and ATLAS, including the usage of "ar" to create an ATLAS optimized LAPACK library, which I placed in /usr/local/lib/atlas/. If I run ranlib on this liblapack.a I get the following errors. The names of the objects seem to be intriguingly similar but not identical to the undefined symbols above. $ ranlib /usr/local/lib/atlas/liblapack.a ranlib: same symbol defined in more than one member in: /usr/local/lib/atlas/liblapack.a (table of contents will not be sorted) ranlib: file: /usr/local/lib/atlas/liblapack.a(ATL_f77wrap_sgesv.o) defines symbol: _F77WRAP_GESV ranlib: file: /usr/local/lib/atlas/liblapack.a(ATL_f77wrap_cgesv.o) defines symbol: _F77WRAP_GESV ranlib: file: /usr/local/lib/atlas/liblapack.a(ATL_f77wrap_dgesv.o) defines symbol: _F77WRAP_GESV ranlib: file: /usr/local/lib/atlas/liblapack.a(ATL_f77wrap_zgesv.o) defines symbol: _F77WRAP_GESV ... snip ... Any help would be greatly appreciated! Thanks, Andrew From bryan.cole at teraview.co.uk Fri Nov 22 06:21:37 2002 From: bryan.cole at teraview.co.uk (bryan cole) Date: 22 Nov 2002 11:21:37 +0000 Subject: [SciPy-user] chaco fonts and other issues In-Reply-To: <000001c291a2$9c666180$8901a8c0@ERICDESKTOP> References: <000001c291a2$9c666180$8901a8c0@ERICDESKTOP> Message-ID: <1037964096.8389.33.camel@bryan.teraviewhq.local> Hi all, Chaco is looking increasingly exciting! but... I just installed the latest tar-ball from the website (0.1.0-alpha-5.379) and the setup.py fails with "import error: module chaco_version not found". Presumably there's a file missing from this distribution. Removing the chaco_version import line and the reference later on works around this. I've just upgraded my machine to RH8.0 and now (after recompiling scipy, chaco etc.) the wxdemo_plot.py runs but none of the plot labels or titles are displayed correctly, irrespective of which font I select (ttf or type1). This is the case for the latest chaco version (0.1.0-alpha-5.379) and also for a slightly earlier version of 0.1.0. Before upgrading to RH8.0, the earlier v0.1.0 seemed to work fine. Screenshot of demo attached. Note, the text in the chaco dialog boxes/button displays fine etc., as does text in my other wxPython applications. One final problem, I had scipy installed and runnnig OK prior to installing chaco. Installed chaco messes up the scipy fastumath module and now scipy fails on import with: ImportError: No module named fastumath. Re-installing SciPy fixes this. Besides RH8.0, I'm using python2.2.1, scipy-0.2.0-alpha-102.3553, Numeric-22.0 cheers, Bryan -- Bryan Cole Teraview Ltd., 302-304 Cambridge Science Park, Milton Road, Cambridge CB4 0WG, United Kingdom. tel: +44 (1223) 435380 / 435386 (direct-dial) fax: +44 (1223) 435382 -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot.png Type: image/png Size: 31906 bytes Desc: not available URL: From dmorrill at enthought.com Fri Nov 22 16:10:30 2002 From: dmorrill at enthought.com (David C. Morrill) Date: Fri, 22 Nov 2002 15:10:30 -0600 Subject: [SciPy-user] chaco fonts and other issues References: <000001c291a2$9c666180$8901a8c0@ERICDESKTOP> <1037964096.8389.33.camel@bryan.teraviewhq.local> Message-ID: <00bc01c2926b$96c739b0$6501a8c0@Dave> > I just installed the latest tar-ball from the website > (0.1.0-alpha-5.379) and the setup.py fails with "import error: module > chaco_version not found". Presumably there's a file missing from this > distribution. Removing the chaco_version import line and the reference > later on works around this. Yes, we'll have to update the build process I suspect. Thanks for pointing it out. > I've just upgraded my machine to RH8.0 and now (after recompiling scipy, > chaco etc.) the wxdemo_plot.py runs but none of the plot labels or > titles are displayed correctly, irrespective of which font I select (ttf > or type1). This is the case for the latest chaco version > (0.1.0-alpha-5.379) and also for a slightly earlier version of 0.1.0. > Before upgrading to RH8.0, the earlier v0.1.0 seemed to work fine. > Screenshot of demo attached. We have a machine running RH 8.0 here. I'll see if I can reproduce the problem. > One final problem, I had scipy installed and runnnig OK prior to > installing chaco. Installed chaco messes up the scipy fastumath module > and now scipy fails on import with: ImportError: No module named > fastumath. Re-installing SciPy fixes this. > > Besides RH8.0, I'm using python2.2.1, scipy-0.2.0-alpha-102.3553, > Numeric-22.0 Hmmm...I'll have to look into that. It probably has something to do with the package structure. Dave Morrill From a.schmolck at gmx.net Fri Nov 22 17:11:41 2002 From: a.schmolck at gmx.net (Alexander Schmolck) Date: 22 Nov 2002 22:11:41 +0000 Subject: [SciPy-user] FW: Vector orientation (pedantry?) In-Reply-To: References: Message-ID: "Perry Greenfield" writes: > Since Stephen was unable to post this directly, he asked me > to do so for him -- Perry > > -----Original Message----- > From: Stephen Walton [mailto:stephen.walton at csun.edu] > Sent: Thursday, November 21, 2002 2:02 PM > To: scipy-user at scipy.net > Subject: Vector orientation (pedantry?) > > > This is probably a historical thing but I had to ask. MATLAB > distinguishes between row and column vectors, so that the inner (dot) > and outer products are a simple matter of switching the order of > multiplication. Numeric forces one to use outerproduct(); > matrixmultiply() always returns the inner product of two vectors whether > they are row, column, or a mixture. OK, either I completely misunderstand you (in which case I apologize, I'm a bit tired) or maybe you are just mistaken in your assumptions : (using Numeric 22) >>> from Numeric import * >>> # col. vec # row vec. >>> dot([[1],[2],[3]], [[1,2,3]]) array([[1, 2, 3], [2, 4, 6], [3, 6, 9]]) >>> matrixmultiply([[1],[2],[3]], [[1,2,3]]) array([[1, 2, 3], [2, 4, 6], [3, 6, 9]]) Well, note that a row and column vector is nothing more than a 1xN or a Nx1 array (as opposed to a what I'd call a 'flat' N-array). That matlab only has matrices and not arrays of different array-rank is more of a bug than a feature. However, I also felt that doing Linear Algebra in Numeric is often quite awkward, so I wrote a matrix class for that is much more functional for that purpose (and than Matrix.py in Numeric), IMHO. I'm going to release it as open source soon, but if you're interested I could send you the code now. cheers, alex From steven.robbins at videotron.ca Fri Nov 22 22:52:17 2002 From: steven.robbins at videotron.ca (Steve M. Robbins) Date: Fri, 22 Nov 2002 22:52:17 -0500 Subject: [SciPy-user] Debian package(s) -- preliminary In-Reply-To: <200211201129.21109.Ralf_Ahlbrink@web.de> References: <200211201129.21109.Ralf_Ahlbrink@web.de> Message-ID: <20021123035217.GL5715@riemann.nyongwa.montreal.qc.ca> On Wed, Nov 20, 2002 at 11:29:21AM +0100, RA wrote: > See: > http://www.scipy.org/Members/RalfA/packages/Debian-woody-DEB/ Hi Ralph, I've just downloaded the diff files and am building packages against current CVS sources of SciPy and F2PY. The immediate problem I've run into is in the build-depends line: dpkg-checkbuilddeps: Unmet build dependencies: python-dev (<< 2.2) I don't understand how you can build python2.2-* packages with this in the build-depends line. (?) There are a number of other things that don't match the Debian python policy or that lintian complains about. I've corrected all these for scipy-core, and it now builds lintian-free packages. I'm starting on F2PY now. So now what shall I do with the corrected packages? The URL above suggests that your packages are intended for woody. Is that true? My modified source packaging is targeted at Debian "unstable" (aka sid), as it must be in order to upload to Debian. Do you want the changed diff to put on the scipy.org site? Does Joe Reinhardt want to coordinate this? Shall I just upload them to Debian myself? (Personally, I'd rather not be "the" Debian maintainer for these packages, but I'm willing to help out from time to time.) -Steve From sugino at brandeis.edu Sat Nov 23 10:35:29 2002 From: sugino at brandeis.edu (Ken Sugino) Date: Sat, 23 Nov 2002 10:35:29 -0500 Subject: [SciPy-user] plt.plot and other wxPython stuff In-Reply-To: <000001c291a2$9c666180$8901a8c0@ERICDESKTOP> References: <20021121140038.085f3b98.sugino@brandeis.edu> <000001c291a2$9c666180$8901a8c0@ERICDESKTOP> Message-ID: <20021123103529.0238b170.sugino@brandeis.edu> Hi, > - its image zooming is slow and memory demanding (once killed my linux > box) > > Those were making scipy/plt a little bit "impractical", so I did some > modifications, which I attached to this email. I hope someone maintaining > plt package will look at them and either incorporate or reimplement them. > > Thanks. These sound like nice additions. I'll take a look. > I noticed the modification for image drawing didn't redraw properly with multiple windows. Attached is the new version. > Chaco already handles this and quite a bit of other stuff (including NaN > support). It is extremely flexible also, allowing for arbitrary nesting > of plot groups. Chaco will become the replacement for plt at some point > (probably SciPy 0.3). In the mean time, we'll try to update plt with > features like yours. > > eric > I tried chaco, but in current states, it's too slow and unstable for daily use. I hope it will become fast and stable pretty soon :) Ken -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: image_object.draw.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: plot_objects.py.patch Type: application/octet-stream Size: 8141 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: interface.py.patch Type: application/octet-stream Size: 4832 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wxplt.py.patch Type: application/octet-stream Size: 1088 bytes Desc: not available URL: From Ralf_Ahlbrink at web.de Sun Nov 24 12:33:06 2002 From: Ralf_Ahlbrink at web.de (RA) Date: Sun, 24 Nov 2002 18:33:06 +0100 Subject: [SciPy-user] Debian package(s) -- preliminary In-Reply-To: <20021123035217.GL5715@riemann.nyongwa.montreal.qc.ca> References: <200211201129.21109.Ralf_Ahlbrink@web.de> <20021123035217.GL5715@riemann.nyongwa.montreal.qc.ca> Message-ID: <200211241833.06820.Ralf_Ahlbrink@web.de> On Samstag, 23. November 2002 04:52:04, Steve M. Robbins wrote: > On Wed, Nov 20, 2002 at 11:29:21AM +0100, RA wrote: > > See: > > http://www.scipy.org/Members/RalfA/packages/Debian-woody-DEB/ > > Hi Ralph, > > I've just downloaded the diff files and am building packages against > current CVS sources of SciPy and F2PY. > > The immediate problem I've run into is in the build-depends line: > > dpkg-checkbuilddeps: Unmet build dependencies: python-dev (<< 2.2) > > I don't understand how you can build python2.2-* packages with > this in the build-depends line. (?) I've installed both, the standard 'python' in _woody_ (2.1), and python2.2. The build dependencies are like you can find e.g. for python-numeric for _woody_. > > There are a number of other things that don't match the Debian python > policy or that lintian complains about. I've corrected all these for > scipy-core, and it now builds lintian-free packages. I'm starting on > F2PY now. My experiences with debian packaging is limited, I just made (or updated) only a few debs for my own use. So, I'm happy about feedback. > > So now what shall I do with the corrected packages? The URL above > suggests that your packages are intended for woody. Is that true? My > modified source packaging is targeted at Debian "unstable" (aka sid), > as it must be in order to upload to Debian. Do you want the changed > diff to put on the scipy.org site? Does Joe Reinhardt want to > coordinate this? Shall I just upload them to Debian myself? > (Personally, I'd rather not be "the" Debian maintainer for these > packages, but I'm willing to help out from time to time.) Yes, you're right, it was intended for woody. And at the moment, I'm using only the stable tree. You're right: it should be definitely included in sid. But I also believe that scipy vers. 0.2 will be released soon. So, it's worthwile to provide woody packages on scipy.org, too. Moreover, the differences between these two diff's probably only affect some python version numbers, do they? Regarding the procedure, I'm not sure. It would be fine, if you can provide me the changed diff's, so that I can use them for packages tested on woody. And you or Joe can upload the corresponding versions for sid. Ralf. > > -Steve > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user From steven.robbins at videotron.ca Sun Nov 24 22:59:09 2002 From: steven.robbins at videotron.ca (Steve M. Robbins) Date: Sun, 24 Nov 2002 22:59:09 -0500 Subject: [SciPy-user] Debian package(s) -- preliminary In-Reply-To: <200211241833.06820.Ralf_Ahlbrink@web.de> References: <200211201129.21109.Ralf_Ahlbrink@web.de> <20021123035217.GL5715@riemann.nyongwa.montreal.qc.ca> <200211241833.06820.Ralf_Ahlbrink@web.de> Message-ID: <20021125035908.GA11579@riemann.nyongwa.montreal.qc.ca> On Sun, Nov 24, 2002 at 06:33:06PM +0100, RA wrote: > On Samstag, 23. November 2002 04:52:04, Steve M. Robbins wrote: > > On Wed, Nov 20, 2002 at 11:29:21AM +0100, RA wrote: > > > See: > > > http://www.scipy.org/Members/RalfA/packages/Debian-woody-DEB/ > > > > Hi Ralph, > > > > I've just downloaded the diff files and am building packages against > > current CVS sources of SciPy and F2PY. > > > > The immediate problem I've run into is in the build-depends line: > > > > dpkg-checkbuilddeps: Unmet build dependencies: python-dev (<< 2.2) > > > > I don't understand how you can build python2.2-* packages with > > this in the build-depends line. (?) > > I've installed both, the standard 'python' in _woody_ (2.1), and python2.2. Yeah, but if you install python-dev from python 2.2 (as I have), the build fails. There is now a python policy that suggests how python modules should be packaged. Briefly, one builds three packages: python2.1-f2py, python2.2-f2py, and python-f2py. The last is an empty package that just depends on the package for the default version of python. > Yes, you're right, it was intended for woody. And at the moment, I'm > using only the stable tree. You're right: it should be definitely > included in sid. But I also believe that scipy vers. 0.2 will be > released soon. So, it's worthwile to provide woody packages on > scipy.org, too. Moreover, the differences between these two diff's > probably only affect some python version numbers, do they? I've put revised packages up at http://people.debian.org/~smr/scipy and .../~smr/f2py. The scipy-core and f2py packages are purely python, so they are installable directly on a woody system. The main scipy packages need rebuilding on a woody system, because they depend on the newer C library package, for example. -Steve From gutmann at mpip-mainz.mpg.de Mon Nov 25 12:14:47 2002 From: gutmann at mpip-mainz.mpg.de (Jochen Gutmann) Date: Mon, 25 Nov 2002 18:14:47 +0100 Subject: [SciPy-user] Problems compiling SciPy from the CVS Message-ID: <200211251814.48231.gutmann@mpip-mainz.mpg.de> Hi, I tried to compile SciPy frim the CVS on a Linux System running Suse Linux 8.0. After a sucessfull build I get the following error when I try to import SciPy. >>> import scipy Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/site-packages/scipy/__init__.py", line 49, in ? import special, io, linalg, stats, fftpack File "/usr/lib/python2.2/site-packages/scipy/fftpack/__init__.py", line 55, in ? from pseudo_diffs import * File "/usr/lib/python2.2/site-packages/scipy/fftpack/pseudo_diffs.py", line 12, in ? import convolve ImportError: /usr/lib/python2.2/site-packages/scipy/fftpack/convolve.so: undefined symbol: fftw_gettimeofday_get_time >>> I have FFTW 2.1.3 installed with all test completing sucessfully. Any help is greatly apreciated. Jochen -- Dr. Jochen S. Gutmann Physics Dept. MPI for Polymers Research Ackermannweg 10 55128 Mainz Germany Phone: +49-6131-379117 FAX: Phone: +49-6131-379100 E-Mail: gutmann at mpip-mainz.mpg.de From stephen.walton at csun.edu Mon Nov 25 12:14:47 2002 From: stephen.walton at csun.edu (Stephen Walton) Date: 25 Nov 2002 09:14:47 -0800 Subject: [SciPy-user] FW: Vector orientation (pedantry?) In-Reply-To: References: Message-ID: <1038244487.28319.66.camel@hector> I think we're still blacklisted so the list won't see this. On Fri, 2002-11-22 at 14:11, Alexander Schmolck wrote: > OK, either I completely misunderstand you (in which case I apologize, I'm a > bit tired) or maybe you are just mistaken in your assumptions : > > (using Numeric 22) > > >>> from Numeric import * > >>> # col. vec # row vec. > >>> dot([[1],[2],[3]], [[1,2,3]]) > array([[1, 2, 3], > [2, 4, 6], > [3, 6, 9]]) > >>> matrixmultiply([[1],[2],[3]], [[1,2,3]]) > array([[1, 2, 3], > [2, 4, 6], > [3, 6, 9]]) OK, I see what you did. What I had tried in my naivete' was: >>> from Numeric import * >>> dot([1,2,3],[1,2,3]) 14 You also wrote: >Well, note that a row and column vector is nothing more than a 1xN or > Nx1 array (as opposed to a what I'd call a 'flat' N-array). So [1,2,3] denotes a 'flat' 3-array to Numeric, while [[1,2,3]] denotes 1-by-3 array? Not sure I understand the distinction. I agree that SciPy is awkward for linear algebra, but it's mainly syntax in my case. I find typing 'x=[1,2,3;4,5,6;7,8,9]' much more straightforward than 'x=array([[1,2,3],[4,5,6],[7,8,9]]), especially since Python/SciPy doesn't seem to have a 'blink matching brackets' option. -- Stephen Walton, Professor, Dept. of Physics & Astronomy, Cal State Northridge stephen.walton at csun.edu From a.schmolck at gmx.net Mon Nov 25 15:05:39 2002 From: a.schmolck at gmx.net (Alexander Schmolck) Date: 25 Nov 2002 20:05:39 +0000 Subject: [SciPy-user] FW: Vector orientation (pedantry?) In-Reply-To: <1038244487.28319.66.camel@hector> References: <1038244487.28319.66.camel@hector> Message-ID: Stephen Walton writes: > > >Well, note that a row and column vector is nothing more than a 1xN or > > Nx1 array (as opposed to a what I'd call a 'flat' N-array). > > So [1,2,3] denotes a 'flat' 3-array to Numeric, while [[1,2,3]] denotes > 1-by-3 array? Not sure I understand the distinction. I'm not sure how best to explain this (I don't know your background, other than that you are likely to be pretty clued about math), but I'll try: These are not the same: scalar 1x vector 1x1 matrix 1x1x1 array 1x1x1x1 array 1 --> [1] -> [[1]], [[[1]]], [[[[1]]]] etc. because apart from storing the same single numerical value, they have different information about their structure (viz. how many, if any, axes there are). If this doesn't make sense, try indexing these constructs: 1[0] ==> TypeError as it makes no sense to index a number [1][0] ==> 1 [[1]][0] ==> [1] etc. If you have one index, you index through what's enclosed by the outermost pair of '[',']'s, so: [1,2,3][0] (which I could maybe more clearly write as 3 rows: [1, 2, 3][0] ) is 1 and [[1], [2], [3]][0] is [1], wheras [[1,2,3]][0] is [1,2,3] Does that start to make sense now? In matlab everything really is a matrix, so 1 and [1] are really just a shorthand for [[1]], and indexing is a hack. This is neither pretty nor does it scale well. > > I agree that SciPy is awkward for linear algebra, but it's mainly syntax > in my case. I perfectly aggree. I especially find that things like: dot(transpose(X), dot(V, transpose(U))) * x quickly render code completely unreadable. That's why with my matrix class it looks like: X.T ._* (V ._* U.T) * x where the pseudo-operator '._*' is the dot-product. > I find typing 'x=[1,2,3;4,5,6;7,8,9]' much more > straightforward than 'x=array([[1,2,3],[4,5,6],[7,8,9]]), especially > since Python/SciPy doesn't seem to have a 'blink matching brackets' > option. well this: >>> from Numeric import dot, array >>> dot(array([[1],[2],[0.00003]]), array([[1,2,3]])) array([[ 1.00000000e+00, 2.00000000e+00, 3.00000000e+00], [ 2.00000000e+00, 4.00000000e+00, 6.00000000e+00], [ 3.00000000e-05, 6.00000000e-05, 9.00000000e-05]]) would become: >>> from nummat import matrix as mat >>> mat('1;2;0.00003') ._* mat('1,2,3') matrix(''' 1.00000 2.00000 3.00000 2.00000 4.00000 6.00000 0.00003 0.00006 0.00009 ''') I like to think that both input and output are markedly preferable in the second case (and much more so for complicated expressions) :) (displayed above is matlab style formatting, Numeric.array-style formatting is also an option; plus really large matrices don't clutter up the screen by default, e.g.: >>> mat.ones((1000,10000)) <1000 x 10000 matrix of type Int32>) Note that you could also use Matrix.py, which also allows you to write >>> Matrix('1, 2, 3') The main advantages over Matrix.py that already comes with Numeric is that my matrix class is (or at least aims to be) completely compatible with Numeric arrays (i.e. you should be able to use one of my matrix objects anywhere where you would you could use a Numeric array (of array rank-2, of course)), provides much more funcationality (among many other things matlab-style output formatting and good syntax for *both* elementwise and matrixwise operations, plus it can use an optional library that makes dot-products for big matrices 40 times or so faster). There are lots of other features and plenty of test-code, but I've lacked the time to package it up and iron out a few things before I put it on the web. There are also at least two disadvantages, a) it needs at lest python 2.2 and b) there is a bug in Numeric that makes it really slow, but I've got a simple and safe patch that fixes that. As I said, I'll be happy to send interested parties a preview of the code. OK, enough with the shameless advertisment for now :) alex -- Alexander Schmolck Postgraduate Research Student Department of Computer Science University of Exeter A.Schmolck at gmx.net http://www.dcs.ex.ac.uk/people/aschmolc/ From oliphant at ee.byu.edu Mon Nov 25 19:43:18 2002 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Mon, 25 Nov 2002 17:43:18 -0700 (MST) Subject: [SciPy-user] FW: Vector orientation (pedantry?) In-Reply-To: <1038244487.28319.66.camel@hector> Message-ID: > > So [1,2,3] denotes a 'flat' 3-array to Numeric, while [[1,2,3]] denotes > 1-by-3 array? Not sure I understand the distinction. The difference is that [[1,2,3]] is a two-dimensional array while [1,2,3] is a one-dimensional arryay. This rank distinction is convenient for some problems and less convenient for matrix algebra problems. > > I agree that SciPy is awkward for linear algebra, but it's mainly syntax > in my case. I find typing 'x=[1,2,3;4,5,6;7,8,9]' much more > straightforward than 'x=array([[1,2,3],[4,5,6],[7,8,9]]), especially > since Python/SciPy doesn't seem to have a 'blink matching brackets' > option. > There is the option in scipy to use the mat function: >>> mat('[1,2,3;4,5,6]') Matrix([[1,2,3], [4,5,6]]) This allows that kind of notation input and also gives you a real 2-D matrix where * means matrix-multiplication. -Travis Oliphant From eric at enthought.com Tue Nov 26 19:04:24 2002 From: eric at enthought.com (eric jones) Date: Tue, 26 Nov 2002 18:04:24 -0600 Subject: [SciPy-user] anti-grain wrappers -- looking for a volunteer Message-ID: <000001c295a8$8e4b5060$8901a8c0@ERICDESKTOP> Hey group, A few days ago Mark Evans pointed out the anti-grain (http://www.antigrain.com) rendering library. It looks like a very good fit as *the* rendering engine for Kiva/Chaco because: (1) it has a BSD compatible license, (2) it path based, (3) it supports arbitrary affine transforms, anti-aliased drawing, and transparency. It may need some modification for full support of what we need, but it looks like a very solid beginning. Using anti-grain (and freetype for text) as the renderer for Tk, wx, GIF(PIL), and most other backends would provide the same capabilities across all platforms, and make it much easier to port to new platforms. Also, the speed looks to be fine in the demo's I've played with. So, based on this, I'm interested in getting a python wrapped version of anti-grain to play with. I've gotten a trivial example working with weave last Sunday (posted to scipy-dev), but don't have time to attack this with the required effort until Christmas break or after(neither does Dave M.). Does anyone else have time now to give this a crack? I'd be happy to steer anyone interested. For now, I'd be happy with any wrapper, but the final version will need to wrapped with swig, f2py (maybe not possible?), weave, or hand-wrapped. Boost python has a few more requirements that I'm willing to add to the SciPy/Chaco tool chain at the moment (maybe in the future...). Thanks, eric p.s. By the way, we still be keeping native PDF and (maybe) OpenGL backends. Also SVG and PS might be added. Pretty much everything else would be rendered to the anti-grain backend and then blitted into the GUI window. ---------------------------------------------- eric jones 515 Congress Ave www.enthought.com Suite 1614 512 536-1057 Austin, Tx 78701 From prabhu at aero.iitm.ernet.in Tue Nov 26 22:46:59 2002 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Wed, 27 Nov 2002 09:16:59 +0530 Subject: [SciPy-user] anti-grain wrappers -- looking for a volunteer In-Reply-To: <000001c295a8$8e4b5060$8901a8c0@ERICDESKTOP> References: <000001c295a8$8e4b5060$8901a8c0@ERICDESKTOP> Message-ID: <15844.16435.921847.998938@monster.linux.in> >>>>> "EJ" == eric jones writes: EJ> Hey group, A few days ago Mark Evans pointed out the EJ> anti-grain (http://www.antigrain.com) rendering library. It EJ> looks like a very good fit as *the* rendering engine for EJ> Kiva/Chaco because: My only concern is *nix compatibility. The screenshots and site seemed to indicate cross platform capability but everything smelled of windows. I haven't used it but do you anticipate problems with getting it working on non-windows platforms? cheers, prabhu From eric at enthought.com Wed Nov 27 11:50:46 2002 From: eric at enthought.com (eric jones) Date: Wed, 27 Nov 2002 10:50:46 -0600 Subject: [SciPy-user] FW: anti-grain Message-ID: <000101c29635$24bbb670$8901a8c0@ERICDESKTOP> I pinged Maxim Shemarnarev (McSeem) about anti-grain, and he responded with this information. It looks like he is working to make it platform independent, so Prabhu's worries about *nix compatibility should be allayed. We'll definitely make sure any solution chosen will work everywhere (well a hopefully large subset of everywhere...) I look forward to technical discussions with McSeem about rendering and the implementation details of Kiva. It looks like he is very knowledgeable and happy to discuss such things. Regards, eric ---------------------------------------------- eric jones 515 Congress Ave www.enthought.com Suite 1614 512 536-1057 Austin, Tx 78701 > -----Original Message----- > From: Maxim Shemanarev [mailto:mcseem at antigrain.com] > Sent: Tuesday, November 26, 2002 10:17 PM > To: eric jones > Subject: Re: anti-grain > > Thank you Eric! > > I'll be happy if AGG can be included in such a big project, because it > really will be a very good promotion. The project is actually very young, > I > started AGG2 in February this year. I work on it alone, 2 or 3 hours a > day, > after my official job hours. I redesigned the current version of AGG two > times and I'm constantly working on new algorithms. > Maybe it'll be interesting if I tell you a brief story. > > AGG was started in 1998 and at that time it was a simple task to write a > plug-in for Macromedia Director that would rotate an image with high > quality > filtering. I solved this task, and there was only a very simple linear > filtering method. You could apply arbitrary affine transformations to the > images, and you could transform a part of the image of any shape. The only > problem was to anti-alias the edges of the image, i.e. the transformed > image > itself was perfectly anti-aliased, but it still had very bad stair-looking > edges. I developed an algorithm for drawing anti-alised line segments. > That > algorithm had perfect line joins (which was the most difficult part of the > job). You can see my ancient demos here: http://antigrain.hypermart.net/ > (sorry about that pop-up windows). > After that I had to abandon the project because of my personal reasons. > After almost 3 years I started again from scratch. There were just some > experiments, called AGG-1 (http://sourceforge.net/projects/vector-agg/ > download agg-1.2.2-beta). It was started in October 2001 and released in > December, 2001. There were just experiments basically with drawing > anti-aliased lines. The lines had incorrect joins but most of all, that > algorithm couldn't draw correctly very small primitives - they had nasty > looking defects. > Then I found FreeType and its nice rasterizer. AGG2 uses the same idea. > David Turner generously gave me permission to use it in my library (the > code > was completely redesigned and improved). It's free of those problems of > drawing very small primitives: http://www.antigrain.com/mol_view.zip (one > of > the latest demo examples) - just drag with the left button pressed to > rotate > and scale the molecule. Also, press PgUp/PgDown to switch between > different > molecules. So, David's algorithm is perfect! It operates only with > polygons, > not lines. If you need to draw a line segment, you have to calculate its 4 > outline vertices (so called path-based approach). > > Then I had to change my primary job and study a lot of organic chemistry > stuff. And only in February this year I started again from scratch, on the > basis of David's algorithm. All this time I've been mostly working on the > design of the library. I did't (and don't) want to use that approach when > you have a class like "Graphics" with hundreds of functions. I wanted to > create something more flexible. So, AGG now (it's actually called AGG2) is > a > number of independent class templates that you can combine somehow in > order > to create a custom graphical pipeline. It even doesn't restrict you with > the > colorspace (well, for now only RGB is implemented). But the flexibility > usually means difficulties in use, that's the rule. AGG now is not an > "end-user" library, it looks more likely a "tool for creating other > tools". > Here is a very simple example: http://www.antigrain.com/img/conv_order.gif > Usually you can't control the order of the conversion steps, especially if > you have a library like GDI+. With AGG you can do that, but the price is > you > usually have to write a number of very complex nested template > declarations. > Still, the pipeline can be organized as a number of polymorphic classes, > but > there will be one virtuall call per vertex on each step, while in case of > templates everything can be easily inlined without any explicit calls! > Then. Arbitrary affine transformations? Phew - that's the easiest pipeline > converter, at least the converters that calculate the outline, or > Bezier-curve converters are much more complicated. > > In August 2002 I finally came back to my favorite topic, image > transformations. The demo is here: > http://www.antigrain.com/image_filters.zip > I combined the path-based approach with images, in other words you can > transform an arbitrary part of the image and the quality of the edges of > your image polygon will be as good as if you rendered a regular solid > polygon. > > I spent some time to design classes for creating examples in Windows and > Linux (just in order to prove the concept of platform independency). So, I > had to study Win32 API and X11. That was tough, because I hate APIs, I > like > algorithms :-). But now I'm proud that I can provide examples for Windows, > for any Unix with basic X11, for MacOS, and for OS X (Carbon API). The > latest is not ready yet, but coming soon (A guy from Prague wrote the > platform specific .cpp file for Mac). > > Recently the problem of drawing single lines has arisen again. The thing > is > my old AGG-1 algorithm draws lines 3-5 times faster than the path-based > David Turner's algorithm. That's worth the efforts to work on it, > especially > considering potential applications of AGG in GIS. I have finally solved > the > problem of line joins (phew!) and I'm working on a good implemantation. > Besides, Hansruedi (he's that very guy from Prague) gave me a very good > idea > of drawing lines decorated with arbitrary image patterns: > http://www.antigrain.com/line_patterns.gif > AFAIU it's very actual for Geographic Information Systems (GIS) and can be > used in any engineering and scientific applications. > > The conclusion is I'll be glad to have a cooperation with your group. AGG > is > designed as a multi-purpose and multi-platform library. My minimal > objectives are to earn some good reputation. There's still no single line > of > docs and I'm terribly sorry about that, but I'll be glad to help you with > some comments and examples because your questions also will help me to > write > some docs. And I hope you'll give me some new ideas to work on. That's the > deal :-). > > The latest snapshot is here: http://www.antigrain.com/agg2.zip > Also, there's a public CVS repository: > http://sourceforge.net/cvs/?group_id=42020 > > Please feel free to ask me any qustions and to forward this message to > your > group. > > McSeem > > > > > ----- Original Message ----- > From: "eric jones" > To: > Sent: Tuesday, November 26, 2002 7:08 PM > Subject: anti-grain > > > > Hey Maxim, > > > > I just had a chance to play with anti-grain, and it looks like it might > > be a really good fit for our chaco scientific plotting project for > > Python. It is part of the SciPy (www.scipy.org) tool suite (or will > > be). Chaco implements a DisplayPDF backend for a lot of different APIs > > (Tk, wxPython, PDF, OpenGL, etc.) A single anti-grain backend would > > supplant multiple of these easing the project development and providing > > the desired capabilities across all GUIs. > > > > I'm running home now, so I can't write more. I just wanted to let you > > know that a reasonably large community is potentially interested in > > making your tool one of its main underpinnings. > > > > I hope to have more productive discussions in the future. > > > > See ya, > > eric > > > > ---------------------------------------------- > > eric jones 515 Congress Ave > > www.enthought.com Suite 1614 > > 512 536-1057 Austin, Tx 78701 > > > > > > > > > > > > From chris at fonnesbeck.org Wed Nov 27 12:06:32 2002 From: chris at fonnesbeck.org (Christopher Fonnesbeck) Date: 27 Nov 2002 12:06:32 -0500 Subject: [SciPy-user] weave build problems Message-ID: <1038416792.1259.21.camel@localhost> I am trying to build the cvs weave on my machine, but get the following error: root at markov:/usr/src/weave# python setup.py build dep: ['scipy_distutils', 'scipy_test', 'scipy_base'] Traceback (most recent call last): File "setup.py", line 44, in ? stand_alone_package(with_dependencies) File "setup.py", line 23, in stand_alone_package config_dict = package_config(primary,dependencies) File "/usr/lib/python2.2/site-packages/scipy_distutils/misc_util.py", line 269, in package_config config.extend([get_package_config(x) for x in dependencies]) File "/usr/lib/python2.2/site-packages/scipy_distutils/misc_util.py", line 255, in get_package_config mod = __import__('setup_'+package_name) ImportError: No module named setup_scipy_distutils However, looking in /usr/lib/python2.2/site-packages/scipy_distutils I see that setup_scipy_distutils.py is there. How can it see misc_util.py, and not setup_scipy_distutils.py when they are in the same directory? Thanks, Chris Fonnesbeck -- Christopher J. Fonnesbeck GA Coop. Fish & Wildlife Research Unit chris at fonnesbeck.org University of Georgia From DavidA at ActiveState.com Wed Nov 27 13:00:47 2002 From: DavidA at ActiveState.com (David Ascher) Date: Wed, 27 Nov 2002 10:00:47 -0800 Subject: [SciPy-user] FW: anti-grain In-Reply-To: <000101c29635$24bbb670$8901a8c0@ERICDESKTOP> References: <000101c29635$24bbb670$8901a8c0@ERICDESKTOP> Message-ID: <3DE5084F.2030105@ActiveState.com> From where I'm sitting, anti-grain sounds like a great bitmap backend rendering engine. I would _strongly_ encourage you to keep vector rendering in mind though, if the goal of making production-quality output is still something you're aiming for. PDF is a great start, but embedding PDF in documents is still a black art. Long-term, SVG will hopefully get broader support as a format that can be used for a variety of media, from printing presses to cellphones =). Cheers, --david From DavidA at ActiveState.com Wed Nov 27 13:00:47 2002 From: DavidA at ActiveState.com (David Ascher) Date: Wed, 27 Nov 2002 10:00:47 -0800 Subject: [SciPy-user] FW: anti-grain In-Reply-To: <000101c29635$24bbb670$8901a8c0@ERICDESKTOP> References: <000101c29635$24bbb670$8901a8c0@ERICDESKTOP> Message-ID: <3DE5084F.2030105@ActiveState.com> From where I'm sitting, anti-grain sounds like a great bitmap backend rendering engine. I would _strongly_ encourage you to keep vector rendering in mind though, if the goal of making production-quality output is still something you're aiming for. PDF is a great start, but embedding PDF in documents is still a black art. Long-term, SVG will hopefully get broader support as a format that can be used for a variety of media, from printing presses to cellphones =). Cheers, --david From pearu at cens.ioc.ee Wed Nov 27 13:42:19 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Wed, 27 Nov 2002 20:42:19 +0200 (EET) Subject: [SciPy-user] weave build problems In-Reply-To: <1038416792.1259.21.camel@localhost> Message-ID: On 27 Nov 2002, Christopher Fonnesbeck wrote: > I am trying to build the cvs weave on my machine, but get the following > error: > > root at markov:/usr/src/weave# python setup.py build > dep: ['scipy_distutils', 'scipy_test', 'scipy_base'] > Traceback (most recent call last): > File "setup.py", line 44, in ? > stand_alone_package(with_dependencies) > File "setup.py", line 23, in stand_alone_package > config_dict = package_config(primary,dependencies) > File "/usr/lib/python2.2/site-packages/scipy_distutils/misc_util.py", > line 269, in package_config > config.extend([get_package_config(x) for x in dependencies]) > File "/usr/lib/python2.2/site-packages/scipy_distutils/misc_util.py", > line 255, in get_package_config > mod = __import__('setup_'+package_name) > ImportError: No module named setup_scipy_distutils > > However, looking in /usr/lib/python2.2/site-packages/scipy_distutils I > see that setup_scipy_distutils.py is there. How can it see misc_util.py, > and not setup_scipy_distutils.py when they are in the same directory? get_package_config looks for setup_scipy_distutils module in ../scipy_distutils, in your case in /usr/src/scipy_distutils. It seems that /usr/src/scipy_distutils does not exist. Since you have scipy_distutils already installed, you can either use python setup_weave.py build or python setup.py build --without-dependencies Eric: Have you already thought about removing setup.py in favor of setup_weave.py? When distributing f2py or weave or chaco separately, they tend to have very similar issues with respect to depending on scipy_distutils, scipy_tests, etc. Recent f2py from its CVS has a possible solution for solving such dependency issues. Basically, when I create a f2py tar-ball, its dependencies, currently scipy_distutils only, are downloaded to the f2py2e directory other/ (in your case, since weave lives in scipy CVS, you can just copy it from the parent directory, of course). And when users install f2py, its setup script checks what is the existing version of scipy_distutils. If it is too 'old' or does not exist, then other/scipy_distutils/ will be installed. Otherwise, just the f2py2e package is installed. It seems that weave could also use a similar approach. If you have better ideas, let me know, I'll try them out. Pearu From DavidA at ActiveState.com Thu Nov 28 20:14:02 2002 From: DavidA at ActiveState.com (David Ascher) Date: Thu, 28 Nov 2002 17:14:02 -0800 Subject: [SciPy-user] Scatter plots Message-ID: <3DE6BF5A.3000603@ActiveState.com> I see no support in kiva or chaco for scatter plots or markers in general. It seems that 'circle', 'dot' etc. are defined, but never used. In general, I'm not clear on how one defines new kinds of plots beyond the base line plots -- say I wanted to do a histogram, for example... What are the plans w.r.t such things, and how can I help? --david PS: In addition to the PIL backend I sent yesterday, I now have an SVG backend mostly ready, modulo a few nasty issues. Let me know if you're interested. From eric at enthought.com Fri Nov 29 12:58:30 2002 From: eric at enthought.com (eric jones) Date: Fri, 29 Nov 2002 11:58:30 -0600 Subject: [SciPy-user] FW: anti-grain In-Reply-To: <3DE5084F.2030105@ActiveState.com> Message-ID: <001401c297d0$ed67a6a0$8901a8c0@ERICDESKTOP> > > From where I'm sitting, anti-grain sounds like a great bitmap backend > rendering engine. I would _strongly_ encourage you to keep vector > rendering in mind> though, if the goal of making production-quality > output is still something you're aiming for. PDF is a great start, but > embedding PDF in documents is still a black art. Long-term, SVG will > hopefully get broader support as a > format that can be used for a variety of media, from printing presses to > cellphones =). Right. The Kiva API is DisplayPDF and therefore vector based. That won't change. The PDF backend will definitely stay, and I would like to see PS/EPS and SVG backends built (thanks for the PIL backend Dave). I have visions of compositing Kiva images with OpenGL 3D rendered images, so the OpenGL backend might be a good one to keep around also. But, instead of making a full blown wx, tkInter, Qt, gtk, PIL, etc. backend for rendering to the screen (bitmap) that is based on the drawing commands of the individual toolkits, it would be much easier to write one anti-grain renderer to a Numeric array or maybe some special image structure. Building a new Kiva backend is then as simple as learning how to blit this thing into the screen for a new toolkit. The GUI interaction portion of Chaco might be significantly refactored when we go down this road also to make porting that part of Chaco much easier also. It may not even be any better to keep a OpenGL version around since we can blit anti-grain images into it just as easily as other APIs. I guess this decision will depend on speed. The only potential downside that I see is if anti-grain is slower at drawing than the GUI toolkits. Anti-grain looked plenty fast to me in the demos I have looked at -- it looked just as fast as GDI+ (windows new path based rendering API), but we'll just have to wait and see on this one. regards, eric From DavidA at ActiveState.com Fri Nov 29 13:33:18 2002 From: DavidA at ActiveState.com (David Ascher) Date: Fri, 29 Nov 2002 10:33:18 -0800 Subject: [SciPy-user] FW: anti-grain In-Reply-To: <001401c297d0$ed67a6a0$8901a8c0@ERICDESKTOP> References: <001401c297d0$ed67a6a0$8901a8c0@ERICDESKTOP> Message-ID: <3DE7B2EE.5040103@ActiveState.com> eric jones wrote: > Right. The Kiva API is DisplayPDF and therefore vector based. That > won't change. The PDF backend will definitely stay, and I would like to > see PS/EPS and SVG backends built (thanks for the PIL backend Dave). The SVG backend is most of the way there, and PS/EPS will be easy -- I may get to them over the weekend. PS/EPS and SVG all have the problem that Chaco wants to measure font widths to figure out "by itself" where to place left-aligned text. Font width computations aren't available to "pure" PS/EPS/SVG/PDF. The PDF backend works because reportlab ships with a "scary" database of glyph widths. I don't particularly like that approach, since it doesn't scale well (if you want to use any but the standard 14 fonts, you're SOL), puts a significant memory burden on the app, but most of all, I think it's unnecessary in most cases. It would be possible to avoid the need to ask for text width for the sake of drawing labels in many back-ends -- however, I realize that Chaco needs to figure out dimensions of things for its layout engine -- not just to draw frames around titles, but to figure out how big graphs are, etc. What I'll probably do is to rip out the fontdata and string-width-computation code out of reportlab and make it more standalone. With some database compression, it can probably be fairly lightweight. That way any backend which uses the standard fonts can get font widths without having to load the fonts into memory -- obviously not relevant for FreeType-based backends, since they need the fonts to produce their output, but useful for any "delayed rendering" formats. [...] > Building a new Kiva backend is then as simple as learning how > to blit this thing into the screen for a new toolkit. Yup. > The GUI > interaction portion of Chaco might be significantly refactored when we > go down this road also to make porting that part of Chaco much easier > also. It may not even be any better to keep a OpenGL version around > since we can blit anti-grain images into it just as easily as other > APIs. I guess this decision will depend on speed. Right -- OpenGL has hardware acceleration at least on some platforms and is the result of hundreds of man-years of optimization and testing. It'll be a while before anti-grain matches that, although anti-grain's 2-d model is a better fit for Kiva, and probably benefits from shortcuts which OpenGL can't afford. > The only potential downside that I see is if anti-grain is slower at > drawing than the GUI toolkits. Anti-grain looked plenty fast to me in > the demos I have looked at -- it looked just as fast as GDI+ (windows > new path based rendering API), but we'll just have to wait and see on > this one. Right -- the demos that I tried, AFAICT, only computed once -- everything else was presumably cached. Regardless, having more backends is only for the good -- it helps define the API better, provides portability (if anti-grain isn't available when creating a png, use PIL instead, etc.). If I didn't have such an allergy to C++, I'd probably have volunteered to help w/ the agg backend =). --david From eric at enthought.com Fri Nov 29 15:04:23 2002 From: eric at enthought.com (eric jones) Date: Fri, 29 Nov 2002 14:04:23 -0600 Subject: [SciPy-user] FW: anti-grain In-Reply-To: <3DE7B2EE.5040103@ActiveState.com> Message-ID: <001901c297e2$85de0bc0$8901a8c0@ERICDESKTOP> ---------------------------------------------- eric jones 515 Congress Ave www.enthought.com Suite 1614 512 536-1057 Austin, Tx 78701 > -----Original Message----- > From: scipy-user-admin at scipy.net [mailto:scipy-user-admin at scipy.net] On > Behalf Of David Ascher > Sent: Friday, November 29, 2002 12:33 PM > To: scipy-user at scipy.net > Cc: scipy-chaco at scipy.org > Subject: Re: [SciPy-user] FW: anti-grain > > eric jones wrote: > > > Right. The Kiva API is DisplayPDF and therefore vector based. That > > won't change. The PDF backend will definitely stay, and I would like to > > see PS/EPS and SVG backends built (thanks for the PIL backend Dave). > > The SVG backend is most of the way there, and PS/EPS will be easy -- I may > get to them over the weekend. Very good news. Thanks. > > PS/EPS and SVG all have the problem that Chaco wants to measure font > widths to > figure out "by itself" where to place left-aligned text. Font width > computations aren't available to "pure" PS/EPS/SVG/PDF. > > The PDF backend works because reportlab ships with a "scary" database of > glyph > widths. I don't particularly like that approach, since it doesn't scale > well > (if you want to use any but the standard 14 fonts, you're SOL), puts a > significant memory burden on the app, but most of all, I think it's > unnecessary > in most cases. > > It would be possible to avoid the need to ask for text width for the sake > of > drawing labels in many back-ends -- however, I realize that Chaco needs to > figure out dimensions of things for its layout engine -- not just to draw > frames > around titles, but to figure out how big graphs are, etc. Yeah. Getting font sizes is an absolute must to layout graphs that look any good. Otherwise axis labels and other text will be running over graph lines, etc. > > What I'll probably do is to rip out the fontdata and string-width- > computation code out of reportlab and make it more standalone. With some > database compression, it can probably be fairly lightweight. That way any > backend which uses the standard fonts can get font widths without having > to load the fonts into memory -- obviously not relevant for FreeType-based > backends, since they need the fonts to produce their output, but useful > for any "delayed rendering" formats. > [...] So this same fontdata code will be usable across all the PS/EPS/SVG/PDF backends? Will SVG need different data than the others? It amazes me that, with all the advanced capabilities Kiva will have (anti-aliased rendering, transparency, etc.), rendering text and dealing with fonts is the part that most worries me. FreeType is only half the battle on bitmap systems -- finding/handling fonts across platforms is the other. On vector systems, it sounds like the problems are worse -- not better. Hopefully the repackaged reportlab "standard font size calculator" will solve 80-90% of the problem. > > > Building a new Kiva backend is then as simple as learning how > > to blit this thing into the screen for a new toolkit. > > Yup. > > > The GUI > > interaction portion of Chaco might be significantly refactored when we > > go down this road also to make porting that part of Chaco much easier > > also. It may not even be any better to keep a OpenGL version around > > since we can blit anti-grain images into it just as easily as other > > APIs. I guess this decision will depend on speed. > > Right -- OpenGL has hardware acceleration at least on some platforms and > is the result of hundreds of man-years of optimization and testing. It'll > be a while before anti-grain matches that, although anti-grain's 2-d model > is a better fit for Kiva, and probably benefits from shortcuts which > OpenGL can't afford. My sense is that HW accelerated OpenGL is amazingly fast for 3D with less attention paid to the 2D stuff (which Doom doesn't care about I guess). The difference may not be so great in a lot of areas. We won't know the end results until we compare them. If necessary, its also not out of the question to write SSE/SSE2 based kernels for algorithms that can benefit. That will help something like 70-90% of the end users. > > > The only potential downside that I see is if anti-grain is slower at > > drawing than the GUI toolkits. Anti-grain looked plenty fast to me in > > the demos I have looked at -- it looked just as fast as GDI+ (windows > > new path based rendering API), but we'll just have to wait and see on > > this one. > > Right -- the demos that I tried, AFAICT, only computed once -- everything > else was presumably cached. The ones I looked at were interactive. Look here: http://www.antigrain.com/agg_comparison/agg_gdiplus.html If you left click and move the mouse around, the image is scaled/rotated. It looks plenty fast. > > Regardless, having more backends is only for the good -- it helps define > the API better, provides portability (if anti-grain isn't available when > creating a png, use PIL instead, etc.). To a point. It does create a maintenance headache. Most Python GUI APIs are, ahhemm, under documented (man is that the pot calling the kettle black coming from a SciPy developer...). Also, most backends won't support some of the advanced features well (or at all). I'm happy to get a large number of backends (and platforms) now so that we can work re-factor the API. But, if in the end, we can get something that is fast and portable with anti-grain that makes platform specific backends trivially simple, I'll be a happy camper. > > If I didn't have such an allergy to C++, I'd probably have volunteered to > help w/ the agg backend =). Dave Morrill has the same allergy. What's with you guys?? Someone must have a shot for that. I'll ask Dave Abrahams... way to many Dave's around here. Actually, the C++ part of anti-grain makes me a little nervous too, even though I really like C++. This is because Python/C++ has more build/portability issues than Python/C, not because of the language. These are getting better all the time, but issues linger. Hopefully we'll have a preliminary anti-grain wrapper in a month or so to play with, and we'll learn the portability problems sooner instead of later. I have every reason to believe McSeem will work with us to solve platform issues at the C++ level. Regards, eric From DavidA at ActiveState.com Fri Nov 29 15:17:20 2002 From: DavidA at ActiveState.com (David Ascher) Date: Fri, 29 Nov 2002 12:17:20 -0800 Subject: [Scipy-chaco] RE: [SciPy-user] FW: anti-grain In-Reply-To: <001901c297e2$85de0bc0$8901a8c0@ERICDESKTOP> References: <001901c297e2$85de0bc0$8901a8c0@ERICDESKTOP> Message-ID: <3DE7CB50.4070500@ActiveState.com> eric jones wrote: > Yeah. Getting font sizes is an absolute must to layout graphs that look > any good. Otherwise axis labels and other text will be running over > graph lines, etc. Axis labels aren't the issue, though -- you can delegate the positioning of a text element to the back-end. But title boxes etc. are an issue. > So this same fontdata code will be usable across all the PS/EPS/SVG/PDF > backends? Will SVG need different data than the others? Correct. Although since I spoke, I cheated and simply imported the reportlab module and delegated the computation to it. Repackaging the code is still something we should do, but now it's just a packaging requirement, which motivates me much less than getting good-looking graphs =). It also has maintenance implications -- some of that code deals with font encoding issues which I know little about. [Aside: reportlab is way overkill for a PDF backend for Kiva -- if that's an issue, know that you could probably do a PDF backend in 200 lines + the font sizing code & data]. > It amazes me that, with all the advanced capabilities Kiva will have > (anti-aliased rendering, transparency, etc.), rendering text and dealing > with fonts is the part that most worries me. FreeType is only half the > battle on bitmap systems -- finding/handling fonts across platforms is > the other. On vector systems, it sounds like the problems are worse -- > not better. Hopefully the repackaged reportlab "standard font size > calculator" will solve 80-90% of the problem. Don't get me started about fonts. Both with PIL and with FreeType, chaco/kiva/scipy will need to define a font registry. Reportlab has something like that, which apparently deals with Type 1 fonts, and BDF fonts. That's probably overkill for this project at this point. > My sense is that HW accelerated OpenGL is amazingly fast for 3D with > less attention paid to the 2D stuff (which Doom doesn't care about I > guess). Back when I looked at this, the major thing that OpenGL did amazingly well in the 2-d space was anti-aliasing, transparency and zooming. Those are very expensive to do in software, and cheap to do in hardware. I've used PyOpenGL to do interactive 2-d applications that used all three of those, and the results were impressive. I didn't have anti-grain to compare with, though. > If you left click and move the mouse around, the image is > scaled/rotated. It looks plenty fast. Cool. > To a point. It does create a maintenance headache. Most Python GUI > APIs are, ahhemm, under documented (man is that the pot calling the > kettle black coming from a SciPy developer...). Having spent some days looking in chaco/kiva, I'd have to agree =). > Dave Morrill has the same allergy. What's with you guys?? Someone must > have a shot for that. I'll ask Dave Abrahams... way to many Dave's > around here. In my case, it's got to do with the fact that I was exposed to C++ when it was too young for public consumption (IMO). I never got to know "grown-up" C++. Current svgcore2d.py attached -- it works well with simple plots (try "python svgcore2d.py output.svg" and then look at the resulting SVG file). I still have a problem with layout of composite plots, which probably has to do with the coordinate transforms that I have to apply. I'll send you and Dave an example output and you can tell me what line I need to change. =) Cheers, --david -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: svgcore2d.py URL: From eric at enthought.com Fri Nov 29 15:37:30 2002 From: eric at enthought.com (eric jones) Date: Fri, 29 Nov 2002 14:37:30 -0600 Subject: [Scipy-chaco] RE: [SciPy-user] FW: anti-grain In-Reply-To: <3DE7CB50.4070500@ActiveState.com> Message-ID: <002101c297e7$26314d40$8901a8c0@ERICDESKTOP> ---------------------------------------------- eric jones 515 Congress Ave www.enthought.com Suite 1614 512 536-1057 Austin, Tx 78701 > -----Original Message----- > From: scipy-user-admin at scipy.net [mailto:scipy-user-admin at scipy.net] On > Behalf Of David Ascher > Sent: Friday, November 29, 2002 2:17 PM > To: scipy-chaco at scipy.org > Cc: scipy-user at scipy.net > Subject: Re: [Scipy-chaco] RE: [SciPy-user] FW: anti-grain > > eric jones wrote: > > > Yeah. Getting font sizes is an absolute must to layout graphs that look > > any good. Otherwise axis labels and other text will be running over > > graph lines, etc. > > Axis labels aren't the issue, though -- you can delegate the positioning > of a > text element to the back-end. But title boxes etc. are an issue. ??? I don't quite get this. We have to know the sizes of the axis labels (both titles and numbers) to trim off enough real estate around a plot so that the numbers don't overlap onto the graph (y labels) or onto each other (x labels). I'm not sure how you would do this without precalculating the actual screen size of the text. > > > So this same fontdata code will be usable across all the PS/EPS/SVG/PDF > > backends? Will SVG need different data than the others? > > Correct. Although since I spoke, I cheated and simply imported the > reportlab > module and delegated the computation to it. Repackaging the code is still > something we should do, but now it's just a packaging requirement, which > motivates me much less than getting good-looking graphs =). It also has > maintenance implications -- some of that code deals with font encoding > issues which I know little about. > > [Aside: reportlab is way overkill for a PDF backend for Kiva -- if that's > an issue, know that you could probably do a PDF backend in 200 lines + the > font sizing code & data]. It would be better not to have the reportlab dependency if we don't loose any capabilities, so if the backend is trivial (nearly identical to the PS one I guess?), I'm for removing the dependency. > > > It amazes me that, with all the advanced capabilities Kiva will have > > (anti-aliased rendering, transparency, etc.), rendering text and dealing > > with fonts is the part that most worries me. FreeType is only half the > > battle on bitmap systems -- finding/handling fonts across platforms is > > the other. On vector systems, it sounds like the problems are worse -- > > not better. Hopefully the repackaged reportlab "standard font size > > calculator" will solve 80-90% of the problem. > > Don't get me started about fonts. Both with PIL and with FreeType, > chaco/kiva/scipy will need to define a font registry. Reportlab has > something like that, which apparently deals with Type 1 fonts, and BDF > fonts. That's probably overkill for this project at this point. > > > My sense is that HW accelerated OpenGL is amazingly fast for 3D with > > less attention paid to the 2D stuff (which Doom doesn't care about I > > guess). > > Back when I looked at this, the major thing that OpenGL did amazingly well > in > the 2-d space was anti-aliasing, transparency and zooming. Those are very > expensive to do in software, and cheap to do in hardware. I've used > PyOpenGL to do interactive 2-d applications that used all three of those, > and the results were impressive. I didn't have anti-grain to compare > with, though. I'm betting OpenGL will win -- or if it doesn't now, it will in the future. Unless there is a compelling reason to get rid of it at some point, keeping an OpenGL backend seems like a good idea. There are only a few features that will be problematic with it (and probably won't be supported). These include "join mitering" and "line end caps." The other thing I'm a little worried about is thick lines. I think some OpenGL implementations don't support lines thicker than 10 points. Beyond that, you have to draw a polygon. This will lead to silly if/then code. There are probably other things, but Dave Morrill, has gotten it all 90% there. > > > If you left click and move the mouse around, the image is > > scaled/rotated. It looks plenty fast. > > Cool. > > > To a point. It does create a maintenance headache. Most Python GUI > > APIs are, ahhemm, under documented (man is that the pot calling the > > kettle black coming from a SciPy developer...). > > Having spent some days looking in chaco/kiva, I'd have to agree =). I promise that this will be remedied, but I won't promise when. :-) > > > Dave Morrill has the same allergy. What's with you guys?? Someone must > > have a shot for that. I'll ask Dave Abrahams... way to many Dave's > > around here. > > In my case, it's got to do with the fact that I was exposed to C++ when it > was too young for public consumption (IMO). I never got to know > "grown-up" C++. > > Current svgcore2d.py attached -- it works well with simple plots (try > "python svgcore2d.py output.svg" and then look at the resulting SVG file). Wait a second... Something must be wrong with the email transmission here. I'm missing the file where you defined all the javascript code to support interaction with the plot.:-) > I still have a problem with layout of composite plots, which probably has > to do with the coordinate transforms that I have to apply. I'll send you > and Dave an example output and you can tell me what line I need to > change. =) ok. See ya, Eric From DavidA at ActiveState.com Fri Nov 29 18:00:23 2002 From: DavidA at ActiveState.com (David Ascher) Date: Fri, 29 Nov 2002 15:00:23 -0800 Subject: [Scipy-chaco] RE: [SciPy-user] FW: anti-grain In-Reply-To: <002101c297e7$26314d40$8901a8c0@ERICDESKTOP> References: <002101c297e7$26314d40$8901a8c0@ERICDESKTOP> Message-ID: <3DE7F187.6080604@ActiveState.com> eric jones wrote: > ??? I don't quite get this. We have to know the sizes of the axis > labels (both titles and numbers) to trim off enough real estate around a > plot so that the numbers don't overlap onto the graph (y labels) or onto > each other (x labels). I'm not sure how you would do this without > precalculating the actual screen size of the text. You're right. I didn't realize the sophistication in your algorithms (I should have, I've admired the tick marks and labeling choices). > It would be better not to have the reportlab dependency if we don't > loose any capabilities, so if the backend is trivial (nearly identical > to the PS one I guess?), I'm for removing the dependency. Ok, I'll try and do that later this week. > I'm betting OpenGL will win -- or if it doesn't now, it will in the > future. Unless there is a compelling reason to get rid of it at some > point, keeping an OpenGL backend seems like a good idea. There are only > a few features that will be problematic with it (and probably won't be > supported). These include "join mitering" and "line end caps." I've never needed those in display code -- only in printouts. PIL will never support that either, and I don't care =). > The > other thing I'm a little worried about is thick lines. I think some > OpenGL implementations don't support lines thicker than 10 points. > Beyond that, you have to draw a polygon. This will lead to silly > if/then code. There are probably other things, but Dave Morrill, has > gotten it all 90% there. There are other weirdnesses, such as the fact that OpenGL "points" are in screen pixels, not in viewspace coordinates. But since Kiva doesn't support points yet, you haven't noticed it =). [..docs...] > I promise that this will be remedied, but I won't promise when. :-) I'll produce a quick writeup of how to do a backend like the ones I did -- someone else can write the "interactive" part. What I'm most in need of isn't Kiva information -- that code is fairly straightforward. It's the Chaco class hierarchy and fancy 'delegate' handling which I'd love to learn more about. Ooh. I just figured out how to do compound plots -- there's a minor bug in plot_container.py:NestedContainers._add_item() -- it shouldn't fail if there's no "window" attribute. With a try/except around that access, I get compound plots w/o having to invoke any of the GUI stuff. Yeehah! [Aside: why do some lines in .co files have the format "foo = bar" while others have "foo: bar"?] > Wait a second... Something must be wrong with the email transmission > here. I'm missing the file where you defined all the javascript code to > support interaction with the plot.:-) Until I get marker support code in Kiva, there's not much point to doing that. I'm don't see SVG as the base for a full-fledged interactive UI (although that would be cool in a sick kind of way) -- but I do want to support some "data mining operations" -- click on a marker hits another web page that gives you more details about that data point, etc. That will happen by adding metadata to individual data points (aka markers). --david From eric at enthought.com Fri Nov 29 18:33:46 2002 From: eric at enthought.com (eric jones) Date: Fri, 29 Nov 2002 17:33:46 -0600 Subject: [Scipy-chaco] RE: [SciPy-user] FW: anti-grain In-Reply-To: <3DE7F187.6080604@ActiveState.com> Message-ID: <000001c297ff$c5ee7930$8901a8c0@ERICDESKTOP> Hey David, > eric jones wrote: > > > ??? I don't quite get this. We have to know the sizes of the axis > > labels (both titles and numbers) to trim off enough real estate around a > > plot so that the numbers don't overlap onto the graph (y labels) or onto > > each other (x labels). I'm not sure how you would do this without > > precalculating the actual screen size of the text. > > You're right. I didn't realize the sophistication in your algorithms (I > should have, I've admired the tick marks and labeling choices). > > > It would be better not to have the reportlab dependency if we don't > > loose any capabilities, so if the backend is trivial (nearly identical > > to the PS one I guess?), I'm for removing the dependency. > > Ok, I'll try and do that later this week. Cool. > > > I'm betting OpenGL will win -- or if it doesn't now, it will in the > > future. Unless there is a compelling reason to get rid of it at some > > point, keeping an OpenGL backend seems like a good idea. There are only > > a few features that will be problematic with it (and probably won't be > > supported). These include "join mitering" and "line end caps." > > I've never needed those in display code -- only in printouts. PIL will > never support that either, and I don't care =). I don't see these as major right now either. On the other hand, one of the desired "selling points" for Kiva is that you get the same output on all platforms. I also hope that it expands to be useful in areas outside of just scientific plotting, and other disciplines may consider these capabilities important. PDF,PS, and (I think) SVG will all support them. It'd be nice if the bitmap/screen rendering did also. > > > The > > other thing I'm a little worried about is thick lines. I think some > > OpenGL implementations don't support lines thicker than 10 points. > > Beyond that, you have to draw a polygon. This will lead to silly > > if/then code. There are probably other things, but Dave Morrill, has > > gotten it all 90% there. > > There are other weirdnesses, such as the fact that OpenGL "points" are in > screen pixels, not in viewspace coordinates. But since Kiva doesn't > support points yet, you haven't noticed it =). DisplayPDF (or at least the API we're emulating) doesn't have a "point" command. I think you would create a point by calling the arc() command to form a circlular path of a given size. > > [..docs...] > > > I promise that this will be remedied, but I won't promise when. :-) > > I'll produce a quick writeup of how to do a backend like the ones I did -- > someone else can write the "interactive" part. That would be very nice. Thanks. > > What I'm most in need of isn't Kiva information -- that code is fairly > straightforward. It's the Chaco class hierarchy and fancy 'delegate' > handling > which I'd love to learn more about. > > Ooh. I just figured out how to do compound plots -- there's a minor bug > in > plot_container.py:NestedContainers._add_item() -- it shouldn't fail if > there's no "window" attribute. With a try/except around that access, I > get compound plots w/o having to invoke any of the GUI stuff. Yeehah! You should have CVS access soon to fix this. > [Aside: why do some lines in .co files have the format "foo = bar" while > others have "foo: bar"?] That is a question for Dave M. > > > Wait a second... Something must be wrong with the email transmission > > here. I'm missing the file where you defined all the javascript code to > > support interaction with the plot.:-) > > Until I get marker support code in Kiva, there's not much point to doing > that. That is definitely desirable. Realistically, that is weeks away, unless you work with Dave M. to rectify it. He is re-factoring this week to make it easy to support multiple kinds of plots with stacked bar charts being the first priority. > I'm don't see SVG as the base for a full-fledged interactive UI > (although that would be cool in a sick kind of way) Yeah, I'm kinda curious how much effort it would take or if it is even possible from Chaco. I'm thinking it will fall in the "a lot of work" category. > -- but I do want to > support some "data mining operations" -- click on a marker hits another > web page that gives you more details about that data point, etc. That > will happen by adding metadata to individual data points (aka markers). Sounds like something Chaco should support to me. Also, lets move future discussions to scipy-chaco at scipy.org. We're (thankfully) getting pretty noisy about the plotting stuff, and the scipy-user crew may not be interested in the discussion. Thanks, eric