I actually started with this approach. Then backed out of it because (i)
I wasn’t familiar enough with the module code to figure out exactly
which parts of the code would have to change/not change (e.g., stridable
case in getDataIndex) and
If you were interested in continuing with this approach, I (and others, I
suspect) would be happy to help you navigate any challenges. My thinking
is that if we had a global (potentially developer-oriented) 'config' that
said whether the default should be RMO or CMO, we could run the entire
Chapel test suite in CMO mode as an acid test that all necessary changes
had been made (along with adding a few point tests that would check that
the layout for CMO and RMO were correct in terms of memory ordering).
(ii) I saw this ominous looking comment at the
top of the initialize routine in DefaultRectangular : "// change name to
setup and call after constructor call sites; we want to get rid of all
initialize functions everywhere”.
I wouldn't let this comment scare you off. 'proc initialize()' is a
feature that we've never been particularly proud of (and I think haven't
even documented as a result?), so this comment is just an indicator that
it's something we hope will go away over time (though the logic in it
wouldn't -- it would just move elsewhere). For context `proc
initialize()` is a procedure that, if defined, the compiler will call
after it invokes an object's constructor. Unfortunately, as we're
switching over from constructors to initializers in the language
definition ('proc init()') the name has become even more unfortunate due
to the similarity.
(As an aside for those really curious about this feature and perhaps
wondering "Why not just put such code into the constructor itself or into
a helper routine that's called by the constructor?" the answer is that in
cases where the compiler-provided constructor was exactly what a user
would want, it was easier to be able to define a post-constructor hook in
this way rather than manually writing out the equivalent of the
compiler-provided constructor and then adding more code to it. I'll note
that even in the new improved initializer world, I still think this
motivation is attractive and am not aware that we've come up with a
productive replacement for initialize() yet. Though there are still open
design questions about opting into the default compiler-provided
initializer which _might_ give us a similar capability... though I'm not
particularly optimistic).
-Brad
So I went with the approach of directly changing the ranges() in the domain and
just modifying the dsiAccess() functions.
- Apan
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
