Lua 5.1 support

[nyankers]

I wrote a patch that adds optional Lua 5.1 support over here.

The focus was on getting Lua and tintin++ ways to communicate, rather than to re-implement all of tintin++ scripting in Lua.

As a result, mostly of the Lua API was written to retrieve information or to set hookpoints to call Lua functions. For example, you still need to call the tintin++ commands to remove nodes (e.g. tt.exec("#unaction", match)) or to create/update map-related stuff.

All triggers have been updated to handle Lua functions, but otherwise the changes to the core tintin++ code was pretty minimal. This is intentional to hopefully make it easier to keep the patch in sync with the core tintin++ code, since I plan to use it, and touching the core tintin++ code would make it harder to merge in any upstream changes. This also means there's a fair bit of redundant code in the Lua modules, because I essentially rewrote what the tintin++ equivalent commands did but for Lua, to avoid overly touching the tintin++ side.

I chose Lua 5.1 specifically, partly to support LuaJIT, and partly because the ability to set environments to threads allowed me to have different sessions have a shared Lua state while having differing environments and threads. This was necessary to keep the copy behavior from gts to newly opened sessions without them all just straight up sharing the same environment, which I thought went against the spirit of tintin++'s overall design. It also serves as a happy medium for allowing different sessions to communicate on the Lua side of things.

One thing I noticed while doing this work was that there are no const char* arguments in tintin++'s code despite many functions having char * arguments they don't touch. I think changing this might have some benefits, because all the strings coming out of Lua are const char*, presumably due to Lua's string internment. For now, I'm copying them into stack strings (str_alloc_stack()), which is probably good enough for a patch. I hesitantly added one in the patch to str_cpy() just because the only thing it's internally calling is strcpy(), but I didn't want to do any more than that.

If you want to try it out, ./configure now supports a few extra options:

• You can pass in LUA=luajit or whatever to specify which Lua library to use (it checks for the existence of lua_setfenv so it won't let you accidentally use Lua 5.2+).
• You can also pass in --with-lua to tell it you want Lua, in which case it'll fail if it's unable to figure out how to get it for you.
• Or --without-lua to prevent it from compiling in Lua functionality, even if you have it available on your system.
• If you're like me and your default includes point to Lua 5.4, you probably also want to set --include-dir=<path> to point to the correct includes.

If you don't pass in --with-lua or the LUA environment variable, it will default to compiling in Lua support if it finds 5.1, and not compiling it in otherwise. The added #LUA command will still exist, but only #lua check will work properly.

I've also added in the very barebones #PROCEDURE and #CALL commands into this patch as a way of allowing tintin++ to call Lua functions directly. Aliases could already be used for this purpose, but I think it's a bit cleaner this way, since you can avoid clouding user input. Of course, they also support running tintin++ scripts, even if the main purpose for adding them is tintin++ to lua communication.

If it looks like an interesting addition to tintin++, I'd be happy to help with any issues there.

Although I did a fair bit of local testing, I really can't guarantee there aren't major bugs or crashes in the patch, so use it at your own risk. The various Lua stuff can be found at #help lua, #help tt api, #help map api, and #help lua getters.

[scandum]

Unfortunately, this isn't something I'm willing to add, for a variety of reasons.

I'm willing to link to your fork from the tintin webpage, though you'd probably want to update the README with some information for people to get started.

[nyankers]

I'm curious what those reasons are. Not that you have to defend not wanting to add it or anything like that, that's perfectly understandable, but just in case they're useful to know as I work on adding it for myself anyway.

It's still pretty unstable, I even managed to find a few major issues since writing the original post, so it might be good to hold off on linking it until I've had a chance to iron it out a bit more. Thanks though!

Once it's a bit more stable, besides filling in the README, I'd probably also want to write some examples of using the Lua side of things. I'll be happy to update you if/when it reaches that point.

[nyankers]

Neat. Although the UIs are totally different, I could imagine some kind of wrapper to share common code between lua tintin++ and mudlet. I don't use mudlet though, so I'm probably not the best person to do that.

Let me know if you find any bugs, have any suggestions, etc.

[mikeggh]

Have discord, irc, or etc?

[mikeggh]

I wanted to discuss pushing all events through the lua engine..

[nyankers]

Oops sorry. If you mean events like #event, you can use tt.event() to do that.

The tintin++ wrapper code is intentionally light for similar reasons to lua as a whole being light, not to mention to try and reduce possible issues when upgrading, but you can build a whole event processing framework in lua if you wanted to. Of course, you could also do that in vanilla tintin++.

One thing I wanted to do that I don't think I actually figured out was make the CATCH events depend on the lua function's return value...

[mikeggh]

I was able to capture input line text, and change it.. for instance to replace bag1 with some long identifier, and send that to the mud. I used..

 
-- remove line from being sent to mud..for one line
function catch_send_filter()
  tt.exec("#unevent {CATCH SEND OUTPUT}")
end

-- vars we wanna search for and replace
varfix = {"bag0","bag1","bag2","ssbag","sbag"}
varrep = {}
-- replace ids from insults
varrep["ssbag"] = "8pioikct2y52n5miazw6xc5mw2n"
varrep["sbag"] = "8pioikct2y52n5miazw6xc5mw2n"
varrep["bag0"] = "lfb7n1by4wqd5liwa476t15i89xa"
varrep["bag1"] = "21rtkkyylp09b5cqzuuav179004p"
varrep["bag2"] = "uurrlpipw089ffgtbd4gekxb81k6"

-- search for these vars
function fix_vars(line, vars)
  local modified_line = line
  for _, var in ipairs(vars) do
    local pattern = "([^$])(" .. var .. ")" -- Match a non-$ followed by the var
    if varrep[var] ~= nil then
      modified_line = modified_line:gsub(pattern, " "..varrep[var])
    else
      modified_line = modified_line:gsub(pattern, " $%2")
    end
  end
  return modified_line
end


ignore_line = false
-- process all cmds going to mud, replace if necessary
function send_filter()
  if ignore_line == true then return end

  oline = tt.get("outputline")
  --pecho("Send filter",oline)
  local blocked = false
  --oline2 = oline
  oline2 = fix_vars(oline, varfix)
  --pecho("oline",oline)
  --pecho("oline2",oline2)
  -- if we modified the line.. send the modifed version
  if 1==1 and tostring(oline2) ~= tostring(oline) then
    -- set this flag so we dont try to modify it twice
    ignore_line = true
    send(oline2)
    ignore_line = false
    -- now setup catch for original line so its wont get sent
    tt.exec("#event {CATCH SEND OUTPUT} {#lua exec catch_send_filter()}")    
  end
end

tt.exec("#event {SEND OUTPUT} {#var {outputline} {%0}; #lua exec send_filter()}")

.. It was the only thing I had tried that NEEDED a catch..

[scandum]

For similar reasons that mudlet doesn't add tintin scripting, even if they should. 😛

Will be interesting to see some example scripts once you got them ready.

[mikeggh]

One example that I like doing is reading/writing sqlite tables. I do not think it is easy as is with tintin scripting. LUA offers this.. I have some examples as well: https://gist.github.com/mikeggh/8780e8460f2447a822d5c44292c499ed (updated, had to remove to change data) .. This gist has 4-5 diff LUA files for different muds. Slothmud, Kallisti, Majormud, and nukefire.. I do not know tintin scripting so I wouldn't have been able to accomplish this.. It is sorta like using python because tons of things exist on pip to expand w out reinventing the wheel..

[sidera-dev]

Do you plan to continue develp it ? or port to the last version of tintin ?

[mikeggh]

I didn't develop it.. ^^^^ nyankers above did.. and I'm currently using LUA for everything and tintin for mapper, and other features liek MSDP/GMCP.. so I personally am not sure I need the newer features

[sidera-dev]

it's a very intresting project, , I'm adding python scripting support (I do know python better ) inspired on this work and using a similar method on my fork. Hope Scandum won't be disappointed

[mikeggh]

He also said he won't accept the pull. You may find people like me who will use anyways!

[sidera-dev]

Well the project is his, I think he has it's son reasons.