> > Could you post a complete patch of your multi-vm changes to a WebKit > bug? I final chromium's diff viewer very difficult to use. >
Multi-vm changes broken into 4 patches: https://bugs.webkit.org/show_bug.cgi?id=73897 https://bugs.webkit.org/show_bug.cgi?id=73899 https://bugs.webkit.org/show_bug.cgi?id=73903 https://bugs.webkit.org/show_bug.cgi?id=73906 > > Regardless of whether this is good for the web or not, some of your > multi-vm changes may be nice to have in WebCore. > > -eric > > On Mon, Dec 5, 2011 at 11:48 AM, Geoffrey Garen <gga...@apple.com> wrote: > > Looking at http://www.webkit.org/projects/goals.html, I see: > > > > Goals > > > > …. > > Hackability > > To make rapid progress possible, we try to keep the code relatively easy > to > > understand…. > > > > Non-Goals > > > > …. > > WebKit is an engineering project not a science project.For new features > to > > be adopted into WebKit, we strongly prefer for the technology or at least > > the use case for it to be proven. > > > > It sounds like you're proposing a change to the goals of the WebKit > project > > -- namely, to use a branch in the WebKit project as a substrate for > > experiments with new technologies, including new technologies that might > > negatively impact hackability. Is that right? > > > > Geoff > > > > On Dec 5, 2011, at 9:26 AM, Vijay Menon wrote: > > > > Hi all, > > > > Many languages compile to JavaScript today to run on the web. As > > alternative, we’ve been experimenting with enabling different language > > runtimes in WebKit to run in web pages alongside JavaScript. > > > > This could be used to support languages like Python, Java, Ruby, Lua, or > - > > what inspired us - Dart (www.dartlang.org). > > > > Some reasons to consider additional runtimes include: > > > > - Speed. Many languages are faster than JavaScript when run natively > and/or > > do not compile to JavaScript efficiently. > > - Developer choice. Another runtime provides developers with more choice > > without requiring them to use a toolchain. > > - Development experience. Languages supported directly in the browser > can > > have a significantly better debugging and profiling experience than they > can > > with compiled code. > > > > We have a quite early patch of this work available here: > > > > - multi-vm changes: http://codereview.chromium.org/8806015/ > > - dart bindings: http://codereview.chromium.org/8802010/ > > > > We’re planning to create a multi-vm branch on webkit.org to experiment > with > > this idea. Our goal with this branch is to (a) demonstrate the above > points > > and (b) show that we can do this without degrading JavaScript > performance or > > the WebKit development experience. If successful, we’d like to submit > these > > changes to WebKit trunk. We welcome your feedback. > > > > Regards, > > > > Anton Muhin > > Pavel Podivilov > > Vijay Menon > > > > _______________________________________________ > > 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 > > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
