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

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


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