Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[atf-dev] Re: atf-dev Digest, Vol 7, Issue 12

FWIW, there are actually two different Javascript validators:

The JS Syntax validator uses Rhino, and lacking any more complex
context-sensitive mechanism like a full parse tree, we're doing the
quick and dirty approach of just running the whole file through
Rhinio's parser "as you type" as well as in batch mode.  The
validation mechanism does seem to do a fairly good job grouping these
requests.  You should be able to cancel; if you can't, it's a bug.
Performance isn't great, but it seems tolerable.

We also run the code through JSLint, which itself is implemented in
Javascript and executed through Rhino.  Not surprisingly, this is an
order of magnitude slower.

You should be able to pick and choose between these validators, and as
Gino points out, we might be able to get away with skipping some
files, like toolkits, which hopefully don't have too many errors :-P

To truly get a fast performing validation and an incremental one, I
think, requires a much more complex approach.  This admittedly was a
tradeoff in the early days of ATF to get the feature running.  There
may still be some room to cache Rhino objects to make this stuff run a
bit faster.

-Adam

On 10/23/06, atf-dev-request@xxxxxxxxxxx <atf-dev-request@xxxxxxxxxxx> wrote:
Send atf-dev mailing list submissions to
        atf-dev@xxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
        https://dev.eclipse.org/mailman/listinfo/atf-dev
or, via email, send a message with subject or body 'help' to
        atf-dev-request@xxxxxxxxxxx

You can reach the person managing the list at
        atf-dev-owner@xxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of atf-dev digest..."


Today's Topics:

   1. javascript validator slowness (John J. Barton)
   2. RE: javascript validator slowness (Philippe Ombredanne)
   3. Re: javascript validator slowness (Gino Bustelo)
   4. Re: javascript validator slowness (David M Williams)


----------------------------------------------------------------------

Message: 1
Date: Sun, 22 Oct 2006 16:55:19 -0700
From: "John J. Barton" <johnjbarton@xxxxxxxxxxxxxxx>
Subject: [atf-dev] javascript validator slowness
To: atf-dev@xxxxxxxxxxx
Message-ID: <5.1.1.6.2.20061022165155.01eb4c80@xxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"

An HTML attachment was scrubbed...
URL: http://eclipse.org/pipermail/atf-dev/attachments/20061022/d0fa3722/attachment.html

------------------------------

Message: 2
Date: Sun, 22 Oct 2006 18:06:04 -0700
From: "Philippe Ombredanne" <pombredanne@xxxxxxxxx>
Subject: RE: [atf-dev] javascript validator slowness
To: "'AJAX Toolkit Framework discussion'" <atf-dev@xxxxxxxxxxx>
Message-ID: <05fc01c6f63f$6b608ce0$0dfbfdc0@computer>
Content-Type: text/plain;       charset="US-ASCII"

John
You wrote:
>I have a javascript file that the validator does not like. To
>spite me it makes editing excruciatingly slow.  Is there a way to
>tell it to stop, give up, you will not be able to validate this file?
IMHO WTP validation is subpar speed wise in general.
And ATF uses the WTP validation framework. :-\

Yet you can disable it either globally in the prefs, or for a project in
the project properties.
You can also always "kill" a currently running validation in the
progress view.
I typically use the global validation prefs such that it is set to be
only manual  (ie not triggered by a build) and invoke it manually now
and then.
I did also define a keybing of rth validate command in the prefs
(Uncategorized ?validate ) to make that process less of a PITA.

If you have some ideas to make it work better and faster in general that
would be nice.
May be something like incremental validation would help quite a bit!
Cordially

--
Cheers
Philippe

philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com
nexB - Open by Design (tm) - http://www.nexb.com
http://easyeclipse.org  -  irc://irc.freenode.net/easyeclipse




------------------------------

Message: 3
Date: Mon, 23 Oct 2006 10:03:34 -0500
From: "Gino Bustelo" <lbustelo@xxxxxxxxx>
Subject: Re: [atf-dev] javascript validator slowness
To: pombredanne@xxxxxxxxx,      "AJAX Toolkit Framework discussion"
        <atf-dev@xxxxxxxxxxx>
Message-ID:
        <3d5064390610230803n6206ceeaod52de872a0ffa873@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"

One idea that we are thinking of implementing is something analogous to the
.cvsignore file. We would call it .jsvalidateignore or something like that.
The concept is that we will have the JS validator look at for this file in
every folder and determine what should be validated. A good use for this is
to be able to ignore the entire set of javascript files of an Ajax
runtime/framework. A user of Dojo does not really care about errors inside
Dojo because he either does not know how to fix them or is really out of his
control.

Thanks,

Gino Bustelo
ATF Developer

On 10/22/06, Philippe Ombredanne <pombredanne@xxxxxxxxx> wrote:
>
> John
> You wrote:
> >I have a javascript file that the validator does not like. To
> >spite me it makes editing excruciatingly slow.  Is there a way to
> >tell it to stop, give up, you will not be able to validate this file?
> IMHO WTP validation is subpar speed wise in general.
> And ATF uses the WTP validation framework. :-\
>
> Yet you can disable it either globally in the prefs, or for a project in
> the project properties.
> You can also always "kill" a currently running validation in the
> progress view.
> I typically use the global validation prefs such that it is set to be
> only manual  (ie not triggered by a build) and invoke it manually now
> and then.
> I did also define a keybing of rth validate command in the prefs
> (Uncategorized ?validate ) to make that process less of a PITA.
>
> If you have some ideas to make it work better and faster in general that
> would be nice.
> May be something like incremental validation would help quite a bit!
> Cordially
>
> --
> Cheers
> Philippe
>
> philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com
> nexB - Open by Design (tm) - http://www.nexb.com
> http://easyeclipse.org  -  irc://irc.freenode.net/easyeclipse
>
>
> _______________________________________________
> atf-dev mailing list
> atf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/atf-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eclipse.org/pipermail/atf-dev/attachments/20061023/3a7846d5/attachment.html

------------------------------

Message: 4
Date: Mon, 23 Oct 2006 11:49:49 -0400
From: David M Williams <david_williams@xxxxxxxxxx>
Subject: Re: [atf-dev] javascript validator slowness
To: AJAX Toolkit Framework discussion <atf-dev@xxxxxxxxxxx>
Message-ID:
        <OFF29C4ACF.07D4F2F3-ON85257210.00567164-85257210.0056F4BD@xxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"

Seems to me the .cvsignore file is useful only because CVS (an external
system) uses it already. That's not the case here, right?

I'd think some more direct way of controlling validation preferences (via
normal validation framework) would be more Eclipse-integrated.

BTW, I agree with the incremental validation statement, and will also
point out that validators should be easily cancelable.
For example, if this problem is with "as you type" validation, you'll want
to be sure any current validation cycles are canceled once a new keystroke
comes in.






"Gino Bustelo" <lbustelo@xxxxxxxxx>
Sent by: atf-dev-bounces@xxxxxxxxxxx
10/23/2006 11:03 AM
Please respond to
AJAX Toolkit Framework discussion <atf-dev@xxxxxxxxxxx>


To
pombredanne@xxxxxxxxx, "AJAX Toolkit Framework discussion"
<atf-dev@xxxxxxxxxxx>
cc

Subject
Re: [atf-dev] javascript validator slowness






One idea that we are thinking of implementing is something analogous to
the .cvsignore file. We would call it .jsvalidateignore or something like
that. The concept is that we will have the JS validator look at for this
file in every folder and determine what should be validated. A good use
for this is to be able to ignore the entire set of javascript files of an
Ajax runtime/framework. A user of Dojo does not really care about errors
inside Dojo because he either does not know how to fix them or is really
out of his control.

Thanks,

Gino Bustelo
ATF Developer

On 10/22/06, Philippe Ombredanne <pombredanne@xxxxxxxxx > wrote:
John
You wrote:
>I have a javascript file that the validator does not like. To
>spite me it makes editing excruciatingly slow.  Is there a way to
>tell it to stop, give up, you will not be able to validate this file?
IMHO WTP validation is subpar speed wise in general.
And ATF uses the WTP validation framework. :-\

Yet you can disable it either globally in the prefs, or for a project in
the project properties.
You can also always "kill" a currently running validation in the
progress view.
I typically use the global validation prefs such that it is set to be
only manual  (ie not triggered by a build) and invoke it manually now
and then.
I did also define a keybing of rth validate command in the prefs
(Uncategorized ?validate ) to make that process less of a PITA.

If you have some ideas to make it work better and faster in general that
would be nice.
May be something like incremental validation would help quite a bit!
Cordially

--
Cheers
Philippe

philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com
nexB - Open by Design (tm) - http://www.nexb.com
http://easyeclipse.org   -  irc://irc.freenode.net/easyeclipse


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eclipse.org/pipermail/atf-dev/attachments/20061023/e6db92e4/attachment.html

------------------------------

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


End of atf-dev Digest, Vol 7, Issue 12
**************************************



Back to the top