Invesigating OOPHM chrome dev tools js extension creation

[Brandon Donnelson]

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

[Ray Cromwell]

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.

> --
> 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-co...@googlegroups.com.
> To view this discussion on the web visit
> 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.

[Manuel Carrasco Moñino]

Leif at Vaadin already was exploring the possibility of having a devmode in pure JS, his experimental work is at https://github.com/Legioth/devmodejs, afaik although it's feasible (he succeed debugging some stuff) it is very slow, apart from other issues like memory allocation, etc.

 

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.

[Goktug Gokdogan]

Somebody previously experimented with it:

https://github.com/Legioth/devmodejs

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.

[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

> 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/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+unsubscribe@googlegroups.com.

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