Julia: Que faut-il pour inclure ClearStacktrace.jl dans Base ?

Ce serait vraiment sympa d'avoir. Ou au moins peut-être une version réduite qui améliore l'impression des traces de pile par défaut dans Base.

Je suis tout à fait d'accord. La principale chose que je ne comprends pas, ce sont les couleurs des signatures. Ils semblent... aléatoires ? Je suppose que les différentes couleurs sont là pour faciliter la sélection des différents éléments, mais c'est un peu bizarre. Qu'en est-il de la couleur == profondeur d'imbrication ? Je pense que la principale bizarrerie réside par exemple dans Tuple{Symbol,Symbol} où les deux Symbol sont de couleurs différentes.

Il y a une autre chose que j'aimerais vraiment voir :

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

mais depuis

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

il semble que nous devrions pouvoir imprimer l'entrée 2 comme quelque chose comme

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

Un petit commentaire, mais pour moi c'est actuellement peut-être un peu trop de couleur "salade". Le compteur stackframe étant bleu, toutes les couleurs différentes dans la signature, etc.

Bonnes suggestions dans l'ensemble. Peut-être quelques commentaires sur les raisons pour lesquelles j'ai fait les choix de couleurs jusqu'à présent :

Les chiffres sont bleus parce qu'ils sont importants, ils ne devraient donc pas être grisés, mais les rendre blancs m'a semblé comme s'ils se battaient pour attirer l'attention avec les noms des fonctions.

Les modules utilisent les couleurs primaires dans un cycle, je pense que c'est très utile car cela permet de filtrer rapidement la trace pour les modules pertinents. C'est quelque chose qui est très lié au format de trace de pile actuel. L'idée est que les gens soient obligés de lire le moins possible pour trouver ce qu'ils cherchent. (J'ai surtout fait des recherches sur les mouvements oculaires et l'attention dans ma vie universitaire jusqu'à présent, donc ces aspects sont importants pour moi ;) )

Les couleurs des signatures sont très discutables. Ceux sur la capture d'écran ci-dessus ont été choisis pour n'être que légèrement différents du gris foncé. En même temps, je voulais que les différentes composantes sémantiques soient discriminantes. C'est pourquoi tous les types et paramètres de type (accolades et virgules) provoquent un changement de couleur. Il y a trois couleurs, ce qui signifie qu'il n'y aura pas deux voisins de la même couleur. J'ai trouvé qu'il est assez difficile de distinguer des mots isolés dans des signatures énormes s'ils sont tous simplement blancs. Les nuances légèrement différentes aident beaucoup mais rendent également tout un peu plus bruyant, visuellement.

Comme le jeu de 16 couleurs n'a pas de couleurs qui ne sont que légèrement différentes du gris foncé, ce n'est probablement pas quelque chose qui peut être inclus dans Base. Dans une mise à jour récente, j'ai remplacé les couleurs par trois nuances de gris légèrement différentes de l'ensemble ANSI, mais même cela ne sera pas pris en charge partout, je suppose.

Oh aussi, la couleur du cadre de pile et les couleurs du module ainsi que le gris foncé et le blanc sont toutes des couleurs système. C'est juste mon thème VSCode particulier qui les rend comme vous le voyez ici.

Ce serait génial d'avoir.

Lors de l'analyse des types d'arguments, il est souvent assez difficile de savoir où l'on s'arrête et où commence le suivant. Colorer le niveau supérieur différemment peut être très utile ici, et peut-être même numéroter les arguments :

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

Nous devrions pouvoir afficher les noms des arguments, comme nous le faisons dans l'impression de methods(f) .

comment c'est? J'ai remplacé les couleurs de signature par du gris foncé, mais le :: est blanc, il est donc important là où les types d'argument commencent. particulièrement utile avec le monstre de type à la position 11

Je l'aime bien. Sera encore mieux avec les noms d'argument.

C'est dommage que l'ordre "fonction - module - arguments" fonctionne si bien pour la mise en page mais n'a pas vraiment de sens sémantiquement. Je n'ai pas de solution cependant; il est clair qu'il est préférable que la fonction passe en premier. Peut-être que le module pourrait passer à la ligne suivante avant l'emplacement du fichier ? Cela fait partie de l'emplacement après tout. Alors peut-être que nous n'aurions pas besoin de l'en-tête non plus.

Je pense que nous pourrions également mettre les nombres en texte normal et les noms des fonctions en gras et/ou en blanc.

Le nom de fichier à la fin du chemin de code (et éventuellement le numéro de ligne) pourrait-il également avoir sa propre couleur plus claire ?

Peut-être que le module pourrait passer à la ligne suivante avant l'emplacement du fichier ? Cela fait partie de l'emplacement après tout. Alors peut-être que nous n'aurions pas besoin de l'en-tête non plus.

Je vais essayer quelques trucs avec ces suggestions.

Le nom de fichier à la fin du chemin de code (et éventuellement le numéro de ligne) pourrait-il également avoir sa propre couleur plus claire ?

C'est techniquement possible bien sûr ;) C'est toujours un compromis entre une meilleure visibilité et un bruit qui attire l'attention.

Pourquoi ne pas écrire les modules en premier, puisqu'ils font partie du nom complet de la fonction ? Peut-être qu'avec la couleur, il peut être assez clair pour écrire simplement Core.eval etc, ou ils pourraient toujours être alignés en colonnes. (Ou peut-être avez-vous essayé ceci et cela avait l'air affreux.)

Pensée vraiment folle : si l'impression des types d'arguments prendrait plus d'une ligne, imprimez la signature sous forme pliée, puis utilisez REPL.TerminalMenus pour permettre aux téléspectateurs de la développer. Quelque chose comme:

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

Connexe: #35915 (que je prévois d'utiliser pour créer un menu en arbre plié, https://github.com/JuliaCollections/FoldingTrees.jl).

À quoi cela ressemble-t-il avec le chemin de code réorganisé dans cet ordre : LineNumber Filename Path
Ensuite, vos yeux ont un emplacement stable pour rechercher le numéro de ligne et le nom de fichier sans aucune couleur supplémentaire nécessaire pour eux (je semble toujours rechercher le nom de fichier et le numéro de ligne enfouis dans les détails, pouvez-vous le dire ?)
Et pour le travail REPL interactif j'adore l'idée pliée ci-dessus :)

Pourquoi ne pas écrire les modules en premier, puisqu'ils font partie du nom complet de la fonction

Ouais j'aime bien l'idée, je pense que j'ai commencé sans couleur et ça n'a pas très bien fonctionné, mais comme ça c'est en fait assez lisible. J'essaierai ensuite sans colonnes, même si les colonnes sont toujours agréables car elles guident votre regard.

Pas sûr de ça ; le nom de la fonction est une information bien plus importante que le module. Pour moi au moins, l'information la plus importante est certainement le nom de la fonction, le nom du fichier et le numéro de ligne. De plus, pour les scripts, la colonne de gauche contiendrait beaucoup de Main ou vide, ce qui n'est pas idéal pour ce cas d'utilisation.

Je pense que lorsque je lis stacktraces, je recherche principalement le dernier appel dans mon code avant qu'il ne passe au code Base/package, car le bogue est généralement dans mon code. Donc, dans ce cas, le module est assez important et l'appel de fonction n'est pas ce que je scanne en premier.

Que dis-tu de ça:

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

Les noms de module seraient toujours alignés afin qu'ils soient faciles à numériser.

En fait, je venais d'essayer quelque chose de proche de ça. J'ai coloré les noms de fonction eux-mêmes cette fois, ils sont donc toujours les plus saillants mais portent les informations du module dans leur couleur. Il y a donc toujours un regroupement évident, mais avec moins d'accent sur tous les noms de modules.

La première fois que j'ai vu que je deviendrais probablement fou en essayant de comprendre ce que signifiaient les couleurs :joy: S'il doit y avoir des couleurs par module, il semble préférable d'appliquer la couleur au nom du module.

J'aime les noms des modules, ils se perdent un peu dans cette dernière photo.

S'ils sont en bas, peut-être que leur donner la même couleur vive relierait les choses ? (Et indiquez clairement où vous traversez une limite de module.) Et, peut-être, si le nom du module apparaît dans le chemin, il pourrait simplement être mis en surbrillance à la place - cela déplacerait également le nom coloré du bord gauche où se trouvent les fonctions.

Pour m'inspirer, je poste quelques images de la dernière fois que la mise en forme de stacktrace a été modifiée.

Souvent, le package exact n'a pas tant d'intérêt que la nature du code : est-ce le noyau Julia, une bibliothèque que j'utilise, la bibliothèque que je développe ou un script ? Nous pourrions avoir quatre couleurs : core/base/dev/stdlib, packages, packages actuellement ]dev ed, et tout le reste (y compris script/REPL). Certaines de ces distinctions sont assez arbitraires et la classification est un peu fragile, mais colorer la méthode en fonction de cela maximiserait (au moins pour moi) les informations sans afficher de texte supplémentaire et en gardant un petit jeu de couleurs facile à mémoriser.

Pour moi, les couleurs concernent davantage les changements de limites, où le code d'un module commence et l'autre se termine. C'est pourquoi je ne leur attribuerais probablement pas de sens inhérent. D'un autre côté, cela peut prêter à confusion.

J'ai essayé de simplifier davantage et j'ai à nouveau supprimé des colonnes car sans la colonne de module, elles ne sont plus si utiles. Ensuite, j'ai d'abord coloré uniquement le numéro de ligne par modules, mais cela laissait toujours le nom du fichier moins visible, ce que de nombreux commentaires ont dit être important. J'ai donc aussi coloré cela dans la couleur du module. Le nom du module lui-même n'est pas coloré car il est trop proche du nom de la fonction et c'est trop bruyant.

Voici la version avec les numéros et les noms de fichiers en couleur :

ici sans les noms de fichiers colorés

Pouvez-vous également essayer de colorer le chemin complet du fichier ?

Quelques idées...
Nom de fichier et numéro de ligne dans un emplacement cohérent avec des espaces doubles pour les mettre en valeur.
La couleur au niveau de la pile et la couleur du module se correspondent pour associer visuellement les lignes associées.
Nom de fichier, numéro de ligne et chemin dans une teinte légèrement différente des types de paramètres pour distinguer sans encombrement.

[Les couleurs dans cet exemple sont arbitraires, pensant davantage à la relation entre leurs positions.
Les niveaux de pile manquants dans l'exemple et la liste de types de paramètres raccourcie sur le dernier élément sont dus au fait que j'ai tapé l'exemple à la main.]

Code utilisé pour produire l'exemple ci-dessus au cas où quelqu'un voudrait jouer avec :

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

Le problème avec ceci est que cela ne laisse pas les liens cliquables dans Atom / VSCode, etc. C'est quelque chose que j'utilise très souvent et je pense que d'autres le font aussi. En fait, j'étends même explicitement les chemins de base pour les rendre cliquables. Cela n'imprime bien sûr plus. Mais je pense que cela augmente l'utilité. Je sais qu'il existe un moyen de sauter pour empiler les entrées de trace par numéro dans le REPL avec un raccourci, mais c'est beaucoup moins intuitif que de simplement cliquer sur un lien à mon avis.

Il peut être judicieux de profiter de l'occasion pour unifier la façon dont les informations de ligne sont imprimées avec le système de journalisation, par exemple :

Notez également que le système de journalisation contracte le répertoire homedir

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

Je pense qu'il y a deux idées de base dans la proposition ici :

• Ayez les informations de ligne sur une ligne distincte de la signature (et peut-être délimitez-la avec une couleur pour la rendre plus facile à trouver).
• Montrez le module.

Voici donc une tentative légèrement plus conservatrice avec ces deux idées :

Une version avec des noms de variables ajoutés et une couleur uniquement sur les noms de module (mais correspondant sinon à la façon dont @info imprime les chemins):

Celui-ci n'a pas de signatures de type très longues, mais peut-être qu'avoir des noms de variables comme celui-ci (si c'est possible ?) facilitera la détection du type le plus externe de chaque argument.

S'il y a trois niveaux de neutre disponibles (comme gras/normal/gris), alors l'impression du chemin du fichier plus légèrement que la signature semble (IMO) comme un bon moyen d'empêcher les choses de fonctionner ensemble. (C'est aussi ce que fait @info .)

 laisser
 printstyled("\njulia> ", color=:green)
 println("f()")
 printstyled("""ERREUR : DimensionMismatch("A a des dimensions (1,2) mais B a des dimensions (3,4)")""", color=:light_red)
 println("\nStacktrace :")
 pour (idx, err) dans énumérer (erreurs)
 mc = idx <= 3 ? :bleu : (idx >= 7 ? :bleu : :jaune) # Couleur du module
 printstyled("[$(err[1])] ", color=:normal, bold=true) # errorno
 printstyled(err[2], color=:normal, bold=true) # fonction
 printstyled("(", color=:normal) # types de paramètres
 pour (i,t) dans énumérer(err[3])
 i != 1 && printstyled(", ", color=:normal)
 printstyled(rand('a':'z')^2, color=:light_black)
 printstyled("::", color=:normal)
 printstyled("$t", color=:normal)
 finir
 printstyled(")", color=:normal)
 println()
 printstyled(" @ ", color=:light_black)
 printstyled(err[6], color=mc) # module
 printstyled(" $(err[7])/$(err[5]):$(err[4])", color=:light_black) # chemin
 println()
 finir
 finir

Je pense qu'il y a deux idées de base dans la proposition ici :

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

Voici donc une tentative légèrement plus conservatrice avec ces deux idées :

J'aime ça. Je pense que le terme est "tuez vos chéris", et ma chérie pourrait être la couleur. Mais je peux voir comment quelque chose d'atténué pourrait être mieux adapté à quelque chose d'aussi basique. Je l'ai légèrement modifié pour que le nom du module et le nom de la fonction s'alignent, ce qui crée une ligne de contraste verticale presque en forme de colonne. Cela devrait aider à trouver les informations pertinentes. Bien que je pense toujours que je ne mettrais pas les types en blanc, car ils deviennent si désordonnés. Si nous avions des noms de variables, peut-être que ceux en blanc auraient l'air bien.

J'aime ça. Je pense que le terme est "tuez vos chéris", et ma chérie pourrait être la couleur.

Juste pour que vous sachiez que je connais votre situation, https://github.com/JuliaLang/julia/pull/18228. C'est un sujet qui est très amusant à bikeshed et tout le monde a un seau de peinture, heh. Comme vous pouvez le voir, ces relations publiques ont également commencé de manière assez ambitieuse, mais sont lentement devenues de plus en plus conservatrices.

Pour moi, la dernière proposition est définitivement une amélioration par rapport au statu quo. Deux choses auxquelles je pense :

• Si possible, ce serait bien d'avoir une sorte de "crochet" pour vos yeux pour les informations de ligne, car elles ont tendance à se fondre avec la signature lorsque la signature est longue.
• Nous devrions probablement aligner les numéros de stackframe lorsqu'il y en a plus de 10 :
  [ 8] [ 9] [10] [11]
  etc. Cela ferait également aligner les @ .

J'aime ça, je pense que nous arrivons quelque part. Il est toujours bon d'être judicieux avec les couleurs, car cela expose moins de surface pour le bikeshedding, et diminue le risque qu'une couleur soit illisible sur le terminal de quelqu'un.

Espacer les choses est bien, mais malheureusement, la syntaxe f (...) est explicitement interdite, donc je pense que nous devons soit supprimer l'espace, soit supprimer les parenthèses.

L'échantillon le plus récent semble généralement bon, mais je seconde l'idée :

Si possible, ce serait bien d'avoir une sorte de "crochet" pour vos yeux pour les informations de ligne, car elles ont tendance à se fondre avec la signature lorsque la signature est longue.

Et j'espère que ce crochet est d'une couleur ou (de préférence) d'une luminosité différente.

Peut-être que vous pourriez faire le cycle de couleurs pour les modules mais ne l'appliquer qu'aux [ ] de chaque côté du numéro de niveau de pile, donc si vous ne pouvez pas voir les couleurs pour une raison quelconque, peu de choses sont perdues.

Peut-être pourriez-vous faire le cycle de couleurs pour les modules mais ne l'appliquer qu'aux [ ]

Il est même difficile de voir correctement la couleur s'il ne s'agit que de crochets et qu'ils sont dans une zone contrastée, donc je ne pense pas que cela fonctionne trop bien.

la syntaxe f (...) est explicitement interdite

Je pense que cela fonctionne bien même sans espace, à cause de la différence de contraste.

Si possible, ce serait bien d'avoir une sorte de "crochet" pour vos yeux pour les informations de ligne

Je suis d'accord, je pense que cela fonctionne bien de laisser les numéros de ligne en gris mais en gras, cela les rend légèrement saillants si vous les recherchez, mais la prochaine étape pour les rendre blancs est beaucoup trop bruyant à mon avis.

Nous devrions probablement aligner les numéros de stackframe

Je l'ai essayé avec des espaces à l'intérieur des parenthèses comme dans votre exemple, mais j'ai trouvé que cela avait l'air un peu bizarre, alors maintenant j'aligne juste les nombres entre parenthèses. Je pense que ça marche plutôt bien.

Voici la dernière version avec toutes ces idées intégrées :

Et en prime, voici à quoi cela pourrait ressembler avec des noms de variables (aléatoires). Encore une fois, j'utilise simplement du gris gras car tous ces noms de variables ne devraient pas se battre pour votre attention, mais devraient être un peu discernables si vous les recherchez

J'aime bien où cela va aussi. Je veux juste mettre un vote pour une sorte de mise en évidence du nom du module. En fait, j'aime assez le style où le même module est coloré de la même manière et fait défiler les couleurs (il y a un problème de couleur de graphique ici si vous considérez que deux lignes de trace de pile sont adjacentes comme un bord de graphique entre leurs modules). Cependant, la signification de cette couleur n'est malheureusement pas assez évidente. Peut-être colorier tous les noms de modules en une seule couleur ?

Cet alignement me semble bon.

Je pense toujours qu'avoir les chemins plus clairement distincts des signatures aiderait à casser les choses - 3 niveaux d'importance, nom/signature/chemin. Les macros de journalisation @info etc. les impriment plus claires que les autres lignes.

Les noms de variables seraient extrêmement agréables à avoir. Voteraient-ils pour qu'ils soient moins importants que les informations de signature, probablement ?

L'alignement des noms de modules sur la gauche vous aide à les numériser, même si je suis triste de voir les couleurs disparaître.

Mes yeux semblent savoir où trouver des choses sur celui-ci :)
Une ligne vierge entre les modules utiliserait-elle trop d'espace vertical ?

Colorer les rangées avec 2 couleurs différentes afin que les rangées alternées aient la même couleur - comme cela se fait souvent dans les tableaux, peut aider à la lisibilité.

Le cycle de couleurs du @ à côté du nom du module au lieu du nom du module lui-même se démarque (car @ est un assez gros caractère) sans trop rivaliser avec le nom de la fonction en surbrillance.

J'ai souvent souhaité les noms de paramètres car ils vous aident à trouver le bon type de paramètre sans avoir à les compter.

Le chemin (et peut-être le nom du module à côté) pourrait-il être d'une luminosité différente de celle des types ? Peut-être juste en faisant correspondre les noms des paramètres ? (Ou tous ensemble faiblement éclairés si vous faites la suggestion de mcabbott de rendre les noms plus sombres que les types)

Vous pouvez explicitement refléter ce que la journalisation utilise, bien qu'idéalement avec des couleurs différentes :

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

Edit : maintenant avec une ligne plus longue qui s'enroule et une image :

Vous pouvez explicitement refléter ce que la journalisation utilise

Ce que je n'aime pas tant à ce sujet, c'est que les sauts de ligne qui ne sont là qu'en raison de la largeur spécifique de REPL ne se transfèrent pas bien si vous redimensionnez votre fenêtre / REPL (si vous voulez faire de la place pour des lignes plus longues par exemple ) ou copier/coller le texte dans des fenêtres de largeur différente

Oui, je ne proposerais pas explicitement de casser les lignes pour rendre les marqueurs continus. En fait, il peut être judicieux de laisser passer les lignes enroulées et, par conséquent, d'avoir un aspect différent. Surtout une réflexion sur la façon de lier la couleur au nom de la fonction, et comment la rendre peut-être moins gênante, si elle fait partie de la bordure au lieu de ressembler à l'en-tête le plus important.

Je dois dire que j'ai aimé la couleur mais je peux comprendre la préférence d'être conservatrice avec elle.

Je veux cependant apporter mon soutien à quelque chose comme

Souvent, le package exact n'a pas tant d'intérêt que la nature du code : est-ce le noyau Julia, une bibliothèque que j'utilise, la bibliothèque que je développe ou un script ? Nous pourrions avoir quatre couleurs : core/base/dev/stdlib, packages, packages actuellement ]dev ed, et tout le reste (y compris script/REPL). [...]

Comme je ne hacke pas sur base et rarement sur des packages (comme la plupart des gens le font, je présume), 90% des erreurs doivent être corrigées dans mon script, 9% dans un package et 1% dans la base. Si j'ai fait une erreur en appelant une fonction, je n'ai pas besoin de savoir exactement dans la base que l'erreur a été renvoyée car je ne vais pas y aller pour la corriger de toute façon, je dois corriger mon code.

J'apprécierais donc une aide visuelle pour voir où je laisse mon code (et peut-être aussi où je laisse le code du package, en entrant dans la base) car dans la plupart des cas, tout ce que je peux ensuite ignorer en toute sécurité pour le moment. Sinon via la couleur, peut-être avec -------------------------------------------- ou quelque chose ? Il ne devrait jamais y en avoir que 2-3.

Si les modules se colorent, alors peut-être que Base/Core devrait être laissé de côté et ne pas avoir de couleur.

En fait, j'aime assez le style où le même module est coloré de la même manière et fait défiler les couleurs

Je suis d'accord avec ça aussi. Si nous allons utiliser plusieurs couleurs, je pense qu'elles devraient être utilisées pour cela. Cela permet également de déterminer les limites entre le code de l'utilisateur et celui du package sans occuper trop d'espace vertical.

Si les modules se colorent, alors peut-être que Base/Core devrait être laissé de côté et ne pas avoir de couleur.

Oui, Base et Core pourraient toujours être gris foncé ou quelque chose du genre, laissant plus de couleurs pour tout le monde :)

Si cela ne fonctionne plus parfaitement en 16 couleurs, il serait peut-être bien d'en faire un hachage des noms de modules, afin de mémoriser certains d'entre eux.

Ou n'avoir que deux couleurs, une pour Base/Core et une pour les modules externes ?

Je pense que le cycle des couleurs ne devrait pas poser de problème, car ma version actuelle propose 6 options sans niveaux de gris :

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

Il existe également des variantes claires, je suppose, mais mon schéma de couleurs dans VSCode (Matériel) les a définis de la même manière que les frères et sœurs plus sombres, donc je suppose que cela pourrait se produire dans certains schémas. Mais quelle est la probabilité qu'une trace de pile passe par plus de 6 modules de bibliothèque différents non-base ou non-standard ? Des paquets bien sûr utiliser le code de nombreux modules, mais dans une pile particulier , il ne faut pas que beaucoup. Au moins, cela ne devrait pas poser de gros problème lors du déchiffrement de la trace de la pile, même s'il y a des collisions de couleurs.

alors il serait peut-être bien d'en faire un hachage des noms de modules, afin de mémoriser certains d'entre eux

C'est en fait assez brillant.

C'est super de voir des gens travailler là-dessus.
Je serais intéressé de voir à quoi ressemble l'alignement correct des noms de fonction :

 [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

Il peut être plus facile pour l'œil de repérer où commencent les arguments de la fonction et d'offrir une assistance pour analyser la chaîne d'appels de fonction tout en ne gaspillant pas beaucoup d'espace. Il doit encore être soutenu par des couleurs, sinon les informations de localisation et les arguments noyeraient tout.

alors il serait peut-être bien d'en faire un hachage des noms de modules, afin de mémoriser certains d'entre eux

C'est en fait assez brillant.

Oh, bonjour sarcelle foncée, mon vieil ami...

alors il serait peut-être bien d'en faire un hachage des noms de modules, afin de mémoriser certains d'entre eux

J'avais l'habitude d'avoir emacs pour faire exactement cela pour les surnoms IRC. Cela n'a pas très bien fonctionné parce que certains de mes amis ont reçu la même couleur et c'était plus déroutant qu'autre chose, alors j'ai fini par coder en dur les couleurs pour mes amis. Je ne recommanderais pas de suivre cette voie, aussi cool que cela puisse paraître. Avoir un ensemble réduit de couleurs pour chaque type de code (par exemple Julia, package, deved package, user) semble plus utile.

J'ai atterri sur un schéma de couleurs d'éditeur qui fait cela, et c'est modérément utile - toutes les variables qui pourraient autrement être bleues sont différentes nuances de vert et de bleu, avec des chaînes et des mots-clés, etc. différents. Peut-être que l'idéal serait quelque chose comme ça dans des classes larges comme celles que vous suggérez (par exemple, bibliothèque standard en rouge-violet, téléchargée en vert-bleu, dev-ed en orange-jaune, base en gris). Ou peut-être est-ce beaucoup trop de travail !

une autre itération : j'ai essayé d'y inclure des noms de variables, même si tout cela me semble très compliqué car je ne connais pas très bien tous les éléments internes. J'ai recoloré les modules car il semblait avoir une réponse positive en général, même si la manière dont les couleurs doivent être attribuées est discutable. Mais avec les couleurs, j'ai l'impression que le module d'une entrée se heurte un peu au nom de fonction de la suivante. J'ai donc introduit des sauts de ligne. Rend tout plus long bien sûr, mais j'aime un peu la marge de manœuvre et la clarté supplémentaires

J'aime bien ton dernier échantillon, il est très clair et lisible :)

Ci-dessous est juste une expérience en appliquant la coloration du module au "@" au lieu du nom du module pour réduire le conflit que vous avez mentionné avec le nom de la fonction, et en essayant de mettre en évidence les types afin que le chemin puisse être distingué un peu plus facilement sans avoir à introduire de blanc lignes.

@jkrumbiegel C'est magnifique. J'ai besoin de ça dans ma vie.

J'aime ces bleus doux

@jkrumbiegel Génial, je ne suis pas sûr que le symbole @ soit nécessaire, il pourrait sembler plus propre sans lui. Si vous voulez expliquer ce qu'est cette information, vous pouvez aussi bien l'écrire comme Jeff l'a suggéré :
in MakieLayout at ~/.julia/packages/MakieLayout/COfBu/src/lineaxis.jl:372

@jkrumbiegel C'est super ! Existe-t-il un moyen de mettre en évidence uniquement le nom du fichier (pas le chemin complet) et le numéro de ligne ? Peut-être un gris un peu plus clair ?

Beau! En fait, j'aime beaucoup les sauts de ligne - ils aident vraiment visuellement et nos traces de pile ont tendance à être si longues que je dois faire défiler de toute façon, je préfère que ce soit clair que de réduire un peu le défilement.

Les :: surlignés sont brillants. Si je devais tracer une courbe montrant le contenu des informations de chaque caractère de la liste de paramètres par rapport à la position du caractère, les :: marquent exactement les maxima locaux de cette courbe. Je sais regarder à gauche d'eux pour le nom et à droite pour la partie la plus importante du type, après cela le contenu de l'information ne fait que chuter.

Je ne suis pas d'accord avec ce commentaire : la mise en évidence doit mettre l'accent sur les choses importantes pour que l'œil sache quoi lire, et le :: n'est certainement pas une chose importante que je devrais lire. En l'état, le blanc est beaucoup plus visible que le bleu foncé audacieux. Distinguer les paramètres serait plus clair en ayant simplement en blanc les noms des arguments (peut-être à l'exception du cas où il n'y a pas d'argument nommé, auquel cas :: pourrait aussi bien être en blanc pour délimiter les arguments). Idem pour le numéro de ligne, je préfère souligner le nom du fichier que le numéro de ligne.

Les noms de packages colorés risquent d'éclipser la chose la plus importante, le nom de la fonction, mais les avoir en gras et avec des sauts de ligne limite vraiment ce risque, bravo !

J'ai beaucoup pensé aux :: avant de les rendre blancs. Bien sûr, les noms des arguments et les types sont les informations réelles, vous pourriez donc penser qu'ils devraient être mis en évidence. Mais ma forte impression en les mettant en avant est qu'elles retiennent votre attention. Mais il n'est pas important de lire chaque nom et type. Vous devriez juste pouvoir trouver ceux que vous recherchez dans une fonction spécifique. Comment je vois les étapes de lecture d'une trace de pile :

1. Obtenez un aperçu général
2. Quelle fonction dans quel module est erronée ?
3. Quelles autres fonctions ont appelé cette fonction à partir de quels autres modules ?
4. Existe-t-il une limite critique entre mon propre code et le code de base ou d'un autre package ? Où est-ce?
5. Quelle fonction est à cette frontière ?
6. Quels types/arguments ont été utilisés ? Où se termine une dispute et où commence la suivante ? C'est particulièrement difficile avec les types paramétriques longs en ce moment.
7. Cela explique-t-il l'erreur ?
8. Si cela ne vous a pas aidé, passez tout en revue avec un peigne fin

Donc les informations type/argument ne sont à mon avis utilisées qu'après s'être orientés et comprendre la structure générale. Une chose à comprendre à propos de la surbrillance est qu'elle ne facilite pas nécessairement la recherche des choses, uniquement si les surbrillances sont relativement clairsemées. Je pense donc que le point culminant :: ne gêne pas et n'attire votre attention que lorsque vous commencez à rechercher des informations sur les variables / types. Et à cette étape, cela donne à vos yeux des crochets pour sauter, rien de plus, rien de moins. Je trouve ça assez efficace.

En passant, tous les arguments n'ont pas de nom, donc la mise en évidence des noms de variables ne vous donnera pas toujours une bonne séparation. Je pense que le :: est toujours là.

Cela semble être une bonne liste, ma principale plainte est le point 6, trouver les lacunes dans les signatures de type long. L'impression de :: super-lumineux aide, même si je suis d'accord, c'est un peu bizarre. L'impression des noms d'arguments (ou peut-être un espace réservé _1 s'il n'y en a pas) aiderait un peu. Peut-être que l'impression du type le plus externe normalement, puis tous ses arguments en gris, aiderait beaucoup?

Combien de niveaux de surbrillance sont réellement disponibles ? :white ne se démarquera pas sur des fonds clairs, en fait je pense que nous pouvons être limités à normal, gras et :light_black (plus les couleurs). À l'heure actuelle, le nom de la fonction et le chemin sont en gras. Dans @error etc, le chemin est light_black, ce qui semble génial.

J'aime l'utilisation de la couleur pour mettre en évidence les modules. Dans certains des exemples ci-dessus, il éclipse l'autre texte, mais est-ce vrai pour les couleurs simples ? Dans quelques thèmes différents, "Module" ici est relativement silencieux (et ::Array, ::Adjoint, ::Int assez clairement la signature de haut niveau):

    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

une autre itération : j'ai essayé d'y inclure des noms de variables, même si tout cela me semble très compliqué car je ne connais pas très bien tous les éléments internes. J'ai recoloré les modules car il semblait avoir une réponse positive en général, même si la manière dont les couleurs doivent être attribuées est discutable. Mais avec les couleurs, j'ai l'impression que le module d'une entrée se heurte un peu au nom de fonction de la suivante. J'ai donc introduit des sauts de ligne. Rend tout plus long bien sûr, mais j'aime un peu la marge de manœuvre et la clarté supplémentaires

C'est peut-être un peu hors sujet, mais puisque nous avons ceci, pouvons-nous avoir un plus joli show pour la sortie de methods et methodswith ? C'est aussi une douleur.

De plus, la couleur des modules peut être une couleur estompée, comme non pas le jaune exact, mais le gris-jaune. Ou, pouvons-nous avoir ces couleurs configurables, comme, startup.jl ?

@jkrumbiegel C'est super ! Existe-t-il un moyen de mettre en évidence uniquement le nom du fichier (pas le chemin complet) et le numéro de ligne ? Peut-être un gris un peu plus clair ?

Cela pourrait : https://github.com/JuliaLang/julia/issues/36026#issuecomment-634481656 . Mais c'est un peu bizarre pour moi puisque le nom du fichier fait partie du chemin, alors pourquoi utilise-t-il une couleur différente ? Habituellement, je clique simplement sur le chemin et VSCode l'ouvrira pour moi, peu importe le nom du fichier.

J'ai abandonné l'utilisation de Crayon.jl, maintenant que je n'utilise plus de couleurs complexes. Aide également au temps de chargement du package. J'ai trouvé un moyen d'améliorer la visibilité du nom de fichier et du numéro de ligne sans que cela devienne visuellement écrasant en soulignant en gris foncé. Cela semble également raisonnable, car nous sommes habitués aux chemins / liens soulignés. Le blanc ou autre surlignage y était trop fort, le gras trop faible.

De plus, je suis passé aux couleurs claires comme premières couleurs dans le cycleur, ce que j'aurais dû faire en premier lieu, mais elles se ressemblent dans mon thème, donc je ne l'ai jamais remarqué. Cela devrait être mieux pour les thèmes où le bleu foncé est à peine visible (c'est la faute du thème cependant).

J'ai enregistré ce style en tant que version 0.2 dans ClearStacktrace.jl afin que nous puissions l'essayer un peu plus.

Deux exemples :

C'est vraiment du beau travail.
Vous avez les noms de paramètres plus clairs et les types plus sombres. Est-ce que cela s'est avéré mieux / mieux lu de cette façon qu'avec les types plus clairs et les noms plus sombres ?

Oui, comme les types sont généralement beaucoup plus longs, cela n'aide pas beaucoup de les rendre plus légers.

Pensées aléatoires :

• peut-être des règles horizontales entre des groupes d'entrées de trace de pile dans le même module ? peut-être trop occupé à chercher
• peut également être bon en haut de la trace de la pile, pour le séparer clairement du message d'erreur

Tout cela est tellement mieux que ce que nous avons maintenant...

J'ai abandonné l'utilisation de Crayon.jl, maintenant que je n'utilise plus de couleurs complexes. Aide également au temps de chargement du package.

Cela a-t-il causé un temps de chargement important ? Il se charge assez rapidement tout seul pour moi

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

Cette version est géniale, mettons cela dans Base.

D'accord : faisons juste cette dernière version.

Merci d'avoir fait tout le travail ici, @jkrumbiegel . Super d'avoir une version que nous pouvons essayer...

Et fork : Je suppose que je pense que c'est un peu inquiétant que rand(5) .* rand(7) plus l'erreur occupe 35 lignes ? J'ai donc créé https://github.com/mcabbott/ClearStacktrace.jl/tree/milder pour essayer. (Plus les problèmes de couleur, etc. discutés ci-dessus.) C'est presque https://github.com/JuliaLang/julia/issues/36026#issuecomment -635294818 avec plus de couleurs.

Notez que dans les cadres d'impression de trace de pile actuels 8-11 dans cet exemple ne sont pas montrés (ils font partie du REPL et seraient dans chaque trace de pile REPL).

En effet, cela s'est amélioré, ce qui est formidable. Mais cela passe toujours de 8 lignes (pour la trace de pile seule) à 20 (ClearStacktrace 0.2). Il y a un petit compromis entre la beauté et le fait de ne pas perdre sa place.

Les chemins sont également imprimés de manière beaucoup plus compacte dans Base, ./broadcast.jl:495 au lieu de //Applications/Julia-1.5.app/Contents/Resources/julia/bin/../share/julia/base/broadcast.jl:495 , cela réduirait également le besoin de lignes vides.

Les chemins de base sont volontairement étendus pour les rendre cliquables. Vous pouvez le désactiver dans ClearStacktrace. Je pourrais aussi rendre les nouvelles lignes facultatives pour les personnes qui ne les aiment pas. Peut-être juste une variable d'environnement.

Et je suppose que j'ai dû manquer de copier la partie de la fonction qui coupe les deux dernières images qui ne changent jamais

J'ai abandonné l'utilisation de Crayon.jl, maintenant que je n'utilise plus de couleurs complexes. Aide également au temps de chargement du package. J'ai trouvé un moyen d'améliorer la visibilité du nom de fichier et du numéro de ligne sans que cela devienne visuellement écrasant en soulignant en gris foncé. Cela semble également raisonnable, car nous sommes habitués aux chemins / liens soulignés. Le blanc ou autre surlignage y était trop fort, le gras trop faible.

De plus, je suis passé aux couleurs claires comme premières couleurs dans le cycleur, ce que j'aurais dû faire en premier lieu, mais elles se ressemblent dans mon thème, donc je ne l'ai jamais remarqué. Cela devrait être mieux pour les thèmes où le bleu foncé est à peine visible (c'est la faute du thème cependant).

J'ai enregistré ce style en tant que version 0.2 dans ClearStacktrace.jl afin que nous puissions l'essayer un peu plus.

Deux exemples :

Curieux de savoir pourquoi il y a un / supplémentaire dans //Applications/Julia-1.4.app/ ?

Probablement un bug de la division et de la reprise du chemin

J'ai abandonné l'utilisation de Crayon.jl, maintenant que je n'utilise plus de couleurs complexes. Aide également au temps de chargement du package.

Cela a-t-il causé un temps de chargement important ? Il se charge assez rapidement tout seul pour moi

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

  0.014410 seconds (22.60 k allocations: 2.274 MiB)

Non, je l'ai principalement supprimé car je ne l'aurais pas dans la base :) Le temps de chargement n'était qu'une supposition

Je suppose qu'il pourrait y avoir trop de lignes vides si nous avons beaucoup d'images de stacktrace comme indiqué dans https://github.com/JuliaLang/julia/issues/36026#issuecomment -636912686 ?

Pas pour faire dérailler la discussion (la dernière version est géniale et une grosse amélioration) mais au sujet du trop grand nombre de nouvelles lignes, le problème est que lorsque l'on travaille au terminal il me semble beaucoup mieux d'imprimer le stacktrace "inversé" (comme J'ai initialement proposé dans https://github.com/JuliaLang/julia/pull/18228) comme:

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

L'information la plus importante est le message d'erreur lui-même et les cadres vers le haut de la pile (plus proche de l'erreur) et l'impression dans cet ordre qui sera toujours visible sans défilement. À l'heure actuelle, je dois souvent faire défiler vers le haut pour voir même le message d'erreur et pas seulement la queue d'un stacktrace.

Cependant, lors de la lecture d'un stacktrace sur un site Web qui a été copié-collé depuis le terminal, vous voulez l'ordre inverse car vous faites défiler de haut en bas plutôt que de bas en haut comme vous le faites dans un terminal ... Un peu difficile à obtenir un bonne conception pour ces deux cas.

Cependant, lors de la lecture d'un stacktrace sur un site Web qui a été copié-collé depuis le terminal, vous voulez l'ordre inverse car vous faites défiler de haut en bas plutôt que de bas en haut comme vous le faites dans un terminal ... Un peu difficile à obtenir un bonne conception pour ces deux cas.

J'avais en fait du code dans ClearStacktrace.jl pendant un moment qui m'a permis de réimprimer le dernier stacktrace. J'avais imaginé cela pour couper les types super longs à un maximum de caractères et pouvoir réimprimer en entier si toute l'information était nécessaire. Mais votre cas d'utilisation serait également intéressant. Je peux imaginer un reprint(inverted = true) ou même un reprint(html = true) où il imprimerait une version html qui conserverait la coloration pour la coller dans un site Web.

De plus, je suis d'accord que compte tenu du sens de défilement, il pourrait être judicieux d'inverser le tout par défaut.

ipython imprime les images dans l'ordre inverse, et malgré le fait de ne pas avoir à faire défiler, j'ai toujours trouvé cela inexplicablement déroutant. Peut-être est-ce simplement dû à mon expérience antérieure avec gdb et d'autres systèmes où le cadre le plus interne est en haut, ou peut-être que d'autres personnes ressentent cela aussi?

En parlant de gdb, ils ont une solution raisonnable aux très longues traces avec leur pager : "appuyez sur entrée pour plus d'images".

Au fait, j'aime la dernière conception visuelle sur https://github.com/JuliaLang/julia/issues/36026#issuecomment -636912686 et je serais extrêmement heureux si nous fusionnions cela. La modification de l'ordre des cadres ou l'ajout de fonctionnalités interactives semblent être des problèmes distincts.

En ce qui concerne les noms de fichiers, j'espère que nous pourrons éventuellement utiliser des séquences OSC d'hyperliens de terminal ( oui, les hyperliens dans les terminaux sont assez largement pris en charge ! ) et que l'éditeur de l'utilisateur pourra les récupérer.

En parlant de trouver le "cadre le plus interne", j'utilise suffisamment de langages au cours de mon travail pour que je ne me souvienne jamais si je devrais regarder en haut ou en bas d'un stacktrace pour mon code dans un langage particulier. Je finis donc par parcourir le nom du fichier jusqu'à ce que j'en voie un que je reconnais. Le soulignement montré ici aiderait, il s'agit donc d'une nette amélioration. Mais je me demande toujours s'il y a un bon moyen d'appeler si je devrais regarder en haut ou en bas. En principe, imprimer YOUR CODE HERE à une extrémité et OTHER CODE HERE à l'autre m'aiderait, mais cela ne semble pas très élégant.

J'ai fait un PR à Base ici https://github.com/JuliaLang/julia/pull/36134
Cela fonctionne pour autant que je sache, mais j'aurai besoin d'aide pour le préparer à la fusion

Existe-t-il un moyen d'omettre les paramètres de type ? Le problème que nous voyons souvent est que la quantité de paramètres de type dans DiffEq, ForwardDiff, etc. peut rendre les choses... intimidantes. Si par défaut, il dit simplement Dual , sauf dans le cas où il y a une répartition vers d'autres méthodes en raison des paramètres de type, alors je pense que vous réduisez 90% du bruit dans la plupart des traces de pile que j'ai lues (et dans dans les autres cas, la suggestion de @timholy est vraiment ce qui est nécessaire, car il s'agit généralement de créer des types ou de faire correspondre des paramètres de type)

S'ils correspondent à un alias de type existant, ils disparaîtront automatiquement maintenant (#36107). Sinon, ils indiquent d'éventuels goulots d'étranglement des performances de compilation.

C'est fait maintenant.

Pour certaines personnes, mais la plupart des gens deviennent confus quand il imprime un type qui prendrait 3 pages de papier imprimé, donc cela devrait probablement être quelque chose qui est opt-in. Je vais ouvrir un autre sujet pour en discuter.

Suite sur https://github.com/JuliaLang/julia/issues/36517