Re: Modify Lua Executable for a -51 option

[Russell Haley <russ.haley@...>]

On Sun, May 6, 2018 at 5:43 PM, Sean Conner <sean@conman.org> 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
thing).

  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
variables).

  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. 

  -spc

[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.