Julia: Was ist erforderlich, um ClearStacktrace.jl in Base einzuschließen?

Das wäre wirklich schön zu haben. Oder zumindest eine abgespeckte Version, die das Drucken von Stacktraces standardmäßig in Base verbessert.

Ich bin ganz dafür. Die Hauptsache, die ich nicht verstehe, sind die Farben in den Signaturen. Sie scheinen ... zufällig? Ich denke, die verschiedenen Farben sind da, um es einfacher zu machen, verschiedene Elemente auszuwählen, aber es ist ein bisschen seltsam. Wie wäre es mit Farbe == Schachtelungstiefe? Ich denke, die Hauptverrücktheit liegt zB in Tuple{Symbol,Symbol} wo die beiden Symbol s unterschiedliche Farben haben.

Es gibt noch etwas, was ich wirklich gerne sehen würde:

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

aber seit

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

es scheint, dass wir in der Lage sein sollten, Eintrag 2 als etwas wie zu drucken

[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}}

Ein kleiner Kommentar, aber mir ist es momentan vielleicht etwas zu viel Farbe "Salat". Der Stackframe-Zähler ist blau, all die verschiedenen Farben in der Signatur usw. Für Basisfarben haben wir bisher nur die 16 Systemfarben (8 + 8 helle Farben) verwendet und das macht ausgefallene Farben etwas schwieriger.

Insgesamt gute Vorschläge. Vielleicht ein paar Kommentare, warum ich die Farbauswahl bisher getroffen habe:

Die Zahlen sind blau, weil sie wichtig sind, sollten also nicht ausgegraut sein, aber sie weiß zu machen, fühlte sich für mich an, als würden sie mit den Funktionsnamen um Aufmerksamkeit kämpfen.

Die Module verwenden die Primärfarben in einem Zyklus, das halte ich für sehr nützlich, da es ermöglicht, den Trace schnell nach relevanten Modulen zu filtern. Dies hat sehr viel mit dem aktuellen Stack-Trace-Format zu tun. Die Idee ist, dass Menschen gezwungen werden sollten, so wenig wie möglich zu lesen, um zu finden, wonach sie suchen. (Ich habe in meinem bisherigen akademischen Leben hauptsächlich Augenbewegungs- und Aufmerksamkeitsforschung betrieben, daher sind mir diese Aspekte wichtig ;) )

Die Farben für die Unterschriften sind sehr umstritten. Die auf dem obigen Screenshot wurden so gewählt, dass sie sich nur geringfügig von Dunkelgrau unterscheiden. Gleichzeitig wollte ich, dass die verschiedenen semantischen Komponenten unterscheidbar sind. Deshalb verursachen alle Typen und Typparameter (geschwungene Klammern und Kommas) einen Farbwechsel. Es gibt drei Farben, was bedeutet, dass es nicht zwei Nachbarn mit derselben Farbe geben wird. Ich habe festgestellt, dass es ziemlich schwierig ist, einzelne Wörter in großen Signaturen zu erkennen, wenn sie alle nur weiß sind. Die leicht unterschiedlichen Farbtöne helfen sehr, machen aber auch optisch alles etwas lauter.

Da das 16-Farben-Set keine Farben hat, die sich nur geringfügig von Dunkelgrau unterscheiden, kann es wahrscheinlich nicht in Base aufgenommen werden. In einem kürzlich durchgeführten Update habe ich die Farben durch drei leicht unterschiedliche Grautöne aus dem ANSI-Set ersetzt, aber auch das wird nicht überall unterstützt, denke ich.

Ach ja auch die Stackrahmenfarbe und die Modulfarben sowie das Dunkelgrau und Weiß sind alle Systemfarben. Es ist nur mein spezielles VSCode-Thema, das sie so rendert, wie Sie es hier sehen.

Das wäre toll zu haben.

Beim Scannen von Argumenttypen ist es oft ziemlich schwer herauszufinden, wo einer aufhört und der nächste beginnt. Hier kann es sehr hilfreich sein, die oberste Ebene anders einzufärben und vielleicht sogar die Argumente zu nummerieren:

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

Wir sollten in der Lage sein, die Argumentnamen anzuzeigen, wie wir es beim Drucken von methods(f) tun.

wie ist das? Ich habe die Signaturfarben durch Dunkelgrau ersetzt, aber :: ist weiß, also ist es hervorstechend, wo Argumenttypen beginnen. besonders hilfreich beim Typ Monster an Position 11

Ich mag das. Wird noch besser mit Argumentnamen.

Schade, dass die Reihenfolge "Funktion - Modul - Argumente" für das Layout so gut funktioniert, aber semantisch nicht wirklich sinnvoll ist. Ich habe jedoch keine Lösung; Natürlich ist es am besten, wenn die Funktion an erster Stelle steht. Vielleicht könnte das Modul in die nächste Zeile vor dem Dateispeicherort gehen? Es gehört schließlich zum Standort. Dann bräuchten wir den Header vielleicht auch nicht.

Ich denke, wir könnten die Zahlen auch in normalen Text schreiben und die Funktionsnamen fett und/oder weiß.

Könnte der Dateiname am Ende des Codepfads (und möglicherweise die Zeilennummer) auch eine eigene hellere Farbe erhalten?

Vielleicht könnte das Modul in die nächste Zeile vor dem Dateispeicherort gehen? Es gehört schließlich zum Standort. Dann bräuchten wir den Header vielleicht auch nicht.

Ich werde mit diesen Vorschlägen ein paar Dinge ausprobieren.

Könnte der Dateiname am Ende des Codepfads (und möglicherweise die Zeilennummer) auch eine eigene hellere Farbe erhalten?

Technisch kann es das natürlich ;) Es ist immer ein Kompromiss zwischen besserer Sichtbarkeit und aufmerksamkeitsstarkem Rauschen.

Warum nicht zuerst die Module schreiben, da sie Teil des vollständigen Namens der Funktion sind? Vielleicht ist es mit Farbe klar genug, um nur Core.eval usw. zu schreiben, oder sie könnten immer noch als Spalten ausgerichtet sein. (Oder vielleicht hast du das versucht und es sah schrecklich aus.)

Wirklich verrückter Gedanke: Wenn das Drucken der Argumenttypen mehr als eine Zeile beanspruchen würde, drucken Sie die Signatur in gefalteter Form aus und verwenden Sie dann REPL.TerminalMenus , damit die Betrachter sie erweitern können. Etwas wie:

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

Verwandte: #35915 (die ich verwenden möchte, um ein gefaltetes Baummenü zu erstellen, https://github.com/JuliaCollections/FoldingTrees.jl).

Wie sieht es aus, wenn der Codepfad in dieser Reihenfolge neu angeordnet ist: LineNumber Filename Path
Dann haben Ihre Augen einen stabilen Ort, um nach der Zeilennummer und dem Dateinamen zu suchen, ohne dass dafür zusätzliche Farbe benötigt wird (ich scheine immer nach dem Dateinamen und der Zeilennummer zu suchen, die in den Details verborgen sind, können Sie das erkennen?)
Und für interaktive REPL-Arbeiten liebe ich die gefaltete Idee oben :)

Warum nicht zuerst die Module schreiben, da sie Teil des vollständigen Namens der Funktion sind

Ja, die Idee gefällt mir irgendwie, ich glaube, ich habe ohne Farbe angefangen und das hat nicht so gut funktioniert, aber so ist es eigentlich recht lesbar. Ich werde es als nächstes ohne Spalten versuchen, obwohl Spalten immer schön sind, weil sie deine Augen leiten.

Nicht sicher, dass; der Funktionsname ist eine weitaus wichtigere Information als das Modul. Zumindest für mich sind die wichtigsten Informationen definitiv der Funktionsname, der Dateiname und die Zeilennummer. Auch für Skripte wäre die linke Spalte viele Main oder leer, was für diesen Anwendungsfall nicht ideal ist.

Ich denke, wenn ich Stacktraces lese, suche ich meistens nach dem letzten Aufruf in meinem Code, bevor er zum Basis- / Paketcode geht, da der Fehler normalerweise in meinem Code steckt. In diesem Fall ist das Modul also ziemlich wichtig und der Funktionsaufruf ist nicht das, was ich zuerst scanne.

Wie wäre es damit:

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

Die Modulnamen würden immer noch aneinandergereiht, so dass sie leicht zu scannen wären.

Ich hatte tatsächlich gerade etwas in der Nähe ausprobiert. Ich habe die Funktionsnamen diesmal selbst eingefärbt, damit sie immer noch am auffälligsten sind, aber die Modulinformationen in ihrer Farbe tragen. Es gibt also immer noch eine offensichtliche Gruppierung, aber mit weniger Fokus auf alle Modulnamen.

Als ich das erste Mal sah, dass ich wahrscheinlich verrückt werden würde, um herauszufinden, was die Farben bedeuten :joy: Wenn es Farben pro Modul geben wird, scheint es besser zu sein, die Farbe einfach auf den Modulnamen anzuwenden.

Ich mag die Modulnamen, sie gehen in diesem neuesten Bild etwas verloren.

Wenn sie unten sind, würde es vielleicht die Dinge verbinden, wenn sie die gleiche helle Farbe haben? (Und machen Sie deutlich, wo Sie eine Modulgrenze überschreiten.) Und wenn der Modulname im Pfad auftaucht, könnte er vielleicht stattdessen einfach dort hervorgehoben werden - das würde auch den bunten Namen vom linken Rand der Funktionen verschieben.

Zur Inspiration poste ich ein paar Bilder von der letzten Optimierung der Stacktrace-Formatierung.

Oft ist nicht das genaue Paket von Interesse, sondern die Art des Codes: Ist es Core Julia, eine Bibliothek, die ich verwende, die Bibliothek, die ich entwickle, oder ein Skript? Wir könnten vier Farben haben: core/base/dev/stdlib, Pakete, Pakete, die derzeit ]dev ed sind, und der ganze Rest (einschließlich script/REPL). Einige dieser Unterscheidungen sind ziemlich willkürlich und die Klassifizierung ist etwas spröde, aber die darauf basierende Farbgebung würde (zumindest für mich) die Informationen maximieren, ohne zusätzlichen Text anzuzeigen und einen kleinen, leicht zu merkenden Satz von Farben beizubehalten.

Für mich geht es bei den Farben eher um Grenzänderungen, bei denen Code aus einem Modul beginnt und das andere endet. Deshalb würde ich ihnen wahrscheinlich keine inhärente Bedeutung beimessen. Andererseits kann das verwirrend sein.

Ich habe versucht, mehr zu vereinfachen und Spalten wieder entfernt, weil sie ohne die Modulspalte nicht mehr so ​​​​nützlich sind. Dann habe ich zuerst nur die Zeilennummer nach Modulen eingefärbt, aber dadurch blieb der Dateiname immer noch nicht so sichtbar, was in vielen Kommentaren wichtig war. Also habe ich das auch in der Modulfarbe eingefärbt. Der Modulname selbst ist nicht farbig, weil er zu nah am Funktionsnamen liegt und das zu verrauscht ist.

Hier ist die Version mit farbigen Nummern und Dateinamen:

hier ohne Dateinamen farbig

Können Sie auch versuchen, den vollständigen Dateipfad einzufärben?

Einige Ideen...
Dateiname und Zeilennummer an einem einheitlichen Ort mit doppelten Leerzeichen, um sie hervorzuheben.
Farbe auf Stapelebene und Modulfarbe stimmen miteinander überein, um die zugehörigen Linien visuell zu paaren.
Dateiname, Zeilennummer und Pfad in einem etwas anderen Farbton als Parametertypen, um eine übersichtliche Unterscheidung zu ermöglichen.

[Farben in diesem Beispiel sind willkürlich, denken Sie mehr darüber nach, wie ihre Positionen zueinander stehen.
Fehlende Stapelebenen im Beispiel und verkürzte Parametertypliste beim letzten Element sind darauf zurückzuführen, dass ich das Beispiel von Hand eingegeben habe.]

Code, der verwendet wurde, um das obige Beispiel zu erstellen, falls jemand damit spielen möchte:

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

Das Problem dabei ist, dass dadurch die Links in Atom / VSCode usw. nicht anklickbar bleiben. Dies ist etwas, das ich sehr oft verwende und ich glaube, dass andere das auch tun. Tatsächlich erweitere ich sogar explizit die Basispfade, um sie anklickbar zu machen. Das druckt natürlich mehr. Aber ich denke, es erhöht den Nutzen. Ich weiß, dass es eine Möglichkeit gibt, Trace-Einträge in der REPL mit einer Verknüpfung nach Nummern zu stapeln, aber dies ist meiner Meinung nach weit weniger intuitiv, als nur auf einen Link zu klicken.

Es kann sinnvoll sein, die Art und Weise, wie die Zeileninformationen gedruckt werden, mit dem Protokollierungssystem zu vereinheitlichen, zum Beispiel:

Beachten Sie auch, dass das Logging-System das Homedir . kontrahiert

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

Ich denke, der Vorschlag enthält zwei Kernideen:

• Lassen Sie die Zeileninformationen in einer separaten Zeile von der Signatur stehen (und grenzen Sie sie möglicherweise mit einer Farbe ab, um sie leichter zu finden).
• Zeigen Sie das Modul an.

Hier ist also ein etwas konservativerer Versuch mit diesen beiden Ideen:

Eine Version mit hinzugefügten Variablennamen und Farbe nur auf den Modulnamen (aber ansonsten entspricht @info Pfade):

Dieser hat keine sehr langen Typsignaturen, aber vielleicht wird es mit Variablennamen wie diesem (wenn das möglich ist?) einfacher, den äußersten Typ jedes Arguments zu erkennen.

Wenn drei Neutralstufen verfügbar sind (wie Fett / Normal / Grau), dann scheint das Drucken des Dateipfads leichter als die Signatur (IMO) eine gute Möglichkeit zu sein, um zu verhindern, dass die Dinge zusammenlaufen. (Das macht auch @info .)

 Lassen
 printstyled("\njulia> ", color=:green)
 println("f()")
 printstyled("""ERROR: DimensionMismatch("A hat Dimensionen (1,2) aber B hat Dimensionen (3,4)")""", color=:light_red)
 println("\nStacktrace:")
 for (idx, err) in enumerate(errors)
 mc = idx <= 3 ? :blue : (idx >= 7 ? :blue : :yellow) # Modulfarbe
 printstyled("[$(err[1])] ", color=:normal, bold=true) # errorno
 printstyled(err[2], color=:normal, bold=true) # Funktion
 printstyled("(", color=:normal) # Parametertypen
 für (i,t) in enumerate(err[3])
 i != 1 && printstyled(", ", color=:normal)
 printstyled(rand('a':'z')^2, color=:light_black)
 printstyled(::", color=:normal)
 printstyled("$t", color=:normal)
 Ende
 printstyled(")", color=:normal)
 println()
 printstyled(" @ ", color=:light_black)
 printstyled(err[6], color=mc) # Modul
 printstyled(" $(err[7])/$(err[5]):$(err[4])", color=:light_black) # path
 println()
 Ende
 Ende

Ich denke, der Vorschlag enthält zwei Kernideen:

* 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.

Hier ist also ein etwas konservativerer Versuch mit diesen beiden Ideen:

Ich mag das. Ich denke, der Begriff ist "töte deine Lieblinge", und mein Liebling könnte die Farbe sein. Aber ich kann sehen, wie etwas Abgeschwächtes für etwas so Grundlegendes besser geeignet sein könnte. Ich habe es ein wenig geändert, sodass der Modulname und der Funktionsname an einer Linie liegen, wodurch eine fast spaltenartige vertikale Kontrastlinie entsteht. Das sollte helfen, die relevanten Informationen zu finden. Obwohl ich immer noch denke, dass ich die Typen nicht in Weiß färben würde, weil sie so unordentlich werden. Wenn wir Variablennamen hätten, würden die in Weiß vielleicht gut aussehen.

Ich mag das. Ich denke, der Begriff ist "töte deine Lieblinge", und mein Liebling könnte die Farbe sein.

Nur damit Sie wissen, dass ich Ihre Situation kenne, https://github.com/JuliaLang/julia/pull/18228. Das ist ein Thema, das Fahrradschuppen sehr viel Spaß macht und jeder hat einen Eimer Farbe, heh. Wie man sieht, startete auch die PR recht ambitioniert, wurde aber langsam immer konservativer heh.

Für mich ist der letzte Vorschlag definitiv eine Verbesserung gegenüber dem Status Quo. Zwei Dinge denke ich:

• Wenn möglich, wäre es schön, eine Art "Haken" für Ihre Augen für die Zeileninformationen zu haben, da sie dazu neigen, mit der Signatur zu verschmelzen, wenn die Signatur lang ist.
• Wir sollten wahrscheinlich die Stackframe-Nummern ausrichten, wenn es mehr als 10 davon gibt:
  [ 8] [ 9] [10] [11]
  usw. Das würde dazu führen, dass die @ ebenfalls in einer Reihe stehen.

Ich mag es, ich denke, wir kommen irgendwo hin. Mit Farben umsichtig zu sein ist immer gut, da dies weniger Oberfläche für den Fahrradabwurf freilegt und das Risiko verringert, dass eine Farbe auf dem Terminal von jemandem unlesbar ist.

Es ist gut, Dinge zu beabstanden, aber leider ist die Syntax f (...) ausdrücklich nicht zulässig, daher denke ich, dass wir entweder das Leerzeichen entfernen oder die Klammern entfernen müssen.

Das neueste Beispiel sieht im Allgemeinen gut aus, aber ich unterstütze die Idee:

Wenn möglich, wäre es schön, eine Art "Haken" für Ihre Augen für die Zeileninformationen zu haben, da sie dazu neigen, mit der Signatur zu verschmelzen, wenn die Signatur lang ist.

Und ich hoffe, dass der Haken eine andere Farbe oder (vorzugsweise) Helligkeit hat.

Vielleicht könnten Sie den Farbzyklus für die Module durchführen, aber nur auf [ ] auf beiden Seiten der Stapelstufennummer anwenden, damit nicht viel verloren geht, wenn Sie die Farben aus irgendeinem Grund nicht sehen können.

Vielleicht könnten Sie den Farbzyklus für die Module machen, aber nur auf die [ ] anwenden

Es ist schwer, die Farbe richtig zu sehen, wenn es nur Klammern sind und sie sich in einem kontrastreichen Bereich befinden, daher denke ich, dass das nicht so gut funktioniert.

die Syntax f (...) ist explizit nicht erlaubt

Ich denke, es funktioniert auch ohne den Raum gut, wegen des Kontrastunterschieds.

Wenn möglich, wäre es schön, eine Art "Haken" für die Augen für die Leitungsinformationen zu haben

Ich stimme zu, ich denke, es funktioniert gut, die Zeilennummern grau, aber fett zu lassen, das macht sie nur leicht hervorstechend, wenn Sie nach ihnen suchen, aber der nächste Schritt, sie weiß zu machen, ist meiner Meinung nach viel zu laut.

Wir sollten wahrscheinlich die Stackframe-Nummern ausrichten

Ich habe es mit Leerzeichen innerhalb der Klammern wie in Ihrem Beispiel versucht, fand aber, dass das etwas seltsam aussah, also richte ich jetzt die Klammernzahlen genau richtig aus. Ich denke, das funktioniert ganz gut.

Hier ist die neueste Version mit all diesen Ideen:

Und als Bonus, so könnte es mit (zufälligen) Variablennamen aussehen. Wieder verwende ich nur fettes Grau, weil all diese Variablennamen nicht um Ihre Aufmerksamkeit kämpfen sollen, sondern ein bisschen erkennbar sein sollten, wenn Sie danach suchen

Ich mag es auch, wo das hinführt. Ich möchte nur eine Stimme für eine Hervorhebung des Modulnamens abgeben. Ich mag den Stil, bei dem das gleiche Modul gleich gefärbt ist und die Farben durchläuft (es gibt hier ein Problem mit der Grafikfarbe, wenn Sie zwei Stapelverfolgungslinien als benachbarte Grafikkante zwischen ihren Modulen betrachten). Es ist jedoch leider ziemlich nicht offensichtlich, was diese Farbe bedeutet. Vielleicht alle Modulnamen in einer einzigen Farbe einfärben?

Diese Ausrichtung sieht für mich gut aus.

Ich denke immer noch, dass eine klarere Unterscheidung der Pfade von den Signaturen helfen würde, die Dinge aufzuteilen - 3 Wichtigkeitsstufen, Name/Signatur/Pfad. Logging-Makros @info usw. drucken sie heller als andere Zeilen.

Variablennamen wären sehr nett. Würden Sie dafür stimmen, dass sie wahrscheinlich weniger bedeutsam sind als Signaturinformationen?

Wenn die Modulnamen links aufgereiht sind, können Sie sie scannen, obwohl ich traurig bin, dass die Farben verschwinden.

Meine Augen scheinen zu wissen, wo diese Dinge zu finden sind :)
Würde eine Leerzeile zwischen Modulen zu viel vertikalen Platz beanspruchen?

Das Einfärben von Zeilen mit 2 verschiedenen Farben, sodass abwechselnde Zeilen die gleiche Farbe haben - wie es oft in Tabellen der Fall ist, kann die Lesbarkeit verbessern.

Das Farbwechseln des @ neben dem Modulnamen anstelle des Modulnamens selbst sticht hervor (weil @ ein ziemlich großes Zeichen ist), ohne zu sehr mit dem hervorgehobenen Funktionsnamen zu konkurrieren.

Die Parameternamen habe ich mir oft gewünscht, da sie einem helfen, den richtigen Parametertyp zu finden, ohne sie durchzählen zu müssen.

Könnte der Pfad (und vielleicht der Modulname daneben) eine andere Helligkeit haben als die Typen? Vielleicht nur mit den Parameternamen übereinstimmen? (Oder alle zusammen schwach beleuchtet, wenn Sie Mcabbotts Vorschlag machen, die Namen dunkler als die Typen zu machen)

Sie könnten explizit spiegeln, was Logging verwendet, wenn auch idealerweise mit anderen Farben:

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

Bearbeiten: jetzt mit einer längeren Zeile, die umbricht, und einem Bild:

Sie könnten explizit spiegeln, was die Protokollierung verwendet

Was mir daran nicht so gut gefällt ist, dass Zeilenumbrüche, die nur aufgrund der spezifischen REPL-Breite vorhanden sind, nicht gut übertragen werden, wenn Sie die Größe Ihres Fensters / REPL ändern (wenn Sie beispielsweise Platz für längere Zeilen schaffen möchten ) oder kopieren / fügen Sie den Text in Fenster unterschiedlicher Breite ein

Ja, ich würde nicht vorschlagen, die Linien explizit zu unterbrechen, um die Markierungen kontinuierlich zu machen. Tatsächlich kann es eine gute Sache sein, umbrochene Zeilen durchbrechen zu lassen und somit anders aussehen zu lassen. Meistens ein Gedanke, wie man die Farbe an den Funktionsnamen bindet und wie man sie vielleicht weniger aufdringlich macht, wenn sie Teil des Rahmens ist, anstatt wie die wichtigste Überschrift auszusehen.

Ich muss sagen, dass mir die Farbe gefallen hat, aber ich kann die Vorliebe verstehen, konservativ zu sein.

Ich möchte jedoch meine Unterstützung hinter so etwas stecken wie

Oft ist nicht das genaue Paket von Interesse, sondern die Art des Codes: Ist es Core Julia, eine Bibliothek, die ich verwende, die Bibliothek, die ich entwickle, oder ein Skript? Wir könnten vier Farben haben: core/base/dev/stdlib, Pakete, Pakete, die derzeit ]dev ed sind, und der ganze Rest (einschließlich script/REPL). […]

Da ich nicht auf Basis und selten auf Paketen hacke (wie die meisten Leute es tun, nehme ich an), müssen 90% der Fehler in meinem Skript behoben werden, 9% in einem Paket und 1% in Basis. Wenn ich einen Fehler beim Aufrufen einer Funktion gemacht habe, muss ich hier in der Basis nicht genau wissen, dass der Fehler ausgelöst wurde, da ich dort sowieso nicht hineingehe, um ihn zu beheben, ich muss meinen Code korrigieren.

Ich würde mich also über einen visuellen Helfer freuen, um zu sehen, wo ich meinen Code hinterlasse (und vielleicht auch, wo ich den Paketcode hinterlasse, um in die Basis zu gehen), da ich in den meisten Fällen alles danach ignorieren kann. Wenn nicht über Farbe, vielleicht mit -------------------------------------------- oder so? Es sollten immer nur 2-3 davon sein.

Wenn Module verfärbt werden, sollte Base/Core vielleicht weggelassen werden und keine Farbe erhalten.

Ich mag den Stil, bei dem das gleiche Modul gleich gefärbt ist und die Farben durchläuft, eigentlich ganz gut

Damit komme ich auch gut zurecht. Wenn wir viele Farben verwenden, sollten sie meiner Meinung nach dafür verwendet werden. Es hilft auch, Grenzen zwischen Benutzer- und Paketcode zu erkennen, ohne zu viel vertikalen Platz einzunehmen.

Wenn Module verfärbt werden, sollte Base/Core vielleicht weggelassen werden und keine Farbe erhalten.

Ja, Base und Core könnten einfach immer dunkelgrau oder so sein, so dass mehr Farben für alle anderen übrig bleiben :)

Wenn dies aufhört, perfekt in 16 Farben zu funktionieren, ist es vielleicht schön, sie zu einem Hash der Modulnamen zu machen, damit Sie sich einige davon merken können.

Oder haben Sie nur zwei Farben, eine für Base/Core und eine für externe Module?

Ich denke, es sollte kein großes Problem sein, Farben zu wechseln, da meine aktuelle Version 6 Nicht-Graustufen-Optionen hat:

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

Ich denke, es gibt auch helle Varianten, aber mein Farbschema in VSCode (Material) hat sie genauso eingestellt wie die dunkleren Geschwister, daher gehe ich davon aus, dass dies in einigen Schemata passieren könnte. Aber wie wahrscheinlich ist es, dass ein Stack-Trace mehr als 6 verschiedene Nicht-Basis- oder Nicht-Standard-Bibliotheksmodule durchläuft? Natürlich Pakete verwenden , um Code aus vielen Modulen, aber in einem bestimmten Stapel sollte es nicht so viele sein. Zumindest sollte das bei der Entschlüsselung des Stacktraces kein großes Problem darstellen, auch wenn es zu Farbkollisionen kommt.

dann ist es vielleicht schön, sie zu einem Hash der Modulnamen zu machen, damit Sie sich einige davon merken können

Das ist tatsächlich irgendwie genial.

Schön zu sehen, wie Leute daran arbeiten.
Mich würde interessieren, wie die richtige Ausrichtung der Funktionsnamen aussieht:

 [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

Es ist möglicherweise einfacher für das Auge, zu erkennen, wo die Funktionsargumente beginnen, und bietet Hilfe beim Analysieren der Kette von Funktionsaufrufen, ohne viel Platz zu verschwenden. Es muss noch durch Farben unterstützt werden, sonst würden die Ortsinfos und Argumente alles übertönen.

dann ist es vielleicht schön, sie zu einem Hash der Modulnamen zu machen, damit Sie sich einige davon merken können

Das ist tatsächlich irgendwie genial.

Oh, hallo dunkelgrün, mein alter Freund...

dann ist es vielleicht schön, sie zu einem Hash der Modulnamen zu machen, damit Sie sich einige davon merken können

Früher habe ich emacs genau das für IRC-Spitznamen machen lassen. Es hat nicht so gut geklappt, weil einigen meiner Freunde die gleiche Farbe zugewiesen wurde und es verwirrender war als alles andere, also habe ich letztendlich Farben für meine Freunde hart codiert. Ich würde nicht empfehlen, diesen Weg zu gehen, auch wenn er cool erscheint. Ein reduzierter Satz von Farben für jeden Codetyp (zB Julia, Paket, entwickeltes Paket, Benutzer) scheint nützlicher zu sein.

Ich bin auf ein Editor-Farbschema gelandet, das dies tut, und es ist mäßig nützlich - alle Variablen, die sonst blau sein könnten, sind verschiedene Schattierungen von Grün und Blau, mit unterschiedlichen Zeichenfolgen und Schlüsselwörtern usw. Das Ideal wäre vielleicht so etwas innerhalb breiter Klassen wie die von Ihnen vorgeschlagenen (zB Standardbibliothek in Rot-Lila, heruntergeladen in Grün-Blau, Entwicklung in Orange-Gelb, Basis in Grau). Oder vielleicht ist das viel zu viel Arbeit!

eine weitere Iteration: Ich habe versucht, Variablennamen hineinzubekommen, obwohl sich alles für mich sehr hackig anfühlt, da ich mit allen Interna nicht sehr vertraut bin. Ich habe die Module neu eingefärbt, weil es allgemein eine positive Resonanz zu bekommen schien, obwohl die Zuordnung der Farben fraglich ist. Aber bei den Farben habe ich das Gefühl, dass das Modul eines Eintrags etwas mit dem Funktionsnamen des nächsten kollidiert. Also habe ich Zeilenumbrüche eingeführt. Macht natürlich alles länger, aber irgendwie mag ich die zusätzliche Luft zum Atmen und die Klarheit

Ich mag dein letztes Beispiel, es ist sehr klar und lesbar :)

Unten ist nur ein Experiment, das die Modulfärbung auf das "@" anstelle des Modulnamens anwendet, um den von Ihnen erwähnten Konflikt mit dem Funktionsnamen zu reduzieren, und das Hervorheben der Typen, damit der Pfad etwas leichter unterschieden werden kann, ohne ein Leerzeichen einfügen zu müssen Linien.

@jkrumbiegel Das ist schön. Ich brauche das in meinem Leben.

Ich mag diesen sanften Blues

@jkrumbiegel Toll, ich bin mir nicht sicher, ob das @-Symbol benötigt wird, es könnte ohne es sauberer aussehen. Wenn Sie erklären möchten, was diese Informationen sind, können Sie sie genauso gut schreiben, wie Jeff vorgeschlagen hat:
in MakieLayout at ~/.julia/packages/MakieLayout/COfBu/src/lineaxis.jl:372

@jkrumbiegel Das sieht toll aus! Gibt es eine Möglichkeit, nur den Dateinamen (nicht den vollständigen Pfad) und die Zeilennummer hervorzuheben? Vielleicht ein etwas helleres Grau?

Schön! Ich mag die Zeilenumbrüche wirklich sehr – sie helfen optisch wirklich und unsere Stack-Traces sind in der Regel so lang, dass ich sowieso scrollen muss, ich wäre lieber klar, als das Scrollen ein wenig zu reduzieren.

Die hervorgehobenen :: sind brillant. Wenn ich eine Kurve zeichnen müsste, die den Informationsgehalt jedes Zeichens der Parameterliste gegen die Zeichenposition zeigt, markieren die :: genau die lokalen Maxima dieser Kurve. Ich weiß, links davon nach dem Namen und rechts nach dem wichtigsten Teil des Typs zu suchen, danach sinkt der Informationsgehalt nur noch.

Diesem Kommentar stimme ich nicht zu: Die Hervorhebung sollte wichtige Dinge hervorheben, damit das Auge weiß, was zu lesen ist, und das :: ist definitiv keine wichtige Sache, die ich lesen sollte. So wie es aussieht, ist das Weiß viel auffälliger als das kräftige Dunkelblau. Die Unterscheidung der Parameter wäre klarer, wenn nur die Argumentnamen in Weiß angegeben werden (vielleicht mit der Ausnahme, wenn es kein benanntes Argument gibt, in diesem Fall könnte :: genauso gut in Weiß sein, um Argumente zu begrenzen). Gleiches gilt für die Zeilennummer, ich würde eher den Dateinamen als die Zeilennummer hervorheben.

Die farbigen Paketnamen laufen Gefahr, das Wichtigste, den Funktionsnamen, zu überschatten, aber diese fett und mit Zeilenumbrüchen schränken dieses Risiko wirklich ein, gut gemacht!

Ich habe viel über die :: nachgedacht, bevor ich sie weiß gemacht habe. Natürlich sind die Argumentnamen und die Typen die eigentlichen Informationen, so dass Sie vielleicht denken, dass sie hervorgehoben werden sollten. Aber mein starker Eindruck beim Hervorheben ist, dass sie Ihre Aufmerksamkeit erfordern. Aber es ist nicht wichtig, jeden Namen und Typ zu lesen. Sie sollten nur in der Lage sein, diejenigen zu finden, die Sie in einer bestimmten Funktion suchen. So sehe ich die Schritte zum Lesen eines Stack-Trace:

1. Verschaffen Sie sich einen allgemeinen Überblick
2. Welche Funktion in welchem ​​Modul fehlerhaft?
3. Welche anderen Funktionen rufen diese Funktion von welchen anderen Modulen auf?
4. Gibt es eine kritische Grenze zwischen meinem eigenen Code und Basis- oder anderem Paketcode? Wo ist es?
5. Welche Funktion hat diese Grenze?
6. Welche Typen/Argumente wurden verwendet? Wo endet ein Argument und wo beginnt das nächste? Dies ist gerade bei langen parametrischen Typen besonders schwierig.
7. Erklärt das den Fehler?
8. Wenn das nicht geholfen hat, alles mit einem feinen Kamm durchgehen

Die Typ-/Argumentinformationen werden meiner Meinung nach also erst nach Orientierung und Verständnis der allgemeinen Struktur verwendet. Beim Hervorheben ist zu beachten, dass es das Auffinden von Dingen nicht unbedingt einfacher macht, nur wenn die Hervorhebungen relativ spärlich sind. Daher denke ich, dass das ::-Highlight nicht im Weg steht und Ihre Aufmerksamkeit erregt, bis Sie anfangen, nach Variablen- / Typinformationen zu suchen. Und bei diesem Schritt gibt es Ihren Augen Haken zum Springen, nicht mehr und nicht weniger. Das finde ich recht effizient.

Als Randnotiz hat nicht jedes Argument einen Namen, daher würde das Hervorheben von Variablennamen nicht immer eine gute Trennung ergeben. Ich denke, das :: ist immer da.

Das scheint eine gute Liste zu sein, meine Hauptbeschwerde ist Punkt 6, die Lücken in langen Schriftsignaturen zu finden. Es hilft, :: superhell zu drucken, obwohl ich zustimme, dass es ein wenig seltsam ist. Das Drucken der Argumentnamen (oder vielleicht eines Platzhalters für _1 falls keiner) würde ein wenig helfen. Vielleicht würde das normale Drucken des äußersten Typs und dann alle seine Argumente in Grau sehr hilfreich sein?

Wie viele Hervorhebungsstufen stehen tatsächlich zur Verfügung? :white wird auf hellen Hintergründen nicht auffallen, tatsächlich denke ich, dass wir uns auf normale, fette und :light_black (plus Farben) beschränken können. Im Moment sind der Funktionsname und der Pfad fett gedruckt. In @error usw. ist der Pfad light_black, was großartig erscheint.

Ich mag die Verwendung von Farbe, um Module hervorzuheben. In einigen der obigen Beispiele überstrahlt es den anderen Text, aber gilt das auch für einfache Farben? In einigen verschiedenen Themen ist "Module" hier relativ stumm (und ::Array, ::Adjoint, ::Int ziemlich eindeutig die Top-Level-Signatur):

    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

eine weitere Iteration: Ich habe versucht, Variablennamen hineinzubekommen, obwohl sich alles für mich sehr hackig anfühlt, da ich mit allen Interna nicht sehr vertraut bin. Ich habe die Module neu eingefärbt, weil es allgemein eine positive Resonanz zu bekommen schien, obwohl die Zuordnung der Farben fraglich ist. Aber bei den Farben habe ich das Gefühl, dass das Modul eines Eintrags etwas mit dem Funktionsnamen des nächsten kollidiert. Also habe ich Zeilenumbrüche eingeführt. Macht natürlich alles länger, aber irgendwie mag ich die zusätzliche Luft zum Atmen und die Klarheit

Könnte etwas abseits vom Thema sein, aber da wir das haben, können wir ein hübscheres show für die Ausgabe von methods und methodswith ? Es ist auch ein Schmerz.

Auch die Farbe von Modulen könnte eine gedimmte Farbe sein, wie nicht exakt gelb, sondern grau-gelb. Oder können wir diese Farben konfigurierbar haben, in etwa startup.jl ?

@jkrumbiegel Das sieht toll aus! Gibt es eine Möglichkeit, nur den Dateinamen (nicht den vollständigen Pfad) und die Zeilennummer hervorzuheben? Vielleicht ein etwas helleres Grau?

Es könnte: https://github.com/JuliaLang/julia/issues/36026#issuecomment -634481656. Aber es ist ein bisschen seltsam für mich, da der Dateiname Teil des Pfads ist. Warum verwendet er also eine andere Farbe? Normalerweise klicke ich einfach auf den Pfad und VSCode öffnet ihn für mich, sodass es egal ist, welchen Namen die Datei hat.

Ich habe mich von Crayon.jl abgewendet, da ich keine komplexen Farben mehr verwende. Hilft auch bei der Ladezeit des Pakets. Ich habe einen Weg gefunden, die Sichtbarkeit von Dateinamen und Zeilennummer zu verbessern, ohne dass sie visuell überwältigend werden, indem ich sie in Dunkelgrau unterstreiche. Das sieht auch vernünftig aus, da wir es gewohnt sind, dass Pfade / Links unterstrichen werden. Weiß oder andere Hervorhebungen waren dort zu stark, fett zu schwach.

Außerdem habe ich im Cycler als erste Farben auf helle Farben umgestellt, was ich eigentlich hätte tun sollen, aber in meinem Theme sehen sie gleich aus, sodass ich es nie bemerkt habe. Dies sollte für Themes besser sein, bei denen Dunkelblau kaum sichtbar ist (das ist jedoch die Schuld des Themes).

Ich habe diesen Stil als Version 0.2 in ClearStacktrace.jl registriert, damit wir ihn noch ein bisschen ausprobieren können.

Zwei Beispiele:

Das ist wirklich schöne Arbeit.
Sie haben die Parameternamen heller und die Typen dunkler. Ist das so besser/lesbar besser geworden als mit den helleren Typen und den dunkleren Namen?

Ja, da die Typen meist viel länger sind, hilft es nicht viel, sie leichter zu machen.

Zufällige Gedanken:

• vielleicht horizontale Regeln zwischen Gruppen von Stack-Trace-Einträgen im selben Modul? vielleicht zu beschäftigt mit suchen
• könnte auch oben im Stacktrace gut sein, um es klar von der Fehlermeldung zu trennen

All dies ist so viel besser als das, was wir jetzt haben ...

Ich habe mich von Crayon.jl abgewendet, da ich keine komplexen Farben mehr verwende. Hilft auch bei der Ladezeit des Pakets.

Hat es eine erhebliche Ladezeit verursacht? Bei mir lädt es ziemlich schnell von alleine

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

Diese Version ist großartig, lass uns das in Base einfügen.

Zustimmen: Lass uns einfach die letzte Version machen.

Danke für die ganze Arbeit hier, @jkrumbiegel . Toll, eine Version zu haben, die wir ausprobieren können...

Und fork: Ich denke, es liegt ein bisschen daran, dass rand(5) .* rand(7) plus Fehler 35 Zeilen belegt? Also habe ich https://github.com/mcabbott/ClearStacktrace.jl/tree/milder zum Ausprobieren gemacht. (Plus Farbprobleme usw., die oben erörtert wurden.) Dies ist fast https://github.com/JuliaLang/julia/issues/36026#issuecomment -635294818 mit mehr Farben.

Beachten Sie, dass im aktuellen Stacktrace die Druckbilder 8-11 in diesem Beispiel nicht gezeigt werden (sie sind Teil des REPL und wären in jedem REPL-Stacktrace enthalten).

Dies hat sich in der Tat verbessert, was großartig ist. Aber es geht immer noch von 8 Zeilen (nur für den Stacktrace) auf 20 (ClearStacktrace 0.2). Es gibt einen kleinen Kompromiss zwischen wie schön es ist und nicht Ihren Platz zu verlieren.

Außerdem werden die Pfade in Base viel kompakter gedruckt, ./broadcast.jl:495 statt //Applications/Julia-1.5.app/Contents/Resources/julia/bin/../share/julia/base/broadcast.jl:495 , dies würde auch den Bedarf an Leerzeilen reduzieren.

Die Basispfade werden absichtlich erweitert, um sie anklickbar zu machen. Sie können dies in ClearStacktrace deaktivieren. Ich könnte die Zeilenumbrüche auch optional für Leute machen, die sie nicht mögen. Könnte nur eine Umgebungsvariable sein.

Und ich schätze, ich habe es verpasst, den Teil der Funktion zu kopieren, der die letzten paar Frames abschneidet, die sich nie ändern

Ich habe mich von Crayon.jl abgewendet, da ich keine komplexen Farben mehr verwende. Hilft auch bei der Ladezeit des Pakets. Ich habe einen Weg gefunden, die Sichtbarkeit von Dateinamen und Zeilennummer zu verbessern, ohne dass sie visuell überwältigend werden, indem ich sie in Dunkelgrau unterstreiche. Das sieht auch vernünftig aus, da wir es gewohnt sind, dass Pfade / Links unterstrichen werden. Weiß oder andere Hervorhebungen waren dort zu stark, fett zu schwach.

Außerdem habe ich im Cycler als erste Farben auf helle Farben umgestellt, was ich eigentlich hätte tun sollen, aber in meinem Theme sehen sie gleich aus, sodass ich es nie bemerkt habe. Dies sollte für Themes besser sein, bei denen Dunkelblau kaum sichtbar ist (das ist jedoch die Schuld des Themes).

Ich habe diesen Stil als Version 0.2 in ClearStacktrace.jl registriert, damit wir ihn noch ein bisschen ausprobieren können.

Zwei Beispiele:

Neugierig, warum / extra in //Applications/Julia-1.4.app/ ?

Wahrscheinlich ein Fehler beim Aufteilen und Wiederverbinden des Pfads

Ich habe mich von Crayon.jl abgewendet, da ich keine komplexen Farben mehr verwende. Hilft auch bei der Ladezeit des Pakets.

Hat es eine erhebliche Ladezeit verursacht? Bei mir lädt es ziemlich schnell von alleine

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

  0.014410 seconds (22.60 k allocations: 2.274 MiB)

Nein, ich habe es meistens entfernt, weil ich es nicht in der Basis haben würde :) Die Ladezeit war nur eine Vermutung

Ich denke, es könnte zu viele Leerzeilen geben, wenn wir viele Stacktrace-Frames haben, wie in https://github.com/JuliaLang/julia/issues/36026#issuecomment -636912686 gezeigt?

Um die Diskussion nicht zu entgleisen (die letzte Version ist großartig und eine große Verbesserung), aber zum Thema zu viele Zeilenumbrüche ist das Problem, dass es mir bei der Arbeit am Terminal viel besser erscheint, den Stacktrace "invertiert" zu drucken (wie Ich habe ursprünglich in https://github.com/JuliaLang/julia/pull/18228 vorgeschlagen) als:

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

Die wichtigsten Informationen sind die Fehlermeldung selbst und die Rahmen oben im Stapel (näher am Fehler) und der Druck in dieser Reihenfolge, die immer ohne Scrollen sichtbar ist. Im Moment muss ich häufig nach oben scrollen, um überhaupt die Fehlermeldung zu sehen und nicht nur das Ende eines Stacktrace.

Wenn Sie jedoch einen Stacktrace auf einer Website lesen, der aus dem Terminal kopiert und eingefügt wurde, möchten Sie die umgekehrte Reihenfolge, da Sie von oben nach unten scrollen und nicht wie in einem Terminal von unten nach oben ... gutes Design für beide Fälle.

Wenn Sie jedoch einen Stacktrace auf einer Website lesen, der aus dem Terminal kopiert und eingefügt wurde, möchten Sie die umgekehrte Reihenfolge, da Sie von oben nach unten scrollen und nicht wie in einem Terminal von unten nach oben ... gutes Design für beide Fälle.

Ich hatte tatsächlich für einen Moment Code in ClearStacktrace.jl , der es mir ermöglichte, den letzten Stacktrace erneut zu drucken. Ich hatte mir das vorgestellt, um superlange Schriften bei einem Zeichenmaximum abzuschneiden und in der Lage zu sein, vollständig nachzudrucken, wenn die gesamte Information benötigt wird. Aber dein Anwendungsfall wäre auch interessant. Ich kann mir ein reprint(inverted = true) oder sogar reprint(html = true) vorstellen, wo es eine HTML-Version drucken würde, die die Farbe zum Einfügen in eine Website beibehalten würde.

Außerdem stimme ich zu, dass es angesichts der Scrollrichtung sinnvoll sein könnte, das Ganze standardmäßig umzukehren.

ipython druckt Frames in umgekehrter Reihenfolge, und obwohl ich nicht scrollen musste, fand ich es immer unerklärlicherweise verwirrend. Vielleicht liegt das nur an meiner vorherigen Erfahrung mit gdb und anderen Systemen, bei denen der innerste Frame oben ist, oder denken andere vielleicht auch so?

Apropos gdb, sie haben mit ihrem Pager eine vernünftige Lösung für sehr lange Traces: "Drücke Enter für mehr Frames".

Ich liebe übrigens das neueste visuelle Design in https://github.com/JuliaLang/julia/issues/36026#issuecomment -636912686 und würde mich sehr freuen, wenn wir das zusammenführen. Das Ändern der Frame-Reihenfolge oder das Hinzufügen interaktiver Funktionen scheinen separate Probleme zu sein.

Was Dateinamen angeht, hoffe ich, dass wir irgendwann OSC-Sequenzen für Terminal-Hyperlinks verwenden können ( ja, Hyperlinks in Terminals werden ziemlich weit verbreitet! ) und eine Möglichkeit für den Editor des Benutzers haben, dies zu erkennen.

Apropos das "innerste Frame" zu finden: Ich verwende im Laufe meiner Arbeit genügend Sprachen, sodass ich mich nie erinnern kann, ob ich oben oder unten in einem Stacktrace nach meinem Code in einer bestimmten Sprache suchen sollte. Am Ende scanne ich den Dateinamen, bis ich einen sehe, den ich erkenne. Die hier gezeigte Unterstreichung würde helfen, also ist dies eine klare Verbesserung. Aber ich frage mich immer noch, ob es eine gute Möglichkeit gibt, zu sagen, ob ich nach oben oder unten schauen sollte. Im Prinzip würde mir das Drucken von YOUR CODE HERE an einem Ende und OTHER CODE HERE am anderen Ende helfen, aber es scheint nicht sehr elegant zu sein.

Ich habe hier eine PR zu Base gemacht https://github.com/JuliaLang/julia/pull/36134
Es funktioniert soweit ich das beurteilen kann, aber ich benötige etwas Hilfe, um es für die Zusammenführung vorzubereiten

Gibt es eine Möglichkeit, Typparameter wegzulassen? Das Problem, das wir oft sehen, ist, dass die Menge an Typparametern in DiffEq, ForwardDiff usw. die Dinge ... entmutigend machen kann. Wenn standardmäßig nur Dual angezeigt wird, außer in dem Fall, dass aufgrund von Typparametern an andere Methoden gesendet wird, dann würden Sie meiner Meinung nach 90% des Rauschens in den meisten Stack-Traces reduzieren, die ich lese (und in In den anderen Fällen ist der Vorschlag von @timholy wirklich erforderlich, da es normalerweise darum geht, Typen zu Typparameter abzugleichen. )

Wenn sie einem vorhandenen Typalias entsprechen, werden sie jetzt einfach automatisch entfernt (#36107). Andernfalls weisen sie auf mögliche Engpässe bei der Kompilierungsleistung hin – also möglicherweise eine Untersuchung wert?

Dies ist jetzt erledigt.

Für einige Leute, aber die meisten Leute sind einfach verwirrt, wenn eine Sorte gedruckt wird, die 3 Seiten bedrucktes Papier benötigt, also sollte es wahrscheinlich etwas sein, das aktiviert werden kann. Ich werde ein anderes Thema eröffnen, um das zu diskutieren.

Fortsetzung in https://github.com/JuliaLang/julia/issues/36517