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.
The code that was the alt code now works entirely with gcc! The ver2 and
ver3 do not yet work with clang but the other versions do so it seems
appropriate to make this the main version and remove the alt code and
alt scripts.
I will continue to work on this in between the README.md files but this
feels like great progress and as it was all I felt up to at this time it
is definitely worth the effort and time.
The ver0 and ver1 work just as before but now ver2 and ver3 only have
one compilation error, rather than two, and I have kind of an idea of
what's going on as well. More work has to be done but at a later time.
The alt code has been changed so that in addition to the main feature
working it will also generate ver0 and ver1 correctly; ver2 and ver3
cannot be compiled still. This is not perfect but it is progress. I will
look at this further later most likely.
Added compile.alt.sh to compile the alt code and generate the alt code
generated code. It generates it in the file name form alt.ver[0-3].c and
the code will be compiled as such.
Added try.sh to demonstrate the main (original) program. This is because
there are a lot of commands to try.
Added try.alt.sh to demonstrate the alt program (not trying the ver2 and
ver3, naturally). The rationale is the same as for try.sh.
The Makefile has been updated for these changes.
Updated .gitignore as a number of new files will be created when running
compile.alt.sh.
The bugs.md has been updated as there has been some progress made. The
hint was removed at this time as it's not applicable now; the problem of
main() args not being allowed is no longer true. However the status line
has not been updated because the root of the problem is this. There are
currently no hints because I do not have any yet.
The thanks file has also been updated for the new scripts as well as the
situation being changed.
As the 'Alternate code' and 'Original code' heading level is now 2 the
'To build' and 'To use' subsections should be level 3, not 4, and also
reworded, this was done:
sgit -e 's/^#### To build/### Alternate build/g' -e 's/^#### To use/### Alternate use/g' '*README.md'
Many more have to be updated and this will be done manually at another
time.
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.
Unfortunately the fix to let the main program compile with clang even
breaks some versions generated (see compile.sh) in syntax error so even
gcc cannot compile those. Therefore it's now alt code. The alt version
will compile with clang and the main feature of the program will work
but the program cannot generate every version of the program.
The bugs.md and thanks-for-fixes.md have been updated along with the
README.md.
In the README.md there is a different heading level for the alt code
sections to compare to another as we try and figure out what heading
levels to use.
I changed the delay to 0 in the compile.sh script but one can set it to
another value if they like.
This entry will have to be worked on more at another time.
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.
Having to click on the links in each README.md file will have to be done
to verify the links work but it appears to be in the form of:
/bugs.md#YYYYauthor-readmemd
There were some places where there should not have been a \ at the end
of lines that were fixed. This occurred because there were spaces at the
end of the lines by accident. Very little else had to be done here.
Originally I put in the author's code without fixes in place. This is
one of the reasons I did not see the improvements that he suggested.
Several fixes had to be made and now it works. It should be noted I have
not tested more than one user updating the high score file but the file
is now created (I had to make a similar fix to the original entry as
well).
Format/typo check README.md file. Not sure I'm done with this one though
as presentation might be improved.
The alt code is based on the author's remarks: a trace routine had been
provided but it was commented out. It offers for some rather fun output.
The Makefile was updated accordingly.
The README.md file has been typo and format fixed.
The .gitignore file has been updated - added paul.alt.
Add a hexa-layered chocolate fudge cake :-) (see below)
Added try.me.sh script which will take a list of files (if no arg
specified it has a default of files added, as described below) and feed
each one to jar.2.
The lisp files added are: fib.lisp from Yusuke Endoh; try.me.txt from
the author; and chocolate_cake.lisp from me. The cake one uses '(quote
...)' that the program supports but the other files do not and plus who
can't use a bit (or lot :-) ) of chocolate cake?
Made the entry look slightly more like the original by adding back the
macros that can't be used but still are part of the entry (#defines for
define and include).
This is done so that I can provide another thing I forgot to mention in
the previous log. I fixed the scripts to not have the ill-famed useless
use of cat. Why is it ill-famed?
Because there's no such thing as a useless cat, that's why! In fact the
fact they exist proves that the Earth is NOT flat: if it was flat they
would have knocked everything off it by now! :-) Besides, they offer all
us ailurophiles hours and hours and years and years of joy and fun and
companionship. And contrary to popular belief, they most certainly do
have a personality and they can be very sociable.
There were some things unclear in the README.md file that have now been
corrected.
Clarified in the README.md that running make clobber all will run the
program itself.
The make alt target now runs the alt code just like the entry itself.
This is fine because it is a simulation (to avoid annoyance of writing
binary data to /dev/tty) and since one may still run the program or
script directly it's fine.
The alternate code section in the README.md was cleaned up and formatted
as well.
This is not complete as some things are not clear to me at this time. I
just fixed some things that could be fixed without looking over the full
file, just updating what was immediately noticed.
Format fix the README.md file including removing some '\'s at end of
lines (in the remarks).
Document feature that if the arg is a large number or < 0 (the latter of
which I discovered a few minutes ago as I was working on this) it will
enter an infinite loop trying to compile code that has syntax errors.
This was noted by the judges at the time so it is not a bug but a
feature. This has been added to the bugs.md and the README.md file.
As Landon said it is a bug (after I asked about it) I have fixed it.
Without this fix the program printed the same thing over and over again
in some cases. The problem was a for() loop that didn't always have the
pointer incremented. It looks like I could have got away with just
updating the increment part of the loop but I didn't do that as I didn't
see it at first.
The optimiser was disabled. That might not be strictly necessary but I
had it disabled for a time so I have kept it disabled.
Also I removed my name in the README.md: this was missed when the much
better idea of a general thanks file was come up with. When testing the
fix I came across part of my name which made me check. I have not yet
typo/format checked this file or any of 1989 so that was not done. That
might or might not happen in part or in whole later today but either way
it'll be started soon.
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'
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).
In the judges' remarks they refer to ouroboros.c as being an executable
but it's not in the repo. This is because it's created by the program
itself. It happens to be in .gitignore but this note should make it less
confusing and prevent people from thinking that a file is actually
missing.
I have tried to make the README.md file less cluttered wrt the clang
defects and instead just show how to use the entry, referring to the
bugs.md for those who need to know.
Added script compile.sh which generates the files and tries to compile
them. The script sleeps (by default approximately 1 second) in between
commands but this can be changed to another value (including 0). One can
also change the compiler path in case their compiler is clang or in the
case of macOS gcc IS clang. The README.md refers to this and gives
examples.
The bugs.md and the thanks-for-fixes.md files have been updated for
these changes and additions.
For those who do not know of the clang defects it is discussed in the
bugs.md and unfortunately for this entry there might be little that can
be done. I haven't tried to understand the entry deeply and maybe doing
so would give some ideas for fixes (beyond what I already did which lets
the main program compile with clang - or at least versions that allow a
fourth arg to main()) but this seems less important for now.
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.
Instead of writing the literal output of the binary to /dev/tty,
we simulate the output by silencing stderr and by piping the binary
thru strings.
The raw binary executable output to /dev/tty was capable "ill effects".
Such "ill effects" could be as mild as printing strange characters, to
beeping (sometimes for extended periods), and even the termination
of the terminal app window in some cases.
The "ill effects" from the printing of the raw binary executable
is highly dependent on the compiler, compiler version, libc, crt0.o,
operating system, terminal app and/or terminal driver. As such,
the "ill effects" that one user might see may be hard to reproduce
in order environments. While some of the more extreme "ill effects"
might be unlikely, what was more common was for the binary output
to be interpreted strangely by the terminal app and/or driver to
the extent that the was lost or not well seen by the user.
This change introduces the ${STRINGS} Makefile variable to the
`/var/mk` file and uses to to "clean out" any output that might
produce such "ill effects". Prior to the command, the echo does
clearly state:
```
NOTE: We will now simulate: cc -c -o /dev/tty jar.1.c
```
We also modify the `1989/jar.1/jar.1.sh` and `1989/jar.1/jar.1.alt.sh'
shell scripts to pipe raw binary through strings as well.
Thus the user can, if they wish, try the raw command themselves.
If that command does produce the more extreme examples of "ill
effects", the fault rests with the user. We mention that the
Makefile will echo the command to stdout in the `README.md`. But
that is as far as we go. We do **NOT RECOMMEND** having a shell
script or Makefile rule that would write the raw binary to `/dev/tty`
but rather let the immigration of the user try or not try it.
In general, the use piping raw binary thru stings makes the original
output more apparent, as was the case when using dumb CRT terminals
that couldn't even process ANSI escape sequences were more common.
In linux running make ver1 and make ver2 and make ver3 (not sure about
ver0 now) there was a strange error when running the rules that meant
the code was not compiled. Thinking on it just now it very likely was
the exit code of the program causing the problem but the file was
generated so I added a '-' to the line so that the rule will proceed to
try and compile the code.
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.
Makefile:90: *** recipe commences before first target. Stop.
This happened due to a typo which left off a \ before a newline where
it is meant to be one line.
Cody Boone Ferguson