about (a): running multiple commands for each field could be annoying if
for ex one was trying to query a server side value and the user had to
enter their password more than once.
about (b), sounds OK but I'm not sure how it would work with the
connections to remote site.
in all this, I think we want to make the low-level (ie ssh tunnel)
connection once and make use of it from then on, for everything. as
opposed to making a connection for querying and then making another
connection for submitting/connecting to pvserver etc (or in your (a)
many connections).
In my suggestion of allowing a script(or as you "executable") to
generate the pvsc xml, PV can use a pipe to communicate to first fetch
the xml from the script then report the user selection back all while
keeping the script alive, and same connection open.
On 04/14/2015 02:00 PM, Utkarsh Ayachit wrote:
Thanks Burlen/Rick.
After discussing it with a few folks here, how about the following options:
a. What if we make it possible to run an "executable" to obtain a
value for any attribute in the XML. One could indeed use a Python
script to produce that value or any other executable.
b. We provide a mechanism to add a Python function in the PVSC. Before
(and/or after) the PVSC is processed by the UI for display, it will
pass the XML to that function which can update the XML as appropriate.
This would mean that the Python code has to be aware of the PVSC's XML
structure, but shouldn't be a problem since the Python code is
embedded in the PVSC XML itself.
Both will allow 1 and 2. 1 may still be a little hard work on the PVSC
writer side, but it's a one time thing.
Burlen, I think 3 is a little independent of this task. I do agree, we
should embed all necessary tools in the paraview bundle -- something
we've been talking about for a while. We should address that, I just
don't want to commit to it just yet :).
Thoughts? The more I think about it, I think I am leaning towards (b).
For (a) the next logical question becomes how does one specify the
path to the executable to run and we're back to the same problem we're
trying to address :). What are your thoughts?
Utkarsh
On Mon, Apr 13, 2015 at 11:48 AM, Burlen Loring <[email protected]> wrote:
OK, I added some notes based on the above discussion.
On 04/13/2015 08:33 AM, Utkarsh Ayachit wrote:
Great, let's start here:
https://docs.google.com/a/kitware.com/document/d/1uzi3VzpCxiGslhqaUde3ZbKcx-9LLG_ly3BYvDiPPx0/edit?usp=sharing
Utkarsh
On Mon, Apr 13, 2015 at 11:29 AM, Burlen Loring <[email protected]>
wrote:
Great, that sounds like a good way to start.
On 04/13/2015 06:53 AM, Utkarsh Ayachit wrote:
Burlen/Rick,
I am totally open to adding new features/refactoring the pvsc code.
It hasn't changed much in a few years, and I am sure we know more than
we did when we started with this :). Since you guys are the ones
actually using this code in the field, it'd be great if you can
identify the feature list of things missing or difficult to do in the
current implementation and we can decide which would be best way
forward.
Should I create a google-doc or something which all can edit to built
this
list?
Utkarsh
On Mon, Apr 13, 2015 at 8:19 AM, Angelini, Richard C (Rick) CIV USARMY
ARL (US) <[email protected]> wrote:
Burlen/Utkarsh —— my preferred solution is also to not set an
environment
variable if possible. For my particular issue, I’d much rather be able
to
do a `which ssh` (or equivalent) to get the answer than than asking the
user to set an environment variable.
Implementing a python-based default_servers definition opens things up
for
much more programmatic flexibility.
# take a guess at which ssh command to use
try:
default_shell=os.popen("which ssh").read()
default_shell=default_shell.rstrip("\r\n")
except:
default_shell="/usr/krb5/bin/
________________________________
Rick Angelini
USArmy Research Laboratory
CISD/HPC Architectures Team
Phone: 410-278-6266
-----Original Message-----
From: Burlen Loring <[email protected]>
Date: Sunday, April 12, 2015 at 10:34 PM
To: Utkarsh Ayachit <[email protected]>, Rick Angelini
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [Paraview] default_servers.pvsc question
Hi Utkarsh,
I think environment variables are kind of a band aid around a larger
issue. In addition to leveraging the user's local environment, there's
also no way to get information from the server side environment. for
example list of account numbers a user can charge jobs to, or a list of
active queues. One thing I have been thinking about is rather than
just
reading pvsc from an xml file, paraview could call a script to get the
pvsc xml. This script could query the user's local/remote environment
and generate the xml. A long time ago we had talked about a python
based
solution. What do you think?
Burlen
On 4/12/2015 11:31 AM, Utkarsh Ayachit wrote:
Rick,
Alas no, this isn't currently supported. But should be fairly
straightforward to add. I've reported a bug:
http://www.paraview.org/Bug/view.php?id=15421
Utkarsh
On Fri, Apr 10, 2015 at 4:09 PM, Angelini, Richard C (Rick) CIV USARMY
ARL (US) <[email protected]> wrote:
Question about the default_servers.pvsc file…..
I have this in my host profile:
<Server name=“My System" resource="csrc://127.0.0.1">
<CommandStartup>
<Options>
<Option name="SSHLOC" label="Local SSH Command" save="true">
<File default="/usr/local/bin/ssh"/>
</Option>
So, when the GUI pops up, the user has an opportunity to change the
path to
ssh. But, rather than hard-coding the default value, or presenting
blank
field and have the user put in the correct path, is it possible to
query the
user’s environment and find `which ssh` and substitute in that
value??
________________________________
Rick Angelini
USArmy Research Laboratory
CISD/HPC Architectures Team
Phone: 410-278-6266
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Search the list archives at: http://markmail.org/search/?q=ParaView
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Search the list archives at: http://markmail.org/search/?q=ParaView
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Search the list archives at: http://markmail.org/search/?q=ParaView
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview
