I'm currently using the rust-lua53 crate to embed Lua into a Rust project. rust-lua53 downloads and builds the Lua tarball during "cargo build" (in its build.rs).
I'd like to make other Lua libraries (written in C) available to Lua code in my application, eg LPeg or LFS, but it's not obvious to me how to do it.
My ideas so far are:
Build the libraries against a stock Lua and hope I get away with it (or have to check it matches every subsequent rust-lua53 release)
Somehow expose the relevant headers from rust-lua53 (can a crate include extra files like that?)
Change to a different Rust/Lua binding which somehow makes this easier.
Fork rust-lua53 and make it embed the extra libraries I want as well as the plain Lua interpreter.
Implement the functionality in Rust instead of relying on C libraries. Plausible for LFS in my application, but re-implementing LPeg is beyond what I want to do right now!
Related
Luarocks wont work on fibaro, so im removing this
As Egor suggested, Fibaro sandboxes their Lua environment. A full list of what is removed is listed at https://manuals.fibaro.com/knowledge-base-browse/blocked-lua-commands/, but it includes require, dofile, load, loadfile, loadstring, several functions in the os library, and the entire io and package library.
That effectively requires all of your code to be contained in a single file, with no access to modules, packages, or libraries other than the remaining parts of the standard library, which means you simply can't do what you're trying to do here.
In perl5 it was easy to link in libperl.so, set some variables and run some code, with callbacks. Is there a story for doing this in perl6?
I think you can find the state of the art in that respect at https://metacpan.org/pod/Inline::Perl6 , which embeds Rakudo in Perl 5.
Besides what #elizabeth-mattijsen has commented, no, there's no such thing. While the perl interpreter was a monolithic thing which might be relatively easily turned into a .so library and then linked with some API endpoints, Perl 6 is two big things: a virtual machine, either Java or MoarVM, plus the interpreter, Rakudo. There could be an scenario in which you wouldn't need to embed Java or MoarVM, because both languages would be running in the same VM. Think Perl 6 embedded in Clojure, for instance. Or Perl6 embedded in 007, both running in MoarVM. That would be kind of easy, and you would be targeting a VM with the same capabilities. But C++, C and Perl6 have a very different abstract virtual machine as a target; think about the Unicode handling, or the concurrent interface. Embedding Perl6 in C would be basically running Perl6 programs from C, instead of running them from the command line.
It is possible that, in the same way Perl regexes ended all over the place, some Perl 6 capabilities, like Unicode handling or grammars, could end up ported or embedded in other languages. But I don't see a clear use case for embedding Perl in C or C++, right now, and devoting some effort for that kind of thing would be, thus, better employed in something completely different.
This isn't an answer, but suppose I've got an already existing C program which is designed to use plugins which are .dlls or .sos, and they get loaded via dlopen or LoadLibrary, an API entry point is found using dlsym or GetProcAddress, then that entry point is called with some sort of handle for the plugin to make calls back into the main process.
Now, suppose I want my plugin (inside of this .dll or .so) to load moarvm, and then run some perl6 script, which in turn uses NativeCall to call back into the main process. How would I go about doing this?
Alternatively, suppose I want my plugin (inside of this .dll or .so) to load the jvm, then run some perl6 script, etc. How would I go about doing this?
Loading perl5 just to load perl6 seems like a silly solution. It might work, but...
I'm working with ESP8266 and I don't want to use Lua for the whole project, I just want to run a few snippets of Lua code, received from wifi/sd card. I'd need to start a Lua environment and run the scripts, which would then eventually call some native functions for low level tasks. In other words, I just want to use Lua as simple scripting language (as it's intended to be) to implement some dynamic behavior. Is it possible? Is there any build of lualib for arduino?
Thanks in advance!
You can simply embed Lua in a extlibs/ folder for example and link to it when compiling your program.
There is existing Lua binaries but building it yourself is easy and better (as it's multiplatform).
OK, I know both answers told me I can just embed the code into my project, however, I found out I need to make some small changes. I made an example working project available here and the following list of changes had to be made:
The flags LUA_32BITS and LUA_USE_LONGJMP (C exception handling) were enabled
The following libraries were excluded: io, os, package, coroutine
The following functions were removed from C API: luaL_fileresult, luaL_execresult, luaL_loadfile, luaL_loadfilex, luaL_dofile, luaB_loadfile, luaB_dofile
Lua output messages are redirected to the Serial interface, check tinylua.h, tinylua.cpp and lauxlib.h to change this behavior
Hope this helps!
The ESP8266 has up to 4MB of program storage. Theoretically you can get up to 16MB as the datasheet specifies.
As I remember, compiling an amalgamated version of Lua (all sources in one file), occupies less than 100kb.
So, you can compile the Lua library and use it as needed on esp8266, even using Arduino IDE.
But you will get NAKED Lua if you do so... No nifty libraries to control Wifi, serial, SD, ports... You would have to provide that in C, or use NodeMCU code as you need.
You can try LuaJIT and access C code directly from Lua, cutting out the need for writing libraries. I have no idea of how you would compile it to Esp8266, or if anyone have tried this before, but you can do it "for science" and tell us how it turned out.
I'm trying to use the luafun library with love2d.
Running lua main.lua, however love . complains about the missing fun library.
I have installed luafun with luarocks.
There's two options.
If you want to distribute whatever you're building, you almost certainly don't want users to install Lua, luarocks, etc. etc. - so the best way is to simply put any libraries into the folder that your game/program/… lives in. (If a library contains compiled things, you'll need to build per platform/OS and then you'll actually want a build process that spits out the various variants, but if it's all-Lua, there's no platform-specific stuff, so just copy it in.)
The other option (mostly for when you only need it to work on your machine) is to adjust package.path and then love will find things just fine. If you use LUA_INIT / LUA_PATH on your machine, Love ignores them but you can manually fetch & process them using os.getenv, dofile / load(code)() & friends. (As the very simplest special case of this, if luarocks is installed in the standard Lua search path, saying require "luarocks.loader" might be enough to get all luarocks-installed packages to work.)
I got code::blocks as my C/C++ compiler along with C++ for dummies, but my only problem is with a obscure scripting language that I have never heard of before; "Squirrel". Is it possible to change the scripting language of code::blocks to something more familiar to me, like lua?
It seems doable in theory. Whether it is doable in practice, hard to say. Here is what you would need to do:
create a folder src/sdk/scripting/lua in which you put the Lua interpreter (+ Lua libraries like io, math etc) source code and create project file for it
create a folder in src/sdk/scripting/lua_bindings where you put your Lua bindings: the C++ files that allow Lua scripts access to the host application. I recommend you use a tool like SWIG to generate them (codeblocks uses SqPlus). This involves determining what code-blocks functions/classes you want to export, creating one or more .i files, running SWIG on them, put the generated files going into "lua_bindings"; create a DLL project for the bindings
Create a src/lua_scripts in which you put the Lua equivalent of scripts found in src/scripts; or rather, a subset of those scripts, because it is unlikely you will want to export to Lua everything that is available via Squirrel if you're just following examples from a book
Find where Squirrel interpreter is instantiated in codeblocks and where RegisterBindings is called; replace it with instantiation of a Lua interpreter and call your luaopen_codeblocks which you will have created via SWIG (no need for a RegisterLuaBindings if you use SWIG, it does that for you)
Find where the various scripts are called by codeblocks (see http://wiki.codeblocks.org/index.php?title=Scripting_Code::Blocks). Call the equivalent Lua scripts (which are in lua_scripts -- you'll surely have to copy this to the installation folder for code-blocks). For example the startup.script, which is the Squirrel script that codeblocks automatically looks for at startup, is run by the following code in src/src/app.cpp:
// run startup script
try
{
wxString startup = ConfigManager::LocateDataFile(_T("startup.script"), sdScriptsUser | sdScriptsGlobal);
if (!startup.IsEmpty())
Manager::Get()->GetScriptingManager()->LoadScript(startup);
}
catch (SquirrelError& exception)
{
Manager::Get()->GetScriptingManager()->DisplayErrors(&exception);
}
I think that's about it.
Naturally based on how extensive your scripting is, you may cut some corners, but as you can see, this is not for the faint of heart!