TADS 3.1.3 now available

In case anyone missed it, an updated version of TADS 3 (TADS 3.1.3) is now available from http://www.tads.org.

The FrobTADS update that goes with it (v1.2.3) is now also up at tads.org/frobtads.htm.

Hooray! Now I don’t have to run recent T3 files in the DOS interpreter. :smiley:

Do you mean on OS X? There are actually no VM changes, so the previous version runs 3.1.3 games just fine.

I meant the TADS 3 update, not FrobTADS. The previous version of TADS had a problem that kept the Windows interpreter from running on my computer, which has now been fixed.

Hello everyone:

Testing our WIP adaptation/translation of adv3 to spanish, we’re getting TCERR_NON_ASCII_SYMBOL errors with 3.1.3 (frobtads 1.2.3 here; other people using the windows installer reported the same).

An example, from a line using the defOrdinal macro (there’re similar errors involving defDigit):

defOrdinal(séptimo, 7);

Macro defined as usual:

#define defOrdinal(str, val) object ordinalWord=#@str numval=val

Looking at the preprocessed output (with -P)

[code][…] /es_es.t(8097): error:
The symbol “séptimo” contains one or more non-ASCII characters (the first is
[Unicode] character U+00e9). Only plain ASCII characters can be used in
symbols; accented letters and other non-ASCII characters aren’t allowed.

object ordinalWord=‘séptimo’ numval=7;

To me, this looks OK (the stringizing seems applied), but the compiler treats the word as a symbol. Maybe the checks in the tokenizer are not correctly aligned with the preprocessor in this case, or something like that (just thinking out loud, with no knowledge of the internals).

Is this expected behaviour?

If more info or a proper bug report at tads.org are needed, just ask for it, please. This is just a naive first contact.

Thank you very much for your time.

Sincerely yours,
[size=85](Long time avid lurker, first post. Please, excuse my english.)[/size]

This does look like a bug, so opening a report on bugdb.tads.org is appropriate.

Done, #0000199 TCERR_NON_ASCII_SYMBOL / Macro Stringizing

I’m confirming this too, I have same problem. Possible workaround is to use expanded definition instead of macro, then it will work. Please note that quoting numerals in macro will make it compile, but not work at runtime, so quoting is not a workaround.

The bug #0000199 is marked as fixed. The fix will be released with 3.1.4 (as bugtracker states).

Is there any public source code repo to track/test this (or any other) improvement before releases?

Unfortunately, no. There was some brief talk in the past about setting up a Git repo for the official sources, but nothing came of it.