Yes. I will create a pull request with these changes.
Thank you
Sriraj
> On Jan 4, 2017, at 10:57 PM, Michael Ferguson <[email protected]> wrote:
>
> Hi -
>
> On 1/4/17, 11:57 AM, "Greg Titus" <[email protected] <mailto:[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
