On Sat, 23 Jan 2016, Andreas Noack wrote:
> In fact, I'm beginning to thing that we ought to provide a
Julia package
> ("GretlLink"?) on
pkg.julialang.org for communication with gretl with
> functions such as the above and more, ideally written by a specialist
> (Andreas, are you interested?). So in practice, a "using GretlLink"
> statement would be implicit every time we enter a "foreign" environment,
> possibly preceded by a 'Pkg.Add("GretlLink")' if necessary.
I'd like to help here, but I'm also bit swamped. I'm pretty up to date on
the Julia side, but I'm not sure what it would take to make a good foreign
environment in Gretl. If either of you can explain what is supposed to
happen on the Julia side then I can probably do it without too much
difficulty.
Thanks, Andreas. Here's a simble example that illustrates what we
have at present in terms of "foreign" support for julia:
<hansl>
open longley.gdt -q
list LX = prdefl .. year
mwrite({employ}, "y.mat", 1)
mwrite({const} ~ {LX}, "X.mat", 1)
foreign language=julia
using MultivariateStats
y = gretl_loadmat("y.mat", true)
X = gretl_loadmat("X.mat", true)
b = llsq(X, y; bias=false)
gretl_export(b, "jl_b.mat", true)
end foreign
matrix jl_b = mread("jl_b.mat", 1)
print jl_b
</hansl>
If you run this using current gretl from git you'll find that it
writes out two files in your "dotdir" (~/.gretl on *nix), namely the
generic utility file gretl_io.jl and the specific script file
gretltmp.jl. If you could take a look at those and suggest
improvements that would be very helpful.
One other thing that occurs to me: at present we call the julia
binary to execute gretltmp.jl, but I wonder if there's a substantial
advantage in linking to libjulia (well, probably dlopen'ing it) and
injecting the julia code (an approach we use with libR if it's
available).
Allin