Regarding issue-57, I agree that replacing the drmaa2_limit enum with a
separate string for each value is a good solution to the dictionary key
problem.
I have a slight preference for this over introducing an auxiliary
function which accepts the enum value and outputs a suitable string.
Pro's: implementation simplicity, extensibility.
Con's: removal of self-documenting enum, additional linktime resolution.
Does spec need to clarify that the string value is the key, not the
string address (don't rely on pointer comparisons).
I believe the header should include extern variable declarations not
definitions (each defn should only exist in one object file).
extern const char * DRMAA2_CPU_TIME;
-Roger
-------- Original Message --------
Subject: [DRMAA-WG] DRMAA C Binding Issue
From: Peter Tröger <[email protected]>
To: [email protected] <[email protected]>
Date: 01/28/2013 05:14 AM
Dear DRMAA friends,
first, a late happy 2013 for all of you. I hope that you make good progress in your DRMAAv2 implementation projects.
Daniel Gruber raised a critical issue for the published C binding spec:
https://redmine.ogf.org/issues/57
My proposal would be to follow Daniel's suggestion and fix the reference
implementation header file:
https://github.com/troeger/drmaav2-mock/blob/master/drmaa2.h
We point the people to this code base anyway, so it is the easiest solution for
making sure everybody uses the same work-around.
The issue tracker archives the modification until we have enough complete
implementations for an errata document.
Any opinions ?
Best regards,
Peter.
P.S.: https://redmine.ogf.org/issues/59 might be also worthwhile a look.
--
drmaa-wg mailing list
[email protected]
https://www.ogf.org/mailman/listinfo/drmaa-wg
