try.sh and try.alt.sh scripts and why should I use them?try.sh script
system, which we do like, you can have this rule invoke the script
-(./try.sh)../try.sh). See the
+FAQ on the “try.sh scripts system”
+for more details.
Although the mkiocccentry(1) tool only checks for those rules, the most up to
@@ -977,15 +979,15 @@ included in your submission), it can be helpful to include a try.sh
The template try.sh script can be used as a starting point, or you can look at
-some of the others in the website, to get some ideas.
It is not detrimental to your chances of winning if you do not include one as not all submissions can make use of them. Nevertheless, it is helpful to include -ways to use your program, and if you have creative ways this can be a bonus. It -does not mean that a program that cannot be used with other programs is less -interesting or less likely to win, but we do enjoy interesting and creative uses -of submissions.
+ways to use your program and as submitted Makefiles should have atry rule, if
+you have creative ways this can be a bonus. It does not mean that a program that
+cannot be used with other programs is less interesting or less likely to win,
+but we do enjoy interesting and creative uses of submissions.
If you have alternate code that you are including, then you can use the -try.alt.sh template instead.
+try.alt.sh template as well.
We recommend that you include the use of these scripts in the try rule in the
example Makefile that you modify for your submission. See the
FAQ on “submission Makefiles.
The IOCCC judges do welcome questions about the IOCCC and will be happy to help.
Chances are, if you have a question, there are a number of other people who -have similar questions. So we recommend first view the +have similar questions. So we recommend that you first view the GitHub discussions for this repo -so see if someone else asked already. Feel free to join in on such a discussion, +to see if someone else asked it already. Feel free to join in on such a discussion, even if to just say:
I have this question too.
@@ -1162,7 +1164,7 @@ discussion.Jump to: top
-Q 2.2: Are there any compiler warnings that I should not worry about?
+Q 2.2: Are there any compiler warnings that I should not worry about in my submissions?
There are unfortunately some warnings that cannot be disabled; they are always @@ -1347,37 +1349,37 @@ certainly more than 3.
In some years, the IOCCC judges discover a truly amazing IOCCC entry that stands out among all of the other IOCCC entries received that year. -For such an IOCCC entry, the IOCCC judges award a “Grand Prize” -or “Best of Show award.
-In 1984-1987, the grand prize winning entries are:
+For such an IOCCC entry, the IOCCC judges award a “Grand Prize” +or “Best of Show award”. +In 1984-1987, the “
Grand Prize” winning entries are:-
- 1984/mullender
-- 1985/shapiro
-- 1986/wall
-- 1987/lievaart
+- 1984/mullender
+- 1985/shapiro
+- 1986/wall
+- 1987/lievaart
Starting from 1988, the entry we liked the most in that year is called -“Best of Show”. Here are the “Best of Show” entries:
+“Best of Show”. Here are the “Best of Show” entries:-
- 1988/applin
-- 1989/jar.2
-- 1990/theorem
-- 1991/brnstnd
-- 1992/vern
-- 1996/august
-- 1998/banks
-- 2000/jarijyrki
-- 2020/carlini
+- 1988/applin
+- 1989/jar.2
+- 1990/theorem
+- 1991/brnstnd
+- 1992/vern
+- 1996/august
+- 1998/banks
+- 2000/jarijyrki
+- 2020/carlini
In 1993, 1994 and 1995 the judges were unable to select a clear overall winning entry. So to give a nod to the entry that had the highest approval ranking from the judges, they used the following awards:
-
-- 1993/rince - Most Well Rounded
-- 1994/shapiro - Most Well Rounded
-- 1995/leo - Best Use of Obfuscation
+- 1993/rince -
+Most Well Rounded- 1994/shapiro -
+Most Well Rounded- 1995/leo -
Best Use of ObfuscationThese could be considered the ‘best entry’ for those years with 1 or +
These could be considered the ‘
best entry’ for those years with 1 or more other entries that came in close behind.Jump to: top
@@ -2997,7 +2999,7 @@ There are only a few cases whenOK_to_editneeds to befalse<Modifications of the original source code is only permitted it can be shown at the file is not the true original source code.
See the -FAQ on “original source code” +FAQ on “original source code” for more information including how to open an IOCCC issue if you believe the original source code is not a true original.
@@ -3216,12 +3218,12 @@ versions:
make altThe following Makefile rules should be in all Makefiles:
-
- all: build the entry programs (main program and any supplementary program)
-- alt: build alternate code
-- clobber: clean up object files and all binary files (except for those that are +
- +
all: build the entry programs (main program and any supplementary program)- +
alt: build alternate code- -
clobber: clean up object files and all binary files (except for those that are not compiled)- clean: a simpler version of
-clobberthat only removes object files.make clobberdepends oncleanso runningmake clobberwill invokemake clean.- everything: equivalent to
+make all alt.- +
clean: a simpler version ofclobberthat only removes object files.make clobberdepends oncleanso runningmake clobberwill invokemake clean.everything: equivalent tomake all alt.Are there any other rules? You tell us!
The top level and the year (e.g.
1984/Makefile,1985/Makefileetc.) @@ -3872,7 +3874,7 @@ than Linux (due to versions and possibly other things)!Given that your entry MUST work as documented, you may be safer to say that your entry keeps the number of warnings and
-Wno-foooptions while compiling withclang -Weverythingat a minimum. You might want to say the -version number and platform too as an extra safety net. Because if you claim zero +version number and platform (OS and OS version) too as an extra safety net. Because if you claim zero warnings, and we find a warning situation, this may diminish the value of your entry as it is not as documented. Thus it might be wise to point this out and if you can test it in multiple platforms (or versions ofclang, see @@ -3922,7 +3924,7 @@ help.Jump to: top
-Q 7.2: Why does an IOCCC entry fail to run?
+Q 7.2: Why does an IOCCC entry fail to compile and/or run?
What may have worked years ago may not work well or work at all today. @@ -3956,12 +3958,16 @@ for how to submit a fix to an IOCCC entry.
Jump to: top
-Q 7.2.1: Why does an IOCCC entry fail to run on my 64-bit system?
++++Q 7.2.1: Why does an IOCCC entry fail to compile and/or run run on my 64-bit system?
+Unfortunately some older entries are non-portable and require 32-bit support or -32-bit binaries. A problem system here is macOS Catalina (10.15) as as of that -version macOS no longer supports 32-bit binaries. If the entry acts on a certain +32-bit binaries. A problem system here is that as of macOS Catalina (10.15) +macOS no longer supports 32-bit binaries. If the entry acts on a certain type of binary, say ELF, then that will also be a problem depending on the entry. For example 2001/anonymous requires 32-bit ELF binaries.
diff --git a/faq.md b/faq.md index 05daeeca2..5c09e5e49 100644 --- a/faq.md +++ b/faq.md @@ -26,7 +26,7 @@ This is FAQ version **28.1.8 2024-12-07**. ## 2. [IOCCC Judging process](#judging) - **Q 2.0**: What is the best way to ask a question about the IOCCC rules, guideline and tools? - **Q 2.1**: How can I comment or make a suggestion on IOCCC rules, guidelines and tools? -- **Q 2.2**: Are there any compiler warnings that I should not worry about? +- **Q 2.2**: Are there any compiler warnings that I should not worry about in my submissions? - **Q 2.3**: What types of entries have been frequently submitted to the IOCCC? - **Q 2.4**: How did an entry that breaks the size rule 2 win the IOCCC? - **Q 2.5**: How many submissions do the judges receive for a given IOCCC? @@ -74,15 +74,15 @@ This is FAQ version **28.1.8 2024-12-07**. ## 6. [Problems compiling IOCCC entries](#compile_problems) - **Q 6.0**: Why don't certain IOCCC entries compile and/or run? - - **Q 6.1.1**: Why do some IOCCC entries fail to compile under macOS? + - **Q 6.1.1**: Why do some IOCCC entries fail to compile and/or run under macOS? - **Q 6.2**: Why do Makefiles use -Weverything with clang? ## 7. [Running IOCCC entries](#running_entries) - **Q 7.0**: What are `try.sh` and `try.alt.sh` scripts and why should I use them? - **Q 7.1**: An IOCCC entry messed up my terminal application, how do I fix this? -- **Q 7.2**: Why does an IOCCC entry fail to run? - - **Q 7.2.1**: Why does an IOCCC entry fail to run on my 64-bit system? +- **Q 7.2**: Why does an IOCCC entry fail to compile and/or run? + - **Q 7.2.1**: Why does an IOCCC entry fail to compile and/or run on my 64-bit system? - **Q 7.3**: How do I find out how to send interrupt/EOF etc. for entries that require it? - **Q 7.4**: How do I download individual winning entries or all winning entries of a given year? @@ -612,7 +612,9 @@ The following rules should exist in your Makefile: - `try` * run the program in a way you suggest. If you use the `try.sh` script system, which we do like, you can have this rule invoke the script - (`./try.sh`). + (`./try.sh`). See the + FAQ on the "[try.sh scripts system](#try_scripts)" + for more details. Although the `mkiocccentry(1)` tool only checks for those rules, the most up to date @@ -690,17 +692,17 @@ included in your submission), it can be helpful to include a `try.sh` script: The template `try.sh` script can be used as a starting point, or you can look at -some of the others in the website, to get some ideas. +some of the others in past winning entries, to get some ideas. It is not detrimental to your chances of winning if you do not include one as not all submissions can make use of them. Nevertheless, it is helpful to include -ways to use your program, and if you have creative ways this can be a bonus. It -does not mean that a program that cannot be used with other programs is less -interesting or less likely to win, but we do enjoy interesting and creative uses -of submissions. +ways to use your program and as submitted Makefiles should have a `try` rule, if +you have creative ways this can be a bonus. It does not mean that a program that +cannot be used with other programs is less interesting or less likely to win, +but we do enjoy interesting and creative uses of submissions. If you have alternate code that you are including, then you can use the -[try.alt.sh template](next/try.alt.sh) instead. +`try.alt.sh` template as well. We recommend that you include the use of these scripts in the `try` rule in the example Makefile that you modify for your submission. See the @@ -869,9 +871,9 @@ The [IOCCC judges](judges.html) do welcome questions about the IOCCC and will be **happy to help**. Chances are, if you have a question, there are a number of other people who -have similar questions. So we recommend first view the +have similar questions. So we recommend that you first view the [GitHub discussions for this repo](https://github.com/ioccc-src/winner/discussions) -so see if someone else asked already. Feel free to join in on such a discussion, +to see if someone else asked it already. Feel free to join in on such a discussion, even if to just say: > I have this question too. @@ -945,7 +947,7 @@ Jump to: [top](#)@@ -1185,39 +1187,39 @@ Jump to: [top](#) In some years, the IOCCC judges discover a truly amazing IOCCC entry that stands out among all of the other IOCCC entries received that year. -For such an IOCCC entry, the IOCCC judges award a "Grand Prize" -or "Best of Show award. +For such an IOCCC entry, the IOCCC judges award a "`Grand Prize`" +or "`Best of Show award`". -In 1984-1987, the grand prize winning entries are: +In 1984-1987, the "`Grand Prize`" winning entries are: -- [1984/mullender](years.html#1984_mullender) -- [1985/shapiro](years.html#1985_shapiro) -- [1986/wall](years.html#1986_wall) -- [1987/lievaart](years.html#1987_lievaart) +- [1984/mullender](1984/mullender/index.html) +- [1985/shapiro](1985/shapiro/index.html) +- [1986/wall](1986/wall/index.html) +- [1987/lievaart](1987/lievaart/index.html) Starting from 1988, the entry we liked the most in that year is called -"Best of Show". Here are the "Best of Show" entries: +"`Best of Show`". Here are the "`Best of Show`" entries: -- [1988/applin](years.html#1988_applin) -- [1989/jar.2](years.html#1989_jar.2) -- [1990/theorem](years.html#1990_theorem) -- [1991/brnstnd](years.html#1991_brnstnd) -- [1992/vern](years.html#1992_vern) -- [1996/august](years.html#1996_august) -- [1998/banks](years.html#1998_banks) -- [2000/jarijyrki](years.html#2000_jarijyrki) -- [2020/carlini](years.html#2020_carlini) +- [1988/applin](1988/applin/index.html) +- [1989/jar.2](1989/jar.2/index.html) +- [1990/theorem](1990/theorem/index.html) +- [1991/brnstnd](1991/brnstnd/index.html) +- [1992/vern](1992/vern/index.html) +- [1996/august](1996/august/index.html) +- [1998/banks](1998/banks/index.html) +- [2000/jarijyrki](2000/jarijyrki/index.html) +- [2020/carlini](2020/carlini/index.html) In 1993, 1994 and 1995 the judges were unable to select a clear overall winning entry. So to give a nod to the entry that had the highest approval ranking from the judges, they used the following awards: -- [1993/rince](years.html#1993_rince) - Most Well Rounded -- [1994/shapiro](years.html#1994_shapiro) - Most Well Rounded -- [1995/leo](years.html#1995_leo) - Best Use of Obfuscation +- [1993/rince](1993/rince/index.html) - `Most Well Rounded` +- [1994/shapiro](1994/shapiro/index.html) - `Most Well Rounded` +- [1995/leo](1995/leo/index.html) - `Best Use of Obfuscation` -These could be considered the 'best entry' for those years with 1 or +These could be considered the '`best entry`' for those years with 1 or more other entries that came in close behind. Jump to: [top](#) @@ -3231,7 +3233,7 @@ Now we will describe each field of each file in the manifest: be shown at the file is not the true **original source code**. See the - FAQ on "[original source code](#original_source_file)" + FAQ on "[original source code](#orig_c)" for more information including how to open an [IOCCC issue](https://github.com/ioccc-src/winner/issues) if you believe the **original source code** is not a true original. @@ -3503,13 +3505,13 @@ versions: The following Makefile rules should be in all Makefiles: -- all: build the entry programs (main program and any supplementary program) -- alt: build alternate code -- clobber: clean up object files and all binary files (except for those that are +- `all`: build the entry programs (main program and any supplementary program) +- `alt`: build alternate code +- `clobber`: clean up object files and all binary files (except for those that are not compiled) -- clean: a simpler version of `clobber` that only removes object files. `make +- `clean`: a simpler version of `clobber` that only removes object files. `make clobber` depends on `clean` so running `make clobber` will invoke `make clean`. -- everything: equivalent to `make all alt`. +- `everything`: equivalent to `make all alt`. Are there any other rules? You tell us! @@ -4657,7 +4659,7 @@ than Linux (due to versions and possibly other things)! Given that your entry **MUST** work as documented, you may be safer to say that your entry keeps the number of warnings and `-Wno-foo` options while compiling with `clang -Weverything` at a minimum. You might want to say the -version number and platform too as an extra safety net. Because if you claim zero +version number and platform (OS and OS version) too as an extra safety net. Because if you claim zero warnings, and we find a warning situation, this may diminish the value of your entry as it is not as documented. Thus it might be wise to point this out and if you can test it in multiple platforms (or versions of `clang`, see @@ -4726,7 +4728,7 @@ Jump to: [top](#)-### Q 2.2: Are there any compiler warnings that I should not worry about? +### Q 2.2: Are there any compiler warnings that I should not worry about in my submissions?@@ -4770,13 +4772,17 @@ Jump to: [top](#)-### Q 7.2: Why does an IOCCC entry fail to run? +### Q 7.2: Why does an IOCCC entry fail to compile and/or run?Unfortunately some older entries are non-portable and require 32-bit support or -32-bit binaries. A problem system here is macOS Catalina (10.15) as as of that -version macOS no longer supports 32-bit binaries. If the entry acts on a certain +32-bit binaries. A problem system here is that as of macOS Catalina (10.15) +macOS no longer supports 32-bit binaries. If the entry acts on a certain type of binary, say ELF, then that will also be a problem depending on the entry. For example [2001/anonymous](2001/anonymous/index.html) requires 32-bit ELF binaries. diff --git a/next/try.alt.sh b/next/try.alt.sh index 459d92974..d825182cb 100644 --- a/next/try.alt.sh +++ b/next/try.alt.sh @@ -1,9 +1,9 @@ #!/usr/bin/env bash # # try.alt.sh - demonstrate IOCCC entry YYYY/foo alternate code -# XXX - try.alt.sh example version: 1.0.0-1 11-28-2024 - XXX +# XXX - try.alt.sh example version: 1.0.0-1 11-28-2024 - XXX # -# XXX - NOTE: if your submission wins and become an entry, then - XXX +# XXX - NOTE: if your submission wins and becomes an entry, then - XXX # XXX - YYYY/foo will be changed to the 4 digit year and directory - XXX # XXX - name. - XXX # XXX - NOTE: please remove the XXX lines in this file, including this one - XXX diff --git a/next/try.sh b/next/try.sh index ad9eb97dd..ac6952211 100644 --- a/next/try.sh +++ b/next/try.sh @@ -1,9 +1,9 @@ #!/usr/bin/env bash # # try.sh - demonstrate IOCCC entry YYYY/foo -# XXX - try.sh example version: 1.0.0-1 11-28-2024 - XXX +# XXX - try.sh example version: 1.0.0-1 11-28-2024 - XXX -# XXX - NOTE: if your submission wins and become an entry, then - XXX +# XXX - NOTE: if your submission wins and becomes an entry, then - XXX # XXX - YYYY/foo will be changed to the 4 digit year and directory - XXX # XXX - name. - XXX # XXX - NOTE: please remove the XXX lines in this file, including this one - XXX diff --git a/thanks-for-help.html b/thanks-for-help.html index 06f578506..bd6789bb3 100644 --- a/thanks-for-help.html +++ b/thanks-for-help.html @@ -5053,8 +5053,10 @@ compilers. See the index.html for more details.-### Q 7.2.1: Why does an IOCCC entry fail to run on my 64-bit system? +++### Q 7.2.1: Why does an IOCCC entry fail to compile and/or run run on my 64-bit system? ++Jump to: top
++Makefiles fixes and improvements
Cody fixed the top level
Makefileallrule which had a strayfi;without anifso the rule failed entirely.Cody also made a variety of other changes in all the Makefiles, sometimes to get @@ -5172,29 +5174,30 @@ helped improve the presentation of their fellow IOCCC entries.
We call out the extensive contributions of Cody Boone Ferguson who is responsible for many -improvements and fixes, including entries that no longer worked -and other important fixes, often EXTREMELY HARD (for certain +improvements and fixes, including fixing many entries that no longer +worked, +often EXTREMELY HARD (for certain definitions of ‘
+obfuscation, to work as much as possible); porting entries like +1998/schweikh1 to +macOS; fixing code like +2001/herrmann2 to work in both 32-bit and +64-bit; providing alternate code where useful/necessary; +improving all Makefiles; writing scripts to greatly simplify running many +of the entries; and other important fixes.HARD’ :-) ), such as 1988/phillipps, 1992/vern, 2001/anonymous, 2004/burley and -2005/giljade; fixing entries such as +2005/giljade; fixing entries like 1985/sicherman and 1986/wall to not require-traditional-cpp; fixing -entries like 1991/dds to work withclang(or, as in the case of +entries like 1991/dds to work with +clang (or, as in the case of 1989/westley, a true masterpiece in -obfuscation, to work as much as possible); porting entries such as -1998/schweikh1 to macOS; fixing code like -2001/herrmann2 to work in both 32-bit and -64-bit; providing alternate code where useful/necessary; -improving allMakefiles; and writing scripts to greatly simplify running many -of the entries.Cody also wrote the feature-rich sgit to easily -run
+runsed(1)on files in the repo which we used to help build the website. He -also co-developed the JSON parser and tools with us, as the -website makes extensive use of JSON.sed(1)on files in the repo which we used earlier on to help build the website.Cody Boone Ferguson also used one of his own tools to detect many dead links. While the tool was not perfect it went a long way to uncover a good number of bad, broken or otherwise invalid links. It was a very laborious task to copy and @@ -5206,14 +5209,15 @@ invalid links are thanks to Cody’s efforts! Another tool he wrote detected inconsistent award titles in the
README.mdfiles (used to generate theindex.htmlfiles) and the CSV file that he generated from our SQL file.Cody also greatly improved the manifests and checked that the generated html -files look well and are presentable, suggested some CSS rules for -image responsiveness on smaller screens along with some other improvements, -greatly improved the FAQ.
-Cody also wrote some of the website scripts and improved and -bug fixed others.
+files look good and are presentable, suggested CSS rules for +image responsiveness and other improvements, and greatly improved the FAQ. +Cody also wrote some of the website scripts, improved and +bug fixed others, co-developed the JSON parser and tools with +us, as we now make extensive use of JSON, and helped test and fix the submit +server for IOCCC28 and beyond.
THANK YOU VERY MUCH for your extensive efforts in helping improve the IOCCC -presentation of past IOCCC entries and fixing almost all entries that no -longer worked, for modern systems!
+presentation of past IOCCC entries, fixing almost all entries that no +longer worked and getting the IOCCC where it is today!Jump to: top
Yusuke Endoh
@@ -5221,7 +5225,7 @@ longer worked, for modern systems!Yusuke Endoh supplied a number of important bug fixes to a number of past IOCCC entries, including fixing numerous entries that no longer worked. Some of those -fixes were EXTREMELY TECHNICALLY CHALLENGING, such as +fixes were EXTREMELY TECHNICALLY CHALLENGING, like 1989/robison, 1990/cmills, 1992/lush and diff --git a/thanks-for-help.md b/thanks-for-help.md index 902ddb323..3c39d2ed5 100644 --- a/thanks-for-help.md +++ b/thanks-for-help.md @@ -6944,8 +6944,10 @@ Jump to: [top](#) Jump to: [top](#)
+[Cody](#cody) fixed the top level `Makefile` `all` rule which had a stray `fi;` without an `if` so the rule failed entirely. @@ -7111,30 +7113,31 @@ Jump to: [top](#) We call out the extensive contributions of [Cody Boone Ferguson](authors.html#Cody_Boone_Ferguson) who is responsible for many -improvements and fixes, including entries that no longer worked -and other important fixes, often **EXTREMELY HARD** (for certain +improvements and fixes, including fixing many [entries that no longer +worked](faq.html#unsupported), +often **EXTREMELY HARD** (for certain definitions of '`HARD`' :-) ), such as [1988/phillipps](thanks-for-help.html#1988_phillipps), [1992/vern](thanks-for-help.html#1992_vern), [2001/anonymous](thanks-for-help.html#2001_anonymous), [2004/burley](thanks-for-help.html#2004_burley) and -[2005/giljade](thanks-for-help.html#2005_giljade); fixing entries such as +[2005/giljade](thanks-for-help.html#2005_giljade); fixing entries like [1985/sicherman](thanks-for-help.html#1985_sicherman) and [1986/wall](thanks-for-help.html#1986_wall) to not require `-traditional-cpp`; fixing -entries like [1991/dds](thanks-for-help.html#1991_dds) to work with `clang` (or, as in the case of +entries like [1991/dds](thanks-for-help.html#1991_dds) to work with +[clang](faq.html#clang) (or, as in the case of [1989/westley](thanks-for-help.html#1989_westley), a true masterpiece in -obfuscation, to work as much as possible); porting entries such as -[1998/schweikh1](thanks-for-help.html#1998_schweikh1) to macOS; fixing code like -[2001/herrmann2](thanks-for-help.html#2001_herrmann2) to work in both 32-bit and -64-bit; providing [alternate code](faq.html#alt_code) where useful/necessary; -improving all `Makefiles`; and writing scripts to greatly simplify running many -of the entries. +obfuscation, to work as much as possible); porting entries like +[1998/schweikh1](thanks-for-help.html#1998_schweikh1) to +[macOS](faq.html#macos_compile); fixing code like +[2001/herrmann2](thanks-for-help.html#2001_herrmann2) to work in [both 32-bit and +64-bit](faq.html#32bit); providing [alternate code](faq.html#alt_code) where useful/necessary; +improving all [Makefiles](#makefiles); writing [scripts](#try) to greatly simplify running many +of the entries; and other important fixes. Cody also wrote the feature-rich [sgit](https://github.com/xexyl/sgit) to easily -run `sed(1)` on files in the repo which we used to help build the website. He -also co-developed the [JSON parser and tools](faq.html#jparse) with us, as the -website makes extensive use of JSON. +run `sed(1)` on files in the repo which we used earlier on to help build the website. Cody Boone Ferguson also used one of his own tools to detect many dead links. While the tool was not perfect it went a long way to uncover a good number of @@ -7148,16 +7151,17 @@ inconsistent award titles in the `README.md` files (used to generate the `index.html` files) and the CSV file that he generated from our SQL file. Cody also greatly improved the manifests and checked that the generated html -files look well and are presentable, suggested some CSS rules for -image responsiveness on smaller screens along with some other improvements, -greatly improved the FAQ. +files look good and are presentable, suggested CSS rules for +image responsiveness and other improvements, and greatly improved the FAQ. -Cody also wrote some of the [website scripts](bin/index.html) and improved and -bug fixed others. +Cody also wrote some of the [website scripts](bin/index.html), improved and +bug fixed others, co-developed the [JSON parser and tools](https://github.com/xexyl/jparse) with +us, as we now make extensive use of JSON, and helped test and fix the submit +server for IOCCC28 and beyond. **THANK YOU VERY MUCH** for your extensive efforts in helping improve the IOCCC -presentation of past IOCCC entries and fixing almost all entries that no -longer worked, for modern systems! +presentation of past IOCCC entries, fixing almost all entries that no +longer worked and getting the IOCCC where it is today! Jump to: [top](#) @@ -7170,7 +7174,7 @@ Jump to: [top](#) [Yusuke Endoh](authors.html#Yusuke_Endoh) supplied a number of important bug fixes to a number of past IOCCC entries, including **fixing _numerous entries_ that no longer worked**. Some of those -fixes were **EXTREMELY TECHNICALLY CHALLENGING**, such as +fixes were **EXTREMELY TECHNICALLY CHALLENGING**, like [1989/robison](thanks-for-help.html#1989_robison), [1990/cmills](thanks-for-help.html#1990_cmills), [1992/lush](thanks-for-help.html#1992_lush) and## Makefiles fixes and improvements+