Tests not doing anything
Kyle Mandli
I have everything running before next week but I am getting the
following:
[mandli@Tiberius:fwrap-dev] python runtests.py –fcompiler=ifort –no-
cleanup
Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29)
[GCC 4.2.1 (Apple Inc. build 5646)]
----------------------------------------------------------------------
Ran 0 tests in 0.000s
OK
and when I try
python runnose.py –fcompiler=ifort –no-cleanup
I get
Not implemented: Defined_Binary_Op
Not implemented: Defined_Binary_Op
Defined_Operator not defined used by Generic_Spec
...........................................................................................using
cached string-4315740744
.using cached string-4315740744
.using cached string-4315740744
.using cached string-4315740744
.using cached string-4315740744
.using cached string-4315740744
.............
----------------------------------------------------------------------
Ran 109 tests in 0.072s
OK
I am running with Mac OS 10.6.4, numpy 1.4, cython 0.12.1. Is this
what I should be seeing?
Kurt Smith
> I have been attempting to run the current tests in fwrap to make sure
> I have everything running before next week but I am getting the
> following:
>
> [mandli@Tiberius:fwrap-dev] python runtests.py –fcompiler=ifort –no-
> cleanup
> Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29)
> [GCC 4.2.1 (Apple Inc. build 5646)]
>
> ----------------------------------------------------------------------
> Ran 0 tests in 0.000s
>
> OK
I've been working on making the runtests.py script a bit more
user-friendly. I'll look into this shortly. It may be that you need
to use '--fcompiler=intelem' rather than '--fcompiler=ifort'; at least
that's what I need to do on my box.
For now, you could try the following commandline:
$ F90=<full path to ifort> python runtests.py -vv --fcompiler=intelem
--no-cleanup
(note the '-vv' flag to make it a bit more verbose). Paste the output
in your reply.
>
> and when I try
>
> python runnose.py –fcompiler=ifort –no-cleanup
>
> I get
>
> Not implemented: Defined_Binary_Op
> Not implemented: Defined_Binary_Op
> Defined_Operator not defined used by Generic_Spec
> ...........................................................................................using
> cached string-4315740744
> .using cached string-4315740744
> .using cached string-4315740744
> .using cached string-4315740744
> .using cached string-4315740744
> .using cached string-4315740744
> .............
> ----------------------------------------------------------------------
> Ran 109 tests in 0.072s
>
> OK
All the noisy stuff you see is output from fparser, which is quite
verbose. I'll try and silence it some more.
The unittests all run and pass fine.
Which revision of fwrap/fparser are you using?
>
> I am running with Mac OS 10.6.4, numpy 1.4, cython 0.12.1. Is this
> what I should be seeing?
>
> --
> 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.
>
>
Kyle Mandli
Kurt Smith
<man...@amath.washington.edu> wrote:
> I am currently using the newest versions from the repos for fwrap/fparser.
> I did the following
> F90=/opt/intel/Compiler/11.1/088/bin/intel64/ifort python runtests.py -vv
> --fcompiler=intelem --no-cleanup
> and got the errors in error_1.txt. Looking at the output, my guess would be
> that ifort is rejecting the file suffixes because they are .f95 rather than
> .f90. I changed some of them and they seemed to work except for a couple of
> tests. The second attachment error2.txt is the resulting output.
Heh. I was testing ifort on a linux box right around the same time,
and ran into the same errors. I changed the .f95 to .f90 in a recent
changeset. Do a $ hg pull -u to get the latest changes.
All but one of the tests should run fine with the above commandline.
You'll need to add another commandline option (LDFLAGS) to tell fwrap
how to link with the ifort core libraries (I hope to improve this
aspect of things -- lots of these annoyances have to do with
numpy.distutils and I'm smoothing out the kinks). Try this:
$ F90=$IFORTBASE/bin/intel64/ifort LDFLAGS='-L$IFORTBASE/lib/intel64
-lifcore' python runtests.py -vv --fcompiler=intelem --no-cleanup
where IFORTBASE=/opt/intel/Compiler/11.1/064 on my box.
If you could let me know whether all your tests pass with this I'd
appreciate it.
BTW, I'm glad to see that you'll be at SciPy 2010. Looking forward to
it. There will be an fwrap sprint for the last 2 days, if you'll be
around for it. Don't know if you have anything else planned.
Thanks,
Kurt
Kurt Smith
> On Tue, Jun 22, 2010 at 12:17 AM, Kyle Mandli
> <man...@amath.washington.edu> wrote:
>> I am currently using the newest versions from the repos for fwrap/fparser.
>> I did the following
>> F90=/opt/intel/Compiler/11.1/088/bin/intel64/ifort python runtests.py -vv
>> --fcompiler=intelem --no-cleanup
>> and got the errors in error_1.txt. Looking at the output, my guess would be
>> that ifort is rejecting the file suffixes because they are .f95 rather than
>> .f90. I changed some of them and they seemed to work except for a couple of
>> tests. The second attachment error2.txt is the resulting output.
>
> Heh. I was testing ifort on a linux box right around the same time,
> and ran into the same errors. I changed the .f95 to .f90 in a recent
> changeset. Do a $ hg pull -u to get the latest changes.
>
> All but one of the tests should run fine with the above commandline.
> You'll need to add another commandline option (LDFLAGS) to tell fwrap
> how to link with the ifort core libraries (I hope to improve this
> aspect of things -- lots of these annoyances have to do with
> numpy.distutils and I'm smoothing out the kinks). Try this:
>
> $ F90=$IFORTBASE/bin/intel64/ifort LDFLAGS='-L$IFORTBASE/lib/intel64
> -lifcore' python runtests.py -vv --fcompiler=intelem --no-cleanup
Whoops, you'll need to make that double quotes rather than single:
Kyle Mandli
Kurt Smith
<man...@amath.washington.edu> wrote:
>> I tried adding the LDFLAGS variable but it did not seem to help things
>> (attached output again). Some of the errors look like conversion errors (is
>> that what the difference between 11 and 11L is?).
Did you pull the most recent revision? What is the output of
$ hg identify
and
$ hg parent
The errors you see are all ones I encountered and fixed in recent
revisions -- I'm using ifort on a linux box so there shouldn't be
platform issues.
>> I will be at Scipy for the entire week including most of the sprints (I
>> leave the evening of Saturday). I was planning on working on fwrap
>> primarily there so hopefully we can work on some of the last issues and
>> discuss the future.
>>
Good to hear.
Kyle Mandli
Kurt Smith
<man...@amath.washington.edu> wrote:
> This is what I have
> $ hg identify
> e2ecf725b1f7+
> $ hg parent
> changeset: 205:e2ecf725b1f7
> user: kwmsmith <kwms...@gmail.com>
> date: Mon Jun 21 19:19:51 2010 -0500
> summary: test that compiled extension modules are importable
I see. There have been a few commits since then -- do a pull and an
update to get the latest changes, and that should fix the issues.
Thanks for the help.
Kyle Mandli
Kurt Smith
<man...@amath.washington.edu> wrote:
> All the tests work now!
Good :-)
> I will try to use some of my own code now and see what happens.
I've been focusing on getting the core modules tested; you'll quickly
find that the fwrap.py script needs some TLC. It isn't very user
friendly or 'discoverable'. This is next on the docket. I'll get to
it in the next day or so.
Kurt