On Tuesday, 8 August 2017 at 08:03:05 UTC, Arjan wrote:
> Small request: could the setting "d.stdlibPath" be inferred from the compiler in use? DMD and LDC both have a conf file in which the paths are already set.

oh cool I didn't know that, is there a standard path to where these conf files are though?

> What about the debugging experience? Plans to integrate that as well?

Use my other extension `code-debug` (or `Native Debug`) for that

Am Tue, 08 Aug 2017 17:13:18 +0000
schrieb WebFreak001 <d.forum@webfreak.org>:

> On Tuesday, 8 August 2017 at 08:03:05 UTC, Arjan wrote:
> > Small request: could the setting "d.stdlibPath" be inferred from the compiler in use? DMD and LDC both have a conf file in which the paths are already set.
> 
> oh cool I didn't know that, is there a standard path to where these conf files are though?

The D frontend (and therefore all compilers) already has code to print the import paths. Unfortunately this code is only used when an import is not found:
------------------------------------------------------------------
test.d:1:8: Fehler: module a is in file 'a.d' which cannot be read
 import a;
        ^
import path[0] = /usr/include/d
import path[1]
= /opt/gdc/lib/gcc/x86_64-unknown-linux-gnu/4.9.4/include/d
------------------------------------------------------------------

It should be trivial though to refactor this code and add a command-line switch to dump the import path. See Module::read in dmodule.c. If Walter opposes adding this to DMD (one more command line switch!) we could probably still add it to GDC glue. This code is all you need:

if (global.path)
{
    for (size_t i = 0; i < global.path->dim; i++)
    {
        const char *p = (*global.path)[i];
        fprintf(stderr, "import path[%llu] = %s\n", (ulonglong)i, p);
    }
}


-- Johannes

On Tuesday, 8 August 2017 at 17:27:30 UTC, Johannes Pfau wrote:
> Am Tue, 08 Aug 2017 17:13:18 +0000
> schrieb WebFreak001 <d.forum@webfreak.org>:
>
>> On Tuesday, 8 August 2017 at 08:03:05 UTC, Arjan wrote:
>> > Small request: could the setting "d.stdlibPath" be inferred from the compiler in use? DMD and LDC both have a conf file in which the paths are already set.
>> 
>> oh cool I didn't know that, is there a standard path to where these conf files are though?
>
> The D frontend (and therefore all compilers) already has code to print the import paths. Unfortunately this code is only used when an import is not found:
> ------------------------------------------------------------------
> test.d:1:8: Fehler: module a is in file 'a.d' which cannot be read
>  import a;
>         ^
> import path[0] = /usr/include/d
> import path[1]
> = /opt/gdc/lib/gcc/x86_64-unknown-linux-gnu/4.9.4/include/d
> ------------------------------------------------------------------
>
> It should be trivial though to refactor this code and add a command-line switch to dump the import path. See Module::read in dmodule.c. If Walter opposes adding this to DMD (one more command line switch!) we could probably still add it to GDC glue. This code is all you need:
>
> if (global.path)
> {
>     for (size_t i = 0; i < global.path->dim; i++)
>     {
>         const char *p = (*global.path)[i];
>         fprintf(stderr, "import path[%llu] = %s\n", (ulonglong)i, p);
>     }
> }
>
>
> -- Johannes

Even better!
But when this is rejected,
one could also trigger it by feeding a deliberate wrong file to the compiler...
Another option is to build a simple hello.d with the -v flag which will reveal the location of the binary the location of the config file used and also the import paths and lib paths so it seems.

On Tuesday, 8 August 2017 at 17:13:18 UTC, WebFreak001 wrote:
> Use my other extension `code-debug` (or `Native Debug`) for that

Is there somebody who used it successfully on Windows?

On Wednesday, 9 August 2017 at 05:24:37 UTC, Dmitry wrote:
> On Tuesday, 8 August 2017 at 17:13:18 UTC, WebFreak001 wrote:
>> Use my other extension `code-debug` (or `Native Debug`) for that
>
> Is there somebody who used it successfully on Windows?

You mean the code-debug? No because there is at least one bug in the mago-mi, I once had a fix for it but seem not to have made it into a PR. Besides that bug(fix) I did run into other issues preventing succesfull use, unfortunately.

code-d yes works fine on windows though, as on linux, one must build dcd-server and dcd-client, dscanner, (dfmt) and put it in the search path or provide the locations to those executables in the settings file. (did not yet try the new code-d serve-d)

On Wednesday, 9 August 2017 at 07:22:36 UTC, Arjan wrote:
> You mean the code-debug?
Any debugging in Visual Studio Code on Windows.
Because I tried some times, but it just didn't work.

On Wednesday, 9 August 2017 at 12:25:55 UTC, Dmitry wrote:
> On Wednesday, 9 August 2017 at 07:22:36 UTC, Arjan wrote:
>> You mean the code-debug?
> Any debugging in Visual Studio Code on Windows.
> Because I tried some times, but it just didn't work.

try using the C/C++ Extension in vscode which uses the visual studio debugger, that one works great on windows for D

On Wednesday, 9 August 2017 at 14:39:12 UTC, WebFreak001 wrote:
> try using the C/C++ Extension in vscode which uses the visual studio debugger, that one works great on windows for D

OMG, it's really works. Thank you alot!
I'll try to use VSCode as main IDE for D code.

On Thursday, 10 August 2017 at 06:49:23 UTC, Dmitry wrote:
> On Wednesday, 9 August 2017 at 14:39:12 UTC, WebFreak001 wrote:
>> try using the C/C++ Extension in vscode which uses the visual studio debugger, that one works great on windows for D
>
> OMG, it's really works. Thank you alot!
> I'll try to use VSCode as main IDE for D code.

I got it working! Nice work so far except I no longer see any output in the extension Code Outline's[1] pane. It works fine in the other version of code-d. I know this functionality probably won't be a priority but in my opinion having the two extensions work together makes writing D code really sweet.

Thanks again!

On Saturday, 19 August 2017 at 05:11:13 UTC, Soulsbane wrote:
> On Thursday, 10 August 2017 at 06:49:23 UTC, Dmitry wrote:
>> On Wednesday, 9 August 2017 at 14:39:12 UTC, WebFreak001 wrote:
>>> try using the C/C++ Extension in vscode which uses the visual studio debugger, that one works great on windows for D
>>
>> OMG, it's really works. Thank you alot!
>> I'll try to use VSCode as main IDE for D code.
>
> I got it working! Nice work so far except I no longer see any output in the extension Code Outline's[1] pane. It works fine in the other version of code-d. I know this functionality probably won't be a priority but in my opinion having the two extensions work together makes writing D code really sweet.
>
> Thanks again!

And I forgot to link the extension: https://marketplace.visualstudio.com/items?itemName=patrys.vscode-code-outline