Comments on: What About JavaScript In Dehydra? http://blog.mozilla.com/tglek/2007/04/04/what-about-javascript-in-dehydra/ Just another Blog.mozilla.com weblog Wed, 11 Nov 2009 17:56:44 -0800 http://wordpress.org/?v=2.8.6 hourly 1 By: Brendan Eich http://blog.mozilla.com/tglek/2007/04/04/what-about-javascript-in-dehydra/comment-page-1/#comment-1233 Brendan Eich Tue, 08 May 2007 00:57:29 +0000 http://blog.mozilla.com/tglek/2007/04/04/what-about-javascript-in-dehydra/#comment-1233 Oh, we definitely want an "ElsaXR" that actually parses. Platform-specific #ifdefs pose a problem, of course, but it's solvable. Taras probably knows the status of this gleam in our eye better and can say more. /be Oh, we definitely want an “ElsaXR” that actually parses. Platform-specific #ifdefs pose a problem, of course, but it’s solvable. Taras probably knows the status of this gleam in our eye better and can say more.

/be

]]> By: Fredrik http://blog.mozilla.com/tglek/2007/04/04/what-about-javascript-in-dehydra/comment-page-1/#comment-986 Fredrik Thu, 05 Apr 2007 11:47:13 +0000 http://blog.mozilla.com/tglek/2007/04/04/what-about-javascript-in-dehydra/#comment-986 Very interesting. It's nice to see your progress reports on this. I've had a similar idea for quite some time, basically a LXR that understands the code it's indexing. Parsing instead of just trying to grep function names or identifiers heuristically. I have a half-assed, not-at-all-finished beginning of a mockup (hehe) for Python, using its built-in parser. Just to see how tricky it is, and how to extract interesting meta-data. Other thoughts are basically a search interface with CSS-like selectors. If you want to see all integer variables in all functions that has "tree" in the function name, you can get that. You could also add things like "trace identifier" (e.g. a variable) and backtrace through what calls can end up touching it. Of course, for duck-typed languages, things change a bit. But the general idea would extend to pretty much all high-level languages. Lucene could work as the data backend, since it's fast and cross-platform. Analysis in Java is probably not a good idea, though. I've pondered using Lisp for as much as possible, or native tools for each language (Elsa for C++, since C++ is a horrendous language to parse) and a common intermediate format which is then massaged and fed to a Lucene index. Anyway, sorry for the rant. And good luck on further progress. Very interesting. It’s nice to see your progress reports on this. I’ve had a similar idea for quite some time, basically a LXR that understands the code it’s indexing. Parsing instead of just trying to grep function names or identifiers heuristically. I have a half-assed, not-at-all-finished beginning of a mockup (hehe) for Python, using its built-in parser. Just to see how tricky it is, and how to extract interesting meta-data.

Other thoughts are basically a search interface with CSS-like selectors. If you want to see all integer variables in all functions that has “tree” in the function name, you can get that. You could also add things like “trace identifier” (e.g. a variable) and backtrace through what calls can end up touching it.

Of course, for duck-typed languages, things change a bit. But the general idea would extend to pretty much all high-level languages. Lucene could work as the data backend, since it’s fast and cross-platform. Analysis in Java is probably not a good idea, though. I’ve pondered using Lisp for as much as possible, or native tools for each language (Elsa for C++, since C++ is a horrendous language to parse) and a common intermediate format which is then massaged and fed to a Lucene index.

Anyway, sorry for the rant. And good luck on further progress.

]]>