Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
Clang CC
yvesdm3000:
--- Quote from: MortenMacFly on February 06, 2016, 08:44:33 pm ---OK, thank you. BTW: There are many more crash candidates. Unfortunately if you use this plugin on Windows it will definitely crash sooner or later. I've never been able to run a complete C::B session w/o crash. :-/
Another thing: Please don't use code that is not portable. alloca for example is very bad and should never be used. Also, currently your git HEAD is broken because it seems you did commit a file (tokendatabase.cpp) w/o resolving conflicts first.
If possible, I would recommend that you test this plugin from time to time on Windows. Be careful with hacks, they usually don't work on other platforms. If it compiles on Windows, I can help with that from time to time... just guide me what to do.
--- End quote ---
OK, it certainly looks like you are viewing the 'devel' branch since the alloca and merge-conflict stuff are in there. It should actually be named 'experimental' and contains a lot of hacks and other things that certainly should not be in master (like you pointed out).
To cope with this misunderstanding I'll create a new branch which is named 'experimental' and I hope it should be more clear for people trying stuff.
I now used the build from the 'master' brand on 16.01 on windows for a couple of hours without any crashing-issue. There is however some desync issue where *rarely* the chosen code-completion is not the one inserted in the editor that I'll look into shortly.
Yves
MortenMacFly:
--- Quote from: yvesdm3000 on February 10, 2016, 11:50:51 am ---OK, it certainly looks like you are viewing the 'devel' branch since the alloca and merge-conflict stuff are in there. It should actually be named 'experimental' and contains a lot of hacks and other things that certainly should not be in master (like you pointed out).
--- End quote ---
Ah - ok, that might be my mistake. I though "devel" is where development occurs and master you only use to sync with Alpha. Good to know. So I'll switch to master and try again...
yvesdm3000:
I made another push to master: Mostly speed and stability improvements.
https://github.com/yvesdm3000/ClangLib
Regarding code-completion, I think that is feature complete. I'm moving on to code-refactoring things.
Yves
ollydbg:
I have some questions:
1, what are the m_UnsavedFiles means in all the Jobs? (in clangproxy.h file), does every job need such parameter?
2, about SyncJob, you just want to run the task in worker thread, but the mainthread is just blocked, is it possible our ccmanager supply some interface which support synchronized request? I mean if ccmanager ask a code completion list, it just returned, and let a specific cc plugin to do the job to fill something(through synchronized api), and this way, we won't let the main gui thread get blocked
EDIT: I would suggest you can add some doxygen style document to the source code, so that people(include me) can read and understand or debug the code easily.
yvesdm3000:
Hi Ollydbg,
--- Quote from: ollydbg on February 21, 2016, 03:23:38 pm ---I have some questions:
1, what are the m_UnsavedFiles means in all the Jobs? (in clangproxy.h file), does every job need such parameter?
--- End quote ---
This is to give Clang access to the files that are open in the editor and are not saved, e.g. the changes that are in the buffer of the editor.
These are duplicated since Clang runs in a thread and the user might start changing them. It results in some nice asserts in libclang when not deep-copied. One might optimize this by only passing the ones that are needed, but it's more complicated than at first sight:
The user might have added an #include statement to an Unsaved header file and we haven't parsed the #include statement and thus we are unaware there is an UnsavedFile we need to pass, so for now I just chose to pass them all and postpone optimizations for later. It has a low impact and a lot less that I would have guessed at the start, so this would have been a premature optimization.
--- Quote ---2, about SyncJob, you just want to run the task in worker thread, but the mainthread is just blocked, is it possible our ccmanager supply some interface which support synchronized request? I mean if ccmanager ask a code completion list, it just returned, and let a specific cc plugin to do the job to fill something(through synchronized api), and this way, we won't let the main gui thread get blocked
--- End quote ---
SyncJob is mostly 'optionally' synchronous, e.g. the caller can wait for it with a timeout. Initially I didn't understand how the C::B 'GetAutocomplist' worked, it seemed like a synchronous operation to me so I figured I'd start a code-completion and when it took too long, just return empty and be ready for the next request. Later on I saw you can actually do the same code-completion request once the threaded one is finished so I figured I keep the timeout-implementation since it keeps the total operation simple&fast when the clang-operation is faster than 20 milliseconds. So theoretically the 'SyncJob' could be removed from the project again, or at least for the CodeCompleteAtJob.
On the other hand, I do think the 'GetAutocomplist'-call in the cc-plugin framework looks like an afterthought, something with a request event and a response event would probably have been much nicer, but I'm unaware of the lowlevel choices and scintilla if that would even be possible.
--- Quote ---EDIT: I would suggest you can add some doxygen style document to the source code, so that people(include me) can read and understand or debug the code easily.
--- End quote ---
Sure thing. I'll add it to the top of my todo list for you.
Yves
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version