Re: D scripting in D
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
Re: D scripting in D
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.
Re: D scripting in D
On Sat, 2017-06-03 at 17:08 +, 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 > > 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 > So why isn't rdmd shipped as a separate thing if it can wrap any of the three compilers? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D scripting in D
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
Re: D scripting in D
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.
Re: D scripting in D
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.
Re: D scripting in D
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.
Re: D scripting in D
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".
Re: D scripting in D
On Fri, 2017-06-02 at 20:47 +, Mike B Johnson via Digitalmars-d- learn 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? > > 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? 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 -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D scripting in D
On Fri, 2017-06-02 at 12:27 +, 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 > > not notice: > > 1. Edit > 2. run rdmd > 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 > 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... Not enough is made of rdmd. rdmd needs to be separated from dmd so it works with gdc and ldc2. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D scripting in D
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
Re: D scripting in D
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?
Re: D scripting in D
On Friday, 2 June 2017 at 17:50:30 UTC, H. S. Teoh wrote: On Fri, Jun 02, 2017 at 05:22:20PM +, 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.
Re: D scripting in D
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.
Re: D scripting in D
On Fri, Jun 02, 2017 at 05:22:20PM +, 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.
Re: D scripting in D
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
Re: D scripting in D
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?
Re: D scripting in D
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.
Re: D scripting in D
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/tssitxrniaxacpktj...@forum.dlang.org
Re: D scripting in D
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...
Re: D scripting in D
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.
Re: D scripting in D
On Fri, 2017-06-02 at 02:39 +, Stefan Koch via Digitalmars-d-learn wrote: > […] > The D compiler is fast enough that it will not break your flow. > 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. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D scripting in D
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!
Re: D scripting in D
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
Re: D scripting in D
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...
Re: D scripting in D
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.
Re: D scripting in D
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.
Re: D scripting in D
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?
D scripting in D
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.
