chapel-users — Users of the Chapel releases

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)

Re: Emacs Chapel Mode

[Peter K. <ca...@ns...>]

Interesting, I didn't know of either. I've only used the chapel-mode
that comes with chapel, ./highlight/emacs/23/chpl-mode.el:

;;; chpl-mode.el --- Major mode for editing Chapel code

;; Author:     2007 Steven T Balensiefer
;; Maintainer: Chapel group <cha...@cr...>
;; Created:    December 2002
;; Version:    0.7
;; Keywords:   Chapel languages oop

/Peter

On Sat, 15 Aug 2020 10:47:10 +0100
Russel Winder <ru...@wi...> wrote:

> Hi,
> 
> Many moons ago, I created the beginnings of a Chapel Mode for Emacs
> and put it up on MELPA for all Emacs users to use. For a whole mix of
> reasons I failed to evolve or even maintain it.
> 
> Damon Kwok has also created a Chapel Mode for Emacs. I do not know
> him but he seems to be a Chinese person trying to make a bit of money
> (via Patreon subscriptions) supporting Emacs modes and stuff. He
> asked if I would transfer the MELPA Chapel Mode from mine to his.
> Given that he is seeming active in the Emacs world and I am doing
> less and less of anything, this seemed like the right thing to do, so
> I have actioned this. Any Emacs user getting Chapel Mode from MELPA
> will now get his mode not mine.
> 
> His repository is at:  https://github.com/damon-kwok/chapel-mode
> 
> My repository, now redundant, is at: 
> https://github.com/russel/Emacs-Chapel-Mode
> 

Emacs Chapel Mode

[Russel W. <ru...@wi...>]

Hi,

Many moons ago, I created the beginnings of a Chapel Mode for Emacs and put it
up on MELPA for all Emacs users to use. For a whole mix of reasons I failed to
evolve or even maintain it.

Damon Kwok has also created a Chapel Mode for Emacs. I do not know him but he
seems to be a Chinese person trying to make a bit of money (via Patreon
subscriptions) supporting Emacs modes and stuff. He asked if I would transfer
the MELPA Chapel Mode from mine to his. Given that he is seeming active in the
Emacs world and I am doing less and less of anything, this seemed like the
right thing to do, so I have actioned this. Any Emacs user getting Chapel Mode
from MELPA will now get his mode not mine.

His repository is at:  https://github.com/damon-kwok/chapel-mode

My repository, now redundant, is at: 
https://github.com/russel/Emacs-Chapel-Mode

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

Re: can i build chplvis with my separate install of FLTK

[Paul D. H. <pd...@co...>]

Yes, that worked for me!  Thanks very much!

[ Also BTW let me say that I am very happy that chapel uses FLTK and not 
something else (like Qt, gtk, or whatever). Years ago, I used to be at 
"expert" level using Qt4 but in the last couple of years I've been using 
FLTK (1.4) and am very happy with it. I hope chapel sticks with FLTK! ]

- Paul

On 7/2/20 7:05 AM, Ferguson, Michael Paul Pratt (Chapel Developer) wrote:
> Hi Paul -
>
> Based upon some Makefile digging, it looks like
> you can do this:
>
>    cd tools/chplvis
>    make clean
>    make FLTK_INSTALL_DIR=/full/path/to/fltk/prefix
>
> I have checked that this appears to work for me
> but it would be great to know if it works for you
> as well.
>
> In my case I tested it by installing an fltk package
> on my system and using FLTK_INSTALL_DIR=/usr
> which allowed chplvis to build.
>   
> Thanks,
>
> -michael
>
>     I am new to chapel. I have built it successfully, but now I want to
>      build the chplvis utility.
>      
>      I have my own installation of FLTK that I would like to build chplvis
>      with, rather than the version that comes down as "third-party" from the
>      chapel github repository. Can I do that and how?
>      
>      Thanks,
>      Paul
>      
>      
>      
>      _______________________________________________
>      Chapel-users mailing list
>      Cha...@li...
>      https://lists.sourceforge.net/lists/listinfo/chapel-users
>      
>

Re: can i build chplvis with my separate install of FLTK

[Lydia D. <lyd...@hp...>]

Is this something we should document in the chplvis support?

Thanks,
Lydia

On 7/2/20 5:05 AM, Ferguson, Michael Paul Pratt (Chapel Developer) wrote:
> Hi Paul -
>
> Based upon some Makefile digging, it looks like
> you can do this:
>
>    cd tools/chplvis
>    make clean
>    make FLTK_INSTALL_DIR=/full/path/to/fltk/prefix
>
> I have checked that this appears to work for me
> but it would be great to know if it works for you
> as well.
>
> In my case I tested it by installing an fltk package
> on my system and using FLTK_INSTALL_DIR=/usr
> which allowed chplvis to build.
>   
> Thanks,
>
> -michael
>
>     I am new to chapel. I have built it successfully, but now I want to
>      build the chplvis utility.
>      
>      I have my own installation of FLTK that I would like to build chplvis
>      with, rather than the version that comes down as "third-party" from the
>      chapel github repository. Can I do that and how?
>      
>      Thanks,
>      Paul
>      
>      
>      
>      _______________________________________________
>      Chapel-users mailing list
>      Cha...@li...
>      https://lists.sourceforge.net/lists/listinfo/chapel-users
>      
>
>
> _______________________________________________
> Chapel-users mailing list
> Cha...@li...
> https://lists.sourceforge.net/lists/listinfo/chapel-users

Re: can i build chplvis with my separate install of FLTK

[Ferguson, M. P. P. (C. Developer) <mic...@hp...>]

Hi Paul -

Based upon some Makefile digging, it looks like
you can do this:

  cd tools/chplvis
  make clean
  make FLTK_INSTALL_DIR=/full/path/to/fltk/prefix

I have checked that this appears to work for me
but it would be great to know if it works for you
as well.

In my case I tested it by installing an fltk package
on my system and using FLTK_INSTALL_DIR=/usr
which allowed chplvis to build.
 
Thanks,

-michael

    I am new to chapel. I have built it successfully, but now I want to 
    build the chplvis utility.
    
    I have my own installation of FLTK that I would like to build chplvis 
    with, rather than the version that comes down as "third-party" from the 
    chapel github repository. Can I do that and how?
    
    Thanks,
    Paul
    
    
    
    _______________________________________________
    Chapel-users mailing list
    Cha...@li...
    https://lists.sourceforge.net/lists/listinfo/chapel-users 
    

can i build chplvis with my separate install of FLTK

[Paul D. H. <pd...@co...>]

I am new to chapel. I have built it successfully, but now I want to 
build the chplvis utility.

I have my own installation of FLTK that I would like to build chplvis 
with, rather than the version that comes down as "third-party" from the 
chapel github repository. Can I do that and how?

Thanks,
Paul

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/>

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

Re: Multiple locale execution on a Mac laptop

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

Definitely OK to ask on SO.  We need more SO question.  :)

-Brad


On Thu, 11 Jun 2020, Takeshi Yamamoto wrote:

> Dear Brad,
>
> I had completely the same question when trying multi-locale runs
> on a single node (Mac) much ago, so glad to find the answer :)
>
> # Indeed, my old note says: "Is it necessary to write
> 'export GASNET_SSH_SERVERS="localhost localohost ...'
> explicitly after enabling password-less SSH?" etc.
>
> So, I am wondering if it is OK to ask this question on StackOverflow
> (unless it is already asked/answered before)?
>
> Best regards,
> Takeshi Yamamoto (@ty1027)
>
> On Fri, Jun 12, 2020 at 8:01 AM Brad Chamberlain <
> bra...@hp...> wrote:
>
>>
>> Hi Richard —
>>
>> Best practice when running GASNet locally is to set:
>>
>>         export GASNET_SPAWNFN=L   # L = local
>>
>> and then there's no need to have a GASNET_SSH_SERVERS list.  Give a shout
>> if this doesn't work for you.
>>
>> -Brad
>>
>>
>> On Thu, 11 Jun 2020, Barrett, Richard F via Chapel-users wrote:
>>
>>> Folks,
>>>
>>> I’m trying to run multilocale on my Mac OSX 10.14.6 4 core laptop, but I
>> don’t believe I have the settings correct.
>>>
>>> Build:
>>>
>>> cd chapel-1.22.0
>>> export CHPL_COMM=gasnet
>>> ./configure
>>> Make
>>>
>>> Compiling my code results in my executable plus executable_real.
>>>
>>> To run, from
>>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__chapel-2Dlang.org_docs_usingchapel_multilocale.html&d=DwIGaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=QUQW-BniEL_d2a7btR4rP5TPiNmpm1pG-Qa_xXzGVKc&m=f-uoASqUgCkyT7DF7LiW2iExfixPEwnpJl0lAx0c74Y&s=qX-sqGKh84GkiXReC9HsAQ
>>> AN1hmUrEpyKyy_Srn7Pc0&e= :
>>>
>>> export GASNET_SPAWNFN=S
>>> export GASNET_SSH_SERVERS="host1 host2 host3 ..."
>>>
>>> But since only one host, is this necessary? When I list my machine name,
>>> I'm prompted for a passwd. If I don't list machines, I see this:
>>>
>>> *** GASNET ERROR: Environment variable SSH_SERVERS is missing.
>>>
>>> And if the command line is "./my_executable_real -nl {num}, I see this
>>> error:
>>>
>>> GASNet: Usage ' my_executable_real <num_nodes> {program arguments}'
>>>
>>> So apparently gasnet launching syntax required here, correct?
>>>
>>> Any help appreciate, with apologies in advance for missing some obvious
>>> documentation.
>>>
>>> Richard
>>> --
>>> Richard Barrett
>>> PO Box 5800, MS-0620
>>> Sandia National Laboratories
>>> Albuquerque, NM 87185
>>> Phone: 505-845-7655
>>> Pager: 505-951-8087
>>>
>>>
>>>
>>> _______________________________________________
>>> Chapel-users mailing list
>>> Cha...@li...
>>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_chapel-2Dusers&d=DwIGaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=QUQW-BniEL_d2a7btR4rP5TPiNmpm1pG-Qa_xXzGVKc&m=f-uoASqUgCkyT7DF7LiW2iExfixPEwnpJl0lAx0c74Y&s=5RS8dH25KS0n4Zor05Nj7Vq-M7BeQhulid4zsrVZATc&e=
>>> _______________________________________________
>> Chapel-users mailing list
>> Cha...@li...
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_chapel-2Dusers&d=DwIFaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=QUQW-BniEL_d2a7btR4rP5TPiNmpm1pG-Qa_xXzGVKc&m=CtY4V5TqH_41g55HXzdE8jIPqrf7QeQOhEo7iGY9fZU&s=nWqd2wwdOe7FcEOSp01iGwN2S9zB8kgR0cyxf04827M&e=
>>
>

Re: Multiple locale execution on a Mac laptop

[Takeshi Y. <yam...@gm...>]

Dear Brad,

I had completely the same question when trying multi-locale runs
on a single node (Mac) much ago, so glad to find the answer :)

# Indeed, my old note says: "Is it necessary to write
'export GASNET_SSH_SERVERS="localhost localohost ...'
explicitly after enabling password-less SSH?" etc.

So, I am wondering if it is OK to ask this question on StackOverflow
(unless it is already asked/answered before)?

Best regards,
Takeshi Yamamoto (@ty1027)

On Fri, Jun 12, 2020 at 8:01 AM Brad Chamberlain <
bra...@hp...> wrote:

>
> Hi Richard —
>
> Best practice when running GASNet locally is to set:
>
>         export GASNET_SPAWNFN=L   # L = local
>
> and then there's no need to have a GASNET_SSH_SERVERS list.  Give a shout
> if this doesn't work for you.
>
> -Brad
>
>
> On Thu, 11 Jun 2020, Barrett, Richard F via Chapel-users wrote:
>
> > Folks,
> >
> > I’m trying to run multilocale on my Mac OSX 10.14.6 4 core laptop, but I
> don’t believe I have the settings correct.
> >
> > Build:
> >
> > cd chapel-1.22.0
> > export CHPL_COMM=gasnet
> > ./configure
> > Make
> >
> > Compiling my code results in my executable plus executable_real.
> >
> > To run, from
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__chapel-2Dlang.org_docs_usingchapel_multilocale.html&d=DwIGaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=QUQW-BniEL_d2a7btR4rP5TPiNmpm1pG-Qa_xXzGVKc&m=f-uoASqUgCkyT7DF7LiW2iExfixPEwnpJl0lAx0c74Y&s=qX-sqGKh84GkiXReC9HsAQ
> > AN1hmUrEpyKyy_Srn7Pc0&e= :
> >
> > export GASNET_SPAWNFN=S
> > export GASNET_SSH_SERVERS="host1 host2 host3 ..."
> >
> > But since only one host, is this necessary? When I list my machine name,
> > I'm prompted for a passwd. If I don't list machines, I see this:
> >
> > *** GASNET ERROR: Environment variable SSH_SERVERS is missing.
> >
> > And if the command line is "./my_executable_real -nl {num}, I see this
> > error:
> >
> > GASNet: Usage ' my_executable_real <num_nodes> {program arguments}'
> >
> > So apparently gasnet launching syntax required here, correct?
> >
> > Any help appreciate, with apologies in advance for missing some obvious
> > documentation.
> >
> > Richard
> > --
> > Richard Barrett
> > PO Box 5800, MS-0620
> > Sandia National Laboratories
> > Albuquerque, NM 87185
> > Phone: 505-845-7655
> > Pager: 505-951-8087
> >
> >
> >
> > _______________________________________________
> > Chapel-users mailing list
> > Cha...@li...
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_chapel-2Dusers&d=DwIGaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=QUQW-BniEL_d2a7btR4rP5TPiNmpm1pG-Qa_xXzGVKc&m=f-uoASqUgCkyT7DF7LiW2iExfixPEwnpJl0lAx0c74Y&s=5RS8dH25KS0n4Zor05Nj7Vq-M7BeQhulid4zsrVZATc&e=
> >_______________________________________________
> Chapel-users mailing list
> Cha...@li...
> https://lists.sourceforge.net/lists/listinfo/chapel-users
>

Re: [EXTERNAL] Re: Multiple locale execution on a Mac laptop

[Barrett, R. F <rf...@sa...>]

That works, thanks.
Richard

On 6/11/20, 4:46 PM, "Brad Chamberlain" <bra...@hp...> wrote:

    
    Hi Richard —
    
    Best practice when running GASNet locally is to set:
    
     	export GASNET_SPAWNFN=L   # L = local
    
    and then there's no need to have a GASNET_SSH_SERVERS list.  Give a shout 
    if this doesn't work for you.
    
    -Brad
    
    
    On Thu, 11 Jun 2020, Barrett, Richard F via Chapel-users wrote:
    
    > Folks,
    >
    > I’m trying to run multilocale on my Mac OSX 10.14.6 4 core laptop, but I don’t believe I have the settings correct.
    >
    > Build:
    >
    > cd chapel-1.22.0
    > export CHPL_COMM=gasnet
    > ./configure
    > Make
    >
    > Compiling my code results in my executable plus executable_real.
    >
    > To run, from 
    > https://urldefense.proofpoint.com/v2/url?u=https-3A__chapel-2Dlang.org_docs_usingchapel_multilocale.html&d=DwIGaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=QUQW-BniEL_d2a7btR4rP5TPiNmpm1pG-Qa_xXzGVKc&m=f-uoASqUgCkyT7DF7LiW2iExfixPEwnpJl0lAx0c74Y&s=qX-sqGKh84GkiXReC9HsAQ
    > AN1hmUrEpyKyy_Srn7Pc0&e= :
    >
    > export GASNET_SPAWNFN=S
    > export GASNET_SSH_SERVERS="host1 host2 host3 ..."
    >
    > But since only one host, is this necessary? When I list my machine name, 
    > I'm prompted for a passwd. If I don't list machines, I see this:
    >
    > *** GASNET ERROR: Environment variable SSH_SERVERS is missing.
    >
    > And if the command line is "./my_executable_real -nl {num}, I see this 
    > error:
    >
    > GASNet: Usage ' my_executable_real <num_nodes> {program arguments}'
    >
    > So apparently gasnet launching syntax required here, correct?
    >
    > Any help appreciate, with apologies in advance for missing some obvious 
    > documentation.
    >
    > Richard
    > -- 
    > Richard Barrett
    > PO Box 5800, MS-0620
    > Sandia National Laboratories
    > Albuquerque, NM 87185
    > Phone: 505-845-7655
    > Pager: 505-951-8087
    >
    >
    >
    > _______________________________________________
    > Chapel-users mailing list
    > Cha...@li...
    > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_chapel-2Dusers&d=DwIGaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=QUQW-BniEL_d2a7btR4rP5TPiNmpm1pG-Qa_xXzGVKc&m=f-uoASqUgCkyT7DF7LiW2iExfixPEwnpJl0lAx0c74Y&s=5RS8dH25KS0n4Zor05Nj7Vq-M7BeQhulid4zsrVZATc&e=
    >

Re: Multiple locale execution on a Mac laptop

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

Hi Richard —

Best practice when running GASNet locally is to set:

 	export GASNET_SPAWNFN=L   # L = local

and then there's no need to have a GASNET_SSH_SERVERS list.  Give a shout 
if this doesn't work for you.

-Brad


On Thu, 11 Jun 2020, Barrett, Richard F via Chapel-users wrote:

> Folks,
>
> I’m trying to run multilocale on my Mac OSX 10.14.6 4 core laptop, but I don’t believe I have the settings correct.
>
> Build:
>
> cd chapel-1.22.0
> export CHPL_COMM=gasnet
> ./configure
> Make
>
> Compiling my code results in my executable plus executable_real.
>
> To run, from 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__chapel-2Dlang.org_docs_usingchapel_multilocale.html&d=DwIGaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=QUQW-BniEL_d2a7btR4rP5TPiNmpm1pG-Qa_xXzGVKc&m=f-uoASqUgCkyT7DF7LiW2iExfixPEwnpJl0lAx0c74Y&s=qX-sqGKh84GkiXReC9HsAQ
> AN1hmUrEpyKyy_Srn7Pc0&e= :
>
> export GASNET_SPAWNFN=S
> export GASNET_SSH_SERVERS="host1 host2 host3 ..."
>
> But since only one host, is this necessary? When I list my machine name, 
> I'm prompted for a passwd. If I don't list machines, I see this:
>
> *** GASNET ERROR: Environment variable SSH_SERVERS is missing.
>
> And if the command line is "./my_executable_real -nl {num}, I see this 
> error:
>
> GASNet: Usage ' my_executable_real <num_nodes> {program arguments}'
>
> So apparently gasnet launching syntax required here, correct?
>
> Any help appreciate, with apologies in advance for missing some obvious 
> documentation.
>
> Richard
> -- 
> Richard Barrett
> PO Box 5800, MS-0620
> Sandia National Laboratories
> Albuquerque, NM 87185
> Phone: 505-845-7655
> Pager: 505-951-8087
>
>
>
> _______________________________________________
> Chapel-users mailing list
> Cha...@li...
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_chapel-2Dusers&d=DwIGaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=QUQW-BniEL_d2a7btR4rP5TPiNmpm1pG-Qa_xXzGVKc&m=f-uoASqUgCkyT7DF7LiW2iExfixPEwnpJl0lAx0c74Y&s=5RS8dH25KS0n4Zor05Nj7Vq-M7BeQhulid4zsrVZATc&e=
>

Multiple locale execution on a Mac laptop

[Barrett, R. F <rf...@sa...>]

Folks,

I’m trying to run multilocale on my Mac OSX 10.14.6 4 core laptop, but I don’t believe I have the settings correct.

Build:

cd chapel-1.22.0
export CHPL_COMM=gasnet
./configure
Make

Compiling my code results in my executable plus executable_real.

To run, from https://chapel-lang.org/docs/usingchapel/multilocale.html :

export GASNET_SPAWNFN=S
export GASNET_SSH_SERVERS="host1 host2 host3 ..."

But since only one host, is this necessary? When I list my machine name, I'm prompted for a passwd. If I don't list machines, I see this:

*** GASNET ERROR: Environment variable SSH_SERVERS is missing.

And if the command line is "./my_executable_real -nl {num}, I see this error:

GASNet: Usage ' my_executable_real <num_nodes> {program arguments}'

So apparently gasnet launching syntax required here, correct?

Any help appreciate, with apologies in advance for missing some obvious documentation.

Richard
-- 
Richard Barrett
PO Box 5800, MS-0620
Sandia National Laboratories
Albuquerque, NM 87185
Phone: 505-845-7655
Pager: 505-951-8087
 

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.

Re: dmap block and v1.21

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

Hi Richard —

OK, now back on the original question.  First, I have a style suggestion 
that _might_ help performance, but I'm not certain it will address the 
main problem that you're running into.  Specifically, where you're 
writing:

>   forall i in b.dom with ( + reduce bnrm2 ) {
>      bnrm2 += b.val[i] * b.val[i];
>   }

I think you can get away with a much more simple expression of the 
computation by writing:

 	var bnrm2 = + reduce [i in b.dom] (b.val[i] * b.val[i]);

or better:

 	var bnrm2 = + reduce [i in b.dom] (b.val[i]**2);

or better:

 	var bnrm2 = + reduce b.val**2;

Reduce expressions iterate over the expression that follows them, applying 
the reduction operator and returning the result.  The first case uses a
forall expression to iterate over the domain and index into the vector.

The second replaces the redundant array indexing with an exponentiation 
which will strength-reduced to a multiplication at compilation time, yet 
without indexing the array twice.

The third replaces the explicit loop with an instance of promotion: 
applying the exponentiation operator to each element in the array and 
returning the sums.

There is _some_ chance that this third form will address your performance 
problem, but now that you've pointed it out, I'm worried that other idioms 
you write will run back into it, so let me explain what I believe is going 
on.  And in doing so let me say that while I think this explanation for 
what's going on is reasonable, I'll also say that this is a known issue 
that we believe we need to do something to address it (because it's a trap 
waiting for people to step into it), but haven't had the chance to do so 
yet.

OK, so let me introduce the issue using a simple example.  Imagine that
I had the following code:

 	record R {
 	  var x: int;
 	}

 	var myR: R;

 	on Locales[1] {
 	  for i in 1..n {
 	    writeln(myR.x);
 	    myR.x += 1;
 	  }
 	}

The instance of R named 'myR' is stored on locale 0 because that's where 
the task was running when its declaration was encountered.  But the big 
computational loop that's accessing it is running on locale 1.  What this 
means is that each time myR.x is read or written, communication back to 
locale 0 needs to take place (we might imagine that the compiler could do 
analysis to determine that nobody else is modifying myR.x at the same 
time, so could cache the value, compute all the updates, and then push the 
result back to the original variable, but that doesn't happen today).

Hopefully this makes sense and seems reasonable:  myR.x is on a remote 
locale, so reads/writes of it need to communicate with that locale.

OK, now let's change R to be _slightly_ more like your example:

 	record R {
 	  var A = newBlockArr({1..n}, real);
 	}

 	var myR: R;

 	on Locales[1] {
 	  for i in n/2..n {
 	    writeln(myR.A[i]);
 	    myR.A[i] += 1;
 	  }
 	}

This example is a bit weirder because R contains a distributed array A, so 
if we're running on two locales, half of myR.A's elements will be on 
Locale 0 and half on Locale 1.

Intuitively, that seems like it means all the references to myR.A[i] 
within the loop ought to be local / not require communication; however, 
the issue is that the myR record itself, as well as the original field A 
that defines the distributed array, lives on locale 0.  So each time the 
compiler sees the expression myR.A, the first thing it does is say "let me 
go talk to locale 0 to find out about this A field... oh, it's a 
distributed array" before finding out that the specific element i that 
it's looking for happens to be local.

Arguably, the compiler should be doing more to help here:  For example, 
maybe when a record containing a distributed array spans an on-clause, it 
should be pulling the array descriptor out of the record and passing a 
copy of it off to the next locale such that it can access it locally. The 
following GitHub issue captures our desire to do better here as well as 
some kicking around of various approaches (for those truly interested):

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

Even though our compiler isn't helping much with this pattern at present, 
a runtime optimization that's been implemented may.  Once you get it 
working with Chapel 1.21, try compiling your original program (whether or 
not my proposed rewrite of the reduction helps) with --cache-remote and 
see if it helps.  (--cache-remote turns on an execution-time optimization 
in which remote puts and gets are cached and avoided when the memory 
consistency model permits it... essentially striving for a similar effect 
as I was suggesting a more aggressive compiler could do in my first 
example).

If this doesn't help, there are some workarounds that can be applied
within the code itself to reduce communication but... they can get
pretty ugly in the extreme cases, so let's see where this gets us.

(I'll mention that we're working towards getting --cache-remote to the 
point that it can be enabled by default, but didn't get there in time for 
Chapel 1.21...).

Hope this helps, and definitely let us know what you find,
-Brad

PS — And sorry again for how long it took us to get to this.


On Mon, 13 Apr 2020, Barrett, Richard F via Chapel-users wrote:

> Folks,
>
> I have some questions regarding the use and subsequent performance of dmap. I’m doing some simple vector computations (add, scale, reduce), with the vectors defined in a record:
>
> record RVectorRB { // Real valued vector.
>
>    var dom = {1..num_vertices} dmapped Block ( boundingBox={1..num_vertices} );
>
>    var val : [dom] real;
> }
>
> Instantiated as this:    var v1 : RVectorRB; , with num_vertices config const.
>
> For RVectorRB vectors b, p, and z, reductions look like this:
>
>   forall i in b.dom with ( + reduce bnrm2 ) {
>      bnrm2 += b.val[i] * b.val[i];
>   }
>
> Vector updates : p.val = z.val + beta*p.val;   // beta real scalar.
>
> Performance on 2 locales (2 nodes of a Cray XC30, 2x16 Haswells) is 44x slower than 1 locale/node. Further, when I comment out the dmap, single node runs 3x faster than with it. Vector lengths 1k up to 100M elements.
>
> This is with v1.20. When I tried to compile with v1.21, I get these errors:
>
> %  chpl main.chpl
> main.chpl:12: In function 'main':
> main.chpl:49: error: Attempt to 'new' a function or undefined symbol
> main.chpl:59: error: 'timings' undeclared (first use this function)
> main.chpl:61: error: 't' undeclared (first use this function)
> main.chpl:63: error: 'TimeUnits' undeclared (first use this function)
> main.chpl:77: error: 'alg' undeclared (first use this function)
>
> 'new' is for instantiating a record, alg is my enumeration, and I'm "using" Chapel's Time module within a module that's used by my main module which is used by main. Checked the release notes but not seeing what's changed. I'm seeing this on the XC as well as my Mac (not the homebrew version).
>
> I'd greatly appreciate any help or information regarding any of the above.
>
> Richard
> -- 
> Richard Barrett
> PO Box 5800, MS-0620
> Sandia National Laboratories
> Albuquerque, NM 87185
> Phone: 505-845-7655
> Pager: 505-951-8087
>
>
>
> _______________________________________________
> Chapel-users mailing list
> Cha...@li...
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_chapel-2Dusers&d=DwIGaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=QUQW-BniEL_d2a7btR4rP5TPiNmpm1pG-Qa_xXzGVKc&m=U-WL-8YdV3j-zOKUf2QYYqRb5SnBUsgaG03nnhB0ER8&s=WyrpdSULX-IJKEjZ7FFiUXjNk9i6gqxL4E1YABd1rYA&e=
>

Re: dmap block and v1.21

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

Hi Richard —

Sorry for the delayed response, it's release season here (to wit: I 
started the day thinking "I'm going to reply to Richard's message first 
thing and here I am trying to sneak a response under the wire).

Let me start with the easy question first.  I think the 1.21 upgrade 
problem you're running into is the following entry from the CHANGES.md 
file:

- made `use` private by default ...

Specifically, given a pattern like the following:

 	module M {
 	  use Time;
 	}

 	module N {
 	  use N;
 	  ...Time.<something>...
 	}

It used to be the case that the `use Time;` in M was considered "public" 
which meant that anything that used M would also see Time's symbols as 
well.  As of Chapel 1.21, `use` statements are private, intended to 
prevent symbols from leaking throughout a code base in an undisciplined 
manner.  The two ways to fix this would be to change the use back into
a public use:

 	module M {
 	  public use Time;  // override the private default
 	}

 	module N {
 	  use N;
 	  ...Time.<something>...
 	}

or to put another `use` into N itself:

 	module M {
 	  use Time;
 	}

 	module N {
 	  use N, Time;
 	  ...Time.<something>...
 	}

Either of these are valid, and the choice will probably depend on whether, 
logically, you'd like everything that uses M to have immediate access to 
Time's symbols or to have those modules state their reliance on Time 
themselves.

This has already gone on a bit long, so let me get to your other question 
in a distinct mail.

-Brad



On Mon, 13 Apr 2020, Barrett, Richard F via Chapel-users wrote:

> Folks,
>
> I have some questions regarding the use and subsequent performance of dmap. I’m doing some simple vector computations (add, scale, reduce), with the vectors defined in a record:
>
> record RVectorRB { // Real valued vector.
>
>    var dom = {1..num_vertices} dmapped Block ( boundingBox={1..num_vertices} );
>
>    var val : [dom] real;
> }
>
> Instantiated as this:    var v1 : RVectorRB; , with num_vertices config const.
>
> For RVectorRB vectors b, p, and z, reductions look like this:
>
>   forall i in b.dom with ( + reduce bnrm2 ) {
>      bnrm2 += b.val[i] * b.val[i];
>   }
>
> Vector updates : p.val = z.val + beta*p.val;   // beta real scalar.
>
> Performance on 2 locales (2 nodes of a Cray XC30, 2x16 Haswells) is 44x slower than 1 locale/node. Further, when I comment out the dmap, single node runs 3x faster than with it. Vector lengths 1k up to 100M elements.
>
> This is with v1.20. When I tried to compile with v1.21, I get these errors:
>
> %  chpl main.chpl
> main.chpl:12: In function 'main':
> main.chpl:49: error: Attempt to 'new' a function or undefined symbol
> main.chpl:59: error: 'timings' undeclared (first use this function)
> main.chpl:61: error: 't' undeclared (first use this function)
> main.chpl:63: error: 'TimeUnits' undeclared (first use this function)
> main.chpl:77: error: 'alg' undeclared (first use this function)
>
> 'new' is for instantiating a record, alg is my enumeration, and I'm "using" Chapel's Time module within a module that's used by my main module which is used by main. Checked the release notes but not seeing what's changed. I'm seeing this on the XC as well as my Mac (not the homebrew version).
>
> I'd greatly appreciate any help or information regarding any of the above.
>
> Richard
> -- 
> Richard Barrett
> PO Box 5800, MS-0620
> Sandia National Laboratories
> Albuquerque, NM 87185
> Phone: 505-845-7655
> Pager: 505-951-8087
>
>
>
> _______________________________________________
> Chapel-users mailing list
> Cha...@li...
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_chapel-2Dusers&d=DwIGaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=QUQW-BniEL_d2a7btR4rP5TPiNmpm1pG-Qa_xXzGVKc&m=U-WL-8YdV3j-zOKUf2QYYqRb5SnBUsgaG03nnhB0ER8&s=WyrpdSULX-IJKEjZ7FFiUXjNk9i6gqxL4E1YABd1rYA&e=
>

dmap block and v1.21

[Barrett, R. F <rf...@sa...>]

Folks,

I have some questions regarding the use and subsequent performance of dmap. I’m doing some simple vector computations (add, scale, reduce), with the vectors defined in a record:

record RVectorRB { // Real valued vector.

   var dom = {1..num_vertices} dmapped Block ( boundingBox={1..num_vertices} );

   var val : [dom] real;
}

Instantiated as this:    var v1 : RVectorRB; , with num_vertices config const.

For RVectorRB vectors b, p, and z, reductions look like this:

   forall i in b.dom with ( + reduce bnrm2 ) {
      bnrm2 += b.val[i] * b.val[i];
   }

Vector updates : p.val = z.val + beta*p.val;   // beta real scalar.

Performance on 2 locales (2 nodes of a Cray XC30, 2x16 Haswells) is 44x slower than 1 locale/node. Further, when I comment out the dmap, single node runs 3x faster than with it. Vector lengths 1k up to 100M elements.

This is with v1.20. When I tried to compile with v1.21, I get these errors:

%  chpl main.chpl 
main.chpl:12: In function 'main':
main.chpl:49: error: Attempt to 'new' a function or undefined symbol
main.chpl:59: error: 'timings' undeclared (first use this function)
main.chpl:61: error: 't' undeclared (first use this function)
main.chpl:63: error: 'TimeUnits' undeclared (first use this function)
main.chpl:77: error: 'alg' undeclared (first use this function)

'new' is for instantiating a record, alg is my enumeration, and I'm "using" Chapel's Time module within a module that's used by my main module which is used by main. Checked the release notes but not seeing what's changed. I'm seeing this on the XC as well as my Mac (not the homebrew version).

I'd greatly appreciate any help or information regarding any of the above.

Richard
-- 
Richard Barrett
PO Box 5800, MS-0620
Sandia National Laboratories
Albuquerque, NM 87185
Phone: 505-845-7655
Pager: 505-951-8087
 

Are you writing "Powered by Chapel" apps?

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

Hi Chapel Users —

I'm working on some updates to the Chapel website, and have been 
considering launching a new "powered by Chapel" section.  If you're using 
Chapel in your applications or computations and would be open to being 
featured on such a list, would you send me as many of the following items 
as possible:

* The name of your project
* A link to a website/repo for the project, if it has one; to some other
   sort of artifact (a recent publication?  a recent presentatoin?) if it
   doesn't.
* The names of people / institutions associated with it
* A 1-2 sentence blurb on the project

Thanks very much,
-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

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: Can't find _real

[Roger M. <rm...@mu...>]

Brad Chamberlain <bra...@hp...> writes:

> I think it also would be reasonable to suggest that, as a fallback
> perhaps when the current behavior fails, the launcher binary should
> search the path for the _real binary rather than giving up after not
> finding it in the same directory.  If you want to propose this, I'd
> suggest opening up a feature request issue on our GitHub page:
>
> 	https://github.com/chapel-lang/chapel/issues
>
> Hope this is helpful,
> -Brad

Done.

Thanks for your help.
Roger