Dear Igor,

     For example the 2.0.5 compiler complains about this piece of code that
version 2.0.4 didn't really complain about:

private global val matrixTasks
:DistArray[subTask{self.home==here,self!=null}];  // At first I didn't put
the "{self.home==here,self!=null}" part but the compiler was complaining

    def this(Matrix:Rail[double],vector:Rail[double],DimSize:int)
    {
        ...................
        ...................
        ...................// Some code
        ...................
//        Matrix creation
        val D1:Dist=Dist.makeUnique();
        matrixTasks
=DistArray.make[subTask{self.home==here,self!=null}](D1);

        finish ateach((i):Point in matrixTasks.dist())
        {
            matrixTasks(i) =new subTask(taskDim);      // here is the
problem LINE 38
        }
    }

ERROR:

<myPath>/myMVmult/MVmult.x10:38: Cannot assign expression to array element
of given type.
          Expression: new subTask(...)
          Type: subTask{self.home==here, self!=null}
          Array element: MVmult.this.matrixTasks(i)
          Type: subTask

Another question, is the rail "copyTo" and "copyFrom" still available?

Thanks alot
Regards,
Mohammed El Sayed


On Sat, Jul 24, 2010 at 8:24 AM, Dave Hudak <dhu...@osc.edu> wrote:

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



-- 
Thank you for your concern.
Regards,
Mohammed El Sayed
------------------------------------------------------------------------------
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

Reply via email to