Re: Auttomated tools

Dror Matalon <[email protected]> Tue, 7 Dec 2004 01:01:31 -0800
Newsgroups gmane.comp.windows.devel.netwindows
Message-ID <[email protected]>
Alex,

This is good news. I've experimented with doxygen but haven't used it
heavily yet. I can't say I'm too surprised that it has some problems
with javascript. On the other hand it has quite a few nice features out of
the box that maybe the solution is to figure out to improve the parser
that is uses. Using Ant and XSLT certainly sounds like a reasonable
solution, although it requires some expertise in Java and Ant (not
really a problem for me). It'd be interesting to see once you're done
with your Rhino hack which poison works better :-).

As far as Mark's perl script, it certainly sounds like it's a step in
the right direction. It finds incompatibilities between function calls
I would also like to be able to detect any variables that have not
been explicitly declared. It seems like one would actually need to hack
Rhino to do that. I peeked at it a bit, but it doesn't seem to use a
grammar which makes it harder to figure out. If I find some time, I'll
try and see if I can make it flag vars that are not declared.

Seems like you guys are thinking about all of this which sounds really
good.

Regards,

Dror


On Mon, Dec 06, 2004 at 04:44:24PM -0800, Alex Russell wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello Dror,
> 
> On Monday 06 December 2004 1:41 pm, Dror Matalon wrote:
> > Hi,
> >
> > Why does netWindows use its own documentation module rather than
> > using doxygen?
> 
> 'cause Doxygen requires significant cludges in order to be made to 
> work with JavaScript, whereas we can more directly model the way 
> things work in JS via DocBook. Mark Anderson went the doxygen route 
> with Burst, and I'm not sure I like what it does to the code. With 
> that in mind, we aren't doing our "own" doc system, we are 
> customizing a stock DocBook DTD and XSLT setup, and automating 
> generation of that documentation out of source code via Ant. If you'd 
> like help getting set up with the documentation portion of the build 
> system, let me know.
> 
> On a related note, I'm working on a hack to Rhino which will output 
> the documentation stubs that both the DocBook and Doxygen routes 
> still require. At that point, you should be able to pick your poison 
> via XSLT to a great extent.
> 
> > Also, has there been any attempts to use a javascript shell to
> > find/catch errors in the code server side? Seems like automated
> > scripts using Rhino or other javascript shells could catch syntax,
> > and possibly other errors.
> 
> Short answer: yes, but it hasn't made it into the build system. Long 
> answer: Mark Anderson (a NW comitter) has built a toolkit 
> (http://burstproject.org) which provides most of these tools. The 
> problematic portions of NW testing have to do with browser-specific 
> behavior, of which there are many. MDA's answer was to emulate a 
> broad swath of this and build a unit-testing harness that works with 
> his browser-emulation setup. This isn't adopted by NW because of a 
> reliance on Perl.
> 
> > Ideally, there would even be a flag that would be equivalent to
> > perl's use strict, or a 'C' lint type of check to find possible
> > errors. I know about
> > "http://www.crockford.com/javascript/jslint.html
> > but somehow doubt that a script that doesn't know about the
> > javascript syntax could do a through job.
> 
> Mark Anderson has also recently put togeather a JS "linker" which does 
> almost exactly this, and in running it against netWindows has exposed 
> several strictness warnings which I've tried to clean up. So from 
> that standpoint, it's another "yes, we have it, but it's not in CVS 
> or build.xml since it relies on Perl".
> 
> > This is not netWindow specific, but as I look at the code more and
> > more, it seems like it's a necessity for a project this large.
> 
> I've been working on a new project (dojotoolkit.org) which implements 
> all of these things from the get-go, and I agree that it's helpful. 
> Back-porting much of this for netWindows isn't a huge priority right 
> now, though, but we'll run this stuff manually from time to time to 
> make sure we're sane.
> 
> Not a great answer for you, but hopefully it gives you a lay of the 
> land.
> 
> Regards
> 
> - -- 
> Alex Russell
> [email protected]   BD10 7AFC 87F6 63F9 1691 83FA 9884 3A15 AFC9 61B7
> [email protected] F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (Darwin)
> 
> iD8DBQFBtPzooV0dQ6uSmkYRAh5fAKCnVJbyWxZ51e/KXUp6at5MJEFidQCfdSHM
> nQKJkdu7iw+Y8dPtn11dOzo=
> =r61Z
> -----END PGP SIGNATURE-----
> 

-- 
Dror Matalon
Zapatec Inc 
1700 MLK Way
Berkeley, CA 94709
http://www.zapatec.com

_______________________________________________
The netWindows developers list: [email protected]
http://netwindows.org/mailman/listinfo/devel_netwindows.org