In generality, in older system languages like C, debug builds often zero-initialize variables, sanitizing them. Release builds usually leave them uninitialized. They are just how they are, whatever was in the memory. If something is depending on an initialized value then and it works in debug but not release, that is a possible cause. Not saying it is but have seen it plenty of times over the years.
Mmm, this issue isn’t the C compiler vs. debugger though, it’s the Dialog compiler vs. debugger… looks like Daniel did find back in mid-June that they’re generating slightly different IR for some reason…
Appears to be a scope problem as deallocation is happening in two different places.They are very far apart in debug v release. The thing being invoked looks like it is being done differently as well. invoke once v invoke tail once
A standard technique in C64 programming is to define multiple user-defined character sets, and swap them in and out. It’s not just a text game technique – it’s a standard way to do graphics for heavily graphical games, constructing the playfield out of 8x8 pixel tiles.
Having this available in the C64 Å-machine runtime would be very powerful. It would also take a significant amount of work, and would chew up memory that not every game would want to use, which would point in the direction of having two runtimes, and only use the multiple charset one where the game actually needs it.
It would be a really cool “nice to have” feature, though, enabling the use of whatever characters the author might wish to include, including potentially graphics for maps or signs or illustrations, and an entire italics font. (And perhaps bold and bold italics, though I’m less convinced that bold will work in an 8x8 bitmap.) A well-thought-out implementation could map some of the resulting characters back to graphics assets that the web interpreter could use when playing on the web.
It’s definitely not a “hack it in within the next month or so” thing, though.
Something I’d be curious about is to see if Dialog could be refactored as a C library that could be used from another engine such as Godot.
Theoretically possible, because of eval.c (the implementation behind the debugger). But I’m not sure I see the use case; a large part of Dialog’s elegance comes from how closely the language is tied to its I/O system.
Here’s an interesting little conundrum.
Currently, when there are multiple definitions for a meta predicate like (story title) or (style class @whatever), Dialog doesn’t raise a warning. It uses the first definition and silently ignores all the others.
This has tripped me up several times, so I’ve tentatively added a warning when this happens (pointing to which definition will be used and saying all the others will be ignored).
However, this means a bunch of existing Dialog code will throw warnings now. Previous versions of the standard library defined their own default rules for the meta predicates, for example, counting on them to be overruled by the author’s code. I’ve updated the library to change that, but anyone using an older library will get warnings now.
Similarly, some existing games define new style classes with the same name as stdlib ones, counting on them to silently override the library ones. (The Impossible Stairs does this with @status, for example.)
But is this a reason to not add the warnings? I don’t think so, personally. I think the benefit to authors is much higher than the cost; I’ve gotten burned before by accidentally defining something like (style class @tutorial) in two different places, for example.
What do you all think?
- Include the warnings. They’re useful.
- Don’t include the warnings. They’re annoying.
- Nuance (explain below)
0
voters
The way you describe it, I would want a warning if two of my files contained the same definition because that is probably a bug, but not if one of my files is conflicting with the standard library. Now, I know that Dialog treats the standard library as just another file with source code, so that’s asking for much.
I know I have at least a few places where I override the standard library style definitions on purpose.
Standard actions that require touching a person (that is, actions that require a touchable object but not a worn or held one):
- SEARCH (already has a default refusal for people)
- FEEL
- KISS (already has a default refusal for people)
- HUG (redirects to KISS)
- TAKE (usually people are not portable)
- PUT OBJ IN/ON/BEHIND/UNDER PERSON (usually people are not containers or supporters)
- GIVE OBJ TO PERSON
- OPEN, CLOSE, LOCK, UNLOCK (usually people are not openable or lockable)
- SWITCH ON/OFF/-- (usually people are not switchable)
- SQUEEZE
- FIX (usually people are not broken)
- EAT, DRINK, TASTE (usually people are not edible or potable)
- CUT PERSON WITH OBJ
- LOOK UP (usually people are not consultable)
- CLIMB, ENTER (usually people are not containers or supporters)
- PUSH PERSON DIR (usually people are not pushable)
- PUSH, PULL, TURN
- FLUSH
- CLEAN
- TIE ROPE TO PERSON (and UNTIE)
- ATTACK PERSON WITH OBJ (already has a default refusal for people)
I think the best practice there is to modify the library itself. Because the library definitely does expect people to override its definition of @meta, for example; but there’s no easy way to determine which clauses happen in library files and which ones don’t.
(Or is there…hmm.)
If you want to see what effect it would have on your projects, pull from this branch.
Would this warning only apply to a fixed set of predicates like (story title) or would it apply generically to all rules that can be proven to always succeed? (I.e. anything without parameters to match and not querying another predicate in their body.)
Either way I think it’s a bit… Weird? Personally. (I know that the recommended way of customizing library behavior is by editing the library file directly, but I still prefer to just override library predicates with rules in my code wherever possible.) A fundamental rule of Dialog is that the first succeeding rule (in source order) wins, adding a warning that more or less amounts to “but actually you should just edit the existing definition instead” feels out of place to me.
You could add some sort of [[library]] attribute to things defined in libraries, or a #pragma library on at the top of the file and off again at the bottom.
Or name the attribute more closely to its intent, [[replacable]] maybe.
-Dave
Specifically the meta predicates—the ones that are queried by the compiler rather than by the story. The library actually goes out of its way to avoid defining rules for most of them! Instead it does something like this:
(story title or default) (story title)
(story title or default) An Interactive Fiction
(story title) (fail)
Why do it this way? Because the compiler prints a warning if there are no rules for one of these predicates, and the library wants those warnings to show through. Most people probably want to provide an actual title instead of An Interactive Fiction, for example. So it took very little effort to extend this pattern.
It would make sense to only apply this new warning to style classes, though. The other ones are unlikely to ever be defined multiple times; right now it just applies to all of them because they run through the same “consult the first clause at compile time” code path.
Whatever you end up deciding, it seems like a chance for the dialog code editor to somehow highlight the active rule.
On further reflection, I think Adrian is right and this shouldn’t apply to the story metadata. Those predicates really are predicates; they’re normal blocks of code that can be queried like any other predicates in the program (and are, in the default banner). There’s no strong reason to make them act differently from other predicates.
The problems I was running into were with style classes specifically, which aren’t like other predicates—they’re instructions to the compiler, not part of the normal Dialog code. So I would like to include the warnings there; but how often will people be defining the small, fixed number of meta predicates in multiple places?
I’ve also made it so those style class warnings only apply when there are multiple definitions outside the library file. The part of the compiler that handles CSS knows which file is the library, conveniently. (The part that handles the other metadata doesn’t.)