Rebuilding TADS3 For Parchment?

Authoring TADS
1

Is there an “official” method for building a new rev of TADS3 for Parchment?

Discovered that there’s a bug (in Date.getClockTime()) that’s patched in the current version of e.g. frobTADS but still appears in the Parchment TADS3 interpreter.

Very simple, non-interactive demonstration:

#charset "us-ascii"
#include <adv3.h>
#include <en_us.h>

#include <date.h>

versionInfo:    GameID
        name = 'sample'
        byline = 'nobody'
        authorEmail = 'nobody <foo@bar.com>'
        desc = '[This space intentionally left blank]'
        version = '1.0'
        IFID = '12345'
;
gameMain:       GameMainDef
        newGame() {
                local d;

                // Because from 00:00 to 00:59 the hour really IS zero,
                // so our test will return a false positive.
                "NOTE:  Do not run this check in the hour of midnight.<.p> ";

                d = new Date().getClockTime();
                if(d[1] == 0) {
                        "This intepreter implements Date.getClockTime() incorrectly. ";
                        "<.p>The following should be the current hour, minute, second, and ms:<.p> ";
                        d.forEach(function(o) {
                                "<<toString(o)>> ";
                        });
                        "<.p> ";
                } else {
                        "This interpreter implements Date.getClockTime() correctly.<.p> ";
                }
        }
        sayGoodbye() {}
;

Compile and run it, and it (should) tell you whether or not the bug is present in the interpreter. The only caveat is that you can’t run it in the hour of midnight, because from 00:00 to 00:59 the hour actually is zero, so the simple test will return a false positive.

2

If you can submit a bug fix to the tads-runner repository then I’ll incorporate it in Emglken and Parchment soon afterwards. This will also help it get into Gargoyle etc.

Or even if you can’t submit a bug fix, if you can confirm the bug is also present in Gargoyle then you could make a bug report.

3

Yeah, it’s in Gargoyle as well; the code I posted is (as far as I know) a self-contained test that any TADS compiler will produce a working .t3 from.

I guess I can create a git account to report the bug later. But that aside: is there some sort of guide/documentation to building a new version of TADS to use with Parchment? Because that would be kinda useful in general, independent of this specific bug.

4

To rebuild TADS (within Emglken) follow the Parchment build instructions, then run:

npm run link-local-emglken

The TADS source files are in src/upstream/emglken/tads. Whenever you edit them, run npm run build in the Emglken folder, and then npm run build in Parchment.

1 Like
5

Cool, thanks.

6

What node/npm version(s) are required/supported?

Using the versions included with Ubuntu (jammy), which are v12.22.9 on node and 8.18.0 on npm there are multiple problems, starting with:

# npm install

> parchment@2022.6.0 prepare
> ./build.js

file:///usr/local/src/parchment/git/parchment/build.js:35
        copy: await readdir('src/fonts/iosevka'),
              ^^^^^

SyntaxError: Unexpected reserved word
    at Loader.moduleStrategy (internal/modules/esm/translators.js:133:18)
    at async link (internal/modules/esm/module_job.js:42:21)
npm ERR! code 1
npm ERR! path /usr/local/src/parchment/git/parchment
npm ERR! command failed
npm ERR! command sh -c -- ./build.js
7

Node 12 is past end of life. I recommend you update to Node 18.

8

Cool, thanks. That’s just the version Ubuntu-current comes with, and if I was going to have to install a different version I wanted to know what version parchment expects (and “the most recent one” isn’t always a good guess in IF-related projects).

9

Yeah I should probably be more careful with that. I do tend to just start using things as they become available in recent versions.

10

Having the current release of an open source project depend on the current revs of the build tools required to compile/package/whatever it makes perfect sense.

And as someone who doesn’t really want to have to spend a lot of cycles worrying about the care and feeding of every tool/library/whatever my pipeline uses, I’d much prefer everything just require whatever’s current. Instead of having to figure out how to hammer together a build environment using a combination of random out-of-date version numbers. Which seems to happen way to frequently in open source development.

1 Like