Julia: ClearStacktrace.jl को बेस में शामिल करने के लिए क्या आवश्यक है?

यह होना वाकई अच्छा होगा। या कम से कम शायद एक छंटनी वाला संस्करण जो बेस में डिफ़ॉल्ट रूप से स्टैकट्रेस की छपाई में सुधार करता है।

मैं सब पक्ष में हूं। मुख्य चीज जो मुझे नहीं मिलती वह है हस्ताक्षर में रंग। वे लग रहे हैं...यादृच्छिक? मुझे लगता है कि विभिन्न तत्वों को चुनना आसान बनाने के लिए अलग-अलग रंग हैं, लेकिन यह थोड़ा अजीब है। रंग == घोंसले की गहराई के बारे में कैसे? मुझे लगता है कि मुख्य अजीबता उदाहरण में है 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 रंगों के सेट में ऐसे रंग नहीं होते हैं जो केवल गहरे भूरे रंग से थोड़े अलग होते हैं, यह शायद ऐसा कुछ नहीं है जिसे बेस में शामिल किया जा सके। हाल के एक अपडेट में, मैंने एएनएसआई सेट से ग्रे के तीन अलग-अलग रंगों के साथ रंगों को बदल दिया, लेकिन यहां तक ​​​​कि हर जगह मुझे लगता है कि इसका समर्थन नहीं किया जाएगा।

ओह भी स्टैक फ्रेम रंग और मॉड्यूल रंग के साथ-साथ गहरे भूरे और सफेद सभी सिस्टम रंग हैं। यह सिर्फ मेरी विशेष वीएससीओडी थीम है जो उन्हें प्रस्तुत करती है जैसे आप यहां देखते हैं।

यह होना बहुत अच्छा होगा।

तर्क प्रकारों को स्कैन करते समय, अक्सर यह पता लगाना बहुत कठिन होता है कि एक कहाँ रुकता है और अगला शुरू होता है। शीर्ष स्तर को अलग-अलग रंग देना यहां बहुत मददगार हो सकता है, और शायद तर्कों को भी क्रमांकित करना:

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

हमें तर्क नाम दिखाने में सक्षम होना चाहिए, जैसे हम methods(f) की छपाई में करते हैं।

यह कैसा हैं? मैंने हस्ताक्षर रंगों को गहरे भूरे रंग से बदल दिया है, लेकिन :: सफेद है इसलिए यह मुख्य है जहां तर्क प्रकार शुरू होते हैं। स्थिति 11 . पर राक्षस प्रकार के साथ विशेष रूप से सहायक

मुझें यह पसंद है। तर्क नामों के साथ और भी बेहतर होगा।

यह बहुत बुरा है कि ऑर्डर "फ़ंक्शन - मॉड्यूल - तर्क" लेआउट के लिए बहुत अच्छा काम करता है लेकिन वास्तव में अर्थपूर्ण रूप से समझ में नहीं आता है। हालांकि मेरे पास कोई समाधान नहीं है; स्पष्ट रूप से फ़ंक्शन के लिए पहले आना सबसे अच्छा है। शायद मॉड्यूल फ़ाइल स्थान से पहले अगली पंक्ति पर जा सकता है? आखिरकार यह स्थान का हिस्सा है। तो शायद हमें हेडर की भी जरूरत नहीं पड़ेगी।

मुझे लगता है कि हम संख्याओं को सामान्य पाठ में और फ़ंक्शन नामों को बोल्ड और/या सफेद में भी डाल सकते हैं।

क्या कोडपथ के अंत में फ़ाइल नाम (और संभवतः लाइन नंबर) को अपना हल्का रंग भी मिल सकता है?

शायद मॉड्यूल फ़ाइल स्थान से पहले अगली पंक्ति पर जा सकता है? आखिरकार यह स्थान का हिस्सा है। तो शायद हमें हेडर की भी जरूरत नहीं पड़ेगी।

मैं इन सुझावों के साथ कुछ चीजों की कोशिश करूँगा।

क्या कोडपथ के अंत में फ़ाइल नाम (और संभवतः लाइन नंबर) को अपना हल्का रंग भी मिल सकता है?

यह तकनीकी रूप से निश्चित रूप से कर सकता है;) यह हमेशा बेहतर दृश्यता और ध्यान खींचने वाले शोर के बीच एक व्यापार है।

मॉड्यूल को पहले क्यों न लिखें, क्योंकि वे फ़ंक्शन के पूर्ण नाम का हिस्सा हैं? शायद रंग के साथ यह केवल Core.eval आदि लिखने के लिए पर्याप्त स्पष्ट हो सकता है, या उन्हें अभी भी कॉलम के रूप में गठबंधन किया जा सकता है। (या शायद आपने यह कोशिश की और यह भयानक लग रहा था।)

वास्तव में पागल विचार: यदि तर्क प्रकारों को प्रिंट करने में एक से अधिक पंक्तियाँ लगेंगी, तो हस्ताक्षर को मुड़े हुए रूप में प्रिंट करें और फिर दर्शकों को इसका विस्तार करने की अनुमति देने के लिए REPL.TerminalMenus का उपयोग करें। कुछ इस तरह:

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

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

संबंधित: #35915 (जिसे मैं एक फोल्ड-ट्री मेनू बनाने के लिए उपयोग करने की योजना बना रहा हूं, https://github.com/JuliaCollections/FoldingTrees.jl)।

इस क्रम में पुनर्व्यवस्थित कोडपथ के साथ यह कैसा दिखता है: LineNumber Filename Path
फिर आपकी आंखों के पास लाइन नंबर और फ़ाइल नाम देखने के लिए एक स्थिर स्थान है, जिसके लिए उनके लिए कोई अतिरिक्त रंग की आवश्यकता नहीं है (मुझे लगता है कि मैं हमेशा विवरण में दफन फ़ाइल नाम और लाइन नंबर की खोज कर रहा हूं, क्या आप बता सकते हैं?)
और इंटरैक्टिव आरईपीएल काम के लिए मुझे ऊपर दिए गए विचार से प्यार है :)

पहले मॉड्यूल क्यों न लिखें, क्योंकि वे फ़ंक्शन के पूरे नाम का हिस्सा हैं

हाँ, मुझे यह विचार पसंद है, मुझे लगता है कि मैंने बिना रंग के शुरुआत की और यह इतना अच्छा काम नहीं किया, लेकिन इस तरह यह वास्तव में काफी पठनीय है। मैं अगले कॉलम के बिना कोशिश करूंगा, हालांकि कॉलम हमेशा अच्छे होते हैं क्योंकि वे आपकी आंखों का मार्गदर्शन करते हैं।

इसके बारे में निश्चित नहीं है; फ़ंक्शन का नाम मॉड्यूल की तुलना में बहुत अधिक महत्वपूर्ण जानकारी है। मेरे लिए कम से कम, सबसे महत्वपूर्ण जानकारी निश्चित रूप से फ़ंक्शन का नाम, फ़ाइल का नाम और लाइन नंबर है। इसके अलावा स्क्रिप्ट के लिए बायां कॉलम बहुत सारे Main या खाली होगा, जो उस उपयोग के मामले के लिए आदर्श नहीं है।

मुझे लगता है कि जब मैं स्टैकट्रेस पढ़ रहा हूं, तो मैं बेस/पैकेज कोड पर जाने से पहले अपने कोड में आखिरी कॉल की तलाश में हूं, क्योंकि आमतौर पर बग मेरे कोड में होता है। तो उस स्थिति में मॉड्यूल बहुत महत्वपूर्ण है और फ़ंक्शन कॉल वह नहीं है जिसे मैं पहले स्कैन कर रहा हूं।

इस बारे में कैसा है:

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

मॉड्यूल नाम अभी भी पंक्तिबद्ध होंगे ताकि उन्हें स्कैन करना आसान हो।

मैंने वास्तव में उसके करीब कुछ करने की कोशिश की थी। मैंने इस बार फ़ंक्शन नामों को स्वयं रंग दिया है, इसलिए वे अभी भी सबसे प्रमुख हैं लेकिन मॉड्यूल जानकारी को अपने रंग में रखते हैं। तो वहाँ अभी भी एक स्पष्ट समूह है, लेकिन सभी मॉड्यूल नामों पर कम ध्यान देने के साथ।

पहली बार मैंने देखा कि मैं शायद यह जानने की कोशिश कर रहा हूं कि रंगों का क्या मतलब है: खुशी: यदि प्रति-मॉड्यूल रंग होने जा रहे हैं, तो मॉड्यूल नाम पर रंग लागू करना बेहतर लगता है।

मुझे मॉड्यूल के नाम पसंद हैं, वे इस नवीनतम तस्वीर में थोड़े खो गए हैं।

यदि वे नीचे हैं, तो शायद उन्हें एक ही चमकीले रंग बनाने से चीजें जुड़ जाएंगी? (और स्पष्ट करें कि आप मॉड्यूल की सीमा को कहां पार करते हैं।) और, शायद, यदि मॉड्यूल का नाम पथ में दिखाई देता है, तो इसके बजाय इसे केवल वहां हाइलाइट किया जा सकता है - यह रंगीन नाम को बाएं किनारे से भी हटा देगा जहां फ़ंक्शन हैं।

कुछ प्रेरणा के लिए, मैं पिछली बार से कुछ छवियों को पोस्ट करता हूं जब स्टैकट्रेस स्वरूपण आया था।

अक्सर सटीक पैकेज कोड की प्रकृति के रूप में इतनी रुचि नहीं रखता है: क्या यह कोर जूलिया है, एक पुस्तकालय जिसका मैं उपयोग कर रहा हूं, जिस पुस्तकालय को मैं विकसित कर रहा हूं, या एक स्क्रिप्ट? हमारे पास चार रंग हो सकते हैं: कोर/बेस/देव/स्टडलिब, पैकेज, पैकेज वर्तमान में ]dev एड, और बाकी सभी (स्क्रिप्ट/आरईपीएल सहित)। इनमें से कुछ भेद बहुत मनमाना हैं और वर्गीकरण थोड़ा भंगुर है, लेकिन इस पर आधारित विधि को रंगना (कम से कम मेरे लिए) बिना किसी अतिरिक्त पाठ को प्रदर्शित किए और छोटे, याद रखने में आसान रंगों के सेट को अधिकतम बनाए रखना होगा।

मेरे लिए, रंग सीमा परिवर्तन के बारे में अधिक हैं, जहां एक मॉड्यूल से कोड शुरू होता है और दूसरा समाप्त होता है। इसलिए मैं शायद उन्हें अंतर्निहित अर्थ नहीं बताऊंगा। दूसरी ओर, यह भ्रमित करने वाला हो सकता है।

मैंने और अधिक सरल बनाने की कोशिश की है, और कॉलम को फिर से हटा दिया है क्योंकि मॉड्यूल कॉलम के बिना वे अब इतने उपयोगी नहीं हैं। फिर पहले मैंने मॉड्यूल द्वारा केवल लाइन नंबर को रंग दिया, लेकिन इसने अभी भी फ़ाइल नाम को इतना दृश्यमान नहीं छोड़ा, जो कि कई टिप्पणियों ने कहा कि महत्वपूर्ण है। इसलिए मैंने उसे मॉड्यूल रंग में भी रंग दिया। मॉड्यूल नाम स्वयं रंगीन नहीं है क्योंकि यह फ़ंक्शन नाम के बहुत करीब है और यह बहुत शोर है।

यहाँ संख्या और फ़ाइल नाम दोनों रंग के साथ संस्करण है:

यहाँ फ़ाइल नाम के बिना रंगीन

क्या आप पूर्ण फ़ाइल पथ को रंगने का भी प्रयास कर सकते हैं?

कुछ विचार...
फ़ाइल नाम और लाइन नंबर एक सुसंगत स्थान में डबल रिक्त स्थान के साथ उन्हें सेट करने के लिए।
स्टैक स्तर का रंग और मॉड्यूल रंग एक दूसरे से संबंधित लाइनों को नेत्रहीन रूप से जोड़ने के लिए मेल खाते हैं।
फ़ाइल नाम, लाइन नंबर, और पथ बिना किसी अव्यवस्था के भेद करने के लिए पैरामीटर प्रकारों की तुलना में थोड़े अलग रंग में।

[इस उदाहरण में रंग मनमाने हैं, इस बारे में अधिक सोच रहे हैं कि उनकी स्थिति कैसे संबंधित है।
उदाहरण में गुम स्टैक स्तर और अंतिम आइटम पर छोटा पैरामीटर प्रकार सूची इसलिए है क्योंकि मैंने हाथ से उदाहरण टाइप किया है।]

यदि कोई इसके साथ खेलना चाहता है तो उपरोक्त नमूना तैयार करने के लिए कोड का उपयोग किया जाता है:

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

इसके साथ समस्या यह है कि यह एटम / वीएससीओडी, आदि में क्लिक करने योग्य लिंक नहीं छोड़ता है। यह कुछ ऐसा है जिसका मैं अक्सर उपयोग करता हूं और मेरा मानना ​​​​है कि अन्य भी ऐसा करते हैं। वास्तव में, मैं उन्हें क्लिक करने योग्य बनाने के लिए आधार पथों को स्पष्ट रूप से विस्तारित करता हूं। यह निश्चित रूप से अधिक प्रिंट करता है। लेकिन मुझे लगता है कि यह उपयोगिता को बढ़ाता है। मुझे पता है कि कुछ शॉर्टकट के साथ आरईपीएल में नंबर द्वारा ट्रेस प्रविष्टियों को स्टैक करने के लिए कूदने का कोई तरीका है, लेकिन यह मेरी राय में एक लिंक पर क्लिक करने से कहीं कम सहज ज्ञान युक्त है।

लॉगिंग सिस्टम के साथ लाइन जानकारी मुद्रित करने के तरीके को एकीकृत करने का अवसर लेना समझ में आता है, उदाहरण के लिए:

साथ ही, ध्यान दें कि लॉगिंग सिस्टम होमडायर को अनुबंधित करता है

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

मुझे लगता है कि यहां प्रस्ताव में दो मुख्य विचार हैं:

• लाइन की जानकारी हस्ताक्षर से अलग लाइन पर रखें (और शायद इसे कुछ रंगों से सीमांकित करें ताकि इसे ढूंढना आसान हो सके)।
• मॉड्यूल दिखाएं।

तो यहाँ उन दोनों विचारों के साथ थोड़ा अधिक रूढ़िवादी प्रयास है:

चर नामों के साथ एक संस्करण जोड़ा गया है, और केवल मॉड्यूल नामों पर रंग (लेकिन अन्यथा मिलान कैसे @info पथ प्रिंट करता है):

इसमें बहुत लंबे प्रकार के हस्ताक्षर नहीं हैं, लेकिन शायद इस तरह के चर नाम होने (यदि यह संभव है?) प्रत्येक तर्क के सबसे बाहरी प्रकार को खोजना आसान बना देगा।

यदि तटस्थ के तीन स्तर उपलब्ध हैं (जैसे बोल्ड/सामान्य/ग्रे), तो हस्ताक्षर की तुलना में फ़ाइल पथ को अधिक हल्के ढंग से प्रिंट करना (आईएमओ) चीजों को एक साथ चलने से रोकने के लिए एक अच्छा तरीका है। (यह वही है जो @info करता है।)

 होने देना
 प्रिंटस्टाइल ("\ n जूलिया>", रंग =: हरा)
 प्रिंट्लन ("एफ ()")
 प्रिंटस्टाइल ("" "त्रुटि: आयाम मिस्मैच ("ए के आयाम (1,2) हैं लेकिन बी के आयाम (3,4)") हैं """, रंग =: light_red)
 println ("\ n स्टैकट्रेस:")
 गणना (त्रुटियों) में (idx, err) के लिए
 एमसी = आईडीएक्स <= 3? :नीला : (idx >= 7 ? :नीला : :पीला) # मॉड्यूल रंग
 प्रिंटस्टाइल ("[$ (गलती [1])] ", रंग =: सामान्य, बोल्ड = सत्य) # त्रुटि
 प्रिंटस्टाइल (गलती [2], रंग =: सामान्य, बोल्ड = सत्य) # फ़ंक्शन
 प्रिंटस्टाइल ("(", रंग =: सामान्य) # परम प्रकार
 के लिए (i, t) गणना में (गलती [3])
 मैं != 1 && प्रिंटस्टाइल ("", ", रंग =: सामान्य)
 प्रिंटस्टाइल (रैंड ('ए': 'जेड') ^ 2, रंग =: लाइट_ब्लैक)
 प्रिंटस्टाइल ("::", रंग =: सामान्य)
 प्रिंटस्टाइल ("$ टी", रंग =: सामान्य)
 समाप्त
 प्रिंटस्टाइल (")", रंग =: सामान्य)
 प्रिंट्लन ()
 प्रिंटस्टाइल ("@", रंग =: लाइट_ब्लैक)
 प्रिंटस्टाइल (गलती [6], रंग = एमसी) # मॉड्यूल
 प्रिंटस्टाइल ("$ (गलती [7]) / $ (गलती [5]): $ (गलती [4])", रंग =: लाइट_ब्लैक) # पथ
 प्रिंट्लन ()
 समाप्त
 समाप्त

मुझे लगता है कि यहां प्रस्ताव में दो मुख्य विचार हैं:

* 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। यह एक ऐसा विषय है जो बाइकशेड के लिए बहुत मजेदार है और हर किसी के पास पेंट की एक बाल्टी है, हे। जैसा कि आप देख सकते हैं, कि पीआर भी काफी महत्वाकांक्षी रूप से शुरू हुआ लेकिन धीरे-धीरे अधिक से अधिक रूढ़िवादी हो गया।

मेरे लिए, अंतिम प्रस्ताव निश्चित रूप से यथास्थिति में सुधार है। दो बातें मैं सोच रहा हूँ:

• यदि संभव हो, तो लाइन की जानकारी के लिए आपकी आंखों के लिए किसी प्रकार का "हुक" रखना अच्छा होगा क्योंकि जब हस्ताक्षर लंबा होता है तो यह हस्ताक्षर के साथ मिल जाता है।
• हमें शायद स्टैकफ्रेम संख्याओं को संरेखित करना चाहिए जब उनमें से 10 से अधिक हों:
  [ 8] [ 9] [10] [11]
  आदि। इससे @ भी लाइन अप हो जाएगा।

मुझे यह पसंद है, मुझे लगता है कि हम कहीं जा रहे हैं। रंगों के साथ विवेकपूर्ण होना हमेशा अच्छा होता है, क्योंकि इससे बाइक शेडिंग के लिए कम सतह क्षेत्र का खुलासा होता है, साथ ही यह जोखिम कम हो जाता है कि किसी के टर्मिनल पर रंग अपठनीय होगा।

चीजों को अलग करना अच्छा है, लेकिन दुर्भाग्य से वाक्यविन्यास f (...) स्पष्ट रूप से अस्वीकृत है, इसलिए मुझे लगता है कि हमें या तो स्थान को हटाने या माता-पिता को हटाने की आवश्यकता है।

सबसे हालिया नमूना आम तौर पर अच्छा दिखता है, लेकिन मैं इस विचार को दूसरा मानता हूं:

यदि संभव हो, तो लाइन की जानकारी के लिए आपकी आंखों के लिए किसी प्रकार का "हुक" रखना अच्छा होगा क्योंकि जब हस्ताक्षर लंबा होता है तो यह हस्ताक्षर के साथ मिल जाता है।

और मुझे आशा है कि हुक एक अलग रंग या (अधिमानतः) चमक है।

हो सकता है कि आप मॉड्यूल के लिए रंगों का चक्र कर सकें, लेकिन इसे केवल स्टैक स्तर संख्या के दोनों ओर [ ] पर लागू करें ताकि यदि आप किसी कारण से रंग नहीं देख पा रहे हैं तो बहुत अधिक नुकसान नहीं हुआ है।

हो सकता है कि आप मॉड्यूल के लिए रंगों का चक्र कर सकें लेकिन इसे केवल [] पर लागू करें

रंग को सही ढंग से देखना भी मुश्किल है अगर यह केवल ब्रैकेट है और वे एक विपरीत क्षेत्र में हैं, इसलिए मुझे नहीं लगता कि यह बहुत अच्छा काम करता है ..

वाक्य रचना f (...) स्पष्ट रूप से अस्वीकृत है

मुझे लगता है कि कंट्रास्ट अंतर के कारण, यह स्थान के बिना भी अच्छी तरह से काम करता है।

हो सके तो लाइन की जानकारी के लिए आपकी आंखों के लिए किसी तरह का "हुक" लगाना अच्छा रहेगा

मैं सहमत हूं, मुझे लगता है कि यह लाइन नंबरों को ग्रे छोड़ने के लिए अच्छी तरह से काम करता है, लेकिन उन्हें बोल्ड करता है, जो उन्हें थोड़ा सा मुख्य बनाता है यदि आप उन्हें ढूंढते हैं लेकिन उन्हें सफेद बनाने का अगला चरण मेरी राय में बहुत शोर है।

हमें शायद स्टैकफ्रेम नंबरों को संरेखित करना चाहिए

मैंने इसे आपके उदाहरण की तरह ब्रैकेट के अंदर रिक्त स्थान के साथ करने की कोशिश की लेकिन पाया कि यह थोड़ा अजीब लग रहा था, इसलिए अब मैं ब्रैकेट वाली संख्याओं को सही तरीके से संरेखित कर रहा हूं। मुझे लगता है कि यह काफी अच्छा काम करता है।

यहां उन सभी विचारों के साथ नवीनतम संस्करण शामिल है:

और एक बोनस के रूप में, यहां बताया गया है कि यह (यादृच्छिक) चर नामों के साथ कैसा दिख सकता है। फिर से मैं केवल बोल्ड ग्रे का उपयोग कर रहा हूं क्योंकि इन सभी चर नामों को आपके ध्यान के लिए संघर्ष नहीं करना चाहिए, लेकिन यदि आप उन्हें ढूंढते हैं तो थोड़ा सा ध्यान देने योग्य होना चाहिए

मुझे यह भी पसंद है कि यह कहाँ जा रहा है। मैं मॉड्यूल नाम की किसी प्रकार की हाइलाइटिंग के लिए सिर्फ वोट देना चाहता हूं। मैं वास्तव में उस शैली को काफी पसंद करता हूं जहां एक ही मॉड्यूल एक ही तरह से रंगीन होता है और यह रंगों के माध्यम से चक्र करता है (यहां एक ग्राफ रंग समस्या है यदि आप दो स्टैक ट्रेस लाइनों को उनके मॉड्यूल के बीच ग्राफ़ एज के रूप में आसन्न मानते हैं)। हालांकि, दुर्भाग्य से, यह स्पष्ट नहीं है कि उस रंग का क्या अर्थ है। शायद सभी मॉड्यूल नामों को एक ही रंग में रंगना?

यह संरेखण मुझे अच्छा लगता है।

मुझे अब भी लगता है कि हस्ताक्षर से अधिक स्पष्ट रूप से अलग पथ होने से चीजों को तोड़ने में मदद मिलेगी - महत्व के 3 स्तर, नाम/हस्ताक्षर/पथ। मैक्रो लॉगिंग @info आदि। उन्हें अन्य पंक्तियों की तुलना में हल्का प्रिंट करें।

परिवर्तनीय नाम रखना बेहद अच्छा होगा। क्या वोट देंगे कि वे हस्ताक्षर की जानकारी से कम महत्वपूर्ण हैं, शायद?

मॉड्यूल नाम बाईं ओर पंक्तिबद्ध होने से आपको उन्हें स्कैन करने में मदद मिलती है, हालांकि रंगों को जाते हुए देखकर मुझे दुख होता है।

मेरी आंखों को यह पता लग रहा है कि इस पर चीजें कहां मिलें :)
क्या मॉड्यूल के बीच एक रिक्त रेखा बहुत अधिक लंबवत स्थान का उपयोग करेगी?

पंक्तियों को 2 अलग-अलग रंगों से रंगना ताकि वैकल्पिक पंक्तियों का रंग समान हो - जैसा कि अक्सर तालिकाओं में किया जाता है, पठनीयता में मदद कर सकता है।

मॉड्यूल नाम के बजाय मॉड्यूल नाम के आगे @ रंग साइकल चलाना हाइलाइट किए गए फ़ंक्शन नाम के साथ बहुत अधिक प्रतिस्पर्धा किए बिना (क्योंकि @ एक बहुत बड़ा वर्ण है) बाहर खड़ा है।

मैंने अक्सर पैरामीटर नामों की कामना की है क्योंकि वे आपको उनके माध्यम से गिनने के बिना सही पैरामीटर प्रकार खोजने में मदद करते हैं।

क्या पथ (और शायद इसके आगे मॉड्यूल का नाम) प्रकारों से भिन्न चमक हो सकता है? शायद सिर्फ पैरामीटर नामों से मेल खाते हैं? (या सभी कम रोशनी वाले एक साथ यदि आप मैकबॉट के नामों को प्रकारों की तुलना में मंद बनाने का सुझाव देते हैं)

आप स्पष्ट रूप से मिरर कर सकते हैं कि लॉगिंग क्या उपयोग करती है, हालांकि आदर्श रूप से विभिन्न रंगों के साथ:

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

संपादित करें: अब एक लंबी लाइन के साथ जो लपेटती है, और एक तस्वीर:

आप स्पष्ट रूप से क्या लॉगिंग का उपयोग करता है दर्पण सकता है

जो चीज मुझे इसके बारे में इतनी पसंद नहीं है वह यह है कि लाइन ब्रेक जो केवल विशिष्ट आरईपीएल चौड़ाई के कारण होते हैं यदि आप अपनी विंडो/आरईपीएल का आकार बदलते हैं (यदि आप उदाहरण के लिए लंबी लाइनों के लिए जगह बनाना चाहते हैं तो अच्छी तरह से स्थानांतरित नहीं होते हैं) ) या टेक्स्ट को अलग-अलग चौड़ाई की विंडो में कॉपी/पेस्ट करें

हां, मैं मार्करों को निरंतर बनाने के लिए स्पष्ट रूप से लाइनों को तोड़ने का प्रस्ताव नहीं दूंगा। वास्तव में यह एक अच्छी बात हो सकती है कि लिपटी हुई रेखाओं को टूटने दें, और इसलिए अलग दिखें। मुख्य रूप से इस बात पर विचार किया जाता है कि रंग को फ़ंक्शन के नाम से कैसे बाँधा जाए, और इसे सबसे महत्वपूर्ण शीर्षक की तरह दिखने के बजाय सीमा का हिस्सा होने पर इसे शायद कम बाधा कैसे बनाया जाए।

मुझे कहना होगा कि मुझे रंग पसंद आया लेकिन मैं इसके साथ रूढ़िवादी होने की प्राथमिकता को समझ सकता हूं।

हालांकि, मैं अपने समर्थन को कुछ इस तरह फेंकना चाहता हूं

अक्सर सटीक पैकेज कोड की प्रकृति के रूप में इतनी रुचि नहीं रखता है: क्या यह कोर जूलिया है, एक पुस्तकालय जिसका मैं उपयोग कर रहा हूं, जिस पुस्तकालय को मैं विकसित कर रहा हूं, या एक स्क्रिप्ट? हमारे पास चार रंग हो सकते हैं: कोर/बेस/देव/स्टडलिब, पैकेज, पैकेज वर्तमान में ]dev एड, और बाकी सभी (स्क्रिप्ट/आरईपीएल सहित)। [...]

चूंकि मैं आधार पर हैकिंग नहीं कर रहा हूं और शायद ही कभी पैकेज पर (जैसा कि ज्यादातर लोग करते हैं, मुझे लगता है), मेरी स्क्रिप्ट में 90% त्रुटियों को ठीक करने की आवश्यकता है, पैकेज में 9% और आधार में 1%। अगर मैंने किसी फ़ंक्शन को कॉल करने में गलती की है, तो मुझे यहां बिल्कुल जानने की आवश्यकता नहीं है क्योंकि त्रुटि को फेंक दिया गया था क्योंकि मैं इसे ठीक करने के लिए वहां नहीं जा रहा हूं, मुझे अपना कोड ठीक करने की आवश्यकता है।

तो मैं यह देखने के लिए कुछ दृश्य सहायक की सराहना करता हूं कि मैं अपना कोड कहां छोड़ रहा हूं (और शायद जहां मैं पैकेज कोड छोड़ रहा हूं, आधार में जा रहा हूं) क्योंकि ज्यादातर मामलों में उसके बाद कुछ भी मैं सुरक्षित रूप से अभी के लिए अनदेखा कर सकता हूं। यदि रंग के माध्यम से नहीं, शायद -------------------------------------------- या कुछ और के साथ? उनमें से केवल 2-3 ही होने चाहिए।

यदि मॉड्यूल रंगीन हो जाते हैं, तो शायद बेस/कोर को छोड़ दिया जाना चाहिए और कोई रंग नहीं दिया जाना चाहिए।

मुझे वास्तव में वह शैली पसंद है जहां एक ही मॉड्यूल को उसी तरह से रंगा जाता है और यह रंगों के माध्यम से चक्र करता है

मैं इसके साथ भी ठीक हूं। यदि हम कई रंगों का उपयोग करने जा रहे हैं, तो मुझे लगता है कि इसके लिए उनका उपयोग किया जाना चाहिए। यह बहुत अधिक ऊर्ध्वाधर स्थान लिए बिना उपयोगकर्ता और पैकेज कोड के बीच की सीमाओं को चुनने में भी मदद करता है।

यदि मॉड्यूल रंगीन हो जाते हैं, तो शायद बेस/कोर को छोड़ दिया जाना चाहिए और कोई रंग नहीं दिया जाना चाहिए।

हां, बेस और कोर हमेशा गहरे भूरे या कुछ और हो सकते हैं, बाकी सभी के लिए और रंग छोड़कर :)

यदि यह 16 रंगों में पूरी तरह से काम करना छोड़ देता है, तो उन्हें मॉड्यूल नामों का हैश बनाना अच्छा हो सकता है, ताकि आप उनमें से कुछ को याद कर सकें।

या केवल दो रंग हैं, एक बेस/कोर के लिए और एक बाहरी मॉड्यूल के लिए?

मुझे लगता है कि रंगों को साइकिल करने में कोई समस्या नहीं होनी चाहिए क्योंकि मेरे वर्तमान संस्करण में 6 गैर-ग्रेस्केल विकल्प हैं:

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

मुझे लगता है कि हल्के रूप भी हैं, लेकिन वीएससीओडी (सामग्री) में मेरी रंग योजना ने उन्हें गहरे भाई बहनों के समान ही सेट किया है, इसलिए मुझे लगता है कि कुछ योजनाओं में ऐसा हो सकता है। लेकिन यह कितनी संभावना है कि एक स्टैक ट्रेस 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

आंख के लिए यह पकड़ना आसान हो सकता है कि फ़ंक्शन तर्क कहाँ से शुरू होते हैं और अधिक स्थान बर्बाद न करते हुए फ़ंक्शन कॉल की श्रृंखला को पार्स करने में सहायता प्रदान करते हैं। इसे अभी भी रंगों द्वारा समर्थित होने की आवश्यकता है, अन्यथा स्थान infos और तर्क सब कुछ डूब जाएगा।

तो उन्हें मॉड्यूल नामों का हैश बनाना अच्छा हो सकता है, ताकि आप उनमें से कुछ को याद कर सकें

यह वास्तव में एक तरह का शानदार है।

ओह, हेलो डार्किश टील, मेरे पुराने दोस्त...

तो उन्हें मॉड्यूल नामों का हैश बनाना अच्छा हो सकता है, ताकि आप उनमें से कुछ को याद कर सकें

मैं Emacs IRC उपनामों के लिए ठीक वैसा ही करता था। यह इतनी अच्छी तरह से काम नहीं कर सका क्योंकि मेरे कुछ दोस्तों को एक ही रंग दिया गया था और यह किसी भी चीज़ से ज्यादा भ्रमित करने वाला था, इसलिए मैंने अपने दोस्तों के लिए हार्ड-कोडिंग रंगों को समाप्त कर दिया। मैं उस मार्ग से नीचे जाने की अनुशंसा नहीं करता, हालांकि यह अच्छा लगता है। प्रत्येक कोड प्रकार (जैसे जूलिया, पैकेज, डेड पैकेज, उपयोगकर्ता) के लिए रंगों का कम सेट होना अधिक उपयोगी लगता है।

मैं एक संपादक रंग योजना पर उतरा जो ऐसा करता है, और यह मामूली रूप से उपयोगी है - सभी चर जो अन्यथा नीले हो सकते हैं, हरे और नीले रंग के विभिन्न रंग हैं, स्ट्रिंग्स और कीवर्ड इत्यादि के साथ अलग हैं। शायद आदर्श कुछ इस तरह के व्यापक वर्गों के भीतर होगा जैसे आप सुझाव देते हैं (उदाहरण के लिए लाल-बैंगनी में मानक पुस्तकालय, हरे-नीले रंग में डाउनलोड किया गया, नारंगी-पीले रंग में देव-एड, भूरे रंग में आधार)। या शायद यह बहुत अधिक काम है!

एक और पुनरावृत्ति: मैंने वहां परिवर्तनीय नाम प्राप्त करने का प्रयास किया, भले ही यह सब मेरे लिए सुपर हैकी लगता है क्योंकि मैं सभी आंतरिक से बहुत परिचित नहीं हूं। मैंने मॉड्यूल को फिर से रंग दिया क्योंकि ऐसा लग रहा था कि इसे सामान्य रूप से सकारात्मक प्रतिक्रिया मिल रही है, भले ही यह बहस का विषय है कि रंगों को कैसे सौंपा जाना चाहिए। लेकिन रंगों के साथ, मुझे लगता है कि एक प्रविष्टि का मॉड्यूल अगले के फ़ंक्शन नाम के साथ थोड़ा सा टकराता है। इसलिए मैंने लाइन ब्रेक की शुरुआत की। सब कुछ निश्चित रूप से लंबा बनाता है, लेकिन मुझे अतिरिक्त श्वास कक्ष और स्पष्टता पसंद है

मुझे आपका अंतिम नमूना पसंद है, यह बहुत स्पष्ट और पठनीय है :)

फ़ंक्शन नाम के साथ आपके द्वारा उल्लिखित टकराव को कम करने के लिए मॉड्यूल नाम के बजाय मॉड्यूल रंग को "@" पर लागू करने का एक प्रयोग नीचे दिया गया है, और प्रकारों को हाइलाइट करने का प्रयास कर रहा है ताकि पथ को रिक्त परिचय के बिना थोड़ा आसान पहचाना जा सके लाइनें।

@jkrumbiegel यह सुंदर है। मुझे अपने जीवन में इसकी जरूरत है।

मुझे वो सॉफ्ट ब्लूज़ पसंद हैं

@jkrumbiegel ग्रेट, मुझे यकीन नहीं है कि @ प्रतीक की आवश्यकता है, यह इसके बिना क्लीनर दिख सकता है। यदि आप यह बताना चाहते हैं कि वह जानकारी क्या है, तो आप इसे वैसे ही लिख सकते हैं जैसे जेफ ने सुझाव दिया था:
in MakieLayout at ~/.julia/packages/MakieLayout/COfBu/src/lineaxis.jl:372

@jkrumbiegel यह बहुत अच्छा लग रहा है! क्या केवल फ़ाइल नाम (पूर्ण पथ नहीं) और लाइन नंबर को हाइलाइट करने का कोई तरीका है? शायद थोड़ा चमकीला ग्रे?

सुंदर! मैं वास्तव में लाइन ब्रेक को वास्तव में पसंद करता हूं-वे वास्तव में दृष्टि से मदद करते हैं और हमारे स्टैक निशान इतने लंबे होते हैं कि मुझे वैसे भी स्क्रॉल करना पड़ता है, मैं स्क्रॉलिंग को थोड़ा सा कम करने के बजाय स्पष्ट होना चाहता हूं।

हाइलाइट किए गए :: शानदार हैं। अगर मुझे चरित्र की स्थिति के खिलाफ पैरामीटर सूची के प्रत्येक चरित्र की सूचना सामग्री दिखाते हुए एक वक्र प्लॉट करना होगा, तो :: उस वक्र के स्थानीय मैक्सिमा को बिल्कुल चिह्नित करता है। मुझे पता है कि नाम के लिए उनमें से बाईं ओर और प्रकार के सबसे महत्वपूर्ण भाग के लिए दाईं ओर देखना है, उसके बाद सूचना सामग्री केवल गिरती है।

मैं इस टिप्पणी से असहमत हूं: हाइलाइटिंग को महत्वपूर्ण चीजों पर जोर देना चाहिए ताकि आंख को पता चले कि क्या पढ़ना है, और निश्चित रूप से एक महत्वपूर्ण चीज नहीं है जिसे मुझे पढ़ना चाहिए। जैसा कि यह खड़ा है सफेद बोल्ड गहरे नीले रंग की तुलना में बहुत अधिक ध्यान देने योग्य है। मापदंडों को भेद करना केवल सफेद रंग में तर्क नाम होने से स्पष्ट होगा (शायद अपवाद के साथ जब कोई नामित तर्क नहीं है, इस मामले में :: तर्कों को सीमित करने के लिए सफेद रंग में भी हो सकता है)। वही लाइन नंबर के लिए जाता है, मैं लाइन नंबर की तुलना में फ़ाइल नाम पर जोर देना चाहता हूं।

रंगीन पैकेज नाम सबसे महत्वपूर्ण चीज़, फ़ंक्शन नाम को ओवरशैड करने का जोखिम चलाते हैं, लेकिन बोल्ड और लाइनब्रेक के साथ होने से वास्तव में उस जोखिम को सीमित कर दिया जाता है, अच्छा किया!

मैंने उन्हें सफेद करने से बहुत पहले :: के बारे में सोचा था। बेशक तर्क नाम और प्रकार वास्तविक जानकारी हैं, इसलिए आप सोच सकते हैं कि उन्हें हाइलाइट किया जाना चाहिए। लेकिन उन्हें हाइलाइट करते समय मेरा मजबूत प्रभाव यह है कि वे आपका ध्यान आकर्षित करते हैं। लेकिन हर नाम और प्रकार को पढ़ना महत्वपूर्ण नहीं है। आपको बस उन लोगों को ढूंढने में सक्षम होना चाहिए जिन्हें आप किसी विशिष्ट फ़ंक्शन में ढूंढ रहे हैं। मैं स्टैक ट्रेस पढ़ने के चरणों को कैसे देखता हूं:

1. एक सामान्य अवलोकन प्राप्त करें
2. किस मॉड्यूल में कौन सा फ़ंक्शन त्रुटिपूर्ण है?
3. इस फ़ंक्शन को अन्य कौन से फ़ंक्शन कहते हैं जिससे अन्य मॉड्यूल?
4. क्या मेरे अपने कोड और आधार या अन्य पैकेज कोड के बीच कोई महत्वपूर्ण सीमा है? कहाँ है?
5. उस सीमा पर क्या कार्य है?
6. किस प्रकार/तर्कों का प्रयोग किया गया? एक तर्क कहाँ समाप्त होता है और दूसरा कहाँ शुरू होता है? यह अभी लंबे पैरामीट्रिक प्रकारों के साथ विशेष रूप से कठिन है।
7. क्या यह त्रुटि की व्याख्या करता है?
8. अगर यह मदद नहीं करता है, तो एक अच्छी कंघी के साथ सब कुछ देखें

तो मेरी राय में प्रकार/तर्क की जानकारी सामान्य संरचना को समझने और समझने के बाद ही उपयोग की जाती है। हाइलाइटिंग के बारे में समझने वाली एक बात यह है कि यह जरूरी नहीं कि चीजों को ढूंढना आसान बनाता है, केवल तभी जब हाइलाइट अपेक्षाकृत विरल हों। तो मुझे लगता है कि :: हाइलाइट रास्ते में नहीं आता है और जब तक आप परिवर्तनीय/प्रकार की जानकारी की तलाश शुरू नहीं करते तब तक आपका ध्यान आकर्षित करें। और उस कदम पर यह आपकी आंखों को कूदने के लिए हुक देता है, कुछ ज्यादा नहीं, कुछ कम नहीं। मुझे यह काफी कुशल लगता है।

एक साइड नोट के रूप में, प्रत्येक तर्क का एक नाम नहीं होता है, इसलिए चर नामों को हाइलाइट करने से आपको हमेशा अच्छा अलगाव नहीं मिलेगा। मुझे लगता है कि :: हमेशा होता है।

यह एक अच्छी सूची की तरह लगता है, मेरी मुख्य शिकायत बिंदु 6 है, लंबे प्रकार के हस्ताक्षरों में अंतराल ढूंढना। प्रिंटिंग :: सुपर-ब्राइट मदद करता है, हालांकि मैं मानता हूं कि यह थोड़ा अजीब है। तर्क नामों को प्रिंट करना (या शायद कुछ _1 प्लेसहोल्डर यदि कोई नहीं) थोड़ी मदद करेगा। शायद सबसे बाहरी प्रकार को सामान्य रूप से प्रिंट करना, और फिर ग्रे में इसके सभी तर्क, बहुत मदद करेंगे?

हाइलाइटिंग के कितने स्तर वास्तव में उपलब्ध हैं? :white हल्की पृष्ठभूमि पर अलग नहीं होगा, वास्तव में मुझे लगता है कि हम सामान्य, बोल्ड और :light_black (प्लस रंग) तक सीमित हो सकते हैं। अभी फ़ंक्शन का नाम और पथ बोल्ड हैं। @error आदि में, पथ light_black है, जो बहुत अच्छा लगता है।

मुझे मॉड्यूल को हाइलाइट करने के लिए रंग का उपयोग पसंद है। ऊपर के कुछ नमूनों में यह दूसरे पाठ से बेहतर है, लेकिन क्या यह साधारण रंगों के लिए सही है? कुछ अलग विषयों में, "मॉड्यूल" यहां अपेक्षाकृत मौन है (और ::Array, ::Adjoint, ::Int स्पष्ट रूप से शीर्ष-स्तरीय हस्ताक्षर):

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

एक और पुनरावृत्ति: मैंने वहां परिवर्तनीय नाम प्राप्त करने का प्रयास किया, भले ही यह सब मेरे लिए सुपर हैकी लगता है क्योंकि मैं सभी आंतरिक से बहुत परिचित नहीं हूं। मैंने मॉड्यूल को फिर से रंग दिया क्योंकि ऐसा लग रहा था कि इसे सामान्य रूप से सकारात्मक प्रतिक्रिया मिल रही है, भले ही यह बहस का विषय है कि रंगों को कैसे सौंपा जाना चाहिए। लेकिन रंगों के साथ, मुझे लगता है कि एक प्रविष्टि का मॉड्यूल अगले के फ़ंक्शन नाम के साथ थोड़ा सा टकराता है। इसलिए मैंने लाइन ब्रेक की शुरुआत की। सब कुछ निश्चित रूप से लंबा बनाता है, लेकिन मुझे अतिरिक्त श्वास कक्ष और स्पष्टता पसंद है

थोड़ा विषय से हटकर हो सकता है लेकिन चूंकि हमारे पास यह है, क्या हमारे पास methods और methodswith के आउटपुट के लिए एक सुंदर show methodswith ? यह भी एक दर्द है।

इसके अलावा, मॉड्यूल का रंग मंद रंग हो सकता है, जैसे कि बिल्कुल पीला नहीं, बल्कि ग्रे-पीला। या, क्या हमारे पास वे रंग विन्यास योग्य हो सकते हैं, जैसे startup.jl ?

@jkrumbiegel यह बहुत अच्छा लग रहा है! क्या केवल फ़ाइल नाम (पूर्ण पथ नहीं) और लाइन नंबर को हाइलाइट करने का कोई तरीका है? शायद थोड़ा चमकीला ग्रे?

यह हो सकता है: https://github.com/JuliaLang/julia/issues/36026#issuecomment -634481656। लेकिन यह मेरे लिए थोड़ा अजीब है क्योंकि फ़ाइल का नाम पथ का हिस्सा है तो यह एक अलग रंग का उपयोग क्यों करता है? आमतौर पर, मैं बस पथ पर क्लिक करता हूं, और VSCode इसे मेरे लिए खोल देगा, इसलिए इससे कोई फर्क नहीं पड़ता कि फ़ाइल का नाम क्या है।

मैं Crayon.jl का उपयोग करने से दूर हो गया हूं, अब जबकि मैं वास्तव में अब जटिल रंगों का उपयोग नहीं करता हूं। पैकेज के लोड समय के साथ भी मदद करता है। मुझे फ़ाइल नाम और लाइन नंबर की दृश्यता को बढ़ाने का एक तरीका मिला, बिना इसे गहरे भूरे रंग में रेखांकित करके नेत्रहीन रूप से भारी बना दिया गया। यह समझदार भी लगता है, क्योंकि हम रास्तों / लिंक को रेखांकित करने के अभ्यस्त हैं। सफेद या अन्य हाइलाइटिंग वहां बहुत मजबूत थी, बोल्ड भी कमजोर।

इसके अलावा, मैंने साइक्लर में पहले रंगों के रूप में हल्के रंगों पर स्विच किया है, जो मुझे पहले स्थान पर करना चाहिए था, लेकिन वे मेरी थीम में समान दिखते हैं इसलिए मैंने कभी ध्यान नहीं दिया। यह उन विषयों के लिए बेहतर होना चाहिए जहां गहरा नीला शायद ही दिखाई दे (हालांकि यह विषय की गलती है)।

मैंने इस शैली को ClearStacktrace.jl में संस्करण 0.2 के रूप में पंजीकृत किया है ताकि हम इसे थोड़ा और आज़मा सकें।

दो उदाहरण:

यह वास्तव में अच्छा काम है।
आपके पास पैरामीटर नाम हल्का और प्रकार गहरा है। क्या यह लाइटर और नाम गहरे रंग के प्रकारों की तुलना में बेहतर दिखने/बेहतर तरीके से पढ़ने के लिए निकला?

हां, चूंकि प्रकार आमतौर पर अधिक लंबे होते हैं, यह उन्हें हल्का बनाने में ज्यादा मदद नहीं करता है।

एकाएक विचार:

• शायद एक ही मॉड्यूल में स्टैक ट्रेस प्रविष्टियों के समूहों के बीच क्षैतिज नियम? शायद देखने में बहुत व्यस्त
• स्टैक ट्रेस के शीर्ष पर भी अच्छा हो सकता है, इसे त्रुटि संदेश से स्पष्ट रूप से अलग करने के लिए

ये सब हमारे पास अभी जो है, उससे कहीं बेहतर हैं...

मैं Crayon.jl का उपयोग करने से दूर हो गया हूं, अब जबकि मैं वास्तव में अब जटिल रंगों का उपयोग नहीं करता हूं। पैकेज के लोड समय के साथ भी मदद करता है।

क्या यह एक महत्वपूर्ण लोड समय का कारण बना? यह मेरे लिए अपने आप बहुत जल्दी लोड हो जाता है

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

यह संस्करण बहुत अच्छा है, आइए इसे बेस में डालते हैं।

सहमत: चलो बस उस अंतिम संस्करण को करते हैं।

यहां सारा काम करने के लिए धन्यवाद, @jkrumbiegel । एक संस्करण के लिए बढ़िया है जिसे हम आजमा सकते हैं ...

और कांटा: मुझे लगता है कि मुझे लगता है कि यह थोड़ा सा संबंधित है कि rand(5) .* rand(7) प्लस त्रुटि 35 लाइनों पर है? इसलिए मैंने कोशिश करने के लिए https://github.com/mcabbott/ClearStacktrace.jl/tree/milder बनाया। (प्लस रंग मुद्दे आदि ऊपर चर्चा की गई।) यह लगभग https://github.com/JuliaLang/julia/issues/36026#issuecomment -635294818 अधिक रंगों के साथ है।

उस उदाहरण में वर्तमान स्टैकट्रेस प्रिंटिंग फ्रेम 8-11 में नोट नहीं दिखाए गए हैं (वे आरईपीएल का हिस्सा हैं और प्रत्येक आरईपीएल स्टैकट्रेस में होंगे)।

वास्तव में, इसमें सुधार हुआ है जो बहुत अच्छा है। लेकिन यह अभी भी 8 लाइनों (अकेले स्टैक ट्रेस के लिए) से 20 (ClearStacktrace 0.2) तक जाता है। यह कितना सुंदर है और अपनी जगह नहीं खो रहा है, इसके बीच थोड़ा सा समझौता है।

पथ भी बेस में और अधिक दृढ़तापूर्वक मुद्रित कर रहे हैं ./broadcast.jl:495 के बजाय //Applications/Julia-1.5.app/Contents/Resources/julia/bin/../share/julia/base/broadcast.jl:495 , यह भी खाली लाइनों के लिए की जरूरत कम होगी।

आधार पथों को क्लिक करने योग्य बनाने के उद्देश्य से उनका विस्तार किया गया है। आप इसे ClearStacktrace में अक्षम कर सकते हैं। मैं उन लोगों के लिए न्यूलाइन्स को वैकल्पिक भी बना सकता था जो उन्हें पसंद नहीं करते। सिर्फ एक पर्यावरण चर हो सकता है।

और मुझे लगता है कि मैंने फ़ंक्शन के उस हिस्से को कॉपी करने से चूक गया होगा जो पिछले कुछ फ़्रेमों को क्लिप करता है जो कभी नहीं बदलते हैं

मैं Crayon.jl का उपयोग करने से दूर हो गया हूं, अब जबकि मैं वास्तव में अब जटिल रंगों का उपयोग नहीं करता हूं। पैकेज के लोड समय के साथ भी मदद करता है। मुझे फ़ाइल नाम और लाइन नंबर की दृश्यता को बढ़ाने का एक तरीका मिला, बिना इसे गहरे भूरे रंग में रेखांकित करके नेत्रहीन रूप से भारी बना दिया गया। यह समझदार भी लगता है, क्योंकि हम रास्तों / लिंक को रेखांकित करने के अभ्यस्त हैं। सफेद या अन्य हाइलाइटिंग वहां बहुत मजबूत थी, बोल्ड भी कमजोर।

इसके अलावा, मैंने साइक्लर में पहले रंगों के रूप में हल्के रंगों पर स्विच किया है, जो मुझे पहले स्थान पर करना चाहिए था, लेकिन वे मेरी थीम में समान दिखते हैं इसलिए मैंने कभी ध्यान नहीं दिया। यह उन विषयों के लिए बेहतर होना चाहिए जहां गहरा नीला शायद ही दिखाई दे (हालांकि यह विषय की गलती है)।

मैंने इस शैली को ClearStacktrace.jl में संस्करण 0.2 के रूप में पंजीकृत किया है ताकि हम इसे थोड़ा और आज़मा सकें।

दो उदाहरण:

इस बारे में उत्सुक हैं कि / में अतिरिक्त //Applications/Julia-1.4.app/ क्यों है?

पथ को विभाजित करने और फिर से जुड़ने से शायद एक बग

मैं Crayon.jl का उपयोग करने से दूर हो गया हूं, अब जबकि मैं वास्तव में अब जटिल रंगों का उपयोग नहीं करता हूं। पैकेज के लोड समय के साथ भी मदद करता है।

क्या यह एक महत्वपूर्ण लोड समय का कारण बना? यह मेरे लिए अपने आप बहुत जल्दी लोड हो जाता है

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

  0.014410 seconds (22.60 k allocations: 2.274 MiB)

नहीं, मैंने ज्यादातर इसे हटा दिया क्योंकि मेरे पास यह आधार में नहीं होगा :) लोड समय सिर्फ एक अनुमान था

मुझे लगता है कि यदि हमारे पास https://github.com/JuliaLang/julia/issues/36026#issuecomment -636912686 में दिखाए गए स्टैकट्रेस के कई फ्रेम हैं तो बहुत अधिक रिक्त रेखाएं हो सकती हैं?

चर्चा को पटरी से उतारने के लिए नहीं (अंतिम संस्करण बहुत अच्छा और एक बड़ा सुधार है) लेकिन बहुत सारी नई पंक्तियों के विषय पर, समस्या यह है कि टर्मिनल पर काम करते समय स्टैकट्रेस "उलटा" (जैसा कि) प्रिंट करना मेरे लिए बहुत बेहतर लगता है मैंने मूल रूप से https://github.com/JuliaLang/julia/pull/18228 में प्रस्तावित किया था:

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

सबसे महत्वपूर्ण जानकारी स्वयं त्रुटि संदेश और स्टैक के शीर्ष की ओर फ़्रेम (त्रुटि के करीब) और इसे इस क्रम में प्रिंट करना है जो हमेशा स्क्रॉल किए बिना दिखाई देगा। अभी मुझे अक्सर त्रुटि संदेश देखने के लिए स्क्रॉल करना पड़ता है, न कि केवल एक स्टैकट्रेस की पूंछ।

हालांकि, टर्मिनल से कॉपी-पेस्ट की गई वेबसाइट पर एक स्टैकट्रेस पढ़ते समय आप विपरीत क्रम चाहते हैं क्योंकि आप टर्मिनल में करते समय नीचे से ऊपर के विपरीत ऊपर से नीचे स्क्रॉल करते हैं ... इन दोनों मामलों के लिए अच्छा डिजाइन।

हालांकि, टर्मिनल से कॉपी-पेस्ट की गई वेबसाइट पर एक स्टैकट्रेस पढ़ते समय आप विपरीत क्रम चाहते हैं क्योंकि आप टर्मिनल में करते समय नीचे से ऊपर के विपरीत ऊपर से नीचे स्क्रॉल करते हैं ... इन दोनों मामलों के लिए अच्छा डिजाइन।

मेरे पास वास्तव में एक पल के लिए ClearStacktrace.jl में कोड था जिसने मुझे अंतिम स्टैकट्रैक को पुनर्मुद्रण करने की अनुमति दी। मैंने कल्पना की थी कि सुपर लॉन्ग टाइप्स को अधिकतम कुछ कैरेक्टर पर काटने के लिए और पूरी जानकारी की आवश्यकता होने पर पूरी तरह से पुनर्मुद्रण करने में सक्षम होने के लिए। लेकिन आपका उपयोग मामला भी दिलचस्प होगा। मैं एक reprint(inverted = true) या यहां तक ​​कि reprint(html = true) कल्पना कर सकता हूं जहां यह एक HTML संस्करण प्रिंट करेगा जो एक वेबसाइट में चिपकाने के लिए रंग बनाए रखेगा।

साथ ही, मैं मानता हूं कि स्क्रॉलिंग दिशा को देखते हुए डिफ़ॉल्ट रूप से पूरी चीज को उलटना समझ में आता है।

ipython फ्रेम को विपरीत क्रम में प्रिंट करता है, और स्क्रॉल न करने के बावजूद मैंने हमेशा इसे बेवजह भ्रमित करने वाला पाया है। शायद यह सिर्फ जीडीबी और अन्य प्रणालियों के साथ मेरे पूर्व अनुभव के कारण है जहां अंतरतम फ्रेम शीर्ष पर है, या शायद अन्य लोग भी ऐसा ही महसूस करते हैं?

जीडीबी की बात करें तो, उनके पास अपने पेजर के साथ बहुत लंबे निशान का उचित समाधान है: "अधिक फ्रेम के लिए एंटर दबाएं"।

वैसे, मैं https://github.com/JuliaLang/julia/issues/36026#issuecomment -636912686 में नवीनतम विज़ुअल डिज़ाइन प्राप्त करता हूं और अगर हम इसे मर्ज करते हैं तो मुझे बेहद खुशी होगी। फ़्रेम क्रम बदलना या इंटरैक्टिव सुविधाएँ जोड़ना अलग-अलग मुद्दों की तरह लगता है।

फ़ाइल नामों के संबंध में, मुझे आशा है कि हम अंततः टर्मिनल हाइपरलिंक OSC अनुक्रमों का उपयोग कर सकते हैं ( हाँ टर्मिनलों में हाइपरलिंक कुछ हद तक व्यापक रूप से समर्थित हैं! ) और उपयोगकर्ता के संपादक के लिए इसे लेने का एक तरीका है।

"अंतरतम फ्रेम" खोजने की बात करते हुए, मैं अपने काम के दौरान पर्याप्त भाषाओं का उपयोग करता हूं कि मुझे कभी याद नहीं आता कि मुझे किसी विशेष भाषा में अपने कोड के लिए स्टैकट्रैक के ऊपर या नीचे देखना चाहिए। इसलिए मैं फ़ाइल नाम को देखकर स्कैन करना समाप्त कर देता हूं जब तक कि मैं एक को नहीं देखता जिसे मैं पहचानता हूं। यहां दिखाया गया रेखांकन मदद करेगा, इसलिए यह एक स्पष्ट सुधार है। लेकिन मुझे अभी भी आश्चर्य है कि अगर मुझे ऊपर या नीचे देखना चाहिए तो कॉल करने का कोई अच्छा तरीका है या नहीं। सिद्धांत रूप में एक छोर पर YOUR CODE HERE और दूसरे छोर पर OTHER CODE HERE को प्रिंट करने से मुझे मदद मिलेगी, लेकिन यह बहुत ही सुरुचिपूर्ण नहीं लगता है।

मैंने यहां आधार के लिए एक पीआर बनाया है https://github.com/JuliaLang/julia/pull/36134
जहाँ तक मैं बता सकता हूँ यह काम करता है, लेकिन इसे विलय के लिए तैयार करने के लिए मुझे कुछ मदद की आवश्यकता होगी

क्या टाइप पैरामीटर को छोड़ने का कोई तरीका है? समस्या जो हम अक्सर देखते हैं वह यह है कि डिफईक, फॉरवर्डडिफ इत्यादि में टाइप पैरामीटर की मात्रा चीजों को कठिन बना सकती है। यदि डिफ़ॉल्ट रूप से यह सिर्फ Dual , तो उस मामले को छोड़कर जहां टाइप पैरामीटर के कारण अन्य तरीकों से प्रेषण होता है, तो मुझे लगता है कि आप मेरे द्वारा पढ़े गए अधिकांश स्टैक ट्रेस में शोर का 90% कम कर देंगे (और में अन्य मामलों में, @timholy का सुझाव वास्तव में आवश्यक है, क्योंकि यह आमतौर पर प्रकार या मिलान प्रकार पैरामीटर बनाने के बारे में है)

अगर वे किसी मौजूदा प्रकार के उपनाम से मेल खाते हैं, तो वे अभी अपने आप चले जाएंगे (#36107)। अन्यथा, वे संभावित संकलन प्रदर्शन बाधाओं को इंगित करते हैं-तो संभवतः जांच के लायक हैं?

यह अब किया जाता है।

कुछ लोगों के लिए, लेकिन ज्यादातर लोग भ्रमित हो जाते हैं जब यह एक प्रकार का प्रिंट आउट लेता है जो मुद्रित पेपर के 3 पृष्ठ लेता है, तो शायद यह कुछ ऐसा होना चाहिए जो ऑप्ट-इन हो। मैं उस पर चर्चा करने के लिए एक और मुद्दा खोलूंगा।

https://github.com/JuliaLang/julia/issues/36517 . में जारी