latex required for building addons (even though no --enable-build-doc)
by Sven Schreiber
Hi again,
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-recommended, texlive-fonts-recommended,
texlive-latex-extra just because of that, which is easily 1GB in size.
thanks,
sven
5 years, 2 months
Bug with saving files
by Marcin Błażejowski
Hi,
let start fresh gretl, define "New data set" as whatever and try to save
as gdt: gretl crashes and gdb says: "/usr/local/bin/gretl_x11: symbol
lookup error: /usr/local/bin/gretl_x11: undefined symbol:
dataset_is_subsampled".
Marcin
--
Marcin Błażejowski
5 years, 4 months
CRASH: 'fcast' after 'var'
by Artur Tarassow
Hi all,
using yesterday's git on linux 19.04, I get the following error when
running the example below:
<[1] 20632 segmentation fault (core dumped) gretl>
<hansl>
clear
open denmark.gdt
list y = LRM
list xlist = LRY
var 7 y # you could also add
xlist; also for 2-d VAR(p)
fcast --out-of-sample # crashes
#fcast --dynamic --out-of-sample # also crashes
</hansl>
Best,
Artur
5 years, 4 months
dbnomics error
by Sven Schreiber
Hi,
I got this error when trying to fetch something from the Belgian central
bank via the dbnomics add-on:
Datentypen nicht passend bei Operation [datatypes not matched]
*** error within loop in function fix_dimensions_bundle
> b.value_label = dvl[key][value]
called by function process_series_bundle
*** error in function process_series_bundle, line 38
> fix_dimensions_bundle(json, &b)
called by function dbnomics_get_series
This is gretl 2019b and dbnomics add-on 0.33.
thanks
sven
5 years, 4 months
The post-conference GUI arrangement thread
by Sven Schreiber
Hello everybody,
at the conference we decided that we should collect all ideas on a GUI
reform (different window arrangements) in one thread. I thought I'd
start this thread here. Please contribute to the brainstorming, ideally
by naming examples and/or giving links.
1) Have a window a bit like Stata where output goes in one area, you
type commands in another one, and there's a command log (and I'm not
sure what else right now). However, I think Stata also sometimes opens
extra windows.
1b) RStudio: I've named this 1b instead of an extra number, because it
seems this is somewhat similar to the Stata window. Please correct me if
this is inaccurate, and/or explain the differences (pros and cons).
2) Have one big meta window that acts a little lig a virtual desktop
just for gretl. All newly opened gretl windows would go into the meta
window, no extra window outside the meta window would ever show up. The
role model for this would be Eviews.
Feel free to add suggestions, this is a brainstorming thread.
Have a good weekend
Sven
5 years, 4 months
Datatypes of json items
by Artur Tarassow
Dear all,
I hope you had a successful gretl conference in Naples!
I am currently working with json files again. Using latest git version
of gretl on Ubuntu linux (even though the behavior also occurs for older
versions), I've found that some of the json-elements grabbed are not of
the expected datatype. See the the following example and the file attached:
<hansl>
string PATH2JSON = "/home/at/tmp/" # set your path
string jsonfile = sprintf("%s/ex_json_num_vector.json", PATH2JSON)
string jread = readfile("@jsonfile")
bundle B = jsongetb(jread)
b = B.JSON
# Evaluate type of elements
#-----------------------------------------------------
# Item Expected Is
# v1 string null
# v2 string array string array
# v3 scalar scalar
# v4 matrix string array
loop i=1..nelem(b) -q
string str = "v$i"
eval b["@str"]
eval typestr(typeof(b["@str"]))
print ""
endloop
</hansl>
Is there a rational reason for this behavior?
Best,
Artur
5 years, 4 months
Incrementing using the '++' operator
by Artur Tarassow
Hi all,
I really like the C-style if-else syntax as well as the C-style '++' and
'--' operators for incrementing and decrementing a number, respectively.
But I am surprised to see that the following does not work:
<hansl>
scalar s = 0
loop i=1..2 -q
catch s = (i==1) ? 1 : +1 # no effect
s
catch s = (i==1) ? 1 : s++ # no effect
s
catch s = (i==1) ? 1 : s+1 # works as intended
s
endloop
</hansl>
Why is the 2nd approach not working here?
Thanks,
Artur
5 years, 4 months
Feature request: vertical line for 'suggested' line length
by Artur Tarassow
Dear all,
from time to time I use the IntelliJ IDEA editor which has an option to
assist the user to follow the PEP8 Python coding guidelines. A tiny but
helpful feature is the vertical line in the editor indicating the
suggested maximum line length (which is 79 characters). I think also the
Matlab editor has a similar indicator line. I find this quite useful for
improving code readability. What do you think?
Best,
Artur
5 years, 5 months
Question on data-types
by Artur Tarassow
Dear all,
I've stumbled about the following behavior (this is on latest git using
linux) where I was wondered about the 'null' type returns.
Is this really intended, and if so why?
<hansl>
string str = "foo"
eval typestr(typeof(str)) # is 'sring'
strings S = null
S += "foo"
eval typestr(typeof(S)) # is array
eval typestr(typeof(S[1])) # is 'null'
bundle b = null
string b.str = "foo"
string b.S = "foo"
eval typestr(typeof(b.str)) # is 'null' type
eval typestr(typeof(b["S"])) # is 'null' type
</hansl>
Best,
Artur
5 years, 5 months
Handling of translated strings (argument labels) for function packages
by Sven Schreiber
Hi,
since we're going to meet up at the conference in two days, we don't
have to discuss this here on the list, but I thought I'll describe and
document the proposal anyway.
The situation: When you execute a function package in the GUI, in the
window where you enter the function arguments, the descriptive labels
for the arguments sometimes come up translated to the local language,
even though the package itself "only" has English labels (as it should).
AFAIK this happens when gretl recognizes the label string as something
where there's already a translation present from another context.
(This already presupposes two things: First you're running gretl in
non-English, secondly the function package author has actually added
labels to the function arguments, which is optional.)
The automatic translation has pros and cons. Pros: You get it for free
and it's good for users who don't know enough English. Cons: Most of the
times the result is a mish-mash of English and the local language, so
the question is if it actually helps enough to be valuable in practice.
The suggestion: First of all, the translation is not predictable for me
as a package author. I think we need a clear "lexicon" of labels that
will be translated. Next, I think a package author should be given
control over whether anything is translated. For some packages it's
probably better to keep them English only; for example given the fact
that the output is never going to be translated (and we actually made it
a policy to not include other languages in public packages, which had
caused some disagreement).
Perhaps the translation control might be as simple as telling the
author: If you don't want it translated, add a blank at the start or at
the end of your label. (?) More sophisticated solutions of course also
exist.
So much for the idea; as I said, perhaps we want to discuss it at the
conference. OTOH not everybody will be there.
cheers
sven
5 years, 5 months
