[webkit-dev] How to Port Webkit to Andriod?
Hi,All: Is there anyone have done the job of porting Webkit to Andriod platform? Thanks. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScriptCore and ES6
Hi Andy, As you probably know, the ECMA TC39 committee is slowly approaching consensus on a new revision of the ECMAScript language. The interim results of this process have gone under various names: Harmony, ES.next, and ES6. They are the same thing. This mail is intended to open the discussion on what to do now regarding ES6 in JSC. Let's stick with using the name ES6. Per Brendan's comments I guess ES.next is probably more correct right now, but the meaning of ES.next is presumably liable to change once ES6 is released! ES6 does not yet define how extended mode is entered, however. Some ES6 functionality is incompatible both with classic mode and with strict mode, so it has to be an opt-in thing, perhaps via script type=application/ecmascript;version=6. However, there is a subset of ES6 that is compatible with strict-mode. I am interested in implementing parts of this set. Specifically, I am interested in implementing block-scoped `let' and `const'. I think it would be fine to enable the compatible subset of ES6 within all strict-mode code. It would not be incompatible with existing code on the web. V8 seems likely to go in this direction as well, and SpiderMonkey already has done so. Effectively, strict mode could become compatible extended mode, globally. As it stands, ES6 introduces a mix of new features (new syntax, which would have been syntax errors in ES5), and changes to the semantics of existing ES5 syntax (typeof null, resolving to global object). So far as the new features are concerned, I don't think we want to make them opt-in and artificially tie them to ES5 strict mode – these features have nothing to do with ES5 strict. If we do want these features to require an explicit opt-in, then they should be restricted to ES6 (extended mode). However I think it is probably unnecessary and undesirable to restrict them at all – instead we should just make them available to all scripts. In practice I don't think there will be any syntax extensions that would be backwards compatible from ES6 to ES5-strict, but not compatible with ES5. We have an existing extension to provide limited support for 'const' in classic mode for web compatibility reasons, but provided that it does not break the web to do so it would be better to replace this with ES6 compatible const semantics, rather than unnecessarily maintaining two separate and incompatible behaviours. Technically 'let' is not a reserved word outside of strict mode in ES5 which could be an issue, but I think even this can probably be support well in classic mode by handling it as a contextual keyword (compatible modulo a minor auto semicolon insertion quirk, I think). Similar for 'yield', and this is likely to be even less of an issue given the restricted context in which it can be used. So far as changes to the semantics of existing syntax are concerned, it is certainly possible that we will need to add support for the script tag to specifying a language version (likely passed into JSC as a property of the SourceCode object). In addition we may want to consider whether it makes sense to imply extended mode within ES6 language features – e.g. if we permit module syntax as an extension in ES5, we may want to enable full ES6 semantics for all code within the body of a module. If we do, this may mean propagating state that enables extended mode when parsing, and tracking this for functions (much as we do already for strict). Compatible extended mode is not a point we need to decide now, however. Implementation work towards agreed-upon parts of ES6 is useful in any eventuality. Now, it is fine enough to have an implementation of parts of ES6 behind an #ifdef. I think though that we should get to the point that the #ifdef is on by default, then removed entirely. We still need a bit to indicate at parse-time whether a piece of code is extended-mode or strict-mode. It does not seem that we need a runtime extended-mode bit, though, as we do with strict-mode vs classic-mode. My current approach to this, given that the ES6 draft doesn't specify how to enter extended mode, is to provide a global flag that turns strict mode into compatible extended mode. We may not want to enable ES6 support by default until the spec is stable and we have a relatively complete implementation, but this shouldn't block development or prevent features from being compiled in at an earlier stage. In fact, we really need to build in all features from the point they are added, so that regression tests can be committed along with the implementation. As such enabling ES6 support should be a runtime setting rather than at compile time one. This should be done via a page setting (WebCore/pages/Settings.h), since this will make it easy for us to enable ES6 support via the WebKit interface, from DRT or a browser (JSC should be able to query this setting via JSGlobalObject). Hope this
Re: [webkit-dev] JavaScriptCore and ES6
In general I think versioning is a bad idea, but out-of-band is even worse. We'd have to change Web Workers (both constructors and importScripts() would need to take some kind version-related information) and everyone on the platform would instead of simply using script have to resort back to specifying the type attribute again. We just got rid of that! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to Port Webkit to Andriod?
On Fri, Dec 16, 2011 at 08:11, michaelwang michaelw...@linpus.com wrote: Hi,All: Is there anyone have done the job of porting Webkit to Andriod platform? The Android port was partially upstreamed to WebKit, until it was removed earlier this year following an announcement by the Android team: https://lists.webkit.org/pipermail/webkit-dev/2011-August/017738.html https://bugs.webkit.org/show_bug.cgi?id=66688 Work is being done allowing the WebKit Chromium port to be build on Android, for which a meta-bug and build instructions are available. It is currently unable to link and/or run. https://bugs.webkit.org/show_bug.cgi?id=66687 http://trac.webkit.org/wiki/Chromium#BuildingonAndroid Best, Peter Thanks. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScriptCore and ES6
On Dec 16, 2011, at 1:24 AM, Anne van Kesteren wrote: In general I think versioning is a bad idea, but out-of-band is even worse. ES.next is going to have a use version 6; in-band pragma. /be ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] JavaScriptCore question
Hi all, I'm using JavaScriptCore for scripting purposes (isolated from webkit), and I'm encountering the following problem: I would like to store a reference to an anonymous function, and later to be able to call it as a callback, something like this: ---javascript node.schedule(some name, function () { ... }); --- What I'm doing right now is in the definition of node.schedule, I store the context and the function (as a JSValueRef), then when I need to call code in there, I'm doing this: JSObjectRef func = JSValueToObject(storedContext, storedCallback, NULL); JSObjectCallAsFunction(cb-context, func, storedObject, 0, NULL, NULL); It doesn't matter how I store the context/function, it always crashes when trying to either convert the value to object or call the object as function. At first I thought that the function was being garbage collected, but even after protecting it, I still got the crash. My guess is that the context is not the right one, so another question is: what context should I be passing here? What would be the right way to do this? Thanks, -- Rolando Abarca M. http://rolando.cl Phones: +1 (415) 655-1041 +56 (2) 581-4591 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScriptCore question
On Dec 16, 2011, at 9:05 AM, Rolando Abarca wrote: Hi all, I'm using JavaScriptCore for scripting purposes (isolated from webkit), and I'm encountering the following problem: I would like to store a reference to an anonymous function, and later to be able to call it as a callback, something like this: ---javascript node.schedule(some name, function () { ... }); --- What I'm doing right now is in the definition of node.schedule, I store the context and the function (as a JSValueRef), then when I need to call code in there, I'm doing this: JSObjectRef func = JSValueToObject(storedContext, storedCallback, NULL); JSObjectCallAsFunction(cb-context, func, storedObject, 0, NULL, NULL) It doesn't matter how I store the context/function, it always crashes when trying to either convert the value to object or call the object as function. At first I thought that the function was being garbage collected, but even after protecting it, I still got the crash. My guess is that the context is not the right one, so another question is: what context should I be passing here? This looks like you're storing the JSContextRef you receive when your callback is called. That's incorrect as a given JSContextRef is only guaranteed to be valid within the callback. All your functions should be from the same initial JSGlobalContextRef you created when initialising your environment, and you should just be using that GlobalContext rather than any per instance context. You should also be protecting the function with JSValueProtect. Hopefully this helps. What would be the right way to do this? Thanks, -- Rolando Abarca M. http://rolando.cl Phones: +1 (415) 655-1041 +56 (2) 581-4591 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to Port Webkit to Andriod?
exter On Friday, December 16, 2011, michaelwang michaelw...@linpus.com wrote: Hi,All: Is there anyone have done the job of porting Webkit to Andriod platform? Thanks. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to Port Webkit to Andriod?
see the code in external/webkit/ On Friday, December 16, 2011, michaelwang michaelw...@linpus.com wrote: Hi,All: Is there anyone have done the job of porting Webkit to Andriod platform? Thanks. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev