force use of pandoc version >= 3.1.12.2
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
1 parent
9eb7a54e9f
commit
b0b212acb1
402 files changed
+37061
-55132
No files matched your search
+71
-88
@@ -129,9 +129,9 @@
|
||||
|
||||
<h2 id="author"><a name="author"></a>Author:</h2>
|
||||
<ul>
|
||||
<li>Name: <a href="../../authors.html#David_Applegate">David
|
||||
Applegate</a><br> Location: <a href="../../location.html#US">US</a> -
|
||||
<em>United States of America</em> (<em>United States</em>) <br><br></li>
|
||||
<li>Name: <a href="../../authors.html#David_Applegate">David Applegate</a><br>
|
||||
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 -->
|
||||
@@ -157,115 +157,98 @@ Applegate</a><br> Location: <a href="../../location.html#US">US</a> -
|
||||
<li>it did not require X to be on the host system</li>
|
||||
<li>both BSD and SVR4 have sockets</li>
|
||||
</ul>
|
||||
<p>Now that X11 and sockets have become ‘standard’, we plan to open up
|
||||
the contest to programs that use them. Future rules will explain this
|
||||
further.</p>
|
||||
<p>We are pleased that this entry has helped bring new ‘life’ into the
|
||||
contest.</p>
|
||||
<p>Now that X11 and sockets have become ‘standard’, we plan to open
|
||||
up the contest to programs that use them. Future rules will
|
||||
explain this further.</p>
|
||||
<p>We are pleased that this entry has helped bring new ‘life’ into
|
||||
the contest.</p>
|
||||
<h2 id="authors-remarks">Authors’ remarks:</h2>
|
||||
<p>The program is a fully-functional X client. It talks directly to the
|
||||
X server through a socket without using Xlib, Xt or any other wussy
|
||||
toolkit junk. With no arguments, it will try to run locally using the
|
||||
unix-domain socket (only on BSD :-( ) or you can give it a command line
|
||||
argument identifying a display host address (in dotted octet notation,
|
||||
like 127.0.0.1:0.0) where the X server is running. It handles color and
|
||||
monochrome displays, and performs whatever byte-swapping and
|
||||
bit-reversal is needed (so that the program works even when the server
|
||||
and the client have different architectures). It buffers communication
|
||||
to the X server for efficiency.</p>
|
||||
<p>The program is a fully-functional X client. It talks directly to
|
||||
the X server through a socket without using Xlib, Xt or any other
|
||||
wussy toolkit junk. With no arguments, it will try to run
|
||||
locally using the unix-domain socket (only on BSD :-( ) or you can
|
||||
give it a command line argument identifying a display host address
|
||||
(in dotted octet notation, like 127.0.0.1:0.0) where the X server
|
||||
is running. It handles color and monochrome displays, and
|
||||
performs whatever byte-swapping and bit-reversal is needed (so
|
||||
that the program works even when the server and the client have
|
||||
different architectures). It buffers communication to the X
|
||||
server for efficiency.</p>
|
||||
<p>NOTE: The original source in davidguy.c used only an IP address
|
||||
argument (assumed :0.0) and assumed the color of black and white.</p>
|
||||
argument (assumed :0.0) and assumed the color of black
|
||||
and white.</p>
|
||||
<p>The program doesn’t require any user interaction; you can just sit
|
||||
back and watch it run. All the action takes place in the root window of
|
||||
the display.</p>
|
||||
back and watch it run. All the action takes place in the root
|
||||
window of the display.</p>
|
||||
<p>We think the program is interesting for these reasons:</p>
|
||||
<ol type="1">
|
||||
<li><p>It belongs to a class of programs that programmers make the
|
||||
following complaints about: they require a mountain of code to implement
|
||||
even the simplest program; and they must be linked with giant libraries
|
||||
of hard-to-understand functions. In contrast to these complaints (made
|
||||
by wimps, in our humble opinion), our program fits in under 1536 bytes,
|
||||
doesn’t need any external functions except for a few system calls, and
|
||||
doesn’t need to include any header files.</p></li>
|
||||
<li><p>It implements an extremely efficient algorithm for the
|
||||
computation it performs. One cool feature of the algorithm (at least as
|
||||
far as this contest is concerned) is that its obscurity is fundamentally
|
||||
necessary for its efficiency. In other words, even if we took steps to
|
||||
present the algorithm clearly, (we haven’t) the relation of the
|
||||
computation performed to the specification of what the program was
|
||||
supposed to do would still be hard to understand.</p></li>
|
||||
<li><p>It belongs to a class of programs that programmers make the following
|
||||
complaints about: they require a mountain of code to implement even the
|
||||
simplest program; and they must be linked with giant libraries of
|
||||
hard-to-understand functions. In contrast to these complaints (made by wimps,
|
||||
in our humble opinion), our program fits in under 1536 bytes, doesn’t need any
|
||||
external functions except for a few system calls, and doesn’t need to include
|
||||
any header files.</p></li>
|
||||
<li><p>It implements an extremely efficient algorithm for the computation it
|
||||
performs. One cool feature of the algorithm (at least as far as this contest is
|
||||
concerned) is that its obscurity is fundamentally necessary for its efficiency.
|
||||
In other words, even if we took steps to present the algorithm clearly, (we
|
||||
haven’t) the relation of the computation performed to the specification of what
|
||||
the program was supposed to do would still be hard to understand.</p></li>
|
||||
</ol>
|
||||
<h3 id="quasi-spoiler-on-internals">Quasi-spoiler on internals:</h3>
|
||||
<p>The program plays <a
|
||||
href="https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life">Conway’s
|
||||
Game of Life</a> in the root window’s background pixmap. It starts by
|
||||
setting the background to random bits, and then plays Life, with one
|
||||
Life cell for each pixel of the screen. In the game of Life, a cell
|
||||
survives to the next round if 2 or 3 of its 8 neighbors are also alive,
|
||||
and a cell is born if exactly 3 of its neighbors are alive. Otherwise, a
|
||||
cell dies of exposure if it has only 0 or 1 neighbors, and dies of
|
||||
overcrowding if it has 4 or more neighbors.</p>
|
||||
<p>The program plays <a href="https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life">Conway’s Game of
|
||||
Life</a> in the root window’s
|
||||
background pixmap. It starts by setting the background to random
|
||||
bits, and then plays Life, with one Life cell for each pixel of the
|
||||
screen. In the game of Life, a cell survives to the next round if
|
||||
2 or 3 of its 8 neighbors are also alive, and a cell is born if
|
||||
exactly 3 of its neighbors are alive. Otherwise, a cell dies of
|
||||
exposure if it has only 0 or 1 neighbors, and dies of overcrowding
|
||||
if it has 4 or more neighbors.</p>
|
||||
<p>The algorithm used to compute the next generation is based on the
|
||||
observation that a cell’s state in the next generation is a boolean
|
||||
function of its current state, and the states of its 8 neighbors (i.e.,
|
||||
a boolean function from 9 bits to 1 bit). This function can be computed
|
||||
by a boolean circuit. In addition, intermediate values computed by the
|
||||
circuit can be shared between neighboring cells, reducing the number of
|
||||
gates per cell required. These ideas have been used before, to compute
|
||||
the next generation through a series of <a
|
||||
href="https://en.wikipedia.org/wiki/Bit_blit">bit blits</a>.</p>
|
||||
<p>Instead of doing this, we map values in the circuit to bits in
|
||||
registers, so that the next generation can be computed efficiently
|
||||
within registers, minimizing memory access. As a result, the computation
|
||||
of the next generation is performed with about 1.6 instructions per life
|
||||
cell, consisting of .125 memory accesses, .17 shifts, and 1.3 logic
|
||||
operations. The net result is that the time to transfer the bits to the
|
||||
X server, and for the X server to draw them on the screen, dominates the
|
||||
time to compute the next generation.</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>
|
||||
function of its current state, and the states of its 8 neighbors
|
||||
(i.e., a boolean function from 9 bits to 1 bit). This function can
|
||||
be computed by a boolean circuit. In addition, intermediate values
|
||||
computed by the circuit can be shared between neighboring cells,
|
||||
reducing the number of gates per cell required. These ideas
|
||||
have been used before, to compute the next generation through a
|
||||
series of <a href="https://en.wikipedia.org/wiki/Bit_blit">bit blits</a>.</p>
|
||||
<p>Instead of doing this, we map values in the circuit to bits in registers, so
|
||||
that the next generation can be computed efficiently within registers,
|
||||
minimizing memory access. As a result, the computation of the next generation
|
||||
is performed with about 1.6 instructions per life cell, consisting of .125
|
||||
memory accesses, .17 shifts, and 1.3 logic operations. The net result is that
|
||||
the time to transfer the bits to the X server, and for the X server to draw them
|
||||
on the screen, dominates the time to compute the next generation.</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-1991davidguy"><a name="inventory"></a>Inventory
|
||||
for 1991/davidguy</h1>
|
||||
<h1 id="inventory-for-1991davidguy"><a name="inventory"></a>Inventory for 1991/davidguy</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/1991/davidguy/davidguy.c">davidguy.c</a>
|
||||
- entry source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1991/davidguy/Makefile">Makefile</a>
|
||||
- entry Makefile</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1991/davidguy/davidguy.orig.c">davidguy.orig.c</a>
|
||||
- original source</li>
|
||||
<li><a href="1991_davidguy.tar.bz2">1991_davidguy.tar.bz2</a> - download
|
||||
entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1991/davidguy/davidguy.c">davidguy.c</a> - entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1991/davidguy/Makefile">Makefile</a> - entry Makefile</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1991/davidguy/davidguy.orig.c">davidguy.orig.c</a> - original source</li>
|
||||
<li><a href="1991_davidguy.tar.bz2">1991_davidguy.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/1991/davidguy/.entry.json">.entry.json</a>
|
||||
- description of entry in JSON</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1991/davidguy/.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/1991/davidguy/.entry.json">.entry.json</a> - description of entry in JSON</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1991/davidguy/.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/1991/davidguy/README.md">README.md</a>
|
||||
- markdown source for index.html</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1991/davidguy/README.md">README.md</a> - markdown source for index.html</li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-inventory.sh -->
|
||||
|
||||
Reference in new issue
Block a user