what matters in having or not terminator bytes is not C or Inform, but the underlying Z-machine target; when you have 128 or 256 Kbytes with 64Kword addressing, and hundreds of text arrays, the memory space gained in NOT having a terminator character in a text array became evident.
Best regards from Italy,
dott. Piergiorgio.
There’s no reason why you couldn’t write code based on null terminated string arrays in Inform 6, but it wouldn’t really provide any advantages either.
But you then have to sacrifice one bit per word to indicate where the end of the string is (marking the final word).
Whether or not this is more efficient than a terminator character, I imagine, depends on how long your average string is—if the average number of words per string is greater than the number of bits per character, the terminator would be more efficient.
I think it’s a bit late to relitigate Z-machine text compression.
Otisdog,
This seems to be great explanation if a person wanted write the compiler or interpreter. For using Inform (6 or 7), a set of rules is better. I don’t mean I6 or I7 “rules” but tutorials on common idioms. The examples are great in the I7 documentation, but it is too much like figuring out how to take the square root of a number with many examples. The algorithm is needed, and examples have limited use. For example, given 25 => 5 and 16 => 4, can one really figure out the square root of 47?
So… there’s some positive feedback on the need and scope but mixed reviews on the proposed style.
Would anyone be interested in “subscribing” (via PM) to a thread with posted drafts of various sections? The Q&A would help to refine the approach and potentially be useful to participants even if the project never makes it to completion.
This sort of thing could possibly be organized with Git.
I should be encouraging you to use IFWiki, but BookStack looks good: https://www.bookstackapp.com/
I agree.
A GitHub repo in markdown would be easy to submit pull requests and edits. And an easy way for @otistdog dog to merge what’s appropriate and reject what’s not.
Plus it’s possible to read the rendered Markdown directly from GitHub (for those of us who want to browse the current pages).
I would caution against using markdown for such a document. It really isn’t designed to produce a book. LaTeX would be much better.
Okay, so I’m confused.
You say “it is not designed to produce a book.” (“It” I assume is markdown.)
Are you saying markdown can’t render down and produce a physical book with text and simple codeblocks?
I mean, if one needs LaTeX specifically, you can always use kramdown or pandoc to convert markdown to LaTeX.
Is what everybody is looking for a physical book? Like a big chunk of old-school paper?
The advantage to markdown is that (a) it’s easy to write, (b) can render to HTML for easy portability to the web, and (c) can be displayed as a work-in-progress in GitHub with fully rendered pages.
Plus, it – markdown, again – makes it easy for folks to submit a PR and contribute to the WIP.
I’m assuming contributions – PRs – pull requests – would be welcome. It could be a pretty active project – at least for a while.
But I could be wrong here – especially if this isn’t a project where user contributions/edits/fixes are encouraged.
Confused.
What am I missing?
For starters: page layout, macros, indexes, bibliographies, cross-references, and footnotes. While Markdowm can render some of that stuff, it can’t automatically keep it consistent and up to date. Pandoc can do more, but is iffy. I’ve been bitten several times by Pandoc stuff that goes out of date leaving documents in unrenderable limbo.
Agree to disagree.
No need for LaTeX, IMHO – way, way overkill. All that stuff – cross-refs, footnotes – can easily be done by markdown.
Plus, as I say, folks can contribute directly to the markdown source if it’s on GitHub/GitLab – which (I’m assuming) is the point.
LaTeX may be a typesetting or layout target – and I agree with that – it’s certainly not community friendly when one is soliciting edits/updates/additions from collaborators.
IMHO – LaTeX is a print target – but doesn’t invite a community process.
Markdown (OTOH) lowers the barrier for community collaboration – but doesn’t need to be a target. It’s simply an easy way to collaborate. The final target – print, web, whatever – can be generated from the final markdown source (if necessary).
As I say – agree to disagree.
All is good! I appreciate the back and forth. I look forward to DM5 in whatever format!
well, there’s plenty of open typesetting formats since the days of Unix v1 roff(1) whose actually composed the earlier printed Unix manuals.
I actually own a (well thumbed and with many bookmarks) physical copy of DM4 alongside the .pdf edition on this machine, and in I6 coding I use both without issues (I don’t hide that my ideal paper “dm4r” is one with punyinform manual as appendix)
Now that the copyright holder IS actually available on this forum, let’s start simple: he can do the Right Thing and release DM4 as GFDL or whatever free documentation license he likes, then do a “DM4r” embodying the errata from Zarf et. al (and, why not ? also the Punyinform manual as appendix…)
anyway, from DM4’s colophon, p.561 of the .pdf edition:
Type was set using CMacTEX3.6, Tom Kiffe’s port of Knuth’s
program (1983), employing macros adapted from those used to typeset The
TEXbook (though sadly not the \plugh macro in that work’s Appendix D).
Final PDF was distilled using dvipdfm by Mark A. Wicks. Indices and
bibliography were prepared automatically by scripts written in MacPerl 5,
Matthias Neeracher’s port of Larry Wall’s formatting language.
whose gives an clear explanation about the actual DM4 typesetting…
so the path I suggest is:
bothering (US sense) Lord Inform until he graciously release DM4 in a public documentation licence (UK sense, because, well, Graham Nelson IS British)
edit the DM4’s latex source with Zarf et al.'s erratum & addenda, up to date to the current standard library. (optionally, with punyinform and/or some major contrib extension in appendices)
release the DM4r.
from the XP, oops, I mean, the experience gained, start to actually design, then write the DM5.
whose seems to me a sound and prudent development path.
Best regards from Italy,
dott. Piergiorgio.
Here’s a book being written on GitHub. You could maybe get some inspiration from it (process and result rather than content!)
No thanks. Write a new book.
(To be clear, I’m not the copyright holder. I’m saying no thanks to including my errata in a modified edition of Graham’s book. Write your own book.)
zarf, I thinked that was clear that point 2 and the subsequent ones depends on success of point 1…
Best regards from Italy,
dott. Piergiorgio.