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.
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.
In case someone wants more of a challenge in a subsection of the judges'
remarks it has the notice about trying to figure it out by looking at
the code and only (unless they are not looking for an additional
challenge) if they get stuck should they come back to read the author's
remarks.
This includes updates from a recent change in txzchk and more details
about the tools and what they check (warnings and errors) and how to use
them individually.
This does need to be reviewed further, possibly being shorted or
referring to an FAQ, but it's a good start.
The rules had a typo fix as well.
Some of these are very important technical fixes as they stated things
that were not accurate. Other things were (hopefully) clarified. Another
check will have to be done sometime soon.
This does mean that in some cases there is now redundant markdown '**'s
to make the links bold but those can be removed as they are discovered -
or not.
FAQ 3.21 tells what try.sh and try.alt.sh scripts are and why one might
want to use them.
FAQ 4.7 discusses why some files were renamed.
FAQ 4.8 discusses additions and removal of some files.
Landon Curt Noll