As per the title, if the stdlib is included before the source file of the game in the dgdebug command call, there will be odd effects. Every location will be known as “location”, and have no description, for example.
This is unexpected, and led to me being confused, and doubting my own program (especially as I am new to Dialog); ordinarily, I would expect the order of files included to have no effect, or for the program to warn me if I pass a list of files that is not sensible. Perhaps the stdlib could be included by default, and a specific flag (say, --stdlib) used if the author wants to include a different stdlib?
Thank you for this valuable feedback!
The order of the files is significant, because the order of rule definitions is significant. And early rules can override later rules, so the story (with specific rules) needs to come before the library (with generic rules).
Extensions such as
stddebug.dg should normally go between the story and the library, because they override/modify library functionality, and the story can override/modify them in turn.
Here are three reasons for requiring the library filename on the commandline:
There is no need to keep a
stdlib.dg in a default, system-wide location. That way lies all kinds of versioning trouble.
The operation of the compiler should be transparent and understandable. (The exception is the optimizer, which is allowed to do magic as long as the functional result is the same.) It is important that the story author understands—at some point—that the order of rule definitions is significant, that the rules of one file are encountered before the rules of another, and that the library is just an ordinary source code file.
If we automate the common case, we only postpone the trouble (and corresponding insight) until the author tries to use their first extension.
That being said, I realize that the current system can be confusing. Others have reported being confused by what happens when you forget to include the library on the commandline at all.
A possible solution could be to include a special marker rule in the library, that tells the compiler that “this file is supposed to be last”. That way, the compiler can detect if the library appears in an unexpected position, or not at all, and print a warning about it. I think warnings, when they are relevant and instructive, are better than magic.
Another endorsement for some sort of “please automate this or at least keep us from tripping over our own feet.” Every single time I return to Dialog after not looking at it for a while, I lose a bunch of time trying to figure out where I’ve gone wrong and it’s “ohhhh yeah I have to manually include the lib and remember which order it goes in.”
(and yes a constructive scolding or “WARNING: Did you really mean to compile in this order?” or whatever at the command line would be better than just letting us dig our own graves and I understand why that is superior to magic fixes.)
Like you I prefer this solution to magic. My concern is that an author might not realize this rule can be removed from the standard library or inserted into another file, undermining efforts to convey that the library is coded in regular Dialog.
I was one search person. If I had not been helped by the amazing people on this forum, I would have benefited most from a reference that listed Dialog errors and their common causes.
I put together dgt to help with this, as well as testing, and packaging. https://github.com/hlship/dialog-tool
I would love to use such a tool, but unfortunately, it being restricted to OS X is troublesome. Consider trying to make it cross-platform? I’m pretty sure some of us here would be interested in using it, and it would be a great help for the community.
Joker is cross-platform; the tool could be made cross-platform as well with some windows and/or linux specific updates to library and executable locations. Alas, I have 0 time to work on that between working on TC and Sand-Dancer, and some work in Elixir, and a game I’m writing in Godot … and, oh yes, day job, home life, etc.
A compiler warning has been added to version 0k/04. Any source code file that defines a rule for
(library version) is considered to be a library. The warning is printed if no library appears on the commandline, or if it appears in any other place than last.
Isn’t the library placement in the command line clearly indicated in the included manual?
Yes it is. Sometimes people forget, or misunderstand. Of course, it’s not feasible to put in warnings to cover every conceivable mistake, but there were two compelling reasons to do it this time:
Several people made the exact same mistake independently.
When they did, the result was a program that behaved in a baffling way, and it took them a long time to figure out what was wrong.
This warning points directly at the root cause of the error, and may eliminate hours of frustration.