The FAQ now notes that there can be times where the jparse repo
(https://github.com/xexyl/jparse/) is different from the mkiocccentry
repo's subdirectory jparse. This is one of the reasons the tools in the
mkiocccentry and the jparse repo show the jparse API with the -V
(version) option.
I believe that this is all that's needed for the jparse repo in the FAQ
but time will tell on that.
Added a new "FAQ 1.4 - What is the **Great Fork Merge**?"
and a new "FAQ 6.18 - I do not understand the IOCCC, can you explain it
to me?".
Updated "FAQ 0.11: How can I validate any JSON document?"
with new jparse info.
Performed `make gen_top_html` to accomplish the above and to test under macOS.
Something that has bothered me VERY MUCH for A VERY LONG TIME is that
the honour roll (under my name) was not very humble and in some respects
rather redundant. I have fixed this a great deal and improved the
readability of it too (grammar and so on).
I also added a point about fixing many entries that no longer worked and
I also did this for Yusuke Endoh too as he was responsible for fixing
numerous (at the least) entries that no longer worked (and it should be
acknowledged and honoured just as much as what I did).
The FAQ I improved is related to one of the things that is in the above,
to do with alternate code. It now explains some of the purposes of
alternate code and why (in some cases) alt code was added when it might
or might not be useful (a judgement call that invariably is not always
perfect). It notes that in many cases the alternate code comes from the
author directly.
With these changes a problem that I felt was a VERY BIG problem should
be resolved now.
A number of rules have been moved from entry `Makefile`s into the
`1337.mk` include file to make it easier for these common rules to be
updated or modified globally (by modifying the `1337.mk` include file).
The entry level `Makefile`s are now similar in form to the
/Makefile.example](https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example)
file from the other repo.
The following make rules were moved into the `1337.mk` include file:
- `make indent.c`
- `make install`
- `make diff_orig_prog`
- `make diff_prog_orig`
- `make diff_alt_prog`
- `make diff_prog_alt`
This simplifies the entry level `Makefile`s so that they mostly reflect
the specifics of the particular entry.
Mentioned in FAQ 4.2, that the make diff rules are in the `1337.mk` include file.
Fixed invalid TAB character in `faq.md`.
Removed `make clean` directives that removed `indent.c`. This file is now
removed via `make indent_clean`, a clean rule that also removes `indent.c`.
Removed `make clobber` directives that removed sandwich, This file is now
removed via `make indent_clobber`, a clean rule that also removes `sandwich`.
Added `make indent_clean` and `make indent_clobber` rules into the top level
`Makefile` and the year level `YYYY/Makefile`.
Performed `make quick_www` to accomplish the above and to test under macOS.
We add links to jump to the top of the file at the bottom of FAQ
sections.
Improved Makefile samples for FAQ 0.3.
Performed `make faq` to accomplish the above and to test under macOS.
We improve entry `index.html` navbar links by allowing the
next and previous to link across years.
The `make genpath` now forms `.allyear`, which is a
sorted contamination of all YYY level `.year` files.
Updated `make help` to reflect the `make genpath` functionality.
Updated FAQ 6.8 to talk about the `.allyear` file.
Fixed links to `.top` and `.allyear' to refer to GitHub.
Changed `bin/subst.entry-navbar.awk` VERSION from "1.2 2024-03-02"
to "1.3 2024-08-02".
Changed `bin/subst.entry-index.sh` VERSION from "1.3.5 2024-08-05"
to "1.4 2024-08-09".
Performed `make www` to accomplish the above and to test under macOS.
Added FAQ 4.9 "What is the original source file?".
Added links for "dot_path" (and "dot_year" and "dot_top").
Clarify reasons why `OK_to_edit` might be set to `false`.
Performed `make www` to accomplish the above and to test under macOS.
Several new FAQ entries have been added to discuss some of the details
of chkentry, txzchk, fnamchk, jparse and maybe others that are related
to the rules and guidelines (and in particular rule 17 and how to
package submission tarballs). As there are new FAQ entries on these
(which is much of what was in the guidelines) the guidelines have been
shortened for these additions.
Looking over the rendered html files it seems okay but I believe that
these entries are works in progress and not complete.
For reference the new FAQ version is 28.0.3 2024-07-27 and the new
guidelines version is 28.11 2024-07-27.
This FAQ was added as part of updates to bin/index.html. I did notice
that there are some inconsistencies with formatting in some FAQs
compared to this (and others also). The example here is that for JSON
members it would be better to use inline code blocks than italics but
some use italics instead. There are others as well. I did look at the
format and the links in this updated FAQ but the format inconsistencies
can be addressed another time - after it is clear that new FAQs will not
have to be added. Even so this FAQ that was added here could also
possibly be improved further - also later on.
The bin/index.html updates need to be more thoroughly checked as part of
further documenting the newer tools (and any additional ones that might
be added) but there should be some improvements as well. This required
check will also be done later on.
The fields are now in the order that the mkiocccentry tool writes them.
A brief note on how to verify that the .auth.json and .info.json files
are valid JSON (not valid according to the IOCCC rules but valid JSON)
is at the end of each of these FAQs. Given that there are numerous FAQs
on different JSON files it seems like that it might be better to have an
entire FAQ on this (it links to a subsection in an FAQ about another
kind of JSON file). Where this might go is unclear to me so it has not
been done yet.
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.
Landon Curt Noll