Work on fwrap and SciPy
Dag Sverre Seljebotn
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.
All work is done in Enthought's "refactor" branches for now [1]. 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.
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.
b) The main strategy is to first move (our own branch of) SciPy over
to fwrap and have that work on CPython, and then move to compiling
things on .NET
c) fwrap does not support g77, only Fortran 90 compilers like
gfortran/ifort etc. For the purposes of the .NET port this is likely to
be good enough. Before a merge with the main CPython branch one must
perhaps look into implementing g77 support in fwrap. I know that David
C. at least earlier stated that g77 support is not going away anytime
soon. Feedback on this welcome.
Dag Sverre
[1]
http://github.com/teoliphant/numpy-refactor
http://github.com/jasonmccampbell/scipy-refactor
Kyle Mandli
--
You received this message because you are subscribed to the Google Groups "Fwrap Users" group.
To post to this group, send email to fwrap...@googlegroups.com.
To unsubscribe from this group, send email to fwrap-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fwrap-users?hl=en.
Dag Sverre Seljebotn
Hi Dag,
As far as I am aware, fwrap is dependent on the C-Fortran bindings that are only included in gfortran (and other similar compilers). In fact, gfortran only supports these iso bindings for versions > 4.4 (Kurt may have to correct me on that one as I do not quite remember the actual version). What exactly "needs" g77 or is this a requirement that fwrap be able to handle fortran 77 (the language that is)?
Rationale: I think it is simply a matter of compiler availability and backwards compatability. NumPy and SciPy are heavily depended upon by lots of people, and requiring a modern gfortran could break stuff for people (or at least cause a major inconvenience on upgrades). However, in a transition to NumPy 2.0, perhaps one can argue for it. We'll have to see. This is simply something that the NumPy and SciPy communities need to discuss. The project should go on a little further (I should have something working to show people) before I'll raise the issue more directly. So let's leave it until we know whether it's an issue :-)
Dag Sverre
Dag Sverre Seljebotn
> Hi,> ...
>
>> All work is done in Enthought's "refactor" branches for now [1]. 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.
>>
>
> One worry would be that if the divergence gets too large, it will not
> be possible to review the changes.
>
Speaking about the Fortran part only, I honestly don't expect anybody
else to do major rewrites of the f2py wrappers (.pyf files) while this
is going on; any (unlikely) minor tweaks can readily be merged (provided
a decision is made for SciPy on CPython to move from f2py to fwrap).
I can try to keep the replacement of f2py with fwrap in a seperate
branch that could potentially be merged without taking the other stuff
from the .NET branch. Not sure whether that will succeed yet, but it is
definitely worth a try. So perhaps one can have two or three branches
with different kinds of changes rather than one large one. Replacing
f2py with fwrap seems to be orthogonal to changes that has to do with
changes necessitated by the refactoring of NumPy, but I don't know yet
whether that will hold true in practice.
(For non-Fortran it would be better to start a new thread on the .NET
refactoring in general and ask Jason McCampbell, I can't tell.)
Dag Sverre
Kurt Smith
<da...@student.matnat.uio.no> 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 [1]. 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.
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.
> b) The main strategy is to first move (our own branch of) SciPy over to
> fwrap and have that work on CPython, and then move to compiling things on
> .NET
>
> c) fwrap does not support g77, only Fortran 90 compilers like
> gfortran/ifort etc. For the purposes of the .NET port this is likely to be
> good enough. Before a merge with the main CPython branch one must perhaps
> look into implementing g77 support in fwrap. I know that David C. at least
> earlier stated that g77 support is not going away anytime soon. Feedback on
> this welcome.
>
I'm interested to hear what DC has to say...
Dag Sverre Seljebotn
> On Wed, Nov 3, 2010 at 5:26 AM, Dag Sverre Seljebotn
> <da...@student.matnat.uio.no> 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 [1]. 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
reasonable.
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
very similar.
Dag Sverre