August 08
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
August 08
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

August 08
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.

August 09
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?

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

August 09
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
August 10
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.
6 hours ago
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!
6 hours ago
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
Next ›   Last »
1 2 3