Negative numbers are a Big Deal for some of the things I’m doing. (Okay, “poking at.”)
2 Likes
What features are important for those negative numbers?
can’t you just add a large number to subtract.
Could Dialog perhaps be extended with a compile switch to generate a code coverage report?
The Skein gives you the ability to quickly run the game dozens, even hundreds, of times; wouldn’t it be nice to be able to generate a report that identified which lines of Dialog code have ever executed? It would definitely help pinpoint areas where the project is not fully tested.
2 Likes
Another wishlist item: for the Skein, I run dgdebug with a fixed width of 80 and have to parse through the returned text to find the prompt. I’m sure some day there’ll be a game that breaks that code.
What would be great is if I could turn off width (no word wrapping at all) and have dgdebug send a special character, such as a null, instead of a prompt. An automation mode, basically.
1 Like
Ooh, interesting! I haven’t looked at the dgdebug code at all but that should be doable.
dialog-if is a fine name, no reason to change the executables names even.
But I’m trying to come up with a name that plays on unification (the core of Prolog), so let’s call it: Unity? Unified? Ah well, dialog-if it is!
1 Like
In practice the opposite is more likely to be true. It is managable to have two projects with the same name, but not when they are going to be installed in the same location and are providing executables with the same name.
I would really like to see negative numbers and the ability to count to higher than 16383, and handling arbitrary characters in both input and output.
2 Likes
I’d like a (quit $) builtin that lets you specify the exit status when you exit the interpreter, for use by CI/CD pipelines, build systems, and so forth.
Ideally, it would support negative numbers, even if the rest of Dialog doesn’t, because the whole point is to be able to exit with an error status, to fail your build.
1 Like
Hmm, okay! This would presumably only be for the debugger, because the Z-machine and Å-machine have no built-in way to exit with a particular status, though the Z-machine does have a “trap” opcode that could do this…you’d just need to build an interpreter that responds to traps like that.
Supporting negative numbers in just one context like this would be a big ask, because it means rewriting the lexer, but it wouldn’t be hard to e.g. specify that the number passed is treated as a signed eight-bit integer, so you can pass 255 to get -1 and so on. I don’t think anyone really uses exit statuses higher than 128, do they?
It’s not really what you’re asking but I think it would be nice to see more native Aa-machine interpreters to make Dialog more of an option for resource-constrained machines that aren’t the C64.
2 Likes
That’s something I’m fully in favor of, but it’s also well beyond my programming abilities I’m afraid.
Something I’d like to see in Dialog’s standard library is the ability to omit parts you don’t want.
You may just not need some actions (and related grammar) because they aren’t needed in your project, especially if you are trying to fit it into a constrained space (like a C64).
You may be replacing parts of the standard library from whole cloth (like the way my Threaded Conversation library replaces the built-in, simpler ask-and-tell mechanics).
I could imagine a number of ways to approach this.
New syntax could be used to mark blocks that could be conditionally excluded, and then combined with new command line options (on the compiler and debugger) to list things to exclude.
Alternately, the standard library could be split into smaller units that could be included explicitly (though I would think that combining the smaller units into a single file would also be included, as it would be used by most authors).
Honestly, this part I don’t think Dialog necessarily needs—because the intent, per the manual, is that you have a separate copy of stdlib.dg for each project, which you go in and hack at ad libitum. I don’t think I have any current or past Dialog projects that use stdlib.dg unmodified. (As opposed to Inform, where the expectation is that you have one central copy of the library which every project depends on.)
1 Like
Fair point. In fact dgt new provides a copy of the standard lib and standard debug in the created project … and the pace of changes to standard lib has, alas, seemed to dry up.
How are we doing about a name and a GitHub repo?
1 Like
Honestly, I’ve somewhat lost track of all this amidst other projects. I’ll see about getting a repo up once final exams are done!
Though one more wishlist item did come up during Familiar Problems development: the ability to make a status line with a variable number of rows. I have code to calculate how tall the automap should be, but then I had to manually define a separate style class for every possible height, and write a bunch of if-statements to choose the right one!
1 Like
Well the name depends on what we think we’re doing. We never really came to a consensus on that, so let’s just make a poll now.
We want to
- Revive Dialog (even without Linus’ explicit permission)
- Fork Dialog (permission not needed)
0
voters
Seems like a pretty big lead for forking Dialog. So for the name, these were suggested before:
- Dialogos
- Pro Dialog
- Dialog-IF (maybe just as the name of the Github Repo, rather than the project itself?)
I quite like Dialogos, but any other suggestions?
2 Likes
Another poll? I like Dialogos. I don’t like Pro Dialog – make’s it sound like payware.
I’m also fine with leaving the name alone and just changing the name of the GitHub repo; I don’t think that the two executable, dgdebug and dialogc will cause conflicts.
1 Like