Libelektra: روابط الصدأ

لا أعرف الكثير عن Rust ، لكنني أفترض أن الروابط التي تم إنشاؤها بواسطة rust-bindgen يمكن استخدامها فقط في unsafe Rust؟ إذا كان هذا هو الحال ، فسيكون من الجيد أن يكون لديك غلاف حول أولئك الذين لديهم واجهة برمجة تطبيقات Rust أكثر اصطلاحية.

تحتوي معظم عمليات ربط الصدأ في AFAIK على صندوق *-sys لتعيين 1: 1 لواجهة برمجة تطبيقات C وصندوق آخر مع واجهة برمجة التطبيقات التي يستخدمها معظم المستخدمين في Rust. إذا كانت هناك طريقة لإخبار Rust باستدعاء keyDel و ksDel والأصدقاء عند الضرورة ، فسيكون ذلك رائعًا حقًا.

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

نعم ، هذه هي الخطة. وأثناء القيام بذلك ، قارن أيضًا مع C API وربما تجد تحسينات في C API (على الأقل في docu).

PhilippGackstatter كما تمت مناقشته: يرجى أيضًا معرفة كيفية التحميل إلى https://crates.io/ وكيفية دمج الربط في نظام CMake الخاص بنا.

PhilippGackstatter أي تقدم؟ لدينا شخص قد يكون مهتمًا أيضًا بتمديد روابط الصدأ.

@ markus2330 لقد بدأت منذ يومين ، لكنني كنت أقرأ في الغالب على bindgen و cmake وكيفية دمجه في المشروع ، لذلك لم يكن هناك ما أعرضه. لكن لدي أول شيئين جاهزين الآن (انظر # 2826). أنا أعمل بشكل كامل في المشروع الآن.

للإجابة على الأسئلة من # 2826 (يرجى تفضيل طرح الأسئلة في القضايا حيث يميل ممثلو العلاقات العامة إلى إرباك المناقشات التي لا تتعلق مباشرة بالرمز):

الأول ، أي الرؤوس في src / include التي أحتاجها لإنشاء روابط لها. على الأقل kdb.h ، لكن هل هناك أنواع أخرى أحتاجها لواجهة برمجة التطبيقات منخفضة المستوى ، بدون دعم البرنامج المساعد؟

لا ، واجهة برمجة التطبيقات ذات المستوى المنخفض متوفرة فقط في kdb.h

والآخر هو ، هل يجب علي تغيير جميع نصوص عامل الإرساء من أجل تثبيت Rustup (الذي يستخدم لتثبيت البضائع والصدأ)؟

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

سيكون من الجيد أن تجعله يتراكم مع الصدأ الأصلي المجمّع في Debian Buster. لم يتم دمج ملف Debian Buster docker # 2819

أفترض أنه لا توجد طريقة آلية للقيام بذلك.

هناك بعض الأفكار للقيام بذلك: # 730

يقدم Rust-bindgen طريقتين لتوليد الارتباطات. أحدهما عبر سطر الأوامر ، وهو بالتالي عملية يدوية وتحتاج إلى التكرار إذا تغير أي شيء في C-API. والآخر عبر برنامج نصي للبناء ، يتم تشغيله في كل مرة يتم فيها تشغيل بناء البضائع. هذا يعني أنه يتم تجديد الروابط في كل بناء. هذا هو ما يتم تنفيذه حاليا. ومع ذلك ، فإنه يتطلب من كل شخص يستخدم الارتباطات أن يكون لديه الرؤوس الضرورية التي تحتاجها elekra. أتخيل ، إذا قام شخص ما فقط بتثبيت elektra ولكن لم يقم بتجميعها ، فقد لا يفي بجميع المتطلبات اللازمة. ربما يكون من المنطقي إعادة إنشاء الرؤوس من حين لآخر يدويًا ، نظرًا لأن C-API لم يعد يتغير كثيرًا بعد الآن؟

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

نعم ، هذه هي الخطة. وأثناء القيام بذلك ، قارن أيضًا مع C API وربما تجد تحسينات في C API (على الأقل في docu).

حتى الآن ، وجدت بعض الفرص البسيطة للتحسين

• keyGetBinary : كرمز اتصال ، لا يمكنني معرفة ما إذا كانت القيمة المرجعة -1 تعني maxSize is 0 أو type mismatch ، أو أي شيء آخر. نظرًا لأن Rust يستخدم معالجة الأخطاء الصريحة في وسيطات الإرجاع الخاصة به ، أود أن أكون قادرًا على مطابقة عدم تطابق النوع مع خطأ ، وأخطاء "maxSize ذات الصلة" بأخرى. لكن بشكل متكرر لا بد لي من استخدام خطأ أكثر عمومية. يمكنني التحقق من عدم تطابق النوع بنفسي ، لكن keyGetBinary يفعل ذلك ، لذلك لدي نفس الشيك مرتين.
  keySetName بعمل شيء مشابه ، حيث يطابق خطأين مختلفين مع -1. في كلتا الحالتين ، هناك أخطاء من الأخطاء (اسم غير صالح) وأخطاء يمكن أن تحدث في برامج الصوت (المفتاح موجود بالفعل في مجموعة المفاتيح) ، لذلك يمكنني نوعًا من فهم القرار. ولكن لماذا لا تستخدم -2 للتوضيح وتجنب الفحص المزدوج؟
• نحويًا ، ألا يجب أن يكون keyIsDirectBelow keyIsDirectlyBelow 🙂؟ إذا كان الأمر كذلك ، فهل يجب علي تصحيح ذلك في Rust API؟

سؤال آخر: keyRel غير مطبق في ربط CPP. هل يجب أن أحذف هذا في Rust أيضًا؟

عمل رائع ، من خلال أسئلتك ، من الواضح أنك نظرت بعمق في واجهة برمجة التطبيقات.

يمكنني التحقق من عدم تطابق النوع بنفسي ، لكن keyGetBinary يقوم بذلك ، لذلك لدي نفس الاختيار مرتين.

ربما يمكنك حتى استخدام نظام الطباعة لتجنب المكالمات الخاطئة؟ (keyGetBinary مسموح به فقط على المفاتيح الثنائية)

ولكن لماذا لا تستخدم -2 للتوضيح وتجنب الفحص المزدوج؟

كان السبب هو التوافق: عادت واجهات برمجة التطبيقات في البداية -1 فقط وليس من الممكن إضافة رموز خطأ أخرى دون كسر البرامج الموجودة (والتي قد تحتوي على ==-1 للتحقق من وجود أخطاء). ولكن مع الإصدار التالي (0.9) يمكننا كسر API مرة أخرى. ويمكننا تجنب مشكلة التوافق بالقول إن أي قيم أقل من الصفر تشير إلى وجود أخطاء. أوافق تمامًا على أن عمليات الربط يجب أن تؤدي إلى أخطاء دقيقة.

هل تريد إصلاح مشاكل API هذه؟

إذا كان الأمر كذلك ، فهل يجب علي تصحيح ذلك في Rust API؟

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

keyRel غير مطبق في ربط CPP. هل يجب أن أحذف هذا في Rust أيضًا؟

نعم ، ربما لاحظت بالفعل أن keyIs (Direct) أدناه و keyRel لها وظائف متداخلة. كانت فكرة keyRel هي إبقاء واجهة برمجة التطبيقات صغيرة (وبالتالي المكتبة صغيرة). لكن keyRel كما هو غير صالح للاستخدام وبطيء أيضًا. لذلك سنزيله على الأرجح في نطاق 0.9. انظر doc / todo / FUTURE لمرشحين آخرين ليتم حذفهم.

ربما يمكنك حتى استخدام نظام الطباعة لتجنب المكالمات الخاطئة؟ (keyGetBinary مسموح به فقط على المفاتيح الثنائية)

هذه فكرة عظيمة. كان من الممكن أن يكون لدي BinaryKey و StringKey وسيكون الأول فقط طريقة get_binary() والثاني فقط سيكون له طريقة get_string() ، وهكذا. سأبحث في هذا.

هل تريد إصلاح مشاكل API هذه؟

أستطيع فعل ذلك. يعتمد على ما يجب أن تكون الأولوية بالنسبة لي. بعد الانتهاء من واجهة برمجة التطبيقات الآمنة لـ Rust ، قلت إنه سيكون من الجيد أيضًا أن يكون لديك واجهة برمجة تطبيقات البرنامج الإضافي في Rust. يمكنك أن تقرر ما هو أكثر أهمية.

هذه فكرة عظيمة. يمكن أن يكون لدي BinaryKey و StringKey وسيكون الأول فقط له طريقة get_binary () والثاني فقط سيكون له طريقة get_string () ، وهكذا. سأبحث في هذا.

شكرا لك. قد يتطلب الأمر عددًا كبيرًا جدًا من الممثلين ، لذلك دعونا نرى ما إذا كانت فكرة جيدة. قد يكون نوع آخر مفيدًا أيضًا للمفاتيح الموجودة في مجموعة المفاتيح (حيث لا يُسمح بـ setName).

أستطيع فعل ذلك. يعتمد على ما يجب أن تكون الأولوية بالنسبة لي. بعد الانتهاء من واجهة برمجة التطبيقات الآمنة لـ Rust ، قلت إنه سيكون من الجيد أيضًا أن يكون لديك واجهة برمجة تطبيقات البرنامج الإضافي في Rust. يمكنك أن تقرر ما هو أكثر أهمية.

نعم ، قم أولاً بإنهاء Rust API من kdb.h ثم سنرى عدد الساعات الإضافية التي يتعين علينا قضاءها.

يجب أن يكون لربط الصدأ الخاص بالمنظمة البحرية الدولية (وأي ارتباط لهذه المسألة) نسختين. واحد يعكس واجهة برمجة تطبيقات C في أقرب وقت ممكن والآخر أكثر اصطلاحًا للغة التي تبني على الإصدار الأول. في النسخة الاصطلاحية ، من المحتمل أن يكون استخدام نظام الكتابة مع BinaryKey و StringKey (أو حتى الأدوية العامة) فكرة جيدة ، إذا كان يجعل استخدام API من Rust أسهل.

kodebach أوافق. ويبدو أن هذا يتم أيضًا مع صناديق elektra و elektra-sys.

kodebach أوافق. ويبدو أن هذا يتم أيضًا مع صناديق elektra و elektra-sys.

نعم، أظن ذلك أيضا. إذا كانت واجهة برمجة التطبيقات الآمنة Rust بها قيود يجب التعامل معها ، فيمكن للمرء استيراد elektra_sys واستدعاء وظيفة الربط C مباشرة.

شكرا لك. قد يتطلب الأمر عددًا كبيرًا جدًا من الممثلين ، لذلك دعونا نرى ما إذا كانت فكرة جيدة. قد يكون نوع آخر مفيدًا أيضًا للمفاتيح الموجودة في مجموعة المفاتيح (حيث لا يُسمح بـ setName).

عملت بشكل رائع لتنفيذ المفتاح. ومع ذلك ، بالنسبة لمجموعات KeySets ، فقد اصطدمت بحاجز على الطريق. بالنسبة لأية طرق تقوم بإرجاع مفتاح ، يجب أن تتوافق مع الواجهة المشتركة التي قمت بإنشائها. لقد قمت بتطبيق طريقة get_value لها معامل إرجاع عام. بالنسبة إلى BinaryKeys الذي يساوي بايت ، بالنسبة إلى StringKeys ، فهو عبارة عن سلاسل. ولكن ما الذي ستعيده النسخة الصدئة من ksNext الآن؟ كائن يتوافق مع "الواجهة الرئيسية" ، ولكن بأي قيمة؟ لا بد لي من اختيار واحد.
هذا ما يجب أن يبدو عليه التوقيع ، حيث تكون القيمة هي النوع الذي يعيده get_value . يمكنني فقط تحديد إما بايت ( Vec<u8> ) أو سلسلة.
pub fn next(&mut self) -> Box<dyn WriteableKey<Value = Vec<u8>>>;

لذلك يمكنني توحيدها إلى بايت ، ولكن بعد ذلك يتعين على المستخدم التحويل إلى سلسلة بنفسه. نظرًا لأن الاختلاف الوحيد بين StringKey و BinaryKeys هو تطبيقهما set_value و get_value ، سيؤدي هذا التغيير إلى إزالة هذا الصريح ولديّ مفاتيح فقط مرة أخرى.

أعتقد أن المشكلة الحقيقية هي أن KeySet في التطبيق الحالي ليس واضحًا بشأن نوع المفاتيح التي يحتوي عليها ، ولكن المفاتيح * هي. لكن السماح لمثيل KeySet باحتواء StringKey أو BinaryKey فقط هو أكبر من القيد الذي أفترضه.
أعتقد أن كلاً من KeySet و KeySet يجب أن يكونا واضحين بشأن ما يحتويانه أو لا شيء منهما. أنا أميل إلى مجموعة المفاتيح العامة ومجموعة المفاتيح الآن ، فقط لأكون متسقًا مع بقية الإلكترا.
أي أفكار؟

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

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

1. تحاول تغيير اسم المفاتيح لمفتاح موجود في مجموعة مفاتيح.
2. محاولة تغيير مفاتيح البيانات الوصفية (أو مفاتيح const أخرى).
3. الخلط بين الازدواجية في Key / KeySet والإشارات إليها.
4. التكرار عبر مجموعات المفاتيح التي تُستخدم أيضًا لقطع المفاتيح بطريقة لا تعمل التكرار بشكل صحيح بعد الآن.
5. نسيان تحرير Key / KeySet

لذا ، إذا كان بإمكان نظام الكتابة المساعدة هناك ، فسيكون ذلك رائعًا. 5. لن يكون ممكنًا حسب التصميم ، بالنسبة لـ 1. و 2. يجب أن يساعدك التجريد.

الارتباك الثنائي / الخلط هو في الواقع خطأ نادر إلى حد ما (لأن المفاتيح الثنائية غير نمطية للغاية: هناك في الغالب تستخدم للاحتفاظ بمؤشرات الوظيفة).

بالمناسبة. إذا كنت تريد كتابة قرار تصميم بشأن الاستخدامات الآمنة لواجهات برمجة التطبيقات ، فيرجى المضي قدمًا (مستند / قرار)

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

ولكن ليس كل تسلسل بايت صالحًا لـ UTF-8 بحيث لا يكون آمنًا حقًا بعد الآن ، أليس كذلك؟

AFAIK نظام الماكرو في Rust قوي جدًا ، ربما توجد طريقة لكتابة دالة تقوم دائمًا بإرجاع النوع الصحيح. على سبيل المثال ، في Kotlin توجد تقنية للخرائط لترميز نوع القيمة في المفتاح. مرجع API هنا هو مثال.

بدلاً من ذلك ، قد يكون الخيار StringKeySet الذي لا يقبل إلا StringKey s منطقيًا ، نظرًا لأن المفاتيح الثنائية نادرة جدًا ولا يتم استخدامها في الغالب في التكوينات.

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

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

قبل القيام بذلك ، أقترح جعل KeySet عامة وإنشاء مثيل لها كـ KeySet<StringKey> إذا كان المستخدم متأكدًا من وجود StringKeys فقط بالداخل (لمجموعات المفاتيح التي لا تأتي من Rust). ومن ثم فمن الطبيعي أن يؤدي التكرار فوقه إلى إنتاج StringKeys فقط.
من شأنه أيضًا أن يفرض أن مجموعات المفاتيح متجانسة عبر نظام النوع ، على الأقل تلك التي أنشأها مستخدمو Rust ، والتي ستكون أكثر أمانًا بشكل عام.
في حالات نادرة حيث يُتوقع وجود مفتاح ثنائي ، سيتعين على المستخدم التحقق باستخدام is_binary و is_string ثم التحويل ، والذي سيكون استدعاء طريقة آمنة.

الخلط بين الازدواجية في Key / KeySet والإشارات إليها.

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

التكرار عبر مجموعات المفاتيح التي تُستخدم أيضًا لقطع المفاتيح بطريقة لا تعمل التكرار بشكل صحيح بعد الآن.

هل تقصد تعديل مجموعة المفاتيح أثناء التكرار عليها؟

بالمناسبة. إذا كنت تريد كتابة قرار تصميم بشأن الاستخدامات الآمنة لواجهات برمجة التطبيقات ، فيرجى المضي قدمًا (مستند / قرار)

ماذا سيكون محتوى ذلك؟

AFAIK نظام الماكرو في Rust قوي جدًا ، ربما توجد طريقة لكتابة دالة تقوم دائمًا بإرجاع النوع الصحيح.

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

ولكن ليس كل تسلسل بايت صالحًا لـ UTF-8 بحيث لا يكون آمنًا حقًا بعد الآن ، أليس كذلك؟

لا يلزم أن تكون سلاسل Elektra أو القيمة الثنائية UTF-8. تقرر Elektra فقط بين السلسلة والثنائي (قد يحتوي على 0 بايت).

AFAIK نظام الماكرو في Rust قوي جدًا ، ربما توجد طريقة لكتابة دالة تقوم دائمًا بإرجاع النوع الصحيح. على سبيل المثال ، في Kotlin توجد تقنية للخرائط لترميز نوع القيمة في المفتاح. مرجع API هنا هو مثال.

نحتاج أيضًا إلى الانتباه لبذل الجهد في الميزات المفيدة. المفاتيح الثنائية نادرة.

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

نعم ، لكنني أرى StringKeySet باعتباره KeySet العادي.

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

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

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

سيكون مجرد أمان مزيف لأن KeySets تأتي من KDB (خارجيًا) وقد تحتوي على بيانات ثنائية في أي حال. وبالتالي أفضل أن يكون لديك KeySet غير عام.

إذا كنت ترغب في التلاعب بالأدوية العامة ، فقم بتوفير أدوات القياس والمحددات التي تحول مجموعات المفاتيح إلى هياكل بيانات (عامة). على سبيل المثال ، مجموعة Elektra من الأعداد الصحيحة إلى Vec<i32> .

هل تقصد تعديل مجموعة المفاتيح أثناء التكرار عليها؟

نعم ، يعدل cut مجموعة المفاتيح. بشكل عام ، تعتبر أجهزة التكرار آمنة للقيام بذلك ولكن العديد من الأشخاص يواجهون مشاكل في القيام بذلك بشكل صحيح.

ماذا سيكون محتوى ذلك؟

ملخص لما نناقشه هنا وكيف صممته.

أعتقد أن التصميم "الحالي" لمجموعة KeySet الذي يمكن أن يحتوي على أي شيء وأنواع مفاتيح محددة لا يعمل معًا ، على الأقل ليس جيدًا.

أنا موافق.

لكنني سأبحث في وحدات الماكرو.

من فضلك لا تعطي الأولوية لذلك.

لا يلزم أن تكون سلاسل Elektra أو القيمة الثنائية UTF-8.

ثم يجب علينا استخدام OsString أو CString بدلاً من String وفقًا لبحث سريع.

لا يلزم أن تكون سلاسل Elektra أو القيمة الثنائية UTF-8.

ثم يجب علينا استخدام OsString أو CString بدلاً من String وفقًا لبحث سريع.

الآن أقوم بالتحويل بين String (وهو UTF-8) إلى CString قبل تمريره إلى elektra. الأساس المنطقي هو أن String هي السلسلة الافتراضية وتتوقع معظم المكتبات الأخرى العمل معها.
يمكنني بدلاً من ذلك أن أجعل API عالي المستوى يطلب ويعيد CString s ، بحيث يتعين على المستخدم التعامل مع كود التحويل ، إذا احتاج إلى String . سيؤدي ذلك إلى إنشاء واجهة برمجة تطبيقات أرق وتقليل معالجة الأخطاء التي يجب التعامل معها. أفترض أن الأمر يتعلق بكيفية رغبة معظم المستخدمين في استخدام واجهة برمجة التطبيقات ، والتي ليس لدي الكثير من التبصر فيها.

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

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

أحاول اكتشاف أفضل طريقة للتعامل مع اتجاه الصدأ -> C ، والانتقال من UTF-8 إلى سلسلة C. يُسمح لسلاسل UTF-8 بأن تحتوي على صفر بايت ، ولكن نقطة الرمز الوحيدة التي يظهر فيها ذلك هي حرف NUL ، وليس خلاف ذلك . أعتقد أنه سيكون من المعقول ذكر ذلك كشرط مسبق في الوثائق الملزمة ، وهو أن السلاسل غير مسموح لها باحتواء البايت الصفري. إذا حدث ذلك على أي حال ، فإن الكود يزعج في هذه المرحلة.

الاحتمال الآخر هو إرجاع خطأ من جميع وظائف المجموعة التي تأخذ سلسلة. ولكن بعد ذلك ، يتعين على المستخدمين التعامل مع هذا NulError طوال الوقت ولا يتم إرجاعه من الناحية العملية.

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

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

نعم ، هذا معقول.

هل توافق على أن استدعاء الذعر هنا هو الأفضل (لا يسمح الإجهاض للمدمرين بالعمل)؟

نعم ، من المنطقي الذعر إذا فشل أحد مالوك. (في حالة الصدأ ، فإن stdlib سيفعل الشيء نفسه. في C لا يُجهض stdlib ، لذلك لا يُجهض C-Elektra أيضًا).

الآن بعد أن تم دمج روابط الصدأ في تنسيق رئيسي ، أود نشرها في crates.io.
أقترح نشرها مع تعيين الإصدار على (الافتراضي) 0.1.0 ، بدلاً من ربطه بـ elektra ، وذلك ببساطة لأن نضج الارتباطات والإلكترا نفسه يختلف. هل توافق @ markus2330؟

يتطلب النشر على https://crates.io حسابًا على GitHub. يمكن نقل ملكية الصناديق بين الحسابات ، لذلك يمكنني استخدام حسابي الآن. أو يمكن لشخص آخر تسجيل الدخول وإرسال الرمز المميز لواجهة برمجة التطبيقات (API) المطلوب للنشر.

شكرًا لك على نشرها على crates.io: sparkle:

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

أو يمكن لشخص آخر تسجيل الدخول وإرسال الرمز المميز لواجهة برمجة التطبيقات (API) المطلوب للنشر.

لقد قمت بتسجيل الدخول مفوض. سأرسل لك رمز API.

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

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

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

أنت محق ، لم أفكر في زيادة الإصدارات الرئيسية لاحقًا.

في الوقت الحالي ، يحدد wrapper.h #include "kdb.h" لتضمين رأس kdb وإنشاء روابط له. لكن clang لا تجد العنوان (في ubuntu:18.10 ، على سبيل المثال). لذلك يجب أن أقول صراحةً لـ clang أن تتضمن /usr/include/elektra حتى تتمكن من البناء.
هل يتم تثبيت elektra دائمًا في /usr/include/elektra بحيث يعمل هذا الحل مع معظم التوزيعات؟

هل يتم تثبيت elektra دائمًا في / usr / include / elektra بحيث يعمل هذا الحل مع معظم التوزيعات؟

نعم ، لأن هناك مكتبة أخرى (أعتقد من Kerberos) تستخدم /usr/include/kdb.h .

في الوقت الحالي ، يجب أن يكون /usr/include/elektra جزءًا من مسار التضمين ، لكن AFAIK نريد تغيير ذلك بحيث يمكن استخدام #include <elektra/kdb.h> بدلاً من ذلك.

هل يتم تثبيت elektra دائمًا في / usr / include / elektra بحيث يعمل هذا الحل مع معظم التوزيعات؟

افتراضيًا يكون / usr / local / include / elektra ولكن معظم التوزيعات ستستخدم / usr / include / elektra ولكن لا يوجد ضمان. لهذا السبب تتمتع أنظمة الإنشاء عادةً ببعض الدعم لتحديد موقع ملفات الرأس. يدعم Elektra cmake و pkg-config.

هل يمكنك إعطاء بعض السياق حول المكان الذي تحتاج إليه؟

يمكن استخدامها بدلا من ذلك.

يجب أن تستخدم بدلا من ذلك. العلاقات العامة ذات الصلة هي # 2880

التغيير إلى #include <elektra/kdb.h> يعمل بالتأكيد في Ubuntu. لذلك سأتغير إلى هذا المسار بدلاً من تضمين /usr/include/elektra .

التغيير إلى #include <elektra/kdb.h> يعمل بالتأكيد في Ubuntu. لذلك سأتغير إلى هذا المسار بدلاً من تضمين /usr/include/elektra .

من المحتمل ألا يعمل مع جميع الرؤوس ، يعتمد البعض على وجود /usr/include/elektra في مسار التضمين.

ربما يكون أفضل شيء تفعله (إذا كان ذلك ممكنًا بالنسبة لك) هو استخدام pkg-config أو cmake --find-package للعثور على ملفات Elektra (IMO cmake يعمل بشكل أفضل).

هل يمكنك إعطاء بعض السياق حول المكان الذي تحتاج إليه؟

لذلك إذا قام المستخدم بتجميع elektra على جهازه ، فإنه يحتاج فقط إلى الصدأ / البضائع ويمكنه استخدام الروابط. لكن حالة الاستخدام الأخرى ، التي يجب استخدام crates.io من أجلها ، هي إذا قام شخص ما بتثبيت elektra (والرؤوس) عبر مدير الحزم الخاص به. ثم المكتبة والعناوين متوفرة. الآن قام المستخدم بتضمين elektra في تبعياته وسوف تجلب البضائع الصندوق elektra-sys . يعتمد فقط على نص البناء و clang لتوليد الارتباطات. لكن كلانج يحتاج إلى العثور على kdb.h بطريقة ما. لذا يمكنني إما تمرير مسارات تضمين إضافية مشفرة في نص الإنشاء أو تعديل عبارة #include ... مباشرةً.

ربما يكون أفضل شيء تفعله (إذا كان ذلك ممكنًا بالنسبة لك) هو استخدام pkg-config أو cmake --find-package للعثور على ملفات Elektra (IMO cmake يعمل بشكل أفضل).

يمكنني محاولة إضافة pkg-config أو cmake لتبعية بناء والعثور على kdb.h بهذه الطريقة. سأبحث في هذا. أوافق على أن هذه هي الطريقة الأكثر موثوقية.

نعم ، يمكنك محاولة استدعاء pkg-config في البرنامج النصي للبناء. إذا لم يكن pkg-config متاحًا ، فيمكنك تجربة المسارات ذات الترميز الثابت مثل / usr / include / elektra و / usr / local / include / elektra. (إذا كان crates.io لا يتطلب توفر pkg-config.)

يمكنك تجربة هذا الصندوق

نعم ، يمكنك محاولة استدعاء pkg-config في البرنامج النصي للبناء. إذا لم يكن pkg-config متاحًا ، فيمكنك تجربة المسارات ذات الترميز الثابت مثل / usr / include / elektra و / usr / local / include / elektra. (إذا كان crates.io لا يتطلب توفر pkg-config.)

أضفت pkg-config كتبعية اختيارية. إذا تمت إضافته ، فسيتم البحث عن elektra واستخدام العنصر المتضمن. وإلا فإنه سيبحث في المجلدين اللذين سميتهما.

تم نشر الارتباطات الآن: elektra و elektra-sys : smiley:

بسبب تبعية النظام المفقودة لـ libelektra في بيئة بناء docs.rs ، لم يتم إنشاء الوثائق. بالإضافة إلى ذلك ، سوف يغيرون بيئة البناء في 30 سبتمبر.
لقد قدمت طلبًا لإضافة libelektra كعنصر تبعية حتى يتم البناء بشكل صحيح في 30 سبتمبر. أضاف أيضًا الحزمة إلى البيئة الحالية ، لذا أصبحت المستندات متاحة الآن: +1:

أعتقد أنه بعد دمج # 2980 ، يمكن إغلاق هذه المشكلة.

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

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

هل يمكنك بعد ذلك إضافة الروابط إلى docu داخل الريبو الخاص بنا؟

يبدو أن نظام elektra-sys غير قابل للاستخدام تقريبًا على أي حال. يعرض مئات الرموز التي لا علاقة لها بإلكترا. علاوة على ذلك ، لا يوجد docu للوظائف الفردية ، على سبيل المثال

https://docs.rs/elektra-sys/0.9.0/elektra_sys/fn.keyString.html

هل يمكنك بعد ذلك إضافة الروابط إلى docu داخل الريبو الخاص بنا؟

نعم ، سأضيفه إلى العلاقات العامة الحالية

يبدو أن نظام elektra-sys غير قابل للاستخدام تقريبًا على أي حال. يعرض مئات الرموز التي لا علاقة لها بإلكترا.

وسوف ننظر في هذا.

علاوة على ذلك ، لا يوجد docu للوظائف الفردية ، على سبيل المثال

من المعتاد بالنسبة لصناديق -sys ألا تحتوي على docu (على سبيل المثال ، openssl-sys ) ، لأنها ترجمات فردية لما يعادل C. لذا يتعين على المرء أن يبحث عن C doc مباشرة. سأضطر أيضًا إلى تسليم نسخة كاملة من docu ، مما يضيف عبئًا آخر للصيانة. يمكنني الارتباط بـ https://doc.libelektra.org/api/current/html/index.html على صفحة docu الرئيسية بالرغم من ذلك.

يبدو أن نظام elektra-sys غير قابل للاستخدام تقريبًا على أي حال. يعرض مئات الرموز التي لا علاقة لها بإلكترا.

وسوف ننظر في هذا.

تم إصلاحه في # 2980 ، وسيتم إصلاحه على docs.rs في المرة القادمة التي ننشر فيها الصندوق.

يمكنني الارتباط بـ https://doc.libelektra.org/api/current/html/index.html على صفحة docu الرئيسية بالرغم من ذلك.

نعم فكرة جيدة!