Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Dynamic Languages Toolkit (DLTK) » compilation unit vs. working copy
compilation unit vs. working copy [message #27793] Mon, 07 July 2008 19:25 Go to next message
Charles Doucette is currently offline 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 12:09 Go to previous messageGo to next message
Charles Doucette is currently offline 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 17:47 Go to previous messageGo to next message
Charles Doucette is currently offline 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 03:19 Go to previous message
Alex Panchenko is currently offline 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
>>>
>>>
>>>
>>>
>>
>
>
Previous Topic:DLTK (and Eclipse) threads
Next Topic:How to get names of files in a project selected In Script Explorer?
Goto Forum:
  


Current Time: Sun Apr 20 19:34:44 EDT 2014

Powered by FUDForum. Page generated in 0.01688 seconds