Re: [gwt-contrib] Re: GWT 2.7.0-RC1 is available
Release notes are here: http://www.gwtproject.org/release-notes.html#Release_Notes_2_7_0_RC1 -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT_uQFBC4AxBZSLdrmCixZH8b0VWNfsE1PU%3DWzwdW3MdNA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Blocking RC1: Fold gwt-codeserver into gwt-dev
It looks like the gwt-codeserver jar will still exist, but the same classes will also be in gwt-dev.jar. So it's ugly but should be backward compatible? - Brian -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT9RgArmAq5W2PQJSQvzhp-9HKPTtAX7ypQVRZBGPU159g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Blocking RC1: Fold gwt-codeserver into gwt-dev
Yes, merging the jars should be fine as a short-term fix. Codeserver should be built as a separate library to enforce that there are no circular dependencies. (We already have one for DevMode -superDevMode but that should be fixed by splitting out DevMode; it doesn't belong in the same library as the compiler.) Long term, we will also want to split gwt-user into multiple jars. It seems like we should either give plugins a way to set up the classpath properly without hard-coding exactly which jars to use, or else plan on building the traditional all-in-one jars when creating the distribution. On Tue Oct 28 2014 at 12:03:25 PM 'Daniel Kurka' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: I think moving sources right now is too risky and too much work we should just merge the jars in dist. On Tue, Oct 28, 2014 at 8:02 PM, Thomas Broyer t.bro...@gmail.com wrote: Fine for me. Do you intend to move the sources or just merge the JARs during dist-dev/dist? -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/2649c79a-bc32-472e-9410-81401fe73de1%40googlegroups.com . For more options, visit https://groups.google.com/d/optout. -- Google Germany GmbH *Dienerstr. 12* *80331 München* Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Katherine Stephens -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujiq25ZHfMsk4cDrnGNE54Wfhvv%2BNEB0YSSZenxyNEv-5Jw%40mail.gmail.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujiq25ZHfMsk4cDrnGNE54Wfhvv%2BNEB0YSSZenxyNEv-5Jw%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT90OfBtkUfSpwpb4L6jQkbwNAyH-52Yrgeqvpc9wYMk1w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: GWT 2.7 release plan
I think this is okay as long as it doesn't cause tests to fail. Elemental is quite separate from everything else so it seems low risk. Daniel? On Thu, Oct 9, 2014 at 8:57 AM, Leif Åstrand legi...@gmail.com wrote: Lots of Elemental patches have been merged in the last few days, but we do still have a short list that would be nice to get included. https://gwt-review.googlesource.com/#/c/9098/ https://gwt-review.googlesource.com/#/c/9099/ https://gwt-review.googlesource.com/#/c/9095/ The code appears to be in good shape, so it only remains for someone with appropriate authority to decide whether the changes are wanted. On Thursday, 9 October 2014 16:25:37 UTC+3, Daniel Kurka wrote: We are making steady progress towards GWT 2.7. At this point we are not accepting any new patches, but we still have a list of issues that we would like to include in the upcoming release. This is no guarantee that all of them are going to make it but we are trying our best. Also we are holding off committing any risky patches to master until we have cut the GWT 2.7 release branch. I'll ping back GWT contributors once we have done that. Please do not commit any patches that do not need to go in. - Issue 8762 https://code.google.com/p/google-web-toolkit/issues/detail?id=8762: Migration to android.json from org.json not being complete (Current patch). Deploy a com.google.gwt.org.json version based of android that the GWT SDK can depend on and update the pom of the SDK to use it. Include a warning in the release notes about small the very small incompatibilities between the two. - Issue 8613 https://code.google.com/p/google-web-toolkit/issues/detail?id=8613: Bug fix for ValuePicker - Issue 8619 https://code.google.com/p/google-web-toolkit/issues/detail?id=8619: Super dev mode can fail to start on windows if previous dirs are still locked. SDM will skip deletion of dirs on windows if it fails and emit a warning. (skybrian) - Issue 8716 https://code.google.com/p/google-web-toolkit/issues/detail?id=8716: Package names can collide with class names on case insensitive file system. John will come up with a fix for GWT 2.7 if it is not to hard to do (stalcup). - Issue 8938 https://code.google.com/p/google-web-toolkit/issues/detail?id=8938: GWT RPC base url is not set correctly for all cases in SDM recompiles. dankurka will update the implementation to include a full computeScriptBase implementation. - GWT RPC policy files should be written to -launcherDir so that the normal server can use them easily (skybrian) - verify sample apps are actually compiling in SDM (since it is now default) (dankurka) - remove generation of SDM targets in samples since it is now default (skybrian) - John found two small issues in incremental. These need to be fixed for GWT 2.7 (stalcup rluble) - Exception links in the chrome dev tools are not clickable (goktug) - Issue 4236 https://code.google.com/p/google-web-toolkit/issues/detail?id=4236: NavigatableMap: We would like to include this in GWT 2.7, but it needs more testing. Ask Andrei to copy all apache testcases and make them work, then we include it in GWT 2.7 (goktug) - Removing IE6 references in the code base (niloc) -Daniel -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/b8d11950-f32a-466a-b748-036622710c70%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/b8d11950-f32a-466a-b748-036622710c70%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT9X18-yHWp370JRRnfndkfuW1PRoPZyjJgSi-xgRis3Aw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] GWT 2.7 release plan
- Make sure sample apps work with DevMode -superdevmode - I think we're waiting on a patch to CLDR 25 On Wed, Oct 1, 2014 at 12:15 PM, 'Daniel Kurka' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: Hi all, we just settled on a GWT 2.7 release plan: - We *code freeze* on *October 7th* and branch for GWT 2.7. - As soon as we have the *remaining patches submitted*, we put out a beta1 build, this should be no later than *October 7th.* - Putting out a *beta1 externally* allows us to collect feedback on the new super dev mode integration externally as well. - We are going to *flip incremental to default* tomorrow and *wait for 1-2 weeks* for google internal feedback, if there is no serious issues we are going to *put out RC1* - GWT 2.7 will still be compatible with Java 6. Patches / Fixes that need to go in: - Recompile on reload: https://gwt-review.googlesource.com/#/c/9323/ (dankurka) - Sending the wrong permutation to the client in SDM, if no files have changed (dankurka). - Investigate why some people are seeing errors with incremental not restricting to one permutation (dankurka). - Public directories are not copied o the war directory when using SDM (skybrian). - Restore Java 6 compatibility (skybrian). - Document limitations of JsonUtils.safeEval and discourage usage (goktug) (promote Json.parse) Patches that are nice to have: - Improve exception logging in SDM (goktug). *If you have any outstanding patches that you thing need to go into GWT 2.7, please bring them to our attention, by replying to this thread or adding me as a reviewer on Gerrit and setting the topic to GWT2.7.* -Daniel -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujirrw0BL1yfX7nxLbH-yVLEofbQM%2BBn-ZtgmriuW56SMNQ%40mail.gmail.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujirrw0BL1yfX7nxLbH-yVLEofbQM%2BBn-ZtgmriuW56SMNQ%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT8y2fE4WQqFeXiJCVwTwD6XbdWiKrR3fH28qzMLvk0Uvg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: GWT 2.7 release plan
It's experimental and hidden behind a flag, but it's there. On Wed, Oct 1, 2014 at 6:20 PM, Cristian Rinaldi csrina...@gmail.com wrote: - JsInterop Preview is part of the release? El miércoles, 1 de octubre de 2014 16:15:26 UTC-3, Daniel Kurka escribió: Hi all, we just settled on a GWT 2.7 release plan: - We *code freeze* on *October 7th* and branch for GWT 2.7. - As soon as we have the *remaining patches submitted*, we put out a beta1 build, this should be no later than *October 7th.* - Putting out a *beta1 externally* allows us to collect feedback on the new super dev mode integration externally as well. - We are going to *flip incremental to default* tomorrow and *wait for 1-2 weeks* for google internal feedback, if there is no serious issues we are going to *put out RC1* - GWT 2.7 will still be compatible with Java 6. Patches / Fixes that need to go in: - Recompile on reload: https://gwt-review.googlesource.com/#/c/9323/ ( dankurka) - Sending the wrong permutation to the client in SDM, if no files have changed (dankurka). - Investigate why some people are seeing errors with incremental not restricting to one permutation (dankurka). - Public directories are not copied o the war directory when using SDM (skybrian). - Restore Java 6 compatibility (skybrian). - Document limitations of JsonUtils.safeEval and discourage usage (goktug) (promote Json.parse) Patches that are nice to have: - Improve exception logging in SDM (goktug). *If you have any outstanding patches that you thing need to go into GWT 2.7, please bring them to our attention, by replying to this thread or adding me as a reviewer on Gerrit and setting the topic to GWT2.7.* -Daniel -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/1d5a4369-e03d-47ba-b8dd-5031e5460751%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/1d5a4369-e03d-47ba-b8dd-5031e5460751%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT-M5mAXmj5Ox8iQihjzFFinLM%2Bc57tmdD1JGwEMxKJHAw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Trying SDM with Java 1.6 Issue gotcha
Oops. This particular bug shouldn't be hard to fix. On Tue, Sep 30, 2014 at 10:50 AM, Brandon Donnelson branflake2...@gmail.com wrote: Just a thought, the folks that forget to update Java 1.6 to Java 1.7 in their project and run SDM (super dev mode) will have issues. A warning could be useful for those trying to run SDM with Java 1.6 otherwise the warning is an exception of no significance. I'm tempted to ask the IDES to add one, but this will be slow to add. :) For those who find this, upgrade to Java 1.7. When running Java 1.6 with SDM this is what is occuring at the moment Runing CodeServer with parameters: [-noprecompile, -port, 9876, -sourceLevel, 1.6, -bindAddress, 127.0.0.1, -logLevel, INFO, com.sencha.gxt.test.TestRunner] Super Dev Mode starting up workDir: /var/folders/x8/9wz7qtw96t7grkdyjw1l61p4gn/T/gwt-codeserver-4814108566559817583.tmp 2014-09-30 10:35:27.314 java[1117:d07] [Java CocoaComponent compatibility mode]: Enabled 2014-09-30 10:35:27.314 java[1117:d07] [Java CocoaComponent compatibility mode]: Setting timeout for SWT to 0.10 Loading Java files in com.sencha.gxt.test.TestRunner. To compile the module 'testrunner' , visit: http://127.0.0.1:9876/recompile/testrunner?user.agent=safari Ignored 89 units with compilation errors in first pass. Compile with -strict or with -logLevel set to TRACE or DEBUG to see all errors. java.lang.NoSuchMethodError: java.io.File.toPath()Ljava/nio/file/Path; at com.google.gwt.dev.codeserver.Recompiler.setUpCompileDir(Recompiler.java:233) at com.google.gwt.dev.codeserver.Recompiler.initWithoutPrecompile(Recompiler.java:194) at com.google.gwt.dev.codeserver.Outbox.maybePrecompile(Outbox.java:81) at com.google.gwt.dev.codeserver.Outbox.init(Outbox.java:60) at com.google.gwt.dev.codeserver.CodeServer.makeOutboxes(CodeServer.java:155) at com.google.gwt.dev.codeserver.CodeServer.start(CodeServer.java:119) at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:91) at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:50) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.google.gwt.dev.shell.SuperDevListener$1.run(SuperDevListener.java:125) [WARN] Server class 'com.google.gwt.dev.shell.jetty.JDBCUnloader' could not be found in the web app, but was found on the system classpath [WARN] Adding classpath entry 'file:/Users/branflake2267/.m2/repository/com/google/gwt/gwt-dev/2.7.0-SNAPSHOT/gwt-dev-2.7.0-SNAPSHOT.jar' to the web app classpath for this session -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/f6f5cf77-4a0a-4adc-be21-36356d281562%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/f6f5cf77-4a0a-4adc-be21-36356d281562%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT_4QqW%3Dn8JAZQJeK%3DUeFZ%2B9GyhTiGND-h_JUTTzrFY7qQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Trying SDM with Java 1.6 Issue gotcha
Actually, that particular stack trace should be fixed by this uncommitted patch: https://gwt-review.googlesource.com/#/c/9361/ However, I haven't tested it on Java 1.6. On Tue, Sep 30, 2014 at 11:48 AM, Brian Slesinsky skybr...@google.com wrote: Oops. This particular bug shouldn't be hard to fix. On Tue, Sep 30, 2014 at 10:50 AM, Brandon Donnelson branflake2...@gmail.com wrote: Just a thought, the folks that forget to update Java 1.6 to Java 1.7 in their project and run SDM (super dev mode) will have issues. A warning could be useful for those trying to run SDM with Java 1.6 otherwise the warning is an exception of no significance. I'm tempted to ask the IDES to add one, but this will be slow to add. :) For those who find this, upgrade to Java 1.7. When running Java 1.6 with SDM this is what is occuring at the moment Runing CodeServer with parameters: [-noprecompile, -port, 9876, -sourceLevel, 1.6, -bindAddress, 127.0.0.1, -logLevel, INFO, com.sencha.gxt.test.TestRunner] Super Dev Mode starting up workDir: /var/folders/x8/9wz7qtw96t7grkdyjw1l61p4gn/T/gwt-codeserver-4814108566559817583.tmp 2014-09-30 10:35:27.314 java[1117:d07] [Java CocoaComponent compatibility mode]: Enabled 2014-09-30 10:35:27.314 java[1117:d07] [Java CocoaComponent compatibility mode]: Setting timeout for SWT to 0.10 Loading Java files in com.sencha.gxt.test.TestRunner. To compile the module 'testrunner' , visit: http://127.0.0.1:9876/recompile/testrunner?user.agent=safari Ignored 89 units with compilation errors in first pass. Compile with -strict or with -logLevel set to TRACE or DEBUG to see all errors. java.lang.NoSuchMethodError: java.io.File.toPath()Ljava/nio/file/Path; at com.google.gwt.dev.codeserver.Recompiler.setUpCompileDir(Recompiler.java:233) at com.google.gwt.dev.codeserver.Recompiler.initWithoutPrecompile(Recompiler.java:194) at com.google.gwt.dev.codeserver.Outbox.maybePrecompile(Outbox.java:81) at com.google.gwt.dev.codeserver.Outbox.init(Outbox.java:60) at com.google.gwt.dev.codeserver.CodeServer.makeOutboxes(CodeServer.java:155) at com.google.gwt.dev.codeserver.CodeServer.start(CodeServer.java:119) at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:91) at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:50) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.google.gwt.dev.shell.SuperDevListener$1.run(SuperDevListener.java:125) [WARN] Server class 'com.google.gwt.dev.shell.jetty.JDBCUnloader' could not be found in the web app, but was found on the system classpath [WARN] Adding classpath entry 'file:/Users/branflake2267/.m2/repository/com/google/gwt/gwt-dev/2.7.0-SNAPSHOT/gwt-dev-2.7.0-SNAPSHOT.jar' to the web app classpath for this session -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/f6f5cf77-4a0a-4adc-be21-36356d281562%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/f6f5cf77-4a0a-4adc-be21-36356d281562%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT_SEMb9n7m%3DAV%2B4xTXPoXcQ_XyfhwYxMBuxthj%3Dfo6s3w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: SDM -XcompilePerFile: initial feedback
This sounds like it might be a deadlock. Could you jstack to get a thread dump of the running process? It should tell us where it's stuck. On Tue, Sep 9, 2014 at 8:42 AM, Jens jens.nehlme...@gmail.com wrote: recentish ones are: 267ad5efd00aae9b0f69eca793891e9fdad28e45 Opts compilePerFile into noPrecompile to avoid 1 permutation. a43aa788cc2b78904c1bf6f0de9b8a1ebe78a6d2 Fixes cascaded generator invalidation for inner classes. 9da4d05b62d7d3cb48ccd03de7b4ad676e2318bd Makes SDM+perFileCompile correctly handle switching browsers. 7365570209426063bbc7fa4745e0b422e4fb4850 Marks types generated by invalidated generators as modified. My colleague used a build that only contained Marks types generated by invalidated generators as modified. . We keep an eye on it if we still get random GIN / UiBinder issues with HEAD. A bit more information about the issue that SDM compilation does not complete for one of my colleagues: - Issue happens with HEAD as well as build from 1st Sep. - Issue only happens if -noprecompile is used (which is now standard with HEAD but wasn't with the build of 1st Sep.) - On my machine I get a warning about certain css files being loaded from class path. This happens between the log output Compiling module ... and Compiling 1 permutation. My colleague does not see these warnings and he only sees the output Compiling module ... which takes forever. So either the InlineClientBundleGenerator never started or takes forever. Otherwise he should have seen the same warnings. - It is not an endless loop because CPU usage drops down to 0% after a minute or so. - A small example app on my colleagues machine works without issues. So SDM is not totally broken on his machine. Only our main app does not work for him. - For any reason it is reproducible on his machine, but so far it is impossible to reproduce on mine. Maybe we find some time tomorrow for some real debugging of CodeServer. -- J. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT969OdkbAm1LK9fM6oOJsPfkrRsjJdSFqRpRmJ2xi6zOg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: SDM -XcompilePerFile: initial feedback
On Mon, Sep 8, 2014 at 3:00 PM, Jens jens.nehlme...@gmail.com wrote: And a last question just popped up again: Is there any way to force embedded Jetty of CodeServer to not print out request logs at DEBUG level? Kind of annoying when all these progress requests show up between GWT logs. i don't know, +skybrian Maybe by configuring java.util.Logger? What does the message look like? (I assume you're passing -logLevel DEBUG to CodeServer? If so I haven't used DEBUG level.) - Brian -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT86KXXZUEWvgVLMUpXeEBeBHW23hdbVV72qto_baojAEQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] JsInterop Advance
I'm eager to start using Java 8 too, but I think we should wait until we
have Java 8 committed (behind a flag) before having the discussion about
whether to require it for anything. As we've found with incremental
compile, sometimes we end up changing direction a bit to reach our goal, so
there's not much point in having policy discussions before the mechanism is
there.
On Thu, Aug 21, 2014 at 9:41 AM, 'Ray Cromwell' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
I think the IDL-DOM generation stuff will be the easy part since the API
is driven by the IDL. The more tricky (likely to bikeshed) stuff I think is
modeling all of the ES5 APIs that back everything. e.g. JsObject, JsArray,
etc.
I somewhat like the old Elemental interfaces (ArrayOf, MapFromStringTo...)
at a high level for allowing shared code to continue to work, but at a
lower level, we need basic interfaces that let you write anything you could
write in JS, like
JsObject.hasOwnProperty(), JsObject.keys(), JsObject.defineProperty(), etc
My goal would be to minimize the need to drop to JS snippets to as small
as possible. But we won't be able to do it perfectly (e.g. dealing with
statics and overloads), and so the workarounds will be where the debate is.
:)
On Thu, Aug 21, 2014 at 9:33 AM, 'Goktug Gokdogan' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
On Thu, Aug 21, 2014 at 5:29 AM, Cristian Rinaldi csrina...@gmail.com
wrote:
Thanks +Goktug Gokdogan for response.
APT is very good option and java 8 support for GWT 3.0 would be a
amazing thing.
You have a planning for Elemental 2.0 or initial documentation to share,
to how you plan address the desing?
Nothing planned yet other than the plan to work on it :) My anticipation
is. initially we will auto generate JsTyped DOM, deal with problems and
incrementally improve it.
El miércoles, 20 de agosto de 2014 16:38:31 UTC-3, Goktug Gokdogan
escribió:
On Wed, Aug 20, 2014 at 6:17 AM, Cristian Rinaldi csri...@gmail.com
wrote:
Community:
I'm playing with JsInterop , and I have two questions:
1) Are you planning to try the static methods of JS objects, such
as Object, Promise, etc.?
There will be some static helpers provided from the SDK. I originally
started the JSNI 2.0 document but it is basically waiting for me to start
on Elemental 2.0 and accumulate more experience to turn it into something
more concrete.
2) How do when an instance is mapped to an existing Object, eg
Promise, has a constructor with parameters?
Actually I have new ideas on this derived from how some other APTs work.
I need to update the JsInterop doc but these are the options that I'm
thinking right now:
*Option 1 (works better for extending):*
@JsType(prototype = Promise)public interface Promise {
/* Protoype_Promise is an autogenerated package visible class */
public static class Prototype extends Protoype_Promise {
public Prototype(Function... functions) {
super(functions);
}
}
void then(Function f);
void cath(Function f);
}
*Option 2 (works better for general use):*
@JsType(prototype = Promise)public interface Promise {
/* Protoype_Promise is an autogenerated package visible class */
public static Promise create(Function... functions) {
return new Protoype_Promise(functions);
}
void then(Function f);
void cath(Function f);
}
*Of course one can do both:*
@JsType(prototype = Promise)public interface Promise {
public static class Prototype extends Protoype_Promise {
public Prototype(Function... functions) {
super(functions);
}
}
public static Promise create(Function... functions) {
return new Prototype(functions);
}
void then(Function f);
void cath(Function f);
}
Currently to resolve this 1) I created the following class
Factory: JS
https://github.com/workingflows/gwt-jscore/blob/master/src/main/java/com/workingflows/js/jscore/client/factory/JS.java
But the interfaces define a contract at the level instance of a
class or object, this way of doing things, I do not know if it is
semantically correct.
To solve 2) there are not many options:
Create a Factory that returns an instance of the object, because
it has no meaning, only to make the new, implement the interface, because
the compiler already does.
There is some progress in this?
I saw in one of the post a proposal to do something like this:
Promise Promise.Prototype p = new (new Function ., new
Function );
Where Promise, is the interface defined with prototype =
Promise.
@JsType(isNative = true, prototype = Promise)
public interface Promise {
void then(Function f);
void cath(Function f);
}
Here 'access to jsCore project:
https://github.com/workingflows/gwt-jscore/
Re: [gwt-contrib] Re: Dropping IE8 support in useragent-less GWT
It would make sense in principle but we don't know anyone who wants to target older browsers without also using permutations. On Tue, Jul 15, 2014 at 3:55 AM, Jens jens.nehlme...@gmail.com wrote: I believe Google builds applications that use Elemental and/or JsInterop, so they don't use c.g.g.dom.DOM or any other thing that inherits UserAgent. Goktug also pointed out earlier in this thread cross-compiled apps where the UI is built with Closure Library. I suspect this might be the case of Google Drive (Spreadsheets) where GWT is only used to compile to JS those bits of Java that are shared with the server, Android app and iOS app (through J2ObjC); from what I understood, in Spreadsheets that would be the code necessary to parse and evaluate formulas. Thanks for the examples. Such cross compiled apps probably doesn't have the concept of permutations but they maybe also want to support older browsers. Wouldn't it make sense then to have something like Core.gwt.xml which is strictly modern, and CoreWithLegacySupport.gwt.xml which inherits Core and introduces runtime feature checks here and there? That way such apps don't have to pull in UserAgent at all and its probably more straight forward than saying: If you need legacy support then inherit core, useragent and possibly collapse all properties if you want a single permutation. Also GWT would have the control how it provides legacy support and far in the future if GWT only has a modern and a legacy permutation then Core could provide the modern permutation while CoreWithLegacySupport introduces the legacy permutation and UserAgent maps all the user agents to modern or legacy. -- J. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/74f12c72-4e7e-4167-b60e-564448d5d918%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/74f12c72-4e7e-4167-b60e-564448d5d918%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT_EmOdm%2BCNSSom9-RnBdoio74ure2aELE49kRExgiMnXw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] JettyLauncher class loader
I don't understand the details enough to make an informed recommendation, but I think introducing a new entry point is a good time to transition to the standard way (assuming it is standard). We could add the backward-compatibility flag if needed after some testing to see what the breakage would be. - Brian On Tue, Jul 1, 2014 at 6:36 AM, Manuel Carrasco Moñino man...@apache.org wrote: Following the discussion here: https://gwt-review.googlesource.com/#/c/8150/2 What do you guys think about changing the way of how embedded jetty class loader works? Options: - leave it as current: a bunch of hacks to load certain classes at first - modify it to use the standard way: first WEB-INF/lib then classpath - a mix of both, so as the default is #2 but we maintain a flag for using #1 - more... ? -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAtaxEabPDFt-2CEFR154GOHcBYMj47BQOVXHUfqvbyGBw%40mail.gmail.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAtaxEabPDFt-2CEFR154GOHcBYMj47BQOVXHUfqvbyGBw%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT_2Y5CvyV-o5s1AOMY%2Bo2dGaWicwBFLPEJRFrMn7J%3DXZg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: GWTproject site menu
If you click Tutorial and then Documentation the animation is a bit unfortunate. Because the previous menu closes at the same time that the new one opens, the new menu expands both up and down so that your cursor ends up pointing to the middle of the new menu, and then you have to wait until it stops moving to figure out where to move the mouse next. In the old UI, the menu item you just clicked on never moves. But I'm not sure what to do about it. Maybe skip animating closing a menu when it's not the one you clicked on? Also, it's not in the demo, but we should make sure sourcemap debugging works with the new version. I sometimes include a link to gwtproject.org in browser bug reports since I don't know any other public websites that have GWT with sourcemaps on. Unfortunately this is going to break any specific directions I put into the bug reports, but hopefully something equivalent should work. - Brian On Thu, May 8, 2014 at 1:59 PM, Manuel Carrasco Moñino man...@apache.orgwrote: That's intentional, it is the same behavior than tree menus in google wikis and GWT trees. Now the parent item link is only clickable when it has a page associated (it was not possible in the last version), so the click is handled to load that page. On Thu, May 8, 2014 at 6:19 PM, Jens jens.nehlme...@gmail.com wrote: I noticed that it is not possible anymore to close a menu category by clicking on the menu item text again. You can now only close a category by using the triangle icon. -- J. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/2f99fddc-668c-449a-8e98-2abf26d8a3bd%40googlegroups.comhttps://groups.google.com/d/msgid/google-web-toolkit-contributors/2f99fddc-668c-449a-8e98-2abf26d8a3bd%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAsxeDCVrEHLrMm4icr%2BY-OVh89RBqfDdnbBUi_qyudZaA%40mail.gmail.comhttps://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAsxeDCVrEHLrMm4icr%2BY-OVh89RBqfDdnbBUi_qyudZaA%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT8z5gtVUbMpkmtLdoykvYv%2BrGgYDT79agjLBG0VzC1X_Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Development Mode will not be supported in Firefox 27+
For the direction of an open source project, people who volunteer to do actual coding are more important than marketing efforts by people who only want to be users. The intersection of GWT developers and Firefox browser developers seems to be the empty set, so we have very limited influence. This is a challenging time and migration can be painful, but this decision fundamentally isn't up to us. We need to move forward. I think a more promising direction for people who want to improve GWT on Firefox would be to investigate problems with the Firefox debugger and contribute patches that make it practical to use. - Brian On Wed, Apr 16, 2014 at 6:10 PM, Mario Jauvin mari...@gmail.com wrote: People, this has been going on since beginning of February with no action on the part of Mozilla. I have create a new mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=996947 which is about the fact that GWT developper does not work in Firefox any longer. I have proposed a workaround solution that I think is reasonable for Mozilla and the GWT developper community. The only way we will get some traction on this is if every developper interested in having GWT developper working on Firefox (and I would think there are probably several hundreds if not thousands) should then create a bugzilla Mozilla account and vote on this bug (please remember to click change my vote to record your vote). You can also add yourself on the CC list to get updated. I am sure that if Mozilla gets a few hundred votes they will come up with something to get GWT developper plugin working again on Firefox. Please forward this text to all the people who you think will be interested in voting. Lets get the word out it can have a exponential effect. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=996947 -- You received this message because you are subscribed to a topic in the Google Groups Google Web Toolkit group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/QSEjbhhHB4g/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Development Mode will not be supported in Firefox 27+
Ivan, there is an existing bug that's related so I will reply there: https://code.google.com/p/google-web-toolkit/issues/detail?id=7693 On Thu, Apr 10, 2014 at 7:22 AM, Ivan Markov ivan.mar...@gmail.com wrote: The StackTraceDeobfuscator does not play very well with the Super Dev Mode code server though. Reason: StackTraceDeobfuscator needs to have access to the AABBCD...HF.symbolMap files generated during the last SDM compilation. However this directory is a moving target in the SDM code server because each compilation done by the SDM code server creates a *brand new* directory containing all the artefacts generated by this compilation (JS files, source maps, symbol maps). I.e.: - Initially, the symbol maps can be found here: code-server-work-dir/module-name/*compile1* /war/WEB-INF/deploy/short-module-name/SymbolMaps - After the second compilation, they are here: code-server-work-dir/module-name/*compile2* /war/WEB-INF/deploy/short-module-name/SymbolMaps - and so on For the JS files (and GWTRPC files) the above scheme is not a problem, as the code server's own HTTP service serves all artefacts generated by the latest compilation at this fixed URL: http://localhost :sdm-port/short-module-name ... except for the source map and the symbol map Now, the latest source map is also served by the code server, using another magic URL (which I don't recall at the moment). But no such luck for the symbol map... Brian: how hard would it be to alter the code server to serve the symbol map as well, at some special URL? 10 април 2014, четвъртък, 00:16:43 UTC+3, Brian Slesinsky написа: If you are debugging interactively, using pause on uncaught exceptions can help. Then you can look at the stack frames in the debugger. Another workaround is to log stack traces to the server and use StackTraceDeobfuscator. This will also help you in production: http://www.gwtproject.org/javadoc/latest/com/google/gwt/core/server/ StackTraceDeobfuscator.html I don't think we can easily deobfuscate stack traces in the GWT application itself, because it requires the sourcemap which is normally only loaded by the debugger. It would be possible with a round trip to the Super Dev Mode code server, but this would be an asynchronous call so the API would be awkward. On Wed, Apr 9, 2014 at 2:03 PM, Chak Lai chakl...@gmail.com wrote: The stack-trace in Super Dev Mode is the only major issue that I have. It would be nice if the UncaughtException in SDM can tell me which line in java source is causing the problem, instead of giving me those JavaScript stack-trace messages... So far I like SDM. My current project is running a lot faster in SDM compare to Development Mode plugin. -- You received this message because you are subscribed to a topic in the Google Groups Google Web Toolkit group. To unsubscribe from this topic, visit https://groups.google.com/d/ topic/google-web-toolkit/QSEjbhhHB4g/unsubscribe. To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-we...@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to a topic in the Google Groups Google Web Toolkit group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/QSEjbhhHB4g/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Development Mode will not be supported in Firefox 27+
If you are debugging interactively, using pause on uncaught exceptions can help. Then you can look at the stack frames in the debugger. Another workaround is to log stack traces to the server and use StackTraceDeobfuscator. This will also help you in production: http://www.gwtproject.org/javadoc/latest/com/google/gwt/core/server/StackTraceDeobfuscator.html I don't think we can easily deobfuscate stack traces in the GWT application itself, because it requires the sourcemap which is normally only loaded by the debugger. It would be possible with a round trip to the Super Dev Mode code server, but this would be an asynchronous call so the API would be awkward. On Wed, Apr 9, 2014 at 2:03 PM, Chak Lai chaklam@gmail.com wrote: The stack-trace in Super Dev Mode is the only major issue that I have. It would be nice if the UncaughtException in SDM can tell me which line in java source is causing the problem, instead of giving me those JavaScript stack-trace messages... So far I like SDM. My current project is running a lot faster in SDM compare to Development Mode plugin. -- You received this message because you are subscribed to a topic in the Google Groups Google Web Toolkit group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/QSEjbhhHB4g/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Development Mode will not be supported in Firefox 27+
It's true these are disadvantages. There are some compensating advantages that people are pointing out: the code executes faster, it works with remote websites where latency is higher, it works with mobile phones, and so on. But there's no question that losing DevMode (other than IE and Firefox 24) is a loss. Our short-term plan is to speed up compiles and generate JavaScript that looks more like Java for Super Dev Mode and draftCompile. But it it will still be JavaScript, and we will have to adjust. Longer-term, it may be possible to create a variable inspector that shows Java objects instead of JavaScript objects, but that isn't even prototyped yet. On Wed, Apr 2, 2014 at 8:35 AM, Jérôme Beau javar...@gmail.com wrote: Hi Ümit, By I cannot inspect Java values of Java variables I mean that the source-mapping of the Chrome Dev Tools (which are good for JS) : - *shows me stuff I'm not interested into *(most of the time) : this is Window[0], DOM, JS or internal GWT-generated functions or properties appear, such as $H, ___clazz$, getClass$, hasCode$, toString toString$, attached, eventsToSink, proto, etc. -* renames stuff I'm interested into* : MyClass becomes MyClass 0 1, etc. this becomes this$static - *doesn't allow me to skip only in my code by defaut*, that is, automatically skip internal, gwt-generated code while stepping - *doesn't allow me to use Java-expressions in breakpoints nor evaluations* : have to use JS string.length, not String.length() for instance, etc. You know, this just like when you debug plain Java code. Most of the time, you are not interested in debugging JDK sources. This may be interesting for understanding things and optimization (if you forget that's only draft JS code that will _not_ be the final code), but this is disabled by default. One might also consider than inspecting bytecode is good for understanding and optimization, but that's not reasonnable. Le mercredi 2 avril 2014 16:26:50 UTC+2, Ümit Seren a écrit : What exactly do you mean with I cannot inspect Java values of Java variables with SDM ? Can you provide an example where you can't inspect a Java value with Chrome Dev Tools ? I think Dev Mode will never come back. SDM is here to stay and despite there is a lot to be desired, with time development experience will be much better than with normal Dev Mode. The Chrome team is putting huge amounts of work into improving Chrome Dev Tools. The profiling features are crucial if you want to create performant web apps and I prefer to do all task (profiling, fiddling with DOM/CSS and debugging) right in the Chrome Dev Tools rather than switching between Chrome Dev Tools and my IDE. For those who really need the features of their IDE there are some efforts to bring sourcemap debugging to eclipse (AFAIK IntelliJ has already support for it built in) The biggest issue with SDM are currently compile times but that's going to improve with the incremental compiler in GWT 2.7. On Wed, Apr 2, 2014 at 3:57 PM, Jérôme Beau java...@gmail.com wrote: Hi Jens, Just for the record : do you agree that using SDM you cannot inspect Java values of Java variables in your browser? I agree about the mobile dev, about knowing the underlying web platform, about everything but... any debugging session, Java or JS, have to be consistent : if I debug JS, I expect to have JS inspections ; if I debug Java (even in the browser through sourcemaps), I expect to see Java values and Java symbols, and I expect that my conditional breakpoints occur on Java expressions, not JS expressions. That's it. Otherwise I would have used a JS framework. Is there a tiny possibility that GWT can provide this in some future? Le mercredi 2 avril 2014 12:47:45 UTC+2, Jens a écrit : I just realized that lack of Firefox 27+ support for dev mode recently (tried it because Chrome's plugin crashed too often) and really think this is a shoot in the foot for GWT : even if you don't control Mozilla choices of course, forcing to move to a non-mature SDM is very risky for GWT itself. But there is no other viable solution and the transition was actually planed more smoothly. I can understand that many people can not use SDM just because the SDM compilation is too slow for their project. But I don't understand people saying that debugging with SDM is a pain. Yeah for a Java developer it is strange to leave the IDE but honestly for every day debugging browsers provide everything you need. There may be some hiccups here and there but overall it is useable and it is not at all comparable to the situation around the time GWT was invented. Back in these days use your Java debugging tools was a very strong argument but today browsers have catch up and will continue to catch up. If GWT will provide debugging in IDEs with SDM then it is only for convenience. You must become a web developer even if choosing GWT and you should understand the browser
Re: Super Dev Mode in Firefox, Breakpoints not being hit
In my testing they do sometimes work but it is certainly flaky. I recommend adding a GWT.debugger() call and recompiling; that should always work, unless something is really wrong. - Brian On Monday, March 3, 2014 12:44:06 PM UTC-8, Ben Hegarty wrote: Hi, I was wondering if anyone is seeing issues using super dev mode in firefox, I've tried it in chrome and it works perfectly, but in firefox the breakpoints aren't being hit, i've even rolled back to using a basic project just to test it and still with no luck. Is anyone else seeing this issue? Or is a special way that firefox enables breakpoints? Regards Ben -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
Re: Super Dev Mode in Firefox, Breakpoints not being hit
Here's the Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=949118 On Tue, Mar 4, 2014 at 11:52 AM, Ben Hegarty heg...@gmail.com wrote: That seems to have helped, so it breaks on the GWT.Debugger() but the breakpoints still seem not to work. At least I have a workaround cheers. On Tuesday, 4 March 2014 18:19:59 UTC, Brian Slesinsky wrote: In my testing they do sometimes work but it is certainly flaky. I recommend adding a GWT.debugger() call and recompiling; that should always work, unless something is really wrong. - Brian On Monday, March 3, 2014 12:44:06 PM UTC-8, Ben Hegarty wrote: Hi, I was wondering if anyone is seeing issues using super dev mode in firefox, I've tried it in chrome and it works perfectly, but in firefox the breakpoints aren't being hit, i've even rolled back to using a basic project just to test it and still with no luck. Is anyone else seeing this issue? Or is a special way that firefox enables breakpoints? Regards Ben -- You received this message because you are subscribed to a topic in the Google Groups Google Web Toolkit group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/AofkGmhKJ-c/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
Re: Development Mode will not be supported in Firefox 27+
I'm not sure what the Jetty problems are but they should be fixed. Do we have a good bug report for them? (In our setup we see stack traces but Jetty still runs.) - Brian On Thu, Feb 27, 2014 at 4:51 PM, joerg.hohwil...@googlemail.com joerg.hohwil...@googlemail.com wrote: Hi there, I can understand that it is a hard task to maintain the GWT and especially DevMode with its plugins. However, the hole thing about GWT is that you can do pure Java and use the Java tooling. Developers know how to work with Eclipse. And within the Eclipse debugger you can evaluate deeply into variables and objects, add conditional breakpoints, exception breakpoints, dynamically evaluate expressions, have step filters, drop to frame, etc., etc. I am a power user and going to SDM with chrome debugger is simply no alternative and will IMHO never be. With GWT 2.6.0 DevMode even stopped working due to Jetty problems so I can not even use it with older FF versions. This is a real pain for me. I am wondering if I wasted the last years building on GWT all nights ( https://github.com/m-m-m/mmm/tree/master/mmm-client/mmm-client-ui/mmm-client-ui-widget/mmm-client-ui-widget-impl-web-gwt). Then I could also assimilate with JS hell and go for AngularJS. Sorry for being so negative but I am really frustrated. Thanks for all your support on GWT (2.6.0 brings J1.7 syntax support, etc. what is really cool) and your will to improve it in the future. Maybe you can change my mind one fine day and bring me back... Regards Jörg Am Donnerstag, 20. Februar 2014 11:57:30 UTC+1 schrieb Thomas Broyer: On Thursday, February 20, 2014 9:49:42 AM UTC+1, m...@touk.pl wrote: Couldn't agree more... debugging the client-side GWT code in the IDE debugger (Eclipse in my case) is base of my every day work :( I'm sure the SDBG devs would love to hear your feedback ;-) https://github.com/sdbg/sdbg -- You received this message because you are subscribed to a topic in the Google Groups Google Web Toolkit group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/QSEjbhhHB4g/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] JavaWriter API as replacement for SourceWriter family
I believe it's just an idea. In practice, we have lots of GWT generator code that's not easily migrated. I'm not familar with APT but if I wanted to learn about it I would probably start by studying Guice's AutoValue. If they're using JavaWriter then that's a good endorsement. - Brian On Thu, Feb 27, 2014 at 4:17 PM, James Nelson ja...@wetheinter.net wrote: Is there anywhere to get a sneak preview on the discussions about the future of codegen? Andres and I have both invested time in some extensions of ast-based codegen, and could really use some time and forewarning to adapt our strategy to stay future-friendly with out apis. -- 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. -- 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.
Re: Development Mode will not be supported in Firefox 27+
I'm not sure there's much to discuss. Firefox 27 is already released, and we do want to move off of Dev Mode sooner or later for other reasons. I don't feel comfortable asking them to bring back an API that they never officially supported anyway and it seems unlikely that they'd agree. Running Firefox 24 seems like an acceptable workaround. Regarding the Firefox-specific debugger API's, I'm not sure it's worth even figuring out if it's feasible or not since our plan is to move to Super Dev Mode. But if someone wants to take a look then go ahead. - Brian On Tue, Feb 25, 2014 at 11:47 AM, Benjamin Bitdiddle benbitdiddl...@gmail.com wrote: Would anyone like to follow up the last comment on the bugzilla thread, where a FF dev claims that: Most C++ JSAPI usage in extensions can in fact be replaced by a combination of privileged script and the debugger APIs I assume we wouldn't be seeing this thread if that was really true as you guys would have just updated the plugin. -- You received this message because you are subscribed to a topic in the Google Groups Google Web Toolkit group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/QSEjbhhHB4g/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
Re: Development Mode will not be supported in Firefox 27+
Super Dev Mode works and we have many teams that use it. The Chrome debugger is quite good and I recommend learning it well; anyone working on web apps will benefit from knowing this tool. For other browsers, adding a GWT.debugger() call to the Java code and recompiling is an easy way to stop in the right place. I discussed other workarounds in my GWT.create talk [1]. It's an unfortunate transition and this experience is not as smooth as it could be yet, but that's where we are. - Brian [1] https://docs.google.com/a/google.com/presentation/d/1DTWZ_06dQsTPhinIwzHSdoPMndRr92wpZoZWicK97YQ/edit?forcehl=1hl=en#s On Wed, Feb 19, 2014 at 8:37 AM, Jeff Evans wayne.mok...@gmail.com wrote: On Tuesday, February 18, 2014 4:30:50 AM UTC-5, Aleksander Gralak wrote: That is pretty bad information for all GWT developers. For now I can stick with FF 24.2, however in the future we need to develop on the most up to date browsers. When do you estimate Super Dev Mode will be production ready? If it is more then 6 months then we should think of some workaround. Is is possible to do a custom build of FF with all necessery symbols exported? According to [1] https://bugzilla.mozilla.org/show_bug.cgi?id=920731 they have switched it off. But if someone (sorry I am not C++ developer so I will not do it myself) can build GWT development version with those symbols. Then we would be able to do development for several more months on the latest browser and wait till Super Dev Mode if fully functional. Can someone clarify what is meant by fully functional for Super dev mode? In my view, debugging the client-side GWT code in the IDE debugger, alongside server-side Java code, is the killer feature. I can't believe anyone would ever consider in-browser Javascript debugging to be an acceptable replacement. Or perhaps I'm missing something? -- You received this message because you are subscribed to a topic in the Google Groups Google Web Toolkit group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/QSEjbhhHB4g/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] bug in permutations.js?
Maybe turn on soft permutations in a sample app, since we do at least test those manually before a release. Long-term, I'd like to see us using soft permutations by default, perhaps to collapse some browser permutations. If it were more commonly used then we'd likely notice that it's broken pretty quickly. - Brian On Fri, Feb 14, 2014 at 2:32 PM, Stephen Haberman step...@exigencecorp.comwrote: Yes it sounds like a bug. Want to add that to the issue tracker? https://code.google.com/p/google-web-toolkit/issues/detail?id=8575 I've verified that the patch fixes the behavior in our application. Any good suggestions about how to test this? Or volunteers to review the patch? Given it was, I assume, a bug in permutations.js, I imagine I would have to create a mini test app with collapse-all-properties, have it compile to JS, and then somehow verify that the right deferred binding for permutation 0 (which ever browser that happened to be) got the right selection. Thanks, Stephen -- 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. -- 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.
Re: [gwt-contrib] bug in permutations.js?
Yes it sounds like a bug. Want to add that to the issue tracker? I wonder why more people aren't seeing this? Does it only affect soft permutations? - Brian On Thu, Feb 13, 2014 at 11:41 AM, Stephen Haberman step...@exigencecorp.com wrote: Hey, We upgraded to GWT 2.6 last week, and our seeing weirdness with StyleInjector. Firefox ends up using the StyleInjectImplIE and errors out because $doc.createStyleSheet is IE only. FF gets the wrong deferred binding because its permutationId is undefined, when it should be 0. (We use collapse-all-properties and direct_install linker.) Looking at permutations.js, it does var softPermutationId, then later when parsing the strongName, our FF strongName doesn't have : in it (see below), so it ends effectively up doing: module.__softPermutationId = undefined; In our module.nocache.js file, here's the gecko1_8 entry: unflattenKeylistIntoAnswers(['gecko1_8'], '9181777BF8BB65802D36B21DCBB83FE1'); No :0 at the end. So, surely __softPermutationId being undefined is a bug? Should I try fixing this by changing getCompiledCodeFilename's softPermutationId to default to 0? Or is the problem with the strong name itself, in that it should always have a :digit suffix? Hm. PermutationsUtil:131 insinuates :0 is left off on purpose. Looking at git log/git blame, doesn't seem like any of this has changed recently? We had been running some post-2.5 GWT trunk. - Stephen -- 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. -- 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.
Re: [gwt-contrib] Re: Not able to run GWTTestCase
I'm not an Eclipse user, but we did upgrade to Jetty 8.1 in 2.6 and its package changed. If you put the new version of Jetty in your classpath that will probably fix it. - Brian On Thu, Feb 13, 2014 at 6:44 AM, Stephan Beutel stephan.beu...@gmail.comwrote: I also tried it with the Eclipse 3.8 and end up at the same point. I'm not able to run any GWTTestCase. Am Mittwoch, 12. Februar 2014 12:17:55 UTC+1 schrieb Stephan Beutel: Hello, I set up my Eclipse to contribute to GWT and worked through the Readme to set up an Eclipse workspace. All errors are gone in my Eclipse (Springsource Toolsuite) now, but I'm not able to run any GWTTestCase from within my Eclipse. The Ant build runs successfully. When trying to run any GWTTestCase I get this error: java.lang.Error: Unresolved compilation problems: The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved AbstractLifeCycle cannot be resolved to a type RequestLog cannot be resolved to a type Request cannot be resolved to a type Response cannot be resolved to a type AbstractHttpConnection cannot be resolved to a type HttpFields cannot be resolved to a type Field cannot be resolved to a type Logger cannot be resolved to a type Logger cannot be resolved to a type Server cannot be resolved to a type WebAppContext cannot be resolved to a type Server cannot be resolved to a type WebAppContext cannot be resolved to a type Server cannot be resolved to a type WebAppContext cannot be resolved to a type Log cannot be resolved WebAppContext cannot be resolved to a type Server cannot be resolved to a type WebAppContext cannot be resolved to a type Server cannot be resolved to a type Log cannot be resolved Log cannot be resolved Server cannot be resolved to a type Server cannot be resolved to a type Log cannot be resolved WebAppContext cannot be resolved to a type WebAppClassLoader cannot be resolved to a type The method findResource(String) of type JettyLauncher. WebAppContextWithReload.WebAppClassLoaderExtension must override or implement a supertype method WebAppClassLoader cannot be resolved to a type WebAppClassLoader cannot be resolved to a type The method findClass(String) of type JettyLauncher. WebAppContextWithReload.WebAppClassLoaderExtension must override or implement a supertype method WebAppClassLoader cannot be resolved to a type The method isServerClass(String) is undefined for the type JettyLauncher. WebAppContextWithReload.WebAppClassLoaderExtension WebAppClassLoader cannot be resolved to a type The method addClassPath(String) is undefined for the type JettyLauncher. WebAppContextWithReload.WebAppClassLoaderExtension The method getInitParams() is undefined for the type JettyLauncher. WebAppContextWithReload The method setParentLoaderPriority(boolean) is undefined for the type JettyLauncher.WebAppContextWithReload The method isSystemClass(String) of type JettyLauncher.WebAppContextWithReload must override or implement a supertype method WebAppContext cannot be resolved to a type The method doStart() of type JettyLauncher.WebAppContextWithReload must override or implement a supertype method The method setClassLoader(JettyLauncher.WebAppContextWithReload.WebAppClassLoaderExtension) is undefined for the type JettyLauncher.WebAppContextWithReload WebAppContext cannot be resolved to a type The method doStop() of type JettyLauncher.WebAppContextWithReload must override or implement a supertype method WebAppContext cannot be resolved to a type The method getClassLoader() is undefined for the type JettyLauncher. WebAppContextWithReload The method setClassLoader(null) is undefined for the type JettyLauncher. WebAppContextWithReload AbstractConnector cannot be resolved to a type Log cannot be resolved Server cannot be resolved to a type Server cannot be resolved to a type AbstractConnector cannot be resolved to a type The method getConnector(TreeLogger) from the type JettyLauncher refers to the missing type AbstractConnector WebAppContext cannot be resolved to a type The method createWebAppContext(TreeLogger, File) from the type JettyLauncher refers to the missing type WebAppContext RequestLogHandler cannot be resolved to a type
Re: [gwt-contrib] Using JIRA as issue tracker instead of google code - and other things
I just ran a bulk edit to change all 2.6 bugs marked fixed not released to fixed. Thanks for catching that! (Switching to a different issue tracker is a whole different discussion.) - Brian On Wed, Feb 5, 2014 at 11:22 AM, Gilberto Torrezan Filho gilberto.torre...@gmail.com wrote: Hi, I was wondering if you have considered using JIRA as issue tracker instead of the suplied by google code. Many open source projects uses it (such as JBoss Errai, at https://issues.jboss.org/browse/ERRAI ) and I think it is far superior than the vanilla google code issue tracker - for the developers and for the community. I was thinking about it because of the fact most of (all?) the issues fixed on 2.6.0 release are marked as Fixed_Not_Released - which implies you don't have an automatic script to update those issues on release... and I don't know if this kind of task could be scripted using google code APIs. The fact is you can do that using JIRA, beside all other advantages. Anyway, using JIRA, google code or any other issue tracker, I think you should automatize the process of releasing the package (including uploads of the binary, the source and the javadoc to gwtproject.org and to Maven central) and closing the related issues at the issue tracker, to avoid awkward situations with the project documentation. -- 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. -- 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.
Development Mode will not be supported in Firefox 27+
Mozilla has stopped exporting some C++ symbols that the Firefox plugin relies on [1]. Therefore it's not possible to support Development Mode in any new versions of Firefox starting with 27. As a workaround, I am doing one last release to get the plugin working again with Firefox 24.2 (and hopefully newer point releases on the ESR track). If you wish to continue to use Development Mode on Firefox, you will need to download this version from Mozilla [2]. For more details see the issue tracker [3]. Long-term, the plan is to improve Super Dev Mode. I apologize for the late notice; when I said at GWT.create that Firefox could stop working with any release, I didn't expect it to be the next one. - Brian [1] https://bugzilla.mozilla.org/show_bug.cgi?id=920731 [2] http://download.cdn.mozilla.net/pub/mozilla.org/firefox/releases/24.2.0esr/ [3] https://code.google.com/p/google-web-toolkit/issues/detail?id=8553 -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Quarterly Hangouts On Air
Perhaps have an occasional meeting day on the mailing list or in G+, sort of like a Reddit Ask me anything? This might work better with people in different timezones. On Mon, Jan 27, 2014 at 11:39 AM, Goktug Gokdogan gok...@google.com wrote: Just FYI, our gwt-team meetings didn't get enough interest for live stream to justify the effort so we eventually switched to just recording instead. One thing that might be useful for community with much less effort is; gwt-steering can look into a few top questions from moderators in their periodic meeting and respond to and/or delegate them. On Mon, Jan 27, 2014 at 1:15 AM, jay jay.gin...@gmail.com wrote: I'll speak up in favor! I'm sure we'd get a number of folks from my company who would be very interested in listening if not actively participating. jay On Sunday, January 26, 2014 12:41:40 PM UTC-8, James Nelson wrote: Hi all, I am just wondering if it would be possible to setup a quarterly QA hangout-on-air with steering committee members taking questions from the public, and presenting on ideas that are in the works for GWT. It would be similar to the panel held at GWT.create, except we could collect up the questions via Google Moderator over the coming months, to give panel members time to discuss and decide on answers. If possible, I would like to get a few RSVPs before mentioning it at the community hangout; we could schedule the first QA panel for the end of March, and post the moderator tomorrow to get people started on the questions. Thanks, James -- 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. -- 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. -- 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.
Re: [gwt-contrib] Re: IntelliJ IDEA set-up
Generally I just exclude the super classes from the project; since there should always a server-side equivalent, the rest of the code should still compile. You lose syntax checking on the super files, though. On Wed, Jan 15, 2014 at 12:10 PM, Danilo Reinert danilorein...@gmail.comwrote: I'm unable to avoid java compiler confusion related to super classes. -- D. Reinert Em quarta-feira, 15 de janeiro de 2014 12h38min53s UTC-3, Danilo Reinert escreveu: I tried importing from eclipse files but I`m still getting 8 errors: java: duplicate class: com.google.gwt.regexp.shared.RegExp java: duplicate class: com.google.gwt.regexp.shared.SplitResult java: duplicate class: com.google.gwt.validation. client.GwtMessageInterpolator java: duplicate class: com.google.gwt.validation.client.spi. GwtConfigurationState java: duplicate class: com.google.gwt.regexp.shared.MatchResult java: duplicate class: com.google.gwt.validation. client.impl.GwtConfiguration GwtConfiguration.java java: com.google.gwt.validation.client.impl.GwtConfiguration is not abstract and does not override abstract method addMapping(java.lang.String) in javax.validation.Configuration java: method does not override or implement a method from a supertype I've configured GWT SDK to $gwt/trunk/build/staging/gwt-0.0.0. Any IDEAs? -- D. Reinert Em quarta-feira, 15 de janeiro de 2014 06h30min03s UTC-3, Julien Dramaix escreveu: IIRC, I've just imported the projects using the eclipse files and followed the instruction in README.txt file. On Wed, Jan 15, 2014 at 10:11 AM, Thomas Broyer t.br...@gmail.comwrote: On Wednesday, January 15, 2014 5:52:54 AM UTC+1, Danilo Reinert wrote: Has anyone set-up gwt project in IDEA 12+ ? I know Ray Cromwell has, among others most probably. Maybe he can share some files somewhere? In the (near?) future, we'll migrate out of Ant to make it easier to auto-configure your IDE (either Eclipse or IntelliJ, possibly others). You can try out Ray's gradle-build branch: https://github.com/ cromwellian/gwt-sandbox/tree/gradle-build I've been working on the Gradle build on my side, based on Ray's scripts and with the intent to first mimick the Ant build, but haven't tested the IntelliJ configuration (yet): https://github.com/ tbroyer/gwt-sandbox/tree/gradle-build -- 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+unsubscribe@ googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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. -- 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.
Re: [gwt-contrib] What about the release of 2.6.0?
Sometime in January after people are back from vacation. On Mon, Dec 30, 2013 at 11:42 AM, Cristiano cristiano.costant...@gmail.comwrote: Hello all, it is many days I don't see info about the release date for GWT 2.6.0... I see in GWT issues there are 7 issues for milestone 2_6 that are not in state FixedNotReleasedhttps://code.google.com/p/google-web-toolkit/issues/detail?id=5524q=milestone%3A2_6sort=status%20milestonecolspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Stars. Is the community only waiting to have these 7 issues fixed before releasing 2.6.0? Any hypothesis on when the final 2.6.0 will be released? Cristiano -- 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. -- 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.
Re: [gwt-contrib] Rebinding Methods improvement proposal and working prototype
This is well-documented and looks like solid work. I think the main issue
will be whether it can be made compatible with modular compilation. So the
best timing will be to land it after modular compilation.
It looks like it should be compatible because the compiler doesn't need to
see how a @Rebind method is implemented in order to call the generator for
a call site? So we can run the generator in each module that calls a
@Rebind-marked interface method.
- Brian
On Thu, Nov 28, 2013 at 6:19 AM, Andrés Testi andres.a.te...@gmail.comwrote:
The last 3 months I have been working on a GWT Improvement Proposal
inspired by the idea of Ray Cromwell for Relaxing constraints on
GWT.create()http://timepedia.blogspot.com.ar/2009/03/relaxing-constraints-on-gwtcreate.html.
I wrote a technical document and implemented it as a fork
of GWT master at GitHubhttps://github.com/andrestesti/gwt-rebindingmethods
.
As a quick example of what is possible to do with Rebinding Methods, you
can look at the hellorebinding
samplehttps://github.com/andrestesti/gwt-rebindingmethods/blob/master/samples/hellorebinding/src/com/google/gwt/sample/hellorebinding/client/MainWidget.java#L39
:
public MainWidget() {
/*
* No boilerplate required to bind user interfaces.
*/
initWidget(UiBinders.createAndBindUi(Widget.class, MainWidget.class,
this));
}
The working prototype is fully functional, and passed the same test suites
than GWT master. DevMode works fine, and I think SuperDevMode should work
too.
Please, feel free to add feedback in the document and/or GitHub. I
apologize for my possible grammatical errors, since I'm not english native
speaker.
Links of interest:
- Ray Cromwell's blog post:
http://timepedia.blogspot.com.ar/2009/03/relaxing-constraints-on-gwtcreate.html
- Rebinding Methods proposal:
https://docs.google.com/document/d/1K25f6-Hxtlj31pthapfUhmNxS1OPiUXZFtHDnHGjrpg
- Working prototype: https://github.com/andrestesti/gwt-rebindingmethods
Thanks in advance.
- Andrés Testi
--
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.
--
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.
Re: NPAPI
I'm not familiar with Windows 8, but I believe you have to run Chrome outside metro mode to get plugins to work. http://blog.chromium.org/2012/07/npapi-plug-ins-in-windows-8-metro-mode.html On Friday, November 29, 2013 10:24:24 AM UTC-8, Joshua Zeidner wrote: Hi Millie, I'm experiencing the same problem. I'm on Windows 8. Did you find a solution? -jmz On Saturday, November 9, 2013 2:48:53 PM UTC-8, Millie Smith wrote: When I try to install the Chrome plugin for GWT, I get the following text in a popup: NPAPI plugin is required by this app. All of the NPAPI installs look complicated. Is there an easy way to get this installed? Also, when I installed the Firefox plugin, Firefox refused to start again without a complete factory reset. The Internet Explorer plugin works, so I'm developing in IE. I don't like IE. Please stop the torture. Any suggestions? :) -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
Re: Building the dev plugin for firefox
It's fairly complicated to build because we have to do a C++ compile against the latest XulRunner SDK on three platforms and assemble the results. Furthermore, converting a new XulRunner SDK into the format needed to do the build is a partially manual process. But if you just want to build on one platform (Linux or Mac, preferably) for a Firefox release we already support, it should be easier and that should be enough to get started. And yes, we'd like to accept patches. I have a document with the build procedure, but it contains Google-specific steps. If you're seriously interested then I could publish a cleaned-up version. - Brian On Tuesday, November 26, 2013 8:33:00 AM UTC-8, navels wrote: What are the general steps involved to build the firefox plugin? How involved are the fixes to maintain compatibility with new FF releases? (I'm sure it depends on the release, but is there a general level of complexity.) Would I be able to contribute patches? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Jetty 9
For GWT 2.6, Super Dev Mode, and the RemoteServiceServlet, you could set the gwt.codeserver.port Java property. On Wed, Nov 20, 2013 at 1:35 AM, Jens jens.nehlme...@gmail.com wrote: The issue comes up when we change a piece of shared code, like a DTO. What we've found is that if we don't stop, recompile from the command line (including gwt compile) the updated DTO can't be sent/received...the GWT-RPC stuff doesn't match up any more and we get failures. You just have to reload the browser first so that the DevMode regenerates *.rpc files for your changed shared DTO classes. After that you redeploy the updated *.rpc files along with the rest of the server code to jetty. I also use external servers (Glassfish / Jetty 9) and never do a GWT compile while developing / debugging. If the external server is not on my local host I use an ant build script to gather all the classes that the IDE already has compiled (basically copying the bin or WEB-INF/classes folder) along with any important GWT files (*.rpc, hosted.html, app.nocache.js). From these files I build a war and then deploy it remotely. If the external server is installed on my local host, for example Jetty, I let it deploy the project's war folder directly as it is already an explored war. Should work well with Eclipse as the hosted.html / app.nocache.js / *.rpc files are all generated into that war folder because of the Eclipse plugin (unless you have configured it different). If you use IntelliJ you can let IntelliJ do all the work by defining a server artifact and configure a Jetty server in IntelliJ to deploy that server artifact. Then you have to modify your GWT DevMode run configuration and add -war path/to/intellij/server/artifact so that hosted.html / app.nocache.js / *.rpc files are placed inside IntelliJ's artifact folder. Then you only have to hit update in IntelliJ to redeploy things in Jetty. I would guess Eclipse WTP lets you do something very similar. In all those cases I often use an additional local web server with HTTP proxy capabilities. That way I can redirect server requests to any external server so for example I could swap between a local Jetty instance of a remote one or between Jetty and a Glassfish installation on different ports, etc. while accessing my app always on http://localhost?gwt.codesrv=... -- J. -- 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. -- 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.
Re: GWT DevMode latest version (1.25 ?) crashes FireFox 24 ESR
I suspect the way we're selecting the correct DLL for the Firefox version is not working somehow. For now, download this version: https://code.google.com/p/google-web-toolkit/downloads/detail?name=gwt-dev-plugin-1-24-rc.xpi On Wed, Nov 6, 2013 at 2:17 AM, Thomas Broyer t.bro...@gmail.com wrote: [+cc skybrian] Brian, any idea? On Wednesday, November 6, 2013 11:10:23 AM UTC+1, stuckagain wrote: Thomas, Should I file this as an issue ? Or is it not worth pursuing since somehow the GWT dev team is thinking about replacing the DevMode with SuperDevMode everywhere ? David On Tue, Nov 5, 2013 at 12:50 PM, David david...@gmail.com wrote: Windows 7 64bit On Monday, November 4, 2013, Thomas Broyer wrote: On which OS is this? On Monday, November 4, 2013 11:52:25 AM UTC+1, stuckagain wrote: Hi, I am trying to run devmode on FireFox 24 ESR release, Plugin version says 1.25. When FireFox starts it crashes, when I delete the GWT DevMode plugin FireFox works again. I can not upgrade to a newer version of FireFox since this is the version that our customers will use and so I want to debug in this version. David -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@ googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] String concatenation
Not a compiler expert, but I wouldn't be surprised since in the AST it will be represented as a binary tree of JBinaryOperation nodes and the visitors walk the tree recursively. So balancing the tree should result in a smaller stack. - Brian On Wed, Oct 30, 2013 at 1:10 PM, Julien Dramaix julien.dram...@gmail.comwrote: Dear GWT lovers, I have a question for the compiler guys : in the CssResource I see a comment mentioning that very large string concatenation expressions using '+' cause the GWT compiler to overflow the stack due to deep AST nesting. So it's preferable to use intermediate concatenation groupings in order to force the AST to be more balanced. I'm just wondering if this issue is still present with the actual version of the compiler or if it was fixed to better handle large concatenation ? Thanks, Julien -- 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. -- 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.
Re: [gwt-contrib] Re: Change in gwt[master]: Added disabled IE10 permutation
On Wed, Oct 23, 2013 at 11:59 AM, Jens jens.nehlme...@gmail.com wrote: Hmm. It's a fair point. On the other hand, you don't *have* to upgrade right away. Hehe sure, but its hard to resist Java7, @GwtIncompatible support and compiler/code splitting bug fixes ;-) But maybe I misunderstood Matthew's post? I was under the impression that with either solution 1 or 2 I could upgrade right away to 2.6 without problems. In order to stay on the safe side when upgrading to 2.6 the only thing I need to care about is to make sure that IE10 permutation is disabled (which means I put myself in the same situation as with GWT 2.5.1 which does not know IE 10). You can certainly try it and most things will likely work, for now. The only issue is if you're using some third-party library that expects the IE10 permutation to be there, and might behave strangely with IE10 if the IE9 permutation gets used instead. We have to decide which configuration people writing third-party libraries should test their code with for 2.6; they aren't likely to test everything and will probably just test with 2.6 and the defaults. It seems better in the long term if they assume the IE10 permutation is there. - Brian -- 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.
Re: A couple minor hurdles to enterprise consideration
I was able to find a virtual machine running Windows 8 and the front page of www.gwtproject.org seemed to load okay. If you have specifics about what they saw and how to reproduce it, that would help. That said, I think GWT would be a poor fit for a company that is mainly targeting IE8. If they're not using GWT already then it's probably best not to start now. - Brian On Tuesday, October 22, 2013 11:59:55 AM UTC-7, Jens wrote: They have probably enabled compatibility mode in IE 8. Turn IE 8 into standards mode and I am pretty sure the gwtproject.org site will show up correctly (although not tested by myself right now) GWT still supports IE 8 and I would guess it will support IE 8 until the end of next year. After that..well..that company just can't upgrade to the newest GWT release anymore. Honestly, if that company does not yet have an upgrade plan for Win 7 (or newer) ready then they will have quite some other problems once MS stops publishing security updates for Win XP and IE 8 in April 2014. -- J. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
Re: GWT 2.6 Release Note
Modular compilation probably won't be ready for GWT 2.6. If it's there at all, it will be experimental. On Tuesday, October 22, 2013 6:02:46 AM UTC-7, Thomas Broyer wrote: On Tuesday, October 22, 2013 2:33:59 PM UTC+2, jesty wrote: Thanks to all for the answer. About this features: * - Modularization and mavenization * It'll actually be a gradle-ization; I declared defeat with Maven, it's hostile to migrations like those. But that only affects people that build GWT themselves. Modularization will be done afterwards (with Maven, it would have had to be done, at least partly, as part of the migration), and should be ready for 3.0 (hopefully). * I'm working in a big project with more than 20 modules and I would like to have this features. Actually I used http://mojo.codehaus.org/gwt-maven-plugin/, not bad, but I hope in a better support :) * You can have a look at http://github.com/tbroyer/gwt-maven-plugin but it's likely to stay in its current pre-alpha state for some time. If you want more flexibility than org.codehaus.mojo:gwt-maven-plugin provides, then you can just use the exec-maven-plugin. What kind of better support are you looking for? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Bad news for GWT DevMode!
I expect that by next summer devmode will *only* work in IE and perhaps an older version of Firefox. Oddly enough, the IE plugin has apparently worked for years with no complaints. (But the issue is that nobody currently on the team has ever built it.) - Brian On Mon, Oct 21, 2013 at 6:56 AM, Thomas Broyer t.bro...@gmail.com wrote: I don't think any committer to the GWT project uses Windows (other than for testing, using VMs then), so it'd be either Firefox or Chrome (no other choice on Linux; and on OSX, Safari is no longer supported started with 5.1, and I don't think anyone uses OmniWeb or similar). Both work well. To answer the question about a “preferred browser”, I've been told that, on Windows, IE works best (is the fastest); that was a while back though, so things might have changed. On Monday, October 21, 2013 3:21:49 PM UTC+2, Ivan Dimitrijevic wrote: IMO Firefox On Friday, October 18, 2013 11:47:13 PM UTC+2, Alex Raugust wrote: Just curious, is there a preferred browser for Classic DevMode? What do the cool kids use? :) On Tuesday, September 24, 2013 4:05:59 AM UTC-7, Thomas Broyer wrote: Just saw this passing on Twitter: http://blog.chromium.** org/2013/09/saying-goodbye-to-**our-old-friend-npapi.htmlhttp://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html This is really bad for DevMode in Chrome (maybe also in Firefox, which was already a nightmare). Means we really need to improve SuperDevMode, or find a non-NPAPI way to plug into the browser. -- 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. -- 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.
Re: [gwt-contrib] Re: Issue with development mode plugin and Custom selection script / hosted.html that allows separate debugging of multiple GWT applications on a single page
For (1), Super Dev Mode supports multiple GWT apps out of the box. (but you
do have to recompile each GWT application you want to debug, one at a time).
For (2) I don't think we support multiple instances of the same GWT app. I
don't think it's a good idea because you'd be loading the same JavaScript
files multiple times (in different iframes). The way I would do it is to
have a single GWT application handle multiple instances of itself
internally. On startup, the entry point could create a separate top-level
widget for each instance. They would share static variables, so you'd
needed to make sure any per-instance state is non-static.
On Thu, Oct 17, 2013 at 3:20 AM, Jamie Cramb jamie.cr...@gmail.com wrote:
Hi Thomas,
Thanks for the reply and apologies for the delay, I must have missed the
email notification re: your reply.
Well its great to hear that it is already solved via the xsiframe linker,
but not a total loss, I learned a good deal about how the IFrame linker
currently works ;)
I gave the xsiframe linker a try with the following results:
- I had to deal with the xsiframe linker not supporting script /
tags (the Piriti library I use for JSON serialization has a script tag in
its *.gwt.xml module files); the workaround for this is well documented but
something to consider when rolling this linker out as the default
(potentially a breaking change).
- I was unable to get this working in Firefox v24 on Win7 64bit but
was unable to get it working in Google Chrome v30.0.1599.101 m... *have
you tried this on Chrome recently*? I actually saw a similar behavior
to what I reported with my own solution (once, i was not able to re-create)
which was that it would fail unless the gwt.codesvr without the module name
was also in the URL.
The reason I'm working on this is primarily for Portal type
functionality; is there any work on the roadmap related to getting GWT to
play nicely inside a portal-type environment where:
1. Multiple GWT applications can be rendered on a single page and
debugged individually (looks like xsiframe linker is getting us there).
2. Multiple instances of the same GWT application can be rendered on
the same page but with different bootstrap params; e.g. being able to
pass in:
- Preferences to tell instance X of the widget to display a graph
over 12 months and instance y to display a graph over 3 months
- The div that the GWT application should attach itself to.
Thanks in advance.
Cheers,
Jamie
On Wednesday, October 9, 2013 8:50:45 AM UTC+1, Thomas Broyer wrote:
Too bad you started investing time in a solution to a problem that's
already solved!
You first have to use the xsiframe linker (which BTW is not a bad idea; I
think we should make it the default linker in some future release), then
just use gwt.codesvr.myModule instead of gwt.codesvr, where myModule is the
name of your module (same name as the folder and nocache.js)
See https://code.google.com/p/**google-web-toolkit/issues/**
detail?id=2079#c21https://code.google.com/p/google-web-toolkit/issues/detail?id=2079#c21
On Tuesday, October 8, 2013 7:07:40 PM UTC+2, Jamie Cramb wrote:
Hi all,
I have a page which has multiple GWT applications running on it. When
it comes to development mode / debugging from eclipse (using the dev mode
plugin in chrome) we start to hit issues because if we put the
gwt.codesvr param in the URL then all of the GWT applications on the page
will try to debug and will fail (because the debugger we have running only
has the source code for one of the applications in its classpath).
My goal is to update the implementation of the bootstrapping process for
dev mode to achieve the following:
1. Externalize the decision on which GWT applications on a page
should debug based on some other JS function that is resident on the page
so it can be controlled via a custom mechanism / server-side decision.
2. Have the ability to assign a custom $hosted URL (e.g.
localhost:9997) for each of the GWT applications on a page that should
be
debugging.
I have achieved the first goal by:
- Providing my own primary linker (an extension of the IFrameLinker)
that overrides the location of the selection script template so that it
uses my modified selection script
- Making my modified selection script provide a custom
isHostedMode() implementation that calls out to a JS function that is
resident on the host page for the decision of whether or not to go into
dev
mode:
function isHostedMode() {
$wnd.shouldDebug('__MODULE_**NAME__');
}
I thought I was close to achieving my second goal by:
- Using the same primary linker to override the hosted.html location
with my own custom hosted.html page.
- Making my hosted.html pickup the $hosted URL from a global var
resident in the host page instead of trying to pick it
Re: [gwt-contrib] Re: Steering committee meeting on GWT 3.0 IE Java compatibility
Okay, we previously talked about having some kind of deprecation policy and I'm fine with that; it seems a lot more limited in scope. I think a reasonable thing to do is to announce that we're dropping a browser version one release before it happens, so we should decide now about what we're going to do in the spring. We shouldn't say anything about what's going to happen next fall - we can decide that later. - Brian On Tue, Oct 8, 2013 at 6:03 PM, Jens jens.nehlme...@gmail.com wrote: Sounds to me that you suddenly start talking about feature guarantees for features that do not yet exist, e.g. supporting a new browser or a new HTML 5 API. That wasn't really my intention and maybe you misunderstood it. What I was talking about are guarantees about how long *existing* features will be supported. And by saying features I effectively meant 1.) Java Version requirements, separated in client + server, 2.) support of browsers, 3.) deprecated API. I think why you start talking about feature guarantees is mainly because of 2.) browser support. Of course a sentence like GWT always supports the latest two browser versions is not fully thought out and correct. It takes time to support a new browser version if there are a lot of changes involved. So such a sentence will be written in a way that does not guarantee a time frame for supporting new browsers. I am pretty sure I or others can write a clear text that everybody here can agree on about what GWT users will have to accept if they choose GWT without locking down the Google GWT team on forcing them to implement support for upcoming HTML 5 features or browsers or to force them to remove deprecated code. Instead such a text will help companies to define their own timelines (From now on we have x month to update our code / J2EE-Server/JVM otherwise its not guaranteed that we can upgrade to the newest GWT version once its released) and it will help companies to communicate browser support to their customers so that their customers also know what to expect (pretty useful for paid SaaS companies). It will also help the GWT team as they will clearly know when its safe to remove deprecated APIs (because users of GWT now know what to expect) and you are free to use newer Java syntax/features on server side once Oracle has released a new Java Version (because users of GWT now know what to expect). Of course time frames are never fully set in stone. For example if Oracle releases Java 9 a month before GWT 5.0 then GWT 5 should not switch from Java 7 to 8 as a server requirement as the time frame would be too short. So you may defer it x * 6 month. As a side note Google also has published browser support policies for their Google Apps in 2011, see http://googleenterprise.blogspot.de/2011/06/our-plans-to-support-modern-browsers.html -- J. -- 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. -- 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.
Re: [gwt-contrib] Re: Steering committee meeting on GWT 3.0 IE Java compatibility
On Tue, Oct 8, 2013 at 12:15 PM, Jens jens.nehlme...@gmail.com wrote: [...] since in practice we won't consider ourselves bound to them. Why not? Because we'll either we'll forget about that page due to turnover or something new will happen and priorities will change. Put it this way: how much do you feel bound by decisions made a few years ago by people who no longer work on GWT? - Brian -- 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.
Re: [gwt-contrib] Re: Steering committee meeting on GWT 3.0 IE Java compatibility
In practice on open source projects, things happen because some person or company volunteers to implement them and sees the project through to the end. So I don't really see steering committee schedule-making as a process that's going to work. The Google GWT team is going to set its own quarterly goals and everyone else is going to make their own decisions about what to work on too. And even if it could work, it's not a good idea. As a more recent example, I don't think we should still do Mavenization just because that's what we originally decided and there were slides at Google I/O to that effect. That's not a winning argument. We should fix the build process in the way that makes the most sense now. We're not doing GWT users any favors by making flat-out promises we won't necessarily keep. It's fair to say that there some things we have to do and supporting major browsers is certainly one of them. But if it's at all doubtful we should leave things open and it's a good idea to hedge. A good phrase to use is we don't have a crystal ball, but [...]. - Brian On Tue, Oct 8, 2013 at 2:02 PM, Thomas Broyer t.bro...@gmail.com wrote: But we now have a steering committee, and decisions are made in public so anyone can bug you when you forget. That's a different situation than before. Le 8 oct. 2013 22:43, Brian Slesinsky skybr...@google.com a écrit : On Tue, Oct 8, 2013 at 12:15 PM, Jens jens.nehlme...@gmail.com wrote: [...] since in practice we won't consider ourselves bound to them. Why not? Because we'll either we'll forget about that page due to turnover or something new will happen and priorities will change. Put it this way: how much do you feel bound by decisions made a few years ago by people who no longer work on GWT? - Brian -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to a topic in the Google Groups GWT Contributors group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/GO4iP9RkxQY/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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. -- 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.
Re: [gwt-contrib] Re: Maven-ization Status
I haven't tried it, but it says here that Gradle has support for publishing to Maven: http://www.gradle.org/docs/current/userguide/publishing_maven.html On Sat, Sep 28, 2013 at 10:49 PM, Cristiano Costantini cristiano.costant...@gmail.com wrote: Hello, What do you think of having gradle (or something else) generating the pom.xml files? I was thinking that as an approach to mavenizzation... I'll try to elaborate more this concept if my laptop battery last enough. Cristiano Il giorno domenica 29 settembre 2013, Ray Cromwell ha scritto: Here's a commit on my private fork containing the gradle stuff https://github.com/cromwellian/gwt-sandbox/commit/8f26f05d78109d0d9a91871df9102c0b461bef90 On Sat, Sep 28, 2013 at 3:59 PM, Thomas Broyer t.bro...@gmail.comwrote: On Sunday, September 29, 2013 12:11:29 AM UTC+2, Ray Cromwell wrote: I bit the bullet and came up with a set of gradle files that can generate IDEA projects which successfully import and then allow you to build dev/user in the IDE and launch compilation of the samples. It's non-ideal because the builtin IDEA support for importing gradle projects doesn't give enough control (need to add Java source to class path but exclude it from javac compile) However, running gradle idea generates the proper files from the command line and you just open them. And now I regret not having (seriously) looked at Gradle before ;-) IIUC, thanks to the Ivy backend, we could even remove the need to checkout the tools from SVN, and simplifying dependency management at the same time; with a combination of client module dependencieshttp://www.gradle.org/docs/current/userguide/dependency_management.html#sub:client_module_dependencies and an Ivy repository with custom patternshttp://www.gradle.org/docs/current/userguide/dependency_management.html#N14ECC; maybe not worth the effort if we want to stop bundling our dependencies in the JARs (they'll have to be deployed to some Maven repo –Central– to support Maven). I'm gonna work on adding support for building and running unit tests and adding SuperDevMode launch rules, then I'll put it up for review. Would you mind publishing what you have already? (publish as a draft –refs/drafts/master instead of refs/for/master– and add me as a reviewer if you don't want to publicize it yet) I'm curious how well Gradle will handle the fact that gwt-dev tests require gwt-user.jar (and includes the sources of the HelloWorld sample, but that's easy) Eclipse users will have to figure out their own gradle magic. ;-p I'll have a look at it then (yep, still mostly an Eclipse user) -- 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. -- 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. -- 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. -- 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.
[gwt-contrib] meeting notes for September 25
September 25, 2013 - Hangout on air today - Matt shared the GWT 2.6 release plan (dochttps://docs.google.com/a/google.com/document/d/1ZdMwcTjc4rkWg6nntCY1BDB1xI2PHPwaCnTYw-9uAKE/edit ) - feature-complete November 4th. Release on December 2. - Bhaskar: which features? - Separate compilation: experimental at best; overly ambitious. - IE10 support? Seems important. - IE6/7? Deprecate, but make sure people can still use it. - Devmode? Need to deprecate because Chrome is dropping NPAPI, Firefox could break at any time. - SuperDevMode? Talked about IDE support. Not fast enough; would be good at least get separate compilation in, perhaps as experimental. - Brian and Ray: maintaining Eclipse has been a hassle in the past. Ray: we should keep the Eclipse plugins decoupled from GWT releases so that we don't have to do a new release with each GWT release. - Goktug: SuperDevMode is better than DevMode for me today. - Bhaskar: I thought Dart had some Eclipse code. Brian: they do but someone still has to maintain the plugin. - Ray: implemented the first part of JsInterop spec. Seems to be working well so far. Turning on exports by default would result in code bloat; need some user controls to trim that down; don't want to export dependencies. Goktug: how does this work with JSO's? Ray: if the JsInterface doesn't have a prototype it can be cross-cast to anything. But if it has a prototype then it can't. Tricky logic. Ray: ran into issues with subclassing; if you subclass then you're forced to implement everything; this prevents calling the prototype method via super. - Colin's feedback: - Still need devmode for IE. Brian: don't know status of sourcemaps on IE. We can keep it for IE for now but support for JsInterop will be hard. - What about code coverage? Brian: We need web mode code coverage to replace Emma. A patch landing soon that might help. Ray: will respond in the review; it's not pluggable enough. - Better typed array support in 2.6? Brian: concerned about enabling it by default until we have more experience. Ray: we can have a compiler flag; experimental feature? Most permutations can use it. - Daniel has a fix for type checks on array stores (still on when checking is off). Will result in a big speedup for arrays. - John: has a feature-complete prototype that mostly works; now time to clean up. Generators need to be configured based on how local they are. Wants to change GWT-RPC generator to generate code from a whitelist for which types can be used for separate compilation. Ray: how do entry points work? John: currently modified existing entry points; need to revisit this. -- 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.
Re: [gwt-contrib] Re: Maven-ization Status
On Thu, Sep 26, 2013 at 10:26 AM, Jens jens.nehlme...@gmail.com wrote: In terms of Gradle vs Buck models, is there any possibility of writing a tool that takes a Buck build file and produces Gradle files? That would seem like a good option in lieu of waiting for Buck support in IntelliJ and Eclipse. This isn't to say I have anything against Buck, it is literally a clone of Google's BUILD system, and so that would actually help us to have just one set of build files for internal vs external. However, it would be nice not to have to hack the IDE stuff manually. If Buck is like Google's BUILD, then a genrule could be used to download dependencies from Maven repos. ;-) Shouldn't it be the other way around? A Gradle plugin that generates Google build files sounds more logical to me as you have more freedom to adjust the generated files to your internal system. Outside Google no one will really use these buck/internal build scripts anyways (lack of IDE support). I don't think direct IDE support for the build system is necessary so long as we can generate correct IDEA and Eclipse projects via commands that everyone can run, sort of like the webAppCreator command. The real question is what language we want the project definitions to be in; it should be something easy to understand, edit, and generate other representations from. -- 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.
Re: [gwt-contrib] Re: Maven-ization Status
I skimmed the Gradle manual and it looks pretty decent. While the syntax and terminology is different, it looks like the concepts map back to stuff I'm already comfortable with. It has tasks which are basically build rules which are configured via Groovy (instead of Python macros). The tool builds and executes a dependency graph, and you can look at the dependency graph before running it. There is a dependency cache and it sounds like they care about both avoiding duplicate work and reproducible builds. It has Maven and Ant compatibility without actually being Maven or Ant. Also, Android is standardizing on it which is a plus. Here's a good place to start reading: http://www.gradle.org/docs/current/userguide/tutorial_using_tasks.html - Brian On Thu, Sep 26, 2013 at 5:12 PM, Cristiano Costantini cristiano.costant...@gmail.com wrote: Il giorno venerdì 27 settembre 2013, Goktug Gokdogan ha scritto: I have been in favor of Buck because that is what most contributors are already familiar with and can bring their expertise. This is a good point which need to be taken into account. But I've found frustrating buck cannot be built on windows, and no binaries are provided. Also, it required me to upgrade to JDK 7 on the mac before I can start to try building GWT... If this is the way to start with contributing to GWT it could be a limitation... -- 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. -- 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.
Re: [gwt-contrib] Re: Maven-ization Status
As a stop-gap measure, can you clean up and check in your IDEA module(s)? - Brian On Wed, Sep 25, 2013 at 9:20 AM, Ray Cromwell cromwell...@google.comwrote: The biggest problem with being a GWT contributor today is that it is hard, very hard, to set up an environment to develop. If you look at the original GWT instructions for Eclipse, and that was *with* already provided .project/.classpath files, it was ridiculous. Starting from scratch is even harder. My dream for mavenization was a) fixing the spaghetti soup of cyclic dependencies so that IDEs would have less trouble modeling the project layout b) having a cross IDE platform representation of the project The way GWT exists today, after years of working with it, requires me to spend over an hour configuring a new IntelliJ project from scratch if I want to do it right, be able to develop both user and dev, be able to run unit tests in the IDE, be able to debug the compiler in the IDE, etc. Ant is fine for command line builds, but it sucks for a) and b), and its flexibility has allowed the GWT source tree to have a structure that would not be tolerated by other build tools -- sometimes too much power is bad. I don't have any particular love for Maven, I'd be fine with Buck or Gradle (IntelliJ seems to have some support for Gradle), but the biggest issue for me is, I don't want to spend an hour fiddling with IDE sub-projects, hand-adding library dependencies (oh wait, which project needs tomcat-jk2.jar?), etc. Even on the GWT team at Google, members have taken to rather absurd techniques like creating one working set of IPR/IML files, and copy/pasting them everytime you start a new repository or branch because they have often forget the precise order of magic tricks they used to set up the build the first time. IMHO, here should be how someone contributes to GWT: git clone http://some-repo IDE open-project some-repo git branch hack hack hack run tests/debug in IDE git commit git push Any more steps than that and I think you've lost. On Wed, Sep 25, 2013 at 1:32 AM, Thomas Broyer t.bro...@gmail.com wrote: On Wednesday, September 25, 2013 9:52:25 AM UTC+2, Cristiano wrote: Hi Thomas, I'm (part-time) having a look at your gwt-sandbox with maven build; I like the way it is modularized: gwt-dev-parent gwt-jsni-parser gwt-util-parent gwt-shared gwt-tools-api gwt-dev-json gwt-dev-ext gwt-user-parent gwt-core-shared gwt-core-client gwt-compiler gwt-maven-plugin gwt-regexp-server gwt-http gwt-safehtml-server gwt-codegen gwt-jetty-launcher gwt-devmode gwt-codeserver gwt-i18n-shared gwt-i18n-server gwt-core-server gwt-regexp-client gwt-bindery-parent event event-gwt gwt-event-shared gwt-event-client gwt-event-logical-shared gwt-event-logical-client gwt-safehtml-client gwt-dom gwt-i18n-client gwt-rpc-shared gwt-rpc-api gwt-rpc-client gwt-rpc-server gwt-browsermanager gwt-resources-core gwt-window gwt-timer gwt-junit gwt-jsonp gwt-resources gwt-mockutilities gwt-safecss-server gwt-safecss-client autobean-shared autobean-vm autobean-gwt gwt-user requestfactory-shared requestfactory-client requestfactory-server requestfactory-gwt requestfactory-apt gwt-dev gwt-user gwt-codeserver gwt-legacy-parent I think it is a very precious piece of work! The build process fails however in resolution of a pugin, com.google.gwt.maven:gwt-**maven-plugin:jar:2.6.0-**SNAPSHOT but it is not the org.codehaus.mojohttp://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.codehaus.mojo%22 :gwt-maven-**plugin:jar:2.6.0-SNAPSHOT is that the one at https://github.com/tbroyer/**gwt-maven-pluginhttps://github.com/tbroyer/gwt-maven-plugin ? No, it's the modulemaven/module. It's a snapshot/copy of the one linked above. I don't like that it is still required to have the gwt-tools in the environment path; This is a temporary step in the migration process. The goal is to migrate to non-patched/non-repackaged dependencies whenever possible, and deploy the third-party deps on Central otherwise. referring to the your post ;-) for me the ultimate build tool is the one that allow you to build a project in two steps: [me@host]# ultimate-scm checkout http://my.project.org/source_**codehttp://my.project.org/source_codetrunk [me@host]# ultimate-build-tool build trunk having to configure gwt-tools it is out of my ideal way of building a project: I don't know if it possible, but gwt-tools should be mavenized too in my opinion. Many libs found inside the gwt tools are available as maven artifacts in Maven Central Repo (for stability, I always try to avoid referring dependency not found on http://search.maven.org/) but this may require Later I also want to try out your buck build files at https://gwt-review.**googlesource.com/3741https://gwt-review.googlesource.com/3741 , (if I find out how the command line options to apply the patch
Re: [gwt-contrib] Possible firefox leak fix
+cromwellian since he did unload support.
Oops, I see now that you attached it. Could you upload it to Gerrit?
I looked pretty hard for a reason why it's window.onUnload and not
window.onload and I can't find any. It dates back to 2010 at least and was
copied from hosted.html, whether deliberately I don't know.
One issue is that it's possible the app itself might want an onunload
handler. See
user/src/com/google/gwt/user/client/impl/WindowImpl.java line 32 where it
can install an onunload handler. It does preserve the old one but it still
seems kind of fragile to install one in the devmode.js. I wonder if there's
some way to detect the unload event in C++?
- Brian
On Tue, Sep 24, 2013 at 5:25 PM, Colin Alworth niloc...@gmail.com wrote:
The patch I provided only tweaks the normal source, and leaves the
generated sources and binaries alone - I think that is already what you are
after.
Note that this does *not* stop the leak by itself - we need to decide what
to do about hosted.html/devmode.js. One (ugly) option is to try to have the
ff plugin add an event handler to the window's close to call back to its
own disconnect? I think there are other ways we could think about doing
this as well, but changing hosted.html keeps it consistent across the board.
On Tuesday, September 24, 2013 6:50:07 PM UTC-5, Brian Slesinsky wrote:
Hi,
Wow, thanks for tracking this down! Could you send a patch that just
modifies the source (not worrying about the autogenerated files)? I will
rebuild them when I do the next release.
Usually I just leave the existing dll's alone and move forward; it's not
worth fixing older plugins. However, I believe Firefox 24 will be an ESR
release so I think it's worth rebuilding that version.
On Tue, Sep 24, 2013 at 4:31 PM, Colin Alworth nilo...@gmail.com wrote:
I spent a little time this weekend learning how to build firefox
plugins, and a little time spilled out into this week, but I think I'm at a
point where I can share what I've done, what I'm seeing, and start asking
for help to finalize this (if it is as meaningful as I hope it is).
First, the issue itself: It looks like we're actually leaking on both
ends - that is, not just in the JVM, but in the browser itself. When Dev
Mode transfers control back to the browser itself, it runs
BrowserChannelServer.**reactToMessages(). This listens at the open
socket between the browser's plugin and itself, and waits for the next byte
to float over the wire, meaning that the browser wants something. This
waiting specifically happens in Message.readMessageType, where we block on
stream.readByte(). Once a tab/window has been closed, the thread that is
actively watching that connection stays stuck in readByte(), waiting for
that next message to float over the wire.
My first thought was why can't we just ask if that socket is closed? -
well, the socket *isn't* closed, which means that the browser is leaking
the socket itself, along with whatever supporting objects were set up to
manage that socket. Note that this suggests a workaround to the leak - quit
and relaunch firefox, and since the socket will be forcibly closed then,
readByte() will throw a EOF exception, and reactToMessages will trip off a
RemoteDeathError (not ideal, but at least it just logs it and moves on,
finishing the leak off).
Next I dug into how to make the plugin actually disconnect when the page
was closed. I started this by finding exactly where the socket was opened
(common/HostChannel.{h|cpp}), then what creates HostChannel objects in the
firefox plugin. This turns out to be achieved in this line in
xpcom/ExternalWrapper.cpp (plus instructive comments):
// TODO(jat): leaks HostChannel -- need to save it in a session object
and
// return that so the host page can call a disconnect method on it at
unload
// time or when it gets GC'd.
HostChannel* channel = new HostChannel();
Okay, so at the time it was written, it was known that this leaks the
channel. This is where I started losing confidence, as it doesnt look like
it could be this easy... The next block actually opens the connection, and
passes it off to a FFSessionHandler instance, which is stored away in a
field:
Debug::log(Debug::Debugging) Connecting... Debug::flush;
if (!channel-connectToHost(**hostPart.c_str(),
atoi(portPart.c_str( {
*_retval = false;
return NS_OK;
}
Debug::log(Debug::Debugging) ...Connected Debug::flush;
sessionHandler.reset(new FFSessionHandler(channel/*, ctx*/));
All this code is part of ExternalWrapper::Connect (note, defined twice
for varying ff versions), and since Connect is never invoked internally, it
was my assumption that I could build a ExternalWrapper::Disconnect that
simply unwound this channel:
NS_IMETHODIMP ExternalWrapper::Disconnect() {
Debug::log(Debug::Info) Disconnecting... Debug::flush;
sessionHandler.get()-**disconnect();
Debug::log(Debug::Info
[gwt-contrib] Google team meeting notes for September 18 and September 11
September 18, 2013 Talking about Q4 goals: * Separate compilation: more people to help John? How to divide the work? Java / JavaScript integration: Ray says he's going to be working on this for Q4, along with Closure compiler integration. * SuperDevMode: fast compile cycles is most important. Brian: got experimental debugger working with Showcase; going to look again at Eclipse plugin. Ray: wrote a servlet to integrate with SuperDevMode so it's always on for dev server. Maybe create a common Super Dev Mode servlet? Performance dashboard (Daniel's project) * Open source: 2.6 Release (Matthew); Hangout next week. * Goktug: want to work on Gin improvements. (Shouldn't take a lot of time.) * More resources on deprecation cleanup? Brian: Matthew doing a great job, continue as-is? Maybe do more in Q1. * John's status: half the generators depend on property values; will have to re-run in each Library when properties change. GWT-RPC generator will need to be global. Ray: maybe CompilationStateBuilder should start with entry points? John: looks like it would be 20% gain. Ray: cheap pruning pass in UnifyAST? Roberto: already happens pretty early. Ray: reports about unused files? Roberto: made some but not useful so far. Brian: intern starting on Sept 30 who will be working on soyc reporting. Talked about what he could do. * Goktug: HTMLUnit upgrade is about ready. Not submitting because HTMLUnit is about to do a release so he will wait and pick that up. * Ray: has a patch to watch filesystem in Super Dev Mode. Brian: great, send it to me. September 11: - Goktug: GWT incubator needs be officially deprecated and removed 400 references to incubator. - Brian's debugger demo: (An alternate Chrome debugger frontend written in Dart; testbed for experiments.) Ray: Nodeclipse looks interesting. (Fork of Chrome's Eclipse plugin) - Daniel talked about opportunities for making GWT run faster on V8. Need to avoid changing object shapes. Lazy initialization is an issue. Ray: maybe revert to the old way of doing it? However we need to avoid increasing code size; for example, using any DOM method once pulled in the whole implementation. Brian: put lazy initialized fields in a sub-object? - Roberto talked about code-splitting Fixed a bug in Codesplitter v1 (which most people are using). v2 is less correct than v1 because it's missing some JavaScript-level dependency fixups. Refactoring the common code that will also be used for v3. Goktug and Ray: we also need a way for developers to manually force a splitpoint. -- 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.
[gwt-contrib] Google team meeting notes for September 4, August 28, August 21
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.
Re: [gwt-contrib] gwt.junit.testcase.includes broken?
Hi, my guess is that it's just an oversight; at Google we have our own build stystem so we don't use the ant scripts all that often. If you want to dive in, I'd be interested in what you find. - Brian On Sat, Aug 31, 2013 at 2:33 PM, Daniel Trebbien dtrebb...@gmail.comwrote: Hi, I am trying to run only the I18NSuite tests in user/test/com/google/gwt/i18n/I18NSuite.java but I am finding that gwt.junit.testcase.includes is no longer working. This used to work: ant -Demma.enabled=false '-Dgwt.junit.testcase.includes=**/I18NSuite.class' test but now this runs all of the tests instead of just the tests in I18NSuite. I also tried adapting the command line mentioned in the thread How to run a single test ?https://groups.google.com/d/topic/google-web-toolkit-contributors/RSPG_158Y6c/discussion, but all of the tests for the user subproject are still run. Was support for gwt.junit.testcase.includes removed? Daniel -- 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. -- 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.
Re: [gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
Thanks for looking into how to improve Java stack traces. I agree that we could do a better job. However, there are some problems with your approach: First of all, we can't guarantee that we will accept this change. That doesn't seem very fair to whoever might be donating money. I would like to make sure we come up with a solution taking the best features of everyone's ideas, while remaining as simple as possible. See the discussion about GWT.create() improvements for an example. So the final result will likely be modified and include ideas from multiple contributors, though course the person who volunteers to do most of the work often has the largest influence. And simple patches aren't a solo effort because someone has to review them and try them out. With a project as complex and widely used as GWT, the drawbacks to a change may be unexpected. It's unfortunate, but we often find that after committing a change to Google's codebase, we discover problems that nobody thought of in review and we not caught by GWT's own tests. It's much easier to test a change if it's broken up into smaller patches. So if possible it's best to split up a larger feature into smaller patches and consider each of them on their merits. For example, if some things are just bug fixes, we should review and commit them separately. This is often a good way to get started in the community - before trying something large, fix simpler bugs. This gives us a chance to get to know your work through smaller and less risky changes, and you'll likely learn things along the way. Resist the urge to add more features since that makes a change riskier and harder to get agreement on. - Brian On Mon, Aug 19, 2013 at 1:06 PM, Alex Epshteyn alexander.epsht...@gmail.com wrote: Hello folks, I just wanted to remind everyone that the last day to fund this project is this Friday, August 23. I've been using this framework in production in my app now for 2 months, and it works great. Have logged 70,000 perfect stack traces so far! Already fixed 3 major bugs in my GWT-based UI code that I would NEVER found otherwise. Let's get this capability into GWT by the end of the year. Please donate! Thanks, Alex On Wednesday, July 17, 2013 4:56:40 PM UTC-4, Alex Epshteyn wrote: Dear fellow GWT users, I would like to announce that I have finally solved what I always thought to be GWT's greatest weakness: its lack of debugging information for client-side exceptions in production. With my patch, your deployed app will be able to report stack traces like this: com.google.gwt.core.client.**JavaScriptException: (TypeError) : a is null com.google.gwt.dom.client.**DOMImplMozilla.$**getBodyOffsetLeft(** DOMImplMozilla.java:145) com.google.gwt.user.client.ui.**PopupPanel.$setPopupPosition(** Document.java:1287) com.google.gwt.user.client.ui.**PopupPanel.setPopupPosition(** PopupPanel.java:884) com.google.gwt.user.client.ui.**PopupPanel.PopupPanel(** PopupPanel.java:453) com.typeracer.commons.client.**widgets.EnhancedPopup.** EnhancedPopup(EnhancedPopup.**java:32) com.typeracer.commons.client.**widgets.PopupWithIcon.**PopupWithIcon(** PopupWithFocusableTextBox.**java:28) com.typeracer.main.client.**controller.**TyperacerUncaughtExceptionHand** ler$1.execute(**TyperacerUncaughtExceptionHand**ler.java:55) com.google.gwt.core.client.**impl.SchedulerImpl.**runScheduledTasks(** SchedulerImpl.java:50) etc... :-) instead of the current state of affairs that looks like this: lineNumber: 3190 columnNumber: 15354: a is null; (TypeError) fileName: http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**B8.cache.htmlhttp://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html stack: @http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3** B8.cache.html:2422http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2422 Rub@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3** B8.cache.html:2423http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2423 dSb@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3** B8.cache.html:3190http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:3190 tA@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3** B8.cache.html:2810http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2810 Xmb@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3** B8.cache.html:2289http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2289 etc... :-( I am asking the community to support me in finishing this effort and integrating my patch into GWT. Please take a look and what I've done, and consider making a donation: http://igg.me/at/gwt-stack-**traces/x/3494291http://igg.me/at/gwt-stack-traces/x/3494291 I am an indie developer and I just need some funding to continue this work. I'm looking for both grassroots and corporate sponsorship for my quest of improving GWT's error reporting and debugging support. I've
Re: [gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
Thanks for looking into how to improve Java stack traces. I agree that we could do a better job. However, there are some problems with your approach: First of all, we can't guarantee that we will accept this change. That doesn't seem very fair to whoever might be donating money. I would like to make sure we come up with a solution taking the best features of everyone's ideas, while remaining as simple as possible. See the discussion about GWT.create() improvements for an example. So the final result will likely be modified and include ideas from multiple contributors, though course the person who volunteers to do most of the work often has the largest influence. And simple patches aren't a solo effort because someone has to review them and try them out. With a project as complex and widely used as GWT, the drawbacks to a change may be unexpected. It's unfortunate, but we often find that after committing a change to Google's codebase, we discover problems that nobody thought of in review and we not caught by GWT's own tests. It's much easier to test a change if it's broken up into smaller patches. So if possible it's best to split up a larger feature into smaller patches and consider each of them on their merits. For example, if some things are just bug fixes, we should review and commit them separately. This is often a good way to get started in the community - before trying something large, fix simpler bugs. This gives us a chance to get to know your work through smaller and less risky changes, and you'll likely learn things along the way. Resist the urge to add more features since that makes a change riskier and harder to get agreement on. - Brian On Mon, Aug 19, 2013 at 1:06 PM, Alex Epshteyn alexander.epsht...@gmail.com wrote: Hello folks, I just wanted to remind everyone that the last day to fund this project is this Friday, August 23. I've been using this framework in production in my app now for 2 months, and it works great. Have logged 70,000 perfect stack traces so far! Already fixed 3 major bugs in my GWT-based UI code that I would NEVER found otherwise. Let's get this capability into GWT by the end of the year. Please donate! Thanks, Alex On Wednesday, July 17, 2013 4:56:40 PM UTC-4, Alex Epshteyn wrote: Dear fellow GWT users, I would like to announce that I have finally solved what I always thought to be GWT's greatest weakness: its lack of debugging information for client-side exceptions in production. With my patch, your deployed app will be able to report stack traces like this: com.google.gwt.core.client.**JavaScriptException: (TypeError) : a is null com.google.gwt.dom.client.**DOMImplMozilla.$**getBodyOffsetLeft(** DOMImplMozilla.java:145) com.google.gwt.user.client.ui.**PopupPanel.$setPopupPosition(** Document.java:1287) com.google.gwt.user.client.ui.**PopupPanel.setPopupPosition(** PopupPanel.java:884) com.google.gwt.user.client.ui.**PopupPanel.PopupPanel(** PopupPanel.java:453) com.typeracer.commons.client.**widgets.EnhancedPopup.** EnhancedPopup(EnhancedPopup.**java:32) com.typeracer.commons.client.**widgets.PopupWithIcon.**PopupWithIcon(** PopupWithFocusableTextBox.**java:28) com.typeracer.main.client.**controller.**TyperacerUncaughtExceptionHand** ler$1.execute(**TyperacerUncaughtExceptionHand**ler.java:55) com.google.gwt.core.client.**impl.SchedulerImpl.**runScheduledTasks(** SchedulerImpl.java:50) etc... :-) instead of the current state of affairs that looks like this: lineNumber: 3190 columnNumber: 15354: a is null; (TypeError) fileName: http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**B8.cache.htmlhttp://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html stack: @http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3** B8.cache.html:2422http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2422 Rub@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3** B8.cache.html:2423http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2423 dSb@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3** B8.cache.html:3190http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:3190 tA@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3** B8.cache.html:2810http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2810 Xmb@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3** B8.cache.html:2289http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2289 etc... :-( I am asking the community to support me in finishing this effort and integrating my patch into GWT. Please take a look and what I've done, and consider making a donation: http://igg.me/at/gwt-stack-**traces/x/3494291http://igg.me/at/gwt-stack-traces/x/3494291 I am an indie developer and I just need some funding to continue this work. I'm looking for both grassroots and corporate sponsorship for my quest of improving GWT's error reporting and debugging support. I've
Re: [gwt-contrib] Initial support for @GwtCreate (code-gen methods)
Interesting. I like the idea of replacing class parameters with something
else. I'm not sure we need to sweep the implementation under the rug.
Particularly in fancier scenarios, it might be easier to work with it
explicitly.
Suppose we have:
/** Encapsulates a GWT create call. */
interface CreatorT {
Class? getClassLiteral();
ListObject getArgs();
T get();
}
public class GWT {
...
/** Performs a GWT.create() call an encapsulates the result. */
final T CreatorT creator(Class? classLiteral, Object... args);
}
Then you can write code that takes a Creator:
MyService s = createService(GWT.creator(MyService.class), arg);
static S extends FooService S createService(CreatorS creator, String
arg) {
S s = creator.get();
// do some initialization involving arg.
return s;
}
This is how you write it without any compiler magic. But we would also
support using a bare class:
MyService s = createService(MyService.class, arg);
static S extends FooService S createService(@Creator final ClassS
theClass, String arg) {
S s = GWT.create(theClass);
// do some initialization involving arg.
return s;
}
The compiler rewrites any Class arg marked as @Creator to actually take a
Creator, inserts the GWT.creator() call at the call site, and replaces the
GWT.create() call with a creator.get() call in the API. So we have compiler
magic to make the API look pretty for simple cases, but it's not strictly
necessary since you could write the same thing yourself (at the cost of
some verbosity).
(I bundled the arguments along with the class since that seemed like the
most conservative approach. I'm not sure what happens if you have
compile-time arguments coming from the different places than the class
itself.)
- Brian
On Fri, Aug 16, 2013 at 2:22 AM, Andrés Testi andres.a.te...@gmail.comwrote:
I've been working on a prototype inspired by Ray Cromwell's proposal for
@GwtCreate parameters, borrowing some ideas from Scala implicit macros. I
apologize for not to post this in the Possible GWT.create() Improvements
thread, but this message is too long to be only a comment.
You can check my patch at https://gwt-review.googlesource.com/4110. This
prototype has passed many JUnit tests cases and works fine (only fails
JEnumTypeTest after my last pull, I don't know why). Devmode also works.
This proposal differs from Ray's original idea in that @GwtCreate is a
parameter annotation instead of a method annotation. Later I will justify
this decision.
This new proposal consists on rewriting methods adding a trailing implicit
parameter of type GwtCreateFactory for each parameter annotated with
@GwtCreate. GwtCreateFactory is a hidden interface used by the compiler:
interface GwtCreateFactory {
T T create();
}
When the compiler finds a code-gen method like
Foo createFoo(@GwtCreate final Class? extends Foo fooType) {
return GWT.create(fooType);
}
it is rewritten as
Foo createFoo(final Class? extends Foo type, GwtCreateFactory
fooType$factory) {
return fooType$factory.create();
}
IMPORTANT:
The @GwtCreate parameter requires to be final.
This proposal doesn't require constant evaluation expression. The
final modifier is required to disable non reproductible side effects.
At method call site, an invocation like
Foo foo = createFoo(SubFoo.class);
is rewritten as
class SubFoo$GwtCreateFactory implements GwtCreateFactory {
@Override public T T create() {
return GWT.create(SubFoo.class);
}
}
Foo foo = createFoo(SubFoo.class, new SubFoo$GwtCreateFactory());
Just like Scala implicit parameters, @GwtCreate can fight against type
erasure and subtyping
interface FooCreator {
T extends Foo T create(@GwtCreate ClassT fooType);
}
class FooCreatorImpl extends FooCreator {
T extends Foo T create(@GwtCreate final ClassT fooType) {
return GWT.create(fooType);
}
}
code-gen constructors are supported too
class CreateByConstructorT extends Foo {
final T instance;
public CreateByConstructor(@GwtCreate final ClassT fooType) {
instance = GWT.create(fooType);
}
}
Again, as in Scala implicit parameters, nesting is allowed
class Foo {}
class SubFoo extends Foo {}
F extends Foo F createFoo(@GwtCreate final ClassF fooType) {
return GWT.create(fooType);
}
S extends SubFoo S createSubFoo(@GwtCreate final ClassS subFooType) {
return createFoo(subFooType);
}
The decision to locate @GwtCreate on parameters was taken to support mixed
code-gen methods
F extends Foo, B extends Bar
void fooBarCreator(@GwtCreate final ClassF fooType, @GwtCreate final
ClassB barType) {
foo = GWT.create(fooType);
bar = GWT.create(barType);
}
Note that the @GwtCreate class parameters aren't replaced by
GwtCreateFactory as was originally suggested by Ray Cromwell. This provides
access to actual parameters.
ClassT storedType;
T
Re: [gwt-contrib] Integrating Spiffy UI into GWT
It seems like a nice project, but integrating it into GWT will slow down both the GWT developers and the SpiffyUI developers a lot. There would have to be some pretty compelling reasons to do that. Otherwise, better to let them keep doing what they're doing, and let them ask for specific changes to GWT if there is something they need that can't be accomplished without our help. On Sun, Aug 11, 2013 at 11:12 AM, Rafiq Ahamed ra...@eitworks.com wrote: Dear folks, I have been a heavy GWT user for the past 4 years in a number of projects. I have used M-GWT and it is great as well. Even though, I like GWT/M-GWT, I dislike the usage of GWT RPC's. RESTFUL webservices integration is the way to go so that the server side can be anything including JSON style NoSQL databases such as Apache Solr or Apache CouchDB. In this context, I like SpiffyUI a lot. I think it would be a big mistake if we do not take the good things from SpiffyUI into GWT. Any thoughts? -- 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. -- 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.
Re: [gwt-contrib] Re: Google team meeting notes for August 7 (and earlier)
I did do some profiling and at the time it looked like a good 40% was spent in the JDT. It will depend on the app though; I'm not satisfied I understand the performance. I've built some infrastructure for collecting better performance metrics inside Google, but at the moment I've put that aside to work on features. On Sat, Aug 10, 2013 at 10:19 PM, Stephen Haberman step...@exigencecorp.com wrote: Hi Brian, Our plan is to make Super Dev Mode compile faster. Have you gotten to discovering what parts are the slow ones? - Stephen -- 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.
Re: [gwt-contrib] Possible GWT.create() Improvements (link)
2. IDE support: IDE can trigger codegen (esp. for debugging) My experience with this has been pretty poor, and running GWT with -gen is at least as useful. Also, Super Dev Mode gives you access to all the generated code. You can either use the browser's debugger with SourceMaps turned on (which also allows you to set breakpoints in generated code), or you can browse the source code directly on the codeserver. It would be nice if we somehow got this working with an IDE, though. - Brian -- John A. Tamplin -- 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. -- 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.
Re: [gwt-contrib] Possible GWT.create() Improvements (link)
Now that I understand it (hopefully), I think Ray's proposal is a good way to define new API's by writing Java wrappers that configure generated objects at runtime. Adding parameters to GWT.create() calls seems somewhat orthogonal as a way to pass arguments to generators at compile time. As often happens with language extensions, when you put them together, things get more complicated but also more expressive; if GWT.create() takes extra arguments then these should also be literals that you can accept in a user-defined create method. On Sat, Aug 10, 2013 at 12:35 PM, Andrés Testi andres.a.te...@gmail.comwrote: I miss this line in my dagger example: CoffeeApp coffeeApp = objectGraph.get(CoffeeApp.class); El sábado, 10 de agosto de 2013 16:23:50 UTC-3, Andrés Testi escribió: This reminds me a lot of Scala macros research. As you probably know, Scala solves code-gen issues with experimental support for several kinds of macros, distinguishing clearly between expression-level and type-level code generation/rewriting. APT covers only a fraction of type-level generation, while GWT.create() covers type-level and a little of expression-level rewriting. In standard JRE applications, expression-level is solved with runtime reflection, but in GWT, we must rely on GWT.create(). We always need expression-level handles to get access to the instances of the generated classes. Take a look at Dagger, injections are generated with APT (type-level) and expression-level handles are done with ObjectGraph by means of runtime reflection: // APT can't save us here, we need runtime reflection ObjectGraph objectGraph = ObjectGraph.create(new DripCoffeeModule()); APT and GWT.create() are complementary done the lack of runtime reflection support in GWT. In this sense, I think the Ray's proposal is a step forward. We can't get rid off GWT.create(), but we can hide it as possible from end users. Only API authors should treat with GWT.create(). El viernes, 9 de agosto de 2013 20:16:55 UTC-3, Goktug Gokdogan escribió: I think in the long-run we should separate the two concepts that is being tackled by GWT.create today. First purpose is the class replacement, especially used by permutations. I think this one should not have anything to do with GWT.create. We can do any class replacement in compiler without requiring a call to GWT.create. This is similar to super-sourcing and can be solved similar and perhaps together. Second purpose is for triggering generators and what most of the proposal are about. As Roberto and perhaps others have been bringing up, it is best to follow regular java code generation practices in GWT. That means for the long-term we can mostly rely on AnnotationProcessors. There are many advantages of that: 1. Not GWT only - continue sharing code with server (JRE), client(GWT) and mobile(Android). 2. IDE support: IDE can trigger codegen (esp. for debugging) 3. Parallelizing the compilation and ease moving from JDT into java 8 compiler plugin. 4. Reusing knowledge from java world and lower the barrier for entry to generators. With that move, deferred binding definition for code generator can be just about providing the naming conventions such as class_name - class_name$Generated. Based on the rule, when the compiler sees GWT.create(A.class), it can be turned into new A$Generated() and expect the generated code to be there. The reason I'm bringing this up is; for any proposal I think it is best to keep it feasible w.r.t this aspect and not push us into a corner for the long run. On Fri, Aug 9, 2013 at 1:24 PM, Brian Slesinsky skyb...@google.comwrote: Hi, I've published a document [1] with my thoughts on some of the GWT.create() proposals. This doesn't cover everything we've discussed but I think it's a start. If you're on this mailing list you should be able to comment. - Brian [1] https://docs.google.com/**document/d/** 1MDqiBEMl7dylYliAceLBBxGFAlSvk**QB9b-kSlnKmZBk/edit?disco=** AGXMcRI#https://docs.google.com/document/d/1MDqiBEMl7dylYliAceLBBxGFAlSvkQB9b-kSlnKmZBk/edit?disco=AGXMcRI# -- http://groups.google.com/**group/Google-Web-Toolkit-**Contributorshttp://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+unsubscribe@** googlegroups.com. For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- 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
[gwt-contrib] Re: Google team meeting notes for August 7 (and earlier)
Our largest projects aren't using Super Dev Mode yet for the same reason - not fast enough yet. But it varies; we have a lot of smaller teams that like it. - Brian On Friday, August 9, 2013 1:56:13 AM UTC-7, Matic Petek wrote: Ray got automatic recompile working in Super Dev Mode for a Google team I would be nice to hear how this was done on such large projects as Google has. I try with out application (170k LOC of client code / GWT-RPC, etc.) and it took 2x-3x more time then DevMode. On Thursday, August 8, 2013 11:04:04 PM UTC+2, Brian Slesinsky wrote: I haven't been sending out emails for our meetings. Let's catch up: August 7th: - John got a hello world app running using separate compilation. We talked a bit about how it might get pulled back into GWT. - Brian: Firefox architecture changes may break the Development Mode plugin by the end of the year. (The ContextStack service went away [1] and word is that they will be making more architectural changes [2]. This isn't the end of Development Mode because we still have Chrome, but we should get moving on Super Dev Mode. - On the bright side, Firefox 23 has support for Source Maps. Need to try it out. - Brian will try out IntelliJ's support for Super Dev Mode. Also need to figure out Eclipse. - Need to look into support for variable names in Super Dev Mode. Ray: perhaps fix up pretty mode to work better? We can rename variables less often. - Fixing up stack traces is a project. We should save the original JavaScript exception and make sure that gets printed to the JavaScript console. Brian will start a design doc. - Talked about internal use of mgwt for mobile apps. - Need to figure out benefits of GWT.create() changes proposed by contributors. Concerned that it will prevent compiler improvements. [1] https://gwt-review.googlesource.com/#/c/3933/ [2] http://bholley.wordpress.com/2012/05/04/at-long-last-compartment-per-global/ July 31: - Deadline for GWT.create() talks coming up. Talked about plans. - Brian: GWT.log() works in Super Dev Mode; working on GWT.debugger(), Firefox plugin release. - John and Ray talked about incremental compilation - Matthew: Gerritt working again. - Ray got automatic recompile working in Super Dev Mode for a Google team - Talked about Goktug's JsInterop proposal [3]. Ray: Elemental would be a lot simpler. - Would it work with Dev Mode? Not optimistic. - Talked about Web Components. [3] https://docs.google.com/document/d/1tir74SB-ZWrs-gQ8w-lOEV3oMY6u6lF2MmNivDEihZ4/edit July 24: - Talked about providing a benchmark to the v8 team to improve GWT performance. - Talked about JsInterop proposal. - Talked about code generation bug [4] - Gerrit server was messed up. [4] https://code.google.com/p/google-web-toolkit/issues/detail?id=8284 July 17: - Talked about JSInterop. - Can GSS be separately compiled/changed without recompiling the whole app? Put this into the build-time improvement bucked. - Talked about GWT.create conference. - Roberto: fixed issues with field initialization; initial fragment may be smaller. - Mike Brock not at Red Hat; effect on steering committee? -- 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.
[gwt-contrib] Possible GWT.create() Improvements (link)
Hi, I've published a document [1] with my thoughts on some of the GWT.create() proposals. This doesn't cover everything we've discussed but I think it's a start. If you're on this mailing list you should be able to comment. - Brian [1] https://docs.google.com/document/d/1MDqiBEMl7dylYliAceLBBxGFAlSvkQB9b-kSlnKmZBk/edit?disco=AGXMcRI# -- 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.
Re: [gwt-contrib] Patch to support GWT.create(this.getClass())
I've published that doc here:
https://docs.google.com/document/d/1MDqiBEMl7dylYliAceLBBxGFAlSvkQB9b-kSlnKmZBk/edit?disco=AGXNBZg#heading=h.gks1bp7hz61l
To clarify, I'm not myself working on any GWT.create() enhancements, but I
thought it was worth documenting my concerns in greater detail rather than
just sending a -2. I think it's possible to improve GWT.create() but I want
to make sure we fully understand what we're getting ourselves into.
On Fri, Aug 9, 2013 at 1:57 PM, Ray Cromwell cromwell...@google.com wrote:
Andres,
You might want to wait a day or two. I think Brian started one by copy
and pasting your proposals and mine into a doc, it might be better for him
to make it public and we all hack on that.
On Fri, Aug 9, 2013 at 12:19 PM, Andrés Testi andres.a.te...@gmail.comwrote:
Ray:
I'm writing a design doc like Nextgen GWT/JS Interop, but for
Relaxation of GWT.create(). I don't know if there are previous official
efforts to bring something like this to life, but if so, I would like know
about similar experiences.
Is there a guideline for these kind of design doc? When I finish a first
document draft, I will share it.
Thanks!
- Andrés
El miércoles, 7 de agosto de 2013 14:31:01 UTC-3, Ray Cromwell escribió:
The annotations were also there to allow the compiler to do error
checking so that class-literal propagation was always possible. So if you
write a function foo(Class? klazz), that then calls GWT.create(klazz),
there will be a compile time error thrown if foo() is not called with a
literal, just like GWT.create(). This means that it will always be possible
to propagate the class literal from parameter to use.
On Wed, Aug 7, 2013 at 5:31 AM, Andrés Testi andres@gmail.comwrote:
Hi Ray. I would like to add your proposal to my patch and generalize
GWT.create() relaxation. I think your annotation @GwtCreate(generator=...)
would solve my problem with the GWT frameworks tendency to instantiate
everything with GWT.create() instead of new.
As Matt Mastracci proposed here https://groups.google.com/d/**
msg/google-web-toolkit-**contributors/_jf8vBC8QDI/**X9LDLTbqB64Jhttps://groups.google.com/d/msg/google-web-toolkit-contributors/_jf8vBC8QDI/X9LDLTbqB64J
a
better approach is to generate a GwtCreateFactory to replace @GwtCreate
Class fields and params.
I will elaborate a more advanced proposal with all of these in account.
Thanks!
- Andrés
El lunes, 5 de agosto de 2013 20:37:45 UTC-3, Ray Cromwell escribió:
Hey Andres, I haven't fully looked at this, but I'm overjoyed you're
working on it, and it seems promising. One thing you might want to do is
review one of my old proposals on allowing any method to delegate
parameters to GWT.create(), see here: http://timepedia.**blogspo**
t.com/2009/03/relaxing-**constra**ints-on-gwtcreate.htmlhttp://timepedia.blogspot.com/2009/03/relaxing-constraints-on-gwtcreate.html
I'm wondering if your work could be adapted to support this.
-Ray
On Mon, Aug 5, 2013 at 8:36 AM, Andrés Testi andres@gmail.comwrote:
Are there interest adding support for allowing
GWT.create(this.getClass()) invocations?
I wrote an experimental patch to support it, adding a few changes to
UnifyAst. I've added the patch as an attached file, because I don't have
yet a CLA (I know this is not the right way to proceed).
There are many usecases for this feature, based in the super type
token pattern (http://gafter.blogspot.com.**ar**
/2006/12/super-type-tokens.**htm**lhttp://gafter.blogspot.com.ar/2006/12/super-type-tokens.html).
I've named this feature as Self Generated Objects (selfgen).
* Some use cases are:
-- Hide invocations to GWT.create()
-- Reduce boilerplate, minimizing the need of extend interfaces like
UiBinder, EditorDriver, etc..
Example, a custom composite :
abstract class UiBinderComposite extends Composite {
protected UiBinderComposite() {
UiBinderWidget, UiBinderComposite binder =
GWT.create(this.getClass());
initWidget(binder.**createAndBin**dUi(this));
}
}
// Usage:
@UiTemplate(mywidget.ui.xml)
class MyUiBinderWidget extends UiBinderComposite {
@UiField
Button clickMe;
}
-- Allow runtime type information on demand (Stroustrup’s
zero-overhead rule: “what you don’t use, you don’t pay for”) by means of
emulation of guava's TypeToken
Example:
abstract class TypeTokenT {
private final TypeInfoT typeInfo;
protected TypeToken() {
typeInfo = GWT.create(this.getClass());
}
...
}
// Usage
new TypeTokenListString(){}
* Implementation
To support this feature, my patch searchs for
GWT.create(this.getClass()) invocations, and replaces they with an
invocation to a syntetic method named this$create. This method is added
to
the current class, and is implemented for each non abstract subclass,
returning an invocation to GWT.create(currentClass).
* Problems found with this implementation:
-- Anonymous classes are hidden to
Re: [gwt-contrib] Nextgen GWT/JS Interop (Public) (google-web-toolkit-contributors@googlegroups.com)
It might be nice to be able to say that anything defined in a .d.ts can be imported into GWT. This will make it easier to work with JavaScript programmers since they don't have to write any Java code. So perhaps it's worth making sure that generating the Java interfaces from .d.ts files will work? I know that generating Elemental code from WebKit IDL files wasn't easy. However, our main use case is to import web components which are new. So my question is how likely people are to write .d.ts files for web components; I don't know if there is much overlap between those two communities yet. On Tue, Aug 6, 2013 at 3:02 PM, Goktug Gokdogan gok...@google.com wrote: Jon (Stalcup) just warned me that it may not necessarily orthogonal so I will make a clarification to what I said. There are number of reasons why it makes we sense to define the contract with java syntax and interface files for GWT (easy IDE support and JDT integration and developer familiarity etc.), but someone might have chosen to start with a custom syntax like the d.ts files. Assuming these interfaces exist and understood by the compiler, any other support can be built on top of that by generating them and provide a seamless integration. On Tue, Aug 6, 2013 at 1:25 PM, Goktug Gokdogan gok...@google.com wrote: We were planning to look into making integration seamless if closure type annotations exists but that's kind of orthogonal to this proposal. When we have that integration, it might not be hard to utilize typescript via typescript to closure conversion. Thanks for suggestion. On Tue, Aug 6, 2013 at 1:29 AM, Xavier Mehaut xavier.meh...@gmail.comwrote: Hi goktuk A nice way to interop with js is the way typescript does through the .d.ts files where js api is declared in a typed way, ensuring then the ability to interop with any preexisted js. Moreover, already existing .d.ts files for many js libraries exist on https://github.com/borisyankov/DefinitelyTyped No extra wirk to do then :) Best regards Xavier Envoyé de mon iPhone Le 6 août 2013 à 09:24, Goktug Gokdogan (Google Drive) gok...@google.com a écrit : I've shared an item with you. This is a design doc that describes a proposal for improving interoperability with GWT and javascript. The proposal provides some essential pieces to provide better and easier interoperability with JS while putting more complex scenarios (e.g. Web Components) and testability into account. Please take a look and provide us some feedback. Cheers, - Goktug [image: Document] Nextgen GWT/JS Interop (Public)https://docs.google.com/document/d/1tir74SB-ZWrs-gQ8w-lOEV3oMY6u6lF2MmNivDEihZ4/edit?usp=sharing Google Drive: create, share, and keep all your stuff in one place. [image: Logo for Google Drive] https://drive.google.com -- 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. -- 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. -- 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. -- 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.
[gwt-contrib] Google team meeting notes for August 7 (and earlier)
I haven't been sending out emails for our meetings. Let's catch up: August 7th: - John got a hello world app running using separate compilation. We talked a bit about how it might get pulled back into GWT. - Brian: Firefox architecture changes may break the Development Mode plugin by the end of the year. (The ContextStack service went away [1] and word is that they will be making more architectural changes [2]. This isn't the end of Development Mode because we still have Chrome, but we should get moving on Super Dev Mode. - On the bright side, Firefox 23 has support for Source Maps. Need to try it out. - Brian will try out IntelliJ's support for Super Dev Mode. Also need to figure out Eclipse. - Need to look into support for variable names in Super Dev Mode. Ray: perhaps fix up pretty mode to work better? We can rename variables less often. - Fixing up stack traces is a project. We should save the original JavaScript exception and make sure that gets printed to the JavaScript console. Brian will start a design doc. - Talked about internal use of mgwt for mobile apps. - Need to figure out benefits of GWT.create() changes proposed by contributors. Concerned that it will prevent compiler improvements. [1] https://gwt-review.googlesource.com/#/c/3933/ [2] http://bholley.wordpress.com/2012/05/04/at-long-last-compartment-per-global/ July 31: - Deadline for GWT.create() talks coming up. Talked about plans. - Brian: GWT.log() works in Super Dev Mode; working on GWT.debugger(), Firefox plugin release. - John and Ray talked about incremental compilation - Matthew: Gerritt working again. - Ray got automatic recompile working in Super Dev Mode for a Google team - Talked about Goktug's JsInterop proposal [3]. Ray: Elemental would be a lot simpler. - Would it work with Dev Mode? Not optimistic. - Talked about Web Components. [3] https://docs.google.com/document/d/1tir74SB-ZWrs-gQ8w-lOEV3oMY6u6lF2MmNivDEihZ4/edit July 24: - Talked about providing a benchmark to the v8 team to improve GWT performance. - Talked about JsInterop proposal. - Talked about code generation bug [4] - Gerrit server was messed up. [4] https://code.google.com/p/google-web-toolkit/issues/detail?id=8284 July 17: - Talked about JSInterop. - Can GSS be separately compiled/changed without recompiling the whole app? Put this into the build-time improvement bucked. - Talked about GWT.create conference. - Roberto: fixed issues with field initialization; initial fragment may be smaller. - Mike Brock not at Red Hat; effect on steering committee? -- 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.
Re: [gwt-contrib] Nextgen GWT/JS Interop (Public) (google-web-toolkit-contributors@googlegroups.com)
I think that's a good point; someone went through the trouble of creating these definition files so it would be nice to be able to use them, even without using TypeScript at all. (On the other hand, how many of those libraries would you say are relevant for GWT? I don't see us using backbone.) For Google, we would want a way to generate Java interfaces from JsDoc type declarations because that's what we use. Also, there may be legal issues using parts of TypeScript without the whole thing so someone would have to investigate that. On Thu, Aug 8, 2013 at 2:25 PM, Xavier Mehaut xavier.meh...@gmail.comwrote: I desagree with this assertion ; the goal is not to interop with ts, haxe, coffee, ..., but only with js. Moreover the future of js is ecmascript 6, so ts is a good candidate to express properly an interface; this is not the case IMO of a jsdoc like solution which is verbose and not so precise and concise as a true language. To finish, i recall in mind https://github.com/borisyankov/DefinitelyTyped as a reminder of the power of the d.ts technics Best regards Xavier Envoyé de mon iPhone Le 8 août 2013 à 22:39, Ray Cromwell cromwell...@google.com a écrit : As cool as I think TS is, there are far more lines of code out there in Js, some even with JsDoc type assertions, so I think the latter would be more useful as a first pass. JsDoc is comments so it works with existing JS. We could explore importing libraries defined in TS, Dart, haXe, et al via some kind of standard plugin extension. On Thu, Aug 8, 2013 at 9:08 AM, Brian Slesinsky skybr...@google.comwrote: It might be nice to be able to say that anything defined in a .d.ts can be imported into GWT. This will make it easier to work with JavaScript programmers since they don't have to write any Java code. So perhaps it's worth making sure that generating the Java interfaces from .d.ts files will work? I know that generating Elemental code from WebKit IDL files wasn't easy. However, our main use case is to import web components which are new. So my question is how likely people are to write .d.ts files for web components; I don't know if there is much overlap between those two communities yet. On Tue, Aug 6, 2013 at 3:02 PM, Goktug Gokdogan gok...@google.comwrote: Jon (Stalcup) just warned me that it may not necessarily orthogonal so I will make a clarification to what I said. There are number of reasons why it makes we sense to define the contract with java syntax and interface files for GWT (easy IDE support and JDT integration and developer familiarity etc.), but someone might have chosen to start with a custom syntax like the d.ts files. Assuming these interfaces exist and understood by the compiler, any other support can be built on top of that by generating them and provide a seamless integration. On Tue, Aug 6, 2013 at 1:25 PM, Goktug Gokdogan gok...@google.comwrote: We were planning to look into making integration seamless if closure type annotations exists but that's kind of orthogonal to this proposal. When we have that integration, it might not be hard to utilize typescript via typescript to closure conversion. Thanks for suggestion. On Tue, Aug 6, 2013 at 1:29 AM, Xavier Mehaut xavier.meh...@gmail.comwrote: Hi goktuk A nice way to interop with js is the way typescript does through the .d.ts files where js api is declared in a typed way, ensuring then the ability to interop with any preexisted js. Moreover, already existing .d.ts files for many js libraries exist on https://github.com/borisyankov/DefinitelyTyped No extra wirk to do then :) Best regards Xavier Envoyé de mon iPhone Le 6 août 2013 à 09:24, Goktug Gokdogan (Google Drive) gok...@google.com a écrit : I've shared an item with you. This is a design doc that describes a proposal for improving interoperability with GWT and javascript. The proposal provides some essential pieces to provide better and easier interoperability with JS while putting more complex scenarios (e.g. Web Components) and testability into account. Please take a look and provide us some feedback. Cheers, - Goktug [image: Document] Nextgen GWT/JS Interop (Public)https://docs.google.com/document/d/1tir74SB-ZWrs-gQ8w-lOEV3oMY6u6lF2MmNivDEihZ4/edit?usp=sharing Google Drive: create, share, and keep all your stuff in one place. [image: Logo for Google Drive] https://drive.google.com -- 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. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google
[gwt-contrib] Re: Google team meeting notes for August 7 (and earlier)
Our plan is to make Super Dev Mode compile faster. Plan B is to use an extended release of Firefox for a while. (I believe Firefox 24 is the next one.) Despite appearances, I'm not actually a C++ programmer and I'm not plugged into the Firefox community enough to know how realistic it is that it would break or what it would take to get working again. Unfortunately few people in the GWT community are interested in this level of advanced browser hackery, or the thread leak would be fixed by now. It's one of the reasons I wanted to avoid anything other than standard browser API's when writing Super Dev Mode. (The debugger API isn't really suitable because if we take it over for Dev Mode, there will be no way to attach a debugger to debug JavaScript.) - Brian On Thursday, August 8, 2013 3:55:26 PM UTC-7, Jens wrote: - Brian: Firefox architecture changes may break the Development Mode plugin by the end of the year. (The ContextStack service went away [1] and word is that they will be making more architectural changes [2]. This isn't the end of Development Mode because we still have Chrome, but we should get moving on Super Dev Mode. Would be good to know what may break means. How realistic is it? IMHO its one of the most important things to figure out asap. As an example: I am developing on Mac OS. Safari plugin is gone, as you stated Firefox is maybe gone by the end of year, Chrome is painfully slow compared to Firefox, SuperDevMode is not an option either for most apps out there (SDM takes ~40 seconds to recompile our app last time i tried it, and its not a really large app). So what should I use then? Thats not a nice situation to be in if Firefox will really break DevMode in the near future. Even today with Firefox the situation isn't great because this known memory leak when using FireFox + DevMode regularly drives me crazy. This all could easily become a real major issue among developers and their every days work. Maybe there are also other things to explore beside SDM. Random thoughts: Maybe its possible to provide a special Google Chrome build that is maybe not that secure but can execute DevMode freaking fast. What about remote connecting to Firefox/Chrome from the IDE? IntelliJ can do this already, maybe it can be used with GWT? Something like IntelliJ's LiveEdit but with GWT support would be so awesome. Maybe thats possible in combination with incremental compilation you mentioned above? -- J. -- 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.
Re: GWT DMP suddenly causing Firefox to crash
I just pushed out an update for Firefox 23 yesterday. Firefox 22 should have been unaffected (I didn't rebuild the Windows binary for 22) but perhaps something went wrong. For comparison, the previous release is here: https://dl.google.com/dl/gwt/plugins/firefox/1.22/gwt-dev-plugin.xpi But since Firefox 23 should be released today, it probably isn't worth spending much time figuring out what went wrong with Firefox 22. I'd recommend upgrading to Firefox 23 and trying it with the latest plugin. - Brian -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
Re: GWT DMP suddenly causing Firefox to crash
I am mystified. I've verified that there is no difference between the 1.22 and 1.23 xpi files except for bumping the version in install.rdf, modifying chrome.manifest to list the new libraries, and adding the new DLL for Firefox 23. Assuming I understand how chrome.manifest works, the new DLL shouldn't be used with Firefox 22. Nonetheless, I was able to reproduce the bug using Firefox 22. It doesn't happen with Firefox 23. On Tuesday, August 6, 2013 11:11:35 AM UTC-7, Brian Slesinsky wrote: I just pushed out an update for Firefox 23 yesterday. Firefox 22 should have been unaffected (I didn't rebuild the Windows binary for 22) but perhaps something went wrong. For comparison, the previous release is here: https://dl.google.com/dl/gwt/plugins/firefox/1.22/gwt-dev-plugin.xpi But since Firefox 23 should be released today, it probably isn't worth spending much time figuring out what went wrong with Firefox 22. I'd recommend upgrading to Firefox 23 and trying it with the latest plugin. - Brian -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Super Dev Mode: deemphasize unused Java lines in codeserver'...
Hello Matthew Dempsky, Leeroy Jenkins, I'd like you to reexamine a change. Please visit https://gwt-review.googlesource.com/3600 to look at the new patch set (#2). Change subject: Super Dev Mode: deemphasize unused Java lines in codeserver's UI .. Super Dev Mode: deemphasize unused Java lines in codeserver's UI Modified the code server to render Java files as HTML when browsing interactively. (JavaScript debuggers continue to load the plain text.) In the HTML, lines that make no contribution to the JavaScript according to the source map are greyed out. This implementation is pretty inefficient since we parse the entire source map on every html page load, but it seems to suffice. Change-Id: Id16bcd2287630cebf7afb8bbbe0a198b28f5ada9 Review-Link: https://gwt-review.googlesource.com/#/c/3600/ --- M dev/codeserver/java/com/google/gwt/dev/codeserver/HtmlWriter.java A dev/codeserver/java/com/google/gwt/dev/codeserver/ReverseSourceMap.java M dev/codeserver/java/com/google/gwt/dev/codeserver/SourceHandler.java M dev/codeserver/java/com/google/gwt/dev/codeserver/SourceMap.java 4 files changed, 142 insertions(+), 15 deletions(-) -- To view, visit https://gwt-review.googlesource.com/3600 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: Id16bcd2287630cebf7afb8bbbe0a198b28f5ada9 Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: John Stalcup stal...@google.com Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com -- 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.
[gwt-contrib] Change in gwt[master]: Super Dev Mode: deemphasize unused Java lines in codeserver'...
Brian Slesinsky has posted comments on this change. Change subject: Super Dev Mode: deemphasize unused Java lines in codeserver's UI .. Patch Set 1: (7 comments) File dev/codeserver/java/com/google/gwt/dev/codeserver/ReverseSourceMap.java Line 1: package com.google.gwt.dev.codeserver; Done Line 12: private final SourceMapConsumerV3 consumer; Not wild about it but I don't have a better name. Line 20:* If it can't be loaded, logs an error and returns null. Done Line 29: logger.log(TreeLogger.WARN, can't parse source map, e); This class is package-local and it's only used in one place, so I think it's okay to specialize it to make the calling code cleaner. If we ever reuse it, we can generalize it. But there was a bug because the caller didn't check for null. Fixed by changing load() to return an empty source map instead of null. File dev/codeserver/java/com/google/gwt/dev/codeserver/SourceHandler.java Line 189: private void sendSourceFileAsHtml(String moduleName, String fileName, BufferedReader lines, If this were a public API then from a what's the contract with the caller perspective, all that matters is that it sends an HTTP response. But since this isn't a public API and there's only one caller, I'd rather explain what it actually does. Line 194: File file = new File(fileName); Done. Went with sourcePath since it's actually a path. Line 200: out.startTag(html).nl(); We don't currently have a server-side templating library as a GWT dependency and I decided to avoid adding one. (Anything we use should do auto-escaping to protect against XSS.) -- To view, visit https://gwt-review.googlesource.com/3600 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Id16bcd2287630cebf7afb8bbbe0a198b28f5ada9 Gerrit-PatchSet: 1 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: John Stalcup stal...@google.com Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com Gerrit-HasComments: Yes -- 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.
[gwt-contrib] Change in gwt[master]: Super Dev Mode: deemphasize unused Java lines in codeserver'...
Hello Matthew Dempsky, Leeroy Jenkins, I'd like you to reexamine a change. Please visit https://gwt-review.googlesource.com/3600 to look at the new patch set (#3). Change subject: Super Dev Mode: deemphasize unused Java lines in codeserver's UI .. Super Dev Mode: deemphasize unused Java lines in codeserver's UI Modified the code server to render Java files as HTML when browsing interactively. (JavaScript debuggers continue to load the plain text.) In the HTML, lines that make no contribution to the JavaScript according to the source map are greyed out. This implementation is pretty inefficient since we parse the entire source map on every html page load, but it seems to suffice. Change-Id: Id16bcd2287630cebf7afb8bbbe0a198b28f5ada9 Review-Link: https://gwt-review.googlesource.com/#/c/3600/ --- M dev/codeserver/java/com/google/gwt/dev/codeserver/HtmlWriter.java A dev/codeserver/java/com/google/gwt/dev/codeserver/ReverseSourceMap.java M dev/codeserver/java/com/google/gwt/dev/codeserver/SourceHandler.java M dev/codeserver/java/com/google/gwt/dev/codeserver/SourceMap.java 4 files changed, 142 insertions(+), 15 deletions(-) -- To view, visit https://gwt-review.googlesource.com/3600 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: Id16bcd2287630cebf7afb8bbbe0a198b28f5ada9 Gerrit-PatchSet: 3 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: John Stalcup stal...@google.com Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com -- 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.
[gwt-contrib] Change in gwt[master]: Super Dev Mode: deemphasize unused Java lines in codeserver'...
Brian Slesinsky has submitted this change and it was merged.
Change subject: Super Dev Mode: deemphasize unused Java lines in
codeserver's UI
..
Super Dev Mode: deemphasize unused Java lines in codeserver's UI
Modified the code server to render Java files as HTML when browsing
interactively. (JavaScript debuggers continue to load the plain text.)
In the HTML, lines that make no contribution to the JavaScript according
to the source map are greyed out.
This implementation is pretty inefficient since we parse the entire
source map on every html page load, but it seems to suffice.
Change-Id: Id16bcd2287630cebf7afb8bbbe0a198b28f5ada9
Review-Link: https://gwt-review.googlesource.com/#/c/3600/
---
M dev/codeserver/java/com/google/gwt/dev/codeserver/HtmlWriter.java
A dev/codeserver/java/com/google/gwt/dev/codeserver/ReverseSourceMap.java
M dev/codeserver/java/com/google/gwt/dev/codeserver/SourceHandler.java
M dev/codeserver/java/com/google/gwt/dev/codeserver/SourceMap.java
4 files changed, 142 insertions(+), 15 deletions(-)
Approvals:
Matthew Dempsky: Looks good to me, approved
Leeroy Jenkins: Verified
diff --git
a/dev/codeserver/java/com/google/gwt/dev/codeserver/HtmlWriter.java
b/dev/codeserver/java/com/google/gwt/dev/codeserver/HtmlWriter.java
index 7cde2c4..ddf7db4 100644
--- a/dev/codeserver/java/com/google/gwt/dev/codeserver/HtmlWriter.java
+++ b/dev/codeserver/java/com/google/gwt/dev/codeserver/HtmlWriter.java
@@ -17,10 +17,12 @@
class HtmlWriter {
private static final SetString ALLOWED_TAGS =
Collections.unmodifiableSet(new HashSetString(Arrays.asList(
- html, head, title, style, body, pre, span, h1, h2,
a,
+ html, head, title, style,
+ body, h1, h2, h3, h4, h5, h6, a, pre, span,
table, tr, td)));
private static final SetString ALLOWED_ATTS =
- Collections.unmodifiableSet(new
HashSetString(Arrays.asList(class=, href=)));
+ Collections.unmodifiableSet(new HashSetString(Arrays.asList(
+ class=, href=)));
private final Writer out;
diff --git
a/dev/codeserver/java/com/google/gwt/dev/codeserver/ReverseSourceMap.java
b/dev/codeserver/java/com/google/gwt/dev/codeserver/ReverseSourceMap.java
new file mode 100644
index 000..a000d71
--- /dev/null
+++
b/dev/codeserver/java/com/google/gwt/dev/codeserver/ReverseSourceMap.java
@@ -0,0 +1,59 @@
+/*
+ * Copyright 2013 Google Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the License); you may
not
+ * use this file except in compliance with the License. You may obtain a
copy of
+ * the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
under
+ * the License.
+ */
+
+package com.google.gwt.dev.codeserver;
+
+import com.google.gwt.core.ext.TreeLogger;
+import com.google.gwt.dev.util.Util;
+import com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3;
+import
com.google.gwt.thirdparty.debugging.sourcemap.SourceMapParseException;
+
+/**
+ * A mapping from Java lines to JavaScript.
+ */
+class ReverseSourceMap {
+ private final SourceMapConsumerV3 consumer;
+
+ private ReverseSourceMap(SourceMapConsumerV3 consumer) {
+this.consumer = consumer;
+ }
+
+ /**
+ * Reads a source map from disk and parses it into an in-memory
representation.
+ * If it can't be loaded, logs a warning and returns an empty source map.
+ */
+ static ReverseSourceMap load(TreeLogger logger, ModuleState moduleState)
{
+SourceMapConsumerV3 consumer = new SourceMapConsumerV3();
+String unparsed = Util.readFileAsString(moduleState.findSourceMap());
+try {
+ consumer.parse(unparsed);
+ return new ReverseSourceMap(consumer);
+} catch (SourceMapParseException e) {
+ logger.log(TreeLogger.WARN, can't parse source map, e);
+ return new ReverseSourceMap(null);
+}
+ }
+
+ /**
+ * Returns true if the given line in a Java file has any corresponding
JavaScript in
+ * the GWT compiler's output. (The source file's path is relative to the
source root directory
+ * where the GWT compiler found it.)
+ */
+ boolean appearsInJavaScript(String path, int lineNumber) {
+// TODO: getReverseMapping() seems to be off by one (lines numbered
from zero). Why?
+return consumer != null !consumer.getReverseMapping(path,
lineNumber - 1, -1).isEmpty();
+ }
+}
diff --git
a/dev/codeserver/java/com/google/gwt/dev/codeserver/SourceHandler.java
b/dev/codeserver/java/com/google/gwt/dev/codeserver/SourceHandler.java
index e24755a..e3bc45b 100644
--- a/dev/codeserver/java/com/google/gwt/dev/codeserver/SourceHandler.java
[gwt-contrib] Google GWT team meeting notes for June 26th
Hi, in the interest of increased transparency, I'm going to start posting notes from GWT team meetings at Google. I'm not sure if we'll keep this up but we'll see how it goes. (My apologies in advance for any errors.) June 26, 2013 - Discussed goals for the next quarter. Of interest to the community: - Improving GWT compiler speed is important as usual. - Improve Super Dev Mode usability to improve internal adoption. In particular, figure out IDE integration. - Finish moving documentation to gwtproject.org and redirect from developers.google.com - Discussed what we should do with GWT designer documentation. The GWT designer is currently not being maintained. No resolution yet. - Discussed how to make mgwt available within Google. - Discussed community outreach, possibly by having public Hangouts and/or posting on YouTube. Still in progress. For now, Brian will write up meeting notes. - Gardening: new process seemed to work well. Matthew talked about automating it. - Talked about adding an end-to-end test for split points. Requires infrastructure. - Daniel: javadoc regenerated and moved to gwtproject.org to fix a security issue. - We discussed updating Google's internal widgets and widget architecture. Long term, one idea is to support web components written in JavaScript and come up with an improvement on JSNI and JavaScriptObjects to allow this. Goktug and Roberto have an idea they think will work. Short term unclear. Being able to consume GSS would help. Needs more discussion. -- 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.
[gwt-contrib] Change in gwt[master]: Optimize initializing fields at the top scope.
Brian Slesinsky has posted comments on this change. Change subject: Optimize initializing fields at the top scope. .. Patch Set 3: (2 comments) File dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java Line 2342: canObserveSubclassFields.add(currentClass); Parameterless static calls seem safe, but for constructors, it seems like we have to visit them to know whether they're safe? Perhaps we could construct a set of locally-safe constructors and a constructor call graph, which can be used to calculate the transitive closure. It should be linear for constructor calls. Line 2498:* Classes that could potentially see uninitialized values for fields that are ininitialized in sp: initialized -- To view, visit https://gwt-review.googlesource.com/3440 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500 Gerrit-PatchSet: 3 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Stephen Haberman stephen.haber...@gmail.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com Gerrit-Reviewer: Stephen Haberman stephen.haber...@gmail.com Gerrit-HasComments: Yes -- 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.
[gwt-contrib] Change in gwt[master]: Super Dev Mode: deemphasize unused Java lines in codeserver'...
Brian Slesinsky has uploaded a new change for review.
https://gwt-review.googlesource.com/3600
Change subject: Super Dev Mode: deemphasize unused Java lines in
codeserver's UI
..
Super Dev Mode: deemphasize unused Java lines in codeserver's UI
Modified the code server to render Java files as HTML when browsing
interactively. (JavaScript debuggers continue to load the plain text.)
In the HTML, lines that make no contribution to the JavaScript according
to the source map are greyed out.
This implementation is pretty inefficient since we parse the entire
source map on every html page load, but it seems to suffice.
Change-Id: Id16bcd2287630cebf7afb8bbbe0a198b28f5ada9
---
M dev/codeserver/java/com/google/gwt/dev/codeserver/HtmlWriter.java
A dev/codeserver/java/com/google/gwt/dev/codeserver/ReverseSourceMap.java
M dev/codeserver/java/com/google/gwt/dev/codeserver/SourceHandler.java
M dev/codeserver/java/com/google/gwt/dev/codeserver/SourceMap.java
4 files changed, 125 insertions(+), 15 deletions(-)
diff --git
a/dev/codeserver/java/com/google/gwt/dev/codeserver/HtmlWriter.java
b/dev/codeserver/java/com/google/gwt/dev/codeserver/HtmlWriter.java
index 7cde2c4..ddf7db4 100644
--- a/dev/codeserver/java/com/google/gwt/dev/codeserver/HtmlWriter.java
+++ b/dev/codeserver/java/com/google/gwt/dev/codeserver/HtmlWriter.java
@@ -17,10 +17,12 @@
class HtmlWriter {
private static final SetString ALLOWED_TAGS =
Collections.unmodifiableSet(new HashSetString(Arrays.asList(
- html, head, title, style, body, pre, span, h1, h2,
a,
+ html, head, title, style,
+ body, h1, h2, h3, h4, h5, h6, a, pre, span,
table, tr, td)));
private static final SetString ALLOWED_ATTS =
- Collections.unmodifiableSet(new
HashSetString(Arrays.asList(class=, href=)));
+ Collections.unmodifiableSet(new HashSetString(Arrays.asList(
+ class=, href=)));
private final Writer out;
diff --git
a/dev/codeserver/java/com/google/gwt/dev/codeserver/ReverseSourceMap.java
b/dev/codeserver/java/com/google/gwt/dev/codeserver/ReverseSourceMap.java
new file mode 100644
index 000..d82b3e1
--- /dev/null
+++
b/dev/codeserver/java/com/google/gwt/dev/codeserver/ReverseSourceMap.java
@@ -0,0 +1,42 @@
+package com.google.gwt.dev.codeserver;
+
+import com.google.gwt.core.ext.TreeLogger;
+import com.google.gwt.dev.util.Util;
+import com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3;
+import
com.google.gwt.thirdparty.debugging.sourcemap.SourceMapParseException;
+
+/**
+ * A mapping from Java lines to JavaScript.
+ */
+class ReverseSourceMap {
+ private final SourceMapConsumerV3 consumer;
+
+ ReverseSourceMap(SourceMapConsumerV3 consumer) {
+this.consumer = consumer;
+ }
+
+ /**
+ * Reads a source map from disk and parses it into an in-memory
representation.
+ * If it can't be loaded, logs an error and returns null.
+ */
+ static ReverseSourceMap load(TreeLogger logger, ModuleState moduleState)
{
+SourceMapConsumerV3 consumer = new SourceMapConsumerV3();
+String unparsed = Util.readFileAsString(moduleState.findSourceMap());
+try {
+ consumer.parse(unparsed);
+ return new ReverseSourceMap(consumer);
+} catch (SourceMapParseException e) {
+ logger.log(TreeLogger.WARN, can't parse source map, e);
+ return null;
+}
+ }
+
+ /**
+ * Returns true if the given line in a Java file has any corresponding
JavaScript in
+ * the GWT compiler's output.
+ */
+ boolean appearsInJavaScript(String filename, int lineNumber) {
+// TODO: getReverseMapping() seems to be off by one (lines numbered
from zero). Why?
+return !consumer.getReverseMapping(filename, lineNumber - 1,
-1).isEmpty();
+ }
+}
diff --git
a/dev/codeserver/java/com/google/gwt/dev/codeserver/SourceHandler.java
b/dev/codeserver/java/com/google/gwt/dev/codeserver/SourceHandler.java
index e24755a..d82c804 100644
--- a/dev/codeserver/java/com/google/gwt/dev/codeserver/SourceHandler.java
+++ b/dev/codeserver/java/com/google/gwt/dev/codeserver/SourceHandler.java
@@ -20,8 +20,11 @@
import com.google.gwt.dev.json.JsonArray;
import com.google.gwt.dev.json.JsonObject;
+import java.io.BufferedReader;
+import java.io.File;
import java.io.IOException;
import java.io.InputStream;
+import java.io.InputStreamReader;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
@@ -83,7 +86,7 @@
sendSourceMap(moduleName, request, response);
} else if (rest.endsWith(.java)) {
- sendSourceFile(moduleName, rest, response);
+ sendSourceFile(moduleName, rest, request.getQueryString(), response);
} else {
response.sendError(HttpServletResponse.SC_NOT_FOUND);
@@ -106,8 +109,7 @@
private void sendSourceMap(String moduleName, HttpServletRequest request,
HttpServletResponse response) throws
[gwt-contrib] Change in gwt[master]: Fix support for Document.{get,set}ScrollLeft() in RTL for sa...
Brian Slesinsky has posted comments on this change.
Change subject: Fix support for Document.{get,set}ScrollLeft() in RTL for
safari and ie9.
..
Patch Set 4: Verified+1 Code-Review+2
Looks like all issues have been resolved.
--
To view, visit https://gwt-review.googlesource.com/3420
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I8ce64ab4bbbae02ee7519ed8d24241cdfbc28617
Gerrit-PatchSet: 4
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Emmanuel Pellereau emmanu...@google.com
Gerrit-Reviewer: Brian Slesinsky skybr...@google.com
Gerrit-Reviewer: Emmanuel Pellereau emmanu...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: No
--
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.
[gwt-contrib] Change in gwt[master]: Fix support for Document.{get,set}ScrollLeft() in RTL for sa...
Brian Slesinsky has submitted this change and it was merged.
Change subject: Fix support for Document.{get,set}ScrollLeft() in RTL for
safari and ie9.
..
Fix support for Document.{get,set}ScrollLeft() in RTL for safari and ie9.
Change-Id: I8ce64ab4bbbae02ee7519ed8d24241cdfbc28617
Review-Link: https://gwt-review.googlesource.com/#/c/3420/
---
M user/src/com/google/gwt/dom/client/DOMImplIE9.java
M user/src/com/google/gwt/dom/client/DOMImplStandardBase.java
M user/test/com/google/gwt/dom/client/ElementTest.java
3 files changed, 41 insertions(+), 2 deletions(-)
Approvals:
Leeroy Jenkins: Verified
Brian Slesinsky: Verified; Looks good to me, approved
diff --git a/user/src/com/google/gwt/dom/client/DOMImplIE9.java
b/user/src/com/google/gwt/dom/client/DOMImplIE9.java
index 6564bb2..a49c651 100644
--- a/user/src/com/google/gwt/dom/client/DOMImplIE9.java
+++ b/user/src/com/google/gwt/dom/client/DOMImplIE9.java
@@ -91,6 +91,11 @@
setScrollLeftImpl(elem, left);
}
+ @Override
+ public void setScrollLeft(Document doc, int left) {
+setScrollLeft(doc.getDocumentElement(), left);
+ }
+
protected native int getBoundingClientRectLeft(Element elem) /*-{
// getBoundingClientRect() throws a JS exception if the elem is not
attached
// to the document, so we wrap it in a try/catch block
diff --git a/user/src/com/google/gwt/dom/client/DOMImplStandardBase.java
b/user/src/com/google/gwt/dom/client/DOMImplStandardBase.java
index 5d698f7..acd9c0a 100644
--- a/user/src/com/google/gwt/dom/client/DOMImplStandardBase.java
+++ b/user/src/com/google/gwt/dom/client/DOMImplStandardBase.java
@@ -223,7 +223,7 @@
@Override
public int getScrollLeft(Element elem) {
-if (isRTL(elem)) {
+if (!elem.hasTagName(BodyElement.TAG) isRTL(elem)) {
return super.getScrollLeft(elem)
- (elem.getScrollWidth() - elem.getClientWidth());
}
@@ -253,7 +253,7 @@
@Override
public void setScrollLeft(Element elem, int left) {
-if (isRTL(elem)) {
+if (!elem.hasTagName(BodyElement.TAG) isRTL(elem)) {
left += elem.getScrollWidth() - elem.getClientWidth();
}
super.setScrollLeft(elem, left);
diff --git a/user/test/com/google/gwt/dom/client/ElementTest.java
b/user/test/com/google/gwt/dom/client/ElementTest.java
index c4a2acf..23d19f0 100644
--- a/user/test/com/google/gwt/dom/client/ElementTest.java
+++ b/user/test/com/google/gwt/dom/client/ElementTest.java
@@ -599,6 +599,40 @@
assertEquals(0, outer.getScrollLeft());
}
+ @DoNotRunWith({Platform.HtmlUnitLayout})
+ public void testDocumentScrollLeftInRtl() {
+Document.get().getDocumentElement().setDir(rtl);
+Document.get().getBody().getStyle().setProperty(direction, rtl);
+
+final DivElement bigdiv = Document.get().createDivElement();
+
+bigdiv.getStyle().setProperty(position, absolute);
+bigdiv.getStyle().setProperty(top, 0px);
+bigdiv.getStyle().setProperty(right, 0px);
+bigdiv.getStyle().setProperty(width, 1px); // Bigger than
window size.
+bigdiv.getStyle().setProperty(height, 400px);
+
+Document.get().getBody().appendChild(bigdiv);
+
+// The important thing is that setting and retrieving scrollLeft
values in
+// RTL mode works only for negative numbers, and that they round-trip
+// correctly.
+try {
+ assertEquals(0, Document.get().getScrollLeft());
+
+ Document.get().setScrollLeft(-32);
+ assertEquals(-32, Document.get().getScrollLeft());
+
+ Document.get().setScrollLeft(32);
+ assertEquals(0, Document.get().getScrollLeft());
+} finally {
+ // Restore direction unconditionally to not break all other tests.
+ Document.get().getBody().removeChild(bigdiv);
+ Document.get().getBody().getStyle().setProperty(direction, ltr);
+ Document.get().getDocumentElement().setDir(ltr);
+}
+ }
+
/**
* innerHTML.
*/
--
To view, visit https://gwt-review.googlesource.com/3420
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: merged
Gerrit-Change-Id: I8ce64ab4bbbae02ee7519ed8d24241cdfbc28617
Gerrit-PatchSet: 4
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Emmanuel Pellereau emmanu...@google.com
Gerrit-Reviewer: Brian Slesinsky skybr...@google.com
Gerrit-Reviewer: Emmanuel Pellereau emmanu...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
--
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.
Re: [gwt-contrib] Re: Temporarily disabling CR+2 on Gerrit
Update: as far as I know, nobody worked on this today. But on the bright side, nothing had to be rolled back. (I worked on getting the Firefox plugin ready for Firefox 22. It should be out on time.) On Thu, Jun 20, 2013 at 3:32 PM, Matthew Dempsky mdemp...@google.comwrote: As a ~24h later status report, we assembled a list of 26 changes that were outstanding, and started working on manually importing them individually so we could parallelize our efforts. It's basically all we've worked on today so far. Current status is: - 12 of them have already been merged. - 3 of them add new JRE 7 dependencies to unit tests, which breaks since we currently still need to support JRE 6 internally. (We're still discussing what to do about these, but they don't seem like a problem.) - 1 of them broke gwt-exporterhttps://code.google.com/p/gwt-exporter/due to the latter depending on GWT internals; fix is in review - 2 more cause performance regressions or breakage that rluble is investigating - 4 more are currently in review/testing - 4 more are still pending review So we're about half to two-thirds caught up now, and progressing quickly. I'm hopefully optimistic that we can re-enable CR+2 tomorrow or early next week, and start accepting patches again. On Wed, Jun 19, 2013 at 12:45 PM, Matthew Dempsky mdemp...@google.comwrote: Hi GWT contributors, We're happy to see so much increased activity in the recent weeks since opening Gerrit to direct external contributions! Unfortunately, the new velocity has stressed our workflow for importing changes back internally within Google, and we've now fallen a couple weeks behind master. After discussing this some, we've decided we need to *temporarily*disable CR+2 on Gerrit while we catch up internally and experiment with a new more scalable workflow for going forward. As soon as we're caught up, we'll reallow CR+2 and try to ramp up again. We really regret the inconvenience in the meantime! :( Thanks, Matthew, on behalf of Google's GWT team -- 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. -- 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.
[gwt-contrib] Change in gwt[master]: Adds isStandalone to ImageResource so Image can used an Uncl...
Brian Slesinsky has posted comments on this change. Change subject: Adds isStandalone to ImageResource so Image can used an UnclippedState. .. Patch Set 8: Had to roll this back again due to projects that implement the ImageResource interface in their mocks, but were missing the new method. (At Google we can fix this, but for 2.6 we should at least warn that it's a breaking change.) -- To view, visit https://gwt-review.googlesource.com/2110 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I832fd71e17e447e642de134e7a556befa1a7f0f1 Gerrit-PatchSet: 8 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Thomas Broyer t.bro...@gmail.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com Gerrit-Reviewer: Matthew Dempsky mdemp...@gwtproject.org Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- 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.
[gwt-contrib] Change in gwt[master]: Add hasClassName method in com.google.gwt.dom.client.Element
Brian Slesinsky has posted comments on this change. Change subject: Add hasClassName method in com.google.gwt.dom.client.Element .. Patch Set 7: As mentioned above, there's a conflict with Sencha which bit us when we tried to import into Google. I created an issue: https://code.google.com/p/google-web-toolkit/issues/detail?id=8211 -- To view, visit https://gwt-review.googlesource.com/3070 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ia09567b8c58cac02f8126c33ef169b26def3d19c Gerrit-PatchSet: 7 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy a.korzhevs...@gmail.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Colin Alworth niloc...@gmail.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Stephen Haberman stephen.haber...@gmail.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- 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.
[gwt-contrib] Change in gwt[master]: Adds an accessor to original throwable from SerializableThro...
Brian Slesinsky has posted comments on this change.
Change subject: Adds an accessor to original throwable from
SerializableThrowable.
..
Patch Set 1: Code-Review+1
(1 comment)
Seems basically okay.
File user/src/com/google/gwt/core/shared/SerializableThrowable.java
Line 124: public void setOriginalThrowable(Throwable originalThrowable) {
When would someone use the setter?
--
To view, visit https://gwt-review.googlesource.com/3500
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I6856ca06f85af0165eea5ff6ac3015081b579352
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: Brian Slesinsky skybr...@google.com
Gerrit-HasComments: Yes
--
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.
[gwt-contrib] Change in gwt[master]: Adds an accessor to original throwable from SerializableThro...
Brian Slesinsky has posted comments on this change. Change subject: Adds an accessor to original throwable from SerializableThrowable. .. Patch Set 2: Code-Review+2 (1 comment) File user/src/com/google/gwt/core/shared/SerializableThrowable.java Line 120:* Returns the original throwable that this serializable throwable is derived from. Note that, Note that the -- To view, visit https://gwt-review.googlesource.com/3500 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I6856ca06f85af0165eea5ff6ac3015081b579352 Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-HasComments: Yes -- 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.
Re: [gwt-contrib] Issue 8083, needs some input from GWT team
Okay, fair enough. Making BigDecimal deserialize faster would certainly be a good thing. I just don't want it to result in hard-to-diagnose errors if there's some kind of mismatch between client and server. If there's any difference then we should probably have a configuration property or an annotation on the remote service interface to turn laziness on. On Fri, Jun 14, 2013 at 1:02 AM, David david.no...@gmail.com wrote: Hi, Theoretically you are absolutely right. But practically is another discussion, I am talking about thousands of lines that need to change just for the GUI tier limitations. The GUI is just a fraction of the application because the same Request/Response objects are used internally as well (command pattern). Redesigning the entire application because of a limitation of the GUI is nuts. But in the way we use BigInteger, I understand your point of view. But the same problem is there with BigDecimal (somebody else filled an issue so I did not bother to create a duplicate, it is marked as assume stale). We show records with BigDecimal in Cell tables. Again RPC is slow here. While the user will only click on certain records to make modifications. Again I could refactor to wait with conversion to BigDecimal until the user changes a value (to validate), but in this case BigDecimal was the right data-type to use and it is not nice to have to redesign an application because the RPC system of GWT has limitations. David On Thu, Jun 13, 2013 at 10:20 PM, Brian Slesinsky skybr...@google.comwrote: I agree; this seems like a workaround for one application that picked the wrong datatype. Maybe we should warn about BigDecimal being slow somewhere? If someone wants to do some performance tests of GWT-RPC serialization, publishing the results would be useful to the community. My recommendation in this case would be create a new class named Id or Key that simply contains the BigDecimal, then modify the code to use it, then change the implementation to store the data in a string field instead. In the end you'll have more readable code. - Brian On Thu, Jun 13, 2013 at 12:03 PM, David david.no...@gmail.com wrote: John, Well, if I don't have support for this patch then I better stop working on it. I can understand that this is not seen as a priority for GWT. Worst case I just replace the BigInteger/BigDecimal class in the project itself, that is basically what I did right now. Oracle sequences can be configured as a range between -10ˆ-26 and 10ˆ27. The Oracle JDBC drivers return a BigInteger if you force it to the extremes. Changing the application is not feasible, that will be too much work, we are talking about many thousands of dependencies in a huge codebase where BigIntegers and BigDecimals are used - while handling this optimisation on the RPC level can be done in just a few lines of code. In many cases we send large lists of objects that contain BigInteger, BigDecimals but only a few will actually be interacted with. So in that case we only need to convert the Strings to BigInteger (or BigDecimal) when really needed. David On Thu, Jun 13, 2013 at 7:52 PM, John A. Tamplin j...@jaet.org wrote: On Thu, Jun 13, 2013 at 3:14 AM, David david.no...@gmail.com wrote: The lazy parsing would only happen during deserialisation in the client. I think it is safe to assume that a BigInteger created through toString on the server will not result in a parse exception in the client code - or are there known incompatibilities ? I don't want that the regular constructor of BigInteger( String ) or BigInteger( String, int) would behave differently than before. Not even in the client when those BigInts are created in the client. That's why I was asking about the possibility to have different serialisers on client and server side. As the why, well currently the custom field serializer converts the BigInteger to a String, the client side needs to parse the string and convert it to an int array, which involves multiple substring, Integer.parseInt and multiply and add operations. Somehow IE8 has a problem with this. IE9 and other browsers are more efficient, but still that is a lot of CPU operations that can be avoided in my use case. In my particular use case they used BigInteger to represent a key in the database (oracle uses sequence numbers that are bigger than what can be represented with long). That might have not been the best idea, but those decisions have been made a long time ago, when I was not around. On the server side there is a usage of equals and compareTo happening, which would be hard to implement without a BigInteger, so there is logic in the choice. They obviously don't want to have an extra layer of objects to avoid the BigInteger in the GWT client since a lot of code is independent of client or server, this would hinder code sharing between the tiers. On the client side these id's are only send forth
Re: [gwt-contrib] Work to do for bug 3042
Another possibility would be to develop a nicer GWT RichTextArea as a separate open source project. There's no reason it has to be in core GWT right away and you'll be able to work faster that way. With real-world usage, you'll probably learn a few things that will make it better quality if we do merge it back to core later. However, if you have to patch GWT to make it work, that is the sort of thing that should be contributed back to GWT. On Thu, Jun 13, 2013 at 10:03 PM, Manuel Carrasco Moñino man...@apache.orgwrote: In my opinion, having the tool-bar in gwt makes perfectly sense, RichTextArea is almost unusable without a bar in any project. It's plenty of gwt projects which have copied and pasted the code from the showcase. I think that you should face this issue in some steps: 1.- Listen to GWT contributors for the convenience of moving RichTextToolbar from samples to gwt. So maintain live this thread until you get enough feedback. 2.- Send a first patch just moving the code from show-case to gwt (showcase should use the new code) 3.- When the patch were accepted, continue adding other features like adding/removing widgets from the toolbar, or a panel grouping RichTextArea + RichTextToolbar, etc. because each thing needs a different review/discussion. - Manolo On Tue, Jun 11, 2013 at 7:25 PM, Adolfo Panizo Touzon adolfo.pan...@gmail.com wrote: Oh! Sorry I saw you were the owner and I thought you had plenty of responsability. Thanks, but everything is fine, the installation process is quite simple/clear, so, all is up and running. :D. Keep an eye into the Issue 1127 because maybe you are interested in giving instructions related to both issues. Thanks, Adolfo. On Tue, Jun 11, 2013 at 10:28 AM, Daniel Kurka danku...@google.com wrote: Hi Adolfo, this is not my issue and I am not solely responsible for it. We should see wait and see if anybody opposes to adding this to GWT, before you actually start working on it, so that your time will not be wasted. On the other hand you can already setup your IDE and tools to be able to start. James pointed out the resources. If there is anything wrong / unclear in those resources please let us know. Or you could even send a patch for the homepage to be updated. - Daniel On Mon, Jun 10, 2013 at 8:07 PM, Adolfo Panizo Touzon adolfo.pan...@gmail.com wrote: Thanks James! But I have done those steps yet (indeed I read in that link I should ask here first :D) . When I said the necessary work I meant the steps for develop the RichTextArea according to the GWT steering committee (for this issue I think Daniel is responsible) so I need to wait for his opinion. Thanks anyway for your quick response. Adolfo. On Mon, Jun 10, 2013 at 1:02 PM, James Horsley james.hors...@gmail.com wrote: Adolfo, To get the source checked out and compiling follow: http://www.gwtproject.org/makinggwtbetter.html#workingoncode To submit the patch use: http://www.gwtproject.org/makinggwtbetter.html#submittingpatches I recently had to move an old svn patch into gerrit and the following gave a very simple way to apply it http://stackoverflow.com/questions/659467/how-to-apply-svn-diff-to-gitjust remember to clean up any leftover .orij and .rej files. Cheers, James On 10 June 2013 10:01, Adolfo Panizo adolfo.pan...@gmail.com wrote: Hi, as I wrote in the issue, I am able to do the necessary work for solving it. So, can you guide me about the steps that I need to follow in order to create a patch properly? Would you like to reuse some code of the old patch? I am going to contact the creator of it because maybe he continues interested on fixing the issue and rebase the patch with the last code. Of course if there are other issues related to RichTextArea I can solve as well. Thanks in advance, Adolfo. -- 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. -- 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. -- El precio es lo que pagas. El valor es lo que recibes. Warren Buffet -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are
[gwt-contrib] Change in gwt[master]: Adding a DOM clear method to RootPanel
Brian Slesinsky has posted comments on this change.
Change subject: Adding a DOM clear method to RootPanel
..
Patch Set 6:
(1 comment)
I still don't think it's necessary but I'm okay with a helper method if
it's very simple to use.
File user/src/com/google/gwt/user/client/ui/RootPanel.java
Line 316: public void clear(boolean clearDom) {
How about calling this clearDom() and removing the boolean? If they don't
want to clear the dom then they can call clear().
Rationale: clear(true) is less readable and memorable because you have to
look up the method definition to see what true means. Hardly anyone would
call this with any value other than a constant true.
--
To view, visit https://gwt-review.googlesource.com/2512
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I712989276142460b91514713eaf8d8f74dbecd7b
Gerrit-PatchSet: 6
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Brian Slesinsky skybr...@google.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: Yes
--
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.
Re: [gwt-contrib] Issue 8083, needs some input from GWT team
I agree; this seems like a workaround for one application that picked the wrong datatype. Maybe we should warn about BigDecimal being slow somewhere? If someone wants to do some performance tests of GWT-RPC serialization, publishing the results would be useful to the community. My recommendation in this case would be create a new class named Id or Key that simply contains the BigDecimal, then modify the code to use it, then change the implementation to store the data in a string field instead. In the end you'll have more readable code. - Brian On Thu, Jun 13, 2013 at 12:03 PM, David david.no...@gmail.com wrote: John, Well, if I don't have support for this patch then I better stop working on it. I can understand that this is not seen as a priority for GWT. Worst case I just replace the BigInteger/BigDecimal class in the project itself, that is basically what I did right now. Oracle sequences can be configured as a range between -10ˆ-26 and 10ˆ27. The Oracle JDBC drivers return a BigInteger if you force it to the extremes. Changing the application is not feasible, that will be too much work, we are talking about many thousands of dependencies in a huge codebase where BigIntegers and BigDecimals are used - while handling this optimisation on the RPC level can be done in just a few lines of code. In many cases we send large lists of objects that contain BigInteger, BigDecimals but only a few will actually be interacted with. So in that case we only need to convert the Strings to BigInteger (or BigDecimal) when really needed. David On Thu, Jun 13, 2013 at 7:52 PM, John A. Tamplin j...@jaet.org wrote: On Thu, Jun 13, 2013 at 3:14 AM, David david.no...@gmail.com wrote: The lazy parsing would only happen during deserialisation in the client. I think it is safe to assume that a BigInteger created through toString on the server will not result in a parse exception in the client code - or are there known incompatibilities ? I don't want that the regular constructor of BigInteger( String ) or BigInteger( String, int) would behave differently than before. Not even in the client when those BigInts are created in the client. That's why I was asking about the possibility to have different serialisers on client and server side. As the why, well currently the custom field serializer converts the BigInteger to a String, the client side needs to parse the string and convert it to an int array, which involves multiple substring, Integer.parseInt and multiply and add operations. Somehow IE8 has a problem with this. IE9 and other browsers are more efficient, but still that is a lot of CPU operations that can be avoided in my use case. In my particular use case they used BigInteger to represent a key in the database (oracle uses sequence numbers that are bigger than what can be represented with long). That might have not been the best idea, but those decisions have been made a long time ago, when I was not around. On the server side there is a usage of equals and compareTo happening, which would be hard to implement without a BigInteger, so there is logic in the choice. They obviously don't want to have an extra layer of objects to avoid the BigInteger in the GWT client since a lot of code is independent of client or server, this would hinder code sharing between the tiers. On the client side these id's are only send forth and back between client and server, no operation is ever performed, so making the custom field serialiser and the BigInteger cooperate gives a big performance improvement. They only operation needed on the client-side is equals, which can also be optimized to do a String comparison when bother have not been parsed after RPC. I'm beginning to think such a change does not belong in GWT. In your example, wouldn't you be better served by only sending strings to the client rather than BigDecimals, if they client never does anything with them but send them back? I think it is going to be pretty rare in normal situations that you instantiate a BigDecimal but never actually use it in the client, so it seems the special-case hack for your use-case should be performed in your code instead. Too often people want to send things to the client that really don't belong there, and that includes particular representations of it. I know DTOs are extra work over just shipping your regular objects over the wire and GWT RPC makes that easy, but in many cases it is the wrong thing to do. Think about if you were building a proto for the communication -- would you send the data in the current form? If not, you shouldn't be sending it that way via RPC just because it is easy to do so. BTW, I thought Oracle sequence numbers did fit in long (aren't they int64?) -- at least all the JDBC code I see for manipulating them stores them in a Java long. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors ---
[gwt-contrib] Change in gwt[master]: Adding a DOM clear method to RootPanel
Brian Slesinsky has posted comments on this change. Change subject: Adding a DOM clear method to RootPanel .. Patch Set 6: Admittedly it's a judgment call. I'm somewhat biased in favor of shorter names and somewhat against giving two methods the same name. I don't think there's a sensible interpretation of clearing the DOM that doesn't include the widgets too, so it seems like we don't need to include that in the name. (By the way, if we did have to do something tricky like avoid clearing the history frame then that would actually be an argument in favor of having this method.) -- To view, visit https://gwt-review.googlesource.com/2512 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I712989276142460b91514713eaf8d8f74dbecd7b Gerrit-PatchSet: 6 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka danku...@google.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- 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.
[gwt-contrib] Change in gwt[master]: Use JSON.parse() instead of eval() to deserialize rpc callba...
Brian Slesinsky has posted comments on this change. Change subject: Use JSON.parse() instead of eval() to deserialize rpc callback payload .. Patch Set 11: Sounds like we need more tests. Serialization code generally does benefit from a thorough test suite. -- To view, visit https://gwt-review.googlesource.com/2900 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I6062180397f5fabed1dd5f08140c2bd43a19fa9f Gerrit-PatchSet: 11 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: John Ahlroos j...@vaadin.com Gerrit-Reviewer: Artur Signell ar...@vaadin.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Colin Alworth niloc...@gmail.com Gerrit-Reviewer: John Ahlroos j...@vaadin.com Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Leif Åstrand l...@vaadin.com Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- 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.
[gwt-contrib] Change in gwt[master]: Adding a DOM clear method to RootPanel
Brian Slesinsky has posted comments on this change. Change subject: Adding a DOM clear method to RootPanel .. Patch Set 6: Code-Review+2 This is a pretty minor change, breakage is unlikely, and I don't think it matters too much, so I'm going to stop bikeshedding. Daniel, I'm okay with whatever you decide. -- To view, visit https://gwt-review.googlesource.com/2512 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I712989276142460b91514713eaf8d8f74dbecd7b Gerrit-PatchSet: 6 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka danku...@google.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- 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.
Re: [gwt-contrib] Issue 8083, needs some input from GWT team
Lazy parsing can be a performance win, but it also complicates the API in the case of a parse error. Have you thought about how to report errors when they happen later? It might less confusing to solve this using a separate LazyBigDecimal class. People can declare fields of this type in their data transfer objects when they're concerned about performance. On Tue, Jun 11, 2013 at 1:56 AM, stuckagain david.no...@gmail.com wrote: Hi, I am working on a fix for this issue: https://code.google.com/p/google-web-toolkit/issues/detail?id=8083 I am avoiding converting from string to the internal format of BigInteger because it has a big performance impact on IE8 when sending it over RPC. It performs much better in IE9 and other browsers, but still I want to optimize this since this is having a major impact in an application I am working on (And I saw some other people in the banking industry having similar issues with BigDecimal). In many cases this data is never modified in the client, so I am delaying the actual parsing of the String to the internal format of BigInteger. Is it feasible to have custom field serializers depending on running in the client or server ? The question I am asking is because I don't want to break the BigInteger(String) constructor that will throw exceptions when you feed it a non parseable string. so my solution would be to use a static method or custom constructor for BigInteger when deserializing on the client. But this method is not available in the real java.math.BigInteger class. So is it possible to have different client and server serializers/deserializer code for RPC ? David -- 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. -- 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.
[gwt-contrib] Change in gwt[master]: Fix non-final field initializers running before the super cstr.
Brian Slesinsky has posted comments on this change. Change subject: Fix non-final field initializers running before the super cstr. .. Patch Set 9: Regarding git procedure, I've already rolled back on google/pu and we can rollback the rollback before merging any change to the same code from trunk, so there's no particular hurry to rollback on trunk. However, if there are any other GWT compiler changes that touch the same code, it might make sense to rollback on trunk first so that the patches apply cleanly. -- To view, visit https://gwt-review.googlesource.com/3030 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I4c8ed0cd718a2188b33cc290fec6071c89be7918 Gerrit-PatchSet: 9 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Stephen Haberman stephen.haber...@gmail.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com Gerrit-Reviewer: Ray Cromwell cromwell...@google.com Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com Gerrit-Reviewer: Stephen Haberman stephen.haber...@gmail.com Gerrit-HasComments: No -- 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.
[gwt-contrib] Change in gwt[master]: Fix non-final field initializers running before the super cstr.
Brian Slesinsky has posted comments on this change. Change subject: Fix non-final field initializers running before the super cstr. .. Patch Set 9: Oops, that wasn't very clear. Let me try again: If think you're going to implement a patch this week to fix the performance regression, please go ahead and do it and don't worry about rollbacks. But if you think it's going to take a while, we should rollback this change on trunk so it doesn't get in the way of other compiler changes. -- To view, visit https://gwt-review.googlesource.com/3030 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I4c8ed0cd718a2188b33cc290fec6071c89be7918 Gerrit-PatchSet: 9 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Stephen Haberman stephen.haber...@gmail.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com Gerrit-Reviewer: Ray Cromwell cromwell...@google.com Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com Gerrit-Reviewer: Stephen Haberman stephen.haber...@gmail.com Gerrit-HasComments: No -- 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.
[gwt-contrib] Change in gwt[master]: Fix non-final field initializers running before the super cstr.
Brian Slesinsky has posted comments on this change. Change subject: Fix non-final field initializers running before the super cstr. .. Patch Set 9: Hi, we had a performance regression reported to us so we rolled this CL back internally. The code where they noticed the regression is a builder class with many instance variables. Apparently the variable's default values were previously initialized on the prototype, so constructing the class was fast. After this change, they're initialized when the constructor is called. In this particular builder it's pointless because it extends Object. So we could put in a check for that, or more generally we could search superclass constructors for virtual methods that might be overridden. If there aren't any, the difference isn't observable and we can initialize fields the faster way. Or if that's too hard, conforming to the spec doesn't seem too important (given that we've lived without it for so many years), so we could just roll this back on trunk. -- To view, visit https://gwt-review.googlesource.com/3030 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I4c8ed0cd718a2188b33cc290fec6071c89be7918 Gerrit-PatchSet: 9 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Stephen Haberman stephen.haber...@gmail.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com Gerrit-Reviewer: Ray Cromwell cromwell...@google.com Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com Gerrit-Reviewer: Stephen Haberman stephen.haber...@gmail.com Gerrit-HasComments: No -- 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.
Re: [gwt-contrib] Re: ValueListBox should implement HasEnabled (6112) (issue1832803)
+mdempsky Hi, I think you're going to have more trouble than most because you're using Windows and that's not so common for GWT development. The code to automatically add the Change-Id line is specific to Unix but you can do it manually by editing the changelist yourself. To fix your most recent commit, run git commit --amend and cut and paste the Change-Id line from the error message to the end of the commit message. (I believe each commit has to have its own Change-Id line and will be reviewed separately? Not sure how that works.) - Brian On Mon, Jun 10, 2013 at 8:17 AM, Patrick Tucker tucker...@gmail.com wrote: Well I just wasted another few hours this morning trying to figure out how to commit something to this new system. Are these instructions complete?? Currently when I try to do a git push it tells me I have to provide a Change-Id. I copied the hook file to the hooks folder and the message did not go away. The command that GIT tells me to run executes chmod in it, being that I am on a windows machine it obviously fails. The online help page also tells me to execute the same command. I'm at a loss. On Monday, June 10, 2013 10:43:27 AM UTC-4, Patrick Tucker wrote: Thanks for the quick response, but that doesn't answer my question. I realize foo is a place holder, I'm trying to figure out what it represents. A file, a message to the reviewers, ... I'm trying to figure out what I should replace it with. Thanks again, Pat On Mon, Jun 10, 2013 at 9:54 AM, Daniel Kurka danku...@google.comwrote: Hi Patrick, foo is often used as a place holder, so something like: git add foo should mean: git add my_cool_edited_file -Daniel On Mon, Jun 10, 2013 at 3:35 PM, Patrick Tucker tucker...@gmail.comwrote: From the gwtproject Making GWT Better page section Gerrit Setup step 3: Make a change and commit it locally using git (e.g., edit a file foo and then run ?git commit -m ?my first change? foo?). What does foo represent? Thanks, Pat On Mon, May 20, 2013 at 3:18 PM, Thomas Broyer t.bro...@gmail.comwrote: Should be http://gwtproject.org/**makinggwtbetter.htmlhttp://gwtproject.org/makinggwtbetter.html On Sunday, May 19, 2013 10:00:01 PM UTC+2, Patrick Tucker wrote: I started from scratch and was able to get it mostly working. Is there a doc that explains the right way to submit a patch? On Friday, May 17, 2013 1:19:33 PM UTC-4, Patrick Tucker wrote: Windows 7 Pro On Friday, May 17, 2013 12:51:47 PM UTC-4, Matthew Dempsky wrote: On Fri, May 17, 2013 at 9:45 AM, Patrick Tucker tuck...@gmail.comwrote: I'm not sure where to find the file that you are referring to, it is not in my eclipse install folder? John was referring to the eclipse directory in the GWT source code tree: https://gwt.**googlesource**.com/gwt/+/master/**eclipse/ **README.txthttps://gwt.googlesource.com/gwt/+/master/eclipse/README.txt I was playing with the settings and tried removing one of the source folders so that I could add it back and got an error saying the file system is read only. Any idea why it would do that? Not sure, that sounds odd to me. Just out of curiosity, what OS are you using? When you prepared the patch from Rietveld, did you checkout the code from Subversion or use the 2.5.1 SDK release zip file? If you were already using Subversion, I would expect using Git shouldn't be any different to setup in Eclipse since the source tree should be the same. -- http://groups.google.com/**group/Google-Web-Toolkit-**Contributorshttp://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+unsubscribe@** googlegroups.comgoogle-web-toolkit-contributors%2bunsubscr...@googlegroups.com . For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- Google Germany GmbH *Dienerstr. 12* *80331 München* Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Katherine Stephens -- http://groups.google.com/**group/Google-Web-Toolkit-**Contributorshttp://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to a topic in the Google Groups GWT Contributors group. To unsubscribe from this topic, visit https://groups.google.com/d/** topic/google-web-toolkit-**contributors/hJzwtP-zEZw/** unsubscribe?hl=en-UShttps://groups.google.com/d/topic/google-web-toolkit-contributors/hJzwtP-zEZw/unsubscribe?hl=en-US . To unsubscribe from this group and all its topics, send an email to google-web-toolkit-**contributors+unsubscribe@**googlegroups.comgoogle-web-toolkit-contributors%2bunsubscr...@googlegroups.com . For more options, visit
[gwt-contrib] Change in gwt[master]: Remove unused, package-private FastStringMap.
Brian Slesinsky has posted comments on this change. Change subject: Remove unused, package-private FastStringMap. .. Patch Set 1: Code-Review+2 Not used in Google code either. -- To view, visit https://gwt-review.googlesource.com/3280 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I8dd9f897a044ba53be5fc74fabb40a382b9ef119 Gerrit-PatchSet: 1 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Stephen Haberman stephen.haber...@gmail.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Manuel Carrasco Moñino manuel.carrasc...@gmail.com Gerrit-Reviewer: Stephen Haberman stephen.haber...@gmail.com Gerrit-HasComments: No -- 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.
[gwt-contrib] Change in gwt[master]: The job of defineSeed is to mark the existence of a class an...
Brian Slesinsky has posted comments on this change. Change subject: The job of defineSeed is to mark the existence of a class and associate its castMap with the class's various constructors. .. Patch Set 2: (1 comment) This is too deep for me to review so I'll leave it to Ray and Roberto. A surface comment: Commit Message Line 7: The job of defineSeed is to mark the existence of a class and associate its castMap with the class's various constructors. The first line of a commit should be a short summary line that makes sense to people not familiar with GWT internals (Fix a bug in the codesplitter) Then say when the bug could happen (The bug occurs when a class has multiple constructors...) and link to the issue. Then go into the detailed explanation of how you fixed it. -- To view, visit https://gwt-review.googlesource.com/3300 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Idc87430b94338d289eae4760a1bef8ad127bd699 Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: John Stalcup stal...@google.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: John Stalcup stal...@google.com Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Ray Cromwell cromwell...@google.com Gerrit-HasComments: Yes -- 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.
Re: [gwt-contrib] serializing final fields
On Wed, Jun 5, 2013 at 7:46 PM, Stephen Haberman step...@exigencecorp.comwrote: I don't have a good idea about what could break I believe nothing would break--it's that final fields that were previously not going over the wire would now go over the wire. It's also possible that the newly exposed final field has a type that has a subclass that isn't designed for serialization. Or it might technically be serializable but actually sending it over the wire doesn't work right for whatever reason. Or perhaps it causes a GWT app's size to blow up because now we're trying to serialize the world. So yes, all sorts of things could go wrong, particularly in extremely complicated and buggy code like GWT-RPC. In principle, a refactoring of GWT-RPC to send some kind of context object all the way through seems like a good change since we might use it for other config settings. (Though it's probably something that we should land as a separate CL.) - Brian -- 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.
