mirror/ioccc
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

force use of pandoc version >= 3.1.12.2

Browse Source 
The `bin/pandoc-wrapper.sh` tool will verify that the ssytem
has a recent enough version of `pandoc(1)`.

We explain why we insist on `pandoc(1)`. version >= 3.1.12.2
in comments where the $PANDOC_MIN_VERSION is set.

Added `--wrap=preserve` as a default argument to `pandoc(1)`.
While this change will impact every HTML file generated,
we believe this will improve the ability of someone to look
at the generated HTML and correlate with the original markdown.

Changed `bin/pandoc-wrapper.sh` VERSION from "1.4.2 2024-03-17"
to "1.4.3 2024-03-18".

Performed `make www` to achieve all of the above and to generate
HTML using the new  `--wrap=preserve` `pandoc(1)` mode.
This commit is contained in:
Landon Curt Noll committed 2024-03-18 01:26:39 -07:00
1 parent 9eb7a54e9f
commit b0b212acb1
402 files changed
+37061 -55132
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

1992/vern/index.html
+79 -110
View File
@@ -130,8 +130,8 @@
<h2 id="author"><a name="author"></a>Author:</h2>
<ul>
<li>Name: <a href="../../authors.html#Vern_Paxson">Vern Paxson</a><br>
Location: <a href="../../location.html#US">US</a> - <em>United States of
America</em> (<em>United States</em>) <br><br></li>
Location: <a href="../../location.html#US">US</a> - <em>United States of America</em> (<em>United States</em>)
<br><br></li>
</ul>
<!-- END: next line ends content generated by: bin/output-index-author.sh -->
@@ -144,8 +144,7 @@ America</em> (<em>United States</em>) <br><br></li>
<h3 id="bugs-and-misfeatures">Bugs and (Mis)features:</h3>
<p>The current status of this entry is:</p>
<pre><code>STATUS: INABIAF - please **DO NOT** fix</code></pre>
<p>For more detailed information see <a
href="../../bugs.html#1992_vern">1992 vern bugs</a>.</p>
<p>For more detailed information see <a href="../../bugs.html#1992_vern">1992 vern bugs</a>.</p>
<h2 id="to-use">To use:</h2>
<div class="sourceCode" id="cb3"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="ex">./vern</span> 3 <span class="co"># &lt;-- default is 2</span></span></code></pre></div>
<h2 id="try">Try:</h2>
@@ -163,155 +162,125 @@ suggested above. :-)</p>
<span id="cb5-3"><a href="#cb5-3" aria-hidden="true" tabindex="-1"></a><span class="ex">65</span> 55</span>
<span id="cb5-4"><a href="#cb5-4" aria-hidden="true" tabindex="-1"></a><span class="ex">66</span> 46</span></code></pre></div>
<p>NOTE: Move values must be restricted to the range 00 to 77.</p>
<p>NOTE: Because some mailers have problems with the original winning
source, a slightly modified version with shorter lines has been
provided.</p>
<p>NOTE: Because some mailers have problems with the original winning source,
a slightly modified version with shorter lines has been provided.</p>
<h2 id="authors-remarks">Author’s remarks:</h2>
<p>This program plays chess. You play the white pieces and the program
the black pieces. Moves are entered as a two-digit number specifying the
coordinates of the piece to be moved followed by another two-digit
number specifying the coordinates of where to move it. Rows and columns
are numbered starting with <code>(0,0)</code> for the upper-left-hand
corner (black’s queen’s rook) and going to <code>(7,7)</code> for the
lower-right-hand corner (white’s king’s rook). For example, the
<code>PK4</code> opening for white is indicated as
<code>"64 44" (without the quotes)</code>. Moves are read using
<code>scanf()</code> so care should be taken to not enter the wrong
number of fields.</p>
<p>This program plays chess. You play the white pieces and the program the black
pieces. Moves are entered as a two-digit number specifying the coordinates of
the piece to be moved followed by another two-digit number specifying the
coordinates of where to move it. Rows and columns are numbered starting with
<code>(0,0)</code> for the upper-left-hand corner (black’s queen’s rook) and going to
<code>(7,7)</code> for the lower-right-hand corner (white’s king’s rook). For example, the
<code>PK4</code> opening for white is indicated as <code>"64 44" (without the quotes)</code>. Moves
are read using <code>scanf()</code> so care should be taken to not enter the wrong number
of fields.</p>
<p>If the move you enter is illegal then you are just prompted again to
move. If the move is legal then the new position is displayed and the
program starts computing its response. For every 64 board positions it
examines a “.” is printed. Once it has chosen its move it simply
displays the board updated to reflect the move.</p>
<p>Your move is prompted for using a string like
<code>"1351 9 2 &gt;"</code>. The first number is how many board
positions the program examined when computing its previous response. The
second number is its anticipated value for the move it just made (with
larger numbers meaning an ultimately better board position for it), and
the third number is the evaluation it assigns to the your current
position (larger numbers meaning better positions for you). A
<code>&gt;</code> indicates that you are not in check; for check it is
changed to <code>!</code>.</p>
<p>Your move is prompted for using a string like <code>"1351 9 2 &gt;"</code>. The first
number is how many board positions the program examined when computing
its previous response. The second number is its anticipated value for
the move it just made (with larger numbers meaning an ultimately better
board position for it), and the third number is the evaluation it
assigns to the your current position (larger numbers meaning better
positions for you). A <code>&gt;</code> indicates that you are not in check; for
check it is changed to <code>!</code>.</p>
<p>There are a few limitations on play:</p>
<ul>
<li>castling can only be done on the king’s side.</li>
<li>prohibitions against castling out of or through check are not
enforced.</li>
<li>prohibitions against castling if the king or rook have moved are not
enforced.</li>
<li>prohibitions against castling out of or through check are not enforced.</li>
<li>prohibitions against castling if the king or rook have moved are not enforced.</li>
<li>pawns are always promoted to queens.</li>
<li>en passant is not allowed.</li>
<li>the board-position-repeated-three-times and fifty-moves stalemates
are not recognized.</li>
<li>the board-position-repeated-three-times and fifty-moves stalemates are not
recognized.</li>
</ul>
<p>If you checkmate the computer it prints “Rats!” and exits. If your
own checkmate is imminent it prints “Har har.” but doesn’t exit so it
can rub your nose in defeat (which may be a move or two away if you’re
<p>If you checkmate the computer it prints “Rats!” and exits. If your own
checkmate is imminent it prints “Har har.” but doesn’t exit so it can
rub your nose in defeat (which may be a move or two away if you’re
playing at a high “ply” - see the next paragraph). Stalemates are not
recognized per se, but when selecting its move the program assigns a
stalemate position a value of 0 so it will try for a stalemate if its
other options are worse.</p>
<p>The program takes one optional argument indicating the ply
(lookahead) it should use. The default is 2, which is enough to keep it
from making flaming blunders. The higher the ply, the better the play,
and the longer you have to wait. For example, at a ply of 2, a response
to the <code>PK4</code> opening takes about 1.8 CPU seconds on a SPARC
ELC when compiled <code>-O</code> with Sun <code>cc</code>. A ply of 3
takes 13 CPU seconds (and results in a different response to
<code>PK4</code>) and a ply of 4 takes a little under 4 CPU minutes (and
for <code>PK4</code> comes up with the same response as a ply of 3). A
ply of 3 is in general good enough to avoid not only flaming blunders
but also immediately stupid moves altogether. A ply of 4 will find all
<p>The program takes one optional argument indicating the ply (lookahead) it should
use. The default is 2, which is enough to keep it from making flaming blunders.
The higher the ply, the better the play, and the longer you have to wait. For
example, at a ply of 2, a response to the <code>PK4</code> opening takes about 1.8 CPU
seconds on a SPARC ELC when compiled <code>-O</code> with Sun <code>cc</code>. A ply of 3 takes 13
CPU seconds (and results in a different response to <code>PK4</code>) and a ply of 4 takes
a little under 4 CPU minutes (and for <code>PK4</code> comes up with the same response as a
ply of 3). A ply of 3 is in general good enough to avoid not only flaming
blunders but also immediately stupid moves altogether. A ply of 4 will find all
mate-in-two’s.</p>
<h3 id="obfuscation">Obfuscation</h3>
<p>This program is obfuscated in a number of ways. First, it abuses the
contest rule regarding ‘;’, ‘{’, and ‘}’ in the source not counting
against the non-whitespace character limit if followed by whitespace. As
can be seen from the build file, certain combinations of these
characters followed by a particular whitespace character are expanded at
build time into much-needed text. Without this hack the program wouldn’t
pass the character limit. A nice side effect is that the initial source
is gloriously difficult to peruse. In particular, the Makefile does:</p>
against the non-whitespace character limit if followed by whitespace.
As can be seen from the build file, certain combinations of these
characters followed by a particular whitespace character are expanded
at build time into much-needed text. Without this hack the program
wouldn’t pass the character limit. A nice side effect is that the
initial source is gloriously difficult to peruse. In particular, the Makefile
does:</p>
<div class="sourceCode" id="cb6"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb6-1"><a href="#cb6-1" aria-hidden="true" tabindex="-1"></a><span class="fu">sed</span> <span class="op">&lt;</span>vern.c <span class="st">&#39;s/{ /(/g;s/} /)/g;s/; /#define /&#39;</span> <span class="kw">|</span> <span class="dt">\</span></span>
<span id="cb6-2"><a href="#cb6-2" aria-hidden="true" tabindex="-1"></a> <span class="fu">sed</span> <span class="st">&#39;s/} /=/g;s/{ /i/g&#39;</span> <span class="op">&gt;</span>vern.tmp.c</span></code></pre></div>
<p>and compiles <code>vern.tmp.c</code>.</p>
<p>Second, the rather ho-hum step has been taking of naming each
variable with a one or two letter identifier to render it meaningless
(and save space). This tactic is rather effective in a complex
program.</p>
<p>Third, the board is represented not as an array of pieces but rather
as an array of function pointers (with a separate array representing
<p>Second, the rather ho-hum step has been taking of naming each variable
with a one or two letter identifier to render it meaningless (and save
space). This tactic is rather effective in a complex program.</p>
<p>Third, the board is represented not as an array of pieces but rather as
an array of function pointers (with a separate array representing
whether a piece is white or black). This obfuscates the program’s
central data structure. There is one function per type of piece; when
called they return 1 if the current move is illegal for that piece and 0
if it is legal. The functions also as a side effect set a global
called they return 1 if the current move is illegal for that piece and
0 if it is legal. The functions also as a side effect set a global
indicating the type of the piece (though the type can also be determined
by comparing the function pointer with the function itself).</p>
<p>Fourth, there are no independent routines for generating potential
moves. Instead, the program generates its moves by brute force: for
every piece it controls on the board, it attempts to move it to every
square on the board. Those moves that are legal it then explores to see
their effects (using <a
href="https://en.wikipedia.org/wiki/Alpha-beta_pruning">alpha-beta
search</a>). This tactic somewhat obfuscates the algorithm used by the
program.</p>
<p>Finally, there are three key constants that occur throughout the
program: <code>64</code>, <code>8</code>, and <code>3</code>
(<code>lg 8</code>). Rather than making these available at compile-time,
<p>Fourth, there are no independent routines for generating potential moves.
Instead, the program generates its moves by brute force: for every piece it
controls on the board, it attempts to move it to every square on the board.
Those moves that are legal it then explores to see their effects (using
<a href="https://en.wikipedia.org/wiki/Alpha-beta_pruning">alpha-beta search</a>). This
tactic somewhat obfuscates the algorithm used by the program.</p>
<p>Finally, there are three key constants that occur throughout the program: <code>64</code>,
<code>8</code>, and <code>3</code> (<code>lg 8</code>). Rather than making these available at compile-time,
which provides a hint as to what the program is up to, they are computed
probabilistically at run-time. An instance of the <a
href="https://en.wikipedia.org/wiki/Renewal_theory#Inspection_paradox">“Inspection
Paradox”</a> is used which happens to produce a value that on average is
close to <code>.64</code>. <code>10000</code> instances of this value
are computed, added up, and then divided by <code>100</code>. Sometimes
the value produced will be <code>63</code> or <code>65</code> instead of
<code>64</code> (but I’ve never observed any other values), so the
result is then rounded to the nearest multiple of <code>4</code>, and
then the other constants are derived from it.</p>
<h2 id="copyright-and-cc-by-sa-4.0-license">Copyright and CC BY-SA 4.0
License:</h2>
<p>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:</p>
probabilistically at run-time. An instance of the <a href="https://en.wikipedia.org/wiki/Renewal_theory#Inspection_paradox">“Inspection
Paradox”</a> is
used which happens to produce a value that on average is close to <code>.64</code>.
<code>10000</code> instances of this value are computed, added up, and then divided by
<code>100</code>. Sometimes the value produced will be <code>63</code> or <code>65</code> instead of <code>64</code> (but
I’ve never observed any other values), so the result is then rounded to the
nearest multiple of <code>4</code>, and then the other constants are derived from it.</p>
<h2 id="copyright-and-cc-by-sa-4.0-license">Copyright and CC BY-SA 4.0 License:</h2>
<p>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:</p>
<pre><code>Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)</code></pre>
<p>For more information, see:
https://creativecommons.org/licenses/by-sa/4.0/</p>
<p>For more information, see: https://creativecommons.org/licenses/by-sa/4.0/</p>
<!-- END: this line ends content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
<!-- START: this line starts content for HTML phase 22 by: bin/output-index-inventory.sh via bin/md2html.sh -->
<!-- START: this line starts content generated by: bin/output-index-inventory.sh -->
<h1 id="inventory-for-1992vern"><a name="inventory"></a>Inventory for
1992/vern</h1>
<h1 id="inventory-for-1992vern"><a name="inventory"></a>Inventory for 1992/vern</h1>
<p><a href="#top">Jump to top</a></p>
<h2 id="primary-files">Primary files</h2>
<ul>
<li><a
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1992/vern/vern.c">vern.c</a>
- entry source</li>
<li><a
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1992/vern/Makefile">Makefile</a>
- entry Makefile</li>
<li><a
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1992/vern/vern.orig.c">vern.orig.c</a>
- original source</li>
<li><a href="1992_vern.tar.bz2">1992_vern.tar.bz2</a> - download entry
source</li>
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1992/vern/vern.c">vern.c</a> - entry source</li>
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1992/vern/Makefile">Makefile</a> - entry Makefile</li>
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1992/vern/vern.orig.c">vern.orig.c</a> - original source</li>
<li><a href="1992_vern.tar.bz2">1992_vern.tar.bz2</a> - download entry source</li>
</ul>
<h2 id="secondary-files">Secondary files</h2>
<ul>
<li><a href="index.html">index.html</a> - entry home page</li>
<li><a
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1992/vern/.entry.json">.entry.json</a>
- description of entry in JSON</li>
<li><a
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1992/vern/.gitignore">.gitignore</a>
- list of files that should not be committed under git</li>
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1992/vern/.entry.json">.entry.json</a> - description of entry in JSON</li>
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1992/vern/.gitignore">.gitignore</a> - list of files that should not be committed under git</li>
<li><a href=".path">.path</a> - directory path from top directory</li>
<li><a
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1992/vern/README.md">README.md</a>
- markdown source for index.html</li>
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1992/vern/README.md">README.md</a> - markdown source for index.html</li>
</ul>
<!-- END: next line ends content generated by: bin/output-index-inventory.sh -->