This question already has answers here:
Does Fortran preserve the value of internal variables through function and subroutine calls?
(3 answers)
Why is there an implied SAVE attribute in Fortran? [duplicate]
(1 answer)
Fortran assignment on declaration and SAVE attribute gotcha
(2 answers)
Closed 4 years ago.
[EDITORIAL: I have read this question but (while in hindsight it is ultimately related in the same way that every question here is related -- i.e., "Why do computers malfunction?") that answer is not the answer to my question. That question is asking why a standards body designed a specific feature into the language. And, the answer does not answer my question which is asking what have I missed in debugging this issue.]
QUESTION: Why does the output from this Fortran program (ExhaustiveListing.f08 + unicodeSupport.f08) shown below indicate that Fortran's DO WHILE has a major bug?
Here's the output followed by environment description and, finally, the source code of the two files in question:
UNEXPECTED OUTPUT
Hex is now: 2500H.
2500─
2501━
2502│
2503┃
2504┄
2505┅
2506┆
2507┇
2508┈
2509┉
250A┊
250B┋
250C┌
250D┍
250E┎
250F┏
Hex is now: 2510H.
Hex is now: 2520H.
Hex is now: 2530H.
Hex is now: 2540H.
Hex is now: 2550H.
Hex is now: 2560H.
Hex is now: 2570H.
RUN FINISHED; exit value 0; real time: 530ms; user: 0ms; system: 0ms
EXPECTED OUTPUT
I expected to have 16 lines of detail between each "Hex is now: xxxxH" line such as that printed between the 2500H and 2510H lines.
PREVIOUS ATTEMPTS TO RESOLVE ISSUE
This program is my attempt to resolve an issue in a much larger project. Having issues with that project (one such problem revolving around working with Unicode in Fortran), I created this project to isolate the Unicode issue. At first, I had the trivial unicodeSupport module combined in the same file as the main program. I removed it into its own file. No, it should not matter and -- it did not affect the outcome. This program is so plainly simple, I cannot see anything which I might be doing wrong. Hence, my coming to SO in hopes that new eyes discover my blunder. Else, it's time to file bug report with gFortran.
ENVIRONMENT
The environment that I'm working in is:
OS: Ubuntu 17.10
IDE: Netbeans 8.2
JDK: Oracle (build 1.8.0_161-b12)
COMPILER: gFortran 7.2.0
COMPILER FLAGS: -std=f2008ts -fno-unsafe-math-optimizations -frounding-math -fsignaling-nans
theGeeko61: 4 decades developing in BASIC, Pascal, FORTRAN, C, Prolog, C++, Java, many others (sorted chronologically by the order in which I learned them)
ExhaustiveListing.f08
! File: ExhaustiveListing.f08
! Author: geeko
!
! Created on March 25, 2018, 7:05 PM
!
! ☐ U2610 ☑ U2611 ☒ U2612
! Use above symbols for indicating items to
! be tested (☐), and items which have either
! passed (☑) or failed (☒) testing.
!
SUBROUTINE displayLine(hex)
USE unicodeSupport
IMPLICIT NONE
INTEGER :: hex, counter=0, point
DO WHILE (counter < 16)
point = hex+counter
WRITE(*,'(Z4.4,A)') point, CHAR(INT(point), ucs4)
counter = counter+1
END DO
END SUBROUTINE
PROGRAM ExhaustiveListingOfUnicodeBoxDrawingChars ! ☒
USE ISO_FORTRAN_ENV
USE unicodeSupport
!!!!!USE testUnicodeSupport ! ☑
IMPLICIT NONE
INTEGER :: hex
open(output_unit, encoding='UTF-8')
hex = 9472
DO WHILE(hex<9600)
PRINT '(A,Z4.4,A)', "Hex is now: ", hex, "H."
CALL displayLine(hex) ! ☒
hex = hex+16
END DO
!!!!CALL performTest() ! ☑
END PROGRAM ExhaustiveListingOfUnicodeBoxDrawingChars
unicodeSupport.f08
! File: unicodeSupport.f08
! Author: geeko
!
! Created on March 25, 2018, 10:09 PM
!
MODULE unicodeSupport
INTEGER, PARAMETER :: ASCII = SELECTED_CHAR_KIND('ASCII')
INTEGER, PARAMETER :: UCS4 = SELECTED_CHAR_KIND('ISO_10646')
END MODULE unicodeSupport
The variable counter declared here
INTEGER :: hex, counter=0, point
possesses the save attribute by virtue of having its value defined on the initialization line.
The second time you enter the subroutine, its value will be 16 and hence there will be no loop.
Remove =0 from the declaration line and write
counter = 0
afterwards.
Related
I downloaded and set up PintOS and the dependencies on my home computer, but when I try to run pintos run alarm-multiple, I get the error:
Unrecognized character \x16; marked by <-- HERE after if ($<-- HERE near column 7 at ~/code/pintos/src/utils/pintos line 911.
That line has ^V on it, the synchronous idle control character. I haven't been able to find any information on this problem; it seems like I'm the only one experiencing it.
I have Perl v5.26.0 installed.
Use of literal control characters in variable names was deprecated in Perl 5.20:
Literal control characters in variable names
This deprecation affects things like $\cT, where \cT is a literal control (such as a NAK or NEGATIVE ACKNOWLEDGE character) in the source code. Surprisingly, it appears that originally this was intended as the canonical way of accessing variables like $^T, with the caret form only being added as an alternative.
The literal control form is being deprecated for two main reasons. It has what are likely unfixable bugs, such as $\cI not working as an alias for $^I, and their usage not being portable to non-ASCII platforms: While $^T will work everywhere, \cT is whitespace in EBCDIC. [perl #119123]
The code causing this problem was fixed in PintOS with this commit in 2016:
committer Ben Pfaff <blp#cs.stanford.edu>
Tue, 9 Feb 2016 04:47:10 +0000 (20:47 -0800)
Modern versions of Perl prefer a caret in variable names over literal
control characters and issue a warning if the control character is used.
This fixes the warning.
diff --git a/src/utils/pintos b/src/utils/pintos
index 1564216..2ebe642 100755 (executable)
--- a/src/utils/pintos
+++ b/src/utils/pintos
## -912,7 +912,7 ## sub get_load_average {
# Calls setitimer to set a timeout, then execs what was passed to us.
sub exec_setitimer {
if (defined $timeout) {
- if ($\16 ge 5.8.0) {
+ if ($^V ge 5.8.0) {
eval "
use Time::HiRes qw(setitimer ITIMER_VIRTUAL);
setitimer (ITIMER_VIRTUAL, $timeout, 0);
Perl 5.26 made it a fatal error to use literal control characters in variable names.
The way you fix it is by ensuring that you are using the most recent version of pintOS. The command git clone git://pintos-os.org/pintos-anon ought to do it.
^V is a perlvar. For reasons unknown to me, it was encoded not as ^ V, but as a single unicode character, which caused the program to fail.
I'm looking to create a macro in P6 which converts its argument to a string.
Here's my macro:
macro tfilter($expr) {
quasi {
my $str = Q ({{{$expr}}});
filter-sub $str;
};
}
And here is how I call it:
my #some = tfilter(age < 50);
However, when I run the program, I obtain the error:
Unable to parse expression in quote words; couldn't find final '>'
How do I fix this?
Your use case, converting some code to a string via a macro, is very reasonable. There isn't an established API for this yet (even in my head), although I have come across and thought about the same use case. It would be nice in cases such as:
assert a ** 2 + b ** 2 == c ** 2;
This assert statement macro could evaluate its expression, and if it fails, it could print it out. Printing it out requires stringifying it. (In fact, in this case, having file-and-line information would be a nice touch also.)
(Edit: 007 is a language laboratory to flesh out macros in Perl 6.)
Right now in 007 if you stringify a Q object (an AST), you get a condensed object representation of the AST itself, not the code it represents:
$ bin/007 -e='say(~quasi { 2 + 2 })'
Q::Infix::Addition {
identifier: Q::Identifier "infix:+",
lhs: Q::Literal::Int 2,
rhs: Q::Literal::Int 2
}
This is potentially more meaningful and immediate than outputting source code. Consider also the fact that it's possible to build ASTs that were never source code in the first place. (And people are expected to do this. And to mix such "synthetic Qtrees" with natural ones from programs.)
So maybe what we're looking at is a property on Q nodes called .source or something. Then we'd be able to do this:
$ bin/007 -e='say((quasi { 2 + 2 }).source)'
2 + 2
(Note: doesn't work yet.)
It's an interesting question what .source ought to output for synthetic Qtrees. Should it throw an exception? Or just output <black box source>? Or do a best-effort attempt to turn itself into stringified source?
Coming back to your original code, this line fascinates me:
my $str = Q ({{{$expr}}});
It's actually a really cogent attempt to express what you want to do (turn an AST into its string representation). But I doubt it'll ever work as-is. In the end, it's still kind of based on a source-code-as-strings kind of thinking à la C. The fundamental issue with it is that the place where you put your {{{$expr}}} (inside of a string quote environment) is not a place where an expression AST is able to go. From an AST node type perspective, it doesn't typecheck because expressions are not a subtype of quote environments.
Hope that helps!
(PS: Taking a step back, I think you're doing yourself a disservice by making filter-sub accept a string argument. What will you do with the string inside of this function? Parse it for information? In that case you'd be better off analyzing the AST, not the string.)
(PPS: Moritz++ on #perl6 points out that there's an unrelated syntax error in age < 50 that needs to be addressed. Perl 6 is picky about things being defined before they are used; macros do not change this equation much. Therefore, the Perl 6 parser is going to assume that age is a function you haven't declared yet. Then it's going to consider the < an opening quote character. Eventually it'll be disappointed that there's no >. Again, macros don't rescue you from needing to declare your variables up-front. (Though see #159 for further discussion.))
I am quite new with fortran and have a question. I need to read 2 integers from the following line:
K=234, L=241, I=0
I am not interested in the last value. Just need the integers 234 and 241. I tried it with
read(20,'(3X,I3,3X,I3)')a,b
It compiles, but when I run the program I always get the error message:
At line 27 of file test.f90 (unit = 20, file = 'int_p2.dat')
Fortran runtime error: Bad value during integer read
Don't know what I am doing wrong. Can someone give me some advice?
You have strings in your line, so your READ statement ought to account for it. You should replace it with
READ(20, '(3(a2,i3,2x))') dumChar, k, dumChar, l, dumInt, dumChar
where dumChar is a character of length 2 and dumInt is an integer.
I don't see a problem in your code. (off course, your format is wrong, but should not give runtime error). Also, you are escaping chars (K,L) rather then reading them. compiler should not complain. but 3X will eat up 1 integer for K=234
Program se
Implicit None
integer :: K,L,I,a,b
open(20, file="se.in",status='old')
read(20,'(3X,I3,3X,I3)')a,b
close(20)
write(*,*)a,b
End Program se
$ cat se.in
K=234, L=241, I=0
$gfortran se.f90
$ ./a.out
34 241
If you still getting the problem, and if this are one single line you are trying to read, do
remove any space before K= in the file.
I think this is the error, as the code is reading non-integer.
GCC version 4.6
The Problem: To find a way to feed in parameters to the executable, say a.out, from the command line - more specifically feed in an array of double precision numbers.
Attempt: Using the READ(*,*) command, which is older in the standard:
Program test.f -
PROGRAM MAIN
REAL(8) :: A,B
READ(*,*) A,B
PRINT*, A+B, COMMAND_ARGUMENT_COUNT()
END PROGRAM MAIN
The execution -
$ gfortran test.f
$ ./a.out 3.D0 1.D0
This did not work. On a bit of soul-searching, found that
$./a.out
3.d0,1.d0
4.0000000000000000 0
does work, but the second line is an input prompt, and the objective of getting this done in one-line is not achieved. Also the COMMAND_ARGUMENT_COUNT() shows that the numbers fed into the input prompt don't really count as 'command line arguments', unlike PERL.
If you want to get the arguments fed to your program on the command line, use the (since Fortran 2003) standard intrinsic subroutine GET_COMMAND_ARGUMENT. Something like this might work
PROGRAM MAIN
REAL(8) :: A,B
integer :: num_args, ix
character(len=12), dimension(:), allocatable :: args
num_args = command_argument_count()
allocate(args(num_args)) ! I've omitted checking the return status of the allocation
do ix = 1, num_args
call get_command_argument(ix,args(ix))
! now parse the argument as you wish
end do
PRINT*, A+B, COMMAND_ARGUMENT_COUNT()
END PROGRAM MAIN
Note:
The second argument to the subroutine get_command_argument is a character variable which you'll have to parse to turn into a real (or whatever). Note also that I've allowed only 12 characters in each element of the args array, you may want to fiddle around with that.
As you've already figured out read isn't used for reading command line arguments in Fortran programs.
Since you want to read an array of real numbers, you might be better off using the approach you've already figured out, that is reading them from the terminal after the program has started, it's up to you.
The easiest way is to use a library. There is FLAP or f90getopt available. Both are open source and licensed under free licenses.
The latter is written by Mark Gates and me, just one module and can be learned in minutes but contains all what is needed to parse GNU- and POSIX-like command-line options. The first is more sophisticated and can be used even in closed-source projects. Check them out.
Furthermore libraries at https://fortranwiki.org/fortran/show/Command-line+arguments
What READ (*,*) does is that it reads from the standard input. For example, the characters entered using the keyboard.
As the question shows COMMAND_ARGUMENT_COUNT() can be used to get the number of the command line arguments.
The accepted answer by High Performance Mark show how to retrieve the individual command line arguments separated by blanks as individual character strings using GET_COMMAND_ARGUMENT(). One can also get the whole command line using GET_COMMAND(). One then has to somehow parse that character-based information into the data in your program.
I very simple cases you just need the program requires, for example, two numbers, so you read one number from arg 1 and another form arg 2. That is simple. Or you can read a triplet of numbers from a single argument if they are comma-separated like 1,2,3 using a simple read(arg,*) nums(1:3).
For general complicated command line parsing one uses libraries such as those mentioned in the answer by Hani. You have set them up so that the library knows the expected syntax of the command line arguments and the data it should fill with the values.
There is a middle ground, that is still relatively simple, but one already have multiple arguments, that correspond to Fortran variables in the program, that may or may not be present. In that case one can use the namelist for the syntax and for the parsing.
Here is an example, the man point is the namelist /cmd/ name, point, flag:
implicit none
real :: point(3)
logical :: flag
character(256) :: name
character(1024) :: command_line
call read_command_line
call parse_command_line
print *, point
print *, "'",trim(name),"'"
print *, flag
contains
subroutine read_command_line
integer :: exenamelength
integer :: io, io2
command_line = ""
call get_command(command = command_line,status = io)
if (io==0) then
call get_command_argument(0,length = exenamelength,status = io2)
if (io2==0) then
command_line = "&cmd "//adjustl(trim(command_line(exenamelength+1:)))//" /"
else
command_line = "&cmd "//adjustl(trim(command_line))//" /"
end if
else
write(*,*) io,"Error getting command line."
end if
end subroutine
subroutine parse_command_line
character(256) :: msg
namelist /cmd/ name, point, flag
integer :: io
if (len_trim(command_line)>0) then
msg = ''
read(command_line,nml = cmd,iostat = io,iomsg = msg)
if (io/=0) then
error stop "Error parsing the command line or cmd.conf " // msg
end if
end if
end subroutine
end
Usage in bash:
> ./command flag=T name=\"data.txt\" point=1.0,2.0,3.0
1.00000000 2.00000000 3.00000000
'data.txt'
T
or
> ./command flag=T name='"data.txt"' point=1.0,2.0,3.0
1.00000000 2.00000000 3.00000000
'data.txt'
T
Escaping the quotes for the string is unfortunately necessary, because bash eats the first quotes.
I am trying to create a module for a fortran 90 program. The file is called epath.f90. When I try to create the file epath.mod by running an object-only compile on the file by way of the commad f95 -c epath.f90 it gives me the following error message:
epath.f90:1:
MODULE euler-path
1
Error: Unclassifiable statement at (1)
epath.f90:8.3:
END MODULE euler-path
1
Error: Expecting END PROGRAM statement at (1)
Error: Unexpected end of file in 'epath.f90'
The code for epath.f90 is:
MODULE euler-path
INTEGER, PARAMETER :: NSTEPS=10
REAL, PARAMETER :: A=0.0, B=1.0, YSTART=0.0
REAL, DIMENSION(0:NSTEPS) :: x,y
END MODULE euler-path
I took the same steps for another module and it worked fine. Any help is appreciated.
In Fortran, names - module names, variable names, etc - have to start with a letter and contain only letters, digits, or underscores. (Fortran in particular forbids using special characters like operators, eg, -/+/*/(/) in names because it's historically taken a very cavalier approach to the use of spaces, or for that matter explicitly defined variable names, which would make it very difficult to distinguish between a-b as a name and the expression a - b.) See, eg, section 3.2.2 ("Names") of the recent Fortran standard.
So euler_path is ok, euler_path123 is ok, but euler-path isn't.