mirror of
https://github.com/ganelson/inform.git
synced 2024-06-26 04:00:43 +03:00
inform7/** typos
This commit is contained in:
parent
bfe5a878c5
commit
8721f499ae
|
@ -455,7 +455,7 @@ Note that a header file called |inform7_symbols.h| is included. This defines
|
|||
useful constants like |i7_A_Take| (for the "taking" action) and |i7_I_Linear_B_tablet|
|
||||
(for the object called "Linear B tablet"). But where did this header come from?
|
||||
|
||||
The answer is that this file can ootionally be created when //inform7// is
|
||||
The answer is that this file can optionally be created when //inform7// is
|
||||
generating C. In Example 5 we ran Inform with |-format=C/no-main|; this time
|
||||
we use |-format=C/no-main/symbols-header|. This also needs a subtle change to
|
||||
the makefile logic; the difference being that |Eg6-C.o| is now dependent on
|
||||
|
@ -477,7 +477,7 @@ Eg6-I.c: Eg6.i7
|
|||
|
||||
Anyway, the result of this is:
|
||||
= (text as ConsoleText)
|
||||
Sir Arthur Evans, hero and archeologist, invites you to explore...
|
||||
Sir Arthur Evans, hero and archaeologist, invites you to explore...
|
||||
|
||||
Welcome
|
||||
An Interactive Fiction
|
||||
|
|
|
@ -22,7 +22,7 @@ Nobody who defines a literal pattern with the word "times" in can expect good
|
|||
results anyway, given that "times" will usually be interpreted as
|
||||
multiplication when Inform eventually parses such a literal.
|
||||
|
||||
@ We create new literal pattenrs during pass 1, which imposes two timing
|
||||
@ We create new literal patterns during pass 1, which imposes two timing
|
||||
constraints:
|
||||
|
||||
(a) The specification sentence must come after the sentence creating the
|
||||
|
|
|
@ -153,7 +153,7 @@ void ImperativeDefinitions::compile_first_block(void) {
|
|||
|
||||
@h The body.
|
||||
During assessment, then, each //imperative_defn// is given a body, which
|
||||
is one of these. It reoresents the body of the definition -- that is, the
|
||||
is one of these. It represents the body of the definition -- that is, the
|
||||
Inform 7 source text written underneath the heading.
|
||||
|
||||
=
|
||||
|
|
|
@ -6,11 +6,11 @@ with which the user can choose to invoke a To phrase.
|
|||
@h Introduction.
|
||||
A "phrase option" is a sort of modifier tacked on to an invocation of a
|
||||
phrase; the only modifiers allowed are those declared in that phrase's
|
||||
preamble. Phrase pptions are an early feature of Inform 7 going back to a
|
||||
preamble. Phrase options are an early feature of Inform 7 going back to a
|
||||
time when its priority was to enable the paraphrasing of Inform 6 library
|
||||
features (such as the bitmap passed as a parameter to the list-printer).
|
||||
|
||||
I now sligjtly regret the existence of phrase options, but above all the
|
||||
I now slightly regret the existence of phrase options, but above all the
|
||||
comma-based syntax used for them, as here. Brackets would have been better;
|
||||
it makes phrase options impossible to use for text substitutions.
|
||||
|
||||
|
|
|
@ -24,7 +24,7 @@ typedef struct booking {
|
|||
int placement; /* one of the |*_PLACEMENT| values above */
|
||||
int place_automatically; /* should this be inserted automatically? */
|
||||
|
||||
struct booking_commentary commentary; /* used omly for indexing and code comments */
|
||||
struct booking_commentary commentary; /* used only for indexing and code comments */
|
||||
|
||||
struct booking *next_booking; /* in its booking list */
|
||||
CLASS_DEFINITION
|
||||
|
|
|
@ -85,7 +85,7 @@ making of the new activity.
|
|||
|
||||
@h Regular meanings.
|
||||
As noted above, //Assertions::make_coupling// is called on each regular
|
||||
assertion: coupling being a lingistic term for placing subject and object into
|
||||
assertion: coupling being a linguistic term for placing subject and object into
|
||||
a relationship with each other. What it does is to split into cases according to
|
||||
the subject and object phrases of a sentence. These can take 12 different forms,
|
||||
so there are $12\times 12 = 144$ possible combinations of subject with object,
|
||||
|
|
|
@ -8,7 +8,7 @@ Setting up the use of this module.
|
|||
|
||||
@ Like all modules, this one must define a |start| and |end| function.
|
||||
|
||||
Note that the "core" plugin itself does nothihg except to be a parent to the
|
||||
Note that the "core" plugin itself does nothing except to be a parent to the
|
||||
other two; it doesn't even have an activation function.
|
||||
|
||||
@e TASK_QUEUE_DA
|
||||
|
|
|
@ -349,7 +349,7 @@ By default the story file will be called something like |story.z8|, but
|
|||
its leafname is actually declared from the source text of the Inform
|
||||
project created to do this wrapping-up. So we need a way to set as well
|
||||
as read this filename. Whatever the leafname, though, it lives in the top
|
||||
level of materuals.
|
||||
level of materials.
|
||||
|
||||
=
|
||||
int Task::wraps_existing_storyfile(void) {
|
||||
|
|
|
@ -6,7 +6,7 @@ Interface to the Problems module.
|
|||
|
||||
@d PROBLEMS_HTML_EMITTER HTML::put
|
||||
|
||||
@ In "silence-is-goldem" mode, we want our Problem messages to look more like
|
||||
@ In "silence-is-golden" mode, we want our Problem messages to look more like
|
||||
traditional Unix errors, even if they're long ones:
|
||||
|
||||
@d FORMAT_CONSOLE_PROBLEMS_CALLBACK Problems::Using::console_format
|
||||
|
|
|
@ -359,7 +359,7 @@ int PluginCalls::new_base_kind_notify(kind *K, kind *super, text_stream *d, word
|
|||
been created. For example, the figures plugin needs to know this so that it
|
||||
can see when a new illustration has been created.
|
||||
|
||||
At the time this is called, the exact kind of an instance may not be knowm,
|
||||
At the time this is called, the exact kind of an instance may not be known,
|
||||
if that instance is an object: so beware of relying on the kind unless you're
|
||||
sure you're not dealing with an object.
|
||||
|
||||
|
|
|
@ -43,7 +43,7 @@ produce Inform 6 code. That is not so: they produce Inter code, which
|
|||
can then be translated as needed.
|
||||
|
||||
Most of the definitions here also have annotations to positions in the
|
||||
main Inform dcumentation: for example, |(documented at phs_s)|. This has
|
||||
main Inform documentation: for example, |(documented at phs_s)|. This has
|
||||
no effect on the code compiled, and is used only when Inform generates
|
||||
certain problem messages; if the source text misuses the phrase, the problem
|
||||
can then give a reference to the relevant documentation. |phs_s| is a
|
||||
|
|
|
@ -638,7 +638,7 @@ To decide whether player consents
|
|||
(- YesOrNo() -).
|
||||
|
||||
@ Support for snippets, which are substrings of the player's command. This
|
||||
is a kind of value which doesm't exist in Basic Inform.
|
||||
is a kind of value which doesn't exist in Basic Inform.
|
||||
|
||||
=
|
||||
Section 2 - The player's command
|
||||
|
|
|
@ -365,7 +365,7 @@ interpretation of words like "inside" which might refer either to the
|
|||
Of the rest, N/S, NE/SW, E/W, SE/NW and U/D, it's noteworthy that this
|
||||
choice imposes a cubical grid on the world, simply because the compass
|
||||
directions are at 45 and 90 degree angles to each other: a hexagonal
|
||||
tessalation would be more faithful to distances (it would get rid of the
|
||||
tessellation would be more faithful to distances (it would get rid of the
|
||||
awkward point that a NE move is root 2 times the length of a N move),
|
||||
but in practice the world model doesn't care much about distances, another
|
||||
example of its qualitative nature. A further point is that, in a
|
||||
|
@ -659,7 +659,7 @@ than HER or IT). There has to be some convention here, and in a case where
|
|||
we don't know our linguistic ground, opting for the least surprising
|
||||
behaviour seems wisest.
|
||||
|
||||
The Inform compiler automatically applies the either-or prpperty |animate|
|
||||
The Inform compiler automatically applies the either-or property |animate|
|
||||
and the valued property |before| to a person, giving that value as just
|
||||
|NULL|. This allows any person to become the protagonist during play
|
||||
(using I6's |ChangePlayer| routine).
|
||||
|
|
|
@ -36,7 +36,7 @@ The verb to index map with in the imperative means the built-in index-map-with m
|
|||
|
||||
@h Use Options.
|
||||
In fact, many of the definitions below are handled slightly differently in
|
||||
the |srules| template files, to avoid the need for conditional compilatipn
|
||||
the |srules| template files, to avoid the need for conditional compilation
|
||||
(and thus to enable the template to be assimilated just once); but we
|
||||
continue to give them the traditional constant names, for the sake of any
|
||||
third-party extensions using these.
|
||||
|
|
|
@ -73,7 +73,7 @@ as a direction name plus "of", since "below" is not the name of the direction
|
|||
... from
|
||||
|
||||
@ Two of the directions are special to mapping, because they have to be parsed
|
||||
slighly differently. (These are the English names; there is no need to translate
|
||||
slightly differently. (These are the English names; there is no need to translate
|
||||
this to other languages.)
|
||||
|
||||
=
|
||||
|
|
|
@ -17,7 +17,7 @@ represented by //explicit_action// objects.
|
|||
(*) An "action name" -- not an ideal thing to call it, but traditional -- is the
|
||||
type of action involved, taken in isolation: for example, "taking". These can
|
||||
also be values at run-time, they have kind |K_action_name|, and they are
|
||||
represented in the comoiler by //action_name// objections.
|
||||
represented in the compiler by //action_name// objections.
|
||||
(*) An "action pattern" is a textual description which matches some actions but
|
||||
not others, and can be vague or specific: for example, "wearing or examining
|
||||
something". Action patterns become values of the kind |K_description_of_action|.
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
An exactly specified action is called "explicit".
|
||||
|
||||
@ Explicit actions are used inside the compiler whenever we kmow exactly what
|
||||
@ Explicit actions are used inside the compiler whenever we know exactly what
|
||||
action we are talking about; stored action constants are //explicit_action//
|
||||
objects in a thin wrapper -- see //Action Kinds//.
|
||||
|
||||
|
|
|
@ -205,7 +205,7 @@ to typecheck each clause.
|
|||
LOG_OUTDENT;
|
||||
}
|
||||
|
||||
@ This is where heterogenous patterns like "dropping a thing or taking a
|
||||
@ This is where heterogeneous patterns like "dropping a thing or taking a
|
||||
container" are thrown out: only the last-placed action is allowed to have
|
||||
clauses.
|
||||
|
||||
|
|
|
@ -625,7 +625,7 @@ some can never happen. For example,
|
|||
ask [someone] about [something]
|
||||
ask [someone] about [text]
|
||||
=
|
||||
have to be that way around, because any comnand which matches the first line
|
||||
have to be that way around, because any command which matches the first line
|
||||
here also matches the second. Putting these lines into order used to be part
|
||||
of the craft of the Inform 6 programmer, but it was always difficult to do,
|
||||
and Inform 7 aimed to liberate authors from the need to do this. A long
|
||||
|
@ -651,7 +651,7 @@ int CGLines::cg_line_must_precede(command_grammar *cg, cg_line *L1, cg_line *L2)
|
|||
@<Higher sort bonuses precede lower ones@>;
|
||||
@<More specific determinations precede less specific ones@>;
|
||||
@<Conditional readings precede unconditional readings@>;
|
||||
@<Lines created earlier precede lines creater later in the source text@>;
|
||||
@<Lines created earlier precede lines created later in the source text@>;
|
||||
}
|
||||
|
||||
@<Perform some sanity checks@> =
|
||||
|
@ -686,7 +686,7 @@ working through a |CG_IS_COMMAND| grammar -- it always knows how many words
|
|||
it has to match. If the player has typed TAKE FROG FROM AQUARIUM, the parser
|
||||
has to make sense of all of the words. It needs to consider the possibility
|
||||
"take [something]" before "take [something] from [something]" because there
|
||||
might be an object called "frog fram aquarium".
|
||||
might be an object called "frog from aquarium".
|
||||
|
||||
On the other hand, if it is parsing a |CG_IS_TOKEN| grammar, it is trying to
|
||||
match as many words as possible from a stream of words that will probably then
|
||||
|
@ -771,6 +771,6 @@ an object has a name like ON VISION ON -- perhaps a book about the antique
|
|||
BBC children's television programme "Vision On" -- so that the command
|
||||
TURN ON VISION ON would match both of the alternative CGLs.
|
||||
|
||||
@<Lines created earlier precede lines creater later in the source text@> =
|
||||
@<Lines created earlier precede lines created later in the source text@> =
|
||||
if (L1->allocation_id < L2->allocation_id) return TRUE;
|
||||
return FALSE;
|
||||
|
|
|
@ -209,7 +209,7 @@ parse_node *CompileValues::cast_nonconstant(parse_node *value, kind *K_wanted,
|
|||
return value;
|
||||
}
|
||||
|
||||
@ Certain kinds of value cannot be used on every virtual machine; for examole,
|
||||
@ Certain kinds of value cannot be used on every virtual machine; for example,
|
||||
the Z-machine does not support real numbers.
|
||||
|
||||
=
|
||||
|
|
|
@ -344,7 +344,7 @@ in the range |ACTOR_IS_PLAYER_CPMC <= N <= ACTOR_MATCHES_CPMC|, and so on.
|
|||
@ This is the easier case: all four ranges of condition must be true, and so
|
||||
we compile code equivalent to |ACTION and ACTOR and DETAILS and WHEN|. We
|
||||
do it in that order for two reasons: firstly, wrong actions are the commonest
|
||||
reasom actions fail to match, and the ACTION tests are quick, so it's efficient
|
||||
reason actions fail to match, and the ACTION tests are quick, so it's efficient
|
||||
to test that first. (The ACTOR tests are also quick, but usually pass.) Secondly,
|
||||
some DETAILS tests will compile non-typesafe code in cases where ACTION would
|
||||
not pass, so DETAILS must be compiled after ACTION. Finally, we put WHEN at
|
||||
|
@ -395,7 +395,7 @@ we still have to compile |true|, to ensure that every action will match.
|
|||
@ A listwise negated pattern is something like "doing something other than
|
||||
examining the box", which matches any action except "examining the box". It
|
||||
might seem that this could be negated just as the negation of the positive
|
||||
case, but that overlookz the hidden clauses about who the actor is, whether
|
||||
case, but that overlooks the hidden clauses about who the actor is, whether
|
||||
the action is a request, and so on -- the |ACTOR_CPMCRANGE| -- and any
|
||||
condition supplied -- the |WHEN_CPMCRANGE|.
|
||||
|
||||
|
|
|
@ -53,7 +53,7 @@ ordinarily a direction.)
|
|||
|
||||
@ The not-nowhere test is needed for patterns like "going from the Dining Room",
|
||||
which we want to match only where there is some destination: i.e., we don't want
|
||||
it to match an attemot to go in a direction not available in the map.
|
||||
it to match an attempt to go in a direction not available in the map.
|
||||
|
||||
@<Compile NOT_NOWHERE_CPMC test@> =
|
||||
EmitCode::inv(NE_BIP);
|
||||
|
|
|
@ -4,7 +4,7 @@ To compile Inter functions.
|
|||
|
||||
@ The code in this section is used throughout the //imperative// and //runtime//
|
||||
modules whenever an Inter function needs to be compiled. This will often not be
|
||||
a function corresponding to a definition in the soruce text; more often, it will
|
||||
a function corresponding to a definition in the source text; more often, it will
|
||||
be a support function needed to implement some feature at runtime.
|
||||
|
||||
However it happens, every function is compiled using code like so:
|
||||
|
|
|
@ -19,7 +19,7 @@ about the function currently being compiled. In particular:
|
|||
(*) what kind of value we should be returning, if anything.
|
||||
|
||||
@ Code can only be compiled "inside" a stack frame, and at any given time
|
||||
(when code is being comoiled, anyway) there is a "current" frame.
|
||||
(when code is being compiled, anyway) there is a "current" frame.
|
||||
|
||||
=
|
||||
stack_frame *current_frame = NULL;
|
||||
|
|
|
@ -7,7 +7,7 @@ As this section of code opens, we are looking at the parse tree for the body
|
|||
of a rule or phrase definition. A request has been made to compile (a version of)
|
||||
this into an Inter function; the stack frame for that has been sorted out, and
|
||||
the function begun. Now we must compile the actual code to go into the function;
|
||||
the test grpup |:invocations| exercises all of this.
|
||||
the test group |:invocations| exercises all of this.
|
||||
|
||||
Here is a typical example rule, taken from the Standard Rules:
|
||||
= (text as Inform 7)
|
||||
|
@ -21,7 +21,7 @@ Report an actor waiting (this is the standard report waiting rule):
|
|||
=
|
||||
In the parse tree, this now looks like so:
|
||||
= (text)
|
||||
IMPERATIVE_NT'report an actor waiting ( this is the standard report waitin'
|
||||
IMPERATIVE_NT'report an actor waiting ( this is the standard report waiting'
|
||||
CODE_BLOCK_NT
|
||||
CODE_BLOCK_NT
|
||||
INVOCATION_LIST_NT'if the actor is the player'
|
||||
|
@ -825,7 +825,7 @@ void CompileBlocksAndLines::verify_say_node_list(parse_node *say_node_list) {
|
|||
StandardProblems::sentence_problem(Task::syntax_tree(),
|
||||
_p_(PM_SayOverComplex),
|
||||
"this is too complex a text substitution",
|
||||
"and needs to be simplified. You might find it helful to define a new text "
|
||||
"and needs to be simplified. You might find it hel[ful to define a new text "
|
||||
"substitution of your own ('To say fiddly details: ...') and then use it "
|
||||
"in this text by including the '[fiddly details]'.");
|
||||
problem_issued = TRUE;
|
||||
|
|
|
@ -39,7 +39,7 @@ front material before compiling the block, and the back material afterwards.
|
|||
|
||||
@ The process of compiling from an inline definition is a little like
|
||||
interpreting a program, and a //csi_state// object represents the state of
|
||||
tbe (imaginary) computer doing that.
|
||||
the (imaginary) computer doing that.
|
||||
|
||||
=
|
||||
typedef struct csi_state {
|
||||
|
@ -160,7 +160,7 @@ unless a code block is opened: if it is, then they're deallocated when it ends.
|
|||
if (CSIS.my_vars[i])
|
||||
LocalVariableSlates::deallocate_I7_local(CSIS.my_vars[i]);
|
||||
|
||||
@ And tbis is what happens when the back part of the definition is finally
|
||||
@ And this is what happens when the back part of the definition is finally
|
||||
compiled.
|
||||
|
||||
=
|
||||
|
@ -179,7 +179,7 @@ the schema, and calls //CSIInline::from_source_text// on any material enclosed
|
|||
in |(+ ... +)| notation.
|
||||
|
||||
|CSIS| is passed to this function as our "opaque state" -- meaning that it is
|
||||
passed through unchanged to our callbach functions, and means that the code
|
||||
passed through unchanged to our callback functions, and means that the code
|
||||
below can share some private state variables.
|
||||
|
||||
=
|
||||
|
|
|
@ -7,7 +7,7 @@ attached.
|
|||
Either-or properties may need rather different run-time implementation from
|
||||
properties with values, but otherwise they might seem nothing special: why
|
||||
not simply regard them as properties holding truth state values? And then
|
||||
there would just be obe type of property.
|
||||
there would just be one type of property.
|
||||
|
||||
The answer is that whereas a computer-science view of the "open" property,
|
||||
say, would take exactly this line -- i.e., that it simply holds a truth
|
||||
|
|
|
@ -94,7 +94,7 @@ void KindSubjects::renew(kind *K, kind *super, wording W) {
|
|||
|
||||
@ Even base kinds which do have subjects do not necessarily allow properties
|
||||
to be given to their values -- "number", for instance, where you cannot give
|
||||
a property to the nunber 6.
|
||||
a property to the number 6.
|
||||
|
||||
In general a value can have properties if and only if its kind passes this test:
|
||||
|
||||
|
|
|
@ -40,7 +40,7 @@ are equivalent here: permission for one is always permission for the other.
|
|||
|
||||
If these were long lists, or searched often, it would be faster to move each
|
||||
found permission to the front, thus tending to move frequently-sought properties
|
||||
to the start. Pofiling shows that this would save no significant time,
|
||||
to the start. Profiling shows that this would save no significant time,
|
||||
whereas the unpredictable order might make testing Inform more annoying.
|
||||
|
||||
@d LOOP_OVER_PERMISSIONS_FOR_PROPERTY(pp, prn)
|
||||
|
|
|
@ -286,7 +286,7 @@ source text description, so that "Mr Beebe" will not be flattened to "mr
|
|||
beebe"; but that we take care to reduce the case of "Your nose" (etc.)
|
||||
to "your nose", unless it occurs in the name of a room, like "Your Bedroom".
|
||||
|
||||
If the "spatial" plugin is inactive, |this_is_a_room| is akways |FALSE|.
|
||||
If the "spatial" plugin is inactive, |this_is_a_room| is always |FALSE|.
|
||||
|
||||
@<Compose the I6 short-name as a piece of text@> =
|
||||
Naming::compose_words_to_I6_naming_text(textual_value, W, FALSE,
|
||||
|
|
|
@ -10,7 +10,7 @@ which use this module:
|
|||
|
||||
@ Like all modules, this one must define a |start| and |end| function.
|
||||
|
||||
Note that the "multimedia" plugin itself does nothihg except to be a parent
|
||||
Note that the "multimedia" plugin itself does nothing except to be a parent
|
||||
to the other three; it doesn't even have an activation function.
|
||||
|
||||
@e MULTIMEDIA_CREATIONS_DA
|
||||
|
|
|
@ -166,7 +166,7 @@ int EmitCode::cast_possible(kind *F, kind *T) {
|
|||
}
|
||||
|
||||
@ Casts are in many cases implicit, so that nothing need be done, and the
|
||||
followimg simply returns |TRUE| to indicate success. But in a few cases, a
|
||||
following simply returns |TRUE| to indicate success. But in a few cases, a
|
||||
function call must be inserted, with a name like |SNIPPET_TY_to_TEXT_TY|;
|
||||
in such cases, this function must exist in the kits somewhere.
|
||||
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
[EqualitySchemas::] Equality Schemas.
|
||||
|
||||
To define how to compile a comparisom of two values.
|
||||
To define how to compile a comparison of two values.
|
||||
|
||||
@ For most word-value kinds, it's easy to compare two values to see if they are
|
||||
equal: all we need is the |==| operator. But for pointer-value kinds, that
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
[RTSpatial::] Here, Nowhere and Everywhere.
|
||||
|
||||
Almost a Beatles song, but really a set of schemas for compilimg the meaning
|
||||
Almost a Beatles song, but really a set of schemas for compiling the meaning
|
||||
of the unary predicates here, nowhere and everywhere.
|
||||
|
||||
@ Here. In fact, at present "here" predicates are never included in propositions to
|
||||
|
|
|
@ -80,7 +80,7 @@ inter_name *RTActions::base_iname(action_name *an) {
|
|||
@ We actually want the other names to still be related to the base name even
|
||||
after a translation; i.e., if an action is translated to |Grab|, then we want
|
||||
to have the related names be |##Grab| and |GrabSub|. So translation needs to
|
||||
happen early-ish in the run, befpre tbe base iname is generated.
|
||||
happen early-ish in the run, before the base iname is generated.
|
||||
|
||||
=
|
||||
void RTActions::translate(action_name *an, wording W) {
|
||||
|
|
|
@ -424,7 +424,7 @@ void RTAdjectives::make_adjective_phrase_package(id_body *idb) {
|
|||
|
||||
@h Compiling tasks for adjectives defined by I7 or Inter code.
|
||||
First, an adjective defined by a condition written in raw Inter code can be
|
||||
tested (but not asserted) using a schema, since those are also raw Inter coce.
|
||||
tested (but not asserted) using a schema, since those are also raw Inter code.
|
||||
All we do is remove the enrobing quotation marks around the condition.
|
||||
|
||||
=
|
||||
|
|
|
@ -58,7 +58,7 @@ package_request *RTVerbs::modal_package(parse_node *where) {
|
|||
return Hierarchy::local_package_to(MVERBS_HAP, where);
|
||||
}
|
||||
|
||||
@h Compilation data for conjgations.
|
||||
@h Compilation data for conjugations.
|
||||
Each |verb_conjugation| object contains this data:
|
||||
|
||||
@d VC_COMPILATION_LINGUISTICS_CALLBACK RTVerbs::initialise_vc
|
||||
|
|
|
@ -123,7 +123,7 @@ inter_name *RTRules::shell_iname(rule *R) {
|
|||
}
|
||||
|
||||
@ Note that the response handler function must be made available to the linker,
|
||||
because the idea is that the kit function will use it. For examole, the code
|
||||
because the idea is that the kit function will use it. For example, the code
|
||||
in the kit might read like so:
|
||||
= (text as Inform 6)
|
||||
[ MY_FOREIGN_R;
|
||||
|
|
Loading…
Reference in a new issue