D scripting (c++ integration)

[J Duncan]

Pragma wrote:
> Johan Granberg wrote:
>> bubu wrote:
>>> Hiya,
>>>
>>> im a game programmer. I want to use some D-scripted objects in my 
>>> game which
>>> is programmed in C++. Can I embed a D scripting host like I can do 
>>> with Lua,
>>> Phyton or Ruby? thx
>>
>> This newsgroup is not used sou much anymore try digitalmars.D instead.
>>
>> To answer your question.
>>
>> I don't know of any way to embed D as a script language but if you 
>> want you could require script writers to compile their scripts using 
>> some D compiler. I think DDL (dsource.org) can be of use here, 
>> alternativly just build the scripts into a .dll/.so file.
>>
>> Hope that helped :)
> 
> Johan, thanks for the plug. :)
> 
> bubu,
> 
> DDL is going to work, but only if you have a D program to start.  You 
> might be able to roll your own scripting host as a .dll or something 
> similar, provided it's in D.  However, there's no embeded compiler 
> product available, so users will still need the D compiler installed.
> 
> With regards to DDL, using D for scripting is the reason why I hatched 
> the project in the first place.  If you go back and read my journal 
> entries in the DSP forum (also on DSource), you'll get an idea of what 
> is ahead of you for dynamic binding on windows, without such a 
> technology.  Depending on how you proceed, you may or may not need to 
> worry about the things I did.
> 
> FWIW, the following pattern can be used to make D flow a bit more like 
> live scripting environments:
> 
> 1) Launch the D compiler from within your app directly, to compile the 
> "script" you want to run - std.process works well.
> 2) Use DDL to bind the .obj file from the compiler output.  The linker 
> will return a DynamicLibrary object to use.
> 3) Use the DynamicLibrary to bind any functions, classes, or static 
> fields that you know to exist in the compiled script.
> 
> That last point is kind of tricky.  While you can simply force script 
> coders to adhere to a particular interface, I found it easier to wrap 
> the whole script in a function (call that step #0) before compilation. 
> This ensures that the starting point of the script was always known, at 
> the cost of disallowing some D constructs (bang-line, imports, module 
> static init, etc).  It also allows the script author to start from line 
> 1, much like one can in PHP or JavaScript.
> 

Actually, I spent most of my weekend experimenting with such techniques. 
(btw pragma I am updating the COFF code but i keep getting sidetracked 
with DDL adventures :) Ive got a little IDE that combines the dparser 
and DDL - mostly for experimentation at the present time. I have a class 
I call a DMachine that loads, links, and manages a set of 
(object/library) modules. Im currently doing basic introspection of the 
mangled identifiers to obtain a catalog of symbols, but Ive started to 
integrate dparser to get a better symbol catalogs. im playing around 
with having a 'extension' source module that is compiled and linked into 
your running exe - at runtime (I even tried did the trick of embedding a 
'script' into a fake module function). Ive even added the expression 
parsing capabilities of dparser to parse out an expression from a string 
( such as 'doSomething("hello");' to a CallExp to call a function). 
basically, as we have discussed, DDL is still very 'raw' and we still 
probably need some sort of 'sdk' layer to make this technology much 
easier. But, we definitely have the capabilities to do what is being 
discussed in this thread. Im not sure i would call this 'scripting' but 
that makes sense. at the least these technologies can probably open our 
binaries or source up to automating the integration of external 
scripting solutions - automatic stub generation, etc...

Anyway, DDL gives us great potential in this area.....