Re: [gwt-contrib] Re: Thoughts on DevMode

FWIW my answer to "I want a really awesome debugging experience" is that you shouldn't be doing any debugging in the browser in the first place, e.g. whether it's old-school DevMode or SuperDevMode or Typescript etc. This is what Tessell allowed (apologies for the self-promotion, although I am

Re: [gwt-contrib] Re: Future direction for common JS api's

Interesting; I had not seen JSweet before. The javac -> TypeScript -> JS approach is surprisingly parallel (albeit with different selections) to J2CL's ecj -> closure -> JS. - Stephen On Wed, May 18, 2016 at 8:50 AM Jens wrote: > Given that Elemental 2 is developed

Re: [gwt-contrib] Re: Generator and Linker maintenance and changes

I agree with Thomas and Daniel that it's good to avoid putting more "official" work into the generators, and encouraging people to move off. But I think I agree more with Colin and Jens that, one way or another, people are using generators today, and will be using them for awhile (e.g. if they

Re: [gwt-contrib] Re: Elemental 2?

> Meanwhile I will revive my own generator project. I'll take the opportunity to hop on a soapbox, but the "closed source/eventually open source" model is a curious trend that I think I've only seen in the GWT community (are their other examples?)... Musing, it probably stems from Google setting

Re: [gwt-contrib] Re: Elemental 2?

going be extra work to move the > development outside; which doesn't make sense at this stage. > > The big things we recently developed for GWT, JsInterop and SuperDevMode > and they were all open source from day one. > > On Fri, Nov 20, 2015 at 5:34 AM, Stephen Haberman < > st

Re: [gwt-contrib] Re: GWTCon 2015 keynote question

t js wrapper to gwt3 >> On 16 Nov 2015 11:29, "Robert Stone" <rob.a.st...@gmail.com> wrote: >> >>> >>> >>> On Sunday, 15 November 2015 15:37:29 UTC, Stephen Haberman wrote: >>>> >>>> >>>> My worry about

Re: [gwt-contrib] Re: GWTCon 2015 keynote question

This is an interesting question (what to use for a greenfield GWT project)... > UiBinder: Would need a rewrite to use APT. I guess no one has looked into > it yet. One main issue is that APT won't get triggered when updating > resources (*.ui.xml) > Yeah, I would probably skip APT and just use

Re: [gwt-contrib] Re: GWTCon 2015 keynote question

> > The important thing is to keep an open mind, not trying to force JS > frameworks into our current best practices, and willingness to be inspired > by the best practices of the chosen JS framework. > > Our best practices has emerged from the constraints of GWT, and those > constraints has just

Re: [gwt-contrib] Re: Stop calling it GWT 3.0

https://www.youtube.com/playlist?list=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLE Thanks! I feel dumb, as the gwt-contrib posts were going under the Forums tab in my gmail account, and so I missed the original email/thread go buy. I only stumbled across this thread later via the web. I'll start

[gwt-contrib] Re: Stop calling it GWT 3.0

Sounds like I'm late to party; I missed the 2015 meetup videos, does someone have a link? (That will teach me to not login to G+ very often...well played, Google...) Not that my opinion matters very much (vs. the GWT team who's doing all the actual work), but I'll +100 any plans for

[gwt-contrib] stack trace on master calling List.sort

Sorry for the cheap bug report, but on GWT master, the innocent looking: final ListString f = newArrayList(); f.sort((a, b) - a.compareTo(b)); Will result in a compiler NPE: Caused by: java.lang.NullPointerException at

Re: [gwt-contrib] status of lambdas

Lambdas work fine in master. Great! Thanks! - Stephen -- 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

[gwt-contrib] status of lambdas

Just curious, but what is the state of lambdas on master? Probably works? Known broken in some hairy boundary cases? Being used in production? Thanks, Stephen -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

I'm attempting to follow along. No real input, other than I did not realize the (perhaps obvious) nuance of JS interop handling both importing (e.g. wrapping DOM and existing libraries) and exporting. And how callbacks are both-ish. Huh. - Stephen On Wed, 22 Apr 2015 21:34:27 -0700 'Goktug

Re: [gwt-contrib] Incremental compiler refreshes triggered by IDE touching files

Hi James, This seemed like a pretty interesting thread. Do you still suspect it's an issue? I remember turning on the right logging ~6-12 months ago to see files get incrementally compiled/etc. with SDM first came out, but it's been awhile... I use Eclipse, so if you can refresh my memory with

Re: [gwt-contrib] Re: How to get the full StackTrace when using SuperDevMode in GWT 2.7?

I use the latest trunk and also SDM with incremental compile. @Goktug could you please provide a sample project where obfuscation works which has the correct configuration? FWIW I'm using a snapshot of GWT master from ~last week, SDM, Chrome 40.0.2214.28, and when I set a breakpoint in

Re: [gwt-contrib] Re: two errors in master

Wow, that's great, Jens! Thanks for digging in to this. - Stephen -- 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

Re: [gwt-contrib] Re: two errors in master

So I think we really have a GWT issue. Great detective work, Jens. I agree, it looks like these type parameters only cause confusion to the GWT compiler, and not to regular the Java/Eclipse compilers. Given that GWT embeds JDT, I wonder if it's a bug in the version of JDT we're currently

[gwt-contrib] Re: two errors in master

Okay, okay, sorry for all the emails, but I ditched sourceLevel 1.8 and am now just playing with the new cached-SDM... Wow. It's awesome. Great work! I was hesitant to move our app over to 2.7.0, but this, this is nice. - Stephen -- You received this message because you are subscribed to

Re: [gwt-contrib] Re: two errors in master

Maybe I'll go try and build a 1.8 version of Guava and see if the issue is in Guava itself? Not sure. I was pretty surprised to find that Guava doesn't compile for 1.8: https://github.com/google/guava/issues/1738 But not at all for the reason/compile errors I was getting (which were related

[gwt-contrib] two errors in master

Hi, Given that the reuse-SDM cache patch (+ various Java 8 patches, hot damn) landed, I tried our app with master. I'm seeing two issues: 1. A transient/only-happened-once ConcurrentModificationException: https://gist.github.com/stephenh/6e32c3077b67769e46cb 2. Some compile errors related to

[gwt-contrib] Re: two errors in master

Note that in my previous email, both errors came from running (Super)DevMode, but FWIW the Guava errors also occur in a regular production compile (which I was not anticipating). - Stephen On Sunday, November 30, 2014 4:24:21 PM UTC-6, Stephen Haberman wrote: Hi, Given that the reuse-SDM

[gwt-contrib] Re: two errors in master

Note that in my previous email, both errors came from running (Super)DevMode, but FWIW the Guava errors also occur in a regular production compile (which I was not anticipating). Ah, crap, I had thought checked for this, but I had mistakenly introduced a 2nd variable: source level. In

Re: [gwt-contrib] JsInterop retrofit

I will try to summarize my thought process and different options that I have played with so that you could get a better understanding where I'm coming from and I hope it will provide good documentation for future. Thanks for the email; I think the format was really useful. One may argue

Re: [gwt-contrib] GWT 2.7.0-RC1 is available

When running DevMode (the Swing UI) with gwt-2.7.0-rc1 installed from Maven central, without gwt-codeserver on my classpath, I get: Caused by: java.lang.NoClassDefFoundError: com/google/gwt/dev/util/arg/JsInteropMode at com.google.gwt.dev.codeserver.Options.init(Options.java:79) at

Re: [gwt-contrib] GWT 2.7 : precompile and incremental flags

if (child.getName().equals(.svn)) // hardcoded filter here Just curious, but didn't svn change (maybe a year ago or so?) to only using one top-level .svn folder, similar to Git's top-level .git folder, and not having .svn littered throughout the file system? - Stephen -- You received

Re: [gwt-contrib] Re: odd super dev mode times

I think it's in master now (commit 14f27064497f1171907d0ecbe01a4d2991a7a855) Oh shoot; I was wondering if that's what Roberto was referring to. I assumed 2.7-beta1 already had that fix, because I saw it on the release/2.7 branch in gerrit (and a few commits down/non-cherry picked). However,

Re: [gwt-contrib] Re: odd super dev mode times

However, right, it didn't actually make it into 2.7-beta1. Crap. Eclipse was lying to me, and had a 2.6.x source jar hooked up to gwt-dev-2.7-beta1.jar (don't ask) when I pulled up PersisentUnitCache in my project to check for the change. So: a) 2.7-beta1 does have John's 14f2706 fix, and b)

Re: [gwt-contrib] Re: odd super dev mode times

I think that CL is only on master. Thats why I said try master and if it works send me a cherry pick for the CL :) $ git branch -a --contains 14f27064497f11 master * release/2.7 remotes/gerrit/HEAD - gerrit/master remotes/gerrit/master remotes/gerrit/release/2.7 I also opened the

[gwt-contrib] odd super dev mode times

Hi, I'm trying out GWT 2.7.0-beta1, and am seeing kind of odd recompile times. (Our app is ~70k LOC, and the main/only generators are GWT-RPC and UiBinder.) The first compile take 40s. Then, only changing a single char in a .java file, the first recompile takes 20s. Then each next one takes

[gwt-contrib] Re: odd super dev mode times

...and, right now, I can't even get the 3s time to kick in again. Ah ha...seems to be something with the PersistentUnitCache. When the recompile is 10-20s every time, I see output of: Wrote 4944 units to persistent cache Wrote 1 units to persistent cache (reload) Wrote 4944

Re: [gwt-contrib] Re: odd super dev mode times

depends on how many files are modified [+ invalidations] Yeah, sorry, I should have mentioned I've only been changing one file, just adding/removing a character in a string. John detected that behavior in the persistent unit cache and has a fix for it. Great! I'll try it out when it hits

Re: [gwt-contrib] Re: calling onLoadErrorFn on permutation 404

- User starts loading old nocache.js, you tell load balancers to redirect to the new app, the nocache.js runs and tries to load an old permutation from a new server where it doesn't exist. Right. I suppose Stephen's deployment strategy is different Yeah, slightly. Currently, if we have

[gwt-contrib] calling onLoadErrorFn on permutation 404

Hey, During our deployments, we have a small window where both old/new servers could potentially be available. I'm trying to hook into the failure of when a client loads the .nocache.js from one version, but tries to get the permutation from another. Currently what happens is that the

[gwt-contrib] class cast exception in ff 17

Hey, I know FF17 is pretty old, but do we care about breakages in it? We noticed some client-side ClassCastExceptions in our logs that are from a user on FF17. The app works fine in FF latest. The exception is odd, because, according to the de-obfuscated stack trace, given a class hierarchy

Re: [gwt-contrib] class cast exception in ff 17

It might be related to the bug[1] that mdempsky@ filed to Firefox earlier. The Firefox's VM was causing an incorrect polymorphic dispatch sometimes. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=872796 Ah, nice! Thanks (Jens too) for saving me the trouble of trying to reproduce that. I

[gwt-contrib] minor sdm bug

Hey, I was trying SDM on a project today, via the -superDevMode flag that was added to DevMode (great work). It worked really well on one project, and then on another I kept getting the GWT needs (re)compiled that's from the old module.nocache.js. Turns out I had a module.nocache.js.gz artifact

Re: [gwt-contrib] Proposal for a generic accessor for GWT properties

https://docs.google.com/document/d/1LEP0H-6z__Mog0QTt-NAFpllcOGu7X5gr7KR32BIT4Y/edit?usp=sharing Spiffy. Of my excitement, 20% of it is because I like this feature, and 80% of it is because there is actually a public design doc before the CL hits trunk. :-) Really cool. I like the keyspace

Re: [gwt-contrib] Future of Renderable and PotentialElement?

The point was more about Orkut announcement doesn't change anything and cannot effect the decision from our perspective; as long as the system is running we need to take care of it. Right, sorry...I thought that the annoucement was exactly that: it would no longer be running, soon (end of

Re: [gwt-contrib] Future of Renderable and PotentialElement?

My point was more about, don't think Orkut announcement as we can't delete it now as Orkut is no more; I might have misinterpreted that. Cool, that makes sense. Maybe you can give us a heads up when Orkut is gone from the Google repo, and then we can revisit PotentialElement's future. I

Re: [gwt-contrib] Last call for GWT 2.6.1

Hi Daniel, If you want to get your changes into GWT 2.6.1, they need to get in before Friday. Selfishly, our app is depending on this patch now: https://gwt-review.googlesource.com/#/c/6780/ I know it's not a bug fix, but it's pretty simple; I assume it's find to cherry pick into 2.6.1? I

Re: [gwt-contrib] Re: Can we move the code to GitHub?

We're starting seeing integrations between Gerrit and GitHub (http://gerrithub.io/) Ooh, that looks spiffy. Thanks for the link, Thomas. From Benjamin's reply: I think other UI frameworks/platforms like AngularJS are gaining more traction/adoption because they are accessible through

Re: [gwt-contrib] Re: Classloader issues for server-side code in DevMode with GWT 2.6

Neither one (depending on your build tool though). Sure, I get that Maven/Gradle/Ant will go through a copy-to-target step first, and so not use any src/... artifacts. So, for them, having the Jetty classloader not use the project classpath makes sense. But at least we way run DevMode in

Re: [gwt-contrib] Re: Classloader issues for server-side code in DevMode with GWT 2.6

Hi Thomas, (or rather, it'll work too well, and won't detect that something is missing in WEB-INF/lib. I'm attempting to follow along, but classloader semantics are fun, so apologies if I'm wrong somewhere... So, to clarify, if I have a dependency, say foo.jar, that isn't GWT, and isn't

Re: [gwt-contrib] Re: final fields patch

Hi Jens, If thats the case you might break people who have final fields whose types are not compatible to GWT-RPC serialization. If this is happening today, and this fix started serializing EnumSet where before it was not, I would again assert the new behavior is the correct behavior, so the

[gwt-contrib] final fields patch

Hey, At one time I was shepherding through the GWT-RPC patch for supporting final fields. One of the unpleasant aspects of the patch as that, instead of just fixing the bug, and serializing final fields always, there was a knob of serialize final fields true, false, and false_nowarn. This,

[gwt-contrib] Re: bug in permutations.js?

Here is the difference in the generated JS. From a ~10/2013 trunk build: function com_google_gwt_dom_client_StyleInjector_StyleInjectorImpl(){ switch (permutationId) { case 1: case 2: case 3: return new StyleInjector$StyleInjectorImplIE_0; } return new

Re: [gwt-contrib] bug in permutations.js?

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

[gwt-contrib] bug in permutations.js?

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

Re: [gwt-contrib] Re: bug in permutations.js?

and only permutations.js assigns it to another value (but does so conditionally, so it never *assigns* undefined to __softPermutationId, it just leaves it not defined). But line 61: https://gwt.googlesource.com/gwt/+/master/dev/core/src/com/google/gwt/core/ext/linker/impl/permutations.js

Re: [gwt-contrib] bug in permutations.js?

Want to add that to the issue tracker? Sure, I'll do that soon... I wonder why more people aren't seeing this? Does it only affect soft permutations? Removing collapse-all-properties does fix it. I'll do that for now and then work on submitting a patch. No idea how I would add a test for

Re: [gwt-contrib] Rebinding Methods improvement proposal and working prototype

It's curious, I googled about Java 8 compiler plugins when RayC said that you talked about a new code-gen feature in Java 8 Ha, yes, that is curious. I guess my memory has never been that great... I hope it will be formalized in future Java versions Ah, that makes sense, since APT followed

Re: [gwt-contrib] Rebinding Methods improvement proposal and working prototype

implemented as a Java 8 compiler plugin (extension point) Interesting! I had not heard of these before: http://techbitsfromsridhar.blogspot.com/2013/02/java-compiler-plug-ins-in-java-8-use.html It looks like these compiler plugins use com.sun packages, and are not a JSR, which AFAIK means no

Re: [gwt-contrib] elemental templates

Yes. We are planing to revive elemental based on new @JsInterface proposal and have web-components-like widget system on top of that. Nice! I'll look forward to your proposal. - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because

[gwt-contrib] elemental templates

Hey, Just curious, but what's the story around templating for Elemental? Googling around seems like it's not supported by UiBinder. Is there anything coming along/WIP internally? Will Goktug's new widget proposal be based on Elemental? I'm just curious as, after glancing at it again, I finally

Re: [gwt-contrib] Deprecating DeRPC classes

Hi Naresh, Could you please let me know is there any patch available to check the impact of removing de rpc calls. I'm glad you're interested in looking in to this. Unfortunately, I don't really know much about DeRPC. There are probably others on the gwt-contrib list who do though...we'll see

Re: [gwt-contrib] Re: Deprecating and moving AsyncProxy out of SDK

Never used it Same here, so +1 to your plans to extract it. - 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

Re: [gwt-contrib] Re: GPE does not like GWT trunk SDK?

Hi Rajeev, Good to hear from you. We're in the process of moving the GPE source to github (and converting the build system to Maven/Tycho so that external developers can build it) , which is why that repo hasn't been updated in a long time. I'll update the homepage to reflect that. Sounds

Re: [gwt-contrib] Re: GPE does not like GWT trunk SDK?

have not been updated to @GWT_GITREV@. Thanks! Good catch. https://gwt-review.googlesource.com/#/c/5194/ - 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

Re: [gwt-contrib] Re: GPE does not like GWT trunk SDK?

I was going to ask how active the GPE project is...is the last commit really from October 2012? https://code.google.com/p/google-plugin-for-eclipse/source/list That doesn't seem right, but AFAICT there isn't another source repo? https://developers.google.com/eclipse/community - Stephen --

Re: [gwt-contrib] being cute with git describe

- do we really want to keep the 0.0.0 special version? (would it really hurt if master currently said 2.5.1-250-g4a00f1e?) FWIW I like 0.0.0 because it strongly differentiates hand-made/master releases vs. official/release branch releases. And it always sorts before release versions, which

Re: [gwt-contrib] being cute with git describe

I was thinking about something like that too. I actually kinda like it, and it gives an easy monotonic counter for tracking master. Agreed. I don't think we're using proper git tags yet. The 'tags' currently in the tree for 2.5.1, etc that were imported from SVN are actually just regular

Re: [gwt-contrib] Gerrit presubmit changes

Wow, that sounds awesome, Matthew. Great work. I'm looking forward to hopefully *not* triggering this great feedback. :-) - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors

[gwt-contrib] being cute with git describe

Hey, So, I was toying with changing git.version over to being based on git describe output, instead of having to pass in GWT_VERSION. The default behavior of git describe is to fail if no tags are found, which it does on master, and this is fine because then we want the 0.0.0 version for

Re: [gwt-contrib] Re: gwt.svnrev

AFAICT, this error only appears if you converted a git svn repo to plain git (i.e. added the googlesource repo and simply do not use git svn any longer) Ah, you are right! That makes more sense...I was fairly incredulous that no one else would have noticed this by now. and I'm not sure it's

[gwt-contrib] gwt.svnrev

Hey, I was building GWT master (ant dist-dev) and am getting an error in common.ant.xml when it tries to call git svn info, as it must think my working copy is still from the old svn repo. I can work on changing this over to just a git describe, but was curious if anyone had ran into this

Re: [gwt-contrib] gwt.svnrev

The closest is Daniel was working on adding a commit-id file Cool, thanks for the link, I had not seen that. Do you know what the idea of the commit-id file was? A replacement for this gwt.svnrev.filename? Looking at About.java, I think it makes sense/would be easy to replace gwt.svnrev with

Re: [gwt-contrib] Thoughts on dropwizard framework as a backend for GWT

I find the approach of flatpack-java from Perka interesting. That does sound nifty; thanks for mentioning it, Jens. I know everyone is scarred from the SOAP debacle, but I'm still surprised that there isn't a defacto web API schema by now. Seems like there have been quite a few attempts ([1]

Re: [gwt-contrib] Thoughts on dropwizard framework as a backend for GWT

Seems like there have been quite a few attempts ([1] is nice), but it doesn't seem like one has ever become widely used. After looking at flatpack, I remember why I don't think it will take off: it (AFAIK) assumes the server-side is Java/JPA/annotations/etc. Swagger looks nice [1] [2] as

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)

Hi John, Thanks for the great responses. do you still have to retranslate the *entire* AST to Javascript source (and is the resulting process still fast if you have to do so)? Yeah, good question...seems like in an ideal world you could cache the JS string for each compilation unit and then

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)

Hey John, it means having an optional compilation path that does not recompile the entire world (as the current monolithic compile path does) and instead tries to recompile just files (or or modules) that have changed. Spiffy! Out of curiosity, would the API look something like:

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)

Hi John, Thanks for reminding me about this... The problem is let's say you change file A. Two things: First is that AFAIK GWT already does this...see the Dependencies class, which I became familiar with when trying to build a list of dependencies for Scala-GWT ASTs so they could fit in this

Re: [gwt-contrib] Re: Google team meeting notes for August 7 (and earlier)

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

Re: [gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

because I don't want to spend so much extra time working on something that people don't really care about. I'm sure many people, current GWT committers included, care very much about bug fixes/improvements to the stack trace deobfuscation code. Unfortunately, I doubt that translates to

Re: [gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

Hi Alex, By the way, who wants to try it? Please get it touch with me (alex at typeracer.com), and I will email you my patch so you can see for yourself how awesome it is. Instead of emailing a patch, how about just uploading it here: https://gwt-review.googlesource.com/#/ I do not think

[gwt-contrib] Change in gwt[master]: Optimize initializing fields at the top scope.

Stephen Haberman has submitted this change and it was merged. Change subject: Optimize initializing fields at the top scope. .. Optimize initializing fields at the top scope. Change-Id

[gwt-contrib] Change in gwt[master]: Optimize initializing fields at the top scope.

, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500 Gerrit-PatchSet: 9 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Stephen Haberman stephen.haber...@gmail.com Gerrit-Reviewer: Brian Slesinsky skybr

[gwt-contrib] Change in gwt[master]: Optimize initializing fields at the top scope.

Stephen Haberman has posted comments on this change. Change subject: Optimize initializing fields at the top scope. .. Patch Set 6: (1 comment) Okay, I went with the conservative approach. I'll look forward to hearing

[gwt-contrib] Change in gwt[master]: Optimize initializing fields at the top scope.

Stephen Haberman has posted comments on this change. Change subject: Optimize initializing fields at the top scope. .. Patch Set 5: (2 comments) File dev/core/src/com

[gwt-contrib] Change in gwt[master]: Optimize initializing fields at the top scope.

, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500 Gerrit-PatchSet: 6 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Stephen Haberman stephen.haber...@gmail.com Gerrit-Reviewer: Brian Slesinsky skybr

[gwt-contrib] Change in gwt[master]: Optimize initializing fields at the top scope.

Stephen Haberman has posted comments on this change. Change subject: Optimize initializing fields at the top scope. .. Patch Set 6: (2 comments) Thanks all, for continuing to vet the patch

[gwt-contrib] Change in gwt[master]: Optimize initializing fields at the top scope.

, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500 Gerrit-PatchSet: 7 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Stephen Haberman stephen.haber...@gmail.com Gerrit-Reviewer: Brian Slesinsky skybr

[gwt-contrib] Change in gwt[master]: Optimize initializing fields at the top scope.

, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500 Gerrit-PatchSet: 8 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Stephen Haberman stephen.haber...@gmail.com Gerrit-Reviewer: Brian Slesinsky skybr

[gwt-contrib] Change in gwt[master]: Optimize initializing fields at the top scope.

Stephen Haberman has posted comments on this change. Change subject: Optimize initializing fields at the top scope. .. Patch Set 6: (1 comment) File dev/core/src/com

[gwt-contrib] Change in gwt[master]: Optimize initializing fields at the top scope.

Stephen Haberman has posted comments on this change. Change subject: Optimize initializing fields at the top scope. .. Patch Set 3: (1 comment) File dev/core/src/com

[gwt-contrib] Change in gwt[master]: Optimize initializing fields at the top scope.

Stephen Haberman 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

[gwt-contrib] Change in gwt[master]: Optimize initializing fields at the top scope.

Stephen Haberman has posted comments on this change. Change subject: Optimize initializing fields at the top scope. .. Patch Set 5: Tweaked some comments. -- To view, visit https://gwt-review.googlesource.com/3440

[gwt-contrib] Change in gwt[master]: Optimize initializing fields at the top scope.

https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset 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

[gwt-contrib] Change in gwt[master]: Optimize initializing fields at the top scope.

Stephen Haberman has posted comments on this change. Change subject: Optimize initializing fields at the top scope. .. Patch Set 2: (1 comment) File dev/core/src/com

[gwt-contrib] Change in gwt[master]: Optimize initializing fields at the top scope.

https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500 Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Stephen Haberman stephen.haber...@gmail.com Gerrit-Reviewer: Brian Slesinsky skybr

[gwt-contrib] Change in gwt[master]: Optimize initializing fields at the top scope.

Stephen Haberman has posted comments on this change. Change subject: Optimize initializing fields at the top scope. .. Patch Set 1: (1 comment) File dev/core/src/com

[gwt-contrib] Change in gwt[master]: Add interfaces for widgets.

Stephen Haberman has posted comments on this change. Change subject: Add interfaces for widgets. .. Patch Set 8: doesn't fit into current IsXXX because if it was you wouldn't need IsWidget2 :) My take is that it's just

[gwt-contrib] Change in gwt[master]: Add interfaces for widgets.

Stephen Haberman has posted comments on this change. Change subject: Add interfaces for widgets. .. Patch Set 8: Hi Colin, the only approach in selecting classes is that these are what I'd used so far, plus a few others

[gwt-contrib] Change in gwt[master]: Add interfaces for widgets.

Stephen Haberman has posted comments on this change. Change subject: Add interfaces for widgets. .. Patch Set 8: Hi Goktug, Being said that, rest assured, I wouldn't -1 for just not using it. Good, good--sorry if I got

[gwt-contrib] Change in gwt[master]: Fix binary vs. internal variable names, remove unused Name c...

Stephen Haberman has uploaded a new change for review. https://gwt-review.googlesource.com/3470 Change subject: Fix binary vs. internal variable names, remove unused Name code. .. Fix binary vs. internal variable names

[gwt-contrib] Change in gwt[master]: Fix binary vs. internal variable names, remove unused Name c...

Stephen Haberman has posted comments on this change. Change subject: Fix binary vs. internal variable names, remove unused Name code. .. Patch Set 1: There are no semantic changes here, just updating variable names

[gwt-contrib] Change in gwt[master]: Optimize initializing fields at the top scope.

Stephen Haberman has posted comments on this change. Change subject: Optimize initializing fields at the top scope. .. Patch Set 1: (1 comment) File dev/core/src/com

[gwt-contrib] Change in gwt[master]: Optimize initializing fields at the top scope.

Stephen Haberman has uploaded a new change for review. https://gwt-review.googlesource.com/3440 Change subject: Optimize initializing fields at the top scope. .. Optimize initializing fields at the top scope. Change-Id

[gwt-contrib] Change in gwt[master]: Add interfaces for widgets.

Stephen Haberman has posted comments on this change. Change subject: Add interfaces for widgets. .. Patch Set 7: Okay, I think this is ready for another cursory review--I'm still mulling about how to do the javadocs. Also

[gwt-contrib] Change in gwt[master]: Optimize initializing fields at the top scope.

Stephen Haberman has posted comments on this change. Change subject: Optimize initializing fields at the top scope. .. Patch Set 1: (1 comment) File dev/core/src/com

  1   2   3   4   5   >