Inspector and Peek in Symbolics Genera

What it is and how it is entered

Inspector is a standalone activity and also a callable subprogram. The difference matters because a call can temporarily take over the invoking Listener, whereas the activity has its own process and can simply be selected away from.

The top-level inspect function rejects a remote terminal and reports that the facility is available only from the main console. That restriction is in the implementation, not merely a recommendation in the manual.

Frame and data-flow architecture

The default frame contains six visible panes:

1. a three-line interaction pane;
2. a history pane and command menu arranged side by side;
3. three vertically arranged inspection panes, the last of which owns the Inspector typeout window.

The number of inspection panes is an initialization option; three is the default, not a structural limit. All panes share an input buffer. The interaction pane reads and evaluates a form, then appends the resulting object to history instead of printing it. The last history objects populate the inspection panes, with the newest in the large bottom pane. Each inspection pane remembers its own scroll position. Top and bottom margin regions and a scroll bar provide object-local navigation.

History is more than a transcript. It stores object identity and a cached display description. Before an object is appended, an EQ-identical occurrence is removed; the same object therefore does not accumulate duplicate history rows. The cache enables quick redisplay but can become deliberately stale when an object changes outside Inspector. DeCache, deleting the history row, or a successful modification invalidates the relevant cached material.

Inspector-specific keyboard controls

Ordinary form editing is supplied by the system Input Editor. The table below is the complete set of special top-level Inspector characters configured in the inspected file, plus the activity selector. Input Editor movement, correction, history, and completion keys are inherited facilities rather than additional Inspector bindings.

Menu pane

The general menu definition has seven entries. The Common Lisp and Zetalisp versions differ only in the history symbol named by Set.

The source contains a wrapper intended to remove Return from the always-running own-process activity, because no useful caller is waiting for a returned value. The fresh runtime contradicted that intent: the frame was named Inspect Frame With Own Process 1, yet its visible menu included Return. This might reflect compiled-world/source-revision skew or a wrapper not taking effect. It is left as an observed disagreement, not silently corrected to match either source or manual.

Mouse navigation

Inspector turns displayed component fields into sensitive items.

The fresh list probe changed the mouse documentation from the generic value message to the list-specific CAR operation while the pointer was over list structure. The attempted click did not visibly add another history object, so that run confirms contextual sensitivity but is not used as proof of a successful follow operation. The follow semantics above are established by source and manual.

Object displays and mutation semantics

The local type dispatch has eleven principal cases. A component is only exposed in Modify mode when its presentation type has a registered setter.

The public manual also describes a Select Method display whose keyword/function pairs are editable. In this source revision, that implementation is guarded for CADR builds and is absent from the Ivory/Open Genera type dispatch. It is therefore historical/manual evidence, not asserted as active Open Genera 8.5 behavior.

Modify is consequently much stronger than a form-field editor. It can alter global function bindings, property lists, object dispatch, live list topology, array leaders, closed-over state, and executable-code constants. Some operations use an abstraction-preserving setter message; others deliberately write the representation. The source itself questions the safety of replacing a flavor message handler. A museum demonstration should use newly allocated probe objects and avoid modifying system objects unless the mutation itself is the subject of the experiment.

Inspector findings the manuals do not fully expose

• Type redirection is intentionally under-annotated. A malformed object handler can substitute another object or force another display type without telling the user that redirection happened; an unknown type has no graceful fallback.
• Function-following is a normalization loop, not merely “look up a symbol's function.” It peels symbols, closures, lexical closures, and valid function-definition lists until no further canonical function is found.
• Source display is conditional on both correspondence information and a Lisp language model. The menu toggles a global preference, but missing source or a non-Lisp function still produces disassembly.
• The source-aware compiled stack-frame path can mark the range associated with the current program counter. The disassembly path can instead mark the instruction index.
• Cache staleness is part of the design. Reinspection is not a guarantee of a fresh read until the cache is invalidated.
• The standalone command's apparent object argument is implemented as a symbol name string lookup, whereas the frame interaction loop evaluates arbitrary forms. The two input paths are not equivalent.
• The own-process Return suppression in source and the visible 8.5 menu do not agree, as recorded above.

Architecture and lifecycle

Peek is an initially invisible, process-owning frame with two panes sharing one input buffer: a one-row dynamic mode menu and a scrolling status pane. The mode menu highlights exactly one item and sends the selected registry entry to the status process. The source deliberately leaves precreation disabled to avoid increasing world size.

On frame start the top level selects Help. The Lisp function zl:peek defaults its optional argument to P and force-types that mode character, while selecting the activity with Select P creates the frame without that function call. The fresh activity therefore opened on Help, matching the top-level source path.

The normal loop:

• waits for input, a redisplay request, or the next update time;
• uses interactive priority when input is pending and noninteractive priority for unattended refresh work;
• stops refreshing while the frame is deexposed and wakes immediately when it becomes visible again;
• notices changes to the dynamic mode registry and reconstructs the frame menu;
• preserves scroll-display objects so changing numeric fields can be refreshed rather than rendering an unrelated text report each cycle;
• waits for a user character before flushing incomplete typeout, preventing a background refresh from erasing diagnostic output.

The default refresh interval is twenty seconds. Genera 8.0 release notes explicitly corrected older documentation that had said two seconds; the local source constant and runtime Help both say twenty.

Complete configured keyboard controls

This table covers every character handled by Peek's top loop in the inspected base source plus the dynamically registered Chaosnet mode.

Hostat has a subsidiary loop after a host-status pass: Space requests another pass and any other character is pushed back so Peek can resume normal handling. That subsidiary loop is reached only if the underlying Chaosnet hostat call returns. The manual's Control-Abort instruction belongs to that underlying operation.

Modes in the inspected source and world

The base file registers seven status modes, Help, and the special Quit menu row. peekch appends Hostat through the same public registry function. The live 8.5 menu therefore contained ten items in this order: Processes, Areas, Meters, File System, Windows, Servers, Network, Help, Quit, Hostat.

The manual's generic Meter description includes Netboot. The local source guards that meter group with #-IMACH; the Open Genera/Ivory runtime showed only the four groups listed above. This is a platform-conditional difference, not missing runtime evidence.

Complete configured object menus

The table is the menu denominator found in the inspected source tree. Network classes can extend the host and server-connection menus; the only such extension found for this baseline is the Chaosnet set listed here. An optional package loaded into another world could add more methods without editing Peek itself.

Several sensitive rows act without opening a menu: area and meter headings toggle detail; Chaosnet connection headings toggle connection lists, meters, routes, and packet queues; a Chaosnet connection-state item can request a forced close. A network-interface overseer delegates to the process menu. Peek should therefore not be described as read-only even when the user never enters Inspector.

Peek findings the manuals do not fully expose

• The mode menu is a runtime registry. Hostat is not hard-coded in the base frame layout; loading the Chaosnet module appends it, and an already existing Peek frame notices the changed list and reconfigures itself.
• Help is generated from that registry, so it can enumerate a mode supplied by another module. It documents Z and Space but omits the six scrolling bindings that the same top loop handles.
• Quit is represented as a mode entry but is not a display mode. The selection path buries the frame and restores the previous highlight; the defined Quit display function is intentionally never called.
• The four base meter groups form another extension registry. Netboot is compiled out on IMACH, explaining its absence from the observed Open Genera menu without treating the manual as universally wrong.
• Processes can switch between compact utilization and a more detailed real/CPU/paging layout through a process subsystem variable. Static screenshots from different worlds can therefore show different columns without implying a different Peek version.
• Current timers and old timer-queue entries come from two different scheduler facilities. Only old queue entries receive Peek's five-operation timer menu.
• Typeout is intentionally modal with respect to refresh: Peek waits for a user character before replacing incomplete diagnostic output.
• Hostat does not implement the scroll-maintained function contract used by the normal modes. It performs a potentially blocking network operation inside Peek's own top-level process. The runtime consequence is recorded below.
• The File System menu's Delete operation leaves the stream open, a sharper operation than the broad manual phrase “close streams” suggests.
• Hidden-detail lists carry mutable redisplay state in scroll-item leaders and compare some canonicalized objects by identity. These are active display structures, not a freshly printed report on every update.

Session boundary

The isolated session was named core-dossiers-20260718, generation 1, and ran from 2026-07-18 03:59:21 to 04:08:08 EDT. Its reproducibility boundary was:

The VLM ran in separate user, mount, network, PID, IPC, and hostname namespaces. Bubblewrap exposed the read-only Guix store, exact read-only helpers and private X socket, generated minimal host lookup files, and the writable private runtime. It did not expose the host root, home, repository, unrelated runtime sockets, or session metadata. The isolated tun0 had no default or external route and no guest-visible host file service. This is native-process reach reduction, not a claim of a complete kernel security boundary.

Xvfb did not advertise MIT-SHM. Both pinned guest-X request substitutions were observed before the harness declared the session running. The one-shot RFC 868 responder received the expected local Ethernet request, sent one validated reply, and exited successfully.

Inspector observation

Host F1 was the harness translation used for the Genera Select key; this is not a Symbolics-keyboard layout claim. Select I opened a blank own-process Inspector with the interaction line, history, menu, and three empty object panes. The menu visibly read Exit, Return, Modify, DeCache, Clear, Set //, and Source, establishing the source/runtime Return disagreement discussed above.

Entering the project-owned probe form '(alpha (beta . gamma) #(1 2 3)) evaluated it and placed the result in history and in the bottom pane labelled a list; the two upper object panes remained empty. A pointer action over the displayed list changed the bottom documentation to the list-specific CAR wording. No system object was modified, and the Modify, Set, and Source operations were deliberately not exercised.

Peek observation

Select P opened Help with the ten-item row described above. Subsequent keys reached Processes, Areas, Meters, File System, Windows, Servers, and Network. Specific visible cross-checks were:

• Processes showed process, state, priority, idle-time, and utilization columns, followed by timer headings. A right click on Peek Frame 1 opened the exact eight-item process menu from source. No operation was chosen.
• Areas showed the memory/region header and live areas. A pointer action on an area inserted a region-detail row, confirming expandable hidden data.
• Meters showed exactly Storage, GC, Disk, and ZWEI Sectionization groups, with no Netboot group.
• File System was empty, consistent with the session's lack of a guest-visible host file service; this does not prove that the mode is normally empty.
• Windows displayed the active screen hierarchy, including Peek, the Inspector and its panes, and the Dynamic Lisp Listener.
• Servers displayed its headings but no active servers in this isolated run.
• Network displayed the local Internet network, counters, and the VLM Ethernet interface on isolated tun0. The screen is evidence about the harness network, not a configured Symbolics site.

Pressing H selected the dynamically registered Hostat row. The status pane entered Chaosnet host-status typeout and the process state became Await Chaosnet enabled, because this session had an Internet interface but no enabled Chaosnet. While that call remained blocked, dispatched P, 5 Z, and Space inputs did not replace the Hostat body. Clicking the Processes menu row changed its highlight and the mouse-documentation line, but the body and process state still showed blocked Hostat. Thus the menu pane handles highlighting before Peek's top-level process consumes the queued menu event.

Two host-side attempts to synthesize the expected Control-Abort combination did not unblock this run. That result is specific to this X translation and a Hostat call already waiting for Chaosnet; it does not establish that Control-Abort fails on Symbolics hardware. Select L subsequently selected the Listener, allowing the session to continue without claiming that Hostat itself returned.

The complete action log contains 33 intents and 33 linked successful dispatch outcomes. “Successful” here means XTEST delivery succeeded, not that the guest performed the intended semantic operation; the blocked Hostat probes illustrate the distinction.

The application-specific intent sequence, in order, was: host F1, then i (Select I); type the probe form and Return; Left at client coordinates (120,492); host F1, then p (Select P); p; Right at (110,59) to expose the process menu; Abort; a; Right at (1100,800) on an area row; m, f, w, s, n, and h; p, 5, z, and Space while Hostat was blocked; two Control/Abort translation probes around another p; Left at (55,9) on the Processes menu row; and finally host F1, then l (Select L). Every intent was recorded before dispatch and linked to its outcome afterward.

Raw capture evidence

All entries below are ignored local evidence identifiers, not links or publishable assets. Each is 1200x900. The action-prefix count and hash bind a capture to the ordered intents and outcomes that preceded it.

Capture names record the researcher's intended state, not an automatic semantic verdict. In particular, the 0020 image is evidence that the intended mode and interval actions had not taken visible effect.

The final 25,569-byte run record has SHA-256 03f497f39e3afc2d34916f6ab817a6664cde14a32224031bf52f90443ea94810. The 31,489-byte, 66-record action log has SHA-256 02df861d873714eb7f75e4fe450d65ec4c965cc407717f0725e1e49e34bb3565.

Shutdown and persistence

The shutdown prompt was observed, yes was sent and accepted, and cleanup progress appeared. The current VLM then reached the previously established cold-load mutex stall and required bounded host termination. The final status is forced-stopped, with forced_stop=true, forced_after_confirmed_shutdown_stall=true, state_may_be_incomplete=true, and orderly_vlm_host_shutdown=false.

The harness did not invoke Save World and did not create a host-process checkpoint. save_world_performed and guest_checkpoint_created remain unknown. The private world was byte-identical to the base at start and stop; that establishes no world-file change, not a general claim that every guest subsystem lacked other persistence. The run record marks the session's possible unsaved Lisp state as discarded. The process boundary and shutdown model are described in Operating Genera through the Xvfb computer-use harness.