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.
A user asked me about possible problems with our TRAMO/SEATS and X13
addons under recent OSX versions. He sent me this link:
If my understanding is correct, newer OSX versions will not run 32-bit
programs. Does this affect us?
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
since summer we can access a package's version:
pkg query extra --quiet
However, as a package developer I also would like to check a user's
install gretl version. Maybe this information could be added to the
$sysinfo-bundle -- of course if not too difficult to do so.
more on the issue of effects of (openblas?) multithreading, but this
time unrelated to MPI. Possibly some pretty large potential gains here,
if my results are correct.
I'm attaching my test script which I ran with yesterday's snapshot on
the following machine specs:
nproc = 4
blascore = "Sandybridge"
os = "windows"
blas = "openblas"
omp_num_threads = 4
ncores = 4
omp = 1
blas_parallel = "OpenMP"
I varied the environment variables OMP_NUM_THREADS and OPENBLAS_NUM_THREADS:
OMP... OPENBLAS... best of 3 runs
<unset/default> <unset/default> 6.4 s
4 4 6.4 s
4 1 6.4 s
1 4 2.9 s
1 1 2.9 s
So the OPENBLAS... settings are irrelevant, but using only a single OMP
thread is twice as fast than gretl's default setting!
(In the script you see that the matrix dimensions are 200x10 and 200x80.)
I guess the underlying Cholesky routine should be checked as well as the
possible root cause.
for some function packages (or addons, like SVAR) it would be useful if
more than one function could be integrated more tightly for GUI usage.
Here's a concrete suggestion that perhaps wouldn't be so difficult to
implement. I'm thinking about an analogue of the current bundle-plot
- add a new "bundle-action" element to the spec file of a function
package which points to another public function of the package
- just like bundle-plot, the corresponding bundle-action function must
take an integer argument with appropriate labels, corresponding to the
menu entries that are created; and of course also takes the bundle
(pointer) as another argument
- Depending on the input value of that integer argument, the designated
bundle-action function would call other functions of the package as
appropriate: in the GUI such a call should lead to a new window being
opened for inputting its argument values, (almost) as if that other
function had been called right at the beginning. The only difference
would be the bundle that presumably would always be implicit in the
call; that could perhaps be omitted from this call window, or could be
greyed out or whatever.
I hope that was a clear explanation of what I have in mind.
I'm currently trying out gretl on a Ubuntu 19.10 installation serving
the screen via Broadway (browser-based).
I see many icon warnings like this:
(gretl_x11:1191): Gtk-WARNING **: 21:28:23.825: Error loading theme icon
'help-about' for stock: Icon 'help-about' not present in theme Yaru
This is gtk3, obviously. I've seen such warnings and the missing icons
on the experimental Windows builds, but not on Linux so far (I think).
Not sure whether that's something gretl itself can solve.
For anyone building gretl on MS Windows: I've added an MSYS2
dependency, namely mingw-w64-x86_64-dlfcn (or mingw-w64-i686-dlfcn for
a 32-bit build).
This contains libdl.dll -- a small library that adds POSIX
functionality for loading and querying modules, which is useful for
libgretl in figuring out what blas/lapack variant we're looking at.
The files pkglist.txt and pkglist32.txt at
are updated accordingly.
the following is of course a gray-area fringe case, but since we have
always agreed that gretl shouldn't crash, here it is:
set R_functions on
series x = 1
foreign language=R --send-data
crash <- function() return(dim(gretldata))
This is with the snapshot from last week.