On Friday, June 8, 2012 12:09:51 AM UTC+2, Stephen Haberman wrote:
>
>
> > AFAICT, Safari 2 is no longer part of the supported browsers list, so
> > my take on it would be to clean-up the codebase and remove every
> > safari2-specific path.
> > There are overall a lot of cleanup (remove event l
On Friday, June 8, 2012 7:46:30 AM UTC+2, Thomas Broyer wrote:
>
>
> (I wonder though: how are events handled? how are they registered? I'll
> look at the UiBinder/UiRenderer code and/or the generated code)
>
Let me clarify: how are native events mapped to DomEvents? (DragStartEvent
in the sam
I wonder if we shouldn't rather aim at integrating the
ServletContainerLauncher with SuperDevMode; which could also be seen as:
building a DevMode where the "code server" (the part to which the DevMode
browser plugin connects, and runs your client code in the JVM) would be
replaced by SuperDevM
Just to check, was everything okay with the CLA I signed?
On 7 June 2012 16:56, James Horsley wrote:
> Thanks Rajeev. Let me know if there's anything else you need with it.
>
>
> On 7 June 2012 16:18, Rajeev Dayal wrote:
>
>> Thomas, thanks for jumping in.
>>
>> James, as Thomas said, we'll def
Reviewers: rdayal, cromwellian, skybrian,
Message:
Note that this doesn't address the possible breaking change described by
Brian at
http://code.google.com/p/google-web-toolkit/issues/detail?id=7397
If we need/want to update org.json (latest version is 20090211) and/or
repackage it, we could add
Yes, documentation is still forthcoming.
On Fri, Jun 8, 2012 at 3:43 AM, Thomas Broyer wrote:
>
> Let me clarify: how are native events mapped to DomEvents?
>
The event is guessed from the type of the first parameter in the event
handler. DragStartEvent.getAssociatedType() == "dragstart"
> (Dr
Just to finish this off in case anyone else has the same problem -
this was fixed in r11031.
https://code.google.com/p/google-web-toolkit/source/detail?r=11031
On Wed, Jun 6, 2012 at 6:52 PM, Chris Price wrote:
> I've just tried to take the demo for a spin but I had a few problems
> trying to co
Yep, you're on the CLA list.
On Fri Jun 08 05:15:45 GMT-400 2012, James Horsley
wrote:
> Just to check, was everything okay with the CLA I signed?
>
> On 7 June 2012 16:56, James Horsley wrote:
>
> Thanks Rajeev. Let me know if there's anything else you need with it.
>
>
> On 7 June 2012 16:18,
Reviewers: rdayal,
Description:
Complete text-* support for Style
Reposting of 1736803
Thanks Patrick!
Please review this at http://gwt-code-reviews.appspot.com/1737804/
Affected files:
M user/src/com/google/gwt/dom/builder/client/DomStylesBuilder.java
M user/src/com/google/gwt/dom/builde
Moving org.json into gwt-dev makes sense because the compiler actually
uses it. I'd like to see it repackaged, but perhaps we can wait until
someone complains?
I'm not sure about validation. Many people don't use it and I sorta
think GWT's validation support ought to be split out of gwt-user into
LGTM. With a Nit.
http://gwt-code-reviews.appspot.com/1565806/diff/8001/user/test/com/google/gwt/editor/client/DirtyEditorTest.java
File user/test/com/google/gwt/editor/client/DirtyEditorTest.java
(right):
http://gwt-code-reviews.appspot.com/1565806/diff/8001/user/test/com/google/gwt/editor/cli
Line length.
Oh no! That was completely fine before adding those generics. :-)
I was putzing around with ant trying to get it to fail the compile so
didn't have Eclipse to flag the error.
Resubmitting.
http://gwt-code-reviews.appspot.com/1565806/
--
http://groups.google.com/group/Google-Web-
>
> Just to finish this off in case anyone else has the same problem -
> this was fixed in r11031.
>
> https://code.google.com/p/google-web-toolkit/source/detail?r=11031
>
Thanks for the info. I had the same problem but now it works. Now lets hope
the compilation process will become a lot fas
I'm definitely interested in getting simple servlets to run in Super
Dev Mode in a way similar to classic Dev Mode. I haven't investigated,
so I don't know if it's better to reuse the existing implementation or
write a fresh one and leave behind some crud.
I don't think we want to try too hard to
I was putzing around with ant trying to get it to fail the compile so
didn't have Eclipse to flag the error.
Huh, I thought I had Eclipse configured to show checkstyle errors like
that--but I don't see it. I see other errors like methods not in
alphabetical order.
Resubmitting.
I hope the
LGTM
On 2012/06/08 18:27:29, stephenh wrote:
> I was putzing around with ant trying to get it to fail the compile
so didn't
have Eclipse to flag the error.
Huh, I thought I had Eclipse configured to show checkstyle errors like
that--but
I don't see it. I see other errors like methods not i
>
> I'm not sure about validation. Many people don't use it and I sorta
> think GWT's validation support ought to be split out of gwt-user into a
> separate jar. If there's no actual bug than I'm inclined to leave it
> alone for now.
This would absolutely kill compatibility with gwt-validati
Submitted as r11033
http://gwt-code-reviews.appspot.com/1737804/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On Fri, Jun 8, 2012 at 2:26 PM, Brian Slesinsky wrote:
> I'm definitely interested in getting simple servlets to run in Super
> Dev Mode in a way similar to classic Dev Mode. I haven't investigated,
> so I don't know if it's better to reuse the existing implementation or
> write a fresh one and l
> > think GWT's validation support ought to be split out of gwt-user
> > into a separate jar.
>
> This would absolutely kill compatibility with gwt-validation
I know very little about gwt-validation and GWT's javax validation, but
wouldn't having GWT's validation in a separate jar make it easier
On 2012/06/08 18:02:44, skybrian wrote:
Moving org.json into gwt-dev makes sense because the compiler actually
uses it.
I'd like to see it repackaged, but perhaps we can wait until someone
complains?
I'm not sure about validation. Many people don't use it and I sorta
think GWT's
validation
Chris, I'm not sure what you mean by "This". Do you mean the patch as
it stands or something I've been speculating about?
On Fri, Jun 8, 2012 at 11:43 AM, Chris Ruffalo wrote:
> This would absolutely kill compatibility with gwt-validation.
> (https://code.google.com/p/gwt-validation/)
--
http
I guess I didn't make myself clear, I was agreeing. GWT's validation
should *always* be in a separate module from gwt-user. What I should have
said "Otherwise, this would completely kill..."
I don't think that moving javax.validation into gwt-user would be a good
idea. Especially if it comes w
How big is your app? (KLOC) Internally, we'd had success with <10s
refresh on some fairly largish apps. I'm wondering if something else
isn't going on. Note that the first compile usually takes long, but
subsequent ones are faster. Are you using UiBinder? One issue could be
generators using too mu
Okay, I think we should just fix JSON in this patch and figure out
validation as a separate patch.
- Brian
On Fri, Jun 8, 2012 at 12:04 PM, Chris Ruffalo wrote:
> I guess I didn't make myself clear, I was agreeing. GWT's validation
> should *always* be in a separate module from gwt-user. What
Reviewers: rdayal,
Description:
Checkstyle fixes
Repost of 1565806
Thanks Stephen!
Patch by: stephen.haber...@gmail.com
Please review this at http://gwt-code-reviews.appspot.com/1725807/
Affected files:
M
dev/core/src/com/google/gwt/core/ext/linker/impl/StandardPublicResource.java
M de
LGTM.
http://gwt-code-reviews.appspot.com/1733805/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On 2012/05/31 16:11:23, stephenh wrote:
> Ping Ping.
Thanks--added a new patchset with a performance note in the javadocs.
Committed as r11032.
http://gwt-code-reviews.appspot.com/1614806/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On 2012/05/22 16:11:49, tbroyer wrote:
LGTM.
https://gwt-code-reviews.appspot.com/1713803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Submitted as r11034
http://gwt-code-reviews.appspot.com/1565806/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On Fri, Jun 8, 2012 at 8:43 PM, Chris Ruffalo wrote:
>> I'm not sure about validation. Many people don't use it and I sorta
>> think GWT's validation support ought to be split out of gwt-user into a
>> separate jar. If there's no actual bug than I'm inclined to leave it
>> alone for now.
>
>
> Thi
Submitted as r11034
http://gwt-code-reviews.appspot.com/1725807/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Submitted as r11035
http://gwt-code-reviews.appspot.com/1733805/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
I just checked again, one of the internal apps we are trying
SuperDevMode against has about 400,000 lines of code and combines in
about 7-8 seconds. So maybe your app has 6x as much code? If not, it
gives us a clue that perhaps there's some other edge condition causing
the compile to be slow.
-Ray
On Fri, Jun 8, 2012 at 8:46 PM, John Tamplin wrote:
> On Fri, Jun 8, 2012 at 2:26 PM, Brian Slesinsky wrote:
>>
>> I'm definitely interested in getting simple servlets to run in Super
>> Dev Mode in a way similar to classic Dev Mode. I haven't investigated,
>> so I don't know if it's better to re
I've just tried SuperDevMode for the first time. I have around 250KLOC, of
which around 200KLOC are translated to javascript.
The code server reported 3 minutes for the initial compile (with 2
permutations), then 37 seconds for the first compile from the browser, and then
consistently 18-19 se
Hmm, that's still not where we'd like to be. Our design goal is < 10s.
Are you using UiBinder, Gin, ImageResource, I18N, GWT RPC? I'm
wondering if one of the generators may or may not have an issue with
incremental compilation.
This may not do anything, but try it anyway, add these JVM flags
-Dg
lgtm
http://gwt-code-reviews.appspot.com/1729804/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
LGTM
http://gwt-code-reviews.appspot.com/1729804/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
I'm not using UiBinder or Gin.
I am using GWT RPC, I18N and ImageResource.
I have approximately:
- 100 methods across several ClientBundles returning an ImageResource.
- 700 I18N methods spread over about 30 interfaces (my initial 2 permutations
were for the default locale)
- for GWT RPC, I hav
Reviewers: conroy,
Description:
Firefox 13 DevMode Plugin
Please review this at http://gwt-code-reviews.appspot.com/1738803/
Affected files:
M plugins/xpcom/FFSessionHandler.cpp
M plugins/xpcom/JSRunner.cpp
M plugins/xpcom/JavaObject.cpp
M plugins/xpcom/JavaObject.h
M plugins/xpcom/M
Opps, sorry, the speedtracer log is always on anyway. Look in the
super-dev-mode work dir, e.g.
/tmp/gwt-codeserver-*/modulename/speedtracer.html
I think the issue might be that I18N generators don't implement
IncrementalGenerator, and so they run every compile, even if nothing
in your interfaces
I've sent the speed tracer file directly to you.
Also, I have some http GET requests that the code server cannot find (quite
reasonably). It would be nice if it could delegate anything it can't find to
the external tomcat/jetty.
It's also objecting to some of the characters in the URL of some
LGTM
http://gwt-code-reviews.appspot.com/1727806/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On Fri, Jun 8, 2012 at 1:49 PM, Thomas Broyer wrote:
> ServletContainerLauncher is simple enough to be reused here. The
> default implementation based on Jetty 6 could be pushed in a separate
> JAR and the SuperDevMode would warn users if it finds a
> WEB-INF/web.xml, isn't run in -noserver mode,
On Saturday, June 9, 2012 12:24:43 AM UTC+2, Brian Slesinsky wrote:
>
> On Fri, Jun 8, 2012 at 1:49 PM, Thomas Broyer wrote:
>
> > ServletContainerLauncher is simple enough to be reused here. The
> > default implementation based on Jetty 6 could be pushed in a separate
> > JAR and the SuperDe
Reviewers: cromwellian,
Description:
Don't allow enum ordinalization if a custom enum method references
values() directly
Addresses issue 7067
(http://code.google.com/p/google-web-toolkit/issues/detail?id=7067)
Please review this at http://gwt-code-reviews.appspot.com/1730804/
Affected files:
LGTM
http://gwt-code-reviews.appspot.com/1730804/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Reviewers: skybrian, tbroyer,
Description:
Add new CSS FunctionValue type as a first-class representation of value
functions, hook it up into the @def replacer.
This means that gradients can now take @def constants. This also fixes
issues with function arguments losing spaces - no more literal()
This is ready for re-review, BTW.
http://gwt-code-reviews.appspot.com/1727803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
> Well, 3 years ago, BobV removed support for Safari 2 from GWT-RPC:
> http://code.google.com/p/google-web-toolkit/source/detail?r=5666
Cool. I'll work on a patch to update isOrHasChild.
- Stephen
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
51 matches
Mail list logo