this is not a new bug / odd behavior, but perhaps it's not on the radar
anymore, because it might be a Windows-only thing. It still happens
"often" (not always), that when you search for a word in the script
editor, the window content is moved such that the next match is just in
the next line below the bottom of the window, so not visible without
This is with recent snapshots and releases, and I think both on Windows
7 and 10.
Maybe tricky to fix, and of course not release-critical.
Merry post-Christmas to all ;-)
I don't know if anyone has yet tried using the new-ish facility to
build gretl on Windows, but in case anyone's interested the
have now been updated: better documentation, smarter shell scripts
and more automation.
I'm a bit confused about the situation with the package FEP (current
version). We specified no-dataset-ok and the info window of the package
(1.3) says "Data requirement: none". However, when I "execute" the
package from the listing window I get an error window "Please open data
This does not happen with other packages that don't need a dataset.
However, FEP specifies a GUI main function, and the other packages don't
seem to do that (e.g. extra.gfn, corresp.gfn), so maybe that's the
OK, I should probably explain what gave rise to the problem noted
by Ignacio in
It's to do with sending information between gretl and gretlmpi in
connection with an "mpi block" in a hansl script. Say you want to
send a matrix from gretl to gretlmpi, and get a processed matrix
back again. You can of course use mwrite() and mread(), which work
via writing and reading of files. But now, experimentally, you can
use these two functions in a special mode: if you give the matrix
filenames the suffix ".shm" we'll transfer the data via shared
memory rather than regular files. Here's a trivial example:
set verbose off
matrix m = mnormal(500,500)
if $mpirank == 0
m = mread("gmat.shm")
m *= 2
end mpi --np=4
m2 = mread("gmat2.shm")
printf "Should be zero: %g\n", maxc(maxr(abs(m2 - 2*m)))
Using ".shm" the behavior is a bit different from usual: the shared
memory block is freed on the first read (to avoid leaking memory).
Also you shouldn't give a full path for the "file", it's
automatically created under /dev/shm on Linux (or in "dotdir" on
Windows, which doesn't support POSIX shared memory).
Although this is quite cool, I'm not sure it's really worthwhile. In
my testing I'm seeing only a small speed advantage over writing the
matrix as a regular binary file, as in
But if anyone would like to test, please go ahead and tell me what
(The problem Ignacio found was due to the fact that some Linux
variants require explicit linkage to librt when using shared memory
functions while others such as Arch and Fedora do not. I was testing
on Arch and Fedora and so didn't see a problem.)
Hi, I am obtaining this errors in trying to build gretl
"Makefile:96: fallo en las instrucciones para el objetivo 'gretlcli'
make: se sale del directorio '/home/ignacio/gretlcomp/gretl/cli'
Makefile:64: fallo en las instrucciones para el objetivo 'cli'
../lib/.libs/libgretl-1.0.so: undefined reference to `shm_unlink'
../lib/.libs/libgretl-1.0.so: undefined reference to `shm_open'
collect2: error: ld returned 1 exit status"
Do you know why?
UPV/EHU Firma de email
Ignacio Díaz-Emparanza Herrero
Akademia Antolakuntza eta Graduondoko dekanorde
Vicedecano de Ordenación Académica y Postgrado
T. +34 946 013 602
Ekonomia Aplikatua III Saila (Ekonometria eta Estatistika)Departamento
de Economía Aplicada III (Econometría y Estadística)
Bizkaiko Campusa Campus de Bizkaia
Avenida lehendakari Aguirre, 83, 48015 Bilbao
T. +34 946 013 740 F. +34 946 013 754
Erne! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta
egotea. Mezuak badu bere hartzailea. Okerreko helbidera heldu bada
(helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari,
korreo honi erantzunda. Kontuz! Mezua ez bada zuretzat, ez erabili, ez
zabaldu beste inori, ez kopiatu eta ez baliatu. *E-mail hau imprimatu
baino lehen egiaztatu imprimatzeko beharra*.
¡Atención! Este mensaje contiene información privilegiada o confidencial
a la que sólo tiene derecho a acceder la persona destinataria. Si usted
lo recibe por error le agradeceríamos que no hiciera uso de la
información y que se pusiese en contacto con la o el remitente.*Antes de
imprimir este e-mail piense bien si es necesario hacerlo. *
I've been working recently on the GUI editor for graphs/plots.
Things in this department may have been a little flaky lately but I
think they have now stabilized in git and snapshots. Some aspects of
the layout of the plot-editor dialog should now be better (in
particular under the "Lines" tab, where available) and I've fixed
several bugs, one or two of which were potential crashers.
So now would be a good time to test this stuff, if anyone is so
inclined. The relevant code is fresh in my mind and any required
fixes ought to come pretty quickly.
My recent work also has implications for function-package writers
who have written, or plan to write, custom plot-generating hansl
code. The chances of having custom plots editable via the gretl GUI
-- at least in some respects -- are now better than before. I won't
burden this message with details but I'll have more to say on this
for people who use Lyx to write their papers and spread the results they
got with gretl, I found this new feature in the upcoming Lyx version
* LyX now supports insertion and automated conversion of Gnuplot
scripts, recognized by their typical extension ".gp" or ".gnuplot".
These can directly be inserted in a LyX document using the
"Insert->Graphics..." dialog, then selecting the Gnuplot script. LyX
automatically adds a proper "set terminal ..." and "set output ..."
line to convert the file to the needed output format (e.g., .eps, .pdf),
depending on whether the document is being previewed on screen or
compiled as PDF or other formats. Terminal options cannot be fine-tuned
at the moment, but that's a capability that may come soon, also
according to the received feedback from users.
So in the future you might produce the gnuplot plots with gretl, and
then you might be able to apply small edits directly within your Lyx
document, instead of having to go back to gretl/gnuplot just for some
cosmetic stuff. Let's see how well this works in practice!
Here's a follow-up to
Some package-writers (and maybe others) have written hansl code to
generate custom plots that are difficult or impossible to obtain
via the built-in "gnuplot" and "plot" commands.
Gretl can _display_ any such plot provided the generated gnuplot
script is valid, but offering GUI editing (e.g. via right-click on a
plot window) is trickier. We can offer the editing facility -- with
a reasonable chance that this doesn't reduce the plot to rubble --
only if gretl "understands what's going on" in the plot (that is, if
we're able to parse enough information out of the plot commands to
make sense of it).
There's no way that gretl is going to incorporate a fully-fledged
gnuplot parser but some of my recent changes make the parsing
somewhat more flexible, hence increasing the chances that a custom
plot can be handled in the GUI plot editor. So I'd like to invite
authors of custom plotting code to try this out: Is your custom plot
now (nominally) editable? (That is, does the "Edit" option appear on
right-click?) And if so, does it actually work or does making
changes destroy the plot?
For anyone interested in pursuing this, here are a few pointers.
1) Take a look at the gretl-generated gnuplot code for a variety of
plot types, to get a sense of the "house style" which is likely to
2) If C doesn't scare you away, maybe look at some of the functions
in gui2/gpt_control.c, in particular parse_gp_line_line() and
parse_gp_set_line(). In such functions you see gretl trying to make
sense of core gnuplot commands -- that should give you a more
precise idea of what formulations we can handle (and by elimination,
what we're not ready to handle).
3) If your plot contains formulations that gretl cannot handle
natively, try protecting them by placing them within the following
two special comment lines in the gnuplot file:
# start literal lines
# end literal lines
That way gretl will know not to mess with them.
It is currently not possible to evaluate if an array of matrices is equal to null or not. Here is an example code snippet. For the list this works fine, for the matrices it doesn't.
matrices ttt = null
list lll = null
I came upon this when trying to set up a function with the following head (data can be passed as series' or 2d-matrices (x,y) ):
function bundle series_to_bundle(list ls[null], series obskey[null], matrices ms[null])
#transform series in bundle of two matrices, the key and the data