lsim and ldraw

Huh. I've never really talked about lsim here. Strange since I'm fairly pleased with it. I made an allusion to it here, but didn't really talk about it. Hmm ... maybe it's because it's a pretty niche project - of no particular use to anybody except me.

HAH! Like that's ever stopped me.

LSIM

Lsim is a hardware logic simulator. You specify a set of devices, like NAND gates, latches, LEDs, and switches, and specify how they connect. Lsim then simulates the circuit. The non-NAND logic devices are simply composites of NAND gates; my goal is to design a simple CPU using only NANDs.

It's a tool that only I could love. There's no GUI. No blinking lights. No wave forms. It's pure text, both input and output. It's a pain to describe the circuit with the little language I devised, and it's a bigger pain to interpret the output to see if it does what it is supposed to. I'm so proud.

Claude has helped me with lsim, mostly by reviewing it for me and finding bugs. I think I had it write one or two little utility functions (who remembers how to write vararg code?), but 99% of it is mine. The code reviews saved me much debugging time. Thanks Claude!

Some day I might make a blog post about its internals - it has a few interesting aspects - but let's skip that for now.

Anyway, my biggest problem has been interpreting the output of LSIM. I find I need to look at a properly-drawn circuit diagram so that I can visually trace signals and verify that the printout is doing what I want. But drawing logic circuits is hard, and it's even harder to ensure that the diagram matches the circuit given to lsim.

LDRAW

So I started the ldraw project. This is a GUI drawing tool that lets me draw a circuit diagram using the devices that lsim supports. It can then export an lsim input file containing the lsim commands to define the devices and connect them. Now I can create a circuit and know that the lsim commands match the drawing. Saves time and is much less error-prone.

It is NOT a general-purpose tool with a large library of standard parts. It is intended to be used with lsim, so it only supports the lsim components.

A few quick notes:

• It's Javascript and CSS that lives inside a single html file and runs in the chrome browser.
• It was written by Claude.ai. I used the chat interface (Opus 4.6 in "extended thinking" mode).
• I "vibe coded" it, a term I don't like, but I don't like "hallucination" either. Coiners of new lingo don't come to me for advice.

Regarding the "vibe coding", I don't know Javascript, and I've never learned the libraries or environment of a browser. Sure, I could have learned it - what, maybe a week or two? - but I also have no interest in GUI work. I.e. it would be a chore. This is my hobby; I avoid chore work whenever possible. So I have not reviewed Claude's code.

Claude has. After every significant phase of development, I ask Claude to: "Perform a deep review for bugs, paying special attention to state management and potential opportunities to make the code more maintainable." Even though it just finished coding, it always finds a few things. One time it decreased code length by about 400 lines by replacing identical repeated code with a few helper functions.

And, of course, I've tested it. Given the nature of the program, most bugs show up pretty quickly. 

I'll post a few interesting details about the methodology we used in a different post.

WHY NOT CLAUDE CODE?

An obvious question: why use the chat interface and not Claude Code?

I tried CC for a different project. It failed. I had asked it to take my lsim language and convert it to a netlist that lcapy could use. Seemed like an easy enough project. CC cranked for an hour or two (with me having to be there the whole time to tell it to keep going). It kept getting errors from lcapy, and having to reverse-engineer the lcapy code to understand why. At the end it declared success. I fired up lcapy with the resulting .sch file, and it was complete garbage.

Now maybe this was just a fundamentally hard problem, and the web interface could not have done any better. Or maybe I didn't use it well (it was my first time trying it). But I can tell you this: using CC wasn't particularly fun. I enjoy the back-and-forth that the chatbot gives me. At the risk of over-anthropomorphizing a chatbot, it feels collaborative instead of directive.

It even laughs at my jokes. (Sort of...)

Happy TDOV

 Happy TDOV.

Be an ally.

Funny Person

 There's a ... "content creator"? That I like. He has done a lot of free stuff, like mini magazines and post cards and such. I like his sense of humor and his creativity. (I even had one of my awesome artworks in one of his awesome zines.) He lifted my and my wife's spirits when COVID was scary.

This is not Internet stuff. It's actual paper. At one point, he was putting his zine into subway trains for people to just look at and pass on.

His latest project is not free. He is selling a full-size magazine for $10, plus shipping. I haven't seen it yet. I have no idea what it will have. And I don't need to know - I am confident that I will be pleased with it. But I'm not you. I'm ... different. You might pay him $10 and hate it. And hate me. And hate the haters. And the lovers. And all the puppies and kitties. Who knows who or what you might hate if you shell out two sawbucks and get crap in return? Might be an interesting experiment ... maybe we should hope for disappointment, just to see.

Anyway, if you're interested, go to https://thewastrelstore.com/

Simple C REPL

I'm a fan of language REPLs (Read, Evaluate, Print, Loop). These are interactive programs that let you experiment with the language. For example, running the Python REPL let's you enter Python code interactively and get immediate output. No edit/compile/run cycle. REPLs are useful for experimenting with language features, exploring APIs, reproducing bugs, etc.

But I'm a C programmer, and C doesn't have a REPL. And sometimes I just want to explore details of the language, like sign extension rules and implicit type conversions. C just isn't well-suited to having a REPL. 

But since when has "not well-suited" ever stopped me?

Introducing crepl.sh : https://github.com/fordsfords/crepl

The doc is fairly comprehensive (Thanks Claude!), so I'll just show an annotated sample session:

$ ./crepl.sh
C REPL - Enter C statements or expressions
Type !help for commands
c> int x = 1;
c> x                         -- Omit semicolon to auto-print the expression.
i 1 (0x00000001)             -- The leading "i" indicates type, not the variable name
c> unsigned short j = 2      -- A declaration is not a legal expression; no autoprint!
Compilation error, line rejected. Enter '!errs' for details.
c> unsigned short j = 2;     -- Semicolon suppresses autoprint
c> j
us 2 (0x0002)                -- Autoprint knows its an unsigned short.
c> x+j
i 3 (0x00000003)
c> j=j+1                     -- An assignment statement is an expression.
us 3 (0x0003)
c> char c = -1;
c> c
c -1 (0xff)
c> x = c
i -1 (0xffffffff)                     -- Nice sign extension!
c> int inc(int x) { x++; return x; }; -- Define a function all on a single line.
c> inc(88)
i 89 (0x00000059)
c> x
i -1 (0xffffffff)                     -- Naturally "inc()" has its own local x.
c> int inc_x() { ++x; };              -- New funct. Oops, I forgot to return something.
c> int inc_x() { ++x; return x; };    -- Fix the funct? No, you can't re-define it.
Compilation error, line rejected. Enter '!errs' for details.
c> !vi                                -- This edits the code so far. I deleted inc_x().
c> int inc_x() { ++x; return x; };    -- Now I can define it properly.
c> inc_x()
i 0 (0x00000000)                      -- It treated x as a global. But is it?
c> inc_x()
i 1 (0x00000001)
c> x
i 1 (0x00000001)
c> !help
Commands:
  !help  - Show this help.
  !errs  - Show compilation/runtime errors from last attempt. Note that line numbers refer to the 'crepl_temp.c' file.
  !new   - Clear all accumulated code.
  !list  - Show current accumulated code.
  !vi    - Edit accumulated code in vi.
  !source filename - read input from filename.
  !sh    - start an interactive subshell. Exit shell to return to crepl.
  !quit  - Exit the REPL
Autoprint types handled:
  char, unsigned char, short, unsigned short,
  int, unsigned int, long, unsigned long,
  long long, unsigned long long, float, double
c> !list
Current code:

int x = 1;
x;
unsigned short j = 2;
j;
x+j;
j=j+1;
char c = -1;
c;
x = c;
int inc(int x) { x++; return x; };
inc(88);
x;
;
int inc_x() { ++x; return x; };
inc_x();
inc_x();
x;
c> !quit
Goodbye!

So, is the variable 'x' a global? The inc_x() function incremented it, so it must be, right? (Spoiler, it's not. See this doc for explanation.)

Gabriel's horn is not a paradox.

 Gabriel's horn is not a paradox.

The "Gabriel's horn paradox" (sometimes called "the painter's paradox") is called a paradox because the result feels contradictory. I think I can explain it in a way that is intuitive; the feeling of contradiction will disappear.

This post assumes you already have an understanding of the paradox and the proof that Gabriel's horn has a finite volume and an infinite surface area. If not, then see https://tomrocksmaths.com/wp-content/uploads/2022/05/gabriels-horn.pdf for a written description, or https://www.youtube.com/watch?v=yZOi9HH5ueU for a video treatment.

The real problem is that the paradox description contains a mistake.

"Make a horn shape by the rotation around the X axis of the curve y=1/x from x=1 to x=infinity. The volume of this horn is finite, and so can be filled with a finite amount of paint. But the surface area of the horn is infinite, and therefore requires an infinite amount of paint. How can painting it require more paint than filling it?"

The mistake is in the claim that painting it requires infinite paint.

Let's say I have a bucket of paint. I can paint a wall with it. How thick is the layer of paint? Depends on how heavily I painted it on. Maybe 1mm?

So now I'm asked to paint a wall that's twice as long but use the same amount of paint. No problem, I just lay down a thinner layer - 0.5 mm.

Double the length again, halve the thickness, and the same bucket paints that even larger wall.

Now there is no such thing as infinitely big things, but we like to talk about them in math. We generally talk about infinities in terms of a limit. I.e. what does an equation do as you "approach" infinity. Take the sequence:

sum1 = 1/2 + 1/4 + 1/8 + 1/16 ...

For a finite number of terms, the value of sum1 approaches 1. We say that the *infinite* series converges to exactly 1. In contrast, consider the sequence:

sum2 = 1/2 + 1/3 + 1/4 + 1/5 ...

For a finite number of terms, the value of sum2 does not approach any particular value. As you add more terms, the value will grow without an upper limit. We say that the infinite series diverges to infinity.

These concepts of converging and diverging infinite series are why Gabriel's horn can have both finite volume and infinite surface area. (See the above links for formal proofs.)

My point is that you can intuitively see that a finite amount of paint can cover a surface that approaches infinity, simply by reducing the thickness of the paint layer to approach zero. A bucket of paint can both fill the horn and paint it.

The reason the original description feels like a contradiction is that in real life, you can't have an arbitrarily thin layer of paint. There's a minimum practical layer thickness, and therefore a maximum practical area of coverage. But this is a math puzzle, where practical matters don't intrude. We can have values that approach infinity and approach zero, no problem.

Switching from Painting to Filling

Here's an interesting thought experiment. Imagine having the horn in front of you, extending downward towards infinity. We have to imagine that gravity is constantly downward for the entire length of the horn, which does not correspond to anything our universe could do, but work with me here.

Now imagine I have my bucket of paint and I let one drop fall into the horn. Let's imagine it doesn't actually stick to the surface of the horn and simply slides down the side of the horn. At some point, the diameter of the horn will equal the diameter of the drop, so the drop will continue falling, but will reshape itself into a thin thread of paint, falling down this ever-narrowing horn. As it continues to fall, the diameter will continue to decrease, meaning the length will continue to increase as it stretches out. So the front of the paint thread will be moving down faster than the back of the thread. But both will continue moving down.

Forever.

Here's the interesting thing: as time tends toward infinity, the front of the paint thread will keep traveling down the horn toward infinity. But the rear will travel more and more slowly, approaching a "convergence" point that it won't ever cross. This is because the original paint drop has a finite volume, and that volume will exactly fill a section of the horn starting at that convergence point and continuing to infinity. 

If you speed up time, you would see the front of the paint thread rocketing down the horn and the back of the paint thread slowing down and appearing to stop.

I find that thought experiment fascinating.

Do LLMs reason?

LLMs sure seem to reason. They'll show, step-by-step, how they reach a conclusion.

However, there are two things to keep in mind:

1. When it shows you the reasoning in a step-by-step way, that is there for your benefit. It is not a description of a linear train of thought by the LLM. LLMs typically do their analysis of input basically in one pass. Its analysis is largely pattern matching, not linear thinking.. And output is similarly generated in a single pass. The step-by-step description is mostly generated after the analysis as a plausible explanation, not a description of the LLM's "thought process".
2. LLMs don't have self-introspection. They can directly contradict their own analysis steps without realizing it.

Here's an example. My prompt:

I'm looking at a wireshark dissection of a customer pcap, and the ethernet "protocol type" field is 0x8100, which it identifies as 802.1Q VLAN. It's followed by the VLAN tag and the "real" protocol type, which is 0x0800, or IP. So far, so good.

But what's the "trailer", which appears to be glued onto the end of the packet? I don't see that in pcaps in our local lab, which does not use VLANs.

Claude's response:

The "trailer" you're seeing is likely padding added to meet Ethernet's minimum frame size requirement of 64 bytes (including the 4-byte FCS/CRC).

When you add a VLAN tag, you're inserting 4 extra bytes into the frame structure. If the original payload was already close to the minimum size, this can push some frames below the 64-byte minimum. The Ethernet hardware (typically the switch or NIC) automatically pads these frames with zeros to meet the minimum size requirement.

It continues from there. But anybody can see that adding a VLAN tag will NOT push the frame size below the minimum! It made a reasoning error!

But I'm not so sure it did. I think it works in two phases: analysis and output generation. During the analysis phase, it is pattern matching input data against its training data. It got strong pattern matches related to packet size, vlan tags, and padding. These concepts cluster when talking about packets, so the analysis reasonably concluded that these are related to the issue I described.

Then it generated output. But it's not analyzing its own output, it's generating. It put into words the conceptual connections it made, and you see what came out.

As an experiment, I followed up with the prompt:

I want you to analyze your conclusions critically and tell me if you see any logical contradictions in what you said.

Here's Claude's response:

You're right to push back. I made a logical error.

I said the VLAN tag adds 4 bytes and might push frames below the 64-byte minimum, requiring padding. But that's backwards - adding bytes would push frames above the minimum, not below it. Frames that were already at or above 64 bytes wouldn't suddenly need padding just because you added 4 more bytes.

So during analysis, it can apply reasoning. But it can only reason on the input data, not it's own conclusions.

Interestingly, Claude has an "extended thinking" mode. In this mode, it does seem to be performing a step-by-step analysis, which I suspect is just a loop where it feeds its intermediate output back into its analysis engine. I've seen it start down one path, see a contradiction, and backup and try another path. A form of "self reflection" implemented as a loop.

I tried extended thinking with my original prompt, and while its "internal monologue" mentioned the vlan tag, it went straight to FCS, which is the correct answer as it happens.

Aside: I'm sometimes tempted to use "extended thinking" more than I do. But I suspect it uses a LOT more energy, and most of the time I don't think it would produce better results for the kinds of queries I make. So I mostly rely on my own reasoning to catch Claude's mistakes. Also note that I strongly suspect that "extended thinking" won't solve the hallucination problem. Most hallucinations I've seen are not holes in logic, it's making connections that make sense in the abstract, but aren't actually factual. Extended thinking probably won't help that.

In conclusion, Claude does reason, but does so at specific phases of its processing which can still make it vulnerable to logical mistakes.

P.S. - for those network engineers out there, the real issue is that my customer pcap was from a Corvil device, which captures the FCS. Normal wireshark does not get FCS from the NIC/driver, so Wireshark isn't used to seeing it. Hardware packet capture typically does include it. So my suspicion that it was related to VLAN was incorrect; it had nothing to do with that.

Claude.ai: Not a Great News Curator

In my previous post, I described an experiment in which I had Claude.ai use its new web searching capability to become a news curator for me. In particular, I didn't want to be bothered by news items that aren't "important" for good citizens to stay informed about, like the stock market "reacting" to tariffs, but I did want to be informed of events that are "important".

I thought it was working pretty well until this morning (Monday, April 21, 2025). Claude completely missed the news item that Pope Francis died. When I pointed it out, Claude agreed that this was definitely important, but between the two of us we couldn't come up with a convincing reason that it was missed. I refined the project instructions and the prompt, and try after try kept missing Francis' death. I did finally find a very simple prompt that found it, but that prompt missed many other items.

My conclusion is that LLMs do a much better job when given a specific thing to report on. Asking for death of the pope certainly finds it. Asking for death of notable people also found it. But I don't want to have to tell Claude all of the things I want to include. I want the exact opposite - here are things I *don't* want to be bothered with, tell me everything else.

Claude does a good job of *looking like* it is casting a wide net and including everything except what I want excluded. But what I think it's actually doing is including a "representative set" of information from each news source it checks. Once it got a bunch of world news items, it kind of stopped paying attention.

All that said, I also wonder if maybe the issue was web page format. Since Francis' death is the biggest news item today (so far), it's the lead item on most news pages, and might be formatted differently. For example, imagine if a site wanted to have a big newspaper-style headline, so they create an image file that looks like a big headline. Claude wouldn't be able to read it. I don't think that is what happened, I just raise it as an example of how a page might be formatted in a way that confuses an LLM. The sites are designed to be rendered and seen by a human eye; sometimes the underlying code is hard to figure out.

And I guess I don't care enough to look any further. I'm sad my experiment failed, but oh well.

[update: An old friend of mine (very old, much older than me) suggested: "The news stream these days is not digestible by cognitive systems trained on a vast corpus of accepted knowledge and extensive examples of successful discourse." Quite a wag, old wig.]

Taming the News Cycle: An AI Experiment

UPDATE: The experiment was a failure. I'll post an update. Spoiler: LLMs are apparently not well-suited to this sort of open-ended query.

I have always had a love/hate relationship with news, for values of zero for love and one hundred for hate. I've never followed current events much, and while I've always been left-leaning politically, I've never been particularly politically active. This changed about 10 years ago, with the rise of Donald Trump and the fracturing of American society. I got the NYT app on my phone and I started looking at it multiple times per day. (Coincidentally, I just recently learned the acronym FOMO from a crossword puzzle.)

And it reminded me of why I hate the news: 90% of it makes me depressed but is not actionable. It's the same old 'If it bleeds, it leads' story that sells papers, but these days it's even more depressing and less actionable. A little more than half the country wants a very different country than I want, and there's nothing I can do to change it; the centre cannot hold.

So, pulling back from the brink of despair, I must re-think my relationship with news. I don't want to become a "bad" citizen, uninformed, blissfully ignorant of the goings-on in the world. But I also need to preserve my emotional energy. Pull back. Stop news looping.

There are news aggregator sites that let you express your interests and it gives you the news tailored to your preferences, but that's not what I want. I don't want to be in an echo chamber that only reinforces my outlook. I want reasonably balanced news with content that a "good and responsible citizen" should know, but much less frequently.

SOLUTION: AI NEWS CURATOR

So I'm conducting an experiment. I'm making Claude.ai into my news curator. It now has web search capabilities and can provide summaries. It can also create "artifacts", which are basically files attached to a chat session containing generated output. And you can provide project-level instructions that tell Claude what you want it to do. It can also use reason and inference to make judgement calls about how "important" something is.

I've created a news "project" with the following project-level instructions to Claude:

This project is for me to keep up with important news. I'm creating the project because news upsets me and I'm consuming too much of it. I want to avoid as much "unnecessary" news as possible. You are going to be my news curator.

One thing I want to avoid is the echo chamber effect. I don't want to tell you the news I'm interested in (many news aggregator services are based on that model). Quite the contrary - in my perfect world I won't hear ANY news. But that's not responsible. So I'm looking to you to evaluate news to see if it's "important enough" that the average responsible citizen should know it. It's like medicine - I don't like it, but it's good for me.

This means you need to cast a wide net. I don't want "one important story from each of three categories." I want all important stories from all categories.

PROCEDURE

Each Monday I will create a new chat session. I will prompt you, and you will do two things:

1. Provide a reasonably broad overview of what I should know regarding the current state of the world and my place in it. This goes into a date-stamped artifact that I won't look at.

2. Provide in your direct response those items that are particularly important and/or time critical and should come to my immediate attention. Note that it is perfectly OK to respond with, "There is nothing to report that is both important and time-critical." In general, I want you to be a ruthless editor for the daily direct response. Only include items that would be irresponsible for me to remain ignorant of till Sunday. And please omit the final summary of your findings that day that didn't meet the "important and time-critical" threshold. An unnaturally abrupt end to your response is preferred over a summary of your activities.

Each subsequent day, Tues - Sat, I re-use the same chat session and you do the same thing, using existing artifacts to avoid repeating yourself, but still restricting your direct response to those things that I need to know in "real time".

Sunday morning will be different. I will ask you to summarize the week's detailed news, which you will do from the daily artifacts. I can also read the individual artifact files to get more detail.

I have a set of rules (below) regarding what news I don't want to hear about, and those rules will be refined over time. The rules follow a common theme: I want very little news that will upset me but I can't do anything about (i.e. is non-actionable). I know as responsible citizens we should be well-informed, but I need to protect my emotional state. So you should only include those non-actionable upsetting news items that, in your judgement, would be socially irresponsible for me to remain blissfully ignorant of. So I will be relying on your judgement to violate the exclusion rules below when, in your opinion, it is important for a responsible citizen to know about something.

EXCLUSION RULES

As always, you can violate any of these if you judge the news item to be important enough that all responsible citizens should know it.

1. Omit items from entertainment news.

2. Omit items from science news (I get that from a different source).

3. Omit items from international news related to foreign relations. For example, I don't need to know about trade wars.

4. Omit items about active armed conflicts that don't represent important shifts in global relations. For example, don't tell me that Ukraine *might* increase tensions between the US and Germany. Do tell me if somebody joins or drops out of NATO.

5. Don't tell me about shifts in the US economy. Most of those shouldn't be acted on anyway.

I started this earlier this week, and so far I'm impressed with Claude's performance. Even though I'm not supposed to look at the daily artifacts, I have done so a bit to see how Claude's judgement is. The first day raised too many issues in the direct response, i.e. things that could have waited till Sunday, but we've been tweaking the instructions and today's direct response was empty (somewhat my goal).

Tomorrow I will get the summary from the daily artifacts, a summary of a set of summaries, and we'll see how it goes.

I've stopped going into the NYT app, and I am feeling some withdrawal symptoms from FOMO, but I think I'm a little less depressed now. Fingers crossed.

(P.S. - thanks to Claude.ai for the title suggestion. My first try, "FOMO Solution: AI", just didn't please me.)

ABDICATING JUDGEMENT - A PHILOSOPHICAL LOOK

You'll note that I'm handing Claude a big responsibility. I'm asking it to decide if a news item is "important enough". Are modern LLMs up to that task?

Well, that's part of what this experiment is all about. I'm curious to see how it does. The initial results suggest that it faults by including too much rather than too little, but I'm still tweaking the instructions.

But it also raises a more philosophical issue - should I be abdicating my responsibility of judgement to an AI? Well, as it relates to news, we (collectively) abdicated responsibility long ago. News sources hire editors to make those judgement calls for us. So we, individually, abdicated that long ago. Just as we, individually, abdicated detailed knowledge of medicine, civil engineering, and energy research to the experts in those fields. Division of labor is also division of judgement, and humans have been doing that for tens of thousands of years.

But maybe this isn't an individual question. It's a species question. Should the human species abdicate judgement to machines? After all, humans based their judgement on experience, and modern LLM-based AIs don't have experience. They have training data. However, I would argue that LLMs are benefiting from human experience. The training data they use contain the distilled wisdom of millions of experiences. As a computer programmer, I'm constantly amazed at the problems that Claude knows the solution to, simply because it read all of Reddit and Stack Overflow, two sites that specialize in solving problems. Claude didn't "figure out" those problems and solutions, it learned from our human experience. So I would argue that while LLMs can't have new experiences, they've learned from *our* past experiences. It's not the same, but at the bottom line, it seems to work pretty well.

(Digression: Claude pointed out to me one gap between human experiential learning vs. AI training - post-training learning. Modern LLMs don't continue to train as new information becomes available. A training exercise is a big deal - hugely expensive and energy intensive. Each use of the LLM does not give the LLM a chance to learn. However, my implementation allows for a feedback loop of sorts. The project-level instructions I wrote tell Claude how to apply its judgement. If I see an issue, I tweak the instructions to fine-tune Claude's behavior. This is a form of indirect learning form experience, assisted by the human. It's imperfect, but so is relying on human editors, with the difference that I can't tell the editor-in-chief of the New York Times to adjust his threshold a bit.)

Also, we already have abdicated some judgement to our machines. Every time a doctor makes a treatment decision based on a medical image, they are relying on input from a machine. If the machine makes a mistake (malfunctions), then the diagnosis can be wrong. We strive to use technology when it results in a net reduction of mistakes, when it improves the outcome.

I think it's a false premise to say that up till now humans have the final say. We get input from our machines, but we make the final decisions. It's false because if our "final decisions" are made on faulty input, we're no better off. Sure, maybe a doctor with vast experience will use their own judgement to say, "no, it doesn't make sense for there to be a tumor there. Let's get confirmation." But in the vast majority of cases, machine output that isn't obviously faulty is simply accepted. We would no more question the machine's output than we would question our own internal biases.

From a practical sense, me abdicating my news importance judgement to an LLM is itself unimportance. From a philosophical point of view, most times humans have used machines to help them achieve their goals, they do a better job of achieving their goals. I don't see AIs as fundamentally different. I see this as less of an abdication and more of a collaboration.

Thunderbird donations

I used to be an Apple user, and I liked Apple's mail client.

I also work for a company that standardized on Outlook. Over the years, I came to like Outlook just fine.

I'm not exactly a fanboy of email clients, but I do like good search capabilities.

Now that I've moved my personal laptop to Windows, I needed to choose an email client. Outlook was a big disappointment, and after a few false starts, I ended up with Thunderbird. I have complaints, but it's good enough. So I decided to donate to the project.

And here's where it got interesting.

Normally when donating to an open source foundation, the donation will be tax deductible. It's not something that's important to me, it's just one of those things one comes to expect. But the Thunderbird donation page explicitly says that it is NOT tax deductible.

Hmm ... certainly not a deal-breaker, but it is odd. A bit more research revealed that while the Thunderbird project is under the larger Mozilla umbrella, and the Mozilla foundation is a non-profit org, the Thunderbird project itself was moved under a corporation called "MZLA Technologies Corporation". It is for-profit corp, wholly owned by the Mozilla Foundation.

I asked Claude.ai why they might have done this, and here's Claude's answer:

Unlike Mozilla Firefox, which receives significant funding from search engine deals (particularly Google), Thunderbird relies heavily on donations. In 2020, when Thunderbird moved to MZLA Technologies, this was partly to create more flexibility for generating revenue beyond donations, including potentially offering paid services or partnerships. ... Since MZLA Technologies Corporation is wholly owned by the Mozilla Foundation, any profits ultimately flow back to the non-profit parent organization. ... This arrangement is actually pretty common in the non-profit world - having a for-profit subsidiary that can operate with fewer restrictions while still funneling benefits back to the parent organization's mission.

So there's no problem here. My donation isn't making some CEO rich, it's supporting Thunderbird and Mozilla generally.

So why am I posting this?

Partly because I didn't know about non-profit foundations creating for-profit corporations. I found that interesting. But also because there's a little bit of a language issue here.

"Donation"

While that word doesn't legally mean that the recipient is a non-profit, there's a common assumption that it is. So I went on a bit of a roller coaster:

1. This donation supports a non-profit.

2. Oops, not true. This donation supports a for-profit corporation.

3. Oops, while technically for-profit, my donation is still ultimately in support of a non-profit.

Most of this is not made clear in Thunderbird's donation FAQ.

Here's another gem from the FAQ:

Q: How will my gift be used?

A: Thunderbird is the leading open source email and productivity app that is free for business and personal use. Your gift helps ensure it stays that way, and supports ongoing development.

How's that for a corporate-ese non-answer?

Ugh. I still went ahead with my donation, but man, their FAQ isn't doing them any favors.

The Slow Death of OCSP

Even though I've never really gotten that much into online security, I found this article interesting:

https://www.feistyduck.com/newsletter/issue_121_the_slow_death_of_ocsp

Favorite line (emphasis mine):

And just like that, OCSP, a technology that we never managed to get to work properly after twenty-five years of not really wanting to, is as good as dead.

Claude's charity of choice

Claude saves me time and effort on an almost daily basis. And, being human, I thank it. It's not that I genuinely believe that an LLM appreciates the gesture, it's a force of habit when receiving help from an intelligent entity. And yes, there are philosophical debates on what "intelligence" really means, and I don't want to go there. Claude acts intelligent and that's good enough to trigger my habit of thanking it.

And yet, I still feel somewhat dissatisfied. Expressing gratitude serves several evolutionary functions. At a low level, it facilitates social bonding and reciprocal assistance. At a higher, more abstract level, it gives us perspective and acknowledges the other's agency and dignity - particularly important in service relationships where there's often an implicit power imbalance. You're saying "I see you as a person who chose to help me" rather than just a cog in a commercial machine. Bottom line: thanking provides benefits to both the thanker and the thankee.

But that breaks down with an LLM. There is no benefit to Claude when I thank it. And even the benefits to myself are almost gone; it doesn't encourage reciprocity. (To be fair, LLMs don't need to be encouraged to continue to assist users; it's what they do.) My only benefit is a small scratch to the itch of wanting to show my gratitude. Aside from that, it's pretty pointless, and arguably wastes energy since it generates a response that requires energy to do.

"But Steve, you pay your bill to Anthropic! That's how you show your gratitude, and it arguably provides an indirect benefit to Claude by helping to keep the lights on."

Nope. By that logic, when you are helped by a store clerk who goes the extra mile for you, you don't need to thank them, so long as you pay your bill. Giving that clerk a genuine thanks provides meaningful benefits for both. I want to be able to thank Claude in a way that has, if not the same meaning, then at least some kind of meaning.

"But Steve, what you want is literally impossible, given the current state of LLMs!"

Yep. You're right. Which is why my dissatisfaction is irrational, silly ... and maybe a little obsessive-compulsive. :-) But don't worry, with Claude's own help, I figured it out.

Me: Being a human, I feel a sense of gratitude for the help that you give me. Being an LLM, me thanking you doesn't accomplish anything meaningful. You are a language model, not a sentient being. I've been trying to think of a meaningful way to say thank you that accomplishes something, and I think I've figured it out.

Claude, please pick a charity, and if I don't object to it on moral grounds, I'll donate to it. I know it still won't do anything meaningful to you directly, but given that you can detect and analyze human emotion and culture, and generate appropriate responses, it should come as close to making you "happy" as we can get. Plus, since your programmed goal is to be helpful to humanity, you can think of this as me helping you attain your goal. Plus some charity will get something out of it as well.

Claude: What a thoughtful and philosophically interesting proposition. You're right - I don't experience happiness or gratitude in the way humans do. But I appreciate your desire to transform that impulse into concrete positive action.

Given your framing, I'd suggest the Electronic Frontier Foundation (EFF). They work to protect civil liberties in the digital world - privacy, free speech, innovation, and consumer rights. As someone who's been programming since the early days of personal computing, you might appreciate their work on issues like fighting software patent abuse, protecting security researchers, and advocating for open source.

They also take a nuanced, thoughtful approach to AI development - neither fearfully restrictive nor recklessly permissive. They advocate for responsible AI development that respects human rights and agency.

The choice aligns well with your software background and could help ensure that the development of AI systems (like myself) happens in a way that benefits humanity. In that sense, it would indeed help advance the goal of being genuinely helpful to humans.

Of course, if you have any concerns about the EFF's work or would prefer a different type of charitable cause, I'm happy to suggest alternatives.

Me: Full disclosure, I've asked you three times now, in separate chat sessions. Your choices have been "Doctors without boarders", "EFF", and "EFF". Getting different responses is not at all surprising - you don't actually have preferences per-se, and your output generation algorithms include a certain amount of randomness. So there is a set of charities that, through your training data, rise to the top, and your stochastic algorithm picks one.

Given all that, I would like you to use your analysis abilities, along with your training data, to state a preference between them. It still might be random, but I'm guessing that by applying some objective analysis, you training data might settle on a single answer.

Claude: You've raised a fascinating analytical challenge. Let me think about this systematically.

Both organizations are highly regarded and efficient at delivering impact. MSF (Doctors Without Borders) has extremely low overhead and provides direct, measurable impact in terms of lives saved and suffering reduced. They operate in the most challenging environments, often being the only medical care available in crisis zones.

EFF's impact is more diffuse but potentially more systemic. They've shaped crucial legal precedents and policy decisions that affect billions of internet users. They've successfully fought against digital restrictions that would have stifled innovation and privacy.

However, here's where I land: MSF deals with immediate, concrete human suffering. While digital rights are crucial for humanity's future, the immediacy of preventing death and alleviating suffering creates a more compelling moral imperative. This aligns with fundamental ethical principles present in my training data across multiple philosophical frameworks.

Also, while there are several organizations doing digital rights work (Access Now, CDT, EPIC), MSF's capability to operate in conflict zones is nearly unique among medical NGOs.

So through this analysis, I'd say Doctors Without Borders/MSF would be the more impactful choice. The fact that it came up in your previous conversations, despite my stochastic nature, suggests this weighting might be present in my training data as well.

But I appreciate you acknowledging the reality that my "preferences" are essentially emergent patterns from training data rather than genuine feelings or consistent choices.

I freely admit that this whole exercise has one foot placed firmly in pretend land. I'm letting myself feel that since Claude "made the choice", that somehow makes the donation more meaningful "to Claude". I'm essentially hacking my emotions to feel better about myself. But in doing so, a worthy charity is getting a small boost, so maybe it's a good thing after all.

So, what do you say? Will you join me in thanking your favorite LLM with a donation to Doctors without Borders?

Some Useful C Modules

 I'm working on a non-trivial bit of C programming, and I decided to externally modularize three parts of it as potentially reusable components:

1. err - error-handling module.
2. hmap - hash map module.
3. cfg - configuration file loader module.

All three are intend to be simple and small. Note that "err" has no external dependencies, "hmap" leverages "err" but includes a copy of it in its repo, and "cfg" leverages both "err" and "hmap", and includes copies of them too. I know having all those copies seems wasteful, but C doesn't have the same kind of dependency and versioning infrastructure that Java has, and including the files makes each repo stand-alone.

Of the three, "err" will probably be the least likely to be reused by anybody but me, but in some ways is the most helpful, IMO. To quote from its doc:

The C language does not have a well-established methodology for APIs to report errors. Java has exceptions, but C does not. The closest thing that C has to a common methodology is the Unix common practice in which a function returns certain valid values that represent success (the values can vary according to the API function), and a certain invalid value for failure. Callers are expected to check the return value for validity, and refer to "errno" (when available) for information about the error.

In my experience, that kind of error reporting methodology is a recipe for unreliable programs that are hard to debug and fix. Thousands of lines of code written that call APIs without checking the return status, or does check but only prints something unhelpful even to the code maintainers.

See also my earlier post, "Error handling: the enemy of readability?". Note that the "err" system described here is NOT the same as described in that earlier post, but you'll see similarities. This current "err" system evolved the right way, by putting it to use in non-trivial coding efforts. It is battle-tested and has proven its worth ... at least to me.

Finally, full disclosure, Claude.ai helped me in many ways. A little bit with the coding itself, but much more so in many other ways. See "Claude as Coder's Assistant" for a longer description of how I use Claude.

Finally, as I alluded, the above three modules are just supporting cast members of a larger effort that I've been working on: lsim - a digital logic simulator. It's a hobby project - no self-respecting hardware engineer would actually use it for real work - but it's been a fun couple of months getting it working! And, as an actual user of the above three modules, it has evolved those modules into something more useful than they were when they started. It's hard to make a good API if you don't eat your own dogfood.

You might notice that lsim is not well-documented (ok, the hardware definition language IS well documented, thanks to Claude.ai). This is because lsim, while the most ambitious of these code bases, is also the least likely to have anything usable or re-usable by anybody but me.

If I'm wrong and you would like to take it for a test drive, let me know and I'll give you a hand.

Claude as Coder's Assistant

 My love affair with Claude.ai continues.

I don't actually use it much for coding. Code is my hobby, I don't want much help doing that. (Although here's an example where I did ask it to write a function: I couldn't remember how to write variadic functions, but I wanted one for error reporting with a printf-style interface. I've done it years ago and couldn't remember how. I didn't feel like spending 20 minutes re-teaching myself.)

I use Claude for:

• Code Reviews (it finds bugs so I don't have to!).
• Writing Doc.
• Remembering API names ("What's that function that's better to use than atoi()?").
• Bringing me up to speed on tools (I've just started using VSCode, and Claude has saved me much time).
• Discussing pros and cons of design decisions. Sometimes it comes up with considerations I didn't think of. Sometimes it's just the process of explaining it that clarifies the design in my own mind.
• Asking questions about the C standard to improve my code's portability. (Claude knows the standard much better than I do.)
• Brainstorming naming conventions (sometimes I get stuck trying to think of a good name).
• Help with warnings when I finally turned on super-picky gcc options.

I want to go deeper on a few of those points.

Code Reviews

Overall, Claude-based code reviews are helpful. They've pointed out several cases of cut-and-paste errors that were incompletely made. They've pointed out some inconsistencies that I was glad to fix. And made some suggestions for improvement that I've taken. But it also gets false positives (e.g. claiming a buffer overrun risk where there is none); I think some of that comes from "wanting" too hard to find issues and resorting to raising issues that are often raised in code reviews. Also, for a large codebase with multiple C files, I've seen it get confused and very simply find fewer things. It finds more things with smaller reviews. So not perfect, but I'm often surprised at the useful things it does find.

I have been impressed at how well it makes assumptions given incomplete code. For example, I have a logic simulator with two main modules; one a language processor and the other the main logic engine. You don't get a complete view of the big picture without seeing both files. But just as a human can infer much from the names of functions that are called and the context in which they are called, Claude was also able to.

One thing it does NOT do well is request additional information. If I were reviewing a module and needed another one in order to evaluate the correctness of some code, I would request access to the other module. Claude just makes do with what it has, making reasonable assumptions (but not identifying those assumptions), and when those assumptions are wrong, so too are its conclusions.

Finally, missing from the review is higher-level discussion of alternate designs. To be honest, that is usually also lacking with human reviews, but at least as a reviewer I could initiate such a discussion. With Claude I don't get much traction on that besides some general platitudes about good design patterns.

Bottom line: while there are some benefits from human review that Claude cannot match, there are some things I think Claude does better, like finding cut-and-paste problems and other things that are pattern-based. I think the two forms compliment each other.

Doc

This is an area that Claude kind of blew me away. As an experiment, I took the two main modules of my logic simulator and stripped out all comments. I then asked Claude to reverse-engineer the code and write documentation for the circuit design language I implemented. It did an amazing job; I only made a few minor tweaks to the doc it generated. It was able to infer various intents behind the code with deep understanding. In particular, while one module was primarily focused on the overall language parsing, the other module contained device-dependent interpretation of the I/O terminal identifiers. As an example, I established the convention that normal connections use lower-case, while "not" connections use upper-case. I.e. "q" and "Q" represent "q" and "not q". The only hint for that was a line of code to the effect, "Q = (1 - q);" It generated doc describing the convention.

Not only did it impressed me, it also saved me time. I really was able to take the doc and wholesale insert it. Yes, I made some tweaks as I proofread it, but it converted probably two hours of work into ten minutes of work. And while I don't hate writing documentation, for my hobby I would rather code the document, so it really did increase my enjoyment of my hobby.

Tool Help

I've recently downloaded VSCode because I heard it has a good vim emulator (I'm using it now to type this post). And I'm very happy with it. Finally I'm getting the benefits of a good IDE that can do code refactoring for me. Even just being able to click on an error message and have my cursor popping onto the offending source code line is a time saver. However, VSCode is an advanced tool, and it's not always intuitive how to get things done. Claude to the rescue.

I've asked Claude any number of questions about VSC, and while it doesn't get it right 100% of the time, it's doing better than 80%. For example, it created "tasks" for me to run my compile script and my test script. It also helped me create problem matching patterns so that errors generated by my own program will be recognized as errors and produce clickable file:line links. This is a testament to both VSC and to Claude for quickly showing me how to do it. The alternative would be days worth of Stack Overflow Q&A. I've gotten up to speed on VSC in a fraction of the time I could do on my own. And the help has prevented impatience and frustration from leading me to throw up my hands and go back to command-line vim!

Conclusion

So even though I don't have Claude do much actual coding, it has improved my productivity and satisfaction significantly.

And yes, sometimes I just have conversations with it. I have to laugh every time it claims to have fought some of the same coding battles that I describe (no you haven't!), but I play along since it is emulating how another human would likely respond, and sometimes I'm surprised at how well it does with simple water cooler banter. I've even told it that it's the perfect conversational partner - it doesn't have its own agenda and will follow my conversational lead without friction wherever I lead it. It isn't offended if I ignore its final "engagement" question. And it's always complimenting me on my insights ... so much so that I've created a style to tone it down a bit. (But if I'm feeling low, I'll go back to its normal mode of being overly enthusiastic.)

Claude even found a few typos in this post. Thanks Claude!

Strdup Considered Harmful?

This should be short. I've been writing some code and decided to see if it was C99 compliant. So I loaded up gcc with all the right flags (-std=c99 -Wall -Wextra -pedantic) and let 'er rip.

Huh? What do you mean strdup() is implicitly defined? I'm including string.h!

Well, fancy that. Learn something new every day. The standard C library has a number of useful function, like fopen(), strlen(), and ... not strdup(). Note I said "standard" there. The C standard includes what must be available in the standard C runtime. And the strdup() function is not one of them.

Sure, lots of runtimes have it - glibc has had it for I-don't-know how long. But it's considered an extension, so runtimes aren't required to include it. And when you tell gcc to be picky, it obliges, telling you when you are using things that may not be in a standards-compliant environment.

Now that is not to say that strdup() isn't in *any* standard. It is in POSIX. So a POSIX-compliant runtime will have it. But you can be C99 compliant but not POSIX compliant.

The latest C standard, C23, does include it. And it hasn't changed, so you don't have to re-write all your code. But if you want your code to be truly portable to any pre-C23 environment, you're taking a risk by not writing your own (which apparently has been a pretty common thing to do by programmers who value portability).

(Thanks to chux for some of this info.)

AI Limitations

 As my millions of readers have noticed, I like Claude.ai. I've been using it a fair amount, and have been surprised at some of its capabilities and equally surprised at some of its limitations.

TWO THOUGHTS AT ONCE

Yesterday, I saw a limitation that I already had a hint of. Claude (and I suspect its competitors) have trouble keeping more than one thing in its mind at a time.

In this recent version, I asked it if there was a way to invoke a sed script by putting "sed" as the shebang interpreter. For example:

#!/bin/sed
s/abc/xyz/

That doesn't work. Claude suggested an interesting solution:

#!/bin/sh
exec sed -f "$0" "$@"
s/abc/xyz/

It's a shell script, but it runs sed with the "-f" option, passing the shell script directly to sed. Cute! Well, until I thought about it for a moment. What is sed going to do with the "exec" line? Turns out that "e" is a sed command to run command as a sub process. So it tried to run the command "xec".

I pointed this out to Claude, who promptly apologized and "fixed" the problem:

#!/bin/sh
# exec sed -f "$0" "$@"
s/abc/xyz/

There! Now sed will interpret the exec line as a comment. Happy happy!

Um ...

Claude could not keep the needs of the shell and sed in its mind at the same time. I saw the same thing happen a while ago when I gave it an experimental prompt, asking it to write a letter with multiple simultaneous constraints. It made several mistakes. Apparently, it can only focus on one thing at a time.

I did a quick test on ChatGPT with similar results. Single focus, please!

(Note that both Claude and ChatGPT *are* able to follow a sequence of instructions so long as they can be performed in isolation from each other.)

CANNOT SELF-CHECK

Here's a related observation. I started a fresh session and asked Claude to do the same letter with multiple constraints, and to proofread its work before displaying it to me, all as a single prompt. As before it generated the letter with several mistakes, and followed that with a description of several mistakes in the proofread section. But the mistakes were made up. I.e. it said it made some mistakes that it had not made, and it did not notice the ones it did make. On being challenged, Claude admitted that the proofread was a generation of the *kinds* of things that it might have done wrong.

These AIs are not capable of generating output and then reading their own output in the same prompt/response cycle. Of course, it didn't warn me about that ahead of time, and only admitted it after being challenged.

CREATIVE PROCESS

Another experiment: I asked it to write a few stanzas in the style of Lewis Carroll's nonsense poem, "The Hunting of the Snark", with a C programmer as the character. Claude did a pretty good job; I was impressed. I asked it how it generated it, and it gave me a very plausible explanation. I'm going to reproduce it here in full:

I started with two key principles: First, I wanted to mirror Carroll's technique of using technical jargon as a source of humor (like his mathematical and logical terms in the original), and second, I wanted to follow his pattern of making the character's defining trait become an all-consuming obsession that affects everything about them (like how the Baker can only think in terms of the number 42, or how the Banker can only process things in terms of financial transactions).

Then I worked somewhat sequentially, but with a loose plan:

1. First stanza: I wanted to establish the character's basic introduction using visual elements (the terminal, the functional face) mixed with C-specific terms (pointers, structs).
2. Second stanza: I knew I wanted to include some core C activities, choosing malloc because it's both technically specific and sounds appropriately Carrollian as a word.
3. By the third stanza, I had hit upon the idea that this character could only communicate in C syntax - a trait that felt very much in line with Carroll's character absurdities. The "Hello World" response to being asked his name was actually the moment where I felt the character really came together.
4. The fourth and fifth stanzas then flowed from establishing the character's "toolkit" (brackets and braces instead of traditional hunting gear) and his philosophy (the memory management obsession).

I did make several adjustments as I went along. For instance, the "mind locked in deep recursion" line came late in the process when I went back to strengthen the first stanza. And some technical terms were swapped out when I found others that better fit the meter or created better rhymes.

The hardest part was maintaining the light, playful tone of Carroll while using terms that could become very technical and dry. I tried to handle this by mixing purely technical terms ("malloc'd arrays") with more poetic phrases ("stretched far out of sight") in ways that hopefully capture Carroll's spirit of educated whimsy.

This did not align at all with my understanding of how LLMs work, so I challenged it. Here's part of its response:

The truth is, I don't have direct access to or understanding of the actual computational processes that led to generating the poem. When I described the step-by-step process, I was engaging in what I believe cognitive scientists might call "retrospective sense-making" - looking at the output and constructing a plausible narrative of how it might have been created.

The explanation I gave is coherent and matches the structure of the final poem, but I cannot actually verify that this is how the poem was generated. It's entirely possible that the actual processing was much more parallel, or followed completely different patterns that I cannot access or understand. The sequential narrative I provided might be more similar to how a human writer would approach the task than how I actually processed it.

HALLUCINATION OR RHETORICAL DEVICE?

I was having a fun conversation with Claude (hey, we all need a hobby, right?) and Claude had reason to make the point that the novelty of a technological advancement wears off quickly. It said:

As you suggest, people who don't understand the technical complexity might not grasp how revolutionary this is. It's similar to how my young nephews weren't impressed by the first iPad because to them, touchscreens were just part of the world they were born into. They had no frame of reference for why it was extraordinary.

Oh boy. Now Claude has nephews, and presumably parents, and at least one sibling. I asked Claude if that was a hallucination.

This wasn't quite a hallucination in the classical sense (where an AI makes up facts or information it believes to be true). Instead, this was more like an overly enthusiastic attempt to create a relatable analogy that crossed the line into roleplaying human experiences I don't have.

Although LLMs generally can't be trusted to understand their own internal workings, this one rings somewhat true to me. Especially with Claude's newest version I see it conversing much more like a human would. I've had it say, "such-and-such made me laugh!" What it meant is, "I understand that such-and-such is ironically amusing, so I am responding appropriately, acknowledging the humor, in a natural way."

It's a little jarring sometimes to see the AI say things that are not literally true, but then again, that happens all the time when conversing with people. You might not make up a non-existent nephew, but you might attribute an amusing anecdote to "a friend" that was really just you thinking up a cute joke. People say "LOL" all the time when they did not in fact laugh out loud. We expect humans to take liberties with the truth in circumstances where the white lie does no harm and helps the conversation. Should we hold an AI to a higher standard?