thanks, Zarf !
Iām surprised it took me this long to go look for them, but we finally have a complete list of invocation labels with documentation.
2 Likes
Just had a whole lot of mysterious trouble (see here: Beta release of Inform App for Linux - #26 by neroden ) because of an undocumented dependency on rsync when doing make forceintegration. Rsync is not necessarily installed on an average Linux system.
The problem is buried quite deep, inside inweb/foundation_module/Chapter 1, which assumes the presence of rsync without checking.
Thereās nothing wrong with depending on rsync (itās easy enough to install on any Linux system), but it should be documented. Please add a description of the rsync dependency to the documentation for inweb, and to the build documentation for inform7.
1 Like
OK, one more āextremely painfulā issue updating to the new (- Include -) mechanism.
There are a certain number of extensions which hack the Parser. By replacing āParser Letter Hā, for example. These now apparently have to replace the entire parser to operate as extensions? Thatās going to be messy. I made a list:
Andrew Plotkin/Unified Glulx Input.i7x
Andrew Plotkin/Unicode Parser.i7x [Iām not sure if this is still needed or functional]
Daniel Stelzer/Multiple Actors.i7x
Jon Ingold/Disambiguation Control.i7x
Matt Weiner/Responsive Disambiguation for 6M62.i7x
Nathanael Nerode/Compliant Characters.i7x
Iām going to try to go through these one at a time and see whether a case should be made for integrating these changes into the standard release, so that these extensions donāt have to replace the whole parser.
(1) My miniscule change made in Compliant Characters does only one thing: it tries to not lose track of the location of the last word the parser could make sense of, so that itās possible to do better error production later in the āanswerā code:
Include (-
! ==== ==== ==== ==== ==== ==== ==== ==== ==== ====
! Compliant Characters replacement for Parser.i6t: Parser Letter H
! ==== ==== ==== ==== ==== ==== ==== ==== ==== ====
.GiveError;
etype = best_etype;
if (actor ~= player) {
if (usual_grammar_after ~= 0) {
verb_wordnum = usual_grammar_after;
jump AlmostReParse;
}
m = wn; ! Save wn (change made by Compliant Characters.i7x), using existing temporary variable
wn = verb_wordnum;
special_word = NextWord();
if (special_word == comma_word) {
special_word = NextWord();
verb_wordnum++;
}
wn = m; ! Restore wn (change made by Compliant Characters.i7x), using existing temporary variable
parser_results-->ACTION_PRES = ##Answer;
parser_results-->NO_INPS_PRES = 2;
parser_results-->INP1_PRES = actor;
parser_results-->INP2_PRES = 1; special_number1 = special_word;
actor = player;
consult_from = verb_wordnum; consult_words = num_words-consult_from+1;
rtrue;
}
-) instead of "Parser Letter H" in "Parser.i6t".This makes it possible for this code from Neutral Standard Responses, designed to find the last word which the parser understood, to work on commands with actors:
To decide which snippet is the extraneous word:
(- (((wn - 1) * 100) + 1) -).Because with the unpatched parser, this doesnāt work on commands with actors, and in fact thereās no good way to find the last word understood by the parser in a command with an actor.
This then makes it possible for Compliant Characters to do this:
Check an actor answering something (called the commandee) that when the latest parser error is the can't see any such thing error and the misunderstood word is in the dictionary (this is the command to actor includes word not in scope rule):
say "[The commandee] [can't] see anything called '[the misunderstood word]' right [now]. [as the parser]Or I misunderstood you.[no line break][as normal][line break]" (A);
restore the oops target;
rule fails;and this:
-- only understood as far as error: [UPTO_PE]
say "[as the parser]I can't understand your entire instruction to [the commandee]. The first part looked like the command '[the command understood so far]', but I didn't expect the word '[the extraneous word]' next.[as normal][line break]" (B);
-- didn't understand that number error: [NUMBER_PE]
say "[as the parser]I can't understand your entire instruction to [the commandee]. The first part looked like the command '[the command understood so far]', which I expected to include a number, but I didn't expect the word '[the extraneous word]' next.[as normal][line break]" (D);This change to the I6T parser code doesnāt change behavior for anyone who isnāt poking at wn inside an Answer action. It looks after a cursory search like nobody else in the Friends of I7 Extensions repository touches this.
Rather than replacing the entire parser in my extension in order to add two lines, I would appreciate consideration of adding the necessary change in the I6T parser file ā the hook ā into the core Inform release.
It only affects code parsed into an āAnswerā actions, and only if that code is hooking in and looking at wn, which should only be happening when reporting parsing errors to the player. It does nothing more than save wn (giving us the location of the last successfully parsed word) and restore it before returning an āAnswerā action, rather than losing track of it and leaving wn in a state which is uninteresting and redundant to other information, which is what currently happens.
This change doesnāt change behavior for anyone unless they are poking at wn inside an Answer action, which nobody else in the Extensions library does. But for anyone trying to code better error responses to things like john, put the box sdfdsfds, the change is essential.
Almost all the extensions which poke at wn are doing so to deal with āI only understood as far asā¦ā type errors or to do disambiguation, so this arguably should make it easier to adapt all of them to do their job on commands with actors.
I have finished a patch. I have rebuilt Inform, I have tested, and my Compliant Characters extension works once this patch is committed to Inform.
parser-hook.diff.txt (1.4 KB)
OK, I got my act together, cloned the repo, and submitted a pull request properly (after fixing some whitespace issues)
2 Likes
So, while working on more extension updates, I stumbled across a technical oddity, and Iām not sure if thereās a better place to ask about it. The Inform 7 WorldModelKit routines for quitting the game (QUIT_THE_GAME_R) are different in Glulx and Z-Machine, and almost certainly shouldnāt be different. I would submit a patch to synchronize them ā but Iām not sure which one is correct.
Glulx:
[ QUIT_THE_GAME_R;
if (actor ~= player) rfalse;
if ((actor == player) && (untouchable_silence == false))
QUIT_THE_GAME_RM('A');
if (YesOrNo()~=0) quit;
];Z-machine:
[ QUIT_THE_GAME_R;
if (actor ~= player) rfalse;
QUIT_THE_GAME_RM('A');
if (YesOrNo()~=0) quit;
];Iām not sure why untouchable_silence is being checked in the Glulx case ā the history of this seems to be lost in the mists of time, as I havenāt been able to trace it through āgit blameā. If I get a consensus on which version is correct Iāll submit a patch to synchronize the two versions.
It certainly looks like an incorrect intrusion into the template code. First appeared in 6L02 ā at least itās not in 6G60. There might be a fix mentioned in the 6L02 release notes, but Iāve lost track of where those are.
1 Like
Change logs in general; 6L02ās change log.
Iām not readily seeing anything related to this, but itās not hard to imagine the issue being described in a way that doesnāt hit any of the keywords I tried.
1 Like
While Iām submitting patches, Iām noticing that three separate extensions have been written to deal with the same bug in the core Inform library:
Article Bug Fix by Daniel Stelzer
Indefinite Article Substitution Fix by Matt Weiner (for Glulx only)
Print Stage Detection by Taryn Michelle
The bug is still present in the current version of the WorldModelKit. I am inclined to submit a permanent patch to fix this once and for all. The most flexible and least invasive patch is Print Stage Detection by Taryn Michelle, though Iām not sure where to move the extensive and excellent associated documentation by Taryn Michelle. However, I would welcome comments.
3 Likes
I must have been the author of this confusion, but canāt remember it at all. Looking at the code now, though, āuntouchable_silenceā simply suppresses response messages explaining that the player canāt reach through some barrier. The variable is set only temporarily and only when checking scope. I canāt imagine circumstances where QUIT_THE_GAME_R could sensibly run when this is set, and therefore the condition (untouchable_silence == false) just looks redundant to me, and should be taken out.
Maybe this was an accident with cut and paste? Anyway, the Z version looks right to me.
4 Likes
That was my guess.
Thank you Mr. Nelson. Pull request made.
1 Like
I think itās worth checking through the ā6M62 Patches.i7xā file and seeing which ones are still needed, to try to get them into v10.1 before release. On a quick check of the current Inform source code, it looks like most of them are still needed, but I havenāt gone through them all in detail (and I donāt fully understand the errors being fixed by some of them, so Iām not quite sure how to test). Any assistance would be appreciated.
3 Likes
Of the contents of 6M62 patches, I was unable to reproduce
and
in v10. They seemed to have already been fixed before the initial release.
The following had already been an old mantis bug: I7-1746 and has been fixed. (I tried it.)
The following have not yet been reported.
3 Likes
Iām feeling pretty good. I fixed the presentation of extension documentation, which has been broken since 6M62. When-and-if Graham Nelson merges it (now done), it should be all spiffy again, like it was before 6M62.
Also fixed the ability of examples in extensions to have a āby Somebodyā phrase.
This is one of the great advantages of being open source: other people can (and will) fix your bugs. These could have been fixed years ago had Inform been open-source earlier, but better late than never. Hooray for open source!
7 Likes
Just to note that Iāve pushed a change to the inform repository to incorporate everything from the ā6M62 Patchesā extension - a collection of useful fixes to misbehaving functions in (what is now) BasicInformKit. Several of these issues had already been addressed, but others had not.
Note in particular that although a different solution had already been found for the issue with rulebooks returning lists, I agreed with ā6M62 Patchesā that it was correct to use the strong kind ID and not the weak kind ID in the implementation of ārule succeedsā.
Iām hoping that this change will cause no problems for anybody; ā6M62 Patchesā should now no longer be needed.
14 Likes
ā¦And Iāve now made a small fix having missed out one change; thanks to otistdog for finding this and pointing this out.
8 Likes
Absolutely astounding. Reading your announcement was like standing in the path of some avalanche.
Thanks Mr. Nelson!
4 Likes
I just looked at what a āKitā is and Iād agree that the FyreVM Core extension would be best served as a Kit. Itās all I6 replacement code. Whoās interested in helping? The current code is here: fyrevmweb-react/extensions/David Cornelson at main Ā· ChicagoDave/fyrevmweb-react Ā· GitHub
Itās a misnomer that the repo is named ā-reactā since thatās just the implementation of a UI using fyrevm-web, but the extensions are there.
David
1 Like
There are some significant changes in the beta today for how to describe a new kit, though the functionality remains the same - you can adapt to these changes quite quickly and easily.
Not everybody will be following this now rather long thread, so Iāve started a page of brief notes about recent changes, and placed it here:
7 Likes
Thanks again for absorbing our long collection of bugfixes.
I am currently trying to figure out the best way to handle the nest of bugs related to the way the kits pick āaā or āanā for an object name, bugs for which there have been three separate extensions written over the years (Article Bug Fix, Indefinite Article Substitution Fix, and Print Stage Detection). I really would like to get this fixed properly in Core Inform.
It has become clear to me that a proper fix requires the ability to dynamically allocate a buffer in a function defined in I6, print to that buffer, and then turn the buffer into a text (all of which can be disposed of at the end of the function ā so it could be allocated on the stack).
The problems are that a proper implementation requires that PrefaceArticleBy must be reentrant, which means it cannot use a global buffer (which it currently does); and it should be able to call out to player-defined I7 code, which means I need a way to convert a buffer into text; and that it must not call PSN__ twice (which is easy enough).
At the moment I do not see how to allocate a function-local buffer on the stack or convert it to a text, though it looks like such things are being done by the internals of Inform 7 so it is perhaps possible. This is essentially bugfix material, but rather difficult bugfix material.
Any assistance would be appreciated.
Iām going to ask for some consideration regarding extending the beta status of Inform 10.1 until some more bugfixes and porting issues are resolved.
The other category of core code for which large amounts of extension material has been written to work around bugs is disambiguation. There are several of these extensions, some of which have been heavily used and used in well-known games (such as Scroll Thief), and they involve invasive parser work.
Two of these are Dismabiguation Control by Jon Ingold and Responsive Disambiguation for 6M62, both of which have to replace multiple Parser Letter sections.
These are two of only three remaining unported extensions which worked for 6M62/9.3 which replace Parser Letter sections: the other one is Unified Glulx Input by Andrew Plotkin, which seems not widely used.
One of the sections replaced in Disambiguation Control is described as āreset cobj_flags on reparsing (the library should do this anyway, I think)ā, which makes me suspect it might be a bug fix.
These are heavily-used extensions which require substantial porting. I would like the chance to figure out if thereās a way to give them better hooks in Core Inform ā because I really donāt like the idea of replacing the entire monolithic Parser routine ā and to see if elements of them are actually bugfixes which should just be pushed up into Core Inform.
3 Likes