On Sun, 28 Sep 2014, Riccardo (Jack) Lucchetti wrote:
in http://lists.wfu.edu/pipermail/gretl-devel/2014-September/005285.html
> Gretl has used gnuplot for all its graphical output since the dawn of
> time. [...]
>
> It could perhaps be advisable to extend the "foreign" command to drive
> gnuplot in a more transparent way than we do now, and at the same time
> take advantage of a change scheduled for gnuplot 5.0 (which should be in
> a cinema near you real soon): "Command scripts may place in-line data in
> a named data block for repeated plotting." This would make it possible
> to pass data to gnuplot in a clean and efficient way.
>
> The big difference with other "foreign" environments would be that it's
> highly likely that a script writer might want to pass to gnuplot strings
> as well as data. So, we could imagine a situation in which we pass
> bundles and have something like
>
> <pseudo-hansl>
> bundle to_gp = null
> to_gp["foo"] = X
> to_gp["bar"] = "A string"
> foreign language=gnuplot --data=to_gp
> ...
> end foreign
> </pseudo-hansl>
>
> Being able to do something like this would reduce the need for
> supporting the rather byzantine syntax we now have for the "gnuplot"
> command, which could be much simplified with some options deprecated.
Sorry it's taken me a while to reply on this, but here are my thoughts.
I like the idea of using a "block" approach for non-trivial gnuplot
commands within gretl, for two main reasons:
1) to avoid option-overload and the somewhat fussy syntax we have at
present for appending "literal" lines to a plot specification; and
2) to streamline the handling of custom plots (i.e. those not supported by
gretl's built-in "gnuplot" options) so that package writers or others
don't have to mess with low-level file I/O.
I think that that these two uses probably call for somewhat different
handling -- maybe two distinct modes of a "plot", or perhaps "foreign",
block.
In the first case I'm thinking of a plot that's of a supported type, and
the user just wants to add a few things (e.g. a specific title, some
labels). With any luck such a plot will be parseable by gretl, so that
editing via the GUI plot dialog should be possible. In the second case, I
have in mind a plot that bypasses gretl's built-in mechanisms and sends a
bunch of literal gnuplot directives.
So for mode 1 you might have something like
a) old-style:
gnuplot foo { set title "My title"; } --with-lines
b) new-style:
plot
data foo
option with-lines
literal set title "My title"
end plot
where "data", "option" and "literal" are supposed to be gretl keywords;
"data" would be followed by the name of a matrix or a list of series,
"option" by an option flag but without the need for "--", and "literal" by
a line that should be passed straight through to gnuplot. You could have
as many option and literal lines as you want.
For mode 2 you might have something like:
plot --data=foo
<literal line 1>
<literal line 2>
...
<literal line n>
end plot
with no gretl keywords inside the block. (OK, basically just thinking out
loud here -- I'm not proposing this with any definiteness.)
I'm not sure about using bundles in this context; my first impression is
that it's an unnecessary layer of indirection, but I'm open to persuasion.
On the use of named data blocks in gnuplot input: Yes, that would
certainly facilitate this sort of thing. The trouble is that (as you say)
such blocks are a gnuplot 5.0 feature. We package gnuplot 5.0 with our
Windows and Mac builds but it may be some time before Linux distros catch
up with that. Even Fedora and Arch (which tend to be pretty much
up-to-date on most things) seem to be quite conservative when it comes to
the gnuplot version they package. At present we only require gnuplot 4.4.0
in the gretl build, though perhaps we could bump that forward a bit.
Allin
