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