From 1c471d8ecd95eb021be02066752e12e2847cd7bc Mon Sep 17 00:00:00 2001 From: Cody Boone Ferguson <53008573+xexyl@users.noreply.github.com> Date: Tue, 30 Apr 2024 10:05:00 -0700 Subject: [PATCH] Fix 2013/hou/Makefile for a.c I noticed a problem with my improvement to the Makefile allowing one to not use a temporary file so although the 'all' rule uses that method one can still generate a.c so one can follow the author's remarks. Links to this file were changed to code blocks, however, as the file does not always exist. make clobber will remove a and a.c. --- 2013/hou/Makefile | 12 +++++++++++- 2013/hou/README.md | 26 ++++++++++++++------------ 2013/hou/index.html | 24 ++++++++++++------------ 3 files changed, 37 insertions(+), 25 deletions(-) diff --git a/2013/hou/Makefile b/2013/hou/Makefile index 2f9f0f460..b85928351 100644 --- a/2013/hou/Makefile +++ b/2013/hou/Makefile @@ -114,6 +114,9 @@ OBJ= ${PROG}.o DATA= luna.jpg old_default.jpg otherroom.jpg otherroom.scene \ doc/camera.png doc/cosine.png doc/draft.png doc/example.md TARGET= ${PROG} +OTHER_PROG= a +OTHER_SRC= a.c +OTHER_OBJ= a.o # ALT_OBJ= ALT_TARGET= @@ -135,6 +138,13 @@ ${PROG}: ${PROG}.c ${CC} ${CFLAGS} $< -o $@ ${LDFLAGS} ./${PROG} | ${CC} ${CFLAGS} -x c - -o $@ ${LDFLAGS} +${OTHER_PROG}: ${PROG}.c + ${CC} ${CFLAGS} $< -o $@ ${LIBS} + +${OTHER_SRC}: ${OTHER_PROG} + ${RM} -f $@ + ./${OTHER_PROG} > $@ + # alternative executable # @@ -207,7 +217,7 @@ clean: clobber: clean ${RM} -f ${TARGET} ${ALT_TARGET} - ${RM} -rf *.dSYM luna.ppm old_default.ppm otherroom.ppm + ${RM} -rf *.dSYM luna.ppm old_default.ppm otherroom.ppm a a.c @-if [ -e sandwich ]; then \ ${RM} -f sandwich; \ echo 'ate sandwich'; \ diff --git a/2013/hou/README.md b/2013/hou/README.md index 2aff2b7ba..d470f493c 100644 --- a/2013/hou/README.md +++ b/2013/hou/README.md @@ -65,16 +65,18 @@ program. This program will loop infinitely while progressively refining a [raytraced](https://en.wikipedia.org/wiki/Ray_tracing_(graphics)) image. -NOTE: the author refers to [a.c](%%REPO_URL%%/2013/hou/a.c), placed in a gzipped file `a.c.gz`. We do not +NOTE: the author refers to `a.c`, placed in a gzipped file `a.c.gz`. We do not include it but it can be generated like: ``` - cc -Wall hou.c -o hou -lm - ./hou > a.c + make a.c ``` -but there is no need to do this as the Makefile takes care of it without even -needing to create a temporary file. +There is no longer a need to do this as the Makefile takes care of it without +even needing to create a temporary file but as the author refers to it and its +uses it can still be generated to follow along. + + ## Author's remarks: @@ -148,15 +150,15 @@ restrictions](#self-imposed-restrictions) section below for more details. * Neither [hou.c](%%REPO_URL%%/2013/hou/hou.c) nor [a.c](%%REPO_URL%%/2013/hou/a.c) (the *real* decompressed source) uses `#define` (or `cc -D`) at all. * The source code is not required at runtime. -* [a.c](%%REPO_URL%%/2013/hou/a.c) does not drop optional features to reduce size. There are pure +* `a.c` does not drop optional features to reduce size. There are pure optimization code that can be dropped without affecting the converged output (only affecting the ray tracing speed / convergence rate). All files are properly `fopen()`ed with `"rb"` / `"wb"` for Windows compatibility. The PPM header has a comment line for non-standard-compliant viewers (specifically, my old HDRShop 1.0). And there is a nice text message saying "please wait...". -Despite the messy look, [a.c](%%REPO_URL%%/2013/hou/a.c) and [hou.c](%%REPO_URL%%/2013/hou/hou.c) compile warning-free +Despite the messy look, `a.c` and [hou.c](%%REPO_URL%%/2013/hou/hou.c) compile warning-free ([hou.c](%%REPO_URL%%/2013/hou/hou.c) even wastes 18 bytes on `#include` just for `putchar(3)`). -[a.c](%%REPO_URL%%/2013/hou/a.c) compiles mostly clean in the C99/ANSI modes of clang and gcc (with: +`a.c` compiles mostly clean in the C99/ANSI modes of clang and gcc (with: ``` -Wall --pedantic @@ -178,15 +180,15 @@ internal states. the code, but they leave the text clear in the *result*. This entry takes it further and obfuscates the output image as well. Can you find the text in the image? Hint: look up. -* [a.c](%%REPO_URL%%/2013/hou/a.c) leaves all shaders in plain text, but the plain text shader code can't +* `a.c` leaves all shaders in plain text, but the plain text shader code can't be taken for its face value; the arithmetic rules subtly diverge from our common sense. -* [a.c](%%REPO_URL%%/2013/hou/a.c) is less portable than [hou.c](%%REPO_URL%%/2013/hou/hou.c) itself. [hou.c](%%REPO_URL%%/2013/hou/hou.c) only depends +* `a.c` is less portable than [hou.c](%%REPO_URL%%/2013/hou/hou.c) itself. [hou.c](%%REPO_URL%%/2013/hou/hou.c) only depends on ASCII and should run just fine on 16-bit, small memory, or -floating-point-incapable machines. [a.c](%%REPO_URL%%/2013/hou/a.c), while still reasonably portable, is +floating-point-incapable machines. `a.c`, while still reasonably portable, is quite memory consuming, requires IEEE754-compliant `double`, and assumes `int` to be 32-bits. -* Though technically endian-dependent, [a.c](%%REPO_URL%%/2013/hou/a.c) remains portable providing that one +* Though technically endian-dependent, `a.c` remains portable providing that one doesn't copy saved sessions across different endianness. diff --git a/2013/hou/index.html b/2013/hou/index.html index 61eb14af3..ec98be038 100644 --- a/2013/hou/index.html +++ b/2013/hou/index.html @@ -431,12 +431,12 @@ really just a decompressor to generate the real source code of the program.

This program will loop infinitely while progressively refining a raytraced image.

-

NOTE: the author refers to a.c, placed in a gzipped file a.c.gz. We do not +

NOTE: the author refers to a.c, placed in a gzipped file a.c.gz. We do not include it but it can be generated like:

-
    cc -Wall hou.c -o hou -lm
-    ./hou > a.c
-

but there is no need to do this as the Makefile takes care of it without even -needing to create a temporary file.

+
    make a.c
+

There is no longer a need to do this as the Makefile takes care of it without +even needing to create a temporary file but as the author refers to it and its +uses it can still be generated to follow along.

Author’s remarks:

Using hou

This program is a programmable rendering engine with a built-in default scene. @@ -497,15 +497,15 @@ restrictions section below for more details.

  • Neither hou.c nor a.c (the real decompressed source) uses #define (or cc -D) at all.
  • The source code is not required at runtime.
    • -
  • a.c does not drop optional features to reduce size. There are pure +
  • a.c does not drop optional features to reduce size. There are pure optimization code that can be dropped without affecting the converged output (only affecting the ray tracing speed / convergence rate). All files are properly fopen()ed with "rb" / "wb" for Windows compatibility. The PPM header has a comment line for non-standard-compliant viewers (specifically, my old HDRShop 1.0). And there is a nice text message saying “please wait…”. -Despite the messy look, a.c and hou.c compile warning-free +Despite the messy look, a.c and hou.c compile warning-free (hou.c even wastes 18 bytes on #include<stdio.h> just for putchar(3)). -a.c compiles mostly clean in the C99/ANSI modes of clang and gcc (with:
    • +a.c compiles mostly clean in the C99/ANSI modes of clang and gcc (with: 
    -Wall --pedantic

    The only warning generated is a pedantic one: "string constant too long".

    @@ -521,15 +521,15 @@ internal states. the code, but they leave the text clear in the result. This entry takes it further and obfuscates the output image as well. Can you find the text in the image? Hint: look up. -
  • a.c leaves all shaders in plain text, but the plain text shader code can’t +
  • a.c leaves all shaders in plain text, but the plain text shader code can’t be taken for its face value; the arithmetic rules subtly diverge from our common sense.
    • -
  • a.c is less portable than hou.c itself. hou.c only depends +
  • a.c is less portable than hou.c itself. hou.c only depends on ASCII and should run just fine on 16-bit, small memory, or -floating-point-incapable machines. a.c, while still reasonably portable, is +floating-point-incapable machines. a.c, while still reasonably portable, is quite memory consuming, requires IEEE754-compliant double, and assumes int to be 32-bits.
    • -
  • Though technically endian-dependent, a.c remains portable providing that one +
  • Though technically endian-dependent, a.c remains portable providing that one doesn’t copy saved sessions across different endianness.

    • Spoiler