On Fri, Jan 22, 2010 at 12:51 PM, Dag Sverre Seljebotn <da...@student.matnat.uio.no> wrote: > Kurt Smith wrote: >> On Fri, Jan 22, 2010 at 3:08 AM, Robert Bradshaw >> <rober...@math.washington.edu> wrote: >>> On Jan 22, 2010, at 12:40 AM, Stefan Behnel wrote: >>>> Robert Bradshaw, 22.01.2010 08:24: >> >>>> What about the Fortran integration? Is there anything we can add >>>> from that >>>> already? If we get a part of that in, we might be able to attract >>>> other >>>> Fortran users. Some of them may even end up participating in the >>>> further >>>> development. Putting this on more shoulders is the best way to push >>>> it further. >>> >>> That'd be nice as well, but it sounds like most of the focus of the >>> project right now is on build systems, and I'm not sure if it's set in >>> stone enough for people to start building codebases around. (I'd be >>> very glad to be wrong, if some of this is ready to go in, now would be >>> great time!) >> >> I'll pipe up here; sorry, been away from the mailing list for a while. >> >> For the record, the fortran project wasn't about providing explicit >> fortran support in Cython, but rather to use Cython as a way to help >> wrap fortran codes. As a necessary part of the project, Cython will >> gain support for memoryviews with a nice declaration syntax and the >> ability to pass these memoryviews as arguments to cdef functions, and >> some other features (declaring them as fields in extension types is >> another). These memoryviews are PEP 3118 buffers that are very >> flexible and can work with fortran arrays. They're updates and >> improvements to the existing buffer support in Cython. >> >> I'd very much like the Cython-side of the GSoC project to be merged >> into 0.13, but I'll have to coordinate with Dag and see what remains >> to be done. The main features are in place, but it's been a while >> since I've focused on this part of the project. I'm happy to devote >> my fwrap time to this to get it in for the 0.13 release. >> >> I'll be in touch with Dag and see what he has to say (or he might jump in >> here). > > If you're asking me what I think you should work on, then I think the > memoryviews should be rather low on the list; there's still a chance > I'll make some time for finishing those, and they're not strictly > needed, just convenient. > > So I'd have this priority: > 1) Rock stable Fortran parsing and wrapper generation (where you have > the advantage of knowing the internals better than anybody else that > might help) > 2) Build system (which somebody else might help with if 1) was just > working)
Yes, these two have been my priority. Since fwrap will be shipped separately from Cython, these can evolve on their own, and ideally (1) will be ready to go in a few months. (2) already works, using numpy.distutils and Cython.distutils, but I'd much prefer something else. Re: memoryviews: My preference would be to get the core functionality of memoryviews working and included in Cython 0.13, since this is a natural sub-project and would be nice to have in a distributed version. (By 'core functionality' I mean -- somewhat selfishly -- the memoryview functionality needed for fwrap :-) But it sounds like you would like to take the memoryviews further than what was done last summer, which is fine. How much of the memoryview support do you want implemented before merging with cython-dev? It would be good to have fwrap be able to work with either the existing buffers in Cython and the new memoryviews, so it ultimately doesn't matter if memoryviews are merged into 0.13. > 3) Memory views (which I might do at some point) > > Did you form any conclusions on the waf vs. scons vs. distutils side? As I mentioned -- distutils already work, but isn't nice. I'm fine with it for now. I haven't been able to test waf vs. scons yet but hope to soon. _______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
