Hi,
I am aware that antlr input stream/reader is the important part of the
parsing, lexing and recognition in antlr as getting character stream is
important to do all these things.
But, we have a parser that works in JEE environment. And unlike DSL we have
very small requirement where we have to
Hi,
I am aware that antlr input stream/reader is the important part of the
parsing, lexing and recognition in antlr as getting character stream is
important to do all these things.
But, we have a parser that works in JEE environment. And unlike DSL we have
very small requirement where we have to
2009/12/13 Gavin Lambert :
> At 07:37 14/12/2009, Marcin Rzeźnicki wrote:
>>Specifically I constructed a sort of catch-all rule which I
>>called LINEOFTEXT and was like ~('\n' | '\r')*. After
>>replacing that with simple .* LINETERMINATOR my problems went
>>away.
>
> Actually, the former is better
2009/12/13 Jim Idle :
> This usually means that your lexer token numbers are out of sync with your
> parser tokens. Regen in correct order and make sure all tokens have been
> declared.
>
Umm, what if I work with combined grammar? And some of literals are 'inlined'?
> Jim
>
> On Dec 13, 2009, at
Hi,
This question is so rudimentary that I am almost embarrassed to ask. But since I almost never try to use ANTLRWorks for my parsers, I'll risk injuring my pride in exchange for learning something.
If I paste the Expr.g *verbatim* from
http://www.antlr.org/works/help/tutorial/content/Expr.
FYI. If anyone is maintaining the info at
http://www.antlr.org/works/help/tutorial/howtorun.html, the last sentence on the
page may be out of date.
I've been using OpenJDL/IcedTea 1.6.x with no problems that I'm aware of.
signature.asc
Description: OpenPGP digital signature
List: http://
Thanks. I am investigating several options now including modifying the v3
ANSI C grammar. I ran into an issue with typedef with that grammar and am
trying to reproduce it in a simpler example.
rahul
On Sun, Dec 13, 2009 at 1:02 PM, Jim Idle wrote:
> You could write your own based upon the v3
At 07:37 14/12/2009, Marcin Rzeźnicki wrote:
>Specifically I constructed a sort of catch-all rule which I
>called LINEOFTEXT and was like ~('\n' | '\r')*. After
>replacing that with simple .* LINETERMINATOR my problems went
>away.
Actually, the former is better than the latter
(more specific
You need to left factor the common introduction to both lays and
decide what it us when you hit ';' or don't.
Jim
On Dec 13, 2009, at 11:49, Johannes Bittner
wrote:
> Hello,
>
> The Java code generated for the following grammar produces a
> NoViableAltException when using "void foo (int a,
This usually means that your lexer token numbers are out of sync with
your parser tokens. Regen in correct order and make sure all tokens
have been declared.
Jim
On Dec 13, 2009, at 11:23, Marcin Rzeźnicki
wrote:
> Hi all,
> What could possibly MismatchedTokenException(0!=0) mean? It happ
On 12/13/2009 02:49 PM, Johannes Bittner wrote:
> Hello,
>
> The Java code generated for the following grammar produces a
> NoViableAltException when using "void foo (int a, int b) { foo }" as
> input, i.e. when the second token is "foo", it works otherwise. I
> tried this with antlrworks 1.3.1. C
Hello,
The Java code generated for the following grammar produces a
NoViableAltException when using "void foo (int a, int b) { foo }" as
input, i.e. when the second token is "foo", it works otherwise. I
tried this with antlrworks 1.3.1. Could somebody clearify why this
happens?
Thanks, Johannes
Hi all,
What could possibly MismatchedTokenException(0!=0) mean? It happened
to me when matching lexer token in parser. Input is as expected (the
text at the point of error matches what would go into this specific
token). It looks like ANTLR lost track of token type identifiers.
--
Greetings
Marc
Thank you very much Jim for offering your help but I think I know now
what has been hitting me. You are right, that was lexer. Specifically
I constructed a sort of catch-all rule which I called LINEOFTEXT and
was like ~('\n' | '\r')*. After replacing that with simple .*
LINETERMINATOR my problems w
Wrestled Hudson into submission but I have not put all the build parameters in
place for it until this afternoon, after which the snapshots and so on will all
be working again. Unfortunately we have a chicken and egg situation with a
change to the generator and the runtime at the same time, whic
It might be better to lex just one token here and not worry about what
characters are in it. Then check it semantically. You will then get errors like
"#z is not a vlaid exactness sequence", instead of the lexer saying "Unexpected
character 'z'". I see the original question was answered so I won
The analysis can take a lot of memory and you may just need more stack space,
but it could also be your grammar construction. Lexers especially can use a lot
of memory to analyse, especially if you specify huge sets of 'valid'
characters'. I'll look at it if you send it to me.
jim
> -Origi
On Sun, 2009-12-13 at 17:38 +0100, Hans-Martin Adorf wrote:
> An no, blanks are not permitted between #b and #e, since these
> character sequences are prefixes for binary numbers in Scheme (#b
> signifies a binary number, #e an exact number).
>
> How can I switch off spaces?
the action `{ $channe
ANTLR can only know so much from your grammar and in a lexer, when it sees a
character it doesn't understand it can only show an error, consume it and move
on. The error will not mean much to the user. The idea is leave errors to be
reported as high up the tool chain as you can (in general) as y
You could write your own based upon the v3 version of the C grammar. Someone
was transforming this to a full gcc compatible parser and said they would
publish it, but that seems to have gone away. Not sure about ANTLR based tools,
but there are plenty of C transformation tools out there.
Jim
> -Original Message-
> From: antlr-interest-boun...@antlr.org [mailto:antlr-interest-
>
> Well, now I just have to tell a little story of how semicolons can
> cause a lot of pain, it happened to me recently. It begins with the
> horror that is T-SQL, which is one of my day-job languages
Thanks a lot Jim. That was very quick.
I will check it out and let you know.
Gokul.
On Fri, Dec 11, 2009 at 9:43 PM, Jim Idle wrote:
> The latest templates process the default parameter values correctly, I
> fixed that too – I need to fix Hudson so the snapshot gets built, but you
> can also
Hi,
thanks, the trick with leaving out one of the question marks does the job.
An no, blanks are not permitted between #b and #e, since these character
sequences are prefixes for binary numbers in Scheme (#b signifies a binary
number, #e an exact number).
How can I switch off spaces?
Regards
Ha
Hi to all,
I am experiencing some problems with excessive memory usage when
generating my parser. I allocated 128MB of heap memory to ANTLRWorks
and it cannot complete generation of parser for Java-like expressions.
I suspect this is rater bad sign but I am not sure whether I need, at
this point, t
2009/12/10 Sam Harwell :
> You're making this too complicated. Parse the identifier as loosely as
> absolutely possible. Many improper identifiers actually don't cause any
> problems in parsing, so you can treat them as valid and provide compiler
> error messages like semantics problems in post-
Greetings!
On Sun, 2009-12-13 at 14:20 +0100, Hans-Martin Adorf wrote:
> here is an excerpt on a SchemeNumber grammar which is part of a Scheme
> grammar that I am toying with.
>
> grammar SchemeNumber;
> tokens {
> HASH = '#' ;
> }
> prefix2: RADIX2 EXACTNESS?
> | EXACTNESS? R
Hi Folks,
here is an excerpt on a SchemeNumber grammar which is part of a Scheme
grammar that I am toying with.
grammar SchemeNumber;
tokens {
HASH = '#' ;
}
prefix2: RADIX2 EXACTNESS?
| EXACTNESS? RADIX2
;
RADIX2: HASH ('b'|'B');
EXACTNESS: HASH ('i'|'I'|'
Hello,
extract of my grammar:
procedural_statement
: WS? builtin_procedure_name WS? '(' argument (',' argument)*)? ')' WS?
;
builtin_procedure_name
: CALL_CMD | EXECUTE_CMD | DB_OPEN | DB_CLOSE | DEFINE_LOGICAL
CALL_CMD
: 'CALL_CMD'
;
etc...
I want to get (print) the procedural_statement only
At 13:37 12/12/2009, David-Sarah Hopwood wrote:
>I thought lexer rules were supposed to find the longest match?
>How can they do that if they're unable to handle common left
>prefixes?
>
>(I have the impression that "longest match" may not be quite
>accurate, but if so, I've never seen the ac
29 matches
Mail list logo
