Chapel project meeting: 2025-10-28 (agenda items, meeting link, notes)

[github-actions[bot]]

This discussion is for the weekly Chapel project meeting.

Date/Time: 2025-10-28 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 have a demo of a new feature for --print-passes to track memory usage

[jabraham17]

I would like to try and reach consensus on #27615

[e-kayrakli]

I can do another demo for the new Parquet mason package effort.

[lydia-duncan]

Here's today's user issues report

[bradcray]

Agenda / Notes

News/Announcements

• new logo design updates:

  • trying to get new logo in time for SC25 announcements about HSPF
  • requested designs from public, but received none, likely due to short fuse
  • have engaged the Linux Foundation designers to develop concepts
    Q: Have we announced submissions are closed?
    A: Deadline was stated in announcements and we've closed the form
  • Lydia didn't propose sending in her concept to avoid leveraging her role

• "Technology Now" podcast will be airing a Chapel episode this week (Thursday)

  • https://www.hpe.com/us/en/discover-more-network/podcasts/technology-now.html

Triage Status

• DavidL: end-of-rotation update
  • lots of disconnects yesterday due to jenkins reconfig
  • main things outstanding:
    • correctness tests failing due to FCP changes (DavidL)
    • dwarf dump atomics failure outstanding (due to code reordering?) (DavidL)
    • miniMD times out frequently lately (3x over weekend)
    • many-to-one is still failing (suppress?) (Brad)
    • sort case timeouts across arkouda configs (or sometimes setopts?)
      Q: Have we been talking about the Arkouda devs about this? Would be
      a way to keep them informed and sounded like they wanted to hear
      about it.
      A: Engin will ping her
  • EX testing, linux32 testing, apptainer testing down for a bit due to infra.

User Issues

• Lydia: weekly report
  • 1 new issue opened -- a perf question from Thitrin based on chapelcon/blog
  • 4 closed issues due to Daniel cleaning house
  • in-progress:
    • Daniel looking at older internal error
    • 3 PRs open from bkmgit needing some attention; holding up release
      • Jade: not sure PRs should hold up a release
      • Lydia: would be nice to test after mod goes in
      • Jade: doesn't think it should affect our test infrastructure nor hold
        up a release; can generate a release
      • [bkmgit joined at this point]
      • Lydia: Wants to discuss what should be done to streamline external PRs
        • not sure whether TSC or this meeting is better
        • Brad: Thinks probably this meeting, at least for starters
        • Lydia: Will queue it up as a topic for next week
      • Jade: W.r.t. DCO being a blocker, how would we fix that?
      • Lydia: Used to have a signed contributor agreement; was eaier to "fix"
        for people than missing a commit on their branch. DCO requires
        more familiarity with git processes, etc. Feels like it's been more
        of a barrier than ideal.
      • Jade: DCO vs. CLA are two different legal mechanisms, so can't
        necessarily swap one for the other. But let's table this for now.
      • bkmgit: DCO stuff seems OK for the main code; expecting people
        to rebase seems reasonable. May be more of a barrier for
        documentation changes where people may not be as familiar with
        git. A CLA is also OK. The paper ones tend to be more
        cumbersome than cases where companies offer services for that,
        like acknowledging through git username, say. But once you
        need name of contributor, origin, etc. that may require more
        process than just having a github bot.

Demos

• Jade: '--print-passes' extension to print memory usage

  • added new flag extending '--print-passes' to include memory usage
    • prints how much additional memory was allocated by each pass as
      reported by the OS
      • one implication is that passes that free memory only turn it back
        over to the allocator, not the OS, so we won't see negative values
      • similarly, a pass that allocates memory that's fulfilled by a
        previously freed block will not show that memory be accounted
    • also adds a new, third, block of summary info, sorted by memory use
    • current two highest-mem passes are parseAndConvert and resolve
  • useful when making changes to the compiler to see if changes you think
    will improve memory usage actually do so

• Engin: Parquet mason package manager

  • follow-up from last week's demo
    • prototype Parquet module / package for mason
    • last week showed some testing output
  • given mason and spack on a system, shows that compiling demo is missing pkg
  • using 'mason build', it will check for an arrow package from spack, and
    install it if not
  • then will build C++ prereqs of the Parquet package and grab package itself
  • then 'mason run' will correctly run the test
  • ready to open PRs for these, and will probably pause on this effort there
    • a mason PR
    • a Parquet PR
    • a mason registry PR
    • an Arkouda PR

Discussion Topics

• Jade: seeking consensus on --debug flag / optimization topic
  • proposal
    • add a new flag to disable a given set of optimizations
    • rename '--debug' to '--debug-symbols' (also '-g')
    • add a new '--debug' flag that throws '-g' and the new flag
  • big question then is naming of flag:
    • candidates:
      --optimized-debug
      --debugging-opts
      --debugging-optimizations
      --debug-safe-opts
      --debug-safe-opts-only
      --debug-friendly-opts
      --debug-optimizations
      --debug-transforms
    • Lydia: Thinks it's OK for it to be long/verbose b/c a user
      won't be typing it frequently, but hopefully recognizable so
      a user can identify it
    • Daniel: hasn't read github issue, but... --debug-safe-opts-only
      is the only one that telegraphs that things are being disabled,
      so it feels like a clear choice. Though he would spell out
      optimizations to avoid confusion with "options".
    • Lydia: Agrees with characterizations and spelling out longhand.
    • Jade: Notes that not all of these things are technically optimizations
    • Brad: Is the ambiguity Daniel points out so bad? The optimizations
      are controlled by options
    • Daniel: Thinks if we have an intention, we should make that intention
      clear. OK with calling it "optimizations" even though it's not only
      optimizations. Even "safe" is not terribly precise. But alternatives
      are too verbose. Some degree of imprecision is OK, but doesn't want
      to be guessing what an abbreviation is meant to represent.
    • Lydia: Likes longer name, but doesn't think opts vs. optimizations is
      a big deal, and a good flag description can help with this
    • Lydia: To Daniel's point, if we're concerned about
      distinguishing between options and optimizations in the future
      then that'd be a definite reason to spell it out. Doesn't
      expect that to happen, so would be OK with safe-opts on that
      basis.
    • Engin (chat): Views this as a developer flag
    • [went to voting somewhere in here]
    • straw poll followed by vote led to '--debug-safe-optimizations-only'

Post-meeting

Office Hours / Q&A

TODOs / Open Issues