The rake.sh script had a typo where '1>&2' was just '1>2'.
The README.md and spoilers.md files were format and typo checked.
I believe this should complete 2014/endoh1.
The alt code now lets one redefine the coordinates (which was
deliberately not obfuscated by the author for this purpose). A casual
look at the code would make one think it's not an alt code but it's a
fixed version that the author provided if a certain statement was not
true (see README.md file) so the only thing that is different is that
there is the #ifndef..#define..#endif of coordinates and the fix to
compile (missing a return value, possibly also fixed in the README.md
file, and an added #include <stdio.h> for putchar(3)).
The alt code lets one redefine the port and also redefine the timing
constants. The reason for the port is in case of firewall (though on
localhost that shouldn't be a problem but it does appear to be that it
might bind to other addresses too). The timing one the author specifies
some uses for changing it. Uses #ifndef..#endif.
Format/typo check README.md file.
This includes updating the run of iocccsize -i on the README.md file as
the size has changed (it also referred to REMARKS.md but I changed it to
README.md). This is to make things consistent.
The mode where the game would play by itself did not work because the
code had 'sinon.c' in it but this does not exist. Now the code refers to
'prog.c'.
Add try.sh script that is an improvement over the previous try command
(or commands in a sequence) in that it loops, asking if you wish to try
again in case of a jam (or any other reason).
Format/typo check README.md.
This should complete the review of 2014/sinon.
The try.sh allows one to override the default indent(1) and sed(1) tools
and also verifies that they are executable. This means one can use, for
example, bcpp, instead of indent, or if one wants to specify a different
path to sed(1) they can. The README.md file explains this more.
README.md file format/typo checked.
This should complete the review of this entry.
Rather than check if $(CC) IS gcc or IS clang check for $(CC) containing
gcc or clang. This is because in some systems or conditions the compiler
might not be called JUST gcc or JUST clang. For instance gcc in MacPorts
is called gcc-mp-13 (for example) but without this change one would have
to symlink gcc to gcc-mp-13 or copy it to gcc.
The FAQ has been updated to address this.
Due to GitHub not serving nor rendering HTML files whose filename
starts with "." (dot), we renamed `.inventory.html` to `inventory.html`.
Renamed: `tmp/gen_dot_winner.sh` -> `tmp/gen_winner_json.sh`
Fixed URL generation for GitHub links in `inventory.html`.
The manifest was updated accordingly.
The `tmp/README.md` file was updated accordingly.
Fixed an incorrect author win for "1989_jar.2" in `author_wins.numbers`
and `author_wins.csv`.
Changed winner_JSON_format_version to "0.5 2023-11-04".
Added `gen_dot_winner.sh` tool to generate .winner.json and .inventory.html
for a winner. This tool uses [pandoc](https://pandoc.org) to convert
markdown to HTML.
Used this command to generate `.winner.json` and `.inventory.html` for
all winners:
```sh
./run_all.sh -v 1 -D 1 ./gen_dot_winner.sh
```
Updated `tmp/README.md` to reflect the above.
Retired "fake.gen_inventory.sh" to `tmp/OLD_manifest/fake.gen_inventory.sh`.
Added `-D level` flag to `run_all.sh` to specify the `-v level` for
the tool that is being run.
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 `.id` files are no longer needed and so they were removed.
The `winner_id` (the contents of the `.id` files) are simply
a concatenation of "year" and "_" and "dir".
Adjusted `.inventory.html`, `tmp/README.md`,
`tmp/fake.gen_inventory.sh`, and the manifest according
to the above.
The new tool, tmp/fake.gen_inventory.sh, now adds
a fake .inventory.html file to each winner entry.
Once the winner2nventory tool is written, the .inventory.html
will contain links to all winner files listed in the inventory.
For now, the tmp/fake.gen_inventory.sh tool just creates
a placeholder file.
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.
We now have 6 diff rules:
diff_orig_prog
diff_prog_orig
diff_alt_prog
diff_prog_alt
diff_orig_alt
diff_alt_orig
The FAQ for these diffs needs to be updated
as we have 6 types of diffs now.
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.
When I got this entry to work apparently I never added a thanks for it
so this is now done.
Also to make the compilation more portable I added -ldl to the LDFLAGS.
This is something Yusuke Endoh did and although not necessary in the
systems I tried it since it uses dlsym() it's better to have it.
There was a comment in the form of:
... the liked/allowed ...
which should instead be:
... liked/allowed ...
and this was fixed with my sgit tool like:
sgit -e 's,the \(liked/allowed or compile\),\1,g' '*Makefile'
Add make rake and rake.sh script that runs the rake command and then
runs prog (if all okay). If rake is not installed it reports this and
checks that gem is installed (as gem installs rake) and if gem is not
installed it reports that and tells one how to get it and what to run
after that. If rake is not installed and gem is it tells the user what
to do as well. After this it tells the user to run the rule or rake.sh
again. If rake is installed but it fails to work it suggests to install
a specific gem (that the author noted in the spoilers file) and then
trying again. An important note on the check for gem is it does not tell
one how to install it but rather use it so if it's run again and for
some reason rake is not installed then it will report the same issue
again. The reason it is done this way is because the ruby file the
README.md file suggests to be executed has an error in it, at least in
macOS. This script should in any event simplify the usage of the entry.
The read_me.md file was renamed to spoilers.md to be clearer in purpose:
it contains spoilers and just having it be read_me.md is not clear.
Updated the todo: now entries up through all of 2013 and up through
2014/endoh1 have had the first pass of the README.md files: the format
fixes. These files will have to be typo checked next. Also
YYYY/README.md files have been checked through 2001 with the caveat that
some changes have to be done with them namely to do with email addresses
(and UUCP addresses) that no longer exist. These things are now noted
and it's noted that format fixes is a prerequisite of typo checks.
The README.md file has been format fixed.
The alt code is what the author provided but fixed to compile (a value
was left off the 'return' in the code). This was added as alt code for
fun and to help one appreciate the obfuscation all the more.
The Makefile does allow one to build it by running 'make alt' but it is
not explained how to configure it like the original was (explained by
the author). This is left as an exercise to the readers.
With the make indent rule there was a typo for indent as 'intent'. This
was fixed with my sgit tool like:
sgit -e 's/no intent\( tool found\)/no indent\1/g' '*Makefile'
This is based on the author's remarks and it theoretically will work
with Microsoft Windows compilers (assuming that anything works with
Windows, of course :-) ). It's not been tested because I'm blessed
enough to not have a way to test it but it should be fine unless
something has changed since 2014.
As I was updating the thanks file I made a simple clarification for
another entry as well but it has no relation to this commit - it's just
in the way because I saw it and wanted to fix it and since it's not
anything other than slight rewording I don't see that it needs a
separate commit.
This is not only to help with formatting - especially important in
markdown files - but it's no longer really necessary to do it. One
might not feel the need to do it in non-markdown files but I did it
anyway to be consistent. Thus instead of showing Un*x/UN*X it shows
Unix/UNIX.
A question of whether or not it should all be the same case is another
thing entirely but if this is desired at some point it should be easy to
do anyway - with some care in case it's in formatted text.
A note about the glob: why '.' when there are C files and other file
types where it could be dangerous to modify? Because I did a git grep
first so I knew that it was safe.
This is a HUGE commit:
417 files changed, 874 insertions(+), 874 deletions(-)
As the IOCCC website now is https enabled I have updated the
'http://www.ioccc' to 'https://www.ioccc'.
There was also a typo in Makefiles where it said 'for VERY WELCOME' when
it should be 'are VERY WELCOME'.
Finally slashdot.org is also https enabled so references to
'http://slashdot' were changed to 'https://slashdot'.
This was done by my sgit tool (see https://github.com/xexyl/sgit)
like:
sgit -e 's,http://www.ioccc,https://www.ioccc,g' -e 's/for VERY WELCOME/are VERY WELCOME/g' -e .
but because I didn't have a list of files that should be modified I had
to be careful which files to commit as I had files that were changed but
not ready to be committed. Since I did it in steps, finding typos as I
went along, I actually ran sgit three times but to simplify the above
(and to show that it's possible to do more than one sed command) I made
it all as one. Since I did not have a list of files ahead of time I had
to determine what files to commit, first going through them like:
for j in $(for i in $(git status|grep modified|cut -d: -f2); do \
git grep 'https://www.ioccc' "$i"; done|cut -d: -f1|sort|uniq); \
do git diff "$j"; done|less -r
(I had to pipe through less because of a strange problem with the git
diff which appears to be because of a terminal problem maybe due to the
command above but it was all I could come up with in a very tired head.)
The above and
git status | grep modified:
showed that some C files had been modified which obviously should not be
done so I had to do:
git co '*c'
to undo those changes.
Finally to commit the correct files I did:
for i in $(git status|grep modified|cut -d: -f2); do \
git grep -E 'https://www.ioccc|https://slashdot|are VERY WELCOME' "$i"; \
done |cut -d: -f1|sort|uniq|xargs git commit -v
or so (with any formatting issues or typos here due to typos in the log
due to the terminal (in)sanity issue described).
This is to make it more standard which further allows one to run make on
some other source code, say because they want to try and fix an entry
but forget to update the Makefile. Or if they're the author they can not
worry about it in some cases. But since LDFLAGS is the standard way it
seems better to have the LIBS variable in the Makefile be LDFLAGS.
Maybe there is a reason to not have this and I'm happy to close this in
that case but it does seem better this way so I'm doing this commit.
As besides the entries that are not supposed to compile/cannot compile
due to architectural limitations all the entries can compile in macOS
(though some do not work - yet(? I have plans to work on more later)) it
was not necessary to not silence the warnings after all as the entries
that don't work will be easy to identify ('they don't work' :-) ) so I
can just do make CSILENCE= all in the directory of those entries which
solves the problem I had originally thought of.
Some of the Makefiles have retained other changes I had to make
yesterday to get the entries to work with clang in linux but most of
them were either not changed or were made better with the rollback of
the commit that originally silenced warnings.
Now work on silencing warnings for linux can be done.
Due to the fact we now have .orig.c files and thus the possibility of
winner.orig or prog.orig being built I have updated all the .gitignore
files so that these files ignored. This was done with the following
shell commands, for reference:
for i in $(find 19* 200* 201[0123] -mindepth 2 -maxdepth 2 -name .gitignore) ; do echo $(dirname "$i"|sed -e 's,[0-9]\{4\}/,,g').orig >> "$i"; done
for i in $(find 201[4-9] 2020 -mindepth 2 -maxdepth 2 -name .gitignore) ; do echo prog.orig >> "$i"; done
and the two commands is because it was only in 2014 that the winning
entries were renamed to prog so prog.orig is the correct glob.
Used the following script to check for warnings
not silenced via ${CSILENCE}:
```sh
find ???? -mindepth 1 -maxdepth 1 -type d | while read dir; do
(cd "$dir"; echo =-=-= "$dir" =-=-= ; csilence -v 1 clobber all ; echo ; csilence -v 1 clobber alt)
done 2>&1 | less
```
Cody Boone Ferguson