Dmitry Vostokov 🇮🇪

I submitted the Dictionary of Debugging to print production and hope to get a proof copy of the paperback edition by the end of next week. The earlier free digital version with clickable links was remastered for print with explicit page numbers.

Table of Contents from the 800+ page book: Local AI on RTX Spark Laptops dumpanalysis.org/spark-book GitHub: github.com/DumpAnalysis/Spar…

Local AI on RTX Spark Laptops: A Hands-On WSL2 Laboratory for Inference, Training, and Deployment, CUDA Programming, GPU Diagnostics, Observability, and Debugging with Complete Exercise Transcripts (ISBN-13: 978-1919135076) is available on Leanpub leanpub.com/sparkbook Although it is currently 100% AI-generated and the exercises were executed on my RTX Spark laptop by Codex, I'm going to do all these labs manually, with some possible editing applied, and bring the book from 99% to 100% completion. I'm selling it to recover investment costs :-) The final book price will increase.

Trace and Log Analysis as a Fabrication Process: Adding and Subtracting Messages through Patterning dumpanalysis.org/trace-log-a… We can view trace and log analysis as a fabrication process. Messages and their relationships provide the material, while analysis patterns guide what we add, remove, combine, or summarize. The resulting artifact must remain connected to its source observations and to the diagnostic question it is intended to answer. In this paper, we develop this perspective through Software Codiagnostics, Diagnostic Operads, and Higher-Order Pattern Narratives. We consider how diagnostic operations compose into fabrication recipes and how their application and revision become material for further analysis. We distinguish recorded observations from derived messages, hypotheses, and padding, and examine the consequences of operation order and information loss. Two worked examples illustrate retry summarization and the recovery of context hidden by component filtering. They show why a compact trace can preserve one diagnostic property while concealing another. We connect the construction of diagnostic artifacts with provenance, preservation obligations, and the diagnosis of the analysis itself.

The Data Journalism Handbook: Towards A Critical Data Practice (open access) taylorfrancis.com/books/oa-e… I noticed this book a few years before it was made open access.

Using Lean in Pattern-Oriented Diagnostics dumpanalysis.org/using-lean-… I think Lean is the most frequent keyword in my feed, so I have to mull it over...

I finished the Introduction to Microfabrication course coursera.org/account/accompl…

Diagnosing from a distance with AI. "The computer driving this passenger display appears to have failed to boot normally and stopped at its EFI firmware shell. The key visible messages are: map: Cannot find required map name. Shell> Here, “map” means a mapping to a storage device or filesystem, not a route map. The EFI shell normally assigns names to accessible filesystems; this message indicates that the requested mapping was unavailable. My working diagnosis is a boot-storage or boot-configuration problem. The main possibilities are: - Boot storage unavailable: failed flash/SSD, a loose connection, or a storage power problem. - Incorrect boot configuration: the firmware selected the shell, or lost the intended boot entry. - Damaged boot files or partition: storage is present, but the normal startup path is unusable. Manufacturer troubleshooting documents associate this same screen with both incorrect boot priority and undetected storage. The photograph alone does not establish that the drive has failed. For maintenance, the decisive first check is whether the firmware detects the boot drive. If absent, investigate storage, connections, and power. If present, inspect boot order and the bootloader. The shell’s map -r command can refresh device mappings and help establish what it can access. The screen is successfully displaying firmware output, so the evidence points to the computer’s startup path rather than the LCD panel. The photograph does not identify the operating system or explain what triggered the failure."

Amazon is now inundated with various crosswords. So I put a unique drop (for now) into this flood. Software Diagnostics, Observability, and Debugging Crosswords (ISBN-13: 978-1919135045). TOC and clickable references are available here: dumpanalysis.org/software-di…, but the full book is only available in paperback, as we are supposed to fill it in with a pencil.

Neurolinguistic and Neurosymbolic Approaches to Memory Dump Analysis: Representation access and functional dissociation in pattern-oriented diagnostics. dumpanalysis.org/neurolingui… This paper complements my recent posts on PrologWinDbg and Prolog for Pattern-Oriented Software Diagnostics. I have to mull it over.

Started my FPGA education with an assortment of boards.

Sending the Electronic Design Automation Acronym Dictionary to print production with a glossy cover so the gold pins will shine, I hope.

Prolog for Pattern-Oriented Diagnostics: Logic Programming for Memory Dump, Trace, and Log Analysis - a book I asked to be written for me, both to brush up on Prolog and to experiment with my pattern languages. I'm planning to study the paperback version with a pen for possible corrections and new ideas. Full PDF: dumpanalysis.org/prolog-for-…

The initial version of the Prolog WinDbg extension is out there: github.com/DumpAnalysis/Prol… The accompanying book will be published later today. Finally, I resumed work that I started more than 15 years ago... dumpanalysis.org/blog/index.…

Semiotics in My Work on Software Diagnostics: From memiotics to observability and Codesign A memory dump, a trace, or a log contains signs of software structure and behavior. Their diagnostic meaning depends on how they were produced, what they refer to, and the context in which I interpret them. A familiar message can suggest completion when it records only acceptance. A recurring pattern can direct an investigation while leaving its cause unresolved. In this article, I trace the semiotic thread in my work from memiotics, introduced in 2008, through analysis pattern icons, symbolic notation, software narratology, and trace linguistics to pattern-oriented observability and Codesign with large language models. I begin with an overview of semiotics and connect its concepts to concrete diagnostic examples. Articles, books, pattern descriptions, and seminar transcripts provide the historical references. The discussion brings together memory interpretation, meaningful trace units, diagnostic residues, and the design of interpretable observations. Throughout, I return to the relationship between an artifact, its interpretation, and the claim it supports. What does this sign allow me to say about the software, and what additional evidence do I need? dumpanalysis.org/semiotics-s…