[ZeroBrane Studio] Re: Debugger not breaking in external file with relative path
- From: Paul K <paul@xxxxxxxxxxxxx>
- To: "zerobrane@xxxxxxxxxxxxx" <zerobrane@xxxxxxxxxxxxx>
- Date: Tue, 29 Mar 2016 20:53:11 -0700
Hi Derek,
I cannot get the debugger to break at my breakpoints in an external file that
is contained in a parent directory (e.g. "../otherfile.lua")
Yes, it's because the file paths in the debugger are not normalized.
The breakpoint is set at \otherfile.lua, but the debug hook (and the
debugger) "sees" \SomeDir\..\otherfile.lua or something along those
lines.
Technically, it's possible to normalize the paths reported by the
debugger, but it needs to happen on every debug hook (as the
breakpoints need to be checked against normalized paths), which is
going to penalize every app. Maybe first check for "^../" or "/../"
and only then normalize to minimize the impact...
One way to avoid this is to use the absolute path instead of a
relative one. Another option is to set the project directory one level
higher. Yet another option would (potentially) be to configure the
debugger to always set breakpoints relative to the project directory,
but this would have the opposite effect of this not working for
absolute paths.
Maybe the IDE should set two breakpoints for files outside of the
project directory: one for the relative path and one for absolute (or
better have it done in the debugger itself). In this case the
de-normalization will only be done when the breakpoints are
set/removed. There are couple of challengers, but it looks doable at
the first glance. This is not going to help in the case when a
relative path (with ../) is used inside the project folder.
Basically, the breakpoint can only be set one way (using a normalized
path), but the same path can be reached in many different
(non-normalized) ways, which creates problems for the current
breakpoint matching logic.
I'm open to suggestions.
Paul.
Other related posts:
