Code::Blocks

User forums => Nightly builds => Topic started by: killerbot on March 09, 2019, 10:22:16 am

Title: The 09 March 2019 build (11579) is out.
Post by: killerbot 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 (http://forums.codeblocks.org/index.php/topic,3232.0.html).

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:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 09 March 2019 build (11579) is out.
Post by: Xaviou on March 09, 2019, 11:38:16 am
Hi

OS X version of this rev can be downloaded from my Google Drive (https://drive.google.com/open?id=0B2rFQ8rNHzEeN0xtU3R6emdhUWs).

Debian Stretch (32 and 64 bits) can be installed from my repo (https://wxstuff.xaviou.fr/article/debian-repository.html).

Regards
Xav'
Title: Re: The 09 March 2019 build (11579) is out.
Post by: raynebc 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?
Title: Re: The 09 March 2019 build (11579) is out.
Post by: stahta01 on March 09, 2019, 09:22:00 pm
Spellcheck not work:

Khram refuses to supply requested information.

Tim S.
Title: Re: The 09 March 2019 build (11579) is out.
Post by: BlueHazzard 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
Title: Re: The 09 March 2019 build (11579) is out.
Post by: raynebc on March 10, 2019, 12:51:06 am
Is installing Open/Libre Office the lowest effort way to get a compatible Hunspell install then?
Title: Re: The 09 March 2019 build (11579) is out.
Post by: stahta01 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= (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.
Title: Re: The 09 March 2019 build (11579) is out.
Post by: raynebc 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?
Title: Re: The 09 March 2019 build (11579) is out.
Post by: BlueHazzard 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...
Title: Re: The 09 March 2019 build (11579) is out.
Post by: raynebc 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.
Title: Re: The 09 March 2019 build (11579) is out.
Post by: sphinx66 on March 11, 2019, 05:29:09 pm
insert/refractor don't work   :'(
Title: Re: The 09 March 2019 build (11579) is out.
Post by: oBFusCATed 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.
Title: Re: The 09 March 2019 build (11579) is out.
Post by: Xaviou on March 12, 2019, 05:14:32 pm
insert/refractor don't work   :'(
Works fine for me on Windows 10 Pro 64bits.
Title: Re: The 09 March 2019 build (11579) is out.
Post by: raynebc 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.
Title: Re: The 09 March 2019 build (11579) is out.
Post by: oBFusCATed 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?
Title: Re: The 09 March 2019 build (11579) is out.
Post by: raynebc 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.
Title: Re: The 09 March 2019 build (11579) is out.
Post by: Miguel Gimenez 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.
Title: Re: The 09 March 2019 build (11579) is out.
Post by: oBFusCATed on March 13, 2019, 10:30:16 am
raynebc: What are the exact steps to reproduce the asserts? Start codeblocks from a rdesktop terminal?
Title: Re: The 09 March 2019 build (11579) is out.
Post by: raynebc 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).
Title: Re: The 09 March 2019 build (11579) is out.
Post by: oBFusCATed 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.
Title: Re: The 09 March 2019 build (11579) is out.
Post by: raynebc 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.
Title: Re: The 09 March 2019 build (11579) is out.
Post by: oBFusCATed 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...
Title: Re: The 09 March 2019 build (11579) is out.
Post by: raynebc 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.
Title: Re: The 09 March 2019 build (11579) is out.
Post by: gd_on 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
Title: Re: The 09 March 2019 build (11579) is out.
Post by: oBFusCATed 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.
Title: Re: The 09 March 2019 build (11579) is out.
Post by: raynebc 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.
Title: Re: The 09 March 2019 build (11579) is out.
Post by: oBFusCATed 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...
Title: Re: The 09 March 2019 build (11579) is out.
Post by: raynebc 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.
Title: Re: The 09 March 2019 build (11579) is out.
Post by: oBFusCATed 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)
Title: Re: The 09 March 2019 build (11579) is out.
Post by: raynebc 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
Title: Re: The 09 March 2019 build (11579) is out.
Post by: darmar 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.
Title: Re: The 09 March 2019 build (11579) is out.
Post by: dkulp 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.