This is a HUGE commit:
417 files changed, 874 insertions(+), 874 deletions(-)
As the IOCCC website now is https enabled I have updated the
'http://www.ioccc' to 'https://www.ioccc'.
There was also a typo in Makefiles where it said 'for VERY WELCOME' when
it should be 'are VERY WELCOME'.
Finally slashdot.org is also https enabled so references to
'http://slashdot' were changed to 'https://slashdot'.
This was done by my sgit tool (see https://github.com/xexyl/sgit)
like:
sgit -e 's,http://www.ioccc,https://www.ioccc,g' -e 's/for VERY WELCOME/are VERY WELCOME/g' -e .
but because I didn't have a list of files that should be modified I had
to be careful which files to commit as I had files that were changed but
not ready to be committed. Since I did it in steps, finding typos as I
went along, I actually ran sgit three times but to simplify the above
(and to show that it's possible to do more than one sed command) I made
it all as one. Since I did not have a list of files ahead of time I had
to determine what files to commit, first going through them like:
for j in $(for i in $(git status|grep modified|cut -d: -f2); do \
git grep 'https://www.ioccc' "$i"; done|cut -d: -f1|sort|uniq); \
do git diff "$j"; done|less -r
(I had to pipe through less because of a strange problem with the git
diff which appears to be because of a terminal problem maybe due to the
command above but it was all I could come up with in a very tired head.)
The above and
git status | grep modified:
showed that some C files had been modified which obviously should not be
done so I had to do:
git co '*c'
to undo those changes.
Finally to commit the correct files I did:
for i in $(git status|grep modified|cut -d: -f2); do \
git grep -E 'https://www.ioccc|https://slashdot|are VERY WELCOME' "$i"; \
done |cut -d: -f1|sort|uniq|xargs git commit -v
or so (with any formatting issues or typos here due to typos in the log
due to the terminal (in)sanity issue described).
Best of Show - Most Shrinkable
Don Yang
omoikane@uguu.org
http://uguu.org/
To build:
make
To run:
./akari [ input_file | - ] [ output_file | - ] [even]
Try:
./akari < example.ppm > odd_output.ppm
./akari - - even < example.ppm > even_output.ppm
./akari example.ppm odd_output.ppm
make akari2
cat akari2.c
./akari2 < akari2.c
./akari2 rot13 < akari2.c
make akari3
cat akari3.c
./akari3
make akari4
cat akari4.c
./akari4
You can automate the above by running:
./try.me.sh
Judges' remarks:
Akari is an image downsampling utility that accepts 3 input formats:
-
PGM (netpbm greyscale image.
Akarionly acceptsPGMfiles with the header:P5 <width> <height> 255. Images with extra comments such as the ones produced by GIMP will not be parsed properly. -
PPM (netpbm RGB image). Only
PPMfiles with the headerP6 <width> <height> 255are accepted. -
ASCII art (with end of lines in LF bytes only, not CRLF!)
Anything that is not parsable as PGM or PPM will be downsampled as ASCII art.
Author's remarks:
Akari is an image downsampling utility. She accepts up to 3 arguments:
The first argument is the input image. If it's - or unspecified, Akari
will read from stdin.
The second argument is the output image. If it's - or unspecified,
Akari will write to stdout.
The third argument, if specified, causes Akari to keep even pixels on even
scanlines. By default Akari will
keep odd pixels on odd scanlines.
Examples:
gcc akari.c -o akari
./akari < example.ppm > odd_output.ppm
./akari - - even < example.ppm > even_output.ppm
./akari example.ppm odd_output.ppm
Akari accepts 3 input formats:
- PGM
(netpbm greyscale
image.
Akarionly acceptsPGMfiles with the header:P5 <width> <height> 255. Images with extra comments such as the ones produced by GIMP will not be parsed properly. PPM (netpbm RGB image). OnlyPPMfiles with the headerP6 <width> <height> 255are accepted. - ASCII art (with end of lines in LF bytes only, not CR-LF)
This is useful for decoding some curiously interlaced images, such as the included example.ppm.
Anything that is not parsable as PGM or PPM will be downsampled as
ASCII art. Since the source code is formatted as ASCII art, it's only
natural to try:
./akari akari.c akari2.c
akari2.c is also a valid C program, and accepts up to 1 argument.
By default, this second program reads text from stdin and writes
expanded output to stdout. If the extra argument is specified, the
output text will also pass through a rot13 filter.
gcc akari2.c -o akari2
./akari2 < input.txt > expanded_output.txt
./akari2 rot13 < input.txt > expanded_and_rot13_output.txt
You can combine the two programs together to have just a regular rot13 filter:
./akari2 rot13 < input.txt | ./akari > rot13.txt
Of course, we wouldn't stop with just 2 programs, you can downsample the source again and get yet another C program:
./akari < akari.c | ./akari > akari3.c
We must go deeper:
./akari < akari.c | ./akari | ./akari > akari4.c
akari3.c and akari4.c are still (mostly valid) C programs.
gcc -Wall will output a few warnings, but still produce output
executables. The output executables each print a message to stdout.
It takes quite a bit of skill and obfuscation to interleave a
C program 4 levels deep, it's much easier to interleave something like
a brainf#$% program in a C program, for example. For comparison, a
brainf#$% program is embedded inside akari.c.
Copyright and CC BY-SA 4.0 License:
This file is Copyright (c) 2023 by Landon Curt Noll. All Rights Reserved. You are free to share and adapt this file under the terms of this license:
Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)
For more information, see: https://creativecommons.org/licenses/by-sa/4.0/