MaxTADS & addword/delword

5 views
Skip to first unread message

Stephen Granade

unread,
Nov 6, 1996, 3:00:00 AM11/6/96
to

Hihi,

I have a game fragment which makes insane use of TADS' addword/delword
commands. While putting MaxTADS through the ringer, I ran this fragment.
Lo and behold, delword was handled correctly. [General note: the original
TADS Mac interpreter does not handle delword() correctly.] Can anyone
else verify this? If so, it means I don't have to rewrite that fragment
to run on Macintoshes (Macintoshi?).

Stephen

--
Stephen Granade | "It takes character to withstand the
sgra...@phy.duke.edu | rigors of indolence."
Duke University, Physics Dept | -- from _The Madness of King George_

Andrew Plotkin

unread,
Nov 6, 1996, 3:00:00 AM11/6/96
to

Stephen Granade (sgra...@bashful.phy.duke.edu) wrote:
> Hihi,

> I have a game fragment which makes insane use of TADS' addword/delword
> commands. While putting MaxTADS through the ringer, I ran this fragment.
> Lo and behold, delword was handled correctly. [General note: the original
> TADS Mac interpreter does not handle delword() correctly.] Can anyone
> else verify this? If so, it means I don't have to rewrite that fragment
> to run on Macintoshes (Macintoshi?).

MaxTADS is based on the TADS 2.2.1 source that was posted by Mike Roberts
about three weeks ago. I believe that contains the delword fix.

You should probably test your code on the standard 2.2.1 Mac runtime
(which was uploaded at the same time.) Most likely you can stop worrying
about it. (Although, for example, the Atari TADS runtime seems to be
dated 1994, so it's not a perfect world.)

I also included a fix for a bug that screws up parsing for commands that
end with a number. ("set dial to 354".) That fix is probably not in the
standard Mac TR, but it is in the Unix source (daves-tads-src.tar.z)

--Z
--

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

Stephen Granade

unread,
Nov 6, 1996, 3:00:00 AM11/6/96
to

In article <erkyrathE...@netcom.com> erky...@netcom.com (Andrew
Plotkin) writes:
> MaxTADS is based on the TADS 2.2.1 source that was posted by Mike
> Roberts about three weeks ago. I believe that contains the delword fix.
>
> You should probably test your code on the standard 2.2.1 Mac runtime
> (which was uploaded at the same time.) Most likely you can stop worrying
> about it. (Although, for example, the Atari TADS runtime seems to be
> dated 1994, so it's not a perfect world.)

I tested the fragment using the 2.2.1 runtime which recently appeared @
gmd.de. Just as before, delword() didn't work. Chalk one up for MaxTADS.

Neil K. Guy

unread,
Nov 6, 1996, 3:00:00 AM11/6/96
to

Andrew Plotkin (erky...@netcom.com) wrote:

: You should probably test your code on the standard 2.2.1 Mac runtime

: (which was uploaded at the same time.) Most likely you can stop worrying
: about it. (Although, for example, the Atari TADS runtime seems to be
: dated 1994, so it's not a perfect world.)

Hm. How strange. I just tested the problem on MaxZip 1.0.1 and TADS
Runtime for Macintosh 2.2.1.0. The problem is fixed on MaxZip but remains
in standard tr. And this is a tr I compiled myself from the standard TADS
source code distribution in THINK C 5.0.2. I wonder if it's a problem
with THINK C that doesn't exist with CodeWarrior? Or perhaps it lies
somewhere else.

- Neil K.

--
the Vancouver CommunityNet * http://www.vcn.bc.ca/
(formerly the Vancouver Regional FreeNet)

Michael Self

unread,
Nov 7, 1996, 3:00:00 AM11/7/96
to

sgra...@bashful.phy.duke.edu (Stephen Granade) writes:
>I have a game fragment which makes insane use of TADS' addword/delword
>commands. While putting MaxTADS through the ringer, I ran this fragment.
>Lo and behold, delword was handled correctly. [General note: the original
>TADS Mac interpreter does not handle delword() correctly.] Can anyone
>else verify this? If so, it means I don't have to rewrite that fragment
>to run on Macintoshes (Macintoshi?).

Macinteesh. Hope this helps.

-- Mike

--
------------------------------------------------------------------------------
Michael Self (ms...@comp.uark.edu) University of Arkansas
------------------------------------------------------------------------------

David Baggett

unread,
Nov 10, 1996, 3:00:00 AM11/10/96
to

In article <55r0gi$t...@newsgate.duke.edu>,
Stephen Granade <sgra...@bashful.phy.duke.edu> wrote:

>I tested the fragment using the 2.2.1 runtime which recently appeared @
>gmd.de. Just as before, delword() didn't work. Chalk one up for MaxTADS.

MaxTADS is probably getting lucky. As far as I know, there's only one
bug fixed in MaxTADS that's not fixed in the standard 2.2.1 distribution,
and that wouldn't (as far as I can tell) affect delword().

I bet something in the TADS source is reading off the end of an array
or other data structure, and thereby getting nondeterministic results.
MaxTADS may just have a 23 where MacTR has a 15... If this is the case,
then delword may be unreliable on *all* machines.

On the other hand, perhaps Mike built MacTR 2.2.1 from something other than
the latest sources.

Dave Baggett
__
d...@ai.mit.edu
"Mr. Price: Please don't try to make things nice! The wrong notes are *right*."
--- Charles Ives (note to copyist on the autograph score of The Fourth of July)

Andrew Plotkin

unread,
Nov 10, 1996, 3:00:00 AM11/10/96
to

David Baggett (d...@xbar.ai.mit.edu) wrote:
> >I tested the fragment using the 2.2.1 runtime which recently appeared @
> >gmd.de. Just as before, delword() didn't work. Chalk one up for MaxTADS.

> MaxTADS is probably getting lucky. As far as I know, there's only one
> bug fixed in MaxTADS that's not fixed in the standard 2.2.1 distribution,
> and that wouldn't (as far as I can tell) affect delword().

Correct.

> I bet something in the TADS source is reading off the end of an array
> or other data structure, and thereby getting nondeterministic results.
> MaxTADS may just have a 23 where MacTR has a 15... If this is the case,
> then delword may be unreliable on *all* machines.

This wouldn't surprise me.

I don't suppose anyone has any idea *where* this is occurring? Which
piece of code actually contains the bug, so I can go look at the source
code and see which versions have it fixed and which don't?

Robert A. Pelak

unread,
Nov 10, 1996, 3:00:00 AM11/10/96
to

In article <erkyrathE...@netcom.com>,

Andrew Plotkin <erky...@netcom.com> wrote:
>David Baggett (d...@xbar.ai.mit.edu) wrote:
>> >I tested the fragment using the 2.2.1 runtime which recently appeared @
>> >gmd.de. Just as before, delword() didn't work. Chalk one up for MaxTADS.
>
>> MaxTADS is probably getting lucky. As far as I know, there's only one
>> bug fixed in MaxTADS that's not fixed in the standard 2.2.1 distribution,
>> and that wouldn't (as far as I can tell) affect delword().
>
>Correct.
>

Could it be a 16 bit versus 32 bit integer issue? What size ints are
being used in MaxTADS?

Robert

Neil K. Guy

unread,
Nov 10, 1996, 3:00:00 AM11/10/96
to

Andrew Plotkin (erky...@netcom.com) wrote:
: David Baggett (d...@xbar.ai.mit.edu) wrote:
: > >I tested the fragment using the 2.2.1 runtime which recently appeared @
: > >gmd.de. Just as before, delword() didn't work. Chalk one up for MaxTADS.

: > MaxTADS is probably getting lucky. As far as I know, there's only one
: > bug fixed in MaxTADS that's not fixed in the standard 2.2.1 distribution,
: > and that wouldn't (as far as I can tell) affect delword().

: Correct.

Well if MaxTADS is simply getting lucky, it's pretty damned lucky,
because there's another TADS parser bug that MaxTADS seems immune to.
This is a highly obscure bug that throws the parser into an infinite loop
in both TADS Runtime for Macintosh and tadsr for SGI-IRIX. But it works
just fine in MaxTADS.

For those interested, the bug is this. Let's say I have a word which is
defined as both an adjective and a noun - the example that I first
encountered is the word "body." Now use this word as an adjective, and
put the word "of" between it and the noun to which the adjective belongs.
Does that make sense? The phrase that causes this problem in the Mac and
IRIX ports of TADS is "large body of water." If you refer to the object
as "large body water" it's fine. Or "large of water". However the parser
goes into a loop trying to use the word as an adjective - try typing this
noun phrase into an affected TADS with the debug trace mode on and you'll
see where it loops.

I've looked at the source, and it seems to be getting stuck at the point
where Mike Roberts modified the parser to accept the word "of" as a
preposition, not just a special word. But I really have no clue what's
going on beyond this. I've mentioned this to him, but I thought I'd throw
it out here as well since the discussion was on weird bugs that MaxTADS
seems above.

Andrew Plotkin

unread,
Nov 10, 1996, 3:00:00 AM11/10/96
to

Robert A. Pelak (pe...@hannah.msc.cornell.edu) wrote:
> >> >I tested the fragment using the 2.2.1 runtime which recently appeared @
> >> >gmd.de. Just as before, delword() didn't work. Chalk one up for MaxTADS.
> >
> >> MaxTADS is probably getting lucky. As far as I know, there's only one
> >> bug fixed in MaxTADS that's not fixed in the standard 2.2.1 distribution,
> >> and that wouldn't (as far as I can tell) affect delword().
> >
> >Correct.

> Could it be a 16 bit versus 32 bit integer issue? What size ints are
> being used in MaxTADS?

32-bit ints in MaxTADS.

I think it's time for me to ask, "what *is* the delword() bug, specifically?"

And what versions of the TADS runtime has it been observed in? All the
Unix ports use 32-bit ints, I assume. For the IBM, there are both 16-bit
and 32-bit versions right? (Or am I confusing address width with int
width?)

Neil K. Guy

unread,
Nov 10, 1996, 3:00:00 AM11/10/96
to

Andrew Plotkin (erky...@netcom.com) wrote:

: I think it's time for me to ask, "what *is* the delword() bug, specifically?"

A word added to the games vocabulary using addword() remains in the
vocabulary after an undo command. The undo command is supposed to undo
*everything*, including words added using addword().

: And what versions of the TADS runtime has it been observed in? All the


: Unix ports use 32-bit ints, I assume. For the IBM, there are both 16-bit
: and 32-bit versions right? (Or am I confusing address width with int
: width?)

I've only noticed the problem in the TADS Runtime for Macintosh, and
I've never heard it mentioned for any other version of TADS. Which leads
me to suspect it might have something to do with the general flakiness of
THINK C at times. (it was compiled using THINK C 5.x)

Andrew Plotkin

unread,
Nov 11, 1996, 3:00:00 AM11/11/96
to

Neil K. Guy (n...@vcn.bc.ca) wrote:
> Andrew Plotkin (erky...@netcom.com) wrote:
> : David Baggett (d...@xbar.ai.mit.edu) wrote:
> : > >I tested the fragment using the 2.2.1 runtime which recently appeared @
> : > >gmd.de. Just as before, delword() didn't work. Chalk one up for MaxTADS.

> : > MaxTADS is probably getting lucky. As far as I know, there's only one
> : > bug fixed in MaxTADS that's not fixed in the standard 2.2.1 distribution,
> : > and that wouldn't (as far as I can tell) affect delword().

> : Correct.

> Well if MaxTADS is simply getting lucky, it's pretty damned lucky,

> because there's another TADS parser bug that MaxTADS seems immune to.
> This is a highly obscure bug that throws the parser into an infinite loop
> in both TADS Runtime for Macintosh and tadsr for SGI-IRIX. But it works
> just fine in MaxTADS.

> For those interested, the bug is this. Let's say I have a word which is
> defined as both an adjective and a noun - the example that I first
> encountered is the word "body." Now use this word as an adjective, and
> put the word "of" between it and the noun to which the adjective belongs.
> Does that make sense? The phrase that causes this problem in the Mac and
> IRIX ports of TADS is "large body of water." If you refer to the object
> as "large body water" it's fine. Or "large of water". However the parser
> goes into a loop trying to use the word as an adjective - try typing this
> noun phrase into an affected TADS with the debug trace mode on and you'll
> see where it loops.

> I've looked at the source, and it seems to be getting stuck at the point
> where Mike Roberts modified the parser to accept the word "of" as a
> preposition, not just a special word. But I really have no clue what's
> going on beyond this. I've mentioned this to him, but I thought I'd throw
> it out here as well since the discussion was on weird bugs that MaxTADS
> seems above.

If this is the section of code I'm thinking of, this may very well be
fixed by Dave Baggett's one-line fix in VOCAB.C.

The lines 1232 - 1251 in VOCAB.C seem to deal with "of".

The three lines immediately following this section check for plurals. In
older TADS source, it looked like this:

if (typelist[cur] & VOCT_PLURAL)
found_plural = TRUE;
}

In Dave's TADS source, it's changed to

if (cmd[cur] && (typelist[cur] & VOCT_PLURAL))
found_plural = TRUE;
}

with a comment saying that the old code could run off the end of the word
list.

Since this is right next to the "of" section, you could have found
another incarnation of the same bug.

Andrew Plotkin

unread,
Nov 11, 1996, 3:00:00 AM11/11/96
to

Neil K. Guy (n...@vcn.bc.ca) wrote:
> Andrew Plotkin (erky...@netcom.com) wrote:
> : > A word added to the games vocabulary using addword() remains in the
> : > vocabulary after an undo command. The undo command is supposed to undo
> : > *everything*, including words added using addword().

> : Oh, happy bouncy joy. (Do you mean "addword" or "delword"?)

> Sorry; I meant addword there, and I really just gave an example of a
> bigger problem.

> The problem is referred to as the delword() problem because, well,
> delword() doesn't seem to work at all. When you use TADS runtime for
> Macintosh you can't delete a word - whether it was added using addword(),
> whether you undo a move or whether it was a word set up as part of the
> original dictionary. I've just compiled the gold skull game with a few
> bits of code to call addword() and delword(); MaxTADS runs it without
> incident, but Mac runtime can't delete any word.

Hm. Well, I still have a copy of Think C 5 lying around; maybe I'll build
TR and see what the deal is.

> : (A little suggestion,
> : boys and girls. If you ever want to design an undo system for a virtual
> : machine, the Z-machine's is a *hell* of a lot easier to write and
> : maintain than TADS's.)

> Is that because of the complexity of TADS or because TADS supports
> multi-level undos whereas the Z-machine doesn't?

The former. (I still hold that the Z-machine is compatible with multiple
undo, if the interpreter wants to support it, which some do.)

TADS stores undo information for every change to the game state. Object
changes, added words, deleted words, etc, etc, all these little packets
of information.

The Z-machine doesn't even know what objects the game file *contains*. It
stores undo information by dumping its entire memory out into a spare
buffer. Cheap, stupid, takes a lot of memory *unless* you use a
differential scheme such as Zip2000 uses, in which case it's quite
efficient. And it's impossible to have "a delword bug"; either memory is
saved correctly, or it's trash and the interpreter crashes.

Neil K. Guy

unread,
Nov 11, 1996, 3:00:00 AM11/11/96
to

Andrew Plotkin (erky...@netcom.com) wrote:
: > A word added to the games vocabulary using addword() remains in the
: > vocabulary after an undo command. The undo command is supposed to undo
: > *everything*, including words added using addword().

: Oh, happy bouncy joy. (Do you mean "addword" or "delword"?)

Sorry; I meant addword there, and I really just gave an example of a
bigger problem.

The problem is referred to as the delword() problem because, well,
delword() doesn't seem to work at all. When you use TADS runtime for
Macintosh you can't delete a word - whether it was added using addword(),
whether you undo a move or whether it was a word set up as part of the
original dictionary. I've just compiled the gold skull game with a few
bits of code to call addword() and delword(); MaxTADS runs it without
incident, but Mac runtime can't delete any word.

: I can't see anything obviously unreliable in the source code. But in no
: sense am I claiming to understand what's going on. (A little suggestion,

: boys and girls. If you ever want to design an undo system for a virtual
: machine, the Z-machine's is a *hell* of a lot easier to write and
: maintain than TADS's.)

Is that because of the complexity of TADS or because TADS supports
multi-level undos whereas the Z-machine doesn't?

- Neil K.

Andrew Plotkin

unread,
Nov 11, 1996, 3:00:00 AM11/11/96
to

Neil K. Guy (n...@vcn.bc.ca) wrote:
> Andrew Plotkin (erky...@netcom.com) wrote:

> : I think it's time for me to ask, "what *is* the delword() bug, specifically?"

> A word added to the games vocabulary using addword() remains in the

> vocabulary after an undo command. The undo command is supposed to undo
> *everything*, including words added using addword().

Oh, happy bouncy joy. (Do you mean "addword" or "delword"?)

I can't see anything obviously unreliable in the source code. But in no

sense am I claiming to understand what's going on. (A little suggestion,
boys and girls. If you ever want to design an undo system for a virtual
machine, the Z-machine's is a *hell* of a lot easier to write and
maintain than TADS's.)

--Z

Neil K. Guy

unread,
Nov 11, 1996, 3:00:00 AM11/11/96
to

Andrew Plotkin (erky...@netcom.com) wrote:

: If this is the section of code I'm thinking of, this may very well be

: fixed by Dave Baggett's one-line fix in VOCAB.C.

: [...]

: Since this is right next to the "of" section, you could have found

: another incarnation of the same bug.

Hm. I've recompiled TADS Runtime for Mac using THINK C 5.0.2 and
incorporating Dave's patch to vocab.c, and so far I haven't been able to
replicate the bug. I hope that's the fix.

Matthew T. Russotto

unread,
Nov 11, 1996, 3:00:00 AM11/11/96
to

In article <566gi3$o...@milo.vcn.bc.ca>, Neil K. Guy <n...@vcn.bc.ca> wrote:

} Is that because of the complexity of TADS or because TADS supports
}multi-level undos whereas the Z-machine doesn't?

Multi-level undos on the Z-machine are trivial to implement (if you
don't mind sucking up memory like it's free), so it has to be the
complexity of TADS. But TADS supports dynamic memory, right? So the
simple Z-machine method wouldn't work.

--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."

Greg Falcon

unread,
Nov 12, 1996, 3:00:00 AM11/12/96
to

************
*DISCLAIMER*
************
This message is extremely long. Stop now if you're not interested in
technical aspects of the Z-machine.

erky...@netcom.com (Andrew Plotkin) wrote:

>The former. (I still hold that the Z-machine is compatible with multiple
>undo, if the interpreter wants to support it, which some do.)

THAT'S IT! (I remember there was some thread I was involved in when I
was making my first appearances here that I dropped out of before
making a final case. It was on this topic. Thanks for bringing it
back up.)

I disagree with you here, and I will make my case starting with
excerpts from the spec.

6.1 The "state of play" is defined as the following: the contents of
dynamic memory; the contents of the stack; the value of the
program counter (PC), and the "routine call state" (that is, the
chain of routines which have called each other in sequence, and
the values of their local variables). Note that the routine call
state, the stack and the PC must be stored outside the Z-machine
memory map, in the interpreter's private memory.

6.1.1.2 An internal saved game for "undo" purposes (if there is one)
is not part of the state of play. This is important: if a
saved game file also contained the internal saved game at the
time of saving, it would be impossible to undo the act of
restoration. It also prevents internal saved games from
growing larger and larger as they include their predecessors.

6.1.2 On a "restore" or "undo" (which restores a game saved into
internal memory), the entire state of play is written back
except for one bit: bit 0 of `Flags 2' in the header, the flag
revealing whether the game is being transcribed to printer.

restore undo EXT:266 A 5 restore_undo <result>
Like restore, but restores the state saved to memory by
save_undo. (The optional parameters of restore may not

be supplied.) The behaviour of restore_undo is
unspecified if no save_undo has previously occurred
(and a game may not legally use it): an interpreter
might simply ignore this.
save undo EXT:265 9 5 save_undo <result>
Like save, except that the optional parameters may not
be specified: it saves the game into a cache of memory

held by the interpreter. If the interpreter is unable
to provide this feature, it must return -1: otherwise
it returns the save return value. (This call is
typically needed once per turn, in order to implement
"UNDO", so it needs to be quick.)


For an interpreter to support multiple undos while still following
this spec, it would need to provide secondary caches of memory. After
the second @save_undo, the cache from the first @save_undo would have
to be written to a secondary cache. (I am aware that there are many
ways an interpreter might implement this cache. I am not arguing
about how it is to be implemented; I am only interested in the end
result.)

I don't argue that an interpreter shouldn't have a "secondary cache",
as I have chosen to call it. An interpreter should be allowed to
store whatever it wants into in its own private memory. I'm sure we
can agree on this.

My argument is that there is no "legal" way for the Z-Machine itself
to access what is in this secondary cache. (Another clarification: I
am not even considering the behavior of the UNDO verb in a game right
now. A program is expected to do some homework before calling
@restore_undo, clearly. I am only discussing the behavior of the
Z-Machine opcodes.)

Say two @save_undo's have been called. You would agree with me that
the first @restore_undo would restore the state of the last called
@save_undo. However, IMO, a second @restore_undo would not restore
the first @save_undo state.

@restore_undo does a very simple task. Everything in the undo cache
(except the transcription bit) is loaded back into place. This
includes dynamic memory, the stack, the program counter, etc... but
NOT the internal save cache. This is spelled out clearly in 6.1.1.2.
For multiple undos to be supported at the Z-Machine level, there would
have to be some mechanism to change what's in the cache. However,
there is only ONE opcode that can write anything to this cache, and
that is @save_undo. @restore_undo by definition only loads what is in
the undo cache back into memory. Since the undo cache does not hold
any undo cache information (6.1.1.2.), it is inconsistant with the
spec to expect @restore_undo to leave the state of play and undo cache
in a condition to allow a second undo.

I'm going to write a program to test out how the Infocom's
interpreters would handle this. As I write this paragraph, the
program hasn't been written yet. I have no idea what the result will
be, but I will report it no matter what the result is. (How
scientific. ;-)

This program is written in Inform's z-assembly (for the most part),
and is therefore a little long. As a technical side question (for
those who are still reading this ;-), was is the proper syntax for
@jump in Inform? I couldn't figure it out, and finally resorted to
using Inform's own "jump"... sorry about that.

!For use in Inform 6 or greater...
[ main f x;
@store f 'A';
.start;
@print "Undo Test^
Current value of F is ";
@print_char f;
@print ".^
Menu options:^
1) Set new value of F^
2) Call @@064save_undo^
3) Call @@064restore_undo^
4) Exit^^
Your choice?";
.inputloop;
@read_char 1 -> x;
@sub x 48 -> x;
@jg x 4 ?inputloop;
@jg 1 x ?inputloop;
@je x 4 ?finished;
@je x 1 ?isone;
@je x 2 ?istwo;
@je x 3 ?isthree;
jump start;

.isone;
@print "Set new value^^
New character?";
@read_char 1 -> f;
@print_char f;
@print "^^";
jump start;

.istwo;
@print "Call @@064save_undo^^
Attempting save...";
@save_undo -> x;
@jg 1 x ?usfailed;
@je 1 x ?ussucc;
@print "@@064restore_undo succeeded.^^";
jump start;

.usfailed;
@print "@@064save_undo failed.^^";
jump start;

.ussucc;
@print "@@064save_undo succeeded.^^";
jump start;

.isthree;
@print "Call @@064restore_undo^^
Attempting restore...";
@restore_undo -> x;
@print "@@064restore_undo failed.^^";
jump start;

.finished;
@print "Exit^^";
@quit;
];

I have just run this program using Frotz and Infocom's DOS Beyond Zork
interpreter, and they both agree with me. @restore_undo does NOT
change the undo cache. If a second @restore_undo is called before a
@save_undo can change the cache, it succeeds... and loads the cache
that was written by the last @save_undo.

Of course, transcripting cannot be accessed in my program, and I'm not
good enough yet with z-machine language to add that feature easily.
(Read as: Too lazy to RTFM.) However, here is what happened when I
ran this program... brought to you by cut-and-paste.


Undo Test
Current value of F is A
<Menu options snipped>
Your choice?Call @restore_undo

Attempting save...@restore_undo failed.

Undo Test
Current value of F is A.
<snipped>
Your choice?Call @save_undo

Attempting save...@save_undo succeeded.

Undo Test
Current value of F is A.
<snipped>
Your choice?Set new value

New character?B

Undo Test
Current value of F is B.
<snipped>
Your choice?Call @save_undo

Attempting save...@save_undo succeeded.

Undo Test
Current value of F is B
<snipped>
Your choice?Set new value

New character?C

Undo Test
Current value of F is C
<snipped>
Your choice?Call @restore_undo

Attempting restore...@restore_undo succeeded.

Undo Test
Current value of F is B.
<snipped>
Your choice?Call @restore_undo

Attempting restore...@restore_undo succeeded.

Undo Test
Current value of F is B.
<snipped>
Your choice?Exit


See my point? The first @restore_undo failed, as the cache was empty.
The third succeeded, as the cache still had contents in it from the
LATEST @save_undo, which held the game state in which f='B'.

I don't disagree with your philosophy about how multiple undos could
be handled. However, the 0.2 spec does not support your philosophy,
IMO.

(I think we need to work on making a 1.0 spec, myself. Your
philosophy could be easily added to the spec without altering the way
any current z-files are interpreted... we could have @restore_undo
revert the cache if possible, and empty it if not.)

Note that the first call to @restore_undo in my program should cause
an "unspecified" result, according to the spec. I propose in 1.0 that
calling @restore_undo while the cache was empty will always cause
@restore_undo to return 0.

That's enough for one post. Awaiting your reply.

Greg (out of breath)
---
___ ___ ___ ___ Greg Falcon (professo...@pnx.com)
/ __\ / __\ / __\ / __\
( ( ( ( ( ( ( ( MEMBER S.S.S.S.
\ \ \ \ \ \ \ \ (Society to Stop Sizeable .SIGs)
\ \ \ \ \ \ \ \
___) ) ___) ) ___) ) ___) ) (With heartfelt apologies to people with
\___/ * \___/ * \___/ * \___/ * proportional fonts or no sense of humor)


Andrew Plotkin

unread,
Nov 12, 1996, 3:00:00 AM11/12/96
to

Matthew T. Russotto (russ...@wanda.vf.pond.com) wrote:
> In article <566gi3$o...@milo.vcn.bc.ca>, Neil K. Guy <n...@vcn.bc.ca> wrote:

> } Is that because of the complexity of TADS or because TADS supports
> }multi-level undos whereas the Z-machine doesn't?

> Multi-level undos on the Z-machine are trivial to implement (if you
> don't mind sucking up memory like it's free), so it has to be the
> complexity of TADS. But TADS supports dynamic memory, right? So the
> simple Z-machine method wouldn't work.

It's not dynamic memory specifically, it's that TADS doesn't run in a
flat memory space.

(The Great IF Machine of the Future will support both dynamic memory and
trivial undo.)

Andrew Plotkin

unread,
Nov 13, 1996, 3:00:00 AM11/13/96
to

I'm going to delete all your hard work and just say...

Greg Falcon (professo...@pnx.com) wrote:
> (I think we need to work on making a 1.0 spec, myself. Your
> philosophy could be easily added to the spec without altering the way
> any current z-files are interpreted... we could have @restore_undo
> revert the cache if possible, and empty it if not.)

Yeah. The spec is our spec, not *the* Z-machine in any sense. (Your
investigation into how Infocom's interpreters work *is*, in quite an
important sense.)

My original contention (boiled down through the whole discussion last
time) was that it is not against the spirit of @restore_undo for
@restore_undo to revert the cache one stage.

Greg Falcon

unread,
Nov 13, 1996, 3:00:00 AM11/13/96
to

erky...@netcom.com (Andrew Plotkin) wrote:

>I'm going to delete all your hard work and just say...

It's not work unless someone makes you do it. ;-)

>Greg Falcon (professo...@pnx.com) wrote:
>> (I think we need to work on making a 1.0 spec, myself. Your
>> philosophy could be easily added to the spec without altering the way
>> any current z-files are interpreted... we could have @restore_undo
>> revert the cache if possible, and empty it if not.)

>Yeah. The spec is our spec, not *the* Z-machine in any sense. (Your


>investigation into how Infocom's interpreters work *is*, in quite an
>important sense.)

My investigation into how Infocom's interpreters work is WHAT?
(Sorry, I just woke up, and I'm a little lost.)

>My original contention (boiled down through the whole discussion last
>time) was that it is not against the spirit of @restore_undo for
>@restore_undo to revert the cache one stage.

Perhaps not against the spirit, but against the spec rules. You said
in a previous message (in some thread about TADS) that the Z-machine
is compatible with these undos if an interpreter wants to support it.

To me, "the Z-machine" means whatever is in the latest spec. (Or you
could use it to mean an Infocom-written interpreter... but I prefer
the former definition.) The big deal about the Z-machine is that "any
legal program exactly determines it's behavior". If you want to write
an interpreter that reverts the cache, fine and well... but then you
would be lying to call it a "0.2 standard interpreter".

My $0.02
Greg

PS. If my logic is flawed, it's because I just woke up. I'll read it
later and see.

Andrew Plotkin

unread,
Nov 13, 1996, 3:00:00 AM11/13/96
to

Greg Falcon (professo...@pnx.com) wrote:
> >Yeah. The spec is our spec, not *the* Z-machine in any sense. (Your
> >investigation into how Infocom's interpreters work *is*, in quite an
> >important sense.)

> My investigation into how Infocom's interpreters work is WHAT?
> (Sorry, I just woke up, and I'm a little lost.)

Is an investigation into *the* Z-machine. (Not definitively, but
significantly.)

> >My original contention (boiled down through the whole discussion last
> >time) was that it is not against the spirit of @restore_undo for
> >@restore_undo to revert the cache one stage.

> Perhaps not against the spirit, but against the spec rules. You said
> in a previous message (in some thread about TADS) that the Z-machine
> is compatible with these undos if an interpreter wants to support it.

> To me, "the Z-machine" means whatever is in the latest spec.

I think the latest spec is incomplete. To you, that's a meaningless
statement. Fortunately this doesn't bother me epistemologically.

:-)

Also, none of my interpreters are compliant with Z-spec 0.2...

Matthew T. Russotto

unread,
Nov 13, 1996, 3:00:00 AM11/13/96
to

In article <erkyrathE...@netcom.com>,

Andrew Plotkin <erky...@netcom.com> wrote:
}I'm going to delete all your hard work and just say...
}
}Greg Falcon (professo...@pnx.com) wrote:
}> (I think we need to work on making a 1.0 spec, myself. Your
}> philosophy could be easily added to the spec without altering the way
}> any current z-files are interpreted... we could have @restore_undo
}> revert the cache if possible, and empty it if not.)
}
}Yeah. The spec is our spec, not *the* Z-machine in any sense. (Your
}investigation into how Infocom's interpreters work *is*, in quite an
}important sense.)
}
}My original contention (boiled down through the whole discussion last
}time) was that it is not against the spirit of @restore_undo for
}@restore_undo to revert the cache one stage.

Agreed, but the Inform library has code preventing this from working.
Infocom games work fine, however.

Reply all
Reply to author
Forward
0 new messages