3:44 p.m.
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
4:04 p.m.
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)
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?
(I'm aware it would be huge, but one could zoom in and out I guess.)
thanks
sven
4:18 p.m.
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
7:16 p.m.
On Sun, 28 Feb 2021, Allin Cottrell wrote:
> 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.
I remember I did that for libgretl a while back using some tool I can't
recall now. IIRC, the output picture was so huge to be useless by all
practical purposes. But it was a long time ago, I don't remember very
well.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
8:46 p.m.
Am 28.02.2021 um 20:16 schrieb Riccardo (Jack) Lucchetti:
On Sun, 28 Feb 2021, Allin Cottrell wrote:
>> 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.
I remember I did that for libgretl a while back using some tool I can't
recall now. IIRC, the output picture was so huge to be useless by all
practical purposes. But it was a long time ago, I don't remember very well.
There's actually a list of this on Wikipedia:
https://en.wikipedia.org/wiki/Call_graph#Static_for_getting_call_graphs_w...:
Does that ring any bells as to which tool it was?
cheers
sven
9:04 p.m.
On Sun, 28 Feb 2021, Sven Schreiber wrote:
Am 28.02.2021 um 20:16 schrieb Riccardo (Jack) Lucchetti:
> On Sun, 28 Feb 2021, Allin Cottrell wrote:
>
>>> 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.
>
> I remember I did that for libgretl a while back using some tool I can't
> recall now. IIRC, the output picture was so huge to be useless by all
> practical purposes. But it was a long time ago, I don't remember very well.
There's actually a list of this on Wikipedia:
https://en.wikipedia.org/wiki/Call_graph#Static_for_getting_call_graphs_w...:
Does that ring any bells as to which tool it was?
Hmm, no, sorry. I can only remember that graphviz was the tool that was
used for producing the plot. But, as I said, it was a long time ago. I
wouldn't be surprised if more modern and powerful tools had become
available in the meantime.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
1706
days inactive
1706
days old
5 comments
3 participants
participants (3)
-
Allin Cottrell -
Riccardo (Jack) Lucchetti -
Sven Schreiber