Debug -> Analyze (documentation)

Started by jmburton2001, May 04, 2018, 12:18:58 PM

Previous topic - Next topic

jmburton2001

Is there a listing for error codes somewhere? I've been searching the help files and tech database but I'm not finding them.

I was using the "Analyze" option and received the following errors in a simple script even though the statements process properly and it returns the correct info.

D:\Log Diagnostic.wbt (543, 84): error 5008: Variable name to long
D:\Log Diagnostic.wbt (543, 21): error 5041: Operand or expression expected
D:\Log Diagnostic.wbt (543, 21): error 5019: Comma or closing parenthesis expected
D:\Log Diagnostic.wbt (543, 88): error 5003: Unexpected item found on line

The variables are pulled from a dialog named "SysInfo"


SysInfo005=`042,169,034,022,DROPLISTBOX,"DropListBox_2",dlVariable2,"1",DEFAULT,70,4,DEFAULT,DEFAULT,DEFAULT`
SysInfo006=`078,169,033,022,DROPLISTBOX,"DropListBox_3",dlVariable3,"1",DEFAULT,80,4,DEFAULT,DEFAULT,DEFAULT`
SysInfo007=`007,169,032,022,DROPLISTBOX,"DropListBox_1",dlVariable1,"2018",DEFAULT,60,DEFAULT,DEFAULT,DEFAULT,DEFAULT`


These are the lines that lead up to and include the error(s) from the analyzer. (I added lines 544 and 545 after receiving the Analyzer errors even though the script doesn't produce any errors either running or debugging.)


540 - FileWrite (Capture, "User year = %dlVariable1%")
541 - FileWrite (Capture, "User day = %dlVariable2%")
542 - FileWrite (Capture, "User month = %dlVariable3%")
543 - FileWrite (Capture, "System equivalent date = %dlVariable1%:%dlVariable3%:%dlVariable2%:00:00:00")
544 - UserDate = StrCat (dlVariable1, ":", dlVariable3, ":", dlVariable2)
545 - FileWrite (Capture, "System equivalent date = %UserDate%:00:00:00")


Line 543 throws multiple errors in the analyzer even though the syntax is correct "FileWrite(filehandle,"some data")" and produces the desired output without error. If I concatenate the dlvariables into another variable and then substitute it, then there are no errors for line 545 even though they're essentially the same.

5008 - Is there a limit to the number of variable substitutions in a Message, AskYesNo, FileWrite, etc?
5041 - What operand or expression is it expecting?
5019 - Where would it expect commas or parentheses?
5003 - What's unexpected on that line?

I'm thinking that line 543 is acceptable, but lines 544 + 545 are considered optimal? Can I safely ignore the errors for line 543?

td

The Syntax Analyzer is a parser and not an interpreter.  Therefore, the Analyzer has absolutely no idea what the contents of variables are.  If you rely heavily on substitution, the Analyzer has limited usefulness.

From the 2018a release notes:

         A few things to remember when using the Syntax Analyzer:
          Variable values are not checked because the script is not executed.
          The Analyzer cannot determine the resulting syntax of substituted variables.
   
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

td

Here is some text we have added to the Compiler help file for the next release that may (hopefully) explain things in a better fashion:

The Syntax Analyze does not determine the contents of script variables.  This means
that the Analyzer does not perform substitution and cannot accurately determine the
syntax of lines containing substitution. This can cause the Analyzer to identify errors
in substitution lines that are correct when the substitution is performed by the
WIL interpreter.   
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

jmburton2001

Thank you for the information on the variable analysis. I've ran the analyzer on some other scripts I've written over the years and it appears that once the analyzer finds "error 5008: Variable name to long" it's followed by these errors:

  • error 5041: Operand or expression expected
  • error 5019: Comma or closing parenthesis expected
  • error 5003: Unexpected item found on line
Initially I thought these errors might be suspect and spent the time trying to figure out what operands, expressions, commas, parentheses, or unexpected item was found. I could never find any of these items (at or around the column reference) that would cause an error in the syntax or hinder the proper processing of the line.

Are these errors "standard" followups when encountering error 5008?

td

There is a whole branch of computer science devoted to language parser theory and practice.   Much of it based on the early works of the linguist Norm Chomsky.  The WIL Syntax Analyzer is based on compsci language parser theory (no need to rediscover the wheel) and any detailed discussion of the inner workings of the analyzer is probably beyond the scope of this forum.

That said, the analyzer is an LL(2) deterministic automation that does not halt the tokenization process on error.   This means that one error can lead to a cascading set of errors on a given line or on more than one line when the error involves a "structure" statement.  Anyone that uses a conventional machine language compiler is very likely already familiar with this behavior and likely knows how to handle cascading error messages.   A classic example is forgetting an opening brace ({) in C++ source and then compiling with the MSFT C++ compiler.  This "sin" often results in 100 or more compiler error messages which can all be addressed with the addition of a single character - the "{".

The best way to handle multiple errors on a line is to pay attention to the first one, that is, the one with the lowest column number for a line and not the one that appears first.  Often correcting that error will make the other errors go away.  If it doesn't, you simply address the next error.  If you know enough about WIL syntax, you can probably understand how all the cascading errors come about.   It is an interesting exercise but, otherwise, not a necessary nor productive use of time.

To put it another way, the skill lies not in noticing the details but in the ability to determine which details are most important.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

jmburton2001

Quote from: td on May 09, 2018, 10:05:41 AMIf you know enough about WIL syntax, you can probably understand how all the cascading errors come about.

I think you nailed it right there. I'm not a programmer, just a pencil pusher, and the only language I've ever worked in (sporadically) is Winbatch. I chose it because I'm "somewhat" familiar with it and have no desire to learn another language when this does what I need.

That's probably why the questions I ask could be considered simple... I'm ignorant and trying to increase my understanding.

I sincerely appreciate and thank you for your assistance in that regard.

td

We did take a look at your "5008: Variable name to long".  Besides noticing that the "to" was missing an "o", it did seem a bit out of place even for a line containing substitution.  As it turned out there was a bug in the way the analyzer handles multiple substitutions in a string literal.  It will be fixed in the next release.  So asking questions simple or otherwise can be a good thing.

Note that this bug does not detract in any way from the previous discussion regarding the analyzer's ability to handle substitution nor cascading errors.  It just happened that the cause was something else in this case. 
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

td

Consider the following line that contains a substitution variable name that is actually too long and produces the same set of errors.

Code (winbatch) Select
FileWrite (Capture, "System equivalent date = %dlVariable1dlVariable3dlVariable2%:00:00:00")


or these two lines the produce an analyzer error but are syntactically correct to the interpreter.

Code (winbatch) Select
strEnd = ' end quote"'
strTest = "start quote%strEnd%
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade