On Sun, 28 Feb 2021, Sven Schreiber wrote:
Am 28.02.2021 um 16:44 schrieb Allin Cottrell:
> 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:
>>
>> 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.
Hm, I find no terms "modtest" or "nonlinearity" in cli/gretlcli.c,
that's why I thought lib/src/libglue.c was the "interface". But probably
"interface" is not the right term.
I see the following (partial) chain:
- nonlinearity_test function in lib/src/compare.c
- called by model_test_driver in lib/src/libglue.c
- called by gretl_cmd_exec in lib/src/interact.c (like you said, of course)
This is another case in point for bridging via libglue.c: we have a
single command, "modtest", with numerous options. Internally, this
branches into various different function calls (not just simple
inflections of a single function call). So the job of libglue is to
sort out the options (rejecting any invalid combinations) then
dispatch execution to where it needs to go. This applies to both CLI
and GUI.
Actually, it would be nice to have a graphical map with the function
calling graph. I'm sure there exist sophisticated automatic tools for
that, any recommendation?
Yeah, that would be nice. I've seen it done for lapack but I haven't
looked into how it's done.
Allin