Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
Clang CC
oBFusCATed:
--- Quote from: l_inc on November 15, 2015, 03:08:18 pm ---Btw. how is it going with integrating the plugin into codeblocks-contrib?
--- End quote ---
This one will land in the core someday. This is not a contrib plugin in.
--- Quote from: yvesdm3000 on November 16, 2015, 07:05:41 am ---For codeblocks-contrib, not sure if I am going to do this immediately, I think the plugin needs restructuring first. I want to split the plugin into pieces:
--- End quote ---
If you want to split this in multiple cb plugins, keep in mind that cb gets slower to start the more plugins there are installed (no matter if enabled or disabled).
Also do you really have added so much code you need to separate it into different pieces?
yvesdm3000:
--- Quote from: oBFusCATed on November 16, 2015, 08:43:39 am ---
--- Quote from: l_inc on November 15, 2015, 03:08:18 pm ---Btw. how is it going with integrating the plugin into codeblocks-contrib?
--- End quote ---
This one will land in the core someday. This is not a contrib plugin in.
--- Quote from: yvesdm3000 on November 16, 2015, 07:05:41 am ---For codeblocks-contrib, not sure if I am going to do this immediately, I think the plugin needs restructuring first. I want to split the plugin into pieces:
--- End quote ---
If you want to split this in multiple cb plugins, keep in mind that cb gets slower to start the more plugins there are installed (no matter if enabled or disabled).
Also do you really have added so much code you need to separate it into different pieces?
--- End quote ---
You do have a good point there. I would mostly do it so there would be room for other plugin developers to use Clang functionality without having to hack on the existing plugin. The best way to do that is to actually use this API ourselves and allow others replace certain behaviours.
Yves
l_inc:
yvesdm3000
--- Quote ---Obviously we can't assume users will always have enough memory to store that in memory, especially for pretty large projects.
--- End quote ---
Well, I have 16GBs in my work laptop, and I would appreciate an option to not drain my SSD of life with temporary stuff. Besides, you would still need to be able to handle low disk space situations, so why wouldn't you leverage the same out-of-space-avoidance mechanism in memory?
--- Quote --- it's better to have ALL files parsed into AST trees. [...] So for example 'goto implementation', it would first look in any TU in memory, if it can't find it, it would go into a slower mode and open each PCH file one by one and see if it can find what it's looking for.
--- End quote ---
Yes, and for the option of no on-disk ASTs it would be necessary to parse all the remaining TUs (a progress bar would make sense), but that's the price for not having enough cache space, no matter if it's on disk or in memory.
Alpha:
--- Quote from: l_inc on November 16, 2015, 12:59:02 pm ---yvesdm3000
--- Quote --- it's better to have ALL files parsed into AST trees. [...] So for example 'goto implementation', it would first look in any TU in memory, if it can't find it, it would go into a slower mode and open each PCH file one by one and see if it can find what it's looking for.
--- End quote ---
Yes, and for the option of no on-disk ASTs it would be necessary to parse all the remaining TUs (a progress bar would make sense), but that's the price for not having enough cache space, no matter if it's on disk or in memory.
--- End quote ---
The support I had initially attempted for in plan of this is TokenDatabase (roughly) keeps track (in memory) of where main definitions exist; then if any of those ASTs are not currently loaded, the could be found directly (not implemented), instead of having to re-parse the entire project. The project does need to be parsed once at least, and this index probably should be serialized for searching to be useful between sessions.
l_inc:
Alpha
This would only help with "find implementation". But "find all references" would still require to traverse the complete set of ASTs. So I support the TokenDatabase idea with respect to keeping it in memory for "find implementation" optimization, but no serialization, because re-/creation of all the non-existent ASTs is still needed for other things.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version