wasmoon 2.0

[ceifa]

Fixes #21 #83 #127 #149 #148 #143 #134
Tried to fix #61, but emscripten have a very limited support for deno

[yuri-kiss]

is there any reason this hasn't recieved any attention

[Drago-Cuven]

should def be merged.

[neico]

How it would improve the consumers to adapt? I never do lua version changes on patch versions, so all the consumers have to upgrade it manually.

this version is non-trivial to move to, take this abstraction as an example:

/** @type {?WASMoon.LuaEngine|WASMoon_5_1.Lua} */
let Lua = null;

// Note: WASMoon 1.x
if( "LuaFactory" in Instance.Backend )
{
	const Factory = new Instance.Backend.LuaFactory( ModuleURL, Env );

	/**
	* @param {string} File
	* @param {string | ArrayBufferView} Contents
	*/
	Instance.MountFile = ( File, Contents ) =>
	{
		Factory.mountFileSync( /** @type {WASMoon.LuaWasm} */( Instance.WASM ), File, Contents );
	}

	Lua = await Factory.createEngine( { openStandardLibs: false, traceAllocations: true } );
}
else if( "Lua" in Instance.Backend )
{
	// Note: WASMoon 2.x
	if( "load" in Instance.Backend.Lua )
	{
		console.error( "WASMoon v2 isn't released yet!" );

		/*
			const Factory = await Instance.Backend.Lua.load(
			{
				wasmFile: ModuleURL,
				env: Env
			} );

			/**
			* @param {string} File
			* @param {string | ArrayBufferView} Contents
			*\/
			Instance.MountFile = ( File, Contents ) =>
			{
				Factory.mountFileSync( /** @type {WASMoon.LuaWasm} *\/( Instance.WASM ), File, Contents );
			}

			Lua = Factory.createState( { openStandardLibs: false, traceAllocations: true } );
		*/
	}
	// Note: WASMoon Lua 5.1 fork
	else if( "create" in Instance.Backend.Lua )
	{
		/**
		* @param {string} File
		* @param {string | ArrayBufferView} Contents
		*/
		Instance.MountFile = function( File, Contents )
		{
			/** @type {WASMoon_5_1.Lua} */( this.Lua ).mountFile( File, Contents );
		}

		Lua = await Instance.Backend.Lua.create(
		{
			customWasmUri: ModuleURL,
			environmentVariables: Env,
			openStandardLibs: false,
			traceAllocations: true
		} );
	}
}

Having a simple version check would highly simplify the above.

That is a good idea! Will try to release it on v2.

EDIT: we already expose the lua_version method

While that is true, said function depends on lua already being created so it might be a bit late depending on the situation (ex. for deciding which wasm file to fetch)

But I was also talking about things that the following (5.1 compatible) code showcases:

// Note: wasmoon currently doesn't expose lua_pushglobaltable(), or LUA_RIDX_GLOBALS, so we use the raw value, which is 2
if( "lua_geti" in this.WASM ) this.WASM.lua_geti( L, this.Backend.LUA_REGISTRYINDEX, 2n );
else if( "LUA_GLOBALSINDEX" in this.Backend ) this.WASM.lua_pushvalue( L, this.Backend.LUA_GLOBALSINDEX );

Side-Note: integer based functions like lua_geti supporting number|BigInt would be a nice QoL since there's no implicit conversion between the two available

I’m open to ideas on how to structure the architecture so we can ship Wasmoon with support for multiple Lua versions without introducing excessive complexity or significantly increasing the package size.

A lot of the newer functions and features can theoretically be aliased, polyfilled to a degree, or outright ignored.
So if you know which lua version the wasm file exposes, then this can be handled transparently in module.ts for example.
UTF-8 (strings) would be a slight issue for previous versions not having a utf8 lib though.
The internals should be aware of the functions that might not be there at the very least to avoid calling into the void.
example:

const Value = BigInt( "luaL_len" in this.WASM ? this.WASM.luaL_len( L, -1 ) : "lua_objlen" in this.WASM ? this.WASM.lua_objlen( L, -1 ) : -1 );

As an side note:
While I'm not happy with all the changes done in this fork a few things like the initial creation of the lua state is a lot more condensed than what it currently is, even with the LuaFactory to Lua change, see here
it also makes calling things such as mountFile easier without having to keep 2 references around (one for Lua and one for LuaEngine), see code example above

[RodrigoDornelles]

How it would improve the consumers to adapt? I never do lua version changes on patch versions, so all the consumers have to upgrade it manually.

I don't think it's the best solution, although I adopted it and it worked well; Lua's ABI has few and at the same time fragile changes.

---

@ceifa What if we could perhaps resolve dynamic symbols? Something like checking if there's a lua_version() function, and if there isn't, it would probably be Lua 5.1, and then basing that on querying a dynamic ABI from the JavaScript side, I don't know how much work that would be and how prohibitive wasmoon would be.