I'll try to keep it short...
> When I’m trying to find out why my presentation layer DOM element didn’t
> receive some DOM attribute as result of computation, this is bug in the
> presentation layer, which was abstracted together with browser in your
> approach
>
Yes, you can assert/debug against
ocalhost is fast enough
>
> Thomas Broyer: Even moving towards Typescript in GWT architecture, there’s
> still big value of Java as language due to code reuse.
>
> Thomas Broyer: js-java glue that was related to codeserver for DevMode is
> already in rotten state.
>
> Stephen
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 men
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 behind closed doors, I wou
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 pur
be part of GWT-SDK so there is 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 a
> 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
I'm attempting to use icons in an svg file in a ui.xml file like:
But with a variable, so:
However, because of the xlink namespace (which the browser requires,
AFAICT), UiBinder and SafeHtml end up disagreeing on whether this is a
SafeUri-requiring attribute.
E.g. here is the UiBinde
wrapper to gwt3
>> On 16 Nov 2015 11:29, "Robert Stone" wrote:
>>
>>>
>>>
>>> On Sunday, 15 November 2015 15:37:29 UTC, Stephen Haberman wrote:
>>>>
>>>>
>>>> My worry about "just pick a mainstream JS framewo
>
> 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 c
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 a
>
> 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 cat
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 large/break
Sorry for the cheap bug report, but on GWT master, the innocent looking:
final List f = newArrayList();
f.sort((a, b) -> a.compareTo(b));
Will result in a compiler NPE:
Caused by: java.lang.NullPointerException
at com.google.gwt.dev.jjs.ast.JMethod.getJsniSignature(JMethod.java:518)
> 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 google-web-toolkit-contributors+unsubscr...@google
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 an
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 s
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 Gok
> 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 FooP
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 google-web-toolkit-contributors+unsubscr.
> 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 usi
> 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
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 th
> 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.
I
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 th
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 gu
> 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 argu
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.(Options.java:79)
at com.google.gwt.de
> 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
Well, this is somewhat anti-climatic, but, AFAICT, it was just
MemoryUnitCache's maps using soft values.
Instead of turning on TRACE everywhere, I upgraded
MinimalRebuildCache's "known modified type" output to WARN. (It would
be great to have log4j-style package-level knobs in the GWT log
output.
> 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 2.
> 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) e
> 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, r
> 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
> ...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 un
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
consi
> - 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
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 permutation
> 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
tha
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 like:
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
.nocache.js.
Turns out I had a .nocache.js.gz artifact that was f
> 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 di
> 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.
> 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 S
> Even Orkut closing the doors, it doesn't mean their code is going away
> anytime soon :)
You're killing me, Goktug. The backwards compatibility knife had
already pierced my heart, and this just shimmied it around a bit. :-)
I had to refresh on memory on PotentialElement, but it looks virtual
D
I've not looked at the code, but I'll chime in my support for Manuel's
approach--I think the JettyLauncher/SuperDevMode class would be the
easiest transition path for us.
(Not all of our devs use GPE, so while the facets sound spiffy/etc.,
hopefully they would be an alternative and not a replacem
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 c
> 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
> 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 Eclip
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'
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
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, coupl
> 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
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 StyleInjector$StyleI
> 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
> 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
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
> 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 follow
> 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 n
> 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
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 n
> 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
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 se
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.
Sound
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
--
ht
> 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
>- 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, whic
> 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 reg
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
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
> 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
> 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 wit
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 bef
> 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 bei
> 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]
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
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
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:
theB
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
Contribut
> 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 brea
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
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
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 he
cribe, 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
Gerrit-Reviewer: Brian Slesinsky
Gerrit-Reviewer: Leeroy Je
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
cribe, 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
Gerrit-Reviewer: Brian Slesinsky
Gerrit-Reviewer: Leeroy Je
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
cribe, 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
Gerrit-Reviewer: Brian Slesinsky
Gerrit-Reviewer: Leeroy Je
cribe, 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
Gerrit-Reviewer: Brian Slesinsky
Gerrit-Reviewer: Leeroy Je
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
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
To
cribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
Gerrit-PatchSet: 5
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman
Gerrit-Reviewer: Brian Slesinsky
Gerrit-Reviewer: Leeroy Je
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
cribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
Gerrit-PatchSet: 4
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman
Gerrit-Reviewer: Brian Slesinsky
Gerrit-Reviewer: Leeroy Je
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
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
visit 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
Gerrit-Reviewer: Brian Slesinsky
Gerrit-Reviewer: Leeroy Je
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
Stephen Haberman has posted comments on this change.
Change subject: Optimize initializing fields at the top scope.
..
Patch Set 2:
Okay, I added a visitor to detect cstrs with polymorphic method calls.
Thanks, Roberto
visit 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
Gerrit-Reviewer: Brian Slesinsky
Gerrit-Reviewer: Leeroy Je
1 - 100 of 520 matches
Mail list logo
