Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [Dltk-dev] IScriptBuilder/IBuildParticipant questions
 
  but i am only passed module A when the the validator is called, i would need access to the ISourceModule object for module B as well.

  it looks like after the ISourceModule was compiled, if it was successful, i could look up the IModuleElement used to represent module B, clear its markers, and recompile it again. a marker would probably be best suited to hold this information against the resource.

  the tricky part would be getting the reference the module A when module B is compiled to let module A know that B depends on it.

  maybe i'd be better off implementing an IScriptBuilder instead?

On Wed, Oct 1, 2008 at 9:45 PM, Alex Panchenko <alex@xxxxxxxxx> wrote:
Dependency tracking is supposed to be internal to the IValidator implementation - the method is called with the list of source modules (either manually right clicked by the user or changed before the build operation).

If it was passed A and validator knows that B depends on A - just validate B too.
The hard part here is actually tracking dependencies - execute perl several times is quite easier.

IScriptBuilder interface supports dependency tracking and IValidator could be extended to support it too, but I don't see the benefit - external validation is quite independent so there is no gain if additional modules would be added externally to the IValidator or internally in it.

Alex

----- Original Message -----
From: "Jae Gangemi" <jgangemi@xxxxxxxxx>
To: "DLTK Developer Discussions" <dltk-dev@xxxxxxxxxxx>
Sent: Thursday, October 2, 2008 8:03:14 AM GMT +06:00 Almaty, Novosibirsk
Subject: Re: [Dltk-dev] IScriptBuilder/IBuildParticipant questions




i have another question :)

how can i track dependencies for 'perl -c' output using the IValidator interface?

for example:

- module A has compile error
- module B uses module A
- module A gets fixed
- module B should be recompiled again as it is a dependent of module A


On Mon, Sep 29, 2008 at 7:49 AM, Jae Gangemi < jgangemi@xxxxxxxxx > wrote:




thanks for the explanation alex. i'll take a look and i'm sure i'll be back w/ additional questions.





On Mon, Sep 29, 2008 at 2:02 AM, Alex Panchenko < alex@xxxxxxxxx > wrote:


Jae,

I did not mention explicitly the interfaces of the 3rd part - IValidatorType/IValidator/ISourceModuleValidator - the API to call external process to perform some code checks/validation.

So there are 3 parts of the builder API in the DLTK:
- IScriptBuilder is the general API
- IBuildParticipant is the API to implement code checks in java code
- IValidator is the API to call external validation process

At the moment there are 2 implementations of the IValidator API:

A) Tcl checker
- org.eclipse.dltk.tcl.internal.tclchecker.TclCheckerType is a factory
- org.eclipse.dltk.tcl.internal.tclchecker.TclCheckerImpl is a configured instance
- org.eclipse.dltk.tcl.internal.tclchecker.TclChecker is a runtime instance

B) External Checker
- org.eclipse.dltk.validators.internal.externalchecker.core.ExternalCheckerType is a factory
- org.eclipse.dltk.validators.internal.externalchecker.core.ExternalChecker is a configured instance
- org.eclipse.dltk.validators.internal.externalchecker.core.ExternalCheckerWorker is a runtime instance

External validators are configured in the Preferences - DLTK - Validators

The list have checkboxes for each validator. If the checkbox is active - the validator is started automatically from the ValidatorBuilder (it implements IScriptBuilder). The checkbox is there since executing external process is time consuming operation, so the end user is able to enable/disable it.

Also they could be executed manually using popup menus:
- on the model element in the script explorer
- in the script editor
(the command in the popup menu is shown only if there are available validators)

The 'perl -c' is the ideal use case for the IValidator API. You just don't need to configure the path of executable and use the interpreter instead.

Today I am going to do refactoring of IBuildParticipant and move it to the dltk.core plugin. After that I will document all builders API in the Wiki.

Regards,
Alex


Jae Gangemi wrote:




ahh - i was wondering why the 'add' button was grey-ed out on that page.

that mechanism isn't going to work for invoking 'perl -c'. the code needs to be compiled using whatever interpreter is configured for the project.

now that i understand the difference between the IScriptBuilder and IBuildParticipant extensions, i'll start putting together an IScriptBuilder implementation for this. i'll try to come up w/ something generic so ruby and other languages can leverage it as well.

thx!

On Sun, Sep 28, 2008 at 9:56 PM, Alex Panchenko < alex@xxxxxxxxx <mailto: alex@xxxxxxxxx >> wrote:

One can use external checker without programming - it is developed
for end users and is fully configurable via UI.
Preferences - DLTK - Validators - [Add] and so on.

Alex

----- Original Message -----

From: "Jae Gangemi" < jgangemi@xxxxxxxxx <mailto: jgangemi@xxxxxxxxx >>
To: "DLTK Developer Discussions" < dltk-dev@xxxxxxxxxxx

<mailto: dltk-dev@xxxxxxxxxxx >>
Sent: Monday, September 29, 2008 8:49:59 AM GMT +06:00 Almaty,
Novosibirsk
Subject: Re: [Dltk-dev] IScriptBuilder/IBuildParticipant questions

i'm confused by what you mean about first testing it and then
building a
perl specific implementation.

On Sun, Sep 28, 2008 at 9:45 PM, Alex Panchenko < alex@xxxxxxxxx

<mailto: alex@xxxxxxxxx >> wrote:

> They are similar.
> tclchecker is designed to run one specific application,
> external checker could run any application - user is able to
configure
> patterns to be parsed in the UI
>
> I mean first you could test it with the external checker and
after that
> make a specific implementation for perl.
>
> Alex
>
> ----- Original Message -----

> From: "Jae Gangemi" < jgangemi@xxxxxxxxx <mailto: jgangemi@xxxxxxxxx >>
> To: "DLTK Developer Discussions" < dltk-dev@xxxxxxxxxxx

<mailto: dltk-dev@xxxxxxxxxxx >>
> Sent: Monday, September 29, 2008 8:38:45 AM GMT +06:00 Almaty,
Novosibirsk
> Subject: Re: [Dltk-dev] IScriptBuilder/IBuildParticipant questions
>
>
>
>
> are there any working examples of something run via an external
validator?
>
> how does an external validator differ from what is used in the
'tclchecker'
> implementation?
>
>
> On Sun, Sep 28, 2008 at 9:24 PM, Alex Panchenko < alex@xxxxxxxxx

<mailto: alex@xxxxxxxxx > > wrote:
>
>
> Hi Jae,
>
> IScriptBuilder is a general DLTK API to help with implementing
builders -
> it accepts the list of source modules that should be built.
>
> IBuildParticipant is an API to provide simple "steps" to be
executed by
> some standard builder. The idea is that subsequent steps may
need some
> information provided by the previous - e.g. the AST, so file
would be parsed
> only once.
>
> Regarding the 'perl -c' - first you should try running it via
external
> validator (this is a separate plugin to run external modules and
parse the
> output).
>
> Regards,
> Alex
>
>
>
>
> ----- Original Message -----
> From: "Jae Gangemi" < jgangemi@xxxxxxxxx

<mailto: jgangemi@xxxxxxxxx > >
> To: "DLTK Developer Discussions" < dltk-dev@xxxxxxxxxxx



<mailto: dltk-dev@xxxxxxxxxxx > >
> Sent: Monday, September 29, 2008 6:50:59 AM GMT +06:00 Almaty,
Novosibirsk
> Subject: [Dltk-dev] IScriptBuilder/IBuildParticipant questions
>
>
>
> hello all -
>
> i was wondering if someone could explain the direction that is
being taken
> with the IBuildParticipant and associated interfaces that have
been added to
> 'org.eclipse.dltk.validators.core' and the different between
implementing an
> IScriptBuilder interface.
>
> i'd like to add compiler support to my plugin (ie, 'perl -c') -
i started
> looking into implementing an IScriptBuilder, but it also seems
that i could
> implement an IBuildParticipant as well, but that is controlled
by the
> ValdatorRuntime, which itself is an implementation of an
IScriptBuilder, so
> these things are all related.
>
> perhaps there should be something like a 'BuilderRuntime' that
controlled
> IBuildParticipants, and the ValidatorRuntime would control
> IValidatorParticipants. things like compiling, task tag parsing,
etc would
> be executed by the BuilderRuntime and anything that serves to
validate
> source would be executed by the ValidatorRuntime, both would run
as part of
> an auto build and the validators could still be run independently.
>
> --
> -jae
>
> _______________________________________________
> dltk-dev mailing list
> dltk-dev@xxxxxxxxxxx <mailto: dltk-dev@xxxxxxxxxxx >

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

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

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

> https://dev.eclipse.org/mailman/listinfo/dltk-dev
>



--
-jae

_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx <mailto: dltk-dev@xxxxxxxxxxx >

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

https://dev.eclipse.org/mailman/listinfo/dltk-dev




--
-jae
------------------------------------------------------------------------

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




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



--
-jae



--
-jae

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



--
-jae

Back to the top