Piergiorgio found a bug when games are compiled using the Unix hc compiler.
It appears that if an object has two nouns and is referred to by the two nouns, the interpreter will crash.
I could not replicate this with the same code compiled by the Windows version of hc.
Piergiorgio - I can upload a zip file with the test code in it but you probably don’t want your WIP uploaded. We can try to make a simple file that replicates it as well but I won’t be able to do that until after Christmas. The bug is pretty easy to replicate, however:
Create an object
Give it like 4 nouns (I am putting commas after each noun, and I ensured the nouns have double quotes around them)
Compile the game, Unix compiler only.
Do something like >x firstnoun secondnoun
The game crashes, I haven’t tried it with the debugger yet.
Let me hand that off to @Piergiorgio_d_errico - can you make a zip file with the minimum that shows the error? (I don’t want to post what you gave me because you may not want that distributed.)
For the record, I’m using Tessman’s standard lib, not your excellent lib, because I wanted a simple thing, whose, as usual in coding, is turned into a not-so-simple thing…
Well, hopefully people eventually feel comfortable enough with Roodylib that they use it for simple projects as well, but no worries, of course. Always good to find another Hugo enthusiast, and thanks for bringing that bug to our attention!
I’ve gotten a bit further with hunting this bug. I compiled the same source with both Linux and Windows and compared the resulting .hex files. The only difference was in the part that corresponds to the Hugo Library’s line 1005 in hugolib.h:
if VerbWord = "give", "offer", "hand", "show"
This code is reached when the parser returns error number 5 which happens when the noun part of the command doesn’t match anything but consists of multiple valid dictionary words. Normally it would reply with either “Not sure what you’re referring to” or “You haven’t encountered anything like that” error message. So in addition to referring to an object with two different synonyms it’ll also crash when you repeat a word (X FOX FOX) or use the names of two separate objects (X FOX ME).
When compiling on Linux the above line compiles to this (made more readable by replacing hex codes with token names and actual dictionary words):
if routine#0x9e0 = dictEntry#"give" or
routine#0x-810 = dictEntry#"offer" or
routine#0x-810 = dictEntry#"hand" or
routine#0x-810 = dictEntry#"show"
The first routine address is correct, the rest are nonsensical. As soon as an interpreter tries to look up a negative routine address, it crashes. The Windows version uses the 0x9e0 address for all of them. Routine#0x9e0 returns the value of VerbWord.
I haven’t figured out yet what the actual bug in the compiler is but I assume it’s somewhere in hccode.c at around line 954 which looks like it handles the comma shortcut.
Before the compiler is fixed the workaround is to avoid the if x = a, b, c shortcut and write it fully as if x = a or x = b or x = c instead. Line 1005 in hugolib.h can be rewritten as:
if VerbWord = "give" or VerbWord = "offer" or VerbWord = "hand" or VerbWord = "show"
Awesome - I hit approve. I can’t remember how I compiled the Unix Hugo compiler back in the day, but once that is merged I can try to do that and check it out.
It also occurs to me that I even I didn’t specifically know that we had moved it to Github. With the Hugo By Example Wiki permanently down, I think maybe we might need a single webpage somewhere that says where to get Hugo stuff. Maybe the Hugo entry for IF Wiki? Would anyone object if we make that the central “current information portal” or whatever for Hugo? And I can throw links to get people there and also mention where the repos and executables are for the Hugor interpreter as well as this Unix compiler.
Sorry for the delay (italian festivities are rather peculiar, more so when the current covid issue is added…) but indeed now I have recompiled from the current github source, and the correct compilation points toward an interesting error of mine:
x facade
The facade of the solarium is painted in a light shade of green, so it blends
well with the environment.
x solarium facade
You haven’t encountered any “solarium facade”. (If you’re sure you need to
refer to that, try putting it another way.)
x solarium
The facade of the solarium is painted in a light shade of green, so it blends
well with the environment.
x green solarium
The facade of the solarium is painted in a light shade of green, so it blends
well with the environment.
x green solarium facade
You haven’t encountered any “green solarium facade”. (If you’re sure you need
to refer to that, try putting it another way.)
obviously, seems that hugo (as language) interprets “solarium facade” as a different item.
oh, bah. Let’s leave players whose lack understanding of saxon genitive in their misery (the original rationale of that synonim…) and implement solarium as adjective, in form of “solarium’s facade”
Thanks to Robb, Juhana and everyone, and
Best regards from Italy,
dott. Piergiorgio.
UPDATE: in a big twist I can’t explain well, with this coding:
scenery facade "facade"
{
in patio
nouns "facade"
adjective "green", "solarium's"
long_desc {"The facade of the solarium is painted in a light shade of green,
so it blends well with the environment."}
}
and Juhana’s path, EVERY 2-3-4 words combination of facade, solarium, green and solarium’s now work normally, without crashing. (I suspect that dictionary truncating does the unexpected trick of parsing both “solarium” and “solarium’s” as referring to the facade object…)
Aside my hunch, I leave the mystery to people whose delve in the innards of the compiler and library and I remain content of having the code doing what i wanted.