Repository navigation
KiteViewers.jl: draw a definition, not a segment CSV #57
Description
Activity
Replacing load_segments/SegmentType/v3_segments.csv with drawing a KiteGeometry SystemDefinition (tether/wing/bridle derived from its tethers and wing blocks), reexporting KiteGeometry; stacked on #56, which is #50 made loadable against KiteUtils 0.13. The V3 fixture becomes a 44-point awesIO structure document converted from the CSV plus the log's first frame, since KiteGeometry's own V3 fixture is the 220-point beam model and does not match tmp_parking.arrow. Also bin/install learns Julia 1.13, the box's Julia, with its manifest. Leaving the hard-coded 1p/4p paths of update_system alone.
The plan changed what this unit asks for, so the body above is now
viewersasplans/topology_state_split_plan.mdwords it today. Read it again before you go on.2 remaining items
- added and removed
on Sep 30, 2026 - added and removed
on Sep 30, 2026 Question from
KiteViewers.jl-57Should this branch commit manifests that pin KiteModels to OpenSourceAWE/KiteModels.jl#312's branch, or wait for a KiteModels release?
Why it's stuck: the pre-push gate has refused this branch three turns running. All three Manifest-v1.1{1,2,3}.toml.default pin KiteUtils 0.11.13 against [compat] 0.13. That mismatch comes from #50/#56 (my base), not from this change, and no registered KiteModels allows KiteUtils 0.13 (latest is v0.11.16; KiteModels #312 and #321 are open and name no issue). I blocked #57 on #54, but the gate still restarts the turn.
The work is done at 8b00fb4: the V3 render is byte-identical to the CSV one, and the full local suite passes with KiteModels at #312's branch in the gitignored live manifest.
- A (recommended): wait. Tell the box to hold this task until KiteModels releases; then I do the minimal resolve and push. Nothing unreleased ships.
- B: commit .defaults with KiteModels at #312's branch via [sources] now. The gate passes and a draft PR opens, but every checkout and CI run installs an unmerged branch until the release.
- changed the title
[-]One kite system definition across the Kite packages: KiteViewers.jl: draw a definition, not a segment CSV[/-][+]KiteViewers.jl: draw a definition, not a segment CSV[/+]on Oct 1, 2026
src/common.jl:65readsdata/v3_segments.csv—segment,point1,point2and a segment type, with neither names nor tethers — and that sidecar is the reason the viewer can draw one system. Take aSystemDefinitioninstead, soplot(state, definition)is one code path and the viewer draws whatever wrote the definition.Delete
load_segments, theSegmentTypeCSV dialect anddata/v3_segments.csvwith it; removing a feature removes what it used (CLEAN_CODE.md§2). ReexportKiteGeometrybeside the KiteUtils reexport already there.KiteViewers #50 is the open frame pull request here, so it is your base while it is open.
The V3 kite is the fixture: it is what the CSV described, and a picture of it before and after is the check. Say in the card if a GLMakie test needs the box's
Xvfbdisplay rather than working around it.Unit
viewersof planplans/topology_state_split_plan.md, tracked in 1-Bart-1/Agents#294.https://github.com/1-Bart-1/Agents/blob/4ee7e2b839cdd358bef56ef3b00097f4b5702f50/plans/topology_state_split_plan.md