Every time I enter neovim in windows 10 to a .js file I get this error:
Error detected while processing function SwitchFlowOrTsLsps[1]..CocAction:
line 2:
E605: Exception not caught: coc.nvim not ready when invoke CocAction "extensionStats"
In my configuration file is the function for which the error occurs:
function! SwitchFlowOrTsLsps(flowIndex)
silent let stats = CocAction("extensionStats")
silent let tsserver = get(filter(copy(stats), function('FindTsServer')), 0)
if(a:flowIndex == 0)
if(tsserver.state == 'disabled')
call CocActionAsync("toggleExtension", "coc-tsserver")
endif
else
if(tsserver.state == 'activated')
call CocActionAsync("toggleExtension", "coc-tsserver")
endif
endif
endfunction
Could someone help me? Although to tell me to delete the function, that function along with some more configurations I copied them from github and I don't understand it, I don't understand what it does.
It could even be a Coc error, that's how I see it but I'm not sure how to fix it, I have coc-json and coc-tsserver installed, if I need any more just say so.
Thank you all.
coc.nvim not ready when invoke
You need to make sure your coc.nvim has started already before invoke this action.
Related
I am deploying a web server, and after I finish compiling.There are the executing documents;
01client.c client epoll_server.c server
Then I try to run server
./server
There is an error which I cant fix it. I have search ways for solving but still can't fix it.
load error: No such file or directory
Maybe some one can help me,please!
Thanks a lot!!!!
System utilities print the program generating the error at the beginning of the line followed by other useful information such as the name of the missing file, so this is probably an error from a user program. I can duplicate the error as follows:
errno = 2;
perror("load error");
which prints:
load error: No such file or directory
Look for the perror line in the server code. If it isn't clear what file it can't find, print the string from the failed command it is reporting.
I'm trying to setup vim-jedi on neovim.
Whenever I open a python file and switch to Insert mode I get the following error:
Error detected while processing InsertEnter Autocommands for "<buffer=1>":
E117: Unknown function: jedi#remove_usages
I'm really new to (neo)vim so I'd really appreciate if could help me resolve this issue, thanks!
Below, I'm providing the information I think is relevant. Please let me know if you require me to provide anything else.
My setup
First I installed vim-jedi from pacman then I set my init.vim file to the following.
" My .nvimrc(init.vim) file
"
:set number relativenumber
:set termguicolors
" Plugins
call plug#begin()
" Solarized theme
let g:neosolarized_contrast = "normal"
set background=dark
Plug 'iCyMind/NeoSolarized'
" Python Completions via jedi
Plug 'davidhalter/jedi-vim', { 'for': 'python' }
call plug#end()
" Select Solarized as my theme.
colorscheme NeoSolarized
Afterwards I
Ran :PlugInstall
Restarted nvim
Ran :PlugUpdate
Restarted nvim and opened my file with nvim db.py.
The file I opened contains the following:
"""Database management functions"""
import tasks3.tasks3.db as db
def init(db_path: str):
engine = db.create_engine(db_path)
Base.metadata.create_all(bind=engine)
def purge(db_path: str):
engine = db.create_engine(db_path)
session = db.orm.sessionmaker(bind=engine)
def drop(db_path: str):
pass
To the best of my knowledge I don't have any additional scripts for nvim.
Additional Note (not sure if this is related)
In the context of the above purge function if type session. I get the following message:
-- Omni completion (^O^N^P) Pattern not found
I have Vim 8.0.1365 with Vlime plugin (065b95f) installed and an SBCL (1.2.11) session with the start-vlime.lisp loaded, running on macOS 10.14.6 (18G87).
When I connect from Vim using \cc, the SBCL session shows vlime-sbcl - New connection from #<AIO-SBCL:AIO-FD {10048DFD63} (so the connection works) but then the debugger is invoked with an SB-KERNEL:PARSE-UNKNOWN-TYPE condition signalled.
The debugger restarts are:
0: [REMOVE-FD-HANDLER] Remove #<SB-IMPL::HANDLER INPUT on descriptor 6: #<FUNCTION AIO-SBCL::SOCKET-INPUT-CB>>
1: [ABORT ] Exit debugger, returning to top level.
(VLIME-SBCL::SOCKET-ERROR-CB #<unavailable argument> #<SB-KERNEL:PARSE-UNKNOWN-TYPE {1004BE9B23}>)
I've tried both restart options. Removing the handler gives no response, and aborting returns SBCL to the * prompt.
The connection appears to exist in Vim (though there is no success message) and can be selected when using the \ss command (I tested on (+ 3 3)).
The SWANK window just displays a -- for each use of \ss and an error message below shows:
Error detected while processing function vlime#plugin#SendToREPL[100]..vlime#ui#input#MaybeInput[33]..<SNR>42_CheckInputValidity[2]..<SNR>32_SendToREPLInputComplete:
line 2:
E716: Key not present in Dictionary: ListenerEval, [a:content, function('s:OnListenerEvalComplete')]))
E116: Invalid arguments for function(a:conn.ListenerEval, [a:content, function('s:OnListenerEvalComplete')]))
E116: Invalid arguments for function vlime#WithThread
I don't have much experience with SBCL or Lisp - this is basically a hurdle at the starting line.
What does the first restart option mean?
The PARSE-UNKNOWN-TYPE condition seems uncommon from a Google search, and not at all in relation to Vlime. What are some next steps I can take to work this out?
(Posting the comment as an answer)
A common source of error when dealing with client/server protocols is a mismatch in versions for the different parts involved. The gihub page for vlime lists dependencies and supported implementations, I'd start from there.
Also, try starting sbcl in a standalone terminal (first install quicklisp, use "rlwrap sbcl" for readline support) and then load Swank manually:
(ql:quickload :swank)
Create a server
(swank:create-server :port 4005)
And connect to it, so you can still debug errors from the terminal if there are problems with the client/server interface.
I have always used erlang stdlib library zip:unzip/1 successfully. Last night i hit a bar with this error:
E:\WimaxStatsParser-1.1>erl
Eshell V5.9.2 (abort with ^G)
1> zip:unzip("e:/WimaxStatsParser-1.1/in/SomeZipFile.zip").
{error,bad_central_directory}
2>
Some one help explain the cause for this ? and how i get around it ?
ADDITIONS
I got some other error on another file: {error,bad_eocd}. Please explain this as well.
I am not able to reproduce your problem with the information you give. There are 2 functions that may send this error:
get_cd_loop/5 and get_name_extra_comment/4 in stdlib-1.18.2/src/zip.erl .
it should be easy to debug
copy the file zip.erl, zip.hrl, file.hrl in a working directory,
compile with debug_info option, you will get the error message "Can't load module that resides in sticky dir", leave the VM
copy zip.beam in the stdlib.../ebin
restart the VM in the working directory, you can now add breakpoint in the zip.erl source.
BR
Pascal.
I want load resources from c++ code. And try repeat this way. But when i try build it, i get:
E:\Android\Samples\android-ndk-assets\project>e:\Android\android-ndk-r8b\ndk-build
Gdbserver : [arm-linux-androideabi-4.6] libs/armeabi/gdbserver
Gdbsetup : libs/armeabi/gdb.setup
"Compile thumb : png <= pngrtran.c
jni/libpng/pngrtran.c: In function 'png_do_expand':
jni/libpng/pngrtran.c:3790:1: internal compiler error: in reload, at reload1.c:1061
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: *** [obj/local/armeabi/objs-debug/png/pngrtran.o] Error 1
I just ran into this problem as well. Another workaround is to build the library as ARM code instead of Thumb code by adding the following line to your makefile:
LOCAL_ARM_MODE := arm
There should be no problem using ARM mode... ARM instructions require twice the space of Thumb instructions but are also much more sophisticated and capable of accomplishing a lot more in a single instruction, so depending on the cleverness of the compiler the resultant code may be bigger or smaller as well as more efficient or less efficient, but should execute with the same results.
I had the same error in android-ndk-r8b.
Looks like the bug in GCC. Do you submit bug report already?
I found the code which make error:
if (*(sp - 5) == red_high &&
*(sp - 4) == red_low &&
*(sp - 3) == green_high && //this line make error
*(sp - 2) == green_low && //this line make error
*(sp - 1) == blue_high &&
*(sp ) == blue_low)
{
*dp-- = 0;
*dp-- = 0;
}
I have a similar error in android-ndk-r8b as well. It occurs when calling ndk-build with the NDK_DEBUG flag set:
ndk-build NDK_DEBUG=1 <--- error
Try setting the NDK_BUILD flag to 0. It should compile. Of course it won't be debuggable :(
ndk-build NDK_DEBUG=0 <--- no error