chapel-education — Discussion about use of Chapel in classes/educational settings

Year-end reminder: switch to Chapel Discourse

[Brad C. <bra...@hp...>]

Hello Chapel Community —

This is a final reminder for 2020 that we're in the process of retiring 
these SourceForge-based Chapel mailing lists in favor of our new Discourse 
site:

 	https://chapel.discourse.group/

If you are interested in keeping in touch with the Chapel community, 
please be sure to register there, as these mailing lists will be going 
away very soon.

Since my last message:

* We've made the Discourse site publicly readable such that you don't need
   to register to browse its contents (though you still do to post)

* We've posted some instructions on how to use Discourse like a mailing
   list, which can be used to recreate the experience of these mailing
   lists for those who aren't attracted to web-based forums:

 	https://chapel.discourse.group/t/welcome-to-the-chapel-programming-language-discourse-page/8

* We've added the ability to sign into the site using your GitHub
   credentials to avoid having to create a new account from scratch.


Best wishes for the end of 2020 and the start of the new year,
-Brad

Missing out on Chapel news? (new release, Bossies, PACT'20 keynote)

[Brad C. <bra...@hp...>]

Hi Chapel Community —

This is a second reminder that if you feel like it's been a bit too quiet 
here recently, remember that we're in the process of replacing the Chapel 
mailing lists with our new Discourse site:

 	https://chapel.discourse.group/

In particular, steer yourself towards the "Announcements" category 
(https://chapel.discourse.group/c/announcements) to catch up on recent 
news like:

* Highlights of today's Chapel 1.23.0 release

* Chapel being named a 2020 Bossie Award winner

* How to watch my keynote on "Compiling Chapel" from PACT'20 last week


We hope to see you there!
-Brad

Chapel mailing lists changing to Discourse

[Brad C. <bra...@hp...>]

Dear Chapel mailing list subscribers —

After years of talking about it but failing to act, we've finally started 
the process of retiring Chapel's SourceForge-hosted mailing lists (the 
ones where you're receiving this message) in favor of a more modern, 
ad-free way of supporting discussions within the community via email or 
the web.  Specifically, we've launched a Chapel Discourse site.

If you're not familiar with Discourse, it's a web-based technology for 
discussions that can be used both from a browser or in more of a mailing 
list mode.  Discourse supports 'topics' sorted into 'categories' where you 
can think of:

* topics = an email thread or a discussion thread on a web forum
* category = like a mailing list or a tag/folder on a web forum

We invite and encourage everyone subscribed here to register and to join 
us for further discussion about Chapel at:

 	https://chapel.discourse.group/

Once you've registered, I suggest:

* taking a look at the 'Categories' tab, which is a good way to get an
   overview of the site, particularly if you're coming from a mailing list
   mindset:

 	https://chapel.discourse.group/categories

   Each top-level category should have a pinned "about this category" post
   that's intended to describe what it's for and how you can post to it via
   email, once registered.

* Decide which categories you want to follow or mute.

* Take a moment to introduce yourself to the community:

 	https://chapel.discourse.group/t/introduce-yourself/

* Send us your questions and feedback in the "site feedback"
   category:

 	https://chapel.discourse.group/c/site-feedback



At some point this fall, we will be disabling the SourceForge mailing 
lists, but for a time, we'll keep both forums going while people work on 
converting over.


Looking forward to further Discourse with you,
-Brad (on behalf of the Chapel team at HPE)

PAW-ATM submission deadline: one month away

[Brad C. <bra...@hp...>]

Hi Chapel Community —

For those doing applications work in Chapel (or another alternative to 
MPI+X), this is a quick reminder that the deadline for talk and paper
submissions is one month away:  https://sourceryinstitute.github.io/PAW/

-Brad

************************************************

                  PAW-ATM 2020:

         Parallel Applications Workshop,
             Alternatives To MPI+X

           Monday, November 16th, 2020

    Held in conjunction with SC20, Atlanta, GA

    <http://sourceryinstitute.github.io/PAW/>

************************************************

CHIUW 2020 wrap-up / PAW-ATM 2020 CFP

[Brad C. <bra...@hp...>]

Hi all —

CHIUW 2020
----------
First, thanks to everyone who attended CHIUW 2020 online the other week. 
We had a good turnout with:

* ~50 people on average per talk
* a high water mark of ~70 during Bill Reus's excellent keynote on Arkouda
* over 100 unique emails registered to attend during the day

If you missed the event, slides and videos of the talks and Q&A sessions 
are available online at the CHIUW 2020 program page:

 	https://chapel-lang.org/CHIUW2020.html

or via the following YouTube playlist:

 	https://www.youtube.com/playlist?list=PLuqM5RJ2KYFjS9vl-GLdmvrIm4uD_l3Ta


PAW-ATM 2020
------------
Next, if you are programming with Chapel, please consider submitting a 
paper or talk to PAW-ATM 2020, a workshop at SC20 that focuses on 
applications work being done in alternatives to MPI+X programming like 
Chapel.  Submissions are due on July 24, and more information about 
PAW-ATM and the submission process can be found on its website here:

 	https://sourceryinstitute.github.io/PAW/

Thanks and best wishes,
-Brad

CHIUW 2020: Final Details

[Brad C. <bra...@hp...>]

Hi Chapel Community —

As a reminder, CHIUW 2020 is taking place this Friday (May 22) in a free, 
public, online format.  We hope you will be able to join us for some or 
all of the day's talks.  Here are some details in a Q&A format:


What is CHIUW?
--------------
CHIUW is the annual Chapel Implementers and Users workshop, designed to 
bring Chapel programmers and developers together to share recent progress 
and results.  CHIUW 2020 represents the 7th annual instance of the 
workshop series.


Online and free you say?
------------------------
Due to Covid-19, CHIUW 2020 will be held online as a Zoom webinar, with 
options to listen in by phone or a few other technologies.  The workshop 
will be open to the public and free of charge.  Anyone who is interested 
in Chapel or parallel programming is welcome to attend, given reasonable
conduct.


Do I need to register?
----------------------
There is no firm requirement to register for CHIUW 2020, however there are 
a few reasons to consider doing so:

a) It gives IPDPS (the conference with which CHIUW is associated) a sense
    of the level of interest in CHIUW

b) It gains you access to the IPDPS online proceedings including the
    papers and abstracts associated with the CHIUW presentations

c) It's free

To register, go to the IPDPS homepage (http://www.ipdps.org/) and click 
the red "Register Today" button in the upper right.


How do I join the workshop?
---------------------------
On the morning of CHIUW 2020, the workshop website will be updated to 
include links to the Zoom meeting and other methods of joining.


Where is the CHIUW 2020 website?
--------------------------------
https://chapel-lang.org/CHIUW2020.html


What will the format of CHIUW 2020 be?
--------------------------------------
The bulk of the day will be made up of 10-20 minute talks from the Chapel 
community describing recent efforts with Chapel.  Some of these talks will 
be given live while others will be pre-recorded and streamed over the 
meeting (or you can watch them simultaneously via YouTube).  Each talk 
will wrap up with a short, live Q&A session.

A highlight of the day will be a keynote talk by Bill Reus (US DOD) on 
"Arkouda: Chapel-Powered, Interactive Supercomputing for Data Science".
The workshop will kick off with a "State of the Project" talk and wrap up 
with an open discussion session.

To keep things moving, there won't be any formal meal breaks or extended 
breaks during the day, though there are scheduled pauses to deal with 
technical issues and give people a chance to stretch or grab a snack.


What's the schedule?
--------------------
The workshop kicks off at 8:30am PDT, and the full schedule is online at: 
https://chapel-lang.org/CHIUW2020.html


Is there anything I should do to prepare?
-----------------------------------------
If you're new to Chapel, or need a refresher, you might want to listen to 
the "Chapel 101" presentation that's already linked on the workshop 
website as background.


How can I find out more?
------------------------
If you have any additional questions, don't hesitate to ask me.


Hope to "see" you on Friday,
-Brad Chamberlain, on behalf of the CHIUW organizing committee

CHIUW 2020: Online, Free, May 22

[Brad C. <bra...@hp...>]

Hi Chapel Community —

Due to the Covid-19 pandemic, CHIUW 2020 will be held in an online, 
virtual workshop format on its original date of next Friday May 22. 
There will be no registration fee to participate, and anyone interested in 
Chapel is welcome to attend for some or all of the day.

Highlights of CHIUW 2020 will include:

* a keynote talk entitled "Arkouda: Chapel-Powered, Interactive
   Supercomputing for Data Science" by Dr. Bill Reus (U.S. DOD)

* submitted presentations representing 4 countries, 3 continents, and 11
   organizations on:

   - Chapel feature improvements
   - Chapel optimizations
   - Applications of Chapel:
     o Computational Fluid Dynamics
     o [Hyper]graph Computations
     o Ultralight Dark Matter

* our annual "State of the Chapel Project" talk

* opportunity for community discussion (technology willing)

For more information, please refer to the CHIUW 2020 website at:

 	https://chapel-lang.org/CHIUW2020.html

We hope to see you there/online!

On behalf of the CHIUW 2020 organizing committee,
-Brad Chamberlain

Announcing Chapel 1.22!

[Brad C. <bra...@hp...>]

Dear Chapel community --

Cray, a Hewlett Packard Enterprise Company, and the Chapel open-source 
community are proud to announce the release of Chapel version 1.22!

This is the second of two Chapel releases that we are making this
month.  Last week's Chapel 1.21 was our typical semi-annual release
containing numerous feature and performance improvements, all of which
are part of Chapel 1.22 as well.

Today's Chapel 1.22 release focuses primarily on a single conceptual
change: that of making Chapel's implicitly indexed types use 0-based
rather than 1-based indexing.  This impacts tuples, strings, bytes,
lists, and inferred-type arrays that are not defined in terms ranges,
domains, or other arrays.  It also impacts language features and
library interfaces that are defined in terms of these types, such as
varargs functions, per-dimension queries of arrays, or search
functions on these types that return position values.

For a more in-depth description of these changes, how we got here, or
tips for updating existing Chapel programs to be compatible with 1.22,
please refer to:

       https://chapel-lang.org/docs/1.22/language/evolution.html

In addition, if you would like help updating to Chapel 1.22 and are
able to share your code with us, please don't hesitate to ask—we'd be
happy to help.

Beyond this major change, Chapel 1.22 also contains a few other
improvements in terms of memory leaks, documentation improvements, and
bug fixes.  For a more complete list of changes, including pointers to
supporting documentation, please refer to CHANGES.md within the
release or online:

   https://github.com/chapel-lang/chapel/blob/release/1.22/CHANGES.md

To download and install the release, see:

   https://chapel-lang.org/download.html

And for a list of everyone who contributed to Chapel 1.22, please see:

   https://github.com/chapel-lang/chapel/blob/release/1.22/CONTRIBUTORS.md

As always, we're interested in feedback on how we can make the Chapel
language, implementation, libraries, and tools more useful to you.

On behalf of the Chapel project,
-Brad Chamberlain


------------------------------------
For further information about Chapel
------------------------------------

Whether you're a user of Twitter or Facebook, or would simply enjoy
checking in on us from time-to-time, Chapel's social media pages have
a reasonably steady stream of content about the project and language:

    https://twitter.com/ChapelLanguage
    https://www.facebook.com/ChapelLanguage

Our development repository is hosted at GitHub, making it the best
place to track, or contribute to, ongoing Chapel development:

    https://github.com/chapel-lang/chapel

The Chapel website can be found at:

    https://chapel-lang.org

and it remains the best place to find Chapel-related information such
as videos, papers, presentations, blog posts, and tutorials.

Announcing Chapel 1.21.0!

[Brad C. <bra...@hp...>]

Dear Chapel community --

Cray, a Hewlett Packard Enterprise Company, and the Chapel open-source
community are proud to announce the release of Chapel version 1.21!

[Mac users: the Homebrew formula is still working its way through the
system... see https://github.com/Homebrew/homebrew-core/pull/52790 ]

This is the first of two releases that we will be making this month.
Chapel 1.21 is our typical semi-annual release containing numerous
feature and performance improvements.  Chapel 1.22 will focus on
changing Chapel's implicitly indexed types to 0-based indexing from
Chapel's historical choice of 1-based.  We recommend that users with
existing Chapel code incrementally upgrade to version 1.21 before 1.22
in order to ease the transition.

Chapel 1.21 includes the following highlights, many of which support
our goal of stabilizing Chapel's core features for a forthcoming
Chapel 2.0 release:

* Chapel's modules and namespaces have improved in a number of ways,
   including:

   - the addition of a new `import` statement that provides a more
     precise way of referring to a module's contents

   - a new ability to rename modules when they're used via `as` (e.g.,
     `use MyLongModuleName as M;`)

   - prototypical support for storing a module's sub-modules in their
     own files

   - reduced bleeding of symbols between modules by making `use`
     private by default and leveraging it in Chapel-provided modules

* Chapel strings are now validated to ensure that they are UTF8, and
   the `bytes` type has been improved to be a true peer to strings.

* Chapel now supports split initialization of variables, constants,
   types, params, and refs, which permits the declaration of a symbol
   to occur in a distinct statement from its initialization.

* We added several features that support a more index-neutral style of
   programming, such as support for looping over heterogeneous tuples
   and a `.indices` query for most collection types.

* This release also contains several new performance improvements and
   optimizations including:

   - better performance and scalability when creating distributed
     domains and arrays

   - improvements to the unordered operation optimization and its
     associated `unorderedCopy()` routine

   - optimized `on`-statement performance for InfiniBand networks

   - improved performance (and correctness) of mis-aligned `ugni` data
     transfers

* The language specification has been converted from PDF to HTML to
   better integrate it with Chapel's other online documentation (see
   https://chapel-lang.org/docs/language/spec/index.html)

* The `ofi`/libfabric implementation of the runtime has improved in
   terms of functionality, portability, and performance.

In addition, Chapel 1.21 contains many other feature enhancements, bug
fixes, and documentation improvements.  For a far more complete list
of changes, including pointers to supporting documentation, please
refer to CHANGES.md within the release or online:

   https://github.com/chapel-lang/chapel/blob/release/1.21/CHANGES.md

To download and install the release, see:

   https://chapel-lang.org/download.html

And for a list of everyone who contributed to Chapel 1.21, please see:

   https://github.com/chapel-lang/chapel/blob/release/1.21/CONTRIBUTORS.md

As always, we're interested in feedback on how we can make the Chapel
language, implementation, libraries, and tools more useful to you.

On behalf of the Chapel project,
-Brad Chamberlain


------------------------------------
For further information about Chapel
------------------------------------

Whether you're a user of Twitter or Facebook, or would simply enjoy
checking in on us from time-to-time, Chapel's social media pages have
a reasonably steady stream of content about the project and language:

    https://twitter.com/ChapelLanguage
    https://www.facebook.com/ChapelLanguage

Our development repository is hosted at GitHub, making it the best
place to track, or contribute to, ongoing Chapel development:

    https://github.com/chapel-lang/chapel

The Chapel website can be found at:

    https://chapel-lang.org

and it remains the best place to find Chapel-related information such
as videos, papers, presentations, blog posts, and tutorials.

Re: CHIUW submission deadline: extended by a week

[Brad C. <bra...@hp...>]

Hi Chapel community —

Just a final reminder that the deadline for CHIUW submissions is tomorrow. 
For details, see:

 	https://chapel-lang.org/CHIUW2020-cfp.html

-Brad


On Fri, 31 Jan 2020, Brad Chamberlain wrote:

>
> Hello Chapel community —
>
> I haven't had the chance to update everything yet, but by request, we'll be 
> extending the CHIUW submission deadline by one week, with no further 
> extensions available.  If your submission isn't already done, please take 
> this opportunity to polish it further, or to submit something if you didn't 
> think you'd have time to.
>
> Best wishes,
> -Brad
>
>
> Brad Chamberlain  Principal Engineer
> Cray, a Hewlett Packard Enterprise company
> 901 Fifth Ave, Suite 1000 | Seattle, WA 98164
> +1-206-701-2077  bra...@hp...  www.cray.com
>

CHIUW submission deadline: extended by a week

[Brad C. <bra...@hp...>]

Hello Chapel community —

I haven't had the chance to update everything yet, but by request, we'll 
be extending the CHIUW submission deadline by one week, with no further 
extensions available.  If your submission isn't already done, please take 
this opportunity to polish it further, or to submit something if you 
didn't think you'd have time to.

Best wishes,
-Brad


Brad Chamberlain  Principal Engineer
Cray, a Hewlett Packard Enterprise company
901 Fifth Ave, Suite 1000 | Seattle, WA 98164
+1-206-701-2077  bra...@hp...  www.cray.com

Reminder: CHIUW 2020 deadline approaching

[Brad C. <bra...@hp...>]

Hi Chapel community —

This is a quick reminder that the deadline for CHIUW 2020 submissions is 
fast approaching, on January 31st.

As in past years, CHIUW will accept full research papers (up to 10 pages) 
and talk-only submissions (1 page).  In addition, this year adds a new 
short paper option (4 pages).

For further details, please refer to the website:

 	https://chapel-lang.org/CHIUW2020-cfp.html

Hope to hear about your work!
-Brad

CHIUW 2020: Call for talks and papers

[Brad C. <br...@cr...>]

Hi Chapel community —

The 7th annual Chapel Implementers and Users Workshop (CHIUW) will take 
place on May 22-23, 2020 in New Orleans, LA as part of IPDPS 2020.  If you 
are doing work with Chapel, or that would be of interest to the Chapel 
community, we highly encourage you to submit a paper or talk to CHIUW in 
order to let the broader community hear about your efforts.  Papers are 
expected to describe novel, previously unpublished work; talks can either 
describe work that is novel, or that you have previously published 
elsewhere.

The deadline for submissions is January 31, 2020.

For additional details about CHIUW 2020 and submissions to it, please 
refer to the call for papers and talks at:

 	https://chapel-lang.org/CHIUW2020-cfp.html

On behalf of the CHIUW 2020 committee,
-Brad

---

Brad Chamberlain  Principal Engineer
Cray, a Hewlett Packard Enterprise company
901 Fifth Ave, Suite 1000 | Seattle, WA 98164
+1-206-701-2077  br...@cr...  www.cray.com

Chapel at SC19

[Brad C. <br...@cr...>]

Hi Chapel Community —

We wanted to make sure you were aware of a few key Chapel-related 
activities at SC19 for those who will be attending:

The main event is the PAW-ATM 2019 workshop, all day on Sunday, November 
17th.  There were two Chapel-related presentations at the workshop:

* Nikhil Padmanabhan (Yale) will be presenting "Simulating Ultralight Dark
   Matter with Chapel: An Experience Report"

* Mike Merrill (DOD) will be presenting on his recently open-sourced
   project, "Arkouda: NumPy-like arrays at massive scale backed by Chapel"
   (Even if you're not attending SC, you'll want to be sure to check
   Arkouda out at https://github.com/mhmerrill/arkouda)

In addition, Michael Ferguson will be serving as a panelist in the closing 
session, and I'll be giving a quick introduction to the workshop and area 
at the start of the day.  Details on PAW-ATM can be found on its website:

 	https://sourceryinstitute.github.io/PAW/


After the workshop, we hope you can join us for our 10th annual (!) CHUG 
(Chapel Users Group) meet-up.  The current plan is to head over to Rhein 
Haus, Denver after things wrap up, so arriving around 6:15pm or so.  Join 
us for drinks, dinner, discussion, and possibly even bocce (!?).

Keep an eye on Chapel's Twitter or Facebook feeds for further updates.


Best wishes, and we hope to see several of you at SC19,
-Brad


---

Brad Chamberlain  Principal Engineer
Cray, a Hewlett Packard Enterprise company
901 Fifth Ave, Suite 1000 | Seattle, WA 98164
+1-206-701-2077  br...@cr...  www.cray.com

Announcing Chapel 1.20!

[Brad C. <br...@cr...>]

Dear Chapel community --

Cray Inc. and the Chapel open-source community are proud to announce
the release of Chapel version 1.20!

[Homebrew users: note that 1.20 is not yet available via homebrew, but
hopefully will be soon. If this is a hassle for you, upvote the PR

       https://github.com/Homebrew/homebrew-core/pull/44425

in hopes of moving it along...]

Chapel 1.20 includes the following highlights:

* Chapel's `string` type now supports UTF-8 codepoints rather than
   just ASCII characters.  In addition, a new `bytes` type with
   corresponding literals (e.g., b"here are some bytes") has been added
   to support arbitrary byte strings.

* For a class `C`, Chapel now distinguishes between variables that can
   store `nil` (using `C?`) and those that cannot (using `C`).  A new
   postfix `!` operator supports non-nil assertions for nilable `C?`
   variables.

* The memory management flavors on classes have been improved so that
   an undecorated class type `C` is now generic with respect to memory
   management type, where before it was treated as `borrowed C`.
   Undecorated `new C()` now defaults to `new owned C()`.  Argument
   passing has also been improved for managed classes to avoid some
   tricky cases.

* Chapel now supports partial instantiations of generic types.
   Uninstantiated and partially instantiated generic types can also now
   be passed to, or returned from, procedures as type arguments.

* To improve namespace sanity, module-level `use` statements can now
   be marked `private` to prevent symbols from becoming visible outside
   of the module.  In addition, top-level modules must now be `use`d
   before their names or contents can be referenced.

* New `list`, `set`, and `map` types have been introduced to support
   standard collections with familiar interfaces.  Related, list-like
   operations on 1D arrays and map-like operations on associative
   arrays have been deprecated in favor of these new types.

* Chapel now supports the creation of multi-locale libraries that can
   be called from Python or C, as well as the ability to pass or return
   strings from exported routines in Chapel libraries.

* A new `UnitTest` module has been added to support unit testing, and
   is also available via the mason package manager's `test` command.

* Several new performance optimizations and enhancements have been
   made including:
   - improved affinity and performance of parallel loops
   - optimized bulk transfers for Block-distributed arrays
   - compiler-generated unordered operations and improved performance
     for unordered operations
   - parallel scans on 1D local and block-distributed arrays
   - improved performance for parallel-safe data structures

* Improvements to the `mason` package manager in terms of testing,
   publishing, searching, and working offline.

* New `Reflection` routines support reasoning about the filename, line
   number, module, or function name of a given line of source code.

* The user-facing interfaces for `atomic` types have been improved and
   normalized.

* Support for libfabric providers has been improved in terms of
   completeness and portability, using the CHPL_COMM=ofi setting.

* A new `none` type with a corresponding `nothing` value is now
   supported to avoid the two interpretations of `void` that had
   previously existed in Chapel.

* A new `EpochManager` package has been added that supports concurrent
   memory reclamation.

* Support for the LLVM compiler back-end has improved.

* We have also improved compiler errors for failures when resolving
   functions and for generic routines.

* An initial Chapel module has been created for Cray Shasta systems
   and is expected to be available as those systems begin shipping to
   customers.


And of course, Chapel 1.20 contains many other feature enhancements,
bug fixes, and documentation improvements.  For a far more complete
list of changes including pointers to supporting documentation, please
refer to CHANGES.md within the release or online:

   https://github.com/chapel-lang/chapel/blob/release/1.20/CHANGES.md

To download and install the release, see:

   https://chapel-lang.org/download.html

And for a list of everyone who contributed to Chapel 1.20, please see:

   https://github.com/chapel-lang/chapel/blob/release/1.20/CONTRIBUTORS.md

As always, we're interested in feedback on how we can make the Chapel
language, implementation, libraries, and tools more useful to you.

On behalf of the Chapel project,
-Brad Chamberlain


------------------------------------
For further information about Chapel
------------------------------------

Whether you're a user of Twitter or Facebook, or would simply enjoy
checking in on us from time-to-time, Chapel's social media pages have
a steady stream of content about the project and language:

    https://twitter.com/ChapelLanguage
    https://www.facebook.com/ChapelLanguage

Our development repository is hosted at GitHub, making it the best
place to track, or contribute to, ongoing Chapel development:

    https://github.com/chapel-lang/chapel

The Chapel website can be found at:

    https://chapel-lang.org

and it remains the best place to find Chapel-related information such
as videos, papers, presentations, blog posts, and tutorials.

Re: [Chapel-developers] Chapel 1.20: Offer to help with nilability changes

[Brad C. <br...@cr...>]

Hi Louis —

I think this gets back to your original question which I skipped hoping 
one of the experts would weigh in...  I can't find the original mail (even 
in the online archives... that's odd), but I believe you asked whether 
there was a way to turn off execution-time checks from '!', e.g. in --fast 
/ --no-checks mode?  I think that question is still being debated here:

 	https://github.com/chapel-lang/chapel/issues/13603

> (there is some additional logic that must be performed after obtaining 
> the recycled node and so we cannot return immediately).

Even if you can't return immediately, you could do the following, since 
the initial assignment to `n` would be non-nil if its declaration was 
moved into the try block (noting that I've messed with your remove() API 
again... without that, you'd still need to use a '!' within the try block 
I think):

 	proc recycle(): unmanaged object {
 	  try {
 	    const n = recycleList.remove();
 	    ... do other stuff with n, just not setting it to nil ...
 	    return n;
 	  } catch exception {
 	    return new unmanaged object();
 	  }
 	}

-Brad




On Sat, 24 Aug 2019, Louis Jenkins wrote:

> The `list.remove` function takes a reference and throws when empty (it's 
> the new standard module), but anyway, the example was more or less a 
> simplified version of actual code being used (there is some additional 
> logic that must be performed after obtaining the recycled node and so we 
> cannot return immediately).
>
> Thank you for informing me that the `!` operator does away with the 
> nil-able type, but is it possible to elide the nil-check here? This is 
> additional overhead that can still be avoided in the recycle list 
> example. If an additional branch is added to a critical path when it can 
> be avoided, it can end up being very undesirable.
>
> Get Outlook for Android<https://aka.ms/ghei36>
>
> ________________________________
> From: Brad Chamberlain <br...@cr...>
> Sent: Saturday, August 24, 2019 1:07:46 AM
> To: Louis Jenkins <Lou...@ho...>
> Cc: Chapel Users Mailing List <cha...@li...>; Chapel Sourceforge Developers List <cha...@li...>; Chapel Educators Mailing List <cha...@li...>
> Subject: Re: [Chapel-developers] Chapel 1.20: Offer to help with nilability changes
>
>
> Hi Louis —
>
> I think there are a few options here (and probably others that the experts
> could suggest... in this case, I'm mostly a messenger who's just trying
> these features out for the first time today as well, so still picking up
> some tricks as I go).
>
> First an assumption: I take it that `recycleList.remove(n)` is going to
> store the thing that's removed in `n`?  (i.e., `n = recycleList.remove();`
> might be another way to express it showing the assignment?)
>
> The first way to write this pattern that occurs to me is as follows, where
> I'm going to take the above liberty with reframing the recycleList API:
>
> proc recycle(): unmanaged object {
>   try {
>     return recycleList.remove();
>   } catch exception {
>     return new unmanaged object();
>   }
> }
>
> Here, both branches return a non-nilable unmanaged object (assuming
> remove() does when it doesn't throw), so things are fine.
>
> Another way would be to use the '!' operator (and here I'll revert to the
> original API to avoid cheating):
>
> proc recycle(): unmanaged object {
>   var n: unmanaged object?;  // this needs to use ? since n will
>                              // initially be nil
>   try {
>     recycleList.remove(n);
>   } catch exception {
>     n = new unmanaged object();
>   }
>   return n!;  // will halt if 'n' is nil, but you've assured me it won't
> }
>
> Note, however, that if the try block throws an exception that doesn't
> match your exception pattern, 'n' will be 'nil' and the ! operator will
> fail.
>
> I think a third approach would be to cast 'n' to 'unmanaged object', but
> I'm not as expert at that approach yet (casting nilability away throws
> when the value is 'nil' whereas '!' halts).
>
>
> To your larger point, though, I think you're correct that nilability can't
> be proven correct by a compiler in all cases (I suspect its equivalent to
> the halting problem), so we do what compilers typically do:  Be
> conservative when we can't be sure and rely on the user to help out in
> such cases.
>
> That said, note that checking nilability in Chapel is more about making
> sure that you don't assign a `nil` or a `C?` to a `C` without first doing
> something to convert it safely (like the '!' operator or a cast).  And
> less about trying to infer whether something is assigned non-nil values
> along all paths or not.
>
> -Brad
>
>
> On Sat, 24 Aug 2019, Louis Jenkins wrote:
>
>> **Memory/Object Pool Pattern**
>>
>> If I know for a fact that a function will always return an object that
>> is not nil, such as the case of an object pool that will create a new
>> object if an object cannot be recycled, how do you represent this with
>> the new changes? It seems that the compiler cannot be determine if the
>> nil-ability of an object can be proven statically, such as the case in
>> the below code snippet; the compiler _could_ see that, in any and all
>> paths, it is impossible for `n` to be `nil`, and is therefore not
>> nil-able; a lot of static analyzers are capable of performing such
>> analysis as well. Would this be considered something 'impossible' to do
>> from a design standpoint, or would this be something that is planned to
>> be supported? If not, how do you prevent nil-ability tainting
>> everything? Is it planned to be able to say to the compiler: "I know
>> that this is not nil-able after this point, please stop interfering with
>> my code?" - I kid, I kid, but really, is there a way to tell it that
>> something is non-nilable after a point?
>>
>> """
>> use List;
>>
>> var recycleList : list(unmanaged object);
>> proc recycle() : unmanaged object {
>>    var n : unmanaged object; // ???
>>    try {
>>        recycleList.remove(n);
>>    } catch exception {
>>        n = new unmanaged object();
>>    }
>>    return n;
>> }
>>
>> var x = recycle();
>> writeln(x);
>> """
>>
>>
>> On 8/23/19, 8:20 PM, "Brad Chamberlain" <br...@cr...> wrote:
>>
>>
>>    I'll answer the parts of this I remember the answers to offhand and leave
>>    the rest for others:
>>
>>   > What would an array of `var A : [D] C` contain by default?
>>
>>    This would be an error (assuming a semicolon after the 'C' rather than an
>>    `= ...`, as would `var A: C;` However, I believe at present, the compiler
>>    only checks the latter, not the former (i.e., there's still a TODO here).
>>
>>
>>   > Why not make all types nil-able by default and make nil-ability an
>>   > opt-in feature?
>>
>>    That is a potential consideration for the future (but is not considered a
>>    breaking change since no other types are currently nilable).
>>
>>    -Brad
>>
>>
>>
>>
>

Re: [Chapel-developers] Chapel 1.20: Offer to help with nilability changes

[Brad C. <br...@cr...>]

Hi Louis —

I think there are a few options here (and probably others that the experts 
could suggest... in this case, I'm mostly a messenger who's just trying 
these features out for the first time today as well, so still picking up 
some tricks as I go).

First an assumption: I take it that `recycleList.remove(n)` is going to 
store the thing that's removed in `n`?  (i.e., `n = recycleList.remove();` 
might be another way to express it showing the assignment?)

The first way to write this pattern that occurs to me is as follows, where 
I'm going to take the above liberty with reframing the recycleList API:

proc recycle(): unmanaged object {
   try {
     return recycleList.remove();
   } catch exception {
     return new unmanaged object();
   }
}

Here, both branches return a non-nilable unmanaged object (assuming 
remove() does when it doesn't throw), so things are fine.

Another way would be to use the '!' operator (and here I'll revert to the 
original API to avoid cheating):

proc recycle(): unmanaged object {
   var n: unmanaged object?;  // this needs to use ? since n will
                              // initially be nil
   try {
     recycleList.remove(n);
   } catch exception {
     n = new unmanaged object();
   }
   return n!;  // will halt if 'n' is nil, but you've assured me it won't
}

Note, however, that if the try block throws an exception that doesn't 
match your exception pattern, 'n' will be 'nil' and the ! operator will 
fail.

I think a third approach would be to cast 'n' to 'unmanaged object', but 
I'm not as expert at that approach yet (casting nilability away throws 
when the value is 'nil' whereas '!' halts).


To your larger point, though, I think you're correct that nilability can't 
be proven correct by a compiler in all cases (I suspect its equivalent to 
the halting problem), so we do what compilers typically do:  Be 
conservative when we can't be sure and rely on the user to help out in 
such cases.

That said, note that checking nilability in Chapel is more about making 
sure that you don't assign a `nil` or a `C?` to a `C` without first doing 
something to convert it safely (like the '!' operator or a cast).  And 
less about trying to infer whether something is assigned non-nil values 
along all paths or not.

-Brad


On Sat, 24 Aug 2019, Louis Jenkins wrote:

> **Memory/Object Pool Pattern**
>
> If I know for a fact that a function will always return an object that 
> is not nil, such as the case of an object pool that will create a new 
> object if an object cannot be recycled, how do you represent this with 
> the new changes? It seems that the compiler cannot be determine if the 
> nil-ability of an object can be proven statically, such as the case in 
> the below code snippet; the compiler _could_ see that, in any and all 
> paths, it is impossible for `n` to be `nil`, and is therefore not 
> nil-able; a lot of static analyzers are capable of performing such 
> analysis as well. Would this be considered something 'impossible' to do 
> from a design standpoint, or would this be something that is planned to 
> be supported? If not, how do you prevent nil-ability tainting 
> everything? Is it planned to be able to say to the compiler: "I know 
> that this is not nil-able after this point, please stop interfering with 
> my code?" - I kid, I kid, but really, is there a way to tell it that 
> something is non-nilable after a point?
>
> """
> use List;
>
> var recycleList : list(unmanaged object);
> proc recycle() : unmanaged object {
>    var n : unmanaged object; // ???
>    try {
>        recycleList.remove(n);
>    } catch exception {
>        n = new unmanaged object();
>    }
>    return n;
> }
>
> var x = recycle();
> writeln(x);
> """
>
>
> On 8/23/19, 8:20 PM, "Brad Chamberlain" <br...@cr...> wrote:
>
>
>    I'll answer the parts of this I remember the answers to offhand and leave
>    the rest for others:
>
>    > What would an array of `var A : [D] C` contain by default?
>
>    This would be an error (assuming a semicolon after the 'C' rather than an
>    `= ...`, as would `var A: C;` However, I believe at present, the compiler
>    only checks the latter, not the former (i.e., there's still a TODO here).
>
>
>    > Why not make all types nil-able by default and make nil-ability an
>    > opt-in feature?
>
>    That is a potential consideration for the future (but is not considered a
>    breaking change since no other types are currently nilable).
>
>    -Brad
>
>
>
>

Re: [Chapel-developers] Chapel 1.20: Offer to help with nilability changes

[Brad C. <br...@cr...>]

I'll answer the parts of this I remember the answers to offhand and leave 
the rest for others:

> What would an array of `var A : [D] C` contain by default?

This would be an error (assuming a semicolon after the 'C' rather than an 
`= ...`, as would `var A: C;` However, I believe at present, the compiler 
only checks the latter, not the former (i.e., there's still a TODO here).


> Why not make all types nil-able by default and make nil-ability an 
> opt-in feature?

That is a potential consideration for the future (but is not considered a 
breaking change since no other types are currently nilable).

-Brad

Chapel 1.20: Offer to help with nilability changes

[Brad C. <br...@cr...>]

Hi Chapel Programmers —

As many of you may know from our State of the Project presentation at 
CHIUW 2019, one of the main things that the Chapel team is currently 
focused on is getting the language to the point that we can minimize, if 
not eliminate, backwards-breaking changes in future releases for a core 
set of language features.  To that end, we are working towards making next 
month's 1.20 release of Chapel the release candidate for what we've been 
referring to as Chapel 2.0.  You can read more about this concept in the 
slides from CHIUW:

 	https://chapel-lang.org/CHIUW/2019/CHIUW2019-Welcome-SoP.pdf


Getting to that release candidate and its intended feature set has 
necessarily involved some growing pains in the name of improving the 
language.  Examples from recent releases include the move from 
constructors to initializers, and the introduction of managed class types. 
This upcoming release features one more similarly significant change 
(along with several smaller ones), which is to distinguish between class 
variables that can store 'nil' and those that cannot.

Briefly, the idea behind this concept is as follows:  Historically, given 
a class 'C', a variable 'var myC: C = ...' could either store 'nil' or 
point to an object of type 'C'.  In the new world (enabled by default on 
master yesterday), a variable of type 'C' will not be able to store 'nil' 
by default.  Instead, the type specifier 'C?' indicates the case where a 
variable may refer to either 'nil' or an instance of 'C'.  New syntax like 
'myC!' can be used to assert/check that 'myC' is non-nil (halting if it's 
not).

Needless to say, this is a fairly large change for code that uses classes, 
although one that we think is worthwhile given that it promotes safer 
coding by default, can reduce the need for nil-checking in many cases, and 
increases awareness of where nil dereferences may occur at compile-time.

Given the impact of this change on Chapel code that uses classes, we 
wanted to offer up-front to help any users with transitioning their 
existing Chapel code from 1.19 to 1.20 — either by helping to work through 
the changes if your code can be shared, or by being even more available 
than usual to answer questions if not.

If this help would be of interest to you, please reply to this mail and 
let me know.

On behalf of the Chapel team at Cray,
-Brad Chamberlain

PAW-ATM extension / CHIUW survey

[Brad C. <br...@cr...>]

Hi Chapel community —

If you're preparing a paper or talk submission to PAW-ATM at SC19, hopefully 
you've heard that there has been an extension to the deadline until August 
15th.  If you haven't been considering a submission, but have applications work 
in Chapel that you'd like to talk about at this SC19 workshop, you've still got 
a few weeks to put an abstract or paper together:

 	https://sourceryinstitute.github.io/PAW/

Also, if you haven't taken our CHIUW survey, we'd be grateful to get your input 
in the next few days to let us know how to make our annual Chapel workshop more 
valuable and/or accessible to you:

 	https://forms.gle/AqjY1ebu2dneQUDc9

Best wishes,
-Brad

CHIUW survey

[Brad C. <br...@cr...>]

Hi Chapel community —

We've put together a short survey to gather input about how to maximize 
the value of CHIUW, our annual Chapel community workshop.  If you've 
attended CHIUW in the past or would like to attend it in the future, 
please consider taking a few minutes to give us your thoughts:

 	https://forms.gle/AqjY1ebu2dneQUDc9

Thanks,
-Brad


PS — Also, while I've got you, please keep in mind that the deadline for
      submissions to the PAW-ATM workshop at SC19 is coming up at the end
      of the month.  Details here:

 	https://sourceryinstitute.github.io/PAW/

Call for Papers/Talks: PAW-ATM at SC19

[Brad C. <br...@cr...>]

Hi Chapel Community —

Now that we're past CHIUW 2019, please keep in mind that the deadline for 
paper and talk submissions to the PAW-ATM workshop at SC19 is coming up in 
just over a month.  If you're doing applications work in Chapel (or other 
alternatives to MPI+X), please consider submitting something to PAW-ATM.

For further details see the PAW-ATM webpage online:

 	https://sourceryinstitute.github.io/PAW/

Or the call for papers below.

Best wishes,
-Brad


************************************************

                 Call for Papers

                  PAW-ATM 2019:

         Parallel Applications Workshop,
             Alternatives To MPI+X

    Held in conjunction with SC 19, Denver, CO
           In cooperation with TCHPC

    <http://sourceryinstitute.github.io/PAW/>
************************************************

Summary
-------

Supercomputers are becoming increasingly complex due to the prevalence of 
hierarchy and heterogeneity in emerging node and system architectures. 
As a result of these trends, users of conventional programming models for 
scalable high-performance applications increasingly find themselves 
writing applications using a mix of distinct programming models—such as 
Fortran90, C, C++, MPI, OpenMP, and CUDA—which are also often becoming 
more complex and detail-oriented themselves. These trends negatively 
impact the costs of developing, porting, and maintaining HPC applications.

Meanwhile, new programming models and languages are being developed that 
strive to improve upon the status quo. This is accomplished by unifying 
the expression of parallelism and locality across the system, raising the 
level of abstraction, making use of modern language design features, 
and/or leveraging the respective strengths of programmers, compilers, 
runtimes, and operating systems.  These alternatives may take the form of 
parallel programming languages (e.g., Chapel, Fortran 2018, Julia, UPC), 
frameworks for large-scale data processing and analytics (e.g., Spark, 
Tensorflow, Dask), or libraries and embedded DSLs that extend existing 
languages (e.g., Legion, COMPSs, SHMEM, HPX, Charm++, UPC++, Coarray C++, 
Global Arrays).

The PAW-ATM workshop is designed to explore the expression of applications 
in scalable parallel programming models that serve as an alternative to 
the status quo.  It is designed to bring together applications experts and 
proponents of high-level programming models to present concrete and 
practical examples of using such alternative models and to illustrate the 
benefits of high-level approaches to scalable programming.


Scope and Aims
--------------

The PAW-ATM workshop is designed as a forum for exhibiting studies of 
parallel applications developed using high-level parallel programming 
models serving as alternatives to MPI+X-based programming. We encourage 
the submission of papers and talks that describe practical 
distributed-memory applications written using alternatives to MPI+X, and 
include characterizations of scalability and performance, expressiveness 
and programmability, as well as any downsides or areas for improvement in 
such models. Our hope is to create a forum in which architects, language 
designers, and users can present, learn about, and discuss the state of 
the art in alternative scalable programming models while also wrestling 
with how to increase their effectiveness and adoption.  Beyond 
well-established HPC scientific simulations, we also encourage submissions 
exploring artificial intelligence, big data analytics, machine learning, 
and other emerging application areas.


Topics include, but are not limited to:

* Novel application development using high-level parallel programming
   languages and frameworks.

* Examples that demonstrate performance, compiler optimization, error
   checking, and reduced software complexity.

* Applications from artificial intelligence, data analytics,
   bioinformatics, and other novel areas.

* Performance evaluation of applications developed using alternatives
   to MPI+X and comparisons to standard programming models.

* Novel algorithms enabled by high-level parallel abstractions.

* Experience with the use of new compiler and runtime environments.

* Libraries using or supporting alternatives to MPI+X.

* Benefits of hardware abstraction and data locality on algorithm
   implementation.


Submissions
-----------

Submissions are solicited in two categories:

1) Full-length papers presenting novel research results:

   * Full-length papers will be published in the workshop proceedings.
     Submitted papers must describe original work that has not appeared
     in, nor is under consideration for, another conference or
     journal. Papers shall be eight (8) pages minimum and not exceed
     ten (10) including text, appendices, and figures.  Appendix pages
     related to the reproducibility initiative dependencies, namely the
     Artifact Description (AD) and Artifact Evaluation (AE), are not
     included in the page count.

2) Extended abstracts summarizing preliminary/published results:

   * Extended abstracts will be evaluated separately and will not be
     included in the published proceedings; they are intended to
     propose timely communications of novel work that will be formally
     submitted elsewhere at a later stage, and/or of already published
     work that would be of interest to the PAW-ATM audience in terms of
     topic and timeliness.  Extended abstracts shall not exceed four
     (4) pages.

When deciding between submissions with similar merit, ties will be broken 
by giving weight to full-length paper submissions over extended abstracts. 
In addition, submissions whose focus relates more directly to the key 
themes of the workshop (application studies, computing at scale, 
high-level alternatives to MPI+X) will be given priority over those that 
don't.

Submissions shall be submitted through Linklings:
   https://submissions.supercomputing.org

Submissions must use 10pt font in the IEEE format:
   https://www.ieee.org/conferences/publishing/templates.html

PAW-ATM follows the reproducibility initiative of SC19.  For more
information, please refer to:
   https://sc19.supercomputing.org/submit/reproducibility-initiative/
   http://sourceryinstitute.github.io/PAW/


Committee
---------

WORKSHOP CHAIR

* Karla Morris - Sandia National Laboratory


ORGANIZING COMMITTEE

* Rosa M. Badia - Barcelona Supercomputing Center
* Bradford L. Chamberlain - Cray Inc.
* Sean Treichler - NVIDIA


PROGRAM COMMITTEE CHAIRS

* Bill Long - Cray Inc.
* Francesco Rizzi - NexGen Analytics


PROGRAM COMMITTEE

* Olivier Aumage - Inria
* Rosa M. Badia - Barcelona Supercomputing Center
* Vicenç Beltran - Barcelona Supercomputing Center
* John Biddiscombe - CSCS Swiss National Supercomputing Centre
* Bradford L. Chamberlain - Cray Inc.
* Salvatore Filippone - Cranfield University
* Marta G. Gasulla - Barcelona Supercomputing Center
* Magne Haveraaen - University of Bergen
* Costin Iancu - Lawrence Berkeley National Laboratory
* Laxmikant Kale - University of Illinois
* Karla Morris - Sandia National Laboratories
* Bill Long - Cray Inc.
* Swaroop S. Pophale - Oak Ridge National Laboratory
* Jason Riedy  - Georgia Institute of Technology
* Francesco Rizzi - NexGen Analytics
* Mitsuhisa Sato - RIKEN Advanced Institute for Computational Science
* Elliott Slaughter - SLAC National Accelerator Laboratory
* Sean Treichler - NVIDIA


ADVISORY COMMITTEE

* Salvatore Filippone - Cranfield University
* Damian W. I. Rouson - Sourcery Institute
* Katherine A. Yelick - Lawrence Berkeley National Laboratory



IMPORTANT DATES:

* Submission Deadline: July 31, 2019
* Author Notification: September 1, 2019
* Camera Ready:        October 1, 2019
* Workshop Date:       November 17|18|22, 2019

CHIUW 2019 is almost here!

[Brad C. <br...@cr...>]

Hi Chapel Community —

CHIUW 2019 is coming up in two weeks!  Highlights include:

* a keynote by Anshu Dubey (Argonne) on Programming Abstractions for
   Orchestration of HPC Scientific Computing

* talks from Chapel community members who've been using Chapel to:
   - accelerate and scale NumPy computations from Jupyter
   - orchestrate computations for hybrid CPU-GPU nodes
   - teach students how to write and tune stencils
   - write a Chapel Graph Library

* talks from the Cray team about Chapel progress including:
   - Chapel's use in Cray HPO / CrayAI
   - interoperating with Python, C, and Fortran
   - recent communication-driven performance optimizations
   - supporting radix sort in the Chapel standard library

In addition, we will have our annual "State of the Chapel Project" talk, a 
lightning talks session, and a follow-up coding day.

Hope to see you at CHIUW / PLDI / FCRC in Phoenix, June 22-23!

-Brad Chamberlain
  (on behalf of the CHIUW 2019 organizing committees)

Chapel workshops: CHIUW 2019 / PAW-ATM 2019

[Brad C. <br...@cr...>]

Hi Chapel Community —

This mail is about two upcoming Chapel-related workshops that you might be 
interested in attending and/or presenting at:


1) CHIUW 2019: the ACM SIGPLAN 6th Annual Chapel Implementers and Users
    Workshop, to be held June 22-23 in Phoenix, AZ with PLDI / FCRC 2019

    * the program is now available: https://chapel-lang.org/CHIUW2019.html

    * early registration closes this Friday, May 24

    * there will be a lightning talks session if you have a short talk on
      a Chapel-related topic that you'd like to give but did not submit
      for review

    * we will be holding a coding day on Sunday following the main workshop


2) PAW-ATM 2019: Parallel Applications Workshop, Alternatives to MPI+X,
    to be held November 17 in Denver, CO in conjunction with SC19

    * its website is here: https://sourceryinstitute.github.io/PAW/

    * submissions are due July 31

    * PAW-ATM accepts both full research papers and talk-only submissions


Please let me know if you have any questions, and we hope to see or hear 
from you at one or both of these events!

-Brad Chamberlain
  (on behalf of the CHIUW and PAW-ATM committees)

CHIUW 2019 deadline extended to March 29

[Brad C. <br...@cr...>]

Hi Chapel Community —

Based on requests from potential authors, we are extending the deadline 
for paper and talk submissions to CHIUW 2019 to March 29th.  No further 
extensions are expected.

If you have a topic that you think would be of interest to the Chapel 
community at PLDI / ACM FCRC 2019, please consider submitting a talk 
proposal or paper.  For further details, refer to:

 	https://chapel-lang.org/CHIUW2019-cfp.html

Best wishes,
-Brad