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/rreyasqnvyagrkvqr...@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 ;)
