[il-antlr-interest: 33271] Re: [antlr-interest] Deciphering the TreeWalker error message ...
Hey Grey,
Yes you are absolutely right, the first element is a rule reference.
My sclarSubExpression snippet is as follows:-
sclarSubExpression
:
^(SUB_EXPR ^(sign sse=sclarSubExpression))
| ^(SUB_EXPR expressionWithParen)
| ^(SUB_EXPR function)
| ^(SUB_EXPR object_name)
| ^(SUB_EXPR constant)
| ^(SUB_EXPR coalesce_exp)
| ^(SUB_EXPR nullif_exp)
| ^(SUB_EXPR case_expression)
;
expressionWithParen
:
^(PAREN_SCLAR_EXPRESSION sclarExpression+)
;
The toStringTree AST is also provided below:
Works:-
--
DML_STATEMENT DOWN select DOWN SELECT_LIST DOWN SELECT_ITEM DOWN
COMPOUND_EXPR DOWN SUB_EXPR DOWN PAREN_SCLAR_EXPRESSION DOWN
COMPOUND_EXPR DOWN SUB_EXPR DOWN 1 UP UP UP UP UP UP UP from DOWN
TABLE_LIST_ITEM DOWN TABLE_OR_VIEW_NAME DOWN table1 UP UP UP where DOWN
CONDITION_LIST DOWN between DOWN COMPOUND_EXPR DOWN SUB_EXPR DOWN 2 UP
UP and DOWN COMPOUND_EXPR DOWN SUB_EXPR DOWN 3 UP UP COMPOUND_EXPR DOWN
SUB_EXPR DOWN 4 UP UP UP UP UP UP UP UP
Parser AST Tree : (DML_STATEMENT (select (SELECT_LIST (SELECT_ITEM
(COMPOUND_EXPR (SUB_EXPR (PAREN_SCLAR_EXPRESSION (COMPOUND_EXPR
(SUB_EXPR 1))) (from (TABLE_LIST_ITEM (TABLE_OR_VIEW_NAME table1)))
(where (CONDITION_LIST (between (COMPOUND_EXPR (SUB_EXPR 2)) (and
(COMPOUND_EXPR (SUB_EXPR 3)) (COMPOUND_EXPR (SUB_EXPR 4
Fails:
---
DML_STATEMENT DOWN select DOWN SELECT_LIST DOWN SELECT_ITEM DOWN
COMPOUND_EXPR DOWN SUB_EXPR DOWN PAREN_SCLAR_EXPRESSION DOWN
COMPOUND_EXPR DOWN SUB_EXPR DOWN 1 UP UP UP UP UP UP UP from DOWN
TABLE_LIST_ITEM DOWN TABLE_OR_VIEW_NAME DOWN table1 UP UP UP where DOWN
CONDITION_LIST DOWN between DOWN COMPOUND_EXPR DOWN SUB_EXPR DOWN 2 UP
UP and DOWN COMPOUND_EXPR DOWN SUB_EXPR DOWN 3 UP UP COMPOUND_EXPR DOWN
SUB_EXPR DOWN 4 UP UP UP UP UP UP UP UP
Parser AST Tree : (DML_STATEMENT (select (SELECT_LIST (SELECT_ITEM
(COMPOUND_EXPR (SUB_EXPR (PAREN_SCLAR_EXPRESSION (COMPOUND_EXPR
(SUB_EXPR 1))) (from (TABLE_LIST_ITEM (TABLE_OR_VIEW_NAME table1)))
(where (CONDITION_LIST (between (COMPOUND_EXPR (SUB_EXPR 2)) (and
(COMPOUND_EXPR (SUB_EXPR 3)) (COMPOUND_EXPR (SUB_EXPR 4
Thanks for spending your valuable time looking into this issue.
Regards,
Vasan
On 7/21/2011 11:23 AM, Gary Miller wrote:
Hey Vasan,
Without seeing the reset of the tree walker grammar and the toStringTree of
the AST I'm really just guessing.
The rule looks a bit odd to me.
All my tree walker rules look more like
compoundExpression
:
^(SOMETOKEN conversion_clause)
| sclarSubExpression
;
I guess you can have rules as the first element of a tree, its just not
something that turns up in my tree grammars.
Regards
Gary
On Thu, Jul 21, 2011 at 3:29 PM, srinivasan karthikeyan pitchai
srinivasan.karthikeyan.pitc...@oracle.com wrote:
Hi Folks,
I forgot to mention. The compoundExpression rule has options{backtrack
= true;} set that is it reads like
compoundExpression
options {backtrack = true;}
:
^(sclarSubExpression conversion_clause)
| sclarSubExpression
;
Thanks,
Vasan
On 7/21/2011 10:56 AM, srinivasan karthikeyan pitchai wrote:
Jim, Gray, Loring,
Thanks for pitching in to give me some direction to focus on.
ANTLR Gurus,
I've solved the issue. Still I am unable to reason out my fix.
I am providing the offending grammar snippet below and would appreciate
your rationale to get an insight into the problem and how the fix works!!
The below rule fails with the
no viable alt; token=[@-1,0:0='DOWN' error message
compoundExpression:
^(sclarSubExpression conversion_clause)
| sclarSubExpression
;
However when I change the rule like the following, i.e make the
conversion_clause optional and then remove the second alternative every
thing works fine!! In my mind both the rules are semantically identical.
compoundExpression:
^(sclarSubExpression conversion_clause?)
;
Thanks a ton.
-Vasan
On 7/21/2011 4:16 AM, Jim Idle wrote:
Or use the dot description producing methods and create a nice graphic
with graphviz. Much easier to see that way.
Jim
-Original Message-
From: antlr-interest-boun...@antlr.org [mailto:antlr-interest-
boun...@antlr.org] On Behalf Of Gary Miller
Sent: Wednesday, July 20, 2011 3:44 PM
To: antlr-interest@antlr.org
Subject: Re: [antlr-interest] Deciphering the TreeWalker error message
...
I often find it usefully to print out the AST (toStringTree in Java)
and walk through the tree grammar manually.
Regards
Gary
On Thu, Jul 21, 2011 at 3:15 AM, Loring Craymerlgcray...@yahoo.com
wrote:
UP and DOWN tokens (start/end of child list for tree) do not have
location information attached so no line/column error reporting.
Mostly the error says that you started a subtree that your grammar
does not match, probably an LPAREN or RPAREN rooted subtree from your
report of cases where you do or do not get the error.
--Loring
[il-antlr-interest: 33272] Re: [antlr-interest] Deciphering the TreeWalker error message ...
Hey Vasan,
Couple of things.
1. My name is Gary not Grey ;-)
2. I'm not really an ANTLR guru.
3.
rule :
^(subrule otherrule)
;
Just looks wrong.
If you inline (expand) out what you have written you would get
compoundExpression
: ^((SUB_EXPR ^(PAREN_SCLAR_EXPRESSION sclarExpression+) conversion_clause )
;
The ^(( is impossible
Make all you start tree look like ^(TOKEN ...)
^(sign sse=sclarSubExpression) therefore also look wrong.
4. I've never tried Jim DOTTreeGenerator but can see how it could be useful.
If you try it out let me know what you think
http://www.antlr.org/pipermail/antlr-interest/2009-March/033417.html
5. A pretty version of you AST toStringTree might help you.
See below. You never see a (( as far as I know.
Regards
Gary
(DML_STATEMENT
(select
(SELECT_LIST
(SELECT_ITEM
(COMPOUND_EXPR
(SUB_EXPR
(PAREN_SCLAR_EXPRESSION
(COMPOUND_EXPR
(SUB_EXPR 1)
)
)
)
)
)
)
(from
(TABLE_LIST_ITEM
(TABLE_OR_VIEW_NAME table1)
)
)
(where
(CONDITION_LIST
(between
(COMPOUND_EXPR
(SUB_EXPR 2)
)
(and
(COMPOUND_EXPR
(SUB_EXPR 3)
)
(COMPOUND_EXPR
(SUB_EXPR 4)
)
)
)
)
)
)
)
On Thu, Jul 21, 2011 at 4:03 PM, srinivasan karthikeyan pitchai
srinivasan.karthikeyan.pitc...@oracle.com wrote:
Hey Grey,
Yes you are absolutely right, the first element is a rule reference.
My sclarSubExpression snippet is as follows:-
sclarSubExpression
:
^(SUB_EXPR ^(sign sse=sclarSubExpression))
| ^(SUB_EXPR expressionWithParen)
| ^(SUB_EXPR function)
| ^(SUB_EXPR object_name)
| ^(SUB_EXPR constant)
| ^(SUB_EXPR coalesce_exp)
| ^(SUB_EXPR nullif_exp)
| ^(SUB_EXPR case_expression)
;
expressionWithParen
:
^(PAREN_SCLAR_EXPRESSION sclarExpression+)
;
The toStringTree AST is also provided below:
Works:-
--
DML_STATEMENT DOWN select DOWN SELECT_LIST DOWN SELECT_ITEM DOWN
COMPOUND_EXPR DOWN SUB_EXPR DOWN PAREN_SCLAR_EXPRESSION DOWN
COMPOUND_EXPR DOWN SUB_EXPR DOWN 1 UP UP UP UP UP UP UP from DOWN
TABLE_LIST_ITEM DOWN TABLE_OR_VIEW_NAME DOWN table1 UP UP UP where DOWN
CONDITION_LIST DOWN between DOWN COMPOUND_EXPR DOWN SUB_EXPR DOWN 2 UP
UP and DOWN COMPOUND_EXPR DOWN SUB_EXPR DOWN 3 UP UP COMPOUND_EXPR DOWN
SUB_EXPR DOWN 4 UP UP UP UP UP UP UP UP
Parser AST Tree : (DML_STATEMENT (select (SELECT_LIST (SELECT_ITEM
(COMPOUND_EXPR (SUB_EXPR (PAREN_SCLAR_EXPRESSION (COMPOUND_EXPR
(SUB_EXPR 1))) (from (TABLE_LIST_ITEM (TABLE_OR_VIEW_NAME table1)))
(where (CONDITION_LIST (between (COMPOUND_EXPR (SUB_EXPR 2)) (and
(COMPOUND_EXPR (SUB_EXPR 3)) (COMPOUND_EXPR (SUB_EXPR 4
Fails:
---
DML_STATEMENT DOWN select DOWN SELECT_LIST DOWN SELECT_ITEM DOWN
COMPOUND_EXPR DOWN SUB_EXPR DOWN PAREN_SCLAR_EXPRESSION DOWN
COMPOUND_EXPR DOWN SUB_EXPR DOWN 1 UP UP UP UP UP UP UP from DOWN
TABLE_LIST_ITEM DOWN TABLE_OR_VIEW_NAME DOWN table1 UP UP UP where DOWN
CONDITION_LIST DOWN between DOWN COMPOUND_EXPR DOWN SUB_EXPR DOWN 2 UP
UP and DOWN COMPOUND_EXPR DOWN SUB_EXPR DOWN 3 UP UP COMPOUND_EXPR DOWN
SUB_EXPR DOWN 4 UP UP UP UP UP UP UP UP
Parser AST Tree : (DML_STATEMENT (select (SELECT_LIST (SELECT_ITEM
(COMPOUND_EXPR (SUB_EXPR (PAREN_SCLAR_EXPRESSION (COMPOUND_EXPR
(SUB_EXPR 1))) (from (TABLE_LIST_ITEM (TABLE_OR_VIEW_NAME table1)))
(where (CONDITION_LIST (between (COMPOUND_EXPR (SUB_EXPR 2)) (and
(COMPOUND_EXPR (SUB_EXPR 3)) (COMPOUND_EXPR (SUB_EXPR 4
Thanks for spending your valuable time looking into this issue.
Regards,
Vasan
On 7/21/2011 11:23 AM, Gary Miller wrote:
Hey Vasan,
Without seeing the reset of the tree walker grammar and the toStringTree of
the AST I'm really just guessing.
The rule looks a bit odd to me.
All my tree walker rules look more like
compoundExpression
:
^(SOMETOKEN conversion_clause)
| sclarSubExpression
;
I guess you can have rules as the first element of a tree, its just not
something that turns up in my tree grammars.
Regards
Gary
On Thu, Jul 21, 2011 at 3:29 PM, srinivasan karthikeyan pitchai
srinivasan.karthikeyan.pitc...@oracle.com wrote:
Hi Folks,
I forgot to mention. The compoundExpression rule has options{backtrack
= true;} set that is it reads like
compoundExpression
options {backtrack = true;}
:
^(sclarSubExpression conversion_clause)
| sclarSubExpression
;
[il-antlr-interest: 33274] Re: [antlr-interest] Antlr C target with LibXML
Hi, try to execute the compiler like gcc -E -P and check the output. Or try to compile the output manually. ANTLR adds a define for each token you declare and these macro definitions do interfere with some datatype present in libxml headers. For example if you create your own token called int in .g then the GLexer.h will contain a macro definition #define int some number When you declare your own token names, you should always use some prefix. Ivan PS: did you try to switch the order of headers included? PS2: off-topic on the other hand it is impossible to compile ANTLR headers with QT, because QT contains macro called emit white emit is a name of the function in antlr headers. Quoting Jim Idle j...@temporal-wave.com: The header files are interfering with each other. You probably need to separate your logic from your parser .g file. However, unless you post all of your project it is hard to see why. Look at the lines indicated as in error and you will probably find some symbol that ANTLR defines that libXML is also defining. When you know what it is, you can possibly undef it before including the libXML headers. I will also try to make time tomorrow to have a look at this. Jim -Original Message- From: antlr-interest-boun...@antlr.org [mailto:antlr-interest- boun...@antlr.org] On Behalf Of Richard Walton Sent: Wednesday, July 20, 2011 6:04 PM To: antlr-interest@antlr.org Subject: [antlr-interest] Antlr C target with LibXML Forgive me if this is not the correct etiquette for asking questions - This is the first mailing list I've subscribed to. I'm having a problem compiling an application using LibXML2 (http://xmlsoft.org/) with a C lexer/grammar generated from ANTLR. My problems are documented here: http://stackoverflow.com/questions/6769548/antlr-c-target-and-xmllib I would be very grateful for any help in fixing the problem. Kind regards, Richard List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your- email-address List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address This message was sent using IMP, the Internet Messaging Program. List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups il-antlr-interest group. To post to this group, send email to il-antlr-inter...@googlegroups.com. To unsubscribe from this group, send email to il-antlr-interest+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 33275] [antlr-interest] Incompatible type in subrules with OR
Hello,
I've this grammar: http://pastebin.com/dNzdGx8R but i get this error
when I test it with AntlrWorks:
[11:23:59] /Users/hammer/output/RDFPathParser.java:383: incompatible types
[11:23:59] found : RDFPathParser.repeat_return
[11:23:59] required: RDFPathParser.shortestPath_return
[11:23:59] v=repeat();
[11:23:59] ^
[11:23:59] /Users/hammer/output/RDFPathParser.java:586: incompatible types
[11:23:59] found : RDFPathParser.filter_return
[11:23:59] required: RDFPathParser.subquery_return
[11:23:59] v=filter();
[11:23:59] ^
[11:23:59] 2 errors
Basically I think the problem is the assignment in the subrules with ORs
in two statements:
locationStep: edge condition? (v=repeat | v=shortestPath)? (''
locationStep)?
- ^(LOCATIONSTEP condition $v locationStep);
condition: ( v=filter | v=subquery ) condition?
- ^(CONDITION $v condition);
How do I handle these situations where I have the two or more options in
a subrule?
Thanks
Claudio
--
Claudio Martella
Free Software Open Technologies
Analyst
TIS innovation park
Via Siemens 19 | Siemensstr. 19
39100 Bolzano | 39100 Bozen
Tel. +39 0471 068 123
Fax +39 0471 068 129
claudio.marte...@tis.bz.it http://www.tis.bz.it
Short information regarding use of personal data. According to Section 13 of
Italian Legislative Decree no. 196 of 30 June 2003, we inform you that we
process your personal data in order to fulfil contractual and fiscal
obligations and also to send you information regarding our services and events.
Your personal data are processed with and without electronic means and by
respecting data subjects' rights, fundamental freedoms and dignity,
particularly with regard to confidentiality, personal identity and the right to
personal data protection. At any time and without formalities you can write an
e-mail to priv...@tis.bz.it in order to object the processing of your personal
data for the purpose of sending advertising materials and also to exercise the
right to access personal data and other rights referred to in Section 7 of
Decree 196/2003. The data controller is TIS Techno Innovation Alto Adige,
Siemens Street n. 19, Bolzano. You can find the complete information on the web
si
te www.tis.bz.it.
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
il-antlr-interest group.
To post to this group, send email to il-antlr-inter...@googlegroups.com.
To unsubscribe from this group, send email to
il-antlr-interest+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 33276] [antlr-interest] (no subject)
Hello, I am Roland Sako from Geneva in Switzerland. I am currently working on a project which I need to generate an expression tree of an Objective-C source code, then I will visit that tree to add extra instruction in it. I just got an Objective-C grammar file from the web (http://spiny.com/software/objc.g) , but when trying to generate something I got error can only show generated grammar for java language. All I would need is to generate a Parser that can construct trees from objectiveC class files. Would it be possible with antlr? Thank you very much. Best Regards List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups il-antlr-interest group. To post to this group, send email to il-antlr-inter...@googlegroups.com. To unsubscribe from this group, send email to il-antlr-interest+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 33277] [antlr-interest] Left recursive grammar
Hi all,
I have this simple grammar
grammar test;
options {
language = Java;
output = AST;
}
a
:
a*B -^(B a*)
| A
;
B :
'.B'
;
A :
'A'
;
and I get the following output when I try to generate the parser in ANTRLWorks
[13:48:53] error(210): The following sets of rules are mutually left-recursive
[a]
I read on the Web that there are solutions to solve this, however they will
mess up the associativity, which I need to keep instead.
So, for instance, for the input
A.B.B
the AST tree should be
^(B ^(B A))
Is there any way to change the grammar in order to eliminate the left recursion
and obtain the above tree. I am afraid I do not get how to do it by just
looking at what is there online about left recursive grammars.
Thanks a lot for your help,
Luigi
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
il-antlr-interest group.
To post to this group, send email to il-antlr-inter...@googlegroups.com.
To unsubscribe from this group, send email to
il-antlr-interest+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 33278] Re: [antlr-interest] Left recursive grammar
Hi Luigi,
I'm not sure if this is possible with ANTLR, or any other LL parser
generator.
See this for a work-around:
http://stackoverflow.com/questions/3799890/antlr-ast-generating-possible-madness
If it _is_ possible using some sort of fancy AST rewrite magic, I'm sure
someone will correct me.
Regards,
Bart.
On Thu, Jul 21, 2011 at 3:00 PM, Luigi Iannone
iann...@cs.manchester.ac.ukwrote:
Hi all,
I have this simple grammar
grammar test;
options {
language = Java;
output = AST;
}
a
:
a*B -^(B a*)
| A
;
B :
'.B'
;
A :
'A'
;
and I get the following output when I try to generate the parser in
ANTRLWorks
[13:48:53] error(210): The following sets of rules are mutually
left-recursive [a]
I read on the Web that there are solutions to solve this, however they will
mess up the associativity, which I need to keep instead.
So, for instance, for the input
A.B.B
the AST tree should be
^(B ^(B A))
Is there any way to change the grammar in order to eliminate the left
recursion and obtain the above tree. I am afraid I do not get how to do it
by just looking at what is there online about left recursive grammars.
Thanks a lot for your help,
Luigi
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
il-antlr-interest group.
To post to this group, send email to il-antlr-inter...@googlegroups.com.
To unsubscribe from this group, send email to
il-antlr-interest+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 33279] Re: [antlr-interest] Left recursive grammar
Your example is ambiguous as well as left recursive. I assume you meant one
of the following:
a : a B | A;
a : A* B | A;
The first can be written as:
a : A (B^)*;
The second can be written as
a : A (A* B^)? | A | B;
Sam
-Original Message-
From: antlr-interest-boun...@antlr.org
[mailto:antlr-interest-boun...@antlr.org] On Behalf Of Luigi Iannone
Sent: Thursday, July 21, 2011 8:00 AM
To: ANTLR
Subject: [antlr-interest] Left recursive grammar
Hi all,
I have this simple grammar
grammar test;
options {
language = Java;
output = AST;
}
a
:
a*B -^(B a*)
| A
;
B :
'.B'
;
A :
'A'
;
and I get the following output when I try to generate the parser in
ANTRLWorks
[13:48:53] error(210): The following sets of rules are mutually
left-recursive [a]
I read on the Web that there are solutions to solve this, however they will
mess up the associativity, which I need to keep instead.
So, for instance, for the input
A.B.B
the AST tree should be
^(B ^(B A))
Is there any way to change the grammar in order to eliminate the left
recursion and obtain the above tree. I am afraid I do not get how to do it
by just looking at what is there online about left recursive grammars.
Thanks a lot for your help,
Luigi
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
il-antlr-interest group.
To post to this group, send email to il-antlr-inter...@googlegroups.com.
To unsubscribe from this group, send email to
il-antlr-interest+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 33280] Re: [antlr-interest] Left recursive grammar
Hi Sam,
But of course, with the inline tree rewrite operators it looks so straight
forward! Nice one!
Regards,
Bart.
On Thu, Jul 21, 2011 at 3:52 PM, Sam Harwell sharw...@pixelminegames.comwrote:
Your example is ambiguous as well as left recursive. I assume you meant one
of the following:
a : a B | A;
a : A* B | A;
The first can be written as:
a : A (B^)*;
The second can be written as
a : A (A* B^)? | A | B;
Sam
-Original Message-
From: antlr-interest-boun...@antlr.org
[mailto:antlr-interest-boun...@antlr.org] On Behalf Of Luigi Iannone
Sent: Thursday, July 21, 2011 8:00 AM
To: ANTLR
Subject: [antlr-interest] Left recursive grammar
Hi all,
I have this simple grammar
grammar test;
options {
language = Java;
output = AST;
}
a
:
a*B -^(B a*)
| A
;
B :
'.B'
;
A :
'A'
;
and I get the following output when I try to generate the parser in
ANTRLWorks
[13:48:53] error(210): The following sets of rules are mutually
left-recursive [a]
I read on the Web that there are solutions to solve this, however they will
mess up the associativity, which I need to keep instead.
So, for instance, for the input
A.B.B
the AST tree should be
^(B ^(B A))
Is there any way to change the grammar in order to eliminate the left
recursion and obtain the above tree. I am afraid I do not get how to do it
by just looking at what is there online about left recursive grammars.
Thanks a lot for your help,
Luigi
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
il-antlr-interest group.
To post to this group, send email to il-antlr-inter...@googlegroups.com.
To unsubscribe from this group, send email to
il-antlr-interest+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 33281] Re: [antlr-interest] (no subject)
Greetings!
On Thu, 2011-07-21 at 14:53 +0200, Roland Sako wrote:
Hello,
I am Roland Sako from Geneva in Switzerland. I am currently working on a
project which I need to generate an expression tree
of an Objective-C source code, then I will visit that tree to add extra
instruction in it.
I just got an Objective-C grammar file from the web
(http://spiny.com/software/objc.g) , but when trying to generate something I
got error can only show generated grammar for java language.
I do not think that this grammar is really for ANTLR --- or rather, if
it is, it must be run thru some preprocessor in order to transform it
into actual ANTLR meta-syntax...
that is, i notice the following non-ANTLR stuff (via a quick scan only):
begins with a {...} section rather than the keyword 'grammar'.
unknown ${declare ...} commands.
actions in [ ]
no lexer rules! e.g. no rule that starts with upper-case letter.
appears to define tokens using regular expressions surrounded
with s.
the last 6 or 7 rules in the file are kinda goofy (in ANTLR
terms).
All I would need is to generate a Parser that can construct trees from
objectiveC class files. Would it be possible with antlr?
the meat of the grammar does appear to be for ANTLR. if you can figure
out how to deal with the above non-ANTLRism you are probably well on
your way to a working parser.
Thank you very much.
i don't think i helped very much, sorry.
-jbb
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
il-antlr-interest group.
To post to this group, send email to il-antlr-inter...@googlegroups.com.
To unsubscribe from this group, send email to
il-antlr-interest+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 33282] Re: [antlr-interest] ANTLR gives segmentation fault for very large input
Is there is any way to delete AST (Abstract Syntax Tree) because it is of no use for my work. On Tue, Jul 19, 2011 at 9:08 PM, Jim Idle [via ANTLR] ml-node+6599207-454424018-346...@n2.nabble.com wrote: You are running out of memory - split up the input in some sensible way. Jim -Original Message- From: [hidden email] [mailto:antlr-interest- [hidden email]] On Behalf Of Piyush Sent: Tuesday, July 19, 2011 1:51 AM To: [hidden email] Subject: [antlr-interest] ANTLR gives segmentation fault for very large input Sir when i am trying to parse a very big input file (of nearly 450 lines) ANTLR is giving segmentation fault. Just for example my grammar funny.g is parsing input file input.v(of near about 45 lines) but gives segmentation fault for big_file_input.v(of about 450 lines) ,which also contains the same input as of input.v 10 times I am attaching my grammar (funny.g and input files) below. So please help me out where i am doing wrong or this is antlr's bug? Thanking You Piyush http://antlr.1301665.n2.nabble.com/file/n6598011/fun.tar fun.tar -- View this message in context: http://antlr.1301665.n2.nabble.com/ANTLR- gives-segmentation-fault-for-very-large-input-tp6598011p6598011.html Sent from the ANTLR mailing list archive at Nabble.com. List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your- email-address List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address If you reply to this email, your message will be added to the discussion below: http://antlr.1301665.n2.nabble.com/ANTLR-gives-segmentation-fault-for-very-large-input-tp6598011p6599207.html To unsubscribe from ANTLR gives segmentation fault for very large input, click here. Cheers! Piyush Bengal Engineering Science University Computer Science and Technology -- View this message in context: http://antlr.1301665.n2.nabble.com/ANTLR-gives-segmentation-fault-for-very-large-input-tp6598011p6607198.html Sent from the ANTLR mailing list archive at Nabble.com. List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups il-antlr-interest group. To post to this group, send email to il-antlr-inter...@googlegroups.com. To unsubscribe from this group, send email to il-antlr-interest+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 33283] [antlr-interest] on crap grammars
This test grammar was called crap by Jim Idle. I am willing to eat the humble
pie and admit where I am an ANTLR novice or don't know something about
grammars, but I am just not seeing it in this simple case:
grammar testerrors;
options
{
language='C';
}
NAME: ( 'a'..'z' | 'A'..'Z' | '0'..'9' )+ ;
WS : ( ' ' | '\t' | '\r' | '\n' )+ { $channel = HIDDEN; } ;
parse:
decl ( options { greedy = true; }: ',' decl )* ','? EOF
;
decl:
NAME ':' type
;
type:
'int' | 'float'
;
The start symbol is a comma-delimited list of simple 'name : type'
declarations and allows the list to optionally end in a comma as is done in
some languages (Python, etc). This is a pretty common way to structure it. In
JavaCC, for example, you'd use a local LOOKAHEAD(2) inside the ()* to
disambiguate the choice between matching one more decl or ending the list.
Without it and with the default k=1, JavaCC emits an ambiguity warning at
parser generation time. In ANTLR case, the ambiguity can be dealt with
similarly, with a local k=2 option or the way done above (which I borrowed from
http://www.antlr.org/grammar/1200715779785/Python.g). Without either, ANTLR
also emits a warning at parser generation time. All of this seems to work as
expected.
So, what is so obviously wrong with the grammar snippet that deserves the
crap moniker? I am learning ANTLR because I want to add a multi-target parser
generator tool to my skill set. For Java work, JavaCC is still out there and
generates fast parsers, has good error handling, and can build ASTs/visitors.
In C++, I would normally do a simple case like this via boost.spirit but it's a
bit of a template metaprogramming monster. With ANTLR I am successfully
compiling my C parser within a larger C++ codebase and the only learning curve
issues are odd error messages on relatively trivial input errors, where ANTLR
can't seem to identify the token it is expecting. E.g., input name : bad
results in
-memory-(1) : error 10 : Unexpected token, at offset 6
near [Index: 0 (Start: 0-Stop: 0) ='missing invalid', type0 Line: 1
LinePos:6]
: Missing invalid
I would be happy to get specific pointers to docs and articles on how to
improve error handling by ANTLR *C* parsers. At least being able to modify the
stock error display function to tackle the common case of mis-spelling a token
name would be great.
Thank you,
Vlad
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
il-antlr-interest group.
To post to this group, send email to il-antlr-inter...@googlegroups.com.
To unsubscribe from this group, send email to
il-antlr-interest+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 33284] Re: [antlr-interest] ANTLR gives segmentation fault for very large input
To skip the AST, just don't use the output=AST option. Here are some specs on the tokens. I'm including the overhead of having them in a CommonTokenStream (or equivalent) because they're not very useful otherwise. Java target, 32-bit VM: 48 bytes/token. Java target, 64-bit VM: 64 bytes/token. CSharp3 target: Same as Java target. C target, 32-bit: 148 bytes/token. C target, 64-bit: 248 bytes/token. You have 6 tokens per line, and it sounds like you're using the C target. The small/large files use 39KiB/3.72GiB of memory respectively for the tokens on a 32-bit machine. They use 65.4KiB/6.24GiB on a 64-bit machine. I'm developing an alternative to CommonToken that uses 8 bytes/token in all of the above targets. Once it's ready (which may not be until ANTLR v4), the same files will only need 2.1KiB/206MiB of memory, a savings of 94.6% on the 32-bit C target, and nearly 97% on the 64-bit C target. -Original Message- From: antlr-interest-boun...@antlr.org [mailto:antlr-interest-boun...@antlr.org] On Behalf Of Piyush Sent: Thursday, July 21, 2011 10:18 AM To: antlr-interest@antlr.org Subject: Re: [antlr-interest] ANTLR gives segmentation fault for very large input Is there is any way to delete AST (Abstract Syntax Tree) because it is of no use for my work. On Tue, Jul 19, 2011 at 9:08 PM, Jim Idle [via ANTLR] ml-node+6599207-454424018-346...@n2.nabble.com wrote: You are running out of memory - split up the input in some sensible way. Jim -Original Message- From: [hidden email] [mailto:antlr-interest- [hidden email]] On Behalf Of Piyush Sent: Tuesday, July 19, 2011 1:51 AM To: [hidden email] Subject: [antlr-interest] ANTLR gives segmentation fault for very large input Sir when i am trying to parse a very big input file (of nearly 450 lines) ANTLR is giving segmentation fault. Just for example my grammar funny.g is parsing input file input.v(of near about 45 lines) but gives segmentation fault for big_file_input.v(of about 450 lines) ,which also contains the same input as of input.v 10 times I am attaching my grammar (funny.g and input files) below. So please help me out where i am doing wrong or this is antlr's bug? Thanking You Piyush http://antlr.1301665.n2.nabble.com/file/n6598011/fun.tar fun.tar -- View this message in context: http://antlr.1301665.n2.nabble.com/ANTLR- gives-segmentation-fault-for-very-large-input-tp6598011p6598011.html Sent from the ANTLR mailing list archive at Nabble.com. List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your- email-address List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address If you reply to this email, your message will be added to the discussion below: http://antlr.1301665.n2.nabble.com/ANTLR-gives-segmentation-fault-for- very-large-input-tp6598011p6599207.html To unsubscribe from ANTLR gives segmentation fault for very large input, click here. Cheers! Piyush Bengal Engineering Science University Computer Science and Technology -- View this message in context: http://antlr.1301665.n2.nabble.com/ANTLR-gives-segmentation-fault-for-very-large-input-tp6598011p6607198.html Sent from the ANTLR mailing list archive at Nabble.com. List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups il-antlr-interest group. To post to this group, send email to il-antlr-inter...@googlegroups.com. To unsubscribe from this group, send email to il-antlr-interest+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 33285] Re: [antlr-interest] Deciphering the TreeWalker error message ...
On 07/21/2011 02:48 AM, Gary Miller wrote: 3. rule : ^(subrule otherrule) ; Just looks wrong. I am under the impression that a treewalker rule should be rooted in a TOKEN, not a subtree. The few treewalker grammars I have written always have rules that look like ^(TOKEN some other rules or TOKENS) If a subrule reference is not allowed to be the root of the tree being parsed, I would have thought that ANTLR would have issued an error when the tree grammar was run through ANTLR I could be wrong with my assumption here, but I have never gotten into trouble by assuming it (so far). Often this involves me collapsing my treewalker rules together. For example, if I have 12 parse rules to accurately describe precidence in an expression, my treegrammar might have 12 alternations, one for each possibly different rooted TOKEN when walking them. This makes my treegrammars (much) smaller than my parser grammars. If you inline (expand) out what you have written you would get compoundExpression : ^((SUB_EXPR ^(PAREN_SCLAR_EXPRESSION sclarExpression+) conversion_clause ) ; The ^(( is impossible Make all you start tree look like ^(TOKEN ...) ^(sign sse=sclarSubExpression) therefore also look wrong. Yes, treegrammar rules can refer to other rules, but the rooted expressions: ^() should be rooted with TOKENs. -- Kevin J. Cummings kjch...@verizon.net cummi...@kjchome.homeip.net cummi...@kjc386.framingham.ma.us Registered Linux User #1232 (http://counter.li.org) List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups il-antlr-interest group. To post to this group, send email to il-antlr-inter...@googlegroups.com. To unsubscribe from this group, send email to il-antlr-interest+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 33286] Re: [antlr-interest] on crap grammars
As Jim pointed out, your problem with tokens showing up in error
messages as invalid is because you just inlined lexer tokens (in your
type rule) without giving them a name. Try making two real lexer rules
with the names you would like to see:
INT : 'int';
FLOAT : 'float';
type : INT | FLOAT;
If you look at the generated C code, you will see how it determines the
string to use from this name. It is also fairly simple to override the
printed string on a case by case basis if that seems appropriate for
your errors. This may be necessary if you discover that the #defines
generated for INT and FLOAT conflict with other defines used in your
code and libraries. You can solve this generically by adding an
underscore to the end of the name (INT_ and FLOAT_), and then just strip
off the last character in your error handler.
- Justin
On 7/21/2011 11:42 AM, Vlad wrote:
This test grammar was called crap by Jim Idle. I am willing to eat the
humble pie and admit where I am an ANTLR novice or don't know something about
grammars, but I am just not seeing it in this simple case:
grammar testerrors;
options
{
language='C';
}
NAME: ( 'a'..'z' | 'A'..'Z' | '0'..'9' )+ ;
WS : ( ' ' | '\t' | '\r' | '\n' )+ { $channel = HIDDEN; } ;
parse:
decl ( options { greedy = true; }: ',' decl )* ','? EOF
;
decl:
NAME ':' type
;
type:
'int' | 'float'
;
The start symbol is a comma-delimited list of simple 'name :type'
declarations and allows the list to optionally end in a comma as is done in
some languages (Python, etc). This is a pretty common way to structure it. In
JavaCC, for example, you'd use a local LOOKAHEAD(2) inside the ()* to
disambiguate the choice between matching one more decl or ending the list.
Without it and with the default k=1, JavaCC emits an ambiguity warning at
parser generation time. In ANTLR case, the ambiguity can be dealt with
similarly, with a local k=2 option or the way done above (which I borrowed
from http://www.antlr.org/grammar/1200715779785/Python.g). Without either,
ANTLR also emits a warning at parser generation time. All of this seems to
work as expected.
So, what is so obviously wrong with the grammar snippet that deserves the
crap moniker? I am learning ANTLR because I want to add a multi-target
parser generator tool to my skill set. For Java work, JavaCC is still out
there and generates fast parsers, has good error handling, and can build
ASTs/visitors. In C++, I would normally do a simple case like this via
boost.spirit but it's a bit of a template metaprogramming monster. With ANTLR
I am successfully compiling my C parser within a larger C++ codebase and the
only learning curve issues are odd error messages on relatively trivial input
errors, where ANTLR can't seem to identify the token it is expecting. E.g.,
input name : bad results in
-memory-(1) : error 10 : Unexpected token, at offset 6
near [Index: 0 (Start: 0-Stop: 0) ='missinginvalid', type0 Line:
1 LinePos:6]
: Missinginvalid
I would be happy to get specific pointers to docs and articles on how to
improve error handling by ANTLR *C* parsers. At least being able to modify
the stock error display function to tackle the common case of mis-spelling a
token name would be great.
Thank you,
Vlad
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
il-antlr-interest group.
To post to this group, send email to il-antlr-inter...@googlegroups.com.
To unsubscribe from this group, send email to
il-antlr-interest+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 33287] Re: [antlr-interest] Antlr C target with LibXML
Also note that it should be possible (and desirable) for you to separate the logic so you don't need both headers at the same time. Please post your grammar files to get more help. Jim -Original Message- From: antlr-interest-boun...@antlr.org [mailto:antlr-interest- boun...@antlr.org] On Behalf Of Ivan Brezina Sent: Thursday, July 21, 2011 2:03 AM To: antlr-interest@antlr.org Subject: Re: [antlr-interest] Antlr C target with LibXML Hi, try to execute the compiler like gcc -E -P and check the output. Or try to compile the output manually. ANTLR adds a define for each token you declare and these macro definitions do interfere with some datatype present in libxml headers. For example if you create your own token called int in .g then the GLexer.h will contain a macro definition #define int some number When you declare your own token names, you should always use some prefix. Ivan PS: did you try to switch the order of headers included? PS2: off-topic on the other hand it is impossible to compile ANTLR headers with QT, because QT contains macro called emit white emit is a name of the function in antlr headers. Quoting Jim Idle j...@temporal-wave.com: The header files are interfering with each other. You probably need to separate your logic from your parser .g file. However, unless you post all of your project it is hard to see why. Look at the lines indicated as in error and you will probably find some symbol that ANTLR defines that libXML is also defining. When you know what it is, you can possibly undef it before including the libXML headers. I will also try to make time tomorrow to have a look at this. Jim -Original Message- From: antlr-interest-boun...@antlr.org [mailto:antlr-interest- boun...@antlr.org] On Behalf Of Richard Walton Sent: Wednesday, July 20, 2011 6:04 PM To: antlr-interest@antlr.org Subject: [antlr-interest] Antlr C target with LibXML Forgive me if this is not the correct etiquette for asking questions - This is the first mailing list I've subscribed to. I'm having a problem compiling an application using LibXML2 (http://xmlsoft.org/) with a C lexer/grammar generated from ANTLR. My problems are documented here: http://stackoverflow.com/questions/6769548/antlr-c-target-and-xmllib I would be very grateful for any help in fixing the problem. Kind regards, Richard List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your- email-address List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email- address This message was sent using IMP, the Internet Messaging Program. List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your- email-address List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups il-antlr-interest group. To post to this group, send email to il-antlr-inter...@googlegroups.com. To unsubscribe from this group, send email to il-antlr-interest+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 33288] Re: [antlr-interest] (no subject)
I think that it is a v2 grammar right?
JIm
-Original Message-
From: antlr-interest-boun...@antlr.org [mailto:antlr-interest-
boun...@antlr.org] On Behalf Of John B. Brodie
Sent: Thursday, July 21, 2011 7:03 AM
To: Roland Sako
Cc: antlr-interest@antlr.org
Subject: Re: [antlr-interest] (no subject)
Greetings!
On Thu, 2011-07-21 at 14:53 +0200, Roland Sako wrote:
Hello,
I am Roland Sako from Geneva in Switzerland. I am currently working
on
a project which I need to generate an expression tree of an
Objective-C source code, then I will visit that tree to add extra
instruction in it.
I just got an Objective-C grammar file from the web
(http://spiny.com/software/objc.g) , but when trying to generate
something I got error can only show generated grammar for java
language.
I do not think that this grammar is really for ANTLR --- or rather, if
it is, it must be run thru some preprocessor in order to transform it
into actual ANTLR meta-syntax...
that is, i notice the following non-ANTLR stuff (via a quick scan
only):
begins with a {...} section rather than the keyword 'grammar'.
unknown ${declare ...} commands.
actions in [ ]
no lexer rules! e.g. no rule that starts with upper-case
letter.
appears to define tokens using regular expressions surrounded
with s.
the last 6 or 7 rules in the file are kinda goofy (in ANTLR
terms).
All I would need is to generate a Parser that can construct trees
from objectiveC class files. Would it be possible with antlr?
the meat of the grammar does appear to be for ANTLR. if you can figure
out how to deal with the above non-ANTLRism you are probably well on
your way to a working parser.
Thank you very much.
i don't think i helped very much, sorry.
-jbb
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-
email-address
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
il-antlr-interest group.
To post to this group, send email to il-antlr-inter...@googlegroups.com.
To unsubscribe from this group, send email to
il-antlr-interest+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 33289] Re: [antlr-interest] ANTLR gives segmentation fault for very large input
Are you sure? Well, just don't generate it and remove the instructions that do? Jim -Original Message- From: antlr-interest-boun...@antlr.org [mailto:antlr-interest- boun...@antlr.org] On Behalf Of Piyush Sent: Thursday, July 21, 2011 8:18 AM To: antlr-interest@antlr.org Subject: Re: [antlr-interest] ANTLR gives segmentation fault for very large input Is there is any way to delete AST (Abstract Syntax Tree) because it is of no use for my work. On Tue, Jul 19, 2011 at 9:08 PM, Jim Idle [via ANTLR] ml-node+6599207- 454424018-346...@n2.nabble.com wrote: You are running out of memory - split up the input in some sensible way. Jim -Original Message- From: [hidden email] [mailto:antlr-interest- [hidden email]] On Behalf Of Piyush Sent: Tuesday, July 19, 2011 1:51 AM To: [hidden email] Subject: [antlr-interest] ANTLR gives segmentation fault for very large input Sir when i am trying to parse a very big input file (of nearly 450 lines) ANTLR is giving segmentation fault. Just for example my grammar funny.g is parsing input file input.v(of near about 45 lines) but gives segmentation fault for big_file_input.v(of about 450 lines) ,which also contains the same input as of input.v 10 times I am attaching my grammar (funny.g and input files) below. So please help me out where i am doing wrong or this is antlr's bug? Thanking You Piyush http://antlr.1301665.n2.nabble.com/file/n6598011/fun.tar fun.tar -- View this message in context: http://antlr.1301665.n2.nabble.com/ANTLR- gives-segmentation-fault-for-very-large-input-tp6598011p6598011.html Sent from the ANTLR mailing list archive at Nabble.com. List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your- email-address List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email- address If you reply to this email, your message will be added to the discussion below: http://antlr.1301665.n2.nabble.com/ANTLR-gives-segmentation-fault- for- very-large-input-tp6598011p6599207.html To unsubscribe from ANTLR gives segmentation fault for very large input, click here. Cheers! Piyush Bengal Engineering Science University Computer Science and Technology -- View this message in context: http://antlr.1301665.n2.nabble.com/ANTLR- gives-segmentation-fault-for-very-large-input-tp6598011p6607198.html Sent from the ANTLR mailing list archive at Nabble.com. List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your- email-address List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups il-antlr-interest group. To post to this group, send email to il-antlr-inter...@googlegroups.com. To unsubscribe from this group, send email to il-antlr-interest+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 33291] Re: [antlr-interest] [C target] Warnings in 64-bit compile
Yep - consider it done.
Jim
-Original Message-
From: antlr-interest-boun...@antlr.org [mailto:antlr-interest-
boun...@antlr.org] On Behalf Of Justin Murray
Sent: Thursday, July 21, 2011 10:19 AM
To: antlr-interest@antlr.org
Subject: Re: [antlr-interest] [C target] Warnings in 64-bit compile
Hi Jim,
I think I tracked down and fixed this bug in the C target template.
Attached is the patched version of C.stg, which I extracted from antlr-
3.4-complete-no-antlrv2.jar/org/antlr/codegen/templates/C/C.stg
and modified. It looks like it is a simple one line fix on line 1699,
changing from ANTLR3_UINT32 to ANTLR3_MARKER. I've confirmed that this
patch makes the warnings go away in my 64-bit build, so I'm submitting
for your review. Please let me know if/when this makes it into a
release.
Thanks,
-- Justin
On 6/24/2011 1:34 PM, Jim Idle wrote:
There are few bug fixes in this beta - all that I can get in will be
in the release version, which won't be too long now. However, you
should still avoid backtrack and memorize unless there is no other
choice.
Jim
-Original Message-
From: antlr-interest-boun...@antlr.org [mailto:antlr-interest-
boun...@antlr.org] On Behalf Of Justin Murray
Sent: Friday, June 24, 2011 8:12 AM
To: antlr-interest@antlr.org
Subject: Re: [antlr-interest] [C target] Warnings in 64-bit compile
Jim,
I just wanted to see if this was on your radar for the 3.4 C runtime
update. I haven't been able to test it with beta3 because I hit some
earlier roadblocks.
Thanks,
-- Justin
Ah it is probably because the backtrack and memorize option. I
strongly
advise that you don't use these but left factor your grammar.
However, I
will fix it of course.
Jim
-Original Message-
From: Justin Murray [mailto:jmur...@aerotech.com]
Sent: Tuesday, December 28, 2010 1:39 PM
To: Jim Idle; antl...@antlr.org
Subject: RE: [antlr-interest] [C target] Warnings in 64-bit
compile
I believe that it is caused by using the memorize=true; option and
building 64-bit. The following grammar has these warnings in the
generated TestParser.c (compiled as C++ code in Visual Studio
2008).
You will find the offending line at the beginning of the generated
prog() function.
-
grammar Test;
options
{
language=C;
backtrack=true;
memoize=true;
}
prog
: SOMETHING+;
SOMETHING
: 'A'..'Z';
--
Thanks,
Justin
-Original Message-
From: antl...@antlr.org
[mailto:antl...@antlr.org] On Behalf Of Jim Idle
Sent: Tuesday, December 28, 2010 3:04 PM
To: antl...@antlr.org
Subject: Re: [antlr-interest] [C target] Warnings in 64-bit
compile
There were some such warnings a number of versions back but they
are
all fixed as far as I know. What construct are you using that
results
in the warning? If you give me a reproducible grammar snippet,
then I
will fix it for the next release, which is just waiting on my
other
commitments right now.
Jim
-Original Message-
From: antl...@antlr.org [mailto:antlr-interest-
boun...@antlr.org] On Behalf Of Justin Murray
Sent: Tuesday, December 28, 2010 11:59 AM
To: antl...@antlr.org
Subject: [antlr-interest] [C target] Warnings in 64-bit compile
Jim,
I am working on making our compiler support 64-bit builds, and
have
run
into a number of compiler warnings due to conflicting types in the
ANTLR generated C code:
warning C4244: '=' : conversion from 'ANTLR3_MARKER' to
'ANTLR3_UINT32', possible loss of data
This comes from the line:
axisMask_StartIndex = INDEX();
axisMask_StartIndex is declared as type ANTLR3_UINT32, and INDEX()
is
returning type ANTLR3_MARKER. On a 64-bit build (on a Windows
machine),
ANTLR3_UINT32 is a typedef of uint32_t, and ANTLR3_MARKER is of
type
ANTLR3_INT64 which is a typedef of int64_t. It seems to me that
this
is
a bug in the template, and that axisMask_StartIndex should have
been
declared as type ANTLR3_MARKER.
My questions are, do you know of a quick workaround for this for
now?
Do you know if this will be fixed in the next release of the C
target
runtime? Also, is there a tenative release date for the C runtime
that
will officially support ANTLR 3.3 (it seems that the code
generated
by
ANTLR 3.3 works ok with the 3.2 C runtime)?
Thanks,
[il-antlr-interest: 33293] Re: [antlr-interest] [C target] Warnings in 64-bit compile
Understood, thanks!
On 7/21/2011 1:49 PM, Jim Idle wrote:
Well actually as this is a change to the template, it is not in the 3.4
release, but will be in the next patch release (should there be one).
Jim
-Original Message-
From: antlr-interest-boun...@antlr.org [mailto:antlr-interest-
boun...@antlr.org] On Behalf Of Justin Murray
Sent: Thursday, July 21, 2011 10:19 AM
To: antlr-interest@antlr.org
Subject: Re: [antlr-interest] [C target] Warnings in 64-bit compile
Hi Jim,
I think I tracked down and fixed this bug in the C target template.
Attached is the patched version of C.stg, which I extracted from antlr-
3.4-complete-no-antlrv2.jar/org/antlr/codegen/templates/C/C.stg
and modified. It looks like it is a simple one line fix on line 1699,
changing from ANTLR3_UINT32 to ANTLR3_MARKER. I've confirmed that this
patch makes the warnings go away in my 64-bit build, so I'm submitting
for your review. Please let me know if/when this makes it into a
release.
Thanks,
-- Justin
On 6/24/2011 1:34 PM, Jim Idle wrote:
There are few bug fixes in this beta - all that I can get in will be
in the release version, which won't be too long now. However, you
should still avoid backtrack and memorize unless there is no other
choice.
Jim
-Original Message-
From: antlr-interest-boun...@antlr.org [mailto:antlr-interest-
boun...@antlr.org] On Behalf Of Justin Murray
Sent: Friday, June 24, 2011 8:12 AM
To: antlr-interest@antlr.org
Subject: Re: [antlr-interest] [C target] Warnings in 64-bit compile
Jim,
I just wanted to see if this was on your radar for the 3.4 C runtime
update. I haven't been able to test it with beta3 because I hit some
earlier roadblocks.
Thanks,
-- Justin
Ah it is probably because the backtrack and memorize option. I
strongly
advise that you don't use these but left factor your grammar.
However, I
will fix it of course.
Jim
-Original Message-
From: Justin Murray [mailto:jmur...@aerotech.com]
Sent: Tuesday, December 28, 2010 1:39 PM
To: Jim Idle; antl...@antlr.org
Subject: RE: [antlr-interest] [C target] Warnings in 64-bit
compile
I believe that it is caused by using the memorize=true; option and
building 64-bit. The following grammar has these warnings in the
generated TestParser.c (compiled as C++ code in Visual Studio
2008).
You will find the offending line at the beginning of the generated
prog() function.
-
grammar Test;
options
{
language=C;
backtrack=true;
memoize=true;
}
prog
: SOMETHING+;
SOMETHING
: 'A'..'Z';
--
Thanks,
Justin
-Original Message-
From: antl...@antlr.org
[mailto:antl...@antlr.org] On Behalf Of Jim Idle
Sent: Tuesday, December 28, 2010 3:04 PM
To: antl...@antlr.org
Subject: Re: [antlr-interest] [C target] Warnings in 64-bit
compile
There were some such warnings a number of versions back but they
are
all fixed as far as I know. What construct are you using that
results
in the warning? If you give me a reproducible grammar snippet,
then I
will fix it for the next release, which is just waiting on my
other
commitments right now.
Jim
-Original Message-
From: antl...@antlr.org [mailto:antlr-interest-
boun...@antlr.org] On Behalf Of Justin Murray
Sent: Tuesday, December 28, 2010 11:59 AM
To: antl...@antlr.org
Subject: [antlr-interest] [C target] Warnings in 64-bit compile
Jim,
I am working on making our compiler support 64-bit builds, and
have
run
into a number of compiler warnings due to conflicting types in the
ANTLR generated C code:
warning C4244: '=' : conversion from 'ANTLR3_MARKER' to
'ANTLR3_UINT32', possible loss of data
This comes from the line:
axisMask_StartIndex = INDEX();
axisMask_StartIndex is declared as type ANTLR3_UINT32, and INDEX()
is
returning type ANTLR3_MARKER. On a 64-bit build (on a Windows
machine),
ANTLR3_UINT32 is a typedef of uint32_t, and ANTLR3_MARKER is of
type
ANTLR3_INT64 which is a typedef of int64_t. It seems to me that
this
is
a bug in the template, and that axisMask_StartIndex should have
been
declared as type ANTLR3_MARKER.
My questions are, do you know of a quick workaround for this for
now?
Do you know if this will be fixed in the next release of the C
target
runtime? Also, is there a tenative release date for the C runtime
that
will officially support ANTLR 3.3 (it seems that the code
generated
by
ANTLR 3.3 works ok with the 3.2 C runtime)?
Thanks,
Justin Murray
Software Engineer
jmur...@aerotech.com
Aerotech, Inc.
101
[il-antlr-interest: 33294] Re: [antlr-interest] [C target] Warnings in 64-bit compile
Jim Idle j...@temporal-wave.com wrote: Hi Jim! Well actually as this is a change to the template, it is not in the 3.4 release, but will be in the next patch release (should there be one). While we're talking C target and release, any ETA for the C runtime tarball for 3.4? Thanks, JB. -- Julien BLACHE http://www.jblache.org j...@jblache.org GPG KeyID 0xF5D65169 List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups il-antlr-interest group. To post to this group, send email to il-antlr-inter...@googlegroups.com. To unsubscribe from this group, send email to il-antlr-interest+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 33295] Re: [antlr-interest] 'Dude' error in v3.4 and possible bugs explained [was: on crap grammars]
Previously I was on 3.2 runtime. It occurred to me to try 3.4 released a day
ago. To this end I've switched to 3.4-beta4 runtime as well. Using one of
the testerrors.g grammars with non-inlined int/float tokens and parser
generated by antlr-3.4-complete.jar I now get on input string name : bad:
string(1) : error 4 : Unexpected token, at offset 6
near [Index: 4 (Start: 31458399-Stop: 31458401) ='bad', type6 Line: 1
LinePos:6]
: unexpected input...
expected one of : Actually dude, we didn't seem to be expecting anything
here, or at least
I could not work out what I was expecting, like so many of us these days!
(this required switching to antlr3StringStreamNew()
from antlr3NewAsciiStringInPlaceStream() as was posted by Jim here:
http://groups.google.com/group/il-antlr-interest/browse_thread/thread/981a79239e352c89
and
as is mentioned within that thread the last argument can't be NULL to avoid
a segfault).
So, this is better because at least the offending token is identified
correctly. The reason the expected set is still not identified correctly
(the 'Dude' part) is because the generated error path for the 'type'
non-terminal always sets the exception's expectingSet to NULL:
{
if ( ((LA(1) = AT_FLOAT_) (LA(1) = AT_INT_)) )
{
CONSUME();
PERRORRECOVERY=ANTLR3_FALSE;
}
else
{
CONSTRUCTEX();
EXCEPTION-type = ANTLR3_MISMATCHED_SET_EXCEPTION;
EXCEPTION-name = (void
*)ANTLR3_MISMATCHED_SET_NAME;
EXCEPTION-expectingSet = NULL; // ---
goto ruletypeEx;
}
}
I might be called names again, but I'd say this error handling does not look
correct because the rule knows exactly what token set it expects right here
but then goes ahead and ignores that info for the purposes of generating
exception info (what's the point in indicating ANTLR3_MISMATCHED_SET_NAME if
that set is always set to NULL).
Examining the generated parser code, I in fact see what appears to be a
correct set that would be FOLLOW(':'): it has bits set for AT_FLOAT_ and
AT_INT_ and is FOLLOWPUSH()ed before the rule is entered.
By manually doctoring the parser code to set EXCEPTION-expectingSet to
point to this FOLLOW set, I get rid of the 'Dude' message but hit on another
bug in displayRecognitionError() that prints the wrong two token names:
string(1) : error 4 : Unexpected token, at offset 6
near [Index: 4 (Start: 13845599-Stop: 13845601) ='bad', type6 Line: 1
LinePos:6]
: unexpected input...
expected one of : EOR, DOWN
Looking at the stock displayRecognitionError() code, it is clear that the
loop over the set bits is not correct (the TODO is right). Fixing it by
adding errBits-isMember(errBits, bit):
for (bit = 1; bit numbits count 8 count size; bit++)
{
// TODO: This doesn;t look right - should be asking if the bit is set!!
//
if (errBits-isMember(errBits, bit) tokenNames[bit]) // --- was
missing bitset member check
{
ANTLR3_FPRINTF(stderr, %s%s, count 0 ? , : , tokenNames[bit]);
count++;
}
}
finally gets me the error message that makes sense:
string(1) : error 4 : Unexpected token, at offset 6
near [Index: 4 (Start: 30442591-Stop: 30442593) ='bad', type6 Line: 1
LinePos:6]
: unexpected input...
expected one of : AT_FLOAT_, AT_INT_
Crap grammars, I hear somebody said? Hmm, I don't think so...
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
il-antlr-interest group.
To post to this group, send email to il-antlr-inter...@googlegroups.com.
To unsubscribe from this group, send email to
il-antlr-interest+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 33296] Re: [antlr-interest] [C target] Warnings in 64-bit compile
Today - I am just reviewing a few things to see if I want to fix them first... Jim -Original Message- From: antlr-interest-boun...@antlr.org [mailto:antlr-interest- boun...@antlr.org] On Behalf Of Julien BLACHE Sent: Thursday, July 21, 2011 11:28 AM To: antlr-interest@antlr.org Subject: Re: [antlr-interest] [C target] Warnings in 64-bit compile Jim Idle j...@temporal-wave.com wrote: Hi Jim! Well actually as this is a change to the template, it is not in the 3.4 release, but will be in the next patch release (should there be one). While we're talking C target and release, any ETA for the C runtime tarball for 3.4? Thanks, JB. -- Julien BLACHE http://www.jblache.org j...@jblache.org GPG KeyID 0xF5D65169 List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your- email-address List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups il-antlr-interest group. To post to this group, send email to il-antlr-inter...@googlegroups.com. To unsubscribe from this group, send email to il-antlr-interest+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 33298] Re: [antlr-interest] 'Dude' error in v3.4 and possible bugs explained [was: on crap grammars]
I think that Vlad may be onto something here. From what I can tell from my
generated grammar, this only affects ANTLR3_MISMATCHED_SET_EXCEPTION type
exceptions. My grammar has several hundred parser rules, but only in 4 cases is
a ANTLR3_MISMATCHED_SET_EXCEPTION generated. In all 4 cases, the expectingSet
is being set to NULL, and in no other cases is expectingSet being set to NULL.
I agree that this would be improved if changed as Vlad described.
It just so happens that the way I implemented my exception handling, I treat
ANTLR3_MISMATCHED_SET_EXCEPTION the same as ANTLR3_RECOGNITION_EXCEPTION, and
don't bother to display the expectingSet, so I never would have discovered this
problem.
Since I recently figured out how the C template works, I decided to take a
peek. I found the following in
antlr-3.4-complete-no-antlrv2.jar/org/antlr/codegen/templates/C/C.stg:
if(PARSER)
EXCEPTION-expectingSet = NULL;
! use following code to make it recover inline;
EXCEPTION-expectingSet = FOLLOW_set_in_ruleNameelementIndex;
!
endif
So it appears that this was done explicitly at some point. You could edit C.stg
to uncomment the code above, and I imagine that it will generate the correct
follow set pointer. Perhaps Jim knows why this is like this? This may be
avoiding some other problems, so I don't know how safe of a change this would
be.
- Justin
On 7/21/2011 2:45 PM, Vlad wrote:
Previously I was on 3.2 runtime. It occurred to me to try 3.4 released
a day ago. To this end I've switched to 3.4-beta4 runtime as well. Using one of
the testerrors.g grammars with non-inlined int/float tokens and parser
generated by antlr-3.4-complete.jar I now get on input string name : bad:
string(1) : error 4 : Unexpected token, at offset 6
near [Index: 4 (Start: 31458399-Stop: 31458401) ='bad', type6
Line: 1 LinePos:6]
: unexpected input...
expected one of : Actually dude, we didn't seem to be expecting
anything here, or at least
I could not work out what I was expecting, like so many of us these
days!
(this required switching to antlr3StringStreamNew() from
antlr3NewAsciiStringInPlaceStream() as was posted by Jim here:
http://groups.google.com/group/il-antlr-interest/browse_thread/thread/981a79239e352c89
and as is mentioned within that thread the last argument can't be NULL to
avoid a segfault).
So, this is better because at least the offending token is identified
correctly. The reason the expected set is still not identified correctly (the
'Dude' part) is because the generated error path for the 'type' non-terminal
always sets the exception's expectingSet to NULL:
{
if ( ((LA(1) = AT_FLOAT_) (LA(1) = AT_INT_)) )
{
CONSUME();
PERRORRECOVERY=ANTLR3_FALSE;
}
else
{
CONSTRUCTEX();
EXCEPTION-type =
ANTLR3_MISMATCHED_SET_EXCEPTION;
EXCEPTION-name = (void
*)ANTLR3_MISMATCHED_SET_NAME;
EXCEPTION-expectingSet = NULL; // ---
goto ruletypeEx;
}
}
I might be called names again, but I'd say this error handling does not
look correct because the rule knows exactly what token set it expects right
here but then goes ahead and ignores that info for the purposes of generating
exception info (what's the point in indicating ANTLR3_MISMATCHED_SET_NAME if
that set is always set to NULL).
Examining the generated parser code, I in fact see what appears to be a
correct set that would be FOLLOW(':'): it has bits set for AT_FLOAT_ and
AT_INT_ and is FOLLOWPUSH()ed before the rule is entered.
By manually doctoring the parser code to set EXCEPTION-expectingSet
to point to this FOLLOW set, I get rid of the 'Dude' message but hit on another
bug in displayRecognitionError() that prints the wrong two token names:
string(1) : error 4 : Unexpected token, at offset 6
near [Index: 4 (Start: 13845599-Stop: 13845601) ='bad', type6
Line: 1 LinePos:6]
: unexpected input...
expected one of : EOR, DOWN
Looking at the stock displayRecognitionError() code, it is clear that
the loop over the set bits is not correct (the TODO is right). Fixing it by
adding errBits-isMember(errBits, bit):
for (bit = 1; bit numbits count 8 count size; bit++)
{
// TODO: This doesn;t look right - should be asking if the bit is set!!
//
if (errBits-isMember(errBits, bit) tokenNames[bit]) // ---
was missing bitset member check
{
ANTLR3_FPRINTF(stderr, %s%s, count 0 ? , : , tokenNames[bit]);
count++;
}
}
finally gets me the error message that makes sense:
[il-antlr-interest: 33299] Re: [antlr-interest] 'Dude' error in v3.4 and possible bugs explained [was: on crap grammars]
This was changed because the tool no longer generates those sets.
Jim
-Original Message-
From: antlr-interest-boun...@antlr.org [mailto:antlr-interest-
boun...@antlr.org] On Behalf Of Justin Murray
Sent: Thursday, July 21, 2011 12:28 PM
To: Vlad
Cc: antlr-interest@antlr.org
Subject: Re: [antlr-interest] 'Dude' error in v3.4 and possible bugs
explained [was: on crap grammars]
I think that Vlad may be onto something here. From what I can tell from
my generated grammar, this only affects ANTLR3_MISMATCHED_SET_EXCEPTION
type exceptions. My grammar has several hundred parser rules, but only
in 4 cases is a ANTLR3_MISMATCHED_SET_EXCEPTION generated. In all 4
cases, the expectingSet is being set to NULL, and in no other cases is
expectingSet being set to NULL. I agree that this would be improved if
changed as Vlad described.
It just so happens that the way I implemented my exception handling, I
treat ANTLR3_MISMATCHED_SET_EXCEPTION the same as
ANTLR3_RECOGNITION_EXCEPTION, and don't bother to display the
expectingSet, so I never would have discovered this problem.
Since I recently figured out how the C template works, I decided to
take a peek. I found the following in antlr-3.4-complete-no-
antlrv2.jar/org/antlr/codegen/templates/C/C.stg:
if(PARSER)
EXCEPTION-expectingSet = NULL;
! use following code to make it recover inline;
EXCEPTION-expectingSet = FOLLOW_set_in_ruleNameelementIndex;
!
endif
So it appears that this was done explicitly at some point. You could
edit C.stg to uncomment the code above, and I imagine that it will
generate the correct follow set pointer. Perhaps Jim knows why this is
like this? This may be avoiding some other problems, so I don't know
how safe of a change this would be.
- Justin
On 7/21/2011 2:45 PM, Vlad wrote:
Previously I was on 3.2 runtime. It occurred to me to try 3.4
released a day ago. To this end I've switched to 3.4-beta4 runtime as
well. Using one of the testerrors.g grammars with non-inlined int/float
tokens and parser generated by antlr-3.4-complete.jar I now get on
input string name : bad:
string(1) : error 4 : Unexpected token, at offset 6
near [Index: 4 (Start: 31458399-Stop: 31458401) ='bad',
type6 Line: 1 LinePos:6]
: unexpected input...
expected one of : Actually dude, we didn't seem to be expecting
anything here, or at least
I could not work out what I was expecting, like so many of us
these days!
(this required switching to antlr3StringStreamNew() from
antlr3NewAsciiStringInPlaceStream() as was posted by Jim here:
http://groups.google.com/group/il-antlr-
interest/browse_thread/thread/981a79239e352c89 and as is mentioned
within that thread the last argument can't be NULL to avoid a
segfault).
So, this is better because at least the offending token is
identified correctly. The reason the expected set is still not
identified correctly (the 'Dude' part) is because the generated error
path for the 'type' non-terminal always sets the exception's
expectingSet to NULL:
{
if ( ((LA(1) = AT_FLOAT_) (LA(1) = AT_INT_)) )
{
CONSUME();
PERRORRECOVERY=ANTLR3_FALSE;
}
else
{
CONSTRUCTEX();
EXCEPTION-type =
ANTLR3_MISMATCHED_SET_EXCEPTION;
EXCEPTION-name = (void
*)ANTLR3_MISMATCHED_SET_NAME;
EXCEPTION-expectingSet = NULL; // ---
goto ruletypeEx;
}
}
I might be called names again, but I'd say this error handling
does not look correct because the rule knows exactly what token set it
expects right here but then goes ahead and ignores that info for the
purposes of generating exception info (what's the point in indicating
ANTLR3_MISMATCHED_SET_NAME if that set is always set to NULL).
Examining the generated parser code, I in fact see what appears to
be a correct set that would be FOLLOW(':'): it has bits set for
AT_FLOAT_ and AT_INT_ and is FOLLOWPUSH()ed before the rule is entered.
By manually doctoring the parser code to set EXCEPTION-
expectingSet to point to this FOLLOW set, I get rid of the 'Dude'
message but hit on another bug in displayRecognitionError() that prints
the wrong two token names:
string(1) : error 4 : Unexpected token, at offset 6
near [Index: 4 (Start: 13845599-Stop: 13845601) ='bad',
type6 Line: 1 LinePos:6]
: unexpected input...
expected one of : EOR, DOWN
Looking at the stock displayRecognitionError() code, it is clear
that the loop over the set bits is not correct (the TODO is right).
Fixing it by adding errBits-isMember(errBits, bit):
for (bit = 1; bit numbits count 8 count size; bit++)
{
[il-antlr-interest: 33304] Re: [antlr-interest] Incompatible type in subrules with OR
Try the following options.
1.
locationStep: edge condition? (repeat | shortestPath)? ('' locationStep)?
- ^(LOCATIONSTEP condition? repeat? shortestPath? locationStep?);
condition: ( filter | subquery ) condition?
- ^(CONDITION filter? subquery? condition?);
or
2.
locationStep
: edge condition? repeat? ('' locationStep)? - ^(LOCATIONSTEP
condition? shortestPath? locationStep?)
| edge condition? shortestPath? ('' locationStep)? -
^(LOCATIONSTEP condition? shortestPath? locationStep?)
;
condition
: filter condition? - ^(CONDITION filter condition?)
| subquery condition? - ^(CONDITION subquery condition?)
;
Regards
Gary
On Thu, Jul 21, 2011 at 9:16 PM, Claudio Martella
claudio.marte...@tis.bz.it wrote:
Hello,
I've this grammar: http://pastebin.com/dNzdGx8R but i get this error
when I test it with AntlrWorks:
[11:23:59] /Users/hammer/output/RDFPathParser.java:383: incompatible types
[11:23:59] found : RDFPathParser.repeat_return
[11:23:59] required: RDFPathParser.shortestPath_return
[11:23:59] v=repeat();
[11:23:59] ^
[11:23:59] /Users/hammer/output/RDFPathParser.java:586: incompatible types
[11:23:59] found : RDFPathParser.filter_return
[11:23:59] required: RDFPathParser.subquery_return
[11:23:59] v=filter();
[11:23:59] ^
[11:23:59] 2 errors
Basically I think the problem is the assignment in the subrules with ORs
in two statements:
locationStep: edge condition? (v=repeat | v=shortestPath)? (''
locationStep)?
- ^(LOCATIONSTEP condition $v locationStep);
condition: ( v=filter | v=subquery ) condition?
- ^(CONDITION $v condition);
How do I handle these situations where I have the two or more options in
a subrule?
Thanks
Claudio
--
Claudio Martella
Free Software Open Technologies
Analyst
TIS innovation park
Via Siemens 19 | Siemensstr. 19
39100 Bolzano | 39100 Bozen
Tel. +39 0471 068 123
Fax +39 0471 068 129
claudio.marte...@tis.bz.it http://www.tis.bz.it
Short information regarding use of personal data. According to Section 13 of
Italian Legislative Decree no. 196 of 30 June 2003, we inform you that we
process your personal data in order to fulfil contractual and fiscal
obligations and also to send you information regarding our services and
events. Your personal data are processed with and without electronic means
and by respecting data subjects' rights, fundamental freedoms and dignity,
particularly with regard to confidentiality, personal identity and the right
to personal data protection. At any time and without formalities you can
write an e-mail to priv...@tis.bz.it in order to object the processing of
your personal data for the purpose of sending advertising materials and also
to exercise the right to access personal data and other rights referred to in
Section 7 of Decree 196/2003. The data controller is TIS Techno Innovation
Alto Adige, Siemens Street n. 19, Bolzano. You can find the complete
information on the web si
te www.tis.bz.it.
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
il-antlr-interest group.
To post to this group, send email to il-antlr-inter...@googlegroups.com.
To unsubscribe from this group, send email to
il-antlr-interest+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
