diff --git a/1992/rules b/1992/rules index 3448becf3..b98cfbeb4 100644 --- a/1992/rules +++ b/1992/rules @@ -142,7 +142,7 @@ into a file named is 'prog.c'. The resulting file must follow rule #2. If possible, we request that you hold off on emailing your entries until 1-Mar-92 0:00 UTC. Early entries will be accepted, however. - We will attempt to email a confirmation to the the first author for + We will attempt to email a confirmation to the first author for all entries received after 1-Mar-92 0:00 UTC. 9) Each person may submit up to 8 entries per contest year. Each entry diff --git a/1993/guidelines b/1993/guidelines index 052757211..da4229569 100644 --- a/1993/guidelines +++ b/1993/guidelines @@ -408,7 +408,7 @@ end With the exception of the header, all text outside of the entry format may be ignored. That is, don't place text outside of the entry and expect the judges to see it. (Our decoding tools aren't - AI progs!) If you need tell the the something, put it in the + AI progs!) If you need tell the something, put it in the ---remark--- section, or send an email to the judges at: ...!{apple,pyramid,sun,uunet}!hoptoad!judges (not the address for diff --git a/1993/rules b/1993/rules index e40e6a799..3d342dcd8 100644 --- a/1993/rules +++ b/1993/rules @@ -163,7 +163,7 @@ into a file named is 'prog.c'. The resulting file must follow rule #2. If possible, we request that you hold off on emailing your entries until 1-Mar-93 0:00 UTC. Early entries will be accepted, however. - We will attempt to email a confirmation to the the first author for + We will attempt to email a confirmation to the first author for all entries received after 1-Mar-93 0:00 UTC. 9) Each person may submit up to 8 entries per contest year. Each entry diff --git a/1994/guidelines b/1994/guidelines index 4ca31c2e6..f8d612f75 100644 --- a/1994/guidelines +++ b/1994/guidelines @@ -492,7 +492,7 @@ end With the exception of the header, all text outside of the entry format may be ignored. That is, don't place text outside of the entry and expect the us to see it. (Our decoding tools are | - not AI progs!) If you need tell the the something, put it in | + not AI progs!) If you need tell the something, put it in | the ---remark--- section, or send an email to the us at: | ...!{apple,pyramid,sun,uunet}!hoptoad!judges (not the address for diff --git a/2000/tomx/README.md b/2000/tomx/README.md index c2dba0630..ae5b4ce8c 100644 --- a/2000/tomx/README.md +++ b/2000/tomx/README.md @@ -1,4 +1,4 @@ -Most Complete Program: +# Most Complete Program: Thomas P John Mishybi Plamoottil @@ -9,106 +9,109 @@ Most Complete Program: http://tomx.tripod.com/ -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 - - 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. + rm -f ./tomx + make -f tomx.c + ./tomx -Selected Author's Comments: +### Selected Judges Remarks - Summary - ------- - This program works as a C source file, a Makefile and also as a - Shell (/bin/sh) script. But unlike some other multi-language prog- - rams, this one is NOT meant to print "Hello, world" in all 3 cases - (At least in the true sense ;-)). The C, make and shell code build - upon each other to create a C program (?) which when executed as a - shell script will compile itself through the C compiler using a - makefile! - Pretty useful, Eh?. +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. - Probably, this is the first entry ever to fully satisfy Rule #1 - ("Your entry must be a complete program") in the strictest sense;-) - Top 5 reasons (IMHO) why this code is an entry for IOCCC - -------------------------------------------------------- - 1. A glance at the source itself will tell U that most of the - Obfuscation is NOT in the C code per se, but in the comments - to the C code. (But sadly, I could not find an "International - Obfuscated C COMMENT contest". So I HAD to sent this entry - here to the IOCCC itself). +### Selected Author's Comments: - 2. Of the 3 languages in the source, the least obfuscated is - C (But again, there was NO obfuscated make/shscript contest) - (Does this hint for a rule in IOCCC-2001 that the major - obfuscation should be in C and not elsewhere???. Mmmmm...) +### Summary - 3. Extending Argument #2... Obfuscation done in the C code - (comments?) create obfuscated code for the other 2 languages. - This opens new possibilities to be explored in depth in future - IOCCCs +This program works as a C source file, a Makefile and also as a +Shell (/bin/sh) script. But unlike some other multi-language prog- +rams, this one is NOT meant to print "Hello, world" in all 3 cases +(At least in the true sense ;-)). The C, make and shell code build +upon each other to create a C program (?) which when executed as a +shell script will compile itself through the C compiler using a +makefile! - Pretty useful, Eh?. - 4. LOOKS like a makefile, WORKS like a shell script and COMPILES - like a C program +Probably, this is the first entry ever to fully satisfy Rule #1 +("Your entry must be a complete program") in the strictest sense;-) - 5. Does something useful (See Notes #1, #2) +### Top 5 reasons (IMHO) why this code is an entry for IOCCC - Notes - ----- - 1. The program could have been something other than the simple - "Hello, world" program that it is. It is possible to do - #include "prog2.c" in the place of the main(), leaving the - complexities of the C file elsewhere and making this source - still acceptable to "make" and "sh". The following modif- - ication to the last few lines will compile IOCCCs famous - "mkentry.c" +1. A glance at the source itself will tell you that most of the + Obfuscation is NOT in the C code per se, but in the comments + to the C code. (But sadly, I could not find an "International + Obfuscated C COMMENT contest". So I HAD to send this entry + here to the IOCCC itself). - .PHONY: /* true clean */ - #undef true - #include "mkentry.c" +2. Of the 3 languages in the source, the least obfuscated is + C (But again, there was NO obfuscated make/shscript contest) + (Does this hint for a rule in IOCCC-2001 that the major + obfuscation should be in C and not elsewhere???. Mmmmm...). - Ain't that useful? +3. Extending Argument #2... Obfuscation done in the C code + (comments?) create obfuscated code for the other 2 languages. + This opens new possibilities to be explored in depth in future + IOCCCs. - 2. By extending this program's idea, It is possible to do some - very interesting things like generating C code on execution - by adding additional code in make/sh (open up a loop????). - This opens the possibilities of generating & compiling some - [obfuscated?] C code.(Maybe should try this if this program - fails at IOCCC 2000) +4. LOOKS like a Makefile, WORKS like a shell script and COMPILES + like a C program. - 3. Changing the "%:%.c" dependency to a "$(PROG):$(PROG).c" form - can compile this program with some other make-s (I got it to - work in Windows using nmake and Gnuwin32's sh ;-) +5. Does something useful (See Notes #1, #2). - 4. Interesting things to do: try "$ ./tomx.c clean". This will - do the same as "make clean" :-)). Also: "$ ./tomx.c all" - 5. Be careful about the Tabs in the source code. Removing them - or converting Tabs to spaces can be disasterous +### Notes + +1. The program could have been something other than the simple "Hello, world" +program that it is. It is possible to do `#include "prog2.c"` in the place of +the main(), leaving the complexities of the C file elsewhere and making this +source still acceptable to "make" and "sh". The following modification to the +last few lines will compile the IOCCC's famous `mkentry.c`. + + + .PHONY: /* true clean */ + #undef true + #include "mkentry.c" + + + Ain't that useful? + +2. By extending this program's idea, It is possible to do some +very interesting things like generating C code on execution +by adding additional code in make/sh (open up a loop????). +This opens the possibilities of generating & compiling some +[obfuscated?] C code. (Maybe should try this if this program +fails at IOCCC 2000) + +3. Changing the `%:%.c` dependency to a `$(PROG):$(PROG).c` form +can compile this program with some other `make`s (I got it to +work in Windows using nmake and Gnuwin32's sh ;-) + +4. Interesting things to do: try `./tomx.c clean`. This will +do the same as `make clean` :-)). Also: `./tomx.c all` + +5. Be careful about the Tabs in the source code. Removing them +or converting Tabs to spaces can be disastrous. diff --git a/2001/guidelines b/2001/guidelines index e8f762fc5..1b081db27 100644 --- a/2001/guidelines +++ b/2001/guidelines @@ -784,7 +784,7 @@ ANNOUNCEMENT OF WINNERS: the winning authors are given a chance to review the judges comments, | and test our Makefile. This review process typically takes a few weeks. | | - Sometime after the initial announcement, and once the the review by | + Sometime after the initial announcement, and once the review by | the winners has been completed (perhaps Feb or Mar 2002), the winning | source will be posted to the IOCCC web site: | | diff --git a/2001/herrmann1/herrmann1.c b/2001/herrmann1/herrmann1.c index 4466a2881..9afde94c5 100644 --- a/2001/herrmann1/herrmann1.c +++ b/2001/herrmann1/herrmann1.c @@ -51,7 +51,7 @@ q D H y ## z d c 0 & 0 d R i W v d B Initializing... -d L V /* the turing */ +d L V /* the Turing */ d M Y(O)/* state to */ d S(x) T(O,1, start ##x) #else diff --git a/2001/herrmann1/herrmann1.gcd b/2001/herrmann1/herrmann1.gcd index a81f70034..0e42be4ec 100644 --- a/2001/herrmann1/herrmann1.gcd +++ b/2001/herrmann1/herrmann1.gcd @@ -35,7 +35,7 @@ #define st13_I I, right, st13 #define st14_O O, left , st_next_iteration #define st14_I O, right, st14 -/* The state "st_next_iteration" means the the turing machine +/* The state "st_next_iteration" means the Turing machine is about to do the next iteration of the Euklid algorithm. (That is, during that state, there are two numbers on the tape with the same gcd as the initial numbers.) */ diff --git a/2001/herrmann1/herrmann1.sh b/2001/herrmann1/herrmann1.sh old mode 100644 new mode 100755 diff --git a/2004/guidelines b/2004/guidelines index bf66f25e2..e43e78a13 100644 --- a/2004/guidelines +++ b/2004/guidelines @@ -492,7 +492,7 @@ ANNOUNCEMENT OF WINNERS: the winning authors are given a chance to review the judges comments, and test our Makefile. This review process typically takes a few weeks. - Sometime after the initial announcement, and once the the review + Sometime after the initial announcement, and once the review by the winners has been completed, the winning source will be posted to the IOCCC web site: diff --git a/2005/guidelines.txt b/2005/guidelines.txt index 6a657459b..cb4158b3d 100644 --- a/2005/guidelines.txt +++ b/2005/guidelines.txt @@ -499,7 +499,7 @@ ANNOUNCEMENT OF WINNERS: the winning authors are given a chance to review the judges comments, and test our Makefile. This review process typically takes a few weeks. - Sometime after the initial announcement, and once the the review + Sometime after the initial announcement, and once the review by the winners has been completed, the winning source will be posted to the IOCCC web site: diff --git a/2006/guidelines.txt b/2006/guidelines.txt index e7fcd9378..35e45c59d 100644 --- a/2006/guidelines.txt +++ b/2006/guidelines.txt @@ -502,7 +502,7 @@ ANNOUNCEMENT OF WINNERS: the winning authors are given a chance to review the judges comments, and test our Makefile. This review process typically takes a few weeks. - Sometime after the initial announcement, and once the the review + Sometime after the initial announcement, and once the review by the winners has been completed, the winning source will be posted to the IOCCC web site: diff --git a/2011/guidelines.txt b/2011/guidelines.txt index 9aba15035..1b83e052a 100644 --- a/2011/guidelines.txt +++ b/2011/guidelines.txt @@ -538,7 +538,7 @@ ANNOUNCEMENT OF WINNERS: the winning authors are given a chance to review the judges comments, and test our Makefile. This review process typically takes a few weeks. - Sometime after the initial announcement, and once the the review + Sometime after the initial announcement, and once the review by the winners has been completed, the winning source will be posted to the IOCCC web site: diff --git a/2012/guidelines.txt b/2012/guidelines.txt index bb0b51d0b..ed80fc705 100644 --- a/2012/guidelines.txt +++ b/2012/guidelines.txt @@ -648,7 +648,7 @@ ANNOUNCEMENT OF WINNERS: the winning authors are given a chance to review the judges comments, and test our Makefile. This review process typically takes a few weeks. - Sometime after the initial announcement, and once the the review + Sometime after the initial announcement, and once the review by the winners has been completed, the winning source will be posted to the IOCCC web site: diff --git a/2013/guidelines.txt b/2013/guidelines.txt index 9915f2acc..dfa890ddf 100644 --- a/2013/guidelines.txt +++ b/2013/guidelines.txt @@ -725,7 +725,7 @@ ANNOUNCEMENT OF WINNERS: the winning authors are given a chance to review the judges comments, and test our Makefile. This review process typically takes a few weeks. - Sometime after the initial announcement, and once the the review + Sometime after the initial announcement, and once the review by the winners has been completed, the winning source will be posted to the IOCCC web site: diff --git a/2014/guidelines.txt b/2014/guidelines.txt index 7bbb1cec9..3c13554aa 100644 --- a/2014/guidelines.txt +++ b/2014/guidelines.txt @@ -740,7 +740,7 @@ ANNOUNCEMENT OF WINNERS: the winning authors are given a chance to review the judges comments, and test our Makefile. This review process typically takes a few weeks. - Sometime after the initial announcement, and once the the review + Sometime after the initial announcement, and once the review by the winners has been completed, the winning source will be posted to the IOCCC web site: diff --git a/2015/endoh1/prog.c b/2015/endoh1/prog.c index 7255af233..b5fa16a3b 100644 --- a/2015/endoh1/prog.c +++ b/2015/endoh1/prog.c @@ -15,7 +15,7 @@ u[1]=y/2 ;w.send(d.slice(0,x<0?0: 2));x=y=-\ ,lu,lv, z;void*f;typedef unsigned long long l;l*p,t[ 99]={0x67452301,0xEFCDAB89, 0x98BADCFE ,308438* 881,3285377520 },i,j,k ,n,m[204]; -#include /*io*/ /*turing*/ +#include /*io*/ /*Turing*/ void s(){ ; for( k =0;k++<7 * 2 *9;)for(i= 0;++i<127; ) e=d + i* 4 +512*k,1[e] +=(i-u)*(i -u)+(k-v)* (k- v )<20?*e+=UV_DROP:0;}l*q= m, g=1LL<<32; diff --git a/2015/guidelines.txt b/2015/guidelines.txt index f64504800..e59286e88 100644 --- a/2015/guidelines.txt +++ b/2015/guidelines.txt @@ -806,7 +806,7 @@ ANNOUNCEMENT OF WINNERS: the winning authors are given a chance to review the judges comments, and test our Makefile. This review process typically takes a few weeks. - Sometime after the initial announcement, and once the the review + Sometime after the initial announcement, and once the review by the winners has been completed, the winning source will be posted to the IOCCC web site: diff --git a/2018/bellard/README.md b/2018/bellard/README.md index 6e9df4f5d..0d569ebe8 100644 --- a/2018/bellard/README.md +++ b/2018/bellard/README.md @@ -68,7 +68,7 @@ Wikipedia and were resized to a width of 1024 pixels. Warning: the program is not protected against invalid input. The program should be portable on any Unix system. On Windows the line -"_setmode(0, 32768); _setmode(1, 32768);" must be added at the start of +`_setmode(0, 32768); _setmode(1, 32768);` must be added at the start of the main() function to avoid unwanted carriage return characters in the output. diff --git a/2018/burton2/README.txt b/2018/burton2/README.txt new file mode 100644 index 000000000..37a9c8c71 --- /dev/null +++ b/2018/burton2/README.txt @@ -0,0 +1,71 @@ +tac comes with a small suite of support programs to test and validate against. +Untar tests and variations in the same dir as the sources, +or change runtest and unob.sh to look elsewhere for the keyword and test files. + +keywords is a critical file, created from ioccc.kw.freq by mkkeywords. +Only ioccc.kw.freq produces results compatible with iocccsize.c; +however, any of the variations can be used instead: + + mkkeywords c11 > keywords + +unob.sh uses the same input file as mkkeywords to control spaces after keywords. +The script allows an environment variable, KW, to override this. +Use it simply: + + unob.sh prog.c | less + unob.sh -p prog.c | less + KW=c11 unob.sh prog.c | less + +To handle obscure command line defines, use the environment variable DEF: + + DEF="-D'g(o)'='goto o;'" KW=c11 unob.sh -p prog.c | less + +It does an amazingly good job for such a simple script. + +Manifest + +prog.c the reason for this README +keywords the file #included in prog.c, output of mkkeywords +mkkeywords reads one of the files from variations, produces string for prog.c +ioccc.kw.freq keywords used by iocccsize, sorted by frequency in 201x ioccc winners +unob.sh a more robust unobfuscation script; requires variations/c11 in cur dir +tokenfix patches up prog -t output for ::, >>>, ... +src.doc.rot13 the answers, or at least significant help +tac.c more clearly written code, offered as a replacement of iocccsize.c +patch fixes single quotes in iocccsize.c, adds #ifndef, removes "I" +fixed_iocccsize.c iocccsize with patch applied, and nop -c argument added + +tests/* +runtest script to run the tests; ./runtest | diff results - +results results without -k +results.k results with -k; opt=kcrs ./runtest | diff results.k - +test*.c various test cases looking for compatability +iocccbug*.c various test cases demonstrating problems with iocccsize +spotcheck script to test a lot of files vs iocccsize +spotdiff summarize the results of spotcheck, showing only differences +discrepancies text file of the differences found using all the ioccc winning entries + +to test prog: + + runtest | diff - results + opt=kcrs runtest | diff - results.k + find ~/src/obc -type f -a -name "*.c" | xargs spotcheck prog + [ | spotdiff | diff -bw - discrepancies ] + +to test tac: + + prog=tac runtest | diff - results + prog=tac opt=krs runtest | diff - results.k + find ~/src/obc -type f -a -name "*.c" | xargs spotcheck tac + +variations/* as described in the remarks, and in each file below +ansi +c++11 +c++14 +c++98 +c11 +c99 +java8 +kandr +kandr2 +v7unix diff --git a/2018/ferguson/.gitignore b/2018/ferguson/.gitignore index e626c23cc..3eeb2ce5f 100644 --- a/2018/ferguson/.gitignore +++ b/2018/ferguson/.gitignore @@ -1,5 +1,5 @@ +prog prog-simple prog.orig weasel -weasel-simple -prog +weasel-simple \ No newline at end of file diff --git a/2018/ferguson/README.md b/2018/ferguson/README.md index eb2309a4f..a46486ec9 100644 --- a/2018/ferguson/README.md +++ b/2018/ferguson/README.md @@ -119,7 +119,7 @@ from the infamous *UNIX-HATERS Handbook*. **[Winning thoughts](#winning):** What it means to me to win as well as some dedications and thanks. Here too I include a link to a website which will be -dedicated to this entry beyond what will be published on the IOCCC website +dedicated to this entry beyond what will be published on the IOCCC website. [FILES]: FILES [rpm.md]: rpm.md @@ -238,8 +238,14 @@ paragraph; the first sentence in fact: the answer to the judges' question and the definition. Can you get the program to search the primorial prime of 97 without passing in specially? -**On user errors:** if the generation reaches **`SIZE_MAX - 1`** I consider it a -user (or monkey) error; if the user insists on being so petulant as to try such +I was quite proud that when the next contest came the judges removed that +question. Later 2018 and all of 2019 was difficult for me so it was like I won a +second time for the same entry. + +### On user errors + +If the generation reaches **`SIZE_MAX - 1`** I consider it a +user (or monkey) error; if the user insists on being so petulant enough as to try such a ridiculous set of parameters in an attempt to make it be no more successful than a monkey typing *then it shouldn't be any more successful than a monkey; if it by chance reaches the target it's because a monkey could too!* Either way @@ -256,7 +262,7 @@ Fish Theorem*). So although the user might not be a monkey the program makes the assumption that **the user could in fact be a monkey called Eric** *although it isn't insolent enough to say the user is a monkey for certain!* -[genetic algorithm]: http://www.doc.ic.ac.uk/~nd/surprise_96/journal/vol1/hmw/article1.html +[genetic algorithm]: https://web.archive.org/web/20180308131613/http://www.doc.ic.ac.uk/~nd/surprise_96/journal/vol1/hmw/article1.html [2018 guidelines]: http://ioccc.org/2018/guidelines.txt @@ -476,32 +482,38 @@ So in this case I joined the options in the following order: 1. **`-q`** -Quiet output. + Quiet output. + 2. **`-r101`** -Mutation rate 101 (out of range). + Mutation rate 101 (out of range). + 3. **`-r5`** -Mutation rate of 5 but note that during parsing I only print invalid mutation + Mutation rate of 5 but note that during parsing I only print invalid mutation rate (only after parsing do I print the final mutation rate whatever it ends up being); so while it appears there is a bug, showing mutation rate out of range three times, this is expected (given the next one, **`-r101`**). This means here the typewriter was taken from Eric the monkey. + 4. **`-r101`** -Mutation rate to 101: this too is out of range (this is the second mutation rate + Mutation rate to 101: this too is out of range (this is the second mutation rate out of range message). The typewriter returns to Eric. + 5. **`-r1`** -Set mutation rate to 1. Take that typewriter away! + + Set mutation rate to 1. Take that typewriter away! + 6. **`-r`** -Set mutation rate to 0; when there are no valid characters passed to + Set mutation rate to 0; when there are no valid characters passed to **`strtol()`** it should return 0: this is the third message about being out of range. Note here that **`rand()`** returns an **`int`** and **`strtol()`** returns a **`long`** but I compare the return value of **`rand()`** to the @@ -509,9 +521,10 @@ mutation rate; if there are any systems where the widths differ this *shouldn't matter* because of truncation but I do in any case specifically check for **`R < 0 || R > 100`**. Either way the invalid range returns the typewriter to Eric. + 7. **`test`** -Finally I requested it find the string **`test`** (will search for **`TEST`**). + Finally I requested it find the string **`test`** (will search for **`TEST`**). Given that it was a short string it did find the answer relatively quickly, even in monkey mode. diff --git a/2018/ferguson/rpm.md b/2018/ferguson/rpm.md index 3d3dd8a99..fb5cab4f8 100644 --- a/2018/ferguson/rpm.md +++ b/2018/ferguson/rpm.md @@ -1,22 +1,26 @@ -What? Install an IOCCC entry? I realise it seems odd so why did I make a rpm -spec file and why did I hint at building RPMs for others? I can't say precisely; -**certainly I'm under no impression that anyone else will want to use it** *but -the entry was fun enough for me that I actually will* (a number of my programs -over the years are programs I actually install and I already have done so with -this entry). I already have my own RPM repository and initially after having won -I set it up so that I could host the weasel rpm (binary and source) there. At -the same time though I feel the entry belongs on the IOCCC website; that is to -say the only place the raw files should be downloadable from is the IOCCC -website itself. Simon Cooper (the judge who deals with setting up the entries on -the IOCCC website) asked me if there is any real attachment in having the RPM -built as part of the entry and the answer is 'no'. He did suggest too that if -I were to have the RPM hosted on the IOCCC website not only would it place a -burden on me to keep it up to date but it would place a burden on the judges - -in other words he himself. Even if it wasn't a burden to me I agree on the other -part and so I have instead come to the following ideas: +## An RPM: what kind of absolute MADNESS is this ? + +What kind of crazy idea is this? Install an IOCCC entry? I realise it seems odd +(at best) so why did I make a rpm spec file and why did I hint at building RPMs +for others? I can't say precisely; **certainly I'm under no impression that +anyone else will want to use it** *but the entry was fun enough for me that I +actually will* (a number of my programs over the years are programs I actually +install and I already have done so with this entry). + +I already have my own RPM repository and initially after having won I set it up +so that I could host the weasel rpm (binary and source) there. At the same time +though I feel the entry belongs on the IOCCC website; that is to say the only +place the raw files should be downloadable from is the IOCCC website itself. +Simon Cooper (the judge who at the time dealt with setting up the entries on the +IOCCC website) asked me if there is any real attachment in having the RPM built +as part of the entry and the answer is 'no'. He did suggest too that if I were +to have the RPM hosted on the IOCCC website not only would it place a burden on +me to keep it up to date (not that it ever needed to be updated) but it would +place a burden on the judges. This is no longer true with GitHub but anyway +since this was for personal reasons I decided that: -* I will not host the actual source code or scripts on my website; they will +* I would not host the actual source code or scripts on my website; they will remain on the IOCCC website. This will most likely never change; instead I would link to the entry directory so that they remain where they belong: the IOCCC website itself. I have set up an [errata page][] however should there be anything @@ -25,12 +29,14 @@ requiring a fix. * I am keeping the weasel.spec file in the entry as it was part of my submission but I do not explain here how to set up the build environment or how to build a RPM: if you know how to use **`rpmbuild`** then you should be able to -work it out. +work it out. Again that's a crazy idea but again it was there and it was part of +the judges' comments (which I liked a lot) which is yet another reason I kept +it. -* Because I strongly suspect I am the only one who has any desire for actually -installing an IOCCC entry I will not worry about setting up a repository; if I -do set up a repository in the future I will include information on it somewhere -at [https://ioccc.xexyl.net/2018/weasel][]. +* Because I strongly suspect (in other words since I know) I am the only one +who has any desire for actually installing an IOCCC entry I did not do anything +further. Nevertheless more information on my entry can be found at +[https://ioccc.xexyl.net/2018/weasel][]. [errata page]: https://ioccc.xexyl.net/2018/weasel/errata [https://ioccc.xexyl.net/2018/weasel]: https://ioccc.xexyl.net/2018/weasel diff --git a/2018/ferguson/test.sh b/2018/ferguson/test.sh old mode 100644 new mode 100755 diff --git a/2018/ferguson/weasel.1 b/2018/ferguson/weasel.1 index 31c72e249..a33304e3f 100644 --- a/2018/ferguson/weasel.1 +++ b/2018/ferguson/weasel.1 @@ -1,4 +1,4 @@ -.TH weasel 1 "20 February 2018" "weasel" "IOCCC 2018" +.TH weasel 1 "15 February 2023" "weasel" "IOCCC 2018" .SH NAME weasel \- The IOCCC 2018 Implementation of Richard Dawkins's Weasel program .SH SYNOPSIS @@ -187,6 +187,6 @@ find it! .PP <\fBhttps://en.wikipedia.org/wiki/Weasel_program\fP> .PP -<\fBhttp://www.doc.ic.ac.uk/~nd/surprise_96/journal/vol1/hmw/article1.html\fP> +<\fBhttps://web.archive.org/web/20180308131613/http://www.doc.ic.ac.uk/~nd/surprise_96/journal/vol1/hmw/article1.html\fP> .SH AUTHOR Cody Boone Ferguson <\fBweasel@xexyl.net\fP> diff --git a/2018/ferguson/weasel.man b/2018/ferguson/weasel.man index f6e817238..fa3eba94e 100644 --- a/2018/ferguson/weasel.man +++ b/2018/ferguson/weasel.man @@ -1,4 +1,4 @@ -.TH weasel 1 "20 February 2018" "weasel" "IOCCC 2018" +.TH weasel 1 "15 February 2023" "weasel" "IOCCC 2018" .SH NAME weasel \- The IOCCC 2018 Implementation of Richard Dawkins's Weasel program .SH SYNOPSIS @@ -187,6 +187,6 @@ find it! .PP <\fBhttps://en.wikipedia.org/wiki/Weasel_program\fP> .PP -<\fBhttp://www.doc.ic.ac.uk/~nd/surprise_96/journal/vol1/hmw/article1.html\fP> +<\fBhttps://web.archive.org/web/20180308131613/http://www.doc.ic.ac.uk/~nd/surprise_96/journal/vol1/hmw/article1.html\fP> .SH AUTHOR Cody Boone Ferguson <\fBweasel@xexyl.net\fP> diff --git a/2018/guidelines.txt b/2018/guidelines.txt index ad05988ed..d494dd738 100644 --- a/2018/guidelines.txt +++ b/2018/guidelines.txt @@ -892,7 +892,7 @@ ANNOUNCEMENT OF WINNERS: the winning authors are given a chance to review the judges comments, and test our Makefile. This review process typically takes a few weeks. - Sometime after the initial announcement, and once the the review + Sometime after the initial announcement, and once the review by the winners has been completed, the winning source will be posted to the IOCCC web site: diff --git a/2019/guidelines.txt b/2019/guidelines.txt index c7f7e73d4..52051e906 100644 --- a/2019/guidelines.txt +++ b/2019/guidelines.txt @@ -900,7 +900,7 @@ ANNOUNCEMENT OF WINNERS: the winning authors are given a chance to review the judges comments, and test our Makefile. This review process typically takes a few weeks. - Sometime after the initial announcement, and once the the review + Sometime after the initial announcement, and once the review by the winners has been completed, the winning source will be posted to the IOCCC web site: diff --git a/2020/guidelines.txt b/2020/guidelines.txt index d6d0345f6..b53fe98d2 100644 --- a/2020/guidelines.txt +++ b/2020/guidelines.txt @@ -935,7 +935,7 @@ ANNOUNCEMENT OF WINNERS: the winning authors are given a chance to review the judges comments, and test our Makefile. This review process typically takes a few weeks. - Sometime after the initial announcement, and once the the review + Sometime after the initial announcement, and once the review by the winners has been completed, the winning source will be posted to the IOCCC web site: diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index b02ddc8c6..25a94edd4 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -5,7 +5,7 @@ 0. Verify that the IOCCC is open for submissions. 1. If the IOCCC is open, you need to register as a contestant. See: how to enter for how to register. -2. Once you have been registered, you will receive and email message for how to +2. Once you have been registered, you will receive an email message for how to prepare your entries for submission, and how to upload the compressed tarballs to our submission portal. 3. Once the IOCCC closes, @@ -15,8 +15,8 @@ notify the winners via email using their previously registered email address, and upload the winning code to the ioccc-src/winner repo which in turn will cause them to be displayed on the IOCCC winners page. -## Update your winning entry +## Updating your winning entries -If you are an IOCCC winner, you may update your entry (meta-data as well as source code) +If you are an IOCCC winner, you may update your entries (meta-data as well as source code) by using a GitHub pull request against the master branch of the ioccc-src/winner repo. diff --git a/README.md b/README.md index 1ed93628e..699f8a71d 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ ### This is NOT the official IOCCC web site! -Please visit www.ioccc.org for the official IOCCC web. +Please visit www.ioccc.org for the official IOCCC web site. Please do NOT bookmark or link to this [experimental web site](https://ioccc-src.github.io/temp-test-ioccc/). diff --git a/all/summary.txt b/all/summary.txt index fba2d1860..19697f67d 100644 --- a/all/summary.txt +++ b/all/summary.txt @@ -44,7 +44,7 @@ 1989 jar.1 char*_="Hello world.\n"; 1989 jar.2 lisp interpreter, compressed 1989 ovdluhe monkey-typer following template, 'APE' identifiers -1989 paul print fibonacci base 2 by simulating turing machine +1989 paul print Fibonacci base 2 by simulating Turing machine 1989 robison apl-expression interpreter (binary), written in C-- 1989 roemer prints e, script-pi shaped layout, _31415 identifiers 1989 tromp squished tetris diff --git a/bin/sgit b/bin/sgit index 92b2e7478..8cea29174 100755 --- a/bin/sgit +++ b/bin/sgit @@ -1,12 +1,12 @@ #!/usr/bin/env bash # -# sgit - sed -i on all files under git control +# sgit - run sed (by default with -i) on all files under git control # -# usage: sgit -e 'sed command'... -# -# This script will allow one to update files under git control without having to -# come up with a list of files and then passing those to the command. It allows -# for multiple sed commands (all with in-place editing) and multiple globs. +# This script allows one to run sed under git control without having to come up +# with a list of files first and then passing those to the command. +# It allows for multiple sed commands and multiple globs. By default it uses -i +# to edit the file in place (without backup extension) but this can be +# overridden with the -I option. See -h option for all the options. # # DISCLAIMER AND WARNING: this is something of a hack and might be error prone. # It works for what is needed but possibly could be improved. Even so I like it @@ -20,22 +20,36 @@ # - Cody Boone Ferguson (@xexyl) # -export SGIT_VERSION="0.0.2-1 13-02-2023" # format: major.minor.patch-release DD-MM-YYYY +export SGIT_VERSION="0.0.5-1 16-02-2023" # format: major.minor.patch-release DD-MM-YYYY -USAGE="usage: $(basename "$0") [-h] [-V] [-v level] [-e command] +USAGE="usage: $(basename "$0") [-h] [-V] [-v level] [-x] [-I] [-o sed_options] [-s sed] [-e command] -h print help and exit -V print version and exit -v level set verbosity level - -e command append sed command to execute on globs + -x turn on tracing (set -x) + -I disable in place editing + -o sed options (don't pass '-') + -s sed set path to sed + -e command append sed command to to list to execute on globs sgit version: $SGIT_VERSION" +SED="$(type -P sed)" +export SED +export SED_OPTIONS="" +export I_FLAG= export VERBOSITY=0 -export SED_COMMANDS= + +# we need an array for sed commands +declare -a SED_COMMANDS + +# we need to remove ' ' from the IFS! +IFS=$'\t\n' + # parse args # -while getopts :hVv:e: flag; do +while getopts :hVv:xIo:s:e: flag; do case "$flag" in h) echo "$USAGE" 1>&2 exit 2 @@ -45,7 +59,15 @@ while getopts :hVv:e: flag; do ;; v) VERBOSITY="$OPTARG"; ;; - e) SED_COMMANDS="$SED_COMMANDS -e $OPTARG" + x) set -x + ;; + I) I_FLAG="-I" + ;; + o) SED_OPTIONS="-$OPTARG" + ;; + s) SED="$OPTARG" + ;; + e) SED_COMMANDS+=(-e "$OPTARG") ;; :) echo "$0: ERROR: option -$OPTARG requires an argument" 1>&2 echo 1>&2 @@ -62,13 +84,31 @@ shift $(( OPTIND - 1 )); # firewall # check that SED_COMMANDS is not empty! -if [[ -z "$SED_COMMANDS" ]]; then +if [[ -z "${SED_COMMANDS[*]}" ]]; then echo "$(basename "$0"): ERROR: you must specify at least one sed command" 1>&2 echo 1>&2 echo "$USAGE" 1>&2 exit 2 fi +# check that sed is executable +if [[ -z "$SED" ]]; then + echo "$(basename "$0"): ERROR: sed cannot be empty" 1>&2 + echo 1>&2 + echo "$USAGE" 1>&2 + exit 2 +elif [[ ! -f "$SED" ]]; then + echo "$(basename "$0"): ERROR: sed is not a regular file: $SED" 1>&2 + echo 1>&2 + echo "$USAGE" 1>&2 + exit 2 +elif [[ ! -x "$SED" ]]; then + echo "$(basename "$0"): ERROR: sed is not an executable file: $SED" 1>&2 + echo 1>&2 + echo "$USAGE" 1>&2 + exit 2 +fi + # also check number of remaining args if [[ "$#" -eq 0 ]]; then echo "$(basename "$0"): ERROR: you must specify at least one glob" 1>&2 @@ -86,22 +126,22 @@ if [[ "$status" -ne 0 ]]; then fi if [[ $VERBOSITY -gt 1 ]]; then - echo "debug[2]: sed commands: $SED_COMMANDS" 1>&2 + echo "debug[2]: sed commands: ${SED_COMMANDS[*]}" 1>&2 fi -# This is not the best performance because it does this on all files of the glob -# rather than only those files matched by the glob with matching text but it's -# better than it used to be (it used to run git ls-files on the repo for each -# sed command so the more you had the slow it would become as it had to get the -# list of files each time!). +# This might not the best performance because it does this on all files of the +# glob rather than only those files matched by the glob with matching text but +# it's better than it used to be (it used to run git ls-files on the repo for +# each sed command so the more you had the slow it would become as it had to get +# the list of files each time!). # # A better approach would be to somehow use git grep to find files that match # but this would complicate the command line (at least in anyway I can think of # how to do it) so we do it on all files in the repo. # # But these would possibly require additional args to the command and -# unnecessarily complicate matters. Anyway it's a hack so it doesn't have to be -# perfect (not that there even is such a thing as perfect). +# unnecessarily complicate matters. Anyway it's something of a hack so it +# doesn't have to be perfect (not that there even is such a thing as perfect). # if [[ "$VERBOSITY" -gt 1 ]]; then echo "debug[2]: looping through all globs" 1>&2 @@ -112,12 +152,34 @@ while [[ "$i" -le "$#" ]]; do echo "debug[2]: found glob: $1" 1>&2 fi if [[ "$VERBOSITY" -ge 1 ]]; then - echo "debug[1]: about to run: git ls-files $1 | xargs sed -i '' $SED_COMMANDS" 1>&2 + if [[ -z "$I_FLAG" ]]; then + if [[ -n "$SED_OPTIONS" ]]; then + echo "debug[1]: about to run: git ls-files $1 | xargs $SED -i\"\" $SED_OPTIONS ${SED_COMMANDS[*]}" 1>&2 + else + echo "debug[1]: about to run: git ls-files $1 | xargs $SED -i\"\" ${SED_COMMANDS[*]}" 1>&2 + fi + else + if [[ -n "$SED_OPTIONS" ]]; then + echo "debug[1]: about to run: git ls-files $1 | xargs $SED $SED_OPTIONS ${SED_COMMANDS[*]}" 1>&2 + else + echo "debug[1]: about to run: git ls-files $1 | xargs $SED ${SED_COMMANDS[*]}" 1>&2 + fi + fi + fi + + if [[ -z "$I_FLAG" ]]; then + if [[ -n "$SED_OPTIONS" ]]; then + git ls-files "$1" | xargs "$SED" -i"" "$SED_OPTIONS" "${SED_COMMANDS[@]}" + else + git ls-files "$1" | xargs "$SED" -i"" "${SED_COMMANDS[@]}" + fi + else + if [[ -n "$SED_OPTIONS" ]]; then + git ls-files "$1" | xargs "$SED" "$SED_OPTIONS" "${SED_COMMANDS[@]}" + else + git ls-files "$1" | xargs "$SED" "${SED_COMMANDS[@]}" + fi fi - # shellcheck disable=SC2086 - # SC2086 (info): Double quote to prevent globbing and word splitting. We can't - # quote this because we need to have word splitting. - git ls-files "$1" | xargs sed -i '' $SED_COMMANDS ((i++)) shift 1 done diff --git a/years.html b/years.html index 05eae0038..a53168074 100644 --- a/years.html +++ b/years.html @@ -273,7 +273,6 @@ Contest @@ -391,7 +382,6 @@ Contest @@ -435,7 +423,6 @@ Contest