i7 / inform7-bugs Goto Github PK
View Code? Open in Web Editor NEWUnofficial bug tracker for Inform 7
Unofficial bug tracker for Inform 7
In general i7's rules for choosing the right function to use when you define another function of the same name but more specialised parameters works brilliantly. But when you define a function with multiple parameters and different levels of specialisations, you give it an impossible choice to decide, and it gives no warning of any ambiguity. It took me a day recently to work out why my function wasn't being called.
To make it clear, if I have
To compute some action on (T - a box) by (P - a person):
To compute some action on (T - a cube) by (P - a person):
To compute some action on (T - a box) by (P - a postman):
I wish the compiler could warn that it had been given an ambiguous choice, and which it selected.
test abcd-e-f with "x me/i".
test abcd-e-g with "l".
When compiling to Z-Code, these tests get the same dictionary entry. It should warn or error when you attempt this.
As discussed here: https://intfiction.org/t/unexpected-arithmetic-results-why/50495
When writing a "to decide" phrase for some block value type (e.g. text) but never using the "decide on ..." phrase, the compiler gets itself confused on the function arguments and generates nonsense code.
As discussed in this IntFiction thread, this sample code:
Lab is a room.
When play begins:
let C be "1234567890123456789012 123456789012345678901234567890123";
let commandWord be "xyzzy";
repeat with CWI running from 1 to the number of words in C:
now commandWord is word number CWI in C;
say "Word [CWI] is: [commandWord].";
produces a BlkValueWrite: writing to index out of range error. A similar error can occur looping over lines instead of words when going from a shorter line to a longer line.
This code by Peter Bates is a fix:
Include (-
Replace TEXT_TY_BlobAccess;
-) after "Definitions.i6t".
Include(-
[ TEXT_TY_BlobAccess txt blobtype ctxt wanted rtxt
p1 p2 cp1 cp2 r;
if (txt==0) return 0;
if (blobtype == CHR_BLOB) return TEXT_TY_CharacterLength(txt);
cp1 = txt-->0; p1 = TEXT_TY_Temporarily_Transmute(txt);
cp2 = rtxt-->0; p2 = TEXT_TY_Temporarily_Transmute(rtxt);
TEXT_TY_Transmute(ctxt);
! ########### insertion begins ###########
if (ctxt) BlkMakeMutable(ctxt);
! ########### insertion ends ###########
r = TEXT_TY_BlobAccessI(txt, blobtype, ctxt, wanted, rtxt);
TEXT_TY_Untransmute(txt, p1, cp1);
TEXT_TY_Untransmute(rtxt, p2, cp2);
return r;
];
-) after "Output.i6t".
Two examples use "examine text printed", but the meaning of the variable isn't documented.
ambiguously plural
is used in an example, but not officially documented.
As discussed in mapped above, mapped below.
The Standard Rules had this in 6L02:
The verb to be above means the mapping up relation.
The verb to be mapped above means the mapping up relation.
The verb to be below means the mapping down relation.
The verb to be mapped below means the mapping down relation.
This gave rise to bug 1373, where the following:
The parlor is a room.
The attic is a room above the parlor.
The parlor is below the attic.
resulted in:
parlor
>u
attic
>u
parlor
>
so it was changed to this in 6L38 (and 6M62):
The verb to be above means the reversed mapping up relation.
The verb to be mapped above means the reversed mapping up relation.
The verb to be below means the reversed mapping down relation.
The verb to be mapped below means the reversed mapping down relation.
but this gives rise to this:
Lab is a room.
basement is a room.
when play begins: now lab is mapped above basement; now basement is mapped below lab;
producing:
Lab
>d
You can't go that way.
>u
basement
>d
Lab
>
Lab is a room.
A box is in the Lab.
When play begins, now the story tense is past tense.
results in "You could see a box here." when it should be there.
Fix:
The you-can-also-see rule response (F) is " [here]".
Inform has some built-in behavior around the word your
in the source text that doesn't seem to be documented anywhere (see #11). It treats the object as properly-named. But putting "your" in the printed name is perhaps not the most judicious choice.
See this example:
Your car is closed and enterable.
>enter car
You can't get into the closed your car.
Compare this to the result when "your" is treated like an indefinite article, akin to your local vicar:
>enter car
You can't get into the closed car.
The showme
command doesn't list correctly the contents of a container when it's part of something.
In the following example, the left drawer contains some documents while the right one contains a banana. The showme
output list the documents under the right drawer instead of the left one.
Test is a room.
A desk is a supporter in Test.
Left drawer and right drawer are containers part of the desk.
Some documents are in the left drawer.
A banana is in the right drawer.
Actual ouput
>showme desk
desk - supporter
Left drawer (part of desk) - open container
right drawer (part of desk) - open container
banana
documents
Expected ouput
>showme desk
desk - supporter
Left drawer (part of desk) - open container
documents
right drawer (part of desk) - open container
banana
The bug comes from the I6 template routine ShowMeRecursively
from Tests.i6t
.
It iterates in this order:
if (obj.component_child) c = c | ShowMeRecursively(obj.component_child, depth+2, f); if ((depth>0) && (obj.component_sibling)) c = c | ShowMeRecursively(obj.component_sibling, depth, f); if (child(obj)) c = c | ShowMeRecursively(child(obj), depth+2, f); if ((depth>0) && (sibling(obj))) c = c | ShowMeRecursively(sibling(obj), depth, f);
If you swap 2 & 3, it prints the correct output:
if (obj.component_child) c = c | ShowMeRecursively(obj.component_child, depth+2, f); if (child(obj)) c = c | ShowMeRecursively(child(obj), depth+2, f); if ((depth>0) && (obj.component_sibling)) c = c | ShowMeRecursively(obj.component_sibling, depth, f); if ((depth>0) && (sibling(obj))) c = c | ShowMeRecursively(sibling(obj), depth, f);
The documentation (§10.3. Using the Scene index) recommends this way to make a scene last 3 turns:
Train Stop ends when the time since Train Stop began is 3 minutes.
But if the scene began less than four minutes before midnight, this means it will never end!
The time of day
variable in Inform 7 is the current game time in minutes since midnight. At midnight, it is 0. So if the Train Stop scene occurs a minute before midnight, it happens at time of day 1439. When time of day passes 1439, it goes back to 0, assuming the standard pace of 1 minute per turn. Then time since 1439 (when Train Stop began) will be -1439 minutes. The next turn it will be -1438 minutes. One minute before the next midnight, the time since Train Stop began
will be 0. It will never be 3.
EDIT:
Fix courtesy of otistdog:
Include
(-
! ==== ==== ==== ==== ==== ==== ==== ==== ==== ====
! Time.i6t: Scene Questions (modified)
! ==== ==== ==== ==== ==== ==== ==== ==== ==== ====
[ SceneUtility sc task;
if (sc <= 0) return 0;
if (task == 1 or 2) {
if (scene_endings-->(sc-1) == 0) return RunTimeProblem(RTP_SCENEHASNTSTARTED, sc);
} else {
if (scene_endings-->(sc-1) <= 1) return RunTimeProblem(RTP_SCENEHASNTENDED, sc);
}
switch (task) {
1:
if (the_time >= scene_started-->(sc-1)) ! current time is the same or later than scene starting time, so no change
return (the_time - scene_started-->(sc-1))%(TWENTY_FOUR_HOURS);
else ! current time is less than scene starting time, so add a day to current time
return ((the_time+TWENTY_FOUR_HOURS) - scene_started-->(sc-1))%(TWENTY_FOUR_HOURS);
2: return scene_started-->(sc-1);
3:
if (the_time >=scene_ended-->(sc-1)) ! current time is the same or later than scene ending time, so no change
return (the_time - scene_ended-->(sc-1))%(TWENTY_FOUR_HOURS);
else ! current time is less than scene ending time, so add a day to current time
return ((the_time+TWENTY_FOUR_HOURS) - scene_ended-->(sc-1))%(TWENTY_FOUR_HOURS);
4: return scene_ended-->(sc-1);
}
];
-) instead of "Scene Questions" in "Time.i6t".
Inform has some built-in behavior around the word your
in the source text that doesn't seem to be documented anywhere. It sets the object to be proper-named
, printed name
to include "your", and indefinite article
to be none. All of this would be expected if it didn't treat "your" specially, but then it understands "my" for the object and not "your". There is also some undocumented special behavior around "my" in the parser and it's not clear how that affects it.
box is a thing. player carries box.
player wears a sweater.
When play begins:
say "The list of objects that player relates to by the possession relation: [list of objects that player relates to by the possession relation].";
results in:
The list of objects that player relates to by the possession relation: .
Workaround:
real-possession relates a person (called P) to a thing (called X) when P has X.
say " [list of objects that player relates to by the real-possession relation].";
https://github.com/Nuku/Flexible-Survival This is the code depot. When compiling, it fails with an error 11.
Translating the Source - Failed
The application ran your source text through the Inform 7 compiler, as usual, but the compiler unexpectedly failed. This should not happen even if your source text is gibberish, so you may have uncovered a bug in the program.
When a program like the I7 compiler fails, it typically returns an error number: this time, the number was 11, and that probably indicates that the compiler failed to manage its data structures properly. Perhaps you created a complicated situation on which it has not been fully tested.
The best option now is probably to reword whatever was last changed and to try again. Subsequent attempts will not be affected by the failure of this one, so there is nothing to be gained by restarting the application or the computer. A failed run should never damage the source text, so your work cannot be lost.
If you think it likely that the Inform 7 compiler is at fault, please check that you have the currently distributed build of the system: if you have, please consider taking the time to fill out a bug report at the Inform bug tracker (www.inform7.com/bugs). If you think the fault may be due to a problem in an extension you're using, then please contact the extension's author directly.
Sorry for the inconvenience.
Docs §27.29:
The token "{-counter:NAME}" expands into the current value of the counter, as a literal decimal number. The token "{-counter-up:NAME}" does the same, but then also increases it by one.
I think this is incorrect - {-counter-up:NAME}
doesn't expand into the value of the counter. Every instance in the Standard Rules looks like {-label:Say}{-counter-up:Say}
.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.