Re: [Numpy-discussion] How to test f2py?
David Cournapeau wrote: Kurt Smith wrote: I'm the developer of fwrap. It is coming along, but will be at least a month, likely two before the first release. (The main areas that need some TLC are the fortran parser and the build system; the build system will leverage numpy's distutils unless waf is easy to get working.) The first release will cover a large portion of f2py's current functionality, but I don't plan on having python callbacks working then. Callbacks will be a part of the second release. An issue that you should be aware of is that fwrap will not work with f77, and requires gfortran 4.3.3 or greater, since it uses C interoperability features not available in f77. (Fwrap will work with any 'modern' fortran compiler that has the basic C interoperability features implemented. Looking around it appears that all of them do have the basic set necessary, see [1]. So this only excludes f77.) By f77, do you mean g77, i.e. the fortran compiler in the GNU gcc 3.x suite ? If so, that's quite a bummer for scipy. I don't see us removing support for g77 in the short or even mid term (many distributions depend on it, and that's not counting windows where there is still no gcc 4.x official support from MinGW). Do you have a list somewhere of what exactly is required for fwrap from the fortran compiler ? I think f77 means Fortran 77 in general, including g77. (Of course, g77 that might be the only compiler left in daily use which only supports Fortran 77 and not also more modern Fortran.) Long-term: While Fortran 77 is not something fwrap targets today, I think it should be possible to add in some special-casing for f77-only support. Basically a command-line flag to fwrap to tell it not to use ISO C BINDING and assume Fortran 77 feature-level only. Kurt, what do you say? Do you chance on an estimate on how long would it take for (somebody else) to do that? (I'd think one basically has to make the same blatant assumptions that f2py makes about type conversion, name mangling etc., but that is also much less dangerous/error-prone for Fortran 77.) Dag Sverre ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
Dag Sverre Seljebotn wrote: (I'd think one basically has to make the same blatant assumptions that f2py makes about type conversion, name mangling etc., but that is also much less dangerous/error-prone for Fortran 77.) Everything related to name mangling can be handled by distutils/numscons, so this is not an issue (I am ready to help if necessary on that side). I don't really know the assumptions made by f2py otherwise: is it prevalent for most fortran compilers to pass most things by reference ? g77 uses the f2c convention I believe, but I don't know much about other compilers, especially proprietary ones, cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
On Fri, Feb 26, 2010 at 04:42, David Cournapeau da...@silveregg.co.jp wrote: I don't really know the assumptions made by f2py otherwise: is it prevalent for most fortran compilers to pass most things by reference ? I think that's part of the standardized semantics, yes. That said, some things in the C API like how to pass the length of a character string are not standardized and are sometimes passed by value. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
On Fri, Feb 26, 2010 at 8:06 AM, Robert Kern robert.k...@gmail.com wrote: On Fri, Feb 26, 2010 at 04:42, David Cournapeau da...@silveregg.co.jp wrote: I don't really know the assumptions made by f2py otherwise: is it prevalent for most fortran compilers to pass most things by reference ? I think that's part of the standardized semantics, yes. That said, some things in the C API like how to pass the length of a character string are not standardized and are sometimes passed by value. Old Fortran didn't use stacks, all the data was collected into a section of memory and the subroutine referenced that memory location; think of it as an anonymous common. The addition of stack variables and the possibility of recursion was an innovation and originally required a special declaration that the variable was local, i.e., on a stack. I don't know how modern Fortran is implemented but using references has a long tradition in the language. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
On Thu, Feb 25, 2010 at 7:18 PM, David Cournapeau da...@silveregg.co.jp wrote: Kurt Smith wrote: I'm the developer of fwrap. It is coming along, but will be at least a month, likely two before the first release. (The main areas that need some TLC are the fortran parser and the build system; the build system will leverage numpy's distutils unless waf is easy to get working.) The first release will cover a large portion of f2py's current functionality, but I don't plan on having python callbacks working then. Callbacks will be a part of the second release. An issue that you should be aware of is that fwrap will not work with f77, and requires gfortran 4.3.3 or greater, since it uses C interoperability features not available in f77. (Fwrap will work with any 'modern' fortran compiler that has the basic C interoperability features implemented. Looking around it appears that all of them do have the basic set necessary, see [1]. So this only excludes f77.) By f77, do you mean g77, i.e. the fortran compiler in the GNU gcc 3.x suite ? Yes, my bad. For some reason 'apt-cache search' finds 'f77' but not 'g77' here. Fwrap makes use of the ISO C BINDING intrinsic module and BIND(C) attributes heavily -- compilers that handle *only* Fortran 77 code don't have this. If so, that's quite a bummer for scipy. I don't see us removing support for g77 in the short or even mid term (many distributions depend on it, and that's not counting windows where there is still no gcc 4.x official support from MinGW). Do you have a list somewhere of what exactly is required for fwrap from the fortran compiler ? Not a comprehensive list, although that would be good to draw up. I'll do that soon. It is entirely possible to add in support for FORTRAN 77-only stuff, to allow g77 to be supported. Since g77 is important to support in scipy it's probably worth the effort. But that will have to come later (over the summer); it wouldn't be too hard. The reason for the new stuff isn't purely academic, either -- it allows interoperability between C structs and Fortran derived types, and greatly improves portability, to the point that fwrap doesn't need to be installed for the wrapped code to compile (similar to Cython-generated code). Kurt cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
On Fri, Feb 26, 2010 at 2:44 AM, Dag Sverre Seljebotn da...@student.matnat.uio.no wrote: David Cournapeau wrote: Kurt Smith wrote: I'm the developer of fwrap. It is coming along, but will be at least a month, likely two before the first release. (The main areas that need some TLC are the fortran parser and the build system; the build system will leverage numpy's distutils unless waf is easy to get working.) The first release will cover a large portion of f2py's current functionality, but I don't plan on having python callbacks working then. Callbacks will be a part of the second release. An issue that you should be aware of is that fwrap will not work with f77, and requires gfortran 4.3.3 or greater, since it uses C interoperability features not available in f77. (Fwrap will work with any 'modern' fortran compiler that has the basic C interoperability features implemented. Looking around it appears that all of them do have the basic set necessary, see [1]. So this only excludes f77.) By f77, do you mean g77, i.e. the fortran compiler in the GNU gcc 3.x suite ? If so, that's quite a bummer for scipy. I don't see us removing support for g77 in the short or even mid term (many distributions depend on it, and that's not counting windows where there is still no gcc 4.x official support from MinGW). Do you have a list somewhere of what exactly is required for fwrap from the fortran compiler ? I think f77 means Fortran 77 in general, including g77. (Of course, g77 that might be the only compiler left in daily use which only supports Fortran 77 and not also more modern Fortran.) Long-term: While Fortran 77 is not something fwrap targets today, I think it should be possible to add in some special-casing for f77-only support. Basically a command-line flag to fwrap to tell it not to use ISO C BINDING and assume Fortran 77 feature-level only. Kurt, what do you say? Do you chance on an estimate on how long would it take for (somebody else) to do that? Once fwrap has blazed a trail for all the main features, including procedure arguments, then it wouldn't be too hard, since 'nice' 77 code is a subset. I'd prefer not to get into the dark corners of 77 stuff, though, like ENTRY statements and statement functions. But if patches come to support these features, who am I to refuse :) How long would it take? I'd rather not hazard a guess. If it is critical for scipy then it will be bumped up on the priority list, though. I don't mean to sound like I assume fwrap will be *the* fortran wrapper for scipy. f2py has worked very well as proven by scipy's success. There is much overlap between their functionality, but they take different approaches. I realize that if fwrap doesn't work well with numpy/scipy then it really isn't useful.The intersection between python users and numerical programmers using fortran ain't that big. If at some point fwrap is used as the fortran wrapper for scipy, then it's fine by me. But that's up to David, Chuck, Travis, et alia. (I'd think one basically has to make the same blatant assumptions that f2py makes about type conversion, name mangling etc., but that is also much less dangerous/error-prone for Fortran 77.) Dag Sverre ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
On Fri, Feb 26, 2010 at 4:42 AM, David Cournapeau da...@silveregg.co.jp wrote: Dag Sverre Seljebotn wrote: (I'd think one basically has to make the same blatant assumptions that f2py makes about type conversion, name mangling etc., but that is also much less dangerous/error-prone for Fortran 77.) Everything related to name mangling can be handled by distutils/numscons, so this is not an issue (I am ready to help if necessary on that side). That's good and will make it easier to support 77-only code in fwrap. I don't really know the assumptions made by f2py otherwise: is it prevalent for most fortran compilers to pass most things by reference ? g77 uses the f2c convention I believe, but I don't know much about other compilers, especially proprietary ones, I'm no expert on 77 stuff, but at least with the standardization of the C interoperability features in the 2003 standard, everything is passed by reference by default between Fortran and C (for the non-opaque types, which are the only allowed arguments between Fortran C). The 'VALUE' keyword was added to the language to allow arguments to be passed by value. Some compilers supported the VALUE kw before the 2003 standard came out (Sun's fortran compiler, for one). Kurt ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
Charles R Harris wrote: On Wed, Feb 24, 2010 at 1:15 AM, David Cournapeau courn...@gmail.com mailto:courn...@gmail.com wrote: On Wed, Feb 24, 2010 at 1:51 PM, Charles R Harris charlesr.har...@gmail.com mailto:charlesr.har...@gmail.com wrote: Boy, that code is *old*, it still uses Numeric ;) I don't think it can really be considered a test suite, it needs lotsa love and it needs to get installed. Anyway, f2py with py3k turns out to have string problems, and I expect other type problems, so there is considerable work that needs to be done to bring it up to snuff. Sounds like gsoc material. I'm not going to worry about it any more until later. If it would take a GSoC to make it up to work, it may be time better spent on improving fwrap. How far along is fwrap? It looks like f2py2e was a project that got dropped half way through an update, some exceptions are of the wrong type, the tests need a complete rewrite, etc. Well, the f2py as included in numpy is at least stable, since it has been used with little to no change for scipy the last few years, whereas fwrap is largely untested on the scale of something like scipy. I was suggesting to look into fwrap *if* f2py would be really hard to make to work for python 3.x. What worries me for f2py is not so much the python code (at worst, we could hack something to call f2py through python 2.x for the 3.x build - numscons runs f2py out of process for // build) as much as the generated C code. Debugging code generators is rarely fun in my experience :) cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
On Thu, Feb 25, 2010 at 8:39 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Feb 25, 2010 at 1:07 AM, David Cournapeau da...@silveregg.co.jp wrote: Charles R Harris wrote: On Wed, Feb 24, 2010 at 1:15 AM, David Cournapeau courn...@gmail.com mailto:courn...@gmail.com wrote: On Wed, Feb 24, 2010 at 1:51 PM, Charles R Harris charlesr.har...@gmail.com mailto:charlesr.har...@gmail.com wrote: Boy, that code is *old*, it still uses Numeric ;) I don't think it can really be considered a test suite, it needs lotsa love and it needs to get installed. Anyway, f2py with py3k turns out to have string problems, and I expect other type problems, so there is considerable work that needs to be done to bring it up to snuff. Sounds like gsoc material. I'm not going to worry about it any more until later. If it would take a GSoC to make it up to work, it may be time better spent on improving fwrap. How far along is fwrap? It looks like f2py2e was a project that got dropped half way through an update, some exceptions are of the wrong type, the tests need a complete rewrite, etc. Well, the f2py as included in numpy is at least stable, since it has been used with little to no change for scipy the last few years, whereas fwrap is largely untested on the scale of something like scipy. I was suggesting to look into fwrap *if* f2py would be really hard to make to work for python 3.x. What worries me for f2py is not so much the python code (at worst, we could hack something to call f2py through python 2.x for the 3.x build - numscons runs f2py out of process for // build) as much as the generated C code. Debugging code generators is rarely fun in my experience :) It might not be too difficult to get f2py running with Python3.x. At first try there were some places in the generated code that called Python string functions that have gone away, but those should be fixable without too much trouble. There may be a few other troublesome spots, but I don't think things will be that difficult. I'm more concerned for the long run. The code needs a fixed up test suite, it needs documentation, and it needs a maintainer, at least for a while. Glad I came across this thread :) I'm the developer of fwrap. It is coming along, but will be at least a month, likely two before the first release. (The main areas that need some TLC are the fortran parser and the build system; the build system will leverage numpy's distutils unless waf is easy to get working.) The first release will cover a large portion of f2py's current functionality, but I don't plan on having python callbacks working then. Callbacks will be a part of the second release. An issue that you should be aware of is that fwrap will not work with f77, and requires gfortran 4.3.3 or greater, since it uses C interoperability features not available in f77. (Fwrap will work with any 'modern' fortran compiler that has the basic C interoperability features implemented. Looking around it appears that all of them do have the basic set necessary, see [1]. So this only excludes f77.) Fwrap by design will work seamlessly with numpy arrays and PEP 3118 buffers [2], and will support Python 2.4 - 3.x (thanks in large part to its leveraging Cython for the C wrappers). It has an expanding testsuite (unittests acceptance tests) and I hope it's designed clearly enough to encourage contributions after the first release. You can trust its C generation as far as you trust Cython's C generation. Although I guess you'll have to trust fwrap's Fortran Cython generation :) But like I said, it has a testsuite that has everything covered. So, to recap: fwrap will do much of what you want, but it will exclude f77, and has a Cython dependency. It won't have callbacks working right away, but will by the second release. When its matured enough I'd like to get fwrap to generate the bindings for scipy. Once it gets to that point (sometime this summer) we can talk :) As far as the 'long run' goes: fwrap has and will have a test suite, documentation and a maintainer, so those are covered. For more information: Fwrap's blog: http://fortrancython.wordpress.com/ Fwrap's bitbucket repository: http://bitbucket.org/kwmsmith/fwrap-dev/ ...which is a mirror of it's cython repo: http://hg.cython.org/fwrap-dev/ Feel free to contact me with any more questions. Thanks, Kurt [1] http://tinyurl.com/yjgtpqp [2] http://www.python.org/dev/peps/pep-3118/ ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
Kurt Smith wrote: I'm the developer of fwrap. It is coming along, but will be at least a month, likely two before the first release. (The main areas that need some TLC are the fortran parser and the build system; the build system will leverage numpy's distutils unless waf is easy to get working.) The first release will cover a large portion of f2py's current functionality, but I don't plan on having python callbacks working then. Callbacks will be a part of the second release. An issue that you should be aware of is that fwrap will not work with f77, and requires gfortran 4.3.3 or greater, since it uses C interoperability features not available in f77. (Fwrap will work with any 'modern' fortran compiler that has the basic C interoperability features implemented. Looking around it appears that all of them do have the basic set necessary, see [1]. So this only excludes f77.) By f77, do you mean g77, i.e. the fortran compiler in the GNU gcc 3.x suite ? If so, that's quite a bummer for scipy. I don't see us removing support for g77 in the short or even mid term (many distributions depend on it, and that's not counting windows where there is still no gcc 4.x official support from MinGW). Do you have a list somewhere of what exactly is required for fwrap from the fortran compiler ? cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
On Wed, Feb 24, 2010 at 1:51 PM, Charles R Harris charlesr.har...@gmail.com wrote: Boy, that code is *old*, it still uses Numeric ;) I don't think it can really be considered a test suite, it needs lotsa love and it needs to get installed. Anyway, f2py with py3k turns out to have string problems, and I expect other type problems, so there is considerable work that needs to be done to bring it up to snuff. Sounds like gsoc material. I'm not going to worry about it any more until later. If it would take a GSoC to make it up to work, it may be time better spent on improving fwrap. Maybe Pearu would have some ideas, but the problem I see with f2py today is that it is pretty much Pearu's work only, and given that the code has a relatively low unit test suite, the code is not that easy to dive in for someone else. cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
I don't think the situation is that bad with f2py. I suppose it will be enough to erect unicode vs. Bytes barrier where the file i/o is done, and let f2py work internally with unicode. Doesn't sound so bad, but I'd have to take a closer look. -- Pauli Virtanen - Alkuperäinen viesti - On Wed, Feb 24, 2010 at 1:51 PM, Charles R Harris charlesr.har...@gmail.com wrote: Boy, that code is *old*, it still uses Numeric ;) I don't think it can really be considered a test suite, it needs lotsa love and it needs to get installed. Anyway, f2py with py3k turns out to have string problems, and I expect other type problems, so there is considerable work that needs to be done to bring it up to snuff. Sounds like gsoc material. I'm not going to worry about it any more until later. If it would take a GSoC to make it up to work, it may be time better spent on improving fwrap. Maybe Pearu would have some ideas, but the problem I see with f2py today is that it is pretty much Pearu's work only, and given that the code has a relatively low unit test suite, the code is not that easy to dive in for someone else. cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
On Wed, Feb 24, 2010 at 5:19 PM, Pauli Virtanen p...@iki.fi wrote: I don't think the situation is that bad with f2py. I suppose it will be enough to erect unicode vs. Bytes barrier where the file i/o is done, and let f2py work internally with unicode. Doesn't sound so bad, but I'd have to take a closer look. How did you handle name clash in numpy for 2to3 ? For example, f2py uses things like dict quite a lot as argument for functions, and it does not look like 2to3 handles this (or does it ?). Of course, I could try a brute force sed script as a pre-processing step, but maybe you got a better way of doing this, cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
ke, 2010-02-24 kello 17:33 +0900, David Cournapeau kirjoitti: On Wed, Feb 24, 2010 at 5:19 PM, Pauli Virtanen p...@iki.fi wrote: I don't think the situation is that bad with f2py. I suppose it will be enough to erect unicode vs. Bytes barrier where the file i/o is done, and let f2py work internally with unicode. Doesn't sound so bad, but I'd have to take a closer look. How did you handle name clash in numpy for 2to3? For example, f2py uses things like dict quite a lot as argument for functions, and it does not look like 2to3 handles this (or does it ?). I suppose you mean using dict as a variable name, and f2py using types.DictType which is dict in Py3? 2to3 does not handle those. Using builtin names as variable names is bad practice, so when I met that in SVN, I just changed the variable names to something more sane. Of course, I could try a brute force sed script as a pre-processing step, but maybe you got a better way of doing this, The best alternative, imho, is not to use dict as a variable name at all. We should make that change manually in SVN sources, both for Py2 and Py3. Grepping the f2py source shows that this problem occurs only in auxfunc.replace, so changing that shouldn't be too much work. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
Pauli Virtanen wrote: The best alternative, imho, is not to use dict as a variable name at all. We should make that change manually in SVN sources, both for Py2 and Py3. Agreed - the changes should be put in the sources. Will do so tonight after work unless someone beats me to it. Grepping the f2py source shows that this problem occurs only in auxfunc.replace, so changing that shouldn't be too much work. I am playing a bit with fftpack, and very few modifications are needed for f2py to run on it. Now, I just have to fix the generated C code to see what's going on. David P.S: is it expected that numpy cannot be built in-place correctly under py3k ? ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
ke, 2010-02-24 kello 18:04 +0900, David Cournapeau kirjoitti: [clip] P.S: is it expected that numpy cannot be built in-place correctly under py3k? Yes, unfortunately. 2to3 cannot really be run in-place, and I did not want to engage distutils in a fight how to read the sources from a different location. So how it works now is that first a complete Py3 converted copy is made in build/py3k, and then the setup.py there is run. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
On Wed, Feb 24, 2010 at 1:15 AM, David Cournapeau courn...@gmail.comwrote: On Wed, Feb 24, 2010 at 1:51 PM, Charles R Harris charlesr.har...@gmail.com wrote: Boy, that code is *old*, it still uses Numeric ;) I don't think it can really be considered a test suite, it needs lotsa love and it needs to get installed. Anyway, f2py with py3k turns out to have string problems, and I expect other type problems, so there is considerable work that needs to be done to bring it up to snuff. Sounds like gsoc material. I'm not going to worry about it any more until later. If it would take a GSoC to make it up to work, it may be time better spent on improving fwrap. How far along is fwrap? It looks like f2py2e was a project that got dropped half way through an update, some exceptions are of the wrong type, the tests need a complete rewrite, etc. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
On Tue, Feb 23, 2010 at 21:14, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, I've made PyCObject - PyCapsule changes to f2py for python3.1. How can I check that f2py still works as advertised before making a commit? numpy/f2py/tests/run_all.py -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
On Tue, Feb 23, 2010 at 8:31 PM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 21:14, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, I've made PyCObject - PyCapsule changes to f2py for python3.1. How can I check that f2py still works as advertised before making a commit? numpy/f2py/tests/run_all.py It's not py3k compatible... also it doesn't find the f2py2e module even though it has been installed with numpy. ? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
On Tue, Feb 23, 2010 at 21:51, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, Feb 23, 2010 at 8:31 PM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 21:14, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, I've made PyCObject - PyCapsule changes to f2py for python3.1. How can I check that f2py still works as advertised before making a commit? numpy/f2py/tests/run_all.py It's not py3k compatible... So make it py3k compatible. also it doesn't find the f2py2e module even though it has been installed with numpy. ? I don't understand this. Error message? -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
On Tue, Feb 23, 2010 at 22:12, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, Feb 23, 2010 at 8:54 PM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 21:51, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, Feb 23, 2010 at 8:31 PM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 21:14, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, I've made PyCObject - PyCapsule changes to f2py for python3.1. How can I check that f2py still works as advertised before making a commit? numpy/f2py/tests/run_all.py It's not py3k compatible... So make it py3k compatible. It's autoconverted in build/py3k. It is, however, not installed anywhere. also it doesn't find the f2py2e module even though it has been installed with numpy. ? I don't understand this. Error message? Running /usr/bin/python /home/charris/Workspace/numpy.git/numpy/f2py/tests/f77/return_character.py 10 --quiet Traceback (most recent call last): File /home/charris/Workspace/numpy.git/numpy/f2py/tests/f77/return_character.py, line 10, in module import f2py2e ImportError: No module named f2py2e TEST FAILURE (status=1) So the import is wrong. The question is: did this used to work? From the independent f2py2e days, yes. Just change those import lines to from numpy import f2py as f2py2e. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
On Tue, Feb 23, 2010 at 9:19 PM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 22:12, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, Feb 23, 2010 at 8:54 PM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 21:51, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, Feb 23, 2010 at 8:31 PM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 21:14, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, I've made PyCObject - PyCapsule changes to f2py for python3.1. How can I check that f2py still works as advertised before making a commit? numpy/f2py/tests/run_all.py It's not py3k compatible... So make it py3k compatible. It's autoconverted in build/py3k. It is, however, not installed anywhere. also it doesn't find the f2py2e module even though it has been installed with numpy. ? I don't understand this. Error message? Running /usr/bin/python /home/charris/Workspace/numpy.git/numpy/f2py/tests/f77/return_character.py 10 --quiet Traceback (most recent call last): File /home/charris/Workspace/numpy.git/numpy/f2py/tests/f77/return_character.py, line 10, in module import f2py2e ImportError: No module named f2py2e TEST FAILURE (status=1) So the import is wrong. The question is: did this used to work? From the independent f2py2e days, yes. Just change those import lines to from numpy import f2py as f2py2e Boy, that code is *old*, it still uses Numeric ;) I don't think it can really be considered a test suite, it needs lotsa love and it needs to get installed. Anyway, f2py with py3k turns out to have string problems, and I expect other type problems, so there is considerable work that needs to be done to bring it up to snuff. Sounds like gsoc material. I'm not going to worry about it any more until later. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
