[antlr-interest] ANTLR3 vcab import exception

[Jim Idle]

________________________________

From: antlr-interest-bounces at antlr.org on behalf of Oliver Zeigermann
Sent: Tue 10/18/2005 1:15 PM
Cc: ANTLR Interest
Subject: Re: [antlr-interest] ANTLR3 vcab import exception



2005/10/18, Terence Parr <parrt at cs.usfca.edu>:
>
> On Oct 18, 2005, at 12:50 PM, Jim Idle wrote:
>
> > Anyone got any thoughts on this (ANTLR 3 built from source code as
> > of Sunday evening, JDK 1.5 Update 5)
> >
> > problem reading token vocabulary file cmql.tokens:
> > java.lang.NullPointerException
> > org.antlr.tool.AssignTokenTypesWalker.importTokenVocab(Unknown Source)
> > org.antlr.tool.AssignTokenTypesWalker.option(Unknown Source)
> > org.antlr.tool.AssignTokenTypesWalker.optionsSpec(Unknown Source)
> > org.antlr.tool.AssignTokenTypesWalker.grammarSpec(Unknown Source)
> > org.antlr.tool.AssignTokenTypesWalker.grammar(Unknown Source)
> > org.antlr.tool.Grammar.setGrammarContent(Unknown Source)
> > org.antlr.Tool.process(Unknown Source)
> > org.antlr.Tool.main(Unknown Source)
>
> I wonder why it says "unknown source"?  Perhaps 1.5 can't read
> old .class files completely?  That would be odd...if you can get me a
> line number i'll look it up ;)

This is most likely because the sources have been compiled without
debug and/or line number options.


Indeed, that is why the unknownsource is there. The exception is being thrown from the code in generated by assign.types.g (at least, according to grep that is the only place it could be thrown). The antrl.jar is built compeltely from scratch using jdk 1.5 and there are no 1.4 classes around because I don't have that jdk loaded.

I will have to rebuild but I will have to setup the project to build it again and so on as I am on the road with my laptop and blah blah blah. Trying to simplify the grammar to see if it goes away. I would also try with the last antlr.jar you produced, but the problem there is that it produces code tha won't compile so I am a bit stuck. This jar has a fix to java.stg that casts adaptor.create() to <<ASTLabelType>> (or whatever the parameter is), which fixes the defualt tree building stuff when ASTLabelType=CommonTree... or at least, I thought it did ;-)

Is the following (example simplified) tree stuff expected to work right now?

: "KEYWORD" STRING -> ^("KEYWORD" STRING)
;

Somehow there must be a strange token or somethign in there, or at least something it does not like, but because I forgot to turn on the debug option for the jar I built, it is hard for me to trace of course. Here are the tokens in case it helps. BTW - do you wantt this type of stuff sent here, or do you prefer an email direct via the feedback web page? I don't mind either way of course.

$ sort -n -k2 -t= cmql.tokens
QUERY=4
DICTSPEC=5
DICTELEMENT=6
DICTNAME=7
DICTHEADING=8
DICTATTRSPEC=9
TERMINALSPEC=10
PRINTERSPEC=11
OUTPUTSPEC=12
QUERYBODY=13
QUERYSPECS=14
FILENAME=15
COMMAND=16
PROCESSOR=17
SORTED=18
TYPEIDLIST=19
TYPEITEMSTREAM=20
TYPEDATASTREAM=21
STATEMENT=22
CONNECTIVES=23
SELECTTO=24
SAVING=25
SELECTFACTOR=26
LBRACE=27
RBRACE=28
EQ=29
STRING=30
SEMI=31
WORD=32
ATTRIBUTEVALUE=33