Transaction-Science/open-standards
Watch
1
0
Fork
You've already forked open-standards
 0
Code Issues Pull requests 7 Projects Releases Packages Wiki Activity Actions 1

ci(standards-build): the other IOReport meters were unexercised too #102

Open
dcharlot wants to merge 1 commit from ci/macos-energy-widen into main
pull from: ci/macos-energy-widen
merge into: Transaction-Science:main
Conversation 0 Commits 1 Files changed 1 +47 -3
dcharlot commented 2026-09-27 03:32:12 -04:00
Owner
Copy link

jcp-energy was never the only one. Six crates carry their own Apple-Silicon IOReport meter, and every workspace holding one is pinned to a linux runner — so none had ever run on the platform whose private API they call. #100 closed one of six.

This adds the three that pass: proof-cascade's meter, eoc-meter, and jouleclaw-energy. Measured before adding, not after — all four steps run green locally with the exact commands the job uses.

jouleclaw-energy is the interesting one: gated #[cfg(all(feature = "ioreport", target_os = "macos"))], so a macOS runner alone reaches none of it. Without the feature the crate reports 23 tests; with it, 29. Six tests hinge on the flag as well as the platform — measured both ways, which is the only way that difference is visible.

sandbox-meter is deliberately absent

It fails on macOS today, and not environmentally. Its CPU Energy channel returns the identical raw value on every successive read across a 0.4 s CPU burn — three reads, 6581800904 each time — while GPU Energy advanced normally in the same snapshots. So soc_cpu_uj is structurally 0 while PowerMeter::is_hardware() still reports true. The crate's own assertion, a busy window costs SoC energy, catches it.

The cause is an implementation difference, not machine state. Both crates ran back-to-back three times on the same host at the same moment: jcp-energy 3/3 pass, sandbox-meter 3/3 fail. jcp-energy reads through IOReportCreateSamplesDelta; sandbox-meter reads the raw cumulative field from IOReportCreateSamples, which on this OS does not advance for that channel.

Two of my own hypotheses were wrong, recorded so nobody re-runs them:

  • The channel is not missing or renamed — "CPU Energy" and "GPU Energy" are both present in the enumerated channel list.
  • to_uj does not reject the unit — it returns Some for both mJ and nJ, and the conversion is correct.

Channel discovery, naming, unit and conversion are all fine. Only the value is frozen.

Adding it here would make this job permanently red, and repairing a meter is not a CI change — it is a correctness fix to shipped energy measurement, on the is_hardware claim a receipt rests on. It belongs in its own change with its own falsification.

🤖 Generated with Claude Code

`jcp-energy` was never the only one. **Six** crates carry their own Apple-Silicon IOReport meter, and every workspace holding one is pinned to a linux runner — so none had ever run on the platform whose private API they call. #100 closed one of six. This adds the three that pass: `proof-cascade`'s meter, `eoc-meter`, and `jouleclaw-energy`. **Measured before adding, not after** — all four steps run green locally with the exact commands the job uses. `jouleclaw-energy` is the interesting one: gated `#[cfg(all(feature = "ioreport", target_os = "macos"))]`, so a macOS runner alone reaches none of it. Without the feature the crate reports **23** tests; with it, **29**. Six tests hinge on the flag as well as the platform — measured both ways, which is the only way that difference is visible. ## `sandbox-meter` is deliberately absent It fails on macOS today, and **not environmentally**. Its `CPU Energy` channel returns the *identical* raw value on every successive read across a 0.4 s CPU burn — three reads, `6581800904` each time — while `GPU Energy` advanced normally in the same snapshots. So `soc_cpu_uj` is structurally **0** while `PowerMeter::is_hardware()` still reports **true**. The crate's own assertion, `a busy window costs SoC energy`, catches it. The cause is an implementation difference, not machine state. Both crates ran back-to-back three times on the same host at the same moment: `jcp-energy` **3/3 pass**, `sandbox-meter` **3/3 fail**. `jcp-energy` reads through `IOReportCreateSamplesDelta`; `sandbox-meter` reads the raw cumulative field from `IOReportCreateSamples`, which on this OS does not advance for that channel. **Two of my own hypotheses were wrong**, recorded so nobody re-runs them: - The channel is *not* missing or renamed — `"CPU Energy"` and `"GPU Energy"` are both present in the enumerated channel list. - `to_uj` does *not* reject the unit — it returns `Some` for both `mJ` and `nJ`, and the conversion is correct. Channel discovery, naming, unit and conversion are all fine. Only the value is frozen. Adding it here would make this job permanently red, and repairing a meter is not a CI change — it is a correctness fix to shipped energy measurement, on the `is_hardware` claim a receipt rests on. It belongs in its own change with its own falsification. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
ci(standards-build): the other IOReport meters were unexercised too
All checks were successful
standards workspaces build + test / jouleclaw-rs (pull_request) Successful in 1m50s
Details
standards workspaces build + test / eoc-rs (pull_request) Successful in 1m55s
Details
standards workspaces build + test / aac-rs (pull_request) Successful in 38s
Details
standards workspaces build + test / joule-code-rs (pull_request) Successful in 43s
Details
standards workspaces build + test / jcp-rs (pull_request) Successful in 1m22s
Details
standards workspaces build + test / arl-rs (pull_request) Successful in 3m28s
Details
standards workspaces build + test / joulecontract-rs (pull_request) Successful in 41s
Details
standards workspaces build + test / map-rs (pull_request) Successful in 33s
Details
standards workspaces build + test / proof-rs (pull_request) Successful in 1m13s
Details
standards workspaces build + test / mesh-rs (pull_request) Successful in 28s
Details
standards workspaces build + test / openpay (pull_request) Successful in 1m34s
Details
standards workspaces build + test / sandbox-rs (pull_request) Successful in 2m6s
Details
standards workspaces build + test / smart-byte-rs (pull_request) Successful in 2m33s
Details
standards workspaces build + test / joule-ui-rs (pull_request) Successful in 8m36s
Details
standards workspaces build + test / jouledesk-rs (pull_request) Successful in 2m20s
Details
standards workspaces build + test / joulehook-rs (pull_request) Successful in 2m32s
Details
standards workspaces build + test / sense-rs (pull_request) Successful in 2m40s
Details
standards workspaces build + test / macOS energy backends (pull_request) Successful in 2m42s
Details
07fb8360f8 
`jcp-energy` was never the only one. Six crates in this repo each carry their own
Apple-Silicon IOReport meter, and every workspace holding one is pinned to a
linux runner — so none of them had ever run on the platform whose private API
they call. #100 closed one of six.

This adds the three that pass: `proof-cascade`'s meter, `eoc-meter`, and
`jouleclaw-energy`. Measured before adding, not after.

`jouleclaw-energy` is the interesting one: it is gated
`#[cfg(all(feature = "ioreport", target_os = "macos"))]`, so a macOS runner alone
reaches none of it. Without the feature the crate reports **23** tests, with it
**29** — six tests hinge on the flag as well as the platform. Both directions
measured rather than assumed, which is the only way that difference is visible.

## sandbox-meter is deliberately absent, and why

It fails on macOS today, and not environmentally. Its `CPU Energy` channel
returns the **identical raw value on every successive read** across a 0.4 s CPU
burn — verified directly: three reads, one value, `6581800904` each time, while
`GPU Energy` advanced normally in the same snapshots. So `soc_cpu_uj` is
structurally 0 while `PowerMeter::is_hardware()` still reports true, and the
crate's own assertion `a busy window costs SoC energy` catches it.

The cause is a real implementation difference, not machine state. Both crates
were run back-to-back three times on the same host at the same moment:
`jcp-energy` passed 3/3, `sandbox-meter` failed 3/3. `jcp-energy` reads through
`IOReportCreateSamplesDelta`; `sandbox-meter` reads the raw cumulative field
from `IOReportCreateSamples`, which on this OS does not advance for that channel.
Channel discovery is not the problem — the name matches, the `mJ` unit label is
recognised and the conversion is correct. Only the value is frozen.

Two earlier hypotheses were wrong and are worth recording so nobody re-runs
them: the channel is **not** missing or renamed (`"CPU Energy"` and
`"GPU Energy"` are both present in the enumerated channel list), and `to_uj`
does **not** reject the unit (it returns `Some` for both `mJ` and `nJ`).

Adding it here would make this job permanently red, and repairing a meter is not
a CI change — it is a correctness fix to shipped energy measurement, on a claim
(`is_hardware`) that a receipt rests on. It belongs in its own change with its
own falsification, not smuggled into a workflow commit.

Verified: all four steps run green locally with the exact commands the job uses.

Co-Authored-By: Claude Opus 5 <[email protected]>
All checks were successful
standards workspaces build + test / jouleclaw-rs (pull_request) Successful in 1m50s
Details
standards workspaces build + test / eoc-rs (pull_request) Successful in 1m55s
Details
standards workspaces build + test / aac-rs (pull_request) Successful in 38s
Details
standards workspaces build + test / joule-code-rs (pull_request) Successful in 43s
Details
standards workspaces build + test / jcp-rs (pull_request) Successful in 1m22s
Details
standards workspaces build + test / arl-rs (pull_request) Successful in 3m28s
Details
standards workspaces build + test / joulecontract-rs (pull_request) Successful in 41s
Details
standards workspaces build + test / map-rs (pull_request) Successful in 33s
Details
standards workspaces build + test / proof-rs (pull_request) Successful in 1m13s
Details
standards workspaces build + test / mesh-rs (pull_request) Successful in 28s
Details
standards workspaces build + test / openpay (pull_request) Successful in 1m34s
Details
standards workspaces build + test / sandbox-rs (pull_request) Successful in 2m6s
Details
standards workspaces build + test / smart-byte-rs (pull_request) Successful in 2m33s
Details
standards workspaces build + test / joule-ui-rs (pull_request) Successful in 8m36s
Details
standards workspaces build + test / jouledesk-rs (pull_request) Successful in 2m20s
Details
standards workspaces build + test / joulehook-rs (pull_request) Successful in 2m32s
Details
standards workspaces build + test / sense-rs (pull_request) Successful in 2m40s
Details
standards workspaces build + test / macOS energy backends (pull_request) Successful in 2m42s
Details
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin ci/macos-energy-widen:ci/macos-energy-widen
git switch ci/macos-energy-widen

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch main
git merge --no-ff ci/macos-energy-widen
git switch ci/macos-energy-widen
git rebase main
git switch main
git merge --ff-only ci/macos-energy-widen
git switch ci/macos-energy-widen
git rebase main
git switch main
git merge --no-ff ci/macos-energy-widen
git switch main
git merge --squash ci/macos-energy-widen
git switch main
git merge --ff-only ci/macos-energy-widen
git switch main
git merge ci/macos-energy-widen
git push origin main
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Transaction-Science/open-standards!102
No description provided.