Hi - On 1/4/17, 11:57 AM, "Greg Titus" <[email protected]> wrote:
>Actually, given Sriraj’s latest response I’ve come around to the other >point of view. > >Let’s separate the issues of the internal and the external task ID >representation. Even if the internal representation is a plain 64-bit >int defined independently from the implementations, defining a >chpl_task_sameIDs() to compare task IDs is a good idea so that the rest >of the code isn’t dependent on that internal type. That’s just good >interface engineering practice. > >Then, no matter what the internal representation is, only the >implementations can provide a reasonable chpl_task_idToString() >conversion function to produce the external representation, because only >the implementations can decode or unpack encoded internal IDs. For >example, if the encoded form has 16 high-order bits of node ID and 48 >low-order bits of task ID within node, if some ID has node==1 and >task_within_node==2 clearly it’s better to print “1:2” rather than the >raw value “281474976710658" or “0x100000002” an implementation >independent convertor would produce. > >Given that we need chpl_task_sameIDs() and chpl_task_idToString() anyway, >I believe we should continue to have the implementations define the task >ID type, so they can use whatever is convenient for them, and then >require them to provide those two functions (and adjust to using those in >qio and chplvis and elsewhere as needed). This approach sounds fine to me too. I'd probably call the methods 'chpl_task_idToString' and 'chpl_task_idEquals' but chpl_task_sameIDs is OK if Greg really wants it to be that way :) Sriraj, can we rely on you to create a pull request making these changes? (at least if nobody else chimes in...) -michael ------------------------------------------------------------------------------ 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
