Dennis Yurichev

For those who haven't seen Knuth's own analysis of his errors while writing TeX, it's well worth reading his 1989 article "The Errors of TeX" [1] and glancing through the full chronological list of errors [2]. [1] https://yurichev.com/mirrors/knuth1989.pdf [2] https://ctan.math.utah.edu/ctan/tex-archive/info/knuth-pdf/errata/erro…

Run `texdoc errorlog`, or visit http://mirrors.ctan.org/info/knuth-pdf/errata/errorlog.pdf — published as Chapter 11 ("The error log of TeX") of the book (collection of papers) Literate Programming (https://cs.stanford.edu/~knuth/lp.html), and it best makes sense if you also read the previous Chapter 10 "The errors of TeX" (DOI 10.1002/spe.4380190702, https://yurichev.com/mirrors/knuth1989.pdf).

I love it how with the Z3Py solver you just write down a few constraints (rows, columns, 3x3 boxes and the given values) and you immediately get an answer. [0] https://ericpony.github.io/z3py-tutorial/guide-examples.htm [1] https://yurichev.com/writings/SAT_SMT_by_example.pdf

All I can do is recommend people to try out the z3 solver, especially through the Python API. There's no better resource than https://yurichev.com/writings/SAT_SMT_by_example.pdf.

> That handful of code took me almost a year to write. Formatting can be tough. See Knuth's extensive bug list for TEX from 1987 at https://yurichev.com/mirrors/knuth1989.pdf to see the kind of tarpit one can get trapped in.

This is good too: https://yurichev.com/writings/SAT_SMT_by_example.pdf

The problem with Ada, was the price of the compilers, and that the few UNIX vendors that bothered with Ada, like Sun, it was an additional license on top of the already expensive SunOS/Solaris Developer SDK. Thus the push for C and C++, alongside security certifications, where those languages feel like using Ada with a C like syntax. https://www.perforce.com/blog/kw/NASA-rules-for-developing-safety-crit… https://yurichev.com/mirrors/C/JPL_Coding_Standard_C.pdf https://misra.org.uk/ Nowadays we live in a world where developers refuse to pay for their tools like other professionals, but hey, Rust is free beer, not like the several millions per seat licenses used by Ada vendors, of whom there are still 7 vendors in business.

One interesting read from a purely software side is the JPL C standards, which are an extension of software standards for things like Mars rovers that cannot not work. There’s a summary on page 4 if you don’t want to read the whole thing https://yurichev.com/mirrors/C/JPL_Coding_Standard_C.pdf Here’s a good article specific to Voyager https://www.allaboutcircuits.com/news/voyager-mission-anniversary-comp… I can’t find it but there was a slide deck online for Curiosity with an explanation of all the stuff I was talking about above

More modern take of this https://yurichev.com/mirrors/C/JPL_Coding_Standard_C.pdf

This paper is a case study of program evolution. The author kept track of all changes made to TEX during a period of ten years, including the changes made when the original program was first debugged in 1978. The log book of these errors, numbering more than 850 items, appears as an appendix to this paper. The errors have been classified into fifteen categories for purposes of analysis. I came to the conclusion that the designer of a new system must not only be the implementor and the first large-scale user; the designer should also write the first user manual. - Donald Knuth, 'The Errors of TeX' (1989) https://yurichev.com/mirrors/knuth1989.pdf (4.8MB) ... via https://github.com/globalcitizen/taoup

Reminds me of Knuth's paper 'The errors of TeX'. He had logged all bugs he made while programming TeX and classified them. Paper is online here: https://yurichev.com/mirrors/knuth1989.pdf

Although I sympathize with this line of thought, remember that we’re all uninitiated by the standards of a few decades ago. The time was when you were uninitiated if you couldn’t hand assemble your programs to a series of hex digits. Indeed, I own a copy of a book aimed at children that teaches you how to do just that for the BBC Micro and ZX Spectrum. (The publisher released it as a free PDF if anyone is curious: https://yurichev.com/mirrors/machine-code-for-beginners.pdf)

Shameless plug about IEEE 754 round-off errors: https://yurichev.com/news/20210131_IEEE_754/

Relevant: Knuth's paper "The Errors of TeX" https://yurichev.com/mirrors/knuth1989.pdf

Not sure which one you are looking for, but MISRA is posted here often when speaking of C/C++ and safe practices. That is kinda focused in the embedded space however, so may not be the same thing you are thinking of. Another common one is JPL C coding standard that has been referenced here before: https://en.wikipedia.org/wiki/MISRA_C https://yurichev.com/mirrors/C/JPL_Coding_Standard_C.pdf

If you enjoy this format, the same author also wrote "SAT/SMT By Example" which I learned a lot from: https://yurichev.com/SAT_SMT.html

Minesweeper: https://yurichev.com/blog/minesweeper_SAT_SN Hexiom: https://github.com/hugomg/hexiom

I found this blog post quite interesting[1]. The author is optimising rack positionning to minimise cabling. However, trying to use his method to optimise a linear typewriter[2] proved unsuccessful, as projected solving time was around 13 million years. [1]https://yurichev.com/blog/cabling_Z3/ [2]https://www.benjaminpoilve.com/projects/typewriter-optimisation.html

"SAT/SMT by Example" that appeared on the front page a day or two ago is also good, if you missed it. https://yurichev.com/SAT_SMT.html

Interesting; I'll have to takea closet look at https://yurichev.com/writings/SAT_SMT_by_example.pdf. If you've heard of Frama-C, these issues are highlighted by automatically inserted checks.

DiffPDF 2.1.3 finds only two tiny (if weird) differences in the appearance of the two versions of the books (https://yurichev.com/writings/AL4B-EN.pdf and https://beginners.re/RE4B-EN.pdf) besides the title, author and build date: two page references at pages 1075 and 1078. Since both sites appear to be owned by the book's author this is most likely just a change that has not yet been pushed to github (or mentioned in the author's sites), but it would be better if the author clarified it (would that be you, dennis714?)

The author of this (Dennis Yurichev) has also written a 200 page "Quick introduction into SAT/SMT solvers and symbolic execution" that is full of examples of how SAT/SMT solvers can be used. [1]: https://yurichev.com/writings/SAT_SMT_draft-EN.pdf

> There ought to be some representation for theorem resolvers that is good for general purpose programming. It's just that nobody found it yet. There are some nice examples of search-based programming in Z3 (using the Python API) in https://yurichev.com/writings/SAT_SMT_draft-EN.pdf , if that is along the lines of what you meant.

Starting back around 2009, I started marking bug fixes in git with the first line containing "Bug fix---description". For example (from my gopher server [1]): a12c3fd Bug fix---sample forgot POST method. 0b1bce2 Bug fix---grab guid when only given numeric uid. 31408da Bug tracking---crash because filename is nil? d993265 Bug fix---Clean the display text to prevent broken index files. 47e98e8 Bug fix---line comments were broken in .port70 files. I do the same at work. I got the idea from Donald Knuth, who wrote a paper about classifying each error in TeX [2]. I didn't go as far as he did, but I still have his list handy: * Algorithm * Blunder * Cleanup * Data * Efficiency * Forgotten * Generalization * Interaction * Language * Mismatch * Portability * Quality * Robustness * Surprise * Typo [1] https://github.com/spc476/port70 [2] "The Errors of TeX" <https://yurichev.com/mirrors/knuth1989.pdf>

A nice complement (and a generalization) of the MISRA C guidelines are the NASA/JPL C guidelines [1], which are also a very beautiful read. They can be succinctly summarized as ten simple rules [2] : 1. Avoid complex flow constructs, such as goto and recursion. 2. All loops must have fixed bounds. This prevents runaway code. 3. Avoid heap memory allocation. 4. Restrict functions to a single printed page. 5. Use a minimum of two runtime assertions per function. 6. Restrict the scope of data to the smallest possible. 7. Check the return value of all non-void functions, or cast to void to indicate the return value is useless. 8. Use the preprocessor sparingly. 9. Limit pointer use to a single dereference, and do not use function pointers. 10. Compile with all possible warnings active; all warnings should then be addressed before release of the software. [1] https://yurichev.com/mirrors/C/JPL_Coding_Standard_C.pdf [2] https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Sa…

Deep dive - https://yurichev.com/writings/UAL-EN.pdf

These are other good resources: - rise4fun https://rise4fun.com/z3/tutorialcontent/guide - https://ericpony.github.io/z3py-tutorial/guide-examples.htm - Programming Z3 -https://theory.stanford.edu/~nikolaj/programmingz3.html - Nikolaj Bjorner's tutorial https://youtu.be/nGwyNmsxX6I - Hakank's examples http://www.hakank.org/z3/ - Yurichev's book "SMT by Example" https://yurichev.com/writings/SAT_SMT_by_example.pdf - http://hackage.haskell.org/package/sbv - https://www.youtube.com/watch?v=ruNFcH-KibY Tikhon Jelvis - Analyzing Programs with Z3 - https://www.youtube.com/watch?v=rvPWDgJc0O4&ab_channel=ACMSIGPLAN - Nadia Polykarpova on Z3 - SAT SMT school https://sat-smt.in/ - Emina Torlak's course https://courses.cs.washington.edu/courses/cse507/19au/calendar.html - Lindsey Kuper - SMT Solving and Solver-Aided Systems http://composition.al/CSE290Q-2019-09/ - http://www.sc-square.org/CSA/school/lectures.html

Focusing on x86-64 (don't waste your time starting with the 32-bit variant when learning, let alone x87 FPU instructions, there's plenty of up-to-date materials for contemporary architectures nowadays): - Chapter 10, Assembly Language (https://www3.nd.edu/~dthain/compilerbook/compilerbook.pdf#chapter.10) of http://compilerbook.org/ - intro_x86-64: Introduction to x86_64 assembly - https://gitlab.com/mcmfb/intro_x86-64 - Introduction to 64 Bit Assembly Language Programming for Linux and OS X - Ray Seyfarth - http://rayseyfarth.com/asm/ - Introduction to Computer Organization with x86-64 Assembly Language & GNU/Linux - Robert G. Plantz - http://bob.cs.sonoma.edu/IntroCompOrg-x64/book.html - Modern X86 Assembly Language Programming - 2018; Daniel Kusswurm - Covers x86 64-bit, AVX, AVX2, and AVX-512 - https://github.com/Apress/modern-x86-assembly-language-programming-2e - Understanding Assembly Language - a.k.a. Reverse Engineering for Beginners; https://yurichev.com/blog/UAL/ - https://beginners.re/ - x86-64 Assembly Language Programming with Ubuntu - Ed Jorgensen - http://www.egr.unlv.edu/~ed/x86.html - Assembly Programming and Computer Architecture for Software Engineers (APCASE) - https://github.com/brianrhall/Assembly - Videos: https://www.youtube.com/channel/UCr0svQEez3UQvlj6-5EYS6w Or, if you prefer talks: - Just enough Assembly for Compiler Explorer - Anders Schau Knatten - NDC TechTown 2019 - https://www.youtube.com/watch?v=soeFwz0cOqU - Modern…