[gwt-contrib] Re: FF8 Devmode Plugin (issue1589803)
On 2011/11/14 17:53:37, conroy wrote: http://gwt-code-reviews.appspot.com/1589803/diff/1/plugins/xpcom/ExternalWrapper.cpp File plugins/xpcom/ExternalWrapper.cpp (right): http://gwt-code-reviews.appspot.com/1589803/diff/1/plugins/xpcom/ExternalWrapper.cpp#newcode28 plugins/xpcom/ExternalWrapper.cpp:28: #include nsIDOMWindowInternal.h I still see unguarded references to nsIDOMWindowInternal in this file. http://gwt-code-reviews.appspot.com/1589803/diff/1/plugins/xpcom/Makefile File plugins/xpcom/Makefile (right): http://gwt-code-reviews.appspot.com/1589803/diff/1/plugins/xpcom/Makefile#newcode138 plugins/xpcom/Makefile:138: MOZALLOC_DLLFLAGS = -lmozalloc On 2011/11/11 10:16:05, tbroyer wrote: In http://gwt-code-reviews.appspot.com/1560803/ we talked about refactoring the MOZALLOC_DLLFLAGS, MOZJS_DLLFLAGS and ALLARCHCFLAGS before the 'ifeq ($(BROWSER),FF40)' (just after line 94) instead of copy/pasting them in each version. indeed. please make this change. FYI ping! http://gwt-code-reviews.appspot.com/1589803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: FF8 Devmode Plugin (issue1589803)
http://gwt-code-reviews.appspot.com/1589803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: FF8 Devmode Plugin (issue1589803)
On 2011/12/02 21:26:45, acleung wrote: PTAL. Thanks. -Alan http://gwt-code-reviews.appspot.com/1589803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: FF8 Devmode Plugin (issue1589803)
LGTM + nit http://gwt-code-reviews.appspot.com/1589803/diff/7001/plugins/xpcom/Makefile File plugins/xpcom/Makefile (right): http://gwt-code-reviews.appspot.com/1589803/diff/7001/plugins/xpcom/Makefile#newcode141 plugins/xpcom/Makefile:141: endif nit: you could make these all independent if statements (rather than chained if-elses) and then check that the GECKO_VERSION is set to something at the end. If make weren't such an abomination of a syntax, this wouldn't be an issue. http://gwt-code-reviews.appspot.com/1589803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: FF8 Devmode Plugin (issue1589803)
http://gwt-code-reviews.appspot.com/1589803/diff/1/plugins/xpcom/ExternalWrapper.cpp File plugins/xpcom/ExternalWrapper.cpp (right): http://gwt-code-reviews.appspot.com/1589803/diff/1/plugins/xpcom/ExternalWrapper.cpp#newcode28 plugins/xpcom/ExternalWrapper.cpp:28: #include nsIDOMWindowInternal.h I still see unguarded references to nsIDOMWindowInternal in this file. http://gwt-code-reviews.appspot.com/1589803/diff/1/plugins/xpcom/Makefile File plugins/xpcom/Makefile (right): http://gwt-code-reviews.appspot.com/1589803/diff/1/plugins/xpcom/Makefile#newcode138 plugins/xpcom/Makefile:138: MOZALLOC_DLLFLAGS = -lmozalloc On 2011/11/11 10:16:05, tbroyer wrote: In http://gwt-code-reviews.appspot.com/1560803/ we talked about refactoring the MOZALLOC_DLLFLAGS, MOZJS_DLLFLAGS and ALLARCHCFLAGS before the 'ifeq ($(BROWSER),FF40)' (just after line 94) instead of copy/pasting them in each version. indeed. please make this change. http://gwt-code-reviews.appspot.com/1589803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: FF8 Devmode Plugin (issue1589803)
I'll reiterate my question: is there any plan to move to js-ctypes? or is there some better alternative? or are binary components and recompiling every 6 weeks a necessary evil? I mean, have you looked at the problem yet? and if so what's the outcome? and is there a plan on your side? If you believe js-ctypes could work, but do not have time/resources to invest in moving to them, then maybe I could try it on my side. But if you already looked at it and know that js-ctypes won't work, then I won't invest time. And if you have a plan to do the move on your side, then I'll wait too. http://gwt-code-reviews.appspot.com/1589803/diff/1/plugins/xpcom/Makefile File plugins/xpcom/Makefile (right): http://gwt-code-reviews.appspot.com/1589803/diff/1/plugins/xpcom/Makefile#newcode138 plugins/xpcom/Makefile:138: MOZALLOC_DLLFLAGS = -lmozalloc In http://gwt-code-reviews.appspot.com/1560803/ we talked about refactoring the MOZALLOC_DLLFLAGS, MOZJS_DLLFLAGS and ALLARCHCFLAGS before the 'ifeq ($(BROWSER),FF40)' (just after line 94) instead of copy/pasting them in each version. http://gwt-code-reviews.appspot.com/1589803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: FF8 Devmode Plugin (issue1589803)
Brian and Ray has been experimenting with different approaches to debug dev mode that steer away from browser plugins / APIs. They have had some success but from what I understand it is still in a very early stage. My plan is to keep FF going as long as possible in the mean time. -Alan On Fri, Nov 11, 2011 at 2:16 AM, t.bro...@gmail.com wrote: I'll reiterate my question: is there any plan to move to js-ctypes? or is there some better alternative? or are binary components and recompiling every 6 weeks a necessary evil? I mean, have you looked at the problem yet? and if so what's the outcome? and is there a plan on your side? If you believe js-ctypes could work, but do not have time/resources to invest in moving to them, then maybe I could try it on my side. But if you already looked at it and know that js-ctypes won't work, then I won't invest time. And if you have a plan to do the move on your side, then I'll wait too. http://gwt-code-reviews.**appspot.com/1589803/diff/1/** plugins/xpcom/Makefilehttp://gwt-code-reviews.appspot.com/1589803/diff/1/plugins/xpcom/Makefile File plugins/xpcom/Makefile (right): http://gwt-code-reviews.**appspot.com/1589803/diff/1/** plugins/xpcom/Makefile#**newcode138http://gwt-code-reviews.appspot.com/1589803/diff/1/plugins/xpcom/Makefile#newcode138 plugins/xpcom/Makefile:138: MOZALLOC_DLLFLAGS = -lmozalloc In http://gwt-code-reviews.**appspot.com/1560803/http://gwt-code-reviews.appspot.com/1560803/we talked about refactoring the MOZALLOC_DLLFLAGS, MOZJS_DLLFLAGS and ALLARCHCFLAGS before the 'ifeq ($(BROWSER),FF40)' (just after line 94) instead of copy/pasting them in each version. http://gwt-code-reviews.**appspot.com/1589803/http://gwt-code-reviews.appspot.com/1589803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: FF8 Devmode Plugin (issue1589803)
On Fri, Nov 11, 2011 at 5:16 AM, t.bro...@gmail.com wrote: I'll reiterate my question: is there any plan to move to js-ctypes? or is there some better alternative? or are binary components and recompiling every 6 weeks a necessary evil? I mean, have you looked at the problem yet? and if so what's the outcome? and is there a plan on your side? If you believe js-ctypes could work, but do not have time/resources to invest in moving to them, then maybe I could try it on my side. But if you already looked at it and know that js-ctypes won't work, then I won't invest time. And if you have a plan to do the move on your side, then I'll wait too. From a brief look, it seems there is no way to get a callback when an object is no longer referenced -- this is required to free the Java object that has been wrapped on the JS side once it is no longer referenced. It also wasn't clear how to create a JS object that wraps a Java object and intercept all the methods, but I assume that part can be done in JS. Aside from that, it looks like it is just moving parts of the problem around. Instead of having FF load the correct binary based on the platform, it looks like it is up to your JS code to figure out what to load (though the examples seem inconsistent, so maybe it isn't that bad). All the calls from the plugin to the JS engine will have to be proxied through the JS code (for example, I didn't see how to allocate a JS string), which will mean a lot of boilerplate and a likely performance impact. So, assuming the finalizer problem can be overcome, I think it would be possible but would be a lot of work to get worse performance. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: FF8 Devmode Plugin (issue1589803)
On Friday, November 11, 2011 4:38:23 PM UTC+1, John A. Tamplin wrote: On Fri, Nov 11, 2011 at 5:16 AM, t.br...@gmail.com wrote: I'll reiterate my question: is there any plan to move to js-ctypes? or is there some better alternative? or are binary components and recompiling every 6 weeks a necessary evil? I mean, have you looked at the problem yet? and if so what's the outcome? and is there a plan on your side? If you believe js-ctypes could work, but do not have time/resources to invest in moving to them, then maybe I could try it on my side. But if you already looked at it and know that js-ctypes won't work, then I won't invest time. And if you have a plan to do the move on your side, then I'll wait too. From a brief look, it seems there is no way to get a callback when an object is no longer referenced -- this is required to free the Java object that has been wrapped on the JS side once it is no longer referenced. It also wasn't clear how to create a JS object that wraps a Java object and intercept all the methods, but I assume that part can be done in JS. Re. intercepting methods, it's possible using proxies (will be in EcmaScript 6; usable since Firefox 4, but discouraged): https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Proxy and the non-standard __noSuchMethod__: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/NoSuchMethod Aside from that, it looks like it is just moving parts of the problem around. Instead of having FF load the correct binary based on the platform, it looks like it is up to your JS code to figure out what to load (though the examples seem inconsistent, so maybe it isn't that bad). As I understand it, in the case of the DevMode, only the common, browser-independent, part would be binary (there might not even be a need for glue code, or only for calling back to the JS engine) and everything else would be done in JS; so it'd save us from compiling one version of the binary component per Gecko SDK version, only one per OS. So releasing for a new version of Firefox would mean, in the best case, only bumping the maxVersion in the update.rdf; something that can be done by anyone locally, and you no longer have to wait for the SDK to be released. That'd also make it possible (and really easy) to test/use the plugin on beta or aurora versions. All the calls from the plugin to the JS engine will have to be proxied through the JS code (for example, I didn't see how to allocate a JS string), which will mean a lot of boilerplate and a likely performance impact. So, assuming the finalizer problem can be overcome, I think it would be possible but would be a lot of work to get worse performance. Searching a bit on the MDN, I don't see how the finalizer issue could be worked around, so I guess it's a show-stopper. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
