Re: How to make java client app to download jar package from server
autoly?
Andrew Thompson wrote:
Patricia Shanahan wrote:
Andrew Thompson wrote:
Patricia Shanahan wrote:
....
(snip)
Fortunately, I have access to a Linux grid computer where I can do up to
64 jobs at a time.
A GUI would be a disaster for this type of work - there is no way I'm
going to manually enter the parameters for each simulation individually.
I don't get it. What 'non-manual' way is there to
enter parameters to a CLI based program, that is
not *also* available to a GUI'd program (if not in
the same exact way, then in some similar form)?
...
The way I use is a make file that looks at the set of parameter files in
the working directory, and generates a task for each parameter file
using it as input and a result file whose name is based on the parameter
file name as output.
There are all sorts of automation and mass production techniques that
can be used to generate, edit, and manage a collection of small, closely
related, structured text files without editing each of them individually.
...mmm, Yeh-OK ..but
At some point, the 'operator' (I am not quite sure, from
your description above, whether you are referring to things
as you might expect your *end* *users* to see, or whether
you are refering to your own builds and such) needs to
'choose a file' to run, right?
I'm my own end user. This is a research project in which I am using a
simulation as a tool. I want to optimize my total time, which means I'll
do infrastructure programming if, and only if, the result will save me
more time than it costs.
I mean, the scenario above seems to link it all
to the 'current directory', so how about this?
Instead of navigating to the correct directory
and 'starting the application' as it seems the
minimum might be for this process to happen,
the user simply 'starts the application' - which
then produces a dialog asking ..
'Current Directory? Yes/No'
..if the user answers 'yes' it proceeds, if 'no',
it shows a JFileChooser to navigate to whatever
directory the process should be performed in.
I generally leave a PUTTY window on the grid computer's control server,
sitting in the right directory. The actual actions to fire up a series
of runs, once I have the parameter files, is something like "!qm"
followed by enter. I'm a touch typist, so the time for four keystrokes
can be ignored - most of the time is bringing up the right window, which
I would have to do anyway.
Which brings me back to the point that a GUI'd
application could not only do what you described
(as far as I vaguely understand it), but do it
(slightly) more easily/slickly for the end user.
..sure it means more programming, but even for things
that I design for running in a headless environment,
if I intend to run them more than a handful of times,
I will 'wrap a GUI around it' as well.
I think you are underestimating the cost. If I were not using qmake I
would have to have some other grid-aware program throwing jobs at the
grid's queues, keeping track of the number of jobs, and adding more when
there is more work to do and the number of jobs is under the limit. Why
reinvent the wheel?
Moreover, the simulator itself would still be a command line program,
because it has to be something I can ship to a grid queue, and in any
case I don't have time to interact with them individually. A batch may
contain over a hundred runs, and up to 50 of them can be running at any
one time.
Patricia