Enhancement: Fix typos

[lcn2]

Scope - About this issue

Fix typos in "judges remarks / winner writeup / winner's remarks".

Fix typos in Makefiles.

Fix typos in rules and guidelines for a given year.

Typos include spelling and grammar.

NOTE: This writeup is subject to changes and revisions as the understanding of this issue evolves / improves. Check back to this note from time to time. When modification are made to this comment, we will try to add a note indicating that the scope of this issue has been updated.

Rules and guidelines

To preserve the rules, when a typo is fixed in a rules file, the original rules should be copied into orig.rules. This helps preserve the historic record.

To preserve the guidelines, when a typo is fixed in a guidelines file, the original rules should be copied into orig.guidelines. This helps preserve the historic record.

In some cases rules and guidelines had intentional "bugs". Some of those "bugs" may be in the form of a typo. As such this should NOT be fixed. When in doubt, ask an IOCCC judge.

Language

The spelling and grammar of text written by an IOCCC judge should be in "US English".

The spelling and grammar of winner, however, may differ depending on the origin of the winner.

Edit with some judgment in mind. :-)

Other files

Typos in other webs site files are in scope. Nevertheless, one should NOT edit typos in source code. Such types are "features, not bugs". :-)

[xexyl]

Well as you know I'm EXTREMELY GOOD at this one. I can certainly help with this!

What about when it's not clear what was meant though ?

Scope - About this issue

Fix typos in "judges remarks / winner writeup / winner's remarks".

Fix typos in Makefiles.

Fix typos in rules and guidelines for a given year.

Typos include spelling and grammar.

Though grammar is also a difficult one to consider, see below.

NOTE: This writeup is subject to changes and revisions as the understanding of this issue evolves / improves. Check back to this note from time to time. When modification are made to this comment, we will try to add a note indicating that the scope of this issue has been updated.

Thanks for the note.

Rules and guidelines

To preserve the rules, when a typo is fixed in a rules file, the original rules should be copied into orig.rules. This helps preserve the historic record.

Rules? Perhaps Makefiles?

To preserve the guidelines, when a typo is fixed in a guidelines file, the original rules should be copied into orig.guidelines. This helps preserve the historic record.

Do you mean remarks ? Or have I forgotten some of the names of earlier entries ?

In some cases rules and guidelines had intentional "bugs". Some of those "bugs" may be in the form of a typo. As such this should NOT be fixed. When in doubt, ask an IOCCC judge.

That's another concern indeed. I would also add: we should not modify if it's rot13'd or encrypted in some other form. That's very intentional by the author and has a real meaning. I noted this one before of course.

Language

The spelling and grammar of text written by an IOCCC judge should be in "US English".

The spelling and grammar of winner, however, may differ depending on the origin of the winner.

Indeed. That's really important to me. Thankfully I know enough US English and I use British English so I should be good at this too.

As far as grammar goes: there is a lot to be said and in some cases British English differs too. It might be hard to distinguish which way to use it. There are also some controversial (and some stupid) rules like the don't end a sentence with a preposition. As OED will remind us:

USAGE There is a traditional view, first set forth by the 17th-century poet and dramatist John Dryden, that it is incorrect to put a preposition at the end of a sentence, as in where do you come from? or she's not a writer I've ever come across. The rule was formulated on the basis that, since in Latin a preposition cannot come after the word it governs or is linked with, the same should be true of English. The problem is that English is not like Latin in this respect, and in many cases (particularly in questions and with phrasal verbs) the attempt to move the preposition produces awkward, unnatural-sounding results. Winston Churchill is often credited with objecting to the rule by saying, ‘This is the sort of English up with which I will not put.’ In standard English the placing of a preposition at the end of a sentence is widely accepted, provided the use sounds natural and the meaning is clear.

Probably the only thing I agree with Churchill about but never mind that! :-)

Edit with some judgment in mind. :-)

Other files

Typos in other webs site files are in scope. Nevertheless, one should NOT edit typos in source code. Such types are "features, not bugs". :-)

Agreed.

[lcn2]

Though grammar is also a difficult one to consider, see below.

If grammatical errors and punctuation and style are to difficult to address, just focus on unclear wording. When some wording needs to be improved, try to maintain the style and format of the author(s): improvement in place rather than rewriting.

Remember that in some cases their may be a pun or joke that should be best as is.

The same could be said to preserve rot13 text as is.

[lcn2]

Thanks for the note.

Just to be clear, when the top level scope comment is updated, we will add a brand new comment at the bottom indicating that the top scope was edited (with a link to that top comment) and perhaps a tiny bit of what was changed or why. We plan to do this for all issues in the repo.

[lcn2]

Well as you know I'm EXTREMELY GOOD at this one. I can certainly help with this!

👍👍👍‼️‼️‼️

[lcn2]

Rules? Perhaps Makefiles?

Yes on rules (and guidelines) for the year.

Every Makefile has already been touched, and the proper "original" (if there was one) was preserved. So you don't need to preserve original copies of Makefiles.

[lcn2]

Do you mean remarks ? Or have I forgotten some of the names of earlier entries ?

The rules and guidelines and overall judges remakes are kept at the year level directory. If those are to be edited, the original text should be kept as an orig file.

[xexyl]

Aside: I am a collector of Notgeld 'emergency money' and I was going through some of my sets this morning as there were some things I wanted to check on them. Unfortunately that took some time so I now have less time here before I need to go do other things. However I hope that later on I can do some work here. We shall see.

And now to the other good stuff - the IOCCC!

Though grammar is also a difficult one to consider, see below.

If grammatical errors and punctuation and style are to difficult to address, just focus on unclear wording. When some wording needs to be improved, try to maintain the style and format of the author(s): improvement in place rather than rewriting.

Yes it might be difficult to address the grammar. And it might be difficult to address the spelling. See below.

Remember that in some cases there may be a pun or joke that should be best as is.

This is another reason to consider not doing this. Perhaps I should just fix spelling errors? I'm not sure. I will do what you wish but: style is difficult to ascertain esp if the person has some peculiarity.

Also I have to say that personally I would not want my entries touched if say someone else was doing this esp without being asked about it.

Should I maybe just address spelling errors / typos and perhaps thing that could EASILY be fixed / clarified?

The same could be said to preserve rot13 text as is.

Absolutely! I even stated this. Plus with mine there's a fun challenge - well the Enigma one - and obviously it's not rot13. For all I know there might be others that are encrypted in some other form that isn't rot13.

[xexyl]

Thanks for the note.

Just to be clear, when the top level scope comment is updated, we will add a brand new comment at the bottom indicating that the top scope was edited (with a link to that top comment) and perhaps a tiny bit of what was changed or why. We plan to do this for all issues in the repo.

Thank you! That's all I need.

[xexyl]

Well as you know I'm EXTREMELY GOOD at this one. I can certainly help with this!

👍👍👍‼️‼️‼️

:)

[xexyl]

Rules? Perhaps Makefiles?

Yes on rules (and guidelines) for the year.

Thank you. I no longer know the context but I'll check back at my reply / the first message at the right time.

Every Makefile has already been touched, and the proper "original" (if there was one) was preserved. So you don't need to preserve original copies of Makefiles.

Thanks!

[xexyl]

Do you mean remarks ? Or have I forgotten some of the names of earlier entries ?

The rules and guidelines and overall judges remakes are kept at the year level directory. If those are to be edited, the original text should be kept as an orig file.

Ah yes. For instance in 2020:

• https://www.ioccc.org/2020/README.md
• https://www.ioccc.org/2020/guidelines.txt
• https://www.ioccc.org/2020/rules.txt

If any of those have typos, for example, they should be renamed to foo.orig and then the fixed copies will be the previous (original .. if it's an original name and it's not original how is it original ? :-) ) name.

[lcn2]

Do you mean remarks ? Or have I forgotten some of the names of earlier entries ?

The rules and guidelines and overall judges remakes are kept at the year level directory. If those are to be edited, the original text should be kept as an orig file.

Ah yes. For instance in 2020:

• https://www.ioccc.org/2020/README.md

• https://www.ioccc.org/2020/guidelines.txt

• https://www.ioccc.org/2020/rules.txt

If any of those have typos, for example, they should be renamed to foo.orig and then the fixed copies will be the previous (original .. if it's an original name and it's not original how is it original ? :-) ) name.

Yes.

[xexyl]

Do you mean remarks ? Or have I forgotten some of the names of earlier entries ?

The rules and guidelines and overall judges remakes are kept at the year level directory. If those are to be edited, the original text should be kept as an orig file.

Ah yes. For instance in 2020:

• https://www.ioccc.org/2020/README.md
• https://www.ioccc.org/2020/guidelines.txt
• https://www.ioccc.org/2020/rules.txt

If any of those have typos, for example, they should be renamed to foo.orig and then the fixed copies will be the previous (original .. if it's an original name and it's not original how is it original ? :-) ) name.

Yes.

Thanks.

[lcn2]

Should I maybe just address spelling errors / typos and perhaps thing that could EASILY be fixed / clarified?

Yes

[xexyl]

Should I maybe just address spelling errors / typos and perhaps thing that could EASILY be fixed / clarified?

Yes

Just to be clear: I meant to not do anything else. Is that still ideal?

.. and I'll be leaving soon. Good news is I got the domains problem completely solved. Tomorrow I will check that DNSSEC is still working but I know the glue records are working (or so it seems through updating the SOA and checking a third party DNS server).

Tomorrow morning I do have more cleaning I need to do but I will be able to discuss more at the least.

UPDATE 0

Leaving now. Will reply to more tomorrow. Enjoy the rest of your day!

[lcn2]

Just to be clear: I meant to not do anything else. Is that still ideal?

Yes, for this particular issue, the idea is to correct typos, and other obvious simple mistakes.

That being said, when you touch a file that hasn't been touched before, and there's not a "orig" copy, a copy needs to be made before changing the file.

UPDATE 0a

Text replaced by comment 1421609887

[lcn2]

OT

I got the domains problem completely solved. Tomorrow I will check that DNSSEC is still working but I know the glue records are working (or so it seems through updating the SOA and checking a third party DNS server).

Congratulations on making progress on your domains.

DNSSEC is something we have been avoiding, but should face, for reasons you can understand.

[lcn2]

Moved this comment to to issue #3 as comment 1421605046

[lcn2]

Moved this comment to issue #3 as comment 1421609887

[xexyl]

Just to be clear: I meant to not do anything else. Is that still ideal?

Yes, for this particular issue, the idea is to correct typos, and other obvious simple mistakes.

That being said, when you touch a file that hasn't been touched before, and there's not a "orig" copy, a copy needs to be made before changing the file.

I think that is imperative as well.

UPDATE 0a

Text replaced by comment 1421609887

I will address this later. I am sure that I will have some questions and general thoughts.

[xexyl]

OT

I got the domains problem completely solved. Tomorrow I will check that DNSSEC is still working but I know the glue records are working (or so it seems through updating the SOA and checking a third party DNS server).

Congratulations on making progress on your domains.

I ended up saving money too and because of that I was able to buy myself more things for my birthday (and rewarding myself for doing so well on losing weight since 2 May .. still have a ways to go but more than half way there).

DNSSEC is something we have been avoiding, but should face, for reasons you can understand.

Thank you. Yes I avoided it for years too but I finally did it and that was years ago now.

[lcn2]

OT

DNSSEC is something we have been avoiding, but should face, for reasons you can understand.

Thank you. Yes I avoided it for years too but I finally did it and that was years ago now.

What do you think you gained by adding DNSSEC?

[xexyl]

OT

DNSSEC is something we have been avoiding, but should face, for reasons you can understand.

Thank you. Yes I avoided it for years too but I finally did it and that was years ago now.

What do you think you gained by adding DNSSEC?

Good question. I think part of it is just the fact it’s extra security.

That and it will silence systems that check for vulnerabilities (at least those that check for it).

It’s probably more important to the user but then my domains don’t exactly have a lot to users. Even so it’s better to have it there anyway.

I will respond to the other replies tomorrow.

I hope you have a great night my friend! When I am awake enough to address the comments I will do that. I will be awake a while yet but I am about to get ready to sleep.

I hope that I can figure out how to fork this repo. What can we do if github doesn’t let me? Something has to be done and unfortunately your idea which I thought would solve the problem didn’t :(

Anyway have a great night! Sleep well my friend!

Good night!

[lcn2]

We believe we have addressed all of the current questions that still need answering at this time. If we've missed something or something else needs to be clarified, please ask again.

[xexyl]

Just to be clear: I meant to not do anything else. Is that still ideal?

Yes, for this particular issue, the idea is to correct typos, and other obvious simple mistakes.

Thanks.

That being said, when you touch a file that hasn't been touched before, and there's not a "orig" copy, a copy needs to be made before changing the file.

That's something I'm not yet clear on how it will go. I guess that's what you mean by the below update?

UPDATE 0a

Text replaced by comment 1421609887

This is about the orig files and not something else in that comment, right?

[lcn2]

That being said, when you touch a file that hasn't been touched before, and there's not a "orig" copy, a copy needs to be made before changing the file. That's something I'm not yet clear on how it will go. I guess that's what you mean by the below update?

UPDATE 0a

Text replaced by comment 1421609887 This is about the orig files and not something else in that comment, right?

Correct.

[xexyl]

That being said, when you touch a file that hasn't been touched before, and there's not a "orig" copy, a copy needs to be made before changing the file. That's something I'm not yet clear on how it will go. I guess that's what you mean by the below update? UPDATE 0a Text replaced by comment 1421609887 This is about the orig files and not something else in that comment, right?

Correct.

Okay but in this case how does the idea you have about an archive tarball (and not having orig files in the repo - which again I personally think is not viewer friendly) change this? From what I gather you don't want orig files now.

[lcn2]

That being said, when you touch a file that hasn't been touched before, and there's not a "orig" copy, a copy needs to be made before changing the file.

That's something I'm not yet clear on how it will go. I guess that's what you mean by the below update?

UPDATE 0a

Text replaced by comment 1421609887

This is about the orig files and not something else in that comment, right?

Correct.

Okay but in this case how does the idea you have about an archive tarball (and not having orig files in the repo - which again I personally think is not viewer friendly) change this? From what I gather you don't want orig files now.

Correct. Truly "orig" files will live in the archive/archive-YYYY.txz files, the git logs and the internet "way-back" Internet archive.

[xexyl]

That being said, when you touch a file that hasn't been touched before, and there's not a "orig" copy, a copy needs to be made before changing the file.

That's something I'm not yet clear on how it will go. I guess that's what you mean by the below update?

UPDATE 0a

Text replaced by comment 1421609887

This is about the orig files and not something else in that comment, right?

Correct.

Okay but in this case how does the idea you have about an archive tarball (and not having orig files in the repo - which again I personally think is not viewer friendly) change this? From what I gather you don't want orig files now.

Correct. Truly "orig" files will live in the archive/archive-YYYY.txz files, the git logs and the internet "way-back" Internet archive.

Okay well I'll wait until you sort this out and I'm sure it'll be clearer to me then.

[xexyl]

$ git grep submittion
1993/guidelines:435:    Be sure that the resubmittion uses the same title and entry number
1993/mkentry.c:584:    printf("Is this a fix, update or resubmittion to a ");
1993/rules:91:    title and entry number as submittion that is being corrected.  Be
1993/rules:92:    sure that you note the resubmittion in the ---remark--- as well.
1994/guidelines:519:    Be sure that the resubmittion uses the same title and entry number
1994/mkentry.c:584:    printf("Is this a fix, update or resubmittion to a ");
1994/rules:91:    title and entry number as submittion that is being corrected.  Be
1994/rules:92:    sure that you note the resubmittion in the ---remark--- as well.
1995/guidelines:579:    Be sure that the resubmittion uses the same title and entry number
1995/mkentry.c:588:    printf("Is this a fix, update or resubmittion to a ");
1996/mkentry.c:584:    printf("Is this a fix, update or resubmittion to a ");
1998/mkentry.c:615:    printf("Is this a fix, update or resubmittion to a ");
2000/mkentry.c:608:    printf("Is this a fix, update or resubmittion to a ");
2001/mkentry.c:637:    printf("Is this a fix, update or resubmittion to a ");
2004/mkentry.c:638:    printf("Is this a fix, update or resubmittion to a ");

This is a consistent typo for resubmission, right ?

[lcn2]

$ git grep submittion

1993/guidelines:435:    Be sure that the resubmittion uses the same title and entry number

1993/mkentry.c:584:    printf("Is this a fix, update or resubmittion to a ");

1993/rules:91:    title and entry number as submittion that is being corrected.  Be

1993/rules:92:    sure that you note the resubmittion in the ---remark--- as well.

1994/guidelines:519:    Be sure that the resubmittion uses the same title and entry number

1994/mkentry.c:584:    printf("Is this a fix, update or resubmittion to a ");

1994/rules:91:    title and entry number as submittion that is being corrected.  Be

1994/rules:92:    sure that you note the resubmittion in the ---remark--- as well.

1995/guidelines:579:    Be sure that the resubmittion uses the same title and entry number

1995/mkentry.c:588:    printf("Is this a fix, update or resubmittion to a ");

1996/mkentry.c:584:    printf("Is this a fix, update or resubmittion to a ");

1998/mkentry.c:615:    printf("Is this a fix, update or resubmittion to a ");

2000/mkentry.c:608:    printf("Is this a fix, update or resubmittion to a ");

2001/mkentry.c:637:    printf("Is this a fix, update or resubmittion to a ");

2004/mkentry.c:638:    printf("Is this a fix, update or resubmittion to a ");

This is a consistent typo for resubmission, right ?

Yes

[xexyl]

```shell
$ git grep submittion

1993/guidelines:435:    Be sure that the resubmittion uses the same title and entry number

1993/mkentry.c:584:    printf("Is this a fix, update or resubmittion to a ");

1993/rules:91:    title and entry number as submittion that is being corrected.  Be

1993/rules:92:    sure that you note the resubmittion in the ---remark--- as well.

1994/guidelines:519:    Be sure that the resubmittion uses the same title and entry number

1994/mkentry.c:584:    printf("Is this a fix, update or resubmittion to a ");

1994/rules:91:    title and entry number as submittion that is being corrected.  Be

1994/rules:92:    sure that you note the resubmittion in the ---remark--- as well.

1995/guidelines:579:    Be sure that the resubmittion uses the same title and entry number

1995/mkentry.c:588:    printf("Is this a fix, update or resubmittion to a ");

1996/mkentry.c:584:    printf("Is this a fix, update or resubmittion to a ");

1998/mkentry.c:615:    printf("Is this a fix, update or resubmittion to a ");

2000/mkentry.c:608:    printf("Is this a fix, update or resubmittion to a ");

2001/mkentry.c:637:    printf("Is this a fix, update or resubmittion to a ");

2004/mkentry.c:638:    printf("Is this a fix, update or resubmittion to a ");

This is a consistent typo for resubmission, right ?

Yes

I will fix it tomorrow.

[xexyl]

This is a consistent typo for resubmission, right ?

Yes

I will fix it tomorrow.

Fixed in commit 017278725a36772512632b9d821c841cd247b0fd.

[xexyl]

Question for you. Is the 'the the' intentional in these files?

1992/rules:145:       We will attempt to email a confirmation to the the first author for
1993/guidelines:411:    AI progs!) If you need tell the the something, put it in the
1993/rules:166:       We will attempt to email a confirmation to the the first author for
1994/guidelines:495:    not AI progs!) If you need tell the the something, put it in          |
2001/guidelines:787:    Sometime after the initial announcement, and once the the review by            |
2001/herrmann1/herrmann1.gcd:38:/* The state "st_next_iteration" means the the turing machine
2004/guidelines:495:    Sometime after the initial announcement, and once the the review
2005/guidelines.txt:502:    Sometime after the initial announcement, and once the the review
2006/guidelines.txt:505:    Sometime after the initial announcement, and once the the review
2011/guidelines.txt:541:    Sometime after the initial announcement, and once the the review
2012/guidelines.txt:651:    Sometime after the initial announcement, and once the the review
2013/guidelines.txt:728:    Sometime after the initial announcement, and once the the review
2014/guidelines.txt:743:    Sometime after the initial announcement, and once the the review
2015/guidelines.txt:809:    Sometime after the initial announcement, and once the the review
2018/guidelines.txt:895:    Sometime after the initial announcement, and once the the review
2019/guidelines.txt:903:    Sometime after the initial announcement, and once the the review
2020/guidelines.txt:938:    Sometime after the initial announcement, and once the the review

? I fixed some that weren't in the guidelines and rules but with those I really don't know if it's intentional. As for 2001/herrmann1/herrmann1.gcd I'm not sure if it's a problem or not. It's a data file. It looks like it's in a comment though - a C style comment.

Similarly in that file there's a 'turing' instead of 'Turing' but I don't know if that should be changed?

Anyway see commit 2976d211779a56581876040d5a1457dd696ea1a1 for places where I'm sure it was okay to fix as I'm sure they were typos.

[lcn2]

Question for you. Is the 'the the' intentional in these files?

1992/rules:145:       We will attempt to email a confirmation to the the first author for
1993/guidelines:411:    AI progs!) If you need tell the the something, put it in the
1993/rules:166:       We will attempt to email a confirmation to the the first author for
1994/guidelines:495:    not AI progs!) If you need tell the the something, put it in          |
2001/guidelines:787:    Sometime after the initial announcement, and once the the review by            |
2001/herrmann1/herrmann1.gcd:38:/* The state "st_next_iteration" means the the turing machine
2004/guidelines:495:    Sometime after the initial announcement, and once the the review
2005/guidelines.txt:502:    Sometime after the initial announcement, and once the the review
2006/guidelines.txt:505:    Sometime after the initial announcement, and once the the review
2011/guidelines.txt:541:    Sometime after the initial announcement, and once the the review
2012/guidelines.txt:651:    Sometime after the initial announcement, and once the the review
2013/guidelines.txt:728:    Sometime after the initial announcement, and once the the review
2014/guidelines.txt:743:    Sometime after the initial announcement, and once the the review
2015/guidelines.txt:809:    Sometime after the initial announcement, and once the the review
2018/guidelines.txt:895:    Sometime after the initial announcement, and once the the review
2019/guidelines.txt:903:    Sometime after the initial announcement, and once the the review
2020/guidelines.txt:938:    Sometime after the initial announcement, and once the the review

No, it is a typo.

? I fixed some that weren't in the guidelines and rules but with those I really don't know if it's intentional. As for 2001/herrmann1/herrmann1.gcd I'm not sure if it's a problem or not. It's a data file. It looks like it's in a comment though - a C style comment.

Similarly in that file there's a 'turing' instead of 'Turing' but I don't know if that should be changed?

Yes.

Anyway see commit 2976d21 for places where I'm sure it was okay to fix as I'm sure they were typos.

Thanks.

[lcn2]

We believe we have addressed all of the current questions that still need answering (some questions we believe are no longer relevant as the issue has been overtaken by recent decisions and/or events) at this time. If we've missed something or something else needs to be clarified, please ask again.

[xexyl]

Another diff to consider:

diff --git i/2000/tomx/README.md w/2000/tomx/README.md
index c2dba0630f6e578319252583b07e928d558f521a..ae5b4ce8cb07996c38926c47c35f92fed7017436 100644
--- i/2000/tomx/README.md
+++ w/2000/tomx/README.md
@@ -1,114 +1,117 @@
[...]
-Judges' Comments:
+## Judges' Comments:
+### To use:

-    To build:
+    make tomx

-   make tomx
+### Try:

-    Try:
+    rm -f ./tomx
+    sh tomx.c
+    ./tomx

-   rm -f ./tomx
-   sh tomx.c              
-   ./tomx
+If sh is your shell:

-    If sh is your shell:
+    rm -f ./tomx
+    chmod +x ./tomx.c
+    ./tomx.c
+    ./tomx

-   rm -f ./tomx
-   chmod +x ./tomx.c
-   ./tomx.c 
-   ./tomx
+### Also try:

-    Also try:
+    rm -f ./tomx
+    make -f tomx.c
+    ./tomx

-   rm -f ./tomx
-   make -f tomx.c
-   ./tomx

-    Polyglots have come and gone, but this was the first one we'd seen
-    where one language *used* another to perform its tasks.  An interesting
-    approach.  Admittedly, it's not all that obfuscated - but there's more
-    to it than you might think, since you have to make sure that your
-    changes don't change the shell code or the makefile.
+### Selected Judges Remarks

+Polyglots have come and gone, but this was the first one we'd seen
+where one language *used* another to perform its tasks.  An interesting
+approach.  Admittedly, it's not all that obfuscated - but there's more
+to it than you might think, since you have to make sure that your
+changes don't change the shell code or the makefile.

Should I commit that also?

[xexyl]

Question for you. Is the 'the the' intentional in these files?

1992/rules:145:       We will attempt to email a confirmation to the the first author for
1993/guidelines:411:    AI progs!) If you need tell the the something, put it in the
1993/rules:166:       We will attempt to email a confirmation to the the first author for
1994/guidelines:495:    not AI progs!) If you need tell the the something, put it in          |
2001/guidelines:787:    Sometime after the initial announcement, and once the the review by            |
2001/herrmann1/herrmann1.gcd:38:/* The state "st_next_iteration" means the the turing machine
2004/guidelines:495:    Sometime after the initial announcement, and once the the review
2005/guidelines.txt:502:    Sometime after the initial announcement, and once the the review
2006/guidelines.txt:505:    Sometime after the initial announcement, and once the the review
2011/guidelines.txt:541:    Sometime after the initial announcement, and once the the review
2012/guidelines.txt:651:    Sometime after the initial announcement, and once the the review
2013/guidelines.txt:728:    Sometime after the initial announcement, and once the the review
2014/guidelines.txt:743:    Sometime after the initial announcement, and once the the review
2015/guidelines.txt:809:    Sometime after the initial announcement, and once the the review
2018/guidelines.txt:895:    Sometime after the initial announcement, and once the the review
2019/guidelines.txt:903:    Sometime after the initial announcement, and once the the review
2020/guidelines.txt:938:    Sometime after the initial announcement, and once the the review

No, it is a typo.

It helped me find a really funny bug in sgit that I'm not sure what to do to solve it yet. I will reply to the rest of the comments though I have to make a minor fix to the commit I made that improves that script.

? I fixed some that weren't in the guidelines and rules but with those I really don't know if it's intentional. As for 2001/herrmann1/herrmann1.gcd I'm not sure if it's a problem or not. It's a data file. It looks like it's in a comment though - a C style comment. Similarly in that file there's a 'turing' instead of 'Turing' but I don't know if that should be changed?

Yes.

Will do. There are many places. Will exclude source code of course if any exist.

Anyway see commit 2976d21 for places where I'm sure it was okay to fix as I'm sure they were typos.

Thanks.

Happy to help.

[lcn2]

Another diff to consider:

diff --git i/2000/tomx/README.md w/2000/tomx/README.md
index c2dba0630f6e578319252583b07e928d558f521a..ae5b4ce8cb07996c38926c47c35f92fed7017436 100644
--- i/2000/tomx/README.md
+++ w/2000/tomx/README.md
@@ -1,114 +1,117 @@
[...]
-Judges' Comments:
+## Judges' Comments:
+### To use:

-    To build:
+    make tomx

- make tomx
+### Try:

-    Try:
+    rm -f ./tomx
+    sh tomx.c
+    ./tomx

- rm -f ./tomx
- sh tomx.c              
- ./tomx
+If sh is your shell:

-    If sh is your shell:
+    rm -f ./tomx
+    chmod +x ./tomx.c
+    ./tomx.c
+    ./tomx

- rm -f ./tomx
- chmod +x ./tomx.c
- ./tomx.c 
- ./tomx
+### Also try:

-    Also try:
+    rm -f ./tomx
+    make -f tomx.c
+    ./tomx

- rm -f ./tomx
- make -f tomx.c
- ./tomx

-    Polyglots have come and gone, but this was the first one we'd seen
-    where one language *used* another to perform its tasks.  An interesting
-    approach.  Admittedly, it's not all that obfuscated - but there's more
-    to it than you might think, since you have to make sure that your
-    changes don't change the shell code or the makefile.
+### Selected Judges Remarks

+Polyglots have come and gone, but this was the first one we'd seen
+where one language *used* another to perform its tasks.  An interesting
+approach.  Admittedly, it's not all that obfuscated - but there's more
+to it than you might think, since you have to make sure that your
+changes don't change the shell code or the makefile.

Should I commit that also?

Sure.

[xexyl]

Another diff to consider:

diff --git i/2000/tomx/README.md w/2000/tomx/README.md
index c2dba0630f6e578319252583b07e928d558f521a..ae5b4ce8cb07996c38926c47c35f92fed7017436 100644
--- i/2000/tomx/README.md
+++ w/2000/tomx/README.md
@@ -1,114 +1,117 @@
[...]
-Judges' Comments:
+## Judges' Comments:
+### To use:

-    To build:
+    make tomx

-   make tomx
+### Try:

-    Try:
+    rm -f ./tomx
+    sh tomx.c
+    ./tomx

-   rm -f ./tomx
-   sh tomx.c              
-   ./tomx
+If sh is your shell:

-    If sh is your shell:
+    rm -f ./tomx
+    chmod +x ./tomx.c
+    ./tomx.c
+    ./tomx

-   rm -f ./tomx
-   chmod +x ./tomx.c
-   ./tomx.c 
-   ./tomx
+### Also try:

-    Also try:
+    rm -f ./tomx
+    make -f tomx.c
+    ./tomx

-   rm -f ./tomx
-   make -f tomx.c
-   ./tomx

-    Polyglots have come and gone, but this was the first one we'd seen
-    where one language *used* another to perform its tasks.  An interesting
-    approach.  Admittedly, it's not all that obfuscated - but there's more
-    to it than you might think, since you have to make sure that your
-    changes don't change the shell code or the makefile.
+### Selected Judges Remarks

+Polyglots have come and gone, but this was the first one we'd seen
+where one language *used* another to perform its tasks.  An interesting
+approach.  Admittedly, it's not all that obfuscated - but there's more
+to it than you might think, since you have to make sure that your
+changes don't change the shell code or the makefile.

Should I commit that also?

Sure.

I will do that when I'm working on the Y2K problems i.e. the entries for 2000! :-)

[xexyl]

Low priority question

In the FAQ you have:

1988/phillipps
Unbeaten for 12 years and counting...

Should the number of years be updated by now ? :-)

[xexyl]

Should I commit that also?

Sure.

I will do that when I'm working on the Y2K problems i.e. the entries for 2000! :-)

I ended up doing it in commit 517e936b6379cbef1c0ea2cf68106540e540719a after all .. before I work on Y2K :-)

[xexyl]

Question for you. Is the 'the the' intentional in these files?

1992/rules:145:       We will attempt to email a confirmation to the the first author for
1993/guidelines:411:    AI progs!) If you need tell the the something, put it in the
1993/rules:166:       We will attempt to email a confirmation to the the first author for
1994/guidelines:495:    not AI progs!) If you need tell the the something, put it in          |
2001/guidelines:787:    Sometime after the initial announcement, and once the the review by            |
2001/herrmann1/herrmann1.gcd:38:/* The state "st_next_iteration" means the the turing machine
2004/guidelines:495:    Sometime after the initial announcement, and once the the review
2005/guidelines.txt:502:    Sometime after the initial announcement, and once the the review
2006/guidelines.txt:505:    Sometime after the initial announcement, and once the the review
2011/guidelines.txt:541:    Sometime after the initial announcement, and once the the review
2012/guidelines.txt:651:    Sometime after the initial announcement, and once the the review
2013/guidelines.txt:728:    Sometime after the initial announcement, and once the the review
2014/guidelines.txt:743:    Sometime after the initial announcement, and once the the review
2015/guidelines.txt:809:    Sometime after the initial announcement, and once the the review
2018/guidelines.txt:895:    Sometime after the initial announcement, and once the the review
2019/guidelines.txt:903:    Sometime after the initial announcement, and once the the review
2020/guidelines.txt:938:    Sometime after the initial announcement, and once the the review

No, it is a typo.

Fixed in commit f1af89b1f75b446bccbdb01e0f2b16fe7fcf47b1.

turing and fibonacci were fixed in commit 0c2a0a471d34196dcc093e16d46a0017188b4cd4 .. with some places where it should not be done.

And that's all I'm doing today. Off to do other things. Well I want to do more which is good but I don't think I should and although I want to move ahead with this I also don't - want to take it easy to start recovering after a long day yesterday. Very very good day but very very long.

Tomorrow I should be able to do more.

[lcn2]

We believe we have addressed all of the current questions that still need answering at this time. If we've missed something important or something else needs to be clarified, please ask again.

We are going to try and focus on critical path tasks now and return to addressing comments after we make useful progress on such tasks.

[xexyl]

QUESTION

Interesting. On the ioccc website under A is for atoi it has:

Someone Anonymous Most Diffused Reaction (2015/endoh1/endoh1.c)

... but Yusuke Endoh is hardly anonymous and that entry is even under his name. Surely this should be deleted from the A section if it's still here?

[lcn2]

QUESTION

Interesting. On the ioccc website under A is for atoi it has:

Someone Anonymous

Most Diffused Reaction (2015/endoh1/endoh1.c)

... but Yusuke Endoh is hardly anonymous and that entry is even under his name. Surely this should be deleted from the A section if it's still here?

It was originally submitted as anonymous but later was changed. However the web site was never moved / updated. Please update this repo to be under E instead.

[xexyl]

QUESTION

Interesting. On the ioccc website under A is for atoi it has:

Someone Anonymous

Most Diffused Reaction (2015/endoh1/endoh1.c) ... but Yusuke Endoh is hardly anonymous and that entry is even under his name. Surely this should be deleted from the A section if it's still here?

It was originally submitted as anonymous but later was changed. However the web site was never moved / updated. Please update this repo to be under E instead.

I figured that's what happened.

Will do.

[xexyl]

One might think each winner's entries should be in chronological order too. Maybe you can address that when you write the tool?

For instance mine are:

Best use of weasel words (2018 ferguson) Most enigmatic (2020 ferguson2) Don't tread on me award (2020 ferguson1)

... but note the last two: ferguson2 comes after ferguson1. Why? Others are like that too (first noticed it with Endoh).

Made the fix with Endoh and will do a pull request in a moment. Then I'll be doing something else. Afraid I don't feel up to doing anything here today.

UPDATE 0

See https://github.com/ioccc-src/temp-test-ioccc/pull/19/commits/c31f4bb682c3ed85fa2a5a94b3b2352beebce271.

This does skew my statistics I generated the other day though :(

[lcn2]

One might think each winner's entries should be in chronological order too. Maybe you can address that when you write the tool?

Agreed.

The order probably came about due to something odd that happened in the past that was never corrected.

[xexyl]

One might think each winner's entries should be in chronological order too. Maybe you can address that when you write the tool?

Agreed.

The order probably came about due to something odd that happened in the past that was never corrected.

Just thought I'd bring it up in case it was not known.