Fix two authors' info in 1995, update FAQ
The (same two) authors of 1995/heathbar and 1995/makarios had invalid information, in one case email as well as in both the url and location. The location was previously set to unknown (ZZ) but I knew from the archive (which used to be what the README.md files which were the hint files had until I was asked to remove that information which was done November 2023) that it was US. I also noticed, however, that the url was invalid and in one case the email was invalid (it referred to the same domain). With these problems in mind the url was changed to refer to the website on the Internet Wayback Machine (in both), the email was set to null in the one that had an email (now it's null in both) and the location_code was set to US (in both). I then did: touch 1995/heathbar/README.md 1995/makarios/README.md so that I could do: make quick_www as only two index.html files had to be updated. This also updated authors.html and location.html, of course. The FAQ was updated with more information on how to update author information with the above two as an example and it now also says how to validate json for those who want to make changes to author information (or if anything else in the future is put in json).
This commit is contained in:
1 parent
826a6eb01a
commit
a8500f8aad
8 files changed
+230
-57
No files matched your search
@@ -1199,13 +1199,15 @@ hints, especially in cases were something else needs to be installed.</p>
|
||||
<p>If you have a fix that makes a minimal impact to the entry, then
|
||||
please consider submitting that change in the form of a pull request.
|
||||
Please see <a href="#fix_an_entry">FAQ 5.2 How may I submit a fix to an IOCCC
|
||||
entry</a>. See also the <a href="#ull_request">FAQ 6.10 How does someone
|
||||
entry</a>. See also the <a href="#pull_request">FAQ 6.10 How does someone
|
||||
make a change to a file and submit that change as a GitHub pull
|
||||
request</a> for more information about pull requests.</p>
|
||||
<p>In some cases alternative code has been added that does compile on some or most systems. Check the write up for the entry for “alt” code and possible ways to compile and run that code. In some cases we replaced the original code (but not the <code>.orig.c</code> file!) with code
|
||||
that works for modern systems but one can view the original code in the
|
||||
<code>.orig.c</code> files (sometimes the original code is also in the directory as a
|
||||
<code>dirname.alt.c</code> or <code>prog.alt.c</code>).</p>
|
||||
<p>In some cases alternative code has been added that does compile on some or most
|
||||
systems. Check the write up for the entry for “alt” code and possible ways to
|
||||
compile and run that code. In some cases we replaced the original code (but not
|
||||
the <code>.orig.c</code> file!) with code that works for modern systems but one can view
|
||||
the original code in the <code>.orig.c</code> files (sometimes the original code is also in
|
||||
the directory as a <code>dirname.alt.c</code> or <code>prog.alt.c</code>).</p>
|
||||
<p>It might also be worth noting that almost all entries, have been
|
||||
fixed so that they can compile in modern systems though just because an entry
|
||||
compiles does not mean it will run on your specific system.</p>
|
||||
@@ -1234,7 +1236,7 @@ a pull request with that change. Pull requests that fix such code
|
||||
while trying to minimize the impact of any changes and preserving
|
||||
the spirit of the original code are very welcome! Please see <a href="#fix_an_entry">FAQ
|
||||
5.2 How may I submit a fix to an IOCCC entry</a> for
|
||||
details. See also the <a href="#ull_request">FAQ 6.10 How does someone make a change to
|
||||
details. See also the <a href="#pull_request">FAQ 6.10 How does someone make a change to
|
||||
a file and submit that change as a GitHub pull request</a>
|
||||
for more information about pull requests.</p>
|
||||
<div id="faq3_3">
|
||||
@@ -1269,7 +1271,7 @@ other things that have to be done plus remembering to do it.</p>
|
||||
that fixes the problem (even if it just a change to the <code>Makefile</code>) that doesn’t
|
||||
negatively impact the entry too much, consider submitting that change in the
|
||||
form of a pull request. Please see <a href="#fix_an_entry">FAQ 5.2 How may I submit a fix to an IOCCC
|
||||
entry</a>. See also the <a href="#ull_request">FAQ 6.10 How does someone
|
||||
entry</a>. See also the <a href="#pull_request">FAQ 6.10 How does someone
|
||||
make a change to a file and submit that change as a GitHub pull
|
||||
request</a> for more information about pull requests.</p>
|
||||
<div id="faq3_5">
|
||||
@@ -1474,8 +1476,8 @@ for downloading, installing and using SDL.</p>
|
||||
<p>In the case that some entries do not work even with SDL1/SDL2 installed it might
|
||||
be that you need additional SDL libraries. See the entry’s index.html for
|
||||
details. If something is not noted you’re welcome to report it as an issue or
|
||||
fix it and make a new pull request.</p>
|
||||
<p>See the <a href="#ull_request">FAQ 6.10 How does someone make a change to a file and submit that change
|
||||
fix it and make a pull request.</p>
|
||||
<p>See the <a href="#pull_request">FAQ 6.10 How does someone make a change to a file and submit that change
|
||||
as a GitHub pull request</a> for more information about pull requests.</p>
|
||||
<div id="faq3_9">
|
||||
<div id="curses">
|
||||
@@ -2164,7 +2166,7 @@ fix. If it is accepted we’ll be happy to credit you in the
|
||||
link to your entries; if you’re not we can link to your website if you wish.</p>
|
||||
<p>Please see <a href="#fix_an_entry">FAQ 5.2 How may I submit a fix to an IOCCC
|
||||
entry</a> for information on how to submit a fix to an
|
||||
IOCCC entry. See also the <a href="#ull_request">FAQ 6.10 How does someone make a change
|
||||
IOCCC entry. See also the <a href="#pull_request">FAQ 6.10 How does someone make a change
|
||||
to a file and submit that change as a GitHub pull request</a>
|
||||
for more information about pull requests.</p>
|
||||
<div id="faq5_2">
|
||||
@@ -2185,7 +2187,7 @@ repo</a>.</p>
|
||||
such as “<em>index.html</em>” files, fixing issues in a “<em>Makefile</em>”, or otherwise
|
||||
correcting an IOCCC entry is <strong>VERY MUCH WELCOME</strong>! Please use the same
|
||||
<a href="https://github.com/ioccc-src/winner/pulls">GitHub pull request</a> process against
|
||||
the master <a href="https://github.com/ioccc-src/winner/branches">branch</a> of the
|
||||
the <a href="https://github.com/ioccc-src/winner/branches">master branch</a> of the
|
||||
<a href="https://github.com/ioccc-src/winner">ioccc-src/winner repo</a>.</p>
|
||||
<p>NOTE: some of the issues in the <a href="bugs.html">bugs.html</a> file includes just missing
|
||||
files and we welcome these too!</p>
|
||||
@@ -2196,10 +2198,10 @@ IOCCC winning entries are presented!</p>
|
||||
<p>And of course, an IOCCC author may update their own entries
|
||||
(metadata as well as source code and any extra files) by opening a
|
||||
<a href="https://github.com/ioccc-src/winner/pulls">GitHub pull request</a>
|
||||
against the master <a href="https://github.com/ioccc-src/winner/branches">branch</a>
|
||||
against the <a href="https://github.com/ioccc-src/winner/branches">master branch</a>
|
||||
of the <a href="https://github.com/ioccc-src/winner">ioccc-src/winner repo</a>.</p>
|
||||
<p>Please see <a href="#fix_an_entry">FAQ 5.2 How may I submit a fix to an IOCCC
|
||||
entry</a>. See also the <a href="#ull_request">FAQ 6.10 How does someone
|
||||
entry</a>. See also the <a href="#pull_request">FAQ 6.10 How does someone
|
||||
make a change to a file and submit that change as a GitHub pull
|
||||
request</a> for more information about pull requests.</p>
|
||||
<p>Note that we’re much more inclined to accept an author’s fixes but the judges
|
||||
@@ -2232,11 +2234,11 @@ to <a href="https://github.com/ioccc-src/winner/issues/new">open a new IOCCC iss
|
||||
<p>For IOCCC website problems that relate to a particular IOCCC entry, please
|
||||
see <a href="#fix_an_entry">FAQ 5.2</a> for information on how submit a fix to an IOCCC entry.</p>
|
||||
<p>You may open a <a href="https://github.com/ioccc-src/winner/pulls">GitHub pull request</a>
|
||||
against the master <a href="https://github.com/ioccc-src/winner/branches">branch</a>
|
||||
against the <a href="https://github.com/ioccc-src/winner/branches">master branch</a>
|
||||
of the <a href="https://github.com/ioccc-src/winner">ioccc-src/winner repo</a>
|
||||
to submit a fix.</p>
|
||||
<p>Please see <a href="#fix_an_entry">FAQ 5.2 How may I submit a fix to an IOCCC
|
||||
entry</a>. See also the <a href="#ull_request">FAQ 6.10 How does someone
|
||||
entry</a>. See also the <a href="#pull_request">FAQ 6.10 How does someone
|
||||
make a change to a file and submit that change as a GitHub pull
|
||||
request</a> for more information about pull requests.</p>
|
||||
<h4 id="some-html-files-should-not-be-directly-modified">Some HTML files should NOT be directly modified</h4>
|
||||
@@ -2263,7 +2265,7 @@ request</a>. There are quicker ways but to be sure you get
|
||||
everything built you should do this. If you modified a markdown and you do not
|
||||
see the same file as a html file then you did not complete the fix.</p>
|
||||
<p>Please see <a href="#fix_an_entry">FAQ 5.2 How may I submit a fix to an IOCCC
|
||||
entry</a>. See also the <a href="#ull_request">FAQ 6.10 How does someone
|
||||
entry</a>. See also the <a href="#pull_request">FAQ 6.10 How does someone
|
||||
make a change to a file and submit that change as a GitHub pull
|
||||
request</a> for more information about pull requests.</p>
|
||||
<p>In some cases, the HTML file is <strong>NOT</strong> based on markdown content, but instead
|
||||
@@ -2303,19 +2305,54 @@ about authors of IOCCC entries. See <a href="#author_json">FAQ 6.6</a> for infor
|
||||
about the contents of these JSON file and how they are used.</p>
|
||||
<p>You may update IOCCC author information in a <code>author_handle.json</code> file
|
||||
by <a href="faq.html#pull_request">submitting a pull request</a>
|
||||
against the master <a href="https://github.com/ioccc-src/winner/branches">branch</a>
|
||||
against the <a href="https://github.com/ioccc-src/winner/branches">master branch</a>
|
||||
of the <a href="https://github.com/ioccc-src/winner">ioccc-src/winner repo</a>.</p>
|
||||
<p>Please see <a href="#fix_an_entry">FAQ 5.2 How may I submit a fix to an IOCCC entry</a>.</p>
|
||||
<p>See also the <a href="#ull_request">FAQ 6.10 How does someone
|
||||
<p>As these files are JSON you should verify that they are validly formed (e.g. you
|
||||
didn’t make a typo).</p>
|
||||
<p>Please make sure that you run <code>make www</code> after updating the file or files. This unfortunately
|
||||
takes quite a while but it is the safest way to do it. There are other ways to go
|
||||
about this that can speed things up. Here is one such way which was done when
|
||||
fixing two authors in 1995 (in one commit as they were the authors of the same
|
||||
two entries):</p>
|
||||
<p>First, the two files, <a href="author/Heather_Downs.json">author/Heather_Downs.json</a> and
|
||||
<a href="author/Selene_Makarios.json">author/Selene_Makarios.json</a> were fixed (the
|
||||
location was set as <code>ZZ</code> but Cody Boone Ferguson knew from the archive that it
|
||||
was the US for both of them and he also noticed that the URL, the same for
|
||||
both, was no longer valid and it was also known that the email was no longer
|
||||
valid as it referred to the same domain). Thus the <code>location_code</code>, <code>url</code> (it was on the Internet Wayback Machine) and
|
||||
in one case the <code>email</code> lines to look like:</p>
|
||||
<pre class="<--json-->"><code> "location_code" : "US",
|
||||
"email" : null,
|
||||
"url" : "https://web.archive.org/web/19961019045145/http://www.bungalow.com/",</code></pre>
|
||||
<p>Now since only two entries (the same entries) were won by these two individuals
|
||||
it means that only two index.html files had to be updated, besides the
|
||||
<a href="authors.html">authors.html</a> and <a href="location.html">location.html</a> files. These
|
||||
are: <a href="1995/heathbar/index.html">1995/heathbar/index.html</a> and
|
||||
<a href="1995/makarios/index.html">1995/makarios/index.html</a>. Thus the following
|
||||
procedure was done:</p>
|
||||
<pre class="<!--sh-->"><code> touch 1995/heathbar/README.md 1995/makarios/README.md
|
||||
make quick_www</code></pre>
|
||||
<p>That works because the <code>quick_www</code> rule will update the <code>authors.html</code> and
|
||||
<code>location.html</code> pages and it will also check the timestamps of the <code>index.html</code>
|
||||
files versus the <code>README.md</code> files. Since they were touched and thus the
|
||||
timestamp was updated, the
|
||||
<a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/bin/quick-readme2index.sh">bin/quick-readme2index.sh</a> tool would
|
||||
only worry about those two files. This greatly speeds things along.</p>
|
||||
<p>Once that command finishes a proper <code>git status</code> and <code>git diff</code> shows that
|
||||
everything is in order. In the end the safest way is to run <code>make www</code>, however.</p>
|
||||
<p>Please see <a href="#fix_an_entry">FAQ 5.2 How may I submit a fix to an IOCCC entry?</a>.</p>
|
||||
<p>See also the <a href="#pull_request">FAQ 6.10 How does someone
|
||||
make a change to a file and submit that change as a GitHub pull
|
||||
request</a> for more information about pull requests.</p>
|
||||
<p><strong>FYI</strong>: The <a href="location.html#ZZ">ZZ - Unknown location</a> is used for
|
||||
historic winning authors whose location or country is not known,
|
||||
whereas the <a href="location.html#XX">XX - Anonymous location</a> is used when the
|
||||
winning author does <strong>not wish to disclose their location</strong>.</p>
|
||||
<h3 id="important-note-about-xx---anonymous-location">Important note about <strong>XX - Anonymous location</strong>:</h3>
|
||||
<p>Unless you are the author who originally selected the <strong>XX - Anonymous
|
||||
location</strong>, please do not attempt to change an <strong>XX - Anonymous
|
||||
location</strong>, without the permission of the original author.</p>
|
||||
location</strong> without the permission of the original author, as sometimes they
|
||||
want to have the location known but not their name and/or other details.</p>
|
||||
<div id="faq5_6">
|
||||
<div id="fix_link">
|
||||
<h2 id="faq-5.6-what-should-i-do-if-i-find-a-broken-or-wrong-web-link">FAQ 5.6: What should I do if I find a broken or wrong web link?</h2>
|
||||
@@ -2535,6 +2572,36 @@ is to look at an example, the <code>author_handle.json</code> file for Yusuke En
|
||||
{ "entry_id" : "2020_endoh3" }
|
||||
]
|
||||
}</code></pre>
|
||||
<p>Before we walk you through the above JSON document, we will show you how to
|
||||
validate that the JSON is validly formed.</p>
|
||||
<div id="validating_json">
|
||||
<h5 id="validating-json-documents">Validating JSON documents</h5>
|
||||
</div>
|
||||
<p>Although special tools (that will validate <code>author_handle.json</code> files) are in
|
||||
the works (which will be documented here after they are developed) there is a
|
||||
way to validate all JSON documents including these files. Until those special
|
||||
tools are developed (which will do the same as this next tool but more) we
|
||||
request that you validate the JSON with this tool that we co-developed with Cody
|
||||
Boone Ferguson. This tool, <code>jparse(1)</code>, for the time being is in the
|
||||
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a> but will later be
|
||||
in a separate repo. In any case you need to download the repo or <code>git clone</code> it
|
||||
and then compile it (cd to the directory and then run <code>make</code>). If you wish to
|
||||
make it easier you can do <code>make install</code> so you can run the tool from any path
|
||||
but in any case the syntax is:</p>
|
||||
<pre class="<!--sh-->"><code> jparse foo.json</code></pre>
|
||||
<p>If the tool exits 0 (and shows no output) then the JSON is valid. If it is
|
||||
invalid you should get an error but for more details you can increase the
|
||||
verbosity with the <code>-v</code> flag like:</p>
|
||||
<pre class="<!--sh-->"><code> jparse -v 3 foo.json</code></pre>
|
||||
<p>If the tool is not installed then you will obviously have to specify the path of
|
||||
the tool.</p>
|
||||
<p>If you wish to validate every JSON file in <code>author/</code> then you could do so like:</p>
|
||||
<pre class="<!--sh-->"><code> for auth in *.json; do jparse 2>/dev/null "$auth" || echo "$auth is invalid JSON" ; done</code></pre>
|
||||
<p>If you see any output then it will say which file or files are invalid JSON
|
||||
(this should not actually happen).</p>
|
||||
<div id="walk_through_author_json">
|
||||
<h5 id="walk-through-of-an-author_handle.json-file">Walk through of an <code>author_handle.json</code> file</h5>
|
||||
</div>
|
||||
<p>We now will walk thru the above JSON document looking at various JSON members:</p>
|
||||
<h5 id="no_comment">no_comment</h5>
|
||||
<pre><code> "no_comment" : "mandatory comment: because comments were removed from the original JSON spec",</code></pre>
|
||||
@@ -2654,6 +2721,9 @@ once used:</p>
|
||||
unknown, it should be the <em>JSON null</em> as the <em>JSON value</em> of this <em>JSON member</em>.
|
||||
For example:</p>
|
||||
<pre><code> "deprecated_twitter_handle" : null,</code></pre>
|
||||
<p>Of course in the future we will not be asking for twitter handles so this means
|
||||
that unless the winner is a previous winner (before we moved to mastodon) this
|
||||
will always be <code>null</code> anyway.</p>
|
||||
<p>NOTE: The <em>JSON null</em> is <strong>NOT</strong> enclosed in quotes!</p>
|
||||
<h5 id="mastodon">mastodon</h5>
|
||||
<pre><code> "mastodon" : "@mame@ruby.social",</code></pre>
|
||||
|
||||
Reference in new issue
Block a user