Hi Thomas, Thanks for a quick turnaround on the bug.
> Mh, I'm afraid no. But roughly speaking, the generator parses the code > of a class file, and evaluation both compile hints (#require, #use) as > well as references to other class in the class definition map. > References found in methods are considered run-time dependencies, > references found in member initializers and 'defer' sections are > load-time deps. So basically I can parse the code looking for all qx.* identifiers, mix that with the classes defined in #requre and #use, and that would be the dependencies? The real problem beside the parsing bug is that generator.py-based build system is not really a good match for our platform (my company works with .NET). Our current project also has a JavaScript parser and pretty-printer/minifier. Do you think it would be feasible to quickly hack a separate dependency analyzer and avoid generator.py altogether? If it's a matter of discovering qx.* identifiers and working out the partial order, it does sound feasible. > :-) Our target language is definitely the current Ecma standard that you > named. But AFAIK there is no proof procedure available that shows that a > given parser will parse any possible word of a given grammar correctly, > so there is always room for surprise :-). JavaScript grammar is especially wicked. I know our current parser certainly chokes on some examples (involving semicolon insertion and object literal/block ambiguity). You might want to look at this (we are also considering giving it a try, ANTLR has a .NET backend): http://www.antlr.org/api/Python/index.html They have an ECMA-262/3ed. grammar which looks promising. As for testing, the Mozilla JS test suite claims to test the parser and lexer. You may want to try running Qooxdoo parser on those tests: http://www.mozilla.org/js/tests/library.html > Thanks, that was very helpful to have a real code example. It looks as > though this code was generated?! Yes, from a .NET ML dialect called F#. We are working on a GWT-like platform (single-source F#, compiled to JS and ASP.NET), and Qooxdoo looks promising as a widget toolkit. As I have not gotten to the optimizer yet, the code contains some redundant closures and bindings - turns out to be a helpful thing to test parsers. Thanks, --A On Thu, Jul 16, 2009 at 7:34 PM, thron7<[email protected]> wrote: > Hi Anton, > > >> I have the qooxdoo generator.py complain of syntax errors on a valid >> ECMA-262 3rd edition JS file. >> > > It seems your code hits various parsing bugs in the generator. I've > opened an initial bug > (http://bugzilla.qooxdoo.org/show_bug.cgi?id=2599) and attached your > code, maybe we will split off bugs for the individual issues later. You > can subscribe to this bug to keep updated. > >> * how do I turn the parser off? I still want generate.py to resolve >> the dependencies. >> > > Unfortunately, that's not possible. Dependency analysis relies on code > parsing (for, hopefully, obvious reasons). > >> * alternatively, is there a document describing how generate.py >> resolves the dependencies? >> > > Mh, I'm afraid no. But roughly speaking, the generator parses the code > of a class file, and evaluation both compile hints (#require, #use) as > well as references to other class in the class definition map. > References found in methods are considered run-time dependencies, > references found in member initializers and 'defer' sections are > load-time deps. > >> * which version of JavaScript does generator.py parse correctly? >> > > :-) Our target language is definitely the current Ecma standard that you > named. But AFAIK there is no proof procedure available that shows that a > given parser will parse any possible word of a given grammar correctly, > so there is always room for surprise :-). > >> The offending code is here: http://woetiawetaw.pastebin.com/m435aff59 >> > > Thanks, that was very helpful to have a real code example. It looks as > though this code was generated?! > >> This is what I get: >> >> !!! Expected expression but found token/RP: ')'. >> file:IntelliFactory.Qx.Demo.Application, line:24, column:18 >> > > What I've seen so far, the generator chokes on your use of the "void" > operator, and the comma operator in expressions, but there might be > more. The only work-around would be to avoid these constructs for the > time being. > > Cheers, > Thomas > > >> >> >> >> > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > -- Kind Regards, Anton Tayanovskyy ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
