[DRMAA-WG] DRMAA C Binding Issue

[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.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4343 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/drmaa-wg/attachments/20130128/f34c42ee/attachment.bin>

[Roger Brobst]

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 <peter at troeger.eu>
To: drmaa-wg at ogf.org <drmaa-wg at ogf.org>
Date: 01/28/2013 05:14 AM

Post by 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.
https://redmine.ogf.org/issues/57
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.

[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 <peter at troeger.eu>
To: drmaa-wg at ogf.org <drmaa-wg at 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.

[Daniel Gruber]

Thanks Peter for posting!

+1 for Rogers solution with "extern const".

Regards,

Daniel

Post by Roger Brobst
Regarding issue-57, one solution is to modify the
drmaa2.h header as follows
typedef enum drmaa2_limit {
DRMAA2_CORE_FILE_SIZE = 0,
. . .
DRMAA2_WALLCLOCK_TIME = 7
} drmaa2_limit;
extern const char *const DRMAA2_CORE_FILE_SIZE;
. . .
extern const char *const DRMAA2_WALLCLOCK_TIME;
const char *const DRMAA2_CORE_FILE_SIZE = "CORE_FILE_SIZE";
. . .
const char *const DRMAA2_WALLCLOCK_TIME = "WALLCLOCK_TIME";
#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 <peter at troeger.eu>
To: drmaa-wg at ogf.org <drmaa-wg at 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.
https://redmine.ogf.org/issues/57
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 at ogf.org
https://www.ogf.org/mailman/listinfo/drmaa-wg