liblua: Implement try_include and use it for inclusion of the local module

[kevans]

Summary

This provides a way to optionally include a module without having to wrap it in filesystem checks. try_include is a little more robust, using the lua search path instead of forcing us to explicitly consider all of the places we could want to include a module.

This will also be used to split out logo/brand graphics into their own files so that we can safely scale up the number of graphics included without worrying a bout the extra memory consumption- opting to lazily load graphics instead.

[cem]

stand/liblua/lutils.c

365 ↗

(On Diff #40175)

This will silently ignore errors other than ENOENT too, right? That seems like something we don't want, maybe.

410 ↗

(On Diff #40175)

Does this need to be a global instead of living in the "loader." namespace? I guess it matches require().

[kevans]

stand/liblua/lutils.c

365 ↗

(On Diff #40175)

Right- maybe that requires some extra consideration. I don't think there's a standard for any kind of try_include, so we have some wiggle room here. Basically, for most of the applications, we don't want a syntax error or something else that might be encountered in the to-be-loaded module to screw up our execution- if the module offers something that we need to use, we need to account for the possibility that it may have such errors and we need to handle it gracefully rather than die.

I guess there might be some circumstances where we'd want to halt on everything but ENOENT, but I'd prefer to handle that with an extra parameter to try_require, perhaps, to indicate that. We'd have to basically copy lua's findloader in loadlib.c to remove the luaL_error invocations along with ll_require.

410 ↗

(On Diff #40175)

Yeah, I'd like to match the namespace availability of related functionality if we can- to the extent that we have global printc to match global print and global try_include to match global try_require, but if it's a functionality normally offered in a namespace we'd offer it in a namespace- preferably loader namespace if it's a special version that's not necessarily compatible with the standard available version.

[cem]

stand/liblua/lutils.c

365 ↗

(On Diff #40175)

Basically, for most of the applications, we don't want a syntax error or something else that might be encountered in the to-be-loaded module to screw up our execution

Yeah, that makes sense. Can we log an error of some kind?

We'd have to basically copy lua's findloader in loadlib.c to remove the luaL_error invocations along with ll_require.

Are the error(s) that come out of require() machine distinguishable?

[kevans]

stand/liblua/lutils.c

365 ↗

(On Diff #40175)

We could return nil and an error message of sorts, but...

I'd have to do some further checking, but at a glance there is no distinguishable difference here between ENOENT and a parse error. They'll both return the same value from the pcall at the very least, and I suspect the only difference is in the resulting error message.

[cem]

stand/liblua/lutils.c

365 ↗

(On Diff #40175)

Like, log somewhere the user is actually likely to see it. I'm thinking the common failure mode here will be: admin writes local.lua with a minor syntax error; effects that local.lua was supposed to provide are silently dropped; admin tears out hair in frustration at impossible to debug system.

They'll both return the same value from the pcall at the very least, and I suspect the only difference is in the resulting error message.

We can strstr() around in the error message if we have to. :-)

[kevans]

stand/liblua/lutils.c

365 ↗

(On Diff #40175)

Right, I need to implement verbose_loader so we can hide messages like that for normal people that don't care. We have a couple others, too, that need to go away for non-verbose setups.

[imp]

stand/liblua/lutils.c

365 ↗

(On Diff #40175)

try_include means "include this file, if it exists, but otherwise act just like include". This means that we need to signal all errors except 'file not found' like we would for a normal include. We need to make the underlying code understand this better and/or signal it separately. I don't think a simple construction of 'require' is going to do it.

I think the 'file not found' should be boot verbose, all other errors should be at all levels.

[kevans]

stand/liblua/lutils.c

365 ↗

(On Diff #40175)

Ok, I'll deal with this next week, maybe.

[kevans]

Did a complete 180 and implemented this in Lua instead. Lua exposes pcall in an actually sane way, so we might as well take advantage of it and use :match to determine if we want to display the error or not.

[kevans]

Correct a typo and drop a comment in describing what try_include should be expected to do.

[cem]

I like it