Recent Posts

Pages: 1 ... 5 6 7 8 9 [10]
91
Development / Re: Query on fixing compiler rename bug(s)
« Last post by oBFusCATed on July 11, 2021, 08:57:15 am »
Post a patch then...
92
Contributions to C::B / Re: C17 and C++20 highlighting kit
« Last post by nowhereman2 on July 11, 2021, 07:52:03 am »
Version 4
  • added [c90] for ISO C90, aka ANSI C89, aka ANSI C standard
  • added [cpp98] for ISO C++98 standard
  • [c17] updated "lib_stdlib_h.txt"
  • [c17] updated "lib_string_h.txt"
  • [cpp14] updated "lib_algorithm.txt"

Version 3
  • added [cpp14] for ISO C++14 standard
  • [cpp20] renamed "lib_coroutines.txt" to "lib_coroutine.txt" and updated script
  • [cpp20] lib_ostream: corrected "no_emit_on_flush" to "noemit_on_flush"
93
Development / Re: Query on fixing compiler rename bug(s)
« Last post by AndrewCot on July 11, 2021, 04:34:47 am »
I have looked a the copy compiler code and compared it to the rename code and narrowed the problem down the the following code not being included in the rename code as the rename works correctly with the equivalent block of code added (I added a rename function on compilerfactory.cpp similar to the existing copy function):
Code
    Compiler::m_CompilerIDs.Remove(compiler->GetID());
    compiler->SetName(newName);
    compiler->m_ID = newName;
    compiler->MakeValidID();

This code is required as the compiler->m_ID was not updated in the current rename source code, which caused the settings to be saved against the old compiler->m_ID "name". When CB is restarted the new name is used to generate a "new" compiler->m_ID, which is then used to load the settings from the default.conf file, but in the case I found there will be no entries and therefore the masterpath is blank (and so are all of the other settings BTW). Ouch!!!!

Looks like the rename is either not used or if it is used then other settings are updated that cause the compiler->m_ID to be updated and therefore the renamed compiler is correctly saved in the default.conf and on a restart the auto-detect is not shown.
94
Development / Re: Query on fixing compiler rename bug(s)
« Last post by AndrewCot on July 11, 2021, 02:00:14 am »
I have not debugged the exact cause as to see where the problem is as I need to first go through the copy code to see what it is doing and then through the rename code to see what it is not doing or doing differently compared to the copy code in order to find the problem or process that is wrong.

I was able to reproduce the issue with the last nightly SVN 1247 on Linux Mint 20.2. Let me be a bit more explicit with the instructions as it is vital that you do make any changes that cause the dirty flag to be set or the auto-detect to be triggered:
  • Select the "GNU GCC Compiler" in the compiler settings
  • Click on the "Copy" button
  • Click on the "Ok" button to add the new compiler
  • Click on the "Ok" button for the check toolchain executables exclamation info dialog
  • Click on the "Rename" button
  • Change the name to "test"
  • Click on the "Ok" button to save and close the rename dialog
  • Click on the "Ok" button to close the compiler dialog
  • Close CB via the [X] on the top right of the app
  • Run CB again.
  • Select ok on the auto detect dialog.   (BTW try to figure out why the auto-detection is being displayed with the info shown)
  • Open the compilers dialog
  • Select the "test"
  • Select the "Toolchain executables" tab and the path is blank!!!

Attached is a an image showing the symptom of the problem with the current SVN 12487 and a local build with the ticket 1117 auto-detection dialog changes that show the real reason the auto-detection dialog is shown ("User-defined masterpath issue")

If you exit Cb before renaming the copied compiler then on next CB startup the compiler is configured as you would expect.
95
Development / Re: Query on fixing compiler rename bug(s)
« Last post by oBFusCATed on July 10, 2021, 10:26:18 am »
Step 6 for me doesn't happen on linux.
My version of C::B doesn't popup the auto-detect dialog and everything works as expected.
At least the compiler's installation directory is correct.

Have you debugged what is the actual problem?
96
Development / Query on fixing compiler rename bug(s)
« Last post by AndrewCot on July 10, 2021, 10:12:01 am »
When I rename compiler in the SVN 12487 and by the looks earlier releases it will result in a compiler configuration that has at least a blank masterpath setting. This can be seen if you do the following:
1) Make a copy of the "GNU GCC Compiler"
2) Rename the "Copy of GNU GCC Compiler" to say "test"
3) Close the compiler dialog
4) Exit CB
5) Load CB.
6) Select ok on the auto detect dialog.
7) Open the compilers dialog
8) Select the "test"
9) Select the "Toolchain executables" tab and the path is blank!!!

I would like to fix this while making other changes in the compilerioptionsdlg.cpp file, but there may be a number of ways to fix this and as such I would like to find out if the following would be acceptable as a fix before I start making changes, but if it not okay please let me know another way that would be acceptable that I can look at to implement:
1) Keep the exiting new name request GUI
2) Use the existing copy functionality to make a copy with the new name with the GUI name request disabled
3) Delete the old compiler name using the existing delete functionality  with the delete configuration disabled
97
Nightly builds / Re: The 09 July 2021 build (12487) is out.
« Last post by AndrewCot on July 10, 2021, 06:40:26 am »
Thanks oBFusCATed for doing the updated Ubuntu releases. BTW It took a number of hours for the builds to finish and the files to appear.

Thanks Pecan for the assert fix as this nightly release has fixed the wxWidget assert startup issue I reported in the previous nightly release (SVN 12483). I upgraded my Linux Mint 20.2 guest OS to the the Ubuntu 20.04 SVN 12487 release and it starts without any asserts.  I manually upgraded my XUbuntu 20.04 guest and it also started without any asserts.
98
Nightly builds / Re: The 09 July 2021 build (12487) is out.
« Last post by oBFusCATed on July 10, 2021, 01:31:31 am »
99
Nightly builds / The 09 July 2021 build (12487) is out.
« Last post by killerbot on July 09, 2021, 10:47:30 pm »
We switched to wx 3.1.5 --> download the new wx dll's see link below

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/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 09 July 2021 build is out.
  - Windows :
   http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2021/CB_20210709_rev12487_win64.7z
  - Linux :
   none

The current SDK version is : 2.11.0

Resolved Fixed:

  • debugger: Better parsing the threads list from CDB (ticket #1060, thanks maras420)
  • SDK: Fix compiler warning
  • logger: Scroll to the end of log control if a new message is added (ticket #1092)

Regressions/Confirmed/Annoying/Common bugs:


    100
    Thanks, I can now reduce the list to remove compilers that are not of interest to me.

    (Until the next release  ;) )

    It is impressive to have such a lot of compilers on offer (and the ability to add new one reasonably easily) but would be nice to be able to put aside 'uninteresting' compilers into a 'saved' folder.  I'll leave that for the experts to ponder.

    Meanwhile many thanks.
    Pages: 1 ... 5 6 7 8 9 [10]