| Re: [Dltk-dev] IScriptBuilder/IBuildParticipant questions |
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> dltk-dev@xxxxxxxxxxx <mailto: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 listdltk-dev@xxxxxxxxxxx <mailto:dltk-dev@xxxxxxxxxxx>
> https://dev.eclipse.org/mailman/listinfo/dltk-dev
>
--
-jae
_______________________________________________
dltk-dev mailing listdltk-dev@xxxxxxxxxxx <mailto:dltk-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/dltk-dev
_______________________________________________
dltk-dev mailing list
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