Announcing Inform 6
Graham Nelson
Announcing Inform 6
===================
Today is Inform's third birthday. Inform 5 has been the current version for
the last two of those years, with the last update being Inform 5.5, released
in June 1995. Every release of Inform before now has been incrementally built
from the very first, Inform 1.
Inform 6 represents a "second generation": entirely rewritten, it works in
fundamentally different ways (for example, it is a one-pass backpatching
compiler, not a two-pass assembling one). Designing a second compiler as
efficiently as possible around the existing language, having learned the
lessons of the first, has made major improvements possible:
Inform 6 is 2.5 to 3 times faster than Inform 5.
Inform 6 allocates about 100K less memory than Inform 5.
Inform 6 generates about 5% more compact code than Inform 5 (though
it stores much more information about classes, so the net effect
on story file size may only be about a 2% reduction).
A linker is included, making it possible to pre-compile sections of code
and "link" them into the game being compiled. (In particular,
using a precompiled copy of the Inform library makes compiling a
small game about 10 times faster than using Inform 5 would have been;
even for a medium-sized game like "Advent", 6 times faster.)
Full object orientation is now provided, with instance variables
(i.e. an unlimited number of properties without need of declaration),
message sending (with parameters), encapsulation, access to
superclasses, instance creation, deletion and copying, etc.
Compound constants (such as "5*MAX_TOKENS - 1") are now allowed wherever
a constant would normally be expected (for example, as an array size).
Expressions can be used as conditions, and conditions and assignments
can be used as expressions.
Hanging elses are correctly handled.
A new front-end layer, including "ICL", a control language for multiple
compilations and elaborate memory settings using preference files;
and better file-naming conventions, with new path variables.
A rewritten assembler, up to date with the most recent Z-machine
archaeological research and allowing assembly of new "customised"
opcodes.
Many annoying restrictions have been removed (e.g., only being able to
use "or" with == and ~= and only for up to 3 values; only being able
to apply ++ and -- to global and local variables; only being able
to use "objectloop" with a narrow range of possibilities).
Much cleaner, totally overhauled source code, heavily annotated with
comments and greatly simplified, and supplied with a thorough
Technical Manual documenting in some detail how it all works.
In addition, Inform 6 comes with a new release of the library, release 6/1.
This is extremely similar in use to release 5/12, but (in order to make it
possible to use it in either standard or precompiled forms) is now divided into
7 instead of just 3 files. These files are:
parser.h verblib.h grammar.h
parserm.h verblibm.h
linklv.h linklpa.h
and all are text files. (As usual, a file called "changes" lists alterations
made to the library.)
And there is also a draft document describing the whole language: not
describing how to use the library and write games, because that's the task of
the Designer's Manual, but describing how to program in Inform. (The new
Programmer's Manual document is a draft which will probably replace the existing
Chapter V in the Designer's Manual in due course.) Most people seem to feel
that the existing manuals are too unsympathetic towards beginners who have
little programming experience; this new draft may help. I would be very
pleased to hear reactions and suggestions.
Finally, there is a fuller version of this release note, detailing the changes
made: obviously this was too long to post to rec.arts.int-fiction.
Note that the main thing I am releasing now is the source code to the new
Inform: there will be some delay before usable ports of it become available.
In the mean time, I suppose anyone eager enough can at least look at the
new programmer's manual. Note also that the present state is very much a
"beta-testing" release: when it does arrive for your machine, don't throw away
your copy of Inform 5.5 (if you have one) just yet.
The source code is divided among some 21 files. Details of this, and of how
to port it to a new machine, can be found in the Technical Manual.
The files which make up this release are all now at the
incoming/if-archive
directory at ftp.gmd.de. Since there would be many individual files to deal
with, some are grouped together into "tar" archives. Firstly,
inform6_source.tar
is such an archive, containing the 21 files
arrays asm bpatch directs errors expressc
expressp files inform lexer linker memory
objects states symbols syntax tables text
veneer verbs header
Of these, "header" is an include file and should probably be unpacked as
a file called "header.h"; the rest should probably be unpacked as "whatever.c".
A second archive, called
inform6_library.tar
contains the 7 library files mentioned above, plus the "changes" file.
The remaining files are:
inform6_release_note.txt [a fuller version of this posting]
inform6_technical_manual.txt [the Technical Manual, which includes
instructions on how to port the code]
inform6_programmers_manual.txt [the new draft manual on how to write
programs in Inform 6]
and, for my fellow Acorn users only,
inform6_riscos_port.spk [the Acorn RISC OS port of Inform 6, set
up and ready for use, including the
library; this needs only an interpreter
to be provided.
The file is a SparkFS archive, readable
with the public-domain utility SparkPlug.]
inform6_riscos_source.spk [an Acorn SparkFS archive of the source]
I wish to thank the very many people who contacted me at the consultation
stage for Inform 6, when I canvassed views on rec.arts.int-fiction as to
what users would most like to see in Inform 6. Not everybody's wish could
be included: for instance, I eventually decided that list-processing and
exception-handling systems would be better left to library extension files,
if anyone thought them worth implementing. Inform is already a very big
programming language: C++ has 48 reserved words, but Inform 6 has 161
(278 if you include Inform assembly-language). Some other wishes were set
aside because they were really requests to change the library suite (e.g.,
could doors open automatically?) rather than the compiler itself.
I must also thank porters in advance for the evenings of trouble this posting
is probably going to cause them: we will be fixing bugs in the new compiler
for a while yet, but it will be worth it.
Graham Nelson
author of Inform, April 30th 1993 - April 30th 1996
Kenneth Fair
Yippee! My fangs are already slavering...
--
KEN FAIR - U. Chicago Law | Power Mac! | Net since '90 | Net.cop
kjf...@midway.uchicago.edu | CABAL(tm) Member | I'm w/in McQ - R U?
The Internet was not created for companies to make money from.
George Caswell
On 29 Apr 1996, Graham Nelson wrote:
>
> Announcing Inform 6
> ===================
>
> Today is Inform's third birthday. Inform 5 has been the current version for
> the last two of those years, with the last update being Inform 5.5, released
> in June 1995. Every release of Inform before now has been incrementally built
> from the very first, Inform 1.
>
...
>
> Note that the main thing I am releasing now is the source code to the new
> Inform: there will be some delay before usable ports of it become available.
> In the mean time, I suppose anyone eager enough can at least look at the
> new programmer's manual. Note also that the present state is very much a
> "beta-testing" release: when it does arrive for your machine, don't throw away
> your copy of Inform 5.5 (if you have one) just yet.
>
I just wanted to mention that I sat down and in about 20 minutes
compiled the inform6 source on my linux box... nice work. (The compile
time wasn't 20 minutes-- that was the time it took for me to fix
DEFINEs, change filenames, and compile the source manually without a
Makefile...) I think you need to add #define STANDARD_DIRECTORIES to the
#ifdef LINUX section... I did, anyway... other than that (And the lack
of a Makefile) it's a straightforward build.
...Just thought I'd mention that, 's nice to know that, even after a
complete overhaul in beta, it still compiles pretty nicely...
....T...I...M...B...U...K...T...U... ____________________________________
.________________ _/>_ _______......[George Caswell, CS '99. 4 more info ]
<___ ___________// __/<___ /......[http://the-eye.res.wpi.edu/~timbuktu]
...//.<>._____..<_ >./ ____/.......[Member LnL+SOMA, sometimes artist, ]
..//./>./ /.__/ /./ <___________.[writer,builder.sysadmin of the-eye ]
.//.</.</</</.<_ _/.<_____________/.[____________________________________]
</.............</...................
Stephen van Egmond
If anyone is working on the Amiga port, please contact me. Else, I'm
going to spend a little while moving it into SAS/C.
Kenneth Fair
Just a question on this: Is anyone working on a Mac port, and if so, how
long should I expect to have to wait?
Huh? Huh? Drool slaver drool.
--
KEN FAIR - U. Chicago Law | Power Mac! | Net since '90 | Net.cop
kjf...@midway.uchicago.edu | CABAL(tm) Member | I'm w/in McQ - R U?
"You're fooling yourself. We're living in a dictatorship, a
self-perpetuating autocracy..." - Dennis
DarkWolf
Hi, on 29 Apr 96 08:59:15 GMT, Graham Nelson (nel...@vax.oxford.ac.uk) wrote:
> Announcing Inform 6
> ===================
Cool, only prob is I'm having trouble compiling on my Amiga. It could be
because I have little knowledge of C :) I set the #define to AMIGA and
created a makefile, but when running smake (using Sas/C compiler) I get a
bunch of warnings and it finaly stops alltogether :( If any Amiga dudes
have sucesfully compiled this, please uuencode the executables for me, it
would really make my day :)
Thanks,
Patrick
Robert A. Pelak
In article <kjfair-2904...@uchinews.uchicago.edu>,
Kenneth Fair <kjf...@midway.uchicago.edu> wrote:
>Just a question on this: Is anyone working on a Mac port, and if so, how
>long should I expect to have to wait?
>
>Huh? Huh? Drool slaver drool.
>
I hope to have a minimal ugly command driven version out in the next
few days; an honest Mac OS port will take some time longer, but be
patient, it will happen.
Matthew Amster-Burton
nel...@vax.oxford.ac.uk (Graham Nelson) wrote:
> Announcing Inform 6
> ===================
Well, this sounds like a good opportunity for a confirmed TADS-er to
play with Inform a bit. Unfortunately, unpacking the tar files
results in a bunch of files with no ".c" or ".h" extensions. I took
educated guesses, but still couldn't get inform.c to compile.
If anyone has tips for compiling under Linux or DOS (DJGPPv2), I'd
appreciate it. Or I could just wait for precompiled binaries to
appear, I suppose.
Thanks,
Matthew
Kenneth Fair
In article <4m53e3$7...@newsstand.cit.cornell.edu>,
pe...@hannah.msc.cornell.edu (Robert A. Pelak) wrote:
>I hope to have a minimal ugly command driven version out in the next
>few days; an honest Mac OS port will take some time longer, but be
>patient, it will happen.
Gratias agimus tibi propter magnam gloriam tuam.
(We thank you for your great glory.)
Stephen van Egmond
In article <4m43sr$b...@raven.eva.net>,
DarkWolf <dark...@bighorn.accessnv.com> wrote:
>Cool, only prob is I'm having trouble compiling on my Amiga. It could be
>because I have little knowledge of C :) I set the #define to AMIGA and
>created a makefile, but when running smake (using Sas/C compiler) I get a
>bunch of warnings and it finaly stops alltogether :( If any Amiga dudes
>have sucesfully compiled this, please uuencode the executables for me, it
>would really make my day :)
It's uploaded.
The problem is in header.h.... the definitions of int32 need to be moved
above the OS-opecific IFDEFs. I have found that limits.h had to be
#included since the uint32 code assumes that the OS code sets the ranges.
George Caswell
On Tue, 30 Apr 1996, Matthew Amster-Burton wrote:
> nel...@vax.oxford.ac.uk (Graham Nelson) wrote:
>
> Well, this sounds like a good opportunity for a confirmed TADS-er to
> play with Inform a bit. Unfortunately, unpacking the tar files
> results in a bunch of files with no ".c" or ".h" extensions. I took
> educated guesses, but still couldn't get inform.c to compile.
>
There's only one header file- header.h <g> You can find the header
filenames by grepping through the C files. Pretty much everything that's
not a header file is a C file.
> If anyone has tips for compiling under Linux or DOS (DJGPPv2), I'd
> appreciate it. Or I could just wait for precompiled binaries to
> appear, I suppose.
>
I can tell you exactly what needs to be done to compile under Linux--
edit header.h. Near the beginning there's a #define ARCHIMEDES or
somesuch. Change it to LINUX. At this point my compile still failed-
if yours does too you also need to go to the section of header.h that
starts with #ifdef LINUX and add, inside the block, a
#define STANDARD_DIRECTORIES. From there it should be a straightforward
compile-- I'd recommend either making a makefile or using syntax like
gcc -c -o arrays.o arrays.c for each c file, then linking...
I don't know about DOS. I never got DJGPP working..
Even the losers get lucky
In article <4m5s3d$2...@nntp4.u.washington.edu>,
Matthew Amster-Burton <mam...@u.washington.edu> wrote:
>nel...@vax.oxford.ac.uk (Graham Nelson) wrote:
>
>> ===================
>
>Well, this sounds like a good opportunity for a confirmed TADS-er to
>play with Inform a bit. Unfortunately, unpacking the tar files
>results in a bunch of files with no ".c" or ".h" extensions. I took
>educated guesses, but still couldn't get inform.c to compile.
>
>appreciate it. Or I could just wait for precompiled binaries to
>appear, I suppose.
>
On the subject of ports, let me share my experience (so far :) with
porting Inform 6. [Note to Graham: a more complete report will be sent
to you via email sometime shortly. Certain problems will be omitted here
so I don't end up making a fool of myself.]
There are a couple of syntax errors in the header.h file (just header in
the .tar archive). I have them written down, but no line numbers. At
any rate, if you end up with a 'duplicate label' or 'type mismatch' error
for a function or it's parameters), check the header file. I noticed a
couple of places where types weren't matching (i.e. 'int' instead of
'int32'). While on some machines this won't matter because int32 is
typecast to an int (32 bit integers would be nice, eh?), my machine uses
16-bit ints, and thus the discrepancy (en example is with
assemble_label_no() from (I think?) symbol.c (like I said, I just made
brief notes). There's also at least one spot where an opening brace '{'
was missing.
Anyways, after a long, hard battle with both my machine and it's compiler
(let's just say some aspects of the architecture of the Apple IIGS aren't
very porter friendly), I managed to dredge up a working executable.
Here's where my question to other porters comes in:
Have you managed to compile a simple program (say, shell.inf), and run it
with an interpreter (say jzip) an have all turn out well? I can't quite
get it to run right, and chances are it's my machine and the compiler
mucking up Graham's beautiful code -- I'd like to take this moment to
thank Graham for writing such truly wonderful, well-comment and very
well-organized code that made hacking it up a pleasure :)
Also, I made modules out of Parser and Verblib, and upon trying to
compile with the -U option I get an error regarding "NO_PLACES" (no such
variable or something, I'll hack around and give a better report if I
can't fix it). Do I need to include linklpa.h and linklv.h myself, or
are they already included?
I've rambled plenty already. It's great to see a new version of inform
with all sorts of new goodies, and it'll be even better once I've managed
to beat the square peg into the round hole and get everything working :)
--
|Evan Day | "You can go out and destroy what's already spent
| da...@peak.org | You can blame on your hat the thoughts in your head
|"Redneckers, they get us| Archer of Loaf
| pissed" - Black Francis| They've got the guns but we've got the numbers.
Robert A. Pelak
In article <4m73fu$d...@peak.org>,
Even the losers get lucky <da...@PEAK.ORG> wrote:
>In article <4m5s3d$2...@nntp4.u.washington.edu>,
>
>Have you managed to compile a simple program (say, shell.inf), and run it
>with an interpreter (say jzip) an have all turn out well? I can't quite
>get it to run right, and chances are it's my machine and the compiler
>mucking up Graham's beautiful code -- I'd like to take this moment to
>thank Graham for writing such truly wonderful, well-comment and very
>well-organized code that made hacking it up a pleasure :)
>
So far my attempts at a Macintosh port have not succeeded. I compiled
Inform with only minor changes, but it crashes when I try to compile
with it. For both hellow.inf and a very short program I wrote (two
rooms, an object, and inclusion of the libraries), Inform seems to
reach the end of all of the files before it has trouble. In the first
case, the system simply crashes; the later presents me with a long
series of "veneer errors." Note, I built Inform using 4 byte
integers and recompiled the ANSI library accordingly. I still have a
large number of things to try, including studying the source code. :)
My experience has been that the Mac port has been a bit more difficult
than some of the others. Has anyone managed to compile it under DOS
yet?
Robert
Graham Nelson
In article <4m5s3d$2...@nntp4.u.washington.edu>, mam...@u.washington.edu (Matthew Amster-Burton) writes:
> nel...@vax.oxford.ac.uk (Graham Nelson) wrote:
>
>> Announcing Inform 6
>> ===================
>
> Well, this sounds like a good opportunity for a confirmed TADS-er to
> play with Inform a bit. Unfortunately, unpacking the tar files
> results in a bunch of files with no ".c" or ".h" extensions. I took
> educated guesses, but still couldn't get inform.c to compile.
>
> If anyone has tips for compiling under Linux or DOS (DJGPPv2), I'd
> appreciate it. Or I could just wait for precompiled binaries to
> appear, I suppose.
>
> Matthew
>
>
header is a header file (hence, "header.h") and all the rest are ".c",
as I think is mentioned within them. In any case, the technical manual
contains very full details on how to compile Inform, including a list
of all the source files and what they do.
Graham Nelson
Damien Neil
On 1 May 1996 00:22:38 -0700, Even the losers get lucky <da...@PEAK.ORG> wrote:
>There are a couple of syntax errors in the header.h file (just header in
>the .tar archive). I have them written down, but no line numbers.
Compiling under Linux, I recall running into only one problem: a
preprocessor constant needs to be defined for the default directory
to place ICL files. (This is with a system type of `UNIX' defined,
not `LINUX'; I see absolutely no reason to treat Linux systems as
different from other Unices.)
>Have you managed to compile a simple program (say, shell.inf), and run it
>with an interpreter (say jzip) an have all turn out well? I can't quite
>get it to run right, and chances are it's my machine and the compiler
>mucking up Graham's beautiful code -- I'd like to take this moment to
>thank Graham for writing such truly wonderful, well-comment and very
>well-organized code that made hacking it up a pleasure :)
Yes.
There seem to be some noticable bugs, however. I haven't had the
opportunity yet to delve deeply into the exact nature and cause
of the problem; when I have something more specific, I'll compile
a bug report for Graham.
I'd like to verify that the problems are real, and not an mistake
in compilation on my part. Code such as:
Nearby thing "thing"
with name 'random' 'thing' ! <- Note lack of ,
description "A random thing";
causes Inform to die with a segmentation fault for me. Does the
same happen for anyone else?
>Also, I made modules out of Parser and Verblib, and upon trying to
>compile with the -U option I get an error regarding "NO_PLACES" (no such
>variable or something, I'll hack around and give a better report if I
>can't fix it). Do I need to include linklpa.h and linklv.h myself, or
>are they already included?
Compiling modules does not seem to work for me; I can compile ParserM.h
and VerblibM.h into ParserM.m5 and Verblib.m5, but the compiled versions
appear not to contain all the code they should. (Functions, for one,
seem to be noticably absent.)
>I've rambled plenty already. It's great to see a new version of inform
>with all sorts of new goodies, and it'll be even better once I've managed
>to beat the square peg into the round hole and get everything working :)
Hear, hear! :>
I especially love the technical manual. The writing style in it is
beautiful (as we have come to expect from Graham :>). I don't think
I've ever read a more entertaining description of the internals of
a program.
If only I could document all my own code as well...
- Damien
Robert Masenten
There seems to be a typo in objects.c, line 828 [in properties_segment]:
if ((token_type ==SYMBOL_TT) && (stypes[i]==PROPERTY_T))
The local variable i isn't used anywhere else in the routine, and, in
particular, is never given a value so stypes[i] points to a random location
in memeory; under Linux, at least, this gives a segmentation fault.
I *think* what needs to be done is to change i to i_m, so the line becomes
if ((token_type==SYMBOL_TT) && (stypes[i_m]==PROPERTY_T))
At least this seems to fix the problem (Graham?).
Robert Masenten
Robert Masenten
Robert Masenten <mase...@hans.math.upenn.edu> wrote:
>There seems to be a typo in objects.c, line 828 [in properties_segment]:
<Sigh> Sorry; I misread my own notes. I *meant* to write that the
reference to i should be replaced by token_value, not i_m, so the
corrected line should be
if ((token_type==SYMBOL_TT) && (stypes[token_value]==PROPERTY_T))
at least as far as I can tell. (Graham?)
Robert Masenten
Alexander Lehmann
Damien Neil (ne...@godzilla.jpl.nasa.gov) wrote:
: On 1 May 1996 00:22:38 -0700, Even the losers get lucky <da...@PEAK.ORG> wrote:
: >There are a couple of syntax errors in the header.h file (just header in
: >the .tar archive). I have them written down, but no line numbers.
: Compiling under Linux, I recall running into only one problem: a
: preprocessor constant needs to be defined for the default directory
: to place ICL files. (This is with a system type of `UNIX' defined,
: not `LINUX'; I see absolutely no reason to treat Linux systems as
: different from other Unices.)
In fact, the only real difference between LINUX and UNIX in the setup is the
lack of the INCLUDE_TASK_ID flag, which means that Linux may get problems
if more than one user uses Inform at once. The only other thing is the
presence of the USE_TEMPORARY_FILES flag in UNIX, which isn't really necessary.
: Compiling modules does not seem to work for me; I can compile ParserM.h
: and VerblibM.h into ParserM.m5 and Verblib.m5, but the compiled versions
: appear not to contain all the code they should. (Functions, for one,
: seem to be noticably absent.)
Yes, I noticed that too.
There seems to be a bit of a problem with upper/lowercase letters in the
filename, since (if I remember correctly) Acron doesn't distinguish between
upper/lower case, this only becomes apparent in the unix version. The
Files in the tar are all lowercase, which can be changed easily, however,
there is an inconsistency in the naming the the VerbLib files. The file is
included as VerbLib in e.g. shell.inf, the file itself then includes the
M file as VerblibM, which is a bit confusing. If VerbLib is used in other
files also, then the M file should be changed to that casing also, I guess.
bye, Alexander
--
Alexander Lehmann, | "On the Internet,
al...@hal.rhein-main.de (plain, MIME, NeXT) | nobody knows
alex...@rbg.informatik.th-darmstadt.de (plain) | you're a dog."
<URL:http://www.student.informatik.th-darmstadt.de/~alexlehm/>
DarkWolf
To whoever ported Inform6 to the Amiga, thanks. I was haveing no luck
porting it :)
Patrick
bonni mierzejewska
On 2 May 1996 04:20:55 GMT, pe...@hannah.msc.cornell.edu (Robert A. Pelak)
wrote:
> ... Has anyone managed to compile it under DOS
>yet?
I've heard that it's been compiled with DJGPP. I've been trying all
morning to get it to compile. The C files will compile to objects -
without warnings, even - but I get linker errors: I think I'm missing out
a library or two.
I can likewise compile the C files to objects with the Borland C command
line compilers, but they will not link. I get two errors from the linker,
that segments _TEXT and DGROUP exceed 64K.
I have been able to compile and link Inform 6 under Linux. It seems to
run okay, but when I try to compile Balances with it, I get segmentation
faults. Hmm. Actually, it would be interesting to know what people have
been managing to compile and/or link and on what platform, and what .inf
files the resulting Inform executable will compile.
I have a Linux executable I'm willing to make available, compiled with GCC
2.7.0 under Linux 1.2.13, but I suspect the Linux folks out there are
perfectly capable of getting it to compile themselves.
bonni
coming soon - 1996 IF Competition entry
__ __
IC | XC | bonni mierzejewska "The Lone Quilter"
---+--- | u6...@wvnvm.wvnet.edu
NI | KA | Kelly's Creek Homestead, Maidsville, WV
Stephen van Egmond
I was unable to do very extensive testing, since I don't have much Inform
source. I received a litany of errors when I tried to compile
magic-toyshop.inf, but I suspect that was because the version of the code
I was using was using withdrawn directives and statements.
I did manage to compile the portion of "through the looking glass" that
was posted on Gareth's home page without difficulty or warnings.
How did I do this?
I found that header.h was making a few assumptions that caused trouble:
int32 wasn't defined before the OS-dependent IFDEFs were compiled. This
was required since (for me) the Amiga IFDEF had a function that returned
int32.
More seriously, I think that there is an IFDEF (within the Amiga code,
not sure about others) that refers to INFORM_FILE that brackets the
function returning int32 referred to above (specifically, the function
that returns a magic "temporary" number based on the process ID used for
temp files or something). This should be MAIN_INFORM_FILE (or whatever
is defined at the top of inform.c).
I think that is the extent of significant problems I found.
Oh, yes, I had to include limits.h (ANSI) for the benefit of the int32
IFDEFs. Those ingenious comparisons make use of DEFINEs from limits.h.
The tacit assumption was that the OS-dependent IFDEFs would find those
constants at some point.
/Steve
Uncle Bob
Damien Neil (ne...@godzilla.jpl.nasa.gov) wrote:
: Nearby thing "thing"
: with name 'random' 'thing' ! <- Note lack of ,
: description "A random thing";
:
: causes Inform to die with a segmentation fault for me. Does the
: same happen for anyone else?
I've fixed this and am corresponding with Graham on it. As soon as I get
a reply, I'll be uploading provisional binaries for both Linux (static
linked) and for 386+ PCs (with djgpp). I have these built but I want to
do a little more testing.
A "generic" PC port looks very problematical at this time. I have a
clean compile and a sort-of clean load, but significant run-time
problems. Is anyone desperate for this port?
Bob N.
--
--------------------------------------------------------------------
Home Page: http://www.btigate.com/~bnewell
E-Mail : bne...@btigate.com
BBS : GobblerNet BBS 701 222 0429
Graham Nelson
exciting corrections made!
Graham
Graham Nelson
In article <4maoo9$4...@netnews.upenn.edu>, mase...@hans.math.upenn.edu (Robert Masenten) writes:
> There seems to be a typo in objects.c, line 828 [in properties_segment]:
>
>
> The local variable i isn't used anywhere else in the routine, and, in
> particular, is never given a value so stypes[i] points to a random location
> in memeory; under Linux, at least, this gives a segmentation fault.
> I *think* what needs to be done is to change i to i_m, so the line becomes
>
> if ((token_type==SYMBOL_TT) && (stypes[i_m]==PROPERTY_T))
>
> At least this seems to fix the problem (Graham?).
>
> Robert Masenten
>
This is correct. The bug is fixed in v6.02. Thanks,
Graham