D scripting (c++ integration)

[Pragma]

J Duncan wrote:
> 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.....

Awesome.  I can't wait to see what you've cooked up.  The idea of using 
DDL for IDE extensions is extremely cool - reminds me of VB-macros for 
Visual Studio.

I've been trying to develop a DDL-based reflection interface myself.

I can't blame you for using a parser to obtain a symbol catalog.  After 
compilation, I've noticed that there are some things that get thrown out:

- non-static field information (it's just an offset)
- templates (template declarations - instances, however, *are* visible)
- enums

... which is going to get a big "duh" from the gallery. :)  Anyway, some 
of this stuff is likely recoverable via debug info, but that's never 
100% reliable, nor implemented (in DDL) as of yet.

Which leads me to a question I've had for a while now.  You mentioned 
stub generators: do you (Mr. Duncan) think that it's feasible to have a 
front end that generates runtime reflection data, suitable for build to 
fold in automatically?  Have you seen/done anything that would make this 
a bad move?

-- 
- EricAnderton at yahoo