Julia: Apa yang diperlukan untuk menyertakan ClearStacktrace.jl di Base?

Ini akan sangat menyenangkan untuk dimiliki. Atau setidaknya mungkin versi yang dipangkas yang meningkatkan pencetakan stacktrace secara default di Base.

Saya semua mendukung. Hal utama yang tidak saya dapatkan adalah warna di tanda tangan. Mereka tampak... acak? Saya kira warna yang berbeda ada untuk membuatnya lebih mudah untuk memilih elemen yang berbeda, tapi itu agak aneh. Bagaimana dengan warna == kedalaman bersarang? Saya pikir keanehan utama ada di misalnya Tuple{Symbol,Symbol} mana kedua Symbol s adalah warna yang berbeda.

Ada hal lain yang sangat ingin saya lihat:

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

tapi sejak

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

sepertinya kita harus bisa mencetak entri 2 sebagai sesuatu seperti

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

Sebuah komentar kecil, tetapi bagi saya saat ini mungkin terlalu banyak warna "salad". Penghitung stackframe berwarna biru, semua warna berbeda dalam tanda tangan, dll. Untuk warna dasar sejauh ini, kami hanya menggunakan 16 warna sistem (8 + 8 warna cerah) dan itu membuat pewarnaan mewah sedikit lebih sulit.

Saran yang bagus secara keseluruhan. Mungkin beberapa komentar mengapa saya membuat pilihan warna sejauh ini:

Angka-angkanya berwarna biru karena penting, jadi tidak boleh diabu-abukan, tetapi membuatnya putih bagi saya terasa seperti mereka memperebutkan perhatian dengan nama fungsi.

Modul menggunakan warna primer dalam satu siklus, saya pikir ini sangat berguna karena memungkinkan untuk dengan cepat menyaring jejak untuk modul yang relevan. Ini adalah sesuatu yang sangat berkaitan dengan format jejak tumpukan saat ini. Idenya adalah bahwa orang harus dipaksa untuk membaca sesedikit mungkin untuk menemukan apa yang mereka cari. (Saya kebanyakan melakukan penelitian gerakan mata dan perhatian dalam kehidupan akademik saya sejauh ini, jadi aspek-aspek itu penting bagi saya;))

Warna untuk tanda tangan sangat bisa diperdebatkan. Yang pada tangkapan layar di atas dipilih hanya sedikit berbeda dari abu-abu gelap. Pada saat yang sama, saya ingin komponen semantik yang berbeda dapat dibedakan. Itu sebabnya semua tipe dan parameter tipe (kurung kurawal dan koma) menyebabkan perubahan warna. Ada tiga warna yang berarti tidak akan ada dua tetangga dengan warna yang sama. Saya menemukan bahwa cukup sulit untuk melihat satu kata dalam tanda tangan tipe besar jika semuanya hanya putih. Nuansa yang sedikit berbeda banyak membantu tetapi juga membuat semuanya sedikit lebih bising, secara visual.

Karena set 16 warna tidak memiliki warna yang hanya sedikit berbeda dari abu-abu gelap, itu mungkin bukan sesuatu yang dapat disertakan dalam Base. Dalam pembaruan baru-baru ini, saya mengganti warna dengan tiga warna abu-abu yang sedikit berbeda dari set ANSI, tetapi bahkan itu tidak akan didukung di mana pun saya kira.

Oh juga warna bingkai tumpukan dan warna modul serta abu-abu tua dan putih adalah semua warna sistem. Hanya tema VSCode khusus saya yang membuatnya seperti yang Anda lihat di sini.

Ini akan sangat bagus untuk dimiliki.

Saat memindai jenis argumen, seringkali cukup sulit untuk mengetahui di mana satu berhenti dan yang berikutnya dimulai. Mewarnai tingkat atas secara berbeda mungkin sangat membantu di sini, dan bahkan mungkin menghitung argumen:

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

Kita harus dapat menampilkan nama argumen, seperti yang kita lakukan pada pencetakan methods(f) .

bagaimana dengan ini? Saya telah mengganti warna tanda tangan dengan abu-abu gelap, tetapi :: berwarna putih sehingga penting di mana tipe argumen dimulai. sangat membantu dengan monster tipe di posisi 11

Saya suka itu. Akan lebih baik dengan nama argumen.

Sayang sekali bahwa urutan "fungsi - modul - argumen" berfungsi dengan sangat baik untuk tata letak tetapi tidak terlalu masuk akal secara semantik. Saya tidak punya solusi; jelas yang terbaik adalah fungsi yang didahulukan. Mungkin modul bisa masuk ke baris berikutnya sebelum lokasi file? Bagaimanapun, itu adalah bagian dari lokasi. Maka mungkin kita juga tidak membutuhkan header.

Saya pikir kita juga bisa menempatkan angka dalam teks normal, dan nama fungsi dalam huruf tebal dan/atau putih.

Bisakah nama file di akhir jalur kode (dan mungkin nomor baris) mendapatkan warna yang lebih terang juga?

Mungkin modul bisa masuk ke baris berikutnya sebelum lokasi file? Bagaimanapun, itu adalah bagian dari lokasi. Maka mungkin kita juga tidak membutuhkan header.

Saya akan mencoba beberapa hal dengan saran ini.

Bisakah nama file di akhir jalur kode (dan mungkin nomor baris) mendapatkan warna yang lebih terang juga?

Secara teknis tentu saja bisa ;) Itu selalu merupakan tradeoff antara visibilitas yang lebih baik dan kebisingan yang menarik perhatian.

Mengapa tidak menulis modul terlebih dahulu, karena mereka adalah bagian dari nama lengkap fungsi? Mungkin dengan warna mungkin cukup jelas hanya untuk menulis Core.eval dll, atau masih bisa disejajarkan sebagai kolom. (Atau mungkin Anda mencoba ini dan itu tampak mengerikan.)

Pemikiran yang benar-benar gila: jika mencetak tipe argumen membutuhkan lebih dari satu baris, cetak tanda tangan dalam bentuk terlipat dan kemudian gunakan REPL.TerminalMenus untuk memungkinkan pemirsa memperluasnya. Sesuatu seperti:

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

Terkait: #35915 (yang saya rencanakan untuk digunakan untuk membuat menu pohon lipat, https://github.com/JuliaCollections/FoldingTrees.jl).

Bagaimana tampilannya dengan codepath yang disusun ulang dalam urutan ini: LineNumber Filename Path
Kemudian mata Anda memiliki lokasi yang stabil untuk mencari nomor baris dan nama file tanpa warna tambahan yang diperlukan untuk mereka (sepertinya saya selalu mencari nama file dan nomor baris yang terkubur dalam detailnya, dapatkah Anda memberi tahu?)
Dan untuk pekerjaan REPL interaktif, saya suka ide terlipat di atas :)

Mengapa tidak menulis modul terlebih dahulu, karena mereka adalah bagian dari nama lengkap fungsi

Ya, saya suka idenya, saya pikir saya memulai tanpa warna dan itu tidak berhasil dengan baik, tetapi seperti ini sebenarnya cukup mudah dibaca. Saya akan mencoba tanpa kolom berikutnya, meskipun kolom selalu bagus karena memandu mata Anda.

Tidak yakin tentang itu; nama fungsi adalah informasi yang jauh lebih penting daripada modul. Bagi saya setidaknya, info yang paling penting pasti nama fungsi, nama file, dan nomor baris. Juga untuk skrip, kolom kiri akan berisi banyak Main atau kosong, yang tidak ideal untuk kasus penggunaan itu.

Saya pikir ketika saya membaca stacktraces, saya kebanyakan mencari panggilan terakhir dalam kode saya sebelum masuk ke Base/kode paket, karena biasanya bug ada di kode saya. Jadi dalam hal ini modulnya cukup penting dan panggilan fungsi bukanlah yang saya pindai terlebih dahulu.

Bagaimana dengan ini:

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

Nama modul akan tetap berbaris sehingga mudah dipindai.

Saya sebenarnya baru saja mencoba sesuatu yang mendekati itu. Saya mewarnai nama fungsi sendiri kali ini, jadi mereka masih yang paling menonjol tetapi membawa informasi Modul dalam warna mereka. Jadi masih ada pengelompokan yang jelas, tetapi dengan kurang fokus pada semua nama modul.

Pertama kali saya melihat bahwa saya mungkin akan gila mencoba mencari tahu apa arti warnanya :joy: Jika akan ada warna per-modul, tampaknya lebih baik hanya menerapkan warna pada nama modul.

Saya suka nama modul, mereka sedikit tersesat dalam gambar terbaru ini.

Jika mereka berada di bawah, mungkin membuat mereka dengan warna cerah yang sama akan menghubungkan banyak hal? (Dan jelaskan di mana Anda melewati batas modul.) Dan, mungkin, jika nama modul muncul di jalur, itu bisa dengan mudah disorot di sana -- itu juga akan memindahkan nama warna-warni dari tepi kiri di mana fungsinya berada.

Untuk beberapa inspirasi, saya memposting beberapa gambar dari terakhir kali mengubah format stacktrace muncul.

Seringkali paket yang tepat tidak begitu menarik seperti sifat kodenya: apakah itu inti julia, perpustakaan yang saya gunakan, perpustakaan yang saya kembangkan, atau skrip? Kami dapat memiliki empat warna: core/base/dev/stdlib, paket, paket saat ini ]dev ed, dan sisanya (termasuk skrip/REPL). Beberapa perbedaan ini cukup arbitrer dan klasifikasinya agak rapuh, tetapi mewarnai metode berdasarkan ini akan (setidaknya bagi saya) memaksimalkan informasi tanpa menampilkan teks tambahan dan menyimpan kumpulan warna yang kecil dan mudah diingat.

Bagi saya, warna lebih banyak tentang perubahan batas, di mana kode dari satu modul dimulai dan yang lainnya berakhir. Itu sebabnya saya mungkin tidak akan memberikan makna yang melekat pada mereka. Di sisi lain, itu mungkin membingungkan.

Saya sudah mencoba menyederhanakan lebih banyak, dan menghapus kolom lagi karena tanpa kolom modul mereka tidak begitu berguna lagi. Kemudian pertama saya hanya mewarnai nomor baris dengan modul, tetapi ini masih membuat nama file tidak begitu terlihat, yang menurut banyak komentar penting. Jadi saya mewarnai itu dalam warna modul juga. Nama modul itu sendiri tidak berwarna karena terlalu dekat dengan nama fungsi dan terlalu berisik.

Ini adalah versi dengan nomor dan nama file berwarna:

di sini tanpa nama file berwarna

Bisakah Anda juga mencoba mewarnai jalur file lengkap?

Beberapa ide...
Nama file dan nomor baris di lokasi yang konsisten dengan spasi ganda untuk menonaktifkannya.
Warna tingkat tumpukan dan warna modul cocok satu sama lain untuk memasangkan garis terkait secara visual.
Nama file, nomor baris, dan jalur dalam warna yang sedikit berbeda dari tipe parameter untuk membedakan tanpa kekacauan.

[Warna dalam contoh ini sewenang-wenang, lebih memikirkan bagaimana posisi mereka berhubungan.
Level tumpukan yang hilang dalam contoh dan daftar tipe parameter yang dipersingkat pada item terakhir adalah karena saya mengetikkan contoh dengan tangan.]

Kode yang digunakan untuk membuat contoh di atas jika ada yang ingin bermain dengannya:

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

Masalah dengan ini adalah bahwa ini tidak membuat tautan dapat diklik di Atom / VSCode, dll. Ini adalah sesuatu yang sangat sering saya gunakan dan saya yakin orang lain juga melakukannya. Bahkan, saya bahkan secara eksplisit memperluas jalur dasar untuk membuatnya dapat diklik. Ini tentu saja mencetak lebih banyak. Tapi saya pikir itu meningkatkan utilitas. Saya tahu ada beberapa cara untuk melompat ke tumpukan entri jejak dengan nomor di REPL dengan beberapa pintasan, tetapi ini jauh lebih tidak intuitif daripada hanya mengklik tautan menurut saya.

Mungkin masuk akal untuk mengambil kesempatan untuk menyatukan cara info baris dicetak dengan sistem logging, misalnya:

Juga, perhatikan bahwa sistem logging mengontrak homedir

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

Saya pikir ada dua ide inti dalam proposal di sini:

• Minta info baris pada baris yang terpisah dari tanda tangan (dan mungkin batasi dengan beberapa warna agar lebih mudah ditemukan).
• Tunjukkan modulnya.

Jadi, inilah upaya yang sedikit lebih konservatif dengan kedua gagasan itu:

Versi dengan nama variabel ditambahkan, dan warna hanya pada nama modul (tetapi sebaliknya cocok dengan cara @info mencetak jalur):

Yang ini tidak memiliki tanda tangan tipe yang sangat panjang, tetapi mungkin memiliki nama variabel seperti ini (jika memungkinkan?) akan memudahkan untuk menemukan tipe terluar dari setiap argumen.

Jika ada tiga level netral yang tersedia (seperti tebal/normal/abu-abu), maka mencetak jalur file lebih ringan daripada tanda tangan tampaknya (IMO) seperti cara yang baik untuk menghentikan semuanya berjalan bersama. (Ini juga yang dilakukan @info .)

 membiarkan
 printstyled("\njulia> ", warna=:hijau)
 println("f()")
 printstyled("""ERROR: DimensionMismatch("A memiliki dimensi (1,2) tetapi B memiliki dimensi (3,4)")""", color=:light_red)
 println("\nStacktrace:")
 for (idx, err) dalam enumerate(errors)
 mc = idx <= 3 ? :biru : (idx >= 7 ? :biru : :kuning) # Warna modul
 printstyled("[$(err[1])] ", color=:normal, bold=true) # errorno
 printstyled(err[2], color=:normal, bold=true) # function
 printstyled("(", color=:normal) # tipe param
 untuk (i,t) di enumerate(err[3])
 saya != 1 && printstyled(", ", warna=:normal)
 printstyled(Rand('a':'z')^2, color=:light_black)
 printstyled("::", warna=:normal)
 printstyled("$t", warna=:normal)
 akhir
 printstyled(")", warna=:normal)
 println()
 printstyled("@", warna=:hitam_cahaya)
 printstyled(err[6], color=mc) # modul
 printstyled(" $(err[7])/$(err[5]):$(err[4])", color=:light_black) # jalur
 println()
 akhir
 akhir

Saya pikir ada dua ide inti dalam proposal di sini:

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

Jadi, inilah upaya yang sedikit lebih konservatif dengan kedua gagasan itu:

Saya suka ini. Saya pikir istilahnya adalah "bunuh kekasihmu", dan sayangku mungkin warnanya. Tapi saya bisa melihat bagaimana sesuatu yang lebih halus mungkin lebih cocok untuk sesuatu yang begitu mendasar. Saya mengubahnya sedikit sehingga nama modul dan nama fungsi sejajar, yang menciptakan garis kontras vertikal yang hampir mirip kolom. Itu akan membantu untuk menemukan informasi yang relevan. Meskipun saya masih berpikir saya tidak akan menempatkan jenisnya dalam warna putih, karena mereka menjadi sangat berantakan. Jika kita memiliki nama variabel, mungkin yang berwarna putih akan terlihat bagus.

Saya suka ini. Saya pikir istilahnya adalah "bunuh kekasihmu", dan sayangku mungkin warnanya.

Agar Anda tahu bahwa saya tahu situasi Anda, https://github.com/JuliaLang/julia/pull/18228. Ini adalah topik yang sangat menyenangkan untuk bikeshed dan setiap orang memiliki seember cat, heh. Seperti yang Anda lihat, PR itu juga dimulai dengan cukup ambisius tetapi perlahan-lahan menjadi semakin konservatif heh.

Bagi saya, proposal terakhir jelas merupakan perbaikan dari status quo. Dua hal yang saya pikirkan:

• Jika memungkinkan, alangkah baiknya untuk memiliki semacam "pengait" untuk mata Anda untuk informasi garis karena cenderung menyatu dengan tanda tangan ketika tanda tangan panjang.
• Kita mungkin harus menyelaraskan nomor stackframe ketika ada lebih dari 10 di antaranya:
  [ 8] [ 9] [10] [11]
  dll. Itu akan membuat @ juga berbaris.

Saya menyukainya, saya pikir kita akan mencapai suatu tempat. Berhati-hati dengan warna selalu baik, karena itu memperlihatkan lebih sedikit area permukaan untuk bikeshedding, ditambah mengurangi risiko bahwa warna tidak akan terbaca di terminal seseorang.

Memberi jarak itu baik, tetapi sayangnya sintaks f (...) secara eksplisit tidak diizinkan, jadi saya pikir kita perlu menghapus spasi atau menghapus parens.

Sampel terbaru umumnya terlihat bagus, tetapi saya mendukung idenya:

Jika memungkinkan, alangkah baiknya untuk memiliki semacam "pengait" untuk mata Anda untuk informasi garis karena cenderung menyatu dengan tanda tangan ketika tanda tangan panjang.

Dan saya harap kait itu memiliki warna yang berbeda atau (lebih disukai) kecerahan.

Mungkin Anda bisa melakukan siklus warna untuk modul tetapi hanya menerapkannya ke [ ] di kedua sisi nomor level tumpukan jadi jika Anda tidak dapat melihat warna karena alasan tertentu tidak banyak yang hilang.

Mungkin Anda bisa melakukan siklus warna untuk modul tetapi hanya menerapkannya pada [ ]

Bahkan sulit untuk melihat warna dengan benar jika itu hanya tanda kurung dan mereka berada di area yang kontras, jadi saya rasa itu tidak berfungsi dengan baik..

sintaks f (...) tidak diizinkan secara eksplisit

Saya pikir itu bekerja dengan baik bahkan tanpa ruang, karena perbedaan kontras.

Jika memungkinkan, akan menyenangkan untuk memiliki semacam "pengait" untuk mata Anda untuk informasi garis

Saya setuju, saya pikir itu bekerja dengan baik untuk membiarkan nomor baris menjadi abu-abu tetapi menebalkannya, itu membuatnya sedikit menonjol jika Anda mencarinya tetapi langkah selanjutnya untuk membuatnya putih terlalu berisik menurut saya.

Kita mungkin harus menyelaraskan nomor stackframe

Saya mencobanya dengan spasi di dalam tanda kurung seperti pada contoh Anda, tetapi ternyata itu terlihat agak aneh, jadi sekarang saya menyelaraskan angka dalam tanda kurung dengan benar. Saya pikir itu bekerja dengan cukup baik.

Inilah versi terbaru dengan semua ide yang tergabung:

Dan sebagai bonus, inilah tampilannya dengan nama variabel (acak). Sekali lagi saya hanya menggunakan abu-abu tebal karena semua nama variabel ini seharusnya tidak memperebutkan perhatian Anda, tetapi harus sedikit terlihat jika Anda mencarinya

Saya suka ke mana arahnya juga. Saya hanya ingin memberikan suara untuk beberapa jenis penyorotan nama modul. Saya sebenarnya cukup menyukai gaya di mana modul yang sama diwarnai dengan cara yang sama dan siklus melalui warna (ada masalah warna grafik di sini jika Anda menganggap dua garis jejak tumpukan berdekatan sebagai tepi grafik di antara modul mereka). Sayangnya, sangat tidak jelas apa arti warna itu. Mungkin mewarnai semua nama modul dalam satu warna?

Penjajaran ini terlihat bagus bagi saya.

Saya masih berpikir bahwa memiliki jalur yang lebih jelas berbeda dari tanda tangan akan membantu memecah hal-hal - 3 tingkat kepentingan, nama/tanda tangan/jalur. Makro logging @info dll. mencetaknya lebih terang daripada baris lainnya.

Nama variabel akan sangat menyenangkan untuk dimiliki. Akankah memilih bahwa mereka kurang penting daripada informasi tanda tangan, mungkin?

Memiliki nama modul yang berbaris di sebelah kiri memang membantu Anda memindainya, meskipun saya sedih melihat warnanya hilang.

Mataku sepertinya tahu di mana menemukan hal-hal yang satu ini :)
Apakah garis kosong antar modul akan menggunakan terlalu banyak ruang vertikal?

Mewarnai baris dengan 2 warna berbeda sehingga baris alternatif memiliki warna yang sama - seperti yang sering dilakukan dalam tabel dapat membantu keterbacaan.

Siklus warna @ di sebelah nama modul alih-alih nama modul itu sendiri menonjol (karena @ adalah karakter yang cukup besar) tanpa terlalu bersaing dengan nama fungsi yang disorot.

Saya sering mengharapkan nama parameter karena mereka membantu Anda menemukan tipe parameter yang tepat tanpa harus menghitungnya.

Mungkinkah jalurnya (dan mungkin nama modul di sebelahnya) memiliki kecerahan yang berbeda dari tipenya? Mungkin hanya mencocokkan nama parameter? (Atau semua cahaya redup bersama jika Anda melakukan saran mcabbott untuk membuat nama lebih redup daripada jenisnya)

Anda dapat secara eksplisit mencerminkan apa yang digunakan logging, meskipun idealnya dengan warna yang berbeda:

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

Sunting: sekarang dengan satu baris lagi yang membungkus, dan gambar:

Anda dapat secara eksplisit mencerminkan apa yang digunakan logging

Hal yang saya tidak begitu suka tentang ini adalah jeda baris yang hanya ada karena lebar REPL tertentu tidak dapat ditransfer dengan baik jika Anda mengubah ukuran jendela / REPL Anda (jika Anda ingin memberi ruang untuk garis yang lebih panjang misalnya ) atau salin / tempel teks ke jendela dengan lebar berbeda

Ya, saya tidak akan mengusulkan secara eksplisit melanggar garis untuk membuat penanda terus menerus. Bahkan mungkin merupakan hal yang baik untuk membiarkan garis yang dibungkus menerobos, dan karenanya terlihat berbeda. Sebagian besar pemikiran tentang bagaimana mengikat warna ke nama fungsi, dan bagaimana membuatnya mungkin kurang menonjol, jika itu adalah bagian dari perbatasan alih-alih terlihat seperti heading yang paling penting.

Saya harus mengatakan saya menyukai warnanya tetapi saya dapat memahami preferensi untuk bersikap konservatif dengannya.

Namun, saya ingin memberikan dukungan saya di belakang sesuatu seperti

Seringkali paket yang tepat tidak begitu menarik seperti sifat kodenya: apakah itu inti julia, perpustakaan yang saya gunakan, perpustakaan yang saya kembangkan, atau skrip? Kami dapat memiliki empat warna: core/base/dev/stdlib, paket, paket saat ini ]dev ed, dan sisanya (termasuk skrip/REPL). [...]

Karena saya tidak meretas basis dan jarang menggunakan paket (seperti yang dilakukan kebanyakan orang, saya kira), 90% kesalahan perlu diperbaiki dalam skrip saya, 9% dalam paket dan 1% di basis. Jika saya membuat kesalahan dengan memanggil suatu fungsi, saya tidak perlu tahu persis di sini di dasar kesalahan itu terjadi karena saya tidak akan masuk ke sana untuk memperbaikinya, saya harus memperbaiki kode saya.

Jadi saya akan menghargai beberapa pembantu visual untuk melihat di mana saya meninggalkan kode saya (dan mungkin juga di mana saya meninggalkan kode paket, masuk ke basis) karena dalam banyak kasus apa pun setelah itu saya dapat dengan aman mengabaikan untuk saat ini. Jika tidak melalui warna, mungkin dengan -------------------------------------------- atau apa? Seharusnya hanya ada 2-3 dari mereka.

Jika modul diwarnai, maka mungkin Base/Core harus ditinggalkan dan tidak diberi warna.

Saya sebenarnya cukup menyukai gaya di mana modul yang sama diwarnai dengan cara yang sama dan siklusnya melalui warna

Aku baik-baik saja dengan itu juga. Jika kita akan menggunakan banyak warna, saya pikir mereka harus digunakan untuk itu. Ini juga membantu memilih batas antara pengguna dan kode paket tanpa mengambil terlalu banyak ruang vertikal.

Jika modul diwarnai, maka mungkin Base/Core harus ditinggalkan dan tidak diberi warna.

Ya, Base dan Core bisa saja selalu berwarna abu-abu gelap atau semacamnya, meninggalkan lebih banyak warna untuk orang lain :)

Jika ini berhenti bekerja dengan sempurna dalam 16 warna, maka mungkin bagus untuk menjadikannya hash dari nama modul, sehingga Anda akan menghafal beberapa di antaranya.

Atau hanya memiliki dua warna, satu untuk Base/Core dan satu untuk modul eksternal?

Saya pikir seharusnya tidak menjadi masalah untuk menggilir warna karena versi saya saat ini memiliki 6 opsi non-skala abu-abu:

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

Ada varian terang juga, saya kira, tetapi skema warna saya di VSCode (Material) mengaturnya sama dengan saudara kandung yang lebih gelap, jadi saya berasumsi itu bisa terjadi di beberapa skema. Tetapi seberapa besar kemungkinan jejak tumpukan melewati lebih dari 6 modul perpustakaan non-basis atau non-standar yang berbeda? Tentu saja paket menggunakan kode dari berbagai modul, tetapi dalam satu tumpukan tertentu tidak boleh ada bahwa banyak. Setidaknya itu tidak akan menyebabkan masalah besar saat menguraikan jejak tumpukan, bahkan jika ada tabrakan warna.

maka mungkin bagus untuk menjadikannya hash dari nama modul, sehingga Anda akan menghafal beberapa di antaranya

Ini sebenarnya agak brilian.

Senang melihat orang-orang mengerjakan ini.
Saya tertarik untuk melihat bagaimana keselarasan yang benar dari nama-nama fungsi terlihat:

 [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

Mungkin lebih mudah bagi mata untuk menangkap di mana argumen fungsi dimulai dan menawarkan bantuan untuk menguraikan rantai panggilan fungsi tanpa membuang banyak ruang. Masih perlu didukung oleh warna, jika tidak info lokasi dan argumen akan menenggelamkan segalanya.

maka mungkin bagus untuk menjadikannya hash dari nama modul, sehingga Anda akan menghafal beberapa di antaranya

Ini sebenarnya agak brilian.

Oh, halo teal gelap, teman lamaku...

maka mungkin bagus untuk menjadikannya hash dari nama modul, sehingga Anda akan menghafal beberapa di antaranya

Saya dulu meminta emacs melakukan hal itu untuk nama panggilan IRC. Itu tidak berhasil dengan baik karena beberapa teman saya diberi warna yang sama dan itu lebih membingungkan daripada apa pun, jadi saya akhirnya memberikan kode warna yang sulit untuk teman-teman saya. Saya tidak akan merekomendasikan pergi ke rute itu, betapapun kerennya tampaknya. Memiliki set warna yang dikurangi untuk setiap jenis kode (misalnya Julia, paket, paket yang dikembangkan, pengguna) tampaknya lebih berguna.

Saya mendapatkan skema warna editor yang melakukan ini, dan ini cukup berguna -- semua variabel yang mungkin berwarna biru adalah berbagai nuansa hijau & biru, dengan string & kata kunci, dll. yang berbeda. Mungkin idealnya akan seperti ini dalam kelas luas seperti yang Anda sarankan (misalnya perpustakaan standar berwarna merah-ungu, diunduh dalam warna hijau-biru, dikembangkan dalam warna oranye-kuning, dasar abu-abu). Atau mungkin ini terlalu banyak pekerjaan!

iterasi lain: Saya mencoba memasukkan nama variabel di sana, meskipun semuanya terasa sangat rumit bagi saya karena saya tidak terlalu akrab dengan semua internal. Saya mewarnai ulang modul karena tampaknya mendapat respons positif secara umum, meskipun masih bisa diperdebatkan bagaimana warna harus ditetapkan. Tetapi dengan warna, saya merasa bahwa modul dari satu entri sedikit berbenturan dengan nama fungsi berikutnya. Jadi saya memperkenalkan jeda baris. Membuat semuanya lebih lama tentu saja, tapi saya suka ruang bernapas tambahan dan kejelasan

Saya suka sampel terakhir Anda, sangat jelas dan mudah dibaca :)

Di bawah ini hanyalah percobaan menerapkan pewarnaan modul ke "@" alih-alih nama modul untuk mengurangi bentrokan yang Anda sebutkan dengan nama fungsi, dan mencoba menyorot jenisnya sehingga jalur dapat dibedakan sedikit lebih mudah tanpa harus memasukkan kosong garis.

@jkrumbiegel Itu indah. Aku butuh ini dalam hidupku.

Saya suka blues lembut itu

@jkrumbiegel Bagus, saya tidak yakin simbol @ diperlukan, mungkin terlihat lebih bersih tanpanya. Jika Anda ingin menjelaskan informasi apa itu, sebaiknya tulis saja seperti yang disarankan Jeff:
in MakieLayout at ~/.julia/packages/MakieLayout/COfBu/src/lineaxis.jl:372

@jkrumbiegel Itu tampak hebat! Apakah ada cara untuk menyorot hanya nama file (bukan path lengkap) dan nomor baris? Mungkin abu-abu sedikit lebih cerah?

Cantik! Saya sebenarnya sangat menyukai jeda baris—mereka benar-benar membantu secara visual dan jejak tumpukan kami cenderung sangat panjang sehingga saya harus tetap menggulir, saya lebih suka itu jelas daripada mengurangi pengguliran sedikit.

:: yang disorot sangat brilian. Jika saya harus memplot kurva yang menunjukkan konten informasi setiap karakter dari daftar parameter terhadap posisi karakter, :: tepat menandai maxima lokal dari kurva itu. Saya tahu untuk melihat ke kiri mereka untuk nama dan ke kanan untuk bagian terpenting dari jenisnya, setelah itu konten informasi hanya turun.

Saya tidak setuju dengan komentar ini: penyorotan harus menekankan hal-hal penting agar mata tahu apa yang harus dibaca, dan :: jelas bukan hal penting yang harus saya baca. Seperti berdiri putih jauh lebih terlihat daripada biru tua yang berani. Membedakan parameter akan lebih jelas dengan hanya memiliki putih nama argumen (mungkin dengan pengecualian ketika tidak ada argumen bernama, dalam hal ini :: mungkin juga putih untuk membatasi argumen). Hal yang sama berlaku untuk nomor baris, saya lebih suka menekankan nama file daripada nomor baris.

Nama paket berwarna berisiko menutupi hal yang paling penting, nama fungsi, tetapi memiliki yang dicetak tebal dan dengan jeda baris benar-benar membatasi risiko itu, bagus!

Saya berpikir tentang :: banyak sebelum saya membuat mereka putih. Tentu saja nama dan tipe argumen adalah informasi yang sebenarnya, jadi Anda mungkin berpikir mereka harus disorot. Tapi kesan kuat saya ketika menyoroti mereka adalah bahwa mereka meminta perhatian Anda. Tapi itu tidak penting untuk membaca setiap nama dan jenis. Anda seharusnya dapat menemukan yang Anda cari dalam fungsi tertentu. Bagaimana saya melihat langkah-langkah membaca jejak tumpukan:

1. Dapatkan gambaran umum
2. Fungsi apa di modul apa yang error?
3. Apa fungsi lain yang disebut fungsi ini dari modul lain mana?
4. Apakah ada batas kritis antara kode saya sendiri dan basis atau kode paket lainnya? Dimana itu?
5. Apa fungsi pada batas tersebut?
6. Jenis/argumen apa yang digunakan? Di mana satu argumen berakhir dan yang berikutnya dimulai? Ini sangat sulit dengan tipe parametrik panjang sekarang.
7. Apakah itu menjelaskan kesalahannya?
8. Jika ini tidak membantu, selesaikan semuanya dengan sisir yang bagus

Jadi informasi tipe/argumen menurut saya hanya digunakan setelah berorientasi dan memahami struktur umum. Satu hal yang perlu dipahami tentang penyorotan adalah bahwa hal itu tidak selalu memudahkan untuk menemukan sesuatu, hanya jika sorotannya relatif jarang. Jadi saya pikir :: sorotan tidak menghalangi dan menarik perhatian Anda sampai Anda mulai mencari informasi variabel/tipe. Dan pada langkah itu memberikan mata Anda kait untuk melompat, tidak lebih, tidak kurang. Saya menemukan itu cukup efisien.

Sebagai catatan tambahan, tidak setiap argumen memiliki nama, jadi menyorot nama variabel tidak selalu memberi Anda pemisahan yang baik. Saya pikir :: selalu ada.

Itu sepertinya daftar yang bagus, keluhan utama saya adalah poin 6, menemukan celah dalam tanda tangan tipe panjang. Mencetak :: super-bright memang membantu, meskipun saya setuju ini agak aneh. Mencetak nama argumen (atau mungkin beberapa _1 placeholder jika tidak ada) akan sedikit membantu. Mungkin mencetak tipe terluar secara normal, dan kemudian semua argumennya berwarna abu-abu, akan banyak membantu?

Berapa banyak level penyorotan yang sebenarnya tersedia? :white tidak akan menonjol pada latar belakang terang, sebenarnya saya pikir kita mungkin terbatas pada normal, tebal, dan :light_black (plus warna). Saat ini nama fungsi dan jalurnya dicetak tebal. Di @error dll, jalurnya adalah light_black, yang tampaknya bagus.

Saya suka penggunaan warna untuk menyorot modul. Dalam beberapa contoh di atas, teks ini lebih cemerlang dari teks lainnya, tetapi apakah ini benar untuk warna sederhana? Dalam beberapa tema yang berbeda, "Modul" di sini relatif tidak terdengar (dan ::Array, ::Adjoint, ::Int cukup jelas sebagai tanda tangan tingkat atas):

    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

iterasi lain: Saya mencoba memasukkan nama variabel di sana, meskipun semuanya terasa sangat rumit bagi saya karena saya tidak terlalu akrab dengan semua internal. Saya mewarnai ulang modul karena tampaknya mendapat respons positif secara umum, meskipun masih bisa diperdebatkan bagaimana warna harus ditetapkan. Tetapi dengan warna, saya merasa bahwa modul dari satu entri sedikit berbenturan dengan nama fungsi berikutnya. Jadi saya memperkenalkan jeda baris. Membuat semuanya lebih lama tentu saja, tapi saya suka ruang bernapas tambahan dan kejelasan

Mungkin sedikit di luar topik tetapi karena kita memiliki ini, dapatkah kita memiliki show lebih cantik untuk output methods dan methodswith ? Ini juga menyakitkan.

Juga, warna modul bisa menjadi warna yang redup, seperti tidak persis kuning, tetapi abu-abu-kuning. Atau, bisakah kita mengatur warna-warna itu, seperti, startup.jl ?

@jkrumbiegel Itu tampak hebat! Apakah ada cara untuk menyorot hanya nama file (bukan path lengkap) dan nomor baris? Mungkin abu-abu sedikit lebih cerah?

Itu bisa: https://github.com/JuliaLang/julia/issues/36026#issuecomment -634481656. Tapi agak aneh bagi saya karena nama file adalah bagian dari path jadi mengapa menggunakan warna yang berbeda? Biasanya, saya hanya mengklik path, dan VSCode akan membukanya untuk saya sehingga tidak masalah apa nama file itu.

Saya telah beralih dari menggunakan Crayon.jl, sekarang saya tidak lagi menggunakan warna kompleks. Membantu dengan waktu buka paket juga. Saya menemukan cara untuk meningkatkan visibilitas nama file dan nomor baris tanpa menjadi berlebihan secara visual dengan menggarisbawahi abu-abu gelap. Itu terlihat masuk akal juga, karena kami terbiasa dengan jalur/tautan yang digarisbawahi. Sorotan putih atau lainnya terlalu kuat di sana, tebal terlalu lemah.

Juga, saya telah beralih ke warna-warna terang sebagai warna pertama di pengendara sepeda, yang seharusnya saya lakukan sejak awal, tetapi mereka terlihat sama di tema saya jadi saya tidak pernah menyadarinya. Ini seharusnya lebih baik untuk tema di mana biru tua hampir tidak terlihat (itulah kesalahan tema).

Saya telah mendaftarkan gaya ini sebagai versi 0.2 di ClearStacktrace.jl sehingga kami dapat mencobanya sedikit lagi.

Dua contoh:

Itu benar-benar pekerjaan yang bagus.
Anda memiliki nama parameter yang lebih terang dan tipe yang lebih gelap. Apakah itu ternyata terlihat lebih baik/terbaca lebih baik daripada dengan tipe yang lebih terang dan nama yang lebih gelap?

Ya, karena jenisnya biasanya lebih panjang, tidak banyak membantu untuk membuatnya lebih ringan.

Pikiran acak:

• mungkin aturan horizontal antara grup entri jejak tumpukan dalam modul yang sama? mungkin terlalu sibuk mencari
• mungkin bagus di bagian atas jejak tumpukan juga, untuk memisahkannya dengan jelas dari pesan kesalahan

Semua ini jauh lebih baik daripada apa yang kita miliki sekarang ...

Saya telah beralih dari menggunakan Crayon.jl, sekarang saya tidak lagi menggunakan warna kompleks. Membantu dengan waktu buka paket juga.

Apakah itu menyebabkan waktu buka yang signifikan? Ini memuat cukup cepat sendiri untuk saya

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

Versi ini bagus, mari kita taruh ini di Base.

Setuju: mari kita lakukan versi terakhir itu.

Terima kasih telah melakukan semua pekerjaan di sini, @jkrumbiegel . Bagus untuk memiliki versi yang bisa kita coba...

Dan fork: Saya kira saya pikir ini sedikit tentang rand(5) .* rand(7) plus error menempati 35 baris? Jadi saya membuat https://github.com/mcabbott/ClearStacktrace.jl/tree/milder untuk dicoba. (Ditambah masalah warna dll yang dibahas di atas.) Ini hampir https://github.com/JuliaLang/julia/issues/36026#issuecomment -635294818 dengan lebih banyak warna.

Catatan dalam bingkai pencetakan stacktrace saat ini 8-11 dalam contoh itu tidak ditampilkan (mereka adalah bagian dari REPL dan akan ada di setiap REPL stacktrace).

Memang, ini telah meningkat yang sangat bagus. Tapi itu masih berjalan dari 8 baris (untuk jejak tumpukan saja) menjadi 20 (ClearStacktrace 0.2). Ada sedikit trade-off antara betapa cantiknya & tidak kehilangan tempat Anda.

Jalur juga dicetak jauh lebih kompak di Base, ./broadcast.jl:495 daripada //Applications/Julia-1.5.app/Contents/Resources/julia/bin/../share/julia/base/broadcast.jl:495 , ini juga akan mengurangi kebutuhan akan baris kosong.

Jalur dasar diperluas dengan tujuan agar dapat diklik. Anda dapat menonaktifkannya di ClearStacktrace. Saya juga bisa membuat baris baru opsional untuk orang yang tidak menyukainya. Bisa saja menjadi variabel lingkungan.

Dan saya kira saya pasti melewatkan menyalin bagian dari fungsi yang memotong beberapa bingkai terakhir yang tidak pernah berubah

Saya telah beralih dari menggunakan Crayon.jl, sekarang saya tidak lagi menggunakan warna kompleks. Membantu dengan waktu buka paket juga. Saya menemukan cara untuk meningkatkan visibilitas nama file dan nomor baris tanpa menjadi berlebihan secara visual dengan menggarisbawahi abu-abu gelap. Itu terlihat masuk akal juga, karena kami terbiasa dengan jalur/tautan yang digarisbawahi. Sorotan putih atau lainnya terlalu kuat di sana, tebal terlalu lemah.

Juga, saya telah beralih ke warna-warna terang sebagai warna pertama di pengendara sepeda, yang seharusnya saya lakukan sejak awal, tetapi mereka terlihat sama di tema saya jadi saya tidak pernah menyadarinya. Ini seharusnya lebih baik untuk tema di mana biru tua hampir tidak terlihat (itulah kesalahan tema).

Saya telah mendaftarkan gaya ini sebagai versi 0.2 di ClearStacktrace.jl sehingga kami dapat mencobanya sedikit lagi.

Dua contoh:

Penasaran kenapa ada tambahan / di //Applications/Julia-1.4.app/ ?

Mungkin bug dari membelah dan bergabung kembali dengan jalur

Saya telah beralih dari menggunakan Crayon.jl, sekarang saya tidak lagi menggunakan warna kompleks. Membantu dengan waktu buka paket juga.

Apakah itu menyebabkan waktu buka yang signifikan? Ini memuat cukup cepat sendiri untuk saya

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

  0.014410 seconds (22.60 k allocations: 2.274 MiB)

Tidak, saya kebanyakan menghapusnya karena saya tidak akan memilikinya di pangkalan :) Waktu muat hanya perkiraan

Saya kira mungkin ada terlalu banyak baris kosong jika kita memiliki banyak bingkai stacktrace seperti yang ditunjukkan di https://github.com/JuliaLang/julia/issues/36026#issuecomment -636912686 ?

Bukan untuk menggagalkan diskusi (versi terakhir bagus dan peningkatan besar) tetapi pada topik terlalu banyak baris baru, masalahnya adalah ketika bekerja di terminal, tampaknya jauh lebih baik bagi saya untuk mencetak stacktrace "terbalik" (sebagai Saya awalnya mengusulkan di https://github.com/JuliaLang/julia/pull/18228) sebagai:

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

Informasi yang paling penting adalah pesan kesalahan itu sendiri dan bingkai ke arah atas tumpukan (mendekati kesalahan) dan mencetaknya dalam urutan ini yang akan selalu terlihat tanpa menggulir. Saat ini saya sering harus menggulir ke atas untuk melihat pesan kesalahan dan bukan hanya ekor stacktrace.

Namun, ketika membaca stacktrace di situs web yang telah disalin-tempel dari terminal, Anda menginginkan urutan yang berlawanan karena Anda menggulir dari atas ke bawah sebagai lawan dari bawah ke atas seperti yang Anda lakukan di terminal... Agak sulit untuk mendapatkan desain yang baik untuk kedua kasus ini.

Namun, ketika membaca stacktrace di situs web yang telah disalin-tempel dari terminal, Anda menginginkan urutan yang berlawanan karena Anda menggulir dari atas ke bawah sebagai lawan dari bawah ke atas seperti yang Anda lakukan di terminal... Agak sulit untuk mendapatkan desain yang baik untuk kedua kasus ini.

Saya sebenarnya memiliki kode di ClearStacktrace.jl sejenak yang memungkinkan saya untuk mencetak ulang stacktrace terakhir. Saya telah membayangkan bahwa untuk memotong tipe super panjang pada beberapa karakter maksimum dan dapat mencetak ulang secara penuh jika seluruh informasi diperlukan. Tetapi kasus penggunaan Anda juga akan menarik. Saya dapat membayangkan reprint(inverted = true) atau bahkan reprint(html = true) mana ia akan mencetak versi html yang akan mempertahankan pewarnaan untuk ditempelkan ke situs web.

Juga, saya setuju bahwa mengingat arah pengguliran, masuk akal untuk membalikkan semuanya secara default.

ipython mencetak bingkai dalam urutan yang berlawanan, dan meskipun tidak harus menggulir, saya selalu menemukan hal itu membingungkan. Mungkin itu hanya karena pengalaman saya sebelumnya dengan gdb dan sistem lain di mana bingkai terdalam berada di atas, atau mungkin orang lain juga merasakan hal ini?

Berbicara tentang gdb, mereka memiliki solusi yang masuk akal untuk jejak yang sangat panjang dengan pager mereka: "tekan enter untuk lebih banyak frame".

Omong-omong, saya menyukai desain visual terbaru di https://github.com/JuliaLang/julia/issues/36026#issuecomment -636912686 dan akan sangat senang jika kami menggabungkannya. Mengubah urutan bingkai atau menambahkan fitur interaktif tampak seperti masalah terpisah.

Mengenai nama file, saya berharap pada akhirnya kita dapat menggunakan urutan OSC hyperlink terminal ( ya hyperlink di terminal agak didukung secara luas! ) dan memiliki cara bagi editor pengguna untuk mengambilnya.

Berbicara tentang menemukan "bingkai terdalam", saya menggunakan cukup banyak bahasa dalam pekerjaan saya sehingga saya tidak pernah dapat mengingat apakah saya harus mencari di bagian atas atau bawah stacktrace untuk kode saya dalam bahasa tertentu. Jadi saya akhirnya memindai dengan melihat nama file sampai saya melihat yang saya kenali. Garis bawah yang ditunjukkan di sini akan membantu, jadi ini adalah peningkatan yang jelas. Tetapi saya masih bertanya-tanya apakah ada cara yang baik untuk memanggil apakah saya harus melihat ke atas atau ke bawah. Pada prinsipnya mencetak YOUR CODE HERE di satu ujung dan OTHER CODE HERE di ujung lain akan membantu saya, tetapi tampaknya tidak terlalu elegan.

Saya telah membuat PR ke Base di sini https://github.com/JuliaLang/julia/pull/36134
Ini berfungsi sejauh yang saya tahu, tetapi saya perlu bantuan untuk membuatnya siap untuk digabungkan

Apakah ada cara untuk menghilangkan parameter tipe? Masalah yang sering kita lihat adalah jumlah parameter tipe di DiffEq, ForwardDiff, dll. dapat membuat segalanya... menakutkan. Jika secara default hanya dikatakan Dual , kecuali dalam kasus di mana ada pengiriman ke metode lain karena parameter tipe, maka saya pikir Anda akan mengurangi 90% kebisingan di sebagian besar jejak tumpukan yang saya baca (dan di kasus lain, saran @timholy benar-benar diperlukan, karena biasanya tentang membuat tipe atau mencocokkan parameter tipe)

Jika mereka sesuai dengan beberapa alias tipe yang ada, mereka akan hilang secara otomatis sekarang (#36107). Jika tidak, mereka menunjukkan kemungkinan kemacetan kinerja kompilasi — jadi mungkin perlu diselidiki?

Ini dilakukan sekarang.

Bagi sebagian orang, tetapi kebanyakan orang hanya menjadi bingung ketika mencetak jenis yang akan memakan 3 halaman kertas cetak, jadi mungkin itu adalah sesuatu yang ikut serta. Saya akan membuka masalah lain untuk membahas itu.

Lanjutan di https://github.com/JuliaLang/julia/issues/36517