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.
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
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.
Regarding issue-57, one solution is to modify the
drmaa2.h header as follows
Replace:
typedef enum drmaa2_limit {
DRMAA2_CORE_FILE_SIZE = 0,
. . .
DRMAA2_WALLCLOCK_TIME = 7
} drmaa2_limit;
With:
extern const char *const DRMAA2_CORE_FILE_SIZE;
. . .
extern const char *const DRMAA2_WALLCLOCK_TIME;
And stipulate that the implementation library must contain:
const char *const DRMAA2_CORE_FILE_SIZE = "CORE_FILE_SIZE";
. . .
const char *const DRMAA2_WALLCLOCK_TIME = "WALLCLOCK_TIME";
How does the above solution compare to updating drmaa2.h with Macros:
#define DRMAA2_CORE_FILE_SIZE "CORE_FILE_SIZE"
. . .
#define DRMAA2_WALLCLOCK_TIME "WALLCLOCK_TIME"
(1) The value of variables can be analyzed in a runtime debugger (to
check that the variable name is consistent with its value?)
(2) Using variables may reduce the number of copies
of strings in the process (the client and the drmaa
implementation library may share). This involves
marginal expense for additional symbol resolution.
(3) Using variables is likely to be more natural to
C++ programmers using the C-lang binding.
What are the ~other~ tradeoffs between
extern const char *const DRMAA2_CORE_FILE_SIZE;
and
#define DRMAA2_CORE_FILE_SIZE "CORE_FILE_SIZE"
-Roger
-------- Original Message --------
Subject: [DRMAA-WG] DRMAA C Binding Issue
From: Peter Tröger
Thanks Peter for posting! +1 for Rogers solution with "extern const". Regards, Daniel Am 28.01.2013 um 20:05 schrieb Roger Brobst:
Regarding issue-57, one solution is to modify the drmaa2.h header as follows Replace: typedef enum drmaa2_limit { DRMAA2_CORE_FILE_SIZE = 0, . . . DRMAA2_WALLCLOCK_TIME = 7 } drmaa2_limit;
With: extern const char *const DRMAA2_CORE_FILE_SIZE; . . . extern const char *const DRMAA2_WALLCLOCK_TIME;
And stipulate that the implementation library must contain: const char *const DRMAA2_CORE_FILE_SIZE = "CORE_FILE_SIZE"; . . . const char *const DRMAA2_WALLCLOCK_TIME = "WALLCLOCK_TIME";
How does the above solution compare to updating drmaa2.h with Macros: #define DRMAA2_CORE_FILE_SIZE "CORE_FILE_SIZE" . . . #define DRMAA2_WALLCLOCK_TIME "WALLCLOCK_TIME"
(1) The value of variables can be analyzed in a runtime debugger (to check that the variable name is consistent with its value?)
(2) Using variables may reduce the number of copies of strings in the process (the client and the drmaa implementation library may share). This involves marginal expense for additional symbol resolution.
(3) Using variables is likely to be more natural to C++ programmers using the C-lang binding.
What are the ~other~ tradeoffs between extern const char *const DRMAA2_CORE_FILE_SIZE; and #define DRMAA2_CORE_FILE_SIZE "CORE_FILE_SIZE"
-Roger
-------- Original Message -------- Subject: [DRMAA-WG] DRMAA C Binding Issue From: Peter Tröger
To: drmaa-wg@ogf.org 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 drmaa-wg@ogf.org https://www.ogf.org/mailman/listinfo/drmaa-wg
participants (3)
-
Daniel Gruber
-
Peter Tröger
-
Roger Brobst