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.
The manifest was updated for 1994/tvr. Rebuilt .entry.json and
index.html.
Bug status changed in 1994/tvr as well. The judges noted that it has an
incorrect result in some cases but the author actually noted this as a
feature so it should not be fixed. Other fixes/updates were made in the
bugs file as well.
A number of other entries of 1994 had minor fixes (formatting, links and
similar things).
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.
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.
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.
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).
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.
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.
We added a space between the markdown triple code mark
and language that was enclosed in HTML comments.
So a line of the form:
````
```<!---c--->
````
became:
````
``` <!---c--->
````
This was done to **help** some code see that the HTML comment
string was not a markdown code specifier. Not all code
understands this after this changed. For example, `pandoc(1)`
still forms HTML classes of the form "<!---c-->"
when it encounters the above mentioned change.
We also fixed a problem with `2019/dogon/README.md` regarding
a markdown code block.
We also fixed a problem with `2020/yang/README.md` regarding
a markdown code block.
When language is specified in a markdown code block such as:
````
```c
printf("Hello, world!\n");
```
````
is used, the resulting HTML as produced by `pandoc(1)` combined
with our revised `ioccc.css` is not intent the code block well.
A temporary "_hack-a-round_" is to turn the "markdown code language
specifier" into an HTML comment. For example:
````
```<!---c-->
printf("Hello, world!\n");
```
````
This commits turns off existing markdown code language specifiers
for now, while preserving our ability to restore them in the future
when a better "_hack-a-round_" to the "markdown code language
specifier" problem is found.
The HTML impact if this "_hack-a-round_" is to produce HTML that
looks like this:
```
<pre class="<!---c-->"><code> .. </code></pre>
```
We might be able to create a complex set of classes for each markdown
code language (there won't be very many) in `ioccc.css`, or we might
find a more general CSS (or maybe `pandoc(1)`?) solution.
For now, this hack-a-round will have to do.
All code blocks in markdown have been intended by at least 4 spaces.
We add `--tab-stop=8` to all `pandoc(1)` executions in order to set
a better tab stop indentation, especially for tab intended code blocks.
Changed `bin/pandoc-wrapper.sh` VERSION from "1.5.3 2024-03-26"
to "1.6 2024-03-31".
Fixed `1991/brnstnd/sorta.README.md` so that the sorta code
is code blocks.
Removed unneeded paragraph group in copyright in `inc/footer.default.html`.
Fixed excess whitespace after list Author on entry `index.html` page.
Changed `bin/output-index-author.sh` VERSION from "1.5.2 2024-03-26"
to "1.6 2024-03-31".
Performed `make www` to perform the above and test under macOS.
TODO: Fix the problem of the initial line of code being extra intended.
TODO: Fix excess whitespace around code that is inline.
The inc/footer.default.html now has a common Copyright and CC BY-SA
4.0 License section for all generated HTML files.
All markdown files have a similar Copyright and CC
at the bottom in the form of an HTML comment.
Entry source is now prog.c for IOCCC years 2014 thru 2020,
or is now dirname.c IOCCC years 1984 thru 2013.
To achieve this state, we renamed the following:
renamed: 2004/hibachi/src/hibachi.c -> 2004/hibachi/hibachi.c
renamed: 2012/omoikane/nyaruko.alt.c -> 2012/omoikane/omoikane.alt.c
renamed: 2012/omoikane/nyaruko.alt2.c -> 2012/omoikane/omoikane.alt2.c
renamed: 2012/omoikane/nyaruko.c -> 2012/omoikane/omoikane.c
renamed: 2012/omoikane/nyaruko.orig.c -> 2012/omoikane/omoikane.orig.c
Modified `bin/subst.entry-index.sh` to add to entry `index.html` file,
links to the `Makefile` and the _C code_ to the top navigation bar.
Changed `bin/subst.entry-index.sh` VERSION from "1.2.2 2024-02-25"
to "1.3 2024-03-02".
Moved printing the Inventory link in the top navigation bar
from `bin/subst.entry-navbar.awk` to `bin/subst.entry-index.sh`.
Changed `bin/subst.entry-navbar.awk` VERSION from "1.0.1 2024-02-23"
to "1.1 2024-03-02".
Moved printing the Inventory link in the top navigation bar
from `bin/subst.year-navbar.awk` to `bin/subst.year-index.sh`.
Changed `bin/subst.year-index.sh` VERSION from "1.0 2024-02-11"
to "1.1 2024-03-02".
Changed `bin/subst.year-navbar.awk` VERSION from "1.0 2024-02-11"
to "1.1 2024-03-02".
Added location names (both default and common) to `author.html`.
Changed `tmp/gen_author_json.sh` VERSION from "1.0 2023-06-06"
to "1.1 2024-03-04".
Added location names (both default and common) to `author.html`.
Changed `bin/gen-authors.sh` VERSION from "1.2 2024-03-09"
to "1.3 2024-03-04".
The manifest and the resulting `.entry.json` files have been changed
for `2004/hibachi` and `2012/omoikane`.
The Makefiles for `2004/hibachi` and `2012/omoikane` copy the
source file into the "previously used location". The `make clobber`
rule removes the copied source. The `.gitignore` files have been
updated accordingly.
Improved how the concept of IOCCC terms _entry_, _author_ and _submission_ are
used in markdown files.
Links to markdown files (files ending in .md) within the repo were
changed to link to HTML files (files ending in .html). Special cases
where `README.md` became `index.html` were modified accordingly.
Fixed URL for `bugs.html` in Makefile comments.
Fixed name of `bin/sgi.sh` referenced in comments in `.gitignore` files.
Links to locations within the repo are now relative. For example a
link to `/contact.html` may become `../contact.html' or '../../contact.html`
depending on the directory level of the markdown file.
Nearly all links with absolute URLs under _https://www.ioccc.org_
or `https://ioccc-src.github.io/temp-test-ioccc_ have been changed to
relative paths within the repo. Some exceptions to this (such as
referring to a GitHub repo) were preserved.
Fixed a number of inside `faq.md` and `bugs.md`.
Added HTML name tags (in the form of an _entry_id_) for each entry
referenced in `bugs.md`. Fixed links from outside of `bugs.html`
into `bugs.html` accordingly.
Where FAQ entries are referenced, a named tag is used so that if a
FAQ is ever renumbered, links outside of `faq.html` will still work.
Changed the _inventory_order_ of a compressed tarball from _300_
to _100000_. While this may have been done for the manifest,
this changed had not yet been propagated into the `.entry.json` files.
Links to web sites that were in the for <URL> are now [URL](URL).
Performed `name www` to process all of the above.
Improved format of `authors.html`. Full names are now bold.
Location codes are now links back into `location.html` and
location names (both default and common) are now italics.
Added _author_handle_ each author.
Changed `bin/gen-authors.sh` VERSION from "1.1 2024-02-25"
to "1.2 2024-03-09".
Improved format of `location.html` as location codes are now bold,
author counts in a given location are now bold, and location names
(both default and common) are now italics.
Changed `bin/gen-location.sh` VERSION from "1.0.1 2024-02-23"
to "1.1 2024-03-04".
Added italic location name after location code in entry
`index.html` files.
Changed `bin/output-index-author.sh` VERSION from "1.4.1 2024-02-23"
to "1.5 2024-03-04".
Added _Location of authors_ to the sidebar as a link to `location.html`.
TODO: While nearly all of the above mentioned changes are likely correct,
they likely introduced a few errors that need correcting.
As requested on GitHub: a tool that will be written, readme2index, will,
as explained:
'... will take the converted HTML from the README.md markdown and
inject it into an HTML template. Things such title, award one and
author information will be injected into the HTML page ahead of the
HTML that was converted from the README.md markdown. Without going
into details of HOW at this time, the result will be a coherent HTML
index.html page with the winner title / award, winning author
information, and important file links come from other sources and
NOT from the README.md file.
The text from the 1st award line, thru the authorship information,
and up to but not including the "## To build:" line in the README.md
file will just get in the way. Moreover authors might be tempted to
try and maintain that top of README.md text instead of working with
the author/_author_handle_.json and winner .winner.json files.
This was done with my[0] sgit(1) (https://github.com/xexyl/sgit) tool like:
sgit -o -n -e '/^## To build:/,$p' '[12][0-9][0-9][0-9]/*/README.md'
[0] Is that shameless self-promotion? I don't know but I don't care: it
is generally a very useful tool and has been used in other repos too.
Besides, I've done it many times before and it's a great example that I
will be adding to the README.md file of the tool, one I hadn't thought
of doing.
Fixed cases where there was a bad trailing backslash.
Improved a few cases where a code block was needed
to highlight some text.
Changed a few cases where a code block needed to
declared as, say, a sh code block.
Fixed a few cases where the winner information was not properly formatted.
Plus a few nits and clarifying text was added.
The first version uses fgets(3). This version will compile (note that it
does not compile right away: one has to make other adjustments; it is
not a matter of just changing the code to use fgets()!) but when fed its
own source code it will not generate code that can be compiled let alone
use fgets(3).
The second version, schnitzi.alt2.c, has an increased buffer size but it
will not generate code with the same buffer size; rather the size will
be the original. I explain this in detail (did this quite some time
back) in the bugs.md file. I noticed today that the author gives quite
some details too which will be something I can look at later on. Right
now it's more important to get the website in order so that the next
contest can run! I will only look at this later on or else at a time
where I am unable to do the more important work but am able to do this
(though I don't know about that happening it is still something that
theoretically could happen).
The alt code already existed but it was changed to the second version as
the goal is to get it to use fgets(3) regardless of the buffer size.
Note that the other functionality of both alt versions is not affected.
More updates to bugs.md for this and the thanks file has had the entry
added to it (which should have been done earlier on but was neglected
due to the way it came about, the alt code).
The entries referenced in `bugs.md` now have, below the
"To build:" section, a "Bugs and (Mis)features section text"
that matches the `bugs.md` status.
Several entries had their "STATUS" changed from:
"STATUS: INABIAF - please **DO NOT** fix" to:
"STATUS: known bug - please help us fix":
This was done because, while some of the bugs were minor,
inviting someone to try and fix the issue does nil harm.
In a few cases a more difficult bug was also changed to
the "please help us fix".
While we do NOT want to waste time fixing such entries NOW,
letting others become involved and to try to fix the entry
is a good thing as to encourages people to study the entry
and try to fix the entry. We don't need to accept a fix
that is offered, and of the fix transforms the source in
a less than desirable way, such a fix (if accepted) could
be become a alt source code.
Change level 3 (###) to level 2 (##):
sgit -e 's/^### \(Alternate code\)/## \1/g' '*README.md'
which is the same as:
sgit -e 's/^### Alternate code/## Alternate code/g' '*README.md'
This is per discussion in GitHub.
As in:
sgit -e 's/# To run/# To use/g' '*README.md'
This makes consistent the message for how to use the program. 'How to
use' was chosen because one can run a program just by doing './foo' but
that doesn't imply that's how to use it but the purpose of the section
is how to use it.
The use of the markdown trailing whitespace to indicate
line break should NOT be done when the following line is empty.
This removes such improper use of whitespace in README.md files.
The fix thank you's have been moved from `README.md` to
`thanks-for-fixes.md`.
**WARNING**: Some mistakes may have been made in doing this.
We presume later changes by others will correct any issues.
The `CONTRIBUTING.md` was renamed `how-to-enter.md`.
A 3rd line of links was added to top level html such as
`contact.html`, `index.html`, `judges.html`, `winners.html`,
and `years.html`.
Improved blank line use in a number (but not all) `README.md` files.
This to make the country code consistent with mkiocccentry (and I guess
international standard country codes).
This affects many README.md files and (for one line) winners.csv.
As noted in commit 3958bbdb04:
Updated URL for author as it has changed. It's very little on his
page and the only page that suggests it is his is the ioccc.html
page. I couldn't find anything else.
As part of redefining INABIAF the entry now has an equivalent
functionality with the generated output. The bugs.md file still has
hints on how to get this to use fgets() (for why this is helpful see
that file). As a starting point I have the original buffer size increase
in schnitzi.alt.c as it would be useful to see how it works and to maybe
get the entry to use fgets(). Unfortunately keeping it using gets() is a
potential problem but changing it to fgets() is also a potential problem
(this goes for all of the entries that use or used gets()). This entry
however still uses gets(). The change is the smaller buffer size which
means that the entry can not handle big files.
The Makefile and README.md now refer to the small buffer size.
As both Landon and I have been wondering if changing entries to use
fgets() is bordering on tampering with entries I decided to make the
original (sometimes bug fixed) versions (using gets()) alt code. I had
originally started to make the fgets() version of each entry the alt but
since the fgets() versions can handle input better and since some also
fixed bugs (see below) I decided to make the original version the alt
code (this also is how it is for other entries).
There were some exceptions here. If the change also fixed some crashes
or other bugs outside of the gets() to fgets() conversion I did not
bother to make an alt version. An example is 1992/dds. In some cases the
alt code does have bug fixes in which case they were added.
Updated the Makefiles and .gitignore files as well for the alt target
and the new files (compiled and in the case of 1992/adrian additional
source files in the Makefile alt rule).
This should solve the problem observed by Landon and me. It wouldn't be
a problem to change it so the alt version is the one that uses fgets()
but I think that might be the wrong choice.
In some entries I altogether avoided changing to fgets() say if the
author notes it uses gets() (in one case even providing a version that
uses fgets()). In some cases using fgets() introduces a bug so those are
also not changed.
As for 1990/tbr there's a strong reason for not having the fgets()
version being the alt. In macOS in particular (in linux - or maybe gcc,
not sure - it shows a warning at linker time) it will mess up the first
line of output in a potentially confusing way. For instance:
$ ./tbr.alt
$ warning: this program uses gets(), which is unsafe.
# nothing here, what to do?
And that touches on another issue of making the alt version the one that
uses gets(): the warnings that can be alarming during compilation,
linking and (in the case of macOS) runtime.
Not all entries should be or can be changed to fgets() but some can and
it's warranted for these reasons. More will possibly happen in the
future.
Formatting fixes in README.md. Also refer to bugs.md file where I give
hints on the magic of the entry in order that it can hopefully be made
to use fgets() and have an increased buffer size.
Updated bugs.md about this entry with an important point about the
fgets() / buffer size issue: it can very easily be made to use fgets()
and having an increased buffer size. But the program is supposed to be
able to be fed its own source code and generate output that can do the
same thing and is compilable. Changing the code to use fgets() will
cause compiler errors in the generated output. As well even though I
changed the buffer size it is not generated in the output when feeding
the program its own source code.
In the bugs.md file I also pointed out just how sensitive this program
is (by design): a single space in the wrong place or a single character
in the wrong place can break the program; it's very sensitive.
One should be able to do:
./schnitzi < schnitzi.c
and compile the generated output. That new program should be able to do
the same thing as well.
The problem with changing it to use fgets() is feeding the program
itself generates compiler errors and the generated file does not use
fgets() either. This will have to be done another time, maybe. The
buffer size was increased to 10000 and even this required some slight
changes in formatting in order for the generated output to compile okay.
The buffer size generated is still the same as the original but now
larger files can be parsed by the original code and everything compiles
okay again.
An example file that would cause the entry to crash is the Makefile. Now
it won't crash. Strangely without increasing the buffer size but even
using fgets() the Makefile did crash the entry. Changing the buffer size
is not a problem but whether or not some other larger file will cause a
problem or not I do not know. I don't see how it would but I don't see
how this happened either.
There is one exception:
$ find . -name '*.hint' -execdir git mv '{}' README.md \;
git statufatal: destination exists, source=1992/albert/albert.hint, destination=1992/albert/README.md
Looking at the two files they differ quite a bit so I've not changed it.
I'll bring this up on GitHub.
Cody Boone Ferguson