This includes some notices to those who wish for a greater challenge.
In the 1998/schweikh3 the man page (and its copy to demonstrate the
entry) have been updated slightly but only in comment (move 'or' from
the command suggested to render it in text to its own line before the
next command also in comment).
The bugs file was updated for an entry or two.
In the line in README.md and index.html files that said:
### NOTICE to those who wish for a greater challenge
I added a ':' at the end of the line.
There were some entries that had a link fix in the index.html file but I
only looked up through 1995/leo as those still have to have a 'look and
feel' check and it would just slow things down.
We add the following level-3 header to help people identify text
they may wish to skip if they wish for a greater challenge:
```
```
After that notice we add:
```
**If you want a greater challenge, don't read any further**:
just try to understand the program via the source.
If you get stuck, come back and read below for additional hints and information.
```
And sometimes follow with:
```
```
Or sometimes follow with:
```
```
Where the alt code impacts a "greater challenge", we add instead:
```
**If you want a greater challenge, don't read any further**:
just try to understand the program without looking at the Alternate code.
If you get stuck, come back and look at the Alternate code.
```
And where a given command impacts a "greater challenge", we add instead:
```
**If you want a greater challenge, don't read any further**:
just try to understand the program without running the command below.
If you get stuck, come back and run the following command:
```
Perform `make www` to perform the above and test under macOS.
In most cases the word was changed to 'obfuscation' as it was about
obfuscation, not deobfuscation. In some cases like 1995/leo since the
file was (in 1995/leo) about a secret switch it was changed to
'secret.md' (and 'secret.html') but there were others like that as well.
One entry had the words 'spoiling the size rule' but this had been
changed to 'deobfuscating the size rule' which was obviously wrong.
In the latter YYYY/README.md files the judges had written after some
entries (brief summaries) '...
...We'll stop spouting spoilers now. Have fun exploring all the
entries!
but that was changed to:
...We'll stop spouting deobfuscation information now. Have fun
exploring all the entries!
which wasn't really about deobfuscation but just a brief summary of what
the entries did.
And in the most problematic case (at least for me :-), 2018/ferguson) I
had put a joke in:
... but it's the only Easter egg I won't spoil
but it was changed to 'won't deobfuscate' which not only is not what it
is but it spoilt the joke.
In some cases the word was changed back to 'SPOILER' (or similar) but in
most cases not. I believe it should be better now. There are some
caveats, however, as below.
Although make find_missing_links is okay I do not remember if this will
catch links that refer to '%%REPO_URL%%' or other pandoc tokens. This
means I might have to go back to some earlier years to verify links are
okay. That should not take that much time I hope.
It might also be that some wording can still be improved some but it is
hoped this will be discovered when checking links and looking over the
manifest (which obviously changed).
Given how problematic leading tabs in markdown files can be,
we have expanded all leading tabs in markdown files by:
```sh
find * -type f -name '*.md' -print |
while read -r file; do
rm -f "$file.tmp" ;
expand < "$file" > "$file.tmp" ;
mv -f -v "$file.tmp" "$file" ;
done
```
Given the previous changes to `bin/pandoc-wrapper.sh` and other recent
commits and recent pull requests, the were were **NO** changes to
any HTML files. This is a **good thing** as the expression goes.
No there are no leading tabs in any markdown files.
A check to catch any re-introduction of leading tabs
into any markdown file is on the way.
BTW: We do not have anything against leading tabs in files,
even though we have had to deal with their impact on forming
HTML from markdown files (as well as the calc source code).
It is just that this is one of those cases where tabs conflict
(sometimes caused by people wanting to change the classic
8-space tab model) with a desired outcome.
Perform `make www` to perform the above and test under macOS.
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.
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.
The author stated that the program assumes EOF is -1 but for systems
that do not have this it will fail. This is indeed a valid concern as
the standard mandates that it's a value < 0 but it doesn't require it to
be -1.
The author also stated that the program could fail if 1 is not a return
value that indicates error so this was changed to EXIT_FAILURE as the
suggested was made. It is possible of course that I missed a place where
this should have been updated but I don't believe so. I am unaware of
any system where this would be a problem and I don't know why it matters
anyway but I made the change as the author stated it could be a problem
with portability.
The README.md file has been formatted and typo checked.
Added try.sh script.
This should complete this entry's review.
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.
As in:
sgit -e 's/# To run/# To use/g' '*README.md'
This makes consistent the message for how to use the program. 'How to
use' was chosen because one can run a program just by doing './foo' but
that doesn't imply that's how to use it but the purpose of the section
is how to use it.
The use of the markdown trailing whitespace to indicate
line break should NOT be done when the following line is empty.
This removes such improper use of whitespace in README.md files.
Or else add an ostomy :-).
Some README.md files have severe ulcerative colitis and will need a
colectomies but others are missing colons. These will be discovered and
fixed in time. In the meantime I've restored some functionality for
these poor README.md files by giving them an ostomy.
There were many many README.md files with the wrong heading level for
different sections. These have been changed.
To help go through the changes it should be noted I used sgit and also
here is what is changed:
The 'Try', 'To build' and 'To run' lines have two '#'s. Some had one and
others had three.
An exception is that in 1984/anonymous/README.md for the alternative
code that had three '#'s. This is not consistent yet and it might be
that only two are desired. But for now that one at least has three.
There is one exception:
$ find . -name '*.hint' -execdir git mv '{}' README.md \;
git statufatal: destination exists, source=1992/albert/albert.hint, destination=1992/albert/README.md
Looking at the two files they differ quite a bit so I've not changed it.
I'll bring this up on GitHub.
Cody Boone Ferguson