[Gretl-devel] nonlinearity tests, etc. (1)
I'm moving this thread to devel, it's not really "user" stuff.
And I'm replying in two parts: on the gretl internals question then
on the BDS nonlinearity test.
On Sun, 28 Feb 2021, Sven Schreiber wrote:
>> (Side remark: At the top of the file it says "library.c
for gretl --
>> main interface to libgretl functions", so I don't understand why it
>> lives under "gui" in the source tree. A hansl batch script on the CLI
>> would also seem to use this.)
>
> In that context "gretl" means the GUI program, as opposed to gretlcli.
> The CLI programs gretlcli and gretlmpi have their own interfaces to
> libgretl, which have to differ in various ways. Nothing but the GUI
> program uses, or could use, gui/library.c.
Aha, good to know. I guess then the other interface is in
lib/src/libglue.c?
Not really. The CLI-specific library interface is in gretlcli.c and
gretlcli-mpi.c. The job of lib/src/libglue.c is to bridge between
the user-command level and the internal functions level, for certain
commands that require pre-processing. For example, commands that
usually operate on series but that support a --matrix=whatever
option, in which case we construct an on-the-fly internal dataset.
What does it mean to execute a script in the GUI script editor,
does that count as GUI or as CLI in this context?
Well, it shares a log with CLI execution, but when a script is
called from the GUI we need various callbacks to keep the GUI in
sync (e.g. populating the main window when series are added or
deleted, populating the "icon view" window when required). So it's a
bit of both.
In gui/library.c you'll see that most commands get passed on to
gretl_cmd_exec(), in src/lib/src/interact.c, but some are so
intimately connected to the GUI that it's best to handle them
locally.
Allin