I am new to lua and I am trying to create a configuration DSL which allows to have sections that already have defaults.
So, the java table is predefined with lot of values
java = {
source = 1.6,
target = 1.6,
directories = {
sources = "src/main/java",
output = "build/clases",
},
}
I have a Config prototype that implements __call so that when called as a function with a table constructor, it only overwrites the defaults. Something (like) this:
Config.__call = function(t, props)
for k,v in pairs(props) do
t[k] = v
end
end
The idea is that you can call the dsl only to specify what you want to override:
java {
source = 1.5,
directories {
sources = "customsrcdir",
}
}
There is a Config.new method that allows to apply the prototype recursively to the tables so that all have a metatable with the __call method set.
My problem is with the "directories" subsection. It is evaluated in the global context, so the only way this works is:
java {
source = 1.5,
java.directories {
sources = "customsrcdir",
}
}
Which is pointless, as this is the same as doing:
java {
source = 1.5
}
java.directories {
sources = "customsrcdir",
}
I tried different approaches to have the desired DSL to work. One was setting a custom global environment with _ENV, but then I realized the table is evaluated before __call.
I wonder if someone with more lua experience has implemented a DSL like this using more advanced table/metatable/_ENV magic.
It's possible to do it your way with calls, but the solution's so convoluted that it's not worth the omission of the =. If you still want the table merge/replacement functionality, then that's not too difficult.
local function merge(t1, t2)
for k, v in pairs(t2) do
-- Merge tables with tables, unless the replacing table is an array,
-- in which case, the array table overwrites the destination.
if type(t1[k]) == 'table' and type(v) == 'table' and #v == 0 then
merge(t1[k], v)
else
t1[k] = v
end
end
end
local data = {
java = {
source = 1.6,
target = 1.6,
directories = {
sources = "src/main/java",
output = "build/classes",
},
}
}
local dsl = {}
load( [[
java = {
source = 1.5,
directories = {
sources = "customsrcdir",
},
}
]], 'dsl-config', 't', dsl)()
merge(data, dsl)
Dumping data will result in:
java = {
directories = {
output = "build/classes",
sources = "customsrcdir"
}
source = 1.5,
target = 1.6
}
Check out how premake does it... Might be a more elegant solution than what you have going right now. http://en.wikipedia.org/wiki/Premake#Sample_Script
Related
I'm trying to override the package.loaded table in the scope of a function using setfenv, but it's not quite working.
local env = {
require = require,
print = print,
package = {
cpath = package.cpath,
loadlib = package.loadlib,
path = package.path,
preload = package.preload,
seeall = package.seeall,
loaded = {
foobar = {
fn = function() print("hello world") end,
},
},
},
}
setfenv(assert(loadstring("require('foobar')")), env)()
Executing the above code, will result in a error because the module foobar isn't found.
It seems that it's for some reason not picking up the package table override that I've specified in the environment.
How do I make this work?
I'm trying to write my own NeoVim Lua based config, stripped down to the minimum I need and with the goal to understand at least most of the config. LSP setup is working fine and is the only source I configured for nvim-cmp:
local cmp = require("cmp")
cmp.setup {
sources = {
{ name = 'nvim_lsp' }
}
}
local capabilities = vim.lsp.protocol.make_client_capabilities()
capabilities = require('cmp_nvim_lsp').update_capabilities(capabilities)
After some startup delay the completion is working in the sense that I see popups with proposed completions, based on information from LSP.
But I cannot select any of the proposed completions. I can just continue to type which reduces the proposed completions, but I cannot use tab, arrow keys, ... to select an entry from the popup. I saw in the docs that one can define keyboard mappings but cannot make sense out of them. They are all rather sophisticated, require a snippet package to be installed, ...
I would prefer to select the next completion via tab and to navigate them via arrow key. "Enter" should select the current one.
Could somebody show me a minimal configuration for this setup or point me to more "basic" docs?
Nvim-cmp requires you to set the mapping for tab and other keys explicitly, here is my working example:
local cmp = require'cmp'
local lspkind = require'lspkind'
cmp.setup({
snippet = {
expand = function(args)
-- For `ultisnips` user.
vim.fn["UltiSnips#Anon"](args.body)
end,
},
mapping = cmp.mapping.preset.insert({
['<Tab>'] = function(fallback)
if cmp.visible() then
cmp.select_next_item()
else
fallback()
end
end,
['<S-Tab>'] = function(fallback)
if cmp.visible() then
cmp.select_prev_item()
else
fallback()
end
end,
['<CR>'] = cmp.mapping.confirm({ select = true }),
['<C-e>'] = cmp.mapping.abort(),
['<Esc>'] = cmp.mapping.close(),
['<C-d>'] = cmp.mapping.scroll_docs(-4),
['<C-f>'] = cmp.mapping.scroll_docs(4),
}),
sources = {
{ name = 'nvim_lsp' }, -- For nvim-lsp
{ name = 'ultisnips' }, -- For ultisnips user.
{ name = 'nvim_lua' }, -- for nvim lua function
{ name = 'path' }, -- for path completion
{ name = 'buffer', keyword_length = 4 }, -- for buffer word completion
{ name = 'omni' },
{ name = 'emoji', insert = true, } -- emoji completion
},
completion = {
keyword_length = 1,
completeopt = "menu,noselect"
},
view = {
entries = 'custom',
},
formatting = {
format = lspkind.cmp_format({
mode = "symbol_text",
menu = ({
nvim_lsp = "[LSP]",
ultisnips = "[US]",
nvim_lua = "[Lua]",
path = "[Path]",
buffer = "[Buffer]",
emoji = "[Emoji]",
omni = "[Omni]",
}),
}),
},
})
This is working great for me. The mapping part corresponds to the config for key mapping in the table. You can tweak your conf based on my config to make it work for you.
I'm working on a game where a bunch of characters will be generated on the fly, based on some constraints defined either in the project or externally via mod files. I am using MoonSharp Lua (5.2) interpreter for interfacing with my C# code, and Lua tables to store the constraint presets. As an example:
require "Defaults"
AgePresets = {}
-- Single value
AgePresets.Newborn = 0
-- Simple ranges
AgePresets.Default = defaultAgeRange --referring to the Defaults require
AgePresets.Child = {1, 12}
AgePresets.Teenager = {13, 19}
AgePresets.YoungAdult = {20, 29}
AgePresets.Adult = {30, 40}
AgePresets.MiddleAge = {40, 60}
AgePresets.Senior = {61, 80}
AgePresets.Elder = {81, 99}
AgePresets.Methuselah = {100, 150}
AgePresets.Methuselah2 = {150, 200}
-- Weighted ranges // again referring to previously defined elements to keep things concise
AgePresets.Tween = {
{weight = 1, minmax = AgePresets.Teenager },
{weight = 1, minmax = AgePresets.YoungAdult }
}
This works fine, but from an end-user point of view, there's a lot of unnecessary typing involved. We are clearly working on AgePresets here but it is still mentioned as a prefix before every member name.
I could of course define AgePresets as an array, like AgePresets = { Child = {}, Teenager = {} } but the problem with that is then I cannot refer to previously defined elements in the array.
This doesn't work:
AgePresets = {
Child = {1,12},
RefToChild = Child, //attempt to index a nil value exception
Teen = {13,19}
}
What I ideally want to achieve is a clean, concise way for users to enter this data in, like in the first example but without having to put AgePresets. prefix before everything. How do I go about declaring a scope in a file such that all succeeding members defined in the file will be within that scope, while maintaining the ability to refer to other members defined previously in the scope?
AgePresets = setmetatable({}, {__index = _G})
do
local _ENV = AgePresets
Newborn = 0
Child = {1,12}
RefToChild = Child -- this ref is Ok
Teen = {13,19}
YoungAdult = {20,29}
Tween = {
{weight = 1, minmax = Teen },
{weight = 1, minmax = YoungAdult }
}
rnd = math.random(10) -- global functions are available here
end
setmetatable(AgePresets, nil)
You can mix the two styles: table constructor for fields that don't need to reference variables that aren't in scope yet, followed by assignment statements for the rest.
I would do that unless the order of the fields in the code significantly enhanced comprehension.
I have an enormous table of functions named engine_api with inline documentation. Because it's becoming so large I'd like to make it more modular.
The api is set up like this:
-- Engine API module
local engine_api = {
engine = {
-- engine functions...
version = ...
},
image = {
-- image functions...
jpeg = {
-- jpeg specific bits
},
},
project = {
-- project functions
}
}
return engine_api
As you can see, it's more than 2 levels deep.
The whole thing is returned as a single table so other parts of the system can call into this api like this:
local api = require "engine_api"
print("Engine version:", engine_api.engine.version());
I still need it to work this way. But what I'd like to do is separate various parts of the API into different files. I thought I might be able to do this using metamethods. But when the metamethod is looked up, the value is actually a string so this naive approach will not work.
local engine = {
-- engine functions...
version = function()
print("engine.version")
end
}
local image = {
-- image functions
get = function()
print("image.get")
end
}
local project = {
-- project functions
load = function()
print("project.load()")
end
}
-- Engine API module
local engine_api = {
}
local engine_api_mt = {
__index = function(tbl, k)
print("k=", k)
return k
end
}
setmetatable(engine_api, engine_api_mt)
Instead I seem to have to do bunch of if then else statements to compare the table name with the string and then return the table and not the string. Is there a way of performing the conversion automatically?
You can make engine_api a single file and require files inside that table, like so:
engine_api.lua:
local engine_api = {
engine = require("engine"),
image = require("image"),
project = require("project"),
}
return engine_api
engine.lua:
local engine = {
version = function()
print("my version")
end
}
return engine
And so on, that way you can call engine_api.engine.version() with no problems at all. I think the metatable is just over the top, unless you are doing something more specific?
In my recently aided in the development of a Dataframe package for Torch. As the code base has quickly doubled there is a need to split the class into several sections for better organization and follow-up (issue #8).
A simple test-class would be a test.lua file in the root folder of the test-package:
test = torch.class('test')
function test:__init()
self.data = {}
end
function test:a()
print("a")
end
function test:b()
print("b")
end
Now the rockspec for this would simply be:
package = "torch-test"
version = "0.1-1"
source = {
url = "..."
}
description = {
summary = "A test class",
detailed = [[
Just an example
]],
license = "MIT/X11",
maintainer = "Jon Doe"
}
dependencies = {
"lua ~> 5.1",
"torch >= 7.0",
}
build = {
type = 'builtin',
modules = {
["test"] = 'test.lua',
}
}
In order to get multiple files to work for a single class it is necessary to return the class object initially created and pass it to the subsections. The above example can be put into the file structure:
\init.lua
\main.lua
\test-0.1-1.rockspec
\Extensions\a.lua
\Extensions\b.lua
The luarocks install/make copies the files according to 'require' syntax where each . signifies a directory and the .lua is left out, i.e. we need to change the rockspec to:
package = "torch-test"
version = "0.1-1"
source = {
url = "..."
}
description = {
summary = "A test class",
detailed = [[
Just an example
]],
license = "MIT/X11",
maintainer = "Jon Doe"
}
dependencies = {
"lua ~> 5.1",
"torch >= 7.0",
}
build = {
type = 'builtin',
modules = {
["test.init"] = 'init.lua',
["test.main"] = 'main.lua',
["test.Extensions.a"] = 'a.lua',
["test.Extensions.b"] = 'b.lua'
}
}
The above will thus create a test-folder where the packages reside together with the files and subdirectories. The class initialization now resides in the init.lua that returns the class object:
test = torch.class('test')
function test:__init()
self.data = {}
end
return test
The subclass-files now need to pickup the class object that is passed using loadfile() (see init.lua file below). The a.lua should now look like this:
local params = {...}
local test = params[1]
function test:a()
print("a")
end
and similar addition for the b.lua:
local params = {...}
local test = params[1]
function test:b()
print("b")
end
In order to glue everything together we have the init.lua file. The following is probably a little over-complicated but it takes care of:
Finding all extensions available and loading them (Note: requires lua filesystem that you should add to the rockspec and you still need to add each file into the rockspec or it won't be in the Extensions folder)
Identifies the paths folder
Loads the main.lua
Works in a pure testing environment without the package installed
The code for init.lua:
require 'lfs'
local file_exists = function(name)
local f=io.open(name,"r")
if f~=nil then io.close(f) return true else return false end
end
-- If we're in development mode the default path should be the current
local test_path = "./?.lua"
local search_4_file = "Extensions/load_batch"
if (not file_exists(string.gsub(test_path, "?", search_4_file))) then
-- split all paths according to ;
for path in string.gmatch(package.path, "[^;]+;") do
-- remove trailing ;
path = string.sub(path, 1, string.len(path) - 1)
if (file_exists(string.gsub(path, "?", "test/" .. search_4_file))) then
test_path = string.gsub(path, "?", "test/?")
break;
end
end
if (test_path == nil) then
error("Can't find package files in search path: " .. tostring(package.path))
end
end
local main_file = string.gsub(test_path,"?", "main")
local test = assert(loadfile(main_file))()
-- Load all extensions, i.e. .lua files in Extensions directory
ext_path = string.gsub(test_path, "[^/]+$", "") .. "Extensions/"
for extension_file,_ in lfs.dir (ext_path) do
if (string.match(extension_file, "[.]lua$")) then
local file = ext_path .. extension_file
assert(loadfile(file))(test)
end
end
return test
I hope this helps if you run into the same problem and find the documentation a little too sparse. If you happen to know a better solution, please share.