docs(twitter): add 1857820858162753661 corpus (NOTimothyLottes mmap-log 'no debugger no libc' design)

13-post thread with @bmcnett. Canonical statement of the mmap log
design: 'printf-debugging is a horrible term; if you're debugger-
free might as well be libc-free.' .log file mapped, first half =
lines of fixed 64-char size (cacheline), second half = single 32-bit
atomic counter for write position. Writing = increment atomic +
dump line. No contention, no file IO, lock-free, captures temporal
ordering across threads. Fixed format:
r|sc.milmic|line_|hex_____|0000000000-|string...
(r=reload, sc.milmic=time since launch, line=source line, hex, dec,
msg). Tlk(__LINE__, n, 'msg') API, no printf needed. Examples show
startup timing (cart mapping 0.005-0.008s) + Vulkan instance 2.4s
with PSO hits at 3K us each. Multi-run log for comparison, Notepad2
F5 to reload. Discussion of fixed line widths in modern era. The
cleanest documentation of the mmap log pattern - 8 months before
the Aug 2025 CART file announcement.

docs/twitter/1857820858162753661/thread.md

@@ -0,0 +1,90 @@
+---
+title: "@bmcnett That line of thinking is universal solution to most self-inflicted prob"
+author: "NOTimothyLottes"
+handle: "@NOTimothyLottes"
+post_url: "https://x.com/NOTimothyLottes/status/1857820858162753661"
+post_id: "1857820858162753661"
+timestamp: "2024-11-16 16:19:43"
+post_count: 13
+reply_count: 0
+repost_count: 0
+like_count: 2
+view_count: 134
+---
+
+# @NOTimothyLottes — @bmcnett That line of thinking is universal solution to most self-inflicted prob
+
+## Post 1 (2024-11-16 15:12:24)
+
+[0] What a horrible term 'printf-debugging'
+If you are debugger-free might as well at least be libc-free
+Here is how I work CPU C code without any debugger in my engines, and how it works better than a debugger for me ...
+
+## Post 2 (2024-11-16 15:15:24) — reply to Post 1
+
+[1] First I map a '.log' file, so there is no other file IO
+(a.) First half of this file (log2 sized file) contains lines of a fixed 64-character size (with the \n at the end)
+(b.) Second half contains just one 32-bit atomic counter of where to write a line
+
+## Post 3 (2024-11-16 15:18:27) — reply to Post 2
+
+[2] So writing a line to this log is 100% overhead-free and lock-free, one just increments the atomic counter, and dumps the comment line in the memory mapped file. Note the 64-byte line size matches a cacheline size, so no contention on the write of the line
+
+## Post 4 (2024-11-16 15:21:07) — reply to Post 3
+
+[3] It's ideal for a multi-thread environment, you get correct temporal ordering captured in the log file without any real effect on the scheduling of threads.
+
+## Post 5 (2024-11-16 15:23:52) — reply to Post 4
+
+[4] Lines are always in a fixed format
+r|sc.milmic|line_|hex_____|0000000000-|string...
+r ... reload count
+sc.milmic ... time since launch (wraps)
+line ... source line number (single file program)
+hex ... hex print of number
+000 ... decimal print of the number
+string ... user msg
+
+## Post 6 (2024-11-16 15:25:16) — reply to Post 5
+
+[5] I write a line with a simple function call
+Tlk(__LINE__,n,"msg");
+Where 'n' is the number, "msg" is a string
+Don't need printf, this is way better
+
+## Post 7 (2024-11-16 15:35:45) — reply to Post 6
+
+[6] Here is an example with a very simple program, just a few first lines. It's nice to automatically see exact timing. Timing since start
+0.005478 sec ... mapping of the cartridge file
+0.006850 sec ... page faulting the full cart file
+0.008230 sec ... window creation done
+etc
+
+![Media 1](./media/1857809793550872629_1.png)
+
+## Post 8 (2024-11-16 15:45:00) — reply to Post 7
+
+[7] Another simple example of a fully pipelined startup, can instantly know where the primary cost is, 
+"Instance begin" and "Instance end" wrap setup of the Vulkan instance, a process which took 2.4 seconds. The 4 PSOs hit in the shader cache at 3k microseconds each
+
+![Media 1](./media/1857812120823308592_1.png)
+
+## Post 9 (2024-11-16 15:48:37) — reply to Post 8
+
+[8] The log file keeps multiple runs, so it's easy to compare. Notepad2 it's F5 to reload the log file.
+
+## Post 10 (2024-11-16 15:58:30) — reply to Post 9
+
+@NOTimothyLottes So each line is 63 spaces followed by a \n, and those 63 spaces get replaced by printable characters dynamically? I have long dreamed of a text format with a fixed 128 byte line width, and cache line size is gradually switching over from 64 to 128
+
+## Post 11 (2024-11-16 16:10:50) — reply to Post 10
+
+@bmcnett Yes fixed character[63]='\n', string fills until then or spaces out. I did 128-char once, but still sometimes use small VGA resolutions. Also written a source editor a few times with this fixed line size, makes for a very simple implementation ...
+
+## Post 12 (2024-11-16 16:15:50) — reply to Post 11
+
+@NOTimothyLottes Variable line width ASCII text files made a lot of sense when storage was 100KB or 100MB or 100GB, but now that it's in the terabytes, why even bother
+
+## Post 13 (2024-11-16 16:19:43) — reply to Post 12
+
+@bmcnett That line of thinking is universal solution to most self-inflicted problems of the modern era.