verify the correct execution of *every* possible parsing error

[amyjko]

The process for this should be to go through each possible parsing error, as enumerated in text.js, and produce a program that produces the error. We want to confirm that there aren't any errors in any of these cases.

[mjslee]

Added control text for all parsing errors. Will continue by writing individual levels that each produce one of the parsing errors (stored separately from our main levels.js) for verification.

[mjslee]

I have gone through each parser error to make sure they were working and being caught correctly. I've made a new 'level_parserErrors.js' file that I used to test.

I encountered the following problems. I could not successfully test the:

1. 'modify' command (test level 16) - I believe it is an internal command that other things can use, but not Gidget.
2. 'and' predicate (test level 19) - I believe this is a goal command and not something Gidget uses directly.
3. missing 'QUERY' name (test level 21) - I couldn't figure out how to get this error to show up.
4. missing 'ON' (test level 22) - "gidget on" produces the expected error message. However, "on gidget" results in an infinite loop in ui.js:1010 (TypeError: Result of expression 'message' [undefined] is not an object.) (New bug When checking goals with 'on,' not including a 'name' before it causes an infinite loop.  #102 filed for this.)

Additional comments:

1. If the parser detects an error in the gCode, the error sound is played at the beginning of the step sequence (i.e. prematurely) due to the way it parses the code. (new bug Parser error sounds play prematurely when executing gCode. #103 filed for this).
2. Textual error messages are displayed as expected by Gidget stepping through the gCode. However, parser errors when evaluating goals are not shown (this is probably the expected behavior for our study since only we will have access to the goal code).

[amyjko]

Do you think it's worth filing bugs on (1), (2), and (3)? Additional comment (2) is probably appropriate behavior, but it's also worth filing for later when we write a level editor.

[mjslee]

The first list of 3 were not bugs per-se, but were results of my not knowing exactly how to write gCode or goalCode to produce call those particular functions.

I'll file another bug (for later) about the the goal evaluation communication (filed as #105)

[amyjko]

The learners won't know exactly how to write gCode either, right? Or goal code? There should be appropriate error messages for those, especially for later when you write a level editor.

[mjslee]

Verified and closed.