Recent Posts

91

General (but related to Code::Blocks) / Re: Problem with SFML 2.0 libraries

« Last post by Qday on July 02, 2024, 03:45:01 am »

Post the current full re-build log.
Edit: Add link to FAQ https://wiki.codeblocks.org/index.php?title=FAQ-Compiling_%28general%29#Q:_How_do_I_report_a_compilation_problem_on_the_forums.3F

Tim S.

Sorry for the late response. I hope you can still help me .

Code

-------------- Clean: Debug in SFML_01 (compiler: GNU GCC Compiler)---------------

Cleaned "SFML_01 - Debug"

-------------- Build: Debug in SFML_01 (compiler: GNU GCC Compiler)---------------

g++.exe -Wall -g -IC:\Dev\SFML-2.6.1\include -c D:\CPP\SFML_01\main.cpp -o obj\Debug\main.o
g++.exe -LC:\Dev\SFML-2.6.1\lib -o bin\Debug\SFML_01.exe obj\Debug\main.o  -static -static-libgcc  -lsfml-audio-d -lsfml-graphics-d -lsfml-main-d -lsfml-network-d -lsfml-system-d -lsfml-window-d -mwindows
Output file is bin\Debug\SFML_01.exe with size 2.37 MB
Process terminated with status 0 (0 minute(s), 1 second(s))
0 error(s), 0 warning(s) (0 minute(s), 1 second(s))
Build log saved as: 
file://D:/CPP/SFML_01/SFML_01_build_log.html

Is it what you were asking for?

92

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

« Last post by sodev on July 01, 2024, 03:09:13 pm »

PS : Why generation of CB Project by Cmake is considered like "deprecated" by Cmake Team ?

Because it is too much of a burden for them to support every IDE there is. Instead, they offer a defined API which allows the IDEs to integrate CMake from their side. This is basically the same approach how programming languages get supported by IDEs through language servers.

93

Nightly builds / Re: The 30 June 2024 build (13533) is out.

« Last post by Xaviou on June 30, 2024, 06:13:41 pm »

Hi.

OS X version of this rev can be downloaded from my website.
There is only a macOS-11.6 version.
Note that it is not a notarized version of the application.

32 bits version for Windows can also be found in the same place.

Debian Bookworm and Bullseye (32 and 64 bits) can be installed from my repo
The corresponding unsigned deb files can also be downloaded from the website page linked above.

Ubuntu-22.04, 23.10 and 24.04 versions can be installed from my ppa

Regards
Xav'

94

Nightly builds / Response -> The 14 June 2024 build (13529) is out.

« Last post by ThierryD on June 30, 2024, 12:36:40 pm »

Hi Pecan,

I wait about next nightly build ... because, today, I can't recompile CB on my platform ... but, it's one of my objective in the future. I participe on Freeglut version 3.6.0 today on Windows and Linux (with CB ... sure !, but also with Cmake).
After install last CB nigthly build (svn 13533), problem disappear.
Thank's for your reactivity, good job.

Bye.

PS : Why generation of CB Project by Cmake is considered like "deprecated" by Cmake Team ?
       Thank's.

95

Nightly builds / The 30 June 2024 build (13533) is out.

« Last post by killerbot on June 30, 2024, 10:29:58 am »

We switched to gcc 14.1.0 (on 20 May 2024) --> download the new wx/mingw dll's see link below

Get the compiler we use here : https://github.com/brechtsanders/winlibs_mingw/releases/download/14.1.0posix-18.1.5-11.0.1-ucrt-r1/winlibs-x86_64-posix-seh-gcc-14.1.0-mingw-w64ucrt-11.0.1-r1.7z

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.

A link to the unicode windows wxWidget dll(s) for Code::Blocks : https://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw32u_gcc_cb_wx325_2D_gcc1410-mingw64.7z
A link to Mingw64 dll's needed by Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/Mingw64dlls14.1.0.7z


The 30 June 2024 build is out.
  - Windows :
   http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2024/CB_20240630_rev13533_win64.7z
  - Linux :
   none

The current SDK version is : 2.25.0

Resolved Fixed:

• BrowseTracker 1.4.117 24/06/18 Fix GetMaxEntries() (Helpers.cpp) to query conf only once

Regressions/Confirmed/Annoying/Common bugs:

96

Nightly builds / Re: The 25 May 2024 build (13524) is out.

« Last post by HuskyDucky on June 28, 2024, 02:28:53 pm »

Hi,

I notice a bug over copy/paste on Code::Blocks.

For example, when I open Dolphin (Fedora's file manager), press F2 over a file and copy its name (Ctrl+C) and try to Paste this text (Ctrl+V) in to a file opened in the Code::Blocks, nothing happens.

I'm running a Fedora 40 KDE (6.1) Spin.

best regards,

97

General (but related to Code::Blocks) / Re: Size_type Erro

« Last post by Miguel Gimenez on June 27, 2024, 12:11:24 pm »

Copy of a post in Reddit.

Waiting for the spam link...

98

General (but related to Code::Blocks) / Size_type Erro

« Last post by williampool on June 27, 2024, 10:16:17 am »

Hello,
I am new to Code::Blocks (and C++) and have been working through examples from C++ All-In-One for dummies, 4th Edition. The code below and several other codes I have tried to run keep having the following error:

error: conversion to 'std::__cxx11::basic_string<char>::size_type' {aka 'long long unsigned int'} from 'int' may change the sign of the result [-Werror=sign-conversion]|

The code for the warning above can be found below. The build error was referencing the following line: InkLevelPercent = InkLevelPercent - words.length();

In another code I tried to run, I received the following similar error:

error: conversion to 'std::vector<std::__cxx11::basic_string<char> >::size_type' {aka 'long long unsigned int'} from 'int' may change the sign of the result [-Werror=sign-conversion]|

The build error was referencing the following line in that code (I can post that code as well if needed):

int randomIndex = rand() % words.size();

Is there something obvious I may be missing? Browsing through Google I kept seeing references to size_t but wasn't sure if that was applicable, and if so, how to change the code to correct the issue.

99

Plugins development / Re: Code completion using LSP and clangd

« Last post by Pecan on June 26, 2024, 11:09:43 pm »

Hi Pecan,

compile_commands.json is read and parsed every time a file is opened. This uses a lot of CPU, especially during the initial parsing of all files, where
 compile_commands.json is read and parsed as many times as the number of files in the project. Attached patch does some optimisation for this.
1. Save the parsed compile_commands.json until the first batch parsing is completed, cleared after that.
2. After initial batch processing, all the filesnames are stored in a vector, and only if the filename is not present in this vector, compile commands is parsed. This helps to avoid parsing of the compile_commands.json after editing and saving of the file.

Thanks, Christo

Here some results from this christo patch.
The first millisecond measure following the filename is the parse time prior to the patch; the second is after applying the patch. There's a significant savings there. And it has a visible effect. It even feels faster.

Looks like I'll be applying the patch.
Thanks Christo.

Code

parser_base.cpp (1601 ms) (1264 ms)
codecompletion.cpp (2281 ms) (1776 ms)
LSP_tokenizer.cpp (1806 ms) (1235 ms)
parser.cpp (2462 ms) (1455 ms)
LSP_symbolsparser.cpp (2322 ms) (1706 ms)
coderefactoring.cpp (1744 ms) (1277 ms)
parsemanager.cpp (2274 ms) (1601 ms)
classbrowser.cpp (1723 ms) (1305 ms)
lspdiagresultslog.cpp (1253 ms) (524 ms)
ccoptionsdlg.cpp (1975 ms) (1554 ms)
ClangLocator.cpp (1295 ms) (1125 ms)
client.cpp (2417 ms) (1764 ms)
searchtree.cpp (596 ms) (329 ms)
cctreectrl.cpp (1983 ms) (1218 ms)
expression.cpp (2114 ms) (1238 ms)
token.cpp (1005 ms) (444 ms)
profiletimer.cpp (1983 ms) (251 ms)
ccdebuginfo.cpp (3174 ms) (1227 ms)
tokentree.cpp (2094 ms) (347 ms)
ccoptionsprjdlg.cpp (2878 ms) (1147 ms)
parsemanager_base.cpp (2345 ms) (410 ms)
selectincludefile.cpp (1791 ms) (395 ms)
doxygen_parser.cpp (3337 ms) (1299 ms)
StringUtils.cpp (491 ms) (346 ms)
gotofunctiondlg.cpp (1834 ms) (964 ms)
processreaderthread.cpp (1546 ms) (855 ms)
insertclassmethoddlg.cpp (2344 ms) (1155 ms)
procutils.cpp (1107 ms) (1078 ms)
winprocess_impl.cpp (1186 ms) (1076 ms)
winprocess.cpp (872 ms) (822 ms)
fileutils.cpp (1167 ms) (1219 ms)
asyncprocess.cpp (1755 ms) (1281 ms)

100

Plugins development / Re: Code completion using LSP and clangd

« Last post by stahta01 on June 26, 2024, 01:51:28 pm »

Oh yes, as sodev said, I just disabled wxUSE_UNSAFE_WXSTRING_CONV. Those STL containers related options have been modified, too, but I don't think they really influence the conversion from wxString to std::string.

Since, IIRC, using STL means wxString is stored as std::string I would say you are technically right but, if the other person is using an STL built wxWidgets and you are not then you could have that as the cause of your problem!

Tim S.