(Asking here before opening an issue.)
Source code locations are displayed during compilation, runtime, and help queries. For example,
julia> include("/tmp/foo.jl") # has a deprecated definition
WARNING: deprecated syntax "inner constructor Foo(...) around /tmp/foo.jl:2".
Use "Foo{T}(...) where T" instead.
julia> methods(mapslices)
# 2 methods for generic function "mapslices":
mapslices(f, A::AbstractArray, dims::AbstractArray{T,1} where T) in Base at abstractarray.jl:1787
mapslices(f, A::AbstractArray, dims) in Base at abstractarray.jl:1785
Packages that deal with source also report locations, eg Revise.jl.
Sometimes it is useful to parse these in the output, eg for highlighting and navigation. For example, I am doing this in julia-repl to make locations like above “clickable” in Emacs. I imagine that other IDEs may do the same.
Currently, the format these locations are printed in is not standardized. I have identified 3 forms (there may be others), parsed with these regexps.
I propose that we pick
- a standard format for displaying locations. My suggestion is
"at $fullpath:$lineumber", eg at /full/path/filename.jl:92.
(If someone wants to propose a different location format, a collection for pretty much every language ever can be found in Emacs.)
- Introduce a function to
Base that prints this format.
Open questions: do we need column number location printing, too? Should we just leave in the interface for it and default to 0 in the meantime?
I am not pushing for this before 1.0, since even though technically this is a breaking change, removing the two other formats and just keeping the one I proposed should be OK for tools which parse all 3. I just wanted to hear comments before opening an issue.
1 Like
As a datapoint, for the SimpleLogger https://github.com/JuliaLang/julia/pull/25111 we went with
@ $module $fullpath:$lineumber
which all base warnings now use.
One issue, I think simply $fullpath might not be good, because the path might have spaces (or other punctuation characters) in it (this is quite common on the Mac).
The fullpath really needs to be quoted, possibly only when certain characters are present in the it.
(Other than that technical issue, I think this is a very good idea!)
What I’d really like is for paths to always begin with either ./ or / on Unixes and .\ or X:\ on Windows. That would give you a defined beginning and end point for the path which makes extracting it significantly easier (and isn’t as ugly as quoting the string imho).
1 Like
AFAICT locations in v0.7 have an absolute path already (at least on Linux; I don’t use Windows so I cannot test that).
I am not sure about quoting, all I need is something that I can match with a regexp. It would be nice to have a solution which is both visually uncluttered (quotes aren’t IMO) and can be captured by a regexp; in theory spaces could be OK since the at[space] and the :line would bracket the whole thing. OTOH the : in the X:\ could cause problems without some regexp magic.
1 Like
No, because nothing prevents you from having something like: “/Users/Scott at Dynactionize/” as part of the path, or named “My Projects:2017”.
Yeah, I need to match that output as well (and for the same reason, IIRC 
).
According to the screenshots in the PR linked above you still get something like Warn @ Main testwarn.jl:22, which isn’t even a completly path.
I think \s(\.\/|\/) as the starting match should work, and as you said \:\d+ for the ending match. That coupled with a sufficiently greedy .+ in the middle should work pretty well imo.
1 Like
I think that’s a good idea (but you still need the quotes in some cases)
This would still need care, to make sure that : in the path is handled correctly.
Well, kinda: \s((?:\.\/|\/).+?)(\:\d+) for example seems to work fine if you assume there always is a line number appended, even for kinda tricky cases like /asd:asd/dsa:12:12.
Can you think of any cases where you’d need quotes of the top of your head?
2 Likes
Given that the MacOS command line requires names like that to be quoted, what’s wrong with quoting them?
(only in the cases where they have characters that require the quoting normally such as ‘#’, ’ ', ‘:’, etc.),
and it would be easier for people wanting to cut/paste that file name somewhere else.
I would prefer to do without quotes if feasible, since they increase visual clutter. They are perfect when the output is parsed, not so much when it is simply eyeballed.
In the cases where there are embedded spaces, or ‘:’ that might be followed by a number, I would say that without quotes, eyeballing something like Sebastian’s example is much more difficult.