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`.
The Makefile rules now have a comment for what they do. The help rule
has not been updated.
The bin/README.md has had some format fixes and some typo fixes as well.
Rebuilt bin/index.html but these two files will have to be checked more
thoroughly later.
The variables CSV2ENTRY and ENTRY2CSV have been added for the new rules
that run the new rules, csv2entry and entry2csv, respectively, according
to the log in 097dd49cc7.
The rules have been added to .PHONY (thinking about this quickly I
believe this is correct but if not it can be corrected) but not make
help as I am not sure where in that rule they should be and I am also
not sure what should be said even as a summary. The rules have a comment
for which tool it runs but it also does not have a summary as I am not
sure what it should say and I do not currently have the time to look
into it.
With this commit it is now easier to run these tools for testing and
otherwise.
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.
This 'bug' was not actually a bug but an improper reading of the author's
remarks. Upon another read later on (today) it became clear what
the author was getting at. It is not what happens upon execution but
rather the layout of the code: if the alternate code (the US specific
version) is a one line of 160 characters and your terminal wraps at 80
columns it will spell out (over two lines):
mainland America
The westley.alt2.c is exactly this. It can be compiled if one has gcc or
a compiler that does not have the limitations of arg types to main()
that clang has by using make alt2 (not make alt as it would fail for
clang but people might want to use the alternate code and in fact the
try.sh script does this) but it has the original limitation that one
needs to have a terminal that wraps at 80 columns (since it has to be
the same length of code). But as that size is not that common nowadays
(and in most cases one would have to resize their window) it's mostly
for show.
Updated manifest, rebuilt .entry.json and index.html.
Updated bugs.md and rebuilt bugs.html.
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.
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.
It is preferable that unobfuscated code is by the author if they have
(and many have done exactly that).
It would also be preferable to include the author or authors of the entry or
entries if at all possible.
This update includes a link to how to find more information about an
author and I think that FAQ was slightly improved as well.
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.
This solves a problem with smaller screens where the code would wrap to
the next line which ruins the formatting of the code on smaller devices.
A downside to this is that it makes it not fit on the screen but since
it technically did not fit on the screen before and this way line breaks
are not added this seems a much better way. It also will mean we
shouldn't need to try and fix all the other long lines in code blocks
(which not only can be problematic but in some cases it can be wrong -
plus it is taking too much time away from moving from entry to the next
entry to the next entry).
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`).
This code was found on the author's web page about the entry and has
been added as prog.alt.c. I added the try.alt.sh script as well.
Manifest updated and rebuilt .entry.json and index.html files.
The previous url was the GitHub url but he has his own domain. The
alt_url is his article about the winning entry of his (of course if he
wanted something different he could do that but it's a good enough guess
for now).
The location of the link is in the About menu under the 'Contacting the
IOCCC' and above 'Thanks for the help'. At first I had it at the very
bottom, under 'IOCCC markdown guidelines', but it seemed better to have
it closer to contacting the IOCCC. This is the same location in the no
JavaScript menu (which, for those who do not know or forget, is not a
requirement except for some screen sizes).
The top level Makefile has a new 'security' rule. Updated make help.
Typo fixes in make help.
SECURITY.html has had a few updates as well: change the wording of entry
code is unsupported (it now says 'ALL CODE IN ALL IOCCC ENTRIES IS
UNSUPPORTED!!') and it now links to the mkiocccentry repo and how to
report a possible security vulnerability in that repo; as that IS
supported - and since there was reference to discussing security
concerns is in SECURITY.html - even though the entries will not receive
security updates - it seemed a good idea to have a link to report such
security issues in the mkiocccentry repo. Perhaps the FAQ needs to be
updated for this too.
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.
Also removed what seems to be unnecessary quotes, much along the lines
in some FAQ links (that will be having the quotes removed).
Added SECURITY.md to bin/md2html.cfg and updated bin/gen-top-html.sh to
build SECURITY.html. The configuration can be improved for keywords and
other things and the file is not linked into the website either but
presumably it should be.
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.
These are very detailed as they are very important parts of the
mkiocccentry toolkit. The guidelines will likely refer to these for
those who want to know more details but that is for another commit.
Landon Curt Noll