Skip to content

Report 2026.01.01, and take version_num()'s optional vector - #98

Merged
revarbat merged 1 commit into
mainfrom
version-2026-and-version-num-arg
Aug 15, 2026
Merged

Report 2026.01.01, and take version_num()'s optional vector#98
revarbat merged 1 commit into
mainfrom
version-2026-and-version-num-arg

Conversation

@revarbat

Copy link
Copy Markdown
Member

Two fixes

1. Wrong release reported. version()/version_num() returned 2025.01.01 — a release that never existed. The OpenSCAD release we track is 2026.01.01 (tag openscad-2026.01.01-TEST2, the first tagged build carrying hex literals and the object() function). So version() is now [2026, 1, 1] and version_num() is 20260101.

2. version_num() ignored its optional argument. The reference accepts a version vector and folds that, not the running release. We always answered with our own — version_num([2019, 5, 0]) returned 20250101 instead of 20190500. Now folded via the reference's own y * 10000 + m * 100 + d, with getVec3's 2-element form defaulting the day to 0. A non-list, a wrong length, or a non-numeric element is undef.

Verified against real OpenSCAD 2022.08.22

Ran the same script through /Applications/OpenSCAD.app:

Expression Real OpenSCAD Ours
version_num([2019,5,0]) 20190500 ✅ match
version_num([2019,5]) 20190500 ✅ match
version_num(5) undef ✅ match
version_num(undef) undef ✅ match
version_num([2019]) undef ✅ match
version_num([2019,5,0,7]) undef ✅ match
version_num(["a","b","c"]) undef ✅ match
version_num(["a","b"]) 3.81052e+286 undef — deliberate

That last row is a real bug in the reference: its size-2 path ignores getVec2's own failure and folds uninitialized doubles. We return undef rather than copy the undefined behavior. Commented at the call site.

Tests

  • VersionNumFoldsAGivenVersionVector — the 3- and 2-element forms
  • VersionNumRejectsAnythingButA2Or3NumberVector — all six undef cases
  • VersionReturnsThreeElementList only checked the list's length, so it could never have caught a wrong release; it now pins the values alongside version_num()'s

867 tests pass, under both OSCAD_BYTECODE_VM=0 and =1.

Version bumped 0.32.1 → 0.32.2.

🤖 Generated with Claude Code

Two fixes to the version builtins:

version()/version_num() reported 2025.01.01, a release that never existed.
The OpenSCAD release to track is 2026.01.01 (tag openscad-2026.01.01-TEST2,
the first tagged build carrying hex literals and the object() function), so
version() is [2026, 1, 1] and version_num() is 20260101.

version_num() also ignored the optional vector argument the reference
accepts, always answering with our own release: version_num([2019, 5, 0])
returned 20250101 instead of 20190500. It now folds whatever it is handed,
via the reference's own y * 10000 + m * 100 + d, with getVec3's 2-element
form defaulting the day to 0. A non-list, a wrong length, or a non-numeric
element is undef.

One deliberate divergence, commented at the call site: the reference's
size-2 path ignores getVec2's own failure and folds uninitialized doubles,
so real OpenSCAD answers version_num(["a", "b"]) with garbage (measured:
3.81052e+286). We return undef there instead.

Every other case was checked against real OpenSCAD 2022.08.22 directly --
[2019,5,0], [2019,5], 5, undef, [2019], [2019,5,0,7] and ["a","b","c"] all
match exactly.

VersionReturnsThreeElementList only asserted the list's length, so it could
not have caught a wrong release; it now pins the values alongside
version_num()'s, which is the point of the pair.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@revarbat
revarbat merged commit 2bbb5df into main Aug 15, 2026
3 checks passed
@revarbat
revarbat deleted the version-2026-and-version-num-arg branch August 15, 2026 07:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant