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/dmd/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

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

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

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.

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.

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!"

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 :/

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.

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.

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).