Chapel project meeting: 2025-12-02 (agenda items, meeting link, notes)

[github-actions[bot]]

This discussion is for the weekly Chapel project meeting.

Date/Time: 2025-12-02 at 10am PT
Join the meeting using this Teams link

---

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.

[jabraham17]

I will have a demo of new linux package features for better performance

[bradcray]

Let's plan on doing a Chapel 2.7 round-table on what people are trying to accomplish as a discussion topic tomorrow.

[bradcray]

Announce the deep-dive on Thursday.

[dlongnecke-cray]

I'd like to discuss #28108 which will make changes to the semantics of the manage statement.

[lydia-duncan]

Here's today's user issues slide

[bradcray]

Agenda / Notes

News/Announcements

• Chapel 2.7 release is coming up

  • Dec 4: Feature freeze
  • Dec 10: Code Freeze
  • Dec 11: Doc Freeze
  • Dec 18: Release day

• Deep-dives:

  • Thursday: Part 2 of Shubh's work on Chapel v. Conveyors IG:
    • Chapel Deep Dive & Demo meeting: topic list #27247 (comment)
  • next week: Likely a TSC meeting on logo design, chair, expanding TSC

• Brad + Jade speaking at UW Data Science seminar this afternoon:

  • https://escience.washington.edu/events/uw-data-science-seminar-brad-chamberlain/

• Daniel's representing Chapel and Arkouda at HPE Discover Barcelona this week

• "My Open Source Experience" podcast:

  • Brad recorded an interview during the week of SC25 (part 1?)
    • scheduled to air early 2026 (Feb?)
  • Engin will record one this Friday

• Advent of Code 2025

  • some discussion of it has started on Discord (see #advent-of-code)
  • only 12 days this year!!! :)

Triage Status

• Engin: mid-rotation update
  • some darwin tests have been failing due to mason issues (Engin has PR)
  • CHAMPS "access denied" failures preventing repo cloning (Engin will ask)
  • some issues pending from Daniel's hand-off
    • build-chapel-packages (Jade?)
    • ofi: C #includes (???)
    • asan (???)
    • ex testing remote fetching AMO timeout (Brad)

User Issues

• Lydia: weekly report
  • 0 new user issues (Thanksgiving!)
  • 1 resolved: including mason in Spack (Jade)

Demos

• Jade: demo of linux package features for better performance
  • previously with linux packages, couldn't do specialization
    • e.g., couldn't do simple vectorizations
    • reason: it caused "runtime not built for this config" style errors
    • now, in 2.7, we get vector instructions
    • made possible by not having CHPL_TARGET_CPU affect the runtime path
      • specifically, it's always set to 'cpu=none'
      • that's controlled by (pre-existing) CHPL_RUNTIME_CPU
        => nice performance improvement for users, transparently
        Q: So we are never specializing the runtime, is that right?
        A: Yes, though we weren't before either, we were just specializing the
        runtime path despite that. Have open issue about specializing the
        runtime as well --- left notes for that for a rainy day.
        Q: Do we need to specialize the runtime? Would there be benefit?
        Would be cool, but are we leaving things on the floor?
        A: Don't have one in mind today
        Q: What about memcpys?
        A: Mmmaybe, but expect that to get libc's version, which we can't control
        Q: What about GMP?
        A: Yes, could help a lot, but couldn't find any evidence that we do this
        in any configuration anyway.

Discussion Topics

• DavidL: semantics of 'manage' w.r.t. throwing
  • Support throwing within a manage statement #28108
  • Today, context managers don't quite work when the manage statement contains
    things that throw
  • Today, generates compiler errors, which are kind of weird
    • "error handling in defer blocks must be complete"
    • says that because exit of context has the 'throws' tag
    • contents of 'defer' block must be atomic -- all stmts execute together
      • throwing violates that
    • pretty bad because you're meant to be able to write 'manage' with throws
  • motivated by use of managers in proc ptr work
    • saw a lack of cleanup
    • used 'defer' to try and clean up, but this didn't work
    • opened a public issue and moved on
    • but then Engin also ran into this issue, motivating fixing it
  • PR Support throwing within a manage statement #28108 fixes issue and should support cases we want to write
  • when implementing hit two big issues:
    • first: every exitContext is marked with 'throws'
      => compiler will see every 'manage' statement as a throwing context
      • imagines most managers will re-throw rather than handling/squashing
        => user will have to put all 'manage' statements into try/catch or throws
      • seemed like unacceptable burden on use of 'manage' statements
      • approach taken: Put into try..catch block temporarily
        • remove it if in a context that can handle errors
        • but in some cases, it stays
          • throw within manage will halt if not handled

Release round-table

Brad

feature freeze:

• nothing expected (had hoped to get reindex optimization done, but...)

code/doc freeze:

• EX hang for atomics test

concerns:

• aforementioned EX hang
• successfully lightening Anna's load
• merge Arkouda sort improvement? (just for quieter nightly testing)
  • one case regressed in playground

Jade

feature freeze:

• 3 PRs:
  • linux package fix that Engin mentioned in triage
  • MacOS stack trace improvements
  • fix for issue in Math module when we weren't excluding cast checks w/ --no...

code/doc freeze:

• PR improving LLVM IR generation -- developer readability change
• bunch of chpl-parallel-debug bug fixes
• transcribe editions/stability slides and conversation into docs

concerns:

• no LLVM 21 support in this release, which has become a portability issue
  • PRs been stuck for many months, but has been in PR dependency hell
  • then got unstuck too close to the release
    => for some OSes, users will have to use bundled or alternative LLVM
    • plus LLVM 22 will probably be coming out soon
    • Fedora, Arch, Homebrew
      • these pin to llvm 20 in our docs
        Q: Will we go through another hell for 22?
        A: No, Spack reconfig should help here (hope, hope)

Anna

feature freeze:

code/doc freeze:

concerns:

Ben

feature freeze:

• dyno changes in support of basic hello world operations...

code/doc freeze:

concerns:

Engin

feature freeze:

• mason PR
  • goal would be to have 2.7 mason good enough to support a Parquet module
  • believes this should be sufficient
  • will also fix an ongoing darwin failure

code/doc freeze:

• doc changes in support of the above PR

concerns:

David

feature freeze:

• 'manage' behavior change w.r.t. throwing discussed above
• procedure pointer PRs in module code

code/doc freeze:

concerns:

Post-meeting

Office Hours / Q&A

• More LLVM
  • LLVM 20 and 21 do not work with ROCm < 6.3
  • however, with newer LLVMs, some bundled AMD issues seem to be resolved
  • so, being able to use newer LLVM expected to help with ROCm and generally
    be better
    • except we can't currently work with ROCm 6.3 b/c it crashes with ...
      something about shared library destructors being called multiple times
      • related to exiting from a GPU kernel
      • e.g., assertOnGPU() would hit it
  • felt unhappily tangled together
  • not sure how to prioritize ROCm fixes / upgrade LLVM without it
  • sounds like more work than we can take on for this release to upgrade
    bundled LLVM
  • Engin:
    • OK with dropping support for older ROCms (e.g., 6.1, 6.2)
    • also OK with having the 6.3-style ugly exit failures
      • would cause issues in our nightly testing that would require prediff
    • So, updating to newer ROCm versions should... just be OK?
    • Jade: Yeah
    • Engin: post-release, would be happy to put some time into ROCm, maybe
      focusing just on 7? (skip 6.4, or just try it and document what we see)
      • assuming we have access to ROCm 7 where we want/need it
      • Jade: And what do users have is a question as well
      • Engin: Concerned that Frontier may not have 7...
      • Jade: Could continue to support 6.3 with ugly exit for Frontier...
      • Engin: Can't really imagine users hitting ugly exit much or complaining
        much about it -- would need to use assertOnGPU on non-GPU loop

TODOs / Open Issues