Recent Posts

1

Development / Re: %I64d or %lld in the plugins\compilergcc\depslib\src\cache.c

« Last post by ollydbg on Yesterday at 02:27:42 pm »

Try the following:
      #if  (_USE_LONG_TIME_T)
         sscanf(buf, "%ld %n", &timeval, &n);
      #else
         #if defined(PRId64)
            sscanf(buf, "%" PRId64 " %n", &timeval, &n);
         #else
            sscanf(buf, "%lld %n", &timeval, &n);
         #endif
      #endif

and
      #if  (_USE_LONG_TIME_T)
         fprintf(f, "%ld %s\n", h->time, h->file);
      #else
         #if defined(PRId64)
            fprintf(f, "%" PRId64 " %s\n", h->time, h->file);
         #else
            fprintf(f, "%lld %s\n", h->time, h->file);
         #endif
      #endif

This works better than the existing code. Give it a quick hack/ try, but you may find a better way.

Hi, thanks, I just tested it. I think your suggested code is better than the current code. 

2

Using Code::Blocks / Re: Hiccups while typing (continuation)

« Last post by ollydbg on Yesterday at 03:09:40 am »

Any change made while no project is active gets written to .conf

I agree, this include the m_Options and the m_BrowserOptions.

When a project is loaded nothing has changed in .conf, so no write options need to be done.

I agree.

If changes are made to settings (OnApply is entered), the active parser that made the changes is recorded by OnApply().
Those changes are then written to the .conf, and only the settings made by that active project are written to the .conf.
all other projects read those settings.

I agree that the writing of m_Options to the configure file should only happens inside the OnApply() function.
When user tweak the Class browser GUI options, it should always to saved to configure file.

But, I think the last sentence ("all other projects read those settings") is not correct. When we switch the Parser, the other Parser should read the m_BrowserOptions, because this is a global setting.
But we don't need to "re-read" the m_Options from the configure file, because different Parsers may have different parsing options.

If no user setting are made via settings, no need to care about writing the .conf.

I agree.

3

Using Code::Blocks / Re: Hiccups while typing (continuation)

« Last post by ollydbg on Yesterday at 02:56:14 am »

I can't find a "Class browser's option. Where is that?
I can possible make those options "always write" if I could figure out where that is.

If you look at this function: void Parser::WriteOptions(), you will see that it actually save two member variables: one is the m_Options, and the other is the m_BrowserOptions.
In my mind, it looks like the "m_BrowserOptions" is shared by all the Parser instances. But the "m_Options" is not, so each Parser instance has its own "m_Options". So, switch the Parser won't switch the browser options, instead, it keep the browser options, but the "m_Options" need to be changed if different Parsers have different m_Options.

So, when a Parser is constructed, it first read the "m_BrowserOptions" and "m_Options" from the configure file, and later user can adjust its own options.

When we switch cbp in a workspace, one Parser get active, so its "m_Options" get active, at this time, the configure file is updated, I mean the active parser's "m_Options" is saved to the configure file.

But if you look at the function: void ClassBrowser::SetParser(ParserBase* parser), you will see:

Code

// ----------------------------------------------------------------------------
void ClassBrowser::SetParser(ParserBase* parser)
// ----------------------------------------------------------------------------
{
    if (m_Parser == parser)
        return;

    m_Parser = parser;
    if (m_Parser)
    {
        const int sel = XRCCTRL(*this, "cmbView", wxChoice)->GetSelection();
        BrowserDisplayFilter filter = static_cast<BrowserDisplayFilter>(sel);
        if (!m_ParseManager->IsParserPerWorkspace() && filter == bdfWorkspace)
            filter = bdfProject;

        m_Parser->ClassBrowserOptions().displayFilter = filter;
        m_Parser->WriteOptions();
        UpdateClassBrowserView();
    }
    else
        CCLogger::Get()->DebugLog("SetParser: No parser available.");
}

You see the "m_Parser->WriteOptions();" also get called.

So, maybe, it looks like we may need to call the "WriteClassBrowserOptions()" like function here inside the "void ClassBrowser::SetParser(ParserBase* parser)", because this class only response for the ClassBrowser related options.

4

Using Code::Blocks / Re: Hiccups while typing (continuation)

« Last post by Pecan on February 05, 2025, 06:57:53 pm »

I'm not fully understand the patch, it looks like all the Parser instance will share the same "option".

If you set a breakpoint(BP) in the file: parser.cpp, in the function body: void Parser::WriteOptions()

Then do something like below:

1, start C::B, this will hit the BP
2, when you open a project, the BP will hit again, at this time, "ReadOptions()" will be called, and returned without writing to the configure file.
3, when you change the classbrowser's option, from current "project" to "everything", the BP will hit again, and "ReadOptions()" will be called again, but still not write to the configure file.

From my point of view, this is not correct.

As Tim said, we should use "../xxxxx.h" include directive, thanks.

I can't find a "Class browser's option. Where is that?
I can possible make those options "always write" if I could figure out where that is.

As it is with the patch:
If no changes were ever made to settings, why should anything be written to the .conf?

The write to .conf takes place when a user changes an item in MainMenu>settings>CodeCompletion.

@parser.cpp void Parser::WriteOptions()
WriteOptions take place on CB startup but changes nothing because active parser is null and m_pOptsChangerProject is null.

Any change made while no project is active gets written to .conf

When a project is loaded nothing has changed in .conf, so no write options need to be done.

If changes are made to settings (OnApply is entered), the active parser that made the changes
is recorded by OnApply().
Those changes are then written to the .conf, and only the settings made by that
active project are written to the .conf. all other projects read those settings.

If no user setting are made via settings, no need to care about writing the .conf.]

Code

ActiveProject   OnAppy project  ActiveProject != OnApplyProject     action
--------------  --------------  -------------------------------    ----------
nullptr          nullptr        False,  will write                  .conf written at startup
nullptr          nullptr        False,  will write                  no projects,.option changed, .conf wrtten
Nullptr          Not null       Does not happen                     Can't happen, no project to record
Not null         nullptr        True,   no write                    no setting changed, no writes
Not null         not null       False,  will write                  option changed, .conf written
nullptr          nullptr        False,  will write                  project closed but no options change, no write
nullptr          not null       True,   no write                    project closed, .conf written for matching project

Writes to the .conf take place only when there is no project or when a project changes options.
when a project changes options, only that project is allow to write the .conf

5

Development / Re: new idea: ship the debug symbols in a separate file when we distribute C::B

« Last post by ollydbg on February 05, 2025, 12:44:57 pm »

Hi, I did some test on separating the debug information from the plugin dlls, and it works fine, with the help of LLM AI model, I create a Windows batch file named separate-debug-info.cmd file, it contents are below:

Code

@echo off
REM Use the directory of this batch file as the target directory.
set "TARGET_DIR=%~dp0"

REM Process all EXE files in the target directory.
for %%F in ("%TARGET_DIR%\*.exe") do (
    echo Processing %%F...
    objcopy --only-keep-debug "%%F" "%%~dpnF.debug"
    strip --strip-debug --strip-unneeded "%%F"
    objcopy --add-gnu-debuglink="%%~dpnF.debug" "%%F"
)

REM Process all DLL files in the target directory.
for %%F in ("%TARGET_DIR%\*.dll") do (
    echo Processing %%F...
    objcopy --only-keep-debug "%%F" "%%~dpnF.debug"
    strip --strip-debug --strip-unneeded "%%F"
    objcopy --add-gnu-debuglink="%%~dpnF.debug" "%%F"
)

echo Done.
pause

Now, put this .cmd file in the folder: <root>\src\devel32_64\share\CodeBlocks\plugins

And suppose you have the command line tools installed, for me, I have msys2's mingw64, and those tools were already installed.

After running this cmd file, you get such contents:

Code

# du -b --block-size=1K *
2056    abbreviations.debug
211     abbreviations.dll
4870    astyle.debug
547     astyle.dll
1097    autosave.debug
124     autosave.dll
1822    classwizard.debug
179     classwizard.dll
23896   codecompletion.debug
1619    codecompletion.dll
17193   compiler.debug
1092    compiler.dll
10200   debugger.debug
763     debugger.dll
2171    defaultmimehandler.debug
184     defaultmimehandler.dll
2931    OccurrencesHighlighting.debug
207     OccurrencesHighlighting.dll
1584    openfileslist.debug
133     openfileslist.dll
90669   org
5214    projectsimporter.debug
278     projectsimporter.dll
6434    scriptedwizard.debug
482     scriptedwizard.dll
1       separate-debug-info.cmd
4776    todo.debug
305     todo.dll
770     xpmanifest.debug
51      xpmanifest.dll

Note the fist column is the filesize in kilobyte unit.

When you run gdb on the debugee C::B, setting breakpoints on the dll source file still works, which means the separating of the debug information work.

6

Development / Re: How to globally set the "custom variables" in the cbp files under a workspace

« Last post by ollydbg on February 05, 2025, 09:47:19 am »

@Wkerry thanks, I see the gd's cbp file is a unified version for all windows versions and wx versions, this is also a great work! Why not put them to our SVN code base? Any devs opinion? 

GD's repo started a long time ago and there was a post in 2024. It makes life allot easier as you have indicated. See https://sourceforge.net/p/codeblocks/tickets/1332/ for an old patch that seems to have not been looked at.

That's great, thanks for the info, I think the devs should take some time to add his patch to the svn repo.

7

Using Code::Blocks / Re: Hiccups while typing (continuation)

« Last post by ollydbg on February 05, 2025, 09:42:56 am »

I'm not fully understand the patch, it looks like all the Parser instance will share the same "option".

If you set a breakpoint(BP) in the file: parser.cpp, in the function body: void Parser::WriteOptions()

Then do something like below:

1, start C::B, this will hit the BP
2, when you open a project, the BP will hit again, at this time, "ReadOptions()" will be called, and returned without writing to the configure file.
3, when you change the classbrowser's option, from current "project" to "everything", the BP will hit again, and "ReadOptions()" will be called again, but still not write to the configure file.

From my point of view, this is not correct.

As Tim said, we should use "../xxxxx.h" include directive, thanks.

8

Development / Re: How to globally set the "custom variables" in the cbp files under a workspace

« Last post by Wkerry on February 05, 2025, 09:15:01 am »

@Wkerry thanks, I see the gd's cbp file is a unified version for all windows versions and wx versions, this is also a great work! Why not put them to our SVN code base? Any devs opinion? 

GD's repo started a long time ago and there was a post in 2024. It makes life allot easier as you have indicated. See https://sourceforge.net/p/codeblocks/tickets/1332/ for an old patch that seems to have not been looked at.

9

Using Code::Blocks / Re: Hiccups while typing (continuation)

« Last post by Pecan on February 05, 2025, 06:37:57 am »

Code

#include "..\parsemanager.h"

My guess is the above line will fail under Linux.

Tim S.

Thanks

10

Using Code::Blocks / Re: Hiccups while typing (continuation)

« Last post by stahta01 on February 05, 2025, 04:48:06 am »

@ ollydbg

Would you try the following CC patch. It works well for me.

It simply remembers the project that applied an options change.
At WriteOptions() it only lets that project update the CC Options and .conf and makes the other projects refresh their cached options.

Patch is also attached to this msg.

Code

Index: ccoptionsdlg.cpp
===================================================================
--- ccoptionsdlg.cpp	(revision 13609)
+++ ccoptionsdlg.cpp	(working copy)
@@ -183,6 +183,10 @@
 
 void CCOptionsDlg::OnApply()
 {
+    //(ph 2025/02/04) // Set the project that changed the .conf data //(ph 2025/02/04)
+    cbProject* pProject = Manager::Get()->GetProjectManager()->GetActiveProject();
+    m_ParseManager->SetOptsChangerProject(pProject);
+
     ConfigManager* cfg = Manager::Get()->GetConfigManager(_T("code_completion"));
 
     // -----------------------------------------------------------------------
Index: parsemanager.h
===================================================================
--- parsemanager.h	(revision 13609)
+++ parsemanager.h	(working copy)
@@ -258,6 +258,9 @@
     void SetSymbolsWindowHasFocus(bool trueOrFalse){ m_SymbolsWindowHasFocus = trueOrFalse;}
     bool GetSymbolsWindowHasFocus(){return m_SymbolsWindowHasFocus;}
 
+    cbProject* GetOptsChangerProject(){ return m_pOptsChangerProject;} //(ph 2025/02/04)
+    void SetOptsChangerProject(cbProject* pProject){m_pOptsChangerProject = pProject;} //(ph 2025/02/04)
+
 protected:
     /** When a Parser is created, we need a full parsing stage including:
      * 1, parse the priority header files firstly.
@@ -527,6 +530,9 @@
     bool m_ClassBrowserViewIsStale = true;
     bool m_SymbolsWindowHasFocus = false;
 
+    //The last project to change the .conf file //(ph 2025/02/04)
+    cbProject* m_pOptsChangerProject = nullptr;
+
 };
 
 #endif // PARSEMANAGER_H
Index: parser/parser.cpp
===================================================================
--- parser/parser.cpp	(revision 13609)
+++ parser/parser.cpp	(working copy)
@@ -29,6 +29,7 @@
 
 #include <wx/tokenzr.h>
 #include <cbstyledtextctrl.h>
+#include "..\parsemanager.h" //(ph 2025/02/04)
 
 #include "parser.h"
 #include "parserthreadedtask.h"
@@ -921,6 +922,16 @@
 
 void Parser::WriteOptions()
 {
+    // If this project didn't change the options, then don't let it overwrite them. //(ph 2025/02/04)
+    cbProject* pActiveProject = Manager::Get()->GetProjectManager()->GetActiveProject();
+    ParseManager* pParseMgr = (ParseManager*)m_Parent;
+    cbProject* pOptsChangerProject = pParseMgr->GetOptsChangerProject();
+    if ( pActiveProject != pOptsChangerProject )
+    {
+        ReadOptions();  // force projects that did not change options to re-read them.
+        return;
+    }
+
     ConfigManager* cfg = Manager::Get()->GetConfigManager(_T("code_completion"));
 
     // Page "Code Completion"
Index: resources/manifest.xml
===================================================================
--- resources/manifest.xml	(revision 13609)
+++ resources/manifest.xml	(working copy)
@@ -3,7 +3,7 @@
     <SdkVersion major="1" minor="10" release="0" />
     <Plugin name="CodeCompletion">
         <Value title="Code completion" />
-        <Value version="1.0.5 24/01/29" />
+        <Value version="1.0.6(ph) 25/02/04" />
         <Value description="This plugin provides a symbols browser for your projects and code-completion inside the editor.
 
 

Code

#include "..\parsemanager.h"

My guess is the above line will fail under Linux.

Tim S.