Dear Yoav,
Thank you for your reply, so did this really actually work right in the
2.0,4 version? because I recall that my results were right .
Another thing is that I was trying your piece of code and it still gives
compilation errors, but you said that it was just a pseudo code.
How can I write this in X10 2.0.5? and I want the "val matrixTasks" which
is the DistArray to be a global member defined as a class member, and
later on in the constructor, I initialize its size and value (which is the
subTask constructor).
I suppose this happens in the 2.0.5, because assertions were added at
compile time, that were not really sensitive in 2.0.4. Is this true?
Thank you all.
On Sun, Jul 25, 2010 at 12:27 PM, Yoav Zibin <yoav.zi...@gmail.com> wrote:
> "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
>
--
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
