[Inform] Inform 6.3 second beta
Cedric Knight
suggestions from the first beta version of the new Inform release.
Unfortunately not all the suggestions could be incorporated in this
version, but they have been considered for future development.
There's now an updated beta, again with numerous small fixes. The new
warning messages should now only indicate genuine problems unless you
are doing something unorthodox or outside normal IF usage. If you can,
please consider testing this software to destruction or subjecting it to
extreme conditions...
You can download library 6/11 beta2 and compiler 6.30 beta2 from
http://www.inform-fiction.org/inform63/
and the release notes are at
http://www.inform-fiction.org/inform63/RelNotes.pdf
Have fun
Kevin Bracey
Neil Cerutti
David Cornelson
Michael Coyne
Roger Firth
Jim Fisher
Dave Griffith
Andrew Hunter
David Kinder
Cedric Knight
Joe Mason
Graham Nelson
Jason Penney
Andrew Plotkin
Gunther Schmidl
Emily Short
Seebs
Cedric Knight <ckn...@gn.babpbc.removeallBstosend.org> wrote:
>Many thanks to everyone who sent or posted bug reports, comments or
>suggestions from the first beta version of the new Inform release.
>Unfortunately not all the suggestions could be incorporated in this
>version, but they have been considered for future development.
>
>There's now an updated beta, again with numerous small fixes. The new
>warning messages should now only indicate genuine problems unless you
>are doing something unorthodox or outside normal IF usage. If you can,
>please consider testing this software to destruction or subjecting it to
>extreme conditions...
So, I tried the first version, and I was very confused, because I'm
used to the "unix inform" package which installs the library and does
everything else like that... I had problems which may have been with
my installation, but I wasn't sure how to debug them.
Is there a quickie install guide to be had for people used to one of
the pre-packaged setups?
-s
--
Copyright 2004, all wrongs reversed. Peter Seebach / se...@plethora.net
http://www.seebs.net/log/ - YA blog. http://www.seebs.net/ - homepage.
C/Unix wizard, pro-commerce radical, spam fighter. Boycott Spamazon!
Consulting, computers, web hosting, and shell access: http://www.plethora.net/
Seebs
Cedric Knight <ckn...@gn.babpbc.removeallBstosend.org> wrote:
>warning messages should now only indicate genuine problems unless you
>are doing something unorthodox or outside normal IF usage. If you can,
>please consider testing this software to destruction or subjecting it to
>extreme conditions...
Help!
Array inputscratch table 60;
[ FakeInput str i j k;
@output_stream - 1;
@output_stream 3 inputscratch;
print (string) str;
@output_stream 1;
@output_stream - 3;
style bold;
for (i = 2 : i <= inputscratch-->0 + 1 : ++i) {
j = 3 + random(7);
if ( ~~k)
@read_char 1 j AlwaysTrue->k;
print (char) inputscratch->i;
}
j = 3 + random(7);
@read_char 1 j AlwaysTrue->j;
style roman;
print "^";
];
This worked with 6.21. 6.3 complains, reasonably, that "inputscratch->i" is
trying to treat a table as a string.
If I try to make inputscratch a string, it doesn't work because output_stream
wants a table.
If I use inputscratch-->i, I get:
[** Programming error: tried to print (char) 26996, which is not
a valid ZSCII character code for output **]
What should I be doing here?
(The goal is to print a string one character at a time.)
Note that 26996 looks very much like two adjacent characters from the
string; it looks like this is now writing two characters at a time into the
table; does that mean I'm supposed to be manually or'ing them out?
John Menichelli
Try changing
Array inputscratch table 60;
to
Array inputscratch buffer 60;
Seebs
John Menichelli <meni...@cox.net> wrote:
>Just a guess...
>
>Try changing
>
> Array inputscratch table 60;
>
>to
>
> Array inputscratch buffer 60;
No luck. Same thing I get with 'string' - nothing shows up at all.
I'm pretty sure it needs to be a table-structured array, because the library
is writing into it two bytes of length, followed by however many bytes, but
it's writing the bytes individually. So, for instance, the string "foo"
would be written as
0 3 f o o
with the first two bytes being the length... Hmm. Ah-hah! If I'm willing
to simply assert that I'll never use this for anything over 255 characters,
which I already did by limiting the array to 60 items (which allowed for
up to 118 chars before, but I never use more than about 40), I can use
inputscratch->1 as the LSB of the length, and that's plenty. YAY!
Roger Firth
news:400e0bc1$0$431$3c09...@news.plethora.net...
> In article <WamPb.7659$bg1.1417@fed1read05>,
> John Menichelli <meni...@cox.net> wrote:
> >Just a guess...
> >
> >Try changing
> >
> > Array inputscratch table 60;
> >
> >to
> >
> > Array inputscratch buffer 60;
>
> No luck. Same thing I get with 'string' - nothing shows up at all.
> I'm pretty sure it needs to be a table-structured array, because the
library
> is writing into it two bytes of length, followed by however many bytes,
but
> it's writing the bytes individually. So, for instance, the string "foo"
> would be written as
> 0 3 f o o
> with the first two bytes being the length... Hmm. Ah-hah! If I'm
willing
> to simply assert that I'll never use this for anything over 255
characters,
> which I already did by limiting the array to 60 items (which allowed for
> up to 118 chars before, but I never use more than about 40), I can use
> inputscratch->1 as the LSB of the length, and that's plenty. YAY!
No, UnYAY! You're kludging round the problem without understanding it,
and one day that'll come back to bite you. The fix, as John says, is to
declare inputscratch as a buffer. This slightly simplified example works
ok for me:
Constant SCRATCHSIZE 60;
Array inputscratch buffer SCRATCHSIZE;
[ FakeInput str i;
@output_stream 3 inputscratch;
print (string) str;
@output_stream -3;
if (inputscratch-->0 > SCRATCHSIZE) "Error: buffer overflow!";
style bold;
for (i=0 : i < inputscratch-->0 : i++)
print (char) inputscratch->(i+WORDSIZE);
style roman;
print "^";
];
Cheers, Roger
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
You'll find my Cloak of Darkness, Parsifal, Informary
and more at http://www.firthworks.com/roger/
Seebs
Roger Firth <ro...@firthworks.com> wrote:
>No, UnYAY! You're kludging round the problem without understanding it,
>and one day that'll come back to bite you. The fix, as John says, is to
>declare inputscratch as a buffer. This slightly simplified example works
>ok for me:
This contradicts my reading of the DM4, which says that inputscratch should
be a table, not a buffer.
>Constant SCRATCHSIZE 60;
>Array inputscratch buffer SCRATCHSIZE;
>[ FakeInput str i;
> @output_stream 3 inputscratch;
> print (string) str;
> @output_stream -3;
> if (inputscratch-->0 > SCRATCHSIZE) "Error: buffer overflow!";
> style bold;
> for (i=0 : i < inputscratch-->0 : i++)
> print (char) inputscratch->(i+WORDSIZE);
> style roman;
> print "^";
>];
Hmm. So, I get a warning for doing -> on a table, but there's no warning
for doing --> on a buffer? I just assumed I was obliged to access it only
in the way I declared it.
Anyway, I like this better than mine, simply because it's more trustworthy;
in particular, it seems likely to survive glulx.
I didn't know there was a constant WORDSIZE; is this one of those subtleties
I missed, or is this new in 6.3/6.11?
Seebs
Roger Firth <ro...@firthworks.com> wrote:
> @output_stream 3 inputscratch;
> print (string) str;
> @output_stream -3;
> if (inputscratch-->0 > SCRATCHSIZE) "Error: buffer overflow!";
> style bold;
> for (i=0 : i < inputscratch-->0 : i++)
> print (char) inputscratch->(i+WORDSIZE);
> style roman;
> print "^";
>];
So, this highlights another quirk.
My loop has:
for (...) {
j = N;
if (~~k)
@read_char 1 j AlwaysTrue -> k;
}
If I understand this correctly, it should pause each iteration for N 10ths
of a second, until the user hits a key.
In fact, what it seems to do is only pause the first time; the variable 'k'
is now getting a 63 stored in it, which is a '?', even if the user hits no
key.
This is a change from the DM4 behavior, which says that you should get a 0
if the user hits no key.
I've tested with
k = 0;
@read_char 1 j AlwaysTrue -> k;
print "k: ", k, ".^";
and I keep getting
k: 63
Is that an actual bug?
Cedric Knight
> In article <WamPb.7659$bg1.1417@fed1read05>,
> John Menichelli <meni...@cox.net> wrote:
>> Just a guess...
>>
>> Try changing
>>
>> Array inputscratch table 60;
>>
>> to
>>
>> Array inputscratch buffer 60;
>
> No luck. Same thing I get with 'string' - nothing shows up at all.
Your routine works fine for me, whether with Array inputscratch 'table',
'string', or 'buffer', except that the first two give compiler warnings
like you say.
> I'm pretty sure it needs to be a table-structured array, because the
> library is writing into it two bytes of length, followed by however
> many bytes, but it's writing the bytes individually.
To be clear, it's the Z-machine itself rather than the library that
records the length of the @output_stream. What you're describing is in
fact the new 'buffer' structure introduced in Inform 6.30: one word
giving the number of characters, then that number of characters as
bytes. 'Tables' only consist of words. E.g.:
Array inputscratch table "restart"
is stored as hex:
00 07 00 72 00 65 00 73 00 74 00 61 00 72 00 74
Array inputscratch buffer "restart"
is stored as
00 07 72 65 73 74 61 72 74
This is the format used by @output_stream 3,
str.print_to_array(inputscratch), or the new PrintToBuffer(inputscratch,
40, str).
Array inputscratch string "restart"
is stored as
07 72 65 73 74 61 72 74
For Glulx, each occurrence of '00' becomes '00 00 00'.
Hoping that doesn't make things even more confusing.
CK
Roger Firth
> In article <bulfvp$jdj9v$1...@ID-62041.news.uni-berlin.de>,
> Roger Firth <ro...@firthworks.com> wrote:
> >No, UnYAY! You're kludging round the problem without understanding it,
> >and one day that'll come back to bite you. The fix, as John says, is to
> >declare inputscratch as a buffer. This slightly simplified example works
> >ok for me:
>
> This contradicts my reading of the DM4, which says that inputscratch
should
> be a table, not a buffer.
'Array MYNAME buffer' is new in the 6.3 compiler, so the DM4 hasn't
anything to say about it. The purpose of the 'buffer' declaration is to
create an initial word followed by N bytes, ideally suited for
print-to-array functionality, and accessible without the warning (which
is also new in 6.3).
All this is described in the Release Notes.
> Hmm. So, I get a warning for doing -> on a table, but there's no warning
> for doing --> on a buffer? I just assumed I was obliged to access it only
> in the way I declared it.
You get a warning for -> on a table array, and for --> on a string array.
> I didn't know there was a constant WORDSIZE; is this one of those
subtleties
> I missed, or is this new in 6.3/6.11?
In Glulx it's always been there, but it's new to the Z-machine compiler.
Again, please read the Release Notes.
Roger Firth
> So, this highlights another quirk.
>
> My loop has:
> for (...) {
> j = N;
> if (~~k)
> @read_char 1 j AlwaysTrue -> k;
> }
>
> If I understand this correctly, it should pause each iteration for N 10ths
> of a second, until the user hits a key.
>
> In fact, what it seems to do is only pause the first time; the variable
'k'
> is now getting a 63 stored in it, which is a '?', even if the user hits no
> key.
>
> This is a change from the DM4 behavior, which says that you should get a 0
> if the user hits no key.
[ AlwaysTrue; ];
for (i=0 : i<10 : i++) {
j = 20;
@read_char 1 j AlwaysTrue->k;
print k, " ";
}
This prints the value of the key pressed, or 0 after 2 seconds.
Seems fine to me.
David Kinder
> is now getting a 63 stored in it, which is a '?', even if the user hits no
> key.
That sounds like an interpreter problem, not a compiler problem.
In fact, I dimly remember there was a mistake like that in an early version
of Windows Frotz 2002. Which interpreter are you using? If WF2002, are you
using the latest release (1.04)?
David
David Kinder
"David Kinder" <d.ki...@btinternetspamnothankyou.com> wrote in message news:bumhlv$qfl$1...@titan.btinternet.com...
David Kinder
in WF2002 1.02. Link to latest version:
http://mirror.ifarchive.org/if-archive/infocom/interpreters/frotz/WindowsFrotz2002.zip
David
Seebs
Unix frotz 2.43.
I believe it worked with the inform 6.21 compiles of Janitor. (I'm redoing
the thing that does fake user input.)
Seebs
Seebs <se...@plethora.net> wrote:
>In article <bumhlv$qfl$1...@titan.btinternet.com>,
>David Kinder <d.ki...@btinternetspamnothankyou.com> wrote:
>>> In fact, what it seems to do is only pause the first time; the variable 'k'
>>> is now getting a 63 stored in it, which is a '?', even if the user hits no
>>> key.
>>
>>That sounds like an interpreter problem, not a compiler problem.
>>
>>In fact, I dimly remember there was a mistake like that in an early version
>>of Windows Frotz 2002. Which interpreter are you using? If WF2002, are you
>>using the latest release (1.04)?
>
>Unix frotz 2.43.
>
>I believe it worked with the inform 6.21 compiles of Janitor. (I'm redoing
>the thing that does fake user input.)
Found it. Could well be the same kind of bug; translate_to_zscii() turns
0 into ?; this is commented as a sanity check for unicode.
David Kinder
> 0 into ?; this is commented as a sanity check for unicode.
Yep, that's the one: definitely an interpreter issue.
David
Seebs
Yay! All better, except that the current release of Janitor won't fill
out a line if you type '?' while it's pretending to receive input from another
player. It's a tolerable workaround for my purposes, and there'll be a patch
soonish for Unix frotz.