Following that quite emotional discussion of JavaScript on  digitalmars.D I decided I'll take a risk to announce my work on porting DMDScript, that is ECMA-262 script engine.

In the end it turned out to more like a quite successful fork given the amount of changes. The goal was not only to just make it compile with D2 and work (that would be of limited value) but also slowly convert it to newer D2 idioms/libraries/etc, I essence simplifying user side code  for writing extensions. For instance, I even managed to use immutable strings throughout, at the expense of a couple of casts at critical spots.

I'm considering current state of release as stable beta, since I had to disable some of original performance tricks in order to debug some issues properly. They eventually would be re-enabled of course.
Latest tar with source code + samples can be found here: http://dsource.org/projects/dmdscript-2/browser/downloads

Things of possible interest:
-- Builds & fully works with latest dmd , tested on Windows and Linux
-- Greatly increased standard conformance
-- Still runs quite fast
-- Some huge bugs fixed, that were present in DMDScript 1.16 . (for instance 'in' _expression_ not implemented)
-- Includes (highly experimental)  module for extending script engine with native D functions/types in a couple of LOCs
-- Contains few basic examples to get started

P.S. I'm still reluctant to give it a version number, should it be DMDScript2 0.1 ?

-- 
Dmitry Olshansky

Dmitry Olshansky wrote:
> The goal was not only to just make it compile with D2
> and work (that would be of limited value)

I tried this too about a year ago...: http://arsdnet.net/dcode/dmdscript_d2.zip

...but overall, from a brief glance, your port is *much* better than mine. I used a lot more casts and idups, and thus introduced new bugs and hurt the performance. I got it working, but not working well.

Nice work!

But there still might be a few ideas or bits of code
we can share from the easy expansion stuff.

I called mine "pretty.d" and "test.d" in that zip. One of the things I tried to do was make a ScriptObject class in D, which you could expand and call with opIndex and opDispatch.

I was only partially successful, but maybe we can better with a newer compiler.

Here's a copy/paste of part of my test.d showing the idea I was chasing:

=======
        auto g = se.globalObject; // se is a ScriptEngine

        /* You can work with the script environment as an associative
array... */
        g["hello"] = "Hello, world!";
        g["lol"] = new ScriptObject; // ScriptObject is just a generic object.
You can specialize it in the constructor.
        //g["lol"]["fun"] = &fun; // Can even assign native top-level functions
this way!  FIXME: broken due to ICE

        /* Or, you can do it with opDispatch, though this is limited to just
assigning existing ScriptObjects... */
        auto so2 = new ScriptObject;
        se.globalObject.lol.hate = so2;

        /* You can also add functions to specific ScriptObjects with the
addFunction template */
        se.addFunction!(raise, "fun")(so2);

=======

And all that stuff would of course be available to the script via the global object.

In pretty.d, you can see some attempt to unify D and dmdscript exceptions too, but I don't recall how well that went, but I'm pretty sure it worked at least one way.


One little thing we both did is one line expansion. One thing I'd add to your code is making the name of the script function default to being the same name as the D function. It's a minor addition, but I think it looks nice.


Generally though, your port is excellent, thanks for doing it!

On 16.12.2010 19:43, Adam Ruppe wrote:
> Dmitry Olshansky wrote:
>> The goal was not only to just make it compile with D2
>> and work (that would be of limited value)
> I tried this too about a year ago...:
> http://arsdnet.net/dcode/dmdscript_d2.zip
Yes, that's the only previous effort I've found, and  it was after my port almost started working.

> ...but overall, from a brief glance, your port is *much* better
> than mine. I used a lot more casts and idups, and thus introduced
> new bugs and hurt the performance. I got it working, but not working
> well.
>
> Nice work!
Thanks, yet I plan a lot of refactoring, one I dream of is eventually replacing struct Value with Algebraic from Phobos. And yes, that exception propagation mechanism, I almost switched to throwing instead of returning exceptions from functions.
> But there still might be a few ideas or bits of code
> we can share from the easy expansion stuff.
>
> I called mine "pretty.d" and "test.d" in that zip. One of the
> things I tried to do was make a ScriptObject class in D, which
> you could expand and call with opIndex and opDispatch.
>
> I was only partially successful, but maybe we can better with
> a newer compiler.
>
> Here's a copy/paste of part of my test.d showing the idea I was chasing:
>
> =======
>          auto g = se.globalObject; // se is a ScriptEngine
>
>          /* You can work with the script environment as an associative
> array... */
>          g["hello"] = "Hello, world!";
>          g["lol"] = new ScriptObject; // ScriptObject is just a generic object.
> You can specialize it in the constructor.
>          //g["lol"]["fun"] =&fun; // Can even assign native top-level functions
> this way!  FIXME: broken due to ICE
>
>          /* Or, you can do it with opDispatch, though this is limited to just
> assigning existing ScriptObjects... */
>          auto so2 = new ScriptObject;
>          se.globalObject.lol.hate = so2;
>
>          /* You can also add functions to specific ScriptObjects with the
> addFunction template */
>          se.addFunction!(raise, "fun")(so2);
>
> =======
Yes, that's awesome. I guess I should get a closer look at that pretty.d!
> And all that stuff would of course be available to the script via
> the global object.
>
> In pretty.d, you can see some attempt to unify D and dmdscript
> exceptions too, but I don't recall how well that went, but I'm
> pretty sure it worked at least one way.
>
>
> One little thing we both did is one line expansion. One thing I'd
> add to your code is making the name of the script function default
> to being the same name as the D function. It's a minor addition,
> but I think it looks nice.

Yes, it's planned, and indeed improves user experience. I just was stuck with the issue of extending of variadic functions/templated functions consider, for example, std.stdio.writeln.  That must have distracted me from this issue.

>
> Generally though, your port is excellent, thanks for doing it!
-- 

Dmitry Olshansky

On 17/12/2010 2:14 AM, Dmitry Olshansky wrote:
> I decided I'll take a risk to announce my work on porting DMDScript,
> that is ECMA-262 script engine.

Nice!

As few seem to read the DMDScript newsgroup, here's my last post as it seems relevant to this topic.

===================================

There's a JavaScript arms race going on (as I'm sure many of you are aware). The competing JS engines of the major browsers are leap-frogging each other in performance every few months it seems.

http://www.conceivablytech.com/4472/products/chrome-10-posts-huge-performance-jump/

It would be so cool (and a huge showcase for the D Programming Language) if DMDScript was in that performance race and beating the big guns.

Possible?

"Brian Hay" <bhay@construct3d.com> wrote in message news:ieecsp$1ej5$1@digitalmars.com...
> On 17/12/2010 2:14 AM, Dmitry Olshansky wrote:
>> I decided I'll take a risk to announce my work on porting DMDScript, that is ECMA-262 script engine.
>
> Nice!
>
> As few seem to read the DMDScript newsgroup, here's my last post as it seems relevant to this topic.
>
> ===================================
>
> There's a JavaScript arms race going on (as I'm sure many of you are aware). The competing JS engines of the major browsers are leap-frogging each other in performance every few months it seems.
>
> http://www.conceivablytech.com/4472/products/chrome-10-posts-huge-performance-jump/
>
> It would be so cool (and a huge showcase for the D Programming Language) if DMDScript was in that performance race and beating the big guns.
>
> Possible?

First step, of course, would be to run those benchmarks on DMDScript. Though everyone probably knows I'm a rather vocal anti-fan of JS, even I'd be very interested to see how DMDScript currently stacks up to the rest. I'd laugh my ass off if after all this time of not a whole lot of work on DMDScript besides the port to D2 (unless I'm mistaken), if it still managed to be on par with or beat all those others that have been pounding their chests and bashing each other over the head.

On 17/12/2010 12:00 PM, Nick Sabalausky wrote:
> "Brian Hay"<bhay@construct3d.com>  wrote in message
> news:ieecsp$1ej5$1@digitalmars.com...
>> On 17/12/2010 2:14 AM, Dmitry Olshansky wrote:
>>> I decided I'll take a risk to announce my work on porting DMDScript,
>>> that is ECMA-262 script engine.
>>
>> Nice!
>>
>> As few seem to read the DMDScript newsgroup, here's my last post as it
>> seems relevant to this topic.
>>
>> ===================================
>>
>> There's a JavaScript arms race going on (as I'm sure many of you are
>> aware). The competing JS engines of the major browsers are leap-frogging
>> each other in performance every few months it seems.
>>
>> http://www.conceivablytech.com/4472/products/chrome-10-posts-huge-performance-jump/
>>
>> It would be so cool (and a huge showcase for the D Programming Language)
>> if DMDScript was in that performance race and beating the big guns.
>>
>> Possible?
>
> First step, of course, would be to run those benchmarks on DMDScript. Though
> everyone probably knows I'm a rather vocal anti-fan of JS, even I'd be very
> interested to see how DMDScript currently stacks up to the rest. I'd laugh
> my ass off if after all this time of not a whole lot of work on DMDScript
> besides the port to D2 (unless I'm mistaken), if it still managed to be on
> par with or beat all those others that have been pounding their chests and
> bashing each other over the head.

Like it or not, javascript is THE programming language of the client-side web (rich web apps, Google maps, docs, Flash ActionScript, X3D etc etc), so to be in that arms race would be a huge boon to the D Programming Language IMHO.

Agreed, DMDScript is unlikely to be competitive with compiled JS engines like V8 and spidermonkey now, but we won't know until it's benchmarked and possibly some of the performance enhancements that went into those engines can be adapted for dmdscript (although I don't know the first thing about interpreter or compiler writing, so I'm just speculating).

Brian Hay wrote:
> It would be so cool (and a huge showcase for the D Programming Language)
>if DMDScript was in that performance race and beating the big guns.

It kicked the living crap out of the competition up to not too long ago! It beat out Firefox 2 by well about 50x when I checked it, and IE7 by IIRC 20x.

What's really impressive is dmdscript was several years old at
that point - as in it only got a few minor bugfixes in those years,
and the main design was even older. It took the big guys some
five years or more to catch up to lone Walter.


It was about 1/2 the speed of Firefox 3 when I checked it last. That
gap has probably widened quite a bit in the last year. A quick check using the
sieve.ds shows Firefox 3 is currently about 16x faster than dmdscript.

The gap is definitely opening up in the other direction now, but still, it took them long enough!



Could dmdscript take the lead back? Probably, though I suspect it'd
be quite a lot of work. But I don't really know. dmdscript is a kind of compiler,
so maybe not. I'm just not qualified.

"Brian Hay" <bhay@construct3d.com> wrote in message news:ieehug$1q5s$1@digitalmars.com...
> On 17/12/2010 12:00 PM, Nick Sabalausky wrote:
>> "Brian Hay"<bhay@construct3d.com>  wrote in message news:ieecsp$1ej5$1@digitalmars.com...
>>> On 17/12/2010 2:14 AM, Dmitry Olshansky wrote:
>>>> I decided I'll take a risk to announce my work on porting DMDScript, that is ECMA-262 script engine.
>>>
>>> Nice!
>>>
>>> As few seem to read the DMDScript newsgroup, here's my last post as it seems relevant to this topic.
>>>
>>> ===================================
>>>
>>> There's a JavaScript arms race going on (as I'm sure many of you are aware). The competing JS engines of the major browsers are leap-frogging each other in performance every few months it seems.
>>>
>>> http://www.conceivablytech.com/4472/products/chrome-10-posts-huge-performance-jump/
>>>
>>> It would be so cool (and a huge showcase for the D Programming Language) if DMDScript was in that performance race and beating the big guns.
>>>
>>> Possible?
>>
>> First step, of course, would be to run those benchmarks on DMDScript.
>> Though
>> everyone probably knows I'm a rather vocal anti-fan of JS, even I'd be
>> very
>> interested to see how DMDScript currently stacks up to the rest. I'd
>> laugh
>> my ass off if after all this time of not a whole lot of work on DMDScript
>> besides the port to D2 (unless I'm mistaken), if it still managed to be
>> on
>> par with or beat all those others that have been pounding their chests
>> and
>> bashing each other over the head.
>
> Like it or not, javascript is THE programming language of the client-side web (rich web apps, Google maps, docs, Flash ActionScript, X3D etc etc), so to be in that arms race would be a huge boon to the D Programming Language IMHO.
>

Agreed. I can at least see the writing on the wall even if I don't like what it says ;)

Although in the case of Flash, I've been using Haxe which compiles directly to Flash bytecode. I think there may be some intermediate ActionScript needed for a few things if you're doing strictly Flash9+, but the combination of Haxe and some custom tools/libs I've made have been enough to paper over enough of the usual drawbacks of maintaining Flash8/Wii compatibility.

> Agreed, DMDScript is unlikely to be competitive with compiled JS engines like V8 and spidermonkey now, but we won't know until it's benchmarked and possibly some of the performance enhancements that went into those engines can be adapted for dmdscript (although I don't know the first thing about interpreter or compiler writing, so I'm just speculating).
>

Yea. It would also be really interesting to see how much work would really be needed to bring it back up to par with the latest competition. Being able to get up the that really easily would be a nice bragging right for D. :)

On 17.12.2010 4:01, Brian Hay wrote:
> On 17/12/2010 2:14 AM, Dmitry Olshansky wrote:
>> I decided I'll take a risk to announce my work on porting DMDScript,
>> that is ECMA-262 script engine.
>
> Nice!
>
> As few seem to read the DMDScript newsgroup, here's my last post as it seems relevant to this topic.
>
> ===================================
>
> There's a JavaScript arms race going on (as I'm sure many of you are aware). The competing JS engines of the major browsers are leap-frogging each other in performance every few months it seems.
>
> http://www.conceivablytech.com/4472/products/chrome-10-posts-huge-performance-jump/ 
>
>
> It would be so cool (and a huge showcase for the D Programming Language) if DMDScript was in that performance race and beating the big guns.
>
> Possible?

Indeed, that would be desirable.
I dreamed to get back performance tuning  from the day it started working, but It's better to fix some bugs and clean up the source first.

-- 
Dmitry Olshansky

On 17.12.2010 5:34, Adam D. Ruppe wrote:
> Brian Hay wrote:
>> It would be so cool (and a huge showcase for the D Programming Language)
>> if DMDScript was in that performance race and beating the big guns.
> It kicked the living crap out of the competition up to not too long ago! It beat
> out Firefox 2 by well about 50x when I checked it, and IE7 by IIRC 20x.
>
> What's really impressive is dmdscript was several years old at
> that point - as in it only got a few minor bugfixes in those years,
> and the main design was even older. It took the big guys some
> five years or more to catch up to lone Walter.
>
>
> It was about 1/2 the speed of Firefox 3 when I checked it last. That
> gap has probably widened quite a bit in the last year. A quick check using the
> sieve.ds shows Firefox 3 is currently about 16x faster than dmdscript.
Yes, it's about 20x times slower on my machine..
It must be the properties of RandAA, namely relatively slow lookup time. Profiler shows 90% time is spent in hashmap lookup function. I had to replace built-in AA at certain point because of spurious segfaults that fixed, but must have degraded speed.

> The gap is definitely opening up in the other direction now, but
> still, it took them long enough!
>
>
>
> Could dmdscript take the lead back? Probably, though I suspect it'd
> be quite a lot of work. But I don't really know. dmdscript is a kind of compiler,
> so maybe not. I'm just not qualified.


-- 
Dmitry Olshansky