Ninja: निंजा विशिष्टता के बारे में स्पष्टीकरण

को निर्मित 1 अप्रैल 2015 · 9टिप्पणियाँ · स्रोत: ninja-build/ninja

मामूली स्पष्टीकरण का गुच्छा:

1. निंजा मैनुअल में कुछ जगहों पर "व्हाट्सएप" का उल्लेख है; पूरी तरह से इसका क्या मतलब है? क्या टैब और/या कैरिज रिटर्न को व्हाइटस्पेस माना जाता है? (तथ्य यह है कि निंजा अज्ञेय को एन्कोडिंग कर रहा है, कम से कम यह बताता है कि यूनिकोड व्हाइटस्पेस की अनुमति नहीं है।)

वर्तमान निंजा कार्यान्वयन \ r और \ t पर त्रुटि प्रतीत होता है। "व्हाट्सएप" के बजाय केवल "रिक्त स्थान" कहना और \ r और \ t के बारे में नियम को स्पष्ट रूप से बताना स्पष्ट हो सकता है।

2. क्या स्वीकार्य चर नामों पर कोई प्रतिबंध है? क्या "foo$ bar = 3" एक वैध चर असाइनमेंट है? क्या "${foo bar}" और/या "${foo$ bar}" उस वेरिएबल के मान्य संदर्भ हैं?

ऐसा लगता है कि निंजा कार्यान्वयन केवल [a-zA-Z0-9_.-]+ (विशेष रूप से "42" जैसे पहचानकर्ताओं को अनुमति देता है) जैसे पहचानकर्ताओं को अनुमति देता है, हालांकि "${foo}" सिंटैक्स को उन पहचानकर्ताओं के लिए उपयोग करने की आवश्यकता है जिनमें अवधि है . यह कहीं भी प्रलेखित प्रतीत नहीं होता है।

3. "यदि कोई रेखा पिछले वाले से अधिक इंडेंट की जाती है, तो उसे उसके पैरेंट स्कोप का हिस्सा माना जाता है; यदि यह पिछले वाले से कम इंडेंट किया जाता है, तो यह पिछले स्कोप को बंद कर देता है।"

यह स्पष्ट नहीं है कि "इसके माता-पिता" का क्या अर्थ है, आईएमओ।

इसके अलावा, इस इनपुट के लिए कड़ाई से व्याख्या की गई है:

rule foo
    x = 1
    y = 2
  z = 3

"y = 2" लाइन "पिछले एक से अधिक" (यानी, "x = 1") इंडेंट नहीं है, इसलिए इसे _not_ इसके माता-पिता के दायरे का हिस्सा माना जाना चाहिए।

इसी तरह, "z = 3" लाइन को "पिछले एक से कम" इंडेंट किया गया है, इसलिए इसे "पिछले स्कोप को बंद करना चाहिए"।

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

4. ऐसा लगता है कि असाइनमेंट स्टेटमेंट के दाईं ओर रिक्त स्थान की संख्या महत्वपूर्ण है, लेकिन इसका कहीं भी उल्लेख नहीं किया गया है जो मैं बता सकता हूं।

5. टिप्पणियाँ केवल स्टैंडअलोन लाइनों के रूप में काम करने लगती हैं, हालांकि सहज रूप से मैंने उनसे शेल टिप्पणियों की तरह व्यवहार करने की अपेक्षा की होगी। शायद ध्यान देने योग्य है।

6. युक्ति कहती है "बिल्ड ब्लॉक (या नियम का उपयोग करता है) में विस्तारित चर के लिए पूर्ण लुकअप ऑर्डर है: [...] 2. बिल्ड ब्लॉक से बिल्ड-स्तरीय चर।"

लेकिन वर्तमान कार्यान्वयन इस बिल्ड को देखते हुए "इको 1 2 4" चलाता है।

rule echo
    command = echo $args
args = 1
args = $args 2
build hello: echo
    args = $args 3
    args = $args 4

7. वर्तमान कार्यान्वयन "$!" जैसे अपरिभाषित एस्केप अनुक्रमों को अस्वीकार करता है; दस्तावेज के लायक लगता है कि $ के अन्य उपयोग अमान्य हैं।

8. शाब्दिक "|" के लिए कोई एस्केप अनुक्रम नहीं है वर्ण, हालांकि यह फ़ाइल नामों के लिए एक असामान्य वर्ण है।

स्रोत

mdempsky

👍1

सबसे उपयोगी टिप्पणी

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

तब आप टैब पर से प्रतिबंध हटाने पर विचार कर सकते हैं, क्योंकि स्वरूपण की एक विशिष्ट शैली को लागू करना केवल मेक की गलती को दोहराना है।

लेक्सर को केवल तभी त्रुटि उठानी चाहिए जब टैब और रिक्त स्थान एक ही फ़ाइल में मिश्रित हों , जिसे (निश्चित रूप से) प्रतिबंधित किया जाना चाहिए। पहली इंडेंट लाइन शेष फ़ाइल के लिए अपेक्षित इंडेंटेशन सेट कर सकती है।

Alhadis 27 नव॰ 2016

👍2

सभी 9 टिप्पणियाँ

मेलिंग सूची में इसे लाने के लिए बेहतर हो सकता है, या उन मुद्दों पर अलग बग फाइल करें जिन्हें आप विशेष रूप से ठीक करना चाहते हैं। :) दस्तावेज़ों में #5 डालने जैसी सामग्री एक साधारण पुल अनुरोध की तरह लगती है।

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

रे 3, मूल रूप से मैंने इंडेंटिंग के कई नेस्टेड स्कोप (जैसे हास्केल "कहां" क्लॉज) की कल्पना की थी और फिर यह कभी भी उपयोगी नहीं रहा। मैं सहमत हूं कि दस्तावेज़ माता-पिता के सभी उल्लेखों को हटा सकते हैं और केवल "इंडेंट या नहीं" को सरल बना सकते हैं।

रु 4, क्या आप विस्तार से बता सकते हैं?

7 और 8 रुपये, यह हालिया धागा देखें: https://groups.google.com/forum/#!topic/ninja -build/UVYk9RhCE4M

evmar 2 अप्रैल 2015

आइटम 4 के लिए, इन दो बिल्डों का व्यवहार समान है:

build a.out: link foo.o bar.o
build a.out: link foo.o  bar.o

लेकिन इन दोनों नियमों का व्यवहार अलग है:

rule hello_one_space_world
    command = echo "hello world"
rule hello_two_space_world
    command = echo "hello  world"

मैं समझता हूं क्यों, लेकिन मुझे नहीं लगता कि यह मैनुअल से बहुत स्पष्ट है।

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

mdempsky 2 अप्रैल 2015

fwiw, मैंने कुछ समय पहले निंजा फाइलों के लिए एक औपचारिक (पीईजी) व्याकरण लिखा था कि मेरा मतलब निंजा दस्तावेज़ों में विलय होना था लेकिन इसके आसपास कभी नहीं मिला। मुझे लगता है कि यह आपके अधिकांश सवालों का जवाब देगा ...

https://github.com/dpranke/glop/blob/master/test_grammars/ninja.pymeta

dpranke 2 अप्रैल 2015

हाँ ये भी भिन्न हैं:

command = echo foo$
  bar
command = echo foo $
  bar

मैं मानता हूं कि इसका इलाज करने का सबसे अच्छा तरीका यह है कि = एक विशेष रूप से लेक्स्ड सेक्शन शुरू करता है (जैसे " सी में विशेष रूप से लेक्सेड सेक्शन कैसे शुरू होता है)।

evmar 2 अप्रैल 2015

dpranke: धन्यवाद, यह मददगार है। (हालांकि मैं कुछ हद तक विसंगतियों को नोट करता हूं; क्या उन्हें कहीं लिखना उपयोगी है?)

इससे मुझे यह भी एहसास होता है कि आप पहचानकर्ताओं (जैसे, नियम और चर नाम) को लपेटने के लिए "$\n" का उपयोग नहीं कर सकते हैं, इसलिए लेक्सर को उन लोगों को भी देखने के लिए प्रासंगिक रूप से जानने की जरूरत है (पथ और मूल्यों के विपरीत, जहां यह है अनुमति दी)। ऐसा लगता है कि सभी विशेष मामले इस तरह के एक साधारण व्याकरण के लिए पारंपरिक लेक्सर + पार्सर जनरेटर समाधान अव्यवहारिक बनाते हैं। खूंटी यहाँ अच्छा लगता है।

mdempsky 2 अप्रैल 2015

बुधवार, 1 अप्रैल, 2015 को शाम 5:38 बजे, मैथ्यू डेम्पस्की नोटिफिकेशन @github.com
लिखा था:

dpranke: धन्यवाद, यह मददगार है। (मैं कुछ हद तक विसंगतियों को नोट करता हूं
यद्यपि; क्या उन्हें कहीं लिखना उपयोगी है?)
हां, अगर विसंगतियां हैं तो मेरा अजगर निंजा क्लोन शायद है
छोटी गाड़ी और मैं इसे ठीक करना चाहूंगा :)। हमें व्याकरण को भी इसमें धकेलना चाहिए
निंजा डॉक्स।

dpranke 2 अप्रैल 2015

कार्यान्वयन में, दो लेक्सर्स हैं: एक टोकन पढ़ने के लिए (जो $ को नहीं समझता है) और दूसरा पहचानकर्ताओं और चर मानों को पढ़ने के लिए (जो $ को समझता है)। दुर्भाग्य से जैसा कि आप देखते हैं कि इसका मतलब है कि लेक्सिंग पार्स पर निर्भर है।

evmar 2 अप्रैल 2015

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

Alhadis 27 नव॰ 2016

👍2

https://github.com/ninja-build/ninja/issues/510

jonesmz 5 फ़र॰ 2020

👍1

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Ninja: निंजा विशिष्टता के बारे में स्पष्टीकरण

सबसे उपयोगी टिप्पणी

सभी 9 टिप्पणियाँ

संबंधित मुद्दों