www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - D scripting in D

reply Mike B Johnson <Mikey Ikes.com> writes:
I wonder if it is possible to somehow turn D in to a scripting 
language that can be run inside D?

The point? To have the same uniform syntax for quickly developing 
scripts that can then be easily transferred, if desired, in to a 
complete binary.

e.g., suppose I am working in some type of analysis software. Use 
a Dscript like feature to develop and test different analysis 
algorithms quickly(rather than using the compile and execute 
model)... then once everything is working, move the code to a D 
file and compile it directly.

Since the syntax would be identical(or nearly so) it would be 
quite easy to copy and paste... unlike, say, using lua or some 
other non-D like scripting language.
Jun 01 2017
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 2 June 2017 at 02:06:27 UTC, Mike B Johnson wrote:

 I wonder if it is possible to somehow turn D in to a scripting 
 language that can be run inside D?


Why not just use regular compiled D?
Jun 01 2017
parent reply Mike B Johnson <Mikey Ikes.com> writes:
On Friday, 2 June 2017 at 02:15:27 UTC, Adam D. Ruppe wrote:

 On Friday, 2 June 2017 at 02:06:27 UTC, Mike B Johnson wrote:

 I wonder if it is possible to somehow turn D in to a scripting 
 language that can be run inside D?


 Why not just use regular compiled D?



Because it requires one to recompile and relink the code for 
every change(and to possibly restart the app and redo all the 
work to get to some point to start testing the code). In a 
scripting engine one can simply call a function and execute 
commands immediately in an interactive way. This allows for much 
faster testing.


e.g., with a hypothetical app that has an interactive Dscript, 
one could do


 App.PlaySound("test123.wav");



instead of

1. change test12.wav to test123.wav
2. save file
3. recompile.
4. run
5. Get back to same test point(could be a lot or a little amount 
of work).


Regardless, that is not the point though. If that was the only 
reason, lua or some other scripting language would suffice.

The problem is that the grammars of all those languages do not 
translate directly in to D. Anglescript is a C++ like script that 
has a near 1-1 correspondence so "porting" code from it to C++ is 
easy.

But it would be nice if a D had a scripting language that used 
the same D syntax as this would make porting a piece of cake.


The point is, why should I develop, say, 100's of algorithms in 
the scripting language that can never easily be ported to native 
and be fast as possible simply because the of the amount of work 
to rewrite the code when, semantically, nothing changes?

Wouldn't it be much better to be able to confidently write the 
code in a scripting environment that allows for nearly instance 
response knowing that it can simply be recompiled to native 
without issue when the time comes for performance optimizations?

Anglescript effectively does this. Note only does it have a C++ 
like syntax, it has the ability to compile to native directly 
with an addon.

I'm looking for something like this in D because D's features are 
much better. having meta capabilities in scripting would be cool.
Jun 01 2017
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 2 June 2017 at 02:32:43 UTC, Mike B Johnson wrote:

 1. change test12.wav to test123.wav
 2. save file
 3. recompile.
 4. run
 5. Get back to same test point(could be a lot or a little 
 amount of work).


If that is all you want; then compile your code into a dll/so and 
load the new version.
The D compiler is fast enough that it will not break your flow.

program-state management would be taken by the static part of 
your program.
Jun 01 2017
next sibling parent Mike B Johnson <Mikey Ikes.com> writes:
On Friday, 2 June 2017 at 02:39:47 UTC, Stefan Koch wrote:

 On Friday, 2 June 2017 at 02:32:43 UTC, Mike B Johnson wrote:

 1. change test12.wav to test123.wav
 2. save file
 3. recompile.
 4. run
 5. Get back to same test point(could be a lot or a little 
 amount of work).


 If that is all you want; then compile your code into a dll/so 
 and load the new version.
 The D compiler is fast enough that it will not break your flow.

 program-state management would be taken by the static part of 
 your program.


I thought about that but the state management would not be 
trivial and would prevent recompilation in most cases(because the 
state would not exist in the same format in recompiled version).  
While it is possible, it doesn't seem like the way to go(and not 
only that, one doesn't get all the benefits a scripting language 
has(sandboxing, jit, etc).

We can come up with alternatives all day long but it will never 
fulfill the role...
Jun 01 2017
prev sibling parent reply Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Fri, 2017-06-02 at 02:39 +0000, Stefan Koch via Digitalmars-d-learn
wrote:

 [=E2=80=A6]
 The D compiler is fast enough that it will not break your flow.
=20


This argument may work for you but it definitely doesn't work for me.

Using a language like Python, Groovy, Clojure, Lisp:

1. Edit
2. Run

With D and Go, both of which claim compilation so fast you do not
notice:

1. Edit
2. Compile
3. Run

This is a 50% overhead (*). Even with LiteIDE and Gogland, you have the
3 stage sequence for Go programming, and it is a wee bit annoying.

If and only if you have continuous compilation without manual
intervention, does Stage 2 go away. As far as I am aware there is
currently no continuous compilation framework for D. Now using inotify
, it should be possible. However Meson/Ninja, CMake/Ninja, SCons, etc.
do not support this out of the box. IntelliJ IDEA and CLion should be
able to support this, but D support isn't yet there out of the box
(**).


(*) Clearly a fatuous number, but there is an election in UK, so
fatuous statistics are order of the day.

(**) IntelliJ-Dlanguage project could always do with more eople working
on it.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jun 02 2017
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 2 June 2017 at 09:39:51 UTC, Russel Winder wrote:

 With D and Go, both of which claim compilation so fast you do 
 not notice:


1. Edit
2. run rdmd


Especially if you only expose to the "script" in D the same 
functions you'd expose to, say, a javascript script, that compile 
can be under a tenth of a second.

But 3/10 of a second isn't bad either and that's about what you'd 
get with an out of the box setup...
Jun 02 2017
parent reply Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Fri, 2017-06-02 at 12:27 +0000, Adam D. Ruppe via Digitalmars-d-
learn wrote:

 On Friday, 2 June 2017 at 09:39:51 UTC, Russel Winder wrote:

 With D and Go, both of which claim compilation so fast you do=C2=A0
 not notice:


=20
 1. Edit
 2. run rdmd
=20


There is no rdmd on Fedora Rawhide. There is only ldc2. (Indeed Debian
Sid has no rdmd either by default, you have to use d-apt.)


 Especially if you only expose to the "script" in D the same=C2=A0
 functions you'd expose to, say, a javascript script, that compile=C2=A0
 can be under a tenth of a second.
=20
 But 3/10 of a second isn't bad either and that's about what you'd=C2=A0
 get with an out of the box setup...


Not enough is made of rdmd. rdmd needs to be separated from dmd so it
works with gdc and ldc2.


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jun 02 2017
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 3 June 2017 at 05:04:24 UTC, Russel Winder wrote:

 Not enough is made of rdmd. rdmd needs to be separated from dmd 
 so it works with gdc and ldc2.


rdmd has always worked with them, at least with their gdmd and 
ldmd wrappers

https://github.com/dlang/tools/blob/master/rdmd.d#L46
Jun 03 2017
parent reply Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Sat, 2017-06-03 at 17:08 +0000, Adam D. Ruppe via Digitalmars-d-
learn wrote:

 On Saturday, 3 June 2017 at 05:04:24 UTC, Russel Winder wrote:

 Not enough is made of rdmd. rdmd needs to be separated from dmd=C2=A0
 so it works with gdc and ldc2.


=20
 rdmd has always worked with them, at least with their gdmd and=C2=A0
 ldmd wrappers
=20
 https://github.com/dlang/tools/blob/master/rdmd.d#L46
=20


So why isn't rdmd shipped as a separate thing if it can wrap any of the
three compilers?

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jun 03 2017
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 3 June 2017 at 17:24:08 UTC, Russel Winder wrote:

 So why isn't rdmd shipped as a separate thing if it can wrap 
 any of the three compilers?


it is... the link above is all there is to it, you simply compile 
it. The docs also call it a download: http://dlang.org/rdmd.html

dmd just happens to bundle it. The others prolly should too.
Jun 03 2017
parent Joakim <dlang joakim.fea.st> writes:
On Saturday, 3 June 2017 at 17:28:36 UTC, Adam D. Ruppe wrote:

 On Saturday, 3 June 2017 at 17:24:08 UTC, Russel Winder wrote:

 So why isn't rdmd shipped as a separate thing if it can wrap 
 any of the three compilers?


 it is... the link above is all there is to it, you simply 
 compile it. The docs also call it a download: 
 http://dlang.org/rdmd.html

 dmd just happens to bundle it. The others prolly should too.


Ldc should have it in the next release, except on Windows:

https://github.com/ldc-developers/ldc/issues/548#issuecomment-306073946
Jun 04 2017
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 2 June 2017 at 02:32:43 UTC, Mike B Johnson wrote:

 But it would be nice if a D had a scripting language that used 
 the same D syntax as this would make porting a piece of cake.



So my script.d has kinda similar syntax, but fairly different 
semantics than good D code (though my jsvar.d provides a type to 
D that is very similar to the type in the script)...

Which means copy/paste might even compile, but it would be liable 
to work differently.


 I'm looking for something like this in D because D's features 
 are much better. having meta capabilities in scripting would be 
 cool.


Mine also doesn't do the meta stuff... yet. I could prolly add it 
easily enough but I never got around to it.


But I really think you can find a lot of use just using D itself. 
Make your application into some kind of library you can link to 
and you can be testing stuff in like a second from the time you 
write it.

anyway i g2g will talk more later
Jun 01 2017
parent reply Mike B Johnson <Mikey Ikes.com> writes:
On Friday, 2 June 2017 at 03:33:37 UTC, Adam D. Ruppe wrote:

 On Friday, 2 June 2017 at 02:32:43 UTC, Mike B Johnson wrote:

 But it would be nice if a D had a scripting language that used 
 the same D syntax as this would make porting a piece of cake.



 So my script.d has kinda similar syntax, but fairly different 
 semantics than good D code (though my jsvar.d provides a type 
 to D that is very similar to the type in the script)...

 Which means copy/paste might even compile, but it would be 
 liable to work differently.


 I'm looking for something like this in D because D's features 
 are much better. having meta capabilities in scripting would 
 be cool.


 Mine also doesn't do the meta stuff... yet. I could prolly add 
 it easily enough but I never got around to it.


 But I really think you can find a lot of use just using D 
 itself. Make your application into some kind of library you can 
 link to and you can be testing stuff in like a second from the 
 time you write it.


I think that is more prone to errors and much harder to implement 
and maintain(assuming we had such a Dscript already).

If one could integrate it easily and well then possibly that 
could be Dscript...

1. Have ldc/dmd compile the "script"(D source) that exports, 
automatically, an entry point(main?). (easy)

2. Somehow allow different scripts to communicate(a real script 
doesn't have a problem with this, but a D app would need to 
"register" itself somehow). This could be easy or hard.

3. Link everything together(dll like stuff).

4. Passing of the hosting D app's context. this could be pretty 
hard to get right?

5. Allow for plug and play of the "dll's" generated... this could 
be tricky too.

Remember, we have to minimize all the junk code that won't be 
used in the D "equivalent" of the script. If one has to access 
all variables through some marshaling process and it slows down 
the code then we loose the ability to optimize by compiling to 
native code... which defeats the whole purpose.


Thoughts?


 anyway i g2g will talk more later



Ok, buddy! Thanks!
Jun 01 2017
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 2 June 2017 at 04:50:00 UTC, Mike B Johnson wrote:

 4. Passing of the hosting D app's context. this could be pretty 
 hard to get right?


You'd ideally access the data through functions and shared value 
types instead of loading it directly. Then you can easily do it 
with shared libs or scripts or, best of all, an external process 
so if the "plugin" crashes, it doesn't crash the rest of the 
program.

This is a decent design for any program really, it decouples 
components and keeps private members private.
Jun 02 2017
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 2 June 2017 at 02:06:27 UTC, Mike B Johnson wrote:

 I wonder if it is possible to somehow turn D in to a scripting 
 language that can be run inside D?

 The point? To have the same uniform syntax for quickly 
 developing scripts that can then be easily transferred, if 
 desired, in to a complete binary.

 e.g., suppose I am working in some type of analysis software. 
 Use a Dscript like feature to develop and test different 
 analysis algorithms quickly(rather than using the compile and 
 execute model)... then once everything is working, move the 
 code to a D file and compile it directly.

 Since the syntax would be identical(or nearly so) it would be 
 quite easy to copy and paste... unlike, say, using lua or some 
 other non-D like scripting language.


You might find the conversation on this thread interesting:
http://forum.dlang.org/thread/tssitxrniaxacpktjsat forum.dlang.org
Jun 02 2017
prev sibling next sibling parent reply Lewis <musicaljelly gmail.com> writes:
On Friday, 2 June 2017 at 02:06:27 UTC, Mike B Johnson wrote:

 I wonder if it is possible to somehow turn D in to a scripting 
 language that can be run inside D?


On a game project I'm working on at home, I've done:

- Hot reloading via a DLL
- A build script that runs in the background, detects file 
changes, and automatically rebuilds
- A code structure that keeps build times to a minimum (currently 
1.8s)

All these combined, and D feels pretty script-like. The setup is 
far from ideal, since it imposes some limitations on the language 
(only limited use of classes/finalizers, be careful with static 
data, some changes to the program state struct require a restart, 
etc). It also took a significant amount of work to get it up and 
running, requiring several changes to druntime.

But writing an entire feature with the game still running, 
followed by testing and iterating, all without closing the game, 
is pretty great. Way nicer than at work, where I have 1-15 minute 
rebuilds, with a restart for every change.
Jun 02 2017
parent reply Mike B Johnson <Mikey Ikes.com> writes:
On Friday, 2 June 2017 at 15:55:53 UTC, Lewis wrote:

 On Friday, 2 June 2017 at 02:06:27 UTC, Mike B Johnson wrote:

 I wonder if it is possible to somehow turn D in to a scripting 
 language that can be run inside D?


 On a game project I'm working on at home, I've done:

 - Hot reloading via a DLL
 - A build script that runs in the background, detects file 
 changes, and automatically rebuilds
 - A code structure that keeps build times to a minimum 
 (currently 1.8s)

 All these combined, and D feels pretty script-like. The setup 
 is far from ideal, since it imposes some limitations on the 
 language (only limited use of classes/finalizers, be careful 
 with static data, some changes to the program state struct 
 require a restart, etc). It also took a significant amount of 
 work to get it up and running, requiring several changes to 
 druntime.

 But writing an entire feature with the game still running, 
 followed by testing and iterating, all without closing the 
 game, is pretty great. Way nicer than at work, where I have 
 1-15 minute rebuilds, with a restart for every change.


Would you mind, when you get some time, to write up a more 
detailed analysis of the problems you had to overcome to get it 
to work? Possibly we could get some type of library solution that 
just "works" with very little change and restriction?

After all, dll's effectively already solve the problem, in some 
sense... except they are generally not meant to be reloaded on 
demand. Solving the issues that reloading causes, I think, would 
be the bulk of the problem?
Jun 02 2017
next sibling parent reply Lewis <musicaljelly gmail.com> writes:
On Friday, 2 June 2017 at 20:47:31 UTC, Mike B Johnson wrote:

 Would you mind, when you get some time, to write up a more 
 detailed analysis of the problems you had to overcome to get it 
 to work? Possibly we could get some type of library solution 
 that just "works" with very little change and restriction?


For sure. I actually want to post the source code at some point, 
but the changes I made are very much set up specifically for this 
project. I'll sift through at some point and see if I can gather 
together something worth posting.

The main problem with hot-reloading DLLs stems from the fact that 
every new D DLL comes with its own copy of druntime. This means a 
second GC, a second registry of active threads, a second registry 
of typeinfos, and so on. If there were a way to load a D DLL that 
automatically used the executable's copy of druntime, most of the 
hacks I had to make could be removed.

For reference, my general approach is that I have an EXE and a 
DLL. We run the EXE, which makes a copy of the DLL and loads the 
copy. Once per frame, the EXE calls GameUpdateAndRender() on the 
DLL, which does everything needed to step the game forward one 
frame. After each call to GameUpdateAndRender(), the EXE checks 
to see if the original DLL has changed. If so, we unload the DLL, 
make a copy of the new one, and load the copy. We then continue 
calling GameUpdateAndRender() as usual. All game state that needs 
to survive a hot reload is stored directly (or referenced 
indirectly) from a giant struct call the GameState. The EXE keeps 
a void* to the GameState, that way the GC doesn't collect 
anything inside it.

The main issues I remember off the top of my head:

- I have to use the GC proxy to redirect DLL GC calls over to the 
EXE's GC. This is because when I hot reload, the DLL's GC dies, 
so it can't be holding on to anything that needs to survive the 
hot reload (and I want pretty much everything to survive a hot 
reload).

- D has some built-in support for redirecting GC calls. However 
when you load a DLL, by the time you get a chance to call 
gc_setProxy(), it's too late, and druntime has already done a few 
allocations into the DLL GC. I had to change the order of a 
couple parts of initialization (in runtime.d I think?), and in my 
own code defer calling dll_attach_process() until after 
DllMain(). That way I get a chance to set up the GC proxy, then 
initialize druntime, which will trigger a few allocations that 
now go to the right place.

- I haven't experimented thoroughly with threading, but I think I 
have to do something similar. Since we're using the EXE's GC, if 
the EXE's druntime doesn't know about the existence of a thread 
spawned through the DLL's druntime, then we run into problems. So 
I redirect all thread spawning over to the EXE.

- With threading, we have to be careful that we don't tear down 
the DLL from underneath a thread that might still be running code 
on it. We have two options. 1. Join all threads before unloading 
the DLL.
2. The thread needs to be running a procedure that originates in 
the EXE, and then calls into the DLL, returning periodically back 
to the EXE. While execution is back in the EXE, we take that 
moment to reload the DLL.

Currently I'm doing the former, but might move to the latter if I 
end up needing long-lived threads for performance reasons. Note 
that callbacks originating from C code running on a separate 
thread also have this same restriction, and need to be handled 
careful.

- The different druntimes have different typeinfos for each 
class. This can be problematic for a few reasons, and I don't 
have as total a grasp on what situations related to classes are 
guaranteed to cause a crash. In particular, finalizers seem to 
cause problems, so I have disabled them entirely in druntime. In 
my own code, I almost exclusively use structs, and any instances 
of classes I do use are never stored long-term, and are never 
allowed to survive a hot reload.

I think those are all the D-specific gotchas, but I'll 
double-check my notes when I get home. In addition, there are 
common gotchas to this approach that would exist in other 
languages (C/C++ for example). Examples:

- Static variables will die in a hot reload, so be cautious using 
them.
- Storing a char* or string that references string in the data 
segment of the DLL will cause problems when we hot reload. To 
avoid this, I have a templated function that, on hot reload, 
iterates over my entire gamestate and copies each string. Since 
hot reloading is a debug-only utility for me, this is acceptable.
- Code changes to the gamestate struct will require a restart. 
Adding a new field to the gamestate does not, since I have some 
padding room at the end of the struct where I can add new fields 
during a hot reload.
- Don't hold on to function pointers through a hot reload, as 
functions addresses are liable to be reshuffled in the new DLL.
- Probably some others I'm forgetting.

In terms of making a library solution, I'm not sure what the best 
approach would be. But allowing users to compile a "light" D DLL 
that auto-patches itself back to the calling EXE's druntime would 
drastically reduce the number of hacks needed to make this work. 
So I guess that would be the main hurdle to overcome?
Jun 02 2017
parent reply Mike B Johnson <Mikey Ikes.com> writes:
On Saturday, 3 June 2017 at 00:02:54 UTC, Lewis wrote:

 On Friday, 2 June 2017 at 20:47:31 UTC, Mike B Johnson wrote:

 [...]


 For sure. I actually want to post the source code at some 
 point, but the changes I made are very much set up specifically 
 for this project. I'll sift through at some point and see if I 
 can gather together something worth posting.

 [...]


Thanks. Maybe some of this could be overcome by a design pattern 
that removes them from being an issue(e.g., script can not use 
GC... only to demonstrate that if that were the case, then you 
wouldn't have to worry about GC issues ;)?

I imagine that if "dll"'s were used that one would have all the 
power to debug and develop them as normal d code, which is nice 
and doesn't require a "script editor and debugger".
Jun 03 2017
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 03/06/2017 10:03 AM, Mike B Johnson wrote:

 On Saturday, 3 June 2017 at 00:02:54 UTC, Lewis wrote:

 On Friday, 2 June 2017 at 20:47:31 UTC, Mike B Johnson wrote:

 [...]


 For sure. I actually want to post the source code at some point, but 
 the changes I made are very much set up specifically for this project. 
 I'll sift through at some point and see if I can gather together 
 something worth posting.

 [...]


 
 Thanks. Maybe some of this could be overcome by a design pattern that 
 removes them from being an issue(e.g., script can not use GC... only to 
 demonstrate that if that were the case, then you wouldn't have to worry 
 about GC issues ;)?
 
 I imagine that if "dll"'s were used that one would have all the power to 
 debug and develop them as normal d code, which is nice and doesn't 
 require a "script editor and debugger".


A lot of this can be done by simply implementing shared libraries fully 
on Windows. There is a reason why TypeInfo doesn't cross the dll 
boundary right now. Sadly it isn't a high priority (and it really really 
needs to be "just done already"). Its fine for Linux.
Jun 03 2017
parent reply Lewis <musicaljelly gmail.com> writes:
On Saturday, 3 June 2017 at 09:28:03 UTC, rikki cattermole wrote:

 A lot of this can be done by simply implementing shared 
 libraries fully on Windows. There is a reason why TypeInfo 
 doesn't cross the dll boundary right now. Sadly it isn't a high 
 priority (and it really really needs to be "just done 
 already"). Its fine for Linux.


Is the D DLL situation different between Windows and Linux right 
now? If so, in what ways? I'm curious, I'm not set up for 
development on Linux currently so I wouldn't be up-to-date on 
these things.
Jun 03 2017
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 03/06/2017 4:43 PM, Lewis wrote:

 On Saturday, 3 June 2017 at 09:28:03 UTC, rikki cattermole wrote:

 A lot of this can be done by simply implementing shared libraries 
 fully on Windows. There is a reason why TypeInfo doesn't cross the dll 
 boundary right now. Sadly it isn't a high priority (and it really 
 really needs to be "just done already"). Its fine for Linux.


 
 Is the D DLL situation different between Windows and Linux right now? If 
 so, in what ways? I'm curious, I'm not set up for development on Linux 
 currently so I wouldn't be up-to-date on these things.


It is yes, all I know off the top of my head is that Windows is 
definitely broken and Linux should just work out of the box.
Jun 03 2017
prev sibling parent Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Fri, 2017-06-02 at 20:47 +0000, Mike B Johnson via Digitalmars-d-
learn wrote:

 [=E2=80=A6]
=20
 Would you mind, when you get some time, to write up a more=C2=A0
 detailed analysis of the problems you had to overcome to get it=C2=A0
 to work? Possibly we could get some type of library solution that=C2=A0
 just "works" with very little change and restriction?
=20
 After all, dll's effectively already solve the problem, in some=C2=A0
 sense... except they are generally not meant to be reloaded on=C2=A0
 demand. Solving the issues that reloading causes, I think, would=C2=A0
 be the bulk of the problem?


And there are always magazines/journals such as Overload and CVu [1]
which are places to publish articles that are more than just Web
ephemera.


[1] https://accu.org/index.php/journal
 =20
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jun 02 2017
prev sibling parent reply Laeeth Isharc <laeeth nospamlaeeth.com> writes:
On Friday, 2 June 2017 at 02:06:27 UTC, Mike B Johnson wrote:

 I wonder if it is possible to somehow turn D in to a scripting 
 language that can be run inside D?

 The point? To have the same uniform syntax for quickly 
 developing scripts that can then be easily transferred, if 
 desired, in to a complete binary.

 e.g., suppose I am working in some type of analysis software. 
 Use a Dscript like feature to develop and test different 
 analysis algorithms quickly(rather than using the compile and 
 execute model)... then once everything is working, move the 
 code to a D file and compile it directly.

 Since the syntax would be identical(or nearly so) it would be 
 quite easy to copy and paste... unlike, say, using lua or some 
 other non-D like scripting language.


Stefan Koch has written a good part of an interpreter for D AST, 
no? And I guess the lexing and parsing stage doesn't take so 
long, whereas not having to link saves much time.

So is there any way to repurpose his work on ctfe to have an 
interpreter that you can call at run time, set context for and 
get return values back?
Jun 02 2017
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 2 June 2017 at 16:13:03 UTC, Laeeth Isharc wrote:

 On Friday, 2 June 2017 at 02:06:27 UTC, Mike B Johnson wrote:

 [...]


 Stefan Koch has written a good part of an interpreter for D 
 AST, no? And I guess the lexing and parsing stage doesn't take 
 so long, whereas not having to link saves much time.

 So is there any way to repurpose his work on ctfe to have an 
 interpreter that you can call at run time, set context for and 
 get return values back?


No there is not.
First it's woefully incomplete and secondly it's tightly bound to 
dmd, and it's semantic phases
Jun 02 2017
next sibling parent reply "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
On Fri, Jun 02, 2017 at 05:22:20PM +0000, Stefan Koch via Digitalmars-d-learn
wrote:

 On Friday, 2 June 2017 at 16:13:03 UTC, Laeeth Isharc wrote:

 On Friday, 2 June 2017 at 02:06:27 UTC, Mike B Johnson wrote:

 [...]


 
 Stefan Koch has written a good part of an interpreter for D AST, no?
 And I guess the lexing and parsing stage doesn't take so long,
 whereas not having to link saves much time.
 
 So is there any way to repurpose his work on ctfe to have an
 interpreter that you can call at run time, set context for and get
 return values back?


 
 No there is not.  First it's woefully incomplete and secondly it's
 tightly bound to dmd, and it's semantic phases


Hmm. I wonder if there's a way for, say, ldc to export llvm bytecode of
a given D program, such that another program can load this bytecode and
interpret it at runtime?  Is it possible to use llvm in such a way?


T

-- 
People tell me that I'm skeptical, but I don't believe them.
Jun 02 2017
parent Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 2 June 2017 at 17:50:30 UTC, H. S. Teoh wrote:

 On Fri, Jun 02, 2017 at 05:22:20PM +0000, Stefan Koch via 
 Digitalmars-d-learn wrote:

 On Friday, 2 June 2017 at 16:13:03 UTC, Laeeth Isharc wrote:

 [...]


 
 No there is not.  First it's woefully incomplete and secondly 
 it's tightly bound to dmd, and it's semantic phases


 Hmm. I wonder if there's a way for, say, ldc to export llvm 
 bytecode of a given D program, such that another program can 
 load this bytecode and interpret it at runtime?  Is it possible 
 to use llvm in such a way?


 T


Yes it is possible but you will be astonished how slow this will 
be.
It is probably more viable run dmd and have it compile into a 
shared library.
Jun 02 2017
prev sibling parent Laeeth Isharc <laeeth nospamlaeeth.com> writes:
On Friday, 2 June 2017 at 17:22:20 UTC, Stefan Koch wrote:

 On Friday, 2 June 2017 at 16:13:03 UTC, Laeeth Isharc wrote:

 On Friday, 2 June 2017 at 02:06:27 UTC, Mike B Johnson wrote:

 [...]


 Stefan Koch has written a good part of an interpreter for D 
 AST, no? And I guess the lexing and parsing stage doesn't take 
 so long, whereas not having to link saves much time.

 So is there any way to repurpose his work on ctfe to have an 
 interpreter that you can call at run time, set context for and 
 get return values back?


 No there is not.
 First it's woefully incomplete and secondly it's tightly bound 
 to dmd, and it's semantic phases


Maybe it's incomplete today, but some day it will be or could be 
finished. And whilst I understand the difficulty of working with 
the dmd codebase as it's structured today, why is it 
intrinsically a problem that your work is bound to dmd?

T - interesting idea about ldc though that's a bit slower than 
dmd.
Jun 02 2017