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.
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.
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 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.
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.
In most cases the word was changed to 'obfuscation' as it was about
obfuscation, not deobfuscation. In some cases like 1995/leo since the
file was (in 1995/leo) about a secret switch it was changed to
'secret.md' (and 'secret.html') but there were others like that as well.
One entry had the words 'spoiling the size rule' but this had been
changed to 'deobfuscating the size rule' which was obviously wrong.
In the latter YYYY/README.md files the judges had written after some
entries (brief summaries) '...
...We'll stop spouting spoilers now. Have fun exploring all the
entries!
but that was changed to:
...We'll stop spouting deobfuscation information now. Have fun
exploring all the entries!
which wasn't really about deobfuscation but just a brief summary of what
the entries did.
And in the most problematic case (at least for me :-), 2018/ferguson) I
had put a joke in:
... but it's the only Easter egg I won't spoil
but it was changed to 'won't deobfuscate' which not only is not what it
is but it spoilt the joke.
In some cases the word was changed back to 'SPOILER' (or similar) but in
most cases not. I believe it should be better now. There are some
caveats, however, as below.
Although make find_missing_links is okay I do not remember if this will
catch links that refer to '%%REPO_URL%%' or other pandoc tokens. This
means I might have to go back to some earlier years to verify links are
okay. That should not take that much time I hope.
It might also be that some wording can still be improved some but it is
hoped this will be discovered when checking links and looking over the
manifest (which obviously changed).
The new FAQ is about how to report bugs in mkiocccentry tools. The rules
and guidelines link to this FAQ.
The rules and guidelines have been corrected and clarified in a number
of ways.
The guidelines had many fixes and where necessary updates (about new
tools for instance) plus some fun for people to discover.
The FAQ was slightly updated as well for the guidelines.
There were numerous things that had to be fixed and there will likely
have to be some discussion as well.
Some formatting fixes and additional links were also added.
This commit involves some updates to the FAQ and while I was at it I
fixed some references of 'entry'/'entries' to 'submission'/'submissions'
(those that should not be 'entry' or 'entries').
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.
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.
Since less information is shown on an entry's index.html page than in
the past a short FAQ entry about how to find the information seems like
a good idea to have.
The index.html file (from index.md) now links to the no JavaScript menu
for those who either wish to use a plaintext menu or for those who the
menu does not work (like I discovered with my iPhone 8 Plus - iOS 16
Safari, a bug that was fixed in iOS 17). It also links to a new FAQ
about the menus: how they work and also what to do if they don't work.
By 'how they work' this refers to on desktop/laptops, on mobile devices:
without JavaScript enabled and also on mobile phones and tablets in
portrait and also landscape mode plus on mobile devices wider than 1024
pixels and also the browser bug I referred to above.
This includes three new png files, screenshots of how it looks on an
iPhone 14 Pro Max (which should be like other mobile phones), one which
shows the iOS 16 Safari bug and one which shows desktops. These are of
course used in the FAQ.
Although not every html file has a link to the plaintext (i.e. the menu
for those with JavaScript disabled), it is hoped that these two changes
will help people navigate if they have a problem with the menus.
The (same two) authors of 1995/heathbar and 1995/makarios had invalid
information, in one case email as well as in both the url and location.
The location was previously set to unknown (ZZ) but I knew from the
archive (which used to be what the README.md files which were the hint
files had until I was asked to remove that information which was done
November 2023) that it was US.
I also noticed, however, that the url was invalid and in one case the
email was invalid (it referred to the same domain).
With these problems in mind the url was changed to refer to the website
on the Internet Wayback Machine (in both), the email was set to null in
the one that had an email (now it's null in both) and the location_code
was set to US (in both).
I then did:
touch 1995/heathbar/README.md 1995/makarios/README.md
so that I could do:
make quick_www
as only two index.html files had to be updated. This also updated
authors.html and location.html, of course.
The FAQ was updated with more information on how to update author
information with the above two as an example and it now also says how to
validate json for those who want to make changes to author information
(or if anything else in the future is put in json).
It should be 'Location of winning authors' (as it is now) but by mistake
there was an extra space ('Location of winning authors'). Obviously
this is a huge commit as every html file with a menu (almost all) had to
be updated.
The fixes in the FAQ correspond to the fixes in the contact.html file.
With this commit the contact.html file seems okay but the FAQ is not yet
looked at.
A few page names were changed and menu link (titles) were changed too.
By page names it means either DESCRIPTION or HEADER_2 in
bin/md2html.cfg. Although it looks better and is more consistent, there
might be one or two that can be further improved.
Naturally every html file that is markdown based was updated.
In some pages at the top it had 'and' but in the menu it had instead a
'&'. The menus (JavaScript and otherwise) now has 'and' to match the
pages. The file nojs-menu.html has been checked for broken links and
indeed one at least was fixed. Very few top level html files need to be
checked now. Some that are entirely generated should be okay but links
will still be checked to be sure.
Some cases of '(Mis)features' from the previous commit were also
corrected to '(mis)features' as this is also part of menu and page
consistency.
The files markdown.{md,html} have had the menus updated too but there
are some other changes that were works in progress. This file is not
thus completed but will be sometime soon.
The entry that was referred to (not named but I remember it as
1986/hague) as having an alternate version for the purpose that it
showed correct output but crashed was fixed quite some time back and so
this has been removed.
In the FAQ entry for downloading the tarballs (which has been renamed to
be a bit clearer) the example tarball for each kind (individual entry
and an entire year) it now links to the tarball in question so one can
more easily determine the path. It also shows where one can find the
tarballs (for each type). Other improvements have also been made but
this and the rest of the file will be further reviewed at another time.
Typo fixes.
This question is called '3.20 - How do I download individual entries or
entries of a given year?' and discusses both the individual entry
tarballs as well as the year based tarballs, each in a subsection. Each
part explains files that exist in the tarball and there are examples of
how one might make use of them after extracting the tarball. It gives an
example tarball name for each, including the path.
Two typo fixes were made in the FAQ 3.13 title (in the link at the top
and the actual question/answer as well).
Although the links in this new entry should work I have not yet checked
the file (though I did check those links added) and I will not until it
becomes clearer that not much more has to be done with the FAQ. Instead
I will focus on the entry html files and possibly together with that the
bugs.html file as well, to make sure of consistency.
There were some cases where the wrong JSON member was referenced when
explaining a different JSON member (in author details).
Also to help clarify the part about if the value is unknown, I have
changed it to be 'it should be ...' rather than 'they should use' since
obviously the author themselves ought to know their email, URL, alt URL
etc. :-)
As numerous entries had to have arg type or arg count in main() changed
(usually to do with clang but not always) it seems like this should be
added to the FAQ.
Regarding use of `temp-test-ioccc` in current repo files:
We will ignore files under `tmp/` as they are going away.
We will ignore files under `bin/` as they will have their default `REPO_URL` value changed during the later parts of the **Great Fork Merge**.
We will ignore `*.html` files as the above changes to `bin/` tool will also change them during the later parts of the **Great Fork Merge**.
We will ignore `sitemap.xml` as the it will change during the later parts of the **Great Fork Merge**.
So this leaves for our consideration the files printed by this command:
```sh
find * -type f ! -name '*.html' ! -name sitemap.xml ! -path 'tmp/*' ! -path 'bin/*' -print0 | xargs -0 grep -l 'temp-test-ioccc'
```
We see 5 (3 sir), 3 cases:
* README.md index.md
The reference to `temp-test-ioccc` will be removed when a given section goes away as part of the later parts of the **Great Fork Merge**.
Nothing needs to be dome here other than to add some **XXX** comments to help remind us of what needs to be done in later parts of the **Great Fork Merge**.
* bugs.md faq.md news.md var.mk
The use of `temp-test-ioccc` is outside of a blob.
Here `https://github.com/ioccc-src/temp-test-ioccc/` may be be replaced by `https://github.com/ioccc-src/winner/` in anticipation of the **Great Fork Merge**.
There is an exception: The historic discussion abouts the history of the `temp-test-ioccc` repo needs to retain their `https://github.com/ioccc-src/temp-test-ioccc/` strings in `faq.md` and `news.md`.
* 2005/sykes/README.md
The markdown links that start with `https://github.com/ioccc-src/temp-test-ioccc/blob/master/` should instead start with `%%REPO_URL%%/`.
After the **Great Fork Merge**, the `%%REPO_URL%%/` value will refer to `https://github.com/ioccc-src/winner/blob/master/` instead.
* 2020/ferguson1/snake.1
There is not a tool to "pre-process" cat pages like there is for markdown files: no should there be.
The cat page refers to a markdown file when instead it should refer to a HTML page.
In this case we suggest that `https://github.com/ioccc-src/temp-test-ioccc/blob/` be replaced by `https://www.isthe.com/`, and `.md` be replaced by `.html` in anticipation of what it will need to be after the **Great Fork Merge**.
* YYYY/entry_dir/*.sh
The shell scripts references by the above command are "helper shell scripts. Like man pages, there is no "pre-processor" for shell scripts, nor should there be.
Looking at these helper shell script files in detail:
```sh
find * -name '*.sh' ! -path 'tmp/*' ! -path 'bin/*' -print0 | xargs -0 grep 'temp-test-ioccc/blob/master'
```
We see that they all make references to `faq.md#something.`.
This is wrong in 2 ways:
0) They should not refer to the markdown file `faq.md` but rather to the HTML file `faq.html`.
1) They punctuate a literal string (with one exception) by adding a final period (".") to a string that requires somebody to copy and paste and exclude the final period (".").
Since these echo commands are suggesting that the user view something within the FAQ, we recommend that `echo "Tip: see https://github.com/ioccc-src/temp-test-ioccc/blob/master/faq.md#` be replaced by `echo "Tip: see https://www.ioccc.org/faq.html#` AND that the final period (".") be removed. Thus they too will anticipate what they will need to be after the **Great Fork Merge**.
This was done by:
sgit -e 's/alt code/alternate code/g' . ; git co tmp/OLD_manifest
as well as updating the tmp/manifest.numbers spreadsheet and exporting
to the CSV file (though that would not strictly be necessary).
The way this works means that the update manifest script does not need
to be run as it sgit(1) touched the .entry.json files (any that needed
to be updated) and so would any index.html files. An example for both
.entry.json and index.html files being modified due to manifest is
2012/kang.
Numerous Makefiles were updated, any try scripts that had 'alt code'
instead of 'alternate code' and README.md/index.html files (unrelated to
the manifest as 'alt code' was used in other places too) and obviously
the manifest.numbers spreadsheet.
However to be safe I will do a run of the manifest script in a bit even
though it should not be necessary. If no commits are made it means all
is good and if any commits are made for the manifest it means that I
did not think of something (or else I made another change after this).
Improved information on how to view the status of the IOCCC, directing
people to `status.html` (which includes a copy of the contents of
`status.json`) instead of directly referring people to `status.json`.
Improved format of "FAQ 0.0: How may I submit to the IOCCC?".
Improved bottom of `index.html` to refer to the above.
Landon Curt Noll