www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD as a library package can now run through all semantic phases

reply Seb <seb wilzba.ch> writes:
In case someone wants to play with DMD as a library, it got a lot 
easier as of today.
Here's an example:

```
#!/usr/bin/env dub
/+dub.sdl:
dependency "dmd" version="~master"
+/
void main()
{
     import dmd.frontend;
     import std.algorithm : each;
     import std.stdio;

     // Sets DMD's global variables. Only required to be called 
once
     // In the future this might be done automatically (e.g. 
module constructor or initOnce)
     initDMD;

     // Search for the predefined import paths of your host 
compiler (DMD and LDC are supported)
     findImportPaths.each!addImport;

     // Load a module
     // (if no second argument is given, the file will be opened 
and read)
     auto m = parseModule("test.d", q{
         void foo()
         {
             foreach (i; 0..10) {}
         }
     });

     // Run through all semantic phases
     m.fullSemantic;
     m.prettyPrint.writeln;
}
```


Want to know what it prints? Run the file!
Spoiler: it's similar to new the AST feature at run.dlang.io:

https://run.dlang.io/is/mwU67O

__Warning__: the DMD DUB package is still experimental and at the 
moment should only be used by alpha warriors.

See also:

https://dlang.org/phobos-prerelease/dmd_frontend.html (will work 
soon)
https://dlang.org/library-prerelease/dmd/frontend.html (Ddox 
documentation, works already)

Huge thanks and credits goes to Jacob Carlborg and Razvan Nitu as 
well.
Jan 26
next sibling parent reply timotheecour <timothee.cour2 gmail.com> writes:
On Friday, 26 January 2018 at 18:40:23 UTC, Seb wrote:
 In case someone wants to play with DMD as a library, it got a 
 lot easier as of today.
 Here's an example:

 ```
 #!/usr/bin/env dub
 /+dub.sdl:
 dependency "dmd" version="~master"
 +/
 void main()
 {
     import dmd.frontend;
     import std.algorithm : each;
     import std.stdio;

     // Sets DMD's global variables. Only required to be called 
 once
     // In the future this might be done automatically (e.g. 
 module constructor or initOnce)
     initDMD;

     // Search for the predefined import paths of your host 
 compiler (DMD and LDC are supported)
     findImportPaths.each!addImport;

     // Load a module
     // (if no second argument is given, the file will be opened 
 and read)
     auto m = parseModule("test.d", q{
         void foo()
         {
             foreach (i; 0..10) {}
         }
     });

     // Run through all semantic phases
     m.fullSemantic;
     m.prettyPrint.writeln;
 }
 ```


 Want to know what it prints? Run the file!
 Spoiler: it's similar to new the AST feature at run.dlang.io:

 https://run.dlang.io/is/mwU67O

 __Warning__: the DMD DUB package is still experimental and at 
 the moment should only be used by alpha warriors.

 See also:

 https://dlang.org/phobos-prerelease/dmd_frontend.html (will 
 work soon)
 https://dlang.org/library-prerelease/dmd/frontend.html (Ddox 
 documentation, works already)

 Huge thanks and credits goes to Jacob Carlborg and Razvan Nitu 
 as well.
on OSX: chmod u+x main.d ./main.d WARNING: A deprecated branch based version specification is used for the dependency dmd. Please use numbered versions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a branch instead. Invalid source/import path: /Users/timothee/.dub/packages/dmd-master/dmd/generated/dub core.exception.AssertError ../../../../../.dub/packages/dmd-master/dmd/src/ md/frontend.d(208): No valid config found.
Jan 26
next sibling parent Seb <seb wilzba.ch> writes:
On Saturday, 27 January 2018 at 00:47:01 UTC, timotheecour wrote:
 on OSX:
 chmod u+x main.d
 ./main.d

 WARNING: A deprecated branch based version specification is 
 used for the dependency dmd. Please use numbered versions 
 instead. Also note that you can still use the 
 dub.selections.json file to override a certain dependency to 
 use a branch instead.
That's expected, but well DMD doesn't use semantic versioning yet, so ~master is the only valid version out there.
 Invalid source/import path: 
 /Users/timothee/.dub/packages/dmd-master/dmd/generated/dub
 core.exception.AssertError ../../../../../.dub/packages/dmd-master/dmd/src/
md/frontend.d(208): No valid config found.
That's not expected (and before OSX went crazy on Travis there where tests for this). What's your default compiler? How did you install it? If it's dmd, then DMD's default detection is called: https://github.com/dlang/dmd/blob/master/src/dmd/frontend.d#L82
Jan 26
prev sibling next sibling parent reply timotheecour <timothee.cour2 gmail.com> writes:
On Saturday, 27 January 2018 at 00:47:01 UTC, timotheecour wrote:
 on OSX:
 chmod u+x main.d
 ./main.d

 WARNING: A deprecated branch based version specification is 
 used for the dependency dmd. Please use numbered versions 
 instead. Also note that you can still use the 
 dub.selections.json file to override a certain dependency to 
 use a branch instead.
 Invalid source/import path: 
 /Users/timothee/.dub/packages/dmd-master/dmd/generated/dub
 core.exception.AssertError ../../../../../.dub/packages/dmd-master/dmd/src/
md/frontend.d(208): No valid config found.
the bug is that homebrew dmd installs dmd.conf in /Users/timothee/homebrew/etc/dmd.conf; findDMDConfig should instead look for dmd.conf by calling `dmd -v|grep 'Config file'` (and caching result for each file+time_last_modified) which would be more robust workaround: hardcode /Users/timothee/homebrew/etc/dmd.conf in findDMDConfig in dmd:src/dmd/frontend.d
Jan 26
parent timotheecour <timothee.cour2 gmail.com> writes:
On Saturday, 27 January 2018 at 01:10:35 UTC, timotheecour wrote:
 On Saturday, 27 January 2018 at 00:47:01 UTC, timotheecour
 the bug is that homebrew dmd installs dmd.conf in 
 /Users/timothee/homebrew/etc/dmd.conf; findDMDConfig should 
 instead look for dmd.conf by calling `dmd -v|grep 'Config 
 file'` (and caching result for each file+time_last_modified) 
 which would be more robust

 workaround: hardcode /Users/timothee/homebrew/etc/dmd.conf in 
 findDMDConfig in dmd:src/dmd/frontend.d
Actually an even more robust way to get the conf file: call dmd -Xf=tempfile and get it from json output doable once https://github.com/dlang/dmd/pull/7757 is accepted
Jan 26
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2018-01-27 01:47, timotheecour wrote:

 Invalid source/import path: 
 /Users/timothee/.dub/packages/dmd-master/dmd/generated/dub
 core.exception.AssertError ../../../../../.dub/packages/dmd-master/dmd/src/
md/frontend.d(208): 
 No valid config found.
Note that you don't *need* to use "findImportPaths". You can specify the import paths yourself, it's a library after all. -- /Jacob Carlborg
Jan 27
prev sibling next sibling parent reply timotheecour <timothee.cour2 gmail.com> writes:
On Friday, 26 January 2018 at 18:40:23 UTC, Seb wrote:
 Want to know what it prints? Run the file!
 Spoiler: it's similar to new the AST feature at run.dlang.io:
prettyPrint produces valid D code except for template instantiations: ``` writeln!int { safe void writeln(int _param_0) { import std.traits : isAggregateType; ((File __tmpfordtor37 = trustedStdout();) , __tmpfordtor37).write(_param_0, '\x0a'); } } ``` why not write something like: ``` template writeln(T:int) { ... } ``` or template writeln(T) if(is(T==int))
Jan 26
parent reply Seb <seb wilzba.ch> writes:
On Saturday, 27 January 2018 at 01:25:18 UTC, timotheecour wrote:
 On Friday, 26 January 2018 at 18:40:23 UTC, Seb wrote:
 Want to know what it prints? Run the file!
 Spoiler: it's similar to new the AST feature at run.dlang.io:
prettyPrint produces valid D code except for template instantiations: ``` writeln!int { safe void writeln(int _param_0) { import std.traits : isAggregateType; ((File __tmpfordtor37 = trustedStdout();) , __tmpfordtor37).write(_param_0, '\x0a'); } } ``` why not write something like: ``` template writeln(T:int) { ... } ``` or template writeln(T) if(is(T==int))
Agreed, but prettyPrint: https://github.com/dlang/dmd/blob/master/src/dmd/frontend.d#L275 is just a nice wrapper around the existing PrettyPrintVisitor: https://github.com/dlang/dmd/blob/master/src/dmd/hdrgen.d#L84
Jan 26
parent timotheecour <timothee.cour2 gmail.com> writes:
On Saturday, 27 January 2018 at 01:36:17 UTC, Seb wrote:
 On Saturday, 27 January 2018 at 01:25:18 UTC, timotheecour 
 Agreed, but prettyPrint:

 https://github.com/dlang/dmd/blob/master/src/dmd/frontend.d#L275

 is just a nice wrapper around the existing PrettyPrintVisitor:


 https://github.com/dlang/dmd/blob/master/src/dmd/hdrgen.d#L84
filed https://issues.dlang.org/show_bug.cgi?id=18311
Jan 26
prev sibling next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 26/01/2018 6:40 PM, Seb wrote:
 In case someone wants to play with DMD as a library, it got a lot easier 
 as of today.
 Here's an example:
 
 ```
 #!/usr/bin/env dub
 /+dub.sdl:
 dependency "dmd" version="~master"
 +/
 void main()
 {
      import dmd.frontend;
      import std.algorithm : each;
      import std.stdio;
 
      // Sets DMD's global variables. Only required to be called once
      // In the future this might be done automatically (e.g. module 
 constructor or initOnce)
      initDMD;
 
      // Search for the predefined import paths of your host compiler 
 (DMD and LDC are supported)
      findImportPaths.each!addImport;
 
      // Load a module
      // (if no second argument is given, the file will be opened and read)
      auto m = parseModule("test.d", q{
          void foo()
          {
              foreach (i; 0..10) {}
          }
      });
 
      // Run through all semantic phases
      m.fullSemantic;
      m.prettyPrint.writeln;
 }
 ```
 
 
 Want to know what it prints? Run the file!
 Spoiler: it's similar to new the AST feature at run.dlang.io:
 
 https://run.dlang.io/is/mwU67O
 
 __Warning__: the DMD DUB package is still experimental and at the moment 
 should only be used by alpha warriors.
 
 See also:
 
 https://dlang.org/phobos-prerelease/dmd_frontend.html (will work soon)
 https://dlang.org/library-prerelease/dmd/frontend.html (Ddox 
 documentation, works already)
 
 Huge thanks and credits goes to Jacob Carlborg and Razvan Nitu as well.
Is it possible to reset the compiler to the point of uninitialized/newly initialized? For reuse in a single process.
Jan 26
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 27/01/2018 4:14 AM, rikki cattermole wrote:
 Is it possible to reset the compiler to the point of uninitialized/newly 
 initialized?
 
 For reuse in a single process.
I have been toying with this idea. Example: void main() { import dmd.frontend; import std.algorithm : each; import std.stdio; // Sets DMD's global variables. Only required to be called once // In the future this might be done automatically (e.g. module constructor or initOnce) initDMD; foreach (_; 0 .. 1) { // This doesn't need to be called first time, // however for repeated usage of dmd as a library, it is required before each time. // It allows for tokens (identifiers mostly) to be reset and not leak memory. resetDMD(); // Search for the predefined import paths of your host compiler (DMD and LDC are supported) findImportPaths.each!addImport; // Load a module // (if no second argument is given, the file will be opened and read) auto m = parseModule("test.d", q{ void foo() { foreach (i; 0..10) {} } }); // Run through all semantic phases m.fullSemantic; m.prettyPrint.writeln; } } Patch (incomplete, and I probably missed loads): From 5f8894ce35ecfccbd1dc48424d262f59bf5dcd6b Mon Sep 17 00:00:00 2001 From: rikki cattermole <alphaglosined gmail.com> Date: Tue, 30 Jan 2018 01:49:22 +1300 Subject: [PATCH] Reset of state --- src/dmd/builtin.d | 2 +- src/dmd/frontend.d | 31 ++++++++++++++++++++++++++++--- src/dmd/objc.d | 2 +- 3 files changed, 30 insertions(+), 5 deletions(-) diff --git a/src/dmd/builtin.d b/src/dmd/builtin.d index 9f1e2163f..b0b0db233 100644 --- a/src/dmd/builtin.d +++ b/src/dmd/builtin.d -218,7 +218,7 extern (C++) Expression eval_yl2xp1(Loc loc, FuncDeclaration fd, Expressions* ar public extern (C++) void builtin_init() { - builtins._init(47); + builtins.reset(47); // safe nogc pure nothrow real function(real) add_builtin("_D4core4math3sinFNaNbNiNfeZe", &eval_sin); add_builtin("_D4core4math3cosFNaNbNiNfeZe", &eval_cos); diff --git a/src/dmd/frontend.d b/src/dmd/frontend.d index 654516d54..d7ffe0e1a 100644 --- a/src/dmd/frontend.d +++ b/src/dmd/frontend.d -18,8 +18,16 import dmd.dmodule : Module; import std.range.primitives : isInputRange, ElementType; import std.traits : isNarrowString; -version (Windows) private enum sep = ";", exe = ".exe"; -version (Posix) private enum sep = ":", exe = ""; +version (Windows) +{ + private enum sep = ";", exe = ".exe"; + private enum DMD_CONF_FILE = "sc.ini"; +} +version (Posix) +{ + private enum sep = ":", exe = ""; + private enum DMD_CONF_FILE = "dmd.conf"; +} /* Initializes the global variables of the DMD compiler. -49,6 +57,23 void initDMD() builtin_init(); } +void resetDMD() +{ + import dmd.tokens; + import dmd.mtype; + import dmd.dmodule; + import dmd.target : Target; + import dmd.objc : Objc; + import dmd.builtin : builtin_init; + + Token.reinitialize(); + //TODO: Type.* = + //TODO: Module.* = + Target._init(); + Objc._init(); + builtin_init(); +} + /** Add import path to the `global.path`. Params: -79,7 +104,7 string findDMDConfig(string dmdFilePath) import dmd.dinifile : findConfFile; import std.string : fromStringz, toStringz; - auto f = findConfFile(dmdFilePath.toStringz, "dmd.conf"); + auto f = findConfFile(dmdFilePath.toStringz, DMD_CONF_FILE); if (f is null) return null; diff --git a/src/dmd/objc.d b/src/dmd/objc.d index 225c2f108..35d4d2331 100644 --- a/src/dmd/objc.d +++ b/src/dmd/objc.d -41,7 +41,7 struct ObjcSelector extern (C++) static void _init() { - stringtable._init(); + stringtable.reset(); } extern (D) this(const(char)* sv, size_t len, size_t pcount) -- 2.12.2.windows.2 From 6313e30a8bfb32e65c74f700ee3ad5ac6e0d7656 Mon Sep 17 00:00:00 2001 From: rikki cattermole <alphaglosined gmail.com> Date: Tue, 30 Jan 2018 00:24:03 +1300 Subject: [PATCH] reset tokens --- src/dmd/identifier.d | 2 +- src/dmd/tokens.d | 7 ++++++- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/src/dmd/identifier.d b/src/dmd/identifier.d index a6702cdda..6e1cef6bf 100644 --- a/src/dmd/identifier.d +++ b/src/dmd/identifier.d -206,6 +206,6 nothrow: static void initTable() { - stringtable._init(28000); + stringtable.reset(28000); } } diff --git a/src/dmd/tokens.d b/src/dmd/tokens.d index 1771fe246..057c5900f 100644 --- a/src/dmd/tokens.d +++ b/src/dmd/tokens.d -599,7 +599,7 extern (C++) struct Token return true; }()); - shared static this() + static void reinitialize() { Identifier.initTable(); foreach (kw; keywords) -609,6 +609,11 extern (C++) struct Token } } + shared static this() + { + reinitialize(); + } + __gshared Token* freelist = null; static Token* alloc() -- 2.12.2.windows.2
Jan 29
parent reply Jacob Carlborg <doob me.com> writes:
On 2018-01-29 13:53, rikki cattermole wrote:

 I have been toying with this idea.
There's a whole bunch of global variables that I think need to be reset. In mtype.d, for example. -- /Jacob Carlborg
Jan 29
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 29/01/2018 4:01 PM, Jacob Carlborg wrote:
 On 2018-01-29 13:53, rikki cattermole wrote:
 
 I have been toying with this idea.
There's a whole bunch of global variables that I think need to be reset. In mtype.d, for example.
Yes, there is a function the patch I added on here, with all the globals imported and TODO's for the ones I didn't do. There is quite a few, and I bet I missed loads :/
Jan 29
prev sibling next sibling parent Johan Engelen <j j.nl> writes:
On Friday, 26 January 2018 at 18:40:23 UTC, Seb wrote:
 In case someone wants to play with DMD as a library, it got a 
 lot easier as of today.
Very cool. *cough* fuzz target *ahem* *cough* continuous fuzzing *cough* . ;) Johan
Jan 27
prev sibling parent reply Amorphorious <Amorphorious gmail.com> writes:
On Friday, 26 January 2018 at 18:40:23 UTC, Seb wrote:
 In case someone wants to play with DMD as a library, it got a 
 lot easier as of today.
 Here's an example:

 ```
 #!/usr/bin/env dub
 /+dub.sdl:
 dependency "dmd" version="~master"
 +/
 void main()
 {
     import dmd.frontend;
     import std.algorithm : each;
     import std.stdio;

     // Sets DMD's global variables. Only required to be called 
 once
     // In the future this might be done automatically (e.g. 
 module constructor or initOnce)
     initDMD;

     // Search for the predefined import paths of your host 
 compiler (DMD and LDC are supported)
     findImportPaths.each!addImport;

     // Load a module
     // (if no second argument is given, the file will be opened 
 and read)
     auto m = parseModule("test.d", q{
         void foo()
         {
             foreach (i; 0..10) {}
         }
     });

     // Run through all semantic phases
     m.fullSemantic;
     m.prettyPrint.writeln;
 }
 ```


 Want to know what it prints? Run the file!
 Spoiler: it's similar to new the AST feature at run.dlang.io:

 https://run.dlang.io/is/mwU67O

 __Warning__: the DMD DUB package is still experimental and at 
 the moment should only be used by alpha warriors.

 See also:

 https://dlang.org/phobos-prerelease/dmd_frontend.html (will 
 work soon)
 https://dlang.org/library-prerelease/dmd/frontend.html (Ddox 
 documentation, works already)

 Huge thanks and credits goes to Jacob Carlborg and Razvan Nitu 
 as well.
What does this actually allow one to do besides parse d code and print it? Can it compile D code at runtime? Interface external D code in unique ways at compile time(similar to string mixins but possibly better)? Just curious what the point is and what box it opens.
Jan 29
parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Tuesday, 30 January 2018 at 00:21:09 UTC, Amorphorious wrote:
 Just curious what the point is and what box it opens.
Better tooling is what comes to my mind. Imagine your editor to understand your code as good as the compiler itself. I assume this is the primary motivation.
Jan 29
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 30, 2018 at 01:20:02AM +0000, Bastiaan Veelo via Digitalmars-d
wrote:
 On Tuesday, 30 January 2018 at 00:21:09 UTC, Amorphorious wrote:
 Just curious what the point is and what box it opens.
Better tooling is what comes to my mind. Imagine your editor to understand your code as good as the compiler itself. I assume this is the primary motivation.
Being able to compile D code in your program (i.e., have an embedded D compiler) is also nice for JIT applications. E.g., fill in a code template with runtime-determined parameters, compile it, and run it at native execution speed. T -- Music critic: "That's an imitation fugue!"
Jan 29
parent reply EntangledQuanta <EQ universe.com> writes:
On Tuesday, 30 January 2018 at 02:04:30 UTC, H. S. Teoh wrote:
 On Tue, Jan 30, 2018 at 01:20:02AM +0000, Bastiaan Veelo via 
 Digitalmars-d wrote:
 On Tuesday, 30 January 2018 at 00:21:09 UTC, Amorphorious 
 wrote:
 Just curious what the point is and what box it opens.
Better tooling is what comes to my mind. Imagine your editor to understand your code as good as the compiler itself. I assume this is the primary motivation.
Being able to compile D code in your program (i.e., have an embedded D compiler) is also nice for JIT applications. E.g., fill in a code template with runtime-determined parameters, compile it, and run it at native execution speed. T
and can it do this? I didn't see anything in the docs that show that it can be used for "scripting", so to speak. Just seemed to be used for semantic analysis and pretty printing. Are these future plans or are they meant to be used as part of simply compiling D code with externally using a dmd compiler bundled with the app(which can already be done)? It would be really cool to be able to create D scripts in an application directly using a "library" solution. I hope though all can be independent of the GC and OS. I'd like to use it for embedded solutions.
Jan 29
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 30/01/2018 4:21 AM, EntangledQuanta wrote:
 On Tuesday, 30 January 2018 at 02:04:30 UTC, H. S. Teoh wrote:
 On Tue, Jan 30, 2018 at 01:20:02AM +0000, Bastiaan Veelo via 
 Digitalmars-d wrote:
 On Tuesday, 30 January 2018 at 00:21:09 UTC, Amorphorious wrote:
 Just curious what the point is and what box it opens.
Better tooling is what comes to my mind. Imagine your editor to understand your code as good as the compiler itself. I assume this is the primary motivation.
Being able to compile D code in your program (i.e., have an embedded D compiler) is also nice for JIT applications.  E.g., fill in a code template with runtime-determined parameters, compile it, and run it at native execution speed. T
and can it do this? I didn't see anything in the docs that show that it can be used for "scripting", so to speak. Just seemed to be used for semantic analysis and pretty printing. Are these future plans or are they meant to be used as part of simply compiling D code with externally using a dmd compiler bundled with the app(which can already be done)?
The backend still isn't fully D, so it won't be a goal short-term. But it should be mostly just hooking up a new target into which it gets put into memory instead of an object file.
 It would be really cool to be able to create D scripts in an application 
 directly using a "library" solution. I hope though all can be 
 independent of the GC and OS. I'd like to use it for embedded solutions.
D isn't a scripting language, it is native. It will always matter what OS/platform you are compiling to.
Jan 29
next sibling parent reply Amorphorious <Amorphorious gmail.com> writes:
On Tuesday, 30 January 2018 at 04:31:43 UTC, rikki cattermole 
wrote:
 On 30/01/2018 4:21 AM, EntangledQuanta wrote:
 On Tuesday, 30 January 2018 at 02:04:30 UTC, H. S. Teoh wrote:
 On Tue, Jan 30, 2018 at 01:20:02AM +0000, Bastiaan Veelo via 
 Digitalmars-d wrote:
 On Tuesday, 30 January 2018 at 00:21:09 UTC, Amorphorious 
 wrote:
 Just curious what the point is and what box it opens.
Better tooling is what comes to my mind. Imagine your editor to understand your code as good as the compiler itself. I assume this is the primary motivation.
Being able to compile D code in your program (i.e., have an embedded D compiler) is also nice for JIT applications.  E.g., fill in a code template with runtime-determined parameters, compile it, and run it at native execution speed. T
and can it do this? I didn't see anything in the docs that show that it can be used for "scripting", so to speak. Just seemed to be used for semantic analysis and pretty printing. Are these future plans or are they meant to be used as part of simply compiling D code with externally using a dmd compiler bundled with the app(which can already be done)?
The backend still isn't fully D, so it won't be a goal short-term. But it should be mostly just hooking up a new target into which it gets put into memory instead of an object file.
 It would be really cool to be able to create D scripts in an 
 application directly using a "library" solution. I hope though 
 all can be independent of the GC and OS. I'd like to use it 
 for embedded solutions.
D isn't a scripting language, it is native. It will always matter what OS/platform you are compiling to.
Um, all scripting languages are native. Just because there is an intermediary doesn't mean much except speed. The boundary isn't as well defined as you want to imply. (and don't start and argument about how 95% of people would say scripting is not the same as native... statistics doesn't imply truth. Scripting is a term that is used to imply that an application supports modification through coding, not much more. It's not all that difficult to grasp. It just turns out that most scripting languages use an intermediate compiler or interpreter because that is how things evolved... it doesn't meant that is the only way things can be) 2nd. What I mean is not the binary but the library code itself. Will it only work on windows, for example. As I said, I want to use it for embedded solutions and if it only works for specific platforms then it is of no use to me and as if it didn't exist in the first place. This means that whatever solution it does use is not tied in to phobos too much nor the GC(ideally, not at all).
Jan 29
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 30/01/2018 5:45 AM, Amorphorious wrote:
 On Tuesday, 30 January 2018 at 04:31:43 UTC, rikki cattermole wrote:
 On 30/01/2018 4:21 AM, EntangledQuanta wrote:
 On Tuesday, 30 January 2018 at 02:04:30 UTC, H. S. Teoh wrote:
 On Tue, Jan 30, 2018 at 01:20:02AM +0000, Bastiaan Veelo via 
 Digitalmars-d wrote:
 On Tuesday, 30 January 2018 at 00:21:09 UTC, Amorphorious wrote:
 Just curious what the point is and what box it opens.
Better tooling is what comes to my mind. Imagine your editor to understand your code as good as the compiler itself. I assume this is the primary motivation.
Being able to compile D code in your program (i.e., have an embedded D compiler) is also nice for JIT applications. E.g., fill in a code template with runtime-determined parameters, compile it, and run it at native execution speed. T
and can it do this? I didn't see anything in the docs that show that it can be used for "scripting", so to speak. Just seemed to be used for semantic analysis and pretty printing. Are these future plans or are they meant to be used as part of simply compiling D code with externally using a dmd compiler bundled with the app(which can already be done)?
The backend still isn't fully D, so it won't be a goal short-term. But it should be mostly just hooking up a new target into which it gets put into memory instead of an object file.
 It would be really cool to be able to create D scripts in an 
 application directly using a "library" solution. I hope though all 
 can be independent of the GC and OS. I'd like to use it for embedded 
 solutions.
D isn't a scripting language, it is native. It will always matter what OS/platform you are compiling to.
Um, all scripting languages are native. Just because there is an intermediary doesn't mean much except speed. The boundary isn't as well defined as you want to imply. (and don't start and argument about how 95% of people would say scripting is not the same as native... statistics doesn't imply truth. Scripting is a term that is used to imply that an application supports modification through coding, not much more. It's not all that difficult to grasp. It just turns out that most scripting languages use an intermediate compiler or interpreter because that is how things evolved... it doesn't meant that is the only way things can be)
That extra indirection makes a big difference, it means you can't just do a asm { jmp $X; } into the code to run it. D has never been a scripting language, but it is partially interpreted (CTFE).
 2nd. What I mean is not the binary but the library code itself. Will it 
 only work on windows, for example. As I said, I want to use it for 
 embedded solutions and if it only works for specific platforms then it 
 is of no use to me and as if it didn't exist in the first place. This 
 means that whatever solution it does use is not tied in to phobos too 
 much nor the GC(ideally, not at all).
Oh it'll work on Windows, OSX, BSD and Linux without a doubt. But embedded has bigger problems then just what the library supports. Can you even compile for it? For example the only way to compile D to ARM is through gdc and ldc. So great you have the frontend running available to you on an ARM chip, but you can't use dmd's backend there as well. So no, this will not help you, in the embedded market. Unless of course you feel up to contributing a new backend ;)
Jan 29
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 30, 2018 at 04:31:43AM +0000, rikki cattermole via Digitalmars-d
wrote:
[...]
 D isn't a scripting language, it is native. It will always matter what
 OS/platform you are compiling to.
One could always hook the front end to a codegen that emits bytecode instead of native assembly. Who knows, perhaps there's already an LLVM codegen that does this, so all you have to do is to specify the right arch to ldc. The argument about asm{} is moot anyway because it's x86-specific. IIRC, gdc doesn't even support dmd's asm{} syntax; it uses its own gcc-specific asm syntax. In theory, even asm blocks can be translated into, say, LLVM IR, and then retargeted to whatever arch you one, including a VM. T -- To provoke is to call someone stupid; to argue is to call each other stupid.
Jan 30
parent Seb <seb wilzba.ch> writes:
On Tuesday, 30 January 2018 at 15:56:12 UTC, H. S. Teoh wrote:
 On Tue, Jan 30, 2018 at 04:31:43AM +0000, rikki cattermole via 
 Digitalmars-d wrote: [...]
 D isn't a scripting language, it is native. It will always 
 matter what OS/platform you are compiling to.
One could always hook the front end to a codegen that emits bytecode instead of native assembly. Who knows, perhaps there's already an LLVM codegen that does this, so all you have to do is to specify the right arch to ldc.
BTW -enable-dynamic-compile was part of LDC 1.7 https://forum.dlang.org/post/zwksmprgfnyukgsamfql forum.dlang.org (It's more suitable for JIT optimization though.)
Jan 30