lua-users home
lua-l archive

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


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.

  So, what do you mean by "-64bit"?

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

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