Julia: ما المطلوب لتضمين ClearStacktrace.jl في Base؟

سيكون من الرائع حقا الحصول عليها. أو على الأقل ربما نسخة مقلصة تعمل على تحسين طباعة أسطر التكديس افتراضيًا في 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}}

تعليق صغير ، لكن بالنسبة لي ، ربما يكون لون "سلطة" أكثر من اللازم حاليًا. عداد إطار المكدس باللون الأزرق ، وجميع الألوان المختلفة في التوقيع وما إلى ذلك. بالنسبة للألوان الأساسية حتى الآن ، استخدمنا فقط ألوان النظام الستة عشر (8 + 8 ألوان ساطعة) وهذا يجعل التلوين الفاخر أصعب قليلاً.

اقتراحات جيدة بشكل عام. ربما يعلق زوجان على سبب إجراء اختيارات الألوان حتى الآن:

الأرقام زرقاء لأنها مهمة ، لذا لا ينبغي أن تكون رمادية اللون ، ولكن اجعلها بيضاء محسوسة بالنسبة لي كما لو كانوا يقاتلون من أجل الاهتمام بأسماء الوظائف.

تستخدم الوحدات الألوان الأساسية في دورة ، وأعتقد أن هذا مفيد جدًا لأنه يسمح بتصفية التتبع بسرعة للوحدات ذات الصلة. هذا شيء له علاقة كبيرة بتنسيق تتبع المكدس الحالي. الفكرة هي أنه يجب إجبار الناس على القراءة بأقل قدر ممكن للعثور على ما يبحثون عنه. (لقد أجريت أبحاثًا حول حركة العين والاهتمام في حياتي الأكاديمية حتى الآن ، لذا فهذه الجوانب مهمة بالنسبة لي ؛))

ألوان التوقيعات قابلة للنقاش للغاية. تم اختيار تلك الموجودة في لقطة الشاشة أعلاه لتكون مختلفة قليلاً فقط عن اللون الرمادي الداكن. في نفس الوقت ، أردت أن تكون المكونات الدلالية المختلفة قابلة للتمييز. هذا هو السبب في أن جميع الأنواع ومعلمات الكتابة (الأقواس المتعرجة والفواصل) تتسبب في تبديل اللون. هناك ثلاثة ألوان مما يعني أنه لن يكون هناك جيران بنفس اللون. لقد وجدت أنه من الصعب جدًا تكوين كلمات مفردة بتوقيعات كتابة ضخمة إذا كانت جميعها بيضاء فقط. تساعد الظلال المختلفة قليلاً كثيرًا ولكنها تجعل كل شيء أكثر صخبًا بصريًا.

نظرًا لأن مجموعة الألوان المكونة من 16 لونًا لا تحتوي على ألوان تختلف اختلافًا طفيفًا عن الرمادي الداكن ، فمن المحتمل ألا يكون شيئًا يمكن تضمينه في Base. في تحديث حديث ، استبدلت الألوان بثلاثة ألوان مختلفة قليلاً من الرمادي من مجموعة ANSI ، لكن حتى ذلك لن يتم دعمه في كل مكان أعتقد.

أوه أيضًا لون إطار المكدس وألوان الوحدة بالإضافة إلى الرمادي الداكن والأبيض كلها ألوان النظام. إنه فقط موضوع VSCode الخاص بي الذي يجعلهم كما تراه هنا.

سيكون من الرائع الحصول على هذا.

عند فحص أنواع الوسائط ، غالبًا ما يكون من الصعب جدًا معرفة المكان الذي يتوقف فيه المرء ويبدأ بعد ذلك. قد يكون تلوين المستوى الأعلى بشكل مختلف مفيدًا جدًا هنا ، وربما حتى ترقيم الحجج:

 [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
ثم يكون لعينيك موقع ثابت للبحث عن رقم السطر واسم الملف دون الحاجة إلى لون إضافي لهما (يبدو أنني أبحث دائمًا عن اسم الملف ورقم السطر المدفون في التفاصيل ، هل يمكنك معرفة ذلك؟)
ولعمل REPL التفاعلي ، أحب الفكرة المطوية أعلاه :)

لماذا لا تكتب الوحدات أولاً ، لأنها جزء من الاسم الكامل للوظيفة

نعم ، لقد أحببت الفكرة نوعًا ما ، أعتقد أنني بدأت بدون ألوان ولم ينجح ذلك بشكل جيد ، لكن مثل هذا في الواقع يمكن قراءته تمامًا. سأحاول بدون أعمدة بعد ذلك ، على الرغم من أن الأعمدة لطيفة دائمًا لأنها توجه عينيك.

لست متاكد حيال ذلك؛ اسم الوظيفة هو معلومة أكثر أهمية بكثير من الوحدة النمطية. بالنسبة لي على الأقل ، فإن أهم المعلومات هي بالتأكيد اسم الوظيفة واسم الملف ورقم السطر. أيضًا بالنسبة للنصوص ، سيكون العمود الأيسر عددًا كبيرًا من Main أو فارغًا ، وهو ليس مثاليًا لحالة الاستخدام هذه.

أعتقد أنه عندما أقرأ stacktraces ، فأنا أبحث في الغالب عن آخر مكالمة في الكود الخاص بي قبل أن ينتقل إلى رمز Base / Package ، نظرًا لأن الخطأ موجود عادةً في الكود الخاص بي. لذا في هذه الحالة ، تكون الوحدة مهمة جدًا ولن يكون استدعاء الوظيفة هو ما أقوم بمسحه ضوئيًا أولاً.

وماذا عن هذا:

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

ستظل أسماء الوحدات مصطفة بحيث يكون من السهل مسحها ضوئيًا.

لقد جربت للتو شيئًا قريبًا من ذلك. لقد قمت بتلوين أسماء الوظائف بأنفسهم هذه المرة ، لذا فهي لا تزال الأكثر بروزًا ولكنها تحمل معلومات الوحدة بألوانها. لذلك لا يزال هناك تجميع واضح ، ولكن مع تركيز أقل على جميع أسماء الوحدات.

في المرة الأولى التي رأيت فيها أنني ربما أذهب إلى المكسرات في محاولة لمعرفة ما تعنيه الألوان: الفرح: إذا كانت هناك ألوان لكل وحدة ، يبدو من الأفضل تطبيق اللون على اسم الوحدة.

تعجبني أسماء الوحدات ، فقد ضاعت قليلاً في هذه الصورة الأخيرة.

إذا كانوا في الأسفل ، فربما جعلهم نفس اللون الزاهي من شأنه أن يربط الأشياء؟ (وضح المكان الذي تعبر فيه حدود الوحدة.) وربما ، إذا ظهر اسم الوحدة في المسار ، فيمكن ببساطة تمييزه هناك بدلاً من ذلك - وهذا من شأنه أيضًا تحريك الاسم الملون بعيدًا عن الحافة اليسرى حيث توجد الوظائف.

للحصول على بعض الإلهام ، قمت بنشر بعض الصور من المرة الأخيرة التي تم فيها التغيير والتبديل في تنسيق تتبع المكدس.

غالبًا ما لا تكون الحزمة الدقيقة ذات أهمية كبيرة مثل طبيعة الكود: هل هي جوليا الأساسية ، أم مكتبة أستخدمها ، أم المكتبة التي أقوم بتطويرها ، أم برنامج نصي؟ يمكن أن يكون لدينا أربعة ألوان: 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 مع بعض الاختصارات ، لكن هذا أقل بديهية من مجرد النقر على رابط في رأيي.

قد يكون من المنطقي اغتنام الفرصة لتوحيد طريقة طباعة معلومات الخط مع نظام التسجيل ، على سبيل المثال:

لاحظ أيضًا أن نظام التسجيل يتعاقد مع homedir

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

أعتقد أن هناك فكرتين أساسيتين في الاقتراح هنا:

• احصل على معلومات الخط في سطر منفصل عن التوقيع (وربما حددها ببعض الألوان لتسهيل العثور عليها).
• اعرض الوحدة.

إذن فهذه محاولة أكثر تحفظًا مع هاتين الفكرتين:

إصدار يحتوي على أسماء متغيرات مضافة ، ولونًا فقط على أسماء الوحدات (ولكن يتطابق بطريقة أخرى مع كيفية طباعة المسارات @info ):

هذا لا يحتوي على توقيعات كتابة طويلة جدًا ، ولكن ربما وجود أسماء متغيرة مثل هذه (إذا كان ذلك ممكنًا؟) سيجعل من السهل تحديد النوع الخارجي لكل وسيطة.

إذا كان هناك ثلاثة مستويات محايدة متاحة (مثل غامق / عادي / رمادي) ، فإن طباعة مسار الملف بشكل خفيف أكثر مما يبدو التوقيع (IMO) كطريقة جيدة لمنع الأشياء من العمل معًا. (هذا أيضًا ما يفعله @info .)

 يترك
 printstyled ("\ njulia>" ، اللون =: أخضر)
 println ("f ()")
 printstyled ("" "خطأ: DimensionMismatch (" A لها أبعاد (1،2) لكن B لها أبعاد (3،4) ")" "" ، اللون =: light_red)
 println ("\ nStacktrace:")
 لـ (معرف ، يخطئ) في تعداد (أخطاء)
 mc = idx <= 3؟ : أزرق: (idx> = 7؟: blue:: yellow) # لون الوحدة
 printstyled ("[$ (err [1])]" ، اللون =: عادي ، غامق = صحيح) # errorno
 printstyled (err [2] ، اللون =: عادي ، غامق = صحيح) # وظيفة
 printstyled ("("، color =: normal) # من أنواع المعلمات
 لـ (i، t) في التعداد (يخطئ [3])
 i! = 1 && printstyled ("،"، color =: normal)
 printstyled (rand ('a': 'z') ^ 2 ، color =: light_black)
 printstyled ("::" ، اللون =: عادي)
 printstyled ("$ t" ، اللون =: عادي)
 نهاية
 printstyled (")" ، اللون =: عادي)
 println ()
 printstyled ("@"، color =: light_black)
 printstyled (Err [6] ، color = mc) # module
 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. هذا موضوع ممتع للغاية لركوب الدراجات ولكل شخص دلو من الطلاء ، هيه. كما ترون ، بدأ هذا العلاقات العامة أيضًا بطموح كبير ولكن ببطء أصبح أكثر وأكثر تحفظًا.

بالنسبة لي ، فإن الاقتراح الأخير هو بالتأكيد تحسين على الوضع الراهن. شيئان أفكر فيهما:

• إذا كان ذلك ممكنًا ، سيكون من الجيد أن يكون لديك نوع من "الخطاف" لعينيك للحصول على معلومات الخط لأنها تميل إلى الاندماج مع التوقيع عندما يكون التوقيع طويلاً.
• ربما ينبغي علينا محاذاة أرقام الإطارات المكدسة عندما يكون هناك أكثر من 10 منهم:
  [ 8] [ 9] [10] [11]
  الخ. هذا من شأنه أن يجعل @ مصطفًا أيضًا.

يعجبني ذلك ، أعتقد أننا نصل إلى مكان ما. أن تكون حكيمًا مع الألوان أمرًا جيدًا دائمًا ، لأن ذلك يعرض مساحة أقل لتساقط الدراجات ، بالإضافة إلى أنه يقلل من خطر أن يكون اللون غير قابل للقراءة على طرف شخص ما.

يعد تباعد الأشياء أمرًا جيدًا ، ولكن لسوء الحظ ، فإن بناء الجملة f (...) غير مسموح به صراحة ، لذلك أعتقد أننا بحاجة إما إلى إزالة المساحة أو إزالة الأقواس.

تبدو أحدث عينة بشكل عام جيدة ، لكنني أؤيد الفكرة:

إذا كان ذلك ممكنًا ، سيكون من الجيد أن يكون لديك نوع من "الخطاف" لعينيك للحصول على معلومات الخط لأنها تميل إلى الاندماج مع التوقيع عندما يكون التوقيع طويلاً.

وآمل أن يكون الخطاف بلون مختلف أو (يفضل) سطوع.

ربما يمكنك القيام بدورة الألوان للوحدات النمطية ولكن فقط قم بتطبيقها على [] على جانبي رقم مستوى المكدس ، لذلك إذا لم تتمكن من رؤية الألوان لسبب ما ، فلن تفقد الكثير.

ربما يمكنك القيام بدورة الألوان للوحدات النمطية ولكن يمكنك تطبيقها فقط على []

من الصعب حتى رؤية اللون بشكل صحيح إذا كان بين قوسين فقط وكانا في منطقة متباينة ، لذلك لا أعتقد أن هذا يعمل بشكل جيد ..

بناء الجملة f (...) غير مسموح به صراحة

أعتقد أنه يعمل بشكل جيد حتى بدون المساحة ، بسبب اختلاف التباين.

إذا كان ذلك ممكنًا ، سيكون من الجيد أن يكون لديك نوع من "الخطاف" لعينيك للحصول على معلومات الخط

أوافق ، أعتقد أنه من الجيد ترك أرقام الأسطر رمادية ولكن جريئة ، وهذا يجعلها بارزة قليلاً إذا بحثت عنها ولكن الخطوة التالية لجعلها بيضاء هي طريقة صاخبة للغاية في رأيي.

ربما ينبغي علينا محاذاة أرقام الإطار المكدس

لقد جربتها بمسافات داخل الأقواس كما في المثال الخاص بك ولكن وجدت أن ذلك بدا غريبًا بعض الشيء ، لذلك أنا الآن على حق في محاذاة الأرقام الموجودة بين قوسين. أعتقد أن هذا يعمل بشكل جيد.

إليك أحدث إصدار مع دمج كل تلك الأفكار:

وكمكافأة ، إليك كيف يمكن أن تبدو بأسماء المتغيرات (العشوائية). مرة أخرى ، أنا أستخدم اللون الرمادي الغامق فقط لأن كل هذه الأسماء المتغيرة لا يجب أن تكافح من أجل جذب انتباهك ، ولكن يجب تمييزها قليلاً إذا بحثت عنها

أنا أحب إلى أين يذهب هذا أيضًا. أريد فقط أن أجري تصويتًا على نوع من إبراز اسم الوحدة. أنا في الواقع أحب تمامًا النمط الذي يتم فيه تلوين نفس الوحدة بنفس الطريقة وهي تتنقل عبر الألوان (هناك مشكلة في لون الرسم البياني هنا إذا كنت تفكر في وجود خطي تتبع مكدس متجاورين كحافة رسم بياني بين وحداتهما). ومع ذلك ، فمن غير الواضح تمامًا ما يعنيه هذا اللون. ربما تلوين جميع أسماء الوحدات بلون واحد؟

هذه المحاذاة تبدو جيدة بالنسبة لي.

ما زلت أعتقد أن وجود مسارات مميزة بشكل أكثر وضوحًا عن التواقيع من شأنه أن يساعد في تقسيم الأمور - 3 مستويات من الأهمية ، الاسم / التوقيع / المسار. تسجيل وحدات الماكرو @info وما إلى ذلك ، اطبعها بدرجة أعلى من الخطوط الأخرى.

سيكون من الرائع للغاية وجود أسماء متغيرة. هل ستصوت بأنها أقل أهمية من معلومات التوقيع ، على الأرجح؟

يساعدك وجود أسماء الوحدات المصطفة على اليسار في مسحها ضوئيًا ، على الرغم من أنني حزين لرؤية الألوان تتلاشى.

يبدو أن عيني تعرف أين أجد الأشياء في هذا :)
هل سيستخدم السطر الفارغ بين الوحدات مساحة عمودية كبيرة جدًا؟

يمكن أن يساعد تلوين الصفوف بلونين مختلفين بحيث يكون للصفوف البديلة نفس اللون - كما يحدث غالبًا في الجداول ، في تسهيل القراءة.

يبرز استخدام اللون @ بجوار اسم الوحدة بدلاً من اسم الوحدة نفسها (لأن @ حرف كبير جدًا) دون التنافس مع اسم الوظيفة المميز كثيرًا.

لطالما كنت أرغب في الحصول على أسماء المعلمات لأنها تساعدك في العثور على نوع المعلمة الصحيح دون الحاجة إلى الاعتماد عليها.

هل يمكن أن يكون المسار (وربما اسم الوحدة بجواره) مختلفًا عن سطوع الأنواع؟ ربما مجرد مطابقة أسماء المعلمات؟ (أو جميعها ذات إضاءة منخفضة معًا إذا فعلت اقتراح mcabbott بجعل الأسماء باهتة أكثر من الأنواع)

يمكنك عكس ما يستخدمه التسجيل بشكل صريح ، على الرغم من أنه من الأفضل استخدام ألوان مختلفة:

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 (إذا كنت تريد إفساح المجال لخطوط أطول على سبيل المثال ) أو نسخ / لصق النص في نوافذ بعرض مختلف

نعم ، لن أقترح صراحة كسر الخطوط لجعل العلامات مستمرة. في الواقع ، قد يكون من الجيد السماح للخطوط الملفوفة بالاختراق ، وبالتالي تبدو مختلفة. في الغالب فكرة حول كيفية ربط اللون باسم الوظيفة ، وكيفية جعله أقل اقتحامًا ، إذا كان جزءًا من الحد بدلاً من أن يبدو العنوان الأكثر أهمية.

يجب أن أقول إنني أحب اللون ولكن يمكنني أن أفهم تفضيل أن أكون متحفظًا معه.

ومع ذلك ، أريد أن أرمي دعمي وراء شيء مثل

غالبًا ما لا تكون الحزمة الدقيقة ذات أهمية كبيرة مثل طبيعة الكود: هل هي جوليا الأساسية ، أم مكتبة أستخدمها ، أم المكتبة التي أقوم بتطويرها ، أم برنامج نصي؟ يمكن أن يكون لدينا أربعة ألوان: core / base / dev / stdlib ، والحزم ، والحزم حاليًا ]dev ed ، وجميع الألوان الباقية (بما في ذلك script / REPL). [...]

نظرًا لأنني لا أقوم بالقرصنة على أساس الحزم ونادرًا ما أقوم بالقرصنة (كما يفعل معظم الأشخاص ، أفترض) ، يجب إصلاح 90٪ من الأخطاء في البرنامج النصي الخاص بي ، و 9٪ في الحزمة و 1٪ في القاعدة. إذا ارتكبت خطأ في استدعاء وظيفة ، فأنا لست بحاجة إلى معرفتها هنا بالضبط في الأساس ، فقد تم إلقاء الخطأ لأنني لن أذهب إلى هناك لإصلاحه على أي حال ، فأنا بحاجة إلى إصلاح الكود الخاص بي.

لذلك سأقدر بعض المساعد المرئي لمعرفة أين سأترك الكود الخاص بي (وربما أيضًا أين سأترك كود الحزمة ، وأذهب إلى القاعدة) لأنه في معظم الحالات يمكنني تجاهل أي شيء بعد ذلك بأمان في الوقت الحالي. إذا لم يكن عن طريق اللون ، فربما مع -------------------------------------------- أو شيء من هذا القبيل؟ يجب أن يكون هناك فقط 2-3 من هؤلاء.

إذا تم تلوين الوحدات ، فربما يجب ترك القاعدة / الأساسية وعدم إعطائها لونًا.

أنا في الواقع أحب تمامًا النمط الذي يتم فيه تلوين نفس الوحدة بنفس الطريقة وتتنقل عبر الألوان

أنا بخير مع ذلك أيضًا. إذا كنا سنستخدم العديد من الألوان ، أعتقد أنه يجب استخدامها لذلك. كما أنه يساعد في تحديد الحدود بين المستخدم ورمز الحزمة دون شغل مساحة رأسية كبيرة.

إذا تم تلوين الوحدات ، فربما يجب ترك القاعدة / الأساسية وعدم إعطائها لونًا.

نعم ، يمكن أن يكون Base and Core دائمًا رمادي غامق أو شيء من هذا القبيل ، مما يترك المزيد من الألوان للجميع :)

إذا توقف هذا عن العمل بشكل مثالي في 16 لونًا ، فقد يكون من الجيد جعلها تجزئة لأسماء الوحدات ، بحيث يمكنك حفظ بعضها.

أو هل لديك لونان فقط ، أحدهما للقاعدة / الأساسية والآخر للوحدات الخارجية؟

أعتقد أنه لا ينبغي أن تكون هناك مشكلة كبيرة في تدوير الألوان لأن إصداري الحالي يحتوي على 6 خيارات غير تدرج الرمادي:

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

أعتقد أن هناك متغيرات ضوئية أيضًا ، لكن مخطط الألوان الخاص بي في VSCode (المواد) جعلهم يضبطون مثل الأشقاء الأكثر قتامة ، لذلك أفترض أن هذا يمكن أن يحدث في بعض المخططات. ولكن ما مدى احتمالية أن يمر تتبع المكدس بأكثر من 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. إذا لم يساعدك ذلك ، فقم بتفقد كل شيء بمشط جيد

لذا فإن معلومات النوع / الحجة في رأيي تستخدم فقط بعد توجيه وفهم الهيكل العام. هناك شيء واحد يجب فهمه حول التمييز وهو أنه لا يسهل بالضرورة العثور على الأشياء ، فقط إذا كانت النقاط البارزة متفرقة نسبيًا. لذلك أعتقد أن :: الإبراز لا يعيق الطريق ويجذب انتباهك حتى تبدأ في البحث عن معلومات متغيرة / من النوع. وفي هذه الخطوة ، تمنح عينيك خطافات للقفز إليها ، لا أكثر ولا أقل. أجد أن ذلك فعال للغاية.

كملاحظة جانبية ، ليس لكل وسيطة اسم ، لذا فإن تمييز أسماء المتغيرات لن يمنحك دائمًا فصلًا جيدًا. أعتقد أن :: هناك دائمًا.

تبدو هذه قائمة جيدة ، شكواي الرئيسية هي النقطة 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

تكرار آخر: حاولت الحصول على أسماء متغيرة هناك ، على الرغم من أن الأمر كله يبدو مخادعًا للغاية بالنسبة لي لأنني لست على دراية كبيرة بجميع العناصر الداخلية. لقد أعدت تلوين الوحدات لأنها بدت وكأنها تحصل على استجابة إيجابية بشكل عام ، على الرغم من أن كيفية تخصيص الألوان أمر قابل للنقاش. ولكن مع الألوان ، أشعر أن وحدة الإدخال تتعارض قليلاً مع اسم الوظيفة التالي. لذلك قدمت فواصل الأسطر. يجعل كل شيء أطول بالطبع ، لكني أحب غرفة التنفس الإضافية والوضوح

قد يكون بعيدًا عن الموضوع قليلاً ولكن نظرًا لأن لدينا هذا ، هل يمكننا الحصول على 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) بالإضافة إلى احتلال 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/ ؟

ربما خطأ من الانقسام والعودة إلى المسار

لقد ابتعدت عن استخدام 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

أهم المعلومات هي رسالة الخطأ نفسها والإطارات باتجاه الجزء العلوي من المكدس (أقرب إلى الخطأ) وطباعتها بهذا الترتيب الذي سيكون دائمًا مرئيًا دون التمرير. في الوقت الحالي ، يتعين علي التمرير لأعلى بشكل متكرر حتى لأرى رسالة الخطأ وليس فقط ذيل تتبع المكدس.

ومع ذلك ، عند قراءة Stacktrace على موقع ويب تم نسخه ولصقه من الجهاز ، فأنت تريد الترتيب المعاكس لأنك تقوم بالتمرير من أعلى إلى أسفل بدلاً من أسفل إلى أعلى كما تفعل في محطة ... تصميم جيد لكلتا الحالتين.

ومع ذلك ، عند قراءة Stacktrace على موقع ويب تم نسخه ولصقه من الجهاز ، فأنت تريد الترتيب المعاكس لأنك تقوم بالتمرير من أعلى إلى أسفل بدلاً من أسفل إلى أعلى كما تفعل في محطة ... تصميم جيد لكلتا الحالتين.

لقد كان لدي بالفعل رمز في 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 على الطرف الآخر ، لكنها لا تبدو أنيقة للغاية.

لقد قمت بعمل علاقات عامة للقاعدة هنا https://github.com/JuliaLang/julia/pull/36134
إنه يعمل بقدر ما أستطيع أن أقول ، لكنني سأحتاج إلى بعض المساعدة لجعله جاهزًا للدمج

هل هناك طريقة لحذف معلمات النوع؟ المشكلة التي نراها في كثير من الأحيان هي أن مقدار معلمات النوع في DiffEq و ForwardDiff وما إلى ذلك يمكن أن يجعل الأشياء ... شاقة. إذا كانت تقول بشكل افتراضي Dual ، إلا في حالة وجود إرسال إلى طرق أخرى بسبب معلمات النوع ، فأعتقد أنك ستقلل 90٪ من الضوضاء في معظم آثار المكدس التي قرأتها (وفي في الحالات الأخرى ، اقتراحtimholy هو حقًا ما هو مطلوب ، نظرًا لأنه عادةً ما يتعلق

إذا كانت تتوافق مع بعض الأنواع المستعارة الموجودة ، فستختفي تلقائيًا الآن (# 36107). خلاف ذلك ، فإنها تشير إلى اختناقات أداء التجميع المحتملة - هل من المحتمل أن يكون الأمر يستحق التحقيق؟

يتم ذلك الآن.

بالنسبة لبعض الأشخاص ، ولكن يشعر معظم الناس بالارتباك عندما يطبعون نوعًا قد يستغرق 3 صفحات من الورق المطبوع ، لذلك من المحتمل أن يكون شيئًا يتم قبوله. سأفتح قضية أخرى لمناقشة ذلك.

تابع في https://github.com/JuliaLang/julia/issues/36517