This question already has answers here:
Syntax error in a Fortran FORMAT statement
(1 answer)
Fortran :: Syntax error in OPEN statement at (1)
(1 answer)
Syntax error in argument list of a subroutine
(1 answer)
Closed 1 year ago.
I am using someone's Fortran scripts, I have changed a little bit in that. Now I am having a syntax error while executing it. I am new to Fortran so not able to figure it out.
The code is as follows:
integer i_canorg
integer i
integer n
integer canorg(n)
real r1demdoms(n)
real r1supdoms(n)
real r1supdomcan(n)
real r1rivout(n)
real r1envflw(n)
if(canorg(i).ne.0)then
i0l_canorg=canorg(i)
call calc_supcan1(i_canorg,r1demdoms(i),r1supdoms(i),r1rivout(i_canorg),r1envflw(i_canorg),r1supdomcan(i))
end if
The code is very long, I additionally added the if command and i_canorg parameter.
I am getting the following error while running the code:
348 | call calc_supcan1(i0lcanorg,r1demdoms(i),r1supdoms(i),r1rivout(i_canorg),r1envflw(i_canorg),r1supdomcan(i))
| 1
Error: Syntax error in argument list at (1)
What can be the reason behind this syntax error?
The reason the program is not compiling is that the line is too long, and unfortunately your compiler's error is not helpful for figuring that out. The dead giveaway is that, including the six spaces at the beginning of the line in the error message, the 1 in the error message is at column 73. Your compiler is interpreting the source code in fixed source form, which has some very particular requirements: see section 3.3.2 of N1191 for complete details.
Your compiler should have an option to specify that your source code should be interpreted in free source form. Based on your error message, it looks like you are most likely using gfortran, which has the command-line option -ffree-line-length-[n]. Check the documentation and set it to an appropriate value for your source code.
If you wish to continue to use fixed source form, then the line has to be broken into multiple lines with a continuation character in the sixth column of each continued line. The character can be anything except a space ( ) or a zero (0), and is ignored if it is in a comment line (a line beginning with the letter C or an asterisk (*)). This is one possible way of fixing the line:
****** <- note the six special columns at the beginning of the line
call calc_supcan1(i_canorg,r1demdoms(i),r1supdoms(i),
> r1rivout(i_canorg),r1envflw(i_canorg),r1supdomcan(i))
I'm trying to create a regex that is capable of analysing something like this:
002561-1415179671591i.jpg
The second part is a unix timestamp (before the i), and I need to extract that. I came up with the following syntax, but std::regex keeps throwing a regex_error before I even check for a match and I'm not too sure what's wrong.
Here's what I've got so far:([:d:])*-[[:d:]]*([:alpha:])\.jpg
The C++ code line that throws the error is the constructor to regex
std::regex reg(regex_expr);
where regex_expr is a string that has been read in from a file.
Really appreciate any help you can give.
Edit: I wrote a try catch section, and it seems I'm getting the following error code
std::regex_constants::error_brack
Edit 2: Ok... seems I'm still getting the error even with a cut-down test:
([:alpha:])*
Edit 3:
Seems I can't get any expression to work. Here's a bit more info. I'm using clang++ 3.5.0 on Kubuntu 14.04.
Not sure that [:d:] can stand for [:digit:]. [EDIT] (It seems it's possible)
When you use a POSIX character class, it must be enclosed in a character class like that:
[[:digit:]]
(This syntax allows to compose other classes [[:digit:]ab])
so:
std::string regex_expr = "([[:digit:]]*)-([[:digit:]]*)([[:alpha:]])\\.jpg";
or if you use the basic mode:
std::string regex_expr = "\\([[:digit:]]*\\)-\\([[:digit:]]*\\)\\([[:alpha:]]\\)\\.jpg";
I would rather use the perl-compatible syntax instead of character classes:
\d+-(\d+)[a-z]*\.jpg
After many tests, for whatever reason, I couldn't get this to work. As I had boost anyway, I tried out the boost::regex and it worked straight away, so I presume that something to do with either clang, or the version of the standard on this pc just wasn't working.
So simply put, tried boost and it worked straight away. Not much of an answer, but I guess that's how things go sometimes.
I get the following error when i run my Parser file ( binary got after compiling Flex/Bison files).
error: syntax error, unexpected TKN_PRIMARY, expecting end of file
Here is rule defined in flex code:
<PRIMARY_MME_STATE>{number} {
lexVal = YYText();
std::cout<<"PRIMARY MME --> "<<lexVal<<std::endl;
yylval->strVal = new std::string(lexVal);
return token::TKN_PRIMARYMME;
}
And my understanding is that since value of TKN_PRIMARY is zero ( which is the value defined for END %token END 0 "end of file") Instead of returning TKN_PRIMARY , it is expecting token END to be returned. Please comment if my understanding is correct . And Also how to tackle this issue.
If TKN_PRIMARY and END have the same value (or, in general, if any two different tokens have the same value), then the bison parser is going to act in unpredictable ways.
Quoting the bison manual:
It is generally best, however, to let Bison choose the numeric codes for
all token types. Bison will automatically select codes that don't
conflict with each other or with normal characters.
I think that's definitely the best way of dealing with the problem.
I've a question about weka as this person:
Hi all:
I felt really strange about WEKA on this.
I have prepared a CSV file which has lots of missing values. One
missing value in this file is basic just no any value between pair of
commas i.e. ,random_value1,,random_value2. This is an example of the
format. You can see there is a pair of commas, between them is just
nothing not even a white_space, and it should indicates a missing
value of the data.
The weird thing is when I read this CSV into WEKA, WEKA assigns all
missing values to a question mark, i.e. '?'. This is exactly how WEKA
expresses it.
And then when I run testing analysis, WEKA started working on these
'?' as some sort useful information. It just missing values, could
WEKA please just jump over it?
These problem became really wasting. Analysis results read like if
missing then value missing, missing assocciates with missing, missing
correlates missing.
Can WEKA reads missing value as missing value, not some sort question
marks? Or can I tell WEKA that for all '?', treat them as missing
values?
Thanks guys
He solved his problem using this solution:
I found a way to tell WEKA about the missings. Just use the fine_and_replace function of a ASCII editor, replace all '?' to ?.
>
but I didn't know how can download ASCII Editor and use it ,, can anyone inform me ????
I suggest you to use notepad2 or notepad++ in windows.
You don't have to work on with missing values. Different algorithms work differently on missing values. So, don't worry, it will be handled just the way it should have been.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I am having some difficulty compiling a C++ program that I've written.
This program is very simple and, to the best of my knowledge, conforms to all the rules set forth in the C++ Standard. I've read over the entirety of ISO/IEC 14882:2003 twice to be sure.
The program is as follows:
Here is the output I received when trying to compile this program with Visual C++ 2010:
c:\dev>cl /nologo helloworld.png
cl : Command line warning D9024 : unrecognized source file type 'helloworld.png', object file assumed
helloworld.png : fatal error LNK1107: invalid or corrupt file: cannot read at 0x5172
Dismayed, I tried g++ 4.5.2, but it was equally unhelpful:
c:\dev>g++ helloworld.png
helloworld.png: file not recognized: File format not recognized
collect2: ld returned 1 exit status
I figured that Clang (version 3.0 trunk 127530) must work, since it is so highly praised for its standards conformance. Unfortunately, it didn't even give me one of its pretty, highlighted error messages:
c:\dev>clang++ helloworld.png
helloworld.png: file not recognized: File format not recognized
collect2: ld returned 1 exit status
clang++: error: linker (via gcc) command failed with exit code 1 (use -v to see invocation)
To be honest, I don't really know what any of these error message mean.
Many other C++ programs have source files with a .cpp extension, so I thought perhaps I needed to rename my file. I changed its name to helloworld.cpp, but that didn't help. I think there is a very serious bug in Clang because when I tried using it to compile the renamed program, it flipped out, printed "84 warnings and 20 errors generated." and made my computer beep a lot!
What have I done wrong here? Have I missed some critical part of the C++ Standard? Or are all three compilers really just so broken that they can't compile this simple program?
Originally from Overv # reddit.
Try this way:
Your < and >, ( and ), { and } don't seem to match very well; Try drawing them better.
In the standard, §2.1/1 specifies:
Physical source file characters are mapped, in an implementation-defined manner, to the basic source character set (introducing new-line characters for end-of-line indicators) if necessary.
Your compiler doesn't support that format (aka cannot map it to the basic source character set), so it cannot move into further processing stages, hence the error. It is entirely possible that your compiler support a mapping from image to basic source character set, but is not required to.
Since this mapping is implementation-defined, you'll need to look at your implementations documentation to see the file formats it supports. Typically, every major compiler vendor supports (canonically defined) text files: any file produced by a text editor, typically a series of characters.
Note that the C++ standard is based off the C standard (§1.1/2), and the C(99) standard says, in §1.2:
This International Standard does not specify
— the mechanism by which C programs are transformed for use by a data-processing
system;
— the mechanism by which C programs are invoked for use by a data-processing
system;
— the mechanism by which input data are transformed for use by a C program;
So, again, the treatment of source files is something you need to find in your compilers documentation.
You could try the following python script. Note that you need to install PIL and pytesser.
from pytesser import *
image = Image.open('helloworld.png') # Open image object using PIL
print image_to_string(image) # Run tesseract.exe on image
To use it, do:
python script.py > helloworld.cpp; g++ helloworld.cpp
You forgot to use Comic Sans as a font, that's why its erroring.
I can't see a new-line after that last brace.
As you know: "If a source file that is not empty does not end in a new-line character, ... the behavior is undefined".
This program is valid -- I can find no errors.
My guess is you have a virus on your machine. It would be best if you reformat your drive, and reinstall the operating system.
Let us know how that works out, or if you need help with the reinstall.
I hate viruses.
I've found it helps to not write my code on my monitor's glass with a magic marker, even though it looks nice when its really black. The screen fills up too fast and then the people who give me a clean monitor call me names each week.
A couple of my employees (I'm a manager) are chipping in to buy me one of those red pad computers with the knobs. They said that I won't need markers and I can clean the screen myself when it's full but I have to be careful shaking it. I supposed it's delicate that way.
That's why I hire the smart people.
File format not recognized You need to properly format your file. That means using the right colors and fonts for your code. See the specific documentations for each compiler as these colors vary between compiler ;)
You forgot the pre-processor. Try this:
pngtopnm helloworld.png | ocrad | g++ -x 'c++' -
Did you handwrite the program and then scan it into the computer? That is what is implied by "helloworld.png". If that is the case, you need to be aware that the C++ standard (even in its newest edition) does not require the presence of optical character recognition, and unfortunately it is not included as an optional feature in any current compiler.
You may want to consider transposing the graphics to a textual format. Any plain-text editor may be used; the use of a word processor, while capable of generating a pretty printout, will most likely result in the same error that you get while trying to scan.
If you are truly adventurous, you may attempt to write your code into a word processor. Print it, preferably using a font like OCR-A. Then, take your printout and scan it back in. The scan can then be run through a third-party OCR package to generate a text form. The text form may then be compiled using one of many standard compilers.
Beware, however, of the great cost of paper that this will incur during the debugging phase.
Draw the include below to make it compile:
#include <ChuckNorris>
I hear he can compile syntax errors...
Unfortunately, you have selected three compilers that all support multiple languages, not just C++. They all have to guess at the programming language you used. As you probably already know, the PNG format is suitable for all programming languages, not just C++.
Usually the compiler can figure out the language itself. For instance, if the PNG is obviously drawn with crayons, the compiler will know it contains Visual Basic. If it looks like it's drawn with a mechanical pencil, it's easy to recognize the engineer at work, writing FORTRAN code.
This second step doesn't help the compiler either, in this case. C and C++ just look too similar, down to the #include. Therefore, you must help the compiler decide what language it really is. Now, you could use non-standard means. For instance, the Visual Studio compiler accepts the /TC and /TP command-line arguments, or you could use the "Compile as: C++" option in the project file. GCC and CLang have their own mechanisms, which I don't know.
Therefore, I'd recommend using the standard method instead to tell your compiler that the code following is in C++. As you've discovered by now, C++ compilers are very picky about what they accept. Therefore the standard way to identify C++ is by the intimidation programmers add to their C++ code. For instance, the following line will clarify to your compiler that what follows is C++ (and he'd better compile it without complaints).
// To the compiler: I know where you are installed. No funny games, capice?
Try this one:
Is your compiler set in expert mode?! If yes, it shouldn't compile. Modern compilers are tired of "Hello World!"
OCR Says:
N lml_�e <loJ+_e__}
.lnt Mk.,n ( ln+ _rSC Lhc_yh )
h_S_
_l
s_l . co__ <, " H llo uo/_d ! '` << s l� . ena_ .
TP__rn _ |
_|
Which is pretty damn good, to be fair.
helloworld.png: file not recognized: File format not recognized
Obviously, you should format your hard drive.
Really, these errors aren't that hard to read.
I did convert your program from PNG to ASCII, but it does not compile yet. For your information, I did try with line width 100 and 250 characters but both yield in comparable results.
` ` . `. ` ...
+:: ..-.. --.:`:. `-` .....:`../--`.. `-
` ` ````
`
` `` .` `` .` `. `` . -``- ..
.`--`:` :::.-``-. : ``.-`- `-.-`:.-` :-`/.-..` ` `-..`...- :
.` ` ` ` .` ````:`` - ` ``-.` `
`- .. ``
. ` .`. ` ` `. ` . . ` . ` . . .` .` ` ` `` ` `
`:`.`:` ` -..-`.`- .-`-. /.-/.-`.-. -...-..`- :``` `-`-` :`..`-` ` :`.`:`- `
`` ` ```. `` ```` ` ` ` ` ` ` ` .
: -...`.- .` .:/ `
- ` `` .
-`
`
The first problem is, that you are trying to return an incorrect value at the end of the main function. C++ standard dictates that the return type of main() is int, but instead you are trying to return the empty set.
The other problem is - at least with g++ - that the compiler deduces the language used from the file suffix. From g++(1):
For any given input file, the file
name suffix determines what kind of
compilation is done:
file.cc file.cp file.cxx file.cpp file.CPP file.c++ file.C
C ++ source code which must be preprocessed. Note that in .cxx, the
last two letters must both be literally x. Likewise, .C refers to a
literal capital C.
Fixing these should leave you with a fully working Hello World application, as can be seen from the demo here.
Your font sucks, how should a parser ever be able to read that? Take a calligraphy course.
Your compilers are expecting ASCII, but that program is obviously written using EBCDIC.
You're trying to compile an image.
Type out what you've hand written into a document called main.cpp, run that file through your compiler, then run the output file.
You need to specify the precision of your output preceded by a colon immediately before the final closing brace. Since the output is not numeric, the precision is zero, so you need this-
:0}
add :
using namespace std;
right after include :P:D
Seems that your compiler doesn't support files in such hmm... encoding. Try to convert it to ASCII.
The problem lies with the syntax definition, try using ruler and compasses for a more classical description!
Cheers,
Try switching input interface. C++ expects a keyboard to be plugged in to your computer, not a scanner. There may be peripherals conflict issues here. I didn't check in ISO Standard if keyboard input interface is mandatory, but that is true for all compilers I ever used. But maybe scanner input is now available in C99, and in this case your program should indeed work. If not you'll have to wait the next standard release and upgrade of compilers.
You could try different colors for brackets, maybe some green or red would help ?
I think your compiler can't rcognize black ink :P
Am I the only one who can't recognize the character between 'return' and the semicolon? That could be it!