Based on a slight modification to the Makefile the program will now
compile to the same file as if dds.c was being used (a.out).
I updated the README.md with some changes in formatting to do with the
alt code but the file has not been fully corrected or even checked.
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.
It seems like if I'm going to add a demo script it might be a good idea
to have a comment briefly explaining what the script does but in such a
way that does not spoil the entry.
The demo.sh script now shows a bit more what is going on, at least in so
far as the text can go either way: instead of showing:
Green terra: Terra green
Vex: Irk
[...]
The rug gary lenT: Gur eht tnel yraG
it shows:
Green terra <-> Terra green
Vex <-> Irk
[...]
The rug gary lenT <-> Gur eht tnel yraG
The Makefile now silences as many warnings as possible.
With clever use of the Makefile and removing a cast that is not strictly
necessary (it does trigger a warning but it still produces correct
output) I was able to get what was once 80 characters but when fixed
increased to 106 characters all the way back down to 85. As for how this
was done it might be helpful to look at what it was prior to this update
as well as the original. The previous version was:
int main(int a, char **b){while((a=getchar())+1)putchar((b=64^a&223)&&(int)b<27?a&96|((int)b+12)%26+1:a);
and the original was:
main(a,b){while((a=getchar())+1)putchar((b=64^a&223)&&b<27?a&96|(b+12)%26+1:a);}
The problem with the original besides needing one of the casts is that
clang is stricter with the types of args of main(). Now it looks like:
main(a,b){while((a=getchar())+1)putchar((b=64^a&223)&&b<27?a&96|((int)b+12)%26+1:a);}
which is almost the same as the original. But how was this done? The
Makefile does:
-D'main(a,b)'='int main(a,b)char**b;'
which lets the main() part be the same as the original but still compile
with clang.
I also added the script demo.sh which simplifies running the command I
had added (or more likely extended) but it also shows it line by line so
you can see how the text is rotated. One of my favourites of the lot is
from Brian Westley and that is one I added.
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).
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
```
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).
There were several fixes that needed to be made. Some were done and in
the process I discovered some fixed entries that really should be an
alternate version. That was not yet done but I have kept track of some
and will find the others - another time.
As there are more important things to do (like the jprint tool in the
mkiocccentry repo) and since I need a break I have decided to make a
pull request with the changes made.
Some README.md files had to be updated for this commit as well.
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.
Well 'first target' :-) but git commit likes to have no more than 50
columns for the summary.
The problem: if one did for instance
make CC=clang clobber all
they would get something like:
Makefile:89: *** recipe commences before first target. Stop.
because of a missing \ at the end of a line in the middle of setting (or
appending to) CSILENCE.
The clang issue does have an alternate version which I made a while back
but I added a note earlier in the file that most likely it'll be needed
for clang - depends on the default CFLAGS possibly but for macOS at
least it does not work. I never tested linux but I probably should.
This is to prevent annoying warnings about gets() - as changing this one
to use fgets() would be very complicated. This can be done for other
entries that use gets() that are either complicated to change or it's
decided to not change them. It won't prevent linker warnings (like with
gcc) but it'll prevent runtime warnings that often get interspersed with
the output of the program sometimes in confusing ways.
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.
The question to ponder is what happens with files that are not BASIC
programs.
I also fixed some typos and made things (I hope) a bit clearer in the
alternate code section.
I noticed that I unfortunately fixed two segfaults that should not have
been fixed: if the input file cannot be opened for reading or the output
file cannot be opened for writing this program will crash. Changed both
dds.c and dds.alt.c (which I added to work with clang). The original fix
that allows this entry to work at all (segfaulted always) remains in
both versions.
Updated README.md and bugs.md. In bugs.md I also added a note that the
compiled code uses gets() not fgets() - whatever it might be worth.
Yes it's very easy to cheat at the game but as my late grandmother told
me when I was a kid: 'it's not cheating if you're not caught' and since
the computer does not catch you any more than her siblings did at the
card table with her hidden drawer with more cards it's not cheating! :-)
But on a more serious note it was documented as a possibility so it's
not a bug it's a feature so I added it to the README.md and bugs.md.
Make it so that the warnings/errors (i.e. stderr) of the compilation (as
well as the echo saying it's going to compile) not show unless -e is
used. This is because the warnings kind of ruin the experience.
Updated README.md to explain this.
The problem was that the read only char*z[] was being written to. This
caused a crash which prevented the delightful program from working. The
fix was to change it to 'char z[][100]'. But why not a smaller number
when the longest string is < 100? Because a smaller number caused
strange output and it was easier to do than find the right value: 100 is
that big and it works well so why bother finding the smallest value? No
other reason behind it.
Fixed the shell script too so that it actually works okay (related to
'.' not being in the path in modern systems).
Updated README.md: moved the ttt.sh related things to new try section
and gave an example run (a losing example, challenging users to cause a
draw or better yet win as well as asking them to test something about
the game).
Added a fun parody to the README.md too. Check it out!
Removed this entry from bugs.md.
This text actually is from Merlyn LeRoy (who is none other than
Brian Westley) on usenet rec.puzzles in a post on 22 August 1992 and of
course I linked to his winning entries and the usenet post!
Cody Boone Ferguson