Julia: Base에 ClearStacktrace.jl을 포함하려면 무엇이 필요합니까?

이것이 있으면 정말 좋을 것입니다. 또는 기본적으로 기본적으로 스택 추적 인쇄를 개선하는 축소된 버전일 수 있습니다.

모두 찬성입니다. 내가 이해하지 못하는 가장 중요한 것은 서명의 색상입니다. 그들은 무작위로 보입니다. 다른 요소를 더 쉽게 고를 수 있도록 다른 색상이 있는 것 같지만 조금 이상합니다. 색상 == 중첩 깊이는 어떻습니까? 제 생각에 가장 이상한 점은 예를 들어 Tuple{Symbol,Symbol} 두 개의 Symbol 가 다른 색상인 경우입니다.

정말 보고 싶은 것이 또 있습니다.

julia> foo(x::T, y::T) where T = error("whoops")
foo (generic function with 1 method)

julia> function bar()
           a = rand(3, 5)
           b = view(a, :, 2:3)
           c = reinterpret(Float32, b)
           foo(c, c)
       end
bar (generic function with 1 method)

julia> bar()
ERROR: whoops
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] foo(::Base.ReinterpretArray{Float32,2,Float64,SubArray{Float64,2,Array{Float64,2},Tuple{Base.Slice{Base.OneTo{Int64}},UnitRange{Int64}},true}}, ::Base.ReinterpretArray{Float32,2,Float64,SubArray{Float64,2,Array{Float64,2},Tuple{Base.Slice{Base.OneTo{Int64}},UnitRange{Int64}},true}}) at ./REPL[1]:1
 [3] bar() at ./REPL[2]:5
 [4] top-level scope at REPL[3]:1

하지만 이후

julia> m = first(methods(foo))
foo(x::T, y::T) where T in Main at REPL[1]:1

julia> m.sig
Tuple{typeof(foo),T,T} where T

우리가 같은 같은 항목 2를 인쇄 할 수 있어야한다 보인다

[2] foo(::T, ::T) where T = Base.ReinterpretArray{Float32,2,Float64,SubArray{Float64,2,Array{Float64,2},Tuple{Base.Slice{Base.OneTo{Int64}},UnitRange{Int64}},true}}

작은 의견이지만 나에게 현재 그것은 아마도 너무 많은 색상 "샐러드"일 것입니다. 스택 프레임 카운터는 파란색, 서명의 모든 다른 색상 등입니다. 기본 색상의 경우 지금까지 16가지 시스템 색상(8 + 8개의 밝은 색상)만 사용했으며 이로 인해 멋진 색상이 조금 더 어려워졌습니다.

전반적으로 좋은 제안. 내가 지금까지 색상을 선택한 이유는 다음과 같습니다.

숫자는 중요하기 때문에 파란색이므로 회색으로 표시해서는 안되지만 흰색으로 만드는 것은 함수 이름으로 주의를 끌기 위해 싸우는 것처럼 느껴졌습니다.

모듈은 주기에서 기본 색상을 사용합니다. 관련 모듈에 대한 추적을 빠르게 필터링할 수 있기 때문에 이것이 매우 유용하다고 생각합니다. 이것은 현재 스택 추적 형식과 매우 관련이 있습니다. 사람들이 원하는 것을 찾기 위해 가능한 한 적게 읽도록 강요되어야 한다는 생각입니다. (지금까지 학창시절에 주로 안구운동과 주의력 연구를 했기 때문에 그런 부분들이 중요합니다 ;) )

서명의 색상은 매우 논쟁의 여지가 있습니다. 위의 스크린샷에 있는 것들은 짙은 회색과 약간만 다르게 선택되었습니다. 동시에 다양한 의미 구성 요소를 식별할 수 있기를 원했습니다. 이것이 모든 유형 및 유형 매개변수(중괄호 및 쉼표)가 색상 전환을 일으키는 이유입니다. 세 가지 색상이 있다는 것은 같은 색상을 가진 두 개의 이웃이 없다는 것을 의미합니다. 거대한 활자 시그니처가 모두 흰색이면 한 단어를 구별하기가 매우 어렵다는 것을 알았습니다. 약간 다른 색조는 많은 도움이 되지만 시각적으로 모든 것을 조금 더 시끄럽게 만듭니다.

16색 세트는 짙은 회색과 약간만 다른 색을 가지고 있지 않기 때문에 베이스에 포함될 수 있는 것은 아닐 것입니다. 최근 업데이트에서 색상을 ANSI 세트의 약간 다른 3가지 회색 음영으로 교체했지만 그마저도 모든 곳에서 지원되지는 않을 것 같습니다.

아 역시 스택 프레임 색상과 모듈 색상은 물론 다크 그레이와 화이트도 모두 시스템 색상입니다. 여기에서 볼 수 있는 것처럼 렌더링하는 것은 내 특정 VSCode 테마일 뿐입니다.

이것은 좋은 것입니다.

인수 유형을 스캔할 때 종종 하나가 어디서 멈추고 다음이 시작되는지 파악하기가 매우 어렵습니다. 최상위 레벨을 다르게 색칠하는 것은 여기에서 매우 도움이 될 수 있으며 아마도 인수에 번호를 매길 수도 있습니다.

 [3] (_1::DataFrames.var#fun##309#"{ ...lighter... }, _2::NamedTuple{ ...lighter... }, _3::Int64})

methods(f) 인쇄에서 하는 것처럼 인수 이름을 표시할 수 있어야 합니다.

어때? 서명 색상을 짙은 회색으로 교체했지만 :: 는 흰색이므로 인수 유형이 시작되는 위치에서 두드러집니다. 위치 11의 유형 몬스터에게 특히 유용합니다.

좋아요. 인수 이름이 있으면 더욱 좋습니다.

"함수 - 모듈 - 인수" 순서가 레이아웃에 대해 잘 작동하지만 의미상으로는 실제로 의미가 없다는 것은 너무 나쁩니다. 하지만 해결책이 없습니다. 분명히 기능이 먼저 오는 것이 가장 좋습니다. 모듈이 파일 위치 이전에 다음 줄로 이동할 수 있습니까? 결국 위치의 일부입니다. 그러면 헤더도 필요하지 않을 수 있습니다.

숫자를 일반 텍스트로, 함수 이름을 굵게 및/또는 흰색으로 입력할 수도 있다고 생각합니다.

코드 경로 끝에 있는 파일 이름(및 줄 번호도 가능)이 더 밝은 색상을 가질 수 있습니까?

모듈이 파일 위치 이전에 다음 줄로 이동할 수 있습니까? 결국 위치의 일부입니다. 그러면 헤더도 필요하지 않을 수 있습니다.

이 제안으로 몇 가지를 시도해 보겠습니다.

코드 경로 끝에 있는 파일 이름(및 줄 번호도 가능)이 더 밝은 색상을 가질 수 있습니까?

물론 기술적으로 가능합니다 ;) 항상 더 나은 가시성과 주의를 끄는 소음 사이의 절충안입니다.

모듈은 함수의 전체 이름의 일부이므로 먼저 작성하지 않는 이유는 무엇입니까? 아마도 색상으로 Core.eval 등을 쓰는 것만으로도 충분히 명확하거나 여전히 열로 정렬될 수 있습니다. (아니면 이것을 시도했는데 끔찍해 보였을 수도 있습니다.)

정말 미친 생각입니다. 인수 유형을 인쇄할 때 한 줄 이상을 차지할 경우 서명을 접힌 형태로 인쇄한 다음 REPL.TerminalMenus 를 사용하여 뷰어가 확장할 수 있도록 합니다. 다음과 같은 것:

julia> run_command(args...)
    Function    Arguments              Location
[1] f           (x::Int, y::Float64)   MyModule1, /path/to/file1.jl: 15
[2] g          +(...)                  MyModule2, /path/to/file2.jl: 64
...

julia> lasttrace()
# presents the above in menu form, allowing user to expand line 2

관련 항목: #35915(접힌 트리 메뉴를 만드는 데 사용할 계획입니다. https://github.com/JuliaCollections/FoldingTrees.jl).

다음 순서로 재배열된 코드 경로를 사용하면 어떻게 보입니까? LineNumber 파일 이름 경로
그러면 눈은 추가 색상 없이 줄 번호와 파일 이름을 찾을 수 있는 안정적인 위치를 갖게 됩니다(저는 항상 세부 사항에 묻혀 있는 파일 이름과 줄 번호를 찾고 있는 것 같습니다. 알 수 있습니까?)
그리고 대화형 REPL 작업의 경우 위의 접힌 아이디어를 좋아합니다. :)

모듈을 먼저 작성하지 않는 이유는 함수의 전체 이름의 일부이기 때문입니다.

네, 아이디어가 마음에 듭니다. 색상 없이 시작했는데 잘 작동하지 않는 것 같습니다. 하지만 이렇게 하면 실제로 읽을 수 있습니다. 기둥이 눈을 안내하기 때문에 항상 좋지만 기둥을 사용하지 않고 다음으로 시도해 보겠습니다.

확실하지 않습니다. 함수 이름은 모듈보다 훨씬 더 중요한 정보입니다. 적어도 나에게 가장 중요한 정보는 확실히 함수 이름, 파일 이름, 줄 번호입니다. 또한 스크립트의 경우 왼쪽 열은 많은 Main 이거나 공백이므로 해당 사용 사례에 적합하지 않습니다.

스택 추적을 읽을 때 일반적으로 버그가 내 코드에 있기 때문에 기본/패키지 코드로 이동하기 전에 내 코드에서 마지막 호출을 주로 찾고 있다고 생각합니다. 따라서 이 경우 모듈은 매우 중요하고 함수 호출은 내가 먼저 스캔하는 것이 아닙니다.

이것은 어떤가요:

[1]  get_ticklabels   ::AbstractPlotting.Automatic, ::Int64
     in MakieLayout at ~/.julia/packages/MakieLayout/COfBu/src/lineaxis.jl:372

모듈 이름은 여전히 ​​정렬되어 있으므로 쉽게 스캔할 수 있습니다.

나는 실제로 그것에 가까운 것을 시도했습니다. 이번에는 함수 이름 자체에 색상을 지정하여 여전히 가장 눈에 띄지만 모듈 정보를 색상으로 전달합니다. 따라서 여전히 명백한 그룹화가 있지만 모든 모듈 이름에 덜 집중합니다.

처음으로 색상이 의미하는 바를 이해하려고 애쓰는 모습을 보았을 때 :joy: 모듈별 색상이 있는 경우 모듈 이름에 색상을 적용하는 것이 더 나은 것 같습니다.

모듈 이름이 마음에 듭니다. 이 최신 사진에서는 약간 손실됩니다.

그들이 바닥에 있다면 같은 밝은 색상으로 만들면 사물을 연결할 수 있습니까? (그리고 모듈 경계를 넘는 위치를 명확히 하십시오.) 그리고 아마도 모듈 이름이 경로에 나타나면 대신 거기에 강조 표시될 수 있습니다. 그러면 함수가 있는 왼쪽 가장자리에서 다채로운 이름이 이동합니다.

영감을 얻기 위해 마지막으로 stacktrace 형식을 조정할 때 나온 몇 가지 이미지를 게시합니다.

종종 정확한 패키지는 코드의 특성만큼 관심을 끌지 못합니다. 핵심 julia, 내가 사용 중인 라이브러리, 개발 중인 라이브러리 또는 스크립트입니까? core/base/dev/stdlib, packages, 현재 ]dev ed 패키지 및 나머지 모든 색상(스크립트/REPL 포함)의 4가지 색상을 가질 수 있습니다. 이러한 구분 중 일부는 매우 임의적이며 분류가 약간 부서지기 쉽지만, 이를 기반으로 하는 방법에 색상을 지정하면 (적어도 저에게는) 추가 텍스트를 표시하지 않고 정보를 최대화하고 작고 기억하기 쉬운 색상 세트를 유지합니다.

나에게 색상은 한 모듈의 코드가 시작되고 다른 모듈이 끝나는 경계 변경에 관한 것입니다. 그래서 나는 그들에게 본질적인 의미를 부여하지 않을 것입니다. 반면에 혼란스러울 수 있습니다.

모듈 열이 없으면 더 이상 유용하지 않기 때문에 더 단순화하려고 시도하고 열을 다시 제거했습니다. 그런 다음 먼저 모듈별로 줄 번호만 채색했지만 여전히 파일 이름이 보이지 않아 많은 의견이 중요하다고 말했습니다. 그래서 모듈 색상으로도 채색했습니다. 모듈 이름 자체는 함수 이름에 너무 가깝고 너무 시끄럽기 때문에 색상이 지정되지 않습니다.

다음은 숫자와 파일 이름이 모두 색칠된 버전입니다.

여기에 파일 이름이 없습니다.

전체 파일 경로를 색칠해 볼 수도 있습니까?

아이디어 좀...
파일 이름과 줄 번호를 일관성 있는 위치에 두어 공백을 두어 구분합니다.
스택 레벨 색상과 모듈 색상이 서로 일치하여 관련 라인을 시각적으로 쌍을 이룹니다.
파일 이름, 줄 번호 및 경로를 매개변수 유형과 약간 다른 색조로 표시하여 복잡하지 않게 구분합니다.

[이 예의 색상은 임의적이며 위치가 어떻게 관련되는지 더 많이 생각합니다.
예시에서 누락된 스택 레벨과 마지막 항목의 단축된 매개변수 유형 목록은 제가 예시를 직접 입력했기 때문입니다.]

누군가가 그것을 가지고 놀고 싶어하는 경우 위의 샘플을 생성하는 데 사용되는 코드:

function main()

    errors = [
              ("1", "get_ticklabels", ("AbstractPlotting.Automatic", "Int64"), "372", "lineaxis.jl", "MakieLayout", "~/.julia/packages/MakieLayout/COfBu/src")
              ("2", "get_ticklabels", ("AbstractPlotting.Automatic", "Int64"), "351", "lineaxis.jl", "MakieLayout", "~/.julia/packages/MakieLayout/COfBu/src")
              ("3", "#105", ("AbstractPlotting.Automatic",), "152", "lineaxis.jl", "MakieLayout", "~/.julia/packages/MakieLayout/COfBu/src")
              ("8", "OnUpdate", ("Tuple{Float32,Float32}",), "218", "Observables.jl", "Observables", "~/.julia/packages/Observables/0wrF6/src")
              ("9", "#setindex!#5", ("Observables.var\"#6#8\"",), "138", "Observables.jl", "Observables", "~/.julia/packages/Observables/0wrF6/src")
              ("10", "setindex!", ("Observables.Observable{Any}",), "126", "Observables.jl", "Observables", "~/.julia/packages/Observables/0wrF6/src")
              ("11", "#LineAxis#95", ("Base.Iterators.Pairs{Symbol,Observables.Observable,NTuple{28,Symbol},NamedTuple{(:endpoints, :limits, :flipped, :ticklabelrotation, :ticklabelalign, :lables
ize, :labelpadding, :ticklabelpad, :labelvisible, :label, :labelfont, :ticklabelfont, :ticklabelcolor}",), "270", "lineaxis.jl", "MakieLayout", "~/.julia/packages/MakieLayout/COfBu/src/lobjects")
    ]

    println()
    for (idx, err) in enumerate(errors)
        # Module color
        mc = idx <= 3 ? :light_red : (idx >= 7 ? :light_red : :light_yellow)
        # Path color
        pc = :blue
        printstyled("[", color=mc)
        printstyled("$(err[1])", color=mc)     # errorno
        printstyled("]  ", color=mc)
        printstyled("$(err[5])", color=pc)     # filename
        printstyled(":", color=pc)             # colon
        printstyled("$(err[4])", color=pc)     # lineno
        printstyled("  $(err[7])", color=pc)   # path
        println()
        printstyled("$(err[6]) ", color=mc)    # module
        printstyled("$(err[2]) ", color=:bold) # function
        printstyled("(", color=:light_blue)    # param types
        for t in err[3]
            printstyled("::", color=:white)
            printstyled("$t", color=:light_blue)
        end
        printstyled(")", color=:light_blue)
        println()
    end
end

이것의 문제는 이것이 Atom/VSCode 등에서 클릭 가능한 링크를 남겨두지 않는다는 것입니다. 이것은 제가 매우 자주 사용하는 것이며 다른 사람들도 마찬가지라고 생각합니다. 사실 클릭할 수 있도록 기본 경로를 명시적으로 확장하기도 합니다. 이것은 물론 더 많이 인쇄합니다. 하지만 활용도를 높이는 것 같아요. 몇 가지 바로 가기를 사용하여 REPL에서 번호별로 추적 항목을 스택으로 이동할 수 있는 방법이 있다는 것을 알고 있지만 이것은 내 생각에 링크를 클릭하는 것보다 훨씬 덜 직관적입니다.

행 정보가 로깅 시스템으로 인쇄되는 방식을 통합할 기회를 잡는 것이 합리적일 수 있습니다. 예를 들면 다음과 같습니다.

또한 로깅 시스템은 homedir을 축소합니다.

julia> include("foo.jl")
┌ Warning: foo
└ @ Main ~/julia/foo.jl:1

여기 제안서에는 두 가지 핵심 아이디어가 있다고 생각합니다.

• 서명과 별도의 줄에 줄 정보가 있어야 합니다(그리고 찾기 쉽도록 일부 색상으로 구분할 수 있음).
• 모듈을 표시합니다.

그래서 다음은 두 가지 아이디어 모두에 대해 약간 더 보수적인 시도입니다.

변수 이름이 추가되고 모듈 이름에만 색상이 지정된 버전(그렇지 않으면 @info 경로를 인쇄하는 방식과 일치함):

이것은 매우 긴 유형 서명을 가지고 있지 않지만 아마도 이와 같은 변수 이름을 갖는 것이(가능하다면?) 각 인수의 가장 바깥쪽 유형을 더 쉽게 찾아낼 수 있을 것입니다.

세 가지 수준의 중립(예: 굵게/보통/회색)을 사용할 수 있는 경우 파일 경로를 서명보다 더 가볍게 인쇄하는 것이(IMO) 함께 실행되는 것을 중지하는 좋은 방법인 것 같습니다. ( @info 도 마찬가지입니다.)

 허락하다
 printstyled("\njulia> ", 색상=:녹색)
 println("f()")
 printstyled("""오류: DimensionMismatch("A에는 치수(1,2)가 있지만 B에는 치수(3,4)가 있습니다.")""", color=:light_red)
 println("\n스택 추적:")
 열거(오류)의 (idx, err)
 mc = idx <= 3 ? :blue : (idx >= 7 ? :blue : :yellow) # 모듈 색상
 printstyled("[$(err[1])] ", color=:normal, bold=true) # errorno
 printstyled(err[2], color=:normal, bold=true) # 함수
 printstyled("(", color=:normal) # 매개변수 유형
 enumerate(err[3])에서 (i,t)에 대해
 i != 1 && printstyled(", ", 색상=:일반)
 printstyled(rand('a':'z')^2, color=:light_black)
 printstyled("::", 색상=:일반)
 printstyled("$t", 색상=:일반)
 끝
 printstyled(")", 색상=:일반)
 println()
 printstyled(" @ ", color=:light_black)
 printstyled(err[6], color=mc) # 모듈
 printstyled(" $(err[7])/$(err[5]):$(err[4])", color=:light_black) # 경로
 println()
 끝
 끝

여기 제안서에는 두 가지 핵심 아이디어가 있다고 생각합니다.

* Have the line info on a separate line from the signature (and perhaps delimited it with some color to make it easier to find).

* Show the module.

그래서 다음은 두 가지 아이디어 모두에 대해 약간 더 보수적인 시도입니다.

나는 이것을 좋아한다. 내 생각에는 "당신의 사랑을 죽여라"라는 용어가 있고 내 사랑이 색일 수도 있습니다. 그러나 나는 톤 다운 된 것이 어떻게 그렇게 기본적인 것에 더 적합 할 수 있는지 알 수 있습니다. 모듈 이름과 함수 이름이 일직선이 되도록 약간 변경했는데, 거의 기둥 모양의 세로 대비선이 생성됩니다. 관련 정보를 찾는 데 도움이 됩니다. 나는 여전히 유형을 흰색으로 두지 않을 것이라고 생각합니다. 왜냐하면 그들은 너무 지저분하기 때문입니다. 변수 이름이 있다면 흰색이 좋을 것입니다.

나는 이것을 좋아한다. 내 생각에는 "당신의 사랑을 죽여라"라는 용어가 있고 내 사랑이 색일 수도 있습니다.

내가 당신의 상황을 알고 있다는 것을 알기 위해 https://github.com/JuliaLang/julia/pull/18228. 이것은 자전거 세차장에서 매우 재미있는 주제이고 모두가 페인트 통을 가지고 있습니다. 보다시피 그 홍보도 꽤 야심차게 시작했지만 점점 보수적으로 변해가더군요 ㅎㅎ

나에게 마지막 제안은 확실히 현상 유지에 대한 개선입니다. 내가 생각하는 두 가지:

• 가능하다면 서명이 길면 서명과 섞이는 경향이 있기 때문에 라인 정보에 대한 일종의 "훅"이 있으면 좋을 것입니다.
• 스택프레임 번호가 10개 이상이면 정렬해야 합니다.
  [ 8] [ 9] [10] [11]
  등등. 그러면 @ 도 정렬됩니다.

나는 그것을 좋아한다. 나는 우리가 어딘가에 가고 있다고 생각한다. 색상에 신중을 기하는 것은 항상 좋은데, 그 이유는 자전거 이동을 위한 표면적이 덜 노출되고 다른 사람의 터미널에서 색상을 읽을 수 없는 위험이 감소하기 때문입니다.

간격을 두는 것은 좋지만 불행히도 f (...) 구문은 명시적으로 허용되지 않으므로 공백을 제거하거나 괄호를 제거해야 한다고 생각합니다.

가장 최근의 샘플은 일반적으로 좋아 보이지만 두 번째 아이디어는 다음과 같습니다.

가능하다면 서명이 길면 서명과 섞이는 경향이 있기 때문에 라인 정보에 대한 일종의 "훅"이 있으면 좋을 것입니다.

그리고 나는 그 고리가 다른 색이나 (바람직하게는) 밝기가 되기를 바랍니다.

모듈의 색상 주기를 수행할 수 있지만 스택 수준 번호의 양쪽에 있는 [ ]에만 적용할 수 있으므로 어떤 이유로 색상을 볼 수 없는 경우 손실이 많지 않습니다.

모듈의 색상 주기를 수행할 수 있지만 [ ]에만 적용할 수 있습니다.

대괄호만 있고 대조적인 부분에 있으면 색을 제대로 보기도 어려워서 잘 안 되는 것 같아요..

구문 f(...)는 명시적으로 허용되지 않습니다.

명암 차이 때문에 공간 없이도 잘 어울리는 것 같아요.

가능하면 라인 정보에 대한 눈에 일종의 "훅"이 있으면 좋을 것입니다.

동의합니다. 줄 번호를 회색으로 유지하지만 굵게 두는 것이 잘 작동한다고 생각합니다. 그러면 찾을 때 약간 눈에 띄지만 흰색으로 만드는 다음 단계는 제 생각에는 너무 시끄럽습니다.

스택 프레임 번호를 정렬해야 합니다.

귀하의 예와 같이 대괄호 안에 공백을 넣어 시도했지만 조금 이상해 보였으므로 이제 대괄호로 묶인 숫자를 올바르게 정렬하고 있습니다. 나는 그것이 꽤 잘 작동한다고 생각합니다.

다음은 이러한 모든 아이디어가 통합된 최신 버전입니다.

그리고 보너스로 여기에 (임의) 변수 이름을 사용하여 표시할 수 있는 방법이 있습니다. 다시 말하지만, 이 모든 변수 이름이 주의를 끌지 않아야 하기 때문에 굵은 회색을 사용하고 있지만 찾아보면 약간 식별할 수 있어야 합니다.

나는 이것이 어디로 가고 있는지도 좋아합니다. 모듈 이름을 강조 표시하기 위해 투표를 하고 싶습니다. 나는 실제로 같은 모듈이 같은 방식으로 색상이 지정되고 색상이 순환하는 스타일을 매우 좋아합니다(두 개의 스택 추적 선이 모듈 사이의 그래프 가장자리로 인접해 있다고 생각하면 여기에 그래프 색상 문제가 있습니다). 그러나 불행히도 그 색이 의미하는 바는 분명하지 않습니다. 모든 모듈 이름을 단일 색상으로 채색합니까?

이 정렬은 나에게 좋아 보인다.

나는 여전히 서명과 경로를 더 명확하게 구분하는 것이 중요도의 3단계인 이름/서명/경로를 구분하는 데 도움이 될 것이라고 생각합니다. 로깅 매크로 @info 등. 다른 줄보다 밝게 인쇄합니다.

변수 이름이 있으면 매우 좋습니다. 서명 정보보다 덜 중요하다고 투표하시겠습니까?

모듈 이름이 왼쪽에 정렬되어 있으면 스캔하는 데 도움이 되지만 색상이 바뀌는 것을 보니 안타깝습니다.

내 눈은 이것에서 물건을 찾을 수있는 곳을 알고있는 것 같습니다 :)
모듈 사이의 빈 줄이 너무 많은 수직 공간을 사용합니까?

2개의 다른 색상으로 행에 색상을 지정하여 대체 행이 동일한 색상을 갖도록 하면 표에서 자주 수행되는 것처럼 가독성에 도움이 될 수 있습니다.

모듈 이름 자체 대신 모듈 이름 옆에 있는 @의 색상 순환은 강조 표시된 함수 이름과 너무 많이 경쟁하지 않고 (@가 꽤 큰 문자이기 때문에) 눈에 띕니다.

매개변수 이름을 세어보지 않고도 올바른 매개변수 유형을 찾는 데 도움이 되기 때문에 매개변수 이름을 자주 원했습니다.

경로(및 그 옆에 있는 모듈 이름)가 유형과 밝기가 다를 수 있습니까? 매개변수 이름만 일치시킬 수 있습니까? (또는 이름을 유형보다 어둡게 만드는 mcabbott의 제안을 수행하는 경우 모든 저조도 함께)

다른 색상을 사용하는 것이 이상적이지만 로깅이 사용하는 것을 명시적으로 미러링할 수 있습니다.

for i in 1:3
    printstyled("┌[", color=:magenta, bold=true); print(i); printstyled("] ", color=:magenta, bold=true)
    printstyled("get_ticklabels", bold=true); print("("); printstyled("style", color=:light_black); print("::AbstractPlotting.Automatic, "); printstyled("n", color=:light_black); print("::Int64")
    i!=2 ? println(")") : begin print(", "); printstyled("xs", color=:light_black);  print("::Array{Float64,2}, ");  printstyled("ys", color=:light_black);  print("::Array{Float64,1}, ");  printstyled("yes", color=:light_black);  print("::Bool, ");  printstyled("no", color=:light_black);  println("::Bool)") end
    printstyled("└ @ ", color=:magenta, bold=true); printstyled("MakieLayout", color=:magenta); printstyled(" ~/.julia/packages/MakieLayout/COfBu/src/lineaxis.jl:372", color=:light_black); println();
end
<strong i="6">@error</strong> join([join(rand('a':'z', rand(1:9))) for _ in 1:25]," ") pi

편집: 이제 줄 바꿈이 되는 하나의 더 긴 줄과 그림이 있습니다.

로깅이 사용하는 것을 명시적으로 미러링할 수 있습니다.

내가 이것에 대해 그다지 좋아하지 않는 점은 특정 REPL 너비 때문에 거기에 있는 줄 바꿈이 창/REPL의 크기를 조정하면 잘 전송되지 않는다는 것입니다(예를 들어 더 긴 줄을 위한 공간을 만들고자 하는 경우) ) 또는 다른 너비의 창에 텍스트를 복사/붙여넣기

예, 나는 마커를 연속적으로 만들기 위해 명시적으로 줄을 끊는 것을 제안하지 않습니다. 사실 줄 바꿈된 선을 통과하여 다르게 보이게 하는 것이 좋을 수 있습니다. 주로 색상을 함수 이름에 묶는 방법과 가장 중요한 제목처럼 보이는 대신 테두리의 일부인 경우 덜 눈에 띄게 만드는 방법에 대한 생각입니다.

색상이 마음에 들었다고 해야하나 보수적인 성향을 이해합니다.

그러나 나는 다음과 같은 것 뒤에 내 지원을 던지고 싶습니다.

종종 정확한 패키지는 코드의 특성만큼 관심을 끌지 못합니다. 핵심 julia, 내가 사용 중인 라이브러리, 개발 중인 라이브러리 또는 스크립트입니까? core/base/dev/stdlib, packages, 현재 ]dev ed 패키지 및 나머지 모든 색상(스크립트/REPL 포함)의 4가지 색상을 가질 수 있습니다. [...]

저는 기본적으로 해킹을 하지 않고 패키지에서 거의 해킹하지 않기 때문에(대부분의 사람들이 추측하는 것처럼) 오류의 90%는 내 스크립트에서, 9%는 패키지에서, 1%는 기본에서 수정해야 합니다. 함수를 호출하는 데 실수를 한 경우 오류가 발생한 기반에서 정확히 알 필요가 없습니다. 어쨌든 수정하기 위해 거기에 가지 않을 것이기 때문에 코드를 수정해야 합니다.

따라서 대부분의 경우 그 이후의 모든 항목을 지금은 안전하게 무시할 수 있기 때문에 코드를 어디에서 남길지(그리고 패키지 코드를 어디에서 떠날지) 볼 수 있는 시각적 도우미에 감사드립니다. 색상이 아닌 경우 -------------------------------------------- 또는 무엇인가? 그 중 2-3개만 있어야 합니다.

모듈에 색상이 지정되면 기본/코어를 제외하고 색상을 지정하지 않아야 합니다.

나는 실제로 같은 모듈이 같은 방식으로 색칠되고 색상이 순환하는 스타일을 아주 좋아합니다.

나도 괜찮아. 많은 색상을 사용할 예정이라면 그 색상을 사용해야 한다고 생각합니다. 또한 수직 공간을 너무 많이 차지하지 않고 사용자와 패키지 코드 사이의 경계를 선택하는 데 도움이 됩니다.

모듈에 색상이 지정되면 기본/코어를 제외하고 색상을 지정하지 않아야 합니다.

네, 베이스와 코어는 항상 짙은 회색일 수 있습니다.

이것이 16가지 색상으로 완벽하게 작동하는 것을 포기한다면 모듈 이름의 해시를 만들어 일부를 기억할 수 있도록 하는 것이 좋습니다.

또는 기본/코어용과 외부 모듈용의 두 가지 색상만 있습니까?

현재 버전에는 6가지 비 회색조 옵션이 있기 때문에 색상을 순환하는 데 큰 문제가 없어야 한다고 생각합니다.

crayon"blue",
crayon"yellow",
crayon"red",
crayon"green",
crayon"cyan",
crayon"magenta",

밝은 변형도 있다고 생각하지만 VSCode(Material)의 색 구성표에는 더 어두운 형제와 동일하게 설정되어 있으므로 일부 구성표에서 발생할 수 있다고 가정합니다. 그러나 스택 추적이 6개 이상의 서로 다른 비기본 또는 비표준 라이브러리 모듈을 통과할 가능성은 얼마나 됩니까? 물론 패키지는 많은 모듈의 코드를 사용하지만 하나의 특정 스택에는 그렇게 많지 않아야 합니다. 적어도 스택 추적을 해독할 때 색상 충돌이 있더라도 큰 문제를 일으키지 않아야 합니다.

그런 다음 모듈 이름의 해시를 만들어 일부를 암기하는 것이 좋습니다.

이것은 실제로 일종의 훌륭합니다.

이 작업을 하는 사람들을 보니 반갑습니다.
함수 이름의 올바른 정렬이 어떻게 보이는지 알고 싶습니다.

 [1] get_ticklabels(code_lowered::...
 [2] get_ticklabels(real::AbstractPlotting
 [3] #105(mtime::
 [4] OnUpdate(vecormat::
 [5] #setindex!#5(atexti::

대

 [1] get_ticklabels(code_lowered::...
 [2] get_ticklabels(real::AbstractPlotting
 [3]           #105(mtime::
 [4]       OnUpdate(vecormat::
 [5]   #setindex!#5(atexti::
 [6]      setindex!(mapslices

많은 공간을 낭비하지 않으면서 함수 인수가 시작되는 위치를 파악하고 함수 호출 체인을 구문 분석하는 데 도움을 제공하는 것이 눈으로 더 쉬울 수 있습니다. 여전히 색상으로 지원해야 합니다. 그렇지 않으면 위치 정보와 인수가 모든 것을 익사시킬 것입니다.

그런 다음 모듈 이름의 해시를 만들어 일부를 암기하는 것이 좋습니다.

이것은 실제로 일종의 훌륭합니다.

오, 안녕, 짙은 청록색, 내 오랜 친구...

그런 다음 모듈 이름의 해시를 만들어 일부를 암기하는 것이 좋습니다.

나는 emacs가 IRC 닉네임에 대해 정확히 그렇게 하도록 했습니다. 몇몇 친구들이 같은 색을 할당받았기 때문에 잘 되지 않았고 무엇보다 혼란스러워서 결국 친구들을 위해 색을 하드 코딩하게 되었습니다. 나는 그 길을 따라가는 것을 권장하지 않지만 그것이 멋지다고 생각합니다. 각 코드 유형(예: Julia, 패키지, 개발 패키지, 사용자)에 대해 색상 집합을 줄이는 것이 더 유용해 보입니다.

나는 이것을 수행하는 편집기 색 구성표에 착륙했으며 적당히 유용합니다. 그렇지 않으면 파란색일 수 있는 모든 변수는 문자열 및 키워드 등이 다른 다양한 녹색 및 파란색 음영입니다. 아마도 이상적인 것은 당신이 제안한 것과 같은 광범위한 클래스 내에서 이와 같을 것입니다(예: 빨간색-보라색의 표준 라이브러리, 녹색-파란색으로 다운로드, 주황색-노란색으로 개발, 회색 기반). 또는 이것은 너무 많은 작업입니다!

또 다른 반복: 나는 모든 내부에 익숙하지 않기 때문에 모든 것이 나에게 아주 해키하게 느껴지지만 거기에 변수 이름을 가져오려고 했습니다. 색상을 어떻게 할당해야 하는지는 논쟁의 여지가 있지만 일반적으로 긍정적인 반응을 얻은 것 같아서 모듈을 다시 채색했습니다. 그러나 색상으로 인해 한 항목의 모듈이 다음 항목의 기능 이름과 약간 충돌하는 느낌이 듭니다. 그래서 줄 바꿈을 도입했습니다. 물론 모든 것을 더 길게 만들지 만 추가 호흡 공간과 선명도가 마음에 듭니다.

마지막 샘플이 마음에 듭니다. 매우 명확하고 읽기 쉽습니다. :)

아래는 모듈명 대신 "@"에 모듈색을 적용하여 함수명과의 충돌을 줄이고, 타입을 강조하여 공백을 넣지 않고도 경로를 좀 더 쉽게 구분할 수 있도록 하는 실험입니다. 윤곽.

@jkrumbiegel 멋지네요 . 내 인생에서 이것이 필요합니다.

나는 그 부드러운 블루스가 좋아

@jkrumbiegel 좋습니다 . @ 기호가 필요한지 잘 모르겠습니다. 기호가 없으면 더 깨끗해 보일 수 있습니다. 해당 정보가 무엇인지 설명하려면 Jeff가 제안한 대로 작성하는 것이 좋습니다.
in MakieLayout at ~/.julia/packages/MakieLayout/COfBu/src/lineaxis.jl:372

@jkrumbiegel 멋지네요 ! 파일 이름(전체 경로가 아님)과 줄 번호만 강조 표시하는 방법이 있습니까? 조금 더 밝은 그레이?

사랑스러운! 저는 실제로 줄 바꿈을 정말 좋아합니다. 시각적으로 정말 도움이 되며 스택 추적이 너무 길어 어쨌든 스크롤해야 하는 경향이 있습니다. 스크롤을 약간 줄이는 것보다 명확한 것이 좋습니다.

강조 표시된 :: 는 훌륭합니다. 문자 위치에 대해 매개변수 목록의 각 문자의 정보 내용을 보여주는 곡선을 그려야 하는 경우 :: 는 해당 곡선의 로컬 최대값을 정확히 표시합니다. 이름은 왼쪽으로, 유형의 가장 중요한 부분은 오른쪽으로 볼 줄 압니다. 그 후에는 정보 콘텐츠만 삭제됩니다.

나는 이 의견에 동의하지 않습니다. 강조 표시는 중요한 것을 강조하여 눈이 무엇을 읽을지 알 수 있도록 해야 하며 :: 확실히 내가 읽어야 할 중요한 것은 아닙니다. 그대로 두면 흰색이 대담한 짙은 파란색보다 훨씬 더 눈에 띕니다. 매개변수를 구분하는 것은 인수 이름을 흰색으로 하면 더 명확해집니다(아마도 명명된 인수가 없는 경우를 제외하고, 이 경우 :: 는 인수를 구분하기 위해 흰색으로 표시될 수 있음). 줄 번호도 마찬가지입니다. 줄 번호보다 파일 이름을 강조하고 싶습니다.

색상이 지정된 패키지 이름은 가장 중요한 기능 이름을 가릴 위험이 있지만 굵은 글꼴과 줄 바꿈으로 된 패키지 이름은 이러한 위험을 실제로 제한합니다. 잘했습니다!

하얗게 만들기 전에 ::에 대해 많이 생각했습니다. 물론 인수 이름과 유형은 실제 정보이므로 강조 표시되어야 한다고 생각할 수 있습니다. 그러나 그것들을 강조할 때 나의 강한 인상은 그것들이 당신의 주의를 요구한다는 것입니다. 그러나 모든 이름과 유형을 읽는 것은 중요하지 않습니다. 특정 기능에서 원하는 것을 찾을 수 있어야 합니다. 스택 추적을 읽는 단계를 보는 방법:

1. 일반 개요 보기
2. 어떤 모듈에서 오류가 발생한 기능은 무엇입니까?
3. 다른 모듈에서 이 기능을 호출한 다른 기능은 무엇입니까?
4. 내 코드와 기본 또는 다른 패키지 코드 사이에 중요한 경계가 있습니까? 어디야?
5. 그 경계에는 어떤 기능이 있습니까?
6. 어떤 유형/인수가 사용되었습니까? 한 주장은 어디에서 끝나고 다음 주장은 시작됩니까? 이것은 현재 긴 매개변수 유형에서 특히 어렵습니다.
7. 그것이 오류를 설명합니까?
8. 이것이 도움이 되지 않으면 가는 빗으로 모든 것을 처리하십시오.

따라서 유형/인수 정보는 일반적인 구조를 파악하고 이해한 후에만 사용하는 것이 제 생각입니다. 강조 표시에 대해 이해해야 할 한 가지는 강조 표시가 상대적으로 드문 경우에만 항목을 더 쉽게 찾을 수 있는 것은 아니라는 것입니다. 그래서 :: 강조표시가 방해가 되지 않고 변수/유형 정보를 찾기 시작할 때까지 주의를 끌 수 있다고 생각합니다. 그리고 그 단계에서 더도 그 이하도 아닌 점프할 수 있는 눈의 고리를 제공합니다. 나는 그것이 매우 효율적이라고 생각합니다.

참고로 모든 인수에 이름이 있는 것은 아니므로 변수 이름을 강조 표시해도 항상 잘 구분되는 것은 아닙니다. :: 항상 있는 것 같아요.

좋은 목록인 것 같습니다. 제 주요 불만 사항은 긴 유형 서명의 공백을 찾는 6번 항목입니다. :: super-bright를 인쇄하면 도움이 되지만 약간 이상하다는 데 동의합니다. 인수 이름(또는 없는 경우 일부 _1 자리 표시자)을 인쇄하면 약간의 도움이 됩니다. 아마도 가장 바깥쪽 유형을 정상적으로 인쇄한 다음 모든 인수를 회색으로 인쇄하는 것이 많은 도움이 될까요?

실제로 사용할 수 있는 강조 표시 수준은 몇 개입니까? :white 는 밝은 배경에서 눈에 띄지 않을 것입니다. 사실 일반, 볼드 및 :light_black (색상 추가)로 제한될 수 있습니다. 지금은 함수 이름과 경로가 굵게 표시되어 있습니다. @error 등의 경로는 light_black이며 훌륭해 보입니다.

나는 모듈을 강조하기 위해 색상을 사용하는 것을 좋아합니다. 위의 샘플 중 일부에서는 다른 텍스트보다 더 빛나지만 단순한 색상에서도 이것이 사실입니까? 몇 가지 다른 테마에서 여기의 "모듈"은 상대적으로 음소거되었습니다(그리고 ::Array, ::Adjoint, ::Int 분명히 최상위 서명).

    printstyled("\nfunction", bold=true); print("(x::Array"); printstyled("{Float64,1}", color=:light_black); print(", y::Adjoint"); printstyled("{Float64,2,Array{Float64,2}}", color=:light_black); println(", z::Int64)")
    printstyled(" @ ", color=:light_black); printstyled("Module", color=:blue); printstyled(" ~/.julia/dev/Package/src/Package.jl:33 \n", color=:light_black)
end

또 다른 반복: 나는 모든 내부에 익숙하지 않기 때문에 모든 것이 나에게 아주 해키하게 느껴지지만 거기에 변수 이름을 가져오려고 했습니다. 색상을 어떻게 할당해야 하는지는 논쟁의 여지가 있지만 일반적으로 긍정적인 반응을 얻은 것 같아서 모듈을 다시 채색했습니다. 그러나 색상으로 인해 한 항목의 모듈이 다음 항목의 기능 이름과 약간 충돌하는 느낌이 듭니다. 그래서 줄 바꿈을 도입했습니다. 물론 모든 것을 더 길게 만들지 만 추가 호흡 공간과 선명도가 마음에 듭니다.

주제에서 조금 벗어났을 수도 있지만 이것이 있기 때문에 methods 및 methodswith 의 출력에 대해 더 예쁜 show 를 가질 수 있습니까? 고통이기도 하다.

또한 모듈의 색상은 정확한 노란색이 아니라 회색-노란색과 같이 흐릿한 색상일 수 있습니다. 또는 startup.jl 와 같이 해당 색상을 구성할 수 있습니까?

@jkrumbiegel 멋지네요 ! 파일 이름(전체 경로가 아님)과 줄 번호만 강조 표시하는 방법이 있습니까? 조금 더 밝은 그레이?

https://github.com/JuliaLang/julia/issues/36026#issuecomment -634481656일 수 있습니다. 그러나 파일 이름이 경로의 일부이기 때문에 약간 이상한데 왜 다른 색상을 사용합니까? 일반적으로 경로를 클릭하기만 하면 VSCode가 파일을 열어주므로 파일 이름은 중요하지 않습니다.

이제 실제로 더 이상 복잡한 색상을 사용하지 않기 때문에 Crayon.jl을 사용하지 않게 되었습니다. 패키지 로드 시간에도 도움이 됩니다. 짙은 회색으로 밑줄을 쳐서 시각적으로 압도적이지 않으면서 파일 이름과 줄 번호의 가시성을 높이는 방법을 찾았습니다. 우리가 밑줄이 그어진 경로/링크에 익숙하기 때문에 그것도 합리적으로 보입니다. 흰색 또는 기타 강조 표시는 너무 강하고 굵게는 너무 약했습니다.

또한, 나는 처음에 했어야 하는 사이클러의 첫 번째 색상으로 밝은 색상으로 전환했지만 내 테마에서 동일하게 보이기 때문에 전혀 눈치채지 못했습니다. 이것은 진한 파란색이 거의 보이지 않는 테마에 더 좋습니다(테마의 잘못임).

이 스타일을 ClearStacktrace.jl 에 버전 0.2로 등록했기 때문에 조금 더 시도해 볼 수 있습니다.

두 가지 예:

정말 좋은 작품입니다.
매개변수 이름은 더 밝게 하고 유형은 더 어둡게 합니다. 유형이 더 밝고 이름이 더 어둡게 하는 것보다 그런 식으로 더 잘 보이거나 더 잘 읽히는 것으로 나타났습니까?

예, 일반적으로 유형이 훨씬 더 길기 때문에 더 가볍게 만드는 데 도움이 되지 않습니다.

무작위 생각:

• 같은 모듈에 있는 스택 추적 항목 그룹 간의 수평 규칙이 아닐까요? 어쩌면 너무 바쁜 찾고
• 오류 메시지와 명확하게 구분하기 위해 스택 추적의 맨 위에도 좋을 수 있습니다.

이 모든 것이 지금 우리가 가지고 있는 것보다 훨씬 낫습니다...

이제 실제로 더 이상 복잡한 색상을 사용하지 않기 때문에 Crayon.jl을 사용하지 않게 되었습니다. 패키지 로드 시간에도 도움이 됩니다.

상당한 로드 시간이 발생했습니까? 그것은 나를 위해 꽤 빨리로드됩니다.

julia> <strong i="8">@time</strong> using Crayons
  0.014410 seconds (22.60 k allocations: 2.274 MiB)

이 버전은 훌륭합니다. 이것을 Base에 넣겠습니다.

동의: 그냥 마지막 버전으로 합시다.

@jkrumbiegel 여기에서 모든 작업을 수행해 주셔서 감사합니다. 우리가 시험해 볼 수 있는 버전이 있다는 것은 좋은 일입니다...

그리고 포크: rand(5) .* rand(7) 플러스 오류가 35줄을 차지한다는 점이 조금 걱정되는 것 같은데요? 그래서 https://github.com/mcabbott/ClearStacktrace.jl/tree/milder 를 만들어 https://github.com/JuliaLang/julia/issues/36026#issuecomment -635294818에 더 많은 색상이 있습니다.

현재 스택 추적 인쇄에서 해당 예의 프레임 8-11은 표시되지 않습니다(REPL의 일부이며 모든 REPL 스택 추적에 있음).

실제로 이것은 훌륭하게 개선되었습니다. 그러나 여전히 8줄(스택 추적만 해당)에서 20개(ClearStacktrace 0.2)로 이동합니다. 그것이 얼마나 예쁜지와 당신의 자리를 잃지 않는 것 사이에는 약간의 절충점이 있습니다.

경로는 또한 자료에서 훨씬 더 컴팩트하게 인쇄됩니다 ./broadcast.jl:495 대신 //Applications/Julia-1.5.app/Contents/Resources/julia/bin/../share/julia/base/broadcast.jl:495 ,이 또한 빈 라인에 대한 필요성을 감소시킬 것이다.

기본 경로는 클릭할 수 있도록 의도적으로 확장됩니다. ClearStacktrace에서 비활성화할 수 있습니다. 개행을 좋아하지 않는 사람들을 위해 개행을 선택 사항으로 만들 수도 있습니다. 환경 변수 일 수 있습니다.

그리고 절대 변경되지 않는 마지막 몇 프레임을 잘라내는 기능의 일부를 복사하는 것을 놓친 것 같습니다.

이제 실제로 더 이상 복잡한 색상을 사용하지 않기 때문에 Crayon.jl을 사용하지 않게 되었습니다. 패키지 로드 시간에도 도움이 됩니다. 짙은 회색으로 밑줄을 쳐서 시각적으로 압도적이지 않으면서 파일 이름과 줄 번호의 가시성을 높이는 방법을 찾았습니다. 우리가 밑줄이 그어진 경로/링크에 익숙하기 때문에 그것도 합리적으로 보입니다. 흰색 또는 기타 강조 표시는 너무 강하고 굵게는 너무 약했습니다.

또한, 나는 처음에 했어야 하는 사이클러의 첫 번째 색상으로 밝은 색상으로 전환했지만 내 테마에서 동일하게 보이기 때문에 전혀 눈치채지 못했습니다. 이것은 진한 파란색이 거의 보이지 않는 테마에 더 좋습니다(테마의 잘못임).

이 스타일을 ClearStacktrace.jl 에 버전 0.2로 등록했기 때문에 조금 더 시도해 볼 수 있습니다.

두 가지 예:

이 이유에 대한 호기심 여분 / 에서 //Applications/Julia-1.4.app/ ?

경로 분할 및 재결합의 버그일 수 있습니다.

이제 실제로 더 이상 복잡한 색상을 사용하지 않기 때문에 Crayon.jl을 사용하지 않게 되었습니다. 패키지 로드 시간에도 도움이 됩니다.

상당한 로드 시간이 발생했습니까? 그것은 나를 위해 꽤 빨리로드됩니다.

julia> <strong i="9">@time</strong> using Crayons

  0.014410 seconds (22.60 k allocations: 2.274 MiB)

아니요, 베이스에 없을 것 같아서 대부분 제거했어요 :) 로딩 시간은 추측일 뿐입니다.

https://github.com/JuliaLang/julia/issues/36026#issuecomment -636912686 과 같이 스택 추적 프레임이 많으면 빈 줄이 너무 많을 수 있습니다.

토론을 방해하지 않기 위해(마지막 버전은 훌륭하고 큰 개선 사항입니다) 너무 많은 줄 바꿈에 대한 주제에서 문제는 터미널에서 작업할 때 스택 추적을 "역전"으로 인쇄하는 것이 훨씬 더 나은 것처럼 보입니다. 나는 원래 https://github.com/JuliaLang/julia/pull/18228)에서 다음과 같이 제안했습니다.

...
[3] frame
[2] frame
[1] frame
Error: Some error happened
blah blah

가장 중요한 정보는 오류 메시지 자체와 스택 상단(오류에 가까움)을 향한 프레임 및 스크롤 없이 항상 볼 수 있는 순서대로 인쇄하는 것입니다. 지금은 스택 추적의 꼬리뿐만 아니라 오류 메시지를 보기 위해 위로 스크롤해야 하는 경우가 많습니다.

그러나 터미널에서 복사하여 붙여 넣은 웹 사이트의 스택 추적을 읽을 때 터미널에서처럼 위에서 아래로 스크롤하는 것이 아니라 위에서 아래로 스크롤하기 때문에 반대 순서를 원합니다. 이 두 가지 경우에 모두 좋은 디자인입니다.

그러나 터미널에서 복사하여 붙여 넣은 웹 사이트의 스택 추적을 읽을 때 터미널에서처럼 위에서 아래로 스크롤하는 것이 아니라 위에서 아래로 스크롤하기 때문에 반대 순서를 원합니다. 이 두 가지 경우에 모두 좋은 디자인입니다.

나는 실제로 마지막 스택 추적을 다시 인쇄할 수 있는 잠시 동안 ClearStacktrace.jl 에 코드를 가지고 있었습니다. 나는 매우 긴 유형을 일부 최대 문자로 자르고 전체 정보가 필요한 경우 전체를 다시 인쇄할 수 있다고 생각했습니다. 그러나 사용 사례도 흥미로울 것입니다. reprint(inverted = true) 또는 reprint(html = true) 를 상상할 수 있습니다. 웹 사이트에 붙여 넣을 때 색상을 유지하는 html 버전을 인쇄합니다.

또한 스크롤 방향이 주어지면 기본적으로 전체를 뒤집는 것이 합리적일 수 있다는 데 동의합니다.

ipython 는 프레임을 반대 순서로 인쇄하고 스크롤할 필요가 없음에도 불구하고 항상 설명할 수 없을 정도로 혼란스러웠습니다. 아마도 그것은 가장 안쪽 프레임이 맨 위에 있는 gdb 및 기타 시스템에 대한 나의 이전 경험 때문이거나 다른 사람들도 그렇게 느낄 수 있습니까?

gdb에 대해 말하자면, 그들은 호출기로 매우 긴 추적에 대한 합리적인 솔루션을 가지고 있습니다. "더 많은 프레임을 보려면 Enter 키를 누르십시오".

그건 그렇고, 나는 https://github.com/JuliaLang/julia/issues/36026#issuecomment -636912686의 최신 시각 디자인을 좋아하고 우리가 그것을 병합한다면 매우 기쁠 것입니다. 프레임 순서를 변경하거나 대화형 기능을 추가하는 것은 별개의 문제처럼 보입니다.

파일 이름과 관련하여 나는 우리가 결국 터미널 하이퍼링크 OSC 시퀀스를 사용할 수 있기를 희망합니다( 예, 터미널의 하이퍼링크는 어느 정도 널리 지원됩니다! ). 사용자 편집기가 이를 선택할 수 있는 방법이 있습니다.

"가장 안쪽 프레임"을 찾는 것에 대해 말하자면, 특정 언어로 된 내 코드에 대한 스택 추적의 맨 위 또는 맨 아래를 봐야 하는지 기억할 수 없을 정도로 작업 과정에서 충분한 언어를 사용합니다. 그래서 결국 내가 인식하는 파일 이름을 볼 때까지 파일 이름을 보면서 스캔합니다. 여기에 표시된 밑줄이 도움이 되므로 이는 분명한 개선 사항입니다. 그러나 나는 여전히 상위 또는 하위를 봐야하는지 부를 수있는 좋은 방법이 있는지 궁금합니다. 원칙적으로 한 쪽 끝에 YOUR CODE HERE 를 인쇄하고 다른 쪽 끝에 OTHER CODE HERE 를 인쇄하면 도움이 되지만 그다지 우아해 보이지는 않습니다.

https://github.com/JuliaLang/julia/pull/36134 에서 Base에 PR을 했습니다.
내가 말할 수있는 한 작동하지만 병합을 준비하려면 도움이 필요합니다.

유형 매개변수를 생략하는 방법이 있습니까? 우리가 자주 보는 문제는 DiffEq, ForwardDiff 등의 유형 매개변수의 양이 문제를 ... 어렵게 만들 수 있다는 것입니다. 기본적으로 Dual 라고 하면 유형 매개변수로 인해 다른 메소드에 디스패치가 있는 경우를 제외하고는 내가 읽은 대부분의 스택 추적에서 노이즈를 90% 줄일 수 있다고 생각합니다. 다른 경우에는 @timholy 의 제안이 실제로 필요한 것입니다. 일반적으로 유형을 만들거나 유형 매개변수를 일치시키는 것이기 때문입니다.)

기존 유형 별칭에 해당하는 경우 이제 자동으로 사라집니다(#36107). 그렇지 않으면 가능한 컴파일 성능 병목 현상을 나타내므로 조사할 가치가 있습니까?

이제 완료되었습니다.

어떤 사람들에게는 3페이지의 인쇄된 용지가 필요한 유형을 인쇄할 때 대부분의 사람들이 혼란스러워 하므로 아마도 옵트인해야 할 것입니다. 나는 그것에 대해 논의하기 위해 다른 문제를 열 ​​것입니다.

https://github.com/JuliaLang/julia/issues/36517 에서 계속