gmane.comp.clustering.drmaa.wg

Re: python-drmaa needs a new maintainer

Enrico Sirola — 2013-03-08T15:46:30

Hi Peter,

Il giorno 08/mar/2013, alle ore 12.48, Peter Tröger ha scritto:

[...]


ok (I didt't even know there were questions about drmaa-pythen on stackoverflow :)


fine. If you think to clone the project somewhere else (github, bitbucket...) let me know and I'll write a pointer on the present home page on googlecode, otherwise I'll add you as a maintainer on the present google code project (let me know your gmail address in this case). Also, in order to give you the status of owner for the drmaa package on PyPi (in order to install it via easy_install/pip) you need to create an account on pypi and write me your username.
Thanks for volunteering!
cheers,
e.

Re: python-drmaa needs a new maintainer

Andre Merzky — 2013-03-08T12:58:33

Hi all, Peter,

On Fri, Mar 8, 2013 at 12:48 PM, Peter Tröger <peter-gdtISb5op9Zulxpn9UvDqw< at >public.gmane.org> wrote:


Let me know if you need help -- I am doing mostly Python nowaday, for
good or for worse :-P

Cheers, Andre.

Re: python-drmaa needs a new maintainer

Peter Tröger — 2013-03-08T11:48:59

Hi Enrico,

first, thanks for years of support for the DRMAA community.

I would volunteer to take over the ownership, since I am anyway the major responsible for drmaa-python on StackOverflow ;-) …

However, since we need to spend the working group resources carefully, I would only volunteer to perform crucial maintenance and security fixes. The DRMAAv2 Python binding is the next thing on the working group agenda, and this is where they major efforts will be spent in the future. Obviously, your code will fit nicely for the according drmaa2-python module implementation.

Best regards,
Peter.


Am 08.03.2013 um 11:48 schrieb Enrico Sirola <enrico.sirola-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>:

python-drmaa needs a new maintainer

Enrico Sirola — 2013-03-08T10:48:20

Hi,
In recent times I don't have time anymore to carry on the development of drmaa-python, the drmaa Python implementation I wrote some time ago. For this reason, I'm looking for a new maintainer taking the project ownership, please drop me a note if interested.
Best Regards,
Enrico

Re: DRMAA Reference

Peter Tröger — 2013-02-18T20:32:51

Hi Gonzalo,

thanks for your interest in DRMAA.


Referencing the GFD.133 specification / DRMAA home page would be more than enough. 

Best regards,
Peter.

DRMAA Reference

Gonzalo Zarza — 2013-02-14T15:00:51

Hi,

I'm an external collaborator (and former PostDoc) of the Computer
Architecture and Operating Systems Department at the Universitat Autonoma
de Barcelona.

Some time ago, we have developed a Simulation Management Tool using DRMAA
to interact with our computer clusters in the department. Now, we're
planning to upload and release the project in Google Code (under
construction web http://code.google.com/p/sim-mgmt-tool/) under the GNU GPL
v2.

Is there any correct or standard procedure for citing/mentioning DRMAA in
this situation? Should we include some reference to the DRMAA
project/website somewhere in the source code?

Thank you!

Best regards,
Gonzalo Zarza

Re: DRMAA C Binding Issue

Daniel Gruber — 2013-01-30T10:12:52

Thanks Peter for posting!

+1 for Rogers solution with "extern const".

Regards,

Daniel

Am 28.01.2013 um 20:05 schrieb Roger Brobst:

Re: DRMAA C Binding Issue

Roger Brobst — 2013-01-28T19:05:17

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 inv

Re: DRMAA C Binding Issue

Roger Brobst — 2013-01-28T16:31:36

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-gdtISb5op9Zulxpn9UvDqw< at >public.gmane.org>
To: drmaa-wg-F/d3TggoGCE< at >public.gmane.org <drmaa-wg-F/d3TggoGCE< at >public.gmane.org>
Date: 01/28/2013 05:14 AM

DRMAA C Binding Issue

Peter Tröger — 2013-01-28T13:14:13

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-OCCI Document Status

Peter Tröger — 2012-11-30T11:27:19

Hi Antonio,


As the Redmine project page says, you can clone the repository with the specification document sources:

git clone http://redmine.ogf.org/git/standards/applications-area/drmaa-wg/drmaav2-occi-binding.git

Please note that this is a document under work. Furthermore, the OCCI-DRMAA standardization is currently suspended, since the OCCI guys need to improve at some points first. One example is the currently missing pagination support in OCCI. You find according comments in the TEX file.


Read the current document, take nothing for granted, and come back with your ideas :) 

Beside that, what about DRMAAv2 support in your projects ? Any language bindings you need to have beside C and OCCI ?

Best regards,
Peter.

DRMAA v1 Tcl language bindings

Fred Youhanaie — 2012-11-16T19:59:35

No, it's not a typo, it is "v1" :-)

I started this project over 3 years ago when I needed an interactive DRMAA shell, but I had to set it aside in 2010 when I started a new job that didn't leave me any spare time. It was almost finished 
then.

I have now managed to tie up the loose ends, it even passes the tests in the test suite, and upload it to Github.

The sources are here: https://github.com/fredyouhanaie/drmaatcl

There is a PDF document, generated from the source code, in the downloads area:
https://github.com/downloads/fredyouhanaie/drmaatcl/drmaatcl-main-14124b9.pdf

See the PDF for examples of use, or the "Examples/" directory in the source tree.

Now, where did I leave that DRMAAv2 spec? :)

Cheers

Fred Youhanaie

DRMAAv2 C binding is finished

Peter Tröger — 2012-11-16T09:02:47

Dear all,

I am happy to inform you that the C binding specification for DRMAAv2 was finally approved. It is now OGF standard GFD-R-P.198.

It is now the time to focus on adoption. The reference implementation is more or less finished, feel free to fork your own version for a quick start:

https://github.com/troeger/drmaav2-mock

New language bindings (Java, Python, ...) only make sense if we have some DRMAAv2 implementations for real systems in place.

Best regards,
Peter.



Anfang der weitergeleiteten Nachricht:

Fwd: [wg-all] JOGC Special Issue

Peter Tröger — 2012-09-17T08:31:20

Dear all,

this is a unique opportunity to summarize our latest DRMAAv2 work in a scientific publication. We can discuss our abstraction approaches that finally lead to the standardized API design.  

Who is interested to join me in the paper writing ? 

It would be also nice to have some early adopter talking about prototype work and the resulting performance numbers.

Best regards,
Peter.

Anfang der weitergeleiteten Nachricht:

Re: DRMAAv2 Root Specification Errata

Andre Merzky — 2012-09-04T20:57:27

Excellent - that should do the trick :-)  Please submit it to the
redmine tracker when you think it is ready.

Thanks, Andre.


On Tue, Sep 4, 2012 at 7:48 PM, Peter Tröger <peter-gdtISb5op9Zulxpn9UvDqw< at >public.gmane.org> wrote:

Re: DRMAAv2 Root Specification Errata

Peter Tröger — 2012-09-04T17:48:36

Andre, thanks for the hint. 

Attached you can find the corrected root specification with an additional errata chapter.

Best regards,
Peter.



Am 04.09.2012 um 12:52 schrieb Andre Merzky <andre-vSXDtpAwmDysTnJN9+BGXg< at >public.gmane.org>:

Re: DRMAAv2 Root Specification Errata

Andre Merzky — 2012-09-04T10:52:03

Peter,

I am afraid you will need a document which includes the complete
specification, with the errata applied, and an appendix which
describes the errata (which is basically what you have right now).

The reason is that you expect the revised spec to replace the DRMAA.v2
spec, right?  But we don't want implementors to read the 'old' spec,
and apply the errata themselves.  So instead, we would like to provide
the corrected spec, and document that errata have been applied to the
previous version.

Hope that makes sense,

  Andre.


On Tue, Sep 4, 2012 at 11:33 AM, Peter Tröger <peter-gdtISb5op9Zulxpn9UvDqw< at >public.gmane.org> wrote:

DRMAAv2 Root Specification Errata

Peter Tröger — 2012-09-04T09:33:37

Dear all,

as decided at OGF35, here is the errata for DRMAAv2 that brings the root spec back in sync with the final C binding you got yesterday.

Please check if your favorite flaw is covered in this document. I will send it to the OGF editors in 24h.

Best regards,
Peter.

DRMAAv2 C Binding - Final document to be submitted

Peter Tröger — 2012-09-03T08:57:09

Dear all,

this is the final version of the DRMAAv2 C binding. Please check if your favorite last change was correctly incorporated. The document will go to the OGF editors in 24 hours.

Best regards,
Peter.



Anfang der weitergeleiteten Nachricht:

Meeting minutes - conference call - August 22

Peter Tröger — 2012-08-28T11:38:20

Am 20.08.2012 um 12:17 schrieb Peter Tröger <peter-gdtISb5op9Zulxpn9UvDqw< at >public.gmane.org>:


Participants: Andre, Daniel, Mariusz, Roger, Stephan Klauck, Peter
Meeting secretary: Peter


All in good health, some reporting from Peter about OGF35 in Delft


- No decision at OGF35, voting needed
- Roger, Peter: "principle of least astonishment, no NULLing in the library"
- Andre, Daniel, Mariusz: "security problem, asynchronous free problem, OpenMPI example"
- 3:2 voting result for changing the API -> free* functions get pointer variable reference and assign NULL to it
- Voting also clarified that no other API changes are made


- No decision at OGF35, voting needed
- 5:0 voting result for keeping MACOS identifier - OS version is already a separate concept in the API
- 5:0 voting result for changing TRUE64 to TRU64
- 5:0 voting result for adding 64bit variations of all instruction set architectures
- These changes demand an errata for the DRMAAv2 root specification


- No decision at OGF35, voting needed
-

Re: Conference call - August 22 - 19:00 UTC

Andre Merzky — 2012-08-21T10:57:43

Hi Peter,

I probably won't make the call, thus some input from my end.  I don't
have overly strong opinions on any of the issues, so whatever option
gets the majority will be fine with me.

Comments inlined below.

Best, Andre.


On Mon, Aug 20, 2012 at 12:17 PM, Peter Tröger <peter-gdtISb5op9Zulxpn9UvDqw< at >public.gmane.org> wrote:

I find nulling convenient and safe, and don't mind a slight asymmetry
in the interface to support it.  You will find best practices in
support of it, but also good arguments against it, I am sure ;-)



Clarifying the text should suffice?



return an error.  Chaining is not very useful, and confusing, if not
applied to all calls - which would make error reporting difficult.



_j_, as that will be frequently used.  Not sure if ultra short
prefixes are good in general though.  length versus readability is
hard to decide, and someone *will* be unhappy, no matter what you
choose...


Cheers, Andre.