🏡
  • ↔
  • →
  1. August 12, 2026
    1. 🔗 @binaryninja@infosec.exchange Sidekick 26.1 is out now! Sidekick finally has a proper home as a Binary Ninja mastodon

      Sidekick 26.1 is out now! Sidekick finally has a proper home as a Binary Ninja view, with each binary or project built around one continuing conversation with a lead agent. Also new: consolidated Resources, terminal access, transaction Revert, faster sidebars, lower first-response latency, and plenty more. Check out everything new in 26.1: https://sidekick.binary.ninja/blog/sidekick-26-1-a-proper-home-for- sidekick/

    2. 🔗 r/Harrogate Rock/Metal/Alternative rss

      Rock/Metal/Alternative | Bottom Of The Bottle, one of Harrogate longest running nights is back and celebrating its 25th Birthday!!! At Bilton Club in October, it's not to be missed 🖤 Tickets are £8 or £12 on the door Bilton club.co.uk submitted by /u/No-Chocolate9752
      [link] [comments]
      ---|---

    3. 🔗 meilisearch/arroy v0.8.0 release

      What's Changed

      Full Changelog : v0.6.3...v0.8.0

    4. 🔗 Barre/ZeroFS v2.2.3 release

      What's Changed

      Full Changelog : v2.2.2...v2.2.3

    5. 🔗 HexRaysSA/plugin-repository commits sync repo: +5 releases rss 
      sync repo: +5 releases

## New releases
- [IDA-MCP](https://github.com/captain-ai-hub/ida-mcp): 0.6.3, 0.6.2, 0.6.1
- [ida-codemode](https://github.com/hexrayssa/ida-codemode): 0.5.2, 0.5.1
    6. 🔗 r/Harrogate Beatiful video of old photos of Harrogate rss

      Beatiful video of old photos of Harrogate | submitted by /u/LowGuide2746
      [link] [comments]
      ---|---

    7. 🔗 r/Harrogate The perfect eclipse spot – am I missing something? rss

      I was on the stray yesterday at 7.15pm, and most of it was still in direct sunlight. You could certainly see the sun, relatively high in the sky, from most of Harrogate.

      There seems to be a lot of hand-wringing about where to stand to see the eclipse, going to Brimham Rocks, needing to be high up etc. Surely you can just stand on the Stray?

      submitted by /u/Much-Pickle-7047
      [link] [comments]

    8. 🔗 seanmonstar Micro: A trait for fluent Durations rss

      I dislike the pattern in some languages to create durations by multiplying constants. It feels like a concession when it cannot be expressed more nicely. There’s a tracking issue to add such constants in libstd.

      How about a trait instead? (I suggested it in the tracking issue a long time ago, but it’s lost in the noise). Rust traits are awesome. They can be implemented on any other type, even primitives, without them needing to cooperate.

      A trait could allow us to write 5.seconds(), or 200.milliseconds(), etc. I think this is much better. I would rather this exist instead. Maybe std::time::TimeUnits, or pick a better name, doesn’t matter which, just that it’s easy to import.

  2. August 11, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-08-11 rss

      IDA Plugin Updates on 2026-08-11

      New Releases:

      Activity:

      • CaeriusIDA
      • capa
        • b5864729: Sync capa-testfiles submodule
        • cd2621d8: Sync capa-testfiles submodule
      • disrobe
        • c11220a1: evidence: bound measured tool execution
        • 44ae17ba: workspace: centralize internal dependency versions
        • 12e0bde5: codec: centralize validated custom base64 decoding
        • df07ddf5: bytes: preserve migrated decoder edge contracts
        • 8d1b6f44: bytes: centralize bounded leb128 decoding
        • d477f752: recon: pin planted corpus finding counts
        • bc931932: chain: enforce typed metadata access
        • 64052f77: native: recover aarch64 binary16 scalar operations
        • a3813104: process: normalize short Windows tool paths
        • 1b2a6dc7: mobile: gate chain analysis helpers
        • c0f94e53: native: bound emitter traversal and ordered membership
        • 0f9d1e87: lua: bind opcode coverage to its table row
        • d74b930d: lua: record prometheus vmify corpus members
        • cc6de0ea: ruby: recover loop jumps and block attachments
      • grokathon
        • 84d5187b: Merge pull request #146 from theodorechapman/engine-demos
        • 268a4d4c: demos: restore the metrics evidence bench as a live hub page
        • 044ae685: demos: 3D engine bay, demo hub, MAME wiring, frozen classic demo
        • 259d93a9: Merge pull request #145 from theodorechapman/mute-game-audio
        • c13753b9: arcade: mute all game audio (breaks screen recordings)
      • ida-codemode
        • 5ba472f0: Merge pull request #21 from HexRaysSA/omp-support
        • d853a1d1: Add oh-my-pi support
        • e92f30f8: 0.5.2
        • 4dd6a603: Remove automated hcli plugin install magic
        • 976503bc: Bump ida-domain in ida-plugin.json
        • d54aa05d: Add hcli ida python explain-environment output to trace log
        • 96a2e441: 0.5.1
        • bce2569d: Bump hcli to 0.19.1
      • ida-pro-mcp
        • 18144409: Merge pull request #62 from GrecAndrei/swarm/paper-addressal
    2. 🔗 r/Harrogate Concentration of AirBnBs? rss

      Hi all,

      Under no illusion that Harrogate is utopian either but currently living inside the walls in York. It is of course gorgeous here but I’m really struggling with the lack of community and problems caused by the very high concentration of short term lets - they’re about 1 in 5 homes where I live.

      We are looking at buying in Harrogate rather than York because the housing market is slightly less compressed, it has much closer access to the Dales and Lakes and because I’m hoping the problem is not as apparent as York.

      I recognise Harrogate is still a tourist town - but with York having the highest tourist to resident ratio in England it dominates everything and is hard to escape. One look at the York reddit and you see it’s just people asking where to stay and what to eat!

      Basically - is the situation any better in Harrogate or am I being mad? Any other York locals made the move?

      submitted by /u/giuseppeh
      [link] [comments]

    3. 🔗 modem-dev/hunk v0.18.1 release

      What's Changed

      Full Changelog : v0.18.0...v0.18.1

    4. 🔗 r/Harrogate Hereford loses its title of biggest dildo buyers to this 'posh' Yorkshire town rss

      Hereford loses its title of biggest dildo buyers to this 'posh' Yorkshire town | submitted by /u/stankmanly
      [link] [comments]
      ---|---

    5. 🔗 HexRaysSA/ida-codemode v0.5.2 release

      Full Changelog : v0.5.1...v0.5.2

    6. 🔗 exe.dev OAuth for Agents rss

      Agents are unusually capable credential-handling tools. They read logs, execute commands, inspect files, call external services, and frequently operate on inputs that weren’t written by the person who deployed them.

      Giving an agent a long-lived secret means trusting not only the agent itself, but every tool it invokes, every file it reads, and every instruction it encounters, magnified by autonomous decision making.

      At exe, we believe agents should be able to access everything they need. That said, we do our best to avoid giving them persistent credentials that could leak.

      The safer model is to give the agent an identity and let it obtain narrowly scoped, short-lived access when it needs it. We’ve already built quite a few things around this idea, including our HTTPS proxy integration and our LLM integration, and recently we added support for Workload Identity Federation, or WIF.

      So what is WIF, and why is it a big deal?

      Years ago, back when I was working on Kubernetes, one of the most popular workflows users had was giving workloads running in k8s access to some cloud resource, say BigQuery.

      The typical solution up until that point was to create a service account, download its secret JSON file—which let you act as that service account—put it in a Secret in the k8s API, mount it into your pod, and then configure the cloud APIs to use it.

      It was a fairly suboptimal user experience. The secret had to be long-lived, could be leaked, needed to be rotated periodically, and there was really no way to know who or what was using it.

      Sounds familiar!

      Then the great security engineers working on Kubernetes realized that, by adding a few features to GCP and Kubernetes, they could use the Kubernetes API server as a trust boundary by having it act as an identity provider.

      In some ways, it already was one: the secrets were stored there, it already had a concept of service accounts, and it knew which workload was running as which identity.

      It worked by letting pods ask the k8s API server for a signed token (or JWT), which could then be presented to GCP to impersonate a service account. GCP would confirm that the k8s API server had signed it and that the cluster was within the configured trust boundary.

      If everything was configured correctly, your Kubernetes pods could now magically act as a GCP service account without ever being given a long-lived GCP credential. As a bonus, you could know exactly which pod was accessing which resources.

      Under the hood, this uses a lesser-known OAuth 2.0 flow called token exchange. One system issues a cryptographically signed token asserting who you are, and another system decides whether it trusts that issuer and is willing to exchange that token for one of its own.

      The method quickly spread, and all the major clouds shipped some version of it. Things like GitHub Actions adopted it too, letting you use GitHub’s identity to access cloud resources instead of storing long-lived cloud credentials.

      The new exe WIF integration follows suite and allows an agent (or workload) running on exe to use its identity to access resources on any cloud, or really anywhere, without needing a long-lived credential sitting around inside the VM.

      It is the same basic idea Kubernetes arrived at years ago: give the workload an identity, establish trust between systems, and mint short-lived access when it is actually needed instead of copying secrets everywhere.

      To use it in exe, go to the integrations page and create a new Identity Federation integration. You can then attach it to tags or individual VMs.

      You’ll need to configure the resource provider (GCP, AWS, etc) to consume the credentials. We have some guides for AWS and GCP already and more are coming soon.

      We would love to hear which services you would use this with and how we could improve the experience.

      Bonus - sequence diagram

      sequenceDiagram
    autonumber

    box Inside the exe VM
        actor Agent as Agent or workload
        participant Auth as Google auth library
    end

    box exe.dev
        participant Integration as Attached WIF integration
        participant Issuer as exe.dev OIDC issuer
    end

    box Google Cloud
        participant STS as Google STS
        participant IAM as IAM Credentials API
        participant BigQuery as BigQuery
    end

    Note over Integration,BigQuery: One-time setup<br/>The integration is attached to this VM<br/>Google trusts the exe.dev OIDC issuer<br/>The exe identity may impersonate the service account

    Agent->>Auth: Make a BigQuery request

    Note over Auth: Google auth loads the external account configuration<br/>and discovers the exe token endpoint

    Auth->>Integration: Request an exe identity token

    Note over Integration,Issuer: Request crosses from the VM<br/>into exe.dev

    Integration->>Integration: Verify the VM is allowed<br/>to use this integration
    Integration-->>Auth: Short-lived exe.dev OIDC token

    Note over Auth,STS: The VM sends the exe identity token<br/>directly to Google Cloud

    Auth->>STS: Exchange exe.dev OIDC token<br/>for a Google federated token

    opt Google does not have the signing keys cached
        STS->>Issuer: Fetch OIDC metadata and signing keys
        Issuer-->>STS: Issuer metadata and signing keys
    end

    STS->>STS: Verify signature, issuer,<br/>audience, expiry, and subject
    STS-->>Auth: Short-lived federated token

    Auth->>IAM: Request an access token for<br/>the configured service account
    IAM->>IAM: Verify the exe identity may<br/>impersonate the service account
    IAM-->>Auth: Short-lived service account access token

    Auth->>BigQuery: Call BigQuery with<br/>the service account access token
    BigQuery-->>Auth: Query response

    Auth-->>Agent: Return result
    7. 🔗 MetaBrainz Picard 3 beta 9 released rss

      Today, we have released MusicBrainz Picard 3 beta 9. This new versions brings several fixes over the last beta 7 (yes, we have skipped a beta number again), but also improvements and some new features.

      Since we are near a final release, we tried to focus on quality of life and UI/UX improvements, some changes in the UI are quite important (release preferences UI is a complete overhaul, and the new About dialog also got a nice refresh). Among the highlights are:

      • MetaBrainz OAuth2 support and various OAuth improvements and bug fixes
      • ISRC reading (from files or CD) and optional submission

      • Word diff for tags in the Metadata Box

      • UI/UX improvements: Redesign of some option pages, along re-organization and performance improvements

      • Plugin API improvements

      Download links and a detailed list of changes since Picard 3 beta 7 are available below. For a more detailed overview of what is new in Picard 3 please see the previous blog post Picard 3 Alpha Release.

      While we have all the major features implemented and with the latest bug fixes we are confident in the current code, this is still a pre-release and there might be bugs. If you use this, do so with care, backup your files and please report any issues you encounter.

      Some of the changes are also backward incompatible, hence we recommend you make a backup of your Picard.ini config file before trying the beta version. You can do so in Picard’s Options under Advanced > Maintenance.

      What’s new?

      Bugs

      • [PICARD-3349] - Copying the "new" column of a deleted tag in the metadata box copies the old value instead of empty
      • [PICARD-3351] - Options dialog is sometimes too big in height, impossible to access Make It So button
      • [PICARD-3352] - "Embed only a single front image" option can prevent images to be loaded
      • [PICARD-3357] - Some Cyanrip log files fail to be parsed
      • [PICARD-3365] - Debug options tooltips not shown
      • [PICARD-3368] - Removing multiple tags from multiple tracks is slow
      • [PICARD-3372] - Infinite OAuth retry loop when refresh token is revoked

      New Features

      • [PICARD-163] - ISRC support for lookup and submission
      • [PICARD-2482] - Submit ISRCs from CD
      • [PICARD-3355] - Allow plugins to unregister script variables and allow double registering
      • [PICARD-3356] - Expose plugin_persist storage in plugin v3 API
      • [PICARD-3358] - Add metadata tag context menu extension point and script variable title for plugins
      • [PICARD-3363] - Add option to allow complete albums to be auto removed after save
      • [PICARD-3367] - Add shell completion generation for picard-cli
      • [PICARD-3369] - Add a test playground for checking file names in local cover art options

      Improvements

      Download

      We appreciate your interest in trying this new version. Use with care, backup your files and please use theMetaBrainz community forums and the ticket system to give feedback and report bugs.

      For Windows and macOS you can download the beta version from the Picard download page. Linux users can run from source or try the beta channel of the Picard snap package.

      Picard is free software and the source code is available on GitHub.

      Acknowledgements

      Code contributions by Bob Swift, Bryan Roessler, Laurent Monin and Philipp Wolfer.
      Translations were updated by "ApeKattQuest, MonkeyPython" (Norwegian Bokmål), blueday (Swedish), Gsam3 (German), Marc Riera (Catalan), silentbird (Chinese (Traditional Han script)) and Vaclovas Intas (Lithuanian).
      Documentation updates by Bob Swift, Laurent Monin and Philipp Wolfer.

    8. 🔗 HexRaysSA/ida-codemode v0.5.1 release

      Full Changelog : v0.5.0...v0.5.1

    9. 🔗 HexRaysSA/plugin-repository commits sync repo: +1 release rss 
      sync repo: +1 release

## New releases
- [ida-codemode](https://github.com/hexrayssa/ida-codemode): 0.5.0
    10. 🔗 jellyfin/jellyfin 12.0 RC5 release

      🚀 Jellyfin Server 12.0 RC5

      We are pleased to announce the fifth release candidate preview release of Jellyfin 12.0!

      This is a preview release, intended for those interested in testing 12.0 before its final public release. We welcome testers to help find as many bugs as we can before the final release.

      As always, please ensure you stop your Jellyfin server and take a full backup before upgrading!

      A note about versioning

      Starting with this release, we are dropping the preceding10. from our versioning. Thus, 10.11.x -> [10.]12.x = 12.x. The reason is simple: at this point in the project, we don't envision a hard break in the API like we planned way back in the early days, and this version scheme was causing a lot of confusion amongst users about what a "major" release was. For more information, please see the RC1 release notes.

      What's new?

      The main goal of this release has been performance. 10.11.0 dropped a major backend rewrite, and while it was broadly functional, it had a lot of rough edges. This release seeks to polish out most of those rough edges and bring better performance to all users.

      There are many other small fixes, improvements, changes, and translations. See our draft release notes here or below for the full list of pull requests. You can also view the Web side changelog here.

      Note: You must be on Jellyfin 10.10.7+ or 10.11.x (ideally, 10.11.11) before upgrading! If you are not, the upgrade will fail. Ensure you upgrade to one of these versions first!

      Note: The initial load of Jellyfin 12.x will run a few migrations and will take several minutes. Please be patient and do not interrupt the process. You can leverage the (newly improved!) startup UI on your local network to see specific progress, or off-network to see general progress, by visiting the server URL in your web browser during startup.

      Note: If you install the RC, you should disable all external plugins and reinstall using the unstable plugin repository, or plugins may fail to load and cause unintended side effects.

      Installing

      This preview release is distributed in all our traditional forms, though not automatically via our Apt repository or latest tag.

      • For all non-Docker environments, you can find the files for manual download in our repository by selecting "Stable Preview" for your OS.
      • For Docker, you can pull the 12.0-rc5 or preview tags.

      What's Changed (since

      v12.0-rc4)

      New Contributors

      Full Changelog : v12.0-rc4...v12.0-rc5

    11. 🔗 backnotprop/plannotator v0.26.8 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.26.7 | Pinpoint targets any element on HTML pages, smarter hover labels, zero-scan hit testing
      v0.26.6 | Fixed empty environment variables in sandboxed sessions (Bun 1.3.14 builds)
      v0.26.5 | HTML pinpoint element annotations, durable annotate submissions, installer fallback for old git, vim HUD cursor fix
      v0.26.4 | Skill-menu hover jitter fix (same-day patch on v0.26.3)
      v0.26.3 | Skill references in comments with / or $, reachable remote session URLs, worktree switcher tooltips
      v0.26.2 | Single-file diff tabs render fully, no more silently dropped review files, light/dark theme pairs, palette-matched code blocks
      v0.26.1 | GitButler 0.22.0 compatibility via capability-probed JSON flags
      v0.26.0 | Edit Mode (suggest by editing the diff), Guided Review virtualization, colorblind theme, safe uninstall, installer opt-outs, OpenCode 2 support
      v0.25.1 | Codex no longer launches on review open, annotate-last follows the live conversation, pi-todos mirror, Claude Opus 5, abandoned-gate dismissal
      v0.25.0 | Vim keyboard controls, Approve with Notes, scriptable annotate gates, persistent Guided Reviews, memory and file-watching hardening
      v0.24.2 | Annotate YAML/JSON/TOML config files, XDG data directory support, Codex model catalog update, Cursor sandbox escape hatch
      v0.24.0 | PR/MR artifact gallery, GitButler review support, port ranges, expanded comment editor, OpenCode + Pi fixes

      What's New in v0.26.8

      This release rebuilds how annotations look and behave on HTML pages, and it is the largest change to the annotate surface since pinpoint mode shipped. Nine PRs landed, three of them from first-time contributors @Snaylaker, @atomicflag, and @monkhai.

      Placed comment markers replace inline highlights on HTML pages

      Annotating a raw HTML page used to write highlight markup directly into the page's own DOM. That caused two visible bugs: multi-paragraph selections often turned only their first paragraph blue, and on some pages the injected markup broke the page's layout. Both had the same root cause, so both are gone the same way: nothing writes into the page anymore.

      Annotations now appear as numbered comment bubbles projected onto a fixed overlay above the page. A bubble sits at the exact point you clicked, not a corner of the element, and it stays glued through scrolling, page re-renders, responsive reflows, and zoom. If the annotated element disappears or scrolls out of a clipped container, its bubble hides instead of floating over unrelated content, and it returns when the target does. Selections highlight through the same overlay, so highlights now always cover the full selection and can never disturb the page beneath.

      The bubbles are real buttons: click one, or click the highlighted text itself, to jump to that annotation in the panel. Highlights brighten on hover so you can tell they are clickable. Bubble numbers match the numbering in the feedback your agent receives, so "see comment 3" means the same thing on screen and in the session. Committed highlights still print; annotating with Cmd+P in mind works the way it did before.

      The implementation went through three adversarial review rounds, a 25-item QA gate with independent verification of every serious finding, and a follow-up hardening pass covering clipping, visibility, print, and per-frame performance on mutation-heavy pages.

      Shift-click selects multiple elements for one comment

      One comment can now cover several places on an HTML page. Make a pinpoint selection, hold Shift, and click more elements: each gains an outline and a chip in the composer, Shift-clicking a selected element removes it, and removing the first selection promotes the next one rather than cancelling the draft. Up to 16 additional targets ride on one comment, and after saving, every target shows a bubble carrying the same comment number. Feedback to the agent lists every selected element, so "these three buttons need the same fix" is one comment, not three.

      HTML sessions open minimal, and stale preferences reset

      Opening an HTML page to annotate now shows just the page: pinpoint input ready, tools hidden, sidebar and annotations drawer closed. Anything you change persists for your next HTML session, but only while you keep using HTML annotate. A preference untouched for a week expires back to these defaults, so a mode you tried once months ago never becomes a permanent surprise. Active users keep their setup; annotating refreshes the clock.

      Pages with their own Content-Security-Policy are now annotatable

      An HTML file carrying its own strict CSP meta tag (common in saved pages and generated reports) silently blocked the annotation script, leaving a page you could see but not annotate. The annotate viewer now removes the document's CSP meta tags before rendering. The iframe sandbox remains the security boundary, and the file on disk is untouched.

      OpenCode: Qwen3.6 no longer corrupts the planning prompt

      OpenCode sessions using Qwen3.6 hit a Jinja template conflict: Plannotator injected its planning instructions as multiple system-prompt parts, and Qwen's template mangled them. @atomicflag rewrote the injection to compose one consolidated system part. The review process surfaced a subtle evaluation-order bug and an escaping edge case, both fixed and regression-tested, and the QA gate then caught that the OpenCode 2 adapter still used the old multi-part path, so the fix now covers both OpenCode 1 and OpenCode 2 entry points.

      Plan position survives window refocus in vim mode

      Switching away from a plan review window and back again reset the vim cursor to the top of the document. @Snaylaker fixed the refocus path to preserve your position, so alt-tabbing to check something no longer costs you your place in a long plan.

      Additional Changes

      • File headers show a hover state in code review. Diff file headers now tint on hover with a short transition, signaling that the header is clickable (it collapses the file). Contributed by @monkhai in #1256.
      • The legacy self-hosting docs route redirects to the canonical docs site. #1255

      Install / Update

      macOS / Linux:

      curl -fsSL https://plannotator.ai/install.sh | bash

      Windows:

      irm https://plannotator.ai/install.ps1 | iex

      Claude Code Plugin: Run /plugin in Claude Code, find plannotator , and click "Update now".

      OpenCode: Clear cache and restart:

      rm -rf ~/.bun/install/cache/@plannotator

      Then in opencode.json:

      {
  "plugin": ["@plannotator/opencode@latest"]
}

      What's Changed

      • fix(vim): preserve plan position on refocus by @Snaylaker in #1252
      • Fix OpenCode plugin Jinja template corruption with Qwen3.6 by @atomicflag in #1114
      • feat(annotate): shift-click multi-element selection for raw-HTML pinpoint by @backnotprop in #1254
      • fix(marketing): redirect self-hosting guide to canonical docs by @backnotprop in #1255
      • feat(review): add file header hover state by @monkhai in #1256
      • feat(annotate): placed comment markers for raw-HTML annotation by @backnotprop in #1257
      • fix: QA-gate hardening for the v0.26.8 feature set by @backnotprop in #1258
      • fix(annotate): strip document-authored CSP meta tags that block the annotation bridge by @backnotprop in #1259
      • feat(annotate): minimal-by-default HTML sessions with stale-preference decay by @backnotprop in #1260

      New Contributors

      Contributors

      Three first-time contributors landed changes in this release. @atomicflag took on a genuinely tricky compatibility problem between Plannotator's system-prompt injection and Qwen3.6's Jinja template, and stuck with it through three review rounds until the fix was airtight. @Snaylaker fixed the vim-mode position reset on window refocus, a small paper cut that anyone reviewing long plans felt daily. @monkhai polished the code review diff headers with a hover state that makes the collapse affordance discoverable.

      Welcome to all three, and thank you.

      Full Changelog : v0.26.7...v0.26.8

    12. 🔗 Ampcode News Global Plugins and Skills rss

      With so much work happening in orbs there needed to be a new place to store Amp plugins and skills. So we added global plugins and skills. They're Amp-hosted, built for agents, and work everywhere Amp runs.

      You can now tell Amp to:

      • "Create a personal plugin that runs our formatter on every file the agent edits."
      • "Import the browser-testing skill from this repo into my personal skills so I can use it on all my projects."
      • "Does anyone on my team share a skill for writing release notes?"
      • "Check if any of my imported plugins are out of date."
      • If you're a workspace admin: "Copy Thorsten's plain-writing plugin into our workspace plugins."

      You can find them in your User Settings and Workspace Settings:

      Personal plugins settings showing plugins with their source

      Workspace skills settings showing shared skills

      Personal vs Workspace

      Personal plugins and skills are good place to experiment and try things out. You can have your agent build something and reload the plugins live within the same thread.

      Workspace plugins and skills are pushable by workspace admins, and are loaded by default for everyone, so we recommend only publishing there once you've tested out something yourself. And if you want to make big changes to an existing workspace plugin, import it into your personal one, give it a test, and then publish it back up.

      Remix and Share

      Personal plugin and skills are much more than a replacement for ~/.config—they can be shared with your workspace too, letting people discover, import and remix them.

      Share dialog with Private and Workspace visibility

      A shared plugin's page showing its source files and where it was imported from

      If there's upstream updates you'd like to pull into your version, or just update your version, you can run amp skill update <name>, amp plugins update <name>, or just ask Amp:

      • "Update the browser-testing skill to the latest version."
      • "Check if any of my imported skills are out of date."
  3. August 10, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-08-10 rss

      IDA Plugin Updates on 2026-08-10

      New Releases:

      Activity:

      • CaeriusIDA
        • b3c50800: Ajoutez des fichiers projet.
        • b296a084: Ajoutez .gitattributes, .gitignore, README.mdet LICENSE.txt.
      • capa
        • ce846fe4: Sync capa-testfiles submodule
        • 79c0d8d0: Merge pull request #3140 from mandiant/dependabot/npm_and_yarn/web/ex…
        • aaf5c643: build(deps-dev): bump js-yaml from 4.3.0 to 4.3.1 in /web/explorer
        • 3563c217: build(deps): bump pip from 26.1.2 to 26.2 (#3136)
        • 1caf26ed: Sync capa rules submodule
      • disrobe
        • c3d4217e: codec: unify seeded adler32 checksums
        • 24cd219d: codec: type and bound lenient percent decoding
        • f6b88958: pyarmor: own hotpatch scratch directories
        • a751dd6e: action: pair output flags with cli commands
        • 65e972e5: native: reject wrapped section file offsets
        • 52827e0a: contain trusted tool process trees
        • 89f05c94: dotnet: refuse unlowered compiler constructs
        • 87a2dc29: core: gate Windows-only anti-analysis imports
        • 61a5a0c4: tighten PHP differentials and static precision checks
        • 49772719: keep full coverage off routine main pushes
        • 52db8fa1: release: prepare v0.10.5
        • 11f4cb3d: go: require parsed containers for recovery
      • DynamicVarCheck_IDA
      • fifam
      • grokathon
        • fd70bd2b: arcade: add desktop start prompt
      • hrtng
        • eb6b9c20: fix enum importing; fix auto-comments;
      • ida-codemode
        • c888608d: Improve timeline view of the dashboard
        • eb4553bc: 0.5.0
        • 80eb7945: Add new trace events to dashboard
        • 3417d0eb: Reformat
        • 4598de45: Do not try hcli from PATH
        • 9155aad9: Switch to regular ida-domain release
        • 7567c320: Add ida-codemode-logs tool to collect logs in a self-contained package
      • ida-domain
      • ida-hcli
        • 56ee5e23: fix: require rich>=14.1 so nested spinners don't abort commands (#296)
        • ef2eba2e: fix: pass all arguments through to the program in ida python commands
        • fd20bd39: docs: document how hcli finds the IDA installation, version, and Python
        • db1e25e6: refactor: consolidate Python-environment inspection in hcli.lib.venv
        • 4dfc729a: refactor: resolvers report their source; explain-environment consumes…
        • 908a5969: refactor: express no-build-isolation only through PipOptions
        • 200c3ce4: refactor: probe interpreter versions in exactly one place
        • 26928279: perf: probe IDA's Python via idat once per process
        • 2a5d02cd: refactor: delete dead hcli.lib.util.python module
      • IDAPluginList
        • e6aa4a2f: chore: Auto update IDA plugins (Updated: 19, Cloned: 0, Failed: 0)
      • Luc-Nhan
        • b1140450: fix(tools): coerce hex-string int args and guard future.cancel()
        • 29ed93c4: fix(tools): reject unknown tool args with actionable message
      • twdll
        • ce21343c: feat: add political parties methods
    2. 🔗 r/Harrogate Does Brimham Rocks carpark really get locked? rss

      Some friends and I were hoping to go to Brimham Rocks to watch the partial eclipse, then go for a walk and then watch the Perseid Meteors. Although the plan is somewhat scuppered after learning the car park is only open until "dusk" (when even is that?!).

      Does anyone know if/when the gates actually get locked, or is the sign to try and deter overnight camping? And if so, is there an alternative parking location we could use?

      submitted by /u/colliewob
      [link] [comments]

    3. 🔗 HexRaysSA/ida-codemode v0.5.0 release

      Full Changelog : v0.4.1...v0.5.0

    4. 🔗 @binaryninja@infosec.exchange Capable of lifting more than ever, with more performance improvements and mastodon

      Capable of lifting more than ever, with more performance improvements and features crammed into one of our biggest releases ever: Binary Ninja 6.0! Join us today @4pm ET to see a preview of our latest improvements: https://youtube.com/live/PojKznVNE_o

    5. 🔗 r/Harrogate Eclipse Glasses rss

      Hi all

      Does anyone know of a place that’s selling cheap eclipse glasses in Harrogate or somewhere close by? Went to order some on next day delivery for the partial eclipse on Wednesday but it seems that non will deliver in time.

      Much appreciated!

      submitted by /u/jadedproductions
      [link] [comments]

    6. 🔗 r/Harrogate Anyone think of a place which has parking, shade and a view? rss

      I know it’s a lot to ask for but I need to find somewhere I can drive a very elderly relative, where there is something to look at and shade trees. A cafe I can get takeaway drinks/ice cream a bonus.

      Edit - to be clear, the relative wants to stay in the car, get some fresh air and look at something pretty without having to get out or bake in full sun.

      submitted by /u/Lumpyproletarian
      [link] [comments]

    7. 🔗 backnotprop/plannotator v0.26.7 release

      Follow @plannotator on X for updates

      What's New in v0.26.7

      One change, and it transforms how annotating HTML pages feels: pinpoint mode now targets any element on the page.

      Pinpoint targets what your cursor is on

      Since v0.26.5, raw-HTML annotate sessions default to pinpoint input. But pinpoint could only target a fixed list of "semantic" HTML tags: headings, paragraphs, tables, sections. Real prototype and report pages are built from styled divs and spans, so hovering a small chip or an icon button selected the whole enclosing section, and some elements could not be selected at all.

      Pinpoint now resolves the element actually painted under your cursor, whatever its tag. Chips, icon buttons, badges, custom cards: all individually annotatable. Elements smaller than 16px promote to their parent so you are not pixel-hunting, and containers are selected the natural way, by pointing at their padding or any spot not covered by a child. The whole interaction stays mouse-only and matches how pinpoint already feels on markdown documents. Hover labels got smarter too: a div with a rowchip class now labels as "rowchip", using its aria-label, role, or class names instead of a bare tag name.

      Under the hood the hover path no longer rebuilds a document-wide element graph every frame; it is a per-event hit-test with zero document scans, which also retires the performance debt noted in the v0.26.5 pinpoint release. Anchor restoration keeps every fail-closed guarantee, and data-testid-style attributes (data-test-id, data-cy, data-qa) now count as trusted element identity for restoring annotations onto regenerated pages. One honest limit: an element with no text and no identifying attribute can be annotated in- session, but its pin does not restore on a later reopen; a pin that cannot verify its target refuses to guess.

      The change went through two adversarial review rounds; the first round removed an anchoring mechanism that could have restored a pin onto the wrong sibling, in favor of failing closed.

      Install / Update

      macOS / Linux:

      curl -fsSL https://plannotator.ai/install.sh | bash

      Windows:

      irm https://plannotator.ai/install.ps1 | iex

      Claude Code Plugin: Run /plugin in Claude Code, find plannotator , and click "Update now".

      OpenCode: Clear cache and restart:

      rm -rf ~/.bun/install/cache/@plannotator

      Then in opencode.json:

      {
  "plugin": ["@plannotator/opencode@latest"]
}

      Pi: Install or update the extension:

      pi install npm:@plannotator/pi-extension

      What's Changed

      • feat(annotate): hit-test pinpoint targeting for raw-HTML sessions by @backnotprop in #1251

      Full Changelog : v0.26.6...v0.26.7

    8. 🔗 HexRaysSA/plugin-repository commits sync repo: +3 releases rss 
      sync repo: +3 releases

## New releases
- [ida-codemode](https://github.com/hexrayssa/ida-codemode): 0.4.1, 0.4.0, 0.3.2
    9. 🔗 backnotprop/plannotator v0.26.6 release

      Follow @plannotator on X for updates

      What's New in v0.26.6

      v0.26.6 is a rebuild-only patch: no Plannotator code changed, but every binary is now compiled with Bun 1.3.14 instead of 1.3.11.

      Env vars now work inside OS sandboxes

      Binaries built with Bun 1.3.11 loaded an empty environment whenever a parent of the working directory was unreadable, which is the normal state inside OS- level sandboxes (Seatbelt on macOS, Landlock on Linux, tools like nono). Every PLANNOTATOR_* variable was silently ignored there: remote mode never activated, fixed ports were dropped, and no warning explained why. This was oven-sh/bun#27802, fixed upstream in Bun 1.3.13.

      We had pinned Bun to 1.3.11 in April because 1.3.12 broke macOS binary signing outright. Before unpinning we verified both directions: a 1.3.14 build reads env vars correctly under an unreadable ancestor, and cross-compiled macOS binaries carry the same valid linker signature as the known-good releases and launch cleanly.

      The release pipeline also gained two permanent guardrails: macOS binaries are now smoke-launched after every build (the April signing breakage shipped because only Linux and Windows were), and a new check runs the freshly built binary from a directory with an unreadable ancestor and asserts env vars still load.

      Install / Update

      macOS / Linux:

      curl -fsSL https://plannotator.ai/install.sh | bash

      Windows:

      irm https://plannotator.ai/install.ps1 | iex

      Claude Code Plugin: Run /plugin in Claude Code, find plannotator , and click "Update now".

      OpenCode: Clear cache and restart:

      rm -rf ~/.bun/install/cache/@plannotator

      Then in opencode.json:

      {
  "plugin": ["@plannotator/opencode@latest"]
}

      Pi: Install or update the extension:

      pi install npm:@plannotator/pi-extension

      What's Changed

      • fix(ci): bump Bun build pin to 1.3.14 for sandbox env loading by @backnotprop in #1250

      Community

      @SierraJC filed #1249 with a complete diagnosis: the exact upstream Bun issue, the fix version, and a one- line repro that distinguishes "binary cannot see the variable" from "binary mishandles the variable". Reports like this make patches fast.

      Full Changelog : v0.26.5...v0.26.6

    10. 🔗 backnotprop/plannotator v0.26.5 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.26.4 | Skill-menu hover jitter fix (same-day patch on v0.26.3)
      v0.26.3 | Skill references in comments with / or $, reachable remote session URLs, worktree switcher tooltips
      v0.26.2 | Single-file diff tabs render fully, no more silently dropped review files, light/dark theme pairs, palette-matched code blocks
      v0.26.1 | GitButler 0.22.0 compatibility via capability-probed JSON flags
      v0.26.0 | Edit Mode (suggest by editing the diff), Guided Review virtualization, colorblind theme, safe uninstall, installer opt-outs, OpenCode 2 support
      v0.25.1 | Codex no longer launches on review open, annotate-last follows the live conversation, pi-todos mirror, Claude Opus 5, abandoned-gate dismissal
      v0.25.0 | Vim keyboard controls, Approve with Notes, scriptable annotate gates, persistent Guided Reviews, memory and file-watching hardening
      v0.24.2 | Annotate YAML/JSON/TOML config files, XDG data directory support, Codex model catalog update, Cursor sandbox escape hatch
      v0.24.1 | Annotate accepts parent-relative ../ file paths
      v0.24.0 | PR/MR artifact gallery, GitButler review support, port ranges, expanded comment editor, OpenCode + Pi fixes
      v0.23.1 | Startup no longer hangs on large or slow directory trees, Ask AI input stays visible after long responses
      v0.23.0 | Plan approval fix for Claude Code 2.1.199+, annotate mode version diff, binary-only --minimal install, reviews post without attribution

      What's New in v0.26.5

      This release makes annotate feedback durable, rebuilds how you annotate raw HTML pages, and fixes real bugs reported from the field: lost Pi feedback after a reload, a vim cursor hiding behind the HUD, and an installer failure on older git. Seven PRs, two from external contributors, including a first contribution from @Whamp.

      Your annotate feedback can no longer be lost

      When you submitted annotate feedback after the invoking agent had already timed out, the server settled the decision with nobody listening and deleted your draft. The feedback then existed nowhere. Reported by @0okay after exactly this happened on Windows.

      Now the server writes your submitted feedback to a durable record under your data directory before it deletes the draft, so a vanished consumer can no longer take your work with it. If the record cannot be written, the draft is kept as the recovery copy instead. This applies to single local file sessions; URL, folder, and last-message sessions stay fully stateless, and disabling annotate history keeps everything stateless as before.

      Annotating HTML pages: pinpoint-first

      Raw-HTML annotate sessions got a rework. Pinpoint is now the default input: hover highlights the element under your cursor, a click pins it and opens the comment composer directly, and each element annotation gets a numbered badge. Drag selection is still one toggle away, and your choice is remembered separately from markdown sessions.

      Pages also open minimal: the first session hides the toolstrip, tab flags, and sidebar so you see just the page, and every session after that opens with exactly the chrome you last left visible.

      Under the hood, element annotations now carry a verified CSS anchor so they restore to the same element when you re-open a page, even after the page was regenerated. Restoration is deliberately fail-closed: when the anchor cannot be trusted, the annotation falls back to text search, and text that moved elsewhere in the page is followed rather than mis-pinned. The feature shipped through two adversarial review rounds plus a 25-item QA sweep, which hardened anchor verification, capped selection sizes, kept pin badges out of printed pages, and bounded anchor building so a click on deeply nested markup can never freeze the tab.

      Pi: feedback delivers after a reload

      A Plannotator browser tab can outlive a Pi /reload. When feedback arrived from such a tab, the extension rejected the freshly reloaded runtime as the same stale session (reload preserves Pi's session id) and the feedback was dropped with an error. @Whamp diagnosed the root cause and fixed it: the extension now tracks an in-process runtime token, so a reload counts as a new active runtime and both feedback and notifications route to it. Comes with a regression test simulating the exact reload scenario.

      Vim: the cursor stays out from under the HUD

      Document vim navigation used to pin the cursor target flush against the viewport edge, exactly where the sticky action bar and the key HUD float, so j/k motion at the top or bottom of a document hid the caret behind an overlay. @rNoz reported it and fixed it: cursor movement now reveals its target with a scrolloff-style margin sized to the viewport, so keyboard motion keeps the caret visible the way mouse scrolling always did.

      The installer works on older git

      install.sh failed its skills step with a misleading "network or git error" on systems whose git predates 2.25 (for example a stale Xcode Command Line Tools git), because git clone --sparse does not exist there. Reported by @dubbl-a. All three installers now probe for the capability and fall back to a plain shallow clone, surfacing the real git error when something else goes wrong. A follow-up in this release also pins the probe to a stable locale, so localized git builds take the fallback correctly too.

      Additional Changes

      • Windows Codex wording corrected. The README claimed Codex hooks are disabled on native Windows while the installer called them experimental and printed setup steps. The docs now agree: experimental, with manual steps (#1241 reported by @dustintran333)
      • Print stays clean. Printing an annotated HTML page no longer bakes pin badges or pinpoint overlays into the output; inline annotation marks remain printable on purpose (#1245)
      • CI now runs every DOM suite. Eight DOM-gated test files were silently skipping in CI, including the vim and HTML-annotate suites; they are wired in and enforced on every run

      Install / Update

      macOS / Linux:

      curl -fsSL https://plannotator.ai/install.sh | bash

      Windows:

      irm https://plannotator.ai/install.ps1 | iex

      Claude Code Plugin: Run /plugin in Claude Code, find plannotator , and click "Update now".

      OpenCode: Clear cache and restart:

      rm -rf ~/.bun/install/cache/@plannotator

      Then in opencode.json:

      {
  "plugin": ["@plannotator/opencode@latest"]
}

      Pi: Install or update the extension:

      pi install npm:@plannotator/pi-extension

      What's Changed

      • Fix feedback delivery after Pi reload by @Whamp in #1240
      • fix(install): fall back to a plain shallow clone when git lacks --sparse by @backnotprop in #1239
      • fix(annotate): persist submitted feedback before deleting the draft by @backnotprop in #1237
      • fix(vim): keep the j/k cursor clear of the HUD bands when scrolling by @rNoz in #1154
      • feat(annotate): pinpoint-first raw-HTML sessions with element anchors and a minimal-first render by @backnotprop in #1243
      • chore: fold in pre-release QA findings by @backnotprop in #1245
      • fix: address the three pre-release sweep findings by @backnotprop in #1246

      New Contributors

      Community

      @Whamp hit the Pi reload bug in daily use, traced it to session identity surviving the reload, and shipped the fix with a regression test. First contribution, and a precise one.

      @rNoz continues to make vim mode better than we left it: he filed the HUD occlusion report (#1153) with a demo video and fixed it himself, including a pure scroll-math helper with its own test suite.

      Issue reporters this release:

      • @0okay reported the lost-feedback failure (#678) that drove the durable-submission work
      • @dubbl-a reported the old-git installer failure (#1238) with the exact git version and error output that made the fix straightforward
      • @dustintran333 caught the README contradicting the installer on Windows Codex hooks (#1241)

      Full Changelog : v0.26.4...v0.26.5

    11. 🔗 Filip Filmar rules_vivado: FPGA Synthesis and Place-and-Route in Bazel rss

      rules_vivado drives the AMD/Xilinx Vivado FPGA toolchain from Bazel: VHDL and Verilog compile, elaborate, simulate, synthesize, place-and-route, generate a bitstream, and program the device, all as hermetic Bazel build actions rather than clicks in a GUI or a pile of ad-hoc TCL. This is the module that turns the Cocoapuffs board flow into bazel build. This post kicks off a short series. Over the Cocoapuffs project and its parent repo a200t_examples I ended up writing a fair number of Bazel modules to make an FPGA-based RISC-V system reproducible from source.

    12. 🔗 Ampcode News A Dial for You rss

      We changed the Dial. Link a ChatGPT subscription and low, medium, and high only use OpenAI models: as the main agent, as the oracle, as the thread reader, as code review. Every model behind those modes is an OpenAI model, billed to your subscription.

      Before this change, you'd still pay for tokens with a subscription linked, because parts of the work ran on other models: low and the thread reader on GLM-5.2, the high oracle on Claude Fable, code review on Haiku — all billed to Amp credits. That confused people, and we get why.

      With a subscription connected:

      • low runs GPT-5.6 Terra instead of GLM-5.2.
      • medium runs GPT-5.6 Sol, as before.
      • high runs GPT-5.6 Sol as both agent and oracle. The oracle used to be Fable.
      • The thread reader and code review move to GPT-5.6 Terra.

      The mode picker with the dial on medium, showing GPT-5.6 Sol as agent and oracle and a green ChatGPT subscription LED

      Doesn't this make the modes worse? Barely, and less every month. The frontier models have converged: any of them gets you to a good result with a good harness. We swapped the default model for most users overnight and nobody complained. So the modes stay at the frontier, and the tokens come out of a subscription you already pay for.

      high also drops its credit minimum when your subscription is active. There's no Fable call left to pay for.

      ultra doesn't change. It runs Claude Fable on credits, because ultra is for the tasks where you want the strongest model, whatever it costs.

      If you don't have a subscription, nothing changes. The modes run as before, on Amp credits.

      Link your subscription and turn the dial.

    13. 🔗 Baby Steps Cylic trait implementations: motivation rss

      Lately I've been thinking about cyclic trait implementations. This is a problem that I've been trying to understand for years and years and I finally feel like I'm geting somewhere. I'm going to try to write out a series of blog posts documenting those explorations and, hopefully, culminating in a design that could be RFC'd. In this first post, I want to talk about one of the interesting questions, what I am going to call "internal" vs "external" proofs. I know that this material can seem abstract, so I'm going to try and connect it to "real Rust" as much as possible! This particular blog post is an introduction, explaining the general problem and giving some motivation for why we care.

      What are cyclic trait implementations?

      Right now in Rust we require most traits to have non-cyclic , or inductive , implementations. To explain what I mean, let's consider this trait:

      trait Dump {
    fn dump(&self);
}

      Now imagine that we have an impl of this for i32:

      // Impl I
impl Dump for i32 {
    fn dump(&self) {
        println!("{self}");
    }
}

      A simple impl for Rc<T> and `Option:

      // Impl RC
impl<T> Dump for Rc<T>
where
    T: Dump,
{
    fn dump(&self) {
        T::dump(self)
    }
}

// Impl Opt
impl<T> Dump for Option<T>
where
    T: Dump,
{
    fn dump(&self) {
        if let Some(v) = self {
            T::dump(v)
        }
    }
}

      and finally a recursive List type that has an impl as well:

      struct List<T> {
    value: Rc<T>,
    next: Option<Rc<List<T>>>,
}

// Impl L
impl<T> Dump for List<T>
where
    T: Dump,
{
    fn dump(&self) {
        Dump::dump(&self.value);
       if let Some(n) = &self.next {
            Dump::dump(n);
        }
    }
}

      If I try to show that List<i32>: Dump, I do that by

      • Applying "impl L" to show that List<i32>: Dump if i32: Dump
        • Then applying "impl I" to show that i32: Dump

      There's no cycle here - that is, I didn't have to use impl L to show that impl L is valid.

      Cyclic logic sounds bad, but it can be exactly what you want

      Now, when I said that "the impl L didn't have to use the impl L to show that it is valid" that might not have sounded suspicious to you. In fact, it's a pretty natural idea. After all, generally when you try to establish a logical argument, you aren't allowed to use cyclic reasoning. That is, you can't say: I know that Niko likes Rust because Niko likes Rust. So, in the same sense, it seems natural that I should not be able to say "I know that List<i32> implements Dump because List<i32> implements Dump".

      But actually, it would sometimes be really useful to say exactly that. One example is so-called "perfect derive". In our Dump impl above, we had one where-clause, T: Dump. And if you were to create a custom derive for Dump and write #[derive(Dump)], the impl I showed is typically exactly what you would get. But it's not necessarily what you want. Consider what you get with #[derive(Clone)]:

      // Impl LC1
impl<T> Clone for List<T>
where
    T: Clone, // <-- generated but not really required!
{
    fn dump(&self) {
        List {
            value: Clone::clone(&self.value),
            next: Clone::clone(&self.next),
        }
    }
}

      Here, the derive is going to create an impl that requires T: Clone. But if you look closely, you'll see that all the fields only use Rc<T>, so in fact, we should be able to clone a List even without T: Clone! But how is the compiler to know this?

      You might think that the compiler could do some super smarty-pants analysis on the fields to figure it out. And, in a way, it can: that is what cyclic trait solving is all about. The thing is, while the compiler can do that, the derive cannot - the derive doesn't have access to the definitions of other types and so forth, and clearly we would need to know things about Option and Rc to figure out whether T: Clone is required here.

      But what we could do is to generate a different impl. Instead of adding T: Clone for each type parameter, we could add a where-clause for each field type. This makes sense: after all, we are just going to be calling Clone on every field, so it's quite logical to say that the impl is valid if every field is cloneable:

      // Impl LC2
impl<T> Clone for List<T>
where
    Rc<T>: Clone,
    Option<Rc<List<T>>>: Clone,
{
    // .. as above ..
}

      Under this formulation, we can see that all we have to be able to do is to clone an Rc<_> and clone an Option<Rc<_>>, neither of which require that T: Clone.

      This idea is called perfect derive

      We call this idea [perfect derive][] and it's been a goal for a while. The thing is, cyclic reasoning is tricky to get right. The Clone example is actually an easy one: that one doesn't really require cyclic reasoning:

      • To show that List<i32>: Clone we have to show that…
        • Rc<i32>: Clone, which is easy because impl<T> Clone for Rc<T> doesn't have any where-clauses1
        • Option<Rc<List<i32>>>: Clone uses the impl<T> Clone for Option<T> where T: Clone impl which requires…
        • Rc<List<i32>>: Clone, which is again easy

      But it's not so easy for Dump

      But if we use that same "cyclic derive pattern" to generate our Dump impl, things don't work out so well. Instead of just a T: Dump bound, our Dump impl now has two bounds:

      // impl L1
impl<T> Dump for List<T>
where
    Rc<T>: Dump, // <-- Used to be `T: Dump`
    Option<Rc<List<T>>>, // <-- This one is new!
{
    fn dump(&self) {...}
}

      Now imagine we try to show List<i32>: Dump. We begin by applying impl L1, which requires us to show that its where clauses hold:

      • To show List<i32>: Dump we use impl L1, which has two where-clauses:
        • Rc<i32>: Dump, this one is easy because the Rc impl requires that i32: Dump which is true.
        • But Option<Rc<List<i32>>>: Dump is tricky. The Option impl requires that…
        • We need to prove Rc<List<i32>>: Dump, and then the Rc impl requires that…
          • We need to prove List<i32>: Dump, but that is what we started with! That's cyclic logic!

      Ugh. Something's tricky here!

      We can't just accept any old cycle because of supertraits

      Now, maybe you think we can just accept any cycles. And for these examples, it would be fine: but it's not correct if you consider supertraits. Consider this trait and impl pair:

      trait Magic: Copy { }

// Impl M
impl<T> Magic for T
where
    T: Magic,
{}

      If you are naive, this weird trait-impl pair can be used to prove that any type is Copy, regardless of whether it has a Copy impl. For example:

      • Say we want to prove that String: Copy. We observe that if a type implements Magic, it must implement Copy, so…
        • We begin by proving String: Magic. We use the impl M, which requires
        • that we show String: Magic, which is a cycle, so we accept it.

      Uh oh, now we did something wrong. We proved that String: Copy even though there is no Copy impl. Something is fishy.

      Now clearly we can all see the problem here - the implementation of Magic didn't really add any information. It was just a tautology, saying that T: Magic if T: Magic. It's not wrong , but implementing Magic was supposed to tell us more than just the fact that there is an impl of Magic, it was supposed to tell us also that the supertrait Copy is implemented. And that's not true here.

      But if you think about it, it's hard to decide why we should reject impl M but accept the impl L1 of Dump for List<T>. They both wind up with a cyclic proof. So what's the difference? This is the question we'll be exploring over the next few blog posts.

      Soundness for traits

      This gets at an interesting question: what does it mean for the trait system to be sound. This seems obvious but actually it was a question I found kind of non-obvious for a long time.

      We've found two satisfactory answers to that question. One of them involves converting to dictionary-passing style. Nadri explained that in a blog post. I think that's a great post to read. I'm going to give another definition here that doesn't require converting to a dependently typed program2

      My rough definition is this3: the trait system is sound if, whenever it accepts some program P, that program cannot have a function that believes some Trait holds for the T, but there is no impl of Trait that can be used. So in the case of Magic and Copy, it's easy to write a program that shows simple cyclic trait solving is unsound:

      trait Magic: Copy {}

impl<T: Magic> Magic for T {}

fn is_copy<T: Copy>() {
    // this function believes `T: Copy`
}

fn main() {
    // this can be called because we believe that
    // * `String: Magic` because
    //     * `String: Magic`, and we accept cycles.
    // And then `String: Magic` implies `String: Copy`.
    is_copy::<String>();
}

      By my definition, any sound type/trait system must reject this program because, if it were to execute, then execution would reach is_copy::<String> and yet there is noCopy impl that is judged to ber applicable to String. Uh oh!

      Coming next

      As I promised, this post was mostly focused on "setting the scene". My goal was to explain what the problem is that we are trying to solve - permitting "good cyclic impls" but forbidding bad ones. I didn't spend a lot of time on the bad ones, but it turns out that there's a wide variety of unsound things one can do, some of which the compiler currently gets wrong, others of which it would only get wrong if we started permitting cycles.

      My motivation for getting into this work is a bit complicated. I want perfect derive. But it's also a loose end in our trait semantics that I really want to see nailed down before we move onto other tasks. Having auto traits (e.g., Send) work differently from other traits is clearly a "smell", and without a strong understanding of the logical underpinnings of our trait system it's easy to get things wrong when we build extensions.

      In the next few posts I'll go a bit deeper into the exploration I and others have been doing. I'll talk about some of the "false starts" we took along the way and why they don't work, and then about some of the solutions that are under consideration. Working through this stuff has really helped me to broaden my understanding of various areas of logic. By the time we're done, we'll cover4 coinduction and productivity, modal logic and the later modality, and we'll see how our techniques might even help us with resolving specialization5.

      I cited it earlier, but if you want to read other tasks on the same subject, I definitely recommend Nadri's post on dictionary-passing style.

      1. Apart from the default Sized bound, I'm ignoring that here ↩︎

      2. I have found that both the dictionary-passing interpretation and the logic approach I'm using are valuable. In the end, they're more or less equivalent, which I guess shouldn't be surprising if you've heard of the Curry Howard Correspondence, but I'll talk about that later perhaps. ↩︎

      3. I would like to, but haven't, define a simplified version of Rust that includes trait solving and simple type checkoing and show that it cannot "go wrong". ↩︎

      4. In a shallow way, I'm no expert! ↩︎

      5. Plot twist, bet you didn't see that coming! I sure didn't. ↩︎

  4. August 09, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-08-09 rss

      IDA Plugin Updates on 2026-08-09

      New Releases:

      Activity:

    2. 🔗 HexRaysSA/ida-codemode v0.4.1 release

      Full Changelog : v0.4.0...v0.4.1

    3. 🔗 HexRaysSA/ida-codemode v0.4.0 release

      Full Changelog : v0.3.2...v0.4.0

    4. 🔗 pydantic/monty v0.0.21 - 2026-08-09 release

      What's Changed

      Full Changelog : v0.0.20...v0.0.21

    5. 🔗 HexRaysSA/ida-codemode v0.3.2 release

      Full Changelog : v0.3.1...v0.3.2

    6. 🔗 pydantic/monty v0.0.20 - 2026-08-09 release

      What's Changed

      Full Changelog : v0.0.19...v0.0.20

    7. 🔗 Confessions of a Code Addict x86 Addressing Modes, Part 2: Indirect, Indexed, and Offset-based Modes rss

      Welcome back to our series on x86 assembly programming. If you are new, you can check out the series overview.

      In the previous part of this article, we covered some of the basics of x86 addressing modes, such as immediate addressing and direct memory addressing. This 2nd part continues where we left and completes the coverage of all the x86 addressing modes, along with all the caveats that you need to be aware of. Along the way, you will also implement some very interesting examples and exercises, such as parsing the command line arguments on the stack, implementing the magic 8-ball game, and implementing a lookup table in assembly.

      Here's what we will learn:

      • Indirect memory addressing: this is how pointers work in C

      • Offset-based addressing: this is how we access fields inside a struct

      • Indexed addressing: this is how we access elements of an array

      • The generalised addressing mode syntax in x86 assembly: all the other addressing modes are simplifications of this generalised syntax

      Let's start with indirect memory addressing.

      I 'm also publishing this series on x86 assembly in the form an ebook (PDF). If you don't wish to upgrade to a subscription, you can purchase the PDF using the following link. If you are a paid subscriber, you can get it at a discount (monthly subs: 20% and annual subs: 50%). Please email me for the discounted link.

      Get Ebook

      Indirect Memory Addressing

      In the previous article, we learned about direct memory addressing, which is only useful when you know the exact memory address that you can encode in the instruction. This is mostly possible for static data of your program because their addresses are known at assembly and linking time. However, most real- world programs work with dynamically allocated memory where the actual memory address is known only at runtime, so direct memory addressing is not viable for such cases. We need indirect memory addressing.

      In indirect memory addressing, the memory address is stored in a register. In this mode, the processor needs to first read the address from the register, do the memory access, and then execute the instruction.

      For example, when we allocate dynamic memory on the heap using malloc or mmap, it returns the address of the allocated memory. The returned address is kept in a register like RAX. Now, if we want to read or write this memory, we need to tell the processor to treat the value in RAX as an address, perform a memory access at that address, and execute the actual instruction.

      This is different from direct memory addressing because there the address was part of the instruction, so the processor did not need to get the address from anywhere. In contrast, here the processor first needs to read the address from the register, and then access memory. You can also think of indirect memory addressing as adding one layer of indirection to memory access.

      While dynamic memory allocation in C is easy, in assembly it is very involved, so we will learn to do that in a future article. Instead, to learn how to use indirect memory addressing, we will copy the address of a value stored in the .data section into a register.

      So, how do we copy the address of a label into a register? We know that when we write:

      # move the value at the label ANSWER_TO_LIFE into rax
movq ANSWER_TO_LIFE, %rax

      The instruction tells the processor to copy the value stored at the address ANSWER_TO_LIFE into rax. However, when we want to copy the address itself into a register, we need to use the $ prefix that turns the instruction into immediate addressing mode:

      # move the address of the label into rax
movq $ANSWER_TO_LIFE, %rax

      After this, the register rax contains the memory address where the value 42 is stored. The following diagram visualizes this

      RAX contains address of a value stored in the .data sectionRAX contains address of a value stored in the .data section

      The diagram shows that after executing that mov instruction, the register rax contains the memory address of the value in the .data section.

      Once we have an address in a register, whenever we want to dereference that address, we need to use indirect addressing mode syntax. The following snippet shows how to copy a value by dereferencing the address in rax.

      # indirect addressing mode
movq (%rax), %rdi # dereference address in rax and copy the value from memory into rdi

      The syntax is a bit different from what we have seen so far. When we write "movq %rax, %rdi", we tell the processor to copy the value stored in rax into rdi. But when we surround one of the registers with parentheses, the assembler generates a different encoding of the instruction that tells the processor that the register contains an address, and it needs to get the value from that address.

      We can see the difference in the encoding using objdump just like we did for direct memory addressing. The following objdump output shows the difference in the encoding for the instructions movq %rax, %rdi and movq (%rax), %rdi.

      0000000000401000 <_start>:
401000:  48  89  c7  mov  %rax,%rdi
401003:  48  8b  38  mov (%rax),%rdi

      You can see that at the machine code level, these two result in two very different encodings.

      Base Address and Base Register

      Before continuing further, let's introduce two important terms that we should understand in the context of assembly programming.

      Base Address

      When working with memory addresses, what we have is the starting address of a value in memory; this is also called the base address of the value.

      For example, an 8-byte value 42 may be stored at the address 0x0010. Because its size is 8 bytes, it spans from the address 0x0010 up to 0x0018. So, 0x0010 is the base address.

      Knowing the base address helps us compute addresses for more complex data types, such as arrays and structs. For example, if we have a struct with three int type fields, and we want to access its 3rd field, we would calculate the address as base address + 8.

      Base Register

      When a register contains a base address for a value in memory, we refer to it as the base register. In the above example, rax is a base register.

      Hands-on Example of Indirect Addressing Mode

      Now, let's put all of this together and write a simple program that reads an integer value from memory, multiplies it by 2, and exits with the result of the multiplication as its status code.

      .data # create the .data section
# create a 64-bit integer value
ANSWER_TO_LIFE: .quad 42

.text
.globl _start
_start:
# copy the address to rax
movq $ANSWER_TO_LIFE, %rax # rax becomes the base register
# copy the value from memory address in rax into rdi
movq (%rax), %rdi
imulq $2, %rdi # multiply value in rdi by 2
movq $60, %rax # put exit syscall no in rax
syscall # execute exit syscall

      You can assemble, link, and run it. I also encourage you to step through this in gdb to see that rax contains an address value after the first mov instruction.

      Indirect Addressing and Pointers in C

      When we use pointers in C, the compiler generates assembly code that uses indirect memory addressing to make it work. The C pointer syntax is just a syntactic sugar to hide this detail.

      For example, if you call malloc or mmap to allocate memory in your C program, they return the address of the allocated memory. This return value is stored in the rax register as per the x86-64 calling convention. And, later when we dereference that memory using the * operator, the compiler generates assembly instructions which use indirect memory access. The following diagram shows this, but you can also test it out yourself using Compiler Explorer.

      Exercise: Traverse a Linked List

      This x86 assembly series is available to paid subscribers. If you'd like to continue reading the rest of this article and access the full series, you can upgrade your subscription.

      Alternatively, you can purchase the x86 assembly book using the link below.

      Get PDF

      Read more

    8. 🔗 Anton Zhiyanov Relying on Go rss

      Everyone is creating a new programming language these days, often one that's "like Go but with more features" or "like Rust but simpler".

      Solod, a systems language for C and Go developers, might look like one of those languages, but it takes a different approach.

      Go's tooling Solod is not "Go-like" in the usual sense, nor is it an attempt to "fix Go's mistakes". At the language level, Solod is literally a subset of Go. Solod reuses much of Go's existing tooling, including syntax highlighting, LSP, linters, and the package management system. Take this quick-start guide, for example: Quick start Install the So command line tool: go install solod.dev/cmd/so@latest Create a new Go project and add the Solod dependency to use the So standard library: go mod init example go get solod.dev@latest Write regular Go code, but use Solod packages instead of the standard Go packages: package main import "solod.dev/so/math" func main() { ans := math.Sqrt(1764) println("Hello, world! The answer is", int(ans)) } Run without saving the binary: so run . That's it! There's nothing new here. It's mostly standard Go workflow, except for so run, which is a Go program that mimics go run. Go's standard library Solod also reuses a lot of Go's standard library code and tests. Some of it is taken verbatim from Go's source code, like these two string functions: // CutPrefix returns s without the provided leading prefix string // and reports whether it found the prefix. func CutPrefix(s, prefix string) (string, bool) { if !HasPrefix(s, prefix) { return s, false } return s[len(prefix):], true } // HasPrefix reports whether the string s begins with prefix. func HasPrefix(s, prefix string) bool { return len(s) >= len(prefix) && s[:len(prefix)] == prefix } Of course, Solod retains the Go authors' copyright. Some code requires changes to support the manual memory management with explicit allocators used by Solod: // Go version. func Clone(s string) string { if len(s) == 0 { return "" } b := make([]byte, len(s)) copy(b, s) return unsafe.String(&b[0], len(b)) } // Solod version. func Clone(a mem.Allocator, s string) string { if len(s) == 0 { return "" } b := mem.AllocSlice, len(s)) copy(b, s) return string(b) } You can probably see the resemblance. A grain of salt

      Go tools don't know that Solod is a subset of the full Go language, so they won't flag features Solod doesn't support, like function literals or iterators. These diagnostics come from the custom so tooling:

      package main

func main() {
    f := func(n int) {
        println(n)
    }
    f(42)
}



main.go:4:7: function literals are not supported
    f := func(n int) {
         ^here

      Also, although a substantial part of Go's standard library is ported verbatim or with minimal changes from the original source, that doesn't mean the code is automatically correct. Solod still needs its own tests, including ones that run under sanitizers and static analyzers.

      It's all C in the end

      All Solod code is translated to regular C11 and then compiled with GCC or Clang. Solod therefore relies on C tooling and decades of optimization work just as much as on Go's.

      Solod code:

      package main

import "solod.dev/so/math"

func main() {
    // What might it be?
    ans := math.Sqrt(1764)
    println("Hello, world! The answer is", int(ans))
}

      Translated C code:

      // -- main.h --
#pragma once
#include "so/builtin/builtin.h"
#include "so/math/math.h"

// -- main.c --
#include "main.h"

int main(void) {
    // What might it be?
    double ans = math_Sqrt(1764.0);
    so_println("%s %" PRIdINT, "Hello, world! The answer is", (so_int)(ans));
    return 0;
}

      The C version is noisier, of course, especially for more complex programs than this one. But it remains readable.

      And since there's no runtime, interoperability between Solod and C costs nothing.

      Final thoughts

      A new language doesn't necessarily need a new ecosystem.

      Solod relies heavily on Go, and I see that as a strength, not a weakness. Reusing Go's proven tools and standard library makes Solod more reliable and easier to work with.

      If you're interested, take a look at Solod's readme — it has everything you need to get started. Or try it online without installing anything.

    9. 🔗 r/Harrogate Food recommendations in Harrogate/Knaresborough rss

      I’m planning a road trip in June next year, around Yorkshire, for my mam’s 50th birthday. I’m struggling to choose somewhere to eat on the third night when I plan to book a room in Harrogate. I’m coming to the locals to hopefully find somewhere nice to eat in either Harrogate itself or Knaresborough.

      Things to help you guys out:

      1) We will be in a car so somewhere with parking would be ideal but it’s not the end of the world if we had to park further away and walk.

      2) Neither of us drink so I’m not bothered about somewhere that sells alcohol.

      3) I’ve budgeted about £80 for our evening meal on this night. That’s to cover both of us,; 2 courses and probably a pint of fizzy pop each. I wouldn’t mind spending a bit more if it’s an exceptionally good restaurant or has a like a niche gimmick we’d enjoy.

      4) My mother likes traditional home cooked British food; think mince and dumplings, corned beef pie or a roast. She LOVES traditional fish and chips. She also enjoys Italian food, particularly lasagne but also enjoys creamy pasta dishes. She also likes curry but it has to mild, like tikka masala or korma.

      5) My mam has a particularly sweet tooth so anywhere with a good desert menu. Extra points if the restaurant serves sticky toffee pudding without raisins😂

      That’s all I can think of right now but I will add an edit if I think of anything else that I should have mentioned. Thanks in advance everyone!

      submitted by /u/strategic-g
      [link] [comments]

generated: August 12, 2026 at 15:47:24