Chapel project meeting: 2026-05-12 (agenda items, meeting link, notes)

[github-actions[bot]]

This discussion is for the weekly Chapel project meeting.

Date/Time: 2026-05-12 at 10am PT
Join the meeting using this Zoom link
See the Chapel community calendar for additional details and dial-in options

---

Prior to the meeting, propose any agenda items using comments below. After the meeting, rough notes will be added in comments.

Typically, these meetings consist of:

• News: Quick updates or announcements to keep people in the loop on key efforts or topics
• Demos: Have something cool to show off? Do it in a ~5-minute demo
• Short Topics: Have something that needs a quick discussion, description, or straw poll? Propose a ~5-minute discussion topic
• Longer Topics: If you have a topic needing more time, propose it with an estimated duration and we'll try to fit it in.

If you'd like to propose an item in any of these categories, please reply to this discussion.

In addition to the above sections, we have some standing agenda items, such as:

• Triage: What is the state of testing and are there issues that need more attention?
• User Issues: What new user issues have come up in the past week, and which should we prioritize?
• Q&A: Have something you want to ask, but not on the clock? We'll open the floor to Q&A as the official meeting wraps up.

[lydia-duncan]

I'll be likely unable to present the user issues report on the 12th, so @DanilaFe has kindly agreed to do it in my stead. Thanks, Daniel!

[jabraham17]

I have a demo of improvements I made to the Crypto package module and proposals for what to do with those improvements

[jabraham17]

I'd like to have a discussion about removing mason external: #28747

[DanilaFe]

I have a demo of a Mason registry viewer which may or may not even be live by the day of the meeting.

[jabraham17]

I'd like to discuss param folding and side effects

This is related to a recent user issue, which I fix in #28793. But that PR introduces more side effects

Related issues

• comparisons between uint and 0 aren't folded by the compiler #5235
• Document rationale for why short-circuiting operators don't fold RHS param values #20873
• optimization opportunity: fold (non-param) && false #20496
• conditional with && is not param-folded away #25531

[DanilaFe]

I'd like to discuss in/inout formals and promotion. See my PR for more info: #28791

[bradcray]

Agenda / Notes

News/Announcements

• Slides from Jade's & Brad's PNW PLSE 2026 from last week are now online:

  • 30 Years of Scalable Parallel Programming: So Many Hardware Advances,
    So Few Broadly Adopted Languages
    • https://chapel-lang.org/presentations/#artifact-pnw-plse26-brad
  • Portable and Performant Explicit Vector Programming
    • https://chapel-lang.org/presentations/#artifact-pnw-plse26-jade
  • (videos expected to follow)

• New "Open Source for Science" Fund

  • First call for Proposals: "Open Source for the Life Sciences"
  • https://os4science.org/funding_opportunity/os4ls/

• Thursday deep-dive slot: no plans for this week at present

  • to propose a topic: Chapel Deep Dive & Demo meeting: topic list #27247

Triage Status

• David: mid-rotation update
  • Jenkins went down over weekend and didn't come up until we were back Monday
  • CHAMPS is still failing
  • GPU configs failing due to ChOp changes that conflicted with our patch
    • David opened PR to fix
    • but repo sync failed last night, so we don't have new results yet

User Issues

• Daniel (filling in for Lydia): weekly report
  • no new user issues
    • Jade: Paul S. raised an issue in Discord that there's no issue for yet
      • related to param/uint comparisons
      • Jade has a PR to fix, but has fallout we need to discuss
        • related to side effects -- see below
  • 1 resolved issue: ==/!= for unions (Brad)
  • 1 in-progress issue: bug fix for out intent stuff (Daniel)

Demos

• Jade: Crypto package improvements

  • Today, Crypto module requires lots of user specification of paths/libs/etc.
  • (demonstrates using a little shasum.chpl program)
  • some weirdness/badness:
    • need to read entire file into memory
    • then do some copies of it before doing the digest
    • aforementioned specification of flags
      • pkg-config can help a bit, but...
  • so, converted Crypto module into Mason package
    • same code, but made into an example in mason
    • used mason command to build: mason build --example --force
    • can run using mason run or manually
  • also improved the Crypto module
    • added new StreamingHash: keep giving it data, will compute as it goes
    • also a borrowed buffer: avoids data copies, sharing original buffer
  • Jade would like to remove the Crypto module, replacing it with Mason module
    • currently, Crypto is an unstable package module
  • Brad: how to preserve testing?
  • Jade: simplest thing is a custom sub_test that clones the package and
    runs mason test on it
    • have already implemented it and it works
    • easy + simple
    • wouldn't necessarily do it for every package, but for ones we care about
    • main downside: re-cloning repo on each test run
  • another approach: separate testing from Jenkins and rely on GH action that
    runs with Chapel nightly, running the tests just on this repo
    • have done this as well, and it prints the result
    • problem 1: if package on user's mason repo, only owner will be notified
      • moving under chapel-lang could help with that for ours
    • problem 2: separate email for failures rather than being incorporated
      • could do more plumbing to address this
    • this is maybe a better option, but requires more work and maintenance
  • Brad: approach 1 seems like it helps with paratest
    • catches errors proactively rather than the day after, which is nice
  • Engin: seems like the approaches focus on different things:
    • changes to the mason package breaking things vs. changes to Chapel
  • Jade: focused more on Chapel developer persona in this
    • imagines repo will get CI no matter what, prob. multiple Chapel versions

• Daniel: Mason registry viewer

  • made a web-based browser for Mason packages, motivated by request from Jade
  • shows all Mason packages on website
    • (not yet live on our website due to hugo version issues this week)
  • for each, shows:
    • version
    • Chapel compatibility
    • lib vs. app
    • last modified date
    • license
    • copyright
    • source links
  • (hmm, missing link for NumPyLike... maybe due to use of http:// link?)
  • checkbox filters to only show packages that work with Chapel 2.0
    • unchecking shows older packages

Discussion Topics

• Jade: Removing mason external

  • Proposal to remove mason external #28747
  • 3 types of dependencies in Mason:
    • normal Chapel code
    • "external": grab something from Spack
    • "system": "it's already on my system"
  • these last two are similar-ish: a way to depend on "non-Chapel" code
  • two problems:
    • mason external doesn't work today
    • design question: why are we explicitly tying users to Spack?
  • tight coupling results in maintenance burden as Slack changes
    • though less bad than it used to be after Spack 1.0
    • but, currently broken...
  • requires extra effort in Mason => more dev effort to test and maintain
  • arguably opting into something less portable b/c of Spack dependence
    • maybe other consumers of your Mason package can't/won't use Spack
  • proposal: remove 'mason external' entirely
    • does same job as 'system', but more specifically
    • no current reliance on it, and those who've tried hit problems
    • avoid maintenance work that'd otherwise be required
  • could imagine better Spack integration later
    • but, no other package manager does this
    • others rely on users to specify actual flags, or they rely on pkg-config
      Q: Do Spack packages set up pkg-config-compatible entries for installed SW?
      A: Yes.
      Brad: Generally on-board. Thinks that the original vision for "not having
      to learn Spack" was attractive, similar to the launcher story (which also
      is a maintenance burden), though the argument maybe isn't as strong since
      you had to speak Spack to a certain extent to use 'mason external'. Also
      thinks tying to Spack made sense as an HPC technology (and now even moreso
      as a sibling in HPSF). But not convinced it's worth our effort now and
      open to pulling it. Maybe open an issue to capture the idea?
      Jade: Part of that vision is "Mason handles things for you", but Jade
      thinks Mason's the wrong tool for the job, and examples of Cargo and Pip
      suggest that as well. If you want to bundle an app for users, you
      shouldn't do it with the package manager, but with containers, or Spack, or
      something outside of the package manager rather than tying into it.
      Feels pretty strongly that we should not bind to Spack. Not personally
      interested in opening the issue for that reason.
      Consensus: Nobody objected to pulling mason external

• Daniel: inout/out arguments and promotion

  • Fix out formals as promoted arguments; disallow out and inout as scalar arguments for promoted calls #28791
  • Nelson filed a bug in which an out argument was promoted; Daniel has fix
  • along the way, found that passing a scalar to an out argument in a
    promoted setting led to a weird const-ness error.
  • proposing making this illegal, similar to other races on scalars in
    parallel contexts
  • could potentially treat it differently depending on whether it's a serial
    or parallel promotion
  • Jade: Sounds similar to other cases we've had where you can promote
    an array over an array of indices and there can be duplicates in those
    indices and you can assign a value to it (a scatter-style assignment).
    Thinks this feels similar: could warn when opting in with a flag to
    warn about races.
  • Daniel: Nitpick, but won't be continuing to allow b/c it's not today.
    • thinks this differs from the case described b/c it's a much less useful
      pattern. Scatter may or may not be safe. Here, it's guaranteed unsafe,
      and not obvious what the productive use case will be. Seems different
      and not worth working around or allowing.
  • Jade: you say it's always race-y, but it's not if it runs in serial;
    but it's more weird to allow it in serial and not in parallel.
  • Daniel: agrees with that last bit
  • Brad: Square bracket loops similarly require task intents to avoid races
    even for a serial iterand, and we typically talk about promotions as
    being similar to square bracket loops in their "parallel if possible;
    serial otherwise" approach. So thinks there's precedent for assuming
    parallel (offline: and likes this because it makes code more stable
    across changes... i.e., I think the square bracket rule is well-motivated).
  • Brad: Generally agrees with Daniel. This feels similar to modifying a
    scalar within a forall loop, which is prevented. Like that case, can
    work around it using an explicit loop rather than promotion, with task
    intents. Constness error we're getting could even be due to shadow
    variables we're inserting in the rewrite.
    • Daniel: Last checked, constness error seemed separate due to promotion
      wrapper's arguments rather than shadow variables
  • Daniel: Sounds like we don't really have consensus...
  • Jade's point was less that we should preserve this, and more that there
    are other options. Pretty convinced that this isn't useful and likely
    implies a bug, so on-board with making it an error.
  • Daniel: stability question. Spec doesn't say anything about promotion of
    out formals specifically (to his knowledge). Presumably we didn't think
    of it / it was an oversight. Easiest thing is to disallow everywhere
    regardless of edition. But in theory could re-apply patch and permit
    races in the regular edition. Don't like, but it might be most principled.
  • Jade: Thinks turning one error into a better error feels OK without going
    through the edition process.
  • Daniel: "Music to my ears"
  • Consensus: Make this an error message improvement, not needing to be
    guarded by an edition.

• Jade: param folding and side-effects

  • out of time, so here's a plug, and we'll move the discussion to Thursday:
  • numerous issues over the years about param-folding and comparisons
    if (x < 0) ... can be param-folded
  • but what if x has side-effects?
  • similar questions about short-circuiting operators and param-folding
    Q: Is there a statement of your opinion on this at present?
    A: Not really, can see two approaches that seem reasonable, so let's discuss

Post-meeting

• Paul: Kathy Yelick named lab director at LBNL starting July 1
  • first director from a computer science perspective, first female director

Office Hours / Q&A

TODOs / Open Issues

• Set up deep-dive on Thursday

[DanilaFe]

User issues slide as presented today. For the unlinked issue, looks like @jabraham17's #28793 can be used as the GitHub source of truth.