search

franko / gsl-shell

GSL library shell based on LuaJIT2
http://franko.github.io/gsl-shell/
GNU General Public License v3.0
92 stars 12 forks source link

Using pre-compiled windows binary libraries with gsl-shell #12

Closed Gavin-Holt closed 7 years ago

Gavin-Holt commented 10 years ago

Hi,

I have been looking for a good scripting language: found Lua. Then I looked for good extensions: found gsl-shell. As a windows user gsl-shell-gui is very nice; it's great to paste code from your help pages and see it run!

My question: how can I use other Luajit compiled libraries (e.g. https://code.google.com/p/lua-files/) in scripts run by gsl-shell.exe or gsl-shell-gui.exe. I have tried putting examples in the gsl-shell folder (as indicated by the default cpath) and "requiring" them - they fail to load.

Like many "users" I do not want to invest time in learning to compile anything from source code.

I would like to be sure the environment is extendable before investing lots of time in gsl-shell.

Kind Regards

Gavin

franko commented 10 years ago

Hi Gavin,

I'm glad you found gsl shell interesting.

Talking about your question: right now I cannot ensure that gsl shell is binary compatible with luajit. The good news if that I became aware of this need from many users and the next release (2.3.1) will be binary compatible.

Otherwise, about the adoption of gsl shell, please consider that it is a small project mainly driven by a single person and it does not have the strength of other projects like scipy, Julia or GNU R. So be careful before choosing if you need to invest a lot of resources.

The strength of gsl shell is that it is based on a sound programming language, Lua, with an outstanding JIT compiler, LuaJIT2. I'm also trying to ensure a good quality of the gsl shell modules and their documentation.

Francesco

Gavin-Holt commented 10 years ago

Hi Francesco,

Sorry to repeat my question..but. I have been trying to access IUP from GSL-Shell.

It would be nice if one could just place pre-compiled DLLs in the cpath and "require". Even with DLLs from the Luajit site this fails (interestingly LFS.DLL from Lua Binaries does work!).

After scratching my head I think the problem is the way FFI works - do you have to compile your FFI interface into a specific instance of Lua(jit).exe and Lua.dll?

It appears that there are numerous Lua+ binaries, each with ONE added library (IupLua.exe, wxLua.exe, GSL-Shell.exe).

I seems a great shame that there is no intermediate that could hold the FFI code and allow any version of Lua(jit) to access the functions in a target library.

The ability to bring together access various libraries, just by copying the correct files into the path, would open up the world of Lua to many many more users.

The hurdle of learning to compile C is a step too far. This may be seen as an advantage - keeping all the idiot windows users at bay!

Kind Regards

Gavin

marcelvanherk commented 10 years ago

Hi,

The IUP Lua DLLs (found on the lua search path) loads other DLLs that therefore have to be on the !system! search path. In my project I have solved this by setting the system PATH when the application starts, as follows (this is Delphi):

SetEnvVarValue('PATH', ExtractFilePath(ParamStr(0)) + 'clibs;' + GetEnvVarValue('PATH'));

This line makes IUP work for me. Maybe it is a similar issue here.

Marcel