[moving to the list] Hi Steve, On Mon, Oct 1, 2012 at 2:34 PM, Steve Fisher <dr.s.m.fisher@gmail.com> wrote:
Andre,
Having started to implement SD in Python I thought I would take a look at the document described below. I found that anonymous accesss to the git repository would not work for me
This should totally work, with git clone http://redmine.ogf.org/git/standards/applications-area/saga-wg.git I just created a dummy user account, and could get the files all right. Would you please let me know the error you see? Thanks!
so I extracted the files one by one
Oy Weh!
and ran the make file only to discover that there is almost no content.
Much ado about nothing, ey? ;-)
I presume that people are working on it - ( relying upon the power of GIT to work in isolation ;-) ) . Does anybody have an up to date copy of the document - as dvi or pdf.
Well, the original mail stated: "hope to have a decent draft document *after* OGF36" so, yes, this is just a skeleton right now. We digged through the mail archives and code repos though, to see what has been discussed and agreed upon before. I'll be adding that material to git during this week. That is what we want to wade through in Chicago, and fill out that document.
My main thought so far - is that the attribute interface should not be implemented in python. Just use a dictionary which can contain anything - including lists to represent vector attributes.
Well, there we go. The last explicit statement I find about attributes is in a mail following a phone confcall: Date: Thu, 12 Nov 2009 11:12:27 +0100 From: Mathijs den Burger <mathijs@cs.vu.nl> To: Manuel Franceschini <livewire@koltern.com>, Thilo Kielmann <kielmann@cs.vu.nl>, Andre Merzky <andre@merzky.net> Subject: Work plan for updating attributes in the SAGA Python bindings "It seems we have reached consensus about the use of SAGA attributes in the Python bindings: only use set_attribute() and get_attribute(), and forget about dictionaries and Python properties." This was motivated in a previous OGF discussion, where the notes say: "Attribute Interface: possibly to ONLY set_attribute/get_attribute, even if that is not 100% pythonesque. SAGA attribs *are* *not* called member attribs, but convey a different semantics. Also, they are sometimes extensible, sometimes not, sometimes read/writable, sometimes readonly - all difficult to express in the 'native' Python way it seems. Not to speak of async..." Happy to hear your (and others) opinion... As a data point: by now I implemented attributes in python for different interfaces (properties, dictionary, plain SAGA), and can express almost all semantics (vector/scalar, enum/string/int/... types, extensible/not extensible, RO/RW/Final, etc) -- but not the async operations. Those will only work for the explicit SAGA calls, and I can't see a way around it. I am not saying this aapproach should be used, at all. Just saying that those parts *can* be implemented. No real python disciple would ever like it, of course -- typed properties! Ugh! :-P
I am very much in favour of getting this tied down ASAP - however we should not make the python API more complex than needed.
Ha! :-) Best, Andre.
Steve
On 17 September 2012 13:21, Andre Merzky <andre@merzky.net> wrote:
Hi all,
I think you all know that we (the former SAGA-C++ group) started to re-implement SAGA in Python, for a variety of reasons. Related to that, we have an increased interest in actually defining these python bindings cleanly.
Over the last years, there have been a gazillion discussions over these bindings, between the different interested groups, but so far the result of that discussion has not been formalized. Mark Santcroos from Amsterdam an me intent to fix that gap over the next couple of weeks, and hope to have a decent draft document after OGF36 in Chicago. We will base that document on the various meeting notes and email threads, which we think represent the consensus of these past discussions.
We thus plan to use next OGF to re-discuss and finalize the binding, and would be delighted if you would come along. If that is not possibly, we intent to share the draft document after OGF for comments / corrections etc. Feel free to follow up with the document evolution on the saga-wg git repository (http://redmine.ogf.org/projects/saga-wg/repository/revisions/master/show/doc...; use your OGF redmine account for r/w access).
As far as I can see (and as far as I can remember), the agreed bindings require relatively small changes to the bindings implemented at VU Amsterdam, which, I think, is the same code base also used by our friends at IN2P3. We wanted to check who takes responsibility of that code at this point, and if there is still commitment to actually follow the OGF binding document, when that is finalized?
Best, Andre.
-- Nothing is really difficult...
-- Nothing is really difficult...
This should totally work, with
git clone http://redmine.ogf.org/git/standards/applications-area/saga-wg.git
Input and output are below: [fisher@smfisher fred]$ http_proxy=wwwcache.rl.ac.uk:8080 git clone http://redmine.ogf.org/git/standards/applications-area/saga-wg.git Initialized empty Git repository in /home/fisher/fred/saga-wg/.git/ it then just sits there doing nothing besides having created the empty repository. Note that I have to use the web proxy to access URLs off site.
Well, the original mail stated:
"hope to have a decent draft document *after* OGF36"
so, yes, this is just a skeleton right now. We digged through the mail archives and code repos though, to see what has been discussed and agreed upon before. I'll be adding that material to git during this week. That is what we want to wade through in Chicago, and fill out that document.
I had assumed that this was a rough document to be discussed in Chicago rather than an empty skeleton. The discussion could be difficult with no existing document. I presume there will not be many of us there so it should be possible with work outside the official sessions. Ole - will you be in Chicago? I will think a bit more about the attribute interface before responding Steve
For SD I have a ServiceDescription with a fixed set of attributes. These should be read only for the user. The obvious way of doing this is to use the @Property decorator as in the Parrot example in http://docs.python.org/library/functions.html#property (the _voltage can be set of course but voltage can't) In my case I then have, where sd is a ServiceDescription, sd.uid, sd.url, sd.name etc. I will also have sd.relatedServices which is a list which I would always create even if empty to allow people to use it without checking first. For the data fields obtained via sd.get_data in the spec I would make sd.data (also read only) return a dictionary (maybe empty). With this: "print sd.data" works without any effort. The dictionary will contain anything you want - but normally it will be simple things like strings and numbers or lists of them. I would also suggest not implementing the async stuff in python. Threads are easy enough for the user to do in python - and you can put exactly what you want in each thread. Steve
On Tue, Oct 2, 2012 at 10:59 AM, Steve Fisher <dr.s.m.fisher@gmail.com> wrote:
This should totally work, with
git clone http://redmine.ogf.org/git/standards/applications-area/saga-wg.git
Input and output are below:
[fisher@smfisher fred]$ http_proxy=wwwcache.rl.ac.uk:8080 git clone http://redmine.ogf.org/git/standards/applications-area/saga-wg.git Initialized empty Git repository in /home/fisher/fred/saga-wg/.git/
it then just sits there doing nothing besides having created the empty repository. Note that I have to use the web proxy to access URLs off site.
The proxy seems indeed to be the problem - I found several forum discussions about that. On http://stackoverflow.com/questions/7734518/how-to-set-up-git-to-get-through-..., the following it listed as solution: http://cntlm.sourceforge.net/ . Hope that helps...
Well, the original mail stated:
"hope to have a decent draft document *after* OGF36"
so, yes, this is just a skeleton right now. We digged through the mail archives and code repos though, to see what has been discussed and agreed upon before. I'll be adding that material to git during this week. That is what we want to wade through in Chicago, and fill out that document.
I had assumed that this was a rough document to be discussed in Chicago rather than an empty skeleton. The discussion could be difficult with no existing document. I presume there will not be many of us there so it should be possible with work outside the official sessions. Ole - will you be in Chicago?
Ole will not be - Mark and Shantenu will be there. Best, Andre.
I will think a bit more about the attribute interface before responding
Steve
-- Nothing is really difficult...
Hi, I am very much in favor of Steve's proposal of not making the Python API more complex that absolutely necessary. On Oct 1, 2012, at 7:39 PM, Andre Merzky <andre@merzky.net> wrote:
I am not saying this aapproach should be used, at all. Just saying that those parts *can* be implemented. No real python disciple would ever like it, of course -- typed properties! Ugh! :-P
If no 'Python disciple' would like it, it should absolutely not go into the Python language bindings, IMHO. My $0.02. Cheers, Ole
I am very much in favour of getting this tied down ASAP - however we should not make the python API more complex than needed.
Hi, On Tue, Oct 2, 2012 at 2:53 PM, Ole Weidner <oweidner@cct.lsu.edu> wrote:
Hi,
I am very much in favor of Steve's proposal of not making the Python API more complex that absolutely necessary.
On Oct 1, 2012, at 7:39 PM, Andre Merzky <andre@merzky.net> wrote:
I am not saying this approach should be used, at all. Just saying that those parts *can* be implemented. No real python disciple would ever like it, of course -- typed properties! Ugh! :-P
If no 'Python disciple' would like it, it should absolutely not go into the Python language bindings, IMHO.
Ok, I should have been more careful - that remark was a little tongue-in-cheek... By now I am quite convinced that there is no single definition of 'pythonesque' outside of what python core represents. So for me, pythonesque is what can easily be done in python without abusing the language. But ask 3 other people about that, and you'll get 3 or more different answers... *sigh* So I think that the current Bliss attribute interface will not meet the love of python programmers in general. I still think it is pythonesque though, as it cleanly exposes the dict and property interfaces. Best, Andre.
My $0.02.
Cheers, Ole
I am very much in favour of getting this tied down ASAP - however we should not make the python API more complex than needed.
-- Nothing is really difficult...
Ole will not be - Mark and Shantenu will be there.
As the developer of the only "clean" SAGA API it is very unfortunate that Ole will not be there. Also I see that the SAGA sessions are on the last day. Can we get some work done earlier? Steve
On Thu, Oct 4, 2012 at 10:48 AM, Steve Fisher <dr.s.m.fisher@gmail.com> wrote:
Ole will not be - Mark and Shantenu will be there.
As the developer of the only "clean" SAGA API it is very unfortunate that Ole will not be there.
Yes - but Ole just moved (physically) from Baton Rouge to Rutgers, and is setting himself up. Also, funding is finite :(
Also I see that the SAGA sessions are on the last day. Can we get some work done earlier?
Yes, I certainly hope so. When will you be getting to Chicago, and how long can you stay? FWIW, Mark and I plan to meet Sunday around 6pm in the lobby of the conference hotel - anybody feel free to join if you are around by then! Best, Andre.
Steve
-- Nothing is really difficult...
participants (3)
-
Andre Merzky -
Ole Weidner -
Steve Fisher