Re: Any issues running in detailed (or pretty) style in production?
> Have you tried working your way into the symbolMaps? No, because I just figured the obfuscated code wasn't worth trying to deobfuscate, but apparently symbolMaps is the key. Kirill provded the details so I plan to refer to that. Thanks for the time! -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Any issues running in detailed (or pretty) style in production?
Great, thanks so much for this information, I'll study it and run some tests, but I'm sure it will create some great leads. Cheers! -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: GWT 2.8.1 release
This is a programmatic mapping from closure externs
https://github.com/google/closure-compiler/tree/master/contrib/externs so,
at the end if it changes it will change the same in every place, so fixing
it should not be very difficult. Anyways, this super awesome project 😜 is
going to expose a user-friendly and type safe API (manual work) over raw
elemental2 https://github.com/hal/elemento (code example here
https://github.com/ibaca/rxtodo-gwt/blob/master/src/main/java/todo/client/ApplicationElement.java#L53),
IMO pretty promising! RxGWT will be using elemento typed events to make it
also Rx typed events just over elemental2!
Code example here, this is always nice...
root = li().data(ITEM, item.id).css("completed", item.completed)
.add(div().css("view")
.add(toggle =
input(checkbox).css("toggle").checked(item.completed).asElement())
.add(msg = label().textContent(item.text).asElement())
.add(destroy = button().css("destroy").asElement()))
.add(summary = input(text).css("edit").asElement())
.asElement();
bind(toggle, change, ev -> {
root.classList.toggle("completed", toggle.checked);
repository.complete(item, toggle.checked);
application.update();
});
All these fields are typed so, root is a HTMLLiElement, toggle is a
HTMLInputElement or ev in the bind method is an InputEvent.
On Wed, Jun 7, 2017 at 10:14 PM Vassilis Virvilis wrote:
> thanks for the clarification.
>
> Maybe a sufficiently strong wording in the compatibility guarantees is
> enough.
>
> Something like this: We will try really hard to not rename all methods and
> move all packages around in the next week commits. However we may introduce
> incompatible changes as we are evolving the API. So no you can't use
> __this__ in __production__.
>
> Or maybe this a bad idea that will lead to a new KDE4 fiasco.
>
> Who knows?
>
> Vassilis
>
>
> On Wed, Jun 7, 2017 at 10:14 PM, Daniel Kurka
> wrote:
>
>> There is some reasoning behind us not broadly announcing elemental2 and
>> the jsinteorp generator:
>> They are both still beta software in the sense that we know there are
>> existing problems, but we already want feedback on them.
>> There are still no guarantees on APIs / compat but if you are brave and
>> want to be part of evolving them and turning them into a finished and
>> polished product, you can do that.
>>
>> We will announce them broadly once we consider them ready for general use
>> and have a compatibility guarantee in place.
>>
>> On Wed, Jun 7, 2017 at 11:48 AM Vassilis Virvilis
>> wrote:
>>
>>> Ah yes that explains it. It was j2cl that I remembered.
>>>
>>> Thanks for the clarification.
>>>
>>> Vassilis
>>>
>>> On Wed, Jun 7, 2017 at 9:40 PM, Colin Alworth
>>> wrote:
>>>
I think you may be misremembering - the jars were released to maven as
experimental last summer, then as beta in April, and only after that were
they on github.
J2CL is not expected to be dropped until it is "ready", but as with
elemental2, this isn't going to mean "bugfree" but more like "complete
enough to be reviewed and used".
On Wednesday, June 7, 2017 at 1:10:37 PM UTC-5, Vassilis Virvilis wrote:
>
> Looks like they are also here in source form
>
> https://github.com/google/elemental2
> https://github.com/google/jsinterop-generator
>
> I thought google didn't want to release them before they were "ready".
> So either they changed their mind, or they feel it is ready or I don't
> remember correctly :-)
>
> Vassilis
>
> On Wed, Jun 7, 2017 at 7:17 PM, Colin Alworth
> wrote:
>
>> The groupId has changed - using the mvnrepository site, try
>> https://mvnrepository.com/artifact/com.google.elemental2 to see all
>> of the jars now available.
>>
>>
>> On Wednesday, June 7, 2017 at 11:14:33 AM UTC-5, Bruno Salmon wrote:
>>>
>>>
>>>
Additionally, this supports the recent beta release of
jsinterop.base and elemental2, available from Maven Central.
>>> Where can we find that elemental2 beta release (I can see only the
>>> June 2016 version on that page
>>>
>>> )?
>>>
>>> Thanks for all your amazing work.
>>>
>> --
You received this message because you are subscribed to the Google
Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to
google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>>> --
>>> Vassilis Virvilis
>>>
>>> --
>>> You received this message because you are subs
Re: Problem compiling GWT code with Java9
can you please share your library and i can try with that. On Thursday, June 8, 2017 at 1:18:56 AM UTC+5:30, James Nelson wrote: > > Hi. > > Per this thread: > https://plus.google.com/+JamesNelsonX/posts/gBfpBDnwV9V > > I have actually dove into Java 9 support, and cleared all the roadblocks > once (before the JCP pushback force the module system to get more last > minute changes). > > The main issue was not language support (easy upgrade from eclipse jdt), > or a tiny change for try-with-resources (allows effectively final variable > references, instead of only local variable declarations)... > The biggest problem was the changes to the classloading system. > > Specifically, they no longer use URLClassLoader for system classloaders, > meaning that any attempts to "rip out the classpath" will not work any > longer. > > I managed to hack together a working compile where I check if java 9 > classloaders are in use, and if so, use reflection (with requires > --add-opens for using reflection on the classloader, plus opening the > source module so that the gwt code can see external resources), to get > access to those URLs. > > What I did is only one way to fix; we could also add classpath > declarations to gwt (I use an annotation system that can reference maven > modules for my own compiles, so I could actually get classpath without > looking inside classloader). There might also be less terrible hacks we > can use once the module APIs are cemented in place. > > > > If you really want to play with this RFN, I can push a build of my gwt > fork to maven central for you to try out. I don't really have a snapshot > repo, or time to respond to bugfixes atm (though I am considering opening a > gwt support shop this fall, and will "do it right" at that time). If you > are comfortable doing local installs to maven just to assess possibilities > (or if you maintain your own nexus repo), I could just send you jars > directly (though, that is generally a bit sketchy, imho). > > Let me know; I won't have time to do a release this weekend as it is my > wife's birthday, but I can fit it in if you'd like (and the comments in the > G+ post aren't helpful enough). > -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Any issues running in detailed (or pretty) style in production?
On Wednesday, June 7, 2017 at 9:39:55 PM UTC+2, rjcarr wrote: > > I've been using GWT for years and years but recently my customers have a > problem that I can't reproduce, and they're remote so I can't just go check > it out in person. > > They're getting an unresponsive script error, and the browser will tell > them where it is, but the code is obfuscated. > Have you tried working your way into the symbolMaps? (that's how the StacktraceDeobfuscator works fwiw) -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
