I'm noticing that I cannot build from git without having a Latex
installation, when I want to also build the addons. In other words, the
regular gretl build skips Latex and pdf creation when the configure
option --enable-build-doc is _not_ given, but using
--enable-build-addons fails without Latex.
Not a big deal of course, but on a Debian test system I had to pull in
texlive-latex-extra just because of that, which is easily 1GB in size.
the following isn't new, and maybe we discussed it already:
function void checkl(list L)
L -= const time
list L print
list myL = time
checkl(myL) # still shows time
Note that outside of a function it works.
Thanks Peter for confirming the test message - I'm resending a message
that didn't get through yesterday:
shouldn't the following work?:
eval (LRY .< 10) * IBO
Geting "matrix not conformable" error.
What works is this two-line approach:
series s = (LRY .< 10)
eval s * IBO
I see in the GUI (2019a) and in the DTD for the package file format that
the new deep dependence idea between packages has arrived. My question:
For packaging the gfn on the CLI with a spec file, is it enough to put a
line like "provider = thatotherpackage" in the spec file?
I just (re-) learned that I cannot stuff an anonymous series into a
list, as in:
list L += abs(myseries)
And I understand why. However, the error message I get is something like
"incompatible types in list += series", and since the right-hand side is
a series alright, I think the message is not quite correct.
But another very minor issue, of course.
this is about the issue of having more than one menu entry for a
function package, or (related but slightly different) having one menu
entry but wanting to offer two or more GUI interfaces when calling the
package from the package listing window.
(Currently, if I'm not very much mistaken, either a package has no
gui-main function and thus no menu entry either, and then all public
functions are offered for a choice in the GUI; or when there's a
gui-main function as required for a menu entry, then the other public
functions are scripting-only.)
The whole thought is prompted by the renewed demand for a SVEC(M) GUI
access with the SVAR addon. Extending the current SVAR GUI would not be
good because it is already a little overloaded.
I see two solutions:
1: Using the fact that recently function packages can depend on each
other, simply introduce a formally separate package, say guiSVEC, which
gets its own menu entry and a single public function. When called and
executed, it pulls in the SVAR addon on which it depends, and calls the
appropriate functions from SVAR in the background.
This solution wouldn't require changes in core gretl, AFAICS.
2: Extend gretl's function package apparatus by allowing designated
gui-2, gui-3 etc. public functions with corresponding menu-attachment-2
Not sure how disruptive such a change would be.
What do you think?
this is of course a luxury request: I've just been reminded that gretl
prompts me for a restart when a new example dataset collection (e.g.
POE4data) is loaded from the server. Is this really necessary nowadays?
I mean compared to the situation with dbnomics, for example, where it's