The idea of having some permutations resolved JIT and cached sounds great! I would expect more differences than just directionality, but I have no idea how many. What about John's plural example, for instance? That's more than a localized string replacement.
On Tue, Oct 20, 2009 at 10:46 AM, Ray Ryan <[email protected]> wrote: > The 40+ languages situation really is unpleasant, and has lead us to devote > a lot of time to squeezing every last ounce of performance out of the > compiler. We've pitted our desire to let the compiler spend time optimizing > code against the need to get things built in a reasonable amount of time, > and we're in a continual struggle on the "reasonable amount of time" side. > How have we convinced ourselves that a tight binary requires a permutation > per language? Wouldn't a permutation per direction (rtl v.ltr) plus load > time stitching of locale resources work just as well in the browser? It's > not like loading the resources would have to happen via a separate browser > request, they could be blended with the rest of the code by the server at > request time. > I think I just suggested that the cache*html files become a template, with > tokens swizzled for localized strings and data urls post compile, perhaps on > demand. That sounds different than a linker to me--is it? > rjrjr > > On Tue, Oct 20, 2009 at 6:59 AM, John Tamplin <[email protected]> wrote: >> >> On Tue, Oct 20, 2009 at 4:24 AM, Thoka <[email protected]> wrote: >>> >>> The initial problem was due to compile time and permutations. We just >>> launched a GWT application with 43 languages, which generates about >>> 43*6(?) permutations, and to get 43 languages (where each language has >>> about 800 text and 300 configuration properties) entirely correct, >>> this would generate a whole bunch of extra builds and server downtime >>> each time a country wants to change even a very small thing as a >>> misspelling. Perhaps this is not very useful when an application is >>> perfectly in shape, configured and all texts are flawless, but while >>> in developing/staging state it has saved us weeks of development since >>> the customer is now able to internationalize their application "live" >>> at staging/pre-prod state via an I18N-servlet, without the need to >>> translate blindly and wait for the re-build and re-deploy for each >>> batch. >>> >>> Perhaps this is not a feature for the common GWT developer, but as >>> stated, it is very nice to have for larger applications. >> >> I agree the situation you describe is an issue. A few points: >> >> Doing a release build, with all the localizations, should only need to be >> done when you are actually pushing a new build to production. All your work >> can be done with a different module that limits the number of locales (and >> user agents, depending on what sort of work you are doing) during >> development. >> GWT is designed for parallel compilation. If you have a compile cluster, >> you can build all the permutations in parallel so that the overall build >> time is the same as one permutation if you have enough machines. Instead of >> calling the Compiler entry point, you run Precompile on the main node, then >> CompilePerms on each permutation (they can all be run in parallel), and then >> Link after all permutations have finished. If the nodes don't share a >> common filesystem, you have to do the work to copy the precompilation.ser >> file to the permutation nodes and get all the artifacts back from them to >> the main node. You also have to provide some glue for your cluster/build >> system to make this happen, but the basic support is there. Eventually we >> will probably provide more assistance in this area. >> Lex is working on changes to the Link phase which should (in theory) allow >> incremental linking -- you could recompile just the permutation you need to >> change and link it with the results of a previous compile, so if all you did >> was to change the German translations you could just rebuild those >> permutations to get your compiled output. >> >> So, basically I agree that this is an issue but I think the best solution >> is not to throw out compile-time evaluation/optimization but instead to use >> the existing tools for parallel compilation, and for us to continue to >> improve those tools. >> -- >> John A. Tamplin >> Software Engineer (GWT), Google >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
