Code::Blocks Forums

User forums => Nightly builds => Topic started by: killerbot on May 17, 2012, 05:16:43 pm

Title: The 17 May 2012 build (7966) is out.
Post by: killerbot on May 17, 2012, 05:16:43 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://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx2812_gcc452-TDM.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10_gcc452-TDM.7z

The 17 May 2012 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20120517_rev7966_win32.7z
  - Linux :
   none

Resolved Fixed:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 17 May 2012 build (7966) is out.
Post by: Grom on May 17, 2012, 06:12:24 pm
What about a new official release?
Title: Re: The 17 May 2012 build (7966) is out.
Post by: stahta01 on May 17, 2012, 06:51:10 pm
What about a new official release?

As long as the SDK API is being changed; it is unlikely for them to do a new official release.
Or in the standard reply, "When it is ready."

Tim S.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: fubo on May 17, 2012, 07:20:20 pm
Bug #18557 still there. Going back to 7789.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: oBFusCATed on May 17, 2012, 07:22:15 pm
http://wiki.codeblocks.org/index.php?title=FAQ-General#Q:_When_will_the_next_stable_version_of_Code::Blocks_be_released.3F
Title: Re: The 17 May 2012 build (7966) is out.
Post by: oBFusCATed on May 17, 2012, 07:24:20 pm
fubo: If you've followed the discussion in the previous nightly build topic, you would have known that this is a feature and it won't be fixed. Sorry.

If you need something not available in the current variables you have to ask for it otherwise you'd be stuck in 7789 forever.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: fubo on May 18, 2012, 07:15:50 am
fubo: If you've followed the discussion in the previous nightly build topic, you would have known that this is a feature and it won't be fixed. Sorry.

If you need something not available in the current variables you have to ask for it otherwise you'd be stuck in 7789 forever.
Ok, so let's accept that was an unwanted feature = a bug up to version 7789. If I understood correctly, all variables exposed here (http://wiki.codeblocks.org/index.php?title=Variable_expansion) can be used in option pane?
And, if I define some variables, can they be used in option pane?
Or no variables are usable?
Title: Re: The 17 May 2012 build (7966) is out.
Post by: oBFusCATed on May 18, 2012, 08:22:19 am
Yes, you can.
See here: http://wiki.codeblocks.org/index.php?title=Global_compiler_variables
And here: http://wiki.codeblocks.org/index.php?title=Environment_Variables_plugin
Title: Re: The 17 May 2012 build (7966) is out.
Post by: fubo on May 18, 2012, 08:56:57 am
Yes, you can.
See here: http://wiki.codeblocks.org/index.php?title=Global_compiler_variables
And here: http://wiki.codeblocks.org/index.php?title=Environment_Variables_plugin
Thank you so much! Changing $exe_dir\$exe_name.txt to $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).txt worked like a charm!
Title: Re: The 17 May 2012 build (7966) is out.
Post by: oBFusCATed on May 18, 2012, 09:25:32 am
Happy it is working now :)
Title: Re: The 17 May 2012 build (7966) is out.
Post by: NilC on May 19, 2012, 12:44:12 am
Four things:

0. Sorry for my English

1. C++11 & AStyle bug
As you surely know, there is "range-based for loop" in C++11:
for (int & x : a)
{
}

AStyle think that it's a label, because of colons and places it in the beginning of the line, so...
file "ASBeautifier.cpp" line "2376"
else if (isJavaStyle() && lastLineHeader == &AS_FOR)
The condition "isJavaStyle()" is no longer needed.

2. "Activate Project" Command

I have about 10 projects in workspace, when I activate some project - sometimes code::blocks freeze for ~5 second, once it freeze forever.
This bug appeared in nightly builds, following the 7790 (7790 if fine). I'm already posts info about this bug, but no one cares :)
Trying to fix by myself.

3. O_o WTF??

Guys, why the hell do you using targets (like Debug, Release, Win32, Linux in normal way) instead of using projects?
Title: Re: The 17 May 2012 build (7966) is out.
Post by: oBFusCATed on May 19, 2012, 01:20:09 am
Guys, why the hell do you using targets (like Debug, Release, Win32, Linux in normal way) instead of using projects?
What targets?
You're free to use whatever fits your way of doing things...
Title: Re: The 17 May 2012 build (7966) is out.
Post by: NilC on May 19, 2012, 02:22:24 am
Guys, why the hell do you using targets (like Debug, Release, Win32, Linux in normal way) instead of using projects?
What targets?
You're free to use whatever fits your way of doing things...

Putting all code in a one pot, and then get some of its parts with the targets - it's a perversion IMHO (But I'm not alone who think so).
Take a look (~350 KB)
http://dl.dropbox.com/u/58962113/Bru.png
http://dl.dropbox.com/u/58962113/CodeBlocks.png
Title: Re: The 17 May 2012 build (7966) is out.
Post by: oBFusCATed on May 19, 2012, 08:24:53 am
No one stops you from using a single target. At work I do just that.
I don't see a problem here.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: MortenMacFly on May 19, 2012, 02:58:23 pm
I don't see a problem here.
I don't, too. In the C::b project case, it bundles nicely related SDK libs, the SDK itself, the main app and some plugins into one project. The build order is from top to bottom and if you want, you can select just several targets of those using virtual targets (what we do). So this is another, but valid concept how to use targets. You don't have to do it that way, of course. All contrib plugins do it different for example.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: NilC on May 19, 2012, 03:19:15 pm
It's still strange for me, but your program - your architecture.
There are "real" problem:
Code::Blocks freeze not only on "Activate Project" command, also on "Rebuild Workspace", also on "Rebuild" - that is more important.
Platform: Win 7 x64 Home Premium.

I'm trying to fix the problem, any ideas??
Title: Re: The 17 May 2012 build (7966) is out.
Post by: MortenMacFly on May 19, 2012, 04:32:24 pm
I'm trying to fix the problem, any ideas??
Provide a test case so we can reproduce. I am working on the same platform as you do (and Win7 64 Ultimate) without any issues like that.

Do you have a freaking application firewall / application blocker installed?
Title: Re: The 17 May 2012 build (7966) is out.
Post by: NilC on May 19, 2012, 04:42:19 pm
Quote
Provide a test case so we can reproduce
Just select Build->Rebuild, other build commands. It's freeze not everytime.

Quote
Do you have a freaking application firewall / application blocker installed?
I do think so. Older builds are working fine.

Ok, I'm debugging right now, if there will be any results - I'll post them.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: MortenMacFly on May 19, 2012, 04:45:04 pm
Quote
Provide a test case so we can reproduce
Just select Build->Rebuild, other build commands. It's freeze not everytime.
i am doing this really often - no issues here.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: carra on May 21, 2012, 12:20:24 pm
The abbreviation list is now alphabetically ordered, nice :)
However, I still can't use command CallMenu and the issues on Editor Tweaks -> Align are still there.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: MortenMacFly on May 21, 2012, 02:11:00 pm
However, I still can't use command CallMenu and the issues on Editor Tweaks -> Align are still there.
Mind pointing to the place where you describe whats wrong? (Bug ID / forum link...)
Title: Re: The 17 May 2012 build (7966) is out.
Post by: carra on May 21, 2012, 02:35:28 pm
The thread in question was this one: http://forums.codeblocks.org/index.php/topic,11660.0
Basically, the problems with Align were:
- It should appear as a menu option, but it is only accessible through right click menu
- It allows for creation of more custom alignment rules. They work and are correctly stored in config file, but after C::B restarts only 4 of them are loaded
Title: Re: The 17 May 2012 build (7966) is out.
Post by: danselmi on May 21, 2012, 02:53:02 pm
The thread in question was this one: http://forums.codeblocks.org/index.php/topic,11660.0
Basically, the problems with Align were:
- It should appear as a menu option, but it is only accessible through right click menu
- It allows for creation of more custom alignment rules. They work and are correctly stored in config file, but after C::B restarts only 4 of them are loaded

This patch makes the number of stored items configurable. Anyone willing to test?
Title: Re: The 17 May 2012 build (7966) is out.
Post by: carra on May 21, 2012, 04:43:20 pm
Wow danselmi, you are quick!
I had a look at your diff and looks like it should do the trick. But I won't be able to try it since I don't compile C::B myself. Sorry there.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: arprog on May 22, 2012, 07:04:39 am
When do you plan to improve code completion? It would be nice to see something like VisualAssist  ;D

Title: Re: The 17 May 2012 build (7966) is out.
Post by: MortenMacFly on May 22, 2012, 07:07:37 am
When do you plan to improve code completion? It would be nice to see something like VisualAssist  ;D
Provide patches...
Title: Re: The 17 May 2012 build (7966) is out.
Post by: MortenMacFly on May 22, 2012, 07:11:16 am
This patch makes the number of stored items configurable. Anyone willing to test?
After compiling this in C::B crashes when I open the editor settings. :-(
Could it be your were missing to provide the XRC file in the patch?!
Title: Re: The 17 May 2012 build (7966) is out.
Post by: danselmi on May 22, 2012, 10:53:38 am
This patch makes the number of stored items configurable. Anyone willing to test?
After compiling this in C::B crashes when I open the editor settings. :-(
Could it be your were missing to provide the XRC file in the patch?!
You are right, it was not only missing in the patch but also on disk. So I had to recreate it. Hopefully this time nothing is missing in the patch (except the adjusted makefile.am ...).
Title: Re: The 17 May 2012 build (7966) is out.
Post by: MortenMacFly on May 22, 2012, 10:59:46 am
You are right, it was not only missing in the patch but also on disk. So I had to recreate it. Hopefully this time nothing is missing in the patch (except the adjusted makefile.am ...).
I guess there was another strange thing: The project file was not correctly instrumented to handle the wxSmith resource. Also, the wxSmith resource did not have a panel or alike as parent... how did you manage to achieve this?

I'll try the new one...

Btw: Patches are easier to handle if they are based on trunk root, not a sub-directory... but thats minor...
Title: Re: The 17 May 2012 build (7966) is out.
Post by: MortenMacFly on May 22, 2012, 12:04:34 pm
(except the adjusted makefile.am ...).
...this comes here (attached).
Title: Re: The 17 May 2012 build (7966) is out.
Post by: Grom on May 22, 2012, 06:13:14 pm
I would spend time on wxSmith. Basically Borland-Embarcadero idea can be implemented here. The wxWidgets component can have some class with list of all control properties to have an easy integration to the wxSmith. + Higher level of automation in wxSmith can be achieved with python script (it will give more automatic menus and tool bars).
Title: Re: The 17 May 2012 build (7966) is out.
Post by: MortenMacFly on May 22, 2012, 08:20:53 pm
The wxWidgets component can have some class with list of all control properties to have an easy integration to the wxSmith.
I don't quite get what exactly you mean, but integrating new UI controls is rather easy already in wxSmith.

What's missing is IMHO an inheritance strategy for UI controls that derive from others. Here, sometimes you won't see the parent's event handlers. If you have some spare time,  concept / implementation for this would be really beneficial.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: MortenMacFly on May 24, 2012, 08:17:48 pm
Hopefully this time nothing is missing in the patch (except the adjusted makefile.am ...).
Tested and works fine here, feel free to commit from my side (including the makefile.am update from my other post).
Title: Re: The 17 May 2012 build (7966) is out.
Post by: hooluupog on May 26, 2012, 08:34:42 am
Codeblocks still freezed when debugging application with large data (for example, vector with 10,000 elements).Yep,"set print elements" can avoid this problem.However,visual studio can show all of the elements imediately when debugging. I don't know how they managed to do that.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: MortenMacFly on May 26, 2012, 09:06:28 am
I don't know how they managed to do that.
Well first of all they use a completely different debugger principle...
Title: Re: The 17 May 2012 build (7966) is out.
Post by: afb on May 26, 2012, 08:32:54 pm
- Mac OS X: (10.4 and up, ppc and i386 - no x86_64 with wxMac)
  http://prdownload.berlios.de/codeblocks/CB_20120517_rev7966_mac2812.zip

More like "yearly" than "nightly", but anyway.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: ollydbg on May 27, 2012, 02:46:54 pm
I don't know how they managed to do that.
Well first of all they use a completely different debugger principle...
@Morten
What does this sentence mean? I want to hear more words about this. :)
Title: Re: The 17 May 2012 build (7966) is out.
Post by: MortenMacFly on May 27, 2012, 03:52:41 pm
What does this sentence mean?
Simply that the VC debugger is completely different from GDB.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: hooluupog on May 28, 2012, 06:55:37 pm
Is there any way to solve the problem? ??? It is so annoying when debugging.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: oBFusCATed on May 28, 2012, 06:59:07 pm
Is there any way to solve the problem? ??? It is so annoying when debugging.
At the moment no... use set print elements to a small value... sorry...
Title: Re: The 17 May 2012 build (7966) is out.
Post by: Grom on May 29, 2012, 05:46:34 pm
Just open Delphi or Lazarus component project. They have special file with registration of control in controls palette. I would tell that Delphi is some-kind of standard of visual development.

The wxWidgets component can have some class with list of all control properties to have an easy integration to the wxSmith.
I don't quite get what exactly you mean, but integrating new UI controls is rather easy already in wxSmith.

What's missing is IMHO an inheritance strategy for UI controls that derive from others. Here, sometimes you won't see the parent's event handlers. If you have some spare time,  concept / implementation for this would be really beneficial.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: oBFusCATed on May 29, 2012, 06:37:15 pm
Delphi is just dead, something from the past...  ;D
Title: Re: The 17 May 2012 build (7966) is out.
Post by: Ceniza on May 29, 2012, 07:27:07 pm
Delphi is just dead, something from the past...  ;D

I wish! Delphi has been catching up since the 2009 version, although they care more about adding features than properly testing and fixing bugs. You can even do 64 bits, MacOS X and iOS development with the latest version (some of those using FireMonkey, which introduces hardware acceleration and some other things).

What allows languages like Object Pascal (Delphi), .NET (C#, ...) and a few others to be nicely and easily used for RAD, visual design and so on is extended support for type introspection through RTTI. In that area C++ is rather... poor. It's true it always comes with a price in terms of overhead and code bloat, but it allows for rather nice stuff to be more easily created and self contained. There's a big chance C++ will not support such a thing to that extent, so solutions like those provided by wxSmith will have to stay the norm. No matter how hard you try to make your design as good as possible for it, it's never good enough for some.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: hooluupog on May 30, 2012, 05:53:11 am
Is there any way to solve the problem? ??? It is so annoying when debugging.
At the moment no... use set print elements to a small value... sorry...
Hi, I tried debugging again within gdb 7.3(python enabled) command environment  and set print elements 0 to let it print all of the elements ,it works well and gives me a very quick response. But it freezed or ran so slowly when debugging in codeblocks. Seems it is not gdb's flaw.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: ollydbg on May 30, 2012, 07:12:34 am
Is there any way to solve the problem? ??? It is so annoying when debugging.
At the moment no... use set print elements to a small value... sorry...
Hi, I tried debugging again within gdb 7.3(python enabled) command environment  and set print elements 0 to let it print all of the elements ,it works well and gives me a very quick response. But it freezed or ran so slowly when debugging in codeblocks. Seems it is not gdb's flaw.
Hi, Hooluupog. I do not think so.

Codeblocks just serves as a front end of gdb, so the most situation is: gdb freeze cause codeblocks freeze.

I believe you can give use the log of both gdb (under Windows Shell) and the gdb log (under Codeblocks Debugger panel), then we can see whether you are true. :)
Title: Re: The 17 May 2012 build (7966) is out.
Post by: hooluupog on May 30, 2012, 08:42:08 am
Hi, Hooluupog. I do not think so.

Codeblocks just serves as a front end of gdb, so the most situation is: gdb freeze cause codeblocks freeze.

I believe you can give use the log of both gdb (under Windows Shell) and the gdb log (under Codeblocks Debugger panel), then we can see whether you are true. :)
It just freezed,the debugger stopped working,and showed none gdb log output. Meanwhile cpu usage was keeping 50%(i3 quard Core cpu).You can see my screenshot.

[attachment deleted by admin]
Title: Re: The 17 May 2012 build (7966) is out.
Post by: oBFusCATed on May 30, 2012, 09:02:33 am
Don't use "set print elements 0" if you use it and you have large data structures it will be slow - end of discussion.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: ollydbg on May 30, 2012, 09:07:52 am
Hi, Hooluupog. I do not think so.

Codeblocks just serves as a front end of gdb, so the most situation is: gdb freeze cause codeblocks freeze.

I believe you can give use the log of both gdb (under Windows Shell) and the gdb log (under Codeblocks Debugger panel), then we can see whether you are true. :)
It just freezed,the debugger stopped working,and showed none gdb log output. Meanwhile cpu usage was keeping 50%(i3 quard Core cpu).You can see my screenshot.
OK, if you debug your program in GDB (Windows shell), the gdb should be freeze too.  :)
Title: Re: The 17 May 2012 build (7966) is out.
Post by: hooluupog on May 30, 2012, 09:17:44 am
Hi, Hooluupog. I do not think so.

Codeblocks just serves as a front end of gdb, so the most situation is: gdb freeze cause codeblocks freeze.

I believe you can give use the log of both gdb (under Windows Shell) and the gdb log (under Codeblocks Debugger panel), then we can see whether you are true. :)
It just freezed,the debugger stopped working,and showed none gdb log output. Meanwhile cpu usage was keeping 50%(i3 quard Core cpu).You can see my screenshot.
OK, if you debug your program in GDB (Windows shell), the gdb should be freeze too.  :)
No,I have tried many times. In gdb command environment  it is very fast to print the elements but slow within codeblocks(nearly 5 mins or so to show the result,feels like it freezed).
Title: Re: The 17 May 2012 build (7966) is out.
Post by: oBFusCATed on May 30, 2012, 09:19:58 am
Yes, it is known issue...
Title: Re: The 17 May 2012 build (7966) is out.
Post by: MortenMacFly on May 30, 2012, 10:37:01 am
Yes, it is known issue...
Yes, I noticed that, too. We should try to find a solution for that. IMHO its related to the PipedProcess class but this is hard to track and (as we found out many times) a sensitive component. My suggestion would be to introduce an own "PipedProcess" class better suited for the debugger not affecting any other components.
@oBFusCATed would that be a "good thing to do" [tm]?
Title: Re: The 17 May 2012 build (7966) is out.
Post by: oBFusCATed on May 30, 2012, 12:02:19 pm
The general slowness comes from the fact that every line of output generates a wx event, which is quite slow.
The previous attempt failed rather miserably, so I'm not sure I want to invest time in improving the situation.
I have very little free time at the moment, because I've started to write my Bachelor's thesis (or whatever is the name in English), so the next two-three mouths will be quite busy.

The GDB/MI plugin doesn't have this problem, because there are less lines of output. Every result from a command is a single line. But unfortunately it is not ready. :)
Title: Re: The 17 May 2012 build (7966) is out.
Post by: ollydbg on May 30, 2012, 01:48:35 pm
The general slowness comes from the fact that every line of output generates a wx event, which is quite slow.
The previous attempt failed rather miserably, so I'm not sure I want to invest time in improving the situation.
I have very little free time at the moment, because I've started to write my Bachelor's thesis (or whatever is the name in English), so the next two-three mouths will be quite busy.
Congratulation!
It looks like you are much younger than me. :)

Quote
The GDB/MI plugin doesn't have this problem, because there are less lines of output. Every result from a command is a single line. But unfortunately it is not ready. :)
What has left in GDB/MI?

@hooluupog
Can you post the steps in both GDB command line and Codeblocks log, also the source code. I'm going to test the lag. Thanks.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: oBFusCATed on May 30, 2012, 02:10:28 pm
Congratulation!
It looks like you are much younger than me. :)
Not that young, I've used the whole available period of 5 years for postponing it :)

What has left in GDB/MI?
Polishing...

@hooluupog
Can you post the steps in both GDB command line and Codeblocks log, also the source code. I'm going to test the lag. Thanks.
Create an array with 10000 elements and try to watch it, should trigger the bug.
If it doesn't trigger it, try array with 10000 wxstring or std::string elements :)

Another way to test it to add 10-20 big classes (many members in them) in the watch window.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: hooluupog on May 30, 2012, 06:12:07 pm
]
@hooluupog
Can you post the steps in both GDB command line and Codeblocks log, also the source code. I'm going to test the lag. Thanks.
The source code and codeblock's log are in attachment.
The steps of GDB command line:
(gdb)file main.exe
(gdb)set print elements 0
(gdb) source c:/minGW32/bin/.gdbinit
(gdb) b 8
(gdb)b 15
(gdb)r
(gdb)c
(gdb)p s
(gdb)p in

[attachment deleted by admin]
Title: Re: The 17 May 2012 build (7966) is out.
Post by: ollydbg on May 31, 2012, 03:04:23 am
@hooluupog
Can you post the steps in both GDB command line and Codeblocks log, also the source code. I'm going to test the lag. Thanks.
The source code and codeblock's log are in attachment.
The steps of GDB command line:
(gdb)file main.exe
(gdb)set print elements 0
(gdb) source c:/minGW32/bin/.gdbinit
(gdb) b 8
(gdb)b 15
(gdb)r
(gdb)c
(gdb)p s
(gdb)p in
Ok, I just test your example code: (I try to print the s when after breakpoint in line 15 hits)
1, CB gdb plugin, CB hangs for more than one minute, and I just close it from Windows Task manager.
2, CB gdb-mi plugin, CB hangs about half a minute, and all the contents was shown in the debuggers log:
Quote
...
[65200]",exp="[65200]",numchild="0",value="1",type="int",thread-id="1"},child={name="var1.[65201]",exp="[65201]",numchild="0",value="3",type="int",thread-id="1"},child={name="var1.[65202]",exp="[65202]",numchild="0",value="7",type="int",thread-id="1"}],has_more="0"
3, in gdb Windows Shell (Windows Console window), gdb print the whole value quickly, about 5-6 seconds.

Title: Re: The 17 May 2012 build (7966) is out.
Post by: cacb on June 02, 2012, 10:18:21 pm
I have reported this before, but it seems to me that the last few months, something has happened to the C::B nightly builds on Windows that cause my projects to build significantly slower than before. My setup is Windows XP SP3, on HP xw4600 Workstation Intel(R) Core(TM)2 Duo CPU E7200@2.53GHz, C::B is set to use 2 processes for parallell builds in the Global Compiler Settings (build options). The compiler is MS Visual C++ 2010 express. I have downloaded pre-built nightlies from this forum only, I never build C::B from source code myself.

I just did an experiment, compiling my own source code using the above, but 2 different nightly builds of C::B. Observe that the only difference is the C::B IDE version, everything else is the same. The source code, project files and build targets are all the same.

I compiled my code 6 times (always complete Rebuild Workspace) in the following sequence

Nightly build CB 7452:                                0 errors, 0 warnings (1 minutes, 35 seconds)
Nightly build CB 7966:  === Build finished: 0 errors, 1 warnings (3 minutes, 39 seconds) ===
Nightly build CB 7452:                                0 errors, 0 warnings (1 minutes, 36 seconds)
Nightly build CB 7966:  === Build finished: 0 errors, 1 warnings (2 minutes, 57 seconds) ===
Nightly build CB 7452:                                0 errors, 0 warnings (1 minutes, 40 seconds)
Nightly build CB 7966:  === Build finished: 0 errors, 1 warnings (3 minutes, 2 seconds) ===

When looking at the "Performance" tab in the XP Task Manager, it is apparent that compilation is pausing a lot when running under CB 7966. This does not happen with CB 7452, and apparently that makes all the difference. After all the compiler and linker is exactly the same.

Have anyone here seen anything like this? Obviously it is an annoying problem, preventing me from using the newest nightlies.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: oBFusCATed on June 02, 2012, 10:26:30 pm
cacb:
Enable the full build log and compare the logs for the two nighlies.
If the commands are the same the errors and warning numbers must be the same, but they aren't.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: cacb on June 02, 2012, 11:50:34 pm
I agree the difference in warning was an oddity, and I am not able to reproduce it now. When I run using both nightlies now, I get no warnings either way. I think the warning was about an object file exporting no symbols, btw.

HOWEVER, I have now re-run the experiment using the different nightlies (getting 0 errors, 0 warnings in both), with logs. The time difference and other behaviour I explained remains as before, big difference. I have studied the logs and find no difference whatsoever in the compiler options. The format of the logs are not exactly the same, however, when running with the 7966 nightly, the name of the compiler is reported for every project build target. With the 7452 nightly, the compiler name is not reported.

e.g.

for 7452
-------------- Build: W32_Debug in FlexTime ---------------

for 7966
-------------- Build: W32_Debug in FlexTime (compiler: MSVC)---------------

I can also see that the compile order is sometimes not exactly the same, it seems 7966 compiles project files in alphabetical sort order, while 7452 uses "some other order". Perhaps it is random, due to multiple CPUs, I don't know. But the sorting differences are such that a full compare using KDIFF3 is not practical. So instead I have looked at various samples manually.

It is clear that for the same files
- the compiler options are exactly the same
- the include paths are exactly the same, both referring to VC2010 Express installation
- the linker commands are exactly the same
- resource builds are the exactly same

Still the build times are very different, 7966 takes almost twice as long.

I tend to believe the differences have nothing to do with the build system as such. The 7966 Nightly generally appears more sluggish on my computer, and the 7452 is more responsive, for example during start-up or shut-down of the IDE (no build going on). I am just guessing here, but if 7966 is accessing the configuration (windows registry) more aggressively than 7452, it could have a big impact. Or it could be due to something entirely different.

What I am saying is that I cannot find any indication that the build time difference has anything to do with the parameters or options provided to the compiler/linker, and I have positively confirmed that the compiler/linker tools are the exactlty same in the two cases.

Still, the difference remains.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: oBFusCATed on June 03, 2012, 12:05:30 am
If you where on unix you can have used the sort utility to sort both files :)
Is there a chance to try to bisect the nightly which is causing the slowness.
We have several nightlies in between 7452 and 7966.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: cacb on June 03, 2012, 12:26:50 am
If you where on unix you can have used the sort utility to sort both files :)
Is there a chance to try to bisect the nightly which is causing the slowness.
We have several nightlies in between 7452 and 7966.

Well, I have a Kubuntu machine in my network, so if you can tell me how use "the sort utility", I could try.

Regarding which nightly is slow, I already reported the following in April
http://forums.codeblocks.org/index.php/topic,16199.msg109543.html#msg109543

See also
http://forums.codeblocks.org/index.php/topic,16199.msg109568.html#msg109568
Where it is stated (by someone else) that 7918 is the first build with lags
Title: Re: The 17 May 2012 build (7966) is out.
Post by: oBFusCATed on June 03, 2012, 01:41:39 am
"cat myfile | sort > mysortedfile"

If the nightly is slow/lags in r7919 only, this should be fixed or you could work around it by disabling the todo plugin.

Slow building is caused by something else, so if you could pinpoint the revision where it started it could help.
Also are you sure that C::B correctly recognises the thread option?
Set it to something big and look in the task manager if you see many instances of cl.exe.
What happens if you tell it to build the code on a single processor?
Title: Re: The 17 May 2012 build (7966) is out.
Post by: cacb on June 03, 2012, 02:03:57 pm
I have tested the "thread option" if you mean Global compiler settings | Build options | Number of processes for parallel builds
I get the expected number of cl.exe instances in Windows Task Manager.

If I set the number to 1, the build takes 5 minutes, i.e. slower than using the 2 processors I have. I get one cl.exe instance. If I set the number to 6, (3 times more than my 2 processors), I get 6 instances of cl.exe, the build then takes 2 minutes 42 seconds, about the same as when using 2 processors (no surprise).

So the problem is unrelated to the number of processor-setting. The problem is that, in 7966, something is preventing the compiler from using available CPU. During build with 7966, CPU use behaves like a yo-yo in Windows Task Manager, see attachment. The processors work at 100% for a while, then pauses for a significant period, where none of the cl.exe processes consume any CPU. This is totally different in 7452, where such pausing is not observed, compilation runs at full speed almost continuously. This is the reason why it is so much faster. The important question is what is causing the pausing in 7966, and I don't know the answer to that.

Another clue is perhaps this: When tweaking the setting Global compiler settings | Build options | Number of processes for parallel builds and press OK on 7452, the dialog disappears immediately. Again, it is different in 7966, where it takes almost 10 seconds from the time OK is pressed until the dialog disappears.

Btw. there is no antivirus or other "known nasties" running on the system. If that had been the problem, it shouldn't help to run an older C::B, but it does.

PS: Todo plugin (and many other plugins) disabled long time ago.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: oBFusCATed on June 03, 2012, 03:24:45 pm
So 7966 is slower than 7452 in single-thread mode?

Also please try to find the first release which is broken. Keep in mind that this issue is not related to the lag depicted in the old nighly's topic.
Also can you try with a clean settings?

And finally: If I understand correctly you see cl.exe doing nothing in the task manager? Or do you see periods of time where there are no cl.exe running?
The first one is not a problem of C::B, it is miss configuration. The second is a problem of C::B.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: cacb on June 04, 2012, 12:12:16 am
So 7966 is slower than 7452 in single-thread mode?

Also please try to find the first release which is broken. Keep in mind that this issue is not related to the lag depicted in the old nighly's topic.
Also can you try with a clean settings?

And finally: If I understand correctly you see cl.exe doing nothing in the task manager? Or do you see periods of time where there are no cl.exe running?
The first one is not a problem of C::B, it is miss configuration. The second is a problem of C::B.

What kind of misconfiguration are you referring to? The configuration is exactly the same with the two C::B nightlies. I wish someone would believe my words.

Title: Re: The 17 May 2012 build (7966) is out.
Post by: oBFusCATed on June 04, 2012, 09:55:07 am
How would I know?
Why do you think I don't believe you?
Title: Re: The 17 May 2012 build (7966) is out.
Post by: cacb on June 04, 2012, 11:16:47 pm
How would I know?
Why do you think I don't believe you?

I don't want to be polemic, but it seems to me as you seem to be sure it isn't the same problem as the lag issue I reported earlier, and you also seem to be sure it is an unidentified "misconfiguration" issue. I am happy to be proven wrong, but the info provided seems to contradict such assertions. I have provided much information that seems quite adequate in characterising this very real issue.  I hope it is understood that I am trying to provide the necessary information.

Some main bullets

1. The current build (7966) lags significantly, also when not building, ref the reported issue with Global compiler settings | Build options | Number of processes for parallel builds here http://forums.codeblocks.org/index.php/topic,16352.msg111221.html#msg111221
The same behaviour is apparent when closing a workspace. So to me it looks like the lag issue is not fixed and could very well be what I am seeing also during build (ok, I speculate, but anyway). 7452 does not have the same lag. I am not convinced now the lag issue reported in April is a different thing, but I am always open for new info.

2. I provided 2 clear screenshots showing the behaviour as seen in Task Manager. I am told this is not a C::B problem even though the only difference is different C::B versions. I am also told it is a "misconfiguration", and I am happy to correct any misconfiguration if it can be identified, but you say you wouldn't know, so it looks like my information is not believed. The configuration is identical in the two cases. How can you be so sure it isn't a C::B problem? I am not saying it is, but I all evidence points in that direction as I see it. Please tell me why I am wrong, as it might help sort things out.

3. Please tell me how to test with clean settings. Is it just a matter of deleting
C:\Documents and Settings\<user>\Application Data\codeblocks\default.conf ?

Thanks.


Title: Re: The 17 May 2012 build (7966) is out.
Post by: oBFusCATed on June 04, 2012, 11:27:10 pm
1. There was an identified lag that was fixed (related to the to-do plugin).
2. OK, you have not told me if the cl.exe-s are there doing nothing or c::b is blocking somewhere between running
3. Yes, but you can rename it. I'm asking this just in case, it isn't because I don't believe you.

And I've asked you to try to find the first nightly with this problem, you have not! And you're comparing 500 revisions.

p.s. Can you provide an example project, which build slow?
p.p.s Does this happen with vc2008 or older compilers?
Title: Re: The 17 May 2012 build (7966) is out.
Post by: cacb on June 05, 2012, 12:28:12 am
1. There was an identified lag that was fixed (related to the to-do plugin).
2. OK, you have not told me if the cl.exe-s are there doing nothing or c::b is blocking somewhere between running
3. Yes, but you can rename it. I'm asking this just in case, it isn't because I don't believe you.

And I've asked you to try to find the first nightly with this problem, you have not! And you're comparing 500 revisions.

p.s. Can you provide an example project, which build slow?
p.p.s Does this happen with vc2008 or older compilers?

1. Ok, but as you can see, I still observe issues.
2. The cl.exe are there all the time as stated before, but they don't always consume CPU, as shown in the Task manager screenshots. That means, they all sometimes do work, then sometimes they don't. My guess is that C::B is blocking, but I cannot be sure, I see the expected number of cl.exe, sometimes they they are listed with using significant CPU, somtetimes they are listed using 0 CPU.
3. Thanks, I shall try it with 7966.

Actually, I have referred you to this post
http://forums.codeblocks.org/index.php/topic,16199.msg109543.html#msg109543
You are telling me I haven't told you, because you believe it is irrelevant, but I am not convinced. The symptoms I reported then
http://forums.codeblocks.org/index.php/topic,16199.msg109481.html#msg109481
appears at least rather similar. If some issues were fixed, maybe some remain.

I recently switched from using VC2008 to VC2010 (both express), I have both installed still and my projects can with some tweaking be built against both. I just tried compiling with 7966 using VC2008. The exact same problem occurs, t looks to be unrelated to using VC2008 or VC2010 compiler (checked also 7452+VC2008).

I don't have a ready workspace to share unfortunately, much as I'd like to do it.

I am going to try renaming the *.conf file now.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: oBFusCATed on June 05, 2012, 12:55:26 am
Quoting myself:
cacb: What about 7789, 7678, 7550?
If we are going to talk with old links. This post was never answered by you!

If the cl.exe are there all the time then they are blocking on some file read or global mutex/semaphore, etc.
cl.exe does some writing to common files (pdbs for example) and this may cause performance problems.
The thing is that C::B is starting them as fast as it can, but there is something slowing them down.
Thus it is not a problem in C::B, but some configuration problem or the cl.exe options are not correct.
(all this analysis is just a speculation)

What is the time difference between the working and the non-working version,
when you set the number of process to 1 in both versions? (I've ask this before, but you've never answer this too).

Also please try to build with mingw as this is know to be good performer, when used in multi-core machines.
Title: Re: The 17 May 2012 build (7966) is out.
Post by: cacb on June 05, 2012, 09:55:35 pm
Unfortunately, I don't have all all the time in the world to run all thinkable and unthinkable combinations of C::B versions, different MS compilers and mingw compiler, plus different settings on each. That is too bad, but it is the truth. I have spent many hours with this issue, and tomorrow I have an important conference to attend to. So I will have to let this rest for a few days.

The cl.exe blocking issue sounds more like what I thought was going on. How this can be a configuration issue I honestly don't understand, I repeat it is the same configuration for the versions I have tested, giving the different result.

I'll check the time difference with one processor, but then I am running out of my own time.

EDIT: Running with 1 processor in both cases below
7452: 2 minutes, 42 seconds
7966: 5 minutes, 7 seconds  (same problem with pausing as always)
Title: Re: The 17 May 2012 build (7966) is out.
Post by: oBFusCATed on June 05, 2012, 10:17:43 pm
The cl.exe blocking issue sounds more like what I thought was going on. How this can be a configuration issue I honestly don't understand, I repeat it is the same configuration for the versions I have tested, giving the different result.
Do project directories look the same after a successful build?
Are you willing to send me both log files for inspection?