The Inform Programming Language
NNelson334
Hello,
I was wondering if I could get a little advice here. Particularly from you,
Graham. I've been wondering recently, why one needs an interpreter to play
Inform games. I realize of course why an interpreter _is_ used, but why is one
_needed_? Why can't one code an interpreter in Inform? Why not a compiler for
that matter?
Well, I've gone and made a complete duplicate set of my entire C/C++
libraries, and am now slowly trying to port them to Inform. I doubt I'll
succeed, but I think it'd be a fun (i.e.: educational, interesting, perhaps)
exercise.
Any advice? Insight? Comments on my apparent over-abundancy of time on my
hands? (That isn't really true, but well, hmm.)
Thanks in advance.
Yours,
N. Nathanael
If you would like to e-mail a response, please use nne...@world-net.net.
Magnus Olsson
In article <19980213074...@ladder03.news.aol.com>,
NNelson334 <nnels...@aol.com> wrote:
> I was wondering if I could get a little advice here. Particularly from you,
>Graham. I've been wondering recently, why one needs an interpreter to play
>Inform games. I realize of course why an interpreter _is_ used, but why is one
>_needed_?
I suppose you mean: why doesn't the Inform compiler produce native
code, that can run directly on you machine, but rather Z-code, which
you need an interpreter to run?
This was really a design decision by Infocom, not by Graham (Graham
just followed in Infocom's footsteps). Infocom started out by porting
Zork to a lot of different home computers. Really different ones: not
just running different OS's, but on differrent hardware with different
processors and totally different instruction sets.
Now, Infocom didn't use Inform, but a language called ZIL, but the
same thing holds for both languages: it's much easier to write *one*
ZIL compiler that produces Z code, and then write a bunch of
interpreters for the different machines, than it is to write a whole
bunch of native-code-generating ZIL compilers. If you write a compiler
(for Inform, ZIL, C++ or whatever) that generates native code for a
PC, you have to rewrite a large portion of the compiler if you want it
to generate Macintosh native code instead.
It is much, much easier to write a Z-code interpreter which can be
re-compiled and ported for different machines (ask the people who've
ported Frotz to different platforms, for example).
And even if you *did* invest the time to write 69 different Infocm
compilers for every conceivable platform, you'd still have to
re-compile every single game for every platform.
Suppose that Infocom had 20 games (that's not the actual figure), and
wanted to sell them on 20 different platforms (again not the actual
figure). They'd have to choose between the following two approaches:
A: Write 20 ZIL-to-native-code compilers, one for each platform. Then
compile each of the 20 games with each compiler. This gives you 400
different game binaries.
B: Write *one* ZIL-to-Z-code compiler, and *one* interpreter which you
can port to 20 platforms. Then compile all the 20 games once. This
gives you 20 interpreter executables, and 20 game binaries. This is much,
much easier to handle.
Exactly the same thing holds for us amateurs and Inform.
>Why can't one code an interpreter in Inform? Why not a compiler for
>that matter?
You seem to confuse two issues here, or maybe I just don't understand
your question correctly. I'll try to answer it as it stands.
Yes, you can write an interpreter in Inform, but what's the point?
You'd still need another interpreter to run it, wouldn't you?
Writing a compiler in Inform would simply be difficult (and you might
run into trouble fitting it into the limited memory model of the
Z-machine). But it would be neat.
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------
Not officially connected to LU or LTH.
Gareth Rees
Magnus Olsson <m...@bartlet.df.lth.se> wrote:
> If you write a compiler (for Inform, ZIL, C++ or whatever) that
> generates native code for a PC, you have to rewrite a large portion of
> the compiler if you want it to generate Macintosh native code instead.
You could try a different strategy. Your Inform compiler outputs C
source code, which is then compiled on the platform (or cross-compiled)
to produce native code. (After all, you're exploiting the portability
of C to make Z-code interpreters easy to port.)
--
Gareth Rees
Paul F. Snively
In article <sihg63d...@cre.canon.co.uk>, Gareth Rees
<gar...@cre.canon.co.uk> wrote:
> You could try a different strategy. Your Inform compiler outputs C
> source code, which is then compiled on the platform (or cross-compiled)
> to produce native code. (After all, you're exploiting the portability
> of C to make Z-code interpreters easy to port.)
The problem with this idea is that not all hardware/OS combinations that
have a C compiler necessarily handle I/O in the same way--that is, there's
still porting work to be done once you have the C code, unless you just
blithely assume that the whole world at least has a text I/O console and
pray that, if they don't (e.g. Macintosh), the compiler and libraries will
provide one for you (e.g. CodeWarrior's SIOUX).
Or you can hope that Andrew Plotkin writes MaxZip...
> Gareth Rees
Paul Snively
Gareth Rees
Paul F. Snively <ch...@mcione.com> wrote:
> The problem with this idea is that not all hardware/OS combinations that
> have a C compiler necessarily handle I/O in the same way
When outputting the C code, of course you output whatever I/O code is
appropriate for the platform you're compiling for. Programming language
theorists will understand this as partial evaluation: the usual dataflow
Interpreter
source
|
C compiler
|
Inform source -> Inform -> Z-code -> Interpreter -> Result
runtime
is partially evaluated to become
Interpreter
source
|
Inform source -> "Native" -> C code -> C compiler -> Result
Inform
--
Gareth Rees
Matthew T. Russotto
}
} I was wondering if I could get a little advice here. Particularly from you,
}Graham. I've been wondering recently, why one needs an interpreter to play
}Inform games. I realize of course why an interpreter _is_ used, but why is one
}that matter?
Certainly an Inform->native compiler is possible... but it's a lot of
work for little gain in performance (on modern machines) and great
loss of portability.
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
NNelson334
Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>And even if you *did* invest the time to write 69 different Infocm
>compilers for every conceivable platform, you'd still have to
>re-compile every single game for every platform.
Well, not really. Not the way I'm thinking it could be done. Read on.
>Yes, you can write an interpreter in Inform, but what's the point?
I don't know what the point is. It'd just be neat.
>You'd still need another interpreter to run it, wouldn't you?
No. Not the way I'm thinking it could be done. Read on.
The Inform 6.14 compiler will compile any syntactically correct Inform code,
right?
Okay. I have the C source code for MaxZip. I also have the C source code
for the Inform 6.14 compiler. I also have a complete set of Apple and Symantec
standard C/C++ libraries, which I use when I compile the source for MaxZip or
Inform 6.14 on my platform.
Now, what if I successfully port my Apple and Symantec standard C libraries
to Inform, the C source code for MaxZip to Inform, and the C source code for
the Inform 6.14 compiler to Inform? (Yeah, I'd compile them with the currently
available C Inform 6.14 compiler, in case you're wondering.)
You'd still have the "one-compiled-game-compatible-with-all-interpreters"
situation. If everyone has an interpreter coded in Inform, and a compiler,
coded in Inform, then no one has to worry about porting the _games_. They
would still be written in Inform. The only trouble a person would have is
porting the Inform source code of the compiler and the interpreter to their
platform.
Sure it'd be tedious. And I'll probably just wind up with some inefficient
(?) programs. But I'd like to see it happen.
Does anyone have any ideas why it _wouldn't_ work? If it could work, would
it be innefficient? If so, why? Why couldn't Inform 7 be geared for
optimizing Inform stand-alones?
The only good reason I can come up with for doing any of this, is that one
could write stand-alone applications/executables/programs coded _entirely_ in
Inform. You can't do that currently, as far as I know. Everything written in
Inform requires some interpreter, written in C or something.
To be honest though, there isn't much of a point. All this work likely
wouldn't really be that useful. But it'd be fun. For me. Maybe. Heh.
Yours,
N. Nathanael
mailto:nne...@world-net.net
--
"If you ask the wrong questions you get answers like '42' or 'God'."
Paul F. Snively
In article <si1zx7c...@cre.canon.co.uk>, Gareth Rees
<gar...@cre.canon.co.uk> wrote:
Oh, sure, Gareth. First you invoke lambda on me, and now partial
evaluation! I now recognize the "secret handshake" of the Knights of the
Lambda Calculus, er... UK Chapter? :-)
I wonder if anyone has successfully created a self-applicable partial
evaluator for C as they have for Scheme (Similix, Schism...) I'm aware of
Tempo, but don't know offhand whether Tempo is self-applicable or not. I
very much doubt it--people would be developing X-to-C compilers left and
right with it otherwise!
(For the uninitiated, a self-applicable partial evaluator for language L
has the rather interesting property that, given an interpreter for source
language S written in L and itself as input, the output is an S-to-L
compiler. The proof is left as an exercise for the reader.)
In any event, I/O functions are typically among the class of functions that
partial evaluators don't treat, since they tend to be restricted to purely
functional subsets of the source language, and I/O is the one aspect of a
language that's generally not purely functional (and Gareth, don't you
start on monads or Concurrent Clean's uniqueness typing, OK?) ;-)
> Gareth Rees
Paul Snively
Patrick Kellum
In article <19980213222...@ladder02.news.aol.com>, NNelson334 was talking about:
> The only good reason I can come up with for doing any of this, is that one
>could write stand-alone applications/executables/programs coded _entirely_ in
>Inform. You can't do that currently, as far as I know. Everything written in
>Inform requires some interpreter, written in C or something.
Stand alone Inform games are already possable, check out JZip. Or am I
missing the point completly? (wouldn't be the first time :-)
Patrick
---
A Title For This Page -- http://www.syix.com/patrick/
Bow Wow Wow Fan Page -- http://www.syix.com/patrick/bowwowwow/
The Small Wonder Page -- http://smallwonder.simplenet.com/
My Arcade Page -- http://ygw.bohemianweb.com/arcade/
"I have photographs of you naked with a squirrel." - Dave Barry
Magnus Olsson
In article <sihg63d...@cre.canon.co.uk>,
Gareth Rees <gar...@cre.canon.co.uk> wrote:
>Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>> If you write a compiler (for Inform, ZIL, C++ or whatever) that
>> generates native code for a PC, you have to rewrite a large portion of
>> the compiler if you want it to generate Macintosh native code instead.
>
>source code, which is then compiled on the platform (or cross-compiled)
>to produce native code. (After all, you're exploiting the portability
>of C to make Z-code interpreters easy to port.)
This is a common strategy. Why didn't Infocom choose it in the early
80's? Simple: because they were targeting small home computers for
which no C compiler (or any other compiler, at least not one with a
standardized language) existed.
Why didn't Graham choose to follow the C-as-an-intermediate-language
strategy, then? Well, of course I can't speak for him, but IIRC he
started Inform specifically as a project to produce Z-code, because
that would be a cooltthing to do.
I still think the Z code route is better for adventure games.
When my game-i-progress, "Hemispheres", which I'm writing in Inform, is
finished, I will only have to release *one* version - the .z5 file.
Everybody with a Z-code interpreter will then be abel to play it.
If Inform had compiled to native code, I would have had to compile it
myself for every possible platform. Which would probably have meant
PC, Macintosh and Acorn - the smallish user base wouldn't have made
it worthwhile for me to compile it for, say Psions. No, I don't want
to release the source until people have played the game for quite
some time.
And if Inform had produced C, I would either have had to get C compilers
for a whole bunch of platforms, or release just the C code. In the
latter case, only the people with a C compiler would have been able
to play the game. People without would have to wait for somebody else
to port it. Messy.
Magnus Olsson
In article <19980213222...@ladder02.news.aol.com>,
>
> I don't know what the point is. It'd just be neat.
>
>>You'd still need another interpreter to run it, wouldn't you?
>
> No. Not the way I'm thinking it could be done. Read on.
>
> The Inform 6.14 compiler will compile any syntactically correct Inform code,
>right?
> Okay. I have the C source code for MaxZip. I also have the C source code
>for the Inform 6.14 compiler. I also have a complete set of Apple and Symantec
>standard C/C++ libraries, which I use when I compile the source for MaxZip or
>Inform 6.14 on my platform.
> Now, what if I successfully port my Apple and Symantec standard C libraries
>to Inform, the C source code for MaxZip to Inform, and the C source code for
>the Inform 6.14 compiler to Inform? (Yeah, I'd compile them with the currently
>available C Inform 6.14 compiler, in case you're wondering.)
To begin with, you *can't* port the standard C libraries to Inform, because
Inform has no low-level interface to OS functionality, the way the C library
has. Just one example: The C library has functions for checking and setting
such things as permissions and dates of files. These concepts simply
don't exist in Inform.
Of course, you could modify the Inform language so it included such
functionality (the modifications to the language itself could be quite
small). We would then have to modify the Z machine so that it included
such concepts (like the Java VM does). Or we could make the Inform
compiler emit native code, but then we're back at square one.
But I take it you're talking about Inform and the Z machine in their
current incarnations.
> You'd still have the "one-compiled-game-compatible-with-all-interpreters"
>situation. If everyone has an interpreter coded in Inform, and a compiler,
>coded in Inform, then no one has to worry about porting the _games_. They
>would still be written in Inform.
That is true. It is of course also true today.
> The only trouble a person would have is
>porting the Inform source code of the compiler and the interpreter to their
>platform.
In what way would this be different from porting the C code of the compiler
and the interpreter to their platform?
> Does anyone have any ideas why it _wouldn't_ work? If it could work, would
>it be innefficient? If so, why?
If I can follow your thoughts here, you are forgetting something quite basic:
As long as the Inform compiler emits Z code and not native code, an
interpreter written in Inform would be totally useless for your
purposes. Sure, you could compile it, but the result of the
compilation would be a Z code file. And to run a Z code file, you need
an interpreter. And you need an interpreter that actually runs on your
hardware. (Please don't say "but you can run the interpreter on
itself". You try that, then come back and tell us where the infinite
recursion bottomed out.)
> The only good reason I can come up with for doing any of this, is that one
>could write stand-alone applications/executables/programs coded _entirely_ in
>Inform. You can't do that currently, as far as I know. Everything written in
>Inform requires some interpreter, written in C or something.
Unless you can work magic, to run a program on your computer, you must either
* compile the program to your computer's native code
or
* have an interpreter (written in native code, or itself being
interpreted by an interpreter written in native code, and so on ad
nauseam) that can interpret the program.
You can't get around this. Either you make Inform output native code, and then
you lose portability, or you make it output Z-code (or something equivalent),
and then you need interpreters written in another language than Inform.
A practical note: if you don't mind limiting your audience, and if you
think requiring them to have a working interpreter is too much of a
hassle, then an alternative to native-code generation is this:
Some interpreters can be bound together with the Z-code file into one
(native) executable. For MS-DOS, use Jzip together with the jzexe
utility. For Macintosh, use MaxZip.
These bound executables can of course only be played on one
platform. But as the interpreter is included in the same file as the
Z-code, the user doesn't even notice that he's really using an
interpreter.
NNelson334
Patrick Kellum <pat...@syix.com> wrote:
>In article <19980213222...@ladder02.news.aol.com>, NNelson334 was
talking about:
>
> > The only good reason I can come up with for doing any of this, is that one
> >could write stand-alone applications/executables/programs coded _entirely_
in
> >Inform. You can't do that currently, as far as I know. Everything written
in
> >Inform requires some interpreter, written in C or something.
>
>missing the point completly? (wouldn't be the first time :-)
Well, kinda, yeah. My point is I want to make stand-alone programs coded
_entirely_ in Inform. For example, an Inform coded version of whatever program
that you are using to view this message.
As things are now, you can make a stand-alone Inform _game_, sure. But it's
coded in C if you're using MaxZip (and C for JZip too, I would assume).
If I can actually do what I want to do, then any stand-alone (DOS/UNIX
command line accessable, MacOS/Windows double-clickable) game, program
whatever, could be coded in Inform.
L. Ross Raszewski
In article <6c36v3$r53$1...@neko.syix.com>,
pat...@syix.com (Patrick Kellum) wrote:
>
> Stand alone Inform games are already possable, check out JZip. Or am I
> missing the point completly? (wouldn't be the first time :-)
>
>
jzip-built executable will only run on DOS/Windows systems. (without a DOS
emulator, but then it's just swapping one interpreter for another)
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
Brock Kevin Nambo
Magnus Olsson wrote in message <6c4bk3$g5l$1...@bartlet.df.lth.se>...
>(Please don't say "but you can run the interpreter on
>itself". You try that, then come back and tell us where the infinite
>recursion bottomed out.)
Well, it bottoms out at infinity.
After that, it starts running like mad!
>>BKNambo
--
http://come.to/brocks.place
Somebody loves you. (Not necessarily me.)
LRS
Magnus Olsson wrote in message <6c1e06$1vn$1...@bartlet.df.lth.se>...
>Suppose that Infocom had 20 games (that's not the actual figure), and
>wanted to sell them on 20 different platforms (again not the actual
>figure). They'd have to choose between the following two approaches:
>
>A: Write 20 ZIL-to-native-code compilers, one for each platform. Then
>compile each of the 20 games with each compiler. This gives you 400
>different game binaries.
>
>B: Write *one* ZIL-to-Z-code compiler, and *one* interpreter which you
>can port to 20 platforms. Then compile all the 20 games once. This
>gives you 20 interpreter executables, and 20 game binaries. This is much,
>much easier to handle.
Speaking as one who was there, I remember when the first Infocom games for
the Mac came out. I was amazed. At that point there were 5-10 games already
out for CP/M (8080/Z80), Atari 400/800, etc. So I wasn't overly surprised
when I first saw Zork I for the Mac. OK, they've ported it to the Mac (I
said to myself). And, not knowing how much effort it was to port these
games, I figured that Mac users, if they were lucky, would get another
Infocom game in, say, 6 months.
But then, over a small number of weeks, I saw Zork II. Then maybe Deadline.
And Starcross. And Zork III. And whatever. And I couldn't understand it. It
didn't make business sense to delay releasing games until all of them were
converted to run on the Mac. And it also didn't seem to make sense that
they'd have invested the money to hire programmers to port all of them
simultaneously.
Then the penny dropped. I finally put 2 and 2 together. I'd already realized
that Infocom had written one interpreter for CP/M, one for the Atari, etc,
and that now they'd simply written one for the Mac. Suddenly all the games
game along for free!
I actually did something like that myself. The 16 bit 8088 CPU (the one in
the earliest IBM PCs) was a lot like the 8-bit 8080 chip. So much so that
there was a program available at that time to take assembler source for the
8080 and mechanically convert it to 8088 assembler. The translator even did
it's best to convert operating system calls from CP/M to PCDOS.
Well, at one point I'd disassembled to CP/M interpreter and had a version of
the program I could compile cleanly. So I fed it through the translator, and
got a version of the interpreter that would work on PCDOS. Well, that didn't
prove too much since Infocom was already shipping DOS versions, with their
own interpreters.
(Hmmm. Interesting aside -- If you took the interpreter for, say, ZORK I
(ZORK1.COM), you'd find an ASCII string inside it for ZORK1.DAT. If you
patched ZORK1.COM to point to, say, DEADLINE.DAT, then by running ZORK1.COM
you'd run Deadline instead. Also note that this doesn't always work. For
example, A Mind Forever Voyaging, Trinity, Zork Zero, and others, use an
enhanced version of the interpreter. Patching ZORK1.COM to point to the
Trinity file wouldn't work. But I digress.)
But I then took the interpreter source (for 8088 PCDOS), and changed the
operating system calls in it. Digital Research, the company that wrote CP/M,
had come out with it's own 16 bit operating system called CP/M-86. This hung
around for a couple of years, but never really went anywhere (other than to
Novell, which is a good definition of going nowhere).
So now I had an interpreter that ran on a different operating system. I'm
perhaps the only one who's ever played Zork on CP/M-86!
And all because Infocom *didn't* compile their games directly into native
machine languages.
Larry Smith
l...@mail.execnet.com
Patrick Kellum
In article <19980214211...@ladder03.news.aol.com>, NNelson334 was talking about:
> Well, kinda, yeah. My point is I want to make stand-alone programs coded
>_entirely_ in Inform. For example, an Inform coded version of whatever program
>that you are using to view this message.
> As things are now, you can make a stand-alone Inform _game_, sure. But it's
>coded in C if you're using MaxZip (and C for JZip too, I would assume).
So you want to somehow get all machines to nativly run z-code? That's
like loading up a Nintendo rom file on my Amiga and expecting to play it.
Can't be done, I need an emulator for it (which, by the way is exactally
what a z-machine interpreter is, an emulator of a non-existant machine).
Writing the interpreter in z-code would acomplish nothing since you would
have nothing to run it with.
> If I can actually do what I want to do, then any stand-alone (DOS/UNIX
>command line accessable, MacOS/Windows double-clickable) game, program
>whatever, could be coded in Inform.
Already possable, on Amiga computers just install a program that acts on
whatever file is clicked on. For example, if I installed the program and
clicked on a z-code file it would intercept this and load the interpreter
first with the z-code file as a command line argument. Easy.
NNelson334
Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>If I can follow your thoughts here, you are forgetting something quite
>basic:
>
>As long as the Inform compiler emits Z code and not native code, an
>interpreter written in Inform would be totally useless for your
>purposes. Sure, you could compile it, but the result of the
>compilation would be a Z code file.
Ah. No wonder. I'm glad I only got through "stdlib.h", "size_t.h",
"wchar_t.h", "stdio.h" and "string.h".
So much for that idea.
Yours,
N. Nathanael
mailto:nne...@world-net.net
--
"A black hole is where God divides by zero."
NNelson334
Patrick Kellum <pat...@syix.com> wrote:
>Already possable, on Amiga computers just install a program that acts on
>whatever file is clicked on. For example, if I installed the program and
>clicked on a z-code file it would intercept this and load the interpreter
>first with the z-code file as a command line argument. Easy.
The Mac OS does this. So does Windows. It isn't the same thing that I
wanted to be able to do with Inform. A program in a file that only runs if you
open it with another program is not a stand-alone program. My reason for even
thinking about all this, was that I wanted to be able to use Inform in other
ways besides games.
I can use C++ to write the exact same games I write in Inform, _and_ create
my own "kool" user interface along the way. And once I get bored with that, I
can use C++ to write whatever else I want. True, I won't have the insto-matic
portability of z-code. Ah well. I guess I can't have it all.
I was trying to find a way around this, but I now have to understand that
Inform is not as powerful as C++, and never will be, because it is _completely_
dependant upon interpreters.
Yours,
N. Nathanael
mailto:nne...@world-net.net
--
"The three principal virtues of a programmer are Laziness, Impatience, and
Hubris."
-- Larry Wall <lw...@netlabs.com> in den Perl5-Manpages
Magnus Olsson
In article <19980215115...@ladder02.news.aol.com>,
NNelson334 <nnels...@aol.com> wrote:
> The Mac OS does this. So does Windows. It isn't the same thing that I
>wanted to be able to do with Inform. A program in a file that only runs if you
>open it with another program is not a stand-alone program.
That's right, and I agree with you that sometimes the need for an interpreter
is a hassle.
What do you think of binding an interpreter and a Z-code file into a standalone
executable, like jzexe does with Jzip?
>My reason for even
>thinking about all this, was that I wanted to be able to use Inform in other
>ways besides games.
Ah, I see. I don't think that's a very good idea, because, as you
write below, Inform isn't as powerful as (say) C++ for general-purpose
programming.
> I can use C++ to write the exact same games I write in Inform,
Yes, apart from the fact that you'll have to duplicate the effort Graham
has put into the Inform libraries, and that (at least IMHO) the syntax of
C++ is more cumbersome than that of Inform *for creating text games*.
>_and_ create
>my own "kool" user interface along the way.
If you want something really new in the interface department, then you must
use a language that gives you full access to Windows (or whatever GUI you're
using), that's correct.
> And once I get bored with that, I
>can use C++ to write whatever else I want.
It seems very important for you that you should only have to learn
*one* language. For my part, I see the need to learn a new langauge as
an opportunity to broaden my mind. (Thelast sentence was not intended
as any criticism of you, just an observation).
> I was trying to find a way around this, but I now have to understand that
>Inform is not as powerful as C++, and never will be, because it is _completely_
>dependant upon interpreters.
That's not quite true. Java is also dependent on interpreters (until
Java chips become widespread), but these interpreters are designed to
give Java the same kind of power as C++.
What really limits Inform's power is not that it is dependant on
interpreters, it's that the virtual machine emulated by these
interpreters (i.e. the Z machine) is rather limited. The Z machine has
severe memory limitations, a limited I/O model, limited windowing
support, and so on.
It is possible to extend the Z machine to make Inform more
powerful. Whether it's worth doing it is another question.
Magnus Olsson
In article <6c5ua5$eji$1...@neko.syix.com>,
Patrick Kellum <pat...@syix.com> wrote:
>In article <19980214211...@ladder03.news.aol.com>, NNelson334
>was talking about:
> >command line accessable, MacOS/Windows double-clickable) game, program
> >whatever, could be coded in Inform.
>
>whatever file is clicked on. For example, if I installed the program and
>clicked on a z-code file it would intercept this and load the interpreter
>first with the z-code file as a command line argument. Easy.
The same thing is possible on Macs and Windows machines (on Windows,
for example, associate the extensions .z3, .z5 and .z5 with WinFrotz).
However, you still have to install the interpreter, and that's what
NNelson wants to get rid of. Which he can't of course.
However, there will probably be a way out in a few years: Write an
<insert language of your choice here> compiler that generates Java
byte code. You'll still need an interpreter, of course, but the point
is that in a few years, most computers will probably come with a
Java interpreter out of the box.
But - this is a *vision*, some people would say hype. Nobody knows
for sure if and when Java will take off, or when it will be as
widely ported as the Z-machine is today.
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------
Patrick Kellum
In article <6c6qjp$vv3$1...@bartlet.df.lth.se>, Magnus Olsson was talking about:
>Ah, I see. I don't think that's a very good idea, because, as you
>write below, Inform isn't as powerful as (say) C++ for general-purpose
>programming.
Well, I was working on a port of the S.S.I./TSR program "Dungeon Master's
Assistant Vol. II" to Inform and it would have been better then the
oiginal (easer UI, better dice routine) but it is on hold until I get my
current project finished. Inform is useful for utilities, it's just that
nobody has made any yet.
>Yes, apart from the fact that you'll have to duplicate the effort Graham
>has put into the Inform libraries, and that (at least IMHO) the syntax of
>C++ is more cumbersome than that of Inform *for creating text games*.
Or for anything IMHO.
>If you want something really new in the interface department, then you must
>use a language that gives you full access to Windows (or whatever GUI you're
>using), that's correct.
Ah, but a full GUI can be writtin in Inform :-) Serious, menus, windows,
clickable buttons, mouse, etc. All are available in the standard
z-machine.
>That's not quite true. Java is also dependent on interpreters (until
>Java chips become widespread), but these interpreters are designed to
>give Java the same kind of power as C++.
I don't see Java taking off like all the magazines say. The idea is great
but the language wasn't written as well as it should have been and it is
already nearly impossable to run one Java program on another system due to
all the hacks people are adding for specific machines.
>It is possible to extend the Z machine to make Inform more
>powerful. Whether it's worth doing it is another question.
If it were extended to make it equal or better then Java then yes it would
be worth it.
Gunther Schmidl
>I think the point is that such a stand-alone is platform dependant; a
>jzip-built executable will only run on DOS/Windows systems. (without a DOS
>emulator, but then it's just swapping one interpreter for another)
*WARNING* *WARNING* *WARNING* *WARNING* *WARNING* *WARNING* *WARNING*
THE LINE FOLLOWING JUST BEFORE THE "--" IS ONLY A JOKE. IN NO WAY IS IT
TO BE TAKEN SERIOUSLY. I AM JUST FOOLING. THIS IS NOT MY OPINION.
*WARNING* *WARNING* *WARNING* *WARNING* *WARNING* *WARNING* *WARNING*
Let's just get rid of any platform except MS-DOS ;-)
--
+------------------------+----------------------------------------------+
+ Gunther Schmidl + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 + except temptation" -- Oscar Wilde +
+ A-4040 LINZ +----------------------------------------------+
+ Tel: 0732 25 28 57 + http://gschmidl.home.ml.org - new & improved +
+------------------------+---+------------------------------------------+
+ sothoth (at) usa (dot) net + please remove the "xxx." before replying +
+----------------------------+------------------------------------------+
Gunther Schmidl
>Ah, but a full GUI can be writtin in Inform :-) Serious, menus, windows,
>clickable buttons, mouse, etc. All are available in the standard
>z-machine.
Now, zWindows would be really cool. And run as fast on an 8086 10 MhZ as
Windows NT does on a Pentium 233 :-)
Graham Nelson
> > generates native code for a PC, you have to rewrite a large portion of
> > the compiler if you want it to generate Macintosh native code instead.
>
> You could try a different strategy. Your Inform compiler outputs C
> source code, which is then compiled on the platform (or cross-compiled)
> to produce native code. (After all, you're exploiting the portability
> of C to make Z-code interpreters easy to port.)
My experiences with Inform have led me to giggle, and then fall
off my chair screaming, whenever "C" and "portability" are
mentioned in the same sentence.
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom
NNelson334
Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>the syntax of C++ is more cumbersome than that of Inform *for creating text
>games*.
You're right.
>For my part, I see the need to learn a new langauge as
>an opportunity to broaden my mind. (Thelast sentence was not intended
>as any criticism of you, just an observation).
I understand. I actually started learning Inform before C++, and it's just
frustrating to have on one hand, such a robust and dynamic language (C++) at
one's fingertips, and another language that is the best at what it does
(Inform), and then not be able to have the best of both worlds at exactly the
same time.
Sure, you can incorperate the two appropriately -- C/C++ interpreter and
compiler, Inform written z-code program files -- but it just isn't the same.
Yours,
N. Nathanael
mailto:nne...@world-net.net
--
"You are in a twisty little passage of standards, all conflicting."
-- Michael Meissner, meis...@osf.org
NNelson334
Okay. But first you have to drop the "MS-", change the "D" to "UN", the "O"
to an "I", and the "S" to "X".
LucFrench
This entire thread just went *plonk*. Should I be worried?
Thanks
Luc French
Brock Kevin Nambo
Gunther Schmidl wrote in message
<34e70...@alijku02.edvz.uni-linz.ac.at>...
>>I think the point is that such a stand-alone is platform dependant; a
>>jzip-built executable will only run on DOS/Windows systems. (without a DOS
>>emulator, but then it's just swapping one interpreter for another)
>
>*WARNING* *WARNING* *WARNING* *WARNING* *WARNING* *WARNING* *WARNING*
>
>THE LINE FOLLOWING JUST BEFORE THE "--" IS ONLY A JOKE. IN NO WAY IS IT
>TO BE TAKEN SERIOUSLY. I AM JUST FOOLING. THIS IS NOT MY OPINION.
>
>*WARNING* *WARNING* *WARNING* *WARNING* *WARNING* *WARNING* *WARNING*
>
*OUTRAGE* *OUTRAGE* *OUTRAGE* *OUTRAGE* *OUTRAGE* *OUTRAGE* *OUTRAGE*
HOW DARE YOU SUGGEST SUCH A THING. THIS IS TAKEN AS A GRAVE PERSONAL
INSULT. I HOPE YOU'RE HAPPY WITH YOURSELF. THIS IS WAR!!!
*OUTRAGE* *OUTRAGE* *OUTRAGE* *OUTRAGE* *OUTRAGE* *OUTRAGE* *OUTRAGE*
<g>
Dancer
Graham Nelson wrote:
For something like inform, Graham, it's just a matter of coding style. Sure,
filesystems are the big sticking point, but the core code for the compiler
should be pretty portable with no woes. I recall running one of the version 4
or version 5 informs through my compiler with all the portability warnings
switched on, and it _yelped_.
No offense intended. S'just stylistic..but style does come down to
portability. Didn't I poke you once, years ago, about passing structures by
value? :)
I guess it all comes down to _types_ and _files_, and anything that can't cope
with ANSI C, you cross-compile on something that can. Types and files should
be neatly extractable into their own modules by class of platform. The config
header in inform is quite functional but it's a little icky to have everything
crammed together, IMO.
YMMV, IMO, and all that. Personally, I love Graham, and want to have his
illicit love-child. :)
D
--
Did you read the documentation AND the FAQ?
If not, I'll probably still answer your question, but my patience will
be limited, and you take the risk of sarcasm and ridicule.
Andrew Plotkin
Dancer (dan...@brisnet.org.au) wrote:
> > My experiences with Inform have led me to giggle, and then fall
> > off my chair screaming, whenever "C" and "portability" are
> > mentioned in the same sentence.
> For something like inform, Graham, it's just a matter of coding style.
"This turns out not to be the case."
> Sure,
> filesystems are the big sticking point
-- the *three* big sticking points are filesystems, input, and output.
The -- four, the four big sticking points are filesystems, input, output,
and process scheduling --
(You think I'm kidding about process scheduling? Last night I was looking
at the abbreviation-optimizing code in Inform. Total data-cruching stuff,
no I/O at all, right? Should be completely portable? Well, there's a
#ifdef MAC right in the middle, to check for cmd-period interrupts from
the user. Which is necessary.)
Did you see the note in one of the header files that preprocessor
directives have to be up against the left margin, not indented, because
of one damn broken cpp somewhere?
Have you written a program as widely ported as Inform is? I haven't.
> I guess it all comes down to _types_ and _files_, and anything that can't cope
> with ANSI C, you cross-compile on something that can. Types and files should
> be neatly extractable into their own modules by class of platform.
Meditate upon the code that creates default filenames. If you think this
is either easy or ANSI, meditate some more.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Dancer
Andrew Plotkin wrote:
> Dancer (dan...@brisnet.org.au) wrote:
> > > My experiences with Inform have led me to giggle, and then fall
> > > off my chair screaming, whenever "C" and "portability" are
> > > mentioned in the same sentence.
>
> > For something like inform, Graham, it's just a matter of coding style.
>
> "This turns out not to be the case."
I'll grant that in some cases it's not the case.
> > Sure,
> > filesystems are the big sticking point
>
> -- the *three* big sticking points are filesystems, input, and output.
> The -- four, the four big sticking points are filesystems, input, output,
> and process scheduling --
>
> (You think I'm kidding about process scheduling? Last night I was looking
> at the abbreviation-optimizing code in Inform. Total data-cruching stuff,
> no I/O at all, right? Should be completely portable? Well, there's a
> #ifdef MAC right in the middle, to check for cmd-period interrupts from
> the user. Which is necessary.)
(deep breath) Ouch. Isn't that only an issue if there's a live serial link (the OS
does baud-rate generation on the mac in timed software loops in the OS), and if you
actually want to bother to have it interruptable? I realise that the mac system is a
cooperative rather than preemptive environment (at least the early ones were).
> Did you see the note in one of the header files that preprocessor
> directives have to be up against the left margin, not indented, because
> of one damn broken cpp somewhere?
Style. I never indent preprocessor directives for just that reason. Learned my
lesson back in the 70's on that score. For me it's one of the automatic "thou shalt
not"'s. Y'know: Thou shalt not pass aggregate types by value. Thou shalt not indent
thy compiler/assembler directives. Thou shalt use limits.h to determine the sizes of
integral data-types if they need to be determined at compile-time. And all of that.
Things you stop thinking about after a few years, and just do.
> Have you written a program as widely ported as Inform is? I haven't.
Umm. Giving the question some careful thought...I'd have to say...'barely'. Yes, but
only barely. Wide variety of systems, hardware, and configurations, and (ick)
_integrating_ directly with software (some of it very buggy, or deficient, or just
not conforming to the interfaces that were published, or having no published
interfaces and requiring guess-work or horrible workarounds). And that was just one
of them. I'm still trying to _forget_ that one. I _did_ abstract everything though,
and #ifdefs were minimal (three or four) only.
> > I guess it all comes down to _types_ and _files_, and anything that can't cope
> > with ANSI C, you cross-compile on something that can. Types and files should
> > be neatly extractable into their own modules by class of platform.
>
> Meditate upon the code that creates default filenames. If you think this
> is either easy or ANSI, meditate some more.
Ah, no. I do definitely _not_ consider it an easy job. But we already break the task
up in the inform source. Surely it would be a little more maintenance_ok if those
chunks were pulled out into system-dependancy modules (ala zip). I remember porting
inform a couple times, and having to patch in more code for the filenaming and I/O
(no stdio library on one of the build targets). I also remember wishing that such
#if/#else stuff was in a separate per-system module. I could have duped a module
that was close to my build-target and just tweaked it a little, and linked.
Graham Nelson
In article <erkyrathE...@netcom.com>, Andrew Plotkin
<URL:mailto:erky...@netcom.com> wrote:
> Dancer (dan...@brisnet.org.au) wrote:
> > > My experiences with Inform have led me to giggle, and then fall
> > > off my chair screaming, whenever "C" and "portability" are
> > > mentioned in the same sentence.
>
> > For something like inform, Graham, it's just a matter of coding style.
>
> "This turns out not to be the case."
>
> > filesystems are the big sticking point
>
> -- the *three* big sticking points are filesystems, input, and output.
> The -- four, the four big sticking points are filesystems, input, output,
> and process scheduling --
And of course data typing. Ever tried to write fool-proof ANSI
code to guarantee a 32-bit signed integer? Nope, sorry -- on a
strict reading of the standard this is impossible. (Of course
you can write code which tells you if it is possible or not on
the given compiler, but this doesn't work, because for some
reason the part of the ANSI standard making definitions for
data type ranges is one of the least adhered to passages. On
one version of VAX C, these definitions are set up with the right
names, but have the wrong values.)
On one of Inform's target compilers, "signed char" produces an
error. On another one, "unsigned char" does. Care to write some
ANSI code which will sort these two cases out, without human
intervention? Bearing in mind that many poor C compilers call
themselves ANSI if can they parse ANSI-style function headers
and that's it.
And then let's talk about object code size. Such as, no procedure
or table exceeding something like 16K for fear of offending one of
the Macintosh compilers. Oh, and how about the malloc() function?
In a completely standard way, this is entirely allowed to reject
all requests to allocate more than 32K minus 5 bytes. And guess
what! On modern machines with 32 _M_ of memory, it sometimes does!
Now try allocating arrays of structures whose size you don't know
in advance because it depends on the implementation of the compiler,
and the size of int, and that sort of thing. How will calloc()
work, for instance? Will it be subject to the same constraints
as malloc(), or not?
Now giggle, fall off your chair, scream. It's always worked for
me.
...No, look, I'm still not done here. Consider this:
printf("The answer is %d\n", 350*701);
Legal responses by fully ANSI standard-compliant C compilers to this
trivial piece of computing include, but are not limited to:
(i) Printing 245350.
(ii) Printing -16794.
(iii) Producing a warning that the %d should be a %Ld
at compilation time, and then (i).
(iv) Ditto, and then (ii).
Circumstances where compiler X produces a warning if you make choice
A, whereas compiler Y produces a warning if you make choice not-A,
are even more frequent. Warnings are a law unto themselves.
Andrew Plotkin
Dancer (dan...@brisnet.org.au) wrote:
> Andrew Plotkin wrote:
> > Dancer (dan...@brisnet.org.au) wrote:
> > > > My experiences with Inform have led me to giggle, and then fall
> > > > off my chair screaming, whenever "C" and "portability" are
> > > > mentioned in the same sentence.
> >
> > > For something like inform, Graham, it's just a matter of coding style.
> >
> > "This turns out not to be the case."
> I'll grant that in some cases it's not the case.
Ok, I think we're in the same wavelength. I like to think of Inform as an
example of an extremely portable pile of source code, because I've made
it work on different Unixes and Mac-with-ANSI-libraries with no changes
at all.
I certainly won't say it's perfect. It's caused me less personal anguish
than any other C source code for a real-world program I've had to deal
with. But I agree with your other points.
> > (You think I'm kidding about process scheduling? Last night I was looking
> > at the abbreviation-optimizing code in Inform. Total data-cruching stuff,
> > no I/O at all, right? Should be completely portable? Well, there's a
> > #ifdef MAC right in the middle, to check for cmd-period interrupts from
> > the user. Which is necessary.)
> (deep breath) Ouch. Isn't that only an issue if there's a live serial
> link (the OS
> does baud-rate generation on the mac in timed software loops in the
> OS), and if you
> actually want to bother to have it interruptable?
You do want this interruptible, since there can be lots of computation
without any output. Last time I tried running the abbreviation code, the
thing took forever and I *had* to type cmd-period.
And you certainly want a compiler to be able to run in the background
while you use the modem.
(I think SIOUX (the ANSI term-window library we use these days on the Mac)
yields time to other processes, and checks for cmd-period, but only when
you print to stdout or read from stdin. Come to think of it, I think
Robert Pelak's MacInform doesn't use SIOUX.)
> I realise that the
> mac system is a
> cooperative rather than preemptive environment (at least the early ones
> were).
Still is -- we're waiting for Rhapsody...
Matthew T. Russotto
In article <ant1614491cbM+4%@gnelson.demon.co.uk>,
Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
}...No, look, I'm still not done here. Consider this:
}
} printf("The answer is %d\n", 350*701);
}
}Legal responses by fully ANSI standard-compliant C compilers to this
}trivial piece of computing include, but are not limited to:
}
} (i) Printing 245350.
} (ii) Printing -16794.
} (iii) Producing a warning that the %d should be a %Ld
} at compilation time, and then (i).
} (iv) Ditto, and then (ii).
Case (iii) is just plain wrong (though perhaps ANSI legal) --
if an int is 4 bytes long, "%d" is a perfectly reasonable format
string for 350*701. If an int is two bytes long, you can't legally be
in case (iii).
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Kenneth Fair
In article <erkyrathE...@netcom.com>, erky...@netcom.com (Andrew
Plotkin) wrote:
>(You think I'm kidding about process scheduling? Last night I was looking
>at the abbreviation-optimizing code in Inform. Total data-cruching stuff,
>no I/O at all, right? Should be completely portable? Well, there's a
>#ifdef MAC right in the middle, to check for cmd-period interrupts from
>the user. Which is necessary.)
I haven't looked at the Inform source, so I don't know what it says, but in
this #ifdef MAC section, should there be a call to WaitNextEvent so as to
allow for multitasking? Or is that taken care of elsewhere?
--
KEN FAIR - U. Chicago Law | <http://student-www.uchicago.edu/users/kjfair>
Of Counsel, U. of Ediacara | Power Mac! | CABAL(tm) | I'm w/in McQ - R U?
"Any smoothly functioning technology will be
indistinguishable from a rigged demo." Isaac Asimov
Kenneth Fair
In article <19980215115...@ladder02.news.aol.com>,
nnels...@aol.com (NNelson334) wrote:
>Patrick Kellum <pat...@syix.com> wrote:
>>Already possable, on Amiga computers just install a program that acts on
>>whatever file is clicked on. For example, if I installed the program and
>>clicked on a z-code file it would intercept this and load the interpreter
>>first with the z-code file as a command line argument. Easy.
>
> The Mac OS does this. So does Windows. It isn't the same thing that I
>wanted to be able to do with Inform. A program in a file that only runs if you
>open it with another program is not a stand-alone program. My reason for even
>thinking about all this, was that I wanted to be able to use Inform in other
>ways besides games.
But you can also, with the interpreters available on the Mac and Windows,
create stand-alone programs--executables--that contain the interpreter
and program file together in a bundle. That would seem to be what you want,
right? I can just hand you the stand-alone program and you can run in
without need of a separate interpreter program.
Matthew T. Russotto
In article <erkyrathE...@netcom.com>,
}> (deep breath) Ouch. Isn't that only an issue if there's a live serial
}> link (the OS does baud-rate generation on the mac in timed software
}> loops in the OS)
*YIPES* It doesn't do that, thankfully -- that sort of stuff was left
behind on the Apple II, which did do the cassette and disk interface
with timed software loops. You'll lose serial data if you don't yield to
other processes, but only because you'll overflow the buffers, not
because of timed loops to do baud-rate generation.
Dancer
Andrew Plotkin wrote:
> I certainly won't say it's perfect. It's caused me less personal anguish
> than any other C source code for a real-world program I've had to deal
> with. But I agree with your other points.
I've found other things that are more readily portable, but yes, Inform _is_ one
of the better ones. My thoughts about stylistics were largely for those areas
where you _do_ need to change something.
> > > #ifdef MAC right in the middle, to check for cmd-period interrupts from
> > > the user. Which is necessary.)
>
> > does baud-rate generation on the mac in timed software loops in the
> > OS), and if you
> > actually want to bother to have it interruptable?
>
> You do want this interruptible, since there can be lots of computation
> without any output. Last time I tried running the abbreviation code, the
> thing took forever and I *had* to type cmd-period.
Hmm. I've never had it run that long, but I'll grant that. My environment is not
everybody's.
> And you certainly want a compiler to be able to run in the background
> while you use the modem.
Probably. Yeah.
> (I think SIOUX (the ANSI term-window library we use these days on the Mac)
> yields time to other processes, and checks for cmd-period, but only when
> you print to stdout or read from stdin. Come to think of it, I think
> Robert Pelak's MacInform doesn't use SIOUX.)
> > I realise that the
> > mac system is a
> > cooperative rather than preemptive environment (at least the early ones
> > were).
>
> Still is -- we're waiting for Rhapsody...
Umm. Didn't they abandon Rhapsody for workstations, and shift their focus to
server environments...a week or two ago? Or will that not make a terrible lot of
difference. I must admit to having been out of the apple scene since about 1989.
John Francis
In article <sihg63d...@cre.canon.co.uk>,
Gareth Rees <gar...@cre.canon.co.uk> wrote:
>Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>> If you write a compiler (for Inform, ZIL, C++ or whatever) that
>> generates native code for a PC, you have to rewrite a large portion of
>> the compiler if you want it to generate Macintosh native code instead.
>
>You could try a different strategy. Your Inform compiler outputs C
>source code, which is then compiled on the platform (or cross-compiled)
>to produce native code. (After all, you're exploiting the portability
>of C to make Z-code interpreters easy to port.)
But this means I would have to have a C compiler (and possibly one
specific C compiler) on my game platform, or access to a machine with
a cross-compiler. Either that, or wait for the game porter for my
machine to get round to doing the port. One great advantage of the
current scheme is that I can grab the Z-machine interpreter now, and
use it on any future .Z5 file as soon as it is released.
I could even play the games on my palm pilot, should I choose to
accquire the appropriate interpreter. i wouldn't be able to do
that for a C-based game, because I don't have the pilot developers
workbench.
--
John Francis jfra...@sgi.com Silicon Graphics, Inc.
(650)933-8295 2011 N. Shoreline Blvd. MS 43U-991
(650)933-4692 (Fax) Mountain View, CA 94043-1389
Unsolicited electronic mail will be subject to a $100 handling fee.
Robert A. Pelak
> Dancer (dan...@brisnet.org.au) wrote:
>
> > Andrew Plotkin wrote:
>
> > > Dancer (dan...@brisnet.org.au) wrote:
> > > > > My experiences with Inform have led me to giggle, and then fall
> > > > > off my chair screaming, whenever "C" and "portability" are
> > > > > mentioned in the same sentence.
> > >
> > > > For something like inform, Graham, it's just a matter of coding style.
> > >
> > > "This turns out not to be the case."
>
> > I'll grant that in some cases it's not the case.
>
> Ok, I think we're in the same wavelength. I like to think of Inform as an
> example of an extremely portable pile of source code, because I've made
> it work on different Unixes and Mac-with-ANSI-libraries with no changes
> at all.
>
> I certainly won't say it's perfect. It's caused me less personal anguish
> than any other C source code for a real-world program I've had to deal
> with. But I agree with your other points.
>
This is not by accident. Graham and we porters have put a considerable amount
of effort into making Inform as portable as possible. It was not a trivial
enterprise.
> > > (You think I'm kidding about process scheduling? Last night I was looking
> > > at the abbreviation-optimizing code in Inform. Total data-cruching stuff,
> > > no I/O at all, right? Should be completely portable? Well, there's a
> > > #ifdef MAC right in the middle, to check for cmd-period interrupts from
> > > the user. Which is necessary.)
>
> > (deep breath) Ouch. Isn't that only an issue if there's a live serial
> > link (the OS
> > does baud-rate generation on the mac in timed software loops in the
> > OS), and if you
> > actually want to bother to have it interruptable?
>
> You do want this interruptible, since there can be lots of computation
> without any output. Last time I tried running the abbreviation code, the
> thing took forever and I *had* to type cmd-period.
>
Not to mention the times when a semicolon is forgotten and 100 error messages
start streaming out to the console.
> And you certainly want a compiler to be able to run in the background
> while you use the modem.
>
> (I think SIOUX (the ANSI term-window library we use these days on the Mac)
> yields time to other processes, and checks for cmd-period, but only when
> you print to stdout or read from stdin. Come to think of it, I think
> Robert Pelak's MacInform doesn't use SIOUX.)
I wrote my own implementations of printf() and such so that I could more
easily customize the interface as well as control event processing. While
most, if not all, of this could have been done with SIOUX, it appeared difficult
to work with as the code for SIOUX is folded in with the rest of their
implementation of the ANSI library. And believe me, it is far more
opaque than the code for Inform.
Robert
Robert A. Pelak
In article <kjfair-1602...@ntcs-ip326.uchicago.edu>,
kjf...@midway.uchicago.edu.REMOVEME (Kenneth Fair) wrote:
> In article <erkyrathE...@netcom.com>, erky...@netcom.com (Andrew
> Plotkin) wrote:
>
> >(You think I'm kidding about process scheduling? Last night I was looking
> >at the abbreviation-optimizing code in Inform. Total data-cruching stuff,
> >no I/O at all, right? Should be completely portable? Well, there's a
> >#ifdef MAC right in the middle, to check for cmd-period interrupts from
> >the user. Which is necessary.)
>
> I haven't looked at the Inform source, so I don't know what it says, but in
> this #ifdef MAC section, should there be a call to WaitNextEvent so as to
> allow for multitasking? Or is that taken care of elsewhere?
In essesnce, yes. It calls a routine that calls WaitNextEvent and then
processes any events tha occur. If cmd-period was hit, control goes back
to Inform so it can clean up after itself.
Robert
Joe Mason
In article <OW$fhubO9GA.203@upnetnews03>,
Brock Kevin Nambo <newsm...@earthling.net> wrote:
>Magnus Olsson wrote in message <6c4bk3$g5l$1...@bartlet.df.lth.se>...
>>(Please don't say "but you can run the interpreter on
>>itself". You try that, then come back and tell us where the infinite
>>recursion bottomed out.)
>
>Well, it bottoms out at infinity.
>
>After that, it starts running like mad!
You don't fool me! It's turtles all the way down!
Joe
Brock Kevin Nambo
Joe Mason wrote in message ...
LOLOL but what if the last turtle decides to walk somewhere?
>>BKNambo (deep questions that go "all the way down")
--
http://come.to/brocks.place
Hey look, it's the Roman Empire!
Dancer
Matthew T. Russotto wrote:
> In article <erkyrathE...@netcom.com>,
> Andrew Plotkin <erky...@netcom.com> wrote:
> }Dancer (dan...@brisnet.org.au) wrote:
>
> }> (deep breath) Ouch. Isn't that only an issue if there's a live serial
> }> link (the OS does baud-rate generation on the mac in timed software
> }> loops in the OS)
>
> *YIPES* It doesn't do that, thankfully -- that sort of stuff was left
> behind on the Apple II, which did do the cassette and disk interface
> with timed software loops. You'll lose serial data if you don't yield to
> other processes, but only because you'll overflow the buffers, not
> because of timed loops to do baud-rate generation.
Err...My source for this was a developer at apple, way back when (pre-1989).
We had corroboratory evidence at the time:
1) Connect a Mac (either a Fat or a Thin, original or plus) to a DEC VAX
11/7xx series terminal port.
2) Login via MacTerm.
3) Close MacTerm (without logging out), and start doing something
processor-intensive.
Some _very_ interesting things start to develop. The baud-rate begins a heavy
drift, and the VAX begins to slow down. The effect on the VAX is particularly
gradual, but quite astonishing. After a few hours, it's so slow that just
about your only recourse is to turn the key, and reboot, because you can no
longer log into the beastie, and the tty's respond somewhat slower than 1
byte per ten minutes.
The first few times had us head-down in the kernel source, without result.
Then we discovered the common factor (the above sequence of events). Our
sysadmin of the era placed some calls to apple, and the information about
baud-rate generation came back to us. I believe that a proper UART was
installed in the MAC II's (about..umm..1987?). I'm only referring to machines
prior to that period.
Matthew T. Russotto
In article <34EAFF01...@brisnet.org.au>,
Dancer <dan...@brisnet.org.au> wrote:
}Err...My source for this was a developer at apple, way back when (pre-1989).
}We had corroboratory evidence at the time:
}1) Connect a Mac (either a Fat or a Thin, original or plus) to a DEC VAX
}11/7xx series terminal port.
}2) Login via MacTerm.
}3) Close MacTerm (without logging out), and start doing something
}processor-intensive.
}
}Some _very_ interesting things start to develop. The baud-rate begins a heavy
I don't know what's going on there, but from the beginning the Mac did
baud-rate generation in hardware (a Zilog 8530). If the problem was
baud rate, the Mac would lose the ability to communicate with the Vax,
not just slow down.
Dancer
Graham Nelson wrote:
> In article <erkyrathE...@netcom.com>, Andrew Plotkin
> <URL:mailto:erky...@netcom.com> wrote:
> > Dancer (dan...@brisnet.org.au) wrote:
> > > > My experiences with Inform have led me to giggle, and then fall
> > > > off my chair screaming, whenever "C" and "portability" are
> > > > mentioned in the same sentence.
> >
> > > For something like inform, Graham, it's just a matter of coding style.
> >
> > "This turns out not to be the case."
> >
> > > Sure,
> > > filesystems are the big sticking point
> >
> > -- the *three* big sticking points are filesystems, input, and output.
> > The -- four, the four big sticking points are filesystems, input, output,
> > and process scheduling --
>
> And of course data typing. Ever tried to write fool-proof ANSI
> code to guarantee a 32-bit signed integer? Nope, sorry -- on a
> strict reading of the standard this is impossible. (Of course
> you can write code which tells you if it is possible or not on
> the given compiler, but this doesn't work, because for some
> reason the part of the ANSI standard making definitions for
> data type ranges is one of the least adhered to passages. On
> one version of VAX C, these definitions are set up with the right
> names, but have the wrong values.)
Yup. Actually, here's another good one for you. It's a BSD/Ultrix C compiler (I
don't recall which version) but it's still in use in many sites: if(expr)
/* comment */
{
always_executed_regardless_of_expr;
}
It treats the comment as the statement block, if it occurs on the same line as
the expression. I spent a DAY looking for that one. :(
> On one of Inform's target compilers, "signed char" produces an
> error. On another one, "unsigned char" does. Care to write some
> ANSI code which will sort these two cases out, without human
> intervention? Bearing in mind that many poor C compilers call
> themselves ANSI if can they parse ANSI-style function headers
> and that's it.
That's sort of why I'm thinking that a per-machine configuration header might
be better than the current one.
> And then let's talk about object code size. Such as, no procedure
> or table exceeding something like 16K for fear of offending one of
> the Macintosh compilers. Oh, and how about the malloc() function?
> In a completely standard way, this is entirely allowed to reject
> all requests to allocate more than 32K minus 5 bytes. And guess
> what! On modern machines with 32 _M_ of memory, it sometimes does!
> Now try allocating arrays of structures whose size you don't know
> in advance because it depends on the implementation of the compiler,
> and the size of int, and that sort of thing. How will calloc()
> work, for instance? Will it be subject to the same constraints
> as malloc(), or not?
calloc() may not be, since in some libraries calloc() is implemented with a
different mid-end, or even back-end in a couple extreme cases. There's at least
one compiler (early Microsoft, I think) where calloc() was just a macro.
I know the 16K object limit. I still write code to it...I get twitchy when
anything starts to get up around that size, and start a new module, even though
nothing I currently develop for has that problem. There were more things than
just a lone Mac compiler had trouble with that one.
> Now giggle, fall off your chair, scream. It's always worked for
> me.
Been there, done that..got the tee-shirt, eaten the ice-cream, shot the
stuffed toy :)
> ...No, look, I'm still not done here. Consider this:
>
> printf("The answer is %d\n", 350*701);
>
> Legal responses by fully ANSI standard-compliant C compilers to this
> trivial piece of computing include, but are not limited to:
>
> (i) Printing 245350.
> (ii) Printing -16794.
> (iii) Producing a warning that the %d should be a %Ld
> at compilation time, and then (i).
> (iv) Ditto, and then (ii).
My assumption here is to expect (ii), or (iv). With the exception of an 8-bit
architecture, I don't expect %d to reliably do more than signed 16 bit output
without a qualifier. I think it's unreasonable to expect it to print 32-bit
values without qualification.
> Circumstances where compiler X produces a warning if you make choice
> A, whereas compiler Y produces a warning if you make choice not-A,
> are even more frequent. Warnings are a law unto themselves.
Oh, my yes:
MRI C compiler:
int foo(char *p, char *q)
{
if(!p)
return 0;
if(q)
return 1;
return 0;
}
The above code, under that compiler complains that nether p or q are 'used'.
Peering at the address does not count. Assigning the address to something else
does. Assigning the address to itself (p=p) doesn't. Dereferencing does.
Err..Sometimes (p[i] does. *p does. *(p+5) does not).
Compiler warnings are a true terror of the night.
J. Holder
Thus spake L. Ross Raszewski <rras...@hotmail.com>:
: In article <6c36v3$r53$1...@neko.syix.com>,
: pat...@syix.com (Patrick Kellum) wrote:
: >
: > Stand alone Inform games are already possable, check out JZip. Or am I
: > missing the point completly? (wouldn't be the first time :-)
: >
: >
: I think the point is that such a stand-alone is platform dependant; a
: jzip-built executable will only run on DOS/Windows systems. (without a DOS
: emulator, but then it's just swapping one interpreter for another)
Actually, a jzip standalone exe for DOS is still playable by UNIX, VMS,
Atari, etc ports of Jzip - Jzip for another platform can ignore the DOS
exe code... It's just not a "standalone" anymore.
--
John Holder (jho...@frii.com) http://www.frii.com/~jholder/
Sr. Programmer Analyst, J.D.Edwards World Source Company, Denver, CO
http://www.jdedwards.com/
Joe Mason
In article <u7tY9TOP9GA.103@upnetnews03>,
Brock Kevin Nambo <newsm...@earthling.net> wrote:
>>
>>You don't fool me! It's turtles all the way down!
>
>LOLOL but what if the last turtle decides to walk somewhere?
(From memory)
"The currently accepted theory is that Atuan the World Turtle is swimming
through space to the great World Turtle Mating Grounds. Determining the sex
of the World Turtle has become of highest importance to scholars."
-- Terry Pratchet, one of the _Discworld_ books (The Colour of Magic, perhaps?)
Joe
Stuart Adair
Joe Mason wrote in message ...
I think he calls this the "Big Bang" theory, doesn't he?
Stuart
--
_____________________
\_ .:stuart adair:. /___ :dubstar::moby::scrawn&lard::eddieizzard:| "i'm
/ / stu...@bigfoot.com \_________ :bigbeat:::interactivefiction:| covered
/ / stuart...@stud.umist.ac.uk _) :terrypratchett::::drum&bass:| in
\ \/\ c.floor homepage back up! (_ /\ :zxspectrum::::fatboyslim:| beees!"
\__/ http://cfloor.home.ml.org [__)/ \_ :quake:kenickie:[frenzi]| -(e.i)
Paul Francis Gilbert
jcm...@undergrad.math.uwaterloo.ca (Joe Mason) writes:
>In article <u7tY9TOP9GA.103@upnetnews03>,
>Brock Kevin Nambo <newsm...@earthling.net> wrote:
>>>
>>>You don't fool me! It's turtles all the way down!
>>
>>LOLOL but what if the last turtle decides to walk somewhere?
>(From memory)
>"The currently accepted theory is that Atuan the World Turtle is swimming
>through space to the great World Turtle Mating Grounds. Determining the sex
>of the World Turtle has become of highest importance to scholars."
>-- Terry Pratchet, one of the _Discworld_ books (The Colour of Magic, perhaps?)
>Joe
My memory of it was:
The currently accepted theory is that Atuan the World Turtle is swimming
through space to a great cosmic breeding ground where Atuan will mate with
the other World Turtles, which the rest of the visible stars obviously
belong to. In that fiery union will the seeds of a new universe be born.
This is known as the Big Bang theory ;-)
--
Paul Gilbert | p...@yallara.cs.rmit.edu.au (The DreamMaster)
Bach App Sci, Bach Eng | The opinions expressed are my own, all my own, and
Year 4, RMIT Melbourne | as such will contain no references to small furry
Australia | creatures from Alpha Centauri.
John Francis
In article <6ci90d$59f$1...@goanna.cs.rmit.edu.au>,
Paul Francis Gilbert <p...@yallara.cs.rmit.EDU.AU> wrote:
>jcm...@undergrad.math.uwaterloo.ca (Joe Mason) writes:
>
>>In article <u7tY9TOP9GA.103@upnetnews03>,
>>Brock Kevin Nambo <newsm...@earthling.net> wrote:
>>>>
>>>>You don't fool me! It's turtles all the way down!
>>>
>>>LOLOL but what if the last turtle decides to walk somewhere?
>
>>(From memory)
>
>>"The currently accepted theory is that Atuan the World Turtle is swimming
>>through space to the great World Turtle Mating Grounds. Determining the sex
>>of the World Turtle has become of highest importance to scholars."
>
>>-- Terry Pratchet, one of the _Discworld_ books (The Colour of Magic, perhaps?)
>
>>Joe
>
>My memory of it was:
>
>The currently accepted theory is that Atuan the World Turtle is swimming
>through space to a great cosmic breeding ground where Atuan will mate with
>the other World Turtles, which the rest of the visible stars obviously
>belong to. In that fiery union will the seeds of a new universe be born.
>This is known as the Big Bang theory ;-)
Thats "Great A'Tuin", I think.
There is also an opposing theory, which states that Great A'Tuin will
continue his (or her) leisurely swim through the cosmos indefinitely.
This is know as the "Steady Gait" theory.
Try alt.books.pratchett for more information. you could possibly try
alt.fan.pratchett, but that could very well prove more confusing than edifying.
ob.if: Did anyone like either of the "DiscWorld" games?
John Elliott
John Francis (jfra...@dungeon.engr.sgi.com) wrote:
: ob.if: Did anyone like either of the "DiscWorld" games?
There are three, one a text adventure for the Spectrum which you can
pick up from gmd.
------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott |BLOODNOK: "But why have you got such a long face?"
|SEAGOON: "Heavy dentures, Sir!" - The Goon Show
:-------------------------------------------------------------------------)
Joe Mason
In article <6ci90d$59f$1...@goanna.cs.rmit.edu.au>,
Paul Francis Gilbert <p...@yallara.cs.rmit.EDU.AU> wrote:
>
>>(From memory)
>
>>"The currently accepted theory is that Atuan the World Turtle is swimming
>>through space to the great World Turtle Mating Grounds. Determining the sex
>>of the World Turtle has become of highest importance to scholars."
>
>>-- Terry Pratchet, one of the _Discworld_ books (The Colour of Magic, perhaps?)
>
>>Joe
>
>My memory of it was:
>
>The currently accepted theory is that Atuan the World Turtle is swimming
>through space to a great cosmic breeding ground where Atuan will mate with
>the other World Turtles, which the rest of the visible stars obviously
>belong to. In that fiery union will the seeds of a new universe be born.
>This is known as the Big Bang theory ;-)
Oh, yes. Forgot that bit. But the sex of the World Turtle IS very important,
of course. We really should know who's going to end up on top.
Joe
Paul Francis Gilbert
jfra...@dungeon.engr.sgi.com (John Francis) writes:
>ob.if: Did anyone like either of the "DiscWorld" games?
>--
>John Francis jfra...@sgi.com Silicon Graphics, Inc.
>(650)933-8295 2011 N. Shoreline Blvd. MS 43U-991
>(650)933-4692 (Fax) Mountain View, CA 94043-1389
>Unsolicited electronic mail will be subject to a $100 handling fee.
I really liked the first one. It had a fairly good plot, most of the puzzles
were logical (sort-of), and the bylines were hilarous (the mon--, er, ape ;-)
librarian hitting you over the head, that nature-guy doing the explanation
voice-overs, and Baldric [black adder] doing some of the voices).
As for the second one, it was a bit disappointing... as Rincewind himself
said, "they've put in more useless puzzles... Sorry, latteral thinking
exercises". Sure there was more to solve, but all the puzzles just didn't
fit into the story as well. All that fuss about getting the mouse blood,
for example, was way overboard). And I felt it was missing some of the
witty byplay that was in the first (I was so disapointed that I couldn't
get the librarian to bonk me on the haed again ;-) ).
p a t c h.net
Paul Francis Gilbert said "To hell with carpal tunnel!" and wrote:
>
> I really liked the first one. It had a fairly good plot, most of the puzzles
> were logical (sort-of), and the bylines were hilarous (the mon--, er, ape ;-)
> librarian hitting you over the head, that nature-guy doing the explanation
> voice-overs, and Baldric [black adder] doing some of the voices).
However, after the five-hundred and seventy-sixth time Rincewind intoned
"-That- doesn't work" the disc suddenly disappeared from the CD-ROM and
ended up in my microwave. I really don't know how that happened.
However, I did enjoy the Librarian, as well as all the other fine
Pratchett touches to the game. I still wish James Earl Jones had been
tapped for the voice of Death; there just is no other worthy voice, I say.
--
der Spatchel. spatula@s p a t c h.net. Proud to eat yummy red meat.
PUTPBAD is undergoing a facelift at http://www.spatch.net/booth. Soon!
"i need some ass, goddammit." - Meef
Tony Ellis
test please ignore
ftp://ftp.gmd.de/if-archive/infocom/compilers/inform6/manuals/designers_manu
al_hlp.zip