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'
The inspiration of the script is based on a 'try' command I added to the
README.md a while back to have more fun with the entry. The difference
is that it allows you to specify the number of lines to print (or up to
the number of lines).
There might be some misleading output in a way but this is a mystery for
users to solve.
This commit includes the two entries not already done (other changes
besides a final typo and formatting pass) in 1984, anonymous and laman.
This commit means that the entries of 1984 have each had their README.md
file formatted and typo fixed one more time and this should be good for
publication.
And I forgot to mention in the previous commit that typo changes were
made and additional formatting too. I added some links that seemed
relevant. Due to the historical significance of the entry I had added
quite a few but few entries have this and I likely won't do it for any
additional entries as it takes too much time. Nevertheless to be
consistent with the rest of the file I did this as well.
Earlier on I found the code that the authors used to generate the array.
I fixed it so it would compile but it created unbalanced '}'s (no
opening '{'s) and it instead should be a single '{' and '}' pair like
mullender.c has and which it now does.
To make it look more like the original but to still work with compilers
without -traditional-cpp (which clang does not support) and other
defects with clang (including one that was problematic in linux but not
macOS) code that used macros had to be modified and used directly. But I
removed the macros because of this. Now they are added back even though
they are unused, just to give it a more authentic, original look.
The thanks-for-fixes.md file was updated for this, both formatting and
otherwise, but an unfortunate thing is that another entry was also
modified in there. This is because I was aiming to just do format fixes
in 1984 in one pull request to save time but then I came across this and
decided to fix it and this should be in a single pull request.
Something I noticed is that the fix for linux clang _appears_ to not be
needed at least with clang 16.0.6 but what the difference is is just
extra warnings. I cannot imagine I changed it just for that so I have
left that change in in case there was a problem in earlier versions or
something else I do not recall. It should be noted that without the
change at least with clang 16.0.6 it appears to work just fine. It is
unclear if it should be changed back but again as I can't imagine that I
would have changed it just for warnings I think it's wiser not to.
When Landon initially tried getting it to work he ended up making the
include files in the Makefile (-include ...) to restore it to be a
one-liner but this was actually an error as it was not a one-liner but
rather a best small program; the original code has the #includes in the
source file.
At the same time I made the code itself one-line as it was indeed one
line (the source of the problem, of course).
Now the fixed code (segfaulted with gcc, failed to compile with clang),
both original and alt version (southern hemisphere: based on the
author's remarks but with my fixes applied) that I added, looks more
like the original.
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.
Previously it stated that there were several people who contributed
thousands of changes, fixes and important fixes but this is not strictly
correct as only one, myself, has actually made thousands of changes.
This bothered me because I'm pedantic and by default think literally but
even so it should be correct so now it is, saying that there are a
number of people who have contributed TO several thousand changes and
one who literally (or numerically :-) ) contributed thousands of
changes but I think this improves it too because it's more clear and
after all isn't that the point of the IOCCC? :-)
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'
To be more like the author's remarks I made the judges' remarks EOLs end
with spaces so that it hopefully is not merged. This is because it's in
verse. This matches what the author did as well.
A few links were added where it seemed useful or interesting.
I believe this file is good and need not be checked for typos later but
it's also hard to be sure because the way it is written (verses) some
things are not words and so I probably will go through it one more time.
Nevertheless with this commit the README.md files of the 2013 entries
(well, the entries of 2013, not 2013 entries! :-) ) have been format
checked and fixed.
In the year 2013 the IOCCC did not yet have the source code of winning
entries as prog.c but in the remarks it included prog.c (when showing
warnings) so references to prog.c were changed to morgan1.c.
A link in the judges' remarks was dead and was replaced by a link in the
Internet Wayback Machine.
Format fix the README.md file.
As there are a lot of commands to try I added them in demo.sh, sleeping
approximately 1 second between each command (though I thought of
prompting instead).
And... since the author appears to love cats I'll throw out the word of
us cat lovers: ailurophile(s). And to those who are afraid of cats
(though I don't know why :-) ), the phobia is: ailurophobia.
If you're an ailurophile see https://rationalwiki.org/wiki/Fun:Cat. Even
if you're not you might find it amusing.
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.
The file previously noted several thousand changes that were mentioned
above but this was mentioned at the top of the file so there were no
several thousand changes. There is something like that in the news but
that won't stay there - in time it'll be rotated out - and the context
is missing anyway. Thus I have removed the part about the changes being
above and slightly modified the rest to be clearer of what was done.
To make this slightly more portable still I have removed the hard-coding
of gcc to make it just be cc. In modern systems this should be fine.
This involved updating the magic numbers by subtracting one from each,
making them (in the primary version 43 and 45 and 94 and 96 in the
alternate code for macOS) but since one of the purposes of the fixes of
code include making them work in more systems I have made it use cc as
it should work (gcc is most likely in all systems anyway but it seemed
like a better idea for 2023).
I previously noted in the thanks-for-fixes.md that the mode in fopen()
could remain 44+__FILE__ (though as noted above it's now 43) but that I
had changed it to "r". This was a mistake and it is now restored though
again it is now 43 not 44.
The FILE * which was renamed to G has been changed back to H. Observe
how there is a macro with the same name. There was actually no need to
change it.
I have restored some of the control codes in the C preprocessor
directives. Unfortunately that is only prior to the #define because some
systems will give an annoying warning otherwise. For instance fedora
linux shows:
schweikh1.c:6:8: warning: form feed in preprocessing directive
6 | #define
x
)
==
0
?__LINE__:0){O
=__LINE__;break;}
}
|
and possibly vertical tab too.
So although it would be ideal to have them closer to the original I deem
that preventing warnings that cannot be, for whatever reason, disabled.
The thanks-for-fixes.md was updated for these changes and now includes
more details on the fixes to match the rest of the other entries (though
some might also be lacking in details).
Add note about twitter no longer being used or endorsed by the IOCCC but
noting that despite this the award title should remain the same.
Unrot13 the spoiler as per the request of Landon months ago. Doing this
also allowed for proper syntax highlighting (via the feature of GitHub's
languages of code blocks) as rot13 of C/c is P/p.
Format fix README.md file.
There were a number of problems in the README.md that were fixed. A big
one was in usage where it said you could run the program and then input
a number. Although one could certainly go through that action it would
have no effect. Not entering a number at the command line does something
different (in a way different) from specifying a number.
Also the historical notes were updated to be more consistent and
hopefully clearer than before.
Since the author called the program yarng (see README.md for why this
is) the Makefile now creates a symlink to it, rather than forcing users
to go back and forth as the author gives example uses as well. The to
use and try sections now also use yarng. Running make clobber (from make
clean) will remove the symlink.
The .gitignore file was updated: added yarng.
The thanks-for-fixes.md file was updated slightly for the above changes,
particularly the historical remarks, linking indeed to the historical
remarks in the README.md file.
By some chance the original code that was restored as schweikh2.orig.c
was not the original. This has been fixed by copying it from the
archive. The file that is being updated is almost like my fix (which
solves a gcc internal compiler error).
At the top in the honour roll I changed (based on discussion) the
entries' links to the README.md files, not the source files, for both
Yusuke Endoh and myself. At the same time I added another category of
fixes that I have made.
Typo fixes as well.
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 README.md format was messed up (extraneous and erroneous '```'s) due
to the nightmare (or perhaps daymare :-) ) of the many merging conflicts
of yesterday which required repeatedly resolving conflicts in GitHub.
I also renamed 'slen.sh' to 'sflen.sh' as it shows the sparkle OF the
length of all the files rather than a sparkle length. References to
slen.sh have been changed to sflen.sh instead.
The demo.sh script and the sflen.sh script now run:
make all || exit 1
before proceeding. It does not do make clobber before because this only
clutters the output and is unnecessary if everything is already
compiled.
Oh and just for those who wonder if daymare is or is not really a word:
it is but I redefined it; literally it refers to a frightening hallucinatory
experience whilst awake (though perhaps GitHub was hallucinating :-) that
there were conflicts (well there were but there shouldn't have been)).
The fact it uses ruby is clear but the ruby script uses (via IO.popen())
the convert tool from the ImageMagick suite. When I first looked at it
and had the error it was not very clear to me what was going on. It was
not until another day when I looked at it again that I recalled that
convert is a tool that comes from ImageMagick which had previously been
on my MacBook Pro but hasn't been (until now) since macOS Sonoma was
installed.
Now the Makefile rule checks that both ruby and ImageMagick (via
checking for 'convert') are installed. If either aren't it will report
where they can be found and then after doing that if either are not
installed it exits 1. Otherwise if both are found it will run the
script.
Change (except in author's remarks in the wget command) the
/1984/mullender/mullender.c to be just mullender.c as it's in the entry
directory itself.
Format fixes in README.md as well.
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.
Cody Boone Ferguson