Recent Posts

Pages: [1] 2 3 4 5 6 ... 10
1
Plugins development / Re: Code completion using LSP and clangd
« Last post by ollydbg on Today at 03:14:55 am »
This is a code format fix:

Code
 clangd_client/src/LSPclient/src/client.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/clangd_client/src/LSPclient/src/client.cpp b/clangd_client/src/LSPclient/src/client.cpp
index fadcb51..459b809 100644
--- a/clangd_client/src/LSPclient/src/client.cpp
+++ b/clangd_client/src/LSPclient/src/client.cpp
@@ -702,9 +702,9 @@ void ProcessLanguageClient::OnLSP_Terminated(wxThreadEvent& event_pipedprocess_t
     wxCommandEvent terminatedEvt(wxEVT_COMMAND_MENU_SELECTED, XRCID("idLSP_Process_Terminated"));
     terminatedEvt.SetEventObject((wxObject*)m_pCBProject);
     terminatedEvt.SetInt(processExitCode);
-    Manager::Get()->GetAppFrame()->GetEventHandler()->ProcessEvent(terminatedEvt)
+    Manager::Get()->GetAppFrame()->GetEventHandler()->ProcessEvent(terminatedEvt);
 
-;    if (processExitCode != 0)
+    if (processExitCode != 0)
     {
         wxString msg = "Unusual termination of LanguageProcessClient(LSP) occured.";
         if (lspClientLogFile.IsOpened() )
2
Plugins development / Re: Code completion using LSP and clangd
« Last post by ollydbg on Today at 03:07:08 am »
@ ollydbg

This change didn't work for me. (Message #69)

I want the codepoint. I don't get any asserts.

With "wxUniChar uniChar(invChar);" I get:
Code
Error: Removed clangd response invalid utf8 char:position(3665), hex(85), U(2026), <cant post> ResponseID:textDocument/completion
Note that I get the codepoint U(2026) back.

With "wxUniChar uniChar(unsigned int(invChar));" I get:

Code
Error: Removed clangd response invalid utf8 char:position(6899), hex(85), U(85), ,<cant post on sf>. ResponseID:textDocument/completion
Here I get only the hex value.

So I changed the wxString::Format to:
Code
msg += wxString::Format("position(%d), hex(%02hhX), U(%x), \'%s\'", invloc, (unsigned int)invChar, (int)uniChar.GetValue(), invStr );
Note the "(int)uniChar.GetValue()"

I'm using wx3.1.5 on windows and wx3.0 on linux.
Works with no asserts.
Does it work for you

In my computer, it works differently than yours.

I did a simple test:

Code
    unsigned char invChar = 0x83;
    wxUniChar uniChar(invChar);

    wxString msg = wxString::Format("hex(%02hhX), U(%x)", (unsigned int)invChar, uniChar.GetValue());

    wxLogMessage(msg);

With the above code, the program just pop up an alert (see screen shot in attachment)

While, with below code, it works OK without the alert.

Code
    unsigned char invChar = 0x83;
    wxUniChar uniChar((unsigned int)invChar);

    wxString msg = wxString::Format("hex(%02hhX), U(%x)", (unsigned int)invChar, uniChar.GetValue());

    wxLogMessage(msg);

Please note that "Create a character from the 8-bit character value c using the current locale encoding.", which means in my locale encoding, a 0x83 is not a valid Unicode code point, I mean maybe we need two bytes or three bytes to convert it to a Unicode code point.

I'm not sure why in your test case, a 0x83 will becomes a larger value code point U(2026). Maybe, you have different locale encoding as mine. I'm on Windows 7 64bit Chinese language edition, so my local encoding maybe some Chinese language.



Quote
Note: it took me 45 minutes to post this. Don't try and post a msg with an invalid utf8 char.  It's a PITA
I also meet this kind of forum error from time to time. So bad.
3
Plugins development / Re: Code completion using LSP and clangd
« Last post by ollydbg on Today at 02:08:15 am »
The plugin spec says they need to be the same. I cannot remember which OS or if it was the plugin, but case differences have caused me problems. I missed this one when comparing CodeBlocks_wx31_64.cbp and clangd_client_wx31_64.cbp changes for the plugin as my CodeBlocks_wx31_64.cbp has the following line for the output:

                <Option output="devel31_64/share/CodeBlocks/plugins/clangd_client" prefix_auto="1" extension_auto="1" />

For generated files, I prefer the lower case file name format. Since you have the commit right to the svn repo, can you fix them?

BTW:

The custom variables in build options can be improved from my point of view:

1,  I see "TARGET_DEVEL_DIR_AC" and "TARGET_DEVEL_DIR_PECAN" and "TARGET_DEVEL_DIR" in custom variables. Can we just keep only one variable? I mean we can use a "global variable" in the Menu->Settings->Global variables. This way, we can set those variables by our own setting.

2, the name TARGET_DEVEL_DIR is not correct here. I think "DEVEL_DIR" mainly refer to a folder named "devel31_64" which store the built exe or dlls. So, a better name could be "CB_SOURCE_ROOT" which refer the the root of the svn/git source code root folder.

4
Plugins development / Re: Code completion using LSP and clangd
« Last post by Pecan on Yesterday at 11:46:27 pm »
@ ollydbg

This change didn't work for me. (Message #69)

I want the codepoint. I don't get any asserts.

With "wxUniChar uniChar(invChar);" I get:
Code
Error: Removed clangd response invalid utf8 char:position(3665), hex(85), U(2026), <cant post> ResponseID:textDocument/completion
Note that I get the codepoint U(2026) back.

With "wxUniChar uniChar(unsigned int(invChar));" I get:

Code
Error: Removed clangd response invalid utf8 char:position(6899), hex(85), U(85), ,<cant post on sf>. ResponseID:textDocument/completion
Here I get only the hex value.

So I changed the wxString::Format to:
Code
msg += wxString::Format("position(%d), hex(%02hhX), U(%x), \'%s\'", invloc, (unsigned int)invChar, (int)uniChar.GetValue(), invStr );
Note the "(int)uniChar.GetValue()"

I'm using wx3.1.5 on windows and wx3.0 on linux.
Works with no asserts.
Does it work for you

Note: it took me 45 minutes to post this. Don't try and post a msg with an invalid utf8 char.  It's a PITA
5
Plugins development / Re: Code completion using LSP and clangd
« Last post by AndrewCot on Yesterday at 10:43:26 pm »
The plugin spec says they need to be the same. I cannot remember which OS or if it was the plugin, but case differences have caused me problems. I missed this one when comparing CodeBlocks_wx31_64.cbp and clangd_client_wx31_64.cbp changes for the plugin as my CodeBlocks_wx31_64.cbp has the following line for the output:

                <Option output="devel31_64/share/CodeBlocks/plugins/clangd_client" prefix_auto="1" extension_auto="1" />

6
Nightly builds / Re: The 16 Januari 2022 build (12655) is out.
« Last post by BlueHazzard on Yesterday at 10:05:36 pm »
Thank you a lot for testing.

I hopefully have fixed the found bugs in svn now.

I am not 100% sure if dragging tree items works on mac, because i have seen some code that uses an #ifdef for mac for tree internal drag and drop, but this code was older then the last DnD rework in wx.
7
Plugins development / Re: Code completion using LSP and clangd
« Last post by Pecan on Yesterday at 09:59:29 pm »
CB Clangd Client / Code / Commit [r32]

Please note that in this revision.
I'm using the Windows clangd_client_wx31_64.cbp
The generated dll file name is:  Clangd_Client.dll
And the zip file name is: clangd_client.zip

Do you think the name should be the same? I mean to keep the case consistent.

I do, but others did not. Wasn't worth quibbling about to me.

Thanks for the wxUniChar fix.
8
Development / Bug in AddMultipleFilesToProject
« Last post by BlueHazzard on Yesterday at 09:55:14 pm »
Code
int ProjectManager::AddMultipleFilesToProject(const wxArrayString& filelist, cbProject* project, int target)
{
    if (!project)
        project = GetActiveProject();

    wxArrayInt targets;
    targets.Add(target);
    if (AddMultipleFilesToProject(filelist, project, targets) == 1)
        return targets[0];
    return -1;
}

The documentation says, that in this function, if the parameter target == -1 then the user gets asked for the targets to add...
Now, AddMultipleFilesToProject calls DoAddFiles
Code
nt ProjectManager::DoAddFileToProject(const wxString& filename, cbProject* project, wxArrayInt& targets)
{
    if (!project)
        return 0;

    if (!SetupTargets(targets, project, m_ui))
        return 0;

And do add files calls setupTargets

Setup targets checks if the targets array is empty and if so, asks the user for the targets...
In our case the array is not empty, but filled with -1 so the documentation is wrong
Code
bool SetupTargets(wxArrayInt &targets, cbProject *project, cbProjectManagerUI *ui)
{
    cbAssert(project);
    cbAssert(ui);

    // do we have to ask for target?
    if (targets.GetCount() == 0)
    {

Or am i missing something?
9
Plugins development / Re: Code completion using LSP and clangd
« Last post by ollydbg on Yesterday at 03:58:56 pm »
I see an alert from this code snippet, and here is the fix:

Code
 clangd_client/src/LSPclient/src/client.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/clangd_client/src/LSPclient/src/client.cpp b/clangd_client/src/LSPclient/src/client.cpp
index 459b809..e03730d 100644
--- a/clangd_client/src/LSPclient/src/client.cpp
+++ b/clangd_client/src/LSPclient/src/client.cpp
@@ -1073,7 +1073,7 @@ bool ProcessLanguageClient::DoValidateUTF8data(std::string& data)
             std::string invStr(&data[invloc], 1);
             //unsigned int invInt = (unsigned int)data[invloc];
             unsigned char invChar(invStr[0]);
-            wxUniChar uniChar(invChar);
+            wxUniChar uniChar((unsigned int)invChar);
 
             // clangd response:
             // {"id":"textDocument/completion","jsonrpc":"2.0","result":{


When debugging, I see that the "invChar" is 161(dec), and it cause the alert from wx.
So, we have to first convert to "unsigned int".

See the document from: wxWidgets: wxUniChar Class Reference


Quote
wxUniChar::wxUniChar    (    unsigned char     c   )    

Create a character from the 8-bit character value c using the current locale encoding.
10
Nightly builds / Re: The 22 January 2022 build (12672) is out.
« Last post by eckard_klotz on Yesterday at 01:46:41 pm »
Hello Miguel Gimenez.

Quote
@eckard_klotz: Works here with the last version, have you tried after restoring the configuration?.
Quote
Please restore your compiler toolchain configuration (with the global variables) and check if it works.

The question is what do you understand as "restoring the configuration" ?

When I read that it is working for you I tried it again and yes you are right it was working as wanted:
  • The revision 12672 has not started the "Compilers Auto Detection" dialogue
  • The compiler settings contain all global variables as configured manually.

The reconstruction was done based on the conf-file left by the  revision 12672 yesterday.
  • I have just replaced the literal information by the global variables.

Now I wondered what I have done wrongly yesterday
  • I repeated step by step what I have done but with a different conf-file I have not used since August 2021.
  • Furthermore please notice, that I have used until yesterday the revision 12516 from August the 15th 2021.
  • Attached you will find a ZIP-file with screen shots and conf-files I mention in the description below.

  • I started Code::Blocks revision 12516 with the configuration "MinGW_9_2_0_64bit_TDM_Original.conf"
    • No "Compilers Auto Detection" dialogue occurred.
    • The configuration of the "Compiler Toolchain Executables" contained global variables ("CB_12516_compiler_toolchain_executables.png").
    • After closing Code::Blocks the file "MinGW_9_2_0_64bit_TDM_ref12516.conf" was stored.
  • Now I started Code::Blocks revision 12672 with the conf-file stored by the revision 12516 "MinGW_9_2_0_64bit_TDM_ref12516.conf".
    • The "Compilers Auto Detection" dialogue occurred.
    • The configuration of the "Compiler Toolchain Executables" contained not all global variables as desired but a lot of literal configurations ("CB_12762_compiler_toolchain_executables.png").
    • After closing Code::Blocks the file "MinGW_9_2_0_64bit_TDM_ref12762.conf" was stored.
    • Please notice, that this file is 3 kb larger than the original one.
  • Now I have corrected the content of the new conf-file by reconstructing the gcc configuration as present in the original conf-file.
    • I left anything else as stored by the revision 12762.
  • At the end I started Code::Blocks revision 12762 with the corrected configuration "MinGW_9_2_0_64bit_TDM_ref12672_Corrected.conf."
    • No "Compilers Auto Detection" dialogue occurred.
    • The configuration of the "Compiler Toolchain Executables" contained global variables as desired.

OK, after a manual correction of the configurations overwritten by Code::Blocks it is keeping the global variables again.
  • For a single user this may be a workaround.
  • But the user has to check every single configuration he has done in the past to ensure not to oversee a hidden modification.
  • Furthermore, this has to be done with every revision change since the user could not know when the conf-file format was changed.

I know where the conf-files are located on my computer:
  • C:\Users\[USER_NAME]\AppData\Roaming\CodeBlocks
  • Thus I have the chance to store the conf-files before changing the Code::Blocks revision to compare it later with the conf-files stored by the new revision
  • But how many Code::Blocks users are realy able to do the same


Best regards,
                    Eckard Klotz.
Pages: [1] 2 3 4 5 6 ... 10