Re: Desired Lua Features

[Paige DePol <lual@...>]

Sean Conner <sean@conman.org> wrote:

> It was thus said that the Great Paige DePol once stated:
>> So, if you could add any one feature to Lua right now, what would that
>> feature be and why would you want to see it added? Please note that this
>> discussion is in no way meant to be interpreted as pressuring Team Lua to
>> add any features to Lua, I am genuinely curious what features people want
>> to see added to Lua and why.
> 
>  Right now---breakpoints.  Every CPU I've programmed has had such a
> feature.  The x86 has INT3, the MC68000 has TRAPn, MIPS the BREAK, the 6502
> BRK, the 6809 SWI, etc.  I would like to see a Lua VM opcode that does the
> same thing, which could be used to avoid the overhead of hooks (the Lua
> program can run full speed until the breakpoint is hit).  
> 
>  Some API in the debug module would probably have to be made to support
> this, but it's something I feel would be nice.  Even something as simple as
> tripping on a function call:
> 
> 	debug.setbreakpoint(target_function,code_to_run)
> 
> where code_to_run() can then do the full hooks method if further detail was
> needed.

I was developing a macOS program a while back, even posted a screenshot, and
it had the ability to set breakpoints. However, it was via a patch to allow
me direct access to all the internals of Lua without using hooks. The idea
being that I wanted to let Lua run as it should, calling hooks when needed,
but allowing me to peek into the internals as needed as well.

A nice benefit of that was gaining the ability of having the parser tell me
what elements it had found so I could do very nice code syntax coloring!

I also had the ability to set breakpoints either on specific lines of code
or via direct instructions in the bytecode, so I can see how having the
ability to set breakpoints would be useful.

I would think that being able to compile a special "debugger" version of Lua
may be helpful. It could then potentially use some standardised protocol to
reveal the internals of Lua directly, leaving hooks for the actual code that
uses them to do so. Then once debugging was finished the standard release
version of Lua could be used to mitigate any performance loss or memory usage
overhead from using the debugging specific version.

I do plan to use the guts of the program I created in a new cross-platform
project that will have the same goal, watching the internals of Lua.

~Paige