Interest regarding integration with DDK

[valentin-baron]

Hello, I develop the following VS Code Plugin: https://github.com/valentin-baron/delphi-devkit , which we actively use in my company that allows directly compiling, running and configuring Delphi Projects. Would you be interested in helping me integrate your extension?

[csm101]

Hi, I wasn't aware of your project: it seems very cool. I will start having a look at it this weekend.
Currently my debugger relies on my other delphi ex that is designed to jump from the delphi editor to visual studio code by. that one doesn't extend the Visual Studio Code experience in any way (meaning: it doesn't install any extension in vscode): it just:

1. creates a workspace file matching the current delphi project group
2. configures some "build tasks" for the projects in the project group (It does this step, but I actually always move back to delphi for building/compiling)
3. (since when I deployed this debugger) creates the "launch" configuration for the debugger for visual studio code, including the configuration for my debugger itself (mostly search paths)
4. opens visual studio code (or locates an already running instance opened on the same workspace) and opens in vscode the current file being edited in delphi and jumps the cursor to the same line.

what your extension does seems to be something I really miss in my workflow, so I will surely give it a look during this weekend (or when my spare time allows it) and see what can I do.

[valentin-baron]

Sadly I haven't tried out much of your extension either, because my company's apps are still Win32 and (from what I've seen) you haven't touched much of Win32 Debugger experience. If this were the case, I'd be happy to integrate it into my extension!

[csm101]

currently didn't touch win32 because our application makes non sense to be compiled 32 bit... well, yes, we still provide it compiled both ways, but we switched to testing it 64 bit because the 32 bit debugger is totally unusable due to the size of the executable and of the debug infos.

I plan to add support to Win32 just when I am totally satisfied of the win64 experience.

[csm101]

Ok, I started (well, claude code started...) working on implementing Win32 support for the debugger.

Meanwhile I opened 2 pull requests on your project:

1. the first pull request is to make also DPK/bpl projects runnable targets, exactly like the delphi IDE does: you can specify a "host executable" to be launched that will load in memory the bpl, so when you hit "run" on a bpl project the host executable will be launched. This is propaedeutic to the integration of the debugger, because this is exactly how you debug BPLs (including delphi design time packages: you set bds.exe as host executable)
2. the second pull request is a separate thing: it adds support for the official DelphiLSP embarcadero visual studio code extension. This extension expects a configuration file that normally is generated by the delphi ide (there is an option for having the ide generate this configuration file it buried inside the code insight configuration for delphi). This extension adds to your project the ability of generating automatically this configuration file without the need of using the delphi ide. It even re-generates the configuration file automatically when you switch between projects.

The second one is very helpful because it brings these feature inside the Visual Studio Code experience:

• Code Completion
• Intellisense
• Parameter Hints
• Mouse-Hover information
• Go to Definition (F12 or CTRL+click)
• Error Insight
• Contextual analysis of the project (revealing also code sections that won't be compiled because of $IFDEFs)

and the error insight output (that gets provided live, without having to wait for a compilation) is actively used by copilot

[valentin-baron]

I'm going to review the changes during this week.
I didn't know that there's a way to generate the DelphiLSP json file without the IDE (or rather, I haven't tried doing it on my own or analyzing it). I avoid using Delphi's native LSP anyways, because it just doesn't function properly with my company's main project (8m compiled lines of code).
I personally use Omnipascal's LSP currently and have actively been working on my own implementation of LSP, albeit it's still in rather early stages.
I don't see DelphILSP json-gen as a bad thing though!

P.S. I have seen some changes, and it seems that Claude or you didn't notice the dproj-rs crate and implemented raw dproj reading logic, which is completely unnecessary; check out https://github.com/valentin-baron/dproj-rs )

[csm101]

I didn't know that there's a way to generate the DelphiLSP json file without the IDE

Well... I just "reverse-engineered" its format. Now DDK generates it whenever you switch the active project. I had also to rethink the handling of the "problems" view in order to "merge" the errors when both DelphiLSP and the compilation phase produced the same errors.
Personally I prefer still DelphiLSP because it is based on the actual delphi compiler and, by doing so, it produces the very same error messages with the very same error codes of the real compiler: there is no drifting in the results. I am not happy about its speed, though, but at least I don't have to wait for the author of another Language Server to catch up with the new features of the language to be able to use them.

The integration with DelphiLSP is optional: if the extension is not installed, it should go back to the previous behavior.

[valentin-baron]

Personally I prefer still DelphiLSP because it is based on the actual delphi compiler and, by doing so, it produces the very same error messages with the very same error codes of the real compiler: there is no drifting in the results. I am not happy about its speed, though, but at least I don't have to wait for the author of another Language Server to catch up with the new features of the language to be able to use them.

At least it works for you... In our project it crashes around 50-100 times a day (that's at least the amount of crash logs it creates), so it's barely useable 😂
I should finish one of the code reviews today I believe, you'll get a notification.

[csm101]

Update: I am in the process of implementing Win32 support... stay tuned.

[csm101]

Ok, I just released the Win32 support, with several bugfixes and some improvements in the Visual Studio Code extension.
in the "call stacks" section you will notice a button that toggles a "raw mode" for a "brute force2 stack inspection that peeks all the contents of the stack checking for actual return addresses of known procedures. I did this because sometimes your code passes through procedures for which you don't have the debug info or sources and are compiled without generating proper stack frames... this allows you to discover all the history of calls that precedes such code. the idea is inspired by JCLDebug which has too a similar optional approach.
And there is also a check for new releases

[valentin-baron]

Alright, I will look into it when I figure out how to set up the extension and if I can aggregate it into DDK; Will let you know if I find problems!