Here are some notes for our last few meetings. I'm sure a comparison between our notes and the YouTube video [1] would show I missed a few things. :-)
[1] https://www.youtube.com/watch?v=hIgR7-3ZAMc September 4, 2013 Brian: meeting with someone working on Chrome devtools to get up to speed. Goktug: still working on HTMLUnit upgrade; typedarrays not working with HTMLUnit, etc. Goktug: tracking down cycle in stack traces causing infinite loop Roberto: Java 7 enabled for Google GWT users Roberto: thinking about how to save compiler state between compiler passes. We also talked about dependency injection for compiler passes. (Either using Guice or manually wiring.) Goal would be for compiler passes to declare what they need (in the constructor) but to have a uniform way of running compiler passes. Needs more design. Roberto: working on code splitter bug; happening more often due to more usage of draft compiles Matt: upgrading GWT code to use the current dom.Element and not the deprecated user.Element. Maybe remove user.Element after 2.6? Matt: deprecating forwarding methods in DOM classes. Daniel: working on performance testing using V8. Got benchmarks working. Daniel: has a patch to drop IE6/IE7. Need to start by disabling the permutation by default. For external users, maybe let Vaadin handle IE6/7 support? Daniel: looking at linker to download external resources using manifest files. Possibly cache data using filesystem API? Matt: security issue with permanently hijacking an application. Daniel: the way cache.html works in default linker defeats browser caching. Switch to cross-site linker? Daniel: had an idea about parsing JavaScript in a webworker. Needs research. August 28, 2013: Hangouts On Air John: just got modular builds running via build system integration. Due to custom namer, JS is very large - 23-30mb minimum dependencies for gwt-user GWT Gallery output is 50mb total, parses in browser in about a second. Minimum compile time for a smallest possible module is ~1.5 seconds, due to resolving dependencies. There's definitely some room for improvement on that baseline. Most modules i'm seeing are compiling in 3-5 seconds. If you have a module taking longer, you should probably split it up. Recompiling an application with just a single source file change costs you the recompile of the affected module (approximately 3-5 seconds) plus the recompile time of the application root module which currently costs about 23 seconds (due to the execution and recompilation of all of the generators and generator output). A sample app being worked with right now (via build system integration), is recompiling in ~60 seconds monolithically, and recompiling in ~28 seconds separately. Moving most generators execution into their most specific module should reduce the application root compile to just linking. And so should result in a cost of 1-5 seconds for the application root compile. Which would mean a roughly 5-10 second application recompile time for small changes, regardless of overall application size, as long as the application has been modularized. For large applications the output JS size may start to cause a problem. There are several currently unexplored opportunities to shrink this size: use obfuscated namer and store a name map in each module's generated .gwtlib probably a 4x-5x size reduction make the linker smart enough to walk the "import" graph (not control flow graph) from each entry point and write out just the JS for classes that are actually reachable (should be computationally pretty cheap) probably a 1.5x-2x size reduction Ray brought up GWT.create() extensions. Lots of ideas, but no consensus yet. Brian: talked about approaches to Eclipse integration for debugging. Lightweight integration versus full debugger. Chrome debugger extension? Need to make contact with Chrome devtools team. Talked about JSInterface. Talked about 2.6 release. Bhaskar: want a volunteer from the open source community. Ray: we should write up what's expected. August 21, 2013: Hangout On Air next week - announcement soon. GWT.create() improvements - test case for external development John: Modular compilation: circular dependencies in Blaze Roberto: need JDT bug fix for Java 7 upgrade Roberto: started on CodeSplitter v3; design doc and CL in progress Daniel: has a v8 patch to add sourcemaps for profiling code Brian: looking into using chromedevtools Eclipse plugin with Super Dev Mode Matt: wrote an autogarden tool Talked about a best practices document for Google GWT projects. Maybe a more elaborate skeleton app? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
