problems using the debugger after compiling with dmd (and ldc)

[iz0eyj]

OS: Windows 11 Hardware,: Core i7, 32GB RAM IDE: Idea 2024.1.4 Plugin: 1.34.1

D is truly amazing, I thought it was impossible to beat C with O3 optimization and Core i7 vector instruction set support... yet on a complicated set of vector-based algorithms (computationally complicated, not as algorithms ), D is a good 30% faster on the same code (1:1 porting). But... but I have to compile with Visual Studio Pro. For three reasons: A) I have never managed to make the plugin work, due to constant errors in the directories... the compiler doesn't work, the debugger doesn't work and even if I try to launch the executable from the IDE it tells me it can't find it! B) The Build control window states that everything went well without reporting errors... even if there are errors and therefore the compilation cannot have been successful. C) It is not possible to compile with LDC and DMD has a huge bug, which no one noticed.

I apologize if I don't provide a test case, but I wouldn't know how to produce it... I'm just too stupid to make it work. Let's be clear, it's not that the VS Pro extension is free from problems, it certainly has them, but at least it compiles, debugs and allows me to choose a compiler version that doesn't generate disasters.

Note that the problem is not related to this particular version of Idea, I just never managed to get it to work.

[rikkimax]

Windows definitely should work, although I haven't been able to use a debugger for it either (for that I use VS with VisualD which is superior to gdb).

LDC is not currently supported in the SDK, but that is ok, you don't have to compile with DMD just have a DMD SDK configured.

You can provide the compiler when building with dub, or go cli (scripts are supported as part of Intellij, I don't always build using the IDE either).

[iz0eyj]

@rikkimax Evidently you're better than me, which isn't at all strange given that I come from C and I'm bringing a big project of mine to D because I consider arguing with a language an excellent way to learn it. Nothing to me... simply there are enormous problems in setting the directories, and I don't understand where they should be declared. Of course I also looked for documentation on the Internet, but it seems that I am the only one in the world who has this problem. But, strange to say, this is the only language that doesn't work out of the box in Jetbrains IDEs.

You tell me that it is not essential to compile with DMD... but how? obviously I can do it from the command line, but how do I tell the IDE to employ LDC, since the plugin only supports DMD (and DMD simply doesn't work)? From the command line it would be really inconvenient, this project is REALLY big, and I feel like I'm back in the 80s, when we wrote operating systems with the vi and debugged them with printf :)

As far as debugging is concerned, I'm happy with gdb, but debugging is another strong point of Visual Studio (and of Embarcadero, which unfortunately doesn't support D).

However, problems with IDEs aside, I really like this language, it seems to me to be the natural object-oriented extension of C, much better than C++. I believe that if the development environments also worked well... :)

[rikkimax]

Okay so the SDK in this plugin provides access to the standard library files. You can ignore it for building if you are using a different compiler, but you still need to specify it. It does mean you can't use the plugin's "Run DMD compiler" configuration.

The SDK setup for dmd, will automatically detect the directories you don't have do anything other than point at it.

You will also need to provide some tools, dub which comes from the compiler, dscanner, dcd, dfmt and optionally gdb.

The VS-code plugin for D by the maintainer of those three tools do automatically install built versions for you, but they are easily compiled using dub.

The script I run to update mine automatically:

pushd DCD

git clean -fd
git fetch
git pull

dub clean
dub upgrade -s
DFLAGS="-O3" dub build --compiler=ldc2 --config=server --build=release
DFLAGS="-O3" dub build --compiler=ldc2 --config=client --build=release

popd
pushd dfix

git clean -fd
git fetch
git pull

dub clean
dub upgrade -s
DFLAGS="-O3" dub build --compiler=ldc2 --build=release

popd
pushd dfmt

git clean -fd
git fetch
git pull

dub clean
dub upgrade -s
DFLAGS="-O3" dub build --compiler=ldc2 --build=release

popd
pushd D-Scanner

git clean -fd
git fetch
git pull

dub clean
dub upgrade -s
DFLAGS="-O3" dub build --compiler=ldc2 --build=release

popd

The SDK issues are a known problem: https://github.com/intellij-dlanguage/intellij-dlanguage/pull/882

You can contact me and WebFreak who is the maintainer of those tools/code-d over on the D Discord server if you need any help relating to anything non-Intellij-plugin related: https://discord.gg/bMZk9Q4

Oh and welcome :)

[iz0eyj]

One thing at a time, the first problem is not in making it find the compiler but the directory in which the executable is generated. Apparently both the run command and the debugger expect to find the executable at a different point than where the compiler generates it, so that's what I can't figure out how to set. For example, the compiler correctly generates the .obj and .exe files C:\Development\Projects\IntelliJ\D\TestAVL\out\test\TestAVL, but then I can't start it (which is perfectly useless if the debugger doesn't work). I don't understand why if the compiler generates the output in a directory consistent with the project settings, both the run command and the debugger tell me they can't find it. Second problem, Build window output: There is an error in the currently loaded code (I provided it specifically for this discussion). On the left I see: TestAVL: build finished at 26/09/.. etc etc with a green tick (which suggests that everything went well)

To the right: Running 'before' tasks Checking sources Copying resources… [TestAVL] Running 'after' tasks Finished, saving caches… Executing post-compile tasks… Synchronizing output directories…

And best of all, the coolest thing is the notification: Build completed succesfully in 586 ms.

If I hadn't intentionally made an error I would go crazy trying to understand why, since everything went well, the output directory does not contain a TestAVL.exe :)

As for the VS Pro extension, it has problems in the automatic code completion part, but it worked first time for everything else. And it is also very convenient because it allows you to modify both the compiler and its flags at will.

[rikkimax]

It's likely that we haven't got the configuration setup working with the debugger support. I don't use it, so I'm of no help there.

I use dub, so I'm of no help for the other configurations.

It would be good if you could please post the screenshots of the configuration, and what happens when you run it.

[SingingBush]

I just tried this out with the latest version of the plugin on latest Intellij & Fedora Linux. There is a problem that needs sorting out so I'll take a look into fixing it. It's worth noting that this plugin has always primary focused on the use of dmd & dub. Prior to debugging any code you will need to ensure that dmd is configured correctly and that all imports are resolved. If it's a dub project then dependencies can be resolved by using the Process D Libraries option from the tools menu if they are not already detected.

Note that you can edit the run D app config to do a build stage before launch. See the following where I've configured the dub build to run before Intellij runs the built executable (I suspect the / at the start of the script path is causing the issue as I get a no such file error when running it). It's probably an issue in DlangRunAppConfiguration.java

There was some minimal documentation about debugging in both the wiki https://github.com/intellij-dlanguage/intellij-dlanguage/wiki/Debugger-Support and https://intellij-dlanguage.github.io but it's in need of an overhaul.

[SingingBush]

@iz0eyj some more changes are required to get the debugger working again which I think are worth doing as a separate ticket. If possible though could you pull the develop branch of this project and run ./gradlew runIde with Java 17 and see if you are able to get everything working as expected. You should be able to have a run configuration that builds your code first as described in my previous post. Using dub makes this process a lot easier.

Depending on when you pull the changes debugging may be working as well: https://github.com/intellij-dlanguage/intellij-dlanguage/issues/959#issuecomment-2197053765

[iz0eyj]

Apologies for the delay, but I rarely understand GitHub since I don't have any open-source projects.

The new version of the plugin is much better, thank you @SingingBush

I abandoned the existing old project, created a new DMD project, and replaced the small example file with my files. At this point, I had to specify that it is an executable in the sdl configuration file, because it had decided to compile as a library (which it is, but not the version I included in the project).

Now I can even compile with LDC, for which it was enough to add the path to the compiler to the targets (given its simplicity, it wouldn't be worth adding it to the plugin settings?). I also created two different builds specifying different output directories for debug and release in the sdl file... magic, everything works.

But no debugging, is there something else to set?

Launching GDB from the command line tells me that the symbols are not present in the executable file, and I don't know enough about the tools of this language to make them generate.

Another thing, in the configuration options (Shift + Alt + F10 -> Edit Configurations) it is possible to choose between build, run and test, so there is no option for simple debugging mode.

I also tried using settings similar to those in @SingingBush's post, but the plugin automatically sets a "script path" that is not compatible with my directory tree and does not allow me to change it.

I would be really happy to bring the project to Jetbrains IDEs... not that I don't appreciate Visual Studio, but I prefer to use it for C#, as well as Embarcadero for C, but it's difficult this way.

Thanks, Federico

[SingingBush]

Using ldc isn't currently supported. However, I was able to get it working with a little workaround. Firstly though, I think you need to put debug in the build options. Here's what I did to get it working for me:

It would also make sense here to control the destination build output because I found my binary in the root of the project and ended up needing to create some directories and moving the binary due to the run configuration expecting the output to be somewhere else (the script path should really be editable):

mkdir classes/production/<project name>
mv <binary name> classes/production/<project name>/<binary name>

Then I was able to use the debug option with the run config

[SingingBush]

I've decided to add some tooltips so that this is easier to use: https://github.com/intellij-dlanguage/intellij-dlanguage/assets/870567/67337828-1bc7-4314-8bf3-458f0b4a856e

Tooltip text will be based on documentation on https://dub.pm/cli-reference/dub-build/

[iz0eyj]

Hi @SingingBush, the first run is a compilation done with LDC, the second with DMD. I didn't touch anything in the program, I just changed the compiler in the project options... I guess you understand that LDC and GDB were pretty much on the same level :) Obviously the correct sequence is the one generated by LDC. Anyway now LDC compiles well, as you can see I had to specify the path because it can't find it on its own, but that doesn't matter at all.

Tomorrow I will try your suggestion, I would do it now but I am about to faint from tiredness (I stopped working on the code at eight in the morning... yesterday! If I continue at this pace I think I'll kick the bucket before I get to the first freeze.

Switching to the JetBrains environment would allow me to bring the D version of the software to Linux as well, while for now there is only the C version, which was actually the origin of everything and which has now become the secondary branch because in D I finally sense something capable of retiring it, which is not C++ or even Rust.

For now, thank you very much, I will let you know.

Thank you, Federico

[iz0eyj]

@SingingBush Hello, Would it be possible to enable the plugin for CLion too? Maybe nothing would change... or maybe the debugger would start working.

Thanks, Federico

[SingingBush]

We can't support CLion without significant changes to the codebase. Unfortunately Jetbrains removed packages from CLion that this project relies on. Annoyingly they were in place on early releases and it was possible to configure the plugin and compile projects but now it's broken significantly.

[iz0eyj]

@SingingBush Jetbrains has excellent products, but sometimes it makes choices that are difficult to understand, to say the least.