Amongst the changes here is that we do not need to have the hex or html
code (numbers) for open and close parentheses (in links) as there are
names. '(' is & followed by lpar; and the ')' is the same but 'rpar;'
instead. This makes it easier to remember and type and it generates the
same html as well (they are all valid). Now the markdown files are
consistent in this (in some cases hex was used and in others the html
code).
Although many markdown files were updated no html files needed to be
updated as it generates the same html. Even so I ran the appropriate
rules to do so just to verify this.
In the years 1991, 1992, 1993, 1994 and 1995 the README.md/index.html
files referred to the UUCP for mail with the text:
For those who appreciate a bit of Internet history, this is how
people used to contact the IOCCC in this given year
and I added to it the text:
via Unix to Unix CoPy (UUCP)
where 'Unix to Unix CoPy (UUCP)' is a link to 'complete' the history.
Updated 1337 hacker rulz to version 7.
Added `1337.mk` to contain the updated 1337 hacker rulz (v7).
We use an optional include of `1337.mk` (or `../1337.mk`,
or `../../1337.mk`) to include the 1337 hacker rulz.
Changed `make deep_magic` to `make more_magic`.
Changed `bin/tar-entry.sh` VERSION from "1.3.7 2024-07-22"
to "1.3.8 2024-07-23".
Changed `bin/tar-year.sh` VERSION from "1.2.5 2024-07-22"
to "1.2.6 2024-07-23".
Add `make new_entry` to `YYYY/Makefile` and `template/Makefile.year`.
Change `make new_year` to use `sort -n -u`.
Made minor debug message fixes to `bin/new-year.sh`.
Changed `bin/new-year.sh` VERSION from "1.3 2024-07-23"
to "1.3.1 2024-07-23".
Improved `bin/add-dir.sh` to update `YYYY/Makefile` with
the new entry directory name.
Changed `bin/add-dir.sh` VERSION from "1.0 2024-07-21"
to "1.1 2024-07-23".
Performed `make www` to accomplish the above and to test under macOS.
For 1993/ant it clarifies (even though the extension of the file
probably would suggest it) that the man page is in text format.
For 2020/endoh2 there were some mistakes introduced with the renaming of
spoiler to other things.
Rebuilt the .entry.json and the index.html files for both.
Rebuilt 2020/endoh2/obfuscation/index.html.
The unobfuscated version was recently provided by the author so this is
no longer an issue.
A code block in the INABIAF was changed to a quote as it's not code but
something the author wrote.
This entry's index.html might not be done as a question also has to be
addressed before the manifest can be fixed.
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.
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.
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.
In the line in README.md and index.html files that said:
### NOTICE to those who wish for a greater challenge
I added a ':' at the end of the line.
There were some entries that had a link fix in the index.html file but I
only looked up through 1995/leo as those still have to have a 'look and
feel' check and it would just slow things down.
The unobfuscated code, which was put in deobfuscated/, has been turned
into alt code. In one case the already existing alt code was made alt2
and the unobfuscated code was alt. In the case of the ones with two C
files there, the one that did not require modification (to compile in
modern systems) were used as those are original.
In a few cases these changes suggested additional files: a test suite
Makefile for the alt code, a try.alt.sh script and maybe some other
things besides.
The bug status was updated for 2015/howe with a known bug: in particular
the test scripts do not work (at least not completely).
In the manifest all references (except for a file name that has not been
renamed - at least not yet) of 'deobfuscated' to 'unobfuscated': a minor
detail that might not matter much but it sounds ever so slightly better
(maybe). These other entries that had an entry_text change were
1995/garry and 2020/endoh2. Rebuilt .entry.json and index.html files for
this (and in the case of the moved code the index.html files also had to
be changed for that in addition to the Makefiles).
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.
Anthony/@SirWumpus kindly provided these files. The source code and
their Makefiles are in a deobfuscated/ subdirectory (for each of the
three entries) but running make alt
from the entry directory works. It uses the deobfuscated version's
Makefile but copies the compiled binary to the entry's directory to keep
things clean (deobfuscated code separate from the entry) to simplify
using the deobfuscated versions.
Entries that had a test suite Makefile have a new one for the
deobfuscated code and a try.alt.sh script was added to 1992/ant and
1993/ant but the entry_text is a bit different than the usual to
indicate that it's the deobfuscated version.
It might be that the way this is done should be reorganised some but
that can be decided on later.
The entries from 2004 and 2005 have not yet been added because some
decisions have to be made as those are the ones with a configure script.
The manifest was updated and the .entry.json and index.html files were
updated. It is not clear yet if the inventory_order is right but that
will be looked at in the next day or two.
Thank you Anthony!
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).
There are many fixes made but a few questions remain so when I reach
those years I will address those then. Unfortunately, due to
infrastructure work right now, this is all I can say even though there
are a number of things I'd like to say.
The list of expressions in the judges' remarks has been changed so that
it fits nicer on smaller screens (it is no longer a code block but a
list and each operator is surrounded by backticks).
The grammar provided by the author (not the code that explains it but
the grammar) now also fits on smaller screens in a nicer way by breaking
it into multiple lines.
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.
That is to say in the bugs file it will look something like:
STATUS: INABIAF - please DO NOT fix
but as a html file it is already bold as a heading. This means there is
no need in the index.html file to have the explicit **DO NOT** as it's
in a code block and it is not consistent in what is in bugs.html. For
instance 1984/mullender had:
STATUS: INABIAF - please **DO NOT** fix
but this meant the index.html file had the '**'s surrounding the DO NOT
which is not consistent with bugs.html.
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.
Make it consistent with my improvement to bin/gen-years.sh: the entry
awards in the links (to each entry) are now in bold and so are the link
names. This helps them stand out a bit more.
The script set the URL for the tarball of all entries in the year to:
$YYYY/$YYYY.tar.bz2 but the link is relative so for 1984, for example,
it would link to 1984/1984/1984.tar.bz2 which obviously is a 404.
I also changed the formatting and wording of the link. It now is all
bold and it says instead (for example with 1984): 'Download all winning
entries from 1984'. Before it still referred to 'entry source' but it is
all entries and more than just the source.
This commit does not mean that the YYYY/index.html files have been
checked (though it's likely that all should be okay at this point) but
the manifest of entries and the tarball of all entries of the year
should at least be good.
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.
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.
This is a very large commit not only because I forgot to run make www
after updating the menus but I also forgot to do that after the update
to some of the award titles (only quick-readme2index.sh was used).
There is a typo fix in bin/README.md.
This commit does mean that md2html.cfg has to be added to bin/README.md
but that can be done later.
The steps run to verify this works okay:
make www
git status
git diff
git add -u
make update
git status
git restore $(git check)
The last is important as it is not time for make update. 'git check' is
an alias:
git diff --name-only
A lot of the award titles that had more than one word capitalised were
changed to just one word capitalised, the first. Some were changed to
have multiple words capitalised. This happened when it was something
like '... prize' or '... award'. An exception to this is 2020/ferguson1:
'Don't tread on me award'. This is because I am not quite sure if I like
'Don't Tread On Me Award' or if it should be 'Don't Tread on Me Award'
(probably not that). For some like 'Grand Prize' or 'Bill Gates Award'
it's simple but I'm not so sure for my Snake entry of 2020. I will try
changing it and comparing it side-by-side to see which looks nicest.
This commit should make it easier to update the form of the award titles
in that they should all be consistent (or more consistent if not
completely) though it should be noted that the macOS Numbers application
(spreadsheet) is case-insensitive. A reason I did not change 'Don't
tread on me award' to 'Don't Tread On Me Award', yet, besides the above
reasons, is that it's a longer title and I am not sure how I like that
many words capitalised. Still it's a title of a slogan/whatever so it
might be better that way. This will be determined in the near future.
The tmp/year_prize.numbers had the text size increased a fair bit as
the default is too small for my pitiful vision (I changed it within
reason as it can become harder in another way if it's too big - 16"
MacBook Pro screen). One of the columns was also widened as it was too
short even for the smaller size.
For HTML files from markdown files other than README.md, the h2
title now refers to the HTML file instead of the markdown file.
Changed `bin/gen-other-html.sh` VERSION from "1.2.3 2024-04-28"
to "1.2.4 2024-05-31" to perform the above.
Perform `make www` to perform the above and test under macOS.
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).
Although there were a few lines that I kind of looked over quickly, not
evaluating the files in question, those seemed in good state anyway.
Often that was binary files.
In some cases for example input more information was given but not in
all as it was not always clear what it should be and it was not always
clear that it was necessary. Some typos were fixed as well.
Rebuilt .entry.json and index.html files.
A few other files were also modified with some minor fixes like
2006/toledo2/README.md for one example. In that case I believe some
binary files were referenced as %%REPO_URL%% but that is incorrect.
These files were edited before the index.html files were rebuilt so they
should be fine.
It should be noted that although I have gone through the entire manifest
and it might be that issue #1933 can be closed there is still a chance
that when I go through the web pages that I might come across a problem
that I will fix at that time. This might or might not be needed but that
will be determined later.
Now might be a good time to run make www but I will worry about that
later (it might or might not even do anything, depending on what was
missed).
This is a large update that modifies every .entry.json file and fixes
many others. The changes of every .entry.json file are as follows:
- change 'entry source' to 'entry source code' [0]
- change 'original source' to 'original source code' [0]
- change 'directory path from top directory' to 'directory path from top
level directory'
[0] This is for consistency purposes. Other options were pondered but as
the index.html files refer to 'Alternate code' this was the simplest way
to go about it and it also feels more natural. A question was whether to
have 'entry code' and 'original entry code' or to have the word 'source'
added to it but I decided upon including the word 'source'. Another
question has occurred to me is whether or not 'original source code'
should instead be 'original entry source code' but that can be decided
upon later as that occurred to me after much of the files were already
rebuilt. The consistency that this commit has made is for the README.md
sections and in particular 'Alternate code'. One might wonder if that
should be changed to 'Alternate source code' as now the manifest
includes 'source' in the 'entry code' and 'original code' but the
manifest itself is what was actually updated and having 'source' feels
more natural for submitted files. After all not all entries have
alternate code. These questions can be decided on when looking at the
index.html files that have been rebuilt.
Changed 'alt code' to 'alternate code' where this was not already done
(in the manifest). It is questionable whether this should be done in
markdown files or not (in the README.md files section it already is done
but not necessarily in other places).
Many files had incorrect descriptions that have been checked.
Renamed 2020/endoh2/spoiler/spoiler.{md,html} to index.{md,html} so one
can go to just 2020/endoh2/spoiler and see the web page. Although the
manifest of 2 020/endoh2/index.html will link to it and that's probably
how most people will notice it it seems useful especially as the web
page links to the different files in spoiler/ or at least refers to
them, giving a description (kind of like the manifest in
2020/endoh2/index.html).
Due to the above changes all the entries had their index.html files
regenerated too.
There were likely other changes and fixes as well.
What has NOT been done is a check over all items, typos or otherwise,
though some typos have been fixed. Nonetheless this commit goes a long
way to resolving issue #1933.
Updated thanks file both with a missing <div> id and added a manifest
improvements section as the manifest is quite important.
We make better use of the rel HTML attribute.
We format the inc/footer.default.html so that it is a
slightly easier to read.
Ran `make www` to perform test the above under macOS.
In other words rather than have the link name in the form of:
1984 decot bugs
it is now:
1984/decot in bugs.html
so that it matches how the entry itself looks (as in how it's
identified) and to say where (what file) it is (in). The reason it says
'in bugs.html' rather than 'bugs' (saying that the entry has bugs) is
because not all are bugs and it's saying where to see it anyway. But
some are features, others are missing links or files or other things
like that and to keep the same form it now says 'in bugs.html'.
This was done with my sgit(1) tool like:
sgit -e 's,\([0-9][0-9][0-9][0-9]\) \([-a-z\.0-9]*\) bugs,\1/\2 in bugs.html,g' '*/*md'
The link to bugs.html itself has the path '../../bugs.html'. This is
important as it's meant to be rendered in the browser. At first this was
not remembered and I did something like:
sgit -e 's,\[\([0-9][0-9][0-9][0-9]\) \([-a-z\.0-9]*\) bugs\](../../bugs.html,\[\1/\2 in bugs.html\](%%REPO_URL%%/bugs.html,g' '*/*md'
but this was changed to the simpler one due to the problem described
above. It's worth putting this note here as a reminder, though, so I
have included it here.
Landon Curt Noll