Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Which event triggers language settings provider and from where?
Hi all,

I improved the code now. I only re-read the comnpile_commands.json file and call the setup()/processLine()shutdown() sequence when it changed. That soved the problem.

best regards
Martin



Von:        Martin.Runge@xxxxxxxxxxxxxxxxx
An:        "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Kopie:        cdt-dev-bounces@xxxxxxxxxxx
Datum:        2015-09-22 10:53
Betreff:        Re: [cdt-dev] Which event triggers language settings provider and from where?
Gesendet von:        cdt-dev-bounces@xxxxxxxxxxx



Hi Andrew,

Yes, the you can see the problematic code here (currently head of master branch, commit 2a3117e04fb325bf2a2fcab8f3dc674b14d3bf6f ): (not very nice yet)

https://github.com/rungemar/cmake4cdt/blob/master/org.eclipse.cdt.cmake4cdt/src/org/eclipse/cdt/cmake/langset/CMakeLangSetProvider.java

I actually call the startup()/processLine()/shutdown() sequence inside getSettingsEntries(), but only for lazy initialisation or if the file "compile_commands.json" changed. So at the second call of getSettingsEntries(), the file already got evaluated and the startup()/processLine()/shutdown() sequence is omitted.

When I saw the problem, the check wether the file changed was not yet implemented and the sequence got called on every call to getSettingsEntries, I'm just improving this. But if there is no recursion, this should only lead to many iterations, not endless.

Do you think, it is a bad idea to call the startup()/processLine()/shutdown() sequence inside of getSettingsEntries() for lazy/on demand initialisation? I havea chosen this way, because the getSettingsEntries method is called with the configuration as argument. The rest of the LanguageSettingsprovider is configuration agnostic.

best regards
Martin






Von:        Andrew Gvozdev <angvoz.dev@xxxxxxxxx>
An:        "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Kopie:        cdt-dev-bounces@xxxxxxxxxxx
Datum:        2015-09-21 18:41
Betreff:        Re: [cdt-dev] Which event triggers language settings provider and from where?
Gesendet von:        cdt-dev-bounces@xxxxxxxxxxx



Hi Martin,
GCCBuildCommandParser does not listen to any events neither to resource change events. Moreover, it will check if the language settings for the provided configuration changed and if not it won't serialize anything. You could put a breakpoint in LanguageSettingsSerializableProvider.isLanguageSettingsProviderStoreChanged(...) to check why it thinks that settings change.

The effect that you are describing could be a result of calling startup()/processLine()/shutdown() sequence on each processed line. That would be just called for many lines and not
endlessly in a loop unless there is a recursion introduced in CMakeLangSetProvider.getSettingsEntries(). How do you implement this method?

Is this code currently on https://github.com/rungemar/cmake4cdt?

Thanks,
Andrew

On Mon, Sep 21, 2015 at 10:39 AM, <Martin.Runge@xxxxxxxxxxxxxxxxx> wrote:
Hi Andrew,

The language settings provider is implemented like this:

public class CMakeLangSetProvider extends LanguageSettingsBaseProvider implements ILanguageSettingsProvider
...
and uses an instance of e.g. GCCBuildCommandParser internally similar to this:
...
if comiler is gcc
    m_commandParser = new GCCBuildCommandParser();
if compiler is clang
   m_commandParser = new ClangBuildCommandParser();
if compiler is msvc
  m_commandParser = new MSVCBuildCommandParser();
...

I need to detect the compiler at runtime, so I do not know which compiler's build command parser to use until I parse the output in the cmake generated file "compile_commands.json". Thats why I don't derive from AbstractBuildCommandParser but use an instance of it.

In the meanwhile I found out, that I called startup() ...for all lines: processLine() .. shutdown()  every time getSettingsEntries got called. I thought, I can optimize that later and reparse the compiler_commands.json only if it changed. Now I think, that the serialisation happening on shutdown() somehow triggers another call to getSettingsEntries?

Another question:
is it possible to avoid the serialisation of the settings entries done by GCCBuildCommandParser and only use it to parse the commands and store them in memory so I can access the results by calling GCCBuildCommandParser.getSettingsEntries() ? I'm not sure if this is better at all... with cmake, many include paths may be unknown until cmake was run (Makefile generated). After that the compile_command.json file is also present, so I could consider it as the persistent storage. I would have to reparse it on every start of Eclipse, but the information would not be kept double and cannot get out of sync.

What do you think?

thanks for your reply.
Martin





Von:        Andrew Gvozdev <angvoz.dev@xxxxxxxxx>
An:        "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Datum:        2015-09-21 15:42
Betreff:        Re: [cdt-dev] Which event triggers language settings provider and from where?
Gesendet von:        cdt-dev-bounces@xxxxxxxxxxx




Hi Martin,
What kind of language settings provider is that? Is it derived from AbstractBuildCommandParser or AbstractBuiltinSpecsDetector?

Thanks,
Andrew

On Mon, Sep 21, 2015 at 3:41 AM, <Martin.Runge@xxxxxxxxxxxxxxxxx> wrote:
Hi all,

I have a language settings provider (CMakeLangSetProvider) that is called
endlessly in a loop. Unfortunetly it is run in a worker thread, so I
cannot see the cause that triggered it in the callstack (see below).

Where should I look at to find the cause that lets the language settings
provider's getSettingEntries() method beeing? Afaik, ressource changes
trigger the language settings provider and I can see the TreeView in
project Explorer flickering. But I don't understand why.

Is there a way to exclude some project folders like the output folder from
those triggering the language settings provider?

best regards
Martin


CMakeLangSetProvider.getSettingEntries(ICConfigurationDescription,
IResource, String) line: 70
LanguageSettingsProvidersSerializer$LanguageSettingsWorkspaceProvider.getSettingEntries(ICConfigurationDescription,
IResource, String) line: 180
LanguageSettingsProvidersSerializer.getSettingEntriesPooled(ILanguageSettingsProvider,
ICConfigurationDescription, IResource, String) line: 1421
LanguageSettingsProvidersSerializer.getSettingEntriesUpResourceTree(ILanguageSettingsProvider,
ICConfigurationDescription, IResource, String) line: 1449
LanguageSettingsProvidersSerializer.getSettingEntriesByKind(ICConfigurationDescription,
IResource, String, int, boolean, boolean) line: 1508
LanguageSettingsProvidersSerializer.getSettingEntriesByKind(ICConfigurationDescription,
IResource, String, int) line: 1550
PathEntryTranslator.collectResourceDataEntries(ICConfigurationDescription,
int, CResourceData, Set<ICLanguageSettingEntry>) line: 2064
PathEntryTranslator.access$11(ICConfigurationDescription, int,
CResourceData, Set) line: 2037
PathEntryTranslator$1.visit(PathSettingsContainer) line: 2025
PathSettingsContainer.doAccept(IPathSettingsContainerVisitor) line: 519
PathSettingsContainer.accept(IPathSettingsContainerVisitor) line: 515
PathEntryTranslator.collectEntries(IProject, ICConfigurationDescription)
line: 2017
ConfigBasedPathEntryStore.getEntries(IProject, ICConfigurationDescription)
line: 237
ConfigBasedPathEntryStore.handleEvent(CProjectDescriptionEvent) line: 198
CProjectDescriptionManager.notifyListeners(CProjectDescriptionEvent) line:
2212
SetCProjectDescriptionOperation.executeOperation() line: 140
SetCProjectDescriptionOperation(CModelOperation).execute() line: 341
SetCProjectDescriptionOperation(CModelOperation).run(IProgressMonitor)
line: 607
Workspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor)
line: 2241
SetCProjectDescriptionOperation(CModelOperation).runOperation(IProgressMonitor)
line: 638
XmlProjectDescriptionStorage(AbstractCProjectDescriptionStorage).setProjectDescription(ICProjectDescription,
int, IProgressMonitor) line: 203
CProjectDescriptionStorageManager.setProjectDescription(IProject,
ICProjectDescription, int, IProgressMonitor) line: 149
CProjectDescriptionManager.setProjectDescription(IProject,
ICProjectDescription, int, IProgressMonitor) line: 885
CProjectDescriptionManager.setProjectDescription(IProject,
ICProjectDescription, boolean, IProgressMonitor) line: 846
CProjectDescriptionManager$6.run(IProgressMonitor) line: 573
CProjectDescriptionManager$5.run(IProgressMonitor) line: 523
Workspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor)
line: 2241
CProjectDescriptionManager.runAtomic(IWorkspaceRunnable, ISchedulingRule,
IProgressMonitor) line: 519
CProjectDescriptionManager.access$2(IWorkspaceRunnable, ISchedulingRule,
IProgressMonitor) line: 517
CProjectDescriptionManager$4.run(IProgressMonitor) line: 498
Worker.run() line: 55
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev

Back to the top