Mailman 3 September 2002 - SciPy-Dev

RE: [Scipy-cvs] CVS update: world/scipy/scipy_distutils/command
by eric jones Sept. 17, 2002

Sept. 17, 2002

That is probably true. I remember that the changes Pearu added based on another user's Sun setup broke the Sun compiler on Duke's machines. I never looked into it very far, but I bet that Duke had an older compiler. Please re-factor/re-organize the code to what you believe is the minimal setup necessary for the Forte compiler on heatmizer. Thanks, eric > -----Original Message----- > From: scipy-cvs-admin(a)scipy.org [mailto:scipy-cvs-admin@scipy.org] On > Behalf Of skip(a)scipy.com > Sent: Monday, September 16, 2002 8:26 PM > To: scipy-cvs(a)scipy.org > Subject: [Scipy-cvs] CVS update: world/scipy/scipy_distutils/command > > > Date: Monday September 16, 2002 @ 20:25 > Author: skip > > Update of /home/cvsroot/world/scipy/scipy_distutils/command > In directory shaft:/tmp/cvs-serv11200 > > Modified Files: > build_flib.py > Log Message: > changes to get SciPy to build with Sun's Forte Fortran compilers. I > suspect there may be more changes in the near future. The > sun_fortran_compiler class seems a bit too complex to me. In fact, it > seems like it declares info for two or four compilers. Should it be > split into two or more classes? > > =================================================================== > File: build_flib.py Status: Up-to-date > > Working revision: 1.36 Tue Sep 17 01:25:57 2002 > Repository revision: 1.36 > /home/cvsroot/world/scipy/scipy_distutils/command/build_flib.py,v > > Existing Tags: > Daily_Snapshot_01-11-2002 (revision: 1.8) > pre_compiler_removal (revision: 1.5) > > _______________________________________________ > Scipy-cvs mailing list > Scipy-cvs(a)scipy.org > http://scipy.net/mailman/listinfo/scipy-cvs

3 2

RE: [Scipy-cvs] CVS update: world/scipy/weave
by eric jones Sept. 17, 2002

Sept. 17, 2002

Hey Pearu, That is a weird thing to be breaking the tests. I made the change in preparation of weave being installed as a separate package. That change will also be made today to the __init__.py file. At that point will need to change this to Import weave But this will work for now. Thanks for tracking it down. Eric > -----Original Message----- > From: scipy-cvs-admin(a)scipy.org [mailto:scipy-cvs-admin@scipy.org] On > Behalf Of Pearu Peterson > Sent: Tuesday, September 17, 2002 1:38 PM > To: scipy-cvs(a)scipy.org > Subject: [Scipy-cvs] CVS update: world/scipy/weave > > > Date: Tuesday September 17, 2002 @ 13:38 > Author: pearu > > Update of /home/cvsroot/world/scipy/weave > In directory shaft:/tmp/cvs-serv25714 > > Modified Files: > __init__.py > Log Message: > This fixes infinite loop when testing weave > > =================================================================== > File: __init__.py Status: Up-to-date > > Working revision: 1.10 Tue Sep 17 18:38:05 2002 > Repository revision: 1.10 > /home/cvsroot/world/scipy/weave/__init__.py,v > > Existing Tags: > pre_classify_conversion (revision: 1.3) > Daily_Snapshot_01-11-2002 (revision: 1.2) > pre_compiler_removal (revision: 1.2) > release_0_2_0 (revision: 1.2) > > _______________________________________________ > Scipy-cvs mailing list > Scipy-cvs(a)scipy.org > http://scipy.net/mailman/listinfo/scipy-cvs

1 0

Re: [Scipy-cvs] CVS update: world/scipy/scipy_distutils/command
by Pearu Peterson Sept. 17, 2002

Sept. 17, 2002

Hi Skip, Few comments about Sun compiler support: 1) Does anyone have idea how many different Sun Fortran are there available? If there are many, then it is fine to introduce new compiler classes, may be something like the following: sun_generic_fortran_compiler sun_forte_fortran_compiler sun_studio_fortran_compiler that have appropiate ver_match strings and *different* vendor attributes. 2) f90 should not have -fixed option specified as scipy_distutils should be able to compile also Fortran 90 free format sources, even if currently there are any F90 sources in Scipy. Note that there are f2py users that wrap F90 free format codes to Python. If your system does not have f77 command (that under Sun should be kinda "alias" to `f90 -fixed`) then specify fc = 'f90 -fixed' (though, I doubt that there is a real need for that). 3) Did you check that calling self.find_lib_dir() is really necessary? Usually, using f77 or f90 as a linker will take care of specifying proper library directories. The same comment goes to items in self.libraries list. Thanks, Pearu

2 4

movement of testing.py to scipy_distutils
by eric jones Sept. 16, 2002

Sept. 16, 2002

Does anyone have any objections to moving testing.py from scipy_base to scipy_distutils? It would make distribution of weave and other potential modules have one less dependency package. Besides the blitz() stuff, weave doesn't rely on anything in scipy_base. And, other than scipy_base it doesn't have any extension module dependencies. I like to keep it that way. Hmmm. I guess testing.py could become its own package (or stand alone module) like scipy_base and scipy_distutils also. I think it actually was at one point...? Anyway, opinions and suggestions welcome. I'd like to get a version of the weave stuff packaged up and ready for people to test (although docs are still not updated) by the end of the day. eric

3 4

Re: [Scipy-cvs] CVS update: world/scipy/weave
by Skip Montanaro Sept. 16, 2002

Sept. 16, 2002

Dunno who is in charge of scipy-cvs, but I think it would be helpful if it was jiggered to include the context diff of the checkin. This allows people to quickly scan the checkin for obvious problems and will probably increase the feedback people get on their checkins. If this is not something which is a standard part of CVS, you might check with Barry Warsaw or one of the other Python SF project admins to see what scripts they needed to modify to get the python-checkins list to display context diffs. Skip

2 1

two scipy test failures...
by Skip Montanaro Sept. 16, 2002

Sept. 16, 2002

Just passing these along to make sure they stay on someone's radar screen (should I be submitting bugs somewhere else?). I still get a couple precision errors when running scipy.test(). This is on Solaris using Sun's compilers: FAIL: check_basic (test_morestats.test_shapiro) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/skip/local/SunOS/lib/python2.2/site-packages/scipy/stats/tests/test_morestats.py", line 37, in check_basic assert_almost_equal(pw,0.52459925413131714,6) File "/home/skip/local/SunOS/lib/python2.2/site-packages/scipy_base/testing.py", line 304, in assert_almost_equal assert round(abs(desired - actual),decimal) == 0, msg AssertionError: Items are not equal: DESIRED: 0.524599254131 ACTUAL: 0.524600028992 Note that I have dialed back the decimal arg from 8 to 6. On Linux I get a different precision error: FAIL: check_mean (test_common.test_rand) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/skip/local/Linux/lib/python2.2/site-packages/scipy/tests/test_common.py", line 27, in check_mean assert_almost_equal(mn,0.5,2) File "/home/skip/local/Linux/lib/python2.2/site-packages/scipy_base/testing.py", line 304, in assert_almost_equal assert round(abs(desired - actual),decimal) == 0, msg AssertionError: Items are not equal: DESIRED: 0.5 ACTUAL: 0.505251432072 Skip

1 0

RE: [SciPy-dev] Boost vs CXX and SCXX
by Chuck Harris Sept. 14, 2002

Sept. 14, 2002

Hi, > -----Original Message----- > From: Francesc Alted [mailto:falted@openlc.org] > Sent: Friday, September 13, 2002 4:40 PM > To: scipy-dev(a)scipy.net > Subject: Re: [SciPy-dev] Boost vs CXX and SCXX > > > After seeing this debate about interfaces between Python and > C++, maybe you > want to have a look at Pyrex > (http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/). > > I've been working for a while in a wrapper for HDF5 format in > Python and I'm I would be very interested in that. How far along are you? Chuck

2 1

Boost vs CXX and SCXX
by Mark Evans Sept. 14, 2002

Sept. 14, 2002

> My current opinion remains that SCXX is the best fit for what weave > needs. I'd be interested, though, if a boost expert can chime in on > what they think is required to extract the list, tuple, dictionary stuff > from boost and whether it is appropriate. A couple years ago my company tasked me with an assignment. I was to evaluate C++ interfacing libraries for Python. At that time Boost was still in alpha stages, but after using it, I considered myself very fortunate to have found it. Prior to that, my company and I had sunk a lot of effort into CXX. Even in its alpha stages, Boost was a dream compared to CXX, the C API, or any other toolkit. My particular project involved an ActiveX chart control interfaced to wxPython, and a Python interface to both Mathematica and Numerical Python. We were creating a technical workspace environment with Python as the front end and Numpy / Mathematica as cooperating back ends. I can't tell you what relief I felt after I switched from CXX to Boost. Boost has a lot of complexity so that your C++ code can remain simple. It minimizes the impact of Python interfacing on C++ code. Wrapping your existing C++ code is trivially simple. Not so with CXX and kin. CXX has a different philosophy, which is to make C++ code read like Python code. About all it really does is to define some C++ objects that behave like Python atoms. That's fine as far as it goes but offers nowhere near the power of Boost. Boost does not prohibit writing code like that, but does not force it on you. Compared to Boost, CXX is pretty dumbed-down, and SCXX even more so. I would hate to see SciPy standardize on either one of them especially after my personal experiences "crawling out from under" them. http://www.boost.org/libs/python/doc/comparisons.html After two years of development Boost has taken the lead and I would consider it folly to adopt any other toolkit for C++ interfacing to Python. (In specialized cases I might use SWIG but otherwise Boost all the way.) The Boost development is very active whereas CXX and kin are as stale as old bread. If your Windows compiler is having problems with templates, then try the free Digital Mars compiler (DigitalMars.com). Mark

7 6

Major CVS changes to weave
by eric jones Sept. 13, 2002

Sept. 13, 2002

Hey group, I've just checked a new version of weave into the CVS. It has major changes in it which are highlighted below. The good news is there are some big improvements and the code should be more portable. The bad news is that it introduced some backward incompatibility. Sorry about that. I'm getting pretty happy with the interface and code generation now, so we're close to a stage where backward compatibility will be maintained in future releases. The docs and maybe a few examples still need updating. I'll try to get these and the web pages cleaned up tomorrow and the next day and then make packaged release of weave when it is done. This big change was needed even if new things weren't coming, but the real reason I've checked this in now is in preparation of adding the *really* cool stuff that Pat Miller is doing to optimize standard python code and Numeric expressions. His stuff is still way experimental, but has huge potential. We'll be working over the next month or so to get it up and running so that it is ready for public consumption. Regards, eric Changes: 0. The underlying library code is significantly re-factored and simpler. There used to be a xxx_spec.py and xxx_info.py file for every group of type conversion classes. The spec file held the python code that handled the conversion and the info file had most of the C code templates that were generated. This proved pretty confusing in practice, so the two files have mostly been merged into the spec file. Also, there was quite a bit of code duplication running around. The re-factoring was able to trim the standard conversion code base (excluding blitz and accelerate stuff) by about 40%. This should be a huge maintainability and extensibility win. 1. With multiple months of using Numeric arrays, I've found some of weave's "magic variable" names unwieldy and want to change them. The following are the old declarations for an array x of Float32 type: PyArrayObject* x = convert_to_numpy(...); float* x_data = (float*) x->data; int* _Nx = x->dimensions; int* _Sx = x->strides; int _Dx = x->nd; The new declaration looks like this: PyArrayObject* x_array = convert_to_numpy(...); float* x = (float*) x->data; int* Nx = x->dimensions; int* Sx = x->strides; int Dx = x->nd; This is obviously not backward compatible, and will break some code (including a lot of mine). It also makes inline() code more readable and natural to write. 2. I've switched from CXX to Gordon McMillan's SCXX for list, tuples, and dictionaries. I like CXX pretty well, but its use of advanced C++ (templates, etc.) caused some portability problems. The SCXX library is similar to CXX but doesn't use templates at all. This, like (1) is not an API compatible change and requires repairing existing code. I have also thought about boost python, but it also makes heavy use of templates. Moving to SCXX gets rid of almost all template usage for the standard type converters which should help portability. std::complex and std::string from the STL are the only templates left. Of course blitz still uses templates in a major way so weave.blitz will continue to be hard on compilers. I've actually considered scrapping the C++ classes for list, tuples, and dictionaries, and just fall back to the standard Python C API because the classes are waaay slower than the raw API in many cases. They are also more convenient and less error prone in many cases, so I've decided to stick with them. The PyObject variable will always be made available for variable "x" under the name "py_x" for more speedy operations. You'll definitely want to use these for anything that needs to be speedy. 3. strings are converted to std::string now. I found this to be the most useful type in for strings in my code. Py::String was used previously. 4. There are a number of reference count "errors" in some of the less tested conversion codes such as instance, module, etc. I've cleaned most of these up. I put errors in quotes here because I'm actually not positive that objects passed into "inline" really need reference counting applied to them. The dictionaries passed in by inline() hold references to these objects so it doesn't seem that they could ever be garbage collected inadvertently. Variables used by ext_tools, though, definitely need the reference counting done. I don't think this is a major cost in speed, so it probably isn't worth getting rid of the ref count code. 5. Unicode objects are now supported. This was necessary to support rendering Unicode strings in the freetype wrappers for Chaco. 6. blitz++ was upgraded to the latest CVS. It compiles about twice as fast as the old blitz and looks like it supports a large number of compilers (including SGI, Steve) though only gcc 2.95.3 (2.96 on Linux) is tested. Compile times now take about 9 seconds on my 850 MHz PIII laptop.

4 4

未承諾広告※ちょっと H=?ISO-2022-JP?B?GyRCJEpOeD9NGyhC?= GET=?ISO-2022-JP?B?GyRCISohKhsoQg==?=
by mailstop＠melcon-c.com Sept. 12, 2002

Sept. 12, 2002

<$B;v6H<TL>(B>$B-k%(%/%7%9(B<$BAw?.<T(B>$B-k%(%/%7%9(B<$BAw?.<T!&;v6H<T(BURL>$B!!(Bhttp://plaza15.mbn.or.jp/~1234/ $B$3$N(BҰ�$B$O9-9p$G$9!#G[?.ITMW$NJ}$O(B mailstop(a)melcon-c.com $BKx$4O"Mm2<$5$$!#G[?.$rDd;_CW$7$^$9(B($BI,$:G[?.Dd;_$9$k%"%I%l%9$G$4JV?.2<$5$$!K(B H$B$J=w$N;R5^A}Cf!*:#$,%A%c%s%9!*(B http://www.melcon-c.com $BB(%"%]B3=P!*(B http://www.melcon-c.com $B$^$:$OEPO?$7$F$M!*(B http://www.melcon-c.com

1 0