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:
1 parent
9eb7a54e9f
commit
b0b212acb1
402 files changed
+37061
-55132
No files matched your search
+165
-255
@@ -129,9 +129,9 @@
|
||||
|
||||
<h2 id="author"><a name="author"></a>Author:</h2>
|
||||
<ul>
|
||||
<li>Name: <a href="../../authors.html#Ondrej_Adamovsky">Ondřej
|
||||
Adamovský</a><br> Location: <a href="../../location.html#CZ">CZ</a> -
|
||||
<em>Czech Republic</em> (<em>Czechia</em>) <br><br></li>
|
||||
<li>Name: <a href="../../authors.html#Ondrej_Adamovsky">Ondřej Adamovský</a><br>
|
||||
Location: <a href="../../location.html#CZ">CZ</a> - <em>Czech Republic</em> (<em>Czechia</em>)
|
||||
<br><br></li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-author.sh -->
|
||||
@@ -144,8 +144,7 @@ Adamovský</a><br> Location: <a href="../../location.html#CZ">CZ</a> -
|
||||
<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#2019_adamovsky">2019 adamovsky bugs</a>.</p>
|
||||
<p>For more detailed information see <a href="../../bugs.html#2019_adamovsky">2019 adamovsky 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">./prog</span> file.unl</span></code></pre></div>
|
||||
<h2 id="try">Try:</h2>
|
||||
@@ -153,107 +152,71 @@ href="../../bugs.html#2019_adamovsky">2019 adamovsky bugs</a>.</p>
|
||||
<h2 id="judges-remarks">Judges’ remarks:</h2>
|
||||
<p>Even after pre-processing and indenting, the C code of this entry it
|
||||
is about as understandable as the Unlambda code.</p>
|
||||
<p>Pretending that we don’t know a bit of functional programming :) and
|
||||
lacking a better way to understand the entry but to fuzz it, we stumbled
|
||||
on a string of bytes which crashed it:</p>
|
||||
<p>Pretending that we don’t know a bit of functional programming :) and lacking a
|
||||
better way to understand the entry but to fuzz it, we stumbled on a string of
|
||||
bytes which crashed it:</p>
|
||||
<pre><code>````.0`.0`.0`c.0``sssss</code></pre>
|
||||
<p>Functional programming is not a panacea against core dumps, after
|
||||
all.</p>
|
||||
<p>Functional programming is not a panacea against core dumps, after all.</p>
|
||||
<p>This can be demonstrated by:</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="ex">./prog</span> crash.unl</span></code></pre></div>
|
||||
<h2 id="authors-remarks">Author’s remarks:</h2>
|
||||
<h3 id="a-highly-structured-state-state-machine">A highly structured
|
||||
state state machine</h3>
|
||||
<h3 id="a-highly-structured-state-state-machine">A highly structured state state machine</h3>
|
||||
<h3 id="purpose">Purpose:</h3>
|
||||
<p>The purpose of this program is to allow you to play Colossal Cave
|
||||
Adventure as implemented by <a
|
||||
href="https://github.com/irori/advent-unlambda"
|
||||
title="Adventure">Kunihiko Sakamoto</a>. As that was written in <a
|
||||
href="http://www.madore.org/~david/programs/unlambda/"
|
||||
title="Unlambda programming language">Unlambda programming language</a>
|
||||
designed by David Alexander Madore it has to be an Unlambda
|
||||
interpreter.</p>
|
||||
<p>The purpose of this program is to allow you to play Colossal Cave Adventure as
|
||||
implemented by <a href="https://github.com/irori/advent-unlambda" title="Adventure">Kunihiko Sakamoto</a>. As that was written in <a href="http://www.madore.org/~david/programs/unlambda/" title="Unlambda programming language">Unlambda programming
|
||||
language</a> designed by David Alexander Madore it has to be an Unlambda interpreter.</p>
|
||||
<h3 id="aesthetics">Aesthetics:</h3>
|
||||
<p>The program grew a bit too long so I had to use several macros to
|
||||
downsize it. That unfortunately reduced my options for program layout. I
|
||||
decided to separate it into two portions: the initial macro section
|
||||
where I had limited resources which you should disregard its shape,
|
||||
unless you like it, and the rest, which is a separator in the form of a
|
||||
single line followed by a section signifying the function of the
|
||||
program, a block with removed shape of lambda character. Even the
|
||||
official IOCCC size tool acknowledges this: When you call
|
||||
<code>./iocccsize -i <prog.c</code>, using the <a
|
||||
href="../../2019/iocccsize.c">2019 version of iocccsize</a>, iocccsize
|
||||
returns <strong>955</strong>, which is the Unicode codepoint of the
|
||||
<strong>λ</strong> character.</p>
|
||||
<p>It might be a surprise for you that according to the IOCCC size tool
|
||||
the program is actually a <code>one-liner</code>. It certainly was for
|
||||
me. I like to think the tool is overwhelmed by the sheer length of the
|
||||
dividing line and totally overlooks the rest of the program.</p>
|
||||
<p>The program grew a bit too long so I had to use several macros to downsize it.
|
||||
That unfortunately reduced my options for program layout. I decided to separate
|
||||
it into two portions: the initial macro section where I had limited resources
|
||||
which you should disregard its shape, unless you like it, and the rest, which is a
|
||||
separator in the form of a single line followed by a section signifying the
|
||||
function of the program, a block with removed shape of lambda character. Even
|
||||
the official IOCCC size tool acknowledges this: When you call <code>./iocccsize -i <prog.c</code>, using the <a href="../../2019/iocccsize.c">2019 version of
|
||||
iocccsize</a>, iocccsize returns <strong>955</strong>,
|
||||
which is the Unicode codepoint of the <strong>λ</strong> character.</p>
|
||||
<p>It might be a surprise for you that according to the IOCCC size tool the program is
|
||||
actually a <code>one-liner</code>. It certainly was for me. I like to think the tool is overwhelmed
|
||||
by the sheer length of the dividing line and totally overlooks the rest of the program.</p>
|
||||
<h3 id="usage">Usage:</h3>
|
||||
<p>When built directly using</p>
|
||||
<div class="sourceCode" id="cb7"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb7-1"><a href="#cb7-1" aria-hidden="true" tabindex="-1"></a><span class="fu">make</span></span></code></pre></div>
|
||||
<p>the program (<code>prog</code>) accepts a single parameter with the
|
||||
name of an Unlambda program. You can download the <a
|
||||
href="https://github.com/irori/advent-unlambda"
|
||||
title="Adventure">Colossal Cave Adventure</a> (the <a
|
||||
href="advent.unl">advent.unl</a> file) and run it like this:</p>
|
||||
<p>the program (<code>prog</code>) accepts a single parameter with the name of an Unlambda program. You can
|
||||
download the <a href="https://github.com/irori/advent-unlambda" title="Adventure">Colossal Cave Adventure</a> (the <a href="advent.unl">advent.unl</a> file)
|
||||
and run it like this:</p>
|
||||
<div class="sourceCode" id="cb8"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb8-1"><a href="#cb8-1" aria-hidden="true" tabindex="-1"></a><span class="ex">./prog</span> advent.unl</span></code></pre></div>
|
||||
<blockquote>
|
||||
<p>NOTE: the file was added to the entry so there is no need to download
|
||||
it.</p>
|
||||
<p>NOTE: the file was added to the entry so there is no need to download it.</p>
|
||||
</blockquote>
|
||||
<p>You can also try other programs from the Web. Many example programs
|
||||
are in the official <a
|
||||
href="http://www.madore.org/~david/programs/unlambda/#distrib"
|
||||
title="Reference Unlambda distribution">Unlambda distribution</a> on the
|
||||
Unlambda homepage. The most complex programs there are entries from <a
|
||||
href="http://www.madore.org/~david/programs/unlambda/#quine"
|
||||
title="Unlambda quine contest">quine contest</a>.</p>
|
||||
<p>There is an alternative build path that requires the 2018 IOCCC size
|
||||
tool to complete. Put the tool source <a
|
||||
href="iocccsize_2018.c">iocccsize_2018.c</a> in the project directory
|
||||
and call</p>
|
||||
<p>You can also try other programs from the Web. Many example programs are in the official
|
||||
<a href="http://www.madore.org/~david/programs/unlambda/#distrib" title="Reference Unlambda distribution">Unlambda distribution</a> on the Unlambda homepage. The most complex programs there are
|
||||
entries from <a href="http://www.madore.org/~david/programs/unlambda/#quine" title="Unlambda quine contest">quine contest</a>.</p>
|
||||
<p>There is an alternative build path that requires the 2018 IOCCC size tool to complete. Put the tool
|
||||
source <a href="iocccsize_2018.c">iocccsize_2018.c</a> in the project directory and call</p>
|
||||
<div class="sourceCode" id="cb9"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb9-1"><a href="#cb9-1" aria-hidden="true" tabindex="-1"></a><span class="fu">make</span> identify</span></code></pre></div>
|
||||
<p>It will build the tool and use it to build an alternative program
|
||||
<code>prog2</code>, which in turn will produce an Unlambda program
|
||||
<code>identify.unl</code>. <code>make identify</code> runs this program
|
||||
to identify itself.</p>
|
||||
<p>The base program (<code>prog</code>) implements an interpreter of
|
||||
Unlambda 2.0. It recognises all its builtins (<code>k</code>,
|
||||
<code>s</code>, <code>i</code>, <code>v</code>, <code>c</code>,
|
||||
<code>d</code>, <code>.x</code>, <code>e</code>, <code>@</code>,
|
||||
<code>?x</code> and <code>|</code>) including the syntactic sugar
|
||||
function <code>r</code> and formatting properties in the form of
|
||||
ignoring whitespace and comments to the end of line introduced by the
|
||||
<code>#</code> character.</p>
|
||||
<p>In case of wrong usage (missing Unlambda program file or missing
|
||||
parameter) or use of an unseekable (<code>fseek(3)</code>) Unlambda
|
||||
program source if it uses the <code>c</code> function, the program
|
||||
returns the message <code>fail</code>. It also informs you about
|
||||
syntactic errors in the Unlambda program should there be any (but only
|
||||
when the execution reaches them).</p>
|
||||
<p>The Unlambda source file may contain several Unlambda programs. The
|
||||
interpreter will run them all in sequence.</p>
|
||||
<p>It will build the tool and use it to build an alternative program <code>prog2</code>, which in turn will
|
||||
produce an Unlambda program <code>identify.unl</code>. <code>make identify</code> runs this program to identify
|
||||
itself.</p>
|
||||
<p>The base program (<code>prog</code>) implements an interpreter of Unlambda 2.0. It
|
||||
recognises all its builtins (<code>k</code>, <code>s</code>, <code>i</code>, <code>v</code>, <code>c</code>, <code>d</code>, <code>.x</code>, <code>e</code>, <code>@</code>, <code>?x</code>
|
||||
and <code>|</code>) including the syntactic sugar function <code>r</code> and formatting properties in
|
||||
the form of ignoring whitespace and comments to the end of line introduced by
|
||||
the <code>#</code> character.</p>
|
||||
<p>In case of wrong usage (missing Unlambda program file or missing parameter) or
|
||||
use of an unseekable (<code>fseek(3)</code>) Unlambda program source if it uses the <code>c</code>
|
||||
function, the program returns the message <code>fail</code>. It also informs you about
|
||||
syntactic errors in the Unlambda program should there be any (but only when the
|
||||
execution reaches them).</p>
|
||||
<p>The Unlambda source file may contain several Unlambda programs. The interpreter
|
||||
will run them all in sequence.</p>
|
||||
<h3 id="unlambda">Unlambda</h3>
|
||||
<p>If you want to familiarise yourself with the language, visit its <a
|
||||
href="https://en.wikipedia.org/wiki/Unlambda"
|
||||
title="Unlambda on Wikipedia">Wikipedia page</a> for a brief
|
||||
introduction or its <a
|
||||
href="http://www.madore.org/~david/programs/unlambda/"
|
||||
title="Unlambda programming language">homepage</a> for an in depth
|
||||
discussion. For further reading you can visit Wikipedia pages on <a
|
||||
href="https://en.wikipedia.org/wiki/Lambda_calculus"
|
||||
title="Lambda Calculus on Wikipedia">Lambda Calculus</a> and <a
|
||||
href="https://en.wikipedia.org/wiki/Combinatory_logic"
|
||||
title="Combinatory Logic on Wikipedia">Combinatory Logic</a>.</p>
|
||||
<p>You can also play with an <a href="https://inazz.jp/unlambda/"
|
||||
title="Online Unlambda interpreter">online interpreter</a> by GitHub
|
||||
user inazz. There you can debug one of the example programs provided or
|
||||
try your wits in writing your own.</p>
|
||||
<p>If you want to familiarise yourself with the language, visit its <a href="https://en.wikipedia.org/wiki/Unlambda" title="Unlambda on Wikipedia">Wikipedia page</a> for
|
||||
a brief introduction or its <a href="http://www.madore.org/~david/programs/unlambda/" title="Unlambda programming language">homepage</a> for an in depth discussion. For further reading you
|
||||
can visit Wikipedia pages on <a href="https://en.wikipedia.org/wiki/Lambda_calculus" title="Lambda Calculus on Wikipedia">Lambda Calculus</a> and <a href="https://en.wikipedia.org/wiki/Combinatory_logic" title="Combinatory Logic on Wikipedia">Combinatory Logic</a>.</p>
|
||||
<p>You can also play with an <a href="https://inazz.jp/unlambda/" title="Online Unlambda interpreter">online interpreter</a> by GitHub user inazz. There you can
|
||||
debug one of the example programs provided or try your wits in writing your own.</p>
|
||||
<h3 id="hints">Hints:</h3>
|
||||
<p>Here are some pointers where to start when trying to understand the
|
||||
interpreter:</p>
|
||||
<p>Here are some pointers where to start when trying to understand the interpreter:</p>
|
||||
<ul>
|
||||
<li>Where are syntax errors detected?</li>
|
||||
<li>How is the memory managed?</li>
|
||||
@@ -264,198 +227,145 @@ interpreter:</p>
|
||||
</ul>
|
||||
<h3 id="obfuscation-sources">Obfuscation sources</h3>
|
||||
<ul>
|
||||
<li>The elephant in the room is the Unlambda language. As we all know,
|
||||
functional programming defies sanity. Furthermore, Unlambda was
|
||||
specifically designed to be unintelligible and hard to code in. Most of
|
||||
its functions are quite simple and straightforward to implement, but two
|
||||
make it a mess: the promise operator <code>d</code> and the call with
|
||||
current continuation <code>c</code>.</li>
|
||||
<li>Most of the additional obfuscation is derived from basic design
|
||||
choices. That is, how the state of the program is stored and how the
|
||||
Unlambda functions are implemented.</li>
|
||||
<li>The elephant in the room is the Unlambda language. As we all know, functional
|
||||
programming defies sanity. Furthermore, Unlambda was specifically designed to be
|
||||
unintelligible and hard to code in. Most of its functions are quite simple and
|
||||
straightforward to implement, but two make it a mess: the promise operator <code>d</code>
|
||||
and the call with current continuation <code>c</code>.</li>
|
||||
<li>Most of the additional obfuscation is derived from basic design choices. That
|
||||
is, how the state of the program is stored and how the Unlambda functions are
|
||||
implemented.</li>
|
||||
</ul>
|
||||
<p>More on this in the <strong>Spoilers</strong> section.</p>
|
||||
<h3 id="build-notes">Build notes:</h3>
|
||||
<p>The program does not require any special treatment by compilers. Some
|
||||
warnings had to be suppressed when compiling with
|
||||
<code>-Wall -Wextra -pedantic</code>. Those were produced because of the
|
||||
formatting of the source code, not any programming technique.
|
||||
Compilation with <code>clang -Weverything</code> produced many more
|
||||
warnings, but those are only relevant for multi-source-file projects and
|
||||
some are really questionable
|
||||
(e.g. <code>-Wdisabled-macro-expansion</code>).</p>
|
||||
<p>The program does not require any special treatment by compilers. Some warnings
|
||||
had to be suppressed when compiling with <code>-Wall -Wextra -pedantic</code>. Those were
|
||||
produced because of the formatting of the source code, not any programming
|
||||
technique. Compilation with <code>clang -Weverything</code> produced many more warnings,
|
||||
but those are only relevant for multi-source-file projects and some are really
|
||||
questionable (e.g. <code>-Wdisabled-macro-expansion</code>).</p>
|
||||
<h3 id="portability">Portability:</h3>
|
||||
<p>Development was done on Debian 9 on x86-64 architecture using mainly
|
||||
Clang 3.8.1-24 and GCC 6.3.0. The source is C11 compliant and does not
|
||||
use any special properties except the following:</p>
|
||||
<p>Development was done on Debian 9 on x86-64 architecture using mainly Clang 3.8.1-24
|
||||
and GCC 6.3.0. The source is C11 compliant and does not use any special properties
|
||||
except the following:</p>
|
||||
<ul>
|
||||
<li>The interpreter sort of relies on tail call optimization. It works
|
||||
well even without it, but the stack runs out quickly with some Unlambda
|
||||
programs (e.g. <code>trivial.unl</code> example from the <a
|
||||
href="http://www.madore.org/~david/programs/unlambda/#distrib"
|
||||
title="Reference Unlambda distribution">reference Unlambda
|
||||
distribution</a> produces segfault). Clang with <code>-O3</code> option
|
||||
does this optimization well and said example does not segfault with it.
|
||||
I was not able to force GCC to optimize it out (probably an operator
|
||||
fault).</li>
|
||||
<li>The only data structure of the program (the <code>union</code>) had
|
||||
much more members originally. I joined all integers to a single
|
||||
<code>long long</code> member in the name of obfuscation. It is used for
|
||||
reference counting (only 1 for every reference) among other uses.
|
||||
<code>size_t</code> should be used for that, but practically, I think
|
||||
the memory would run out sooner than the reference counter in any real
|
||||
world situation even when <code>size_t</code> is bigger than
|
||||
<code>long long</code>. It is also used for storing <code>char</code>s
|
||||
for later printing. This might produce some warnings, but since it was
|
||||
developed using <code>char</code>s it should be always used safely.</li>
|
||||
<li>The interpreter sort of relies on tail call optimization. It works well even
|
||||
without it, but the stack runs out quickly with some Unlambda programs (e.g.
|
||||
<code>trivial.unl</code> example from the <a href="http://www.madore.org/~david/programs/unlambda/#distrib" title="Reference Unlambda distribution">reference Unlambda distribution</a> produces
|
||||
segfault). Clang with <code>-O3</code> option does this optimization well and said example
|
||||
does not segfault with it. I was not able to force GCC to optimize it out
|
||||
(probably an operator fault).</li>
|
||||
<li>The only data structure of the program (the <code>union</code>) had much more
|
||||
members originally. I joined all integers to a single <code>long long</code> member in the
|
||||
name of obfuscation. It is used for reference counting (only 1 for every
|
||||
reference) among other uses. <code>size_t</code> should be used for that, but practically,
|
||||
I think the memory would run out sooner than the reference counter in any real
|
||||
world situation even when <code>size_t</code> is bigger than <code>long long</code>. It is also used
|
||||
for storing <code>char</code>s for later printing. This might produce some warnings, but
|
||||
since it was developed using <code>char</code>s it should be always used safely.</li>
|
||||
</ul>
|
||||
<h3 id="spoilers">Spoilers:</h3>
|
||||
<ul>
|
||||
<li><p>You can examine the <a href="progSpoiler.c">progSpoiler.c</a>
|
||||
file. It is the original final version of the interpreter, before I
|
||||
started the downsizing. It accepts one more optional parameter that
|
||||
specifies a filename for the output Unlambda function (it’s the Unlambda
|
||||
function that remains after all function applications are done). When no
|
||||
filename is provided, <code>stderr</code> is used.</p>
|
||||
<p>The function <em>output</em> is used for this additional
|
||||
functionality. You can use it while debugging to visualise current
|
||||
variables.</p></li>
|
||||
<li><p>The Unlambda functions are represented by a record consisting of
|
||||
an array of five multipurpose arguments. The first one refers to the
|
||||
function implementing its application, the second and the third ones are
|
||||
for arguments of the function, the fourth one is for stack building, and
|
||||
the fifth one is the reference counter.</p>
|
||||
<p>The function argument is used not only for evaluation of the
|
||||
functions, but also as a state variable to decide whether we want to
|
||||
call it, or do something else.</p></li>
|
||||
<li><p>The interpreter reads the Unlambda source as it interprets it,
|
||||
translating the incoming character to a function using a constructor
|
||||
stored in translation array <code>T</code>.</p>
|
||||
<p>This means the interpreter must reposition in the source file
|
||||
whenever current continuation is called.</p></li>
|
||||
<li><p>The state of the interpreter is represented by trees representing
|
||||
evaluated Unlambda functions stored on the C stack as local variables,
|
||||
plus the source file position. When a current continuation is created,
|
||||
the stack is unwound using the fourth argument of the nodes, stored in
|
||||
the continuation, and rebuilt back resuming the evaluation. When its
|
||||
called, the stack is unwound and thrown away, and the stack stored in
|
||||
the continuation is restored.</p>
|
||||
<p>This makes implementation of a complete debugger a bit more
|
||||
challenging.</p>
|
||||
<p>For this to work, the functions that do the work (i.e. make a series
|
||||
of applications and/or evaluations each of which may be a call to
|
||||
current continuation), the <code>s</code> combinator and the
|
||||
<code>`</code> application operation had to be broken down to pieces,
|
||||
one for each application/evaluation and corresponding helper functions
|
||||
for stack rebuilding. (the helper functions are named beginning with
|
||||
<code>r</code> instead of <code>f</code>)</p></li>
|
||||
<li><p>The <code>`</code> application operation does the reading of the
|
||||
Unlambda source when needed. It also implements the promise function.
|
||||
Whenever it would apply it, it overwrites the Apply constructor in
|
||||
translation array <code>T</code>, changing its function to build an
|
||||
unevaluated sub-tree that is later evaluated whenever the promise is
|
||||
<li><p>You can examine the <a href="progSpoiler.c">progSpoiler.c</a> file. It is the original
|
||||
final version of the interpreter, before I started the downsizing. It accepts
|
||||
one more optional parameter that specifies a filename for the output Unlambda
|
||||
function (it’s the Unlambda function that remains after all function
|
||||
applications are done). When no filename is provided, <code>stderr</code> is used.</p>
|
||||
<p>The function <em>output</em> is used for this additional functionality. You can use
|
||||
it while debugging to visualise current variables.</p></li>
|
||||
<li><p>The Unlambda functions are represented by a record consisting of an array of
|
||||
five multipurpose arguments. The first one refers to the function implementing
|
||||
its application, the second and the third ones are for arguments of the
|
||||
function, the fourth one is for stack building, and the fifth one is the
|
||||
reference counter.</p>
|
||||
<p>The function argument is used not only for evaluation of the functions, but also
|
||||
as a state variable to decide whether we want to call it, or do something else.</p></li>
|
||||
<li><p>The interpreter reads the Unlambda source as it interprets it, translating the
|
||||
incoming character to a function using a constructor stored in translation array
|
||||
<code>T</code>.</p>
|
||||
<p>This means the interpreter must reposition in the source file whenever current
|
||||
continuation is called.</p></li>
|
||||
<li><p>The state of the interpreter is represented by trees representing evaluated
|
||||
Unlambda functions stored on the C stack as local variables, plus the source
|
||||
file position. When a current continuation is created, the stack is unwound
|
||||
using the fourth argument of the nodes, stored in the continuation, and rebuilt
|
||||
back resuming the evaluation. When its called, the stack is unwound and thrown
|
||||
away, and the stack stored in the continuation is restored.</p>
|
||||
<p>This makes implementation of a complete debugger a bit more challenging.</p>
|
||||
<p>For this to work, the functions that do the work (i.e. make a series of applications
|
||||
and/or evaluations each of which may be a call to current continuation), the <code>s</code>
|
||||
combinator and the <code>`</code> application operation had to be broken down to pieces, one
|
||||
for each application/evaluation and corresponding helper functions for stack
|
||||
rebuilding. (the helper functions are named beginning with <code>r</code> instead of <code>f</code>)</p></li>
|
||||
<li><p>The <code>`</code> application operation does the reading of the Unlambda source when
|
||||
needed. It also implements the promise function. Whenever it would apply it, it
|
||||
overwrites the Apply constructor in translation array <code>T</code>, changing its function
|
||||
to build an unevaluated sub-tree that is later evaluated whenever the promise is
|
||||
applied.</p></li>
|
||||
<li><p>To further the obfuscation, I shortened the function names while
|
||||
downsizing, but preserved their meaning (with the exception of Apply
|
||||
functions, which I renamed to <code>Y</code> to possibly confuse with
|
||||
<code>Y</code> combinator). Simple functions retained their names to
|
||||
misguide the reader to believe to know what is what. The names of
|
||||
continuation and exit functions were swapped. The names of
|
||||
<code>S</code> and Apply functions were shuffled both for <code>S</code>
|
||||
functions and Apply functions in the same way to hide the meaning of
|
||||
<code>f</code> and <code>r</code> prefixes.</p></li>
|
||||
<li><p>To further the obfuscation, I shortened the function names while downsizing,
|
||||
but preserved their meaning (with the exception of Apply functions, which I
|
||||
renamed to <code>Y</code> to possibly confuse with <code>Y</code> combinator). Simple functions retained
|
||||
their names to misguide the reader to believe to know what is what. The names of
|
||||
continuation and exit functions were swapped. The names of <code>S</code> and Apply functions
|
||||
were shuffled both for <code>S</code> functions and Apply functions in the same way to hide
|
||||
the meaning of <code>f</code> and <code>r</code> prefixes.</p></li>
|
||||
</ul>
|
||||
<h3 id="identification-spoiler">Identification spoiler:</h3>
|
||||
<p>The alternative build path <code>make identify</code> output
|
||||
commemorates a <a href="../../2014/birken/index.html"
|
||||
title="Best use of port 1701">previous IOCCC winning entry</a> which
|
||||
uses similar methods to mess with the size tool.</p>
|
||||
<p>The alternative build path <code>make identify</code> output commemorates a <a href="../../2014/birken/index.html" title="Best use of port 1701">previous IOCCC
|
||||
winning entry</a> which uses similar methods to mess with the size tool.</p>
|
||||
<h3 id="judges-spoilers">Judges’ spoilers:</h3>
|
||||
<p>It is not a bug, it is a feature. :)</p>
|
||||
<p>The crash is caused by a stack overflow. Conventional Unlabmda
|
||||
interpreters implement the Unlambda execution stack using data
|
||||
structures on the heap. This interpreter uses the C call stack for this
|
||||
purpose. In a conventional interpreter, the judges’ program would
|
||||
consume memory until the user (or the operating system) would lose
|
||||
patience. The C call stack is usually of a limited size and protected,
|
||||
so this interpreter crashes, when the judges’ program depletes the
|
||||
stack. You can always increase the maximal stack size through the system
|
||||
settings (on Linux) or compiler options (on Windows) if your Unlambda
|
||||
program needs it. Nevertheless, it will not help the judges’ program
|
||||
which quickly depletes any limit you define.</p>
|
||||
<p>The judges, pretending to not know what they are doing, created a
|
||||
program that grows Unlambda execution stack indefinitely. You may
|
||||
consider it an Unlambda anti-pattern. Normally, infinite cycles in
|
||||
Unlambda work by creating two functions and applying one to the other
|
||||
which creates further functions to apply. The application of the
|
||||
function frees its position on the stack. This program builds one ever
|
||||
growing function that will never be complete and be able to be
|
||||
applied.</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>
|
||||
<p>The crash is caused by a stack overflow. Conventional Unlabmda interpreters
|
||||
implement the Unlambda execution stack using data structures on the heap. This
|
||||
interpreter uses the C call stack for this purpose. In a conventional
|
||||
interpreter, the judges’ program would consume memory until the user (or the
|
||||
operating system) would lose patience. The C call stack is usually of a limited
|
||||
size and protected, so this interpreter crashes, when the judges’ program
|
||||
depletes the stack. You can always increase the maximal stack size through the
|
||||
system settings (on Linux) or compiler options (on Windows) if your Unlambda
|
||||
program needs it. Nevertheless, it will not help the judges’ program which
|
||||
quickly depletes any limit you define.</p>
|
||||
<p>The judges, pretending to not know what they are doing, created a program that
|
||||
grows Unlambda execution stack indefinitely. You may consider it an Unlambda
|
||||
anti-pattern. Normally, infinite cycles in Unlambda work by creating two
|
||||
functions and applying one to the other which creates further functions to
|
||||
apply. The application of the function frees its position on the stack. This
|
||||
program builds one ever growing function that will never be complete and be able to
|
||||
be applied.</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-2019adamovsky"><a name="inventory"></a>Inventory
|
||||
for 2019/adamovsky</h1>
|
||||
<h1 id="inventory-for-2019adamovsky"><a name="inventory"></a>Inventory for 2019/adamovsky</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/2019/adamovsky/prog.c">prog.c</a>
|
||||
- entry source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/adamovsky/Makefile">Makefile</a>
|
||||
- entry Makefile</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/adamovsky/prog.orig.c">prog.orig.c</a>
|
||||
- original source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/adamovsky/try.sh">try.sh</a>
|
||||
- how to run</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/adamovsky/advent.unl">advent.unl</a>
|
||||
- unlambda script</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/adamovsky/crash.unl">crash.unl</a>
|
||||
- unlambda script</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/adamovsky/iocccsize_2018.c">iocccsize_2018.c</a>
|
||||
- 2018 iocccsize source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/adamovsky/progSpoiler.c">progSpoiler.c</a>
|
||||
- SPOILER WARNING</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/adamovsky/sierpinski.unl">sierpinski.unl</a>
|
||||
- unlambda code</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/adamovsky/spam.unl">spam.unl</a>
|
||||
- unlambda code</li>
|
||||
<li><a href="2019_adamovsky.tar.bz2">2019_adamovsky.tar.bz2</a> -
|
||||
download entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/adamovsky/prog.c">prog.c</a> - entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/adamovsky/Makefile">Makefile</a> - entry Makefile</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/adamovsky/prog.orig.c">prog.orig.c</a> - original source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/adamovsky/try.sh">try.sh</a> - how to run</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/adamovsky/advent.unl">advent.unl</a> - unlambda script</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/adamovsky/crash.unl">crash.unl</a> - unlambda script</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/adamovsky/iocccsize_2018.c">iocccsize_2018.c</a> - 2018 iocccsize source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/adamovsky/progSpoiler.c">progSpoiler.c</a> - SPOILER WARNING</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/adamovsky/sierpinski.unl">sierpinski.unl</a> - unlambda code</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/adamovsky/spam.unl">spam.unl</a> - unlambda code</li>
|
||||
<li><a href="2019_adamovsky.tar.bz2">2019_adamovsky.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/2019/adamovsky/.entry.json">.entry.json</a>
|
||||
- description of entry in JSON</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/adamovsky/.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/2019/adamovsky/.entry.json">.entry.json</a> - description of entry in JSON</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/adamovsky/.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/2019/adamovsky/README.md">README.md</a>
|
||||
- markdown source for index.html</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/adamovsky/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