शाखा 5.5 के ढांचे के भीतर SObjectizer का पहला संस्करण चार साल पहले - अक्टूबर 2014 की शुरुआत में थोड़ा अधिक जारी किया गया था। और आज अगला संस्करण 5.5.23 की संख्या के तहत जारी किया गया था , जो कि संभवतः संभवतः, SObjectizer-5.5 के इतिहास को बंद कर देगा। मेरी राय में, पिछले चार वर्षों में जो कुछ किया गया है उसे देखने और देखने का यह एक बड़ा कारण है।

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

शायद किसी को पुरातत्व की दृष्टि से ऐसी कहानी में दिलचस्पी होगी। और किसी को, शायद, सी + + के लिए अपने स्वयं के अभिनेता ढांचे को विकसित करने के रूप में इस तरह के संदिग्ध साहसिक से बचना होगा;)

पुराने सी ++ संकलक की भूमिका के बारे में थोड़ा गीतात्मक विषयांतर

SObjectizer-5 का इतिहास 2010 के मध्य में शुरू हुआ। उसी समय, हमने तुरंत C ++ 0x पर ध्यान केंद्रित किया। पहले से ही 2011 में, उत्पादन कोड लिखने के लिए SObjectizer-5 के पहले संस्करणों का उपयोग किया जाने लगा। यह स्पष्ट है कि हमारे पास सामान्य C ++ 11 समर्थन के साथ संकलक नहीं थे।

लंबे समय तक हम "आधुनिक सी ++" की सभी विशेषताओं का पूरी तरह से उपयोग नहीं कर सके: वैरेडिक टेम्प्लेट, नोएक्ससेप्ट, कॉन्स्टैक्स, आदि। यह एसओबीजेनाइजर एपीआई को प्रभावित नहीं कर सका। और यह बहुत, बहुत लंबे समय के लिए प्रभावित हुआ। इसलिए, यदि किसी विशेषता का विवरण पढ़ने के दौरान आपके पास एक प्रश्न है "यह पहले क्यों नहीं किया गया है?", तो इस प्रश्न का उत्तर सबसे अधिक संभावना है: "क्योंकि यह पहले संभव नहीं था"।

पिछले दिनों SObjectizer-5.5 में क्या दिखाई और / या बदला है?

इस खंड में, हम कई विशेषताओं पर जाएंगे, जो कि SObjectizer पर महत्वपूर्ण प्रभाव डालती हैं। इस सूची में क्रम यादृच्छिक है और वर्णित विशेषताओं के "महत्व" या "वजन" से संबंधित नहीं है।

So_5 :: rt नाम स्थान को अस्वीकार करना

क्या था?

प्रारंभ में, पांचवें SObjectizer में, SObjectizer रनटाइम से संबंधित सब कुछ so_5 :: rt नाम स्थान के अंदर परिभाषित किया गया था। उदाहरण के लिए, हमारे पास so_5 :: rt :: environment_t, so_5 :: rt :: agent_t, so_5 :: rt :: message_t, आदि हैं। उदाहरण के लिए, SO-5.5.0 से पारंपरिक HelloWorld उदाहरण में आप क्या देख सकते हैं:

#include <so_5/all.hpp> class a_hello_t : public so_5::rt::agent_t { public: a_hello_t( so_5::rt::environment_t & env ) : so_5::rt::agent_t( env ) {} void so_evt_start() override { std::cout << "Hello, world! This is SObjectizer v.5." << std::endl; so_environment().stop(); } void so_evt_finish() override { std::cout << "Bye! This was SObjectizer v.5." << std::endl; } }; int main() { try { so_5::launch( []( so_5::rt::environment_t & env ) { env.register_agent_as_coop( "coop", new a_hello_t( env ) ); } ); } catch( const std::exception & ex ) { std::cerr << "Error: " << ex.what() << std::endl; return 1; } return 0; } 

संक्षिप्त नाम "आरटी" रन-टाइम के लिए है। और यह हमें प्रतीत हुआ कि "so_5 :: rt" रिकॉर्ड "so_5 :: runtime" की तुलना में बहुत बेहतर और अधिक व्यावहारिक है।

लेकिन यह पता चला कि कई लोगों के लिए "आरटी" केवल "वास्तविक समय" है और कुछ नहीं। और "रनटाइम" के लिए एक शॉर्टहैंड के रूप में "आरटी" का उपयोग उनकी भावनाओं का इतना उल्लंघन करता है कि कभी-कभी RuNet में SObjectizer के संस्करणों की घोषणाएं "वास्तविक समय" के अलावा "rt" की अनुमति योग्य व्याख्या के विषय पर होलीवर में बदल जाती हैं।

अंत में, हम इससे थक गए हैं। और हमने सिर्फ so_5 :: rt नेमस्पेस अनपेक्षित किया।

क्या बन गया है?

सब कुछ जो "so_5 :: rt" के अंदर परिभाषित किया गया था, बस "so_5" में बदल गया। परिणामस्वरूप, वही HelloWorld अब इस तरह दिखता है:

 #include <so_5/all.hpp> class a_hello_t : public so_5::agent_t { public: a_hello_t( context_t ctx ) : so_5::agent_t( ctx ) {} void so_evt_start() override { std::cout << "Hello, world! This is SObjectizer v.5 (" << SO_5_VERSION << ")" << std::endl; so_environment().stop(); } void so_evt_finish() override { std::cout << "Bye! This was SObjectizer v.5." << std::endl; } }; int main() { try { so_5::launch( []( so_5::environment_t & env ) { env.register_agent_as_coop( "coop", env.make_agent<a_hello_t>() ); } ); } catch( const std::exception & ex ) { std::cerr << "Error: " << ex.what() << std::endl; return 1; } return 0; } 

लेकिन पुराने नाम "so_5 :: rt" वैसे भी उपलब्ध थे, जो सामान्य रूप से s (टाइपेडिफ्स) के माध्यम से उपलब्ध थे। इसलिए SO-5.5 के पहले संस्करणों के लिए लिखा गया कोड SO-5.5 के हाल के संस्करणों में भी काम करने योग्य है।

अंत में, so_5 :: rt नाम स्थान 5.6 संस्करण में हटा दिया जाएगा।

इसका क्या प्रभाव पड़ा?

संभवतः, SObjectizer पर कोड अब अधिक पठनीय है। फिर भी, so_5 :: send () so_5 :: rt :: send () से बेहतर माना जाता है।

खैर, यहाँ, SObjectizer डेवलपर्स के साथ की तरह, सिरदर्द कम हो गया है। एक समय में SObjectizer की घोषणाओं के आस-पास बहुत सारे खाली चटकारे और अनावश्यक तर्क थे (सवालों से शुरू होकर "सामान्य रूप से C ++ में अभिनेताओं की आवश्यकता क्यों है" और "आप संस्थाओं का नाम लेने के लिए पास्कलकेस का उपयोग क्यों नहीं करते") के साथ समाप्त होते हैं। एक ज्वलनशील विषय कम हो गया और यह अच्छा था :)

संदेश भेजने और संदेश संचालकों के विकास को सरल बनाएं

क्या था?

SObjectizer-5.5 के पहले संस्करणों में भी, डिलीवर_मेसेज पद्धति का उपयोग करके सामान्य संदेश भेजा गया था, जिसे प्राप्तकर्ता के mbox पर कॉल करना था। एक लंबित या आवधिक संदेश भेजने के लिए, प्रकार के पर्यावरण .t के ऑब्जेक्ट पर single_timer / schedule_timer को कॉल करना आवश्यक था। और पहले से ही एक अन्य एजेंट के लिए एक तुल्यकालिक अनुरोध भेजने के लिए आम तौर पर संचालन की एक पूरी श्रृंखला की आवश्यकता होती है। यहाँ, उदाहरण के लिए, यह सब चार साल पहले कैसे देखा गया होगा (std :: make_unique (), जो अभी तक C ++ 11 में उपलब्ध नहीं था, पहले से ही उपयोग किया जाता है):

 //   . mbox->deliver_message(std::make_unique<my_message>(...)); //   . env.single_timer(std::make_unique<my_message>(...), mbox, std::chrono::seconds(2)); //   . auto timer_id = env.schedule_timer( std::make_unique<my_message>(...), mbox, std::chrono::seconds(2), std::chrono::seconds(5)); //         10 . auto reply = mbox->get_one<std::string>() .wait_for(std::chrono::seconds(10)) .sync_get(std::make_unique<my_message>(...)); 

इसके अलावा, SObjectizer में संदेश संचालकों का प्रारूप 5.5 संस्करण तक विकसित हो गया है। अगर शुरू में SObjectizer-5 में सभी हैंडलर का प्रारूप होना चाहिए:

 void evt_handler(const so_5::event_data_t<Msg> & cmd); 

फिर समय के साथ अनुमत स्वरूपों में कुछ और जोड़े गए:

 //  ,  Msg --  ,   . ret_value evt_handler(const Msg & msg); ret_value evt_handler(Msg msg); //  ,     . ret_value evt_handler(); 

नए हैंडलर प्रारूप का व्यापक रूप से उपयोग किया जाता है लगातार पेंटिंग "const so_5 :: event_data_t <Msg> &" अभी भी एक खुशी है। लेकिन, दूसरी ओर, सरल प्रारूप टेम्पलेट एजेंटों के अनुकूल नहीं थे। उदाहरण के लिए:

 template<typename Msg_To_Process> class my_actor : public so_5::agent_t { void on_receive(const Msg_To_Process & msg) { // Oops! ... } }; 

ऐसा टेम्पलेट एजेंट केवल तभी काम करेगा जब Msg_To_Process एक संदेश प्रकार है, न कि सिग्नल प्रकार।

क्या बन गया है?

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

फ़ंक्शंस भेजने के अलावा, request_future / request_value फ़ंक्शंस दिखाई दिए, जो एजेंटों के बीच सिंक्रोनस इंटरैक्शन के लिए डिज़ाइन किए गए हैं।

परिणामस्वरूप, अब संदेश भेजना इस प्रकार है:

 //   . so_5::send<my_message>(mbox, ...); //   . so_5::send_delayed<my_message>(env, mbox, std::chrono::seconds(2), ...); //   . auto timer_id = so_5::send_periodic<my_message>( env, mbox, std::chrono::seconds(2), std::chrono::seconds(5), ...); //         10 . auto reply =so_5::request_value<std::string, my_message>(mbox, std::chrono::seconds(10), ...); 

संदेश संचालकों के लिए एक और संभावित प्रारूप जोड़ा गया है। इसके अलावा, यह प्रारूप है जिसे अगले मुख्य रिलीज में SObjectizer के मुख्य एक के रूप में छोड़ दिया जाएगा (और, संभवतः, केवल एकमात्र)। यह निम्न प्रारूप है:

 ret_type evt_handler(so_5::mhood_t<Msg> cmd); 

जहाँ Msg एक संदेश प्रकार या एक संकेत प्रकार हो सकता है।

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

 void my_agent::on_msg(mhood_t<Some_Msg> cmd) { ... // -  . //       . so_5::send(another_agent, std::move(cmd)); } 

इसका क्या प्रभाव पड़ा?

भेजने के कार्यों और संदेश हैंडलर की उपस्थिति mhood_t <Msg> प्राप्त कर रहे हैं, हम कह सकते हैं, मौलिक रूप से उस कोड को बदल दिया है जिसमें संदेश भेजे और संसाधित किए जाते हैं। यह केवल ऐसा मामला है जब यह केवल इस बात पर पछतावा होता है कि SObjectizer -5 पर काम की शुरुआत में हमारे पास न तो वैरिएड टेम्प्लेट समर्थन के साथ संकलक थे, और न ही उनका उपयोग करने में अनुभव। भेजें कार्यों और mhood_t का परिवार शुरू से ही होना चाहिए था। लेकिन इतिहास जैसे-जैसे विकसित हुआ है ...

कस्टम संदेश प्रकारों के लिए समर्थन

क्या था?

प्रारंभ में, सभी भेजे गए संदेश so_5 :: message_t वर्ग के वंशज वर्ग होने चाहिए थे। उदाहरण के लिए:

 struct my_message : public so_5::message_t { ... //  my_message. my_message(...) : ... {...} //   my_message. }; 

जबकि पांचवें एसोबिजाइज़र का उपयोग केवल स्वयं द्वारा किया गया था, इससे कोई प्रश्न नहीं उठा। खैर, इस तरह और उस तरह।

लेकिन जैसे ही थर्ड-पार्टी यूजर्स को सोबजेलाइज़र में दिलचस्पी होने लगी, हम तुरंत एक नियमित रूप से दोहराए जाने वाले सवाल पर आ गए: "लेकिन मुझे निश्चित रूप से so_5 :: message_t से संदेश प्राप्त करना होगा?" यह मुद्दा उन स्थितियों में विशेष रूप से प्रासंगिक था जहां प्रकार की वस्तुओं को संदेश के रूप में भेजना आवश्यक था जो उपयोगकर्ता बिल्कुल भी प्रभावित नहीं कर सकता था। मान लीजिए कि कोई उपयोगकर्ता SObjectizer और कुछ अन्य बाहरी लाइब्रेरी का उपयोग करता है। और इस बाहरी पुस्तकालय में एक निश्चित प्रकार एम है, जिन वस्तुओं को उपयोगकर्ता संदेशों के रूप में भेजना चाहते हैं। दोस्तों को M और so_5 :: message_t टाइप करने के लिए ऐसी स्थितियों में अच्छी तरह से और कैसे? केवल अतिरिक्त आवरण जो उपयोगकर्ता को मैन्युअल रूप से लिखना था।

क्या बन गया है?

हमने संदेश भेजने वाले को Sbjectizer-5.5 में संदेश भेजने की क्षमता जोड़ी है, भले ही संदेश प्रकार so_5 :: message_t से विरासत में नहीं मिला हो। यानी अब उपयोगकर्ता आसानी से लिख सकता है:

 so_5::send<std::string>(mbox, "Hello, World!"); 

So_5 :: message_t वैसे भी हुड के नीचे रहता है, बस टेम्पलेट मैजिक भेजने के कारण () समझता है कि std :: string को विरासत से so_5 :: message_t नहीं है और एक साधारण std नहीं है :: string का निर्माण सेंड के अंदर किया गया है, लेकिन so_5 से एक विशेष वारिस :: message_t, जिसके अंदर उपयोगकर्ता का std :: string पहले से ही स्थित है।

इसी तरह के टेम्पलेट जादू सदस्यता के लिए लागू होते हैं। जब SObjectizer प्रपत्र का संदेश हैंडलर देखता है:

 void evt_handler(mhood_t<std::string> cmd) {...} 

तब SObjectizer समझता है कि वास्तव में एक विशेष संदेश std :: string object के साथ आएगा। और आपको इस विशेष संदेश से stler :: string के लिंक को पास करने के साथ हैंडलर को कॉल करने की आवश्यकता है।

इसका क्या प्रभाव पड़ा?

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

परस्पर संदेश

क्या था?

प्रारंभ में, SObjectizer-5 में, केवल 1: N इंटरैक्शन मॉडल का उपयोग किया गया था। यानी भेजे गए संदेश में एक से अधिक प्राप्तकर्ता हो सकते हैं (या एक से अधिक भी हो सकते हैं)। भले ही एजेंटों को 1: 1 मोड में बातचीत करने की आवश्यकता होती है, फिर भी वे एक बहु-निर्माता / बहु-उपभोक्ता मेलबॉक्स के माध्यम से संचार करते हैं। यानी 1 में: एन मोड, बस एन इस मामले में कड़ाई से एक इकाई थी।

ऐसी परिस्थितियों में जहां एक संदेश एक से अधिक प्राप्तकर्ता एजेंट द्वारा प्राप्त किया जा सकता है, भेजे गए संदेशों को अपरिवर्तनीय होना चाहिए। इसीलिए संदेश संचालकों के निम्नलिखित प्रारूप थे:

 //       . ret_type evt_handler(const event_data_t<Msg> & cmd); //       . ret_type evt_handler(const Msg & msg); //    . //        . ret_type evt_handler(Msg msg); 

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

 struct process_image : public so_5::message_t { std::unique_ptr<gif_image> image_; process_image(std::unique_ptr<gif_image> image) : image_{std::move(image)) {} }; 

अधिक सटीक रूप से, ऐसा संदेश भेजा जा सकता है। लेकिन इसे एक स्थिर वस्तु के रूप में प्राप्त करने के बाद, यह process_image :: image_ की सामग्री को स्वयं से निकालना संभव नहीं होगा। मुझे इस तरह की विशेषता को उत्परिवर्तित करना होगा। लेकिन तब हम संकलक से नियंत्रण खो देंगे यदि process_image 1: N मोड में भेजे गए किसी कारण के लिए है।

क्या बन गया है?

SObjectizer-5.5 में, परस्पर संदेश भेजने और प्राप्त करने की क्षमता को जोड़ा गया है। उसी समय, उपयोगकर्ता को विशेष रूप से संदेश भेजना चाहिए जब भेजना और जब सदस्यता लेना हो।

उदाहरण के लिए:

 //    . so_5::send<my_message>(mbox, ...); //     my_message. so_5::send<so_5::mutable_msg<my_message>>(mbox, ...); ... //     . void my_agent::on_some_event(mhood_t<my_message> cmd) {...} //      my_message. void my_agent::on_another_event(mhood_t<so_5::mutable_msg<my_message>> cmd) {...} 

SObjectizer के लिए, my_message और mutable_msg <my_message> दो भिन्न प्रकार के संदेश हैं।

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

इसका क्या प्रभाव पड़ा?

परिवर्तनशील संदेशों के साथ यह अप्रत्याशित रूप से बदल गया। हमने उन्हें C ++ रूस -2017 में SObjectizer की एक रिपोर्ट के आधार पर चर्चा के परिणामस्वरूप SObjectizer में जोड़ा। इस भावना के साथ, "ठीक है, अगर वे पूछते हैं, तो किसी को इसकी आवश्यकता है, इसलिए यह एक कोशिश के लायक है।" खैर, उन्होंने व्यापक मांग की उम्मीद के बिना किया। यद्यपि इसके लिए मुझे बहुत लंबे समय तक "स्मोक बैम्बू" रखना था, इससे पहले कि मैं यह सोचता कि एसओ -५५ में बिना टूटे संगतता के साथ परस्पर संदेश कैसे जोड़ा जाए।

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

पदानुक्रमित राज्य मशीन एजेंट

क्या था?

SObjectizer में एजेंट मूल रूप से राज्य मशीन थे। एजेंटों को स्पष्ट रूप से राज्यों का वर्णन करना और विशिष्ट राज्यों में संदेशों की सदस्यता लेना था।
उदाहरण के लिए:

 class worker : public so_5::agent_t { state_t st_free{this, "free"}; state_t st_bufy{this, "busy"}; ... void so_define_agent() override { //     st_free. so_subscribe(mbox).in(st_free).event(...); //     st_busy. so_subscribe(mbox).in(st_busy).event(...); ... } }; 

लेकिन ये साधारण राज्य मशीनें थीं। राज्यों को एक दूसरे में निहित नहीं किया जा सकता था। राज्य के प्रवेश और निकास हैंडलर के लिए कोई समर्थन नहीं था। राज्य में बिताए समय पर कोई प्रतिबंध नहीं था।

यहां तक ​​कि राज्य मशीनों के लिए इस तरह का सीमित समर्थन सुविधाजनक था और हमने इसे एक वर्ष से अधिक समय तक इस्तेमाल किया। लेकिन एक समय पर, हम और अधिक चाहते थे।

क्या बन गया है?

SObjectizer पदानुक्रमित राज्य मशीनों के लिए समर्थन का परिचय देता है।

अब राज्यों को एक दूसरे में बांटा जा सकता है। माता-पिता के राज्यों के इवेंट हैंडलर बच्चे राज्यों द्वारा "विरासत में" प्राप्त होते हैं।

एक राज्य में प्रवेश करने और बाहर निकलने के लिए हैंडलर्स का समर्थन किया जाता है।

एजेंट द्वारा राज्य में रहने के समय पर एक सीमा निर्धारित करना संभव है।

राज्य के लिए एक इतिहास रखना संभव है।

आदेश निराधार न होने के लिए, यहां एक एजेंट का उदाहरण दिया गया है जो एक जटिल श्रेणीबद्ध राज्य मशीन नहीं है (मानक उदाहरण से कोड ब्लिंकलिंग है)

 class blinking_led final : public so_5::agent_t { state_t off{ this }, blinking{ this }, blink_on{ initial_substate_of{ blinking } }, blink_off{ substate_of{ blinking } }; public : struct turn_on_off final : public so_5::signal_t {}; blinking_led( context_t ctx ) : so_5::agent_t{ ctx } { this >>= off; off.just_switch_to< turn_on_off >( blinking ); blinking.just_switch_to< turn_on_off >( off ); blink_on .on_enter( []{ std::cout << "ON" << std::endl; } ) .on_exit( []{ std::cout << "off" << std::endl; } ) .time_limit( std::chrono::milliseconds{1250}, blink_off ); blink_off .time_limit( std::chrono::milliseconds{750}, blink_on ); } }; 

हमने पहले ही एक अलग लेख में यह सब वर्णित किया है, इसे दोहराने की कोई आवश्यकता नहीं है।

वर्तमान में ऑर्थोगोनल राज्यों के लिए कोई समर्थन नहीं है। लेकिन इस तथ्य के दो स्पष्टीकरण हैं। सबसे पहले, हमने इस समर्थन को बनाने की कोशिश की और कई कठिनाइयों का सामना किया, जिनमें से बहुत अधिक हमें बहुत महंगा लग रहा था। और, दूसरी बात, किसी ने अभी तक रूढ़िवादी राज्यों के लिए नहीं कहा है। जब पूछा गया, तो इस विषय पर वापस।

इसका क्या प्रभाव पड़ा?

एक भावना है कि यह बहुत गंभीर है (हालांकि हम यहां हैं, ज़ाहिर है, व्यक्तिपरक और पक्षपाती)। आखिरकार, यह एक बात है जब, विषय क्षेत्र में जटिल परिमित राज्य मशीनों के साथ सामना किया जाता है, तो आप वर्कआर्ड की तलाश शुरू करते हैं, कुछ को सरल करते हैं, कुछ पर अतिरिक्त ताकत खर्च करते हैं। और यह पूरी तरह से अलग मामला है जब आप अपने आवेदन से वस्तुओं को अपने C ++ कोड से लगभग 1-इंच -1 में मैप कर सकते हैं।

इसके अलावा, पूछे जाने वाले प्रश्नों को देखते हुए, उदाहरण के लिए, एक राज्य से / के लिए इनपुट / आउटपुट हैंडलर के व्यवहार से, इस कार्यक्षमता का उपयोग किया जाता है।

mchain-s

क्या था?

यह एक दिलचस्प स्थिति थी। SObjectizer का उपयोग अक्सर इसलिए किया जाता था ताकि आवेदन का केवल भाग SObjectizer में लिखा जाए। एप्लिकेशन के बाकी कोडों का सामान्य तौर पर अभिनेताओं के साथ, या विशेष रूप से SObjectizer के साथ कुछ भी नहीं हो सकता है। उदाहरण के लिए, एक GUI एप्लिकेशन जिसमें कुछ पृष्ठभूमि कार्यों के लिए एक SObjectizer का उपयोग किया जाता है, जबकि मुख्य कार्य एप्लिकेशन के मुख्य थ्रेड पर किया जाता है।

और ऐसे मामलों में, यह पता चला कि नॉन-सोबिजाइज़र भाग से एसओबीज़ाइज़र भाग तक, जानकारी भेजना उतना ही सरल है: यह साधारण भेजने-कार्यों को कॉल करने के लिए पर्याप्त है। लेकिन विपरीत दिशा में सूचना का प्रसार इतना सरल नहीं है। हमें लग रहा था कि यह अच्छा नहीं है और आपके पास एप्लिकेशन के SObjectizer भागों और सीधे बॉक्स से नॉन-SObjectizer भागों के बीच कुछ सुविधाजनक संचार चैनल होने चाहिए।

क्या बन गया है?

इसलिए, संदेश श्रृंखलाएं या, अधिक परिचित संकेतन में, मॉबिन्स SObjectizer में दिखाई दिए।

माचिन एकल-उपभोक्ता मेलबॉक्स का ऐसा विशिष्ट संस्करण है, जहाँ संदेश नियमित रूप से भेजे जाने वाले कार्यों द्वारा भेजे जाते हैं। लेकिन माचिन से संदेश निकालने के लिए, आपको एजेंट बनाने और उन पर हस्ताक्षर करने की आवश्यकता नहीं है। दो विशेष कार्य हैं जिन्हें एजेंटों के अंदर भी कहा जा सकता है, यहां तक ​​कि बाहरी एजेंटों को भी: प्राप्त () और चयन करें ()। पहला केवल एक चैनल से संदेश पढ़ता है, जबकि दूसरा एक साथ कई चैनलों के संदेश पढ़ सकता है:

 using namespace so_5; mchain_t ch1 = env.create_mchain(...); mchain_t ch2 = env.create_mchain(...); select( from_all().handle_n(3).empty_timeout(200ms), case_(ch1, [](mhood_t<first_message_type> msg) { ... }, [](mhood_t<second_message_type> msg) { ... }), case_(ch2, [](mhood_t<third_message_type> msg ) { ... }, [](mhood_t<some_signal_type>){...}, ... )); 

हम पहले ही यहाँ कई बार माचिन के बारे में बात कर चुके हैं: अगस्त 2017 में और मई 2018 में । इसलिए, विशेष रूप से इस विषय पर कि कैसे mchains के साथ काम दिखता है, हम यहां गहराई तक नहीं गए।

इसका क्या प्रभाव पड़ा?

SObjectizer-5.5 में mchains की उपस्थिति के बाद, यह पता चला कि SObjectizer वास्तव में, एक "अभिनेता" ढांचे से भी कम हो गया, जितना पहले था। एक्टर मॉडल और पब / सब का समर्थन करने के अलावा, एसओबीजेनाइजर ने सीएसपी के लिए समर्थन भी जोड़ा (अनुक्रमिक प्रक्रियाओं के मॉडल को संवाद करते हुए)। Mchains आपको SObjectizer पर काफी जटिल मल्टी-थ्रेडेड एप्लिकेशन विकसित करने की अनुमति देता है बिना किसी एक्टर के। और कुछ कार्यों के लिए यह सुविधाजनक से अधिक है। जो हम खुद समय-समय पर उपयोग करते हैं।

संदेश सीमा तंत्र

क्या था?

मॉडल ऑफ एक्टर्स की सबसे गंभीर कमियों में से एक है ओवरलोड की घटना का पूर्वाभास। अपने आप को ऐसी स्थिति में ढूंढना बहुत आसान है जहां भेजने वाला अभिनेता प्राप्त करने वाले अभिनेता को संदेश तेज प्रक्रिया से तेज गति से भेजता है।

एक नियम के रूप में, अभिनेता के ढांचे में संदेश भेजना एक गैर-अवरुद्ध ऑपरेशन है। इसलिए, जब "फुर्तीला-निर्माता और निरंकुश-उपभोक्ता" की एक जोड़ी होती है, तो प्राप्तकर्ता अभिनेता की कतार बढ़ जाएगी, जबकि कम से कम किसी तरह की मुफ्त मेमोरी है।

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

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

क्या बन गया है?

बस इतना है कि सरल परिदृश्यों में आप तैयार किए गए अधिभार संरक्षण उपकरण का उपयोग कर सकते हैं, तथाकथित संदेश की सीमा। यह तंत्र आपको अनावश्यक संदेशों को छोड़ने, या उन्हें अन्य प्राप्तकर्ताओं को भेजने की अनुमति देता है, या यहां तक ​​कि सीमा से अधिक होने पर भी आवेदन को बाधित करता है। उदाहरण के लिए:

 class worker : public so_5::agent_t { public: worker(context_t ctx) : so_5::agent_t{ ctx //     100  handle_data, //      //  . + limit_then_redirect<handle_data>(100, [this]{ return another_worker_;}) //     1  check_status, //       . + limit_then_drop<check_status>(1) //     1  reconfigure, //     , ..  reconfigure //        . + limit_then_abore<reconfigure>(1) } {...} ... }; 

इस विषय को एक अलग लेख में अधिक विस्तार से वर्णित किया गया है ।

इसका क्या प्रभाव पड़ा?

यह कहना नहीं है कि संदेश सीमाओं का उद्भव कुछ ऐसा हो गया है जिसने मूल रूप से SObjectizer को बदल दिया है, इसके कार्य या इसके साथ काम करने के सिद्धांत। बल्कि, इसकी तुलना रिजर्व पैराशूट से की जा सकती है, जिसका उपयोग केवल अंतिम उपाय के रूप में किया जाता है। लेकिन जब आपको इसका उपयोग करना होता है, तो आपको खुशी होती है कि यह मौजूद है।

संदेश वितरण अनुरेखण तंत्र

क्या था?

SObjectizer-5 डेवलपर्स के लिए एक ब्लैक बॉक्स था। जिसमें संदेश भेजा जाता है और ... और यह या तो प्राप्तकर्ता को आता है, या नहीं आता है।

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

समस्या यह थी कि संदेश वितरण तंत्र SObjectizer रन-टाइम की Giblets में गहराई से छिपा हुआ था और इसलिए, SObjectizer के डेवलपर्स के लिए भी प्राप्तकर्ता को संदेश भेजना मुश्किल था, उपयोगकर्ताओं का उल्लेख नहीं करना। विशेष रूप से नौसिखिए उपयोगकर्ताओं के बारे में जिन्होंने इस तरह की तुच्छ गलतियों की सबसे बड़ी संख्या बनाई।

क्या बन गया है?

SObjectizer-5.5 में, संदेश वितरण प्रक्रिया को ट्रेस करने के लिए एक विशेष तंत्र जिसे संदेश वितरण अनुरेखण (या बस msg_tracing) कहा जाता है, और फिर अंतिम रूप दिया गया। इस तंत्र और इसकी क्षमताओं को एक अलग लेख में अधिक विस्तार से वर्णित किया गया था ।

इसलिए अब, यदि संदेश डिलीवरी पर खो जाते हैं, तो आप बस msg_tracing को सक्षम कर सकते हैं और देख सकते हैं कि ऐसा क्यों होता है।

इसका क्या प्रभाव पड़ा?

SObjectizer में लिखे गए डिबगिंग एप्लिकेशन बहुत सरल और अधिक सुखद बन गए हैं। खुद के लिए भी ।

Env_infrastructure और एकल-थ्रेडेड env_infrastructureures की अवधारणा

क्या था?

हमने बहु-सूत्रीय कोड के विकास को सरल बनाने के लिए हमेशा SObjectizer को एक उपकरण माना है। इसलिए, SObjectizer-5 के पहले संस्करणों को केवल बहु-थ्रेडेड वातावरण में काम करने के लिए लिखा गया था।

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

यानीSObjectizer मल्टी-थ्रेडेड प्रोग्रामिंग के लिए और मल्टी-थ्रेडेड वातावरण में उपयोग के लिए बनाया गया था। और यह हमारे लिए पूरी तरह से अनुकूल है।

हालाँकि, जैसा कि SObjectizer का उपयोग "जंगली में" किया गया था, ऐसी स्थितियों की खोज की गई थी जहाँ इसके समाधान में अभिनेताओं का उपयोग करना काफी कठिन था। लेकिन, एक ही समय में, सभी काम और, एक ही कार्य प्रवाह पर किया जा सकता था।

और हमने एक बहुत ही दिलचस्प समस्या का सामना किया: क्या एक एकल काम करने वाले धागे पर काम करने के लिए SObjectizer को सिखाना संभव है?

क्या बन गया है?

यह पता चला कि यह संभव है।

इसने हमें बहुत पैसा खर्च किया, समाधान के साथ आने में बहुत समय और प्रयास लगा। लेकिन समाधान का आविष्कार किया गया था।

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

SObjectizer के लिए, कई एकल-थ्रेडेड env_infrastructureures विकल्प बनाए गए हैं। इसने हमें SObjectizer पर एकल-थ्रेडेड एप्लिकेशन विकसित करने की अनुमति दी, जिसके अंदर सामान्य एजेंट एक दूसरे के साथ नियमित संदेशों का आदान-प्रदान करते हैं।

हमने एक अलग लेख में इस कार्यक्षमता के बारे में अधिक विस्तार से बात की । ।

इसका क्या प्रभाव पड़ा?

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

रन-टाइम निगरानी उपकरण

क्या था?

संदेश वितरण तंत्र के संदर्भ में न केवल SObjectizer-5 एक ब्लैक बॉक्स था। लेकिन यह भी पता लगाने का कोई तरीका नहीं था कि वर्तमान में आवेदन के अंदर कितने एजेंट काम कर रहे हैं, कितने और कौन से डिस्पैचर बनाए गए हैं, कितने काम के धागे शामिल हैं, कितने संदेश डिस्पैचरों की कतार में इंतजार कर रहे हैं, आदि।

यह सभी जानकारी 24/7 चल रहे अनुप्रयोगों की निगरानी के लिए बहुत उपयोगी है। लेकिन डिबगिंग के लिए, मैं समय-समय पर यह भी समझना चाहूंगा कि क्या कतारें बढ़ती हैं या यदि एजेंटों की संख्या बढ़ती / घटती है।

दुर्भाग्य से, कुछ समय के लिए, हमारे हाथ ऐसी सूचनाओं को एकत्र करने और प्रसारित करने के लिए SObjectizer में धन जोड़ने की बात नहीं पहुंची।

क्या बन गया है?

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

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

इसका क्या प्रभाव पड़ा?

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

तो यह "आप यह कर सकते हैं" श्रेणी से एक विशेषता है, लेकिन इसकी उपस्थिति, हमारी राय में, तुरंत साधन को दूसरे भार वर्ग में स्थानांतरित करती है। क्योंकि"घुटने पर" एक अभिनेता ढांचे का प्रोटोटाइप बनाना इतना मुश्किल नहीं है। बहुतों ने ऐसा किया है और कई और भी करेंगे। लेकिन फिर अपने विकास को रन-टाइम मॉनिटरिंग जैसी चीज़ से लैस करने के लिए ... अब तक, सभी घुटने से तैयार किए गए ड्राफ्ट जीवित नहीं हैं।

और एक लाइन में एक बात और

चार वर्षों के लिए, एसओबीजेलाइज़र-5.5 में बहुत सारे नवाचार और परिवर्तन हुए हैं, जिनमें से एक सारांश में भी इसका वर्णन बहुत अधिक स्थान लेगा। इसलिए, हम शाब्दिक रूप से एक पंक्ति द्वारा उनमें से कुछ को दर्शाते हैं। यादृच्छिक क्रम में, बिना किसी प्राथमिकता के।

SObjectizer-5.5 CMake बिल्ड सिस्टम के लिए समर्थन जोड़ता है।

अब SObjectizer-5 को एक गतिशील और एक स्थिर पुस्तकालय के रूप में बनाया जा सकता है।

SObjectizer-5.5 अब बनाया गया है और Android पर चलता है (दोनों CrystaX NDK के माध्यम से और नवीनतम Android NDK के माध्यम से)।

निजी प्रेषणकर्ता सामने आए हैं। अब आप ऐसे डिस्पैचर बना सकते हैं और उनका उपयोग कर सकते हैं जिन्हें कोई और नहीं देखता है।

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

सहकारिता बनाने और पंजीकरण के लिए उपकरणों को काफी सरल बनाया गया है: विधियाँ_कोप / परिचय_चिल्ड_कोप, मेक_एजेंट / मेक_एगेंट_विथ_बिंडर और वह सब।

लॉक ऑब्जेक्ट्स के एक कारखाने की अवधारणा दिखाई दी और अब आप चुन सकते हैं कि आपको किन लॉक ऑब्जेक्ट्स की आवश्यकता है (म्यूटेक्स, स्पिनलॉक, संयुक्त या कुछ अन्य के आधार पर)।

लिपटे_env_t वर्ग दिखाई दिया है और अब आप अपने आवेदन में SObjectizer चला सकते हैं न केवल so_5 :: लॉन्च (!) के साथ।

Stop_guards की अवधारणा दिखाई दी और अब आप SObjectizer की शटडाउन प्रक्रिया को प्रभावित कर सकते हैं। उदाहरण के लिए, आप SObjectizer को तब तक रुकने से रोक सकते हैं जब तक कि कुछ एजेंटों ने अपना आवेदन कार्य पूरा नहीं कर लिया हो।

अब आप उन संदेशों को रोक सकते हैं जो एजेंट को दिए गए थे, लेकिन वे एजेंट (तथाकथित dead_letter_handlers) द्वारा संसाधित नहीं किए गए थे।

संदेशों को विशेष "लिफाफे" में लपेटने का अवसर था। लिफाफे संदेश के बारे में अतिरिक्त जानकारी ले सकते हैं और प्राप्तकर्ता को संदेश देने पर कुछ कार्रवाई कर सकते हैं।

5.5.0 से 5.5.23 की संख्या में

कोड / परीक्षणों / उदाहरणों के संदर्भ में बने मार्ग को देखना भी दिलचस्प है। यहाँ क्लोक यूटिलिटी हमें SObjectizer-5.5.0 कर्नेल कोड की मात्रा के बारे में बताती है:

 -------------------------------------------------- -----------------------------
भाषा फ़ाइलें रिक्त टिप्पणी कोड
-------------------------------------------------- -----------------------------
सी / सी ++ हैडर 58 2119 5156 5762
सी ++ 39 1167 779 4759
रूबी 2 30 2 75
-------------------------------------------------- -----------------------------
एसयूएम: 99 3316 5937 10596
-------------------------------------------------- -----------------------------

और यहाँ एक ही बात है, लेकिन v.5.5.23 के लिए (जिनमें से 1147 लाइनें वैकल्पिक-लाइट लाइब्रेरी कोड हैं):

 -------------------------------------------------- -----------------------------
भाषा फ़ाइलें रिक्त टिप्पणी कोड
-------------------------------------------------- -----------------------------
सी / सी ++ हैडर 133 6279 22173 21068
सी ++ 53 2498 2760 10398
CMake 2 29 0 177
रूबी 4 53 2 129
-------------------------------------------------- -----------------------------
एसयूएम: 192 8859 24935 31772
-------------------------------------------------- -----------------------------

V.5.5.0 के लिए परीक्षणों की मात्रा:

 -------------------------------------------------- -----------------------------
भाषा फ़ाइलें रिक्त टिप्पणी कोड
-------------------------------------------------- -----------------------------
सी ++ 84 2510 390 11540
रूबी 162 496 0 1054
सी / सी ++ हैडर 1 11 0 32
-------------------------------------------------- -----------------------------
एसयूएम: 247 3017 390 12626
-------------------------------------------------- -----------------------------

V.5.5.23 के लिए टेस्ट:

 -------------------------------------------------- -----------------------------
भाषा फ़ाइलें रिक्त टिप्पणी कोड
-------------------------------------------------- -----------------------------
C ++ 324 7345 1305 35231
रूबी 675 2,353 0 4,671
CMake 338 43 0 955
सी / सी ++ हैडर 11 107 3 448
-------------------------------------------------- -----------------------------
एसयूएम: 1348 9848 1308 41305

खैर, v.5.5.0 के उदाहरण:

 -------------------------------------------------- -----------------------------
भाषा फ़ाइलें रिक्त टिप्पणी कोड
-------------------------------------------------- -----------------------------
सी ++ 27 765 463 3322
रूबी 28 95 0 192
-------------------------------------------------- -----------------------------
एसयूएम: 55 860 463 3514

वे हैं, लेकिन पहले से ही v.5.5.23 के लिए:

 -------------------------------------------------- -----------------------------
भाषा फ़ाइलें रिक्त टिप्पणी कोड
-------------------------------------------------- -----------------------------
सी ++ 67 2141 2061 9341
रूबी 133 451 0 868
CMake 67 93 0 595
सी / सी ++ हैडर 1 12 11 32
-------------------------------------------------- -----------------------------
एसयूएम: 268 2697 2072 10836

लगभग हर जगह, लगभग तीन गुना की वृद्धि।

और SObjectizer के लिए प्रलेखन की मात्रा शायद और भी बढ़ गई है।

निकट भविष्य की योजनाएं (और न केवल)

संस्करण 5.5.23 की रिहाई के बाद SObjectizer के लिए प्रारंभिक विकास योजनाएं लगभग एक महीने पहले यहां बताई गई थीं । मौलिक रूप से, वे नहीं बदले हैं। लेकिन यह महसूस किया गया कि संस्करण 5.6.0, जिसका रिलीज़ 2019 की शुरुआत के लिए नियोजित है, को सोब्जेलाइज़र की अगली स्थिर शाखा की शुरुआत के रूप में तैनात करने की आवश्यकता होगी। इस तथ्य के साथ कि 2019 के दौरान, एसओबीजेलाइज़र 5.6 शाखा के तहत बिना किसी महत्वपूर्ण परिवर्तन के विकसित होगा।

यह उन लोगों को सक्षम करेगा जो अब अपनी परियोजनाओं में SO-5.5 का उपयोग कर रहे हैं, धीरे-धीरे इस डर के बिना SO-5.6 पर स्विच करने के लिए कि उन्हें SO-5.7 पर भी स्विच करना होगा।

संस्करण 5.7, जिसमें हम खुद को SO-5.5 और SO-5.6 के मूल सिद्धांतों से कहीं भी भटकने देना चाहते हैं, 2019 में प्रयोगात्मक माना जाएगा। स्थिरीकरण और रिलीज के साथ, अगर सबकुछ ठीक हो जाता है, तो पहले से ही 2020 में।

निष्कर्ष

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

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

यदि आपको ऐसा कुछ नहीं मिला है या आपके पास SObjectizer में पर्याप्त नहीं है - तो हमें बताएं। हम हमेशा रचनात्मक आलोचना सुनते हैं। और, अगर यह हमारी शक्ति में है, तो हम उपयोगकर्ताओं की इच्छाओं को जीवन में लाते हैं।