Landon Curt Noll
7712db4a17
Given how problematic leading tabs in markdown files can be,
we have expanded all leading tabs in markdown files by:
```sh
find * -type f -name '*.md' -print |
while read -r file; do
rm -f "$file.tmp" ;
expand < "$file" > "$file.tmp" ;
mv -f -v "$file.tmp" "$file" ;
done
```
Given the previous changes to `bin/pandoc-wrapper.sh` and other recent
commits and recent pull requests, the were were **NO** changes to
any HTML files. This is a **good thing** as the expression goes.
No there are no leading tabs in any markdown files.
A check to catch any re-introduction of leading tabs
into any markdown file is on the way.
BTW: We do not have anything against leading tabs in files,
even though we have had to deal with their impact on forming
HTML from markdown files (as well as the calc source code).
It is just that this is one of those cases where tabs conflict
(sometimes caused by people wanting to change the classic
8-space tab model) with a desired outcome.
Perform `make www` to perform the above and test under macOS.
To build:
make
Bugs and (Mis)features:
The current status of this entry is:
STATUS: INABIAF - please DO NOT fix
For more detailed information see 2013/dlowe in bugs.html.
To use:
./dlowe [number...]
where [number...] is one or more number, space separated.
Try:
./try.sh
What is different about the above if you do something like:
echo 'IOCCC winning entry 2013/dlowe' > ioccc.txt
./try.sh
rm -f ioccc.txt
?
To make it simpler to see try showing just the different line like:
./diff.sh
Judges' remarks:
We liked how this entry used Unicode, specifically UTF-8, in a somewhat obfuscated way.
Also, why doesn't it crash but instead produces a correct output when called with one argument or when all arguments are equal?
For extra fun, compile and run fun.c:
#include <stdio.h>
int main() {
printf("%d %d %d\n", (int)(-1.0/0.0), (int)(0.0/0.0), (int)(1.0/0.0));
}
with gcc and clang.
With GCC (4.7.2), we get
-2147483648 -2147483648 -2147483648
and with clang (3.3), we get
-2147483648 0 2147483647
and with Apple clang version 15.0.0 (clang-1500.0.40.1) in 2023, we get:
1840985120 -2033041452 35979112
Which one is correct? :)
NOTE: make all will compile fun.c but to provide a different compiler
you can do something like:
make CC=clang fun
Author's remarks:
sparkl
A tiny implementation of command-line sparkline data visualization.
Synopsis
$ ./sparkl 0 1 2 3 4 5 6 7
▁▂▃▄▅▆▇▉
$ echo "sparkline of file lengths: $(wc -c * | awk '{print $1}' | xargs ./sparkl)"
sparkline of file sizes: ▁▁▁▃▃▂▁▂▁▁▉
NOTE: this has been provided in slflen.sh so you can try:
./slflen.sh
instead (which try.sh also uses).
Description
This is a handy little tool for visualizing numeric series from the
command line, using sparklines. Pass it a numeric series as arguments, and
sparkl will display a sparkline graph, which you can use to very quickly get a
sense of the shape of your data.
Limitations
- Crashes with 0 arguments. It'd be trivial to fix, but adds a few bytes to the code.
- Produces bogus graphs when given > about 5000 arguments.
- Only works if your terminal is UTF-8 and your font supports the 8 glyphs used.
- Produces a few harmless compiler warnings.
Obfuscation
The code is very terse. I was torn between submitting this version, and a
one-line version compressed using a couple more -D flags.
Hand-rolled UTF-8 sequence, magic numbers (what's that 7 for?), meaningless variable names, reused variables, and so on.
Acknowledgements
Edward Tufte invented sparklines (among other things.) Brilliant.
Zach Holman's 'spark' utility was absolutely an inspiration.
As I was writing up this description, I discovered I'm not the first person to write an obfuscated C sparkline utility! Vicent Martí created this one years (!) ago. (My implementation is completely independent.)