"here" is a complicated notion, and it is place-sensitive.
val p1 = here;
at (anotherPlace) {
  val p2 = here;
  // p1 and p2 are different!
}

Your code created a subTask at different places, so the home of each element
was different.
You actually wanted to express this type:
"a distributed array whose elements are subTask, and at position array(0)
there is a subTask whose home is the same as the home of array(0)"
*This type is not expressible in X10 type system.*
I would write it in pseudo-X10 like this:
val distArray:DistArray[subTask{ foreach(P in distArray.dist)
distArray(p).home == self.home} ] =
  DistArray.make(dist, (point:Point)=> at (dist(point)) new subTask(...) );

(Note that you have to initialize the array with a closure, and not with an
ateach, because if you access an array element before the ateach, then it
has a null value, which violate the constraint.
This will be another compilation error in the next release of X10 which
related to default values. We're working on that now :)


In fact, I think PlaceLocalHandler will be a good fit for what you want.


thanks,
Yoav





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



On Sun, Jul 25, 2010 at 7:00 AM, mohammed elsaeedy <
mohammed.elsae...@kaust.edu.sa> wrote:

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