Open sonoro1234 opened 9 months ago
The way to go instead of creating a new repo (as lgsl does) to avoid diverging from gsl-shell would be to set some variables to control the running process:
If any script being able to run in gsl-shell does define EXEFILE
and thenrequire"start"
I am able to run until gsl.lua
is required. At this point the C functions are loaded from the executable (return ffi.C) instead to being loaded from a C module (as done in previous gsl-shell versions). This could be fixed by using return ffi.load('libgsl-0')
and having the dll in the directory (from a previous version as I havent tried to compile it)
The next issue is more problematic because in linfit_rank.lua:50 there is local V1t = matrix.new(r, n, |i,j| V:get(j, i))
which uses gsl-shell function notation that should be converted to standard Lua notation.
I dont know if I would find more issues later but first I would like to know if you would be interested in this at all.
Hi Victor,
your suggestions are all fine. In principle I wanted to remove all the "short syntax notation" from the implementation files and the remaining places are easily found and fixed.
On the other side I have little spare time in this moment and I am working on other projects.
If you feel to make some PR I will be glad to review them.
Hi Franco,
I was interested in 2012 and I am still interested in being able to use gsl as a module that can be loaded in LuaJIT (with require"gsl") Is this now posible? I saw lgsl but seems abandoned
Best Regards Victor Bombi