लाजर वह जैसा है

अक्सर, हमारे अपने तर्क में इस मुद्दे और आत्मविश्वास को समझने की अनिच्छा गलत धारणाओं को जन्म देती है। एक सार्वजनिक मंच पर बयान के रूप में व्यक्त की गई ये धारणाएं दृढ़ता से दूसरों के दिमाग में बस सकती हैं और गलत नकारात्मक विचारों का निर्माण कर सकती हैं।

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

कथन : निष्पादन योग्य फ़ाइलों का आकार खराब है। संकलक, लिंकर, आदि को दोष देना है।

इस विषय पर कुछ जानकारी विकि पृष्ठ पर पाई जा सकती है।

तो, निष्पादन योग्य फ़ाइल के आकार का मुख्य घटक डीबगिंग जानकारी है। डिबगिंग जानकारी FPC संकलक द्वारा तब जोड़ी जाती है जब "-g" स्विच को इसमें पास किया जाता है। एफपीसी 2 प्रकार की डिबगिंग जानकारी उत्पन्न कर सकता है: अप्रचलित स्टैब्स और आधुनिक बौना (संस्करण 2 या 3), जो कंपाइलर को पारित की गई कुंजियों द्वारा भी निर्धारित किया जाता है। दोनों प्रकार की डिबगिंग जानकारी को gdb डीबगर द्वारा समझा जाता है। लाजर में, आप डिबगिंग जानकारी को सक्षम / अक्षम कर सकते हैं, और परियोजना सेटिंग्स में "लेआउट" टैब पर इसकी उपस्थिति भी निर्धारित कर सकते हैं:

यदि आप विंडोज या लिनक्स के तहत एक परियोजना का निर्माण कर रहे हैं, तो आप एक बाहरी डिबगिंग प्रतीक फ़ाइल बना सकते हैं। इस स्थिति में, डिबगिंग जानकारी को निष्पादन योग्य फ़ाइल में नहीं जोड़ा जाएगा, और इसके बजाय बाहरी डीबगिंग फ़ाइल का लिंक रखा जाएगा।

डिबगिंग जानकारी का अपवाद Windows पर 20MB से 1.6MB तक एक खाली परियोजना के आकार को कम करता है। लेकिन, 1.6MB भी 300Kb से अधिक है, जो डेल्फी 7 ने बाहर कर दिया (उदाहरण के लिए डेल्फी XE, पहले से ही RTTI सूजन के कारण बहुत अधिक देता है)। यह संकलक या लिंकर का मामला नहीं है, जो अपना काम सही ढंग से करते हैं, लेकिन पूरा बिंदु एलसीएल में है।

LCL - लाजर कंपोनेंट लाइब्रेरी आर्किटेक्चरली में दो भाग होते हैं: फ्रंट एंड - एप्लीकेशन डेवलपर्स के लिए एक प्लेटफ़ॉर्म-इंडिपेंडेंट क्लास लाइब्रेरी (TForm, TButton, TLabel, ...) और बैकेंड - एक विशिष्ट प्लेटफ़ॉर्म (win32, qt, gtk2) के लिए इन घटकों को लागू करने के लिए जिम्मेदार हिस्सा। ..)। बैकएंड के प्रारंभिक कार्यान्वयन के दौरान, किसी ने वास्तव में निष्पादन योग्य फ़ाइलों के आकार के बारे में नहीं सोचा था और सामान्य तरीकों को लिखा था जिसमें उन्होंने सभी फ्रंटेंड वर्गों को संबोधित किया था।

उदाहरण के लिए, lcl \ interfaces \ win32 \ win32proc.pp मॉड्यूल से निम्न कोड TCustomGroupBox, TCustomTabControl वर्गों को निष्पादन योग्य फ़ाइल में खींचता है, भले ही आप उन्हें कहीं भी उपयोग न करें:
if (TheWinControl is TCustomGroupBox) then
begin
...
end else
if TheWinControl is TCustomTabControl then
begin
...
end;


रिफैक्टिंग करने से इस समस्या को हल किया जा सकता है, लेकिन इसके लिए काफी प्रयास और समय की आवश्यकता होती है, जो हाथों की कमी की स्थिति में अन्य समस्याओं को सुलझाने में खर्च करना बेहतर होता है। मुझे कहना होगा कि इस दिशा में कुछ प्रयास २ या ३ साल पहले किए गए थे, जो एक खाली परियोजना के आकार को ३०० केबी के रूप में कम करने की अनुमति देते थे।

कथन : लाजर एक बार विंडोज पर स्थापित किया गया था, और यह याद किया गया था कि एक खिड़की और एक बटन के साथ सबसे सरल कार्यक्रम भी लंबे समय तक संकलित करता है।

समस्या तब थी जब FPC ने विंडोज के लिए GNU लिंकर का उपयोग किया था। लेकिन, एफपीसी 2.2 (और अब लाजर एफपीसी 2.6 का उपयोग करता है) में, समस्या विंडोज के लिए एक एकीकृत लिंकर विकसित करके तय की गई थी। इसके अलावा, उस समय, GNU लिंकर Win64 प्लेटफॉर्म के तहत निर्माण करने में सक्षम नहीं था, जिसने अपने स्वयं के अंतर्निहित लिंकर के विकास को भी प्रेरित किया। यह ध्यान दिया जाना चाहिए कि लिनक्स और डार्विन के तहत बिल्ड स्पीड के साथ ऐसी कोई समस्या नहीं थी (और परिणामस्वरूप इन प्लेटफार्मों के लिए अभी भी कोई लिंकर नहीं है)।

अब असेंबल करना और मेरी मशीन पर एक फॉर्म के साथ एक खाली प्रोजेक्ट शुरू करना 2 सेकंड से अधिक नहीं लगता है।

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

अतिरिक्त पैकेज बनाकर डॉकिंग को सक्षम किया जा सकता है, लेकिन यह अनुशंसित नहीं है, क्योंकि अभी भी कई अनसुलझे मुद्दे हैं। संस्करण 1.2 तक, डॉकिंग तैयार हो जाएगा और सबसे अधिक संभावना तुरंत पर्यावरण में निर्मित होगी।

कथन : "मैक ओएस एक्स: 10.4, एलसीएल केवल 32 बिट है, गैर-एलसीएल 64 बिट हो सकता है।" हाँ, प्रभावशाली।

सबसे पहले, इसका मतलब है कि लाजर मैक ओएस एक्स के लिए संस्करण 10.4 से कम नहीं की परियोजनाओं को इकट्ठा करता है। यही है, 10.5 और 10.6 और 10.7 और 10.8 समर्थित हैं (जिस पर लाजर वर्तमान में मुझ पर चल रहा है)। LCL प्रोजेक्ट्स केवल 32 बिट हो सकते हैं।

यह इस तथ्य के कारण है कि मैक्स ओएस एक्स पर 2 मुख्य सिस्टम लाइब्रेरी हैं: कार्बन और कोको। कार्बन पहले दिखाई दिया और कार्यों का एक पुस्तकालय था। इसके आधार पर एलसीएल बैकएंड बनाने में कोई समस्या नहीं थी, जो किया गया था। Apple ने एक और कोको लाइब्रेरी शुरू की, जिसमें कार्यों के बजाय ऑब्जेक्टिव-सी कक्षाएं शामिल हैं। बाद में, Apple ने घोषणा की कि वह कार्बन लाइब्रेरी को 64 बिट नहीं बनाएगा, और सामान्य रूप से नए अनुप्रयोगों को केवल कोको के लिए विकसित किया जाना चाहिए।

ऑब्जेक्टिव-सी कक्षाओं के साथ बातचीत करने के लिए, एफपीसी में ऑब्जेक्टिव-पास्कल नामक एक बोली जोड़ी गई है। कोको के लिए एक बैकएंड भी लाजर में जोड़ा गया है, लेकिन यह वर्तमान में विकास में है। यह संभव है (मैं इसके लिए एक प्रयास करूँगा), संस्करण 1.2 तक यह gtk2 और qt के तहत बैकेंड स्तर पर होगा।