mirror/ioccc
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #266 from xexyl/2019-ciura

Browse Source 
Fixes in 2019/ciura + update to bugs.md
This commit is contained in:
Landon Curt Noll authored and GitHub committed 2023-04-03 08:49:06 -07:00
2 parents b6d27f286b 227f02a65f
commit f9f9158fa1
7 files changed
+135 -75
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

2019/ciura/README.md
+61 -46
View File
@@ -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.
How many different ways can this be done?
A few letters, one at a time, with no repeats. How many different ways can this
be done?
While a quick brown fox might jump over the lazy dog,
it has too many repeat letters to allow this entry to repeat.
It is better that Mr Jock, TV quiz PhD, bags few lynx.
While a quick brown fox might jump over the lazy dog, it has too many repeat
letters to allow this entry to repeat. It is better that Mr Jock, TV quiz PhD,
bags few lynx.
Speaking of jumping, can you rewrite the code to
remove all of the goto jumps in this code?
Speaking of jumping, can you rewrite the code to remove all of the goto jumps in
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
qualm fjord wiz pyx vs beg kc nth
quartz jinx vs fed kc womb glyph
quid jamb fez vs pyx kc growl nth
quiz fjord pyx vs bag kc mewl nth
quiz fjord pyx vs gab kc mewl nth
quiz fjord pyx vs gem bawl kc nth
quiz fjord pyx vs meg bawl kc nth
quiz fjord vex bawl kc gyp ms nth
quiz jamb flex vs kc gyp word nth
quiz jamb pyx vs kc flog drew nth
quiz jamb pyx vs kc frog lewd nth
quiz jamb pyx vs kc frog weld nth
quiz jamb pyx vs kc golf drew nth
quiz jamb pyx vs kc grew fold nth
quiz jamb pyx vs kc grow nth fled
quiz jamb pyx vs kc growl fed nth
```sh
$ grep .. /usr/share/dict/words | ./prog abcdefghijklmnopqrstuvwxyz
qualm fjord wiz pyx vs beg kc nth
quartz jinx vs fed kc womb glyph
quid jamb fez vs pyx kc growl nth
quiz fjord pyx vs bag kc mewl nth
quiz fjord pyx vs gab kc mewl nth
quiz fjord pyx vs gem bawl kc nth
quiz fjord pyx vs meg bawl kc nth
quiz fjord vex bawl kc gyp ms nth
quiz jamb flex vs kc gyp word nth
quiz jamb pyx vs kc flog drew nth
quiz jamb pyx vs kc frog lewd nth
quiz jamb pyx vs kc frog weld nth
quiz jamb pyx vs kc golf drew nth
quiz jamb pyx vs kc grew fold 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`
outputs a sorted list of unique words in a given language, one per
line. It requires `aspell` with a dictionary for _LANGUAGE_CODE_.
- [getwords.sh](getwords.sh)
`wrapprog.py LETTERS [N]`
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.
`./getwords.sh LANGUAGE_CODE`
`de.sh`, `en.sh`, `fr.sh`, `it.sh`, `pl.sh`,
and `ru.sh` output German, English, French, Italian, Polish,
and Russian perfect pangrams, respectively. They require a UTF-8
locale.
outputs a sorted list of unique words in a given language, one per line. It
requires `aspell` with a dictionary for _LANGUAGE_CODE_.
### 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
`prog.c` without warnings in C11 and C99 mode. For a clean
With the supplied [Makefile](Makefile), both `gcc` and `clang` compile
[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 -1
View File
@@ -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
+5 -5
View File
@@ -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 \
| aspell --lang=$1 expand \
| tr ' ' '\n' \
| sort -u
LC_ALL=C aspell --lang="$1" dump master \
| LC_ALL=C aspell --lang="$1" expand \
| LC_ALL=C tr ' ' '\n' \
| LC_ALL=C sort -u
2019/ciura/it.sh
+1 -1
View File
@@ -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 -1
View File
@@ -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 -1
View File
@@ -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
+65 -20
View File
@@ -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 per fix, please!
request](https://github.com/ioccc-src/temp-test-ioccc/pulls) (with ONE PULL
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
below for more information. If an entry has more than one status it means that
either they all apply or they compliment each other. For instance
Entries below have one or more of the following _**STATUS**_ values. Please see
the text below for more information. If an entry has more than one status it
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
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. 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 ? :-) ).
to fix the warnings will actually introduce bugs! Other times 'fixing' them will
break the entry (see below).
## 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
formatting code.
experienced this many times with vim so he tends to disable all format options
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!