Invalid constants file

[Ducky]

The constants file I sent you was generated using the latest jar you
sent me.

I ran it again today with the most recent jar you sent me and there
are still several duplicate constants defined. I run a batch file that
wipes out any existing java files (and I have also done it manually to
be sure) it is a freshly generated constants file.

The grammar that I am using (and sent to you) is not public, please do
not post details of that grammar to this discussion group.

Regards,

Dale

-----Original Message-----
From: "Jonathan Revusky" [rev...@gmail.com]
Date: 02/17/2009 02:34 AM
To: "Dale Lotts"
Subject: Re: try this one

> This is the grammar I am using - note that the generated
> Constants has duplicate tokens defined.

Yeah, I see the problem. You see FreeCC unifies much more the tokens
with syntactic productions, so Token implements Node as well and the
token.kind field is the ID of a token. So, basically, it generates
constants by capitalizing the name for both tokens and productions,
and you have a token called DISTRACTER and a production called
distracter and it generates a constant name for the token and the
production that is the same -- DISTRACTER.

And this can be quite a common issue, especially if you are moving
from jjtree/javacc. In any case, this is fixed basically. It should
work if you use the freecc.jar I sent you. This is because if there is
a token called DISTRACTER and a syntactic production that would also
generate a constant name of DISTRACTER, it appends _PRODUCTION to the
constant name for the production, to avoid the duplicate naming. You
might have to delete any older XXXConstants.java file you have lying
around.

I've attached the most current freecc.jar again just in case.

Anyway, please write about any further issues you come across to the
freecc-devel mailing list. There is a basic need to generate some
visible activity so that people can see that the project is alive.

Thanks,

JR

[Ducky]

Using the new jar you sent me the constants file is now correct.
However, there is still one issue.

The following code starts line 826 of the generated parser:
distracter node2=null;
if (buildTree) {
node2=new distracter();
Token jjtStartToken=getToken(1);
node2.setBeginLine(jjtStartToken.beginLine);
node2.setBeginColumn(jjtStartToken.beginColumn);
node2.setInputSource(this.getInputSource());
openNodeScope(node2);
}

There is no class generated with the name "distracter".

Let me know if you need me to send you the grammar again.

-Dale

[Jonathan Revusky]

On Wed, Feb 25, 2009 at 4:34 PM, Ducky <dale....@gmail.com> wrote:
>
> Using the new jar you sent me the constants file is now correct.
> However, there is still one issue.
>
> The following code starts line 826 of the generated parser:
>        distracter node2=null;
>        if (buildTree) {
>            node2=new distracter();
>            Token jjtStartToken=getToken(1);
>            node2.setBeginLine(jjtStartToken.beginLine);
>            node2.setBeginColumn(jjtStartToken.beginColumn);
>            node2.setInputSource(this.getInputSource());
>            openNodeScope(node2);
>        }
>
> There is no class generated with the name "distracter".

Drat. I see the problem here, which is that I didn't adjust that part
of the code generation template.

These bugs you're running into are actually fairly shallow. I mean,
they're not bugs in any deep algorithms or anything. The overall
problem here is that it is screwing up when there is a production with
the same name as a token, even the same name case-insensitively, like
in this case, a token named DISTRACTER and a BNF production called
distracter. I thought the only issue was using the same constant name,
which was the original problem you ran into, so what it does now is
that if there is a token named DISTRACTER, say, then it names the
constant for the BNF production DISTRACTER_PRODUCTION to distinguish
it. But there is some other naming issue here...

One workaround would probably be to make sure that none of your tokens
and BNF productions have the same name (even case insensitive-wise) as
in DISTRACTER/distracter in this case. Or alternatively, (and these
workarounds should only be necessary until I've absolutely nailed this
naming scheme stuff) is to explicitly name the node for the distracter
production, so where you have

void distracter(ElementBuilder parent, Color foreColor, Color
backgroundColor ) :

you could have:

void distracter(ElementBuilder parent, Color foreColor, Color
backgroundColor ) #BNF_DISTRACTER(>1) :

You see, the name of the node class is simply assumed to be distracter
unless it is overridden by a tree-building annotation as above.

Oh, and also note that if you are not using tree-building, i.e. in
JavaCC-land, you are using javacc, but not jjtree, then you should not
have much of an issue at all, since you just put
TREE_BUILDING_ENABLED=false;

in your options block and you don't have any of these issues AFAICS.

>
> Let me know if you need me to send you the grammar again.

I still have the grammar you sent me and yes, I reproduced your
problem. You can expect a resolution of this stuff pretty soon
because, as I said, these are very shallow issues really. Also, the
other issue you filed with the NPE, I see the bug there also. It's a
problem that occurs in token productions which use <*> to say that
they are in all lexical states.

Anyway, thanks a lot for reporting these issues. It would be very very
hard to nail all these bugs without at least some third parties out
there trying to use the tool and reporting back, as you have done. If
I wasn't at this exact moment a bit distracted by other things, I'd
probably have fixed these things within a few hours of receiving the
bug report, but due to the some other matters, it may take a day or
two.

Thanks,

JR