[ZeroBrane Studio] Re: Remote debugging: IDE project path vs. actual file path
- From: Paul K <paul@xxxxxxxxxxxxx>
- To: "zerobrane@xxxxxxxxxxxxx" <zerobrane@xxxxxxxxxxxxx>
- Date: Thu, 23 Oct 2014 22:30:05 -0700
Hi Jan,
> Also, it ONLY works if the startdebug.lua file is open in ZBS and it MUST be
> the file currently viewed.
> It is as if the currently opened and VIEWED file influences the debugger
> significantly, which is really weird. I get that the project dir has an
> influence, but the currently VIEWED file? Probably a bug?
No, as far as I understand your setup, it's not a bug, but it needs an
explanation.
ZBS will generally doesn't care if the file is the current one or not
when searching for a file during debugging, as long as it's opened in
the IDE (if you want the IDE to also open files for you, there is
editor.autoactivate option).
However, this only works when the file name is known. For example, if
you run "lua.exe d:\foo\bar.lua", the interpreter reports
"d:\foo\bar.lua" as the file path, so the IDE knows exactly what file
to check for. However, in your case you load it as
"../../startdebug.lua", which is likely the path that IDE gets, but
when this path is combined with the project dir "..gamedir\scripts\",
the combined path is "..gamedir\scripts\..\..\startdebug.lua", so the
IDE checks for that file outside of "gamedir" folder and the file is
(obviously) not there. Then the IDE falls back to the last resort,
which is to check the name of the currently opened file and if it
happens to be startdebug.lua, it will happily assume that this is the
one you wanted to debug and remap the paths based on that information
(which probably makes the breakpoints to work in the case as well).
This is the same effect as can be achieved with the solution I sent
you earlier, which also avoid the need to startdebug.lua. Hope the
explanation sheds some light on what may be going on in your case.
Paul.
Other related posts:
