[gwt-contrib] Re: Testing GWT 2.9.0 for release

gwt-user depends on jsinterop-annotations:sources (with the sources qualifier), and jsinterop-annotations:sources contains the Annotations.gwt.xml. It really seems right. We have tested in various projects and works perfectly. But, we downloaded a corrupted gwt-user in one of the tests, and we

Re: [gwt-contrib] Re: Java10 support

There are some other bugs recently fixed in eclipse ECJ, at this moment looks a good idea to at least wait for the ECJ 4.9 release. https://bugs.eclipse.org/bugs/show_bug.cgi?id=477894 JRE emulation, hehe just contribute it! (:P) I recommend to create some super source in your project and try

Re: [gwt-contrib] Re: The elusive J2CL

Being slow but mature is a pretty good thing sometimes. As you said, "today's rapidly changing IT" is crazy rapidly, you start a project in a technology that when the project is production ready it might be that technology considered deprecated already. Java and GWT are all about maturity and

Re: [gwt-contrib] Super slow compilation in projects with many wildcard generics

t; On Monday, October 2, 2017 at 8:42:22 AM UTC+2, Ignacio Baca Moreno-Torres > wrote: >> >> FYI The patch will be released for 4.8M3 >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=521438#c17 >> >> On Wednesday, September 27, 2017 at 11:09:43 PM UTC+2, Roberto >

Re: [gwt-contrib] Super slow compilation in projects with many wildcard generics

at 10:56 AM, Ignacio Baca Moreno-Torres < > ign...@bacamt.com > wrote: > >> JDT has a bug (https://bugs.eclipse.org/bugs/show_bug.cgi?id=521438) >> that make it super slow to compile some project involving wildcards >> generics. Actually, there are many problems with perform

[gwt-contrib] Super slow compilation in projects with many wildcard generics

JDT has a bug (https://bugs.eclipse.org/bugs/show_bug.cgi?id=521438) that make it super slow to compile some project involving wildcards generics. Actually, there are many problems with performance and memory consumption since Java 8, this has just lived longer bc it was a bit more difficult

[gwt-contrib] Re: Question about contributing with java.util.concurrent emulation

Definitively I have duplicated some of its super-sources, initially rxjava-gwt dependends on guava bc it super-sourced some pretty common utilities like TimeUnit or Executor, etc. but until I get forced to implement various other classes I just prefer to copy-paste and remove the guava

[gwt-contrib] Question about contributing with java.util.concurrent emulation

I have created various java.util.concurrent and some java.lang super-sources. This makes easier to

[gwt-contrib] Re: $entry() wrapper and JsInterop

that notes about guidelines to use JsInterop+Widget before taking any decision about the future of widgets will be... nice. On Tuesday, July 11, 2017 at 4:11:52 PM UTC+2, Thomas Broyer wrote: > > > > On Tuesday, July 11, 2017 at 1:46:55 PM UTC+2, Ignacio Baca Moreno-Torres > wrote: >

[gwt-contrib] $entry() wrapper and JsInterop

What is going to happen with $entry() utility? Some guidance in the JsInterop gdoc will be a good idea so libs-creator can apply a uniform strategy. Elemento, for example, is waiting to see what to do (https://github.com/hal/elemento/issues/18), but there are various libraries already using

Re: [gwt-contrib] Fwd: jsinterop woes: Part 2: return Double[]

Oh, the classic array problem! ;) https://github.com/gwtproject/gwt/issues/9318 IMO as you are wrapping a client lib, and this code is not going to be shared (used in JRE), so just use elemental2.core.Array. Probably JsArrayLike is enough as an argument but returning an Array it is easier to use.

Re: [gwt-contrib] Re: Elemental2 and JsInterop base beta releases available.

I see, thanks! On Wednesday, May 10, 2017 at 9:28:30 AM UTC+2, Thomas Broyer wrote: > > It was declared as function(number) not long ago: > https://github.com/google/closure-compiler/commit/91500d4cd57a608a442ba7466eb015e9ad40afcf > So next version of jsinterop JARs should have it right. --

Re: [gwt-contrib] Re: Elemental2 and JsInterop base beta releases available.

Question about OscilatorNode (https://github.com/google/closure-compiler/blob/c77ca197a1f6674e4c267a29a3643a86b61cf51d/externs/browser/w3c_audio.js) This start method is translated as a "StartCallbackFunction start", should it not be translated as a method directly? This callback field cannot

Re: [gwt-contrib] Re: Elemental2 and JsInterop base beta releases available.

t; the related elemental class (JsObject) > > On Thu, Apr 13, 2017 at 1:42 PM, Ignacio Baca Moreno-Torres < > ign...@bacamt.com > wrote: > >> Hi, a question about JsPropertyMap. >> >> It does not have a keys() method, ideally using Object.keys, this is

Re: [gwt-contrib] Re: Elemental2 and JsInterop base beta releases available.

Hi, a question about JsPropertyMap. It does not have a keys() method, ideally using Object.keys, this is on purpose? And, the unique method to obtain the keys is the forEach method, but current implementation iterates over all properties wich might be dangerous, why this method do not use

[gwt-contrib] Re: Elemental2 and JsInterop base beta releases available.

Yep, same problem here https://github.com/ibaca/dndfiles-gwt. BUT! if you compile GWT do not fails, only throws this error the codeserver. Anyway, good work! independent libs and specially base lib are really good news! thanks. On Friday, April 7, 2017 at 12:17:57 AM UTC+2, Jens wrote: > >

[gwt-contrib] Re: Stopping Dev Mode (DevMode) Launcher Enhancements

I created this issue with my concern about not using embebed jetty (https://github.com/gwtproject/gwt/issues/9437). For me the main problem is that the codeserver do not uses the auto-recompile.nocache.js, so I use the devmode but the embebed jetty is just to open the client side app, non

Re: [gwt-contrib] GWT Eclipse Plugin (V3) Shortcuts/Launchers

Something like this will be pretty self-explanatory: Super Development Mode (debug in JavaScript, using SDBG or browser tools) Legacy Development Mode (debug in Java, requires deprecated browser plugin) Even better, each parenthesis has the next link respectively:

Re: [gwt-contrib] GWT Eclipse Plugin (V3) Shortcuts/Launchers

This is how I think that newbies will understand it easier... I suppose the change is too big, but maybe some part might be interesting. Any way current state is pretty good! good work. I have re-ordered, leaving the classic devmode the last one. 1. GWT Super DevMode - a client side GWT CodeServer

Re: [gwt-contrib] Re: Eclipse Code Server Launcher Icon

Em... this is kind of related, some days ago I speak about this with manolo in gitter; currently the CodeServer use the standard nocache.js instead of the compile-on-refresh (actually uses the compile-on-refresh the first time, but subsequent compilations uses the standard one). And... does not

Re: [gwt-contrib] Re: Eclipse Code Server Launcher Icon

at way it's obvious. The icon design looks promising >> tho. It has to be 16x16 so it's a bit too tall I think. >> >> >> On Thu, Aug 25, 2016 at 10:31 AM Ignacio Baca Moreno-Torres < >> ign...@bacamt.com> wrote: >> >>> I'll personally prefer the curre

[gwt-contrib] Re: Eclipse Code Server Launcher Icon

I'll personally prefer the current logo (GWT logo) for the codeserver, because I think that the codeserver is the actual GWT part, and for the devmode and web application (which I suppose are a devmode or variants using some java web server) I will suggest a standard server icon plus a small

Re: [gwt-contrib] Thinking about the future: GWT 3, J2Cl, modularization, etc.

Sound really good for us! Also similar to JEE which sync a group of libraries and freezes its version in each releases. The idea of 2.9 to be the modular release without J2CL involved sound good too! I have been thinking in two ideas that might reduces the release and marketing problem

[gwt-contrib] Re: GWT 2.8.0 RC1 is here!

Hi Kirill, this is a known limitation of the mojo plugin, you really should try this one https://github.com/tbroyer/gwt-maven-plugin/ which solves most of the limitation of the mojo plugin. In any case, mojo plugin will be released as 2.8.0-rc1 in the next days. On Friday, July 29, 2016 at

Re: [gwt-contrib] Re: Experimental release of Elemental2

+1 to add some type-safe, in my current mini-project (almost 50 lines of code) there are 5 cast! 2 elements, 2 events and 1 event target... the event target is mandatory, but the events and elements will be nice to be type-safe. On Sat, Jul 2, 2016 at 11:07 PM Manuel Carrasco Moñino

Re: [gwt-contrib] Re: Experimental release of Elemental2

JsType example is: elemental2.EventListener. On Friday, July 1, 2016 at 12:10:04 PM UTC+2, Ignacio Baca Moreno-Torres wrote: > > Thanks, now makes sense. I get confused with the JsFunction JsType(native) > because elemental2 has some callbacks as JsFunction and others as > JsType(

Re: [gwt-contrib] Re: Experimental release of Elemental2

of JsType (ex. elemental2.JsType)? On Friday, July 1, 2016 at 10:33:22 AM UTC+2, Goktug Gokdogan wrote: > > > > On Thu, Jun 30, 2016 at 11:42 PM, Ignacio Baca Moreno-Torres < > ign...@bacamt.com > wrote: > >> Yep, not sure why... but I just try again and the p

Re: [gwt-contrib] Re: Experimental release of Elemental2

urce.com/#/c/15193/ (which will be submitted > before the final release). > > On Thu, Jun 30, 2016 at 3:03 PM, Ignacio Baca Moreno-Torres < > ign...@bacamt.com > wrote: > >> I just applied elemental2 to this simple drang and FileReader >> showcase ( >> https:

Re: [gwt-contrib] Re: Experimental release of Elemental2

I just applied elemental2 to this simple drang and FileReader showcase (https://github.com/ibaca/dndfiles-gwt/blob/master/src/main/java/dndfiles/client/DndFiles.java). Elemental2 looks good, but I think that JsInterop still a bit... unpredictable. The project compiles correctly, but the

[gwt-contrib] Changes to maven dependencies makes GwtTest fail

I'm updating the old mojo plugin and one of the IT throws this stacktrace. I'm investigating, but I post it here now just in case that anyone are already aware. I see that some dependencies and source code has been excluded from gwt-dev, and looks like org/apache/commons has been excluded but

[gwt-contrib] Re: Setting up gwt project for development

I think this is the recomended setup: https://github.com/gwtproject/gwt/tree/master/eclipse On Friday, May 6, 2016 at 12:55:20 AM UTC+2, Konstantin Solomatov wrote: > > Hello, > > How do you usually setup the gwt project for development? The repository > provides only ant build file which is

Re: [gwt-contrib] GWT compiler optimization breaks some lambdas

(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/c

[gwt-contrib] Re: JsInterop is pruning non readed properties

Compiled using 2.8.0-SNAPSHOT and without -generateJsInteropExports. With -generateJsInteropExport works! (i.e.: Foo.bar field is not pruned) On Tuesday, April 12, 2016 at 3:57:10 PM UTC+2, Ignacio Baca Moreno-Torres wrote: > > This code: > public class Client implements E

[gwt-contrib] Re: JsInterop is pruning non readed properties

ention. I had quite a few issues with the Beta that went > away in the latest snapshot build. > > On Tuesday, April 12, 2016 at 11:11:17 AM UTC-4, Paul Stockley wrote: >> >> Are you compiling with -generateJsInteropExports ? >> >> On Tuesday, April 12, 2016 at 9:

[gwt-contrib] JsInterop is pruning non readed properties

This code: public class Client implements EntryPoint { Console log = Browser.getWindow().getConsole(); @Override public void onModuleLoad() { Foo foo = new Foo(); foo.bar = 666; log.log(foo); } @JsType public static class Foo { public int bar;

Re: [gwt-contrib] Re: JsInterop Object Literal

If your concert is to be able to write one-line initializers, and you are using java8 syntax you also do something like that: public static T apply(T t, Consumer fn) { fn.accept(t); return t; } @JsType(isNative = true, namespace = JsPackage.GLOBAL, name = "Object") class

Re: [gwt-contrib] GWT compiler optimization breaks some lambdas

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

Re: [gwt-contrib] GWT compiler optimization breaks some lambdas

types, which now seems to be the problem. Probably both test that Ray said fixed the problem, but only if the type used was the Overlay type (I didn't test that). Thanks. On Tuesday, October 27, 2015 at 9:17:48 AM UTC+1, Ignacio Baca Moreno-Torres wrote: > > Tests: > >- Creat

Re: [gwt-contrib] GWT compiler optimization breaks some lambdas

mbdas > and it looks ok. > > It would really help if you could narrow it down to a small reprocase that > I can run. > > On Sun, Oct 25, 2015 at 5:23 AM, Ignacio Baca Moreno-Torres < > ign...@bacamt.com > wrote: > > function ILe(a) { > var b; > b = Erb(

Re: [gwt-contrib] GWT compiler optimization breaks some lambdas

26, 2015 at 8:27:41 PM UTC+1, Ignacio Baca Moreno-Torres wrote: > > Bootstrap using lambda (fail) > > // java > return service.get().getBootstrap().bootstrap().doOnNext(data -> { > Account account = data.getAccount(); > if (account == null) auth.get().resetSessio

Re: [gwt-contrib] GWT compiler optimization breaks some lambdas

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 <google-web-toolkit-contributors@googlegroups.com >>> > w

Re: [gwt-contrib] GWT compiler optimization breaks some lambdas

resources.get()'), 62), c = Vu(new $u(b,b), new TLe), Erb(iEl(c, 'REF001'), 82) } On Sunday, October 25, 2015 at 12:18:01 PM UTC+1, Ignacio Baca Moreno-Torres wrote: > > Sorry, this is pretty confusing, just comment that the lamba cases > described previously still (in HEAD) g

Re: [gwt-contrib] GWT compiler optimization breaks some lambdas

kit-contributors@googlegroups.com> wrote: > Are you using a recent snapshot? > On Oct 24, 2015 04:40, "Ignacio Baca Moreno-Torres" <igna...@bacamt.com> > wrote: > >> There is a bug which optimizations nullify variables which might not be >> null. I'm trying to r

Re: [gwt-contrib] Re: GWT compiler optimization breaks some lambdas

Oct 24, 2015 at 4:54 AM, Ignacio Baca Moreno-Torres < > igna...@bacamt.com> wrote: > >> Other situation producing the same problem. If next code is replaced by >> lambda and method reference... the next block end up being optimized as if >> response is

[gwt-contrib] GWT compiler optimization breaks some lambdas

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

[gwt-contrib] Re: GWT compiler optimization breaks some lambdas

Uub(e.Od(), 6163); Jak(a, d) } c && lrm(a.d, a.c) } On Saturday, October 24, 2015 at 1:40:24 PM UTC+2, 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 outsi

Re: [gwt-contrib] Re: Voice of the GWT Committee???

IMHO current organization is pretty good, docs in the official page, news in google+, question and issues in Google groups and you can always chat with the community in ##gwt. All this 4 places are easy to contribute, so if you see less info and news is just because the community is not very news

[gwt-contrib] Re: Async process return operation on AbstractRequestContext

Although I also think that this may be a bad workflow problem, I also think that for some use cases this patch might be helpful. For me, this problem appears in two cases. Case 1. A reporting app which loads reporting data for a long period and allow client side analysis. The request load

Re: [gwt-contrib] Re: Async process return operation on AbstractRequestContext

But I prefer something very simple which solves the problem without touching too much. My patch looks simple which is important to be accepted. Also, I prefer that the user perspective do not change, so accumulate the EntityProxyChange until all operations are processed is required. Breaks up

[gwt-contrib] Async process return operation on AbstractRequestContext

RequestFactory has some performance problems. One of them occurs when the AbstractRequestContext need to parse the response and create all proxies. This problem is especially annoying if the time required to process this response forces the explorer to show the warning message ~*A script on

[gwt-contrib] Re: Async process return operation on AbstractRequestContext

generate some silent concurrency problems that I had not detected yet. If I add this patch with some improvements and tests as a pull-request, it might be accepted? On Monday, July 7, 2014 3:00:53 PM UTC+2, Ignacio Baca Moreno-Torres wrote: RequestFactory has some performance problems. One