Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Code completion using LSP and clangd
ollydbg:
--- Quote from: Pecan on October 14, 2022, 10:27:38 pm ---@ olldbg RE: Reply #218 on: October 11, 2022, 02:44:26
Thanks, it works for me.
Will be in rev 85.
--- Code: ---// ----------------------------------------------------------------------------
void ProcessLanguageClient::writeClientLog(const std::string& logmsg)
// ----------------------------------------------------------------------------
{
if (not lspClientLogFile.IsOpened()) return;
std::string logcr = "";
if (not StdString_EndsWith(logmsg, "\n"))
logcr = "\n";
std::string out = "\n" + GetTime_in_HH_MM_SS_MMM() + " " + logmsg + logcr;
lspClientLogFile.Write(out.c_str(), out.size());
lspClientLogFile.Flush();
}
// ----------------------------------------------------------------------------
void ProcessLanguageClient::writeServerLog(const std::string& logmsg)
// ----------------------------------------------------------------------------
{
if (not lspServerLogFile.IsOpened()) return;
lspServerLogFile.Write(logmsg.c_str(), logmsg.size());
lspServerLogFile.Flush();
--- End code ---
--- End quote ---
Good work, this should the correct fix.
ollydbg:
Hi, I'm building clangd_client rev84 with the latest C::B rev 12976.
Do I need to change the line to this:
--- Code: ---// ----------------------------------------------------------------------------
void ClgdCompletion::OnCompilerStarted(CodeBlocksEvent& event)
// ----------------------------------------------------------------------------
{
//If this is a idCompileMenuRun only, do not set compiler is running
// else we'll hang before nightly rev 12975 fix
//#warning Developer should remove this condition after nightly for CB rev 12975
//if (ns_CompilerEventId == XRCID("idCompilerMenuRun")) return;
GetParseManager()->SetCompilerIsRunning(true);
}
--- End code ---
I have to comment out the line
--- Code: --- //if (ns_CompilerEventId == XRCID("idCompilerMenuRun")) return;
--- End code ---
Am I correct?
Pecan:
--- Quote from: ollydbg on October 15, 2022, 05:47:11 am ---Hi, I'm building clangd_client rev84 with the latest C::B rev 12976.
Do I need to change the line to this:
--- Code: ---// ----------------------------------------------------------------------------
void ClgdCompletion::OnCompilerStarted(CodeBlocksEvent& event)
// ----------------------------------------------------------------------------
{
//If this is a idCompileMenuRun only, do not set compiler is running
// else we'll hang before nightly rev 12975 fix
//#warning Developer should remove this condition after nightly for CB rev 12975
//if (ns_CompilerEventId == XRCID("idCompilerMenuRun")) return;
GetParseManager()->SetCompilerIsRunning(true);
}
--- End code ---
I have to comment out the line
--- Code: --- //if (ns_CompilerEventId == XRCID("idCompilerMenuRun")) return;
--- End code ---
Am I correct?
--- End quote ---
You are correct. That fix is not needed with CB rev 12975 and above.
Thanks for testing.
MaxGaspa:
--- Quote from: Pecan on October 14, 2022, 09:45:18 pm ---
I've made a temporary fix (until the next Nightly) that circumvents the missing event.
Be careful though, the circumvention allows clangd to parse files while the "Run" command is active. You might want to right-click on the project name and "Pause parsing(toggle)" before running your program from the menu run command.
After the "Run" finishes, you can "Pause parsing(toggle)" again to continue parsing where it left off.
--- End quote ---
@pecan
At the moment I'm unable to replicate the bug, so the bug seems fixed.
Is there any inconvenience leaving the parser working while I'm running the application? I mean not considering the CPU usage?
Max
ollydbg:
Hi, Pecan, In the latested r84 and with the change to using the std::string output of the both function writeClientLog() and writeServerLog().
I found an interesting thing that I got two different encoding output of the Chinese text in the comments.
One place is here, in the function: bool ProcessLanguageClient::WriteHdr(const std::string &in)
I see that the output of the content(usually the textDocument/didOpen message's content the client try to send to the LSP server) will be in GB2312 in my PC.
While, the content received from the server(usually the textDocument/hover message return from the LSP server) will be in UTF8 format.
I just exam the function body: bool ProcessLanguageClient::WriteHdr(), I see it still use the some kinds of std::string to wxString, and later some wxString to std::string, some conversion will use the default local encoding.
For example:
--- Code: ---limitedLogOut = wxString::Format("<<< Write():\n%s", wxString(in)).Mid(0,512) + "<...DATA SNIPED BY LOG WRITE()...>";
--- End code ---
The variable in to wxString will use wrong encoding.
So, what I think is that we should use std::string inside the WriteHdr().
Even I see there is a function call:
--- Code: --- // Write raw data to clangd server
#if defined(_WIN32)
bool ok = m_pServerProcess->WriteRaw( out ); //windows
if (not ok)
{
writeClientLog("Error: WriteHdr() failed WriteRaw()");
return false;
}
#else
// unix just posts the msg to an output thread queue, so no return code.
m_pServerProcess->Write( fileUtils.ToStdString(out) ); //unix
#endif
--- End code ---
I think the content sent to the pipe is still in UTF8 encoding. (I just checked the code in src\winprocess\asyncprocess\winprocess_impl.cpp.
--- Code: ---bool WinProcessImpl::Write(const std::string& buff) { return WriteRaw(buff + "\r\n"); }
bool WinProcessImpl::WriteRaw(const wxString& buff) { return WriteRaw(FileUtils::ToStdString(buff)); }
bool WinProcessImpl::WriteRaw(const std::string& buff)
{
// Sanity
if(!IsRedirect()) {
return false;
}
m_writerThread->Write(buff);
return true;
}
--- End code ---
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version