تنفيذ الرمز المخصص على GO

هذا في الواقع كل شيء عن العقود الذكية.

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

لسوء الحظ ، لم نقم بتطوير الأمان حتى الآن ، لذا لن أصفه الآن ، ولكن سأعطي بعض التلميحات.

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

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

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

وهكذا ، نقوم بتنفيذ GO

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

كل شيء بسيط عندما تبني مكتبتك ، تقوم ببنائها باستخدام المفتاح - buildmode = plugin وتحصل على ملف .so ، الذي تفتحه بعد ذلك.

p, err := plugin.Open(path) 

تبحث عن الشخصية التي تهتم بها:

 symbol, err := p.Lookup(Method) 

والآن ، اعتمادًا على ما إذا كان المتغير دالة أو دالة ، يمكنك إما تسميته أو استخدامه كمتغير.

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

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

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

عقودنا هي كائنات من "الفئة" المقابلة ، وفي البداية تم تخزين مثيل هذا الكائن في متغيرنا المصدّر ، لذا يمكننا إنشاء متغير آخر آخر:

 export, err := p.Lookup("EXPORT") obj := reflect.New(reflect.ValueOf(export).Elem().Type()).Interface() 

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

إذا كنت مهتمًا بكيفية القيام بذلك ، ولكنك كسول جدًا لقراءة الوثائق ، فعندئذٍ:

 method := reflect.ValueOf(obj).MethodByName(Method) res:= method.Call(in) 

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

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

 var EXPORT ContractType 

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

نحن لا نحبها حقًا. وضربنا بشدة.

التحليل

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

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

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

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

 func (pf *ParsedFile) codeOfNode(n ast.Node) string { return string(pf.code[n.Pos()-1 : n.End()-1]) } 

نحن في الواقع نقوم بتحليل الملف والحصول على أعلى عقدة AST التي سنزحف منها إلى الملف.

 fileSet = token.NewFileSet() node, err := parser.ParseFile(fileSet, name, code, parser.ParseComments) 

بعد ذلك ، ننتقل إلى الكود بدءًا من العقدة العلوية ، ونجمع كل شيء مثير للاهتمام في بنية منفصلة.

 for _, decl := range node.Decls { switch d := decl.(type) { case *ast.GenDecl: … case *ast.FuncDecl: … } } 

Decls ، لقد تم تحليله بالفعل في مصفوفة ، وقائمة بكل ما تم تحديده في الملف ، ولكنها عبارة عن مجموعة من واجهات Decl التي لا تصف ما بداخلها ، لذلك يجب أن يلقي كل عنصر بنوع معين ، وهنا ابتعد مؤلفو اللغة عن فكرتهم باستخدام الواجهات ، الواجهة في go / ast هي بالأحرى فئة أساسية.

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

الشيء الوحيد الذي نحتاج إلى تذكره بشكل منفصل هو اسم نوع البيانات الموروث من BaseContract ، وسنقوم بالرقص حوله.

إنشاء التعليمات البرمجية

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

وهنا الشيء الرئيسي ، يلف على الوظائف. يتم استكمال اسم الغلاف بنوع من البادئة والآن يسهل العثور على الغلاف.

 symbol, err := p.Lookup("INSMETHOD_" + Method) wrapper, ok := symbol.(func(ph proxyctx.ProxyHelper, object []byte, data []byte) (object []byte, result []byte, err error)) 

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

ماذا لدينا داخل الغلاف؟

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

 {{ range $method := .Methods }} func INSMETHOD_{{ $method.Name }}(ph proxyctx.ProxyHelper, object []byte, data []byte) ([]byte, []byte, error) { self := new({{ $.ContractType }}) err := ph.Deserialize(object, self) if err != nil { return nil, nil, err } {{ $method.ArgumentsZeroList }} err = ph.Deserialize(data, &args) if err != nil { return nil, nil, err } {{ if $method.Results }} {{ $method.Results }} := self.{{ $method.Name }}( {{ $method.Arguments }} ) {{ else }} self.{{ $method.Name }}( {{ $method.Arguments }} ) {{ end }} state := []byte{} err = ph.Serialize(self, &state) if err != nil { return nil, nil, err } {{ range $i := $method.ErrorInterfaceInRes }} ret{{ $i }} = ph.MakeErrorSerializable(ret{{ $i }}) {{ end }} ret := []byte{} err = ph.Serialize([]interface{} { {{ $method.Results }} }, &ret) return state, ret, err } {{ end }} 

سوف يهتم القارئ اليقظ بما هو مساعد الوكيل؟ - هذا هو كائن الجمع الذي ما زلنا بحاجة إليه ، ولكننا نستخدم الآن قدرته على التسلسل وإلغاء التسلسل.

حسنًا ، سوف يسأل أي شخص يقرأ ، "لكن هذه هي حججك ، من أين هم؟" إليك أيضًا إجابة مفهومة ، نعم النص / القالب ليس هناك عدد كافٍ من النجوم من السماء ، ولهذا السبب نحسب هذه الأسطر في الشفرة ، وليس في القالب.

يحتوي method.ArgumentsZeroList على شيء مثل

 var arg0 int = 0 Var arg1 string = “” Var arg2 ackwardType = ackwardType{} Args := []interface{}{&arg0, &arg1, &arg2} 

وبناءً عليه ، تحتوي الوسيطات على "arg0، arg1، arg2".

وبالتالي ، يمكننا أن نطلق على أي شيء نريده ، مع أي توقيع.

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

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

ولكن ماذا لو أردنا استدعاء عقد من عقد؟

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

كيف تنظم كل هذا؟ - سيتعين علينا تخزين عقود أخرى في دليل خاص يمكن لمولدنا التعرف عليه وإنشاء وكلاء لكل عقد يتم استيراده.

أي إذا التقينا:

 import “ContractsDir/ContractAddress" 

نكتبها على قائمة العقود المستوردة.

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

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

 RouteCall(ref Address, method string, args []byte) ([]byte, error) 

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

ولكن من الضروري أن يبدو كل شيء للمستخدم كما يلي:

 ret := contractPackage.GetObject(Address).Method(arg1,arg2, …) 

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

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

 type {{ .ContractType }} struct { Reference Address } 

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

 func GetObject(ref Address) (r *{{ .ContractType }}) { return &{{ .ContractType }}{Reference: ref} } 

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

 {{ range $method := .MethodsProxies }} func (r *{{ $.ContractType }}) {{ $method.Name }}( {{ $method.Arguments }} ) ( {{ $method.ResultsTypes }} ) { {{ $method.InitArgs }} var argsSerialized []byte err := proxyctx.Current.Serialize(args, &argsSerialized) if err != nil { panic(err) } res, err := proxyctx.Current.RouteCall(r.Reference, "{{ $method.Name }}", argsSerialized) if err != nil { panic(err) } {{ $method.ResultZeroList }} err = proxyctx.Current.Deserialize(res, &resList) if err != nil { panic(err) } return {{ $method.Results }} } {{ end }} 

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

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

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

في السابق ، قمنا ببساطة بتمرير السياق ، وكان حقلاً غير واضح في نوع BaseContract مع مُحدد ومُحضر ، وسمح المُحدد بتعيين الحقل مرة واحدة فقط ، لذلك تم تعيين السياق قبل تنفيذ العقد ، ولم يتمكن المستخدم من قراءته إلا.

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

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

 func GetContext() *core.LogicCallContext { return gls.Get("ctx").(*core.LogicCallContext) } 

وهو يستخدمه بسعادة ، ولكننا نستخدمه في RouteCall () ، على سبيل المثال ، لفهم العقد الذي يستدعي حاليًا شخصًا ما.

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

معًا

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

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

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