It turns out this is a known but yet unresolved bug. I’m not sure yet if the following is an actual fix or just some band-aid that hides the real problem, which is why I didn’t push it to the repo. I need to run TADS base code changes though Mike Roberts, but he didn’t have time to deal with this yet.
If you want to test this out, open the tads3/tcprs.cpp file and at line 1044 you will find this:
Replace that whole function with the following and rebuild t3make (make t3make should be enough in this case):
/*
* Create a symbol node
*/
CTcPrsNode *CTcParser::create_sym_node(const textchar_t *sym, size_t sym_len)
{
/*
* First, look up the symbol in local scope. Local scope symbols
* can always be resolved during parsing, because the language
* requires that local scope items be declared before their first
* use.
*/
if (local_symtab_ != 0) {
CTcPrsSymtab *symtab;
CTcSymbol *entry = local_symtab_->find(sym, sym_len, &symtab);
/* if we found it in local scope, return a resolved symbol node */
if (entry != 0 && symtab != global_symtab_)
return new CTPNSymResolved(entry);
}
/* if there's a debugger local scope, look it up there */
if (debug_symtab_ != 0)
{
/* look it up in the debug symbol table */
tcprsdbg_sym_info info;
if (debug_symtab_->find_symbol(sym, sym_len, &info))
{
/* found it - return a debugger local variable */
return new CTPNSymDebugLocal(&info);
}
}
/*
* We didn't find it in local scope, so the symbol cannot be resolved
* until code generation - return an unresolved symbol node. Note a
* possible implicit self-reference, since this could be a property of
* 'self'.
*/
set_self_referenced(TRUE);
return new CTPNSym(sym, sym_len);
}
Is what I have dedicated my afternoon and night, after a cooldown from tackling the year-old issue. Indeed work, but with really strange results (smaller binaries when built with -d (debug), both with standard adv3 and adv3lite a very anomalous thing I’m still investigating)
Currently I consider unpatched TADS3/standard adv3 as “production grade” and patched TADS3/adv3lite as “experimental”. (I have patched your current github frobTADS, last commit 13 June this year)
Thanks and best regards from Italy,
dott. Piergiorgio.
do you want me to try reverting the cmake-related files to the prior master version (a simple backup of the branch files followed by a cp -a of the cmake-related files from the master dir) ?
[BTW, I have decided to NOT entry this year’s IFComp, so I have IF-dev time available…]
Looks like older cmake versions still need a DESTINATION specified for executables. Fixed in all branches and rebased the fix-null-local-symbol-table-lookup branch and force-pushed it. So make sure to
That’s quite normal. You need to use -d -pre instead of just -d, because pre-initialization is not performed by default in debug builds like it is in release builds. Or the other way around, use -nopre when doing a release build to prevent pre-init. That way you’re not comparing apples to oranges.
I’ll do some more testing, involving also the standard adv3 library, then, if successful, the patched “fix-null-local-symbol-table-lookup” build (the …/t3mak0830 above) will be installed, as t3make, into /usr/local/lib and promoted to “production” status; anyway, your final suggestion, the one about switches, gets the deserved “solution” flag. Thanks, kudos and
indeed something has popped up: with adv3 all works as expected with -nopre, with adv3lite, the -nopre story files simply don’t run, all four 'terps (frob, qtads2, qtads3 and gargoyle tadsr) giving
Runtime error: nil object reference
[Hit any key to exit.]
summing all up, my diagnosis is what seems NOT production-grade is adv3lite… but I’m reasonably sure that adv3 works as expected (and -nopre under adv3 giving avg ~50-60k smaller story files…)
Not a real problem. the actual one, now solved, was the capability of experimenting and fooling with adv3lite; if something there has general usefulness, perhaps I’ll attempt to implement/port it as an adv3 extension.
I guess that you can safely merge the fix, with an proviso in the documentation (in the changelog, perhaps ?) about the much larger (doubled in size) story files generated by adv3lite.
I guess we have closed the issue, or you want me to do some specific tests ?
Thanks again, and
Best regards from Italy,
dott. Piergiorgio.