From 9e6f1b2ff7974c2ef813e660836bc8fc7cf366fe Mon Sep 17 00:00:00 2001 From: Brad Chamberlain Date: Tue, 8 Sep 2020 16:57:00 -0700 Subject: [PATCH] Move away from @cray.com email addresses This PR removes @cray.com email addresses, using the following strategy: * removes GOALS.md and STATUS.devel which seem like files that aren't of much importance anymore now that more of our documentation is online and at GitHub. Updated README.devel and README.files to reflect this, as well as a few rules in Makefile.devel that haven't been used since the SVN days. * removed references to chapel_info@cray.com which is going away. Though we're replacing it with an equivalent, it seems poor form to mention it as plaintext in all these files (many of which used disguiseme in the .rst cases, but it seems unlikely to help when the sources themselves are public). In most cases, referred people to the GitHub issues page instead, or figured they could figure out how to contact us. * updated scripts that mailed to $user@cray.com to refer to $user@hpe.com, though more effort could/should eventually be put here to make these more organization-agnostic. * removed some text files containing my email address which I can't recall why I would've intentionally put into the repository. * some other stuff as well? --- GOALS.md | 28 - Makefile.devel | 7 - README.devel | 1 - README.files | 1 - STATUS.devel | 899 ------------------ doc/rst/platforms/cygwin.rst | 2 +- doc/rst/technotes/extern.rst | 6 +- doc/rst/technotes/firstClassFns.rst | 3 +- doc/rst/usingchapel/bugs.rst | 22 - doc/rst/usingchapel/building.rst | 2 +- doc/rst/usingchapel/chplenv.rst | 3 +- doc/rst/usingchapel/privatebugs.rst | 38 - doc/rst/usingchapel/tasks.rst | 10 +- highlight/emacs/chpl-mode.el | 2 +- test/release/examples/primers/sparse.chpl | 11 +- test/sparse/bradc/CSR/sparse.chpl | 11 +- test/studies/590o/blerner/FEEDBACK | 80 -- test/studies/590o/blerner/FEEDBACK-blc | 257 ----- test/studies/590o/blerner/FEEDBACK2 | 332 ------- test/studies/590o/blerner/FEEDBACK2-blc | 156 --- test/studies/590o/blerner/FEEDBACK3 | 110 --- test/studies/590o/blerner/FEEDBACK3-blc | 69 -- util/buildRelease/testRelease | 2 +- .../generate-dev-releaseinfo.bash | 6 +- util/cron/README | 2 +- util/cron/lookForTabs.cron | 2 +- util/cron/nightly | 2 +- util/cron/start_opt_test | 2 +- util/tokencount/tokctnightly | 2 +- 29 files changed, 31 insertions(+), 2037 deletions(-) delete mode 100644 GOALS.md delete mode 100644 STATUS.devel delete mode 100644 doc/rst/usingchapel/privatebugs.rst delete mode 100644 test/studies/590o/blerner/FEEDBACK delete mode 100644 test/studies/590o/blerner/FEEDBACK-blc delete mode 100644 test/studies/590o/blerner/FEEDBACK2 delete mode 100644 test/studies/590o/blerner/FEEDBACK2-blc delete mode 100644 test/studies/590o/blerner/FEEDBACK3 delete mode 100644 test/studies/590o/blerner/FEEDBACK3-blc diff --git a/GOALS.md b/GOALS.md deleted file mode 100644 index f70a0db77eda..000000000000 --- a/GOALS.md +++ /dev/null @@ -1,28 +0,0 @@ -Chapel Public Release Goals -=========================== - -The goals of this release are as follows: - -* to give the general public an opportunity to see the state and - evolution of the Chapel implementation first-hand - -* to get feedback on the Chapel language and its ongoing - implementation (please direct to chapel_info@cray.com or the - community mailing lists hosted at SourceForge) - -* to demonstrate Chapel's base language features - -* to demonstrate Chapel's task parallel features in a multi-threaded, - multi-locale setting. - -* to demonstrate Chapel's data parallel features via a combination of - - (i) a multi-threaded, single-locale implementation of ranges and - irregular domains and arrays; - - (ii) a multi-threaded, multi-locale implementation of regular - domains and arrays using some standard distributions. - -For more detailed notes on what is or is not supported -in this release, refer to the Issues list on GitHub -(https://github.com/chapel-lang/chapel/issues). diff --git a/Makefile.devel b/Makefile.devel index 3a5eba4ebfe9..5718d6ab5cbd 100644 --- a/Makefile.devel +++ b/Makefile.devel @@ -64,10 +64,3 @@ SPECTEST_DIR = ./test/release/examples/spec spectests: FORCE rm -rf $(SPECTEST_DIR) doc/util/extract-rst-tests.py doc/rst/language/spec/ --output $(SPECTEST_DIR) - -FUTURES: - cd test && find . -wholename ".svn" -prune -o \( -name \*.future \) -exec head -n 1 {} + > FUTURES - - -future_stats: FUTURES - ./util/devel/test/future_stats STATUS.devel test/FUTURES diff --git a/README.devel b/README.devel index be50d413b18f..18f1b52c71f2 100644 --- a/README.devel +++ b/README.devel @@ -18,7 +18,6 @@ description: CHANGES.md CONTRIBUTORS.md COPYRIGHT - GOALS.md LICENSE LICENSE.chapel QUICKSTART.rst diff --git a/README.files b/README.files index 60aca59ad08d..a92dcb8bc570 100644 --- a/README.files +++ b/README.files @@ -12,7 +12,6 @@ further information about the files and directories that they contain. CHANGES.md : a list of changes in each release CONTRIBUTORS.md : a list of contributors to the Chapel project COPYRIGHT : copyright information - GOALS.md : the goals of this release LICENSE : license information for the Chapel release as a whole LICENSE.chapel : license statement for the Chapel implementation itself README.files : this file diff --git a/STATUS.devel b/STATUS.devel deleted file mode 100644 index 273c7e5d6106..000000000000 --- a/STATUS.devel +++ /dev/null @@ -1,899 +0,0 @@ -# -# This file lists all the existing futures that are categorizes as "bug" or -# "unimplemented feature." -# -# All comments will be stripped out before releasing the final STATUS -# -# To remove comments use: grep -v "^\ *#" STATUS.devel (or 'make STATUS') -# -# To further facilitate generating the final STATUS file, please put the -# names of the future files on a separate line from comments (one future -# per line). For example: -# -# # path/to/future/blah.future -# -# If for some reason a .future is omitted prepend the name of the future -# with the 'OMITTED:' and use comments to explain. For example: -# -# # OMITTED: path/to/future/blah.future -# # b/c it's too difficult to explain -# -# -============================ -Chapel Implementation Status -============================ - -This file contains a list of unimplemented features and known bugs in -the Chapel implementation. If you find additional bugs and -unimplemented features, or if you would like to request prioritization -of items in this file, please let us know at -https://chapel-lang.org/bugs.html or chapel_info@cray.com. Please -feel encouraged to err on the side of mailing us with any issues you -run into. - -# OMITTED: functions/vass/resolution/need-ambiguous-error-1.future -# b/c it seems a little obscure (it'd be nice to see an example with a non-standard module function) -# -# OMITTED: users/vass/crash1callDestructorsMain.future -# b/c not investigated -# -# OMITTED: users/csep524/userDefReduceSlim.future -# b/c multiple errors in the user code and hard to quantify what is wrong -# -# OMITTED: users/npadmana/fftw/testFFTWsegfault.future -# b/c not investigated or diagnosed -# -# OMITTED: functions/deitz/iterators/iterator_uses_setter.future -# b/c 'setter' has been removed from the language and it's unclear if this test -# can be updated -# - -General (see also portability section at the bottom of this file) ------------------------------------------------------------------ - -- Some error messages are confusing or unhelpful. If needed, please - ask us for help with interpreting the message. - # compflags/bradc/badConfigParamOverride.future - # sparse/bradc/accumInds-forexpr.future - # functions/vass/resolution/need-missing-return-error-2.future - # types/scalar/bradc/index-int.future - # users/rohanbadlani/bugs/bug1.future -- Compiler and runtime and errors may report incorrect line numbers, - may not be formatted correctly, or may be garbled. If needed, - please ask us for help finding the line in question. - # parsing/vass/newline-in-string-compiletime-1.future -- Errors in unused code may not be reported by the compiler - # users/kreider/feature_unusedcode.future -- Names in a Chapel program can collide with names used internally. - # modules/hilde/Writer.future - # types/records/sungeun/chapelTypes/record_array.future - # extern/vass/c_sublocid_any.inner-extern.future -- There are several internal memory leaks - - Privatized domains and arrays (i.e., those that use the standard - distributions) are leaked - - Non-default domain maps may be leaked - - Data associated with iterators may be leaked - - Records with generic fields may be leaked - # types/records/ferguson/leak-futures/iterate-loop-break.future - # types/records/ferguson/leak-futures/iterate-loop-break2.future - # types/records/ferguson/leak-futures/iterate-twice-break.future - # types/records/ferguson/leak-futures/record-in-record-generic.future - # arrays/ferguson/semantic-examples/4-init-class-field.future - # arrays/ferguson/semantic-examples/4-init-record-field.future -- Separate compilation of Chapel files is not supported. - # separate_compilation/jturner/array.future - # separate_compilation/jturner/use_array.future - # separate_compilation/jturner/use_classextern.future - # separate_compilation/jturner/use_classextern2.future - # separate_compilation/jturner/use_fcfunc.future - # separate_compilation/jturner/use_methodextern.future - # separate_compilation/jturner/use_methodextern2.future - # separate_compilation/jturner/use_overload.future - # separate_compilation/jturner/use_record.future - # separate_compilation/jturner/use_simplefloat.future - # separate_compilation/jturner/use_subclass.future -- Back-end compilers may emit warning messages. -- The --gdb flag is only supported for single-locale platforms that - support gdb. Please ask us for help if you want to debug a - multilocale program. - - -Types, Params, Variables, and Consts ------------------------------------- -- The default value for the locale type is incorrect. - # types/locale/bradc/defaultLocaleVal.future - # multilocale/sungeun/locale_default.future -- Type inferred for a variable initialized to 'nil' is not 'object' - # classes/deitz/class/infer_nil.future -- Multiple configuration parameters with different types declared in a - single statement result in an internal compiler error. - # functions/bradc/paramFnNonParamArgs/multConfigTypes.future -- When setting a config variable that shares an initializer on the - command line, the new value is incorrectly propagated to the other - variables. - # execflags/bradc/configShareInit.future -- When setting a boolean config variable on the command line, using a - space as the delimiter results in an "Unexpected flag" error. - # execflags/thomasvandoren/configVarBooleanSpaceAfter.future -- When setting an integral config variable on the command line, only - base 10 values are supported. - # execflags/tmacd/config_num.future -- Some assignments to ref variables can cause an internal compiler error. - # variables/sungeun/refvar-assign-with-cast.future - # variables/vass/ref-to-const-domain.future -- Using an if-expression as the left-hand side of an assignment may not work. - # expressions/ferguson/if-expr/ifi.future -- Taking a reference of an array formal argument causes a const checking error. - # arrays/bradc/refArray2.future -- Variables that rely on each other for initialization - and/or type inference may result in an internal compiler error. - # functions/deitz/test_outoforder.future -- Constant checking is incomplete. - # domains/bradc/assignConstDom2.future - # domains/bradc/assignConstDom.future - # types/records/const-checking/todo-multiple-asgn-errors.future -- Attempting to instantiate a generic class in a type alias context results - in an unresolved call error. - # functions/vass/param-formal-in-ctor.future -- Type aliases and enum declarations cannot be declared private/public. - # visibility/private/typeAlias.future - # visibility/private/privateEnum.future -- Defining a method on a type alias is not supported. - # users/ferguson/type-alias-method.future -- Implicit `this` not working for method on specific instantiation; - explicitly writing e.g. `this.field` may be required. - # functions/ferguson/spec-insn-method-no-this.future - -Conversions ------------ -- Casts to non-type variables do not result in an error at compile time. - # expressions/vass/cast-to-non-type-1.future - # expressions/vass/cast-to-non-type-2.future -- Integer to c_string cast promotes from int to real before cast is performed - # types/string/thomasvandoren/int-to-c_string.future -- Casting from string to uint(32) clips result to 31 bits on 32 bit platforms - # types/string/cassella/cast-biggish-uint32-through-string.future - -Statements and Expressions --------------------------- -- Continue statements in forall and coforall statements not implemented. - # statements/diten/continueInForall.future - # statements/sungeun/continue_coforall_label.future - # statements/sungeun/continue_forall_label.future -- On statement variable declarations are not yet supported. - E.g., on Locales(1) var x: real; - # multilocale/sungeun/on_statement_var_decl.future -- The local statement is not well supported. For example, declaring - domains (whether explicitly via a declaration or implicitly via - slicing) results in a runtime seg fault or non-local access error. - Also, on statements in local blocks should be illegal, but result in - local execution. - # multilocale/local/sungeun/local_privatization.future - # users/jglewis/locClassSegFault.future -- Nested for expressions can cause runtime failure - # expressions/diten/forExprs.future -- Using domain extraction syntax inside a variable declaration causes - compiler failure instead of a clean error - # users/bguarraci/domain_extraction.future - -Modules -------- - # OMITTED: modules/sungeun/resolution/module-resolution-issue.future - # b/c I'm not able to describe it concisely -- Modules that rely on each other for initialization and/or type - inference may result in an internal compiler error. - # functions/bradc/resolveConfig.future - # modules/deitz/test_module_mutual_use.future - # modules/diten/mutualuse.future - # modules/diten/mutualuse2.future - # modules/diten/mutualuse3.future -- User modules named the same as types defined internal/standard modules - can cause multiple definition errors. - # modules/lydia/object.future - # modules/lydia/object2.future -- Modules that use another module that uses a begin statement in its - initialization result in an internal compiler error. - # parallel/begin/vass/begin-in-module-init.future -- Constructor calls with the same name in different modules are not - properly resolved. - # trivial/jturner/module_class_name_clash.future -- Cannot call new for or declare a variable for a type defined in another - module without explicitly using the module. - # users/ferguson/module_new.future - # modules/sungeun/no-use-record.future -- If multiple modules with the same name define 'main' and the '--main-module' - flag is used, there is an internal error. - # modules/cassella/ambigmodmain.future - # modules/cassella/ambigmodmain.unnested.future - # modules/cassella/ambigmodmain.unnested2.future -- Secondary methods are not handled properly within 'only' lists in 'use' - statements. - # visibility/only/canSeeSecondaryMethod.future - -Functions and Iterators ------------------------ -- Invalid where clauses may result in an internal compiler error. - # functions/bradc/resolution/uintParamInWhere.future -- Querying the type of a function is not supported and currently - returns an internal type. - # functions/sungeun/type_illegal.future -- Default values for formal arguments do not accept conditional - expressions. - # functions/deitz/default/test_default_conditional_expr.future -- Specified argument types that are not types should return a Chapel - compile time error, but instead they may result in an internal - compiler error or compile and run. - # functions/deitz/test_arg_type_is_value_error.future - # functions/vass/return-type-function-failure.future -- Formal arguments that depend on preceeding vararg arguments fail to compile - # functions/nspark/generic-varargs2.future -- Array-of-array formal argument declarations do not work. - # arrays/bradc/arrayOfArrayArg.future -- Returning arrays from getter/setter functions always uses the setter version - # functions/bharshbarg/arr-ref-return.future -- Function argument with type tuple of generic class results in a - compiler assertion. - # functions/diten/fnGenericTupleArg.future - # functions/vass/arg-is-tuple-with-generic-class.future -- Actual arguments for formals with out intent do not follow implicit - conversion rules and must match exactly in type. - # functions/vass/out-intent-desired.future -- Sync and single vars incorrectly passed to generic ref or const intent - arguments. - # types/sync/vass/ref-sync-2.future -- Sync and single variables in records are not properly copied out - when the record is passed as an out or inout argument. - # types/single/sungeun/writeRecordInOutProc.future -- Parentheses-less function without curly braces enclosing the body - fail to parse correctly. - # parsing/vass/parenthesis-less-function-string.future -- Recursive functions that return arrays are not yet supported - # functions/dinan/array_return_from_recursive.future -- Type and parameter functions are not checked for side effects. -- Ref functions returning multiple class types should be illegal, but - instead they are compiled and result in runtime error. - # functions/diten/varFnRetClasses.future - # functions/diten/varFnRetClasses2.future -- Ref functions that return local data may not result in an error. - # functions/deitz/test_var_function_returns_local_via_var_function.future -- Ref functions that return fields from a record argument passed by - blank intent may produce incorrect results. - # optimizations/copyPropagation/cp-problem1.future -- Type functions with unambiguous return paths may result in "illegal - cast" errors. - # users/weili/typefnbug.future - # This should be updated when someone knows a little more - # about what exactly is going on -- Support for closures and first-class functions is not complete. - # functions/jturner/first-class-generic-function.future - # functions/vass/closure-outlives-captured-vars.future -- Recursive iterators may not work correctly. - # functions/iterators/vass/recursive-iterator-in-expr-context.future - # studies/madness/aniruddha/madchap/recordBug/test_likepy.future -- Parallel recursive iterators are not supported. - # functions/iterators/tzakian/par_iter_recursive.future -- Iterators in records cannot change fields in that record. - # functions/deitz/iterators/test_record_iterator.future -- Iterators with reference variables cause program to crash at runtime - when compiled with the --baseline flag. - # studies/shootout/nbody/sidelnik/nbody_iterator_7-refInIterator.future -- Const checking is incorrect for standalone iterator index variables - # performance/vectorization/vectorizeOnly/constChecking/standaloneConstChecking.future - # statements/elliot/loops/modifyIndicesStandalone.future -- Ref iterators yielding records may introduce uninitialized values - # types/records/ferguson/parallel/coforall-mod/coforall-mod.future -- Passing unexpected argument to default 'these' iterator causes internal error - # users/rohanbadlani/bugs/bug3.future -- The ref version of a ref/val function pair is sometimes chosen when the val - version would be better. - # functions/vass/setter-passed-to-another-fun.future - # functions/deitz/iterators/test_promote_var_function_and_iterate.future -- A forall loop with an iteratable expression that does not provide - leader/follower iterators cause an internal compiler error. - # functions/iterators/vass/forall-without-leaderfollower.future -- Function return point analysis is conservative. - # functions/deitz/test_return1.future - # trivial/preston/gcd.future -- Missing function body at declaration results in an internal compiler - error. - # functions/lydia/syntax-error-unclear-message.future - # functions/lydia/syntax-error-unclear-message2.future -- Function arguments of type 'const ref' should be allowed to have - default values. - # functions/sungeun/const_ref_arg_default_value.future -- Formal argument intents on 'this' can result in incorrect function resolution - or errors. - # functions/bradc/paramThis/funParamThis3.future - - -Strings -------- -- String assignment across locales is sometimes by reference and - sometimes by value. - # distributions/bradc/block1Dlocale.future -- Casting from complex to string mishandles -0.0i - # types/complex/diten/complexCastToString.future -- Casting a sync type to string results in an internal representation of - the type instead of a clean, user-facing representation. - # types/sync/vass/sync-type-1.future -- Implicit conversion of a param c_string to string does not work. - # types/string/diten/c_stringParamInfer.future -- c_string variable are sometimes copied to remote locales. - # types/string/sungeun/c_string/multilocale/remote_assign_c_string.future - # types/string/sungeun/c_string/multilocale/remote_assign_global_c_string.future -- Changes to a string used in a begin statement are not visible from - the begin body. - # types/string/sungeun/stringInBegin.future -- Global constant strings are not replicated across locales - # multilocale/bradc/stringConstRepl.future - - -Tuples ------- -- Specifying the type of a tuple of domains or arrays results in a - runtime error (nil dereference). It may be possible to work around - this by implicitly specifying the type by using an assignment at the - declaration. - # types/tuple/sungeun/hetTupleWithArray.future - # types/tuple/sungeun/hetTupleWithArrayInitWithType.future - # types/tuple/sungeun/hetTupleWithDomain.future - # types/tuple/sungeun/hetTupleWithDomainInitWithType.future - # types/tuple/sungeun/homTupleOfArrays.future - # types/tuple/sungeun/homTupleOfDomains.future - # types/tuple/claridge/tuple_of_domains.future - # arrays/vass/tuple-with-array-1.future -- Invalid use of tuple expansion as an expression results in the - expression evaluating to the first element of the tuple. - # functions/vass/return-of-tuple-expansion-1.future - # types/tuple/vass/tuple-expansion-with-parens-1.future -- Tuple expanded list enclosed in parenthesis does not result in a - tuple. - # functions/vass/return-of-tuple-expansion-2.future -- Cannot iterate over heterogeneous tuples - # types/tuple/sungeun/iteration/heteroTupleOfArrays.future - # types/tuple/sungeun/iteration/heteroTupleOfDomains.future - # types/tuple/sungeun/iteration/heteroTupleOfRanges.future -- Cannot iterate over a tuple of iteratable expressions (e.g., - iterators). - # types/tuple/sungeun/iteration/iteratable.future -- Reference tuples do not work. - # variables/kbrady/ref-in-tuple.future - # reductions/thomasvandoren/test/TestMini.future -- References cannot be members of classes or records. - # variables/kbrady/ref-member.future - - -Ranges ------- -- Range operations can result in overflow. - e.g., (0:uint..5 by -1).length - # arrays/elliot/maximalUintArray.future - # types/range/sungeun/length_broken.future -- Ranges that span the entire representable range of the index type - do not work. - # types/range/hilde/noCountBigUint.future -- Range alignment is not always displayed when printing a range using - writeln(). - # types/range/vass/writeranges-1.future -- The indexOrder() method on ranges does not work if the unbounded on - the 'low' end. - # types/range/vass/indexorder-nofirst-1.future - # types/range/vass/indexorder-nofirst-2.future -- Param ranges are not supported. - # users/sidelnik/param_range.future -- Range internals (bounds, stride, and alignment) are not checked for - overflow when being manipulated. - # types/range/hilde/needRangeCountType.future - # types/range/hilde/countError.future - # types/scalar/hilde/absMinInt.future - - -Classes, Records, and Unions ----------------------------- -- Generic domain types in field declarations result in a compile time - error. - # domains/vass/generic-domain-field.future -- Generic types in default value for type fields result in a compile time error - # functions/typeMethods/genericRecordTypeMethod.future - # users/ferguson/generic_type_method.future -- Record and class members that are defined to be array aliases fail - to compile without an explicitly specified element type. - # classes/stonea/arrayAliasRecordMember.future - # studies/hpcc/HPL/stonea/serial/hplExample1.future -- Multiple inheritance as defined in the spec (single base class with - fields) is not implemented. - # classes/figueroa/DestructorSubclassing2.future - # classes/figueroa/DestructorSubclassing3.future -- Records returned from functions are destructed incorrectly. - # types/records/kbrady/return-record.future -- User-defined initializers/constructors and destructors are not robust. - # users/murai/test_nested_class_constructor.future - # classes/bradc/initialize-secondary.future - # classes/vass/nested-class-with-user-defined-constructor-1.future - # classes/initializers/nested-class-with-user-defined-initializer-1.future - # classes/initializers/noReturnInInit.future - # classes/initializers/assign-param-segfault.future -- Copy constructors are not properly implemented. - # types/records/ferguson/missing-auto-copy.future - # types/records/sungeun/constructor2.future - # users/vass/km/array-of-records-crash-1.explicit-type.future - # users/vass/km/array-of-records-crash-1.future - # functions/ferguson/ref-return-intent6.future -- Generic methods called with param actuals may result in "unresolved - call" error at compile time or incorrect generated code. - # classes/vass/generic-method-with-param-arg-1.future - # classes/vass/generic-method-with-param-arg-2.future - # classes/vass/generic-method-with-param-arg-3.future -- Function resolution may be overly conservative for methods of subclasses. - # classes/bradc/compilerErrorInMethod/testClear.future - # classes/diten/subclassMethodCall.future -- Cannot call a standalone function from a class method of the same name - # functions/lydia/method-iter-resolution-bug.future -- Declaring class members using type aliases may result in unresolved - type errors. - # arrays/deitz/part5/test_array_type_field_type.future - # classes/diten/type_order_problem.future - # types/records/bharshbarger/nestedRecordInClass2.future -- Ambiguous definitions of class methods that are overridden in a - subclass result in an internal compiler error. - # classes/vass/duplicate-virtual-method-error-2.future -- Classes or records nested in procedures or iterators may result in a - compile time error. - # classes/vass/jglewis-class-in-function.future - # users/ferguson/record-in-iterator.future - # users/ferguson/inner-record-generic.future -- Non-sync arguments to default initializers/constructors that expect - sync vars are not properly coerced to sync type. - # classes/hannah/coercingIntToSyncIntOnConstructor.future - # classes/initializers/coercingIntToSyncIntOnInitializer.future -- Assigning to param class members from constructors may fail to compile - # classes/constructors/assign-param-segfault.future -- Implicit casting of record parameters not implemented. - # users/ferguson/recordEquivalence.future -- Atomic operations don't promote cleanly to whole arrays - # types/atomic/albrecht/arrayatomics.future -- Using a comparison operator with a record and 'nil' results in an - internal compiler error. - # types/records/sungeun/recordNotNil1.future - # types/records/sungeun/recordNotNil2.future -- Records inheritance does not properly expose parent methods. - # types/records/vass/method-of-parent-record-1.future -- Nested classes and records can result in multiple destructor calls - # classes/constructors/nested-destructor.future - # classes/initializers/nested-destructor.future -- Nested record inheritance results in a compilation error. - # types/records/vass/nested-record-with-outer-1.future -- Nested record constructor should not need an explicit generic outer - # users/bguarraci/nested_record.future -- Nested records as fields in outer classes/records is not robust - # types/records/engin/fieldOfOuter.future - # types/records/engin/nestedRecordField.future -- Unused records defined in procedures result in an internal compiler error. - # types/records/vass/unused-decl-in-proc-1.future - # types/records/vass/unused-decl-in-proc-2.future -- Recursive records result in function resolution error or internal - compiler error. - # types/records/sungeun/recursiveRecord.future - # arrays/dinan/array_of_records.future -- Classes arguments passed to out, inout, and ref intent formals - result in a compiler internal error. - # classes/vass/ref-like-intents/inout-subclass.future - # classes/vass/ref-like-intents/out-subclass.future - # classes/vass/ref-like-intents/ref-subclass.future -- Specifying the type when declaring a record variable with const - fields results in a compile time errors regarding assigning to const - fields. - # types/records/const-checking/todo-initializing-typed-var.future -- Default arrays of records with const fields result in compile time - errors regarding assigning to const fields. - # types/records/const-checking/scenario-1-array-of-record-with-const-fld.future - # types/records/const-checking/scenario-2-init-array-of-rec-with-const-fld.future - # types/records/const-checking/todo-constructors-for-const-rec-fields.future -- Associative domains and arrays of records with const fields result - in compile time errors regarding assigning to const fields. - # types/records/const-checking/scenario-3-assoc-dom-of-record-with-const-fld.future -- Comparison (== or !=) of records with array or domain fields result - in a back-end C compiler error. - # types/records/bharshbarger/recordArrCmp.future - # types/records/bharshbarger/recordDomArrCmp.future -- There's no way to determine which field of a union is "active". -- Setting union field from constructor doesn't work - # classes/diten/constructUnion.future - -Domain Maps, Domains and Arrays -------------------------------- -- Reference counting (used for memory management of domain maps, - domains, and arrays) may contain bugs. - # arrays/diten/replaceArrayAccess/arrayAlias2.future - # distributions/vass/dmap-var-decl.future - # studies/graph500/v1/main.future - # studies/hpcc/HPL/vass/bug.future -- The default domain map is currently a single type for all default domains - # distributions/bradc/layoutEquality.future -- Assignment from a distributed domain to a non-distributed domain causes - a runtime error. - # distributions/kushal/assignDomain.future -- Assignment to domain maps with declared domains not supported for - all domain map types. - # distributions/deitz/test_distribution_syntax2.future -- PrivateDist must be used at the top-level scope. - # distributions/sungeun/misc/useDummyDist.future -- Subset checks on subdomains is not implemented. -- Bounds checks are not implemented for block-cyclic array slices - # distributions/bradc/blkCyc/blkCycSliceOOB.future -- Bounds checks on index types is not implemented. -- Concurrent slicing of privatized Replicated arrays dereferences nil - # distributions/dm/hplx.future -- Query expressions on domains and subdomains not supported. - # domains/vass/domain-arg-query-expr.future - # functions/vass/arg-is-queried-domain.future -- Arrays of arrays where the inner arrays vary in size are not supported. - # arrays/deitz/test_skyline_array.future - # studies/590o/wk3/02arrOfArr-irregular.future -- Array of array procedure arguments may cause compile time errors - # users/kreider/bug_array_of_arrays.future -- Array values are permitted to be detupled in an iterator - # functions/iterators/bradc/badzip/misZipArrays.future -- Arrays of subdomains may not work. - # users/jglewis/bfs_102207/driver_breadth_first_search.future -- Indexing of array literals may be mis-parsed. - # arrays/vass/literal-indexing.future -- Arrays declared over domains with negative strides may result in errors. - # users/weili/arrNegDom-blc.future - # users/weili/arrNegDom2.future - # users/weili/arrNegDom3.future -- Array and domain runtime type information is not preserved through - generic instantiation. - # arrays/vass/initialization-mapped-1.future -- Modifications to Sparse domains are not thread-safe. - # domains/sungeun/sparse/forall.future - # domains/sungeun/sparse/stress.future -- Sparse domain/array slicing is not supported. - # arrays/stonea/sliceSparseSubdomain.future - # sparse/bradc/sliceWithDense.future -- Sparse arrays of arrays can halt when reading values that were not added - # functions/bharshbarg/sparse-ref-return.future -- Associative arrays of arrays can add new array elements by reading - empty positions - # functions/bharshbarg/assoc-ref-return.future -- Associative domain/array slicing is not supported. - # users/ferguson/assoc-slice.future -- Associative domain clear() does not reset values of arrays declared - over the domain. - # domains/sungeun/assoc/clear.future -- Associative domains with array or domain index types do not work. - # domains/sungeun/assoc/arrayIdxType.future - # domains/sungeun/assoc/assocArrayIdxType.future - # domains/sungeun/assoc/assocDomainIdxType.future - # domains/sungeun/assoc/domainIdxType.future - # domains/claridge/domainOfDomains.future - # puzzles/deitz/puzzle080117.future -- Associative domain literal syntax with a single domain index in - initializer drops the extra {} and becomes the same as the single - domain. - # domains/sungeun/assoc/literalSingleAssocDomain.future - # domains/sungeun/assoc/literalSingleDomain.future -- Associative arrays with associative array element types result in a - runtime error. - # arrays/johnk/associative/recursive.future -- Returning a runtime type computed from a local variable does not work - # types/type_variables/ferguson/returning-runtime-type-from-local.future -- Array type expressions evaluate the domain portion twice - # types/type_variables/ferguson/runtime-type-call-print.future -- Slicing a dimensional array with a different type of domain fails - # distributions/dm/sx8.future - -Task Parallelism and Synchronization ------------------------------------- -- Atomic statements are not implemented. -- Remove value forwarding does not respect the memory order imposed by - atomic variables. - # parallel/begin/deitz/test_begin_cobegin1_atomic.future -- Deadlock may occur due to an insufficient number of threads. - # multilocale/deitz/needMultiLocales/test_big_recursive_on.future - # multilocale/deitz/needMultiLocales/test_big_recursive_on_begin.future -- Arrays may not be moved to the heap due to begin statements or - other indirect array element accesses. - # memory/deitz/test_tricky_heap_case.future -- Sync variables cannot be used in conditional expressions - # types/sync/vass/if-sync-int.future -- Semantics of sync class types are not clearly defined - # parallel/sync/waynew/class3.future -- Default 'const ref' task intent for record does not prevent updates to sync - variable field in the record from within task. - # parallel/sync/waynew/record2.future - # parallel/sync/waynew/record2c.future -- A 'sync' statement with a 'begin' statement in it at module scope can cause - an internal compiler error. - # users/ferguson/bug-zhao.future -- Specifying one variable multiple times in a with clause should be an error - # parallel/taskPar/cassella/too-many-intents.future - -Data Parallelism ----------------- - # OMITTED: studies/lsms/shemmy/m-lsms.par-forall.future - # b/c it is unclear if this is user error or a bug -- Some data parallel statements that are meant to be parallelized in Chapel - are serialized with a warning message "X has been serialized". For - example: - 1. Scans are always serialized. - # arrays/deitz/parallelism/test_scan_is_parallel.future - 2. Assignments from ranges to multidimensional arrays are always serialized. -- Array promotion/forall/for/scan expressions always evaluate to 1D arrays. - E.g., f(A) where A promotes f() should result in an array of type: - [A.domain] f(A(i)).type but instead results in a 1D array - E.g., [i in D] f(i) should result in an array of type: [D] f(i).type - but instead results in a 1D array - # arrays/bradc/inferArrayType.future - # arrays/tmacd/promotionLosesArrayShape.future - # reductions/bradc/minmaxlocscan-shape.future - # sparse/bradc/inferSparseArrayType.future -- Parallel zippered iteration does not perform runtime size/shape checks - # functions/iterators/bradc/badzip/arrayZipMismatch.future - # functions/iterators/bradc/badzip/arrayZipMismatch2.future - # functions/iterators/bradc/badzip/rangeSizeMismatch.future -- Domain promotion results in a race condition. - # have not futurized yet (see REGRESSIONS domains/sungeun/assoc/minus_equals.chpl) -- Arrays and domains of different ranks can be zippered serially. -- Reductions and scans of arrays of arrays may result in errors. - # arrays/sungeun/array_of_arrays/bxor_reduce.future - # arrays/sungeun/array_of_arrays/max_reduce.future - # arrays/sungeun/array_of_arrays/sum_reduce.future - # studies/shootout/nbody/sidelnik/nbody_fullreduction.future -- Reduction type definitions nested in classes or records cannot be - used directly outside of enclosing class or record's scope. - # users/ferguson/histogram/reductionex_class.future - # users/ferguson/histogram/reductionex_record.future -- Reductions zippered arrays of mismatched rank result in a compile time error. - # arrays/diten/reduce2Dwith3D.future - # arrays/diten/reduce3Dwith2D.future -- Cannot not use an instance of a reduction class for a reduction. - # reductions/sungeun/count.future -- Whole-domain assignment operations on sparse domains are not all - serialized as they should be. - # domains/sungeun/sparse/minus_equals.future - # domains/sungeun/sparse/plus_equals.future -- Task intents do not work for coforalls and cobegins used in iterators. - # TODO: are there any futures? better wording? -- 'in' and 'const in' forall intents do not work correctly - # parallel/forall/in-intents/array-var-var.future - # parallel/forall/in-intents/both-arr-dom-const-var.future - # parallel/forall/in-intents/both-arr-dom-var-const.future - # parallel/forall/in-intents/domain-var-var.future -- Iterating over a range where bound+stride overflows the index type - results in runtime halt - # users/bguarraci/for_byte.future -- Overloaded xor used in a reduction may result in an internal - compiler error. - # reductions/bradc/badoverload.future -- Zipping an associative domain with another iterator in a forall loop can - result in compile time errors. - # users/ferguson/assoc_domain_zip_range1.future - # users/ferguson/assoc_domain_zip_range.future - - -Standard Modules, Standard Distributions, and Standard Layouts --------------------------------------------------------------- -- On some platforms, the Math module is limited by the back-end C compiler. -- Extended precision math functions are not supported. - # modules/standard/math/figueroa/extended-precision_math_functions.future -- The BlockCyclic distribution is incomplete. -- Reindexing stridable Cyclic is not fully supported. - # users/jglewis/test_cyclic_dist.future -- Block and Cyclic domains containing indices near the minimum or - maximum integral type may overflow. -- Array assignment fails for Block distributions with bounding boxes - that do not overlap with the bounds of the domain. - # arrays/sungeun/multilocale/weird_bbox_block.future -- Records with domain map fields do not work. - # types/records/sungeun/distInRecord.future - # types/records/sungeun/distInRecordInClass.future - - -Input and Output ----------------- -- Printing of replicated arrays may not work properly. - # io/vass/writeThis-on.future -- Using 'on' in a writeThis() method can lead to a deadlock. - # multilocale/bradc/needMultiLocales/writeThisUsingOn.future - # distributions/vass/dmap-writeln-default-value.future -- Calling writeln() of function names should be illegal, but currently - results in unexpected output, obscure error messages, or internal - compiler errors. - # io/sungeun/funcPtr1.future - # io/sungeun/funcPtr2.future - # io/sungeun/funcPtr3.future - # io/sungeun/funcPtr4.future - # io/sungeun/funcPtr5.future - # io/sungeun/funcPtr6.future -- Reading class fields out of order is not supported - # io/ferguson/read-class-reorder3.future - - -Optimizations -------------- -# OMITTED: optimizations/rafa/rankChange.future -# b/c workaround put in place -# OMITTED: arrays/diten/replaceArrayAccess/aliasThroughArgs2.future -# OMITTED: arrays/diten/replaceArrayAccess/modifyInAnotherTask2.future -# OMITTED: arrays/diten/replaceArrayAccess/wholeArrayAssignInLoop.future -# b/c this optimization is still in "experimental" phase -- Disabling inlining may cause incorrect code to be generated. - # SEE NIGHTLY BASELINE TESTING NOTES - # functions/deitz/nested/test_nested_var_iterator3.future -- Module scope runtime constants are not replicated across locales - # users/bguarraci/const_locale.future - - -Miscellaneous -------------- -# OMITTED: chpldoc/compflags/alphabetical/classFields.doc.future -# b/c the future is terse, and I have no idea what is wrong -# OMITTED: memory/shannon/memstatEquals.future -# b/c it's pretty benign and probably will not cause a problem -# OMITTED: modules/bradc/mainRoutineSurprise/M2.future -# b/c it's not clear if this is a bug or a feature request -# OMITTED: types/scalar/tmacd/fatal.future -# b/c it's a bit difficult to describe. -- Nil extern class references not properly handled. - # users/ferguson/extern_class_test.future -- Extern functions with array arguments cannot have specified 'void' return type - # users/ibertolacc/void_extern_proc_array.future -- Functions from extern includes that have naming conflicts with - internal functions result in a back-end C compiler error. - # extern/tzakian/shadow.future -- Functions and variables declared with the same name at the same scope result - in multiple definition errors - # users/bguarraci/function_name.future -- Leaving off () when calling exit results in an internal compiler - error. - # exits/albrecht/exitWithNoCall.future - # exits/sungeun/exitWithNoParensNoArgs.future -- Compiler warning mechanism not always type-checked correctly. - # users/vass/tuple-crash-1.future -- Compiler warning mechanism can result it lost warning if there are - multiple warnings. - # trivial/vass/repeated-warning-1.future -- If the -o argument matches an existing directory name , the - resulting binary is placed in /.tmp. - # compflags/bradc/dirNameMatchesBin/foo.future -- The usual scoping rules are not followed perfectly during function - and type resolution. - # types/records/sungeun/chapelTypes/record_range.future -- Programs requiring non-linear resolution may fail to compile. - E.g., mutual module uses that access variables across both modules -- Creating many domain types or arrays or tuples types causes the - compilation time to become unreasonable. - # arrays/deitz/many/test_many_arrays_of_star_tuples.future - # arrays/deitz/many/test_many_ranks_of_arithmetic_domains.future -- Types composed of runtime types are not runtime types. - # arrays/deitz/part3/test_record_of_array_type.future - # arrays/deitz/part3/test_record_of_domain_type.future - # arrays/deitz/part6/test_tuple_of_array.future - # types/tuple/diten/runtimeTypeInTuple.future - # types/tuple/diten/runtimeTypeInTuple2.future - # types/tuple/diten/tupleOfArray.future - # types/tuple/diten/tupleOfArray2.future - # types/tuple/stonea/returnArrayTuple.future -- Indexing string literals results in a parse error - # types/string/sungeun/c_string/substr.future -- Getting the locale-id of variable in local-on statement can be incorrect. - # optimizations/localon/bad-id.future - -Performance ------------ -- The body of forall loops over domains with non-default distribution - are unnecessarily cloned. - # distributions/bradc/clonedForall.future -- Many provably local variables are unnecessarily widen for - multilocale execution - # performance/bradc/refArgIsWide.future -- Task creation for coforall/cobegin statements can be better optimized. - # multilocale/lydia/checkNumTasks.future -- Mechanisms for program tear-down can be better optimized. - # parallel/taskPar/sungeun/endCountTest.future - - -chpldoc -------- -- chpldoc comments that are not closed with using the specified - comment style are not detected. - # chpldoc/compflags/comment/badClose.doc.future -- chpldoc is incorrect or incomplete for some types - # chpldoc/enum/docConstants.doc.future - - -Developer ---------- -- User defined chpl__initCopy() function are ignored in the - removeUnnecessaryAutoCopyCalls pass. - # classes/hilde/alwaysOverrideCopyInit.future -- The "no copy" and "no auto destroy" pragmas used with variable - declarations with specified types result in an internal compiler - error. - # trivial/sungeun/pragmas/noCopyNoDestroyPragma.future - # trivial/sungeun/pragmas/noCopyNoDestroyPragmaArray.future - # trivial/sungeun/pragmas/noCopyNoDestroyPragmaArrayWithInit.future - # trivial/sungeun/pragmas/noCopyNoDestroyPragmaWithInit.future - - -LLVM (experimental) -------------------- - - -Multi-locale/GASNet executions ------------------------------- -- stdin does not work for multi-locale/GASNet executions - - -Incremental compilation (experimental) --------------------------------------- -- Incremental compilation support is not enabled for LLVM - # compflags/kushal/llvm-incremental.future -- Cannot include C header files that define symbols with - incremental compilation enabled - # extern/kushal/extern-includes.future - - -Portability ------------ -Linux64: -- On some systems the GMP fac_ui function causes valgrind to issue invalid - read errors - # modules/standard/gmp/lydia/gmp_leak.future - -Ubuntu: -- Ubuntu 14.04 32-bit (not 64-bit) has a bug in preadv/pwritev support. - This problem may prevent proper functioning for many of Chapel's IO - routines. This problem is not present in Ubuntu 12.04 or 14.10 or any - 64-bit version. See the bug report here: - https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1309818 - -OpenSUSE: -- If the site-config package is installed, it sets a CONFIG_SITE environment - variable which causes some packages in third-party to store their - libraries in lib64 (vs lib) on 64-bit platforms. Unsetting CONFIG_SITE will - allow Chapel to build in that case. - -cygwin: -- cygwin builds may demonstrate portability issues. -- The qthreads tasking layer is not supported. -- Some utf8 characters have incorrect lengths on cygwin - # io/ferguson/utf8/widecols-cygwin-copy.future - -OS/X: -- For older version (e.g., leopard), the qthreads tasking layer is not - supported. -- Static linking not supported. - -PGI compilers: -- Chapel generated identifier names may be too long. - -Intel compilers: -- Static linking may not work. -# OMITTED: studies/lulesh/intelVectBug/lulesh.future -# We suspect that there is a vectorization bug with icc - -IEEE floating-point standard conformance: - The --ieee-float flag is implemented by passing appropriate flags to - the back-end compiler. For some compilers, 100% IEEE floating-point - conformance is not implemented. In such cases, the --ieee-float - flag will request the most standard conformant floating-point - behavior (if such behavior can be identified). - - -# Not Really Bugs -# OMITTED: modules/standard/LAPACK/dgees.future -# c_ptr(c_char) is the same signedness as the underlying c_char. I believe this -# test is incorrect about this point. -# OMITTED: users/bguarraci/count_type.future -# The range count operator's argument type shouldn't change the range's index type -# OMITTED: users/bguarraci/ref_nil_conjunction.future -# "if (classRef) then ..." is true if not nil, but -# "if (classRef1 && classRef2) then ..." doesn't treat each value as a boolean -# OMITTED: users/bguarraci/sorted_access.future -# iterator or promoted expressions cannot be accessed as arrays without -# assigning to an array first -# OMITTED: users/bguarraci/string_compilation.future -# string(1) is an unresolved call to a function named string, not a cast from -# int to string diff --git a/doc/rst/platforms/cygwin.rst b/doc/rst/platforms/cygwin.rst index e003691b336f..76ea0688cebf 100644 --- a/doc/rst/platforms/cygwin.rst +++ b/doc/rst/platforms/cygwin.rst @@ -36,7 +36,7 @@ hard-drive (``/cygdrive/c/``) to create ``/cygdrive/c/chapel`` tends to work well. Currently, our compiler-generated Makefiles break when the compiler or runtime use an absolute path that contains spaces. If any Cygwin experts have tips on addressing this issue in a portable way, -please let us know at :disguise:`chapel_info@cray.com`. +please let us know. Required Packages diff --git a/doc/rst/technotes/extern.rst b/doc/rst/technotes/extern.rst index faca186c6d36..7162f20b26df 100644 --- a/doc/rst/technotes/extern.rst +++ b/doc/rst/technotes/extern.rst @@ -997,6 +997,6 @@ Future Directions ================= We intend to continue improving these capabilities to provide richer -and richer support for external types and functions over time. If you -have specific requests for improvement, please let us know at: -:disguise:`chapel_info@cray.com`. +support for external types and functions over time. If you +have specific requests for improvement, please let us know on the +Chapel GitHub issue page or community forums. diff --git a/doc/rst/technotes/firstClassFns.rst b/doc/rst/technotes/firstClassFns.rst index 9e9afcedd7c3..d849cb041696 100644 --- a/doc/rst/technotes/firstClassFns.rst +++ b/doc/rst/technotes/firstClassFns.rst @@ -150,4 +150,5 @@ Future Directions Over time, we will be improving the support for first-class functions and their syntax. If you have specific feature requests or -suggestions, please let us know at: :disguise:`chapel_info@cray.com`. +suggestions, please let us know on the Chapel GitHub issues page or +community forums. diff --git a/doc/rst/usingchapel/bugs.rst b/doc/rst/usingchapel/bugs.rst index 26b8ec1e28bf..80bbddd11e2d 100644 --- a/doc/rst/usingchapel/bugs.rst +++ b/doc/rst/usingchapel/bugs.rst @@ -4,28 +4,6 @@ Reporting Chapel Issues ======================= -Public Issues -------------- - Chapel uses `GitHub Issues`_ to track public issues. If you have a bug report, feature request, or other issue to report, please use the "New Issue" button on that page to file it. - -Public issues that predate our issue tracker can be found in the -(retired) `STATUS.devel file`_ and the (retired) -`chapel-bugs mailing list archives`_. - -Private Issues --------------- - -Chapel accepts private issue reports :any:`by email `. - -.. _GitHub Issues: https://github.com/chapel-lang/chapel/issues -.. _chapel-bugs mailing list archives: https://sourceforge.net/p/chapel/mailman/chapel-bugs/ -.. _STATUS.devel file: https://github.com/chapel-lang/chapel/blob/master/STATUS.devel - -.. toctree:: - :hidden: - :maxdepth: 1 - - privatebugs diff --git a/doc/rst/usingchapel/building.rst b/doc/rst/usingchapel/building.rst index 9a45ff151b0f..f0981effb1a6 100644 --- a/doc/rst/usingchapel/building.rst +++ b/doc/rst/usingchapel/building.rst @@ -163,7 +163,7 @@ new build environment by creating ``Makefile.`` and/or ``Makefile.`` files and setting your environment variables to refer to those files. If you do develop new build environment support that you would like to contribute back to the community, we encourage -you to send your changes back to us at: :disguise:`chapel_info@cray.com` +you to submit a pull request to the Chapel GitHub repository. .. _readme-installing: diff --git a/doc/rst/usingchapel/chplenv.rst b/doc/rst/usingchapel/chplenv.rst index da7e8049adc0..c7cccd450974 100644 --- a/doc/rst/usingchapel/chplenv.rst +++ b/doc/rst/usingchapel/chplenv.rst @@ -116,8 +116,7 @@ CHPL_HOST_PLATFORM We are interested in making our code framework portable to other platforms -- if you are using Chapel on a platform other than the ones listed above, please refer to :ref:`platform-specific-settings` for ways to set up a - Makefile for this platform and/or contact us at: - :disguise:`chapel_info@cray.com` + Makefile for this platform. .. _readme-chplenv.CHPL_TARGET_PLATFORM: diff --git a/doc/rst/usingchapel/privatebugs.rst b/doc/rst/usingchapel/privatebugs.rst deleted file mode 100644 index b1553caa213a..000000000000 --- a/doc/rst/usingchapel/privatebugs.rst +++ /dev/null @@ -1,38 +0,0 @@ -.. _readme-privatebugs: - -========================= -Private Issues Guidelines -========================= - -If for any reason you are uncomfortable reporting your bug in a public setting, -you may submit a private bug report. - -Private issues can be sent to the core Chapel team at HPE using: -:disguise:`chapel_bugs@cray.com` - -When submitting a private bug report, please include the following information: - -.. note:: - - **Summary of Problem** - - - What behavior did you observe when encountering this issue? - - What behavior did you expect to observe? - - **Steps to Reproduce** - - - Please attach source code that will reproduce the problem. - - To the extent possible, providing simplified programs demonstrating the - problem will be appreciated. - - If you are unable to submit code, please describe how to recreate the - issue. - - **How did you compile your program? e.g.** ``chpl foo.chpl -o foo`` - - How did you execute your program? e.g. ``./foo 42`` - - If any input files are required, please include them as well. - - **Configuration Information** - - - Output of ``chpl --version``: - - Output of ``$CHPL_HOME/util/printchplenv --anonymize``: - - Back-end compiler and version, e.g. ``gcc --version`` or ``clang --version``: - - (For Cray systems only) Output of ``module list``: diff --git a/doc/rst/usingchapel/tasks.rst b/doc/rst/usingchapel/tasks.rst index 2205a782fb62..99d84f49d464 100644 --- a/doc/rst/usingchapel/tasks.rst +++ b/doc/rst/usingchapel/tasks.rst @@ -35,9 +35,6 @@ detail. The rest of this document includes: * a list of tasking-related methods on the locale type * a brief description of future directions for the tasking layer -If you have questions about tasks that are not covered in the following, -please send them to :disguise:`chapel_info@cray.com`. - -------------------------- Task Implementation Layers @@ -273,9 +270,8 @@ The Chapel program will generate an error if the requested number of threads per locale is too large. For example, when running multi-locale programs, the GASNet communication layer typically places an upper bound of 127 or 255 on the number of threads per locale (There are ways to -work around this assumption on certain platforms -- please contact us at -:disguise:`chapel_info@cray.com` or peruse the GASNet documentation if you need -to do so.) +work around this assumption on certain platforms -- please contact us if +you need to do so, or peruse the GASNet documentation). CHPL_TASKS == fifo ------------------ @@ -426,5 +422,5 @@ balancing at the other end of the spectrum (for programmers who would prefer not to manage threads or whose programs cannot trivially be load balanced manually). Our hope is to leverage existing open source threading and task management software and to collaborate with others -in these areas, so please contact us at :disguise:`chapel_info@cray.com` if you'd +in these areas, so please contact us if you'd like to work with us in this area. diff --git a/highlight/emacs/chpl-mode.el b/highlight/emacs/chpl-mode.el index 65e389e13fa0..489959f8ccde 100644 --- a/highlight/emacs/chpl-mode.el +++ b/highlight/emacs/chpl-mode.el @@ -1,7 +1,7 @@ ;;; chpl-mode.el --- Major mode for editing Chapel code ;; Author: 2007 Steven T Balensiefer -;; Maintainer: Chapel group +;; Maintainer: Chapel group ;; Created: December 2002 ;; Version: 0.7 ;; Keywords: Chapel languages oop diff --git a/test/release/examples/primers/sparse.chpl b/test/release/examples/primers/sparse.chpl index ca1165da255f..362b8985bc9a 100644 --- a/test/release/examples/primers/sparse.chpl +++ b/test/release/examples/primers/sparse.chpl @@ -282,9 +282,8 @@ writeSpsArr(); // over time. // // Anyone reading this far who is interested in exploring more with -// sparse domains and arrays in Chapel is encouraged to contact us at -// chapel_info@cray.com. We currently have a Compressed Sparse Row -// (CSR) sparse domain/array layout within our modules and an -// implementation of the NAS CG benchmark that makes use of it, and -// would be happy to provide the curious with full explanations of -// the features therein, and are open to new suggestions. +// sparse domains and arrays in Chapel is encouraged to contact us. +// We currently have a Compressed Sparse Row (CSR) sparse domain/array +// layout within our modules and an implementation of the NAS CG benchmark +// that makes use of it, and would be happy to provide the curious with +// full explanations of the features therein, and are open to new suggestions. diff --git a/test/sparse/bradc/CSR/sparse.chpl b/test/sparse/bradc/CSR/sparse.chpl index 6b9e91d8c8ea..ef53827b2f8f 100644 --- a/test/sparse/bradc/CSR/sparse.chpl +++ b/test/sparse/bradc/CSR/sparse.chpl @@ -260,9 +260,8 @@ writeSpsArr(); // over time. // // Anyone reading this far who is interested in exploring more with -// sparse domains and arrays in Chapel is encouraged to contact us at -// chapel_info@cray.com. We currently have a Compressed Sparse Row -// (CSR) sparse domain/array implementation in the works and a -// virtually complete implementation of the NAS CG benchmark that -// makes use of it, and would be happy to share those examples with -// users of the release. +// sparse domains and arrays in Chapel is encouraged to contact us. +// We currently have a Compressed Sparse Row (CSR) sparse domain/array +// implementation in the works and a virtually complete implementation +// of the NAS CG benchmark that makes use of it, and would be happy to +// share those examples with users of the release. diff --git a/test/studies/590o/blerner/FEEDBACK b/test/studies/590o/blerner/FEEDBACK deleted file mode 100644 index e48a42ebf7c1..000000000000 --- a/test/studies/590o/blerner/FEEDBACK +++ /dev/null @@ -1,80 +0,0 @@ -These thoughts are all "in the small", focusing on things I saw while -trying to write my toy program. They're not necessarily language-wide -things. - -* The language seems very large, and as had been said during the -quarter, it's not clear what the core of the language is. - -* I know we discussed this in class, but while writing my toy program, I -could not keep straight the difference between calling functions with [] -versus (). Most of the time, it didn't matter -- most of my functions -were one-argument anyway, but I was confused by the documentation about -string.substring: you show both foo.substring(i) and foo.substring[i], -but only foo.substring[i..j], so I wasn't ever sure whether ranges were -treated as single variables or whether they were zipped over... - -* The semantics of begin, cobegin, forall and coforall need some -clarification. For instance, the spec should say explicitly something -like, "Coforall { } is sugar for forall { begin { - } }", rather than just the English prose it currently has. - -* I ran across a bug in the implementation of coforall loops where if -your iteration variable has structure (a tuple or something), the -current compiler doesn't privatize the destructured values properly. -Combining the first and third points above, why can't you say "'for - in <2+D domain> { }' is sugar for 'for temp in <2+D -domain> { const = temp; }'. In all cases, temp is -locally scoped to the current iteration of the loop." Then your -compiler bug goes away, because your semantic support for loops is -simplified. - -* I'd like to hierarchically define domains. That is, given domains D1, -D2, I want to define var D3 = [D1, D2] and have it be the cartesian -product of them. It's of no big deal to me whether you flatten those -domains (e.g. if D1 and D2 were a 1-D and a 2-D domain, whether D3 would -be a standard 3-D domain or a 1D x (2-D) domain) with coordinates ((x), -(y, z)). - -* File IO is sorely lacking :-p - -* Idiomatically, I wanted the ability to construct lists of values and -fold over them. The best I came up with was to define sparse domains -and add elements to them, then iterate over indices in the sparse -domain. That seems rather "meta" -- I want a list of those values, not -have those values be indices to some other array. - -* Also, once I'd defined a sparse domain, and an array using it, every -time I added an element to the domain that array must be reallocated, -no? I'd like a way to say, "Here's a dense domain, and a sparse domain -over it, and an array over *that*; now hang on a sec while I initialize -the sparse domain... ok, *now* go ahead and allocate that array once and -for all, thanks." - -* There doesn't seem to be an easy way to re-order iterators, or if -there is I didn't understand it clearly. For instance, given the -iteration [1..2, 1..4], which yields the pairs (1,1), (1,2), (1,3), -(1,4), (2,1), (2,2), (2,3), (2,4) in that order, I'd like a simple way -to "take the transpose" of that and get column major order. If I'd had -that, then I wouldn't have been bitten by the coforall bug above -- I -could have used a forall loop instead. :) I suspect I could work around -this by having done forall (y,x) in [1..4, 1..2], which swaps the -variables and also the iterator, but that feels not-clean, somehow. - -Some slightly larger thoughts: - -* The core of the language is a bigger issue. - -* The syntax isn't well specified in the spec, I think due to its change -over time. But it wasn't clear why you had an optional "then" keyword, -for instance; pick one syntax (e.g. C's, since you're very close to it -already) and stick to it. Or, if you want the flexibility, give -examples of the different options. - -* There's a heavy learning curve, I think, which is aggravated by the -lack of examples. A lot of the code I wrote was written via -copy-paste-modify, and I wasn't always sure what syntax was critical and -what was style and what was optional. - - -That's all for now; if I think of other stuff I'll send it your way. -~ben diff --git a/test/studies/590o/blerner/FEEDBACK-blc b/test/studies/590o/blerner/FEEDBACK-blc deleted file mode 100644 index 3dc1566126b0..000000000000 --- a/test/studies/590o/blerner/FEEDBACK-blc +++ /dev/null @@ -1,257 +0,0 @@ - -A few responses here, with the intent of helping you leave the language -study with a few more questions answered. I agree that most of the things -that you point out could be better documented/rationalized. - -Thanks for your thoughts -- we really appreciate them, --Brad - ------------- - -> * I know we discussed this in class, but while writing my toy program, I -> could not keep straight the difference between calling functions with [] -> versus (). Most of the time, it didn't matter -- most of my functions were -> one-argument anyway, but I was confused by the documentation about -> string.substring: you show both foo.substring(i) and foo.substring[i], but -> only foo.substring[i..j], so I wasn't ever sure whether ranges were treated -> as single variables or whether they were zipped over... - -Here's how I remember the zipper vs. tensor semantics -- it's based -strongly on how the choice of syntax fell out: Our belief was that for a -function call with two promoted arguments -- say, exp(A, B) -- the natural -interpretation seemed to be to zipper the arguments and create a result of -the same shape (e.g., exp(A(1), B(1)), exp(A(2), B(2)), ...). Meanwhile, -array slicing notation, which is a tensor product, more traditionally uses -square brackets -- A[2:n-1, 2:n-1] in Fortran, for example. - -Stylistically, when I'm slicing an array, I almost always use square -brackets, even if its a 1D slice like A[i, 1..n]. This is equivalent to -A(i, 1..n) of course, but I tend to use the square brackets because it -looks more like a slice to me. - -I suspect that the author of the substring code (which may have been me, -though I don't think it was), was falling into a similar mode, thinking of -a substring as being a slice of a string. At some point, I think we even -supported substring slicing via the indexing function, so this may have -been a leftover from that conversion. All that said, I suspect that I'd -probably write it using parenthesis today now that it looks more like a -method and I don't think of it as being a promotion. Do you remember -where you saw that? Language spec or example codes? - - -> * The semantics of begin, cobegin, forall and coforall need some -> clarification. For instance, the spec should say explicitly something like, -> "Coforall { } is sugar for forall { begin { } }", -> rather than just the English prose it currently has. - -Agreed. This makes sense to me. I'd probably describe it less in terms -of sugar and more interms of "semantically equivalent to", since that -suggests that we might implement it intelligently (using a tree of spawns -rather than a linear sequence of them, e.g.). Sugar implies strongly to -me that it is probably just implemented by making the conversion you -specified. - -Note that the sugar you give above is incomplete because it doesn't -capture the join at the bottom of the forall loop. The rewrite of this -would probably involve capturing some sort of termination condition into a -sync variable and waiting after the loop for all the sync variables to be -filled. The tedium of writing this common idiom all of the time was part -of the motivation for introducing the coforall (along with the observation -that we could probably do the spawn and joins more efficiently for a large -group of tasks than a beginning or lazy user would bother to. - - -> * I ran across a bug in the implementation of coforall loops where if your -> iteration variable has structure (a tuple or something), the current compiler -> doesn't privatize the destructured values properly. Combining the first and -> third points above, why can't you say "'for in <2+D domain> { -> }' is sugar for 'for temp in <2+D domain> { const = temp; }'. -> In all cases, temp is locally scoped to the current iteration of the loop." -> Then your compiler bug goes away, because your semantic support for loops is -> simplified. - -As I understand it, this rewrite is essentially what we do, but a -"privatize me" flag on the original variables wasn't getting propagated to -the temporary variables appropriately, causing the temps to be allocated -on the stack rather than the heap in the generated code, which is what -resulted in having multiple threads share the values. So yes, we think in -terms of these rewrites, but that doesn't imply that the compiler will be -bug-free. Steve's already working on the fix for this. - - -> * I'd like to hierarchically define domains. That is, given domains D1, D2, -> I want to define var D3 = [D1, D2] and have it be the cartesian product of -> them. It's of no big deal to me whether you flatten those domains (e.g. if -> D1 and D2 were a 1-D and a 2-D domain, whether D3 would be a standard 3-D -> domain or a 1D x (2-D) domain) with coordinates ((x), (y, z)). - -We do too. This is on the todo list. - - -> * File IO is sorely lacking :-p - -Agreed. - - -> * Idiomatically, I wanted the ability to construct lists of values and fold -> over them. The best I came up with was to define sparse domains and add -> elements to them, then iterate over indices in the sparse domain. That seems -> rather "meta" -- I want a list of those values, not have those values be -> indices to some other array. - -I'd suggest thinking of the domains truly as 1st class index sets, and not -simply a means of creating an array. For example, I use associative -domains to implement sets of values all the time, and never allocate -arrays over them. Along those same lines, I think sparse arithmetic -domains are a very reasonable way to store a sorted list of elements from -a bounded set of indices, even if they're never used to implement an -array. - -All that said, it is our intention to support a standard list class in the -standard libraries (and in fact, I think we have a first draft already -there -- I'm not sure if it's documented). We used to have a sequence -type in the language, but it was one thing that's been pruned out of the -language and put into the library with the goal of making the language -smaller. - - -> * Also, once I'd defined a sparse domain, and an array using it, every time I -> added an element to the domain that array must be reallocated, no? I'd like -> a way to say, "Here's a dense domain, and a sparse domain over it, and an -> array over *that*; now hang on a sec while I initialize the sparse domain... -> ok, *now* go ahead and allocate that array once and for all, thanks." - -Does anything prevent you in this case from moving the declaration of the -array after the sparse domain's initialization? If not, I'd suggest doing -that -- declare the dense domain, the sparse domain, initialize the sparse -domain, now declare the sparse array. That way, the allocation happens in -one fell swoop as you'd like. - -In any case, I believe an important compiler optimization for sparse -domains/arrays is going to be to batch up reallocations like this on the -user's behalf (and this is the sort of thing that fits into that second -"optional interface" category of a distribution -- a sparse implementation -that wants to support this kind of optimized addition would support it, -but there would be no requirement to support modification of more than one -index at a time. - -Even with such an optimization, as a distrustful user, I'd still move the -array declaration after the sparse domain's initialization, if I had the -power to do so. - -Or, can the sparse domain be initialized on its declaration line rather -than after its declaration (using an iterator, e.g.)? This would be the -ideal way to do it since it would allow the sparse domain to be declared -const, which should result in other optimization and readability benefits. - - -> * There doesn't seem to be an easy way to re-order iterators, or if there is -> I didn't understand it clearly. For instance, given the iteration [1..2, -> 1..4], which yields the pairs (1,1), (1,2), (1,3), (1,4), (2,1), (2,2), -> (2,3), (2,4) in that order, I'd like a simple way to "take the transpose" of -> that and get column major order. If I'd had that, then I wouldn't have been -> bitten by the coforall bug above -- I could have used a forall loop instead. -> :) I suspect I could work around this by having done forall (y,x) in [1..4, -> 1..2], which swaps the variables and also the iterator, but that feels -> not-clean, somehow. - -If you're doing a forall loop then by definition you're abdicating control -over the iteration order of the loop (and since our forall loops are -currently sequential, you're going to get our default iteration order of -RMO in practice). You can regain this control by authoring the -distribution for the domain over which you're iterating, in which case -you're specifying the implementation of forall loops. - -A lighter-weight way to do this would be to simply write your own -standalone iterator: - - def CMO(D: domain(2)) { - for i in D.dim(1) { - for j in D.dim(1) { - yield (i,j); - } - } - } - -and invoke it: - - for (x,y) in CMO([1..2, 1..4]) { - ... - } - -This looks simple because it's all sequential -- making it parallel would -be harder, but given that you have some pretty heavy constraints on the -order of the parallelism, that seems appropriate. Implementing parallel -wavefront style loops has similar issues -- one technique is to use an -array of sync variables to control when each iteration can legally fire. - - - -> * The syntax isn't well specified in the spec, I think due to its change over -> time. - -Hmm, I don't think it's changed that much since the spec was written. -Could you clarify for me in what way it seems poorly specified and how it -could be improved? Are you referring to the syntax "diagrams" or the -supporting text that describes them? - -> But it wasn't clear why you had an optional "then" keyword, for -> instance; pick one syntax (e.g. C's, since you're very close to it already) -> and stick to it. - -For single-statement conditionals, there's a syntactic ambiguity due to -Chapel's use of square brackets for both function arguments and forall -loops. For example: - - if A [D] write("hi"); - -Could be: - - if A[D] { - write("hi"); - } - -or: - - if A { - [D] write("hi"); - } - -So optional keywords like "then" (and its partners in crime) are used to -support the single statement cases of control flow: - - if A[D] then write("hi"); - - if A then [D] write("hi"); - -Since the single statement could itself be a compound statement, this -permits: - - if A then { [D] write("hi"); write("there"); } - -but of course, the then isn't strictly required in this case. The result -is if you use curly brackets religiously, you'll end up being very C-like. -If you like to avoid curly brackets in single-statement cases, you need to -use the keywords. - -This rationale should be captured in the spec if it isn't already. - -If you have thoughts about getting rid of the then altogether, that would -of course be of interest. - - - -> * There's a heavy learning curve, I think, which is aggravated by the lack of -> examples. A lot of the code I wrote was written via copy-paste-modify, and I -> wasn't always sure what syntax was critical and what was style and what was -> optional. - -Are you talking about examples in the spec (which I'd completely agree -with), or examples in the release itself (which I could also agree with, -but would need some suggestions about what examples you'd like to see -included, or how the existing examples could be made more instructive -- -we're happy to add more, but don't want to overwhelm anyone by providing -more than they can wrap their heads around). - - - diff --git a/test/studies/590o/blerner/FEEDBACK2 b/test/studies/590o/blerner/FEEDBACK2 deleted file mode 100644 index c5e0b1e3e235..000000000000 --- a/test/studies/590o/blerner/FEEDBACK2 +++ /dev/null @@ -1,332 +0,0 @@ -From blerner@cs.washington.edu Thu Dec 6 11:51:01 2007 -Date: Thu, 06 Dec 2007 11:50:58 -0800 -From: Ben Lerner -To: Brad Chamberlain -Subject: Re: Thoughts on using Chapel - -And some replies to those. Most of my "complaints" can be waved away as -"newbie alerts", so take them with a large grain of salt... - -~ben -> > * I know we discussed this in class, but while writing my toy program, I -> > could not keep straight the difference between calling functions with [] -> > versus (). Most of the time, it didn't matter -- most of my functions -> > were one-argument anyway, but I was confused by the documentation about -> > string.substring: you show both foo.substring(i) and foo.substring[i], -> > but only foo.substring[i..j], so I wasn't ever sure whether ranges were -> > treated as single variables or whether they were zipped over... -> -> Here's how I remember the zipper vs. tensor semantics -- it's based -> strongly on how the choice of syntax fell out: Our belief was that for a -> function call with two promoted arguments -- say, exp(A, B) -- the natural -> interpretation seemed to be to zipper the arguments and create a result of -> the same shape (e.g., exp(A(1), B(1)), exp(A(2), B(2)), ...). Meanwhile, -> array slicing notation, which is a tensor product, more traditionally uses -> square brackets -- A[2:n-1, 2:n-1] in Fortran, for example. -> -> Stylistically, when I'm slicing an array, I almost always use square -> brackets, even if its a 1D slice like A[i, 1..n]. This is equivalent to -> A(i, 1..n) of course, but I tend to use the square brackets because it -> looks more like a slice to me. -> -> I suspect that the author of the substring code (which may have been me, -> though I don't think it was), was falling into a similar mode, thinking of -> a substring as being a slice of a string. At some point, I think we even -> supported substring slicing via the indexing function, so this may have -> been a leftover from that conversion. All that said, I suspect that I'd -> probably write it using parenthesis today now that it looks more like a -> method and I don't think of it as being a promotion. Do you remember -> where you saw that? Language spec or example codes? -> -I saw these three snippets in the documentation. Part of my confusion I -think was my C-programmer's intuition that a string is a char array, and -therefore brackets are appropriate. But it's a function call, and I don't -think I want tensor semantics, so parentheses. Wait, but there's only one -argument, so they're equivalent. And so on, round and round. Your example -of A[i, 1..n] is particularly tricky -- when i is holding a range, this has -very different semantics between [] and (), even though it looks like -there's only one range present to slice over. If you went with your current -suspicion and wrote it with parens today, you'd get, what, a diagonal slice -of characters through an array of strings? I'm not saying your design is -wrong, just that it takes getting used to, and can hide some unexpected -complexities. -> -> > * The semantics of begin, cobegin, forall and coforall need some -> > clarification. For instance, the spec should say explicitly something -> > like, "Coforall { } is sugar for forall { begin { -> > } }", rather than just the English prose it currently has. -> -> Agreed. This makes sense to me. I'd probably describe it less in terms -> of sugar and more interms of "semantically equivalent to", since that -> suggests that we might implement it intelligently (using a tree of spawns -> rather than a linear sequence of them, e.g.). Sugar implies strongly to -> me that it is probably just implemented by making the conversion you -> specified. -As I understood the semantics of forall, you *might* implement the -iterations sequentially, or in parallel; I wasn't sure which behavior -happened when or why. But if you were to implement forall in parallel, then -surely the same tree-of-spawns would be used for coforall. So I didn't see -the sugar as being restrictive of your implementation strategies. That -said, sure -- saying they're semantically equivalent is fine for programmer -understanding. -> -> Note that the sugar you give above is incomplete because it doesn't -> capture the join at the bottom of the forall loop. The rewrite of this -> would probably involve capturing some sort of termination condition into a -> sync variable and waiting after the loop for all the sync variables to be -> filled. The tedium of writing this common idiom all of the time was part -> of the motivation for introducing the coforall (along with the observation -> that we could probably do the spawn and joins more efficiently for a large -> group of tasks than a beginning or lazy user would bother to. -True, I forgot that point :). But the larger point remains, if you can -"compile away" coforall loops into even an inefficient representation using -foralls and joins and whatever, then you've shrunk the core language. I -think, in fact, that the only two concepts you need in this space are -for-loops and begin; cobegin, forall, and coforall can all be implemented in -terms of those two. -> -> -> > * I ran across a bug in the implementation of coforall loops where if -> > your iteration variable has structure (a tuple or something), the -> > current compiler doesn't privatize the destructured values properly. -> > Combining the first and third points above, why can't you say "'for -> > in <2+D domain> { }' is sugar for 'for temp in <2+D -> > domain> { const = temp; }'. In all cases, temp is locally -> > scoped to the current iteration of the loop." Then your compiler bug -> > goes away, because your semantic support for loops is simplified. -> -> As I understand it, this rewrite is essentially what we do, but a -> "privatize me" flag on the original variables wasn't getting propagated to -> the temporary variables appropriately, causing the temps to be allocated -> on the stack rather than the heap in the generated code, which is what -> resulted in having multiple threads share the values. So yes, we think in -> terms of these rewrites, but that doesn't imply that the compiler will be -> bug-free. Steve's already working on the fix for this. -Ok, I was thinking of fixing this as sugar in the parser, because we know -that rewriting this explicitly fixed the bug. Either way works. -> -> > * Idiomatically, I wanted the ability to construct lists of values and -> > fold over them. The best I came up with was to define sparse domains -> > and add elements to them, then iterate over indices in the sparse -> > domain. That seems rather "meta" -- I want a list of those values, not -> > have those values be indices to some other array. -> -> I'd suggest thinking of the domains truly as 1st class index sets, and not -> simply a means of creating an array. For example, I use associative -> domains to implement sets of values all the time, and never allocate -> arrays over them. Along those same lines, I think sparse arithmetic -> domains are a very reasonable way to store a sorted list of elements from -> a bounded set of indices, even if they're never used to implement an -> array. -> -> All that said, it is our intention to support a standard list class in the -> standard libraries (and in fact, I think we have a first draft already -> there -- I'm not sure if it's documented). We used to have a sequence -> type in the language, but it was one thing that's been pruned out of the -> language and put into the library with the goal of making the language -> smaller. -> -> -Makes sense. The thing I felt awkward about was wanting to write ([i in D] -i) all the time to grab the indices out of the domain. It feels like a -weird typecast : arith.domain.indextype -> int. I was trying to maintain in -my head that "yeah, they domain uses ints for indices, but treat them as -opaque, or else there's a slippery slope to thinking ints are indices when -they're not." Maybe that's just me being new to Chapel. - -> > * Also, once I'd defined a sparse domain, and an array using it, every -> > time I added an element to the domain that array must be reallocated, -> > no? I'd like a way to say, "Here's a dense domain, and a sparse domain -> > over it, and an array over *that*; now hang on a sec while I initialize -> > the sparse domain... ok, *now* go ahead and allocate that array once and -> > for all, thanks." -> -> Does anything prevent you in this case from moving the declaration of the -> array after the sparse domain's initialization? If not, I'd suggest doing -> that -- declare the dense domain, the sparse domain, initialize the sparse -> domain, now declare the sparse array. That way, the allocation happens in -> one fell swoop as you'd like. -I wanted all the declarations to be global, so I wouldn't have to pass them -around in my code. -> -> In any case, I believe an important compiler optimization for sparse -> domains/arrays is going to be to batch up reallocations like this on the -> user's behalf (and this is the sort of thing that fits into that second -> "optional interface" category of a distribution -- a sparse implementation -> that wants to support this kind of optimized addition would support it, -> but there would be no requirement to support modification of more than one -> index at a time. -> -> Even with such an optimization, as a distrustful user, I'd still move the -> array declaration after the sparse domain's initialization, if I had the -> power to do so. -> -> Or, can the sparse domain be initialized on its declaration line rather -> than after its declaration (using an iterator, e.g.)? This would be the -> ideal way to do it since it would allow the sparse domain to be declared -> const, which should result in other optimization and readability benefits. -Not in my case -- the sparse domain StartIndices, for instance, is the -location of all "<" characters in the input, and the positions just after -all ">" characters. That said, they are constant, right after I figure that -information out. Here's a wacky thought: would the following work? -const AllIndices : [1..length(input)] -var StartIndices : single sparse subdomain(AllIndices) <<== note the -single! -var EndIndices : single sparse subdomain(AllIndices) <<== note the single! -var parsedElements : [StartIndices, EndIndices] single XmlElement <<== -hierarchical domains, not there yet but soon :) - -/* expectation: parsedElements has not been allocated yet, since it's -waiting for StartIndices and EndIndices to be assigned */ - -StartIndices = ComputeStartIndices(input); /* still waiting... */ -EndIndices = ComputeEndIndices(input); -/* Ok, go! Both sets of indices are available, so parsedElements can be -allocated. Moreover, unless it's reassigned, the domain of parsedElements -must be constant. */ - -> > * There doesn't seem to be an easy way to re-order iterators, or if -> > there is I didn't understand it clearly. For instance, given the -> > iteration [1..2, 1..4], which yields the pairs (1,1), (1,2), (1,3), -> > (1,4), (2,1), (2,2), (2,3), (2,4) in that order, I'd like a simple way -> > to "take the transpose" of that and get column major order. If I'd had -> > that, then I wouldn't have been bitten by the coforall bug above -- I -> > could have used a forall loop instead. :) I suspect I could work around -> > this by having done forall (y,x) in [1..4, 1..2], which swaps the -> > variables and also the iterator, but that feels not-clean, somehow. -> -> If you're doing a forall loop then by definition you're abdicating control -> over the iteration order of the loop (and since our forall loops are -> currently sequential, you're going to get our default iteration order of -> RMO in practice). You can regain this control by authoring the -> distribution for the domain over which you're iterating, in which case -> you're specifying the implementation of forall loops. -> -> A lighter-weight way to do this would be to simply write your own -> standalone iterator: -> -> def CMO(D: domain(2)) { -> for i in D.dim(1) { -> for j in D.dim(1) { -> yield (i,j); -> } -> } -> } -> -> and invoke it: -> -> for (x,y) in CMO([1..2, 1..4]) { -> ... -> } -> -> This looks simple because it's all sequential -- making it parallel would -> be harder, but given that you have some pretty heavy constraints on the -> order of the parallelism, that seems appropriate. Implementing parallel -> wavefront style loops has similar issues -- one technique is to use an -> array of sync variables to control when each iteration can legally fire. -Well, yeah. I was kinda hazy on the iterators section (I think I missed -class that day). But essentially what I did was coforall create every -thread at once, then have my array of single variables to let the iterations -proceed in wavefronts as you described. (I don't need sync vars because -each subproblem should be solved uniquely, and solved exactly once, so -single vars give me some sanity checks on my algorithm, and should give the -compiler some constant optimization opportunities.) When the coforall loop -was broken, I thought of trying to explicitly code this other ordering on -the parallelism via a forall loop. -> -> -> -> > * The syntax isn't well specified in the spec, I think due to its change -> > over time. -> -> Hmm, I don't think it's changed that much since the spec was written. -> Could you clarify for me in what way it seems poorly specified and how it -> could be improved? Are you referring to the syntax "diagrams" or the -> supporting text that describes them? -There are some BNF-style descriptions in the spec, but I'm not sure they -match reality explicitly. (I think the syntax for class declarations and -deriving from base classes is missing a colon separating class D : B, for -instance. Also evidently semicolons are prohibited following class and -function body definitions, but are required after variable definitions in -class bodies. I didn't gather that from the spec; just from the example -programs. I was also confused by the if-then syntax, see below.) It's not -so much that the spec is blatantly poorly specified, but when there are -mismatches between the spec and reality, I don't know which is newer or more -correct. Having an appendix at the end containing the Bison grammar you -actually use in the compiler (dropping the semantic actions or other cruft) -should be an automated way to keep the spec in sync with the code. - -> -> > But it wasn't clear why you had an optional "then" keyword, for -> > instance; pick one syntax (e.g. C's, since you're very close to it -> > already) and stick to it. -> -> For single-statement conditionals, there's a syntactic ambiguity due to -> Chapel's use of square brackets for both function arguments and forall -> loops. For example: -> -> if A [D] write("hi"); -> -> Could be: -> -> if A[D] { -> write("hi"); -> } -> -> or: -> -> if A { -> [D] write("hi"); -> } -> -> So optional keywords like "then" (and its partners in crime) are used to -> support the single statement cases of control flow: -> -> if A[D] then write("hi"); -> -> if A then [D] write("hi"); -> -> Since the single statement could itself be a compound statement, this -> permits: -> -> if A then { [D] write("hi"); write("there"); } -> -> but of course, the then isn't strictly required in this case. The result -> is if you use curly brackets religiously, you'll end up being very C-like. -> If you like to avoid curly brackets in single-statement cases, you need to -> use the keywords. -> -> This rationale should be captured in the spec if it isn't already. -> -> If you have thoughts about getting rid of the then altogether, that would -> of course be of interest. -I see. Well, I personally would just consistently use brackets until I was -more comfortable with the language, but another possibility is one taken by -Perl and I think Ruby, where you can say - if ; -instead of the typical -if then - -The claimed advantage to this is that for one-liner statements like this, -the point is the , and not its guarding , so get the guard out -of the way and read the statement first. - -> > * There's a heavy learning curve, I think, which is aggravated by the -> > lack of examples. A lot of the code I wrote was written via -> > copy-paste-modify, and I wasn't always sure what syntax was critical and -> > what was style and what was optional. -> -> Are you talking about examples in the spec (which I'd completely agree -> with), or examples in the release itself (which I could also agree with, -> but would need some suggestions about what examples you'd like to see -> included, or how the existing examples could be made more instructive -- -> we're happy to add more, but don't want to overwhelm anyone by providing -> more than they can wrap their heads around). -> -Mostly in the spec. I found the example .chpl files very helpful. I didn't -get far enough into the language with this one foray to need anything much -beyond genericStack and beer, with a few others for quick checks. But in -the spec, given that I wasn't sure about syntax in some cases, and semantics -in some others (the loops, mentioned above), it would have helped to see a -few example statements or expressions that showed "ok, here's what a derived -class looks like; here's the options for if statements, etc." diff --git a/test/studies/590o/blerner/FEEDBACK2-blc b/test/studies/590o/blerner/FEEDBACK2-blc deleted file mode 100644 index 202cf54e0ce2..000000000000 --- a/test/studies/590o/blerner/FEEDBACK2-blc +++ /dev/null @@ -1,156 +0,0 @@ -From bradc@cray.com Thu Dec 6 14:16:38 2007 -Date: Thu, 6 Dec 2007 14:16:37 -0800 (PST) -From: Brad Chamberlain -To: Ben Lerner -Subject: Re: Thoughts on using Chapel - - -> Your example of A[i, 1..n] is particularly tricky -- when i is holding a -> range, this has very different semantics between [] and (), even though it -> looks like there's only one range present to slice over. If you went with -> your current suspicion and wrote it with parens today, you'd get, what, a -> diagonal slice of characters through an array of strings? - -Yeah, this is all correct -- in writing that example in email, the -implication was meant to be clear that i was an integer, but you're correct -that in general it could be a range, in which case things become more -important again. - - -> As I understood the semantics of forall, you *might* implement the -> iterations sequentially, or in parallel; I wasn't sure which behavior -> happened when or why. But if you were to implement forall in parallel, -> then surely the same tree-of-spawns would be used for coforall. - -Typically, foralls will be implemented using something between the two -extremes of "1 thread" (for) and "1 thread per iteration" (coforall). For -domains and arrays, for example, I think of foralls as generating an -appropriate amount of parallelism for the locales onto which the object is -distributed, each of which is doing the work it owns sequentially. In -practice, foralls on domains and arrays will be implemented in terms of the -distribution, so a user could implement it using either of the extremes, -something in the middle, or something completely different. - - -> But the larger point remains, if you can "compile away" coforall loops -> into even an inefficient representation using foralls and joins and -> whatever, then you've shrunk the core language. - -Agreed. - - -> > Does anything prevent you in this case from moving the declaration of -> > the array after the sparse domain's initialization? If not, I'd suggest -> > doing that -- declare the dense domain, the sparse domain, initialize -> > the sparse domain, now declare the sparse array. That way, the -> > allocation happens in one fell swoop as you'd like. -> -> I wanted all the declarations to be global, so I wouldn't have to pass -> them around in my code. - -Globals are evaluated/initialized in order in Chapel, and code can exist at -the file level (it becomes initialization code for the module), so this -still ought to be workable (I have to admit that I hadn't had a chance to -connect your comments to your code, and am just starting to do so now). -Imagine: - -var StartIndices: sparse subdomain(AllIndices); - -// compute StartIndices += ...; - -var Arr: [StartIndices] real; - - -But wait, you don't declare any arrays over your sparse domains! :) - - - -> > Or, can the sparse domain be initialized on its declaration line rather -> > than after its declaration (using an iterator, e.g.)? This would be the -> > ideal way to do it since it would allow the sparse domain to be declared -> > const, which should result in other optimization and readability -> > benefits. -> -> Not in my case -- the sparse domain StartIndices, for instance, is the -> location of all "<" characters in the input, and the positions just after -> all ">" characters. That said, they are constant, right after I figure -> that information out. - -This still seems like it should be doable, though. Imagine something like: - -const StartIndices: sparse subomdain(AllIndices) - = genStartIndices(AllIndices, str); - -def genStartIndices(AllIndices, str) { - forall z in AllIndices do { - if str.substring[z] == '<' then { - yield z; - } - else if str.substring[z] == '>' && - z < length(str) && str.substring[z+1] != "<" then - yield z+1; - } - } -} - - -> Here's a wacky thought: would the following work? -> const AllIndices : [1..length(input)] -> var StartIndices : single sparse subdomain(AllIndices) <<== note the -> single! -> var EndIndices : single sparse subdomain(AllIndices) <<== note the -> single! -> var parsedElements : [StartIndices, EndIndices] single XmlElement <<== -> hierarchical domains, not there yet but soon :) -> -> /* expectation: parsedElements has not been allocated yet, since it's -> waiting for StartIndices and EndIndices to be assigned */ -> -> StartIndices = ComputeStartIndices(input); /* still waiting... */ -> EndIndices = ComputeEndIndices(input); -> /* Ok, go! Both sets of indices are available, so parsedElements can be -> allocated. Moreover, unless it's reassigned, the domain of parsedElements -> must be constant. */ - -MMMmmmmaybe. I think we've been vague/uncertain about what single should -mean in the domain context, which is the main thing that makes me nervous -about this. - - - -> There are some BNF-style descriptions in the spec, but I'm not sure they -> match reality explicitly. (I think the syntax for class declarations and -> deriving from base classes is missing a colon separating class D : B, for -> instance. Also evidently semicolons are prohibited following class and -> function body definitions, but are required after variable definitions in -> class bodies. I didn't gather that from the spec; just from the example -> programs. I was also confused by the if-then syntax, see below.) It's -> not so much that the spec is blatantly poorly specified, but when there -> are mismatches between the spec and reality, I don't know which is newer -> or more correct. Having an appendix at the end containing the Bison -> grammar you actually use in the compiler (dropping the semantic actions or -> other cruft) should be an automated way to keep the spec in sync with the -> code. - -OK, thanks for pointing out the cases you found that seemed wrong. These -are bugs in the spec -- the spec's syntax is meant to describe what the -compiler currently has implemented. - - -> Mostly in the spec. I found the example .chpl files very helpful. I -> didn't get far enough into the language with this one foray to need -> anything much beyond genericStack and beer, with a few others for quick -> checks. But in the spec, given that I wasn't sure about syntax in some -> cases, and semantics in some others (the loops, mentioned above), it would -> have helped to see a few example statements or expressions that showed -> "ok, here's what a derived class looks like; here's the options for if -> statements, etc." - -OK, thanks. We agree -- the current pass of the spec is pretty lightweight -on both examples and rationale. We've been better at adding more as we go, -but haven't made a truly concerted effort to take a full pass through with -the intent of adding more of these. - -Thanks again, --Brad - diff --git a/test/studies/590o/blerner/FEEDBACK3 b/test/studies/590o/blerner/FEEDBACK3 deleted file mode 100644 index 7b7cc4001b8c..000000000000 --- a/test/studies/590o/blerner/FEEDBACK3 +++ /dev/null @@ -1,110 +0,0 @@ -From blerner@cs.washington.edu Thu Dec 6 14:39:20 2007 -Date: Thu, 06 Dec 2007 14:39:17 -0800 -From: Ben Lerner -To: Brad Chamberlain -Subject: Re: Thoughts on using Chapel - - -> > > Does anything prevent you in this case from moving the declaration of -> > > the array after the sparse domain's initialization? If not, I'd -> > > suggest doing that -- declare the dense domain, the sparse domain, -> > > initialize the sparse domain, now declare the sparse array. That way, -> > > the allocation happens in one fell swoop as you'd like. -> > -> > I wanted all the declarations to be global, so I wouldn't have to pass -> > them around in my code. -> -> Globals are evaluated/initialized in order in Chapel, and code can exist -> at the file level (it becomes initialization code for the module), so this -> still ought to be workable (I have to admit that I hadn't had a chance to -> connect your comments to your code, and am just starting to do so now). -> Imagine: -> -> var StartIndices: sparse subdomain(AllIndices); -> -> // compute StartIndices += ...; -> -> var Arr: [StartIndices] real; -> -> -> But wait, you don't declare any arrays over your sparse domains! :) -True, I didn't. But that's because I didn't have hierarchical domains. I -wanted to define parsedElements over [StartIndices, EndIndices], didn't have -support for that, so switched to AllIndices, and made it dense. -> > -> > Not in my case -- the sparse domain StartIndices, for instance, is the -> > location of all "<" characters in the input, and the positions just -> > after all ">" characters. That said, they are constant, right after I -> > figure that information out. -> Or, can the sparse domain be initialized on its declaration line rather -> than after its declaration (using an iterator, e.g.)? This would be the -> ideal way to do it since it would allow the sparse domain to be declared -> const, which should result in other optimization and readability benefits. -> -> This still seems like it should be doable, though. Imagine something -> like: -> -> ... -> -I like that. It seemed weird to me, because I'd gotten file-level constants -and config values mixed up in my head. Also, I didn't think you could have -code at the file level outside functions, and still didn't make the -connection between user-defined iterators and sparse subdomains. Some wacky -connections here :) Also, this would be a good example to have in chapter -19, because the current description of sparse subdomains is...sparse. -Having an example saying "Like all domains, sparse subdomains are -particularly effective when they're constant, as the compiler can optimize -them effectively. One convenient idiom is to define - -const D : sparse subdomain(B) = computeIndices(...); -def computeIndices(...) { ... yield ; ... } -> -> > Here's a wacky thought: would the following work? -> > const AllIndices : [1..length(input)] -> > var StartIndices : single sparse subdomain(AllIndices) <<== note the -> > single! -> > var EndIndices : single sparse subdomain(AllIndices) <<== note the -> > single! -> > var parsedElements : [StartIndices, EndIndices] single XmlElement <<== -> > hierarchical domains, not there yet but soon :) -> > -> > /* expectation: parsedElements has not been allocated yet, since it's -> > waiting for StartIndices and EndIndices to be assigned */ -> > -> > StartIndices = ComputeStartIndices(input); /* still waiting... */ -> > EndIndices = ComputeEndIndices(input); -> > /* Ok, go! Both sets of indices are available, so parsedElements can be -> > allocated. Moreover, unless it's reassigned, the domain of -> > parsedElements must be constant. */ -> -> MMMmmmmaybe. I think we've been vague/uncertain about what single should -> mean in the domain context, which is the main thing that makes me nervous -> about this. -> -Hehe. It seems like an idea with potential. Another thing that would be -"nice to express" is when an array's domain is constant, that is, I can't -say "A.domain = newdomain;" Because even if I know D is a constant domain, -and A was defined over [D], I may change it later... - -> > There are some BNF-style descriptions in the spec, but I'm not sure they -> > match reality explicitly. (I think the syntax for class declarations -> > and deriving from base classes is missing a colon separating class D : -> > B, for instance. Also evidently semicolons are prohibited following -> > class and function body definitions, but are required after variable -> > definitions in class bodies. I didn't gather that from the spec; just -> > from the example programs. I was also confused by the if-then syntax, -> > see below.) It's not so much that the spec is blatantly poorly -> > specified, but when there are mismatches between the spec and reality, I -> > don't know which is newer or more correct. Having an appendix at the -> > end containing the Bison grammar you actually use in the compiler -> > (dropping the semantic actions or other cruft) should be an automated -> > way to keep the spec in sync with the code. -> -> OK, thanks for pointing out the cases you found that seemed wrong. These -> are bugs in the spec -- the spec's syntax is meant to describe what the -> compiler currently has implemented. -The other thing I was confused about (though I gave it only a quick scan) -was the user-defined compile errors, and what kinds of expressions are -permitted in defining them. The thing I was must confused about was how -much of a phase-distinction you maintained between compiling code and -running some code during compilation. diff --git a/test/studies/590o/blerner/FEEDBACK3-blc b/test/studies/590o/blerner/FEEDBACK3-blc deleted file mode 100644 index 1c1d1567a2e9..000000000000 --- a/test/studies/590o/blerner/FEEDBACK3-blc +++ /dev/null @@ -1,69 +0,0 @@ -From bradc@cray.com Thu Dec 6 16:56:55 2007 -Date: Thu, 6 Dec 2007 16:56:55 -0800 (PST) -From: Brad Chamberlain -To: Ben Lerner -Subject: Re: Thoughts on using Chapel - - -> > But wait, you don't declare any arrays over your sparse domains! :) -> True, I didn't. But that's because I didn't have hierarchical domains. I -> wanted to define parsedElements over [StartIndices, EndIndices], didn't -> have support for that, so switched to AllIndices, and made it dense. - -That's right, you told me this. I'm having trouble keeping all the details -in my head at once. - - -> I like that. It seemed weird to me, because I'd gotten file-level -> constants and config values mixed up in my head. Also, I didn't think you -> could have code at the file level outside functions, and still didn't make -> the connection between user-defined iterators and sparse subdomains. - -Yeah, the file-level code outside functions is a little funky, but having -decided to try it, we find ourselves liking it a bunch. Formally, that code -is the module's initialization code, run when the module is initialized. -Practically speaking, it tends to do exactly what you want. - -> Some wacky connections here :) Also, this would be a good example to have -> in chapter 19, because the current description of sparse subdomains -> is...sparse. Having an example saying "Like all domains, sparse -> subdomains are particularly effective when they're constant, as the -> compiler can optimize them effectively. One convenient idiom is to define -> -> const D : sparse subdomain(B) = computeIndices(...); -> def computeIndices(...) { ... yield ; ... } - -Fair enough. I think the sparse example is currently better documentation -than the sparse section of the language spec. :) Unfortunately, I think I -wrote both. - - -> Hehe. It seems like an idea with potential. Another thing that would be -> "nice to express" is when an array's domain is constant, that is, I can't -> say "A.domain = newdomain;" Because even if I know D is a constant -> domain, and A was defined over [D], I may change it later... - -We've recently decided that allowing an array's domain to change via -A.domain is a bad idea for reasons similar to this. As a result, we're -moving towards making A.domain being supported to query a const domain -value, rather than a reference to the array's domain. The downside of this -is that if you want to change an array's domain, you'd need to be able to -refer to it by name or pass it along with the array. The upside is that I -think there will be a whole lot less self-foot-shooting going on. (And -there were some subtleties in the implementation that led us in this -direction as well). - - -> The other thing I was confused about (though I gave it only a quick scan) -> was the user-defined compile errors, and what kinds of expressions are -> permitted in defining them. The thing I was must confused about was how -> much of a phase-distinction you maintained between compiling code and -> running some code during compilation. - -OK, we'll try to clarify that. The short answer is that the compilerError() -function generates the error if it is found to be invoked during function -resolution, and it can only refer to param expressions (and possibly -types?). Basically, similar rules as our other compile-time computation -machinery (which we may have discussed before you got back from Europe?). - --Brad diff --git a/util/buildRelease/testRelease b/util/buildRelease/testRelease index f26a341eff2d..a4559ef1898e 100755 --- a/util/buildRelease/testRelease +++ b/util/buildRelease/testRelease @@ -45,7 +45,7 @@ $user = `whoami`; chomp($user); $debugmail = $ENV{'CHPL_NIGHTLY_DEBUG_EMAIL'}; if ($debugmail eq "") { - $debugmail = "$user\@cray.com"; + $debugmail = "$user\@hpe.com"; if ($debug == 1) { $replymail = $debugemail; } diff --git a/util/build_configs/cray-internal/generate-dev-releaseinfo.bash b/util/build_configs/cray-internal/generate-dev-releaseinfo.bash index 4550e1c93d27..54953e015d9d 100755 --- a/util/build_configs/cray-internal/generate-dev-releaseinfo.bash +++ b/util/build_configs/cray-internal/generate-dev-releaseinfo.bash @@ -69,9 +69,9 @@ Chapel $major.$minor Interested users are encouraged to ask questions and join discussions in a variety of forums (Stack Overflow, Gitter, mailing lists, etc.) listed at https://chapel-lang.org/users.html. - Questions about Chapel can be directed to the Chapel team at - chapel_info@cray.com. To file bugs or feature requests against - Chapel, refer to \$CHPL_HOME/doc/html/usingchapel/bugs.html or + Questions about Chapel can be directed to the Chapel team. To file + bugs or feature requests against Chapel, refer to + \$CHPL_HOME/doc/html/usingchapel/bugs.html or https://chapel-lang.org/bugs.html. diff --git a/util/cron/README b/util/cron/README index 6de6a9abc865..2fa92b1bb90d 100644 --- a/util/cron/README +++ b/util/cron/README @@ -33,7 +33,7 @@ Testing changes to these scripts export CHPL_NIGHTLY_LOGDIR=$PWD/chapel-test-logs export CHPL_NIGHTLY_CRON_LOGDIR=$PWD/chapel-test-logs -export CHPL_NIGHTLY_CRON_RECIPIENT=$USER@cray.com +export CHPL_NIGHTLY_CRON_RECIPIENT=$USER@hpe.com export CHPL_NIGHTLY_TEST_CONFIG_NAME=$USER.test # Run the script, if appropriate diff --git a/util/cron/lookForTabs.cron b/util/cron/lookForTabs.cron index 2d99fe441ee3..55e4ec3dd525 100755 --- a/util/cron/lookForTabs.cron +++ b/util/cron/lookForTabs.cron @@ -5,7 +5,7 @@ use File::Basename; $user = `whoami`; chomp($user); -$mailcommand = "| mail -s \"Cron Nightly TAB check\" $user\@cray.com"; +$mailcommand = "| mail -s \"Cron Nightly TAB check\" $user\@hpe.com"; $cwd = abs_path(dirname(__FILE__)); $chplhomedir = abs_path("$cwd/../.."); diff --git a/util/cron/nightly b/util/cron/nightly index 15a3d58751d2..1c71e78381ee 100755 --- a/util/cron/nightly +++ b/util/cron/nightly @@ -248,7 +248,7 @@ $user = `whoami`; chomp($user); $debugmail = $ENV{'CHPL_NIGHTLY_DEBUG_EMAIL'}; if ($debugmail eq "") { - $debugmail = "$user\@cray.com"; + $debugmail = "$user\@hpe.com"; if ($debug == 1) { $replymail = $debugemail; } diff --git a/util/cron/start_opt_test b/util/cron/start_opt_test index c391eb754311..594b2bb3df3f 100755 --- a/util/cron/start_opt_test +++ b/util/cron/start_opt_test @@ -75,7 +75,7 @@ foreach $line (@lines) { if ($cron && (!exists($ENV{"CHPL_TEST_NOMAIL"}) or grep {$ENV{"CHPL_TEST_NOMAIL"} =~ /^$_$/i} ('','\s*','0','f(alse)?','no?'))) { $nerror = $nerrort2/2; if ($nerror == 0) { - open(FILE, "| mail -s \"Cron $nerror/$nerror (chap02:opts tests)\" $allmail $ENV{'USER'}\@cray.com"); + open(FILE, "| mail -s \"Cron $nerror/$nerror (chap02:opts tests)\" $allmail $ENV{'USER'}\@hpe.com"); } else { open(FILE, "| mail -s \"Cron $nerror/$nerror (chap02:opts tests)\" $failuremail $allmail"); } diff --git a/util/tokencount/tokctnightly b/util/tokencount/tokctnightly index 853d5b6cae42..647051f803af 100755 --- a/util/tokencount/tokctnightly +++ b/util/tokencount/tokctnightly @@ -47,7 +47,7 @@ $user = `whoami`; chomp($user); $debugmail = $ENV{'CHPL_NIGHTLY_DEBUG_EMAIL'}; if ($debugmail eq "") { - $debugmail = "$user\@cray.com"; + $debugmail = "$user\@hpe.com"; if ($debug == 1) { $replymail = $debugemail; }