[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
>>>>
>>>>
>>