Mailman 3 May 2002 - SciPy-Dev

Re: [SciPy-dev] cvs change broke macos x compatibility
by Jeff Whitaker May 31, 2002

May 31, 2002

> That was me. Sorry about that. It is fixed in CVS now. Pearu: Thanks! Seems to be working now. Here are my test results on OS X: >>> scipy.test_all() ... Ran 586 tests in 534.560s FAILED (errors=1) >>> -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/CDC R/CDC1 Email : jsw(a)cdc.noaa.gov 325 Broadway Web : www.cdc.noaa.gov/~jsw Boulder, CO, USA 80303-3328 Office : Skaggs Research Cntr 1D-124

1 0

cvs change broke macos x compatibility
by Jeff Whitaker May 30, 2002

May 30, 2002

Yesterday's cvs snapshot won't compile on OS X. The error is: ar -curs build/temp.darwin-5.4-PowerMacintosh-2.2/libcalc_lwork.a build/temp.darwin-5.4-PowerMacintosh-2.2/calc_lwork.o ar: illegal option -- s It worked a week ago - someone must have just added the "s" option to ar. This is not supported on OS X. -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/CDC R/CDC1 Email : jsw(a)cdc.noaa.gov 325 Broadway Web : www.cdc.noaa.gov/~jsw Boulder, CO, USA 80303-3328 Office : Skaggs Research Cntr 1D-124

2 1

RE:[PATCH] zeros.c
by Chuck Harris May 29, 2002

May 29, 2002

This patch does the following: 1) If the passed function raises an exception, that is the exception reported. 2) If the passed function does not return a valid value, the report is made clearer. 3) Small formatting cleanup 4) Documentation strings are added for the module functions. 5) A reference counting bug is fixed The reference counting bug is easy to trigger by passing the extra argument. Say def f(x): return x - .5 foo = 'fubar' for i in range(1000) : bisect(f,0,1,args=foo) at some point foo will be garbage collected and disappears. I must admit that I haven't tried precisely this example and no longer have the original installed to check, but it should work. Oddly enough, Idle also seems to suffer from a reference counting bug, so using sys.getrefcount may return unexpected results. The reason this bug shows up is that PyTuple_GetItem borrows a reference and PyTuple_SET_ITEM steals it, so when the tuple is destroyed the reference count of the item is decremented instead of being left in its original state. The lines all seem to end in ^M, as reported by emacs. It is not visible here, but there may be some sort of line end problem. I got the source from CVS using http to download the files. Is this as it should be? Chuck ==================PATCH================== --- zeros-old.c Wed May 29 13:40:50 2002 +++ zeros.c Wed May 29 11:39:09 2002 @@ -40,11 +40,18 @@ args = myparams->args; f = myparams->function; PyTuple_SetItem(args,0,Py_BuildValue("d",x)); - val = PyFloat_AsDouble(retval=PyObject_CallObject(f,args)); - Py_XDECREF(retval); + retval = PyObject_CallObject(f,args); + if (PyErr_Occurred()) { + Py_XDECREF(retval); + longjmp(myparams->env, 1); + } + val = PyFloat_AsDouble(retval); if (PyErr_Occurred()) { + PyErr_SetString(PyExc_RuntimeError,"Could not convert function value to double"); + Py_XDECREF(retval); longjmp(myparams->env, 1); } + Py_XDECREF(retval); return val; } @@ -62,11 +69,10 @@ PyObject *f,*xargs,*item,*fargs=NULL; - if (!PyArg_ParseTuple(args,"OdddiOi|i",&f,&a,&b,&xtol,&iter,&xargs,&fulloutput,&disp)) - { - PyErr_SetString(PyExc_RuntimeError,"Unable to parse arguments"); - return NULL; - } + if (!PyArg_ParseTuple(args,"OdddiOi|i",&f,&a,&b,&xtol,&iter,&xargs,&fulloutput,&disp)) { + PyErr_SetString(PyExc_RuntimeError,"Unable to parse arguments"); + return NULL; + } if (xtol < 0) { PyErr_SetString(PyExc_ValueError,"xtol must be >= 0"); return NULL; @@ -87,6 +93,7 @@ for (i = 0; i < len; i++) { item = PyTuple_GetItem(xargs, i); if (item == NULL) { Py_DECREF(fargs); return NULL;} + Py_INCREF(item); PyTuple_SET_ITEM(fargs,i+1,item); } @@ -154,10 +161,10 @@ static PyMethodDef Zerosmethods[] = { - {"_bisect", _bisect, METH_VARARGS, "a"}, - {"_ridder", _ridder, METH_VARARGS, "a"}, - {"_brenth", _brenth, METH_VARARGS, "a"}, - {"_brentq", _brentq, METH_VARARGS, "a"}, + {"_bisect", _bisect, METH_VARARGS, "bisect(f,a,b)"}, + {"_ridder", _ridder, METH_VARARGS, "ridder(f,a,b)"}, + {"_brenth", _brenth, METH_VARARGS, "brenth(f,a,b)"}, + {"_brentq", _brentq, METH_VARARGS, "brentq(f,a,b)"}, {NULL, NULL} };

1 0

blas/lapack interfaces
by Pearu Peterson May 29, 2002

May 29, 2002

On Tue, 28 May 2002, eric wrote: > > Pearu wrote: > > I agree. Having the C interfaces around is useful only if there is a > > memory issue. > > Lets keep them. Your packaging in linalg makes the fail over to > flapack completely transparent, so the only cost is maintaining the > code. That may not be a small cost though -- these wrappers > definitions are pretty dang complex now. I saw that you split the > Fortran and C wrappers files at some point. I had really wanted to > avoid this to help with maintainability but assume it was done to > handle the callstatement() stuff. I do wish they were still unified. > Do you think it might be possible to introduce a <c_section> and > <f_section> tag to our interface_gen generic scripts to include > specific sections in the generated interface files depending on the > target language? I did that split in order to avoid complexity when it was not really clear how these signatures will look like (in this process new features to f2py were added). However, the signatures to Fortran and C routines were created in parallel to ensure the compability. Also, you'll see that signatures to the same Fortran or C routine are in some cases quite different (because C and Fortran routines require a bit different strategies for wrapping and managing memory of temporaries, also BLAS?LAPACK interfaces of the same routine but for complex or real input data may differ etc.) but their apparence in Python is (almost) identical (some wrappers to C routines have extra optional arguments to handle data ordering issues with additional flexibility). But now, when the most important BLAS/LAPACK routines are exposed and we have basic unittests (and need more), I agree, that the next step would be to merge the signatures of Fortran and C routines to ease the maintainability. And yes, introducing <c|f_section> tags are possible when doing that. In addition, I would like to suggest splitting the current generic signature files into smaller files, each containing signatures to one particular routine. Having different routine signatures in separate files (collected in some subdirectory of scipy/linalg), IMHO, they will be easier to maintain and discuss compared to its current form where the generic files, containing a large number of different signatures, are quite longish and difficult to handle. And we need to document the blas and lapack functions. I hope we can do that while reviewing-testing-freezing the signatures. Pearu

1 0

patch to build_flib to support digital fortran compiler
by Berthold Höllmann May 29, 2002

May 29, 2002

I have added a class "digital_fortran_compiler" to build_flib.py which adds support for the Digital Fortran Comiler under WinNT to the scipy_distutils. Please find the class attached (no diffs because or the recent changes to build_flib.py did not allow a good diff). This email contains confidential information for the exclusive attention of the intended addressee. Any access of third parties to this email is unauthorized. Any use of this email by not intended recipients like copying, distribution, disclosure etc. is prohibited and may be unlawful. When addressed to our clients the content of this email is subject to the General Terms and Conditions of GL's Group of Companies applicable at the date of this email. GL's Group of Companies does not warrant and/or guarantee that this message at the moment of receipt is authentic, correct and its communication free of errors, interruption etc.

2 2

PATCH: scipy_distutils/system_info.py
by cookedm＠physics.mcmaster.ca May 27, 2002

May 27, 2002

Ok, I've taken another look at the system_info.py code. The attached patch does the following: - The wrong things were being set for static and shared libraries. Static libraries should be linked as 'extra_objects', and shared libraries using 'libraries' and 'library_dirs'. - X11 is only linked statically if static_first=1 is set in the x11 section of the site.cfg file (i.e., only when you explicitly ask for it, which you probably won't) - The environment variables ATLAS and FFTW can now be set to a list of directories, if you don't want to use the site.cfg method. - The doc strings for {Atlas,FFTW}NotFoundError now mention site.cfg as a method of setting paths -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke |cookedm(a)mcmaster.ca

2 8

FYI on meaning of 'Test Completed' on Download/Scoreboard pages of SciPy.org
by David C. Morrill May 22, 2002

May 22, 2002

Just a quick note on the meaning of 'Test Completed' in the 'Test Results' column of the new Download and Scoreboard pages on the scipy.org web site. 'Test Completed' means that the test phase of the build process completed successfully, but the build process was not able to locate the result information (i.e. number of tests run, failures, errors) in the build log. It currently locates the result information using a regular expression, so unexpected changes in the message format may cause it to break (which is what is happening now). I'm looking into a fix for this (both short term and long term) right now. In the meantime, you can still examine the build logs via the web pages to see the actual test results. So the bad news is that the 'Test Results' fields is currently partially 'broken'. The good news is that what broke it appears to be a number of CVS check-ins by Travis Oliphant that eliminated all of the test failures that were occuring. So, all-in-all, a big net positive I think. Thanks Travis!. Dave Morrill --- David Morrill <dmorrill at enthought.com> Enthought, Inc. [www.enthought.com and www.scipy.org] (512) 536-1057

3 2

CVS mailing list
by eric May 22, 2002

May 22, 2002

By the way Pearu, We've only had the CVS mailing list for a few days, and I already like it *very* much. Thanks for suggesting it. And thanks, Adam, for setting it up. eric -- Eric Jones <eric at enthought.com> Enthought, Inc. [www.enthought.com and www.scipy.org] (512) 536-1057

1 0

New CVS commit mailing list
by Adam Barker May 21, 2002

May 21, 2002

Hello all, I'm pleased to announce that we now have a CVS commit log mailing list. The new mailing list is called scipy-cvs, and is accessible at: http://www.scipy.net/mailman/listinfo/scipy-cvs This list receives automatic updates on every commit to our repository. Enjoy! Let me know if you have any questions. Thanks, Adam

2 1

Scipy.org login problems
by Adam Barker May 20, 2002

May 20, 2002

Hi all, Apparently there was a bit of a bungle on my part last week with the account expiration setup. I inadvertently locked out everyone's account as of Friday or Saturday. Anyway, the problem should be fixed now, and everyone should be able to log in. If you have any trouble, let me know and I'll try to get it fixed as quickly as possible. Sorry for any inconvenience, Adam

3 2