I'm want to help for this project for use it in everyday development, but this thing is annoying a lot #32. And I want to help with it

@tomblind please look at this changes.

Really cool and useful, waiting for the review.

@A-Kovalev-Playrix First off, I think this is a great addition and fingers crossed it gets merged in.

I tried to get your branch with this working, in my case I'm using love2d and and calling lldebugger.pullBreakpoints() in love.update() which is called every frame.

However I still can't get breakpoints to be detected at run time =. To make sure I didn't make a mistake in the settings file/it's actually working, I manually set pullBreakpointsSupport default true in package.json (and did a clean npm run build; vsce package)...still no luck.

I know the debugger is configured correctly, because I can still set a breakpoint before launching Love, and the breakpoint will work.

But setting a breakpoint after Love launches still doesn't do anything. Any ideas on where I might troubleshoot?

In case it matters, I'm on Mac OS 12.6 running an arm m1 cpu. Maybe I'll try it on my Windows PC and see if I have more luck there, just in case it's some detail of how pipe communication works.

Hi @ianfitzpatrick! Thanks for your interest and support for this feature.

I have dug a little into Love2d and found 2 problems and fixed them. Hope that fixes will fix your case too. Could you try it one more time? In case if this does not help could you try to disable JIT with call jit.off() somewhere in the beginning for example right after lldebugger.start() and test it?

@A-Kovalev-Playrix Thanks so much for taking a look at it!

Well, progress sort of, I pulled in your latest changes and repackaged the extension, and now I'm now getting an error on launching debug:

[request] launchRequest

[request] configurationDoneRequest

[info] launching `"/Applications/love.app/Contents/MacOS/love" client` from "/Users/ianfitzpatrick/code/bee-game"

[info] process launched

[request] threadsRequest

[message] {"breakType":"step","threadId":1,"type":"debugBreak","tag":"$luaDebug","message":"step"}

[command] autocont
Error: ....local-lua-debugger-vscode-0.3.5/debugger/lldebugger.lua:1937: attempt to compare two nil values
stack traceback:
	[love "boot.lua"]:345: in function '__lt'
	....local-lua-debugger-vscode-0.3.5/debugger/lldebugger.lua:1937: in function 'pullBreakpoints'
	....local-lua-debugger-vscode-0.3.5/debugger/lldebugger.lua:1973: in function 'pullBreakpoints'
	main.lua:36: in function 'update'
	[love "callbacks.lua"]:162: in function <[love "callbacks.lua"]:144>
	[C]: in function 'xpcall'

Appears to be this line that is the issue:

if newPullSeek > lastPullSeek then

I tried both starting with and without breakpoints enabled, unfortunately in both cases I get this error. I also tried including and omitting jit.off()

Doubt it matters, but here are my main.lua and launch.json files.

https://gist.github.com/ianfitzpatrick/dd67547bd455de6bcedfaf2add7158fc
https://gist.github.com/ianfitzpatrick/3b35f83e77bc5f366e3f7648092b35d0

In launch.json, if I set "pullBreakpointsSupport": false then debugging goes back to normal, no crash on start (but obviously can't add breakpoints at run time).

Maybe looking for newPullSeek or lastPullSeek before they are initialized? Sorry troubleshooting a lua extension is a bit beyond me.

Unfortunately I have not tested Mac version before. Now I realized that there is no way to make non blocking pipe on macos neither linux. FIFO pipes on this platforms does not have seek support and raises error on use.

I did this through regular file instead of pipe with hope that seek is quiet cheap here. Now it should works.

@A-Kovalev-Playrix You're awesome, that fixed it, am now able to set breakpoints at runtime!

One side effect seems to be, the debugger continues to run after you end the lua program, forcing you to manually hit stop several times in the debugger to end the debugging session. Is that perhaps a side effect of file communication being laggy?

Other than that, works excellent. Thanks again.

@A-Kovalev-Playrix Just curious if the debugger stops for you correctly when you tell it to with this patch or not?

Still don't have enough time to look at the problem. I will try to find some time to investigation on next week.

And seems you are right it can be caused by this changes (especially if you have not noticed this before). Probably this happens because of not closed file descriptor. I thought that application close should close all opened file descriptors automatically maybe I was wrong about it

Sorry to bug you about it, appreciate your help whenever!

@ianfitzpatrick I have found the problem with hung on close and fixed it. I hope that was the same problem you have found. Could you check the fix?

@A-Kovalev-Playrix Ah rad, it works perfectly now! Thanks so much for this, it's really going to make a bunch of people's development lives so much better.

Hope this gets merged in 🤞🤞🤞. Meanwhile, going to package up and use this branch in vscode.

Thanks again!

@jemal As it doesn't refer to this PR I made separate PR for discussion with example in my repo here. Welcome to discuss it there.

Awesome job. Hoping for review soon 👍🤞

@tomblind any chance you can review this PR or assign write privileges to a trusted member of the community to move things forward?

@tomblind Please, your extension is great and works well for so many cases. Please accept this PR or comment on what is missing here. It is needed for full use of the debugger and we are waiting for the release with this feature 👍

Hi! Any updates here?

Does this also work for you guys, when develop source code path is different to executed source code?

I am coding in vscode and my git project ia stored in D:/prog/mod and the game is located in steam path like C:/../steamapps/common/../mod.

Looks like it's not reliable, when setting a breakpoint in D:. Any hints?

@Ismoh - did you notice what was discussed in #62? What worked for me was a case insensitive absolute path comparison...

Thanks for the hint. I'll take a look soon!

I finally managed to build the extension myself (it's as simple as "npm update" and run the <ctrl><shift><b> build command from VScode after clonig the repo), because I've also wanted to have the pull breakpionts support...

I've used @Ismoh's fork with builtin pullBreakpoints(), but can't get it to work. Breakpoints set while running seem not to get triggered. As far as I can see from the sources, it should only take two steps to make it work:

1. add the "pullBreakpointsSupport": true, to the launch configuration
2. call the lldebugger.pullBreakpoints() cyclically from my LUA code

Is there a chance, that somebody posts a quick howto or shares a sample config?

Thanks!

@ogsadmin

This is my .vscode/launch.json:

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Launch Noita with debugger",
      "type": "lua-local",
      "request": "launch",
      "program": {
        // "lua": "C:/Program Files (x86)/Steam/steamapps/common/Noita/noita_dev_log.exe",
        // "file": "C:/Program Files (x86)/Steam/steamapps/common/Noita/mods/noita-mp/init.lua",
        "command": "C:/Program Files (x86)/Steam/steamapps/common/Noita/noita_dev_log.exe",
        "communication": "stdio"
      },
      "args": ["-debug_lua", "-no-console", "-luadebugger"],
      "stopOnEntry": false,
      "cwd": "C:/Program Files (x86)/Steam/steamapps/common/Noita",
      // "env": {
      //   "LOCAL_LUA_DEBUGGER_VSCODE": "1"
      // },
      "verbose": true,
      "pullBreakpointsSupport": true,
      // "scriptFiles": ["${workspaceFolder}/mods/noita-mp/**/*.lua"],
      // "stepUnmappedLines": true,
      // "scriptRoots": ["${workspaceFolder}/mods/noita-mp/**/*.lua", "."]
    },
    {
      "name": "Launch LuaJITProfilerRunner.lua with debugger",
      "type": "lua-local",
      "request": "launch",
      "program": {
        "command": "lua.bat"
      },
      "args": ["-jp=a ${workspaceFolder}/mods/noita-mp/LuaJITProfilerRunner.lua"],
      "stopOnEntry": true,
      "cwd": "${workspaceFolder}/mods/noita-mp",
      "verbose": true
      "pullBreakpointsSupport": true,
    },
    {
      "name": "Launch unitTestRunner.lua with debugger",
      "type": "lua-local",
      "request": "launch",
      "program": {
        "command": "lua.bat"
      },
      "args": ["${workspaceFolder}/mods/noita-mp/tests/unitTestRunner.lua"],
      "stopOnEntry": true,
      "cwd": "${workspaceFolder}/mods/noita-mp",
      "verbose": true
      "pullBreakpointsSupport": true,
    }
  ]
}

The debugger is working fine for me, when debugging/starting a lua file, see unitTestRunner.lua config.

But when using the debugger inside of an exe, it's not working out of the box. I had to do the following workaround, but it still sometimes don't recognise breakpoints unfortunately:

1. require the lldebugger and run .start():

   -- Check if we wan't to debug the mod
   if DebugGetIsDevBuild() then
      if not lldebugger then
         lldebugger = require("lldebugger") -- or error("Unable to load debugger!", 2)
      end
      lldebugger.start()
      lldebugger.pullBreakpoints()
   end

2. Make sure to run lldebugger.pullBreakpoints() inside the games (or whatever) update or loop function.

I hope this helps!

Edit:
If the above isn't working, you need to overwrite the extensions files in vscode extensions directory, after you build it yourself.
Here are the files listed, I had overwritten.

@Ismoh

Thank you very much for your feedback - I actually found a nasty oversight in my build with the help of your comments (changing the package.json extension name without also changing it in extension.ts), however, still no success.

I've double checked the code copied into %appdata%/.vscode/extensions/myextension and also checked, that the lldebugger.start() and lldebugger.pullBreakpoints() functions are called correctly.

I can successfully run the debugger, the initial breakpoint (and other breakpoints set while in break) are working, but adding new breakpoints while running does not. Also strange: removing a breakpoint makes it vanish from the vscode breakpoint list, but it still triggered from the backend (when continuing debugging)...

I've setup a minimal project, so I can test - but even though debugging works in general, the pullBreakpoint() does not.

Here is my launch.json:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug Custom Lua Environment",
            "type": "lua-local",
            "request": "launch",
            "program": {
                "lua": "lua-5.1.exe",
                "file": "test.lua"
            },
            "args": [ ]
        }
    ]
}

And a minimal test.lua:

local lldebugger = loadfile(os.getenv("LOCAL_LUA_DEBUGGER_FILEPATH"))()
lldebugger.start()

while true do

	lldebugger.pullBreakpoints()
	print("Hello")

end

Any more ideas?

Thanks!

I've updated dependencies for vscode debugger, maybe it helps.
Ismoh#4

Create an issue on my fork. Feels like we're missusing this PR. @ogsadmin

@ogsadmin The problem seems to be in launch.json. Can you add "pullBreakpointsSupport": true ? This should help.

@A-Kovalev-Playrix I am too stupid - I've missed setting the flag, when creating the test configuration, sorry. The sample project and launch configuration are now working perfectly (I am using @Ismoh's fork )! Thanks for your help!

For reference, here is the correct, working launch.json:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug Custom Lua Environment",
            "type": "lua-local",
            "request": "launch",
            "program": {
                "lua": "lua-5.1-dyn.exe",
                "file": "test.lua"
            },
            "args": [ ],
            "pullBreakpointsSupport": true,
            "verbose": true
        }
    ]
}

For anyone finding this thread and wondering how to get it working with love2d, here's what I did

First, if this PR is still not merged, search for an extension called 'Second Local Lua Debugger' in the VSCode extension marketplace. That's a fork of this repo with this PR merged.

Next, setup your launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug Love",
            "type": "lua-local",
            "request": "launch",
            "pullBreakpointsSupport": true, // <- this setting is required
            "program": {
                "command": "love"
            },
            "args": [
                "${workspaceFolder}"
            ]
        }
    ]
}

In my main.lua I added this at the top

lldbg = false
if os.getenv("LOCAL_LUA_DEBUGGER_VSCODE") == "1" then require("lldebugger").start(); lldbg = true end

then in love.update

if lldbg then lldebugger.pullBreakpoints() end

Now I can run my little sample love2d app, add and remove breakpoints at runtime. Pause, step, inspect variables, add variables to the watch window. Ace.

Somewhere I also read you should set t.console = false but for me that was not required.