We switched to wx 3.1.5 --> download the new wx dll's see link belowIf you tested the 22 january nightly you may find your compiler executable has changed from gcc.exe to mingw32-gcc.exe and g++.exe to mingw32-g++.exe. Please correct this, you won't be asked again.Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml
Before you use a nightly make sure you understand how it works (http://forums.next.codeblocks.org/index.php/topic,3232.0.html).
A link to the unicode windows wxWidget dll(s) for Code::Blocks : https://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw31u_gcc_cb_wx315_2D_gcc810-mingw64.7z
A link to Mingw64 dll's needed by Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/Mingw64dlls8.1.0.7z
The 24 April 2022 build is out.
- Windows :
http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2022/CB_20220424_rev12802_win64.7z
- Linux :
none
The current SDK version is : 2.17.0
Resolved Fixed:
- Fix XML syntax of some lexers (&, < and > must be escaped when not in a CDATA block)
- Printing: Detect incorrect page range (start > end)
- Try to fix crash reported in ticket #1168.
- Printing: Add support for printing multiple documents as a block.
- Compiler: Fix assert when opening "Advanced options".
- Fix translation when using wx3.1.6.
- Allow splash screen translation.
- Move crash report file if C::B folder is not writable (ticket #1249, thanks Andrew Cottrell).
- cb_share_config: allow to export selected settings only
- cbp2make: respect target selection for exports
- compiler: respect 8.3 notation settings in advanced compiler options for source files, too (this is often needed for cross-compilers like QNX on Windows)
- scriptin: Add script binding for tinyXML functions to read XML files within squirrel
- scripting: Improve error reporting of test_string for script testing
- scripting: Add test script for the XML script binding.
- scripting: Add versioning for script binding. So we can check and change scripting binding version in scripts.
- Apply patch to Enhance C::B GDB memory watch class for future changes. (Thanks Andrew Cottrell)
- sdk: scripting, fix ask permission dialog to remember the selection.
Regressions/Confirmed/Annoying/Common bugs:
The Clangd_Client for this nightly can be downloaded at
https://sourceforge.net/projects/cb-clangd-client/files/Plugin_Install_Package/Windows_x64/ClangdClientForCBNightly_20220424_rev12802_win64.zip/download
Copy the included clangd_client.zip to <YourCodeBlocksNightlyFolder>\share\CodeBlocks\clangd_client.zip
Do not unzip this file.
Copy the included clangd_client.dll to <YourCodeBlocksNightlyFolder>\share\CodeBlocks\plugins\clangd_client.dll
Restart your CodeBlocks Nightly.
Install instructions for LLVM/clangd are included within the downloaded .zip file.
Modify message
Why is CB_20220327_rev12765_win64.7z part of the content of the package? ;)
Quote from: AlexN on April 25, 2022, 10:44:23 AM
Why is CB_20220327_rev12765_win64.7z part of the content of the package? ;)
Likely because the last newbie did not understand that this plugin is for the nightly build and they tried to use it with an self-build of Code::Blocks. Or maybe it was just a mistake. Since, it is the wrong nightly it is likely a mistake.
Tim S.
Quote from: AlexN on April 25, 2022, 10:44:23 AM
Why is CB_20220327_rev12765_win64.7z part of the content of the package? ;)
Pecan has fixed the wrong file name.
@Pecan, great work! I will build the C::B and clangd_client soon.
Quote from: AlexN on April 25, 2022, 10:44:23 AM
Why is CB_20220327_rev12765_win64.7z part of the content of the package? ;)
Ok, I'm confused. I don't see the above as part of
https://sourceforge.net/projects/cb-clangd-client/files/Plugin_Install_Package/Windows_x64/ClangdClientForCBNightly_20220424_rev12802_win64.zip/download
I just downloaded it and it only has:
PS C:\temp> unzip -l c:\temp\ClangdClientForCBNightly_20220424_rev12802_win64.zip
Archive: c:/temp/ClangdClientForCBNightly_20220424_rev12802_win64.zip
Length Date Time Name
-------- ---- ---- ----
60422506 04/24/22 14:01 clangd_client.dll
552378 04/23/22 11:13 clangd_client.zip
6367 03/18/22 09:46 Windows-LLVM-ClangD-Install-Readme.txt
3230 03/18/22 09:47 Windows-Plugin-Install-Readme.txt
-------- -------
60984481 4 files
Quote from: Pecan on April 25, 2022, 07:37:41 PM
Quote from: AlexN on April 25, 2022, 10:44:23 AM
Why is CB_20220327_rev12765_win64.7z part of the content of the package? ;)
Ok, I'm confused. I don't see the above as part of
https://sourceforge.net/projects/cb-clangd-client/files/Plugin_Install_Package/Windows_x64/ClangdClientForCBNightly_20220424_rev12802_win64.zip/download
I just downloaded it and it only has:
PS C:\temp> unzip -l c:\temp\ClangdClientForCBNightly_20220424_rev12802_win64.zip
Archive: c:/temp/ClangdClientForCBNightly_20220424_rev12802_win64.zip
Length Date Time Name
-------- ---- ---- ----
60422506 04/24/22 14:01 clangd_client.dll
552378 04/23/22 11:13 clangd_client.zip
6367 03/18/22 09:46 Windows-LLVM-ClangD-Install-Readme.txt
3230 03/18/22 09:47 Windows-Plugin-Install-Readme.txt
-------- -------
60984481 4 files
Sorry, It was part of CB_20220424_rev12802_win64 zip.
Tim S.
@ Killerbot
Wups !
@ Killerbot, I don't know how this happened by I managed to pollute the latest nightly while updating my clangd_client project.
Could you look at
http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2022/CB_20220424_rev12802_win64.7z
and delete
f:\usr\Proj\cbNightly\CodeBlocks\CB_20220327_rev12765_win64.7z
out of the nightly, or re-upload it.
Also, could you tell me how it's possible that I could do that so I won't do it again. I'm not an administrator of Code::Blocks on SourceForge.
Thanks
Quote from: Pecan on April 25, 2022, 07:37:41 PM
Quote from: AlexN on April 25, 2022, 10:44:23 AM
Why is CB_20220327_rev12765_win64.7z part of the content of the package? ;)
Ok, I'm confused. I don't see the above as part of
https://sourceforge.net/projects/cb-clangd-client/files/Plugin_Install_Package/Windows_x64/ClangdClientForCBNightly_20220424_rev12802_win64.zip/download
I just downloaded it and it only has:
My mistake, I spoke from the nightly build.
Observed strange behavior: C::B cannot neither to find nor to replace the string " ::". For example, with " !=" everything looks OK.
Quote from: nenin on April 28, 2022, 09:55:57 AM
Observed strange behavior: C::B cannot neither to find nor to replace the string " ::". For example, with " !=" everything looks OK.
I have no idea what is your problem.
Can you be more specific? We need detailed information about your problem.
the mistake was mine, in the zip of the recent nightly I also included the previous nightly. In the meantime I have replaced it with a slim-fit one ;-)
Quote from: ollydbg on April 28, 2022, 04:50:44 PM
Quote from: nenin on April 28, 2022, 09:55:57 AM
Observed strange behavior: C::B cannot neither to find nor to replace the string " ::". For example, with " !=" everything looks OK.
I have no idea what is your problem.
Can you be more specific? We need detailed information about your problem.
Sorry, I cannot reproduce the issue today. Yesterday I did massive migration from named to anonymous namespaces, with a lot of "Search/Replace..." operations, and I faced situation when C::B could not find " ::" subsring in code.
did you have regexp replacing activated?
Quote from: BlueHazzard on April 29, 2022, 03:08:06 PM
did you have regexp replacing activated?
No. Only one not very typical point was that edited files are UTF-8: there are some strings with Greek letters. But I cannot reproduce problems at these files later.
Very strong braking when executing a program in the CodeBlocks shell environment. In this case, there is a strong influence on the timers for organizing real-time calculations. Perhaps the latter circumstance leads to damage to large arrays inside the executable program, too.
Please, tell me, is it possible to disable the influence of CodeBlocks on the debug execution time of the program inside it?
Весьма сильное торможение при исполнении программы в среде оболочки CodeBlocks. При это происходит сильное влияние на таймеры для организации вычислений в реальном времени. Возможно последнее обстоятельство приводит к порче больших массивов внутри исполняемой программы, тоже.
Пожалуйста, подскажите, можно ли отключать влияние CodeBlocks на время отладочного исполнения программы внутри него?
Codeblocks has only influence on the debugee when you set a breakpoint or when you have many watches, memory windows open.
Less watches, less data to transfer, less impact... Also codeblocks adds only overhead if your program actually stops on a breakpoint. If your program runs, codeblocks does not add any overhead.
The rest of overhead you are experiencing comes from gdb.
GDB on windows is really slow, see this: https://stackoverflow.com/questions/27380443/why-is-gdb-so-slow-in-windows
So linux user have a better experience here. On linux the overhead should be fairly small, expect you are using some conditional breakpoints...
What operating system are you using?
Thank you, sincerely. Yes, always have many open windows in CodeBlocks. Need to debug programs in full speed optimization mode. Errors in the computational experiment appear after a very long time of observation of the results.
Unfortunately, CodeBlocks executes programs much more slowly than if it were to run outside of this shell. For real-time execution, this is essential.
Thank you again, so be it.
Благодарю, искренне. У меня всегда много открытых окон в CodeBlocks. Мне приходится отлаживать программы в режиме полной оптимизации по скорости выполнения. Погрешности в вычислительном эксперименте проявляются после весьма длительного времени наблюдения результатов.
К сожалению CodeBlocks исполняет программы значительно медленнее, чем если бы работать вне этой оболочки. Для исполнения в реальном времени это существенно.
Благодарю, еще раз, пусть так и будет.
Quote from: Khram on May 04, 2022, 06:10:23 PM
Thank you, sincerely. Yes, always have many open windows in CodeBlocks. Need to debug programs in full speed optimization mode. Errors in the computational experiment appear after a very long time of observation of the results.
Unfortunately, CodeBlocks executes programs much more slowly than if it were to run outside of this shell. For real-time execution, this is essential.
Thank you again, so be it.
And, what is the the operating system you are using?
If you fail to answer the only reasons are you do not understand the question or you are a help vampire!
Tim S.
QuoteYes, always have many open windows in CodeBlocks
Normal windows (like code editors) do not influence the debugger performance. Only windows from the menu Debug->debugging windows influence the performance.
But as I said... The thing that makes your application slow is gdb, and that probably because you are using windows... Nothing to do with codeblocks....
Without GDB, and only full optimization for speed. OS in Windows-11.
So have you tried to set the environment variable as described in https://stackoverflow.com/questions/27380443/why-is-gdb-so-slow-in-windows ?
Have you tried gdb from the console, without codeblocks? (it should not make any difference)
Other things that can help:
Not more than 4 break points
Do not debug to libraries with debug symbols (this should only slow down initial startup, but not runtime)
try out cdb instead of gdb
I do not know the kind of bug you are huntig, but you can also try to use printf instead of gdb,
if you search for performance bugs, you can try https://github.com/wolfpld/tracy
ecc...
Thank you. Yes, I have debugging done exclusively with cprintf and in OpenGL on two graphics windows, asynchronously. No GDB or CDB debuggers are fundamentally not used. That is, the calculations themselves, as if in the background, and regardless of this, the visualization of two different processes of wave hydrodynamics and hydromechanics of the ship.
What happens: inside CodeBlocks, seven cores are evenly loaded at 45%, the eighth core at 100%. Without CodeBlocks - the experiment is much faster and all eight cores are loaded evenly by about 40%, and, accordingly, the interactive control is more responsive to external control commands.
Thanks for the link: https://github.com/wolfpld/tracy - really very interesting
Благодарю. Да у меня отладка выполняется исключительно с помощью cprintf и в OpenGL на двух графических окнах, асинхронно. Никакие отладчики GDB или CDB принципиально не используются. То есть, расчеты сами по себе, как бы в фоновом режиме, и независимо от этого визуализация двух различных процессов гидродинамики волн и гидромеханики корабля.
Что получается: внутри CodeBlocks равномерно загружаются семь ядер на 45%, восьмое ядро на 100%. Без CodeBlocks - эксперимент проходит значительно быстрее и все восемь ядер загружаются равномерно примерно на 40%, и, соответственно, интерактивное управление получается более отзывчивым на внешние команды управления.
Спасибо за ссылку: https://github.com/wolfpld/tracy - реально очень интересно
The general impression is that CodeBlocks itself launches a debugger, such as GDB, which then affects the user program running inside the shell.
Общее впечатление такое, что сам CodeBlocks, запускает отладчик, типа GDB, который затем влияет на исполняемую внутри оболочки пользовательскую программу.
QuoteThe general impression is that CodeBlocks itself launches a debugger, such as GDB, which then affects the user program running inside the shell.
Codeblocks starts the application trough gdb if you run it in debug mode (Red Arrow in tool bar, or Debug->Start)
If you run your application with the green arrow in the toolbar or Build->Run no debugger is called.
Hi,
my C:B is locking down once in a while and there is no RPT file created.
Our company setting for Windows 10 is preventing creating file into the "C:\Program Files\CodeBlocks\" unless you're admin.
Possible that is preventing RPT file to be created ?
Thanks,
svn 12802
Windows 10 Entreprise, 21H2
16 GB
It if just locks there will be no report, only crashes create one.
Starting with r12785, C::B will check if the folder containing the executable is writable, and if it is not then it will write the RPT file in the config folder:
%appdata%\Codeblocks
This is making sense, my previous nightly build was 12765.
Thanks.
:)