Lua is designed for embedding into larger host programs. Last time I talked about how to make C functions available to Lua, now I want to talk about how to bundle Lua libraries in with your host program.<\/p>\n
First, we have to understand what it means to load a library. Most Lua libraries are packaged into modules (which I’ll get into later), one module per file. You call Notably, you’re not passing a file name to A function that evaluates to a module is called a loader<\/em>. Searchers<\/em> try to find loaders, so there’s a searcher that looks in files and returns functions that call But, even before it starts calling searchers, it checks if you’ve provided a loader for that module by hand. You can do that by putting it in a table, Let’s say you have a module, Penlight, in pl.lua. You want to embed this in your app. So, you store it in your binary as a string, and provide a C function that returns the string (actually you’d use some kind of data file, but I’m keeping this simple). The first place it’ll look for the loader is Now, when you call It’s easy to see how you could build a whole package system with this: byte-compile the files first and run them through zlib, put them all in a data file, since Lua is designed for embedding into larger host programs. Last time I talked about how to make C functions available to Lua, now I want to talk about how to bundle Lua libraries in with your host program. First, we have to understand what it means to load a library. Most Lua libraries are packaged […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"http:\/\/www.playwithlua.com\/index.php?rest_route=\/wp\/v2\/posts\/11"}],"collection":[{"href":"http:\/\/www.playwithlua.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.playwithlua.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.playwithlua.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.playwithlua.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=11"}],"version-history":[{"count":0,"href":"http:\/\/www.playwithlua.com\/index.php?rest_route=\/wp\/v2\/posts\/11\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.playwithlua.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=11"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.playwithlua.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=11"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.playwithlua.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=11"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}require<\/code> and pass it a module name, and it returns the module (usually as a table containing some functions).<\/p>\nrequire<\/code>, you’re passing a module name. The fact that these modules map to files is just sort of coincidence. In actuality, require<\/code> looks in several different places (locations on package.path<\/code>, C libraries on package.cpath<\/code>, and so on) for a function that will evaluate to the module.<\/p>\ndofile<\/code> on them, for example. Each searcher that Lua uses is stored in the confusingly-named package.loaders<\/code>, so one way to find this would be to add a searcher that will look for a particularly-named function (exposed from C) and call it, like if I try to load “foo” that means try to call “load_foo_from_c()<\/code>“.<\/p>\npackage.preload<\/code>. If you only want one module this is much easier to do.<\/p>\npackage.preload['pl']<\/code>, so put this there:<\/p>\n\npackage.<\/span>preload[<\/span>'pl'<\/span>]<\/span> =<\/span> function<\/span>(<\/span>)<\/span>\n local<\/span> str =<\/span> load_pl_from_c(<\/span>)<\/span>\n local<\/span> fn =<\/span> loadstring<\/span>(<\/span>str)<\/span>\n return<\/span> fn(<\/span>)<\/span>\nend<\/span><\/pre><\/div><\/div><\/div>\n\nrequire 'pl'<\/code> it will execute this function, read the text of the pl library from wherever the host stored it, and run it. And, if you’re testing your script outside the host program, it will still work; just don’t add anything to preload and it will just read the file from the path.<\/p>\npackage.preload<\/code> is a table that means you can put a metatable on it, etc. One idea I had was to tie this to curl and have it load packages from a repository over http.<\/p>\n","protected":false},"excerpt":{"rendered":"