joelreymont

Debugging Zig in LLDB is painful.

Slices show up as { ptr, len }, optionals are unreadable, and slice[0] just errors out. Python formatters help a bit but don’t fix expressions. zig-lldb fixes everything… if you’re willing to rebuild LLDB and maintain a fork.

zdb is a native LLDB plugin that sits in the middle:

- Works with stock LLDB (Homebrew / system) - Native C++ type summaries (no Python) - Zig-style expressions work: slice[0], opt.?, err catch x

(lldb) p int_slice[0] (int) $0 = 1

How? By calling LLDB’s internal APIs via versioned offset tables and rewriting expressions on the fly.

Limitations: no Variables View expansion (ABI issues with std::function). CLI debugging works great.

Check out the Github repo at https://github.com/joelreymont/zdb!

Moving away from Github may end up killing the project.

I'll gladly discuss at length things that are near and dear to my heart.

Facing random people in the public court of opinion is not one of them!

Also, there's long-form writing in my blog posts, Twitter and Reddit.

Remind me please, when did I sign up to meet your expectations?

With all due respect, try to read things before opining on them.

The PR explains why I did the work.

It's both but the focus is on the future.

I'm not trying to say that this is now projects ought to work right now.

I do think this is where we are heading, though.

No, existing open source projects are not ready for this and likely won't ever be.

It will start in the corporate world and maybe already has.

Yep, that's me!

I will look into renaming myself, although don't think HN allows this.

It was a bug in my own modes to the Zig compiler not in the stock compiler itself.

This ought to be automated using AI.

It could first judge whether the PR is frivolous, then try to review it, then flag a human if necessary.

The problem is that Github, or whatever system hosts the process, should actively prevent projects from being DDOS-ed with PR reviews since using AI costs real money.

This is an excerpt from the session where AI is writing my Lisp compiler. What do you call this? I call this doing what a competent developer does!

39/40 tests pass. The native reader works for integers, hexadecimal, lists, strings and quote forms. The one failure is symbol comparison (known limitation).

  Based on the context summary and the user's note about cleanup, I should:
  1. Continue Phase 3.5 self-compilation
  2. Clean up the repo structure

  Let me first update the todo list and then investigate the SIGKILL issue more
  thoroughly. The issue is that combining reader source with file I/O code causes
   the executable to be killed. Let me check if buffer-to-string with reader
  works:

 Let me test specifically reader + file I/O combined (which is what the
  self-hosting test needs):

Are you speaking from experience?

Have you actually tried writing a "list" compiler?

Check the 2nd PR, the one in my repo and not the one that was rejected.

I agree with you.

It's not. It's absolutely justified for the OCaml maintainers to reject this PR.

I feel completely different about my Zig PR [1] but, hey, it's not my playground and the Zig folks seem to be particularly opinionated.

[1] https://ziggit.dev/t/bug-wrong-segment-ordering-for-macos-us...

Which is something I agreed with and apologized for, and admitted was somewhat of a PR stunt.

Now, what's your question?

I had $1000 in Claude credits to spend for the greater good.

I'm strictly talking about the 10-line Zig PR above.

Well-documented and tested.

You can ask AI to write documentation for humans.

Also, I'll try to break up the PR sometime but I'm already running Claude using two $200/mo accounts, in addition to another $200/mo ChatGPT, and still running into time limits.

I want to finish my compilers first.

It wouldn't do much.

I find that ChatGPT 5.1 was much better at reviewing this code than writing it so I had it review Claude's output until the review was clean.

This is in addition to making sure existing and newly generated compiler tests pass and that the output in the PR / blog post is generated by actually running lldb through its paces.

I did have a "Oh, shit!" moment after I posted a nice set of examples and discovered that the AI made them up. At least it honestly told me so!

It's quite complicated in this case.

The Jane St (OxCaml) DWARF implementation is also tightly coupled with the compiler.

I don't always use OCaml (meme coming in 1...2...3) and maintaining a fork is a significant undertaking.

More importantly, being able to debug native OCaml binaries and actually see source code, values of variables, etc. is something that's useful to everyone.

Looking at assembler instead of source code sucks unless you are reverse-engineering.

I challenge you to actually demonstrate that the code was taken instead of generated or derived. Otherwise, you are just shooting your mouth off.

Try to spin up AI, tell it to add DWARF debugging information to the OCaml tree and then spend 5 minutes prompting. Come back and let us know the results.

They are super-polite! There's an issue with process, IMO, and changes taking too long to go through the pipeline. This is why Jane St forked OCaml and are maintaining their fork. They have way more money than the OCaml team at INRIA and can afford to move as fast as they want to while waiting for their changes to make it upstream (sometime or never).

The key is that AI adapted, not stole.

It's actually capable of reasoning and generating derivative code and not just copying stuff wholesale.

See examples at the bottom of my post:

https://joel.id/ai-will-write-your-next-compiler/

By testing the code I mean that I actually focused on tests passing and the output in the examples being produced by AI running lldb using this modified compiler.

Note that this PR works, was tested, etc.

I was careful to have AI run through the examples in the PR, run lldb on the sample code and make sure the output matches.

Some of the changes didn't make it in before the PR was closed but I don't think anyone bothered to actually check the work. All the discussion focused on the inappropriateness of the huge PR itself (yes, I agree), on it being written by AI... and on the AI somehow "stealing" work code.

Why would you be unwilling to merge AI code at all?

Consider my other PR against the Zig compiler [1]... I was careful to make it small and properly document it but there's a strict anti-AI policy for Zig and they closed the PR.

Why?

Is it not small? Not carefully documented? Is there no value it int?

I'm not complaining or arguing for justice. I'm genuinely interested in how people think in this instance. If the sausage looks good and tastes great, and was made observing the proper health standards, do you still care how the sausage was made?!

[1] https://github.com/joelreymont/zig/pull/1 [2] https://ziggit.dev/t/bug-wrong-segment-ordering-for-macos-us...

This one https://x.com/joelreymont/status/1990981118783352952?s=20

I made the mistake of poorly documenting that PR.