The full source is one C file.

What it does

It walks a C source tree and inlines all #include "local.h" directives recursively. System includes (<stdio.h>) pass through untouched. The result is one .c file you can paste anywhere.

./amalgamate main.c utils.c > squashed.c

Pass every .c that contributes symbols. Order matters: the compiler sees the file top to bottom, definitions before use.

Build on Linux or MSYS2 UCRT64:

gcc -std=c99 -Wall -Wextra -o amalgamate amalgamate.c

Resolution order

For each #include "name.h" the tool tries, in order: the directory of the including file, each -I path, then cwd. System includes (<name.h>) are never touched.

./amalgamate -I include/ -I vendor/include/ main.c utils.c > squashed.c

Both -I dir and -Idir forms work, matching gcc convention.

What works

The typical multi-file C project amalgamates cleanly. Given a layout like:

main.c     -- includes utils.h, math.h
utils.c    -- defines add(), and sub() not declared in utils.h
math.c     -- defines mul(), and square() not declared in math.h
types.h    -- shared typedefs, included by both utils.h and math.h

Header guards (#ifndef) survive intact. types.h is inlined every time it appears, but the preprocessor deduplicates it. That is the right behavior — the tool doesn’t second-guess the preprocessor.

Symbols not declared in any header (sub, square above) are present in the output because their .c files were passed explicitly. The caller must extern-declare them. Same constraint as with a normal linker.

What breaks

Colliding static names across translation units.

static limits linkage, not scope. In separate TUs the compiler never sees both definitions. In a single TU it does. C99 forbids two definitions of the same name in the same scope, even if both are static.

This compiles fine as separate TUs:

/* utils.c */
static i32 helper(void) { return 1; }

/* math.c */
static double helper(void) { return 3.14; }  /* same name, different type */

Amalgamated, it fails:

error: conflicting types for 'helper'; have 'double(void)'
note: previous definition of 'helper' with type 'i32(void)'

The fix is manual: adopt a prefix convention before amalgamating.

/* utils.c */
static i32 utils_helper(void) { return 1; }

/* math.c */
static double math_helper(void) { return 3.14; }

The tool cannot rename symbols. That requires a parser. This tool is not a parser.

Include cycles are detected and fatal:

include cycle detected: /src/cycle_a.h
  /src/main.c
  /src/cycle_a.h
  /src/cycle_b.h

That is always a bug in the source. Fix the source.

Flags

--with-line emits #line directives around each inlined file. Without them, a compiler error in the amalgamated output gives a line number that maps to nothing in your editor. With them, errors point back to the original file.

./amalgamate --with-line main.c utils.c > squashed.c

--once skips a file if already emitted. Useful for projects that use #pragma once instead of header guards, or to avoid redundant inlining across many TUs.

--list prints the resolved path of every file that would be inlined, without producing output. Useful for auditing the dependency tree.

./amalgamate --list main.c utils.c

-x file excludes a specific file from inlining. The #include is replaced with a tombstone comment; the compiler sees nothing. Useful when one header must remain external.

-o outfile writes to a file instead of stdout.

-v prints the include tree to stderr, indented by depth.

Keep it small.

Several frameworks emerged to answer that question. Let me go through the most common ones, with practical examples.

Why bother with a framework ?

A prompt is just text. Yet, a poorly written prompt yields a poor result. A well-structured one yields a precise, useful one.

The frameworks are just mnemonics. They are a checklist to avoid forgetting important context. Nothing more, nothing less.

A good framework makes the right path the easy path. Without one, the path of least resistance is to skip context entirely.

Think of them the same way one might think of 1OPS : the rule itself is simple, but its value comes from discipline — not from the rule.

CRAFT

Context, Role, Action, Format, Target

The most widely used one. Easy to remember, covers most cases.

Context: Building a 2D platformer in C99
Role:    Senior game engine developer
Action:  Write an AABB collision detection system
Format:  Annotated C99, Linux kernel style
Target:  Embedded / low-level developers

A good default. Start here.

RISEN

Role, Instructions, Steps, End goal, Narrowing

Better suited for multi-step tasks where the order matters.

Role:         Physics programmer
Instructions: Implement sweep-and-prune broadphase
Steps:        1) Define axis-sorted list  2) Find overlapping pairs  3) Output pair buffer
End goal:     Reusable broadphase module
Narrowing:    C99, no dynamic allocation, < 300 lines

The Narrowing part is the most valuable addition over CRAFT. It is where you exclude what you don’t want — which is often as important as what you do want.

Saying “no dynamic allocation” is more useful than any amount of positive description. The model cannot read your mind, but it can follow a constraint.

CREATE

Character, Request, Extras, Adjustments, Type, Extras¹

More creative and generative in orientation. The double Extras is intentional : first pass for constraints, second pass for polish.

Character:   Senior graphics programmer
Request:     Implement a sprite batch renderer
Extras:      Must sustain 10k sprites @ 60fps
Adjustments: Vulkan only, no OpenGL
Type:        C99 source file
Extras:      Inline performance notes

The distinction between Extras and Adjustments is subtle but useful : Extras adds, Adjustments redirects.

CARE

Context, Ask, Rules, Examples

Best when you have concrete I/O examples. Closest to a proper specification.

Context:  Tile-based binary map loader
Ask:      Parse format into a struct
Rules:    No malloc, fixed buffers, C99 only
Examples: [binary sample] → [expected struct output]

The Examples part is the killer feature here. An LLM guided by examples makes far fewer wrong assumptions.

The Rules field deserves equal attention. What you forbid is as load-bearing as what you permit : an unconstrained surface invites the wrong solution every time.

This maps directly to how always optimizing for junior devs works in code : concrete examples remove ambiguity faster than any amount of prose.

CLEAR

Concise, Logical, Explicit, Audience, Role

A meta-framework of sorts. Less about structure, more about quality attributes of each component.

Concise:   "Write a ring buffer"
Logical:   "for audio streaming, SPSC"
Explicit:  "thread-safe via atomics, no locks"
Audience:  Embedded C developers
Role:      DSP systems programmer

Useful as a review checklist once the prompt is written rather than as a writing guide. Run it after CRAFT, not instead of it.

Comparison

In practice

No need to pick one and stick to it forever. CRAFT covers ~80% of daily use. Reach for RISEN when the task has sequencing constraints. Use CARE when you can supply examples — it gives the most deterministic output.

The frameworks are not mutually exclusive either. A CRAFT prompt can embed CARE’s Examples without issue.

There is an obvious parallel with cool vs useful : every new framework looks interesting, but the boring, reliable one does the actual job. CRAFT is boring. Use CRAFT.

The real takeaway is : always include what the output is for and who reads it. That single addition — Target in CRAFT, Audience in CLEAR — has the biggest impact on output quality, and is the most commonly forgotten element.²

Explore Standard Preprocessor Directives

As the GCC manual tells us, you can know the default preprocessor definitions for your target by running:

gcc -dM -E - < /dev/null

This will output a list of all predefined macros for your target architecture.

Note that it also work with optimisation flags, therefore to know the difference for each optimization level, you can run:

gcc -dM -E -O0 - < /dev/null > defs_O0.txt
gcc -dM -E -Os - < /dev/null > defs_Os.txt

$ diff  defs_O0.txt defs_Os.txt
60a61
> #define __OPTIMIZE__ 1
182d182
< #define __NO_INLINE__ 1

The flags are documented in the GCC manual Common Predefined Macros page.

An excerpt of interest is:

__OPTIMIZE__ __OPTIMIZE_SIZE__ __NO_INLINE__

These macros describe the compilation mode. __OPTIMIZE__ is defined in all optimizing compilations. __OPTIMIZE_SIZE__ is defined if the compiler is optimizing for size, not speed. __NO_INLINE__ is defined if no functions will be inlined into their callers (when not optimizing, or when inlining has been specifically disabled by -fno-inline).

These macros cause certain GNU header files to provide optimized definitions, using macros or inline functions, of system library functions. You should not use these macros in any way unless you make sure that programs will execute with the same effect whether or not they are defined. If they are defined, their value is 1.

A very important information is that as soon as you have 2 code paths, you need to make sure that both paths are correct. Otherwise very subtle bugs may appear, as testing might leverage one of the paths and productive code uses the other one.

Leveraging These Directives in Our Code

That means, we can do exactly the same in our code to optimize for size.

For example in order to compute a CRC checksum, we can use a precomputed table for speed, or compute it on the fly for size.

#ifdef __OPTIMIZE_SIZE__
// Size optimized version: compute CRC on the fly
uint8_t crc8_t(uint8_t crc, uint8_t data) {
    crc ^= data;
    for (uint8_t i = 0; i < 8; i++) {
        if (crc & 0x80) {
            crc = (crc << 1) ^ 0x07;
        } else {
            crc <<= 1;
        }
    }
    return crc;
}

#else // __OPTIMIZE_SIZE__

// Speed optimized version: use a precomputed table
static const uint8_t crc8_table[256] = {
    // Precomputed CRC-8 table values
    0x00, 0x07, 0x0E, 0x09, 0x1C, 0x1B, 0x12, 0x15,
    0x48, 0x4F, 0x46, 0x41, 0x54, 0x53, 0x5A, 0x5D,
    ...
};

uint8_t crc8_t(const uint8_t crc, const uint8_t data) {
    return crc8_table[crc ^ data];
}

#endif // __OPTIMIZE_SIZE__

uint8_t crc8(const uint8_t *data, size_t len) {
    uint8_t crc = 0;
    for (size_t i = 0; i < len; i++) {
        crc = crc8_t(crc, data[i]);
    }
    return crc;
}

The code is only an illustration, the CRC-8 code is not correct.

To leverage the recent minima theme version, we had to leverage the jekyll-remote-theme plugin.

The package for Debian is ruby-jekyll-remote-theme but it has been removed since Debian 12.

That said, the Debian 11 version is still installable on Debian 12, so you can do:

wget http://ftp.debian.org/debian/pool/main/r/ruby-jekyll-remote-theme/ruby-jekyll-remote-theme_0.4.2-1_all.deb
sudo apt install ./ruby-jekyll-remote-theme_0.4.2-1_all.deb

Then, you can run jekyll locally with the plugin as if it is on github pages.

The Prayer

God, grant me the serenity to accept the things I cannot change.
Courage to change the things I can.
And wisdom to know the difference.

You don’t need the God part for this to be useful. What matters is the three-way split.

A Secular Version

May I find calm for what I cannot change.
May I find courage for what I can.
And may I know the difference.

Applied to a Codebase

Every codebase has things you can change and things you cannot.

Cannot change — legacy ABI contracts, the OS scheduler, a dependency you don’t own, the language your team already knows. Pushing against these burns time and goodwill. The correct response is to accept the constraint and design around it.

Can change — naming, structure, test coverage, your own habits. These are the things worth spending energy on. Yet they are often the first to be deprioritized because they don’t feel urgent.

The difference — this is the hard part. A surprising number of arguments in code review, in architecture meetings, and in bug post-mortems are really about misclassifying something. Someone fighting a constraint that is fixed. Someone accepting a constraint that is actually movable.

The Cool Stuff versus Useful Stuff problem is a variant of this. The cool stuff feels changeable because it is new. The boring stuff feels fixed because it is old. Neither feeling is reliable.

A Simple Test

Before spending more than an hour on a problem, ask:

1. Is this actually in my control?
2. If yes, is it worth the cost to change it?
3. If no, what is the cheapest design that works given this constraint?

That third question is the one most people skip. They either fight the constraint or give up entirely. Designing around a fixed constraint is a skill, and it is underrated.

The prayer is just a reminder to ask the question before you start.

Goals

The main goal is learning, but the end result should be a real, working opamp. The design aims to use components as common as possible: resistors, capacitors, and widely available ICs. The LM358 is the obvious choice for opamps, but the NE555 is also considered, especially for the now-defunct NE555 challenge.

Using another LM358 instead of a NE555 could keep the project within the opamp challenge, but might conflict with the secondary objective.

Secondary Objective

A surface-mount (SMD) version should aim to be pin-compatible with the most common dual opamps in DIP-8 format. If DIP-8 is too complex, a pin-compatible quad-op in DIP-14 format is the fallback.

Design

The design is simple. To put the LM358 in RRIO mode, the trick is to supply it with a single voltage source that has slightly more amplitude than the main voltage source. This overcomes the voltage drops inherent to the LM358’s internal construction.

The easiest way to achieve this is with a capacitive charge pump. Many RRIO opamps use this method for input rail-to-rail. Output rail-to-rail is usually done with a CMOS buffer, which limits current draw and fits inside the IC die.

This project skips the CMOS output buffer, instead generating a charge pump powerful enough to drive the opamp load directly.

Everything starts in a simulator

First, I start all my designs in a simulator. I’m using the one from Paul Falstad, as it is dead simple to use, and working well enough for most of my needs.

I’m using a NE555 to generate a dual voltage power source from a single voltage one. The pattern is very common : a simple capacitor charge pump for each voltage.

I don’t need to have a very high or low voltage, as I only need to supply a little more that the voltage drops in the opamp IC.

Note, I also leverage the fact that the NE555 has a rather strong output, and it will be able drive both charge pumps directly without needed to use buffers.

The values I’m using are also rather common as it is only power-of-ten. Which are the most easy to source components.

The diodes will be the very common 1N4148, also ubiquitous to find. Using some Schottky ones like the 1N5711 might be more efficient, but they are more difficult to source.

The circuit is available in the Live Simulation.

Breadboard Time for the Charge Pumps

Simulation works nicely, now let’s try it out for real.

As Ken Yap nicely commented, there is a strong voltage drop in the bipolar NE555, typically 1.7V. The usual way is to leverage a CMOS version such as the LMC555, but as I’m aiming for very common components, I’ll use only regular NE555.

Building the charge pumps

The charge pumps are not hard to build. I’m using a simple breadboard, and a very simple DIY USB powering for 5V.

Testing the outputs

Now, it is time to test the 2 voltage outputs.

A very nice 9V and -4V.

Issue is that it doesn’t hold the voltage as nicely with some load. I tested with a yellow LED in series with a 1k resistors and it falls to 4.5v with a current of 2.4 mA (2.4V across a 1k resistor).

Anyway, let’s try with the LM358 now.

Adding the LM358

Let’s finally add the LM358 to the mix.

Without Load

It works quite well without any load.

Positive & Negative outputs are within 50mV of the input with a simple voltage follower.

With Load

As expected, with some load, the voltage isn’t that great : 3.3V only at 2.4mA, which isn’t surprising, given the output of the charge pump.

Conclusion & Improvements

My initial idea didn’t work as well as expected. Without load it is perfect, but as soon as some load is added, the voltage drops.

But the good findings are that the charge pump is the weak link here. So, if it is improved it should be fine.

I’m planning to try 2 improvements:

• Using a LMC555, which is the CMOS version of the NE555 as suggested in the comments by Ken Yap.
• Using a CD4069 CMOS buffer to achieve the same effect than using the LMC555.

Once I’ll manage a stable output even with the max expected load from the LM358, I’ll aim to miniaturize on a PCB.

Debian ships with the mingw-w64 package that provide a nice cross compiler toolchain.

Yet SDL2 and its extensions don’t ship ready-made Debian packages for the mingw-w64 toolkit.

I therefore created a script that generates debian packages. It downloads the windows version and installs them in the correct directory so that the mingw-w64 toolkit picks it up.

Usage:

sh build-sdl2-mingw.sh "" 2.30.2           # core SDL2
sh build-sdl2-mingw.sh image 2.8.2         # SDL_image
sh build-sdl2-mingw.sh mixer 2.8.0         # SDL_mixer
sh build-sdl2-mingw.sh ttf 2.22.0          # SDL_ttf
sh build-sdl2-mingw.sh net 2.2.0           # SDL_net

sudo dpkg -i sdl2-mingw-w64-i686-dev_2.30.2.deb sdl2-mingw-w64-x86-64-dev_2.30.2.deb \
sdl2image-mingw-w64-i686-dev_2.8.2.deb sdl2image-mingw-w64-x86-64-dev_2.8.2.deb \
sdl2mixer-mingw-w64-i686-dev_2.8.0.deb sdl2mixer-mingw-w64-x86-64-dev_2.8.0.deb \
sdl2net-mingw-w64-i686-dev_2.2.0.deb sdl2net-mingw-w64-x86-64-dev_2.2.0.deb \
sdl2ttf-mingw-w64-i686-dev_2.22.0.deb sdl2ttf-mingw-w64-x86-64-dev_2.22.0.deb

Note that for distribution, the SDL2.dll and friends still need to be manually copied in the application directory.

Prerequisites

I’m using the default GitHub Pages Jekyll engine with a tweaked minima theme. That one doesn’t support the dark theme yet. But the upstream does.

Thankfully, GH pages supports the jekyll-remote-theme which is exactly designed to enable themes from 1a GitHub repository.

Installation

1. add the jekyll-remote-theme plugin to your _config.yml
2. replace the theme: minim1 configuration option with remote_theme: "jekyll/minima

You can also be specific with jekyll/minima@a6d4d9ce". The use of a commit id ensures that changes on the theme don’t randomly break your site. That’s useful when you customize it afterwards. But beware to always keep it up to date from time to time.

1. add the skin to dark or auto

minima:
  skin: auto

1. tweak the modifications you made to adjust to upstream’s changes. Mostly the dynamic css namings, that are enabling the skins.

Now, if you chose the auto skin as I did, the site will automatically adjust depending on the configuration of your brower.

I’ll might add a button in the future, but it already suits my needs.

Setup

1. Shuffle the cards.
2. Deal 3 cards to each player, then 2 more.
3. Place 1 card face up — this will be the discard pile.
4. Deal 3 more cards.
5. Place the remaining cards face down — this will be the draw pile.

Gameplay

A game can be played by counting the accumlated points or by simply counting the number of rounds won.

Start of Turn

1. Play one card from your hand onto the discard pile, face up. It must share a common trait with the top discard card — either the same rank or the same suit.
2. If the player has no valid card to play, they draw 2 cards and skip their turn.
3. If the player had only one card before drawing, they draw nb_players − 1 additional cards.
4. The round ends when a player must draw but the deck is empty, or when a player plays their last card.
5. It ends immediately. Drawn cards still count.
6. Players total the points of the cards remaining in their hands.

Scoring

• Number cards score their face value.
• Face cards (J, Q, K) score 1 point.
• Aces score 11 points.

In a points game, players add up their points each round. In a victory game, the winner of a round is determined as follows:

1. The player with the lowest total points.
2. If tied, the player with the most cards.
3. If still tied, the player with the lowest master card.

Variants

The core tenet of rules is rather flexible, and does accomodate nicely with some variants that one can leverage to adjust the playing experience to its audience.

Joker Variant

• A player may discard a Joker on any card, but must then discard nb_players additional cards that follow the discard rules. Jokers can be stacked.
• If the player cannot play the required additional cards, they draw nb_players × 2 cards.
• Jokers score 20 points

Using a 32-card cards deck

Using a 32-card deck has the same rules, but leads to much shorter rounds. Since only the higher number values are present, so it is a little more intense.

Using multiple 54-card decks

One can also use multiple 54-card decks to enable longer rounds, or when there are a significant amount of players. Ideally the back side of the cards should be identical, but that’s not really required as having different back coloring gives away some information that can be strategically used.

Naming explanation

“Kartu Sama” means “Same Card” in Indonesian, which nicely fits the theme of the game & the blog since the Java island is in Indonesia.

This is the line you need to add to your C files.

#define gets(x) fgets(x, sizeof(x), stdin)

Don’t add it in a header file, only in each C file.

The sizeof will only be correct in the case of statically defined buffers.

If it is a dynamic buffer, it is still secure, but incorrect. With a simple pointer, the sizeof will only be the of the size of a single element.