Merge pull request #11 from xexyl/updates-post-birthday

Updates post birthday
This commit is contained in:
Landon Curt Noll authored and GitHub committed 2023-02-22 20:44:28 -08:00
commit 7f589b4866
34 files changed
+334 -432

No files matched your search

+1 -1
View File
@@ -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
+1 -1
View File
@@ -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
+1 -1
View File
@@ -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
+1 -1
View File
@@ -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
+83 -80
View File
@@ -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.
+1 -1
View File
@@ -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: |
|
+1 -1
View File
@@ -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
+1 -1
View File
@@ -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.) */
Regular → Executable
View File
File mode changed.
+1 -1
View File
@@ -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:
+1 -1
View File
@@ -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:
+1 -1
View File
@@ -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:
+1 -1
View File
@@ -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:
+1 -1
View File
@@ -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:
+1 -1
View File
@@ -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:
+1 -1
View File
@@ -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:
+1 -1
View File
@@ -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*/ <stdio.h> /*turing*/
#include /*io*/ <stdio.h> /*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;
+1 -1
View File
@@ -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:
+1 -1
View File
@@ -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.
+71
View File
@@ -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
+2 -2
View File
@@ -1,5 +1,5 @@
prog
prog-simple
prog.orig
weasel
weasel-simple
prog
weasel-simple
+24 -11
View File
@@ -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.
+28 -22
View File
@@ -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
Regular → Executable
View File
File mode changed.
+2 -2
View File
@@ -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>
+2 -2
View File
@@ -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>
+1 -1
View File
@@ -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:
+1 -1
View File
@@ -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:
+1 -1
View File
@@ -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:
+3 -3
View File
@@ -5,7 +5,7 @@
0. Verify that the <A HREF="https://www.ioccc.org/index.html#enter">IOCCC is open</A> for submissions.
1. If the IOCCC is open, you need to register as a contestant.
See: <A HREF="https://www.ioccc.org/index.html#enter">how to enter</A> 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 <A HREF="https://www.ioccc.org/index.html#enter">IOCCC</A> closes,
@@ -15,8 +15,8 @@ notify the winners via email using their previously registered email address,
and upload the winning code to the <A HREF="https://github.com/ioccc-src/winner">ioccc-src/winner</A> repo
which in turn will cause them to be displayed on the <A HREF="https://www.ioccc.org/years.html">IOCCC winners page</A>.
## 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 <A HREF="https://github.com/ioccc-src/winner/pulls">GitHub pull request</A>
against the master branch of the <A HREF="https://github.com/ioccc-src/winner">ioccc-src/winner</A> repo.
+1 -1
View File
@@ -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/).
+1 -1
View File
@@ -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
+88 -26
View File
@@ -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'... <glob...>
#
# 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] <glob...>
USAGE="usage: $(basename "$0") [-h] [-V] [-v level] [-x] [-I] [-o sed_options] [-s sed] [-e command] <glob...>
-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
+9 -262
View File
File diff suppressed because it is too large. Load diff