Code::Blocks

User forums => Nightly builds => Topic started by: killerbot on January 17, 2010, 09:18:01 am

Title: The 16 January 2010 build (6088) is out.
Post by: killerbot on January 17, 2010, 09:18:01 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.7z

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

The 16 January 2010 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20100116_rev6088_win32.7z
  - Linux :
   none

Resolved Fixed:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 16 January 2010 build (6088) is out.
Post by: blueshake on January 17, 2010, 09:58:52 am
wow,I am the second one to post this thread.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: jens on January 17, 2010, 10:10:05 am
I just moved the debian binaries (32- and 64-bit), sources and documentation packages (german and english) into my repository.

See here (http://apt.jenslody.de) how to use it.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: Loaden on January 17, 2010, 11:19:15 am
 :lol: great!
Title: Re: The 16 January 2010 build (6088) is out.
Post by: Loaden on January 17, 2010, 01:42:42 pm
Hello everyone, I let CB supported the temporary font on Win32, but I do not know how to achieve under Linux.
Please attention, thank you!
http://forums.codeblocks.org/index.php/topic,11876.0.html (http://forums.codeblocks.org/index.php/topic,11876.0.html)
Title: Re: The 16 January 2010 build (6088) is out.
Post by: lucas on January 17, 2010, 02:22:34 pm
Hello everyone,

I have just downloaded and installed this nightly builds just to check out how CC works. In this regard I created a simple C++ console project that includes only the file iostream as it's shown below:

====================
#include <iostream>

using namespace std;

int main()
{
    cout << "Hello world!" << endl;
    return 0;
}
====================

I tried to complete the keyword "cout" but all I got is the following message: C++ parser is stil parsing files. Also I checked in the Windows Task Manager the status of the resources that CodeBlocks were using: CPU at 55% (also the CPU fan was working hard).

Also I unchecked the options "Update parser when typing" but the CPU did not fall under 55% ...

I do not know what exactly did you want to get fixed concerning the code completion (aside the points that you listed) but it seems that with every nightly build the CC plugin is not getting better at all.

Otherwise CB is a great product and it really helps me. Thanks all of you for the hard working.

Best regards,
Lucas
Title: Re: The 16 January 2010 build (6088) is out.
Post by: MortenMacFly on January 17, 2010, 02:28:34 pm
I do not know what exactly did you want to get fixed concerning the code completion (aside the points that you listed) but it seems that with every nightly build the CC plugin is not getting better at all.
Thanks for such valuable feedback.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: ollydbg on January 17, 2010, 04:32:53 pm
@morten: Is it possible to Disable the "real time parse" before the batch parse is done? (whether it is set or unset).
Title: Re: The 16 January 2010 build (6088) is out.
Post by: MortenMacFly on January 17, 2010, 07:21:38 pm
@morten: Is it possible to Disable the "real time parse" before the batch parse is done? (whether it is set or unset).
Not exactly sure what you mean, but if it is disabled in the settings it will be the same for batch parse. If you mean generally disabling this while batch parse is running, this would need to be implemented.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: UsYer on January 17, 2010, 10:02:06 pm
Hi,
I've got a problem with this build. After installing it everythign worked normal as usual. But after closing and trying to reopen CodeBlocks I get the following message: "This application has requested the Runtime to terminate in an unusual way..." I think you this message.
I never had any Issues with the nightlies before and I've no clue what could have caused this error.
I'm using Win7 64Bit.
Anyone else experiencing this?

regards UsYer
Title: Re: The 16 January 2010 build (6088) is out.
Post by: Suryavarman on January 17, 2010, 10:47:02 pm
Under Vista 64 :
Now, it's very slow for edit code.
Every 8 seconds codeblocks is blocked and I can not write for 2 seconds. ( My project : 21K lines )

EDIT :
It's ok.

Configure editor -> Code-Completion and symbols browser-> Update parser when typing = false

:)
Title: Re: The 16 January 2010 build (6088) is out.
Post by: ollydbg on January 18, 2010, 01:12:28 am
@morten I mean the second opinion which disable real time parse while the batch parse was running.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: chao on January 18, 2010, 01:53:48 am
I checked in the Windows Task Manager the status of the resources that CodeBlocks were using: CPU at 55% (also the CPU fan was working hard).

Also I unchecked the options "Update parser when typing" but the CPU did not fall under 55% ...

My CB has the same problem on both xp and vista.
disable "Follow GLOBAL includes"(in C/C++parser settings)  will reduce the CPU usage in my case.
So I guess the code completion plugin caused the problem.
Build 6023 does not have this problem.
(BTW, I don't know much English, and I hope the above words are clear.)
Title: Re: The 16 January 2010 build (6088) is out.
Post by: jens on January 18, 2010, 06:52:11 am
My CB has the same problem on both xp and vista.
disable "Follow GLOBAL includes"(in C/C++parser settings)  will reduce the CPU usage in my case.

What compiler and SDK do you use, when the issue occurs ?
Title: Re: The 16 January 2010 build (6088) is out.
Post by: blueshake on January 18, 2010, 08:09:44 am
I want to ask a question here too.
when the issue happened,does the parser hint that the c++ is still parsing?
Title: Re: The 16 January 2010 build (6088) is out.
Post by: vix on January 18, 2010, 08:30:08 am
I checked in the Windows Task Manager the status of the resources that CodeBlocks were using: CPU at 55% (also the CPU fan was working hard).

Also I unchecked the options "Update parser when typing" but the CPU did not fall under 55% ...
The same for me (WinXP SP2, TDM-MinGW 4.4.1.2).

when the issue happened,does the parser hint that the c++ is still parsing?
Yes, you're right.
After the parsing the CPU consumption falls to 1-2% (as usual).
I tried to disable the Code Completion plugin and there isn't a such high CPU load.
Moreover also this last NB has this problem (http://forums.codeblocks.org/index.php/topic,11790.0.html (http://forums.codeblocks.org/index.php/topic,11790.0.html))
Title: Re: The 16 January 2010 build (6088) is out.
Post by: blueshake on January 18, 2010, 08:35:09 am
Quote
I tried to disable the Code Completion plugin and there isn't a such high CPU load.

you do not need to disable cc,just disable parse while typing. :D
Title: Re: The 16 January 2010 build (6088) is out.
Post by: blueshake on January 18, 2010, 08:38:05 am
can you report  Editor file (about 2000+ lines)which you are typing with real-time parse,how much time dose it cost in your machine?
Title: Re: The 16 January 2010 build (6088) is out.
Post by: lucas on January 18, 2010, 08:51:18 am
The compiler that I used to test the code completion was Visual C++ 2008 on Windows XP SP3.

The code was very simple:

#include <iostream>

using namespace std;

int main()
{
    cout << "Hello world!" << endl;
    return 0;
}

I was trying to auto-complete the keyword "cout".

Regards,
Lucas

I checked in the Windows Task Manager the status of the resources that CodeBlocks were using: CPU at 55% (also the CPU fan was working hard).

Also I unchecked the options "Update parser when typing" but the CPU did not fall under 55% ...
The same for me (WinXP SP2, TDM-MinGW 4.4.1.2).

when the issue happened,does the parser hint that the c++ is still parsing?
Yes, you're right.
After the parsing the CPU consumption falls to 1-2% (as usual).
I tried to disable the Code Completion plugin and there isn't a such high CPU load.
Moreover also this last NB has this problem (http://forums.codeblocks.org/index.php/topic,11790.0.html (http://forums.codeblocks.org/index.php/topic,11790.0.html))
Title: Re: The 16 January 2010 build (6088) is out.
Post by: blueshake on January 18, 2010, 09:02:10 am
The compiler that I used to test the code completion was Visual C++ 2008 on Windows XP SP3.

The code was very simple:

#include <iostream>

using namespace std;

int main()
{
    cout << "Hello world!" << endl;
    return 0;
}

I was trying to auto-complete the keyword "cout".

Regards,
Lucas

I checked in the Windows Task Manager the status of the resources that CodeBlocks were using: CPU at 55% (also the CPU fan was working hard).

Also I unchecked the options "Update parser when typing" but the CPU did not fall under 55% ...
The same for me (WinXP SP2, TDM-MinGW 4.4.1.2).

when the issue happened,does the parser hint that the c++ is still parsing?
Yes, you're right.
After the parsing the CPU consumption falls to 1-2% (as usual).
I tried to disable the Code Completion plugin and there isn't a such high CPU load.
Moreover also this last NB has this problem (http://forums.codeblocks.org/index.php/topic,11790.0.html (http://forums.codeblocks.org/index.php/topic,11790.0.html))


done in this thread.http://forums.codeblocks.org/index.php/topic,11800.msg80725.html#msg80725 (http://forums.codeblocks.org/index.php/topic,11800.msg80725.html#msg80725)
Title: Re: The 16 January 2010 build (6088) is out.
Post by: vix on January 18, 2010, 09:15:57 am
you do not need to disable cc,just disable parse while typing. :D
I didn't explain very weel in my post: I've already disable parse while typing... It was the first thing I did  :D
but unfortunately this don't help  :(

So I disabled the whole plugin.. and  :D  :D
I'm not typing anything, I'm opening the C::B cbp and I see this behaviour
Title: Re: The 16 January 2010 build (6088) is out.
Post by: blueshake on January 18, 2010, 09:28:04 am
@vix

can you try this,just start  c::b application. and then open the cb project and post the output log here 
Title: Re: The 16 January 2010 build (6088) is out.
Post by: lucas on January 18, 2010, 09:28:13 am
I did not explain it very well. The code I wrote down above caused the CB to employ the CPU at a rate of 55% while the single message I got when trying to auto-complete the keyword "cout" was something like that the 'C++ parser is stil parsing the file'.

The problem here is not that the "cout" failed to be auto-completed. The issue I try to present here is that the CB uses a lot of the CPU without getting any result. Also after I unchecked the option "Update parser when typing" the CPU was high.

The test was done using the MSVC 2008 (headers were provided by the standard installation of the MSVC 2008) and the code is minimal (I have not tested it for a large project yet).

Lucas

The compiler that I used to test the code completion was Visual C++ 2008 on Windows XP SP3.

The code was very simple:

#include <iostream>

using namespace std;

int main()
{
    cout << "Hello world!" << endl;
    return 0;
}

I was trying to auto-complete the keyword "cout".

Regards,
Lucas

I checked in the Windows Task Manager the status of the resources that CodeBlocks were using: CPU at 55% (also the CPU fan was working hard).

Also I unchecked the options "Update parser when typing" but the CPU did not fall under 55% ...
The same for me (WinXP SP2, TDM-MinGW 4.4.1.2).

when the issue happened,does the parser hint that the c++ is still parsing?
Yes, you're right.
After the parsing the CPU consumption falls to 1-2% (as usual).
I tried to disable the Code Completion plugin and there isn't a such high CPU load.
Moreover also this last NB has this problem (http://forums.codeblocks.org/index.php/topic,11790.0.html (http://forums.codeblocks.org/index.php/topic,11790.0.html))


done in this thread.http://forums.codeblocks.org/index.php/topic,11800.msg80725.html#msg80725 (http://forums.codeblocks.org/index.php/topic,11800.msg80725.html#msg80725)
Title: Re: The 16 January 2010 build (6088) is out.
Post by: blueshake on January 18, 2010, 09:42:02 am
According to  the users' voices,it seems the issues (the cpu used over 50%) are  all  relative to msvc(vc 2005,vc2008),gcc is working fine.



NOtTE:

I suspect something wrong with the path parse.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: ollydbg on January 18, 2010, 09:42:07 am
@lucas (http://forums.codeblocks.org/index.php?action=profile;u=123).
Do these steps:
1, open your project, in the cpp file, remove or comment the line below(so there's no include directives in the source file):

Code: [Select]
#include <iostream>  

2, the close your project.

3, reopen your project.

And see what happens. Did your CPU still 50% hang?
Title: Re: The 16 January 2010 build (6088) is out.
Post by: vix on January 18, 2010, 09:52:43 am
@vix

can you try this,just start  c::b application. and then open the cb project and post the output log here 
Here you are
Code: [Select]
Initialize EditColourSet .....
Initialize EditColourSet: done.
Loading toolbar...
AStylePlugin: loaded
Autosave: loaded
AutoVersioning: loaded
BrowseTracker: loaded
BYOGames: loaded
CB_Koders: loaded
Cccc: loaded
ClassWizard: loaded
CodeCompletion: loaded
CodeSnippets: loaded
CodeStat: loaded
Compiler: loaded
copystrings: loaded
CppCheck: loaded
Debugger: loaded
FilesExtensionHandler: loaded
DevPakUpdater: loaded
cbDragScroll: loaded
EnvVars: loaded
Exporter: loaded
HeaderFixup: loaded
HelpPlugin: loaded
HexEditor: loaded
IncrementalSearch: loaded
cbKeyBinder: loaded
lib_finder: loaded
MouseSap: loaded
OpenFilesList: loaded
Profiler: loaded
ProjectsImporter: loaded
RegExTestbed: loaded
ScriptedWizard: loaded
SymTab: loaded
ThreadSearch: loaded
ToDoList: loaded
wxSmith: loaded
wxSmithMime: loaded
wxSmithAui: loaded
wxSmithContribItems: loaded
WindowsXPLookNFeel: loaded
Source code formatter (AStyle) plugin activated
Autosave plugin activated
AutoVersioning plugin activated
BrowseTracker plugin activated
Koders query plugin activated
Cccc plugin activated
Class wizard plugin activated
Code completion plugin activated
Code snippets plugin activated
Code statistics plugin activated
Added compiler "GNU GCC Compiler"
Parsing stage done (0 total parsed files, 0 tokens in 0 minute(s), 0.0 seconds).
Updating class browser...
Class browser updated.
Added compiler "Microsoft Visual C++ Toolkit 2003"
Added compiler "Microsoft Visual C++ 2005/2008"
Added compiler "Borland C++ Compiler (5.5, 5.82)"
Added compiler "Digital Mars Compiler"
Added compiler "OpenWatcom (W32) Compiler"
Added compiler "GNU GCC Compiler for MSP430"
Added compiler "Cygwin GCC"
Added compiler "LCC Compiler"
Added compiler "Intel C/C++ Compiler"
Added compiler "SDCC Compiler"
Added compiler "Tiny C Compiler"
Added compiler "GDC D Compiler"
Added compiler "Digital Mars D Compiler"
Added compiler "GNU ARM GCC Compiler"
Added compiler "GNU AVR GCC Compiler"
Added compiler "GNU GCC Compiler for PowerPC"
Added compiler "GNU GCC Compiler for TriCore"
Compiler plugin activated
Copy Strings to clipboard plugin activated
CppCheck plugin activated
Debugger plugin activated
Files extension handler plugin activated
DevPak updater/installer plugin activated
DragScroll plugin activated
Environment variables plugin activated
Source Exporter plugin activated
Header Fixup plugin activated
Help plugin plugin activated
HexEditor plugin activated
IncrementalSearch plugin activated
Keyboard shortcuts plugin activated
Library finder plugin activated
MouseSap plugin activated
Open files list plugin activated
Code profiler plugin activated
Foreign projects importer plugin activated
Regular expressions testbed plugin activated
Project wizard added for 'Empty project'
Project wizard added for 'Console application'
Project wizard added for 'D application'
Project wizard added for 'Direct/X project'
Project wizard added for 'Dynamic Link Library'
Project wizard added for 'Kernel Mode Driver'
Project wizard added for 'FLTK project'
Project wizard added for 'GLFW project'
Project wizard added for 'GLUT project'
Project wizard added for 'GTK+ project'
Project wizard added for 'Irrlicht project'
Project wizard added for 'Lightfeather project'
Project wizard added for 'Matlab project'
Project wizard added for 'OpenGL project'
Project wizard added for 'Ogre project'
Project wizard added for 'Code::Blocks plugin'
Project wizard added for 'QT4 project'
Project wizard added for 'SDL project'
Project wizard added for 'SmartWin project'
Project wizard added for 'Static library'
Project wizard added for 'STL port application'
Project wizard added for 'Shared library'
Project wizard added for 'Win32 GUI project'
Project wizard added for 'wxWidgets project'
Build-target wizard added for 'Console'
Build-target wizard added for 'Static library'
Build-target wizard added for 'Dynamic Link Library'
Build-target wizard added for 'wxWidgets'
Project wizard added for 'ARM Project'
Project wizard added for 'AVR Project'
Project wizard added for 'TriCore Project'
Project wizard added for 'PowerPC Project'
File(s) wizard added for 'Empty file'
File(s) wizard added for 'C/C++ source'
File(s) wizard added for 'C/C++ header'
Scripted wizard plugin activated
Symbol Table Plugin plugin activated
ThreadSearch plugin activated
Todo List plugin activated
wxSmith plugin activated
wxSmith - MIME plugin plugin activated
wxSmith - Aui plugin activated
wxSmith - Contrib Items plugin activated
Windows XP Look'n'Feel plugin activated
Initializing plugins...
Loading workspace "C:\Documents and Settings\viganoe\Dati applicazioni\codeblocks\default.workspace"
Workspace file contains no projects...
Loading project file...
Parsing project file...
Loading target tinyXML
Loading target AutoRevision
Loading target ConsoleRunner
Loading target Squirrel
Loading target Squirrel std lib
Loading target SqPlus
Loading target scintilla
Loading target sdk
Loading target src
Loading target AStyle
Loading target Compiler depslib
Loading target Compiler
Loading target Debugger
Loading target Code-completion
Loading target Class wizard
Loading target Default MIME handler
Loading target Open files list
Loading target Scripted wizard
Loading target To-do
Loading target Autosave
Loading target XP look & feel
Loading target Projects-workspaces importer
Loading project files...
870 files loaded
Done loading project in 250ms
Project's base path: D:\projects\CodeBlocks\src\
Project's common toplevel path: D:\projects\CodeBlocks\src\
Final encoding detected: Windows Western European (CP 1252) (ID: 33)
project data set for D:\projects\CodeBlocks\src\base\tinyxml\tinystr.cpp
Text seems to be pure ASCII!
We use user specified encoding: Windows Western European (CP 1252) (ID: 33)
Final encoding detected: Windows Western European (CP 1252) (ID: 33)
project data set for D:\projects\CodeBlocks\src\sdk\blockallocated.cpp
Text seems to be pure ASCII!
We use user specified encoding: Windows Western European (CP 1252) (ID: 33)
Final encoding detected: Windows Western European (CP 1252) (ID: 33)
project data set for D:\projects\CodeBlocks\src\sdk\cbstyledtextctrl.cpp
Text seems to be pure ASCII!
We use user specified encoding: Windows Western European (CP 1252) (ID: 33)
Final encoding detected: Windows Western European (CP 1252) (ID: 33)
project data set for D:\projects\CodeBlocks\src\sdk\compiletargetbase.cpp
Text seems to be pure ASCII!
We use user specified encoding: Windows Western European (CP 1252) (ID: 33)
Final encoding detected: Windows Western European (CP 1252) (ID: 33)
project data set for D:\projects\CodeBlocks\src\sdk\editarraystringdlg.cpp
Top Editor: D:\projects\CodeBlocks\src\sdk\editarraystringdlg.cpp
Add project Code::Blocks in parsing queue
Caching internal gcc dirs for adding to parser...
Caching GCC dir: c:\MinGW\lib\gcc\mingw32\4.4.1\include\c++
Caching GCC dir: c:\MinGW\lib\gcc\mingw32\4.4.1\include\c++\mingw32
Caching GCC dir: c:\MinGW\lib\gcc\mingw32\4.4.1\include\c++\backward
Caching GCC dir: c:\MinGW\include
Caching GCC dir: c:\MinGW\lib\gcc\mingw32\4.4.1\include
Caching GCC dir: c:\MinGW\lib\gcc\mingw32\4.4.1\include-fixed
Passing list of files to batch-parser.
Batch-parsing 724 file(s)...
Starting batch parsing...
Parsing stage done (1507 total parsed files, 84531 tokens in 0 minute(s), 44.594 seconds).
Updating class browser...
Class browser updated.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: lucas on January 18, 2010, 09:57:34 am
I've just created a simple project but using MinGW-4.4.0 system. Strangely everything is all right now: no CPU high rate, code completion worked.

I do not know why in the case of the MSVC 2008 the things were wrong.

Lucas

@lucas (http://forums.codeblocks.org/index.php?action=profile;u=123).
Do these steps:
1, open your project, in the cpp file, remove or comment the line below(so there's no include directives in the source file):

Code: [Select]
#include <iostream>  

2, the close your project.

3, reopen your project.

And see what happens. Did your CPU still 50% hang?
Title: Re: The 16 January 2010 build (6088) is out.
Post by: ollydbg on January 18, 2010, 10:07:13 am
Quote
Parsing stage done (1507 total parsed files, 84531 tokens in 0 minute(s), 44.594 seconds).
@vix (http://forums.codeblocks.org/index.php?action=profile;u=4098).
So, there is nothing wrong. When your Parser in CodeCompletion were doing Batch parsing, your CPU usage should be 50%. After it finished it's parsing(44.595 seconds later), your CPU usage should be 1-2%.
So, I don't see any thing wrong.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: chao on January 18, 2010, 11:28:17 am
My CB has the same problem on both xp and vista.
disable "Follow GLOBAL includes"(in C/C++parser settings)  will reduce the CPU usage in my case.

What compiler and SDK do you use, when the issue occurs ?
Hello,
I use mingw-g++-4.4, (Mingw installed at C:\Mingw).
It occurs when I just open a project.

I'm not sure what "Follow GLOBAL includes" exactly means.
It seems g++(or CB) can auto-detect the SDK and stl paths and my
CB Compiler settings include paths to boost and wxWidgets.
One project of mine is about 6k lines of code, and it does not use boost or wx,
I do use templates and stl often.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: adfm on January 18, 2010, 11:29:15 am
thanks for the "disable code-completion" setting. I was getting crazy ;)
Title: Re: The 16 January 2010 build (6088) is out.
Post by: vix on January 18, 2010, 01:54:03 pm
So, there is nothing wrong. When your Parser in CodeCompletion were doing Batch parsing, your CPU usage should be 50%. After it finished it's parsing(44.595 seconds later), your CPU usage should be 1-2%.
So, I don't see any thing wrong.
I think you're right: as a matter of fact I can use C::B during this parsing.
But the 4-5 seconds freezing at startup (http://forums.codeblocks.org/index.php/topic,11790.msg80521.html#msg80521 (http://forums.codeblocks.org/index.php/topic,11790.msg80521.html#msg80521)) is still there. Nightly Build 5911 doesn't have this problem
Title: Re: The 16 January 2010 build (6088) is out.
Post by: ollydbg on January 18, 2010, 02:03:28 pm
So, there is nothing wrong. When your Parser in CodeCompletion were doing Batch parsing, your CPU usage should be 50%. After it finished it's parsing(44.595 seconds later), your CPU usage should be 1-2%.
So, I don't see any thing wrong.
I think you're right: as a matter of fact I can use C::B during this parsing.
But the 4-5 seconds freezing at startup (http://forums.codeblocks.org/index.php/topic,11790.msg80521.html#msg80521 (http://forums.codeblocks.org/index.php/topic,11790.msg80521.html#msg80521)) is still there. Nightly Build 5911 doesn't have this problem
Yes, agreed. I still guess something wrong when a project was loading :).
Title: Re: The 16 January 2010 build (6088) is out.
Post by: blueshake on January 18, 2010, 02:19:04 pm
I encounter this issue too,when I start the C::B applicatioin, it take a long time to get ready for work. :D
Title: Re: The 16 January 2010 build (6088) is out.
Post by: afb on January 18, 2010, 05:28:45 pm
- Mac OS X 10.4 - 10.6: (32-bit Universal ppc/x86 with wxWidgets 2.8.10 + patch (http://wiki.wxwidgets.org/Development:_wxMac#Building_under_10.6_Snow_Leopard))
    http://prdownload.berlios.de/codeblocks/CB_20100116_rev6088_mac2810.zip

Note that you will also need Xcode Tools installed to get GCC and SDK and such.
These are bundled by Apple with the Mac OS X operating system, updated at ADC (http://connect.apple.com).
Title: Re: The 16 January 2010 build (6088) is out.
Post by: Loaden on January 18, 2010, 05:58:47 pm
In the creation wizard does not support this macro replacement.
But if change $(TARGET_COMPILER_DIR) to $(CODEBLOCKS),it's work fine.
Please fix it, thanks!

[attachment deleted by admin]
Title: Re: The 16 January 2010 build (6088) is out.
Post by: private_joker on January 18, 2010, 06:11:04 pm
Hello everyone,

I have just downloaded and installed this nightly builds just to check out how CC works. In this regard I created a simple C++ console project that includes only the file iostream as it's shown below:

====================
#include <iostream>

using namespace std;

int main()
{
    cout << "Hello world!" << endl;
    return 0;
}
====================

I tried to complete the keyword "cout" but all I got is the following message: C++ parser is stil parsing files. Also I checked in the Windows Task Manager the status of the resources that CodeBlocks were using: CPU at 55% (also the CPU fan was working hard).

Also I unchecked the options "Update parser when typing" but the CPU did not fall under 55% ...

I do not know what exactly did you want to get fixed concerning the code completion (aside the points that you listed) but it seems that with every nightly build the CC plugin is not getting better at all.

Otherwise CB is a great product and it really helps me. Thanks all of you for the hard working.

Best regards,
Lucas
Hi, I experienced same problem: http://forums.codeblocks.org/index.php/topic,11827.0.html (http://forums.codeblocks.org/index.php/topic,11827.0.html) and http://developer.berlios.de/bugs/?func=detailbug&bug_id=16647&group_id=5358 (http://developer.berlios.de/bugs/?func=detailbug&bug_id=16647&group_id=5358)
I heard only 2 things:
1) All is Ok (on Ubuntu)
2) All is Ok (on MinGW)
So that pretty "good".

-----------------------------------------

According to  the users' voices,it seems the issues (the cpu used over 50%) are  all  relative to msvc(vc 2005,vc2008),gcc is working fine.



NOtTE:

I suspect something wrong with the path parse.

Hi, i have only 3 small question for you:
1. Did You see it? ( http://developer.berlios.de/bugs/?func=detailbug&bug_id=16647&group_id=5358 ), I guess - YES. Is  "issues" is NOT reprodused in 6023 (latest SVN rev. w/o broken CC).
2. "gcc is working fine" Hmmm... CB designed and works only w. GCC? I guess - NOT.
3. Where I can see a fresh "Roadmap" or something similar.

CB is pretty good IDE, but last time... Something going wrong, I guess in developers team crept devs from M$ ;)

Title: Re: The 16 January 2010 build (6088) is out.
Post by: InsidE on January 18, 2010, 06:58:29 pm
I tried to complete the keyword "cout" but all I got is the following message: C++ parser is stil parsing files. Also I checked in the Windows Task Manager the status of the resources that CodeBlocks were using: CPU at 55% (also the CPU fan was working hard).

Also I unchecked the options "Update parser when typing" but the CPU did not fall under 55% ...

i have the same bug.
system : XP SP3

EDIT:
using ms sdk for sever 2008( 6.1 )
Title: Re: The 16 January 2010 build (6088) is out.
Post by: lucas on January 18, 2010, 07:11:28 pm
Hello,

I re-tested the code completion using MSVC2008. The behaviour is the same: no code completion, CPU over 50%.
However the problem does not occur with MinGW (4.4.0 in my case).

So I can confirm the following: well is good in the world of GCC (MinGW) :) The other side is doomed at this moment :)

Lucas

I've just created a simple project but using MinGW-4.4.0 system. Strangely everything is all right now: no CPU high rate, code completion worked.

I do not know why in the case of the MSVC 2008 the things were wrong.

Lucas

@lucas (http://forums.codeblocks.org/index.php?action=profile;u=123).
Do these steps:
1, open your project, in the cpp file, remove or comment the line below(so there's no include directives in the source file):

Code: [Select]
#include <iostream>  

2, the close your project.

3, reopen your project.

And see what happens. Did your CPU still 50% hang?
Title: Re: The 16 January 2010 build (6088) is out.
Post by: Folco on January 18, 2010, 07:40:49 pm
I have selected the option "Home key always moves carret to first column" in Settings -> General Settings -> Other Options.
But it doesn't seem to work : when I press the Home key, the carret is set at the first char (after the identation, not at the first column of the line).

Someone could confirm that ?
(Fedora 12, current nightly)
Title: Re: The 16 January 2010 build (6088) is out.
Post by: Zini on January 18, 2010, 07:50:10 pm
Comfirmed. Ubuntu 9.04 (64 bit). Broke about a year ago, I think. Here is the bug report:

http://developer.berlios.de/bugs/?func=detailbug&bug_id=15359&group_id=5358
Title: Re: The 16 January 2010 build (6088) is out.
Post by: blueshake on January 19, 2010, 02:22:19 am
Quote
Hi, i have only 3 small question for you:
1. Did You see it? ( http://developer.berlios.de/bugs/?func=detailbug&bug_id=16647&group_id=5358 ), I guess - YES. Is  "issues" is NOT reprodused in 6023 (latest SVN rev. w/o broken CC).
2. "gcc is working fine" Hmmm... CB designed and works only w. GCC? I guess - NOT.
3. Where I can see a fresh "Roadmap" or something similar.

CB is pretty good IDE, but last time... Something going wrong, I guess in developers team crept devs from M$ Wink


you may misunderstand my meaning.I just try to point out what the issue is.not mean to say cb is designed only for gcc.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: Loaden on January 19, 2010, 03:39:40 am
I can confirm it, SVN 6089.
Please download this CB pack, and unpack it to D:\LoveDEV.
http://ppn.googlecode.com/files/LoveDEV.7z (http://ppn.googlecode.com/files/LoveDEV.7z) Contains VC9 compiler, I promise there is no virus, there is no malicious code.
if create a VC project, CPU is 50%.
Code: [Select]
#include <iostream>
#include <windows.h>
#include <winbase.h>

using namespace std;

int main()
{
    ::
    cout << "Hello world!" << endl;
    return 0;
}

[attachment deleted by admin]
Title: Re: The 16 January 2010 build (6088) is out.
Post by: ollydbg on January 19, 2010, 07:35:47 am
@all.
I find the bug why the parser get stuck when parsing the VC 2005 header files:
Here is the detailed report.

I found that the parser in CC will loop infinitively in parsing these code:

in the header file: vc\include\crtdefs.h, around line: 2043.

Code: [Select]
typedef struct localeinfo_struct
{
    pthreadlocinfo locinfo;
    pthreadmbcinfo mbcinfo;
} _locale_tstruct, *_locale_t;

and the bug seems in the void ParserThread::HandleTypedef(), there is a while loop in this function.
Code: [Select]
void ParserThread::HandleTypedef(){
...
while(true)
{
        token = m_Tokenizer.GetToken();
        peek = m_Tokenizer.PeekToken();
......
}

}

Unluckily, this is a infinit loop, and we can't break the loop. each time, we will get the token = "_locale_tstruct" and peek = "," , So, this is the REASON why many C::B users who use VC compilers will get their IDE hangs.

So, there is a logic error in handling typedef statement....

Title: Re: The 16 January 2010 build (6088) is out.
Post by: critic on January 19, 2010, 11:16:50 am
I think this is strange behaviour of CC:
Code: [Select]
std::string().append("").append("").append(""). // and etc

The more recurces I use the slower CC works. Why? After last point in the example I waited about 15 seconds. And so on.
Can it be eliminated?
Title: Re: The 16 January 2010 build (6088) is out.
Post by: critic on January 19, 2010, 11:32:34 am
Question to developers: can you change color of selected line text in window shown by Ctrl+Tab or use system setting?
In various system menus selected item highlighted by dark blue color (for example) and item's text font - by white (when item is not selected - font color is black). This issue appears because of that I can't see selected element :shock:
Title: Re: The 16 January 2010 build (6088) is out.
Post by: blueshake on January 19, 2010, 11:37:36 am
I think this is strange behaviour of CC:
Code: [Select]
std::string().append("").append("").append(""). // and etc

The more recurces I use the slower CC works. Why? After last point in the example I waited about 15 seconds. And so on.
Can it be eliminated?


of course this will slow down the search process.you can see that 5 items will be searched.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: critic on January 19, 2010, 11:55:44 am
But in Eclipse the same example works fine with 20 and over recursions. Is it's CC engine independent of recursions count?  :?
Title: Re: The 16 January 2010 build (6088) is out.
Post by: jens on January 19, 2010, 12:23:39 pm
Would it be possible to remember the last x search results if no reparsing has been done in the meantime and first search in the results-list (map or whatever is the best for this purpose) ?
After reparsing this list should be either cleared or updated.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: MortenMacFly on January 19, 2010, 12:42:06 pm
I find the bug why the parser get stuck when parsing the VC 2005 header files:
Well done.

So, there is a logic error in handling typedef statement....
True.
You pointed correctly to:
Code: [Select]
void ParserThread::HandleTypedef(){
...
while(true)
{
        token = m_Tokenizer.GetToken();
        peek = m_Tokenizer.PeekToken();
......
        else if (peek == ParserConsts::comma)
        {
            m_Tokenizer.UngetToken();
            if (components.size() != 0)
            {
......
}
Just from a quick look I've added the other "bad" part. I'll look into it and try to reproduce.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: blueshake on January 19, 2010, 01:01:28 pm
@morten

you can try this patch:


Code: [Select]
Index: src/plugins/codecompletion/parser/parserthread.cpp
===================================================================
--- src/plugins/codecompletion/parser/parserthread.cpp (revision 6090)
+++ src/plugins/codecompletion/parser/parserthread.cpp (working copy)
@@ -1803,19 +1803,20 @@
         else if (peek == ParserConsts::comma)
         {
             m_Tokenizer.UngetToken();
+
             if (components.size() != 0)
             {
                 wxString ancestor;
                 while (components.size() > 0)
                 {
-                    wxString token = components.front();
+                    wxString tempToken = components.front();
                     components.pop();
 
                     if (!ancestor.IsEmpty())
                         ancestor << _T(' ');
-                    ancestor << token;
-                    ReadClsNames(ancestor);
+                    ancestor << tempToken;
                 }
+                ReadClsNames(ancestor);
             }
         }
         else if (token == ParserConsts::kw_enum)
@@ -1989,11 +1990,9 @@
         else if (current == _T("*"))
         {
             m_IsPointer = true;
-            continue;
+            //continue;
         }
-        else if (   wxIsalpha(current.GetChar(0))
-                 && (   (m_Tokenizer.PeekToken() == ParserConsts::semicolon)
-                     || (m_Tokenizer.PeekToken() == ParserConsts::comma)) )
+        else if ((wxIsalpha(current.GetChar(0)) || current.GetChar(0) == '_') )
         {
             TRACE(_T("ReadClsNames() : Adding variable '%s' as '%s' to '%s'"),
                   current.wx_str(),
@@ -2014,6 +2013,7 @@
             m_Tokenizer.UngetToken();
             break;
         }
+
     }
 }
 
Title: Re: The 16 January 2010 build (6088) is out.
Post by: blueshake on January 19, 2010, 01:04:22 pm
I have discussed this with ollydbg,to avoid you do the second time of the issue.I put it here,not test it seriously. :D
Title: Re: The 16 January 2010 build (6088) is out.
Post by: oBFusCATed on January 19, 2010, 01:14:20 pm
I have discussed this with ollydbg,to avoid you do the second time of the issue.I put it here,not test it seriously. :D

Morten don't you think there is a need for another CC branch?
Title: Re: The 16 January 2010 build (6088) is out.
Post by: MortenMacFly on January 19, 2010, 01:59:30 pm
Morten don't you think there is a need for another CC branch?
I thought about that already (a lot!)... But I won't be able to maintain another branch, I am already trying hard to keep 4 different copies in sync. As you see: Not without errors. ;-)

However, we still have the CC branch. So all what's needed is to re-active it by merging from trunk. I'll see what I can do...
Title: Re: The 16 January 2010 build (6088) is out.
Post by: ollydbg on January 19, 2010, 02:15:03 pm
Morten don't you think there is a need for another CC branch?
I thought about that already (a lot!)... But I won't be able to maintain another branch, I am already trying hard to keep 4 different copies in sync. As you see: Not without errors. ;-)

However, we still have the CC branch. So all what's needed is to re-active it by merging from trunk. I'll see what I can do...
If you re-active the CC branch, please write a post in the CodeCompletion redesign sub-forum. :D
Title: Re: The 16 January 2010 build (6088) is out.
Post by: MortenMacFly on January 19, 2010, 02:22:35 pm
Why did you do this:
Code: [Select]
Index: src/plugins/codecompletion/parser/parserthread.cpp
===================================================================
--- src/plugins/codecompletion/parser/parserthread.cpp (revision 6090)
+++ src/plugins/codecompletion/parser/parserthread.cpp (working copy)
@@ -1989,11 +1990,9 @@
         else if (current == _T("*"))
         {
             m_IsPointer = true;
-            continue;
+            //continue;
         }
-        else if (   wxIsalpha(current.GetChar(0))
-                 && (   (m_Tokenizer.PeekToken() == ParserConsts::semicolon)
-                     || (m_Tokenizer.PeekToken() == ParserConsts::comma)) )
+        else if ((wxIsalpha(current.GetChar(0)) || current.GetChar(0) == '_') )
         {
             TRACE(_T("ReadClsNames() : Adding variable '%s' as '%s' to '%s'"),
                   current.wx_str(),
@@ -2014,6 +2013,7 @@
             m_Tokenizer.UngetToken();
             break;
         }
+
     }
 }
 
?!
How is this related to the typedef problem?

BTW: Did you notice the similarity between the ReadClsNames() and ReadVarNames() method?
Title: Re: The 16 January 2010 build (6088) is out.
Post by: blueshake on January 19, 2010, 02:30:58 pm
Quote
BTW: Did you notice the similarity between the ReadClsNames() and ReadVarNames() method?


yes.



actually the issue is caused by the ReadClsNames(most) in the typedef handle. :D

the codes below:

Code: [Select]
-        else if (   wxIsalpha(current.GetChar(0))
-                 && (   (m_Tokenizer.PeekToken() == ParserConsts::semicolon)
-                     || (m_Tokenizer.PeekToken() == ParserConsts::comma)) )



if you debug,you will find that if condition cannt be got in and cause the infinite loop.



of course the codes have effor on it too.

Code: [Select]
                    if (!ancestor.IsEmpty())
                         ancestor << _T(' ');
-                    ancestor << token;
-                    ReadClsNames(ancestor);
Title: Re: The 16 January 2010 build (6088) is out.
Post by: Loaden on January 19, 2010, 03:57:54 pm
Two questions.
1. Global namepace there are problems with the plug-sshot-1.png. This problem has been resolved here:http://forums.codeblocks.org/index.php/topic,11804.msg80702.html#msg80702 (http://forums.codeblocks.org/index.php/topic,11804.msg80702.html#msg80702)
Code: [Select]
#include <iostream>
#include <windows.h>
#include <winbase.h>
#include <string>
#include <map>
#include <vector>

int main()
{
    ::
    return 0;
}

[attachment deleted by admin]
Title: Re: The 16 January 2010 build (6088) is out.
Post by: Loaden on January 19, 2010, 04:02:17 pm
2. VC project, CPU still 50% overload.

I found here, is not change:
Code: [Select]
-        else if (   wxIsalpha(current.GetChar(0))
-                 && (   (m_Tokenizer.PeekToken() == ParserConsts::semicolon)
-                     || (m_Tokenizer.PeekToken() == ParserConsts::comma)) )
+        else if ((wxIsalpha(current.GetChar(0)) || current.GetChar(0) == '_') )
         {
             TRACE(_T("ReadClsNames() : Adding variable '%s' as '%s' to '%s'"),
                   current.wx_str(),
@@ -2014,6 +2013,7 @@
             m_Tokenizer.UngetToken();
             break;
         }
+

The code here looks not applied. If you modify the code here, it can solve the CPU overload.

and here:
        else if (token  == _T("*"))
        {
            m_IsPointer = false;
            continue;
        }
        else if (peek == ParserConsts::comma)
        {
            m_Tokenizer.UngetToken();
            if (components.size() != 0)
            {
                wxString ancestor;
                while (components.size() > 0)
                {
                    wxString token = components.front();
                    components.pop();

                    if (!ancestor.IsEmpty())
                        ancestor << _T(' ');
                    ancestor << token;
                }
                ReadClsNames(ancestor);
            }

token variables at different scope, readability is not good.

[attachment deleted by admin]
Title: Re: The 16 January 2010 build (6088) is out.
Post by: Xaviou on January 20, 2010, 08:34:12 am
Ubuntu 8.04 to 9.10 Amd64 tar.gz archive (containing '.deb' installers builds with wx2810 from wxWidgets's repository) can be found  here (http://www.archive-host.com/compteur.php?url=http://codeblocks.archive-host.com/CB_20100115_802_rev6088_Ubuntu704-910_wx2810_amd64tar.gz).
".mo" file for french translation can be founded here (http://www.archive-host.com/compteur.php?url=http://codeblocks.archive-host.com/CB_20100116_rev6088_fr.zip) (see below for installation instructions)
Full Win32 French Version (including wxWidgets and MinGW dlls and french ".mo" files) can be founded here (http://www.archive-host.com/compteur.php?url=http://codeblocks.archive-host.com/CB_20100116_rev6088_win32_fr.7z)

Installing french files:

Regards
Xav'
Title: Re: The 16 January 2010 build (6088) is out.
Post by: pasgui on January 20, 2010, 10:14:01 am
Build for Ubuntu i386/amd64 can be found here (http://lgp203.free.fr/ubuntu) (howto (http://lgp203.free.fr/spip/spip.php?article1))

wxWidgets for amd64:
- From Hardy Heron 8.04 to Jaunty Jacklope 9.04: wxWidgets from http://www.wxwidgets.org (http://www.wxwidgets.org) (howto (http://lgp203.free.fr/spip/spip.php?article1))
- For Karmic Koala 9.10: wxWidgets from http://www.wxwidgets.org (http://www.wxwidgets.org) with jaunty-wx for the distribution (howto (http://lgp203.free.fr/spip/spip.php?article1))
wxWidgets for i386:
- From Hardy Heron 8.04 to Jaunty Jacklope 9.04: wxWidgets from http://www.wxwidgets.org (http://www.wxwidgets.org) (howto (http://lgp203.free.fr/spip/spip.php?article1))
- For Karmic Koala 9.10: wxWidgets from Ubuntu (universe)

Also included in the codeblocks-fr package (in the same repository), the french translation.

Best regards, pasgui
Title: Re: The 16 January 2010 build (6088) is out.
Post by: sbezgodov on January 20, 2010, 01:53:07 pm
I have following bug. When class browsers filter is "All local symbols (Workspace)", you can see that symbol list is same as using "Everything" filter. Is doesn't depend on projects quantity in workspace.
rev.6088 and rev.6080 has this bug, but rev.6023 nighty build works fine.

Can anyone confirm? Thanks.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: Micool121 on January 21, 2010, 12:01:36 am
build 6088: class functions parameters are not parsed anymore :

for example:

Code: [Select]
spsysModelSystem * xmlInterface::parseSystem(QDomElement element)
{
    int i;
    systLayout * defaultLayout;
    QDomElement defLayoutElmt = element.firstChildElement("systLayout");

....
}
QDomElement class is not recognised anymore for "element"... it worked in previous build...
Title: Re: The 16 January 2010 build (6088) is out.
Post by: ollydbg on January 21, 2010, 01:10:02 am
Would it be possible to remember the last x search results if no reparsing has been done in the meantime and first search in the results-list (map or whatever is the best for this purpose) ?
After reparsing this list should be either cleared or updated.
hi, jens, i am not fully understand what is this suggestion means. we always do a search under a scope, so different search keywords have different scopes, how can we remember the search result?
Title: Re: The 16 January 2010 build (6088) is out.
Post by: ollydbg on January 21, 2010, 02:20:51 am
build 6088: class functions parameters are not parsed anymore :

for example:

Code: [Select]
spsysModelSystem * xmlInterface::parseSystem(QDomElement element)
{
    int i;
    systLayout * defaultLayout;
    QDomElement defLayoutElmt = element.firstChildElement("systLayout");

....
}
QDomElement class is not recognised anymore for "element"... it worked in previous build...

It works fine here on my own build rev 6091. You can see the screen shot below, with the test code:
Code: [Select]
class QDomElement
{
public:
    int aaaaa;
    int bbbbb;
};


spsysModelSystem * xmlInterface::parseSystem(QDomElement element)
{
    int i;
    systLayout * defaultLayout;
    QDomElement defLayoutElmt = element.
}


Edit
See the log of rev 6091 in trunk:

Code: [Select]
* CC: fixed bug with not parsing function arguments anymore (thanks OllyDbg)
So, I think it has already fixed in the trunk. So you can build your own C::B, or wait a moment for the next nightly build.


[attachment deleted by admin]
Title: Re: The 16 January 2010 build (6088) is out.
Post by: ollydbg on January 21, 2010, 02:25:43 am
I have following bug. When class browsers filter is "All local symbols (Workspace)", you can see that symbol list is same as using "Everything" filter. Is doesn't depend on projects quantity in workspace.
rev.6088 and rev.6080 has this bug, but rev.6023 nighty build works fine.

Can anyone confirm? Thanks.


If you supply a simple test case, I will test for you. Thanks.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: sbezgodov on January 21, 2010, 10:38:22 am
If you supply a simple test case, I will test for you. Thanks.

Just open hello world project or CB ContribPlugins workspace and you will see it when parsing is done. Look at attached images.
There is also TokenMatchesFilter() function in class browser, but seems that it was not changed in latest revisions. I think that token's m_IsLocal flag is not correctly set. What is the meaning of this flag? Seems it determines file is found in workspace or not.

[attachment deleted by admin]
Title: Re: The 16 January 2010 build (6088) is out.
Post by: jens on January 21, 2010, 01:32:30 pm
If you supply a simple test case, I will test for you. Thanks.

Just open hello world project or CB ContribPlugins workspace and you will see it when parsing is done. Look at attached images.

Confirmed on linux.

This bug might be related to another issue, where the ide is unaccessible for some seconds on startup.
At least if the symbols-browser normally shows "All local symbols", and now shows "Everything" instead, because loading into the symbols-browser takes much longer and locks the IDE until it's finished.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: ollydbg on January 21, 2010, 04:00:09 pm
@jens and sbezgodov
I read some source code about the m_IsLocal.
Code: [Select]
void ParserThread::HandleIncludes()
{
    wxString filename;
    bool isGlobal = !m_IsLocal;
    wxString token = m_Tokenizer.GetToken();
    // now token holds something like:
    // "someheader.h"
    // < and will follow iostream.h, >
    if (TestDestroy())
        return;

    if (!token.IsEmpty())
    {
        if (token.GetChar(0) == '"')
        {
            // "someheader.h"
            // don't use wxString::Replace(); it's too costly
            size_t pos = 0;
            while (pos < token.Length())
            {
                wxChar c = token.GetChar(pos);
                if (c != _T('"'))
                    filename << c;
                ++pos;
            }
        }
        else if (token.GetChar(0) == '<')
        {
            isGlobal = true;
            // next token is filename, next is . (dot), next is extension
            // basically we'll loop until >
            while (1)
            {
                token = m_Tokenizer.GetToken();
                if (token.IsEmpty())
                    break;
                if (token.GetChar(0) != '>')
                    filename << token;
                else
                    break;
            }
        }
    }

    if (!filename.IsEmpty())
    {
        TRACE(F(_T("HandleIncludes() : Found include file '%s'"), filename.wx_str()));
        do
        {
            // setting all #includes as global
            // it's amazing how many projects use #include "..." for global headers (MSVC mainly - booh)
            isGlobal = true;

            if (!(isGlobal ? m_Options.followGlobalIncludes : m_Options.followLocalIncludes))
                break; // Nothing to do!

            wxString real_filename = m_pParent->GetFullFileName(m_Filename, filename, isGlobal);
            // Parser::GetFullFileName is thread-safe :)

            if (real_filename.IsEmpty())
                break; // File not found, do nothing.

            {
                wxCriticalSectionLocker lock(s_MutexProtection);
                if (m_pTokensTree->IsFileParsed(real_filename))
                    break; // Already being parsed elsewhere
            }

            TRACE(F(_T("HandleIncludes() : Adding include file '%s'"), real_filename.wx_str()));
            // since we 'll be calling directly the parser's method, let's make it thread-safe
            {
                wxCriticalSectionLocker lock2(s_mutexListProtection);
                m_pParent->DoParseFile(real_filename, isGlobal);
            }
        } while (false);
    }
}

So, most Tokens in header files should be global (not local), only files belong to the workspace is local. Is there something wrong in handling include files?...
Title: Re: The 16 January 2010 build (6088) is out.
Post by: MortenMacFly on January 21, 2010, 05:26:03 pm
Code: [Select]
            // setting all #includes as global
            // it's amazing how many projects use #include "..." for global headers (MSVC mainly - booh)
            isGlobal = true;
That makes it quite clear: We set all files to global as usually there is no strict usage of <> and "". So if we are strict users (of MSVC) will complain.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: jens on January 21, 2010, 09:14:34 pm
I think I found the cause for the local workspace bug, this patch should correct it:
Code: [Select]
--- tmp/tmpVBbR0I-meld/parser.cpp
+++ home/jens/codeblocks-build/codeblocks.trunk/src/plugins/codecompletion/parser/parser.cpp
@@ -964,7 +964,7 @@
         return;
 
     LoaderBase* loader = 0; // defer loading until later
-    Parse(filename, isGlobal, loader);
+    Parse(filename, !isGlobal, loader);
 }
 
 void Parser::StartStopWatch()

The old line was:
Code: [Select]
    Parse(filename, flags == 0, loader); // isLocal = (flags==0)
@Morten:
please have a look.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: MortenMacFly on January 22, 2010, 11:10:24 am
@Morten:
please have a look.
That seems correct... hmmm... another bug introduced by me when actually simplifying things. I should be more careful. I'll commit the collected bug fixes in a minute.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: ollydbg on January 22, 2010, 02:28:25 pm
@morten:
Current SVN still failed in parsing VC++ headers.
See here and the patch: Re: The 16 January 2010 build (6088) is out. (http://forums.codeblocks.org/index.php/topic,11875.msg80805.html#msg80805) :D
Title: Re: The 16 January 2010 build (6088) is out.
Post by: MortenMacFly on January 22, 2010, 02:44:31 pm
@morten:
Current SVN still failed in parsing VC++ headers.
I know. However, I am hardly trying to commit. But BerliOS doesn't let me at the moment. Access is not granted and won't be for some time. I don't know when I am able to commit again.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: Loaden on January 24, 2010, 06:15:16 am
SVN6110, wxSmith
..\..\..\include\cbstyledtextctrl.h|9|error: wx/wxscintilla.h: No such file or directory|

lost search path
Code: [Select]
..\..\..\sdk\wxscintilla\include
wxSmith - Aui
D:\CodeBlocks\src\plugins\contrib\wxSmithAui\wxSmithAui.cpp|1|warning: ..\..\..\include/sdk.h.gch: not used because `CB_PRECOMP' not defined|
Title: Re: The 16 January 2010 build (6088) is out.
Post by: fprijatelj on January 24, 2010, 10:27:56 am
Hi

My platform   win-XP

1. Build, or Rebuild, looses my ENVIRONMENT settings.
If I go to Project/Properties/EnvVars and click ok  and then  run program everything is OK.
After new build, I have to repeat the upper procedure.

2. QT4 Project has only mingw option.
   From 4.6 Nokia distributes both mingw and MSVC versions of lib.


BRGS
Franček



Title: Re: The 16 January 2010 build (6088) is out.
Post by: MortenMacFly on January 24, 2010, 01:56:13 pm
1. Build, or Rebuild, looses my ENVIRONMENT settings.
Enable the debugging in the envvars plugin and inspect the debug log what actually happens. I cannot reproduce.

2. QT4 Project has only mingw option.
   From 4.6 Nokia distributes both mingw and MSVC versions of lib.
You can enhance the wizard in any way you like. Just right-clock on it and select "edit". Feel free to add msvc support and provide a patch / updated wizard.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: Loaden on January 24, 2010, 04:33:52 pm
Hi, Morten, can you apply of the temporary font patch?
Code: [Select]
Index: app.cpp
===================================================================
--- app.cpp (revision 6112)
+++ app.cpp (working copy)
@@ -675,6 +675,17 @@
         }
         Manager::ProcessPendingEvents();
 
+#ifdef __WXMSW__
+        wxString fontPath = GetAppPath() + _T("/share/CodeBlocks/fonts/*.*");
+        wxString font = wxFindFirstFile(fontPath);
+        while (!font.IsEmpty())
+        {
+            ::AddFontResource(font);
+            font = wxFindNextFile();
+        }
+        ::SendMessage(HWND_BROADCAST, WM_FONTCHANGE, 0, 0);
+#endif
+
         // finally, show the app
         splash.Hide();
         SetTopWindow(frame);
@@ -733,6 +744,17 @@
     // ultimate shutdown...
     Manager::Free();
 
+#ifdef __WXMSW__
+        wxString fontPath = GetAppPath() + _T("/share/CodeBlocks/fonts/*.*");
+        wxString font = wxFindFirstFile(fontPath);
+        while (!font.IsEmpty())
+        {
+            ::RemoveFontResource(font);
+            font = wxFindNextFile();
+        }
+        ::SendMessage(HWND_BROADCAST, WM_FONTCHANGE, 0, 0);
+#endif
+
     // WX docs say that this function's return value is ignored,
     // but we return our value anyway. It might not be ignored at some point...
     return m_Batch ? m_BatchExitCode : 0;

[attachment deleted by admin]
Title: Re: The 16 January 2010 build (6088) is out.
Post by: MortenMacFly on January 24, 2010, 04:41:02 pm
Hi, Morten, can you apply of the temporary font patch?
If it's temporary, why should I apply it? :shock:
Title: Re: The 16 January 2010 build (6088) is out.
Post by: Loaden on January 24, 2010, 04:44:19 pm
About AStyle plugin, Here is a new problem:http://forums.codeblocks.org/index.php/topic,11847.0.html (http://forums.codeblocks.org/index.php/topic,11847.0.html)
Title: Re: The 16 January 2010 build (6088) is out.
Post by: Loaden on January 24, 2010, 04:45:08 pm
Hi, Morten, can you apply of the temporary font patch?
If it's temporary, why should I apply it? :shock:
Because CB can be portable, but if the target machine does not have CB set the font how to do?
For example, Dejuva the fonts in the Windows platform is not installed.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: MortenMacFly on January 24, 2010, 04:48:07 pm
For example, Dejuva the fonts in the Windows platform is not installed.
C::B runs just fine on Windows without Dejuva, even portable. Probably I don't get what you are trying to tell, but font management is handled by wxWidgets just fine. Why do we need an own layer? Could you re-phrase the explanation please?
Title: Re: The 16 January 2010 build (6088) is out.
Post by: Biplab on January 24, 2010, 05:01:20 pm
For example, Dejuva the fonts in the Windows platform is not installed.
C::B runs just fine on Windows without Dejuva, even portable. Probably I don't get what you are trying to tell, but font management is handled by wxWidgets just fine. Why do we need an own layer? Could you re-phrase the explanation please?

Possibly he wants to add the feature to support loading of fonts (not installed in the system) from share folder. :)
Title: Re: The 16 January 2010 build (6088) is out.
Post by: Loaden on January 24, 2010, 05:08:05 pm
For example, Dejuva the fonts in the Windows platform is not installed.
C::B runs just fine on Windows without Dejuva, even portable. Probably I don't get what you are trying to tell, but font management is handled by wxWidgets just fine. Why do we need an own layer? Could you re-phrase the explanation please?

Possibly he wants to add the feature to support loading of fonts (not installed in the system) from share folder. :)
Yes, this is what I want to express.

[attachment deleted by admin]
Title: Re: The 16 January 2010 build (6088) is out.
Post by: MortenMacFly on January 24, 2010, 06:45:39 pm
Possibly he wants to add the feature to support loading of fonts (not installed in the system) from share folder. :)
Ok. Got that point. But still: Why shall this be temporarily? I mean if it's only temporarily when shall we remove that option again, and why?! Isn't it better you (Loaden) keep in your local copy until you don't need it anymore?
Title: Re: The 16 January 2010 build (6088) is out.
Post by: Loaden on January 25, 2010, 01:00:29 am
Possibly he wants to add the feature to support loading of fonts (not installed in the system) from share folder. :)
Ok. Got that point. But still: Why shall this be temporarily? I mean if it's only temporarily when shall we remove that option again, and why?! Isn't it better you (Loaden) keep in your local copy until you don't need it anymore?
OK!
But this feature is still valuable, such as OpenOffice.org have the same feature.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: blueshake on January 25, 2010, 02:55:13 am
hi,morten:

I think what Loaden's word "temprary" is :

because he(Loaden) build an comtable version of c::b.he want to add such a festure that support loading
fonts dirctly from the relative fonts path of c::b(e.g. ..share\fonts\).

why we need to do this?

assumpt that the operation system which we used don't contain the fonts(e.g. Dejuva),so if you want to use this font,you have to copy the fonts(you want to use) to system folder.but sometime you don't have the authoration to do that.So if the c::b have the ability to  do this(loading fonts from its folder).it will be much better. :D
Title: Re: The 16 January 2010 build (6088) is out.
Post by: Loaden on January 25, 2010, 04:53:25 am
hi,morten:

I think what Loaden's word "temprary" is :

because he(Loaden) build an comtable version of c::b.he want to add such a festure that support loading
fonts dirctly from the relative fonts path of c::b(e.g. ..share\fonts\).

why we need to do this?

assumpt that the operation system which we used don't contain the fonts(e.g. Dejuva),so if you want to use this font,you have to copy the fonts(you want to use) to system folder.but sometime you don't have the authoration to do that.So if the c::b have the ability to  do this(loading fonts from its folder).it will be much better. :D
If work under limited user, that is, such a situation. :P
Title: Re: The 16 January 2010 build (6088) is out.
Post by: critic on January 25, 2010, 12:00:40 pm
Hello, everybody!
What you can say about this: http://forums.codeblocks.org/index.php/topic,11311.msg77442.html#msg77442
I think this message wasn't noticed.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: critic on January 25, 2010, 12:04:55 pm
And else one question: can you add setting to save IDE configuration to installation directory or user profile directory?
This is for portability of codeblocks. Sometimes I use IDE on USB stick and so on.
Now only the latter is available.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: oBFusCATed on January 25, 2010, 12:29:26 pm
Have you read this: http://wiki.codeblocks.org/index.php?title=FAQ#Q:_How_do_I_make_Code::Blocks_portable.3F

For you feature request: have you added it as such in the project page -> feature request?
Also If you desperately need this you can make a patch and submit it for inclusion
Title: Re: The 16 January 2010 build (6088) is out.
Post by: critic on January 25, 2010, 01:17:18 pm
Ok, thx.
And what about http://forums.codeblocks.org/index.php/topic,11311.msg77442.html#msg77442
Is this feature already available in C::B, but I don't know about it?
Title: Re: The 16 January 2010 build (6088) is out.
Post by: blueshake on January 25, 2010, 01:29:20 pm
And else one question: can you add setting to save IDE configuration to installation directory or user profile directory?
This is for portability of codeblocks. Sometimes I use IDE on USB stick and so on.
Now only the latter is available.


hi,you can try Loaden's portable of c::b from here.http://code.google.com/p/portablecb/downloads/list (http://code.google.com/p/portablecb/downloads/list)

Title: Re: The 16 January 2010 build (6088) is out.
Post by: blueshake on January 25, 2010, 01:31:22 pm
Ok, thx.
And what about http://forums.codeblocks.org/index.php/topic,11311.msg77442.html#msg77442
Is this feature already available in C::B, but I don't know about it?


seems not yet. :D
Title: Re: The 16 January 2010 build (6088) is out.
Post by: ollydbg on January 25, 2010, 02:53:02 pm
Ok, thx.
And what about http://forums.codeblocks.org/index.php/topic,11311.msg77442.html#msg77442
Is this feature already available in C::B, but I don't know about it?


Quote
Please, add sorting of project tree without case matching (otherwise I have 2 alphabetically sorted lists). I think this can be an option in context menu of the project manager widget.
Feature request about this, or the next CC's feature request post (http://forums.codeblocks.org/index.php/topic,11311.msg77443.html#msg77443)?
Title: Re: The 16 January 2010 build (6088) is out.
Post by: critic on January 26, 2010, 05:48:13 am
This request is relative to project manager's widget, not CC (as I understood you  :?) - applying to view only. Sorry for my english  :oops:.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: critic on January 26, 2010, 07:02:22 am
Something was changed in Ctrl+Tab feature (opened files switcher). Before this one Ctrl+Tab switches to the previous file editor and was allowed to select any file from popup list.
Now this list working in other way and I think that previous version was better  :P.
And else, highlighted item is not recognizable because text is black and selection is dark blue  :(.
May be I don't understand how to use new version of it  :??
Can you revert to that version?
Title: Re: The 16 January 2010 build (6088) is out.
Post by: MortenMacFly on January 26, 2010, 07:10:29 am
Something was changed in Ctrl+Tab feature (opened files switcher).
I cannot reproduce. You didn't state platform, version, which version was "better" -> nothing. In addition there were no changes recently that would cause such a behaviour. So I recommend you do y clean checkout and full re-build, as written in the commit logs.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: critic on January 26, 2010, 07:28:41 am
Something was changed in Ctrl+Tab feature (opened files switcher).
I cannot reproduce. You didn't state platform, version, which version was "better" -> nothing. In addition there were no changes recently that would cause such a behaviour. So I recommend you do y clean checkout and full re-build, as written in the commit logs.

I compare 8.02 and current nightly build. I lefthander and that's why I select file from popup window only with keyboard (my left hand presses Ctrl+Tab).

I supply 2 screenshots:


[attachment deleted by admin]
Title: Re: The 16 January 2010 build (6088) is out.
Post by: MortenMacFly on January 26, 2010, 10:08:30 am
I compare 8.02 and current nightly build.
This is a completely different base. we have switched from wxFlatNotebook to wxAuiNotebook and there is no way back. The behaviour concerning ordering is already considered and a patch is being tested. The colouring depends on your system fonts - mine just looks fine.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: sdfwds4 on January 28, 2010, 12:16:02 pm
thanks  :D
Title: Re: The 16 January 2010 build (6088) is out.
Post by: Matheus Martino on January 31, 2010, 11:13:47 am
That is the first Nightly build i try to use after the release of the version 8.02.

I'm trying to compile the source code of the OGRE3D library, i'm using it with MinGW 5.1.6.

With CB 8.02 i can compile it with no problem, but with that nightly build just after opening the BIG project workspace my CPU load goes to 100%, impossible to work that way.

I have VS 2008 Express installed, but Code::Blocks is configured to use mingw.

Excuse me if my english fail!

EDIT: OK! It stops if i disable the "Code completion" plugin and RESTART the program.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: Folco on February 01, 2010, 02:41:01 am
Indeed. The devs are working hard to get a less cpu-hungry behavior.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: glaure on February 01, 2010, 04:55:17 pm
Hi!

I just tried this nightly in Ubuntu 9.10. Got it running and loading my (rather large) workspace using a Makefile based build. It was slow as hell but didnt do anything. After minutes I always got the message "Target is uptodate" in the build log (clean or build).
Sorry to say that: I jumped back to 8.02 asap.

Bye Gunther
Title: Re: The 16 January 2010 build (6088) is out.
Post by: Folco on February 01, 2010, 06:14:31 pm
Quote
After minutes I always got the message "Target is uptodate" in the build log (clean or build).
You didn't try to rebuild your project ?
Title: Re: The 16 January 2010 build (6088) is out.
Post by: jens on February 01, 2010, 07:37:31 pm
Hi!

I just tried this nightly in Ubuntu 9.10. Got it running and loading my (rather large) workspace using a Makefile based build. It was slow as hell but didnt do anything. After minutes I always got the message "Target is uptodate" in the build log (clean or build).
Sorry to say that: I jumped back to 8.02 asap.

Bye Gunther

You should switch on full commandline logging, to see which commands are generated.

You should also check the "make commands" tab for your build targets and the project.
If the targets commands exist, they are used, otherwise the commands of the project.
Title: Re: The 16 January 2010 build (6088) is out.
Post by: critic on February 05, 2010, 10:16:52 am
Quote
Quote
I compare 8.02 and current nightly build.
This is a completely different base. we have switched from wxFlatNotebook to wxAuiNotebook and there is no way back. The behaviour concerning ordering is already considered and a patch is being tested. The colouring depends on your system fonts - mine just looks fine.

Anyway, sometimes (not always) Ctrl+Tab doesn't work correctly - required file in the popup list is selected, but when I release buttons it opens another tab.

It is not systematic bug, but it exists.

And else, it was very useful to switch between 2 last tabs by Ctrl+Tab. Now it is not possible.  :cry:
Title: Re: The 16 January 2010 build (6088) is out.
Post by: jens on February 05, 2010, 11:21:28 am
And else, it was very useful to switch between 2 last tabs by Ctrl+Tab. Now it is not possible.  :cry:

Do you mean jumping from the first tab to the last or vice-versa (wrapping) ?

If yes this should work in the next nightly, see this thread for details: http://forums.codeblocks.org/index.php/topic,11519.msg78453.html#msg78453 (http://forums.codeblocks.org/index.php/topic,11519.msg78453.html#msg78453) .
Title: Re: The 16 January 2010 build (6088) is out.
Post by: critic on February 08, 2010, 07:37:32 am
And else, it was very useful to switch between 2 last tabs by Ctrl+Tab. Now it is not possible.  :cry:

Do you mean jumping from the first tab to the last or vice-versa (wrapping) ?

If yes this should work in the next nightly, see this thread for details: http://forums.codeblocks.org/index.php/topic,11519.msg78453.html#msg78453 (http://forums.codeblocks.org/index.php/topic,11519.msg78453.html#msg78453) .

No. Tabs order does not matter. But when I work with only 2 tabs (though I have more tabs opened at this moment) for some time I need to switch between them very quickly.
Let's make condition:

In older versions of C::B first keypress of Ctrl+Tab switches to the previous active tab, i.e. to B. The next keypress of Ctrl+Tab switches to A. And so on. If I press Tab more then 1 time without releasing Ctrl I can activate other tabs.

My English is not good. That's why explanation is so long. Sorry.  :oops:
Title: Re: The 16 January 2010 build (6088) is out.
Post by: critic on February 08, 2010, 12:30:42 pm
If my explanation is not clear enough here some additional information: popup list of tabs contains items ordered by last time of their's active state (current active tab is on the top of this list).
Ctrl+Tab popups this list and selects the second item if it exists. So, the first and the second items trade places.
Can you make the same behaviour in new component `wxAuiNotebook` or make this variant as option of behaviour?
Title: Re: The 16 January 2010 build (6088) is out.
Post by: jp971 on February 10, 2010, 02:35:52 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.7z

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

The 16 January 2010 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20100116_rev6088_win32.7z
  - Linux :
   none

Resolved Fixed:

  • CC: added missing replace to initialisation
  • CC: allow using a non-alphanumeric replace token
  • CC applying patch by OllyDbg to handle template arguments better
  • CC: made parsing while typing ("real time parse") an option as it slows down the IDE massively for large projects
  • CC: remove some crash candidates
  • wx-2.9 migration: Build fixes for HexEditor.cpp
  • compiler: applied patch #2897: PrependDir() can be used for single directory only
  • compiler: applied patch #2877: CompilerOptionsDlg acesses tabs that don't exist
  • compiler: LCC compiler supports new registry key for auto-detection
  • applied (modified) patch #2861: New sharedlib project - choose between c and c++
  • fixed a bug with accelerator being used twice (thanks daniloz)
  • CC: fixed bug with skipping to wrong character (thanks OllyDbg)
  • CC: fixed bug with enabling parse while typing (thanks blueshake)
  • allow macros in default code

Regressions/Confirmed/Annoying/Common bugs:



    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: Seronis on February 10, 2010, 04:33:27 am
    @jp971,  any point to that quote ?
    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: Edy on February 10, 2010, 12:16:28 pm
    If my explanation is not clear enough here some additional information: popup list of tabs contains items ordered by last time of their's active state (current active tab is on the top of this list).
    Ctrl+Tab popups this list and selects the second item if it exists. So, the first and the second items trade places.
    Can you make the same behaviour in new component `wxAuiNotebook` or make this variant as option of behaviour?

    You mean the Visual Studio-style for switching tabs. I'm sorry, but I strongly dislike that method: you never know how many Ctrl+Tab presses you need for switching to a tab that is two positions ahead, or even the contiguous one - it depends on the tabs you have been on previously. And I don't want to stop my work for reading a pop-up list in order to just switch to the tab two positions ahead.

    I usually work at the same time in more than two tabs. Working in Visual Studio really pisses me off because each time I need to switch to another tab, I must either stop my workflow to read the pop-up list and locate the target tab, or start pressing Ctrl-Tab two times, then three, four and so on until I reach the desired tab.

    So I really like the current C::B style of switching tabs in the same order as they are seen: if I want to go to the tab two positions ahead, simply two fast Ctrl-Tab and I'm there. Return to the previous tab is two fast Ctrl-Shift-Tab, and ready to continue. If I'm working on two or more tabs frequently, then I move them to closer positions. But the point is that I only need a quick look at the tabs to quickly move to any of them.
    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: critic on February 10, 2010, 12:46:09 pm
    To @Edy
    Going to another tab without mouse don't require a list. List is required to find item by name. In your case you need just 2 shortcuts to switch between tabs in 2 opposite directions.
    As for Visual Studio tabs switching style - in eclipse this made as I described before.
    In this case will be great to have an option or another additional popup list to the existent one. And shortcuts each user can configure himself.
    The problem is that I used such behaviour and it disappears in latest nightlies. It's bad for me. :(
    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: critic on February 10, 2010, 12:59:22 pm
    `Toolbar drag crash` appears again, isn't it  :?: (win xp)
    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: ollydbg on February 10, 2010, 01:15:31 pm
    `Toolbar drag crash` appears again, isn't it  :?: (win xp)
    It is a wxWidgets bug, and can be fixed by this post:
    Re: The 13 April 2009 build (5535) is out. (http://forums.codeblocks.org/index.php/topic,10406.msg71815.html#msg71815)
    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: oBFusCATed on February 10, 2010, 01:18:01 pm
    And shortcuts each user can configure himself.
    Keybinder plugin should do that job?
    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: critic on February 11, 2010, 05:57:00 am
    @oBFusCATed
    About that I just told. Required only additional feature which was earlier in C::B (popup list of tabs with sorting by time of last activity).

    @ollydbg
    Thanks. It's very useful.
    Title: Caret disappears from time to time
    Post by: loopcoder on February 11, 2010, 11:01:20 pm
    Hi everyone,

    I'm using C::B on an old Windows2000 box (yes, something like that still exists....) and I really love to work with it - it's so slim and fast. A big THANK YOU SO MUCH to all contributers!  :D

    Lately I'm switched from the 8.02 stable version to the the latest build [6088], which is even a way better (and surely prettier) then the stable version.
    But one small bug annoys me in the editor: After deleting whole lines (Ctrl-L) the caret (that blinking cursor mark) disappears. It's shown again when you move the cursor or do some typing. It's only from time to time, mostly in more "complicated" syntax structures, and I didn't managed to reproduce it.

    Hmm. Does anybody else had seen similar behaviour? Maybe a scintilla bug?   

    Title: Re: Caret disappears from time to time + C::B crashs
    Post by: loopcoder on February 11, 2010, 11:44:56 pm
    After deleting whole lines (Ctrl-L) the caret (that blinking cursor mark) disappears. It's shown again when you move the cursor or do some typing. It's only from time to time, mostly in more "complicated" syntax structures, and I didn't managed to reproduce it.

    I found a way to reproduce a related error (not the same situation, but same behavior):

    - open a C++ source file
    - type something which is enclosed in curly brackets, like:

    {
       foobar;
    }

    bug1: sometimes the folding line (left margin) is not shown

    - place the caret inside the brackets (on the "foobar" line) and close the {}-fold

    bug2: caret disappears   

    - use the cursor keys, so that the caret will be shown again
    - now delete the line with the fold (ctrl-L)

    bug3: caret disappears again, nor any text which is typed now will be shown. Characters are written to the text buffer though. When moving the cursor around, the caret and the "hidden" text appears.

    bug4:
    When you do the whole thing in a new source file and place the fold on the very first line, C::B will crash when deleting that closed fold!


    greetings...



     
    Title: Re: Caret disappears from time to time + C::B crashs
    Post by: loopcoder on February 12, 2010, 12:12:30 am

    - place the caret inside the brackets (on the "foobar" line) and close the {}-fold

    bug2: caret disappears  

    - use the cursor keys, so that the caret will be shown again
    - now delete the line with the fold (ctrl-L)

    bug3: caret disappears again, nor any text which is typed now will be shown. Characters are written to the text buffer though. When moving the cursor around, the caret and the "hidden" text appears.


    ...probably a Scintilla bug. Bug1 and bug2 can also be found in SciTE 2.02 for example.

    Bug3 is a bit different here: If you delete a fold, only the opening bracket is deleted, and the fold is opened again. And SciTE does not crash, if the deleted fold is in the first line (bug4) .

    But there are other strange things in SciTE: moving the cursor outside a closed fold sometimes had the effects described above (no caret, no text shown) as well.

    So I guess, the folding feature in Scintilla is still/again a bit buggy. Or is it just my system configuration?

    geetings

    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: jens on February 12, 2010, 12:52:32 am
    Thanks for reporting this, I can not reproduce the crash (on linux), but will try it on w2k (yes I also have it), but not today ( I have to go to bed).

    The other problems are reproducible.
    The cause seems to be that Ctrl+L deletes the actual line, this is the one with the fold, but does not unfold the block before.
    I think it should either unfold the folded block, or delete it completely, and of course the caret should be visible in all cases.

    You also report this issue at scintillas bug-tracker: http://sourceforge.net/tracker/?atid=102439&group_id=2439 (http://sourceforge.net/tracker/?atid=102439&group_id=2439) .
    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: critic on February 12, 2010, 07:29:20 am
    Can you make an `Available macros` button in the forms where macros can be used? It will be very useful for users, especially for newcomers.  :P I mean `default code`, `search paths`, `toolchain` config pages and etc.
    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: yesno on February 12, 2010, 11:40:26 am
    (Maybe OT because it's for rev. 6155 rather than 6088)

    If I compile the whole project all is fine like before, no errors but a bunch of warnings, most like
    "comparison of unsigned with signed integer".
    But if I try to start the application, I get this message from the OS:
    "Die Anwendung konnte nicht richtig initialisiert werden (0xc0000005)"
    (The application could not be initialized correctly (0xc0000005)),
    no matter with or without the plugins.

    The downloaded version 6088 (from here) runs fine and my version 5945 (self-compiled) too.

    My OS is WinXP SP2, the compiler is MinGW 3.4.5 and the wxWidgets version is 2.8.10 (self-compiled).

    Please give me a hint what I should do / where I should search.

    Thanks in advance and with kind regards

    yesno

    PS C::B is the best IDE I've ever seen
    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: jens on February 12, 2010, 12:05:33 pm
    You should either use a clean svn checkout, or clean the C::B project and the contrib-plugins workspace and manual delete th edevl and output directorires.
    Make sure that the pch-files are deleted ( src/include/*.gch ).

    Or try the clean-script posted by MortenMacFly here: http://forums.codeblocks.org/index.php/topic,11773.msg79887.html#msg79887 (http://forums.codeblocks.org/index.php/topic,11773.msg79887.html#msg79887)

    We updated the scintilla-version and had some other api-changes, that might lead to problems if older libs remain.
    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: critic on February 12, 2010, 12:08:35 pm
    Once again to Ctrl+Tab topic: in the IDE can be made browsing (forward and backward) as in internet browser (firefox, for example). This is much better then switching between last two tabs. Because of the code changes made by user browsing can be done with switching tabs only (without line positioning, though editing of the code before this line can be monitored by IDE and if it happens then reset positioning in that tab).
    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: Pecan on February 12, 2010, 11:13:58 pm
    (Maybe OT because it's for rev. 6155 rather than 6088)

    If I compile the whole project all is fine like before, no errors but a bunch of warnings, most like
    "comparison of unsigned with signed integer".
    But if I try to start the application, I get this message from the OS:
    "Die Anwendung konnte nicht richtig initialisiert werden (0xc0000005)"
    (The application could not be initialized correctly (0xc0000005)),
    no matter with or without the plugins.

    The downloaded version 6088 (from here) runs fine and my version 5945 (self-compiled) too.

    My OS is WinXP SP2, the compiler is MinGW 3.4.5 and the wxWidgets version is 2.8.10 (self-compiled).

    Please give me a hint what I should do / where I should search.

    Thanks in advance and with kind regards

    yesno

    PS C::B is the best IDE I've ever seen

    I also receive the 0xc0000005 (on Windows7) when starting CodeBlocks when compiled with mingw 3.4.5. Updating mingw to a 4+ version solved the problem.

    Be sure to recompile wxWidgets before re-compiling CodeBlocks with a new mingw version.


     
    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: critic on February 15, 2010, 07:45:18 am
    Can you make automatic addition of closing brace (`}`) only after pressing Enter, because in the following situation I need to delete it:

    Before modification of code:

    Code: [Select]
    if(something)
        doSomething();

    After modification of code:

    Code: [Select]
    if(something)
    {// I printer opening brace and now I need to delete closing brace - because I want to use doSomething(); function in braces
       
    }    doSomething();

    Though I need the next:

    Code: [Select]
    if(something)
    {// I pressed enter after `if(something)` and printed opening brace only (editor doesn't know about doSomething(); function - is it must be in braces or no - I will specify it later)
        doSomething();

    The closing brace I will print when needed (i.e. I will show the editor where it is required to place).

    If I press Enter after `{` the closing brace can appear:

    Code: [Select]
    if(something)
    {
        // I pressed enter after opening brace (i.e. I don't want doSomething(); function to be in braces)
    }
    doSomething();

    And else - if I printed opening brace on the same line with doSomething() function and then pressed enter the following will be correct:

    Code: [Select]
    if(something)
    {
        doSomething();
    }

    About classes: closing brace of classes and structs must be followed with `;`. Not it isn't.
    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: blueshake on February 15, 2010, 08:09:17 am
    @critic


    I can make a patch for this.But I am working for some cc bugs.Not sure when I can finish it. :D
    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: critic on February 15, 2010, 08:15:22 am
    @blueshake

    Ok. Thanks for response. I'm a beta tester and only point on some defects in my opinion.

    Else one defect in autocompletion of braces:
    When I printing closing `"` (i.e. opening `"` already exists) I get `"""` instead of `""`.

    Thanks for your work.
    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: critic on February 15, 2010, 01:21:29 pm
    I almost always use Custom Makefile option enabled (for Qt projects) and when I rebuild project the following take place:
    Code: [Select]

    -------------- Clean: Debug in ExceptionViewer ---------------

    mingw32-make.exe -f Makefile.Release clean
    mingw32-make.exe -f Makefile.Debug clean
    mingw32-make.exe -f Makefile.Debug
    mingw32-make.exe[1]: Entering directory `D:/dev/projects/vvts3/arm/ExceptionViewer'
    del obj\Debug\moc\moc_exception_viewer.cpp
    mingw32-make.exe[1]: Entering directory `D:/dev/projects/vvts3/arm/ExceptionViewer'
    del obj\Debug\moc\moc_exception_viewer.cpp
    del obj\Debug\uic\ui_except_dlg.h
    del obj\Debug\except_dlg.o obj\Debug\exception_viewer.o obj\Debug\main.o obj\Debug\moc_exception_viewer.o
    del obj\Debug\uic\ui_except_dlg.h
    mingw32-make.exe[1]: Leaving directory `D:/dev/projects/vvts3/arm/ExceptionViewer'
    del obj\Debug\except_dlg.o obj\Debug\exception_viewer.o obj\Debug\main.o obj\Debug\moc_exception_viewer.o
    mingw32-make.exe[1]: Entering directory `D:/dev/projects/vvts3/arm/ExceptionViewer'
    d:\bin\dev\libs\qt\4.5.0\bin\uic.exe ..\..\..\..\our_libs\arm_kit\src\arm_kit\except_dlg.ui -o obj\Debug\uic\ui_except_dlg.h
    g++ -c -Wall -g -g -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_THREAD_SUPPORT -I"d:\bin\dev\libs\qt\4.5.0\include" -I"..\..\..\..\our_libs\arm_kit\src" -I"d:\bin\dev\libs\Qt\4.5.0\include" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtCore" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtGui" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtXml" -I"d:\bin\dev\libs\qt\4.5.0\include\ActiveQt" -I"obj\Debug\moc" -I"obj\Debug\uic" -I"d:\bin\dev\libs\qt\4.5.0\mkspecs\default" -o obj\Debug\except_dlg.o ..\..\..\..\our_libs\arm_kit\src\arm_kit\except_dlg.cpp
    mingw32-make.exe[1]: Leaving directory `D:/dev/projects/vvts3/arm/ExceptionViewer'
    g++ -c -Wall -g -g -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_THREAD_SUPPORT -I"d:\bin\dev\libs\qt\4.5.0\include" -I"..\..\..\..\our_libs\arm_kit\src" -I"d:\bin\dev\libs\Qt\4.5.0\include" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtCore" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtGui" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtXml" -I"d:\bin\dev\libs\qt\4.5.0\include\ActiveQt" -I"obj\Debug\moc" -I"obj\Debug\uic" -I"d:\bin\dev\libs\qt\4.5.0\mkspecs\default" -o obj\Debug\exception_viewer.o exception_viewer.cpp
    g++ -c -Wall -g -g -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_THREAD_SUPPORT -I"d:\bin\dev\libs\qt\4.5.0\include" -I"..\..\..\..\our_libs\arm_kit\src" -I"d:\bin\dev\libs\Qt\4.5.0\include" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtCore" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtGui" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtXml" -I"d:\bin\dev\libs\qt\4.5.0\include\ActiveQt" -I"obj\Debug\moc" -I"obj\Debug\uic" -I"d:\bin\dev\libs\qt\4.5.0\mkspecs\default" -o obj\Debug\main.o main.cpp
    D:/bin/dev/libs/qt/4.5.0/bin\moc.exe -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_THREAD_SUPPORT -I"d:\bin\dev\libs\qt\4.5.0\include" -I"..\..\..\..\our_libs\arm_kit\src" -I"d:\bin\dev\libs\Qt\4.5.0\include" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtCore" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtGui" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtXml" -I"d:\bin\dev\libs\qt\4.5.0\include\ActiveQt" -I"obj\Debug\moc" -I"obj\Debug\uic" -I"d:\bin\dev\libs\qt\4.5.0\mkspecs\default" -D__GNUC__ -DWIN32 exception_viewer.h -o obj\Debug\moc\moc_exception_viewer.cpp
    g++ -c -Wall -g -g -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_THREAD_SUPPORT -I"d:\bin\dev\libs\qt\4.5.0\include" -I"..\..\..\..\our_libs\arm_kit\src" -I"d:\bin\dev\libs\Qt\4.5.0\include" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtCore" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtGui" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtXml" -I"d:\bin\dev\libs\qt\4.5.0\include\ActiveQt" -I"obj\Debug\moc" -I"obj\Debug\uic" -I"d:\bin\dev\libs\qt\4.5.0\mkspecs\default" -o obj\Debug\moc_exception_viewer.o obj\Debug\moc\moc_exception_viewer.cpp
    g++ -enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc -Wl,-subsystem,console -mthreads -Wl -o bin\Debug\ExceptionViewer.exe obj/Debug/except_dlg.o obj/Debug/exception_viewer.o obj/Debug/main.o obj/Debug/moc_exception_viewer.o  -L"d:\bin\dev\libs\qt\4.5.0\lib" -LD:\bin\dev\libs\Qt\4.5.0\lib -lQtCore4 -lQtGui4 -lQtXml4
    mingw32-make.exe[1]: Leaving directory `D:/dev/projects/vvts3/arm/ExceptionViewer'


    :\dev\projects\vvts3\arm\ExceptionViewer\obj\Debug\moc\moc_exception_viewer.cpp


    :\dev\projects\vvts3\arm\ExceptionViewer\obj\Debug\uic\ui_except_dlg.h


    :\dev\projects\vvts3\arm\ExceptionViewer\obj\Debug\except_dlg.o
    exception_viewer.cpp: In member function `void arm::ExceptionViewer::onReadyRead()':
    exception_viewer.cpp:39: warning: unused variable 'quitter'
    Cleaned "ExceptionViewer - Debug"

    -------------- Build: Debug in ExceptionViewer ---------------

    Target is up to date.
    Nothing to be done.


    Build log appears in the `clean` section. Is it a bug? And else, C::B is freezed when rebuilding from begining of `clean` section till begining of `build` section, that is all time of rebuild process. When it became normal (not freezed) all log text appears and in build section - `nothing to be done`.
     
    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: critic on February 17, 2010, 06:28:01 am
    I want to requiest a new feature - adding files right to the virtual folders in the project's tree. Is it possible?

    I use my libraries at sources level (without precompiled binaries .so or .dll, or .a) and that's why I need to add sources directly to project. When I add files to project from outside of project's directory all project's files names became large that is not friendly. But when I split these files in virtual folders - all OK - one virtual folder for each library.
    Now, to add files to virtual folder I need to add them to project's root, then move them one by one to virtual folder created before. It will be better to allow multiple selection of files in project's tree for such operations and allow addition of files to concrete virtual folder as to the project's root node
    Title: Bug: end-of-line comments confuse the symbol parser
    Post by: loopcoder on February 18, 2010, 04:54:39 pm
    As many "cross-platform-coders" I work on Linux and Windows at the same time.
    The class browser (symbol pane) and the code completion do not work for me at all - and luckily I found the reason (just minutes before wiping C::B off my hard drive... ;) )

    The parser cannot handle stream comments ("//"), if the EOL mode does not match the current OS (e.g. just CR in Windows). That is quite often the case, if you do the main development under a pleasant OS and want to make it work in a Windows environment...

    Small sample: (save it to a unix file (just CR) )

    class Foo {
    public:
       int this_is_parsed;  // knock-out comment
       int oh_thats_bad;
    }


    That bug may also apply for other EOL modes (Mac..)


    regards


     
    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: critic on February 19, 2010, 07:37:23 am
    I use UTF-8 charset and LF end of line - it works fine. Earlier I used cp1251 with CRLF - it worked fine too. CF is MAC end of line. If you work under windows and linux (not MAC), why do you choose CF?

    EDIT:
    May be it's charset and `end of line` incompatibility? Which charset do you use?
    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: loopcoder on February 19, 2010, 12:33:44 pm
    Yes, sorry, I have mixed up CR (\r)  and LF (\n).

    The point is: the syntax parser does not work, if you have single line comments ("//...") in a mac file (CR) using C::B in Windows (maybe as well in other non-Mac systems).

    If you share your files, such situations may occure.
    I consider this as a bug, since you expect the parser / the class browser / the code completion to work in any environment and setting -- you will always blame the software, not your settings ;)
    The syntax parser should accept both '\n' and '\r' as EOL. No big deal.    
    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: critic on February 24, 2010, 05:55:17 am
    @loopcoder
    +  :)
    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: Hans Henrik on February 26, 2010, 01:08:03 am
    found a bug, but idk how long it has lasted or if it even is in 8.02, just found it using 6088

    in Wx-wizard, when you specify "Configure Advanced Options", on "console or GUI?", it will threat Debug as Release and visa-versa

    how to reproduce:
    start C::B->File->New->Project->WxWidgets Project->(Next->)WxWidgets 2.8.x->(whatever in project-title)->next->next->WxSmith->Frame Based->Next->Next->Next->Configure Advanced Options->Next->Debug->Console->Release->GUI

    and your release build will be console and your debug-build wont.  :!: :wink:
    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: BrayMailloux on February 27, 2010, 07:25:43 pm
    I tried to build this nightly following the instruction posted via http://wiki.codeblocks.org/index.php?title=Nightly_Cookbook

    I'm as far as using the built nightly to compile the Code::Blocks source into a new build. When I compile, this is the error printed in the build log.

    Linking dynamic library: devel\wxscintilla.dll
    C:\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot find -lwxmsw28u
    collect2: ld returned 1 exit status
    Process terminated with status 1 (1 minutes, 12 seconds)
    1 errors, 6 warnings

    There is quite a bit of log before that... but it does not seem important because it all succeeds.
    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: stefanos_ on February 28, 2010, 10:34:57 am
    Hans Henrik, I can confirm your bug as of 28-02-2010.

    System Specificatons:

    IDE Version: Code::Blocks svn 6117
    Operating System: Windows XP SP3
    Compiler: MinGW: 5.1.6 (g++ 3.4.5)

    I will download the latest svn version right now to test it as well. Though still I don't know the major differences between the TDM's GCC and MinGW, I can though guess that TDM's GCC is using the latest stable libraries I would say (4.4.1, I hope I am correct).

    Current news [as of 28-02-2010 12:45 Local time (Cyprus)]: I have downloaded the latest svn code [6181] and the bug remains the same. Hans my friend, can you report it please in http://developer.berlios.de/bugs/?group_id=5358 where is the official bug page?
    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: Biplab on February 28, 2010, 05:30:45 pm
    found a bug, but idk how long it has lasted or if it even is in 8.02, just found it using 6088

    in Wx-wizard, when you specify "Configure Advanced Options", on "console or GUI?", it will threat Debug as Release and visa-versa

    how to reproduce:
    start C::B->File->New->Project->WxWidgets Project->(Next->)WxWidgets 2.8.x->(whatever in project-title)->next->next->WxSmith->Frame Based->Next->Next->Next->Configure Advanced Options->Next->Debug->Console->Release->GUI

    and your release build will be console and your debug-build wont.  :!: :wink:

    Bug is now Fixed in trunk in rev 6182. Thanks for pointing this.
    Title: Re: The 16 January 2010 build (6088) is out.
    Post by: stefanos_ on March 01, 2010, 07:26:56 am
    Anytime mate ;) Cheers should go to Hans of course for his good observation.

    Bravo Hans, well done.  8)