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

[github-actions[bot]]

This discussion is for the weekly Chapel project meeting.

Date/Time: 2025-09-30 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.

[DanilaFe]

I'd like to have a discussion on the meanings of the various modules/* subfolders, and what is appropriate to go in them. Of particular interest is where we can put code that we are okay exposing to the users, while still using it in the compiler / standard modules.

[DanilaFe]

Also, I would like to do a demo of some of the Dyno work I've been doing :)

[lydia-duncan]

Here's today's user issues slide

[bradcray]

Agenda / Notes

News/Announcements

• LF/HPSF legal transition complete

  • HPE transferred rights to LF
  • Technical charter added to governance repo
  • GOVERNANCE.md updated to reflect tech charter:
    • https://github.com/chapel-lang/governance/blob/main/GOVERNANCE.md

• Good deep-dive with Shubh (Ga Tech) last week on Thursday

  • topic: initial IG results

• TSC meeting this Thursday, focused on logo design and HPSF transition
  Topics for Oct 2 TSC meeting TSC#17

• ChapelCon next week, Oct 7-10

  • browse schedule and register at: https://chapel-lang.org/chapelcon25/

Triage Status

• Brad: end-of-rotation update
  • should be fixed in next run:
    • many configs (linux64-clang, linux64-gcc*, linux64-llvm*, darwin, EX):
      • blog warning that's sensitive to prims.cpp line number (Daniel)
    • gpusuite: bad CUDA path due to version change (Engin)
  • ongoing, owned, and outstanding:
    • Arkouda+GPU: conflict between new enum and one in CUDA file (Engin)
    • verify: internal error in 'useBreakpoint-lldb' test (Jade, Daniel)
    • Arkouda v2 testing config: still being brought up (Jade)
  • ongoing sporadics:
    • Arkouda sort failures
      • https://github.com/Cray/chapel-private/issues/7246
    • EX rocm testing: continuing to have jenkins-github script perm err
      • opened https://github.com/Cray/chapel-private/issues/7673 to track
    • Curl failures (DavidL):
      • opened: https://github.com/Cray/chapel-private/issues/7674
    • OOM in Arkouda compile causes "error: invoking driver compilation phase"
      • https://github.com/Cray/chapel-private/issues/7528
  • ongoing, unowned / I own for now:
    • localBlock5 failures in EX testing
    • sporadic "no route to host" failures on EX
    • apptainer: /tmp/ seems full
    • build-packages: 2 configs failed (sporadic?)
    • vagrant: 1 config failed (sporadic?)
    • test-release-tarball: "error creating release"

User Issues

• Lydia: weekly report
  • 1 new user issue: Can we support arrays of refs
  • 0 newly resolved user issues, probably due to ChapelCon

Demos

• Daniel: Dyno work demo
  • implementation of re-instatiating partial type instantiations in Dyno
  • example:
    • record with 3 type fields
    • type alias instantiating some, but not all, of the record's types
    • can then take an existing partial instantiation, and supply another type
    • can then fill in third thing and get complete type
    • can also instantiate fields out-of-order
      • though CLS/Dyno doesn't necessarily make order clear, currently
        Q: Should CLS annotations use ? in partial instantiations? Multiple '?'
        to mark multiple unknowns? positional '?' to indicate orders? [or
        keyword-based args?]
        A: Agree, though Dyno currently can't do this due to need to get access
        to the global context. But we should work around this and make it
        happen.

Discussion Topics

• Daniel: the meaning of the modules/* directories
  • had a discussion this week about where potential future standard modules
    should live, or experimental utilities, or ...
    • modules/standard?
    • modules/package?
    • mason package?
      • (that's pulled in automtically? b/c want to have std libs might use it)
  • example: managed locks using context managers
  • reason for not putting into standard modules: hurdle of stabilization
    • uncertainty of TSC's role
      [see Brad's comment below]
  • Daniel: other examples exist of package libraries used by standard modules
  • unstable standard module?
  • what ought to go in a standard vs. package module
  • package modules have sometimes been mason packages that haven't been spun
    out yet -- putting new packages there creates more work when those are
    spun out to mason eventually
  • other interpretation of package modules: batteries-included
  • standard modules have review hurdle
  • some standard modules have compiler entanglements
  • Engin: adding stuff to the standard modules should be a little easier
    now that we have editions. We can add something in an edition and
    change it in a future editions if we don't like it that much. Feels
    like it lowers the barrier there.
  • Engin: believes all package modules should become either mason or
    standard modules; that modules/packages should ultimately go away
  • Engin: for David's examples, seems like there are clear locations for
    some things -- e.g., context manager for timers should be in Time;
    for comm counts in CommDiagnostics
  • Daniel: One problem with mason modules at present is that the standard
    library cannot call into it; in David's case, wants to use the code in
    compiler code, which makes a mason module not feel like a good fit
    • Engin: agrees
  • Lydia: worried about characterization of review as onerous -- if we think
    something is useful, we need to give it review and scrutiny to avoid
    getting into a situation where users rely on it and write breaking code.
    Review shouldn't be a barrier to start trying things out... Suggests
    needing an "under development" space in modules. Does that suggest
    another area for draft standard modules?
  • Daniel: Agrees with what you've said. These things seem to invoke an
    unstable standard module. It gives the user a warning when they use
    --warn-unstable. Doesn't introduce a new directory. And we already
    don't expose the module directory structure to users anyway. They
    wouldn't know about 'modules/draft/' necessarily
  • Lydia: Well, but the docs do distinguish between standard and package
    modules.
  • Daniel: Do you think the directory is more important than an unstable
    marker on the module itself?
  • Lydia: Would be more comfortable moving packages to a new standard/drafts
    directory than moving them into modules/standard and making them unstable.
    Somehow putting them in a separate directory seems to indicate intent
    more clearly (maybe for us as developers, if not for users)
  • Brad: Would you mark them explicitly unstable in the code?
  • Lydia: Not necessarily, would have their presence in that directory
    automatically cause them to be treated that way, similar to /packages.
  • DavidL: Could also make them private standard modules for some things
    that are designed more for our use than for end-users.
  • DavidL: Thinks iteration and experience is important until we get
    enough experience with a feature to know how people feel about it.
    Doesn't think we should require review before things are added.
  • DavidL: Also sensitive to putting code into modules/standard without
    much oversight.
  • Lydia: Agrees with the need to evaluate and get experience with
    interfaces before locking them in.
  • Brad:
    • agrees that standard over packages feels right for things being
      used by compiler or anticipated to be compiler -- doesn't feel
      strongly about new directory vs. unstable/edition-guarded feature
      in existing module/directory (would probably use a directory for
      new modules but also open to putting features linked to an existing
      module into that module as unstable/edition-guarded)
    • most decisions should be screened past developer community here;
      say, do a demo, or have a discussion after filing a github issue
    • TSC should only be called in for most extreme cases, not as a
      gatekeeper for any new feature, module, etc. That is Tuesday
      meeting material, and we're still making most decisions based on
      consensus among the developer community. Past examples that may
      have made it to the TSC: 0- vs. 1-based indexing; introduction
      of owned/shared/borrowed classes; not much else?
  • Engin: clarifies what he was thinking of w.r.t. using editions to
    try things out
  • Daniel: Hadn't thought about editions, but thinks of them as being
    a mechanism to hide code that a user shouldn't see if they didn't
    opt into that edition, right?
  • Lydia: Yeah, more about changing behaviors... Thinks of new things
    as being marked unstable; as they get stabilized, tuck them into an
    edition.
  • Daniel: Unclear how applicable editions are to this type of case or
    not
  • Engin (in chat): The compiler could use an internal function
    ('chpl_foo()') and the user-facing new feature can wrap it
    ('proc foo() do chpl_foo()') as a means of having something
    always available to the compiler even if it's not to the user.
    • some discussion between Daniel and Engin about how applicable this
      is to types, say
  • Lydia: Earlier, when David was talking about thoughts reviewing the
    API: Wanted to distinguish between early discussions about "Should
    this be in the standard modules at all vs. a mason package?" when
    adding a new module. That feels like it should happen early/first.
    Whether or not things become stable should be wrapped up in the
    edition portion.
  • Daniel: Understands need for review process, but it would be a shame
    if David wrote a utility, it's useful, we use it internally, and we
    get stuck not being able to expose it. Something is better than
    nothing, even if that something is not ideal. Specific David case
    is that there's code he wants to use in the standard modules for
    dynamic loading, so it's going to be there somewhere...
  • Lydia/Brad: You seem to be anticipating a big barrier within this
    group when new features are brought forward, but that doesn't seem
    like a characterization of how this group and meeting usually
    reviews things. People generally seem pretty open and supportive
    of cool new things rather than sitting around with arms folded
    not letting anything in. [Giving a demo or leading a discussion
    should not be considered onerous -- more like part of how we do
    development and generate consensus on, and awareness of, efforts]
  • Daniel: Will circle back to David to discuss candidates and bring
    one back next week as a trial run.

Post-meeting

Office Hours / Q&A

TODOs / Open Issues