The latest contributor hangout recording posted at the GWT G+
pagehttps://plus.google.com/u/1/b/116516353752856283537/116516353752856283537/posts
is more
than two months old - November 27, 2013.
Weren't there any newer sessions in the meantime?
29 януари 2014, сряда, 02:37:52 UTC+2, Bhaskar
Would it be possible to publish the recordings of these meetings in a more
timely manner?
19 days after the (supposedly held?) Feb 26 session there is nothing yet on
the GWT G+ page.
Assuming that these meetings happen on a monthly basis, 19 days of lag
looks big :)
22 февруари 2014, събота,
Dear GWT team (and John in particular),
Lately I was checking from time to time the progress of the SDM incremental
compiler in GWT 2.7.0.
Let me first say - great work so far!
This morning our project was - for the first time - compilable with the new
incremental SDM code-path, without
For example, I noticed that a huge amount of time ( 50% of the whole
linking time) is spend in Saving source with extras, i.e. SourceSaver.
Given that these sources are only needed by the browser during a
sourcemap-based debugging session, can't they be served on the fly by the
18 август 2014, понеделник, 21:10:17 UTC+3, Roberto Lublinerman написа:
So out of pure curiosity - are there obvious optimizations in the linker
which are still pending?
We have been thinking about strategies to incrementalize the work done by
the linkers, one idea is to have a linker
(a) Javascript hot-swapping
One disadvantage of the current SDM recompilation is that it triggers
page reload in the browser.
If the application being debugged is a stateful, single-paged one, this
means that even for a very small change, the developer essentially
starts-over the
I can confirm similar results to the previous post:
- 3 to 6 seconds for recompiling changes to a single file
- 5 to 6 seconds for linking
- Changes to more types naturally cause the compile time to grow (e.g. 13
seconds for around 10 changed files) however the linking stays at 5 to 6
seconds
BTW using a more recent laptop seems to make a difference and nearly
doubles the performance:
MacBook Pro model 2013 (I7 2.7 GHz):
- 2 to 3 seconds for recompiling changes to a single file
- 2 to 3 seconds for linking
- Changes to more types of course again results in a growth of the
(Background: I'm trying to further shorten the edit-compile-debug cycle by
playing with hot-code swapping of recompiled JavaScript in Chrome (via
Eclipse / SDBG))
GWT 2.7.0-SNAPSHOT, SDM mode, xsiframe linker (obviously), playing with
LiveEdit from within Chromedevtools initially:
- Editing
Daniel,
I'm not planning to edit the generated JavaScript by hand. My idea is to
remove the need to do webapp *reloading*. The problem with reloading the
webapp is NOT that it takes a lot of time (it probably doesn't), but that
if the webapp is a stateful one, reloading it on each SDM
август 2014, неделя, 20:33:13 UTC+3, Ray Cromwell написа:
Try using the xs linker instead.
On Sun, Aug 31, 2014 at 10:15 AM, Ivan Markov ivan@gmail.com
javascript: wrote:
(Background: I'm trying to further shorten the edit-compile-debug cycle
by playing with hot-code swapping
https://gwt.googlesource.com/gwt.git/+/2.5.1/dev/codeserver/java/com/google/gwt/dev/codeserver/Recompiler.java
On Mon, Sep 1, 2014 at 2:43 AM, Ivan Markov ivan@gmail.com
javascript: wrote:
Ray,
Using the xs linker seems like a bad idea, as it combines the
disadvantages of sso
I have some good news and some bad news...
The good news:
None of my original suspicions as to why Chrome LiveEdit does not work are
true.
Live editing works just fine when the script is injected in the page
programmatically by another script using DOM manipulations (ala xsiframe
linker). And
Another option would be to abandon Chrome LiveEdit completely in favor of a
do-it-yourself approach.
JavaScript does allow functions and variables redefinition, so maybe we can
just inject another script inside the iframe with the newly recompiled
permutation?
(To have this instantaneous, only
One option is to get source-map support improved
directly in Eclipse/IntelliJ, so that the Javascript-based developer
tools are not used, rather, the IDEs connect to the Browsers via
remote debugging protocols, but the SourceMap/indexing/navigation is
done by Eclipse/IntelliJ.
A
I'm also interested in this. Check http://sdbg.github.io/ for a
GWT-friendly JavaScript+Sourcemaps debugger for Eclipse.
As for avoiding page refreshes, it is a great idea but as Ray said once, it
would require significant work in GWT itself as well. For more details, you
may want to check my
I agree that the debugging experience of GWT can be improved.
That might happen either by trying to resurrect DevMode by hacking on
Chromium and the JVM, or by implementing Java watch expressions and
conditional breakpoints in Chrome Devtools / Eclipse SDBG.
I think the second approach might be
>
>
> Thank you, GWT people, for spending your time answering my thoughts.
>
>
> To summarize (and TLDR), these were responses in the thread:
>
>
> Ivan Markov: We should improve javascript-side debugging to match DevMode.
>
> Jens: Google is busy doing other
A cross-post from
here:
https://discuss.kotlinlang.org/t/interop-with-googles-j2cl-what-would-it-take/2991
Whoever is interested - please post. ... and correct/clarify if you notice
I've mentioned anything which is imprecise.
--
You received this message because you are subscribed to the
Don't you think there could've been 2x or even 3x as much people working on
porting GWT2 stuff over to J2CL if J2CL was released in the first place?
For one, releasing J2CL could've made me reconsider how much time I invest
in my own SDBG pet project. Which - at the current situation is exactly
I am quite sure this does not belong in this group, so let's
> continue the discussion in the main GWT group
>
> On Tue, Mar 6, 2018 at 4:48 AM, Ivan Markov <ivan@gmail.com
> > wrote:
>
>> This time I'll bite...
>>
>> J2CL has been - what? - two to
to me. I am also not interested in
>>> anything that would compile differently in dev mode than in production mode
>>> in the interest of fast compiles, we have been down that road before with
>>> the legacy development mode, and when something worked in dev mode but not
>>> i
Goktug, sorry for being a but stubborn here, but we need a tad more
visibility:
{quote}
The main blocker for releasing J2CL for wider audience is even basic
missing functionalities around building it in open-source and seeing at
least some output for your compilations.
{quote}
"even basic
This time I'll bite...
J2CL has been - what? - two to three years in the making - yet, there is
nothing released to the public yet (aside from a preview to a few blessed
individuals).
Before someone follows up again with the usual matra that "it is not
production ready yet and it will do more
24 matches
Mail list logo
