I have the following statement in my vtl on line 36 :
#if( !$util.isNullOrEmpty($ctx.args.filter.outstanding_amount.lt))
I get an error:
Parse error on line 36:
....outstanding_amount.lt)) $util.qui
-----------------------^
Expecting 'ID', 'CONTENT', got '<'
I read that lt and gt are a short versions of lower than and greater than operators.
How to make the parser understand .lt and .gt as identifiers and not logical operators?
Try:
$ctx.args.filter.outstanding_amount.get('lt')
Related
I'm using the Mermaid CLI to generate a flowchart (http://knsv.github.io/mermaid/flowchart.html). It works great, but I can't figure out how to get special characters (percent signs, parenthesis, etc) working as text within a node.
For illustration purposes here is a sample flowchart definition for Mermaid (filename is example.mermaid):
graph TD
question1{Gas tank less than 1/8?}
action1[Fill tank to 100%]
question1-- Yes -->action1
When I run mermaid on that file, I get this error (it blows up on the percent sign):
My-MacBook-Pro:mermaid mark$ mermaid example.mermaid
Error: Parse error on line 3:
...on1[Fill tank to 100%]question1-- Yes -
-----------------------^
Expecting 'QUOTE', 'TAG_END', 'TAG_START', 'MULT', 'EQUALS', 'PLUS', 'DOT', 'BRKT', 'COLON', 'ALPHA', 'COMMA', 'NUM', 'CLICK', 'CLASS', 'CLASSDEF', 'LINKSTYLE', 'STYLE', 'PIPE', 'THICK_ARROW_OPEN', 'THICK_ARROW_CROSS', 'THICK_ARROW_CIRCLE', 'THICK_ARROW_POINT', 'DOTTED_ARROW_OPEN', 'DOTTED_ARROW_CROSS', 'DOTTED_ARROW_CIRCLE', 'DOTTED_ARROW_POINT', 'ARROW_OPEN', 'ARROW_CROSS', 'ARROW_CIRCLE', 'ARROW_POINT', '==', '-.', '--', 'MINUS', 'DIAMOND_STOP', 'DIAMOND_START', 'PE', 'PS', 'SQE', 'SQS', 'end', 'subgraph', 'NEWLINE', 'TAGSTART', 'TAGEND', 'DIR', 'SPACE', 'GRAPH', 'EOF', 'SEMI', got 'PCT'
../dist/mermaid.full.js:14712 in parseError
../dist/mermaid.full.js:14782 in parse
../dist/mermaid.full.js:13260
../dist/mermaid.full.js:16846
../dist/mermaid.full.js:16889
phantomjs://webpage.evaluate():23 in executeInPage
phantomjs://webpage.evaluate():29
phantomjs://webpage.evaluate():29
PHANTOM ERROR: TypeError: 'null' is not an object (evaluating 'element.setAttribute')
TRACE:
-> /usr/local/lib/node_modules/mermaid/lib/phantomscript.js: 149 (in function resolveSVGElement)
-> /usr/local/lib/node_modules/mermaid/lib/phantomscript.js: 69
I tried escaping the percent sign, like this:
action1[Fill tank to 100&]
But then I get the same error on the semicolon. Any thoughts on how I can escape those characters to make it work? Thanks!
Use quotation marks "" to enclose your text and escape special characters, e.g. in your example:
graph TD
question1{"Gas tank less than 1/8?"}
action1["Fill tank to 100%"]
question1-- Yes -->action1
will produce this diagram:
This is now documented in the official documentation.
Here are more examples of escaping / quoting special characters. The code
flowchart LR
A["For most symbols double quotes are enough: ```~`!##$%^*()[]{}|\/:;'?<>,.+=-_"]
B["[""<<br>>&½#35;189;"]"]
B --> C[""<<br>>&½#189;"]
produces
Using this method most unicode characters (including non-ASCII) can be included using either unicode entity or markdown #code; syntax (both ways are illustrated using the character ½ in the diagram above). See also the official documentation.
Disclaimer: I didn't test it in Mermaid CLI. Tested in markdown-viewer and Mermaid live editor.
That was an issue with early mermaid versions. I tried your example code with mermaid 0.4.0 where it renders fine. I would recommend upgrading.
I have a PostgreSQL 8.4 database that is being queried by an application that is outside of my control. Queries such as the following are throwing warnings but are working...
SELECT "tagname","tagindex","tagtype","tagdatatype" FROM "tagtable" WHERE "tagname" = 'Lift_Stations\07\ETMs\Generator_ETM'
However, the same query for stations 08 and 09 are failing...
SELECT "tagname","tagindex","tagtype","tagdatatype" FROM "tagtable" WHERE "tagname" = 'Lift_Stations\08\ETMs\Generator_ETM'
WARNING: nonstandard use of escape in a string literal LINE 2:
...,"tagdatatype" FROM "tagtable" WHERE "tagname" = 'Lift_Stat...
^ HINT: Use the escape string syntax for escapes, e.g., E'\r\n'.
ERROR: invalid byte sequence for encoding "UTF8": 0x00 HINT: This
error can also happen if the byte sequence does not match the encoding
expected by the server, which is controlled by "client_encoding".
*** Error ***
ERROR: invalid byte sequence for encoding "UTF8": 0x00 SQL state:
22021 Hint: This error can also happen if the byte sequence does not
match the encoding expected by the server, which is controlled by
"client_encoding".
I know the problem is incorrect escaping, but given the fact that 08 and 09 are the only ones not working, I'm hoping someone might have a bright idea on how to work around this.
Thanks!
It should work if you enable standard_conforming_strings.
The following rule in antlr4 will not work for a valid input:
testSimple
: 'name' 'eq' WORD+? .*? NEWLINE
WORD: ~[ \t\f\r\n]+ ;
The input is :
name eq John Tom Allen notAName
The error is:
line 1:8 no viable alternative at input 'John'
I know using nongreedy operator has some limitations, like the 'first match wins' rule afterwards. And the rule is particularly ambiguous. But shouldn't it at least match the input in at least one way?
Try parsing with an explicit EOF symbol on the end of your entry rule. For example:
startTestSimple
: testSimple EOF
;
Without the explicit EOF in place, the algorithm may fail to find a viable alternative in some cases. Issue #118 describes one case where this is a problem; unfortunately the performance impact of the known solution is quite large, so we won't be including it in the ANTLR 4 runtime until we come up with an alternate solution.
Surprise, I am building an SQL like language parser for a project.
I had it mostly working, but when I started testing it against real requests it would be handling, I realized it was behaving differently on the inside than I thought.
The main issue in the following grammar is that I define a lexer rule PCT_WITHIN for the language keyword 'pct_within'. This works fine, but if I try to match a field like 'attributes.pct_vac', I get the field having text of 'attributes.ac' and a pretty ANTLR error of:
line 1:15 mismatched character u'v' expecting 'c'
GRAMMAR
grammar Select;
options {
language=Python;
}
eval returns [value]
: field EOF
;
field returns [value]
: fieldsegments {print $field.text}
;
fieldsegments
: fieldsegment (DOT (fieldsegment))*
;
fieldsegment
: ICHAR+ (USCORE ICHAR+)*
;
WS : ('\t' | ' ' | '\r' | '\n')+ {self.skip();};
ICHAR : ('a'..'z'|'A'..'Z');
PCT_CONTAINS : 'pct_contains';
USCORE : '_';
DOT : '.';
I have been reading everything I can find on the topic. How the Lexer consumes stuff as it finds it even if it is wrong. How you can use semantic predication to remove ambiguity/how to use lookahead. But everything I read hasn't helped me fix this issue.
Honestly I don't see how it even CAN be an issue. I must be missing something super obvious because other grammars I see have Lexer rules like EXISTS but that doesn't cause the parser to take a string like 'existsOrNot' and spit out and IDENTIFIER with the text of 'rNot'.
What am I missing or doing completely wrong?
Convert your fieldsegment parser rule into a lexer rule. As it stands now it will accept input like
"abc
_ abc"
which is probably not what you want. The keyword "pct_contains" won't be matched by this rule since it is defined separately. If you want to accept the keyword in certain sequences as regular identifier you will have to include it in the accepted identifier rule.
I'm using ANTLR to generate recognizer for a java-like language and the following rules are used to recognize generic types:
referenceType
: singleType ('.' singleType)*
;
singleType
: Identifier typeArguments?
;
typeArguments
: '<' typeArgument (',' typeArgument)* '>'
;
typeArgument
: referenceType
;
Now, for the following input statement, ANTLR produces the 'no viable alternative' error.
Iterator<Entry<K,V>> i = entrySet().iterator();
However, if I put a space between the two consecutive '>' characters, no error is produced. It seams that ANTLR cannot distinguish between the above rule and the rule used to recognize shift expressions, but I don't know how to modify the grammar to resolve this ambiguity. Any help would be appreciated.
You probably have a rule like the following in the lexer:
RightShift : '>>';
For ANTLR to recognize >> as either two > characters or one >> operator, depending on context, you'll need to instead place your shift operator in the parser:
rightShift : '>' '>';
If your language includes the >>> or >>= operators, those would need to be moved to the parser as well.
To validate that x > > y isn't allowed, you'll want to make a pass over the resulting parse tree (ANTLR 4) or AST (ANTLR 3) to verify that the two > characters parsed by the rightShift parser rule appear in sequence.
280Z28 is probably right in his diagnosis that you have a rule like
RightShift : '>>';
An alternative solution is to explicitly include the possibility of a trailing >> in your parser. (I have seen this in other grammars, but only in LALR.)
typeArguments
: ('<' typeArgument (',' typeArgument)* '>') |
('<' typeArgument ',' referenceType '<' typeArgument RightShift );
;
In Antlr3, that will need to be left factored.
Whether this is clearer or having a second pass that validates your right shift operator depends on how often you need to use this.