आपकी यूनिट्स पढ़ता है
यह वर्किंग फोल्डर में .pas और .dpr फाइलों की सूची बनाता है, खोजता है और खोलता है, और फिर आपको यह दिखाता है कि उसने कौन सी फाइलें और लाइनें खोजीं।
Pascal प्रोग्रामिंग में Arraydeck, जो Windows 10 और 11 के लिए एक स्वतंत्र AI एजेंट है, एक कामकाजी साझेदार बनकर आता है। यह आपकी यूनिट्स खोलता है, उन्हें खोजता है, संपादित करता है और आपकी बिल्ड कमांड चलाता है, और हर एक्शन चैट में एक कार्ड के रूप में दिखाई देता है जिसमें उसका वास्तविक परिणाम होता है, ताकि आप हर कदम पर काम को ट्रैक कर सकें और यह अनुमान न लगाएं कि क्या हुआ।
यह वर्किंग फोल्डर में .pas और .dpr फाइलों की सूची बनाता है, खोजता है और खोलता है, और फिर आपको यह दिखाता है कि उसने कौन सी फाइलें और लाइनें खोजीं।
हर edit_file बदलाव एक diff के रूप में दिखाई देता है, और Ask first मोड में आप किसी भी बदलाव को लागू करने से पहले उसे स्वीकार या अस्वीकार कर सकते हैं।
Shell आपकी अपनी बिल्ड और टेस्ट कमांड्स चलाता है और यह अनुमान नहीं लगाता कि वे पास हुईं या नहीं, बल्कि वास्तविक exit code रिपोर्ट करता है।
हर कदम चैट में एक कार्ड है। कार्ड टूल, फाइल या कमांड और परिणाम का नाम बताता है, और एक विस्तारित कार्ड पूरा कमांड आउटपुट या diff दिखाता है, इसलिए हर एक्शन के लिए सबूत आपके सामने रहता है जब आप अगला स्वीकार करने का निर्णय लेते हैं।
*.pas4 फाइलेंTStringList.Create2 मैचReport.pasपढ़ाReport.pas+5 -1build.batexit 0एक डेलफी डेवलपर जो एक प्रोजेक्ट विरासत में पाता है, अक्सर एक यूनिट खोलता है जिस पर वर्षों से कोई काम नहीं हुआ है। Arraydeck से इसे समझाने के लिए कहें। एजेंट read_file कॉल करता है, फिर interface सेक्शन, implementation सेक्शन और uses क्लॉज को सरल शब्दों में वर्णन करता है, और grep दिखाता है कि इसके प्रोसीयर्स को अन्य यूनिट्स से कहाँ कॉल किया गया है। कुछ लिखा नहीं जाता। जवाब को एक मानचित्र के रूप में उपयोग करें, प्रमाण के रूप में नहीं: प्रत्येक दावे की तुलना स्रोत से करें, अपने एडिटर में यूनिट खोलें और अपनी बिल्ड कमांड चलाएं, जो वास्तविक exit code रिपोर्ट करती है, इससे पहले कि आप प्रोजेक्ट की एक लाइन भी बदलें। जब पहली यूनिट स्पष्ट हो जाए, तो अगली यूनिट के लिए रिक्वेस्ट दोहराएं।
स्ट्रिंग में Unicode कोड कन्वर्ट करने के लिए, पहले उस रूटीन को खोजें जो टेक्स्ट बनाता या विभाजित करता है। एजेंट फंक्शन नाम के लिए grep चलाता है, read_file के साथ यूनिट पढ़ता है और edit_file के साथ एक बदलाव सुझाता है। Ask first में diff आपका इंतजार करता है। Shell फिर आपकी बिल्ड कमांड और टेस्ट कमांड चलाता है, और प्रत्येक कार्ड वास्तविक exit code दिखाता है। स्ट्रिंग्स सिंगल क्वोट्स का उपयोग करते हैं और := एक मान असाइन करता है, इसलिए पुराने रूटीन के काम करने के तरीके के सापेक्ष diff पढ़ें, अपने डेटा से टेक्स्ट के साथ इसे टेस्ट करें और यदि कोई केस अलग व्यवहार करता है तो बदलाव को अस्वीकार करें। टेस्ट सहमत होने तक पुराने रूटीन की एक कॉपी रखें।
लोगों को यह बहस होती है कि एक फंक्शन में कितने रिटर्न होने चाहिए, और Arraydeck यह चयन आपको छोड़ देता है। एक फंक्शन चुनें जिसमें कई एग्जिट हैं और एक ऐसे वर्जन के लिए कहें जो Result को एक बार सेट करता है। एजेंट यूनिट पढ़ता है, फंक्शन को संपादित करता है और बदलाव को diff के रूप में दिखाता है। Pascal प्रोग्रामिंग रिटर्न वैल्यू को Result में रखता है, इसलिए एडिट छोटा है और लाइन-दर-लाइन जांचने में आसान है। टेस्ट को बाद में चलाएं, क्योंकि एजेंट यह वादा नहीं कर सकता कि नया वर्जन पुराने जैसा व्यवहार करेगा, और यदि कोई टेस्ट फेल होता है तो diff को अस्वीकार करें। एक छोटा, समीक्षित एडिट एक बड़े रीराइट से बेहतर है।
अपने प्रोजेक्ट में FMX डायलॉग्स को सही ढंग से उपयोग करने के लिए, एजेंट से हर जगह खोजने के लिए कहें जहां एक डायलॉग दिखाया जाता है। यह .pas फाइलों पर grep चलाता है, read_file के साथ मैच खोलता है और चैट में एक छोटी सूची लिखता है, प्रत्येक यूनिट और प्रत्येक इवेंट हैंडलर का नाम बताते हुए। बटन क्लिक जैसे इवेंट फॉर्म के प्रोसीयर्स होते हैं, इसलिए सूची एक विषय सूची की तरह पढ़ी जाती है। बदलावों के लिए Ask first में स्विच करें, प्रत्येक diff की समीक्षा करें और फॉर्म को स्वयं टेस्ट करें, क्योंकि एजेंट फॉर्म को विज़ुअल रूप से डिज़ाइन नहीं करता है। प्रत्येक फॉर्म के लिए दोहराएं।
Arraydeck एक होस्टेड सर्विस या एडिटर प्लगइन नहीं है। यह केवल आपके अपने फाइलों, आपके पीसी और सर्वरों के लिए है जिनका उपयोग करने की अनुमति आपको है, और आप उनमें काम रखते हैं: फाइल टूल्स चैट के वर्किंग फोल्डर में काम करते हैं, लेकिन Shell, वेब और SSH उसमें सीमित नहीं हैं। यह यह वादा नहीं कर सकता कि कोड या विश्लेषण सही है, इसलिए हर diff को पढ़ें, प्रोजेक्ट को बिल्ड करें और किसी बदलाव पर भरोसा करने से पहले अपने टेस्ट चलाएं।