[webkit-dev] How to Port Webkit to Andriod?

2011-12-16 Thread michaelwang

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

2011-12-16 Thread Gavin Barraclough
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

2011-12-16 Thread Anne van Kesteren
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?

2011-12-16 Thread Peter Beverloo
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

2011-12-16 Thread Brendan Eich
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

2011-12-16 Thread Rolando Abarca
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

2011-12-16 Thread Oliver Hunt

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?

2011-12-16 Thread Eric Zhu
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?

2011-12-16 Thread Eric Zhu
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