|Anonymous | Login | Signup for a new account||2017-03-25 18:30 PDT|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001592||Documentation, Examples, and Web Site||Examples||public||2015-03-31 11:42||2016-12-15 15:01|
|Status||resolved||Resolution||no change required|
|Target Version||Fixed in Version|
|Summary||0001592: Example 228 Otranto: Use of "Actions" testing command alters program flow.|
|Description||By turning action listing on, the outcome of the actions differ. See additional information below for transcript. As action listing is often used to bug hunt, having it cause bugs is very bad.|
The bug is probably not limited to this example, but it's where it's easiest to detect and reproduce. I've seen something similar happen in a story I was working on earlier, but I don't have the sourcecode for that available.
|Minimal Source Text To Reproduce|
Use example 228 ------ A reduced example which demonstrates this: A rope is a kind of thing. Definition: a thing is nonrope if it is not a rope. Attachment relates things to each other in groups. The verb to be stuck to means the attachment relation. Definition: a thing is tied if the number of things stuck to it is greater than 1. Definition: a thing is hindering if it is stuck to the noun and it is not within the location. Definition: something is anchored if it is fixed in place or it is scenery or it is part of an anchored thing. Definition: a thing is pullable if it is not the noun and it is not the player. After reading a command: now every thing is unmentioned. Instead of pulling something tied: if the noun is unmentioned: say "The impulse is transmitted to [the list of pullable things stuck to the noun]."; repeat with item running through pullable things stuck to the noun: say "[item]: [run paragraph on]"; try pulling the item; if the noun is a rope and the noun is not within the location: if the number of nonrope hindering things is 0, move the noun to the location; otherwise: continue the action. Before pulling something which is not visible: if the noun is anchored: say "[The noun] resists, for whatever reason." instead; otherwise: let space be the holder of the noun; let way be the best route from the space to the location; if the way is a direction: move the noun to the location; say "[The noun] [if the way is up]rises[otherwise]slides[end if] into view." instead; otherwise: move the noun to the location; say "[The noun] slides into view." instead. The Fallow Field is a room. "The very land is gloomy, the earth plowed into untended rows that yield no fruit, shadowed by the castle to the north. A chasm, no doubt the product of some upheaval of the earth, opens before your feet.". An oak stump is fixed in place in the Field. A hempen rope is a rope in the field. It is stuck to the oak stump and the wooden chest. The Chasm is below the Field. "Your person is most uncomfortably pressed on every side by the closeness of the walls; to which you may add as a further inconvenience, that the irregularity of the floor making it difficult to walk upright." The wooden chest is a closed openable container in the Chasm. The description of the wooden chest is "A handsome, solid case not long committed to its dank enclosure, or it would long since have rotted." Rule for printing the name of the wooden chest when the chest is not handled: say "deadweight". Understand "dead" or "weight" or "deadweight" as the chest. Before pulling the wooden chest: now the chest is handled.
Actions listing on.
[pulling the hempen rope]
Nothing obvious happens.
[pulling the hempen rope - succeeded]
Actions listing off.
The impulse is transmitted to the oak stump and the deadweight.
oak stump: The oak stump is firmly anchored.
deadweight: The wooden chest rises into view.
|Tags||No tags attached.|
So, this code depends on the "mentioned" property. This is the direct cause of the problem: the actions listing prints object names, which sets the "mentioned" property, which changes the code behavior.
You could argue that debug messages should not change any state at all. However, this is hard to guarantee in general. A "printing the name of..." rule can always change state. In this case, the standard "make named things mentioned" rule sets the mentioned flag.
(Debug code could skip the "printing the name of..." activity when listing object names, and go directly to the printed name property. That would fix this particular bug -- but it would also make debugging output less informative. And there could *still* be state changes, e.g., when the printed name of a thing is "[one of]X[or]Y[or]Z[cycling].") (Which is itself a tricky case, but let's not go down that grue-pit.)
I'd argue that the example code is buggy, or at least fragile. It's trying to use "mentioned" as a proxy flag for "already pulled by the chain of stuck-together things". It would be better to create a separate flag:
A thing can be pull-processed. After reading a command: now every thing is not pull-processed. Instead of pulling something tied: if the noun is not pull-processed: say "The impulse is transmitted to [the list of pullable things stuck to the noun]."; repeat with item running through pullable things stuck to the noun: now item is pull-processed; say "[item]: [run paragraph on]"; try pulling the item; if the noun is a rope and the noun is not within the location: if the number of nonrope hindering things is 0, move the noun to the location; otherwise: continue the action.
(This is not a complete fix. Other pull responses would need to set the pull-processed flag.)
|There are arguments on both sides (well, see above), but I agree with Zarf on this.|
|This was marked "resolved" for 6L38 but the code and behavior in 6M62 has not changed.|
|2015-03-31 11:42||FictitiousFrode||New Issue|
|2015-03-31 13:33||zarf||Steps to Reproduce Updated||View Revisions|
|2015-03-31 13:51||zarf||Note Added: 0003391|
|2015-09-03 11:15||graham||Note Added: 0004127|
|2015-09-03 11:15||graham||Status||new => resolved|
|2015-09-03 11:15||graham||Resolution||open => no change required|
|2015-09-03 11:15||graham||Assigned To||=> graham|
|2016-12-15 15:00||zarf||Note Added: 0004634|
|2016-12-15 15:01||zarf||Summary||Example 228: Use of "Actions" testing command alters program flow. => Example 228 Otranto: Use of "Actions" testing command alters program flow.|
|Copyright © 2000 - 2010 MantisBT Group|