> 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. >
Yes, that's the basic idea. If you want to look at the code, look at tool/pylib/generator/code/DependencyLoader.py:_analyzeClassDepsNode(). Look for the line "if node.type == "variable":", that's where the central code starts. Our code is heavily based on our AST, though, so that might make it difficult to understand. For the partial order you can restrict yourself to references outside method bodies. But even our current dependency analyser doesn't get at all dependencies, e.g. static method calls to initialize class members are not analysed recursively (s. http://bugzilla.qooxdoo.org/show_bug.cgi?id=1455). If you come up with a working solution, and are free to disclose it, I would be very interested to see it. > 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. > Thanks for the pointer, I'll have a look at this. > 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 > Good point. > Yes, from a .NET ML dialect called F#. Lucky you :). I know F# only by name, but looked a bit at Haskell and OCaml. > 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. > That sounds great. It seems an increasingly popular idea to "draw in" an API into a familiar environment, so people don't have to code JS. Besides GWT, there are two other approaches I'm familiar with that do this for Java, both using qooxdoo as their "rendering layer". One is the Eclipse RAP project http://eclipse.org/rap, the other QWT http://qooxdoo.org/contrib/project/qwt (both are on qooxdoo 0.7, though). It might be interesting to check their code if you look for inspiration on how to use qooxdoo this way. Keep us posted. 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
