:TOPS-20:: /tops-twen'tee/ /n./ See {{TWENEX}}.
:tourist: /n./ [ITS] A guest on the system, especially one who generally logs in over a network from a remote location for {comm mode}, email, games, and other trivial purposes. One step below {luser}. Hackers often spell this {turist}, perhaps by some sort of tenuous analogy with {luser} (this also expresses the ITS culture's penchant for six-letterisms). Compare {twink}, {read-only user}.
:tourist information: /n./ Information in an on-line display that is not immediately useful, but contributes to a viewer's gestalt of what's going on with the software or hardware behind it. Whether a given piece of info falls in this category depends partly on what the user is looking for at any given time. The `bytes free' information at the bottom of an MS-DOS `dir' display is tourist information; so (most of the time) is the TIME information in a Unix `ps(1)' display.
:touristic: /adj./ Having the quality of a {tourist}. Often used as a pejorative, as in `losing touristic scum'. Often spelled `turistic' or `turistik', so that phrase might be more properly rendered `lusing turistic scum'.
:toy: /n./ A computer system; always used with qualifiers.
1. `nice toy': One that supports the speaker's hacking style
adequately. 2. `just a toy': A machine that yields insufficient
{computron}s for the speaker's preferred uses. This is not
condemnatory, as is {bitty box}; toys can at least be fun. It
is also strongly conditioned by one's expectations; Cray XMP users
sometimes consider the Cray-1 a `toy', and certainly all RISC
boxes and mainframes are toys by their standards. See also {Get
a real computer!}.
:toy language: /n./ A language useful for instructional
purposes or as a proof-of-concept for some aspect of
computer-science theory, but inadequate for general-purpose
programming. {Bad Thing}s can result when a toy language is
promoted as a general purpose solution for programming (see
{bondage-and-discipline language}); the classic example is
{{Pascal}}. Several moderately well-known formalisms for
conceptual tasks such as programming Turing machines also qualify
as toy languages in a less negative sense. See also {MFTL}.
:toy problem: /n./ [AI] A deliberately oversimplified case of a
challenging problem used to investigate, prototype, or test
algorithms for a real problem. Sometimes used pejoratively. See
also {gedanken}, {toy program}.
:toy program: /n./ 1. One that can be readily comprehended;
hence, a trivial program (compare {noddy}). 2. One for which
the effort of initial coding dominates the costs through its life
cycle. See also {noddy}.
:trampoline: /n./ An incredibly {hairy} technique, found in some {HLL} and program-overlay implementations (e.g., on the Macintosh), that involves on-the-fly generation of small executable (and, likely as not, self-modifying) code objects to do indirection between code sections. These pieces of {live data} are called `trampolines'. Trampolines are notoriously difficult to understand in action; in fact, it is said by those who use this term that the trampoline that doesn't bend your brain is not the true trampoline. See also {snap}.
:trap: 1. /n./ A program interrupt, usually an interrupt caused by some exceptional situation in the user program. In most cases, the OS performs some action, then returns control to the program. 2. /vi./ To cause a trap. "These instructions trap to the monitor." Also used transitively to indicate the cause of the trap. "The monitor traps all input/output instructions."