Home » Eclipse Projects » Dynamic Languages Toolkit (DLTK) » compilation unit vs. working copy
| compilation unit vs. working copy [message #27793] |
Mon, 07 July 2008 23:25  |
 Charles Doucette
Messages: 125
Registered: July 2009 |
Senior Member |
|
|
Since apparently we are unable to affect the internal DLTK model of our
source modules, we attempt to build and refine our own models. Somehow we
want the ability to distinguish between clean compilation units (not open as
editor input) and potentially dirty working copies (open in an editor
window). The model of a working copy could refer to something defined in a
model of a compilation unit, but not vice-versa. Thus, we believe we need a
way to distinguish between those two sources of input.
I've seen that the interface ISourceModule has the method isWorkingCopy.
Unfortunately, the parser interface methods that we can easily override do
not refer to that interface:
1) ISourceElementParser.parseSourceModule: (this is the high level interface
when I also do semantic checks per module)
public void parseSourceModule(char[] contents, ISourceModuleInfo astCache,
char[] filename) {
2) ISourceParser.parse: (this is the low level interface where I simply
create the AST tree and populate our corresponding model of declarations)
ModuleDeclaration parse(char[] fileName, char[] source, IProblemReporter
reporter);
The only other thing I see is that both methods have access to the current
IProblemReporter.
From another topic I was told that until you edit a module, IProblemReporter
will be null.
Is that currenly the only way to distinguish between a compilation unit and
a working copy - or is there another way?
Thanks,
Chuck
|
|
|
| Re: compilation unit vs. working copy [message #32822 is a reply to message #27793] |
Mon, 06 October 2008 16:09  |
Charles Doucette
Messages: 125
Registered: July 2009 |
Senior Member |
|
|
I'd still like to know how to distinguish between clean compilation units
(parsed and/or checked as part of a build) and potentially dirty working
copies (invoked from an editor).
Thanks,
Chuck
"Chuck Doucette" <cdoucette@vaultus.com> wrote in message
news:g4u8ni$803$1@build.eclipse.org...
> Since apparently we are unable to affect the internal DLTK model of our
> source modules, we attempt to build and refine our own models. Somehow we
> want the ability to distinguish between clean compilation units (not open
> as editor input) and potentially dirty working copies (open in an editor
> window). The model of a working copy could refer to something defined in a
> model of a compilation unit, but not vice-versa. Thus, we believe we need
> a way to distinguish between those two sources of input.
>
> I've seen that the interface ISourceModule has the method isWorkingCopy.
> Unfortunately, the parser interface methods that we can easily override do
> not refer to that interface:
>
> 1) ISourceElementParser.parseSourceModule: (this is the high level
> interface when I also do semantic checks per module)
> public void parseSourceModule(char[] contents, ISourceModuleInfo astCache,
> char[] filename) {
>
> 2) ISourceParser.parse: (this is the low level interface where I simply
> create the AST tree and populate our corresponding model of declarations)
> ModuleDeclaration parse(char[] fileName, char[] source, IProblemReporter
> reporter);
>
> The only other thing I see is that both methods have access to the current
> IProblemReporter.
> From another topic I was told that until you edit a module,
> IProblemReporter will be null.
>
> Is that currenly the only way to distinguish between a compilation unit
> and a working copy - or is there another way?
>
> Thanks,
>
> Chuck
>
>
>
>
|
|
|
| Re: compilation unit vs. working copy [message #32852 is a reply to message #32822] |
Mon, 06 October 2008 21:47 |
Charles Doucette
Messages: 125
Registered: July 2009 |
Senior Member |
|
|
Apparently - my build participants (except for the parser I assume) are now
supposed
to implement IBuildParticipant:
void build(ISourceModule module, ModuleDeclaration ast, IProblemReporter
reporter) throws CoreException;
I'm assuming I can distinguish between clean complition unit and a
potentially dirty working copy by looking at properties of the source
module, i.e. isWorkingCopy()?
Is that true?
Chuck
"Chuck Doucette" <cdoucette@vaultus.com> wrote in message
news:gcddad$ulu$1@build.eclipse.org...
> I'd still like to know how to distinguish between clean compilation units
> (parsed and/or checked as part of a build) and potentially dirty working
> copies (invoked from an editor).
>
> Thanks,
> Chuck
>
> "Chuck Doucette" <cdoucette@vaultus.com> wrote in message
> news:g4u8ni$803$1@build.eclipse.org...
>> Since apparently we are unable to affect the internal DLTK model of our
>> source modules, we attempt to build and refine our own models. Somehow we
>> want the ability to distinguish between clean compilation units (not open
>> as editor input) and potentially dirty working copies (open in an editor
>> window). The model of a working copy could refer to something defined in
>> a model of a compilation unit, but not vice-versa. Thus, we believe we
>> need a way to distinguish between those two sources of input.
>>
>> I've seen that the interface ISourceModule has the method isWorkingCopy.
>> Unfortunately, the parser interface methods that we can easily override
>> do not refer to that interface:
>>
>> 1) ISourceElementParser.parseSourceModule: (this is the high level
>> interface when I also do semantic checks per module)
>> public void parseSourceModule(char[] contents, ISourceModuleInfo
>> astCache, char[] filename) {
>>
>> 2) ISourceParser.parse: (this is the low level interface where I simply
>> create the AST tree and populate our corresponding model of declarations)
>> ModuleDeclaration parse(char[] fileName, char[] source, IProblemReporter
>> reporter);
>>
>> The only other thing I see is that both methods have access to the
>> current IProblemReporter.
>> From another topic I was told that until you edit a module,
>> IProblemReporter will be null.
>>
>> Is that currenly the only way to distinguish between a compilation unit
>> and a working copy - or is there another way?
>>
>> Thanks,
>>
>> Chuck
>>
>>
>>
>>
>
>
|
|
|
| Re: compilation unit vs. working copy [message #33094 is a reply to message #32852] |
Tue, 07 October 2008 07:19 |
Alex Panchenko
Messages: 342
Registered: July 2009 |
Senior Member |
|
|
isWorkingCopy() is one of the ways, also you can check buildType in the
beginBuild() method of the IBuildParticipantExtension
Regards,
Alex
Chuck Doucette wrote:
> Apparently - my build participants (except for the parser I assume) are now
> supposed
> to implement IBuildParticipant:
> void build(ISourceModule module, ModuleDeclaration ast, IProblemReporter
> reporter) throws CoreException;
>
> I'm assuming I can distinguish between clean complition unit and a
> potentially dirty working copy by looking at properties of the source
> module, i.e. isWorkingCopy()?
>
> Is that true?
>
> Chuck
>
> "Chuck Doucette" <cdoucette@vaultus.com> wrote in message
> news:gcddad$ulu$1@build.eclipse.org...
>> I'd still like to know how to distinguish between clean compilation units
>> (parsed and/or checked as part of a build) and potentially dirty working
>> copies (invoked from an editor).
>>
>> Thanks,
>> Chuck
>>
>> "Chuck Doucette" <cdoucette@vaultus.com> wrote in message
>> news:g4u8ni$803$1@build.eclipse.org...
>>> Since apparently we are unable to affect the internal DLTK model of our
>>> source modules, we attempt to build and refine our own models. Somehow we
>>> want the ability to distinguish between clean compilation units (not open
>>> as editor input) and potentially dirty working copies (open in an editor
>>> window). The model of a working copy could refer to something defined in
>>> a model of a compilation unit, but not vice-versa. Thus, we believe we
>>> need a way to distinguish between those two sources of input.
>>>
>>> I've seen that the interface ISourceModule has the method isWorkingCopy.
>>> Unfortunately, the parser interface methods that we can easily override
>>> do not refer to that interface:
>>>
>>> 1) ISourceElementParser.parseSourceModule: (this is the high level
>>> interface when I also do semantic checks per module)
>>> public void parseSourceModule(char[] contents, ISourceModuleInfo
>>> astCache, char[] filename) {
>>>
>>> 2) ISourceParser.parse: (this is the low level interface where I simply
>>> create the AST tree and populate our corresponding model of declarations)
>>> ModuleDeclaration parse(char[] fileName, char[] source, IProblemReporter
>>> reporter);
>>>
>>> The only other thing I see is that both methods have access to the
>>> current IProblemReporter.
>>> From another topic I was told that until you edit a module,
>>> IProblemReporter will be null.
>>>
>>> Is that currenly the only way to distinguish between a compilation unit
>>> and a working copy - or is there another way?
>>>
>>> Thanks,
>>>
>>> Chuck
>>>
>>>
>>>
>>>
>>
>
>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 11:31:50 GMT 2024
Powered by FUDForum. Page generated in 0.03423 seconds |
] 
Search
Help
Register
Login
Home
