Hi folks,

I've started work on (trying to) re-write portions of the parser, in
hope of being able to improve performance in scenes with loops or
frequently-invoked macros (though only time will tell whether I'll just
wreck performance for linear scenes), and with a bit of luck also
improve stability.

As a first step, I'm writing a brand new _scanner_, i.e. a module that
will take a scene file and, in simplified terms, split it up into
individual "words" -- such words being (A) potential identifiers and
keywords, (B) numeric literals, (C) string literals, and (D) single- or
two-character operators and punctuation -- while at the same time
skipping over whitespace, line breaks and comments. The scanner will
also be responsible for earmarking each "word" with the line and column
where it was found.

Since I intend to subject the module to a lot of automated tests, but am
a bit short on time and imagination to conjure up those tests all by
myself, and also because some bugs might be in there because I may be
oblivious of a certain problematic scenario, I hereby present to you the
following

------------------------------------------------------------------------
CHALLENGE: CONCOCT A TEST CASE THAT WILL REVEAL AN ISSUE IN THE SCANNER.
------------------------------------------------------------------------

Notes:

- Single-line test cases are preferred. In general, the shorter a test
case is, the better.

- Since only the scanner will be tested, the test cases do not have to
make any sense syntactically. This is only about whether the parser
correctly splits the text up into "words" as explained above.

- Test cases do not even have to be well-formed. Part of the scanner's
job is to detect and report malformed input, such as a bad escape
sequence in a string or an unclosed comment.

- Besides the suggested input, test cases should also outline the
expected output.

- Speaking of comments and expected output, if your test case involves
block comments, please consider both (a) the expected result if nested
block comments are allowed (the current parser's behaviour), and (b) the
expected result if block comments do not nest (the current syntax
highlighting behaviour).

- An "issue" may be pretty much anything on the spectrum from blatant
bugs to just surprising but perfectly good behaviour.

- An "issue" may also be a case where the new scanner's behaviour is
perfectly in line with the documentation, but the existing parser's
behaviour turns out to differ. In such a case, please consider both (a)
the expected behaviour as per the documentation, as well as (b) the
observed behaviour in POV-Ray v3.7.

- By accepting this challenge, you agree that your submission /may/ end
up in POV-Ray's official repository, as part of a set of unit tests.
(For this to happen, your test case does not have to actually trigger a
bug in the current version of the scanner; after all, future changes
might accidently break things again.)

Post a reply to this message