lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Sun, May 6, 2018 at 5:43 PM, Sean Conner <> wrote:
It was thus said that the Great Russell Haley once stated:
> Okay, here's a really embarassing thing to have to admit: I actually spent
> more than 30 seconds looking for a C library to parse options from a
> command line and another one to read in a config file. Really. I did that
> while creating a C program to *wrap the lua executable*.
> I'm thinking about creating the following options that that can be run from
> command line or set by a config file:
> - Said -51 option (done)
> - a -64bit option. No idea how to do that...
> - choose the garbage collector and step
> - set the path and cpath
> (yes, yes. glorified script file)

  If you are going down this path, then plan to go all-out:  options can be
set by

        command line, which overrides (or extends)
        environment variables, which overrides
        per-directory config file (example ./megalua.conf), which overrides
        per-user config file (example $HOME/.megalua), which overrides
        system-wide config file (example /etc/megalua), which overrides
        default setting in the program.

That's exactly what I was thinking but perhaps a slightly different order of override:
- command line overides
- local directory config file overrides
- environment variables
- user config file
- global per interpreter file

I'll also need a LUA_51 "configuration tree" as well.

  So, what do you mean by "-64bit"?
Sorry,  a half thought: The idea is to start with the 32 bit application and if the user wants a 64 bit interpreter (specified -64bit), the 32 bit application launches the 64 bit application with the same parameters and then closes.

> Anyway, what I really wanted to converse about is the possibility of
> putting instrumentation in lua to return various run time data points (e.g.
> 'how long x takes to execute, how many times function y was called) and
> then to consider a built in debugger. Does anyone have thoughts on that?

  All of that can be done within Lua itself---no need to modify the Lua
interpreter.  The only feature Lua lacks is a true breakpoint---run the code
until *this* point in the program, but you can simulate it (it requires the
line hook (hook called for every line of code) which is not quite the same

  But aside, all a debugger really needs is a way of gaining control (Lua
does, with hooks) and a way of examining the environment.  Lua's
debug.debug() function can almost do this (it can't examine local

  What would I want from a debugger?  The ability to set a true breakpoint.
The ability to examine all the state (including locals).  The ability to
attach to currently running Lua code and start debugging [1].
Thanks for the input! I'll examine this. :)

I know LuaPlus has a spiffy debugger that's designed to be embedded in a C++ application. It (apparently) calls the Scite text editor, but I don't know too much more besides that. 


[1]     That last one is key for what I do at work.  It's not always easy to
        run Lua from a debugger at work, so the ability to "attach" to a
        running program is nice.