2014-03-07 11:46:33 +00:00
|
|
|
/*
|
|
|
|
* This file is part of mpv.
|
|
|
|
*
|
Relicense some non-MPlayer source files to LGPL 2.1 or later
This covers source files which were added in mplayer2 and mpv times
only, and where all code is covered by LGPL relicensing agreements.
There are probably more files to which this applies, but I'm being
conservative here.
A file named ao_sdl.c exists in MPlayer too, but the mpv one is a
complete rewrite, and was added some time after the original ao_sdl.c
was removed. The same applies to vo_sdl.c, for which the SDL2 API is
radically different in addition (MPlayer supports SDL 1.2 only).
common.c contains only code written by me. But common.h is a strange
case: although it originally was named mp_common.h and exists in MPlayer
too, by now it contains only definitions written by uau and me. The
exceptions are the CONTROL_ defines - thus not changing the license of
common.h yet.
codec_tags.c contained once large tables generated from MPlayer's
codecs.conf, but all of these tables were removed.
From demux_playlist.c I'm removing a code fragment from someone who was
not asked; this probably could be done later (see commit 15dccc37).
misc.c is a bit complicated to reason about (it was split off mplayer.c
and thus contains random functions out of this file), but actually all
functions have been added post-MPlayer. Except get_relative_time(),
which was written by uau, but looks similar to 3 different versions of
something similar in each of the Unix/win32/OSX timer source files. I'm
not sure what that means in regards to copyright, so I've just moved it
into another still-GPL source file for now.
screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but
they're all gone.
2016-01-19 17:36:06 +00:00
|
|
|
* mpv is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
2014-03-07 11:46:33 +00:00
|
|
|
*
|
|
|
|
* 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
|
Relicense some non-MPlayer source files to LGPL 2.1 or later
This covers source files which were added in mplayer2 and mpv times
only, and where all code is covered by LGPL relicensing agreements.
There are probably more files to which this applies, but I'm being
conservative here.
A file named ao_sdl.c exists in MPlayer too, but the mpv one is a
complete rewrite, and was added some time after the original ao_sdl.c
was removed. The same applies to vo_sdl.c, for which the SDL2 API is
radically different in addition (MPlayer supports SDL 1.2 only).
common.c contains only code written by me. But common.h is a strange
case: although it originally was named mp_common.h and exists in MPlayer
too, by now it contains only definitions written by uau and me. The
exceptions are the CONTROL_ defines - thus not changing the license of
common.h yet.
codec_tags.c contained once large tables generated from MPlayer's
codecs.conf, but all of these tables were removed.
From demux_playlist.c I'm removing a code fragment from someone who was
not asked; this probably could be done later (see commit 15dccc37).
misc.c is a bit complicated to reason about (it was split off mplayer.c
and thus contains random functions out of this file), but actually all
functions have been added post-MPlayer. Except get_relative_time(),
which was written by uau, but looks similar to 3 different versions of
something similar in each of the Unix/win32/OSX timer source files. I'm
not sure what that means in regards to copyright, so I've just moved it
into another still-GPL source file for now.
screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but
they're all gone.
2016-01-19 17:36:06 +00:00
|
|
|
* GNU Lesser General Public License for more details.
|
2014-03-07 11:46:33 +00:00
|
|
|
*
|
Relicense some non-MPlayer source files to LGPL 2.1 or later
This covers source files which were added in mplayer2 and mpv times
only, and where all code is covered by LGPL relicensing agreements.
There are probably more files to which this applies, but I'm being
conservative here.
A file named ao_sdl.c exists in MPlayer too, but the mpv one is a
complete rewrite, and was added some time after the original ao_sdl.c
was removed. The same applies to vo_sdl.c, for which the SDL2 API is
radically different in addition (MPlayer supports SDL 1.2 only).
common.c contains only code written by me. But common.h is a strange
case: although it originally was named mp_common.h and exists in MPlayer
too, by now it contains only definitions written by uau and me. The
exceptions are the CONTROL_ defines - thus not changing the license of
common.h yet.
codec_tags.c contained once large tables generated from MPlayer's
codecs.conf, but all of these tables were removed.
From demux_playlist.c I'm removing a code fragment from someone who was
not asked; this probably could be done later (see commit 15dccc37).
misc.c is a bit complicated to reason about (it was split off mplayer.c
and thus contains random functions out of this file), but actually all
functions have been added post-MPlayer. Except get_relative_time(),
which was written by uau, but looks similar to 3 different versions of
something similar in each of the Unix/win32/OSX timer source files. I'm
not sure what that means in regards to copyright, so I've just moved it
into another still-GPL source file for now.
screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but
they're all gone.
2016-01-19 17:36:06 +00:00
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
|
2014-03-07 11:46:33 +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
|
|
|
#include <assert.h>
|
|
|
|
#include <string.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>
|
2014-02-24 19:47:20 +00:00
|
|
|
#include <math.h>
|
2014-02-14 12:49:10 +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
|
|
|
#include <lua.h>
|
|
|
|
#include <lualib.h>
|
|
|
|
#include <lauxlib.h>
|
|
|
|
|
2014-12-15 13:40:13 +00:00
|
|
|
#include "osdep/io.h"
|
|
|
|
|
2016-01-11 18:03:40 +00:00
|
|
|
#include "mpv_talloc.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
|
|
|
|
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"
|
stats: some more performance graphs
Add an infrastructure for collecting performance-related data, use it in
some places. Add rendering of them to stats.lua.
There were two main goals: minimal impact on the normal code and normal
playback. So all these stats_* function calls either happen only during
initialization, or return immediately if no stats collection is going
on. That's why it does this lazily adding of stats entries etc. (a first
iteration made each stats entry an API thing, instead of just a single
stats_ctx, but I thought that was getting too intrusive in the "normal"
code, even if everything gets worse inside of stats.c).
You could get most of this information from various profilers (including
the extremely primitive --dump-stats thing in mpv), but this makes it
easier to see the most important information at once (at least in
theory), partially because we know best about the context of various
things.
Not very happy with this. It's all pretty primitive and dumb. At this
point I just wanted to get over with it, without necessarily having to
revisit it later, but with having my stupid statistics.
Somehow the code feels terrible. There are a lot of meh decisions in
there that could be better or worse (but mostly could be better), and it
just sucks but it's also trivial and uninteresting and does the job. I
guess I hate programming. It's so tedious and the result is always shit.
Anyway, enjoy.
2020-04-08 22:27:54 +00:00
|
|
|
#include "common/stats.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"
|
2014-08-29 10:09:04 +00:00
|
|
|
#include "misc/bstr.h"
|
2014-10-19 03:27:35 +00:00
|
|
|
#include "misc/json.h"
|
2014-11-22 06:21:33 +00:00
|
|
|
#include "osdep/subprocess.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"
|
lua: add an utility function for starting processes
Because 1) Lua is terrible, and 2) popen() is terrible. Unfortunately,
since Unix is also terrible, this turned out more complicated than I
hoped. As a consequence and to avoid that this code has to be maintained
forever, add a disclaimer that any function in Lua's utils module can
disappear any time. The complexity seems a bit ridiculous, especially
for a feature so far removed from actual video playback, so if it turns
out that we don't really need this function, it will be dropped again.
The motivation for this commit is the same as with 8e4fa5fc.
Note that there is an "#ifndef __GLIBC__". The GNU people are very
special people and thought it'd be convenient to actually declare
"environ", even though the POSIX people, which are also very special
people, state that no header declares this and that the user has to
declare this manually. Since the GNU people overtook the Unix world with
their very clever "embrace, extend, extinguish" strategy, but not 100%,
and trying to build without _GNU_SOURCE is hopeless; but since there
might be Unix environments which support _GNU_SOURCE features partially,
this means that in practice "environ" will be randomly declared or not
declared by system headers. Also, gcc was written by very clever people
too, and prints a warning if an external variable is declared twice (I
didn't check, but I suppose redeclaring is legal C, and not even the gcc
people are clever enough to only warn against a definitely not legal C
construct, although sometimes they do this), ...and since we at mpv hate
compiler warnings, we seek to silence them all. Adding a configure test
just for a warning seems too radical, so we special-case this against
__GLIBC__, which is hopefully not defined on other libcs, especially not
libcs which don't implement all aspects of _GNU_SOURCE, and redefine
"environ" on systems even if the headers define it already (because they
support _GNU_SOURCE - as I mentioned before, the clever GNU people wrote
software THAT portable that other libcs just gave up and implemented
parts of _GNU_SOURCE, although probably not all), which means that
compiling mpv will print a warning about "environ" being redefined, but
at least this won't happen on my system, so all is fine. However, should
someone complain about this warning, I will force whoever complained
about this warning to read this ENTIRE commit message, and if possible,
will also force them to eat a printed-out copy of the GNU Manifesto, and
if that is not enough, maybe this person could even be forced to
convince the very clever POSIX people of not doing crap like this:
having the user to manually declare somewhat central symbols - but I
doubt it's possible, because the POSIX people are too far gone and only
care about maintaining compatibility with old versions of AIX and HP-UX.
Oh, also, this code contains some subtle and obvious issues, but writing
about this is not fun.
2014-10-18 23:42:28 +00:00
|
|
|
#include "stream/stream.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",
|
2023-07-23 22:54:35 +00:00
|
|
|
# include "player/lua/defaults.lua.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",
|
2023-07-23 22:54:35 +00:00
|
|
|
# include "player/lua/assdraw.lua.inc"
|
2024-01-02 17:58:32 +00:00
|
|
|
},
|
|
|
|
{"mp.input",
|
|
|
|
# include "player/lua/input.lua.inc"
|
2014-05-23 11:24:27 +00:00
|
|
|
},
|
|
|
|
{"mp.options",
|
2023-07-23 22:54:35 +00:00
|
|
|
# include "player/lua/options.lua.inc"
|
2013-09-25 22:56:41 +00:00
|
|
|
},
|
2014-05-12 23:14:07 +00:00
|
|
|
{"@osc.lua",
|
2023-07-23 22:54:35 +00:00
|
|
|
# include "player/lua/osc.lua.inc"
|
2014-11-19 17:51:53 +00:00
|
|
|
},
|
|
|
|
{"@ytdl_hook.lua",
|
2023-07-23 22:54:35 +00:00
|
|
|
# include "player/lua/ytdl_hook.lua.inc"
|
2017-09-26 23:17:47 +00:00
|
|
|
},
|
|
|
|
{"@stats.lua",
|
2023-07-23 22:54:35 +00:00
|
|
|
# include "player/lua/stats.lua.inc"
|
2019-12-07 16:16:10 +00:00
|
|
|
},
|
|
|
|
{"@console.lua",
|
2023-07-23 22:54:35 +00:00
|
|
|
# include "player/lua/console.lua.inc"
|
2020-08-05 20:37:47 +00:00
|
|
|
},
|
|
|
|
{"@auto_profiles.lua",
|
2023-07-23 22:54:35 +00:00
|
|
|
# include "player/lua/auto_profiles.lua.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;
|
2020-02-01 17:10:07 +00:00
|
|
|
const char *path; // NULL if single file
|
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;
|
stats: some more performance graphs
Add an infrastructure for collecting performance-related data, use it in
some places. Add rendering of them to stats.lua.
There were two main goals: minimal impact on the normal code and normal
playback. So all these stats_* function calls either happen only during
initialization, or return immediately if no stats collection is going
on. That's why it does this lazily adding of stats entries etc. (a first
iteration made each stats entry an API thing, instead of just a single
stats_ctx, but I thought that was getting too intrusive in the "normal"
code, even if everything gets worse inside of stats.c).
You could get most of this information from various profilers (including
the extremely primitive --dump-stats thing in mpv), but this makes it
easier to see the most important information at once (at least in
theory), partially because we know best about the context of various
things.
Not very happy with this. It's all pretty primitive and dumb. At this
point I just wanted to get over with it, without necessarily having to
revisit it later, but with having my stupid statistics.
Somehow the code feels terrible. There are a lot of meh decisions in
there that could be better or worse (but mostly could be better), and it
just sucks but it's also trivial and uninteresting and does the job. I
guess I hate programming. It's so tedious and the result is always shit.
Anyway, enjoy.
2020-04-08 22:27:54 +00:00
|
|
|
size_t lua_malloc_size;
|
2020-04-09 00:18:48 +00:00
|
|
|
lua_Alloc lua_allocf;
|
|
|
|
void *lua_alloc_ud;
|
stats: some more performance graphs
Add an infrastructure for collecting performance-related data, use it in
some places. Add rendering of them to stats.lua.
There were two main goals: minimal impact on the normal code and normal
playback. So all these stats_* function calls either happen only during
initialization, or return immediately if no stats collection is going
on. That's why it does this lazily adding of stats entries etc. (a first
iteration made each stats entry an API thing, instead of just a single
stats_ctx, but I thought that was getting too intrusive in the "normal"
code, even if everything gets worse inside of stats.c).
You could get most of this information from various profilers (including
the extremely primitive --dump-stats thing in mpv), but this makes it
easier to see the most important information at once (at least in
theory), partially because we know best about the context of various
things.
Not very happy with this. It's all pretty primitive and dumb. At this
point I just wanted to get over with it, without necessarily having to
revisit it later, but with having my stupid statistics.
Somehow the code feels terrible. There are a lot of meh decisions in
there that could be better or worse (but mostly could be better), and it
just sucks but it's also trivial and uninteresting and does the job. I
guess I hate programming. It's so tedious and the result is always shit.
Anyway, enjoy.
2020-04-08 22:27:54 +00:00
|
|
|
struct stats_ctx *stats;
|
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
|
2014-10-19 05:37:46 +00:00
|
|
|
#define mp_lua_len lua_objlen
|
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
|
|
|
#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);
|
|
|
|
}
|
2014-10-19 05:37:46 +00:00
|
|
|
#define mp_lua_len lua_rawlen
|
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
|
|
|
#endif
|
|
|
|
|
2014-10-21 23:10:15 +00:00
|
|
|
// Ensure that the given argument exists, even if it's nil. Can be used to
|
|
|
|
// avoid confusing the last missing optional arg with the first temporary value
|
|
|
|
// pushed to the stack.
|
|
|
|
static void mp_lua_optarg(lua_State *L, int arg)
|
|
|
|
{
|
2014-10-23 13:11:49 +00:00
|
|
|
while (arg > lua_gettop(L))
|
2014-10-21 23:10:15 +00:00
|
|
|
lua_pushnil(L);
|
|
|
|
}
|
|
|
|
|
lua: autofree infrastructure: x2 faster
The speedup is due to moving big part of the autofree runtime overhead
(new lua c closure) to happen once on init at af_pushcclosure, instead
of on every call. This also allows supporting upvalues trivially, even
if mpv doesn't use it currently, and is more consistent with lua APIs.
While x2 infrastructure speedup is meaningful - and similar between
lua 5.1/5.2/jit, in practice it's a much smaller improvement because
the autofree overhead is typically small compared to the "real" work
(the actual functionality, and talloc+free which is needed anyway).
So with this commit, fast functions improve more in percentage.
E.g. utils.parse_json("0") is relatively fast and is now about 25%
faster, while a slower call like mp.command_native("ignore") is now
about 10% faster than before. If we had mp.noop() which does nothing
(but still "needs" alloc/free) - it would now be about 50% faster.
Overall, it's a mild performance improvements, the API is now more
consistent with lua, and without increasing code size or complexity.
2020-03-23 08:48:13 +00:00
|
|
|
// autofree: avoid leaks if a lua-error occurs between talloc new/free.
|
|
|
|
// If a lua c-function does a new allocation (not tied to an existing context),
|
2023-03-28 15:16:42 +00:00
|
|
|
// and an uncaught lua-error occurs before "free" - the allocation is leaked.
|
lua: autofree infrastructure: x2 faster
The speedup is due to moving big part of the autofree runtime overhead
(new lua c closure) to happen once on init at af_pushcclosure, instead
of on every call. This also allows supporting upvalues trivially, even
if mpv doesn't use it currently, and is more consistent with lua APIs.
While x2 infrastructure speedup is meaningful - and similar between
lua 5.1/5.2/jit, in practice it's a much smaller improvement because
the autofree overhead is typically small compared to the "real" work
(the actual functionality, and talloc+free which is needed anyway).
So with this commit, fast functions improve more in percentage.
E.g. utils.parse_json("0") is relatively fast and is now about 25%
faster, while a slower call like mp.command_native("ignore") is now
about 10% faster than before. If we had mp.noop() which does nothing
(but still "needs" alloc/free) - it would now be about 50% faster.
Overall, it's a mild performance improvements, the API is now more
consistent with lua, and without increasing code size or complexity.
2020-03-23 08:48:13 +00:00
|
|
|
|
2020-03-22 20:07:26 +00:00
|
|
|
// autofree lua C function: same as lua_CFunction but with these differences:
|
lua: autofree infrastructure: x2 faster
The speedup is due to moving big part of the autofree runtime overhead
(new lua c closure) to happen once on init at af_pushcclosure, instead
of on every call. This also allows supporting upvalues trivially, even
if mpv doesn't use it currently, and is more consistent with lua APIs.
While x2 infrastructure speedup is meaningful - and similar between
lua 5.1/5.2/jit, in practice it's a much smaller improvement because
the autofree overhead is typically small compared to the "real" work
(the actual functionality, and talloc+free which is needed anyway).
So with this commit, fast functions improve more in percentage.
E.g. utils.parse_json("0") is relatively fast and is now about 25%
faster, while a slower call like mp.command_native("ignore") is now
about 10% faster than before. If we had mp.noop() which does nothing
(but still "needs" alloc/free) - it would now be about 50% faster.
Overall, it's a mild performance improvements, the API is now more
consistent with lua, and without increasing code size or complexity.
2020-03-23 08:48:13 +00:00
|
|
|
// - It accepts an additional void* argument - a pre-initialized talloc context
|
|
|
|
// which it can use, and which is freed with its children once the function
|
2022-04-25 11:27:18 +00:00
|
|
|
// completes - regardless if a lua error occurred or not. If a lua error did
|
lua: autofree infrastructure: x2 faster
The speedup is due to moving big part of the autofree runtime overhead
(new lua c closure) to happen once on init at af_pushcclosure, instead
of on every call. This also allows supporting upvalues trivially, even
if mpv doesn't use it currently, and is more consistent with lua APIs.
While x2 infrastructure speedup is meaningful - and similar between
lua 5.1/5.2/jit, in practice it's a much smaller improvement because
the autofree overhead is typically small compared to the "real" work
(the actual functionality, and talloc+free which is needed anyway).
So with this commit, fast functions improve more in percentage.
E.g. utils.parse_json("0") is relatively fast and is now about 25%
faster, while a slower call like mp.command_native("ignore") is now
about 10% faster than before. If we had mp.noop() which does nothing
(but still "needs" alloc/free) - it would now be about 50% faster.
Overall, it's a mild performance improvements, the API is now more
consistent with lua, and without increasing code size or complexity.
2020-03-23 08:48:13 +00:00
|
|
|
// occur then it's re-thrown after the ctx is freed.
|
|
|
|
// The stack/arguments/upvalues/return are the same as with lua_CFunction.
|
|
|
|
// - It's inserted into the lua VM using af_pushc{function,closure} instead of
|
|
|
|
// lua_pushc{function,closure}, which takes care of wrapping it with the
|
2022-04-25 11:27:18 +00:00
|
|
|
// automatic talloc allocation + lua-error-handling + talloc release.
|
lua: autofree infrastructure: x2 faster
The speedup is due to moving big part of the autofree runtime overhead
(new lua c closure) to happen once on init at af_pushcclosure, instead
of on every call. This also allows supporting upvalues trivially, even
if mpv doesn't use it currently, and is more consistent with lua APIs.
While x2 infrastructure speedup is meaningful - and similar between
lua 5.1/5.2/jit, in practice it's a much smaller improvement because
the autofree overhead is typically small compared to the "real" work
(the actual functionality, and talloc+free which is needed anyway).
So with this commit, fast functions improve more in percentage.
E.g. utils.parse_json("0") is relatively fast and is now about 25%
faster, while a slower call like mp.command_native("ignore") is now
about 10% faster than before. If we had mp.noop() which does nothing
(but still "needs" alloc/free) - it would now be about 50% faster.
Overall, it's a mild performance improvements, the API is now more
consistent with lua, and without increasing code size or complexity.
2020-03-23 08:48:13 +00:00
|
|
|
// This requires using AF_ENTRY instead of FN_ENTRY at struct fn_entry.
|
|
|
|
// - The autofree overhead per call is roughly two additional plain lua calls.
|
|
|
|
// Typically that's up to 20% slower than plain new+free without "auto",
|
|
|
|
// and at most about twice slower - compared to bare new+free lua_CFunction.
|
2022-04-25 11:27:18 +00:00
|
|
|
// - The overhead of af_push* is one additional lua-c-closure with two upvalues.
|
2020-03-22 20:07:26 +00:00
|
|
|
typedef int (*af_CFunction)(lua_State *L, void *ctx);
|
2014-10-18 22:09:27 +00:00
|
|
|
|
lua: autofree infrastructure: x2 faster
The speedup is due to moving big part of the autofree runtime overhead
(new lua c closure) to happen once on init at af_pushcclosure, instead
of on every call. This also allows supporting upvalues trivially, even
if mpv doesn't use it currently, and is more consistent with lua APIs.
While x2 infrastructure speedup is meaningful - and similar between
lua 5.1/5.2/jit, in practice it's a much smaller improvement because
the autofree overhead is typically small compared to the "real" work
(the actual functionality, and talloc+free which is needed anyway).
So with this commit, fast functions improve more in percentage.
E.g. utils.parse_json("0") is relatively fast and is now about 25%
faster, while a slower call like mp.command_native("ignore") is now
about 10% faster than before. If we had mp.noop() which does nothing
(but still "needs" alloc/free) - it would now be about 50% faster.
Overall, it's a mild performance improvements, the API is now more
consistent with lua, and without increasing code size or complexity.
2020-03-23 08:48:13 +00:00
|
|
|
static void af_pushcclosure(lua_State *L, af_CFunction fn, int n);
|
|
|
|
#define af_pushcfunction(L, fn) af_pushcclosure((L), (fn), 0)
|
|
|
|
|
|
|
|
|
2020-03-22 20:52:53 +00:00
|
|
|
// add_af_dir, add_af_mpv_alloc take a valid DIR*/char* value respectively,
|
|
|
|
// and closedir/mpv_free it when the parent is freed.
|
|
|
|
|
|
|
|
static void destruct_af_dir(void *p)
|
|
|
|
{
|
|
|
|
closedir(*(DIR**)p);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void add_af_dir(void *parent, DIR *d)
|
|
|
|
{
|
|
|
|
DIR **pd = talloc(parent, DIR*);
|
|
|
|
*pd = d;
|
|
|
|
talloc_set_destructor(pd, destruct_af_dir);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void destruct_af_mpv_alloc(void *p)
|
|
|
|
{
|
|
|
|
mpv_free(*(char**)p);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void add_af_mpv_alloc(void *parent, char *ma)
|
|
|
|
{
|
|
|
|
char **p = talloc(parent, char*);
|
|
|
|
*p = ma;
|
|
|
|
talloc_set_destructor(p, destruct_af_mpv_alloc);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-10-19 03:46:16 +00:00
|
|
|
// Perform the equivalent of mpv_free_node_contents(node) when tmp is freed.
|
2023-03-28 15:16:42 +00:00
|
|
|
static void steal_node_allocations(void *tmp, mpv_node *node)
|
2014-10-19 03:46:16 +00:00
|
|
|
{
|
|
|
|
talloc_steal(tmp, node_get_alloc(node));
|
|
|
|
}
|
|
|
|
|
2020-04-09 00:18:48 +00:00
|
|
|
// lua_Alloc compatible. Serves only to track memory usage. This wraps the
|
|
|
|
// existing allocator, partly because luajit requires the use of its internal
|
|
|
|
// allocator on 64-bit platforms.
|
stats: some more performance graphs
Add an infrastructure for collecting performance-related data, use it in
some places. Add rendering of them to stats.lua.
There were two main goals: minimal impact on the normal code and normal
playback. So all these stats_* function calls either happen only during
initialization, or return immediately if no stats collection is going
on. That's why it does this lazily adding of stats entries etc. (a first
iteration made each stats entry an API thing, instead of just a single
stats_ctx, but I thought that was getting too intrusive in the "normal"
code, even if everything gets worse inside of stats.c).
You could get most of this information from various profilers (including
the extremely primitive --dump-stats thing in mpv), but this makes it
easier to see the most important information at once (at least in
theory), partially because we know best about the context of various
things.
Not very happy with this. It's all pretty primitive and dumb. At this
point I just wanted to get over with it, without necessarily having to
revisit it later, but with having my stupid statistics.
Somehow the code feels terrible. There are a lot of meh decisions in
there that could be better or worse (but mostly could be better), and it
just sucks but it's also trivial and uninteresting and does the job. I
guess I hate programming. It's so tedious and the result is always shit.
Anyway, enjoy.
2020-04-08 22:27:54 +00:00
|
|
|
static void *mp_lua_alloc(void *ud, void *ptr, size_t osize, size_t nsize)
|
|
|
|
{
|
|
|
|
struct script_ctx *ctx = ud;
|
|
|
|
|
|
|
|
// Ah, what the fuck, screw whoever introduced this to Lua 5.2.
|
|
|
|
if (!ptr)
|
|
|
|
osize = 0;
|
|
|
|
|
2020-04-09 00:18:48 +00:00
|
|
|
ptr = ctx->lua_allocf(ctx->lua_alloc_ud, ptr, osize, nsize);
|
|
|
|
if (nsize && !ptr)
|
|
|
|
return NULL; // allocation failed, so original memory left untouched
|
stats: some more performance graphs
Add an infrastructure for collecting performance-related data, use it in
some places. Add rendering of them to stats.lua.
There were two main goals: minimal impact on the normal code and normal
playback. So all these stats_* function calls either happen only during
initialization, or return immediately if no stats collection is going
on. That's why it does this lazily adding of stats entries etc. (a first
iteration made each stats entry an API thing, instead of just a single
stats_ctx, but I thought that was getting too intrusive in the "normal"
code, even if everything gets worse inside of stats.c).
You could get most of this information from various profilers (including
the extremely primitive --dump-stats thing in mpv), but this makes it
easier to see the most important information at once (at least in
theory), partially because we know best about the context of various
things.
Not very happy with this. It's all pretty primitive and dumb. At this
point I just wanted to get over with it, without necessarily having to
revisit it later, but with having my stupid statistics.
Somehow the code feels terrible. There are a lot of meh decisions in
there that could be better or worse (but mostly could be better), and it
just sucks but it's also trivial and uninteresting and does the job. I
guess I hate programming. It's so tedious and the result is always shit.
Anyway, enjoy.
2020-04-08 22:27:54 +00:00
|
|
|
|
|
|
|
ctx->lua_malloc_size = ctx->lua_malloc_size - osize + nsize;
|
|
|
|
stats_size_value(ctx->stats, "mem", ctx->lua_malloc_size);
|
|
|
|
|
|
|
|
return ptr;
|
|
|
|
}
|
|
|
|
|
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);
|
2014-10-25 15:20:25 +00:00
|
|
|
MP_WARN(ctx, "%s\n", tr ? tr : "(unknown)");
|
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
|
|
|
}
|
|
|
|
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);
|
2017-09-28 09:53:57 +00:00
|
|
|
MP_DBG(ctx, "loading file %s\n", fname);
|
2022-03-23 09:11:03 +00:00
|
|
|
void *tmp = talloc_new(ctx);
|
2022-04-25 11:27:18 +00:00
|
|
|
// according to Lua manual chunkname should be '@' plus the filename
|
2022-03-23 09:11:03 +00:00
|
|
|
char *dispname = talloc_asprintf(tmp, "@%s", fname);
|
|
|
|
struct bstr s = stream_read_file(fname, tmp, ctx->mpctx->global, 100000000);
|
2020-05-10 14:46:21 +00:00
|
|
|
if (!s.start)
|
|
|
|
luaL_error(L, "Could not read file.\n");
|
2022-03-23 09:11:03 +00:00
|
|
|
if (luaL_loadbuffer(L, s.start, s.len, dispname))
|
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
|
|
|
lua_error(L);
|
2020-05-10 14:46:21 +00:00
|
|
|
lua_call(L, 0, 1);
|
2022-03-23 09:11:03 +00:00
|
|
|
talloc_free(tmp);
|
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);
|
2017-09-28 09:53:57 +00:00
|
|
|
MP_DBG(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;
|
|
|
|
}
|
|
|
|
|
lua: fix highly security relevant arbitrary code execution bug
It appears Lua's package paths try to load .lua files from the current
working directory. Not only that, but also shared libraries.
WHAT THE FUCK IS WHOEVER IS RESPONSIBLE FOR THIS FUCKING DOING?
mpv isn't setting this package path; currently it's only extending it.
In any sane world, this wouldn't be a default. Most programs use
essentially random working directories and don't change it.
I cannot comprehend what bullshit about "convenience" or whatever made
them do something this broken and dangerous. Thousands of programs using
Lua out there will try to randomly load random code from random
directories.
In mpv's case, this is so security relevant, because mpv is normally
used from the command line, and you will most likely actually change
into your media directory or whatever with the shell, and play a file
from there. No, you don't want to load a (probably downloaded) shared
library from this directory if a script try to load a system lib with
the same name or so.
I'm not sure why LUA_PATH_DEFAULT in luaconf.h (both upstream and the
Debian version) put "./?.lua" at the end, but in any case, trying to
load a module that doesn't exist nicely lists all package paths in
order, and confirms it tries to load files from the working directory
first (anyone can try this). Even if it didn't, this would be
problematic at best.
Note that scripts are _not_ sandboxed. They're allowed to load system
libraries, which is also why we want to keep the non-idiotic parts of
the package paths.
Attempt to fix this by filtering out relative paths. This is a bit
fragile and not very great for something security related, but probably
the best we can do without having to make assumptions about the target
system file system layout. Also, someone else can fix this for Windows.
Also replace ":" with ";" (for the extra path). On a side note, this
extra path addition is just in this function out of laziness, since
I'd rather not have 2 functions with edit the package path.
mpv in default configuration (i.e. no external scripts) is probably not
affected. All builtin scripts only "require" preloaded modules, which,
in a stroke of genius by the Lua developers, are highest priority in the
load order. Otherwise, enjoy your semi-remote code execution bug.
Completely unrelated this, I'm open for scripting languages and
especially implementations which are all around better than Lua, and are
suited for low footprint embedding.
2020-02-05 15:20:37 +00:00
|
|
|
static void fuck_lua(lua_State *L, const char *search_path, const char *extra)
|
2020-02-01 17:10:07 +00:00
|
|
|
{
|
|
|
|
void *tmp = talloc_new(NULL);
|
|
|
|
|
|
|
|
lua_getglobal(L, "package"); // package
|
lua: fix highly security relevant arbitrary code execution bug
It appears Lua's package paths try to load .lua files from the current
working directory. Not only that, but also shared libraries.
WHAT THE FUCK IS WHOEVER IS RESPONSIBLE FOR THIS FUCKING DOING?
mpv isn't setting this package path; currently it's only extending it.
In any sane world, this wouldn't be a default. Most programs use
essentially random working directories and don't change it.
I cannot comprehend what bullshit about "convenience" or whatever made
them do something this broken and dangerous. Thousands of programs using
Lua out there will try to randomly load random code from random
directories.
In mpv's case, this is so security relevant, because mpv is normally
used from the command line, and you will most likely actually change
into your media directory or whatever with the shell, and play a file
from there. No, you don't want to load a (probably downloaded) shared
library from this directory if a script try to load a system lib with
the same name or so.
I'm not sure why LUA_PATH_DEFAULT in luaconf.h (both upstream and the
Debian version) put "./?.lua" at the end, but in any case, trying to
load a module that doesn't exist nicely lists all package paths in
order, and confirms it tries to load files from the working directory
first (anyone can try this). Even if it didn't, this would be
problematic at best.
Note that scripts are _not_ sandboxed. They're allowed to load system
libraries, which is also why we want to keep the non-idiotic parts of
the package paths.
Attempt to fix this by filtering out relative paths. This is a bit
fragile and not very great for something security related, but probably
the best we can do without having to make assumptions about the target
system file system layout. Also, someone else can fix this for Windows.
Also replace ":" with ";" (for the extra path). On a side note, this
extra path addition is just in this function out of laziness, since
I'd rather not have 2 functions with edit the package path.
mpv in default configuration (i.e. no external scripts) is probably not
affected. All builtin scripts only "require" preloaded modules, which,
in a stroke of genius by the Lua developers, are highest priority in the
load order. Otherwise, enjoy your semi-remote code execution bug.
Completely unrelated this, I'm open for scripting languages and
especially implementations which are all around better than Lua, and are
suited for low footprint embedding.
2020-02-05 15:20:37 +00:00
|
|
|
lua_getfield(L, -1, search_path); // package search_path
|
|
|
|
bstr path = bstr0(lua_tostring(L, -1));
|
|
|
|
char *newpath = talloc_strdup(tmp, "");
|
|
|
|
|
|
|
|
// Script-directory paths take priority.
|
|
|
|
if (extra) {
|
|
|
|
newpath = talloc_asprintf_append(newpath, "%s%s",
|
|
|
|
newpath[0] ? ";" : "",
|
|
|
|
mp_path_join(tmp, extra, "?.lua"));
|
|
|
|
}
|
2020-02-01 17:10:07 +00:00
|
|
|
|
lua: fix highly security relevant arbitrary code execution bug
It appears Lua's package paths try to load .lua files from the current
working directory. Not only that, but also shared libraries.
WHAT THE FUCK IS WHOEVER IS RESPONSIBLE FOR THIS FUCKING DOING?
mpv isn't setting this package path; currently it's only extending it.
In any sane world, this wouldn't be a default. Most programs use
essentially random working directories and don't change it.
I cannot comprehend what bullshit about "convenience" or whatever made
them do something this broken and dangerous. Thousands of programs using
Lua out there will try to randomly load random code from random
directories.
In mpv's case, this is so security relevant, because mpv is normally
used from the command line, and you will most likely actually change
into your media directory or whatever with the shell, and play a file
from there. No, you don't want to load a (probably downloaded) shared
library from this directory if a script try to load a system lib with
the same name or so.
I'm not sure why LUA_PATH_DEFAULT in luaconf.h (both upstream and the
Debian version) put "./?.lua" at the end, but in any case, trying to
load a module that doesn't exist nicely lists all package paths in
order, and confirms it tries to load files from the working directory
first (anyone can try this). Even if it didn't, this would be
problematic at best.
Note that scripts are _not_ sandboxed. They're allowed to load system
libraries, which is also why we want to keep the non-idiotic parts of
the package paths.
Attempt to fix this by filtering out relative paths. This is a bit
fragile and not very great for something security related, but probably
the best we can do without having to make assumptions about the target
system file system layout. Also, someone else can fix this for Windows.
Also replace ":" with ";" (for the extra path). On a side note, this
extra path addition is just in this function out of laziness, since
I'd rather not have 2 functions with edit the package path.
mpv in default configuration (i.e. no external scripts) is probably not
affected. All builtin scripts only "require" preloaded modules, which,
in a stroke of genius by the Lua developers, are highest priority in the
load order. Otherwise, enjoy your semi-remote code execution bug.
Completely unrelated this, I'm open for scripting languages and
especially implementations which are all around better than Lua, and are
suited for low footprint embedding.
2020-02-05 15:20:37 +00:00
|
|
|
// Unbelievable but true: Lua loads .lua files AND dynamic libraries from
|
|
|
|
// the working directory. This is highly security relevant.
|
|
|
|
// Lua scripts are still supposed to load globally installed libraries, so
|
|
|
|
// try to get by by filtering out any relative paths.
|
|
|
|
while (path.len) {
|
|
|
|
bstr item;
|
|
|
|
bstr_split_tok(path, ";", &item, &path);
|
2020-02-06 13:15:31 +00:00
|
|
|
if (mp_path_is_absolute(item)) {
|
lua: fix highly security relevant arbitrary code execution bug
It appears Lua's package paths try to load .lua files from the current
working directory. Not only that, but also shared libraries.
WHAT THE FUCK IS WHOEVER IS RESPONSIBLE FOR THIS FUCKING DOING?
mpv isn't setting this package path; currently it's only extending it.
In any sane world, this wouldn't be a default. Most programs use
essentially random working directories and don't change it.
I cannot comprehend what bullshit about "convenience" or whatever made
them do something this broken and dangerous. Thousands of programs using
Lua out there will try to randomly load random code from random
directories.
In mpv's case, this is so security relevant, because mpv is normally
used from the command line, and you will most likely actually change
into your media directory or whatever with the shell, and play a file
from there. No, you don't want to load a (probably downloaded) shared
library from this directory if a script try to load a system lib with
the same name or so.
I'm not sure why LUA_PATH_DEFAULT in luaconf.h (both upstream and the
Debian version) put "./?.lua" at the end, but in any case, trying to
load a module that doesn't exist nicely lists all package paths in
order, and confirms it tries to load files from the working directory
first (anyone can try this). Even if it didn't, this would be
problematic at best.
Note that scripts are _not_ sandboxed. They're allowed to load system
libraries, which is also why we want to keep the non-idiotic parts of
the package paths.
Attempt to fix this by filtering out relative paths. This is a bit
fragile and not very great for something security related, but probably
the best we can do without having to make assumptions about the target
system file system layout. Also, someone else can fix this for Windows.
Also replace ":" with ";" (for the extra path). On a side note, this
extra path addition is just in this function out of laziness, since
I'd rather not have 2 functions with edit the package path.
mpv in default configuration (i.e. no external scripts) is probably not
affected. All builtin scripts only "require" preloaded modules, which,
in a stroke of genius by the Lua developers, are highest priority in the
load order. Otherwise, enjoy your semi-remote code execution bug.
Completely unrelated this, I'm open for scripting languages and
especially implementations which are all around better than Lua, and are
suited for low footprint embedding.
2020-02-05 15:20:37 +00:00
|
|
|
newpath = talloc_asprintf_append(newpath, "%s%.*s",
|
|
|
|
newpath[0] ? ";" : "",
|
|
|
|
BSTR_P(item));
|
|
|
|
}
|
|
|
|
}
|
2020-02-01 17:10:07 +00:00
|
|
|
|
lua: fix highly security relevant arbitrary code execution bug
It appears Lua's package paths try to load .lua files from the current
working directory. Not only that, but also shared libraries.
WHAT THE FUCK IS WHOEVER IS RESPONSIBLE FOR THIS FUCKING DOING?
mpv isn't setting this package path; currently it's only extending it.
In any sane world, this wouldn't be a default. Most programs use
essentially random working directories and don't change it.
I cannot comprehend what bullshit about "convenience" or whatever made
them do something this broken and dangerous. Thousands of programs using
Lua out there will try to randomly load random code from random
directories.
In mpv's case, this is so security relevant, because mpv is normally
used from the command line, and you will most likely actually change
into your media directory or whatever with the shell, and play a file
from there. No, you don't want to load a (probably downloaded) shared
library from this directory if a script try to load a system lib with
the same name or so.
I'm not sure why LUA_PATH_DEFAULT in luaconf.h (both upstream and the
Debian version) put "./?.lua" at the end, but in any case, trying to
load a module that doesn't exist nicely lists all package paths in
order, and confirms it tries to load files from the working directory
first (anyone can try this). Even if it didn't, this would be
problematic at best.
Note that scripts are _not_ sandboxed. They're allowed to load system
libraries, which is also why we want to keep the non-idiotic parts of
the package paths.
Attempt to fix this by filtering out relative paths. This is a bit
fragile and not very great for something security related, but probably
the best we can do without having to make assumptions about the target
system file system layout. Also, someone else can fix this for Windows.
Also replace ":" with ";" (for the extra path). On a side note, this
extra path addition is just in this function out of laziness, since
I'd rather not have 2 functions with edit the package path.
mpv in default configuration (i.e. no external scripts) is probably not
affected. All builtin scripts only "require" preloaded modules, which,
in a stroke of genius by the Lua developers, are highest priority in the
load order. Otherwise, enjoy your semi-remote code execution bug.
Completely unrelated this, I'm open for scripting languages and
especially implementations which are all around better than Lua, and are
suited for low footprint embedding.
2020-02-05 15:20:37 +00:00
|
|
|
lua_pushstring(L, newpath); // package search_path newpath
|
|
|
|
lua_setfield(L, -3, search_path); // package search_path
|
2020-02-01 17:10:07 +00:00
|
|
|
lua_pop(L, 2); // -
|
|
|
|
|
|
|
|
talloc_free(tmp);
|
|
|
|
}
|
|
|
|
|
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 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: fix highly security relevant arbitrary code execution bug
It appears Lua's package paths try to load .lua files from the current
working directory. Not only that, but also shared libraries.
WHAT THE FUCK IS WHOEVER IS RESPONSIBLE FOR THIS FUCKING DOING?
mpv isn't setting this package path; currently it's only extending it.
In any sane world, this wouldn't be a default. Most programs use
essentially random working directories and don't change it.
I cannot comprehend what bullshit about "convenience" or whatever made
them do something this broken and dangerous. Thousands of programs using
Lua out there will try to randomly load random code from random
directories.
In mpv's case, this is so security relevant, because mpv is normally
used from the command line, and you will most likely actually change
into your media directory or whatever with the shell, and play a file
from there. No, you don't want to load a (probably downloaded) shared
library from this directory if a script try to load a system lib with
the same name or so.
I'm not sure why LUA_PATH_DEFAULT in luaconf.h (both upstream and the
Debian version) put "./?.lua" at the end, but in any case, trying to
load a module that doesn't exist nicely lists all package paths in
order, and confirms it tries to load files from the working directory
first (anyone can try this). Even if it didn't, this would be
problematic at best.
Note that scripts are _not_ sandboxed. They're allowed to load system
libraries, which is also why we want to keep the non-idiotic parts of
the package paths.
Attempt to fix this by filtering out relative paths. This is a bit
fragile and not very great for something security related, but probably
the best we can do without having to make assumptions about the target
system file system layout. Also, someone else can fix this for Windows.
Also replace ":" with ";" (for the extra path). On a side note, this
extra path addition is just in this function out of laziness, since
I'd rather not have 2 functions with edit the package path.
mpv in default configuration (i.e. no external scripts) is probably not
affected. All builtin scripts only "require" preloaded modules, which,
in a stroke of genius by the Lua developers, are highest priority in the
load order. Otherwise, enjoy your semi-remote code execution bug.
Completely unrelated this, I'm open for scripting languages and
especially implementations which are all around better than Lua, and are
suited for low footprint embedding.
2020-02-05 15:20:37 +00:00
|
|
|
fuck_lua(L, "path", ctx->path);
|
|
|
|
fuck_lua(L, "cpath", NULL);
|
2020-02-01 17:10:07 +00:00
|
|
|
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
|
2014-10-24 19:56:45 +00:00
|
|
|
if (lua_pcall(L, 0, 0, -2)) { // errf [error]
|
|
|
|
const char *e = lua_tostring(L, -1);
|
|
|
|
MP_FATAL(ctx, "Lua error: %s\n", e ? e : "(unknown)");
|
|
|
|
}
|
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
|
|
|
|
scripting: load scripts from directories
The intention is to provide a slightly nicer way to distribute scripts.
For example, you could put multiple source files into the directory, and
then import them from the actual script file (this is still
unimplemented).
At first I wanted to require a config file (because you need to know at
least which scripting backend it should use). This wouldn't have been
too hard (could have reused/abused the mpv config file parsing
mechanism, and I already had working code that was just 2 function
calls). But probably better to do this without new config files, because
it might become a pain in the distant future.
So this just probes for "main.lua", "main.js", etc., until an existing
file is found.
Another important change is that this skips all directory entries whose
name starts with ".". This automatically excludes the "." and ".."
special directories, and is probably useful to exclude random crap that
might be lying around in the directory (such as editor temporary files,
or OSX, in its usual hrmful, annoying, and idiotic modus operandi,
sharting all over any directories opened by "Finder").
Although the changelog mentions the docs, they're added only in a later
commit.
2020-02-01 17:09:40 +00:00
|
|
|
static int load_lua(struct mp_script_args *args)
|
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 = -1;
|
|
|
|
|
|
|
|
struct script_ctx *ctx = talloc_ptrtype(NULL, ctx);
|
|
|
|
*ctx = (struct script_ctx) {
|
scripting: load scripts from directories
The intention is to provide a slightly nicer way to distribute scripts.
For example, you could put multiple source files into the directory, and
then import them from the actual script file (this is still
unimplemented).
At first I wanted to require a config file (because you need to know at
least which scripting backend it should use). This wouldn't have been
too hard (could have reused/abused the mpv config file parsing
mechanism, and I already had working code that was just 2 function
calls). But probably better to do this without new config files, because
it might become a pain in the distant future.
So this just probes for "main.lua", "main.js", etc., until an existing
file is found.
Another important change is that this skips all directory entries whose
name starts with ".". This automatically excludes the "." and ".."
special directories, and is probably useful to exclude random crap that
might be lying around in the directory (such as editor temporary files,
or OSX, in its usual hrmful, annoying, and idiotic modus operandi,
sharting all over any directories opened by "Finder").
Although the changelog mentions the docs, they're added only in a later
commit.
2020-02-01 17:09:40 +00:00
|
|
|
.mpctx = args->mpctx,
|
|
|
|
.client = args->client,
|
|
|
|
.name = mpv_client_name(args->client),
|
|
|
|
.log = args->log,
|
|
|
|
.filename = args->filename,
|
2020-02-01 17:10:07 +00:00
|
|
|
.path = args->path,
|
stats: some more performance graphs
Add an infrastructure for collecting performance-related data, use it in
some places. Add rendering of them to stats.lua.
There were two main goals: minimal impact on the normal code and normal
playback. So all these stats_* function calls either happen only during
initialization, or return immediately if no stats collection is going
on. That's why it does this lazily adding of stats entries etc. (a first
iteration made each stats entry an API thing, instead of just a single
stats_ctx, but I thought that was getting too intrusive in the "normal"
code, even if everything gets worse inside of stats.c).
You could get most of this information from various profilers (including
the extremely primitive --dump-stats thing in mpv), but this makes it
easier to see the most important information at once (at least in
theory), partially because we know best about the context of various
things.
Not very happy with this. It's all pretty primitive and dumb. At this
point I just wanted to get over with it, without necessarily having to
revisit it later, but with having my stupid statistics.
Somehow the code feels terrible. There are a lot of meh decisions in
there that could be better or worse (but mostly could be better), and it
just sucks but it's also trivial and uninteresting and does the job. I
guess I hate programming. It's so tedious and the result is always shit.
Anyway, enjoy.
2020-04-08 22:27:54 +00:00
|
|
|
.stats = stats_ctx_create(ctx, args->mpctx->global,
|
|
|
|
mp_tprintf(80, "script/%s", mpv_client_name(args->client))),
|
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
|
|
|
};
|
|
|
|
|
stats: some more performance graphs
Add an infrastructure for collecting performance-related data, use it in
some places. Add rendering of them to stats.lua.
There were two main goals: minimal impact on the normal code and normal
playback. So all these stats_* function calls either happen only during
initialization, or return immediately if no stats collection is going
on. That's why it does this lazily adding of stats entries etc. (a first
iteration made each stats entry an API thing, instead of just a single
stats_ctx, but I thought that was getting too intrusive in the "normal"
code, even if everything gets worse inside of stats.c).
You could get most of this information from various profilers (including
the extremely primitive --dump-stats thing in mpv), but this makes it
easier to see the most important information at once (at least in
theory), partially because we know best about the context of various
things.
Not very happy with this. It's all pretty primitive and dumb. At this
point I just wanted to get over with it, without necessarily having to
revisit it later, but with having my stupid statistics.
Somehow the code feels terrible. There are a lot of meh decisions in
there that could be better or worse (but mostly could be better), and it
just sucks but it's also trivial and uninteresting and does the job. I
guess I hate programming. It's so tedious and the result is always shit.
Anyway, enjoy.
2020-04-08 22:27:54 +00:00
|
|
|
stats_register_thread_cputime(ctx->stats, "cpu");
|
|
|
|
|
2015-04-01 21:59:09 +00:00
|
|
|
if (LUA_VERSION_NUM != 501 && LUA_VERSION_NUM != 502) {
|
|
|
|
MP_FATAL(ctx, "Only Lua 5.1 and 5.2 are supported.\n");
|
|
|
|
goto error_out;
|
|
|
|
}
|
|
|
|
|
2020-04-08 23:54:25 +00:00
|
|
|
lua_State *L = ctx->state = luaL_newstate();
|
2016-09-24 23:00:20 +00:00
|
|
|
if (!L) {
|
|
|
|
MP_FATAL(ctx, "Could not initialize Lua.\n");
|
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
|
|
|
goto error_out;
|
2016-09-24 23:00: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
|
|
|
|
2020-04-09 00:18:48 +00:00
|
|
|
// Wrap the internal allocator with our version that does accounting
|
|
|
|
ctx->lua_allocf = lua_getallocf(L, &ctx->lua_alloc_ud);
|
|
|
|
lua_setallocf(L, mp_lua_alloc, 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
|
|
|
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:
|
|
|
|
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);
|
2023-10-23 21:42:17 +00:00
|
|
|
int n = mp_msg_find_level(level);
|
|
|
|
if (n >= 0)
|
|
|
|
return n;
|
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
|
|
|
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");
|
2024-04-09 13:05:39 +00:00
|
|
|
mp_msg(ctx->log, msgl, (i == 2 ? "%s" : " %s"), 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
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2020-02-04 19:40:16 +00:00
|
|
|
static int script_get_script_directory(lua_State *L)
|
|
|
|
{
|
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
if (ctx->path) {
|
|
|
|
lua_pushstring(L, ctx->path);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-10-19 03:46:16 +00:00
|
|
|
static void pushnode(lua_State *L, mpv_node *node);
|
2014-04-06 01:22:17 +00:00
|
|
|
|
2020-03-22 20:52:53 +00:00
|
|
|
static int script_raw_wait_event(lua_State *L, void *tmp)
|
2014-02-10 20:03:59 +00:00
|
|
|
{
|
|
|
|
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-12-15 13:44:25 +00:00
|
|
|
mpv_event *event = mpv_wait_event(ctx->client, luaL_optnumber(L, 1, 1e20));
|
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
|
|
|
|
2020-03-21 21:09:07 +00:00
|
|
|
struct mpv_node rn;
|
|
|
|
mpv_event_to_node(&rn, event);
|
2023-03-28 15:16:42 +00:00
|
|
|
steal_node_allocations(tmp, &rn);
|
2014-04-08 19:10:00 +00:00
|
|
|
|
2020-03-21 21:17:05 +00:00
|
|
|
pushnode(L, &rn); // 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-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
|
|
|
const char *level = luaL_checkstring(L, 1);
|
2019-11-17 23:33:32 +00:00
|
|
|
int r = mpv_request_log_messages(ctx->client, level);
|
|
|
|
if (r == MPV_ERROR_INVALID_PARAMETER)
|
|
|
|
luaL_error(L, "Invalid log level '%s'", level);
|
|
|
|
return check_error(L, 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
|
|
|
}
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2022-12-16 21:22:33 +00:00
|
|
|
static int script_del_property(lua_State *L)
|
|
|
|
{
|
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
const char *p = luaL_checkstring(L, 1);
|
|
|
|
|
|
|
|
return check_error(L, mpv_del_property(ctx->client, p));
|
|
|
|
}
|
|
|
|
|
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)
|
|
|
|
{
|
lua: makenode: prevent lua stack corruption
Normally there was no issue, but when the code converted a deeply
nested table into an mpv node - it didn't ensure the stack has room.
Lua doesn't check stack overflow when invoking lua_push* functions,
and leaves this responsibility to the (c) user via lua_checkstack.
Normally that's not an issue because when a lua (or autofree) function
is called, it's guaranteed at least LUA_MINSTACK (20) pushes.
However, pushnode and makenode are recursive, and each iteration can
add few values at the stack (which are popped when the recursion
unwinds), so checkstack must be used on (recursive) entry.
pushnode already checked the stack, makenode did not.
This commit checks the stack at makenode as well. The value of 6
(stack places to reserve) is with some room to spare, and in pratice
each iteration needs 2-3 at most (pushnode also leaves room).
Example which could previously corrupt the stack:
utils.format_json({d1={d2={<8 more times>}}}
This uses makenode to convert the lua table into an mpv node which
the json writer uses as input, and if the depth is 10 or more then
corruption could occur. mp.command_native is also affected, as well as
any other mp/utils command which takes a lua table as input.
While at it, fix the error string which pushnode used (luaL_checkstack
uses the provided string with "Stack overflow (%s)", so the user
message only needs to be additional info).
2021-10-20 08:26:13 +00:00
|
|
|
luaL_checkstack(L, 6, "makenode");
|
|
|
|
|
2014-02-26 21:33:23 +00:00
|
|
|
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;
|
2020-08-16 00:56:38 +00:00
|
|
|
case LUA_TSTRING: {
|
|
|
|
size_t len = 0;
|
|
|
|
char *s = (char *)lua_tolstring(L, t, &len);
|
|
|
|
bool has_zeros = !!memchr(s, 0, len);
|
|
|
|
if (has_zeros) {
|
|
|
|
mpv_byte_array *ba = talloc_zero(tmp, mpv_byte_array);
|
|
|
|
*ba = (mpv_byte_array){talloc_memdup(tmp, s, len), len};
|
|
|
|
dst->format = MPV_FORMAT_BYTE_ARRAY;
|
|
|
|
dst->u.ba = ba;
|
|
|
|
} else {
|
|
|
|
dst->format = MPV_FORMAT_STRING;
|
|
|
|
dst->u.string = talloc_strdup(tmp, s);
|
|
|
|
}
|
2014-02-26 21:33:23 +00:00
|
|
|
break;
|
2020-08-16 00:56:38 +00:00
|
|
|
}
|
2014-02-26 21:33:23 +00:00
|
|
|
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) {
|
2016-09-24 15:52:36 +00:00
|
|
|
count = n - 1;
|
2014-02-26 21:33:23 +00:00
|
|
|
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) {
|
|
|
|
luaL_error(L, "key must be a string, but got %s",
|
2016-09-24 15:52:36 +00:00
|
|
|
lua_typename(L, lua_type(L, -2)));
|
2014-02-26 21:33:23 +00:00
|
|
|
}
|
|
|
|
list->keys[list->num] = talloc_strdup(tmp, lua_tostring(L, -2));
|
|
|
|
list->num++;
|
|
|
|
lua_pop(L, 1); // key
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
// unknown type
|
|
|
|
luaL_error(L, "disallowed Lua type found: %s\n", lua_typename(L, t));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-03-22 20:07:26 +00:00
|
|
|
static int script_set_property_native(lua_State *L, void *tmp)
|
2014-02-26 21:33:23 +00:00
|
|
|
{
|
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
const char *p = luaL_checkstring(L, 1);
|
|
|
|
struct mpv_node node;
|
|
|
|
makenode(tmp, &node, L, 2);
|
|
|
|
int res = mpv_set_property(ctx->client, p, MPV_FORMAT_NODE, &node);
|
|
|
|
return check_error(L, res);
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2020-03-22 20:52:53 +00:00
|
|
|
static int script_get_property_base(lua_State *L, void *tmp, int is_osd)
|
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);
|
2020-03-22 20:52:53 +00:00
|
|
|
int type = is_osd ? 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) {
|
2020-03-22 20:52:53 +00:00
|
|
|
add_af_mpv_alloc(tmp, result);
|
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);
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2020-03-22 20:52:53 +00:00
|
|
|
static int script_get_property(lua_State *L, void *tmp)
|
|
|
|
{
|
|
|
|
return script_get_property_base(L, tmp, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int script_get_property_osd(lua_State *L, void *tmp)
|
|
|
|
{
|
|
|
|
return script_get_property_base(L, tmp, 1);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2014-10-19 03:46:16 +00:00
|
|
|
static void pushnode(lua_State *L, mpv_node *node)
|
2014-02-24 19:47:20 +00:00
|
|
|
{
|
lua: makenode: prevent lua stack corruption
Normally there was no issue, but when the code converted a deeply
nested table into an mpv node - it didn't ensure the stack has room.
Lua doesn't check stack overflow when invoking lua_push* functions,
and leaves this responsibility to the (c) user via lua_checkstack.
Normally that's not an issue because when a lua (or autofree) function
is called, it's guaranteed at least LUA_MINSTACK (20) pushes.
However, pushnode and makenode are recursive, and each iteration can
add few values at the stack (which are popped when the recursion
unwinds), so checkstack must be used on (recursive) entry.
pushnode already checked the stack, makenode did not.
This commit checks the stack at makenode as well. The value of 6
(stack places to reserve) is with some room to spare, and in pratice
each iteration needs 2-3 at most (pushnode also leaves room).
Example which could previously corrupt the stack:
utils.format_json({d1={d2={<8 more times>}}}
This uses makenode to convert the lua table into an mpv node which
the json writer uses as input, and if the depth is 10 or more then
corruption could occur. mp.command_native is also affected, as well as
any other mp/utils command which takes a lua table as input.
While at it, fix the error string which pushnode used (luaL_checkstack
uses the provided string with "Stack overflow (%s)", so the user
message only needs to be additional info).
2021-10-20 08:26:13 +00:00
|
|
|
luaL_checkstack(L, 6, "pushnode");
|
2014-02-24 19:47:20 +00:00
|
|
|
|
|
|
|
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++) {
|
2014-10-19 03:46:16 +00:00
|
|
|
pushnode(L, &node->u.list->values[n]); // table value
|
2014-02-24 19:47:20 +00:00
|
|
|
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
|
2014-10-19 03:46:16 +00:00
|
|
|
pushnode(L, &node->u.list->values[n]); // table key value
|
2014-02-24 19:47:20 +00:00
|
|
|
lua_rawset(L, -3);
|
|
|
|
}
|
|
|
|
break;
|
2015-04-20 21:05:52 +00:00
|
|
|
case MPV_FORMAT_BYTE_ARRAY:
|
|
|
|
lua_pushlstring(L, node->u.ba->data, node->u.ba->size);
|
|
|
|
break;
|
2014-02-24 19:47:20 +00:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-03-22 20:07:26 +00:00
|
|
|
static int script_get_property_native(lua_State *L, void *tmp)
|
2014-02-24 19:47:20 +00:00
|
|
|
{
|
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
const char *name = luaL_checkstring(L, 1);
|
2014-10-21 23:10:15 +00:00
|
|
|
mp_lua_optarg(L, 2);
|
2014-02-24 19:47:20 +00:00
|
|
|
|
|
|
|
mpv_node node;
|
|
|
|
int err = mpv_get_property(ctx->client, name, MPV_FORMAT_NODE, &node);
|
|
|
|
if (err >= 0) {
|
2023-03-28 15:16:42 +00:00
|
|
|
steal_node_allocations(tmp, &node);
|
2014-10-19 03:46:16 +00:00
|
|
|
pushnode(L, &node);
|
|
|
|
return 1;
|
2014-02-24 19:47:20 +00:00
|
|
|
}
|
|
|
|
lua_pushvalue(L, 2);
|
2014-10-19 03:46:16 +00:00
|
|
|
lua_pushstring(L, mpv_error_string(err));
|
2014-02-24 19:47:20 +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-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;
|
|
|
|
}
|
|
|
|
|
2020-03-22 20:07:26 +00:00
|
|
|
static int script_command_native(lua_State *L, void *tmp)
|
2014-10-10 22:25:07 +00:00
|
|
|
{
|
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
2014-10-21 23:10:15 +00:00
|
|
|
mp_lua_optarg(L, 2);
|
2014-10-10 22:25:07 +00:00
|
|
|
struct mpv_node node;
|
|
|
|
struct mpv_node result;
|
|
|
|
makenode(tmp, &node, L, 1);
|
|
|
|
int err = mpv_command_node(ctx->client, &node, &result);
|
|
|
|
if (err >= 0) {
|
2023-03-28 15:16:42 +00:00
|
|
|
steal_node_allocations(tmp, &result);
|
2014-10-19 03:46:16 +00:00
|
|
|
pushnode(L, &result);
|
|
|
|
return 1;
|
2014-10-10 22:25:07 +00:00
|
|
|
}
|
|
|
|
lua_pushvalue(L, 2);
|
2014-10-19 03:46:16 +00:00
|
|
|
lua_pushstring(L, mpv_error_string(err));
|
2014-10-10 22:25:07 +00:00
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
|
2020-03-22 20:07:26 +00:00
|
|
|
static int script_raw_command_native_async(lua_State *L, void *tmp)
|
2018-05-10 13:26:27 +00:00
|
|
|
{
|
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
uint64_t id = luaL_checknumber(L, 1);
|
|
|
|
struct mpv_node node;
|
|
|
|
makenode(tmp, &node, L, 2);
|
|
|
|
int res = mpv_command_node_async(ctx->client, id, &node);
|
|
|
|
return check_error(L, res);
|
|
|
|
}
|
|
|
|
|
2018-05-12 16:48:35 +00:00
|
|
|
static int script_raw_abort_async_command(lua_State *L)
|
|
|
|
{
|
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
uint64_t id = luaL_checknumber(L, 1);
|
|
|
|
mpv_abort_async_command(ctx->client, id);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
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_set_section_mouse_area(lua_State *L)
|
|
|
|
{
|
|
|
|
struct MPContext *mpctx = get_mpctx(L);
|
|
|
|
|
|
|
|
char *section = (char *)luaL_checkstring(L, 1);
|
2016-03-07 21:20:51 +00:00
|
|
|
int x0 = luaL_checkinteger(L, 2);
|
|
|
|
int y0 = luaL_checkinteger(L, 3);
|
|
|
|
int x1 = luaL_checkinteger(L, 4);
|
|
|
|
int y1 = luaL_checkinteger(L, 5);
|
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_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;
|
|
|
|
}
|
|
|
|
|
2018-03-23 15:24:49 +00:00
|
|
|
static int script_raw_hook_add(lua_State *L)
|
|
|
|
{
|
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
uint64_t ud = luaL_checkinteger(L, 1);
|
|
|
|
const char *name = luaL_checkstring(L, 2);
|
|
|
|
int pri = luaL_checkinteger(L, 3);
|
|
|
|
return check_error(L, mpv_hook_add(ctx->client, ud, name, pri));
|
|
|
|
}
|
|
|
|
|
|
|
|
static int script_raw_hook_continue(lua_State *L)
|
|
|
|
{
|
|
|
|
struct script_ctx *ctx = get_ctx(L);
|
|
|
|
lua_Integer id = luaL_checkinteger(L, 1);
|
|
|
|
return check_error(L, mpv_hook_continue(ctx->client, id));
|
|
|
|
}
|
|
|
|
|
2020-03-22 20:52:53 +00:00
|
|
|
static int script_readdir(lua_State *L, void *tmp)
|
2014-05-25 17:51:11 +00:00
|
|
|
{
|
|
|
|
// 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;
|
|
|
|
}
|
2020-03-22 20:52:53 +00:00
|
|
|
add_af_dir(tmp, dir);
|
2014-05-25 17:51:11 +00:00
|
|
|
lua_newtable(L); // list
|
2020-03-22 21:45:06 +00:00
|
|
|
char *fullpath = talloc_strdup(tmp, "");
|
2014-05-25 17:51:11 +00:00
|
|
|
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;
|
2014-10-17 19:46:08 +00:00
|
|
|
if (stat(fullpath, &st))
|
2014-05-25 17:51:11 +00:00
|
|
|
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
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2017-12-11 21:04:51 +00:00
|
|
|
static int script_file_info(lua_State *L)
|
|
|
|
{
|
|
|
|
const char *path = luaL_checkstring(L, 1);
|
|
|
|
|
|
|
|
struct stat statbuf;
|
|
|
|
if (stat(path, &statbuf) != 0) {
|
|
|
|
lua_pushnil(L);
|
|
|
|
lua_pushstring(L, "error");
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
lua_newtable(L); // Result stat table
|
|
|
|
|
|
|
|
const char * stat_names[] = {
|
|
|
|
"mode", "size",
|
|
|
|
"atime", "mtime", "ctime", NULL
|
|
|
|
};
|
2019-12-25 18:01:43 +00:00
|
|
|
const lua_Number stat_values[] = {
|
2017-12-11 21:04:51 +00:00
|
|
|
statbuf.st_mode,
|
|
|
|
statbuf.st_size,
|
|
|
|
statbuf.st_atime,
|
|
|
|
statbuf.st_mtime,
|
|
|
|
statbuf.st_ctime
|
|
|
|
};
|
|
|
|
|
|
|
|
// Add all fields
|
|
|
|
for (int i = 0; stat_names[i]; i++) {
|
2019-12-25 18:01:43 +00:00
|
|
|
lua_pushnumber(L, stat_values[i]);
|
2017-12-11 21:04:51 +00:00
|
|
|
lua_setfield(L, -2, stat_names[i]);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Convenience booleans
|
|
|
|
lua_pushboolean(L, S_ISREG(statbuf.st_mode));
|
|
|
|
lua_setfield(L, -2, "is_file");
|
|
|
|
|
|
|
|
lua_pushboolean(L, S_ISDIR(statbuf.st_mode));
|
|
|
|
lua_setfield(L, -2, "is_dir");
|
|
|
|
|
|
|
|
// Return table
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2014-05-25 17:51:11 +00:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2022-05-12 14:12:57 +00:00
|
|
|
static int script_join_path(lua_State *L, void *tmp)
|
2014-05-25 17:51:11 +00:00
|
|
|
{
|
|
|
|
const char *p1 = luaL_checkstring(L, 1);
|
|
|
|
const char *p2 = luaL_checkstring(L, 2);
|
2022-05-12 14:12:57 +00:00
|
|
|
char *r = mp_path_join(tmp, p1, p2);
|
2014-05-25 17:51:11 +00:00
|
|
|
lua_pushstring(L, 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
|
|
|
|
2020-03-22 20:07:26 +00:00
|
|
|
static int script_parse_json(lua_State *L, void *tmp)
|
2014-10-19 03:27:35 +00:00
|
|
|
{
|
2014-10-21 23:10:15 +00:00
|
|
|
mp_lua_optarg(L, 2);
|
2014-10-19 03:27:35 +00:00
|
|
|
char *text = talloc_strdup(tmp, luaL_checkstring(L, 1));
|
|
|
|
bool trail = lua_toboolean(L, 2);
|
|
|
|
bool ok = false;
|
|
|
|
struct mpv_node node;
|
2023-07-07 23:51:21 +00:00
|
|
|
if (json_parse(tmp, &node, &text, MAX_JSON_DEPTH) >= 0) {
|
2014-10-19 03:27:35 +00:00
|
|
|
json_skip_whitespace(&text);
|
2014-10-25 23:00:34 +00:00
|
|
|
ok = !text[0] || trail;
|
2014-10-19 03:27:35 +00:00
|
|
|
}
|
|
|
|
if (ok) {
|
2014-10-19 03:46:16 +00:00
|
|
|
pushnode(L, &node);
|
2014-10-19 03:27:35 +00:00
|
|
|
lua_pushnil(L);
|
|
|
|
} else {
|
|
|
|
lua_pushnil(L);
|
|
|
|
lua_pushstring(L, "error");
|
|
|
|
}
|
|
|
|
lua_pushstring(L, text);
|
|
|
|
return 3;
|
|
|
|
}
|
|
|
|
|
2020-03-22 20:07:26 +00:00
|
|
|
static int script_format_json(lua_State *L, void *tmp)
|
2015-04-22 18:55:05 +00:00
|
|
|
{
|
|
|
|
struct mpv_node node;
|
|
|
|
makenode(tmp, &node, L, 1);
|
|
|
|
char *dst = talloc_strdup(tmp, "");
|
|
|
|
if (json_write(&dst, &node) >= 0) {
|
|
|
|
lua_pushstring(L, dst);
|
2023-12-16 19:10:58 +00:00
|
|
|
return 1;
|
2015-04-22 18:55:05 +00:00
|
|
|
}
|
2023-12-16 19:10:58 +00:00
|
|
|
|
|
|
|
lua_pushnil(L);
|
|
|
|
lua_pushstring(L, "error");
|
2015-04-22 18:55:05 +00:00
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
|
2020-07-16 23:36:33 +00:00
|
|
|
static int script_get_env_list(lua_State *L)
|
|
|
|
{
|
|
|
|
lua_newtable(L); // table
|
|
|
|
for (int n = 0; environ && environ[n]; n++) {
|
|
|
|
lua_pushstring(L, environ[n]); // table str
|
|
|
|
lua_rawseti(L, -2, n + 1); // table
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2020-03-22 17:53:19 +00:00
|
|
|
#define FN_ENTRY(name) {#name, script_ ## name, 0}
|
2020-03-22 20:07:26 +00:00
|
|
|
#define AF_ENTRY(name) {#name, 0, script_ ## name}
|
2014-05-26 19:46:01 +00:00
|
|
|
struct fn_entry {
|
|
|
|
const char *name;
|
2020-03-22 20:07:26 +00:00
|
|
|
int (*fn)(lua_State *L); // lua_CFunction
|
|
|
|
int (*af)(lua_State *L, void *); // af_CFunction
|
2014-05-26 19:46:01 +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
|
|
|
|
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),
|
2020-03-22 20:52:53 +00:00
|
|
|
AF_ENTRY(raw_wait_event),
|
2014-02-10 20:03:59 +00:00
|
|
|
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),
|
2020-02-04 19:40:16 +00:00
|
|
|
FN_ENTRY(get_script_directory),
|
2014-02-10 21:42:20 +00:00
|
|
|
FN_ENTRY(command),
|
|
|
|
FN_ENTRY(commandv),
|
2020-03-22 17:53:19 +00:00
|
|
|
AF_ENTRY(command_native),
|
|
|
|
AF_ENTRY(raw_command_native_async),
|
2018-05-12 16:48:35 +00:00
|
|
|
FN_ENTRY(raw_abort_async_command),
|
2020-03-22 23:19:29 +00:00
|
|
|
AF_ENTRY(get_property),
|
|
|
|
AF_ENTRY(get_property_osd),
|
2014-02-24 19:47:20 +00:00
|
|
|
FN_ENTRY(get_property_bool),
|
|
|
|
FN_ENTRY(get_property_number),
|
2020-03-22 17:53:19 +00:00
|
|
|
AF_ENTRY(get_property_native),
|
2022-12-16 21:22:33 +00:00
|
|
|
FN_ENTRY(del_property),
|
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),
|
2020-03-22 17:53:19 +00:00
|
|
|
AF_ENTRY(set_property_native),
|
2014-04-08 19:10:00 +00:00
|
|
|
FN_ENTRY(raw_observe_property),
|
|
|
|
FN_ENTRY(raw_unobserve_property),
|
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_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),
|
2018-03-23 15:24:49 +00:00
|
|
|
FN_ENTRY(raw_hook_add),
|
|
|
|
FN_ENTRY(raw_hook_continue),
|
2014-05-25 17:51:11 +00:00
|
|
|
{0}
|
|
|
|
};
|
|
|
|
|
2014-06-10 21:56:05 +00:00
|
|
|
static const struct fn_entry utils_fns[] = {
|
2020-03-22 20:52:53 +00:00
|
|
|
AF_ENTRY(readdir),
|
2017-12-11 21:04:51 +00:00
|
|
|
FN_ENTRY(file_info),
|
2014-05-25 17:51:11 +00:00
|
|
|
FN_ENTRY(split_path),
|
2022-05-12 14:12:57 +00:00
|
|
|
AF_ENTRY(join_path),
|
2020-03-22 17:53:19 +00:00
|
|
|
AF_ENTRY(parse_json),
|
|
|
|
AF_ENTRY(format_json),
|
2020-07-25 22:10:52 +00:00
|
|
|
FN_ENTRY(get_env_list),
|
2014-05-25 17:51:11 +00:00
|
|
|
{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
|
|
|
};
|
|
|
|
|
2020-03-22 20:07:26 +00:00
|
|
|
typedef struct autofree_data {
|
|
|
|
af_CFunction target;
|
|
|
|
void *ctx;
|
|
|
|
} autofree_data;
|
|
|
|
|
|
|
|
/* runs the target autofree script_* function with the ctx argument */
|
|
|
|
static int script_autofree_call(lua_State *L)
|
2020-03-22 17:53:19 +00:00
|
|
|
{
|
lua: autofree infrastructure: x2 faster
The speedup is due to moving big part of the autofree runtime overhead
(new lua c closure) to happen once on init at af_pushcclosure, instead
of on every call. This also allows supporting upvalues trivially, even
if mpv doesn't use it currently, and is more consistent with lua APIs.
While x2 infrastructure speedup is meaningful - and similar between
lua 5.1/5.2/jit, in practice it's a much smaller improvement because
the autofree overhead is typically small compared to the "real" work
(the actual functionality, and talloc+free which is needed anyway).
So with this commit, fast functions improve more in percentage.
E.g. utils.parse_json("0") is relatively fast and is now about 25%
faster, while a slower call like mp.command_native("ignore") is now
about 10% faster than before. If we had mp.noop() which does nothing
(but still "needs" alloc/free) - it would now be about 50% faster.
Overall, it's a mild performance improvements, the API is now more
consistent with lua, and without increasing code size or complexity.
2020-03-23 08:48:13 +00:00
|
|
|
// n*args &data
|
|
|
|
autofree_data *data = lua_touserdata(L, -1);
|
|
|
|
lua_pop(L, 1); // n*args
|
2020-03-22 20:07:26 +00:00
|
|
|
assert(data && data->target && data->ctx);
|
|
|
|
return data->target(L, data->ctx);
|
2020-03-22 17:53:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int script_autofree_trampoline(lua_State *L)
|
|
|
|
{
|
lua: autofree infrastructure: x2 faster
The speedup is due to moving big part of the autofree runtime overhead
(new lua c closure) to happen once on init at af_pushcclosure, instead
of on every call. This also allows supporting upvalues trivially, even
if mpv doesn't use it currently, and is more consistent with lua APIs.
While x2 infrastructure speedup is meaningful - and similar between
lua 5.1/5.2/jit, in practice it's a much smaller improvement because
the autofree overhead is typically small compared to the "real" work
(the actual functionality, and talloc+free which is needed anyway).
So with this commit, fast functions improve more in percentage.
E.g. utils.parse_json("0") is relatively fast and is now about 25%
faster, while a slower call like mp.command_native("ignore") is now
about 10% faster than before. If we had mp.noop() which does nothing
(but still "needs" alloc/free) - it would now be about 50% faster.
Overall, it's a mild performance improvements, the API is now more
consistent with lua, and without increasing code size or complexity.
2020-03-23 08:48:13 +00:00
|
|
|
// n*args
|
2020-03-22 20:07:26 +00:00
|
|
|
autofree_data data = {
|
lua: autofree infrastructure: x2 faster
The speedup is due to moving big part of the autofree runtime overhead
(new lua c closure) to happen once on init at af_pushcclosure, instead
of on every call. This also allows supporting upvalues trivially, even
if mpv doesn't use it currently, and is more consistent with lua APIs.
While x2 infrastructure speedup is meaningful - and similar between
lua 5.1/5.2/jit, in practice it's a much smaller improvement because
the autofree overhead is typically small compared to the "real" work
(the actual functionality, and talloc+free which is needed anyway).
So with this commit, fast functions improve more in percentage.
E.g. utils.parse_json("0") is relatively fast and is now about 25%
faster, while a slower call like mp.command_native("ignore") is now
about 10% faster than before. If we had mp.noop() which does nothing
(but still "needs" alloc/free) - it would now be about 50% faster.
Overall, it's a mild performance improvements, the API is now more
consistent with lua, and without increasing code size or complexity.
2020-03-23 08:48:13 +00:00
|
|
|
.target = lua_touserdata(L, lua_upvalueindex(2)), // fn
|
2020-03-22 20:07:26 +00:00
|
|
|
.ctx = NULL,
|
|
|
|
};
|
|
|
|
assert(data.target);
|
2020-03-22 17:53:19 +00:00
|
|
|
|
lua: autofree infrastructure: x2 faster
The speedup is due to moving big part of the autofree runtime overhead
(new lua c closure) to happen once on init at af_pushcclosure, instead
of on every call. This also allows supporting upvalues trivially, even
if mpv doesn't use it currently, and is more consistent with lua APIs.
While x2 infrastructure speedup is meaningful - and similar between
lua 5.1/5.2/jit, in practice it's a much smaller improvement because
the autofree overhead is typically small compared to the "real" work
(the actual functionality, and talloc+free which is needed anyway).
So with this commit, fast functions improve more in percentage.
E.g. utils.parse_json("0") is relatively fast and is now about 25%
faster, while a slower call like mp.command_native("ignore") is now
about 10% faster than before. If we had mp.noop() which does nothing
(but still "needs" alloc/free) - it would now be about 50% faster.
Overall, it's a mild performance improvements, the API is now more
consistent with lua, and without increasing code size or complexity.
2020-03-23 08:48:13 +00:00
|
|
|
lua_pushvalue(L, lua_upvalueindex(1)); // n*args autofree_call (closure)
|
|
|
|
lua_insert(L, 1); // autofree_call n*args
|
|
|
|
lua_pushlightuserdata(L, &data); // autofree_call n*args &data
|
2020-03-22 17:53:19 +00:00
|
|
|
|
2020-03-22 20:07:26 +00:00
|
|
|
data.ctx = talloc_new(NULL);
|
lua: autofree infrastructure: x2 faster
The speedup is due to moving big part of the autofree runtime overhead
(new lua c closure) to happen once on init at af_pushcclosure, instead
of on every call. This also allows supporting upvalues trivially, even
if mpv doesn't use it currently, and is more consistent with lua APIs.
While x2 infrastructure speedup is meaningful - and similar between
lua 5.1/5.2/jit, in practice it's a much smaller improvement because
the autofree overhead is typically small compared to the "real" work
(the actual functionality, and talloc+free which is needed anyway).
So with this commit, fast functions improve more in percentage.
E.g. utils.parse_json("0") is relatively fast and is now about 25%
faster, while a slower call like mp.command_native("ignore") is now
about 10% faster than before. If we had mp.noop() which does nothing
(but still "needs" alloc/free) - it would now be about 50% faster.
Overall, it's a mild performance improvements, the API is now more
consistent with lua, and without increasing code size or complexity.
2020-03-23 08:48:13 +00:00
|
|
|
int r = lua_pcall(L, lua_gettop(L) - 1, LUA_MULTRET, 0); // m*retvals
|
2020-03-22 20:07:26 +00:00
|
|
|
talloc_free(data.ctx);
|
2020-03-22 17:53:19 +00:00
|
|
|
|
|
|
|
if (r)
|
|
|
|
lua_error(L);
|
|
|
|
|
lua: autofree infrastructure: x2 faster
The speedup is due to moving big part of the autofree runtime overhead
(new lua c closure) to happen once on init at af_pushcclosure, instead
of on every call. This also allows supporting upvalues trivially, even
if mpv doesn't use it currently, and is more consistent with lua APIs.
While x2 infrastructure speedup is meaningful - and similar between
lua 5.1/5.2/jit, in practice it's a much smaller improvement because
the autofree overhead is typically small compared to the "real" work
(the actual functionality, and talloc+free which is needed anyway).
So with this commit, fast functions improve more in percentage.
E.g. utils.parse_json("0") is relatively fast and is now about 25%
faster, while a slower call like mp.command_native("ignore") is now
about 10% faster than before. If we had mp.noop() which does nothing
(but still "needs" alloc/free) - it would now be about 50% faster.
Overall, it's a mild performance improvements, the API is now more
consistent with lua, and without increasing code size or complexity.
2020-03-23 08:48:13 +00:00
|
|
|
return lua_gettop(L); // m (retvals)
|
2020-03-22 17:53:19 +00:00
|
|
|
}
|
|
|
|
|
lua: autofree infrastructure: x2 faster
The speedup is due to moving big part of the autofree runtime overhead
(new lua c closure) to happen once on init at af_pushcclosure, instead
of on every call. This also allows supporting upvalues trivially, even
if mpv doesn't use it currently, and is more consistent with lua APIs.
While x2 infrastructure speedup is meaningful - and similar between
lua 5.1/5.2/jit, in practice it's a much smaller improvement because
the autofree overhead is typically small compared to the "real" work
(the actual functionality, and talloc+free which is needed anyway).
So with this commit, fast functions improve more in percentage.
E.g. utils.parse_json("0") is relatively fast and is now about 25%
faster, while a slower call like mp.command_native("ignore") is now
about 10% faster than before. If we had mp.noop() which does nothing
(but still "needs" alloc/free) - it would now be about 50% faster.
Overall, it's a mild performance improvements, the API is now more
consistent with lua, and without increasing code size or complexity.
2020-03-23 08:48:13 +00:00
|
|
|
static void af_pushcclosure(lua_State *L, af_CFunction fn, int n)
|
2020-03-22 17:53:19 +00:00
|
|
|
{
|
lua: autofree infrastructure: x2 faster
The speedup is due to moving big part of the autofree runtime overhead
(new lua c closure) to happen once on init at af_pushcclosure, instead
of on every call. This also allows supporting upvalues trivially, even
if mpv doesn't use it currently, and is more consistent with lua APIs.
While x2 infrastructure speedup is meaningful - and similar between
lua 5.1/5.2/jit, in practice it's a much smaller improvement because
the autofree overhead is typically small compared to the "real" work
(the actual functionality, and talloc+free which is needed anyway).
So with this commit, fast functions improve more in percentage.
E.g. utils.parse_json("0") is relatively fast and is now about 25%
faster, while a slower call like mp.command_native("ignore") is now
about 10% faster than before. If we had mp.noop() which does nothing
(but still "needs" alloc/free) - it would now be about 50% faster.
Overall, it's a mild performance improvements, the API is now more
consistent with lua, and without increasing code size or complexity.
2020-03-23 08:48:13 +00:00
|
|
|
// Instead of pushing a direct closure of fn with n upvalues, we push an
|
|
|
|
// autofree_trampoline closure with two upvalues:
|
|
|
|
// 1: autofree_call closure with the n upvalues given here.
|
|
|
|
// 2: fn
|
|
|
|
//
|
|
|
|
// when called the autofree_trampoline closure will pcall the autofree_call
|
|
|
|
// closure with the current lua call arguments and an additional argument
|
|
|
|
// which holds ctx and fn. the autofree_call closure (with the n upvalues
|
|
|
|
// given here) calls fn directly and provides it with the ctx C argument,
|
|
|
|
// so that fn sees the exact n upvalues and lua call arguments as intended,
|
|
|
|
// wrapped with ctx init/cleanup.
|
|
|
|
|
|
|
|
lua_pushcclosure(L, script_autofree_call, n);
|
2020-03-22 17:53:19 +00:00
|
|
|
lua_pushlightuserdata(L, fn);
|
lua: autofree infrastructure: x2 faster
The speedup is due to moving big part of the autofree runtime overhead
(new lua c closure) to happen once on init at af_pushcclosure, instead
of on every call. This also allows supporting upvalues trivially, even
if mpv doesn't use it currently, and is more consistent with lua APIs.
While x2 infrastructure speedup is meaningful - and similar between
lua 5.1/5.2/jit, in practice it's a much smaller improvement because
the autofree overhead is typically small compared to the "real" work
(the actual functionality, and talloc+free which is needed anyway).
So with this commit, fast functions improve more in percentage.
E.g. utils.parse_json("0") is relatively fast and is now about 25%
faster, while a slower call like mp.command_native("ignore") is now
about 10% faster than before. If we had mp.noop() which does nothing
(but still "needs" alloc/free) - it would now be about 50% faster.
Overall, it's a mild performance improvements, the API is now more
consistent with lua, and without increasing code size or complexity.
2020-03-23 08:48:13 +00:00
|
|
|
lua_pushcclosure(L, script_autofree_trampoline, 2);
|
2020-03-22 17:53:19 +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++) {
|
2020-03-22 20:07:26 +00:00
|
|
|
if (e[n].af) {
|
lua: autofree infrastructure: x2 faster
The speedup is due to moving big part of the autofree runtime overhead
(new lua c closure) to happen once on init at af_pushcclosure, instead
of on every call. This also allows supporting upvalues trivially, even
if mpv doesn't use it currently, and is more consistent with lua APIs.
While x2 infrastructure speedup is meaningful - and similar between
lua 5.1/5.2/jit, in practice it's a much smaller improvement because
the autofree overhead is typically small compared to the "real" work
(the actual functionality, and talloc+free which is needed anyway).
So with this commit, fast functions improve more in percentage.
E.g. utils.parse_json("0") is relatively fast and is now about 25%
faster, while a slower call like mp.command_native("ignore") is now
about 10% faster than before. If we had mp.noop() which does nothing
(but still "needs" alloc/free) - it would now be about 50% faster.
Overall, it's a mild performance improvements, the API is now more
consistent with lua, and without increasing code size or complexity.
2020-03-23 08:48:13 +00:00
|
|
|
af_pushcclosure(L, e[n].af, 0); // modtable fn
|
2020-03-22 17:53:19 +00:00
|
|
|
} else {
|
|
|
|
lua_pushcclosure(L, e[n].fn, 0); // modtable fn
|
|
|
|
}
|
2014-05-26 19:46:01 +00:00
|
|
|
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);
|
|
|
|
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 = {
|
2023-10-22 19:00:13 +00:00
|
|
|
.name = "lua",
|
2014-05-12 23:14:07 +00:00
|
|
|
.file_ext = "lua",
|
|
|
|
.load = load_lua,
|
|
|
|
};
|