Inform library 6/8 released
Graham Nelson
Inform Library 6/8 now released
===============================
It has been a rather long time coming, but library 6/8 is now
available, at least for testing purposes. I am fairly confident
that it is more reliable than 6/7, but until it has been tested
for a couple of weeks, you may wish to wait before upgrading.
Note that this is not the very hasty library release which I
made to go with the new beta-release of the compiler, 6.20:
this one is Library 6/8, serial number 981213.
This was very much a maintenance release. About 80 bug reports
have been submitted over the last year, reporting something like
thirty different bugs, and I've fixed everything I could
reproduce, which is almost everything. The changes are cited
below in the usual way.
At present the files are, not very conveniently, in the Zip
archive
Ilib68.zip
in the directory incoming/if-archive at ftp.gmd.de; and the eight
files included will probably need renaming to have ".h" on the
end if you use an operating system with file extensions.
It might be useful to clarify the status of Inform 6.20 at this
point. Basically... it has a nice new feature, but it's very much
a beta release at present, undergoing testing. We're already up
to patch level "a". As soon as I think it looks clean enough,
there'll be a proper release of Inform 6.21: in the mean time, by
all means play with 6.20, but perhaps you might not want to
actually publish a story file it produces.
Graham Nelson
13 December 1998
-----------------------------------------------------------------------------
261. The "score" text now describes "0 turns" correctly (for the
benefit of games which set the turn counter to 0 because they
don't wish to begin on turn 1).
262. The banner now prints "S" if the game is compiled with strict error
checking.
263. A new debugging verb, "changes", traces changes in the object
state -- moves, removes, attribute and property alterations. (This
only works in games compiled with strict error checking, which
in turn only works with Inform 6.20 or later.)
264. Numerous small parser bugs or infelicities, which violated the
strict error-checking alluded to above, have been removed. In
particular this caused "vile zero errors from hell" on three
occasions: if typing "say to me"; in some circumstances of darkness;
and, albeit quite rarely, when listing some plural groups of object
names.
265. The scope for debugging verbs like "purloin" now no longer includes
classes or uncreated objects. The "tree" listing similarly omits
these.
266. Using "Constant MANUAL_PRONOUNS" no longer results in a compilatiom
warning about an unused variable in "InvSub".
267. The command "me, again" no longer sends the parser into an infinite
recursion.
268. Light no longer shines out of an object with the following combination
of attributes: enterable, container, not open, not transparent.
(Thanks to Paul Mikell for fixing this.)
269. The maximum number of words parsed on a line of input is now 15.
It was previously in theory 64, but in practice this caused some
buffers to be overwritten.
270. The Transfer action no longer tries to Drop items unless the
second noun given is "the floor". Instead, it defaults to Insert
unless the second noun is a supporter, in which case to PutOn.
271. The Empty action, for emptying one container into another, takes
greater care to check that circumstances don't intervene (if the
individual transfers make things happen). Also, you can now
"empty" containers onto supporters (say, onto a table); and a
new message, ##EmptyT 4, has been added to take care of the case
when a player asks to empty something into itself.
272. You now can't enter a visible but inaccessible enterable object
(say, a hole which is visible inside a locked glass cabinet).
273. The rules on edible clothing are now properly toughened up, or
I'll eat my hat. In particular an attempt to Eat a worn item of
clothing results in a Disrobe action first. The same applies to
the ThrowAt action.
274. If the player gets into an opaque container and closes the lid
so that the world outside is invisible, the status line no longer
prints the current location, but instead the outermost visible
container. This matches what "look" would print up.
275. New games now start by printing a new-line, just in case the cursor
begins on the top line of the screen (as it sometimes does) and
then the game prints text on that line; which subsequently gets
hidden beneath the status line.
276. It's now possible to change "MAX_TIMERS", the maximum number of
timers or daemons active at any one time, as claimed in chapter 18
of the Designer's Manual.
277. When several objects have "each_turn" routines and one of these
moves the object elsewhere, the sequence of events is now correct.
(Previously it was possible for things from the "elsewhere" room
to take place in the original room, thanks to an oversight.)
278. A tiny bug causing an array bound to be overstepped when scanning
the table of descriptors for the current language has been removed.
(With thanks to Anson Turner for spotting the possibility in the
coding; this bug has never manifested itself in play.)
279. The code handling the final "restore, restart, quit" option has
been moved to its own routine in the parser, to suit anyone who
needs to "Replace" it for some nefarious purpose.
280. Library message ##Remove, 1 has had a double-space removed.
281. The parser error "There are only (however many) available" now
gets the right number of however many it is. (This happens if you
try to take seven out of a pile of five apples, for instance.)
282. Several small bugs have been removed from the parser's disambiguation
code, and the trace-level-4 output showing the process happening has
been made a little more comprehensible. In particular two different
bugs to do with identical objects (spotted by Todd Lair and Brent
VanFossen respectively) have been taken out. Furthermore, problems
with "take X and Y" not properly working where X and Y belong to
different parents (e.g. one on the floor, one on a table) should now
abate, thanks to a suggested improvement by Graham Fyffe.
283. Two bugs have been removed from the library's "note arrival"
routines. Recall that noting arrival means calling the new location's
"initial" routine, and calling the entry point routine "NewRoom" if
the designer has provided one. The principle is that this should
happen whenever the player enters or is taken to a new and non-dark
location, or when light is restored to a previously-dark location.
284. The list-writer was previously unable to cope with recursive listed-
together groups of objects: e.g., a listed-together set of Hanoi disks
on a listed-together set of Hanoi pegs. This restriction is lifted.
-----------------------------------------------------------------------------
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom
Ricardo Dague
>
> Inform Library 6/8 now released
> ===============================
I know this is late, but there's a bug (I think) in how the
parser runs parse_name. If the parse_name routine calls
NextWord() but then returns -1 to let the parser check the
name property in the usual way, the variable wn isn't reset
properly.
In the following code, shouldn't the user be able to call
the object "thing"?
object thing "thing"
with name 'thing',
parse_name [; NextWord(); return -1; ];
The bug (I think) is in parserm. Lines 3227-3228
{ parser_action = NULL; j = wn;
k=RunRoutines(obj,parse_name);
should be changed to
{ parser_action = NULL; j = wn;
k=RunRoutines(obj,parse_name); wn = j;
Is this right?
-- Ricardo
Zimri
graham...@hotmail.com wrote in message
<751l85$mqa$1...@nnrp1.dejanews.com>...
>In article <ant1302550b0M+4%@gnelson.demon.co.uk>,
> Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>>
>> Inform Library 6/8 now released
>> ===============================
>
>Excellent. I guess this means I'll have to update my hacks.
You mean hacking the library? Specifically, the [ LanguageLM n x1; function
of the English.h library? Don't do that. You'd have to redo it every time
Dr Nelson makes a change. Even then, you might mess up and have to
redownload it. Finally, it's ethically questionable (I mean, this is
someone else's code...).
Having said that, I've felt the need to override the canned responses,
believe me. In fact, I think everyone should. We're not Dr Nelson. We're
never going to be Dr Nelson. So how come all the Inform games I've played
sound like him? Outside his games, responses like "You can't usefully blow
<xxxx>" and "I only understood you as far as wanting to <yyyy>" are
stylistically jarring. They are also over-used.
Here are some workarounds that don't require messing with the library. I
stole this example from CE Forman's MST3K sourcecode (sorry Chris!):
Object LibraryMessages "lm"
with before [;
Attack: "It would really make more sense to specify some living \
thing^to kill. Hostility really requires a target of some \
sort.";
<etc.>;
];
Chris says you have to do this BEFORE the Include "Verblib"; statement in
your source file. I'm guessing this is because Verblib.h is the library
which brings that programmer-defined LibraryMessages object into
compilation. At any rate, later on that library will call Verblibm.h, which
uses all that "before [; <blah>;];" stuff I just mentioned.
You can even override the error responses. For example, the infamous "You
can't do any such thing" can be altered (according to Ken Fair, 24 Nov 1997,
in
http://x14.dejanews.com/getdoc.xp?AN=292036782&search=thread&threaded=1&CONT
EXT=913608846.392364034&HIT_CONTEXT=913608807.391708707&HIT_NUM=2&hitnum=6):
Miscellany:
if (lm_n == 30) {
wn = 1;
while (i == NextWordStopped()) {
if (i == -1) "You can't see that here.";
}
i = ((wn-1) * 8);
print "Sorry, I don't know the word, ~";
for (j = 0 : j < parse->i : j++) {
print (char) buffer->(parse->(i+1) + j);
} ".~";
}
to get you an "Infocom response". At least, so he said back in '97...
unfortunately it only returns the second word, not the noun (so if you're
like me and type out "look at chalice" instead of "x chalice", you're
screwed). I'm not sure an Infocom response is possible outside the .h file,
but I prefer Dr Nelson's inspecific method anyway... but on the third hand,
*anything* is preferable to yet another canned Inform response. (Matt
Barringer, where are you?)
To sum up: there's no pressing need to hack the library, but by all means,
override it. PLEASE override it. Your grandchildren will thank you. I
will thank you. Garrison Boyd from the Amstell Lite commercials will thank
you. Angels will sing your name <blah blah Blah...>
--- Zimri'el
Looking for a new sig 'cause --Z is taken
graham...@hotmail.com
Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>
> ===============================
Excellent. I guess this means I'll have to update my hacks.
- GLYPH
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Adam J. Thornton
Hey, _Stiffy Makane: The Undiscovered Country_ is going to make HEAVY use
of that one!
Adam
--
ad...@princeton.edu
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman
Zimri
>At least, so he said back in '97...
>unfortunately it only returns the second word, not the noun (so if you're
>like me and type out "look at chalice" instead of "x chalice", you're
>screwed).
I just tested his routine again, and I have to retract that. It worked -
but there was a variable assignment within a while() statement which
frightened my version 6.15 Inform compiler. Here's a version which keeps
Inform happy:
Object LibraryMessages "lm"
with before
[ i j; Miscellany:
if (lm_n == 30) {
wn = 1; i = -1;
while (i) {
i = NextWordStopped();
if (i == -1) "You can't see that here.";
}
i = ((wn-1) * 4);
print "Sorry, I don't know the word, ~";
for (j = 0 : j < parse->i : j++) {
print (char) buffer->(parse->(i+1) + j);
} "~.";
}
];
I've been doing more thinking about this, and it looks like a prime
candidate for a subroutine. You really wouldn't want to duplicate this code
over 30-odd cases. But even this is an unnecessary kludge...
If you look above, you can see the lm_n variable (argument n in the English
and Verblibm libraries) holds the switch; in this case, lm_n=30. AFAICS, in
just such a way the lm_o variable was supposed to hold the object noun.
lm_o is (mis)assigned in the following lines in parserm:
[ L___M n x1 s;
s=action;
lm_n=n; lm_o=x1;
action=sw__var;
if (RunRoutines(LibraryMessages,before)~=0) { action=s; rfalse; }
action=s;
LanguageLM(n, x1);
];
I couldn't get lm_o to work - the compiler decides it's an integer and
converts it into a zero. It's defined in linklv.h: "Import global lm_o".
It seems to be the classic "Defined As Integer, Assigned As String Tug Of
War".
lm_o really should be a *pointer* to a string, shouldn't it? My C++ days
are past me, but I remember that much. Shouldn't lm_o=x1 really be
lm_o=*x1?
I guess I should hand this thread over to someone who knows what they're
talking about...
-- Zimri'el
Andrew Plotkin
> Two vents follow...
> graham...@hotmail.com wrote in message
> <751l85$mqa$1...@nnrp1.dejanews.com>...
> >In article <ant1302550b0M+4%@gnelson.demon.co.uk>,
> > Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
> >>
> >> Inform Library 6/8 now released
> >> ===============================
> >
> >Excellent. I guess this means I'll have to update my hacks.
> You mean hacking the library? Specifically, the [ LanguageLM n x1; function
> of the English.h library? Don't do that. You'd have to redo it every time
> Dr Nelson makes a change. Even then, you might mess up and have to
> redownload it. Finally, it's ethically questionable (I mean, this is
> someone else's code...).
>
> Having said that, I've felt the need to override the canned responses,
> believe me.
Ah. Yes, this is a known topic.
The LibraryMessages scheme isn't a workaround -- it's the documented,
supported way to change Inform library messages. Graham (Nelson :-) will
certainly ensure that it keeps working through future library releases.
However, it has one significant disadvantage: when you override a message
with LibraryMessages, the default string is still compiled into your game
file, even though it's never used. If you replace *lots* of messages, this
wastes a fair amount of space. (High memory, not RAM.) Some authors have
*had* to edit LanguageLM; the memory bloat would be crippling otherwise.
However (again), I think Graham (Fyffe :-) wasn't just talking about
replacing library messages. He supports a large set of library alterations
that go a lot deeper than text changes. There's nothing wrong with that.
> To sum up: there's no pressing need to hack the library, but by all means,
> override it. PLEASE override it. Your grandchildren will thank you. I
> will thank you. Garrison Boyd from the Amstell Lite commercials will thank
> you. Angels will sing your name <blah blah Blah...>
Well, no.
There's only one person that will thank you for not hacking the library,
and that's you. You're the one who has to support the hacks for your own
game. You're the one that has to transfer them to a new library when a new
library appears.
There are ways to minimize the hackiness. You can Replace a library
routine in your own code. But sometimes this doesn't help, and you really
do have to go in and change the library source.
I have had to hack the library for each of my games. They were small
hacks, but important for small parsing details that I wanted to get
*right*. (Right my *my* game, of course -- these were customizations for
my game, not library bugs.)
I pay the price: I have to keep a separate version of the library files
for every games. Since I'm lazy, I probably will never upgrade any of
those games to a more advanced library version; I'd have to transfer the
hacks over, and then re-test *everything*.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Doeadeer3
In article <erkyrathF...@netcom.com>, erky...@netcom.com (Andrew
Plotkin) writes:
>I have had to hack the library for each of my games. They were small
>hacks, but important for small parsing details that I wanted to get
>*right*. (Right my *my* game, of course -- these were customizations for
>my game, not library bugs.)
>
>I pay the price: I have to keep a separate version of the library files
>for every games. Since I'm lazy, I probably will never upgrade any of
>those games to a more advanced library version; I'd have to transfer the
>hacks over, and then re-test *everything*.
I put a big !CHANGED comment before each change so I can use my word search
function in my editor to find it and change each new library that way also (if
I want to keep that change as a standard change).
(Probably Z does something similar.)
Just mentioning that is it a good idea to document (somehow) one's changes.
A lot of us change the code itself.
Doe :-) But they are "open" libraries, so we can.
Doe doea...@aol.com (formerly known as FemaleDeer)
****************************************************************************
"In all matters of opinion, our adversaries are insane." Mark Twain
Gareth Rees
> I put a big !CHANGED comment before each change so I can use my word
> search function in my editor to find it and change each new library
> that way also (if I want to keep that change as a standard change).
One approach to this problem (applying your library changes to a new
version of the library) is to use an interactive 3-way merge tool.
A 3-way merge tool takes 3 files:
1 an ancestor (in this case, Graham's 6/7 library release);
2 a revision of file 1 (in this case, Graham's 6/8 library release);
3 another revision of file 1 (in this case, your hacked library).
An interactive 3-way merge tool presents you with a list of the changes
from file 1 to file 2. You can examine each change and decide whether
you want to apply it to file 3 or not. Where the 1->2 change overlaps
with one of your 1->3 changes the tool won't be able to make the change
automatically, but it can flag the change as one needing some work on
your part.
Tools you can use:
* In Unix, `merge' is a non-interactive 3-way merge tool (it
automatically applies all the 1->2 changes to 3, flagging overlaps).
* `ediff' is an Emacs application for performing interactive 3-way
merges. It is very good indeed (especially since it's easy to step
out of `ediff' and back into your file to do some editing to patch
up an overlap). It comes as standard with Emacs and XEmacs.
* The commercial VCS tool Perforce (http://www.perforce.com/) has an
interactive 3-way merge editor.
--
Gareth Rees
Andrew Plotkin
> In article <erkyrathF...@netcom.com>, erky...@netcom.com (Andrew
> Plotkin) writes:
> >I have had to hack the library for each of my games. They were small
> >hacks, but important for small parsing details that I wanted to get
> >*right*. (Right my *my* game, of course -- these were customizations for
> >my game, not library bugs.)
> >
> >I pay the price: I have to keep a separate version of the library files
> >for every games. Since I'm lazy, I probably will never upgrade any of
> >those games to a more advanced library version; I'd have to transfer the
> >hacks over, and then re-test *everything*.
> I put a big !CHANGED comment before each change so I can use my word search
> function in my editor to find it and change each new library that way also (if
> I want to keep that change as a standard change).
>
> (Probably Z does something similar.)
Absolutely.
> Just mentioning that is it a good idea to document (somehow) one's changes.
Yup.
David Glasser
> lm_o really should be a *pointer* to a string, shouldn't it? My C++ days
> are past me, but I remember that much. Shouldn't lm_o=x1 really be
> lm_o=*x1?
Inform is not a strongly typed language. You don't need fancy syntax to
assign things. There is only one type.
That said, x1 is not a string; it is the object (object number, that is)
that is in the LibraryMessage.
--
David Glasser gla...@NOSPAMuscom.com http://onramp.uscom.com/~glasser
DGlasser @ ifMUD : fovea.retina.net:4001 | r.a.i-f FAQ: come.to/raiffaq
Sadie Hawkins, official band of David Glasser: http://www.port4000.com/
ne...@norwich.edu
Gareth Rees <gar...@cre.canon.co.uk> wrote:
> Doeadeer3 <doea...@aol.com> wrote:
> > I put a big !CHANGED comment before each change so I can use my word
> > search function in my editor to find it and change each new library
> > that way also (if I want to keep that change as a standard change).
>
> version of the library) is to use an interactive 3-way merge tool.
>
> A 3-way merge tool takes 3 files:
>
> 1 an ancestor (in this case, Graham's 6/7 library release);
> 2 a revision of file 1 (in this case, Graham's 6/8 library release);
> 3 another revision of file 1 (in this case, your hacked library).
>
> An interactive 3-way merge tool presents you with a list of the changes
> from file 1 to file 2. You can examine each change and decide whether
> you want to apply it to file 3 or not. Where the 1->2 change overlaps
> with one of your 1->3 changes the tool won't be able to make the change
> automatically, but it can flag the change as one needing some work on
> your part.
>
> Tools you can use:
>
> * In Unix, `merge' is a non-interactive 3-way merge tool (it
> automatically applies all the 1->2 changes to 3, flagging overlaps).
>
> * `ediff' is an Emacs application for performing interactive 3-way
> merges. It is very good indeed (especially since it's easy to step
> out of `ediff' and back into your file to do some editing to patch
> up an overlap). It comes as standard with Emacs and XEmacs.
>
> * The commercial VCS tool Perforce (http://www.perforce.com/) has an
> interactive 3-way merge editor.
Another possibility is the interesting GNU utility, diff3.
--
Neil Cerutti
ne...@norwich.edu
Jonadab the Unsightly One
> I couldn't get lm_o to work - the compiler decides it's an integer
Every variable is an integer in Inform. Always.
> and
> converts it into a zero. It's defined in linklv.h: "Import global lm_o".
> It seems to be the classic "Defined As Integer, Assigned As String Tug Of
> War".
?
> lm_o really should be a *pointer* to a string, shouldn't it?
String? Isn't it a pointer to an object?
> My C++ days
> are past me, but I remember that much.
Inform isn't quite like C++. The syntax is similar, but
there are differences. Inform is a good deal less
hairy, for one thing. Syntactically, that is.
> Shouldn't lm_o=x1 really be
> lm_o=*x1?
Pointer dereferencing doesn't apply in inform.
Every variable is an integer, and can point
equally well to a string, object, dictionary entry,
array entry, class, property, attribute, ...
- jonadab
Jonadab the Unsightly One
> I put a big !CHANGED comment before each change so I can use my word search
> function in my editor to find it and change each new library that way also (if
> I want to keep that change as a standard change).
I now use the following system:
#IFDEF Jonadab;
! changed code goes here
#IFNOT;
! unchanged code remains here
#ENDIF;
Unfortunately, I did not have the forsight to do this with Diary, and
now I am definitely paying the price.
- jonadab
Magnus Olsson
David Glasser <gla...@DELETEuscom.com> wrote:
>Zimri <zim...@earthlink.net> wrote:
>
>> lm_o really should be a *pointer* to a string, shouldn't it? My C++ days
>> are past me, but I remember that much. Shouldn't lm_o=x1 really be
>> lm_o=*x1?
>
>Inform is not a strongly typed language. You don't need fancy syntax to
>assign things. There is only one type.
Actually, there are different types of data, but there's only one type
of variable, which can be interpreted either as an integer or as a
pointer to an object, a string or a dictionary entry.
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------
Frank Filz
For Windows there's vdiffmrg (which unfortuanately seems to have
disappeared....) Perforce even has a page on using vdiffmrg, but their
pointer to it is the same as WinFiles.com's....
--
Frank Filz
-----------------------------
Work: mailto:ff...@us.ibm.com
Home: mailto:ff...@mindspring.com
graham...@hotmail.com
"Zimri" <zim...@earthlink.net> wrote:
> Two vents follow...
>
> graham...@hotmail.com wrote in message
> <751l85$mqa$1...@nnrp1.dejanews.com>...
> >In article <ant1302550b0M+4%@gnelson.demon.co.uk>,
> > Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
> >>
> >> ===============================
> >
>
> You mean hacking the library? Specifically, the [ LanguageLM n x1; function
> of the English.h library? Don't do that. You'd have to redo it every time
> Dr Nelson makes a change. Even then, you might mess up and have to
> redownload it. Finally, it's ethically questionable (I mean, this is
> someone else's code...).
I guess you haven't seen my hack. It does several cool things that you *just
can't do* without hacking the library. I did it to make the library more like
an engine I made on my Amiga way back when.
Like, in unhacked Inform, can you do this?
>Open the book that's on the dresser then take the book that's in the box on
the shelf.
( of course, now that Inform only recognizes 15 words, I might be SOL. Why 15
specifically? Is that the theoretical upper limit? )
I think what I'll do is make a detailed list of updates for myself, so
whenever a new Inform lib is released it will be a piece of cake to patch it
with my hacks. And I never said you have to use my hack :)
- GLYPH
Joe Mason
>Like, in unhacked Inform, can you do this?
>
>>Open the book that's on the dresser then take the book that's in the box on
>the shelf.
>
>( of course, now that Inform only recognizes 15 words, I might be SOL. Why 15
>specifically? Is that the theoretical upper limit? )
You can hack that too. It's a Library 6/8 limit, if I'm not mistaken.
Joe
--
Congratulations, Canada, on preserving your national igloo.
-- Mike Huckabee, Governor of Arkansas
graham...@hotmail.com
jon...@zerospam.com (Jonadab the Unsightly One) wrote:
> doea...@aol.com (Doeadeer3) wrote:
>
> > I put a big !CHANGED comment before each change so I can use my word search
> > function in my editor to find it and change each new library that way also
(if
> > I want to keep that change as a standard change).
>
> I now use the following system:
>
> #IFDEF Jonadab;
> ! changed code goes here
> #IFNOT;
> ! unchanged code remains here
> #ENDIF;
Oh, big woohoo for this one. I'll be using this method in my updated hack if
you don't mind. (of course, I'll use #IFDEF GLYPH :)
Zimri
>Zimri (zim...@earthlink.net) wrote:
>> Having said that, I've felt the need to override the canned
responses,
>> believe me.
>
>Ah. Yes, this is a known topic.
Yeah. Sorry for bringing it up again, and especially for phrasing it
in such an evangelistic manner. It would've helped if I'd started
with Inform earlier than <koff> 10 December this year...
I grew up in NG's like rec.games.frp.dnd and soc.history.ancient,
where I started out knowing what I was talking about. This is my
first foray into a newsgroup in which I am decidedly Clueless. (I'm
not clueless in *playing* the games... but I'm no good at *writing*
them.)
Anyway, I apologize for the tone in the technical part of my rant. I
explain it below...
>The LibraryMessages scheme isn't a workaround -- it's the documented,
>supported way to change Inform library messages.
I should've guessed, just from the fact that the "[before:]" method
was implemented at all.
>However, it has one significant disadvantage: when you override a
message
>with LibraryMessages, the default string is still compiled into your
game
>file, even though it's never used. If you replace *lots* of messages,
this
>wastes a fair amount of space. (High memory, not RAM.) Some authors
have
>*had* to edit LanguageLM; the memory bloat would be crippling
otherwise.
Ack! Say it ain't so.
Any plans on introducing a "garbage collection algorithm" into the
Z-machine? Will Dr Nelson be converting the LanguageLM parts most
likely to be overridden into OO format, where they can be destroyed if
overridden?
>However (again), I think Graham (Fyffe :-) wasn't just talking about
>replacing library messages. He supports a large set of library
alterations
>that go a lot deeper than text changes. There's nothing wrong with
that.
He made that clear in a later post.
>> To sum up: there's no pressing need to hack the library, but by
all means,
>> override it. PLEASE override it. Your grandchildren will thank
you. I
>> will thank you. Garrison Boyd from the Amstell Lite commercials
will thank
>> you. Angels will sing your name <blah blah Blah...>
>
>Well, no.
>
>There's only one person that will thank you for not hacking the
library,
>and that's you.
<snipping the rest>
I was actually referring to players thanking the programmer for not
reverting to Dr Nelson's canned responses. This was my vent #2. I
dunno, it's just a big beef with me. I love Curses and Jigsaw, but as
a player I don't like to read Curses dialogue within a totally
different game.
One analogy would be the Iliad. Like IF, it is a story where much of
the text is "stock" (white armed Athene, when rosy fingered dawn
appeared, etc. etc.). Now, before anyone flames me, I will state
right now that there is *nothing* wrong with using stock. In both
epic and IF, stock is demanded by the genre. The poet has to remember
10,000 lines of verse and the IF author has to support 10,000 lines of
code.
Now, say I'm reading an epic by a modern poet. Although this new epic
is not anything like the Iliad, it contains the same stock epithets
and phrases, but applied to different people. I'm willing to accept
the need for stock, but for heaven's sake, make up your own.
I did not assume that the programmers out there were lazy; I honestly
thought it was because many of you just didn't know about the
LibraryMessages routine. It wasn't mentioned in the Technical Guide
and I had to find out about it through CE Forman's source code. And
CE Forman, IMO, is in the "top tier" of IF authors to-day. I
concluded that it was an obscure feature of Inform, and that I needed
to enlighten the masses. Feel free to laugh at me now. I deserve it.
In the meantime, you answered my implicit question with an implicit
explanation. IF authors don't bother with the stock phrases because:
1. it would require the programmer to put up with a heap o' wasted
memory space.
2. the programmer is probably hacking the library anyway, for other
reasons.
3. supporting that stuff is no fun. programmers have other bugs to
chase down.
I also realize (now) that there's a big ol' flamewar going on just
outside the door. This is not the best time for inflammatory posts by
blithering newbies. Oops.
-- Zimri'el
Andrew Plotkin
> >when you override a message
> >with LibraryMessages, the default string is still compiled into your
> >game file, even though it's never used. If you replace *lots* of
> >messages, this wastes a fair amount of space. (High memory, not RAM.)
> >Some authors have *had* to edit LanguageLM; the memory bloat would be
> >crippling otherwise.
> Ack! Say it ain't so.
>
> Any plans on introducing a "garbage collection algorithm" into the
> Z-machine? Will Dr Nelson be converting the LanguageLM parts most
> likely to be overridden into OO format, where they can be destroyed if
> overridden?
The Z-machine has no memory allocation at all; everything is allocated at
compile time. (Unless you set aside a big array and write your own memory
manager in Z-code to parcel it out. Which has been done, but rarely.)
And object-orientation really doesn't have anything to do with the
question.
It *can* be done at compile time -- theoretically. The problem is, the
library contains a big switch statement, and the LibraryMessages object
contains another big switch statement, and the compiler has no way to know
that cases in one will obsolete cases in the other. (The whole LM system
is written in library code; the compiler doesn't know about it at all.)
It's not immediately obvious how to add a language feature which would
support this kind of smart overriding, without being hopelessly gross for
either the compiler or the programmer or both.
I mean, you could define a separate function for every library message --
when you Replace a function, the old version doesn't get compiled in. But
who wants to deal with that?
David Glasser
> I did not assume that the programmers out there were lazy; I honestly
> thought it was because many of you just didn't know about the
> LibraryMessages routine. It wasn't mentioned in the Technical Guide
> and I had to find out about it through CE Forman's source code. And
> CE Forman, IMO, is in the "top tier" of IF authors to-day. I
> concluded that it was an obscure feature of Inform, and that I needed
> to enlighten the masses. Feel free to laugh at me now. I deserve it.
Well, this is because the Technical Guide isn't the main Inform manual.
It is about, well, technical aspects of Inform. I think you'll have a
lot more success with the Designer's Manual.
Two "by the way"s: CE Forman was in the "top tier" last year but seems
to have forcefully left IF-dom. Wah.
Also, there's another solution: if you are overloading a *lot* of
LibraryMessages, you can make a copy (a copy!) of English.h, munge
around with a few language directives, and make changes in there. Much
simpler if you are overloading practically every message.
> I also realize (now) that there's a big ol' flamewar going on just
> outside the door. This is not the best time for inflammatory posts by
> blithering newbies. Oops.
You're not blithering. 'sokay. Plus, as OT (off topic) as your OT (old
testament) posts are, I'm learning from them.
Jonadab the Unsightly One
> I grew up in NG's like rec.games.frp.dnd and soc.history.ancient,
> where I started out knowing what I was talking about.
Heh. I had a similar problem. Before I had internet
access 99% of my human contact was with people who
may have been to high school but didn't care to learn
anything while there. So then I charged into this
newsgroup and acted like I knew 10 times as much
as anyone because I was used to that being the case.
(Literally. Yes, it's sad. I worked at McDonald's
at the time...) Oopse.
I got set straight pretty quickly.
> This is my
> first foray into a newsgroup in which I am decidedly Clueless. (I'm
> not clueless in *playing* the games... but I'm no good at *writing*
> them.)
Yet. If you're good at playing them and *enjoy* writing them,
then you can become good at writing them with practice.
Tip: Pick out several of the ones you liked best as a player,
and force yourself to write a list of why you liked each one.
> >*had* to edit LanguageLM; the memory bloat would be crippling
> otherwise.
> Ack! Say it ain't so.
It's no big deal; keep a backup copy of the unaltered
version, and comment all the changes you make with
a distinctive mark (!!CHANGE!! or something, or
#ifdef YOURNAMEHERE, or whatever tickles your fancy,
but mark them somehow).
You may eventually find yourself needing to alter
small bits of parser behavior for the particular
needs of a given game, too. This can fortunately
usually be done with a Replace directive so you
don't have to actually edit the parser, although
not always. (For example, changing certain things
about the Darkness object are most easily done
by editing the library directly. It might be nice
if future versions of the library used thedark as
a variable, initially set to library_dark_object,
but which you could set to your own object instead
if you liked. But these are very small things
in any case. You don't have to write your own
parser :-)
> Any plans on introducing a "garbage collection algorithm" into the
> Z-machine?
Not likely. Perhaps in a future VM designed to
succeed the Z-Machine.
> I was actually referring to players thanking the programmer for not
> reverting to Dr Nelson's canned responses. This was my vent #2. I
> dunno, it's just a big beef with me. I love Curses and Jigsaw, but as
> a player I don't like to read Curses dialogue within a totally
> different game.
Yeah, I kind of agree here. The defaults are just that,
and made to be changed. Of course, if your game
is a very short game that takes place entirely in
a dentist's office, there might not be any need
to bother with the verbs for Sing and Swim...
> I did not assume that the programmers out there were lazy; I honestly
> thought it was because many of you just didn't know about the
> LibraryMessages routine. It wasn't mentioned in the Technical Guide
> and I had to find out about it through CE Forman's source code.
I thought it was in the DM... or was I mistaken?
> And
> CE Forman, IMO, is in the "top tier" of IF authors to-day.
Was. Unfortunately he's left the IF world,
probably for good.
> I
> concluded that it was an obscure feature of Inform, and that I needed
> to enlighten the masses. Feel free to laugh at me now. I deserve it.
No, no. Wait till you say something really stupid.
We'll laugh at you then. Stating the obvious isn't
nearly as silly as some of what goes on around here.
> 1. it would require the programmer to put up with a heap o' wasted
> memory space.
> 2. the programmer is probably hacking the library anyway, for other
> reasons.
Those two make sense.
> 3. supporting that stuff is no fun. programmers have other bugs to
> chase down.
I'm not sure the Library Messages object generates bugs, though.
> I also realize (now) that there's a big ol' flamewar going on just
> outside the door. This is not the best time for inflammatory posts by
> blithering newbies. Oops.
Inflammatory posts that are on-topic aren't so bad.
Sometimes they generate healthy discussion.
The worst flamewars are usually off-topic.
Oh, and they're mild compared to a lot of other groups.
- jonadab
Jonadab the Unsightly One
> > #IFDEF Jonadab;
> Oh, big woohoo for this one. I'll be using this method in my updated hack if
> you don't mind. (of course, I'll use #IFDEF GLYPH :)
Nope, I don't mind.
It's a little extra typing, but it leaves little doubt as
to the changes you made.
- jonadab
Magnus Olsson
Jonadab the Unsightly One <jon...@zerospam.com> wrote:
>"Zimri" <zim...@earthlink.net> wrote:
Some discussion about how overriding library messages leaves the
unused messages around in the Z code file wasting space, snipped in
the post I'm following up to, but it led up to the following:
>> Any plans on introducing a "garbage collection algorithm" into the
>> Z-machine?
>
>Not likely. Perhaps in a future VM designed to
>succeed the Z-Machine.
Actually you don't want GC in this case. GC is good for programs where
you create a lot of object dynamically at run time (as you do with
"new" in C++, or malloc() in C) - it automatically removes those
objects when they aren't needed any more (unlike in C++ or C, where
you have to remember to delete them yourself). While Inform does
support dynamic object creation, I don't think this is a big issue -
yet.
Anyway, what's the problem here is unused *static* objects - text, in
this case, which is allocated space by the compiler but never
used. What's needed is for the compiler to recognize things like "this
string is in the source code, but it is never actually printed by the
program, so I don't have to put it in the Z-code file". An optimizer,
in other words.
ne...@norwich.edu
> > And
> > CE Forman, IMO, is in the "top tier" of IF authors to-day.
>
> Was. Unfortunately he's left the IF world,
> probably for good.
Ye Olde Infocomme shop is still going strong last time I checked the site, and
he is still offering Delusions and promoting the IF contest (obliquely) on his
site.
http://netnow.micron.net/~jgoemmer/infoshop.html
--
Neil Cerutti
ne...@norwich.edu
Sean T Barrett
>Anyway, what's the problem here is unused *static* objects - text, in
>this case, which is allocated space by the compiler but never
>used. What's needed is for the compiler to recognize things like "this
>string is in the source code, but it is never actually printed by the
>program, so I don't have to put it in the Z-code file". An optimizer,
>in other words.
However, in this context, the particular analysis required is
pretty much unachievable--that is, no compiler known to mankind
has ever (so far as I know or can imagine) done this.
[begin technical detail]
That's because the situation is that there are a bunch of cases
within a single switch statement. The function is still called;
it's just not always called with ever possible value (e.g. in
the notify-message case, Miscellany with subvalue 50).
If that function is ever called from a place where it's not
clear where it's not obvious whether the subvalue is 50 or
the 'verb' is Miscellany (e.g. if the function were ever called
with the value of a variable as a parameter, since optimizers
are unlikely to decipher that a variable in a particular case
is never some particular number), the compiler cannot remove
that case from the code.
[end technical detail]
Now, certainly, someone could write a special-purpose optimizer
that looks for exactly this case and propagates around the right
data so as to figure it out. However, that means you won't
see gains in general from this optimization--it's really just
to fix up this one problem--and therefore, there are probably
better approaches which involve structuring the library differently.
Sean
Jonadab the Unsightly One
>
> Inform Library 6/8 now released
> ===============================
> Ilib68.zip
I am almost sure this bug is in the library.
The last several routines called before
the error were library routines, and the
last of my routines before that was a
before rule that only traps one action
and does a print_ret of a static string.
[ InformLibrary.begin_action(a = 31, n = 0, s = 0, source = 1) ]
[ BeforeRoutines() ]
[ GamePreRoutine() ]
[ RunRoutines(obj = 23, prop = 29) ]
[ RA__Pr(obj = 23, identifier = 29) ]
[ RunRoutines(obj = 19, prop = 4) ]
[ RA__Pr(obj = 25, identifier = 4) ]
[ CA__Pr(obj = 25, id = 4) ]
[ Z__Region(addr = 13361) ]
[ Unsigned__Compare(x = 13361, y = 24023) ]
[ Unsigned__Compare(x = 13361, y = 3053) ]
[ Room::before() ]
[ ScopeCeiling(person = 23) ]
[ SearchScope(domain1 = 19, domain2 = 23, context = 0) ]
[ ScopeWithin(domain = 19, nosearch = 23, context = 0) ]
[ ScopeWithin(domain = 23, nosearch = 0, context = 0) ]
[ ScopeWithin_O(domain = 20, nosearch = 20, context = 0) ]
[ DoScopeAction(thing = 20) ]
[ RT__Err(crime = 3, obj = 0) ]
[** Programming error: tried to test "has" or "hasnt" of [
PrintShortName(o = 0)
]
[ PSN__(o = 0) ]
[ RT__ChPrintS(a = 24117) ]
[ Z__Region(addr = 24117) ]
[ Unsigned__Compare(x = 24117, y = 24023) ]
nothing **]
BTW, if I haven't said so already, I'm very appreciative
of Inform 6.2; it's already found one error in a game
that I might never have discovered otherwise. Thanks.
I do have one suggestion; I have no idea how difficult
it might or might not be to implement, but if the
message
[** Programming error: tried to test "has" or "hasnt" of nothing **]
could be easily modified to also list the attribute
in question (even by number) it would make tracking
these things down even easier.
- jonadab
Magnus Olsson
Sean T Barrett <buz...@world.std.com> wrote:
>Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>>Actually you don't want GC in this case.
>[snip]
>>Anyway, what's the problem here is unused *static* objects - text, in
>>this case, which is allocated space by the compiler but never
>>used. What's needed is for the compiler to recognize things like "this
>>string is in the source code, but it is never actually printed by the
>>program, so I don't have to put it in the Z-code file". An optimizer,
>>in other words.
>
>However, in this context, the particular analysis required is
>pretty much unachievable--that is, no compiler known to mankind
>has ever (so far as I know or can imagine) done this.
>
>[begin technical detail]
>
>That's because the situation is that there are a bunch of cases
>within a single switch statement. The function is still called;
>it's just not always called with ever possible value (e.g. in
>the notify-message case, Miscellany with subvalue 50).
That's true. I was thinking more of the plentiful cases where
you can be more certain that some code or data will never be used,
e.g. when a routine is replaced. With some changes to the library
(and, possibly, some minor changes to the language as well) it
might be possible to extend this to library messages - get rid of
the big switch, for example, and replace it with a lot of objects that
can ber replaced by the user.
But all this would be a lot of work. IMHO the effort needed would be
much more wisely invested in making Inform produce code for a
different VM without the tight memory limits.
Jonadab the Unsightly One
I think I've tracked this down. Maybe. Hopefully.
Any insights would be appreciated.
[All this involves Inform 6.2 & Library 6/8.]
Somewhere within the realms of BeforeRoutines something
was going a bit wrong somehow when my initialise routine
had set player to a replacement object but hadn't
changed the actor variable; I changed the actor variable
to match and cleared it up. I'm not precisely sure where
the bug was occuring or what caused it. My tracking
notes follow, woven into a section of debugging transcript
in a non-chronological fashion. It appears that the actual
error was happening on an action call after BeforeRoutines
returned but before the action was actually started.
[ InformLibrary.begin_action(a = 31, n = 0, s = 0, source = 1) ]
! i.e., Look
[ BeforeRoutines() ]
! BeforeRoutines does its thing, calling SearchScope just about
! dead last before returning; I'm almost certain SearchScope
! returns before the error. BeforeRoutines doesn't do much
! after calling it:
! SearchScope(ScopeCeiling(player),player,0);
! scope_reason=PARSING_REASON;
! if (parser_one~=0) rtrue;
! if (inp1>1 && RunRoutines(inp1,before)~=0) rtrue;
! ! That particular condition must be false (if it even
! ! gets past the check on parser_one above), because
! ! RunRoutines is not called again before the error.
! rfalse;
! ];
! So I think BeforeRoutines returns before the error, but the
! error happens before the Look is carried out.
[ RunRoutines(obj = 19, prop = 4) ]
! before routine of darkness object.
[ GamePreRoutine() ] ! called by BeforeRoutines
[ RunRoutines(obj = 23, prop = 29) ]
! Orders prop of drowsy student
! called by BeforeRoutines as orders prop of player
! [ RunRoutines obj prop;
! if (obj == thedark
! && prop ~= initial or short_name or description)
! obj=real_location;
! if (obj.&prop == 0) rfalse;
! return obj.prop();
! ];
[ RA__Pr(obj = 23, identifier = 29) ]
! Orders prop of drowsy student
! Must be called by obj.prop(); ?
! At this point BeforeRoutines does the following:
! scope_reason=REACT_BEFORE_REASON;
! This becomes significant later.
[ RunRoutines(obj = 19, prop = 4) ]
! before routine of darkness object.
! Called by BeforeRoutines in a condition as the before
! property of location.
! RunRoutines changes objects to real_location, yielding this:
! obj.prop(); where obj is the bedroom and prop is before
[ RA__Pr(obj = 25, identifier = 4) ]
! before routine of bedroom.
! Must be called by RunRoutines as obj.prop();
! The bedroom does not have its own before routine, although
! it does inherit one from the Room class, which we'll get to...
[ CA__Pr(obj = 25, id = 4) ]
! I have no idea what this is; RA__Pr must call it
! to handle inherited props or something.
[ Z__Region(addr = 13360) ]
! Must be called by CA__Pr?
[ Unsigned__Compare(x = 13360, y = 23817) ]
! Probably called by Z__Region
[ Unsigned__Compare(x = 13360, y = 3053) ]
! Probably called by Z__Region
[ Room::before() ]
! This undoubtedly descends from the call to the before routine
! of the bedroom, which inherits from Room, which is why
! I think everything in between is still related to that
! obj.prop(); call to the bedroom's before property.
! before [;
! wait: "You get even drowsier.";
! ];
[ ScopeCeiling(person = 23) ]
! Here's the relevant section in BeforeRoutines:
! SearchScope(ScopeCeiling(player),player,0);
! (23 is the drowsy student.)
! And here's what ScopeCeiling does:
! [ ScopeCeiling person act;
! act = parent(person); if (act == 0) return person;
! if (person == player && location == thedark)
! return thedark;
! while (parent(act)~=0
! && (act has transparent || act has supporter
! || (act has container && act has open)))
! act = parent(act);
! return act;
! ];
[ SearchScope(domain1 = 19, domain2 = 23, context = 0) ]
! domain1 should be coming from ScopeCeiling(player), which
! apparently returned 19 -- the darkness object.
! domain2 is 23, the drowsy student.
! SearchScope calls ScopeWithin twice, calls ScopeWithin_O
! at Point C (marked below) and then apparently exits
! back to BeforeRoutines.
[ ScopeWithin(domain = 19, nosearch = 23, context = 0) ]
! Called by SearchScope at Point A (marked below)
[ ScopeWithin(domain = 23, nosearch = 0, context = 0) ]
! Called by SearchScope at Point B (marked below)
[ ScopeWithin_O(domain = 20, nosearch = 20, context = 0) ]
! Called by SearchScope at Point C (marked below)
! Note that actor is incorrectly set to self_obj;
! I'm recifying this in Initialise now, and it
! appears to solve the problem. ???
! Anyway, ScopeWithin_O should get here:
! { DoScopeAction(domain); jump DontAccept; }
! That DoScopeAction is the last routine called before
! the error, so we're very close now. After the
! jump, ScopeWithin_O should proceed as follows:
! if (child(domain)~=0 && ...
! But the child of the self object should be zero, so
! it should proceed here:
! ! Drag any extras into context
!
! ad = domain.&add_to_scope;
! (That should be zero, so ScopeWithin_O should return.
[ DoScopeAction(thing = 20) ]
! Called by ScopeWithin_O because the scoping reason is unusual.
! If my calculations are correct, it should do this:
! if (thing.react_before==0 or NULL) return;
! Since neither the self object nor the drowsy student
! should have a react_before as near as I can determine,
! DoScopeAction must return.
[ RT__Err(crime = 3, obj = 0) ]
[** Programming error: tried to test "has" or "hasnt" of [
PrintShortName(o = 0)
]
! What follows is for reference.
[ SearchScope domain1 domain2 context i;
i=0;
! Everything is in scope to the debugging commands
#ifdef DEBUG;
if (scope_reason==PARSING_REASON
&& verb_word == 'purloin' or 'tree' or 'abstract'
or 'gonear' or 'scope' or 'showobj')
{ for (i=selfobj:i<=top_object:i++)
if (i ofclass Object && (parent(i)==0 || parent(i) ofclass
Object))
PlaceInScope(i);
rtrue;
}
#endif;
! First, a scope token gets priority here:
if (scope_token ~= 0)
{ scope_stage=2;
if (indirect(scope_token)~=0) rtrue;
}
! Next, call any user-supplied routine adding things to the scope,
! which may circumvent the usual routines altogether if they return
true:
if (actor==domain1 or domain2 && InScope(actor)~=0) rtrue;
! Pick up everything in the location except the actor's possessions;
! then go through those. (This ensures the actor's possessions are
in
! scope even in Darkness.)
if (context==MULTIINSIDE_TOKEN && advance_warning ~= -1)
{ if (IsSeeThrough(advance_warning)==1)
ScopeWithin(advance_warning, 0, context);
}
else
{ if (domain1~=0 && domain1 has supporter or container)
ScopeWithin_O(domain1, domain1, context);
ScopeWithin(domain1, domain2, context); !
Point A
if (domain2~=0 && domain2 has supporter or container)
ScopeWithin_O(domain2, domain2, context);
ScopeWithin(domain2, 0, context); !
Point B
}
! A special rule applies:
! in Darkness as in light, the actor is always in scope to himself.
if (thedark == domain1 or domain2)
{ ScopeWithin_O(actor, actor, context); !
Point C
if (parent(actor) has supporter or container)
ScopeWithin_O(parent(actor), parent(actor), context);
}
];
[ DoScopeAction thing s p1;
s = scope_reason; p1=parser_one;
#ifdef DEBUG;
if (parser_trace>=6)
{ print "[DSA on ", (the) thing, " with reason = ", scope_reason,
" p1 = ", parser_one, " p2 = ", parser_two, "]^";
}
#endif;
switch(scope_reason)
{ REACT_BEFORE_REASON:
if (thing.react_before==0 or NULL) return;
#ifdef DEBUG;
if (parser_trace>=2)
{ print "[Considering react_before for ", (the) thing,
"]^"; }
#endif;
if (parser_one==0) parser_one =
RunRoutines(thing,react_before);
REACT_AFTER_REASON:
if (thing.react_after==0 or NULL) return;
#ifdef DEBUG;
if (parser_trace>=2)
{ print "[Considering react_after for ", (the) thing,
"]^"; }
#endif;
if (parser_one==0) parser_one =
RunRoutines(thing,react_after);
EACH_TURN_REASON:
if (thing.&each_turn==0) return;
#ifdef DEBUG;
if (parser_trace>=2)
{ print "[Considering each_turn for ", (the) thing, "]^";
}
#endif;
PrintOrRun(thing, each_turn);
TESTSCOPE_REASON:
if (thing==parser_one) parser_two = 1;
LOOPOVERSCOPE_REASON:
indirect(parser_one,thing); parser_one=p1;
}
scope_reason = s;
];
- jonadab