I got this error message while using StringTemplate:
line 94:26: unexpected char: ')'
And after about 15 minutes of randomly adding and removing blank lines in my template, and observing how the number in that message changed, I finally isolated the line that caused trouble. It was line #152, position #35.
Is the value after "line " just normally totally wrong, or is there a way of deducing the real line number from that output?
In StringTemplate (ST) 4, it appears that the first number is the line number, within the specific template at issue and not the line number within the .stg file if that's what you're using (which most of us do).
When I'm using vim, this means I need to mentally offset that from the line number of the first line of the template (add them together) to get the actual line number within the .stg file.
The second number in the ST error is the character position within that line of the template. But wait, there's more - you know you love it...
When an error is on the first line of a multi-line template: since ST elides the starting newline in multi-line templates, ST effectively combines the first/ declaration line (ending in "<<") with the second (actual start of the template) line, in multi-line templates;
so at least with ST-4.0.8 I need to subtract the length of the template declaration line from the character position, to get the actual character position.
The first "\n" eliding (for multi-line templates only) also means the line number may appear to be offset by 1, and possibly the character position, for an error on the "first line".
The error should include the filename and template name, so it's enough information for an automated script or tool, but a bit cumbersome for us mere humans.
Good luck.
Related
I have the following segment of comment in my code file (the last line is intentionally missing the slash characters - that the error):
// * Cube Back Text from Méi guī
// 一颗 心 怕 摔倒 打破
//"yī kē xīn pà shuāi dǎo dǎ pò"
// "It's the heart afraid of breaking"
// 不敢 起舞 欢 歌
// "bù gǎn qǐwǔ huāngē"
// "that never learns to dance."
不敢起舞欢歌 (dance)
But the red error dot appears on the second character of the second line (second slash of the line "// * Cube Back Text from Méi guī".
Stranger, if I remove various quotes in the comment, the character that is hilited changes.
I assume this has something to do with a recursive structure somewhere in the parser that is continuing to parse the quotes inside the comment itself and ultimately figures out where to signal the error.
I suppose this is a bug ("semi-bug") that I should post to the GitHub list - to completely ignore anything past the second slash on a commented line, or some other change so that the error tag shows up on the line where the error actually is?
As it is, I futzed around about 10 minutes wondering if OpenSCAD just didn't like files longer than 575 lines.
I get the same problem when I try your example or modify it slightly but it worked perfectly when I replaced everything with random Latin characters so I think the bug has a lot to do with the Chinese ideographs you used.
In any case, I only copied the small sample you gave so it probably have nothing to do with the length of the file.
CMake documentation (for example current version 3.11.2) states
CMake Warning and Error message text displays using a simple markup language. Non-indented text is formatted in line-wrapped paragraphs delimited by newlines. Indented text is considered pre-formatted.
However, it doesn't mention any markup format. Unless the "non-indented" vs. "indented" is all there is about the "simple markup".
Anyway, I failed to make it work with FATAL_ERROR mode.
Furthermore, I noticed that with STATUS mode message is printed with leading -- (two dashes and space). While with FATAL_ERROR every line break in the message is turned into two lines, which (IMHO) looks awful.
Now I have a multiline message which lists what is wrong in CMAKE_BUILD_TYPE and what values are accepted. Because of above-mentioned issues, I ended up printing the message as STATUS and indenting subsequent lines with three spaces (so they align well with the --). Then I do a simple FATAL_ERROR repeating only the "title line" (stating that CMAKE_BUILD_TYPE is wrong). This looks acceptable on both console output and cmake-gui. (Although the 3 spaces indentation is needless on cmake-gui...)
However, I'm surprised how poorly is this topic described. And it seems to be so since long - see for example question [CMake] Extra blank lines with SEND_ERROR and FATAL_ERROR ?! remaining unanswered for almost 9 years now...
Are there any good practices, advice or tips for handling such messages? Or should they be avoided in the first place?
You're right. The "simple markup" is either non-indented (unformatted) or indented (formatted). Also, the non-indented text is in paragraphs delimited by newlines. That's why you end up with blank lines in between paragraphs.
Here's a running explanation of the various kinds of messages. Warning types and error types behave the same as far as formatted vs. unformatted text goes. The difference, of course, is what happens to the processing and generation phases of CMake. For readability, you can split strings into multiple double-quoted pieces that will be concatenated.
# STATUS
message(STATUS
"This is a status message. It is prefixed with \"-- \". It goes to stdout. The "
"lines will wrap according to the width of your terminal.\n"
"New lines will begin a new line at column 1, but without the \"-- \" prefix, "
"unless you provide it; they will not create a blank line (i.e., new "
"paragraph). Spacing between sentences is unaltered by CMake.\n"
"-- Here's a new paragraph with an explicit \"-- \" prefix added.")
# no mode given (informational)
message(
"This is an informational message. It goes to stderr. Each line begins at column "
"1. The lines will wrap according to the width of your terminal.\n"
"New lines will begin a new line at column 1; they will not create a blank line "
"(i.e., new paragraph). Spacing between sentences is unaltered by CMake (3 spaces "
"preceded this sentence.).")
# WARNING--unformatted
message(WARNING
"This is an unformatted warning message. It goes to stderr. Each line begins "
"at column 3. The lines will wrap at a particular column (it appears to be "
"column 77, set within CMake) and wrap back to column 3.\n"
"New lines will begin a new paragraph, so they will create a blank line. A final "
"thing about unformatted messages: They will separate sentences with 2 spaces, "
"even if your string had something different.")
# WARNING--formatted and unformatted
message(WARNING
" This is a formatted warning message. It goes to stderr. Formatted lines will"
" be indented an additional 2 spaces beyond what was provided in the output"
" string. The lines will wrap according to the width of your terminal.\n"
" Indented new lines will begin a new line. They will not create a blank line."
" If you separate sentences with 1 space, that's what you'll get. If you"
" separate them with 2 spaces, that's also what you'll get.\n"
" If you want to control the width of the formatted paragraphs\n"
" (a good practice), just keep track of the width of each line and place\n"
" a \"\\n\" at the end of each line.\n \n"
" And, if you want a blank line between paragraphs, just place \"\\n \\n\"\n"
" (i.e., 2 newlines separated by a space) at the end of the first paragraph.\n"
"Non-indented new lines, however, will be treated like unformatted warning "
"messages, described above. They will begin at and wrap to column 3. They begin "
"a new paragraph, so they will create a blank line. There will be 2 spaces "
"between sentences, regardless of how many you placed after the period (In the "
"script, there were 4 spaces before this sentence).\n"
"And, as you'd expect, a second unindented paragraph will be preceded by a "
"blank line. But why would you mix formatted and unformatted text?")
I saved this into Message.cmake and invoked it with cmake -P Message.cmake 2> output.txt. It results in the following stdout:
-- This is a status message. It is prefixed with "-- ". It goes to stdout. The lines will wrap according to the width of your terminal.
New lines will begin a new line at column 1, but without the "-- " prefix, unless you provide it; they will not create a blank line (i.e., new paragraph). Spacing between sentences is unaltered by CMake.
-- Here's a new paragraph with an explicit "-- " prefix added.
The file, output.txt, contains:
This is an informational message. It goes to stderr. Each line begins at column 1. The lines will wrap according to the width of your terminal.
New lines will begin a new line at column 1; they will not create a blank line (i.e., new paragraph). Spacing between sentences is unaltered by CMake (3 spaces preceded this sentence.).
CMake Warning at MessageScript.cmake:19 (message):
This is an unformatted warning message. It goes to stderr. Each line
begins at column 3. The lines will wrap at a particular column (it appears
to be column 77, set within CMake) and wrap back to column 3.
New lines will begin a new paragraph, so they will create a blank line. A
final thing about unformatted messages: They will separate sentences with 2
spaces, even if your string had something different.
CMake Warning at MessageScript.cmake:28 (message):
This is a formatted warning message. It goes to stderr. Formatted lines will be indented an additional 2 spaces beyond what was provided in the output string. The lines will wrap according to the width of your terminal.
Indented new lines will begin a new line. They will not create a blank line. If you separate sentences with 1 space, that's what you'll get. If you separate them with 2 spaces, that's also what you'll get.
If you want to control the width of the formatted paragraphs
(a good practice), just keep track of the width of each line and place
a "\n" at the end of each line.
And, if you want a blank line between paragraphs, just place "\n \n"
(i.e., 2 newlines separated by a space) at the end of the first paragraph.
Non-indented new lines, however, will be treated like unformatted warning
messages, described above. They will begin at and wrap to column 3. They
begin a new paragraph, so they will create a blank line. There will be 2
spaces between sentences, regardless of how many you placed after the
period (In the script, there were 4 spaces before this sentence).
And, as you'd expect, a second unindented paragraph will be preceded by a
blank line. But why would you mix formatted and unformatted text?
SUMMARY
INFORMATIONAL MESSAGES (no mode given)
start at column 1
wrap in terminal window until newline
go to stderr
new paragraphs begin without preceding blank line
sentence and word spacing preserved
STATUS MESSAGES
start at column 1, with "-- " prefix on first paragraph
wrap in terminal window until newline
go to stdout
new paragraphs begin without preceding blank line
sentence and word spacing preserved
UNFORMATTED WARNING AND ERROR MESSAGES (unindented strings)
start at column 3
wrap at column 77
go to stderr
new paragraphs are preceded by a blank line
sentences separated by 2 spaces; words by 1 space
FORMATTED WARNING AND ERROR MESSAGES (indented strings)
start at column 3, plus whatever indentation the string had
wrap in terminal window until newline
go to stderr
new paragraphs begin without preceding blank line
sentence and word spacing preserved
Informix 11.5
I am trying to search for carriage returns and line feeds that may exist in a VARCHAR field. First, I need a SELECT statement to show that they exist. Second, I need to REPLACE them with a space or other character.
I've tried all kinds of variations:
CHR(10) + CHR(13)
CHR(10) || CHR(13)
CHAR(13) + CHAR(10)
CHAR(13) || CHAR(10)
SELECT CHR(10) from systables;
Everything gives an error: Routine (chr) can not be resolved.
I've been searching all over and just can't find anything that works, and I'm sure this is crazy stupid easy.
Get the ASCII package from the IIUG
The CHR() function was added to IDS 11.70; it isn't in IDS 11.50.
The good news is you can add the function because IDS is an extensible server. The better news for you is that you can obtain the relevant code from the IIUG web site in the Software Archive under the Miscellaneous section as ascii.
That should allow you to do what you need. (Note: I wrote the code way back when — before there was support built into any of the servers.)
Windows makes things more complicated
I was uploading the ascii.unl file and I get an error that the number of columns do not match on line 13. Have you seen this before? I'm on Windows 2008. The errors are:
846: Number of values in load file is not equal to number of columns.
847: Error in load file line 13.
I hadn't seen it before, but I've not tried the file on Windows and … well, let's say life gets trickier on Windows than it is on Unix (and this bit isn't all that simple on Unix).
First of all, the data file needs to have CRLF line endings instead of the NL-only line endings that are standard on Unix. (Note that NL, newline, is another name for LF, line feed — aka '\n'.) For most lines in the unload file, that isn't a problem.
The two entries for which it might be (is) a problem are for CR and LF — entries 13 and 10 respectively. In theory, if the entry for line 10 contains (in C string notation) "10|\\\n\r\n" (that is, 10, pipe, backslash, newline, CRLF), all should be OK; the absence of an error message for line 10 suggests that it is OK.
Similarly, the entry for line 13 is "13|\r\r\n", which apparently causes grief. The simplest trial fix is to add a backslash here too: "13|\\\r\r\nn". The backslash says "the next character doesn't have a special meaning". If that doesn't work, we'll probably have to try hex-escape notation: "13|\\0d\r\n" — and use dbaccess -X to enable the hex escape notation.
With luck, one of those two (or both) will work. If neither works, come back and we'll try to think of something else.
As per my above comment:
I was uploading the ascii.unl file and I get an error that the number of columns do not match on line 13. Have you seen this before? I'm on Windows 2008. 846: Number of values in load file is not equal to number of columns. 847: Error in load file line 13.
Here is what I see in the ascii.unl file.
If I put this into MS Word and turn on Show Formatting/Paragraph marks, it shows this:
Maybe i'm missing something, but does anyone know how the debugging line numbering works in BigQuery?
I get an error like this:
Failed to save view. 2.196 - 2.226: Ambiguous column name eventcode.
and I'm not sure what the address 2.196-2.226 means. Specifically, what does the decimal signify? The second line of my query is very short (just SELECT *), so I don't think the numbers after the decimal indicate a character range?
Anyway -- I can't find any info for it in the docs, so any help here would be great
Line counting is most like shifted by 1 so it is actually line number #1 (not #2)
196 - 226 points to char range on that line with piece of code that introduces ambiquity - just the second piece (that has already existing aliac or column name for it)
Somehow for some first lines line numbering is incremented by 1 - it can be a bug on BQ UI side.
Btw, I noticed same strange behaviour in CodeMirror BQ UI is using, so it can be CodeMirror's bug too
do you know if the following statement is guaranteed to be true by one of the fortran 90/95/2003 standards?
"Suppose a read statement for a character variable is given a blank line (i.e., containing only white spaces and new line characters). If the format specifier is an asterisk (*), it continues to read the subsequent lines until a non-blank line is found. If the format specifier is '(A)', a blank string is substituted to the character variable."
For example, please look at the following minimal program and input file.
program code:
PROGRAM chk_read
INTEGER, PARAMETER :: MAXLEN=30
CHARACTER(len=MAXLEN) :: str1, str2
str1='minomonta'
read(*,*) str1
write(*,'(3A)') 'str1_start|', str1, '|str1_end'
str2='minomonta'
read(*,'(A)') str2
write(*,'(3A)') 'str2_start|', str2, '|str2_end'
END PROGRAM chk_read
input file:
----'input.dat' content is below this line----
yamanakako
kawaguchiko
----'input.dat' content is above this line----
Please note that there are four lines in 'input.dat' and the first and third lines are blank (contain only white spaces and new line characters). If I run the program as
$ ../chk_read < input.dat > output.dat
I get the following output
----'output.dat' content is below this line----
str1_start|yamanakako |str1_end
str2_start| |str2_end
----'output.dat' content is above this line----
The first read statement for the variable 'str1' seems to look at the first line of 'input.dat', find a blank line, move on to the second line, find the character value 'yamanakako', and store it in 'str1'.
In contrast, the second read statement for the variable 'str2' seems to be given the third line, which is blank, and store the blank line in 'str2', without moving on to the fourth line.
I tried compiling the program by Intel Fortran (ifort 12.0.4) and GNU Fortran (gfortran 4.5.0) and got the same result.
A little bit about a background of asking this question: I am writing a subroutine to read a data file that uses a blank line as a separator of data blocks. I want to make sure that the blank line, and only the blank line, is thrown away while reading the data. I also need to make it standard conforming and portable.
Thanks for your help.
From Fortran 2008 standard draft:
List-directed input/output allows data editing according to the type
of the list item instead of by a format specification. It also allows
data to be free-field, that is, separated by commas (or semicolons) or
blanks.
Then:
The characters in one or more list-directed records constitute a
sequence of values and value separators. The end of a record has the
same effect as a blank character, unless it is within a character
constant. Any sequence of two or more consecutive blanks is treated as
a single blank, unless it is within a character constant.
This implicitly states that in list-directed input, blank lines are treated as blanks until the next non-blank value.
When using a fmt='(A)' format descriptor when reading, blank lines are read into str. On the other side, fmt=*, which implies list-directed I/O in free-form, skips blank lines until it finds a non-blank character string. To test this, do something like:
PROGRAM chk_read
INTEGER :: cnt
INTEGER, PARAMETER :: MAXLEN=30
CHARACTER(len=MAXLEN) :: str
cnt=1
do
read(*,fmt='(A)',end=100)str
write(*,'(I1,3A)')cnt,' str_start|', str, '|str_end'
cnt=cnt+1
enddo
100 continue
END PROGRAM chk_read
$ cat input.dat
yamanakako
kawaguchiko
EOF
Running the program gives this output:
$ a.out < input.dat
1 str_start| |str_end
2 str_start| |str_end
3 str_start| |str_end
4 str_start|yamanakako |str_end
5 str_start| |str_end
6 str_start|kawaguchiko |str_end
On the other hand, if you use default input:
read(*,fmt=*,end=100)str
You end up with this output:
$ a.out < input.dat
1 str1_start|yamanakako |str1_end
2 str2_start|kawaguchiko |str2_end
This Part of the F2008 standard draft probably treats your problem:
10.10.3 List-directed input
7 When the next effective item is of type character, the input form
consists of a possibly delimited sequence of zero or more
rep-char s whose kind type parameter is implied by the kind of the
effective item. Character sequences may be continued from the end of
one record to the beginning of the next record, but the end of record
shall not occur between a doubled apostrophe in an
apostrophe-delimited character sequence, nor between a doubled quote
in a quote-delimited character sequence. The end of the record does
not cause a blank or any other character to become part of the
character sequence. The character sequence may be continued on as many
records as needed. The characters blank, comma, semicolon, and slash
may appear in default, ASCII, or ISO 10646 character sequences.