Skip to content

docs(server/scene): mark ExternalPosition2D as an unimplemented stub - #86

Merged
joschaschmiedt merged 1 commit into
mainfrom
chore/external-position-2d-todo
Jul 10, 2026
Merged

docs(server/scene): mark ExternalPosition2D as an unimplemented stub#86
joschaschmiedt merged 1 commit into
mainfrom
chore/external-position-2d-todo

Conversation

@joschaschmiedt

Copy link
Copy Markdown
Contributor

Marks the ExternalPosition2D animation as an unimplemented stub at every site that currently claims it reads shared memory. No behaviour change.

Why

The server accepts an ExternalPosition2D animation, returns a valid handle, reports Running from QueryAnimation, and round-trips it through config save/load. The stimulus never moves. The entire implementation is animation_advance.rs:

// External position is driven by an external process; never self-terminates.
Animation::ExternalPosition2D { .. } => false,

No shm_open, no mmap, no move_to. The comment describes an intent, not a behaviour.

Everything around the read exists, which is what makes it hard to notice — the enum variant, the proto message, the command.rs create/query wiring and the Python client method all ship today. Three of them promise a per-frame shm read in their doc comments. A client author reading animations.proto or the Python docstring has no way to discover the command does nothing; they get a success response and a motionless stimulus, with nothing in the log.

So this marks all four sites rather than only the Rust arm:

  • server/src/scene/animation/animation_advance.rs — the stub match arm
  • server/src/scene/animation/animation_kind.rs"Read 2-D position from a POSIX shm float array each frame."
  • proto/vstimd/v1/animations.proto — the same claim on the wire type
  • client/python/vstimd/animations/animations_client.py — the Python docstring, as a Sphinx .. warning::

Scope

Documentation only. Deciding whether to reject at create time with UNIMPLEMENTED or implement the read is #84; that issue argues for rejecting if #79 is close and implementing if it is not, but rules out leaving it accepting-and-ignoring.

Not folded into #79 because that issue implements this arm as one part of a feature depending on the vinput crate (#77) and the device registry (#78), inside epic #81. The defect — a shipped command that silently does nothing — stands independently of whether that epic lands.

Verification

  • cargo clippy clean (the one warning, module_inception in scene/stimulus/mod.rs, is pre-existing)
  • make typecheck passes
  • No generated *_pb2.* files staged

Refs #84, #79, #83

🤖 Generated with Claude Code

https://claude.ai/code/session_01TovGgCFRVaGjUhKHLVKgUF

The server accepts an ExternalPosition2D animation, returns a valid handle
and reports Running, but `animation_advance` never opens the shm segment and
the stimulus never moves. Four sites independently document a per-frame shm
read that does not exist:

  - animation_advance.rs — the stub match arm
  - animation_kind.rs    — "Read 2-D position from a POSIX shm float array"
  - animations.proto     — the same claim on the wire type
  - animations_client.py — the Python docstring

A client reading the proto or the Python API has no way to discover the
command does nothing. Mark all four with TODO(#84) rather than only the Rust
arm. No behaviour change.

Refs #84, #79, #83

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TovGgCFRVaGjUhKHLVKgUF
@joschaschmiedt
joschaschmiedt merged commit 88d8d2c into main Jul 10, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant