Historical footnote: DDT was developed at MIT for the PDP-1 computer in 1961. At that time DDT stood for "DEC Debugging Tape". Since then, the idea of an on-line debugging program has propagated throughout the computer industry. DDT programs are now available for all DEC computers. Since media other than tape are now frequently used, the more descriptive name "Dynamic Debugging Technique" has been adopted, retaining the DDT abbreviation. Confusion between DDT-10 and another well known pesticide, dichloro-diphenyl-trichloroethane (C14-H9-Cl5) should be minimal since each attacks a different, and apparently mutually exclusive, class of bugs.
(The `tape' referred to was, incidentally, not magnetic but paper.) Sadly, this quotation was removed from later editions of the handbook after the {suit}s took over and DEC became much more `businesslike'.
The history above is known to many old-time hackers. But there's more: Peter Samson, compiler of the original {TMRC} lexicon, reports that he named `DDT' after a similar tool on the TX-0 computer, the direct ancestor of the PDP-1 built at MIT's Lincoln Lab in 1957. The debugger on that ground-breaking machine (the first transistorized computer) rejoiced in the name FLIT (FLexowriter Interrogation Tape).
:de-rezz: /dee-rez'/ [from `de-resolve' via the movie
"Tron">[ (also `derez') 1. /vi./ To disappear or dissolve; the
image that goes with it is of an object breaking up into raster
lines and static and then dissolving. Occasionally used of a
person who seems to have suddenly `fuzzed out' mentally rather than
physically. Usage: extremely silly, also rare. This verb was
actually invented as *fictional* hacker jargon, and adopted in
a spirit of irony by real hackers years after the fact. 2. /vt./
The
Macintosh resource decompiler. On a Macintosh, many program
structures (including the code itself) are managed in small
segments of the program file known as `resources'; `Rez' and
`DeRez' are a pair of utilities for compiling and decompiling
resource files. Thus, decompiling a resource is `derezzing'.
Usage: very common.
:dead: /adj./ 1. Non-functional; {down}; {crash}ed. Especially used of hardware. 2. At XEROX PARC, software that is working but not undergoing continued development and support. 3. Useless; inaccessible. Antonym: `live'. Compare {dead code}.
:dead code: /n./ Routines that can never be accessed because all calls to them have been removed, or code that cannot be reached because it is guarded by a control structure that provably must always transfer control somewhere else. The presence of dead code may reveal either logical errors due to alterations in the program or significant changes in the assumptions and environment of the program (see also {software rot}); a good compiler should report dead code so a maintainer can think about what it means. (Sometimes it simply means that an *extremely* defensive programmer has inserted {can't happen} tests which really can't happen — yet.) Syn. {grunge}. See also {dead}, and {The Story of Mel, a Real Programmer}.
:dead link: /n./ [WWW] A World-Wide-Web URL that no longer points to the information it was written to reach. Usually this happens because the document has been moved or deleted. Lots of dead links make a WWW page frustrating and useless and are the #1 sign of poor page maintainance. Compare {dangling pointer}.
:DEADBEEF: /ded-beef/ /n./ The hexadecimal word-fill pattern for freshly allocated memory (decimal -21524111) under a number of IBM environments, including the RS/6000. Some modern debugging tools deliberately fill freed memory with this value as a way of converting {heisenbug}s into {Bohr bug}s. As in "Your program is DEADBEEF" (meaning gone, aborted, flushed from memory); if you start from an odd half-word boundary, of course, you have BEEFDEAD. See also the anecdote under {fool}.
:deadlock: /n./ 1. [techspeak] A situation wherein two or more processes are unable to proceed because each is waiting for one of the others to do something. A common example is a program communicating to a server, which may find itself waiting for output from the server before sending anything more to it, while the server is similarly waiting for more input from the controlling program before outputting anything. (It is reported that this particular flavor of deadlock is sometimes called a `starvation deadlock', though the term `starvation' is more properly used for situations where a program can never run simply because it never gets high enough priority. Another common flavor is `constipation', in which each process is trying to send stuff to the other but all buffers are full because nobody is reading anything.) See {deadly embrace}. 2. Also used of deadlock-like interactions between humans, as when two people meet in a narrow corridor, and each tries to be polite by moving aside to let the other pass, but they end up swaying from side to side without making any progress because they always move the same way at the same time.
:deadly embrace: /n./ Same as {deadlock}, though usually used only when exactly two processes are involved. This is the more popular term in Europe, while {deadlock} predominates in the United States.