Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [Dltk-dev] script parse/syntax errors not markers anymore on the file? (and shown in problems view)

I could fix it my self (in our code) if  forceProblemDetection  of ReconcileWorkingCopyOperation
What does that boolean do. i dont see it getting used anywhere

I created a usage for it in the makeConsistent call:

    public void makeConsistent(SourceModule workingCopy,
            IProblemRequestor problemRequestor) throws ModelException {
        if (!workingCopy.isConsistent() || forceProblemDetection) { << ADDED this or

if it is forced then go on
Problem is that SourceModule itself also has the same check again so i disabled that :

    public void makeConsistent(IProgressMonitor monitor) throws ModelException {
        // if (isConsistent()) return;

and then in my workspace resouce change listener i call reconcile() on the files that are changed
so that there cache is cleared before the builder runs

And then it also works consistently

johan




On Mon, Jul 28, 2008 at 8:47 PM, Johan Compagner <jcompagner@xxxxxxxxx> wrote:
thx
everything seem to work just as before and almost better :)

I am debugging the last thing that i like to see fixed.
And that is a file that is changed from outside eclipse (for example other editor)
That has "compile" errors in it

I noticed that this almost works..
Sometimes it reports it nicely when i do a refresh other times it doesnt
So i started digging.

And if i put 1 sleep in the code it works ;)

SourceParserUtil:

public static ModuleDeclaration getModuleDeclaration(ISourceModule module,
            IProblemReporter reporter, int flags, IContentAction action) {
        ISourceModuleInfoCache sourceModuleInfoCache = ModelManager
                .getModelManager().getSourceModuleInfoCache();
        try {
            Thread.sleep(1000);
        } catch (InterruptedException ex) {
            // TODO Auto-generated catch block
            ex.printStackTrace();
        }
        ISourceModuleInfo sourceModuleInfo = sourceModuleInfoCache.get(module);
        return getModuleDeclaration(module, reporter, sourceModuleInfo, flags,
                action);
    }

If i put in a sleep just before the sourceModuleInfoCache is accessed then the errors are reported like clockwork

This is because when i say to a file refresh yourself 2 things are running pretty much at the same time

1 the builder (the code above)
2 the ReconcileWorkingCopyOperation

that calls SourceModule:
    public void makeConsistent(IProgressMonitor monitor) throws ModelException {
        if (isConsistent()) return;
        // makeConsistent(false/*don't create AST*/, 0, monitor);

        // Remove AST Cache element
        ISourceModuleInfoCache sourceModuleInfoCache = ModelManager
                .getModelManager().getSourceModuleInfoCache();
        sourceModuleInfoCache.remove(this);
        openWhenClosed(createElementInfo(), monitor);
    }

And that removes the current one from the cache so if the builder comes just after that then it works because the builder will then parse
the file again. If the builders finds the moduleinfo then it reuses the previous one and that has already a module declaration so no parsing..

So how to fix this race condition? Should the builder just be kicked that it has to do its work after the makeConsistent/removefrom cache call?
So that it does parse and reports errors?

Or should the makeConsistent() call does that itself? make sure that it is parsed again? (that is in my eyes what makeConsistent does mean to me
be in a consistent (compiled up to date state)

 johan


On Mon, Jul 28, 2008 at 3:18 PM, Alex Panchenko <alex@xxxxxxxxx> wrote:
Johan Compagner wrote:
How should the validator core project contribute to that?

org.eclipse.dltk.validators.internal.core.ValidatorBuilder
implements IScriptBuilder

it is called from ScriptBuilder to parse all the files and report errors for them.

After that it calls "validators" (if there are any) to perform additional semantic checks, etc.

The messages with subject "bug #239707 discussion" are about that change.

Regards,
Alex


_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev



Back to the top