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