Hi John -- > What would be the preferred way to define the aforementioned policy > object? I was thinking of creating a base class and having the user > derive policies from it. However, did I miss something, or can't methods > be defined abstract? Also there is nothing similar to Java's interfaces > in chapel, right?
You're correct that Chapel doesn't currently have any support for interfaces -- this has been an area of investigation by academic partners for some time now (actually, more than just interfaces: support for constrained generic interfaces a la the failed C++11 concepts feature), but it hasn't resulted in the feature being available on master yet. We're currently trying to figure out how to resource this effort to get it done. In the meantime, I usually just specify an interface informally (i.e., in documentation, not code), and rely on it to be there in my use cases. I should also mention that occasionally we run into bugs in our dynamic dispatch implementatino that have not yet been diagnosed/fixed. So rather than using a class hierarchy to express an interface like this, I often just use generic instantiation against class objects with no shared parent. > Another question is, what is the current status of support for sparse > domains? Ie. should I require each locale to have a continuous, > rectangular block of data or not? Sparse domains currently are only supported for a single locale, and have not received much attention from a performance tuning point of view. I'd suggest, at least as a starting point if it's sufficient for your personal needs, focusing on the dense rectangular block as a starting point. I've made some attempts to get a block implementation working in which each local block is a sparse array, but never got it working well enough to merge it. I can try and dig up that code to share with you if it becomes useful in a subsequent step. -Brad ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users
