Any canonicalization errors (e.g., sort error, mv error, etc.) will
cause an immediate `exit 8`.
The `bin/entry2csv.sh` tool will verify the author_handles referred
to by `author_wins.csv` and check the `author/cauthor_handle.json' file set.
The `bin/csv2entry.sh` tool will verify the author_handles referred
to by `author_wins.csv` and check the `author/cauthor_handle.json' file set.
In `bin/entry2csv.sh` changed VERSION from 1.0.4 2024-07-19"
"1.1 2024-07-20".
In `bin/csv2entry.sh` changed VERSION from to "1.0.1 2024-07-19"
"1.1 2024-07-20".
Performed `make www` to accomplish the above and to test under macOS.
TODO: Remove the `tmp` directory (after saving contents into private storage)
after testing and improvement of `bin/csv2entry.sh` and
`bin/entry2csv.sh is complete.
Fixed typo in `make csv2entry` rule in `Makefile`.
Fixed how exit codes triggered deep within loops are realized.
Regularize how raising an exit codes with loops are announced.
The use of `-n` does NOT prevent the creation of temporary files:
only permanent files are not modified with `-n`. NOTE: While
CSV files are NOT permanent files, they too are not modified with `-n`.
Fixed the canonical sort of `manifest.csv`. Now running
`bin/csv2entry.sh` immediately after `bin/entry2csv.sh` will not
modify `manifest.csv`.
If `bin/csv2entry.sh` encounters an author handle for which
there is no `author/author_handle.json` file, the tool will
complete the formation of the CSV file set and then exit 9
at the very end.
Fixed a few comments in `bin/csv2entry.sh` and `bin/entry2csv.sh`.
In `bin/entry2csv.sh` changed VERSION from "1.0.3 2024-07-19"
to "1.0.4 2024-07-19".
In `bin/csv2entry.sh` changed VERSION from "1.0 2024-07-19"
to "1.0.1 2024-07-19".
Performed `make www` to accomplish the above and to test under macOS.
TODO: Incorporate as needed, more processing of `author/author_handle.json` files.
TODO: Remove the `tmp` directory (after saving contents into private storage).
Added `make entry2csv` and `make csv2entry` to the help list.
Changed the "syntax" if the lines printed by `make help` so
that when one selects the entire line and pastes that line
into the shell, the trailing comment is not seen as a rule,
nor it is executed.
Made other minor formatting changes of `make help`.
Added `bin/csv2entry.sh` VERSION "1.0 2024-07-19".
In `bin/entry2csv.sh` changed VERSION from "1.0.2 2024-07-14"
to "1.0.3 2024-07-19".
The `bin/entry2csv.sh` tool converts all entry `.entry.json` files
into canonicalized `author_wins.csv`, `manifest.csv`, and `year_prize.csv`
CSV files.
The `bin/csv2entry.sh` tool converts `author_wins.csv`, `manifest.csv`,
and `year_prize.csv` (canonicalizing them if needed) `.entry.json`
files for all entries.
To change the manifest for one or more entries:
```sh
bin/entry2csv.sh -v 1
# ((import `manifest.csv` into a spreadsheet tool))
# ((modify in the spreadsheet tool, the content as needed))
# ((export the spreadsheet contents, as the CSV file `manifest.csv`))
bin/csv2entry.sh -v 1
make www
``
To change the award for one or more entries:
```sh
bin/entry2csv.sh -v 1
# ((import `year_prize.csv` into a spreadsheet tool))
# ((modify in the spreadsheet tool, the content as needed))
# ((export the spreadsheet contents, as the CSV file `year_prize.csv`))
bin/csv2entry.sh -v 1
make www
``
To change the authorship of one or more entries:
```sh
bin/entry2csv.sh -v 1
# ((import `author_wins.csv` into a spreadsheet tool))
# ((modify in the spreadsheet tool, the content as needed))
# ((export the spreadsheet contents, as the CSV file `author_wins.csv`))
bin/csv2entry.sh -v 1
# ((modify winning_entry_set of `author/author_handle.json` files as needed))
make www
``
Performed `make www` to accomplish the above and to test under macOS.
TODO: Review and improve/expand as needed, changes that were made to `bin/README.md`.
TODO: Remove the `tmp` directory (after saving contents into private storage).
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.
We use the `status_codes=("${PIPESTATUS[@]}")` method to
collect all of the bash exit codes from a pipe in one go,
and then test for any failure with `[[ ${status_codes[*]} =~ [1-9] ]]`.
There are other cases where an exit code is obtained,
however in each of those cases only a single exit code
from just one of the commands in the pipe is needed.
In `bin/gen-sitemap.sh` changed VERSION from "1.3.9 2024-06-21"
to "1.3.10 2024-07-18".
In `bin/gen-status.sh` changed VERSION from "1.5.4 2024-07-18"
to "1.5.5 2024-07-18".
Performed `make www` to accomplish the above and to test under macOS.
We improve FAQ 5.5 (correcting or updating IOCCC author information)
by adding a generic example on changing author's URL.
Now the "PLEASE HELP us identify proper locations for IOCCC authors"
(that now follows the change of URL example) contains only
generic information about changing the location_code from ZZ to AU.
We remove the indirect reference to author email in FAQ 6.16 as we
do not wish to call out what we previously included in the
`authors.html` page.
This commit modifies that otherwise perfect fine PR #2578.
Performed `make www` to accomplish the above and to test under macOS.
We improve FAQ 5.5 (correcting or updating IOCCC author information)
by adding a generic example on changing author's URL.
Now the "PLEASE HELP us identify proper locations for IOCCC authors"
(that now follows the change of URL example) contains only
generic information about changing the location_code from ZZ to AU.
We remove the indirect reference to author email in FAQ 6.16 as we
do not wish to call out what we previously included in the
`authors.html` page.
This commit modifies that otherwise perfect fine PR #2578.
Performed `make www` to accomplish the above and to test under macOS.
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.
We improve the language in `SECURITY.md` and the resulting
`SECURITY.html` page, and add an important disclaimer. We also add
that same disclaimer to the bottom of the of the main `index.html`
we page (via `index.md`).
We add a new `bin/entry2csv.sh` tool VERSION "1.0 2024-07-14"
that will convert entry `.entry.json` files into 3 CSV files
`author_wins.csv`, `manifest.csv`, and `year_prize.csv`.
The `bin/entry2csv.sh` tool uses `bin/manifest.csv.entry.awk`.
The new `bin/manifest.csv.entry.awk` VERSION is "1.0 2024-07-14".
This tool will be used to convert entry `.entry.json` file into
CSV files suitable for importing into a spreadsheet application
for further processing.
TODO: Write the `bin/csv2entry.sh` tool, for a given entry, to
convert 3 CSV files into that entry's c`.entry.json` file.
As a trial, we change the `<pre>..</pre>` and `<code>..</code>`
blocks form "_Indigo_" to "_DarkGreen_".
We needed a colour that was **NOT** on the "_blue_ thru _purple_" colour
range, nor "_red_" that is currently used by links.
We choose "_DarkGreen_" as this is the same colour as the box around
quotes. Given that `<pre>..</pre>` and `<code>..</code>` text
is unlikely to be confused with a box around a quote, we felt this
was a safe colour to try.
We add a FAQ version of "28.0 2024-07-14" to `faq.md`
using a similar form of version strings as `next/rules.md`
and `next/guidelines.md`.
Ran `make faq` to perform and test the above under macOS.
While the use of `**font-weight: bold;` helps links standout in
most cases, there a few "_link heavy_" pages were the **MANY BOLD
LINK IN CLOSE PROXIMITY** looks excessive to the point of being
distracting. In areas where **nearly everything is BOLD, nothing
seems to stand out**.
Fortunately there seems to be only a very few places where this is a problem:
* `faq.html` - the table of contents
* `authors.html` - nearly the entire page
* `location.html` - nearly the entire page
* `years.html` - nearly the entire page
As an **bold** 😎 experiment we added to the CSS:
```css
/*
* To make a link non-bold, use: <a class="normal" href="url">link text</a>
*/
a.normal {
font-weight: normal;
}
```
And then modified select tools and a markdown file to "_unbold_"
those "_link heavy_" areas of the 4 pages above.
We don't claim that this is the best solution and there may be an
even better way to solve this, nevertheless we **do** think the it
improves the look and feel of the "_link heavy_" areas of the 4
pages above. For example, in `faq.html` beyond the table of
contents, the bold links look reasonable (although again there are
some quasi-"_link heavy_" areas down in the page look a bit too
bold, but perhaps not enough to warrant changing so we only altered
the table of contents).
In a few cases, while we were editing code that generated links,
we remove a few "**.**"'s where we didn't think they helped the
look and feel.
Change `bin/gen-authors.sh` VERSION from "1.10.3 2024-05-24"
to "1.10.4 2024-07-13".
Change `bin/gen-location.sh` VERSION from "1.4.2 2024-05-19"
to "1.4.3 2024-07-13".
Change `bin/gen-years.sh` VERSION from "1.3.3 2024-07-07"
to "1.3.4 2024-07-13".
Performed `make www` to accomplish the above and to test under macOS.
Repaired the output_award function in `bin/gen-years.sh`
and `bin/output-year-index.sh`.
Previous modifications to the output_award function made
is impossible to detect if output was empty.
Modifications also ran counter the Unix concept that a function
should ideally to one thing and one thing well.
Changed so that the code that called the output_award function
would decorate the award with bold markdown syntax.
Changed `bin/gen-years.sh` VERSION from "1.3.2 2024-05-19"
to "1.3.3 2024-07-07".
Changed `bin/output-year-index.sh` VERSION from "1.4.1 2024-04-28"
to "1.4.2 2024-07-07".
Ran `make www` to perform the above and test under macOS.
Perhaps we need a test, run under `make test`, to look for
cases where 'foo.html' is older than 'foo.md` or where
`index.html` is older than `README.md`, etc. ???
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.
Thanks to @xexyl for the suggestion.
Changed `bin/chk-entry.sh` VERSION from "1.1.7 2024-04-28"
to VERSION="1.1.8 2024-07-06".
Performed `make test` to test the above.
Harmonized and improve the headers that are prepended
to the rules and guidelines given the IOCCC state.
Attempted to make the headers that are prepended
to the rules and guidelines more consistent.
Make reference to, where applicable, FAQs
about feedback and questions in those headers.
Perform `make www` to perform the above and test under macOS.
Fixed a number of typos, inconsistencies, and problems with the
rules and guidelines.
Improved how the closed version of the rules and guidelines declare
themselves at the top of the markdown and HTML file.
Changed `next/rules.md` VERSION from "2024-06-29-v28"
to "28.1 2024-06-29" in order to be more consistent
with IOCCC tool version format.
Changed `next/guidelines.md` VERSION from "2024-06-29-v28"
to "28.1 2024-06-29" in order to be more consistent
with IOCCC tool version format.
Make a minor format fix to `faq.md`.
Performed `make status` and `make www` to test the above umder macOS.
Added a `#weverything` div tag to the FAQ.
Expanded and improved(?) a number of rules and guidelines.
In particular, the consequences of the new mkiocccentry
repo have been put into the rules and guidelines.
This is a checkpoint from which we can review,
edit and improve.
The way that markdown quotes are currently formatted (with a gray
vertical line) looks too much like a change bar. The change bar
is an important tool to help notice new and changed rules and
guidelines. Unfortunately the current quotes style looks too much
like a change bar, so we use markdown quotes **ONLY** for literal
quotes (such as from Mark Twain) in the `guidelines.md` file.
Clarified and simplified the request to not use ASCII tabs within
markdown file content.
Added _guidelines_ to `next/guidelines.md` about not using ASCII
tab characters in markdown files while stating that is just fine
to use ASCII tabs in non-markdown files and C code.
The `make tab_check` rule now simply checks for ASCII tabs within
markdown files, except `markdown.md` where they are required to
serve as examples of what not to do.
Perform `make quick_www` to perform the above and test under macOS.
Perform `make www` to perform the above and test under macOS.
Given that there are no longer any ASCII tab characters within
leading whitespace in markdown files, commit XXX added a `make
tab_check` rule to the top level `Makefile`. Moreover both `make
quick_www` and `make www` perform a `make tab_check` after running
`make clobber`.
Perform `make quick_www` to perform the above and test under macOS.
Perform `make www` to perform the above and 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.
Each individual IOCCC rule has its own div tag.
References to a specific IOCCC rule is now a link.
We now use the term **IOCCC rules** more consistency when
referring to the rules.
We now use the term **IOCCC guidelines** more consistency when
referring to the guidelines.
In the **IOCCC guidelines**, we use _guideline_ when
referring to a general guideline.
Updated **IOCCC rules** and **IOCCC guidelines** to 2024-06-23-v28.
Added guidelines about the recent Rule 2a changes.
Improved to order of the guidelines related to Rule 2.
Added a ">" formatted quote about the iocccsize summary to the IOCCC guidelines.
Perform `make www` to perform the above and test under macOS.
Improve the formatting in `1992/westley/README.md`
and thus the resulting `1992/westley/index.html`.
Corrected a mistake on the use of `./whereami.alt`.
Perform `make www` to perform the above and test under macOS.
The `bin/pandoc-wrapper.sh` tool will use `expand(1)` to expand
leading ASCII TAB characters into multiples of 8 ASCII space
characters on all markdown data before piping it into `pandoc(1)`.
Thus, any leading ASCII TAB character in markdown files will be
automatically converted into spaces using 8 character tabs.
Changed `bin/pandoc-wrapper.sh` VERSION from "1.6.3 2024-06-22"
to "1.7 2024-06-22" to preform the above.
Perform `make www` to perform the above and test under macOS.
It turns out that only one other HTML file was impacted: `bugs.html`.
All other leading ASCII tab characters have been rendered
[Mostly Harmless](https://en.wikipedia.org/wiki/Mostly_Harmless). :)
When `bin/pandoc-wrapper.sh` encounters a fatal error, it will
leave behind `debug.input.md` and `debug.output.html`.
Added `debug.input.md` and `debug.output.html` to `.gitignore`.
The `.gitignore` file comment noew refers to `sgi.sh` not sgi.
Changed `bin/pandoc-wrapper.sh` VERSION from "1.6.2 2024-04-18"
to 1.6.3 2024-06-22" to preform the above.
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.
One must **NOT** use ASCII TAB characters to intent text. Down the TAB-ed
road is nothing but trouble! There are _quasi-solutions_, however those
have side effects that lead to a different set of problems.
The `markdown.md` was updated to ask that text not be intended with ASCII tabs.
See [Please do NOT use ASCII tabs to indent
text](https://ioccc-src.github.io/temp-test-ioccc/markdown.html#markdown.html#please-do-not-specify-a-language-for-a-code-block).
We discovered this awhile ago and fixed it in markdown files. Sorry
(tm Canada 🇨🇦), we forgot to mention this this in `markdown.md`.
BTW: It took some **deep magic** to be able to show an HTML comment
after a starting fenced markdown code block! See the **NO_COMMENT=**
line in `bin/md2html.cfg`. :-)
TODO: Stamp out indenting TABs in markdown files, especially in code blocks.
TODO: Consider a rule to detect problematic ASCII TAB intendation
within makrkdown files.
Detect were the stat tool is located. If no stat tool is found,
set `$STAT_TOOL` to `false`. Cleanup comments related to
determining the modification time of a file.
Changed `bin/gen-sitemap.sh` VERSION from "1.3.8 2024-04-28"
to "1.3.9 2024-06-21".
Changed `bin/gen-status.sh` VERSION from "1.5.2 2024-04-30"
to "1.5.3 2024-06-21".
Perform `make www` to perform the above and test under macOS.
Changed version from "2024-06-11-v28"
to "2024-06-15-v28'.
Changed all places where a date was used.
Improved the "XXX - date/time is TBD - XXX" message format.
Removed more stuff about tweeting that we no longer do.
Added a few missing | change marks.
As we fixed a rules typo, we went ahead and merged in a few of the
new rules that were pending.
Landon Curt Noll