Iam using this code in Pine Script but getting the "mismatched input 'if' expecting 'end of line without line continuation'" error.
How to fix that error with this function code?
//#version=3
if study("My Script1")
Conversion, reason: Source pine is incorrect. line 5: mismatched input 'if' expecting 'end of line without line continuation'
study() is a script type declaration statement. It returns void. Using it in an if statement makes no sense and wrong.
Also, if you want to check if some variable is equal to another variable, you should use the == comparison operator.
Related
I want to execute shell commands inside if-block of Gnuplot. I tried the following:
datatype = 'full'
if ( datatype eq 'full' ) {
# Run shell command
!echo 'full'
} else {
# Run different shell command
!echo 'not full'
}
However, this gives me the error "filename.plt" line xx: invalid command
FYI, I already know instead of !echo, I can use print to do the same thing. That's not the point. I want to use shell commands with the symbol ! within the if-block. Any help will be appreciated.
#choroba has given the correct solution: use the system("command") function instead of !command.
As to why this is necessary, in brief:
(1) The ! operator is interpreted as indicating a shell command only if it is the first token on a gnuplot input line. Otherwise it is interpreted as a logical NOT.
(2) Gnuplot bracketed clauses { lots of commands } are treated internally as a single long input line. This is an implementation detail that has changed over time. The safest general guideline is that a bracketed clause should not contain any syntax that is documented as acting on or affecting a single line of input. This includes # macro substitution, single-line if statements, and as you found, the ! operator.
(1+2) Therefor a ! inside a bracketed clause is not seen as being the first token, and is interpreted as a logical NOT operator instead.
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've been linting my python code for some time now in order to make it more Pythonian and to that effect I've been using pylint to help identify problematic code blocks. However, now I'm having a kind of weird error, where pylint is flagging a correctly formatted constant name as not conforming to the regex provided.
Orginially, the constant was named main, which should match with the regex [a-z\_][a-z0-9\_]{2,30}$, but I got the convention violation message anyway. I tried changing the constant to run_main without any change. I even tried chaning the regex to [\_][a-z0-9\_]{2,30}$|[a-z][\_][a-z0-9\_]{2,30}$but the convention violation persists. I've tried testing the expressions on several regex testing sites to make sure I was not in the wrong. Is it a bug in pylint or am I missing something obvious?
The constant is defined in the following code block:
if __name__ == "__main__":
javabridge.start_vm(class_path=bf.JARS)
run_main = mainInterface()
and the relevant part of my pylintrc file is:
# Naming style matching correct constant names
#const-naming-style=
# Regular expression matching correct constant names. Overrides const-naming-
# style
const-rgx='[\_][a-z0-9\_]{2,30}$|[a-z][\_][a-z0-9\_]{2,30}$'
which yields the following output:
393,4,convention,C0103:Constant name "run_main" doesn't conform to "'[\\_]
[a-z0-9\\_]{2,30}$|[a-z][\\_][a-z0-9\\_]{2,30}$'" pattern ("'[\\_][a-z0-
9\\_]{2,30}$|[a-z][\\_][a-z0-9\\_]{2,30}$'" pattern)
Pylint wants any variable assigned in the outermost scope to be in all uppercase. Calling it MAIN should remove the warning.
I have a 17gb tab separated file and I get the above error when using python/pandas
I am doing the following:
data = pd.read_csv('/tmp/testdata.tsv',sep='\t')
I have also tried adding encoding='utf8' and also tried read_table and various flags, including low_memory=True, but I always get the same error at the same line.
I ran the following on the file:
awk -F"\t" 'FNR==1025974 {print NF}' /tmp/testdata.tsv
An it returns 281 for the number of fields so awk is telling me that line has the correct 281 columns, but read_csv is telling me I have 331.
I also tried the above awk on line 1025973 and 1025975, just to be sure something wasn't relative to zero and they both come back as 281 fields.
What am I missing here?
So to debug this, I took my header line, then took the single line from above and ran it through read_csv. I then got another error:
Error tokenizing data. C error: EOF inside string starting at line 1
The problem turned out to be that, by default, read_csv will look for a closing double quote if it sees a double quote immediately after the delimiter.
I incorrectly assumed that if I specified sep="\t" it would split only on tabs and not care about any other characters.
Long story short, to fix this, add the following flag to read_csv
quoting=3 which is QUOTE_NONE.
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.