the following script yields a plot for which the x-range goes far beyond
2020-02-28 when using daily data. I use latest git version on Ubuntu 19.10.
set verbose off
setobs 7 2020-01-20
series a = normal()
series b = normal()
list L = dataset
# x-axis shows all the way long up to 2021
scatters L --with-lines --output=display
I am bit puzzled about the following behaviour. Even though, the sample
is restricted to "t>3" obs. only, the strvals() function returns the
distinct string-values of series x of the full data set. Is this
intended, or a bug? I use latest git version on Ubuntu 19.04.
set verbose off
nulldata 6 -p
series x = 1
smpl time > 3 --restrict
x = 2
strings names = defarray("A", "B")
eval strvals(x) # shows ["A", "B"]
smpl time > 3 --restrict
eval strvals(x) # still shows ["A", "B"]
The current macOS (1.015, Catalina) has additional security checks.
The installer gives a warning for the current gretl-2019d-quartz.pkg distribution.
Apple warns that the program cannot be run. There is however a button to open the file so it can be opened (at your own risk).
But it is not safe to assume that this will continue to be the case.
See this page: https://support.apple.com/en-gb/guide/security/welcome/1/web
As of February 2020 Apple will require that apps distributed outside of the Mac store will have to be notarized.
which most likely means that the current gretl package can't be opened and that gretl cannot be run on macOS Catalina.
Another remark: I do not know how the macOS package is created but the contents cannot be inspected by Pacifist (an app used to view the contents of a ,pkg distribution; see https://charlessoft.com). Very useful app.
for the first time I am working with gretl's ODBC connector. So far it
seems to work fine for standard queries using the Exasol data base on
linux. However, I stumbled over to 2 issues:
1) I want to write a open_odbc_connection() function. Unfortunately, the
'open' command cannot be executed within a function. For its standard
application loading a data set I fully understand the reason. However,
for just opening a ODBC connection by the '--odbc" option, I don't get
rational for this restriction.
Feature request: Allow making use of the open command in case the --odbc
option is passed.
2) While loading data through the 'data' command, e.g. by executing
<data x query="@statement" --odbc>, this command does not seem to work
in case one wants to send a 'statement' -- like "create table" or "drop
table" -- to the database which does not return a series.
Feature request: allow sending a sql-statement which does not return a
series or anything.
Maybe these points imply to add a new command or function. What do you
I'd like to raise the issue of a possible new release. The background is
the time series menu problem introduced in 2019d. (I'm not going to say
breakage because that would be too strong.) I know this does not affect
many contributed packages, but for GUI-centric usage it is still a bit
of a problem. And from experience a release is not going to happen in a
matter of days anyway.
So what is needed at this point? Some particular kind of testing to
avoid surprises like the one with VAR standard errors? (Plus the usual
translation updates I guess...)
A further update for gretl's "R_functions" apparatus: it's now
possible to traffic in gretl bundles.
* You can pass a gretl bundle as an argument to an R function; it
will be converted to an R "list", with tags corresponding to the
* You can return an R list from an R function and it will be
converted to a gretl bundle -- provided that all elements of the
list have associated tags. (Tags are optional for native R lists,
but they're not optional for conversion to a gretl bundle.)
There are certain restrictions (some of which may eventually be
relaxed). At present a gretl bundle to be passed to R can contain
only these gretl types: scalar, (real) matrix, string, array of
strings, and bundle. Similarly in the other direction: an R list to
be converted to a gretl bundle can contain only elements which
directly correspond to the gretl types just mentioned.
With current git, the command
string sep = "\"
works ok, but the conditional assignment statement
string sep = $windows ? "\" : "/"
gives an error, because the backslash is considered an escaping character.
This breaks the xy_color packages (and possibly some more).
More generally, the funny thing is that
string sep = 1 ? "/" : "\"
string sep = 0 ? "/" : "\"
both work ok, so I guess it has something to do with the parsing of the
I found out about this by chance, so I have no idea of how long this
(possible) bug has been there.
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)