# 2026.07.28 Weekly Meeting
**URL:** https://discourse.slicer.org/t/2026-07-28-weekly-meeting/47713
**Category:** Weekly meetings
**Created:** [July 22, 2026, 12:34pm UTC](https://discourse.slicer.org/t/2026-07-28-weekly-meeting/47713 "2026-07-22T12:34:14Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@ebrahim](https://discourse.slicer.org/u/ebrahim)
#### Post date: [July 22, 2026, 12:34pm UTC](https://discourse.slicer.org/t/2026-07-28-weekly-meeting/47713/1 "2026-07-22T12:34:14Z")
Title: 2026.07.28 Weekly Meeting
Next Tuesday, we will be having our next weekly hangout at **10:00 AM ET until 11:00 AM ET.**
Anyone is welcome to join at this link: [Google Meet meeting](https://meet.google.com/ymg-ahrz-www)
* * *
**Agenda:**
Please post to this thread to put a topic on the agenda! We will try to prioritize agenda items during the meeting.
* * *
Thanks
Sam and Ebrahim
---
### Author:  [@muratmaga](https://discourse.slicer.org/u/muratmaga)
#### Post date: [July 22, 2026, 4:50pm UTC](https://discourse.slicer.org/t/2026-07-28-weekly-meeting/47713/2 "2026-07-22T16:50:52Z")
Discuss this [Unintentionally moving whole markup nodes · Issue #9303 · Slicer/Slicer · GitHub](https://github.com/Slicer/Slicer/issues/9303)
---
### Author:  [@ebrahim](https://discourse.slicer.org/u/ebrahim)
#### Post date: [July 22, 2026, 7:59pm UTC](https://discourse.slicer.org/t/2026-07-28-weekly-meeting/47713/3 "2026-07-22T19:59:39Z")
>
>
> Remove the irrelevant \`(cherry picked from commit 1dd81e00f2667acb771d3e412fce95…fcd811a338)\` comment.
>
> One more thought: Everybody should use AI assistance in development (it would be irresponsible to not do it). For this reason, I would recommend to add the AI agent as a coauthor only when the human author does not fully understand, review, or test the change; or for any other reason does not take full responsibility for the proposed changes. I expect not everybody would agree with this - we can discuss at the next dev meeting.
> Everybody should use AI assistance in development (it would be irresponsible to not do it). For this reason, I would recommend to add the AI agent as a coauthor only when the human author does not fully understand, review, or test the change; or for any other reason does not take full responsibility for the proposed changes. I expect not everybody would agree with this - we can discuss at the next dev meeting.
---
### Author:  [@ebrahim](https://discourse.slicer.org/u/ebrahim)
#### Post date: [July 27, 2026, 11:55am UTC](https://discourse.slicer.org/t/2026-07-28-weekly-meeting/47713/4 "2026-07-27T11:55:06Z")
Discussion item: [dependabot](https://github.com/Slicer/Slicer/blob/main/.github/dependabot.yml). Should dependabot be updating actions on a _weekly_ basis and for every patch? Should we [group](https://docs.github.com/en/code-security/tutorials/secure-your-dependencies/optimizing-pr-creation-version-updates#grouping-related-dependencies-together) the actions updates?
---
### Author:  [@ebrahim](https://discourse.slicer.org/u/ebrahim)
#### Post date: [July 28, 2026, 7:25pm UTC](https://discourse.slicer.org/t/2026-07-28-weekly-meeting/47713/5 "2026-07-28T19:25:36Z")
Notes from the discussion:
## installer scripts
Some questions still need answering: [ENH: Add installer scripts to Slicer by mauigna06 · Pull Request #9294 · Slicer/Slicer · GitHub](https://github.com/Slicer/Slicer/pull/9294)
- Here’s Steve’s one-line install:
`(cd ~/Downloads; curl -L "http://download.slicer.org/download?os=linux&stability=any&offset=0" | tar xvfz -)`
For linux a proposal is to split the script into two scripts, one “inner script” for installing, which is a script that gets packaged into the tarball itself, and one “outer script” in Utilities/Scripts/SlicerInstallers/ that is more generic and only handles what cannot be done from the inner script (e.g. downloading and extracting the tarball).
## speeding up slicer initialization
>
>
> \## What this is
>
> The first time each newly built or freshly downloaded shared li…brary is loaded, the operating system inspects it and caches the verdict per file — on macOS a \`syspolicyd\` / \*\*XProtect\*\* security scan (~0.13 s per Mach-O, measured), on Windows an antivirus scan, cold filesystem caches everywhere. Slicer ships \*\*~900 libraries\*\*, so the first launch of a new build or a freshly downloaded copy can spend \*\*a minute or two\*\* on this at near-zero CPU, showing a blank Dock icon and no window, before startup even really begins. Later launches take seconds.
>
> This adds a \*\*pre-warm\*\* that performs that inspection up front, behind an optional native progress splash, so the wait is visible and explained instead of a frozen/absent window.
>
> \### Honest scope: this is a first-launch \*\*experience\*\* fix, not a speedup
>
> The security scan is \*\*serialized by the system daemon\*\* (single-threaded system-wide — verified: an 8-worker parallel version gave \*no\* speedup and was removed). So the pre-warm \*\*does not make the total launch faster\*\* — the cost is unavoidable. What it buys:
>
> \- the unavoidable wait becomes a \*\*native progress window with an accurate ETA\*\* ("Preloading 3D Slicer libraries… about a minute left") instead of a blank screen, and
> \- a \*\*stamp file limits the work to when it's actually needed\*\*: after a new build or download, and once per session after a reboot (which clears the OS caches). The splash is only shown when the run is predicted to exceed \*\*2 seconds\*\*, so ordinary launches stay silent.
>
> \## How it works
>
> \- \*\*macOS primitive:\*\* each library is mapped with \`PROT\_EXEC\`, which makes the kernel run the \*identical\* scan and cache it — without \`dlopen\`, dependency resolution, or spawning a process. (Other platforms load in a disposable worker.)
> \- \*\*\`SlicerPrewarm.py\`\*\* — the sequential warm-up, a boot-session-aware stamp, and native progress splashes for macOS (AppKit), Windows (user32), and X11, all drawn through \`ctypes\` with \*\*no GUI-toolkit dependency\*\*.
> \- Three entry points: an automatic \*\*\`prewarm\` build target\*\* (freshly built libs at end of build), the \*\*macOS bundle bootstrap\*\* (a small compiled \`CFBundleExecutable\` shim that pre-warms before \`exec\`-ing the real app, preserving the process identity), and an \*\*in-app hook\*\* for extension / additional-module paths known only at runtime.
> \- Disable with \`SLICER\_DISABLE\_STARTUP\_PREWARM=1\`.
>
> \## Relationship to prior discussion
>
> Addresses the first-launch experience described in \*\*#9203\*\* (Improve startup speed) and \*\*#8638\*\* (Improve Slicer startup experience). Concrete points from that discussion this acts on:
>
> \- \*\*macOS has no launcher\*\* (and therefore no launcher splash) — so the launcher-splash handoff fix (#8808, Win/Linux) doesn't cover the macOS cold first launch. The bundle bootstrap here is the macOS analog: it puts \*something\* on screen during the wait.
> \- The reported failure mode — \*"nothing appears for ~10 s, the user thinks it failed and relaunches, producing a 2nd instance"\* — is directly what the progress splash is meant to prevent on first launch. (This PR does \*\*not\*\* add single-instance locking; that's a separate mitigation.)
> \- Per the discussion, this intentionally \*\*does not\*\* add an XML launcher↔app progress protocol — it uses a self-contained native splash instead.
>
> Complementary to \*\*#9306\*\* (lazy VTK Python modules), which reduces the \*actual\* Python-import work at every startup. That PR is a genuine \`PERF\` speedup; this one is first-launch transparency for a cost that can't be reduced — the two are independent (no shared files) and address different parts of the same "startup feels slow" problem, which is why they're separate PRs.
>
> \## Status / notes
>
> \- Draft. Primarily exercised on macOS arm64; the Windows/X11 splashes are implemented but need testing on those platforms.
> \- The pre-warm is a no-op on a normal warm launch (stamp check only) and never blocks or aborts startup — any failure (unwritable stamp, splash init failure, etc.) is swallowed.
> \- Not addressed here (possible follow-ups from the same discussion): skipping instantiation of testing modules when developer mode is off, and preventing a second instance during a slow first launch.
>
> 🤖 Generated with \[Claude Code\](https://claude.com/claude-code)
## WebGPU / Wasm / C++ / TypeScript / Rust
- Lots of discussion of different experiments
## things we did not get to
Consider discussing next time.
- middle click on markups: [Unintentionally moving whole markup nodes · Issue #9303 · Slicer/Slicer · GitHub](https://github.com/Slicer/Slicer/issues/9303)
- AI assistance, authorship, and responsibility: [BUG: Restore dropped Python wrapping hierarchy dependencies by pieper · Pull Request #9305 · Slicer/Slicer · GitHub](https://github.com/Slicer/Slicer/pull/9305#issuecomment-5050694165)
- dependabot and upgrade frequency