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
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
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
>>
>>
>
>
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
>>
>>
>
>
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
>>
>
>
According to this blog post:
http://metajack.wordpress.com/2008/07/01/the-state-of-javascript-documentat…
Natural Docs would be the best choice for that but since the article is
almost 2 years old, we might give a second try to those before settling
on a particular tool:
JsDoc
HeaderDoc
Interestingly, JsDoc is written in Javascript so we might as well go for
Javascript all the way ;-)
To be a little more objective on the choice of tool, we might want to
check the following issues:
1. Automatic doc from source code (What style of programming is
supported?)
2. What explicit comment tags are supported?
3. What is the quality of the documentation output?
I suggest looking at this next week.
Erick
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