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.
The alt code now allows one to quit early (in curses mode) and this
calls endwin() to restore terminal sanity. Due to the way the code is
designed the function which does that has to be defined three times but
only one has any code in it, that of the curses one. This means that
nodelay() is also called when initialising curses. At least at this time
the original entry does not have this feature and so one will have to
type 'reset' after they end the program to restore terminal sanity.
The alt code has been improved in another way too: now one does not have
to specify both macros at the command line when wishing to configure
only one of the programs. This is accomplished by #ifndef..#endif blocks
at the beginning of the file. That has not been done in other entries
but probably should be to help out.
The README.md file has been typo/format checked/fixed.
The FAQ has been updated as well: a question about how to use entries
that require curses has been added. This required some minor reordering
of the numbers but I believe that I got everything okay.
This includes typos, inconsistencies as well as updates to referring to
an entry to show how clang can complicate matters (sometimes greatly)
but making your entries work with clang will make your entry better.
A number of the FAQ questions strings were rewritten to be order,
a big more consistent in tone, and without any markdown symbols.
Each FAQ section has an HTML name tag before the section.
This has been done as an experiment in linking.
The FAQ table of contents has links into the FAQ sections,
however those links are using the current HTML name tags
and may not work in the `faq.md` markdown document.
We are not sure this will work, but we followed this suggestion:
https://stackoverflow.com/questions/6695439/how-to-link-to-a-named-anchor-in-multimarkdown
Unfortunately it is rendered literally in GitHub so this will not work.
Also '\' was removed from two lines in the file which were also rendered
literally (though that might be because of the <head> and <style>
related problem. Instead <br> has been used.
There are three new images in png/ which are part of this entry. It
might be reasonable to remove ne but to keep it consistent with the rest
of the answer it is kept there for now.
This commit is partly a test to see how it comes out with GitHub and
also in general so that it might have to be revised.
The faq.md has had some html added as well, not only embedded CSS style
for 'img' to hopefully make it responsive but also the question has a
named anchor to link to more easily later on (this is likely to happen
to the rest of the questions/answers at another time).
The FAQ has been updated to add something that was missing to the entry
about the general Makefile rules (make clobber, make all, make alt etc.)
that was in the todo. This has been removed from the todo.md as well.
Fix link in FAQ: not how-to-bugfix.md but how-to-help.md as I changed
this a while back as it isn't a matter of fixing a bug (which could be
any number of problems) but rather how to help with the website etc.
Make sure before a line starting with '#' that there are two blank lines
above it. Some already had this but many did not.
Change other things in todo.md file based on some things that have been
done (with corrections needed in some cases and otherwise the need to
verify no corrections are needed).
Typo fix in todo.md (swap a letter with a space).
I am aware that the todo.md is kind of a mess because of how it has been
updated. It would be helpful to have sections but this was meant to be a
quick update as it is more important to work on the things rather than
to organise the things that have to be done.
This felt important because numerous times I have had to put in a
README.md file and/or the thanks file that state that the authors' or
author's remarks no longer apply and what should be done about it. These
should be located and either be removed or be synchronised (or even
refer to the FAQ?).
Swap order of alt and original code in build/try sections so that the
original code is suggested second, after alt code, with the bugs and
(mis)features added to the README.md file, pointing out that it'll only
work on VAX-11 / PDP-11 machines. This is added in the bugs.md (it was
actually missing from the bugs.md file).
The alt code (both versions, see below) now have a lower limit on the
microseconds at 500 (still defaults at 10000). This is because anything
much lower and it's nigh impossible to see and in some cases it won't
work at all (at least in the MacBook Pro with the M1 chip).
Added second alt code which is like the first except that once it times
out it starts over.
Running make alt will compile both alt versions.
The gentab.c file that I added (found from the author) and fixed to
compile could not always create code that would compile due to some
characters needing to be escaped like ' and \. These are now escaped if
they are encountered but there certainly could be more that I did not
think of that would have to be escaped.
I have provided some examples as well and included how to use other diff
programs like colordiff. Checking formatting (including how it looks on
GitHub) and typo checks notwithstanding this entry is in good condition.
It seems to me that it is a good idea to show people how to see what
changed in order to get an entry to work in modern systems. I gave an
example where it's harder to tell because it's a very long line and an
example where it's easier to tell as it's not long lines but rather
shorter lines. Well it's easier to see on a line-by-line basis ..
whether it's easy to see what actually changed is probably another
matter entirely (especially since it's easier to see when you have
compiler errors in front of you) :-)
I gave example output of a program where not changing it caused
confusing output, particularly in macOS, which is one of the strongest
reasons to make the change as it affects usability (in that it can make
one wonder what to do albeit probably briefly so).
As I thought it was indeed in unix but it seems to have vanished. I had
never seen it back then and it appears that only Plan 9 now has it. Plan
9, however, was never used for judging.
FAQ now links to Unix man page for cb.
Includes Plan 9 source code and a html rendered man page. If there was a
unix or linux version the code can no longer be found.
Some README.md files refer to this tool. When an author's remarks it
will not be removed or updated but if in the judges' remarks it might be
moved to a historical note subsection. This will happen in time with
additional passes of the README.md files - for most it should be the
final pass but the years 2011+ will need a pass before that.
It is now noted that in some cases the fix can be as simple as adding
a macro so that the entry looks almost identical to the original. I gave
an example of 1988/reddy where all that had to be added was a
redefinition of gets.
The reason it is in alt code is because one of the forms of input (see
below) will, although print out correct output, segfault after
outputting the text. That is when one does something like:
echo foo | ./hague.alt
Whether it might be worth making it the entry itself with a note in the
Makefile and README.md and bugs.md (because it does print out correct
output) can be determined later - or not.
This change required several files to be updated besides the new file
hague.alt.c.
The prototype answer is from discussion on GitHub, suggested by Landon,
but I added to it and fixed typos as well. I probably introduced some
other problems at this hour and at least one thing comes to mind as
perhaps not ideal to have but these things can be worked out now that
they're in the file.
The following entries were added:
0. Makefile rules.
1. 32-bit entries not working in 64-bit systems.
2. Some entries not working in macOS either uncompilable or
non-functional.
3. Entries that cannot be compiled with clang.
For (3) this especially is problematic for macOS as even /usr/bin/gcc is
clang (as has been noted many times before this but not in the FAQ).
At least one typo fix was also made and at least one entry that already
existed was updated a bit.
The fixes to the thanks file are related to the FAQ entries added.
As I was looking at 2004/burley/README.md it occurred to me that
numerous entries have been modified in ways that are incongruent with
what the author(s) originally wrote about the entry. In some cases this
has been noted in the README.md file (like has been added to
2004/burley/README.md itself) but not in all. That should probably be
checked for and I will do that in time most likely but in the meantime
it felt even better to update the FAQ about this which this commit does
as well.
I added an entry on how to get sound entries to work under macOS (well
some already will work but some need SoX and I explained two ways to
install it - MacPorts and Homebrew).
I added an entry explaining where to find a list of entries with known
issues or things that appear to be issues but are rather features.
I also elaborated on some entries and I moved the terminal sanity (or
insanity :-) ) entry closer to the top as it seems like it is better to
help restore terminal sanity closer to the top as a messed up terminal
is very annoying.
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.
Remove how to install SDL1 / SDL2 from var.mk as it's already in faq.md.
Instead refer to faq.md. How to compile (variables etc.) is still in the
var.mk file.
Reworded that section a bit and added 'Other linux distributions'
subsection to 'Linux' (in faq.md).
Minor typo fix in faq.md at the same time as the above change. Normally
I would not do this but it's one word changed and I am too tired at this
time (or can't be bothered?) to do another pull request for one word.
In other words after running a curses program (ANSI escape codes can
also cause problems) the terminal can be quite insane; echo might be
disabled as a simpler example but many worse more annoying problems can
occur.
The simplest way is to run reset. This will restore everything though
it'll clear the screen (clear command will not fix any problems but just
clear the screen). For echo disabled stty echo should work. Sometimes
you can get away with doing stty sane.
Now these are in the faq.md. I wrote more about this in 2020/ferguson1
but that doesn't really matter other than it was the inspiration for
this entry (which I think is a good idea to include).
Since fixes can be made via GitHub pull requests I updated the question
about finding bugs in entries, making sure to note that just because
someone has a fix does not mean that it'll be accepted (in fact I kind
of feel guilty about the fixes I have made except for entries that no
longer worked for one of the reasons noted in the FAQ entry).
It's very possible that in fixing entries rule 2 will be broken in some
entries. This should be noted in the faq as people might notice it and
find it dubious. The new entry now points out that when fixing entries
it's very possible that rule 2 could inadvertently be broken but the
originals can be seen in /archive.
Mostly this update is about SDL and SDL2 and how to compile and run
entries that make use of it. But I first saw reference to this idea in
2018/giles/README.md.
I added to macOS section MacPorts which is another very popular package
manager for macOS (I personally don't like Homebrew and I use MacPorts
instead).
Minor fixes in 2018/giles/README.md (formatting plus make a URL an
actual link).
Some years after the entry was published the judges asked them if they
wished to remain anonymous. They said yes but added that they are well
known for their there connection to the C language.
I fixed at the same time the typo that was in this quote as it seemed
that it's better to be clear than to keep a quote exactly as is
especially as it might have not been a copy paste in the first place.
Now you can specify the number of microseconds to sleep in between
writes! This makes it easier to experiment with different speeds as well
as solve any problems if your CPU is too slow or too fast
BTW: is there such a thing as too fast a CPU ? :-) actually yes for
certain code which is probably not as uncommon as you think :-) ).
Format fixes (besides line lengths other formatting changes were made in
hopes to make things clearer / easier to see / better).
Reword some answers a bit to hopefully make them better.
Typo fixes here and there. There is one I'm not sure if it's meant to be
a typo or rather if I should change it since it's actually a quote: that
from 1984/anonymous. Thus I have not changed it.
Now anyone can enjoy 1984/mullender! This was a slight change to code
originally suggested in the faq (which was also updated, see below) made
for modern systems (since CPUs are much faster nowadays the duration for
usleep was much too long so one could not really enjoy the entry).
Updated bugs.md to remove this entry from the bugs.md file.
Also updated faq.md with another item. Unfortunately I had already added
another entry to faq.md and had failed to commit it before doing this
change (and adding it to the faq): how to get X11 entries (or actually
any X11 application) to work in macOS Mountain Lion and beyond. This is
why that faq entry is on this branch. It was not intended but it felt
like this change should be on its own branch / in a separate pull
request. I did not want to temporarily modify faq.md simply for this. I
have more changes to faq.md to make but that'll be on another branch so
that I have these changes there as well.
I tried to keep the formatting as close to the original as possible.
It's very likely links have to be fixed and it's very likely formatting
has to be fixed.
Some things necessarily had to change but very few did in fact need to
change.
As tempting as it was to change it to British English I did not (though
I started to when fixing a link but I caught myself in time) :-)
Naturally as this is a major change problems are expected but these will
be worked out. I guess the next step would be to do this for other raw
html files but I don't fancy doing more than one in a day. This can be
discussed later though as some will be automatically generated anyway so
no need for a markdown file (faq.md was discussed as a good idea).
Landon Curt Noll