D scripting

[EntangledQuanta via Digitalmars-d-learn]

On Tuesday, 5 September 2017 at 19:19:19 UTC, Andre Pany wrote:
> 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 ):

Hmm, I used to have that problem with windows and visual studio. 
It was a Visual studio issue. Not sure if that is what you were 
using.  Sometimes it's just programs that lock on to it for no 
good reason.

There are ways around that: Use "unlocker" to unlock the file 
before deletion. Possibly rename the file to a random name 
opening up the space. Remove the generated files later when they 
build up. Load the DLL from memory(There are some online memory 
DLL loaders).

> 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.
>

But that would be quite a bit of work? Modifying the compiler? 
I'm just looking for something relatively straightforward and 
simple ;)