www.digitalmars.com         C & C++   DMDScript  

DMDScript - DMDScript now under Boost license

reply Walter Bright <newshound1 digitalmars.com> writes:
http://www.digitalmars.com/dscript/index.html
Mar 22 2010
next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Thank you. 

Under svn there is both the gpl and boost license files, and no indication 
which is the right one. Could you remove gpl.txt to avoid confusion?
Mar 22 2010
prev sibling next sibling parent Bernard Helyer <b.helyer gmail.com> writes:
On 22/03/10 20:30, Walter Bright wrote:

 http://www.digitalmars.com/dscript/index.html


Oh wow, awesome!
Mar 22 2010
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Walter Bright wrote:

 http://www.digitalmars.com/dscript/index.html


Now on reddit! 
http://www.reddit.com/r/programming/comments/biufj/javascript_engine_released_under_boost_license/
Mar 26 2010
prev sibling next sibling parent reply strtr <strtr spam.com> writes:
Walter Bright Wrote:


 http://www.digitalmars.com/dscript/index.html


Would it be possible to have some sort of scripting as part of D?
Mar 28 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
strtr wrote:

 Walter Bright Wrote:
 

 http://www.digitalmars.com/dscript/index.html


 
 Would it be possible to have some sort of scripting as part of D?


What did you have in mind?
Mar 28 2010
next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
I think it would be pretty great if you could add functions, etc., to
the scripting language with a simple one liner:

mixin makeAccessibleFromScript!(scriptEngine, foo);

Or something similar. The template there could mix in a wrapper
function for whatever foo() happens to be, and register it with the
scripting engine all in one call.

Then, to call a function defined in script, you should be able to just
do callScriptFunction("name", args...);, but this is optional; I say
getting D functions accessible from the script with ease is more
important.


Anyway, you take that and the dmdscript and package them together as
an D extender library. To use it, you just import the script module,
mixin the template to extend it, and boom, done.


Perhaps down the line, a magic function could even look for
 scriptable attributes* and add them automatically. But no need
immediately.

* I'll say again, I'd love to have user defined attributes accessible
from __traits for just this kind of thing.

On 3/29/10, Walter Bright <newshound1 digitalmars.com> wrote:

 strtr wrote:

 Walter Bright Wrote:


 http://www.digitalmars.com/dscript/index.html


 Would it be possible to have some sort of scripting as part of D?


 What did you have in mind?
Mar 29 2010
parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 29/03/10 18:41, Adam Ruppe wrote:

 I think it would be pretty great if you could add functions, etc., to
 the scripting language with a simple one liner:

 mixin makeAccessibleFromScript!(scriptEngine, foo);


You can do with with MiniD, LuaD, PyD, Monster, and possibly others to 
allow you to script in minid, lua, python an monster (I think there's 
something for ruby out there too). I haven't played with dmdscript, but 
I'd guess there's a simple way to expose D functions to it.


 Or something similar. The template there could mix in a wrapper
 function for whatever foo() happens to be, and register it with the
 scripting engine all in one call.

 Then, to call a function defined in script, you should be able to just
 do callScriptFunction("name", args...);, but this is optional; I say
 getting D functions accessible from the script with ease is more
 important.


All of the above languages/wrappers have some way of doing this, with 
various degrees of simplicity/ease.


 Anyway, you take that and the dmdscript and package them together as
 an D extender library. To use it, you just import the script module,
 mixin the template to extend it, and boom, done.


I don't think this is a good idea, unless a decent policy for what is 
included can be figured out. That said, I believe there's an old version 
of dmd packaged with projects that work with it.


 Perhaps down the line, a magic function could even look for
  scriptable attributes* and add them automatically. But no need
 immediately.

 * I'll say again, I'd love to have user defined attributes accessible
 from __traits for just this kind of thing.


I'm pretty sure user defined attributes aren't in for D2, it looks like 
it'll be D3 or later if/when we get them.
Mar 29 2010
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Mon, Mar 29, 2010 at 06:49:35PM +0100, Robert Clipsham wrote:

 I haven't played with dmdscript, but 
 I'd guess there's a simple way to expose D functions to it.


It isn't terribly complex, but it is a bit wordy. The docs are
here: http://www.digitalmars.com/dscript/extending.html

You have to make your function in a certain convention, then
register it using a struct and a function.

The function convention gives you the most access to the script
environment, but it is a pain to write all your functions that way.


 I'm pretty sure user defined attributes aren't in for D2, it looks like 
 it'll be D3 or later if/when we get them.


Indeed. But everyone on this group needs /some/ wish feature
to bring up at every opportunity, right? :-P

-- 
Adam D. Ruppe
http://arsdnet.net
Mar 29 2010
parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 29/03/10 19:30, Adam D. Ruppe wrote:

 On Mon, Mar 29, 2010 at 06:49:35PM +0100, Robert Clipsham wrote:

 I haven't played with dmdscript, but
 I'd guess there's a simple way to expose D functions to it.


 It isn't terribly complex, but it is a bit wordy. The docs are
 here: http://www.digitalmars.com/dscript/extending.html

 You have to make your function in a certain convention, then
 register it using a struct and a function.

 The function convention gives you the most access to the script
 environment, but it is a pain to write all your functions that way.


You could always write a nice wrapper function/template which 
automatically does all that guff for you :) If you do, I'm sure Walter 
wouldn't mind adding it into dmdscript providing you license it 
appropriately :)


 I'm pretty sure user defined attributes aren't in for D2, it looks like
 it'll be D3 or later if/when we get them.


 Indeed. But everyone on this group needs /some/ wish feature
 to bring up at every opportunity, right? :-P


Agreed :) Guess I need to go and sit in a corner until I think of a 
feature, then I can come back to the group a true D user :P
Mar 29 2010
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Mon, Mar 29, 2010 at 07:45:39PM +0100, Robert Clipsham wrote:

 You could always write a nice wrapper function/template which 
 automatically does all that guff for you :) If you do, I'm sure Walter 
 wouldn't mind adding it into dmdscript providing you license it 
 appropriately :)


Yup, that's what I'm thinking about in these messages. The one
problem point might be dmdscript is D1 IIRC.

I'll have to grab the updated source and see what I can make of it.


 Agreed :) Guess I need to go and sit in a corner until I think of a 
 feature, then I can come back to the group a true D user :P


Make sure it is something that's been done to death and only
marginally useful anyway for big bonus points!

-- 
Adam D. Ruppe
http://arsdnet.net
Mar 29 2010
parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 29/03/10 20:07, Adam D. Ruppe wrote:

 On Mon, Mar 29, 2010 at 07:45:39PM +0100, Robert Clipsham wrote:

 You could always write a nice wrapper function/template which
 automatically does all that guff for you :) If you do, I'm sure Walter
 wouldn't mind adding it into dmdscript providing you license it
 appropriately :)


 Yup, that's what I'm thinking about in these messages. The one
 problem point might be dmdscript is D1 IIRC.

 I'll have to grab the updated source and see what I can make of it.


I seem to recall it is, and a fairly old D1 at that... You could always 
update it and send a patch Walter's way, see if he accepts it :)


 Agreed :) Guess I need to go and sit in a corner until I think of a
 feature, then I can come back to the group a true D user :P


 Make sure it is something that's been done to death and only
 marginally useful anyway for big bonus points!


Hmm, I'll definitely be wanting the bonus points... This is gonna need 
some thinking!
Mar 29 2010
next sibling parent Adam Ruppe <destructionator gmail.com> writes:
On 3/29/10, Robert Clipsham <robert octarineparrot.com> wrote:

 I seem to recall it is, and a fairly old D1 at that... You could always
 update it and send a patch Walter's way, see if he accepts it :)


Walter seems to have fixed it up the the new D1; it compiled there.

And I just spent the day making a port to D2. There's a few WTFs in
there though, which I hacked around.

Here it is:
http://arsdnet.net/dcode/dmdscript_d2.zip

First, once each in dobject.d and script.d, I casted away a const.
grep for FIXME.

Second, and this is the big one: the assocative array implementation
in there seems to have broken entirely with the switch to D2. Look for
"BIG HACK" in property.d - I had to do this two times:

	assert(key !is null);
	p = *key in table;

	// BIG HACK! in seems broken!
        if(p is null)
	foreach(k,ref v; table) {
		if(k.toString() == key.toString()) {
			p = &v; // WTF
			break;
		}
	}

Previously, it used a custom AA implementation, similar to the one in
Phobos, but not quite the same. It cached the hashes for boosted
speed.

In phobos2, the AA implementation is completely different. This first
manifested itself as linker errors on foreach statements (fix it by
compiling as:

dmd -oftest *.d

instead of using the makefile). Then, I noticed obvious things were failing.

After spending a few hours on it, I decided to just give up and use
the above hack. I still don't understand why it is happening that way.
(I thought const correctness would be the hard thing, but aside from
the two casts, it was fairly easy. The stupid AA has been the real
problem!)



But, anyway, it now works on some simple scripts, and the asserts in
there all work, so I think it is working correctly.

Now, with it compiling as D2, the next step will be making the wrapper
template I mentioned yesterday. I don't have time to do it today
though.

On the bright side, I know the code a bit better now than I ever did
before, so maybe I can make this template better than I thought! We'll
see.
Mar 30 2010
prev sibling next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
All right, now I'm actually done for the day.

Updated the zip at the link:
http://arsdnet.net/dcode/dmdscript_d2.zip

To add a pretty interface (pretty.d). It is incomplete, but works to
play with. test.d is an example of how to use it.

	auto se = new ScriptEngine;
	se.addFunction!(fun, "fun");  // adding D functions is just giving
the names. the second arg is required since stringof the alias kept
treating it as a property.....
	se.addFunction!(fun2, "fun2");
	se.compile("function test(a) { println(a); }");
	se.call("test", 40); // and it is almost as easy to call script functions!

When I go back to finish it, I'm thinking I'll add more integration
with std.variant and opDispatch, so the D and javascript code
basically work the same way.


To do this, I did have to do one change to dmdscript itself: edited
dnative.d to add an overload constructor so it can take a delegate as
well as a function. That let my template just use a nested function to
keep it easy. It might not work properly if the script tries to
redefine the function though.

Still, good enough for now. I've been at this for 9 hours! Blown my
whole day off.

On 3/30/10, Adam Ruppe <destructionator gmail.com> wrote:

 On 3/29/10, Robert Clipsham <robert octarineparrot.com> wrote:

 I seem to recall it is, and a fairly old D1 at that... You could always
 update it and send a patch Walter's way, see if he accepts it :)


 Walter seems to have fixed it up the the new D1; it compiled there.

 And I just spent the day making a port to D2. There's a few WTFs in
 there though, which I hacked around.

 Here it is:
 http://arsdnet.net/dcode/dmdscript_d2.zip

 First, once each in dobject.d and script.d, I casted away a const.
 grep for FIXME.

 Second, and this is the big one: the assocative array implementation
 in there seems to have broken entirely with the switch to D2. Look for
 "BIG HACK" in property.d - I had to do this two times:

 	assert(key !is null);
 	p = *key in table;

 	// BIG HACK! in seems broken!
         if(p is null)
 	foreach(k,ref v; table) {
 		if(k.toString() == key.toString()) {
 			p = &v; // WTF
 			break;
 		}
 	}

 Previously, it used a custom AA implementation, similar to the one in
 Phobos, but not quite the same. It cached the hashes for boosted
 speed.

 In phobos2, the AA implementation is completely different. This first
 manifested itself as linker errors on foreach statements (fix it by
 compiling as:

 dmd -oftest *.d

 instead of using the makefile). Then, I noticed obvious things were
 failing.

 After spending a few hours on it, I decided to just give up and use
 the above hack. I still don't understand why it is happening that way.
 (I thought const correctness would be the hard thing, but aside from
 the two casts, it was fairly easy. The stupid AA has been the real
 problem!)



 But, anyway, it now works on some simple scripts, and the asserts in
 there all work, so I think it is working correctly.

 Now, with it compiling as D2, the next step will be making the wrapper
 template I mentioned yesterday. I don't have time to do it today
 though.

 On the bright side, I know the code a bit better now than I ever did
 before, so maybe I can make this template better than I thought! We'll
 see.
Mar 30 2010
parent Bernard Helyer <b.helyer gmail.com> writes:
On 31/03/10 13:34, Adam Ruppe wrote:

 All right, now I'm actually done for the day.

 Updated the zip at the link:
 http://arsdnet.net/dcode/dmdscript_d2.zip

 To add a pretty interface (pretty.d). It is incomplete, but works to
 play with. test.d is an example of how to use it.

 	auto se = new ScriptEngine;
 	se.addFunction!(fun, "fun");  // adding D functions is just giving
 the names. the second arg is required since stringof the alias kept
 treating it as a property.....
 	se.addFunction!(fun2, "fun2");
 	se.compile("function test(a) { println(a); }");
 	se.call("test", 40); // and it is almost as easy to call script functions!

 When I go back to finish it, I'm thinking I'll add more integration
 with std.variant and opDispatch, so the D and javascript code
 basically work the same way.


 To do this, I did have to do one change to dmdscript itself: edited
 dnative.d to add an overload constructor so it can take a delegate as
 well as a function. That let my template just use a nested function to
 keep it easy. It might not work properly if the script tries to
 redefine the function though.

 Still, good enough for now. I've been at this for 9 hours! Blown my
 whole day off.

 On 3/30/10, Adam Ruppe<destructionator gmail.com>  wrote:

 On 3/29/10, Robert Clipsham<robert octarineparrot.com>  wrote:

 I seem to recall it is, and a fairly old D1 at that... You could always
 update it and send a patch Walter's way, see if he accepts it :)


 Walter seems to have fixed it up the the new D1; it compiled there.

 And I just spent the day making a port to D2. There's a few WTFs in
 there though, which I hacked around.

 Here it is:
 http://arsdnet.net/dcode/dmdscript_d2.zip

 First, once each in dobject.d and script.d, I casted away a const.
 grep for FIXME.

 Second, and this is the big one: the assocative array implementation
 in there seems to have broken entirely with the switch to D2. Look for
 "BIG HACK" in property.d - I had to do this two times:

 	assert(key !is null);
 	p = *key in table;

 	// BIG HACK! in seems broken!
          if(p is null)
 	foreach(k,ref v; table) {
 		if(k.toString() == key.toString()) {
 			p =&v; // WTF
 			break;
 		}
 	}

 Previously, it used a custom AA implementation, similar to the one in
 Phobos, but not quite the same. It cached the hashes for boosted
 speed.

 In phobos2, the AA implementation is completely different. This first
 manifested itself as linker errors on foreach statements (fix it by
 compiling as:

 dmd -oftest *.d

 instead of using the makefile). Then, I noticed obvious things were
 failing.

 After spending a few hours on it, I decided to just give up and use
 the above hack. I still don't understand why it is happening that way.
 (I thought const correctness would be the hard thing, but aside from
 the two casts, it was fairly easy. The stupid AA has been the real
 problem!)



 But, anyway, it now works on some simple scripts, and the asserts in
 there all work, so I think it is working correctly.

 Now, with it compiling as D2, the next step will be making the wrapper
 template I mentioned yesterday. I don't have time to do it today
 though.

 On the bright side, I know the code a bit better now than I ever did
 before, so maybe I can make this template better than I thought! We'll
 see.






Woo! Awesome. You made my day!

n_n
Apr 02 2010
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Wed, Mar 31, 2010 at 02:34, Adam Ruppe <destructionator gmail.com> wrote:


 All right, now I'm actually done for the day.

 Updated the zip at the link:
 http://arsdnet.net/dcode/dmdscript_d2.zip

        se.addFunction!(fun, "fun");  // adding D functions is just giving
 the names. the second arg is required since stringof the alias kept
 treating it as a property.....


I remember having the same problem... You can try  __traits(identifier,
...):

enum string  scriptName = getPlainName!(__traits(identifier, T));


Philippe
Mar 31 2010
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wed, Mar 31, 2010 at 08:06:11PM +0200, Philippe Sigaud wrote:

 enum string  scriptName = getPlainName!(__traits(identifier, T));


Outstanding! That did it.

I'll update the zip on my website at the end of the day. I now have
wrapping of exceptions from script/native set up too. When I have the time
I'm thinking about making a wrapper with opdispatch and std.variant to
try and erase the lines between script world and native world.

-- 
Adam D. Ruppe
http://arsdnet.net
Mar 31 2010
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Wed, Mar 31, 2010 at 20:22, Adam D. Ruppe <destructionator gmail.com>wrote:


 On Wed, Mar 31, 2010 at 08:06:11PM +0200, Philippe Sigaud wrote:

 enum string  scriptName = getPlainName!(__traits(identifier, T));


 Outstanding! That did it.

 Cool, I wasn't sure it'd work. Now we know what this new trait is for :)
Mar 31 2010
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wed, Mar 31, 2010 at 09:03:10PM +0200, Philippe Sigaud wrote:

 Cool, I wasn't sure it'd work. Now we know what this new trait is for :)


It is slightly different than my old code: the getPlainName helper function
is not required with the __trait. (It truncated the string at the first
paren, since stringof returns the arguments too, whereas identifier does
not).

I think it would be a good idea to get a nice overview doc written up on
template idioms - things like this, how to use the isSomeString, etc,
templates in std.traits to work the constraints, and so on.

Another one in pretty.d I hit was taking a ParameterTypeTuple and using it
to expand the runtime args array. At first, I used a list of static if
T.length == 1, and manually written it out. Today, I changed it to a CTFE
function returning a string to mix on, which sucks less, but still feels
weird.

Having a nice overview document would be good to save time and make this
kind of code prettier. Maybe I'll write one to get started then post it to
the group for additions and improvements. Don't have the time today though.

-- 
Adam D. Ruppe
http://arsdnet.net
Mar 31 2010
prev sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Wed, Mar 31, 2010 at 21:21, Adam D. Ruppe <destructionator gmail.com>wrote:


 On Wed, Mar 31, 2010 at 09:03:10PM +0200, Philippe Sigaud wrote:

 Cool, I wasn't sure it'd work. Now we know what this new trait is for :)


 It is slightly different than my old code: the getPlainName helper function
 is not required with the __trait. (It truncated the string at the first
 paren, since stringof returns the arguments too, whereas identifier does
 not).


I get it.



 I think it would be a good idea to get a nice overview doc written up on
 template idioms - things like this, how to use the isSomeString, etc,
 templates in std.traits to work the constraints, and so on.


Or the way to sneak arrays as template parameters...

Oh yes. I'd be willing to participate, but I'm also waiting to see what
Andrei says in his book.

I recently made a template to bind template parameters, and another to
determine the 'arity' of a template (no param, 1, etc.). The latter was
after discovering that if an alias parameter is a template, the .stringof
gives the entire signature : parameters, constraints, etc.
I'm discovering something new every week and I have the impression my
knowledge of templates is ... kaleidoscopic : lots of colorful parts, no
global vision.




 Another one in pretty.d I hit was taking a ParameterTypeTuple and using it
 to expand the runtime args array. At first, I used a list of static if
 T.length == 1, and manually written it out. Today, I changed it to a CTFE
 function returning a string to mix on, which sucks less, but still feels
 weird.


I still feel wrong when I'm using CTFE. That's too bad, because with the
recent leaps in the CTFE perimeter Don made, CTFE has become a very powerful
tool indeed.


Having a nice overview document would be good to save time and make this

 kind of code prettier. Maybe I'll write one to get started then post it to
 the group for additions and improvements. Don't have the time today though.


A document, or a wiki page. But to start things and get a little attention,
a discussion here is better.


  Philippe
Mar 31 2010
prev sibling parent reply strtr <strtr spam.com> writes:
Walter Bright Wrote:


 strtr wrote:

 Walter Bright Wrote:
 

 http://www.digitalmars.com/dscript/index.html


 
 Would it be possible to have some sort of scripting as part of D?


 
 What did you have in mind?


Scripting in de form of a dialect/subset of D in the std/language.
I don't know enough about scripting to say anything specific/useful.
It's just that if scripting were part of D, I would have used it already where
the possibilities mentioned by Robert Clipsham just look that much bigger a
step.
And being part of the language/community simply instils trust.
Mar 29 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
strtr wrote:

 Scripting in de form of a dialect/subset of D in the std/language.
 I don't know enough about scripting to say anything specific/useful.
 It's just that if scripting were part of D, I would have used it already where
the possibilities mentioned by Robert Clipsham just look that much bigger a
step.
 And being part of the language/community simply instils trust.


I thought about that a lot, but CTFE seems to fill that gap well enough.
Mar 29 2010
next sibling parent strtr <strtr spam.com> writes:
Walter Bright Wrote:


 strtr wrote:

 Scripting in de form of a dialect/subset of D in the std/language.
 I don't know enough about scripting to say anything specific/useful.
 It's just that if scripting were part of D, I would have used it already where
the possibilities mentioned by Robert Clipsham just look that much bigger a
step.
 And being part of the language/community simply instils trust.


 
 I thought about that a lot, but CTFE seems to fill that gap well enough.


I don't think CTFE fills the gap of RTFE.
I need the scripting for my users and they can't compile the program :)
Maybe you are talking about another gap.
Now, choosing a scripting language feels like a stab in the dark and I can't
put it off forever :)
Mar 29 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

 I thought about that a lot, but CTFE seems to fill that gap well enough.


CTFE works at compile-time, while people add scripting languages like Python,
JavaScript, Groovy, Jpython, Jruby, etc, to run-time C/C++/Java code for other
purposes. For example games are often written in C++ and Lua. For example
Firefox is C++ and JavaScript, ecc. You can't write one million of lines of D
CTFE code to script a 3D videogame. So unless you leave the compiler beside the
running program, and you allow to dynamically interpret and run D code at
runtime, the purposes are very different.

So I think embedding/extending D2 with a scripting/dynamic language (like MiniD
o Python with Pyd) will be useful for some future D projects. But I don't want
it built-in, people will find ways to attach it as they do to C/C++/Java. You
have to focus in building a good D language.

What I think I'd like in D is something like this, but I think there's no need
to use JavaScript for this, it can be used just D code:
https://developer.mozilla.org/en/Treehydra

Bye,
bearophile
Mar 29 2010
parent bearophile <bearophileHUGS lycos.com> writes:
 What I think I'd like in D is something like this, but I think there's no need
to use JavaScript for this, it can be used just D code:
 https://developer.mozilla.org/en/Treehydra


This page explains what Treehydra is:
https://developer.mozilla.org/En/Treehydra_Manual


Treehydra is meant to be used for analyses that need more detail than Dehydra's
flattened ASTs. Instead of representing code in "easy" form like Dehydra,
Treehydra relies on GIMPLE, the GCC Internals "middle-end" intermediate
representation.<


This is Dehydra, that's quite simpler to use:
https://developer.mozilla.org/en/Dehydra

Dehydra for example allows to add JavaScript callbacks to the compiler:
https://developer.mozilla.org/En/Dehydra/Function_Reference

Callback Functions The following functions may be provided by the analysis
script and will be called by Dehydra while compiling. See the Dehydra object
reference for details on the available object properties.<


The nicer page about Dehydra can be this one:
https://developer.mozilla.org/En/Dehydra/Object_Reference


Dehydra represents C++ types and variables as JavaScript objects. The objects
are designed to distill that type system to the minimum such that it can be
easy to match on.<


All those properties are present for all the variables, functions, etc, of the
C++ code. Such static reflexivity can be useful in D too, to extend the type
system a little, for user-defined properties, as a starting point to implement
macros.

Bye,
bearophile
Mar 31 2010
prev sibling parent Eric Poggel <dnewsgroup yage3d.net> writes:
On 3/22/2010 3:30 AM, Walter Bright wrote:

 http://www.digitalmars.com/dscript/index.html


Much appreciated!  Also wondering how its performance compares against V8.
Mar 30 2010