Files
ocp/NOTEPAD.md
stroblme c006ef1665 Add NOTEPAD with the leftovers from the 8.0.1 bump
- the bound surface is inventoried from the app alone, but assay is a
  consumer too — which is why BRepPrimAPI_MakeSphere is unbound and
  assay's fixture generator has been unrunnable since the cutover.
- the GIL rationale for STEP/IGES predates 8.0's thread-safety
  contract and should cite why that contract does not apply to us.
- TKHelix is compiled by the builder image but not in the link list.
2026-08-11 13:21:32 +02:00

2.0 KiB

Notepad

Leftovers, deferrals and things noticed in passing. Nothing here blocks a release; the phase plan lives in the app repo at docs-private/reference/roadmap.md.

Open

  • CHORE/COVERAGE — the bound surface is inventoried from the app alone, but assay is a consumer too. tools/inventory.py parses app/backend for from OCP.<mod> import ..., which is why BRepPrimAPI_MakeSphere is not bound: the app never builds a sphere. assay/scripts/gen_flow_fixtures.py does, so it has failed at import against the app's venv since the 10C cutover (2026-08-10) and nobody noticed — its fixtures predate the swap. Either teach inventory.py a second source root or keep a small hand-maintained addendum for non-app consumers, then bind what it turns up. Logged from the assay side in assay/NOTEPAD.md.

  • DOC/GIL — the STEP/IGES rationale predates OCCT 8.0's thread-safety contract and should cite it. docs/design.md's Inc 3 note explains why the XSTEP readers and writers hold the GIL. 8.0 added a contract that sounds like it changes this and does not: it is one reader or writer per thread, default parameter set, which is a per-instance guarantee that explicitly excludes mutated Interface_Static — and app/backend/n3xd/ cad/import_.py sets xstep.cascade.unit process-wide. IGES read is still documented non-thread-safe. Releasing the GIL would also buy nothing: the app parses imports in a resource-bounded subprocess (cad/import_pool.py) with import_max_concurrency = 1. Worth a few lines so the question is not re-opened from the release notes alone.

  • CHORE/BUILD — TKHelix is compiled by the builder image but not linked. occt/Dockerfile builds ModelingAlgorithms, so libTKHelix.so.8.0.1 and the HelixGeom_*/HelixBRep_* headers are in the image; CMakeLists.txt's toolkit list simply does not name it. One line plus a module whenever the thread-feature spike (roadmap 10E) wants it — no image rebuild.

Closed

None yet.