Hello gretl devs,
I am using the clipboarder windows app (http://nes.bplaced.net/clipboarder.html) which enables one to copy & paste many items in a row more fast. However, for reasons I do not know, this does not work stable with gretl. Whenever I "switch" the content currently in the clipboard with this tool, I can paste the content sometimes, but not always. If I remember correctly, I had similar issues without clipboarder (and former versions of gretl!) before.
I've noticed a strange behavior that appears to concern the exists()
If I run the following code repeatedly (by clicking run in the script
matrix not_existing_yet = exists(not_existing_yet) ? \
(not_existing_yet ~ I(2)) : I(2)
...what happens is that every second time it runs as expected, and every
other time it produces the error "symbol 'not_existing_yet' undefined"
(re-translated). But this error only happens after two loop iterations
(i.e. I see "i = 2" in the output).
Fairly recent snapshot on Windows.
When I click on /Help/Command reference I am obtaining this error:
Falló al abrir el archivo «/opt/gretl/share/gretl/gretl_gui_cmdref.en»:
No existe el archivo o el directorio
and the same for /Help/function reference
(gretl from git, downloaded and built today, on Ubuntu 16.04)
Departamento de Economía Aplicada III (Econometría y Estadística)
Universidad del País Vasco - Euskalherriko Unibertsitatea, UPV/EHU
Tfno: (+34) 94 601 3732
This relates to Sven's posting at
I'm working on getting the "member-of" relation to recurse, as it
ideally should, in "genr" expressions. The simpler task is to get
this right on the right-hand side of an assignment, and I think I've
made some progress. Here's an example of a script that would not
have (fully) worked before, but now should, in git:
matrices M = array(1)
M = seq(1,3)
# array -> matrix -> element
b.mat = seq(1,3)
# bundle -> matrix -> submatrix
bundles B = defarray(b)
# array -> bundle -> matrix: OK
# array -> bundle -> matrix -> element
c.B = B
# bundle -> array -> bundle -> matrix -> submatrix
It would be good to have the same sort of thing working on the
left-hand side (assignment to an arbitrarily nested member of a
compound object). We're not there yet but I'm hopeful... Stay tuned.
I am playing around with the fcast command. I am wondering why I can't
provide the no. of steps-ahead by the scalar "k" in the example below.
This would be very helpful when writing functions.
set verbose off
open denmark.gdt -q
series gM = diff(LRM)
ols gM 0 gM(-1) -q
fcast 1985:1 1987:3 1 --rolling
# Does not work
scalar k = 1
fcast 1985:1 1987:3 k --rolling
I want to raise a "policy question". Currently contributed function
packages can decide "for themselves" whether they want to be added
somewhere in the gretl menus. IIRC this was borrowed from the gretl add-ons.
For the outsider/user this blurs the distinction between core gretl and
the contributions, which is exactly the purpose of the mechanism.
However, there is a difference in the amount of testing that goes into a
functionality in core gretl compared to the testing that a function
package receives. (I'm talking about the testing done by the code
authors, not about the quite superficial checks that Allin, Jack, and I
are doing when moving a submitted package to the public server. And I am
also talking about packages written by myself, this is not meant as
So the problem is that to the user package bugs would look like gretl
bugs, which makes gretl look less reliable than it is.
My first suggestion therefore is to include the "author" field not only
in the package list in the "on server" window, but also in the list
window displaying the locally installed packages. This should make it
more transparent that these are _contributed_ packages, and not core
gretl. (Also the ego of the authors might benefit a little.)
Secondly, my proposal is that before a package is allowed to appear in
the menus it would need to pass some additional checks. For example,
this check could be provided by replicating in the example script some
BTW, there is a real-world experience behind my suggestion. Of course
this policy change would not prevent all bugs; for example I remember a
bug affecting (some) results in the SVAR addon, and that addon was
certainly tested quite thoroughly. But still I think it could help.
So -- what do you think?
allow me to open a new thread for the shell command launching stuff here.
I'm following Allin's advice to use "start gretlcli" to background the
gretlcli process on Windows. The problem I'm facing right now (with the
latest snapshot) is that when I do (in the Windows cmd.exe console):
gretlcli.exe -b hansltemp.inp > testy.out
I get a good testy.out file written. However, when I do:
start gretlcli.exe -b hansltemp.inp > testy.out
The testy.out file gets overwritten as expected, but it is empty (0
bytes). I know this might be a Windows issue instead of a gretl issue,
but perhaps somebody has an idea about what's going on nevertheless.
(I also have a totally different issue with a silently failing bread()
function in a loop which somehow ignores part of the bundle contents,
but I leave that for later...)
This relates to the thread started By Sven in
but I think it merits a thread of its own.
When working up an MPI-based variant of the task Sven's talking
about (launching a bunch of parallel processes, each of which
carries out the same basic computation but with a process-specific
set of parameter values) I noticed something that's a little
awkward. Namely, for almost everything that's indexable in hansl,
the index starts at 1, but with MPI we've carried over the
underlying MPI specification in which the indexation of processes
starts at 0 (so n parallel processes have IDs 0 to n-1).
So long as what's in place is clearly documented (and I think it
is), a hansl coder should be able to handle this without huge
difficulty. Nonetheless I wonder if we'd be better to identify MPI
processes in hansl using a 1-based index. This would be easy to
arrange, but would be backward-incompatible. Which leads to two
1) Does anyone at this point have an investment in gretl-MPI scripts
that use 0-based process IDs? (I suspect not, but maybe I'm wrong.)
2) If backward-compatibility turns out not to be a serious issue, do
we think it's worthwhile to switch to 1-based MPI process IDs?
would it be too difficult (or have unwanted side effects) to enable
several 'set' instructions on a single line, as in:
"set echo off, messages off" ?
Obviously you will like this only if you share my preference for less
lines of code instead of more...