[us-commits] [ehb54/ultrascan3] 505b56: perceiver: run the regression in CI, under floors ...

[emre brookes]

  Branch: refs/heads/ehb54-issue-1016-somo-merge-2
  Home:   https://github.com/ehb54/ultrascan3
  Commit: 505b560e0e802db5fe8bb52f906b70d1f7f2264d
      https://github.com/ehb54/ultrascan3/commit/505b560e0e802db5fe8bb52f906b70d1f7f2264d
  Author: ehb54 <brookes at uthscsa.edu>
  Date:   2026-08-18 (Tue, 18 Aug 2026)

  Changed paths:
    M .github/workflows/somo-module-tests.yml
    M us_somo/develop/perceiver/Makefile
    M us_somo/develop/perceiver/residue_oracle.h
    M us_somo/develop/perceiver/tests/regression.cpp

  Log Message:
  -----------
  perceiver: run the regression in CI, under floors that can actually fail

Set 2 committed the fixtures, but CI still only asserted the vacuous-pass
guard -- it built bin/regression, ran it with NO arguments to prove it fails
on nothing, and never scored a structure. The regression itself had not run
in CI at all.

Running it is not enough on its own: the harness only failed when it scored
ZERO atoms, so perception could fall from 99.8% to 90% and still exit 0. Two
optional floors are added, and `make regress-ci` pins them to the committed
fixture set:

  --min-atoms 41219      a fixture going missing or truncated would quietly
                         shrink what every percentage is measured over while
                         still reporting a healthy-looking number
  --min-geometric 99.8   perception getting worse fails the build

They are floors, not expected values: an improvement must not fail. Both are
reported together rather than short-circuiting, so one run tells you
everything out of tolerance. Unknown options are now rejected rather than
being read as input filenames.

The vacuous-pass step is kept alongside the real run, because the real run
would still go green if the fixtures vanished AND the guard broke.

residue_oracle.h is brought to the coding standards. It had

  while (ss>>t) v.push_back(t); return v;

which is what -Wmisleading-indentation was reporting on every build: the
return reads as guarded by the while and is not. Braces settle it. Scoring is
unchanged -- 41219 atoms, 99.833% geometric perception, 69 genuine errors,
before and after.

Also drops the stale "the demo structures are not committed to the
repository" text from the failure message, which set 2 made untrue.

Co-Authored-By: Claude Opus 5 <noreply at anthropic.com>


  Commit: 59325d3cbbd758a15ae9fe6f17c5f53fda5aa85d
      https://github.com/ehb54/ultrascan3/commit/59325d3cbbd758a15ae9fe6f17c5f53fda5aa85d
  Author: ehb54 <brookes at uthscsa.edu>
  Date:   2026-08-18 (Tue, 18 Aug 2026)

  Changed paths:
    M us_somo/develop/grpy/grpy_exposure.hpp
    M us_somo/develop/grpy/grpy_shell.hpp
    M us_somo/develop/grpy/tests/test_shell.cpp
    M us_somo/develop/src/us_hydrodyn_grpy.cpp
    M us_somo/develop/src/us_hydrodyn_other.cpp
    M us_somo/develop/src/us_hydrodyn_settings.cpp

  Log Message:
  -----------
  somo: braces on the code this set adds, per the coding standards

The UltraScan III standards require braces on a simple if/for/while body.
The rule earns its keep: an unbraced body is what produced the
-Wmisleading-indentation warning on the perceiver build, and it is the shape
that lets a second statement be added later outside the guard it appears to
be under.

Scope is deliberately narrow, so this stays reviewable:

  - the four grpy files this set ADDS are formatted in full with the project
    tool (ehb54/grpy-cpp tools/us3_style.pl). The whole file is new code, so
    there is no existing formatting for a reviewer to diff against.
  - the files this set MODIFIES get braces ONLY, only on lines this set
    added: 15 sites across us_hydrodyn_grpy.cpp, _other.cpp and _settings.cpp.
    No spacing, indentation or reflow -- those files carry ~1400 pre-existing
    unbraced bodies between them, and touching any of them would bury this
    set's actual changes in the diff. That remains for the planned full pass.

Verified: brace counts balance in every edited file (delta 0 opening vs
closing), grpy test_shell and test_process both ALL PASS, perceiver unit
tests 147 checks 0 failures, regression unchanged at 99.833% over 41219
atoms.

Note for anyone repeating this with the tool: `--check` reports a body whose
brace sits on its own line as unbraced, though the formatter correctly leaves
it alone. Acting on that list mechanically produces `) {` above `{`. Twelve
of the sites here were that false positive and were skipped. Fixed upstream
in ehb54/grpy-cpp#1.

Co-Authored-By: Claude Opus 5 <noreply at anthropic.com>


  Commit: 735d4f94f2cdef575e6e0b2d18c4a99115fb3d51
      https://github.com/ehb54/ultrascan3/commit/735d4f94f2cdef575e6e0b2d18c4a99115fb3d51
  Author: ehb54 <brookes at uthscsa.edu>
  Date:   2026-08-18 (Tue, 18 Aug 2026)

  Changed paths:
    M us_somo/develop/cmdline.pri
    M us_somo/develop/generic.pri
    M us_somo/develop/libus_somo.pro

  Log Message:
  -----------
  somo: declare the C++17 the grpy module requires

Nothing in the SOMO build declared a C++ standard, so it inherited whatever
the compiler happened to default to. That was harmless while the code was
C++11-compatible. This set vendors the grpy module, which is not: its own
tests compile it with -std=c++17, and ShellReport::Provenance is brace-
initialized while carrying default member initializers, which is only an
aggregate from C++14 on.

The result was a build that depends on the toolchain rather than on anything
stated. The CI containers use a GCC new enough to default to gnu++17, so they
compile it and the branch looked fine. A Qt5 macOS build passes -std=gnu++11
from its mkspec and fails outright:

  grpy/grpy_shell.hpp:443:27: error: no viable overloaded '='
  note: candidate function not viable: cannot convert initializer list
        argument to 'grpy::ShellReport::Provenance'

macOS is a release target, so this would have surfaced at packaging time
rather than in CI.

Declared in the tracked build files rather than in local.pri, which is
per-developer and untracked -- a requirement of the source belongs with the
source, and existing developers' local.pri files would never have picked it
up. Set in all three of libus_somo.pro, generic.pri and cmdline.pri so the
library and the programs linking against it agree.

Verified on arm64 macOS / Qt 5.15.14, whose mkspec is one of the affected
ones: every source compiles, including grpy_shell.hpp and grpy_exposure.hpp.

Co-Authored-By: Claude Opus 5 <noreply at anthropic.com>


Compare: https://github.com/ehb54/ultrascan3/compare/2eb987336bc7...735d4f94f2cd

To unsubscribe from these emails, change your notification settings at https://github.com/ehb54/ultrascan3/settings/notifications