We move `tmp/format-headers.sh` into `bin/format-headers.sh`.
We also add a few missing empty lines to `README.md`.
We add `bin/format-headers.sh` to the `bin/README.md`.
We run `bin/format-headers.sh` to perform the above.
Performed `make www` to accomplish the above and to test under macOS.
Instead of code blocks the bug / (mis)features statuses are quoted
rather than in a code block. In the case that there is more than one a
line break was added at the end of all but the last one.
A bug status was renamed to be slightly more correct (maybe more than
one was renamed for the same purpose but at least one was).
The bug statuses in the quotes are now bold to let them stand out
better.
We quasi-canonicalized markdown links to FAQ entries.
**IMPORTANT NOTE**: This is a useful step in completing issue #2417. This commit is consistent with the top level TODO comment requirements. Nevertheless, this changes made by this commit needs to be examined and in some cases improved.
A link to an FAQ entry is of the form:
```
FAQ on "[the link text](....faq.html#string)"
FAQ on "[the link text](....faq.html#string)"
```
The "FAQ" is at the start of the line, or in rare cases is preceded only by whitespace.
The reference to the FAQ starts outside of the markdown link with the string **FAQ ON "**.
After the markdown link is a **"** followed by either the end of line or a single punctuation character such as a period or comma.
We reduced the size of "the link text" that refer to an FAQ to at most 3 words. In some cases the sentence and/or text surrounding the markdown link to a FAQ may need to be further adjusted to better accommodate this new style.
**IMPORTANT NOTE**: References to a FAQ entry are on a separate line.
p.s. When linking to the `faq.html` file itself, we use markdown of the form "`the [IOCCC FAQ](..../faq.html)`" and place the word "the" outside of the "IOCCC FAQ" link text.
Given the above system (and because references to an FAQ entry is on a separate line), the following command shows links to FAQ entries, sorted by FAQ entry "link #name" so that one may evaluate the way a given FAQ entry is referenced:
```sh
find * -name '*.md' -print0 | xargs0 grep -E '^[[:space:]]*FAQ on "' | sed -e 's/^\([^:]*\):\( *FAQ on "[^#]*\)#\([^)]*\)\()".*\)$/#\3\t\1\t\2#\3\4/' | sort
```
The above command shows the value of consistency when it comes to FAQ references.
**NOTE**: There are a few differences on how a given FAQ is references. That is probably OK as there is NOT an "total mandate" that all references to a given FAQ must have the same "link text" for example. On the other hand if references to a given FAQ can be identical, that might be helpful. We are certain that in some contexts the "link text" might need to change.
Should we decide to change the way FAQ are referenced, we will be able to modify identify and modify them with greater ease.'
Examine the changes made by this commit and adjust and/or improve as needed.
Performed `make www` to accomplish the above and to test under macOS.
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.
That is to say in the bugs file it will look something like:
STATUS: INABIAF - please DO NOT fix
but as a html file it is already bold as a heading. This means there is
no need in the index.html file to have the explicit **DO NOT** as it's
in a code block and it is not consistent in what is in bugs.html. For
instance 1984/mullender had:
STATUS: INABIAF - please **DO NOT** fix
but this meant the index.html file had the '**'s surrounding the DO NOT
which is not consistent with bugs.html.
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.
Once upon a time after adding the entry to the bugs file it was changed
so that it should be a bug to be fixed and when verifying things since
it was very quick to fix I added it. It now has been restored to the
original.
The bugs file was updated and the thanks file was updated accordingly
along with the index.html and README.md 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.
Entry source is now prog.c for IOCCC years 2014 thru 2020,
or is now dirname.c IOCCC years 1984 thru 2013.
To achieve this state, we renamed the following:
renamed: 2004/hibachi/src/hibachi.c -> 2004/hibachi/hibachi.c
renamed: 2012/omoikane/nyaruko.alt.c -> 2012/omoikane/omoikane.alt.c
renamed: 2012/omoikane/nyaruko.alt2.c -> 2012/omoikane/omoikane.alt2.c
renamed: 2012/omoikane/nyaruko.c -> 2012/omoikane/omoikane.c
renamed: 2012/omoikane/nyaruko.orig.c -> 2012/omoikane/omoikane.orig.c
Modified `bin/subst.entry-index.sh` to add to entry `index.html` file,
links to the `Makefile` and the _C code_ to the top navigation bar.
Changed `bin/subst.entry-index.sh` VERSION from "1.2.2 2024-02-25"
to "1.3 2024-03-02".
Moved printing the Inventory link in the top navigation bar
from `bin/subst.entry-navbar.awk` to `bin/subst.entry-index.sh`.
Changed `bin/subst.entry-navbar.awk` VERSION from "1.0.1 2024-02-23"
to "1.1 2024-03-02".
Moved printing the Inventory link in the top navigation bar
from `bin/subst.year-navbar.awk` to `bin/subst.year-index.sh`.
Changed `bin/subst.year-index.sh` VERSION from "1.0 2024-02-11"
to "1.1 2024-03-02".
Changed `bin/subst.year-navbar.awk` VERSION from "1.0 2024-02-11"
to "1.1 2024-03-02".
Added location names (both default and common) to `author.html`.
Changed `tmp/gen_author_json.sh` VERSION from "1.0 2023-06-06"
to "1.1 2024-03-04".
Added location names (both default and common) to `author.html`.
Changed `bin/gen-authors.sh` VERSION from "1.2 2024-03-09"
to "1.3 2024-03-04".
The manifest and the resulting `.entry.json` files have been changed
for `2004/hibachi` and `2012/omoikane`.
The Makefiles for `2004/hibachi` and `2012/omoikane` copy the
source file into the "previously used location". The `make clobber`
rule removes the copied source. The `.gitignore` files have been
updated accordingly.
Improved how the concept of IOCCC terms _entry_, _author_ and _submission_ are
used in markdown files.
Links to markdown files (files ending in .md) within the repo were
changed to link to HTML files (files ending in .html). Special cases
where `README.md` became `index.html` were modified accordingly.
Fixed URL for `bugs.html` in Makefile comments.
Fixed name of `bin/sgi.sh` referenced in comments in `.gitignore` files.
Links to locations within the repo are now relative. For example a
link to `/contact.html` may become `../contact.html' or '../../contact.html`
depending on the directory level of the markdown file.
Nearly all links with absolute URLs under _https://www.ioccc.org_
or `https://ioccc-src.github.io/temp-test-ioccc_ have been changed to
relative paths within the repo. Some exceptions to this (such as
referring to a GitHub repo) were preserved.
Fixed a number of inside `faq.md` and `bugs.md`.
Added HTML name tags (in the form of an _entry_id_) for each entry
referenced in `bugs.md`. Fixed links from outside of `bugs.html`
into `bugs.html` accordingly.
Where FAQ entries are referenced, a named tag is used so that if a
FAQ is ever renumbered, links outside of `faq.html` will still work.
Changed the _inventory_order_ of a compressed tarball from _300_
to _100000_. While this may have been done for the manifest,
this changed had not yet been propagated into the `.entry.json` files.
Links to web sites that were in the for <URL> are now [URL](URL).
Performed `name www` to process all of the above.
Improved format of `authors.html`. Full names are now bold.
Location codes are now links back into `location.html` and
location names (both default and common) are now italics.
Added _author_handle_ each author.
Changed `bin/gen-authors.sh` VERSION from "1.1 2024-02-25"
to "1.2 2024-03-09".
Improved format of `location.html` as location codes are now bold,
author counts in a given location are now bold, and location names
(both default and common) are now italics.
Changed `bin/gen-location.sh` VERSION from "1.0.1 2024-02-23"
to "1.1 2024-03-04".
Added italic location name after location code in entry
`index.html` files.
Changed `bin/output-index-author.sh` VERSION from "1.4.1 2024-02-23"
to "1.5 2024-03-04".
Added _Location of authors_ to the sidebar as a link to `location.html`.
TODO: While nearly all of the above mentioned changes are likely correct,
they likely introduced a few errors that need correcting.
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.
There was some inconsistency as far as whether or not the problem was a
bug or feature, where not enough args would result in a crash. At one
point it seems it was changed to a bug, not a feature, and it is then
that I must have fixed it. However the bugs.md file incorrectly labelled
another entry as ollinger and the README.md for ollinger referred to
something that did not exist or rather it existed but it was for another
entry.
A minor fix in bugs.md has been done as well: change the status name of
using fgets() to not refer to getline(3); rather the description does
that. This is because no other place has that function in the status
line. Doing this is how I found the problem this commit fixes as another
entry should have that status.
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.
Fixed cases where there was a bad trailing backslash.
Improved a few cases where a code block was needed
to highlight some text.
Changed a few cases where a code block needed to
declared as, say, a sh code block.
Fixed a few cases where the winner information was not properly formatted.
Plus a few nits and clarifying text was added.
We introduce a bit of fun, while specifying that something
is "supposed to happen".
NOTE: There is no need to change the INABIAF STATUS. The use
there is perfectly fine.
The entries referenced in `bugs.md` now have, below the
"To build:" section, a "Bugs and (Mis)features section text"
that matches the `bugs.md` status.
Several entries had their "STATUS" changed from:
"STATUS: INABIAF - please **DO NOT** fix" to:
"STATUS: known bug - please help us fix":
This was done because, while some of the bugs were minor,
inviting someone to try and fix the issue does nil harm.
In a few cases a more difficult bug was also changed to
the "please help us fix".
While we do NOT want to waste time fixing such entries NOW,
letting others become involved and to try to fix the entry
is a good thing as to encourages people to study the entry
and try to fix the entry. We don't need to accept a fix
that is offered, and of the fix transforms the source in
a less than desirable way, such a fix (if accepted) could
be become a alt source code.
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.
This was done quite easily with a bit of thought. I generated a script
that could be modified in vim if necessary (as it turned out to be
though some of it could have been generated too but I did not think of
everything at once and it is a hack).
This is how I generated it:
echo '#!/bin/bash' > bin/check_awards.sh ; ( while read -r g ; do echo grep "$g"; done < <(sed -e 's,_,/,g' -e 's/"/\\"/g' tmp/year-auth-prize.csv | awk -F, '{print grep "\x22" $2 "\x22" " " $1 "/" "README.md"}' ); ) >> bin/check_awards.sh
Then I I modified the file (again this was a hack to make it easier and
quicker and better for being tired too) in vim to make the grep use -Hc
so I could pipe it to 'grep :0'. This found the files without the right
award. So the final command was:
sh bin/check_awards.sh |grep :0
though I did have to edit some files several times.
For reference the script has been added to the repo too but with +x
permissions.
This change also required updating the CSV file in tmp/.
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.
We reverse the workaround for UTF-8 character in 2001/ollinger/README.md
from 76d2e9d053 and put back the é
character in that file.
We did this because the test for reversing a similar workaround
for 2011/borsanyi/README.md worked with commit
43350972c9.
The file `2001/ollinger/README.md` contained a single lower case
small letter e with a acute mark as defined by the UTF-8 character
for the 2 bytes: 0xc3 0xa9.
Replaced the RAW UTF-8 character: "LATIN SMALL LETTER E WITH ACUTE"
with the HTML "é". Not sure what the best way to handle this,
however.
This character crashed markdown tools such as _qlmarkdown_
AND it prevented GitHub from rendering the web site. GitHub
reported in "Build with Jekyll":
```
Conversion error: Jekyll::Converters::Markdown encountered an error while converting '2001/ollinger/README.md':
847
The source text contains invalid characters for the used encoding UTF-8
848
/usr/local/bundle/gems/kramdown-2.3.2/lib/kramdown/parser/base.rb:93:in `adapt_source': The source text contains invalid characters for the used encoding UTF-8 (RuntimeError)
849
from /usr/local/bundle/gems/kramdown-2.3.2/lib/kramdown/parser/kramdown.rb:90:in `parse'
850
from /usr/local/bundle/gems/kramdown-parser-gfm-1.1.0/lib/kramdown/parser/gfm.rb:56:in `parse'
851
from /usr/local/bundle/gems/kramdown-2.3.2/lib/kramdown/parser/base.rb:69:in `parse'
852
from /usr/local/bundle/gems/kramdown-2.3.2/lib/kramdown/document.rb:102:in `initialize'
853
from /usr/local/bundle/gems/jekyll-3.9.3/lib/jekyll/converters/markdown/kramdown_parser.rb:42:in `new'
854
from /usr/local/bundle/gems/jekyll-3.9.3/lib/jekyll/converters/markdown/kramdown_parser.rb:42:in `convert'
855
from /usr/local/bundle/gems/jekyll-3.9.3/lib/jekyll/converters/markdown.rb:77:in `convert'
856
from /usr/local/bundle/gems/jekyll-3.9.3/lib/jekyll/renderer.rb:101:in `block in convert'
857
from /usr/local/bundle/gems/jekyll-3.9.3/lib/jekyll/renderer.rb:99:in `each'
858
from /usr/local/bundle/gems/jekyll-3.9.3/lib/jekyll/renderer.rb:99:in `reduce'
859
from /usr/local/bundle/gems/jekyll-3.9.3/lib/jekyll/renderer.rb:99:in `convert'
860
from /usr/local/bundle/gems/jekyll-3.9.3/lib/jekyll/renderer.rb:83:in `render_document'
861
from /usr/local/bundle/gems/jekyll-3.9.3/lib/jekyll/renderer.rb:62:in `run'
862
from /usr/local/bundle/gems/jekyll-3.9.3/lib/jekyll/site.rb:479:in `render_regenerated'
863
from /usr/local/bundle/gems/jekyll-3.9.3/lib/jekyll/site.rb:472:in `block in render_pages'
864
from /usr/local/bundle/gems/jekyll-3.9.3/lib/jekyll/site.rb:471:in `each'
865
from /usr/local/bundle/gems/jekyll-3.9.3/lib/jekyll/site.rb:471:in `render_pages'
866
from /usr/local/bundle/gems/jekyll-3.9.3/lib/jekyll/site.rb:192:in `render'
867
from /usr/local/bundle/gems/jekyll-3.9.3/lib/jekyll/site.rb:71:in `process'
868
from /usr/local/bundle/gems/jekyll-3.9.3/lib/jekyll/command.rb:28:in `process_site'
869
from /usr/local/bundle/gems/jekyll-3.9.3/lib/jekyll/commands/build.rb:65:in `build'
870
from /usr/local/bundle/gems/jekyll-3.9.3/lib/jekyll/commands/build.rb:36:in `process'
871
from /usr/local/bundle/gems/github-pages-228/bin/github-pages:70:in `block (3 levels) in <top (required)>'
872
from /usr/local/bundle/gems/mercenary-0.3.6/lib/mercenary/command.rb:220:in `block in execute'
873
from /usr/local/bundle/gems/mercenary-0.3.6/lib/mercenary/command.rb:220:in `each'
874
from /usr/local/bundle/gems/mercenary-0.3.6/lib/mercenary/command.rb:220:in `execute'
875
from /usr/local/bundle/gems/mercenary-0.3.6/lib/mercenary/program.rb:42:in `go'
876
from /usr/local/bundle/gems/mercenary-0.3.6/lib/mercenary.rb:19:in `program'
877
from /usr/local/bundle/gems/github-pages-228/bin/github-pages:6:in `<top (required)>'
878
from /usr/local/bundle/bin/github-pages:23:in `load'
879
from /usr/local/bundle/bin/github-pages:23:in `<main>'
```
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