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.
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.
It was actually declared it was a bug (the entry no longer did the
invalid input check that it once did) and I fixed it so it no longer
needs to be documented at all.
Now the game will re-prompt the player if invalid input is entered both
for the level and for the move. The way it was fixed is described in the
thanks-for-fixes.md file but here is a summary of the previous problem
and the fix.
If one entered an invalid level it proceeded to prompt for the move.
Thus if one entered '.' or anything other than a number it would still
move on. As for the move if one entered invalid input it would prompt
again but in an infinite loop, not letting one enter anything and
instead flooding the screen. The format specifier was thus a '%d'. Now
it's a '%2s' on a 'char A[100]'. After the scanf() it uses atoi(). For
the level it checks if > 10 || < 0 || !isdigit(*A) and if the if is 1 it
goes back to prompting the level. Of course since '-' is not a digit the
check for < 0 is superfluous but I did it anyway. Now prior to prompting
the level it zeroes out 'A' (*A='\0'). For the movement the do..while
loop condition checks for invalid input but it needed a scanf() with
"%2s" also and then use atoi() on the string (A). But in that case there
was no need to zero out the string (might not even be in the other but I
did it anyway).
Now as far as the level goes I checked for > 10 only because later in
the code it checks for < 10 and if so it increments it by 2 so I presume
that it's invalid if it's >10. This might or might not be correct but I
do not know the rules of the game and neither do I know the author's
intentions.
One more important point is that it does seem to stop playing the game,
making the same move again and again, but this might be another problem
or maybe it's a draw or something else. As I said I don't know how to
play the game so I can't verify it either way.
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.
With the compilation fix of the code some symmetry was unfortunately
destroyed. To try and keep it as close as possible to the original I had
just commented out the code. But looking at it again today it occurred
to me that I can make it look more symmetrical by removing the commented
out code and then formatting the code a bit differently (another cast
was removed to do this). It is not any less authentic but it now has
more symmetry which was an important part of the entry's layout.
Although this is very unlikely(?) nowadays the judges noted that
putchar() has to exist and if compilation fails one should include
stdio.h. This cannot be done in the file, however, as it would ruin the
symmetry (already some of this was messed up due to C standard changes).
Restored the #define D define even though it can't be used with modern
compilers, just so it looks as close to the original as possible. This
goes for both versions, the one with the board and the entry (limited by
the contest restrictions).
As index(3) in some systems requires strings.h and since it's identical
to strchr and since the judges said in System V machines (not that we
should have to worry about those these days) they had to define index to
strchr I have done this in the Makefile.
Also the #define _ define was restored even though it's not used in
order to make it look closer to the original entry. This has to be done
in other files as well, as I think on it.
Format and typo checked README.md.
This was in the 'Try' section but as a ailurophile (cat lover) I have to
say that if one removes a useless use of cat then literally speaking if
there were any cats left then they would be useful. I utterly object,
therefore, that there is no longer a cat here because cats most
certainly are useful. For instance if Earth was flat cats would have
pushed everything off it by now which is proof to those not in the Flat
Earth Society that the Earth is not flat. It's not proof to the Flat
Earthers but that's because they think it's flat regardless when in
reality the only related thing that might be flat is their brain, kind
of like a battery that's gone flat. And that's flat :-) But I digressed;
the point is that there was no need for the cat command here even if
there's always a use for cats. :-)
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'
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 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.
I also updated the todo.md file as I left some things out that have to
be done. I only explicitly named one thing but when I go over them as a
final pass I will address the things in question (some will require
discussion).
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).
(Well .. some warnings. See below.)
Depending on system (compiler and possibly platform) different warnings
were being triggered. It was easy to fix the code for some of them (like
wrong prototypes and then #including stdlib.h) but this caused problems
in another way (in macOS clang - clang is more strict and has -Werror or
else an equivalent by default which might or might not be possible to
disable .. haven't tried it) but since the code works as is I simply
silenced the warnings in the Makefile.
A note that might be useful to know for other Makefiles that has to do
with the fact that macOS gcc equates to clang (which I have noted many
times as it's an unfortunate problem): since it is seen as gcc the
Makefile check for gcc only will be triggered in macOS even though the
compiler is clang.
A similar problem is that if one does in linux just 'make' they might
end up with the compiler being 'cc' so I added an ifeq in the Makefile
for just cc. It might or might not be useful to add this to the rest of
the entry Makefiles. The same warnings disabled for cc and gcc were
added.
Another thing to keep in mind is with gcc/cc in linux it will still show
the warnings that were silenced as in it will show that some warnings
might have been disabled (it won't warn about the problems but will note
that some warnings were disabled - no I can't figure out the real
purpose of it either other than to be extra careful .. or annoying :-) ).
In linux clang also triggers even more warnings including the ridiculous
misleading indentation that they unfortunately adopted from gcc. These
warnings were not disabled at this time.
As far as the README.md goes one of the to run commands was incorrect in
that when running './wall' by itself one should put in numbers only, not
just any text.
This improvement redefines gets() to use fgets() with the correct args
so that the code can refer to gets() to look more like the original
code.
Note that the prototype for gets() that is in the original code cannot
be there because of conflicting types of fgets() and a couple other
errors that arise from redefining gets(). This fix is part of issue #936
which with this commit is more than halfway complete.
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
```
Landon Curt Noll