Re: [Gretl-devel] basic Julia support

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).