Slitherine

# excludes.pl - AGElint chk*.pl excludes routines                               

open(EXCLUDES, "$EXCLUDES");
while(<EXCLUDES>) {
    chomp;
    next if (/^\s*#/);
    $thing = $_;
    print "$thing\n" if $DEBUG;
    if ($thing =~ /^\(.+\)$/) {
        $EXCLPAT = $thing;
    } else {
        $excludes{"./$thing"}++;
    }
}
close(EXCLUDES);

...

1;  # required!

    if ($excludes{$file}) {
        print "skipping $file\n" if $DEBUG;
        next;
    }

    if ($EXCLPAT && ($file =~ /($EXCLPAT)/)) {
        print "skipping $file\n" if $DEBUG;
        next;
    }

• ...
  
• Better pinpoint the exact line number of reported error.
  
• Improve parser 'error' recovery, for detecting all errors etc. in a given data file.
  
• ...
  

• Better describe errors (and not so readily default to the generic, often uninformative "syntax error").
  

cond:             conditions { txterrmsg(_ERROR, FALSE, lineno, "duplicate Conditions statement"); }

                | actordisabled
                | actorenabled
...
                | selunqunit
                | turnindex

		| altercusubunit { txterrmsg(_WARNING, TRUE, linenorhs, "suspicious, unusual use of %s in Conditions section", "AlterCuSubUnit"); }
...

                ;

act:              actions { txterrmsg(_ERROR, FALSE, lineno, "duplicate Actions statement"); }

                | absorbfaction
                | addnationalregions
...
		| winparams
                | winparamsvp

                | probability { txterrmsg(_WARNING, TRUE, linenorhs, "suspicious, unusual use of %s in Actions section", "Probability"); }
...

                ;

quote:

ORIGINAL: berto

Still more:

If you are a C (or Java or Perl or ...) programmer, you see this parser "confusion" effect if, for instance, you omit a required ; or } or some other "little" thing.

Then, when the program compiles (or runs), you see a spew of compiler errors filling your monitor screen. And maybe not also errors due to later-on coding mistakes.

You go back and fix the "little" mistake, and the thing then compiles cleanly (or reveals the earlier masked errors).

So you see, even the best of the C (and Java and Perl and ...) compilers can get confused. Again, it's an inherent limitation to the available parsing technology. Parser confusion -- can't help it!

#!/usr/bin/perl                                                                 

require "common.pl";

# register all localisations in the %locals hash                                
open(LOCALS, "cd \"$GAMEDIR\"; find -name \\*.csv -exec cut --delimiter=\\; -f 1 {} \\; | egrep -v \"^//\" | egrep \"[a-zA-Z]\" | sort | uniq |");
while (<LOCALS>) {
    chomp;
    $local = $_;
    print "LOC1 #$local#\n" if $DEBUG;
    if ($local =~ /^\s*(\S.+\S)\s*$/) {  # strip leading/trailing whitespace    
        $local = $1;
        print "LOC2 #$local#\n" if $DEBUG;
        # now convert to all lower case                                         
        $local = lc($local);
        print "LOC3 #$local#\n" if $DEBUG;
        $locals{$local}++;
    }
}
close(LOCALS);

open(LOCALS, "cd \"$GAMEDIR\"; find -name \\*.csv -exec cut --delimiter=\\; -f 1 {} \\; | egrep -v \"^//\" | egrep \"[a-zA-Z]\" | sort | uniq |")

/*                                                                              
   agelint.h -- AGElint common header file for all binaries                        
                                                                                
 */

gcc -O2 -Wall -Wshadow -Wconversion -Wpointer-arith -Wcast-qual -c agelint.c -o agelint.o
In file included from agelint.c:6:0:
agelint.h:2:11: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘.’ token
In file included from agelint.h:10:0,
                 from agelint.c:6:
/usr/include/sys/types.h:34:18: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘u_char’
agelint.c: In function ‘checkcfg’:
agelint.c: In function ‘init’:
agelint.c: In function ‘getroot’:
agelint.c: In function ‘date2days’:
make[1]: *** [agelint.o] Error 1
make[1]: Leaving directory `/home/berto/games/ageod/agelint'

quote:

ORIGINAL: berto


Action statements appearing in the Conditions section -- one way to handle this "problem" (?) is by giving warnings:

---

cond:             conditions { txterrmsg(_ERROR, FALSE, lineno, "duplicate Conditions statement"); }

                | actordisabled
                | actorenabled
...
                | selunqunit
                | turnindex

		| altercusubunit { txterrmsg(_WARNING, TRUE, linenorhs, "suspicious, unusual use of %s in Conditions section", "AlterCuSubUnit"); }
...

                ;

---

And similarly for condition statements appearing in the Actions section:

---

act:              actions { txterrmsg(_ERROR, FALSE, lineno, "duplicate Actions statement"); }

                | absorbfaction
                | addnationalregions
...
		| winparams
                | winparamsvp

                | probability { txterrmsg(_WARNING, TRUE, linenorhs, "suspicious, unusual use of %s in Actions section", "Probability"); }
...

                ;

---

By giving explicit warning messages, we avoid the more generic, and possibly confusing, "syntax error" messages.

Chliperic, I genuinely, really, truly appreciate your open-mindedness, cooperativeness, and patience. And your feedback.

As with most things in life, you get one chance to make your impression. With many people, you don't get a second chance.

As I develop AGElint and promote its use, I try to understand the, at best, indifference and, at worst, hostility it sometimes engenders.

I suspect that some people are looking for excuses to write me off, seizing for example the issue of false positives to disparage AGElint. They see false positives, and think: "Berto is a doofus. He doesn't know what he's doing. AGElint sucks." I think: "No, I know what I'm doing, in large part. I just need to do a better job of clarifying the AGElint error/warning statements [among other refinements, improvements, and bug fixes]."

That's what I suspect, anyway.

quote:

ORIGINAL: berto

Another thing I need to do is to have fewer "syntax error:" and more "warning:" and/or use more 'txterrmsg(_ERROR, ..., <explicit error message> ...)' function calls.

setcontrol:       _SETCONTROL eq pct
                | _SETCONTROL eq alsval sc pct
                | _SETCONTROL eq alsval pct { txterrmsg(_ERROR, TRUE, linenorhs, "missing ; field separator"); }
                | _SETCONTROL eq alsval { txterrmsg(_ERROR, TRUE, linenorhs, "missing ; field separator, else missing value"); }
                {
                /*
                http://www.ageod.net/agewiki/SetControl
                Syntax:  SetControl = [RegionUID;]Value
                */
                }
                ;

aisetparams:      _AISETPARAMS eq anynamnoscintsclist
                | _AISETPARAMS eq namintsclist { txterrmsg(_WARNING, TRUE, linenorhs, "suspicious, undocumented use of ; separating Param from Value", "turnindex"); }
                {
                /*
                http://www.ageod.net/agewiki/AI.SetParams
                Syntax:  AI.SetParams = <Param1 Value1> [;<Param2 Value 2>] [;<Param3 Value 3>] ...
                */
                }
                ;

SelectFaction{W}*={W}*$?{C}{DC}{2}/{nDC} {
                          ECHO;
                          if (! strchr(yytext, '$')) {
                            txterrmsg(_ERROR, TRUE, lineno, "missing $ before FAC name");
                          }
                          FREE(factionselect);
                          factionselect = strdup(yytext+yyleng-3);
                          DECHO("FACTIONSELECT");
                          if (islist_selects) {
                            fprintf(stdout, "%s:%d:%s\n", txtfile, lineno, yytext);
                          }
                        /* the arbitrarily placed SelectFaction wreaks havoc
                           with the grammar, so we "cheat" by not returning
                           it to the parser
                         */
        	        /* RETURNCMD(_SELECTFACTION); */
        	        }

quote:

ORIGINAL: berto


Another puzzler...

AI.SetParams

shows

---

Syntax

AI.SetParams = <Param1 Value1> [;<Param2 Value 2>] [;<Param3 Value 3>] ...

---

but actual usage shows

---

[root@berto agelint]# ./kwddat AI.SetParams
1 AI.SetParams = aiLRV_HarborValCoef 90;aiLRV_RailVal 20;aiLRV_DestRailVal 13
1 AI.SetParams = aiLRV_HarborValCoef;90;aiLRV_RailVal ;20;aiLRV_DestRailVal;13
6 AI.SetParams = aiLRV_HarborValCoef 80;aiLRV_RailVal 20;aiLRV_DestRailVal 13
7 AI.SetParams = aiLRV_HarborValCoef;80;aiLRV_RailVal ;20;aiLRV_DestRailVal;13

---

that is, a ; semi-colon separating the Param from Value.

Do I decide that the AGEWiki is authoritative and accurate? Or do I decide that the actual usage is authoritative and accurate? For now, I have decided in favor of the former. In either case, one usage or the other would generate a warning, and invite closer inspection.

So, I am handling this discrepancy between the AGEWiki docs and actual usage in this way:

---

aisetparams:      _AISETPARAMS eq anynamnoscintsclist
                | _AISETPARAMS eq namintsclist { txterrmsg(_WARNING, TRUE, linenorhs, "suspicious, undocumented use of ; separating Param from Value", "turnindex"); }
                {
                /*
                http://www.ageod.net/agewiki/AI.SetParams
                Syntax:  AI.SetParams = <Param1 Value1> [;<Param2 Value 2>] [;<Param3 Value 3>] ...
                */
                }
                ;

---

And so it goes...

quote:

ORIGINAL: Chliperic

err...I will not comment the AI events in PON, BOA2. ROP 1.03 has a very basic intuition of I developped later, it was my first real try. For AACW, there are almost absent, as far I know. Let's say AACW is showing what the generic AI may do.

RUS AI events are mine. FY AI events are yet more polished and improved. There are certainly between 700 and 1,000 AI events.

SVF should need much less, with only 2 factions.

• Removing genericalness from the txt.y parser.
  
• Better describing errors, and not so readily defaulting to the generic, often uninformative "syntax error".