Erlang 21

xref




erlang

xref

मॉड्यूल

xref

मॉड्यूल सारांश

कार्यों, मॉड्यूल, अनुप्रयोगों और रिलीज के बीच निर्भरता का विश्लेषण करने के लिए एक क्रॉस संदर्भ उपकरण।

विवरण

Xref एक क्रॉस रेफरेंस टूल है, जिसका उपयोग फ़ंक्शन, मॉड्यूल, एप्लिकेशन और रिलीज़ के बीच निर्भरता खोजने के लिए किया जा सकता है।

फ़ंक्शंस के बीच के कॉल या तो f() या m:f() जैसे बाहरी कॉल हैं। मॉड्यूल डेटा , जो BEAM फ़ाइलों से निकाले जाते हैं, में स्थानीय फ़ंक्शन, निर्यात किए गए फ़ंक्शन, स्थानीय कॉल और बाहरी कॉल शामिल हैं। डिफ़ॉल्ट रूप से, अंतर्निहित फ़ंक्शन (बीआईएफ) पर कॉल को अनदेखा किया जाता है, लेकिन यदि इस मॉड्यूल के कुछ कार्यों द्वारा स्वीकार किए गए विकल्प बिल्डिन्स true , तो बीआईएफ को कॉल भी शामिल हैं। यह ओटीपी संस्करण का विश्लेषण है जो यह तय करता है कि बीआईएफ क्या कार्य करता है। कार्यात्मक वस्तुओं को कहा जाता है कि वे जहां बनाई गई हैं (और कहीं नहीं) कहलाती हैं। अनारक्षित कॉल वैरिएबल मॉड्यूल, वैरिएबल फंक्शन या वैरिएबल तर्कों के साथ apply या spawn करने के apply कॉल हैं। उदाहरण M:F(a) , apply(M, f, [a]) , और spawn(m, f(), Args) । अनचाही कॉल्स को उन कॉल्स द्वारा दर्शाया जाता है जहाँ वेरिएबल मॉड्यूल्स को परमाणु '$M_EXPR' से बदल दिया गया है, वेरिएबल फ़ंक्शंस को '$F_EXPR' साथ बदल दिया गया है, और वेरिएबल नंबरों को नंबर -1 से बदल दिया गया है। उपर्युक्त उदाहरण '$M_EXPR':'$F_EXPR'/1 , '$M_EXPR':f/1 , और m:'$F_EXPR'/-1 । अनसुलझे कॉल बाहरी कॉल का एक सबसेट हैं।

चेतावनी

अनारक्षित कॉल मॉड्यूल डेटा को अधूरा बनाते हैं, जिसका अर्थ है कि विश्लेषण के परिणाम अमान्य हो सकते हैं।

अनुप्रयोग मॉड्यूल का संग्रह हैं। मॉड्यूल की BEAM फाइलें एप्लिकेशन डायरेक्टरी के ebin उपनिर्देशिका में स्थित हैं। एप्लिकेशन डायरेक्टरी का नाम एप्लिकेशन के नाम और संस्करण को निर्धारित करता है। रिलीज़ , रिलीज़ डायरेक्टरी के lib उपनिर्देशिका में स्थित अनुप्रयोगों का संग्रह है। डिज़ाइन प्रिंसिपल्स बुक में एप्लिकेशन और रिलीज़ के बारे में पढ़ने के लिए अधिक है।

Xref सर्वरों को नामों से पहचाना जाता है, जो नए सर्वर बनाते समय आपूर्ति किए जाते हैं। प्रत्येक Xref सर्वर में रिलीज़ का एक सेट, अनुप्रयोगों का एक सेट और मॉड्यूल डेटा के साथ मॉड्यूल का एक सेट होता है। Xref सर्वर एक दूसरे से स्वतंत्र होते हैं, और सभी विश्लेषणों का मूल्यांकन एक एकल Xref सर्वर के संदर्भ में किया जाता है (अपवाद कार्य m/1 और d/1 जो सर्वर का उपयोग बिल्कुल नहीं करते हैं)। एक Xref सर्वर का मोड यह निर्धारित करता है कि मॉड्यूल डेटा को BEAM फ़ाइलों से निकाला जाता है क्योंकि मॉड्यूल सर्वर में जोड़े जाते हैं। R7 के साथ शुरू, विकल्प debug_info साथ संकलित BEAM फाइलों में तथाकथित डिबग जानकारी होती है, जो कोड का एक सार प्रतिनिधित्व है। functions मोड में, जो डिफ़ॉल्ट मोड है, डिबग जानकारी से फ़ंक्शन कॉल और लाइन नंबर निकाले जाते हैं। modules मोड में, डिबग जानकारी को वर्तमान में नजरअंदाज कर दिया जाता है, लेकिन मॉड्यूल के बीच निर्भरता को बीईएएम फाइलों के अन्य हिस्सों से निकाला जाता है। modules मोड functions मोड की तुलना में काफी कम समय और अंतरिक्ष की खपत है, लेकिन जो विश्लेषण किया जा सकता है वह सीमित है।

एक विश्लेषण किया गया मॉड्यूल एक मॉड्यूल है जिसे अपने मॉड्यूल डेटा के साथ Xref सर्वर में जोड़ा गया है। लाइब्रेरी मॉड्यूल एक ऐसा मॉड्यूल है जो लाइब्रेरी पथ में उल्लिखित कुछ निर्देशिका में स्थित होता है। एक पुस्तकालय मॉड्यूल का उपयोग करने के लिए कहा जाता है यदि इसके कुछ निर्यात किए गए कार्यों का उपयोग कुछ विश्लेषण मॉड्यूल द्वारा किया जाता है। एक अज्ञात मॉड्यूल एक मॉड्यूल है जो न तो एक विश्लेषण मॉड्यूल है और न ही एक पुस्तकालय मॉड्यूल है, लेकिन जिनके निर्यात कार्यों का उपयोग कुछ विश्लेषण मॉड्यूल द्वारा किया जाता है। एक अज्ञात फ़ंक्शन एक उपयोग किया जाने वाला फ़ंक्शन है जो किसी भी विश्लेषण मॉड्यूल द्वारा न तो स्थानीय या निर्यात किया जाता है और न ही किसी भी पुस्तकालय मॉड्यूल द्वारा निर्यात किया जाता है। एक अपरिभाषित फ़ंक्शन एक बाहरी रूप से उपयोग किया जाने वाला फ़ंक्शन है जो किसी भी विश्लेषण किए गए मॉड्यूल या लाइब्रेरी मॉड्यूल द्वारा निर्यात नहीं किया जाता है। इस धारणा के साथ, एक स्थानीय फ़ंक्शन एक अपरिभाषित फ़ंक्शन हो सकता है, अर्थात् यदि यह कुछ मॉड्यूल से बाहरी रूप से उपयोग किया जाता है। सभी अज्ञात कार्य भी अपरिभाषित कार्य हैं; उपयोगकर्ता की मार्गदर्शिका में एक figure है जो इस संबंध को दिखाता है।

R9C के साथ शुरू, मॉड्यूल विशेषता टैग deprecated Xref को पदावनत कार्यों के बारे में सूचित करने के लिए और वैकल्पिक रूप से जब कार्यों को हटाने की योजना बनाई जाती है। कुछ उदाहरण विचार दिखाते हैं:

-deprecated ({च, 1})।
निर्यात किया गया फ़ंक्शन f/1 पदावनत है। कुछ भी नहीं कहा जाता है कि f/1 हटाया जाएगा या नहीं।
-deprecated ({च, '_'})।
सभी निर्यात किए गए फ़ंक्शंस f/0 , f/1 वगैरह को डिप्रेस्ड किया जाता है।
-deprecated (मॉड्यूल)।
मॉड्यूल में सभी निर्यात किए गए कार्यों को पदावनत किया जाता है। समतुल्य -deprecated({'_','_'}). बराबर -deprecated({'_','_'}).
-deprecated ([{ग्राम, 1, next_version}])।
फ़ंक्शन g/1 को हटा दिया गया है और अगले संस्करण में हटा दिया जाएगा।
-deprecated ([{जी, 2, next_major_release}])।
फ़ंक्शन g/2 को हटा दिया गया है और अगले प्रमुख रिलीज में हटा दिया जाएगा।
-deprecated ([{जी, 3, अंततः}])।
फ़ंक्शन g/3 को पदावनत किया जाता है और अंततः हटा दिया जाएगा।
-deprecated ({ '_', '_', अंत में})।
मॉड्यूल में सभी निर्यात किए गए कार्यों को हटा दिया जाता है और अंततः इसे हटा दिया जाएगा।

इससे पहले कि कोई विश्लेषण हो, मॉड्यूल डेटा सेट किया जाना चाहिए। उदाहरण के लिए, सभी मॉड्यूल डेटा ज्ञात होने पर क्रॉस संदर्भ और अज्ञात फ़ंक्शन की गणना की जाती है। पूर्ण डेटा ( analyze , q , variables ) की आवश्यकता वाले फ़ंक्शंस डेटा को स्वचालित रूप से सेट करने का ध्यान रखते हैं। add , replace , remove , set_library_path या update फंक्शन्स में से किसी को कॉल करने के बाद मॉड्यूल डेटा (फिर से) सेट करना होगा।

मॉड्यूल डेटा सेट करने का परिणाम कॉल ग्राफ़ है । ए (निर्देशित) ग्राफ में कोने का एक सेट और (निर्देशित) किनारों का एक सेट होता है। किनारों फ़ंक्शन, मॉड्यूल, एप्लिकेशन या रिलीज़ के बीच कॉल (से, तक) का प्रतिनिधित्व करते हैं । से To कहा जाता है, और To कहा जाता है कि इसका उपयोग From से किया जाता है। कॉल ग्राफ़ के कोने सभी मॉड्यूल डेटा के कार्य हैं: विश्लेषण किए गए मॉड्यूल के स्थानीय और निर्यात किए गए कार्य; इस्तेमाल किया BIF; पुस्तकालय मॉड्यूल के निर्यात कार्यों का इस्तेमाल किया; और अज्ञात कार्य। संकलक द्वारा जोड़े गए फ़ंक्शन module_info/0,1 निर्यात किए गए कार्यों में शामिल हैं, लेकिन केवल जब कुछ मॉड्यूल से बुलाया जाता है। किनारों सभी मॉड्यूल डेटा के फ़ंक्शन कॉल हैं। किनारों के एक सेट होने का एक परिणाम यह है कि एक ही किनारा है यदि कोई फ़ंक्शन स्थानीय और बाहरी रूप से एक और एक ही कोड की एक पंक्ति में कई बार उपयोग किया जाता है।

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

कॉल ग्राफ के अलावा एक ग्राफ होता है जिसे इंटर कॉल ग्राफ कहा जाता है। यह कॉल्स (From, To) का एक ग्राफ़ है, जिसमें कॉल टू ग्राफ़ से कॉल टू की एक श्रृंखला है, और प्रत्येक से और टू एक निर्यातित फ़ंक्शन या अप्रयुक्त स्थानीय फ़ंक्शन है। कॉल ग्राफ़ के लिए कोने समान हैं।

मॉड्यूल, अनुप्रयोगों और रिलीज के बीच कॉल भी निर्देशित रेखांकन हैं। इन रेखांकन के किनारों और किनारों के प्रकार हैं (सबसे विशेष से सबसे सामान्य तक): कार्यों के लिए Fun ; मॉड्यूल के लिए Mod ; App लिए App ; और रिलीज के लिए Rel । निम्नलिखित पैराग्राफ रेखांकन के साथ शुरू होने वाले ग्राफ के कुछ हिस्सों के चयन और विश्लेषण के लिए उपयोग की जाने वाली भाषा के विभिन्न निर्माणों का वर्णन करेंगे:

  • अभिव्यक्ति :: = लगातार
  • कॉन्स्टेंट :: = कॉन्स्टैट्स | कास्ट : प्रकार | RegExpr
  • कांस्ट्स :: = लगातार | [ लगातार , ... ] | { लगातार , ... }
  • लगातार :: = कॉल | कॉन्स्ट
  • Call :: = FunSpec -> FunSpec | { एमएफए , एमएफए } | AtomConst -> AtomConst | { AtomConst , AtomConst }
  • कांस्ट :: = AtomConst | फनस्पेक | एमएफए
  • AtomConst :: = अनुप्रयोग | मॉड्यूल | रिहाई
  • फ़नस्पेक :: = मॉड्यूल : फ़ंक्शन / योग्यता
  • MFA :: = { मॉड्यूल , फंक्शन , एरिटी }
  • RegExpr :: = RegString : प्रकार | RegFunc | RegFunc : टाइप करें
  • RegFunc :: = RegModule : RegFunction / RegArity
  • RegModule :: = RegAtom
  • विनियमन :: = RegAtom
  • RegArity :: = RegString | नंबर | _ | -1
  • RegAtom :: = RegString | परमाणु | _
  • RegString :: = - एक नियमित अभिव्यक्ति, जैसा कि re मॉड्यूल में वर्णित है, दोहरे उद्धरणों में संलग्न है -
  • प्रकार :: = Fun | Mod | App | Rel
  • समारोह :: = परमाणु
  • आवेदन :: = परमाणु
  • मॉड्यूल :: = परमाणु
  • रिलीज :: = परमाणु
  • Arity :: = संख्या | -1
  • परमाणु :: = - एर्लांग परमाणुओं के समान -
  • संख्या :: = - गैर-नकारात्मक एरलांग पूर्णांक के समान -

स्थिरांक के उदाहरण हैं: kernel , kernel->stdlib , [kernel, sasl] , [pg -> mnesia, {tv, mnesia}] : Mod । यह एक त्रुटि है अगर Const उदाहरण किसी भी ग्राफ के किसी भी शीर्ष से मेल नहीं खाता है। यदि AtomConst के AtomConst उदाहरण से मेल खाते एक से अधिक शीर्ष हैं, तो सबसे सामान्य प्रकार में से एक को चुना जाता है। स्थिरांक की सूची को स्थिरांक के एक सेट के रूप में व्याख्या की जाती है, सभी एक ही प्रकार के। स्थिरांक का एक समूह कॉल की एक श्रृंखला का गठन करता है (जो कि हो सकता है, लेकिन कुछ ग्राफ के कॉल की वास्तविक श्रृंखला के अनुरूप नहीं है)। एक प्रकार की सूची या Constant टपल को असाइन करना प्रत्येक Constant को टाइप असाइन करने के बराबर है।

ग्राफ के कुछ सिरों को चुनने के लिए नियमित अभिव्यक्ति का उपयोग एक साधन के रूप में किया जाता है। एक RegExpr जिसमें एक RegString और एक प्रकार शामिल है - एक उदाहरण "xref_.*" : Mod - की व्याख्या उन मॉड्यूल (या अनुप्रयोग या रिलीज़, प्रकार के आधार पर) के रूप में की जाती है जो अभिव्यक्ति से मेल खाते हैं। इसी तरह, एक RegFunc को कॉल ग्राफ़ के उन कोने के रूप में व्याख्या किया जाता है जो अभिव्यक्ति से मेल खाते हैं। एक उदाहरण "xref_.*":"add_.*"/"(2|3)" , जो कि किसी भी xref मॉड्यूल के दो या तीन के सभी कार्यों को मिलाता है। एक अन्य उदाहरण, एक जो 10 या उससे अधिक के सभी कार्यों से मेल खाता है: _:_/"[1-9].+" । यहाँ _ ".*" संक्षिप्त नाम है, जो कि नियमित अभिव्यक्ति है जो किसी भी चीज़ से मेल खाता है।

चर का सिंटैक्स सरल है:

  • अभिव्यक्ति :: = चर
  • चर :: = - एर्लांग चर के समान -

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

E
ग्राफ किनारों (*) को बुलाओ।
V
ग्राफ़ वर्टिसेस (*) को कॉल करें।
M
मॉड्यूल। सभी मॉड्यूल: विश्लेषण किए गए मॉड्यूल, लाइब्रेरी मॉड्यूल और अज्ञात मॉड्यूल का उपयोग किया।
A
अनुप्रयोगों।
R
विज्ञप्ति।
ME
मॉड्यूल किनारों। सभी मॉड्यूल कॉल।
AE
आवेदन पत्र। सभी एप्लिकेशन कॉल।
RE
किनारों को जारी करें। सभी रिलीज़ कॉल।
L
स्थानीय कार्य (*)। विश्लेषण किए गए मॉड्यूल के सभी स्थानीय कार्य।
X
निर्यातित कार्य। विश्लेषण किए गए मॉड्यूल के सभी निर्यात किए गए कार्य और लाइब्रेरी मॉड्यूल के सभी उपयोग किए गए निर्यात कार्य।
F
कार्य (*)।
B
BIF का इस्तेमाल किया। यदि सभी विश्लेषण किए गए मॉड्यूल के लिए builtins false , तो B खाली है।
U
अज्ञात कार्य।
UU
अप्रयुक्त कार्य (*)। विश्लेषण किए गए मॉड्यूल के सभी स्थानीय और निर्यात किए गए फ़ंक्शन जिनका उपयोग नहीं किया गया है।
XU
बाहरी रूप से प्रयुक्त कार्य। सभी मॉड्यूल के कार्य - स्थानीय कार्यों सहित - जिनका उपयोग किसी बाहरी कॉल में किया गया है।
LU
स्थानीय रूप से प्रयुक्त कार्य (*)। सभी मॉड्यूल के कार्य जो कुछ स्थानीय कॉल में उपयोग किए गए हैं।
OL
एक विशेषता टैग on_load (*) के साथ कार्य।
LC
स्थानीय कॉल (*)।
XC
बाहरी कॉल (*)।
AM
विश्लेषण किए गए मॉड्यूल।
UM
अज्ञात मॉड्यूल।
LM
लाइब्रेरी मॉड्यूल का उपयोग किया।
UC
अनारक्षित कॉल। modules मोड में खाली।
EE
इंटर कॉल ग्राफ किनारों (*)।
DF
पदावनत किए गए कार्य। सभी पदावनत किए गए निर्यात कार्य और सभी उपयोग किए गए बीआईएफ को हटा दिया गया।
DF_1
पदावनत किए गए कार्य। सभी हटाए गए कार्यों को अगले संस्करण में हटा दिया जाएगा।
DF_2
पदावनत किए गए कार्य। सभी हटाए गए कार्यों को अगले संस्करण या अगले प्रमुख रिलीज में हटा दिया जाएगा।
DF_3
पदावनत किए गए कार्य। सभी हटाए गए कार्यों को अगले संस्करण में, अगले प्रमुख रिलीज या बाद में हटा दिया जाएगा।

ये पूर्वनिर्धारित चर (सेट ऑपरेटर + (यूनियन) और - (अंतर) के साथ-साथ कास्ट ऑपरेटर ( टाइप ) बारे में कुछ तथ्य हैं जो नीचे वर्णित हैं):

  • F , L + X बराबर है।
  • V , X + L + B + U बराबर है, जहाँ X , L , B और U जोड़ीदार डिसऑइंट हैं (अर्थात, जिनमें कोई तत्व समान नहीं है)।
  • UU , V - (XU + LU) बराबर है, जहाँ LU और XU में समान तत्व हो सकते हैं। दूसरे तरीके से डालें:
  • V , UU + XU + LU बराबर है।
  • OL , F का एक सबसेट है।
  • E , LC + XC बराबर है। ध्यान दें कि LC और XC में समान रूप से तत्व हो सकते हैं, अर्थात् यदि कोई फ़ंक्शन स्थानीय और बाहरी रूप से एक और समान फ़ंक्शन से उपयोग किया जाता है।
  • U , XU सबसेट है।
  • B , XU सबसेट है।
  • LU range LC बराबर है।
  • XU , range XC बराबर है।
  • LU F का एक सबसेट है।
  • UU , F सबसेट है।
  • range UC , U सबसेट है।
  • M , AM + LM + UM बराबर है, जहां AM , LM और UM जोड़ीदार डिसऑइंट हैं।
  • ME (Mod) E बराबर है।
  • AE (App) E बराबर है।
  • RE (Rel) E बराबर है।
  • (Mod) V , M सबसेट है। समानता रखती है यदि सभी विश्लेषण किए गए मॉड्यूल में कुछ स्थानीय, निर्यात या अज्ञात फ़ंक्शन हैं।
  • (App) M , A सबसेट है। यदि सभी अनुप्रयोगों में कुछ मॉड्यूल हो तो समानता रखती है।
  • (Rel) A , R सबसेट है। यदि सभी रिलीज में कुछ अनुप्रयोग है तो समानता है।
  • DF_1 , DF_1 का सबसेट है।
  • DF_2 , DF_2 का सबसेट है।
  • DF_3 DF का एक सबसेट है।
  • DF , X + B का सबसेट है।

एक महत्वपूर्ण धारणा भावों के रूपांतरण की है। एक कास्ट एक्सप्रेशन का सिंटैक्स है:

  • अभिव्यक्ति :: = ( प्रकार ) अभिव्यक्ति

कास्ट ऑपरेटर की व्याख्या नाम प्रकार, Expression के प्रकार, और Expression की व्याख्या के तत्वों की संरचना पर निर्भर करती है। यदि नामित प्रकार अभिव्यक्ति प्रकार के बराबर है, तो कोई रूपांतरण नहीं किया जाता है। अन्यथा, रूपांतरण एक समय में एक कदम किया जाता है; (Fun) (App) RE , उदाहरण के लिए, (Fun) (Mod) (App) RE बराबर है। अब मान लें कि Expression की व्याख्या स्थिरांक (कार्यों, मॉड्यूल, अनुप्रयोग या रिलीज़) का एक सेट है। यदि नामित प्रकार अभिव्यक्ति Mod तुलना में अधिक सामान्य है, तो क्रमशः Mod और Fun कहें, तो कास्ट एक्सप्रेशन की व्याख्या उन मॉड्यूलों का समूह है जिनके अभिव्यक्ति की व्याख्या में उल्लेखित कम से कम एक फ़ंक्शन है। यदि नाम प्रकार अभिव्यक्ति प्रकार से अधिक विशेष है, तो Fun और Mod कहें, तो व्याख्या मॉड्यूल के सभी कार्यों का सेट है ( modules मोड में, रूपांतरण आंशिक है क्योंकि स्थानीय फ़ंक्शन ज्ञात नहीं हैं)। अनुप्रयोग और रिलीज़ से रूपांतरण कार्य को समान रूप से करते हैं। उदाहरण के लिए, (App) "xref_.*" : Mod सभी अनुप्रयोगों को देता है जिसमें कम से कम एक मॉड्यूल होता है जैसे कि xref_ मॉड्यूल नाम का एक उपसर्ग होता है।

अब मान लें कि Expression की व्याख्या कॉल का एक सेट है। यदि नामित प्रकार अभिव्यक्ति प्रकार की तुलना में अधिक सामान्य है, तो क्रमशः Mod और Fun कहें, तो कास्ट एक्सप्रेशन की व्याख्या कॉल का सेट है (एम 1, एम 2) जैसे कि अभिव्यक्ति की व्याख्या में एम 1 के कुछ फ़ंक्शन से कॉल शामिल है। M2 के कुछ फ़ंक्शन के लिए। अगर नाम का प्रकार अभिव्यक्ति के प्रकार से अधिक विशेष है, तो Fun और Mod कहें, तो व्याख्या सभी फ़ंक्शन कॉल (एफ 1, एफ 2) का सेट है जैसे कि अभिव्यक्ति की व्याख्या में कॉल (एम 1, एम 2) और एफ 1 है। एम 1 और एफ 2 का एक फ़ंक्शन एम 2 का एक फ़ंक्शन है ( modules मोड में, कोई फ़ंक्शन कॉल नहीं हैं, इसलिए Fun को एक कास्ट हमेशा एक खाली सेट देता है)। फिर से, अनुप्रयोगों और रिलीज से रूपांतरण अनुरूप काम करते हैं।

स्थिरांक और चर की व्याख्या सेट हैं, और उन सेटों को सेट ऑपरेटरों के आवेदन द्वारा नए सेट बनाने के आधार के रूप में उपयोग किया जा सकता है। वाक्य-विन्यास:

  • अभिव्यक्ति :: = अभिव्यक्ति BinarySetOp अभिव्यक्ति
  • बाइनरीसटैप :: = + | * -

+ , * और - क्रमशः संघ, प्रतिच्छेदन और अंतर के रूप में व्याख्या की जाती हैं: दो सेटों के संघ में दोनों सेटों के तत्व होते हैं; दो सेटों के प्रतिच्छेदन में दोनों सेटों के तत्व समान हैं; और दो सेटों के अंतर में पहले सेट के तत्व शामिल हैं जो दूसरे सेट के सदस्य नहीं हैं। दो सेट के तत्व एक ही संरचना के होने चाहिए; उदाहरण के लिए, एक फ़ंक्शन कॉल को फ़ंक्शन के साथ जोड़ा नहीं जा सकता। लेकिन अगर एक कास्ट ऑपरेटर तत्वों को संगत बना सकता है, तो अधिक सामान्य तत्व कम सामान्य तत्व प्रकार में परिवर्तित हो जाते हैं। उदाहरण के लिए, M + F (Fun) M + F बराबर है, और E - AE E - (Fun) AE बराबर है E - (Fun) AE । एक और उदाहरण: X * xref : Mod की व्याख्या मॉड्यूल xref द्वारा निर्यात किए गए फ़ंक्शंस के सेट के रूप में की जाती है; xref : Mod को और अधिक विशेष प्रकार के X ( Fun , अर्थात) में परिवर्तित किया जाता है, जो xref सभी कार्यों को पूरा करता है, और X साथ प्रतिच्छेदन (विश्लेषण किए गए मॉड्यूल और लाइब्रेरी मॉड्यूल द्वारा निर्यात किए गए सभी कार्यों) की व्याख्या उन कार्यों के रूप में की जाती है, जो कुछ के लिए निर्यात किए जाते हैं मॉड्यूल और xref कार्य।

अपर सेट ऑपरेटर भी हैं:

  • अभिव्यक्ति :: = UnarySetOp अभिव्यक्ति
  • UnarySetOp :: = domain | range | strict

याद रखें कि कॉल एक जोड़ी है (से, टू)। domain को कॉल के सेट पर लागू किया गया है, सभी कोने के सेट के रूप में व्याख्या की गई है, और सभी कोने के सेट के रूप में range strict संचालक की व्याख्या फॉर्म (ए, ए) हटाए गए फॉर्म पर सभी कॉल के साथ ऑपरेंड है।

प्रतिबंध ऑपरेटरों की व्याख्या पहले ऑपरेंड, कॉल का एक सेट का सबसेट है। दूसरा ऑपरेंड, वर्टिकल का एक सेट, पहले ऑपरेंड के प्रकार में बदल जाता है। प्रतिबंध ऑपरेटरों का सिंटैक्स:

  • अभिव्यक्ति :: = अभिव्यक्ति RestrOp अभिव्यक्ति
  • RestrOp :: = |
  • RestrOp :: = ||
  • RestrOp :: = |||

तीन ऑपरेटरों के लिए कुछ विस्तार से व्याख्या:

|
किसी भी कोने से कॉल का सबसेट।
||
किसी भी कोने पर कॉल का सबसेट।
|||
किसी भी कोने से और के लिए कॉल का सबसेट। कॉल के सभी सेटों के लिए CS और सभी सेट के वर्सेस VS , CS ||| VS CS ||| VS CS | VS * CS || VS बराबर है CS | VS * CS || VS CS | VS * CS || VS CS | VS * CS || VS

दो फ़ंक्शन (मॉड्यूल, एप्लिकेशन, रिलीज़) एक ही दृढ़ता से जुड़े घटक से संबंधित हैं यदि वे एक-दूसरे को सीधे (इन) कॉल करते हैं। components ऑपरेटर की व्याख्या कॉल के सेट के दृढ़ता से जुड़े घटकों का सेट है। कॉल के एक सेट का condensation दृढ़ता से जुड़े घटकों के बीच कॉल का एक नया सेट है जैसे कि दो घटकों के बीच एक बढ़त है अगर पहले घटक के कुछ स्थिर है जो दूसरे घटक के कुछ निरंतर कॉल करता है।

ऑपरेटर की व्याख्या दूसरे ऑपरेंड (कॉल का एक सेट) की कॉल की एक श्रृंखला है जो दिए गए क्रम में पहले ऑपरेंड (स्थिरांक का एक समूह) के सभी कोने को फेंकती है। दूसरा ऑपरेंड पहले ऑपरेंड के प्रकार में बदल जाता है। उदाहरण के लिए, ऑपरेटर का उपयोग यह पता लगाने के लिए किया जा सकता है कि क्या एक फ़ंक्शन अप्रत्यक्ष रूप से किसी अन्य फ़ंक्शन को कॉल करता है, और कॉल की श्रृंखला यह दर्शाती है कि कैसे। ग्राफ़ का सिंटैक्स विश्लेषण करने वाले ऑपरेटर:

  • अभिव्यक्ति :: = अभिव्यक्ति BinaryGraphOp अभिव्यक्ति
  • अभिव्यक्ति :: = UnaryGraphOp अभिव्यक्ति
  • UnaryGraphOp :: = components | condensation
  • बाइनरीग्राफऑप :: = of

जैसा कि पहले उल्लेख किया गया था, ग्राफ विश्लेषण ग्राफ़ के digraph प्रतिनिधित्व पर काम करते हैं। डिफ़ॉल्ट रूप से, digraph प्रतिनिधित्व तब बनाया जाता है जब जरूरत होती है (और अब उपयोग नहीं होने पर हटा दिया जाता है), लेकिन इसे closure ऑपरेटर के उपयोग से भी स्पष्ट रूप से बनाया जा सकता है:

  • अभिव्यक्ति :: = बंद करने की अभिव्यक्ति
  • क्लोजरओप :: = closure

closure ऑपरेटर की व्याख्या ऑपरेंड का ट्रांजिटिव क्लोजर है।

प्रतिबंध ऑपरेटरों को बंद करने के लिए भी परिभाषित किया गया है; closure E | xref : Mod closure E | xref : Mod की व्याख्या xref मॉड्यूल से प्रत्यक्ष या अप्रत्यक्ष फ़ंक्शन कॉल के रूप में की जाती है, जबकि E | xref : Mod की व्याख्या E | xref : Mod E | xref : Mod से प्रत्यक्ष कॉल का सेट है। यदि कुछ ग्राफ़ का उपयोग कई ग्राफ़ विश्लेषणों में किया जाना है, तो उपयोगकर्ता के चर को ग्राफ़ के digraph प्रतिनिधित्व को असाइन करने के लिए समय बचाता है, और फिर सुनिश्चित करें कि ग्राफ़ के सूची प्रतिनिधित्व के बजाय हर ग्राफ़ विश्लेषण उस चर पर काम करता है।

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

  • अभिव्यक्ति :: = ( लाइनऑप ) अभिव्यक्ति
  • अभिव्यक्ति :: = ( XLineOp ) अभिव्यक्ति
  • लाइनऑप :: = Lin | ELin | LLin | XLin
  • XLineOp :: = XXL

फ़ंक्शन के सेट पर लागू Lin ऑपरेटर की व्याख्या प्रत्येक फ़ंक्शन को उस पंक्ति संख्या को असाइन करती है जहां फ़ंक्शन परिभाषित होता है। पुस्तकालय मॉड्यूल के अज्ञात कार्यों और कार्यों को नंबर 0 सौंपा गया है।

फ़ंक्शन कॉल के सेट पर लागू किए गए कुछ लाइनओप ऑपरेटर की व्याख्या प्रत्येक कॉल को लाइन नंबर के सेट को असाइन करती है जहां पहला फ़ंक्शन दूसरे फ़ंक्शन को कॉल करता है। सभी ऑपरेटरों द्वारा सभी कॉल को पंक्ति संख्या नहीं दी गई है:

  • Lin ऑपरेटर को कॉल ग्राफ़ किनारों के लिए परिभाषित किया गया है;
  • LLin ऑपरेटर को स्थानीय कॉल के लिए परिभाषित किया गया है।
  • XLin ऑपरेटर को बाहरी कॉल के लिए परिभाषित किया गया है।
  • ELin ऑपरेटर को इंटर कॉल ग्राफ़ किनारों के लिए परिभाषित किया गया है।

Lin ( LLin , XLin ) ऑपरेटर उन लाइनों को असाइन करता है जहां कॉल (स्थानीय कॉल, बाहरी कॉल) किए जाते हैं। ELin ऑपरेटर प्रत्येक कॉल (से, टू) के लिए असाइन करता है, जिसके लिए इसे परिभाषित किया गया है, हर लाइन एल ऐसी है कि लाइन एल पर कॉल से शुरुआत से टू तक कॉल की एक श्रृंखला है।

XXL ऑपरेटर को फ़ंक्शन कॉल के सेट पर लागू लाइनऑप ऑपरेटरों में से किसी की व्याख्या के लिए परिभाषित किया गया है। इसका परिणाम यह है कि फ़ंक्शन कॉल को एक पंक्ति संख्याबद्ध फ़ंक्शन कॉल के साथ प्रतिस्थापित किया जाता है, अर्थात, कॉल के दो कार्यों में से प्रत्येक को फ़ंक्शन की एक जोड़ी और फ़ंक्शन को परिभाषित करने वाली लाइन द्वारा प्रतिस्थापित किया जाता है। XXL ऑपरेटर के प्रभाव को LineOp ऑपरेटरों द्वारा पूर्ववत किया जा सकता है। उदाहरण के लिए, (Lin) (XXL) (Lin) E , (Lin) (XXL) (Lin) E के बराबर है।

+ , - , * और # ऑपरेटरों को लाइन नंबर अभिव्यक्तियों के लिए परिभाषित किया गया है, बशर्ते कि ऑपरेंड संगत हों। LineOp ऑपरेटरों को मॉड्यूल, एप्लिकेशन और रिलीज़ के लिए भी परिभाषित किया गया है; ऑपरेंड को संक्षेप में फ़ंक्शन में बदल दिया गया है। इसी प्रकार, लाइन ऑपरेटर ऑपरेटरों की व्याख्या के लिए परिभाषित किया गया है।

काउंटिंग ऑपरेटर की व्याख्या एक सेट के तत्वों की संख्या है। क्लोजर के लिए ऑपरेटर अपरिभाषित है। संख्याओं पर लागू होने पर + , - और * ऑपरेटरों को स्पष्ट अंकगणितीय ऑपरेटरों के रूप में व्याख्या की जाती है। मतगणना संचालक का वाक्य विन्यास:

  • अभिव्यक्ति :: = CountOp अभिव्यक्ति
  • CountOp :: = #

सभी बाइनरी ऑपरेटर्स बाएं सहयोगी हैं; उदाहरण के लिए, A | B || C A | B || C A | B || C , (A | B) || C बराबर है (A | B) || C (A | B) || C । निम्नलिखित सभी ऑपरेटरों की एक सूची है, पूर्ववर्तीता के बढ़ते क्रम में:

  • + -
  • *
  • #
  • | , || ; |||
  • of
  • ( प्रकार )
  • closure , components , condensation , domain , range , strict

कोष्ठक का उपयोग समूहन के लिए किया जाता है, या तो अभिव्यक्ति को अधिक पठनीय बनाने के लिए या ऑपरेटरों की डिफ़ॉल्ट पूर्वता को ओवरराइड करने के लिए:

  • अभिव्यक्ति :: = ( अभिव्यक्ति )

क्वेरी बयानों का एक गैर-रिक्त अनुक्रम है। एक बयान या तो एक उपयोगकर्ता चर या अभिव्यक्ति का एक असाइनमेंट है। असाइनमेंट का मान दाएं हाथ की अभिव्यक्ति का मूल्य है। यह कहीं और एक सादा अभिव्यक्ति डाल करने के लिए कोई मतलब नहीं है, लेकिन पिछले प्रश्नों में। इन प्रस्तुतियों द्वारा प्रश्नों के वाक्य-विन्यास को संक्षेप में प्रस्तुत किया गया है:

  • प्रश्न :: = कथन , ...
  • कथन :: = असाइनमेंट | अभिव्यक्ति
  • असाइनमेंट :: = चर := अभिव्यक्ति | चर = अभिव्यक्ति

जब तक पहले हटाया नहीं जाता एक चर को एक नया मान नहीं सौंपा जा सकता है। = ऑपरेटर द्वारा असाइन किए गए चर क्वेरी के अंत में हटा दिए जाते हैं, जबकि := ऑपरेटर द्वारा असाइन किए गए चर केवल forget जाने के लिए कॉल द्वारा निकाले जा सकते हैं। जब मॉड्यूल डेटा को फिर से सेट करने की आवश्यकता होती है तो कोई उपयोगकर्ता चर नहीं होते हैं; यदि कोई भी फ़ंक्शन जो मॉड्यूल डेटा को फिर से सेट करने के लिए आवश्यक बनाता है, उसे फिर से कहा जाता है, सभी उपयोगकर्ता चर भूल जाते हैं।

प्रकार

application() = atom()
arity() = int() | -1
bool() = true | false
call() = {atom(), atom()} | funcall()
constant() = mfa() | module() | application() | release()
directory() = string()
file() = string()
funcall() = {mfa(), mfa()}
function() = atom()
int() = integer() >= 0
library() = atom()
library_path() = path() | code_path
mfa() = {module(), function(), arity()}
mode() = functions | modules
module() = atom()
release() = atom()
string_position() = int() | at_end
variable() = atom()
xref() = atom() | pid()  

निर्यात

add_application (Xref, Directory [, Options]) -> {ok, application ()} | त्रुटि

प्रकार

एक एप्लिकेशन, मॉड्यूल के अनुप्रयोग और module data को एक Xref server जोड़ता Xref server । मॉड्यूल अनुप्रयोग के सदस्य होंगे। डिफॉल्ट का उपयोग अनुप्रयोग के नाम के रूप में हटाए गए संस्करण के साथ निर्देशिका के आधार नाम का उपयोग करना है, लेकिन यह name विकल्प द्वारा ओवरराइड किया जा सकता है। आवेदन का नाम लौटाता है।

यदि दी गई निर्देशिका में ebin नाम का उपनिर्देशिका है, तो उस निर्देशिका में मॉड्यूल (BEAM फाइलें) खोजी जाती हैं, अन्यथा दिए गए निर्देशिका में मॉड्यूल खोजे जाते हैं।

यदि Xref सर्वर का mode functions , तो ऐसी BEAM फाइलें जिनमें कोई debug information को अनदेखा कर दिया जाता है।

add_directory (Xref, निर्देशिका [, विकल्प]) -> {ठीक है, मॉड्यूल} | त्रुटि

प्रकार

दिए गए निर्देशिका में पाए गए modules' data और modules' data को एक Xref server में जोड़ता Xref server । डिफ़ॉल्ट उपनिर्देशिकाओं की जांच करने के लिए नहीं है, लेकिन अगर विकल्प recurse का मूल्य true , तो मॉड्यूल सभी स्तरों पर उपनिर्देशिकाओं के साथ-साथ दिए गए निर्देशिका में खोजे जाते हैं। जोड़े गए मॉड्यूल के नामों की क्रमबद्ध सूची देता है।

जोड़े गए मॉड्यूल किसी भी एप्लिकेशन के सदस्य नहीं होंगे।

यदि Xref सर्वर का mode functions , तो ऐसी BEAM फाइलें जिनमें कोई debug information को अनदेखा कर दिया जाता है।

add_module (Xref, फ़ाइल [, विकल्प]) -> {ठीक है, मॉड्यूल ()} | त्रुटि

प्रकार

एक मॉड्यूल और उसके module data को एक Xref server जोड़ता है। मॉड्यूल किसी भी एप्लिकेशन का सदस्य नहीं होगा। मॉड्यूल का नाम लौटाता है।

यदि Xref सर्वर का mode functions , और BEAM फ़ाइल में कोई debug information , तो त्रुटि संदेश no_debug_info वापस आ गया है।

add_release (Xref, निर्देशिका [, विकल्प]) -> {ठीक है, जारी ()} | त्रुटि

प्रकार

एक रिलीज, अनुप्रयोगों के रिलीज, अनुप्रयोगों के module data और module data को एक Xref server जोड़ता है। अनुप्रयोग रिलीज़ के सदस्य होंगे, और मॉड्यूल अनुप्रयोगों के सदस्य होंगे। डिफॉल्ट में डायरेक्टरी के बेस नेम को रिलीज के नाम के रूप में उपयोग करना है, लेकिन यह name विकल्प द्वारा ओवरराइड किया जा सकता है। रिलीज का नाम देता है।

यदि दी गई निर्देशिका में उपनिर्देशिका नाम दिया गया है, तो उस निर्देशिका में निर्देशिकाओं को अनुप्रयोग निर्देशिका माना जाता है, अन्यथा दी गई निर्देशिका के सभी उपनिर्देशिकाओं को अनुप्रयोग निर्देशिका माना जाता है। यदि कुछ एप्लिकेशन के कई संस्करण हैं, तो उच्चतम संस्करण वाले को चुना जाता है।

यदि Xref सर्वर का mode functions , तो ऐसी BEAM फाइलें जिनमें कोई debug information को अनदेखा कर दिया जाता है।

विश्लेषण (Xref, विश्लेषण [, विकल्प]) -> {ठीक है, उत्तर} | त्रुटि

प्रकार

एक पूर्वनिर्धारित विश्लेषण का मूल्यांकन करता है। चुने हुए विश्लेषण के आधार पर, call() या constant() डुप्लिकेट के बिना एक क्रमबद्ध सूची देता है। पूर्वनिर्धारित विश्लेषण, जो सभी analyzed modules पर काम करते हैं, (विश्लेषण के साथ चिह्नित हैं (*) केवल functions mode में उपलब्ध हैं):

undefined_function_calls (*)
undefined functions लिए कॉल की सूची लौटाता है।
undefined_functions
undefined functions की सूची देता है।
locals_not_used (*)
उन स्थानीय कार्यों की सूची लौटाता है जिनका स्थानीय स्तर पर उपयोग नहीं किया गया है।
exports_not_used
निर्यात किए गए कार्यों की एक सूची लौटाता है जो बाहरी रूप से उपयोग नहीं किए गए हैं।
deprecated_function_calls (*)
deprecated functions लिए बाहरी कॉल की सूची लौटाता है।
{deprecated_function_calls, DeprFlag} (*)
हटाए गए कार्यों के लिए बाहरी कॉल की सूची लौटाता है। यदि DeprFlag के बराबर है, तो अगले संस्करण में निकाले जाने वाले फ़ंक्शन को कॉल लौटा दी जाती है। यदि DeprFlag के बराबर है, तो अगली बड़ी रिलीज़ में हटाए जाने वाले फ़ंक्शन को कॉल के साथ-साथ अगले संस्करण में निकाले जाने वाले फ़ंक्शन को भी कॉल किया जाता है। अंत में, अगर DeprFlag eventually बराबर है, तो DeprFlag जाने वाले फ़ंक्शन के सभी कॉल वापस कर दिए जाते हैं, जिसमें अगले संस्करण या अगले प्रमुख रिलीज़ में हटाए जाने वाले फ़ंक्शन भी शामिल हैं।
deprecated_functions
बाह्य रूप से उपयोग किए गए पदावनत कार्यों की सूची लौटाता है।
{deprecated_functions, DeprFlag}
बाह्य रूप से उपयोग किए गए पदावनत कार्यों की सूची लौटाता है। यदि DeprFlag के बराबर है, तो अगले संस्करण में निकाले जाने वाले फ़ंक्शन वापस कर दिए जाते हैं। यदि DeprFlag के बराबर है, तो अगली बड़ी रिलीज़ में हटाए जाने वाले फ़ंक्शंस लौटा दिए जाते हैं और साथ ही फ़ंक्शंस को अगले वर्जन में हटा दिया जाता है। अंत में, अगर DeprFlag eventually बराबर है, तो DeprFlag सभी फ़ंक्शन वापस कर दिए जाते हैं, जिसमें अगले संस्करण या मुख्य रिलीज़ में हटाए जाने वाले फ़ंक्शन भी शामिल हैं।
{call, FuncSpec} (*)
दिए गए कार्यों में से कुछ के द्वारा कहे गए कार्यों की सूची लौटाता है।
{use, FuncSpec} (*)
दिए गए कार्यों में से कुछ का उपयोग करने वाले कार्यों की एक सूची देता है।
{module_call, ModSpec}
दिए गए मॉड्यूल में से कुछ द्वारा मॉड्यूल की सूची लौटाता है।
{module_use, ModSpec}
मॉड्यूल की एक सूची देता है जो दिए गए कुछ मॉड्यूल का उपयोग करता है।
{application_call, AppSpec}
दिए गए अनुप्रयोगों में से कुछ द्वारा बुलाए गए आवेदनों की सूची लौटाता है।
{application_use, AppSpec}
दिए गए अनुप्रयोगों में से कुछ का उपयोग करने वाले अनुप्रयोगों की सूची लौटाता है।
{release_call, RelSpec}
दिए गए रिलीज़ में से कुछ के द्वारा जारी रिलीज़ की सूची लौटाता है।
{release_use, RelSpec}
दिए गए रिलीज़ में से कुछ का उपयोग करने वाले रिलीज़ की सूची लौटाता है।
d (निर्देशिका) -> [DebugInfoResult] | [NoDebugInfoResult] | त्रुटि

प्रकार

दिए गए निर्देशिका में पाए गए मॉड्यूल को चेक किए गए deprecated functions लिए कॉल, undefined functions लिए कॉल और अप्रयुक्त स्थानीय कार्यों के लिए जांच की जाती है। कोड पथ का उपयोग library path रूप में किया जाता library path

यदि कुछ मिली हुई BEAM फ़ाइलों में debug information , तो उन मॉड्यूल की जाँच की जाती है और टुपल्स की एक सूची दी जाती है। प्रत्येक टपल का पहला तत्व इनमें से एक है:

  • deprecated , दूसरा तत्व पदावनत कार्यों के लिए कॉल की एक क्रमबद्ध सूची है;
  • undefined , दूसरा तत्व अपरिभाषित कार्यों के लिए कॉल की एक क्रमबद्ध सूची है;
  • unused , दूसरा तत्व अप्रयुक्त स्थानीय कार्यों की एक क्रमबद्ध सूची है।

यदि कोई BEAM फ़ाइल में डिबग जानकारी नहीं है, तो ट्यूपल्स की एक सूची वापस आ जाती है। प्रत्येक टपल का पहला तत्व इनमें से एक है:

  • deprecated , दूसरा तत्व बाह्य रूप से उपयोग किए गए पदावनत कार्यों की क्रमबद्ध सूची है;
  • undefined , दूसरा तत्व अपरिभाषित कार्यों की क्रमबद्ध सूची है।
भूल जाओ (Xref) -> ठीक है
भूल जाओ (Xref, चर) -> ठीक है | त्रुटि

प्रकार

forget/1 और forget/2 एक xref server सभी या कुछ user variables निकालें।

format_error (त्रुटि) -> शुल्क

प्रकार

इस मॉड्यूल के किसी फ़ंक्शन द्वारा दी गई त्रुटि को देखते हुए, फ़ंक्शन format_error अंग्रेजी में त्रुटि का एक वर्णनात्मक स्ट्रिंग लौटाता है। फ़ाइल त्रुटियों के लिए, फ़ाइल format_error/1 में फ़ंक्शन format_error/1 कहा जाता है।

get_default (Xref) -> [{विकल्प, मूल्य}]
get_default (Xref, विकल्प) -> {ठीक है, मान} | त्रुटि

प्रकार

एक या अधिक विकल्पों के डिफ़ॉल्ट मान लौटाता है।

get_library_path (Xref) -> {ठीक है, LibraryPath}

प्रकार

library path लौटाता है।

जानकारी (Xref) -> [जानकारी]
जानकारी (Xref, श्रेणी) -> [{आइटम, [जानकारी]}]
जानकारी (Xref, श्रेणी, आइटम) -> [{आइटम, [जानकारी]}]

प्रकार

info फ़ंक्शन राज्य की और Xref server के module data के बारे में कुछ क्रम में जोड़े {टैग, शब्द ()} की सूची के रूप में जानकारी लौटाते हैं।

निम्नलिखित टैग के साथ info/1 रिटर्न की जानकारी (टैग के साथ चिह्नित (*) केवल functions मोड में उपलब्ध हैं):

  • library path , library path ;
  • mode , mode ;
  • no_releases , रिलीज़ की संख्या;
  • no_applications , अनुप्रयोगों की कुल संख्या (सभी रिलीज़ की);
  • no_analyzed_modules , analyzed modules की कुल संख्या;
  • no_calls (*), कुल कॉल की संख्या (सभी मॉड्यूल में), अलग-अलग कॉल के रूप में अलग-अलग लाइनों में एक फ़ंक्शन कॉल के उदाहरणों के बारे में;
  • no_function_calls (*), कुल local calls , हल की गई external calls और unresolved calls ;
  • no_functions (*), स्थानीय और निर्यात कार्यों की कुल संख्या;
  • no_inter_function_calls (*), Inter Call Graph की कुल संख्या।

Xref सर्वर के सभी या कुछ विश्लेषण किए गए मॉड्यूल, एप्लिकेशन, रिलीज़ या लाइब्रेरी मॉड्यूल के बारे में info/2 और info/3 वापसी। हर विश्लेषण किए गए मॉड्यूल के लिए निम्न जानकारी दी गई है:

  • application यदि मॉड्यूल किसी एप्लिकेशन से संबंधित नहीं है, तो एक खाली सूची, अन्यथा एप्लिकेशन नाम की एक सूची;
  • builtins , क्या बीआईएफ को कॉल मॉड्यूल के डेटा में शामिल हैं;
  • directory निर्देशिका, जहां मॉड्यूल BEAM फ़ाइल स्थित है;
  • no_calls (*), विभिन्न कॉल के रूप में विभिन्न लाइनों में एक फ़ंक्शन कॉल के उदाहरणों के संबंध में कॉल की संख्या;
  • no_function_calls (*), स्थानीय कॉल की संख्या, बाहरी कॉल और अनसुलझे कॉल का समाधान;
  • no_functions (*), स्थानीय और निर्यात कार्यों की संख्या;
  • no_inter_function_calls (*), इंटर कॉल ग्राफ़ की कॉल की संख्या;

निम्नलिखित जानकारी हर आवेदन के लिए लौटा दी गई है:

  • directory निर्देशिका, जहां मॉड्यूल 'BEAM फाइलें स्थित हैं;
  • no_analyzed_modules विश्लेषण किए गए मॉड्यूल की संख्या;
  • no_calls (*), एप्लिकेशन के मॉड्यूल की कॉल की संख्या, अलग-अलग कॉल के रूप में विभिन्न लाइनों में एक फ़ंक्शन कॉल के उदाहरणों के बारे में;
  • no_function_calls (*), स्थानीय कॉल की संख्या, बाहरी कॉल और एप्लिकेशन के मॉड्यूल की अनसुलझे कॉल;
  • no_functions (*), अनुप्रयोग के मॉड्यूल के स्थानीय और निर्यात कार्यों की संख्या;
  • no_inter_function_calls (*), एप्लिकेशन के मॉड्यूल के इंटर कॉल ग्राफ़ की कॉल की संख्या;
  • release एक खाली सूची अगर आवेदन किसी भी रिलीज से संबंधित नहीं है, अन्यथा रिलीज नाम की सूची;
  • version संख्याओं की सूची के रूप में अनुप्रयोग का संस्करण। उदाहरण के लिए, निर्देशिका "कर्नेल-2.6" आवेदन नाम kernel और आवेदन संस्करण [2,6] में परिणाम देता है ; "कर्नेल" नाम kernel और संस्करण देता है []।

निम्न सूचना हर रिलीज़ के लिए वापस की जाती है:

  • directory रिलीज़ निर्देशिका;
  • no_analyzed_modules विश्लेषण किए गए मॉड्यूल की संख्या;
  • no_applications आवेदनों की संख्या;
  • no_calls (*), रिलीज के मॉड्यूल की कॉल की संख्या, अलग-अलग कॉल के रूप में विभिन्न लाइनों में एक फ़ंक्शन कॉल के उदाहरणों के बारे में;
  • no_function_calls (*), स्थानीय कॉल की संख्या, बाहरी कॉल और रिलीज के मॉड्यूल के अनसुलझे कॉल;
  • no_functions (*), रिलीज के मॉड्यूल के स्थानीय और निर्यात कार्यों की संख्या;
  • no_inter_function_calls (*), रिलीज के मॉड्यूल के इंटर कॉल ग्राफ की कॉल की संख्या।

प्रत्येक लाइब्रेरी मॉड्यूल के लिए निम्न जानकारी दी गई है:

  • directory , निर्देशिका जहां library module's BEAM फ़ाइल स्थित है।

हर नंबर पर कॉल, फ़ंक्शंस आदि के लिए no_ टैग द्वारा लौटाया गया , उसी नंबर पर एक क्वेरी लौटाया जाता है। नीचे सूचीबद्ध ऐसे प्रश्नों के उदाहरण हैं। कुछ क्वेरीज़ no_ टैग संख्याओं में से दो या अधिक का योग लौटाती हैं। mod ( ) app , rel किसी भी मॉड्यूल (अनुप्रयोग, रिलीज) को संदर्भित करता है।

  • no_analyzed_modules

    • "# AM" (जानकारी / 1)
    • "# (Mod) app:App" (आवेदन)
    • "# (Mod) rel:Rel" (जारी)
  • no_applications

    • "# A" (जानकारी / 1)
  • no_calls । हल और अनसुलझे कॉल की संख्या का योग:

    • "# (XLin) E + # (LLin) E" (जानकारी / 1)
    • "T = E | mod:Mod, # (LLin) T + # (XLin) T" (मॉड्यूल)
    • "T = E | app:App, # (LLin) T + # (XLin) T" (आवेदन)
    • "T = E | rel:Rel, # (LLin) T + # (XLin) T" (जारी)
  • no_functions । पुस्तकालय मॉड्यूल में कार्य और कार्यों की module_info/0,1 गणना नहीं की जाती है info । मान "Extra := _:module_info/\"(0|1)\" + LM" लिया गया है कि , स्थानीय और निर्यात कार्यों की संख्या का योग है:

    • "# (F - Extra)" (जानकारी / 1)
    • "# (F * mod:Mod - Extra)" (मॉड्यूल)
    • "# (F * app:App - Extra)" (आवेदन)
    • "# (F * rel:Rel - Extra)" (जारी)
  • no_function_calls । स्थानीय कॉल की संख्या का योग, बाहरी कॉल और अनसुलझे कॉल का समाधान:

    • "# LC + # XC" (जानकारी / 1)
    • "# LC | mod:Mod + # XC | mod:Mod" (मॉड्यूल)
    • "# LC | app:App + # XC | app:App" (आवेदन)
    • "# LC | rel:Rel + # XC | mod:Rel" (जारी)
  • no_inter_function_calls

    • "# EE" (जानकारी / 1)
    • "# EE | mod:Mod" (मॉड्यूल)
    • "# EE | app:App" (आवेदन)
    • "# EE | rel:Rel" (जारी)
  • no_releases

    • "# R" (जानकारी / 1)
m (मॉड्यूल) -> [DebugInfoResult] | [NoDebugInfoResult] | त्रुटि
m (फ़ाइल) -> [DebugInfoResult] | [NoDebugInfoResult] | त्रुटि

प्रकार

दी गई BEAM फ़ाइल ( .beam एक्सटेंशन के साथ या बिना ) या कॉल द्वारा पाई गई फ़ाइल code:which(Module) को कॉल deprecated functions , कॉल undefined functions , और अप्रयुक्त कार्यों के लिए जाँच की जाती है । कोड पथ के रूप में प्रयोग किया जाता है library path

यदि BEAM फ़ाइल शामिल है debug information , तो ट्यूपल्स की एक सूची वापस आ जाती है। प्रत्येक टपल का पहला तत्व इनमें से एक है:

  • deprecated दूसरा तत्व पदावनत कार्यों के लिए कॉल की एक क्रमबद्ध सूची है;
  • undefined दूसरा तत्व अपरिभाषित कार्यों के लिए कॉल की एक क्रमबद्ध सूची है;
  • unused दूसरा तत्व अप्रयुक्त स्थानीय कार्यों की एक क्रमबद्ध सूची है।

यदि BEAM फ़ाइल में डिबग जानकारी नहीं है, तो ट्यूपल्स की सूची वापस आ जाती है। प्रत्येक टपल का पहला तत्व इनमें से एक है:

  • deprecated दूसरा तत्व बाह्य रूप से उपयोग किए गए पदावनत कार्यों की क्रमबद्ध सूची है;
  • undefined दूसरा तत्व अपरिभाषित कार्यों की क्रमबद्ध सूची है।
q (Xref, क्वेरी [, विकल्प]) -> {ठीक है, उत्तर} | त्रुटि

प्रकार

एक query के संदर्भ में एक का मूल्यांकन करता है Xref server , और अंतिम विवरण का मूल्य लौटाता है। मान का सिंटैक्स अभिव्यक्ति पर निर्भर करता है:

  • डुप्लिकेट के बिना किसी क्रमबद्ध सूची द्वारा कॉल का एक सेट दर्शाया गया है call()
  • स्थिरांक का एक सेट बिना डुप्लिकेट के एक क्रमबद्ध सूची द्वारा दर्शाया गया है constant()
  • दृढ़ता से जुड़े घटकों का एक सेट डुप्लिकेट के बिना एक सॉर्ट की गई सूची है Component
  • दृढ़ता से जुड़े घटकों के बीच कॉल का एक सेट डुप्लिकेट के बिना एक सॉर्ट की गई सूची है ComponentCall
  • कॉल की एक श्रृंखला को सूची के द्वारा दर्शाया गया है constant() । सूची में प्रत्येक कॉल के शीर्ष से और अंतिम कॉल के शीर्ष से समाहित है।
  • of ऑपरेटर देता है false अगर दिया स्थिरांक के बीच कॉल की कोई श्रृंखला पाया जा सकता है।
  • closure ऑपरेटर ( मूल्य) का मान digraph परमाणु द्वारा दर्शाया जाता है 'closure()'
  • पंक्तिबद्ध फ़ंक्शन का एक सेट बिना डुप्लिकेट के एक सॉर्ट की गई सूची द्वारा दर्शाया गया है DefineAt
  • लाइन संख्याबद्ध फ़ंक्शन कॉल का एक सेट बिना डुप्लिकेट के एक सॉर्ट की गई सूची द्वारा दर्शाया गया है CallAt
  • पंक्तिबद्ध फ़ंक्शन और फ़ंक्शन कॉल का एक सेट डुप्लिकेट के बिना किसी क्रमबद्ध सूची द्वारा दर्शाया गया है AllLines

दोनों के लिए CallAt और AllLines यह मानता है कि बिना किसी सूची तत्व के LineNumbers एक खाली सूची है; ऐसे तत्वों को हटा दिया गया है। के स्थिरांक component और पूर्णांक LineNumbers क्रमबद्ध और बिना डुप्लिकेट के होते हैं।

remove_application (Xref, Applications) -> ठीक | त्रुटि

प्रकार

अनुप्रयोगों और उनके मॉड्यूल को निकालता है और ए module data से Xref server

remove_module (Xref, मॉड्यूल) -> ठीक | त्रुटि

प्रकार

निकालता है analyzed modules और ए module data से Xref server

remove_release (Xref, Releases) -> ठीक | त्रुटि

प्रकार

विज्ञप्ति और उनके अनुप्रयोग, मॉड्यूल और module data एक से निकालता है Xref server

प्रतिस्थापन_प्प्लिकेशन (Xref, अनुप्रयोग, निर्देशिका [, विकल्प]) -> {ठीक है, आवेदन ()} | त्रुटि

प्रकार

एप्लिकेशन के मॉड्यूल को किसी अन्य एप्लिकेशन निर्देशिका से पढ़े गए अन्य मॉड्यूल के साथ बदल देता है। एप्लिकेशन की रिलीज़ सदस्यता बरकरार रखी गई है। ध्यान दें कि आवेदन का नाम रखा गया है; दिए गए निर्देशिका के नाम का उपयोग नहीं किया गया है।

प्रतिस्थापन_मॉडल (Xref, मॉड्यूल, फ़ाइल [, विकल्प]) -> {ठीक है, मॉड्यूल ()} | त्रुटि

प्रकार

एक BEAM फ़ाइल से पढ़े गए डेटा module data की जगह analyzed module । मॉड्यूल की एप्लिकेशन सदस्यता बरकरार है, और इसलिए builtins मॉड्यूल के विकल्प का मूल्य है । यदि रीड मॉड्यूल का नाम दिए गए मॉड्यूल से भिन्न होता है, तो एक त्रुटि लौटा दी जाती है।

update समारोह कंपाइल मॉड्यूल के मॉड्यूल डेटा अद्यतन करने के लिए एक विकल्प है।

set_default (Xref, विकल्प, मूल्य) -> {ठीक है, ओल्डवैल्यू} | त्रुटि
set_default (Xref, OptionValues) -> ठीक | त्रुटि

प्रकार

एक या अधिक विकल्पों का डिफ़ॉल्ट मान सेट करता है। इस तरह सेट किए जा सकने वाले विकल्प हैं:

  • builtins प्रारंभिक डिफ़ॉल्ट मान के साथ false ;
  • recurse प्रारंभिक डिफ़ॉल्ट मान के साथ false ;
  • verbose प्रारंभिक डिफ़ॉल्ट मान के साथ false ;
  • warnings प्रारंभिक डिफ़ॉल्ट मान के साथ true

प्रारंभिक डिफ़ॉल्ट मान सेट करते समय बनाए जाते हैं Xref server

set_library_path (Xref, LibraryPath [, Options]) -> ok | त्रुटि

प्रकार

सेट करता है library path । यदि दिए गए मार्ग निर्देशिकाओं की सूची है, library modules तो दिए गए क्रम में निर्देशिकाओं का पता लगाने के दौरान पहले मॉड्यूल का चयन करके निर्धारित किया जाता है, उन मॉड्यूल के लिए जो एक से अधिक निर्देशिका में होते हैं। डिफ़ॉल्ट रूप से, लाइब्रेरी पथ एक खाली सूची है।

पुस्तकालय पथ code_path का उपयोग कार्यों द्वारा किया जाता है m/1 और d/1 , लेकिन यह भी स्पष्ट रूप से सेट किया जा सकता है। हालांकि ध्यान दें कि कोड पथ को library module मॉड्यूल डेटा सेट करते समय उपयोग किए गए प्रत्येक के लिए एक बार ट्रैवर्स किया जाएगा । दूसरी ओर, यदि केवल कुछ मॉड्यूल हैं जो उपयोग किए जाते हैं लेकिन विश्लेषण नहीं किए जाते हैं, code_path तो लाइब्रेरी पथ को सेट करने की तुलना में उपयोग करना तेज हो सकता है code:get_path()

यदि लाइब्रेरी पथ पर सेट है code_path , तो लाइब्रेरी मॉड्यूल का सेट निर्धारित नहीं है, और info फ़ंक्शन लाइब्रेरी मॉड्यूल की खाली सूची लौटाएगा।

start (NameOrOptions) -> लौटें

प्रकार

बनाता है a Xref server । प्रक्रिया को वैकल्पिक रूप से एक नाम दिया जा सकता है। डिफ़ॉल्ट mode है functions । जिन विकल्पों को Xref द्वारा मान्यता प्राप्त नहीं है, उन्हें पास किया जाता है gen_server:start/4

प्रारंभ (नाम, विकल्प) -> वापसी

प्रकार

Xref server दिए गए नाम के साथ बनाता है । डिफ़ॉल्ट mode है functions । जिन विकल्पों को Xref द्वारा मान्यता प्राप्त नहीं है, उन्हें पास किया जाता है gen_server:start/4

बंद करो (xref)

प्रकार

रुक जाता है Xref server

अद्यतन (Xref [, विकल्प]) -> {ठीक है, मॉड्यूल} | त्रुटि

प्रकार

बदलता है module data सब की analyzed modules बीम फ़ाइलें जिनमें से आखिरी एक द्वारा पढ़ा के बाद से संशोधित किया गया है add समारोह या update । मॉड्यूल की एप्लिकेशन सदस्यता बरकरार है, और इसलिए builtins विकल्प का मूल्य है । बदले हुए मॉड्यूल के नामों की क्रमबद्ध सूची देता है।

चर (Xref [, विकल्प]) -> {ठीक है, [VariableInfo]}

प्रकार

के चर के नामों की क्रमबद्ध सूची देता है Xref server । डिफ़ॉल्ट को user variables केवल वापस करना है ।

यह भी देखें

beam_lib(3) , digraph(3) , digraph_utils(3) , re(3) , TOOLS User's Guide

Original text