compile version [-Z] throws error from getline

jannick0 commented 8 years ago

The simple awk script

/a/ { print "ahh" }

is well processed in the direct mode:

java -jar jawk-1.03-SNAPSHOT-stand-alone.jar -f Simple.awk input.txt

while for the compile version (-Z switch)

java -jar jawk-1.03-SNAPSHOT-stand-alone.jar -Z -f Simple.awk input.txt

throws an error. Effectively it confesses that it is a severe error.

I am not sure if this is going back to an incompatible number of arguments of the procedure org.jawk.jrt.JRT.jrtConsumeInput, but I might be completely wrong here. I checked that standalone BEGINand END blocks run through without any problem in compile mode. So rules reading from input appear to cause the issue.

hoijui commented 8 years ago

trying this on my own, i get two different errors, neither of which matches your description. ;-) looks like this is a buggy/not well tested part of JAWK. can you please give the error message you get?

~~if i don't supply an argument to the '-Z' option, i get an IOException ...~~ ... just saw that you already supplied a patch for that.. thanks! :-)

if i do supply an argument (path to a class file to be generated), i get:

Exception in thread "main" org.jawk.frontend.AwkParser$LexerException: Decimal point encountered with no values on either side. (<command-line-supplied-script>:0)
    at org.jawk.frontend.AwkParser.lexer(AwkParser.java:603)
    at org.jawk.frontend.AwkParser.SYMBOL(AwkParser.java:1417)
    at org.jawk.frontend.AwkParser.FACTOR(AwkParser.java:1322)
    at org.jawk.frontend.AwkParser.FACTOR_FOR_INCDEC(AwkParser.java:1229)
    at org.jawk.frontend.AwkParser.FACTOR_FOR_IN(AwkParser.java:1197)
    at org.jawk.frontend.AwkParser.FACTOR_FOR_GETLINE(AwkParser.java:1180)
    at org.jawk.frontend.AwkParser.TERM(AwkParser.java:1151)
    at org.jawk.frontend.AwkParser.TERM(AwkParser.java:1159)
    at org.jawk.frontend.AwkParser.TERM(AwkParser.java:1159)
    at org.jawk.frontend.AwkParser.TERM(AwkParser.java:1159)
    at org.jawk.frontend.AwkParser.TERM(AwkParser.java:1159)
    at org.jawk.frontend.AwkParser.TERM(AwkParser.java:1159)
    at org.jawk.frontend.AwkParser.EXPRESSION(AwkParser.java:1083)
    at org.jawk.frontend.AwkParser.COMPARISON_EXPRESSION(AwkParser.java:1063)
    at org.jawk.frontend.AwkParser.LE2_EXPRESSION(AwkParser.java:1043)
    at org.jawk.frontend.AwkParser.LE1_EXPRESSION(AwkParser.java:1025)
    at org.jawk.frontend.AwkParser.TERTIARY_EXPRESSION(AwkParser.java:1009)
    at org.jawk.frontend.AwkParser.CONCAT_EXPRESSION(AwkParser.java:990)
    at org.jawk.frontend.AwkParser.CONCAT_EXPRESSION(AwkParser.java:993)
    at org.jawk.frontend.AwkParser.COMMA_EXPRESSION(AwkParser.java:970)
    at org.jawk.frontend.AwkParser.ASSIGNMENT_EXPRESSION(AwkParser.java:950)
    at org.jawk.frontend.AwkParser.RULE(AwkParser.java:875)
    at org.jawk.frontend.AwkParser.RULE_LIST(AwkParser.java:796)
    at org.jawk.frontend.AwkParser.SCRIPT(AwkParser.java:779)
    at org.jawk.frontend.AwkParser.parse(AwkParser.java:337)
    at org.jawk.Awk.invoke(Awk.java:149)
    at org.jawk.Main.invoke(Main.java:113)
    at org.jawk.Main.main(Main.java:85)

jannick0 commented 8 years ago

Right, patch #5 remedies the dot issue.

The -z switch compiles a byte-coded version AwkScript.class of the awk script

public class AwkScript implements VariableManager

including the method

public final int ScriptMain(final AwkParameters parameters)

as described in the explanatory comment of AwkCompilerImpl.java.

Here what I can see so far: The changes of 3c54af0 were not pushed through to the structure of AwkScript.class dynamically generated upon -z, such as the argument change from parameters to settings and the signature change of org.jawk.jrt.JRT.jrtConsumeInput. This implies that AwkScript.class causes an error when ScriptMain is called due to a syntax error. Given 3c54af0 the required changes to AwkScript.class would have to be coded in stone in the Java code stack language thru BCEL. I think I am saying that if the above is true then 3c54af0 makes -z useless ... but I might be far off here, of course.

hoijui commented 8 years ago

soo.. you get the same exception i do? i just tested with the commit before the one you mention (parameters -> settings change), and i get the same exception. ... and same with the initial commit of the repo. in other words.. though you might very well be true that this commit you mention causes bugs in the compiled AWK script part, this problem i am seeing was there before already.

jannick0 commented 8 years ago

I am not sure if I am fully following:

First of, I am living on a Windows system which might be a reason for different jawk behaviours.
Using the Jan 18, 2008, sfnet version jawk 1.02 I am able to run -z out of the box without any issues.
Since the first commit bf7dbb901354c1171e3dcdff7247269972ef89b7 is syntactically identical to the sfnet version - as you say in the comment of the initial commit - , this should work, too. I just compiled and checked ... just to be more than sure.
I am trapped by the same error you copied above when running the current repo version. The proposed patch #5 should help. As far as I can see this code snip was touched in 2992950752bba6b1263c8724eb17f89dc2310bc6. Or do you still face an error after incl. #5?

Honestly speaking, it would be great if the compile mode could be reactivated. Probably an option to revisit 3c54af0 and to try to find another implementation keeping the compile infrastructure untouched? What would be your thoughts and / or preference?

jannick0 commented 8 years ago

I just happened to produce the error you copied above, after I have simply forgotten the -f switch in

[jawk 1.02] java org.jawk.Awk -z -f Simple.awk

which runs like a charm here when -f is provided. Does this help you, too?

hoijui / Jawk

compile version [-Z] throws error from getline #6