Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
CC makes C::B hang in ExpandBackticks
MortenMacFly:
--- Quote from: oBFusCATed on January 04, 2013, 12:53:58 am ---For me it is almost impossible to rebuild cb's workspace at the moment.
--- End quote ---
In your BT I don-t even see what goes wrong... ???
Jenna:
--- Quote from: MortenMacFly on January 04, 2013, 06:33:37 am ---
--- Quote from: jens on January 04, 2013, 01:29:53 am ---I can reproduce the issue not always but quite often, it's always ExpandBackticks called by CC-timer which hangs.
--- End quote ---
I can't. :( Must be Linux only - maybe because under Windows there is nothing to expand...?! Did you manage to find a way to reproduce it under Windows? Is it really ExpandBackticks only?
Edit: Oh, and BTW: Where does CC call ExpandBackticks? I didn't find it with a quick search...
--- End quote ---
CC calls GetCommandGenerator in AddProjectToParser.
The commandgenerator get initiated and calls SetupCompilerOptions, SetupLinkerOptions etc.
And this calls ExpandBackticks.
wxExecute always hangs in wxGUIAppTraits::WaitForChild() or wxPipeInputStream::CanRead().
The latter might be the real issue for some reason I don't know.
I just saw that I forgot to attach the full bt in one of my prior posts.
I attach it here.
oBFusCATed:
--- Quote from: MortenMacFly on January 04, 2013, 06:37:40 am ---In your BT I don-t even see what goes wrong... ???
--- End quote ---
The strangest thing is that it happens if I run cb from cb, if I use the run.sh script it works.
MortenMacFly:
--- Quote from: jens on January 04, 2013, 09:30:28 am ---CC calls GetCommandGenerator in AddProjectToParser.
--- End quote ---
So it means this is the actually command that should be wrapped in an event, or is it the wxExecute call in the compiler? The latter is more hard to do, cause it would change the logic in CC as the call does immediately return w/o a result.
I wonder what's best here:
Actually calling GetCommandGenerator is done to obtain the project include dirs which will trigger wxExecute if backticked expressions are in place. Maybe a better solution is if CC does not use CommandGenerator at all, but evaluates the project / target settings itself, including executing what ever. Another option is to move the method from CommandGenerator to the core and wrap it there... maybe extend project manager.
What would be a good thing to do [tm]?
oBFusCATed:
--- Quote from: MortenMacFly on January 04, 2013, 11:39:53 am ---Maybe a better solution is if CC does not use CommandGenerator at all, but evaluates the project / target settings itself, including executing what ever.
--- End quote ---
Why? Duplicating code is never a good thing.
BTW: I'm looking why the no-change-build of cb is slow. It turned out that the DirectCommands object is recreated tons of times (takes 30-50% time).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version