Julia: Что нужно для включения ClearStacktrace.jl в базу?

Было бы здорово иметь это. Или, по крайней мере, может быть урезанная версия, которая улучшает печать трассировок стека по умолчанию в Base.

Я полностью за. Главное, чего я не понимаю, - это цвета подписей. Они кажутся ... случайными? Я предполагаю, что разные цвета нужны, чтобы было легче выделять разные элементы, но это немного странно. Как насчет цвета == глубины вложенности? Я думаю, что основная странность, например, в Tuple{Symbol,Symbol} где два Symbol s имеют разные цвета.

Я бы очень хотел увидеть еще кое-что:

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

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

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

но с тех пор

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

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

кажется, что мы должны иметь возможность распечатать запись 2 как что-то вроде

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

Небольшой замечание, но для меня это в настоящее время, возможно, слишком много цветного «салата». Счетчик фреймов стека - синий, все разные цвета в подписи и т. Д. Для базовых цветов до сих пор мы использовали только 16 системных цветов (8 + 8 ярких), что немного усложняет причудливую окраску.

В целом хорошие предложения. Может быть, пара прокомментирует, почему я до сих пор выбрал цвет:

Цифры синие, потому что они важны, поэтому не должны быть выделены серым цветом, но когда они становятся белыми, мне показалось, что они борются за внимание с помощью имен функций.

Модули используют основные цвета в цикле, я думаю, это очень полезно, потому что позволяет быстро отфильтровать трассировку для соответствующих модулей. Это то, что очень связано с текущим форматом трассировки стека. Идея в том, что людей нужно заставлять читать как можно меньше, чтобы найти то, что они ищут. (До сих пор я в основном занимался исследованиями движения глаз и внимания в своей академической жизни, поэтому эти аспекты важны для меня;))

Цвета подписей очень спорны. Те, что на скриншоте выше, были выбраны так, чтобы они лишь немного отличались от темно-серого. В то же время я хотел, чтобы разные семантические компоненты были различимы. Вот почему все типы и параметры типа (фигурные скобки и запятые) вызывают переключение цвета. Есть три цвета, что означает, что не будет двух соседей с одинаковым цветом. Я обнаружил, что довольно сложно различить отдельные слова в огромных подписях, если все они просто белые. Немного разные оттенки очень помогают, но также делают визуально более шумным.

Поскольку в наборе из 16 цветов нет цветов, которые лишь незначительно отличаются от темно-серого, вероятно, это не то, что можно включить в Base. В недавнем обновлении я заменил цвета тремя слегка разными оттенками серого из набора ANSI, но даже это, я думаю, не везде будет поддерживаться.

Кроме того, цвет рамки стека и цвета модуля, а также темно-серый и белый - все системные цвета. Это просто моя конкретная тема VSCode, которая отображает их так, как вы видите здесь.

Было бы здорово иметь это.

При сканировании типов аргументов часто довольно сложно понять, где заканчивается один и начинается следующий. Здесь может быть очень полезно раскрасить верхний уровень по-другому и, возможно, даже пронумеровать аргументы:

 [3] (_1 :: DataFrames.var "# fun ## 309 #" { ... светлее ... }, _2 :: NamedTuple { ... светлее ... }, _3 :: Int64})

Мы должны иметь возможность отображать имена аргументов, как при печати methods(f) .

Как это? Я заменил цвета подписи на темно-серый, но :: белый, поэтому он заметен там, где начинаются типы аргументов. особенно полезно с типовым монстром на позиции 11

Мне это нравится. Будет еще лучше с именами аргументов.

Жаль, что порядок «функция - модуль - аргументы» так хорошо работает для макета, но не имеет смысла семантически. Но у меня нет решения; очевидно, что лучше, чтобы функция была на первом месте. Может быть, модуль мог бы перейти на следующую строку перед местоположением файла? В конце концов, это часть локации. Тогда, может быть, и заголовок нам не понадобится.

Я думаю, мы могли бы также поместить числа в обычный текст, а имена функций - жирным и / или белым шрифтом.

Может ли имя файла в конце пути кода (и, возможно, номер строки) получить свой собственный более светлый цвет?

Может быть, модуль мог бы перейти на следующую строку перед местоположением файла? В конце концов, это часть локации. Тогда, может быть, и заголовок нам не понадобится.

Я попробую пару вещей с этими предложениями.

Может ли имя файла в конце пути кода (и, возможно, номер строки) получить свой собственный более светлый цвет?

Технически, конечно;) Это всегда компромисс между лучшей видимостью и привлекающим внимание шумом.

Почему бы не написать сначала модули, поскольку они являются частью полного имени функции? Возможно, с помощью цвета может быть достаточно просто написать Core.eval т. Д., Или они все еще могут быть выровнены как столбцы. (Или, возможно, вы пробовали это, и это выглядело ужасно.)

Действительно сумасшедшая мысль: если печать типов аргументов займет более одной строки, распечатайте подпись в свернутом виде, а затем используйте REPL.TerminalMenus чтобы позволить зрителям расширить ее. Что-то вроде:

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

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

По теме: # 35915 (который я планирую использовать для создания меню в виде свернутого дерева, https://github.com/JuliaCollections/FoldingTrees.jl).

Как это выглядит, если кодовый путь переставлен в следующем порядке: LineNumber Filename Path
Тогда у ваших глаз будет стабильное место для поиска номера строки и имени файла без необходимости в дополнительном цвете (я, кажется, всегда ищу имя файла и номер строки, скрытые в деталях, вы можете сказать?)
А для интерактивной работы REPL мне нравится сложенная идея выше :)

Почему бы не написать сначала модули, поскольку они являются частью полного имени функции

Да, мне нравится эта идея, я думаю, что начал без цвета, и это не сработало так хорошо, но в таком виде это на самом деле вполне читаемо. Далее я попробую без столбцов, хотя столбцы всегда хороши, потому что они направляют ваш взгляд.

Не уверен в этом; имя функции - гораздо более важная информация, чем модуль. По крайней мере, для меня самая важная информация - это имя функции, имя файла и номер строки. Также для скриптов в левом столбце будет много Main или пусто, что не идеально для этого варианта использования.

Я думаю, что когда я читаю трассировки стека, я в основном ищу последний вызов в моем коде, прежде чем он перейдет к базовому / пакетному коду, поскольку обычно ошибка находится в моем коде. Так что в этом случае модуль очень важен, а вызов функции - это не то, что я сканирую в первую очередь.

Как насчет этого:

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

Имена модулей по-прежнему будут совпадать, чтобы их было легко сканировать.

На самом деле я только что пробовал что-то близкое к этому. На этот раз я раскрасил сами имена функций, так что они по-прежнему наиболее заметны, но несут информацию о модулях своим цветом. Таким образом, все еще существует очевидная группировка, но с меньшим вниманием ко всем именам модулей.

В первый раз я увидел, что, наверное, сойду с ума, пытаясь понять, что означают цвета: радость: Если будут цвета для каждого модуля, кажется, лучше просто применить цвет к имени модуля.

Мне нравятся названия модулей, они немного теряются на последней картинке.

Если они внизу, возможно, их объединение в один яркий цвет? (И проясните, где вы пересекаете границу модуля.) И, возможно, если имя модуля появляется в пути, его можно было бы просто выделить там вместо этого - это также сдвинуло бы красочное имя с левого края, где находятся функции.

Для некоторого вдохновения я публикую несколько изображений с момента последней настройки форматирования stacktrace.

Часто интересует не столько конкретный пакет, сколько характер кода: это ядро ​​julia, библиотека, которую я использую, библиотека, которую я разрабатываю, или сценарий? У нас может быть четыре цвета: core / base / dev / stdlib, пакеты, текущие пакеты ]dev ed и все остальное (включая script / REPL). Некоторые из этих различий довольно произвольны, а классификация немного хрупка, но раскрашивание основанного на этом метода позволило бы (по крайней мере, для меня) максимизировать информацию без отображения лишнего текста и сохранения небольшого, легко запоминающегося набора цветов.

Для меня цвета больше связаны с изменениями границ, когда код одного модуля начинается, а другой заканчивается. Вот почему я бы, наверное, не стал придавать им внутреннее значение. С другой стороны, это может сбивать с толку.

Я попытался упростить больше и снова удалил столбцы, потому что без столбца модуля они больше не так полезны. Затем сначала я раскрасил модули только по номеру строки, но это все равно оставило имя файла не очень видимым, что, по мнению многих комментариев, важно. Так что я тоже покрасил это в цвет модуля. Само имя модуля не окрашено, потому что оно слишком близко к имени функции и слишком шумно.

Вот версия с раскрашенными номерами и именами файлов:

здесь без имен файлов окрашены

Вы также можете попробовать раскрасить полный путь к файлу?

Некоторые идеи...
Имя файла и номер строки в одинаковом месте с двойными пробелами, чтобы выделить их.
Цвет уровня стека и цвет модуля соответствуют друг другу, чтобы визуально соединить связанные линии.
Имя файла, номер строки и путь имеют немного другой оттенок, чем типы параметров, чтобы их можно было различать без беспорядка.

[Цвета в этом примере произвольные, больше нужно думать о том, как соотносятся их позиции.
Отсутствующие уровни стека в примере и сокращенный список типов параметров в последнем элементе вызваны тем, что я набрал пример вручную.]

Код, использованный для создания приведенного выше примера на случай, если кто-то захочет поиграть с ним:

function main()

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

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

Проблема в том, что при этом ссылки в Atom / VSCode и т. Д. Не становятся доступными для кликов. Это то, что я использую очень часто и считаю, что и другие тоже. Фактически, я даже явно расширяю базовые пути, чтобы сделать их интерактивными. Это, конечно, печатает больше. Но я думаю, это увеличивает полезность. Я знаю, что есть способ перейти к стеку записей трассировки по номеру в REPL с помощью некоторого ярлыка, но, на мой взгляд, это гораздо менее интуитивно понятно, чем просто щелкнуть ссылку.

Возможно, имеет смысл воспользоваться возможностью унифицировать способ печати информации о строке с системой регистрации, например:

Также обратите внимание, что система ведения журналов сжимает домашний адрес

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

Я думаю, что в этом предложении есть две основные идеи:

• Поместите информацию о строке на отдельной строке от подписи (и, возможно, выделите ее некоторым цветом, чтобы ее было легче найти).
• Покажи модуль.

Итак, вот немного более консервативная попытка с обеими идеями:

Версия с добавленными именами переменных и цветом только имен модулей (но в остальном соответствует тому, как @info печатает пути):

У этого нет очень длинных сигнатур типов, но, возможно, наличие таких имен переменных (если это возможно?) Упростит определение внешнего типа каждого аргумента.

Если доступно три уровня нейтральности (например, жирный / нормальный / серый), то печать пути к файлу более легкая, чем кажется (IMO), как хороший способ остановить совместную работу. (Это также то, что делает @info .)

 позволять
 printstyled ("\ njulia>", цвет =: зеленый)
 println ("е ()")
 printstyled ("" "ОШИБКА: DimensionMismatch (" A имеет размеры (1,2), но B имеет размеры (3,4) ")" "", color =: light_red)
 println ("\ nStacktrace:")
 for (idx, err) в перечислении (ошибки)
 mc = idx <= 3? : blue: (idx> = 7?: blue:: yellow) # Цвет модуля
 printstyled ("[$ (err [1])]", color =: normal, bold = true) # errorno
 printstyled (err [2], color =: normal, bold = true) # функция
 printstyled ("(", color =: normal) # типы параметров
 for (i, t) in enumerate (err [3])
 i! = 1 && printstyled (",", color =: normal)
 printstyled (rand ('a': 'z') ^ 2, цвет =: светлый_черный)
 printstyled ("::", цвет =: нормальный)
 printstyled ("$ t", цвет =: нормальный)
 конец
 printstyled (")", цвет =: нормальный)
 println ()
 printstyled ("@", color =: light_black)
 printstyled (err [6], color = mc) # модуль
 printstyled ("$ (err [7]) / $ (err [5]): $ (err [4])», color =: light_black) # путь
 println ()
 конец
 конец

Я думаю, что в этом предложении есть две основные идеи:

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

* Show the module.

Итак, вот немного более консервативная попытка с обеими идеями:

Мне это нравится. Я думаю, что термин «убей своих любимых», и моя дорогая может быть цветом. Но я понимаю, как что-то более мягкое может лучше подходить для чего-то столь простого. Я немного изменил его, так что имя модуля и имя функции совпадают, что создает почти столбчатую вертикальную контрастную линию. Это должно помочь найти нужную информацию. Хотя я все еще думаю, что не стал бы выделять шрифты белым, потому что они получаются очень беспорядочными. Если бы у нас были имена переменных, может быть, хорошо бы смотрелись белые.

Мне это нравится. Я думаю, что термин «убей своих любимых», и моя дорогая может быть цветом.

Просто чтобы вы знали, что я знаю вашу ситуацию, https://github.com/JuliaLang/julia/pull/18228. Это очень интересная тема для велосипедистов, и у каждого есть ведро с краской, хех. Как видите, этот PR тоже начинался довольно амбициозно, но постепенно становился все более и более консервативным, хех.

Для меня последнее предложение определенно является улучшением статус-кво. Я думаю о двух вещах:

• Если возможно, было бы неплохо иметь какой-то «крючок» для ваших глаз для информации о строке, потому что она имеет тенденцию сливаться с подписью, когда подпись длинная.
• Вероятно, нам следует выровнять номера стековых фреймов, когда их больше 10:
  [ 8] [ 9] [10] [11]
  и т.д. Это заставит @ также выстроиться в линию.

Мне это нравится, я думаю, мы к чему-то идем. Разумный подход к цветам - это всегда хорошо, так как это дает меньшую площадь поверхности для навешивания велосипедов, а также снижает риск того, что цвет будет нечитаемым на чьем-либо терминале.

Разбивка - это хорошо, но, к сожалению, синтаксис f (...) явно запрещен, поэтому я думаю, что нам нужно либо удалить пробел, либо убрать скобки.

Самый последний образец в целом выглядит неплохо, но я поддерживаю идею:

Если возможно, было бы неплохо иметь какой-то «крючок» для ваших глаз для информации о строке, потому что она имеет тенденцию сливаться с подписью, когда подпись длинная.

И я надеюсь, что крючок другого цвета или (желательно) яркости.

Возможно, вы могли бы сделать цикл цветов для модулей, но применить его только к [] по обе стороны от номера уровня стека, поэтому, если вы не можете видеть цвета по какой-то причине, теряется немногое.

Возможно, вы могли бы сделать цикл цветов для модулей, но применить его только к []

Трудно даже правильно увидеть цвет, если это только скобки и они находятся в контрастной области, поэтому я не думаю, что это работает слишком хорошо ...

синтаксис f (...) явно запрещен

Думаю, он хорошо работает даже без пространства из-за разницы в контрасте.

Если есть возможность, было бы неплохо иметь какой-нибудь «крючок» для глаз для строчной информации.

Я согласен, я думаю, что неплохо было бы оставить номера строк серыми, но жирным, что делает их немного заметными, если вы их ищете, но следующий шаг, чтобы сделать их белыми, на мой взгляд, слишком шумный.

Вероятно, нам следует выровнять номера стековых фреймов

Я пробовал с пробелами внутри скобок, как в вашем примере, но обнаружил, что это выглядит немного странно, поэтому теперь я просто выравниваю числа в скобках. Я думаю, это работает очень хорошо.

Вот последняя версия со всеми этими идеями:

И в качестве бонуса вот как это может выглядеть с (случайными) именами переменных. Опять же, я просто использую полужирный серый цвет, потому что все эти имена переменных не должны отвлекать ваше внимание, но должны быть немного различимы, если вы их ищете.

Мне тоже нравится, к чему все идет. Я просто хочу проголосовать за какое-то выделение имени модуля. На самом деле мне очень нравится стиль, в котором один и тот же модуль окрашен одинаково, и он циклически меняет цвета (здесь возникает проблема с цветом графика, если вы считаете, что две линии трассировки стека смежны как граница графа между их модулями). Однако, к сожалению, довольно неочевидно, что означает этот цвет. Может быть, раскрасить все имена модулей в один цвет?

Мне этот расклад кажется хорошим.

Я все еще думаю, что наличие путей, более четко отличных от сигнатур, помогло бы разбить вещи - 3 уровня важности, имя / подпись / путь. Макросы журнала @info и т. Д. Выводят их светлее, чем другие строки.

Было бы очень хорошо иметь имена переменных. Возможно, проголосовали бы за то, чтобы они были менее значимыми, чем информация для подписи?

Выравнивание названий модулей слева действительно помогает их сканировать, хотя мне грустно видеть, что цвета исчезают.

Кажется, мои глаза знают, где найти что-нибудь на этом :)
Будет ли пустая строка между модулями использовать слишком много вертикального пространства?

Раскрашивание строк двумя разными цветами, чтобы альтернативные строки имели один и тот же цвет - как это часто делается в таблицах, может улучшить читаемость.

Цветной цикл @ рядом с именем модуля вместо самого имени модуля выделяется (потому что @ - довольно большой символ), не слишком конкурируя с выделенным именем функции.

Мне часто нужны имена параметров, поскольку они помогают найти правильный тип параметра без необходимости их пересчитывать.

Может ли путь (и, возможно, имя модуля рядом с ним) иметь другую яркость, чем типы? Может просто совпадение названий параметров? (Или все вместе при слабом освещении, если вы сделаете предложение Макэбботта сделать имена более тусклыми, чем типы)

Вы можете явно отразить то, что используется при ведении журнала, хотя в идеале с разными цветами:

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

Изменить: теперь с одной длинной строкой, которая переносится, и изображением:

Вы можете явно отразить то, что использует ведение журнала

Что мне не очень нравится в этом, так это то, что разрывы строк, которые есть только из-за определенной ширины REPL, плохо переносятся, если вы измените размер окна / REPL (если вы хотите освободить место для более длинных строк, например ) или скопируйте / вставьте текст в окна разной ширины

Да, я бы не предлагал явно разрывать линии, чтобы маркеры были непрерывными. На самом деле, это может быть хорошо, если строки будут перерезаны и, следовательно, будут выглядеть иначе. В основном это мысль о том, как связать цвет с именем функции и как сделать его, возможно, менее навязчивым, если он является частью границы, а не выглядит как самый важный заголовок.

Я должен сказать, что мне понравился цвет, но я понимаю, что я предпочитаю быть с ним консервативным.

Однако я хочу поддержать что-то вроде

Часто интересует не столько конкретный пакет, сколько характер кода: это ядро ​​julia, библиотека, которую я использую, библиотека, которую я разрабатываю, или сценарий? У нас может быть четыре цвета: core / base / dev / stdlib, пакеты, текущие пакеты ]dev ed и все остальное (включая script / REPL). [...]

Поскольку я не взламываю базы и редко использую пакеты (как это делают большинство людей, я полагаю), 90% ошибок нужно исправить в моем скрипте, 9% в пакете и 1% в базе. Если я допустил ошибку при вызове функции, мне не нужно здесь точно знать, что именно в базе возникла ошибка, так как я все равно не собираюсь ее исправлять, мне нужно исправить свой код.

Так что я был бы признателен за визуальный помощник, чтобы увидеть, где я оставляю свой код (и, возможно, также, где я оставляю код пакета, переходя в базу), потому что в большинстве случаев все, что после этого, я могу спокойно игнорировать. Если не через цвет, может быть, с -------------------------------------------- или что-то в этом роде? Их должно быть только 2-3.

Если модули окрашиваются в цвет, возможно, следует исключить Base / Core и не задавать цвет.

На самом деле мне очень нравится стиль, в котором один и тот же модуль окрашен одинаково и циклически меняет цвета.

Меня это тоже устраивает. Если мы собираемся использовать много цветов, я думаю, что их следует использовать для этого. Это также помогает определить границы между кодом пользователя и кода пакета, не занимая слишком много места по вертикали.

Если модули окрашиваются в цвет, возможно, следует исключить Base / Core и не задавать цвет.

Да, Base и Core всегда могут быть темно-серыми или что-то в этом роде, оставляя больше цветов для всех остальных :)

Если это перестает идеально работать с 16 цветами, то было бы неплохо сделать их хешем имен модулей, чтобы вы запомнили некоторые из них.

Или есть только два цвета, один для Base / Core и один для внешних модулей?

Я думаю, что не должно быть большой проблемы с циклическим переключением цветов, потому что моя текущая версия имеет 6 вариантов без оттенков серого:

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

Думаю, есть и светлые варианты, но в моей цветовой схеме в VSCode (Material) они установлены так же, как и более темные братья и сестры, поэтому я предполагаю, что это может произойти в некоторых схемах. Но насколько вероятно, что трассировка стека проходит через более чем 6 различных небазовых или нестандартных библиотечных модулей? Конечно пакеты используют код из разных модулей, но в одном конкретном пакете не должно быть так много. По крайней мере, это не должно вызывать больших проблем при расшифровке трассировки стека, даже если есть коллизии цветов.

тогда было бы неплохо сделать их хешем имен модулей, чтобы вы запомнили некоторые из них

Это действительно здорово.

Приятно видеть людей, работающих над этим.
Мне было бы интересно посмотреть, как выглядит правильное выравнивание имен функций:

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

против

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

Возможно, глазу будет легче уловить, где начинаются аргументы функции, и предложить помощь в синтаксическом анализе цепочки вызовов функций, не тратя много места. Его по-прежнему нужно поддерживать цветами, иначе информация о местах и ​​аргументы заглушили бы все.

тогда было бы неплохо сделать их хешем имен модулей, чтобы вы запомнили некоторые из них

Это действительно здорово.

О, привет, тёмно-бирюзовый, мой старый друг ...

тогда было бы неплохо сделать их хешем имен модулей, чтобы вы запомнили некоторые из них

Раньше у меня emacs делал именно это для псевдонимов IRC. Это не сработало так хорошо, потому что некоторым из моих друзей был назначен один и тот же цвет, и это сбивало с толку больше, чем что-либо еще, поэтому я закончил жестко кодировать цвета для своих друзей. Я бы не рекомендовал идти по этому пути, как бы круто это ни казалось. Сокращенный набор цветов для каждого типа кода (например, Julia, пакет, созданный пакет, пользователь) кажется более полезным.

Я выбрал цветовую схему редактора, которая делает это, и она умеренно полезна - все переменные, которые в противном случае могли бы быть синими, имеют разные оттенки зеленого и синего, с разными строками, ключевыми словами и т. Д. Возможно, идеальным было бы что-то подобное в широких классах, подобных тем, которые вы предлагаете (например, стандартная библиотека в красно-фиолетовом цвете, загруженная в зелено-синем, разработанная в оранжево-желтом, базовая в сером). Или, может быть, это слишком много работы!

еще одна итерация: я попытался добавить туда имена переменных, хотя мне все это кажется супер хакерским, поскольку я не очень хорошо знаком со всеми внутренними функциями. Я перекрасил модули, потому что в целом это вызвало положительный отклик, хотя спорный вопрос о том, как следует назначать цвета. Но с цветами я чувствую, что модуль одной записи немного конфликтует с именем функции следующей. Поэтому я ввел разрывы строк. Делает, конечно, дольше, но мне нравится дополнительная передышка и ясность

Мне нравится ваш последний образец, он очень четкий и читаемый :)

Ниже приведен всего лишь эксперимент, в котором цвет модуля применяется к символу «@» вместо имени модуля, чтобы уменьшить конфликт, который вы упомянули с именем функции, и попробовать выделить типы, чтобы можно было легче различать путь, не вводя пробел. линий.

@jkrumbiegel Это красиво. Мне это нужно в моей жизни.

Мне нравится этот мягкий блюз

@jkrumbiegel Отлично, я не уверен, что нужен символ @, без него он мог бы выглядеть чище. Если вы хотите объяснить, что это за информация, вы можете просто написать ее, как предложил Джефф:
in MakieLayout at ~/.julia/packages/MakieLayout/COfBu/src/lineaxis.jl:372

@jkrumbiegel Отлично выглядит! Есть ли способ выделить только имя файла (а не полный путь) и номер строки? Возможно, чуть более яркий серый?

Прекрасный! Мне на самом деле очень нравятся разрывы строк - они действительно помогают визуально, и наши трассировки стека, как правило, настолько длинные, что мне все равно приходится прокручивать, я бы предпочел, чтобы они были четкими, чем немного уменьшили прокрутку.

Выделенные :: великолепны. Если бы мне пришлось построить кривую, показывающую информационное содержание каждого символа списка параметров в зависимости от положения символа, :: точно отметит локальные максимумы этой кривой. Я знаю, что нужно смотреть слева от них для названия и справа для наиболее важной части типа, после этого информационное содержание только падает.

Я не согласен с этим комментарием: выделение должно подчеркивать важные вещи, чтобы глаз знал, что читать, а :: определенно не является важной вещью, которую я должен читать. В его нынешнем виде белый цвет гораздо более заметен, чем насыщенный темно-синий. Различение параметров было бы более ясным, если бы имена аргументов были выделены белым цветом (возможно, за исключением случаев, когда именованный аргумент отсутствует, и в этом случае :: может быть белым для разделения аргументов). То же самое и с номером строки, я бы предпочел выделить имя файла, а не номер строки.

Цветные имена пакетов могут затмить самое важное, имя функции, но выделение их жирным шрифтом и переносом строк действительно ограничивает этот риск, молодец!

Я много думал о :: перед тем, как сделать их белыми. Конечно, имена аргументов и типы являются фактической информацией, поэтому вы можете подумать, что они должны быть выделены. Но при их выделении у меня сильное впечатление, что они привлекают ваше внимание. Но не обязательно читать каждое имя и тип. Вы должны просто найти те, которые вам нужны, в конкретной функции. Как я вижу этапы чтения трассировки стека:

1. Получите общий обзор
2. Какая функция в каком модуле ошибалась?
3. Какие еще функции вызывали эту функцию из каких других модулей?
4. Есть ли критическая граница между моим собственным кодом и базовым или другим кодом пакета? Где это находится?
5. Какая функция находится на этой границе?
6. Какие типы / аргументы использовались? Где заканчивается один аргумент и начинается следующий? Это особенно сложно сейчас с длинными параметрическими типами.
7. Это объясняет ошибку?
8. Если это не помогло, пройдите все тонкой расческой.

Таким образом, информация о типе / аргументе, на мой взгляд, используется только после ориентации и понимания общей структуры. Одна вещь, которую следует понимать в отношении выделения, заключается в том, что оно не обязательно облегчает поиск вещей, только если блики относительно редки. Поэтому я думаю, что :: highlight не мешает и не привлекает ваше внимание, пока вы не начнете искать информацию о переменных / типах. И на этом этапе это дает вашим глазам зацепки, на которые можно прыгать, ни больше, ни меньше. Я считаю это весьма эффективным.

Кстати, не у каждого аргумента есть имя, поэтому выделение имен переменных не всегда даст вам хорошее разделение. Я думаю: :: всегда есть.

Кажется, это хороший список, моя основная жалоба - это пункт 6, поиск пробелов в длинных сигнатурах. Печать :: super-bright действительно помогает, хотя, согласен, это немного странно. Печать имен аргументов (или, возможно, некоторого заполнителя _1 если его нет) немного поможет. Возможно, вам очень поможет обычная печать внешнего типа, а затем все его аргументы серым цветом?

Сколько уровней подсветки реально доступно? :white не будет выделяться на светлом фоне, на самом деле я думаю, что мы можем ограничиться обычным, жирным шрифтом и :light_black (плюс цвета). Сейчас имя функции и путь выделены жирным шрифтом. В @error т. Д. Путь - light_black, что кажется отличным.

Мне нравится использование цвета для выделения модулей. В некоторых из приведенных выше примеров он затмевает другой текст, но верно ли это для простых цветов? В нескольких разных темах "Module" здесь относительно приглушен (и ::Array, ::Adjoint, ::Int довольно явно подпись верхнего уровня):

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

еще одна итерация: я попытался добавить туда имена переменных, хотя мне все это кажется супер хакерским, поскольку я не очень хорошо знаком со всеми внутренними функциями. Я перекрасил модули, потому что в целом это вызвало положительный отклик, хотя спорный вопрос о том, как следует назначать цвета. Но с цветами я чувствую, что модуль одной записи немного конфликтует с именем функции следующей. Поэтому я ввел разрывы строк. Делает, конечно, дольше, но мне нравится дополнительная передышка и ясность

Возможно, это немного не по теме, но, раз уж у нас есть это, можем ли мы получить более красивую show для вывода methods и methodswith ? Это тоже боль.

Также цвет модулей мог быть тусклым, например, не совсем желтым, а серо-желтым. Или мы можем настроить эти цвета, например, startup.jl ?

@jkrumbiegel Отлично выглядит! Есть ли способ выделить только имя файла (а не полный путь) и номер строки? Возможно, чуть более яркий серый?

Это могло быть: https://github.com/JuliaLang/julia/issues/36026#issuecomment -634481656. Но для меня это немного странно, так как имя файла является частью пути, так почему он использует другой цвет? Обычно я просто щелкаю путь, и VSCode открывает его для меня, поэтому не имеет значения, какое имя имеет файл.

Я отказался от использования Crayon.jl, теперь, когда я больше не использую сложные цвета. Также помогает время загрузки пакета. Я нашел способ улучшить видимость имени файла и номера строки, чтобы они не становились визуально подавляющими, за счет подчеркивания темно-серым цветом. Это тоже выглядит разумным, поскольку мы привыкли, что пути / ссылки подчеркиваются. Белое или другое выделение было слишком сильным, жирное - слишком слабым.

Кроме того, я переключился на светлые цвета в качестве первых цветов в цикле, что я должен был сделать в первую очередь, но они выглядят одинаково в моей теме, поэтому я никогда не замечал. Это должно быть лучше для тем, в которых темно-синий почти не виден (хотя это ошибка самой темы).

Я зарегистрировал этот стиль как версию 0.2 в ClearStacktrace.jl так что мы можем попробовать его еще немного.

Два примера:

Это действительно хорошая работа.
У вас есть имена параметров светлее, а типы темнее. Так получилось, что это выглядит лучше / читается лучше, чем с более светлыми типами и более темными именами?

Да, поскольку типы обычно намного длиннее, облегчение их не очень помогает.

Случайные мысли:

• может быть, горизонтальные правила между группами записей трассировки стека в одном модуле? может быть, слишком занят поиском
• может быть хорошо и в верхней части трассировки стека, чтобы четко отделить ее от сообщения об ошибке

Все это намного лучше, чем то, что есть сейчас ...

Я отказался от использования Crayon.jl, теперь, когда я больше не использую сложные цвета. Также помогает время загрузки пакета.

Это привело к значительному времени загрузки? Для меня он загружается довольно быстро сам по себе

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

Эта версия отличная, давайте поместим это в Base.

Согласитесь: давайте сделаем последнюю версию.

Спасибо за всю работу, @jkrumbiegel . Приятно иметь версию, которую мы можем опробовать ...

И вилка: я думаю, я думаю, это немного касается того, что ошибка rand(5) .* rand(7) plus занимает 35 строк? Поэтому я сделал https://github.com/mcabbott/ClearStacktrace.jl/tree/milder, чтобы попробовать. (Плюс проблемы с цветом и т. Д., О которых говорилось выше.) Это почти https://github.com/JuliaLang/julia/issues/36026#issuecomment -635294818 с большим количеством цветов.

Обратите внимание, что в текущей трассировке стека кадры 8-11 в этом примере не показаны (они являются частью REPL и будут присутствовать в каждой трассировке стека REPL).

Действительно, ситуация улучшилась, и это здорово. Но он по-прежнему увеличивается с 8 строк (только для трассировки стека) до 20 (ClearStacktrace 0.2). Есть небольшой компромисс между тем, насколько это красиво, и тем, чтобы не потерять свое место.

Пути также печатаются намного более компактно в Base, ./broadcast.jl:495 вместо //Applications/Julia-1.5.app/Contents/Resources/julia/bin/../share/julia/base/broadcast.jl:495 , это также уменьшит потребность в пустых строках.

Базовые пути специально расширены, чтобы сделать их интерактивными. Вы можете отключить это в ClearStacktrace. Я также мог бы сделать новые строки необязательными для людей, которым они не нравятся. Может быть просто переменной окружения.

И, наверное, я пропустил копирование той части функции, которая отсекает последние пару кадров, которые никогда не меняются.

Я отказался от использования Crayon.jl, теперь, когда я больше не использую сложные цвета. Также помогает время загрузки пакета. Я нашел способ улучшить видимость имени файла и номера строки, чтобы они не становились визуально подавляющими, за счет подчеркивания темно-серым цветом. Это тоже выглядит разумным, поскольку мы привыкли, что пути / ссылки подчеркиваются. Белое или другое выделение было слишком сильным, жирное - слишком слабым.

Кроме того, я переключился на светлые цвета в качестве первых цветов в цикле, что я должен был сделать в первую очередь, но они выглядят одинаково в моей теме, поэтому я никогда не замечал. Это должно быть лучше для тем, в которых темно-синий почти не виден (хотя это ошибка самой темы).

Я зарегистрировал этот стиль как версию 0.2 в ClearStacktrace.jl так что мы можем попробовать его еще немного.

Два примера:

Интересно, почему в //Applications/Julia-1.4.app/ есть лишний / //Applications/Julia-1.4.app/ ?

Вероятно, ошибка разделения и повторного присоединения пути

Я отказался от использования Crayon.jl, теперь, когда я больше не использую сложные цвета. Также помогает время загрузки пакета.

Это привело к значительному времени загрузки? Для меня он загружается довольно быстро сам по себе

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

  0.014410 seconds (22.60 k allocations: 2.274 MiB)

Нет, я в основном удалил его, потому что у меня не было его в базе :) Время загрузки было только предположением

Я предполагаю, что может быть слишком много пустых строк, если у нас много кадров stacktrace, как показано в https://github.com/JuliaLang/julia/issues/36026#issuecomment -636912686?

Чтобы не сорвать обсуждение (последняя версия отличная и большое улучшение), но по теме слишком большого количества новых строк проблема в том, что при работе в терминале мне кажется намного лучше напечатать трассировку стека «перевернутой» (как Первоначально я предлагал в https://github.com/JuliaLang/julia/pull/18228) как:

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

Самая важная информация - это само сообщение об ошибке и кадры в верхней части стека (ближе к ошибке) и их печать в таком порядке, который всегда будет виден без прокрутки. Прямо сейчас мне часто приходится прокручивать вверх, чтобы увидеть даже сообщение об ошибке, а не только хвост трассировки стека.

Однако при чтении трассировки стека на веб-сайте, который был скопирован с терминала, вам нужен противоположный порядок, потому что вы прокручиваете сверху вниз, а не снизу вверх, как в терминале ... Довольно сложно получить хороший дизайн для обоих этих случаев.

Однако при чтении трассировки стека на веб-сайте, который был скопирован с терминала, вам нужен противоположный порядок, потому что вы прокручиваете сверху вниз, а не снизу вверх, как в терминале ... Довольно сложно получить хороший дизайн для обоих этих случаев.

На самом деле у меня был код в ClearStacktrace.jl на мгновение, который позволил мне перепечатать последнюю трассировку стека. Я предполагал, что это позволит вырезать сверхдлинные типы при максимальном количестве символов и иметь возможность перепечатать полностью, если потребуется вся информация. Но ваш вариант использования тоже был бы интересен. Я могу представить себе reprint(inverted = true) или даже reprint(html = true) где он будет печатать html-версию, которая сохранит окраску для вставки на веб-сайт.

Кроме того, я согласен с тем, что, учитывая направление прокрутки, имеет смысл инвертировать все по умолчанию.

ipython печатает кадры в обратном порядке, и, несмотря на отсутствие необходимости прокрутки, я всегда находил это необъяснимо запутанным. Возможно, это просто из-за моего предыдущего опыта работы с GDB и другими системами, где самый внутренний фрейм находится наверху, или, возможно, другие люди тоже так думают?

Говоря о gdb, у них есть разумное решение для очень длинных трассировок с помощью пейджера: «нажмите Enter, чтобы увидеть больше кадров».

Кстати, мне нравится последний визуальный дизайн на https://github.com/JuliaLang/julia/issues/36026#issuecomment -636912686, и я буду очень рад, если мы объединим его. Изменение порядка кадров или добавление интерактивных функций кажутся отдельными проблемами.

Что касается имен файлов, я надеюсь, что в конечном итоге мы сможем использовать последовательности OSC гиперссылок терминала (

Говоря о поиске «самого внутреннего фрейма», я использую достаточно языков в ходе своей работы, поэтому я никогда не могу вспомнить, должен ли я смотреть на верхнюю или нижнюю часть трассировки стека для моего кода на каком-либо конкретном языке. В итоге я просматриваю имя файла, пока не найду то, что узнаю. Подчеркивание, показанное здесь, поможет, так что это явное улучшение. Но я все еще задаюсь вопросом, есть ли хороший способ позвать меня, когда я должен смотреть вверх или вниз. В принципе, печать YOUR CODE HERE на одном конце и OTHER CODE HERE на другом мне помогла бы, но это не кажется очень элегантным.

Я сделал PR для базы здесь https://github.com/JuliaLang/julia/pull/36134
Насколько я могу судить, это работает, но мне понадобится помощь, чтобы подготовить его к слиянию.

Есть ли способ опустить параметры типа? Проблема, которую мы видим часто, заключается в том, что количество параметров типа в DiffEq, ForwardDiff и т. Д. Может сделать вещи ... пугающими. Если по умолчанию он просто сказал Dual , за исключением случая, когда есть отправка другим методам из-за параметров типа, тогда, я думаю, вы уменьшите 90% шума в большинстве трассировок стека, которые я читал (и в в других случаях предложение @timholy действительно является тем, что требуется, поскольку обычно речь идет о создании типов или сопоставлении параметров типа)

Если они соответствуют какому-либо существующему псевдониму типа, они просто исчезнут автоматически (# 36107). В противном случае они указывают на возможные узкие места производительности компиляции - так что, возможно, стоит изучить?

Это сделано сейчас.

Для некоторых людей, но большинство людей просто сбиваются с толку, когда он распечатывает шрифт, который занимает 3 страницы печатной бумаги, поэтому, вероятно, это должно быть что-то, что нужно. Я открою еще один вопрос, чтобы обсудить это.

Продолжение https://github.com/JuliaLang/julia/issues/36517