[ANNOUNCE] Glulx preliminary specification
Andrew Plotkin
I'm really proud of myself. I've managed to finish an entirely new
text-adventure VM without even mentioning to anybody here that I've been
working on it. (Although I admit it's been kind of an open secret on
IFmud.) Now that it's finally almost ready to go, I thought I'd let you
all know about it.
Actually, the VM itself isn't all that exciting -- it's just a generic
32-bit VM with Glk I/O, about as simple as a machine can get. It has a few
specializations for IF, but not as many as even the Z-machine (which was
already pretty generic.)
It's only interesting because I've got a version of the Inform compiler
that compiles to it. Standard Inform language, nearly the standard Inform
libraries; the only differences are that just about all the Z-machine
limits are gone. Global variables, local variables, properties,
attributes, classes, amount of property data, various others I'm
forgetting. Most are now unlimited; or at least jacked up a few orders of
magnitude. And more orders of magnitude can be added with compiler
upgrades. The VM (and the interpreters) don't have to change.
(My great gratitude to Graham, if you'll pardon the alliteration, for his
permission and support in this project. And for the code base.)
------------------
I really, really wanted to have this finished by April 1. Didn't happen.
So much for the dramatic ironies.
However, I can offer you the following:
One (1) Glulx VM specification, medium-done but not entirely browned. All
the core functionality is there -- the arithmetic, logic, and control
opcodes. The Glk interface isn't set yet. I'm still tossing around ideas
for additional useful toys like hardware sorting and searching. I haven't
come up with anything useful for text compression, so strings are all in
plaintext for the moment.
One (1) interpreter, medium-rare. This is "glulxe" (for Glulx-execute.) It
is, of course, a Glk program, so you can start playing with it on any
machine with a Glk library. On the other hand, you don't have any game
files to run. Again, the core functionality is there, but not fancy stuff
like save/restore/undo.
One (1) Glulx disassembler, "glulxdump", in working order.
Regrettably, I can't offer you even a taste of the Inform compiler for
Glulx. Much too bloody-rare to pass USDA inspection. Here's where it is:
Arithmetic, conditionals, and control statements -- the C-like subset of
Inform -- is pretty much done. Integers, strings, functions, and arrays
are all usable.
You can compile objects and classes, but the language support is
half-done. Attributes work, but the veneer code that handles properties
isn't there yet. The parent(), child(), and sibling() functions work, and
also the (a in b) test. The move, remove, and objectloop statements don't.
I haven't even looked at the parts of Inform that compile the dictionary
and grammar tables.
The Inform source I'm working with is pretty grotesque. It's all over
#ifdefs and comments. Eventually Graham and I will merge the source back
into a single Inform distribution that can compile to either Z-code or
Glulx. But that process hasn't started yet.
The Inform library parser will also have to be worked over to understand
both the Glulx and Z-code dictionary/grammar tables. The rest of the
library will remain almost unchanged, however.
Not all the limits can really be raised as high as they can theoretically
go. For example, the compiler is hardwired to 56 attributes per object.
There's no reason that couldn't be raised as high as you need -- or
lowered, if you want to save memory -- the VM doesn't care. But it's a
#defined constant in the Inform source, so you'd have to recompile the
compiler to change it. Eventually this will be a command-line switch; it's
not yet.
And there are all sorts of little corners and knuckles that I haven't
gotten around to yet. Like the read statement. You could bypass the read
statement and call the Glk line-input API directly, except of course that
I haven't sorted out the Glk interface in the Glulx VM...
But it's all coming together.
Not bad for a month's work.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
David Given
erky...@netcom.com (Andrew Plotkin) writes:
> I'm really proud of myself. I've managed to finish an entirely new
> text-adventure VM without even mentioning to anybody here that I've been
> working on it. (Although I admit it's been kind of an open secret on
> IFmud.) Now that it's finally almost ready to go, I thought I'd let you
> all know about it.
Oh, yawn, it's just another revolutionary idea that'll change the face of
interactive fiction as we know it today. Why not do something *different*
for a change?
Much kudos and all that (especially for the Inform port --- now all we
need is a Tads one), and I'm now going through the spec, but I do have one
question: where *do* you get your names? Glk, Glulx, Blorb, Floo...
--
+- David Given ---------------McQ-+ "The sky was the perfect untroubled blue
| Work: d...@tao-group.com | of a television screen, tuned to a dead
| Play: dgi...@iname.com | channel." --- Neil Gaiman, _Neverwhere_
+- http://wired.st-and.ac.uk/~dg -+
ne...@norwich.edu
erky...@netcom.com (Andrew Plotkin) wrote:
> http://www.eblong.com/zarf/glulx/
>
> I'm really proud of myself. I've managed to finish an entirely new
> text-adventure VM without even mentioning to anybody here that I've been
> working on it. (Although I admit it's been kind of an open secret on
> IFmud.) Now that it's finally almost ready to go, I thought I'd let you
> all know about it.
This is so cool I have to go to the bathroom!
Neil Cerutti
ne...@norwich.edu
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Evin C Robertson
preliminar.. by Andrew Plo...@netcom.co
> is, of course, a Glk program, so you can start playing with it on any
> machine with a Glk library. On the other hand, you don't have any game
> files to run. Again, the core functionality is there, but not fancy stuff
> like save/restore/undo.
There's a minor bug: op_quit is missing from lookup_operandlist in operand.c
After you add that line in, here's a hex dump for a hello world:
6c47 6c75 0100 0000 0000 0001 0000 0001
0000 0002 0000 0001 0000 2000 0000 0000
00c0 7200 3001 2081 0001 0000 0000 0000
48e0 6c65 6f6c 7720 726f 646c 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
Simon 'tufty' Stapleton
> In article <erkyrathF...@netcom.com>,
> erky...@netcom.com (Andrew Plotkin) wrote:
> > http://www.eblong.com/zarf/glulx/
> >
> > I'm really proud of myself. I've managed to finish an entirely new
> > text-adventure VM without even mentioning to anybody here that I've been
> > working on it. (Although I admit it's been kind of an open secret on
> > IFmud.) Now that it's finally almost ready to go, I thought I'd let you
> > all know about it.
>
> This is so cool I have to go to the bathroom!
Hello world looks like this.
47 6C 75 6C 00 01 00 00 00 00 01 00 00 00 01 00
00 00 02 00 00 00 01 00 00 00 00 30 00 00 00 00
E0 48 65 6C 6C 6F 20 77 6F 72 6C 64 00 00 00 00
C1 00 00 72 03 00 00 00 20 31 00 00 00 00 00 00
and then pad it to 256 bytes
Simon
--
_______ _______
| ----- | Biased output from the demented brain of | ----- |
||MacOS|| Simon Stapleton. ||Linux||
|| 8.5 || || PPC ||
| ----- | sstaple AT liffe DoT com | ----- |
| -+-.| (if you can't figure it out...) | -+-.|
|洵洵洵洱 |洵洵洵洱
------- -------
Andrew Plotkin
> where *do* you get your names? Glk, Glulx, Blorb, Floo...
It's a kind of magic.
ne...@norwich.edu writes:
> This is so cool I have to go to the bathroom!
But not that kind.
Simon 'tufty' Stapleton (nob...@no.bloody.where) wrote:
> Hello world looks like this.
>
> 47 6C 75 6C 00 01 00 00 00 00 01 00 00 00 01 00
> 00 00 02 00 00 00 01 00 00 00 00 30 00 00 00 00
> E0 48 65 6C 6C 6F 20 77 6F 72 6C 64 00 00 00 00
> C1 00 00 72 03 00 00 00 20 31 00 00 00 00 00 00
> and then pad it to 256 bytes
Evin C Robertson (ec...@andrew.cmu.edu) wrote:
> 6c47 6c75 0100 0000 0000 0001 0000 0001
> 0000 0002 0000 0001 0000 2000 0000 0000
> 00c0 7200 3001 2081 0001 0000 0000 0000
> 48e0 6c65 6f6c 7720 726f 646c 0000 0000
[and then pad it to 256 bytes]
Geez, you people.
Thank you. I suppose I should post a genuine Inform-generated "Hello
world", but it'd look pretty much the same.
A couple of footnotes to the above:
Evin did his hexdump by 16-byte hex values, so swap those byte pairs if
you're typing it in by hand.
Evin, you have a spurious "01" byte after the "quit" opcode. This is
harmless, since it never gets executed, but "quit" takes no operands.
Simon's code doesn't disassemble properly in glulxdump. This is a bug in
glulxdump, not in Simon's code. (Glulxdump assumes that functions come
before strings in ROM. Otherwise, it can't tell when the last function
ends, and it goes zooming off to the end of file and crashes.)
You both skipped the checksum, which is not surprising, since Glulxe
doesn't check it. (My Inform code doesn't generate it yet, either.)
Also, a correct Glulx program must open a Glk window and set the current
stream before it prints anything. The current version of Glulxe does this
for you, since it doesn't understand the "glk" opcode yet. However, the
final release *won't*. So both the above programs will eventually fail.
Oh, and don't either of you people believe in newlines?
> There's a minor bug: op_quit is missing from lookup_operandlist in
operand.c
True. The other game-state opcodes as well.
Ricardo Dague
>
> http://www.eblong.com/zarf/glulx/
>
> I'm really proud of myself. I've managed to finish an entirely new
> text-adventure VM without even mentioning to anybody here that I've been
> working on it. (Although I admit it's been kind of an open secret on
> IFmud.) Now that it's finally almost ready to go, I thought I'd let you
> all know about it.
>
> 32-bit VM with Glk I/O, about as simple as a machine can get. It has a few
> specializations for IF, but not as many as even the Z-machine (which was
> already pretty generic.)
YAYY! Somebody finally got off their keester and started one
of these.
Thank you so much.
-- Ricardo
Iain Merrick
> Hello world looks like this.
>
> 47 6C 75 6C 00 01 00 00 00 00 01 00 00 00 01 00
> 00 00 02 00 00 00 01 00 00 00 00 30 00 00 00 00
> E0 48 65 6C 6C 6F 20 77 6F 72 6C 64 00 00 00 00
> C1 00 00 72 03 00 00 00 20 31 00 00 00 00 00 00
>
> and then pad it to 256 bytes
Tufty, I hate you...
My version is much better, though. It has a checksum and everything. :P
--
Iain Merrick
Iain Merrick
[ ... various Hello Worlds ... ]
> Geez, you people.
I just posted one too. Is this some sort of twisted psychological
experiment?
[...]
> You both skipped the checksum, which is not surprising, since Glulxe
> doesn't check it. (My Inform code doesn't generate it yet, either.)
[gloat]
> Also, a correct Glulx program must open a Glk window and set the current
> stream before it prints anything. The current version of Glulxe does this
> for you, since it doesn't understand the "glk" opcode yet. However, the
> final release *won't*. So both the above programs will eventually fail.
This I discovered, _after_ writing an initialisation function.
Okay, here are some serious suggestions:
(1) Change the name. 'Glulx' is ugly, difficult to pronounce, and
difficult to type. And meaningless. And ugly.
(2) Hmmm, compressed strings (sect. 1.5.1.2)... this would be easy
enough if you didn't have to compress them individually, as you say. Do
you _have_ to compress them individually? How about if you define a
'bunch of strings' object type, and add an opcode to extract string N
from a given bunch?
Then again, perhaps you could do this in bytecode rather than a
dedicated opcode, which would be keeping with the 'Glulx spirit'.
Although they'd have to be decompressed into RAM, and it would make
sense to purge the decompressed strings before saving... and it might be
slow. Hmmm.
(3) Change the name. I mean, 'Glulx spirit' sounds like some obscure
brand of Polish vodka or something.
(4) It might be worthwhile adding some coding conventions to the
specification. For instance, have an object type which you can put
before a function to supply debugging information; this would help
decouple the debugger (assuming someone writes such a thing) from a
specific compiler (e.g., Inform).
(5) Change the name. There are plenty of more attractive names you could
use... for instance, 'dsyxt', 'quoxp' or 'rthcb'.
(6) The layout of objects is rather loosely defined, no doubt
intentionally. But it seems that code generated on-the-fly in the RAM
area is within the spec, or even overlapping objects... I wonder if this
is a good thing. I can't imagine why you'd ever want to do such bizarre
things; but then again, I can't think of a compelling reason for
disallowing them.
Hmmm... if the interpreter included a JIT compiler, it would be useful
for it to be able to safely make certain assumptions about which bits of
memory can contain executable code. But I don't suppose anyone's going
to write a JIT interpreter for IF games in the near future.
(7) Change the name.
--
Iain Merrick
Andrew Plotkin
> Okay, here are some serious suggestions:
> (2) Hmmm, compressed strings (sect. 1.5.1.2)... this would be easy
> enough if you didn't have to compress them individually, as you say. Do
> you _have_ to compress them individually? How about if you define a
> 'bunch of strings' object type, and add an opcode to extract string N
> from a given bunch?
That's just what LZW and related algorithms can't do. They work by taking
a block of text, sucking out some redundancy, and then repeating the
process on the result. The compressed text can only be decoded all at
once, beginning to end.
The only approach I've thought of is to decompress all the text into
native memory (not VM memory) when the game starts up. This seems a waste,
and it makes life very hard for terps that run on small machines (like
PDAs.)
> (4) It might be worthwhile adding some coding conventions to the
> specification. For instance, have an object type which you can put
> before a function to supply debugging information; this would help
> decouple the debugger (assuming someone writes such a thing) from a
> specific compiler (e.g., Inform).
I tend to prefer having debug info be in a separate file, instead of
interspersed in the program file. Inform is already set up to generate
that a separate debug file for Z-code, too. Modifying that code for Glulx
debug output will be easy enough.
> (6) The layout of objects is rather loosely defined, no doubt
> intentionally. But it seems that code generated on-the-fly in the RAM
> area is within the spec, or even overlapping objects... I wonder if this
> is a good thing.
Certainly generating strings on the fly is important. Functions, I don't
know, but I'm sure someone will come up with a reason. (SML, anyone? :-)
> Hmmm... if the interpreter included a JIT compiler, it would be useful
> for it to be able to safely make certain assumptions about which bits of
> memory can contain executable code.
But not all that useful, if the information is just "is it above or below
this boundary?" It would be nice if the compiler could scan through memory
and find all the functions, but making that possible would be a much
bigger change than merely limiting executable code to ROM.
> But I don't suppose anyone's going
> to write a JIT interpreter for IF games in the near future.
Hasn't happened yet. It's been talked about.
Aris Katsaris
Andrew Plotkin wrote in message ...
>http://www.eblong.com/zarf/glulx/
Glulx? Glulx?!?! LOL. You hate vowels or something?. Jeez, even "Gringr" is
better than Glulx... :)
Otherwise, great job!
Aris Katsaris
Lucian Paul Smith
: Okay, here are some serious suggestions:
: (1) Change the name. 'Glulx' is ugly, difficult to pronounce, and
: difficult to type. And meaningless. And ugly.
Ordinarily I wouldn't argue about naming conventions, but in this case, I
really must concur. I'm sure Zarf has some wonderful Smullyanesque reason
for naming it thus, but it's lost on me.
If it doesn't change, I shall take to calling it 'G-code' and the
'G-machine'.
But that's just me.
-Lucian
David Given
erky...@netcom.com (Andrew Plotkin) writes:
[...]
> But not all that useful, if the information is just "is it above or below
> this boundary?" It would be nice if the compiler could scan through memory
> and find all the functions, but making that possible would be a much
> bigger change than merely limiting executable code to ROM.
All objects have a leading type byte, right? So why not add another four
bytes for the size of the object?
This would allow you to scan through memory, looking at each object. You'd
identify functions by the type. You would need to ensure that unused space
was correctly identified as such, though.
--
+- David Given ---------------McQ-+ "Gaping from its single obling socket was
| Work: d...@tao-group.com | scintillating, many fauceted scarlet
| Play: dgi...@iname.com | emerald..." --- Jim Theis, _The Eye of
+- http://wired.st-and.ac.uk/~dg -+ Argon_
Adam J. Thornton
Lucian Paul Smith <lps...@rice.edu> wrote:
>Iain Merrick (i...@cs.york.ac.uk) wrote:
>: Okay, here are some serious suggestions:
>: (1) Change the name. 'Glulx' is ugly, difficult to pronounce, and
>: difficult to type. And meaningless. And ugly.
It sounds like a noise you make when you're starting to throw up.
>Ordinarily I wouldn't argue about naming conventions, but in this case, I
>really must concur. I'm sure Zarf has some wonderful Smullyanesque reason
>for naming it thus, but it's lost on me.
Maybe he was starting to throw up.
Adam
--
ad...@princeton.edu
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman
Christopher Scott
>
>(1) Change the name. 'Glulx' is ugly, difficult to pronounce, and
>difficult to type. And meaningless. And ugly.
"gloo-lcks"? Works for me.
>(7) Change the name.
(8) Built in debugger? Please?
--
Christopher Scott | csc...@table.jps.net
Andrew Plotkin
> In article <erkyrathF...@netcom.com>,
> erky...@netcom.com (Andrew Plotkin) writes:
> [...]
> > But not all that useful, if the information is just "is it above or below
> > this boundary?" It would be nice if the compiler could scan through memory
> > and find all the functions, but making that possible would be a much
> > bigger change than merely limiting executable code to ROM.
> All objects have a leading type byte, right? So why not add another four
> bytes for the size of the object?
> This would allow you to scan through memory, looking at each object. You'd
> identify functions by the type. You would need to ensure that unused space
> was correctly identified as such, though.
Sure. That's the thing, though. At that point you've got a scheme where
all of memory is divided up into objects, of one sort or another. And the
program has to be careful to never step on the memory structure.
I considered this, but decided that the hassle far outweighs the potential
benefits.
(What *are* the benefits? Debugging, and hardware assist to the program,
pretty much. But Inform has debugging conventions already; and
Inform+libraries don't *need* hardware assist. And the Z-machine has shown
that hardware assist tends to turn into a liability awful quick, anyway.)
If you want a fully-structured VM dataspace, it may be a clue that your
problem fits better with the T3 VM than with Glulx.
Andrew Plotkin
Doeadeer3
>From: erky...@netcom.com (Andrew Plotkin)
>Date: 4/1/99 12:43 PM Pacific Daylight Time
>If you want a fully-structured VM dataspace, it may be a clue that your
>problem fits better with the T3 VM than with Glulx.
>
>--Z
>
Would be nice if someone posted in words of one-syllable (and not funny
syllables) what this all means.
You may notice comments on your post are limited to people who actually
understand (have a clue) what you are talking about.
So Graham is supporting this? Does this mean this will be the new z-machine
specification (g-machine)? Will Inform be tailored to it in the future? Will
interpreters be written for it?
Or is it a fancy deadend?
Thank you. Over and out.
Doe :-)
Doe doea...@aol.com (formerly known as FemaleDeer)
****************************************************************************
"In all matters of opinion, our adversaries are insane." Mark Twain
Daniel Schepler
> Iain Merrick (i...@cs.york.ac.uk) wrote:
> > Okay, here are some serious suggestions:
>
> > (2) Hmmm, compressed strings (sect. 1.5.1.2)... this would be easy
> > enough if you didn't have to compress them individually, as you say. Do
> > you _have_ to compress them individually? How about if you define a
> > 'bunch of strings' object type, and add an opcode to extract string N
> > from a given bunch?
>
> That's just what LZW and related algorithms can't do. They work by taking
> a block of text, sucking out some redundancy, and then repeating the
> process on the result. The compressed text can only be decoded all at
> once, beginning to end.
>
> The only approach I've thought of is to decompress all the text into
> native memory (not VM memory) when the game starts up. This seems a waste,
> and it makes life very hard for terps that run on small machines (like
> PDAs.)
>
If I recall correctly from the time I browsed through the gzip RFC,
the compression format is a Huffman encoded string of bytes and codes
which give a negative offset and a length to copy (within a certain
range). What if Glulk used a hybrid approach between this and the
Z-machine abbreviation mechanism? In particular, there would be a
table of (probably compressed) common substrings, and an encoding of a
Huffman tree, and then a compressed string would be a Huffman-encoded
string of plain characters and special codes referring to one of the
common substrings. (In particular, the current Inform compiler
already has code to generate a good set of common substrings, although
I haven't really thought about the adjustments which would make it
optimize for Huffman coding as opposed to Z-machine coding.)
--
Daniel Schepler "Please don't disillusion me. I
sche...@math.berkeley.edu haven't had breakfast yet."
-- Orson Scott Card
Doeadeer3
>Date: 4/1/99 3:35 PM Pacific Daylight Time
>Thank you. Over and out.
>
>Doe :-)
>
>
Didn't mean to sound snippy if I did. I am genuinely curious.
Would also like to congratulate you -- but I would prefer to know what I am
congratulating you on first before I do.
Doe :-) A lot of us are not familiar with the z-machine specs, etc. We just
use Inform and leave that stuff to others.
Emerick Rogul
: BTW - In addition to my other q's, is that pronounced "Gluck"?
I think you just pronounce it by clearing your throat. ;-)
-Emerick
--
-------------------------------------------------------------------------
Emerick Rogul /\/ "...painted portraits of minions and slaves,
eme...@cs.bu.edu /\/ crotch mavens and one-night plays..."
-------------------------------------------------------- 'here', pavement
Adam Cadre
> The three obvious choices are the one syllable "glulks", the two
> syllable "glue-lik" and the Microsoft-esque "Glul X".
I am referring to it exclusively as "Andy P's Specification of Luv."
"Glulxe" is accordingly pronounced "Andy P's Interpreter of Luv."
-----
Adam Cadre, Anaheim, CA
http://adamcadre.ac
R. Alan Monroe
>If it doesn't change, I shall take to calling it 'G-code' and the
>'G-machine'.
Isn't the term "G-code" already used in Computer Aided Manufacturing?
:^)
Have fun
Alan
Adam J. Thornton
But then locations in it, would be G-spots, and that would be cool.
Joe Mason
I really hate the name. Even just "Glux" would be better.
Joe
--
"Think hard and long about what your favorite book is. Once identified, read
it a paragraph at a time. Then after having read the paragraph, read each
sentence. See the way the sentences interrelate. Then, read the words..."
-- Mike Berlyn, on learning to write
Joe Mason
>>>If it doesn't change, I shall take to calling it 'G-code' and the
>>>'G-machine'.
>
>>Isn't the term "G-code" already used in Computer Aided Manufacturing?
>>:^)
>
>But then locations in it, would be G-spots, and that would be cool.
Not to mention when the compression debate comes out with a winner, we can call
the resulting objects "G-strings".
(And do people writing G-code games get to be called G-men?)
Doeadeer3
Doe :-)
Joe Mason
>BTW - In addition to my other q's, is that pronounced "Gluck"?
The three obvious choices are the one syllable "glulks", the two syllable
"glue-lik" and the Microsoft-esque "Glul X". Personally, I will never refer
to it as "Glulx" and will rename all the executables in my copy to remove the
abomination.
Joe
Cthulu f'tagh! Glulx f'tagh!
Adam J. Thornton
Only the male ones.
If they're Baumian troglodytes, they're G-nomes, though.
Andrew Plotkin
> >Date: 4/1/99 12:43 PM Pacific Daylight Time
> >If you want a fully-structured VM dataspace, it may be a clue that your
> >problem fits better with the T3 VM than with Glulx.
> Would be nice if someone posted in words of one-syllable (and not funny
> syllables) what this all means.
Well, not the sentence quoted above -- that was addressed to people
designing IF systems and compilers.
> You may notice comments on your post are limited to people who actually
> understand (have a clue) what you are talking about.
Plus Joe Mason, but let's not got there. :-)
> So Graham is supporting this?
I will be supporting the version of the Inform compiler that compiles to
it. When Graham and I get the compilers intergrated, I'll be supporting
the part of it that compiles to Glulx code.
> Does this mean this will be the new z-machine specification (g-machine)?
It is a new machine specification. It's not really "the new Z-machine",
because it's designed completely from scratch. But you can write games in
Inform and compile them into Glulx game files. Or will, when I get that
part finished. See my original post for a status report.
> Will Inform be tailored to it in the future?
Have I answered this? I'm not sure what you mean by "tailored".
> Will interpreters be written for it?
As I posted, I have written an interpreter for it. The interpreter isn't
quite done, but hey, the compiler isn't done either. I just thought it
would be an appropriate day to announce the project.
Andrew Plotkin
> > You may notice comments on your post are limited to people who actually
> > understand (have a clue) what you are talking about.
> Plus Joe Mason, but let's not got there. :-)
Whoo! That didn't come out right at all. Sorry.
I didn't mean to imply that Joe didn't have a clue. I was just making the
obvious joke about his slew of objection to the, er, non-technical parts
of my proposal. :)
Knight37
Joe Mason <jcm...@uwaterloo.ca> wrote in message
news:92302489...@news.remarQ.com...
>Doeadeer3 <doea...@aol.com> wrote:
>>BTW - In addition to my other q's, is that pronounced "Gluck"?
>
>The three obvious choices are the one syllable "glulks", the two syllable
>"glue-lik" and the Microsoft-esque "Glul X". Personally, I will never
refer
>to it as "Glulx" and will rename all the executables in my copy to remove
the
>abomination.
>
>Joe
>
>Cthulu f'tagh! Glulx f'tagh!
LOL...
Hey, Zarf, I think you should have all of the executables check to make
sure that their names have not been changed, and if they have, rename them
back to glulx and fill the screen with ;P;P;P;P;P;P...
knight37
Knight37
The unspeakable virtual machine that shall not be named!
knight37
Joe Mason
>Andrew Plotkin (erky...@netcom.com) wrote:
>
>> > You may notice comments on your post are limited to people who actually
>> > understand (have a clue) what you are talking about.
>
>> Plus Joe Mason, but let's not got there. :-)
>
>Whoo! That didn't come out right at all. Sorry.
Right - that's a horrible typo you let slip. Shame on you!
>I didn't mean to imply that Joe didn't have a clue. I was just making the
>obvious joke about his slew of objection to the, er, non-technical parts
>of my proposal. :)
Actually, I have a few more technical questions as well, but I haven't read the
spec yet. I'm mainly wondering how this thing scales - is it able to run on
Pilots and other small hardware (I'm more interested in supporting portables
than legacy systems)?
BTW, I should mention I've been without news access for a while - the first
day was my server's fault, but after that it was my own stupidity in not
regenerating my newsgroup list. Your post was the first thing I read when I
got back. I regard this as a good omen.
On the other hand, my keyboadddrd has started to spit random garbage out (which
I've thoughtfully eraseddddd), which is a bad omen. %%%%%%MJaybe the God Glulk6
is pissed off at me...
Joe
IF
Adam J. Thornton wrote:
> In article <92302078...@news.remarQ.com>,
> Joe Mason <jcm...@uwaterloo.ca> wrote:
> >(And do people writing G-code games get to be called G-men?)
>
> Only the male ones.
>
> If they're Baumian troglodytes, they're G-nomes, though.
And if there's ever a port of Zork 2, it will include the G-wiz of Frobozz.
Ian
Den
> (1) Change the name. 'Glulx' is ugly, difficult to pronounce, and
> difficult to type. And meaningless. And ugly.
How about...
FIZ - Fiz Isn't Z-machine
APHID - Andrew Plotkin Hoots, "It's Deliberate!"
Or Zarf could create a new language specially for programming for the
glulx machine called
Remarkable Andrew 'Interactive Fiction' Plotkin's Object Oriented Language
Hmm, I'm pushing it a bit aren't I?
--
Den rotate Glulx round the alphabet a bit... Zeneq? Vajam?
Andrew Plotkin
> Actually, I have a few more technical questions as well, but I haven't read the
> spec yet. I'm mainly wondering how this thing scales - is it able to run on
> Pilots and other small hardware (I'm more interested in supporting portables
> than legacy systems)?
The Glulx interpreter is much smaller than a Z-code interpreter, since
there's no object-handling code, and no interface code.
When you add in a Glk library, it swells back up some, because Glk has
more capability in general than Z-machine I/O. However, a Glk library on a
PDA will itself be pretty small, so I think the total is about comparable.
Glulx game files will be larger than Z-code files. Some of this is because
the object-handling code is all in the library -- but this is really a
very small effect. Most of the increase is because the assembly code has
many four-byte constants and addresses, where Z-code would have two-byte
or one-byte values. The instructions are less efficiently packed, too. I'm
estimating that the executable part of the game file will be about twice
as large as the executable part of an equivalent Z-code file.
Ditto for the object/property/dictionary data, since that has to store
four-byte values as well.
The text data will be the same size or smaller than Z-compressed text.
(Because if I can't find a better algorithm, I'll *use* Z-compression.)
However, I don't think any of this is a big deal, because the primary use
of Glulx is for Inform games that are too big for V8 *already*. (Use more
than 512K of data, or more than 64K of RAM.) So being too big for a PDA
is, to some degree, only a problem if it was a problem already.
(The secondary use of Glulx is for Inform games that want to use Glk I/O.
Since nobody's gotten to a PDA Glk library yet, I don't know how much
capability that is -- would PalmGlk be able to display PNG images and play
sound files? And multiple windows would get even more amazingly cramped
than a Palm is already. So I can't say how much of a temptation Glulx
would be on the Palm, compared to the factor-of-two game size penalty.)
Iain Merrick
> Iain Merrick (i...@cs.york.ac.uk) wrote:
> > Okay, here are some serious suggestions:
>
> > (2) Hmmm, compressed strings (sect. 1.5.1.2)... this would be easy
> > enough if you didn't have to compress them individually, as you say. Do
> > you _have_ to compress them individually? How about if you define a
> > 'bunch of strings' object type, and add an opcode to extract string N
> > from a given bunch?
>
> That's just what LZW and related algorithms can't do. They work by taking
> a block of text, sucking out some redundancy, and then repeating the
> process on the result. The compressed text can only be decoded all at
> once, beginning to end.
This is what the 'extract string N' function would do. To speed up
subsequent calls, the results could be cached...
> The only approach I've thought of is to decompress all the text into
> native memory (not VM memory) when the game starts up. This seems a waste,
> and it makes life very hard for terps that run on small machines (like
> PDAs.)
...like that. Yeah, that's basically what I meant.
However, you wouldn't have to put _all_ the text in a single compressed
block; you could have several chunks, each containing a few KB of text.
Would that be a reasonable compromise between compression and memory
overhead, or just a horrible cludge?
> > (4) It might be worthwhile adding some coding conventions to the
> > specification. For instance, have an object type which you can put
> > before a function to supply debugging information; this would help
> > decouple the debugger (assuming someone writes such a thing) from a
> > specific compiler (e.g., Inform).
>
> I tend to prefer having debug info be in a separate file, instead of
> interspersed in the program file. Inform is already set up to generate
> that a separate debug file for Z-code, too. Modifying that code for Glulx
> debug output will be easy enough.
Well, as long as there _is_ a debugger; either approach would work, I
suppose. I was thinking of the common practice on the Mac (and probably
other OS's) of embedding symbolic names into executable code for use by
a general-purpose debugger (usually Macsbug).
Either way, it would be nice to have a general-purpose Glulx debugger,
rather than a dedicated Glulx-code-generated-by-Inform debugger.
Iain Merrick
> I am referring to it exclusively as "Andy P's Specification of Luv."
>
> "Glulxe" is accordingly pronounced "Andy P's Interpreter of Luv."
After reading Aris Katsaris' post, my brain has irrevocably rewired
itself to read 'glulx' as 'grignr'.
Iain Merrick
> You seem to have missed addressing the most important point:
>
> I really hate the name. Even just "Glux" would be better.
I second this motion.
In fact, _third_ it, since someone elde made this point already.
--
Iain Merrick
Iain Merrick
> Joe Mason wrote:
>
> > I really hate the name. Even just "Glux" would be better.
>
> I second this motion.
>
> In fact, _third_ it, since someone else made this point already.
Hang on -- that was me.
Make that 'second' again.
Doeadeer3
>> So Graham is supporting this?
>
>I will be supporting the version of the Inform compiler that compiles to
>it. When Graham and I get the compilers intergrated, I'll be supporting
>the part of it that compiles to Glulx code.
That sounds like a coordinated effort. :-)
>> Does this mean this will be the new z-machine specification (g-machine)?
>
>It is a new machine specification. It's not really "the new Z-machine",
>because it's designed completely from scratch. But you can write games in
>Inform and compile them into Glulx game files. Or will, when I get that
>part finished. See my original post for a status report.
Gotcha. Well, the new VM is what I meant (from scratch). Been discussed before.
I remember one major thread last year.
>> Will Inform be tailored to it in the future?
>
>Have I answered this? I'm not sure what you mean by "tailored".
Yes, I think you answered it above. You did mention (if I read it right) the
parser would need to be rewritten in previous post.
I am getting the image of two Informs: one compiler for the z-machine, one
compiler for the g-machine.
>> Will interpreters be written for it?
>
>As I posted, I have written an interpreter for it. The interpreter isn't
>quite done, but hey, the compiler isn't done either. I just thought it
>would be an appropriate day to announce the project.
Okay, gotcha on that too. (See I WAS having trouble following all the parts you
said you had finished and/or were still working on.)
Well, congratulations, then! I know this is something others, in you
particular, have wanted for sometime. Release from the z-machine opcodes/memory
limits.
I was also most curious to how Inform, Graham's continued support of Inform and
what versions of Inform, tie in. Since I am more familiar with the high level
language than with the low level z-machine.
One is the part I use, one is the "under the hood" part that is important, but
not something I truly understand anyway, just like I don't truly understand my
car's engine. Yes, it affects performance, I understand that, but it is not the
part I am conversant or most concerned with.
Good luck with the rest. But I am sure you will have no problem.
Doe :-) CONGRATS again!!!
Doeadeer3
>Date: 4/2/99 9:40 AM Pacific Daylight Time
>>I will be supporting the version of the Inform compiler that compiles to
>>it. When Graham and I get the compilers intergrated, I'll be supporting
>>the part of it that compiles to Glulx code.
>I am getting the image of two Informs: one compiler for the z-machine, one
>compiler for the g-machine.
P.S. I meant UNTIL they are integrated.
Doe :-)
Andrew Plotkin
> I am getting the image of two Informs: one compiler for the z-machine, one
> compiler for the g-machine.
That'll be the state at first. Graham has said he wants to eventually
merge them together, so that you could have a single compiler, where you
type "inform -v8" or "inform -vg" to compile either way. This will require
some effort.
> Well, congratulations, then!
Thanks.
Daryl McCullough
>
>http://www.eblong.com/zarf/glulx/
>
>I'm really proud of myself. I've managed to finish an entirely new
>text-adventure VM without even mentioning to anybody here that I've been
>working on it. (Although I admit it's been kind of an open secret on
>IFmud.) Now that it's finally almost ready to go, I thought I'd let you
>all know about it.
Congratulations!
I remember an exchange about a year ago on the subject
"IF VM (Was Re: Block Delimiting: Alternative 3 )"
Daryl:
Is there an implementation of the Z-machine that uses GLK for its I/O?
Zarf:
No. I may write one as an exercise, but (1) it wouldn't
gain anything from the author's point of view (given the
current Z-machine -- not extending it) and (2) good
Z-machine ports already exist on most platforms. So
there's no real value in it.
Daryl McCullough
CoGenTex, Inc.
Ithaca, NY
Andrew Plotkin
> erky...@netcom.com (Andrew Plotkin) says...
> >
> >http://www.eblong.com/zarf/glulx/
> >
> >I'm really proud of myself. I've managed to finish an entirely new
> >text-adventure VM without even mentioning to anybody here that I've been
> >working on it. (Although I admit it's been kind of an open secret on
> >IFmud.) Now that it's finally almost ready to go, I thought I'd let you
> >all know about it.
> Congratulations!
Thanks.
> I remember an exchange about a year ago on the subject
> "IF VM (Was Re: Block Delimiting: Alternative 3 )"
> Daryl:
> Is there an implementation of the Z-machine that uses GLK for its I/O?
> Zarf:
> No. I may write one as an exercise, but (1) it wouldn't
> gain anything from the author's point of view (given the
> current Z-machine -- not extending it) and (2) good
> Z-machine ports already exist on most platforms. So
> there's no real value in it.
That's why Glulx is not "Z-machine version 10". It is extended in all the
ways that the Z-machine, um, isn't.
In fact, though, Evin Robertson *has* been working on a Z-machine
interpreter that uses Glk for its I/O. It's been nifty for making Floyd
work on IFmud. Also, when paired with the GTK Glk interpreter that (I
believe) someone is working on, it will provide a genuinely new Z-machine
port. (GTK is an open-source interface toolkit for Linux / X windows.
Considerably fancier than the XGlk I have now.)
Jesse McGrew
[snip]
: Sure. That's the thing, though. At that point you've got a scheme where
: all of memory is divided up into objects, of one sort or another. And the
: program has to be careful to never step on the memory structure.
[snip]
: If you want a fully-structured VM dataspace, it may be a clue that your
: problem fits better with the T3 VM than with Glulx.
Or perhaps with Snack, which stores data as one of seven types (boolean,
integer, string, list, object, code, undef). Data can be often be coerced
into another type: for example, coercing the integer 1234 to a string
produces the string "1234".
There's no risk of the game ruining data structures because there is no
memory addressing. Data can only be stored on the stack, in global or local
variables, as elements of a list, or as properties of an object, and values
that become inaccessible are freed automatically. Objects are a special
case, because they are always accessible by number until they are explicitly
destroyed.
--
/ Jesse "Monolith" McGrew \ :) -> TMBG, UCB/TDS, AMD, ROTT/Sin
| Most quotable man on the Internet | :( -> CW/R&B/rap/alt, WWF/WCW/etc,
\ Mr2001 on IRC / Intel/Cyrix/PPC, Q2
Joe Mason
>
>In fact, though, Evin Robertson *has* been working on a Z-machine
>interpreter that uses Glk for its I/O. It's been nifty for making Floyd
>work on IFmud. Also, when paired with the GTK Glk interpreter that (I
>believe) someone is working on, it will provide a genuinely new Z-machine
>port. (GTK is an open-source interface toolkit for Linux / X windows.
>Considerably fancier than the XGlk I have now.)
Now would be a good time to mention I'm working on QGlk, using the QT toolkit.
Mainly to teach myself QT.
Andrew Plotkin
> Andrew Plotkin <erky...@netcom.com> wrote:
> [snip]
> : Sure. That's the thing, though. At that point you've got a scheme where
> : all of memory is divided up into objects, of one sort or another. And the
> : program has to be careful to never step on the memory structure.
> [snip]
> : If you want a fully-structured VM dataspace, it may be a clue that your
> : problem fits better with the T3 VM than with Glulx.
> Or perhaps with Snack, which stores data as one of seven types (boolean,
> integer, string, list, object, code, undef). Data can be often be coerced
> into another type: for example, coercing the integer 1234 to a string
> produces the string "1234".
>
> There's no risk of the game ruining data structures because there is no
> memory addressing.
Yes, that's pretty much the T3 approach. If I read the specs aright.
You and Mike Roberts can fight it out. :-)
Scott Blomquist
>
> Graham has said he wants to eventually
>merge them together, so that you could have a single compiler, where you
>type "inform -v8" or "inform -vg" to compile either way. This will require
>some effort.
In the mean while, simply have inform -vg spawn the glulx compiler with
the same arguments it was called with. ;)
Oh, and all of this name-change recommendation crap... Ignore it, Andrew.
There's absolutely nothing wrong with fully unpronouncable nonsense words.
The license should deny use of glulx to people who object to (and more
importantly, try to change) the name 'glulx'!
Yours in jest.
--
_ Scott Blomquist KI5LT
(_` _ _ -|--|- mailto:sblo...@bigfoot.com
._)(_ (_) | | http://www.umr.edu/~sblomqui/
Scott Blomquist
>
>You seem to have missed addressing the most important point:
>
I get the feeling that Andrew is overlooking addressing this point
quite intentionally. Good for him! Long live the name 'glulx'!
Scott Blomquist
>In article <37039E...@cs.york.ac.uk>, Iain Merrick wrote:
>
>>
>>(1) Change the name. 'Glulx' is ugly, difficult to pronounce, and
>>difficult to type. And meaningless. And ugly.
>
>
>>(7) Change the name.
>
>(8) Built in debugger? Please?
And on the same day, Andrew Plotkin replied:
>Christopher Scott (csc...@table.jps.net) wrote:
>> (8) Built in debugger? Please?
>
>Built into what?
If I wasn't convinced before (see my earlier post) that Zarf was *intentionally*
ignoring the name change suggestion, this cinches it. In reply to a few
suggestions, he deleted the suggestions comprising 2/3 of the message. Hmmmmm.
Magnus Olsson
>>As I posted, I have written an interpreter for it. The interpreter isn't
>>quite done, but hey, the compiler isn't done either. I just thought it
>>would be an appropriate day to announce the project.
(...)
>Well, congratulations, then! I know this is something others, in you
>particular, have wanted for sometime.
Indeed. And while we others (well, some of us, at least) have been
talking, and talking, and talking, Zarf has actually been DOING
something. Great! Thanks, and congratulations!
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------
Jonadab the Unsightly One
> question: where *do* you get your names? Glk, Glulx, Blorb, Floo...
He's got an old scrabble set with most of the tiles missing, but all
the "l" tiles are still there.
If zerospam.com bounces substitute bright.net
-- Jonadab the Unsightly One
Jonadab the Unsightly One
> Meaningless?
>
> Glulx [GLULKZ], n. [Gr. _glulkos_, orgy.]
> 1. a Zarfian virtual machine specification.
> 2. a virtual machine meeting such a specification.
> 3. a large-mouthed demon who delights in devouring young lovers whole.
Consider that the canonical lexical entry for 'glulx'.
Jonadab the Unsightly One
> (5) Change the name. There are plenty of more attractive names you could
> use... for instance, 'dsyxt', 'quoxp' or 'rthcb'.
All out on account of not containing an 'l'.
How about 'glkoo', 'gblxk', or 'klg'? 'vxlgk'?
David Given
jcm...@uwaterloo.ca (Joe Mason) writes:
[...]
> Not to mention when the compression debate comes out with a winner, we can call
> the resulting objects "G-strings".
[...]
Been done. GEOS calls strings of graphics opcodes gstrings.
--
+- David Given ---------------McQ-+
| Work: d...@tao-group.com | Closed mouths gather no feet.
| Play: dgi...@iname.com |
+- http://wired.st-and.ac.uk/~dg -+
Alan Trewartha
and if you'll permit me
Second: Hoo
In article <3708cfc0...@news.bright.net>, Jonadab the Unsightly One
<URL:mailto:jon...@zerospam.com> wrote:
> d...@tao.co.uk (David Given) wrote:
>
> > question: where *do* you get your names? Glk, Glulx, Blorb, Floo...
>
> He's got an old scrabble set with most of the tiles missing, but all
> the "l" tiles are still there.
Well if you type 'glulx' into the keywords of DejaNews and wade past this
and associated threads you come to two unconnected postings.
One from Zarf that gives us an insight into how much he hates us all. The
other, obviously the inspiration for the name, is slap in the middle of some
binhex (or something) encoding of a Mac .sea file. What is the mystical
significance of that .sea is the crucial question.
Actually who cares? I'm a very happy bunny. Now I'm waiting (without much
breath-holding activity) to see how the compiler progresses and how long
development will take on the Acorn side of things.
--
Mail to alant instead of no.spam
Adam J. Thornton
Andrew Plotkin <erky...@netcom.com> wrote:
>Christopher Scott (csc...@table.jps.net) wrote:
>> (8) Built in debugger? Please?
>Built into what?
Built into "Stoink", I guess.
Adam
--
ad...@princeton.edu
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman
Andrew Plotkin
> First: Woo
> and if you'll permit me
I shall.
> Second: Hoo
I do my best.
> binhex (or something) encoding of a Mac .sea file. What is the mystical
> significance of that .sea is the crucial question.
"Self-extracting archive" is as mystical as it gets, I'm afraid.
> Actually who cares? I'm a very happy bunny. Now I'm waiting (without much
> breath-holding activity) to see how the compiler progresses and how long
> development will take on the Acorn side of things.
The compiler is Graham's code with bits modified, so it should compile
everywhere that standard Inform compiles, by the standard procedure.
As to the interpreter -- I haven't heard that anyone's working on an Acorn
native Glk library. But GlkTerm should compile on anything that has a
curses library. Has anyone tried it on RiscOS?
Jonadab the Unsightly One
> Oh, and all of this name-change recommendation crap... Ignore it, Andrew.
> There's absolutely nothing wrong with fully unpronouncable nonsense words.
It's not fully unpronouncable. You obviously didn't see the
invisible vowells. It's spelled 'glulx' and pronounced 'gluelicks'.
> The license should deny use of glulx to people who object to (and more
> importantly, try to change) the name 'glulx'!
Only if they try to change the spelling. I can forsee that the
pronunciation is going to become a religious issue, much like
'xyzzy'.
David Given
jon...@zerospam.com (Jonadab the Unsightly One) writes:
> sblo...@umr.edu (Scott Blomquist) wrote:
>
>> Oh, and all of this name-change recommendation crap... Ignore it, Andrew.
>> There's absolutely nothing wrong with fully unpronouncable nonsense words.
>
> It's not fully unpronouncable. You obviously didn't see the
> invisible vowells. It's spelled 'glulx' and pronounced 'gluelicks'.
But it *is* pronouncable, and you don't need to insert vowels, either.
Glulx == `glulks'
Glulxe == `glulksey'
Glk == `gl@k', where @ is a schwa
What's the problem?
--
+- David Given ---------------McQ-+ "Gaping from its single obling socket was
| Work: d...@tao-group.com | scintillating, many fauceted scarlet
| Play: dgi...@iname.com | emerald..." --- Jim Theis, _The Eye of
+- http://wired.st-and.ac.uk/~dg -+ Argon_
Stuart Moore
doea...@aol.com (Doeadeer3) wrote:
> >Subject: Re: [ANNOUNCE] Glulx preliminary specification
> >From: erky...@netcom.com (Andrew Plotkin)
>
> >If you want a fully-structured VM dataspace, it may be a clue that your
> >problem fits better with the T3 VM than with Glulx.
> >
> >
> [SNIP!]
Woah, Marnie - what Andrew is talking about is possibly a revolution in the IF
community!
Inform is a powerful language in it's own right, but the Z-Machine is holding
it back. What Andrew is proposing is a new VM (Virtual Machine) for Inform to
compile to, that'll allow Inform to reach it's true (non-Z-Machine bound)
potential.
So, what I gather is that, if Graham and Andrew can work together enough, a
new VM model will be used by Inform (possibly the hopefully-forthcoming 6.21)
- the G-Machine.
The Z-Machine is dead. Long live the G-Machine.
Bye,
--
Stuart Moore.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Andrew Plotkin
> In article <19990401173532...@ng-fw1.aol.com>,
> doea...@aol.com (Doeadeer3) wrote:
> >
> > >If you want a fully-structured VM dataspace, it may be a clue that your
> > >problem fits better with the T3 VM than with Glulx.
> Woah, Marnie - what Andrew is talking about is possibly a revolution in
> the IF community!
Actually, I was the one that wrote the quote above. The Z-machine/Glulx
family share a number of assumptions and ways of looking at the world,
rather different from the way the TADS/T3 family looks at the world.
(Primarily, the Z-machine's state is fundamentally an array of bytes, and
the TADS state is fundamentally a heap of objects. Glulx and T3 have both
refined their respective familial approaches to be cleaner and more
elegant.)
So different problems are probably suited more to one or the other.
> Inform is a powerful language in it's own right, but the Z-Machine is holding
> it back. What Andrew is proposing is a new VM (Virtual Machine) for Inform to
> compile to, that'll allow Inform to reach it's true (non-Z-Machine bound)
> potential.
Yes. Erm, do I get the impression you meant this as email? :-)
> So, what I gather is that, if Graham and Andrew can work together enough, a
> new VM model will be used by Inform (possibly the hopefully-forthcoming 6.21)
I don't know about version numbers, but I'm the one doing the work here.
Don't blame Graham for delays. :)
There are many details left to do, but I'm hoping that it'll only take
another month or so before I can get a beta out. Well, I should say,
another month or so before I can try to compile a complete Inform game to
Glulx. I won't try to predict how many problems that'll turn up...
> The Z-Machine is dead.
Is not. Any game that can fit in 512K, and which is content with the
standard V5/8 I/O, is probably better off as a Z-machine game. Glulx files
will be considerably larger, all other things being equal.
George Caswell
> Iain Merrick <i...@cs.york.ac.uk> wrote:
>
> > (5) Change the name. There are plenty of more attractive names you could
> > use... for instance, 'dsyxt', 'quoxp' or 'rthcb'.
>
> All out on account of not containing an 'l'.
>
> How about 'glkoo', 'gblxk', or 'klg'? 'vxlgk'?
>
Hee, hee... that Zarf may be able to get work done on his projects, but
-I- can think up cool names! :)
---GEC
(Implementor of a Z-machine environment... well, the basic memory controller,
at least...)
Doeadeer3
>Date: 4/9/99 6:47 AM Pacific Daylight Time
>Woah, Marnie - what Andrew is talking about is possibly a revolution in the
>IF
>community!
>
>Inform is a powerful language in it's own right, but the Z-Machine is holding
>it back. What Andrew is proposing is a new VM (Virtual Machine) for Inform to
>compile to, that'll allow Inform to reach it's true (non-Z-Machine bound)
>potential.
I thought Zarf already explained that quite well.
I just wanted him to spell out what Graham's support was/wasn't. Which he did.
BTW - I prefer being called Doe.
>The Z-Machine is dead. Long live the G-Machine.
Oh, I seriously doubt that. Many games are not so big that they will NEED the
g-machine.
Doe :-) Thx.
Arcum Dagsson
> In article <370cfdd7...@news.bright.net>,
> jon...@zerospam.com (Jonadab the Unsightly One) writes:
> > sblo...@umr.edu (Scott Blomquist) wrote:
> >
> >> Oh, and all of this name-change recommendation crap... Ignore it, Andrew.
> >> There's absolutely nothing wrong with fully unpronouncable nonsense words.
> >
> > It's not fully unpronouncable. You obviously didn't see the
> > invisible vowells. It's spelled 'glulx' and pronounced 'gluelicks'.
>
> But it *is* pronouncable, and you don't need to insert vowels, either.
>
> Glulx == `glulks'
> Glulxe == `glulksey'
> Glk == `gl@k', where @ is a schwa
>
> What's the problem?
Glulx seems to alternate, with me, between Glux (forgetting about the
other l), or, when I recall the l, Glulix. I can see it becoming a
religious issue, with people spelling it out, half-spelling and half
saying it("Glue-L-X"), and inventing their own unique ways of saying it.
How does Zarf pronounce it?
--Arcum Dagsson
"What is the point of treating him to a complete sprng-clean,
polishing all the bits and bobs with beeswax, and scrubbing his
terminals with soapy water, if he's going to go all peculiar?"
Andrew Plotkin
> How does Zarf pronounce it?
I pronounce it the way Goob does.
Ricardo Dague
>
> Glulx seems to alternate, with me, between Glux (forgetting about the
> other l), or, when I recall the l, Glulix. I can see it becoming a
> religious issue, with people spelling it out, half-spelling and half
> saying it("Glue-L-X"), and inventing their own unique ways of saying it.
We should pronounce it "glue lox" to rhyme with Maalox. This
may become useful once we start writing games int it. ;)
-- Ricardo