Code::Blocks

User forums => Nightly builds => Topic started by: killerbot on October 28, 2014, 01:16:20 pm

Title: The 27 October 2014 build (10016) is out.
Post by: killerbot on October 28, 2014, 01:16:20 pm
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 for Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw28u_gcc_cb_wx2812_gcc481-TDM.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/mingwm10_gcc481-TDM.7z

The 27 October 2014 build is out.
  - Windows :
   http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2014/CB_20141027_rev10016_win32.7z
  - Linux :
   none

Resolved Fixed:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 27 October 2014 build (10016) is out.
Post by: jens on October 28, 2014, 03:46:56 pm
No update of Fedora or Dedbian packages possible until end of next week, sorry.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: arprog on October 28, 2014, 05:36:48 pm
Option "Collect defines from project file" not working if project generated by cmake (13.12 - nightly)
Title: Re: The 27 October 2014 build (10016) is out.
Post by: shurick on October 28, 2014, 05:47:52 pm
Packages for openSUSE (http://codeblocks.esy.es) (binaries and sources) for 32-bit and 64-bit.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: stahta01 on October 28, 2014, 06:32:55 pm
Option "Collect defines from project file" not working if project generated by cmake (13.12 - nightly)

Is it a "custom makefile" project or a normal CB project?
What version of CMake?
Edit2: What compiler is the project using?

Edit: Do you have "interpret #if, #else ..." checked?

From EditorManager::CollectDefines function in editormanager.cpp;
The function appears to require then both to be checked.  

Tim S.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: arprog on October 28, 2014, 10:27:39 pm
Option "Collect defines from project file" not working if project generated by cmake (13.12 - nightly)

Is it a "custom makefile" project or a normal CB project?
What version of CMake?
Edit2: What compiler is the project using?

Edit: Do you have "interpret #if, #else ..." checked?

From EditorManager::CollectDefines function in editormanager.cpp;
The function appears to require then both to be checked.  

Tim S.


"interpret #if, #else ..." checked
cmake 3.0.2
mingw-w64 4.9.1
cmd: cmake -G "CodeBlocks - MinGW Makefiles"
cmake generates custom makefile project
Title: Re: The 27 October 2014 build (10016) is out.
Post by: stahta01 on October 29, 2014, 01:35:51 am
Option "Collect defines from project file" not working if project generated by cmake (13.12 - nightly)

Is it a "custom makefile" project or a normal CB project?
What version of CMake?
Edit2: What compiler is the project using?

Edit: Do you have "interpret #if, #else ..." checked?

From EditorManager::CollectDefines function in editormanager.cpp;
The function appears to require then both to be checked.  

Tim S.


"interpret #if, #else ..." checked
cmake 3.0.2
mingw-w64 4.9.1
cmd: cmake -G "CodeBlocks - MinGW Makefiles"
cmake generates custom makefile project

FYI: Code::Blocks does NOT look into the makefile when a custom makefile is used; it only looks at the setting in the cbp file.
But, if you disable the "custom makefile" for a short time and add the defines to the correct target/project level.
Change it back to "custom makefile"; then change the project target to be built; it will grey in/out the blocks based on the defines in the CB Project. Note: It really ignores those defines in most other uses of building the project.

Tested using wxThings created project from wxCode.
cmake 3.0.2 Used the GUI tool.

Tim S.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: arprog on October 29, 2014, 03:00:23 pm
In generated cbp, defines present...
Title: Re: The 27 October 2014 build (10016) is out.
Post by: stahta01 on October 29, 2014, 03:20:10 pm
In generated cbp, defines present...

Start a new thread for your problem; and post a link to your cbp file.

Tim S.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: arprog on October 29, 2014, 11:04:08 pm
I found!
By default selected virtual target "all", if i select my subproject works fine.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: oBFusCATed on October 30, 2014, 08:22:40 pm
@ollydbg:
I've tried to upgrade to 10016, but there was a massive problem with code completion - it ran until it depleted all my memory (12g+4g swap)...
I've no time to debug why it breaks such badly, but reverting to 9990 fixed the problem... at least it didn't repeat the whole day.

Centos 6 64bit...
Title: Re: The 27 October 2014 build (10016) is out.
Post by: ollydbg on October 30, 2014, 11:48:36 pm
But I cant reproduce, I will check all the changed code.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: oBFusCATed on October 31, 2014, 12:09:57 am
Of course you won't be able to reproduce it, you need the special pattern of code that breaks it...
I don't know what breaks it and I doubt I have the time to find it.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: ollydbg on October 31, 2014, 09:57:15 am
I have a question that I want to install C::B to a Linux(ubuntu10.04 in virtualbox), I just follow the instruction here:
http://apt.jenslody.de/
As jens suggest ubuntu user should try pasgui's ppa (https://launchpad.net/~pasgui/+archive/ppa/). I have correctly configure the apt, like:Read about installing (https://launchpad.net/+help-soyuz/ppa-sources-list.html)
Code: [Select]
sudo add-apt-repository ppa:pasgui/ppa
and Then
Code: [Select]
sudo apt-get update
From Ubuntu10.04's synaptic package manager, I still see the old C::B 8.02 supply from the official ubuntu, but the nightly build version of pasgui does not shown up.

Any idea how to fix this issue? What is the minimal system requirement of pasgui's nightly build binaries? Thanks.

BTW: I have also try jens' repo before, but it has the same issue: I still don't see any nightly build version of C::B show in the synaptic package manager.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: scarphin on October 31, 2014, 10:35:09 am
Do you see the nightly version with the search command or the like?
Code: [Select]
apt-cache search codeblocks
Title: Re: The 27 October 2014 build (10016) is out.
Post by: Alpha on October 31, 2014, 05:18:08 pm
From Ubuntu10.04's synaptic package manager, I still see the old C::B 8.02 supply from the official ubuntu, but the nightly build version of pasgui does not shown up.
That one only has builds for Ubuntu 14.04, try https://launchpad.net/~damien-moore/+archive/ubuntu/codeblocks (https://launchpad.net/~damien-moore/+archive/ubuntu/codeblocks) (and/or a newer version of Ubuntu).
Title: Re: The 27 October 2014 build (10016) is out.
Post by: oBFusCATed on November 01, 2014, 05:37:40 pm
@ollydbg:
I had the same problem with 9990.
It happens only if a specific project is selected in the workspace.
If another project is selected as default project the problem doesn't happen.
I've used only rev 9855 before 9990 and 10016.

Here is a backtrace (incomplete) when the problem happened
Code: [Select]
(gdb) bt
#0  0x00007f6a88222bd5 in TokenTree::TokenExists(wxString const&, int, short) () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#1  0x00007f6a8821fd2b in Tokenizer::GetReplacedToken(wxString&) () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#2  0x00007f6a882203a6 in Tokenizer::DoGetToken() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#3  0x00007f6a8821fd84 in Tokenizer::GetReplacedToken(wxString&) () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#4  0x00007f6a882203a6 in Tokenizer::DoGetToken() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#5  0x00007f6a8821fd84 in Tokenizer::GetReplacedToken(wxString&) () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#6  0x00007f6a882203a6 in Tokenizer::DoGetToken() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#7  0x00007f6a8821fd84 in Tokenizer::GetReplacedToken(wxString&) () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#8  0x00007f6a882203a6 in Tokenizer::DoGetToken() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#9  0x00007f6a8821fd84 in Tokenizer::GetReplacedToken(wxString&) () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#10 0x00007f6a882203a6 in Tokenizer::DoGetToken() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#11 0x00007f6a8821fd84 in Tokenizer::GetReplacedToken(wxString&) () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#12 0x00007f6a882203a6 in Tokenizer::DoGetToken() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#13 0x00007f6a8821fd84 in Tokenizer::GetReplacedToken(wxString&) () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#14 0x00007f6a882203a6 in Tokenizer::DoGetToken() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#15 0x00007f6a8821fd84 in Tokenizer::GetReplacedToken(wxString&) () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#16 0x00007f6a882203a6 in Tokenizer::DoGetToken() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#17 0x00007f6a88222464 in Tokenizer::GetToken() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#18 0x00007f6a88213899 in ParserThread::DoParse() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#19 0x00007f6a88216ec9 in ParserThread::HandleClass(ParserThread::EClassType) () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#20 0x00007f6a88215a90 in ParserThread::DoParse() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#21 0x00007f6a8821a79e in ParserThread::Parse() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#22 0x00007f6a88203769 in Parser::Parse(wxString const&, bool, bool) () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#23 0x00007f6a8820d197 in ParserThread::HandleIncludes() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#24 0x00007f6a88216905 in ParserThread::DoParse() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#25 0x00007f6a8821a79e in ParserThread::Parse() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#26 0x00007f6a88203769 in Parser::Parse(wxString const&, bool, bool) () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#27 0x00007f6a8820d197 in ParserThread::HandleIncludes() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#28 0x00007f6a88216905 in ParserThread::DoParse() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#29 0x00007f6a8821a79e in ParserThread::Parse() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#30 0x00007f6a8821b219 in ParserThread::Execute() () from /usr/lib64/codeblocks/plugins/libcodecompletion.so
#31 0x00007f6aa06b1b35 in cbThreadPool::cbWorkerThread::Entry() () from /usr/lib64/libcodeblocks.so.0
#32 0x0000003073ae7021 in wxThreadInternal::PthreadStart(wxThread*) () from /usr/lib64/libwx_baseu-2.8.so.0
#33 0x00000030692079d1 in start_thread () from /lib64/libpthread.so.0
#34 0x0000003068ae886d in clone () from /lib64/libc.so.6
Title: Re: The 27 October 2014 build (10016) is out.
Post by: oBFusCATed on November 01, 2014, 09:59:38 pm
Another problem that is extremely annoying is that the value of the "Case sensitive matches" in the code completion settings is not save in the config file.
And I have to set it every time I start new instance of codeblocks.
Also why this is set to the non-obvious state on, I think this should be off by default.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: ollydbg on November 02, 2014, 09:20:52 am
Do you see the nightly version with the search command or the like?
Code: [Select]
apt-cache search codeblocks
Hi, thanks, here are the logs, but it looks like Alpha is correct, those binaries need a newer Ubuntu. Here is the failure log in Ubuntu10.04, I finally see the codeblocks nightly svn10016 in synaptic package manager, but installation get failed.

Quote
apt-cache search codeblocks
libcodeblocks0 - Code::Blocks shared libraries
codeblocks - Code::Blocks integrated development environment (IDE)
codeblocks-dbg - Code::Blocks debugging libraries
codeblocks-contrib - contrib plugins for Code::Blocks IDE
codeblocks-dev - Code::Blocks development libraries (SDK)
codeblocks-contrib-dbg - Debugging libraries for the Code::Blocks contrib plugins
codeblocks-common - common files for Code::Blocks IDE
codeblocks-contrib-common - common files for the contrib plugins for Code::Blocks IDE
codeblocks-headers - Code::Blocks development headers (SDK)
codeblocks-fr - French translation for codeblocks
codeblocks-wxcontrib-headers - Code::Blocks development headers for wxContribItems
codeblocks-libwxcontrib0 - Code::Blocks shared libraries for wxContribItems
codeblocks-wxcontrib-dev - Code::Blocks development libraries for wxContribItems
libpath-dispatcher-perl - flexible and extensible command-line dispatch for Perl programs





apt-cache showpkg codeblocks
Package: codeblocks
Versions:
13.12svn10016-0ubuntu1~trusty (/var/lib/apt/lists/ppa.launchpad.net_pasgui_ppa_ubuntu_dists_trusty_main_binary-i386_Packages)
 Description Language:
                 File: /var/lib/apt/lists/ppa.launchpad.net_pasgui_ppa_ubuntu_dists_trusty_main_binary-i386_Packages
                  MD5: d79be8ed08e6a743818b1212de720d34

8.02-0ubuntu4 (/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_lucid_universe_binary-i386_Packages)
 Description Language:
                 File: /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_lucid_universe_binary-i386_Packages
                  MD5: 23f14fed420b36ac3f02ca22fe86384e


Reverse Depends:
  codeblocks-contrib,codeblocks 10.05svn7965-1
  libcodeblocks0,codeblocks
  libwxsmithlib0,codeblocks
  libcodeblocks0,codeblocks
  codeblocks-dbg,codeblocks 8.02-0ubuntu4
  codeblocks-contrib,codeblocks
  codeblocks-fr,codeblocks
  codeblocks-common,codeblocks 13.12svn10016-0ubuntu1~trusty
  codeblocks-common,codeblocks 13.12svn10016-0ubuntu1~trusty
  codeblocks-contrib,codeblocks 13.12svn10016-0ubuntu1~trusty
  codeblocks-dbg,codeblocks 13.12svn10016-0ubuntu1~trusty
  libcodeblocks0,codeblocks
Dependencies:
13.12svn10016-0ubuntu1~trusty - libc6 (2 2.4) libcodeblocks0 (5 13.12svn10016-0ubuntu1~trusty) libgcc1 (2 1:4.1.1) libglib2.0-0 (2 2.12.0) libgtk2.0-0 (2 2.8.0) libstdc++6 (2 4.6) libwxbase2.8-0 (2 2.8.12.1+dfsg) libwxgtk2.8-0 (2 2.8.12.1+dfsg) codeblocks-common (5 13.12svn10016-0ubuntu1~trusty) xterm (0 (null)) libwxgtk2.8-dev (0 (null)) wx-common (0 (null)) codeblocks-contrib (0 (null)) gcc (16 (null)) g++ (0 (null)) gdb (0 (null))
8.02-0ubuntu4 - libcodeblocks0 (0 (null)) libatk1.0-0 (2 1.20.0) libc6 (2 2.7) libcairo2 (2 1.2.4) libfontconfig1 (2 2.4.0) libfreetype6 (2 2.2.1) libgcc1 (2 1:4.1.1) libglib2.0-0 (2 2.12.0) libgtk2.0-0 (2 2.17.11) libpango1.0-0 (2 1.14.0) libstdc++6 (2 4.1.1) libwxbase2.8-0 (2 2.8.10.1) libwxgtk2.8-0 (2 2.8.10.1) libx11-6 (0 (null)) zlib1g (2 1:1.1.4) libwxgtk2.8-dev (0 (null)) wx-common (0 (null)) codeblocks-contrib (0 (null)) gcc (16 (null)) g++ (0 (null)) gdb (0 (null)) xterm (0 (null))
Provides:
13.12svn10016-0ubuntu1~trusty -
8.02-0ubuntu4 -
Reverse Provides:


apt-get install codeblocks
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
  codeblocks: Depends: libcodeblocks0 (= 13.12svn10016-0ubuntu1~trusty) but 10.05svn7965-1 is to be installed
              Depends: libwxbase2.8-0 (>= 2.8.12.1+dfsg) but 2.8.12.1-0 is to be installed
              Depends: libwxgtk2.8-0 (>= 2.8.12.1+dfsg) but 2.8.12.1-0 is to be installed
E: Broken packages


From Ubuntu10.04's synaptic package manager, I still see the old C::B 8.02 supply from the official ubuntu, but the nightly build version of pasgui does not shown up.
That one only has builds for Ubuntu 14.04, try https://launchpad.net/~damien-moore/+archive/ubuntu/codeblocks (https://launchpad.net/~damien-moore/+archive/ubuntu/codeblocks) (and/or a newer version of Ubuntu).
I have just installed Ubuntu 14.10, and it works now, thanks!
Title: Re: The 27 October 2014 build (10016) is out.
Post by: ollydbg on November 02, 2014, 09:56:15 am
@ollydbg:
I had the same problem with 9990.
It happens only if a specific project is selected in the workspace.
If another project is selected as default project the problem doesn't happen.
I've used only rev 9855 before 9990 and 10016.

Here is a backtrace (incomplete) when the problem happened
...
It crashed when parsing class definition body, and I see macro expansion happens several times, but finally it crashed in m_TokenTree->TokenExists. If I see the crash in my system, I can debug it. But currently I can't.

Another problem that is extremely annoying is that the value of the "Case sensitive matches" in the code completion settings is not save in the config file.
And I have to set it every time I start new instance of codeblocks.
Also why this is set to the non-obvious state on, I think this should be off by default.

It's a bug.
I did some test, if you open C::B (without opening any project), and just set the "Case sensitive matches", and close C::B, you will see those settings get saved.
But if you open C::B, and open one project, then set the "Case sensitive matches" option, and this options gets lost if you close C::B.
I will look into this.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: oBFusCATed on November 02, 2014, 12:31:21 pm
It crashed when parsing class definition body, and I see macro expansion happens several times, but finally it crashed in m_TokenTree->TokenExists. If I see the crash in my system, I can debug it. But currently I can't.
This is not a crash, I've just stopped it to see what is doing.
It doesn't crash but what happens is probably that it enters an infinite loop of macro expansion.
I'll try to see if this is related to a single project or the order of evaluation of project breaks it.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: ollydbg on November 02, 2014, 03:04:17 pm

Another problem that is extremely annoying is that the value of the "Case sensitive matches" in the code completion settings is not save in the config file.
And I have to set it every time I start new instance of codeblocks.
Also why this is set to the non-obvious state on, I think this should be off by default.

It's a bug.
I did some test, if you open C::B (without opening any project), and just set the "Case sensitive matches", and close C::B, you will see those settings get saved.
But if you open C::B, and open one project, then set the "Case sensitive matches" option, and this options gets lost if you close C::B.
I will look into this.

Debugged a while, I found the reason why this bug happens, but I don't have a clean way to fix this issue.
See, the CC setting was stored in configure file.
When C::B start up, CC will create a default parser object called "temp parser".
When a parser object is created, it will copy the settings(such as the "Case sensitive matches") from the configure file to its own member variable.
When you open the CC dialog, the active parser object's setting will be modified also the CC related setting in configure files will get updated. This means, the configure file contains the active parser's settings.

When a CB project loaded, a new parser object(we call "new parser" here) is created and activated. So far, so good. When you changed the CC setting, both the "new parser"'s setting and the configure file get updated.

The issue comes when you close C::B, which means, you need to
1, destroy "new parser"
2, destroy "temp parser"

When destroy "new parser", all its setting was saved, but after that, the active parser switches to "temp parser", the setting in "temp parser" was active, and finally the "temp parser" get destroyed, its setting was saved (not the "new parser"), so your setting was lost!

I have not a good idea to fix this issue. Say, we have a setting shared by several parser objects. But they may be different, but the last destroyed parser's setting will be saved to the configure file.


Title: Re: The 27 October 2014 build (10016) is out.
Post by: oBFusCATed on November 03, 2014, 12:13:28 am
Just add a flag to the temp parser and prevent it from saving its settings.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: pluto on November 03, 2014, 12:43:47 am
Hi :)
I've found some small issues that have been present for a few builds now. I'm currently using the build 10016 on Windows 7 32bit.
I'm not sure I should open tickets on SF for any these things. If I have, just tell me. I don't want to waste anyone's time :p

1) The Code Completion option "display info when hovering mouse over a token in the editor" is always active.
Even when uncheckd, it shows a tooltip. Plus it has wrong colors.
(http://s25.postimg.org/72xomhur3/cbcc1.png)
Ticketed here: https://sourceforge.net/p/codeblocks/tickets/88/ (https://sourceforge.net/p/codeblocks/tickets/88/)

2) The mouse cursor on the left margin is not mirrored or showing the left-to-right arrow. In older versions of CB it worked like that if I'm not mistaken.

3) If I put the focus on one of the dockable windows (while docked), its titlebar changes to the focused color, and that's correct.
If then I click in the editor, the cursor shows up in the editor and I can type fine, but the docked titlebar still has the focused color. To get the unfocused color I have to click on the editor tab.
I don't know if it's simply a color problem or there is some orphan window selection of sorts.

4) I use a dark theme in Windows, and so it's very visible where CB mixes system colors with custom ones, and it's very unreadable ;p
here some examples (hope they show correctly):

(http://s25.postimg.org/i57cyoe7j/cbdark1.png)

(http://s25.postimg.org/76w3ghpm7/cbdark2.png)

(http://s25.postimg.org/8n7lymsj3/cbdark3.png)

(http://s25.postimg.org/r420pg8hb/cbdark4.png)

(http://s25.postimg.org/s18fybjzj/cbdark5.png)

(http://s25.postimg.org/5voc80u0f/cbdark6.png)

5) The key bindings for the split and unsplit are missing

Thanks for reading :)

Title: Re: The 27 October 2014 build (10016) is out.
Post by: ollydbg on November 03, 2014, 06:25:10 am
Just add a flag to the temp parser and prevent it from saving its settings.
Yes can be done easily, but cause another issue. If a user open C::B (with out any C::B project opened), and change some CC settings, those settings also get unsaved. :(
Title: Re: The 27 October 2014 build (10016) is out.
Post by: ollydbg on November 03, 2014, 06:31:13 am
1) The Code Completion option "display info when hovering mouse over a token in the editor" is always active.
Even when uncheckd, it shows a tooltip.
I can confirm it, please report it in Sourceforge, thanks.
BTW: I think it is related to this post: Re: code completion settings do not take effect. (http://forums.codeblocks.org/index.php/topic,19732.msg134750.html#msg134750), it is related to ccmanager refactoring.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: oBFusCATed on November 03, 2014, 12:11:11 pm
This is not a crash, I've just stopped it to see what is doing.
It doesn't crash but what happens is probably that it enters an infinite loop of macro expansion.
I'll try to see if this is related to a single project or the order of evaluation of project breaks it.
@ollydbg: Can you guide me where to add logging, so I can try which file causes the problem?

I have multiple projects in a workspace and it is not a single project that causes it :(
I've in fact found the to projects that cause the problem and it is 100% reproducible. And of course I cannot share them. :(

edit: rev 9855 doesn't exhibit the same problem.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: ollydbg on November 03, 2014, 02:40:33 pm
This is not a crash, I've just stopped it to see what is doing.
It doesn't crash but what happens is probably that it enters an infinite loop of macro expansion.
I'll try to see if this is related to a single project or the order of evaluation of project breaks it.
@ollydbg: Can you guide me where to add logging, so I can try which file causes the problem?

I have multiple projects in a workspace and it is not a single project that causes it :(
I've in fact found the to projects that cause the problem and it is 100% reproducible. And of course I cannot share them. :(
Look at the file Parserthread.cpp, there is a line
Code: [Select]
#define CC_PARSERTHREAD_DEBUG_OUTPUT 0You can change it to
Code: [Select]
#define CC_PARSERTHREAD_DEBUG_OUTPUT 1Now, you enable the log message in Parserthread.cpp.
The log messages are default to go in the "Code::Blocks Debug log" panel if you pass "--debug-log" when C::B started, you can redirect them to a file by using some option like:"--debug-log-to-file". Maybe, if you don't pass those options, the debug log messages will be shown in the terminal under Linux.

You can also enable the log message in Parser.cpp(by setting CC_PARSER_DEBUG_OUTPUT to 1) and Tokenizer.cpp(by setting CC_TOKENIZER_DEBUG_OUTPUT to 1) if you still don't find hang reason, but mostly I think only log messages in Parserthread.cpp is enough.

Quote
edit: rev 9855 doesn't exhibit the same problem.
I will exam all the related changed after this revision.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: oBFusCATed on November 03, 2014, 05:37:29 pm
@ollydbg: I've done some bisecting and r9931 seems to be the last working revision. r9932 is broken.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: scarphin on November 04, 2014, 04:20:14 pm
My keyboard shortcuts for 'debugging windows' (namely 'alt-shift-x' where x is a digit between 0 and 9) doesn't work after I load a project. Although they are unchanged in the 'cbKeyBinder10.ini', they are not listed in settings->editor->keyboard shortcuts-> corresponding entries nor do they work. Even when I load a modified codeblocks.cbp project file, 'cbKeyBinder10.ini' changes with all the targets added to the file and 'debugging windows' shortcuts gone. I attached a zip containing 2 'cbkeybinder10.ini' files, one before any project loaded and one after codeblocks.cbp loaded. Also what is the .bak file used for?

Btw is there a way to prevent editor from editing while debugging? I often find myself trying to edit the code during a debugging session which is very frustrating. ;)

Win7 x64 SP1
Title: Re: The 27 October 2014 build (10016) is out.
Post by: Pecan on November 05, 2014, 07:54:29 pm
I made some changes on 10/29/2014 that might fix this.
Either update your svn or wait for the next nightly.

Please let us know if the 10/29 revert fixes the problem.

What version of CB (before 10/27) worked for you?

In, any case, I'll look into it.

Could you give me the exact steps to cause the problem.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: scarphin on November 06, 2014, 12:22:18 am
svn rev 10020 still exhibits the same problem. Unfortunately I couldn't find a working build after checking all the nightlies I have (back to rev 9673).

Steps to reproduce:
1- Launch cb, see the 'debugging windows' bindings are there before loading a project,
2- Load a project,
3- Check again to see the bindings are gone.

Some older revisions doesn't change 'cbkeybinder10.ini' file after closing cb even though the bindings are not listed on the shortcuts dialog, they don't work either. But latest nightlies change the file to add the targets of the opened project.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: gd_on on November 06, 2014, 02:47:24 pm
There is a side effect problem introduced in autorevision.cpp in svn 10011.
I have a unix machine which does not have access to internet. The file autorevision.h has been correctly set on another one, and I copy it (with many others !) on this isolated unix machine.
But when I build C::B on this isolated machine, autorevision.h is modified by the task autorevision with a svn number 0, an unknown date ....
If I reset the test at line 240 with >= as it was before svn 10011, my autorevision.h file is not modified, and it's what I need on this isolated machine.

gd_on
Title: Re: The 27 October 2014 build (10016) is out.
Post by: oBFusCATed on November 06, 2014, 03:16:15 pm
I can confirm this issue, either building from a git checkout or using release tar.bz2 file generated with make dist results in "svn 0" in the splashscreen.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: gd_on on November 06, 2014, 04:31:06 pm
Also, bugs in BrowseTracker_wx30.cbp and BrowseTracker_wx30_64.cbp.
ExtraCommands add manifest.xml, the folder images and a .xrc file in /devel... It should be, I think, respectively in /devel30... and /devel30_64...
With those corrections, BrowseTracker toolbar is correct. As it was, it's a too large and empty toolbar.

gd_on
Title: Re: The 27 October 2014 build (10016) is out.
Post by: Alpha on November 06, 2014, 07:53:11 pm
Does this work better?
Code: [Select]
diff --git a/src/build_tools/autorevision/autorevision.cpp b/src/build_tools/autorevision/autorevision.cpp
index b0220b6..514ebd7 100644
--- a/src/build_tools/autorevision/autorevision.cpp
+++ b/src/build_tools/autorevision/autorevision.cpp
@@ -227,17 +227,17 @@ bool QuerySvn(const string& workingDir, string& revision, string &date)
 
 bool WriteOutput(const string& outputFile, string& revision, string& date)
 {
-    string old;
-    string comment("/*");
-    comment.append(revision);
-    comment.append("*/");
-
     {
         ifstream in(outputFile.c_str());
         if (!in.bad() && !in.eof())
         {
+            string old;
             in >> old;
-            if(old == comment)
+            int oldRev = 0;
+            size_t pos = old.find('*');
+            if (pos != string::npos)
+                oldRev = atoi(old.c_str() + pos + 1);
+            if(oldRev >= atoi(revision.c_str()))
             {
                 if(be_verbose)
                     printf("Revision unchanged (%s). Skipping.", revision.c_str());
@@ -256,7 +256,7 @@ bool WriteOutput(const string& outputFile, string& revision, string& date)
         return false;
     }
 
-    fprintf(header, "%s\n", comment.c_str());
+    fprintf(header, "/*%s*/\n", revision.c_str());
     fprintf(header, "//don't include this header, only configmanager-revision.cpp should do this.\n");
     fprintf(header, "#ifndef AUTOREVISION_H\n");
     fprintf(header, "#define AUTOREVISION_H\n\n\n");
Title: Re: The 27 October 2014 build (10016) is out.
Post by: jens on November 06, 2014, 10:29:53 pm
Same effect with less conversion, even if it should not matter much as it happens only one time:
Code: [Select]
commit e2e7ed0e50fc1843cb0ae77cafd82f07305695cb
Author: Jens Lody <jens@codeblocks.org>
Date:   Thu Nov 6 22:26:28 2014 +0100

    * fix for commit 10011, which could lead to revision string "0"

Index: src/build_tools/autorevision/autorevision.cpp
===================================================================
--- src/build_tools/autorevision/autorevision.cpp
+++ src/build_tools/autorevision/autorevision.cpp
@@ -237,10 +237,12 @@
         if (!in.bad() && !in.eof())
         {
             in >> old;
-            if(old == comment)
+            size_t l_old = old.length();
+            size_t l_comment = comment.length();
+            if(l_old > l_comment || ((l_old == l_comment) && old >= comment))
             {
                 if(be_verbose)
-                    printf("Revision unchanged (%s). Skipping.", revision.c_str());
+                    printf("Revision unchanged or older (%s). Skipping.", revision.c_str());
                 in.close();
                 return false;
             }
Title: Re: The 27 October 2014 build (10016) is out.
Post by: oBFusCATed on November 07, 2014, 12:28:14 am
@gd_on: the two patches are in svn now...
Title: Re: The 27 October 2014 build (10016) is out.
Post by: ollydbg on November 07, 2014, 09:08:58 am
@ollydbg: I've done some bisecting and r9931 seems to be the last working revision. r9932 is broken.
I still can't reproduce the issue in my system. :'(
As a workaround, you can just try to comment out the line "HandleMacroExpansion(id, peek);", thus disable the macro expansion for the first meet token, and see whether the issue happens again.
I have a local patch which only handles macro expansion in the Tokenizer level(low level), but not in the ParserThread level(high level), but that involves too many code changes......
Title: Re: The 27 October 2014 build (10016) is out.
Post by: gd_on on November 07, 2014, 09:20:36 am
@oBFusCATed : Thanks
@jens and Alpha : I tried your two patches. Both give me the "good" result on the isolated machine : svn number not modified in my autorevision.h file and this is what I expected.
So, it's up to you to choose which one is better than the other. May be jens's one is a little bit shorter... and less conversion.

gd_on
Title: Re: The 27 October 2014 build (10016) is out.
Post by: Alpha on November 07, 2014, 04:15:26 pm
@jens, less work is generally better; go ahead and commit.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: jens on November 07, 2014, 08:35:27 pm
@jens, less work is generally better; go ahead and commit.
In svn (r10029).
I build the new revision and try to upload it, but it might not be possible before monday, because my provider will switch internet off this night (don't know the exact time) and I will not have any internet access until monday (at least).
Title: Auto-generated files path are not used when added to project
Post by: wab on November 10, 2014, 02:27:31 pm
I found a tiny bug, or non finished functionality.

Settings -> Compiler... -> Global Compiler Settings -> Other Settings -> Advanced Options... -> Commands:

1. Add new "Source ext.": ui
2. Field "Command" stay on "Compile single file to object file"
3. "Command line macro": $(#qt5.uic) -o "Src/GeneratedFiles/ui_$file_name.h" "$file"
4. "Generated files (to be further compiled)": Src/GeneratedFiles/ui_$file_name.h

So, when I'm add "Src/Kreator/somefile.ui" to project and make rebuild then:
a. File is generated inside right path: Src/GeneratedFiles/ui_somefile.h
b. CodeBlocks always put fixed position of "Auto-generated" path in window "Management -> Projects" to: "Src/Kreator/ui_somefile.h"
c. Because my ui_somefile.h is into "Src/GeneratedFiles/ui_somefile.h" - compiler cannot find it

(First solution) For working well I need to change:
ch.3. "Command line macro": $(#qt5.uic) -o "ui_$file_name.h" "$file"
ch.4. "Generated files (to be further compiled)": ui_$file_name.h

(Second solution) Or for alternative working well solution I need to change:
ch.3. "Command line macro": $(#qt5.uic) -o "Src\Kreator\ui_$file_name.h" "$file"
ch.4. "Generated files (to be further compiled)": Src\Kreator\ui_$file_name.h


But it is really mess when I have all generated files into main folder (first solution) or in folder of my source file Src\Kreator\* (second solution).
Auto-generated files for new extensions always put same directory as source. So first solution shouldn't work at all, but it work well :-).

So either I cannot configure this Code::Blocks functionality or it doesn't work like it should.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: oBFusCATed on November 15, 2014, 01:04:25 pm
Debugged a while, I found the reason why this bug happens, but I don't have a clean way to fix this issue.
See, the CC setting was stored in configure file.
When C::B start up, CC will create a default parser object called "temp parser".
When a parser object is created, it will copy the settings(such as the "Case sensitive matches") from the configure file to its own member variable.
When you open the CC dialog, the active parser object's setting will be modified also the CC related setting in configure files will get updated. This means, the configure file contains the active parser's settings.

When a CB project loaded, a new parser object(we call "new parser" here) is created and activated. So far, so good. When you changed the CC setting, both the "new parser"'s setting and the configure file get updated.

The issue comes when you close C::B, which means, you need to
1, destroy "new parser"
2, destroy "temp parser"

When destroy "new parser", all its setting was saved, but after that, the active parser switches to "temp parser", the setting in "temp parser" was active, and finally the "temp parser" get destroyed, its setting was saved (not the "new parser"), so your setting was lost!

I have not a good idea to fix this issue. Say, we have a setting shared by several parser objects. But they may be different, but the last destroyed parser's setting will be saved to the configure file.
Any plans to fix this issue? If not please say so, so I can take a look at it ...  it is quite annoying...
Title: Re: The 27 October 2014 build (10016) is out.
Post by: ToApolytoXaos on November 15, 2014, 03:49:11 pm
Apologies if I have asked again in the past: is it possible to add the same feature Find declaration... with Ctrl+mouse hover hotkeys?

I use NetBeans a lot for web development (Java as well) and find this feature quite appealing; it helps tremendously while looking for certain information about a class or member function.

How difficult is it to implement it?
Title: Re: The 27 October 2014 build (10016) is out.
Post by: oBFusCATed on November 17, 2014, 11:39:39 pm
Khram: Please try to describe the problem with more details, so we can try to solve it. Steps to reprocude, OS? Does it happen with the previous nightly?
Title: Re: The 27 October 2014 build (10016) is out.
Post by: ollydbg on November 18, 2014, 01:28:04 am
Debugged a while, I found the reason why this bug happens, but I don't have a clean way to fix this issue.
See, the CC setting was stored in configure file.
When C::B start up, CC will create a default parser object called "temp parser".
When a parser object is created, it will copy the settings(such as the "Case sensitive matches") from the configure file to its own member variable.
When you open the CC dialog, the active parser object's setting will be modified also the CC related setting in configure files will get updated. This means, the configure file contains the active parser's settings.

When a CB project loaded, a new parser object(we call "new parser" here) is created and activated. So far, so good. When you changed the CC setting, both the "new parser"'s setting and the configure file get updated.

The issue comes when you close C::B, which means, you need to
1, destroy "new parser"
2, destroy "temp parser"

When destroy "new parser", all its setting was saved, but after that, the active parser switches to "temp parser", the setting in "temp parser" was active, and finally the "temp parser" get destroyed, its setting was saved (not the "new parser"), so your setting was lost!

I have not a good idea to fix this issue. Say, we have a setting shared by several parser objects. But they may be different, but the last destroyed parser's setting will be saved to the configure file.
Any plans to fix this issue? If not please say so, so I can take a look at it ...  it is quite annoying...
I know it's annoying. As a workaround, you can just open C::B (without any project opened), and open the setting dialog for CodeCompletion, then close C::B, all the settings should be saved.

If you do want to forbid the setting saving of the "temp parser", you can just add an parameter of the Parser's constructor, say
Code: [Select]
Parser::Parser(....., bool saveSetting = true)
{
...
}

And create a temp parser in the code
Code: [Select]
m_TempParser = new Parser(this, nullptr, false); // the last parameter means we don't want to save the setting of this temp parser
But note that this still break something, such as the workaround I said before.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: Manolo on November 18, 2014, 06:56:45 pm
Hi
Something has gone wrong in my CB svn 10032 (Ubuntu 14.04 64bits) with the watches window:
'tmpv' is a double and it'a shown OK.
'float3' is defined in the previous line to the breakpoint as
Code: [Select]
float float3[3] = {0, -1.5, 8.3};As you can see every value != 0 is splitted into two lines: the integer and the decimal parts.

Would this issue be related to localization? (I'm at Spain) It does not happen in Windows 8.1

THX
Title: Re: The 27 October 2014 build (10016) is out.
Post by: oBFusCATed on November 18, 2014, 07:47:28 pm
Manolo: Can you post the full log from the debugger?
Title: Re: The 27 October 2014 build (10016) is out.
Post by: Manolo on November 18, 2014, 08:00:35 pm
I have created a new console project with this code:
Code: [Select]
#include <iostream>

using namespace std;

int main()
{
    float float3[3] = {0, -1.5, 8.3};
    cout << "Hello world!" << endl;
    return float3[0] ? 0 : 1;
}
Put a breakpoint at "cout <<..." line. The behaviour for the watches window is still broken.

Here is the full debugger log:
Code: [Select]
Active debugger config: GDB/CDB debugger:Default
Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: /home/manolo/PROGS/ConsoleMinimal/
Adding source dir: /home/manolo/PROGS/ConsoleMinimal/
Adding file: /home/manolo/PROGS/ConsoleMinimal/bin/Debug/ConsoleMinimal
Changing directory to: /home/manolo/PROGS/ConsoleMinimal/.
Set variable: LD_LIBRARY_PATH=.:/usr/lib32

[debug]Command-line: /usr/bin/gdb -nx -fullname -quiet  -args /home/manolo/PROGS/ConsoleMinimal/bin/Debug/ConsoleMinimal
[debug]Working dir : /home/manolo/PROGS/ConsoleMinimal

Starting debugger: /usr/bin/gdb -nx -fullname -quiet  -args /home/manolo/PROGS/ConsoleMinimal/bin/Debug/ConsoleMinimal
done

[debug]Leyendo símbolos desde /home/manolo/PROGS/ConsoleMinimal/bin/Debug/ConsoleMinimal...
[debug]hecho.
[debug](gdb)
[debug]> set prompt >>>>>>cb_gdb:

Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints

[debug]>>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
[debug]Copyright (C) 2014 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "x86_64-linux-gnu".
[debug]Type "show configuration" for configuration details.
[debug]Para las instrucciones de informe de errores, vea:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]Find the GDB manual and other documentation resources online at:
[debug]<http://www.gnu.org/software/gdb/documentation/>.
[debug]For help, type "help".
[debug]Type "apropos word" to search for commands related to "word".
[debug]>>>>>>cb_gdb:
[debug]> set confirm off

Debugger name and version: GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1

[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor intel
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Punto de captura 1 (lanzar)
[debug]>>>>>>cb_gdb:
[debug]> source /usr/share/codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory /home/manolo/PROGS/ConsoleMinimal/
[debug]Source directories searched: /home/manolo/PROGS/ConsoleMinimal:$cdir:$cwd
[debug]>>>>>>cb_gdb:
[debug]> break "/home/manolo/PROGS/ConsoleMinimal/main.cpp:8"
[debug]Punto de interrupción 2 at 0x400880: file /home/manolo/PROGS/ConsoleMinimal/main.cpp, line 8.
[debug]>>>>>>cb_gdb:

Punto de interrupción 2 at 0x400880: file /home/manolo/PROGS/ConsoleMinimal/main.cpp, line 8.

[debug]Using terminal's PID as console PID 13970, TTY /dev/pts/11
[debug]> tty /dev/pts/11
[debug]Queued:[tty /dev/pts/11]
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]Starting program: /home/manolo/PROGS/ConsoleMinimal/bin/Debug/ConsoleMinimal
[debug]Breakpoint 2, main () at /home/manolo/PROGS/ConsoleMinimal/main.cpp:8
[debug]/home/manolo/PROGS/ConsoleMinimal/main.cpp:8:94:beg:0x400880
[debug]>>>>>>cb_gdb:

At /home/manolo/PROGS/ConsoleMinimal/main.cpp:8
Title: Re: The 27 October 2014 build (10016) is out.
Post by: oBFusCATed on November 18, 2014, 09:20:40 pm
Hm, does this happen you start C::B from console like LC_ALL=C codeblocks?
C::B parses the output of the debugger, so a localized gdb is expected to break pretty badly.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: Manolo on November 18, 2014, 09:49:26 pm
Starting C:B from a terminal with command "LC_ALL=C codeblocks" does not show the issue.
So, it seems it's a gdb localized problem.

I haven't changed anything, just used gdb as it is right after installing it.
Should I change it or would C:B be aware of it?

THX
Title: Re: The 27 October 2014 build (10016) is out.
Post by: oBFusCATed on November 18, 2014, 09:54:47 pm
@Jens: Any idea how do we solve this same problem for the compiler? I've tried to search for locale setting code, but I couldn't find any.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: jens on November 18, 2014, 10:10:41 pm
For the compiler I added LC_ALL with the value C to "Settings -> Environment... -> Environment variables".
This might (hopefully) also work for gdb.
Title: Re: The 27 October 2014 build (10016) is out.
Post by: oBFusCATed on November 18, 2014, 10:37:02 pm
Are you adding this manually?
Title: Re: The 27 October 2014 build (10016) is out.
Post by: Manolo on November 18, 2014, 11:16:11 pm
Quote
For the compiler I added LC_ALL with the value C to "Settings -> Environment... -> Environment variables".
This might (hopefully) also work for gdb.
Doing this manually works for me.
Thank you for showing this easy solution.