Fwrap is quickly progressing & converging on release. (Mea culpa for the *lack* of a release in April.) I’m finding that, like solving a PDE, 80% of the human effort takes place with handling the boundary conditions, even though they are, well, just the boundary. For fwrap’s purposes, that means a *lot* of work has been taken up in the compilation bits, and by that I mean getting the different fortran compilers, cython and numpy to play nicely (although the fortran compilers are the primadonnas of the bunch). Whoever comes up with a killer solution for ‘make’ in Python will gain my eternal gratitude. But I digress.
For those interested in checking things out (alpha sofware, interface is stabilizing, usual caveats, etc.) fwrap is hosted at sourceforge here:
(I’ll put up more handy links there shortly)
The project’s mercurial repo can be checked out here (although it will likely be converted to git soon):
You’ll need numpy (>=1.3.0 — haven’t checked earlier versions), cython (>= 0.11 — ibid) and fparser (which will be distributed with fwrap when 0.1 comes along). Fwrap uses nose for unit testing. You can get an svn checkout of fparser here:
$ svn co http://f2py.googlecode.com/svn/trunk/fparser/ fparser
Once these are in place (recommended that a symlink to fparser be placed in the fwrap_src directory) you can run the “integration tests” (runs fwrap on fortran code, compiles it and runs a doctest suite on the resulting module) from within the toplevel fwrap directory:
$ python runtests.py –fcompiler=gnu95 –no-cleanup
There are other options, the one you’ll probably care the most about is the –fcompiler flag. By default it is ‘gnu95’. ‘–no-cleanup’ is also handy, it makes sure to leave everything in place in BUILD after running the tests.
If you care to run the tests and let me know how it goes, I’d be obliged. Current tests work on Mac OS X 10.5 and Ubuntu 9.04. Windows testing is sorely lacking and much needed.