Merge pull request #266 from xexyl/2019-ciura

Fixes in 2019/ciura + update to bugs.md

2019/ciura/README.md

@@ -31,7 +31,14 @@ make
 ./ru.sh
 ```
 
-### Alternate code
+[Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) fixed invalid bytes
+error in `tr` in the scripts. He notes that at least on his systems (macOS and
+fedora linux) the alternative languages do not work. Perhaps that is the wrong
+locale or it's unable to come up with perfect pangrams but one will not get
+errors now (it did not work before the fixes either). Thank you Cody for your
+assistance!
+
+### Alternate code:
 
 There is an alternate version of this code that flushes stdout after writing a newline.
 See the Author's comments for more information.
@@ -46,15 +53,15 @@ Use `prog.alt` as you would `prog` above.
 
 ## Judges' comments:
 
-A few letters, one at a time, with no repeats.
+A few letters, one at a time, with no repeats.  How many different ways can this
-How many different ways can this be done?
+be done?
 
-While a quick brown fox might jump over the lazy dog,
+While a quick brown fox might jump over the lazy dog, it has too many repeat
-it has too many repeat letters to allow this entry to repeat.
+letters to allow this entry to repeat.  It is better that Mr Jock, TV quiz PhD,
-It is better that Mr Jock, TV quiz PhD, bags few lynx.
+bags few lynx.
 
-Speaking of jumping, can you rewrite the code to
+Speaking of jumping, can you rewrite the code to remove all of the goto jumps in
-remove all of the goto jumps in this code?
+this code?
 
 ## Author's comments:
 
@@ -65,25 +72,27 @@ written with an alphabet and outputs perfect pangrams composed of these
 words. A perfect pangram is a series of words that contains every letter
 of the alphabet exactly once.
 
-Example execution:
+#### Example execution:
 
-    $ grep .. /usr/share/dict/words | ./prog abcdefghijklmnopqrstuvwxyz
+```sh
-    qualm fjord wiz pyx vs beg kc nth
+$ grep .. /usr/share/dict/words | ./prog abcdefghijklmnopqrstuvwxyz
-    quartz jinx vs fed kc womb glyph
+qualm fjord wiz pyx vs beg kc nth
-    quid jamb fez vs pyx kc growl nth
+quartz jinx vs fed kc womb glyph
-    quiz fjord pyx vs bag kc mewl nth
+quid jamb fez vs pyx kc growl nth
-    quiz fjord pyx vs gab kc mewl nth
+quiz fjord pyx vs bag kc mewl nth
-    quiz fjord pyx vs gem bawl kc nth
+quiz fjord pyx vs gab kc mewl nth
-    quiz fjord pyx vs meg bawl kc nth
+quiz fjord pyx vs gem bawl kc nth
-    quiz fjord vex bawl kc gyp ms nth
+quiz fjord pyx vs meg bawl kc nth
-    quiz jamb flex vs kc gyp word nth
+quiz fjord vex bawl kc gyp ms nth
-    quiz jamb pyx vs kc flog drew nth
+quiz jamb flex vs kc gyp word nth
-    quiz jamb pyx vs kc frog lewd nth
+quiz jamb pyx vs kc flog drew nth
-    quiz jamb pyx vs kc frog weld nth
+quiz jamb pyx vs kc frog lewd nth
-    quiz jamb pyx vs kc golf drew nth
+quiz jamb pyx vs kc frog weld nth
-    quiz jamb pyx vs kc grew fold nth
+quiz jamb pyx vs kc golf drew nth
-    quiz jamb pyx vs kc grow nth fled
+quiz jamb pyx vs kc grew fold nth
-    quiz jamb pyx vs kc growl fed nth
+quiz jamb pyx vs kc grow nth fled
+quiz jamb pyx vs kc growl fed nth
+```
 
 Rearranging the words into more or less meaningful expressions is the
 user's duty.
@@ -94,9 +103,10 @@ Programming_ by Donald E. Knuth. As of June 2019, you can download an
 incomplete draft of the fascicle from [Knuth's
 website](https://www-cs-faculty.stanford.edu/~knuth/fasc5c.ps.gz).
 
-### Usage
+### Usage:
+
+`./prog LETTERS [N]`
 
-`prog LETTERS [N]`
 reads allowed words from standard input and writes perfect pangrams
 with at most _N_ words composed of _LETTERS_ to standard output, one
 per line. If _N_ is not given, the number of words in the pangrams is
@@ -106,25 +116,30 @@ _LETTERS_ must not exceed 97 characters.
 The exit status is 0 if no error occurred, 1 if the input word list
 is too long, and 2 if the command-line arguments are missing.
 
-### Helper scripts
+### Helper scripts:
 
-`getwords.sh LANGUAGE_CODE`
+- [getwords.sh](getwords.sh)
-outputs a sorted list of unique words in a given language, one per
-line. It requires `aspell` with a dictionary for _LANGUAGE_CODE_.
 
-`wrapprog.py LETTERS [N]`
+    `./getwords.sh LANGUAGE_CODE`
-works similarly to `prog LETTERS [N]` except that it merges
-anagrams before passing them to `prog` and expands them in
-`prog`'s output. This way, it finishes the job faster than
-`prog` when there are millions of perfect pangrams. It requires a
-UTF-8 locale.
 
-`de.sh`, `en.sh`, `fr.sh`, `it.sh`, `pl.sh`,
+    outputs a sorted list of unique words in a given language, one per line.  It
-and `ru.sh` output German, English, French, Italian, Polish,
+    requires `aspell` with a dictionary for _LANGUAGE_CODE_.
-and Russian perfect pangrams, respectively. They require a UTF-8
-locale.
 
-### Miscellaneous remarks
+- [wrapprog.py](wrapprog.py)
+
+    `./wrapprog.py LETTERS [N]`
+
+    works similarly to `./prog LETTERS [N]` except that it merges pangrams
+    before passing them to `prog` and expands them in `prog`'s output. This way,
+    it finishes the job faster than `prog` when there are millions of perfect
+    pangrams. It requires a UTF-8 locale.
+
+- [de.sh](de.sh), [en.sh](en.sh), [fr.sh](fr.sh), [it.sh](it.sh),
+[pl.sh](pl.sh), and [ru.sh](ru.sh) output German,
+English, French, Italian, Polish, and Russian perfect pangrams, respectively.
+They require a UTF-8 locale.
+
+### Miscellaneous remarks:
 
 I dare submit this entry to categories _algorithms_,
 _internationalization_ (I have not found active use of `<wchar.h>`
@@ -143,7 +158,7 @@ the example from section [What is this?](#wit) finished in 1.35
 seconds. On the other hand, `prog` can only output series of words
 with non-repeating characters, unlike `klausler`.
 
-In contrast to `prog.alt.c`, `prog.c` does not call
+In contrast to [prog.alt.c](prog.alt.c), [prog.c](prog.c) does not call
 `fflush(stdout)` after outputting each line, thus running faster.
 I am grateful to Witold Jarnicki for suggesting this change.
 The original `prog` finished the example above in 100 minutes
@@ -171,8 +186,8 @@ by without `goto M` and `goto H`, I challenge the adherents of
 structured programming to refactor `goto T`, which jumps back into a
 nested `if` block.
 
-With the supplied `Makefile`, both `gcc` and `clang` compile
+With the supplied [Makefile](Makefile), both `gcc` and `clang` compile
-`prog.c` without warnings in C11 and C99 mode. For a clean
+[prog.c](prog.c) without warnings in C11 and C99 mode. For a clean
 compilation with `gcc -std=c90`, add `-Wno-format` to
 `CSILENCE` in `Makefile`.
 

2019/ciura/de.sh

@@ -1,3 +1,3 @@
 #!/usr/bin/env bash
 set -x
-./getwords.sh de | tr A-ZÄÖÜ a-zäöü | grep .. | ./prog aäbcdefghijklmnoöpqrsßtuüvwxyz
+LC_ALL=C ./getwords.sh de | LC_ALL=C tr '[:lower:]' '[:upper:]'  | LC_ALL=C grep .. | LC_ALL=C ./prog aäbcdefghijklmnoöpqrsßtuüvwxyz

2019/ciura/getwords.sh

@@ -1,12 +1,12 @@
 #!/usr/bin/env bash
 
-if [ "$#" -ne 1 ]; then
+if [[ "$#" -ne 1 ]]; then
     echo "Usage: $0 <language code>"
     echo "Run (aspell dump dicts) to see the available codes."
     exit 2
 fi
 
-aspell --lang=$1 dump master \
+LC_ALL=C aspell --lang="$1" dump master \
-  | aspell --lang=$1 expand \
+  | LC_ALL=C aspell --lang="$1" expand \
-  | tr ' ' '\n' \
+  | LC_ALL=C tr ' ' '\n' \
-  | sort -u
+  | LC_ALL=C sort -u

2019/ciura/it.sh

@@ -2,4 +2,4 @@
 (>&2 echo "Please be patient. Extracting Italian words")
 (>&2 echo "from aspell takes a few minutes.")
 set -x
-./getwords.sh it | grep .. | ./prog aàbcdeèéfghiìlmnoòpqrstuùvz #jkwxy
+LC_ALL=C ./getwords.sh it | LC_ALL=C grep .. | LC_ALL=C ./prog aàbcdeèéfghiìlmnoòpqrstuùvz #jkwxy

2019/ciura/pl.sh

@@ -1,3 +1,3 @@
 #!/usr/bin/env bash
 set -x
-./getwords.sh pl | egrep -v '^[^aiouwz]$' | ./prog aąbcćdeęfghijklłmnńoóprsśtuwyzźż
+LC_ALL=C ./getwords.sh pl | LC_ALL=C grep -vE '^[^aiouwz]$' | LC_ALL= ./prog aąbcćdeęfghijklłmnńoóprsśtuwyzźż

2019/ciura/ru.sh

@@ -1,3 +1,3 @@
 #!/usr/bin/env bash
 set -x
-./getwords.sh ru | ./prog абвгдеёжзийклмнопрстуфхцчшщъыьэюя
+LC_ALL=C ./getwords.sh ru | LC_ALL=C ./prog абвгдеёжзийклмнопрстуфхцчшщъыьэюя

bugs.md

@@ -12,8 +12,8 @@ Can you fix/improve entries not under the INABIAF (it's not a bug it's a
 feature)? You are **VERY WELCOME** to try.
 
 Please submit your fixes fix in a [GitHub pull
-request](https://github.com/ioccc-src/temp-test-ioccc/pulls) with one pull
+request](https://github.com/ioccc-src/temp-test-ioccc/pulls) (with ONE PULL
-request per fix, please!
+REQUEST *PER* FIX, please)!
 
 We will be **happy to credit anyone who submits successful [GitHub pull
 requests](https://github.com/ioccc-src/temp-test-ioccc/pulls)** in the entry's
@@ -25,14 +25,19 @@ If you do fix an entry please feel free to delete the entry from this file!
 Otherwise if you wish to not worry about it we can do that to make sure the
 format is consistent and clean.
 
-Thank you!
+THANK YOU!
 
 ### ON **ALL** FIXES / IMPROVEMENTS / CHANGES
 
 Make **ABSOLUTE CERTAIN** that you test the entry _BEFORE_ **AND** _AFTER_ your
 changes! This includes output and the same input functionality! Sometimes it
 might seem to be fine but is actually not! We will note some where this is known
-to happen (if it's not yet fixed).
+to happen (if it's not yet fixed). This has actually already happened to us.
+Sometimes it is okay: some entries are known to not work but they can still have
+improvements (rarer situation but it's happened). Some might have slightly
+different output but which is not a problem for instance a newline after output
+in [Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson)'s changing it to
+[1994/ldb](1994/ldb/ldb.c) use `fgets()` from `gets()`.
 
 Make **ABSOLUTE CERTAIN** that you read the README.md file _BEFORE_ your changes
 as it's important to see that the code is doing what it is supposed to. In the
@@ -43,12 +48,19 @@ someone who will know e.g. us.
 Make **ABSOLUTE CERTAIN** that you read the next section, the list of statuses
 and the related information, BEFORE you submit a pull request!
 
+**BE VERY AWARE** that sometimes fixing an entry for one platform will break it
+under another so if you have more than one platform (e.g. macOS and linux) it
+would be wise to test it under all that you have access to. Otherwise we can do
+that. Of course if the entry does not work under any platform and you fix it for
+one that's more than fine (and it has been done numerous times).
+
+Again, THANK YOU!
 
 # LIST OF STATUSES - PLEASE READ BEFORE FIXING (you may skip if you're only interested in knowing about entries with known issues)
 
-Entries below have one of the following _**STATUS**_ values. Please see the text
+Entries below have one or more of the following _**STATUS**_ values. Please see
-below for more information. If an entry has more than one status it means that
+the text below for more information. If an entry has more than one status it
-either they all apply or they compliment each other. For instance
+means that either they all apply or they compliment each other. For instance
 [2004/gavin](2004/gavin/gavin.c) crashes but it also doesn't even compile with
 some platforms/architectures.
 
@@ -60,21 +72,34 @@ of the remaining entries resolved in the near future but nevertheless if you're
 okay making people very sad you may have a go at the entries :-) He'll remove
 this part later on.
 
-## Compiler warnings are very rarely a problem
+## General notes about the statuses and making fixes
+
+### Compiler warnings are very rarely a problem
 
 In general warnings should NOT be addressed. The only time they should be
 CONSIDERED is when the entry does not work. However note that sometimes trying
-to fix the warnings will actually introduce bugs! Below in some entries we do
+to fix the warnings will actually introduce bugs! Other times 'fixing' them will
-list some warnings that definitely should be ignored (including some introduced
+break the entry (see below).
-by fixes) but we do not list them all: trying to keep track of them all would be
-impractical especially as different compilers give different warnings. Another
-type of warning that would be hard to keep track of is different data sizes on
-different platforms. These tend to be required at the risk that sometimes the
-entry will not work for certain platforms, some of which might or might not be
-fixable. But even if they are fixable (which will likely be hard to do) it's
-almost certain that such code would be just as non-portable (importable ? :-) ).
 
-## Request for one-liners:
+Below in some entries we do list some warnings that definitely should be ignored
+(including some introduced by fixes) but we do not list them all: trying to keep
+track of them all would be impractical especially as different compilers give
+different warnings.
+
+Another type of warning that would be hard to keep track of is different data
+sizes on different platforms.  These tend to be required at the risk that
+sometimes the entry will not work for certain platforms, some of which might or
+might not be fixable; a good example where it was required to change and is okay
+is when [Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) fixed the
+segfault in macOS of [1989/paul](1994/paul/paul.c): changing the `int *` to a
+`long *` was required and it works just as well with linux.
+
+But even if they are fixable (which will likely be hard to do) it's almost
+certain that such code would be just as non-portable (importable ? :-) ).
+
+Hopefully with the example entries listed above you get the idea.
+
+### Request for one-liners:
 
 For one-liners please keep the file one line if at all possible! If it needs an
 include you can update the Makefile `CINCLUDE` variable. For instance if it
@@ -88,8 +113,8 @@ If you make changes PLEASE TRY and keep the source code layout as close to the
 original as possible. This might not always be possible and if you have an
 editor that does formatting it can cause problems. Sometimes formatters can even
 break code! [Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) has
-experienced this many times so he tends to disable all format options when
+experienced this many times with vim so he tends to disable all format options
-formatting code.
+when formatting code.
 
 
 
@@ -950,6 +975,19 @@ but this is expected and the file `ioccc.html` will be generated properly.
 
 # 2019
 
+## [2019/ciura](2019/ciura/prog.c) ([README.md](2019/ciura/README.md))
+## STATUS: known bug - please help us fix
+
+[Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) fixed the scripts so
+that the locale is correct (or at least correct for the commands to be run
+without error, notwithstanding English which isn't a problem) but he notes that
+under both macOS and fedora linux the alternative language scripts don't report
+anything. This happened before and after the fix to the scripts.
+
+Maybe it's the locale or maybe it's the dictionary files but it appears that
+they did work for some. If you can identify the problem we would appreciate the
+help!
+
 
 ## [2019/endoh](2019/endoh/prog.c) ([README.md](2019/endoh/README.md))
 ## STATUS: INABIAF - please **DO NOT** fix
@@ -973,3 +1011,10 @@ things that are misinterpreted as bugs. See his
 # 2022
 
 These years did not have an IOCCC entry.
+
+# Final words
+
+We hope this document was of use to you in determining which entries are known
+to have a problem, what entries are known to have features that are not bugs and
+so on. We also thank you for going through this document and, if you propose any
+fixes via a pull request or otherwise, we thank you as well for the help!