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

[github-actions[bot]]

This discussion is for the weekly Chapel project meeting.

Date/Time: 2026-05-19 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.

[jabraham17]

I would like to discuss #28834

[jabraham17]

I have a demo of new error handling features

[lydia-duncan]

I talked to Daniel about this already, but my kitchen remodel is still ongoing so he'll be doing the report again this week

[DanilaFe]

I have a demo of some prototype CLS features I developed while waiting for Arkouda builds.

[DanilaFe]

I missed a user issue that was tracked only in our internal issue tracker. It's now listed in this updated user issues slide.

[bradcray]

Agenda / Notes

News/Announcements

• Brad/Jade speaking/demoing at Northwest C++ Users Group on Thursday

  • combination intro + "what's new since ~2022"
  • https://nwcpp.org/May-2026.html

• 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: end-of-rotation update
  • last week: LLVM 22 fallout, but Jade, Anna, Ben, David, Daniel helping...
  • most yellow failures are accounted for
    • new ofi failure regarding deprecated behavior (Brad)
    • Arkouda server crashes (Daniel)
    • twoLocales failure (Jade)
  • two red builds that still need a look (David)
  • CHAMPS is not really accounted for (David->Daniel)
    • patch application issue?
      • Yessish... Jade created patch believed correct, merged
      • now getting mkl linking failures -- reason unclear
        • did we mess up paths?
        • mkl moved locations?
        • something else changed on CHAMPS's side?
    • Daniel will take a look; and can help out again after dlopen stuff

User Issues

• Daniel: weekly report
  • no new nor closed user issues
  • progress being made on param ** (Brad)
  • [post-meeting: identified one internal user issue; see slide above]

Demos

• Jade: new error-handling features

  • was working on mason, exceptions wanted a better experience
  • running a throwing program, error is reported as uncaught
    • but not much information between where it was thrown and uncaught
    • would like a trace
  • Chapel gives traces for halts, but not uncaught errors
  • now they do!
  • what if user had handled error and wants to know where it came from?
    • can now print out stacktrace from code when opting into new edition
  • but better errors on uncaught cases are by default
  • Daniel: Could .stacktrace() be available by default, unstabley?
    • Jade: They could...
    • Brad: Tends to agree
  • Brad: How does implementation of this work?
    • new hook that compiler inserts when doing error prop work
    • gets inserted whenever we catch an error and rethrow it up stack trace
    • get new information and push onto stack, then print it out
  • Brad: zero overhead for non-throwing errors
    • Jade: Right. For programs that do throw, there's a bit of overhead
      in terms of space (pointer in error class) and time (creation)
  • Jade: Caveat: throwing iterators don't work very well

• Brad: expanded website "news" section

  • "What's New?" front page banner links to new "news" page
    • clicking the "more..." link after front page news leads partway into it
  • Jade: third entry has unrendered html
  • Daniel: thinks it's probably not the fault of this recent PR
    • thinks there's a way to unescape HTML... should be easy
  • [post-meeting: fixed; this was Update test/users/bugzilla/bug794131/ #18; Daniel's new approach fixes]

• Daniel: prototype CLS features

  • was going through old assigned issues, one of which was return type
    inference for CLS
    • turned out to be pretty easy in current day and age
  • shows two test functions, one that returns 42, other 42.0
    • see inlays that show that one returns int(64) and the other real(64)
    • uses regular Dyno type inference mechanism -- if Dyno can do it, this can
  • also works with type-returning procedures
    • gets in right place w.r.t. where clauses and such
  • what about generics?
    • one returns its argument -- labeled as returning x.type by default
      • then when showing instantiation, matches argument type (int/real/etc.)
    • other always returns 42 regardless of instantiation, labled as int(64)
    • more complex example takes x and y, returns tuple
      • labeled as (x.type, y.type)
    • another returns array-of-arg-x, correctly shows array type
    • another takes list(?eltType), reports returning eltType
    • works best for parametric polymorphic functions
      • could work in theory for ad hoc polymorphic, but not as reliable
  • Brad: any changes to Dyno itself?
  • Daniel: Had to plumb some new stuff through from Dyno to chapel-py
    • previously did some interface resolution stuff
      • relied on placeholders for generics
      • leveraged that here, plumbing it through to Python

Discussion Topics

• Jade: More on param-folding of <, &&, etc.

  • How much should Chapel param fold #28834
  • brief review: How much param folding should Chapel do on bool expressions
  • last week's deep-dive was:
    • don't param-fold uint/int comparisons
    • don't fold anything between non-param and param
    • continue to fold param && non-param, param || non-param
    • continue not folding non-param && param, non-param || param
  • Brad: delta from what we have today?
  • Jade: remove asymmetric < folding that we do today
    • improve docs, add new tests
  • Brad: Likes that delta is minimal
  • Brad: explains some thoughts over week:
    • param-ness of an op shouldn't depend on values, just types and param-ness
      • but false && x vs. true && x does
      • consider this a special case, ideally the only one?
    • notes asymmetry in that param procs squash side-effects
      • so, should x && false also do so? for now, thinks no, but seems odd
      • maybe compiler should be warning for side effects in param procedures

• Brad: implementing ** on param reals: have a branch that adds:

  • param real ** param int
    • implemented for **(0..6 | 8) as it is for real ** param int
    • implemented for other exponents using pow()
  • param real ** param real
    • implemented using pow()
  • concerns raised on issue:
    • real ** real is an anti-pattern (param or otherwise)
    • real ** n should be implemented with pown()
    • what do real applications / other users want?
      Daniel: Doesn't think we should do half-measures
  • we should either be cautious about real**real everywhere (or nowhere?)
  • personally in favor of proceeding with this by symmetry argument
    • if we switch to pown(), should do it for compile- and runtime
    • and believes we should do it if it becomes available
    • would be up for an issue on this
    • and thinks it should be guarded by an edition going forward
      Anna: What's special about those exponents?
      Brad: only require a small number of multiplies to implement (0-2?)
  • have been treated this way for a long time now; can't recall rationale
    • probably faster
    • possibly better numerical properties?
  • could reconsider, but for this PR, only focused on symmetric treatment
    Jade: on-board with this change
  • makes sense to have pow() match btwn runtime & compile-time, as proposed
  • from stability perspective, this should probaby go into an edition
  • what about complex numbers -- we do have ** between pairs of complexes
    • can file issue for this, but not sure want to hold up this PR over that
    • Jade: OK with it not holding up this PR, but would want to implement soon
      (and may)
    • Daniel: Do we have complex params?
    • Jade: (checking) yes
    • Jade: Notes we don't support pow() on imaginary numbers...
      TODO before merge:
  • docs in PR
  • guard change by edition in PR
  • new issue for ** on param complex
  • new issue for ** on imag

Post-meeting

• discussion about whether param complex should pass to param real/imag if one
  component is 0.0
  • considering analogies with other param conversions (int/uint, int/real)

Office Hours / Q&A

TODOs / Open Issues

• cancel Thursday meeting if no plans