D scripting

[Andre Pany via Digitalmars-d-learn]

On Tuesday, 5 September 2017 at 18:37:17 UTC, EntangledQuanta 
wrote:
> On Tuesday, 5 September 2017 at 08:13:02 UTC, Andre Pany wrote:
>> On Tuesday, 5 September 2017 at 07:32:24 UTC, EntangledQuanta 
>> wrote:
>>> I would like to use D as a "scripting" language for my D app. 
>>> There seems to be no such thing.
>>>
>>> Since we can include the D compiler in our distribution, it 
>>> is easy to enable "plugin" capabilities, but directly 
>>> interfacing with the source code seems like it would require 
>>> a bit of work(duplicating the code that one wants to include 
>>> so it can be linked in and "hot swapping").
>>
>> Which OS do you use? I had a similiar idea but failed on 
>> windows due to some strange effects. I think they were caused 
>> by the known windows dll unload bug, discussed here: 
>> http://forum.dlang.org/thread/rreyasqnvyagrkvqrjos@forum.dlang.org
>>
>> At the end I decided to use the script engine from Adam Ruppe 
>> (arsd) until this bug is fixed.
>>
>> Kind regards
>> André
>
>
> Yes, windows ;/ Seems that thread has some answers! Maybe bug 
> him enough to fix the bug?
>
> How far did you get with it?
>
> "The problem seems to only manifest when a proper DllMain() 
> method is exported from the library.  If none is provided, or 
> if the given implementation can be optimized away, the error 
> does not ocurr."
>
> Was that the case for you too? That could be overcome with just 
> using a normal function that is called right after loading?
>
> I'm curious how the exporting of code as that seems to be the 
> biggest challenge(so that we don't have to hand write the 
> exports ourselves).
>
>
> Thanks.

My issue was that after unload the shared library, the dll file 
was still locked for deletion on the file system. Therefore I was 
not able to change something in my "script" and restart it. 
Somehow even after terminating in task manager, the dll file was 
still locked. I assume this reproducable effect is caused by the 
known issue.
I already give up at this point ):

Just an idea for you: in delphi you can set the properties of a 
component (a class with runtime reflection enabled) on runtime. 
You can even call the methods and events of a component. I build 
a Delphi Bridge for D (see recent post on announce). It is almost 
the same scenario as here are also dll calls involved.
What I want to say, you could build something like the Delphi 
rtti for your D classes and make generic methods available via 
the dll interface.

Kind regards
André