- Tachyon-list - mailman.iro.umontreal.ca

PLDI Registration
by Maxime Chevalier-Boisvert 10 Mai '10

10 Mai '10

The PLDI early registration will be closing in a few hours. Are we going? - Maxime

1 0

V8 Embedder's Guide
by Erick Lavoie 10 Mai '10

10 Mai '10

Really good explanations of the concepts behind the implementation of V8: http://code.google.com/apis/v8/embed.html

1 0

Doxygen reference for v8
by Erick Lavoie 06 Mai '10

06 Mai '10

http://izs.me/v8-docs/ For an example usage of the Arguments class to add our own C++ functions, see: http://izs.me/v8-docs/shell.cc-example.html All the important class references are one click away, which is pretty neat! Erick

1 0

Parser completeness and speed?
by Erick Lavoie 06 Mai '10

06 Mai '10

Marc, how does your parser fare on the echo3 demo javascript file? For the record, the OMeta parser in javascript would take roughly 3-4 seconds to parse it and translate it again to javascript. Taken from: http://demo.nextapp.com/echo3csjs/ I've included the "AppCompressed.js" file in this email. Erick

1 0

V8 improving
by Marc Feeley 05 Mai '10

05 Mai '10

The competition is improving: http://chrome.blogspot.com/2010/05/pedal-to-chrome-metal-our-fastest-beta.h… Marc

1 0

Using V8 Developer Shell (D8)
by Erick Lavoie 05 Mai '10

05 Mai '10

V8 provides a nice developer shell to interactively execute and debug javascript code using their Engine. The build instructions as well as the dependencies can be found here <http://code.google.com/apis/v8/build.html>. To allow calling native C++ functions from javascript directly such as what is done in the standard libraries (see src/v8natives.js), simply set the "allow_natives_syntax" flag from src/flag-definitions.h to "true". This will allow calling functions like %CompileString directly. To see how C++ functions can be exposed to javascript, look at void Shell::Initialize() from src/d8.cc. When an error occurs, the d8 shell automatically enters debug mode. The listing of available commands can be found at "function DebugRequest" of src/d8.js. Erick

1 1

Ecmascript conformance tests
by Marc Feeley 04 Mai '10

04 Mai '10

Here's an interesting test suite for Ecmascript that we should look into: http://es5conform.codeplex.com/ Marc

1 0

Re: [Tachyon-list] Using Git with WebKit
by Erick Lavoie 03 Mai '10

03 Mai '10

I chose to set up the git repository at Gitorious mainly for the following reasons: 1. No administration of users/git server/etc on OS X, simply high-level management of users on Gitorious 2. Public repository so anybody can clone our project on Gitorious and eventually provide patches 3. Free and no publicity 4. No security hassle The repository will be essentially a mirror of the official WebKit git repo with our own branches for our work. We will be able to share our changes through it. It won't be automatically kept in sync with the WebKit repo because we don't need to. However, it should be fairly easy from time to time to reapply our modifications on top of the latest version of WebKit by manually fetching the latest commits from WebKit and doing a "git-rebase" on top of the latest revision. We will be able to tag the project at different points to still have access to earlier work. Example Scenario: 1. We instrument WebKit for logging traces in a branch forked from the current up-to-date Webkit Repo 2. Let's say we publish results on traces done. We git-tag the current HEAD of our branch with a name like "Conference XYZ". 3. Further work is done on the main WebKit project. 4. We decide to regenerate traces for a newer WebKit for another paper. We obtain the latest commits from Webkit with git-fetch, then git-rebase all the work we have done on top of the newer version, resolving conflicts along the way. We git-tag the current HEAD of our branch with "Conference ABC". 5. Etc. until WebKit considers our work to be oh-so wonderful that they decide to integrate it. We then submit a single patch with all our changes (on top of the latest WebKit revision) using git-diff. The really interesting thing is that git-rebase, git-fetch, git-tag and git-diff automate most of the work we need to do to follow the WebKit project without continually having to resolve conflicts because they are working on similar parts of the code base, as would be the case with svn. The same steps would equally apply to a rewriting of the javascript engine. The project can be found at: http://gitorious.org/tachyon I will push the 1.7 GB of commits from WebKit later today, when I am on the campus network. Erick Le 10-05-02 10:23 , chevalma(a)iro.umontreal.ca a écrit : > This should be easier to work with than the svn bridge, but will you still > be setting us up a repository based on this? We need somewhere to keep our > own code so we can easily share it (and have it backed up). > > - Maxime > > >> Here is a link to the wiki page describing how to use git with webkit: >> >> http://trac.webkit.org/wiki/UsingGitWithWebKit >> >> There is really nothing fancy to do, since we are not committers on >> webkit. Simply: >> >> git clonegit://git.webkit.org/WebKit.git WebKit >> >> >> Each revision in svn corresponds to a different commit in git. In bonus >> the whole repository in git is 1.7 GB compared to 2.0 GB for the latest >> revision checkout of the svn repo! >> >> Erick >> _______________________________________________ >> Tachyon-list mailing list >> Tachyon-list(a)iro.umontreal.ca >> https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list >> >> > >

3 3

Re: [Tachyon-list] Using Git with WebKit
by Erick Lavoie 03 Mai '10

03 Mai '10

I'll look at how to do this on dynamo2 today. The basic idea is simply to have a repository that is accessible to everyone contributing to the project on which we will synchronize our changes. We will be able to commit to that repository and keep it in sync with the latest revision. Le 10-05-02 10:23 , chevalma(a)iro.umontreal.ca a écrit : > This should be easier to work with than the svn bridge, but will you still > be setting us up a repository based on this? We need somewhere to keep our > own code so we can easily share it (and have it backed up). > > - Maxime > > >> Here is a link to the wiki page describing how to use git with webkit: >> >> http://trac.webkit.org/wiki/UsingGitWithWebKit >> >> There is really nothing fancy to do, since we are not committers on >> webkit. Simply: >> >> git clonegit://git.webkit.org/WebKit.git WebKit >> >> >> Each revision in svn corresponds to a different commit in git. In bonus >> the whole repository in git is 1.7 GB compared to 2.0 GB for the latest >> revision checkout of the svn repo! >> >> Erick >> _______________________________________________ >> Tachyon-list mailing list >> Tachyon-list(a)iro.umontreal.ca >> https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list >> >> > >

1 0

Re: [Tachyon-list] Inspiration: Self Klein's Metacircular Virtual Machine Kit
by Erick Lavoie 02 Mai '10

02 Mai '10

Oups, did a private reply to mark. Mark is there a way to set the "reply-to" field of the mailing list to the mailing list itself? Thanks -------- Message original -------- Sujet: Re: [Tachyon-list] Inspiration: Self Klein's Metacircular Virtual Machine Kit Date : Thu, 29 Apr 2010 23:48:05 -0400 De : Erick Lavoie <erick.lavoie(a)gmail.com> Pour : Marc Feeley <feeley(a)iro.umontreal.ca> There is still a couple of things that worries me. Given that they were mostly three working on Klein and that they never achieve a level of performance similar to their C++ implementation, I feel that the problem of boostrapping a system efficiently (in terms of development time) to achieve both simplicity and performance is not completely understood and therefore risky. What I get from the paper, is that tools for inspecting and debugging the VM are of paramount importance but can be really tricky to get right. That's something we should take into account in planning the work ahead. At this point, I find it really hard to assess the amount of work in front of us. I can't completely nail it yet, but there is something that makes meta-circular implementation of live systems a lot harder to think about than plain layered systems with different "languages" for each of the layers. To be successful, I think we will have to learn as much as we can from other projects. Talking about tools, I think the Maxine VM inspector is really interesting. http://wikis.sun.com/display/MaxineVM/Inspector Still interesting to note that Sun lost interest in the Klein project but still kept the idea of meta-cicularity... Erick Le 29/04/10 19:30 , Marc Feeley a écrit : > Nice find Erick. Well what can I say... the reasons they mention for Klein being metacircular are pretty much what I was saying for Tachyon. > > Marc > > > On 2010-04-29, at 5:16 PM, Erick Lavoie wrote: > > >> "In constructing Klein, we have attempted to adhere to various principles, including object-orientation, metacircularity, heavy code reuse, reactiveness, and mirror-based reflection. We expect these principles to yield many benefits, including: >> • A simpler, more malleable VM (because it is written almost entirely in a high-level language). >> • Less replicated code (because the VM and the applications running on top of it are written in the same language and can share code, as can the VM and its development environment). >> • Better performance (because the VM will be able to do optimizations across the entire code base, including the VM code itself - imagine being able to inline the hotspots of the VM right up into an application). >> • Faster turnaround when making changes to the VM (because the VM will no longer be tied to C++ and its compilation system)." >> http://kleinvm.sourceforge.net/ >> >> However, the current version is not complete yet as a lot of things are yet to be done. >> >> Erick >> _______________________________________________ >> Tachyon-list mailing list >> Tachyon-list(a)iro.umontreal.ca >> https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list >> > >

2 2