I’ve created a new organization on GitHub called Dialog-IF. The address is https://github.com/Dialog-IF. As a starting point I pulled all the versions of Dialog and Å-machine from the homepage of @lft and commited them from earliest to the last (without the prebuilt directory), one commit per release. This makes it possible to see changes between releases and correlate them with the release notes.
See this as an example only. The organizations name can be changed when the community settles on a name and I’m happy to share/transfer ownership of it to anyone interested…
(It would be nice if @lft issued a blessing or a cease and desist notice. Have anyone contacted him? I could mail him in swedish, but unfortunately isn’t Sweden small enough so that everyone knows everyone else.)
Thank you for setting this up! Importing the history is already very helpful for archaeology…
I went and filed issues for a couple of bugs. I may follow up later with some of the feature ideas that folks around here have mentioned. @heasm66, if you want to add me as a collaborator I’m happy to do some tagging and other repo gardening if / when I have the time…
I haven’t reached out to @lft, but I think sending an email is a fine idea. (Let me know if you’d rather do this; if not I can probably take this also.)
I really like the original name. The latest upstream release is four years old.
Unless Linus objects I don’t see the need for a name change. A new name might be called for if there were any drastic language changes done.
I prefer that Henrik gives his opinion on the fork’s name, but I’m all for dialogic, because dia- 's meaning is:
before vowels, di-, word-forming element meaning “through, in different directions, between,” also often merely intensive, “thoroughly, entirely,” from Greek dia “through; throughout,” probably cognate with bi- and related to duo “two” (from PIE root *dwo- “two”) with a base sense of “twice.”
so, contains the very philosophy and scope of a fork, plus probably means also “twice”, which is another objective, a fork leading to an improved dialog, that is, dialog 2.0.
It’s close to the original but still distinct, and even a bit more “pun like” in that evokes both conversation and logic.
Ultimately, I would be happy to move the Homebrew formulae and libraries and tools I’ve been working on into the new organization, whatever its name ends up being.
If a renamed system catches on, it’s likely to be grouped with Dialog in any “platform” fields in comps/listings, at least for a while. So how do you feel about seeing “Dialog/Dialogic” versus other pairs?
This is where I think “Dialog/Trialog” is particularly pleasing.
Oh, before I forget, here’s a wish-list item that should be relatively easy. Support display:none as a style on the Z-machine interpreter (by turning off output stream 1). This lets you output text to the transcript without it appearing on the screen.
Infocom did this (starting with Trinity) when something important was shown in the status line, so that you could find it in the transcript later. It would be especially useful in the Scott Adams translator, where the room description isn’t included in the transcript by default.
As a bonus, you can also use this to discard all output without it appearing anywhere, by putting your display:none box in a status area instead of the main text!
I’ve added that and a few more issues on the repo. I’ll try and sync things over from time to time, but I encourage everyone to write up ideas there directly too if they’d like!
(Also, I just sent Linus an email that covers some recent Dialog history / this thread / the naming question. Will report back if anything interesting comes of it!)
If I want to start working on these issues, should I ask to be added as a contributor (username is dstelzer) and split off some git branches, or should I make a fork and then do pull requests from there?
I’ve invited you as contributer. I also made a branch, dialog-0m03_0_46---Last-official-release, to have a pin on the last release from @lft.
I think it’s currently ok to split of branches and work on the issues from there. No need for forks yet. If the pool of contributers becomes big, we may need to rethink this and have a smaller group that accepts pull requests from outside forks.
Now that we are starting to do changes to the code, I kinda like the idea to leave original documentation intact and collect the changes in an addendum - like the one for Inform6.