Author Topic: The 09 March 2019 build (11579) is out.  (Read 7155 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5164
The 09 March 2019 build (11579) is out.
« on: March 09, 2019, 10:22:16 am »
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 : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw31u_gcc_cb_wx311_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 March 2019 build is out.
  - Windows :
   http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2019/CB_20190309_rev11579_win64.7z
  - Linux :
   none

The current SDK version is : 1.37.0

Resolved Fixed:

  • InfoWindow: Log the info message to the main log
  • CppCheck: Fix crash when the generated xml is missing (thanks blauzahn)
  • sdk: Fix memory leak when showing the "choose compiler" dialog, because the current compiler is not available
  • CC: fix #25 Casting a function call to void breaks parser
  • CC: fix SF #176 Code completion fails with enums whose underlying types
  • wxSmith: fix wxImagePanel preview error if empty image is used.
  • wxSmith: fix "dangling" frames which cause C::B process alive after C::B closed
  • CC: fix parsing of function declaration which returns enum type
  • ThreadSearch: Fix overwriting of search mask on windows (thanks Miguel Gimenez)
  • ThreadSearch: Use file filter mask for all search options, not only for search in directories
  • ThreadSearch: Use file filter mask for all search options, not only for search in directories
  • UI: Make it possible to assign a keyboard shortcut to Build -> Select target -> Select target...

Regressions/Confirmed/Annoying/Common bugs:



    Offline Xaviou

    • Regular
    • ***
    • Posts: 297
      • X@v's wxStuff
    Re: The 09 March 2019 build (11579) is out.
    « Reply #1 on: March 09, 2019, 11:38:16 am »
    Hi

    OS X version of this rev can be downloaded from my Google Drive.

    Debian Stretch (32 and 64 bits) can be installed from my repo.

    Regards
    Xav'
    « Last Edit: March 10, 2019, 05:38:33 pm by Xaviou »
    The french wxWidgets site : http://www.wxdev.fr
    My wxWidgets's stuff : https://wxstuff.xaviou.fr/

    Offline Khram

    • Multiple posting newcomer
    • *
    • Posts: 19
    • 3D-tensor mathematics - vector space
      • ShipDesign
    Re: The 09 March 2019 build (11579) is out.
    « Reply #2 on: March 09, 2019, 04:10:27 pm »
    Spellcheck not work:
    C++ & Fortran in MinGW-GCC-4.3.3 & Equation-GCC-9.1 with CB 13.12(9958)

    Offline raynebc

    • Almost regular
    • **
    • Posts: 201
    Re: The 09 March 2019 build (11579) is out.
    « Reply #3 on: March 09, 2019, 06:35:41 pm »
    It's very nice to see the void casting bug fixed in this release.  I don't immediately see that Hunspell is actually included with Firefox 65.x on Windows, it seems to ship with a different kind of dictionary as there is no dictionary folder in the browser's install folder, and nothing obviously relevant in my Firefox profile folder.  Manually installing the Hunspell dictionary plugin for Firefox (https://addons.mozilla.org/en-US/firefox/addon/us-english-dictionary/) didn't provide something that is obviously (to me) usable in C::B.  Is there some no-effort way to get the spell checker going like it was out-of-the-box in older nightly builds?

    Also, I find that when I use ALT+F, S to invoke the save function (a habit I have so I don't have to move my left hand from the home row), it saves, but it also brings up a dialog asking me to enter a name for the template.  It seems like it incorrectly invokes the "Save project as template" function in this scenario?

    Offline stahta01

    • Lives here!
    • ****
    • Posts: 6554
      • My Best Post
    Re: The 09 March 2019 build (11579) is out.
    « Reply #4 on: March 09, 2019, 09:22:00 pm »
    Spellcheck not work:

    Khram refuses to supply requested information.

    Tim S.
    « Last Edit: March 09, 2019, 09:47:34 pm by stahta01 »
    C Programmer working to learn more about C++ and Git.
    On Windows 7 64 bit and Windows 10 32 bit.
    On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
    --
    When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

    Offline BlueHazzard

    • Developer
    • Lives here!
    • *****
    • Posts: 2380
    Re: The 09 March 2019 build (11579) is out.
    « Reply #5 on: March 09, 2019, 09:38:07 pm »
    Spellcheck not work:

    Khram refuses to supply requested information.

    Tim S.

    I am working on it. He provided example files here http://forums.codeblocks.org/index.php/topic,23102.msg157663.html#msg157663
    I can reproduce the error on windows now, but it is hard for me to fix it...

    It's very nice to see the void casting bug fixed in this release.  I don't immediately see that Hunspell is actually included with Firefox 65.x on Windows, it seems to ship with a different kind of dictionary as there is no dictionary folder in the browser's install folder, and nothing obviously relevant in my Firefox profile folder.  Manually installing the Hunspell dictionary plugin for Firefox (https://addons.mozilla.org/en-US/firefox/addon/us-english-dictionary/) didn't provide something that is obviously (to me) usable in C::B.  Is there some no-effort way to get the spell checker going like it was out-of-the-box in older nightly builds?
    My codeblocks finds the dictionaries from libre office and works out of the box

    Offline raynebc

    • Almost regular
    • **
    • Posts: 201
    Re: The 09 March 2019 build (11579) is out.
    « Reply #6 on: March 10, 2019, 12:51:06 am »
    Is installing Open/Libre Office the lowest effort way to get a compatible Hunspell install then?

    Offline stahta01

    • Lives here!
    • ****
    • Posts: 6554
      • My Best Post
    Re: The 09 March 2019 build (11579) is out.
    « Reply #7 on: March 10, 2019, 01:31:12 am »
    Is installing Open/Libre Office the lowest effort way to get a compatible Hunspell install then?

    Do these directions no longer work?
    http://wiki.codeblocks.org/index.php?title=SpellChecker_plugin&plugin=

    Edit: I am guessing having "OpenOffice 4.1.5" installed is why it works for me.

    Tim S.
    « Last Edit: March 10, 2019, 01:33:28 am by stahta01 »
    C Programmer working to learn more about C++ and Git.
    On Windows 7 64 bit and Windows 10 32 bit.
    On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
    --
    When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

    Offline raynebc

    • Almost regular
    • **
    • Posts: 201
    Re: The 09 March 2019 build (11579) is out.
    « Reply #8 on: March 10, 2019, 07:46:14 am »
    Firefox (at least the version I'm using, 65.0.1) has no dictionaries folder in it's installation path.  The Hunspell page's hints about installing the dictionary via a Firefox add-on doesn't make a dictionary available for CodeBlocks's use in a way that's obvious to me.  It seems like I would need to either install some unrelated third party software or build Hunspell from source, which is certainly more involved than installing OpenOffice.  Older builds came with the spell checker built-in, is that something that's not coming back?  Will the spell checker be included by default in future full releases?

    Offline BlueHazzard

    • Developer
    • Lives here!
    • *****
    • Posts: 2380
    Re: The 09 March 2019 build (11579) is out.
    « Reply #9 on: March 10, 2019, 05:59:34 pm »
    Quote
    or build Hunspell from source
    Why would you want to build hunspell from source? The only thing you need are dictionaries. Codeblocks provides the binaries, but not the dictionaries... You can download from here https://github.com/wooorm/dictionaries , or you download the dictionary extensions from libre office or open office, extract them like a zip archive and only use the dictionaries from inside them, no need to install some office suite...

    Quote
    Will the spell checker be included by default in future full releases?
    The spell checker should be included by default (if nothing went wrong with this nightly, i did no checked it) but you have to provide the dictionary for your language, as it always was...

    Offline raynebc

    • Almost regular
    • **
    • Posts: 201
    Re: The 09 March 2019 build (11579) is out.
    « Reply #10 on: March 11, 2019, 03:01:14 pm »
    I didn't have to manually install one previously, Code::Blocks automatically selected or came with it.  When I launch C::B 17.12, the Editor options confirm that it is using the dictionary that it came with at share\codeblocks\SpellChecker.  Included in this folder is a file called "en_US.dic".  I guess I'll have this nightly use that dictionary, if you believe that will work.

    A bigger problem though is that this nightly build fails assertion and then crashes on launch if it is started during a Remote Desktop session.  A C::B session I had already opened crashed immediately after I remote desktopped into the computer.  This is a show stopper for me and I'll have to downgrade to 17.12.  I hadn't used any of the nightlies since that release, so I don't know which other nightlies may be similarly affected.  The assert message is as follows:

    ===
    A debugging check in this application has failed.

    ../../src/msw/bitmap.cpp(1346): assert "" Assert failure"" failed in GetRawData(): incorrect bitmap type in wxBitmap::GetRawData()
    ===

    If I click continue instead of stop, this alert dialog message is diplayed:
    ===
    A debugging check in this application has failed.

    ../../src/msw/bitmap.cpp(272): assert "!m_dib" failed in Free(): forgot to call wxBitmap::UngetRawData()!
    ===

    Continuing to click Continue just repeatedly alternates between these two messages, possibly indefinitely, until stop is clicked and the program is allowed to crash.
    « Last Edit: March 11, 2019, 03:14:39 pm by raynebc »

    Offline sphinx66

    • Single posting newcomer
    • *
    • Posts: 3
    Re: The 09 March 2019 build (11579) is out.
    « Reply #11 on: March 11, 2019, 05:29:09 pm »
    insert/refractor don't work   :'(

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11828
      • Travis build status
    Re: The 09 March 2019 build (11579) is out.
    « Reply #12 on: March 12, 2019, 09:22:07 am »
    Continuing to click Continue just repeatedly alternates between these two messages, possibly indefinitely, until stop is clicked and the program is allowed to crash.
    On linux there is a checkbox to ignore further asserts of this type. Isn't this the case on windows?
    Does the assert window provide a backtrace?

    There are hundreds of images in code::blocks and without more info it will be hard to find out what is going on.
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline Xaviou

    • Regular
    • ***
    • Posts: 297
      • X@v's wxStuff
    Re: The 09 March 2019 build (11579) is out.
    « Reply #13 on: March 12, 2019, 05:14:32 pm »
    insert/refractor don't work   :'(
    Works fine for me on Windows 10 Pro 64bits.
    The french wxWidgets site : http://www.wxdev.fr
    My wxWidgets's stuff : https://wxstuff.xaviou.fr/

    Offline raynebc

    • Almost regular
    • **
    • Posts: 201
    Re: The 09 March 2019 build (11579) is out.
    « Reply #14 on: March 12, 2019, 06:36:52 pm »
    There's a "don't show this dialog again" checkbox in the Windows release, I just didn't want to use that if it would suppress the message even in future launches of the program (in case I could help troubleshoot).  I found that if I did click Continue 34 times it did get into the IDE eventually.  I went into the editor settings and pointed the spell checker dictionary to the one that came with Codeblocks 17.12.  After re-launching the IDE, going back into the editor settings, selecting US English for the dictionary and clicking OK, a wxWidgets debug alert window was displayed saying:

    ===
    A debugging check in this application has failed.

    ../../src/common/wincmn.cpp(1531): asesert ""Assert failure"" failed in RemoveEventHandler(): where has the event handler gone?
    ===

    Clicking continue allows the editor dialog to close.  Going back into the spell checker settings shows that the dictionary path and language were retained.  However I can't tell that the spell checker is working.  Intentionally misspelled comments are not being underlined like older versions of CodeBlocks I've used, and there is no context menu item for the spell checker.  SpellChecker 0.1 is listed as enabled in the manage plugins dialog, and the cited DLL file exists as the listed path of share\CodeBlocks\plugins\SpellChecker.dll.

    I don't see a backtrace offered with any of the assert dialog messages I've mentioned.

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11828
      • Travis build status
    Re: The 09 March 2019 build (11579) is out.
    « Reply #15 on: March 12, 2019, 07:37:44 pm »
    There's a "don't show this dialog again" checkbox in the Windows release, I just didn't want to use that if it would suppress the message even in future launches of the program (in case I could help troubleshoot).
    This is not something that is preserved between launches.

    I found that if I did click Continue 34 times it did get into the IDE eventually.
    Can you try to disable some plugins to try to find if it is a plugin causing these asserts?
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline raynebc

    • Almost regular
    • **
    • Posts: 201
    Re: The 09 March 2019 build (11579) is out.
    « Reply #16 on: March 13, 2019, 01:31:26 am »
    I went into "Plugins>Manage plugins", selected all plugins (since all were enabled by default) and clicked Disable.  After it spent several seconds disabling them one by one, the program crashed.  I tried the process again and it crashed immediately after the dialog displays that it is disabling FortranProject.  So I decided to open C::B, disable a set of 10 plugins at a time, use "Save everything" and restart the IDE just so I could make progress.  After disabling the first couple sets this way I saw the number of failed assertion messages had decreased.  Ultimately, I found that attempting to disable the "FortranProject",  "Symbol Table Plugin" or "Thread Search" plugins (even individually) causes the IDE to immediately crash, so I skipped them.  I was able to disable all plugins other than those 3.  After doing so, I only have to click Continue 16 times to get into the IDE when I open it during a Remote Desktop session.

    Offline Miguel Gimenez

    • Regular
    • ***
    • Posts: 303
    Re: The 09 March 2019 build (11579) is out.
    « Reply #17 on: March 13, 2019, 09:22:09 am »
    The Thread Search crash is known (ticket 777) and linked to the Reopen Editor crash in ticket 807.

    The Fortran Project crash has the same origin (use-after-free), but in this case the solution is easy: remove the call to Destroy() in FortranProject::RemoveLogWindow(bool appShutDown). I will try to report this to Darmar.

    At least three plugins fail due to this use-after-free issue; Probably in old SDK code the cbEVT_REMOVE_LOG_WINDOW event didn't delete the window, but now it does and this plugins are not aware of the change.

    EDIT: I can't reproduce the Symbol Table plugin crash.
    « Last Edit: March 13, 2019, 09:36:02 am by Miguel Gimenez »

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11828
      • Travis build status
    Re: The 09 March 2019 build (11579) is out.
    « Reply #18 on: March 13, 2019, 10:30:16 am »
    raynebc: What are the exact steps to reproduce the asserts? Start codeblocks from a rdesktop terminal?
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline raynebc

    • Almost regular
    • **
    • Posts: 201
    Re: The 09 March 2019 build (11579) is out.
    « Reply #19 on: March 13, 2019, 07:29:47 pm »
    All I have to do is remote desktop from computer A to computer B, and while remotely operating computer B, launch this nightly release of Code::Blocks on computer B.  Both computers in this scenario are running Windows 7 x64 Pro, although I'm not sure if that's relevant.  Most of the time, when I run into problems with programs not working in a Remote Desktop session it's involving limitations with the session's display such as no support for hardware acceleration (Mozilla Firefox has had problems with this off and on).

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11828
      • Travis build status
    Re: The 09 March 2019 build (11579) is out.
    « Reply #20 on: March 13, 2019, 08:17:25 pm »
    Can you try older night builds and 17.12? The goal is to see if this issue is caused by the switch to wx3.1 and 64bits.
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline raynebc

    • Almost regular
    • **
    • Posts: 201
    Re: The 09 March 2019 build (11579) is out.
    « Reply #21 on: March 13, 2019, 09:09:51 pm »
    As per my previous posts, 17.12 works fine in this scenario and I am using it.  I was having trouble getting the spell checking features working when I noticed that it has to be enabled manually at the bottom right corner of the IDE, even though the plugin itself was already enabled.  After I right clicked on it and opted to "enable spell check", it worked the way I was expecting (underlines words that it doesn't recognize, has a context menu for underlined words, etc).  I'm not sure if it got turned off somehow, or one of the C::B releases eventually required turning it on manually, but I suppose I missed this step somewhere.

    When I launch the 12-9-2017 nightly (WX 303, x64), it loads without any failed asserts.

    When I launch the 4-29-2018 nightly (WX 303, x64), it loads without any failed asserts.

    When I launch the 5-10-2018 nightly (WX 311, x64), it loads with failed asserts.

    By the way, is there a way to have the spell checker plugin display a list of words in the active project that are flagged as misspelled, so I can easily look for real typos in my comments?  Manually skimming through source files one at a time isn't a good way to do this, and I have some comment typos that have been present for years mostly because I knew of no efficient way to find them.
    « Last Edit: March 13, 2019, 09:12:37 pm by raynebc »

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11828
      • Travis build status
    Re: The 09 March 2019 build (11579) is out.
    « Reply #22 on: March 13, 2019, 11:37:39 pm »
    Ok, so it seems the move to wx3.1 is causing it. Unfortunately I have no way to reproduce this, because I don't have two windows pcs...
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline raynebc

    • Almost regular
    • **
    • Posts: 201
    Re: The 09 March 2019 build (11579) is out.
    « Reply #23 on: March 14, 2019, 03:07:52 am »
    It probably mostly just matters that the remotely controlled computer is running Windows.  You could possibly use any RDP client to connect with for the sake of testing (ie. I have an RDP client on my cell phone).

    Edit:  Oddly, I RDP'd into the computer from the Android phone and launched this nightly build, and the assert messages did NOT display.  It must depend on the RDP client settings too, perhaps third party implementations manage to avoid this particular issue.
    « Last Edit: March 14, 2019, 03:22:13 am by raynebc »

    Offline gd_on

    • Regular
    • ***
    • Posts: 458
    Re: The 09 March 2019 build (11579) is out.
    « Reply #24 on: March 14, 2019, 09:37:27 am »
    Could these problems with wxAssert be linked with a change in default configuration file (config.gcc) for a msw build.
    In wx 2.8.12 we have :
    Code: [Select]
    # Should __WXDEBUG__ be defined? The default value "default" means that it will
    # be defined if BUILD=debug and not defined if BUILD=release. [0,1,default]
    DEBUG_FLAG ?= default
    In wx 3.11 (or 12) we have :
    Code: [Select]
    # Value of wxDEBUG_LEVEL. The default value is the same as 1 and means that all
    # but expensive assert checks are enabled, use 0 to completely remove debugging
    # code. [0,1,default]
    DEBUG_FLAG ?= 1
    May be for a wx release build, it should be nice to force DEBUG_FLAG=0 (or DEBUG_FLAG=default) on the build command.
    Those wxAssert are very annoying and, as far I can see, are more warnings than errors (but nevertheless, they indicate that something is not correct in the code !).
    Effectively, when you see a dialog box with such assert, you can check a box to avoid all other asserts, but it's still annoying because you have to do that each time you launch your code using wxwidgets.
    Has anybody tried such config option ?

    gd_on
    Windows 10 or 7, svn C::B (last version or almost!), WxWidgets 2.8.12, Compilers TDM 4.9.2 32 bits (gcc and gfortran installed in C:\MinGW32). Tests with C::B 64 bits and WxWidgets 2.8.12 or 3.1.2 (64 bits) compiled by TDM 4.9.2 or Std 8.1 in C:\MinGW64

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11828
      • Travis build status
    Re: The 09 March 2019 build (11579) is out.
    « Reply #25 on: March 14, 2019, 10:41:58 am »
    There is a documented way to do this for wx>=3.x. We don't do this because we want to catch as many errors as we can. And we're still in a transition period. Especially on windows. I guess we could build final releases without wx asserts, but I'd prefer if we keep the asserts in night builds.

    So if you see an assert don't hesitate to report it on the forum or the ticket page in sf.net. It is always a bug.
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline raynebc

    • Almost regular
    • **
    • Posts: 201
    Re: The 09 March 2019 build (11579) is out.
    « Reply #26 on: March 14, 2019, 06:18:09 pm »
    I've confirmed that if I RDP into the Windows computer via Android phone, launch this nightly build (it starts without any asserts), disconnect and then RDP into the Windows computer from a Windows computer, C::B immediately starts the same set of assert messages even though it was already running.  So this reaction occurs when the program detects the display has changed, and not just during launch.  After I clicked continue through the asserts, the IDE seemed to resume normal function.

    Should I put an enhancement request on the bug tracker about a way to list all words flagged by the spell checker?  Having the option to sort this list would also be very handy so I could ignore variable names and look for truly misspelled words.
    « Last Edit: March 14, 2019, 06:20:29 pm by raynebc »

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11828
      • Travis build status
    Re: The 09 March 2019 build (11579) is out.
    « Reply #27 on: March 14, 2019, 06:55:03 pm »
    Should I put an enhancement request on the bug tracker about a way to list all words flagged by the spell checker?  Having the option to sort this list would also be very handy so I could ignore variable names and look for truly misspelled words.
    Yes... But if someone would implement it is another matter...
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline raynebc

    • Almost regular
    • **
    • Posts: 201
    Re: The 09 March 2019 build (11579) is out.
    « Reply #28 on: March 14, 2019, 10:12:57 pm »
    Bummer.  Guess there's no efficient way to spell check an entire project short of feeding all of the comment lines into a word processor.

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11828
      • Travis build status
    Re: The 09 March 2019 build (11579) is out.
    « Reply #29 on: March 14, 2019, 11:55:34 pm »
    You're a programmer, you can look at the source and add the features missing in it. It is not that hard.  8)
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline raynebc

    • Almost regular
    • **
    • Posts: 201
    Re: The 09 March 2019 build (11579) is out.
    « Reply #30 on: March 16, 2019, 10:10:58 am »
    It would take me enormously longer than somebody who already has a meaningful amount of experience working with:
    1.  The Code::Blocks source code
    2.  C++
    3.  wxWidgets

    Offline darmar

    • Multiple posting newcomer
    • *
    • Posts: 57
    Re: The 09 March 2019 build (11579) is out.
    « Reply #31 on: March 16, 2019, 10:42:00 am »
    The Fortran Project crash has the same origin (use-after-free), but in this case the solution is easy: remove the call to Destroy() in FortranProject::RemoveLogWindow(bool appShutDown). I will try to report this to Darmar.

    The suggested change to FortranProject plugin was committed into the SVN.

    Offline dkulp

    • Multiple posting newcomer
    • *
    • Posts: 10
    Re: The 09 March 2019 build (11579) is out.
    « Reply #32 on: March 19, 2019, 02:50:38 pm »

    wxSmith still doesn't work on OSX Mojave.   A quick flash of the dialog and then everything turns black.  Gut feeling is something is not being double buffered correctly.