2014-03-07 11:46:33 +00:00
|
|
|
/*
|
|
|
|
* This file is part of mpv.
|
|
|
|
*
|
|
|
|
* mpv is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* mpv is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
|
|
|
* with mpv. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
#include <assert.h>
|
|
|
|
#include <string.h>
|
2014-07-10 06:28:03 +00:00
|
|
|
#include <strings.h>
|
2014-02-14 12:49:10 +00:00
|
|
|
#include <sys/types.h>
|
2014-05-26 19:47:43 +00:00
|
|
|
#include <sys/stat.h>
|
|
|
|
#include <unistd.h>
|
2014-02-14 12:49:10 +00:00
|
|
|
#include <dirent.h>
|
2014-02-24 19:47:20 +00:00
|
|
|
#include <math.h>
|
2014-02-14 12:49:10 +00:00
|
|
|
|
|
|
|
#include "osdep/io.h"
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
|
|
|
|
#include <lua.h>
|
|
|
|
#include <lualib.h>
|
|
|
|
#include <lauxlib.h>
|
|
|
|
|
|
|
|
#include "talloc.h"
|
|
|
|
|
2013-12-17 01:39:45 +00:00
|
|
|
#include "common/common.h"
|
2013-12-17 01:02:25 +00:00
|
|
|
#include "options/m_property.h"
|
2013-12-17 01:39:45 +00:00
|
|
|
#include "common/msg.h"
|
lua: allow scripts to snoop messages
Adds the following Lua function to enable message events:
mp.enable_messages(size, level)
size is the maximum number of messages the ringbuffer consists of. level
is the minimum log level for a message to be added to the ringbuffer,
and uses the same values as the mp.log() function. (Actually not yet,
but this will be fixed in the following commit.)
The messages will be delivered via the mp_event() in the user script,
using "message" as event name. The event argument is a table with the
following fields:
level: log level of the message (string as in mp.log())
prefix: string identifying the module of origin
text: contents of the message
As of currently, the message text will contain newline characters. A
message can consist of several lines. It is also possible that a
message doesn't end with a newline, and a caller can use multiple
messages to "build" a line. Most messages will contain exactly 1 line
ending with a single newline character, though.
If the message buffer overflows (messages are not read quickly enough),
new messages are lost until the queued up messages are read. At the
point of the overflow, a special overflow message is inserted. It will
have prefix set to "overflow", and the message text is set to "".
Care should be taken not to print any messages from the message event
handler. This would lead to an infinite loop (the event handler would be
called again after returning, because a new message is available). This
includes mp.log() and all mp.msg.* functions. Keep in mind that the Lua
print() function is mapped to mp.msg.info().
2014-01-16 20:34:58 +00:00
|
|
|
#include "common/msg_control.h"
|
2013-12-17 01:02:25 +00:00
|
|
|
#include "options/m_option.h"
|
2013-12-17 00:23:09 +00:00
|
|
|
#include "input/input.h"
|
2013-12-17 01:02:25 +00:00
|
|
|
#include "options/path.h"
|
2013-12-17 01:39:45 +00:00
|
|
|
#include "bstr/bstr.h"
|
2013-10-29 20:35:29 +00:00
|
|
|
#include "osdep/timer.h"
|
2014-02-10 20:03:59 +00:00
|
|
|
#include "osdep/threads.h"
|
2013-11-24 11:58:06 +00:00
|
|
|
#include "sub/osd.h"
|
2013-12-17 00:08:53 +00:00
|
|
|
#include "core.h"
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
#include "command.h"
|
2014-02-10 20:03:59 +00:00
|
|
|
#include "client.h"
|
|
|
|
#include "libmpv/client.h"
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
|
|
|
|
// List of builtin modules and their contents as strings.
|
2013-12-16 23:53:22 +00:00
|
|
|
// All these are generated from player/lua/*.lua
|
2014-06-10 21:56:05 +00:00
|
|
|
static const char * const builtin_lua_scripts[][2] = {
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
{"mp.defaults",
|
2013-12-16 23:53:22 +00:00
|
|
|
# include "player/lua/defaults.inc"
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
},
|
|
|
|
{"mp.assdraw",
|
2013-12-16 23:53:22 +00:00
|
|
|
# include "player/lua/assdraw.inc"
|
2014-05-23 11:24:27 +00:00
|
|
|
},
|
|
|
|
{"mp.options",
|
|
|
|
# include "player/lua/options.inc"
|
2013-09-25 22:56:41 +00:00
|
|
|
},
|
2014-05-12 23:14:07 +00:00
|
|
|
{"@osc.lua",
|
2013-12-16 23:53:22 +00:00
|
|
|
# include "player/lua/osc.inc"
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
},
|
|
|
|
{0}
|
|
|
|
};
|
|
|
|
|
|
|
|
// Represents a loaded script. Each has its own Lua state.
|
|
|
|
struct script_ctx {
|
|
|
|
const char *name;
|
lua: redo error handling, print backtraces
The original goal was just adding backtraces, however making the code
safe (especially wrt. to out of memory Lua errors) was hard. So this
commit also restructures error handling to make it conceptually simpler.
Now all Lua code is run inside a Lua error handling, except the calls
for creating and destroying the Lua context, and calling the wrapper C
function in a safe way.
The new error handling is actually conceptually simpler and more
correct, because you can just call any Lua function at initialization,
without having to worry whwther it throws errors or not.
Unfortunately, Lua 5.2 removes lua_cpcall(), so we have to emulate it.
There isn't any way to emulate it in a way that works the same on 5.1
and 5.2 with the same semantics in error cases, so ifdeffery is needed.
The debug.traceback() function also behaves weirdly differently between
the Lua versions, so its output is not as nice as it could be (empty
extra line).
2014-07-07 15:13:44 +00:00
|
|
|
const char *filename;
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
lua_State *state;
|
|
|
|
struct mp_log *log;
|
2014-02-10 20:03:59 +00:00
|
|
|
struct mpv_handle *client;
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
struct MPContext *mpctx;
|
2014-02-10 20:03:59 +00:00
|
|
|
int suspended;
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
};
|
|
|
|
|
lua: redo error handling, print backtraces
The original goal was just adding backtraces, however making the code
safe (especially wrt. to out of memory Lua errors) was hard. So this
commit also restructures error handling to make it conceptually simpler.
Now all Lua code is run inside a Lua error handling, except the calls
for creating and destroying the Lua context, and calling the wrapper C
function in a safe way.
The new error handling is actually conceptually simpler and more
correct, because you can just call any Lua function at initialization,
without having to worry whwther it throws errors or not.
Unfortunately, Lua 5.2 removes lua_cpcall(), so we have to emulate it.
There isn't any way to emulate it in a way that works the same on 5.1
and 5.2 with the same semantics in error cases, so ifdeffery is needed.
The debug.traceback() function also behaves weirdly differently between
the Lua versions, so its output is not as nice as it could be (empty
extra line).
2014-07-07 15:13:44 +00:00
|
|
|
#if LUA_VERSION_NUM <= 501
|
|
|
|
#define mp_cpcall lua_cpcall
|
|
|
|
#else
|
|
|
|
// Curse whoever had this stupid idea. Curse whoever thought it would be a good
|
|
|
|
// idea not to include an emulated lua_cpcall() even more.
|
|
|
|
static int mp_cpcall (lua_State *L, lua_CFunction func, void *ud)
|
|
|
|
{
|
|
|
|
lua_pushcfunction(L, func); // doesn't allocate in 5.2 (but does in 5.1)
|
|
|
|
lua_pushlightuserdata(L, ud);
|
|
|
|
return lua_pcall(L, 1, 0, 0);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
static struct script_ctx *get_ctx(lua_State *L)
|
|
|
|
{
|
|
|
|
lua_getfield(L, LUA_REGISTRYINDEX, "ctx");
|
|
|
|
struct script_ctx *ctx = lua_touserdata(L, -1);
|
|
|
|
lua_pop(L, 1);
|
|
|
|
assert(ctx);
|
|
|
|
return ctx;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct MPContext *get_mpctx(lua_State *L)
|
|
|
|
{
|
|
|
|
return get_ctx(L)->mpctx;
|
|
|
|
}
|
|
|
|
|
lua: redo error handling, print backtraces
The original goal was just adding backtraces, however making the code
safe (especially wrt. to out of memory Lua errors) was hard. So this
commit also restructures error handling to make it conceptually simpler.
Now all Lua code is run inside a Lua error handling, except the calls
for creating and destroying the Lua context, and calling the wrapper C
function in a safe way.
The new error handling is actually conceptually simpler and more
correct, because you can just call any Lua function at initialization,
without having to worry whwther it throws errors or not.
Unfortunately, Lua 5.2 removes lua_cpcall(), so we have to emulate it.
There isn't any way to emulate it in a way that works the same on 5.1
and 5.2 with the same semantics in error cases, so ifdeffery is needed.
The debug.traceback() function also behaves weirdly differently between
the Lua versions, so its output is not as nice as it could be (empty
extra line).
2014-07-07 15:13:44 +00:00
|
|
|
static int error_handler(lua_State *L)
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
{
|
lua: redo error handling, print backtraces
The original goal was just adding backtraces, however making the code
safe (especially wrt. to out of memory Lua errors) was hard. So this
commit also restructures error handling to make it conceptually simpler.
Now all Lua code is run inside a Lua error handling, except the calls
for creating and destroying the Lua context, and calling the wrapper C
function in a safe way.
The new error handling is actually conceptually simpler and more
correct, because you can just call any Lua function at initialization,
without having to worry whwther it throws errors or not.
Unfortunately, Lua 5.2 removes lua_cpcall(), so we have to emulate it.
There isn't any way to emulate it in a way that works the same on 5.1
and 5.2 with the same semantics in error cases, so ifdeffery is needed.
The debug.traceback() function also behaves weirdly differently between
the Lua versions, so its output is not as nice as it could be (empty
extra line).
2014-07-07 15:13:44 +00:00
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
|
lua: redo error handling, print backtraces
The original goal was just adding backtraces, however making the code
safe (especially wrt. to out of memory Lua errors) was hard. So this
commit also restructures error handling to make it conceptually simpler.
Now all Lua code is run inside a Lua error handling, except the calls
for creating and destroying the Lua context, and calling the wrapper C
function in a safe way.
The new error handling is actually conceptually simpler and more
correct, because you can just call any Lua function at initialization,
without having to worry whwther it throws errors or not.
Unfortunately, Lua 5.2 removes lua_cpcall(), so we have to emulate it.
There isn't any way to emulate it in a way that works the same on 5.1
and 5.2 with the same semantics in error cases, so ifdeffery is needed.
The debug.traceback() function also behaves weirdly differently between
the Lua versions, so its output is not as nice as it could be (empty
extra line).
2014-07-07 15:13:44 +00:00
|
|
|
if (luaL_loadstring(L, "return debug.traceback('', 3)") == 0) { // e fn|err
|
|
|
|
lua_call(L, 0, 1); // e backtrace
|
|
|
|
const char *tr = lua_tostring(L, -1);
|
|
|
|
MP_WARN(ctx, "%s\n", tr);
|
|
|
|
}
|
|
|
|
lua_pop(L, 1); // e
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
|
lua: redo error handling, print backtraces
The original goal was just adding backtraces, however making the code
safe (especially wrt. to out of memory Lua errors) was hard. So this
commit also restructures error handling to make it conceptually simpler.
Now all Lua code is run inside a Lua error handling, except the calls
for creating and destroying the Lua context, and calling the wrapper C
function in a safe way.
The new error handling is actually conceptually simpler and more
correct, because you can just call any Lua function at initialization,
without having to worry whwther it throws errors or not.
Unfortunately, Lua 5.2 removes lua_cpcall(), so we have to emulate it.
There isn't any way to emulate it in a way that works the same on 5.1
and 5.2 with the same semantics in error cases, so ifdeffery is needed.
The debug.traceback() function also behaves weirdly differently between
the Lua versions, so its output is not as nice as it could be (empty
extra line).
2014-07-07 15:13:44 +00:00
|
|
|
return 1;
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
}
|
|
|
|
|
2014-02-10 20:03:59 +00:00
|
|
|
// Check client API error code:
|
2014-02-10 23:10:25 +00:00
|
|
|
// if err >= 0, push "true" to the stack, and return 1
|
|
|
|
// if err < 0, push nil and then the error string to the stack, and return 2
|
2014-02-10 20:03:59 +00:00
|
|
|
static int check_error(lua_State *L, int err)
|
|
|
|
{
|
2014-02-10 23:10:25 +00:00
|
|
|
if (err >= 0) {
|
|
|
|
lua_pushboolean(L, 1);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
lua_pushnil(L);
|
|
|
|
lua_pushstring(L, mpv_error_string(err));
|
|
|
|
return 2;
|
2014-02-10 20:03:59 +00:00
|
|
|
}
|
|
|
|
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
static void add_functions(struct script_ctx *ctx);
|
|
|
|
|
lua: redo error handling, print backtraces
The original goal was just adding backtraces, however making the code
safe (especially wrt. to out of memory Lua errors) was hard. So this
commit also restructures error handling to make it conceptually simpler.
Now all Lua code is run inside a Lua error handling, except the calls
for creating and destroying the Lua context, and calling the wrapper C
function in a safe way.
The new error handling is actually conceptually simpler and more
correct, because you can just call any Lua function at initialization,
without having to worry whwther it throws errors or not.
Unfortunately, Lua 5.2 removes lua_cpcall(), so we have to emulate it.
There isn't any way to emulate it in a way that works the same on 5.1
and 5.2 with the same semantics in error cases, so ifdeffery is needed.
The debug.traceback() function also behaves weirdly differently between
the Lua versions, so its output is not as nice as it could be (empty
extra line).
2014-07-07 15:13:44 +00:00
|
|
|
static void load_file(lua_State *L, const char *fname)
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
{
|
lua: redo error handling, print backtraces
The original goal was just adding backtraces, however making the code
safe (especially wrt. to out of memory Lua errors) was hard. So this
commit also restructures error handling to make it conceptually simpler.
Now all Lua code is run inside a Lua error handling, except the calls
for creating and destroying the Lua context, and calling the wrapper C
function in a safe way.
The new error handling is actually conceptually simpler and more
correct, because you can just call any Lua function at initialization,
without having to worry whwther it throws errors or not.
Unfortunately, Lua 5.2 removes lua_cpcall(), so we have to emulate it.
There isn't any way to emulate it in a way that works the same on 5.1
and 5.2 with the same semantics in error cases, so ifdeffery is needed.
The debug.traceback() function also behaves weirdly differently between
the Lua versions, so its output is not as nice as it could be (empty
extra line).
2014-07-07 15:13:44 +00:00
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
2014-01-21 20:23:42 +00:00
|
|
|
char *res_name = mp_get_user_path(NULL, ctx->mpctx->global, fname);
|
2014-02-14 12:49:10 +00:00
|
|
|
MP_VERBOSE(ctx, "loading file %s\n", res_name);
|
lua: redo error handling, print backtraces
The original goal was just adding backtraces, however making the code
safe (especially wrt. to out of memory Lua errors) was hard. So this
commit also restructures error handling to make it conceptually simpler.
Now all Lua code is run inside a Lua error handling, except the calls
for creating and destroying the Lua context, and calling the wrapper C
function in a safe way.
The new error handling is actually conceptually simpler and more
correct, because you can just call any Lua function at initialization,
without having to worry whwther it throws errors or not.
Unfortunately, Lua 5.2 removes lua_cpcall(), so we have to emulate it.
There isn't any way to emulate it in a way that works the same on 5.1
and 5.2 with the same semantics in error cases, so ifdeffery is needed.
The debug.traceback() function also behaves weirdly differently between
the Lua versions, so its output is not as nice as it could be (empty
extra line).
2014-07-07 15:13:44 +00:00
|
|
|
int r = luaL_loadfile(L, res_name);
|
|
|
|
talloc_free(res_name); // careful to not leak this on Lua errors
|
|
|
|
if (r)
|
|
|
|
lua_error(L);
|
|
|
|
lua_call(L, 0, 0);
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int load_builtin(lua_State *L)
|
|
|
|
{
|
|
|
|
const char *name = luaL_checkstring(L, 1);
|
2014-05-26 21:53:29 +00:00
|
|
|
char dispname[80];
|
|
|
|
snprintf(dispname, sizeof(dispname), "@%s", name);
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
for (int n = 0; builtin_lua_scripts[n][0]; n++) {
|
|
|
|
if (strcmp(name, builtin_lua_scripts[n][0]) == 0) {
|
2014-02-28 23:50:59 +00:00
|
|
|
const char *script = builtin_lua_scripts[n][1];
|
2014-05-26 21:53:29 +00:00
|
|
|
if (luaL_loadbuffer(L, script, strlen(script), dispname))
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
lua_error(L);
|
|
|
|
lua_call(L, 0, 1);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
}
|
lua: redo error handling, print backtraces
The original goal was just adding backtraces, however making the code
safe (especially wrt. to out of memory Lua errors) was hard. So this
commit also restructures error handling to make it conceptually simpler.
Now all Lua code is run inside a Lua error handling, except the calls
for creating and destroying the Lua context, and calling the wrapper C
function in a safe way.
The new error handling is actually conceptually simpler and more
correct, because you can just call any Lua function at initialization,
without having to worry whwther it throws errors or not.
Unfortunately, Lua 5.2 removes lua_cpcall(), so we have to emulate it.
There isn't any way to emulate it in a way that works the same on 5.1
and 5.2 with the same semantics in error cases, so ifdeffery is needed.
The debug.traceback() function also behaves weirdly differently between
the Lua versions, so its output is not as nice as it could be (empty
extra line).
2014-07-07 15:13:44 +00:00
|
|
|
luaL_error(L, "builtin module '%s' not found\n", name);
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Execute "require " .. name
|
lua: redo error handling, print backtraces
The original goal was just adding backtraces, however making the code
safe (especially wrt. to out of memory Lua errors) was hard. So this
commit also restructures error handling to make it conceptually simpler.
Now all Lua code is run inside a Lua error handling, except the calls
for creating and destroying the Lua context, and calling the wrapper C
function in a safe way.
The new error handling is actually conceptually simpler and more
correct, because you can just call any Lua function at initialization,
without having to worry whwther it throws errors or not.
Unfortunately, Lua 5.2 removes lua_cpcall(), so we have to emulate it.
There isn't any way to emulate it in a way that works the same on 5.1
and 5.2 with the same semantics in error cases, so ifdeffery is needed.
The debug.traceback() function also behaves weirdly differently between
the Lua versions, so its output is not as nice as it could be (empty
extra line).
2014-07-07 15:13:44 +00:00
|
|
|
static void require(lua_State *L, const char *name)
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
{
|
2014-02-14 12:49:10 +00:00
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
MP_VERBOSE(ctx, "loading %s\n", name);
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
// Lazy, but better than calling the "require" function manually
|
2014-02-14 12:49:10 +00:00
|
|
|
char buf[80];
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
snprintf(buf, sizeof(buf), "require '%s'", name);
|
lua: redo error handling, print backtraces
The original goal was just adding backtraces, however making the code
safe (especially wrt. to out of memory Lua errors) was hard. So this
commit also restructures error handling to make it conceptually simpler.
Now all Lua code is run inside a Lua error handling, except the calls
for creating and destroying the Lua context, and calling the wrapper C
function in a safe way.
The new error handling is actually conceptually simpler and more
correct, because you can just call any Lua function at initialization,
without having to worry whwther it throws errors or not.
Unfortunately, Lua 5.2 removes lua_cpcall(), so we have to emulate it.
There isn't any way to emulate it in a way that works the same on 5.1
and 5.2 with the same semantics in error cases, so ifdeffery is needed.
The debug.traceback() function also behaves weirdly differently between
the Lua versions, so its output is not as nice as it could be (empty
extra line).
2014-07-07 15:13:44 +00:00
|
|
|
if (luaL_loadstring(L, buf))
|
|
|
|
lua_error(L);
|
|
|
|
lua_call(L, 0, 0);
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
}
|
|
|
|
|
2014-05-26 19:46:01 +00:00
|
|
|
// Push the table of a module. If it doesn't exist, it's created.
|
|
|
|
// The Lua script can call "require(module)" to "load" it.
|
|
|
|
static void push_module_table(lua_State *L, const char *module)
|
|
|
|
{
|
|
|
|
lua_getglobal(L, "package"); // package
|
|
|
|
lua_getfield(L, -1, "loaded"); // package loaded
|
|
|
|
lua_remove(L, -2); // loaded
|
|
|
|
lua_getfield(L, -1, module); // loaded module
|
|
|
|
if (lua_isnil(L, -1)) {
|
|
|
|
lua_pop(L, 1); // loaded
|
|
|
|
lua_newtable(L); // loaded module
|
|
|
|
lua_pushvalue(L, -1); // loaded module module
|
|
|
|
lua_setfield(L, -3, module); // loaded module
|
|
|
|
}
|
|
|
|
lua_remove(L, -2); // module
|
|
|
|
}
|
|
|
|
|
lua: redo error handling, print backtraces
The original goal was just adding backtraces, however making the code
safe (especially wrt. to out of memory Lua errors) was hard. So this
commit also restructures error handling to make it conceptually simpler.
Now all Lua code is run inside a Lua error handling, except the calls
for creating and destroying the Lua context, and calling the wrapper C
function in a safe way.
The new error handling is actually conceptually simpler and more
correct, because you can just call any Lua function at initialization,
without having to worry whwther it throws errors or not.
Unfortunately, Lua 5.2 removes lua_cpcall(), so we have to emulate it.
There isn't any way to emulate it in a way that works the same on 5.1
and 5.2 with the same semantics in error cases, so ifdeffery is needed.
The debug.traceback() function also behaves weirdly differently between
the Lua versions, so its output is not as nice as it could be (empty
extra line).
2014-07-07 15:13:44 +00:00
|
|
|
static int load_scripts(lua_State *L)
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
{
|
lua: redo error handling, print backtraces
The original goal was just adding backtraces, however making the code
safe (especially wrt. to out of memory Lua errors) was hard. So this
commit also restructures error handling to make it conceptually simpler.
Now all Lua code is run inside a Lua error handling, except the calls
for creating and destroying the Lua context, and calling the wrapper C
function in a safe way.
The new error handling is actually conceptually simpler and more
correct, because you can just call any Lua function at initialization,
without having to worry whwther it throws errors or not.
Unfortunately, Lua 5.2 removes lua_cpcall(), so we have to emulate it.
There isn't any way to emulate it in a way that works the same on 5.1
and 5.2 with the same semantics in error cases, so ifdeffery is needed.
The debug.traceback() function also behaves weirdly differently between
the Lua versions, so its output is not as nice as it could be (empty
extra line).
2014-07-07 15:13:44 +00:00
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
const char *fname = ctx->filename;
|
2014-02-10 20:03:59 +00:00
|
|
|
|
lua: redo error handling, print backtraces
The original goal was just adding backtraces, however making the code
safe (especially wrt. to out of memory Lua errors) was hard. So this
commit also restructures error handling to make it conceptually simpler.
Now all Lua code is run inside a Lua error handling, except the calls
for creating and destroying the Lua context, and calling the wrapper C
function in a safe way.
The new error handling is actually conceptually simpler and more
correct, because you can just call any Lua function at initialization,
without having to worry whwther it throws errors or not.
Unfortunately, Lua 5.2 removes lua_cpcall(), so we have to emulate it.
There isn't any way to emulate it in a way that works the same on 5.1
and 5.2 with the same semantics in error cases, so ifdeffery is needed.
The debug.traceback() function also behaves weirdly differently between
the Lua versions, so its output is not as nice as it could be (empty
extra line).
2014-07-07 15:13:44 +00:00
|
|
|
require(L, "mp.defaults");
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
|
lua: redo error handling, print backtraces
The original goal was just adding backtraces, however making the code
safe (especially wrt. to out of memory Lua errors) was hard. So this
commit also restructures error handling to make it conceptually simpler.
Now all Lua code is run inside a Lua error handling, except the calls
for creating and destroying the Lua context, and calling the wrapper C
function in a safe way.
The new error handling is actually conceptually simpler and more
correct, because you can just call any Lua function at initialization,
without having to worry whwther it throws errors or not.
Unfortunately, Lua 5.2 removes lua_cpcall(), so we have to emulate it.
There isn't any way to emulate it in a way that works the same on 5.1
and 5.2 with the same semantics in error cases, so ifdeffery is needed.
The debug.traceback() function also behaves weirdly differently between
the Lua versions, so its output is not as nice as it could be (empty
extra line).
2014-07-07 15:13:44 +00:00
|
|
|
if (fname[0] == '@') {
|
|
|
|
require(L, fname);
|
|
|
|
} else {
|
|
|
|
load_file(L, fname);
|
|
|
|
}
|
|
|
|
|
|
|
|
lua_getglobal(L, "mp_event_loop"); // fn
|
|
|
|
if (lua_isnil(L, -1))
|
|
|
|
luaL_error(L, "no event loop function\n");
|
|
|
|
lua_call(L, 0, 0); // -
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int run_lua(lua_State *L)
|
|
|
|
{
|
|
|
|
struct script_ctx *ctx = lua_touserdata(L, -1);
|
|
|
|
lua_pop(L, 1); // -
|
|
|
|
|
|
|
|
luaL_openlibs(L);
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
|
|
|
|
// used by get_ctx()
|
|
|
|
lua_pushlightuserdata(L, ctx); // ctx
|
|
|
|
lua_setfield(L, LUA_REGISTRYINDEX, "ctx"); // -
|
|
|
|
|
2014-05-26 19:46:01 +00:00
|
|
|
add_functions(ctx); // mp
|
|
|
|
|
|
|
|
push_module_table(L, "mp"); // mp
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
|
2014-05-26 19:46:01 +00:00
|
|
|
// "mp" is available by default, and no "require 'mp'" is needed
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
lua_pushvalue(L, -1); // mp mp
|
|
|
|
lua_setglobal(L, "mp"); // mp
|
|
|
|
|
|
|
|
lua_pushstring(L, ctx->name); // mp name
|
|
|
|
lua_setfield(L, -2, "script_name"); // mp
|
|
|
|
|
2014-02-24 19:47:20 +00:00
|
|
|
// used by pushnode()
|
|
|
|
lua_newtable(L); // mp table
|
|
|
|
lua_pushvalue(L, -1); // mp table table
|
|
|
|
lua_setfield(L, LUA_REGISTRYINDEX, "UNKNOWN_TYPE"); // mp table
|
|
|
|
lua_setfield(L, -2, "UNKNOWN_TYPE"); // mp
|
2014-02-26 21:32:57 +00:00
|
|
|
lua_newtable(L); // mp table
|
|
|
|
lua_pushvalue(L, -1); // mp table table
|
|
|
|
lua_setfield(L, LUA_REGISTRYINDEX, "MAP"); // mp table
|
|
|
|
lua_setfield(L, -2, "MAP"); // mp
|
|
|
|
lua_newtable(L); // mp table
|
|
|
|
lua_pushvalue(L, -1); // mp table table
|
|
|
|
lua_setfield(L, LUA_REGISTRYINDEX, "ARRAY"); // mp table
|
|
|
|
lua_setfield(L, -2, "ARRAY"); // mp
|
2014-02-24 19:47:20 +00:00
|
|
|
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
lua_pop(L, 1); // -
|
|
|
|
|
2014-02-24 19:47:20 +00:00
|
|
|
assert(lua_gettop(L) == 0);
|
|
|
|
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
// Add a preloader for each builtin Lua module
|
|
|
|
lua_getglobal(L, "package"); // package
|
|
|
|
assert(lua_type(L, -1) == LUA_TTABLE);
|
|
|
|
lua_getfield(L, -1, "preload"); // package preload
|
|
|
|
assert(lua_type(L, -1) == LUA_TTABLE);
|
|
|
|
for (int n = 0; builtin_lua_scripts[n][0]; n++) {
|
|
|
|
lua_pushcfunction(L, load_builtin); // package preload load_builtin
|
|
|
|
lua_setfield(L, -2, builtin_lua_scripts[n][0]);
|
|
|
|
}
|
|
|
|
lua_pop(L, 2); // -
|
|
|
|
|
|
|
|
assert(lua_gettop(L) == 0);
|
|
|
|
|
lua: redo error handling, print backtraces
The original goal was just adding backtraces, however making the code
safe (especially wrt. to out of memory Lua errors) was hard. So this
commit also restructures error handling to make it conceptually simpler.
Now all Lua code is run inside a Lua error handling, except the calls
for creating and destroying the Lua context, and calling the wrapper C
function in a safe way.
The new error handling is actually conceptually simpler and more
correct, because you can just call any Lua function at initialization,
without having to worry whwther it throws errors or not.
Unfortunately, Lua 5.2 removes lua_cpcall(), so we have to emulate it.
There isn't any way to emulate it in a way that works the same on 5.1
and 5.2 with the same semantics in error cases, so ifdeffery is needed.
The debug.traceback() function also behaves weirdly differently between
the Lua versions, so its output is not as nice as it could be (empty
extra line).
2014-07-07 15:13:44 +00:00
|
|
|
// run this under an error handler that can do backtraces
|
|
|
|
lua_pushcfunction(L, error_handler); // errf
|
|
|
|
lua_pushcfunction(L, load_scripts); // errf fn
|
|
|
|
if (lua_pcall(L, 0, 0, -2)) // errf [error]
|
|
|
|
MP_FATAL(ctx, "Lua error: %s\n", lua_tostring(L, -1));
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
|
lua: redo error handling, print backtraces
The original goal was just adding backtraces, however making the code
safe (especially wrt. to out of memory Lua errors) was hard. So this
commit also restructures error handling to make it conceptually simpler.
Now all Lua code is run inside a Lua error handling, except the calls
for creating and destroying the Lua context, and calling the wrapper C
function in a safe way.
The new error handling is actually conceptually simpler and more
correct, because you can just call any Lua function at initialization,
without having to worry whwther it throws errors or not.
Unfortunately, Lua 5.2 removes lua_cpcall(), so we have to emulate it.
There isn't any way to emulate it in a way that works the same on 5.1
and 5.2 with the same semantics in error cases, so ifdeffery is needed.
The debug.traceback() function also behaves weirdly differently between
the Lua versions, so its output is not as nice as it could be (empty
extra line).
2014-07-07 15:13:44 +00:00
|
|
|
return 0;
|
|
|
|
}
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
|
lua: redo error handling, print backtraces
The original goal was just adding backtraces, however making the code
safe (especially wrt. to out of memory Lua errors) was hard. So this
commit also restructures error handling to make it conceptually simpler.
Now all Lua code is run inside a Lua error handling, except the calls
for creating and destroying the Lua context, and calling the wrapper C
function in a safe way.
The new error handling is actually conceptually simpler and more
correct, because you can just call any Lua function at initialization,
without having to worry whwther it throws errors or not.
Unfortunately, Lua 5.2 removes lua_cpcall(), so we have to emulate it.
There isn't any way to emulate it in a way that works the same on 5.1
and 5.2 with the same semantics in error cases, so ifdeffery is needed.
The debug.traceback() function also behaves weirdly differently between
the Lua versions, so its output is not as nice as it could be (empty
extra line).
2014-07-07 15:13:44 +00:00
|
|
|
static int load_lua(struct mpv_handle *client, const char *fname)
|
|
|
|
{
|
|
|
|
struct MPContext *mpctx = mp_client_get_core(client);
|
|
|
|
int r = -1;
|
|
|
|
|
|
|
|
struct script_ctx *ctx = talloc_ptrtype(NULL, ctx);
|
|
|
|
*ctx = (struct script_ctx) {
|
|
|
|
.mpctx = mpctx,
|
|
|
|
.client = client,
|
|
|
|
.name = mpv_client_name(client),
|
|
|
|
.log = mp_client_get_log(client),
|
|
|
|
.filename = fname,
|
|
|
|
};
|
|
|
|
|
|
|
|
lua_State *L = ctx->state = luaL_newstate();
|
|
|
|
if (!L)
|
|
|
|
goto error_out;
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
|
lua: redo error handling, print backtraces
The original goal was just adding backtraces, however making the code
safe (especially wrt. to out of memory Lua errors) was hard. So this
commit also restructures error handling to make it conceptually simpler.
Now all Lua code is run inside a Lua error handling, except the calls
for creating and destroying the Lua context, and calling the wrapper C
function in a safe way.
The new error handling is actually conceptually simpler and more
correct, because you can just call any Lua function at initialization,
without having to worry whwther it throws errors or not.
Unfortunately, Lua 5.2 removes lua_cpcall(), so we have to emulate it.
There isn't any way to emulate it in a way that works the same on 5.1
and 5.2 with the same semantics in error cases, so ifdeffery is needed.
The debug.traceback() function also behaves weirdly differently between
the Lua versions, so its output is not as nice as it could be (empty
extra line).
2014-07-07 15:13:44 +00:00
|
|
|
if (mp_cpcall(L, run_lua, ctx)) {
|
|
|
|
const char *err = "unknown error";
|
|
|
|
if (lua_type(L, -1) == LUA_TSTRING) // avoid allocation
|
|
|
|
err = lua_tostring(L, -1);
|
|
|
|
MP_FATAL(ctx, "Lua error: %s\n", err);
|
|
|
|
goto error_out;
|
|
|
|
}
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
|
2014-05-12 23:14:07 +00:00
|
|
|
r = 0;
|
|
|
|
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
error_out:
|
2014-02-10 20:03:59 +00:00
|
|
|
if (ctx->suspended)
|
|
|
|
mpv_resume(ctx->client);
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
if (ctx->state)
|
|
|
|
lua_close(ctx->state);
|
|
|
|
talloc_free(ctx);
|
2014-05-12 23:14:07 +00:00
|
|
|
return r;
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
}
|
|
|
|
|
lua: allow scripts to snoop messages
Adds the following Lua function to enable message events:
mp.enable_messages(size, level)
size is the maximum number of messages the ringbuffer consists of. level
is the minimum log level for a message to be added to the ringbuffer,
and uses the same values as the mp.log() function. (Actually not yet,
but this will be fixed in the following commit.)
The messages will be delivered via the mp_event() in the user script,
using "message" as event name. The event argument is a table with the
following fields:
level: log level of the message (string as in mp.log())
prefix: string identifying the module of origin
text: contents of the message
As of currently, the message text will contain newline characters. A
message can consist of several lines. It is also possible that a
message doesn't end with a newline, and a caller can use multiple
messages to "build" a line. Most messages will contain exactly 1 line
ending with a single newline character, though.
If the message buffer overflows (messages are not read quickly enough),
new messages are lost until the queued up messages are read. At the
point of the overflow, a special overflow message is inserted. It will
have prefix set to "overflow", and the message text is set to "".
Care should be taken not to print any messages from the message event
handler. This would lead to an infinite loop (the event handler would be
called again after returning, because a new message is available). This
includes mp.log() and all mp.msg.* functions. Keep in mind that the Lua
print() function is mapped to mp.msg.info().
2014-01-16 20:34:58 +00:00
|
|
|
static int check_loglevel(lua_State *L, int arg)
|
|
|
|
{
|
|
|
|
const char *level = luaL_checkstring(L, arg);
|
2014-01-16 20:37:29 +00:00
|
|
|
for (int n = 0; n < MSGL_MAX; n++) {
|
|
|
|
if (mp_log_levels[n] && strcasecmp(mp_log_levels[n], level) == 0)
|
lua: allow scripts to snoop messages
Adds the following Lua function to enable message events:
mp.enable_messages(size, level)
size is the maximum number of messages the ringbuffer consists of. level
is the minimum log level for a message to be added to the ringbuffer,
and uses the same values as the mp.log() function. (Actually not yet,
but this will be fixed in the following commit.)
The messages will be delivered via the mp_event() in the user script,
using "message" as event name. The event argument is a table with the
following fields:
level: log level of the message (string as in mp.log())
prefix: string identifying the module of origin
text: contents of the message
As of currently, the message text will contain newline characters. A
message can consist of several lines. It is also possible that a
message doesn't end with a newline, and a caller can use multiple
messages to "build" a line. Most messages will contain exactly 1 line
ending with a single newline character, though.
If the message buffer overflows (messages are not read quickly enough),
new messages are lost until the queued up messages are read. At the
point of the overflow, a special overflow message is inserted. It will
have prefix set to "overflow", and the message text is set to "".
Care should be taken not to print any messages from the message event
handler. This would lead to an infinite loop (the event handler would be
called again after returning, because a new message is available). This
includes mp.log() and all mp.msg.* functions. Keep in mind that the Lua
print() function is mapped to mp.msg.info().
2014-01-16 20:34:58 +00:00
|
|
|
return n;
|
|
|
|
}
|
|
|
|
luaL_error(L, "Invalid log level '%s'", level);
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
static int script_log(lua_State *L)
|
|
|
|
{
|
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
|
lua: allow scripts to snoop messages
Adds the following Lua function to enable message events:
mp.enable_messages(size, level)
size is the maximum number of messages the ringbuffer consists of. level
is the minimum log level for a message to be added to the ringbuffer,
and uses the same values as the mp.log() function. (Actually not yet,
but this will be fixed in the following commit.)
The messages will be delivered via the mp_event() in the user script,
using "message" as event name. The event argument is a table with the
following fields:
level: log level of the message (string as in mp.log())
prefix: string identifying the module of origin
text: contents of the message
As of currently, the message text will contain newline characters. A
message can consist of several lines. It is also possible that a
message doesn't end with a newline, and a caller can use multiple
messages to "build" a line. Most messages will contain exactly 1 line
ending with a single newline character, though.
If the message buffer overflows (messages are not read quickly enough),
new messages are lost until the queued up messages are read. At the
point of the overflow, a special overflow message is inserted. It will
have prefix set to "overflow", and the message text is set to "".
Care should be taken not to print any messages from the message event
handler. This would lead to an infinite loop (the event handler would be
called again after returning, because a new message is available). This
includes mp.log() and all mp.msg.* functions. Keep in mind that the Lua
print() function is mapped to mp.msg.info().
2014-01-16 20:34:58 +00:00
|
|
|
int msgl = check_loglevel(L, 1);
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
|
|
|
|
int last = lua_gettop(L);
|
|
|
|
lua_getglobal(L, "tostring"); // args... tostring
|
|
|
|
for (int i = 2; i <= last; i++) {
|
|
|
|
lua_pushvalue(L, -1); // args... tostring tostring
|
|
|
|
lua_pushvalue(L, i); // args... tostring tostring args[i]
|
|
|
|
lua_call(L, 1, 1); // args... tostring str
|
|
|
|
const char *s = lua_tostring(L, -1);
|
|
|
|
if (s == NULL)
|
|
|
|
return luaL_error(L, "Invalid argument");
|
2013-12-21 20:49:13 +00:00
|
|
|
mp_msg(ctx->log, msgl, "%s%s", s, i > 0 ? " " : "");
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
lua_pop(L, 1); // args... tostring
|
|
|
|
}
|
2013-12-21 20:49:13 +00:00
|
|
|
mp_msg(ctx->log, msgl, "\n");
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int script_find_config_file(lua_State *L)
|
|
|
|
{
|
2013-12-21 19:45:19 +00:00
|
|
|
struct MPContext *mpctx = get_mpctx(L);
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
const char *s = luaL_checkstring(L, 1);
|
2014-06-18 23:55:40 +00:00
|
|
|
char *path = mp_find_config_file(NULL, mpctx->global, s);
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
if (path) {
|
|
|
|
lua_pushstring(L, path);
|
|
|
|
} else {
|
|
|
|
lua_pushnil(L);
|
|
|
|
}
|
|
|
|
talloc_free(path);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2014-02-10 20:03:59 +00:00
|
|
|
static int script_suspend(lua_State *L)
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
{
|
2014-02-10 20:03:59 +00:00
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
if (!ctx->suspended)
|
|
|
|
mpv_suspend(ctx->client);
|
|
|
|
ctx->suspended++;
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-02-10 20:03:59 +00:00
|
|
|
static int script_resume(lua_State *L)
|
lua: allow scripts to snoop messages
Adds the following Lua function to enable message events:
mp.enable_messages(size, level)
size is the maximum number of messages the ringbuffer consists of. level
is the minimum log level for a message to be added to the ringbuffer,
and uses the same values as the mp.log() function. (Actually not yet,
but this will be fixed in the following commit.)
The messages will be delivered via the mp_event() in the user script,
using "message" as event name. The event argument is a table with the
following fields:
level: log level of the message (string as in mp.log())
prefix: string identifying the module of origin
text: contents of the message
As of currently, the message text will contain newline characters. A
message can consist of several lines. It is also possible that a
message doesn't end with a newline, and a caller can use multiple
messages to "build" a line. Most messages will contain exactly 1 line
ending with a single newline character, though.
If the message buffer overflows (messages are not read quickly enough),
new messages are lost until the queued up messages are read. At the
point of the overflow, a special overflow message is inserted. It will
have prefix set to "overflow", and the message text is set to "".
Care should be taken not to print any messages from the message event
handler. This would lead to an infinite loop (the event handler would be
called again after returning, because a new message is available). This
includes mp.log() and all mp.msg.* functions. Keep in mind that the Lua
print() function is mapped to mp.msg.info().
2014-01-16 20:34:58 +00:00
|
|
|
{
|
2014-02-10 20:03:59 +00:00
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
2014-02-10 23:57:40 +00:00
|
|
|
if (ctx->suspended < 1)
|
|
|
|
luaL_error(L, "trying to resume, but core is not suspended");
|
|
|
|
ctx->suspended--;
|
|
|
|
if (!ctx->suspended)
|
|
|
|
mpv_resume(ctx->client);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int script_resume_all(lua_State *L)
|
|
|
|
{
|
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
if (ctx->suspended)
|
|
|
|
mpv_resume(ctx->client);
|
|
|
|
ctx->suspended = 0;
|
2014-02-10 20:03:59 +00:00
|
|
|
return 0;
|
|
|
|
}
|
lua: allow scripts to snoop messages
Adds the following Lua function to enable message events:
mp.enable_messages(size, level)
size is the maximum number of messages the ringbuffer consists of. level
is the minimum log level for a message to be added to the ringbuffer,
and uses the same values as the mp.log() function. (Actually not yet,
but this will be fixed in the following commit.)
The messages will be delivered via the mp_event() in the user script,
using "message" as event name. The event argument is a table with the
following fields:
level: log level of the message (string as in mp.log())
prefix: string identifying the module of origin
text: contents of the message
As of currently, the message text will contain newline characters. A
message can consist of several lines. It is also possible that a
message doesn't end with a newline, and a caller can use multiple
messages to "build" a line. Most messages will contain exactly 1 line
ending with a single newline character, though.
If the message buffer overflows (messages are not read quickly enough),
new messages are lost until the queued up messages are read. At the
point of the overflow, a special overflow message is inserted. It will
have prefix set to "overflow", and the message text is set to "".
Care should be taken not to print any messages from the message event
handler. This would lead to an infinite loop (the event handler would be
called again after returning, because a new message is available). This
includes mp.log() and all mp.msg.* functions. Keep in mind that the Lua
print() function is mapped to mp.msg.info().
2014-01-16 20:34:58 +00:00
|
|
|
|
2014-04-06 01:22:17 +00:00
|
|
|
static bool pushnode(lua_State *L, mpv_node *node, int depth);
|
|
|
|
|
2014-02-10 20:03:59 +00:00
|
|
|
static int script_wait_event(lua_State *L)
|
|
|
|
{
|
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
lua: allow scripts to snoop messages
Adds the following Lua function to enable message events:
mp.enable_messages(size, level)
size is the maximum number of messages the ringbuffer consists of. level
is the minimum log level for a message to be added to the ringbuffer,
and uses the same values as the mp.log() function. (Actually not yet,
but this will be fixed in the following commit.)
The messages will be delivered via the mp_event() in the user script,
using "message" as event name. The event argument is a table with the
following fields:
level: log level of the message (string as in mp.log())
prefix: string identifying the module of origin
text: contents of the message
As of currently, the message text will contain newline characters. A
message can consist of several lines. It is also possible that a
message doesn't end with a newline, and a caller can use multiple
messages to "build" a line. Most messages will contain exactly 1 line
ending with a single newline character, though.
If the message buffer overflows (messages are not read quickly enough),
new messages are lost until the queued up messages are read. At the
point of the overflow, a special overflow message is inserted. It will
have prefix set to "overflow", and the message text is set to "".
Care should be taken not to print any messages from the message event
handler. This would lead to an infinite loop (the event handler would be
called again after returning, because a new message is available). This
includes mp.log() and all mp.msg.* functions. Keep in mind that the Lua
print() function is mapped to mp.msg.info().
2014-01-16 20:34:58 +00:00
|
|
|
|
2014-02-10 20:03:59 +00:00
|
|
|
double timeout = luaL_optnumber(L, 1, 1e20);
|
|
|
|
|
|
|
|
// This will almost surely lead to a deadlock. (Polling is still ok.)
|
|
|
|
if (ctx->suspended && timeout > 0)
|
|
|
|
luaL_error(L, "attempting to wait while core is suspended");
|
|
|
|
|
|
|
|
mpv_event *event = mpv_wait_event(ctx->client, timeout);
|
lua: allow scripts to snoop messages
Adds the following Lua function to enable message events:
mp.enable_messages(size, level)
size is the maximum number of messages the ringbuffer consists of. level
is the minimum log level for a message to be added to the ringbuffer,
and uses the same values as the mp.log() function. (Actually not yet,
but this will be fixed in the following commit.)
The messages will be delivered via the mp_event() in the user script,
using "message" as event name. The event argument is a table with the
following fields:
level: log level of the message (string as in mp.log())
prefix: string identifying the module of origin
text: contents of the message
As of currently, the message text will contain newline characters. A
message can consist of several lines. It is also possible that a
message doesn't end with a newline, and a caller can use multiple
messages to "build" a line. Most messages will contain exactly 1 line
ending with a single newline character, though.
If the message buffer overflows (messages are not read quickly enough),
new messages are lost until the queued up messages are read. At the
point of the overflow, a special overflow message is inserted. It will
have prefix set to "overflow", and the message text is set to "".
Care should be taken not to print any messages from the message event
handler. This would lead to an infinite loop (the event handler would be
called again after returning, because a new message is available). This
includes mp.log() and all mp.msg.* functions. Keep in mind that the Lua
print() function is mapped to mp.msg.info().
2014-01-16 20:34:58 +00:00
|
|
|
|
2014-02-10 20:03:59 +00:00
|
|
|
lua_newtable(L); // event
|
|
|
|
lua_pushstring(L, mpv_event_name(event->event_id)); // event name
|
|
|
|
lua_setfield(L, -2, "event"); // event
|
lua: allow scripts to snoop messages
Adds the following Lua function to enable message events:
mp.enable_messages(size, level)
size is the maximum number of messages the ringbuffer consists of. level
is the minimum log level for a message to be added to the ringbuffer,
and uses the same values as the mp.log() function. (Actually not yet,
but this will be fixed in the following commit.)
The messages will be delivered via the mp_event() in the user script,
using "message" as event name. The event argument is a table with the
following fields:
level: log level of the message (string as in mp.log())
prefix: string identifying the module of origin
text: contents of the message
As of currently, the message text will contain newline characters. A
message can consist of several lines. It is also possible that a
message doesn't end with a newline, and a caller can use multiple
messages to "build" a line. Most messages will contain exactly 1 line
ending with a single newline character, though.
If the message buffer overflows (messages are not read quickly enough),
new messages are lost until the queued up messages are read. At the
point of the overflow, a special overflow message is inserted. It will
have prefix set to "overflow", and the message text is set to "".
Care should be taken not to print any messages from the message event
handler. This would lead to an infinite loop (the event handler would be
called again after returning, because a new message is available). This
includes mp.log() and all mp.msg.* functions. Keep in mind that the Lua
print() function is mapped to mp.msg.info().
2014-01-16 20:34:58 +00:00
|
|
|
|
2014-04-08 19:10:00 +00:00
|
|
|
if (event->reply_userdata) {
|
|
|
|
lua_pushnumber(L, event->reply_userdata);
|
|
|
|
lua_setfield(L, -2, "id");
|
|
|
|
}
|
|
|
|
|
2014-02-10 20:03:59 +00:00
|
|
|
if (event->error < 0) {
|
|
|
|
lua_pushstring(L, mpv_error_string(event->error)); // event err
|
|
|
|
lua_setfield(L, -2, "error"); // event
|
|
|
|
}
|
lua: allow scripts to snoop messages
Adds the following Lua function to enable message events:
mp.enable_messages(size, level)
size is the maximum number of messages the ringbuffer consists of. level
is the minimum log level for a message to be added to the ringbuffer,
and uses the same values as the mp.log() function. (Actually not yet,
but this will be fixed in the following commit.)
The messages will be delivered via the mp_event() in the user script,
using "message" as event name. The event argument is a table with the
following fields:
level: log level of the message (string as in mp.log())
prefix: string identifying the module of origin
text: contents of the message
As of currently, the message text will contain newline characters. A
message can consist of several lines. It is also possible that a
message doesn't end with a newline, and a caller can use multiple
messages to "build" a line. Most messages will contain exactly 1 line
ending with a single newline character, though.
If the message buffer overflows (messages are not read quickly enough),
new messages are lost until the queued up messages are read. At the
point of the overflow, a special overflow message is inserted. It will
have prefix set to "overflow", and the message text is set to "".
Care should be taken not to print any messages from the message event
handler. This would lead to an infinite loop (the event handler would be
called again after returning, because a new message is available). This
includes mp.log() and all mp.msg.* functions. Keep in mind that the Lua
print() function is mapped to mp.msg.info().
2014-01-16 20:34:58 +00:00
|
|
|
|
2014-02-10 20:03:59 +00:00
|
|
|
switch (event->event_id) {
|
|
|
|
case MPV_EVENT_LOG_MESSAGE: {
|
|
|
|
mpv_event_log_message *msg = event->data;
|
|
|
|
|
|
|
|
lua_pushstring(L, msg->prefix); // event s
|
|
|
|
lua_setfield(L, -2, "prefix"); // event
|
|
|
|
lua_pushstring(L, msg->level); // event s
|
|
|
|
lua_setfield(L, -2, "level"); // event
|
|
|
|
lua_pushstring(L, msg->text); // event s
|
|
|
|
lua_setfield(L, -2, "text"); // event
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case MPV_EVENT_SCRIPT_INPUT_DISPATCH: {
|
|
|
|
mpv_event_script_input_dispatch *msg = event->data;
|
|
|
|
|
|
|
|
lua_pushinteger(L, msg->arg0); // event i
|
|
|
|
lua_setfield(L, -2, "arg0"); // event
|
|
|
|
lua_pushstring(L, msg->type); // event s
|
|
|
|
lua_setfield(L, -2, "type"); // event
|
|
|
|
break;
|
|
|
|
}
|
2014-02-17 01:33:47 +00:00
|
|
|
case MPV_EVENT_CLIENT_MESSAGE: {
|
|
|
|
mpv_event_client_message *msg = event->data;
|
|
|
|
|
|
|
|
lua_newtable(L); // event args
|
|
|
|
for (int n = 0; n < msg->num_args; n++) {
|
|
|
|
lua_pushinteger(L, n + 1); // event args N
|
|
|
|
lua_pushstring(L, msg->args[n]); // event args N val
|
|
|
|
lua_settable(L, -3); // event args
|
|
|
|
}
|
|
|
|
lua_setfield(L, -2, "args"); // event
|
|
|
|
break;
|
|
|
|
}
|
2014-04-06 01:22:17 +00:00
|
|
|
case MPV_EVENT_PROPERTY_CHANGE: {
|
|
|
|
mpv_event_property *prop = event->data;
|
|
|
|
lua_pushstring(L, prop->name);
|
|
|
|
lua_setfield(L, -2, "name");
|
|
|
|
switch (prop->format) {
|
|
|
|
case MPV_FORMAT_NODE:
|
|
|
|
if (!pushnode(L, prop->data, 50))
|
|
|
|
luaL_error(L, "stack overflow");
|
|
|
|
break;
|
|
|
|
case MPV_FORMAT_DOUBLE:
|
|
|
|
lua_pushnumber(L, *(double *)prop->data);
|
|
|
|
break;
|
|
|
|
case MPV_FORMAT_FLAG:
|
|
|
|
lua_pushboolean(L, *(int *)prop->data);
|
|
|
|
break;
|
|
|
|
case MPV_FORMAT_STRING:
|
|
|
|
lua_pushstring(L, *(char **)prop->data);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
lua_pushnil(L);
|
|
|
|
}
|
|
|
|
lua_setfield(L, -2, "data");
|
|
|
|
break;
|
|
|
|
}
|
2014-02-10 20:03:59 +00:00
|
|
|
default: ;
|
lua: allow scripts to snoop messages
Adds the following Lua function to enable message events:
mp.enable_messages(size, level)
size is the maximum number of messages the ringbuffer consists of. level
is the minimum log level for a message to be added to the ringbuffer,
and uses the same values as the mp.log() function. (Actually not yet,
but this will be fixed in the following commit.)
The messages will be delivered via the mp_event() in the user script,
using "message" as event name. The event argument is a table with the
following fields:
level: log level of the message (string as in mp.log())
prefix: string identifying the module of origin
text: contents of the message
As of currently, the message text will contain newline characters. A
message can consist of several lines. It is also possible that a
message doesn't end with a newline, and a caller can use multiple
messages to "build" a line. Most messages will contain exactly 1 line
ending with a single newline character, though.
If the message buffer overflows (messages are not read quickly enough),
new messages are lost until the queued up messages are read. At the
point of the overflow, a special overflow message is inserted. It will
have prefix set to "overflow", and the message text is set to "".
Care should be taken not to print any messages from the message event
handler. This would lead to an infinite loop (the event handler would be
called again after returning, because a new message is available). This
includes mp.log() and all mp.msg.* functions. Keep in mind that the Lua
print() function is mapped to mp.msg.info().
2014-01-16 20:34:58 +00:00
|
|
|
}
|
2014-02-10 20:03:59 +00:00
|
|
|
|
2014-02-17 01:33:47 +00:00
|
|
|
// return event
|
2014-02-10 20:03:59 +00:00
|
|
|
return 1;
|
lua: allow scripts to snoop messages
Adds the following Lua function to enable message events:
mp.enable_messages(size, level)
size is the maximum number of messages the ringbuffer consists of. level
is the minimum log level for a message to be added to the ringbuffer,
and uses the same values as the mp.log() function. (Actually not yet,
but this will be fixed in the following commit.)
The messages will be delivered via the mp_event() in the user script,
using "message" as event name. The event argument is a table with the
following fields:
level: log level of the message (string as in mp.log())
prefix: string identifying the module of origin
text: contents of the message
As of currently, the message text will contain newline characters. A
message can consist of several lines. It is also possible that a
message doesn't end with a newline, and a caller can use multiple
messages to "build" a line. Most messages will contain exactly 1 line
ending with a single newline character, though.
If the message buffer overflows (messages are not read quickly enough),
new messages are lost until the queued up messages are read. At the
point of the overflow, a special overflow message is inserted. It will
have prefix set to "overflow", and the message text is set to "".
Care should be taken not to print any messages from the message event
handler. This would lead to an infinite loop (the event handler would be
called again after returning, because a new message is available). This
includes mp.log() and all mp.msg.* functions. Keep in mind that the Lua
print() function is mapped to mp.msg.info().
2014-01-16 20:34:58 +00:00
|
|
|
}
|
|
|
|
|
2014-02-10 20:03:59 +00:00
|
|
|
static int script_request_event(lua_State *L)
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
{
|
2014-02-10 20:03:59 +00:00
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
const char *event = luaL_checkstring(L, 1);
|
|
|
|
bool enable = lua_toboolean(L, 2);
|
|
|
|
// brute force event name -> id; stops working for events > assumed max
|
|
|
|
int event_id = -1;
|
|
|
|
for (int n = 0; n < 256; n++) {
|
|
|
|
const char *name = mpv_event_name(n);
|
|
|
|
if (name && strcmp(name, event) == 0) {
|
|
|
|
event_id = n;
|
|
|
|
break;
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
}
|
|
|
|
}
|
2014-02-10 20:03:59 +00:00
|
|
|
lua_pushboolean(L, mpv_request_event(ctx->client, event_id, enable) >= 0);
|
|
|
|
return 1;
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
}
|
|
|
|
|
lua: allow scripts to snoop messages
Adds the following Lua function to enable message events:
mp.enable_messages(size, level)
size is the maximum number of messages the ringbuffer consists of. level
is the minimum log level for a message to be added to the ringbuffer,
and uses the same values as the mp.log() function. (Actually not yet,
but this will be fixed in the following commit.)
The messages will be delivered via the mp_event() in the user script,
using "message" as event name. The event argument is a table with the
following fields:
level: log level of the message (string as in mp.log())
prefix: string identifying the module of origin
text: contents of the message
As of currently, the message text will contain newline characters. A
message can consist of several lines. It is also possible that a
message doesn't end with a newline, and a caller can use multiple
messages to "build" a line. Most messages will contain exactly 1 line
ending with a single newline character, though.
If the message buffer overflows (messages are not read quickly enough),
new messages are lost until the queued up messages are read. At the
point of the overflow, a special overflow message is inserted. It will
have prefix set to "overflow", and the message text is set to "".
Care should be taken not to print any messages from the message event
handler. This would lead to an infinite loop (the event handler would be
called again after returning, because a new message is available). This
includes mp.log() and all mp.msg.* functions. Keep in mind that the Lua
print() function is mapped to mp.msg.info().
2014-01-16 20:34:58 +00:00
|
|
|
static int script_enable_messages(lua_State *L)
|
|
|
|
{
|
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
2014-02-10 20:03:59 +00:00
|
|
|
check_loglevel(L, 1);
|
|
|
|
const char *level = luaL_checkstring(L, 1);
|
|
|
|
return check_error(L, mpv_request_log_messages(ctx->client, level));
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
}
|
|
|
|
|
2014-02-10 21:42:20 +00:00
|
|
|
static int script_command(lua_State *L)
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
{
|
2014-02-10 20:03:59 +00:00
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
const char *s = luaL_checkstring(L, 1);
|
|
|
|
|
2014-02-10 20:03:59 +00:00
|
|
|
return check_error(L, mpv_command_string(ctx->client, s));
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
}
|
|
|
|
|
2014-02-10 21:42:20 +00:00
|
|
|
static int script_commandv(lua_State *L)
|
2013-12-20 17:01:04 +00:00
|
|
|
{
|
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
int num = lua_gettop(L);
|
2014-02-10 20:03:59 +00:00
|
|
|
const char *args[50];
|
|
|
|
if (num + 1 > MP_ARRAY_SIZE(args))
|
2013-12-20 17:01:04 +00:00
|
|
|
luaL_error(L, "too many arguments");
|
|
|
|
for (int n = 1; n <= num; n++) {
|
2014-02-10 20:03:59 +00:00
|
|
|
const char *s = lua_tostring(L, n);
|
2013-12-20 17:01:04 +00:00
|
|
|
if (!s)
|
|
|
|
luaL_error(L, "argument %d is not a string", n);
|
2014-02-10 20:03:59 +00:00
|
|
|
args[n - 1] = s;
|
2013-12-20 17:01:04 +00:00
|
|
|
}
|
2014-02-10 20:03:59 +00:00
|
|
|
args[num] = NULL;
|
|
|
|
return check_error(L, mpv_command(ctx->client, args));
|
2013-12-20 17:01:04 +00:00
|
|
|
}
|
|
|
|
|
2014-02-10 23:23:10 +00:00
|
|
|
static int script_set_property(lua_State *L)
|
|
|
|
{
|
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
const char *p = luaL_checkstring(L, 1);
|
|
|
|
const char *v = luaL_checkstring(L, 2);
|
|
|
|
|
|
|
|
return check_error(L, mpv_set_property_string(ctx->client, p, v));
|
|
|
|
}
|
|
|
|
|
2014-02-24 19:47:20 +00:00
|
|
|
static int script_set_property_bool(lua_State *L)
|
|
|
|
{
|
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
const char *p = luaL_checkstring(L, 1);
|
|
|
|
int v = lua_toboolean(L, 2);
|
|
|
|
|
|
|
|
return check_error(L, mpv_set_property(ctx->client, p, MPV_FORMAT_FLAG, &v));
|
|
|
|
}
|
|
|
|
|
2014-02-26 21:33:23 +00:00
|
|
|
static bool is_int(double d)
|
|
|
|
{
|
|
|
|
int64_t v = d;
|
|
|
|
return d == (double)v;
|
|
|
|
}
|
|
|
|
|
2014-02-24 19:47:20 +00:00
|
|
|
static int script_set_property_number(lua_State *L)
|
|
|
|
{
|
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
const char *p = luaL_checkstring(L, 1);
|
|
|
|
double d = luaL_checknumber(L, 2);
|
|
|
|
// If the number might be an integer, then set it as integer. The mpv core
|
|
|
|
// will (probably) convert INT64 to DOUBLE when setting, but not the other
|
|
|
|
// way around.
|
|
|
|
int res;
|
2014-02-26 21:33:23 +00:00
|
|
|
if (is_int(d)) {
|
|
|
|
res = mpv_set_property(ctx->client, p, MPV_FORMAT_INT64, &(int64_t){d});
|
2014-02-24 19:47:20 +00:00
|
|
|
} else {
|
|
|
|
res = mpv_set_property(ctx->client, p, MPV_FORMAT_DOUBLE, &d);
|
|
|
|
}
|
|
|
|
return check_error(L, res);
|
|
|
|
}
|
|
|
|
|
2014-02-26 21:33:23 +00:00
|
|
|
static void makenode(void *tmp, mpv_node *dst, lua_State *L, int t)
|
|
|
|
{
|
|
|
|
if (t < 0)
|
|
|
|
t = lua_gettop(L) + (t + 1);
|
|
|
|
switch (lua_type(L, t)) {
|
|
|
|
case LUA_TNIL:
|
|
|
|
dst->format = MPV_FORMAT_NONE;
|
|
|
|
break;
|
|
|
|
case LUA_TNUMBER: {
|
|
|
|
double d = lua_tonumber(L, t);
|
|
|
|
if (is_int(d)) {
|
|
|
|
dst->format = MPV_FORMAT_INT64;
|
|
|
|
dst->u.int64 = d;
|
|
|
|
} else {
|
|
|
|
dst->format = MPV_FORMAT_DOUBLE;
|
|
|
|
dst->u.double_ = d;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case LUA_TBOOLEAN:
|
|
|
|
dst->format = MPV_FORMAT_FLAG;
|
|
|
|
dst->u.flag = !!lua_toboolean(L, t);
|
|
|
|
break;
|
|
|
|
case LUA_TSTRING:
|
|
|
|
dst->format = MPV_FORMAT_STRING;
|
|
|
|
dst->u.string = talloc_strdup(tmp, lua_tostring(L, t));
|
|
|
|
break;
|
|
|
|
case LUA_TTABLE: {
|
|
|
|
// Lua uses the same type for arrays and maps, so guess the correct one.
|
|
|
|
int format = MPV_FORMAT_NONE;
|
|
|
|
if (lua_getmetatable(L, t)) { // mt
|
|
|
|
lua_getfield(L, -1, "type"); // mt val
|
|
|
|
if (lua_type(L, -1) == LUA_TSTRING) {
|
|
|
|
const char *type = lua_tostring(L, -1);
|
|
|
|
if (strcmp(type, "MAP") == 0) {
|
|
|
|
format = MPV_FORMAT_NODE_MAP;
|
|
|
|
} else if (strcmp(type, "ARRAY") == 0) {
|
|
|
|
format = MPV_FORMAT_NODE_ARRAY;
|
|
|
|
}
|
|
|
|
}
|
2014-04-24 00:30:19 +00:00
|
|
|
lua_pop(L, 2);
|
2014-02-26 21:33:23 +00:00
|
|
|
}
|
|
|
|
if (format == MPV_FORMAT_NONE) {
|
|
|
|
// If all keys are integers, and they're in sequence, take it
|
|
|
|
// as an array.
|
|
|
|
int count = 0;
|
|
|
|
for (int n = 1; ; n++) {
|
|
|
|
lua_pushinteger(L, n); // n
|
|
|
|
lua_gettable(L, t); // t[n]
|
|
|
|
bool empty = lua_isnil(L, -1); // t[n]
|
|
|
|
lua_pop(L, 1); // -
|
|
|
|
if (empty) {
|
|
|
|
count = n;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (count > 0)
|
|
|
|
format = MPV_FORMAT_NODE_ARRAY;
|
|
|
|
lua_pushnil(L); // nil
|
|
|
|
while (lua_next(L, t) != 0) { // key value
|
|
|
|
count--;
|
|
|
|
lua_pop(L, 1); // key
|
|
|
|
if (count < 0) {
|
|
|
|
lua_pop(L, 1); // -
|
|
|
|
format = MPV_FORMAT_NODE_MAP;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (format == MPV_FORMAT_NONE)
|
|
|
|
format = MPV_FORMAT_NODE_ARRAY; // probably empty table; assume array
|
|
|
|
mpv_node_list *list = talloc_zero(tmp, mpv_node_list);
|
|
|
|
dst->format = format;
|
|
|
|
dst->u.list = list;
|
|
|
|
if (format == MPV_FORMAT_NODE_ARRAY) {
|
|
|
|
for (int n = 0; ; n++) {
|
|
|
|
lua_pushinteger(L, n + 1); // n1
|
|
|
|
lua_gettable(L, t); // t[n1]
|
|
|
|
if (lua_isnil(L, -1))
|
|
|
|
break;
|
|
|
|
MP_TARRAY_GROW(tmp, list->values, list->num);
|
|
|
|
makenode(tmp, &list->values[n], L, -1);
|
|
|
|
list->num++;
|
|
|
|
lua_pop(L, 1); // -
|
|
|
|
}
|
|
|
|
lua_pop(L, 1); // -
|
|
|
|
} else {
|
|
|
|
lua_pushnil(L); // nil
|
|
|
|
while (lua_next(L, t) != 0) { // key value
|
|
|
|
MP_TARRAY_GROW(tmp, list->values, list->num);
|
|
|
|
MP_TARRAY_GROW(tmp, list->keys, list->num);
|
|
|
|
makenode(tmp, &list->values[list->num], L, -1);
|
|
|
|
if (lua_type(L, -2) != LUA_TSTRING) {
|
|
|
|
talloc_free(tmp);
|
|
|
|
luaL_error(L, "key must be a string, but got %s",
|
|
|
|
lua_typename(L, -2));
|
|
|
|
}
|
|
|
|
list->keys[list->num] = talloc_strdup(tmp, lua_tostring(L, -2));
|
|
|
|
list->num++;
|
|
|
|
lua_pop(L, 1); // key
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
// unknown type
|
|
|
|
talloc_free(tmp);
|
|
|
|
luaL_error(L, "disallowed Lua type found: %s\n", lua_typename(L, t));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int script_set_property_native(lua_State *L)
|
|
|
|
{
|
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
const char *p = luaL_checkstring(L, 1);
|
|
|
|
struct mpv_node node;
|
|
|
|
void *tmp = talloc_new(NULL);
|
|
|
|
makenode(tmp, &node, L, 2);
|
|
|
|
int res = mpv_set_property(ctx->client, p, MPV_FORMAT_NODE, &node);
|
|
|
|
talloc_free(tmp);
|
|
|
|
return check_error(L, res);
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2014-02-10 21:42:20 +00:00
|
|
|
static int script_get_property(lua_State *L)
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
{
|
2014-02-10 20:03:59 +00:00
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
const char *name = luaL_checkstring(L, 1);
|
|
|
|
int type = lua_tointeger(L, lua_upvalueindex(1))
|
2014-02-10 20:03:59 +00:00
|
|
|
? MPV_FORMAT_OSD_STRING : MPV_FORMAT_STRING;
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
|
|
|
|
char *result = NULL;
|
2014-02-10 20:03:59 +00:00
|
|
|
int err = mpv_get_property(ctx->client, name, type, &result);
|
|
|
|
if (err >= 0) {
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
lua_pushstring(L, result);
|
|
|
|
talloc_free(result);
|
|
|
|
return 1;
|
2014-02-24 19:47:20 +00:00
|
|
|
} else {
|
|
|
|
if (lua_isnoneornil(L, 2) && type == MPV_FORMAT_OSD_STRING) {
|
|
|
|
lua_pushstring(L, "");
|
|
|
|
} else {
|
|
|
|
lua_pushvalue(L, 2);
|
|
|
|
}
|
|
|
|
lua_pushstring(L, mpv_error_string(err));
|
|
|
|
return 2;
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
}
|
2014-02-24 19:47:20 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int script_get_property_bool(lua_State *L)
|
|
|
|
{
|
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
const char *name = luaL_checkstring(L, 1);
|
|
|
|
|
|
|
|
int result = 0;
|
|
|
|
int err = mpv_get_property(ctx->client, name, MPV_FORMAT_FLAG, &result);
|
|
|
|
if (err >= 0) {
|
|
|
|
lua_pushboolean(L, !!result);
|
|
|
|
return 1;
|
|
|
|
} else {
|
|
|
|
lua_pushvalue(L, 2);
|
|
|
|
lua_pushstring(L, mpv_error_string(err));
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int script_get_property_number(lua_State *L)
|
|
|
|
{
|
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
const char *name = luaL_checkstring(L, 1);
|
|
|
|
|
|
|
|
// Note: the mpv core will (hopefully) convert INT64 to DOUBLE
|
|
|
|
double result = 0;
|
|
|
|
int err = mpv_get_property(ctx->client, name, MPV_FORMAT_DOUBLE, &result);
|
|
|
|
if (err >= 0) {
|
|
|
|
lua_pushnumber(L, result);
|
|
|
|
return 1;
|
|
|
|
} else {
|
|
|
|
lua_pushvalue(L, 2);
|
2014-02-10 23:10:25 +00:00
|
|
|
lua_pushstring(L, mpv_error_string(err));
|
2014-02-16 23:19:30 +00:00
|
|
|
return 2;
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
}
|
2014-02-24 19:47:20 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static bool pushnode(lua_State *L, mpv_node *node, int depth)
|
|
|
|
{
|
|
|
|
depth--;
|
|
|
|
if (depth < 0)
|
|
|
|
return false;
|
|
|
|
luaL_checkstack(L, 6, "stack overflow");
|
|
|
|
|
|
|
|
switch (node->format) {
|
|
|
|
case MPV_FORMAT_STRING:
|
|
|
|
lua_pushstring(L, node->u.string);
|
|
|
|
break;
|
|
|
|
case MPV_FORMAT_INT64:
|
|
|
|
lua_pushnumber(L, node->u.int64);
|
|
|
|
break;
|
|
|
|
case MPV_FORMAT_DOUBLE:
|
|
|
|
lua_pushnumber(L, node->u.double_);
|
|
|
|
break;
|
|
|
|
case MPV_FORMAT_NONE:
|
|
|
|
lua_pushnil(L);
|
|
|
|
break;
|
|
|
|
case MPV_FORMAT_FLAG:
|
|
|
|
lua_pushboolean(L, node->u.flag);
|
|
|
|
break;
|
|
|
|
case MPV_FORMAT_NODE_ARRAY:
|
|
|
|
lua_newtable(L); // table
|
2014-02-26 21:32:57 +00:00
|
|
|
lua_getfield(L, LUA_REGISTRYINDEX, "ARRAY"); // table mt
|
|
|
|
lua_setmetatable(L, -2); // table
|
2014-02-24 19:47:20 +00:00
|
|
|
for (int n = 0; n < node->u.list->num; n++) {
|
|
|
|
if (!pushnode(L, &node->u.list->values[n], depth)) // table value
|
|
|
|
return false;
|
|
|
|
lua_rawseti(L, -2, n + 1); // table
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case MPV_FORMAT_NODE_MAP:
|
|
|
|
lua_newtable(L); // table
|
2014-02-26 21:32:57 +00:00
|
|
|
lua_getfield(L, LUA_REGISTRYINDEX, "MAP"); // table mt
|
|
|
|
lua_setmetatable(L, -2); // table
|
2014-02-24 19:47:20 +00:00
|
|
|
for (int n = 0; n < node->u.list->num; n++) {
|
|
|
|
lua_pushstring(L, node->u.list->keys[n]); // table key
|
|
|
|
if (!pushnode(L, &node->u.list->values[n], depth)) // table key value
|
|
|
|
return false;
|
|
|
|
lua_rawset(L, -3);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
// unknown value - what do we do?
|
|
|
|
// for now, set a unique dummy value
|
2014-02-26 21:32:57 +00:00
|
|
|
lua_newtable(L); // table
|
2014-02-24 19:47:20 +00:00
|
|
|
lua_getfield(L, LUA_REGISTRYINDEX, "UNKNOWN_TYPE");
|
2014-02-26 21:32:57 +00:00
|
|
|
lua_setmetatable(L, -2); // table
|
2014-02-24 19:47:20 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int script_get_property_native(lua_State *L)
|
|
|
|
{
|
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
const char *name = luaL_checkstring(L, 1);
|
|
|
|
|
|
|
|
mpv_node node;
|
|
|
|
int err = mpv_get_property(ctx->client, name, MPV_FORMAT_NODE, &node);
|
|
|
|
const char *errstr = mpv_error_string(err);
|
|
|
|
if (err >= 0) {
|
|
|
|
bool ok = pushnode(L, &node, 50);
|
|
|
|
mpv_free_node_contents(&node);
|
|
|
|
if (ok)
|
|
|
|
return 1;
|
|
|
|
errstr = "value too large";
|
|
|
|
}
|
|
|
|
lua_pushvalue(L, 2);
|
|
|
|
lua_pushstring(L, errstr);
|
|
|
|
return 2;
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
}
|
|
|
|
|
2014-04-06 01:22:17 +00:00
|
|
|
static mpv_format check_property_format(lua_State *L, int arg)
|
|
|
|
{
|
2014-04-08 19:10:00 +00:00
|
|
|
if (lua_isnil(L, arg))
|
|
|
|
return MPV_FORMAT_NONE;
|
2014-04-06 01:22:17 +00:00
|
|
|
const char *fmts[] = {"none", "native", "bool", "string", "number", NULL};
|
|
|
|
switch (luaL_checkoption(L, arg, "none", fmts)) {
|
|
|
|
case 0: return MPV_FORMAT_NONE;
|
|
|
|
case 1: return MPV_FORMAT_NODE;
|
|
|
|
case 2: return MPV_FORMAT_FLAG;
|
|
|
|
case 3: return MPV_FORMAT_STRING;
|
|
|
|
case 4: return MPV_FORMAT_DOUBLE;
|
|
|
|
}
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
|
2014-04-08 19:10:00 +00:00
|
|
|
// It has a raw_ prefix, because there is a more high level API in defaults.lua.
|
|
|
|
static int script_raw_observe_property(lua_State *L)
|
2014-04-06 01:22:17 +00:00
|
|
|
{
|
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
uint64_t id = luaL_checknumber(L, 1);
|
|
|
|
const char *name = luaL_checkstring(L, 2);
|
|
|
|
mpv_format format = check_property_format(L, 3);
|
|
|
|
return check_error(L, mpv_observe_property(ctx->client, id, name, format));
|
|
|
|
}
|
|
|
|
|
2014-04-08 19:10:00 +00:00
|
|
|
static int script_raw_unobserve_property(lua_State *L)
|
2014-04-06 01:22:17 +00:00
|
|
|
{
|
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
uint64_t id = luaL_checknumber(L, 1);
|
|
|
|
lua_pushnumber(L, mpv_unobserve_property(ctx->client, id));
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
static int script_set_osd_ass(lua_State *L)
|
|
|
|
{
|
|
|
|
struct MPContext *mpctx = get_mpctx(L);
|
|
|
|
int res_x = luaL_checkinteger(L, 1);
|
|
|
|
int res_y = luaL_checkinteger(L, 2);
|
|
|
|
const char *text = luaL_checkstring(L, 3);
|
2014-01-18 00:19:20 +00:00
|
|
|
osd_set_external(mpctx->osd, res_x, res_y, (char *)text);
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int script_get_osd_resolution(lua_State *L)
|
|
|
|
{
|
|
|
|
struct MPContext *mpctx = get_mpctx(L);
|
|
|
|
int w, h;
|
2014-01-18 00:19:20 +00:00
|
|
|
osd_object_get_resolution(mpctx->osd, OSDTYPE_EXTERNAL, &w, &h);
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
lua_pushnumber(L, w);
|
|
|
|
lua_pushnumber(L, h);
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int script_get_screen_size(lua_State *L)
|
|
|
|
{
|
|
|
|
struct MPContext *mpctx = get_mpctx(L);
|
2014-01-18 00:19:20 +00:00
|
|
|
struct mp_osd_res vo_res = osd_get_vo_res(mpctx->osd, OSDTYPE_EXTERNAL);
|
|
|
|
double aspect = 1.0 * vo_res.w / MPMAX(vo_res.h, 1) /
|
|
|
|
vo_res.display_par;
|
|
|
|
lua_pushnumber(L, vo_res.w);
|
|
|
|
lua_pushnumber(L, vo_res.h);
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
lua_pushnumber(L, aspect);
|
|
|
|
return 3;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int script_get_mouse_pos(lua_State *L)
|
|
|
|
{
|
|
|
|
struct MPContext *mpctx = get_mpctx(L);
|
2013-09-27 13:39:28 +00:00
|
|
|
int px, py;
|
|
|
|
mp_input_get_mouse_pos(mpctx->input, &px, &py);
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
double sw, sh;
|
2014-01-18 00:19:20 +00:00
|
|
|
osd_object_get_scale_factor(mpctx->osd, OSDTYPE_EXTERNAL, &sw, &sh);
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
lua_pushnumber(L, px * sw);
|
|
|
|
lua_pushnumber(L, py * sh);
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
|
2014-02-10 21:42:20 +00:00
|
|
|
static int script_get_time(lua_State *L)
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
{
|
2014-02-24 20:59:20 +00:00
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
lua_pushnumber(L, mpv_get_time_us(ctx->client) / (double)(1000 * 1000));
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int script_input_define_section(lua_State *L)
|
|
|
|
{
|
|
|
|
struct MPContext *mpctx = get_mpctx(L);
|
|
|
|
char *section = (char *)luaL_checkstring(L, 1);
|
|
|
|
char *contents = (char *)luaL_checkstring(L, 2);
|
2014-02-17 01:38:07 +00:00
|
|
|
char *flags = (char *)luaL_optstring(L, 3, "");
|
|
|
|
bool builtin = true;
|
2014-02-25 23:59:19 +00:00
|
|
|
if (strcmp(flags, "default") == 0) {
|
2014-02-17 01:38:07 +00:00
|
|
|
builtin = true;
|
2014-02-25 23:59:19 +00:00
|
|
|
} else if (strcmp(flags, "force") == 0) {
|
2014-02-17 01:38:07 +00:00
|
|
|
builtin = false;
|
|
|
|
} else if (strcmp(flags, "") == 0) {
|
|
|
|
//pass
|
|
|
|
} else {
|
2014-02-28 23:40:22 +00:00
|
|
|
luaL_error(L, "invalid flags: '%s'", flags);
|
2014-02-17 01:38:07 +00:00
|
|
|
}
|
|
|
|
mp_input_define_section(mpctx->input, section, "<script>", contents, builtin);
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int script_input_enable_section(lua_State *L)
|
|
|
|
{
|
|
|
|
struct MPContext *mpctx = get_mpctx(L);
|
|
|
|
char *section = (char *)luaL_checkstring(L, 1);
|
|
|
|
char *sflags = (char *)luaL_optstring(L, 2, "");
|
|
|
|
bstr bflags = bstr0(sflags);
|
|
|
|
int flags = 0;
|
|
|
|
while (bflags.len) {
|
|
|
|
bstr val;
|
|
|
|
bstr_split_tok(bflags, "|", &val, &bflags);
|
|
|
|
if (bstr_equals0(val, "allow-hide-cursor")) {
|
|
|
|
flags |= MP_INPUT_ALLOW_HIDE_CURSOR;
|
|
|
|
} else if (bstr_equals0(val, "allow-vo-dragging")) {
|
|
|
|
flags |= MP_INPUT_ALLOW_VO_DRAGGING;
|
|
|
|
} else if (bstr_equals0(val, "exclusive")) {
|
|
|
|
flags |= MP_INPUT_EXCLUSIVE;
|
|
|
|
} else {
|
|
|
|
luaL_error(L, "invalid flag: '%.*s'", BSTR_P(val));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
mp_input_enable_section(mpctx->input, section, flags);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int script_input_disable_section(lua_State *L)
|
|
|
|
{
|
|
|
|
struct MPContext *mpctx = get_mpctx(L);
|
|
|
|
char *section = (char *)luaL_checkstring(L, 1);
|
|
|
|
mp_input_disable_section(mpctx->input, section);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int script_input_set_section_mouse_area(lua_State *L)
|
|
|
|
{
|
|
|
|
struct MPContext *mpctx = get_mpctx(L);
|
|
|
|
|
|
|
|
double sw, sh;
|
2014-01-18 00:19:20 +00:00
|
|
|
osd_object_get_scale_factor(mpctx->osd, OSDTYPE_EXTERNAL, &sw, &sh);
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
|
|
|
|
char *section = (char *)luaL_checkstring(L, 1);
|
|
|
|
int x0 = luaL_checkinteger(L, 2) / sw;
|
|
|
|
int y0 = luaL_checkinteger(L, 3) / sh;
|
|
|
|
int x1 = luaL_checkinteger(L, 4) / sw;
|
|
|
|
int y1 = luaL_checkinteger(L, 5) / sh;
|
|
|
|
mp_input_set_section_mouse_area(mpctx->input, section, x0, y0, x1, y1);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int script_format_time(lua_State *L)
|
|
|
|
{
|
|
|
|
double t = luaL_checknumber(L, 1);
|
|
|
|
const char *fmt = luaL_optstring(L, 2, "%H:%M:%S");
|
|
|
|
char *r = mp_format_time_fmt(fmt, t);
|
|
|
|
if (!r)
|
|
|
|
luaL_error(L, "Invalid time format string '%s'", fmt);
|
|
|
|
lua_pushstring(L, r);
|
|
|
|
talloc_free(r);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2014-04-12 18:13:53 +00:00
|
|
|
static int script_get_wakeup_pipe(lua_State *L)
|
|
|
|
{
|
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
lua_pushinteger(L, mpv_get_wakeup_pipe(ctx->client));
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2014-05-25 17:51:11 +00:00
|
|
|
static int script_readdir(lua_State *L)
|
|
|
|
{
|
|
|
|
// 0 1 2 3
|
|
|
|
const char *fmts[] = {"all", "files", "dirs", "normal", NULL};
|
|
|
|
const char *path = luaL_checkstring(L, 1);
|
|
|
|
int t = luaL_checkoption(L, 2, "normal", fmts);
|
|
|
|
DIR *dir = opendir(path);
|
|
|
|
if (!dir) {
|
|
|
|
lua_pushnil(L);
|
|
|
|
lua_pushstring(L, "error");
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
lua_newtable(L); // list
|
|
|
|
char *fullpath = NULL;
|
|
|
|
struct dirent *e;
|
|
|
|
int n = 0;
|
|
|
|
while ((e = readdir(dir))) {
|
|
|
|
char *name = e->d_name;
|
|
|
|
if (t) {
|
|
|
|
if (strcmp(name, ".") == 0 || strcmp(name, "..") == 0)
|
|
|
|
continue;
|
|
|
|
if (fullpath)
|
|
|
|
fullpath[0] = '\0';
|
|
|
|
fullpath = talloc_asprintf_append(fullpath, "%s/%s", path, name);
|
|
|
|
struct stat st;
|
|
|
|
if (mp_stat(fullpath, &st))
|
|
|
|
continue;
|
|
|
|
if (!(((t & 1) && S_ISREG(st.st_mode)) ||
|
|
|
|
((t & 2) && S_ISDIR(st.st_mode))))
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
lua_pushinteger(L, ++n); // list index
|
|
|
|
lua_pushstring(L, name); // list index name
|
|
|
|
lua_settable(L, -3); // list
|
|
|
|
}
|
|
|
|
talloc_free(fullpath);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int script_split_path(lua_State *L)
|
|
|
|
{
|
|
|
|
const char *p = luaL_checkstring(L, 1);
|
|
|
|
bstr fname = mp_dirname(p);
|
|
|
|
lua_pushlstring(L, fname.start, fname.len);
|
|
|
|
lua_pushstring(L, mp_basename(p));
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int script_join_path(lua_State *L)
|
|
|
|
{
|
|
|
|
const char *p1 = luaL_checkstring(L, 1);
|
|
|
|
const char *p2 = luaL_checkstring(L, 2);
|
|
|
|
char *r = mp_path_join(NULL, bstr0(p1), bstr0(p2));
|
|
|
|
lua_pushstring(L, r);
|
|
|
|
talloc_free(r);
|
|
|
|
return 1;
|
|
|
|
}
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
|
|
|
|
#define FN_ENTRY(name) {#name, script_ ## name}
|
2014-05-26 19:46:01 +00:00
|
|
|
struct fn_entry {
|
|
|
|
const char *name;
|
|
|
|
int (*fn)(lua_State *L);
|
|
|
|
};
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
|
2014-05-26 19:46:01 +00:00
|
|
|
static const struct fn_entry main_fns[] = {
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
FN_ENTRY(log),
|
2014-02-10 20:03:59 +00:00
|
|
|
FN_ENTRY(suspend),
|
|
|
|
FN_ENTRY(resume),
|
2014-02-10 23:57:40 +00:00
|
|
|
FN_ENTRY(resume_all),
|
2014-02-10 20:03:59 +00:00
|
|
|
FN_ENTRY(wait_event),
|
|
|
|
FN_ENTRY(request_event),
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
FN_ENTRY(find_config_file),
|
2014-02-10 21:42:20 +00:00
|
|
|
FN_ENTRY(command),
|
|
|
|
FN_ENTRY(commandv),
|
2014-02-24 19:47:20 +00:00
|
|
|
FN_ENTRY(get_property_bool),
|
|
|
|
FN_ENTRY(get_property_number),
|
|
|
|
FN_ENTRY(get_property_native),
|
2014-02-10 23:23:10 +00:00
|
|
|
FN_ENTRY(set_property),
|
2014-02-24 19:47:20 +00:00
|
|
|
FN_ENTRY(set_property_bool),
|
|
|
|
FN_ENTRY(set_property_number),
|
2014-02-26 21:33:23 +00:00
|
|
|
FN_ENTRY(set_property_native),
|
2014-04-08 19:10:00 +00:00
|
|
|
FN_ENTRY(raw_observe_property),
|
|
|
|
FN_ENTRY(raw_unobserve_property),
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
FN_ENTRY(set_osd_ass),
|
|
|
|
FN_ENTRY(get_osd_resolution),
|
|
|
|
FN_ENTRY(get_screen_size),
|
|
|
|
FN_ENTRY(get_mouse_pos),
|
2014-02-10 21:42:20 +00:00
|
|
|
FN_ENTRY(get_time),
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
FN_ENTRY(input_define_section),
|
|
|
|
FN_ENTRY(input_enable_section),
|
|
|
|
FN_ENTRY(input_disable_section),
|
|
|
|
FN_ENTRY(input_set_section_mouse_area),
|
|
|
|
FN_ENTRY(format_time),
|
lua: allow scripts to snoop messages
Adds the following Lua function to enable message events:
mp.enable_messages(size, level)
size is the maximum number of messages the ringbuffer consists of. level
is the minimum log level for a message to be added to the ringbuffer,
and uses the same values as the mp.log() function. (Actually not yet,
but this will be fixed in the following commit.)
The messages will be delivered via the mp_event() in the user script,
using "message" as event name. The event argument is a table with the
following fields:
level: log level of the message (string as in mp.log())
prefix: string identifying the module of origin
text: contents of the message
As of currently, the message text will contain newline characters. A
message can consist of several lines. It is also possible that a
message doesn't end with a newline, and a caller can use multiple
messages to "build" a line. Most messages will contain exactly 1 line
ending with a single newline character, though.
If the message buffer overflows (messages are not read quickly enough),
new messages are lost until the queued up messages are read. At the
point of the overflow, a special overflow message is inserted. It will
have prefix set to "overflow", and the message text is set to "".
Care should be taken not to print any messages from the message event
handler. This would lead to an infinite loop (the event handler would be
called again after returning, because a new message is available). This
includes mp.log() and all mp.msg.* functions. Keep in mind that the Lua
print() function is mapped to mp.msg.info().
2014-01-16 20:34:58 +00:00
|
|
|
FN_ENTRY(enable_messages),
|
2014-04-12 18:13:53 +00:00
|
|
|
FN_ENTRY(get_wakeup_pipe),
|
2014-05-25 17:51:11 +00:00
|
|
|
{0}
|
|
|
|
};
|
|
|
|
|
2014-06-10 21:56:05 +00:00
|
|
|
static const struct fn_entry utils_fns[] = {
|
2014-05-25 17:51:11 +00:00
|
|
|
FN_ENTRY(readdir),
|
|
|
|
FN_ENTRY(split_path),
|
|
|
|
FN_ENTRY(join_path),
|
|
|
|
{0}
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
};
|
|
|
|
|
2014-05-26 19:46:01 +00:00
|
|
|
static void register_package_fns(lua_State *L, char *module,
|
|
|
|
const struct fn_entry *e)
|
|
|
|
{
|
|
|
|
push_module_table(L, module); // modtable
|
|
|
|
for (int n = 0; e[n].name; n++) {
|
|
|
|
lua_pushcclosure(L, e[n].fn, 0); // modtable fn
|
|
|
|
lua_setfield(L, -2, e[n].name); // modtable
|
|
|
|
}
|
|
|
|
lua_pop(L, 1); // -
|
|
|
|
}
|
|
|
|
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
static void add_functions(struct script_ctx *ctx)
|
|
|
|
{
|
|
|
|
lua_State *L = ctx->state;
|
|
|
|
|
2014-05-26 19:46:01 +00:00
|
|
|
register_package_fns(L, "mp", main_fns);
|
|
|
|
|
|
|
|
push_module_table(L, "mp"); // mp
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
|
|
|
|
lua_pushinteger(L, 0);
|
2014-02-10 21:42:20 +00:00
|
|
|
lua_pushcclosure(L, script_get_property, 1);
|
|
|
|
lua_setfield(L, -2, "get_property");
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
|
|
|
|
lua_pushinteger(L, 1);
|
2014-02-10 21:42:20 +00:00
|
|
|
lua_pushcclosure(L, script_get_property, 1);
|
|
|
|
lua_setfield(L, -2, "get_property_osd");
|
2014-05-25 17:51:11 +00:00
|
|
|
|
|
|
|
lua_pop(L, 1); // -
|
|
|
|
|
2014-05-26 19:46:01 +00:00
|
|
|
register_package_fns(L, "mp.utils", utils_fns);
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
}
|
|
|
|
|
2014-05-12 23:14:07 +00:00
|
|
|
const struct mp_scripting mp_scripting_lua = {
|
|
|
|
.file_ext = "lua",
|
|
|
|
.load = load_lua,
|
|
|
|
};
|