sakhnik / nvim-gdb Goto Github PK
View Code? Open in Web Editor NEWNeovim thin wrapper for GDB, LLDB, PDB/PDB++ and BashDB
Neovim thin wrapper for GDB, LLDB, PDB/PDB++ and BashDB
After upgrading this morning I the plugin does not work. Instead much error text is generated centering around a missing gdb.app, eventually ending with:
E5108: Error while calling lua chunk for luaeval(): [string ""]:1: attempt to index global 'gdb' (a nil value)
I checked the prerequisites, but maybe I missed something. I can't seem to find this gdb.app lua module anywhere. Is it part of this plugin or something else? Any tips? It worked great before, and I love this plugin.
Using NVIM v0.3.1 from the 18.04LTS package from the Ubuntu repos.
Taken from the issue's #14 comment:
After starting nvim I usually press ctrl - p
to search for the file I want to edit.
:map <C-p>
results in the following output: n <C-P> * :FZF<CR>
Typing :GdbStart gdb -q -f <mybinary>
starts the the TUI like environment in a new tab.
After my debug session I write quit in the debuggers console. It is not necessary to do anything. Writing quit instantly results in the same issue.
This results in switching to my previous tab where I edited my file.
All keymaps are overwritten from now on.
:map <C-p>
results in the following output: No mapping found
These are my settings for this plugin:
" nvim-gdb ((((((((((((((((((((((((((((((((((((((((((((((((
" gdb and lldb wrapper
Plug 'sakhnik/nvim-gdb'
let g:nvimgdb_disable_start_keymaps = 1
" nvim-gdb ))))))))))))))))))))))))))))))))))))))))))))))))
PS: Had the same issue before setting let g:nvimgdb_disable_start_keymaps = 1
A tiny python proxy would open PTY to allow issuing server commands to GDB or LLDB outside stdin, and return result programmatically without stdout. Conveniently, GDB allows to bypass command history by prefixing commands with server
.
Consider naming custom commands in a specific manner <start,end> for easier concealment.
x-nvim-gdb-
and next GDB/LLDB promptHow to overwrite the default mappings for <Leader>dd
and <Leader>dl
?
I don't want to remove ./a.out
all of the time.
This did not work
nnoremap <leader>dd :GdbStart gdb -q -f
nnoremap <leader>dl :GdbStartLLDB lldb
settings set frame-format
has a more global effect than needed.
The alternative target stop-hook add --one-liner 'print(lldb.frame.GetLineEntry())'
isn't suitable too, because it wouldn't track navigation in the call stack (up, down).
We need either to work around or to declare a limitation.
Consider querying for LLDB breakpoints on every step just like in GDB (#20). Unfortunately, LLDB doesn't allow concealing commands in the history. So need to scout anything useful in LLDB API.
So as a first idea of a feature that can be implemented via lldb's python API would be to query for the stack. You can do this either with a :NvimGdbQueryStack
or as a persistent display on every single stop.
This could be don via something like (making up the APIs as I go as I don't know them all off the top of my head)
if is_x86_64():
stack_pointer = "$rsp"
else:
stack_pointer = "$sp"
output = lldb.HandleCommand(f"memory read -l 8 -c 64 {stack_pointer}")
process_stack_output(output)
vim.command("vert bo 30new | setlocal notemp | setlocal readonly")
w = vim.windows.getlast()
w.contents = output
What are your thoughts on this?
The plugin tends to issue <c-c>
here and there for its own purposes. Try to leave the execution intact at all times. One way could be to defer the execution to the time when the program is interrupted by other events.
While using GdbStartPDB python3 ...
, GdbEvalWord
doesn't have knowledge that I'm using python 3, so it uses print ...
instead of print(...)
When there is a duplicate breakpoint on a line, it's possible to show the count of them.
Consider making an option to configure custom symbols for the signs and optional number for the terminals that support proper font rendering.
We'll need a C++ test project. Consider dependencies (gdb, lldb, cmake, shell). Investigate available vim/shell test frameworks.
Just rebased to check your current patch and hit this immediately. I went to the docs and copied in
\ 'sign_current_line': '▶',
\ 'sign_breakpoint': [ '●', '●²', '●³', '●⁴', '●⁵', '●⁶', '●⁷', '●⁸', '●⁹', '●ⁿ' ]
\ }
to both my config and default config_override and it still errors out. Hackaround was just to sign define GdbCurrentLine text=▶
in my init.vim.
Hi,
This is a bit of a complex issue to describe but when I'm in the code buffer and doing multiple GdbBreakpointToggle on for example the empty line just before a function, it keeps stacking breakpoints instead of toggling the breakpoint just below.
I guess it might be a bit of a hard issue to resolve, but would solidify greatly the already awesome plugin that you created!
When i started it by ":GdbStart gdb -q -f a.out",i got errors bleow:
Error detected while processing function nvimgdb#Spawn[1]..98_InitMachine:
line 20:
E118: Too many arguments for function: function
E15: Invalid expression: function("s:GdbPaused_continue", data)
line 21:
E118: Too many arguments for function: function
E15: Invalid expression: function("s:GdbPaused_jump", data)
line 22:
E118: Too many arguments for function: function
E15: Invalid expression: function("s:GdbPaused_info_breakpoints", data)
line 23:
E118: Too many arguments for function: function
E15: Invalid expression: function("s:GdbPaused_breakpoint", data)
line 26:
E118: Too many arguments for function: function
E15: Invalid expression: function("s:GdbRunning_pause", data)
It looks like the commands like :GdbNext
persist. They are useless after the debugging session.
Consider undefining them after quitting a session.
Hi,
I love the feature of overriding keys for debugging and it's in my point of view extremely useful.
But something that could be great would be to stop the overriding when typing things into the command line. an example would be to just try typing start in the gdb command line after opening the debugging tab. I saw (maybe I'm wrong) that the override is disabled when going to another tab, so I guessed it was feasible.
Thanks for your dedication!
a dlv wrapper would be useful.
Error detected while processing function <lambda>1:
line 1:
E5108: Error while calling lua chunk for luaeval(): ...g/nvim/pack/minpac/start/nvim-gdb/lua/gdb/breakpoint.lua:95: connect: No such file or directory
This happens frequently upon just launching lldb.
Seems like the UDS isn't being created at some point? Can't make sense out of the moonscript syntax to really follow it.
Run tests on [https://travis-ci.org]
Look at the TODOs in the test_30_pdb.py
. Decide how to fix the disabled checks.
Hi, I was trying to use your plugin when I encountered several issues.
First of all, I think you should point out in your README.md that you have to launch ./install in the plugin directory to install it.
But then, when I tried, I got the following output at the end:
Installing https://luarocks.org/json-lua-0.1-3.rockspec
Cloning into 'json-lua'...
remote: Enumerating objects: 7, done.
remote: Counting objects: 100% (7/7), done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 7 (delta 0), reused 3 (delta 0), pack-reused 0
Receiving objects: 100% (7/7), 15.89 KiB | 15.89 MiB/s, done.
Do not use 'module' as a build type. Use 'builtin' instead.
json-lua 0.1-3 is now installed in /home/narice/.vim/bundle/nvim-gdb/lua/rocks (license: CC)
/usr/bin/luajit: ...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: error loading module 'lfs' from file '/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so':
/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so: undefined symbol: luaL_setfuncs
stack traceback:
[C]: in function 'a_loader'
...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: in function <...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:150>
[C]: in function 'require'
...ocks/lib/luarocks/rocks-5.1/moonscript/0.5.0-1/bin/moonc:4: in main chunk
[C]: at 0x563de9e87c00
/usr/bin/luajit: ...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: error loading module 'lfs' from file '/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so':
/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so: undefined symbol: luaL_setfuncs
stack traceback:
[C]: in function 'a_loader'
...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: in function <...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:150>
[C]: in function 'require'
...ocks/lib/luarocks/rocks-5.1/moonscript/0.5.0-1/bin/moonc:4: in main chunk
[C]: at 0x55b8eda61c00
/usr/bin/luajit: ...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: error loading module 'lfs' from file '/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so':
/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so: undefined symbol: luaL_setfuncs
stack traceback:
[C]: in function 'a_loader'
...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: in function <...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:150>
[C]: in function 'require'
...ocks/lib/luarocks/rocks-5.1/moonscript/0.5.0-1/bin/moonc:4: in main chunk
[C]: at 0x55734df2cc00
/usr/bin/luajit: ...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: error loading module 'lfs' from file '/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so':
/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so: undefined symbol: luaL_setfuncs
stack traceback:
[C]: in function 'a_loader'
...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: in function <...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:150>
[C]: in function 'require'
...ocks/lib/luarocks/rocks-5.1/moonscript/0.5.0-1/bin/moonc:4: in main chunk
[C]: at 0x55943d2cac00
/usr/bin/luajit: ...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: error loading module 'lfs' from file '/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so':
/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so: undefined symbol: luaL_setfuncs
stack traceback:
[C]: in function 'a_loader'
...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: in function <...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:150>
[C]: in function 'require'
...ocks/lib/luarocks/rocks-5.1/moonscript/0.5.0-1/bin/moonc:4: in main chunk
[C]: at 0x563afdcfac00
/usr/bin/luajit: ...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: error loading module 'lfs' from file '/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so':
/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so: undefined symbol: luaL_setfuncs
stack traceback:
[C]: in function 'a_loader'
...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: in function <...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:150>
[C]: in function 'require'
...ocks/lib/luarocks/rocks-5.1/moonscript/0.5.0-1/bin/moonc:4: in main chunk
[C]: at 0x5629926f6c00
/usr/bin/luajit: ...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: error loading module 'lfs' from file '/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so':
/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so: undefined symbol: luaL_setfuncs
stack traceback:
[C]: in function 'a_loader'
...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: in function <...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:150>
[C]: in function 'require'
...ocks/lib/luarocks/rocks-5.1/moonscript/0.5.0-1/bin/moonc:4: in main chunk
[C]: at 0x5595897b2c00
/usr/bin/luajit: ...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: error loading module 'lfs' from file '/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so':
/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so: undefined symbol: luaL_setfuncs
stack traceback:
[C]: in function 'a_loader'
...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: in function <...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:150>
[C]: in function 'require'
...ocks/lib/luarocks/rocks-5.1/moonscript/0.5.0-1/bin/moonc:4: in main chunk
[C]: at 0x56447d279c00
/usr/bin/luajit: ...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: error loading module 'lfs' from file '/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so':
/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so: undefined symbol: luaL_setfuncs
stack traceback:
[C]: in function 'a_loader'
...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: in function <...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:150>
[C]: in function 'require'
...ocks/lib/luarocks/rocks-5.1/moonscript/0.5.0-1/bin/moonc:4: in main chunk
[C]: at 0x557a76f05c00
/usr/bin/luajit: ...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: error loading module 'lfs' from file '/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so':
/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so: undefined symbol: luaL_setfuncs
stack traceback:
[C]: in function 'a_loader'
...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: in function <...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:150>
[C]: in function 'require'
...ocks/lib/luarocks/rocks-5.1/moonscript/0.5.0-1/bin/moonc:4: in main chunk
[C]: at 0x56284b54ac00
/usr/bin/luajit: ...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: error loading module 'lfs' from file '/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so':
/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so: undefined symbol: luaL_setfuncs
stack traceback:
[C]: in function 'a_loader'
...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: in function <...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:150>
[C]: in function 'require'
...ocks/lib/luarocks/rocks-5.1/moonscript/0.5.0-1/bin/moonc:4: in main chunk
[C]: at 0x564c56e84c00
/usr/bin/luajit: ...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: error loading module 'lfs' from file '/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so':
/home/narice/.vim/bundle/nvim-gdb/lua/rocks/lib/lua/5.1/lfs.so: undefined symbol: luaL_setfuncs
stack traceback:
[C]: in function 'a_loader'
...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:153: in function <...dle/nvim-gdb/lua/rocks/share/lua/5.1/luarocks/loader.lua:150>
[C]: in function 'require'
...ocks/lib/luarocks/rocks-5.1/moonscript/0.5.0-1/bin/moonc:4: in main chunk
[C]: at 0x560705880c00
All the following errors seems to point to the same cause, the lfs module, but I don't really know what to do at this point.
I hope the output helps you a bit.
Thanks in advance!
Set multiple breakpoints, continue few times. Make sure the arrow is always shown.
Hi,
I'm getting the following errors when starting GdbStartLLDB with a simple .c program.
"allEven.c" 47L, 1090C
Error detected while processing function <SNR>107_JobOutput[1]..31[15]..32[13]..<SNR>106_GdbRunning_pause[7]..24:
line 1:
E117: Unknown function: chansend
Error detected while processing function <SNR>107_JobOutput[1]..31[15]..32[13]..<SNR>106_GdbRunning_pause[7]..24:
line 1:
E117: Unknown function: chansend
Error detected while processing function <SNR>107_JobOutput[1]..31[15]..32[13]..<SNR>106_GdbRunning_pause[7]..24:
line 1:
E117: Unknown function: chansend
Error detected while processing function <SNR>107_JobOutput[1]..31[15]..32[13]..<SNR>106_GdbRunning_pause[7]..24:
line 1:
E117: Unknown function: chansend
I am on macOS.
lldb --version == lldb-900.0.64
In the GDB CLI type info <tab>
to show the completions. Then type locals
.
Expected: info locals
executed.
Actual: 'Command not found: local'
It looks like info breakpoints
is fired automatically, messing with the interpreter. Need to find a way to distinguish between prompt + pause and prompt + prefix of the next command.
lldb has listeners and event emitters that will let you know when the state changes and events in the debugger. e.g. you can register to listen for StateChanged
and check if StateStopped
and StopReasonBreakpoint
. This will fix the bt
bug where nvim-gdb switches files 14 times for all 14 stack frames due to lldb printing out 14 frames and nvim-gdb parsing 14 different cues to switch files.
And obviously this opens up the possibilities for many other improvements once you get that going. (e.g. querying frame var
after every stop and updating a side panel with the variable info, thread lists, frame lists, memory views, etc etc etc)
Here's a little example script that demonstrates the APIs:
https://github.com/apple/swift-lldb/blob/stable/examples/python/performance.py
Any interest on this idea?
The debugging commands don't make sense outside the debugging session. Set/unset them as the user navigates the tab pages.
Alternatively, make mappings buffer-local. Keep in mind that a user may open buffers in the debug tab page too.
When providing the full python executable I would expect sys.path
to be set as:
$ .venv/bin/python -m pdb foo.py
$ (Pdb) import sys
$ (Pdb) sys.path
['', '/Users/berserk/Source/ocean/.venv/lib/python36.zip', '/Users/berserk/Source/ocean/.venv/lib/python3.6', '/Users/berserk/Source/ocean/.venv/lib/python3.6/lib-dynload', '/nix/store/mb1fwxr8w1n16fww8bp8spy6xy5dbjhm-python3-3.6.6-env/lib/python3.6', '/Users/berserk/Source/ocean/.venv/lib/python3.6/site-packages']
Whereas in :exe 'GdbStartPDB '.expand('%:p:h').'/.venv/bin/python -m pdb '.expand('%')
, sys.path
is equal to that of $ python -m pdb foo.py
.
Might be the cause of #42, since my virtualenv's python is 3 and my system's python is 2.
I use cgdb a lot and just come across nvim-gdb, think it may integrate well with my LSP workflow. cgdb is not very helpful reading source code due to the lack of cross references. In nvim + LanguageClient-neovim, I can use ccls for definition/references/hover.
Is it easy to turn the following some cgdb bindings into nvim-gdb maps?
# `;` switches to the source window
# `i` switches to the command window
imap ; <ESC>
## when the focus is in the source window, the following keys can be used
## they are easier to press compared with <F9> ...
map c :continue<CR>
map d :down<CR>
map f :finish<CR>
map s :step<CR>
map u :up<CR>
map v iinfo<Space>locals<CR><ESC>
With cgdb, my cursor mostly stay in the source window. I use d
u
f
c
a lot, when I need to eval something, I press i
to switch to the command window, enter p foo
, press Enter and then ;
to go back to the source window.
Do you have suggestions how I can duplicate the workflow with nvim-gdb? As you see, p foo
is a time-consuming process. The ideal approach is to stay in the source window, hit some shortcut to evaluate an identifier. cgdb/cgdb#141
By default the gdb window is in the terminal mode (-- TERMINAL --
). I know C-\ C-n
enters normal mode but it does not seem very convenient...
I think there are many others who don't like bindings. You may consider creating a wiki page describing how to bind these commonly used commands to single-letter keys.
When exit
is executed in the terminal windows, the debugger exits, but an error is issued.
Consider how the debugging session could be terminated too.
It seems that there isn't a plugin that support lldb for vim8 now.
Will you develop this to support vim8 ?
Hi,
a "ghost" buffer is created or kept after stopping gdb with GdbDebugStop or typing directly in the command line "q".
I hope it's easily fixable
If breakpoint is set with <f8>
, the sign is placed correctly.
If set with a CLI command, no sign is shown
Currently, the addresses are hardcoded to simplify testing with socat.
Make them random temporary files eventually to allow concurrent debugging sessions.
Python built-in debugger. Should be suitable for integration.
The goal is to keep the reference to the source code while debugging, to benefit from vim navigation when setting breakpoints.
If I'm in the source code and I press F8
, I will see a breakpoint appear on the line.
If I'm in lldb and I type breakpoint set --file file.c --line X
, I will not see the breakpoint appear on the line.
Will try to confirm on gdb as well when I can.
Btw, great plugin.
Consider the scenario:
<leader>dd
<f8>
:GdbDebugStop
The breakpoint marker stays on. Should be gone.
I love this minimal plugin, however LLDB is easier to get working on macOS, as GDB has some security complications. Would it be easily possible to support LLDB too?
Investigate how to use travis for testing in Darwin.
I noticed that the command to install the plugin in the readme is not correct, the pipe needs to be escaped with a leading backslash otherwise you get an error (At least it did for me).
The line:
Plug 'sakhnik/nvim-gdb', { 'do': ':!./install.sh | UpdateRemotePlugins' }
Should be replaced by:
Plug 'sakhnik/nvim-gdb', { 'do': ':!./install.sh \| UpdateRemotePlugins' }
I would have changed it myselve but I dont have much experience with git and all that I know is limited to git itself and not github.
Apparently, the state machine has a shortcoming with lldb. The last (lldb)
transits to the state paused
, and the sign is displayed. Maybe need to introduce one more state exited
.
Start debugging, close the source window manually. When :GdbDebugStop
is called, the plugin complains that cannot delete the last tab.
Ideally, a distinct sign would be used to distinguish between one/multiple breakpoints.
Ideally, a user should be able to run multiple debuggers independently. For that, tab-local variables could be used :help t:var
when installed in the beginning. i can debug and saw my code. and F6, F7 step in, out...
and then, after i changed my keymap. there is a E31 error message still happened, even I fallback every.
please help.
in my NeoVim RC
38 Plug 'sakhnik/nvim-gdb' , {'do': './install.sh' }
39
40 let g:nvimgdb_config_override = {
41 \ 'key_next': '',
42 \ 'key_step': '',
43 \ 'key_finish': '',
44 \ 'key_continue': '',
45 \ 'key_until': '',
46 \ 'key_breakpoint': '',}
47
48 let g:nvimgdb_disable_start_keymaps = 1
49 nnoremap dd :GdbStart gdb -q ../bin/iBetter
50 nnoremap ds :GdbDebugStop
Hey!
Your plugin looks pretty nice, I'm giving it a short for my rust code soon!
I noticed you're having quite a bit of dependencies on lua packages that you're installing via install.sh
. That's a bit of an uncomfortable situation, imho, and while I can't judge the necessity, I do want to point out to you this PR where we want to improve the developer's experience with lua, and provide functionality as a "lua stdlib". Maybe you want to chime in with your experience :)
info line
is called for gdb in the function nvimgdb#Interrupt()
. Check it works in lldb too.
Running GdbStart gdb produces the error:
Error detected while processing function nvimgdb#Spawn:
line 1:
E117: Unknown function: GdbInit
Haven't figured out how to properly debug vimscript/vim-running-python to know what the errors are doing, but this pops up:
Error detected while processing function <SNR>165_OnBufEnter[5]..<SNR>165_GdbPaused_info_breakpoints[27]..<SNR>165_InfoBreakpoints[5]..provider#python3#Call:
line 18:
error caught in request handler 'python_eval ["InfoBreakpoints('/Users/lanza/.dotfiles/dtf', '/var/folders/p5/2m9kg46x21q8h5f9p6tpft64rm_j69/T/nvimfAJWz1/2')"]':
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/neovim/plugin/script_host.py", line 166, in python_eval
return eval(expr, self.module.__dict__)
File "<string>", line 1, in <module>
File "/Users/lanza/Projects/nvim-gdb/lib/info_breakpoints.py", line 24, in InfoBreakpoints
data, addr = sock.recvfrom(65536)
Press ENTER or type command to continue
Error detected while processing function <SNR>165_OnBufEnter[5]..<SNR>165_GdbPaused_info_breakpoints[27]..<SNR>165_InfoBreakpoints[5]..provider#python3#Call:
line 18:
socket.timeout: timed out
Press ENTER or type command to continue
Error detected while processing function <SNR>165_OnBufEnter[5]..<SNR>165_GdbPaused_info_breakpoints[29]..<SNR>165_RefreshBreakpointSigns[2]..<SNR>165_SetBreakpointSigns:
line 6:
E715: Dictionary required
Press ENTER or type command to continue
Error detected while processing function <SNR>165_OnBufEnter[5]..<SNR>165_GdbPaused_info_breakpoints[29]..<SNR>165_RefreshBreakpointSigns[2]..<SNR>165_SetBreakpointSigns:
line 6:
E714: List required
Press ENTER or type command to continue
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.