It worked! Thanks, Beth! Dave On Jul 23, 2010, at 5:23 PM, Beth Tibbitts wrote:
> Sorry, it was still uploading/propagating. > Try now! > > > ...Beth > > Beth Tibbitts > Eclipse Parallel Tools Platform http://eclipse.org/ptp > IBM STG Communications Protocols and Tools > Mailing Address: IBM Corp., Coldstream Research Campus, 745 West New > Circle Road, Lexington, KY 40511 > > Dave Hudak <dhu...@osc.edu> wrote on 07/23/2010 04:49:53 PM: > >> From: >> >> Dave Hudak <dhu...@osc.edu> >> >> To: >> >> Mailing list for users of the X10 programming language > <x10-users@lists.sourceforge.net> >> >> Date: >> >> 07/23/2010 04:51 PM >> >> Subject: >> >> Re: [X10-users] X10 and X10DT 2.0.5 Released >> >> I just tried to update. The X10DT is still at 2.0.4 in Eclipse. >> >> Dave >> On Jul 23, 2010, at 3:46 PM, Igor Peshansky wrote: >> >>> We're happy to announce that X10 and X10DT version 2.0.5 are now > available >>> for download. This release contains a number of bug fixes and > improvements >>> to the code base. For more details, please see the X10 2.0.5 release > page >>> at http://x10-lang.org/X10+2.0.5+Release. >>> >>> The 2.0.5 Release notes are appended. >>> >>> Release 2.0.5 >>> >>> This release includes both the C++ and Java code generation backends. >>> >>> We are planning to remove x10.lang.Rail in favor of x10.array.Array >>> in either the 2.1.0 or 2.1.1 release of X10. In the 2.0.5 release, >>> we believe the x10.array.Array API and performance have reached >>> acceptable levels to let users begin to migrate away from Rail >>> usage in preparation. There are a few noticeable differences between >>> the Rails and Arrays that are worth highlighting. >>> - Rail.length becomes Array.size() >>> - Array[T] implements Iterable[Point], not Iterable[T]. >>> This impacts enhanced forloops over Rails. >>> - Although bounds checking performance for Array has significantly >>> improved since 2.0.4, it is inherently slower than bounds checking >>> on Rails because we want to allow Arrays to be defined over >>> user-defined >>> Regions. Therefore we must incur one virtual function call when >>> performing a bounds check on Array. NO_CHECKS performance of Rails >>> and Arrays is believed to be equivalent. >>> >>> No significant language changes were made since the 2.0.4 release. >>> For details on any minor language changes, please consult the >>> language specification included in the X10 release. >>> >>> The following features described in the 2.0 language manual do not >>> currently work and will be fixed in the subsequent releases: >>> >>> - Non-static type definitions as class or interface members >>> (static type defs do work) >>> - Type definitions as package members (i.e., in the outermost scope of >>> a compilation unit) >>> - Shared local variables >>> - Extern methods >>> >>> Additionally, the following features described in the language >>> manual do not currently work with the C++ backend and will be fixed in >>> the subsequent releases: >>> >>> - Garbage collection on AIX and BlueGene >>> - Generic virtual methods >>> - Exception stack traces on Cygwin and AIX >>> >>> The generated C++ code requires g++ 4.2 or better to be compiled; >>> we do almost all of our testing against g++ 4.3.2. On AIX, you >>> may either use g++ 4.2 or better or xlC 10.01.0000.0005 or better. >>> >>> Below is a summary of JIRA issues addressed for the X10 2.0.5 release. >>> >>> ** Improvements and New Features >>> * [XTENLANG-59] - language support for guaranteed inlining >>> * [XTENLANG-424] - Improve dependency processing for files in >>> libx10.mft in C++ backend >>> * [XTENLANG-618] - Use != null constraints to remove null-checks in >>> codegen >>> * [XTENLANG-650] - Need to structure language manual such that all >>> code snippets can be extracted and compiled as part of a "sanity build" > of >>> the manual >>> * [XTENLANG-889] - autodefinition of equals(S) for struct type S if >>> not provided by the user >>> * [XTENLANG-896] - Phased Clocks >>> * [XTENLANG-1007] - CUDA: support using the standard technique for >>> kernel param passing >>> * [XTENLANG-1142] - implement basic Array.copyTo Array.copyFrom >>> operations >>> * [XTENLANG-1284] - Add new validation steps for Platform >>> Configuration >>> * [XTENLANG-1308] - Fully specify signature of main method >>> * [XTENLANG-1322] - Correct the description of @Native and friends > in >>> the 2.0.3 language manual >>> * [XTENLANG-1406] - Remove templates from the java backend >>> * [XTENLANG-1425] - Inline Rail/ValRail.make[T](int length, (Int) => > >>> T) when it is passed a closure literal as a initializer in Java backend >>> * [XTENLANG-1444] - improving x10.dist/build.xml to support spaces > in >>> directory names >>> * [XTENLANG-1453] - Need to migrate X10DT builder to use ecj instead > >>> of downstream JDT builder >>> * [XTENLANG-1485] - Enhance parameter substitution mechanism of >>> @Native to support command line option of x10c compiler >>> * [XTENLANG-1486] - Support NO_CHECKS flag in Array/DistArray >>> * [XTENLANG-1496] - Privatize value field of Rail and ValRail >>> * [XTENLANG-1497] - Privatize an element of ValRail[Rail[T]] >>> * [XTENLANG-1502] - Handle mix of native files with X10 files for C+ > + >>> back-end >>> * [XTENLANG-1531] - should not see Eclipse compiler warnings on >>> generated Java code in X10 perspective >>> * [XTENLANG-1535] - more informative error message when displaying >>> number of dynamic checks >>> * [XTENLANG-1552] - Implement exception stack traces for MacOS >>> >>> ** Bugs >>> * [XTENLANG-60] - Dist can't implement both (Point)=>Place and >>> (Place)=>Region due to compiler restriction >>> * [XTENLANG-280] - General sequential performance of Array library >>> * [XTENLANG-293] - Performance of rail access >>> * [XTENLANG-498] - Calls to exception-throwing methods from within >>> closures causes downstream Java compiler to flag an unhandled exception >>> * [XTENLANG-509] - Control characters in AIX stack traces >>> * [XTENLANG-649] - Using a function with a type constraint on a >>> generic parameter breaks code elsewhere ...?! >>> * [XTENLANG-678] - Existential Despair >>> * [XTENLANG-715] - What is section 9.2 doing? >>> * [XTENLANG-778] - Default values for structs and functions? >>> * [XTENLANG-873] - Regions can be made with negative rank >>> * [XTENLANG-911] - Need support for an "X10 runtime container" to >>> handle version skew on X10 runtime updates >>> * [XTENLANG-976] - Update DistAlgebra3.x10 test case to reflect that > >>> union on non-disjoint distributions is allowed if mappings are > compatible >>> * [XTENLANG-1054] - Dist.toString() has backwards arrow (should > print >>> place/region mapping in the same way it appars in X10 source code). >>> * [XTENLANG-1103] - Dist.makeBlock(1..13) does the wrong thing. >>> * [XTENLANG-1125] - Test case Calls/StructCall3_MustFailCompile > seems >>> obsolete. >>> * [XTENLANG-1131] - X10 grammar contains qualifiers that are not in >>> the language spec >>> * [XTENLANG-1133] - Internal compiler error >>> * [XTENLANG-1139] - Annotation spec description is bad >>> * [XTENLANG-1250] - NQueensPar.x10 (samples) doesn't compile due to >>> apparent typechecker problem >>> * [XTENLANG-1265] - Duplicate compilation error message >>> * [XTENLANG-1314] - Code fragment with dependent type causes illegal > >>> C++ to be generated >>> * [XTENLANG-1370] - X10DT hangs >>> * [XTENLANG-1382] - Compilation spuriously succeeds with >>> -commandlineonly when dependent files have semantic errors >>> * [XTENLANG-1396] - Generate accessor function for statics with > global >>> constant initializers in the header to enable inlining >>> * [XTENLANG-1403] - WrappedRuntimeException shouldn't be > user-visible >>> * [XTENLANG-1408] - -EXTERNALIZE_ASTS doesn't work >>> * [XTENLANG-1416] - Code not generated for files unrelated to files >>> with syntactic/semantic errors >>> * [XTENLANG-1419] - Numeric promotion of unsigned types not defined >>> * [XTENLANG-1424] - Position of X10ParsedClassType_c and >>> ConstrainedType_c are not the same as the X10CanonicalTypeNode_c >>> * [XTENLANG-1426] - Launching X10 Hello world causes NPE (internal >>> error) >>> * [XTENLANG-1430] - Compiler throws NPE >>> * [XTENLANG-1434] - 'continue lbl' can't be used in a loop. >>> * [XTENLANG-1436] - masterBuildRelease and > masterBuildToolIntegration >>> scripts don't work on cygwin >>> * [XTENLANG-1441] - NPE from type-checker compiling code that uses >>> generics >>> * [XTENLANG-1442] - Non-compilable Java code results from references > >>> to members of a bounded type parameter >>> * [XTENLANG-1452] - Memory leak in HashMap.remove >>> * [XTENLANG-1458] - Wrong signature of main method >>> * [XTENLANG-1459] - Incomprehensible error message for (possibly) >>> illegal return value >>> * [XTENLANG-1462] - Searching for a property even in a static method >>> * [XTENLANG-1466] - lub (least upper bound or least common ancestor) > >>> for null and non-null type fails >>> * [XTENLANG-1473] - Illegal positions when using super. >>> * [XTENLANG-1476] - X10Parser bugs >>> * [XTENLANG-1491] - Node positions missing file path when source >>> located in .jar files >>> * [XTENLANG-1505] - null==null fails in the java backend >>> * [XTENLANG-1506] - String compareTo issues >>> * [XTENLANG-1513] - X10TypeMixin.isNonNull not working as expected >>> blocking backend optimization of null checks >>> * [XTENLANG-1514] - Compiler reports on "dynamically checked calls" >>> but it does not fail with -STATIC_CALLS >>> * [XTENLANG-1515] - someStruct.toString() in the C++ backend fails > to >>> post compile >>> * [XTENLANG-1517] - Java error when x10c tries to make a java array > of >>> generic type >>> * [XTENLANG-1521] - C++ backend: bug in struct's equal (==) for >>> structs when boxed to interface >>> * [XTENLANG-1522] - C++ backend removes assertion - there is no way > to >>> run with assertions on >>> * [XTENLANG-1524] - HashMap.entries() returns a set where some > entries >>> are null >>> * [XTENLANG-1526] - README.txt out of date >>> * [XTENLANG-1533] - X10DT: any pending compilation error prevents > all >>> code generation for a package. >>> * [XTENLANG-1539] - compiler NPE at >>> polyglot.ast.LocalDecl_c.addDecls(LocalDecl_c.java:156) >>> * [XTENLANG-1542] - Use @NativeRep to allow X10 program to catch >>> UnsupportedException >>> * [XTENLANG-1543] - StackOverflow error when uncommenting a piece of > >>> code >>> * [XTENLANG-1545] - compiler emits same error message twice for one >>> problem >>> >>> For the details of JIRA issues fixed in this release, see >>> http://jira.codehaus.org/browse/XTENLANG/fixforversion/15896 >>> >>> Please use the X10 JIRA to report bugs, after ensuring the problem is >>> not already reported: >>> > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&pid=11812&resolution=-1 > >>> >>> > ------------------------------------------------------------------------------ > >>> This SF.net email is sponsored by Sprint >>> What will you do first with EVO, the first 4G phone? >>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >>> _______________________________________________ >>> X10-users mailing list >>> X10-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/x10-users >> >> --- >> David E. Hudak, Ph.D. dhu...@osc.edu >> Program Director, HPC Engineering >> Ohio Supercomputer Center >> http://www.osc.edu >> >> >> >> >> >> >> >> >> >> >> > ------------------------------------------------------------------------------ > >> This SF.net email is sponsored by Sprint >> What will you do first with EVO, the first 4G phone? >> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >> _______________________________________________ >> X10-users mailing list >> X10-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/x10-users > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > X10-users mailing list > X10-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/x10-users --- David E. Hudak, Ph.D. dhu...@osc.edu Program Director, HPC Engineering Ohio Supercomputer Center http://www.osc.edu ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ X10-users mailing list X10-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/x10-users
