Libelektra: रस्ट बाइंडिंग

मैं जंग के बारे में इतना नहीं जानता, लेकिन मुझे लगता है कि rust-bindgen द्वारा उत्पन्न बाइंडिंग का उपयोग केवल unsafe जंग में किया जा सकता है? यदि ऐसा है, तो अधिक मुहावरेदार रस्ट एपीआई वाले लोगों के चारों ओर एक आवरण रखना अच्छा होगा।

AFAIK अधिकांश रस्ट बाइंडिंग में C API के 1:1 मैपिंग के लिए एक *-sys क्रेट और API के साथ एक अन्य क्रेट होता है जिसे अधिकांश उपयोगकर्ता वास्तव में Rust में उपयोग करेंगे। यदि रस्ट को स्वचालित रूप से keyDel , ksDel और दोस्तों को आवश्यक होने पर आमंत्रित करने के लिए कहने का कोई तरीका है तो यह वास्तव में अच्छा होगा।

यदि ऐसा है, तो अधिक मुहावरेदार रस्ट एपीआई वाले लोगों के चारों ओर एक आवरण रखना अच्छा होगा।

हाँ, यह योजना है। और ऐसा करते समय, सी एपीआई के साथ भी तुलना करें और शायद सी एपीआई (कम से कम दस्तावेज़ में) में सुधार पाएं।

@PhilippGackstatter जैसा कि चर्चा की गई है: कृपया यह भी पता करें कि https://crates.io/ पर कैसे अपलोड किया जाए और हमारे सीएमके सिस्टम में बाइंडिंग को कैसे एकीकृत किया जाए।

@PhilippGackstatter कोई प्रगति? हमारे पास कोई है जो रस्ट बाइंडिंग का विस्तार करने में भी दिलचस्पी ले सकता है।

@ मार्कस 2330 मैंने कुछ दिन पहले शुरू किया था, लेकिन मैं ज्यादातर बाइंडजेन, सेमेक पर पढ़ रहा था और इसे परियोजना में कैसे एकीकृत किया जाए, इसलिए दिखाने के लिए कुछ भी नहीं था। लेकिन मेरे पास अभी पहली दो चीज़ें तैयार हैं (#2826 देखें)। मैं अभी इस प्रोजेक्ट पर पूरी तरह से काम कर रहा हूं।

#2826 से प्रश्नों का उत्तर देने के लिए (कृपया मुद्दों में प्रश्न पूछना पसंद करें क्योंकि पीआर में उन चर्चाओं के लिए भ्रमित होने की प्रवृत्ति होती है जो सीधे कोड से संबंधित नहीं होती हैं):

एक है, src/include में कौन से हेडर के लिए मुझे बाइंडिंग जेनरेट करने की आवश्यकता है। कम से कम kdb.h, लेकिन क्या प्लगइन समर्थन के बिना मुझे निम्न-स्तरीय एपीआई की आवश्यकता है?

नहीं, निम्न-स्तरीय API केवल kdb.h . में है

दूसरा यह है कि, क्या मुझे रस्टअप स्थापित करने के लिए सभी डॉकटर लिपियों को बदलना होगा (जिसका उपयोग कार्गो और रस्टक को स्थापित करने के लिए किया जाता है)?

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

यह अच्छा होगा यदि आप इसे डेबियन बस्टर में संकलित देशी जंग के साथ संकलित कर सकते हैं। डेबियन बस्टर डॉकर फ़ाइल अभी तक मर्ज नहीं हुई है #2819

मुझे लगता है कि ऐसा करने का कोई स्वचालित तरीका नहीं है।

ऐसा करने के लिए कुछ उपाय हैं: #730

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

प्रत्येक निर्माण पर पुनर्जनन उचित समाधान प्रतीत होता है, अन्य बाइंडिंग भी उसी तरह काम करते हैं (उन्हें स्थापित करने के लिए स्विग की आवश्यकता होती है)। आप जिन समस्याओं का वर्णन कर रहे हैं, उनसे बचने के लिए आप जेनरेट की गई हेडर फाइलों को आसानी से इंस्टॉल कर सकते हैं।

हाँ, यह योजना है। और ऐसा करते समय, सी एपीआई के साथ भी तुलना करें और शायद सी एपीआई (कम से कम दस्तावेज़ में) में सुधार पाएं।

अब तक, मुझे सुधार के कुछ छोटे अवसर मिले हैं

• keyGetBinary : कॉलिंग कोड के रूप में, मुझे नहीं पता कि -1 का रिटर्न मान maxSize is 0 या type mismatch या कुछ और है। चूंकि जंग अपने रिटर्न तर्कों में स्पष्ट त्रुटि प्रबंधन का उपयोग करता है, इसलिए मैं एक त्रुटि के लिए प्रकार बेमेल मिलान करने में सक्षम होना चाहता हूं, और "अधिकतम आकार से संबंधित" त्रुटियों को दूसरे से मेल करना चाहता हूं। लेकिन कर्नेटली मुझे एक और सामान्य त्रुटि का उपयोग करना है। मैं अपने आप में एक प्रकार के बेमेल की जांच कर सकता था, लेकिन keyGetBinary ऐसा करता है, इसलिए मेरे पास दो बार एक ही चेक है।
  keySetName कुछ ऐसा ही करता है, दो अलग-अलग त्रुटियों को -1 से मिलाता है। दोनों ही मामलों में त्रुटियां हैं जो बग (अमान्य नाम) और त्रुटियां हैं जो ध्वनि कार्यक्रमों (कुंजी पहले से ही कीसेट में) में हो सकती हैं, इसलिए मैं निर्णय को समझ सकता हूं। लेकिन डबल चेकिंग से बचने और स्पष्टीकरण के लिए -2 का उपयोग क्यों न करें?
• व्याकरण की दृष्टि से, keyIsDirectBelow होना चाहिए keyIsDirectlyBelow ? यदि हां, तो क्या मुझे इसे रस्ट एपीआई में ठीक करना चाहिए?

एक और सवाल: सीपीपी बाइंडिंग में keyRel लागू नहीं किया गया है। क्या मुझे इसे रस्ट में भी छोड़ देना चाहिए?

बढ़िया काम, आपके प्रश्नों से यह स्पष्ट है कि आपने पहले ही एपीआई में गहराई से देखा है।

मैं अपने आप को एक प्रकार के मेल नहीं खाने की जांच कर सकता था, लेकिन keyGetBinary ऐसा करता है, इसलिए मेरे पास एक ही चेक दो बार है।

हो सकता है कि आप गलत कॉल से बचने के लिए टाइपसिस्टम का भी उपयोग कर सकें? (keyGetBinary को केवल बाइनरी कुंजियों पर अनुमति है)

लेकिन डबल चेकिंग से बचने और स्पष्टीकरण के लिए -2 का उपयोग क्यों न करें?

कारण संगतता थी: एपीआई शुरू में केवल -1 लौटा और मौजूदा प्रोग्राम को तोड़े बिना अन्य त्रुटि कोड जोड़ना संभव नहीं है (जिसमें त्रुटियों की जांच के लिए ==-1 हो सकता है)। लेकिन अगली रिलीज (0.9) के साथ हम एपीआई को फिर से तोड़ सकते हैं। और हम यह कहकर संगतता की समस्या से बच सकते हैं कि 0 से नीचे का कोई भी मान त्रुटियों का संकेत देता है। मैं पूरी तरह से सहमत हूं कि बाइंडिंग में सटीक त्रुटियां होनी चाहिए।

क्या आप इन API समस्याओं को ठीक करना चाहते हैं?

यदि हां, तो क्या मुझे इसे रस्ट एपीआई में ठीक करना चाहिए?

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

keyRel को CPP बाइंडिंग में लागू नहीं किया गया है। क्या मुझे इसे रस्ट में भी छोड़ देना चाहिए?

हां, जैसा कि आपने पहले ही नीचे keyIs(Direct) पर ध्यान दिया होगा और keyRel में अतिव्यापी कार्यक्षमता है। keyRel का विचार एपीआई को छोटा रखना था (और इस प्रकार पुस्तकालय छोटा)। लेकिन keyRel as-is प्रयोग करने योग्य नहीं है और धीमी भी है। इसलिए सबसे अधिक संभावना है कि हम इसे 0.9.1 के भीतर हटा देंगे। अन्य उम्मीदवारों को हटाने के लिए doc/todo/FUTURE देखें।

हो सकता है कि आप गलत कॉल से बचने के लिए टाइपसिस्टम का भी उपयोग कर सकें? (keyGetBinary को केवल बाइनरी कुंजियों पर अनुमति है)

बढ़िया विचार है। मेरे पास BinaryKey और StringKey और केवल पहले वाले के पास get_binary() विधि होगी और केवल दूसरे के पास get_string() विधि होगी, और इसी तरह। मैं इस पर गौर करूंगा।

क्या आप इन API समस्याओं को ठीक करना चाहते हैं?

मैं ऐसा कर सकता हूँ। निर्भर करता है कि मेरे लिए प्राथमिकता क्या होनी चाहिए। रस्ट के लिए सुरक्षित एपीआई को खत्म करने के बाद, आपने कहा कि रस्ट में प्लगइन एपीआई भी होना अच्छा होगा। आप तय कर सकते हैं कि क्या अधिक महत्वपूर्ण है।

बढ़िया विचार है। मेरे पास बाइनरीकी और स्ट्रिंगकी हो सकती है और केवल पहले के पास get_binary() विधि होगी और केवल दूसरे में get_string() विधि होगी, और इसी तरह। मैं इस पर गौर करूंगा।

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

मैं ऐसा कर सकता हूँ। निर्भर करता है कि मेरे लिए प्राथमिकता क्या होनी चाहिए। रस्ट के लिए सुरक्षित एपीआई को खत्म करने के बाद, आपने कहा कि रस्ट में प्लगइन एपीआई भी होना अच्छा होगा। आप तय कर सकते हैं कि क्या अधिक महत्वपूर्ण है।

हां, पहले kdb.h से रस्ट एपीआई खत्म करें और फिर हम देखेंगे कि हमें और कितने घंटे बिताने हैं।

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

@ कोडबैक मैं सहमत हूं। और ऐसा लगता है कि यह इलेक्ट्रा और इलेक्ट्रा-सिस क्रेट के साथ भी किया जाता है।

@ कोडबैक मैं सहमत हूं। और ऐसा लगता है कि यह इलेक्ट्रा और इलेक्ट्रा-सिस क्रेट के साथ भी किया जाता है।

हां मुझे भी ऐसा ही लगता है। यदि सुरक्षित रस्ट एपीआई की सीमाएँ हैं जिन्हें एक के आसपास काम करने की आवश्यकता है तो elektra_sys आयात कर सकते हैं और सीधे एक-से-एक सी बाइंडिंग फ़ंक्शन को कॉल कर सकते हैं।

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

इसने प्रमुख कार्यान्वयन के लिए बहुत अच्छा काम किया। हालांकि कीसेट्स के लिए, मैंने एक रोड ब्लॉक मारा है। किसी भी तरीके के लिए जो एक कुंजी देता है, उसे मेरे द्वारा बनाए गए सामान्य इंटरफ़ेस के अनुरूप होना चाहिए। मैंने एक विधि get_value है जिसमें एक सामान्य रिटर्न पैरामीटर है। बाइनरीकीज़ बाइट्स के लिए, स्ट्रिंगकीज़ के लिए यह स्ट्रिंग्स है। लेकिन ksNext का जंग संस्करण अब क्या लौटाता है? एक वस्तु जो "कुंजी इंटरफ़ेस" को संतुष्ट करती है, लेकिन किस मूल्य के साथ? मुझे एक चुनना है।
यह वही है जो हस्ताक्षर को दिखना चाहिए, जहां मूल्य वह प्रकार है जो get_value लौटाता है। मैं केवल बाइट्स ( Vec<u8> ) या स्ट्रिंग निर्दिष्ट कर सकता हूं।
pub fn next(&mut self) -> Box<dyn WriteableKey<Value = Vec<u8>>>;

तो मैं इसे बाइट्स में एकीकृत कर सकता था, लेकिन फिर उपयोगकर्ता को स्वयं स्ट्रिंग में कनवर्ट करना होगा। चूंकि StringKey और BinaryKeys का एकमात्र अंतर उनका set_value और get_value कार्यान्वयन है, यह परिवर्तन उस खोजकर्ता को हटा देगा और मेरे पास मूल रूप से केवल कुंजी फिर से हैं।

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

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

सामान्य तौर पर, टाइप सिस्टम को उपयोगकर्ता का समर्थन करना चाहिए, इसके रास्ते में नहीं आना चाहिए। इसलिए इसे जितना हो सके सिंपल रखें। सबसे आम त्रुटियां हैं:

1. कीसेट में मौजूद किसी कुंजी के लिए कुंजियों का नाम बदलने का प्रयास कर रहा है।
2. मेटा-डेटा कुंजी (या अन्य कॉन्स्ट कुंजी) को बदलने की कोशिश कर रहा है।
3. कुंजी/कीसेट का भ्रमित दोहराव और उनके संदर्भ।
4. कीसेट्स पर पुनरावृति करना जिनका उपयोग कुंजियों को इस तरह से काटने के लिए भी किया जाता है कि पुनरावृत्ति अब सही ढंग से काम नहीं करती है।
5. एक कुंजी/कीसेट मुक्त करना भूल जाना

तो अगर टाइप सिस्टम वहां मदद कर सकता है, तो यह बहुत अच्छा होगा। 5. उम्मीद है कि डिजाइन द्वारा संभव नहीं होगा, 1. और 2 के लिए। आपके अमूर्तता को मदद करनी चाहिए।

बाइनरी/स्ट्रिंग भ्रम वास्तव में एक दुर्लभ त्रुटि है (क्योंकि बाइनरी कुंजियां बहुत ही असामान्य हैं: ज्यादातर फ़ंक्शन पॉइंटर्स को पकड़ने के लिए उपयोग की जाती हैं)।

बीटीडब्ल्यू। यदि आप एपीआई के सुरक्षित उपयोग के बारे में एक डिजाइन निर्णय लिखना चाहते हैं, तो कृपया आगे बढ़ें (डॉक्टर/निर्णय)

उपयोगिता के दृष्टिकोण से यह उस कुंजी को वापस करने के लिए समझ में आता है जिसमें स्ट्रिंग के लिए गेटर होता है, क्योंकि यह सबसे अधिक इस्तेमाल किया जाने वाला संस्करण है।

लेकिन हर बाइट अनुक्रम मान्य यूटीएफ -8 नहीं है, इसलिए यह वास्तव में टाइपएफ़ नहीं होगा, है ना?

AFAIK जंग में मैक्रो सिस्टम बहुत शक्तिशाली है, शायद एक ऐसा फ़ंक्शन लिखने का एक तरीका है जो हमेशा सही प्रकार देता है। उदाहरण के लिए, कोटलिन में मानचित्रों के लिए कुंजी में मान प्रकार को एन्कोड करने की एक तकनीक है। यहाँ पर एपीआई संदर्भ एक उदाहरण है।

वैकल्पिक रूप से एक StringKeySet जो केवल StringKey s को स्वीकार करता है, समझ में आ सकता है, क्योंकि बाइनरी कुंजियाँ इतनी दुर्लभ हैं और अधिकतर कॉन्फ़िगरेशन में उपयोग नहीं की जाती हैं।

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

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

ऐसा करने से पहले, मैं सुझाव देता हूं कि KeySet को सामान्य बनाएं और इसे KeySet<StringKey> रूप में तुरंत चालू करें यदि उपयोगकर्ता सुनिश्चित है कि अंदर केवल StringKeys हैं (उन KeySets के लिए Rust से नहीं आ रहे हैं)। तब यह केवल स्वाभाविक है कि इस पर पुनरावृति करने से केवल StringKeys उत्पन्न होंगे।
यह भी लागू करेगा कि कीसेट टाइप सिस्टम के माध्यम से सजातीय हैं, कम से कम रस्ट उपयोगकर्ताओं द्वारा बनाए गए हैं, जो समग्र रूप से सुरक्षित होंगे।
दुर्लभ मामलों में जहां एक बाइनरी कुंजी की उम्मीद की जाती है, उपयोगकर्ता को is_binary और is_string साथ जांच करनी होगी और फिर कनवर्ट करना होगा, जो एक सुरक्षित विधि कॉल होगा।

कुंजी/कीसेट का भ्रमित दोहराव और उनके संदर्भ।

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

कीसेट्स पर पुनरावृति करना जिनका उपयोग कुंजियों को इस तरह से काटने के लिए भी किया जाता है कि पुनरावृत्ति अब सही ढंग से काम नहीं करती है।

क्या आपका मतलब उस पर पुनरावृति करते हुए कीसेट को संशोधित करना है?

बीटीडब्ल्यू। यदि आप एपीआई के सुरक्षित उपयोग के बारे में एक डिजाइन निर्णय लिखना चाहते हैं, तो कृपया आगे बढ़ें (डॉक्टर/निर्णय)

इसकी सामग्री क्या होगी?

AFAIK जंग में मैक्रो सिस्टम बहुत शक्तिशाली है, शायद एक ऐसा फ़ंक्शन लिखने का एक तरीका है जो हमेशा सही प्रकार देता है।

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

लेकिन हर बाइट अनुक्रम मान्य यूटीएफ -8 नहीं है, इसलिए यह वास्तव में टाइपएफ़ नहीं होगा, है ना?

न तो इलेक्ट्रा के तार या बाइनरी मान को UTF-8 होना चाहिए। इलेक्ट्रा केवल स्ट्रिंग और बाइनरी के बीच निर्णय लेता है (0 बाइट्स हो सकते हैं)।

AFAIK जंग में मैक्रो सिस्टम बहुत शक्तिशाली है, शायद एक ऐसा फ़ंक्शन लिखने का एक तरीका है जो हमेशा सही प्रकार देता है। उदाहरण के लिए, कोटलिन में मानचित्रों के लिए कुंजी में मान प्रकार को एन्कोड करने की एक तकनीक है। यहाँ पर एपीआई संदर्भ एक उदाहरण है।

हमें उपयोगी सुविधाओं में प्रयास करने के लिए भी देखना होगा। बाइनरी कुंजियाँ दुर्लभ हैं।

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

हां, लेकिन मैं स्ट्रिंगकीसेट को सामान्य कीसेट के रूप में देखूंगा।

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

हां, लेकिन जैसा कि कहा गया है कि यह एक छोटी सी समस्या है। जो लोग बाइनरी डेटा (जैसे फ़ंक्शन एड्रेस) स्टोर करते हैं, उन्हें पता चलेगा कि कुंजी कैसे डाली जाए (यदि इसके बारे में कुछ दस्तावेज है)।

ऐसा करने से पहले, मेरा सुझाव है कि KeySet को सामान्य बनाएं और इसे KeySet के रूप में इंस्टेंट करेंयदि उपयोगकर्ता सुनिश्चित है कि अंदर केवल StringKeys हैं (उन KeySets के लिए Rust से नहीं आ रहे हैं)। तब यह केवल स्वाभाविक है कि इस पर पुनरावृति करने से केवल StringKeys उत्पन्न होंगे।

यह केवल नकली सुरक्षा होगी क्योंकि कीसेट केडीबी (बाहरी रूप से) से आते हैं और उनमें किसी भी मामले में बाइनरी डेटा हो सकता है। इस प्रकार मैं KeySet गैर-जेनेरिक रखना पसंद करता हूं।

यदि आप जेनरिक के साथ खेलना चाहते हैं, तो गेटर्स और सेटर्स प्रदान करें जो कीसेट्स को (जेनेरिक) डेटा संरचनाओं में परिवर्तित करते हैं। उदाहरण के लिए Vec<i32> के पूर्णांकों की एक इलेक्ट्रा सरणी।

क्या आपका मतलब उस पर पुनरावृति करते हुए कीसेट को संशोधित करना है?

हाँ cut कीसेट को संशोधित करता है। सामान्य तौर पर इटरेटर ऐसा करने के लिए सुरक्षित होते हैं लेकिन कई लोगों को इसे ठीक करने में समस्या होती है।

इसकी सामग्री क्या होगी?

हम यहां क्या चर्चा करते हैं और आपने इसे कैसे डिजाइन किया, इसका एक सारांश।

मुझे लगता है कि कीसेट का "वर्तमान" डिज़ाइन जिसमें कुछ भी हो सकता है और ठोस कुंजी प्रकार एक साथ काम नहीं करते हैं, कम से कम अच्छी तरह से नहीं।

मैं सहमत हूँ।

लेकिन मैं मैक्रोज़ में देख लूंगा।

कृपया इसे प्राथमिकता न दें।

न तो इलेक्ट्रा के तार या बाइनरी मान को UTF-8 होना चाहिए।

फिर हमें त्वरित खोज के अनुसार String बजाय OsString या CString उपयोग करना चाहिए।

न तो इलेक्ट्रा के तार या बाइनरी मान को UTF-8 होना चाहिए।

फिर हमें त्वरित खोज के अनुसार String बजाय OsString या CString उपयोग करना चाहिए।

अभी मैं रस्ट के String (जो कि UTF-8 है) से CString कनवर्ट कर रहा हूं, इसे इलेक्ट्रा पर पास करने से पहले। तर्क यह है कि String डिफ़ॉल्ट स्ट्रिंग है और अधिकांश अन्य पुस्तकालय इसके साथ काम करने की उम्मीद करते हैं।
मैं इसके बजाय उच्च-स्तरीय एपीआई को CString s के लिए पूछ सकता हूं और वापस कर सकता हूं, जैसे कि उपयोगकर्ता को रूपांतरण कोड से निपटना होगा, अगर उन्हें String । यह एक पतली एपीआई और कम त्रुटि प्रबंधन के लिए तैयार करेगा जिससे निपटने की आवश्यकता है। मुझे लगता है कि यह नीचे आता है कि अधिकांश उपयोगकर्ता एपीआई का उपयोग कैसे करना चाहेंगे, जिसमें मुझे इतनी अंतर्दृष्टि नहीं है।

मैं सहमत हूं कि भाषाओं के सबसे सामान्य स्ट्रिंग प्रकार को वापस करना सबसे अच्छा है। गैर-UTF8 स्ट्रिंग दुर्लभ होनी चाहिए (शायद बायनेरिज़ से भी अधिक दुर्लभ)।

मैं सहमत हूं कि भाषाओं के सबसे सामान्य स्ट्रिंग प्रकार को वापस करना सबसे अच्छा है। गैर-UTF8 स्ट्रिंग दुर्लभ होनी चाहिए (शायद बायनेरिज़ से भी अधिक दुर्लभ)।

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

दूसरी संभावना एक स्ट्रिंग लेने वाले सभी सेट फ़ंक्शंस से एक त्रुटि वापस करना है। लेकिन फिर उपयोगकर्ताओं को इस NulError हर समय निपटना पड़ता है और यह व्यावहारिक रूप से कभी वापस भी नहीं आता है।

keyNew आवंटन त्रुटि पर एक पूर्ण सूचक वापस कर सकता है। जंग में मैं या तो स्पष्ट त्रुटियां या घबराहट वापस कर सकता हूं, लेकिन एक निहित शून्य नहीं। सिग्नलिंग त्रुटियों पर जंग दस्तावेज़ स्मृति से बाहर एक भयावह त्रुटि और इस मामले में stdlib abort s को मानता है। ऐसा लगता है कि जावा बाध्यकारी इस मामले को संभाल नहीं रहा है, इसलिए मुझे लगता है कि यह प्रक्रिया से बाहर निकल जाएगा, क्योंकि NullPointerException फेंक दिया गया है।
क्या आप सहमत हैं कि यहां आतंक को कॉल करना सबसे अच्छा है (निरस्त करने से विनाशकों को चलने की अनुमति नहीं मिलती)?

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

हाँ, वाजिब है।

क्या आप सहमत हैं कि यहां आतंक को कॉल करना सबसे अच्छा है (निरस्त करने से विनाशकों को चलने की अनुमति नहीं मिलती)?

हां, अगर मॉलोक विफल हो जाए तो घबराना समझ में आता है। (रस्ट के मामले में जैसा कि stdlib वही करेगा। C में stdlib निरस्त नहीं होता है, इसलिए C-Elektra भी निरस्त नहीं होता है)।

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

https://crates.io पर प्रकाशन के लिए एक GitHub खाते की आवश्यकता होती है। क्रेट के स्वामित्व को खातों के बीच स्थानांतरित किया जा सकता है, इसलिए मैं अभी के लिए अपने स्वयं का उपयोग कर सकता हूं। या कोई और लॉगिन कर सकता है और मुझे एपीआई टोकन भेज सकता है जो प्रकाशित करने के लिए आवश्यक है।

उन्हें crates.io पर प्रकाशित करने के लिए धन्यवाद: स्पार्कल:

मैं संस्करण को सीधे इलेक्ट्रा से जोड़ूंगा, क्योंकि वे इलेक्ट्रा के रेपो का हिस्सा हैं। लेकिन यह वास्तव में महत्वपूर्ण नहीं है: यदि crates.io में आमतौर पर कुछ विशिष्ट संस्करण स्कीमा होता है, तो वहां जो आम है उससे बेहतर चिपके रहें।

या कोई और लॉगिन कर सकता है और मुझे एपीआई टोकन भेज सकता है जो प्रकाशित करने के लिए आवश्यक है।

मैंने एक अधिकृत लॉग इन किया। मैं आपको एपीआई टोकन भेजूंगा।

मैं संस्करण को सीधे इलेक्ट्रा से जोड़ूंगा, क्योंकि वे इलेक्ट्रा के रेपो का हिस्सा हैं। लेकिन यह वास्तव में महत्वपूर्ण नहीं है: यदि crates.io में आमतौर पर कुछ विशिष्ट संस्करण स्कीमा होता है, तो वहां जो आम है उससे बेहतर चिपके रहें।

इसके साथ बड़ी समस्या है, सिमेंटिक वर्जनिंग के अनुसार, अगर हमें बाइंडिंग में ब्रेकिंग चेंज करना है तो हम उसके अनुसार वर्जन को अपग्रेड नहीं कर सकते। इसलिए हम केवल ब्रेकिंग परिवर्तन ही कर सकते हैं जब इलेक्ट्रा उन्हें करता है।

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

आप सही कह रहे हैं, मैंने बाद में प्रमुख संस्करणों को बढ़ाने के बारे में नहीं सोचा था।

अभी, wrapper.h केडीबी हेडर को शामिल करने और इसके लिए बाइंडिंग जेनरेट करने के लिए #include "kdb.h" निर्दिष्ट करता है। लेकिन क्लैंग को हेडर नहीं मिलता है (उदाहरण के लिए ubuntu:18.10 )। इसलिए मुझे इसे बनाने के लिए /usr/include/elektra को शामिल करने के लिए क्लैंग को स्पष्ट रूप से बताना होगा।
क्या इलेक्ट्रा हमेशा /usr/include/elektra में स्थापित होता है ताकि यह समाधान अधिकांश वितरणों के लिए काम करे?

क्या इलेक्ट्रा हमेशा /usr/include/elektra में स्थापित होता है ताकि यह समाधान अधिकांश वितरणों के लिए काम करे?

हां, क्योंकि एक और पुस्तकालय है (मुझे केर्बरोस से लगता है) जो /usr/include/kdb.h का उपयोग करता है।

अभी के लिए /usr/include/elektra को शामिल पथ का हिस्सा बनना है, लेकिन AFAIK हम इसे बदलना चाहते हैं ताकि इसके बजाय #include <elektra/kdb.h> का उपयोग किया जा सके।

क्या इलेक्ट्रा हमेशा /usr/include/elektra में स्थापित होता है ताकि यह समाधान अधिकांश वितरणों के लिए काम करे?

डिफ़ॉल्ट रूप से यह/usr/स्थानीय/शामिल/इलेक्ट्रा है लेकिन अधिकांश वितरण/usr/include/elektra का उपयोग करेंगे लेकिन इसकी कोई गारंटी नहीं है। इसलिए बिल्ड सिस्टम में आमतौर पर हेडर फाइलों का पता लगाने के लिए कुछ समर्थन होता है। इलेक्ट्रा cmake और pkg-config को सपोर्ट करता है।

क्या आप इस बारे में कुछ संदर्भ दे सकते हैं कि आपको इसकी आवश्यकता कहां है?

की जगह इस्तेमाल किया जा सकता है।

बजाय इस्तेमाल किया जाना चाहिए। प्रासंगिक पीआर #2880 . है

#include <elektra/kdb.h> बदलना निश्चित रूप से उबंटू में काम करता है। तो फिर मैं /usr/include/elektra को शामिल करने के बजाय उस पथ में बदल

#include <elektra/kdb.h> बदलना निश्चित रूप से उबंटू में काम करता है। तो फिर मैं /usr/include/elektra को शामिल करने के बजाय उस पथ में बदल

यह शायद सभी शीर्षकों के लिए काम नहीं करेगा, कुछ /usr/include/elektra शामिल पथ में होने पर भरोसा करते हैं।

संभवतः सबसे अच्छी बात (यदि आपके लिए संभव हो) pkg-config या cmake --find-package का उपयोग इलेक्ट्रा फ़ाइलों को खोजने के लिए करना होगा (IMO cmake बेहतर काम करता है)।

क्या आप इस बारे में कुछ संदर्भ दे सकते हैं कि आपको इसकी आवश्यकता कहां है?

तो यदि कोई उपयोगकर्ता अपनी मशीन पर इलेक्ट्रा संकलित करता है, तो उसे केवल जंग/कार्गो की आवश्यकता होती है और बाइंडिंग का उपयोग कर सकता है। लेकिन अन्य उपयोग का मामला, जिसके लिए crates.io का उपयोग किया जाना चाहिए, अगर कोई अपने पैकेज मैनेजर के माध्यम से इलेक्ट्रा (और हेडर) स्थापित करता है। फिर पुस्तकालय और शीर्षलेख उपलब्ध हैं। अब जब उपयोगकर्ता अपनी निर्भरता में इलेक्ट्रा शामिल करता है और कार्गो elektra-sys टोकरा लाएगा। यह केवल बिल्ड स्क्रिप्ट पर निर्भर करता है और बाइंडिंग उत्पन्न करने के लिए क्लैंग करता है। लेकिन क्लैंग को किसी तरह kdb.h खोजने की जरूरत है। इसलिए मैं या तो अतिरिक्त हार्डकोडेड पास कर सकता हूं जिसमें बिल्ड स्क्रिप्ट में पथ शामिल हैं या सीधे #include ... स्टेटमेंट को संशोधित करें।

संभवतः सबसे अच्छी बात (यदि आपके लिए संभव हो) pkg-config या cmake --find-package का उपयोग इलेक्ट्रा फ़ाइलों को खोजने के लिए करना होगा (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 जोड़ा। यदि इसे जोड़ा जाता है, तो यह इलेक्ट्रा की खोज करेगा और प्रदान किए गए समावेशी का उपयोग करेगा। अन्यथा यह आपके द्वारा नामित दो निर्देशिकाओं में खोज करेगा।

बाइंडिंग अब प्रकाशित हुई हैं: इलेक्ट्रा और इलेक्ट्रा-एसआईएस : स्माइली:

docs.rs बिल्ड वातावरण में libelektra की अनुपलब्ध सिस्टम निर्भरता के कारण, दस्तावेज़ीकरण नहीं बना। साथ ही, वे 30 सितंबर को बिल्ड परिवेश को बदल देंगे।
मैंने एक निर्भरता के रूप में libelektra जोड़ने का अनुरोध प्रस्तुत किया ताकि यह सितंबर 30th पर सही ढंग से निर्माण हो सके। उन्होंने पैकेज को मौजूदा परिवेश में भी जोड़ा, इसलिए डॉक्स अब उपलब्ध हैं: +1:

मुझे लगता है कि #2980 के विलय के बाद इस मुद्दे को बंद किया जा सकता है।

बहुत बढ़िया, उन्होंने सुपर-फास्ट प्रतिक्रिया दी। क्या यह एक समस्या होगी कि वे इसे काफी पुराने परिवाद के साथ बनाते हैं? (मैंने यह नहीं देखा कि कौन सा संस्करण है लेकिन अगर वे इसे पैकेज मैनेजर से शामिल करते हैं तो यह निश्चित रूप से 0.9 से अधिक पुराना होगा।)

elektra टोकरा के लिए कोई समस्या नहीं है, क्योंकि यह केवल दस्तावेज़ीकरण है। elektra-sys मुझे लगता है कि इसमें इलेक्ट्रा का जो भी संस्करण है वह वर्तमान के बजाय उत्पन्न किया गया था। लेकिन मुझे लगता है कि शायद ही कोई रैपर की जगह रॉ बाइंडिंग का इस्तेमाल करेगा। तो दस्तावेज़ों को स्वचालित रूप से बनाने के लिए एक छोटा व्यापार बंद।

क्या आप हमारे रेपो में दस्तावेज़ के लिंक जोड़ सकते हैं?

ऐसा लगता है कि इलेक्ट्रा-एसआईएस वैसे भी लगभग अनुपयोगी है। यह सैकड़ों प्रतीकों को दिखाता है जिनका इलेक्ट्रा से कोई लेना-देना नहीं है। इसके अलावा व्यक्तिगत कार्यों के लिए कोई दस्तावेज नहीं है, उदाहरण के लिए

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

क्या आप हमारे रेपो में दस्तावेज़ के लिंक जोड़ सकते हैं?

हाँ, मैं इसे मौजूदा PR . में जोड़ दूँगा

ऐसा लगता है कि इलेक्ट्रा-एसआईएस वैसे भी लगभग अनुपयोगी है। यह सैकड़ों प्रतीकों को दिखाता है जिनका इलेक्ट्रा से कोई लेना-देना नहीं है।

मैं इस पर गौर करूंगा।

इसके अलावा व्यक्तिगत कार्यों के लिए कोई दस्तावेज नहीं है, उदाहरण के लिए

-sys क्रेट के लिए यह विशिष्ट है कि उनके पास दस्तावेज़ नहीं है (उदाहरण के लिए openssl-sys ), क्योंकि वे सी समकक्ष के एक-से-एक अनुवाद हैं। तो किसी को सीधे सी डॉक्टर को देखना होगा। मुझे सभी दस्तावेज़ों की प्रतिलिपि भी देनी होगी, जो एक और रखरखाव बोझ जोड़ता है। हालांकि मैं मुख्य दस्तावेज़ पृष्ठ पर https://doc.libelektra.org/api/current/html/index.html से लिंक कर सकता हूं।

ऐसा लगता है कि इलेक्ट्रा-एसआईएस वैसे भी लगभग अनुपयोगी है। यह सैकड़ों प्रतीकों को दिखाता है जिनका इलेक्ट्रा से कोई लेना-देना नहीं है।

मैं इस पर गौर करूंगा।

इसे #2980 में ठीक किया गया है, और अगली बार जब हम टोकरा प्रकाशित करेंगे, तो इसे docs.rs पर ठीक कर दिया जाएगा।

हालांकि मैं मुख्य दस्तावेज़ पृष्ठ पर https://doc.libelektra.org/api/current/html/index.html से लिंक कर सकता हूं।

हाँ अच्छा उपाए!