I am very happy to say that I am looking in to JavaCC. While developing a sample grammar file I am facing a problem please go through the following .
I want to validate a conditional statement which starts with either "if" or "IF"(like this I want to validate any token with case insensitive).
But I am able to validate only one of the cases.
The process That I followed is as follows.
* I have declared (if or IF) as a token
* I have defined option
IGNORE_CASE = true;
Please let me know at the earliest. Thanks in advance.
You are in the wrong forum. This forum is for UDS - Universal Development Server (formerly known as Forte 4GL). You would be better off posting your questions to a Java (or java related) forum (SunONE Studio for instance).
I beg to differ. He is writing a Forte UDS grammar to convert Tool to Java. We should fully support him in this effort -- especially in consideration of the prices that consulting companies charge to do that conversion for you. They won't sell you their tool. I, too, will be developing a Forte UDS grammar for javacc in order to do this conversion.
What's your goal? Tree producer, Translator or a feeder to a new Fort� compiler?
I may be digressing but why not hijacking the actual Fort� TOOL parser: proxyfy the library qqc4 that contains the "qqc4_4GLParser::yyparse" method(on windoze the Fort� dev runtime has been compiled with the debug flags so you get the full name of most of the methods in the dll) that spews a load of qqc4_Statement, qqc4_Expression ... or any other technique to intercept APIs calls on wintel machines.
Are the grammar and parser producer mandatory thingies?
Just out of curiousity are the GUI & overall architecture migrated yet?
Did you try to manually fcompile a dummy partition that contains your components and use a C++ grammar & parser. Sounds silly I know.
Otherwise go down the road of opening Fort� workspace using Fort� (hidden Configuration, TOOLompiler plans & more) the ClassType gives you many things (except virtual attributes) and hacking thru qqrt_IRBlock and reparse the Byte* attribute, you get a much simpler thing to parse (roughly a set of 250 'assembly like' instructions with already ID'ed operands and well formatted parameters) I've done that manually to extract algorithms from deployed partitions (interpreted) where no source code was available. Should be easier to write the grammar for a "byte array" than a developer's dissertation.
Is there a way to call fcompile and tell it to output the .c files? I'm thinking if I can get ahold of the C files I can use antlr 3 with an ansi C grammar, set the target to java and have antlr generate .java files from the .c files.
I'm got even sure what file to send into fcompile - what's the file extension fcompile is expecting to see?
Thanks for ANY help - thoughts greatly appreciated.
I haven't done this for a while so I may be a bit rusty.
The "-cleanup" flag tells fcompile to delete the generated files - so try running fcompile without it to keep the generated code.
fcompile takes .pgf files as input.
You can find more details on fcompile in "A Guide to the iPlanet UDS Workshops" manual.
I'll assume you are new to that Fort� thing,
look at what's in the fcompile shell script to see what can be an input to it, but you need to partition the app thru the Workshop or fscript
ftcmpile always output the generated C++, so to cover the basics, make a dummy application with 1 client partition and 1 server partition all in 1 project called TestApp. From the Fort� workshop partition this application and view the properties on the right pane of the partition workshop make sure you checked the box "Compiled"
basically do as Mark advised, read thru
kick the C++ compilation from the partition workshop and chose make all, autocompile (if it is not done yet you need to load into the environment repository apps AUTOCOMPILESVC & CODEGENERATIONSVC)
if your env is centrale:
look into the $FORTE_ROOT/appdist/centrale/testapp/cl0/ and subdirectories
once the pgf are generated in ./codegen/testap0 and ./codegen/testap1 the cpp files are in the platform dependant directory: (axp_osf, ibm_aix, seq_ptx, pc_nt ... ) assuming SunSol (ANSI C)
./sun_sol/testap0-1 the bom file is a file that can be fed to the compiler-linker for an automated build and the cc are the c++ files and cdf are the .h++ headers.
You don't need to have the C++ Compiler installed on the machine to get the cc files and in fact it is probably better as it'll fail and leave for sure all the generated files hanging.