[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.technology.dltk] Re: Semantic checking - via validators?

But I thought that if your editing created a syntax error, it was
a) flagged in the editor window with a red marker
b) added to the problems window immediately (presumably via the problem 
reporter)

So, when is the problem reporter supposed to be set?

Indeed, I did run it in the debugger.
That's where I came up with:
 >> The problem appears to in SourceModule.getProblemReporter.
Specifically, the problem reporter is null because noProblemReporter is 
true:

protected IProblemReporter getProblemReporter(String natureId) throws 
CoreException {
// check for the working copy reporter first
ModelManager.PerWorkingCopyInfo wcInfo = getPerWorkingCopyInfo();
if (wcInfo != null) {
if (wcInfo.noProblemReporter) {
return null;
}

I'm not sure how the field noProblemReporter in 
ModelManager.PerWorkingCopyInfo becomes true, since I believe it is 
implicitly initialized to false, and I don't see any line of code that 
modifies its value.

Chuck

"Alex Panchenko" <alex@xxxxxxxxx> wrote in message 
news:g3f7ob$nab$1@xxxxxxxxxxxxxxxxxxxx
> Hi Chuck,
>
> The problem reporter is intentionally disabled (i.e. null) when the 
> parsing occurs during editor open, because we want to keep current markers 
> intact to be able to open the file from the problems/tasks view and 
> navigate to the line the marker is placed on.
>
> In all other situations it should work correctly. Have you tried stepping 
> through the code in the debugger to see why it is null?
>
> Regards,
> Alex
>
>
> Chuck Doucette wrote:
>> I wrote a visitor pattern to do semantic checking.
>> For the time being, I was attempting to invoke it whenever I invoked the 
>> parser.
>> It detects problems and tries to report them.
>> Unfortunately, the problem reporter is not instantiated (i.e. it is 
>> null).
>> Thus, no problems are reported (even though there are some).
>>
>> The problem appears to in SourceModule.getProblemReporter.
>>
>> Shouldn't we be able to add problems to the Problems view?
>>
>> Chuck
>>
>> "Andrei Sobolev" <haiodo@xxxxxxxxx> wrote in message 
>> news:g09mhq$9i2$1@xxxxxxxxxxxxxxxxxxxx
>>> Hi Chuck,
>>>
>>> Nice to see, what DLTK help you.
>>>
>>> We don't have something special in area of semantic analysis, etc.
>>>
>>> Where is some ways to implement such features:
>>> 1) Using of ScriptBuilder.
>>> In DLTK we have feature named ScriptBuilder. This is incremental 
>>> resource builder, used for building Mixin models, etc.
>>> It will give you list of changed resources, and you cold check all this 
>>> files and set appropriate markers.
>>> All Eclipse markers will be show in DLTK Text editors. ScriptBuilder 
>>> will contain information about builded resources,
>>> and will be executed on each resource operations, like "resource added", 
>>> "resource content changed".
>>>
>>> 2) You could use Validator, Validators framework uses Script Builder for 
>>> incremental execution of validators. One more
>>> additional point, validators framework manages validator instances and 
>>> allow unified way to sore configurations, etc.
>>> Also user could turn on/off and execute validators from DLTK UI.
>>>
>>> 3) If you also plan to make semantic checks for file edited, you need to 
>>> extend Reconciler from your
>>> ScriptSourceViewerConfiguration class. Reconciler will rebuild model, 
>>> and do checks, after user will make some changes
>>> in code. By default it is 500 milliseconds delay, so reconciler will be 
>>> executed only if user not type code 500
>>> milliseconds.
>>>
>>>
>>> References:
>>> 1) Extension point to implement: org.eclipse.dltk.core.builder
>>> 2) We have "package require" checker implemented for Tcl. 
>>> (TclCheckBuilder class).
>>> 3) ScriptSourceViewerConfiguration.getReconciler()
>>>
>>> Best regards,
>>> Andrei Sobolev.
>>>
>>>
>>>> Thanks to ANTLR and DLTK, I now have an advanced editor which can
>>>> immediately flag syntactic problems in our language source files.
>>>>
>>>> My question is if/when/how should I find/flag semantic errors in the 
>>>> source
>>>> file?
>>>>
>>>> 1.    Is there any part of DLTK framework which could/should be used to
>>>> invoke/perform semantic checks?    I assume the answer to this is no. I 
>>>> know
>>>> you support external validators - but we'd like the semantic checking 
>>>> to be
>>>> performed implicitly.
>>>>
>>>> 2.    When should semantic checks be performed - whenever the parser is
>>>> invoked?
>>>>
>>>> 3.    How should errors be reported - using the parser's error 
>>>> reporter?
>>>>         Also, how can we determine the line number for populating 
>>>> IProblem
>>>> in the file if that information is:
>>>>         a) not available in DLTKToken
>>>>         b) not kept in ASTNode
>>>>
>>>> Thanks,
>>>> Chuck
>>>>
>>>>
>>