(just in case someone read this thread) This problem has already been fixed
in 2.8.0-SNAPSHOT. Thanks.
On Tuesday, October 27, 2015 at 9:17:47 PM UTC+1, Ignacio Baca
Moreno-Torres wrote:
>
> At last!
> https://github.com/ibaca/gwt-instantiable-inference-bug/blob/master/src/main/java/com/bacamt/
At
last!
https://github.com/ibaca/gwt-instantiable-inference-bug/blob/master/src/main/java/com/bacamt/ibaca/client/Bug.java
As Roberto said, the problem seems to be the instantiability inference. The
project works correctly on draftCompile, but on optimized compile the
lambas parameters gets n
Tests:
- Create a variable with the lambda to fix type inference; did not work.
- Add a EntryPointDataOverlay.create() factory (not called); did not
work.
- Add EntryPointData data = new EntryPointDataPojo() before lambda; did
not work, but now data_0 is not null, but its metho
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
>
> 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
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
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
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;
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
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
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
function ILe(a) {
var b;
b = Erb(PDl(a.a, 'REFXXX store'), 164);
Erb(PDl(Erb(b.De(), 82), 'REFXXX store.get()'), 82);
return Erb(PDl(undefined, 'REFXXX store.get().values()'), 6)
}
This was the actual b.De() function.
u9c(701, 1, { 164: 1, 701: 1, 3: 1 }, Uh);
_.De = function Vh() {
Sorry, this is pretty confusing, just comment that the lamba cases
described previously still (in HEAD) get solved when lamdas are changed to
anonymous classes.
On Sunday, October 25, 2015 at 12:08:09 PM UTC+1, Ignacio Baca
Moreno-Torres wrote:
>
> Next, I show two methods, this.getResource and
Next, I show two methods, this.getResource and the 'this' constructor.
getResource get wrong because the output never assigns the map variable.
And the constructor is showed to see how this.store is assigned. This time,
the anonymous class do not solves the problem.
public Collection> getResou
Recompiled using HEAD dcea13b1d223513418c90c34324ac6929059de3c, with no
JsInterop and optimization 1.
function $Xj(a, b) {
var c, d, e, f;
JDl(b, 'response required');
JDl(null .V0(), 'response.uuid required');
a.g = null .V0();
c = false;
for (f = null .V0().V0(); f.Md();
The only thing I can think of is that when the class is created for the
lambda in gwtastbuilder, the super class or implemented interfaces are not
set up correctly.
I'll check later to see if that is there case.
On Oct 24, 2015 19:07, "'Ray Cromwell' via GWT Contributors" <
google-web-toolkit-cont
Are you using @JsFunction/JsInterop? Unless the implementation has changed
recently, Lambda's are supported in GWT by essentially synthesizing static
inner classes, and so if static inner classes work, but lambda's don't,
it's really weird. The optimization stages no nothing of lambdas and only
see
This was from 94e45975a06ece1b8d65541aaabf833f9d8c7b07 (6 October 2015 at
04:29:19 GMT+2), I'll try tomorrow with HEAD, but looking the commits looks
improbable that the problem has been solved.
On Sat, Oct 24, 2015 at 10:30 PM 'Roberto Lublinerman' via GWT Contributors
wrote:
> Are you using a
Are you using a recent snapshot?
On Oct 24, 2015 04:40, "Ignacio Baca Moreno-Torres"
wrote:
> There is a bug which optimizations nullify variables which might not be
> null. I'm trying to reproduce the error outside our app but I can't, I'll
> continue trying, but for now I going to describe the
There is a bug which optimizations nullify variables which might not be
null. I'm trying to reproduce the error outside our app but I can't, I'll
continue trying, but for now I going to describe the problem.
return service.get().getBootstrap().bootstrap().doOnNext(data -> {
Account account =
20 matches
Mail list logo