Re: [Gretl-devel] "start gretlcli.exe" vs. simple "gretlcli.exe" (on Windows)
Am 15.01.2017 um 19:10 schrieb Allin Cottrell:
On Fri, 13 Jan 2017, Sven Schreiber wrote:
I'm attaching a new variant of my own. I've cut back on
printing, error
checking and options to try to expose the overall structure as clearly
as possible. Besides that there are two main points that you might like
to consider.
Thanks a lot (but I haven't had time to check out the latest script yet)!
1) MPI stuff: you don't need to write out N temporary script
files, one
will do nicely. The only rank-specific point in the script is the name
of the bundle to read/write and that can be constructed conditional on
$mpirank. Also, echo and messages are off by default in an MPI block;
there's no need to turn them off explicitly.
OK.
2) Per-process output files: I think that for most users most of the
time it would be more user-friendly to gather the content of these files
and consolidate the output, so that's what I've done. I guess one could
have an option switch in this regard.
I have also been thinking whether writing the output files is actually
more of a debugging option, pushing for / assuming that everything
valuable should be put into the bundles.
I haven't done anything about this in my current variant, but if
it were
my package I'd probably want to give the option of supplying the
user-code via the name of a script file rather than a hansl string.
That was actually the idea for normal use cases, but I thought the
contents string could always be produced on the fly by
"readfile(<pathstring>)".
Last small point: my variant cleans up its temporary files, if we
don't
want to preserve tham for debugging purposes.
I'm still undecided whether it should be a requirement that the current
gretl instance has shell commands enabled, now that mpi and not the
shell is used. Is there actually a way to check programmatically that
gretl preference setting?
thanks,
sven