On 3/7/24 12:15, John Hubbard wrote: > On 3/7/24 12:03, Randy Dunlap wrote: >> On 3/7/24 10:17, Kent Overstreet wrote: >>> On Wed, Mar 06, 2024 at 07:18:57PM -0800, Randy Dunlap wrote: > ... >>>>> +- i.e. iterating over them to print them in debugfs/procfs. >>>> >>>> i.e., iterating >>> >>> i.e. latin id est, that is: grammatically my version is fine >>> >> >> Some of my web search hits say that a comma is required after "i.e.". >> At least one of them says that it is optional. >> And one says that it is not required in British English. >> >> But writing it with "that is": >> >> >> hence code tagging) and then finding and operating on them at runtime >> - that is iterating over them to print them in debugfs/procfs. >> >> is not good IMO. But it's your document. >> > > Technical writing often benefits from a small amount redundancy. Short > sentences and repetition of terms are helpful to most readers. And this > also stays out of the more advanced grammatical constructs, as a side > effect. > > So, for example, something *approximately* like this, see what you > think: > > Memory allocation profiling is based upon code tagging. Code tagging is > a library for declaring static structs (typically by associating a file > and line number with a descriptive string), and then finding and > operating on those structs at runtime. Memory allocation profiling's > runtime operation is simply: print the structs via debugfs/procfs. Works for me. Thanks. -- #Randy
