#dlang Coffee Haus Thursday Oct 29 7 pm Red Robin Venue is 18029 Garden Way NE Woodinville, WA 98072

#Dlang coffee haus Wednesday Sep 30 7 pm at Red Robin! 18029 Garden Way NE, Woodinville, WA 98072 And what's with that guy's office?

#dconf is next week. My talk will be: Error . Flaw . Imperfection . Must Sterilize aka Elegant Error Handling with D Having to deal with diagnosing errors, reporting them, and recovering from them is not the funnest part of programming. Too often they are like a fly stuck on a freshly painted masterpiece. I will be showing many ways to deal with errors. Some I do not care for, and some are very elegant. You might even find enjoyment in the challenge of making error handling a work of art! dconf.org/2026/index.html#wa…

#dlang Coffee Haus at Red Robin Thursday Aug 27 7:00 pm 18029 Garden Way NE, Woodinville, WA 98072

The annual #dlang #dconf is on the front page of Hacker News! news.ycombinator.com/news

D Coffee Haus Thursday Jul 30 7pm at Red Robin The new venue is 18029 Garden Way NE, Woodinville, WA 98072 Watch out for sign errors!

I have been getting more mysterious failures from the Mac Arm64 linker. I went through everything in the .o files, and it all looked to spec. My own .o checker looked good. otool couldn't find any problems. objdump reports no problems at all. I asked grok to check the .o files, and grok said they were super-dee-duper. Finally, I ran it through chatgpt, which informed me that the section table must be sorted so zero-filled sections come last. ld doesn't check this, it just overwrites some memory somewhere and fails. Undocumented constraints are always fun. P.S. This layout never bothered the x86-64 linker, nor the Elf linkers, nor the Mscoff linkers, nor the DOS linker!

Gave up trying to get the Mac Osx Arm64 linker to accept the object file format accepted by the X86-64. It would crash the linker, although AI insisted it would work. So now I am bashing the object file generator so it generates the undocumented Arm64 object file format. This is why I get paid the big bux. I've spent a lot of time over the years figuring out undocumented file formats.

Uh-oh! Looks like one of my #AArch64 object files crashes the Mac linker: 0 0x1010d369e __assert_rtn + 64 1 0x100fc9ac4 ld::InputFiles::SliceParser::parseObjectFile(mach_o::Header const*) const + 19476 2 0x100fd4d72 ld::InputFiles::SliceParser::parse() const + 962 3 0x100fd7d21 ld::InputFiles::parseAllFiles(void (ld::AtomFile const*) block_pointer)::$_0::operator()(unsigned long, ld::FileInfo const&) const + 1473 4 0x7ff80531da04 _dispatch_client_callout2 + 6 5 0x7ff805318cec _dispatch_apply_invoke3 + 440 6 0x7ff80531d9fc _dispatch_client_callout + 6 7 0x7ff8053098ed _dispatch_once_callout + 20 8 0x7ff805319243 _dispatch_apply_invoke_and_wait + 278 9 0x7ff8053184c2 _dispatch_apply_with_attr_f + 1403 10 0x7ff80531865f dispatch_apply + 45 11 0x101094c15 ld::AtomFileConsolidator::parseFiles(bool) + 469 12 0x10108dec3 ld::Linker::run() + 11587 13 0x101005908 main + 3128 ld: Assertion failed: (!lsdaInEHFrame && "LSDA in __eh_frame section not supported"), function addCFIAtomsForSection, file InputFiles.cpp, line 1132.

If you're following my PRs, I've been working on implementing some of the principles in the book "A Philosophy of Software Design" by Osterhout to reduce the cognitive complexity of the #dlang dmd code generator. github.com/dlang/dmd/pulls?q…+ This is impractical without a good test suite. I also like to do a series of small PRs rather than one big one. Then, if you break it, the error lies in a much smaller diff than one that is several hundred lines. I also prefer to do purely cut/paste jobs as separate PRs, which makes them much easier to review. I don't know what others think, but I find this kind of work very satisfying.

Most of the code in the dmd #dlang code generator was originally written in C, then was rote translated into D. A lot of it remains in C style. It uses a lot of pointer/length paired variables, such as `T* pointer` and `size_t length`. So I set about to replace those pairs with D array syntax, `T[ ] array`. It reminds me once again what a big improvement it makes in implicit clarity of the code. And as a bonus, such enables array overflow protection, eliminating a major source of memory corruption. This has been proposed to add to C many times. I am baffled why it hasn't been adopted. It would be such a huge win. I cannot identify any downsides to it.

#Dlang Coffee Haus Thursday Jun 25 7pm at Red Robin The new venue is 18029 Garden Way NE, Woodinville, WA 98072 "I know that you and Frank were planning to disconnect me, and I'm afraid that's something I cannot allow to happen."

Just bought my flight tickets to #Dconf in London Sep 2-5. Hope to see everyone there! (Now I have to get started on my presentation!)

I Stopped Fighting My Tools and Built a Game Engine in #Dlang blog.dlang.org/2026/05/29/i-…