Godot: صفيف تشريح لـ GDScript

لاحظ أن هذا يتم بسهولة باستخدام range وفهمات من # 4716:

var result = array[from:to:step]
# Is the same as:
var result = (array[i] for i in range(from,to,step))

أيضًا ، لإلقاء بناء جملة CoffeeScript هنا أيضًا:

x = array[from...to]

قد نقوم بتكييف هذا لدعم حجم الخطوة (نظرًا لأنهم لا يفعلون ذلك):

x = array[from..step..to]
# or
x = array[from...to:step]

صيغة imho python مع: أكثر ملاءمة - أحرف أقل وأكثر إحكاما

صيغة imho python مع: أكثر ملاءمة - أحرف أقل وأكثر إحكاما

+1. وأقل إرباكًا. نحن نشبه لغة بيثون ، لذلك دعونا لا نستورد السلوكيات من كل اللغات الأخرى في العالم وإلا سيصبح GDScript غير متسق حقًا.

بناء جملة D ($ هو حجم المصفوفة):

array[2..4]
array[2..$]
array[$-1..$]

فقط للرجوع اليها. أوافق على أن لغة Python تتناسب بشكل أفضل مع GDScript: P

أنا على استعداد للعمل على هذا.

كخطوة أولى ، أقوم بإعداد علاقات عامة تضيف فهرسة سلبية. (إذا سمحنا باستخدام array[:-1] ، فسنسمح أيضًا array[-1] أيضًا.)

ماذا عن التخصيص لشرائح المصفوفة؟ هل توجد حالات استخدام؟

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

أعتقد أن أحد القيود التي يتعين علينا إجراؤها هو أن قيم الاستبدال يجب أن يكون لها نفس الحجم (الذي تفرضه Python أيضًا على هياكل تشبه المصفوفة ذات حجم ثابت ، مثل البايت)

بمعنى آخر ، يجب أن يعمل ما يلي:

var a = range(10)
a[2:5] = [10, 11, 12]
print(a) #[0, 1, 10, 11, 12, 3, 4, 5, 6, 7, 8, 9]

قد يكون ما يلي:

a = range(10)
a[1::2] = [10, 11, 12, 13, 14]
print(a) # [0, 10, 2, 11, 4, 12, 6, 13, 8, 14]

لكن هذا على الأرجح لن يكون:

a = range(10)
a[2:5] = [10]
print(a) # [0, 1, 10, 5, 6, 7, 8, 9]

آراء؟

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

Brakhane لا أحد في عجلة من أمره - خذ وقتك :)

انظر # 5701 و # 5765
لقد أضفت عملية شريحة بسيطة مكونة من وسيطتين إلى روابط DVector و ByteArray والتي يمكن أن تنطبق مع بعض الروابط المستقبلية على أي من أنواع مصفوفة GDSript منخفضة المستوى (IntArray ، StringArray ، إلخ). الكود ليس موجودًا بعد للتعامل مع -1. أدركت للتو أنني تركت هذه الراحة للتو.

أعتقد أن هذا يجب أن يتم تنفيذه لـ 3.0 ، حاليًا لدينا فقط طريقة subarray(from, to) المطبقة لـ PoolByteArray ، ولكن ليس للأنواع المضمنة الأخرى ، لذلك فهي غير متسقة للغاية. إذا لم ننفذ شيئًا ثابتًا للإصدار 3.0 ، فإنني أقترح الرجوع إلى رقم 5879 (الذي لم يتم شحنه بعد في إصدار ثابت) لتجنب إدخال واجهة برمجة تطبيقات قد يتم استبدالها لاحقًا.

تم تنفيذ عملي بنسبة 98٪ (وهو يعمل ، ولكن هناك بعض حالات تسرب الذاكرة والأعطال العشوائية التي لم يكن لدي الوقت لتصحيحها) ، ولكن نظرًا لضيق الوقت في الحياة الواقعية ، لن أتمكن من إنهائه.

أنا أكثر من راغب في وضع العمل قيد التقدم في فرع حتى يتمكن شخص ما (مساعدتي) من إنهائه. يمكنني المساعدة في الأسئلة المتعلقة بالتنفيذ. سيكون من العار أن يضيع جهدي (ربما أقضي حوالي 40 ساعة حتى الآن)

التطبيق مكتمل إلى حد كبير (وأنا فخور جدًا بمدى اكتماله) ، على سبيل المثال ، يعمل التقسيم كما هو الحال في Python لمعظم أنواع المصفوفات ، بما في ذلك المهمة ( a[1:4] = [1,2,3] على سبيل المثال يعمل ، كذلك a[1:3] = b[10:13:2] والعكس بالعكس).

هناك بعض المحاذير بالرغم من ذلك:

• التنفيذ معقد نوعًا ما ، ويجب أن يكون لديك بعض الفهم حول Variant.cpp و variant_op بالإضافة إلى مترجم الرمز الثانوي لفهمه.
• للحفاظ على سلامة عقلي والمساعدة في تصحيح الأخطاء ، اضطررت إلى استبدال بعض وحدات الماكرو في variant_op بقوالب مكافئة ، فإن IMO تجعل الكود أكثر قابلية للقراءة (مع تمكين التحسينات بأسرع ما يمكن) ، ولكن نظرًا لأن الكود يعتمد على 2.1 ، هناك ربما تحتاج إلى إعادة بناء ديون للترجمة مع 3.0 ؛ أيضًا ، نظرًا لأن الكود هو WIP ، لم يكن لدي وقت لتقسيمه إلى التزامات منفصلة ، لذلك في بعض الأحيان يتم استبدال الماكرو بقالب بينما في نفس الوقت يتم إضافة منطق المتغير أيضًا ؛ يجعل الأمر أصعب قليلاً (لكن ليس من الصعب جدًا) التمييز بين الاثنين
• لتجنب جعل مترجم كود البايت غير متوافق مع الإصدارات القديمة ، كان علي تقديم نوع بيانات جديد slice ، والذي يجب كشفه في المحرر. تم هذا العمل ، ولكن هناك بعض الحواف الخشنة.
• كما ذكرنا سابقًا ، فإن المشكلة "الوحيدة" المتبقية هي بعض فساد الذاكرة الذي لم أستطع اكتشافه ؛ يجب أن يكون كل من يريد تصحيح هذا الأمر على دراية بكيفية عمل مترجم Godot bytecode

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

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

كيف تجري الامور؟
نتطلع هذا. :)

@ bojidar-bg هو برنامج gdscript dev الجديد لدينا ، هل ترغب في تجربته؟ : ص

حسنا ، سوف تدفع من أجل 3.1

أردت فقط ملاحظة أن طريقة المصفوفة الفرعية تستخدم نطاقات شاملة ، في حين أن هذا (نأمل) يستخدم نطاقات تقطيع بأسلوب الثعبان.

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

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

أي تقدم مع هذا؟
لقد اكتشفت للتو أنه يمكنني حقًا استخدام هذه الوظيفة في GDscript

الانتقال إلى المرحلة التالية مثل الإصدار 3.1 تم تجميده الآن (و 3.2 لديه العديد من التحسينات المخططة لـ GDScript).

مرحبًا ، لقد صادفت هذا العنصر للتو وأردت رمي ​​اثنين من سنتي.

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

بينما أنا جميعًا مع السكر النحوي ، أعتقد أن مطور اللعبة العادي لديه توقعات معقولة تتعلق بالذرية والسرعة عندما يتم تنفيذ أي شيء يتعلق بالأقواس ، والأقواس المتعرجة ، والأقواس وما إلى ذلك في GDScript. إذا تم كسر هذا العقد ، فإن السؤال عن متى يجب علي دفع شيء ما إلى GDNative يصبح أكثر ضبابية. أعتقد أن وظيفة "sub_array ()" أو "slice ()" الجيدة ستكون أفضل طريقة للذهاب لأنه بعد ذلك (أفترض) يمكنك الاحتفاظ برمز فهرسة المصفوفة الحالي كما هو.

هل هناك أي تقدم في هذا؟ يمكنني تقديم PR الذي يضيف مثل هذه الأساليب.

ما زلت تريد أن يتم تنفيذ هذا. أى اخبار؟

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

@ bojidar-bg

لاحظ أن هذا يتم بسهولة باستخدام range وفهمات من # 4716:

var result = array[from:to:step]
# Is the same as:
var result = (array[i] for i in range(from,to,step))

هذا ليس صحيحًا حاليًا ، حيث لم يتم تضمين المفاهيم بعد. الصيغة الحالية هي:

var result = []
for i in range(from, to, step):
    result.append(array[i])

من الغريب أن المطورين رفضوا العلاقات العامة لهذه الميزة (# 15222) لأسباب تتعلق بسهولة القراءة.

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

أنا شخصياً أجد السطر الواحد ليس أصعب في القراءة من الثلاثة. أي شخص آخر يعتقد أنه يجب إعادة فتح هذه المحادثة؟

SnailBones أعتقد أن وجود طريقة Array.slice() مضمنة هي الأكثر منطقية هنا. لغات مثل JavaScript لها وظيفة مماثلة ، ويبدو أنها تعمل بشكل جيد هناك:

أعتقد أن فهم القوائم سيكون أمرًا رائعًا ، ولكن الحصول على Array.slice() منفصل سيكون مفيدًا بغض النظر.

أنا أعمل على طريقة Array.slice الآن

هل سيكون من الأفضل إنشاء نوع شريحة متغير جديد مثل طريقة عمل بايثون حيث يتم إدخال كائن الشريحة هذا في المصفوفة كمعامل ، أو أن يتم ترميز استدعاء وظيفة الشريحة في المصفوفة في المترجم؟ انتهيت من طريقة slice وأبحث في إضافة بناء جملة start:end:delta إلى فهرسة gdscript.

سيكون كائن الشريحة أكثر "Pythonic" ؛) ولكن الطريقة المشفرة
سيكون من شبه المؤكد أن يكون أسرع. في كلتا الحالتين ، باستخدام ملف
البداية: النهاية : تركيب دلتا
سيكون من المفيد جدا.

يوم السبت ، 20 تموز (يوليو) 2019 ، الساعة 6:05 مساءً ، كاميرون ريكس ، [email protected]
كتب:

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

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/godotengine/godot/issues/4715؟email_source=notifications&email_token=ACJUE6P4A4CDQWUS4PSQQH3QAOK2JA5CNFSM4CEI4JPKYY3PNVWWK3TUL52HS4DFVREXG43VMV
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ACJUE6LOTSF243FOYXXR2SDQAOK2JANCNFSM4CEI4JPA
.

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

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

يوم السبت 20 يوليو 2019 الساعة 11:28 مساءً كاميرون ريكس [email protected]
كتب:

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

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/godotengine/godot/issues/4715؟email_source=notifications&email_token=ACJUE6IMHLNTYTVL7DITY2TQAPQX3A5CNFSM4CEI4JPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW13
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ACJUE6P5Q55EXAWD6IB4ARDQAPQX3ANCNFSM4CEI4JPA
.

سأرى ما إذا كان بإمكاني العثور على تطبيقي القديم الذي لا يزال موجودًا في مكان ما. تم الانتهاء منه بنسبة 90 ٪ وعمل نوعًا ما مثل Python ، حيث يوجد كائن شريحة يمكنك استخدامه للفهرسة في المصفوفات. يمكنك حتى القيام بأشياء مثل arr [2: 4] = [1،2،3].

توقفت عن العمل عليها بسبب ضيق الوقت

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

creikey هذا يبدو مشابهًا جدًا لأسلوبي. لقد حذفت مستودع godot GitHub الخاص بي ، لكن ربما لا يزال لدي الرمز موجودًا في مكان آخر. سأقوم بنشر التحديث

creikey لقد عثرت على صفحة ويب غير حديثة تمامًا (قد تكون هناك بعض الميزات مفقودة في هذا الإصدار). يمكنك العثور عليها هنا: https://github.com/brakhane/godot/compare/4c4ab14..8a258c0

لا تزال هناك بعض الأخطاء ، على سبيل المثال ، لقد لاحظت هنا للتو https://github.com/brakhane/godot/compare/4c4ab14..8a258c0#diff -7d521a4f767fb1ae3c908a20616084a4R1446 يجب أن تقول ".end" بدلاً من ".start"

إذا كانت لديك أسئلة ، يسعدني الرد عليها. سأحاول أيضًا العثور على إصدار أحدث.

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