Author Topic: The 25 september 2010 build (6634) CODECOMPLETION BRANCH version is out.  (Read 115514 times)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5906
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 25 september 2010 build (6634) CODECOMPLETION BRANCH version is out.
« Reply #75 on: October 08, 2010, 12:05:27 pm »
CB_CC_BRANCH_r6675 can't parce ole2.h with MinGW

Code
#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.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5906
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 25 september 2010 build (6634) CODECOMPLETION BRANCH version is out.
« Reply #76 on: October 08, 2010, 12:09:33 pm »
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.

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline Loaden

  • Lives here!
  • ****
  • Posts: 1014
Re: The 25 september 2010 build (6634) CODECOMPLETION BRANCH version is out.
« Reply #77 on: October 08, 2010, 01:31:03 pm »
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!

Offline Loaden

  • Lives here!
  • ****
  • Posts: 1014
Re: The 25 september 2010 build (6634) CODECOMPLETION BRANCH version is out.
« Reply #78 on: October 09, 2010, 06:39:43 am »
@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! :D

EDIT: Please waiting, found a new issue, we need a whole day for test. :(
« Last Edit: October 09, 2010, 08:05:11 am by Loaden »

Offline Loaden

  • Lives here!
  • ****
  • Posts: 1014
Re: The 25 september 2010 build (6634) CODECOMPLETION BRANCH version is out.
« Reply #79 on: October 09, 2010, 06:52:06 am »
@MortenMacFly
Maybe we need merged with trunk (trunk to cc_branch) ?
We need your help. :)

Offline Loaden

  • Lives here!
  • ****
  • Posts: 1014
Re: The 25 september 2010 build (6634) CODECOMPLETION BRANCH version is out.
« Reply #80 on: October 09, 2010, 12:08:54 pm »
@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! :D

EDIT: Please waiting, found a new issue, we need a whole day for test. :(
Fixed in r6687, so, I think we are ready now. :D

Offline Loaden

  • Lives here!
  • ****
  • Posts: 1014
Re: The 25 september 2010 build (6634) CODECOMPLETION BRANCH version is out.
« Reply #81 on: October 10, 2010, 02:21:00 pm »
Hi,
I'm testing C::B CC_branch on another big project - OpenOffice and after ~20 minutes CC parser is hanging on:

Code
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
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?

Offline polygon7

  • Multiple posting newcomer
  • *
  • Posts: 104
    • Home site
Re: The 25 september 2010 build (6634) CODECOMPLETION BRANCH version is out.
« Reply #82 on: October 11, 2010, 04:41:30 pm »
Could you trying r6690?

I have tested it with rev. 6702 and CodeCompletion works ("Parse complex macros" is enabled):
Code
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
#include <
or
Code
#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
/usr/include
/usr/include/boost
/usr/include/libxml2
best regards,
p7
 Free open source UML modeling tool: ArgoUML

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5489
Re: The 25 september 2010 build (6634) CODECOMPLETION BRANCH version is out.
« Reply #83 on: October 11, 2010, 05:07:23 pm »
yes, this delay is already present for so time now, I can confirm ;-)

Offline Loaden

  • Lives here!
  • ****
  • Posts: 1014
Re: The 25 september 2010 build (6634) CODECOMPLETION BRANCH version is out.
« Reply #84 on: October 11, 2010, 05:12:35 pm »
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. :(
« Last Edit: October 11, 2010, 05:19:20 pm by Loaden »

Offline polygon7

  • Multiple posting newcomer
  • *
  • Posts: 104
    • Home site
Re: The 25 september 2010 build (6634) CODECOMPLETION BRANCH version is out.
« Reply #85 on: October 11, 2010, 05:33:25 pm »
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
#include "
C::B will use that "cache"?
best regards,
p7
 Free open source UML modeling tool: ArgoUML

Offline Loaden

  • Lives here!
  • ****
  • Posts: 1014
Re: The 25 september 2010 build (6634) CODECOMPLETION BRANCH version is out.
« Reply #86 on: October 11, 2010, 05:38:25 pm »
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
#include "
C::B will use that "cache"?
Yes, use std::map<wxString, std::list<wxString> > to save all system headers.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: The 25 september 2010 build (6634) CODECOMPLETION BRANCH version is out.
« Reply #87 on: October 11, 2010, 08:39:34 pm »
linux-kernel 2.6.29:
Code
Project 'test' parsing stage done (21821 total parsed files, 910203 tokens in 3 minute(s), 11.931 seconds).

linux-kernel 2.6.35:
Code
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.

Offline Loaden

  • Lives here!
  • ****
  • Posts: 1014
Re: The 25 september 2010 build (6634) CODECOMPLETION BRANCH version is out.
« Reply #88 on: October 12, 2010, 01:56:23 am »
I am just compiling it on my server, to update the cc-repo.
:D Thanks!

Offline Loaden

  • Lives here!
  • ****
  • Posts: 1014
Re: The 25 september 2010 build (6634) CODECOMPLETION BRANCH version is out.
« Reply #89 on: October 12, 2010, 08:55:28 am »
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!