VSCode Harbour Extension Update

[Eric Lendvai]

I though I would share that I found the good fork for Antonino's VSCode Harbour extension, that supports debugging on multi-threading apps. 

https://github.com/ankerdata/harbourCodeExtension

They also converted the extension to Typescript.

I do my own build using:
1. Disable Antonino's version of the Harbour Extension
2. Build and install the vsix (extension) into VSCode
   cd  <FolderPathOfLocalRepo>
   npm run package
   code --install-extension <FolderPathOfLocalRepo>\harbour-extension.vsix --force
3. Ensure you fetch the latest 
   Open the VSCode command and search for: Harbour Get Debugger
   Use that prg as the debugger you include in your code.

Thanks team Ankerdata !

[fdaniele]

Thanks nr. Eric !

[Alex Strickland]

Hi Eric

I'm glad it is working well for you.

My colleague actually got it working with neovim first. As you can well imagine these days much of the work was done by Claude.

Please let me know if anything is not working for you and we'll see what we can do.

-- 

Regards

Alex

--
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: https://groups.google.com/group/harbour-users
---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/harbour-users/6156424d-b97d-42ae-982a-2cf2adac8980n%40googlegroups.com.

[jparada]

Hi, I compile with -b to include debug info.
With a simple .prg and request: "launch", I press F5, set a breakpoint on a line, and the debugger does not stop there unless I add an explicit AltD() in the code before that line. Once execution passes through AltD(), the breakpoint works normally.
My question: is this the expected behavior of this version (i.e., a session needs to be "armed" via AltD() before breakpoints become effective), or should it stop directly at the breakpoint without needing AltD()?
I want to confirm this before testing a more complex scenario (a multi-threaded server).

Thanks in advance.

Javier

[Alex Strickland]

Hi Javier

We deliberately removed the old behaviour where it stops on the first executable line because it was a pain for multiple threads.

It should stop at the first breakpoint and I did some experimenting and sometimes it does and sometimes it doesn't as I discovered when doing some tests last night. 

It is news to me that AltD() helps with that behaviour, so that is useful input thank you.

We (and Claude) need to check that out, don't hold your breath though :).

-- 

Regards

Alex

To view this discussion visit https://groups.google.com/d/msgid/harbour-users/88286d45-c9a8-454e-b7f4-f1228ff16db8n%40googlegroups.com.

[jparada]

Hi Alex,

Thanks for confirming, that's very helpful context. I'll keep testing on my end and will report back anything useful — please keep me informed too if you find anything on your side.

I also discussed this with Claude after your reply, here's a short summary of its take:

"Your response confirms the old shared-state behavior was removed deliberately for the multi-thread fix (TSD-based debug info), which matches what we found comparing the generated dbg_lib.prg between versions. The fact that it's inconsistent ("sometimes it does, sometimes it doesn't") suggests a race condition where the breakpoint is registered correctly via TCP, but the worker thread's debug context isn't initialized/synced in time to see it. AltD() likely works as a workaround because it forces that per-thread initialization manually — the same sync that's supposed to happen automatically (but doesn't always) when a breakpoint hits.

Practically: AltD() at the start of the function/endpoint you want to debug seems like the most reliable approach for now, until this gets a proper fix."

Thanks again for the quick reply!

Regards,
Javier