Julia: ClearStacktrace.jlをBaseに含めるには何が必要ですか？

これは本当にいいと思います。 または、少なくとも、Baseでのデフォルトのスタックトレースの印刷を改善する縮小バージョンかもしれません。

私はすべて賛成です。 私が得られない主なものは、署名の色です。 彼らは...ランダムに見えますか？ さまざまな要素を見つけやすくするためにさまざまな色があると思いますが、少し奇妙です。 色==入れ子の深さはどうですか？ 主な奇妙さは、たとえばTuple{Symbol,Symbol}にあると思います。ここで、2つの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の明るいカラー）のみを使用しており、派手なカラーリングが少し難しくなっています。

全体的に良い提案。 たぶん、私がこれまでに色を選択した理由について、いくつかのコメントがあります。

数字は重要なので青色になっているので、グレー表示にしないでください。ただし、関数名で注目を集めているように、数字を白く感じました。

モジュールはサイクルで原色を使用します。これは、関連するモジュールのトレースをすばやくフィルタリングできるため、非常に便利だと思います。 これは、現在のスタックトレース形式と非常に関係があります。 アイデアは、人々が探しているものを見つけるためにできるだけ少なく読むことを強制されるべきであるということです。 （これまでの学業では、主に眼球運動と注意力の研究を行っていたので、これらの側面は私にとって重要です;））

署名の色は非常に議論の余地があります。 上のスクリーンショットのものは、ダークグレーとわずかに異なるように選択されています。 同時に、さまざまなセマンティックコンポーネントを識別できるようにしたかったのです。 そのため、すべてのタイプとタイプパラメータ（中括弧とコンマ）によって色が切り替わります。 3つの色があります。つまり、同じ色の隣人が2人いることはありません。 巨大な型注釈で単一の単語がすべて白である場合、それらを理解するのは非常に難しいことがわかりました。 わずかに異なる色合いは大いに役立ちますが、視覚的にすべてを少しうるさくします。

16色セットにはダークグレーとわずかに異なる色がないため、ベースに含めることができるものではない可能性があります。 最近の更新では、色をANSIセットとは少し異なる3つのグレーの色合いに置き換えましたが、それでも、私が推測するすべての場所でサポートされるわけではありません。

また、スタックフレームの色とモジュールの色、およびダークグレーと白はすべてシステムの色です。 ここに表示されているようにレンダリングするのは、私の特定のVSCodeテーマです。

これは素晴らしいことです。

引数の型をスキャンするとき、1つがどこで停止し、次がどこで開始するかを理解するのはかなり難しいことがよくあります。 ここでは、トップレベルの色を変えたり、引数に番号を付けたりすることも非常に役立つ場合があります。

 [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：モジュールごとの色がある場合は、モジュール名に色を適用する方が良いようです。

私はモジュール名が好きです、それらはこの最新の写真で少し失われます。

それらが一番​​下にある場合、おそらくそれらを同じ明るい色にすることは物事をつなぐでしょうか？ （そして、モジュールの境界を越える場所を明確にします。）そして、おそらく、モジュール名がパスに表示されている場合は、代わりに単に強調表示することができます。これにより、関数がある左端からカラフルな名前が移動します。

いくつかのインスピレーションを得るために、スタックトレースのフォーマットを微調整することが最後に出てきたときの画像をいくつか投稿します。

多くの場合、正確なパッケージはコードの性質ほど重要ではありません。コアジュリア、使用しているライブラリ、開発中のライブラリ、またはスクリプトですか。 コア/ベース/ dev / stdlib、パッケージ、現在]dev edのパッケージ、その他すべて（スクリプト/ REPLを含む）の4色を使用できます。 これらの区別のいくつかはかなり恣意的であり、分類は少し脆弱ですが、これに基づいて方法を着色すると、（少なくとも私にとっては）余分なテキストを表示せずに情報を最大化し、小さくて覚えやすい色のセットを維持します。

私にとって、色は境界の変更に関するものであり、一方のモジュールからのコードが始まり、もう一方のモジュールが終わります。 だから私はおそらく彼らに固有の意味を割り当てないでしょう。 一方で、それは混乱を招くかもしれません。

私はもっ​​と単純化しようとしましたが、モジュール列がないとあまり役に立たなくなったので、もう一度列を削除しました。 次に、最初にモジュールごとに行番号のみに色を付けましたが、それでもファイル名があまり表示されないままでした。これは多くのコメントが重要であると述べています。 それで、モジュールの色でもそれを着色しました。 モジュール名自体は、関数名に近すぎてノイズが多すぎるため、色付けされていません。

番号とファイル名の両方が色付けされたバージョンは次のとおりです。

ここではファイル名は色付けされていません

ファイルのフルパスに色を付けてみることもできますか？

いくつかのアイデア...
ファイル名と行番号は、それらを区別するために2つのスペースを使用して一貫した場所にあります。
スタックレベルの色とモジュールの色が一致して、関連する線を視覚的にペアにします。
ファイル名、行番号、およびパスは、パラメータータイプとはわずかに異なる色相であり、混乱することなく区別できます。

[この例の色は任意であり、それらの位置がどのように関連しているかをよりよく考えています。
例のスタックレベルが欠落していて、最後の項目のパラメータタイプリストが短縮されているのは、例を手動で入力したためです。]

誰かがそれで遊びたい場合に備えて、上記のサンプルを生成するために使用されるコード：

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内の番号でトレースエントリをスタックする方法があることは知っていますが、これは私の意見ではリンクをクリックするよりもはるかに直感的ではありません。

たとえば、次のように、行情報がログシステムで印刷される方法を統一する機会を利用することは理にかなっています。

また、ロギングシステムはホームディレクトリを縮小することに注意してください

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

ここでの提案には2つのコアアイデアがあると思います。

• 署名とは別の行に行情報を配置します（見つけやすくするために、色で区切ってください）。
• モジュールを表示します。

したがって、これらの両方のアイデアを使用した、もう少し保守的な試みを次に示します。

変数名が追加され、モジュール名だけに色が付けられたバージョン（ただし、それ以外の場合は@infoがパスを出力する方法と一致します）：

これにはあまり長い型シグネチャはありませんが、おそらくこのような変数名を使用すると（可能であれば）、各引数の最も外側の型を簡単に見つけることができます。

利用可能なニュートラルのレベルが3つある場合（太字/通常/灰色など）、ファイルパスを署名よりも軽く印刷すること（IMO）は、物事が一緒に実行されるのを防ぐ良い方法のようです。 （これは@infoが行うことでもあります。）

させて
 printstyled（ "\ njulia>"、color =：green）
 println（ "f（）"）
 printstyled（ "" "エラー：DimensionMismatch（" Aの寸法は（1,2）ですが、Bの寸法は（3,4） "）" ""、color =：light_red）
 println（ "\ nStacktrace："）
 for（idx、err）in enumerate（errors）
 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（ "、"、color =：normal）
 printstyled（rand（ 'a'： 'z'）^ 2、color =：light_black）
 printstyled（ "::"、color =：normal）
 printstyled（ "$ t"、color =：normal）
 終わり
 printstyled（ "）"、color =：normal）
 println（）
 printstyled（ "@"、color =：light_black）
 printstyled（err [6]、color = mc）＃モジュール
 printstyled（ "$（err [7]）/ $（err [5]）：$（err [4]）"、color =：light_black）＃パス
 println（）
 終わり
終わり

ここでの提案には2つのコアアイデアがあると思います。

* 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で、私があなたの状況を知っていることを知ってい

私にとって、最後の提案は間違いなく現状を改善することです。 私が考えている2つのこと：

• 可能であれば、署名が長いと署名と混ざり合う傾向があるため、線情報を目で確認するための何らかの「フック」があると便利です。
• スタックフレーム番号が10を超える場合は、おそらくスタックフレーム番号を揃える必要があります。
  [ 8] [ 9] [10] [11]
  など。これにより、 @も整列します。

私はそれが好きです、私たちはどこかに到達していると思います。 色を慎重に扱うことは、バイクシェディングの表面積が少なくなるだけでなく、誰かの端末で色が読めなくなるリスクを減らすため、常に良いことです。

間隔を空けるのは良いことですが、残念ながら構文f (...)は明示的に許可されていないため、スペースを削除するか、親を削除する必要があると思います。

最新のサンプルは一般的に見栄えが良いですが、私は2番目のアイデアです。

可能であれば、署名が長いと署名と混ざり合う傾向があるため、線情報を目で確認するための何らかの「フック」があると便利です。

そして、フックが別の色または（できれば）明るさであることを願っています。

モジュールの色のサイクルを実行することもできますが、スタックレベル番号の両側の[]にのみ適用するため、何らかの理由で色が表示されない場合でも、ほとんど失われません。

たぶんあなたはモジュールの色のサイクルを行うことができますが、それを[]にのみ適用します

かっこだけでコントラストのある部分にあると色がよく見えないので、あまりうまくいかないと思います。

構文f（...）は明示的に許可されていません

コントラストの違いがあるので、スペースがなくてもうまくいくと思います。

可能であれば、回線情報のためにあなたの目に何らかの「フック」があるといいでしょう

私は同意します。行番号を灰色のまま太字のままにしておくとうまくいくと思います。それは、それらを探すとわずかに目立つようになりますが、白にする次のステップは、私の意見ではあまりにもうるさいです。

おそらくスタックフレーム番号を揃える必要があります

あなたの例のように角かっこ内にスペースを入れて試してみましたが、少し奇妙に見えたので、角かっこで囲まれた数字を正しく揃えています。 それはかなりうまくいくと思います。

これらすべてのアイデアが組み込まれた最新バージョンは次のとおりです。

そしてボーナスとして、これが（ランダムな）変数名でどのように見えるかを示しています。 繰り返しますが、これらの変数名はすべて注意を引くために戦うべきではないため、太字の灰色を使用していますが、それらを探すと少し識別できるはずです。

私はこれがどこに向かっているのかも好きです。 モジュール名のある種の強調表示に投票したいだけです。 私は実際、同じモジュールが同じように色付けされ、色が循環するスタイルがとても好きです（2つのスタックトレースラインがモジュール間のグラフエッジとして隣接していると考えると、ここにグラフの色の問題があります）。 ただし、残念ながら、その色の意味はかなり明白ではありません。 おそらく、すべてのモジュール名を1つの色で着色しますか？

この配置は私にはよく見えます。

パスを署名とより明確に区別することで、物事を分割するのに役立つと思います。重要度の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

編集：折り返す1つの長い行と画像があります：

ロギングが使用するものを明示的にミラーリングできます

これについて私があまり好きではないのは、ウィンドウ/ REPLのサイズを変更した場合（たとえば、より長い行のためのスペースを作りたい場合）、特定のREPL幅のためにのみ存在する改行がうまく転送されないことです）またはテキストをコピーして、異なる幅のウィンドウに貼り付けます

はい、マーカーを連続させるために明示的に線を切ることは提案しません。 実際、折り返した線を突破させて、見た目を変えるのは良いことかもしれません。 ほとんどの場合、色を関数名に関連付ける方法と、最も重要な見出しのように見えるのではなく、境界線の一部である場合は、目立たないようにする方法について考えます。

私は色が好きだったと言わなければなりませんが、私はそれを保守的にすることの好みを理解することができます。

しかし、私は私のサポートを次のようなものの後ろに投げたいです

多くの場合、正確なパッケージはコードの性質ほど重要ではありません。コアジュリア、使用しているライブラリ、開発中のライブラリ、またはスクリプトですか。 コア/ベース/ dev / stdlib、パッケージ、現在]dev edのパッケージ、その他すべて（スクリプト/ REPLを含む）の4色を使用できます。 [...]

私はベースでハッキングしておらず、パッケージではめったにハッキングしていないので（ほとんどの人がそうしていると思います）、エラーの90％をスクリプトで修正する必要があり、9％をパッケージで、1％をベースで修正する必要があります。 関数の呼び出しを間違えた場合、ベースで正確に知る必要はありません。とにかく修正するためにそこに行くつもりはないので、エラーがスローされました。コードを修正する必要があります。

ですから、ほとんどの場合、それ以降は今のところ無視しても問題ないので、コードをどこに残しているか（そして、パッケージコードをどこに残して、ベースに入るのか）を視覚的に確認していただければ幸いです。 色ではない場合は、おそらく--------------------------------------------か何かで？ それらは2〜3個しかないはずです。

モジュールに色が付いた場合は、ベース/コアを省略して色を付けないでください。

私は実際、同じモジュールが同じように色付けされ、色が循環するスタイルがとても好きです

私も大丈夫です。 たくさんの色を使うなら、そのために使うべきだと思います。 また、垂直方向のスペースを取りすぎずに、ユーザーコードとパッケージコードの境界を見つけるのにも役立ちます。

モジュールに色が付いた場合は、ベース/コアを省略して色を付けないでください。

はい、ベースとコアは常にダークグレーか何かで、他のすべての人により多くの色を残すことができます:)

これが16色で完全に機能することを諦めた場合は、モジュール名のハッシュにして、それらのいくつかを覚えておくとよいでしょう。

または、ベース/コア用と外部モジュール用の2色のみがありますか？

私の現在のバージョンには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::

vs

 [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、パッケージ、devedパッケージ、ユーザーなど）ごとに色のセットを減らした方が便利なようです。

私はこれを行うエディターの配色にたどり着きましたが、それは適度に便利です。そうでなければ青になる可能性のあるすべての変数は、文字列やキーワードなどが異なる、緑と青のさまざまな色合いです。 おそらく理想は、あなたが提案するような幅広いクラス内でこのようなものになるでしょう（たとえば、赤紫の標準ライブラリ、緑青でダウンロード、オレンジ黄色で開発、灰色のベース）。 または、おそらくこれはあまりにも多くの作業です！

別の反復：私はすべての内部にあまり精通していないため、すべてが非常にハッキーだと感じていますが、そこに変数名を取得しようとしました。 どのように色を割り当てるかは議論の余地がありますが、一般的に肯定的な反応が得られたように見えたので、モジュールの色を変更しました。 しかし、色によっては、あるエントリのモジュールが次のエントリの関数名と少し衝突しているように感じます。 そこで、改行を導入しました。 もちろんすべてが長くなりますが、私は追加の呼吸室と明快さが好きです

私はあなたの最後のサンプルが好きです、それは非常に明確で読みやすいです:)

以下は、モジュール名の代わりに「@」にモジュールの色を適用して、関数名との衝突を減らし、タイプを強調表示して、空白を導入せずにパスを少し簡単に区別できるようにする実験です。行。

@jkrumbiegelそれは美しいです。 私は私の人生でこれが必要です。

私はそれらの柔らかいブルースが好きです

@jkrumbiegelすばらしい、@記号が必要かどうかは
in MakieLayout at ~/.julia/packages/MakieLayout/COfBu/src/lineaxis.jl:372

@jkrumbiegel見栄えがいいです！ ファイル名（フルパスではなく）と行番号だけを強調表示する方法はありますか？ おそらく少し明るい灰色ですか？

素晴らしい！ 私は実際に改行が本当に好きです。改行は視覚的に非常に役立ち、スタックトレースは非常に長くなる傾向があるため、とにかくスクロールする必要があります。スクロールを少し減らすよりも明確にしたいと思います。

強調表示された::は素晴らしいです。 パラメータリストの各文字の情報内容を文字位置に対して示す曲線をプロットする必要がある場合、 ::はその曲線の極大値を正確にマークします。 名前については左側を、タイプの最も重要な部分については右側を見るとわかります。その後、情報の内容は削除されるだけです。

私はこのコメントに同意しません。ハイライトは重要なことを強調して、目が何を読むべきかを理解できるようにする必要があります。::は間違いなく私が読むべき重要なことではありません。 現状では、白は大胆な濃い青よりもはるかに目立ちます。 パラメータの区別は、引数名を白で表示するだけで明確になります（おそらく、名前付き引数がない場合を除いて、引数を区切るために::も白で表示される場合があります）。 行番号についても同じことが言えます。行番号よりもファイル名を強調したいと思います。

色付きのパッケージ名は、最も重要なものである関数名を覆い隠すリスクがありますが、太字で改行を付けておくと、そのリスクが実際に制限されます。

::を白くする前によく考えました。 もちろん、引数の名前と型は実際の情報なので、強調表示する必要があると思うかもしれません。 しかし、それらを強調するときの私の強い印象は、それらがあなたの注意を呼びかけるということです。 しかし、すべての名前とタイプを読むことは重要ではありません。 特定の機能で探しているものを見つけることができるはずです。 スタックトレースを読み取る手順を確認する方法：

1. 一般的な概要を取得する
2. どのモジュールのどの機能がエラーになりましたか？
3. 他のどのモジュールからこの関数を呼び出した他の関数は何ですか？
4. 自分のコードとベースコードまたは他のパッケージコードとの間に重大な境界はありますか？ それはどこにある？
5. その境界にはどのような機能がありますか？
6. どのタイプ/引数が使用されましたか？ 1つの引数はどこで終わり、次の引数はどこから始まりますか？ これは、現在、長いパラメトリックタイプでは特に困難です。
7. それはエラーを説明していますか？
8. これが役に立たなかった場合は、細かい櫛ですべてを通過します

したがって、タイプ/引数の情報は、一般的な構造を方向付けて理解した後にのみ使用されると私は考えています。 ハイライトについて理解しておくべきことの1つは、ハイライトが比較的まばらである場合にのみ、必ずしも物を見つけやすくなるとは限らないということです。 したがって、変数/型の情報を探し始めるまで、::ハイライトは邪魔にならず、注意を引くことはないと思います。 そしてその段階で、それはあなたの目にジャンプするためのフックを与えます、それ以上でもそれ以下でもありません。 それは非常に効率的だと思います。

ちなみに、すべての引数に名前があるわけではないため、変数名を強調表示しても、必ずしも適切に分離できるとは限りません。 ::はいつもそこにあると思います。

それは良いリストのようです。私の主な不満はポイント6で、長い型の署名のギャップを見つけます。 ::超高輝度で印刷すると効果がありますが、少し奇妙だと思います。 引数名（または、存在しない場合は_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の可能性があり

複雑な色を実際に使用しなくなったため、Crayon.jlの使用をやめました。 パッケージのロード時間にも役立ちます。 濃い灰色の下線を引くことで、視覚的に圧倒されることなく、ファイル名と行番号の視認性を高める方法を見つけました。 パス/リンクに下線が引かれていることに慣れているので、それも理にかなっているように見えます。 白やその他のハイライトが強すぎ、太字が弱すぎました。

また、サイクラーの最初の色として明るい色に切り替えたので、そもそもそうすべきだったのですが、テーマは同じように見えるので気づきませんでした。 これは、濃い青がほとんど見えないテーマに適しているはずです（ただし、これはテーマのせいです）。

このスタイルをバージョン0.2としてClearStacktrace.jlので、もう少し試してみることができます。

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の使用をやめました。 パッケージのロード時間にも役立ちます。 濃い灰色の下線を引くことで、視覚的に圧倒されることなく、ファイル名と行番号の視認性を高める方法を見つけました。 パス/リンクに下線が引かれていることに慣れているので、それも理にかなっているように見えます。 白やその他のハイライトが強すぎ、太字が弱すぎました。

また、サイクラーの最初の色として明るい色に切り替えたので、そもそもそうすべきだったのですが、テーマは同じように見えるので気づきませんでした。 これは、濃い青がほとんど見えないテーマに適しているはずです（ただし、これはテーマのせいです）。

このスタイルをバージョン0.2としてClearStacktrace.jlので、もう少し試してみることができます。

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

最も重要な情報は、エラーメッセージ自体と、スタックの一番上（エラーに近い方）のフレームと、スクロールせずに常に表示される順序で印刷することです。 現在、スタックトレースの末尾だけでなく、エラーメッセージを表示するために、頻繁に上にスクロールする必要があります。

ただし、ターミナルからコピーして貼り付けられたWebサイトでスタックトレースを読み取る場合は、ターミナルの場合のように下から上にスクロールするのではなく、上から下にスクロールするため、逆の順序が必要です。これらの両方の場合に適した設計。

ただし、ターミナルからコピーして貼り付けられたWebサイトでスタックトレースを読み取る場合は、ターミナルの場合のように下から上にスクロールするのではなく、上から下にスクロールするため、逆の順序が必要です。これらの両方の場合に適した設計。

私は実際にClearStacktrace.jlにしばらくの間コードを持っていたので、最後のスタックトレースを再印刷することができました。 超ロングタイプを最大文字数で切り取り、全情報が必要な場合は完全に転載できることを想定していました。 しかし、あなたのユースケースも興味深いでしょう。 reprint(inverted = true)またはreprint(html = true)でさえ、Webサイトに貼り付けるための色を保持するhtmlバージョンを印刷することを想像できます。

また、スクロール方向を考えると、デフォルトで全体を反転することが理にかなっている可能性があることに同意します。

ipythonは逆の順序でフレームを印刷し、スクロールする必要がないにもかかわらず、私はいつもそれが不可解に混乱していることに気づきました。 おそらくそれは、gdbや他のシステムで最も内側のフレームが一番上にあるという私の以前の経験によるものでしょうか、それとも他の人もこのように感じているのでしょうか？

gdbと言えば、ポケットベルを使用した非常に長いトレースに対する合理的な解決策があります。「Enterキーを押してフレームを増やす」。

ちなみに、 https： //github.com/JuliaLang/julia/issues/36026#issuecomment -636912686で最新のビジュアルデザインを紹介していますが、それを統合すれば非常に嬉しいです。 フレームの順序を変更したり、インタラクティブ機能を追加したりすることは、別の問題のように思われます。

ファイル名に関しては、最終的にはターミナルハイパーリンクOSCシーケンスを使用でき（はい、ターミナルのハイパーリンクはある程度広くサポートされています！ ）、ユーザーのエディターがそれを取得できるようになることを願っています。

「最も内側のフレーム」を見つけることについて言えば、私は仕事の過程で十分な言語を使用しているので、特定の言語でコードのスタックトレースの上部または下部を確認する必要があるかどうかを思い出せません。 そのため、認識できるファイル名が見つかるまで、ファイル名を調べてスキャンすることになります。 ここに示されている下線は役立つので、これは明らかな改善です。 しかし、私はまだ上を見るべきか下を見るべきかを呼びかける良い方法があるのだろうかと思います。 原則として、一方の端にYOUR CODE HEREを印刷し、もう一方の端にOTHER CODE HEREを印刷すると役に立ちますが、あまりエレガントではないようです。

私はここでベースにPRをしましたhttps://github.com/JuliaLang/julia/pull/36134
私の知る限りでは機能しますが、マージの準備をするためにいくつかの助けが必要です

タイプパラメータを省略する方法はありますか？ 私たちがよく目にする問題は、DiffEq、ForwardDiffなどの型パラメーターの量が物事を困難にする可能性があることです。 タイプパラメータが原因で他のメソッドへのディスパッチがある場合を除いて、デフォルトでDualと表示されている場合は、私が読んだほとんどのスタックトレース（および他の場合、 @ timholyの提案は本当に必要なものです。なぜなら、それは通常、型の作成または型パラメーターのマッチングに関するものだからです）

それらが既存の型エイリアスに対応している場合は、自動的に削除されます（＃36107）。 それ以外の場合は、コンパイルパフォーマンスのボトルネックの可能性を示しているので、調査する価値がありますか？

これは今行われます。

一部の人にとっては、ほとんどの人は3ページの印刷された紙を必要とするタイプを印刷するときに混乱するだけなので、おそらくオプトインの何かであるはずです。 それについて議論するために別の問題を開きます。

https://github.com/JuliaLang/julia/issues/36517に続く