Re: [drmaa-wg] DRMAA for Torque
Meanwhile I'm surprised by something: in the ST_SUPPORTED_ATTR test the program checks the drmaa_get_next_attr_name() return code, comparing it with DRMAA_ERRNO_SUCCESS and then with DRMAA_ERRNO_INVALID_ATTRIBUTE_VALUE. If the return code is neither of these values, the test fails. I understood that the drmaa_get_next_attr_name() function was supposed to return DRMAA_ERRNO_NO_MORE_ELEMENTS when the end of the list is reached. That's what my lib does, and the therefore the test fails.
Where am I wrong ?
Nowhere. I will fix this immediately. The more interesting question is while earlier tests with other implementations didn't brought that up (Dan, Andreas ?). Thanks ! Peter.
Thanks for the help.
Matthieu Cargnelli
Am 04.02.2006 um 21:26 schrieb Peter Troeger:
Meanwhile I'm surprised by something: in the ST_SUPPORTED_ATTR test the program checks the drmaa_get_next_attr_name() return code, comparing it with DRMAA_ERRNO_SUCCESS and then with DRMAA_ERRNO_INVALID_ATTRIBUTE_VALUE. If the return code is neither of these values, the test fails. I understood that the drmaa_get_next_attr_name() function was supposed to return DRMAA_ERRNO_NO_MORE_ELEMENTS when the end of the list is reached. That's what my lib does, and the therefore the test fails.
Where am I wrong ?
Nowhere. I will fix this immediately. The more interesting question is while earlier tests with other implementations didn't brought that up (Dan, Andreas ?).
Ok, I found it. The C-binding spec 1.0 introduced DRMAA_ERRNO_NO_MORE_ELEMENTS as new error code (see also tracker issue #1173). SGE, Condor and the current test suite where mainly implemented according to C-binding v0.95, so this is a historical bug. Peter.
Thanks !
Peter.
Thanks for the help.
Matthieu Cargnelli
Thanks for pointing that out. I'll file an issue against SGE, and add the missing error code. Daniel Peter Troeger wrote On 02/04/06 21:46,:
Am 04.02.2006 um 21:26 schrieb Peter Troeger:
Meanwhile I'm surprised by something: in the ST_SUPPORTED_ATTR test the program checks the drmaa_get_next_attr_name() return code, comparing it with DRMAA_ERRNO_SUCCESS and then with DRMAA_ERRNO_INVALID_ATTRIBUTE_VALUE. If the return code is neither of these values, the test fails. I understood that the drmaa_get_next_attr_name() function was supposed to return DRMAA_ERRNO_NO_MORE_ELEMENTS when the end of the list is reached. That's what my lib does, and the therefore the test fails.
Where am I wrong ?
Nowhere. I will fix this immediately. The more interesting question is while earlier tests with other implementations didn't brought that up (Dan, Andreas ?).
Ok, I found it. The C-binding spec 1.0 introduced DRMAA_ERRNO_NO_MORE_ELEMENTS as new error code (see also tracker issue #1173). SGE, Condor and the current test suite where mainly implemented according to C-binding v0.95, so this is a historical bug.
Peter.
Thanks !
Peter.
Thanks for the help.
Matthieu Cargnelli
-- *************************************************** * Daniel Templeton UMPK18 x83749 * * Staff Engineer, Sun N1 Grid Engine * *************************************************** * An "intellectual" is a man who takes more * * words than he needs to say more than he knows. * * -Dwight D. Eisenhower * ***************************************************
Uh... Peter, I don't see that error code in the 1.0 C binding. I remember talking about it, but I don't remember actually doing anything about it. Is 1.0 not the final C binding spec? Daniel Daniel Templeton wrote On 02/06/06 15:29,:
Thanks for pointing that out. I'll file an issue against SGE, and add the missing error code.
Daniel
Peter Troeger wrote On 02/04/06 21:46,:
Am 04.02.2006 um 21:26 schrieb Peter Troeger:
Meanwhile I'm surprised by something: in the ST_SUPPORTED_ATTR test the program checks the drmaa_get_next_attr_name() return code, comparing it with DRMAA_ERRNO_SUCCESS and then with DRMAA_ERRNO_INVALID_ATTRIBUTE_VALUE. If the return code is neither of these values, the test fails. I understood that the drmaa_get_next_attr_name() function was supposed to return DRMAA_ERRNO_NO_MORE_ELEMENTS when the end of the list is reached. That's what my lib does, and the therefore the test fails.
Where am I wrong ?
Nowhere. I will fix this immediately. The more interesting question is while earlier tests with other implementations didn't brought that up (Dan, Andreas ?).
Ok, I found it. The C-binding spec 1.0 introduced DRMAA_ERRNO_NO_MORE_ELEMENTS as new error code (see also tracker issue #1173). SGE, Condor and the current test suite where mainly implemented according to C-binding v0.95, so this is a historical bug.
Peter.
Thanks !
Peter.
Thanks for the help.
Matthieu Cargnelli
-- *************************************************** * Daniel Templeton UMPK18 x83749 * * Staff Engineer, Sun N1 Grid Engine * *************************************************** * An "intellectual" is a man who takes more * * words than he needs to say more than he knows. * * -Dwight D. Eisenhower * ***************************************************
The 'official' DRMAA C-binding v1.0 is linked from drmaa.org. The link points to the GGF13 GridForge folder with the according document. It specifies DRMAA_ERRNO_NO_MORE_ELEMENTS as return code for drmaa_get_next_attr_name, drmaa_get_next_attr_value and drmaa_get_next_job_id. Regards, Peter. Am 06.02.2006 um 19:24 schrieb Daniel Templeton:
Uh... Peter, I don't see that error code in the 1.0 C binding. I remember talking about it, but I don't remember actually doing anything about it. Is 1.0 not the final C binding spec?
Daniel
Daniel Templeton wrote On 02/06/06 15:29,:
Thanks for pointing that out. I'll file an issue against SGE, and add the missing error code.
Daniel
Peter Troeger wrote On 02/04/06 21:46,:
Am 04.02.2006 um 21:26 schrieb Peter Troeger:
Meanwhile I'm surprised by something: in the ST_SUPPORTED_ATTR test the program checks the drmaa_get_next_attr_name() return code, comparing it with DRMAA_ERRNO_SUCCESS and then with DRMAA_ERRNO_INVALID_ATTRIBUTE_VALUE. If the return code is neither of these values, the test fails. I understood that the drmaa_get_next_attr_name() function was supposed to return DRMAA_ERRNO_NO_MORE_ELEMENTS when the end of the list is reached. That's what my lib does, and the therefore the test fails.
Where am I wrong ?
Nowhere. I will fix this immediately. The more interesting question is while earlier tests with other implementations didn't brought that up (Dan, Andreas ?).
Ok, I found it. The C-binding spec 1.0 introduced DRMAA_ERRNO_NO_MORE_ELEMENTS as new error code (see also tracker issue #1173). SGE, Condor and the current test suite where mainly implemented according to C-binding v0.95, so this is a historical bug.
Peter.
Thanks !
Peter.
Thanks for the help.
Matthieu Cargnelli
-- *************************************************** * Daniel Templeton UMPK18 x83749 * * Staff Engineer, Sun N1 Grid Engine * *************************************************** * An "intellectual" is a man who takes more * * words than he needs to say more than he knows. * * -Dwight D. Eisenhower * ***************************************************
The current DRMAA release in Condor 6.7.16 contains the problem, it will be fixed with the next release. Regards, Peter. Am 06.02.2006 um 15:29 schrieb Daniel Templeton:
Thanks for pointing that out. I'll file an issue against SGE, and add the missing error code.
Daniel
Peter Troeger wrote On 02/04/06 21:46,:
Am 04.02.2006 um 21:26 schrieb Peter Troeger:
Meanwhile I'm surprised by something: in the ST_SUPPORTED_ATTR test the program checks the drmaa_get_next_attr_name() return code, comparing it with DRMAA_ERRNO_SUCCESS and then with DRMAA_ERRNO_INVALID_ATTRIBUTE_VALUE. If the return code is neither of these values, the test fails. I understood that the drmaa_get_next_attr_name() function was supposed to return DRMAA_ERRNO_NO_MORE_ELEMENTS when the end of the list is reached. That's what my lib does, and the therefore the test fails.
Where am I wrong ?
Nowhere. I will fix this immediately. The more interesting question is while earlier tests with other implementations didn't brought that up (Dan, Andreas ?).
Ok, I found it. The C-binding spec 1.0 introduced DRMAA_ERRNO_NO_MORE_ELEMENTS as new error code (see also tracker issue #1173). SGE, Condor and the current test suite where mainly implemented according to C-binding v0.95, so this is a historical bug.
Peter.
Thanks !
Peter.
Thanks for the help.
Matthieu Cargnelli
-- *************************************************** * Daniel Templeton UMPK18 x83749 * * Staff Engineer, Sun N1 Grid Engine * *************************************************** * An "intellectual" is a man who takes more * * words than he needs to say more than he knows. * * -Dwight D. Eisenhower * ***************************************************
Peter, I figured out what's wrong. The error is not in the list of errors at the end of the doc, but it is in the return code list for the individual functions. Daniel Peter Troeger wrote On 02/07/06 08:20,:
The current DRMAA release in Condor 6.7.16 contains the problem, it will be fixed with the next release.
Regards, Peter.
Am 06.02.2006 um 15:29 schrieb Daniel Templeton:
Thanks for pointing that out. I'll file an issue against SGE, and add the missing error code.
Daniel
Peter Troeger wrote On 02/04/06 21:46,:
Am 04.02.2006 um 21:26 schrieb Peter Troeger:
Meanwhile I'm surprised by something: in the ST_SUPPORTED_ATTR test the program checks the drmaa_get_next_attr_name() return code, comparing it with DRMAA_ERRNO_SUCCESS and then with DRMAA_ERRNO_INVALID_ATTRIBUTE_VALUE. If the return code is neither of these values, the test fails. I understood that the drmaa_get_next_attr_name() function was supposed to return DRMAA_ERRNO_NO_MORE_ELEMENTS when the end of the list is reached. That's what my lib does, and the therefore the test fails.
Where am I wrong ?
Nowhere. I will fix this immediately. The more interesting question is while earlier tests with other implementations didn't brought that up (Dan, Andreas ?).
Ok, I found it. The C-binding spec 1.0 introduced DRMAA_ERRNO_NO_MORE_ELEMENTS as new error code (see also tracker issue #1173). SGE, Condor and the current test suite where mainly implemented according to C-binding v0.95, so this is a historical bug.
Peter.
Thanks !
Peter.
Thanks for the help.
Matthieu Cargnelli
-- *************************************************** * Daniel Templeton UMPK18 x83749 * * Staff Engineer, Sun N1 Grid Engine * *************************************************** * An "intellectual" is a man who takes more * * words than he needs to say more than he knows. * * -Dwight D. Eisenhower * ***************************************************
-- *************************************************** * Daniel Templeton UMPK18 x83749 * * Staff Engineer, Sun N1 Grid Engine * *************************************************** * An "intellectual" is a man who takes more * * words than he needs to say more than he knows. * * -Dwight D. Eisenhower * ***************************************************
participants (2)
-
Daniel Templeton -
Peter Troeger