Chapel project meeting: 2025-09-23 (agenda items, meeting link, notes)

[github-actions[bot]]

This discussion is for the weekly Chapel project meeting.

Date/Time: 2025-09-23 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 would like to have a brief discussion about #27823

[jabraham17]

I will have a short demo of a small debugging improvement I am working on with compiler temps

[jabraham17]

I would like to discuss #27826

[lydia-duncan]

Today's user issues report slide

[bradcray]

Agenda / Notes

News/Announcements

• Chapel 2.6 was released last Thursday — thanks everyone!

  • announcement: https://chapel-lang.org/blog/posts/announcing-chapel-2.6/

• Published 6th blog in "10 Myths of Scalable Parallel Prog. Languages" series:

  • topic: performance of higher-level languages
  • https://chapel-lang.org/blog/posts/10myths-part6/

• Second TSC held last week

  • topics: GOVERNANCE.md, voting, logo, and renaming
  • slides and notes at: https://github.com/chapel-lang/TSC/tree/main/meetings
  • issues related to logo and renaming for asynchronous voting / discussion:
    • Should we rename 'Chapel' in the near-term/foreseeable future? (a time-focused question) TSC#9
    • Should we have a new logo and/or mascot before publicizing our move to HPSF? TSC#11
    • Should we rename 'Chapel'? TSC#10
    • Logo / Mascot Brainstorming TSC#12
    • Logo Design Process Considerations TSC#4

• this Thursday's deep-dive: Shubh (GaTech / Habanero labs) will share aggregation
  results from ORNL Frontier

Triage Status

• Brad: mid-rotation update

  • new (sporadic?) gasnet+quickstart failure in memory/gbt/test-memLog (Brad/steal)

    • > 1: --:0: allocate 16B of thread list descriptor at 0x7f26a8000b60
    • Engin: found closed sporadic about this from 2021 (checking, seems to be a different, unrelated failure mode)

  • EX testing: coming back up after sys upgrade (thanks: Jade, Anna, Engin)

    • main 'ofi' configs (unowned)
      • new failure in multilocale/diten/localBlock/needMultiLocales/localBlock5
      • error: *** STEP [i] ON [node] CANCELLED AT [time] DUE TO TASK FAILURE ***
    • gpusuite: bad path to CUDA (Engin)
    • ROCm: error fetching 'origin' due to permission error (unowned)
      • cannot exec '/path/to/jenkins-gitclient-pass*.sh'
      • Jade: ongoing network failures?
      • Anna: agrees permission denied is odd... Will wipe out workspace to see
        what happens

  • apptainer testing: hitting disk space issues (Brad/steal/teach)

  • test-release-tarball: still running into OOM on [system] (Brad/steal/teach)

    • proposal: pin test config to another system

  • Arkouda:

    • new ASAN failure (Engin notified devs)
    • v2 testing config: still being brought up (Jade)
    • long-term sporadic sorting failure (Engin?)

  • CHAMPS: continuing to fail due to developer changes (since Aug 7) (devs+Engin)

User Issues

• Lydia: weekly report
  • one new user issue by Guillaume: indexing uint(8) rank-change array views (Brad)
  • one resolved issue: warning for rotl/rotr for too-large shifts

Demos

• Jade: debugging demo

  • auto-filtering of compiler-generated temps to focus on user identifiers
  • pretty-printing of complex, atomics, and owned classes
  • breakpoint in coforall: breaks on pthreads, not Chapel tasks / qthreads
    • e.g., for 10-iter coforall, 4 qthreads hit breakpoint on 4-core system
    • can switch between threads and see distinct 'i' values
    • can see partially initialized array
      Q: Why 4 threads, 4 cores?
      A: No, should be 8 cores... not sure why 4
      Q: Tried with fifo -- would that be better?
      A: Haven't tried yet; looked into teaching about qthreads more...
      Q: Need for 'p *Arr' rather than 'p Arr'
      A: It's because we're using C's understanding of evaluating expressions;
      within coforall, 'Arr' is a ref shadow variable, which shows up as a pointer,
      so we need to dereference it. Looked a bit into what it would take to add
      Chapel as own language to lldb, and it's a massive lift.
      Q: Could we auto-deref C pointers in our pretty printer since they're not used
      much in Chapel?
      A: Could have dire consequences for recursive data structures, e.g. made of
      Chapel classes
      Q: Can we not distinguish between Chapel classes and C pointers?
      A: owned, today, yes. Borrowed and unmanaged, no, but working on that.
      Q: Something about pretty-printing I missed

• Daniel: rendering of enums' values within CLS-enabled editor

  • print implicit and explicitly computed enum values
    (e.g., 'red = 1, green, blue, cyan = red: int + 10, yellow, etc.'
    can show values of green, blue, cyan, yellow, etc.)
  • also, editors like VSCode will insert the values for you if you want

Discussion Topics

• Jade: how to end-of-life Cray XC/ugni support

  • no longer supported by HPE and our ability to test is going away
  • Q: should we continue to support XC in some way and what should we do with code?
  • Fair amount of code and the only way to target XC
  • options:
    • leave there
    • deprecate
    • delete
  • Jade's inclination is to delete
  • GASNet team proposed deprecation first
  • Engin, Anna: prefer gentle deprecation and then removal in 2.8
  • consensus: deprecate for 2.7, remove in 2.8

• Jade: require gnu17 support to build the runtime?

  • runtime uses VLAs, which are a gnu extension
  • should either not be using them or explicitly saying we're using them
  • started to remove, but found more cases than wanted to deal with at this time
  • tempted to opt into gnu17 standard with Clang -- newer and supported by all
    compilers we list as prerequisites
  • note this is less about adding new requirements and more like stating what
    we'll use
  • Q: Have you tried this? Was it clean?
  • A: Yes and yes.
  • Q: Does going to gnu17 open the door to lots of other features?
  • A: Yes, though there are ways to focus in on "just VLAs"
  • Q: Arkouda currently has some C++ code that requires C++17. Does that mean
    Arkouda is already compliant with this change? I guess gnu17 and C++17
    are different things...
  • A: C17 standard didn't really add new features, more like cleaned up language.
    Don't anticipate Arkouda running into issues with this as a result.
  • Devs may appreciate an early heads-up and PR to try before the next release for
    Arkouda devs to try
  • Pretty sure they're using gcc11, which should be fine w.r.t. this

Post-meeting

Office Hours / Q&A

• Learning about wiping workspaces in Jenkins
• Learning about restricting jenkins jobs from running on specific system

TODOs / Open Issues