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

Re: [Chapel-education] availability

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

Hi Daye --

I can't comment on Chapel's availability on machines -- any Cray X* system can have Chapel installed by a sysadmin if they choose to, but whether or not they do varies from center to center (and I don't have accounts on most).

If Qthreads gives you problems building from source, try setting CHPL_TASKS=fifo and rebuilding again (which should take Qthreads out of the loop).  At the same time, we'd like to hear about any build problems you run into, so if you would send those to chapel-bugs@...  (another sourceforge mailing list), that would be most appreciated.

Thanks,
-Brad


________________________________
From: Daye Liu [ros...@gm...]
Sent: Saturday, November 15, 2014 10:03 AM
To: cha...@li...
Subject: [Chapel-education] availability

Hello, is chapel available at any major computing centers or educational resources such as XSEDE? I attempted to install chapel, but ran into several problems, mainly related to qthread.

[Chapel-education] availability

[Daye L. <ros...@gm...>]

Hello, is chapel available at any major computing centers or educational
resources such as XSEDE? I attempted to install chapel, but ran into
several problems, mainly related to qthread.

[Chapel-education] [Chapel-announce] SC14: Lightning Talks, Hierarchical Locales talk, and more

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

Hi Chapel Community --

* LIGHTNING TALKS: We're excited to announce the lineup and topics for the
   fourth annual Chapel Lightning Talks BoF at SC14 next week (Tuesday @
   12:15, room 293):

   - Chapel Overview, Greg Titus (Cray Inc.)

   - CoMD in Chapel: The Good, the Bad, and the Ugly, David Richards
     (Lawrence Livermore National Laboratory)

   - Chapel for Python Programmers, Simon Lund (University of Copenhagen)

   - Chapel Iterators: Providing Tiling for the Rest of Us, Ian
     Bertolacci (Colorado State University)

   - Chapel I/O: Getting to Your Data Wherever It Is, Timothy Zakian
     (Indiana University)

   - LLVM-based Communication Optimizations for Chapel, Akihiro Hayashi
     (Rice University)

   - COHX: CHAPEL ON HSA+XTQ (Adventures of a PGAS Language in a
     Heterogeneous World) Deepak Majeti (Rice University)

   If you haven't attended the Lightning Talks BoF before, each of the
   talks above gets a five-minute slot, after which there will be a general
   Q&A session for all the speakers.  Thanks to Sung-Eun Choi (Cray) and
   Richard Barrett (Sandia) for co-hosting the BoF this year, and to all
   the speakers for participating.  We hope you can join us!


* HIERARCHICAL LOCALES TALK: Since our last mail, Greg Titus has been
   scheduled to give a talk on Chapel's Hierarchical Locales in the
   Emerging Technology Theater (booth 233) on Tuesday at 4:30pm.  Come hear
   him describe this Chapel concept, designed to make the language
   future-proof against the diversity of processor architectures that are
   coming our way in the exascale era.


* AND MORE: Of course on top of that, we have
   - the Chapel tutorial (Sunday morning)
   - the Chapel Users Group (CHUG) BoF and Happy Hour (Wednesday evening)
   - the Emerging Technologies exhibit on hierarchical locales (all week)
   - a poster from Colorado State, participation in other BoFs, and more!


For further details on all Chapel-related events at SC14, please refer to 
the Chapel SC14 webpage (http://chapel.cray.com/SC14.html) or our latest 
article on the Cray blog, "Chapel at SC14: Making Big Easy" 
(http://blog.cray.com/?p=7428).


We hope to see and meet many of you at the show!
-Brad (on behalf of the Chapel team)

---

Chapel on Facebook: https://www.facebook.com/ChapelLanguage
Chapel on the web:  http://chapel.cray.com/

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-announce mailing list
Cha...@li...
https://lists.sourceforge.net/lists/listinfo/chapel-announce

[Chapel-education] [Chapel-announce] Chapel Facebook page and communications overview

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

Hi Chapel Community --

A few weeks ago, we kicked off a Chapel Facebook page as a means of 
communicating about Chapel-related events in a lighter-weight, more 
conversational way than the traditional SourceForge mailing lists.  For 
example, recent posts have included announcements of:

* the third and final part of the "Why Chapel?" series of blog articles

* a pointer to the hot-off-the-presses detailed release notes for v1.10

* a regressions week effort being undertaken by the Cray team (as we speak!)

* and of course, announcements that we'd also post to the mailing lists,
   like the 1.10 release and upcoming SC14 activities.

The page also includes a historical timeline of significant events in the 
project's history (which we'll try to continue to add to over time).

This page is available for viewing whether you have a Facebook account or 
not:

 	https://www.facebook.com/ChapelLanguage

For those of you who do, we invite you to "Like" the page in order to get 
a mix of Chapel activites posted regularly to your newsfeed and help 
spread the word.


Chapel Mailing Lists
--------------------

While discussing Chapel communications, it's worth reviewing the major 
Chapel mailing lists at SourceForge:

   * chapel-announce: a "broadcast-only" list that we try to use sparingly
     (less than a dozen times a year) to announce things like releases,
     calls for participation in high-profile Chapel events like CHIUW and
     SC, and the like.  Mails to this list also forward to the following
     three community discussion lists, so there's no need to subscribe to
     it unless you don't want to belong to the following ones.

   * chapel-users: a community list for users, developers, and fans of the
     Chapel language to discuss the language and its implementation.  Note
     that bug reports or "Why is my build not working?" types of mail
     should typically be directed to chapel-bugs rather than here.

   * chapel-developers: a community list for developers and those who want
     to pay attention to Chapel's implementation effort.

   * chapel-education: a community list for educators interested in using
     Chapel in their courses and interacting with similarly-minded folks.

   * chapel-bugs: a place to wrestle through anything that isn't working
     as expected or advertised.

There are also a few lists whose contents are auto-generated by code 
commits (chapel-commmits) and nightly testing (chapel-test-results-*) for 
those who are deeply involved in the development.

Any of these lists can be subscribed to or browsed at SourceForge:

 	http://sourceforge.net/p/chapel/mailman/


Chapel Webpage
--------------

For those who prefer a pull-based method of getting information, the 
Chapel webpage is your best bet, where the front page will typically point 
to the most interesting recent content and the "What's new?" section will 
point to most any added content of significance:

 	http://chapel.cray.com/
 	http://chapel.cray.com/whatsnew.html


Chapel-developers chatroom
--------------------------

Finally, for Chapel developers, there is a chapel developers IRC channel for 
real-time discussions with others who happen to be logged in at the time.  See 
the "Developer Resources" page at chapel.cray.com for details.


We hope that the community is able to hear about Chapel in the ways that suit 
them best using these methods.  If you have feedback on ways in which 
additional modes of communication could be improved or enhanced, please
let us know.

Thanks,
-Brad
  (on behalf of the Chapel community)


------------------------------------------------------------------------------
_______________________________________________
Chapel-announce mailing list
Cha...@li...
https://lists.sourceforge.net/lists/listinfo/chapel-announce

[Chapel-education] [Chapel-announce] Chapel at SC14 (plus: Lightning Talk proposals due Friday!)

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

Hi Chapel Community --

As SC14 gets closer, we wanted to make you aware of a number of 
Chapel-related events that will be taking place at the conference.

First, a quick reminder that if you have Chapel-related work that you'd 
like to highlight as part of the Chapel Lightning Talks BoF at SC14, those 
proposals are due at the end of this week.  Details regarding the BoF and 
proposal process can be found at:  http://chapel.cray.com/SC-BoF-LT.html

Details and coordinates for all Chapel-related SC14 events can be found on 
the Chapel website at:

 	http://chapel.cray.com/events.html

Here's a conversational rundown:

* Chapel Tutorial: SC14 will kick off with a half-day Chapel tutorial on
   Sunday morning.  If you or your colleagues would like training in
   Chapel, this is the place to be.  We'll be taking a new approach this
   year, using sample computations to drive the introduction of Chapel
   concepts rather than simply walking through the language's feature set.

* Exhibition Floor: throughout the week, when the exhibition floor is
   open, we'll have a spot in the Emerging Technologies booth where you
   can stop by and hear about our ongoing work to support user-defined
   Hierarchical Locale Models in Chapel, or anything else you might be
   interested in.  This is the default place to come find us during the
   week if you want to talk Chapel between other events.

* Chapel Lightning Talks BoF: In the Tuesday lunchtime BoF slot, we'll be
   holding our annual lightning talks BoF, highlighting Chapel-related work
   being undertaken by members of the broad community via short 5-minute
   talks followed by a group Q&A session.

* Chapel Poster: Ian Bertolacci (Colorado State University) will be
   presenting a poster on Tuesday evening, showing results from work he's
   been undertaking studying the abstraction of interesting tiling patterns
   using Chapel iterators.

* Chapel Users Group BoF: On Wednesday evening, we'll be doing a BoF
   designed to serve as a forum for users of Chapel (current and
   potential).  The BoF will start with a very brief introduction to Chapel
   and a rundown of recent Chapel events before opening the floor up to
   questions about Chapel and discussion about its future.

* CHUG Happy Hour: On Wednesday evening after the Chapel Users Group BoF,
   we'll be having our 5th Annual CHUG Happy Hour at Mulate's -- the same
   place where we kicked off the inaugural event in 2010.  Come join us!

* LLVM, Locality for Exascale, and PGAS BoFs: In addition to the
   Chapel-oriented BoFs above, the language will be represented during the
   week by members of the community at three other BoFs being organized
   by external groups.

If you are aware of other Chapel-oriented events that should be added to 
this list, please let us know.

We hope to see and meet many of you at SC14 this year!
-Brad Chamberlain
  (on behalf of the Chapel team)

------------------------------------------------------------------------------
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-announce mailing list
Cha...@li...
https://lists.sourceforge.net/lists/listinfo/chapel-announce

[Chapel-education] [Chapel-announce] Announcing Chapel version 1.10!

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

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk

[Chapel-education] The Fourth Annual Chapel Lightning Talks BoF @ SC14

[Sung-Eun C. <su...@cr...>]

Fourth Annual Chapel Lightning Talks @ SC14
New Orleans, LA
Tuesday November 18th, 2014
12:15pm - 1:15pm
http://chapel.cray.com/SC-BoF-LT.html

Call For Proposals

We are pleased to announce the Fourth Annual Chapel Lightning Talks
Birds-of-a-Feather session at SC14 this November. The BoF is designed
to highlight interesting work being done in or around Chapel across
the broad community: research collaborations, use of Chapel in
education, application studies, supporting technologies, etc.

As in previous years, we anticipate having ~6 talks @ 5 minutes each
as the core of the session. We'll start with a brief overview of the
Chapel project to provide context for the talks (also limited to 5
minutes) and will wrap up with a Q&A session involving all the
speakers.

To propose a talk, please send the following information to
cha...@cr... by October 10th:

* a proposed title
* a paragraph summarizing what you'd cover in your 5 minutes
* a short speaker bio
* (optional, but recommended) sample slides from previous talks
  demonstrating that you can create engaging slides; or that you've
  presented a short, lightning-style talk before. (Note that these can
  be from any technical talk or lecture; they don't need to be related
  to your proposed topic in any way).

>From the submissions, the organizers will curate a program for the
BoF, attempting to emphasize diverse and novel work. We will strive to
prioritize new work relative to the previous lightning talks BoFs,
though speakers from previous years are definitely encouraged to
submit a talk that highlights new work or progress.

Key Dates:

* October 10th: submissions due
* October 24th: author notification
* November 18th: Chapel Lightning Talks BoF @ SC14

BoF Organizers:

* Richard Barrett, Sandia National Laboratories
* Sung-Eun Choi, Cray Inc.

[Chapel-education] PGAS14 CFP (deadline extension and additional information)

[Jim D. <jam...@gm...>]

(Apologies if you got multiple copies of this email.)

Important Changes:
(1) Submission deadline extended to August 5th
(2) page limit and LaTeX template information added.

CALL FOR PAPERS

===============================================

The 8th International Conference on Partitioned Global Address Space
Programming Models (PGAS 2014)

http://nic.uoregon.edu/pgas14

October 7-10, 2014 University of Oregon and Hilton Eugene Eugene, Oregon,
USA

Held in cooperation with ACM SIGHPC

===============================================

Partitioned Global Address Space (PGAS) programming models offer a
shared address space model that simplifies programming while exposing
data/thread locality to enhance performance. This facilitates the
development of programming models that can deliver both productivity
and performance. The PGAS conference is the premier forum to present
and discuss ideas and research developments in the area of: PGAS
models, languages, compilers, runtimes, applications and tools, PGAS
architectures and hardware features. Topics of interest include, but
are not limited to:

* Applications. New applications that are uniquely enabled by the PGAS
model, existing applications and effective application development
practices for PGAS codes.

* Performance. Analysis of application performance over various
programming models.

*  Developments in Programming Models and Languages.  PGAS models,
language extensions, and hybrid models to address emerging
optimizations for PGAS languages, low level libraries, memory
consistency architectures, such as multicore, hybrid, heterogeneous,
SIMD and reconfigurable architectures.

*  Tools, Compilers, and Implementations. Integrated Development PGAS
Environments, performance analysis tools, and debuggers. Compiler
models. Hardware support for PGAS languages, performance studies and
insights, productivity studies, and language interoperability.


The PGAS Programming Models Conference is dedicated to the
presentation and discussion of research work in this field. Papers
should report on original research, and should include enough
background material to make them accessible to the entire PGAS
research community. Papers describing experiences should indicate how
they illustrate general principles; papers about parallel programming
foundations should indicate how they relate to practice.

Deadlines

* Paper submissions due date extended to: August 5, 2014
* Notification to authors of acceptance: September 1, 2014
* Camera-ready papers due: September 6, 2014
* Event takes place: October 7-10, 2014

Submissions

* Use ACM SIG template:
http://www.acm.org/sigs/publications/proceedings-templates

* No firm page limit. 10 pages are desired; 8-12 pages will be
accepted. The content must justify the length in the case of longer
papers.

* We are using EasyChair to manage submissions. Papers may be
submitted at: https://www.easychair.org/conferences/?conf=pgas14

Proceedings

The proceedings will be archived in both the ACM Digital Library and
IEEE Xplore, by virtue of SIGHPC.

Organizing Committee

Allen D. Malony, U. Oregon, General Chair
Sameer Shende, U. Oregon, Local Arrangements Chair
Wyatt Spear, U. Oregon, Web Chair
Khaled Hamidouche, Ohio State University, Publicity Chair

Program Committee

Jeff Hammond, Intel Labs (Chair)
Gheorge Almasi, IBM
Eric Bohm, University of Illinois, Urbana-Champaign
Dan Bonachea, Lawrence Berkeley National Laboratory
Sunita Chandrasekaran, University of Houston
Sung-Eun Choi, Cray
Jim Dinan, Intel
Michael Ferguson, Department of Defense (USA)
Hal Finkel, Argonne National Laboratory
Michael Garland, NVIDIA
Dave Grove, IBM
Oscar Hernandez, Oak Ridge National Laboratory
Torsten Hoefler, ETH Zürich
Sriram Krishnamoorthy, Pacific Northwest National Laboratory
Bill Long, Cray
Jack Poulson, Georgia Tech
Alistair Rendell, Australian National University
Vivek Sarkar, Rice University
Mitsuhisa Sato, University of Tsukuba
Guangming Tan, Institute of Computing Technology of the Chinese
Academy of Sciences
Vinod Tipparaju, AMD
Keith Underwood, Intel
Nathan Wichmann, Cray

Steering Committee

Lauren Smith, DoD
Tarek El-Ghazawi, George Washington University
William W. Carlson, IDA
Katherine Yelick, Lawrence Berkeley National Laboratory

Contact Information

Allen D. Malony (ma...@cs...)
Sameer Shende (sa...@cs...)
Jeff Hammond (jef...@ac...)

[Chapel-education] PGAS14 CFP

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

Hi Chapel Community --

If you are doing Chapel-related work and looking for a place to publish 
it, the annual PGAS workshop is a good venue to consider.  Its deadline is 
just under 2 months away (July 29th).  See the full call for papers below.

-Brad



CALL FOR PAPERS

=============================================================

The 8th International Conference on Partitioned
Global Address Space Programming Models (PGAS 2014)
http://nic.uoregon.edu/pgas14

October 7-10, 2014
University of Oregon
Eugene, Oregon, USA

Held in cooperation with ACM SIGHPC

=============================================================

Partitioned Global Address Space (PGAS) programming models offer a
shared address space model that simplifies programming while exposing
data/thread locality to enhance performance. This facilitates the
development of programming models that can deliver both productivity
and performance. The PGAS conference is the premier forum to present
and discuss ideas and research developments in the area of: PGAS
models, languages, compilers, runtimes, applications and tools, PGAS
architectures and hardware features.

Topics of interest include, but are not limited to:
* Applications. New applications that are uniquely enabled by the PGAS
model, existing applications and effective application development
practices for PGAS codes.
* Performance. Analysis of application performance over various
programming models.
* Developments in Programming Models and Languages. PGAS models,
language extensions, and hybrid models to address emerging
architectures, such as multicore, hybrid, heterogeneous, SIMD and
reconfigurable architectures.
* Tools, Compilers, and Implementations. Integrated Development
Environments, performance analysis tools, and debuggers. Compiler
optimisations for PGAS languages, low level libraries, memory
consistency models. Hardware support for PGAS languages, performance
studies and insights, productivity studies, and language
interoperability.

The PGAS Programming Models Conference is dedicated to the
presentation and discussion of research work in this field. Papers
should report on original research, and should include enough
background material to make them accessible to the entire PGAS
research community. Papers describing experiences should indicate how
they illustrate general principles; papers about parallel programming
foundations should indicate how they relate to practice.

# Deadlines

* Paper submissions due: July 29, 2014
* Notification to authors of acceptance: September 1, 2014
* Camera-ready papers due: September September 6, 2014
* Event takes place: October 7-10, 2014

# Submissions

We are using EasyChair to manage submissions.  The link to submit
papers will be added to the conference home page in the near future.

# Proceedings

The proceedings will be archived in both the ACM Digital Library and
IEEE Xplore, by virtue of SIGHPC.

# Organizing Committee

Allen D. Malony, U. Oregon, General Chair
Sameer Shende, U. Oregon, Local Arrangements Chair
Wyatt Spear, U. Oregon, Web Chair

# Program Committee

Jeff Hammond, Intel Labs (Chair)
Gheorge Almasi, IBM
Eric Bohm, University of Illinois, Urbana-Champaign
Dan Bonachea, Lawrence Berkeley National Laboratory
Sunita Chandrasekaran, University of Houston
Sung-Eun Choi, Cray
Jim Dinan, Intel
Michael Ferguson, Department of Defense (USA)
Hal Finkel, Argonne National Laboratory
Michael Garland, NVIDIA
Dave Grove, IBM
Oscar Hernandez, Oak Ridge National Laboratory
Torsten Hoefler, ETH Zürich
Sriram Krishnamoorthy, Pacific Northwest National Laboratory
Bill Long, Cray
Jack Poulson, Georgia Tech
Alistair Rendell, Australian National University
Vivek Sarkar, Rice University
Mitsuhisa Sato, University of Tsukuba
Guangming Tan, Institute of Computing Technology of the Chinese
Academy of Sciences
Vinod Tipparaju, AMD
Keith Underwood, Intel
Nathan Wichmann, Cray

# Steering Committee

Lauren Smith, DoD
Tarek El-Ghazawi, George Washington University
William W. Carlson, IDA
Katherine Yelick, Lawrence Berkeley National Laboratory

# Contact Information

Allen D. Malony (ma...@cs...)
Sameer Shende (sa...@cs...)
Jeff Hammond (jef...@ac...)

[Chapel-education] [Chapel-announce] CHIUW in 2-1/2 weeks!!

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

Chapel Community --

This is a quick reminder that CHIUW (the Chapel Implementers and Users 
Workshop) will be held in just 2-1/2 weeks, on Friday May 23rd, as part of 
IPDPS 2014.  We hope to see you and your colleagues there!

The backbone of the workshop will be composed of technical talks 
describing Chapel application studies, language extensions, compiler 
optimizations, and runtime improvements.  The day will start with a brief 
introduction to Chapel and the project's status.  Mid-day, Robert Harrison 
(BNL/SBU) will be giving a keynote presentation on MADNESS and Chapel. 
The workshop will wrap up with a community/panel discussion on Chapel's 
future and priorities.

For details on the program, including extended abstracts for the talks, 
please refer to:

 	http://chapel.cray.com/CHIUW.html

Register for CHIUW through the IPDPS 2014 page at:

 	http://www.ipdps.org/

See you in Phoenix!
-Brad


------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
Chapel-announce mailing list
Cha...@li...
https://lists.sourceforge.net/lists/listinfo/chapel-announce

[Chapel-education] [Chapel-announce] Announcing Chapel 1.9.0!

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

Chapel commmunity --

Cray Inc. and the Chapel developer community are pleased to announce
the release of version 1.9.0 of Chapel.  This release's highlights
include:

* Improved operator precedence for bitwise operators, '..' and 'in'.
   See the Quick Reference guide in the release or on the web
   (http://chapel.cray.com/spec/quickReference.pdf) to view the revised
   precedence table.

* The ability for users to provide their own overloads for the
   assignment operator.  For example:

     proc =(ref lhs:mytype, rhs:mytype) { ... }

* Improved the mapping of Chapel's atomic variables to intrinsic
   hardware capabilities when using Intel and Cray compilers as the
   back-end compiler.

* Significant performance improvements and reductions in
   compiler-introduced memory leaks.  To see or track changes in Chapel
   performance over time, refer to our newly-available-to-the-public
   performance tracking graphs at: http://chapel.sourceforge.net/perf/
   See the 'Performance Improvements' and 'Memory Improvements'
   sections of the CHANGES file (excerpted at the bottom of this
   message) for more details in what has improved.

* Several new Chapel versions of the Computer Language Benchmarks Game
   (http://benchmarksgame.alioth.debian.org/) computations are now
   available in the examples/benchmarks/shootout/ directory.

* Improved the performance of most nested data parallel idioms by
   flipping the default value of dataParIgnoreRunningTasks from 'false'
   to 'true'.  This causes inner data parallel loops to be sensitive to
   the number of tasks that are already running rather than assuming
   that they are the only thing running.  See the "Controlling Degree
   of Data Parallelism" section in doc/README.executing for more
   details.

* Significantly improved the quality and production-readiness of the
   LLVM back-end.  See doc/technotes/README.llvm for more information.

* Improved the symmetry of program startup and execution across the
   locales a program is running on.  Historically, there has been an
   asymmetry in which locale #0 has set up its tasks and threads in a
   manner that was distinct from all other locales.

* Added a 'make check' rule to the top-level Makefile that can be used
   to validate that a build seems to be compiling and running
   correctly.

* Made significant improvements to the testing system, particularly
   for performance testing scenarios.

* Implemented numerous bug fixes.  See the "Bug Fixes" section in the
   CHANGES file, excerpted at the end of this file, for details.

...and much more!  See below for a more complete list of changes in
version 1.9.0, or refer to $CHPL_HOME/CHANGES within the release
itself.

Contributors to this release include:

   Kyle Brady, Cray Inc.
   Brad Chamberlain, Cray Inc.
   Sung-Eun Choi, Cray Inc.
   Lydia Duncan, Cray Inc.
   Michael Ferguson, LTS
   Akihiro Hayashi, Rice University
   Tom Hildebrandt, Cray Inc.
   David Iten, Cray Inc.
   Rafael Larrosa Jiminez, University of Malaga
   Vassily Litvinov, Cray Inc.
   Jun Nakashima, University of Tokyo
   Elliot Ronaghan, Cray Inc./Moravian College
   Brandon Ross, University at Buffalo
   Greg Titus, Cray Inc.
   Thomas Van Doren, Cray Inc.
   Chris Wailes, Indiana University

To download the release, visit our SourceForge page at:

          http://sourceforge.net/projects/chapel

At this site, you can also browse the mailing list archives and track
our progress day-by-day.  Our main project page continues to be hosted
at:

          http://chapel.cray.com

and it remains the best place to browse papers, presentations,
documents, tutorials, and news items; or to read about collaborations
with researchers and educators.

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

On behalf of the Chapel Team,
-Brad Chamberlain

=============
version 1.9.0
=============

Twelfth public release of Chapel, April 17, 2014

Highlights (see entries in subsequent categories for details)
-------------------------------------------------------------
* numerous performance improvements (see 'Performance Improvements' below)
* significant reductions in compiler-introduced memory leaks
* added five new Computer Language Benchmark Games to the examples/ directory
* improved operator precedence for '|', '^', '&', '<<', '>>', '..', and 'in'
* added the ability for a user to create overloads of the assignment operator
* implemented atomic variables using intrinsics for Intel and Cray compilers
* flipped the default nested parallelism policy via dataParIgnoreRunningTasks
* significantly improved the stability/generality of the LLVM back-end
* added a slurm-srun launcher for use with native SLURM and improved pbs-aprun
* added a 'make check' rule to the top-level Makefile to validate a build
* improved the symmetry of program startup and polling across the locales
* significant improvements to the testing system, esp. performance testing
* updates to the GASNet and GMP packages and new snapshots of hwloc and re2
* improved the code base's portability w.r.t. clang, gcc, Mac OS X, Debian 7.4
* numerous bug fixes (see 'Bug Fixes' below)

Packaging Changes
-----------------
* added a 'make check' rule to the top-level Makefile to validate a build
* removed the half-hearted support for Chapel syntax highlighting in emacs 21

Environment Changes
-------------------
* added a new CHPL_HWLOC environment variable to control the use of 'hwloc'
   (see doc/README.chplenv)
* made CHPL_*_COMPILER default to 'clang' for CHPL_*_PLATFORM 'darwin'
* made CHPL_TASKS default to 'qthreads' when CHPL_LOCALE_MODEL == 'numa'
* made CHPL_HWLOC default to 'hwloc' when CHPL_TASKS = 'qthreads'
* established a 1:1 correspondance between CHPL_TASKS and CHPL_THREADS options
* deprecated the user-controlled CHPL_THREADS environment variable
* removed support for CHPL_TASKS=none due to lack of significant utility
* made GASNet use the 'large' segment by default for the 'ibv' conduit
* made CHPL_LAUNCHER default to 'gasnetrun_ibv' when using GASNet's mxm conduit
   (see doc/README.launcher)

Semantic Changes / Changes to Chapel Language
---------------------------------------------
* improved operator precedence for '|', '^', '&', '<<', '>>', '..', and 'in'
   (see precedence tables in the 'Expressions' spec chapter or quick ref card)
* added the ability for a user to create overloads of the assignment operator
   (see 'Statements' chapter in the language specification)
* added a 'noinit' capability to squash default initialization for basic types
   (see 'Variables' chapter in the language specification)
* for a domain D, previously {D} == D; now it interprets it as 'domain(D.type)'
* added support for an expression-less 'serial' statement
   (i.e., 'serial do' == 'serial true do')
* added support for dynamic casts of the 'nil' value, producing 'nil'
   (see 'Conversions' chapter of the language specification)
* clarified that deleting a 'nil' value is OK and will have no effect
   (see 'Classes' chapter of the language specification)
* added the ability to mark the 'this' as having 'ref' intent for methods
   (see 'Classes' chapter of the language specification)

New Features
------------
* implemented support for the 'break' statement within param loops

Changes to the Implementation
-----------------------------
* dataParIgnoreRunningTasks is now 'false' by default for locale model 'flat'
   (see doc/README.executing for details)
* changed the default size of the call stack size to 8 MiB for all task options
   (see doc/README.tasks for details)

New Interoperability Features
-----------------------------
* extended c_ptrTo() to support 1D rectangular arrays
* added support for casts between c_ptr types

Standard Modules
----------------
* added support for abs() on imaginary types
* added isSubtype() and isProperSubtype() queries to the standard Types module
   (see 'Standard Modules' chapter of the spec for details)

Documentation
-------------
* added descriptions of 'atomic' variables and 'noinit' expressions to the spec
   (see the 'Task Parallelism and Synchronization' and 'Variables' sections)
* clarified specification of casting from numeric types to 'bool'
* reworked LICENSE files to clarify third-party licenses and isolate BSD text
   (see LICENSE and LICENSE.chapel)
* refreshed and reorganized README.tasks
* documented that 'clang' is available as a CHPL_*_COMPILER option
   (see doc/README.chplenv)
* improved description of Cray-specific runtime environment variables
   (see doc/platforms/README.cray)
* clarified formatted I/O documentation regarding width/precision
   (see doc/technotes/README.io)
* added a performance notes file (PERFORMANCE)
* removed the user agreement (AGREEMENT)
* generally refreshed README-based documentation
* general updates and improvements to the language specification

Example Codes
-------------
* added new Chapel ports of several Computer Language Benchmark Games (CLBG)
   (see spectralnorm.chpl, mandelbrot.chpl, fannkuchredux.chpl, meteor.chpl,
    and pidigits.chpl in benchmarks/shootout/)
* added an improved/simplified version of the CLBG chameneos-redux example
   (see benchmarks/shootout/chameneosredux.chpl)
* improved the release versions of RA to use atomic rather than sync vars
* made the examples/programs/tree.chpl example reclaim its memory
* made minor improvements to the MiniMD example and primer examples
* fixed a few incorrect statements in comments within primers/syncsingle.chpl

Cray-specific Notes
-------------------
* changed Cray XC Systems(TM) to use GASNet over the aries conduit by default
* added a slurm-srun launcher for use with Cray systems supporting native SLURM

Launcher-specific Notes
-----------------------
* added a slurm-srun launcher for use with native SLURM systems
* improved the pbs-aprun launcher for use with Moab/Torque
* made the gasnetrun_ibv launcher forward all CHPL_ environment variables
* made the 'aprun' launcher more careful about when it can correctly use '-j'

Portability of code base
------------------------
* improved code base's portability to newer versions of gcc
* improved code base's portability to Darwin/Mac OS X and Debian 7.4
* improved code base's portability for compilation with 'clang'
* enabled 'tcmalloc' to be built on Cray XC systems

Compiler Flags (see 'man chpl' for details)
-------------------------------------------
* removed the --serial and --serial-forall flags; use serial statements instead
* started ignoring --static for Mac OS X since it isn't well-supported
* added a --print-passes-file flag to print passes to a specified filename

Error Message Improvements
--------------------------
* changed the wording of internal errors for succinctness

Performance Improvements
------------------------
* implemented atomic variables using intrinsics for Intel and Cray compilers
* optimized whole-array binary read/write operations for default domains/arrays
* extended global constant replication to additional types
* improved the compiler's ability to remote value forward values
* optimized away sublocale-related code for the 'flat' locale model
* improved 'numa' locale model performance for --local compilations)
* optimized blocking on sync variables for 'fifo' tasking based on # of tasks
* within serial sections, optimized forall loops over ranges, domains, arrays
* improved the task accounting for loops over Block-distributed arrays
* improved the loop-invariant code motion optimization's use of alias analysis
* removed unnecessary copies for formal arguments
* optimized program startup times in several ways

Locale Model Improvements
-------------------------
* improved the 'numa' locale model to reduce unnecessary changes in sublocale
* improved the 'numa' locale model's range, domain, and array iterators

Memory Improvements
-------------------
* reduced compiler-introduced memory leaks, particulary in I/O code
* reduced memory usage due to compiler-introduced copies on primitive types
* improved the reclamation of arrays of sync/single variables
* moved the end-of-program memory reporting to a point after the runtime exits

Third-Party Software Changes
----------------------------
* updated GASNet to version 1.22.0 with a patch to fix 'aries' conduit bugs
* added a snapshot of hwloc version 1.7.2 for compute node introspection
* added a snapshot of re2 (20140111) to the third-party directory
* added a snapshot of dygraphs to the third-party directory for perf graphs
* updated our snapshot of GMP to version 6.0.0
* various minor improvements to the Qthreads tasking layer
* disabled pshm for all non-udp GASNet conduits

Bug Fixes / New Semantic Checks (for old semantics)
---------------------------------------------------
* improved const-ness checking for const fields and const records/unions
* added a semantic check for tuple size mismatch when destructuring a tuple
* fixed a bug in which [u]int & imag literals were represented incorrectly
* fixed a bug where iterators with complex control flow could yield bad values
* fixed a bug in which timer.clear() did not reset the timer if it was running
* fixed a bug in which abs() on reals incorrectly called the complex version
* fixed a bug in converting between Chapel and C strings
* fixed a bug in which casts from ints/uints to bools were not always correct
* fixed some problems with the GMP random number routines
* fixed a bug on Cygwin for usernames with spaces in them
* extended global constant replication to additional types
* fixed a "read after freed" bug on domains used in nonblocking on calls
* fixed bug in loop invariant code motion related to aliasing in records/tuples
* fixed a subtle/minor race condition regarding accounting of tasks
* fixed Qthreads tasking layer bug resulting incorrect task placement
* fixed a bug in which Qthreads was asked for task-local storage prematurely
* fixed a potential race in task reporting (-t/--taskreport)
* fixed an optimization shortcut for array reindexing
* fixed a bug in which while loops warned about testing against local consts
* improved 'printchplenv' to avoid perl problems in unexpected cases

Runtime Library Changes
-----------------------
* improved the symmetry of program startup and polling across the locales
* improved descriptions of the runtime communication interface in chpl-comm.h
* simplified the implementation of the registry of global variables
* added ability for fifo tasks to implement thread-level storage using __thread

Generated Code Cleanups
-----------------------
* simplified the implementation of operations on homogeneous tuples
* removed the passing of wide strings by ref by default
* squashed the code generation of an unused program initialization function
* squashed redundant calls to initialize the ChapelStandard module
* folded out tautological comparisons between uints and 0s (e.g., myuint >= 0)

Compiler Performance
--------------------
* short-circuited the beautify pass if --savec is not specified
* short-circuited some logic in the parallel pass for --local compiles

Compiler Improvements
---------------------
* significantly improved the stability/generality of the LLVM back-end
* re-implemented copy propagation to handle aliases better
* made de-nested functions use 'const' arguments in more cases

Testing System
--------------
* added the ability to run multiple trials of each test to the testing system
* added support for sweeping current performance tests across past releases
* added the ability to track compiler performance during testing
* added a regexp-based correctness check capability for performance tests
* changed performance testing to support --fast by default
* added a script to splice .dat files created by performance testing
* permit SLURM to control the node list for parallel testing
* replaced 'paratest.server's -duplex flag with -nodepara for oversubscription
* added a capability to add annotations to performance graphs
* made performance testing compile with --static by default
* in generating performance graphs, the previous directory is now removed
* added a capability for the performance graphs to be rsync'd to SourceForge
* added a logarithmic/linear toggle to the generated performance graphs
* added a capability for the 'nightly' script to svn commit performance data
* added additional print messages to 'nightly' to better describe progress
* added a -retaintree option to 'nightly' to use the existing writable tree
* added support for testing the '--fast' flag in the 'nightly' script
* worked on making the testing system less Cray-centric in its design
* made test scripts send mail to the sourceforge mailing lists by default
* added options for naming test suites, specifying recipients, etc.
* unified the naming and structure of the cron job testing scripts
* removed reliance on tcsh-specific features for improved csh portability

Makefile Changes
----------------
* made all builds update Makefile dependences, not just developer builds 
* made Makefiles propagate CFLAGS/CXXFLAGS to third-party builds

Internal/Developer-oriented
---------------------------
* added dataPar* arguments to these() iterators for ranges/default rectangular
* made Block's leader iterator forward to DefaultRectangular
* made sure that arguments to exported functions are always local/narrow
* changed most assignment operator signatures to take the LHS by 'ref'
* added support for a "minimal modules" compilation mode for core language work
* added a developer flag --report-optimized-loop-iterators to track loop opts
* made internal errors appear as such in developer mode
* refactored the reference count code for domain maps, domains, and arrays
* switched to a symbolic initializer for locale IDs to improve flexibility
* refactored QIO and Regexp reference counting
* deprecated the internal InitPrivateGlobals module
* added config params to support program startup communication diagnostics
   (see 'printInitVerboseComm' and 'printInitCommCounts')
* added a verification pass to ensure ref types for return types are available
* renamed NUM_KIND_FLOAT to NUM_KIND_REAL
* renamed 'Class'->'Aggregate' in the compiler sources when record|class|union
* switched to a bulk copy of flags when copying Symbol classes
* changed the representation of intents to support bitmasks
* moved the initialization of memory tracking from the modules to the runtime
* removed user-level memory leaks from example codes in the language spec
* created FLAG_COMPILER_GENERATED to separate functions/labels from FLAG_TEMP
* added PRIM_IS_ATOMIC_TYPE to query whether something is an atomic type
* added new primitives for querying whether a type is a tuple, sync, or single
* improved the internal use cases of 'printchplenv'
* removed redundant overloads of ==/!= for syserr and err_t
* improved the implementation when 'noRefCount' is true
* removed no-longer-necessary _ensure_reference_type() feature
* changed extern routines that take string arguments to take 'c_string' instead
* changed extern routines that take 'inout' arguments to 'ref' when appropriate
* numerous refactorings of the compiler code for clarity and/or effiency




------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Chapel-announce mailing list
Cha...@li...
https://lists.sourceforge.net/lists/listinfo/chapel-announce

[Chapel-education] [Chapel-announce] CHIUW/IPDPS: Advance Program available, Advance Registration due 3/25

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

Hi Chapel Community --

We've just posted the Advance Program for CHIUW (the Chapel Implementers 
and Users Workshop) to the Chapel website:

 	http://chapel.cray.com/CHIUW.html

It includes 8 contributed talks on a variety of Chapel-related topics from 
the broad Chapel community, a keynote from Robert Harrison (SBU/BNL), a 
brief overview of Chapel and the project's status, and a community/panel 
discussion to wrap up the day.

CHIUW will be held on Friday, May 23rd as part of IPDPS.  Advance 
Registration for attending is due on March 25th (5 days from now) and can 
save you $100+ depending on your registration type.

We hope to see you there!
-Brad
(on behalf of the CHIUW steering committee)

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Chapel-announce mailing list
Cha...@li...
https://lists.sourceforge.net/lists/listinfo/chapel-announce

Re: [Chapel-education] [Chapel-announce] Reminder: CHIUW talk proposals due today

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

Hi Chapel Community --

Just a quick reminder that the deadline for CHIUW talk proposals is today.

I'm personally not a big fan of deadline extensions, but if you have 
something that you'd really like to propose and simply can't get it in 
today, let me know and I'll pass such requests along to the steering 
committee for consideration along with the summary of what we received.

Thanks,
-Brad


On Thu, 9 Jan 2014, Brad Chamberlain wrote:

>
> Hi Chapel Community --
>
> As a quick reminder, the deadline to propose a talk for CHIUW (the Chapel 
> Implementers and Users Workshop) is coming up on January 17th.  CHIUW itself 
> will be held on Friday, May 23rd as an IPDPS workshop.
>
> The proposal process is intended to be short and sweet: Submit an extended 
> abstract of no more than a page describing your proposed talk.  Please see 
> the CHIUW website for more information on the workshop and submission 
> process.
>
> Thanks very much,
> -Brad
>

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-announce mailing list
Cha...@li...
https://lists.sourceforge.net/lists/listinfo/chapel-announce

[Chapel-education] [Chapel-announce] Reminder: CHIUW talk proposals due Jan 17th

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

Hi Chapel Community --

As a quick reminder, the deadline to propose a talk for CHIUW (the Chapel 
Implementers and Users Workshop) is coming up on January 17th.  CHIUW 
itself will be held on Friday, May 23rd as an IPDPS workshop.

The proposal process is intended to be short and sweet: Submit an extended 
abstract of no more than a page describing your proposed talk.  Please see 
the CHIUW website for more information on the workshop and submission 
process.

Thanks very much,
-Brad

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-announce mailing list
Cha...@li...
https://lists.sourceforge.net/lists/listinfo/chapel-announce

Re: [Chapel-education] cutting a range in half

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

This is probably clear given my previous message, but it's because the 
elements of 'rangeHalves' are the 'range' type with all its default 
values.  This is part of what I was trying to get away from in my 
suggestion to return an array or tuple literal rather than naming the 
variable to be returned -- that permits you and the compiler to rely on 
type inference rather than having to specify all the characteristics of 
the ranges being taken in as arguments and returned.  It also means that 
your splitRange() routine will be less sensitive to the range types that 
are passed in (e.g., an optimal splitRange() routine would take ranges of 
any idxType and return ranges of the same idxType whereas any declaration 
of 'range' type will take the default idxType regardless of what the input 
argument is).

-Brad


On Sat, 28 Dec 2013, Kyle Burke wrote:

> Brad & All,
>
> Follow-up question.  I've rewritten splitRange:
>
> proc splitRange(rangeToSplit : range(stridable = true)) {
>    var rangeHalves: [0..1] range;
>    if (rangeToSplit.size <= 1) {
>        rangeHalves[0] = rangeToSplit;
>        rangeHalves[1] = 0..-1;
>    } else {
>        var oldStride = rangeToSplit.stride;
>        writeln("oldStride: ", oldStride);
>        var newStride = oldStride * 2;
>        writeln("newStride: ", newStride);
>        writeln("Is rangeToSplit stridable?  ", rangeToSplit.stridable);
>        rangeHalves[0] = rangeToSplit by newStride;
>        rangeHalves[1] = (rangeToSplit by (rangeToSplit.stride * 2)) align
> (rangeToSplit.stride + rangeToSplit.alignedLow);
>    }
>    return rangeHalves;
> }
>
> Unfortunately, when I call it on:
> var rangeA: range (stridable=true) = 0..14;
> var rangeAHalves = splitRange(rangeA);
>
> I get the following error:
>
> oldStride: 1
> newStride: 2
> Is rangeToSplit stridable?  true
> .......  error: halt reached - non-stridable range assigned non-unit stride
>
> (The error is occuring in the line: rangeHalves[0] = rangeToSplit by
> newStride; )
>
> -Kyle
>
>
>
> On Sat, Dec 28, 2013 at 3:56 PM, Kyle Burke <pai...@gm...> wrote:
>
>> Brad,
>>
>> Thanks so much! :)  This is really helpful!
>>
>> Why does the following cause a run-time error:
>>
>> var rangeA: range = 0..14 by 2;
>>
>> But the following does not?
>>
>> var rangeA: range = 0..14;
>> writeln(rangeA);
>>
>> I'm sure I'll have more questions in the future. :)
>>
>> -Kyle
>>
>>
>>
>> On Fri, Dec 20, 2013 at 3:51 PM, Brad Chamberlain <br...@cr...> wrote:
>>
>>>  Hi Kyle --
>>>
>>>  Here's what's going on in this test...
>>>
>>>  The stridability (or not) of a range is a compile-time (param)
>>> characteristic of the range type and its whole purpose in life is to give
>>> the implementation the ability to optimize away unnecessary overhead in the
>>> (common) case that a range value will never be strided.  Specifically,
>>> since arrays are built from domains which are built from ranges, array
>>> accesses can be much more efficiently expressed when it's known that their
>>> index ranges are dense.
>>>
>>>  What this means is that a line like:
>>>
>>>    rangeToSplit.stridable = true;
>>>
>>>  doesn't work in Chapel because it'd be like trying to change the type
>>> (or a static property of the type) at execution time in the language.
>>>
>>>  Another piece of this is that in a declaration context, the undecorated
>>> type 'range' causes its type properties to be set to their defaults.  For
>>> example:
>>>
>>>    var r: range = 1..10 by 2;
>>>
>>>  is illegal (will generate a runtime error) because ranges are
>>> unstridable by default and so this is trying to assign an strided range
>>> value to an unstridable range variable.  To fix this, one would use:
>>>
>>>    var r: range(stridable=true) = 1..10 by 2;
>>>
>>>  Similarly, in your argument declaration, you're essentially asserting
>>> that this function should take an unstridable range as its argument for
>>> similar reasons.  If you wanted to make the function generic with respect
>>> to the stridability of the range, a quick shorthand for doing so would be:
>>>
>>>    proc splitRange(rangeToSplit: range(?)) {
>>>   }
>>>
>>>  which says "rangeToSplit is a range whose type arguments can be
>>> anything (any index type, any stridability, any boundedness, etc.).
>>>
>>>  So, I believe the quick fix to your program as it stands would be to
>>> declare 'rangeHalves' to be an array of range(stridable=true).
>>>
>>>  Since declaring the stridability of ranges is a bit verbose and
>>> annoying, this is also a great opportunity to lean on the type inference
>>> capabilities of the language.  For example, rather than declaring the array
>>> of ranges to return, you could just return an array literal of ranges:
>>>
>>>    return [ rangeToSplit by newStride,
>>>               rangeToSplit by ....  align .... ];
>>>
>>>  (the one thing I had to change in your code to make this work is to
>>> change the callsite to refer to these elements as '1' and '2' rather than
>>> '0' and '1' since anonymous arrays use 1-based indexing).
>>>
>>>  That said, for cases like this ("I want to return two things") I think
>>> tuples are a better choice in that they're lighter-weight, don't require
>>> the types to be identical, and support de-tupling syntax at the callsite.
>>>  For example, I would tend to write your program using idioms like:
>>>
>>>    return (rangeToSplit by newStride,
>>>              rangeToSplit by ... align ... );
>>>
>>>  and
>>>
>>>    var (rangeB, rangeC) = splitRange(rangeA);
>>>
>>>  Hope this is a helpful start to getting you unstuck,
>>> -Brad
>>>
>>>
>>>   ------------------------------
>>> *From:* Kyle Burke [pai...@gm...]
>>> *Sent:* Friday, December 20, 2013 6:31 AM
>>> *To:* cha...@li...
>>> *Subject:* [Chapel-education] cutting a range in half
>>>
>>>     Hello Chapel Educators,
>>>
>>>  I'm trying to come up with some good Chapel homework questions.  One of
>>> these could be:
>>>
>>> Write a function, splitRange, that takes a stridable and finite range and
>>> returns an array containing 2 halves of the given range.  I'd like to use
>>> striding to try to do the splitting in constant time.  Unfortunately, it
>>> seems that stridable ranges become unstridable inside the function call.
>>>
>>>  Here's my attempt:
>>>
>>> /**
>>>  * Divides a range into two equal parts.  Precondition: rangeToSplit must
>>> be stridable and finite!
>>>  */
>>> proc splitRange(rangeToSplit : range) {
>>>     var rangeHalves: [0..1] range;
>>>     if (rangeToSplit.size <= 1) {
>>>         rangeHalves[0] = rangeToSplit;
>>>         rangeHalves[1] = 0..-1;
>>>     } else {
>>>         //rangeToSplit.stridable = true;
>>>         var oldStride = rangeToSplit.stride;
>>>         writeln("oldStride: ", oldStride);
>>>         var newStride = oldStride * 2;
>>>         writeln("newStride: ", newStride);
>>>         rangeHalves[0] = rangeToSplit by newStride;
>>>         rangeHalves[1] = (rangeToSplit by (rangeToSplit.stride * 2))
>>> align (rangeToSplit.stride + rangeToSplit.alignedLow);
>>>     }
>>>     return rangeHalves;
>>> }
>>>
>>>  Here's my test code:
>>>
>>> /**
>>>  * Prints out all elements in a range.
>>>  */
>>> proc printRange(rangeToPrint) {
>>>     for element in rangeToPrint {
>>>         write(element);
>>>         if (element != rangeToPrint.last) {
>>>             write(", ");
>>>         }
>>>     }
>>>     writeln("");
>>> }
>>>
>>> //tests for splitRange
>>>
>>> var rangeA = 0..14;
>>> write("rangeA: ");
>>> printRange(rangeA);
>>> printRange(rangeA by 2);
>>> var rangeAHalves = splitRange(rangeA);
>>> var rangeB = rangeAHalves[0];
>>> var rangeC = rangeAHalves[1];
>>> write("rangeB: ");
>>> printRange(rangeB);
>>> write("rangeC: ");
>>> printRange(rangeC);
>>>
>>>  It's able to stride rangeA by 2 outside the call to splitRange, but not
>>> inside.  Anyone have any experience with this issue?
>>>
>>>  -Kyle
>>>
>>> --
>>> Me: kg...@co...  (or pai...@gm...)
>>> http://www.cs.colby.edu/kgburke/
>>>
>>
>>
>>
>> --
>> Me: kg...@co...  (or pai...@gm...)
>> http://www.cs.colby.edu/kgburke/
>>
>
>
>
> -- 
> Me: kg...@co...  (or pai...@gm...)
> http://www.cs.colby.edu/kgburke/
>

Re: [Chapel-education] cutting a range in half

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

> Why does the following cause a run-time error:
> 
> var rangeA: range = 0..14 by 2;
> 
> But the following does not?
>
> var rangeA: range = 0..14;

Like many Chapel types, 'range' is a parameterized type that takes a 
number of arguments to fully specify its type.  If those arguments are not 
supplied (as in this example), they take on default values.  For example, 
an index type (idxType) can be specified to indicate the type of integers 
stored/generated by the range, but if it's not specified, it defaults to 
'int' (int(64)).

Stridability is another characteristic, and it defaults to 'non-stridable' 
which doesn't permit strided ranges to be stored by the range.  This 
choice was made to favor performance in the common (unstrided) case and 
generate an error in the uncommon case (which you're seeing).

As a result, the two ways to get a stridable range would be to specify the 
non-default value for whether the range is stridable:

 	var rangeA: range(stridable=true) = 0..14 by 2;

or to use type inference to have the compiler fill that in for you:

 	var rangeA = 0..14 by 2;

In either case, if you do:

 	writeln(rangeA);
 	writeln(typeToString(rangeA.type));

you'll get:

 	0..14 by 2
 	range(int(64),bounded,true)

-Brad

Re: [Chapel-education] cutting a range in half

[Kyle B. <pai...@gm...>]

Brad & All,

Follow-up question.  I've rewritten splitRange:

proc splitRange(rangeToSplit : range(stridable = true)) {
    var rangeHalves: [0..1] range;
    if (rangeToSplit.size <= 1) {
        rangeHalves[0] = rangeToSplit;
        rangeHalves[1] = 0..-1;
    } else {
        var oldStride = rangeToSplit.stride;
        writeln("oldStride: ", oldStride);
        var newStride = oldStride * 2;
        writeln("newStride: ", newStride);
        writeln("Is rangeToSplit stridable?  ", rangeToSplit.stridable);
        rangeHalves[0] = rangeToSplit by newStride;
        rangeHalves[1] = (rangeToSplit by (rangeToSplit.stride * 2)) align
(rangeToSplit.stride + rangeToSplit.alignedLow);
    }
    return rangeHalves;
}

Unfortunately, when I call it on:
var rangeA: range (stridable=true) = 0..14;
var rangeAHalves = splitRange(rangeA);

I get the following error:

oldStride: 1
newStride: 2
Is rangeToSplit stridable?  true
 .......  error: halt reached - non-stridable range assigned non-unit stride

(The error is occuring in the line: rangeHalves[0] = rangeToSplit by
newStride; )

-Kyle



On Sat, Dec 28, 2013 at 3:56 PM, Kyle Burke <pai...@gm...> wrote:

> Brad,
>
> Thanks so much! :)  This is really helpful!
>
> Why does the following cause a run-time error:
>
> var rangeA: range = 0..14 by 2;
>
> But the following does not?
>
> var rangeA: range = 0..14;
> writeln(rangeA);
>
> I'm sure I'll have more questions in the future. :)
>
> -Kyle
>
>
>
> On Fri, Dec 20, 2013 at 3:51 PM, Brad Chamberlain <br...@cr...> wrote:
>
>>  Hi Kyle --
>>
>>  Here's what's going on in this test...
>>
>>  The stridability (or not) of a range is a compile-time (param)
>> characteristic of the range type and its whole purpose in life is to give
>> the implementation the ability to optimize away unnecessary overhead in the
>> (common) case that a range value will never be strided.  Specifically,
>> since arrays are built from domains which are built from ranges, array
>> accesses can be much more efficiently expressed when it's known that their
>> index ranges are dense.
>>
>>  What this means is that a line like:
>>
>>    rangeToSplit.stridable = true;
>>
>>  doesn't work in Chapel because it'd be like trying to change the type
>> (or a static property of the type) at execution time in the language.
>>
>>  Another piece of this is that in a declaration context, the undecorated
>> type 'range' causes its type properties to be set to their defaults.  For
>> example:
>>
>>    var r: range = 1..10 by 2;
>>
>>  is illegal (will generate a runtime error) because ranges are
>> unstridable by default and so this is trying to assign an strided range
>> value to an unstridable range variable.  To fix this, one would use:
>>
>>    var r: range(stridable=true) = 1..10 by 2;
>>
>>  Similarly, in your argument declaration, you're essentially asserting
>> that this function should take an unstridable range as its argument for
>> similar reasons.  If you wanted to make the function generic with respect
>> to the stridability of the range, a quick shorthand for doing so would be:
>>
>>    proc splitRange(rangeToSplit: range(?)) {
>>   }
>>
>>  which says "rangeToSplit is a range whose type arguments can be
>> anything (any index type, any stridability, any boundedness, etc.).
>>
>>  So, I believe the quick fix to your program as it stands would be to
>> declare 'rangeHalves' to be an array of range(stridable=true).
>>
>>  Since declaring the stridability of ranges is a bit verbose and
>> annoying, this is also a great opportunity to lean on the type inference
>> capabilities of the language.  For example, rather than declaring the array
>> of ranges to return, you could just return an array literal of ranges:
>>
>>    return [ rangeToSplit by newStride,
>>               rangeToSplit by ....  align .... ];
>>
>>  (the one thing I had to change in your code to make this work is to
>> change the callsite to refer to these elements as '1' and '2' rather than
>> '0' and '1' since anonymous arrays use 1-based indexing).
>>
>>  That said, for cases like this ("I want to return two things") I think
>> tuples are a better choice in that they're lighter-weight, don't require
>> the types to be identical, and support de-tupling syntax at the callsite.
>>  For example, I would tend to write your program using idioms like:
>>
>>    return (rangeToSplit by newStride,
>>              rangeToSplit by ... align ... );
>>
>>  and
>>
>>    var (rangeB, rangeC) = splitRange(rangeA);
>>
>>  Hope this is a helpful start to getting you unstuck,
>> -Brad
>>
>>
>>   ------------------------------
>> *From:* Kyle Burke [pai...@gm...]
>> *Sent:* Friday, December 20, 2013 6:31 AM
>> *To:* cha...@li...
>> *Subject:* [Chapel-education] cutting a range in half
>>
>>     Hello Chapel Educators,
>>
>>  I'm trying to come up with some good Chapel homework questions.  One of
>> these could be:
>>
>> Write a function, splitRange, that takes a stridable and finite range and
>> returns an array containing 2 halves of the given range.  I'd like to use
>> striding to try to do the splitting in constant time.  Unfortunately, it
>> seems that stridable ranges become unstridable inside the function call.
>>
>>  Here's my attempt:
>>
>> /**
>>  * Divides a range into two equal parts.  Precondition: rangeToSplit must
>> be stridable and finite!
>>  */
>> proc splitRange(rangeToSplit : range) {
>>     var rangeHalves: [0..1] range;
>>     if (rangeToSplit.size <= 1) {
>>         rangeHalves[0] = rangeToSplit;
>>         rangeHalves[1] = 0..-1;
>>     } else {
>>         //rangeToSplit.stridable = true;
>>         var oldStride = rangeToSplit.stride;
>>         writeln("oldStride: ", oldStride);
>>         var newStride = oldStride * 2;
>>         writeln("newStride: ", newStride);
>>         rangeHalves[0] = rangeToSplit by newStride;
>>         rangeHalves[1] = (rangeToSplit by (rangeToSplit.stride * 2))
>> align (rangeToSplit.stride + rangeToSplit.alignedLow);
>>     }
>>     return rangeHalves;
>> }
>>
>>  Here's my test code:
>>
>> /**
>>  * Prints out all elements in a range.
>>  */
>> proc printRange(rangeToPrint) {
>>     for element in rangeToPrint {
>>         write(element);
>>         if (element != rangeToPrint.last) {
>>             write(", ");
>>         }
>>     }
>>     writeln("");
>> }
>>
>> //tests for splitRange
>>
>> var rangeA = 0..14;
>> write("rangeA: ");
>> printRange(rangeA);
>> printRange(rangeA by 2);
>> var rangeAHalves = splitRange(rangeA);
>> var rangeB = rangeAHalves[0];
>> var rangeC = rangeAHalves[1];
>> write("rangeB: ");
>> printRange(rangeB);
>> write("rangeC: ");
>> printRange(rangeC);
>>
>>  It's able to stride rangeA by 2 outside the call to splitRange, but not
>> inside.  Anyone have any experience with this issue?
>>
>>  -Kyle
>>
>> --
>> Me: kg...@co...  (or pai...@gm...)
>> http://www.cs.colby.edu/kgburke/
>>
>
>
>
> --
> Me: kg...@co...  (or pai...@gm...)
> http://www.cs.colby.edu/kgburke/
>



-- 
Me: kg...@co...  (or pai...@gm...)
http://www.cs.colby.edu/kgburke/

Re: [Chapel-education] cutting a range in half

[Kyle B. <pai...@gm...>]

Brad,

Thanks so much! :)  This is really helpful!

Why does the following cause a run-time error:

var rangeA: range = 0..14 by 2;

But the following does not?

var rangeA: range = 0..14;
writeln(rangeA);

I'm sure I'll have more questions in the future. :)

-Kyle



On Fri, Dec 20, 2013 at 3:51 PM, Brad Chamberlain <br...@cr...> wrote:

>  Hi Kyle --
>
>  Here's what's going on in this test...
>
>  The stridability (or not) of a range is a compile-time (param)
> characteristic of the range type and its whole purpose in life is to give
> the implementation the ability to optimize away unnecessary overhead in the
> (common) case that a range value will never be strided.  Specifically,
> since arrays are built from domains which are built from ranges, array
> accesses can be much more efficiently expressed when it's known that their
> index ranges are dense.
>
>  What this means is that a line like:
>
>    rangeToSplit.stridable = true;
>
>  doesn't work in Chapel because it'd be like trying to change the type
> (or a static property of the type) at execution time in the language.
>
>  Another piece of this is that in a declaration context, the undecorated
> type 'range' causes its type properties to be set to their defaults.  For
> example:
>
>    var r: range = 1..10 by 2;
>
>  is illegal (will generate a runtime error) because ranges are
> unstridable by default and so this is trying to assign an strided range
> value to an unstridable range variable.  To fix this, one would use:
>
>    var r: range(stridable=true) = 1..10 by 2;
>
>  Similarly, in your argument declaration, you're essentially asserting
> that this function should take an unstridable range as its argument for
> similar reasons.  If you wanted to make the function generic with respect
> to the stridability of the range, a quick shorthand for doing so would be:
>
>    proc splitRange(rangeToSplit: range(?)) {
>   }
>
>  which says "rangeToSplit is a range whose type arguments can be anything
> (any index type, any stridability, any boundedness, etc.).
>
>  So, I believe the quick fix to your program as it stands would be to
> declare 'rangeHalves' to be an array of range(stridable=true).
>
>  Since declaring the stridability of ranges is a bit verbose and
> annoying, this is also a great opportunity to lean on the type inference
> capabilities of the language.  For example, rather than declaring the array
> of ranges to return, you could just return an array literal of ranges:
>
>    return [ rangeToSplit by newStride,
>               rangeToSplit by ....  align .... ];
>
>  (the one thing I had to change in your code to make this work is to
> change the callsite to refer to these elements as '1' and '2' rather than
> '0' and '1' since anonymous arrays use 1-based indexing).
>
>  That said, for cases like this ("I want to return two things") I think
> tuples are a better choice in that they're lighter-weight, don't require
> the types to be identical, and support de-tupling syntax at the callsite.
>  For example, I would tend to write your program using idioms like:
>
>    return (rangeToSplit by newStride,
>              rangeToSplit by ... align ... );
>
>  and
>
>    var (rangeB, rangeC) = splitRange(rangeA);
>
>  Hope this is a helpful start to getting you unstuck,
> -Brad
>
>
>   ------------------------------
> *From:* Kyle Burke [pai...@gm...]
> *Sent:* Friday, December 20, 2013 6:31 AM
> *To:* cha...@li...
> *Subject:* [Chapel-education] cutting a range in half
>
>     Hello Chapel Educators,
>
>  I'm trying to come up with some good Chapel homework questions.  One of
> these could be:
>
> Write a function, splitRange, that takes a stridable and finite range and
> returns an array containing 2 halves of the given range.  I'd like to use
> striding to try to do the splitting in constant time.  Unfortunately, it
> seems that stridable ranges become unstridable inside the function call.
>
>  Here's my attempt:
>
> /**
>  * Divides a range into two equal parts.  Precondition: rangeToSplit must
> be stridable and finite!
>  */
> proc splitRange(rangeToSplit : range) {
>     var rangeHalves: [0..1] range;
>     if (rangeToSplit.size <= 1) {
>         rangeHalves[0] = rangeToSplit;
>         rangeHalves[1] = 0..-1;
>     } else {
>         //rangeToSplit.stridable = true;
>         var oldStride = rangeToSplit.stride;
>         writeln("oldStride: ", oldStride);
>         var newStride = oldStride * 2;
>         writeln("newStride: ", newStride);
>         rangeHalves[0] = rangeToSplit by newStride;
>         rangeHalves[1] = (rangeToSplit by (rangeToSplit.stride * 2)) align
> (rangeToSplit.stride + rangeToSplit.alignedLow);
>     }
>     return rangeHalves;
> }
>
>  Here's my test code:
>
> /**
>  * Prints out all elements in a range.
>  */
> proc printRange(rangeToPrint) {
>     for element in rangeToPrint {
>         write(element);
>         if (element != rangeToPrint.last) {
>             write(", ");
>         }
>     }
>     writeln("");
> }
>
> //tests for splitRange
>
> var rangeA = 0..14;
> write("rangeA: ");
> printRange(rangeA);
> printRange(rangeA by 2);
> var rangeAHalves = splitRange(rangeA);
> var rangeB = rangeAHalves[0];
> var rangeC = rangeAHalves[1];
> write("rangeB: ");
> printRange(rangeB);
> write("rangeC: ");
> printRange(rangeC);
>
>  It's able to stride rangeA by 2 outside the call to splitRange, but not
> inside.  Anyone have any experience with this issue?
>
>  -Kyle
>
> --
> Me: kg...@co...  (or pai...@gm...)
> http://www.cs.colby.edu/kgburke/
>



-- 
Me: kg...@co...  (or pai...@gm...)
http://www.cs.colby.edu/kgburke/

Re: [Chapel-education] cutting a range in half

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

Hi Kyle --

Here's what's going on in this test...

The stridability (or not) of a range is a compile-time (param) characteristic of the range type and its whole purpose in life is to give the implementation the ability to optimize away unnecessary overhead in the (common) case that a range value will never be strided.  Specifically, since arrays are built from domains which are built from ranges, array accesses can be much more efficiently expressed when it's known that their index ranges are dense.

What this means is that a line like:

  rangeToSplit.stridable = true;

doesn't work in Chapel because it'd be like trying to change the type (or a static property of the type) at execution time in the language.

Another piece of this is that in a declaration context, the undecorated type 'range' causes its type properties to be set to their defaults.  For example:

  var r: range = 1..10 by 2;

is illegal (will generate a runtime error) because ranges are unstridable by default and so this is trying to assign an strided range value to an unstridable range variable.  To fix this, one would use:

  var r: range(stridable=true) = 1..10 by 2;

Similarly, in your argument declaration, you're essentially asserting that this function should take an unstridable range as its argument for similar reasons.  If you wanted to make the function generic with respect to the stridability of the range, a quick shorthand for doing so would be:

  proc splitRange(rangeToSplit: range(?)) {
  }

which says "rangeToSplit is a range whose type arguments can be anything (any index type, any stridability, any boundedness, etc.).

So, I believe the quick fix to your program as it stands would be to declare 'rangeHalves' to be an array of range(stridable=true).

Since declaring the stridability of ranges is a bit verbose and annoying, this is also a great opportunity to lean on the type inference capabilities of the language.  For example, rather than declaring the array of ranges to return, you could just return an array literal of ranges:

  return [ rangeToSplit by newStride,
              rangeToSplit by ....  align .... ];

(the one thing I had to change in your code to make this work is to change the callsite to refer to these elements as '1' and '2' rather than '0' and '1' since anonymous arrays use 1-based indexing).

That said, for cases like this ("I want to return two things") I think tuples are a better choice in that they're lighter-weight, don't require the types to be identical, and support de-tupling syntax at the callsite.  For example, I would tend to write your program using idioms like:

  return (rangeToSplit by newStride,
             rangeToSplit by ... align ... );

and

  var (rangeB, rangeC) = splitRange(rangeA);

Hope this is a helpful start to getting you unstuck,
-Brad


________________________________
From: Kyle Burke [pai...@gm...]
Sent: Friday, December 20, 2013 6:31 AM
To: cha...@li...
Subject: [Chapel-education] cutting a range in half

Hello Chapel Educators,

I'm trying to come up with some good Chapel homework questions.  One of these could be:

Write a function, splitRange, that takes a stridable and finite range and returns an array containing 2 halves of the given range.  I'd like to use striding to try to do the splitting in constant time.  Unfortunately, it seems that stridable ranges become unstridable inside the function call.

Here's my attempt:

/**
 * Divides a range into two equal parts.  Precondition: rangeToSplit must be stridable and finite!
 */
proc splitRange(rangeToSplit : range) {
    var rangeHalves: [0..1] range;
    if (rangeToSplit.size <= 1) {
        rangeHalves[0] = rangeToSplit;
        rangeHalves[1] = 0..-1;
    } else {
        //rangeToSplit.stridable = true;
        var oldStride = rangeToSplit.stride;
        writeln("oldStride: ", oldStride);
        var newStride = oldStride * 2;
        writeln("newStride: ", newStride);
        rangeHalves[0] = rangeToSplit by newStride;
        rangeHalves[1] = (rangeToSplit by (rangeToSplit.stride * 2)) align (rangeToSplit.stride + rangeToSplit.alignedLow);
    }
    return rangeHalves;
}

Here's my test code:

/**
 * Prints out all elements in a range.
 */
proc printRange(rangeToPrint) {
    for element in rangeToPrint {
        write(element);
        if (element != rangeToPrint.last) {
            write(", ");
        }
    }
    writeln("");
}

//tests for splitRange

var rangeA = 0..14;
write("rangeA: ");
printRange(rangeA);
printRange(rangeA by 2);
var rangeAHalves = splitRange(rangeA);
var rangeB = rangeAHalves[0];
var rangeC = rangeAHalves[1];
write("rangeB: ");
printRange(rangeB);
write("rangeC: ");
printRange(rangeC);

It's able to stride rangeA by 2 outside the call to splitRange, but not inside.  Anyone have any experience with this issue?

-Kyle

--
Me: kg...@co...<mailto:kg...@co...>  (or pai...@gm...<mailto:pai...@gm...>)
http://www.cs.colby.edu/kgburke/

[Chapel-education] cutting a range in half

[Kyle B. <pai...@gm...>]

Hello Chapel Educators,

I'm trying to come up with some good Chapel homework questions.  One of
these could be:

Write a function, splitRange, that takes a stridable and finite range and
returns an array containing 2 halves of the given range.  I'd like to use
striding to try to do the splitting in constant time.  Unfortunately, it
seems that stridable ranges become unstridable inside the function call.

Here's my attempt:

/**
 * Divides a range into two equal parts.  Precondition: rangeToSplit must
be stridable and finite!
 */
proc splitRange(rangeToSplit : range) {
    var rangeHalves: [0..1] range;
    if (rangeToSplit.size <= 1) {
        rangeHalves[0] = rangeToSplit;
        rangeHalves[1] = 0..-1;
    } else {
        //rangeToSplit.stridable = true;
        var oldStride = rangeToSplit.stride;
        writeln("oldStride: ", oldStride);
        var newStride = oldStride * 2;
        writeln("newStride: ", newStride);
        rangeHalves[0] = rangeToSplit by newStride;
        rangeHalves[1] = (rangeToSplit by (rangeToSplit.stride * 2)) align
(rangeToSplit.stride + rangeToSplit.alignedLow);
    }
    return rangeHalves;
}

Here's my test code:

/**
 * Prints out all elements in a range.
 */
proc printRange(rangeToPrint) {
    for element in rangeToPrint {
        write(element);
        if (element != rangeToPrint.last) {
            write(", ");
        }
    }
    writeln("");
}

//tests for splitRange

var rangeA = 0..14;
write("rangeA: ");
printRange(rangeA);
printRange(rangeA by 2);
var rangeAHalves = splitRange(rangeA);
var rangeB = rangeAHalves[0];
var rangeC = rangeAHalves[1];
write("rangeB: ");
printRange(rangeB);
write("rangeC: ");
printRange(rangeC);

It's able to stride rangeA by 2 outside the call to splitRange, but not
inside.  Anyone have any experience with this issue?

-Kyle

-- 
Me: kg...@co...  (or pai...@gm...)
http://www.cs.colby.edu/kgburke/

[Chapel-education] [Chapel-announce] SC13 Wrap-up / CHIUW call for talks

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

Hi Chapel Community --

SC13
====

Thanks to everyone who came to one or more Chapel events at SC13!  It was 
a busy week, the major highlights being:

 	* our emerging technologies exhibit which gave Chapel a home base
 	  on the show floor where potential users/developers could find us
 	  throughout the week (and did they ever!);

 	* Ray Chen's research poster, which was named a semi-finalist
 	  in the ACM Research Competition;

 	* this year's crop of lightning talks speakers who covered topics
 	  as diverse as Chapel over MPI-3, HDFS computing in Chapel,
 	  Chapel in education, and Chapel support for futures, autotuning,
 	  and MiniMD;

 	* David Bunde and Kyle Burke's Chapel session in the HPC Educators
 	  program which, in addition to teaching educators about how to
 	  use Chapel in their classes, served as a place for people who
 	  heard about Chapel during the week to show up and learn more
 	  about it;

 	* and of course, the annual CHUG happy hour which gave us a chance
 	  to catch up with some of you in a more relaxed setting.


For those of you who weren't able to make it to SC13, we've managed to 
capture most of the materials involved on the website's presentations 
page:

 	http://chapel.cray.com/presentations.html


What's Next?  CHIUW!
====================

The next big Chapel community event that you should plan for is CHIUW: the 
Chapel Implementers and Users Workshop, to be held at IPDPS 2014 on 
Friday, May 23rd.  This will be the first official Chapel workshop we've 
held, and we hope that many of you will be able to join us there.

We encourage members of the broad Chapel community to propose short 
research talks for presentation at the workshop -- the deadline for 
extended abstracts being January 17th.

For more information on CHIUW (format, submissions, steering committee), 
please refer to the CHIUW and IPDPS websites, respectively:

 	http://chapel.cray.com/CHIUW.html
and:
 	http://www.ipdps.org/


Best wishes and we'll hope to see many of you in the new year,
-Brad


------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-announce mailing list
Cha...@li...
https://lists.sourceforge.net/lists/listinfo/chapel-announce

[Chapel-education] [Chapel-announce] Roll-up of Chapel events at SC13

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

Hi Chapel Community --

Highlights of this year's Chapel-related events at SC13 include:

* the annual Chapel Lightning Talks BoF, featuring five-minute talks by
   members of the broad Chapel community on Chapel's relationship to
   education, MPI-3, HDFS, autotuning, futures, and MiniMD (Wed 12:15-1:15)

* an ongoing presence in the Emerging Technologies booth on the show floor
   (all week, booth #3547)

* a Chapel session in the HPC Educators Program (Thus, 1:30-5pm),
   presented by David Bunde (Knox College) and Kyle Burke (Colby College)

* the 4th annual Chapel Users Group Happy Hour (CHUG) (Wed, 5pm til we drop)


In addition, there is a Chapel-related poster by Ray Chen (U MD) in the 
posters session and talks by members of the Cray Chapel team in various 
settings.

For further details and links, please refer to the "Upcoming Events" 
section of the Chapel website (and if we've missed anything, please let us 
know):

 	http://chapel.cray.com/events.html


Hope to see many of you next week at SC13!
-Brad
  (on behalf of the Chapel team)

------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-announce mailing list
Cha...@li...
https://lists.sourceforge.net/lists/listinfo/chapel-announce

[Chapel-education] [Chapel-announce] Announcing Chapel 1.8.0!

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

Chapel commmunity --

Cray Inc. and the Chapel developer community are pleased to announce
the release of version 1.8.0 of Chapel.  This release's highlights
include:

* Initial support for user-defined locale models, permitting a compute
   node's architecture to be modeled abstractly within Chapel; and a
   NUMA locale model built in terms of it.

* Support for accessing HDFS file systems via Chapel's files and
   channels, providing a foundation for expressing "big data"
   computations in Chapel.

* Improved tasking semantics with respect to references to variables
   from scopes outside of the tasks; in particular, scalar variables
   are now copied into tasks via a const copy, reducing the chances of
   race conditions and improving performance in common cases.

* New example codes demonstrating the Mantevo MiniMD proxy application
   in Chapel, as well as four benchmarks from the Computer Lanugage
   Benchmark Game.

* Performance optimizations benefitting array accesses and loop
   idioms, based on shifted array base pointers and loop invariant code
   motion.

* Improved memory utilization by closing a number of
   compiler-generated memory leaks (though others remain).

* Improved interoperability with C via new helper types: c_string,
   c_ptr(type), and c_void_ptr.

* Improved support for computations on small integers, including the
   ability to create ranges, domains, and arrays with small-int
   indices.

* Support for dygraph-based performance monitoring within the Chapel
   performance regression testing framework.

* Updates to the GASNet, Qthreads, MassiveThreads, LLVM, and CLANG
   packages.

* The addition of a new 'cray-cs' platform to represent Cray Cluster
   Supercomputers like the Cray CS30 (TM).

* Making 'gemini' the default GASNet conduit for the 'cray-xe' and
   'cray-xk' target platforms.

* The inclusion of a new SLURM + GASNet-over-Infiniband launcher.

* Numerous bug fixes, including improvements to semantic checks and
   error messages.

...and much more!  See below for a more complete list of changes in
version 1.8.0, or refer to $CHPL_HOME/CHANGES within the release
itself.

Contributors to this release include:

   Rafael Asenjo, University of Malaga
   Brad Chamberlain, Cray Inc.
   Sung-Eun Choi, Cray Inc.
   Saliya Ekanayake, Indiana University
   Michael Ferguson, LTS
   Alexey Gokhberg, Unicorn Enterprises SA
   Ben Harshbarger, Cray Inc./University of Washington
   Tom Hildebrandt, Cray Inc.
   David Iten, Cray Inc.
   Rafael Larrosa Jiminez, University of Malaga
   Jun Nakashima, University of Tokyo
   Vassily Litvinov, Cray Inc.
   Elliot Ronaghan, Cray Inc./Moravian College
   Sara Salem, Cairo University
   Alberto Sanz, University of Malaga
   Darren Smith, University of Maryland
   Greg Titus, Cray Inc.
   Joe Yan, University of Maryland
   Tim Zakian, Cray Inc./Indiana University

To download the release, visit our SourceForge page at:

          http://sourceforge.net/projects/chapel

At this site, you can also browse the mailing list archives and track
our progress day-by-day.  Our main project page continues to be hosted
at:

          http://chapel.cray.com

and it remains the best place to browse papers, presentations,
documents, tutorials, and news items; or to read about collaborations
with researchers and educators.

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

On behalf of the Chapel Team,
-Brad Chamberlain


=============
version 1.8.0
=============

Eleventh public release of Chapel, October 17, 2013

Highlights (see entries in subsequent categories for details)
-------------------------------------------------------------
- added initial support for user-defined locale models and a NUMA locale model
- added initial support for accessing HDFS file systems via files/channels
- improved tasking semantics w.r.t. references to variables from outer scopes
- added new example codes for MiniMD and the Computer Language Benchmark Game
- performance optimizations related to array base pointers, loop-invariant code
- removed a number of compiler-generated memory leaks
- added new types for interoperating with C: c_string, c_ptr(type), c_void_ptr
- improved support for small-int computations, ranges, domains, and arrays
- support for dygraph-based performance monitoring in the testing system
- updates to the GASNet, Qthreads, MassiveThreads, LLVM, and CLANG packages
- added a new 'cray-cs' platform to represent Cray Cluster Supercomputers
- made 'gemini' the default GASNet conduit for 'cray-xe' and 'cray-xk'
- added support for a SLURM + GASNet-over-Infiniband launcher

New Features
------------
- added initial support for specifying locale models ('hierarchical locales')
   (see doc/technotes/README.localeModels)
- added support for a prototype NUMA locale model
   (see doc/technotes/README.localeModels)
- added initial support for accessing HDFS file systems via files/channels
   (see doc/technotes/README.hdfs)
- added new 'const in' and 'const ref' argument intents
   (see the 'Argument Intents' section in the language specification)
- added built-in config params for all CHPL_* environment settings

Semantic Changes / Changes to Chapel Language
---------------------------------------------
- improved tasking semantics w.r.t. references to variables from outer scopes
   (e.g., in 'var x=0; begin { ...x... }', 'x' is a const copy within the task)
   (see 'Task Intents' section in the language specification)
- added 'ref' clauses to obtain the previous reference tasking semantics
   (e.g., 'var x: int; begin ref(x) { ...x... }' causes '...x...' to refer to x)
   (see 'Task Intents' section in the language specification)
- made blank intents for atomic variables get interpreted as 'ref'
   (see the 'Argument Intents' section in the language specification)
- added support for ranges, domains/arrays with small-int index types
   (e.g., 'range(int(8))' is now a supported type)
- added operator support for pairs of small int/uint types
   (e.g., 'int(8) + int(8)' now generates an int(8) rather than int(32))
- added operator support for homogenous tuple/scalar pairs
   (e.g., (1,2,3) + 1 => (2,3,4))
- extended the member() method on domains to support varargs as well as tuples
   (e.g., 'var D = {1..n, 1..n};' supports 'D.member(i,j)' and 'D.member((i,j))')
- the compiler now only creates '==' operators for matching record types
- made 'bool' types prefer dispatching to 'int' args over smaller-int options
   (e.g., foo(true) will prefer to dispatch to foo(x:int) over foo(x:int(8)))

New Interoperability Features
-----------------------------
- added support for 'c_ptr(type)' and 'c_void_ptr' to refer to local C pointers
   (see doc/technotes/README.extern)
- added support for a 'c_string' type to refer to local C char* pointers
   (see doc/technotes/README.extern)

Deprecated Features
-------------------
- removed experimental GPU work to prepare for a revised approach to GPU support
- removed the callStackSize() query from the locale type
- removed certain config consts to control runtime arguments
   (see "Flags on Generated Executables" section below)

Standard Modules
----------------
- added a new 'UtilReplicatedVar.chpl' standard module for replicated variables
- new 'HDFSiterator' and 'RecordParser' modules to help with parsing HDFS files

Documentation
-------------
- added a new README to describe the new locale model concept and NUMA model
   (see doc/technotes/README.localeModels)
- added a new README.hdfs file to describe HDFS file system access in Chapel
   (see doc/technotes/README.hdfs)
- made significant improvements to the README.cray file
   (see doc/platforms/README.cray)
- refreshed the 'chpl' man page, particularly the SYNOPSIS/ENVIRONMENT sections
- refreshed the Chapel Quick Reference document
- major updates to the 'Task Parallelism' section of the spec for task intents
- made minor updates to several chapters in the language specification
- updated README.chplenv to reflect new CHPL_* environment variables
- minor updates to various README files

Example Codes
-------------
- added an initial port of the Mantevo MiniMD miniapp to Chapel
   (see examples/benchmarks/miniMD)
- added Chapel ports of four codes from the Computer Language Benchmark Game
   (see examples/benchmarks/shootout)
- fixed a bug in the atomics.chpl primer example
- cleaned up the beer.chpl example

Cray-specific Notes
-------------------
- added a new 'cray-cs' platform to represent Cray Cluster Supercomputers (CS)
   (see doc/platforms/README.cray for more information)
- made 'gasnet' the default CHPL_COMM setting for all Cray platforms
- made 'gemini' the default GASNet conduit for 'cray-xe' and 'cray-xk' platforms
   (see doc/platforms/README.cray)
- added support for the GASNet 'aries' conduit for the 'cray-xc' platform
   (see doc/platforms/README.cray)
- made 'aprun' the default launcher for 'cray-x*' systems when available
- removed support for the 'xmt', 'x1', and 'x2' platforms and related features
- generated warning messages on cray-x* systems when no PrgEnv is loaded
- removed -target=linux flag from cray-prgenv-* compiler options

Launcher-specific Notes
-----------------------
- added support for a SLURM + GASNet-over-Infiniband launcher
   (see 'slurm-gasnetrun_ibv' in doc/README.launcher)
- made the aprun-based launchers use the system's default number of CPUs
- brought the pbs launchers up-to-date with the current NCCS wrapper of qsub

Portability of code base
------------------------
- worked around a PGI portability issue with C structs in the generated code

Compiler Flags (see 'man chpl' for details)
-------------------------------------------
- added --[no-]warn-const-loops to control warnings about loops over constants
- added --[no-]loop-invariant-code-motion to enable/disable that optimization
- added --[no-]llvm-wide-opt to enable/disable LLVM wide pointer optimizations
- added warnings to '--[no-]serial' indicating its likely deprecation

Flags on Generated Executables
------------------------------
- replaced flags that govern runtime behavior with environment variables:
     callStackSize       -> CHPL_RT_CALL_STACK_SIZE
     commConcurrency     -> CHPL_RT_COMM_CONCURRENCY
     numHardwareThreads  -> CHPL_RT_NUM_HARDWARE_THREADS
     numThreadsPerLocale -> CHPL_RT_NUM_THREADS_PER_LOCALE

Error Message Improvements
--------------------------
- improved const checking for actuals passed to out/inout/const ref/ref intents
- improved error messages for programs with bad type resolution cycles
- added a warning for while loops over constants
- errors for assignments to non-lvalues no longer halt compilation immediately

Performance Improvements
------------------------
- improved performance of local arrays by storing a shifted base pointer
- added a loop-invariant code motion optimization
- passed more things by value ('this', array/domain/domain map wrappers)
- made some improvements to the bulk copy optimization

Memory Leak Improvements
------------------------
- reduced memory leaked by strings by sharing them more aggressively
- improved support for destroying more automatic variables as they leave scope
- fixed a memory leak relating to inlining of iterators
- plugged memory leaks related to file types
- freed temporary buffers used for formatted I/O on complex values

Bug Fixes / New Semantic Checks (for old semantics)
---------------------------------------------------
- fixed bugs in extern blocks containing #define's
- fixed a bug when reading string literals that began with whitespace
- fixed a bug in which whitespace was written to binary files for array output
- fixed bugs related to writef() for complex values
- fixed size mismatches in IO code for 32-bit linux systems
- fixed a bug in the compareExchange implementation for atomic reals
- fixed bugs in Regexp convenience functions and the naming of string.split()
- fixed some bugs in BigInt functions in the GMP module
- fixed a bug in which AdvancedIterators would serialize if #chunks < #tasks
- fixed a bug related to 'ref' intents and the fast segment for GASNet
- fixed a bug related to using --make on the chpl command line
- bug fix for lost updates to fields of 'this' in certain scenarios
- fixed dead code elimination for blocks that are their own sole in-arc

Third-Party Software Changes
----------------------------
- updated to GASNet version 1.20.2 which improves the Cray native conduits
- updated to Qthreads version 1.10 and turned on support for stack overflow
   (see reference to QT_GUARD_PAGES in doc/README.tasks for more information)
- updated to MassiveThreads version 0.95 with support for task-private data
- updated the LLVM back-end to use version 3.3 and packaged it with the release
- packaged CLANG 3.3 with the release rather than requiring a separate download

Runtime Library Changes
-----------------------
- made several interface changes to support locale models/hierarchical locales

Generated Code Cleanups
-----------------------
- declared non-exported symbols 'static' in generated code
- added support for targeting 'op=' operators in the back-end
- removed chains of unnecessary autocopy/autodestroy calls

Compiler Performance
--------------------
- disabled compiler internal verification by default to improve compile time

LLVM Back-end Changes
---------------------
- added wide pointer support for the LLVM back-end via CHPL_WIDE_POINTERS
   (see doc/technotes/README.llvm and doc/README.chplenv)
- added support for LLVM-based communication optimizations via --llvm-wide-opt
   (see doc/technotes/README.llvm)

Testing System
--------------
- changed performance graphing to use dygraphs
- added support for filing .bad files against futures to track behavior changes
- added support for setting environment variables on a per-test/-directory basis
- added the ability to use an external 'time -p' command for performance tests
- added directory-level PERFCOMPOPTS/PERFEXECOPTS files
- added a timeout feature for performance testing (separate from correctness)
- fixed a bug in which spec tests weren't being generated correctly
- added the capability for the test directory to clean itself up more thoroughly

Makefile Changes
----------------
- changed the naming scheme for intermediate object file directories
- added a 'cleanall' target between 'clean' and 'clobber'
   (see README.building)
- made the 'clean' and 'cleanall' targets preserve a working installation
- accelerated the Makefile framework, particularly for no-op re-builds
- made the Makefiles smarter about rebuilding the compiler when necessary

Internal/Developer-oriented
---------------------------
- added a new 'createTaskFunctions' pass that creates functions defining tasks
- added a new 'resolveIntents' pass which resolves 'blank' and 'const' intents
- added a per-pass consistency/verification framework
- added a --verify compiler flag for running optional verification steps
- added an --ignore-errors-for-pass compiler flag for developers
- added a compiler analysis to compute dominators
- fixed a bug in isDefAndOrUse() for op= primitives
- rearchitected the QIO framework to support multiple file systems
- refactored the memory interface to better separate checking/tracking concerns
- switched to using 'ref' intents rather than 'inout' for I/O routines
- added "atomic type" flag for identifying atomic types to the compiler
- added "donor" function concept, making the callee responsible for deletion
- added "runtime type init fn" pragma to clarify overloaded "has runtime type"
- fixed a bug in which 'begin's in internal modules broke compilation
- restructured iterators so that not all yields would share the same variable
- improved cases where filename/line numbers aren't set correctly
- continued transition toward STL collections within the compiler
- added new capabilities to the bit vector class
- removed several instances of strcpy()s in the compiler
- added a functional interface for invoking remote functions by ID
- restructured #includes to avoid reliance on compiler-specific search policies
- added new features for debugging the compiler

Changes In Support of Hierarchical Locales
------------------------------------------
- made ranges and default rectangular domains/arrays use sublocales, if present
- made on-clauses get invoked through locale model module code in Chapel
- moved optimization of local on-clauses from the compiler to locale model code
- made task invocation flow through locale model module code written in Chapel
- mapped the tasking interface's support for hierarchical locales to Qthreads
- made hierarchical locale model compilations use wide pointers and on-clauses


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-announce mailing list
Cha...@li...
https://lists.sourceforge.net/lists/listinfo/chapel-announce

[Chapel-education] [Chapel-announce] Call for Participation: SC13 Chapel Lightning Talks BoF (fwd)

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

Hi Chapel Community --

This is just a quick reminder that we're a few days from the proposal 
deadline for participating in the SC13 Chapel Lightning Talks BoF. See the 
original announcement below for more information.

-Brad


---------- Forwarded message ----------
Date: Mon, 16 Sep 2013 16:42:27 -0700 (PDT)
From: Brad Chamberlain <br...@cr...>
To: Chapel Announcements <cha...@li...>
Subject: Call for Participation: SC13 Chapel Lightning Talks BoF


Hi Chapel community --

We're pleased to announce the third annual Chapel Lightning Talks BoF at SC13 
this November.  As in previous years, this BoF is designed to highlight 
interesting work being done in or around Chapel across the broad community.

If you will be attending SC13 and have Chapel-related work that you would like 
to highlight there, please consider proposing a talk for this session 
(scheduled for Wednesday, November 20th, from 12:15-1:15).

Our goal for the session is to generate increased interest in the Chapel 
language within the HPC community by covering a diverse set of topics from 
within the broader Chapel community outside of Cray: research collaborations, 
use of Chapel in education, application studies, supporting technologies, etc.

We've been using the lightning talk format for this BoF in order to cover a 
broad spectrum of activities and keep the session quick and lively.  To that 
end, we anticipate having ~6 talks @ 5 minutes each as the core of the session. 
We'll start with a brief overview of the Chapel project to provide context for 
the talks and will wrap up with a Q&A session involving all the speakers.

To propose a talk, please send the following information to 
cha...@cr... by October 5th:

* a proposed title

* a paragraph summarizing what you'd cover in your 5 minutes

* a short speaker bio (1 short paragraph)

* (optional, but recommended) sample slides from previous talks
    demonstrating that you can create engaging slides; or that you've
    presented a short, lightning-style talk before.  (Note that these
    can be from any technical talk or lecture; they don't need to be
    related to your proposed topic in any way).

>From the submissions, we will curate a program for the BoF, attempting to 
emphasize diverse and novel work.  We will strive to prioritize new work 
relative to the previous lightning talks BoFs, though speakers from previous 
years are definitely encouraged to submit a talk that highlights new work or 
progress.

Key Dates:

* Oct  9th: Proposals due

* Oct 18th: Notification of decisions

* Nov  1st: Speakers submit draft slides for feedback

* Nov 20th: the BoF at SC13 (12:15-1:15)

Please note that in order to participate in the BoF, you'll need to be
registered for SC13.


We're looking forward to this BOF and hope you'll submit something and/or join 
us to hear the talks!

-Brad
   (on behalf of the Chapel team)

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-announce mailing list
Cha...@li...
https://lists.sourceforge.net/lists/listinfo/chapel-announce

[Chapel-education] [Chapel-announce] Call for Participation: SC13 Chapel Lightning Talks BoF

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

Hi Chapel community --

We're pleased to announce the third annual Chapel Lightning Talks BoF at 
SC13 this November.  As in previous years, this BoF is designed to 
highlight interesting work being done in or around Chapel across the broad 
community.

If you will be attending SC13 and have Chapel-related work that you would 
like to highlight there, please consider proposing a talk for this session 
(scheduled for Wednesday, November 20th, from 12:15-1:15).

Our goal for the session is to generate increased interest in the Chapel 
language within the HPC community by covering a diverse set of topics from 
within the broader Chapel community outside of Cray: research 
collaborations, use of Chapel in education, application studies, 
supporting technologies, etc.

We've been using the lightning talk format for this BoF in order to cover 
a broad spectrum of activities and keep the session quick and lively.  To 
that end, we anticipate having ~6 talks @ 5 minutes each as the core of 
the session.  We'll start with a brief overview of the Chapel project to 
provide context for the talks and will wrap up with a Q&A session 
involving all the speakers.

To propose a talk, please send the following information to 
cha...@cr... by October 5th:

* a proposed title

* a paragraph summarizing what you'd cover in your 5 minutes

* a short speaker bio (1 short paragraph)

* (optional, but recommended) sample slides from previous talks
    demonstrating that you can create engaging slides; or that you've
    presented a short, lightning-style talk before.  (Note that these
    can be from any technical talk or lecture; they don't need to be
    related to your proposed topic in any way).

>From the submissions, we will curate a program for the BoF, attempting to 
emphasize diverse and novel work.  We will strive to prioritize new work 
relative to the previous lightning talks BoFs, though speakers from 
previous years are definitely encouraged to submit a talk that highlights 
new work or progress.

Key Dates:

* Oct  9th: Proposals due

* Oct 18th: Notification of decisions

* Nov  1st: Speakers submit draft slides for feedback

* Nov 20th: the BoF at SC13 (12:15-1:15)

Please note that in order to participate in the BoF, you'll need to be
registered for SC13.


We're looking forward to this BOF and hope you'll submit something and/or 
join us to hear the talks!

-Brad
   (on behalf of the Chapel team)

------------------------------------------------------------------------------
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-announce mailing list
Cha...@li...
https://lists.sourceforge.net/lists/listinfo/chapel-announce