There have been problems with the inform7 Eg*-C tests, but apart from that everything else should pass. Admittedly it’s been a few days since I ran all tests to check, though.
Actually this was a probably a case of me getting mixed up on my steps and not doing what Adrian suggested. I had only created empty Tx directories instead of copying them with their contents. When I do this, then make check at least fully runs. The “indoc” tests still appear to fail on Windows (in Cygwin context):
All 4 tests failed (time taken 0:03, 4 simultaneous threads)
But the rest of the tests do actually run, which wasn’t happening previously. So that’s a key step: make sure you create the extra directories that link up with the logical core processors in your CPU. And don’t just create the directory; copy one of the existing Tx directories.
That said, even though all tests run now there are still quite a few failures I’m seeing beyond just the indoc ones. The output for the “-from inform7 all” tests shows a lot of issues that I don’t see when I run on MacOS. All 1987 tests succeed on Mac. On Windows, 21 of those fail. I see things like this:
[652] Eg6-C made, but produced the wrong output
Discrepancy at line 2:
make[2]: Entering directory '/home/jeffn/i7/inform/inform7/Tests/Test Makes/Eg7-C'
Discrepancy at line 6:
Sir Arthur Evans, hero and archeologist, invites you to explore...
Discrepancy at line 7:
Sir Arthur Evans, hero and archeologist, invites you to explore...
Discrepancy at line 8:
Welcome
Discrepancy at line 9:
An Interactive FictionWelcome
Discrepancy at line 10:
Release 1 / Serial number 220409 / Inform 7 v10.1.0 / DAn Interactive Fiction
Discrepancy at line 11:
Release 1 / Serial number 220512 / Inform 7 v10.1.0 / D
Discrepancy at line 12:
Jarn Mound
Discrepancy at line 13:
You can see a Linear B tablet here.Jarn Mound
Discrepancy at line 14:
You can see a Linear B tablet here.
...and so on (stopped reading after 10 errors)
Notice how some of that looks like line break issues.
As another example, I see these failures on Windows but not on Mac:
Discrepancy at line 2:
inter: kit sourceinform 6 syntax error in function 'E1': operator '+' used with 1 not 2 operand(s)
Discrepancy at line 3:
inter: kit sourceinform 6 syntax error in function 'E2': do without until
Discrepancy at line 4:
inter: kit sourceinform 6 syntax error in function 'E3': expected 'on' or 'off' after 'font', not 'whatever'
Discrepancy at line 5:
inter: kit sourceinform 6 syntax error in function 'E4': move without to
Discrepancy at line 6:
inter: kit sourceinform 6 syntax error in function 'E5': 'for' header with too few clauses
Discrepancy at line 7:
inter: kit sourceinform 6 syntax error in function 'E6': 'for' header with too many clauses
Discrepancy at line 8:
inter: kit sourceinform 6 syntax error in function 'E7': unexpected '{ ... }' code block
Discrepancy at line 9:
inter: kit sourceinform 6 syntax error in function 'E8': unexpected '{'
Discrepancy at line 10:
inter: kit sourceinform 6 syntax error in function 'E8': unexpected use of reserved word 'print'
Discrepancy at line 11:
inter: kit sourceinform 6 syntax error in function 'E8': unexpected '}'
That’s from the intest -from inter all test run.
Probably also worth noting that while the above is what I see in the Cygwin context, in the WSL context, I don’t see most of those errors at all. I still see the “inter” ones but that’s it. But I suppose in a WSL context you’re not actually building Windows executables if that’s what you want to do.
As I mentioned, the Eg*-C tests have some problem I’ve not looked into, and now one inter testcase (“BadKit”) also fails, though that doesn’t look very significant. Everything else passes.
The BadKit test fail mentioned by David was on me, and is not a Windows problem. It’s fixed in the latest commit, Added -build-locate and -use-locate options to inbuild · ganelson/inform@9521282 · GitHub
4 Likes
Recent updates have fixed the segfaults I mentioned earlier. I’m going to wait to update the smoketest results until I’ve added something to exclude all the stuff that doesn’t compile under 6M62, which will make for more meaningful results.
2 Likes
would a Windows user mind trying to compile the following in v10, please?
Lab is a room.
Persuasion: if "" is the topic understood, do nothing.
Compilation errors out with “inform7: fatal error: Out of memory for text stream storage” on Linux but not Mac OS.
OK, fresh results, as of v10 commit 4bd2c0a (which, at the rate that Graham has been fixing bugs is two commits old as of this writing):
v10 extension smoketest results
6M62 extension smoketest results
This omits extensions that don’t compile under 6M62 (so 6M62’s errors page is bare). It also compiles Extension examples and embeds their ‘test me’ output, if any, and provides a link to play the compiled example.
Things I learned while extracting and compiling examples and diffing the output between 6M62 and v10.
There are lots and lots of incorrectly formatted examples. My extraction code probably isn’t perfect, but there’s a lot of extensions whose examples have whitespace issues.
Obvious in hindsight:I really should have used -rng; there are bunches of meaningless diffs 'cause the output had a random element.
6M62 had a bug in specified units scaled at something; v10 fixed it.
There are a bunch of minute Standard Library response changes. [ Edited: this is wrong; I was seeing the effect of extensions themselves. ]
And then things I didn’t find: there aren’t any cases where an example compiled on 6M62 and its extension compiled on v10 but the example didn’t. There was no sign of any behavior changes: it looked like the things I described above accounted for all the differences in output.
Edited: v10 now reflects commit 904d8ef; 6M62’s errors page is populated again; rubric detection fixed; some of the more gratuitously ugly formatting issues fixed. Many remain…
v10 results updated for v10 commit 87b3b71 … not much is changing now other than formatting, so I won’t keep posting updates; I’ll just name the commit on the v10 extension Current page itself.
6 Likes
Ardimaster has found that it compiles on Windows, and on Linux using clang 13 or (out just this monh) gcc 12, so the only known failures are with gcc 10 or 11 on Linux: it looks like a gcc bug.
Inform7 v10 compiles fine on my RPi 4, RaspiOS 64 with gcc 10.2.1.
1 Like
v10 compiles fine; but so far as it’s been tested, but if you then use it to compile the Inform 7 snippet I posted above then that compilation fails if you had built I7 with a gcc prior to 12.1 (well, at least the failure has been seen on a specific subversion each of gcc 10 and gcc 11). If you’d like to try it, I’d be interested in seeing if your different architecture made a difference.
1 Like
I have yet to use v10 with non-included extensions. I will see if I can work out a test.
PS. RaspiOS / gcc is based upon Debian(10.2.1-6)
Thank you
Unless I misunderstand something, the snipped compiles fine on my RPi.
1 Like
I haven’t figured out how to make an account on the new bug tracker, nor have I set up my own Github clone of the main Inform repository. However, I would like to push a bugfix upstream. This is the fix for which I wrote the extension Parser Error Number Bugfix.i7x when Inform was not open source. I’m not sure whether that could be fixed by an extension currently; it was really a hacky job.
But this is just a straight-up bug and it really should just be fixed properly in the core Inform release.
What happened is that two parser errors were swapped into the wrong order in I7 code, creating a mismatch with the I6 code and causing the wrong error to be reported.
A git diff is attached. If someone could get this into upstream it would be much appreciated.
parser-error-number-bugfix.diff.txt (778 Bytes)
1 Like
Regarding incorrectly formatted examples, the Inform standard is actually seriously obnoxious; switching from a project to an example requires adding an extra tab in front of everything, while switching the other way requires removing an extra tab. It means you can’t copy-paste between examples and projects. I know I introduced whitespace errors repeatedly during this manual editing when trying to copy-paste between examples and projects.
On top of that, hard tabs are out of fashion these days and required reconfiguring my text editor – I really wish Inform did something more like Python does with space-based indentation. Oh well, I know that would be hard to program.
To save somebody the trouble of opening a pull request, I’ve just gone ahead and made Nathanael’s fix for the parser errors being the wrong way round. This causes no problem for anything in the test suite (except to one of the index test cases, because it means the enumerated errors are listed in a different order in the index), and is clearly a clean fix. Thanks.
10 Likes
Thanks so much, Mr. Nelson. 
2 Likes
Wow. It’s probably boring to read that version 10 just works, but it pretty much does. Thank you!
I built it yesterday and tried it on my medium-sized work in progress. I removed one old bug workaround, found and reported a new bug that was already fixed when I checked after work today, and tweaked Eric Eve’s Bulk Limiter as mentioned upthread.
Thanks to Andrew Plotkin’s regtest.py, I was able to confirm output is essentially the same as with 6M62 and I will (hopefully) finish this soon with the latest release.
3 Likes
I’m not sure if is an issue or not, but I suspect that there’s much (now collective) work to do on code generation.
compiling the generated I6 code with this:
inform/inform6/Tangled/inform6 -w -G -~D '$OMIT_UNUSED_ROUTINES=1' <WIP>.inform/Build/auto.inf -o <WIP>.inform/Build/<WIP>.ulx
I got this surprising return on unused routines & warnings:
108472 unused bytes stripped out (23.6%)
Compiled with 3532 suppressed warnings
for the record, the entire report is:
Inform 6.36 for Linux (24th January 2022)
In: 1 source code files 92501 syntactic lines
81605 textual lines 2432037 characters (ISO 8859-1 Latin1)
Allocated:
9681 symbols 3451635 bytes of memory
Out: Glulx story file 1.220519 (570K long):
23 classes 89 objects
230 global vars 92397 variable/array space
84 verbs 372 dictionary entries
149 grammar lines (version 2) 226 grammar tokens (unlimited)
82 actions 40 attributes (maximum 56)
39 common props (maximum 253) 30 individual props (unlimited)
458673 bytes of code 108472 unused bytes stripped out (23.6%)
127097 characters used in text 99485 bytes compressed (rate 0.782)
0 abbreviations (maximum 64) 3306 routines (unlimited)
79528 instructions of code 44971 sequence points
133376 bytes writable memory used 449792 bytes read-only memory used
583168 bytes used in machine 1073158656 bytes free in machine
Offsets in story file:
16c85 Synonyms 1c8aa Defaults 16c89 Objects 177a9 Properties
00000 Variables 1e7a2 Parse table 1f008 Actions 1f154 Preactions
1f154 Adjectives 1f154 Dictionary 0003c Code 55835 Strings
Compiled with 3532 suppressed warnings
Completed in 0.000 seconds
I can only surmise that there’s many thing to polish in the “pass 1” (inform7, formerly ni) code generation.
Any comments ? (I guess that this is a difficult question even for Lord Inform itself and Uncle Zarf…)
Best regards from Italy,
dott. Piergiorgio.
That’s not code generation, that’s low-level support for features not used in every game. You’d have to do an inventory to see exactly what’s involved.
Quite possibly the right answer is to let I7 do what it does and then use OMIT_UNUSED_ROUTINES.
thanks, Zarf !