Run Glulxercise test suite #61
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was a serious regression in e385ce1 in that the parser would never understand any input because it still had a newline appended to it!
We'll run these in an automated fashion in the future, since Zarf has written scripts for them for checking the output.
Original location: https://github.com/erkyrath/glk-dev/tree/master/unittests Remove the Z5 tests which are mostly duplicates. (We don't need to test the interpreters' implementations, we want to test the Glk library using the Glulxe reference implementation.) Also add the Regtest scripts that go along with each test, in order to run these as part of automation. (Don't include any tests that don't have a Regtest script.)
This runs the entire set of Zarf's Glulxercise tests, along with their corresponding Regtest scripts, during 'meson test'. We add a runner program which takes care of instantiating a ChimaraIF widget in a GTK offscreen window, parsing the Regtest script, and performing the requested checks. Some of the checks are not currently possible (like checking graphics output, or synthesizing hyperlink input.)
Previously the UI message would be freed at the end of ui_message_perform in the UI thread, but then the response would still be read out of it in the Glk thread. This would usually happen to work, but would occasionally cause crashes or hangs. Instead, set a flag in the UI message when it is being awaited so that we don't free it until the response has been received in the Glk thread.
Without this, a game that prints banner text and immediately exits, will never fire the 'command' signal to be able to print the banner text to a transcript.
When the Glk program exits with any windows open, the library waits for one final keypress in order to ensure that any text printed just before exiting remains visible. However, if not in interactive mode, don't do this; it gets in the way of transcripting.
There were a few things wrong with reusing the queues for subsequent Glk program runs: a memory leak when emptying the line input queue, an invalid free for the char input queue, and a race condition where input from the previous program run might end up being queued in the next run. In order to make things simpler, just don't reuse these queues; destroy and recreate them for each Glk program run.
It happened that a window could have handled the line input event on the UI thread before glk_select() was called, and so the type of its pending input request would be NONE by the time glk_select() needed to figure out whether to release the buffer as a char buffer or unicode buffer. This could cause the dispatch unregister callback to be called with the wrong buffer. So, put a new flag in the window struct, to indicate whether the last line input request was unicode or not. This is a hacky solution; it would be better if the event struct itself could indicate the type of the line input request.
This was a late addition to the 0.7.4 Glk spec, which we hadn't yet adopted. Pull in the change from CheapGlk, and add a test case for it. The test case requires loading a resource file in the unit tests, so add some machinery for that as well.
Because of signalling NaNs, we can't count on glibc's powf() function to implement the Glulx-specified pow opcode correctly. For now, use the safer wrapper. See: erkyrath/glulxe#31
Fixes a long-standing bug with glk_buffer_to_title_case_uni() where the results would be incorrect for characters that expand into more than one character in titlecase. We hardcode a list of titlecase exceptions from Unicode, and otherwise continue to use the GLib 1-to-1 mapping from g_unichar_totitle(). Closes: #28
We would previously check the window to see if the input request was for a unicode character, after cancelling the input request; so there was a race condition where the input request type might end up being NONE, meaning that we could not generate a character input event for a non-Latin1 key.
We would previously log a warning here, but looking up a nonexistent resource number to see if it exists is a perfectly legal thing for a Glk program to do. Now the tests should pass without logging any warnings or criticals.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Zarf has published automation scripts for the Glulxercise test suite over at https://github.com/erkyrath/glk-dev/tree/master/unittests/regtests. We can use these scripts to get better automated test coverage for the Glk library.
The rest of the commits are fixes for things that caused tests to fail. (Including fixing a long-standing bug with
glk_buffer_to_title_case_uni(), #28.) We should have a clean baseline now so that future changes don't cause any regressions.Well, almost clean. The test runs on CI seem a bit flaky. My next PR after I merge this will be to get them clean under the address sanitizer.