Could you compile both working and not working with -style PRETTY.
That would make it easier to map to Java.
On Oct 25, 2015 05:23, "Ignacio Baca Moreno-Torres"
wrote:
> function ILe(a) {
> var b;
> b = Erb(PDl(a.a, 'REFXXX store'), 164);
> Erb(PDl(Erb(b.De(), 82), 'REFXXX store.get()'), 8
Also could you try the equivalent lamda that is not a method reference, i.e
(parameters) -> this.processResponse(params);
I looked at the way we construct the innerclasses corresponding to lambdas
and it looks ok.
It would really help if you could narrow it down to a small reprocase that
I can
Use Bug-link, see https://gwt-review.googlesource.com/#/c/13710/
On Sun, Oct 25, 2015 at 5:25 AM, Jens wrote:
> Hi,
>
> In Gerrit "Bug: issue " points to Google Code. Do we already have an
> alternative wording for cross linking to Github? Something like "Bug:
> #" maybe?
>
> -- J.
>
> -
Bootstrap using lambda (fail)
// java
return service.get().getBootstrap().bootstrap().doOnNext(data -> {
Account account = data.getAccount();
if (account == null) auth.get().resetSessionData(false);
else auth.get().setSessionData(account, data.getKeychain());
theme.get().setCustomi
I said that optimize=0 fix errors, but I just compiled the project a get
the same bootstrap+lamba error. But with draftCompile the result looks ok.
// bootstrap case, lambda, pretty, draftCompile
_.lambda$5 = function lambda$5(data_0){
$clinit_ApplicationBootstrapper();
var account, user;
It looks to me like it might be a type inferencing issue Roberto. Remember,
the lambda is matched to a SAM interface method. When it synthesizes the
implementation, it takes info from JDT about the 'expected type' which is
inferred by JDT. I wonder if the type inferred messes up type tightener
some
Is the data that flows in the lambda an object created by your Java
applications or does it flow from JavaScript?
On Mon, Oct 26, 2015 at 1:48 PM, 'Ray Cromwell' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:
> It looks to me like it might be a type inferencing is
>
> I did not use pretty style because I thought that this flag produces
> different result, I tested now and looks like the output is the same, but,
> I'm pretty sure that some flags changes this issues, optimize is obvious
> that fixes the problem, but I think that namespace=package also changes
It would be really helpful if you could isolate your problem to a small
example.
On Mon, Oct 26, 2015 at 2:39 PM, Roberto Lublinerman
wrote:
> I did not use pretty style because I thought that this flag produces
>> different result, I tested now and looks like the output is the same, but,
>> I'm
