deps: Bump FSharp.Core from 10.1.202 to 10.1.203#454
Merged
Conversation
--- updated-dependencies: - dependency-name: FSharp.Core dependency-version: 10.1.203 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Contributor
Author
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
AceHack
added a commit
that referenced
this pull request
Apr 25, 2026
…459) Otto-268 follow-on: drain-log for the multi-class cascade PR #421 (post-merge follow-up to #409). Captures four finding classes in one follow-up: A. Node provisioning correctness (P1, CI/runtime): cross-file node-version pin drift; CI-vs-local divergence. B. Companion version alignment (P2, consistency): downstream stale-version reference. C. Otto-279 INVERSE — role-ref correction on current-state surface (operational substrate; NOT history-class). D. Downstream prose typos. Pattern observations: - Cross-file version-pin drift is a recurring CI-correctness class. Fix template: single canonical pin; all references read from it. Pre-commit-lint candidate: cross-file version-string compare. - Otto-279 INVERSE: history-class preserves names; current-state surfaces replace with role-refs. Both halves of the rule need uniform application. - Multi-finding-class cascades benefit from explicit per-class grouping in the drain-log. - Node provisioning is a high-leverage substrate-fix surface; same shape as Otto-114 forward-mirror compounding fix. URL → PR-number defensive pattern: capture URL from gh-pr-create output before arming auto-merge to avoid Dependabot-PR-number- collision (lesson from #454/#455 hazard earlier this tick).
AceHack
added a commit
that referenced
this pull request
Apr 25, 2026
…mini xref) Otto-268 follow-on: drain-log for the targeted single-finding cascade PR #428 (post-merge follow-up to parent #126 Grok CLI capability map). Captures one Gemini capability-map cross-reference truth-update. Per Otto-250 training-signal discipline. Pattern observations: 1. Cross-capability-map xref consistency is its own class. The repo has a growing family of CLI capability maps (Codex / Grok / Gemini / Claude Code) that form a related-document cluster needing joint cross-reference maintenance. Future doc-lint candidate: maintain manifest of related-document clusters and warn on edit-without-sweep. 2. Multi-CLI capability-map family is its own substrate pattern. Worth documenting in `_patterns.md`: when multiple capability maps cover overlapping but distinct CLIs, they form a cluster that benefits from shared structure (status taxonomy, parity- matrix shape, score-summary conventions) and joint cross-reference maintenance. 3. Targeted single-finding follow-ups are the cheapest cascade shape — 1 finding / 1 commit / 1 merge gate. Cascade-pattern amortized cost is dominated by the few-thread cascades. URL → PR-number defensive pattern continues (lesson from #454/#455 collision earlier this session).
AceHack
added a commit
that referenced
this pull request
Apr 25, 2026
…#460) * hygiene(#268+): pr-preservation drain-log for #428 (#126 follow-up Gemini xref) Otto-268 follow-on: drain-log for the targeted single-finding cascade PR #428 (post-merge follow-up to parent #126 Grok CLI capability map). Captures one Gemini capability-map cross-reference truth-update. Per Otto-250 training-signal discipline. Pattern observations: 1. Cross-capability-map xref consistency is its own class. The repo has a growing family of CLI capability maps (Codex / Grok / Gemini / Claude Code) that form a related-document cluster needing joint cross-reference maintenance. Future doc-lint candidate: maintain manifest of related-document clusters and warn on edit-without-sweep. 2. Multi-CLI capability-map family is its own substrate pattern. Worth documenting in `_patterns.md`: when multiple capability maps cover overlapping but distinct CLIs, they form a cluster that benefits from shared structure (status taxonomy, parity- matrix shape, score-summary conventions) and joint cross-reference maintenance. 3. Targeted single-finding follow-ups are the cheapest cascade shape — 1 finding / 1 commit / 1 merge gate. Cascade-pattern amortized cost is dominated by the few-thread cascades. URL → PR-number defensive pattern continues (lesson from #454/#455 collision earlier this session). * drain(#460 follow-up): fix capability-map xref + inline-code-span split Codex P2 + Copilot P1+P2 caught: - Inline code span split across newline (`docs/` on one line, `research/openai-codex-cli-capability-map.md` on the next) — reflowed to single-line so the path renders as one token. - Capability-map cluster listed `docs/research/codex-cli-first- class-2026-04-23.md` as if in-tree, but PR #231 is still OPEN at time of this drain-log so the file isn't yet in main. Reframed as 'pending merge of PR #231; will be in-tree once that PR lands' with the in-tree `openai-codex-cli-capability-map.md` listed first. Same forward-author-to-future-state-of-main drift class as #377 (38% stale-resolved density). The drain-log itself exhibits the pattern it documents — cited a forthcoming-but-not-yet-landed file as if already present. Inline-code-span line-wrap is the 5th observation of that class in the corpus (now: #191 / #195 / #219 / #423 / #460). At this density the doc-lint Class A (PR #465 BACKLOG) is high-leverage automation.
This was referenced Apr 25, 2026
AceHack
added a commit
that referenced
this pull request
Apr 25, 2026
…81) (#478) Aaron 2026-04-25 invoked the DST no-flakes rule (Otto-272 / Otto-248) after `Zeta.Tests.Formal.SharderInfoTheoreticTests.Uniform traffic: consistent-hash is already near-optimal` flaked 3 times in this session on unrelated PRs (#454, #458, #473). Investigation identified the root cause: three call sites in this test file used `HashCode.Combine k` for hashing, which by .NET design re-seeds per-process to deter hash flooding. The Jump-consistent-hash output depends on the input hash, so different processes assign the same keys to different shards — sometimes the load distribution lands within `< 1.2 max/avg ratio`, sometimes not. Fix: introduce `detHash` helper using `XxHash3.HashToUInt64` on the key's 4-byte little-endian representation. Same convention `src/Core/Sketch.fs` `AddBytes` already uses. Replace all three `HashCode.Combine` call sites (lines 54, 91, 119) with `detHash`. Verified determinism by running the test 3 times in separate processes — all pass with identical output (no longer process-randomized). Drop the previous `DST-exempt` comment on the `InfoTheoreticSharder does not make skew worse` test — the test is now DST-clean, not exempt. Replaced with a `DST-clean per Otto-281 fix` comment that names the fix and the trigger. This is the "real flake" class per Otto-248 — not a registry 502 or transient infra issue but an actual determinism violation in test code. Otto-272 DST discipline applies: fix the flake, capture the reproduction, prevent the compounding. Other `HashCode.Combine` sites still in the codebase (production code in `src/Core/Sketch.fs`, `src/Core/Shard.fs`, `src/Core/NovelMathExt.fs`; one test in `tests/Tests.FSharp/Sketches/CountMin.Tests.fs`) are intentionally left alone in this PR — they are either not flaking under current observation or have different determinism contracts. A separate audit can sweep them if/when they become a problem.
AceHack
added a commit
that referenced
this pull request
Apr 25, 2026
* ci(dependabot): group nuget + github-actions updates per Otto-280 Per Aaron 2026-04-25 directive: ungrouped per-package PRs add noise to the drain queue when several packages bump in the same week (observed today with #454 / #455 / #457 / #458 — four separate PRs for one .NET servicing roll). Add groups stanza to both nuget and github-actions updates: - dotnet-runtime: System.* / Microsoft.* (servicing rolls cluster here, e.g. 10.0.6 → 10.0.7). - fsharp-and-tooling: FSharp.* / FsCheck / xunit / Meziantou.* / Mono.*. - nuget-minor-patch: catch-all for everything else, minor/patch only. - github-actions-minor-patch: catch-all for action SHA-pins. Major bumps still open as individual PRs so they get scrutiny. Single CI run covers each cluster instead of N runs for N PRs. * ci(dependabot): exclude non-runtime Microsoft.* + role-ref attribution Two thread fixes on PR #473: 1. **`dotnet-runtime` group narrowed.** Add `exclude-patterns` for `Microsoft.NET.Test.Sdk` (test harness) and `Microsoft.Z3` (SMT solver) so they fall through to `nuget-minor-patch` rather than being mis-bundled into the .NET servicing-roll rollup. Caught by copilot-pull-request-reviewer. 2. **Attribution as role-ref.** Per Otto-279 (current-state surface = role-ref preferred over name), `.github/dependabot.yml` is a config file = current-state surface. Replace "Per Aaron Otto-280" with "Per maintainer Otto-280" in two comment locations. The tag (Otto-280) still carries traceability without using a contributor name in code/config. * ci(dependabot): keep Microsoft.NET.Test.Sdk in dotnet-runtime group Maintainer pushback 2026-04-25: `Microsoft.NET.Test.Sdk` actually ships on .NET's monthly servicing cadence (18.x track follows .NET 10), so it does belong with the runtime rollup. Excluding it would push it into the catch-all `nuget-minor-patch` group, which muddies the cluster more than the original concern. `Microsoft.Z3` (the MSR SMT solver) genuinely runs on independent solver-team timelines, so the exclusion stays. Net change vs prior commit on this branch: drop one entry from `exclude-patterns`, expand the rationale comment so a future reader sees why one is in and the other out (Otto-282 — the why-comment as mental-load optimization). * ci(dependabot): inline rationale, drop Otto-NNN reference Resolves PR #473 thread `PRRT_kwDOSF9kNM59liop`. Copilot flagged that `Otto-280` is a maintainer-memory tag with no in-repo discoverable artifact, leaving the comment durable only as long as the agent has its memory tree available. The reviewer is right: future readers (humans, contractors, third-party AI) cannot resolve `Otto-NNN` references. Per Otto-282 (write the WHY in-place), the right fix is to inline the rationale rather than cite a tag. Two comments updated: 1. Top NuGet rationale comment now self-explains: "ungrouped per-package PRs add noise to the drain queue when several packages bump in the same week — every System.* / Microsoft.* bump on a .NET monthly servicing roll would otherwise open as its own PR within hours of the others, multiplying CI runs and human review for what is effectively a single coordinated change." 2. GitHub Actions comment now points back to the NuGet group's rationale rather than re-citing the Otto-NNN tag. Net: same intent, no out-of-repo references required to parse the file.
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
1 participant
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.
Updated FSharp.Core from 10.1.202 to 10.1.203.
Release notes
Sourced from FSharp.Core's releases.
No release notes found for this version range.
Commits viewable in compare view.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)