Happy New Year

[gd_on]

I wish an happy new coding year with CodeBlocks (of course  ) to all developpers and users

[BlueHazzard]

Also from my side, a happy new year...

[Pecan]

And wishing a healthy New Year too.

I'm very happy today, I finally got CB-clangd_client working on Linux. So it's already started 'happy' for me !!
Boy... what a chore.

[BlueHazzard]

And wishing a healthy New Year too.

I'm very happy today, I finally got CB-clangd_client working on Linux. So it's already started 'happy' for me !!
Boy... what a chore.

Is it this?
https://sourceforge.net/p/cb-clangd-client/code/HEAD/tree/

some more information on this?
(i am thrilled)

[killerbot]

does this already work in CB ?
or at least already some part ?
let's add this plug-in to our nightly builds then ? or only linux ? either way, the sooner the better , anywhere : win/ linux ;-)

[ollydbg]

Hi, everyone, happy new year!

@Pecan, good work!

I would like to try this plugin if you release it.
Is it this?
https://sourceforge.net/p/cb-clangd-client/code/HEAD/tree/

[AndrewCot]

Happy new year and best wishes.

@pecan excellent work.

I have integrated the code into my unofficial installer and uploaded the installer to SF (https://sourceforge.net/projects/unofficial-cb-installers/). I have only tested that I can configure and it runs like the existing code completion plugin.

The changes I had to do were:
1. Fix compiler errors in client.cpp that did not include the wc_str() to convert wxString for use by std::fstream
2. I included the SF src at the C::B src\plugin level like the codecompletion is in a new directory (\src\plugins\clangd_client)
4. Created a new ClangdClient_wx31_64.cpb project and updated it for my local build process and updated the cbp so it does not use the zipResources.bat
5. Updated the main workspace to reference the new ClangdClient_wx31_64.cpb file
6. Updated the NSIS installer to add the plugin

Changes that still need to be done that I spotted are:
1) Fix compiler warning (I used GCC 11.2)
2) Add support for building under Linux, Mac and Windows x86.
3) Either keep this as a separate plugin or incorporate it into the core plugin set. (My quick integration is a half way house as in it is a separate plugin, but not in the contrib directory)
4) Add plugin files to the Debain, Mac and windows installer scripts/process.
5) Test installers works and the plugin works after installing using installer
6) Two potential bugs I spotted while the codecompletion plugin is still supported:
     a) You can enable the code completion plugin after the clangd_client is enabled.
     b) If you disable the clangd_client and enable the codecompletion then C::B crashes if you try to open the Settings->editor sub menu
   If this plugin is to replace the codecompletion plugin then we could live with these until the codecompletion plugin is retired.
7) The clangd_client.dll is 39MB.... Need to check out why it is so big.

The following is what is needed to get the plugin working with MSYS2:
1) Install MSYS 2  clang packages:
    pacman -S mingw-w64-clang-x86_64-toolchain
2) Configure for use:
    a) In the Settings->editor select Clangd_Client settings.
    b)  In the C/C++ parser tab change the LLVM directory to the following or where you have the clangd.exe installed):
            C:\msys64\clang64\bin

[Pecan]

Wow !! Thanks guys. Didn't expect such enthusiasm. :>)

That plugin @ https://sourceforge.net/p/cb-clangd-client/code/HEAD/tree/ is an early version I used before adding Linux support. I now have it working on both windows and linux. I'll upload that to SourceForge this week as soon as (I remove all my asm("int3") traps and) re-testing on both systems.

@ AndrewCot : thanks for all the suggestions. I'll get to work on 'em.

[killerbot]

I would make a core plugin out of it, because code completion is a big feature most developers really want to be excellent.
Out existing code completion is already for years, let's be honest, old crap :-(
It fell behind the moment c++11 was introduced.
And I think it is a main reason for people to choose eclipse or vscode.

[AndrewCot]

@Pecan
I have made some more changes in order to add the plugin to the core and as such here is some more feedback:
1) I updated to use -std=gnu++17 in the CodeBlocks_wx31_64.cbp project file as the code does not build with C++11.
2) The client.cpp does not build with the -DCB_PRECOMP compiler option. I had to add the following block and then it successfully built:
#include "sdk_precomp.h"

#ifndef CB_PRECOMP
   ..... existing WX and CB header files
#endif


@all
Are there any known issues with moving to C++17 to build C::B?

[AndrewCot]

@pecan
It appears that processing the files is slow as per the logged info shown below:

Opening D:\Andrew_Development\WorkingOnThese\AC-WindowsInstaller\src\CodeBlocks_wx31_64.cbp
Done.
cbProject::Open took: 0.725 seconds.
ProjectManager::SetProject took: 1.686 seconds.
ProjectManager::LoadProject took: 2.732 seconds.
ParseManager::CreateParser: Finish creating a new parser for project 'Code::Blocks wx3.1.x (64 bit)'
LSP opened editor parse finished for D:\Andrew_Development\WorkingOnThese\AC-WindowsInstaller\src\plugins\clangd_client\src\LSPclient\include\protocol.h (1441 ms) (496 more)
LSP opened editor parse finished for D:\Andrew_Development\WorkingOnThese\AC-WindowsInstaller\src\plugins\clangd_client\src\codecompletion\parser\LSP_tokenizer.h (3194 ms) (495 more)
LSP opened editor parse finished for D:\Andrew_Development\WorkingOnThese\AC-WindowsInstaller\src\plugins\clangd_client\src\codecompletion\codecompletion.cpp (4342 ms) (494 more)
LSP opened editor parse finished for D:\Andrew_Development\WorkingOnThese\AC-WindowsInstaller\src\plugins\clangd_client\src\LSPclient\include\client.cpp (3738 ms) (493 more)
LSP opened editor parse finished for D:\Andrew_Development\WorkingOnThese\AC-WindowsInstaller\src\include\compilerfactory.h (660 ms) (492 more)
LSP opened editor parse finished for D:\Andrew_Development\WorkingOnThese\AC-WindowsInstaller\src\plugins\clangd_client\src\asyncprocess\asyncprocess.cpp (2228 ms) (491 more)
LSP opened editor parse finished for D:\Andrew_Development\WorkingOnThese\AC-WindowsInstaller\src\sdk\configmanager-revision.cpp (3543 ms) (490 more)
LSP opened editor parse finished for D:\Andrew_Development\WorkingOnThese\AC-WindowsInstaller\src\sdk\cygwin.cpp (3534 ms) (489 more)
LSP background parsing finished for: D:\Andrew_Development\WorkingOnThese\AC-WindowsInstaller\src\src\environmentsettingsdlg.cpp (3262 ms) (488 more)

Is there a way of speeding this up? Any ideas on where to look or what to check or do?
I am using MSYS2 with the latest updates as of a few hours ago (this resulted in waht looked like a big MinGW 64 9.00 run time update) and GCC 11.2.0.

[Pecan]

@ AndrewCot

I've replied at https://forums.codeblocks.org/index.php/topic,24357.msg169048.html#msg169048

[killerbot]

one of the reasons obfuscated was conservative of the c++ standard was, that it could no longer be build on centos. centos typically comes half a decade or more behind of compiler support or whatever other package support (ignoring here the reasons).

Personally I agree with stepping up the compiler standard requirement, we are already on c++20, so we are still conservative ;-)

If this is what it takes to get back in the game for code completion, let's try it out.

[killerbot]

well does it also provide code completion , or is it just continuously compiling as you type and telling you already if you have errors ?

[Pecan]

well does it also provide code completion , or is it just continuously compiling as you type and telling you already if you have errors ?

clangd_client was built to start providing any feature that was provided in the older CodeCompletion within ~3 seconds (or just after clangd returns from indexing the active editor). The active editor is the first file handed to clangd when a project is loaded.

It does not matter if clangd does not complete all the inactive editors. They just chug along being parsed in the background to provide info to the symbols window.

The order files are handed to clangd are:
   1) The active editor
   2) All the other editor
   3) The most recently modified files (not in an editor)
   4) All other unmodified files (not in an editor)

When a file is activated in an editor, it goes to the front of the line.

Works well for me. Is there any problem with this?
If so, it needs to be fixed. I can do that. (I think) :>)