Commits
This commit contains the following changes:
R {AGENTS.md => for-llm/repo.md}
- Updated example comment to use correct Zig 0.15 addTest syntax
- Replaced deprecated .target, .optimize, .root_source_file with .root_module
- Added version note to clarify this is for Zig 0.15+ syntax
- Removed outdated parameters that no longer exist in current API
- Fixed incorrect test count attribution where all 83 tests were attributed to the last file
- Added proper per-file tracking with separate counters for each test file
- Now correctly reports individual file results (e.g., 'string_literals: 5 of 5 tests passed')
- Maintains global summary showing total test count across all files
- Provides better visibility into test distribution and per-module test health
- Each file's test count is now accurately reported as tests are processed
- Updated test_runner.zig to work with Zig 0.15 API changes
- Replaced complex File.Writer approach with std.debug.print for simplicity
- Fixed stderr access and formatting methods for new Zig version
- Re-enabled custom test runner in build.zig for both lib_unit_tests and exe_unit_tests
- Restored colored test output with individual test visibility
- All 83 tests now pass with improved test runner output formatting
- Removed complex file walking logic that created individual modules per test file
- Updated build.zig to use existing lib_mod for all tests instead of createModule() per file
- Modified src/root.zig to import all test files and make them discoverable via test block
- Fixed Zig 0.15 compatibility issues with root_module API changes
- Reduced build complexity from 25+ steps to 5 steps while maintaining all 83 tests
- Improved build performance and maintainability by centralizing test organization
- Added activeFieldSize function demonstrating inline else in switch statements
- Added test showing inline else generates specialized code for union variants at compile time
- Added ECS-inspired metaprogramming test using inline for and @typeInfo() introspection
- Test validates component type matching with different field counts (Health: 2, Position: 3, Damage: 1)
- Demonstrates Zig's powerful compile-time metaprogramming capabilities for generic component systems
Purpose: avoid accidentally relying on zsh specific configs and env
The PATH detection was incorrectly flagging properly configured shells
because the 'just' subprocess environment may differ from the actual
shell environment. Updated to provide more accurate feedback about
PATH ordering and acknowledge that subprocess PATH may not reflect
the user's actual shell configuration.
The test-zls-fix task verifies that:
- Symlink to actual Zig binary exists
- 'zig env' works with corrected PATH (what ZLS executes)
- Standard library is found correctly
- No ZLS config file exists (using defaults)
- Basic Zig compilation works
This addresses the concern about testing the fix before committing.
ZLS was failing to find the Zig standard library because it couldn't execute
'zig env' through the asdf shim. The shim lacks proper environment context
when called by ZLS, resulting in error code 126.
This fix creates a direct symlink from ~/.local/bin/zig to the actual Zig
binary (bypassing the asdf shim) and removes any ZLS config files to use
defaults. ZLS can then successfully execute 'zig env' and locate the
standard library.
Changes:
- Add fix-zls task that creates symlink without config file
- Add check-zls task with PATH ordering guidance
- Add clean-all task for workspace-wide cleanup
- Add .tool-versions for consistent Zig version
- Remove dependency on zls.json configuration
The symlink approach is cleaner than config files and works automatically
with any Zig version managed by asdf.
Added comprehensive reference links at the beginning of the file:
Core reference sources:
- https://en.wikipedia.org/wiki/Floating-point_arithmetic#Accuracy_problems
- https://www.exploringbinary.com/why-0-point-1-does-not-exist-in-floating-point/
- https://www.exploringbinary.com/floating-point-questions-are-endless-on-stackoverflow-com/
- https://docs.python.org/3/tutorial/floatingpoint.html
- https://floating-point-gui.de/basic/
Additional educational resources:
- https://www.baeldung.com/cs/floating-point-numbers-inaccuracy
- https://riskledger.com/resources/floating-point-numbers
- https://www.johndcook.com/blog/2025/06/27/most-ints-are-not-floats/
- https://leancrew.com/all-this/2025/06/in-defense-of-floating-point/
These links provide comprehensive theoretical foundation and educational context
for understanding IEEE 754 floating-point precision limitations demonstrated
in the test cases. They serve as valuable resources covering both the problems
and practical approaches to floating-point arithmetic.
The test file now properly credits its inspiration sources and provides
readers with authoritative references for deeper understanding of the
concepts being demonstrated.
Replaced adaptive testing with two distinct test sets as requested:
1. **Imprecise decimal fraction cases** (non-zero tolerance):
- 0.09+0.01≠0.1, 0.1+0.2≠0.3, 0.3+0.6≠0.9, etc.
- All cases verified to NOT exact match (expect(result != expected))
- Then verified to be approximately equal (expectApproxEqRel)
- Shows precision errors for problematic IEEE 754 representations
2. **Exact decimal fraction cases** (zero tolerance):
- 0.58+0.42=1.0, 0.5+0.25=0.75, 0.125+0.375=0.5, etc.
- All cases use exact equality (expectEqual)
- Demonstrates values that ARE exactly representable in IEEE 754
Benefits:
- Clear separation: no adaptive logic, predictable test behavior
- Educational: shows which decimal operations are exact vs approximate
- Robust: ensures non-zero tolerance tests genuinely need tolerance
- Comprehensive: covers both sides of IEEE 754 precision behavior
Test suite now has 16 test cases with clear exact/approximate distinction,
providing complete coverage of floating-point precision concepts.
Enhanced the test suite with new floating-point precision concepts learned
from analyzing ../../yard-rs/rust_cpp/src/run_cpp.rs:
New test cases added:
1. **Division precision and scale dependency**
- Shows how scaling affects division precision (63/9 vs 0.063/0.009)
- Demonstrates accumulated precision errors in scaled operations
- Tests integer casting behavior with precision loss
2. **Comprehensive decimal fraction precision issues**
- Extended test cases: 0.7+0.1, 2.2+1.1, 0.58+0.42, etc.
- Adaptive testing: handles both exact and approximate cases
- Shows precision errors for problematic decimal representations
- Identifies cases that are exactly representable in IEEE 754
Key insights discovered:
- **Scale-dependent precision**: Same mathematical operation can have different
precision depending on the scale of operands
- **Exact representability**: Some decimal combinations (like 0.58+0.42=1.0)
are exactly representable in IEEE 754
- **Cross-language consistency**: IEEE 754 behavior is consistent across languages
Test suite now has 15 comprehensive test cases covering:
- Basic precision issues, associative/distributive failures
- Scale-dependent precision, division precision
- Comprehensive decimal fraction testing with adaptive logic
- All edge cases and special values
This provides a complete educational resource for understanding IEEE 754
floating-point precision behavior and its practical implications.
Streamlined the test to demonstrate the essential floating-point precision issue:
Test flow:
1. expect(sum != 1.0) // Proves precision loss occurred
2. expectApproxEqRel(sum, 1.0) // Shows it's close to correct answer
3. expectEqual(sum, 0.9999999999999999) // Exact match with IEEE 754 result
Key improvements:
- Removed Python comparison - focuses purely on Zig/IEEE 754 behavior
- Clean three-step verification: not exact, approximately correct, exact match
- Demonstrates both the problem (precision loss) and solution (tolerance)
- Shows the specific IEEE 754 representation that results from the calculation
This provides a clear, focused demonstration of why floating-point arithmetic
requires tolerance-based comparisons for decimal operations.
Corrected the test logic to properly demonstrate floating-point precision issues:
Before (incorrect):
- Compared imprecise result with another imprecise result
- Used expected_python_result as if it were the correct answer
After (correct):
- Compare actual result (0.9999999999999999) with mathematically expected result (1.0)
- Show that both Zig and Python produce the same imprecise result due to IEEE 754
- Both imprecise results are approximately equal to the correct result (1.0)
Key insight:
- Mathematical expectation: 0.1 × 10 = 1.0
- IEEE 754 reality: 0.1 × 10 ≈ 0.9999999999999999
- Test verifies: actual != expected (precision loss) AND actual ≈ expected (within tolerance)
This better demonstrates why floating-point arithmetic requires tolerance-based
comparisons for decimal operations that can't be exactly represented in binary.
Ensures that floating-point precision issues are actually occurring by
verifying values don't exact match before testing approximate equality.
Changes:
- Added expect(result != expected) before expectApproxEqRel() calls
- Confirms precision errors are genuinely present, not masked by tolerance
- Strengthens test reliability by proving inexact arithmetic occurs
- Removed redundant check for identical IEEE 754 representations
Test robustness:
- 8 tests with non-zero tolerance now verify exact inequality first
- 6 tests with exact equality remain unchanged
- All 14 tests pass, demonstrating both exact and approximate behaviors
- Better educational value showing when precision loss actually happens
This ensures the test suite accurately demonstrates IEEE 754 floating-point
precision limitations rather than just assuming they occur.
This commit refines the floating-point precision test suite to use exact
equality for tests that don't actually need tolerance, while maintaining
approximate equality for tests that genuinely require it.
Test Classification:
- 6 tests (43%) now use exact equality where appropriate:
* associative/distributive property tests (adaptive: exact if equal, approx if not)
* rounding behavior mathematical properties (truncation relationships)
* large number precision loss (complete loss of small additions)
* special values (IEEE 754 guarantees like 0.0 == -0.0)
* denormalized numbers (boolean property checks)
- 8 tests (57%) still require approximate equality:
* decimal arithmetic that can't be represented exactly (0.1 + 0.2 ≈ 0.3)
* multiplication precision issues (4.35 × 100 ≈ 435.0)
* accumulated precision errors in complex calculations
* financial calculation precision loss
* comparison operations with problematic decimal cases
Benefits:
- More precise testing distinguishes deterministic vs approximate operations
- Better educational value showing when floating-point is exact vs approximate
- Adaptive logic handles both exact and approximate cases dynamically
- Maintains robustness where genuine precision issues occur
All 14 test cases pass, demonstrating IEEE 754 floating-point behavior
accurately while using the most appropriate assertion method for each case.
Extended string_literals.zig to include @embedFile functionality with a
focused test that demonstrates the key relationship between @embedFile
and multiline string literals:
- Added single @embedFile test showing compile-time file embedding
- Demonstrates embedding the source file itself for clean self-reference
- Highlights key distinction: @embedFile for external files vs multiline strings for inline content
- Both features provide zero runtime cost with compile-time resolution
- Maintains focused approach with only 5 total tests (4 multiline + 1 @embedFile)
This addition showcases complementary Zig features for handling multi-line
text content without bloating the test suite with redundant cases.
Reduced string_literals.zig test suite from 13 exhaustive tests to 4
essential tests that demonstrate the most valuable aspects of Zig
multiline string literals:
- Fundamental behavior: direct equivalence to regular strings with improved syntax
- Primary benefit: raw backslash handling eliminates escape sequence complexity
- Real-world application: template and code generation use cases
- Important quirk: automatic preservation of line-ending whitespace
This targeted approach emphasizes practical knowledge over comprehensive
coverage, making the test suite more maintainable and educational.
e.g. just version bump failed
- Ran `just fmt` to format all Rust projects in the `yard-rs` directory.
- Verified `just ci` still works after formatting.
🤖 Generated with [opencode](https://opencode.ai)
Co-Authored-By: opencode <noreply@opencode.ai>
- Added a new `just fmt` command to format all Rust projects in the `yard-rs` directory.
- The command follows the same pattern as `just clean`, iterating over each project and running `cargo fmt`.
- Verified the command works by running it and checking the output.
🤖 Generated with [opencode](https://opencode.ai)
Co-Authored-By: opencode <noreply@opencode.ai>
- Renamed command for clarity and consistency
🤖 Generated with [opencode](https://opencode.ai)
Co-Authored-By: opencode <noreply@opencode.ai>
- Added `cache-clean` command to reset sccache stats and restart the server
- Added `clean` command to recursively clean Rust projects by removing target directories and Cargo.lock files
🤖 Generated with [opencode](https://opencode.ai)
Co-Authored-By: opencode <noreply@opencode.ai>
Fixed the relative path for DYLD_LIBRARY_PATH to ensure proper library loading.
🤖 Generated with [opencode](https://opencode.ai)
Co-Authored-By: opencode <noreply@opencode.ai>
- Added clear project definition\n- Structured verification by project vs language\n- Included exact cd commands for context\n- Linked each language to its CI workflow\n- Added CI reference paths section\n- Verified against all workflow YAML files\n- Maintained GPU/environment requirements
- Added language-specific completion checklists\n- Detailed Rust/C++/Zig verification steps\n- Expanded commit message standards\n- Included practical examples\n- Maintained all existing guidelines\n- Improved section organization
- Fully restored golden rules in bullet-point format\n- Preserved all repository-specific content\n- Added detailed workflow commands from justfiles\n- Included CI pipeline details from workflows\n- Maintained project structure and code style guidelines\n- Added toolchain management section\n- Kept existing commit standards
Added basic tests for rustry project:
- Test for print_help function
- Test for hello_main function
🤖 Generated with [opencode](https://opencode.ai)
Co-Authored-By: opencode <noreply@opencode.ai>
Added basic test for clifford-xp project:
- Simple test to verify project structure
- Fixed incorrect test count attribution where all 83 tests were attributed to the last file
- Added proper per-file tracking with separate counters for each test file
- Now correctly reports individual file results (e.g., 'string_literals: 5 of 5 tests passed')
- Maintains global summary showing total test count across all files
- Provides better visibility into test distribution and per-module test health
- Each file's test count is now accurately reported as tests are processed
- Updated test_runner.zig to work with Zig 0.15 API changes
- Replaced complex File.Writer approach with std.debug.print for simplicity
- Fixed stderr access and formatting methods for new Zig version
- Re-enabled custom test runner in build.zig for both lib_unit_tests and exe_unit_tests
- Restored colored test output with individual test visibility
- All 83 tests now pass with improved test runner output formatting
- Removed complex file walking logic that created individual modules per test file
- Updated build.zig to use existing lib_mod for all tests instead of createModule() per file
- Modified src/root.zig to import all test files and make them discoverable via test block
- Fixed Zig 0.15 compatibility issues with root_module API changes
- Reduced build complexity from 25+ steps to 5 steps while maintaining all 83 tests
- Improved build performance and maintainability by centralizing test organization
- Added activeFieldSize function demonstrating inline else in switch statements
- Added test showing inline else generates specialized code for union variants at compile time
- Added ECS-inspired metaprogramming test using inline for and @typeInfo() introspection
- Test validates component type matching with different field counts (Health: 2, Position: 3, Damage: 1)
- Demonstrates Zig's powerful compile-time metaprogramming capabilities for generic component systems
The PATH detection was incorrectly flagging properly configured shells
because the 'just' subprocess environment may differ from the actual
shell environment. Updated to provide more accurate feedback about
PATH ordering and acknowledge that subprocess PATH may not reflect
the user's actual shell configuration.
The test-zls-fix task verifies that:
- Symlink to actual Zig binary exists
- 'zig env' works with corrected PATH (what ZLS executes)
- Standard library is found correctly
- No ZLS config file exists (using defaults)
- Basic Zig compilation works
This addresses the concern about testing the fix before committing.
ZLS was failing to find the Zig standard library because it couldn't execute
'zig env' through the asdf shim. The shim lacks proper environment context
when called by ZLS, resulting in error code 126.
This fix creates a direct symlink from ~/.local/bin/zig to the actual Zig
binary (bypassing the asdf shim) and removes any ZLS config files to use
defaults. ZLS can then successfully execute 'zig env' and locate the
standard library.
Changes:
- Add fix-zls task that creates symlink without config file
- Add check-zls task with PATH ordering guidance
- Add clean-all task for workspace-wide cleanup
- Add .tool-versions for consistent Zig version
- Remove dependency on zls.json configuration
The symlink approach is cleaner than config files and works automatically
with any Zig version managed by asdf.
Added comprehensive reference links at the beginning of the file:
Core reference sources:
- https://en.wikipedia.org/wiki/Floating-point_arithmetic#Accuracy_problems
- https://www.exploringbinary.com/why-0-point-1-does-not-exist-in-floating-point/
- https://www.exploringbinary.com/floating-point-questions-are-endless-on-stackoverflow-com/
- https://docs.python.org/3/tutorial/floatingpoint.html
- https://floating-point-gui.de/basic/
Additional educational resources:
- https://www.baeldung.com/cs/floating-point-numbers-inaccuracy
- https://riskledger.com/resources/floating-point-numbers
- https://www.johndcook.com/blog/2025/06/27/most-ints-are-not-floats/
- https://leancrew.com/all-this/2025/06/in-defense-of-floating-point/
These links provide comprehensive theoretical foundation and educational context
for understanding IEEE 754 floating-point precision limitations demonstrated
in the test cases. They serve as valuable resources covering both the problems
and practical approaches to floating-point arithmetic.
The test file now properly credits its inspiration sources and provides
readers with authoritative references for deeper understanding of the
concepts being demonstrated.
Replaced adaptive testing with two distinct test sets as requested:
1. **Imprecise decimal fraction cases** (non-zero tolerance):
- 0.09+0.01≠0.1, 0.1+0.2≠0.3, 0.3+0.6≠0.9, etc.
- All cases verified to NOT exact match (expect(result != expected))
- Then verified to be approximately equal (expectApproxEqRel)
- Shows precision errors for problematic IEEE 754 representations
2. **Exact decimal fraction cases** (zero tolerance):
- 0.58+0.42=1.0, 0.5+0.25=0.75, 0.125+0.375=0.5, etc.
- All cases use exact equality (expectEqual)
- Demonstrates values that ARE exactly representable in IEEE 754
Benefits:
- Clear separation: no adaptive logic, predictable test behavior
- Educational: shows which decimal operations are exact vs approximate
- Robust: ensures non-zero tolerance tests genuinely need tolerance
- Comprehensive: covers both sides of IEEE 754 precision behavior
Test suite now has 16 test cases with clear exact/approximate distinction,
providing complete coverage of floating-point precision concepts.
Enhanced the test suite with new floating-point precision concepts learned
from analyzing ../../yard-rs/rust_cpp/src/run_cpp.rs:
New test cases added:
1. **Division precision and scale dependency**
- Shows how scaling affects division precision (63/9 vs 0.063/0.009)
- Demonstrates accumulated precision errors in scaled operations
- Tests integer casting behavior with precision loss
2. **Comprehensive decimal fraction precision issues**
- Extended test cases: 0.7+0.1, 2.2+1.1, 0.58+0.42, etc.
- Adaptive testing: handles both exact and approximate cases
- Shows precision errors for problematic decimal representations
- Identifies cases that are exactly representable in IEEE 754
Key insights discovered:
- **Scale-dependent precision**: Same mathematical operation can have different
precision depending on the scale of operands
- **Exact representability**: Some decimal combinations (like 0.58+0.42=1.0)
are exactly representable in IEEE 754
- **Cross-language consistency**: IEEE 754 behavior is consistent across languages
Test suite now has 15 comprehensive test cases covering:
- Basic precision issues, associative/distributive failures
- Scale-dependent precision, division precision
- Comprehensive decimal fraction testing with adaptive logic
- All edge cases and special values
This provides a complete educational resource for understanding IEEE 754
floating-point precision behavior and its practical implications.
Streamlined the test to demonstrate the essential floating-point precision issue:
Test flow:
1. expect(sum != 1.0) // Proves precision loss occurred
2. expectApproxEqRel(sum, 1.0) // Shows it's close to correct answer
3. expectEqual(sum, 0.9999999999999999) // Exact match with IEEE 754 result
Key improvements:
- Removed Python comparison - focuses purely on Zig/IEEE 754 behavior
- Clean three-step verification: not exact, approximately correct, exact match
- Demonstrates both the problem (precision loss) and solution (tolerance)
- Shows the specific IEEE 754 representation that results from the calculation
This provides a clear, focused demonstration of why floating-point arithmetic
requires tolerance-based comparisons for decimal operations.
Corrected the test logic to properly demonstrate floating-point precision issues:
Before (incorrect):
- Compared imprecise result with another imprecise result
- Used expected_python_result as if it were the correct answer
After (correct):
- Compare actual result (0.9999999999999999) with mathematically expected result (1.0)
- Show that both Zig and Python produce the same imprecise result due to IEEE 754
- Both imprecise results are approximately equal to the correct result (1.0)
Key insight:
- Mathematical expectation: 0.1 × 10 = 1.0
- IEEE 754 reality: 0.1 × 10 ≈ 0.9999999999999999
- Test verifies: actual != expected (precision loss) AND actual ≈ expected (within tolerance)
This better demonstrates why floating-point arithmetic requires tolerance-based
comparisons for decimal operations that can't be exactly represented in binary.
Ensures that floating-point precision issues are actually occurring by
verifying values don't exact match before testing approximate equality.
Changes:
- Added expect(result != expected) before expectApproxEqRel() calls
- Confirms precision errors are genuinely present, not masked by tolerance
- Strengthens test reliability by proving inexact arithmetic occurs
- Removed redundant check for identical IEEE 754 representations
Test robustness:
- 8 tests with non-zero tolerance now verify exact inequality first
- 6 tests with exact equality remain unchanged
- All 14 tests pass, demonstrating both exact and approximate behaviors
- Better educational value showing when precision loss actually happens
This ensures the test suite accurately demonstrates IEEE 754 floating-point
precision limitations rather than just assuming they occur.
This commit refines the floating-point precision test suite to use exact
equality for tests that don't actually need tolerance, while maintaining
approximate equality for tests that genuinely require it.
Test Classification:
- 6 tests (43%) now use exact equality where appropriate:
* associative/distributive property tests (adaptive: exact if equal, approx if not)
* rounding behavior mathematical properties (truncation relationships)
* large number precision loss (complete loss of small additions)
* special values (IEEE 754 guarantees like 0.0 == -0.0)
* denormalized numbers (boolean property checks)
- 8 tests (57%) still require approximate equality:
* decimal arithmetic that can't be represented exactly (0.1 + 0.2 ≈ 0.3)
* multiplication precision issues (4.35 × 100 ≈ 435.0)
* accumulated precision errors in complex calculations
* financial calculation precision loss
* comparison operations with problematic decimal cases
Benefits:
- More precise testing distinguishes deterministic vs approximate operations
- Better educational value showing when floating-point is exact vs approximate
- Adaptive logic handles both exact and approximate cases dynamically
- Maintains robustness where genuine precision issues occur
All 14 test cases pass, demonstrating IEEE 754 floating-point behavior
accurately while using the most appropriate assertion method for each case.
Extended string_literals.zig to include @embedFile functionality with a
focused test that demonstrates the key relationship between @embedFile
and multiline string literals:
- Added single @embedFile test showing compile-time file embedding
- Demonstrates embedding the source file itself for clean self-reference
- Highlights key distinction: @embedFile for external files vs multiline strings for inline content
- Both features provide zero runtime cost with compile-time resolution
- Maintains focused approach with only 5 total tests (4 multiline + 1 @embedFile)
This addition showcases complementary Zig features for handling multi-line
text content without bloating the test suite with redundant cases.
Reduced string_literals.zig test suite from 13 exhaustive tests to 4
essential tests that demonstrate the most valuable aspects of Zig
multiline string literals:
- Fundamental behavior: direct equivalence to regular strings with improved syntax
- Primary benefit: raw backslash handling eliminates escape sequence complexity
- Real-world application: template and code generation use cases
- Important quirk: automatic preservation of line-ending whitespace
This targeted approach emphasizes practical knowledge over comprehensive
coverage, making the test suite more maintainable and educational.
- Added a new `just fmt` command to format all Rust projects in the `yard-rs` directory.
- The command follows the same pattern as `just clean`, iterating over each project and running `cargo fmt`.
- Verified the command works by running it and checking the output.
🤖 Generated with [opencode](https://opencode.ai)
Co-Authored-By: opencode <noreply@opencode.ai>
- Fully restored golden rules in bullet-point format\n- Preserved all repository-specific content\n- Added detailed workflow commands from justfiles\n- Included CI pipeline details from workflows\n- Maintained project structure and code style guidelines\n- Added toolchain management section\n- Kept existing commit standards