from:"Ivan Markov"

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

2018-05-31 Thread Ivan Markov

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 
zero. Or whether to invest time in the abandoned typescript2java effort, 
which would bring seamless JSInterop with gazillions of .d.ts'd JS 
libraries without the need to manually code JSInterop bindings...

Say what you want, but 3 months since my original rant that at the top of 
this thread, the "basic Bazel building issues" of Goktug seem still to be a 
roadblock and J2CL is still nowhere to be seen.

... and then we had Daniel planning to write a book on J2CL end of 2016, 
remember? Come on guys, it is Q3 2018 now... I might now agree with Learner 
Evermore on his points 2) to 5), but with point 1) he nailed it:
"1. The backing company backed off but kept the crucial new piece secret - 
J2CL."

On Wednesday, May 30, 2018 at 6:07:25 PM UTC+3, Frank Hossfeld wrote:
>
> That's not really true. There are a lot of people working on the GWT 
> module, getting them out of GWT and moving them to standalone artifacts. 
> Doing that, they replace JSNI with JsInterop, replace generators, etc. This 
> is all done, to get GWT 2 ready for GWT 3. And if you want to see something 
> existing in GWT 3, you can ask vertispan to do the job. 
>
> With the knowledge about the things, that will change with GWT 3 / J2CL, I 
> was able to make mvp4g ready for GWT 3 / J2CL. I replaced the generator 
> with APT and remove the dependency to any GWT classes. I created a sample 
> application based on the new version (mvp4g2) and Elemental 2. And yes, it 
> works with J2CL. 
>
> And, keep in mind, applications written in GWT in 2010 still work. What 
> was the favorite JS framework at that time? I don't remember.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/03d79d23-11e5-423b-9009-d439a569c512%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] The elusive J2CL

2018-03-09 Thread Ivan Markov

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 missing functionalities" sounds quite worrysome. What is the 
ETA for implementing these and releasing a preview? If e.g. two months, 
fine. If we are talking Q4/2018 or 2019, then that's a different 
proposition altogether. I guess, not just for us. Please don't answer with 
the "it's done when it is done" slogan. :) That's one of the major pains 
for this community imo.

Final Q: are all the legal issues for releasing in the open resolved by 
now? From personal experience, these might take forever to resolve.

On Thursday, March 8, 2018 at 10:51:21 PM UTC+2, Goktug Gokdogan wrote:
>
> > There is still tone of work to do for a polished open source experience 
> but at least we can give access to more people who is really interested.
>
> What I meant here; is giving access *after* basic bazel stuff is finished 
> so there will be something to play with. We don't want to give access to 
> a broader group for something that is dead on arrival.
>
>
> On Thu, Mar 8, 2018 at 5:31 AM Alberto Mancini  > wrote:
>
>> Hello, 
>> yes, definitely I would like to be in. 
>> I am really interested.
>>
>> Cheers,
>>Alberto. 
>>
>>
>> On Thu, Mar 8, 2018 at 2:21 PM Nándor Előd Fekete > > wrote:
>>
>>> I am *really* interested. Can you sign me up?
>>>
>>>
>>> On Thursday, March 8, 2018 at 9:13:01 AM UTC+1, Goktug Gokdogan wrote:

 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. That is blocked on missing 
 functionalities in bazel. After that we can probably finished in more 
 timely manner.
 There is still tone of work to do for a polished open source experience 
 but at least we can give access to more people who is really interested.

>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "GWT Contributors" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com 
>>> .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/8de62b64-4bc8-4158-80d4-b15ef688f523%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGv30V%3DfWDpwQ45u9mPVuXY%3D62PJZ%2B9uxearZk5Lq_a0j2yjaA%40mail.gmail.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/067f44a4-2f87-49f1-9495-3e7a13f1f0ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] The elusive J2CL

2018-03-08 Thread Ivan Markov

Goktug,

We don't want a polished experience. We want *some* experience. :)

Is there anything we can help with? BTW, I thought Bazel is already open 
sourced and you are already building with it? What's the roadblock there?

BTW 2: Releasing a J2CL binary would also help, as long as that's somehow 
legally possible.


On Thursday, March 8, 2018 at 10:13:01 AM UTC+2, Goktug Gokdogan wrote:
>
> 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. That is blocked on missing 
> functionalities in bazel. After that we can probably finished in more 
> timely manner.
> There is still tone of work to do for a polished open source experience 
> but at least we can give access to more people who is really interested.
>
>
>
> On Wed, Mar 7, 2018 at 11:43 PM Ivan Markov <ivan@gmail.com 
> > wrote:
>
>> I posted my message (OK. My rant!) here, because I wanted to get the 
>> attention of Goktug, Daniel & the rest of  the Google crew. It is a plea to 
>> change something ASAP, and if someone could, it is them.
>>
>> As for the rest of your comments... don't know where to start. Most 
>> important is, you seem to imply that using J2CL will resurrect something 
>> similar to the old legacy development mode. That couldn't be farther from 
>> the truth - I suggest you check the available (scarce) info on J2CL. Also: 
>> with the new compiler toolchain we (should) have even faster compiles. "We 
>> should" because it is not available anywhere, so we can't play with it. We 
>> are currently in the 5 to 10 seconds of recompile time with GWT, and I want 
>> this down to 2 seconds. I want Webpack all the way down, also for my Java 
>> code. With HMR. With HMR + react-hot-loader. Maybe that's possible with the 
>> GWT toolchain, but I'm not holding my breath...
>>
>> On Thursday, March 8, 2018 at 6:17:28 AM UTC+2, Tony BenBrahim wrote:
>>>
>>> I am perfectly happy with Java/JsInterop in its current state. Sure 
>>> there are some things that could be improved, but what couldn't. BTW, I 
>>> have never used the GWT widgets, so my case may be different. I tried TS, 
>>> Angular, etc..., and have come back to GWT with JsInterop to deal with 
>>> large projects. Porting a largish Angular/Typescript project back to GWT 
>>> with JsInterop, I found several bugs, because Typescript gives the illusion 
>>> of types and "type checking", while GWT does real type checking.
>>> Put me in the camp that does not care if J2CL ever comes out. I want 
>>> fast compiles, especially in dev mode, anything that threatens that with a 
>>> 2 step compile is of no interest 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 
>>> in prod mode, it was not fun to fix.
>>> Anyways, 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 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 harm than good" or "somebody is 
>>>> porting the GWT widgets to J2CL as without these J2CL would be unusable" 
>>>> let's ask ourselves: *are these statements holding any ground anymore*?
>>>>
>>>> Here's a situation which is very likely not typical to just us: 
>>>> We have to - like NOW - start replacing - in our app - all the dying 
>>>> GWT widget-set/RPC legacy with a maintained and more contemporary toolkit 
>>>> (React, Angular2, whatever).
>>>>
>>>> (And please let's not argue over whether the GWT widget-set is still an 
>>>> option for any new development. For us it is not. Also let's not argue if 
>>>> coding against JavaScript libs with the existing GWT compiler toolchain is 
>>>> a viable option in the long term - it is obviously not.)
>>>>
>>>> The q

Re: [gwt-contrib] The elusive J2CL

2018-03-07 Thread Ivan Markov

I posted my message (OK. My rant!) here, because I wanted to get the 
attention of Goktug, Daniel & the rest of  the Google crew. It is a plea to 
change something ASAP, and if someone could, it is them.

As for the rest of your comments... don't know where to start. Most 
important is, you seem to imply that using J2CL will resurrect something 
similar to the old legacy development mode. That couldn't be farther from 
the truth - I suggest you check the available (scarce) info on J2CL. Also: 
with the new compiler toolchain we (should) have even faster compiles. "We 
should" because it is not available anywhere, so we can't play with it. We 
are currently in the 5 to 10 seconds of recompile time with GWT, and I want 
this down to 2 seconds. I want Webpack all the way down, also for my Java 
code. With HMR. With HMR + react-hot-loader. Maybe that's possible with the 
GWT toolchain, but I'm not holding my breath...

On Thursday, March 8, 2018 at 6:17:28 AM UTC+2, Tony BenBrahim wrote:
>
> I am perfectly happy with Java/JsInterop in its current state. Sure there 
> are some things that could be improved, but what couldn't. BTW, I have 
> never used the GWT widgets, so my case may be different. I tried TS, 
> Angular, etc..., and have come back to GWT with JsInterop to deal with 
> large projects. Porting a largish Angular/Typescript project back to GWT 
> with JsInterop, I found several bugs, because Typescript gives the illusion 
> of types and "type checking", while GWT does real type checking.
> Put me in the camp that does not care if J2CL ever comes out. I want fast 
> compiles, especially in dev mode, anything that threatens that with a 2 
> step compile is of no interest 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 in 
> prod mode, it was not fun to fix.
> Anyways, 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 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 harm than good" or "somebody is 
>> porting the GWT widgets to J2CL as without these J2CL would be unusable" 
>> let's ask ourselves: *are these statements holding any ground anymore*?
>>
>> Here's a situation which is very likely not typical to just us: 
>> We have to - like NOW - start replacing - in our app - all the dying GWT 
>> widget-set/RPC legacy with a maintained and more contemporary toolkit 
>> (React, Angular2, whatever).
>>
>> (And please let's not argue over whether the GWT widget-set is still an 
>> option for any new development. For us it is not. Also let's not argue if 
>> coding against JavaScript libs with the existing GWT compiler toolchain is 
>> a viable option in the long term - it is obviously not.)
>>
>> The question: shall we scrap GWT altogether and rewrite in JS/TS? Or 
>> shall we continue with Java/JSInterop?
>>
>> Now, please enlighten me how we can defend the option of continuing in 
>> Java/JSInterop - even in front of ourselves - given that 3 years from the 
>> initial announcement - J2CL is still just smoke and mirrors for almost all 
>> Google outsiders?  We can't play with it to gain some confidence that it 
>> will work for us.. Also what happens if Google changes their mind and 
>> decides not to release it - say - due to legal issues? We would be stuck 
>> with an all-new Java/JSInterop code still bound to the dying compiler 
>> toolchain of GWT. Not a situation anybody wants to end up with, I guess...
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/d9a326c6-ae1b-4577-8dd4-71d765ff547f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] The elusive J2CL

2018-03-06 Thread Ivan Markov

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 harm than good" or "somebody is
porting the GWT widgets to J2CL as without these J2CL would be unusable"
let's ask ourselves: *are these statements holding any ground anymore*?

Here's a situation which is very likely not typical to just us:
We have to - like NOW - start replacing - in our app - all the dying GWT
widget-set/RPC legacy with a maintained and more contemporary toolkit
(React, Angular2, whatever).

(And please let's not argue over whether the GWT widget-set is still an
option for any new development. For us it is not. Also let's not argue if
coding against JavaScript libs with the existing GWT compiler toolchain is
a viable option in the long term - it is obviously not.)

The question: shall we scrap GWT altogether and rewrite in JS/TS? Or shall
we continue with Java/JSInterop?

Now, please enlighten me how we can defend the option of continuing in
Java/JSInterop - even in front of ourselves - given that 3 years from the
initial announcement - J2CL is still just smoke and mirrors for almost all
Google outsiders? We can't play with it to gain some confidence that it
will work for us.. Also what happens if Google changes their mind and
decides not to release it - say - due to legal issues? We would be stuck
with an all-new Java/JSInterop code still bound to the dying compiler
toolchain of GWT. Not a situation anybody wants to end up with, I guess...

--
You received this message because you are subscribed to the Google Groups "GWT
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/b99a4589-68f8-47f0-a414-80468bb90d5a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Kotlin/JS - Interop with Google’s J2CL - what would it take?

2017-05-30 Thread Ivan Markov

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 Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/6e5bae19-7f05-41f4-bed2-017cfbe91fae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GWTReact Release and Roadmap

2017-05-01 Thread Ivan Markov

Side question: I can imagine that the lack of object spread probably makes 
Redux a bit annoying to use from Java. Yet, if you are not using neither 
Redux nor MobX, how are you managing your state?


On Monday, May 1, 2017 at 3:48:51 PM UTC+3, Paul Stockley wrote:
>
> I agree both Redux and MobX are both pretty stable. The decision was more 
> a reflection on the current state of the GTWReact projects. I would say 
> both are really proof of concepts at this stage. Redux in particular would 
> really need interfaces building to the common middleware to be really 
> useful.
>
> On Sunday, April 30, 2017 at 11:05:08 AM UTC-4, Mark Erikson wrote:
>>
>> For what it's worth, as a Redux maintainer I can assure you that Redux is 
>> very stable and not going to meaningfully change (at least at the API 
>> level) from here on out :)
>>
>> On Sunday, April 30, 2017 at 8:27:10 AM UTC-4, Paul Stockley wrote:
>>>
>>> I have just released a new version of the GWTReact 
>>>  projects to support GWT 2.8.1
>>>
>>> As of this release, I will no longer be maintaining the MobX and Redux 
>>> projects. Our company is not using them currently and I don't have the time 
>>> to keep them updated. In the future, we may update MobX if we start using 
>>> it in production. If you would like take over maintenance of either of 
>>> these projects please let me know.
>>>
>>> *Road Map*
>>>
>>> With the current release, I feel pretty good about the quality of the 
>>> projects. We are starting to use both gwt-interop-utils and gwt-react in 
>>> our production code with excellent results. However, I think to get to a 
>>> 1.0 release I need to make the following changes:
>>>
>>>
>>>1. Migrate gwt-interop-utils to use the new GWT base project
>>>2. Migrate gwt-react to use elemental 2
>>>
>>> I will start working on these objectives in a month or two. The main 
>>> determining factor on how quick this happens will be how fast elemental 2 
>>> matures.
>>>
>>>

-- 
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.

[gwt-contrib] Re: Thoughts on DevMode

2017-01-15 Thread Ivan Markov


>
>
> 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 things, so no hope with gwtromium.
>
> Jens: Change your attitude towards SuperDevMode. Also, DevMode was not so 
> cool.
>
> Arnaud: Don’t believe what I said in article! // thanks Arnaud, I’m better 
> now ;)
>
> Arnaud: TCP via localhost is fast enough
>
> Thomas Broyer: Even moving towards Typescript in GWT architecture, there’s 
> still big value of Java as language due to code reuse.
>
> Thomas Broyer: js-java glue that was related to codeserver for DevMode is 
> already in rotten state.
>
> Stephen Haberman: Abstract away browser and debug in JVM without browser.
>
>
> I will respond here in one message to each of these points:
>
>
> Ivan Markov and Jens, there’s a lot more to JVM debugging that stepping 
> and seeing the source. This is "drop frame", hot code reload, evaluate Java 
> expression (before deciding whether I should step into or over function 
> “verifyCondition(x1.var1, x2.var2)” I evaluate it in expression evaluator 
> first to check whether it’s valid – not working with java code in front of 
> me in IDE, when JS being evaluated). Also: breakpoint skip count and 
> specified exception breakpoint; field access breakpoint; something else 
> obvious so much that I even can’t specially recall. I code in java since 
> long ago, and these features are just common tools for me, hardwired into 
> the muscles, and this makes SuperDevMode looking like a toy. Last time I 
> checked, source maps do not map even variables names (not mentioning 
> scopes), and, knowing the pace of its development, I don’t give much hope 
> to that. Integration of JS debugging into IDEs can't help much with all 
> this. Saying all above, I see your (and similar people) favorable attitude 
> towards SuperDevMode coming from both low expectations [1] of what good 
> debugging is and maybe (sorry!) from excessive self-convincing that 
> SuperDevMode is super, due to apparent lack of alternative (which I try to 
> change by idea of gwtromium).
>
>
> [1] I’m aware of two opposing attitudes toward debugging, best illustrated 
> by systems-level embedded programmers which usually can afford only 
> printf() and must put most effort in writing code that works correct in 
> first place (this influences their thought process and attitude even after 
> they move to upper levels), as opposed to high-level programmers which can 
> literally edit-and-continue most of their time.
>
>
>
I openly admitted that the current GWT debugging experience sucks so I'll 
pass on your Java-debugging-is-so-much-better eye opener.
As for GWT "no longer stretching the limits"... while I sympathize your 
emotions, the battle is lost. A single toolkit can't possibly keep up with 
all the innovation on the JavaScript front, so they either need to have a 
very good jsinterop + lightning fast transpiler (ASAP!!), or Java in the 
browser will die.

Now to the concrete topic of GWT debugging:
Unfortunately, Google seems to have other priorities right now so we are on 
our own for anything besides the core compiler (cough, transpiler). 
So as Jens said - screaming out loud won't help. If you really want to make 
a difference - invest your time, swim against the current and prototype the 
gwtromium thing (or help improve the sourcemap debugger - a lost of what 
you mention about native Java debugging is possible to implement with 
enhancements to the sourcemap debugger). 
This community needs more people *doing* stuff.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/0a0b473b-8fb5-4996-8e2f-2baa0338567a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Thoughts on DevMode

2017-01-12 Thread Ivan Markov

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 easier, but it will require hacking on 
GWT itself, because evaluation of Java expressions in the debugger would 
need support from the compiler. That might be easier to do with J2CL once 
it is out. Let's see - rumor goes, initial beta or something is expected 
this quarter...


On Friday, January 13, 2017 at 1:45:05 AM UTC+2, Predrag Remark wrote:
>
> I agree 100% with everything you said. I was thinking exactly about this 
> idea (when I first saw dartium). I was wondering why it's not done in gwt 
> the similar thing long time ago (DevMode with special version of Chromium) 
> ? SDM in Chrome or Eclipse (with sdbg) is nothing comparing to DevMode. It 
> does not really replace DevMode it's just a bad hack that I personally 
> don't find useful at all. It's faster than DevMode, but that is it. It's 
> not really a debugger if you are not able to watch Java expressions and 
> variables, it looks more like some kind of hacking than debugging. I still 
> prefer to use DevMode with Mozilla 26 and IE11 than the latest Chrome and 
> it's source maps (so called) "debugger".
>
>
> On Thu, Jan 12, 2017 at 10:43 PM, sanny...@gmail.com  <
> sanny...@gmail.com > wrote:
>
>> Hello, GWT people.
>>
>> 
>>
>> GWT got its popularity because it allowed DevMode in the browser (run 
>> java in VM in browser, manipulate DOM, use your IDE!). In fact, the GWT 
>> project appeared as clever hack on hack on hack to stretch limits of 
>> possible, to be ahead of its time, and that was cool. Nobody did that 
>> before. Now GWT turns into much like... i don't know, more like typescript 
>> compiler. No, really, with announcements like those "Let’s examine 
>>  the 
>> parts of GWT doomed to extinction: generators, Widgets, GWT-RPC, UiBinder …
>> " it's just another typescript. Typescript also looks like Java! Its 
>> transpiler is and will always be faster than GWT. There's no reason for GWT 
>> to be anymore. And there's no GWT events, reddit comments on its 
>> announcement are like 
>> 
>>  
>> "oh, it's still alive?". 
>>
>> So while GWT is essentially already dead for me with removal of DevMode 
>> (I understand this removal happens because of browsers architectural 
>> changes, not because the idea failed), I still think about various 
>> workarounds.
>>
>> 
>>
>> I remember, in GWT 1.0 special mozilla-based internal browser was shipped 
>> with GWT. It was long before GWT DevMode plugins for all browsers. And 
>> nobody thought it's bad option, although it didn't support SVG which was 
>> already in firefox, canvas, etc. It was the way to go. IT WAS the cool part.
>>
>> With removal of NPAPI and devmode plugins, maybe it would be feasible to 
>> take chromium, maintain one (1) patchset that allows it to run alongside 
>> with JVM (maybe even same process!) on all platforms, allowing DevMode via 
>> direct calls, and distribute it on manner they do it with dartium? 
>> gwtromium?
>>
>> You ask "what about other browsers"? You don't need other browsers. 
>> Citing same source: "modern browsers are now more standard and compatible 
>> , and 
>> we no longer need to have the homogenization layer that GWT gives", and 
>> this is in fact true. For other browsers, use SuperDevMode, it's useful 
>> enough to catch browser-related issues. But main program logic should be 
>> allowed to be developed (and debugged!) in Java. Because GWT is... Java.
>>
>> By introducing more strong ties and even sharing process with JVM it 
>> would be possible to speed up roundtrips java<->browser due to absence of 
>> TCP connection and serialization, so it will be even noticeably faster than 
>> before.
>>
>> So, does this idea make sense? Or javascript-transmitted disease 
>> finally won?
>>
>> Thanks.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/a5b2d7d3-6092-4d73-a801-928b4d01585e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vue GWT: Vue.JS integration for GWT 2.8

2017-01-09 Thread Ivan Markov


>
>
> => Java to JS component translation
>
> Indeed the Java introspection at runtime is also not my favorite thing. 
> Adding a $ before each property name could be a valid solution and I'm 
> surely considering it :).
> This will also negate the need to filter out properties manually (like the 
> ___ that is too generic), because only the "interesting" properties would 
> be copied over.
>

I'm no longer sure that would work. Even if I prefix my "to-go-in-data {}" 
fields in the Java class with $ so as to signal VueGwt to only put these 
properties in data {}, Vue monitors the properties defined in data {} 
*recursively. *So if I have a field which is OK to go in data {} but the 
object kept inside this field *itself *has fields which should not be 
monitored by Vue, there is no way to tell Vue not to do so... Just look at 
Vue's state.js & observer.js code...
 

>
> For the @JsProperty, sadly they still would need it (or at least a @JsType 
> + public properties), as the Vue.JS template are not parsed by GWT. The 
> name in the template must match the ones in the JS translation of the Java 
> component. If GWT rename them at compile time, then you'll get for example:
> {{ bob }} in your template and data: {a: "hello"} in your component.
>

That's correct.

 

>
> => Circular reference in data model.
>
> I tried to create in pure Vue.JS a component that returns a circular 
> reference upon creation, and it also breaks:
> https://codepen.io/anon/pen/oBXBmB
> (if you remove the test.circular = test, it works again).
>
> Also Vue doc in v1 specifically said that it needs not not contain 
> circular reference. In the v2 they say that you can clone the data using 
> JSON.stringify(JSON.parse(...));
> https://github.com/vuejs/Discussion/issues/265
> https://vuejs.org/v2/api/#data
>
> Fixing the way we build the Component data to make sure to only integrate 
> the properties needed by the user would probably make this less of an issue.
>

I think the "return JSON.parse(JSON.stringify(data));" trick that you do in 
VueGwtTools.js has to go. 
For one, this call completely disconnects the original set of fields in 
data {}, from the ones that Vue will monitor. So I'm not sure that the 
current VueGwt implementation monitors the correct fields at all?

Also, a copy of the data {} is anyway required in Vue.js only when you 
register a new Vue *component* (as opposed to just instantiating a new Vue 
instance): https://vuejs.org/v2/guide/components.html#data-Must-Be-a-Function
Perhaps the misunderstanding and the mismatch comes from how you register a 
new component. In  your example, you do it like this:

@JsTypepublic class RootComponent extends VueComponent
{
public RootComponent()
{
// ChildComponent is registered to be used in our RootComponent
this.registerComponent(new ChildComponent());
}
}


In Java and also with your approach where data {}, props {} methods {} and 
all are flattened in a single Java object, it would feel much more natural 
if you do it like this:

@JsTypepublic class RootComponent extends VueComponent
{
public RootComponent()
{
// ChildComponent is registered to be used in our RootComponent
this.registerComponent(ChildComponent.class);
}
}


... and then VueGwt should map a JS *function *to the Vue "data" property 
which function should instantiate a fresh instance of the ChildComponent 
class, ending up with a separate data {} copy for each new component 
instance, as is required.
(It is another topic how to do this reflective instantiation of the 
component with GWT anyway. Perhaps you need a Factory pattern here, in the 
absence of reflection in GWT?)

 

>
> => Minor issues
>
> 1: Yes, for now we just wanted to get feedback, so it wasn't needed, but 
> if people show interest it will happen.
>
> 2: Indeed, nice catch! I'll make sure to add it to the documentation.
>
>
> => Other questions
>
> As you saw even if the Java introspection is nice and pretty easy to do 
> (with naming convention), it doesn't not feel very "Java" or clean to code 
> with it. I was thinking about using annotations with annotations processor 
> to avoid having naming conventions.
>
> For example a simple component could look like:
> @Component
> public class myComponent extends VueComponent {
>   @VueData
>   protected String myMessage = "Hello";
>
>   @VueMethod
>   protected void resetMessage() {
> this.myMessage = "";
>   }
>
>   @VueWatch
>   protected void myMessage() {
> // Do something
>   }
> }
>
> This would be much cleaner to code. Also it might be possible to 
> automatically bind templates, we would also gain the ability to fine tune 
> the component behavior by passing parameters to the @Component annotation.
>
> My main issue with this is after doing some research, it seems that 
> annotation processors integrates poorly for now with GWT super dev mode. 
> You have to manually rereun the annotation processor after each change. I 
>

Re: Vue GWT: Vue.JS integration for GWT 2.8

2017-01-06 Thread Ivan Markov

Hi there.
 

> It's still a work in progress, but* we would be glad to hear what you 
> think of it.*
>
>
What I think is the following: this is very neat! 

With the above said, I have one roadblocker and two minor issues 
(disclaimer: I'm a *complete* NB in Vue.js).

The roadblocker:
==

You are converting the Java/GWT representation of a Vue component into the 
one Vue expects by using a runtime introspection of the VueComponent object 
from within JavaScript.
Because of this approach, you are putting properties in data {} which are 
NOT declared as a @JsProperty in Java. You know, internal private members 
that I might have in my Vue component ending on _g$, like an EventBus 
instance or you-name-it.
The problem with this is that the conversion fails in JSON.parse() with a 
"Converting circular structure to JSON" complaint.

Given that it is not very realistic - especially in hybrid Vue/GWT Widget 
projects to have all props marked as @JsProperty, and all of these to be 
non-circular, this probably needs to be addressed.

An idea: since you are anyway using naming conventions (a computed_ prefix 
for computed props, a watch_ prefix for watchers), how about applying this 
to ALL props that should end in data {} and perhaps to all methods that 
should end in methods {}?
Perhaps you can fix it so that it processes only methods and properties 
that are starting with e.g. a single "$" or suchlike?
NOTE: That might have the additional benefit that these methods and 
properties might not necessarily have to be marked with 
@JsMethod/JsProperty, as you - in fact - don't care about their name being 
preserved from Java to JS, as long as it starts with a "$".

Another idea: you are anyway filtering out some GWT methods, like those 
starting with "$init" or with "___" (the latter might be dangerous btw as 
it is a bit too generic!), so you can just as well filter out everything 
that ends with _g$ as well, because that's the mangling suffix GWT puts on 
all props and methods which had not been exposed via @JsProperty / 
@JsMethod / @JsType annotations. Of course this relies on GWT internals and 
might break in future, but I don't think there will be a perfect, pure and 
clean solution anyway if a JS object introspection is used.

Now, even if the above is addressed (and I think it should as the 
programmer has to have control what ends up in data {} and methods {}), the 
whole "return JSON.parse(JSON.stringify(data));" approach is not giving me 
a warm fuzzy feeling. Is that how Vue is supposed to work? With 
non-circular data {} only?

Two minor issues:
=

1. Having the project published in Maven Central soon would be nice - even 
if it is just a snapshot.

2. I was missing a "https://unpkg.com/vue/dist/vue.js";>" include and it took me 
some time to realize it. If VueGwt indeed does not inject the vue.js lib, 
this has to be at least mentioned in the GitHub README.md file.


*Keep up the good 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.

Re: SDM and client debugging with eclipse debugger?

2015-04-23 Thread Ivan Markov

Hi,

SDBG *no longer *provides a ZIP version of the plugin (as noted on the
Releases page).
I hope you managed to install from the P2 site. If you used some of the old
ZIP releases, you shouldn't as they are really old in the meantime.

Perhaps you can use the approach outlined here:
https://groups.google.com/forum/#!topic/sdbg/qvkr4WJvpm0

четвъртък, 23 април 2015 г., 15:33:49 UTC+3, kwma...@gmail.com написа:

Good news! I got it working now with the sdbg plugin - after restarting
everything (eclipse, jboss, debug configs, sdm on) , the debugger pauses in
the client code at the break points set :-)
Regards
Kristian

On Thursday, April 23, 2015 at 12:13:04 PM UTC+2, kwma...@gmail.com wrote:

Hi Ivan,

in the meantime I was able to install the sdbg plugin and tried to use it
according to video from the github readme page of the project.

Difference was that I did start Codeserver via Debug - [GWT] Web
Application (Super Dev Mode) and did not get a classnotfoundexception for
the CodeServer. Also - since I have to use the target app server as runtime
environment (e.g. JNDI-Lookup), I did provide the URL of the local JBOSS
when creating a Launch Chrome Debug Configuration instead of the URL from
the Development Mode View in Eclipse.

Unfortunately I do get the same behaviour that the debugger does not halt
at the break points in the client code. Should it work as expected also
with local jboss as runtime instead of GWT-Plugin-internal JETTY Runtime?

Thanks
Kristian

On Thursday, April 23, 2015 at 9:10:01 AM UTC+2, kwma...@gmail.com wrote:

OK, thanks for the info! This clarifies the behaviour I described in my
initial post.

On Wednesday, April 22, 2015 at 3:23:32 PM UTC+2, Jens wrote:

With SDM your client side code only runs in the browser and you have to
set break points in the browser's dev tools. Launching the JVM in debug
mode does not give you anything for client side debugging.

There is an Eclipse plugin called SDGB on Github that allows Eclipse to
connect to Chrome browser and then you can set break points in Eclipse
(and
Eclipse synchronizes them with Chrome browser).

-- J.

--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit 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 http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: SDM and client debugging with eclipse debugger?

2015-04-22 Thread Ivan Markov

Here's the web-page of the plugin: http://sdbg.github.io/
Drop me a note if you can't get it running.


сряда, 22 април 2015 г., 16:23:32 UTC+3, Jens написа:

 With SDM your client side code only runs in the browser and you have to 
 set break points in the browser's dev tools. Launching the JVM in debug 
 mode does not give you anything for client side debugging.

 There is an Eclipse plugin called SDGB on Github that allows Eclipse to 
 connect to Chrome browser and then you can set break points in Eclipse (and 
 Eclipse synchronizes them with Chrome browser).


 -- J.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit 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 http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Invesigating OOPHM chrome dev tools js extension creation

2014-11-25 Thread Ivan Markov

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 Chrome LiveEdit and SDM thread in this group:
https://groups.google.com/forum/#!searchin/google-web-toolkit-contributors/chrome$20liveedit$20and$20sdm/google-web-toolkit-contributors/W-oKhuuT0S8/yLM_UL-bTRUJ

There is also the problem that if you decide to base hot patching on top of
Chrome LiveEdit (which is not necessarily required, the way JavaScript
works!), LiveEdit seems to have an upper limit on the JS file size it can
swallow (around 10Mb). If your JS is bigger than that, the browser simply
crashes.

Hot-patching on recompile is explored in these SDBG classes:
https://github.com/sdbg/sdbg/tree/master/com.github.sdbg.integration.jdt/src/com/github/sdbg/integration/jdt/gwt

At the current stage, hot-patching works only via page refresh (which kinda
defeats the whole purpose), due to (a) the changes required to the GWT JS
code emitter itself, and (b) because of the aforementioned Chrome LiveEdit
limitation.

24 ноември 2014, понеделник, 21:57:15 UTC+2, Brandon Donnelson написа:

Ah ha, nice. Thanks for sharing. I remember seeing Lief's work now that
you bring that up.

Ok I'm ending my OOPHM hacking, although I'd like to look at the
possibility of using IDE to remotely control browser dev tools and work
with the SDM systems, or in other words I like what Ray said.

Like working with break points in the browser source maps could be synced
the IDE breakpoints. Would be nifty to look into js modifications done in
incremental compile and inject them into the browser instead of waiting for
them to be loaded again on refresh.

Thanks,
Brandon

On Monday, November 24, 2014 10:30:24 AM UTC-8, Goktug Gokdogan wrote:

Somebody previously experimented with it:
https://github.com/Legioth/devmodejs

On Mon, Nov 24, 2014 at 9:49 AM, 'Ray Cromwell' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:

If you mean replacing the DevMode plugin with pure JS in Chrome Dev
Tools, I don't think it's practical. You need synchronously re-entrant
code execution. Javascript's only synchronous blocking call is XHR
sync. But you also need re-entrancy, and when you are
debugging/pausing execution, you run into additional hurdles. Many
people have tried hacks to do this, with Applets, with XHR, it's
possible in theory if you rewrite all code sent to the browser to use
continuations. I would advocate just continuing to make IDE
integration with SDM better.

On Mon, Nov 24, 2014 at 9:38 AM, Brandon Donnelson
branfl...@gmail.com wrote:
I'm investigating the possibility of creating a js chrome dev tools
extension to talk OOPHM with GPE OOPHM. So far it looks potential
feasible
to use what's in place on in GPE to do the communicating with some new
browser extension. Although I do see having to write some new
bidirectional
options to sync up the log entries and maybe adding some new parsing
ability
for sdm output.

For those who might know some about the OOPHM process, would you see
any
hang ups in writing a chrome dev tools javascript extension?

Thanks,
Brandon

https://groups.google.com/d/msgid/google-web-toolkit-contributors/a1363906-faef-427d-b8f6-c9209dce891a%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send
an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7cKBFJeg8S-1B_Mzw%2BGMb21k-3qkRO-jzb%2B0-hQkR%3D4VQ%40mail.gmail.com
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/bcf01e57-63c7-48c1-9655-65e67815af0a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: GWT 2.7 SDM incremental output too large

2014-10-23 Thread Ivan Markov



  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 shameless plug: this is anyway what SDBG does already now...
Blink's remote debugging protocol has no idea what a sourcemap is, aside 
from one little string hint telling me what is the name of the sourcemap 
file associated with script XYZ (which is btw very useful as it saves me 
from fetching the huge GWT JS output and scanning //# sourceMappingURL=). All 
the sourcemap parsing and indexing is happening in Eclipse.

Of course it is another topic that as of now, SDBG still only supports 
Chrome.

-- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/fb484556-ef5c-43de-aaaf-cd55856837be%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Chrome LiveEdit and SDM

2014-09-06 Thread Ivan Markov

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 even if there is a //sourceURL= hint at the end of it.

So the good news is that the xsiframe linker does not need any of the
original changes I thought would be needed, and in theory should work out
of the box.

The bad news:
Chrome LiveEdit seems to break simply when the script is too big:
- Above 10Mb, it is not editable at all from within Chromedevtools. I don't
know whether this is a restriction of Chromedevtools, or of V8;
- But even below 10Mb, editing large script files usually leads to the
browser getting stuck for some seconds and then simply crashing;

Next steps:
(1) I'll try to check if LiveEdit would work with at least (very) small GWT
projects;
(2) Splitting the large scripts into many smaller scripts may solve the
problem? If yes, then the code splitting logic in the xsiframe linker which
is currently incompatible with sourcemaps should be implemented in a way
compatible with sourcemaps - somehow;
(3) Maybe file bugs to Chromium?

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/0c37043f-ae49-4b8a-a5d2-20e2e821ea94%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Chrome LiveEdit and SDM

2014-09-06 Thread Ivan Markov

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 a script containing the changed types 
should be injected, however I'm not sure if/what needs to be fixed so that 
sourcemaps continue to work after that.)

-- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/eeeb5252-162b-4381-a3fa-14da59fa9873%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Chrome LiveEdit and SDM

2014-09-04 Thread Ivan Markov

Thanks for the hint.
Any idea why the code server insists on using the xsiframe linker? 5 lines
below your suggested fix there is even a check if the primary linker is a
descendant of xsiframe.

01 септември 2014, понеделник, 23:00:15 UTC+3, John Stalcup написа:

err, in master that would be
https://gwt.googlesource.com/gwt.git/+/master/dev/codeserver/java/com/google/gwt/dev/codeserver/Recompiler.java

and line 327

On Mon, Sep 1, 2014 at 12:58 PM, John Stalcup sta...@google.com
javascript: wrote:

you could try changing line 182 in Recompiler.java to register the std
linker
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 and the xsiframe: :)
(a) Like xsiframe, it injects script tags in the document body via
JavaScript, which makes these script tags uneditable via Chrome LiveEdit
(b) Like sso, it uses the Module Pattern to wrap all GWT code in a
function closure. I doubt that LiveEdit can replace the so-wrapped
functions, even if problem (a) was solved somehow.

I think a better starting point would be the xsiframe linker, as it at
least does not use the Module Pattern (right?) so at least problem (b) is
gone.

31 август 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
wrote:

(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 module.nocache.js works
- However editing module-0.js does not work (big surprise)

Problem 1: I think the sourceURL=module-0.js line at the end of
the script should be present only if CrossSiteIframeLinker is running in
non-pretty / production mode. In pretty mode, where the script tag
src
attribute is directly modified to point to the CAGFG...AB.cache.js
permutation this is probably just bringing confusion, no?

Unfortunately, fixing Problem 1 alone did not enable LiveEdit.
I think another issue (let's call it Problem 2) is that the xsiframe
linker is creating the iframe script tags dynamically using
JavaScript DOM manipulations. There is some evidence on the internet that
editing scripts injected that way is not supported.

I was thinking of solving Problem 2 by just switching to the sso
(SingleScriptLinker) linker, but then:
(a) It is still not supported in SuperDevMode -
https://code.google.com/p/google-web-toolkit/issues/detail?id=7722
(b) By looking at the source, it seems it is wrapping all the
generated GWT code in enclosing functions, which are then called at the
end
of the script block. I don't think LiveEdit will be re-evaluating these,
so
this wrapping has to go somehow...

Any ideas?

--
You received this message because you are subscribed to the Google
Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send
an email to google-web-toolkit-contributors+unsubscribe@
googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/google-web-toolkit-contributors/033a0106-49a2-
4d66-aed0-5ee07d515c4d%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/033a0106-49a2-4d66-aed0-5ee07d515c4d%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

https://groups.google.com/d/msgid/google-web-toolkit-contributors/6d7bf5da-0ba5-48a1-b2f7-2dec9e74370b%40googlegroups.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/ffeaade4-ad02-4483-87e5-f1b9e0730a87%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Chrome LiveEdit and SDM

2014-09-01 Thread Ivan Markov

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 recompile means
the developer has to essentially start over in reproducing the problem
being debugged (e.g. navigating in the webapp, opening the relevant
screens, clicking here and there, etc.).

This problem is not something new. It is well known and addressed when
doing e.g. server-side or rich client development (HotSpot hot code
replace; JRebel; edit-and-continue in the .NET / Win32 world, etc.)

How can webapp reloading be removed? By integrating SuperDevMode in Eclipse
in such a way that:
(a) The SDM recompilation to be transparent and part of the regular IDE
project build (
https://github.com/ivmarkov/sdbg/blob/master/com.github.sdbg.integration.jdt/src/com/github/sdbg/integration/jdt/gwt/GWTSDMBuilder.java
)
(b) The JavaScript generated by the recompilation should be automatically
pushed to Chrome via the Chrome Debugger wire protocol - without reloading
the webapp
(
https://github.com/ivmarkov/sdbg/blob/master/com.github.sdbg.integration.jdt/src/com/github/sdbg/integration/jdt/gwt/GWTSDMBuilder.java

https://github.com/ivmarkov/sdbg/blob/master/com.github.sdbg.integration.jdt/src/com/github/sdbg/integration/jdt/gwt/GWTSDMDOMResourceTracker.java
)

Both (a) and (b) are easy, except that (b) does not work. It does not work,
because the way the xsiframe linker injects the permutation script in the
DOM is not compatible with Chrome LiveEdit.

P.S. As for my SDM recompilation times - see here:
https://groups.google.com/forum/#!topic/google-web-toolkit-contributors/1EYSq2QZ51s

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/69679d80-0294-493c-b703-c2d2caf3ceb5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Chrome LiveEdit and SDM

2014-09-01 Thread Ivan Markov

Ray,

Using the xs linker seems like a bad idea, as it combines the disadvantages
of sso and the xsiframe: :)
(a) Like xsiframe, it injects script tags in the document body via
JavaScript, which makes these script tags uneditable via Chrome LiveEdit
(b) Like sso, it uses the Module Pattern to wrap all GWT code in a function
closure. I doubt that LiveEdit can replace the so-wrapped functions, even
if problem (a) was solved somehow.

I think a better starting point would be the xsiframe linker, as it at
least does not use the Module Pattern (right?) so at least problem (b) is
gone.

31 август 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 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 module.nocache.js works
- However editing module-0.js does not work (big surprise)

Problem 1: I think the sourceURL=module-0.js line at the end of the
script should be present only if CrossSiteIframeLinker is running in
non-pretty / production mode. In pretty mode, where the script tag src
attribute is directly modified to point to the CAGFG...AB.cache.js
permutation this is probably just bringing confusion, no?

I was thinking of solving Problem 2 by just switching to the sso
(SingleScriptLinker) linker, but then:
(a) It is still not supported in SuperDevMode -
https://code.google.com/p/google-web-toolkit/issues/detail?id=7722
(b) By looking at the source, it seems it is wrapping all the generated
GWT code in enclosing functions, which are then called at the end of the
script block. I don't think LiveEdit will be re-evaluating these, so this
wrapping has to go somehow...

Any ideas?

https://groups.google.com/d/msgid/google-web-toolkit-contributors/033a0106-49a2-4d66-aed0-5ee07d515c4d%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/6d7bf5da-0ba5-48a1-b2f7-2dec9e74370b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Chrome LiveEdit and SDM

2014-08-31 Thread Ivan Markov

(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 module.nocache.js works
- However editing module-0.js does not work (big surprise)

Problem 1: I think the sourceURL=module-0.js line at the end of the 
script should be present only if CrossSiteIframeLinker is running in 
non-pretty /  production mode. In pretty mode, where the script tag src 
attribute is directly modified to point to the CAGFG...AB.cache.js 
permutation this is probably just bringing confusion, no?

Unfortunately, fixing Problem 1 alone did not enable LiveEdit.
I think another issue (let's call it Problem 2) is that the xsiframe linker 
is creating the iframe  script tags dynamically using JavaScript DOM 
manipulations. There is some evidence on the internet that editing scripts 
injected that way is not supported.

I was thinking of solving Problem 2 by just switching to the sso 
(SingleScriptLinker) linker, but then:
(a) It is still not supported in SuperDevMode - 
https://code.google.com/p/google-web-toolkit/issues/detail?id=7722
(b) By looking at the source, it seems it is wrapping all the generated GWT 
code in enclosing functions, which are then called at the end of the script 
block. I don't think LiveEdit will be re-evaluating these, so this wrapping 
has to go somehow...

Any ideas?

-- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/033a0106-49a2-4d66-aed0-5ee07d515c4d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: SDM -XcompilePerFile: initial feedback

2014-08-29 Thread Ivan Markov

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

The improvement compared to my original post seems to be:
- 50% to 100% for a single file recompile
- 300% to 400% for the linking phase

The machine is an ageing core I7-2630QM

Regarding project size, SDM reports traversal of 76197 fields and methods 
and 6950 types.

As for bugs, I don't have anything to report, but I was not using 2.7 on a 
daily basis yet.

-- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/415d940f-071b-4e37-99d7-1c88a0df437c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: SDM -XcompilePerFile: initial feedback

2014-08-29 Thread Ivan Markov

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 
recompilation time; this time it is 8 instead of 13 seconds for the same 
set of around 10 changed files. Linking still 3 seconds.

I think you are getting there!

-- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/c646cebb-005a-42fd-9f9d-62334e1a3189%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: SDM -XcompilePerFile: initial feedback

2014-08-19 Thread Ivan Markov

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 that outputs js for different
Java classes to different resources and that could be incrementalized.

Sounds interesting! However if you mean separate JavaScript file per Java
class, wouldn't that generate too many Javascript files in case I have,
say, refactor-renamed a heavily used method? Another approach is maybe each
time to output a single JavaScript file, which contains the delta of the
changes to the previous JavaScript file (i.e. some new functions and some
function redefinitions). Then the browser uses the old JavaScript + the new
one... Anyway, just thinking loud, you sure know the topic better than me...

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
code server rather than being pregenerated on disk during the
recompilation? There are debugging scenarios (in-IDE debugging with SDBG),
where these source files are not even needed and never requested from the
codeserver.

I am currently working on this one. There are two options here: 1)
serving source code directly without copying and 2) copying only changed
sources. Option 1) would be the optimal in terms of compile time but it
might result of a worse debugging experience (if you modify a source while
debugging the source mapping will be out of date).

I think the out-of-date problem in option (1) does not happen so often in
practice.
Also, even if you do (2), the out-of-date problem is impossible to avoid if
you use an in-IDE debugger like SDBG. Reason: SDBG is not really using the
source files' copies you generate in the code server, but rather is opening
and using directly the source files in the Eclipse project (and that's how
it should be or else the integration between editing and debugging won't be
so seamless). The DART Editor does it too, and I would assume JIDEA does
the same.

So IMO the ideal solution would be if you serve the source files directly,
and maybe keep the option to pregenerate the source files on disk if
somebody is using an out-of-IDE debugger like ChromeDevTools and wants to
avoid the out-of-date problem by all means.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/a374638a-d924-4977-b14b-80b7615b9721%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: SDM -XcompilePerFile: initial feedback

2014-08-19 Thread Ivan Markov

(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 debugging, as the application state is lost.

Now, the debugging protocol of Blink allows the debugger to hot-swap a
piece of JavaScript with a newer version, right?
If the incremental compiler preserves the names of the generated
Javascript types/functions, then a debugger like SDBG can detect the SDM
recompilation and can pro-actively push the newly generated JavaScript into
the browser. Imagine how cool is this: you stay on the page, spot a bug
(say, in an onclick event handler), fix the bug in the Java code, hit the
Recompile button (or Eclipse/SDBG does it for you behind the scenes when
you save your Java file!) and there you have it - you can click again and
now the correct, recompiled event handler will be triggered. All of this
without leaving the application page and starting over.

Of course, for the above to work, additional changes may be necessary.
For example, contrary to production, the generated javascript file should
probably always be named the same way. Perhaps, it should also not contain
one big eval statement. Finally, for big changes, the above hot-swapping
will likely not work, but the idea is not to make it work in all cases, but
for the majority of the small, incremental changes.

It does sound like an interesting idea. If at some point the browser
reload time (as opposed to the compile time) is the longest part then we
will start looking at ways to speed that up. One similarish idea we've
discussed is to change the linkers so that the output JS exists as
separates files. This would allow the browser to hold on to it's
precompiled javascript cache for parts of the application that haven't
changed (thus reload much faster). But as Ray mentions, we're pretty heads
down on an earlier stage of development right now. So I probably won't be
looking at something like this any time soon, but patches welcome.

The javascript hot swapping is not (only) addressing the browser page
reload time. Rather, it is addressing the frustration of the user that he
has lost the state of the app due to the page reload, and now she has to
potentially do lots of manual clicks and types *inside* the app until it is
brought again to the state where the bug happens. But for sure this is a
much lower priority than having a very fast incremental recompilation and
relinking. Once I have some time myself, I may start looking into hot
swapping in the context of SDBG.

(BTW, If outputting the 30+ MB javascript file does take some time then
looking into outputting instead a delta javascript file as you hint is
probably worth it even if we put aside my dreams for hot-code swapping via
the debugger... but then I'm only speculating here...)

What I am working on is trying to flesh out the maturity of this current
approach. At the moment we do not notice when you change the content of
resource files which were inputs to Generators and so as a result we fail
to rerun those Generators when we should. Once this is corrected there will
be a while spent on general bug finding.

After that we will probably start looking at remaining performance
bottlenecks. Roberto is already looking at Linkers and we think that the
next big opportunity after that will be in improving the TypeOracle
construction time (see
https://gwt.googlesource.com/gwt/+/master/dev/core/src/com/google/gwt/dev/javac/CompilationUnitTypeOracleUpdater.java

and related classes). But there will probably be other opportunities as
well.

Sounds great. I am already happy with the current 7 seconds recompile (as
long as the 18 seconds of relinking go down to 2 or so :-) ), but faster is
always better.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/1132c1d4-0ac7-4d1e-a1ad-7575e6dadab5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] SDM -XcompilePerFile: initial feedback

2014-08-18 Thread Ivan Markov

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 internal compiler errors or visible 
malfunctioning.

And this with NO changes to the codebase. Also the fact that I don't have 
to split our codebase into very many small acyclic modules (not that it is 
not a good practice anyway) is obviously a HUGE PLUS.

What I am observing in terms of recompilation times is encouraging (25 
seconds with 2.7 vs. 47 with 2.6.1) but what is even more interesting is 
that the compilation itself (up until where it says Compile of 
permutations succeeded) seems to take only 7 seconds, which is less than 
30% of the recompilation time.

In other words, with the new incremental compiler, the biggest slowdown 
during recompilation seems to be the linker now, right?
If the linking time can go down to, say, a couple of seconds, then SDM is 
there (IMO).

So out of pure curiosity - are there obvious optimizations in the linker 
which are still pending?

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 
code server rather than being pregenerated on disk during the 
recompilation? There are debugging scenarios (in-IDE debugging with SDBG), 
where these source files are not even needed and never requested from the 
codeserver.

Also, is there any way to accelerate the linker which is in the control of 
the developer?
For example, can I turn off the above source files pregeneration to see how 
much time is saved during recompilation?

= 

Finally one side question:
Does the incremental compiler preserve the names of the generated 
JavaScript types/functions across recompiles? Including the names of the 
types/functions which ARE recompiled (as long as the programmer did not 
change the name of the corresponding Java method/class, that is)?

Because if it does, this opens interesting possibilities:

(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 debugging, as the application state is lost. 

Now, the debugging protocol of Blink allows the debugger to hot-swap a 
piece of JavaScript with a newer version, right?
If the incremental compiler preserves the names of the generated Javascript 
types/functions, then a debugger like SDBG can detect the SDM recompilation 
and can pro-actively push the newly generated JavaScript into the browser. 
Imagine how cool is this: you stay on the page, spot a bug (say, in an 
onclick event handler), fix the bug in the Java code, hit the Recompile 
button (or Eclipse/SDBG does it for you behind the scenes when you save 
your Java file!) and there you have it - you can click again and now the 
correct, recompiled event handler will be triggered. All of this without 
leaving the application page and starting over.

Of course, for the above to work, additional changes may be necessary. For 
example, contrary to production, the generated javascript file should 
probably always be named the same way. Perhaps, it should also not contain 
one big eval statement. Finally, for big changes, the above hot-swapping 
will likely not work, but the idea is not to make it work in all cases, but 
for the majority of the small, incremental changes.

(b) On the fly evaluation of Java expressions in the debugger
The challenge here is that the expression being evaluated must be compiled 
as if it is already part of the GWT application (i.e.  if it refers to 
application's classes, methods fields etc., it should be with their correct 
javascript names). 
This sounds like a perfect fit for the incremental compiler - how about a 
new HTTP service point in the codeserver? Say, something like 
http://localhost:port?eval=Java-expression-or-if-required-whole-Java-type, 
which outputs, as a response, a valid JavaScript block of code which can be 
evaluated by the debugger? SDBG (or other debugger) will then use the SDM 
codeserver as a compiler of sorts for the expression entered by the user 
during debugging.

I'm surely missing something - for example the evaluated expression needs 
to be capable of accessing the variables on the currently selected 
stackframe in the debugger, but if Eclipse's Java debugger is capable of 
doing that without special support in the Java debugging protocol, then it 
should be possible for our case as well.

What do you think?

-- 
You received this message because you are subscribed

Re: [gwt-contrib] SDM -XcompilePerFile: initial feedback

2014-08-18 Thread Ivan Markov

Actually, saving sources isn't strictly needed to make source maps work,
especially for non-Googlers, so we can probably default this to false.

This is likely to break the ChromeDevTools debugger, as it does need and
does request those source files from the codeserver, isn't it?
(SDBG does not need these as it has the real source files in the Eclipse
IDE.)

Therefore the perfect scenario would be if these files are indeed
materialized by the codeserver lazily, on a file-by-file basis, once such a
file is requested by the browser.
A compromise would be if there is an option to switch their generation off,
but it defaults to ON (generating them).

Finally one side question:
Does the incremental compiler preserve the names of the generated
JavaScript types/functions across recompiles? Including the names of the
types/functions which ARE recompiled (as long as the programmer did not
change the name of the corresponding Java method/class, that is)?

Yes, within a session. If you restart SDM, then no. Hot-patching and
expression evaluation are definitely things we've discussed (I want to
build an Apple XCode/Swift Playground-like REPL for fun myself), but first
we've got to make the normal SDM experience out of the box great, including
IDE integration and super-fast recompile. Once we get there, hopefully we
can do the other things and reach a state that was better than DevMode was.

I think within a session is good enough.
And yes, super-fast recompile is the most important thing of all.
Everything else can wait.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/fd6bda6d-1a6e-4e8c-9df3-7d62bf7bbc77%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Development Mode will not be supported in Firefox 27+

2014-04-10 Thread Ivan Markov

The StackTraceDeobfuscator does not play very well with the Super Dev Mode
code server though.

Reason: StackTraceDeobfuscator needs to have access to the
AABBCD...HF.symbolMap files generated during the last SDM compilation.
However this directory is a moving target in the SDM code server because
each compilation done by the SDM code server creates a *brand new*
directory containing all the artefacts generated by this compilation (JS
files, source maps, symbol maps). I.e.:
- Initially, the symbol maps can be found here:
code-server-work-dir/module-name/*compile1*
/war/WEB-INF/deploy/short-module-name/SymbolMaps
- After the second compilation, they are here:
code-server-work-dir/module-name/*compile2*
/war/WEB-INF/deploy/short-module-name/SymbolMaps
- and so on

For the JS files (and GWTRPC files) the above scheme is not a problem, as
the code server's own HTTP service serves all artefacts generated by the
latest compilation at this fixed URL:
http://localhost:sdm-port/short-module-name

... except for the source map and the symbol map

Now, the latest source map is also served by the code server, using another
magic URL (which I don't recall at the moment).
But no such luck for the symbol map...

Brian: how hard would it be to alter the code server to serve the symbol
map as well, at some special URL?

10 април 2014, четвъртък, 00:16:43 UTC+3, Brian Slesinsky написа:

If you are debugging interactively, using pause on uncaught exceptions
can help. Then you can look at the stack frames in the debugger.

Another workaround is to log stack traces to the server and use
StackTraceDeobfuscator. This will also help you in production:

http://www.gwtproject.org/javadoc/latest/com/google/gwt/core/server/StackTraceDeobfuscator.html

I don't think we can easily deobfuscate stack traces in the GWT
application itself, because it requires the sourcemap which is normally
only loaded by the debugger. It would be possible with a round trip to the
Super Dev Mode code server, but this would be an asynchronous call so the
API would be awkward.

On Wed, Apr 9, 2014 at 2:03 PM, Chak Lai chakl...@gmail.com javascript:
wrote:

The stack-trace in Super Dev Mode is the only major issue that I have. It
would be nice if the UncaughtException in SDM can tell me which line in
java source is causing the problem, instead of giving me those JavaScript
stack-trace messages...

So far I like SDM. My current project is running a lot faster in SDM
compare to Development Mode plugin.

--
You received this message because you are subscribed to a topic in the
Google Groups Google Web Toolkit group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/google-web-toolkit/QSEjbhhHB4g/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
google-web-toolkit+unsubscr...@googlegroups.com javascript:.
To post to this group, send email to
google-we...@googlegroups.comjavascript:
.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Development Mode will not be supported in Firefox 27+

2014-04-04 Thread Ivan Markov

Regarding sourcemap support for fields/variable names deobfuscation:

1- I found some thoughts on SourceMap.next here: 
http://fitzgeraldnick.com/weblog/55/ . 
It goes as far as suggesting how conditional breakpoints and eval() 
expressed in the source language can work for sourcemap-based debuggers. 
(If I understand it correctly, it shifts the responsibility for 
implementing these to the transpiler. The debugger will just call a 
javascript function defined in the sourcemap).

2- Some thoughts how we may address the problem in SDBG (the sourcemap JS 
debugger for Eclipse): https://github.com/sdbg/sdbg/issues/6


02 април 2014, сряда, 20:04:33 UTC+3, Brian Slesinsky написа:

 It's true these are disadvantages.  There are some compensating advantages 
 that people are pointing out: the code executes faster, it works with 
 remote websites where latency is higher, it works with mobile phones, and 
 so on. But there's no question that losing DevMode (other than IE and 
 Firefox 24) is a loss.

 Our short-term plan is to speed up compiles and generate JavaScript that 
 looks more like Java for Super Dev Mode and draftCompile. But it it will 
 still be JavaScript, and we will have to adjust. Longer-term, it may be 
 possible to create a variable inspector that shows Java objects instead of 
 JavaScript objects, but that isn't even prototyped yet.



 On Wed, Apr 2, 2014 at 8:35 AM, Jérôme Beau java...@gmail.comjavascript:
  wrote:

 Hi Ümit,

 By I cannot inspect Java values of Java variables I mean that the 
 source-mapping of the Chrome Dev Tools (which are good for JS) :

 - *shows me stuff I'm not interested into *(most of the time) : this 
 is Window[0], DOM, JS or internal GWT-generated functions or properties 
 appear, such as $H, ___clazz$, getClass$, hasCode$, toString  
 toString$, attached, eventsToSink, proto, etc.
 -* renames stuff I'm interested into* : MyClass becomes MyClass 0 
 1, etc. this becomes this$static
 - *doesn't allow me to skip only in my code by defaut*, that 
 is,  automatically skip internal, gwt-generated code while stepping
 - *doesn't allow me to use Java-expressions in breakpoints nor 
 evaluations* : have to use JS string.length, not String.length() for 
 instance, etc.

 You know, this just like when you debug plain Java code. Most of the 
 time, you are not interested in debugging JDK sources. This may be 
 interesting for understanding things and optimization (if you forget that's 
 only draft JS code that will _not_ be the final code), but this is disabled 
 by default. One might also consider than inspecting bytecode is good for 
 understanding and optimization, but that's not reasonnable. 

 Le mercredi 2 avril 2014 16:26:50 UTC+2, Ümit Seren a écrit :

 What exactly do you mean with I cannot inspect Java values of Java 
 variables with SDM ? 
 Can you provide an example where you can't inspect a Java value with 
 Chrome Dev Tools ? 

 I think Dev Mode will never come back. SDM is here to stay and despite 
 there is a lot to be desired, with time development experience will be much 
 better than with normal Dev Mode. 

 The Chrome team is putting huge amounts of work into improving Chrome 
 Dev Tools. 
 The profiling features are crucial if you want to create performant web 
 apps and I prefer to do all task (profiling, fiddling with DOM/CSS and 
 debugging) right in the Chrome Dev Tools rather than switching between 
 Chrome Dev Tools and my IDE. 

 For those who really need the features of their IDE there are some 
 efforts to bring sourcemap debugging to eclipse (AFAIK IntelliJ has already 
 support for it built in)

 The biggest issue with SDM are currently compile times but that's going 
 to improve with the incremental compiler in GWT 2.7. 



 On Wed, Apr 2, 2014 at 3:57 PM, Jérôme Beau java...@gmail.com wrote:

 Hi Jens,

 Just for the record : do you agree that using SDM you cannot inspect 
 Java values of Java variables in your browser? I agree about the mobile 
 dev, about knowing the underlying web platform, about everything but... 
 any 
 debugging session, Java or JS, have to be consistent : if I debug JS, I 
 expect to have JS inspections ; if I debug Java (even in the browser 
 through sourcemaps), I expect to see Java values and Java symbols, and I 
 expect that my conditional breakpoints occur on Java expressions, not JS 
 expressions. That's it. Otherwise I would have used a JS framework.

 Is there a tiny possibility that GWT can provide this in some future? 


 Le mercredi 2 avril 2014 12:47:45 UTC+2, Jens a écrit :

 I just realized that lack of Firefox 27+ support for dev mode recently 
 (tried it because Chrome's plugin crashed too often) and really think 
 this 
 is a shoot in the foot for GWT : even if you don't control Mozilla 
 choices 
 of course, forcing to move to a non-mature SDM is very risky for GWT 
 itself.


 But there is no other viable solution and the transition was actually 
 planed more smoothly. I can understand that many

[gwt-contrib] Re: Next Contributor Hangout

2014-03-15 Thread Ivan Markov

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, събота, 06:37:46 UTC+2, Bhaskar Janakiraman написа:

 Hi Folks,
 The next contributor hangout will be on Wednesday, February 26, from 
 10.45am to 11.30am PST. As before, please send me email (bjanakiraman at 
 google) if you have something to discuss and want to participate in person, 
 and I'll send you an invite. 

 Agenda:
 Discuss on-going work and patches. 

 The session will be recorded and made available via the GWT G+ 
 pagehttps://plus.google.com/u/1/b/116516353752856283537/116516353752856283537/posts
 . 

 Thanks,
 Bhaskar


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

SuperDevMode: speedtracer.html reports much shorter compile times than what is really observed

2014-02-22 Thread Ivan Markov

I'm using GWT 2.5.1 (still).

The subject says it all: 
- The reality: our project compiles for ~ 38 seconds (in the SuperDevMode 
Code Server; single permutation; second  subsequent compilations). (This 
is what is printed in the Code Server console, and what I observe using a 
stopwatch.) 
- But according to the generated speedtracer.html file - big surprise - it 
should have taken a mere 15 seconds! 

Is anyone aware of any inaccuracies in the Speed Tracer logs?

(I can email (personally) the speed tracer file as well as the console 
logs.)

=

P.S. Regarding Speed Tracer - this 
(https://code.google.com/p/speedtracer/issues/detail?id=54sort=-id) is 
really annoying.
Anyone willing to push a new release to Chrome Web Store?
Or - if ChromeDevTools' Timeline view is the future - how about changing 
the GWT compiler to generate profiling info compatible with ChromeDevTools 
instead?

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit 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 http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Re: Next Contributor Hangout

2014-02-04 Thread Ivan Markov

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 Janakiraman написа:

 Hi Folks,
 Sorry about this, but I'm going to have to move this hangout by a week, to 
 Wednesday Feb 5th, same time -  10.45 to 11.30am. We have another internal 
 (Google) meeting that requires me and other GWT team members to be present. 

 The meeting will still be recorded and available as usual. 

 Thanks,
 Bhaskar


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

Re: [gwt-contrib] The elusive J2CL

Re: [gwt-contrib] The elusive J2CL

Re: [gwt-contrib] The elusive J2CL

[gwt-contrib] The elusive J2CL

[gwt-contrib] Kotlin/JS - Interop with Google’s J2CL - what would it take?

Re: GWTReact Release and Roadmap

[gwt-contrib] Re: Thoughts on DevMode

Re: [gwt-contrib] Thoughts on DevMode

Re: Vue GWT: Vue.JS integration for GWT 2.8

Re: Vue GWT: Vue.JS integration for GWT 2.8

Re: SDM and client debugging with eclipse debugger?

Re: SDM and client debugging with eclipse debugger?

Re: [gwt-contrib] Invesigating OOPHM chrome dev tools js extension creation

Re: [gwt-contrib] Re: GWT 2.7 SDM incremental output too large

Re: [gwt-contrib] Chrome LiveEdit and SDM

Re: [gwt-contrib] Chrome LiveEdit and SDM

Re: [gwt-contrib] Chrome LiveEdit and SDM

Re: [gwt-contrib] Chrome LiveEdit and SDM

Re: [gwt-contrib] Chrome LiveEdit and SDM

[gwt-contrib] Chrome LiveEdit and SDM

Re: [gwt-contrib] Re: SDM -XcompilePerFile: initial feedback

Re: [gwt-contrib] Re: SDM -XcompilePerFile: initial feedback

[gwt-contrib] Re: SDM -XcompilePerFile: initial feedback

[gwt-contrib] Re: SDM -XcompilePerFile: initial feedback

[gwt-contrib] SDM -XcompilePerFile: initial feedback

Re: [gwt-contrib] SDM -XcompilePerFile: initial feedback

Re: Development Mode will not be supported in Firefox 27+

Re: Development Mode will not be supported in Firefox 27+

[gwt-contrib] Re: Next Contributor Hangout

SuperDevMode: speedtracer.html reports much shorter compile times than what is really observed

[gwt-contrib] Re: Next Contributor Hangout

32 matches

Site Navigation

Mail list logo

Footer information