fix: a source that has sent no CONFIG reads connecting, not connected
A stream that answered CONNECT but has sent no CONFIG has no signal list, so nothing can be enabled and no DATA frame is owed. Calling that "connected, but no data is arriving: another reader may hold the source" blamed a second reader that does not exist, and the badge blinked green over it -- a working pipeline is exactly what it did not have. The glance word is `connecting` (ten characters, no wider than `event held`, so the fixed-set layout rule still holds) and the badge takes a fourth, steady yellow phase, both from the first frame rather than after the three-second stall test. The stall notice itself now splits on `have_config`: the unicast contention wording where a signal list exists, "trying to connect" where it does not, with `[udpscope] connecting:` on stderr beside the old `starved:`.
This commit is contained in:
1 parent
b313cac46e
commit
811c6d80f0
5 files changed
+145
-52
No files matched your search
@@ -599,14 +599,24 @@ Two lines of the self-check output are assertions in disguise:
|
||||
first run's values, and the signals it names must come back *acquired* (a `row 0 slot 0
|
||||
-> channel ... samples=N` line). Delete the file before a run whose layout you did not
|
||||
mean to inherit (`127.0.0.1_9540.toml` and friends accumulate otherwise).
|
||||
- `[udpscope] starved: connected (config=D), reconnects=N, no new frames in the last
|
||||
- `[udpscope] starved: connected (config=1), reconnects=N, no new frames in the last
|
||||
second ...` (stderr, once per second while the state holds, plus a status-line notice) —
|
||||
"connected but nothing is arriving after a reconnect", which over unicast is the second
|
||||
instance taking the source's single session. Two ways to see it without a second client:
|
||||
point the app at a UDP port where nothing answers (the client CONNECTs, times out,
|
||||
reconnects; `config=0`), and check it does **not** fire against a live source. The status
|
||||
line carries ` | N reconnects` only when N > 0, which is the same counter without the
|
||||
prose.
|
||||
instance taking the source's single session. Check it does **not** fire against a live
|
||||
source. The status line carries ` | N reconnects` only when N > 0, which is the same
|
||||
counter without the prose.
|
||||
**The same stall test has two outcomes, split on `have_config`, and they are different
|
||||
diagnoses.** With a signal list in hand, the above. With **no CONFIG at all** it prints
|
||||
`[udpscope] connecting: connected (config=0), reconnects=N, no configuration from the
|
||||
stream ...` and the notice reads *trying to connect* — nothing was taken away, because
|
||||
with no signal list nothing can be enabled and no DATA frame is owed, and the old wording
|
||||
blamed a second reader that does not exist. That state is also named *without* waiting for
|
||||
the three-sample stall: the glance word is `connecting` and the badge is **yellow** from the
|
||||
first frame (see `badge frames:`). The way to see it with no second client is to point the
|
||||
app at a UDP port where nothing answers (the client CONNECTs, times out, reconnects), which
|
||||
is now the `config=0` branch and no longer exercises the `starved:` one at all — a check of
|
||||
the unicast-contention wording needs a real second reader, or a source that configures and
|
||||
then goes quiet.
|
||||
- **The export's `time`/`abs_seconds` columns must be strictly increasing and evenly
|
||||
spaced.** Check the written file, not just the probe: `np.diff(t)` with no `<= 0` and
|
||||
`rows / (t[-1] - t[0])` equal to the stored rate (the `ch` line's figure). Duplicate or
|
||||
@@ -626,13 +636,19 @@ Two lines of the self-check output are assertions in disguise:
|
||||
(see the `f64` time-ring invariant below). The figure to compute is the ULP of `t[0]` and of
|
||||
`abs_seconds[0]` — the defect that invariant guards is microseconds, nine orders of magnitude
|
||||
above the arithmetic noise, so the two readings cannot be confused.
|
||||
- `badge frames: lit=L dim=D idle=I` — the activity badge's phase per frame. Over a run
|
||||
that acquired anything **both `lit` and `dim` must be non-zero**: that is what "it
|
||||
- `badge frames: lit=L dim=D idle=I connecting=C` — the activity badge's phase per frame. Over
|
||||
a run that acquired anything **both `lit` and `dim` must be non-zero**: that is what "it
|
||||
blinks" means, and a badge stuck lit is indistinguishable from a working one in a
|
||||
screenshot. One or two `idle` frames at the start are the frames before the socket
|
||||
connected; a large `idle` is correct only when the run paused or disarmed (a
|
||||
`UDPSCOPE_PROBE_DISARM_MS` run should show hundreds). The `mode ...` lines carry the
|
||||
rest of the status line, so `rate` and `last event ... ago` are checked there.
|
||||
`UDPSCOPE_PROBE_DISARM_MS` run should show hundreds). **`connecting` must be 0 on a run
|
||||
against a live source** — it is the steady *yellow* phase, "the socket answered but the
|
||||
stream has sent no CONFIG", and a non-zero count against a working mock means a signal list
|
||||
that arrived late or not at all. It is the *only* non-zero phase on a dead-port run
|
||||
(measured: `lit=0 dim=0 idle=90 connecting=446`, the `idle` being the frames before the
|
||||
first CONNECT), which is also the check that a source that has sent nothing never gets the
|
||||
blinking green. The `mode ...` lines carry the rest of the status line, so `rate` and
|
||||
`last event ... ago` are checked there.
|
||||
- `frame cost: tick A/B ms over N, draw C/D ms (max at frame F), paint E/G ms over M` and
|
||||
`frame path: raw=R lod=L frames, segments S/T (mean/max), visible max V samples` — the
|
||||
drawing cost, split into the frame tick, `PlotArea`'s own draw (timed from the frame
|
||||
@@ -727,7 +743,7 @@ Two lines of the self-check output are assertions in disguise:
|
||||
it afterwards.
|
||||
- `[keys] a: armed 0->1 | space: paused 0->1 | t: trigger panel: 0->1 | … | editable focused: 'm' refused=1` (stderr, `UDPSCOPE_PROBE_KEYS_MS`) — **every `X->Y` pair must differ** and **`refused` must be 1**. The refusal is the whole reason the controller is in the bubble phase: every bare-letter accel is also a character, so an accel that fires while a `GtkEditable` has focus makes the window entry unusable. A pair reading `0->0` is an action whose dispatch does not reach the handler a click reaches. Note the format is `<key>: <widget-description>: <before>-><after>` — the name passed to `before_after()` includes the widget's description, so `t: trigger panel: 0->1` is the correct form (not `t: trigger panel 0->1` without the colon before the values).
|
||||
- `[zoomkeys] ctrl+plus x=[..]->[..] y_held=1 | alt+plus y=[..]->[..] x_held=1` (stderr, `UDPSCOPE_PROBE_ZOOMKEYS_MS`) — **both `_held` must be 1 and both zooms must still happen.** Run it inside a pinned state, where a frame cannot re-frame the other axis for its own reasons: `UDPSCOPE_PROBE_PAUSE_MS=1500 UDPSCOPE_PROBE_ZOOMKEYS_MS=2200`. A `_held=0` is the modifier not reaching the plotter's controller; an unchanged range on the *zoomed* axis is the opposite failure, the key doing nothing. Ctrl restricts to x and Alt to y; Ctrl+Alt zooms neither (no special case needed — neither flag alone fires).
|
||||
- `status bar: glance=[● live · 1.09 MS/s · 2 s window] max_glance_chars=53 detail_fields=11 popover_rebuilds=0` (exit dump) — **`max_glance_chars` must stay small** (under about 60) and **`popover_rebuilds` must be 0**. The status row is directly above the plot, so this is the "layout must not depend on content" rule read from the bar's own side: the state field is one word from a fixed set, the rate field is `%.3g` (so `10 kS/s`, never `10.0 kS/s`), and the two fields a *state* adds are both elapsed times — trigger mode's `last event … ago` and a pause's `for <elapsed>` — which step units rather than growing digits (`format_elapsed()`). A **paused** glance is not in the dump at all: it is read by `[pause-probe]`'s `glance=` field, since the dump's own line is taken live. `detail_fields` is the popover's label count, a literal, so adding a label without thinking about layout shows up here. The glance rate format matters: `%.3g` drops the trailing zero that a `%.4g` or a fixed-precision format would keep — a rate that reads differently in the dump and in the help page is a format disagreement, and `14-status.txt`'s example must match it.
|
||||
- `status bar: glance=[● live · 1.09 MS/s · 2 s window] max_glance_chars=53 detail_fields=11 popover_rebuilds=0` (exit dump) — **`max_glance_chars` must stay small** (under about 60) and **`popover_rebuilds` must be 0**. The status row is directly above the plot, so this is the "layout must not depend on content" rule read from the bar's own side: the state field is one word from a fixed set (`connecting`, `live`, `paused`, `armed`, `capturing`, `event held`, `disarmed` — a word added to it must be **no wider than the widest already there**, which is what let `connecting` join at ten characters beside `event held`; the dead-port glance reads `max_glance_chars=51` against a live run's 54), the rate field is `%.3g` (so `10 kS/s`, never `10.0 kS/s`), and the two fields a *state* adds are both elapsed times — trigger mode's `last event … ago` and a pause's `for <elapsed>` — which step units rather than growing digits (`format_elapsed()`). A **paused** glance is not in the dump at all: it is read by `[pause-probe]`'s `glance=` field, since the dump's own line is taken live. `detail_fields` is the popover's label count, a literal, so adding a label without thinking about layout shows up here. The glance rate format matters: `%.3g` drops the trailing zero that a `%.4g` or a fixed-precision format would keep — a rate that reads differently in the dump and in the help page is a format disagreement, and `14-status.txt`'s example must match it.
|
||||
|
||||
The probes are the regression net — when changing UI or plot-host behaviour, extend
|
||||
the probe/dump in `src/ui.cpp` rather than adding a separate harness.
|
||||
@@ -1681,9 +1697,14 @@ far the largest file.
|
||||
Those two used to read the *label*, and the label no longer carries `packets`, `gaps`,
|
||||
`plot 1:` or the buffer figures — so a `gtk_label_get_text()` there would silently reduce
|
||||
every documented `mode …:` assertion to four fields. The glance line's state field is **one
|
||||
word from a fixed set** (`live`, `paused`, `armed`, `capturing`, `event held`, `disarmed`) for
|
||||
the layout reason above; a seventh word, or a field whose width tracks the stream, breaks the
|
||||
row the plot is laid out under.
|
||||
word from a fixed set** (`connecting`, `live`, `paused`, `armed`, `capturing`, `event held`,
|
||||
`disarmed`) for the layout reason above; a word **wider than the widest already there**, or a
|
||||
field whose width tracks the stream, breaks the row the plot is laid out under. The set may
|
||||
grow — `connecting` was added for the no-CONFIG state — but only on that condition, and the
|
||||
check is the dump's `max_glance_chars`. `connecting` is derived from `have_config` alone and
|
||||
sits **ahead of every other branch**, including the display mode's: with no signal list, every
|
||||
other word claims something that does not exist yet. The `mode` prose branches the same way for
|
||||
the same reason, which is what keeps the two tiers from disagreeing.
|
||||
- **The ⓘ popover's widgets are built once and only their text is set.** It is visible when the
|
||||
tick updates it, so a rebuild is a per-frame relayout of a widget on screen.
|
||||
`update_status_popover()` only ever calls `gtk_label_set_text()`, and `popover_rebuilds` in
|
||||
|
||||
Reference in new issue
Block a user