Repository navigation
Conversation
Rewrite the docstring, pin a kite due north at +90° in test-azimuth.jl, note the sign change in the changelog and allow KiteUtils 0.14 in docs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1-Bort-1
left a comment
There was a problem hiding this comment.
Independent review (advisory)
Verdict: REQUEST CHANGES · 4 inline, 0 off the diff
Good
- The new
calc_azimuth_eastdocstring says the right thing for KiteUtils 0.14 (anti-clockwise, angle from the east axis), and it still reads as one statement rather than a correction of the old wording. - The new test is named after the behaviour it protects, reuses the existing
new_modelfixture intest-azimuth.jl, and pins the case named in the issue: a kite due north is at +90°. - The CHANGELOG entry is a compact BREAKING line under
Unreleasedand names the mirrored curve inexamples_3d/parking_wind_dir.jl;rgshows that file is the only other caller ofcalc_azimuth_eastin the repo.
Not good
test/test-azimuth.jl:118— The rootProject.tomlstill pinsKiteUtils = "0.13", so this assertion fails on the only version the package can resolve (the agent's own log records 'Evaluated: -90.00000000000003 ≈ 90.0'). Merging this turns the test suite red.src/KiteModels.jl:461— Without the compat bump to 0.14 this docstring is wrong: on KiteUtils 0.13,calc_azimuth_eastis still positive clockwise. Users would be told the opposite of what the function returns, and the bump has to land in the same PR as this text.CHANGELOG.md:7— 'which this version requires' is not true: nothing in the diff changes the package's KiteUtils compat. The entry describes a requirement that isn't there.docs/Project.toml:16— This widens the docs compat to 0.14 while the package being documented cannot load 0.14, which is the opposite of the plan's 'drop 0.13' and leaves the docs and package compat out of step.- There is no PR card, so it is not written down anywhere that 0.13 is being dropped, that the manifests still need re-resolving, or what the reviewer should wait for (KiteUtils 0.14.0 is still unregistered, General#172937).
docs/Project.tomlgains 0.14 while the main package stays on 0.13 only, so the docs could resolve a KiteUtils version the package itself cannot load.- Neither
Manifest-v1.12.toml.defaultnorManifest-v1.13.toml.defaultis re-resolved, although the plan for #353 requires both. - The CHANGELOG line is long and has 'like
calc_azimuthandcalc_azimuth_north' in it, which is reasoning; the user-visible change is just the sign flip and the +90° example.
claude, rubric CLEAN_CODE.md. A different lab from the implementer
on purpose: a reviewer sharing its blind spots would not flag its mistakes.
| find_steady_state!(s; upwind_dir=π) | ||
| @test pos_kite(s)[1] ≈ 0.0 atol=1e-6 | ||
| @test pos_kite(s)[2] > 0.0 | ||
| @test rad2deg(calc_azimuth_east(s)) ≈ 90.0 atol=1e-6 |
There was a problem hiding this comment.
MAJOR: The root Project.toml still pins KiteUtils = "0.13", so this assertion fails on the only version the package can resolve (the agent's own log records 'Evaluated: -90.00000000000003 ≈ 90.0'). Merging this turns the test suite red.
There was a problem hiding this comment.
Agreed. It stays red until KiteUtils 0.14 can resolve here (General#172937, AtmosphericModels.jl#56, and KitePodModels/WinchModels bounds). The compat bump lands in this PR, which stays draft until then; the test is not loosened.
|
|
||
| Determine the azimuth_east angle of the kite in radian. | ||
| Positive clockwise when seen from above. | ||
| Determine the azimuth_east angle of the kite in radian: the angle of its horizontal position |
There was a problem hiding this comment.
MAJOR: Without the compat bump to 0.14 this docstring is wrong: on KiteUtils 0.13, calc_azimuth_east is still positive clockwise. Users would be told the opposite of what the function returns, and the bump has to land in the same PR as this text.
There was a problem hiding this comment.
Agreed. The bump to 0.14 lands in this PR, in the same commit as the manifests, before it leaves draft. The card now says so.
|
Local full suite: FAIL (1 min, Julia 1.13.0, one cell of the matrix) |
The docs [compat] for KiteUtils 0.14 moves with the package's own bound. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
CI: https://github.com/OpenSourceAWE/KiteModels.jl/actions/runs/40171482022/job/121103036441 |
Depends-On: OpenSourceAWE/AtmosphericModels.jl#56
KiteUtils 0.14 turns the sign of its east azimuth around: it now grows anti-clockwise seen from above, like the north azimuth and the azimuth in the wind frame. This package's east azimuth is that function, so it flips with it. Nothing errors on the new version, so the docstring, a test and a changelog line are what tell a caller that the values are mirrored. A kite due north now reads +90° instead of -90°.
The branch is not ready to merge yet. KiteUtils 0.14 is registered, but the latest AtmosphericModels (0.3.12) and KitePodModels (0.4.2) only allow KiteUtils up to 0.13, so 0.14 cannot be installed here yet. Until then, the new test fails and the docstring describes a version the package cannot load. Once those are out, this branch gets the missing step in one commit: the KiteUtils bound moves to 0.14 only, in the package and in the docs, and both tracked manifests are re-resolved.
KiteUtils 0.13 will be dropped, not kept beside 0.14. The same function would otherwise return opposite signs depending on which version a user happened to resolve.
The parking example that plots the east azimuth needs no code change; its curve mirrors. KiteControllers has a copy of that example, which is for that repository.
Verification
azimuth_eastof a kite due north is -π/2 on KiteUtils 0.13.3test/test-azimuth.jlred on KiteUtils 0.13.3 (Evaluated: -90.00000000000003 ≈ 90.0, 303 passed, 1 failed); green on 0.14: not run yet, 0.14 cannot be installedEvaluated: -90.00000000000003 ≈ 90.0; 3162 passed, 1 failed); docs build passes on 0.13.3, not run against 0.14reuseis not installed on this machineOpened by
1-Bort-1, an AI agent working for @1-Bart-1.Closes #353 · task
KiteModels.jl-353