CLIM 2 demonstrations and tutorial programs on Genera

Scope, evidence, and interaction conventions

The evidence layers answer different questions:

All programs are CLIM application frames. A frame owns application state and a layout of panes; its command table owns typed commands and menu inheritance; presentations connect displayed objects to Lisp objects; translators turn a gesture over a presentation into a command; accepting-values and gadgets form dialogs; output records retain visible structure; and incremental redisplay updates selected records rather than blindly redrawing a whole pane. Those are portable CLIM concepts. Genera-specific activity registration, Select keys, filesystem calls, process operations, and printer integration are identified as such.

Application tables below use CLIM's semantic gesture names. On the inspected Genera port, Select is the ordinary left-button action, Describe is the ordinary middle-button action, and Delete is Shift-Middle. A source-defined modified gesture is spelled out literally. Edit is retained by name where the application relies on the port's standard edit gesture; no unverified physical mapping is invented. Right invokes the context menu of currently applicable presentation translators. The complete common 36-command input editor, activation, completion, abort, and command-entry bindings are documented once in CLIM 2 on Symbolics Genera and apply to accepted text in these frames unless an application shadows them.

address-book

address-book is a volatile, shared address list that demonstrates presentations and incremental redisplay. It has a current-address pane, a sorted names pane, and an interactor. Five sample contacts seed a global list; every Address Book frame in the same Lisp shares that list.

Entries are sorted by the substring after the final space in the name, making the last word act like a surname. The implementation rejects a new entry whose name matches an existing name case-insensitively, but gives no duplicate warning. There is no save, load, import, export, or address-book file format. The manual summarizes lookup, add, remove, and edit; the shared global database, sort rule, and silent duplicate suppression are source-only findings.

Dependencies are CLIM Demo, accepting-values, presentations, and incremental redisplay. Safety impact is limited to volatile Lisp state. Screenshot/runtime TODO: launch and capture the names/current-address/edit states after CLIM and Genera-CLIM can be loaded into an unsaved isolated world; currently blocked by the absent CLIM system.

CLIM bitmap-editor

The CLIM bitmap-editor is an 8-by-8 pattern exercise, not the full Genera Dynamic Windows Bitmap Editor documented in Bitmap, stipple, and raster paint editors. Its three panes are an accepting-values palette, a magnified cell grid, and a live preview of the resulting CLIM pattern. Defaults are eight rows, eight columns, ten-pixel cells, and a two-entry black/white palette.

Resizing allocates a new array, preserves the overlapping old rectangle, fills new cells with palette index zero, and relays out the frame. The preview builds a CLIM pattern from the index array and palette. The manual explains the grid and preview connection but does not disclose three important implementation facts: selecting a cell cycles rather than paints with current-color, both color-editing buttons are stubs, and there is no save/load/export path. No image file is read or written.

Dependencies are CLIM Demo, accepting-values, gadgets, colors, patterns, and the demo color chooser. Safety impact is confined to volatile pattern and palette state; the program performs no filesystem I/O. Screenshot/runtime TODO: capture palette, grid, preview, and Options after optional CLIM loading is possible; the base world has no CLIM.

browser

browser is an extensible graph/text browser over live Lisp and Genera objects. Its scrollable graph pane uses incremental redisplay, its interactor accepts commands, and a modeless control pane selects the browser family and rendering options.

Function browsing inspects compiled callers/callees; class and package browsing use live CLOS/package metadata; filesystem browsing reads guest directories. The Lisp-object browser is more dangerous: a list whose first element names a function can be evaluated, and a symbol can be resolved through its value. Use it only on trusted input. Hardcopy mutates the guest filesystem or contacts a configured printer. Snapshots are not files and do not survive the Lisp image.

The manual documents graph selection, adding/removing/hiding/ellipsizing nodes, and hardcopy. Source adds the exact control ranges, snapshot behavior, subnode gestures, and two defects/oddities: the exported-symbol subnode reuses an “instance variables” title, and no persistence exists for snapshots. A source comment also describes editing the underlying object, but the inspected command table defines no corresponding browser translator; this remains an unimplemented or stale-comment feature, not a documented control.

The Genera activity declaration contains raw byte 0x03 as its Select key. That byte is preserved as source evidence, but its intended Symbolics key name is not asserted without runtime or character-encoding confirmation.

Dependencies are CLIM Demo plus Genera CLOS, packages, filesystem, compiler cross-reference data, and optional hardcopy services according to browser type. Screenshot/runtime TODO: capture the control pane and at least class and package graphs after CLIM becomes loadable in isolation; currently no browser frame can be created.

cad-demo

cad-demo is a gate-level logic drawing demonstration. A single design pane is also its output history. It can place And gates, Or gates, constant Logic One, and constant Logic Zero components; wires connect outputs to inputs. Components and pins are custom output records and presentations rather than a separate CAD document format.

The manual emphasizes custom output records, custom highlighting, menu-directed commands, and record dragging. It also explicitly warns that a feedback circuit can crash the demo. Source inspection shows no save/load, netlist, interchange, or hardcopy format, no implemented scale command, and an ignored Swap Layouts experiment guarded out because only one layout exists. State exists only in memory.

This is not an electrical simulator or production CAD tool; do not use it for a real circuit. Dependencies are CLIM Demo, formatted/output records, presentations, and pointer tracking. Screenshot/runtime TODO: capture the Setup circuit plus a selected component and equation only in a disposable CLIM world; currently blocked by absent CLIM.

color-chooser

color-chooser is a linked RGB/IHS color-selection dialog. The frame has no menu bar: a color swatch, six vertical sliders, and an Exit push button are the entire direct surface.

Both drag and value-changed callbacks synchronize the two coordinate systems continuously. A dynamic palette uses a mutable dynamic color; other displays are repainted. There is no color-library file, persistence, textual import, or named color management. The User's Guide describes the linked sliders and swatch; the dynamic-color branch and precise ranges come from source.

Dependencies are CLIM Demo, physical slider gadgets, color conversion, and a color-capable or stipple-fallback port. Safety impact is confined to volatile frame and palette state. Screenshot/runtime TODO: capture the swatch and both linked slider groups after CLIM loading is restored; currently blocked.

demo-app

The chooser calls demo-app “Activity Demo.” It is a demonstration of CLIM's activity-frame substrate rather than a domain application. Each frame divides its space between an interactor and an otherwise blank display pane, and can create or select peer activity frames.

The untitled counter is shared; results and frames are volatile. No document or interchange format exists. The installed demo chapter does not describe this program, so its purpose, two-pane layout, random range, and translator are source-only findings. Source attribution includes portions credited to Franz.

Dependencies are CLIM Demo, activity-frame, presentations, and a random-number generator. Screenshot/runtime TODO: capture two named peer frames and the number translator when CLIM is available; currently blocked by the unloaded system.

flight-planner

flight-planner is a presentation-rich aviation teaching demo over a built-in, historical New England data set. Its large map pane occupies roughly three quarters of the frame and an interactor occupies the rest. It is not an airworthy planner: the navigation rows are fixed historical demo data, are not current or authoritative, and must never be used for real navigation.

The data model has ground positions, routes, Victor airways, aircraft, flight plans, winds, and navigation-log rows. The source contains 164 literal navigation rows, then filters them to latitude 41–44 and longitude 70–74 for the visible region. It also builds coastlines and sample aircraft. A navigation row encodes an identifier, short name, kind, frequency, long name, latitude degrees/minutes, longitude degrees/minutes, and variation/elevation fields. This is an internal Lisp table, not a supported import file.

Add Ground Position accepts name, long name, kind (airport, VOR, named-intersection, or visual checkpoint), latitude, longitude, and altitude 0–60,000. Add Route and Add Victor Airway accept a starting airport/intersection/VOR and then waypoints until NIL; an airway also has a name. Add Aircraft accepts identifier, type, preferred altitude, cruise speed, fuel consumption, maximum fuel, and hourly cost.

The flight-plan dialog accepts VFR, IFR, or DVFR; aircraft; equipment; true airspeed; departure time; altitude; remarks; fuel; alternate; pilot contact; 1–500 people aboard; and aircraft color. Time is entered in an hour/minute form; wind uses direction and speed. The computed result is an in-memory navigation log and analysis, not a filed plan and not a durable document.

The manual highlights presentation-type inheritance, custom highlighting, dialogs, and table formatting. Source inspection adds several non-manual limits: wind defaults to zero, rows outside the fixed bounds silently disappear, a comment flags the inverse coordinate calculation's Y value, and the aircraft editor accepts a new hourly cost but fails to assign it before restoring the old value. That last item is a source-visible edit bug pending runtime confirmation.

Dependencies are CLIM Demo, navdata, trigonometric/numeric code, presentations, tables, dialogs, and Genera display services. No filesystem operation is defined. Screenshot/runtime TODO: after CLIM can be loaded, capture the bounded map and a synthetic route/log with a conspicuous “historical demo—do not navigate” caption; currently blocked.

graphics-demo

graphics-demo is a menu of self-running CLIM drawing examples. It has an 800-by-600 demonstration pane and a short explanation pane.

While the demo's timed-wait routine is active, an ordinary character ends the current wait and a pointer event exits the whole frame. These are the only application-defined direct gestures; the seven commands have no declared accelerator keys. The examples exercise transformations, inks, lines, polygons, circles, random generation, and timed redisplay. They load no assets and save no data. The manual states the color/stipple fallback and transformation purpose; the exact animations and early-exit behavior are source findings. Portions are credited to International Lisp Associates.

Dependencies are CLIM Demo, CLIM drawing and affine transformations, colors or stipple fallback, random-number generation, and timed gesture input. Safety impact is limited to volatile drawing, short waits, and operator-triggered frame exit; the demos perform no file I/O.

Screenshot/runtime TODO: capture one transformation example and the solved maze, as two distinct visible claims, after CLIM can run; the present world has no CLIM.

graphics-editor

graphics-editor is the User's Guide's “Boxes-and-Wires Editor.” It demonstrates selection, pointer tracking, handles, command-table grouping, and incremental redisplay. A scrollable canvas and modeless options pane can be arranged in horizontal or vertical layouts.

New boxes are numbered monotonically and automatically arrow-connected from the previous box, so the demo is not a general free-wiring editor despite its manual name. Source comments call the private reusable object substrate “Zdrava”; it is not a CLIM product facility. The File menu contains no Open, Save, Import, or Export command, and there is no document format. Deleting a box cascades to its arrows.

The manual describes boxes, tracking wires, selection, redisplay ticks, bounding rectangles, command-table groups, and graphical option presentations. Automatic chain wiring, click-without-drag behavior, and the lack of persistence are source findings. Dependencies are CLIM Demo, presentations, pointer tracking, incremental redisplay, and the private demo object substrate. Safety impact is confined to volatile scene state. Screenshot/runtime TODO: capture creation, selection handles, and tracked arrows in a disposable loaded world; currently blocked.

ico-frame

ico-frame, registered as “Ico Demo,” animates a bouncing, rotating icosahedron. Its source credits Xerox, portions to Franz, and says the algorithm was taken from the traditional X11 ico demo and improved. This is explicit lineage, unlike similarity-based attribution.

The geometry has twelve vertices and twenty faces. The object is approximately 150 by 150 pixels, starts with velocity 13 by 9, rotates five degrees around both X and Y per frame, performs hidden-face selection, and bounces at the pane boundary. Repaint can start the animation automatically. The worker and dynamic palette layers are released on Catch/Quit, but an abnormal failure could still leave a process or colors until cleanup.

No model file or animation export exists. Dependencies are CLIM Demo, process support, transformations, dynamic colors, and optional multi-buffering. The safety concern is the background worker and temporary palette allocation: normal Catch/Quit cleans both up, while an abnormal failure may require disposable-world cleanup. Screenshot/runtime TODO: capture both face-and-edge rendering and the options pane after CLIM loading; a static image cannot prove motion, so the caption must state what was source-established versus observed.

lisp-listener

lisp-listener is a CLIM command-or-form REPL with one scrollable interactor and no menu bar. It accepts Lisp forms or CLIM commands, presents returned values as reusable objects, maintains the Common Lisp *, **, ***, /, //, ///, +, ++, +++, and - histories, and supplies a nested in-pane restart UI unless native debugging is selected. On Genera, End is an additional activation gesture.

Select on an output expression supplies the underlying value when it matches the current input context; Describe constructs a form to describe the object; Super-Middle constructs a description of the presentation record itself. The source defines a Genera Select key, but its encoded character cannot be decoded with high confidence from the extracted file; the public manual identifies the standalone activity as Select Lambda. This manual/source correspondence should be verified at runtime before treating the extraction as exact keyboard evidence.

The User's Guide notes the custom top level, patterned prompt, translators, scrollable history, and that *debug-io* is not normally rebound to this window. Source inspection reveals the complete command inventory and the two convincing stubs. The listener is security-sensitive: arbitrary typed forms are evaluated; Use/Store Value can evaluate forms; compile/load execute code; edit, output-history copy, delete, and expunge mutate guest files. Run only trusted forms and pathnames inside a disposable world.

Dependencies are CLIM Demo, the Common Lisp evaluator/compiler, Genera filesystem and editor integration, conditions/restarts, and the shared CLIM input editor. Screenshot/runtime TODO: capture a harmless multiple-value evaluation and a nested synthetic error after CLIM becomes loadable; the generic Dynamic Lisp Listener is not a substitute.

peek-frame

peek-frame, registered as “Peek,” is a small process-status and process-control demo. It incrementally redraws a table of Process, State, and Activity, with the time and current refresh condition above it. The default interval is one second.

The User's Guide only calls it a small process-status program demonstrating incremental redisplay. Source inspection changes the Genera interpretation of two options: the GC branch prints that statistics are unknown on this port, and OS-process enumeration exists only for Lucid and Allegro, so enabling Show OS Processes on Genera adds no OS rows. A source comment mentions an Update command, but no such command is defined; Redisplay is the actual control.

Process actions are live and destructive. Exercise Activate, Deactivate, Destroy, or Restart only in an isolated disposable world and never against a needed service. There is no data file or export format. Dependencies are CLIM Demo and clim-sys process introspection/control. Screenshot/runtime TODO: capture the table and Options dialog only after CLIM can be loaded; destructive commands should be verified on a synthetic expendable process.

plot-demo

plot-demo, registered as “Plotting Demo,” combines a graph pane, modeless options pane, editable data table, and interactor. Its initial five-by-four array has an X column of years and three city series. The same data can be shown as a line plot, bar graph, or pie chart.

Print Graph exists only in the Allegro conditional branch; it is not a Genera command. Likewise, only Edit X Label, Edit Y Label, Edit Data Point, and Quit are menu items on Genera; the remaining named commands are entered through the command processor or presentation gestures.

The save format is exactly three Common Lisp printed objects in order: the X-label list, Y-label list, and plot-data array. There is no required extension, schema tag, version, or validation. Loading untrusted files is unsafe because it uses the Lisp reader and then assumes compatible objects and dimensions. Saving supersedes the selected file after confirmation.

The manual highlights pointer tracking, formatted output, a modeless dialog, and drag scrolling. Source adds the exact format and a suspicious method signature: the X/Y-label presentation methods use a typep-shaped parameter where sibling methods use a type parameter. Because a compiled VBin exists but the app was not run, this is recorded as a source anomaly, not a proven runtime failure.

Dependencies are CLIM Demo, graph/table formatting, accepting-values, presentations, filesystem streams for save/load, and the Lisp reader/printer. Screenshot/runtime TODO: capture all three graph types and a table edit after CLIM loading; currently blocked.

puzzle

puzzle, registered as “15 Puzzle,” is the polished Demo-system version of the 4-by-4 sliding puzzle. Fifteen numbered cells and one gap are presented in a large fixed text display with incremental redisplay.

The move translator uses a tester to expose only legal row/column cells, and a custom highlighter outlines a candidate. The scramble routine repairs parity rather than accepting an arbitrary unsolvable permutation. State is volatile; there is no puzzle file, undo, move counter, or saved game.

The manual identifies direct manipulation, table formatting, and incremental redisplay, while the exact multi-cell rule, solvability repair, keyboard exit, and no-persistence boundary come from source. Dependencies are CLIM Demo, presentations, formatted tables, and incremental redisplay. Screenshot/runtime TODO: capture a scrambled board with one legal highlighted move after CLIM can be loaded; currently blocked.

scigraph

scigraph, registered as “Custom Output Records,” is a performance demonstration for output-record design, not a general scientific plotting package. A caption pane occupies the upper fifth and a vertically scrollable display accumulates examples until cleared.

Each run displays elapsed time. The data are generated in memory and are neither loaded nor saved. Points remain presentations, but this frame defines no command translator for them. The manual reports that its third representation was about three times faster than the first for this application; that is a contemporary manual result, not a measurement reproduced by this audit.

Dependencies are CLIM Demo, custom output-record protocols, presentations, timing, and random-number generation. Safety impact is limited to volatile point generation, allocation, and timing. Screenshot/runtime TODO: capture all three labeled results in one controlled run and record their measured times only after CLIM can be loaded; currently blocked.

thinkadot

thinkadot simulates the mechanical Think-a-Dot finite-state toy. Eight binary diverter nodes form a fixed network beneath three entry chutes, with left and right exit indicators. Light and dark dots encode each diverter's current state.

The path is computed and the state display changes; the source does not animate a visible marble travelling through each edge. The state is volatile and has no file format. The manual identifies the mechanical toy; the eight-node model, instantaneous update, and exact reset semantics are source findings.

Dependencies are CLIM Demo, presentations, and incremental redisplay. Screenshot/runtime TODO: capture the initial state and one post-drop state after CLIM loading, explicitly avoiding a claim of path animation; currently blocked.

fifteen-puzzle-1

fifteen-puzzle-1 is the tutorial's deliberately elementary first frame. A fixed-width, very-large text pane shows the solved 4-by-4 grid, and a command-menu pane supplies four buttons. The frame has no ordinary menu bar.

Each command swaps one adjacent tile; there are no presentations, pointer moves, Reset, Scramble, or Exit command. Closing the application therefore depends on the surrounding frame/window facility. The stage teaches the minimum application frame: state slots, commands, application and command-menu panes, layout, and a display function. State is an in-memory 4-by-4 array and always starts solved.

The tutorial manual presents this as the elementary application before adding semantic output. Source confirms the exact button semantics and the conspicuous lack of an exit path. Dependencies are CLIM Tutorial, application-frame panes, a command-menu pane, and ordinary table/text output. Safety impact is confined to volatile puzzle state. Screenshot/runtime TODO: capture the solved board and four-button command pane after CLIM Tutorial can be loaded; currently blocked by absent CLIM.

fifteen-puzzle-2

fifteen-puzzle-2 replaces four directional buttons with presentation-based direct manipulation. Each numbered cell is presented as a puzzle-piece carrying its encoded position.

The Move command takes integer row and column arguments; the presentation translator supplies them from the selected cell. This stage has no translator tester, so even a geometrically illegal cell can be selected and dispatched; the move routine then finds no path and leaves the board unchanged. The frame relies on ordinary post-command display rather than targeted redraw. There is no scramble or persistence.

The tutorial uses this version to introduce presentations, translators, and clean frame exit. Dependencies are CLIM Tutorial, presentations, a translator, and formatted table output; safety impact is confined to volatile puzzle state. Screenshot/runtime TODO: capture a legal sensitive tile and a multi-cell slide when the tutorial system is runnable; currently blocked.

fifteen-puzzle-3

fifteen-puzzle-3 keeps the second stage's Move, Reset, Exit, and Select interaction, but disables the normal display-after-every-command path. It stores the output record for each cell and manually erases, replaces, and reinstalls the records touched by a move.

This is “incremental redisplay the hard way”: explicit presentation/output-record bookkeeping is the teaching subject, not a user-visible feature. The frame adds record storage, fixed character width and line height, and a reset path that clears the pane and reconstructs every record. It still has no translator tester, scramble, undo, saved game, or file format.

The direct controls are exactly Select a piece, Reset, and Exit, with the same legal-move semantics as stage 2. Dependencies are CLIM Tutorial, presentations, and direct output-record erasure/replacement; safety impact is confined to volatile puzzle and display-record state. Screenshot/runtime TODO: one final board image cannot prove the manual record operations; after CLIM loads, capture before/after screens and retain timing/record inspection as local evidence. Currently blocked.

fifteen-puzzle-4

fifteen-puzzle-4 removes stage 3's explicit record table and expresses each cell with updating-output. CLIM's incremental redisplay compares the cell's cached value under a stable position identifier and updates changed cells.

User-visible behavior remains Select a piece, Reset, and Exit; a legal same-row/column selection slides all intervening tiles, and an illegal selection does nothing. There is still no translator tester, so pointer sensitivity does not yet communicate legality before dispatch. No state is persisted.

The tutorial's point is architectural: stage 3 and stage 4 should look the same, but stage 4 delegates record reconciliation to CLIM. Dependencies are CLIM Tutorial, presentations, updating-output, and incremental redisplay; safety impact is confined to volatile puzzle and output-record state. Screenshot/runtime TODO: capture the board plus an output-record inspection or controlled redraw trace after loading CLIM, because pixels alone cannot establish the implementation difference. Currently blocked.

fifteen-puzzle-5

fifteen-puzzle-5 is the completed tutorial progression. It keeps stage 4's updating-output structure and adds a translator tester that calls the same move-path calculation used by the command. Only pieces sharing the gap's row or column are now sensitive. It also defines an input reader for puzzle pieces.

The complete direct surface remains Select a legal piece, Reset, and Exit; there are no keys, scramble, undo, score, save, or load commands. The progression across all five frames is therefore:

This exact progression is established jointly by the tutorial manual and the five source files. Stage 5 depends on CLIM Tutorial, presentations, updating-output, incremental redisplay, a translator tester, and presentation input; safety impact is confined to volatile puzzle state. Screenshot/runtime TODO: capture pointer sensitivity over one legal and one illegal cell once CLIM is runnable; currently blocked.

lsq

lsq is a least-squares plotting tutorial supplied in two successive source stages. Both files define the same frame, presentation types, and many of the same functions; loading the second after the first replaces definitions. Treat them as two versions of one lesson, not as simultaneously selectable frames.

Both stages have a drawing layout and a tabular layout, default axes from 0.0 to 1.0, no initial points, incremental graph/equation display, and polynomial least-squares fitting by a general linear-regression routine using Cholesky factorization. The curve menu offers Linear, Quadratic, and Cubic; a fit requires enough points, then displays an equation and correlation. Points, fits, and axis settings are volatile; neither stage reads or writes a data file.

Tic-Tac-Toe

Tic-Tac-Toe is the tutorial's 3-by-3 graphical game. The board pane occupies nine tenths of the frame and a status pane the remainder. X and O are graphical presentations under a board-position type hierarchy, and both panes use incremental redisplay.

Starting play from an edited nonterminal board counts X and O marks to determine whose turn it is. Starting from a terminal position first clears the board. If the program is X, it makes the initial move before returning input.

The source-level move priority is: take an immediate win; block an immediate loss; create a fork; block one fork or force play when there are multiple fork points; take the center; otherwise take the first available corner. When the AI has several accumulated candidate points, selection among them is random. This is a compact tactical player, not a general game-search engine. There is no final edge-square fallback after the center and corners; an unusual edited position could therefore leave the move routine without coordinates, a source-visible risk that needs runtime confirmation. There is no network play, score history, undo, saved board, or file format.

The tutorial uses the program to teach presentation-type inheritance, command enablement, and graphics transformations. Source adds the editable-start-position semantics and exact tactical policy. Dependencies are CLIM Tutorial, presentations, transformations, command enablement, incremental redisplay, and random selection among equivalent moves. Safety impact is confined to volatile game state. Screenshot/runtime TODO: capture editing, active play, and a terminal status after CLIM Tutorial can run; currently blocked.

clim-tests

clim-tests is an interactive conformance, regression, visual-inspection, and benchmark workbench. It is not an automated pass/fail harness. A small caption pane explains the selected test and a scrollable display pane shows the result or accepts follow-up input. On Genera it registers Select Circle.

The top command bar is Graphics, Redisplay, Benchmarks, Output Recording, Formatted Output, Presentations, Menus and Dialogs, and Exit. Selecting a displayed form presentation evaluates it. Many tests deliberately sleep, refresh, open menus/dialogs, or wait for input, so “test completed” does not imply correctness; the researcher judges the visible result against the caption.

Cross-program manual and source findings

The public User's Guide describes fifteen Demo programs. The source registry adds Activity Demo and a conditional Test Suite entry, neither of which receives a program section in that manual chapter. Conversely, the Test Suite entry is only a launcher probe; without separately loading its body, choosing it has no visible effect. This makes the source registry, not the prose chapter, the authoritative menu census.

The guide tells readers to load CLIM-DEMOS, while the inspected system declaration defines and imports clim-demo with pretty name CLIM Demo. No alias named CLIM-DEMOS was found in the inspected declaration. The plural spelling is retained as a manual/source discrepancy rather than silently “corrected” into evidence of an additional system.

The programs also expose a useful spectrum of CLIM architecture:

This range is historically important: the examples teach typed semantic interaction and retained output structure rather than a widget/callback-only model. It does not make each example a finished product. In particular, the User's Guide itself calls the new demos instructional and not product quality.

Runtime record and screenshot decision

The runtime evidence is reused from the fresh CLIM core audit because it asks the exact prerequisite question for every frame on this page. Rebooting the same unchanged base world would not make an absent package or system present.

The final system scan searched all registered system names for CLIM, rather than only a hand-picked six-name list. The package and feature check independently corroborates absence: the CLIM declaration would create the package and push CLIM features when loaded. The optional source media exists on the host, but the sandbox deliberately exposes no guest file service. No Load System CLIM attempt was made, because it could only test missing site/media configuration or widen the isolation boundary; it could not safely reach these frames in the current setup.

Two raw Listener captures record those negative results. They remain ignored and unpublished: 0010-clim-system-status-runtime.png is 11,748 bytes, PNG SHA-256 50cfae39733ca7815ca0dd150aa1d659987ada8a2961f593610fe43dcab97b0c, normalized pixel SHA-256 82dca042cd4c94cc0560999ff96836a0aa6c571898387a68c73e6d6f6ef0d6e1; 0011-clim-package-feature-status.png is 11,852 bytes, PNG SHA-256 cc64888a59e7850ae526ca08cc17ba050d4d8832eb1b9df8d2a9a724e5abbccc, normalized pixel SHA-256 8de9dc9ccbb2da887f29f57cdeb265aac1a2517f29942d9efa6a3b85af4056bc. Neither depicts a D59 program, so neither meets the museum's evidentiary usefulness threshold. There is no publishable application screenshot to review under the screenshot publication policy.

Artifact identities

All paths in these tables are portable paths below the licensed sys.sct/clim/rel-2/ media root. They disclose no machine-specific location and no source contents.

Preservation and future verification

• Keep every licensed source, VBin, SAB, decoded Help file, restored world, and raw harness capture untracked. This page contains evidence metadata and original analysis only.
• Restore CLIM and Genera-CLIM into a fresh private world through a deliberately configured, read-only guest media service. Load CLIM Demo, CLIM Tutorial, and the test suite separately; do not save over the base world.
• Verify each source anomaly independently: bitmap current-color behavior; CAD feedback failure; browser package-subnode title; Flight Planner cost edit and coordinate warning; Plot label methods; LSQ slot/zoom/visibility defects; Peek's absent Genera GC/OS data; and Test Suite conditional counts.
• Use only synthetic address, filesystem, package, process, graph, navigation, and benchmark data. Never operate Flight Planner as an aviation tool or Peek against an important process.
• Curate the minimum screenshots needed for substantive claims. Keep raw sequences local; review every selected image under the four-factor policy; exclude Help prose, third-party artwork, and decorative galleries.
• Do not use modern McCLIM, Allegro CLIM, or LispWorks CLIM output as a proxy for this Genera port. They can help explain portable architecture, but only the licensed Genera runtime can verify these exact frames.

Sources

• Symbolics, Common Lisp Interface Manager (CLIM), Release 2.0, especially the Fifteen Puzzle, Tic-Tac-Toe, and Least Squares tutorial chapters; “Using the CLIM Demos”; and the application-frame, presentations, output-record, redisplay, formatted-output, gadget, and command chapters.
• Symbolics, CLIM 2.0 Release Notes and Installation Guide, for release-local loading, compatibility, and port context.
• Licensed Open Genera 2.0 / Genera 8.5 SYS:CLIM;REL-2;DEMO;, TUTORIAL;, and TEST; declarations, source, compiled inventory, patch metadata, and recovered installed Help identified above; inspected 2026-07-18.
• CLIM 2 on Symbolics Genera, for the portable/native layer boundary, full common input-editor bindings, optional-system census, and the same isolated runtime prerequisite probe.

Last verified: 2026-07-18.