puremourning / vimspector

vimspector - A multi-language debugging system for Vim
http://puremourning.github.io/vimspector-web
Apache License 2.0
4.11k stars 175 forks source link

[Feature Request]: Support Lua #234

Closed aidoTank closed 4 years ago

puremourning commented 4 years ago

What debug adapter is there for Lua? Which ones have you tried?

puremourning commented 4 years ago

looks like there's this: https://github.com/actboy168/lua-debug

found this too, but have no idea how to make it work : https://github.com/dibyendumajumdar/ravi-vscode-debugger

but I can't read the readme.

PR welcome with tests.

aidoTank commented 4 years ago

EmmyLua:https://github.com/EmmyLua/EmmyLuaDebugger LuaPandahttps://github.com/Tencent/luapanda but only support idea or vscode

puremourning commented 4 years ago

we need something that has a DAP interface, ideally with its documentation written in English.

By following the documentation you should be able to use any DAP debug adapter without changes to vimspector.

luoxz-ai commented 4 years ago

[Feature Request]: Support Lua EmmyLua: https://github.com/EmmyLua/EmmyLuaDebugger LuaPanda: https://github.com/Tencent/luapanda Client <--- ---> Server
debug

puremourning commented 4 years ago

https://github.com/puremourning/vimspector/wiki/languages

puremourning commented 4 years ago

Looks like it should be trivial to make this work : https://github.com/dibyendumajumdar/ravi-vscode-debugger/blob/master/package.json#L37-L43. Please contribute and help others.

eduardomezencio commented 4 years ago

There's this https://github.com/tomblind/local-lua-debugger-vscode I've been using it for some time now, works really great and can debug love2d games (the thing I really use it for). I'll try to get it working with vimspector on the next few days and report the results here

eduardomezencio commented 4 years ago

I may need some help to get this going. I tried to configure the extension I mentioned above, I see that vimspector is connecting to the extension's adapter and even launching the program, but I can't stop in breakpoints. I added "verbose": true to my launch config both in vscode and in vimspector, hoping that it would show me some clue. It prints basically the same, except that I see vscode printing something that I don't see when I run in vimspector

[request] launchRequest
[request] configurationDoneRequest
[info] launching `"love" /home/edju/Documents/Code/love/test4 -debug` from "/home/edju/Documents/Code/love/test4"
[info] process launched
[request] threadsRequest

everything above is printed to the terminal in both cases, but right after that, in vscode only, when debugging starts, I see

[message] {"threadId":1,"breakType":"step","tag":"$luaDebug","type":"debugBreak","message":"step"}

Do you have any tip for something I can check/try?

puremourning commented 4 years ago

Can you gist the entire vimspector log?

And the entire DAP trace from vscode?

The message above does not look standard.

eduardomezencio commented 4 years ago

Can you gist the entire vimspector log?

This is the vimspector log vimlog.txt

And the entire DAP trace from vscode?

I can't find this log in vscode, can you point me to some instructions?

The message above does not look standard.

Yes, this specific from this extension, I just put it there because maybe it would ring a bell to someone.

puremourning commented 4 years ago

it is rejecting the threads request (without giving a reason)

2020-11-11 23:33:14,222 - DEBUG - Message received: {'seq': 5, 'type': 'response', 'request_seq': 3, 'command': 'threads', 'success': False}
2020-11-11 23:33:14,222 - ERROR - Request failed: None

But after that there are no events; no breakpoint events or anything. Maybe it broke. I've seen servers break for less.

Can you try maybe to comment out this line in python3/vimspector/debug_session.py (around line 1022):

      self._stackTraceView.LoadThreads( True )

I have no idea how to get logs out of vscode. I've barely used it.

puremourning commented 4 years ago

Perhaps related https://github.com/puremourning/vimspector/issues/285

eduardomezencio commented 4 years ago

Here's the log after commenting this line: vimspector-log-commenting-load-threads.txt

Not really related to this log, but I thing I found the problem, I'll investigate a bit more and then report here

eduardomezencio commented 4 years ago

Well, I kinda know what the problem is, but don't know how to solve it.

One first point to be noted about this extension is that for its debugging to work, it requires you to, somewhere in your code, call require("lldebugger").start(), and breakpoints only start working after calling that in your code. To be able to call that, the extension needs to add the extension path to your LUA_PATH, since the lldebugger.lua source file that you need to import is in the extension folder.

I don't know exactly how it works for the extension to get this path, but it seems to set this path here (I don't know if vimspector even runs this code) and it's used here to set the lua path and allow you to import the file.

What I know is that, if I get the files that need to be imported and manually put them in the lua path before calling require "lldebugger", then the extension works correctly, stopping on breakpoints, allowing me to inspect variables and so on. Although it works for me like that already, I would like to get it correctly configured and add it to vimspector supported debuggers. Do you have any idea about the way to go from here?

puremourning commented 4 years ago

I don't know if vimspector even runs this code

It doesn't. That looks like vscode extension code.

and it's used here to set the lua path and allow you to import the file.

It looks like you should be able to set extensionPath in your launch config to point to whatever is needed, then shouldn't that work?

if you used a gadget installer file to install the extension then vimspector gives you ${gadgetDir} which might help.

eduardomezencio commented 4 years ago

Thanks, it worked perfectly now.

I would like to contribute this to vimspector, but I tried to create a gadget installer file for this, and I see that after cloning the repository, the install process removes a lot of the needed files for the debugger to run, for some reason.

To get it to work, I did everything manually: cloned the vscode extension repository inside vimspector/gadgets/linux, built it (npm install && npm run build), created a config file for it in .gadgets.d/lua-local.json:

{
  "adapters": {
    "lua-local": {
      "command": [
        "node",
        "${gadgetDir}/local-lua-debugger-vscode/extension/debugAdapter.js"
      ],
      "configuration": {
        "interpreter": "lua",
        "extensionPath": "${gadgetDir}/local-lua-debugger-vscode"
      },
      "name": "lua-local"
    }
  }
}

and finally added the vimspector.json file to my project's root folder, with content similar to the launch.json one would use in vscode.

I don't know if it's possible to do this with gadget installers, because it deletes some of the files needed, as I mentioned before, and also because it doesn't seem to support running build commands after cloning the repository, and this particular extension requires this additional step.

So, right now, other than pointing my steps to make it work, I don't know how I can contribute this to the project.

puremourning commented 4 years ago

Thanks. The gadget installer files are kinda limited. If it needs to run npm install, I think it can’t do that. We could perhaps add some script option to run commands after download but it starts to look like an inner-system effect.

Writing up the steps on the wiki would be helpful.

The other option is to make a PR to add it as a supported gadget in gadgets.py, installer.py and README.md (and a simple test case in support/test/lua)

eduardomezencio commented 4 years ago

The other option is to make a PR to add it as a supported gadget in gadgets.py, installer.py and README.md (and a simple test case in support/test/lua)

I'll look into this option and try to open a PR soon.

puremourning commented 4 years ago

Fixed by #294