I’m glad to say that the f2cy part of the GSoC miterm evaluation is functional. By that I mean it can wrap functions & subroutine subprograms (not in modules, yet) with any integer or real argument. The testing framework is all in place, and all tests pass. There are still many things that I’d like to add before the midterm, but the basics are all there, and the additions should be fairly modular and easy to do. The code could use some cleanup, but it shouldn’t be too bad.
Here are the some additions I’d like to make before the midterm if time allows — nothing to be inferred by the ordering except where noted:
1) Support locally defined parameter kind-types (easy), e.g.:
subroutine foo(a,b) integer :: DP parameter (DP = 8 ) integer, parameter :: SP = 4 real(kind=DP), intent(inout) :: a real(kind=SP), intent(in) :: b ! ... end subroutine
2) Next, support use’d module kind-type parameters (easy):
module ktps integer :: KTP parameter (KTP = 10) end module ktps integer function bar(a) use ktps real(kind=KTP), intent(inout) :: a ! ... end function
3) Next, support module-scoped functions (some corner cases to consider, a bit harder) — just to give you an idea…
module container use ktps, local_kpts => KTPS integer, parameter :: C_KTPS = local_ktps contains subroutine mod_subr(a) use othermod, rename_p => orig_p use yetanother, only: yetanother_p => xxx implicit none integer(kind=C_KTPS) :: a integer(kind=other_mod_param), intent(out) :: b integer(kind=rename_p) :: c ! ... end subroutine end module
4) Logical <-> Integer conversions (probably before the above)
The ‘logical’ type is basically a specially typed integer — whenever a subprogram’s argument is a logical, its C wrapper should use the equivalently-sized integer and do a conversion before & after the call.
5) Character arguments:
It seems that these are functionally equivalent to one-dimensional arrays, with a few bugaboos to watch out for. I’m lumping them in with the second-half of the project, since after working with integer/real arrays I’ll have a better feel as to the best way to handle character arrays.
6) Complex arguments:
Since we can’t assume C99 _Complex support, these need to be passed in as structs, converted to the native complex type in fortran, and converted back on return. Once (4) is done, I’ll have a better feel for these. I’m putting them off until the second half, since they’re equivalent to passing derived types.
I’m turning my full attention to tickets 299, 300 & 178 now, provided that the recent intense discussion about a native Cython array type leave these tickets unchanged (see http://article.gmane.org/gmane.comp.python.cython.devel/6654).