progress bar error on Windows with 'pkg install'
by Sven Schreiber
Hi,
when doing 'pkg install johansensmall' on Windows 10 with gretl 2019c
I'm getting an error window complaining about:
gretl\plugins\progress_bar.dll
error 0x0000045
(plus more text)
The install then seems to proceed normally, however.
cheers
sven
6 years
new outfile option --tempfile
by Allin Cottrell
I've noticed that some function packages make use of "home-made"
functions to create a temporary file in the user's dotdir. These
probably work fine in most cases, but they're not safe against race
conditions and I thought we should have a "proper" way of doing the
job.
That's now provided by outfile. You say
outfile foo --tempfile
where "foo" is either the name of an existing string variable or a
valid hansl identifier that's not yet used for any object.
The outcome is that a file is created in dotdir using the safe
C-library function mkstemp(), and its name is written into foo
(which is created if it doesn't already exist).
<hansl>
string foo # declaration optional
outfile foo --tempfile
# do stuff ...
end outfile
printf "Output went to %s\n", foo
printf "Content is\n%s\n", readfile(foo)
</hansl>
Allin
6 years
MPI issue
by Marcin Błażejowski
Hi,
what such an error means (haavelmo machine, MPI in 20 threads):
#########################################
get_gretl_charset: using UTF-8
Writing 106 Kbytes of data
deserialize bundle: bundle is broken (err = 2)
gretlmpi: error executing script: halting
> MODEL = bread("MODEL")
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 7 in communicator MPI_COMM_WORLD
with errorcode 1.
NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
gretlmpi: child process exited abnormally
#########################################
It happens at start of MPI. All threads should read the same bundle from
disk. On my computer (4 cores) it happens too, but rarelly.
Regards,
Marcin
--
Marcin Błażejowski
6 years
Last Trade on yahoo_get.gfn
by leonardosuarezromero＠gmail.com
Hi everyone
I'm have been using the yahoo_get.gfn function since a while but I have noticed that the last trading day value is always empty, this results to be really annoying as it results to be the most important value to do forecasting. Anyone knows the reason and how to solve it?
Kind regards
6 years
Windows and gtk3
by Sven Schreiber
Hi,
this is a message and suggestion without any urgency, just picking up
bits and pieces from various years (!).
I think it would be good to move the Windows version of gretl to using
gtk3 instead of gtk2, at least as an option, if at all technically
possible. First of all I would hope that it gets a more "modern" look
automatically through that. Secondly it would be really cool to run
gretl in a browser window, as discussed on this list in March ("GTK
broadway support in gretl?"), and already back in 2014.
Some more background: Six years ago Allin announced ("gtk version in
gretl build" in October 2013) that on Linux gtk3 was the preferred
framework. Later after version 2017d it was made easier to build gretl
on Windows, as I tested myself back then. (BTW, the build appendix C of
the guide still does not mention documents like
http://ricardo.ecn.wfu.edu/pub/gretl/winbuild/gretl-winbuild.pdf.) That
Windows build document does not really mention the assumed GTK version,
but the underlying package list
http://ricardo.ecn.wfu.edu/pub/gretl/winbuild/pkglist.txt is only made
for gtk2 (for example with mingw-w64-x86_64-gtk2).
Are there any known problems wih gtk3 on Windows that have been observed
after, say, after 2017? If not I'd like to try this eventually, after
the summer.
thanks
sven
6 years
some devel news: using function pointers
by Allin Cottrell
Here's something I've been working on lately. tl;dr: gretl has just
become substantially more efficient in respect of basic functions
applied to each element of a big matrix or series. If you'd like the
full story, read on.
By "basic functions" I mean those that take a single floating-point
value as argument and return a floating-point value, such as log,
exp, fabs, all the C-library trigonometric functions, and a bunch of
libgretl functions such as cnorm, dnorm, round, etc.
Suppose you want to apply such functions to a big matrix. You can of
course do that in hansl -- as in "matrix logM = log(M)" for a matrix
M -- but what's going on in the background? (The C library has no
"matrix" type and its log function applies strictly to single
numeric values, with the sole exception of complex numbers if we
consider those pairs as "not single").
We have to do the following (in pseudo-code):
for each element x = M(i,j) of original matrix M
apply function f to x and get result y
set element R(i,j) of result matrix R to y
end
The question is, how do we implement the "apply function f" part?
That is, how is "function f" identified? If it were identified by
name ("log", "sin" and so on) we'd have to look up the function by
name on each iteration of the loop. That's possible under POSIX but
not, in general, on MS Windows (or not without severe contortions),
and it would be horribly inefficient.
Up till now we've identified f using a fixed ID number, associated
with the name of the function via a look-up table. And the inner
"apply" bit included a loop across these IDs. So, for example, if
"log" mapped to ID 287 and "exp" to 288, that loop would include
lines resembling
if (f == 287) return log(x);
if (f == 288) return exp(x);
along with many other clauses of the same sort.
That's much better than look-up by name, but gretl still has to wade
through a bunch of "if (f == ID)" clauses to find what should be
done per element of the matrix (or entry in the series).
Solution: Instead of making "f" a symbolic ID of any sort that has
to be looked up, make it an actual pointer-to-function (the memory
address at which the function can be found). That's what we now do
for such functions.
In my experiments this reduces the time taken for scripts that are
heavy on calls to "basic functions", as defined above, by roughly 25
to 45 percent. Artificial example:
<hansl>
matrix m = muniform(50, 50)
set stopwatch
loop 5000 -q
res = log(m)
res = exp(m)
res = sqrt(m)
endloop
printf "elapsed: %gs\n", $stopwatch
</hansl>
In current git you can turn off the use of function pointers, to
compare with old-style behavior, by commenting out line 1340 of
lib/src/gensyntax.c (with comment "attach function pointer, if
available").
Allin
6 years
Accessing a package's version
by Artur Tarassow
Hi all,
Since gretl supports the idea of package dependencies now, I think it's
useful to add an accessor to a package's version for checking that the
required version is actually installed on the system.
In python one has those magic methods of which one is
PACKAGE.__version__. Do we have such an accessor available in gretl?
Given that it exists in the spec-file it should be possible to grab it,
or not?
Thanks,
Artur
6 years
