To simplify things, let's assume, that there are two Lua scripts, one program and one module, e.g:
sample.lua
local sample = {}
sample.fun1 = function()
end;
return sample;
I'm using it in program, like this:
program.lua
local sample = require("sample");
sample.fun1();
And now i'm trying to use the same module in C (first running lua program, what is important here), something like this:
luaL_dofile(luaState, "program.lua");
...
lua_getglobal(luaState, "sample");
lua_getfield(luaState,-1, "fun1");
or
luaL_dofile(luaState, "program.lua");
...
lua_getglobal(luaState, "sample.fun1");
But both versions causing crash. My question here: Is it possible to use somehow module, which was previously used in program? For this example it is of course nonsense, but my system is far more complicated and i need this functionality. Maybe some other approach to achieve this?
Related
What's the best way to open a file in the default application from Vala?
A bit like how xdg-open works.
I found some existing code in another application, but later on I also found this
GLib.AppInfo.launch_default_for_uri method.
A simple example:
var file = File.new_for_path (file_path);
if (file.query_exists ()) {
try {
AppInfo.launch_default_for_uri (file.get_uri (), null);
} catch (Error e) {
warning ("Unable to launch %s", file_path);
}
}
If you're using GTK, then you've also got Gtk.gtk_show_uri_on_window(), which uses the GLib stuff under the hood.
As far as I know there is only one implementation of the relevant freedesktop.org standards.
That is the reference implementation in xdg-utils:
https://www.freedesktop.org/wiki/Software/xdg-utils/
The tools are written in shell script, for example here is the source code for xdg-open:
https://cgit.freedesktop.org/xdg/xdg-utils/tree/scripts/xdg-open.in
So by far the easiest way is to just call the xdg-open script via Process.spawn_async and friends.
If you insist on using a library function you would have to implement a standard conforming library yourself.
Update:
There are quite a few libraries in various languages that implement some of the freedesktop.org standards, for example here is a list on GitHub:
https://github.com/topics/xdg
For example here is a similar tool to xdg-open written in D:
https://github.com/FreeSlave/mimeapps/blob/master/source/mimeapps.d
What I didn't find so far is a Vala / GLib or plain C library that could easily be used from a Vala application.
Update 2:
Actually it turns out there is something for that purpose in GLib (or more precisely in Gio):
https://valadoc.org/gio-2.0/GLib.AppInfo.launch_default_for_uri_async.html
https://developer.gnome.org/gio/stable/GAppInfo.html
So you should be able to use the GLib.AppInfo.launch_default_for_uri_async method.
I have a module compiled in a shared object (I followed the library part of this article https://chsasank.github.io/lua-c-wrapping.html) and I want to load it from C not from the interpreter.
Is it possible ? If so how to do it ?
Yes, it's possible, as require is a function stored in a global environment. Lua does the same in standalone interpreter when it needs to process the -l option, see the dolibrary function.
You do this the same way as with any other global function - in simplest case calling lua_getglobal(), then pushing the name of the file to require, and calling lua_call/lua_pcall/whatever.
I know that I am late, but someone else may struggle with this right now (like I just did).
This is a simple way of doing "require" from C:
int reqRes = luaL_dostring(L, "local t=require('myLib') return (t~=nil)");
if (reqRes==0)
//success
else
//failed
Unfortunately, right now, I'm using Lua 5.1 and "dolibrary" function doesn't exist, I >tried to take some part of the code and it crashes :\ So, for now, I use luaL_dostring(L, >"require 'libMyWrappings'"); libMyWrappings must be in the same directory as the c >program, and I can't use a path to indicate the lib. – Aminos Jan 22 at 11:45
I just ran into the same issue, it has to do when the package library is loaded
{LUA_LOADLIBNAME, luaopen_package}
needs to happen before you try and call it
I'm trying to understand what is happening behind the Rcpp::sourceCpp() call on a parallelized environment. Recently, this was partially addressed in the question: Using Rcpp function in parLapply on Windows.
Within this post, Dirk said,
"You need to run the sourceCpp() call in each spawned process, or else get them your code."
This was in response to questioner's use of distributing the Rcpp function to the worker processes. The questioner was sending the Rcpp function via:
clusterExport(cl = cl, varlist = "payoff")
I'm confused as to why this doesn't work. My thoughts are that this was what the objective of the clusterExport() is for.
The issue here is that the compiled code is not "exportable" to the spawned processes without being embedded in a package due to how binaries are linked into R's processes.
Traditionally, the clusterExport() statement allows for R specific code to be distributed to workers.
By using clusterExport() on an Rcpp function, you are only receiving the R declaration and not the underlying shared library. That is to say, the R CMD SHLIB given in Attributes.R is not shared with / exported to the workers. As a result, when a call is then made to an Rcpp function on the worker, R cannot find the correct shared library.
Take the previous question's function:
Rcpp::cppFunction("NumericVector payoff( double strike, NumericVector data) {
return pmax(data - strike, 0);
}")
Note: I'm using cppFunction() instead of sourceCpp() but the results are equivalent since cppFunction() calls sourceCpp() to create the function.
Typing the function name:
payoff
Yields the R declaration with a shared library pointer.
function (strike, data)
.Primitive(".Call")(<pointer: 0x1015ec130>, strike, data)
This shared library is only available on process that compiled the function.
Hence, why it is always ideal to embed compiled code within a package and then distribute the package.
Update:
Some further reading (local variable cannot be seen in a closure across the file?) gave me an "aha!" moment as to exactly why my code didn't work.
In Lua, local x is visible to anything within the same scope - things in the same function, if/then structures, for loops, other functions called from that function, etc, but not other modules, even if they're called from within the local's scope. I haven't found a better explanation than "because reasons", but simply knowing that modules are an exception to the "normal" scope behavior at least puts my mind at ease.
Original post:
(Terribly sorry if there's an answer for this out there; I've been Googling for a couple of hours and come up short.)
I've written a GUI library for my preferred audio software (Reaper). There's a strong potential for scripts to be running during recording/playback, so performance is a big issue, and I'm trying to keep everything Local where possible. Easy enough, in general, but I'm having a bit of trouble when it comes to using the GUI library + element classes in a script.
Main GUI module:
-- Core.lua --
local function GUI_table()
local GUI = {}
-- Template for GUI elements
GUI.Element = {}
function GUI.Element:new(name)
local elm = {}
setmetatable(elm, self)
self.__index = self
return elm
end
...add a bunch of GUI.do_this = function()....
return GUI
end
GUI = GUI_table()
All of the GUI elements are separate files of the same form:
-- Class - Button.lua --
if not GUI then throw_a_missing_library_error_and_quit end
GUI.Button = GUI.Element:new()
function GUI.Button:draw()
...etc...
I'm currently loading them from the parent script via loadfile("Core.lua")(). This works well enough, but it places GUI in the global table with the associated overhead for lookups. Trying to rewrite things so that GUI can be local has, thus far, not gone well. I've tried:
local GUI
loadfile("Core.lua")()
loadfile("Class - Button.lua")()
...
Fails because the main script's GUI calls all go to the local _GUI, but loaded files can't see or add to it because of scoping.
loadfile("Core.lua")()
loadfile("Class - Button.lua")()
local GUI = GUI
Runs fine, but doesn't make a difference performancewise: Errors in module code still trace back to the module (i.e. "line 23 in Class - Button.lua"), which leads me to assume the modules are still held within their own scope and my local GUI isn't actually being touched.
I've also tried having Core.lua return the GUI table directly, so the main script can have local GUI = loadfile("Core.lua")(), but I ran into trouble giving the element modules access to it, as above. I know, scoping.
So, given all of the above, is there a "correct" way to write/structure the modules so that everything ends up in a local GUI? I get the impression that the defunct module(..., package.seeall) functionality would have solved this... maybe not though.
Cheers.
This is a problem with circular dependencies. I notice that Element and Button go inside GUI, but they don't depend on GUI for their construction. Putting Element in its own file will allow you to make everything local.
-- Core.lua --
local GUI = {}
-- Template for GUI elements
GUI.Element = require 'Element'
GUI.Button = require 'Button'
return GUI
-- Element.lua --
return {
new = function(self, name)
local elm = {}
setmetatable(elm, self)
self.__index = self
return elm
end,
}
-- Class - Button.lua --
Button = require('Element'):new()
function Button:draw()
end
return Button
I use VLC media player 1.1.9 on Ubuntu 11.04. I'm trying to experiment with lua extensions for VLC; so I've added the file test.lua in ~/.local/share/vlc/lua/extensions/, which has only these two lines:
fps="25.000"
frame_duration=1/tonumber(fps)
When I run vlc with verbose output for debugging, I get (edited to split on multiple lines:):
$ vlc --verbose 2
...
[0xa213874] lua generic warning: Error loading script
~/.local/share/vlc/lua/extensions/test.lua:
.../.local/share/vlc/lua/extensions/test.lua:2:
attempt to call global 'tonumber' (a nil value)
...
Now, as far as I know, tonumber as function is part of Lua5.1 proper (Lua 5.1 Reference Manual: tonumber) - and on my system:
$ locate --regex 'lua.*so.*' | head -4
/usr/lib/libipelua.so.7.0.10
/usr/lib/liblua5.1.so
/usr/lib/liblua5.1.so.0
/usr/lib/liblua5.1.so.0.0.0
... apparently I do have Lua 5.1 installed.
So, why do I get an error on using tonumber here - and how can I use this (and other) standard functions in a VLC lua extension properly?
Documentation is sparse for VLC Lua extensions to say the least but I did find an example in the github vlc repository here: https://github.com/videolan/vlc/blob/master/share/lua/extensions/VLSub.lua
Judging from that example it appears you need to supply some basic event functions for your addon for VLC to call into when certain events happen. Some of the obvious callback handlers I've noticed:
descriptor, this should return a table that contains fields describing your addon.
activate, this seems to get called when you activate it from view menubar.
deactivate, called when you deactivate the addon from view menubar.
plus a couple of other functions like close and input_change which you can guess what they're for.
From my brief testing done on VLC 2.0.8 under Win7 it appears VLC loads the lua extension using an empty sandbox environment. This is likely the reason you're getting nil for tonumber and I'm betting none of the other standard lua functions are accessible either when you try to perform computation at this global scope.
However, if I move that code into one of the event handling functions then all those standard functions are accessible again. For example:
function descriptor()
return
{
title = "Test Ext";
version = "0.1";
author = "";
shortdesc = "Testing Lua Extension";
capabilities = {};
description = "VLC Hello Test Addon";
}
end
function activate()
print "test activating"
local fps = tonumber "25.000"
local frame_duration = 1 / fps
print(frame_duration)
return true
end
-- ...
That prints out what you would expect in the console debug log. Now the documentation (what little there is) doesn't mention any of this but what's probably happening here is VLC is injecting the standard lua functions and vlc api table into the sandboxed environment when any of these event handlers get called. But during the extension loading phase, it is done in an empty sandbox environment which explains why all those lua function calls end up being nil when you try to use it at the outter most scope.
I recommend cloning the VLC source tree from github and then performing a grep on the C source that's embedding lua to see what VLC is really doing behind the scenes. Most of the relevant code will likely be here: https://github.com/videolan/vlc/tree/master/modules/lua
Probably some extension script installed in your system overwrites the function and the Lua interpreter instance is shared between all extension scripts, so you end up not being able to call the function if that script is called before yours.
As a quick workaround, Lua being dynamically typed, you can still do things like:
1 / "25.000"
and the string will be coerced to a number.
Alternatively, you can define a tonumber equivalent like:
string_to_num = function(s) return s + 0 end
This again relies on dynamic typing.