The trouble is that file names in stdlib methods are (inappropriate) absolute paths:
julia> ml=methods(edit)
# 5 methods for generic function "edit":
[1] edit(path::AbstractString) in InteractiveUtils at
/buildworker/worker/package_linux64/build/usr/share/julia/site/v0.7/InteractiveUtils/src/editless.jl:37
#etc.
julia> less(edit,(AbstractString,))
/buildworker/worker/package_linux64/build/usr/share/julia/site/v0.7/InteractiveUtils/src/editless.jl:
No such file or directory
We can cheat:
julia> ml.ms[1].file=Symbol("../site/v0.7/InteractiveUtils/src/editless.jl");
julia> less(edit,(AbstractString,)) # this works
This is troublesome for those of us who want to consult "The Real Documentation" but didn't build from source.
(edited to fit more useful issue title)
Note that this problem can be circumvented by locally rebuilding the system image.
If we want to kill this with a bazooka, see https://github.com/rust-lang/rust/issues/38322#issuecomment-294864626 and -fdebug-prefix-map
dup #21921 (probably)
The distinction from #21921 is that in out-of-tree builds stdlib
gets good file references but base
is problematic, whereas in official binary distributions it's the other way around. The file
fields for base
methods are handled specially, perhaps something similar could be done for stdlib
.
Thanks for making this a priority. It's kind of sad to see that this still is not fixed in 1.0.2.
Since this has been marked as priority, what are the chances that we'll have correct paths in 1.1.0? Can this be added in 1.1.1? Isn't it technically breaking? In my opinion this is really important and it'd be a shame if we'd had to wait for 4 more month.
Here is a quick monkey-patch you can do in ~/.julia/config/startup.jl
to fix it (originally https://github.com/tkf/InteractiveCodeSearch.jl/issues/3#issuecomment-440557571)
"""
Original `Base.find_source_file`.
"""
function _find_source_file_orig(path::AbstractString)
(isabspath(path) || isfile(path)) && return path
base_path = joinpath(Sys.BINDIR::String, Base.DATAROOTDIR, "julia", "base", path)
return isfile(base_path) ? base_path : nothing
end
function Base.find_source_file(path::AbstractString)
found = _find_source_file_orig(path)
if found isa AbstractString && ! isfile(found)
for m in methods(Pkg.add)
exfile = try
String(m.file)
catch err
continue
end
idx = findlast(joinpath(Base.Filesystem.path_separator,
"share", "julia"), exfile)
if idx isa Nothing
continue
end
prefix = exfile[1:idx[1]]
if startswith(path, prefix)
# e.g., relpath = "share/julia/stdlib/v0.7/..."
relpath = path[length(prefix)+1:end]
return joinpath(Base.Sys.BINDIR, "..", relpath)
end
end
end
return found
end
@tkf: This doesn't seem to work:
julia> using Statistics
julia> @which mean(rand(3))
mean(A::AbstractArray) in Statistics at C:\cygwin\home\Administrator\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.0\Statistics\src\Statistics.jl:128
It looks like which
does not call find_source_file
. My hack probably works only with @less
and @edit
. Also, not sure if it works in Windows.
Additional notes:
For LLDB, this can be corrected for by running settings set target.source-map /path/to/julia/build /path/to/julia/install
. For macOS, this can be automated by creating a small text file with the content described at http://lldb.llvm.org/symbols.html. Otherwise, it would need to be put in a ~/.lldbinit
file. On GDB, the equivalent command is set substitute-path /path/to/julia/build /path/to/julia/install
and also may be automated by creating a ~/.gdbinit
file or /usr/lib/debug/julia.gdb
file.
This still seems to be an issue (tried with v1.2-rc2 and v1.3, using the official binaries on 64-bit Linux). I guess this needs more than JuliaDebug/JuliaInterpreter.jl#144 and #31388 ?
Is there a chance to fix this in v1.2 or v1.3? It's possible to work around it (via symlink or so), I usually do, but that's kinda hard to sell that to novice users when introducing them to Julia (and showing them how easy it is to see how things work inside). :-)
JuliaInterpreter/Debugger seems to have their own fix for this. Would either of @timholy or @KristofferC possibly know if that fix could be used on base itself?
kinda hard to sell that to novice users when introducing them to Julia (and showing them how easy it is to see how things work inside)
+1 from me. The possibility to use @which
and co. in front of a class to show them how easy it is to inspect Julia internals is typically a "wow" moment. I really hope this gets fixed soon!
We could probably use the same trick here. Will try it out and report back.
Most helpful comment
+1 from me. The possibility to use
@which
and co. in front of a class to show them how easy it is to inspect Julia internals is typically a "wow" moment. I really hope this gets fixed soon!