By changing the _inventory_order_ of the compressed tarball from
**100000** to **1415926535**, the compressed tarball will land at
the top of the secondary file list and remain still easy to find.
Updated the `manifest.numbers` spreadsheet and rebuilt
the `.entry.json` files.
Added `next/` directory to hold the next IOCCC rules and guidelines.
Added `next/README.md` that `bin/gen-top-html.sh` uses to form
the `next/index.html` file.
Added _Rules and Guidelines_ link to the sidenav bar to link to the
`next/index.html` file.
Added _IOCCC Rules_ as `next/rules.md` that `bin/gen-top-html.sh`
uses to form the `next/rules.html` file.
Added _IOCCC Guidelines_ as `next/guidelines.md` that `bin/gen-top-html.sh`
uses to form the `next/guidelines.html` file.
Changed `bin/gen-top-html.sh` VERSION from "1.2.4 2024-04-13"
to "1.3 2024-04-14".
Prevent `pandoc(1)` from interpreting the commented out language
of a markdown code block as a code class. So a markdown such as:
````
``` <!---sh-->
...
```
````
that produced HTML of the form:
```html
<pre class="<!---sh-->"><code>...</code></pre>
```
will now produce HTML of the form:
```html
<pre><code>...</code></pre>
```
NOTE: Before when the language of a markdown code block
was not commented, the HTML produced by `pandoc(1)` was
oddly indented with extra whitespace on the first line
of the code block. While commenting out the language
of the code block removed some of the odd intending,
it left a weird class in the HTML pre block that
surrounded the HTML code block. This hack prevents
`pandoc(1)` from assigning a class to the HTML pre block.
Changed `in/md2html.sh` VERSION from "1.2.1 2024-04-13"
to "1.3 2024-04-14".
Added `make gen_sitemap` to end of both `make www` and `make
quick_www` in top level Makefile.
Ram `make www` to test under macOS and to perform the above.
**IMPORTANT NOTE**: The current `next/rules.md` and `next/guidelines.md`
are simply the 2020 IOCCC Rules and Guidelines converted into
markdown form. There are **NOT** the Rules and Guidelines that
will be used the IOCCC MOCK, nor the next IOCCC.
TODO: Improve the `bin/gen-status.sh` tool to modify the top of the
`next/rules.md` and `next/guidelines.md` files to keep them
in sync with the _contest_status_ as found in `status.json`.
TODO: Improve the look and feel of the `next/rules.md` and
`next/guidelines.md` markdown files.
To build:
make
To use:
./hou 'expression'
Try:
./try.sh
As the script asks you, what does the last one mean? Can you get it to report a different value? Hint: it's in this file, kind of.
Judges' remarks:
This self-documenting scientific calculator compiles clean with no warnings under the most strict pedantic mode of gcc and clang.
The first example, along with the correct result appears in the source code. What does it mean?
The calculator obeys the precedence rules and allows parenthesis.
./hou '1+2*3'
./hou '(1+2)*3'
What exactly does the text formatting do?
What does this evaluate to in C?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
Self documenting source
Comments would almost be redundant. :-}
The ASCII art is valid C code
... and not just fancy formatted comment removed by the C Pre-processor.
The only multi-byte strings are format strings
The code does not contain some simple string-encoded lookup table for calculator operations.
Example input and output in the source
The example input and output in the C code is significant. Can you find out why?
The button layout
The button layout in the C code is significant ... not just a nice looking layout.
Input parsing
The parser is functionally equivalent to a normal arithmetic parser for all valid inputs. For another fun challenge: try to determine how it parses the command line argument.
Author's remarks:
Obfuscations
This program is designed to be self-documenting. It doesn't just provide an example command line. It also provides the expected output and illustrates all supported functionality using embedded ASCII art.
- A few line numbers are significant and careless beautification will break the program.
- The entire ASCII art is valid code. The preprocessor won't remove any part of it.
- The only strings longer than 1 byte are
printf(3)/sscanf(3)format strings, even after preprocessing. No string-encoded lookup table is used. - The example input and its expected output are both algorithmically significant.
- The button layout is also significant.
- The actual syntax being parsed is not that obvious, despite being functionally equivalent for all correct inputs.
Portability
- This program requires
argvto point to writable memory. It doesn't require the actualargvstrings to be writable, though. - This program requires ASCII.
- This program doesn't work with
%estyle numbers like1e-4. - Some seemingly redundant code works to eliminate warnings and evade a gcc bug.
Spoilers
The parser parses function names, subtraction, and division as single-letter unary operators. A bitmask encoded hash table is used to check no-ops/digits and another hash function maps the ASCII to a function ordinal, which is then executed by the button panel.
Both hash functions were found using a separate search program. Another program was used to find a way to format one hash function as example input such that it produces something resembling the bitmask hash table as part of its output.