Good news people! I have finished Stage 1 of the code completion redesign. After fixing the crashes, hangs and unexpected exceptions ( :mrgreen: ), I managed to optimize most of the Codecompletion plugin. You'll notice a significant speed-up related to previous versions - specially when saving files.
I'll commit as soon as I finish recompiling latest SVN :eek: and test.
Benchmarks welcome :)
Post-Edit notes:
1) Warning! I may have possibly caused one or two unicode bugs since my C::B version is ANSI (i needed to debug some strings and unicode had a bug in there). But I can't wait anymore to commit, i'm sure any unicode-related bugs can be fixed in very little time.
2) Tested - ANSI version works like charm! :D I also removed redundant categories from the symbols (i.e. classes, defines, others) if they contain no tokens. I'll commit now :)
3) Oops, I forgot to mention... the Load/Save progress dialog of the codecompletion cache has been wiped out. Anyway i really hope you don't miss it, because:
Done parsing project Code::Blocks ANSI (wx2.6) (485 total parsed files, 14999 tokens in 0.813 seconds).
<- and that's unoptimized :D
4) Hit my first bug :( Apparently, when loading the cache, the class browser isn't updated. This is bad! :( I need some help with this guys. Probably an event not triggered or something. In any case, i'll still commit. I'm sure we can spare the cache for now. Sorry :?
Commited (revision 1711 ). Enjoy :)
That's just great Rick. Thanks :D
Feedback: "Search->Go to function" no longer works...
Ouch. OK, i'll see what I can do. Just a question, is the said function present in the class browser, or it's gone (as if the token wasn't generated in the first place)?
Update: Apparently the cache problem is more complicated than i thought :( But I spotted two bugs already! :)
1) When loading from the cache, the tree pointer is still uninitialized in the tokens, so that's the reason for the crash if you invoce codecompletion when cached. This one's very easy to fix.
2) The namespaces and global namespace list isn't updated when loading from the cache. This could be the bug responsible for the class browser not being updated. I'll see if these objects can be updated in the token addition instead of afterwards.
I'll fix them tonight.
Fix "Search->Go to function" please. I can't work without it :P
Btw, you did notice I added support for unicode wxStrings in the debugger, didn't you?
I bet you would now like STL support too, right? ;)
Quote from: mandrav on January 12, 2006, 06:28:03 PM
Fix "Search->Go to function" please. I can't work without it :P
Nevermind, I 've fixed it myself :)
In
Parser::ParseBufferForFunctions replace
Quote
ParserThread* thread = new ParserThread(this,&this->m_abort_flag,
wxEmptyString,
false,
opts,
m_pTokens);
with
Quote
ParserThread* thread = new ParserThread(this,&this->m_abort_flag,
wxEmptyString,
false,
opts,
m_pTempTokens);
Quote from: mandrav on January 12, 2006, 06:36:51 PM
Nevermind, I 've fixed it myself :)
Thanks! :D One less problem to worry about. Please commit it, since in last night's fix-attempt i modified too much code unnecessarily, so i'll have to update.
Oh btw... I search for funtions using ctrl-f :P (no kidding :shock: )
Quote from: rickg22 on January 12, 2006, 08:05:02 PM
Oh btw... I search for funtions using ctrl-f :P (no kidding :shock: )
It's the same thing but it only takes 2-3 keypresses usually, instead of typing the whole function name ;)
About that, I sent you a PM about a new feature request. :) You'll like the idea.
Edit: nevermind... i tried the goto function now :P
Caché loading is finally fixed! :D
There was a problem with LoadIntFromFile... apparently the -1 was read as -256. Yianniis, any idea of why this happens?
In any case, i replaced the "== -1", for "< 0" and now works like charm. Yes, creepy. :shock:
This code is in the latest SVN head, or the code that is published in the nightly builds?
The Nightly Builds are compiled from SVN head. Last post, from January 13, says something was fixed, so any Nightly Build after that date (maybe including) will have those fixes.
I am having a problem with a codecompletion (rev 1800) following project following includes right. I hav the following directory structure:
/math
/include
/src
Math.cbp
/common
/include
/src
/test
/src
mathtest.cpp
tests.cbp
The tests.cbp project has these includes ../common/include and ../math/include (on the one and only target in the file), but every time I tell the parser to follow local and global includes it still doesn't get any symbols from those headers. It doesn't seem to parser them at all. If I open up the Math.cbp project it parsed all the headers that are its files fine, but it to doesn't follow the ../common/include (which is global includes for all targets in the project) path to parse those files.
Is it just me or the "Go to declaration" and "Go to implementation" when you right click on an item of the class browser takes you to the wrong place?
I tried that today with many items and it always took me to the wrong file at a "random" line.
Quote from: Game_Ender on January 19, 2006, 08:46:57 AM
The tests.cbp project has these includes ../common/include and ../math/include (on the one and only target in the file), but every time I tell the parser to follow local and global includes it still doesn't get any symbols from those headers.
Hmmm, this case I really don't know. My modifications only optimized the parsing of the files, (and screwed up the codecompletion :P ), but i don't remember altering the logic behind the include paths. Can you try this with... (eew) RC2 (please install in another directory) and tell if it works?
Quote from: Ceniza on January 19, 2006, 10:59:52 AM
Is it just me or the "Go to declaration" and "Go to implementation" when you right click on an item of the class browser takes you to the wrong place?
Hmm I'll check it out...