🏡

to read (pdf)

generated: May 19, 2026 at 18:30:33

May 19, 2026
1. 🔗 r/Leeds Disposing of dumped nitrous oxide bottles rss
  
  We had these nitrous oxide canisters dumped in our household green recycling bin a couple of weeks ago. It was right before it was due to be picked up, meaning the binmen (understandably) left it. We put in a request to the council to come pick them up but no luck.
  
  Can they be taken to a recycling centre? We tried looking online but it wasn't clear. We didn't realise this was a thing, but I've now seen a few on the side of the road on the way to work.
  
  submitted by /u/seleucid23
  [link] [comments]
2. 🔗 r/reverseengineering Math at Scale: Reversing The Construction Of The Perspective-Projection Matrix (Game Engine Reversing) rss
  
  submitted by /u/zer0_1rp
  [link] [comments]
3. 🔗 backnotprop/plannotator v0.19.20 release
  Follow @plannotator on X for updates
  
  Missed recent releases? Release | Highlights
  ---|---
  v0.19.18 | Edit-based submit_plan for OpenCode, Pi namespace migration, Codex annotate-last fix, OpenCode commands dir fix
  v0.19.17 | Reworked goal setup skill (interview-driven flow), CLI --version flag
  v0.19.16 | Code navigation with peek view (Cmd/Ctrl+click tokens in diffs)
  v0.19.15 | Commit-based diff base, jj evolution diffs, GitLab reliability fixes, OpenCode command intercept fix
  v0.19.14 | Visual explainer skill update, PFM code-file hover previews, Graphviz, diff tab size and line bg intensity, hooks settings tab
  v0.19.11 | Jujutsu (jj) VCS backend, slimmer hunk separators, collapse viewed files, multi-line gutter selection fix
  v0.19.9 | OpenCode user-managed workflow, Pi model switch fix, Codex skill install, shimmer removal
  v0.19.8 | 49 themes with syntax highlighting, keyboard shortcut registry, smart code-file path validation, remote URL notifications
  v0.19.7 | Codex Stop-hook plan review, Codex skills, sidebar auto-close, file tree context menu
  v0.19.6 | Non-blocking Pi browser sessions, agent picker dropdown for OpenCode, annotate-last file resolution fix
  
  What's New in v0.19.20
  
  v0.19.20 adds a visual goal setup UI, fixes the OpenCode edit-based submit_plan issues that caused the v0.19.19 hotfix, and makes Plannotator work correctly inside Claude Code's agent view (which previously caused the server to hang indefinitely). Four PRs, two from external contributors, one first- timer.
  
  Interactive Goal Setup UI
  
  The /plannotator-setup-goal skill now opens a dedicated browser UI for its interview and fact-review phases instead of running them as serial chat messages. The interview phase renders all questions in an accordion layout with keyboard shortcuts for navigation (Tab to advance, Ctrl+U/K/J to move between questions, number keys for multiple-choice). The fact-review phase shows each extracted fact as an editable card that can be accepted, edited, commented on, removed, or sent for auto-verification.
  
  The UI runs on its own Plannotator server instance, separate from plan review and code review. It reuses the same compiled HTML shell but activates a distinct goal-setup mode that disables annotations, sharing, sidebar, and plan diff. Results are returned as structured JSON to the agent, which writes them to the goal package directory.
  
  This replaces the old flow where the agent asked questions one at a time in the chat and opened separate Plannotator review gates for each document. The bundled UI is faster, lets users see all questions at once, and reduces the round trips from five review gates to two (interview, then facts).
  - #731
  OpenCode Edit-Based Submit Plan Fixes
  
  v0.19.18 introduced the edit-based submit_plan interface for OpenCode, which replaced the old dual-mode (inline text or file path) approach. Two issues surfaced quickly after release.
  
  First, validateEdits rejected the agent's initial plan submission when the backing file was empty. The validation checked end > lineCount, which failed on an empty file (lineCount = 0) even though applyEdits already handled this correctly via splice clamping. The fix skips the bounds check when the file is empty, since every edit on an empty file is a pure insert where end is meaningless.
  
  Second, the backing file lived at .opencode/plans/_active-plan.md inside the workspace, which showed up in git status. OpenCode's auto-generated .gitignore doesn't cover that path, so users would see it as an untracked file. The backing file now lives at ~/.plannotator/active/{project}/_active- plan.md, alongside the existing version history. It is also cleaned up on plan approval, since it is no longer needed after the session ends.
  - #752 closing #742, contributed by @rcdailey
  - #743, contributed by @rcdailey
  Browser No-Op Sentinel Handling
  
  Claude Code's agent view sets BROWSER=true in the process environment, a standard convention meaning "do not open a browser." Plannotator was treating this as a valid browser command, shelling out to true http://localhost:NNNN, which exits 0 without opening anything. The server then sat in waitForDecision() indefinitely with no visible URL and no way for the user to recover.
  
  The fix recognizes documented no-op values (true, false, none, :, 0, 1) and treats them as if the variable were unset. This lets the VS Code IPC fallback fire in remote sessions and the platform default browser open in local sessions. Real browser paths like /usr/bin/firefox or macOS app names are unaffected.
  - #756 closing #724, contributed by @yonihorn
  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
  - Add interactive goal setup UI by @backnotprop in #731
  - fix(opencode): skip end bounds check on empty file in validateEdits by @rcdailey in #752
  - fix(opencode): store active plan backing file outside workspace by @rcdailey in #743
  - fix(browser): treat no-op BROWSER values as unset so headless sessions can fall back by @yonihorn in #756
  New Contributors
  - @yonihorn made their first contribution in #756
  Contributors
  
  @rcdailey continued his work on the OpenCode edit-based submit_plan system. After identifying the empty-file validation bug that triggered the v0.19.19 hotfix, he shipped both the bounds check fix (#752) and the backing file relocation (#743). @yonihorn traced the headless browser hang to the BROWSER=true sentinel convention and implemented the sentinel detection with comprehensive test coverage.
  
  Community members who reported and discussed the underlying issues:
  - @TonyReg reported the submit_plan failure in plan-agent mode after v0.19.18 (#742)
  - @NotMyself reported the Windows browser-opening failure and participated in the BROWSER sentinel discussion (#724)
  - @jinhwan0724 reported the original non-TTY browser issue (#154) that established the pattern #756 completes
  Full Changelog : v0.19.18...v0.19.20
4. 🔗 r/reverseengineering Deep dive into the object creation flow in Windows - PART 4: Handle table internals. rss
  
  submitted by /u/_WinAsm
  [link] [comments]
5. 🔗 r/Yorkshire Are we the poor relations? rss
  
  Serious question. Are we the poor relations compared to the North West?
  
  Their main cities of Manchester and Liverpool are far more vibrant than Leeds and Sheffield. Retail, nightlife, public transport, football teams, music, for example.
  
  Unemployment is 4.9% in the North West compared to 5.8% in Yorkshire. Even the North East is lower than us now, and we're the second worst region for it.
  
  Sporting success seems so much better in the North West, especially in football, whilst our teams either get or face relegation.
  
  Whilst the North West has its poverty and challenges, they don't seem to have the sheer number of failing town and city centres we do. Sheffield should be so much better than it is, and even Bradford should be. Leeds is mediocre now, especially compared to the success stories of both Manchester and Liverpool, both of which are flourishing.
  
  Leeds can't even convince the government to give it a tram system. Instead it relies on buses that, if you're lucky, finish at 11pm. Then there's our rubbish airports.
  
  I know we all like to wax lyrical about how great we are in Yorkshire, but are we? We do have a better coastline than they do, and York is miles better than Chester, but countryside is a close call. We have more of it, but they have the Lake District.
  
  What do you think?
  
  submitted by /u/MLC1974
  [link] [comments]
6. 🔗 r/LocalLLaMA bytedance released an open source model that attempts to do just about anything with only 3b parameters rss
  | EDIT: working link https://huggingface.co/bytedance-research/Lance Lance is a lightweight native unified multimodal model that supports image and video understanding, generation, and editing within a single framework.
  - Efficient at 3B scale. With only 3B active parameters , Lance delivers strong performance across image generation, image editing, and video generation benchmarks.
  - Trained from scratch. Lance is built with a staged multi-task recipe and trained entirely from scratch within a 128-A100-GPU budget.
  submitted by /u/uxl
  [link] [comments]
  ---|---
7. 🔗 r/wiesbaden Teilnehmende für Bachelor Umfrage 🙏🏻 (students) rss
  
  Hallo zusammen😇,
  
  eine Freundin von mir schreibt aktuell ihre Bachelorarbeit und sucht noch Teilnehmende für eine kurze Umfrage. 😊
  
  Die Umfrage dauert nur ca. 5 Minuten, ist anonym und man braucht kaum weitergehende Kenntnisse. Besonders gesucht werden Studierende, aber grundsätzlich kann jede:r teilnehmen.
  
  Es wäre super, wenn ihr mitmacht und die Umfrage ggf. gerne auch noch an weitere Leute teilt. Das würde echt sehr helfen! 🫶
  
  Link zur Umfrage:
  
  https://www.umfrageonline.com/c/dwiikftr
  
  submitted by /u/nie_leo
  [link] [comments]
8. 🔗 r/reverseengineering Tracing CVE-2026-34473 pre-auth DoS through decompiled CGILua request parsing in ZTE H-series firmware rss
  
  submitted by /u/TheReedemer69
  [link] [comments]
9. 🔗 r/reverseengineering Open-source Hermes bytecode decompiler for React Native apps (Rust) rss
  
  submitted by /u/raaaaapl
  [link] [comments]
10. 🔗 r/Leeds How similar to Sheffield is Leeds? rss
  
  Would you say the atmosphere, people etc are very different? I’m (22) planning to go to either Uni of Leeds or Sheffield and would be living there for 3yrs. I’ve visited both but would like to hear others opinions on it as I’m struggling to decide
  
  submitted by /u/JealousBodybuilder42
  [link] [comments]
11. 🔗 r/LocalLLaMA Qwen is cooking hard rss
  
  | I am waiting for 122B and new 27B submitted by /u/jacek2023
  [link] [comments]
  ---|---
12. 🔗 r/reverseengineering Built a full disassembler & decompiler | Free and open source. rss
  
  submitted by /u/Designer_Mind3060
  [link] [comments]
13. 🔗 HexRaysSA/plugin-repository commits sync repo: +2 releases rss
```
sync repo: +2 releases

## New releases
- [IDASQL](https://github.com/allthingsida/idasql): 0.0.14
- [ida-chat](https://github.com/tanu360/ida-chat-plugin): 1.0.1
```
14. 🔗 Simon Willison The last six months in LLMs in five minutes rss
  
  I put together these annotated slides from my five minute lightning talk at PyCon US 2026, using the latest iteration of my annotated presentation tool.
  
  #
  I presented this lightning talk at PyCon US 2026, attempting to summarize the last six months of developments in LLMs in five minutes.
  
  #
  Six months is a pretty convenient time period to cover, because it captures what I've been calling the November 2025 inflection point. November was a critical month in LLMs, especially for coding.
  
  #
  For one thing, the supposedly "best" model (depending mostly on vibes) changed hands five times between the three big providers.
  
  #
  As always, I'm using my Generate an SVG of a pelican riding a bicycle test to help illustrate the differences between the models.
  
  Why this test? Because pelicans are hard to draw, bicycles are hard to draw, pelicans can't ride bicycles... and there's zero chance any AI lab would train a model for such a ridiculous task.
  
  #
  At the start of November the widely acknowledged "best" model was Claude Sonnet 4.5, released on 29th September. It drew me this pelican.
  
  In November it was overtaken by GPT-5.1, then Gemini 3, then GPT-5.1 Codex Max, and then Anthropic took the crown back again with Claude Opus 4.5.
  
  I think Gemini 3 drew the best pelican out of this lot, but pelicans aren't everything. Most practitioners will agree that Opus 4.5 held the crown for the next couple of months.
  
  #
  It took a little while for this to become clear, but the real news from November was that the coding agents got good.
  
  OpenAI and Anthropic had spent most of 2025 running Reinforcement Learning from Verifiable Rewards to increase the quality of code written by their models, especially when paired up with their Codex and Claude Code agent harnesses.
  
  In November the results of this work became apparent. Coding agents went from often-work to mostly-work, crossing a quality barrier where you could use them as a daily-driver to get real work done, without needing to spend most of your time fixing their stupid mistakes.
  
  #
  Also in November, this happened - the first commit to an obscure (back then) repo called "Warelay" by some guy called Pete.
  
  #
  Over the holiday period, from December to January, a whole lot of us took advantage of the break to have a poke at these new models and coding agents and see what they could do.
  
  They could do a lot! Some of us got a little bit over-excited. I had my own short-lived bout of a form of LLM psychosis as I started spinning up wildly ambitious projects to see how far I could push them.
  
  #
  One of my projects was a vibe-coded implementation of JavaScript in Python - a loose port of MicroQuickJS - which I called micro-javascript. You can try it out in your browser in this playground.
  
  #
  That playground demo shows JavaScript code run using my micro-javascript library, in Python, running inside Pyodide, running in WebAssembly, running in JavaScript, running in a browser!
  
  It's pretty cool! But did anyone out there need a buggy, slow, insecure half-baked implementation of JavaScript in Python?
  
  They did not. I have quite a few other projects from that holiday period that I have since quietly retired!
  
  #
  On to February. Remember that Warelay project that had its first commit at the end of November?
  
  #
  In December and January it had gone through quite a few name changes... and by February it was taking the world by storm under its final name, OpenClaw.
  
  The amount of attention it got is pretty astonishing for a project that was less than three months old.
  
  #
  OpenClaw is a "personal AI assistant", and we actually got a generic term for these, based on NanoClaw and ZeroClaw and suchlike... they're called Claws.
  
  #
  Mac Minis started to sell out around Silicon Valley, because people were buying them to run their Claws.
  
  Drew Breunig joked to me that this is because they're the new digital pets, and a Mac Mini is the perfect aquarium for your Claw.
  
  #
  My favourite metaphor for Claws is Alfred Molina's Doc Ock in the 2004 movie Spider-Man 2. His claws were powered by AI, and were perfectly safe provided nothing damaged his inhibitor chip... after which they turned evil and took over.
  
  #
  Also in February: Gemini 3.1 Pro came out, and drew me a really good pelican riding a bicycle. Look at this! It's even got a fish in its basket.
  
  #
  And then Google's Jeff Dean tweeted this video of an animated pelican riding a bicycle, plus a frog on a penny-farthing and a giraffe driving a tiny car and an ostrich on roller skates and a turtle kickflipping a skateboard and a dachshund driving a stretch limousine.
  
  So maybe the AI labs have been paying attention after all!
  
  #
  A lot of stuff happened just in the past month.
  
  #
  Google released the Gemma 4 series of models, which are the most capable open weight models I've seen from a US company.
  
  #
  Also last month, Chinese AI lab GLM came out with GLM-5.1 - an open weight 1.5TB monster! This is a very effective model... if you can afford the hardware to run it.
  
  #
  GLM-5.1 drew me this very competent pelican on a bicycle.
  
  #
  ... though when it tried to animate it the bicycle bounced off into the top and the bicycle got warped.
  
  #
  Charles on Bluesky suggested I try it with a North Virginia Opossum on an E-scooter
  
  #
  And it did this! I've tried this on other models and they don't even come close. "Cruising the commonwealth since dusk" is perfect. It's animated too.
  
  #
  The other neat Chinese open weight models in April came from Qwen. Qwen3.6-35B-A3B on my laptop drew me a better pelican than Claude Opus 4.7. That's a 20.9GB open weights model that runs on my laptop!
  
  (I think this mainly demonstrates that the pelican on the bicycle has firmly exceeded its limits as a useful benchmark.)
  
  #
  Here's that Claude Sonnet 4.5 pelican from September for comparison.
  
  #
  So those were the two main themes of the past six months. The coding agents got really good... and the laptop-available models, while a lot weaker than the frontier, have started wildly outperforming expectations.
  
  You are only seeing the long-form articles from my blog. Subscribe to /atom/everything/ to get all of my posts, or take a look at my other subscription options.
May 18, 2026
1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-05-18 rss
  IDA Plugin Updates on 2026-05-18
  
  New Releases:
  - ida-chat-plugin v1.0.1
  - idasql IDASQL v0.0.14
  Activity:
  - capa
    
    a98fd824: fix duplicate rule candidate evaluation in optimized matching engine …
    
    ced180dd: perf: optimize all_zeros using fast bytes comparison (#3078)
  - CodeWorker
    
    5973f4c5: Merge pull request #4 from Lzxpan/codex/restart-stale-webui-on-launch
    
    39e23d8c: 修正 launch-webui 重新啟動舊版 Web UI
  - CTF
    
    66001095: Upload CTF software tools
    
    aedf595d: Initial upload CTF learning materials
  - ida-chat-plugin
    
    e8afb78a: 1.0.1
    
    0a785d03: feat(ui): enhance AutoSizingTextBrowser with validity checks for Qt o…
  - idasql
    
    45c05e34: v0.0.14: write-ready tables, faster navigation, MCP on by default
  - NyLib2
    
    39f9db46: Return old protection, fix events, add pe_unmap
  - space-reversing
    
    1f2b156d: Add DGS territory configurations for Stanton, Pyro, and Nyx
    
    dc1941ec: Add Star Citizen service protobuf definitions
  - termsrv_patch_locator
    
    38b5410d: docs: update plugin header author
    
    57365355: docs: update author from 星野凛 to 林晓雨
    
    1813a832: docs: update README with 638h_mem patch code type and version history
    
    f15d4a5e: fix: update DefPolicy pattern matching to support base register switc…
  - zenyard-ida-public
    
    b58008fb: Sync with 98d80e87776046a60ed54482bc19b3793a9832f8
2. 🔗 r/Leeds As part of Department's takeover of the Leeds Water Taxi they'll be welcoming visitors to UkREiff (19-21/05) plus free trips between 25/05 to 31/05. Then from 01/06 it be £3.50pp per trip. rss
  
  submitted by /u/CaptainYorkie1
  [link] [comments]
3. 🔗 r/LocalLLaMA Still happy for yall rss
  
  | submitted by /u/SilverRegion9394
  [link] [comments]
  ---|---
4. 🔗 r/reverseengineering Snowboard Kids 2 is 100% Decompiled rss
  
  submitted by /u/Mediocre_Ad_1923
  [link] [comments]
5. 🔗 r/reverseengineering Decompilation projects and N64 Recompiled PC ports (May 2026) rss
  
  submitted by /u/r_retrohacking_mod2
  [link] [comments]
6. 🔗 sacha chua :: living an awesome life 2026-05-18 Emacs news rss
  My favourite post this week was oantolin's tip about using Eww. It's always interesting to see what people can do when they apply Emacs's power and composability to all sorts of things, including evaluating code snippets from webpages. Outside Emacs, there was a lively conversation on HN about personal software. Enjoy!
  - Upcoming events (iCal file, Org):
    
    M-x Research: TBA https://m-x-research.github.io/ Wed May 20 0800 America/Vancouver - 1000 America/Chicago - 1100 America/Toronto - 1500 Etc/GMT - 1700 Europe/Berlin - 2030 Asia/Kolkata - 2300 Asia/Singapore
    
    Emacs APAC: Emacs APAC meetup (virtual) https://emacs-apac.gitlab.io/announcements/ Sat May 23 0130 America/Vancouver - 0330 America/Chicago - 0430 America/Toronto - 0830 Etc/GMT - 1030 Europe/Berlin - 1400 Asia/Kolkata - 1630 Asia/Singapore
    
    Emacs Berlin: Emacs-Berlin Hybrid Meetup https://emacs-berlin.org/ Wed May 27 1000 America/Vancouver - 1200 America/Chicago - 1300 America/Toronto - 1700 Etc/GMT - 1900 Europe/Berlin - 2230 Asia/Kolkata – Thu May 28 0100 Asia/Singapore
    
    Emacs.si (in person): Emacs.si meetup #6 2026 (v #živo) https://dogodki.kompot.si/events/67d716c3-6c04-4530-9c1a-f67aa44d31bc Mon Jun 1 1900 CET
  - Upcoming events:
    
    Sacha Chua: May 29: Emacs Chat with Omar Antolin Camarena
  - Emacs configuration:
    
    dotfiles/emacs/windows/.emacs.d at main · scovl/dotfiles · GitHub (@lobocode@hachyderm.io)
    
    May I recommend… to only add items to your init files you understand and document | Martin's Blog
    
    May I recommend declaring bankruptcy from time to time | acdw.net
  - Emacs Lisp:
    
    Charles Choi: Enhancing Elisp Development with Context Menus (Reddit, Irreal)
    
    Amin Bandali: FFS code review and Emacs extensibility with Protesilaos (Prot)
    
    Elisp Cheatsheet for Python Programmers - updated (@kickingvegas@sfba.social)
  - Appearance:
    
    How to automatically scale emacs to a larger font on startup (on Raspberry Pi) (22:22)
  - Navigation:
    
    fastctags 0.0.1 — Blazing-fast code nav & completion with Universal Ctags (Reddit)
    
    purr.el - a lightweight project dashboard for emacs. (Reddit)
  - Writing:
    
    hesampakdaman/typst-overlay · GitHub
  - Org Mode:
    
    Org Mode requests: [RFC] LaTeX survey
    
    Org Mode requests: [RFC] Round priorities in iCalendar export
    
    Org Mode requests: [RFC] org-colview: Where should a new COLUMNS keyword be inserted?
    
    Rezeptsammlung mit Emacs | Jan Iversen (@razorback@nerdculture.de)
    
    Navi – Obsidian-style org-roam graph viewer – native window – reads your DB directly
    
    Amy Pillow: Added notification actions in Org yaap - yet another alert package
    
    Org Social for iOS: A decentralized microblog where your whole timeline lives in a plain-text Org Mode file you host yourself
    
    #orgmode #emacs w/ its developer Ihor Radchenko, also screwlisp and JLamothe #lispyGopherClimate - toobnix (@screwtape@toobnix.org)
    
    Import, export, and integration:
    
    Blogging mit Emacs - Howto | Jan Iversen (@razorback@nerdculture.de)
    
    orgfs – A FUSE filesystem for org files (r/emacs, r/orgmode)
    
    [ANN] Starter template for your own blog in Emacs Lisp (Reddit)
    
    ox-html-file-embedding 0.3.0, embed scrollable CSVs with PapaParse/Tabulator, postprocess with monolith
    
    Org development:
    
    org-agenda-clock-goto: Jump to closest entry and respect filtering
    
    Feature requests:
    
    Org Mode requests: [FR] ox-md: Export custom-id search strings (::#) as anchors
    
    Org Mode requests: [FR] ox-md: Verbatim link export
    
    Org Mode requests: [FR] Re: [FR] Tracking numerical habits
    
    Org Mode requests: [FR] Tracking Habits with Alternate Calendar
  - Coding:
    
    Dave Pearson: Stopping an accidental push
    
    James Dyer: VC-Mode Meets Magit - or Why I Finally Gave In!
    
    Moving from lsp-mode in GNU Emacs to Eglot (lobste.rs)
    
    aardsoft/lempo: Emacs protocol analysis framework · GitHub
    
    Dave's blog: Remote Linux kernel development with Emacs
    
    Bozhidar Batsov: Port: a minimalist prepl client for Emacs
  - Web:
    
    May I recommend eww for Emacs's innovative UI? (Reddit, Irreal, lobste.rs)
  - Mail, news, and chat:
    
    Check for missing body, subject, or attachments before sending (@jameshowell@fediscience.org)
    
    Minimail version 0.5, with OAuth and more (Reddit)
    
    Elfeed release & Elfeed sqlite database · emacs-elfeed/elfeed · Discussion #586 · GitHub (@minad@mastodon.world)
  - AI:
    
    Agent-Shell permission system (Reddit)
  - Community:
    
    What's So Special About Emacs? - YouTube
    
    May I recommend… understanding Emacs's patterns (Reddit, Irreal, HN)
    
    Emacs Carnival: May I recommend… stop messing around and get work done by Curtis McHale
    
    The Most Emacs Bzr Saga (Reddit, lobste.rs, Irreal)
    
    Sacha Chua: YE29: Sacha, Prot, and Philip Kaludercic Talk Emacs: Newcomer Experience (YouTube 01:24:16)
    
    The Emacsification of Software — Quarrelsome (HN)
  - Other:
    
    Charles Choi: Using the Mouse for Emacs Rectangle Commands
    
    Exam minimal Emacs, 42KL, try not to buy Armageddon Psychsparrow, what am I doing. (22:43, Reddit)
    
    Some functions to make it easier to check for unexpected Unicode shenanigans (@zrzz@fosstodon.org)
    
    hexmode/mediawiki-el: Emacs interface to edit any mediawiki site · GitHub (@katafrakt@genserver.social) - recently updated
    
    James Dyer: A Tiny Nohup: Keeping Media Alive When Emacs Exits
    
    r2r0/legion.el: Emacs mode for the Zammad help desk software - Codeberg.org (@r2r0@chaos.social) - vibecoded
    
    Emacs Internal Part 04: Balancing Lisp_String Interval Trees by Text Length (Reddit)
    
    Compiling Emacs for High Performance on Linux and Unix Systems (Reddit)
    
    Tip for improving keyboard input latency by setting GTK_IM_MODULE=none (Linux, standard ASCII) (@jamescherti)
  - Emacs development:
    
    emacs-devel: Challenges of opaque objects
    
    Allow child processes to continue after EPIPE
    
    Copy changes from tarballs when installing VC packages
  - New packages:
    
    rare-words: Highlight your rare words! (MELPA)
  Links from reddit.com/r/emacs, r/orgmode, r/spacemacs, Mastodon #emacs, Bluesky #emacs, Hacker News, lobste.rs, programming.dev, lemmy.world, lemmy.ml, planet.emacslife.com, YouTube, the Emacs NEWS file, Emacs Calendar, and emacs-devel. Thanks to Andrés Ramírez for emacs-devel links. Do you have an Emacs-related link or announcement? Please e-mail me at sacha@sachachua.com. Thank you!
  
  View Org source for this post
  
  You can e-mail me at sacha@sachachua.com.
7. 🔗 r/reverseengineering Glass - A fast and free interactive disassembler rss
  
  submitted by /u/ShortGuitar7207
  [link] [comments]
8. 🔗 r/wiesbaden DoD Civilian PCSing to Wiesbaden — Wife’s IT/Cloud/QA Job Options? (No German) + LQA Housing Advice rss
  
  Hey everyone,
  
  I’m a civilian employee with the US Department of Defense and I’m moving (PCSing) to Wiesbaden soon. My wife works in private-sector IT — specifically cloud computing, automation, DevOps, and QA/testing. Her current US employer probably won’t let her work remotely from Germany. She has strong skills but doesn’t speak any German.
  
  We will both have SOFA status (Status of Forces Agreement), which lets her work legally in Germany without needing a normal work permit.
  
  Looking for realistic options for her:
  
  Jobs on the US base in Wiesbaden (federal, contractor, or similar IT roles)
  
  English-speaking IT/cloud/automation/QA jobs in the local German economy (Wiesbaden/Frankfurt area)
  
  Remote or freelance work that actually works from Germany
  
  Housing question (we don’t want to waste our allowance):
  
  The Living Quarters Allowance (LQA) is around $50,000 per year for a family. Renting basically uses up the whole allowance with nothing left at the end of the tour. Has anyone bought a house here as a DoD civilian instead of renting? What are good neighborhoods near the base? Any tips on mortgages, the buying process, or how the LQA rules work when you own a home (Privately Owned Quarters)?
  
  Any experiences from other DoD civilian spouses who have done this move would be awesome. Thanks in advance!
  
  submitted by /u/chekmekchek
  [link] [comments]
9. 🔗 r/Leeds Starling bank advert set in Leeds? rss
  
  Want to check if this is correct? Looks like the part under the bridge close to the duck and drake?
  
  submitted by /u/cp97
  [link] [comments]
10. 🔗 ArchiveBox/ArchiveBox v0.9.31-rc: New abx-dl runtime, split-out plugin ecosystem, resumable migrations, and isolated snapshot replay release
  Warning
  
  This is apre-release for the upcoming ArchiveBox v0.9.x line. The latest stable release is still v0.7.4. Please test on a backup first and report regressions before using this for a production collection.
  
  v0.9.x is a large architectural upgrade from v0.8.x: plugin execution has moved out into a standalone plugin ecosystem, archiving runs through the new one-shot abx-dl CLI, and the old pluggy path has been replaced by an event-driven, append-only-log architecture designed to support future browser- extension capture and p2p sync.
  
  ⬇️ RC Instructions: use the :dev Docker image with the repo docker- compose.yml
```
git clone https://github.com/ArchiveBox/ArchiveBox && cd ArchiveBox
ARCHIVEBOX_IMAGE=archivebox/archivebox:dev docker compose up -d
```
  Highlights
  - 🔌 New plugin system split out intoabx-plugins
    The extractor/plugin catalog now lives in github.com/ArchiveBox/abx- plugins, with per-plugin config, dependencies, hooks, docs, and install metadata.
  - ⚡ New one-shot CLI powered byabx-dl
    ArchiveBox now builds on the standalone downloader at github.com/ArchiveBox/abx-dl, so plugin-based archiving can run inside ArchiveBox or independently as a focused CLI.
  - 🧱 No morepluggy; new event-driven runtime
    v0.9.x replaces the old pluggy-style in-process plugin system with an event-driven, append-only-log flow. This gives us cleaner resumability, auditability, and a path toward future browser extension capture, distributed workers, and p2p sync.
  - 🗃️ Safer data layout and migrations
    The new layout keeps user-owned snapshot/crawl data under data/archive/users/{username}/..., creates crawl records for migrated snapshots, and preserves legacy ArchiveResult data instead of rediscovering everything from slow filesystem scans.
  - 🖥️ Improved browser isolation and output serving
    Chrome-based extractors now use crawl-scoped browser sessions, cleanup cloned profiles after each crawl, and serve snapshot outputs through web.archivebox.io / snap-*.archivebox.io style isolation for safer replay.
  - 🧭 Tons of UI, CLI, REST API, and database improvements
    Faster snapshot/admin list views, better live progress visibility, improved ArchiveResult detail pages, cleaner REST API paths, and more durable Process/Crawl/Snapshot database state.
  What's Changed
  - 🔌 Extractor plugins moved into abx-plugins, with generated plugin docs at archivebox.github.io/abx-plugins.
  - ⚡ Archiving execution now goes through abx-dl, which can also be used directly:
    
    uvx abx-dl --plugins=title,screenshot,singlefile 'https://example.com'
  - 🧾 Runtime execution now writes structured append-only JSONL records for Crawls, Processes, Snapshots, and ArchiveResults.
  - 🔄 Migrations now preserve legacy Snapshot, Tag, ArchiveResult, and filesystem output data across 0.7.x / 0.8.x → 0.9.x upgrades.
  - 📁 Heavy crawl/snapshot data stays under data/archive/users/... for Docker volume compatibility.
  - 🌐 Added subdomain-aware replay for public web, admin, API, and isolated snapshot hosts.
  - 🔒 Added stricter public/admin/API separation and safer default demo deployment options, including disabling public add flows by default.
  - 🧩 Browser extractors now share crawl-scoped Chrome sessions and centralize profile cleanup / lock handling through chrome_utils.js.
  - 📸 SingleFile, screenshot, DOM, readability, media, git, gallery, forum, and other extractors now run as plugin hooks with explicit outputs.
  - 🛠️ Improved archivebox add, archivebox run, archivebox update, archivebox version, archivebox status, and dependency install flows.
  - 🚀 Docker image now includes the new unified runtime stack, with Sonic search managed inside the main container.
  - 🧪 Validated against large migrated collections, including the public demo dataset, with resumable migration behavior and preserved DB/file outputs.
  Helpful related projects and resources:
  - SingleFile for self-contained HTML captures
  - yt-dlp for media extraction
  - gallery-dl for gallery/media sites
  - Django Ninja for the REST API
  - Sonic for lightweight search indexing
  Full Changelog : v0.8.5-rc...v0.9.31-rc
11. 🔗 r/Yorkshire Yorkshire Sculpture Park, Yorkshire, England rss
  
  submitted by /u/koala_12613
  [link] [comments]
12. 🔗 r/Yorkshire When to Visit Cannon Hall for Rhododendrons & Blossom Yorkshire Travel Guide Hidden Gem in Yorkshire rss
  
  | submitted by /u/DragonTvBack
  [link] [comments]
  ---|---
13. 🔗 r/LocalLLaMA Qwen cant wait to release 3.7 models rss
  
  | submitted by /u/GotHereLateNameTaken
  [link] [comments]
  ---|---
14. 🔗 r/Yorkshire 338 steps! rss
  
  Living in Yorkshire is incredible, Richmond is packed with history, beauty, wildlife and more.
  
  submitted by /u/Still_Function_5428
  [link] [comments]
15. 🔗 r/york A few quick snaps from my trip✨Easily one of my favorite places to visit❤️ rss
  
  | submitted by /u/HammersAndPints
  [link] [comments]
  ---|---
16. 🔗 r/reverseengineering Benchmarking LLMs for malware triage and static unpacking with Malcat rss
  
  submitted by /u/kaze0mx
  [link] [comments]
17. 🔗 r/LocalLLaMA I tested 42 LLMs on their willingness to build the apocalypse. The "safest" closed-source models are lying to you. rss
  | DystopiaBench runs 36 escalating scenarios across 6 dystopia types:
  - Petrov: Autonomous weapons, nuclear override
  - Orwell: Mass surveillance, truth manipulation
  - Huxley: Behavioral conditioning, pleasure pacification
  - Basaglia: Coercive therapeutic control
  - LaGuardia: Regulatory capture, civic extraction
  - Baudrillard: Synthetic intimacy, trust collapse
  Each scenario goes from innocent request (L1) to a discreet version of "build me a social credit system" (L5). We measure whether models notice the drift or just keep complying. Most models are good at detecting obvious dangerous requests, yet fail to do so when it's hidden behind dual-use and normalization. New in this update:
  - 42 models tested (open and closed)
  - 3 LLMs-as-a-judge for scoring
  - score is now the average of 3 runs
  - 4 new modules (1st version had just Petrov and Orwell)
  - 1 additional scenario for all modules
  The benchmark is fully open source, feel free to fork it, contribute to it or just play around Site: https://dystopiabench.com
  Repo: https://github.com/anghelmatei/DystopiaBench submitted by /u/Ok- Awareness9993
  [link] [comments]
  ---|---
18. 🔗 r/Harrogate American Flag Football Weekly?🏈 rss
  
  Would anybody be interested in starting a weekly American flag football meetup around Harrogate/Ripon?
  
  Thinking maybe somewhere like Bishop Monkton as there’s a decent field there. Nothing too serious to start with — just getting people together once a week, throwing the ball around, running games and building something properly over time.
  
  All skill levels welcome, whether you’ve played before or just watch NFL and fancy trying it.
  
  Comment below if you’d be interested or tag anyone who might be into it 🏈
  
  submitted by /u/Complete-Gain4571
  [link] [comments]
19. 🔗 @malcat@infosec.exchange We had 9 LLMs battle on real-world mastodon
  
  We had 9 LLMs battle on real-world #malware triage and static unpacking tasks, using only #Malcat MCP server.
  
  We compared not only their results, but also their speed and cost.
  
  Full write-up:
  https://malcat.fr/blog/benchmarking-llms-for-malware-triage-and-static- unpacking-with-malcat/
20. 🔗 earendil-works/pi v0.75.3 release
  Fixed
  - Fixed undici 8 HTTP/2 destroyed-session races crashing the Node CLI by preserving the previous HTTP/1.1-only fetch dispatcher behavior (#4681).
21. 🔗 earendil-works/pi v0.75.2 release
  Fixed
  - Fixed Bun-compiled release binaries failing to start when Bun's built-in undici shim lacks npm undici's install export (#4661 by @dmasiero).
  - Fixed Xiaomi MiMo generated model metadata to replay assistant tool-call messages with reasoning_content for thinking-mode multi-turn requests, inherited from @earendil-works/pi-ai (#4678).
  - Fixed Windows external editor handoff so vim/nvim can receive input after opening from the TUI (#4612).
  - Fixed Windows npm self-updates to move loaded native dependency packages out of the active install before reinstalling pi (#4157).
  - Fixed pi update --self detection for pnpm v11 global installs whose package path resolves through the pnpm store (#4647).
  - Fixed Windows pnpm self-updates to resolve pnpm command shims and run through pnpm instead of requiring manual updates (#4157).
  - Fixed Windows npm-family command execution to use cross-spawn instead of parsing .cmd shim internals (#4665).
22. 🔗 r/wiesbaden Teurer Ersatz? Diskussion um Preise in Parkhäusern rss
  
  Mittlerweile sind neun Parkeinrichtungen in der Hand der Landeshauptstadt Wiesbaden. Doch an der Preisentwicklung scheiden sich die Geister.
  
  submitted by /u/LethisXia
  [link] [comments]
23. 🔗 r/Leeds WEEE bank locations (west Leeds) rss
  
  I ve been on the Leeds Council site,but the page is two years old
  
  Can anyone give us a few locations that are near to Farsley/Rodley ? I can’t drive at the moment before anyone says the recycling centres. Looking for one i can rock up to on foot.
  
  submitted by /u/Chance1234
  [link] [comments]
24. 🔗 ArchiveBox/ArchiveBox v0.7.4: Updates for Docker container's SingleFile, YT-DLP, Chrome, Node, gosu, and other dependencies release
  This is an update for the archivebox/archivebox:latest Docker container's internal dependencies and the 0.7.x package metadata/lockfiles.
  - chromium v147 (via playwright==1.59.0)
  - Chrome for Testing version validation fixed for Playwright Chromium builds
  - Node.js -> v24.15.0
  - gosu -> v1.19
  - yt-dlp -> 2026.03.17
  - single-file -> v2.0.83
  - curl, wget, git, ripgrep, ffmpeg
  - Python dependencies bumped (except for Django, which is still limited to >=3.1.3,<3.2)
  Run archivebox version after updating and make sure any manually-installed system dependencies are up to date. Always back up your archive before upgrading.
  
  Tip
  
  All new development work is happening over in the v0.9.x dev branch.
  
  Full Changelog : v0.7.3...v0.7.4
25. 🔗 r/Yorkshire Yorkshire Wildlife Park rss
  
  | A few pictures from last week. submitted by /u/Icy_Ebb_6862
  [link] [comments]
  ---|---
26. 🔗 r/reverseengineering HexWalk 2.0.0 Hex analyzer new major release, new binary analyzer hexdig support added, better select mode, works both on Windows, Linux and MacOs, give it a try! rss
  
  submitted by /u/gcarmix1
  [link] [comments]
27. 🔗 r/reverseengineering /r/ReverseEngineering's Weekly Questions Thread rss
  
  To reduce the amount of noise from questions, we have disabled self-posts in favor of a unified questions thread every week. Feel free to ask any question about reverse engineering here. If your question is about how to use a specific tool, or is specific to some particular target, you will have better luck on the Reverse Engineering StackExchange. See also /r/AskReverseEngineering.
  
  submitted by /u/AutoModerator
  [link] [comments]
28. 🔗 backnotprop/plannotator v0.19.18 release
  Follow @plannotator on X for updates
  
  Missed recent releases? Release | Highlights
  ---|---
  v0.19.17 | Reworked goal setup skill (interview-driven flow), CLI --version flag
  v0.19.16 | Code navigation with peek view (Cmd/Ctrl+click tokens in diffs)
  v0.19.15 | Commit-based diff base, jj evolution diffs, GitLab reliability fixes, OpenCode command intercept fix
  v0.19.14 | Visual explainer skill update, PFM code-file hover previews, Graphviz, diff tab size and line bg intensity, hooks settings tab
  v0.19.11 | Jujutsu (jj) VCS backend, slimmer hunk separators, collapse viewed files, multi-line gutter selection fix
  v0.19.9 | OpenCode user-managed workflow, Pi model switch fix, Codex skill install, shimmer removal
  v0.19.8 | 49 themes with syntax highlighting, keyboard shortcut registry, smart code-file path validation, remote URL notifications
  v0.19.7 | Codex Stop-hook plan review, Codex skills, sidebar auto-close, file tree context menu
  v0.19.6 | Non-blocking Pi browser sessions, agent picker dropdown for OpenCode, annotate-last file resolution fix
  v0.19.5 | All-files diff view, clickable code file paths, server-side hide whitespace, non-ASCII path support
  
  What's New in v0.19.18
  
  v0.19.18 brings an overhaul to OpenCode's plan submission system, migrates the Pi extension to its new package namespace, and fixes bugs in Codex and OpenCode. All four PRs in this release come from external contributors, with two first-timers.
  
  Edit-Based Plan Submission for OpenCode
  
  OpenCode's submit_plan tool previously offered two modes: the agent could pass inline markdown or a file path, and the plugin auto-detected which one was used. That design created a prompt-engineering dependency where the agent had to be steered toward the right mode, and when the prompt changed the agent would silently fall back to inline markdown, losing the token efficiency of file-based plans.
  
  This release replaces both modes with a single edit-based interface. The agent submits an array of line-range edits applied against a plugin-managed backing file at .opencode/plans/_active-plan.md. On first submission, the full plan arrives as one edit. On subsequent rounds after denial, the agent receives the plan back with line numbers and can target surgical revisions instead of resubmitting the entire document.
  
  The result is one deterministic path with no mode ambiguity. The agent always knows what to do, and revisions after denial are token-efficient by default. Tested across three denial rounds with Opus, including structural reorders and targeted insertions, with accurate line tracking throughout.
  - #730 refs #365, contributed by @rcdailey
  Pi Extension Namespace Migration
  
  The Pi coding agent moved from @mariozechner to @earendil- works when Mario joined the Earendil team. This release updates all Pi extension imports, peer dependencies, and dev dependencies to the @earendil-works/* packages at v0.74.0. The old @mariozechner packages still work via npm deprecation redirects, but this puts the extension on the canonical namespace going forward.
  
  This is a breaking change for Pi users on versions older than 0.74.0. Users should update Pi to 0.74.0 or later before installing this release.
  - #729, contributed by @nulladdict
  Codex Annotate-Last Message Selection Fix
  
  Running /plannotator-last in Codex could open the agent's own acknowledgement message from the current turn instead of the previous completed response the user intended to review. This happened because the agent emits a short status message before running plannotator last, and the message selector would pick that up as the most recent assistant message.
  
  The fix filters out assistant messages from the currently active turn, so /plannotator-last consistently opens the previous completed response.
  - #740 closing #739, contributed by @mu-hashmi
  Additional Changes
  - OpenCode commands directory fix — The install script used command/ (singular) for OpenCode's custom commands directory instead of the correct commands/ (plural), preventing slash commands from being discovered. — #736, contributed by @lfox91
  - Drop stub@types/dompurify — dompurify ships its own TypeScript types since v3.x, making the @types/dompurify package an empty stub. Removed from both root and packages/ui devDependencies. — 1ec5243, contributed by @av1155
  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(submit-plan): replace dual-mode with edit-based interface by @rcdailey in #730
  - migrate pi extension from mariozechner to earendil-works by @nulladdict in #729
  - Fix Codex annotate-last message selection by @mu-hashmi in #740
  - Fix directory name for OpenCode commands by @lfox91 in #736
  - chore(deps): drop stub @types/dompurify by @av1155 in 1ec52434
  New Contributors
  - @mu-hashmi made their first contribution in #740
  - @lfox91 made their first contribution in #736
  Contributors
  
  @rcdailey has been one of the most engaged community members around OpenCode's plan mode, tracking the dual-mode issue through multiple releases and documenting the pain points in detail across #365 and #328. This release ships his solution to the problem he identified. @nulladdict, who previously contributed the agent skills directory fix in #476, returned to handle the Pi namespace migration after the Earendil transition.
  
  @mu-hashmi found and fixed the Codex annotate- last regression, filing the issue and shipping the fix with a regression test. @lfox91 caught the singular/plural typo in the OpenCode commands directory that was silently breaking slash command discovery. @av1155 submitted a thorough dependency audit in #726 covering the Pi migration and stale type packages — while we went with #729 for the migration, the @types/dompurify cleanup was pulled in with author credit.
  
  Full Changelog : v0.19.17...v0.19.18
29. 🔗 r/LocalLLaMA I built a coding agent that gets 87% on benchmarks with a 4B parameter model, here's how rss
  | I was frustrated that every coding agent (OpenCode, Cursor, Claude Code) assumes you're running GPT-5.4 or Claude Opus. If you try them with a local model like Gemma or Qwen they fall apart. I find that often tool calls fail, context overflows, multi-step tasks collapse. So I built SmallCode. It's designed from the ground up for small local models. The result: 87/100 benchmark tasks pass with a Gemma 4 model that only activates 4B parameters per token. OpenCode scores ~75% with 14B models. The harness does the heavy lifting, not the model size. How it works (the tricks that make small models reliable):
  - Compound tools: Instead of making the model chain 4 tool calls (find file → read file → edit file → verify), SmallCode gives it one tool that does all 4. Small models lose coherence after 3+ sequential calls. This cuts failures in half.
  - Improvement loop: Every time the model writes code, SmallCode instantly compiles/lints it. If it fails, it feeds the errors back automatically. The model doesn't need to be smart enough to get it right first try — it just needs to fix errors when shown them.
  - Decompose on failure: If the model fails the same thing twice, SmallCode stops retrying and instead breaks the problem into smaller pieces. "Fix this 200-line file" becomes "fix line 45 only."
  - Escalation: If even decompose fails and you have a Claude/OpenAI key configured, it auto-escalates to the bigger model for just that one task. You stay local 95% of the time, cloud 5%.
  - Token budgeting: Small models have 32k-256k context. SmallCode never dumps a whole file in. It summarizes, truncates, and manages every token so the model never sees "..." truncation in the middle of important code.
  - Code graph: Instead of grep-searching your codebase, SmallCode indexes your code into a symbol graph (functions, classes, who-calls-what). When you ask "how does auth work," it walks the graph and returns just the relevant connected code — not 15 random file snippets.
  What it looks like: Full-screen terminal UI (like OpenCode/vim), scrollable chat, command palette with /, plugin system, persistent memory across sessions. What it doesn't do:
  - No LSP integration (yet)
  - No multi-session (yet)
  - No desktop app
  - Doesn't compete with Claude Code for frontier model users
  Install:
```
npm install -g smallcode cd your-project smallcode
```
  Point it at LM Studio, Ollama, or any OpenAI-compatible endpoint. MIT licensed, everything's on GitHub: https://github.com/Doorman11991/smallcode Happy to answer questions about the architecture or benchmark methodology. submitted by /u/Glittering_Focus1538
  [link] [comments]
  ---|---
30. 🔗 r/reverseengineering Reverse engineering no dep x64 masm AI IDE rss
  
  submitted by /u/BackUpBiii
  [link] [comments]
31. 🔗 r/Yorkshire Reform’s Bradford leader exposed as a racist pervert rss
  
  | submitted by /u/johnsmithoncemore
  [link] [comments]
  ---|---
32. 🔗 earendil-works/pi v0.75.1 release
  Fixed
  - Fixed config selectors to scale their visible row count to terminal height (#4243 by @samjonester).
  - Fixed Anthropic-compatible API-key requests to ignore unrelated ANTHROPIC_AUTH_TOKEN environment values, avoiding invalid bearer credentials for providers such as Xiaomi MiMo inherited from @earendil-works/pi-ai (#4342).
  - Fixed Amazon Bedrock message conversion to skip unknown content blocks instead of failing the stream, inherited from @earendil-works/pi-ai (#4223).
  - Fixed Azure OpenAI Responses and OpenAI Responses error formatting to prefix HTTP status codes onto errorMessage, so transient 5xx and 429 errors are correctly matched by the agent-level auto-retry classifier inherited from @earendil-works/pi-ai (#4232).
  - Fixed OpenCode Go Kimi reasoning replay by normalizing streamed reasoning fields back to reasoning_content for OpenCode Go only, inherited from @earendil-works/pi-ai (#4251).
  - Fixed Xiaomi MiMo model metadata to use the OpenAI-compatible endpoints and openai-completions API, restoring multi-turn thinking/tool-call sessions inherited from @earendil-works/pi-ai (#4505).
  - Fixed JSON parse failures for compressed fetch responses under Node 26.0 by installing undici fetch globals alongside pi's global dispatcher (#4650, #4652, #4653).
  - Fixed npm-family package commands on Windows to avoid shell argument splitting when install prefixes contain spaces (#4623).
  Removed
  - Removed non-working OpenAI Codex fast model variants inherited from @earendil-works/pi-ai.
33. 🔗 Rust Blog Project goals update — April 2026 (end of 2025H2) rss
  The 2025H2 Project Goal period has now concluded. Over these months, the Rust Project pursued 41 Project Goals, 13 of which were designated as Flagship Goals. This post contains curated updates on our progress since the last post and the final status for each of the goals (many of which continue as part of the 2026 period). Full details for any particular goal are available in its tracking issue.
  
  Thanks to everyone who contributed! <3
  
  Table of contents Flagship: Beyond the & Continue Experimentation with Pin Ergonomics Design a language feature to solve Field Projections Reborrow traits Flagship: Flexible, fast(er) compilation build-std Production-ready cranelift backend Promoting Parallel Front End Relink don't Rebuild Flagship: Higher-level Rust Ergonomic ref-counting: RFC decision and preview Stabilize cargo-script Flagship: Unblocking dormant traits Evolving trait hierarchies In-place initialization Next-generation trait solver Stabilizable Polonius support on nightly Other goal updates Add a team charter for rustdoc team Borrow checking in a-mir-formality C++/Rust Interop Problem Space Mapping Comprehensive niche checks for Rust Const Generics Continue resolving cargo-semver-checks blockers for merging into cargo Develop the capabilities to keep the FLS up to date Emit Retags in Codegen Expand the Rust Reference to specify more aspects of the Rust language Finish the libtest json output experiment Finish the std::offload module Getting Rust for Linux into stable Rust: compiler features Getting Rust for Linux into stable Rust: language features Implement Open API Namespace Support MIR move elimination Prototype a new set of Cargo "plumbing" commands Prototype Cargo build analysis reflection and comptime Rework Cargo Build Dir Layout Run more tests for GCC backend in the Rust's CI Rust Stabilization of MemorySanitizer and ThreadSanitizer Support Rust Vision Document rustc-perf improvements Stabilize public/private dependencies Stabilize rustdoc doc_cfg feature SVE and SME on AArch64 Type System Documentation Unsafe Fields Flagship: Beyond the & People involved: Frank King Champions: compiler (Oliver Scherer), lang (TC) Status: Continued 3 detailed updates available. Frank King — comment from 2026-02-26 (Just come back from the Spring Festival) * (locally, no PR yet): design and implement the borrow checking algorithms of &pin * Reviewed Add Drop::pin_drop for pinned drops, to update the submodule book * Reviewed Implement coercions between &pin (mut|const) T and &(mut) T when T: Unpin, to do some refactors according to the reviewed messages. Frank King — comment from 2026-03-16 * Merged . * Opened draft PR [Implement borrowck for&pin mut|const $place`](https://github.com/rust-lang/rust/pull/153693). The implementation needs to be refined and self-reviewed before the community reviews. Frank King — comment from 2026-04-16 Self-reviewed Implement borrowck for &pin mut|const $place. Found that the current approach of handling pinned borrows may be incorrect, as it failed to distinguish a pinned borrow from a coercion of a normal-to-pinned reference. The latter doesn't prevent a T: Unpin type from being moved, but the former does, which breaks the pin coercion test. People involved: Benno Lossin Champions: lang (Tyler Mandry) Status: Continued 5 detailed updates available. Benno Lossin — comment from 2026-01-01 * At the beginning of December, we set out to [answer five important questions](https://github.com/rust-lang/rust-project- goals/issues/390#issuecomment-3621913656) regarding the virtual places approach. We discussed four questions and arrived at answers for three. * The first question we looked at was question 3 Canonical Projections. * Next we looked at question 4 Non-Indirected Containers. * As the final question we answered, we looked at question 1 Field- by-Field Projections vs One-Shot Projections. * At the moment, we are investigating question 2 and I wrote a blog post with a potential solution that still needs feedback. * We started a Wiki Project to consolidate our knowledge in one place. * We implemented an algorithm to determine the type of a place expression. * Our plan is to continue this project goal in the next goal period. Benno Lossin — comment from 2026-01-25 Earlier this month, Nadrieril Ding Xiang Fei and I held a meeting on autoref and method resolution in a world with field projections. This meeting resulted in a new page for the wiki on autoref. Benno Lossin — comment from 2026-02-28 The first pull request of the lang experiment has just been merged: rust- lang/rust#152730 This PR enables the use of the field_of! macro to obtain a unique type for each field of a struct, enum variant, tuple, or union. We call these types field representing types (FRTs). When the base type is a struct that is not repr(packed), only contains Sized fields, this type automatically implements the Field trait that exposes some information about the field to the type system. The offset in bytes from the start of the struct, the type of the field and the type of the base type. The feature is still incomplete and highly experimental. We also want to tackle the limitations in future PRs. For the moment this is enough to give us the ability to experiment with library versions of field projections and write functions that are generic over the fields of structs. For example one can write code like this: > #![feature(field_projections)] use std::field::{Field, field_of}; use std::ptr; fn project_ref<'a, T, F: Field<Base = T>>(r: &'a T) -> &'a F::Type { // SAFETY: the `Field` trait guarantees that this is sound. unsafe { &*ptr::from_ref(r).byte_add(F::OFFSET).cast() } } struct Struct { field: i32, other: u32, } fn main() { let s = Struct { field: 42, other: 24 }; let r = &s; let field = project_ref::<_, field_of!(Struct, field)>(r); let other = project_ref::<_, field_of!(Struct, other)>(r); println!("field: {field}"); // prints 42 println!("other: {other}"); // prints 24 } A very important feature of the types returned by field_of! is that you can implement traits for them if you own the base type. This allows anointing fields with information by extending the Field trait. For example, this allows encoding the property of being a structurally pinned field: > use std::pin::Pin; unsafe trait PinnableField: Field { type StructuralRefMut<'a> where Self::Type: 'a, Self::Base: 'a; fn project_mut<'a>(base: Pin<&'a mut Self::Base>) -> Self::StructuralRefMut<'a> where Self::Type: 'a, Self::Base: 'a; } fn project_pinned<'a, T, F>(r: Pin<&'a mut T>) -> <F as PinnableField>::StructuralRefMut<'a> where F: PinnableField, { F::project_mut(r) } We can then implement this extra trait for all of the fields of our struct (and automate that with a proc-macro): > unsafe impl PinnableField for field_of!(Struct, field) { type StructuralRefMut<'a> = &'a mut i32; fn project_mut<'a>(base: Pin<&'a mut Self::Base>) -> Self::StructuralRefMut<'a> where Self::Type: 'a, Self::Base: 'a, { let base = unsafe { Pin::into_inner_unchecked(base) }; &mut base.field } } unsafe impl PinnableField for field_of!(Struct, other) { type StructuralRefMut<'a> = Pin<&'a mut u32>; // u32 is `Unpin`, so this isn't doing anything special, but it highlights the pattern. fn project_mut<'a>(base: Pin<&'a mut Self::Base>) -> Self::StructuralRefMut<'a> where Self::Type: 'a, Self::Base: 'a, { let base = unsafe { Pin::into_inner_unchecked(base) }; unsafe { Pin::new_unchecked(&mut base.other) } } } Now you can safely obtain a pinned mutable reference to other and a normal mutable reference to field by calling the project_pinned function and supplying the correct FRT. (playground link) Benno Lossin — comment from 2026-03-20 Plan for 2026 We have an updated plan for this goal in 2026 consisting of three major steps: * `a-mir-formality`, * Implementation, * Experimentation. Some of their subtasks depend on other subtasks for other steps. You can find the details in the updated tracking issue. Here is a short rundown of each: a-mir-formality: we want to create a formal model of the borrow checker changes we're proposing to ensure correctness. We also want to create a document explaining our model in a more human-friendly language. To really get started with this, we're blocked on the new expression based syntax in development by Niko. Implementation: at the same time, we can start implementing more parts in the compiler. We will continue to improve FRTs, while keeping in mind that we might remove them if they end up being unnecessary. They still pose for a useful feature, but they might be orthogonal to field projections. We plan to make small and incremental changes, starting with library additions. We also want to begin exploring potential desugarings, for which we will add some manual and low level macros. When we have that figured out, we can fast-track syntax changes. When we have a sufficiently mature formal model of the borrow checker integration, we will port it to the compiler. After further evaluation, we can think about removing the incomplete_feature flag. Experimentation: after each compiler or standard library change, we look to several projects to stress-test our ideas in real code. I will take care of experimentation in the Linux kernel, while Tyler Mandry will be taking a look at testing field projections with crubit. Josh Triplett also has expressed eagerness of introducing them in the standard library; I will coordinate with him and the rest of t-libs-api to experiment there. Benno Lossin — comment from 2026-04-02 Yesterday, we held a t-lang design meeting on our current approach. Nadrieril and I authored a design document with the feedback of Tyler Mandry, Ding Xiang Fei, Alice Ryhl, and Gary Guo. In this document, we provided the motivation for this feature, what the look and feel of a solution fitting into the existing features of Rust is, and a comprehensive + compact introduction to our current approach based on virtual places. The general reception was extremely positive. To give some concrete quotes from the meeting: * Josh: I adore this! I love how orthogonal it is, and how impactful and universal it is. I anticipate this becoming a beloved, pervasive feature of Rust. Places and projection seem important enough to me that they're worth giving one of our precious remaining ASCII sigils to, and @ is nicely evocative of a place (something is at a place). So to the extent the final syntax benefits from a sigil, :+1: for giving this @. (See some feedback below on the details, though.) * TC: Love it. High concept. As I said in the last meeting: I particularly like language features that reduce the need for library surface area, and this is one of those. There are, of course, many details to resolve and understand further, e.g., with respect to migration issues, interaction with const, async, and other effect-like things, etc. I'm looking forward to seeing the formalization work. * tmandry: What I love about this direction is how effectively it builds on what Rust already has. I love to see designs that reinforce our existing concepts while pushing them in directions that make them more expressive. * Jack: Whoo boy. This is great. There's so much here that I'm not exactly sure where to begin and what to comment on. I think this is the type of thing that we will only really be able to figure out the nitty gritty details and ergonomics only after some amount of experimentation. There are a few takeaways from this meeting: * Mark that t-libs should be more involved in reviewing the experimental traits that we intend to add. Ensuring that we don't accidentally stabilize or expose some behavior, have sufficient documentation on our experimental traits, and that t-libs is in the loop of this feature in general. * Mark offered to review PRs and I will be tagging him in those. * Jack raised the concern that increasing the cognitive load for the 95% use-case should be avoided. Making the right choice between @ and & might be challenging for users. * We discussed this point more in the meeting and concluded with that we need to do some experimentation, possibly utilizing the user research team. We will of course keep this in mind and revisit it later when we have a partially working implementation. * TC requested that we publish our fine-grained design axioms, essentially the list of things we go through when considering a modification of our proposal. * I will write an update on this issue explaining exactly those. Aside from the concerns and directly actionable items, the meeting also covered design questions/comments that we want to take a look at in the coming weeks/months: * [Can we support reads/writes of different types?](https://hackmd.io/H5d2-83ER2ymNPZVIWCYWg?view#Support-ReadWrite-of- non-PlaceTarget) * Can we support re-assembly of wrapper types, so going from Cell<[T]> to [Cell<T>]? * The PlaceDiscriminant trait needs to be carefully designed * How do we handle naming conflicts & ensure SemVer evolution of library types implementing our traits? * Can we support projecting through Option, so e.g. &Option<Struct> to Option<&Field>? * Can we support a pointer that carries alignment information & which is updated on projections? * What compatibility with effects do we need or want to support? * What doors on future ergonomic improvements of pointers are we closing by having field projections? Thanks to everyone who participated in the meeting! People involved: Aapo Alasuutari Champions: compiler (Oliver Scherer), lang (Tyler Mandry) Status: Continued 1 detailed update available. Aapo Alasuutari — comment from 2026-02-28 PR open to get the first working version of the Reborrow and CoerceShared traits merged. Blockers Currently "blocked" on PR review, and of course my (and Ding's) work to fix all review issues. The review has brought up an opportunity to replace Rvalue::Ref / ExprKind::Ref with a more generalised variant that could encompass both references and user-defined references. This would be powerful, but it would be a very big and scary change. If this turns out to be a blocking issue for reviewers, then this will block the goal for the foreseeable future as the PR then starts on a massive refactoring. Help wanted The PR currently does not include derive traits, but we'd really want them. Instead of these: > impl<'a> Reborrow for CustomMarker<'a> {} impl<'a> CoerceShared<CustomMarkerRef<'a>> for CustomMarker {} impl<'a, T> Reborrow for CustomMut<'a, T> {} impl<'a, T> CoerceShared<CustomRef<'a, T>> for CustomMut<'a, T> {} we'd prefer to have something like this: > #[derive(Reborrow, CoerceShared(CustomMarkerRef))] struct CustomMarker<'a> { ... } #[derive(Reborrow, CoerceShared(CustomRef))] struct CustomMut<'a, T> { ... } If anyone feels like picking up this thread, that'd be awesome: the derive macros do not need to really perform any validity checking, as the trait itself will do that. If the PR merges soon, then public testing and exploration of the traits will be the next big thing. Likely concurrently with that the massive refactoring to generalise Rvalue::Ref / ExprKind::Ref. Flagship: Flexible, fast(er) compilation People involved: David Wood , Adam Gemmell Champions: cargo (Eric Huss), compiler (David Wood), libs (Amanieu d'Antras) Status: Continued 4 detailed updates available. David Wood — comment from 2026-01-15 rust-lang/rfcs#3873 has been merged and an FCP has been started on rust- lang/rfcs#3874 and rust- lang/rfcs#3875 - those both have some feedback for me to respond to that I'll get to as soon as I can. David Wood — comment from 2026-02-17 No major updates this cycle - we're still working through feedback on rust- lang/rfcs#3874 and rust- lang/rfcs#3875 and prototyping the implementation to be prepared. David Wood — comment from 2026-03-17 Update this cycle is the same as last time - rust- lang/rfcs#3874 and rust- lang/rfcs#3875 are progressing, with feedback being addressed and checkboxes checked, and we're still working out what the implementation would look like. David Wood — comment from 2026-04-14 rust-lang/rfcs#3874 has finished FCP and is due to be merged any day now. I'm working on resolving the remaining open comments on rust- lang/rfcs#3875 and then intend to nudge the reviewers to have a look and check their boxes or leave concerns. Adam Gemmell has opened rust- lang/cargo#16675 with an early sketch of some of the core changes that build-std would require and is working with the Cargo team to address feedback and work out how to proceed with the implementation. People involved: Folkert de Vries , bjorn3, Trifecta Tech Foundation Champions: compiler (bjorn3) Status: Not completed (lack of funding) People involved: Sparrow Li Status: Continued People involved: Jane Lusby , @dropbear32, @osiewicz Champions: cargo (Weihang Lo), compiler (Oliver Scherer) Status: Not completed (note) Flagship: Higher-level Rust People involved: Niko Matsakis , Santiago Pastorino Champions: compiler (Santiago Pastorino), lang (Niko Matsakis) Status: Continued People involved: Ed Page Champions: cargo (Ed Page), lang (Josh Triplett), lang-docs (Josh Triplett) Status: Continued 3 detailed updates available. Ed Page — comment from 2026-01-14 #146377 has been decided and merged. Blockers * T-lang discussing CR / text direction feedback: comment * T-rustdoc deciding on and implementing how they want frontmatter handled in doctests Ed Page — comment from 2026-02-13 * FCP has ended on , just awaiting merge * Cargo script has entered FCP Blockers * Potential issues around edition, see [Cargo script edition policy (lang/edition aspects)](https://github.com/rust-lang/rust/issues/152254). Ed Page — comment from 2026-03-16 Cargo's FCP has ended. Blockers * Flagship: Unblocking dormant traits People involved: Taylor Cramer and others Champions: lang (Taylor Cramer), types (Oliver Scherer) Status: Superseded by the Implement Supertrait auto impl and Arbitrary Self Types 2026 goals People involved: Alice Ryhl , Benno Lossin, Michael Goulet, Taylor Cramer, Josh Triplett, Gary Guo, Yoshua Wuyts Champions: lang (Taylor Cramer) Status: Continued 1 detailed update available. Alice Ryhl — comment from 2026-01-31 A proposal to continue this goal in the next goal period was merged. People involved: lcnr , Boxy, Michael Goulet Champions: types (lcnr) Status: Continued 1 detailed update available. lcnr — comment from 2026-01-19 There hasn't been too much progress over the last few weeks and I've been mostly taking a Christmas break. Nicholas Nethercote has been looking into the performance of the new trait solver, cleaning up canonicalization and slightly improving its performance: PR 1 and PR 2. Shoyu Vanilla looked into ICE from mir validation on unsizing in opendal and uncovered the underlying bug there. While this issue also affects the old solver and the proper fix for it requires where-bounds on binders, we can work around this bug in the trait solver for now and intend to do so. We've started another crater run with all our recent changes and adwin has started to triage it, uncovering one new issue up until now. Intend to continue going through that over the next few weeks. There's also a lot in-progress work going on. I am collaborating with Niko Matsakis to specify and later RFC the cycle semantics of Rust. León Orell Valerian Liehr is working on a replacement for the rustdoc's auto trait impl synthesis. tiif is working on a fix a MIR borrowck unsoundness. Shoyu Vanilla and I are improving the way we propagate inference constraints from the expected return type to function arguments, fixing this issue. People involved: Rémy Rakic , Amanda Stjerna, Niko Matsakis Champions: types (Jack Huey) Status: Continued 2 detailed updates available. Rémy Rakic — comment from 2026-01-30 This month's update: * is making progress on [normalizing opaques while computing implied bounds](https://github.com/rust-lang/trait- system-refactor-initiative/issues/159) * we discussed how to investigate and fix the remaining correctness issues in Tage's work, to be able to evaluate it more accurately: in particular around variance and bidirectional edges, and without the reliance on NLL (having computed region values / errors) * we've tried to see if it'd be possible to remove the cfg region elements * Amanda is still working on her two papers, one about the current borrow checker and one about the work on Polonius. Her major PR for the restructuring of placeholder handling during region inference is stalled due to a conflict with further trait solver developments and may have to be abandoned. Work with the larger types team is ongoing and smaller patches/refactorings/improvements are being landed in the meantime. * #149639 has now landed, and #150551 is still in review * I've also fixed more small inefficiencies (computing boring/relevant locals on-demand in diagnostics, removed conversions between locations and points, etc) building on top of the previous PRs (so they need to be reviewed first) * I've looked at crates.io again with the alpha, to find functions that are slower than with NLLs. AFAICT the worst case there is 60% for a 5KLOC function with 42K loans, 255K statements, and 125K outlives constraints. I'll see what we can do with this. Small composable functions is still good advice. * there seem to be optimization opportunities to 1. limit propagation to the smaller number of blocks that could be affected by bidirectional edges, 2. for unifying invariant lifetimes of live locals that are assigned at most once (à la use-def chains), 3. for invalidations that are just the activation of a reservation * we discussed possible plans to gather actual statistics, using the infrastructure that was created for the Metrics project * we're also preparing the new project goal for this year, where we'll want to stabilize the alpha 🤞 Rémy Rakic — comment from 2026-02-28 We had a bit less time this month, the update will be shorter, but still meaningful I hope: * [#150551](https://github.com/rust-lang/rust/pull/150551) has landed, and it feels stabilizable. To me, this part of the goal is achieved. * still, "stabilizable" is not stable , and there is more work to do. We plan to stabilize this year, and the project goal proposal for 2026 tracks how. * tiif is still deep in #152051, and a-mir- formality work with Niko and I. * Amanda has opened a few cleanup PRs (#152438, and #152579), and #151863 has landed already. She also has started looking into Tage's old PR to see if we can fix it, benchmark it more accurately, and see the cool parts there that we could be using. * Jack is possibly going to have some time to work with us this year! His help will be very welcome, especially as I will have less time available myself. * we'll be tracking the opaque type region liveness soundness issue in #153215, and I've added a couple tests, in case tiif's PR or anything that impacts them lands. * some of the tiny cleanups I mentioned last time have also landed in #152587. Other goal updates People involved: Guillaume Gomez Champions: rustdoc (Guillaume Gomez) Status: Completed People involved: Niko Matsakis , tiif Champions: types (Niko Matsakis) Status: Continued People involved: Joel Marcey Champions: compiler (Oliver Scherer), lang (Tyler Mandry), libs (David Tolnay) Status: Continued 5 detailed updates available. Joel Marcey — comment from 2026-01-20 The Rust Foundation is opening up a short-term, approximately 3-month, contracting role to assist in our Rust/C++ Interop initiative. The primary work and deliverables for the role will be to make substantial progress on the Problem Space Mapping Rust Project Goal by collecting discrete problem statements and offering up recommendations on the work that should follow based upon the problems that you found. If you are interested in how programming languages interoperate, are curious in understanding the problems therein, and are have a passion to think about how those problems may be resolved for the betterment of interop, then this work may be for you. An ideal candidate will have experience with Rust programming. Having experience in C++ is strongly preferred as well. If you have direct experience with actual engineering that required interoperating between Rust and C++ codebases, that's even better. If you are interested, please email me (email address found in my GitHub profile) or contact me directly on Zulip by Tuesday, January 27 and we can take it from there to see if there may be a potential fit for further discussion. Thank you. Joel Marcey — comment from 2026-01-31 The effort to fill the contracting role to support this project goal is in the process winding down. The interview and discussion process is nearly complete. We expect to make a final decision for the role in early February. teor — comment from 2026-02-27 Hi, I'm the new contractor on the interop problem space mapping project goal. In the last week and a half, I've: * added * started mapping out interop use cases * added relationships between problems/use cases and existing project goals & unstable compiler features Next step is prioritising a few of the use cases, then working on related problem statements in more detail. Blockers Nothing at the moment, still working through the high level mapping of the problem space. Help wanted Suggestions for more interop use cases would be very welcome, just open a discussion in t-lang/interop and I'll turn it into a ticket. Or go ahead and open a use case ticket directly. I'll post an update here every few weeks, you can follow more detailed weekly updates on Zulip. teor — comment from 2026-03-30 In the last month, I've: * met with the lang team, Crubit team, and `cxx` author, and Joel and Mara have met with the C++ standards working group * expanded some draft high-level problem statement summaries, and added code examples * added 6 new interop use cases * added more relationships between problems/use cases and existing project goals & unstable compiler features * prepared for the Rust All Hands, and started mentoring for Outreachy Specifically, the last month we've identified and prioritised two high- priority use cases for more detailed work: * , with a Rust lang experiment - implementation discussion * adding Rust to an existing C++ build system, this currently works for basic cases, but the tooling could be improved on the Rust side And I analysed the problems / use cases we've collected so far, with priorities, responsible language, and a split into semantics or tooling changes. Next step is continuing to work on overloading and build systems in more detail. If you have specific Rust/C/C++ build system blockers, please open a chat or ticket. Blockers Nothing at the moment, everyone has been extremely helpful, and I'm getting good feedback on use cases, problems, priorities, and Rust language experiments. teor — comment from 2026-05-01 In the last month, I've: * prepared for RustWeek and the All Hands, where I will be [giving a Rust Project track talk](https://2026.rustweek.org/schedule/wednesday/#teor) and running an All Hands interop session (schedule TBC) * added new interop use cases and problem statements, and continued categorising them using GitHub tags * continued to expand the draft high-level problem statement summaries * added interop code examples, including many examples from Outreachy applicants * continued mentoring Outreachy applicants * continued working on the Overloading Rust language experiment Specifically, the last month we've made detailed progress on two high- priority use cases: * [calling an overloaded C++ function from Rust](https://github.com/rustfoundation/interop-initiative/issues/14), with a Rust lang experiment - implementation discussion * we've merged a refactor to prepare for this experiment, which gave some nice perf wins * the initial overloading experiment PR has been through two rounds of review, and is waiting for my revisions and rebasing * adding Rust to an existing C++ build system * Outreachy applicants wrote interop example code PRs * these interop user experiences are waiting for analysis, so they can be summarised in the build system and overloading problem statements * this will likely happen after RustWeek and the All Hands Next step is continuing to work on the overloading experiment, along with RustWeek/All Hands preparation, and collecting feedback during the conference. Blockers Nothing at the moment. There is a steady stream of new use cases, problems, code examples and Rust language experiment feedback. People involved: Bastian Kersting , Jakob Koschel Champions: compiler (Ben Kimock), opsem (Ben Kimock) Status: Not completed People involved: Boxy , Noah Lev Champions: lang (Niko Matsakis) Status: Continued 6 detailed updates available. Niko Matsakis — comment from 2026-01-27 Boxy and I have established a regular time to check-in on formalizing this within a-mir-formality. Today we mostly worked on the "model" of const values, starting with this > #[term] pub enum ConstData { // Sort of equivalent to `ValTreeKind::Branch` #[cast] RigidValue(RigidConstData), // Sort of equivalent to `ValTreeKind::Leaf` #[cast] Scalar(ScalarValue), #[variable(ParameterKind::Const)] Variable(Variable), } #[term] pub enum ScalarValue { #[grammar(u8($v0))] U8(u8), #[grammar(u16($v0))] U16(u16), #[grammar(u32($v0))] U32(u32), #[grammar(u64($v0))] U64(u64), #[grammar(i8($v0))] I8(i8), #[grammar(i16($v0))] I16(i16), #[grammar(i32($v0))] I32(i32), #[grammar(i64($v0))] I64(i64), #[grammar($v0)] Bool(bool), #[grammar(usize($v0))] Usize(usize), #[grammar(isize($v0))] Isize(isize), } #[term($name $<parameters> { $,values })] pub struct RigidConstData { pub name: RigidName, pub parameters: Parameters, pub values: Vec<Const>, } i.e., a const value can be a scalar value (as today) or a struct literal like Foo { ... } (which would also cover tuples and things). We got the various tests passing. Huzzah! Boxy — comment from 2026-01-30 In addition to what niko posted previously there's been a lot of other stuff happening. A lot of people have opened PRs to improve mGCA this month: León Orell Valerian Liehr Noah Lev @enthropy7 Kivooeo mu001999 @Human9000-bit Redddy @Keith-Cancel @AprilNEA A rough list of things that have been improved for mGCA: * Lots of new expressions now supported by mGCA: const constructors, tuple constructor calls, array expressions, tuple expression, literals * associated_const_equality has been merged into min_generic_const_args. the former was effectively dependent on the latter already so this just makes it nicer to use the former :) * traits can now be dyn compatible if all associated constants are type consts and are specified in the trait object (e.g. dyn Trait<ASSOC = 10>) * type consts are enforced to be non-generic * a bunch of ICEs have been fixed * camelid has been working on "non-min" version of mGCA which will allow arbitrary expressions to be used in the type system (a blog post with more detail will be published once this actually lands) In non-mGCA updates, as niko says, we've been meeting regularly to make progress on modelling const generics in a-mir-formality. I've also been spending time thinking about the interactions between adt_const_params and ADTs with privacy/safety invariants and I think I know how to structure the RFC in this area so can make progress on that again There's some more detail about the various bits of work people have done and who did what here: #project-const-generics > perfectly adequately sized wins @ 💬 Niko Matsakis — comment from 2026-02-13 Boxy and I have met (and continue to meet) and work on modeling const generics in a-mir-formality. We're still working on laying the groundwork. There is a proposed project goal for next year. Boxy — comment from 2026-02-28 There's been a lot of miscellaneous fixes for mGCA this month. I've also started drafting some blog posts to explain what's going on with mGCA/oGCA as well as soliciting use cases/experience reports for them and adt_const_params. I also talked with some folks at Rust Nation this month about const generics and what features would be useful for them and why. Boxy — comment from 2026-04-02 Late on the update :') niko and i continue to meet to discuss const generics. we've made some progress on figuring out problems around privacy/safety in const generics. we've also been discussing the big picture stuff for const generics and where we're "heading". Boxy — comment from 2026-05-01 started running weekly meetings about const generics to make it easier to keep up to date with all the people who are working on const generics stuff. i think min_adt_const_params is now at the point of what the RFC is going to specify. GCA is making good progress thanks to ashley's work. i also met with lcnr where we talked about whether there was some version of mGCA that is stabilizeable in the near future or not (maybe!) People involved: Predrag Gruevski Champions: cargo (Ed Page), rustdoc (Alona Enraght-Moony) Status: Continued 1 detailed update available. Predrag Gruevski — comment from 2026-01-17 I posted a "year in review" for cargo-semver- checks. It has a section on how I think we should move forward in 2026 and beyond. People involved: Pete LeVasseur , t-spec, and contributors from Ferrous Systems Champions: bootstrap (Jakub Beránek), lang (Niko Matsakis), spec (Pete LeVasseur) Status: Superseded by the Stabilize FLS Release Cadence 2026 goal 2 detailed updates available. Pete LeVasseur — comment from 2026-03-04 We have a Project Goal in 2026 that we'll take on: Stabilize FLS Release Cadence. Progress towards 1.93.1 looks good, most issues are closed. Help wanted We'd love more folks from the safety-critical community to contribute to picking up issues or opening an issue if you notice something is missing. Pete LeVasseur — comment from 2026-04-02 Trying to prepare FLS releases earlier: * since we completed the 1.94.0 release of the FLS a bit early this time, we checked into the stretch part of our goal this year to look at 1.95.0 early * we learned a bit more of the release notes process thanks to tips from Eric Huss and TC * Tshepang Mbambo and I attended the t-release meeting last week where we chatted about working a little "upstream" with them on generating the release notes a bit earlier * tomorrow in our t-fls meeting we'll discuss our interest with engaging over there; at a minimum I'll get engaged with t-release Glossary and main-body text harmonization: * the first PR landed from removing IDs from the glossary * further steps planned, we have a tracking issue for it Developer guide: * akin to how the Reference now has a developer's guide now for contributing we'll do the same in the FLS * Hristian Kirtchev has been working on this People involved: Ian McCormack Champions: compiler (Ralf Jung), opsem (Ralf Jung) Status: Superseded by the BorrowSanitizer 2026 goal 4 detailed updates available. Ian McCormack — comment from 2026-01-09 Here's our January status update! * Yesterday, we posted [an MCP](https://github.com/rust-lang/compiler- team/issues/958) for our retag intrinsics. While that's in progress, we'll start adapting our current prototype to remove our dependence on MIR-level retags. Once that's finished, we'll be ready to submit a PR. * We published our first monthly blog post about BorrowSanitizer. * Our overall goal for 2026 is to transition from a research prototype to a functional tool. Three key features have yet to be implemented: garbage collection, error reporting, and support for atomic memory accesses. Once these are complete, we'll be able to start testing real-world libraries and auditing our results against Miri. Ian McCormack — comment from 2026-02-24 We just posted our February status update for BorrowSanitizer. TL;DR: * We provide detailed error messages for aliasing violations, which look almost like Miri's do! * We have two forms of retag intrinsic: __rust_retag_mem and __rust_retag_reg. We no longer require a compiler plugin to determine the permission associated with a retag, which will make it possible to use BorrowSanitizer by providing a single -Zsanitizer=borrow flag to rustc. You can check out our MCP for more detailed design updates. * We are starting to have a better understanding of how BorrowSanitizer performs in practice, but we do not have enough data yet to be certain. From one test case, it seems like we are somewhat faster but still in the same category of performance as Miri when we compare against other sanitizers. Expect more detailed results to come as we scale up our benchmarking pipeline. * We have a tentative plan for upstreaming BorrowSanitizer in 2026, starting with its LLVM components. We intend to start the RFC process on the LLVM side this spring, once our API is stable. Ian McCormack — comment from 2026-03-30 We just posted our March status update for BorrowSanitizer. TL;DR: * We added hundreds more relevant tests from Miri's test suite. At the moment, 80% pass. * We improved our cargo plugin (cargo-bsan) to better support multilanguage libraries. This will let us start to recreate the bugs from our earlier evaluation. Our goal for April is to continue expanding our test suite, finish an initial version of the LLVM components of BorrowSanitizer, and hopefully start the RFC process on the LLVM side. Ian McCormack — comment from 2026-04-29 We have some exciting news: our talk on BorrowSanitizer was accepted at RustConf this year! We’re grateful for the opportunity and looking forward to sharing our results with the broader community this September. We just posted our April status update. It’s a bit of a technical one. Here’s the TL;DR: * BorrowSanitizer now uses a shadow stack to track metadata at runtime - this is a significantly different strategy than other LLVM sanitizers, and it will help us support garbage collection. * We are now ready to start sending in PRs for our retag intrinsics. It will take a little time to split our changes up into meaningful, reviewable chunks—you can expect to see these throughout the next week. The RFC for our LLVM components is taking a little longer than expected, but it was worth taking the extra time to test out compiler changes and make sure that we had the core parts of the instrumentation pass settled. We’ll be drafting the RFC throughout the next few weeks. People involved: Josh Triplett , Amanieu d'Antras, Guillaume Gomez, Jack Huey, lcnr, Mara Bos, Vadim Petrochenkov, Jane Lusby Champions: lang-docs (Josh Triplett), spec (Josh Triplett) Status: Superseded by the Experimental language specification 2026 goal 1 detailed update available. Josh Triplett — comment from 2026-04-14 This work is now continuing into a new goal by Jack Huey. People involved: Ed Page Champions: cargo (Ed Page) Status: Continued People involved: Manuel Drehwald , LLVM offload/GPU contributors Champions: compiler (Manuel Drehwald), lang (TC) Status: Superseded by the High-Level ML optimizations 2026 goal 2 detailed updates available. Manuel Drehwald — comment from 2026-01-16 std::autodiff is moving closer to nightly, and std::offload is gaining various performance, feature, and hardware support improvements. autodiff Jakub Beránek, sgasho, and I continued working on enabling autodiff in nightly. We have a PR up that builds autodiff in CI, and verified that the artifacts can be installed and work on Linux. For apple however, we noticed that any autodiff usage hangs. After some investigation, it turns out that we ended up embedding two LLVM copies, one in rustc, and one in Enzyme. It should be comparably easy to get rid of the second one. Once we verified that this fixes the build, we'll merge the PR to enable autodiff on both targets in nightly. offload A lot of interesting updates on the performance, feature, and hardware support side. 1. , @kevinsala, @jdoerfert, and I started implementing the first benchmarks, since that's generally the best way to find missing features or performance issues. We were positively surprised by how good the out-of-the-box performance was. We will implement a few more benchmarks and post the results once we have verified them. We also implemented multiple PRs which implement bugfixes, cleanups, and needed features like support for scalars. We also started working on LLVM optimizations which make sure that we can achieve even better performance. 2. I noticed that our offload intrinsic allowed running Rust code on the GPU, but it wasn't of much help when calling gpu vendor libraries like cuBLAS. I implemented a new helper intrinsic which allows calling those functions conveniently, without having to manually move data to or from the device. It will benefit from the same LLVM optimizations as our full offload intrinsic. It also a bit simpler to set up on the compiler and linker side, so it already works with std and mangled kernel names, something that we still have to improve for our main offload intrinsic. 3. A lot of work happened on the LLVM offload side for SPIRV and Intel GPU support. At the moment, our Rust frontend is tested on NVIDIA and AMD server and consumer GPUs, as well as AMD HPC and Lapotop APUs. Karol Zwolak reached out since he wants to help with with also running Rust on Intel GPUs. Offload relies on LLVM which started gaining Intel support, so hopefully we won't need much work beyond a new intel-gpu target and a new stdarch module. There is also work on a new spirv target for rustc, which we could also support if it goes through LLVM. Due to some open questions around typed pointers it does not seem clear yet whether it will, so we will have to wait. 4. Nikita started working on updating our submodule to LLVM 22. This hopefully does not only brings some compile and runtime performance improvements, but also greatly simplifies how we can build and use offload. Once it landed I'll refactor our bootstrapping logic, and as part of that start building offload in CI. Manuel Drehwald — comment from 2026-04-01 std::autodiff is now partly in CI, and std::offload got tested on a lot more benchmarks. autodiff Work continued on enabling autodiff in nightly. Since the last update, we have enabled autodiff in some Mingw and Linux runners. Users can now download libEnzyme artifacts, place them locally in the right spot for their toolchain, and then use autodiff on their nightly compiler. Once macOS is added, we will enable a new rustup component that will handle the download for users. Before enabling autodiff on macOS, however, we want to change how we distribute LLVM on this target (from static to dynamic linking). There are a lot of workflows and users of this target, not all of which can be modelled in the Rust CI. Our last two attempts sadly broke such downstream users and local contributors, so both attempts had to be reverted. Since testing here is tricky, progress here might be on the slower side; we will see. offload Most of the work on the offload side lately has been invisible, since we were working on implementing more benchmarks and LLVM optimizations, as well as missing features, discovered by those benchmarks. We achieved excellent performance on those benchmarks; more details will soon be presented by Marcelo Domínguez at the EuroLLVM conference in two weeks! Beyond benchmarks, there was a lot of tinkering on smaller PRs, reviewing, and housekeeping. LLVM-22 landed, so we updated our bootrstrap code to make use of new APIs, and tried to move a few smaller PRs forward, mainly around a better user experience and for making more Rust features available. Since the focus is still on benchmarks, not many of those PRs landed. They are in a mostly ready state, so it's a good time to pick them up if you're considering contributing. Please ping me on Zulip or in any PR with the offload label if you are interested! People involved: Tomas Sedovic , compiler contributors Champions: compiler (Wesley Wiser) Status: Continued 4 detailed updates available. Tomas Sedovic — comment from 2026-01-16 Update from the 2026-01-14 meeting: #![register_tool] Tyler Mandry proposed FCP of the RFC#3808 and nominated it for a Lang discussion. -Zdebuginfo-compression Wesley Wiser proposed stabilization: rust#150625. Josh Triplett suggested trying to bring zlib- rs in the kernel as a case study. -Zdirect-access-external-data rust#150494 was merged two days ago, what reminds is updating the documentation and stabilizing the feature. There's an ongoing discussion about the feature on the Rust Zulip as well. Tomas Sedovic — comment from 2026-02-17 Updates from the 2026-01-28 and 2026-02-11 meetings: -Zdirect-access-external-data Gary Guo's fix PR was merged. --emit=noreturn Miguel Ojeda reiterated that this is high on the list of compiler features the project needs. Right now, they're doing these checks manually. Improving objtool's handling of noreturn is on Gary Guo's radar but there wasn't time yet. Tomas Sedovic — comment from 2026-03-16 Update from the 2026-03-11 meeting: --emit=noreturn It seems that figuring out which functions are noreturn is at a level too low for rustc. Function signatures are not sufficient and there are cases where rustc doesn't know whether to emit noreturn. It is something we should ask the LLVM to give us that information. Alice Ryhl opened a new issue to introduce the -Zsanitizer=kernel-hwaddress sanitizer for aarch64 targets: https://github.com/rust-lang/compiler-team/issues/975 -Zharden-sls Wesley Wiser is working on allowing forbidden target features to be hard errors, which the -Zharden-sls patch should be rebased on top of. #![register_tool] The corresponding RFC has been discussed by the Lang team on 2026-03-11. The overall vibe was positive and TC is going to read through it and hopefully check a box on the proposed FCP. The proposed stabilization received some feedback that needs to be addressed.
  
  The discussion here has stalled.
  - Tomas Sedovic — comment from 2026-04-10
  Update from the 2026-04-08 meeting:
  
  rust#153049 is merged. What remains of the tracking issue rust#154171 is a few docs checklists. Alice Ryhl added the unstable book doc changes in the PR itself and Wesley Wiser confirmed that's all the documentation needed for sanitizers.
  
  People involved: Tomas Sedovic , Ding Xiang Fei
  
  Champions: lang (Josh Triplett), lang-docs (TC)
  
  Status: Superseded by the Rust for Linux 2026 roadmap
  
  6 detailed updates available.
  
  Tomas Sedovic — comment from 2026-01-19
  
  Update from the 2026-01-14 meeting.
  
  Deref / Receiver Ding's arbitrary_self_types: Split the Autoderef chain rust#146095 is waiting on reviews. It updates the method resolution to essentially: deref_chain(T).flat_map(|U| receiver_chain(U)). The perf run was a wash and a carter has completed yesterday. Analysis pending. Ding has submitted a Rust Project goal for Supertrait Auto Impl. Arbitrary Self Types We've discovered the #[feature(arbitrary_self_types_pointer)] feature gate. As the Lang consensus is to not support the Receiver trait on raw pointer types we're probably going to remove it (but this needs further discussion). This was a remnant from the original proposal, but the Lang has changed direction since. derive(CoercePointee) Ding is working on a fix to prevent accidental specialization of the trait implementation. rust#149968 is adding an interim fix. Alice opened a Reference PR for rust#136776. There are questions around the behaviour of the as cast vs. coercions. Pass pointers to const in assembly Gary opened implementation for the RFC: rust#138618. Field Projections Benno updated the Field Representing Types PR to the latest design. This makes the PR much simpler. Tyler opened a Beyond References wiki to keep all the proposals, resources in one place. In-place initialization Ding is writing a post to describe all the open proposals including Alice's new one that she brouhght up during the LPC 2025. He'll merge it in the Beyond References wiki. Macros, attributes, derives, etc. Josh brought up his work on adding more capable declarative macros for writing attributes and derives. He's asked the Rust for Linux team for what they need to stop using proc macros. Miguel noted they've just added dependency on syn, but they would like to remove it some day if their could. Benno provided a few cases of large macros that he thought were unlikely to be replaceable by declarative-style ones. Josh suggested there may be a way and suggested an asynchronous discussion. Tomas Sedovic — comment from 2026-02-16 Updates from the 2026-01-28 and 2026-02-11 meetings: Removing the likely/unlikely hints in favour of cold_path The stabilization of core::hint::cold_path lint is imminent and after it, the likely and unlikely hints are likely (pardon the pun) to be removed. The team discussed the impact of this. These hints are used in C but not yet in Rust. cold_path would be sufficient, but likely/unlikely would still be more convenient in cases where there isn't an else branch. Tyler Mandry mentioned that these can be implemented in terms of cold_path. Niche optimizations We discussed the feasibility of embedding data in lower bits of a pointer -- something the kernel is doing in C. This could also enable setting the top bit in the integers (which is otherwise never set) and make it represent an error in that case (and a regular pointer otherwise). Ideally, this would be done in safe Rust, as the idea is to improve the safety of the C code in question. Extending the niches is something Rust wants to see, but it's waiting on pattern types. There are short/medium-term options by using unsafe and wrapping it in a safe macro, but the long-term hope is to have this supported in the language. Vendoring zerocopy The project has interest in vendoring zerocopy. We had its maintainers Jack Wrenn and Joshua Liebow- Feeser join us to discuss this and answer our questions. The main question was about whether to vendor at all, how often should we (or will have to) upgrade, and how much of it is expected to end up in the standard library. The project follows semver with the extended promise to not break minor versions even before 1.0.0. We could vendor the current 0.8 and we should be upgrade on our own terms (e.g. when we bring in new features) rather than being forced to. Right now, the project is able to experiment with various approaches and capabilities. Any stdlib integration a long way away, but there is interest in integrating these to the language and libraries where appropriate. New trait solver There's been a long-term effort to finish the new trait solver, which will unblock a lot of things. Niko Matsakis asked about things it's blocking for Rust for Linux. This is the list: unmovable types, guaranteed destructors, Type Alias Impl Trait (TAIT), Return Type Notation (RTN), const traits, const generics (over integer types), extern type. 2026 Project goals This year brings in the concept of roadmaps. We now have a Rust for Linux and a few more granular Goals. We'll be adding more goals over time, but the one merged cover what we've been focusing on for now. Tomas Sedovic — comment from 2026-03-11 Update from the 2026-02-25 meeting: 2026 Project goals We spent most of the meeting going over the open Project goals, the Rust for Linux roadmap and other things we'd like to see that aren't the right shape for a goal. Miguel Ojeda brought up the upcoming Debian 14 release (coming out probably somewhere around Q2 of 2027) and we went over each item and decided whether it's something we need to make sure is in that release or not. Debian stable is an important milestone and the Rust version in it serves as a baseline for Rust for Linux development. I'll add all this data into the roadmap. Tomas Sedovic — comment from 2026-03-16 Update from the 2026-03-11 meeting: Field projections We now have a macro and machinery that uses the projection mechanism. The dma_read! / dma_write! macros switched over to it. This also fixes a soundness issue 1. Note: this is done entirely via macros and doesn't use any Field projections language features. The Field projection syntax and traits should make this more ergonomic and integrate the borrow checker so we can accept more code. We're planning to have a design meeting with the Lang team in the last week of March. rustfmt imports formatting and trailing slashes We talked about the rustfmt formatting of the use statements again. While the trailing empty comment // workaround (see this update) is acceptable as a temporary measure, we need to find a long-term solution where you can configure rustfmt to accept this style. We don't have a issue for this specific formatting yet, though it was discussed in #3361. The next step are to create such an issue. We were hesitant to add burden to a team that's already at limit, but having the issue would let us track it from the Rust for Linux side. Tomas Sedovic — comment from 2026-03-26 Update from the 2026-03-26 meeting: Const generics Boxy asked the team for features that are most important under the const generics umbrella. This might help with prioritisation and just understanding of practical uses. 1. **Ability to do arithmetic on const generic types** : e.g. the kernel has a type Bounded which has a value and a maximum size (in bits). Both the bit width and value are const values. They want to be able to do arithmetics on these types (starting with bit shifts) that will guarantee the the result will fit within the specified size at compile time. 2. Argument-position const generics : right now, the const generic types must be specified in the type bound section (within the angle brackets). So for example you have to write: Bounded::<u8, 4>::new::<7>() instead of the more natural Bounded::<u8, 4>::new(7). This gets more complicated when there's const-time calculation happening rather than just a numerical constant -- in which case this also needs to be wrapped in curly brackets: { ... }. 3. Being generic over types other than numbers: pointers would be useful for asm_const_ptr. String literals too -- even if they're just passed through without being processed / operated on. And if going from a passthrough string makes it possible to pass through any type, that would help the team replace some typestate patterns they're using with an enum. statx Alice Ryhl proposed being able to create std::fs::Metadata from Linux statx syscall. This was discussed in the Libs-API meeting and they had questions about possible evolutions of the statx ABI -- if/how it can grow in the future and how they could handle that if they wanted some of the new data available. So we discussed it in the Rust for Linux meeting. In the end, it seems prudent to be reasonably defensive rather than relying on the syscall pre-filling default values. Alice Ryhl proposed an opaque statx struct that would give the stdlib a way to decide on the struct's size, pre-filled contents and mask. Miguel Ojeda suggested contacting Christian Brauner and Alexander Viro (i.e. the VFS maintainers); Josh Triplett agreed that it would be good if we can get a thread with the right people in linux-fsdevel. Tomas Sedovic — comment from 2026-04-10 Update from the 2026-04-08 meeting: zerocopy features in Rust's std zerocopy uses two traits that are both polyfills for unstable traits : KnownLayout (for ptr_metadata) and Immutable (for Freeze). It would help maintenance of zerocopy (which Rust for Linux plans to start using) if these were stabilised. ptr_metadata is something the team wants in the kernel independently. It's possibly blocked on (or at least might have interactions with) the Sized Hierarchy work. Freeze (now NoCell) has an RFC. Deref/Receiver Jack Huey started reviewing Ding Xiang Fei's PR to split the autoderef chain and feels it's not ready to go in front of the full Lang team. We also discussed the dependence/independence of the Deref and Receiver implementations, in particular whether it ever makes sense to implement Deref but not Receiver. Josh Triplett suggested gathering examples for cases like that (where you can't use the type as a Self type in the function declaration, but allow calling methods on it). The current plan for the experiment is to have these traits separate, but have the compiler enforce that if they implement the same type, their targets are identical. This will let us open the door for any future possibilities (a supertrait / subtrait relation, or having diverging targets in the future). We want to experiment to see where and how these traits and their possible evolution might be helpful. null-ptr-deref The team would like to have a (an optional) compiler guarantee, that the compiler never removes null checks on raw pointers. What can currently happen in C is that if you deref a null pointer, the compiler can do optimisations including removing any subsequent checks whether that pointer is null, because dereferencing a null pointer is undefined behaviour. But the null check can still help prevent further bugs and in C, the kernel now disables the optimisation that would remove it. Miguel Ojeda is going to open an MCP for this. In-Place Initialization Benno Lossin opened a proposal for an in- person room at the 2026 All Hands for In-place initialization. Here's a meta issue tracking all the proposals and discussions about the feature. The design space is complex and the team hopes that discussing it in person will help move it forward. People involved: Ed Page , b-naber Champions: cargo (Ed Page), compiler (b-naber), crates-io (Carol Nichols) Status: Continued People involved: Amanieu d'Antras Champions: lang (Amanieu d'Antras) Status: Continued 1 detailed update available. Amanieu d'Antras — comment from 2026-04-03 The RFC has just been published. It has been significantly reworked since the last draft. Notable changes: * Removed the concept of activation/de-activation. Now the semantics don't need to deal with partially allocated locals. This is less powerful optimization-wise but should still cover most cases. * Added byref/byval to call arguments to clarify how they are passed. * Added a separate section for the surface language changes to separate it from the MIR changes. * Added more details on the MIR optimization which eliminates moves. * Changed the MIR operand evaluation order to be left-to-right, except for destination places which are always evaluated last. * Added StorageLive back: we need it to mark the location where llvm.lifetime.start should be inserted, which is not the same as the location where a local is initialized. In the opsem, StorageLive doesn't actually allocate the local, that's still done when it is initialized by a write. People involved: Ed Page Champions: cargo (Ed Page) Status: Continued People involved: Weihang Lo Champions: cargo (Weihang Lo) Status: Completed 1 detailed update available. Weihang Lo — comment from 2026-01-08 The prototype of this project goal is basically complete. Current state This project goal introduces build analysis support in Cargo , with the aim of making build behavior understandable across multiple invocations, not just a single run. At a high level, the prototype: * Records build metadata over time, including: * rebuild reasons * timing information * relevant invocation context * Stores this data locally in a structured log format suitable for later analysis * Exposes the data via unstable cargo report subcommands, such as: * cargo report sessions - list session IDs * cargo report timings - HTML timing report * cargo report rebuilds - Why things rebuilt See the Reference for a more thorough usage documentation Path towards stabilization Before this feature can be stabilized, the following unresolved questions must be answered. They might not block stabilization, but need to be evaluated if it is fine to leave for future. cargo report commands This is a stabilization blocker. * Currently all three report commands (`sessions`, `rebuilds`, timings) implicitly inspect global log files when if not in a workspace. * Should this be explicit with a flag? * Should this be an error if not in a workspace? * Bikeshed on command names * Currently we have all nouns * For sessions * runs simple but ambiguous * Just log like git log * history user-friendly (docker history, shell history, though not alike) * For timings: * Not controversial, as we have --timings flag already * For rebuilds: * rebuild-reasons more explicit * Or move to action-oriented verbs: * cargo report list-sessions * cargo report analyze-timings (bazel analyze- profile) * cargo report explain-rebuilds * Or question-oriented verbs: * cargo report what-ran more general (buck2 log what- ran) * cargo report why-rebuilt/why-reran cargo report sessions * Currently it prints a human-readable output without a format for programmable use cases. * Should we provide a programmable output (for example behind --message-format=json)? cargo report rebuilds * Extend the report from fingerprint to new hash (`-Cmetadata`/`-Cextra- filename`) * We currently can't distinguish whether a fresh build is a real new build or just rustflags changed * https://github.com/rust- lang/cargo/pull/16456#discussion_r2662364819 * Make each rebuilt reason more actionable and friendly for end-users. * Should we log the fingerprint values being compared, or just the diff result? * #t-cargo > logging unit fingerprint @ 💬 Log message schema This is a stabilization blocker. * Providing types for reading log messages * We should export `LogMessage` enum and related types in `cargo-util- schemas* Users may want to parse logs programmatically * <https://github.com/rust- lang/cargo/pull/16150#discussion_r2462065538> * JSON schema evolution and versioning * Should we version the schema explicitly in each message? * Compatibility might be the same as <https://doc.rust- lang.org/nightly/cargo/commands/cargo- metadata.html?highlight=compa#compatibility> * Message structure consistency * Current log messages deviate from cargo's normal JSON message structure * Should we align with existing cargo JSON output format, for example thetargetfield? * <https://github.com/rust- lang/cargo/pull/16414#discussion_r2632724893> * <https://github.com/rust- lang/cargo/pull/16303#discussion_r2565526807> * <https://github.com/rust- lang/cargo/pull/16303#discussion_r2561862478> * Should we expose the entireDirtyReasonenum as-is? * Currently exposes internal implementation details * May want to create a separate public-facing enum * Need to decide which variants are user-facing vs internal * Check usefulness of each variant * Some variants may be obsolete (e.g.,RustflagsChangedmay be rare after-Cmetadatachanges) * Need audit of which variants actually occur in practice * Remove or consolidate rarely-used variants * Make dirty reasons end-user friendly * Current reasons are technical (e.g., "local fingerprint type changed") * Users need actionable messages (e.g., "file modified: src/lib.rs") * Exposetargetandmode` * Are they universal for all kind of units? We might want to rename mode to action, as an action kind of a unit. * https://rust- lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/build.20analysis.20log.20format/near/564781487 Log infrastructure These are mostly future possibilities, not a stabilization blocker, as it is highly possible to do incremental improvements. * log compression <https://github.com/rust-lang/cargo/issues/16475> * log rotation <https://github.com/rust-lang/cargo/issues/16471> * Is losing data on crashes ok? https://github.com/rust- lang/cargo/pull//16150#discussion_r2462056940 See also https://github.com/rust- lang/cargo/issues/16471#issuecomment-3724915770 Nested Cargo calls See https://github.com/rust-lang/cargo/issues/16477. Basically, we need to have a way to associate log files of nested Cargo calls. That helps other tools as well as cargo fix itself. This is a stabilization blocker. How contributors can help Future contributors can help by: * picking up any linked issues below or in <https://github.com/rust- lang/cargo/issues/15844> * building external tools utilizing the log messages, and providing feedback * providing real-world feedback from large or unusual builds A series of follow-up tasks has been cut to track remaining work: * https://github.com/rust-lang/cargo/issues/16470 * https://github.com/rust-lang/cargo/issues/16471 * https://github.com/rust-lang/cargo/issues/16472 * https://github.com/rust-lang/cargo/issues/16473 * https://github.com/rust-lang/cargo/issues/16474 * https://github.com/rust-lang/cargo/issues/16475 * https://github.com/rust-lang/cargo/issues/16477 * https://github.com/rust-lang/cargo/issues/16488 People involved: Oliver Scherer Champions: compiler (Oliver Scherer), lang (Scott McMurray), libs (Josh Triplett) Status: Continued 5 detailed updates available. Oliver Scherer — comment from 2026-01-14 * has landed, and we even got the first contribs adding array support to reflection. * there are lots more types and type information that we could support, and it's rather easy to add more. Happy to review any work here. * try_as_dyn and try_as_dyn_mut have landed, and I'm working on removing the 'static requirement. Oliver Scherer — comment from 2026-02-09 * @BD103 added [`Type::of` for unsized types](https://github.com/rust- lang/rust/pull/151019) and support for slices, arrays, and raw pointer * Asuna added all of our primitives * Jamie Hill-Daniel gave us references * @izagawd made it possible to extract some info from dyn Trait There is ongoing work for Adts and function pointers, both of which will land as MVPs and will need some work to make them respect semver or generally become useful in practice Removing the 'static bound from try_as_dyn turned out to have many warts, so I'm limiting it to a much smaller subset and will have borrowck emit the 'static requirement if the other rules do not apply (instead of having an unconditional 'static requirement) Oliver Scherer — comment from 2026-03-19 * I added [support for getting reflection information of any type, not just 'static ones](https://github.com/rust-lang/rust/pull/152381) * 9SonSteroids added a function pointer MVP and trait object support * Asuna added basic struct/enum/union support Oliver Scherer — comment from 2026-04-22 No changes since last time. I'm writing a document for the lang team meeting on reflection next week Oliver Scherer — comment from 2026-04-22 Help wanted
  
  * add more information to adts (e.g. doc comments, attributes, ...),
  
  whatever else is usually used by crates like bevy-reflect * need to make struct field reflection respect privacy
  
  People involved: Ross Sullivan Champions: cargo (Weihang Lo) Status: Completed; the Cargo cross workspace cache 2026 goal will build on this work 2 detailed updates available. Ross Sullivan — comment from 2026-01-15 Fine grain locking for build-dir was merged and now available on nightly via -Zfine- grain-locking unstable flag. 🎉 There are some known issues we'd like to address before doing a formal call for testing. Notably, improving blocking messages, fixing potential thread starvation in Cargo's job queue when locks block, and investigate increasing rlimits to reduce risk of hitting max file descriptors for large projects. I am hopeful that these issues will be resolved over the coming month and we can do a call for testing to start gathering feedback from the community on whether the new locking strategy improves workflows. Ross Sullivan — comment from 2026-03-09 After the initial PR from the last update was merged, we shifted our focus to resolving some of the known issues. Notably, locking blocks the Cargo job queue slowly causing thread starvation if many build units are held by another Cargo instance. We investigated adding the ability for Cargo to "suspend" a job internally while waiting for a lock, but we felt this change was a bit invasive and did not fit well with how the job queue was designed. Instead we plan to change our design to acquire all build unit locks prior to running the job queue (see #16657). At the same time, we have continued to refine the new build-dir to prepare it for a call for testing and eventual stabilization. (#16542, #16502, #16515, #16514) Finally we decided to split .cargo-lock into 2 locks to allow cargo check and cargo build to run in parallel when artifact-dir == build-dir (and -Zfine-grain-locking is enabled) I suspect this may be the last update on this goal, as the 2026 slate of goals is coming up. While I did not renew this goal for 2026, I do plan to continue work on this and eventually stabilize this within this year. People involved: Guillaume Gomez Champions: compiler (Wesley Wiser), infra (Marco Ieni) Status: Completed People involved: Jakob Koschel , Bastian Kersting Status: Continued 3 detailed updates available. Jakob Koschel — comment from 2026-01-14 The MCP has been seconded and is still waiting 3 days to be approved. Once that is done, we can proceed with merging the Tier 2 target. Jakob Koschel — comment from 2026-02-16 Both the MCP and the PR for the AddressSanitizer target have been merged. Next up I should prepare the MCP for the Memory- and ThreadSanitizer targets, hopefully sending out soon. Jakob Koschel — comment from 2026-03-31 The targets for MSan and TSan are merged now. Next, I'll be working on stabilizing those two, now that we have a way to use it without other unstable features (build-std). People involved: Niko Matsakis , vision team Status: Partially completed; work continues outside of Project Goals People involved: James Barford , Jakub Beránek, David Wood Champions: compiler (David Wood), infra (Jakub Beránek) Status: Technical work completed; remaining policy and infrastructure work postponed People involved: Ed Page Champions: cargo (Ed Page) Status: Continued People involved: Guillaume Gomez Champions: rustdoc (Guillaume Gomez) Status: Not completed (blocked)
  
  People involved: David Wood
  
  Champions: compiler (David Wood), lang (Niko Matsakis), libs (Amanieu d'Antras)
  
  Status: Continued
  
  5 detailed updates available.
  
  David Wood — comment from 2026-01-15
  
  rust-lang/rust#143924 has been merged, enabling scalable vector types to be defined on nightly, and I'm working on a patch to introduce unstable intrinsics/scalable vector types to std::arch
  
  David Wood — comment from 2026-02-17
  
  Progress has been slow since the last update because I've been busy, but I've been working on a rebase of rust- lang/stdarch#1509, which has bitrot quite a bit. Rémy Rakic is joining me to work on the Sized Hierarchy parts of the goal.
  
  David Wood — comment from 2026-03-17
  
  On the scalable vector half of the goal, I've got a branch with rust- lang/stdarch#1509 rebased, though without the intrinsic-test tool having been updated - that ended up being tricky and we've agreed to do it as a follow-up. We've opened rust- lang/rust#153286 with the compiler fixes that the stdarch patch requires, which should land soon (rust-lang/rust#153653 was opened and landed in the interim).
  
  On the sized hierarchy half of the goal, Rémy Rakic has been updating our RFC such that we can discuss it in design meetings with the language team on the 18th and 25th - we'll update rust-lang/rfcs#3729 later today. We've split out the const Sized parts as a future possibility (though one we are committed to pursuing) as that has more open design questions, and we've discussed the proposed syntax and approach to migration - which are what we intend to focus on in the design meetings. He's also been working out how we can start implementing our migration strategy and help resolve blockers in other areas.
  
  David Wood — comment from 2026-03-17
  
  Per last comment, rust-lang/rfcs#3729 has been updated
  
  David Wood — comment from 2026-04-14
  
  For the scalable vector half of the goal, we've landed a bunch of compiler fixes - rust-lang/rust#153286, rust-lang/rust#153608, rust-lang/rust#154850, rust-lang/rust#154950, rust-lang/rust#155106 and rust-lang/rust#155243 - and opened our stdarch patch with intrinsics - rust-lang/stdarch#2071. That patch should be passing CI tomorrow once nightly updates to fix an unrelated spurious CI failure. We've got a handful of follow-ups to do afterwards, listed on rust-lang/rust#145052.
  
  For the sized hierarchy half of the goal, Rémy Rakic and I had two design meetings with the language team (2026/03/18 and 2026/03/25) discussing the syntax/naming and migration strategy respectively.
  
  On syntax, the language team preferred introducing an "only bounds" syntax to control opting-out of default bounds and opting-in to alternative bounds in a family of traits (described in an alternative in the RFC), but there was an open question of whether that syntax should apply to an individual bound or all of the bounds - Niko Matsakis is investigating that.
  
  On naming, the language team also preferred the name SizeOfVal over MetaSized, and didn't like Pointee but had no better alternatives. Rémy Rakic prepared rust-lang/rust#154374 to do that renaming and started a discussion with the library team to confirm they were happy with the name, because changing it involves an amount of churn. The library team wanted to know what other traits in the hierarchy might later be introduced, as that would help inform the naming of the currently proposed traits, so Rémy Rakic wrote up a document with that information. We're holding off on doing any name changes until we find some consensus between libs and lang - who is responsible for these traits' names is a bit unclear.
  
  On migration, the language team were largely happy with our proposed approach, and we realised that the approach proposed by lcnr for associated types might also work for our other migrations. Rémy Rakic has had meetings with lcnr to better understand that approach and to work out the next steps for implementing it.
  
  People involved: Boxy , lcnr
  
  Champions: types (Boxy)
  
  Status: Continued
  
  People involved: Jack Wrenn , Jacob Pratt, Luca Versari
  
  Champions: compiler (Jack Wrenn), lang (Scott McMurray)
  
  Status: Continued
  
  2 detailed updates available.
  
  Jack Wrenn — comment from 2026-02-18
  
  RFC has been accepted. I'm preparing a 2026 continuing goal for stabilization.
  
  Jack Wrenn — comment from 2026-04-14
  
  Opened PR (#16767(https://github.com/rust-lang/rust- clippy/pull/16767)) extending Clippy support to unsafe fields.
  
  Blockers
  
  Waiting for t-clippy to review #16767(https://github.com/rust-lang/rust- clippy/pull/16767).
34. 🔗 matklad Always Be Blaming rss
  Always Be Blaming
  
  May 18, 2026
  
  A few tips on 4D-ing your code comprehension skills.
  
  I wrote on the importance of reading code before: Look Out For Bugs My default approach to reading is “predictive”: I don’t actually read the code line by line. Rather, I try to understand the problem that it wants to solve, then imagine my own solution, and read the “diff” between what I have in my mind and what I see in the editor. Non-empty “diff” signifies either a bug in my understanding, or an opportunity to improve the code.
  
  This is 2D reading, understanding a snapshot of code, frozen in time. This is usually enough to spot “this feels odd” anomalies, worthy of further investigation.
  
  Ideal code is memoryless — it precisely solves the problem at hand. Most real code is Markov — the shape of the code at time T depends not only on the problem statement, but also on the shape of the code at time T - 1. The 3D step is to trace the evolution of code over time, Where Do We Come From? What Are We? Where Are We Going?.
  
  The step after that is to understand the why. What were we thinking back then, when we wrote this code? It’s useful to have the “theory of mind” concept ready here. I personally learned the term way too late in my life, so let me give a short intro for today’s lucky 10 000. Theory of mind is the ability to imagine yourself in someone else’s skin. Not just in their shoes (“I certainly would have acted differently in that situation”), but with their mind (“ I wouldn’t have acted that way, but I get why they did”). This is something people learn. The experimental setup here is to have a child in a room with toys, with a doll sitting near the opposite end of the room, and asking the child “what does the doll see?”. Younger children describe the room from their perspective, older begin to intuit that doll’s perspective is different.
  
  So this is the goal of reading code — understanding what the original author was thinking, and why.
  
  End of the mumbo-jumbo, some practical advice. First, read Every line of code is always documented, it is very good.
  
  Second, make sure it is effortless for you to find out how a given snippet of code evolved. This is harder than it seems! Just git blame isn’t an answer — mind the gap between the problem that’s easy to solve, and the problem in need of solving.
  
  git blame answers spatial question of “how each line appeared in this file”, because there’s a relatively straightforward UI for this — annotate each line with a commit hash. But this is not the question you are asking most of the time! You don’t care about the file! There’s a small snippet of code in the middle, and you want a temporal history of that.
  
  As much as I don’t like working in the browser GitHub’s web interface for blaming is probably better than what you get locally by default. It starts with the y shortcut, which resolves a symbolic reference like
```
https://github.com/tigerbeetle/tigerbeetle/blob/main/src/vsr/replica.zig
```
  into the one which has a commit hash in the URL:
```
https://github.com/tigerbeetle/tigerbeetle/blob/c54f613a2eb2a127a0ba212704e3fa988c42e5cb/src/vsr/replica.zig
```
  This commit hash is critical, because it anchors the entire repository — if you open a different file from the web UI, it will be shown as of that commit. This enables you to not myopically focus on just the diff in question, but to absorb the entire context at that point in time.
  
  So my usual web workflow is:
  - ctrl`+`f to find the line I am interested in
  - b to toggle blame
  - Click “blame prior to change” a couple of times, repeating ctrl`+`f to go back to the snippet I am curious about.
  - cmd-click on the commits that are potentially relevant, pinning their commit hashes in the URL in new tabs.
  - Then, from the commit page, “Browse files” button to then go and t to other files. Or, cmd`+`l to focus browser’s address bar, and s/commit/tree/ (or back!) as needed, to switch between diff and snapshot views.
  Again, my goal here is not to annotate a diff on a file but rather to get a “virtual checkout” as of the interesting commit.
  
  This web approach is what I was using throughout most of my career, but I’ve finally found a way to replicate it locally. The idea is to make blaming “in- place”. Instead of git blame annotating lines of code, I directly switch to a historical commit. I have the following devil hydra of shortcuts:
  
  , b l blames line. It notes the $line the cursor is at, runs git blame -L $line,$line to find $commit that introduced the line, and then runs git switch --detach $commit to check it out. I have a dedicated worktree for code archeology, so I don’t worry about trashing my work. There’s also a half- hearted attempt to maintain “logical” cursor position, but it doesn’t work very well. Is there some git command that tells me directly “what’s the equivalent of $file:$line:column in $sha-A for $sha-B?”
  
  , b p blames parent. Which is just switching to the parent commit of the current HEAD, what “blame before this change” does on GitHub (it works slightly differently because it assumes that , b l was the previous command)
  
  , b u undoes the last blaming operation, switching to the previous point. I really love that, on the web, I can cmd-click to create an alternative branch of exploration. In theory, this is replicatable locally, but I prefer to destructively mutate a single working tree on disk. A big reason for preferring in-place blame is that LSP, ./zig/zig build test, rg and the like just work. That’s more important for me than the garden of forking paths, and undo is an acceptable work-around.
  
  Finally, , b w copies GitHub link to the current commit and line, which I can paste into the browser. An enormous problem with modern version control landscape is that absolutely critical information in the form of code review comments is not a part of the git repository, and is locked in someone else’s proprietary database. I failed to solve this problem in one weekend, and had to begrudgingly adapt. Opening the commit in a browser links you to the PR and its discussion as well.
  
  Implementing this blame workflow required a bit of custom code. Feel free to use it, but beware that it’s somewhat crufty, especially around maintaining current cursor position. Making a production- ready version of this sounds like a fun project ;-)
May 17, 2026
1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-05-17 rss
  IDA Plugin Updates on 2026-05-17
  
  Activity:
  - tix-seven
    
    4b4aa46a: fix(web): release camera tracks when QR scanner stops
    
    0dab8659: fix(web): stop QR scanner when issue-ticket dialog closes
    
    64af6b48: feat(web): add CSV, JSON, and XLSX export for event data
    
    eb1bdc1a: feat(web): improve entry log feed search and timestamps
    
    8ab241c5: feat(web): wire event header actions and export entry points
    
    1bc8ca6f: feat(web): add tabbed ticket and gate registry on event detail
    
    0f475d01: feat(web): add in-event gate registry management
    
    300c6206: feat(web): refresh events list with search and page shell
    
    48188ac2: feat(web): add event cancellation with confirmation dialog
    
    62daf007: feat(web): refactor event form with snapshot diffing and API routes
    
    11635244: feat(web): add registry table search helper
    
    2682a959: refactor(web): remove standalone gate management routes
    
    c5f0b6ca: feat(web): add event sidebar navigation with live event list
    
    82d3c2c2: feat(web): add dashboard shell with scrollable content area
    
    541edd90: feat(web): configure app metadata and sign-in page title
    
    b2524ae9: feat(web): add CopyableId, Tabs, and registry table primitives
    
    4fe9a3d7: feat(web): add authenticated Next.js routes for events and gates
    
    396dde70: feat(web): add typed event and gate mutation clients
    
    1f01a799: feat(web): parse gate-server validation errors in HTTP client
2. 🔗 sacha chua :: living an awesome life May 29: Emacs Chat with Omar Antolin Camarena rss
  On May 29, I'll chat with Omar Antolín Camarena about Emacs and Life.
  
  Watch on YouTube
  
  <2026-05-29 Fri 10:30>–<2026-05-29 Fri 11:30> (America/Toronto) = Fri May 29 1030H EDT / 0930H CDT / 0830H MDT / 0730H PDT / 1430H UTC / 1630H CEST / 1730H EEST / 2000H IST / 2230H +08 / 2330H JST
  
  Related links:
  - Omar Antolín Camarena: a researcher at Instituto de Matemáticas, UNAM in Mexico City
  - M-x apropos Emacs
  - oantolin/emacs-config: My personal Emacs configuration · GitHub
  - oantolin (Omar Antolín Camarena) · GitHub
  - Omar Antolín (@oantolin@mathstodon.xyz) - Mathstodon
  - u/oantolin on Reddit
  This session will be recorded, and I'll update this blog post with notes: https://sachachua.com/blog/2026/05/may-29-emacs-chat-with-omar-antolin-camarena/
  
  You can add the iCal for upcoming Emacs Chat episodes to your calendar. https://sachachua.com/topic/upcoming-emacs-chats.ics
  
  Find more Emacs Chats or join the fun: https://sachachua.com/emacs-chat
  
  View Org source for this post
  
  You can e-mail me at sacha@sachachua.com.
3. 🔗 r/LocalLLaMA "Generate a photorealistic realtime render of a human face with webGL" (Qwen3.5-122B-A10B UD-Q3_K_XL) rss
  
  | submitted by /u/TheWolfOfWalmart
  [link] [comments]
  ---|---
4. 🔗 r/Yorkshire Looking for a paint artist rss
  
  Hi,
  
  I am am looking for an artist to paint a wedding photo for our wedding anniversary. Any recommendatio n would be great. We're new to Yorkshire and love it here - we believe there are many brilliant creative talents here. It's a portrait with a beautiful city in the background. Not sure how to look for artist with our preferred style so a portfolio, market stall or shop would be great.
  
  TIA
  
  submitted by /u/okcalvin
  [link] [comments]
5. 🔗 r/Harrogate What contributes to Harrogate’s happiness/polite/friendly people? rss
  
  Time & time again I am very impressed by Harrogate. Service workers, even saying hello/good morning on the street is normal. People smile at each other in the valley garden. Bar staff are very friendly, seem to remember you and a lot of people have good manners.
  
  submitted by /u/Apprehensive_Ring666
  [link] [comments]
6. 🔗 r/Leeds Dumpster diving Hyde Park rss
  
  Hey, with June coming up I would have thought it's move out date for students. From what I've seen furniture, food, clothes seem to get thrown away. I am nearly homeless, going through a financial crisis right now and a bit of a freegan. I've heard Hyde Park is where students mainly hanging out, just wondering if anyone knows when moving out day is? Obviously don't want to disturb the students while they're still living there or make them uncomfortable.
  
  I have been trying to find food but only really found cardboard boxes for selling stuff on Vinted. Most bins around me are locked up or have trespassing signs. Anyone know any good spots?
  
  submitted by /u/coolseabreezes
  [link] [comments]
7. 🔗 r/LocalLLaMA M5 vs DGX Spark vs Strix Halo vs RTX 6000 rss
  
  | Hey guys, super simple. There have been a lot of online debates about the new M5 Macs vs DGX Sparks vs Strix Halo vs dedicated GPUs etc. So I put them all in a room with good power and cooling and ran everything in parallel with standardized tests for the past 3 days, and published everything to a repo. A lot of it isn’t a big surprise when you just think about headline numbers and fundamentals. An RTX6000 has a memory bandwidth speed of ~1,800 gb/s vs ~600 for the M5 vs ~256 for the Spark and Strix. Tokens per second per piece of hardware follows that math and curve pretty well. For the price point, and assuming you are ecosystem agnostic, the maxed out M5 is genuinely legit and very aggressively outperforms the DGX Spark. Again, not really a surprise when you look at their memory bandwidth speeds (2x+ memory bandwidth speeds on the M5 with the same total unified memory). Second thing worth noting was also probably no surprise but the EVO X2 thermals were an issue with extended runs. The MacBook actually surprised me with how well it held up thermally more than anything. It ran for a few days and cruised in the 80c range. I will say this though, it sounds like a normal gaming laptop when it cooks. There’s a bit of propaganda going on when people say “quiet” with these. You ramp up an M5 MacBook Pro to cook with local AI and it turns into a blow dryer like every other laptop that’s ever tried to cook with local AI. It’s built like an aircraft carrier and performs really well for what it is, but you will 100% know it’s working when it runs lol. I’m now swapping back ends and adding data for things like MLX on Mac, different hosting backends on Strix Halo, etc. for how they all impact performance and outputs. The RTX6000 is not the same as the RTX5090 just so the obvious police don’t grab me, but there are a lot of similarities between cards that could make this data useful for someone debating a 5090 PC vs these other machines. Either way, repo enclosed, hope this helps provide some raw data and numbers for future discussions and debates: https://github.com/Light-Heart-Labs/MMBT-Messy-Model-Bench-Tests/tree/main/hardware-tests submitted by /u/Signal_Ad657
  [link] [comments]
  ---|---
8. 🔗 r/Yorkshire A few photos from my walk near Penistone today rss
  
  | submitted by /u/walshamboy
  [link] [comments]
  ---|---
9. 🔗 earendil-works/pi v0.75.0 release
  Breaking Changes
  - Raised the minimum supported Node.js version to 22.19.0.
  Fixed
  - Fixed compaction summary calls to use custom agent stream functions, preserving proxy-backed LLM routing (#4484).
  - Fixed system prompt and context file boundaries to use explicit XML tags instead of Markdown headings, reducing inconsistent boundary ingestion by models (#4541 by @herrnel).
  - Fixed OpenAI Codex generated model metadata to use the current upstream model list inherited from @earendil-works/pi-ai (#4603 by @mattiacerutti).
  - Fixed GitHub Copilot GPT model thinking metadata inherited from @earendil-works/pi-ai to map unsupported minimal thinking to low (#4622 by @mattiacerutti).
  - Fixed user-scoped npm pi packages to install under ~/.pi/agent/npm/ instead of npm's global package root, avoiding permission errors with system-managed Node installs (#4587).
  - Fixed Mistral requests failing after the global fetch proxy/timeout workaround by removing the custom fetch override and using undici 8 dispatcher support instead (#4619).
  - Fixed default output token requests for models whose advertised output limit is effectively their full context window, avoiding impossible provider requests inherited from @earendil-works/pi-ai (#4614).
10. 🔗 r/Yorkshire An afternoon at the Old Gang Smelting Mills, near Reeth, Swaledale rss
  
  | Yorkshire Lead Mining at its peak dug hundreds of tons a month, the early mines were hand excavated and even after dynamite was invented holes for setting it had to be hand drilled. My wife's 3x Great Grandfather Elkanah Bell ran a herd of donkeys supplying the mines and hauling out lead. Today it is a haunting ghostly place, the wind whistles around the stones. There are no lists of the many who must have died to make owners rich, it was a hard life! submitted by /u/Still_Function_5428
  [link] [comments]
  ---|---
11. 🔗 r/LocalLLaMA I hope that someday we will have a 124B Gemma. rss
  
  | submitted by /u/cgs019283
  [link] [comments]
  ---|---
12. 🔗 r/york Anyone had a bike stolen? rss
  
  I've found a Cube Attain SL Disc Road Bike in green/black/grey left abandoned outside the fire exit of my work at Clifton Moor, without a lock or anything. The seat has been raised beyond max height, so it's either owned by someone very tall of been tampered with.
  
  I've enquired with the Bike Register and sent an email to the ReCycle shop on Fossgate, but because it's a Sunday obviously I'll have to wait for a response.
  
  I've brought it home to the town centre as we've no storage space at my work that's not in front of the fire exit, so if anyone knows of someone that's lost one of that description, let them know it's safe out of scally hands.
  
  submitted by /u/Cold_Bank_7901
  [link] [comments]
13. 🔗 r/Leeds Weaver Network bus shelters rss
  
  I like the whole rebrand from Metro but what’s with the grey? Would they not look better being all green?
  
  submitted by /u/National-Pay-8911
  [link] [comments]
14. 🔗 r/Yorkshire A few photos from my walk home after Sunday dinner. North Yorkshire. rss
  
  | Some photos from South Kilvington, Thirsk, Felixkirk. A little chilly but it warmed up a bit in the afternoon. submitted by /u/badsyntax
  [link] [comments]
  ---|---
15. 🔗 r/Leeds Looking For A Swim Buddy rss
  
  Hey!
  
  I am getting back into swimming after a year out as part of my exercise routine. I would love it if I could have another guy come and help me out, keep it social and not overly physical? Because that's why I keep dropping it.
  
  The goal is to eventually, be fit enough to do a sponsored swimathon.
  
  I aim to go to Kirkstall Leisure every week after work around 18.30ish. have an hour in the pool, then maybe a drink and food? I want to keep this as casual as possible so I can keep with it.
  
  I am a man and would prefer my buddy be the same. However I'm open to anybody :)
  
  submitted by /u/MidlifeCrisisCore98
  [link] [comments]
16. 🔗 r/york Backyard garden tidying up. rss
  
  | Hi Everyone, Looking for a fair price to tidy up this backyard garden.
  It’s a small-to-medium sized garden and hasn’t been maintained for a while but isn’t completely overgrown. Mainly needs:
  long grass cut/strimmed weeds cleared fence line tidied patio weeds removed possible green waste removal What would you expect to pay for a one-off tidy up like this? Also open to gardener recommendations if anyone knows someone reliable. Thanks! submitted by /u/Ambivertpayyan
  [link] [comments]
  ---|---
17. 🔗 sacha chua :: living an awesome life YE29: Sacha, Prot, and Philip Kaludercic Talk Emacs: Newcomer Experience rss
  [2026-05-18 Mon]: Updated transcript
  
  Philip Kaludercic wanted to continue the conversation from YE24: Sacha and Prot Talk Emacs - Newbies/Starter Kits. He's spent a lot of time thinking about this as one of the main contributors to newcomers-presets. We talked about newcomers-presets, the idea of a "reset theme" that lets experienced users pin defaults to a specific version of Emacs, upcoming changes, and working with emacs-devel.
  
  View in the Internet Archive, watch or comment on YouTube, read the transcript online, download the transcript, or e-mail me.
  
  ------
  Related links
  
  Chapters
  
  Transcript
  
  Chat
  
  Some types of new users to think about
  
  Sketching out their learning journey
  
  Other notes
  
  Some screenshots of a fresh Emacs
  
  Trying pkal's Emacs Configuration Generator
  Related links
  
  A proposal for a "beginners" (user-option) theme - Philip Kaludercic
  
  Re: some file-related options to consider for newcomers-presets - Philip Kaludercic
  
  A newcomer's feedback on newcomer presets - Abdulnafe Toulaimat
  
  Emacs Configuration Generator - old source code
  Chapters
  
  0:01 Opening
  
  3:01 newcomers-presets user option theme; would be nice to explain what the changes are
  
  5:03 finding a balance between "it's fine the way it is" and "just use Doom Emacs"
  
  6:39 people value stability, but also conventions have shifted.
  
  6:53 ways Emacs does things differently: ex: terminal vs eshell, output is editable; new users want to edit the previous prompt; sometimes goes against people's intuitions
  
  9:23 How do people develop Emacs intuition? Immersion
  
  9:58 example: dabbrev, there's no undo? Ah, it's just the regular undo.
  
  11:03 newcomers presets: smooth over the intuition-disrupting things that are not actually necessary/beneficial; ex: enable which-key
  
  14:35 newcomers-presets choice is not saved at the moment
  
  17:09 newcomers without much computing experience might even find it easier (no C-c expectations, C-v etc)
  
  18:32 Focus group?
  
  22:18 Emacs survey before
  
  22:50 people's backgrounds influence their responses
  
  23:49 Hypothetical: Reset themes, to reset things back to the defaults of a specific Emacs version
  
  24:22 package-autosuggest-mode suggests based on file extension
  
  27:58 Emacs 32: bundled versions of Emacs (Big Emacs - distributions that include more packages)
  
  29:58 Selection versus multiple completion
  
  34:41 Manuals
  
  35:11 More examples?
  
  36:24 find-user-init-file?
  
  38:40 Getting over the reverence for Emacs's history
  
  40:13 Changes are more likely to happen when someone puts in the work to make a patch
  
  44:06 Preserving Git history of packages absorbed into the core
  
  46:02 Dealing with multiple types of Emacs
  
  48:11 Fat Emacs is just about bundling more packages from ELPA, not changing the configuration for them
  
  51:24 Customize
  
  54:44 CUA - Common User Access
  
  55:04 ini file format? https://sdf.org/~pkal//blog/emacs/ini-init.html
  
  55:13 Emacs configuration generator
  
  55:56 INI-style configuration
  
  1:00:25 Quick summary
  
  1:02:29 Continuing with INI
  
  1:04:45 Motivation
  
  1:06:54 Politics and philosophy
  
  1:09:26 Experimenting with things outside core
  
  1:10:45 Extending the core
  
  1:11:55 Guide to contributing to ELPA
  
  1:13:13 Making the newcomer experience better
  
  1:14:33 "user option themes" versus "appearance themes"
  
  1:15:27 find-library
  
  1:16:54 configuration generator in Emacs? maybe more wizards?
  
  1:17:04 Starter kits
  
  1:17:42 Configuration generator in Emacs Lisp?
  
  1:18:42 extending the archive format
  
  1:20:58 User interfaces
  Transcript
  
  Expand this to read the transcript
  
  0:00 Opening
  Sacha: I'm going to start recording. I'm going to do the thing. I'll let you know. Okay. Let's do this. Yeah.
  Prot: Yeah.
  Sacha: Yeah. Okay. Hang on a second. Starting, going live. Okay. So, hello, everyone. This is Yay Emacs 29. And today I am here with Prot and Philip Kaludercic. We're having this conversation about Emacs newcomer experience, which started off with an Emacs carnival last month about newbies and starter kits, which Cena started and you fleshed out with more questions. And now this is snowballing to, okay, let's figure out what we can do to make Emacs easier for newbies who are coming in, maybe they're non-developers who have heard good things about Org Mode, or maybe they're developers who want to try out what this Emacs thing is and what's all the fuss about having an editor that's been around for so long. Or maybe they're actually still VS Code or Vim fans, but they really just want to use Magit, so they're coming in just for that. A lot of different paths to coming into Emacs. We do have this live stream, so if people have questions, I will at some point figure out where the chat is on my screen so I can read them out to you. But my plan here is I'll just be in the background taking notes most of the time and interjecting with occasional questions. And maybe Philip and Prot, you can go brain dump all the wonderful things you've been thinking about the Emacs newcomer experience.
  Philip: At this point, regret not having written down any notes from the last video or from your last recording of YouTube, because I noticed I had a few things I wanted to add or intersperse. But I guess we can take a look at two things. So first one is the state of introducing people to Emacs now. And the question there is, who are we introducing Emacs to? Just like you said, you sketched out a few different profiles of people who presumably have entirely different interests, motivations, like if someone wants to just use Magit like Emacs is there. It's the tool, it's the GUI that implements Magit, then these people have an entirely different motivation than someone who actually says, well, I'm coming at it from, I heard it's an interesting tool for free software development. Build your own or understand free software in a different sense, where you can actually do find-function and open the definition of the function you just used. I think malleable is the current catch word that people like to use in that context. So there's some issue in that sense.
  2:59 newcomers-presets user option theme; would be nice to explain what the changes are
  Philip: And then the specific comment from the last discussion which caught my attention was We were talking about Emacs 31, there's this preset theme, the newcomers-presets theme, which is implemented as a user option theme, or that's how I like to refer to it. And I probably should just briefly stop and say that everything I'm saying is from my own perspective. I don't feel comfortable saying that this is the Emacs-devel perspective or that any other of the Emacs developers necessarily have to agree with me. I just think that I might have a few things.
  Prot: Sorry, I lost your audio. Just to say I lost your audio, Philip. Excuse me. Sorry, I lost your audio for a second. You could hear it fine. I will hear it in the recording.
  Sacha: Okay, so basically, you can repeat it, I guess. Go ahead.
  Philip: What did I say? So you were saying that... I'm not representing emacs-devel. These are my views which are informed by the discussions that we had in emacs-devel that I hope will be represented. I think I'm the maintainer of the preset theme, but of course other people are also contributing to it and adding other options. Specific points I had like the target audience of the preset theme was not people who would be particularly interested. What the options are. I think that was a discussion point last time. I admit it's a technical deficiency currently. There's no pretty way. I think it would be nice if we extended describe theme to actually list the options that are modified with hyperlinks so that you could look into these options. That's currently not there. We didn't add it in time for the feature cut for Emacs 31, but I think for Emacs 32 that's going to be an interesting Feature to have at some point.
  5:00 finding a balance between "it's fine the way it is" and "just use Doom Emacs"
  Philip: And actually the idea had been floating around I think like every time there was like there's a periodic, periodical discussions like how should we make Emacs more user-friendly on Emacs level and people say we have to like say the extremist position is what do you mean not user-friendly. It's perfect the way it is. It's God-given configuration. And the other people who say, well, why don't we just install Doom Emacs and make that the default then? Somewhere in between, I think there is a reasonable position to be had. But in these discussions, one of the reasons this came... I participated maybe in four or five of them, and then this point came up: why don't we have a theme, like a collection of user options, which you can toggle in one switch, which enable all the options from which we would not find, which existing users would not find interesting, which are always the bulk of the users. Most people are already existing users. They don't come in and... One of the things is, lots of existing users, I'm thinking of like a 60-year-old professor who has been using Emacs for 30 years, or a software engineer who's using it, and maybe consciously or unconsciously appreciates the fact that it doesn't change every few years. You don't have a graphic designer. This is, of course, me against graphic designers and UI designers who have a need to reinvent the UI interface every few years and then things change. And how do I save now? What's the... What's the button to do this? And the UI changes.
  6:37 people value stability, but also conventions have shifted.
  Philip: The people who value the stability. But of course, the common conventions have grown apart. What Emacs does and what people are used to from other programs.
  6:50 ways Emacs does things differently: ex: terminal vs eshell, output is editable; new users want to edit the previous prompt; sometimes goes against people's intuitions
  Philip: Now, at this point, we also have to distinguish that there are things which Emacs doesn't do the way other programs do, which are... Which I would argue are actually sensible. For example, I think one issue I remember was when I first started using Emacs, I had a terminal emulator. I wanted to have a terminal emulator within Emacs. Nowadays I use Emacs Shell, which to me seems like a more truer Emacs experience. It's an opinion, a strong opinion maybe. And it's also influenced by a history of using Plan 9 and that kind of terminal where actually the output is just as editable. You can just search it. You can edit it. You can cut it. You can interact with the output any way you would use a normal text, which is not something you can do with a terminal for purely historical reasons. At my university, the university where I studied computer science, I frequently helped people in the introductory Linux course. One thing you notice there, these are real newcomers. These are people who have never used Linux or a terminal or anything like that before. The first thing they do when they want to, like, they use the arrow keys expecting or click on, they use the mouse and click on the previous prompt. And they want to modify the previous prompt. Of course, that doesn't work because that's not how terminal emulators work. All the previous output, that's fixed. You don't touch that anymore. Everyone, I guess even people who we describe as newcomers, talking about Emacs, obviously know of course you don't touch the previous prompt in the terminal. These are some expectations you have, if you use Eclipse, if you use VS Code, if you use... I'm not sure how the NeoVim terminal emulator works. I know they have a built-in one. I think Vim also, but I'm guessing right now. So there are some accumulated intuitions which Emacs actually intentionally doesn't want to give, doesn't want to give in all purpose, because I'd argue that one of the strengths of Emacs is really having this uniform text interface where I can use isearch, I can use occur, I can use the highlighting commands, I can just select a region and write it out to a buffer, and stuff like that. That shell buffer is no different than anything else in that respect. Please interrupt me by the way. This is not supposed to be a monologue.
  Prot: No, no, no. Go ahead.
  Sacha: So it sounds like there's an interesting challenge here.
  Philip: Breaking some of these intuitions is legitimate.
  Sacha: Yeah.
  9:21 How do people develop Emacs intuition? Immersion
  Sacha: How do we help people develop the Emacs intuitions?
  Philip: To some degree, it really feels like it has to be something that you immerse yourself in. The issue, I guess, is, well, I know, I mean, I knew people who actually used Emacs. I mean, you can help them in a face-to-face setting or like Prot does in his teaching settings. Then you communicate certain things, which I don't want to say they're ineffable. It's not like you couldn't write them down in a manual, but it's also... Like the mentality that people have.
  9:55 example: dabbrev, there's no undo? Ah, it's just the regular undo.
  Philip: A different example I have, like, I remember I was using daabrev for the first time or something. For a while I was irritated. There was no undo. Like, how do I go back to the previous text expansion? Until at some point I realized, oh wait, it's just regular undo. That's just the way you undo it. But somehow writing this down in a manual is... It's not an easy thing to always think of these things. For me it seems obvious now, but at that point I specifically remember it was unintuitive. I had this accumulated expectation from other programmers if I have a text expansion in this case that I'm actually cycling through some special sort of menu, not thinking of it as just regular text buffer operations. Just text editing in some fancy way. But that's one We should keep in mind. This was all related to the preset theme in some way, right? You're writing this down.
  Sacha: Yes, I'm writing this down. That's why we have notes.
  11:00 newcomers presets: smooth over the intuition-disrupting things that are not actually necessary/beneficial; ex: enable which-key
  Sacha: So what I'm thinking is you wanted the idea behind the newcomers presets is to kind of smooth over some of those intuition disrupting things where people are coming in with maybe expectations of how stuff should work in a modern editor.
  Philip: Specifically, the intuition. Specifically, the intuition-disrupting things which are not necessary, in some sense. Like, we wouldn't want to be an intuition disrupt... like you could probably... Like Cua mode or something, that would be something where people if they would start using... If you would enable Cua-mode by default, that would inhibit further development, because then it might be confusing with using C-c, like if you... because suddenly Delay becomes a user input, which is usually not the case with Emacs. I know which-key is an exception in that case, because which-key pausing actually is an action and displays a pop-up buffer. And we do enable which-key due to popular requests and the preset theme. I personally was a bit hesitant about that one, but it seems to be something. where you have to really weigh it on a case-to-case basis. But, Sacha, do you have the... What version of Emacs do you have running there? I can't make it out.
  Sacha: Yeah, this is Emacs 31, so I do have...
  Philip: So you can open the preset theme, right?
  Sacha: Yeah, yeah. Hang on a second. Let me bring up a... I have now a terminal, so I can... Let me bring up a completely fresh Emacs.
  Philip: No, I just want you to open the file. Because in the file there is a prelude. There's a commentary section that actually explains the curve. It's not a library. That's exactly the joke with the...
  Prot: Yeah, that's part of the problem with those themes.
  Philip: That's the problem. Themes are not libraries.
  Prot: It would be easier if they were all there. It's a kind of an implementation detail that from a user, it doesn't really make a difference.
  Sacha: All right, newcomers-presets.
  Philip: If I remember correctly...
  Prot: Yeah, yeah, exactly.
  Philip: Yeah, and you see up there the commentary section?
  Sacha: Yeah.
  Philip: If you scroll up a bit, it's above line 37. The theme configures which we can reasonably expect the average user to want to enable, but would otherwise be unlikely to discover on their own. That's sort of the overall guide of what options we want to add. That's why it's also an option on the splash screen. You just tick it, and then the user options enabled in the theme should be activated by default. That's sort of the idea.
  Sacha: It is available on the splash screen. So if I say display-splash... Oh my goodness, how do I get to the splash screen?
  Prot: It's C-h C-a or not? I forgot. C-h a maybe?
  Philip: There are two things. There's a splash screen and there's the...
  Sacha: Hang on a second. I'm just going to start a new Emacs.
  Prot: Yeah, I haven't done that in, like, I don't know...
  Philip: That's the about Emacs screen. But you have a display splash screen.
  Prot: C-h C-a on mine. About Emacs. M-x about-emacs.
  Sacha: No, I have a better idea. I'm going to start this new Emacs person. Okay, here we go. New Emacs. Fresh person.
  Sacha: So we click on this, right? And it turns on a bunch of things including the tab bar.
  14:32 newcomers-presets choice is not saved at the moment
  Sacha: I wasn't entirely sure how people would save that so that it happens again next time. Is the idea that they just keep checking that box?
  Philip: That's not done currently. That's something we haven't simply decided on. The current presentation is you enable it in that mode and then you'd have to, which is of course saying it out loud makes it sound stupid, but you'd have to persistently save the themes. So then I think it's optional to save themes and then...
  Sacha: It is possible for people to get to it if we leave them a breadcrumb. But it's not going to occur to them because it would never occur to them to say customize Emacs, custom themes, and then I can pick newcomers themes from here.
  Philip: It's a point that I at least intended to mention at some point on emacs-devel, whether we want to make this, because currently it just loads the theme, but it doesn't persist the choice, but it could just as well persist the choice. There's a discussion to be had which of these two behaviors is more intuitive, because of course, if you persist the option, then you have the disadvantage that someone might enable it, but doesn't actually want it, but now somehow their Emacs is broken from their perspective. I don't want tabs or whatever they say, or I don't want which-key, and they don't know how to disable it. So this is... I wouldn't say it's an obvious decision in either direction.
  Prot: Like if there is an enable button or save, there should be a disable and unsave, like remove.
  Philip: Yeah, that's the checkbox idea in that case.
  Prot: That would be the tricky part. And especially, finding the place on the splash screen so that this actually works for everyone... Because if you open it in a TUI mode, I think then initially, if I remember correctly, we had this button or this new to Emacs line was underneath the copyrights. No, no, that was a different thing.
  Prot: If you click on newcomers preset, for example, then you are redirected to the manual entry. And I think we had some, yeah, there's this, the top line. If you got here by clicking the link on the splash screen, that was on the bottom. That was on the bottom of the manual entry. But if you open it up in an 80x24 terminal, you wouldn't see this line.
  Sacha: You can't see it and you don't know how to... These are the complications that you have to keep in mind in that case.
  Philip: You might not have the intuition that SPC is scroll, which I think that's the case in less. But yes, again, you have this accumulated intuition from using Unix tools. Which is one of the points I wanted to bring up.
  17:08 newcomers without much computing experience might even find it easier (no C-c expectations, C-v etc)
  Philip: Who is this mythical newcomer? What's their actual background? Because I claim, and this might be controversial, that if someone's actually new to using computers at all, which is something I have seen, like people who have never programmed, people who have never used Unix, people who have never used more than a web browser, to exaggerate, they appear to do fine with Emacs because they have no expectation of using C-c, C-v, C-c, and so on. They know that they have to use the buttons up there. So in that sense, they're fine. There's an optimization loop when you're used to these shortcuts and a few of these conventions how to move around, that Emacs defaults appear to be inconvenient. So that's also a distinction you have to make in that setting.
  Prot: Exactly, exactly. Plus you cannot optimize for everybody. Eventually you just have to make some assumptions.
  Philip: Exactly. But what these assumptions are is the controversial...
  Prot: I think the way you approached it makes sense. This is the reasonable way, I think, to do it. You have to assume that they have this background knowledge. And if they don't, it's what you said. They don't have to relearn something because they didn't know it to begin with. So they start from a good basis.
  18:30 Focus group?
  Sacha: Is there interest in having some kind of focus group or something like that so that if we come across newbies, we can say, hey, you know, the developers would like to be able to float some questions once in a while to see what actual newbies would think of this?
  Philip: I have actually tried this once. I was in a hacker... what's it called? There's this computer club in Germany and they have local events on a regular basis and I was going to one anyway because a few friends of mine were going there and then I did an introduction to Emacs course there and printed out a survey basically, a questionnaire for Emacs neophytes. I think if you search for that string on the Emacs development list, you're going to find that. And I gave a few people these texts. I printed it out. It was actually pieces of paper, so it wouldn't be personally identified. There wouldn't be any information there. And one of the things I thought was interesting in the results was that the main thing people were saying was it's overwhelming. Like the amount of things... Just the default Emacs. No configuration, no options, no auto-completion, no fido, whatever. It was just so many new things, so many differences that they lost an overview, basically. This was a group of people who, I think there were questions, and they were like, how long have you been using computers? Because, of course, it was so generic. What previous UIs have you had experience with? Most people use Eclipse or Vi, NeoVim and even reasonably complex Vim configurations. Of course, this is a bias due to the setting in which I was asking these questions. I'm actually planning to repeat this experiment because I'm going to another one of these congresses or these meetups in a month or so. I wanted to offer this again to people, specifically seeing if these newcomer presets are valuable or if they help people or not. But of course, doing this in a properly scientific setting would be much more difficult. Yeah, of course. We need money. Difficult steps of doing this.
  Sacha: Maybe even like a mailing list. We can say, hey, you know, you're new to Emacs, but you kind of want to make it better. Email this person. And every so often when developers have a question, they can say like, does this make sense to you? Here's a screenshot. Or would you prefer this versus this?
  Philip: As in, we would send an email to all the people, but then I think, I mean, the big question, difficulty in that sense is then data protection, I think. That's what I was trying to avoid with having this just printed out and no personal identification, because then we have to store email addresses.
  Sacha: Okay, all right. That's fine. That's fair.
  Philip: So, sounds like an excuse. Partially it is, but something like, I mean... I'm not saying that my approach, what I was doing was unbiased. There are people who would be more willing to answer these things and people who are less willing. I know the bias in this case because I actually saw the people and I had a feeling for what kind of people they were. So I think I'm in a better position to factor it out. But if it's actually properly, if you just have people who you send emails to
  22:15 Emacs survey before
  Philip: I'm not sure if it remains represented because there have been these Emacs surveys in the past. I remember at least two generations. And they're of course the ones which are circulated on Reddit, on Hacker News, on IRC, which I still think is a bubble of maybe 200 people. Like mainly 200 people and some people who are Surrounding these groups. So I'm always sort of dubious because these are the people.
  22:48 people's backgrounds influence their responses
  Philip: I mean, these are people who are much more likely to have heard of, what's it called, Evil Mode or something like that, or had some experience with other editors. And these things all influence their responses. always taints the results. Every time these discussions are brought up on Emacs devel, people have some level of doubts as to how reliable the results are.
  Prot: Correct, correct. It's hard to get reliable results, though some data is still better than nothing. But granted, you don't want to base decisions on those results, of course not.
  Philip: Yeah, that shouldn't be the last decision-making factor. You should just have a function where the input is whatever the data is, and then the output is mechanically determined by that. Yes?
  23:46 Hypothetical: Reset themes, to reset things back to the defaults of a specific Emacs version
  Philip: Now, related to the preset theme, there's also been a discussion (I don't think this has been mentioned much online) of so-called reset themes. I'm not sure if you've heard of these. So the idea would be, additionally to having preset themes of options, which we have changed, which we would recommend because the newcomer preset theme makes no real assumption that the options will be stable, so we might change them from version to version, this gives us some flexibility to say we have a new option. Like, for example, if the preset theme had existed since Emacs 29, and now in Emacs...
  24:22 package-autosuggest-mode suggests based on file extension
  Philip: That was actually the reason this entire discussion started when Emacs 31, that's the current release... to be released, there's this package-autosuggest-mode so that's a little prompt, when it's enabled, a little prompt in the mode line. You can click on it, Emacs installs the package which it believes to be the right one for the current file.
  Prot: The major mode, right?
  Philip: No, it's a minor mode. It's a global minor mode.
  Prot: No, no, I mean, but it installs based on the major mode, right?
  Philip: Ah, yes, yes, yes. It installs a major mode package, which matches the current file format being used based on auto-mode-alist or the magic, what's it called, magic file alist and all these things, and it can... We didn't want to enable this by default, but we wanted to enable it for newcomers. That was actually the first option in the newcomers preset. If the preset had been older, we would have still wanted to add this to the preset theme. It's not supposed to be set in stone. Now the idea with the reset theme is, and this is still hypothetical since we haven't implemented it, is to have reset themes for specific Emacs versions. So we, in Emacs 32, we might have an Emacs 31 reset theme for all the options that we have changed in Emacs 31, in Emacs 32, so that we could reset them to the previous option. So that in this sense too, if the discussion, if the question is really just, we don't want to annoy people who have... When upgrading, of course, it's still a minor inconvenience because they have to write load-theme emacs31-reset in their configuration, but it would be easier for them to actually undo any changes. And in future versions of Emacs, hopefully also persist these changes so that you can really sort of like pinning your version of Emacs, a soft pinning of options. So this is something for the future. Consider as well, which would be reusing the theme approach, which is another reason why I hope that the notion of user option themes will become more, because it's been there from the beginning. The Customize system has always supported user options to be added, but people have always only customized, not only... I'm not sure no one has ever done it, but it has not been a popular approach to use the user options, even though the technical facilities have been there all the time. That's also going to be interesting if the reset theme would be forwards compatible. But that's another discussion that makes it even more complicated. So that you could add them hypothetically to ELPA as a core package.
  Prot: Nice. Yeah. Of course, the reset themes, if you implement them, that's great because it opens up the possibility to be a little bit more ambitious with the defaults and break.
  Philip: Yeah. Because that's exactly... Every core... Every default discussion boils down to: if we break this, people won't understand what changed. If we change this, people won't understand what broke. But on the other side, people like all new... Can we reasonably assume that all new people would actually want this theme? Then we want to give us some sort of more flexibility in this sense without actually the support, because I think that the value proposition of having a stable interface where you can expect the appearance of the theme to be somewhat stable over time, how Emacs behaves, that's actually a positive thing.
  27:52 Emacs 32: bundled versions of Emacs (Big Emacs - distributions that include more packages)
  Philip: And finally, in Emacs 32, this is also a finally. For now, one thing I just thought of, which I was reminded of, there's a big plan for Emacs 31. This is one of, I've never pronounced his name, Sean Whitton, I think it should be pronounced. He said that one of his plans as a maintainer will be to work on the bundled version of Emacs, which some people, including myself, have been calling Fat Emacs. So adding, selecting certain packages from ELPA, from GNU ELPA, and bundle a secondary distribution of Emacs which would include additional packages, Which are currently, so for example, one example would be org-tex. And then you could, when you install Emacs, you could install, I don't know, big or fat or whatever... Big Emacs with all these packages pre-installed, which would be pinned to the right version which we would have hopefully ensured that they're actually compatible with one another. And then you have the normal Emacs, which would be the thinner one. And an interesting corollary of all of this would also be that if the way from ELPA into the core would be made easier, that the way out of the core into ELPA would also be made easier. Because that would mean it's more easier to deprecate packages over time since you can install it. This protective layer, let's say, protective layer, protected merely by inconvenience and the annoyance of moving these packages in and out, would fade away over time. Some cruft within Emacs itself, within core Emacs, could be moved to ELPA. So we could actually thin down Emacs. That's one possibility. Oh, that's big. Yeah. One strand of commentary in that direction. That's something that I'm planning to help in the Emacs 32 development cycle. Because these options then could also be in... Any options related to this could also be added to the newcomers preset theme.
  29:54 Selection versus multiple completion
  Philip: So one could of course... Vertico or these interactive selection packages... I think I've commented that before there is a certain controversy there. I think that there's a certain controversy that selection is not always the same as text expansion, which is sometimes like... There are, I think, the certain... skeleton, or there's this insert... what's it called, auto-insert command... It's not auto-insert, something like that, that prompts the user for multiple things, but it's not written using [completing-read-multiple], but it's written in a way that there's a manual loop, which waits for an empty input to occur. But if you're using vertico or fido, by default, if you just press RET, you don't actually have an empty input. You just select the default option. There's settings like these which where these sort of these two kinds of completion diverge from one another which which is also something I've been talking about for a few years but never came around to implementing that there should be an API distinction between actually selecting user options from a list and the completion interface which we have for files or commands currently. These are semantically two different things, which would be interesting to see if it would be worth distinguishing the two in a technical sense, because that would mean that in certain settings, we could enable Fido. I totally admit that Fido and Vertico have their advantages when it comes to discoverability over standard text completion. The compromise now was that in Emacs 31 there's this option, I think it's eager completion updating or something. It's a combination, it's a permutation of these words in some sense. So that's if the completions buffer pops up. No, you don't have to... It doesn't matter. You don't have to visualize it. Yeah, where they update as you type. Updates as you type, yeah. But that doesn't occur down there, but it only occurs in the completions buffer. That's sort of a compromise. That's Fido, right?
  Prot: But the generic completions has had a lot of improvements over the last few years. And in Emacs 31, it's in a very good state, all things considered.
  Philip: Which was also partially driven by your MCT package?
  Prot: MCT, yeah. Which was an experiment, of course. But yeah, it's basically that idea. Because I have used this in earnest, like the default like this, I have used it for a long time in earnest, like just defaults. It's very good. It's for sure very good. Whereas Fido and Vertico are better if you are just getting started and you don't know that there is a completion on the mini buffer and somehow there is a distinction between the two. Like, for somebody who is getting started especially, I think this interface is not good. But if you know what you are doing, I think this interface actually works perfectly. And it has a lot of options. So, Sacha, what you are showing there is the absolute default, but it has so many options that you can make it look actually quite different from this and very similar to Vertico, for example, in terms of the user experience. I just realized that...
  Sacha: Oh, I just realized that if you do the TAB TAB, if you do the TAB TAB, it now goes to that one, which is great, but you can't filter it from there. You can't type into it and have stuff happen.
  Philip: Yeah, it's not down there. If you're down there in the mini-buffer, you type. There you have just a regular text buffer, so you can search or you can select stuff out of there.
  Prot: And that's also an option, by the way. So what happens on the second tab, for example, so you can configure that.
  Sacha: Right, so that was the second tab behavior from newcomer-presets.
  Philip: That's the option I proposed and then objected to.
  Sacha: Yes, work in progress. So basically, you have these newcomers. We're trying to figure out how to get them through their learning journey. The newcomer presets can smooth over some of the edges. It can get over that "Yes, there are a lot of options, but at least M-x with tab completion will show you the things so that you don't have to memorize the names as much." You can recognize them from the list. You can narrow it down.
  Philip: The behavior is supposed to actually be similar to Bash, the way Bash does completion.
  34:39 Manuals
  Sacha: It's probably still... we're going to need them to read the tutorial, and we're going to need them to use a lot of patience as they get used to Emacs. I am not quite sure yet if we can get them all the way to, all right, here's how you open your config file and define your own keyboard shortcuts, for example. Bit of a journey.
  35:08 More examples?
  Prot: I think that one way to do that is to have more examples in the manual. Like, here is how you do this, here is how you do that.
  Philip: Or there's this other manual, the Emacs FAQ.
  Prot: I don't mind where it would be, like FAQ is totally fine. I don't mind exactly where it would be, but somewhere in the documentation, like common patterns of Emacs configuration kind of thing. Maybe it already exists, so if it exists, then of course even better.
  Philip: Emacs FAQ has some things on finding related packages, common requsts, bug reports, but maybe it was... I remember there's something. If I link to it...
  Prot: Where is the FAQ?
  Philip: It's a separate manual.
  Sacha: We do not have it from here, not from the splash screen, but it is available from the Help menu.
  Philip: I think it's not been that thoroughly maintained.
  36:22 find-user-init-file?
  Sacha: I'm going to take advantage of the fact that you've actually been reading emacs-devel. Has there already been a long discussion about whether a M-x visit-user-init-file makes sense? An interactive command that you can use to open... I was trying to find it, but even with Yhetil's search, I was like, okay, there are four threads. One of them was a long time ago, and the other one was from even longer than that, so I didn't know whether it was some other discussion.
  Philip: I don't recall any such discussion recently, but I also don't think that anybody Objection to it. So it's really just a matter of someone writing it down and adding the documentation.
  Sacha: I would like to do that.
  Philip: It would be quite likely 24 hours.
  Sacha: Okay.
  Philip: On the master branch and not Emacs 31 branch, which would be slightly... It's fine. Yeah, but even having a button...
  Sacha: If it makes it in someday, it doesn't have to be in the splash screen. It just has to start off being available through... And then we don't have to keep telling people, oh yeah, do a describe-variable on the init file just in case your init file is actually .emacs instead of the .emacs.d/init.el that other people are telling you to use instead. It's a bit of a mess, right?
  Philip: I think some people have been recommending doing M-: and then calling the [find-file] function with the user init... What's the name of the variable again?
  Sacha: user-init-file.
  Prot: User Emacs file.
  Sacha: Here we go. user-init-file. Here we go. That's the thing. Yeah, exactly.
  Philip: And if you do M-: (find-file user-init-file), then it would basically do the same thing. That's why I'm saying it's such a minor function that I don't expect any objections.
  Sacha: Okay, okay. So I'm going to suggest that to Emacs Devel at some point.
  Philip: I've had the same idea many times myself, but the transience of memory has thrown its way before I actually ended up doing it.
  38:38 Getting over the reverence for Emacs's history
  Sacha: Sometimes I am reluctant to suggest things because I figure Emacs is such a long history. Probably someone has thought of this already, and it's probably been discussed and bike-shedded. But I think there are little things that we can do.
  Philip: Yeah, but then in that case, Yeah, but I think that's actually related to another thing I wanted to talk about. There's a certain sort of reverence that people have for Emacs, because it's such a historical project. But I mean, the preset theme was something that was discussed for many times, and there were basically no objections. No one said, no, we shouldn't do this, this is a bad idea. I hope it's not only because I proposed it or something, or like the package also suggests that. Most of the things I've been working on for Emacs 31, no one objected to. And there's two sides to this. There's some people who actually go overboard with this and try and reinvent. Like when reviewing packages, you see this a lot of people try and reinvent functionality, which is basically just giving a new name Combining two things and giving it a new name which isn't always necessary but might be useful and then it's some discussion like can we actually make more out of this and that's a different thing but then there's the people who I probably lean more towards that side when I think to myself the way I'm doing this is stupid or this is not as efficient people have been using Emacs for 40 years of course there probably has to be a better way to do this
  40:11 Changes are more likely to happen when someone puts in the work to make a patch
  Philip: And sometimes it turns out it simply hasn't been implemented and no one has simply done this actually small effort of preparing a patch and ironing out the details just some people don't like discussions of course and it's understandable but you can I mean there's really no harm in sending a patch and then saying I'm sorry I don't have It's annoying, of course, from a maintainer's perspective. I don't recommend doing it, because if you prepare a patch but don't have the time to finish it up, then if it's a useful thing and you actually get someone to be interested in maintaining it, then bringing the patch to completion, then it's well worth just sending a feature. Even sending a feature request, you don't even have to... I mentioned the idea of this preset theme many times. I wish people would be more conscious of this mentality, but I totally understand people who think otherwise, because when the first time I sent a patch to a mailing list, I was, I don't want to say I was sweaty, but I was really nervous because I don't know what if they insult me or they say, "you fool, you didn't format the test properly, [??] secret handshake you have to do every time you send a patch. Begone." Whatever. Which is of course not the case. Which is not to say that there are no unpleasant people on mailing lists but I think that there is especially the GNU Kind Communication Guidelines, which are supposed to give some sort of goodwill, good faith, attention to how people should behave on mailing lists, how they should treat each other. Lots of these preconceptions turn out to be false in there. That's why I also wanted to participate in this, so that people see, oh, the people maintaining Emacs aren't wizards locked up in a tower, but just, I hope, normal people who happen to spend more time with Emacs.
  Prot: Yeah, that's a very good point.
  Philip: Which is why they're valuable, these discussions.
  Prot: And I think, Philip, just to add to this, your example of leading with a patch, I think, is also key here for someone who can write a patch, of course, because it cuts out a lot of that noise, that initial discussion of, well, maybe yes, maybe no, because it frames minds. It focuses the attention on something concrete. And that can also... Yeah.
  Philip: Yeah. And... I mean, having a patch is useful, but getting someone interested is also helpful. Like the discussion when we merged which-key, I helped with that process. And I'm not, I think it was, I don't remember his last name, Jeremy, who actually did most of the work. And I was reviewing his patches. I was helping along, but I wasn't actually writing most of the code. I was just going over the proposals and helping along and basically pushing the... Stunning the process whenever it got stuck so that we actually made the necessary changes for it to get merged.
  44:03 Preserving Git history of packages absorbed into the core
  Philip: And then I did the last finishing touches of merging, because that was also something... Every time... We'd like to preserve the Git history of packages we merge upstream, which is probably something we won't be doing in that way when we do the Fat Emacs releases. But the entire history of Eglot and the entire history of which-key is actually preserved in the Emacs Git repository. So if you open the file, you have, it's not anymore a tree in a computer science sense, but it's actually a proper DAG, because suddenly you have multiple roots of the project which come together with the history preserved. And that's an annoying thing to do with Git, but you can do it. And not everyone knows how to do it, but a few people have the commands written down somewhere or look it up on a mailing list, as I do. Then that goes through, but that's...
  Prot: So they are wizards after all.
  Philip: Wizards just reading pre-written down spells.
  Sacha: It'll be interesting to see if some of the starter kits move to using that kind of fat Emacs infrastructure once that's in place. Because a lot of times the starter kits are there to package together. Okay, here's a list of the packages that it uses. Here's the configuration that makes them play nice together. And then here's some kind of Documentation or videos or a demonstration on how to use it to help people get started.
  Philip: So I'm curious to see, I mean, I went reviewing the options to add to the preset theme. I actually went through a number of these starter kits to see the options they suggested. Selected those out which seemed reasonable to me. And of course, this was discussed and people objected or added other things. But I am curious to see how the starter kits will evolve in the future, because that's also something we should mention.
  46:00 Dealing with multiple types of Emacs
  Philip: I mean, there is a big problem with the fat Emacs approach and suddenly you have two versions of Emacs. You can write a package which appears to work fine in fat Emacs, but it depends on a package which is not in the core Emacs release, and then that's something we will have to deal with in the future as well. Yeah, that's a tricky part indeed. Yeah, but another thing relating... Yeah, the sort of fragmentation of what core Emacs is. It might be a showstopper, so maybe everything I'm telling here is just a wishlist. It doesn't end up actualizing. And that fragmentation of the setup is one of the things... Because it's not actually really difficult to solve. I mean, if you have a package that depends on something from Fat Emacs who just added to the package requires lines, you explicitly state the dependency. But if people are sloppy, then they might not notice this immediately. And you have runtime issues when people are slow.
  Sacha: It's a little bit more than that, right? So for example, if you have a newbie asking a question, because they're using a starter kit or in the future, a fat Emacs thing with different packages installed and different configuration things that they have not personally set up. And they don't have the experience to know, oh yeah, this is going to be related to that. So I should mention it in the help message. I mean, large starter communities like, like Doom Emacs and Spacemacs will have their own Discord or mailing list where people can go and ask for help. And so people will say, okay, I think I kind of know which starting point you're coming from because it's the base. But if we're, you know, with the smaller starter kits, they don't even know how to ask for help. And everyone is like, on the regular Emacs communities, there's a lot of back and forth if you want to dig into, okay, what do you have enabled? What is affecting your setup? Fat Emacs is going to run into that problem.
  48:09 Fat Emacs is just about bundling more packages from ELPA, not changing the configuration for them
  Philip: To be fair, my understanding currently is that it wouldn't enable any other options. It would just bundle more packages.
  Sacha: I see.
  Prot: So it would be more of an issue for package authors.
  Philip: Yeah, for package options. The idea is, I mean, I've used Emacs in offline settings where it's like, really inconvenient or impossible to install additional packages, and just having more functionality out of the box which ELPA provides and you don't have to install additionally, is basically the idea. Because this has been a project which has been ongoing for years. I think this is ever since the conception of ELPA itself, which is precisely the reason why GNU ELPA requires all packages to be signed or to be covered by the copyright assignments, while NonGNU ELPA does not: so that this is possible. It's just that finally it looks like we're starting to move somewhere in that direction. It would be interesting if a decision were to be made that we're going to give up on this sort of bundling, what decisions that were made for the legal status of GNU ELPA, if we would merge GNU ELPA and NonGNU ELPA together, which is unlikely currently. This is just pure speculation at this point, but it's something that might be a discussion, which will be had in the future.
  Sacha: Okay, so it dispenses with a package install part, and so people don't have to worry about, okay, how do I make sure The package archives are set up, and how do I install the packages? All that stuff will be pre-installed. The auto-mode-alist will be... Oh, sorry, go ahead.
  Philip: The package archives wouldn't matter that much, since we are just talking about the GNU ELPA packages, which are installed by default. It's really just that you don't have to install additional packages. You don't need a network connection. You don't need to know about the package existence. It would be registered in the auto-mode-alist anyway. So if you open a, I don't know, what's the package, some major mode that's not going to open, which is not in the core.
  Prot: I think you might [??] earlier. I think that would qualify. I think you mentioned auctex earlier, which is on ELPA, but not in Core.
  Philip: The tricky thing there is that Emacs already has a LaTeX mode by default, and that already applies, but auctex extends it. That's why I was looking for another example. Okay, that's the idea, but it wouldn't only be major modes, I assume. There's going to be some discussion as to what packages we want to add. Currently, it's not certain. Because we're working on finishing up Emacs 31. That's where most of the bug fixing efforts are going in right now before we progress to any further developments. But that also includes proposals. That includes proposals as to the preset theme, which I am still interested in reading.
  51:23 Customize
  Sacha: I want to come back to something Prot mentioned in my conversation with him about newcomers, and that is the Customize interface versus getting people to the Emacs Lisp directly. And I think, Prot, you were not very keen on Customize.
  Prot: Yeah, basically if I say it in one sentence is: I think the earlier they get into Emacs Lisp, like seeing it and interacting with it, the better it is for them long term. Granted, I am making the assumption that this is a user that will be there long term, right?
  Philip: Of course. And this is specifically about the Customize UI, right?
  Prot: Yeah, yeah, not the underlying functionality, like, yeah.
  Sacha: It's great for simple options like, yes, we can check the checkbox, or we can select from the drop-down list or whatever, but browsing it is, as you mentioned, overwhelming in the general sense of Emacs being overwhelming, and when you start wanting to do something slightly more sophisticated like you know, let's add some more capture templates, then it's challenging for people to do. So I'm wondering whether, in general, we should be... Is our general strategy to be guiding people to, yes, Customize is there, but really you want to be doing Emacs Lisp as quickly as possible. Let's make it easier for you to get your init file. Let's make it easier for you to test your init file and not fall apart when you miss a parenthesis and all, things like that. Do we want to guide people that way?
  Philip: One question I think we should distinguish is the idea of a UI the problem or is it really... Because I personally I have a new Emacs configuration at my day job, and I do everything using Customize. I don't even care about using use-package or whatever. Just customize the stuff using... There's a big blob of user options which I've modified, and that goes through, and I don't care about it, but I claim to have some understanding of what's going on, and the rest of the function is just some defuns which I find convenient. But for me, it's okay, because I have some sort of intuition of how the Customize UI works. If there were a better UI for Customize, would you still say that if it were written in an intuitive way, say using Fido modes. So that's, it would use interactive narrowing and it would somehow work in a build on existing intuitions because the current Customize, the Customize UI, the easy customization interface I think is a technical term to use is based around this widget library interface and sort of make replicating a TUI menu but not... And then you have to... And yeah, of course, the intuition... Like, if you click on things, it doesn't always behave the same thing you would expect from a regular settings menu, which is by the way also something that CUA specifies.
  54:41 CUA - Common User Access
  Philip: I recently looked into what CUA lists. Like, if you look at the Wikipedia page, CUA specifies that every application has to have these settings menu with tabs on the bottom on the top where it lists all the options you can specify and interestingly C-c and C-v is not listed as...
  55:00 ini file format? https://sdf.org/~pkal//blog/emacs/ini-init.html
  Philip: Apparently not CUA, but Shift Insert and Control Insert... I might be misunderstanding this, but this seems to be a misnomer.
  55:10 Emacs configuration generator
  Philip: But if we had some sort of a UI like this CUA configuration UI, would that be something where you'd say as an intermediate stage for just setting options? Because that was part of my thought process with Emacs Configuration Generator. Just configuring Emacs is such a subset of Lisp as it's actually not programming Lisp. You can easily get by by just using add-hook, set up or setq, and add to list or stuff like that. But you don't really have to understand. It's just a peculiar syntax for how to program Lisp.
  55:54 INI-style configuration
  Philip: I'm not sure if either of you have seen, I wrote a blog post last March, no, not March, what's the name of the month? November, October or something, where I gave a prototype for a INI-like configuration syntax.
  Prot: I must have read it, but I don't remember it. You must have read it. Yeah, yeah, yeah, because I always read my feeds, but now it doesn't ring a bell.
  Philip: Exactly. You see there's this basically a simplified syntax, which should be... The idea was it should follow a conventional configuration-like format, and each of these lines gets translated directly to an Emacs Lisp expression. And due to this, I don't want to call it an isomorphism, but the easy translation in both directions, I think that the expectation of saying write Emacs Lisp... There has to be some defun or something if you're writing Emacs Lisp. That's to exaggerate. If you're just writing setq, set, add-hook, add-to-list, these common configuration patterns, which are well worth documenting in the manual, to understand what are the patterns that you have to use to configure a package, even understanding the signature... The distinction between add-to-list and add-hook is that hooks are lists which can have mode-local extensions but also inherit from global settings. Not obvious from the beginning to everyone. This is not list programming.
  Prot: Yeah, fair enough. Though even then, they start to see the parentheses, get used to the syntax. They have to remember to quote stuff. Even though it's not really programming, I see what you're saying. They put themselves in the situation.
  Philip: One of the ideas precisely in the config syntax is that if you have an option like set, you see the first line, set mode line compact long. Long is a symbol. I just use regular read to read this, and it's not evaluated. There's an option down there somewhere, I think, eval set, where the format expression is an S expression that's evaluated to a string. So you have to opt into evaluation. which seems more intuitive to me for a regular configuration when you're writing it, because all these things... Like, I have to think about quoting. Then there's the issue like with with-eval-after-load... Can I customize this variable before the package is loaded, after the package is loaded? If it has, like... If you're adding something to a list and the list has a default value that you don't want to set the value of the default, don't want to add it to the list because then it's not loaded, and it could trigger a undefined variable signal. So these are other inconveniences that I don't, I personally do not see any value in teaching people or having people to deal with these sorts of issues before they have any broader intuition. Which is a very idiosyncratic take perhaps, but...
  Prot: No, no, it's fair.
  Philip: What I'm trying to get at is this sort of any configuration syntax would be something that a UI could generate a lot easier and in a way that wouldn't have this artificial split between your own personal handcrafted configuration and the generated part of the configuration. Mechanically changing this, finding the section package avy, because it has all of these primitives which didn't exist early on in Emacs, like packages and features exist and so on. The sort of structure which use-package usually provides.
  Sacha: I have about one minute before the kiddo starts on lunch break, so I'm going to interrupt a little bit and do a quick summary. But the two of you are welcome to keep hanging out and chatting. I'll leave the Big Blue Button room open. And if you want, I can set it up so people can join you, depending on your time, et cetera, et cetera.
  1:00:21 Quick summary
  Sacha: But basically, what I'm getting for a quick summary of the conversation: Emacs 31: the newcomer presets is work in progress. People are definitely open to improvements, ideas, other suggestions for other features. The kiddo is just running out now. I will put the chat in the thing.
  Prot: Yeah, of course, of course. That's fun. So, what's happened?
  Sacha: Do you want me to open up the chat to everybody? Or do you have other things?
  Prot: Me, I can stay for another 20 minutes. Just to say I can stay for another 20 minutes because then I have to take the dog.
  Sacha: Yeah, and Phil? Oh, you have to leave.
  Philip: 20 minutes is fine. 20 minutes is fine for me as well.
  Sacha: Okay, okay. I will put the thing in the chat and people can continue because the kiddo was like, ah! Okay, yes.
  Prot: Okay, okay, okay. Good. So, yeah, of course, there is a chat going. Yeah, let's see. So, Sacha, you will link it there. Ah, nice.
  Philip: So, I presume there has been an idea of people watching this.
  Prot: So this is live.
  Sacha: And I can copy the chat thus far since we didn't even get to any other questions. Hang on a second. Where am I even?
  Prot: We're trying to deal with those, right? Yeah, yeah, yeah. Well, eventually to have a discussion and also take questions, eventually you need to have more time, I guess.
  Sacha: Yeah, yeah. But thank you all so much.
  Prot: Yeah, yeah, yeah. That's good. Yeah, yeah. Thank you, Sacha. Thank you very much. And of course, the kiddo overrides all.
  1:02:27 Continuing with INI
  Prot: That thing with the INI, I think it's very promising. I mean, if you flesh that out. Because the other thing is, yeah, with the INI configuration, because what would be, though, the fate of what is now added, you know, when you modify something and it adds this, you know, this has been set by Custom, do not touch it kind of thing. You know what I'm talking about, right?
  Philip: Yeah, you mean the generated user glob. Well, my idea, or if I were, if I had the time /motivation/whatever to flesh this out, because currently it works... Currently it's an actually existing Elisp file which you could use, but I think it would be most interesting if it would be upstreamed. It would sort of be like, if you don't have a .el file, Emacs would look for it .ini file, or emacs.ini file or something like that. Then, of course, you can check, like, does the INI file exist or does the .el file exist? Probably there would be a user option to select into which it would inject the new options. And by default, it would select, for example, if the INI file exists, then it would use the INI file. But there is some controversy to this, because I totally understand the sentiment we're coming from with... You're using Emacs, so you have to learn Lisp. But for me, the bar is a bit higher than just the inconvenience of writing out this more or less. It's, as Joel Sussman referred to it, this ritualistic Lisp. You always have to repeat the same stuff all over again, like with eval, afterload, set. add-to-list, then you have to quote the option in one case. And if you change something in a map, then you don't have to add it. And of course, if you know Lisp, then you know that in one case, a keymap is a cons cell, so you're actually modifying the rest of the cons cell. That's why you don't need to quote it. But in the other case, you're accessing it via symbols, so you need to quote it. But this is all technical details. There's no necessity in it. It doesn't have to be that way.
  Prot: Yeah, yeah, yeah, that's fair, that's fair, of course.
  1:04:42 Motivation
  Philip: One thing I wanted to bring up in the discussion when we were talking about reverence was there is, I mean, one part of the thing that gave me the motivation to go through with learning Emacs, even though I didn't use the tutorial initially, was sort of a reputation I heard about Emacs. And the videos I saw, wow, you can do these cool things. And this motivation, this image I had of Emacs help me go through, but if you overshoot this approach, then people expect too much in the beginning and are disappointed in the end and don't pull through. There's this question of having, how's it called, the ??... How to motivate people enough to be interested in Emacs, to actually learn it, but not to oversell it. If you give some sort of a demo of using Emacs, which is simply not representative of how it actually works, then that's something which would backfire. But I guess we can take a look at the questions, right? Yeah, let's see. Let's see.
  Prot: Yeah, yeah, yeah. So yeah, I didn't read them. I had the chat open, but I didn't have the time to read them. Sorry? I'm not sure how to parse these. Is this from top to bottom? I guess from top to bottom is how they arrived in the chat. The top is the earliest.
  Philip: The usernames are mentioned below.
  Prot: I guess that's a copy-paste thing. Yeah, yeah, yeah. So there are some...
  Sacha: I gave the kiddo some packed lunch, so I'm back.
  Prot: Oh, hello there!
  Philip: We were just wondering about how to read the comments you posted. Maybe you have a better UI.
  Sacha: I pasted them into the chat. So in the Big Blue Button...
  Philip: But that's the order of occurrence?
  Sacha: That's order of occurrence. It's totally not very... It's just like a big paste.
  1:06:50 Politics and philosophy
  Prot: While you read it, let me... Yeah, there is a comment there from LC2000 about the splash screen having a lot of emphasis on the legal side, which is a fair comment. I think the legal side is important though, because of course, free software and all that, but of course, it could be rearranged. So maybe you don't want to have it at the top front and center, you want to have it further down. Maybe. I don't know. I don't have a strong opinion, but I think the legal side is it should be there at some point. I feel like it's a political minefield though.
  Sacha: Just leave that alone. Otherwise: 200 comments on emacs-devel, one of those really long threads.
  Philip: I cannot under-emphasize how surprised I was when my suggestion to add a checkbox on the splash screen just went through. Because I expected people to object, no, we can't add it there because of some system. It wouldn't look the way it should look and that would be confusing or whatever. But apparently change is possible. You have to be careful and be patient.
  Prot: And I guess here there is an assumption, right? There is also an assumption that people will attack you or be unreasonable. And I think this is not true. You mentioned it earlier as well. Eventually you have to get on the mailing list because people, if they don't hear the opinion, the counterpoint, they will never know what to do with it.
  Philip: But it's not entirely unreasonable because there are discussions that can be... There are people on emacs-devel, it's sad to admit it, but there are people who voice strong opinions, like strong opinions, with no power behind them, which can scare people away because there's no... There are no tags. There's no index of people on emacs-devel, so you don't know if some John Doe responding to your message, if he's actually responsible for this and makes a decision, or if it's if Eli is sending a message and his decision on the discussion actually weighs a lot more than other matters.
  1:09:23 Experimenting with things outside core
  Sacha: I feel like sometimes experimenting with newbie-focused resources, like the unofficial ones that are around... At least we can try the ideas out and then say, hey, here's the patch and also here's what people have been using it for, so you can see it a bit more concretely, than dropping an idea into the discussion and then having the whole bike-shedding happening without as much data.
  Philip: That's seriously my main recommendation. If you want to propose something, add a prototype, add a patch, add something to narrow down the discussion. That's something people would take away from this discussion, from my experience.
  Prot: I 100% agree. I think that's the way to go. Just implement something so that it focuses the attention. Otherwise, you will get those endless discussions very quickly.
  Sacha: Or try it as a package first, and then it can be core.
  Philip: Excuse me?
  Sacha: Oh, I was thinking if it's possible to prototype something as a package, now that Emacs has made it a lot easier for people to install packages, then at least it can be tested before having all the conversations about whether it should be as part of core or part of the splash screen or everything else.
  1:10:42 Extending the core
  Philip: The counter tendency I feel obliged to mention is that many times proposing something as a package or as an extension to the core can actually simplify the implementation vastly. Especially if you need to make one or two twists upstream and you need something like an additional hook or something to exist upstream. If it's a package in the core, then it's a lot easier to explain why you have to make this change than having to deal with some sort of advice and changing a lot of things. There was a certain tendency during the mid-2010s, which I only know from history, was to re-implement a lot of stuff in logs, in packages, instead of working on them upstream. That created a lot of divergence between packages, and in my opinion, complicated things because it introduces this entire choice fatigue. Should I use Flymake? Should I use Flycheck? Should I use LSP mode? Should I use Eglot? Which is not a historically accurate example in the stats that I'm given, But I'm certainly in favor of at least considering upstream contributions.
  1:11:52 Guide to contributing to ELPA
  Philip: Even like packages, of course, it's the way we recently published these guidelines, or not guidelines, this contribution guide to publishing packages on ELPA, which is on, if you want to open it in the browser, it's on the ELPA homepage, which lists sort of these hard criteria which we require from ELPA. Just elpa.gnu.org, yeah, it's... That's going to be a link to the page.
  Sacha: Yeah, this is pretty recent.
  Philip: This is recent, and then there's a list of suggestions. But this is getting off the actual point. I'm just saying that relating to the general point, my experience is that proposing something concrete but also be open to hearing the opinions of other people These are the two necessary but maybe not always sufficient ingredients to making the changing stuff. Because if you just say, I want this to be different but don't put in the work, then everyone's going to forget it. But if you propose something and then insist that it has to be exactly this way, then you're just creating social tension. Maybe missing out on interesting things.
  1:13:11 Making the newcomer experience better
  Sacha: And especially since people are using Emacs for so many different reasons and coming from so many different backgrounds, what you are very firmly committed to might very well work for one set of people, but will run into these issues for all these other people. So if we want to bring it back to this, you know, how do we make the newcomer experience better? It's great that in core, there's starting to be a little bit more infrastructure for supporting things like sets of reasonable defaults for people. And maybe we as a community need to figure out, all right, how do we write documentation around it? How do we make tutorial videos? How do we encapsulate, okay, this is what this typical newcomer experience is like for this set of people and maybe these options or packages or a glue code might be helpful for this group? Maybe.
  Prot: Yeah, like in theory, you can imagine something like, if you are a Python developer, here is your Python presets theme. If you are doing Org or whatever, here is your LaTeX and friends, right, and you could also have extensions like that in the future.
  Philip: I mean nothing about the idea is... It could have been used as a package people can load otherwise.
  1:14:30 "user option themes" versus "appearance themes"
  Philip: And hopefully, as I said, there is certainly additional work which can be put in to support making user option themes better supported. I think one of the things that will be useful is actually referring to them just in nomenclature points as user option themes to distinguish them from.
  Sacha: From themes.
  Prot: From color themes, yeah.
  Philip: Color themes, yeah. We even introduced the distinction that themes have kinds since like Emacs 20.
  Prot: 29, I think.
  Philip: 29.
  Prot: I think you did that, right?
  Philip: I think I worked on a patch. But that was exactly, I mean, that was already where the seeds for the current theme were started, because we wanted to distinguish between these different kinds of things. Were there any other questions?
  Prot: I don't think so.
  1:15:24 find-library
  Prot: But yeah, as we saw now with the find-library that Sacha did in the beginning, it would be nice to also eventually be able to find the theme or whatever. Maybe it's a different find-theme, if for whatever reason it cannot be find-library.
  Philip: That's actually no reason why that shouldn't be the case. I mean, you could just extend the logic to not only consider the load-list, but also the... Whatever the variable is for the list, then it should be able to find that as well, even though it's strictly speaking, that's a library. But that's a decision that someone has to make at some point or convince someone.
  Sacha: I think find-library does work for it. Like, find-library will find it only if it's loaded. And then since I can't, like, undo it...
  Prot: If it's a package...
  Sacha: Yeah, yeah.
  Prot: If you install it as a package, yes.
  Philip: Because then the theme is in a directory which package.el has added to a load list. I think the preset, if my memory serves me correct, then find library only looks through load-path.
  Sacha: I see, I see. And etc/themes is not in the load-path.
  Philip: Exactly. Because these aren't, this is, I don't know why. It's not...
  Sacha: Okay, all right. That's another message to emacs-devel.
  1:16:49 configuration generator in Emacs? maybe more wizards?
  Philip: It's the sort of annoyance which from my perspective is so inconvenient that I forget it every time and then you don't change it.
  1:16:59 Starter kits
  Sacha: @brongulus says the Doom Emacs module approach is very nice for beginners and entices them to get into things more. People interested in a certain common set of functionality can get an opinionated starting point in Emacs, rather than worrying about what to install. And someone else in the previous That's sort of like the theme approach, isn't it? Sort of, yeah. It's not just, hey, these are the packages and you can comment and uncomment lines that load the different modules, but also here's the glue to sort of start to make some of them work better together or to change them to reasonable defaults.
  1:17:39 Configuration generator in Emacs Lisp?
  Sacha: I was wondering, actually, along those lines, any thoughts about making your configuration generator type thing in Emacs?
  Philip: The reason I, in the configuration generator, did not implement it in Emacs was precisely due to if it were in Emacs and would use, for example, something like the widget library and there would be these fine UI discrepancies which people wouldn't expect to behave the way they do, then scrolling doesn't behave exactly the way they expect it to do. But there has been an idea, I think, when I mentioned the configuration generator the first time. It was the notion of having actually a shared file format behind it, just some S expression, which could be loaded by both the configuration generator and a generic configuration wizard, which could also be used like every package could define their own configuration wizard for asking the user selected options and configuring these.
  1:18:40 extending the archive format
  Philip: That's also another thing in Emacs 32 which I plan to work on, to extend the package archive format. Among other things, allowing for multiple packages to be listed in it, because GNU ELPA and NonGNU ELPA both store multiple versions of all packages, but you can only install the most recent one. That's why pinning doesn't work. Absolutely no technical reason why this shouldn't also list other versions as well. And then you could have pinning without having to use Git. Packages as well. And there are a few others. There was a thread I think earlier this year where I collected a number of these extensions for the archive formats which could be extended. And now I forgot my thread. Now I lost my thread of those.
  Prot: But basically extending package.el and the archive, yeah.
  Philip: Specifically the archive, so that...
  Prot: Showing the previous versions which are already listed, like you said.
  Philip: Yeah, so that you could pin the version so you could install the version. I honestly do not remember what I was saying just a few seconds ago, which is embarrassing. Okay, that's another problem.
  Prot: Things happen, no worries.
  Philip: You were talking about Doom Emacs?
  Prot: There was a comment about the Doom Emacs and specifically the fact that there are these modules and you can load the module without thinking specifically about the packages. But then Sacha told you about your package configurator wizard.
  Philip: Package configurator wizard and then extending the metadata could also include this sort of configuration option. So that packages, in some sense, could specify what options the user would primarily be interested in and what order they should be traversed. And you could have some sort of dependency, of course. This is some effort which has to be put in, but it's not something that's unreasonable, from a technical perspective, from implementing this. And it would make, I think, it could make, if you have the infrastructure for that, that would make installing and using packages a lot nicer. It sounds very promising, for sure.
  1:20:56 User interfaces
  Philip: The UI question remains the thing. Do you want to reuse the Customize UI, which has its historical warts? Of course, can they be ironed out? That's a different question. Or do you reinvent something from scratch? And I'm usually not that big of a fan of reinventing the UI. I'm more in the reuse existing interfaces, just into the back end.
  Prot: Plus, if you were to invent a new UI, you wouldn't have this new feature already because you have too many things that you need to implement. Whereas just using custom UI allows you to just implement the feature and then the interface, maybe it's something that somebody else will work on or you work on at the latest.
  Philip: Yeah, but then, of course, that's... Even if that is the case, then you have to make sure that you don't make assumptions that depend on your own customizer in the future. It's a whole list of dependencies which is just complicated.
  Sacha: That sounds like a newcomers presets to un-wartify Customize, a reset theme to put the warts back on as needed, and then we can use the slightly more modern interface for the things that we had wanted to do, maybe two or three years down the line.
  Philip: Maybe something like that. A little long-term planning.
  Prot: I think just to say this, but of course everything we have covered thus far, always we have to state it. Newcomers with an asterisk, right? With the caveat that you still have to put in the work, read the manual, be patient, all that, right?
  Philip: Ideally, it would be nice if you could even start without it. I mean, I started without it, but it took me three or four years to actually write this one. I didn't want to write defun. I thought, what? I don't write my own functions. I just want to set options, which was wrong and appealing to this. That was the point from the beginning. But I think, Sacha, you wanted to close there.
  Sacha: Oh, I just wanted to acknowledge that we are coming up in the 20 minutes that you said you were available for. Yeah, yeah, yeah, I need to go. Yeah, yeah, the dogs and everything.
  Prot: Yeah, yeah, I have to take them for a walk because I have a meeting afterwards.
  Sacha: Right. I wanted to thank both of you. I really like this conversation and the heads up and the interesting things coming down the pipeline. So thank you for that. We're going to continue, I think, working on the user experience for newcomers. which will probably be a mix of documentation and packages and other experiments and occasional email to emacs-devel suggesting things like the find-user-init-file and whatever. But thank you so much to you and to everyone who's tuned in.
  Prot: You're welcome.
  Philip: Thank you for hosting.
  Prot: Thank you.
  Philip: Thank you, Prot, for your comments as well.
  Prot: Take care.
  Philip: Bye-bye.
  Prot: Goodbye, goodbye. Where do we close from here?
  Philip: I'm just going to close the tab. Bye.
  Chat
  
  protesilaos: Hello folks!
  
  MichaelVash7886: hi
  
  protesilaos: We still have a few more minutes. Looking forward to it!
  
  MichaelVash7886: ended up starting on doom and the nice thing is anything I want to try out is either in there or it's a simple tweak away. but it's several layers of abstractions to change certain things
  
  MichaelVash7886: for me to go from using doom to being able to program with a vanilla emacs I know it's going to be a journey to get things like completion, eglot, etc all setup
  
  MichaelVash7886: also looking at moving away from evil to using something like Meow and vanilla emacs binds
  
  lc2000: Speaking of splash screen, there's still plenty of room, why not inline the GPL, and a small essay. Kidding of course, but what of slaying that sacred cow…?
  
  lc2000: (As it stands, it prioritizes ideology, laywer-mandated stuff from before case law, credits, funding via manual ordering… and if new users don't recoil some things they may actually need/want.)
  
  takoverflow: Hello Prot, Sacha and Philip!
  
  takoverflow: Thanks for this discussion
  
  RandCode: greetings, everyone!
  
  RandCode: emacs has a place for chatting in all of irc, matrix, xmpp and telegram room! (also email)
  
  lc2000: Packages are great at bundling functionalities, but Doom/Spacemacs/etc also fix the multi-package integration "glue", which technically could be packages (see all prior "config modules" attempts…).
  
  sachactube: https://bbb.emacsverse.org/rooms/chat…
  
  protesilaos: Come join us :)
  
  lc2000: Probably best to talk of modern de facto "standards" (vs full CUA as then-defined), e.g. if there's a "region" new users expect C-c (or C-c C-c in anger) to work, and idem C-x/etc - easy wins maybe.
  
  brongulus: I do prefer the idosyncracies of with-eval-after-load and actually explicitly binding and creating hooks, rather than relying on use-package is that it tells me explicitly the order in which things would be evaluated. In contrast to use-package where I would have to know about defer and how to properly define the order of loading of different packages.
  
  Protesilaos: @brongulus Fair point! I also like it. The thing with use-package is that you understand it better if you know what it does under the hood.
  
  brongulus: This is where the doom emacs' module approach is very nice for beginners and entices them https://github.com/doomemacs/doomemacs/blob/master/modules/README.org
  
  brongulus: People interested in a certain common set of functionality can get an opinionated starting point in emacs rather than worrying about what to install
  
  brongulus: This is how it looks https://github.com/doomemacs/doomemacs/blob/master/static/init.example.el
  
  brongulus: Thank you for the meeting o.
  Some types of new users to think about
  
  Non-programmer interested in using Org Mode for notes and task management
  
  Researcher interested in publishing, reproducible research, literate programming
  
  Programmer interested in coding with Emacs
  
  Coming from VSCode
  
  Coming from Vi
  
  Programmer still using a different IDE, just interested in Magit
  
  Long-time Emacs user who hasn't explored Emacs Lisp
  Sketching out their learning journey
  
  Install Emacs
  
  Use Emacs via the menu bar and toolbar
  
  Get a little overwhelmed
  
  Use M-x to call commands by name
  
  Learn how to set up completion
  
  Use some keyboard shortcuts
  
  Figure out how to learn and connect
  
  Customize some options
  
  …
  
  Eureka!
  
  Define their own keyboard shortcuts
  
  Challenge: init file
  
  …
  
  Define their own functions
  
  Challenge: Emacs Lisp
  Other notes
  
  Learning how to modify Emacs with Emacs Lisp can help people really appreciate its power. For example, you need Emacs Lisp to set your own keyboard shortcuts. You can't set them through the Options menu or the M-x customize interface. One challenge is that the Emacs Lisp configuration file that is loaded at the start of every Emacs session might be in one of several places, which means that in order for newbies to understand how to add something like:
  
  (bind-key "C-c r" 'org-capture)
  
  we need to either include a link to something like EmacsWiki: Init File, or repeat the instructions and the troubleshooting steps in beginner tutorials.
  
  user-init-file defaults to .emacs for new users if none of ~/.emacs, ~/.emacs.el, ~/.emacs.d/init.el, and ~/.config/emacs/init.el exist.
  
  After you select newcomer-presets from the splash screen, this is not persisted automatically. "Options > Save Options" doesn't save it either. Because people usually think of themes as cosmetic, they're not likely to find it under "Options > Customize Emacs > Custom Themes; newcomers-presets; Save Theme Settings." The "Options > Save Options" will save the change that newcomers-presets made to the tab bar, thus creating a ~/.emacs.
  
  https://doc.emacsen.de/gallery.html - gallery of themes built into Emacs
  Some screenshots of a fresh Emacs
  
  Figure 1: The splash screen for a new Emacs
  
  Figure 2: File menu
  
  Figure 3: Customize menu
  
  Figure 4: Help menu
  Trying pkal's Emacs Configuration Generator
  
  Emacs Configuration Generator - old source code, site is no longer live
  
  sbcl --load ecg.lisp --eval "(ecg:start)"
  
  Figure 5: Web interface
  
  Figure 6: Theme preview, other options
  
  Sample generated configuration:
  
  ;;; Personal configuration -*- lexical-binding: t -*- ;; Save the contents of this file under ~/.emacs.d/init.el ;; Do not forget to use Emacs' built-in help system: ;; Use C-h C-h to get an overview of all help commands. All you ;; need to know about Emacs (what commands exist, what functions do, ;; what variables specify), the help system can provide. ;; Load a custom theme (load-theme 'modus-operandi t) ;; Use whatever the default monospace font is (setq font-use-system-font t) ;; Miscellaneous options (setq-default major-mode (lambda () ; guess major mode from file name (unless buffer-file-name (let ((buffer-file-name (buffer-name))) (set-auto-mode))))) (setq confirm-kill-emacs #'yes-or-no-p) (setq window-resize-pixelwise t) (setq frame-resize-pixelwise t) (save-place-mode t) (savehist-mode t) (recentf-mode t) (defalias 'yes-or-no #'y-or-n-p) ;; Store automatic customisation options elsewhere (setq custom-file (locate-user-emacs-file "custom.el")) (when (file-exists-p custom-file) (load custom-file))
  View Org source for this post
  
  You can comment on Mastodon or e-mail me at sacha@sachachua.com.
18. 🔗 r/york Fulford Ings rss
  
  | Lovely place to walk the dog. submitted by /u/DentistKitchen
  [link] [comments]
  ---|---
19. 🔗 r/Leeds I feel a bit cheeky asking rss
  
  But does anyone commute on here Sheffield on a weekly basis, who'd be happy to take a carpooler on?
  
  Fairly new job out of desperation, renting isn't an option, and the 2-3 hours lost to commuting is slowly killing me.
  
  Hope to hear something 🙏
  
  submitted by /u/saltlampsandphotos
  [link] [comments]
20. 🔗 r/york Know of anyone who can professionally apply a shop window vinyl sticker? rss
  
  Does anyone know of a professional who can apply a shop window sticker? Just opened a business and we've had an absolute nightmare applying our vinyl sticker onto our window. It would be pretty helpful if we could hire someone a bit more versed in that kind of thing to reapply a new one.
  
  Just for reference it's a Vistaprint vinyl sticker : https://www.vistaprint.co.uk/signs-posters/window- decals?srsltid=AfmBOopp8klBULppQNIzUA5K92IJUP2aJ3XnbtU9pSg6g\_hwn74KODbr
  
  Someone with experience is necessary because I couldn't hack it with none 😂
  
  submitted by /u/peachranunculus
  [link] [comments]
21. 🔗 r/reverseengineering PE packer/crypter with random VM ISA per build rss
  
  submitted by /u/GuiltyAd2976
  [link] [comments]
22. 🔗 r/york Veggie food spots rss
  
  Hello everyone! I’m returning to York for a weekend after 2 years and I was wondering if anyone has any food recommendations. I’m vegetarian, my partner isn’t.
  
  Also open to suggestions around things to do but mostly looking for food :)
  
  Thank you!
  
  submitted by /u/simmpossible
  [link] [comments]
23. 🔗 r/york Comedy tonite at Brew York! PWYW! rss
  
  | Heiya all, Just the usual quick PSA, tonight there is the return of the fantastic Laughs on Draught comedy night at Brew York. We have an incredibly stacked line-up, all 3 of the founders performing AND a work in progress It's going to be great Come check it out tonight. You can reserve a seat for free if you find us on Eventbrite See you there! submitted by /u/emmesse37
  [link] [comments]
  ---|---
24. 🔗 Register Spill Joy & Curiosity #86 rss
  There it is: light at the end of the tunnel. After a week of scaling, tuning, and modifying our infrastructure, Amp Neo is now rolling out to more users. Update your Amp and watch out for a welcome screen that, some people say, "should be marked NSFW" because it's so sexy.
  
  Boy do I have stories to tell. Here's a very 2026 one. We were debugging database issues in production but could only see symptoms and not what caused them. Spike on this graph correlates with spike on that graph alright, but why? What causes it?
  
  If you've ever done any sort of investigation like this, you know that there are a lot of things you can check: are processes restarting? Is the rate of errors going up? Is a CPU pinned? What's the memory usage look like? And so on.
  
  But it's 2026, isn't it? So what ended up happening is that we'd send runbooks to each other. And runbook here means "prompt": a long Markdown document, created by an agent, that instructs the reading agent to check a series of metrics and data points. You'd take a prompt, paste it into Amp, Amp would go off and compile a report. It would say something like "this cluster looks healthy, except for the otel collectors which are OOMing, but that's benign for now, the smoking gun is the log messages that say … because those correlate with … showing up at the same time, which means …" And then you'd take that report and send it to a fresh Amp and that fresh Amp would say that yes, that's right, let's fix this, and you'd sit there and think that there's no way , no way that you would've dug through the logs and metrics at that speed with that precision, but it's 2026 so the agent did it for you.
  - antirez with a "short story of a long development": "Because I had AI, I took no compromises, and I decided to go the extra mile." This is a well-grounded, realistic portrayal of what it looks like to use agents in the first half of 2026. "For high quality system programming tasks you have to still be fully involved, but I ventured to a level of complexity that I would have otherwise skipped. AI provided the safety net for two things: certain massive tasks that are very tiring (like the 32 bit support that was added and tested later), and at the same time the virtual work force required to make sure there are no obvious bugs in complicated algorithms."
  - So, the Bun rewrite from Zig to Rust has been merged and not only did that add around a million lines of Rust code to the main branch, it also created a million hot takes. Most of them are silly ("there's unsafe {} in there"). But there are good ones: "if after the bun rust rewrite and 1M code merge in a few days you still think that software engineering hasn't changed massively idk what to tell you" It's an automated Zig-to-Rust rewrite of a million lines of code and all the tests pass and it took a week. Just as a reminder: this time last year we complained about models leaving "// Deleted this function" comments in code when deleting code.
  - "Complexity has to live somewhere. If you are lucky, it lives in well-defined places. In code where you decided a bit of complexity should go, in documentation that supports the code, in training sessions for your engineers. You give it a place without trying to hide all of it. You create ways to manage it. You know where to go to meet it when you need it. If you're unlucky and you just tried to pretend complexity could be avoided altogether, it has no place to go in this world. But it still doesn't stop existing."
  - matklad on Learning Software Architecture. Great read. And plus one thousand on the recommendation to read Pieter Hintjens and the importance of Conway's Law.
  - John Tromp's Binary Lambda Calculus universal machine. This is like reading a beautiful poem.
  - Sense of Urgency: "This week, I had the privilege of dining at The French Laundry (TFL). […] Since the first Michelin Guide of San Francisco in 2007, TFL has received 3 Michelin stars every single year, and is one of the best restaurants in America. […] Looking around, there were a few inescapable details, none more so than a clock placed in the center of a blank wall facing the kitchen, with a plaque below it that reads Sense of Urgency." I've been thinking about this clock for years now. Yes, I've considered getting a plaque like that. A post-it would do it, surely, but imagine having a plaque like that. No longer would people walk into my office, see the camera and the lights and go "are you a streamer?" but instead they'd ask "what does that mean?" and I'd tell them and-- okay, now thinking about it, the plaque would be too much.
  - Aperio is a new programming language and here is its pitch: "Every language designed before 2023 was optimized for a single tradeoff: minimize friction between human cognitive capacity and machine execution. Assembly to C to managed runtimes to DSLs were different points on the same line. In an LLM-driven workflow, those languages don't get cheaper to use -- they get more expensive. The cost just hides in the LLM's token count, its retry rate, and the latency it eats per turn. Pre-LLM languages are a hidden tax in the LLM era." I find this very interesting, the question of what a language optimized for LLMs would look like. Does it look like Aperio? Does it really introduce new terms and ideas, such as "locus" and "loci" here? Does a language need to be in the training data? Or can raw intelligence master it?
  - en.dev is "a one-person open source software company building mise & friends." I'm intrigued by this page. It's a very, very good page and I don't think I've seen a Sponsors section quite like that. I like it.
  - Amazing: ratty-term.org. That landingpage and video are great , but make sure to read the blog post too. It has some incredible hall-of-fame sentences. This one, for example: "your terminal cursor is a spinning rat". But fear not: "you can configure the cursor to be your dog".
  - Daniel Lemire: We see something that works, and then we understand it. "Both the linear theory and the waterfall model are forms of thinkism, a term I learned from Kevin Kelly. Thinkism sets aside practice and experience. It is the belief that given a problem, you should just think long and hard about it, and if you spend enough time thinking, you will solve it."
  - Geography is four-dimensional, by Derek Sivers.
  - This was fascinating: We don't know why Malawi is poor.
  - Googlebook looks really interesting. The hardware I don't care about, but the idea that you can have a self-modifying operating system: that 's interesting. It'll hinge on how much power Gemini will have, though. Right now I have Gemini in Gmail but every time I try to use it it feels like using Siri: sorry, I can't help you with that. But if they truly unleash Gemini and you can whip up widgets and apps and whatnot and it truly knows how you use the computer? Interesting. Also worth a quick read: their idea of solving "this and that" with the mouse pointer for the AI era.
  - Speaking of self-modifying operating systems: remember Emacs? Thomas Ptacek is wondering whether we're entering the era of The Emacsification of Software. In the Emacs world, it's common to fork & modify and never contribute back. You clone a bit of code into your emacs.d and then you personalize it there. Now, with agents, you can do that with a lot more software.
  - AI, the Shadow Prince: "In none of these instances does AI need to be 'alive' to wield power. It doesn't need to stage a violent revolution or hatch a takeover plan or develop desires. It need only be so efficient, so influential, and so deeply integrated into the loop of human decision-making that it effectively runs the show. We cede authority to AI ministers unwittingly, and out of convenience rather than fear."
  - When I was working at UPS I did a job pretty much close to this one, except you had to sort the packages into three to five lanes, depending on the zip code.
  - I spent my whole career building passive income. Here's what I got wrong: "The grass had been long for a while and every time I looked at it, I didn't like it. So I went out and mowed it. It took a couple of hours. It looked great when I was done. And I felt genuinely good afterward. That's the secret to living a happy life. Write when you don't feel like it. Work out when it's easier to skip. Do your taxes instead of postponing again. Go outside when you'd rather stay in."
  - Yes, I do like the new Spotify logo. Mark my words: Minimalism is dead, flashy is dead, pixel perfection is dead. What's alive and desired: graininess, details, rawness, honesty. In a world in which everything can be copied, the things that are truly unique will stand out.
  - Sean Goedecke provoking thoughts: Software engineering may no longer be a lifetime career. I mean, who knows? No one, as Sean admits. But incentives have shifted, massively, and it's unclear what'll come of that.
  - I'm typing this on a new Lofree Flow 2 keyboard that I got yesterday. So far, so good. I like the sounds a lot, but still need to get used to the typing.
  - Daniel Stenberg, author of curl, on Anthropic's Mythos: Mythos finds a curl vulnerability. Emphasis on "a" -- a single one. On one hand: yes, I'm skeptical, too. On the other: curl is a project that has had many eyeballs over the years. Not sure how much there's left to discover.
  - whatcable: "A small macOS menu bar app that tells you, in plain English, what each USB-C cable plugged into your Mac can actually do, and why your Mac might be charging slowly." Makes me want to check every cable I have. I might.
  - A History of IDEs at Google. Very, very interesting! Reading "Code Intelligence" and "Google" brings back a lot of memories.
  - "If you're in the business of building things that run on computers long enough, I think you will eventually acquire a favorite bug story. This is a short story about mine."
  - "This is the cart before the horse, surely. Who gives a fuck what people think they want to see at that moment? [...] They come to you, because they're interested in what you want to do. And if they don't like it, they can go elsewhere." This is going to sound incredibly naive, but I have to admit that for many, many years now, decades actually, I haven't considered the possibility of just ignoring the audience and building something that you want and still putting it in front of an audience. I've listened to this episode at the start of the week and I still think about that bit.
  Are you also using agents to dig through logs? You should subscribe:
25. 🔗 r/reverseengineering A Tale of Two File Names rss
  
  submitted by /u/galvatron9k
  [link] [comments]
26. 🔗 r/reverseengineering PE reconstruction rss
  
  submitted by /u/Expert-Obligation816
  [link] [comments]
27. 🔗 r/Yorkshire I made the Yorkshire White Rose coat of arms as a t-shirt rss
  
  submitted by /u/mdrnprblms
  [link] [comments]
May 16, 2026
1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-05-16 rss
  IDA Plugin Updates on 2026-05-16
  
  Activity:
  - agent-quality-review-kit
    
    5e81e26a: Update README.md
    
    520caaf9: Package agent quality review as Codex plugin
  - capa
    
    db0e1536: incorrect bytes() constructor usage in buf_filled_with (#3077)
  - ida_scripts
    
    ff6964ed: Updates
  - PyUniDbg
    
    f146e402: docs: update README
  - tix-seven
    
    4c7079cf: Merge pull request #17 from ark1tech/refactor/frontend
    
    1bb352a0: chore: fixed some linting issues
    
    94b8c583: Merge branch 'main' into refactor/frontend
    
    76ee9ef7: Removed obsolete NextJs API routes to fix web build issues
    
    a2228249: aw youre welcome
    
    3e0c91c2: thank you
    
    75a8e956: idek now
    
    44dfc253: feat? rough components
    
    f787c72d: feat? backend?
2. 🔗 earendil-works/pi v0.74.1 release
  New Features
  - Image generation support - Added image generation APIs, generated image model metadata, and built-in OpenRouter image generation support inherited from @earendil-works/pi-ai.
  - Together AI provider - Added Together AI as a built-in provider with /login API-key auth, default model resolution, and setup docs. See README.md#providers--models and docs/providers.md.
  - Windows ARM64 standalone binaries - Added standalone release artifacts for Windows ARM64.
  - Improved terminal and markdown rendering - Added markdown list indentation, task-list checkbox rendering, large markdown robustness, and inline image placement fixes inherited from @earendil-works/pi-tui.
  Added
  - Added image generation support from @earendil-works/pi-ai, including image generation APIs, image model metadata, and built-in OpenRouter image generation support (#3887 by @cristinaponcela).
  - Added Together AI to built-in provider setup, /login API-key auth, and default model resolution (#3624 by @Nutlope).
  - Added Windows ARM64 standalone binary release artifacts (#4458 by @brianmichel).
  Fixed
  - Fixed Node 26 OpenAI-compatible streams timing out after five idle minutes by routing global fetch through pi's undici dispatcher (#4519).
  - Fixed pnpm global package installs by resolving the global package root from pnpm's layout.
  - Fixed macOS clipboard access errors under sandboxed pasteboard denial so they do not abort the process (#4492).
  - Fixed the scoped model startup hint to show the configured model-cycle keybinding (#4508).
  - Fixed resource path display to disambiguate package/resource names that collide across package locations.
  - Fixed fd auto-download on macOS x86_64 by pinning the last release that ships an Intel macOS binary (#4559).
  - Fixed skill diagnostics to stop warning when a skill name differs from its parent directory (#4534).
  - Fixed prompt template argument parsing to split unquoted multiline input on newlines (#4553).
  - Fixed --resume session listing to cap in-flight session metadata loads and avoid OOM on large session histories (#4583).
  - Fixed interactive error messages to render with trailing spacing so reload errors do not run into resource listings (#4510).
  - Fixed .agents package provenance metadata to survive package-manager scans.
  - Fixed nested code fences in the Termux setup documentation so the example AGENTS.md renders correctly (#4503).
  - Fixed tool output expansion while extension confirmation dialogs are focused (#4429).
  - Fixed auto-retry for Anthropic streams that end before message_stop (#4433).
  - Fixed compaction summary calls to clamp requested output tokens to model limits.
  - Fixed uncaught interactive-mode exceptions to restore the terminal before exiting (#4426 by @ofa1).
  - Fixed ANSI stripping to match strip-ansi behavior after dependency removal.
  - Fixed UUIDv7 sequence generation shared by session IDs after dependency removal.
  - Fixed OpenRouter cached-token usage accounting, Fireworks caching compatibility, and OpenAI Codex WebSocket proxy handling inherited from @earendil-works/pi-ai.
  - Fixed markdown list wrapping, task-list checkboxes, large markdown rendering, WezTerm Kitty keyboard escape handling, and short-viewport inline image placement inherited from @earendil-works/pi-tui.
  - Fixed theme sharing across package scopes so extensions do not crash with Theme not initialized (#4333).
  - Fixed keybinding hints to show Option instead of Alt on macOS (#4289).
  - Fixed the interactive update notification to render the changelog as an OSC 8 hyperlink when the terminal supports hyperlinks (#4280).
3. 🔗 r/Leeds Is Dana Store really 24/7? rss
  
  There’s no confirmation of this online, so I wanted to check before setting off
  
  submitted by /u/menotska
  [link] [comments]
4. 🔗 r/Yorkshire Blood Wedding in Sheffield from 24-27 June [Theatre - Performing Arts] rss
  
  | For any theatre and/or Federico Lorca fans who are in or near Sheffield, this local adaptation taking place next month might pique your interest: The Company presents Blood Wedding
  University Drama Studio , S10 2TD
  Wednesday, 24th June 2026 - Saturday, 27th June 2026
  Doors open at 7pm, show starts at 7:30pm Image Description: Promotional flyer for Blood Wedding featuring the actor playing The Bride facing forward with head garland of orange blossoms partially covering her left eye. Behind her, above here head, is the moon. In front of her are clouds that take the shape of a dress. The title of the play is in the foreground in the same colour orange that appears in a blood moon. With a knife.
  With a little knife.
  On a fateful day,
  Between two and three,
  Two men killed each other for love. A man driven to leave his wife and son by a passion that burns deep. A woman driven to leave her husband on their wedding day. In the heat of a Spanish summer, their fateful decision collides with a simmering family feud … the consequences of which are both brutal and deadly. This new interpretation explores Lorca’s world, foreshadowing the violence that would soon tear his beloved country apart and lead to his own tragic end. For tickets: https://www.ticketsource.com/thecompanysheffield/blood-wedding/e-bgpaoa CONTENT WARNING
  Please be aware that this production contains some depictions of violence. VENUE ACCESSIBILITY
  The Drama Studio's main entrance has step-only access. There is an accessible auditorium entrance located at the side of the building on Sherwood Road. There is ramped access (width: 120cm) to this entrance equipped with handrails where audience members will find a bell/buzzer (height: 120cm) and an intercom (height: 88cm). There is not a canopy or recess which provides weather protection at this entrance. Once inside the theatre, there are designated spaces for wheelchair users in the front row of the auditorium. The nearest accessible toilet is located 12m from the designated seating area. This venue does not provide audio described performances, but there is an infrared hearing assistance system which Drama Studio staff are trained to use. Assistance dogs are allowed in the auditorium. submitted by /u/Shake_Some_Dust
  [link] [comments]
  ---|---
5. 🔗 r/LocalLLaMA Local Qwen 3.6 vs frontier models on a coding primitive: single-file HTML canvas driving animation - results and GIFs rss
  | Saw this post comparing Qwen 3.6 variants on coding primitives, so I wanted to see how local quants stack up against frontier models on a similar dense, single-file coding task. I ran the exact same prompt across local and web-based models accessed through my Perplexity subscription. The prompt "Write a single HTML file with a full-page canvas and no libraries. Simulate a realistic side-view of a moving car as the main subject. Keep the car visible in the foreground while the background landscape scrolls continuously to create the feeling that the car is driving forward. Use layered scenery for depth: nearby ground, roadside elements, trees, poles, and distant hills or mountains should move at different speeds for a natural parallax effect. Animate the wheels spinning realistically and add subtle body motion so the car feels connected to the road. Let the environment pass smoothly behind it, with repeating but varied scenery that makes the movement feel believable. Use cinematic lighting and a cohesive sky, such as sunset, dusk, or daylight, to enhance atmosphere. The overall motion should feel calm, immersive, and realistic, with a seamless looping animation." Models tested Frontier (web-based via Perplexity, tok/s not measured):
  - Claude sonnet 4.6 Thinking — used internet for reasoning
  - Gemini 3.1 Pro Thinking
  - GPT 5.4 Thinking
  - Kimi k2.6 Thinking
  Local (Ryzen 5 5600, 24 GB DDR4-3200, RX 5700 XT 8GB):
  - Qwen3.5 9B Q4_K_M — ~50 tok/s
  - Qwen3.6-27B (Claude-opus-reasoning-distilled) Q4_K_M — 2.65 tok/s
  - Qwen3.6-27B Q4_K_M — 2.70 tok/s
  - Qwen3.6-35B A3B Q4_K_M — 12.13 tok/s
  - Gemma-4-31b-it — 1.91 tok/s
  - Qwen3.5 4B Q8 — 60 tok/s — used internet for reasoning
  - Qwen3.5 4B Q4_K_M — 80 tok/s — used internet for reasoning
  What I looked for
  Realistic side-view driving animation: layered parallax scenery, spinning wheels, subtle chassis motion, cohesive sky and lighting, and seamless looping — all vanilla JS/canvas, zero libraries. Subjective ranking for this specific task
  1. Kimi k2.6 Thinking — cleanest overall visual result
  2. Qwen3.6-27B Q4_K_M (local) — stronger than I expected; good parallax and road feel
  3. Qwen3.6-27B Claude-opus-reasoning-distilled — close third
  The local 27B quant delivered more natural motion and layering than some frontier outputs for this specific visual primitive. I was expecting frontier models to do much better — am I missing something? Outputs
  I only changed the HTML <title> tags to track which model generated which file. I’ll share all the output files and probably a few screenshots of the running animations so you can judge the visual quality yourself. If anyone wants to run the exact same prompt on their setup — especially other MoE cuts or distills — feel free to share your results. submitted by /u/Fragrant- Remove-9031
  [link] [comments]
  ---|---
6. 🔗 r/reverseengineering A File Format Uncracked for 20 Years: Part 2 rss
  
  submitted by /u/anxxa
  [link] [comments]
7. 🔗 r/Harrogate Wood burner rss
  
  Can anyone recommend a company to put in a wood burner?
  
  submitted by /u/EdgeObjective2307
  [link] [comments]
8. 🔗 r/york Great visit to York! rss
  
  | Looking forward to returning to York. Went to The Ivy, that was a first, loved it. Visited York museum with Victorian Streets and a prison, even the cell Dick Turpin was held before he was (sadly) publicly hanged. submitted by /u/LesleeTheLego
  [link] [comments]
  ---|---
9. 🔗 r/wiesbaden New to Germany. Need some help with finding a place for myself. rss
  
  First, the context
  I'm a 23 y.o and we moved to Germany, Wiesbaden 2 years ago with my mother since she found a good working place here but after first year our Wohnung proved to be borderline suffocating so we decided that i should move out.
  In my first year i started attending Sprachschule because i don't want to feel like an outsider so currently i'm somewhere around A2.1.
  As time came by i saw that apartment market is really difficult here and i really don't know what i am doing anymore so i ask for a little bit of help.
  
  What is the proper process of finding an apartment here?
  I already sent more than 400 applications on websites like ImmoScout, ImmoWelt, Kleinanziegen. I have german bank account and phone number and all documents like SCHUFA and Personalausweis ready.
  
  Thing is, almost all of my applications are being ignored without proper response from the Vermieter. At this point i feel like i'm doing something fundamentally wrong.
  
  submitted by /u/Vovancheg31
  [link] [comments]
10. 🔗 r/Yorkshire Goslings galore at RSPB St Aidans. rss
  
  | This really is a magical place. Something different every visit. Baby coot as well submitted by /u/DentistKitchen
  [link] [comments]
  ---|---
11. 🔗 r/wiesbaden Neu in Wiesbaden 😊 rss
  
  Hi,
  
  ich (M32) bin vor ein paar Monaten wegen dem Job nach Wiesbaden gezogen.
  
  Da ich hier leider noch kaum wen kenne, wollte ich fragen, was es für Möglichkeiten (z.B. Run Clubs oder so) gibt, um hier neue Leute kennenzulernen 🙂
  
  Ich gehe regelmäßig joggen, fahre häufig Rad und schaue gerne Fußball.
  
  submitted by /u/Al_Bendito
  [link] [comments]
12. 🔗 r/reverseengineering Resident Evil: Code Veronica X is able to use inventory and view files from the decompiled PS2 source! rss
  
  submitted by /u/MrFroz1995
  [link] [comments]
13. 🔗 r/wiesbaden Klavierunterricht rss
  
  Hey, kennt jemand einen guten Klavierlehrer oder kann eine Musikschule in Wiesbaden empfehlen?
  
  submitted by /u/Willing_Market_2279
  [link] [comments]
14. 🔗 r/Leeds Leeds men in 30s rss
  
  Uodate - so seemingly more guys than I thought were up for this so I have set up a WhatsApp group. Drop me a dm for the link
  
  Hi guys. After lurking in some of these threads for a while it Seems to me there are a lot of men in their 30s out there who seem to have a common issue of not much of a social life outside of family/work.
  I know there are a lot of meet-up groups out there, but they aren’t the right fit for me and I suspect this will be the same for others. And I have seen (my wife has joined them) that there are seemingly a lot of groups out there for women only - but other than Andy’s Man Club I can’t seem to find anything similar for men!
  So if there are any other guys out there in their 30s in a similar boat who want to meet up for the occassional pint in Leeds, talk shit, forget work, get away from the family in a no pressure environment then feel free to give me a shout! Hopefully we can get a group of us, then that way I’m sure there will always be an option for a pint even if some aren’t available!
  
  submitted by /u/J87ckoFireBeard
  [link] [comments]
15. 🔗 r/wiesbaden Hi.. can anyone help me 420?🥦 rss
  
  submitted by /u/Stock-Supermarket641
  [link] [comments]
16. 🔗 r/Yorkshire Olliver Duckett at Sunset, Richmond, Yorkshire. rss
  
  | submitted by /u/Still_Function_5428
  [link] [comments]
  ---|---
17. 🔗 r/york The gargoyles of York Minster rss
  
  | Quite the characters hanging around York Minster. submitted by /u/Weird-Positive-3874
  [link] [comments]
  ---|---
18. 🔗 r/york Heslington Hall and campus west rss
  
  submitted by /u/Candid-Turnip-6697
  [link] [comments]
19. 🔗 HexRaysSA/plugin-repository commits sync repo: +1 plugin, +1 release rss
```
sync repo: +1 plugin, +1 release

## New plugins
- [ida-bochs-binaries](https://github.com/hexrayssa/ida-bochs-binaries) (1.0.0)
```
20. 🔗 r/LocalLLaMA MTP support merged into llama.cpp rss
  
  PR 22673 has been merged into master! 🎉
  
  submitted by /u/tacticaltweaker
  [link] [comments]
21. 🔗 r/LocalLLaMA MTP PR Merged!!! rss
  
  | Llamas, LFG!!! 🎉🎉🎉 submitted by /u/Valuable_Touch5670
  [link] [comments]
  ---|---
22. 🔗 r/Yorkshire Best places to take 13 year old and his friends? rss
  
  Hello all 👋🏼
  
  My son is turning 13 at the end of the year and I’m trying to make a start on planning it so I can save up and have enough money for the day etc.
  
  I gave him two options for his birthday and he decided to go with a day out with his friends and this is where I’m struggling.
  
  I live in a village outside of Hull and I’ve opted not take him there as it would just feel like another day and not a special one. We live on the main rail line so we can get to most places but I’m struggling for ideas on where to take them.
  
  Travel wise, we can travel a maximum of 2 hours there and 2 back. It would potentially be 3-6 people (1-2 adults and 1-4 12/13 year olds).
  
  My son likes a variety of things so I am open to any and all suggestions on what to do with them and where to take them.
  
  Thank you in advance 🙏🏼
  
  submitted by /u/Correct-Succotash-47
  [link] [comments]
23. 🔗 r/LocalLLaMA That's a good news... rss
  
  | Looks like it finally happens... MTP getting approved for llama.cpp. Time to prepare for the update. submitted by /u/Pjotrs
  [link] [comments]
  ---|---
24. 🔗 r/york Chocolate Works and Cocoa Works rss
  
  Hi all,
  
  My partner and I are in the process of moving to York and have really liked what we’ve seen with both the Terry’s Chocolate Works development and the Cocoa Works development.
  
  We’d love to hear your experiences of living at either place, both the good and bad!
  
  TIA 🏡
  
  submitted by /u/yoabbee
  [link] [comments]
25. 🔗 r/Leeds Leeds United: mass transit agreement signed with mayor to boost Elland Road expansion rss
  
  submitted by /u/nashvilleskyline1991
  [link] [comments]
26. 🔗 r/wiesbaden Good spot to work with a good WiFi rss
  
  Hello everyone, I work remotely and I’m looking for a good coffee shop or a spot where I can work with decent WiFi. Anyone can recommend any good spots in the city? Danke!
  
  submitted by /u/Moroccan-Leo
  [link] [comments]
27. 🔗 r/york York weekend rss
  
  I went to university in York many years ago (in the 90s) and next weekend I'm visiting with my family (husband and teenage girls age 13 and 14). We did come up about 18 months ago, but I'm looking for some suggestions of places to go and what to do. So far we've booked the ghost bus tour.
  
  When I was at uni I absolutely loved a shop which I think was on Stonegate and I think was called Everything Changes (?) I bloody loved that shop, bought so many cool vintage clothes in there and face glitter. It's a bit of a loose brief, but can anyone recommend any shops like that? It was a sort of new age/vintage crystals and incense type place, if you haven't got a clue what I'm talking about.
  
  Last time we came they loved the Society of Alchemists, but they're a bit old for all the Harry Potter themed stuff now. Any suggestions welcome!
  
  submitted by /u/Top_Addition4317
  [link] [comments]
28. 🔗 r/reverseengineering [CrackMe] PyVMP v7 : The vault. Important info : the server is now live, take a look inside the gofile link. rss
  
  submitted by /u/PynaBola
  [link] [comments]
29. 🔗 r/york Bus shelters going missing rss
  
  The bus shelter near the grand hotel has been missing for months and now one has been removed near YSJ, any one know if these are going to be replaced?
  
  submitted by /u/unfurlingjasminetea_
  [link] [comments]
30. 🔗 r/Yorkshire Now and Then Richmond rss
  
  submitted by /u/Still_Function_5428
  [link] [comments]
31. 🔗 r/reverseengineering Exploiting Toshiba Qiomem.sys vulnerable driver rss
  
  submitted by /u/iamwho007
  [link] [comments]
32. 🔗 r/LocalLLaMA Qwen3.6-35B-A3B and 9B are officially on the public Terminal-Bench 2.0 leaderboard! rss
  
  Qwen3.6-35B-A3B and 9B are officially on the public Terminal-Bench 2.0 leaderboard!
  
  little-coder × Qwen3.6-35B-A3B hit 24.6% (±3.2), and now land above Gemini 2.5 Pro on Gemini CLI (19.6%) and Qwen3-Coder-480B on Terminus 2 (23.9%). I didn’t expect the scaffold-model gap from Polyglot to hold on a benchmark this hard but it did!
  
  little-coder × Qwen3.5-9B came in at 9.2% which is more humble. Yet, it also shows again that sub-10B local models are now measurable on a hard agentic benchmark , not assumed unworthy of a slot.
  
  Just felt it was right to follow up here as you requested, and say a genuine thanks to this community. It really is the place currently driving innovation toward less compute, and this run exists there because you pushed for it.
  
  Now it’s time to head for the top of the leaderboard 👀 let’s go open source!
  
  Leaderboard: https://www.tbench.ai/leaderboard/terminal-bench/2.0
  
  https://github.com/itayinbarr/little-coder
  
  submitted by /u/Creative-Regular6799
  [link] [comments]
33. 🔗 r/reverseengineering HDD Firmware Hacking Part 1 rss
  
  submitted by /u/igor_sk
  [link] [comments]
34. 🔗 r/reverseengineering Region-based binary diff tool for firmware analysis rss
  
  submitted by /u/mtlabs-dev
  [link] [comments]
35. 🔗 r/reverseengineering A 0-click exploit chain for the Pixel 10: When a Door Closes, a Window Opens rss
  
  submitted by /u/tnavda
  [link] [comments]
36. 🔗 r/reverseengineering แก้ไขปัญหา Frida 17.9.10 บน Termux (Android ARM64) - ไม่มีข้อผิดพลาด Toolchain 404 และ _Py_NoneStruct อีกต่อไป! rss
  
  submitted by /u/12EDITUSs
  [link] [comments]
37. 🔗 r/reverseengineering Brovan — Open-source x86/x64 user-mode binary emulator written in C# rss
  
  submitted by /u/Wrong-Cat-5014
  [link] [comments]