Announce: Jsure, a static Javascript analyzer, checks syntax, catches undeclared variables and bad regexes.
berke...@gmail.com
I'd like to announce the availability of a new Javascript verifier,
Jsure. In addition
to checking the syntax of your Javascript files, it can catch things
like bad regular expressions, property names some browsers don't like,
access to variables not
visible in the scope as well as some other things.
Jsure is fully open-source and is released under the LGPL.
Exalead, where Jsure was developed, has been using it daily for more
than 6 months now on the Javascript-heavy shared social desktop Baagz
(http://baagz.com/).
Jsure is a stand-alone command-line tool which comes as a single
binary with no particular dependencies (save for things like libc).
You need neither Rhino nor a
JVM to run it. Pre-compiled binaries for Linux (x86, amd64) and Mac
are available.
You can also use Jsure online thru the web interface at http://jsure.org/
Javascript code, being dynamic, is difficult to analyze. But even
basic checks,
(such as attempts to catch uses of undefined variables or of unused
function
arguments) combined with some developer discipline turn out to be
useful.
Note 1. To compile Jsure, you need to install Aurochs (http://
aurochs.fr/)
which is used as its parsing engine (and is also LGPL).
Note 2. The command-line version has some experimental features such
as an attempt at type-checking or an edit-distance based spell checker
for identifiers.
--
Berke DURAK
MC
MC
timothytoe
> I have tried to use it on the website...it does not seem to be working.
> MC
I just now used the web version. It caught two problems jslint missed.
Henry
wrote:
> Hello,
>
> I'd like to announce the availability of a new Javascript
> verifier, Jsure. In addition to checking the syntax of your
> Javascript files, it can catch things like bad regular
> expressions, property names some browsers don't like,
> access to variables not visible in the scope as well as
> some other things.
This is a joke, right? Apart from not working at all on IE 6 (which is
pretty bad), given the input:-
var x;
x = (x >>> 0);
- it produces the output:-
| ERROR: In file "*stdin*", parse error at line 2, column 9:
| 2 x = (x >>> 0);
- highlighting the third chevron in the unsigned right shift operator.
The very least a javascript checker should be expected to do is to
recognise all of the operators available in javascript.
The line numbers in the output get way off very quickly and some of
the subjects of complaints are very arbitrary, such as:-
function x(ev){
ev = (ev || window.event);
...
}
- which is pretty standard browser scripting, gets the 'warning':-
| WARNING: In file "*stdin*" at line 2, columns 4 to 28: Assigning to
argument "ev":
| 2 ev = (ev || window.event);
berke...@gmail.com
No.
> Apart from not working at all on IE 6 (which is
> pretty bad),
I'll have that checked. You're talking of the web interface I assume?
> given the input:-
>
> var x;
> x = (x >>> 0);
> - it produces the output:-
>
> | ERROR: In file "*stdin*", parse error at line 2, column 9:
> | 2 x = (x >>> 0);
>
> - highlighting the third chevron in the unsigned right shift operator.
> The very least a javascript checker should be expected to do is to
> recognise all of the operators available in javascript.
Fixed in the source tree. No need to write five paragraphs, a simple
"it doesn't recognize the unsigned right shift operator" would have
been enough.
> The line numbers in the output get way off very quickly
This could be a CR or CR/LF issue. Are you using a mac?
Do you have any examples?
> and some of
> the subjects of complaints are very arbitrary, such as
> ...
> | WARNING: In file "*stdin*" at line 2, columns 4 to 28: Assigning to
> argument "ev":
> | 2 ev = (ev || window.event);
That's why every warning is configurable to suit your coding
practices. The option you're looking for is
"-assigning-to-args i". You can also use "-ignorify" to
suppress warnings on specific subtrees of your source directory.
--
Berke Durak
Dr J R Stockton
3g2000hse.googlegroups.com>, Mon, 10 Mar 2008 11:25:24,
"berke...@gmail.com" <berke...@gmail.com> posted:
BTW, it's not entirely happy about the newsgroup FAQ (and there's very
little active JavaScript in the FAQ) :
WARNING: In file "*stdin*" at line 9, columns 0 to 17: Toplevel binding
to "hash":
9 hash=location.hash;
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
For news:borland.*, use their server newsgroups.borland.com ; but first read
their Guidelines etc. via <URL:http://support.codegear.com/newsgroups/> ff.
Berke Durak
> In comp.lang.javascript message <b947f147-62e0-4180-897b-df3d44a32453@k1
> 3g2000hse.googlegroups.com>, Mon, 10 Mar 2008 11:25:24,
> "berke...@gmail.com" <berke...@gmail.com> posted:
>>
>>You can also use Jsure online thru the web interface at http://jsure.org/
>>
>
> ISTM that the Web home page of a verifier should itself be valid HTML,
> using W3 as by Opera Ctrl-Alt-V.
I agree, and will pass the blame to the person who did the front-end.
> ISTM also that, when given its own URL, it should not give any errors,
> rather than a large number (in Opera).
It gives warnings, not errors. To be expected. See the paragraph below on
conformance.
> And that orange and pale red are not wisely-chosen colors for that
> report.
> ISTM that the page should display reasonably in MS IE 6, and that it
> should do something when its button is pressed. Neither is so.
Maybe, but only if this is due to lack of compliance on our part.
Otherwise, there is no need to support obsolescent browsers in a tool
targeted at web developers.
> ISTM that the page should state, explicitly, what standard it is
> checking to, and should link to that standard.
AFAIK there exists no useful Javascript standard to which adherence can be
statically checked, save for the syntax, which is based on the ECMA 262
grammar. The checks performed attempts to detect what might be considered
bad coding style or possibly suspicious constructs, which is more or less
the only kind of things you can do short of rewriting an entire JS
interpreter.
> I tested my js-quick.htm and got only one complaint :
>
> ERROR: In file "*stdin*", parse error at line 300, column 7:
> 300 SS = "" ; K = In ; while (K--) SS += S2 // Build padding
>
> Why does that give a parse error?
That fragment by itself parses fine, maybe you could send me the context?
> In my js-date5.htm results :
>
> ERROR: In file "*stdin*", parse error at line 445, column 21:
> 445 D = new Date(D - 36e5*H) // to GMT
>
> Why does that give a parse error?
Because I forgot exponents in float lexemes. Fixed in the source,
you'll have to wait for changes to migrate to the web version.
> And why 445, since that, starting from 1, is line 448.
That's according to your definition of newlines. I guess some of your
lines are not terminated with LFs; maybe you have bits of CR-terminated
code written on a Mac?
--
Berke Durak
MC
MC
"timothytoe" <timot...@gmail.com> wrote in message
news:519d6cb8-116e-42e4...@s19g2000prg.googlegroups.com...
Zmitro Lapcjonak
wrote:
> You can also use Jsure online thru the web interface athttp://jsure.org/
I tryed the web interface (upload and direct input), the responce is:
The change you wanted was rejected.
Maybe you tried to change something you didn't have access to.
--
Zmitro Lapcjonak
Henry
> On Mar 11, 12:45 pm, Henry wrote:
>> <snip>
>> This is a joke, right?
>
> No.
A language checker that does not recognise all of the operators from
the language it purports to check?
>> Apart from not working at all on IE 6 (which is
>> pretty bad),
>
> I'll have that checked. You're talking of the web interface
> I assume?
Didn't I quote the web interface URL just before my comments on it?
>> given the input:-
>
>> var x;
>> x = (x >>> 0);
>> - it produces the output:-
>
>> | ERROR: In file "*stdin*", parse error at line 2, column 9:
>> | 2 x = (x >>> 0);
>
>> - highlighting the third chevron in the unsigned right shift
>> operator. The very least a javascript checker should be expected
>> to do is to recognise all of the operators available in javascript.
>
> Fixed in the source tree. No need to write five paragraphs,
> a simple "it doesn't recognize the unsigned right shift
> operator" would have been enough.
It makes more sense to provide both the input and the output so that
each can be verified by third party observers.
>> The line numbers in the output get way off very quickly
>
> This could be a CR or CR/LF issue.
Unlikely.
> Are you using a mac?
No.
> Do you have any examples?
The ones I tried.
>> and some of
>> the subjects of complaints are very arbitrary, such as
>> ...
>> | WARNING: In file "*stdin*" at line 2, columns 4 to 28: Assigning to
>> argument "ev":
>> | 2 ev = (ev || window.event);
>
> That's why every warning is configurable to suit your coding
> practices.
But should the defaults for the web interface be unsuitable for
general browser scripting tasks?
> The option you're looking for is
> "-assigning-to-args i".
<snip>
I was not looking for anything once I had determined that it the
software was unsuitable for use with javascript (the only reasonable
conclusion once I had determined that it did not understand all
javascript operators).
Dr J R Stockton
Tue, 11 Mar 2008 18:32:01, Berke Durak <obd...@free.fr> posted:
>On Mon, 10 Mar 2008 19:53:52 +0000, Dr J R Stockton wrote:
>
>> In comp.lang.javascript message <b947f147-62e0-4180-897b-df3d44a32453@k1
>> 3g2000hse.googlegroups.com>, Mon, 10 Mar 2008 11:25:24,
>> "berke...@gmail.com" <berke...@gmail.com> posted:
>>>
>>>You can also use Jsure online thru the web interface at http://jsure.org/
>> ISTM also that, when given its own URL, it should not give any errors,
>> rather than a large number (in Opera).
>
>It gives warnings, not errors. To be expected. See the paragraph below on
>conformance.
Users expect verification tools to be perfect, at least by the standards
of the tool in question. If you cannot code the input page to agree
with your default settings, then either your coding is careless or your
defaults are inappropriate.
>> And that orange and pale red are not wisely-chosen colors for that
>> report.
>
>> ISTM that the page should display reasonably in MS IE 6, and that it
>> should do something when its button is pressed. Neither is so.
>
>Maybe, but only if this is due to lack of compliance on our part.
>Otherwise, there is no need to support obsolescent browsers in a tool
>targeted at web developers.
All that your Web page does is provide the user with a choice of input
text controls and a couple of buttons. That can be done in a manner
compatible with all browsers within the last decade or so. There's no
need to try to be clever, and it's unwise to do so unreliably.
While one can expect a professional developer to have access to all of
the latest browsers, it's wrong to assume that such a person always uses
the latest. A professional should check his work on recent major
browsers - and, if he finds a problem, he may well want to use your tool
from that system.
>> ISTM that the page should state, explicitly, what standard it is
>> checking to, and should link to that standard.
>
>AFAIK there exists no useful Javascript standard to which adherence can be
>statically checked, save for the syntax, which is based on the ECMA 262
>grammar.
Then you can refer to ECMA 262, though ISO/IEC 16262 would be better.
> The checks performed attempts to detect what might be considered
>bad coding style or possibly suspicious constructs, which is more or less
>the only kind of things you can do short of rewriting an entire JS
>interpreter.
>
>> I tested my js-quick.htm and got only one complaint :
>>
>> ERROR: In file "*stdin*", parse error at line 300, column 7:
>> 300 SS = "" ; K = In ; while (K--) SS += S2 // Build padding
>>
>> Why does that give a parse error?
>
>That fragment by itself parses fine, maybe you could send me the context?
I have already indicated the URL : /in toto/, it is <URL:http://www.merl
yn.demon.co.uk/js-quick.htm>. But it is not helpful to show a line
which does not contain the error, while stating that it does.
>> In my js-date5.htm results :
>>
>> ERROR: In file "*stdin*", parse error at line 445, column 21:
>> 445 D = new Date(D - 36e5*H) // to GMT
>>
>> Why does that give a parse error?
>
>Because I forgot exponents in float lexemes. Fixed in the source,
>you'll have to wait for changes to migrate to the web version.
ISTM that, when you detect a claimed error, there's probably a
particular position in the line at which that decision was made. Giving
that position should be helpful.
>> And why 445, since that, starting from 1, is line 448.
>
>That's according to your definition of newlines. I guess some of your
>lines are not terminated with LFs; maybe you have bits of CR-terminated
>code written on a Mac?
I checked the value 445 in two independent ways. All of my code is
written in DOS/Windows, with CRLFs. And I have just piped that file
through a process which uses CRLF for all newlines, getting an identical
file (by DOS, fc /b). I've also counted the CRs, the LFs, and the CRLFs
- all 1244. It seems to be your counting that is at fault.
Using File Upload, I get
ERROR: In file "*stdin*", parse error at line 1, column 0:
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
To declare an error at Line 1 Column 0 seems premature.
However, your checker is nicer than W3's in at least one case. It found
no errors in an empty file, whereas W3 pontificated Teutonically about
the title. OTOH, ISTM that "empty file" would be better treated as a
special case, with a specific warning or error.
But it gives "An error occured / An unknown error occured, please check
your input for typos or try again later." on URI <http://www.merlyn.demo
n.co.uk/gravity0.htm> which only the following JavaScript :
<div><input type=button name=Eval value="Eval"
onClick="F.Result.value=eval(F.Code.value)"></div>
Testing just that by direct upload gives
ERROR: In file "*stdin*", parse error at line 1, column 1:
1 <div><input type=button name=Eval value="Eval"
You should run your material through a proper English spelling-checker :
"occured" is wrong.
It accepts direct input of
function f() {
var a
var a
b
}
which is rather odd code.
It's a good idea to read the newsgroup c.l.j and its FAQ. See below.
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk IE6 IE7 FF2 Op9 Sf3
news:comp.lang.javascript FAQ <URL:http://www.jibbering.com/faq/index.html>.
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
John G Harris
wrote:
>On Mon, 10 Mar 2008 19:53:52 +0000, Dr J R Stockton wrote:
<snip>
>> And why 445, since that, starting from 1, is line 448.
>
>That's according to your definition of newlines. I guess some of your
>lines are not terminated with LFs; maybe you have bits of CR-terminated
>code written on a Mac?
JohnS gave the program an HTML file. The HTML standard says that CR,
CRLF, and LF are all equally valid end-of-line symbols. As line endings
are significant in javascript your program should cope with all three.
John
--
John Harris
dhtml
> In comp.lang.javascript message <b947f147-62e0-4180-897b-df3d44a32453@k1
> 3g2000hse.googlegroups.com>, Mon, 10 Mar 2008 11:25:24,
>
>
>
> >You can also use Jsure online thru the web interface athttp://jsure.org/
>
> BTW, it's not entirely happy about the newsgroup FAQ (and there's very
> little active JavaScript in the FAQ) :
>
> WARNING: In file "*stdin*" at line 9, columns 0 to 17: Toplevel binding
> to "hash":
> 9 hash=location.hash;
>
Sounds like a valid warning. Shouldn't that be:
var hash = location.hash;
(var)
> --
> (c) John Stockton, nr London UK. ?...@merlyn.demon.co.uk Turnpike v6.05 MIME.
John G Harris
Stockton wrote:
<snip>
>However, your checker is nicer than W3's in at least one case. It found
>no errors in an empty file, whereas W3 pontificated Teutonically about
>the title.
If a validator that gives the correct answer is Teutonic then hooray for
Teutons.
The shortest possible HTML document is
<title></title>
and its upper case variants. No HTML document can be empty, from which
you can deduce that an empty file is invalid. A working validator must
say so.
>OTOH, ISTM that "empty file" would be better treated as a
>special case, with a specific warning or error.
<snip>
Here though, a complete absence of javascript code is not an error,
neither in an html file nor in a js file. Saying that it's an error
would be wrong.
A warning would seem appropriate, but it would have to be carefully
worded. After all, there's no way the validator can tell if you've sent
the wrong file or sent the right file to the wrong validator.
Also, "empty" needs to be defined carefully. Empty of javascript is not
the same as empty of whitespace chars, or HTML content.
John
--
John Harris
Dr J R Stockton
8924D9443D28E23ED5CD>, Wed, 12 Mar 2008 21:28:01, John G Harris
<jo...@nospam.demon.co.uk> posted:
But CR, CRLF, and LF are not necessarily equally treated by whatever I
use to count the number of lines; so your condition is necessary, but
does not ensure agreement. Those who count lines with an ASR33 and a
ruler marked in sixths of an inch will not detect CR at all.
--
(c) John Stockton, nr London UK. *@merlyn.demon.co.uk/??.Stockton@physics.org
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Correct <= 4-line sig. separator as above, a line precisely "-- " (SoRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SoRFC1036)
Dr J R Stockton
3g2000prf.googlegroups.com>, Thu, 13 Mar 2008 01:26:35, dhtml
<dhtmlk...@gmail.com> posted:
>On Mar 11, 5:01 am, Dr J R Stockton <j...@merlyn.demon.co.uk> wrote:
>> In comp.lang.javascript message <b947f147-62e0-4180-897b-df3d44a32453@k1
>> 3g2000hse.googlegroups.com>, Mon, 10 Mar 2008 11:25:24,
>> "berke.du...@gmail.com" <berke.du...@gmail.com> posted:
>>
>>
>>
>> >You can also use Jsure online thru the web interface athttp://jsure.org/
>>
>> BTW, it's not entirely happy about the newsgroup FAQ (and there's very
>> little active JavaScript in the FAQ) :
>>
>> WARNING: In file "*stdin*" at line 9, columns 0 to 17: Toplevel binding
>> to "hash":
>> 9 hash=location.hash;
>>
>
>Sounds like a valid warning. Shouldn't that be:
>
>var hash = location.hash;
>
>(var)
I did not say that it was or was not valid. But it shows that at least
one of the FAQ writer and Jsure must fall short of true perfection.
>> --
>> (c)
Please do not over-quote - sigs, for example.
--
(c) John Stockton, nr London UK. replyYYWW merlyn demon co uk Turnpike 6.05.
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes precede replies. Snip well. Write clearly. Mail no News.
Dr J R Stockton
8924D9443D28E23ED5CD>, Thu, 13 Mar 2008 15:59:25, John G Harris
<jo...@nospam.demon.co.uk> posted:
>On Wed, 12 Mar 2008 at 17:34:07, in comp.lang.javascript, Dr J R
>Stockton wrote:
>
> <snip>
>>However, your checker is nicer than W3's in at least one case. It found
>>no errors in an empty file, whereas W3 pontificated Teutonically about
>>the title.
>
>If a validator that gives the correct answer is Teutonic then hooray for
>Teutons.
>
>The shortest possible HTML document is
><title></title>
>and its upper case variants. No HTML document can be empty, from which
>you can deduce that an empty file is invalid. A working validator must
>say so.
A sensible validator would point out the real fault, that the file
contains no characters. The lack of Title is a mere detail.
I've seen worse, though; one validator, if given an invalid URL, would
then analyse and report on the "404" page.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
John G Harris
Stockton wrote:
>In comp.lang.javascript message <4iRWCDEh...@J.A830F0FF37FB96852AD0
>8924D9443D28E23ED5CD>, Wed, 12 Mar 2008 21:28:01, John G Harris
><jo...@nospam.demon.co.uk> posted:
>>On Tue, 11 Mar 2008 at 18:32:01, in comp.lang.javascript, Berke Durak
>>wrote:
>>>On Mon, 10 Mar 2008 19:53:52 +0000, Dr J R Stockton wrote:
>>
>> <snip>
>>>> And why 445, since that, starting from 1, is line 448.
>>>
>>>That's according to your definition of newlines. I guess some of your
>>>lines are not terminated with LFs; maybe you have bits of CR-terminated
>>>code written on a Mac?
>>
>>JohnS gave the program an HTML file. The HTML standard says that CR,
>>CRLF, and LF are all equally valid end-of-line symbols. As line endings
>>are significant in javascript your program should cope with all three.
>
>But CR, CRLF, and LF are not necessarily equally treated by whatever I
>use to count the number of lines; so your condition is necessary, but
>does not ensure agreement. Those who count lines with an ASR33 and a
>ruler marked in sixths of an inch will not detect CR at all.
I wasn't worrying about line numbers. I was worrying about a javascript
validator that says
var a = 42 CR alert(a);
has a syntax error when your favourite browser correctly says there's
nothing wrong.
John
--
John Harris
John G Harris
Stockton wrote:
>In comp.lang.javascript message <TvFN2UDd...@J.A830F0FF37FB96852AD0
>8924D9443D28E23ED5CD>, Thu, 13 Mar 2008 15:59:25, John G Harris
><jo...@nospam.demon.co.uk> posted:
<snip>
>>The shortest possible HTML document is
>><title></title>
>>and its upper case variants. No HTML document can be empty, from which
>>you can deduce that an empty file is invalid. A working validator must
>>say so.
>
>A sensible validator would point out the real fault, that the file
>contains no characters. The lack of Title is a mere detail.
<snip>
You haven't thought it through. A file that's empty, a file that
contains nothing but spaces, tabs, and line endings, and a file that
contains lots of text but no tags have the same problem : each lacks the
compulsory title element.
Maybe the user has submitted the wrong file. In that case, saying the
file is invalid will cause the user to notice the real fault. The user
will then submit the right file.
Maybe the user thought the file was valid. In that case, saying the
minimum requirements, namely the presence of a title element, is the
useful thing to do.
Saying something that might not be useful, and then doing it only for
one special case, is bloating the validator for no good reason. This
bloat adds more things to go wrong and adds more test cases to be run at
each update. Both violate the golden rule : Keep It Simple.
John
--
John Harris