Chapel project meeting: 2026-02-17 (agenda items, meeting link, notes)

[github-actions[bot]]

This discussion is for the weekly Chapel project meeting.

Date/Time: 2026-02-17 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.

[bradcray]

Deferred from last week:

• @jabraham17: Demo of flag for pass-through of slurm options
• @bradcray: Discussion of opening Slack to the public

[DanilaFe]

I'd like to demo my work on improving chapel-py + chpl-language-server with richer understanding of error messages (#28391).

I'd also like to discuss having our developers test chpl-language-server with Dyno resolution enabled, to build confidence and possibly fix common issues.

[lydia-duncan]

Here's today's user issues report slide

[bradcray]

Agenda / Notes

News/Announcements

• Chapel 2.8 release dates:

  • Feb 26: Feature freeze
  • Mar 4: Code freeze
  • Mar 5: Doc freeze
  • Mar 12: Release day

• Shubh's CUG submission was accepted

Triage Status

• David: mid-rotation update
  • system issues:
    • ton of failures yesterday due to out-of-disk space issue (Anna)
    • another sys is down this week for maintenance, causing failures yesterday
  • others
    • new oom test failures (Anna)
    • new ifMask test valgrind failure (Jade)
    • curl error (sporadic?) (Brad & DavidL)
  • checking to make sure others weren't missed
• Also, Brad looking into why email previews have gotten worse on Discourse
  • seems to be a Discourse configuration issue

User Issues

• Lydia: weekly report
  • one new user issue opened: request for CUDA 13.1 support (Jade?)
    • related to LLVM update issues
  • two closed:
    • one about internal error in reduction in nested loops (Daniel)
    • TCL/Modulefile issue (resolved earlier; closed this past week) (Anna)
  • old issue:
    • method for asserting errors in unit test jmag722 (Jade replied today)
• Jade: There's also a PR open for isClose() (Engin just ran CI)

Demos

• Jade: pass-through flag for Slurm launchers

  • adds new flag to slurm-based launchers for passing additional flags to srun
    • e.g., anything we don't support directly, people can access
    • e.g., can pass '-S0' on Frontier to use all cores without GPUs
  • also fixed a pretty bad string-parsing bug in Slurm launchers
  • current flag name is '--launcher-flags'
    • but we refer to 'foo' (vs. 'foo_real') as the launcher, so...
    • orienting on '--system-launcher-flags' instead for clarity

• Daniel: demo of chapel-py + chapel-language-server error understanding

  • resolution failure didn't provide much information about why it failed
    • whole call expression is marked as the problem when it may just be 1 arg
  • in looking to fix it, realized chapel-py alone couldn't help
    • not enough information stored in 'Error' class
  • but, compiler/Dyno has much richer information, not available to chapel-py
    • well, until now
  • piped more information through to chapel-py, which can now flag faulty arg
  • similar improvements to tuple- and 'use-with-rename' errors
  • plenty of room to do more going forward in CLS w.r.t. diagnostics
    • e.g., auto-fixes for simple errors
  • Engin: Having these Python classes feels like a maintenance burden?
    • Daniel: These are auto-generated from Dyno's classes, so no...
  • Engin: Is it like C++/Python "general" magic, or is it more customized?
    • Daniel: Not a script -- use a C++ #define to define macros for classes
      • used when needing to iterate over all the classes, etc.
      • so no script, done using C preprocessing
  • Brad: These probably require using the --dyno flag?
    • Daniel: Yes, except for the 'use' with filtering -- others require types
      • see discussion topic below

• Jade: last-minute demo on tooling

  • have been reviewing Chapel code and finding styling inconsistencies
    • annoying and wants tooling to help
  • created three linter rules to help
    1. un-attached else
    2. un-attached catch
    3. dangling curly brackets
  • also auto-fixits
  • one weird case: '}\n// comment\nelse { ...' (no obvious/legal fixit)
  • if don't like these rules, can disable them
    • but would like it to be more broadly configurable--rolling rules together
  • fixits sort of serving as a crutch without a formatter
  • also fixed a lot of bugs while doing this
  • Engin: Do you warn for unattached while in do...while?
    • Jade: this is one exception not currently handled, but probably could
      • just didn't get to it / prioritize it
    • another is square bracket loops, which are harder to fix
      • (b/c their location information is a mess)

• DavidL: Dynamic loading demo

  • using GASNet, building a Chapel library and a program that dyn. loads it
  • library contains an exported procedure that calls printf on each locale
  • program grabs library, gets number of tests, loops over and runs them
    • gets procedure pointer using 'loadLocally' (per-locale ability to call)
  • running with one locale, a bunch of stuff is printed out
    • debug information about initializing modules
    • comm diagnostics to trace communication
    • similar for program 2, which launches and runs task
    • then program 2's module initialization
    • then runs tests themselves, printing output
  • running on two locales, lots more is printed out to get both set up
    • current problem is that 'on' clauses are calling stuff in program 1
    • need to adjust 'on' functions to execute the correct fn table entries
  • Brad: program 1 and program 2 are library and executable, respectively?
    • yeah, should give better names
  • Engin: could exercise this on dynamically loading unit tests potentially
  • Engin: in talking about this, we've talked about a shared runtime
    • but what about internal modules? looks as though binaries get their own
      • should they? is there a problem there?
    • David: That's been discussed somewhat...
      • duplicated at present, but don't necessarily need to be longer-term
        • not aware of problems this is causing, though there may be some...
      • doing this for simplicity / to try and get a minimal viable product
      • use of generics in standard/internal modules is a challenge
  • Jade: Why use 1-based numbering for programs rather than 0-based?
    • David: These are IDs and 0 is reserved
  • Brad: Wants to point out that a single dynamically loaded copy of the
    runtime is being shared between the executable and library -- a great
    milestone

Discussion Topics

• Brad: Discussion of opening HPSF-provided Slack to the public

  • Jade: In favor of this, particularly given Discord trends w.r.t. privacy
    • not saying we should stop using Discord, but good to have alternatives
  • straw poll: 6 in favor, no opposed

• Daniel: Would devs test chpl-language-server with Dyno enabled?

  • Using CLS with --dyno works reasonably well in Daniel's opinion
  • Interested in turning it on by default
  • But others' mileage may vary
  • So, curious whether others would be willing to be --dyno CLS guinea pigs
    • to let us gather data and decide whether to enable by default
    • or if not, what we would need to do to get to that point
    • Daniel happy to help people get it set up if desired
  • Jade: Can I share some experiences so far?
    • Daniel: Yes, and can put in Slack thread
    • Jade: Will do that -- am somewhat hesitant to turn it on by default
  • Straw poll: Who's using the CLS already?
    • no: 4
    • yes: 3
    • with --dyno: 1
  • Jade supports having more people using the CLS in general because it feels
    like it's gotten less stable between 2.6 and 2.7
    • Daniel: Seems surprising... not much has changed. Can you report?
    • Jade: Hard to report... just seeing more typical crashes than usual

Post-meeting

Office Hours / Q&A

TODOs / Open Issues

• Set up community Slack links