The 25 september 2010 build (6634) CODECOMPLETION BRANCH version is out.

[ollydbg]

CB_CC_BRANCH_r6675 can't parce ole2.h with MinGW

Code: [Select]

#include <ole2.h>
...
VARIANT param;
VariantInit(&param);
param./*Ctrl-Space show only dblVal*/


Sorry, this is too complex, my personal opinion, not yet plan to support it.

there are some unnamed union in the declaration of VARIANT. I'm trying to figure it out. but the latest cc_branch get crashed when I try to view ole2.h.

[ollydbg]

The second time (parsing without) was done immediately after closing the project, so that most of the files are still in the systems hdd-buffer.

No, because the ParserThread instance of these files does not created.

...I'm confused about your discussion. Jens says that the second batch parse takes much less time because of the system's cache for source files.

[Loaden]

The second time (parsing without) was done immediately after closing the project, so that most of the files are still in the systems hdd-buffer.

No, because the ParserThread instance of these files does not created.

...I'm confused about your discussion. Jens says that the second batch parse takes much less time because of the system's cache for source files.

I see, thanks!

[Loaden]

@killerbot
Could you publish a CODECOMPLETION BRANCH nightly build in this weekend?
We add some feature, and fixed some bugs of reported in forum.
Thanks a lot!

EDIT: Please waiting, found a new issue, we need a whole day for test.

[Loaden]

@MortenMacFly
Maybe we need merged with trunk (trunk to cc_branch) ?
We need your help.

[Loaden]

@killerbot
Could you publish a CODECOMPLETION BRANCH nightly build in this weekend?
We add some feature, and fixed some bugs of reported in forum.
Thanks a lot!

EDIT: Please waiting, found a new issue, we need a whole day for test.

Fixed in r6687, so, I think we are ready now.

[Loaden]

Hi,
I'm testing C::B CC_branch on another big project - OpenOffice and after ~20 minutes CC parser is hanging on:

Code: [Select]

InitTokenizer() : m_Filename='/usr/include/bits/time.h', m_FileSize=2866.
Parse() : Parsing '/usr/include/bits/time.h'
DoParse() : Loop:m_Str='', token='#'
DoParse() : Loop:m_Str='', token='#'
DoAddToken() : Created token='_STRUCT_TIMEVAL', file_idx=12732, line=70, ticket=
GetActualTokenType() : Searching within m_Str='1'
GetActualTokenType() : Compensated m_Str='1'
GetActualTokenType() : Found '1'
DoAddToken() : Prepending ''
DoParse() : Loop:m_Str='', token='#'
HandleIncludes() : Found include file 'bits/types.h'
DoParse() : Loop:m_Str='', token='struct'
HandleClass() : Found class 'timeval'
DoAddToken() : Created token='timeval', file_idx=12732, line=75, ticket=
GetActualTokenType() : Searching within m_Str=''
GetActualTokenType() : Compensated m_Str=''
GetActualTokenType() : Returning ''
DoAddToken() : Prepending ''
DoAddToken() : Added/updated token 'timeval' (353789), type '', actual ''. Parent is  (-1)
DoParse() : Loop:m_Str='', token='__time_t'
DoParse() : Loop:m_Str='__time_t ', token='tv_sec'
DoAddToken() : Created token='tv_sec', file_idx=12732, line=77, ticket=
GetActualTokenType() : Searching within m_Str='__time_t'
GetActualTokenType() : Compensated m_Str='__time_t'
GetActualTokenType() : Found '__time_t'
DoAddToken() : Prepending ''
DoAddToken() : Added/updated token 'tv_sec' (353790), type '__time_t', actual '__time_t'. Parent is timeval (353789)
DoParse() : Loop:m_Str='__time_t', token=';'
DoParse() : Loop:m_Str='', token='__suseconds_t'
DoParse() : Loop:m_Str='__suseconds_t ', token='tv_usec'
DoAddToken() : Created token='tv_usec', file_idx=12732, line=78, ticket=
GetActualTokenType() : Searching within m_Str='__suseconds_t'
GetActualTokenType() : Compensated m_Str='__suseconds_t'
GetActualTokenType() : Found '__suseconds_t'
DoAddToken() : Prepending ''
DoAddToken() : Added/updated token 'tv_usec' (353791), type '__suseconds_t', actual '__suseconds_t'. Parent is timeval (353789)
DoParse() : Loop:m_Str='__suseconds_t', token=';'
DoParse() : Loop:m_Str='', token='}'
InitTokenizer() : m_Filename='/usr/include/bits/dirent.h', m_FileSize=1609.
Parse() : Parsing '/usr/include/bits/dirent.h'
DoParse() : Loop:m_Str='', token='struct'
HandleClass() : Found class 'dirent'
C++ Parser is still parsing files...
C++ Parser is still parsing files...
C++ Parser is still parsing files...


Code: [Select]

Tasks: 143 total,   1 running, 142 sleeping,   0 stopped,   0 zombie
Cpu(s): 60.8%us,  3.0%sy,  0.0%ni, 36.0%id,  0.2%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   2062772k total,  1969520k used,    93252k free,   145608k buffers
Swap:  2104476k total,     9292k used,  2095184k free,   664664k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                                                            
15947 1234   20   0  824m 573m  34m S  102 28.5  19:55.35 codeblocks


// EDIT: C::B CC branch rev 6671

Could you trying r6690?

[polygon7]

Could you trying r6690?

I have tested it with rev. 6702 and CodeCompletion works ("Parse complex macros" is enabled):

Code: [Select]

Loading project files...
23587 files loaded
Done loading project in 66327ms
Project's base path: /home/lukaszg/projekty/openoffice/
Project's common toplevel path: /home/lukaszg/projekty/openoffice/
[New Thread 0xa8e53b70 (LWP 21390)]
Caching GCC dir: /usr/include/c++/4.5.1
Caching GCC dir: /usr/include/c++/4.5.1/i686-pc-linux-gnu
Caching GCC dir: /usr/include/c++/4.5.1/backward
Caching GCC dir: /usr/local/include
Caching GCC dir: /usr/lib/gcc/i686-pc-linux-gnu/4.5.1/include
Caching GCC dir: /usr/lib/gcc/i686-pc-linux-gnu/4.5.1/include-fixed
Caching GCC dir: /usr/include
Passing list of files to batch-parser.
Header to parse up-front: '/usr/include/c++/4.5.1/cstddef'
Header to parse up-front: '/usr/include/boost/config.hpp'
Header to parse up-front: '/usr/include/boost/filesystem/config.hpp'
Header to parse up-front: '/home/lukaszg/projekty/openoffice/embedserv/source/inc/stdafx.h'
Add up-front parsing 4 file(s) for project 'openoffice'...
Add batch-parsing 12303 file(s) for project 'openoffice'...
Create new parser for project 'openoffice'
EnvVars: Obtained 'default' as active envvar set from config.
EnvVars: Set 'default' will not be applied (already active).
Starting batch parsing for project 'openoffice'...
[New Thread 0xa8652b70 (LWP 21395)]

Project 'openoffice' parsing stage done (13394 total parsed files, 403357 tokens in 1 minute(s), 46.055 seconds).

... but there is a problem when I'm trying to write:

Code: [Select]

#include <
or

Code: [Select]

#include "
to include some file then C::B have ~2-7 sec. "hang" (project type or size doesn't matter).

My default (global) compiler search directories are:

Code: [Select]

/usr/include
/usr/include/boost
/usr/include/libxml2


[killerbot]

yes, this delay is already present for so time now, I can confirm ;-)

[Loaden]

yes, this delay is already present for so time now, I can confirm ;-)

Because there has too many system headers, and seems need a fast IO system.
And now, I have not good idea.

[polygon7]

yes, this delay is already present for so time now, I can confirm ;-)

Because there has too many system headers, and seems need a fast IO system.
And now, I have not good idea.

I don't know - maybe C::B could use some kind of "memory cache" for global / project include file names
- on C::B start one thread could insert global includes file names into some std::map<filename, path>(or maybe other container),
and when user open some project another thread could insert per project file names into same container?

//Edit: And when user write:

Code: [Select]

#include " C::B will use that "cache"?

[Loaden]

yes, this delay is already present for so time now, I can confirm ;-)

Because there has too many system headers, and seems need a fast IO system.
And now, I have not good idea.

I don't know - maybe C::B could use some kind of "memory cache" for global / project include file names
- on C::B start one thread could insert global includes file names into some std::map<filename, path>(or maybe other container),
and when user open some project another thread could insert per project file names into same container?

//Edit: And when user write:

Code: [Select]

#include " C::B will use that "cache"?

Yes, use std::map<wxString, std::list<wxString> > to save all system headers.

[jens]

linux-kernel 2.6.29:

Code: [Select]

Project 'test' parsing stage done (21821 total parsed files, 910203 tokens in 3 minute(s), 11.931 seconds).

linux-kernel 2.6.35:

Code: [Select]

Project 'test' parsing stage done (30447 total parsed files, 1313354 tokens in 6 minute(s), 54.779 seconds).

Good work !
 I am just compiling it on my server, to update the cc-repo.

[Loaden]

I am just compiling it on my server, to update the cc-repo.

Thanks!

[Loaden]

yes, this delay is already present for so time now, I can confirm ;-)

Hi, killerbot, Could you have a trying r6707.
And post the debug log in here?
Thanks!