Inform 6.12 source released
Graham Nelson
Inform 6.12 now released
========================
Both the Inform compiler and library are now due for updated releases,
but I'm doing this in two stages, compiler today. The changes consist
of a fair number of worthwhile bug fixes, plus support for non-ASCII
character sets and provisional support for the Infix debugger (which
a highly secret cabal of authors is currently plotting over). To
be more exact:
-------------------------------------------------------------------------
Feature added:
A new switch, -C, and the ability to read source code files in any
ISO 8859 standard extension to the ASCII character set. The
default is ISO 8859-1, Latin1, the standard character set on
most computers in most European countries. This means that
many accented characters can simply be typed directly, a
particular advantage with exotic ISO ranges (Arabic, Hebrew,
Greek, Cyrillic, etc.). If your computer is unable to use any
of 8859-1 to -9, the -C0 switch (for plain ASCII only) can be
used. Accent markers such as '@:u' (for u-diaeresis) remain
valid, just as usual, but a new string escape '@{..hex number..}'
allows the specification of any Unicode character. For instance
'@{a9}' produces a copyright sign (Unicode values between $0000
and $00ff are equal to ISO Latin1 values), and '@{2657}' produces
in principle a White bishop chess symbol. In practice, if you
wish to use rare Unicode symbols, you'll need an interpreter
obeying the Z-Machine Standard 1.0, and you'll probably have
to supply it with an appropriate font as well; also, any characters
not normally resident in the Z-machine need to be declared in
advance of use with the "Zcharacter table" directive. But if
you're only using (e.g.) ordinary German, Spanish or French
accents the new facilities will work with any Standard 0.2
interpreter.
The "Zcharacter" directive, for configuring the Z-machine to
use non-English alphabets, is greatly enhanced.
(In the Z-machine, Inform now always generates a header extension
table, and sometimes uses a slot within it to point to a Unicode
translation table newly specified in Standard 1.0.)
The debugging information file has finally been brought up to date with
Inform 6, and old code inherited from Inform 5 (the only such
code in the whole compiler) has been cleaned out. The main change
is in producing source-code-to-PC-value maps, which is made more
difficult by the compression of code at the end of each routine.
The exact format will probably change: this release is an interim
one, to assist development of Infix.
The concept of sequence points has been introduced, to assist Infix.
Bugs fixed:
Not a bug as such, but the veneer implementation has been changed so that
class-objects never have attributes set. In 6.01 to 6.11, a class
object like Monster might have the attribute "animate" and would
therefore be picked up in objectloops over all animate objects, and
so on. This is undesirable, and illogical since after all class
objects don't provide any properties, so why have attributes?
Anyway, the result means that objectloops of the form
objectloop (x has <attribute>) ...
will now not range through classes but only genuine game objects.
When compound Boolean conditions are used as expressions (for instance,
in an assignment like "x = (y>1) || d;") the wrong answers could
result if the top operator was ||. (If it was &&, or if the
condition had no &&s or ||s in, or if the condition was being used
as a test rather than a numerical value, everything was normal.)
Fake actions being defined before grammar version is set were causing
mysterious problems. This would happen if the Fake_Action directive
were used before "Parser" is included. An error message has been
added advising that Fake_Action directives should be moved.
(Fake actions are now mostly obsolete anyway.)
Any attributes aliased together being given the unhelpful name
"<unknown attribute>" in output from the "showobj" debugging verb.
Backpatch *** errors *** sometimes being produced as a knock-on effect
from already-reported linkage errors. (These *** errors *** are
now suppressed if linkage has already broken down.)
The character codes for << and >> (Continental European quotation marks)
were the wrong way around, following a mistake in version 0.2 of
the Z-Machine Standards document. They have therefore been
swapped over, following the correction made in version 1.0 of that
document.
Accented characters deep inside dictionary words sometimes getting lost.
(Because of an ambiguity in the Standards document where Inform
made the wrong choice, but interpreters made the right one.)
The -w (suppress warnings) switch doing nothing. (In writing Inform 6
I simply forgot this.)
Source code cleaning:
A new UNIX64 port, for 64-bit Unix machines, added (courtesy of Magnus
Olsson) which should subtract pointers correctly even in the unlikely
event that they lie in different 2^32 byte pages. Otherwise identical
to UNIX.
And a new BEOS port added (courtesy of Michael van Biesbrouck) but which is
identical to the Linux one in all but name.
Link error message handling, and character error message handling,
slightly more automated.
The "Compiled with %d errors and %d warnings" message reworded so as not
to mention 0 of anything, and to indicate how many warnings were
suppressed (by the -q or -w switches).
The table of memory settings is now printed more prettily in response
to the ICL command $list.
A new memory setting, MAX_LABELS, has been added, along with error checking
to test for too many label points in any single routine.
Various functions to do with character set handling tidied up and moved
into the new section "chars.c".
-------------------------------------------------------------------------
As a temporary measure, you can get hold of the new material from the
Inform 6 Home Page:
http://www.gnelson.demon.co.uk/inform.html
Please note that there may be a delay of one to three days before
the new material becomes "visible" from your region of the Internet,
because of the regrettable way that my Internet service provider
organises its WWW space. The material will in any case be filed
in its proper place at ftp.gmd.de shortly.
My thanks, as ever, to those who have emailed me bug reports.
I am always grateful for these, though it can sometimes take me
a couple of weeks to reply when I have a serious email backlog,
for which I apologise. Please try to send me a short piece of
source code demonstrating what you think is wrong, if possible:
this saves on long explanations and makes it much easier for me
to find the problem.
Graham Nelson
26 March 1997
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom
Kathleen Fischer
Graham Nelson wrote:
> Not a bug as such, but the veneer implementation has been changed so that
> class-objects never have attributes set. In 6.01 to 6.11, a class
> object like Monster might have the attribute "animate" and would
> therefore be picked up in objectloops over all animate objects, and
> so on. This is undesirable, and illogical since after all class
> objects don't provide any properties, so why have attributes?
> Anyway, the result means that objectloops of the form
>
> objectloop (x has <attribute>) ...
>
> will now not range through classes but only genuine game objects.
Does this mean (like I think it does) that if I have
Class Birds (100)
has animate
and I have created just 3 birds in my game, objectloop will only pick up
those 3 and ignore the 97 uncreated birds? (please say yes, its a real
bummer the way it works now)
Kathleen (who is feeling rather dense today - which is to say things are
pretty much normal)
--
*******************************************************************
* Kathleen M. Fischer
* kfischer@x_greenhouse.llnl.gov (Remove the 'x_' before replying)
** "Don't stop to stomp ants while the elephants are stampeding" **
Graham Nelson
In article <333AA6BA.1CFB@x_greenhouse.llnl.gov>, Kathleen Fischer
<URL:mailto:kfischer@x_greenhouse.llnl.gov> wrote:
>
> Graham Nelson wrote:
> > Not a bug as such, but the veneer implementation has been changed so that
> > class-objects never have attributes set. In 6.01 to 6.11, a class
> > object like Monster might have the attribute "animate" and would
> > therefore be picked up in objectloops over all animate objects, and
> > so on. This is undesirable, and illogical since after all class
> > objects don't provide any properties, so why have attributes?
> > Anyway, the result means that objectloops of the form
> >
> > objectloop (x has <attribute>) ...
> >
> > will now not range through classes but only genuine game objects.
>
>
> Class Birds (100)
> has animate
>
> and I have created just 3 birds in my game, objectloop will only pick up
> those 3 and ignore the 97 uncreated birds? (please say yes, its a real
> bummer the way it works now)
I didn't mean that, but it's a very good idea. I'll certainly
consider it for the next release. At present, uncreated objects
are regarded as residing in a distant, unvisitable location.
BPD
Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>Inform 6.12 now released
<sigh> I wish that there was more of a possibility that someday I
will come across such an announcement for TADS 2.3...
BPD
Kathleen Fischer
Graham Nelson wrote:
> I didn't mean that, but it's a very good idea. I'll certainly
> consider it for the next release. At present, uncreated objects
> are regarded as residing in a distant, unvisitable location.
<from somewhere far far away, comes the mournful wail of a disillusioned
programmer>
Kathleen