[SciPy-Dev] [fwrap-users] Work on fwrap and SciPy
Dag Sverre Seljebotn
Thu Nov 4 04:59:26 CDT 2010
On 11/03/2010 10:00 PM, Kurt Smith wrote:
> On Wed, Nov 3, 2010 at 5:26 AM, Dag Sverre Seljebotn
> <email@example.com> wrote:
>> This is just a quick note to inform people that I am currently working with
>> Enthought to bring SciPy to the .NET platform. In particular, I will work on
>> the Fortran parts of SciPy.
>> The primary strategy will be to improve fwrap enough to make it usable for
>> SciPy, and then move SciPy over to fwrap instead of f2py. The point here is
>> that Carl Witty is already working on a .NET backend for Cython, and since
>> fwrap generates Cython code we get the .NET port that way.
> This is great news. Thanks for doing this, and to Enthought for
> providing support. I think all parties will benefit :-)
>> All work is done in Enthought's "refactor" branches for now . The
>> intention is certainly to merge back to main eventually, but questions of
>> how or when or whether will have to wait; getting things up and running on
>> .NET has priority.
> Sure. The fact that the .NET-specific stuff is in Cython should make
> merging fwrap much easier than it otherwise would be. I'm interested
> in keeping fwrap-main synced up with fwrap-.NET, so that they won't
> diverge too much. Your thoughts on this are welcome.
I'm basically happy to work as closely with the main branch as you want
me to. Bug-fix stuff I'll prepare as patches straight into your trunk.
More special purpose functionality that I'm less confident that you'd
accept without discussion would need to live in a branch unless you in
fact have time to discuss it with me :-)
I think the limiting factor here is what time you have available for
discussion. As I work on this full-time and you probably must make do on
scrapes of time here and there, I see some danger that you wouldn't be
able to "keep up" with the decisions I must make as I go, and that some
temporary forking must happen here and there for that reason. This does
of course also depend on how much control you want to have over fwrap,
or if you're happy to let me loose on my own on the main branch :-)
Obviously, the more time we spend talking together, the more my work
will be in sync with your wishes for the fwrap code base. On my end, I
feel I can easily justify spending time to discuss issues with you
because it greatly reduces the risk of going in a wrong direction, and
also makes me find out how to do things quicker than if I have to go
look at the source code.
If you have time for it, it would be good to schedule a Skype session. I
already have a small list of decisions for the code base I'd like your
input on :-)
> At any rate, whatever improvements I make to fwrap in the coming
> months will likely be orthogonal to callbacks. The code could use
> some refactoring, to use the visitor pattern consistently throughout.
>> Some details:
>> a) The most important missing feature in fwrap is callbacks. I'm sure there
>> are other things I'll have to implement as well.
> There are differences between callbacks in f77 and callbacks in F90,
> using modern (Fortran 2003) features. So figuring out whether g77
> support is a requirement would be good to know before attacking this
> problem. F90 callbacks (using the 2003 features) are much stricter,
> and last time I looked not all compilers support all features that
> would be useful for callback support.
As all the code in SciPy is F77, that's what I'll need to support. I'm
trying to substitute f2py, and will try to emulate it as closely as is
If nothing else, it should at least get the ground well prepared for
callbacks on the Cython code generation side, where they ought to be
More information about the SciPy-Dev