Code::Blocks Forums

User forums => Nightly builds => Topic started by: killerbot on November 07, 2010, 11:30:02 am

Title: The 07 November 2010 build (6840) is out.
Post by: killerbot on November 07, 2010, 11:30:02 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 for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx2810_gcc441.7z

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

The 07 November 2010 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20101107_rev6840_win32.7z
  - Linux :
   none

Resolved Fixed:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 07 November 2010 build (6840) is out.
Post by: Jenna on November 07, 2010, 12:11:26 pm
Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my repo (http://apt.jenslody.de/).
Title: Re: The 07 November 2010 build (6840) is out.
Post by: Max on November 07, 2010, 04:30:07 pm
Any chance to have a nightly of the debugger branch?

Max
Title: Re: The 07 November 2010 build (6840) is out.
Post by: Folco on November 07, 2010, 05:31:39 pm
When executing a make uninstall, some folders remain :
/usr/local/share/codeblocks/ (with folders inside)
/usr/local/include/[codeblocks | wxsmith | wxSmithContribItems]/
/usr/local/lib/[codeblocks | wxSmithContribItems]

$(HOME)/.codeblocks isn't removed, perhaps this is the expected result ?

But for folders in /usr/loca, this is normal ?

(all this is true for svn 6838, currently compiling 6840).
Title: Re: The 07 November 2010 build (6840) is out.
Post by: sandford on November 07, 2010, 06:04:24 pm
Could someone expand on the bullet point: "always have one free core of parallel builds". Does this mean that even if I manually specify C::B to use one thread per core, it will only use N-1 cores? Or does this only apply to the default parallel build settings?
Title: Re: The 07 November 2010 build (6840) is out.
Post by: Jenna on November 07, 2010, 06:16:02 pm
Could someone expand on the bullet point: "always have one free core of parallel builds". Does this mean that even if I manually specify C::B to use one thread per core, it will only use N-1 cores? Or does this only apply to the default parallel build settings?
The log shows work in progress.
After some discussion between the devs, we decided to kee a conservative default value (if no conf-file exists) of 1.
The range you can chose is between one and 16 or between one and the cpu-(or better core-)count, if it is greater than 16.
Title: Re: The 07 November 2010 build (6840) is out.
Post by: oBFusCATed on November 07, 2010, 06:55:51 pm
By the way is it possible to make this option per compiler?
On windows if you have gcc and visual studio, you have to modify it when switching compilers,
because VC doesn't work, when the option is !=1.
Title: Re: The 07 November 2010 build (6840) is out.
Post by: Jenna on November 07, 2010, 07:35:22 pm
When executing a make uninstall, some folders remain :
/usr/local/share/codeblocks/ (with folders inside)
/usr/local/include/[codeblocks | wxsmith | wxSmithContribItems]/
/usr/local/lib/[codeblocks | wxSmithContribItems]

$(HOME)/.codeblocks isn't removed, perhaps this is the expected result ?

But for folders in /usr/loca, this is normal ?

(all this is true for svn 6838, currently compiling 6840).
There is/was a discussion about that: http://www.mail-archive.com/automake@gnu.org/msg00423.html

I suggest using checkinstall for the last step (make install), it exists for almost every distribution, and can create packages for almost any package-manager: http://checkinstall.izto.org/ (http://checkinstall.izto.org/) .
Title: Re: The 07 November 2010 build (6840) is out.
Post by: Folco on November 07, 2010, 08:52:22 pm
Thank you !
Title: Re: The 07 November 2010 build (6840) is out.
Post by: Loaden on November 08, 2010, 01:02:50 am
because VC doesn't work, when the option is !=1.
Works well for me, which your OS? VC version?
I'm testing on XPSP3, VC10.
Title: Re: The 07 November 2010 build (6840) is out.
Post by: oBFusCATed on November 08, 2010, 09:44:47 am
Loaden: VC 10 is something like VisualStudio 4.0, because VisualStudio 6.0 has compiler with version 12.00.
Title: Re: The 07 November 2010 build (6840) is out.
Post by: ollydbg on November 08, 2010, 09:53:37 am
Loaden: VC 10 is something like VisualStudio 4.0, because VisualStudio 6.0 has compiler with version 12.00.
VC10 I think is Visual C++ 2010.
Title: Re: The 07 November 2010 build (6840) is out.
Post by: Loaden on November 08, 2010, 10:19:51 am
Loaden: VC 10 is something like VisualStudio 4.0, because VisualStudio 6.0 has compiler with version 12.00.
VC10 I think is Visual C++ 2010.

That's my meaning.  :lol:
Title: Re: The 07 November 2010 build (6840) is out.
Post by: ikipiki on November 08, 2010, 11:19:11 am
Thanks for this build, it is pretty stable.
Just one thing that I have note. When editor option “interpret #if, #else, #endif to gray...” is on, editor ignores defines in project build options.
Title: Re: The 07 November 2010 build (6840) is out.
Post by: ptDev on November 08, 2010, 11:21:20 am
The unofficial installer (nightly build with the added plugins cbDiff, ColorCoder, FileManager, PowerShell, SpellChecker and XPMEditor) has been updated to svn revision 6840. The announcement can be found here (http://forums.codeblocks.org/index.php/topic,13234.msg88948.html#msg88948).

Direct download link here (http://www.mediafire.com/file/n9xlfl5dgh6ubue/cb-svn6840-setup.zip).
Title: Re: The 07 November 2010 build (6840) is out.
Post by: tanq on November 08, 2010, 01:41:37 pm
By the way is it possible to make this option per compiler?
On windows if you have gcc and visual studio, you have to modify it when switching compilers,
because VC doesn't work, when the option is !=1.
U can add new build targets and assign different compiler to them.
Title: Re: The 07 November 2010 build (6840) is out.
Post by: oBFusCATed on November 08, 2010, 03:01:02 pm
Your post is totally unrelated.
I know how to setup a project with different compilers...
Title: Re: The 07 November 2010 build (6840) is out.
Post by: elettronica67 on November 08, 2010, 10:25:02 pm
Hi,
does someone know when the debugger branch will be merged with the main branch?

Thanks in advance
Paolo
Title: Re: The 07 November 2010 build (6840) is out.
Post by: oBFusCATed on November 08, 2010, 11:38:13 pm
Yes it will, someday :)
Title: Re: The 07 November 2010 build (6840) is out.
Post by: Folco on November 09, 2010, 12:41:22 am
The Debian way: "when it's ready" ^^
Title: Re: The 07 November 2010 build (6840) is out.
Post by: Monolith on November 09, 2010, 09:24:41 am
Misspelling in Settings->Editor->Source Formatter->Formatting "Insert space padding after paren headers only."

Also I was wondering if there was a way to edit "smart" indent tabbing style. I would like the "smart" indent to kick over only 1 tab on continued lines and not line up under the parameters.
Title: Re: The 07 November 2010 build (6840) is out.
Post by: oBFusCATed on November 09, 2010, 11:09:48 am
Yes you can turn of the parameter alignment...

It is somewhere in Settings -> Editor, look for checkbox "smart indent brace" or something like that...
Title: making order of search directories
Post by: huliming2004 on November 10, 2010, 02:57:15 am
Reacently i was immigratting a qt-mingw project to vs2005, i found that
you cannot make the order of search directories. i found many file conficts
like imessag.h, parser.h with vs2005 PlatformSDK, i adjust the search order to
avoid it and found it was very inconvenient. Do you provide a fuction that can
move directory items up and down like vs2005 or delphi do?
(build options -> search directories)

best regards!
Title: Re: The 07 November 2010 build (6840) is out.
Post by: oBFusCATed on November 10, 2010, 09:18:41 am
I think there are two buttons on the right side -> "up" and "down"
Title: Re: The 07 November 2010 build (6840) is out.
Post by: Folco on November 10, 2010, 05:17:08 pm
I think I have a problem with "current project".

I have two opened projects (but I don't use a workspace file to open both in the same time : I open .cbp files separately).

I have an own "build" tool binded to the F5 key. Here its parameters : (http://www.mirari.fr/Ihhs)

As you can see, it uses ${PROJECT_DIR} to be sure that the 'build.sh' script is the one of the current project.
(edit -> on this shot, I have forgotten the '$' symbol before {...}. But behaviour is still same after having added it :()

In CB, my current project is 'Par' (it's written in bold font), the one which is not current is 'pdtlib' (simple font).

But when I press F5, the 'build.sh' script is the one of Pdtlib, not the one of Par. Is it a bug, or am I totally wrong ?

I tried to toggle current activated project, by double-clicking or right-clicking the project name, it's always assemble Pdtlib, never Par.

(http://www.mirari.fr/g1oH)
Title: Re: The 07 November 2010 build (6840) is out.
Post by: Folco on November 10, 2010, 05:30:26 pm
hmmm...

The problem doesn't occur anymore if I specify the 'working dir' in the Tools parameters... so now I can get the right script to be launched.

But before this solution, C::B log was quite strange :
Quote
Launching tool 'Build': /usr/bin/konsole --hold --workdir /mnt/[...]/PAR/src/ -e build.sh (in /mnt/[...]/PDTLIB/src/)
Why didn't in work correctly ?? --workdir is a valid switch... http://www.digipedia.pl/man/doc/view/konsole.1/

How to check that C::B really executes that ?
Title: Re: The 07 November 2010 build (6840) is out.
Post by: huliming2004 on November 10, 2010, 06:18:53 pm
I think there are two buttons on the right side -> "up" and "down"
thanks! I have used codeblocks for about 2 years without noticing it,
maybe it is because i alway uses "this is a custom Makefile", and write *.pro files,
qmake it, then compile. Anyway thanks again.
Title: Re: The 07 November 2010 build (6840) is out.
Post by: beanbaby on November 11, 2010, 09:30:15 am
Thx, I find this tool is perfect!!
Title: Re: The 07 November 2010 build (6840) is out.
Post by: SotM on November 11, 2010, 12:17:19 pm
I think I found a bug.
Let's say I have a workspace and it is opened, there are 2 projects (regular C). Names are: Project1, MyLibrary.
Project1 uses some functions from MyLibrary.
I opened a C file from Project1, then right clicked on a function (which can be found within Project1), and select 'Find implementation...', and it jumps right to the implementation of that particular function.
BUT, if I do the same (right click and select 'Find impl..') on a function which can be found in MyLibrary it says "Not found <function name>".
And if I jump to project MyLibrary and try to "Find" that function within this project then everything will be fine. But, again, if I try to find a function "outside" this project then I get a message "Not found ... " :(
If I do the same procedures with 'Find declaration ...' then everything is just fine.

It did work fine with other CodeBlocks builds, but last 2 or 3 beta builds don't work fine.

Or maybe I'm wrong and I need to turn on some special features.
Ideas/comments?
Title: Re: The 07 November 2010 build (6840) is out.
Post by: NerdIII on November 11, 2010, 05:17:21 pm
I just tried the gentoo ebuild for the svn version and it worked flawless. The code completion is really marture now and Code::Blocks is my preferred IDE on Linux now. Thank you for all the time you spent on this project and the plugins!
Especially the Alt+n symbol rename functionality is a very convenient addition.

Some glitches I found in the code completion (svn 6843):
- It sometimes tries to complete 'itself'. It happens when I type "int variab|;" and the caret is at the pipe symbol. Then the popup shows me "variab" as a suggestion.
- Also the codecompletion is now at a point where it shouldn't get any slower. When I write a simple for loop with a integer counter-variable I already experience some lag.
- Template classes seem to pose a problem. When I have a vector<...> it can't find it's methods.
Title: Re: The 07 November 2010 build (6840) is out.
Post by: killerbot on November 11, 2010, 07:55:58 pm
I think I found a bug.
Let's say I have a workspace and it is opened, there are 2 projects (regular C). Names are: Project1, MyLibrary.
Project1 uses some functions from MyLibrary.
I opened a C file from Project1, then right clicked on a function (which can be found within Project1), and select 'Find implementation...', and it jumps right to the implementation of that particular function.
BUT, if I do the same (right click and select 'Find impl..') on a function which can be found in MyLibrary it says "Not found <function name>".
And if I jump to project MyLibrary and try to "Find" that function within this project then everything will be fine. But, again, if I try to find a function "outside" this project then I get a message "Not found ... " :(
If I do the same procedures with 'Find declaration ...' then everything is just fine.

It did work fine with other CodeBlocks builds, but last 2 or 3 beta builds don't work fine.

Or maybe I'm wrong and I need to turn on some special features.
Ideas/comments?


I have noticed this too, indeed this is a nasty problem.
I think this showed up during all the code completion refactorings. Let's hope our CC gurus put their brains too it.
Title: Re: The 07 November 2010 build (6840) is out.
Post by: Loaden on November 12, 2010, 06:38:33 am
I think I found a bug.
Let's say I have a workspace and it is opened, there are 2 projects (regular C). Names are: Project1, MyLibrary.
Project1 uses some functions from MyLibrary.
I opened a C file from Project1, then right clicked on a function (which can be found within Project1), and select 'Find implementation...', and it jumps right to the implementation of that particular function.
BUT, if I do the same (right click and select 'Find impl..') on a function which can be found in MyLibrary it says "Not found <function name>".
And if I jump to project MyLibrary and try to "Find" that function within this project then everything will be fine. But, again, if I try to find a function "outside" this project then I get a message "Not found ... " :(
If I do the same procedures with 'Find declaration ...' then everything is just fine.

It did work fine with other CodeBlocks builds, but last 2 or 3 beta builds don't work fine.

Or maybe I'm wrong and I need to turn on some special features.
Ideas/comments?


I have noticed this too, indeed this is a nasty problem.
I think this showed up during all the code completion refactorings. Let's hope our CC gurus put their brains too it.
You should use two targets, but not two projects.
Because now a project per a parser.
Title: Re: The 07 November 2010 build (6840) is out.
Post by: SotM on November 12, 2010, 08:38:59 am
You should use two targets, but not two projects.
Because now a project per a parser.
Can you explain more? What should I do?
Title: Re: The 07 November 2010 build (6840) is out.
Post by: killerbot on November 12, 2010, 09:01:14 am
It means where in the past most probably there was a parser that parsed all projects in the workspace, and as such had the information of everything available, now there is only 1 parser per project. And it seems the information stays ONLY within that project.

As in your example :
project 1 --> library
project 2 --> executable

Depending on the project that is active, only  1 set of information is available [there are always ripple through because of the header files].

If you would change your setup of your project(s) to only 1 project which then has 2 targets : the library and the executable; then again all the information is available for the code completion.

However, I don't agree to this, I think we should look for a secondary mechanism, to also check the other projects in the workspace. If there are a lot of projects in the workspace such a search might slow down things.
But this limited search has been a pain in the *** ;-)

In all the years that I used CB, or VS for that matter, and all the places I worked at, the typical approachwas : 1 project per library. And this library can be used by many many applications.

So while I am working on application 1, I have a workspace with the code of that executable, together with all the libraries it is using.

Someone else is working on application 2, similar setup. So that means that a library will end up as a project in several workspaces.

If it was a target it could not be shared, unless everything is constantly duplicated, or everything is put into 1 project, but different applications should not end up in the same project. They have nothing to do with one another, even ignoring the fact of the amount of stuff that needs to be parsed in such a case.

So my suggestion, let's have a mechanism that all projects are parsed in the workspace (starting with the active one, the other can be parsed in the background). In case this might however be too high a penalty on performance load, make it a setting so the user can choose to do it this way or not. And in future we can continue to work on speeding things up if needed. Other IDE can also parse this way, so it is possible ;-)

To me this reduced functionality has been troublesome ;-) , but don't forget we did get a lot of improvements on the code completion side in return. So please, pretty please, can we take this one 1 step further on the ladder of improved completion ?

Title: Re: The 07 November 2010 build (6840) is out.
Post by: Loaden on November 12, 2010, 09:29:03 am
Maybe, we can make it configurable, but perhaps exist more issue about one workspace per one parser.
I will trying it if i find some time.
Title: Re: The 07 November 2010 build (6840) is out.
Post by: NerdIII on November 12, 2010, 10:03:29 am
When do you need code completion from another project? It means you use a symbol from some other compilation unit, right? And that can only work if the other project is a library, right? That leads me to the idea that you could extend the code completion object of the application project to also query the code completion objects of all dependent libraries in order to find implementations of exported symbols.
That might be more intuitive after all than using a checkbox to parse "all projects at once", which would lead to lib1 finding implementations in an independent lib2. I'm not so keen on the idea that the code completion loses exactness again, it would be a step backwards.

code completion plugin
-> application (-Lmylib, uses foo())
-> library (-o libmylib.so/mylib.dll, export void foo())

The code completion plugin object sits at the top and when the application cc object cannot find an implementation it could ask the cc plugin object to return
a) the list of libraries the project is linked against and compare the names with the output filename of any open library project (exact match possible).
- or -
b) all dependent library projects.
Then the application cc object queries the found library cc objects for exports with the requested name.
Title: Re: The 07 November 2010 build (6840) is out.
Post by: cacb on November 12, 2010, 07:46:37 pm
Some general observations.

Code::Blocks is getting better and better, but I find some stability issues sometimes  :lol:. These comments refer to Windows XP and using MS Visual Studio 2008 Express compiler.

- When I have many source files and/or wxSmith resource file open at the same time, I often want to close all. This tends to crash Code::Blocks, however  :shock:. I think this is a fairly old problem seen with many nightly builds.

- I keep moving my project files between two machines (both Win XP) and find that C::B is messing with my settings/use of global variables. For example, in my project file I have this

Code
	<Add directory="$(#wx.include)" />
<Add directory="$(#wx)\contrib\include" />
<Add directory="$(#wx)\lib\vc_lib\mswd" />
   
The problem is that C::B tends to replace this with the expanded full path, which obviously does not work on the other machine, so I have to edit the .cbp file over and over again to fix it back to what it was. But it keeps coming back. Mostly, this happens on one machine and not the other, for some reason.

- When I open a workspace, very often I get an error message dialog that I did not use to get with the same setup before:
Quote
cl.exe - Unable To Locate Component
This application has failed to start because mspdb80.dll was not found. Re-installing the application may fix this problem.
OK
Then I have to OK this dialog, and everything is apparently working, including compilation and linking.

I have seen these problems with build 6840, but also with 6752 and earlier.
Title: Re: The 07 November 2010 build (6840) is out.
Post by: cacb on November 12, 2010, 08:39:50 pm
Some general observations.

And one more problem, this one is fairly new but very annoying. It relates to wxSmith. Again seen on WinXP.

If you for example create a wxPanel class and put a wxButton somewhere, you may not want to keep the Button variable as a member of the class, all you care about is the event it generates, and a member button is not needed. To do this, I simply uncheck the "Is member" checkbox in the wxSmith properties area. However: This [always?/sometimes?/often?] silently changes the Identifier of the button from, say ID_BUTTON1 to wxID_ANY and thus causes havoc in the event handling. This is a nasty bug I spent some time figuring out.
Title: Re: The 07 November 2010 build (6840) is out.
Post by: Loaden on November 15, 2010, 03:49:07 pm
To me this reduced functionality has been troublesome ;-) , but don't forget we did get a lot of improvements on the code completion side in return. So please, pretty please, can we take this one 1 step further on the ladder of improved completion ?
Here is an un-complete patch for this issue.
Sorry, I have no time to do it now.
Because some reason, I should leave a time.
If other devs find time, please continue this improve.
Best regards!