Code::Blocks Forums

User forums => Nightly builds => Topic started by: killerbot on December 13, 2020, 10:43:55 am

Title: The 13 December 2020 build (12240) is out.
Post by: killerbot on December 13, 2020, 10:43:55 am
 new PATCHED wx dll , please download these too and replace your old ones !!!

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.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_wx313_2D_gcc810-mingw64-2.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 13 December 2020 build is out.
  - Windows :
   http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2020/CB_20201213_rev12240_win64.7z
  - Linux :
   none

The current SDK version is : 2.4.0

Resolved Fixed:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 13 December 2020 build (12240) is out.
Post by: stahta01 on December 13, 2020, 11:16:44 am
new PATCHED wx dll , please download these too and replace your old ones !!!

The wxWidgets DLL on the download link was the same as the one I downloaded with the last nightly.
Is the link wrong?

Tim S.
Title: Re: The 13 December 2020 build (12240) is out.
Post by: omlk on December 13, 2020, 07:51:43 pm
Why not use MSYS2 (https://www.msys2.org/) for compiling Code::Blocks? MSYS2 include MinGW gcc v11?
Title: Re: The 13 December 2020 build (12240) is out.
Post by: oBFusCATed on December 14, 2020, 01:24:03 am
omlk: What would we gain?
Title: Re: The 13 December 2020 build (12240) is out.
Post by: gh_origin on December 14, 2020, 04:38:05 am
omlk: What would we gain?

A Unix-like build environment. Produces native binaries using MinGW, doesn't need to ship another DLL like Cygwin. But there is MSYS2 DLL for anyone need a POSIX compatibility layer.

BTW, if you choose to go forward with LSP and CCLS, then MSYS2 is a good choice. You have to depend on it anyway. Offering CodeBlocks packages on MSYS2 (co-operate with the MSYS2 team), so installing CodeBlocks with all the needed stuffs for CCLS made easy with just pacman -S codeblocks, pacman will handle all of the dependencies for you, the users don't need to setup CCLS packages themselves before able to use CodeBlocks.

Please note, there is Qt Creator and complete Qt5 packages for MSYS2 for a while. It's nothing wrong for CodeBlocks to follow. Employing MSYS2 also lower the maintenance efforts, as we now using the same Unix-like environment across platforms, no need to set Windows specific stuffs anymore.

And also, if you choose to continue to distribute CodeBlocks binaries like what you are doing now alongside with/instead of MSYS2 packages of CodeBlocks, you still need to bundle MSYS2 related stuffs for CCLS anyway. So using the same environment really helps avoiding a lot of troubles.
Title: Re: The 13 December 2020 build (12240) is out.
Post by: stahta01 on December 14, 2020, 06:33:30 am
omlk: What would we gain?

A Unix-like build environment. Produces native binaries using MinGW, doesn't need to ship another DLL like Cygwin. But there is MSYS2 DLL for anyone need a POSIX compatibility layer.

BTW, if you choose to go forward with LSP and CCLS, then MSYS2 is a good choice. You have to depend on it anyway. Offering CodeBlocks packages on MSYS2 (co-operate with the MSYS2 team), so installing CodeBlocks with all the needed stuffs for CCLS made easy with just pacman -S codeblocks, pacman will handle all of the dependencies for you, the users don't need to setup CCLS packages themselves before able to use CodeBlocks.

Please note, there is Qt Creator and complete Qt5 packages for MSYS2 for a while. It's nothing wrong for CodeBlocks to follow. Employing MSYS2 also lower the maintenance efforts, as we now using the same Unix-like environment across platforms, no need to set Windows specific stuffs anymore.

And also, if you choose to continue to distribute CodeBlocks binaries like what you are doing now alongside with/instead of MSYS2 packages of CodeBlocks, you still need to bundle MSYS2 related stuffs for CCLS anyway. So using the same environment really helps avoiding a lot of troubles.

I have tried off and on to get the CB configure/make method of build to work under MSys2 and I have failed!
I am now using edited CB Projects to build CB under MSys2 and it works reasonably well.

Tim S.
Title: Re: The 13 December 2020 build (12240) is out.
Post by: omlk on December 14, 2020, 10:32:02 am
omlk: What would we gain?

А step into the future.  ;)
Title: Re: The 13 December 2020 build (12240) is out.
Post by: omlk on December 14, 2020, 10:38:47 am
Pay attention!
-fcommon


https://gcc.gnu.org/gcc-9/changes.html
https://gcc.gnu.org/gcc-10/changes.html
https://gcc.gnu.org/gcc-11/changes.html
Title: Re: The 13 December 2020 build (12240) is out.
Post by: stahta01 on December 14, 2020, 12:20:17 pm
Pay attention!
-fcommon

https://gcc.gnu.org/gcc-10/changes.html

Please think! The CB Team can already use a newer GCC 10 Compiler without using MSys2.

Tim S.
Title: Re: The 13 December 2020 build (12240) is out.
Post by: oBFusCATed on December 14, 2020, 12:47:16 pm
А step into the future.  ;)
Ok, you can troll and waste our time, but what else would we gain?
Is GCC 10 faster to build?
Does it produce faster binaries?
Does it actually work? :)
Title: Re: The 13 December 2020 build (12240) is out.
Post by: oBFusCATed on December 14, 2020, 12:50:20 pm
Pay attention!
-fcommon

https://gcc.gnu.org/gcc-10/changes.html
Why should we care about a C only flag?
You continue to be trolling.

p.s. You can use GCC 10 for your projects. You're not obliged to use the compiler we use. You have to use the same compiler if you want to do binary C::B plugins.
Title: Re: The 13 December 2020 build (12240) is out.
Post by: omlk on December 14, 2020, 02:40:18 pm
Please think! The CB Team can already use a newer GCC 10 Compiler without using MSys2.

Tim S.

Okay, I'll explain why I don't think gcc,g++ 10 is used. Because http://sourceforge.net only has the latest buggy version 8.1.0. If the development team used to get the build C::B Linux, it would have long been used gcc,g++ 10, as well as the impression that builds in Windows.If my guess is wrong, please tell me exactly where I went wrong.
Title: Re: The 13 December 2020 build (12240) is out.
Post by: omlk on December 14, 2020, 03:12:17 pm
А step into the future.  ;)
Ok, you can troll and waste our time, but what else would we gain?
Is GCC 10 faster to build?
Does it produce faster binaries?
Does it actually work? :)

I wasn't going to troll you or waste your precious time on nonsense.
Title: Re: The 13 December 2020 build (12240) is out.
Post by: gh_origin on December 14, 2020, 04:06:17 pm
I have tried off and on to get the CB configure/make method of build to work under MSys2 and I have failed!
I am now using edited CB Projects to build CB under MSys2 and it works reasonably well.

Tim S.

The problem is with make. Not MinGW! This is why you could use MSYS2's MinGW to build CodeBlocks using CodeBlocks successfully.
Please note that mingw32-make's Makefiles and make's Makefiles are incompatible.
I think you should regenerate it using autoconf -i -f and try again.
This is the reason why CodeLite has 'CodeLite Makefile Generator' and 'CodeLite Makefile Generator - UNIX'.
I always hope someday CodeBlocks could have the Makefile generator ability of CodeLite.
CodeLite also supports cmake. But I don't use cmake, so I don't care.
Title: Re: The 13 December 2020 build (12240) is out.
Post by: gh_origin on December 14, 2020, 04:08:35 pm
Please think! The CB Team can already use a newer GCC 10 Compiler without using MSys2.

Tim S.

I don't think so. If I recall it right, CodeBlocks need CXXFLAGS='-fpermissive' when building with higher GCC. Correct me if I'm wrong.
Title: Re: The 13 December 2020 build (12240) is out.
Post by: gh_origin on December 14, 2020, 04:12:31 pm
Okay, I'll explain why I don't think gcc,g++ 10 is used. Because http://sourceforge.net only has the latest buggy version 8.1.0. If the development team used to get the build C::B Linux, it would have long been used gcc,g++ 10, as well as the impression that builds in Windows.If my guess is wrong, please tell me exactly where I went wrong.

The CodeBlocks projects used to use TDM GCC before it was abandoned. They just switched to MinGW64 for the last release.
Now TDM GCC is back. It's nothing wrong for them to switching back to it again:

https://jmeubank.github.io/tdm-gcc/download/

Your reasons was wrong. I would say they should switch to MSYS2 because of CCLS and their future dependence of LSP.
Title: Re: The 13 December 2020 build (12240) is out.
Post by: gh_origin on December 14, 2020, 04:22:13 pm
I wasn't going to troll you or waste your precious time on nonsense.

I don't think you are trolling, too. You are just annoying and it takes energy to address your wrong statements so I just try my best to avoid talking with you.

But this is the last time I use CodeBlocks so it's no longer a problem for me.

I no longer have to teach Programming anymore. I'm back teaching Elementary Math only.

They hired a new teacher to teach Programming for the students and he switched to VSCode, as I and my students have done all of the cleaning job so the sample code no longer depends on any Borland specific features and compile cleanly under TDM GCC 9.2 and Clang 11 with -std=gnu++98 now. It's a bit sad that the code still not yet conforms to C++11.

Bye everyone. And good luck to you all with your new adventure with LSP and CCLS.
Title: Re: The 13 December 2020 build (12240) is out.
Post by: stahta01 on December 14, 2020, 05:54:05 pm
I have tried off and on to get the CB configure/make method of build to work under MSys2 and I have failed!
I am now using edited CB Projects to build CB under MSys2 and it works reasonably well.

Tim S.

The problem is with make. Not MinGW! This is why you could use MSYS2's MinGW to build CodeBlocks using CodeBlocks successfully.
Please note that mingw32-make's Makefiles and make's Makefiles are incompatible.
I think you should regenerate it using autoconf -i -f and try again.
This is the reason why CodeLite has 'CodeLite Makefile Generator' and 'CodeLite Makefile Generator - UNIX'.
I always hope someday CodeBlocks could have the Makefile generator ability of CodeLite.
CodeLite also supports cmake. But I don't use cmake, so I don't care.

I use MSys2 all the time! Have you even once created an MSys2 package?

I am going to write you off as someone who knows little about what they post; till you list for me the packages in MSys2 you have contributed to!

Tim S.


Title: Re: The 13 December 2020 build (12240) is out.
Post by: killerbot on December 14, 2020, 06:10:01 pm
new PATCHED wx dll , please download these too and replace your old ones !!!

The wxWidgets DLL on the download link was the same as the one I downloaded with the last nightly.
Is the link wrong?

Tim S.

no, but I repeat this some time, since not everybody see every nightly. Wil ltry to do a better job on this and on the next nightly remove it.
Title: Re: The 13 December 2020 build (12240) is out.
Post by: eckard_klotz on December 17, 2020, 09:49:35 am
Dear Code::Blocks Developers.


I still face that the symbol-browser is not available in the nightly.

Thus I rebuild Code::Blocks base on the patch http://forums.codeblocks.org/index.php/topic,23580.60.html (http://forums.codeblocks.org/index.php/topic,23580.60.html) from Miguel Gimenez http://forums.codeblocks.org/index.php?action=profile;u=34306 (http://forums.codeblocks.org/index.php?action=profile;u=34306) by my self.

I have done the same since the symbol-browser was disabled but I never faced issues with it.


I wish you and all C::B users a marry Christmas and a happy new year.

Take care about you and stay healthy,
                                                       Eckard Klotz.
Title: Re: The 13 December 2020 build (12240) is out.
Post by: Miguel Gimenez on December 17, 2020, 10:30:56 am
There is a fully threaded version of my patch for the symbol browser, see https://sourceforge.net/p/codeblocks/tickets/1031/ (https://sourceforge.net/p/codeblocks/tickets/1031/). If you use it and have any problem please report it in the ticket (and if it works as it should please also report).
Title: Re: The 13 December 2020 build (12240) is out.
Post by: ollydbg on December 17, 2020, 11:12:08 am
Dear Code::Blocks Developers.


I still face that the symbol-browser is not available in the nightly.

Thus I rebuild Code::Blocks base on the patch http://forums.codeblocks.org/index.php/topic,23580.60.html (http://forums.codeblocks.org/index.php/topic,23580.60.html) from Miguel Gimenez http://forums.codeblocks.org/index.php?action=profile;u=34306 (http://forums.codeblocks.org/index.php?action=profile;u=34306) by my self.

I have done the same since the symbol-browser was disabled but I never faced issues with it.
  • From my point of view a symbol-browser is an essential part of an IDE like Code::Blocks.
  • Thus I like to ask you to integrate it again with the nightly build.
  • In the case that some users still face issues with it, you may deactivate it by default and add a warning visible when the user is activating it.
  • This way the single user could decide, if symbol-browser becomes active or not.


I wish you and all C::B users a marry Christmas and a happy new year.

Take care about you and stay healthy,
                                                       Eckard Klotz.

Hi, you can also look at this post:
Re: Symbols browser issue of CC has been fixed for my Linux (http://forums.codeblocks.org/index.php/topic,23580.msg165336.html#msg165336)

I have a custom build binary in github.
Title: Re: The 13 December 2020 build (12240) is out.
Post by: eckard_klotz on December 17, 2020, 01:22:14 pm
Hello Miguel Gimenez and Ollydbg.

Thanks for your reply and all the effort you have taken so far to make the symbol-browser run again.

What I wanted suggest in this nightly discussion is to add it again to the nightly release again to the next nightlies.

Take care and stay healthy,
                                       Eckard Klotz.
Title: Re: The 13 December 2020 build (12240) is out.
Post by: gh_origin on December 20, 2020, 09:03:38 am
I use MSys2 all the time! Have you even once created an MSys2 package?

I am going to write you off as someone who knows little about what they post; till you list for me the packages in MSys2 you have contributed to!

Tim S.

I used Manjaro Linux but not really MSYS2. I have setup MSYS2, let it there, but don't use it much. All of my writings are just what I thought what it should be. I have no way to back it up. I have experience with the pacman package manager but never created any packages either for Arch or MSYS2.

So, I just wrote what I thought to be right. Honestly, I have no basis for it other than my own experience and reasoning. It could be all wrong.
Title: Re: The 13 December 2020 build (12240) is out.
Post by: eckard_klotz on January 10, 2021, 04:59:02 pm
Hello All.

I wish a happy new year for all Code::Blocks Developers as well as for all Code::Blocks Users.


Unfortunately I face currently some issues with the Undo functionality of the editor.

Sometimes a change done in one step for several lines could only be undone line for line. Commenting out several lines by using [Ctrl][Shift][C] is an example for this
But more confusing is that several independent changes are some times undone in one single step even only the last change should really be undone.

I'm working with the revision 12240 build by my self on Windows 10.

The only modifications I have done are


Somewhere here in the Code::Blocks forum I already read that this issue is already known and that the used Scintilla library-version is the reason.
Thus I assume that somebody is already working on it.
 
However, is it possible to clear the undo-queue manually from time to time to ensure that old changes which should definitely be kept will not be undone?

Please stay well and healthy,
                                         Eckard Klotz.
Title: Re: The 13 December 2020 build (12240) is out.
Post by: oBFusCATed on January 10, 2021, 06:57:45 pm
Edit -> Clear changes history?

No, it is not a known problem. Give link or post a ticket on sf.net with exact steps to reproduce the problem.
Also first make sure that geany/scite/codelite/notepad++ behave differently.
Title: Re: The 13 December 2020 build (12240) is out.
Post by: eckard_klotz on January 17, 2021, 10:43:29 am
Hello oBFusCATed.

Thanks for your reply and please accept my apologize for my late answer.

First of all thanks for your tip where to find the "Clear changes history" item.

Quote
No, it is not a known problem.

Quote
Also first make sure that geany/scite/codelite/notepad++ behave differently.

Quote
Give link or post a ticket on sf.net with exact steps to reproduce the problem.

But my main request was how to clear the undo-history and this question was answered by you. So once again thanks for your support.

Stay well and healthy,
                                Eckard Klotz.
Title: Re: The 13 December 2020 build (12240) is out.
Post by: oBFusCATed on January 17, 2021, 01:39:11 pm
Quote
Also first make sure that geany/scite/codelite/notepad++ behave differently.
  • I'm unsure what you mean with mentioning the behaviour of other tools.
  • As far as I understand it it is a problem located in a third-party library used with Code::Blocks.
  • So I understand, that it has to be solved by the third party project.
  • Never the less it is a already known problem. Otherwise you would not mention the other tools.
  • Or do you expect that I as user of Code::Blocks set up a bug-report in the third-party project with the statement, that the third-party library results in a problem with Code::Blocks?

You're overthinking. We don't know where the problem happens, yet.
So testing other uses of the library could reveal if it is in the library or in C::B.
I've never said to log any issues in another project's.
We're currently investigating where the problem happens.

  • What I can tell you is, that it happens if you edit several files in parallel.
It will be quite surprising if this is related to multiple files. I think the undo data structures in the editor are not shared between files - we have a wxScintilla object for every tab (if split we have two such objects).

Are you sure the lexer is set correctly. You can make .cpp/.h files to behave like plaintext files if you switch the lexer.
Title: Re: The 13 December 2020 build (12240) is out.
Post by: eckard_klotz on January 18, 2021, 05:02:56 pm
Hello oBFusCATed.

Let's skip the first point even I'm confused about. But I think at the end it is not helping anybody.

Quote
It will be quite surprising if this is related to multiple files. I think the undo data structures in the editor are not shared between files - we have a wxScintilla object for every tab (if split we have two such objects).
As I wrote at the end it happens "randomly". But I faced several times that it happens when I'm stepping back to a file I have edited some time ago.

What is with my assumption that it is associated with the age of the change I want to redo?
In the documentation of Scintilla you provided via link (in the bug-report discussion) they write "...  It will continue to collect undoable actions until memory runs out. ...". But they don't mention what happens when memory runs out.

Furthermore they write "... These transactions can be nested and only the top-level sequences are undone as units. ..."
Could it be that this nesting will be done with older undoable actions ?

Quote
Are you sure the lexer is set correctly. You can make .cpp/.h files to behave like plaintext files if you switch the lexer.
Actually I have not modified or changed the lexer. However, could you please provide some more details about the doubt you have in mind.
May be I have really modified it without noticing it.

Stay well and healthy,
                                Eckard Klotz.
Title: Re: The 13 December 2020 build (12240) is out.
Post by: oBFusCATed on January 18, 2021, 05:47:49 pm
What is with my assumption that it is associated with the age of the change I want to redo?
I doubt there is something called age in the Undo data structure, but I don't know how it works in details, so you might be correct or not. I just think that this assumption doesn't seems plausible.

In the documentation of Scintilla you provided via link (in the bug-report discussion) they write "...  It will continue to collect undoable actions until memory runs out. ...". But they don't mention what happens when memory runs out.
C::B crashes, probably.

Furthermore they write "... These transactions can be nested and only the top-level sequences are undone as units. ..."
Could it be that this nesting will be done with older undoable actions ?
This is not user visible. It is meant to group multiple actions in a single undo operation. Say you have an operation "replace all AAA with BBB", to implement it you'll do multiple scintilla actions and  if you don't group them the user would be able to (or have to) undo every single replace operation. The nesting feature allows composing operations without too much hassle and surprises (there are some places where we don't use this api and the results aren't good).

Actually I have not modified or changed the lexer. However, could you please provide some more details about the doubt you have in mind.
May be I have really modified it without noticing it.
I don't ask if you've modified the C/C++ lexer, but if you're using it or not when the bug happens. Edit -> Highlight mode or the combo in the status bar would tell you.
Title: Re: The 13 December 2020 build (12240) is out.
Post by: eckard_klotz on January 20, 2021, 05:05:32 pm
Hello oBFusCATed.

Quote
I don't ask if you've modified the C/C++ lexer, but if you're using it or not when the bug happens. Edit -> Highlight mode or the combo in the status bar would tell you.

I used in all cases the the lexer / highlight mode chosen by Code::Blocks C/Cpp.

Stay well and healthy,
                                Eckard Klotz.