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 README.md file has been format/typo checked.
The alt code default usleep(3) value has been increased from 65000 to
75000.
This should complete 2006/sloane.
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.
In the case where we recommend trying the alternate code first, the
lower section is 'Original code' but this was at heading level 3 when
discussion suggests 2 so this was done as well:
sgit -e 's/^### \(Original code\)/## \1/g' '*README.md'
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.
Unfortunately later versions of clang have an additional defect where
not only are the args of main() required to be specific types but there
can only be 0, 2 or 3 args. This program did not use the second arg so I
removed it originally but this will obviously not work for all systems
so I have brought the second arg back.
The unfortunate problem here is that the author used the letter Z for
the second arg and that's exactly what I have been using for the macro
for usleep() in alt code (Z for sleep of course). So here in order to
make it so that the entry looks as close to the original as possible I
have kept it as Z (changing the type to 'char **') and instead renamed
the Z macro to just S. S was selected as it can also stand for sleep but
also it's kind of (not quite but kind of) a backwards Z. Whether the
other entries should also be changed to be '-DS=...' is something to
consider for consistency but that can be decided another time. It
probably doesn't matter except that it does bother me as I don't like
inconsistent consistencies any more than I like consistent
inconsistencies or inconsistent consistencies.
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.
Instead of having the 'Alternate code' section be the original, rename
it to 'Original code'.
Changed note about alternate code at top to refer to original code.
As the original entry is too fast for modern systems I have (after
discussion with Landon) made the build and try sections refer to
'sloane.alt' instead of the original entry. The 'alternate section' now
refers to 'sloane' instead. This is a rare case where the reversal of
alt (in this case provided by me) and the original is valuable.
There are other entries where I will end up doing this as well for the
same reason of the entry going too fast in modern systems and these will
be updated in time, now that a method to do it has been established.
The fix thank you's have been moved from `README.md` to
`thanks-for-fixes.md`.
**WARNING**: Some mistakes may have been made in doing this.
We presume later changes by others will correct any issues.
The `CONTRIBUTING.md` was renamed `how-to-enter.md`.
A 3rd line of links was added to top level html such as
`contact.html`, `index.html`, `judges.html`, `winners.html`,
and `years.html`.
Improved blank line use in a number (but not all) `README.md` files.
Alt code uses usleep() with the macro Z (default 65000 but one can
override it - I explain in the README.md how to do this) to let one see
in modern systems what is going on. This also allows for those (like
myself) who don't like to see text (or other things) zooming by very
rapidly. The former is more important for most people I'd think. It
didn't even occur to me what was going on until I slowed it down and the
award title didn't mean anything to me until after it either though I
read about this entry a long time ago. But still the latter part is
useful as well.
Format fix README.md.
Fix compilation in some systems: compilation issue is that some
systems (looking at fedora and CentOS linux and probably others) don't
link in lm by default.
The other issue is what the author stated - that not using certain
includes might cause problems. To not ruin the format of the code I
added -include ... to the Makefile.
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.
The problem was that the second arg was not of type char ** but an
implicit int and broken record though I am clang forces the types to be
correct without any option to disable this.
As it happens though the second arg is not even used so I removed it as
clang does allow this for some reason. This helps with keeping the
original format as close as possible. This triggers a different warning
but that's okay.
I also added a warning to the README.md about how it is a lot of change
in text very quickly as this could cause some problems for some people.