http://www.ifarchive.org/indexes/if-archiveXprogrammingXglulxXinterpretersXgit.html
This is a new version from Iain. The change from 1.2.1 is the addition of a
patch from me to add support for the new Glulx 3.1 opcodes @malloc and
@mfree, which Inform 7 makes use of for indexed text. As a result, there
should be no Glulx features used by Inform 7 games that Git does not support.
Much of the credit for the new opcode support should go to Zarf, as I have
shamelessly stolen the heap implementation from Glulxe. However, if you come
across any problems with this, it's probably best to hassle me first :)
A new Windows build of 1.2.2 is available from the same location on the
Archive. This has also been compiled with GCC 2.95, allowing Git's "direct
threading" mode to be used, which gives a ~15% speedup over previous Windows
builds.
David
This is great news. Thank you!
jb
You are super, David. You are the IF plumber fixing small leaks, here
and there, polishing the IF experience for everyone and that is a very
important role because most users will not be tolerant of any kind of
annoyance during play.
Kritsada Piriyakitpaiboon
I like that :-)
David
FWIW, GCC 4.2 also compiles Git with "direct threading" mode enabled.
Thanks for the patch! This will make Gargoyle users happy as well.
I got it to work with GCC 4.3, too. The resulting executable was
substantially (about 10%) slower than that produced with GCC 2.95, though.
David
What do you use to benchmark the speeds? I've just been loading up
the latest release of Alabaster and estimating the initial load time,
so anything more sophisticated would be an improvement on my technique.
I'm not using anything much more sophisticated - I have a hacked version of
my Glk library that will run through a text file of commands then print the
time taken from start-up to shut-down, and I ran that on play throughs of
Alabaster and Eric Eve's Nightfall.
David
This presents a name collision between this interpreter and the
source-code organizing program of the same name. Could we consider a
name change? Perhaps "gin" or "glin"?
--
David Griffith
dgr...@cs.csbuak.edu <-- Switch the 'b' and 'u'
I am in no way affiliated or connected with either Git, and thought I
should make it clear before my post - I speak for no one but myself
(nice and redundant, just the way I like it).
According to http://git.kernel.org/?p=git/git.git;a=tags, the source-
code organizing program dates from two years ago. If this information
is incorrect, then the program should make the information easier to
find.
According to http://diden.net/if/git/releases/, the interpreter dates
from October 2003.
Apparently the interpreter is older, and if anyone has to change names
is the source-code organizing program.
That said, I see no reason why they shouldn't both have the same name.
Check out http://www.audacity.com/ for an example of a name clash that
was fully taken in stride. People who want the source-code program
will get to it, and people who want the interpreter will find it. We
should all be living in peace, harmony and weed.
To paraphrase a classic movie, why should the Glulx interpreter change
its name? The source control system is the one that sucks.
vw
> To paraphrase a classic movie, why should the Glulx interpreter change
> its name? The source control system is the one that sucks.
>
maybe because one is famous, the other one is not? ;)
Personnally I don't care, but I think it's generally not a so good idea
to have a project with a 3 letters name.