digitalmars.D - DMD as a library package can now run through all semantic phases
- Seb (47/47) Jan 26 2018 In case someone wants to play with DMD as a library, it got a lot
- timotheecour (11/58) Jan 26 2018 on OSX:
- Seb (8/19) Jan 26 2018 That's expected, but well DMD doesn't use semantic versioning
- timotheecour (8/19) Jan 26 2018 the bug is that homebrew dmd installs dmd.conf in
- timotheecour (4/12) Jan 26 2018 Actually an even more robust way to get the conf file:
- Jacob Carlborg (5/9) Jan 27 2018 Note that you don't *need* to use "findImportPaths". You can specify the...
- timotheecour (22/24) Jan 26 2018 prettyPrint produces valid D code except for template
- Seb (5/29) Jan 26 2018 Agreed, but prettyPrint:
- timotheecour (2/7) Jan 26 2018 filed https://issues.dlang.org/show_bug.cgi?id=18311
- rikki cattermole (4/59) Jan 26 2018 Is it possible to reset the compiler to the point of uninitialized/newly...
- rikki cattermole (168/172) Jan 29 2018 I have been toying with this idea.
- Jacob Carlborg (5/6) Jan 29 2018 There's a whole bunch of global variables that I think need to be reset....
- rikki cattermole (4/11) Jan 29 2018 Yes, there is a function the patch I added on here, with all the globals...
- Johan Engelen (5/7) Jan 27 2018 Very cool.
- Amorphorious (6/53) Jan 29 2018 What does this actually allow one to do besides parse d code and
- Bastiaan Veelo (4/5) Jan 29 2018 Better tooling is what comes to my mind. Imagine your editor to
- H. S. Teoh (8/14) Jan 29 2018 Being able to compile D code in your program (i.e., have an embedded D
- EntangledQuanta (11/25) Jan 29 2018 and can it do this? I didn't see anything in the docs that show
- rikki cattermole (6/32) Jan 29 2018 The backend still isn't fully D, so it won't be a goal short-term.
- Amorphorious (19/55) Jan 29 2018 Um, all scripting languages are native. Just because there is an
- rikki cattermole (12/67) Jan 29 2018 That extra indirection makes a big difference, it means you can't just
- H. S. Teoh (14/16) Jan 30 2018 One could always hook the front end to a codegen that emits bytecode
- Seb (5/13) Jan 30 2018 BTW
In case someone wants to play with DMD as a library, it got a lot
easier as of today.
Here's an example:
```
/+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 2018
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:
```
/+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 2018
Seb <seb wilzba.ch> 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 2018
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 2018
On Saturday, 27 January 2018 at 01:10:35 UTC, timotheecour wrote:On Saturday, 27 January 2018 at 00:47:01 UTC, timotheecourthe 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.dActually 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 2018
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 2018
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 2018
On Saturday, 27 January 2018 at 01:25:18 UTC, timotheecour wrote:On Friday, 26 January 2018 at 18:40:23 UTC, Seb wrote: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#L84Want 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 2018
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#L84filed https://issues.dlang.org/show_bug.cgi?id=18311
Jan 26 2018
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:
```
/+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 2018
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 2018
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 2018
On 29/01/2018 4:01 PM, Jacob Carlborg wrote:On 2018-01-29 13:53, rikki cattermole wrote: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 :/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.
Jan 29 2018
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 2018
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:
```
/+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 2018
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 2018
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: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!"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 2018
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: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.On Tuesday, 30 January 2018 at 00:21:09 UTC, Amorphorious wrote: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. TJust 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 2018
On 30/01/2018 4:21 AM, EntangledQuanta wrote:On Tuesday, 30 January 2018 at 02:04:30 UTC, H. S. Teoh wrote: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.On Tue, Jan 30, 2018 at 01:20:02AM +0000, Bastiaan Veelo via Digitalmars-d wrote: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)?On Tuesday, 30 January 2018 at 00:21:09 UTC, Amorphorious wrote: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. TJust 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.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 2018
On Tuesday, 30 January 2018 at 04:31:43 UTC, rikki cattermole wrote:On 30/01/2018 4:21 AM, EntangledQuanta wrote: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).On Tuesday, 30 January 2018 at 02:04:30 UTC, H. S. Teoh wrote: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.On Tue, Jan 30, 2018 at 01:20:02AM +0000, Bastiaan Veelo via Digitalmars-d wrote: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)?On Tuesday, 30 January 2018 at 00:21:09 UTC, Amorphorious wrote: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. TJust 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.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 2018
On 30/01/2018 5:45 AM, Amorphorious wrote:On Tuesday, 30 January 2018 at 04:31:43 UTC, rikki cattermole wrote: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).On 30/01/2018 4:21 AM, EntangledQuanta wrote: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)On Tuesday, 30 January 2018 at 02:04:30 UTC, H. S. Teoh wrote: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.On Tue, Jan 30, 2018 at 01:20:02AM +0000, Bastiaan Veelo via Digitalmars-d wrote: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)?On Tuesday, 30 January 2018 at 00:21:09 UTC, Amorphorious wrote: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. TJust 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.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.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 2018
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 2018
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: [...]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.)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.
Jan 30 2018