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.
This is to make them consistent with the others called try.sh which
seems better named as it's under the try section.
The manifest files in tmp/ have been updated as well, including the
macOS Numbers file.
I ended up not doing a git pull in the system with the problem (of
implicit ints being an error) and so the Makefile used was the old one
prior to the change in diff rules. This commit restores them and the
silencing of implicit int warnings.
In linux clang does not support implicit int and it's an error. I ended
up adding 'int' but to make it more like the original I added to the
CSILENCE -Wno-implicit-int instead. Thus the code is the original and
only the Makefile is different.
The thanks file was updated for this but also other entries (nothing
changed in the entries themselves, just changes in the description in
the thanks 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.
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.
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'
When trying to get this entry to work for modern systems I ended up
replacing some macros with what they translated to. This meant that it
did not look as close to what the original entry looked like.
There was another change as well in this commit. The variable that is
the file to open was changed to a FILE * instead of an int. Although it
did not crash after the change I made when trying to open the file (see
below for why this was done) it's not strictly correct either in modern
systems (and maybe not in older systems either though it clearly
worked).
Now as for why the fix to being able to open the file: it's because at
the time I was trying to get it to work with modern systems even though
the author stated that it was designed for i386 linux. Doing this proved
possible with a number of other entries but in order for it to even get to
that point this change was necessary. According to Yusuke Endoh, it did
work with an emulator so that was not strictly necessary but I did not
know this at the time and it seems better that at least it can open the
file even if it won't completely work due to the way it is designed. It
seems better too as it might help provide a way to get a version for
64-bit systems.
The thanks-for-fixes.md and bugs.md files were updated on account of
these changes. The bugs.md file also includes why it was changed when
the entry is designed for i386 linux: besides the fact that I fixed the
supplementary program that did not work at all. It seems that, according
to Yusuke, that both works in an emulator but this way at least one can
enjoy the supplementary program in modern systems too and the entry
itself is a bit more correct.
The bug status of this entry changed as well. It now has both INABIAF
but also asking for alternate code. Why this is is explained in the
file: it does indeed seem to not make sense but the rationale is
explained there.
The alt target list now includes the supplementary program I added.
There were some problems fixed in the README.md file that occurred when
the (far superior) thanks-for-fixes.md file was introduced.
The thanks file was updated as well.
That is
sgit -e 's/Use make\( to compile\)/Use `make`\1/g' -e \
's/makefile/Makefile/g' '20[0-9][0-9]/README.md'
This way 'make' is formatted with a code block (or whatever the term is
in markdown terminology) and 'makefile' is changed to Makefile.
BTW: fun fact: Landon was part of the recommendation of naming Makefiles
Makefile instead of makefile which is shown in the man page make(1):
Normally you should call your makefile either makefile or Makefile.
(We recommend Makefile because it appears prominently near the
beginning of a directory listing, right near other important files
such as README.) The first name checked, GNUmakefile, is not
recommended for most makefiles. You should use this name if you
have a makefile that is specific to GNU Make, and will not be
understood by other versions of make. If makefile is '-', the
standard input is read.
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 change was already applied in the README.md files of the years <
2000, yesterday, but I got tired of doing it manually as I do each year
so I used my sgit tool (https://github.com/xexyl/sgit) like:
sgit -e 's/\(Look at the README.md file for the given\) winner/\1 winning entry/g' -e \
's/\(on how to compile\) the winner/\1 it/g' .
which changed the text:
... for the given winner
and
on how to compile the winner
to
... for the winning entry
and
... on how to compile it
This felt useful because the winner is not the entry itself but the
author (and in some cases authors). This should be clearer now. When I
do a final pass I will check for any consistency issues in the ones
changed manually.
In this commit the year 2013/README.md was format fixed as the change
was done in this file, manually, yesterday, when I did format fixes but
which was not committed as I wanted to do it with the years 2000+.
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).
Fixed supplementary program to add a newline after printing the first
line: else the output of both lines were merged and hard to read.
Updated Makefile to always compile the supplementary program.
Modified thanks-for-fixes.md wrt this entry including fixing the link to
the supplementary program (it did not specify the directory: it just had
the file name itself).
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.
C99 does not support implicit int. There are three ways I can think of
that would solve this problem but I chose to add the 'int' to the
parameters to prevent any problems in the future.
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
```
The script herrmann1.sh invoked the program itself which is not needed
and would in fact invoke it during compilation as the script is what
compiles the program. The program is to be invoked via the script
itself but the script also compiles the program as well.
Fixed the script for shellcheck.
Note that there still is a problem in that with older gcc versions it's
supposed to animate on compilation but this no longer works. See the
bugs.md for details.
At least one entry was missing (1984/anonymous).
Some entries were removed. One such entry was not ever broken but
instead when I had renamed a file (to markdown) I forgot to update the
DATA variable in the Makefile which then broke compilation. This was
seen in the log and mistakenly believed that there was something wrong
with the entry when there wasn't. Other entries removed were not fixes
but notes.
Various README.md files have been updated for this sometimes just
formatting merely because I opened the file because for instance there
is an alternate version (many by me) that is referred to. I'd not be
surprised if more README.md files have to be updated for this much
better system but these will be found in time when I do another pass
(and some years I have not checked at all yet).
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.
The is a file excluded from this commit that has had the change because
there are other changes but the file is incomplete. That file will be
committed when the fixes are complete which will happen at a later date.
Since arrow keys can be more natural than other keys like the program's
',' and '.' for movement I added a version which lets you use arrow keys
instead. One player could use the ',' and the other '.' or both can play
with the same, whichever they pick.
I also slowed down the speed of the ball as it moved very fast
considering the slow speed the paddle moves. The README.md shows how to
reset it or change the value via make.
Updated .gitignore.
Added herrmann2.alt.c. This is for a new try command to show a feature
of the entry. It can generate the original code so the try command does
this, redirecting stdout to a file (herrmann2.orig.c) and then does a
diff on the two files, to show how they're the same.
The make alt rule was fixed so it doesn't compile with herrmann2.c but
rather herrmann2.alt.c though I'm not even sure why that was defined at
all except to say that it must have been something I forgot to change
after fixing it properly.
Updated .gitignore to add herrmann2.orig.c.
Further format fixes in README.md.
This sings a different counting song, Ten in the Bed. It uses another C
feature (a char *[]) that the Ten Green Bottles does not use. This is
for fun as well as to show another program (with a different C feature)
that the program works on, again assuming -m32 is allowed.
Instead of using numbers it uses strings (as expected with a char *[])
in the singing.
This was for fun (and to see if the program would work on arrays) after
I remembered the song in a comment on GitHub - about the Ten Green
Bottles song.
Running make alt will compile the anonymous.ten.c without specifying
-m32: whether it'll end up being 64-bit or not would depend on the
system but it'll be saved as anonymous.ten.64 anyway.
The try.me.sh script will run this program directly, skipping the entry
itself, if the anonymous.ten.c cannot be compiled as a 32-bit binary.
Updated .gitignore.
Added a couple git diff commands to try and moved the INABIAF and the
warning from the author to below the judges' comments as already most
people probably will want to skip past long before to the next section.
Perhaps the fix should be moved to under the judges' comments as well
but I don't know.
There is one exception that I'm aware of and that is the U macro (U is
referenced only in strings) and this is because it segfaulted and it was
a minor change so didn't seem worth investigating further, at least for
now (if not for ever).
This feels like a new pull request is appropriate here so although it's
technically the same idea of the previous pull request this is what
should be the final revision (again unless I figure out why U
segfaulted).
Cody Boone Ferguson