While not strictly necessary, replacing the two ASCII tab characters
in the markdown copyright comment makes it easier to detect problematic
TAB indentation within markdown files.
After this commit, only 90 markdown files have leading ASCII TAB
characters. And again, while not strictly necessary, we can consider
running expand on those 90 markdown files to see what effect that
might have on the HTML files they produce.
Replace leading ASCII TAB characters with multiples of 8 ASCII SPACE
characters (the default action of the `expand(1)` tool) might have
an negative effect on some HTML formatting where **hack-a-round**
formatting was attempted to fix broken indentation caused by
problematic ASCII TAB characters.
Think of this as a baseline for evaluating leading
TAB characters within markdown files.
TODO: Consider either using `expand(1)` to replace leading ASCII
TAB characters with multiples of 8 ASCII SPACE characters AND/OR
modifying the appropriate `bin` tool to convert leading ASCII TAB
characters into multiples of 8 ASCII SPACE characters.
This was done by:
sgit -e 's/alt code/alternate code/g' . ; git co tmp/OLD_manifest
as well as updating the tmp/manifest.numbers spreadsheet and exporting
to the CSV file (though that would not strictly be necessary).
The way this works means that the update manifest script does not need
to be run as it sgit(1) touched the .entry.json files (any that needed
to be updated) and so would any index.html files. An example for both
.entry.json and index.html files being modified due to manifest is
2012/kang.
Numerous Makefiles were updated, any try scripts that had 'alt code'
instead of 'alternate code' and README.md/index.html files (unrelated to
the manifest as 'alt code' was used in other places too) and obviously
the manifest.numbers spreadsheet.
However to be safe I will do a run of the manifest script in a bit even
though it should not be necessary. If no commits are made it means all
is good and if any commits are made for the manifest it means that I
did not think of something (or else I made another change after this).
Changed in 1984/anonymous 'source code tattoo image' to 'source code and
tattoo image'.
Changed in 1984/mullender 'header file for gentab.c for compatibility
with 1984 systems' to 'gentab.c header file for compatibility with
systems in 1984'. The rationale here is that it's not 1984 systems but
systems in 1984. I would have kept the ordering of the wording the same
but that was more than 59 characters. The way it is worded now is not
necessarily better (other than not being literally incorrect - that is
if it's interpreted literally it is incorrect) but it's also not worse.
Minor format fix in 1985/shapiro/README.md.
Rebuilt index.html and .entry.json files.
We added a space between the markdown triple code mark
and language that was enclosed in HTML comments.
So a line of the form:
````
```<!---c--->
````
became:
````
``` <!---c--->
````
This was done to **help** some code see that the HTML comment
string was not a markdown code specifier. Not all code
understands this after this changed. For example, `pandoc(1)`
still forms HTML classes of the form "<!---c-->"
when it encounters the above mentioned change.
We also fixed a problem with `2019/dogon/README.md` regarding
a markdown code block.
We also fixed a problem with `2020/yang/README.md` regarding
a markdown code block.
When language is specified in a markdown code block such as:
````
```c
printf("Hello, world!\n");
```
````
is used, the resulting HTML as produced by `pandoc(1)` combined
with our revised `ioccc.css` is not intent the code block well.
A temporary "_hack-a-round_" is to turn the "markdown code language
specifier" into an HTML comment. For example:
````
```<!---c-->
printf("Hello, world!\n");
```
````
This commits turns off existing markdown code language specifiers
for now, while preserving our ability to restore them in the future
when a better "_hack-a-round_" to the "markdown code language
specifier" problem is found.
The HTML impact if this "_hack-a-round_" is to produce HTML that
looks like this:
```
<pre class="<!---c-->"><code> .. </code></pre>
```
We might be able to create a complex set of classes for each markdown
code language (there won't be very many) in `ioccc.css`, or we might
find a more general CSS (or maybe `pandoc(1)`?) solution.
For now, this hack-a-round will have to do.
All code blocks in markdown have been intended by at least 4 spaces.
We add `--tab-stop=8` to all `pandoc(1)` executions in order to set
a better tab stop indentation, especially for tab intended code blocks.
Changed `bin/pandoc-wrapper.sh` VERSION from "1.5.3 2024-03-26"
to "1.6 2024-03-31".
Fixed `1991/brnstnd/sorta.README.md` so that the sorta code
is code blocks.
Removed unneeded paragraph group in copyright in `inc/footer.default.html`.
Fixed excess whitespace after list Author on entry `index.html` page.
Changed `bin/output-index-author.sh` VERSION from "1.5.2 2024-03-26"
to "1.6 2024-03-31".
Performed `make www` to perform the above and test under macOS.
TODO: Fix the problem of the initial line of code being extra intended.
TODO: Fix excess whitespace around code that is inline.
The inc/footer.default.html now has a common Copyright and CC BY-SA
4.0 License section for all generated HTML files.
All markdown files have a similar Copyright and CC
at the bottom in the form of an HTML comment.
The script had "s surrounding the git ls-files command which turned it
to a single file which of course is wrong.
Ran script again fixing many README.md files that had incorrect number
of blank lines for critical headers.
This will have to be done a final but a good number of files have been
corrected.
This alt code allows one to resize the maze. Obviously if one uses -D
with a value that's not a number it will fail to compile. If it's <= 0
|| >= 5000 it will set to the default of 39.
The try.alt.sh script plays with this, first selecting a random number
(in range $RANDOM % 38) to compile with and then run. After that it runs
in an infinite loop, exiting only if input includes non-digit
characters. A value >= 5000 sets it to the default of 39 (in the code).
As requested on GitHub: a tool that will be written, readme2index, will,
as explained:
'... will take the converted HTML from the README.md markdown and
inject it into an HTML template. Things such title, award one and
author information will be injected into the HTML page ahead of the
HTML that was converted from the README.md markdown. Without going
into details of HOW at this time, the result will be a coherent HTML
index.html page with the winner title / award, winning author
information, and important file links come from other sources and
NOT from the README.md file.
The text from the 1st award line, thru the authorship information,
and up to but not including the "## To build:" line in the README.md
file will just get in the way. Moreover authors might be tempted to
try and maintain that top of README.md text instead of working with
the author/_author_handle_.json and winner .winner.json files.
This was done with my[0] sgit(1) (https://github.com/xexyl/sgit) tool like:
sgit -o -n -e '/^## To build:/,$p' '[12][0-9][0-9][0-9]/*/README.md'
[0] Is that shameless self-promotion? I don't know but I don't care: it
is generally a very useful tool and has been used in other repos too.
Besides, I've done it many times before and it's a great example that I
will be adding to the README.md file of the tool, one I hadn't thought
of doing.
The years 1984, 1985 and 1986 have had all winning entry README.md files
updated. This includes formatting, adding author's comments (which in
these years means nothing but still have the section there to indicate
that there were no comments) and possibly other things.
I have updated some - not all - of the 1987 winning entry README.md
files. I have to do other things now but I want these committed. I will
work on the other README.md files another time.
Updated the README.md files.
Renamed shapiro/shapiro.orig.c -> shapiro/shapiro.alt.c. This is one of
the exceptions where we have the alt version as this alt version is not
actually in the archive tarball (there are other exceptions for various
reasons).
Unfortunately some entries will either not compile under macOS or not
run correctly. We used a patch from Yusuke Endoh for
1985/applin/applin.c. Thank you Yusuke! This is actually the entry that
does not work right under macOS but it does under linux.
Update main README.md with links.
Update a number of other README.md files with typos and other fixes and
improvements (including fixing invocations and adding a 'Try:' section
to match later year README files).
Update various Makefiles to add notes and to make some entries compile
(in some cases, those that require -traditional-cpp, they will not
compile under clang and we note this).
Update archive/archive-1985.tar.bz2. Why? Because the purpose of the
archive/ files are for the original files and some of the files in there
were not original. See the files 1985/lycklama/lycklama.orig.c and
1985/shapiro/shapiro.orig.c which in the tarball do not have the .orig
added to the name.
Landon Curt Noll