Repository navigation
DM-56839: Update vendored ERFA and some wcsLib 8 fixes - #100
Merged
Merged
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #100 +/- ##
=======================================
Coverage 63.02% 63.03%
=======================================
Files 84 84
Lines 97005 97006 +1
Branches 30759 30760 +1
=======================================
+ Hits 61142 61148 +6
+ Misses 19492 19483 -9
- Partials 16371 16375 +4 ☔ View full report in Codecov by Harness. |
- QSC projection (astQSCfwd): within about 0.008 degrees of the
centre of face 4 (phi = -90, theta = 0) the forward projection
switches to a small-angle formula, where the longitude offset
from the face centre was computed as p *= (90 + p)*D2R, i.e.
multiplied by the longitude itself, instead of p = (90 + p)*D2R.
The other faces had the right form. At phi = -90.005, theta = 0,
x came out as 269.538 instead of 269.995 degrees, so a point
near the face centre was put 0.46 degrees from where it belongs.
Upstream wcslib 3.0 rewrote qscs2x without the slip (it has no
CHANGES entry); the result now agrees with wcslib 8.10.
- New test ast_tester/testwcsmap.c, which compares WcsMap
projections with upstream wcslib 8.10 at the points where the
fork has differed from it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DidLSReaHyVFnUCCMn54Xw
- HPX polar zone, odd H (astHPXfwd, astHPXrev): the facet centre was
computed with floor(... + 1/2), an integer division that adds
nothing, where upstream adds 0.5. With PV2_1=3, PV2_2=3 the south
pole at phi = -180 went to x = -240 instead of -120, and with
PV2_1=PV2_2=4, phi = -131.9 at the pole went to x = -180 instead
of -90. The default H = 4, K = 3 was not affected.
- HPX reverse, latitude range (astHPXrev, upstream 4.7): the polar
zone was cut off at |y| = 90, which is right only for H = 4. It
now extends to (K+1)/2 facets of 180/H degrees, so with
PV2_1=PV2_2=3 the point (x, y) = (-0.4, -119.5) is accepted.
- HPX reverse, facet edge (astHPXrev, upstream 4.7 and 4.20): a
point is on a polar facet when (x - xc)/sigma is less than the
facet half-width 180/H; the test now allows 1e-12 degrees for
rounding, as upstream does, so the reverse of the forward of
(90, -89.26) with the default H and K is no longer rejected.
- HPX reverse at the pole (astHPXrev, upstream 4.3): sigma = 0 was
rejected, so the forward projection of either pole had no
reverse. As upstream, the apex of each facet now maps back to the
pole, at the facet's central longitude.
The wanted values in testwcsmap.c are wcslib 8.10's hpxs2x and
hpxx2s outputs.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DidLSReaHyVFnUCCMn54Xw
…tream does
- ZPN projection (astZPNfwd): the forward projection reports a point
as bad when its native colatitude is past the turning point of
the radial polynomial (w[0]), where the projection folds back on
itself. The test also required the polynomial degree to exceed 2.
That condition was a guard against the uninitialised w[0] that
7b67e1b fixed: w[0] is now PI for degree < 2 (no turning point)
and the turning point itself for degree 2, so the guard only
hid the far-side test for quadratics. Upstream wcslib applies it
at every degree.
With PV2_1=1.27118, PV2_2=-0.210643 the point (5.4085552,
-89.2063216) was projected to (10.34, -109.25) degrees, which
the reverse maps to a different point on the near side; it is
now bad, as in wcslib 8.10.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DidLSReaHyVFnUCCMn54Xw
….22)
- PCO projection (astPCOfwd): y is r0*(cot(theta)*(1 - cos(phi*
sin(theta))) + theta). Close to the equator cot(theta) is very
large and 1 - cos(...) cancels to a few bits, so y lost most of
its precision: at (phi, theta) = (90, 1e-9) it came out as
1.0e-9 degrees, where the true value is 2.23e-9, and at
(-170, -5e-5) x and y were wrong by 2e-10 and 4e-10 degrees.
For |theta| < 1e-4 degrees the forward projection now uses the
series wcslib 4.22 introduced, x = w[0]*phi*cos(theta) and
y = (w[0] + w[3]*x*x)*theta, where w[0] = r0*D2R and the new
constant w[3] = D2R/(2*r0).
The reverse is unchanged, as it is in wcslib 8.10.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DidLSReaHyVFnUCCMn54Xw
- COP projection (astCOPfwd): at either pole the radius came from
r = Y0 - r0*cos(delta)*tan(theta - sigma), which is zero at the
pole on the standard parallels' side only up to rounding, so the
apex of the cone was put up to 1e-14 degrees off (0, Y0). The
other pole gives the same expression the same near-zero value,
and r*C < 0 is decided by rounding, so it was accepted: with
PV2_1=60, PV2_2=0 the south pole projected onto the apex, and
the reverse of that is the north pole.
As in wcslib 4.22, a pole now has r = 0 exactly, and is bad when
it is on the other side of the equator from sigma (PV2_1).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DidLSReaHyVFnUCCMn54Xw
- wcsmath.h defined D2R as PI/180.0, R2D as 180.0/PI and SQRT2INV as
1.0/SQRT2 without parentheses, so an expression such as theta*D2R
expanded to (theta*PI)/180.0 rather than theta*(PI/180.0), and
x/D2R would have been (x/PI)/180.0. The first is the same
arithmetic in a different order, so the results differed from
upstream's in the last bit; wcslib 8.7 added the parentheses.
Most projections now give results that differ in the last bit
from before, and the difference is magnified where the projection
is steep: MER at (0, 89.999999) moves from y = 1063.2311752544 to
1063.2311737966 degrees, which is wcslib 8.10's value. Used in
wcslib/proj.c, wcstrig.c and tpn.c.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DidLSReaHyVFnUCCMn54Xw
…mits
- WcsMap reverse (Map in wcsmap.c): a native longitude or latitude
returned by a reverse projection just past a limit of the accepted
range was rejected unless it was within one ULP, an allowance made
so that the validity of a WCS would not depend on FMA contraction.
Rounding in the projections themselves lands boundary points
further out than that: the reverse of a forward projection on the
-180 meridian comes back about 9e-14 degrees below -180 for PAR,
MOL and PCO (on a grid of 400001 latitudes, 11%, 22% and 8% of
the points), and the reverse of a point just past the antipode of
ARC lands a few ULP beyond -90. AST returned bad for all of these.
The points that are still rejected, all within five degrees of a
pole, are beyond wcslib's tolerance too.
Upstream wcslib's prjbchk sets a native coordinate within a
per-projection tolerance of a limit to the limit and rejects one
beyond it. WcsMap now does the same with wcslib 8.10's tolerances,
held in a new column of the projection table: 1e-13 degrees for
most projections, 2e-13 for SZP, 1e-12 for SFL (and GLS), PAR,
PCO, HPX and XPH, and 1e-11 for BON and MOL. This covers the FMA
case the one-ULP allowance was written for, and matching wcslib
is less confusing for anyone comparing AST with other FITS-WCS
software.
AST keeps its half-open upper longitude limit: a value at or past
the upper limit is the wrap of the lower one and is still clipped,
so that a whole-sky grid does not map two pixels to one meridian.
The tolerance applies at the lower longitude limit and at both
latitude limits.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DidLSReaHyVFnUCCMn54Xw
timj
force-pushed
the
u/timj/DM-56839-vendored
branch
from
October 28, 2026 15:29
ed81343 to
98dc7c0
Compare
- erfa/ is replaced by ERFA v2.0.1-12-g1a8044c: every source file AST
already carried, erfa.h, erfam.h and the top-level LICENSE, INFO,
README.rst and RELEASE.rst, copied unmodified. AST's copy was ERFA
1.3.0. The new erfadatextra.c, erfadatextra.h and erfaextra.h hold
the leap-second table that eraDat now reads through eraDatini, in
thread-local storage; erfadatextra.c is included in palwrap.c and
its three functions (eraDatini, eraGetLeapSeconds,
eraSetLeapSeconds) are renamed in erfa2ast.h, so libast_pal still
exports no unprefixed era symbol. Makefile.am lists the new files
and no longer lists erfa/00READ.ME, which does not exist.
- erfam.h: ERFA_DAU is the IAU 2012 astronomical unit,
149597870.7e3 m (was 149597870e3), ERFA_AULT is derived from it
(499.0047838... s, was 499.004782) and ERFA_DNINT returns +0.0
rather than -0.0 for an argument in (-0.5, 0).
palPvobs divides by ERFA_DAU to give the observer's position and
velocity in au, and SpecMap's topocentric correction converted that
velocity back with its own 149.597870e6 km per au, so with this
commit alone the Earth-rotation velocity is 4.7e-9 of itself too
small (about 1.5e-3 Hz at 200 GHz), and the CLASS spectral wcsconv
fixtures and one SpecMap transform oracle fail. A later commit
makes SpecMap use the same au, after which the correction is what it
was with ERFA 1.3.
ERFA_DNINT reaches AST only through eraD2tf, which rounds
magnitudes and so never passes it a negative argument; formatting
is unchanged.
- Code changes among the files AST compiles, beyond comments,
copyright years and a final bare return: dat.c (table year 2016
to 2023, table moved behind eraDatini; Delta(AT) unchanged, last
entry 2017-01-01, 37 s); jd2cal.c and jdcalf.c (compensated
summation); the split-date time-scale functions (taitt, taiut1,
taiutc, tcbtdb, tcgtt, tdbtcb, tdbtt, tttai, tttcg, tttdb, ttut1,
ut1tai, ut1tt, ut1utc, utctai), which now apply the correction to
the part with the larger magnitude rather than the larger value
(the same part for AST's 2400000.5 + MJD form); d2dtf.c (leap
second detected as |dleap| > 0.5); p06e.c (sign of one
coefficient of an output AST does not use); pb06.c (rewritten);
pvstar.c and starpv.c (variable names, and pvstar no longer
rejects w < 0 separately); and eors.c, dtf2d.c, pnm06a.c and
starpm.c, whose changes are literals and names only.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DidLSReaHyVFnUCCMn54Xw
- SpecMap's topocentric velocity correction (TopoVel, used by the
TPF2HL and HLF2TP conversions and by SpecFrame) takes the
observer's Earth-rotation velocity from palPvobs in au/s and
converted it to km/s with 149.597870e6 km per au. palPvobs divides
by ERFA_DAU, which ERFA 2.0 changed to the IAU 2012 value of
149597870.7 km, so after the ERFA update the two no longer matched
and the velocity came out 4.7e-9 of itself too small (about 1.5e-3
Hz at 200 GHz). TopoVel now converts with ERFA_DAU itself, from
erfam.h, so the two cannot differ, and the correction is what it
was before the ERFA update: the CLASS spectral wcsconv fixtures and
the SpecMap transform oracle pass again.
The heliocentric and barycentric velocities convert ERFA's
eraEpv00 output, which does not depend on ERFA_DAU, and are
unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DidLSReaHyVFnUCCMn54Xw
- SlaMap's FK45Z and FK54Z conversions call ERFA's eraFk45z and
eraFk54z in place of PAL's palFk45z and palFk54z. fk45z.c,
fk54z.c and fk524.c (which eraFk54z calls), which AST's copy of
ERFA did not have, are copied unmodified from ERFA
v2.0.1-12-g1a8044c, included in palwrap.c, listed in Makefile.am
and renamed in erfa2ast.h.
- FK5 to FK4 changes results away from B1950. PAL's C palFk54z
applied the fictitious FK4 proper motion of an object fixed in FK5
linearly in RA and Dec. The Fortran SLALIB original, sla_FK54Z,
called sla_PM, which steps the Cartesian unit vector along the
tangential motion and converts back, and eraFk54z is that same
algorithm, so this restores SLALIB's behaviour. The linear step in
RA fails for a point that the fictitious motion (at most 2.4e-8
radians, 5 mas, per year) carries close to a pole: there the result
changes by up to the size of the motion itself, 1.4e-7 radians
(28 mas) at B1980 and 1.6e-6 radians (0.3 arcsec) at B2050 in a
scan dense near both poles. Elsewhere the change is far smaller,
1e-14 radians at (1.0, 0.5) for B1980. At B1950 the two agree to
rounding. SlaMap's FK45Z and FK54Z conversions use the FK5-to-FK4
routine in one direction each.
- FK4 to FK5 agrees with palFk45z to rounding.
- testslamap checks FK54Z and FK45Z against eraFk54z and eraFk45z
computed with upstream ERFA 2.0.1; the B1980 FK54Z case near the
south pole failed by 7.1e-10 radians in RA before this change.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DidLSReaHyVFnUCCMn54Xw
…tream 4.7)
- HPX projection (astHPXfwd): in the polar zone the facet arithmetic
places native longitude +180 beyond x = 180, outside the projection
plane: with the default H and K, (180, 90) went to x = 225 and
(180, 60) to x = 196.47. WcsMap passes +180 through unchanged
(palDrange maps only values beyond pi), and +180 is common, for
instance on the meridian behind the reference point of a SphMap.
wcslib 4.7 folds such an x back to 360 - x, which puts the point on
the facet it belongs to (x = 135 and 163.53); this does the same.
The reverse of such a point gives longitude +180, which WcsMap's
half-open longitude range still rejects, as it does for every
projection.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DidLSReaHyVFnUCCMn54Xw
- The transform oracles (ast_tester/fixtures/oracle/*.oracle) are
updated where, and only where, this branch changes the library's
output. Each file is the committed version plus the difference
between the output of the branch point (c6c6075) and of this
branch, both built on the same host with the same flags, so values
captured on another platform are kept wherever this branch does not
move them. The simplify oracle's sections for fixtures added since
it was last generated are not added here.
Every changed oracle section belongs to a fixture that goes through
a WcsMap (most of them: the D2R parenthesisation moves the last
bits, up to 5e-10 relative) or an FK4 conversion away from B1950
(palFk54z through ERFA: timj.ast at B2002 moves by 4.5e-8 pixels).
No wcsconv reference changes: with SpecMap using the same au as
palPvobs, the CLASS spectral headers give the same output as before.
- The grid SVG references under fixtures/plot/expected are not
changed. The grid tests compare only the text labels, which do not
move; four plots' polylines do (HPX from the HPX fixes and the
WcsMap tolerance, COBE, SCP and TSC from the D2R change), but those
references already differed from this host's output before this
branch, so regenerating them here would replace another platform's
capture.
- ast.news describes the wcslib projection fixes, the WcsMap
tolerance, ERFA 2.0.1 and the FK5 to FK4 change.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DidLSReaHyVFnUCCMn54Xw
- The MER near-pole case and the y coordinate of the COP apex cases
compared values that go through libm (log, tan) with a tolerance of
zero, against wanted values computed on macOS, so they could fail
on a platform whose libm rounds differently. MER now allows 1e-9
degrees, still far below the 1.5e-6 the unparenthesised D2R gave,
and the COP apex y allows 1e-12. The COP apex x stays exact: it is
zero by construction, and the old code put it 1e-14 off. Both
cases still fail with their fixes reverted.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DidLSReaHyVFnUCCMn54Xw
AddSpecCvt copied the whole argument array for a conversion, which for the conversions to and from heliocentric frequency is one element longer than the documented argument list, so astSpecAdd read past the end of the caller's array. The new C-only test testspecmap passes TPF2HL its six documented arguments in an array of that size, which AddressSanitizer reports as a stack-buffer-overflow without this change. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DidLSReaHyVFnUCCMn54Xw
The reverse projection took only sigma == 0 as the pole, as upstream wcslib does. A WcsMap converts x and y to radians and back, which for some H and K (3 and 3, 3 and 1, 3 and 6, 6 and 1, among others) moves the pole's y by a few ULP: sigma comes out about 1e-16, and dividing x - xc by it rejects the point, or y lands just beyond the polar zone. Both now count as the pole, with the 1e-12 degree margin the projection already uses for facet edges. The points left rejected at a pole are those the forward projection places at x = +180, which WcsMap's half-open longitude range rejects by design. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DidLSReaHyVFnUCCMn54Xw
Every other ERFA function is renamed astEra<name>; eraZr alone had a stray "n". libast_pal exports astEraZr in place of astEranZr, and nothing outside erfa2ast.h refers to either name. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DidLSReaHyVFnUCCMn54Xw
palDe2h, palDh2e, palDs2tp, palDtp2s, palDtps2c and palFk524 have no caller in AST, and palFk45z and palFk54z have none now that SlaMap calls eraFk45z and eraFk54z. Remove them, with their renames in pal2ast.h. The remaining files in pal/ are unchanged from upstream PAL. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DidLSReaHyVFnUCCMn54Xw
None of the PAL routines AST carries has changed in upstream PAL
since AST last updated (0.9.7); the light-deflection changes to
palAmpqk and palMapqkz from 2016 were already here. What has changed
is copied from PAL master (v0.9.10-9-g75017db):
- pal.h comments out the prototypes of routines PAL does not
implement (0.9.10). AST's own pal.h carries a copy of the same
prototypes and is updated to match.
- palOne2One.c corrects the argument descriptions of palDbear and
an author's initials.
- pal1sofa.h gains the SOFA name of eraHd2ae, which upstream's palZd
uses.
Every file in pal/ is now identical to upstream PAL.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DidLSReaHyVFnUCCMn54Xw
timj
force-pushed
the
u/timj/DM-56839-vendored
branch
from
October 28, 2026 15:44
98dc7c0 to
5e550ba
Compare
timj
added a commit
to Starlink/starlink-ast-rs
that referenced
this pull request
Oct 28, 2026
C AST at 3d3f255f (Starlink/ast#100) carries wcslib 8.10's projection fixes, ERFA 2.0.1, SlaMap's FK4/FK5 conversions through ERFA and the removal of the PAL routines AST does not call. - vendor/ is re-copied from that commit, keeping the proj.c include and the astSizeOf stub, its only local changes (vendor/README.md). - SlaMap's FK45Z and FK54Z call astEraFk45z and astEraFk54z, as C now does; the test-only PAL horizon wrappers, whose C is gone, are removed. testslamap.c's new cases are fk4_fk5_match_erfa. - WcsMap's reverse projection accepts a native coordinate past a limit by wcslib's per-projection tolerance, as C does since 3062dca8, in place of one ULP. testwcsmap.c is ported whole as test_wcsmap_edges.rs; its ARC antipode case failed before. - SpecMap converts the observer velocity from palPvobs with ERFA's ERFA_DAU, the au palPvobs uses. testspecmap.c's TPF2HL case is topocentric_to_heliocentric_frequency, which failed by 6.9e-6 Hz before. - The three changed transform oracles are mirrored, and the eight probe corpora whose C values moved are regenerated; a build of the previous pin reproduces every one of them as committed, so each change is C's. The LSST oracle gets a probe of its own (lsst_probe.c) in place of hand-captured values from an older build, and matches C bit for bit. Two SINCOS_MERGE_LICENSED cases, AZEL to AZEL aligned in FK4, now match C exactly in a debug build and leave the list. - The MapMerge audit citations of slamap, specmap and wcsmap are re-anchored and every checklist is marked against the new pin. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
timj
added a commit
to Starlink/starlink-ast-rs
that referenced
this pull request
Oct 28, 2026
C AST at 3d3f255f (Starlink/ast#100) carries wcslib 8.10's projection fixes, ERFA 2.0.1, SlaMap's FK4/FK5 conversions through ERFA and the removal of the PAL routines AST does not call. - vendor/ is re-copied from that commit, keeping the proj.c include and the astSizeOf stub, its only local changes (vendor/README.md). - SlaMap's FK45Z and FK54Z call astEraFk45z and astEraFk54z, as C now does; the test-only PAL horizon wrappers, whose C is gone, are removed. testslamap.c's new cases are fk4_fk5_match_erfa. - WcsMap's reverse projection accepts a native coordinate past a limit by wcslib's per-projection tolerance, as C does since 3062dca8, in place of one ULP. testwcsmap.c is ported whole as test_wcsmap_edges.rs; its ARC antipode case failed before. - SpecMap converts the observer velocity from palPvobs with ERFA's ERFA_DAU, the au palPvobs uses. testspecmap.c's TPF2HL case is topocentric_to_heliocentric_frequency, which failed by 6.9e-6 Hz before. - The three changed transform oracles are mirrored, and the eight probe corpora whose C values moved are regenerated; a build of the previous pin reproduces every one of them as committed, so each change is C's. The LSST oracle gets a probe of its own (lsst_probe.c) in place of hand-captured values from an older build, and matches C bit for bit. Two SINCOS_MERGE_LICENSED cases, AZEL to AZEL aligned in FK4, now match C exactly in a debug build and leave the list. - The MapMerge audit citations of slamap, specmap and wcsmap are re-anchored and every checklist is marked against the new pin. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
timj
added a commit
to Starlink/starlink-ast-rs
that referenced
this pull request
Oct 28, 2026
C AST at 3d3f255f (Starlink/ast#100) carries wcslib 8.10's projection fixes, ERFA 2.0.1, SlaMap's FK4/FK5 conversions through ERFA and the removal of the PAL routines AST does not call. - vendor/ is re-copied from that commit, keeping the proj.c include and the astSizeOf stub, its only local changes (vendor/README.md). - SlaMap's FK45Z and FK54Z call astEraFk45z and astEraFk54z, as C now does; the test-only PAL horizon wrappers, whose C is gone, are removed. testslamap.c's new cases are fk4_fk5_match_erfa. - WcsMap's reverse projection accepts a native coordinate past a limit by wcslib's per-projection tolerance, as C does since 3062dca8, in place of one ULP. testwcsmap.c is ported whole as test_wcsmap_edges.rs; its ARC antipode case failed before. - SpecMap converts the observer velocity from palPvobs with ERFA's ERFA_DAU, the au palPvobs uses. testspecmap.c's TPF2HL case is topocentric_to_heliocentric_frequency, which failed by 6.9e-6 Hz before. - The three changed transform oracles are mirrored, and the eight probe corpora whose C values moved are regenerated; a build of the previous pin reproduces every one of them as committed, so each change is C's. The LSST oracle gets a probe of its own (lsst_probe.c) in place of hand-captured values from an older build, and matches C bit for bit. Two SINCOS_MERGE_LICENSED cases, AZEL to AZEL aligned in FK4, now match C exactly in a debug build and leave the list. - The MapMerge audit citations of slamap, specmap and wcsmap are re-anchored and every checklist is marked against the new pin. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.