You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- daemon.serve() now warms the NanonisController before publishing the
PID file so the very first client request lands on a hot instrument
instead of paying the import + connect cost (~600 ms) inline.
daemon start now takes ~840 ms but daemon's first served request is
~100 ms p50 like all subsequent ones.
- Add numpy>=1.23 as an explicit dependency: nanonis-spm 1.0.9 imports
numpy unconditionally but does not declare it in its wheel metadata,
so a bare pip install would silently leave NanonisClass unimportable.
- CHANGELOG.md 0.2.0 entry documents all breaking changes (package /
CLI / class renames, qcodes removal, trajectory removal, env-var
cleanup) plus the latency table.
- README.md rewritten for the new architecture and audience: drops the
qcodes-bridge framing, leads with the warm-daemon performance story,
documents nspmctl daemon lifecycle and --no-daemon escape hatch.
Acceptance summary on the simulator:
raw nanonis-spm one-shot floor: ~110 ms
nspmctl --no-daemon get bias_v: ~525 ms p50 (cold inline)
nspmctl get bias_v (warm daemon): 102 ms p50 / 118 ms p95
85 tests + 1 skipped (simulator-gated) pass
wheel installs cleanly in a fresh venv and the smoke test succeeds.
- Slim the implementation aggressively, but preserve the existing CLI command contract and tool-result schema.
4
+
- Remove the trajectory-related CLI commands.
5
+
- Preferred rename is `nspmctl`; do not build a Rust client for this effort.
6
+
- Keep both one-shot/non-daemon mode and a daemon mode; daemon instances should auto-exit after 30 minutes of idle time.
7
+
- Treat this CLI as agent-facing high-call-volume tooling. Benchmark raw `nanonis-spm``bias get` latency as the baseline, prioritize persistence/warm execution so repeated calls avoid re-importing `nanonis_spm`, target hot-call latency around `0.3 ms`, and treat roughly `19 ms` as acceptable if TCP-connect overhead cannot be reduced further.
0 commit comments