Re: [gwt-contrib] Chrome LiveEdit and SDM
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
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
Re: [gwt-contrib] Chrome LiveEdit and SDM
HotPatching via recompilation will require significant work in SDM. If you just did the naive thing and patched in the JS that changed, stuff would break: 1) clinit()s which have already been called would be restored, so classes would get initialized twice 2) some instance fields of the class would get reinitialized 3) callbacks held by JSNI closures might still point to old code in some circumstances I think SDM mode would have to do minimally the following: 1) collect only the JS that actually changed 2) don't emit clinits for already live classes, and if the user added a new clinit to an existing class or a new statically initialized field, force a full refresh 3) don't re-emit field initializers for existing fields on classes, only for new added fields 4) if method signatures change, may have to force a full refresh 5) the code must be patched in via linker-dependent scope injection as if it were an AsyncFragment On Sat, Sep 6, 2014 at 9:05 AM, Ivan Markov wrote: > 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
