I am soliciting feedback on a new version of Glulx Entry Points. This new version makes three main changes:
Older versions of GEP have placed the basic event-dispatching logic in a long, switch-statement based I6 routine, HandleGlkEvent(). The new version puts all of that logic into a short I7 phrase. This is made possible by exposing the event type constants as a kind of value.
With the event types exposed as a kind of value, it is no longer necessary to have eight different event-handling rulebooks with hard-to-remember names such as the “glulx timed activity rules” or the “glulx arranging rules”. Instead, we have a single rulebook parameterized on the event type value, e.g. “glulx input handling rule for a timer-event” or “glulx input handling rule for an arrange-event”. This also makes it possible to write rules that would fire for all types of input, or only for a certain set of input types. The older eight rulebooks are retained for compatibility with existing extensions, but are effectively deprecated (and can be disabled entirely via use option if they are not needed).
The input context passed by the Inform library is now made accessible to the author (older versions of GEP ignored this parameter): thus, we can now test whether an event occurred while the library was waiting for line input or for character input.
I have added some useful wrappers as well, including phrases to query which window an event was received in, to identify the type of event received (e.g., timer, hyperlink, etc.) at any time during handling, and others. There are also I7 phrase wrappers for calling the PrintPrompt() and DrawStatusLine() routines, both of which folks working with extended I/O often need to trigger manually.
If you’ve written Glulx extensions or know anything about Glulx, I would greatly appreciate any comments you might have! Glulx Entry Points is a built-in extension, which means that it should be well vetted before it’s released!
Oh, and if you have a Glulx project in the works that uses Glulx Entry Points under the hood (most Glulx extensions, e.g. Flexible Windows, use GEP), could you try including this to see whether it works seamlessly? The process is simple:
Remove the “Candidate” from the filename if necessary, so that it is called “Glulx Entry Points.i7x”.
Install it in Inform 7 in the standard way. The built-in extension will not be overwritten; instead this version will be placed in your user extensions folder, and will be preferred over the built-in version. You can delete the new version from your user folder whenever you like.
Looks nice! Just one wrinkle: HandleGlkEvent ignores the ev parameter, which leads to unexpected behavior when ev isn’t gg_event. (I know that this doesn’t happen very often, but sometimes it’s nice not to clobber Inform’s structure.) Could GEP save ev in a global and then refer to that instead of gg_event?
(Ooh, and feature request: could it also @push and @pull evGlobal, evGlobal–>0, …, and evGlobal–>3 so that HandleGlkEvent is reentrant?)
Thanks for taking a look! This is a good idea, and in the spirit of also recovering the context parameter for folks to use. I will definitely do this.
I’m sorry, but I’m not smart enough to get exactly what this would mean . We’re basically caching the event info before processing, and then restoring afterward, correct? Meaning that we can change/override the event info during handling but restore it afterward so that the author can refer to the original event after handling, even if we’ve overwritten the parameters during handling?
[ HandleGlkEvent ev context abortres newcmd cmdlen ;
evGlobal = ev;
@push evGlobal; !etc.
(+ library input context +) = context;
ret = (+ value returned by glk event handling +) ;
@pull evGlobal; !etc.
return ret;
];
What path are you thinking of where HandleGlkEvent could be called recursively? An event handler which calls YesOrNo()? Surely that would run into all sorts of other non-reentrant library code…?
Zarf: Yeah, that’s the kind of thing I was thinking of. The only other non-reentrancy I see is in regards to buffer, parse, etc., which wouldn’t matter most of the time, but I might well be missing something.
Erik: Right, you understood correctly, though the pushes ought to be before ev is stored in the global. That way, if an event-handling rule ends up calling glk_select/HandleGlkEvent for I/O of its own, the original event is still available afterwards.
Of course, such a rule could save and restore the event on its own, and nobody has complained before. I was just thinking it would be nice if it the process was automatic.
. We’re basically caching the event info before processing, and then restoring afterward, correct? Meaning that we can change/override the event info during handling but restore it afterward so that the author can refer to the original event after handling, even if we’ve overwritten the parameters during handling?