Recent Posts

1

Nightly builds / Re: The 14 June 2024 build (13529) is out.

« Last post by Elena on Yesterday at 11:10:15 pm »

Hi, thanks for your support. Since at present I am not equipped to compile C::B I will surely test once the new NB binary is ready (it seems there haven't been any new NB since December btw)

2

Nightly builds / Re: The 14 June 2024 build (13529) is out.

« Last post by Pecan on Yesterday at 10:57:57 pm »

Hi, I hope this message will be noticed. I did not open a new topic because it is definitely related to build 13529 and over.

I also have experienced major slowdowns since b13529.
What I wanted to point out is that the culprit was indeed Browse Tracker, I disabled it and now everything is fine as before.
At the moment of writing this, current NB is 13600 and the problem is *still present*. Therefore, I simply have to keep the plugin disabled. Hope this helps.
Therefore, please consider fixing the plugin, which is causing major slowdowns since b13529

Thx

Fixed svn 13612.

The actual slowdown culprit was CodeCompletion  (CC) "Parse while typing" setting. However when the user disabled settings while a project was loaded, CC clobbered the settings back to the older condition as the project was closed.

Although the fix preserves the users settings in the .conf (global settings) the user will still have to re-parse the projects/files in order to apply the changed CodeCompletion global settings to the projects or files.

The easiest way to do that is to close and reopen the workspace or right-click on a project in the workspace tree and select 'Reparse this project'.

3

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

« Last post by Pecan on Yesterday at 10:48:36 pm »

@ ollydbg

Thanks for all your help and excellent guidance.
I decided to break the changes up into two tasks.

I've committed what we have. (svn 13612) and will continue with your further suggestions.
But after I study CC some more and get more confident about your suggestions.



Thanks,

4

Using Code::Blocks / Re: Strange behavior in xterm

« Last post by perosoft on Yesterday at 03:56:28 pm »

Prior to archlinux, i have kubuntu.
All work with no problems.
This problem apear on arch linux
And yes, system("/usr/local/texlive/2024/bin/x86_64-linux/latex");, working.
Thank you !

5

Using Code::Blocks / Re: Strange behavior in xterm

« Last post by Михаил Агарков on Yesterday at 10:28:14 am »

You need to do system("/usr/local/texlive/2024/bin/x86_64-linux/latex");
instead or install latex in /usr/bin/ for it to work AFAIK.

6

Using Code::Blocks / Re: Strange behavior in xterm

« Last post by perosoft on Yesterday at 05:02:12 am »

This is pdfTeX, Version 3.141592653-2.6-1.40.26 (TeX Live 2024) (preloaded format=latex)
 restricted \write18 enabled.

which latex
/usr/local/texlive/2024/bin/x86_64-linux/latex

user .bashrc

cat .bashrc
#
# ~/.bashrc
#

# If not running interactively, don't do anything
[[ $- != *i* ]] && return

alias ls='ls --color=auto'
alias grep='grep --color=auto'
PS1='[\u@\h \W]\$ '

export PATH="/usr/local/texlive/2024/bin/x86_64-linux:$PATH"

7

Using Code::Blocks / Re: Strange behavior in xterm

« Last post by stahta01 on February 14, 2025, 05:47:05 pm »

Posting the result of below from the system shell might help

Code

which latex

8

Using Code::Blocks / Strange behavior in xterm

« Last post by perosoft on February 14, 2025, 09:44:16 am »

Hi,

Using codeblocks with gcc compiler, linux.
When i run program in codeblocks, xterm appear.
In source i have a system call: system("latex");
Result is: sh: line 1: latex: command not found.
But if i simple launch xterm latex is found.
Launching xterm by codeblocks does not find latex.

If i launch codeblocks from console all is fine xterm find latex
Details
Host: arch Kernel: 6.13.2-arch1-1 arch: x86_64 bits: 64 compiler: gcc v: 14.2.1
Desktop: KDE Plasma v: 6.3.0 Distro: Arch Linux

Sugestions, please !

9

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

« Last post by ollydbg on February 14, 2025, 03:50:37 am »

If a parser only reads the settings at parser creation time, when the user later changes the global settings but the parser is not allowed to read them after the change, the user now is parsing without the settings he/she requested.

If that user was me, I'd call that a bug.

My initial thought is that:

When user loads a cbp, the Parser created, and the global CC option is copied to the Parser's member variable(m_Options or other names). A TempParser is created when CC plugin get initialized, this Parser serves for the standalone cpp files parsing.

When project A's CC option dialog get opened, it shows the Parser A's member variable m_Options, and when user click the Apply button, its m_Options are updated, and the global options inside .conf file also get updated.

When we switch to project B, when I open the CC option dialog, it would show:

option1: Parser B's m_Options, because m_Options in Parser B is originally a copy of .conf when it gets created, so it is before we modify the "project A's CC options".

option2: Parser B's m_Options should reread from the .conf file, so that the global CC option was copied to project B.

From your point of view, you think the "option2" is the correct option. I just think a while, and I think you are correct, that is "All the Parser instances now share a same CC options".

I think it would be better to throw up a message box saying "Sorry, sniff, global settings will not be applied for a project/parser until you request a re-parse of all the other loaded projects." Just kidding...

This is a hard problem. If we don't apply changes, we violate UI standards. If we do change them, a busy parser won't apply them anyway.

Maybe we should put up a message box that says, these changes will only be applied on the next re-parse for a project.
We could list the projects that have a 'busy' not done flag.

I remember this situation from about 13 years ago. The client asked me to throw up a message box that said "Options cannot be changed while a workspace is loaded".

Yes, I agree. Changing some of the parsing option does not take effect immediately.

Even I have change the project A's CC option, and the parser A is already finished its parsing job, so to make the parser option get affect, we have to "reparse" the project.

As a convolution, I think you patch is OK! Thanks for so many times to tweak your patches.

The remaining issue is: since all the Parsers were sharing a single CC option, why do we keep so many copies? Maybe, we can just have one in the ParseManager class. 

10

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

« Last post by Pecan on February 13, 2025, 11:02:15 pm »

So, what is the time we need to "read the Parser option from the .conf to the Parser instance", I think it should be in the constructor, and this should be the only place a Parser instance to read the initial parsing option.

I don't understand this request at all.
 
If a parser only reads the settings at parser creation time, when the user later changes the global settings but the parser is not allowed to read them after the change, the user now is parsing without the settings he/she requested.

If that user was me, I'd call that a bug.

I think it would be better to throw up a message box saying "Sorry, sniff, global settings will not be applied for a project/parser until you request a re-parse of all the other loaded projects." Just kidding...

This is a hard problem. If we don't apply changes, we violate UI standards. If we do change them, a busy parser won't apply them anyway.

Maybe we should put up a message box that says, these changes will only be applied on the next re-parse for a project.
We could list the projects that have a 'busy' not done flag.

I remember this situation from about 13 years ago. The client asked me to throw up a message box that said "Options cannot be changed while a workspace is loaded".