#13157 closed defect (fixed)
inline_fortran is STILL broken on OS X
Reported by: | benjaminfjones | Owned by: | was |
---|---|---|---|
Priority: | major | Milestone: | sage-5.4 |
Component: | interfaces | Keywords: | fortran osx |
Cc: | kcrisman, mvngu, flawrence | Merged in: | sage-5.4.beta0 |
Authors: | Jeroen Demeyer | Reviewers: | Karl-Dieter Crisman, Benjamin Jones |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description (last modified by )
Despite #7465 being closed as "worksforme", the following snippet in the notebook in Sage-5.2 on Mac OS X 10.7.4 fails.
%fortran C FILE: FIB1.F SUBROUTINE FIB(A,N) C C CALCULATE FIRST N FIBONACCI NUMBERS C INTEGER N REAL*8 A(N) DO I=1,N IF (I.EQ.1) THEN A(I) = 0.0D0 ELSEIF (I.EQ.2) THEN A(I) = 1.0D0 ELSE A(I) = A(I-1) + A(I-2) ENDIF ENDDO END C END FILE FIB1.F
Here is the error in full: http://pastebin.com/iVBkjckp
Apply:
- 13157_inline_fortran.patch to the Sage library.
- 13157_scripts.patch to
$SAGE_ROOT/local/bin
.
Attachments (2)
Change History (15)
comment:1 Changed 10 years ago by
comment:2 Changed 10 years ago by
Wait, there is no sage_fortran
any more, so that doesn't make sense to apply anyway. And the current numpy code has
'linker_so' : [None, "-g", "-Wall"],
so the shared
business can't be the issue, or at least not in exactly the same way.
I can also confirm that this is not just a Lion issue; the same happens on 10.6.
comment:3 Changed 10 years ago by
- Description modified (diff)
- Summary changed from %fortran in the notebook (and fortran.eval on command line) is STILL broken on OS X to inline_fortran is STILL broken on OS X
Changed 10 years ago by
comment:4 Changed 10 years ago by
- Description modified (diff)
- Status changed from new to needs_review
Changed 10 years ago by
comment:5 Changed 10 years ago by
The file inline_fortan.py
still lacks documentation, but I don't feel like fixing that now. Needs testing and review.
comment:6 Changed 10 years ago by
Tested on Linux, OS X and OpenSolaris, works fine.
comment:7 Changed 10 years ago by
Any reviewers?
comment:8 follow-up: ↓ 9 Changed 10 years ago by
- Reviewers set to Karl-Dieter Crisman
This works fine on OS X now. The code changes are minimal and make sense - nice error test. I only tested this on OS X 10.7, not previous systems; I guess someone should test this doesn't break anything on Linux, and take jdemeyer's word for it on OpenSolaris.
Any reason for the change of standard error to standard output instead of the previous vice versa? It does seem more natural given the names of the terms, but I'm not a bash expert...
comment:9 in reply to: ↑ 8 Changed 10 years ago by
I tested this on many platforms and it works. Is that sufficient for positive review then?
Replying to kcrisman:
Any reason for the change of standard error to standard output instead of the previous vice versa? It does seem more natural given the names of the terms, but I'm not a bash expert...
The redirection
1>&2 >foo
is equivalent to
>foo
It's like saying: redirect stdout to stderr. Oh, never mind, redirect it to foo
instead. This doesn't really make sense, so I assume it's a mistake.
While
>foo 2>&1
means: redirect stdout to foo
. Now redirect stderr to the new stdout, which is foo
. This therefore redirects both stdout and stderr to foo
.
Off topic and just for educational value: the redirection
2>&1 >foo
would mean: redirect stderr to the current stdout. Now redirect stdout (but not stderr) to foo
.
comment:10 Changed 10 years ago by
- Reviewers changed from Karl-Dieter Crisman to Karl-Dieter Crisman, Benjamin Jones
- Status changed from needs_review to positive_review
I just tested on OS X 10.7, OS X 10.6, and Debian linux and it looks good to go.
comment:11 Changed 10 years ago by
- Milestone changed from sage-5.3 to sage-5.4
comment:12 Changed 10 years ago by
- Merged in set to sage-5.4.beta0
- Resolution set to fixed
- Status changed from positive_review to closed
comment:13 Changed 7 years ago by
- Description modified (diff)
Umm, there is something really odd here. The flags passed seem to indicate something went quite wrong. For instance, one bit is
What the heck?
No wonder the errors look like
I don't know how that verbiage got passed there, though.
Anyway, since
that means it's no surprise that at the end
though that is just a symptom.
Does ticket:8010:attachment:trac-8010_numpy.patch (sorry, can't get the link right) look like it might solve it for you, just on the off chance? One would have to make a new spkg, of course. But the patch was never applied, to my knowledge.