Spyder: स्पाइडर 4.0.0 लाइनों को जोड़ने या हटाने के दौरान असहनीय रूप से धीमा

@gabrielclow , आपका वर्णन पर्याप्त नहीं है। कृपया पोस्ट करें:

1. आप किस प्रकार की फ़ाइलों का संपादन कर रहे हैं (पायथन या अन्य)?
2. आपके पास कितनी लाइनें हैं?
3. क्या आपके पास "इंडेंट गाइड" जैसी चीजें सक्षम हैं?

अंत में, कृपया एक वीडियो पोस्ट करें (लाइसेंस के साथ एनिमेटेड जिफ़) समस्या यह देखने के लिए कि आप वास्तव में क्या संदर्भित कर रहे हैं।

@gabrielclow , आपका वर्णन पर्याप्त नहीं है। कृपया पोस्ट करें:

1. आप किस प्रकार की फ़ाइलों का संपादन कर रहे हैं (पायथन या अन्य)?
2. आपके पास कितनी लाइनें हैं?
3. क्या आपके पास "इंडेंट गाइड" जैसी चीजें सक्षम हैं?

अंत में, कृपया एक वीडियो पोस्ट करें (लाइसेंस के साथ एनिमेटेड जिफ़) समस्या यह देखने के लिए कि आप वास्तव में क्या संदर्भित कर रहे हैं।

1. मैं केवल .py फाइलें संपादित कर रहा हूं
2. ऐसा नहीं लगता कि यह लाइनों की संख्या पर निर्भर करता है। 5k लाइनों के साथ 50 से बड़ी लाइनों वाली छोटी फाइलों में होता है।
3. मैं केवल ऑटो-पूर्ण (स्क्रीनशॉट में कॉन्फ़िगर) का उपयोग करता हूं। बाकी को बंद कर दिया गया है (कोई लाइनिंग नहीं, कोई कोड स्टाइल लाइनिंग नहीं, कोई डॉकस्ट्रिंग लाइनिंग नहीं, कोई इंडेंट गाइड नहीं)। मेरी कोई दूसरी भाषा नहीं है और मैंने पतंग उड़ाने की कोशिश भी की।

Gif में, मैं Enter दबाए रखता हूं, नई लाइनों के बनने की प्रतीक्षा करता हूं और फिर उन्हें हटाने के लिए Ctrl + Z को पकड़ता हूं (Ctrl + D के समान प्रभाव, इसलिए मैं अनुमान लगा रहा हूं कि इसका भी कोई लेना-देना नहीं है। छोटा रास्ता)। स्पाइडर तब रुक जाता है और लाइनों को सुचारू रूप से करने के बजाय धीरे-धीरे जोड़ता और हटाता है:

अद्यतन : जाहिरा तौर पर, अगर मैं कुछ फ़ाइलों को बंद कर देता हूं तो धीमा कम ध्यान देने योग्य है!
अद्यतन 2 : इसके अलावा, धीमा करने की मात्रा स्पष्ट रूप से प्रत्येक फ़ाइल में खुली फ़ाइलों की संख्या + लाइनों की संख्या से संबंधित है, लेकिन यह वर्तमान में चयनित एक की परवाह किए बिना होता है। अगर मैं केवल कुछ छोटी फाइलें रखता हूं और बाकी को बंद कर देता हूं, तो यह बहुत आसान है
अपडेट 3 : यदि मैं बहुत लंबा पकड़ता हूं या बहुत तेज दबाता हूं, तो स्पाइडर कुछ देर के लिए लटक भी सकता है

इसके अलावा, धीमा होने की मात्रा स्पष्ट रूप से खुली फ़ाइलों की संख्या से संबंधित है

जब आपने सबसे खराब मंदी देखी तो आपने कितनी फाइलें खोली हैं?

इसके अलावा, धीमा होने की मात्रा स्पष्ट रूप से खुली फ़ाइलों की संख्या से संबंधित है

जब आपने सबसे खराब मंदी देखी तो आपने कितनी फाइलें खोली हैं?

मैं ज्यादातर 6-8 फाइलों के साथ काम करता हूं। आमतौर पर उनमें से दो बड़े होते हैं (4k-5k लाइनें) और बाकी 100-500 लाइनों वाली छोटी फाइलें होती हैं।

@ CAM-Gerlach, क्या आपने इससे पहले ऐसा कुछ देखा है?

अगर मैं इस पर टिप्पणी कर सकता हूं, तो मुझे भी वही समस्या हो रही है, जिसने वास्तव में मुझे स्पाइडर 4 की स्थापना रद्द कर दी और स्पाइडर 3.3.6 पर वापस चला गया।
मेरे पास केवल वही सेटिंग्स सक्षम हैं जो स्पाइडर 3 में भी सक्षम हैं, इसलिए पीईपी 8 चेकिंग; कोड पूरा होने और विवरण सक्षम हैं; लेकिन कोई डॉकस्ट्रिंग चेकिंग नहीं; कोड के टुकड़े; होवर वर्णन; पतंग; आदि।
मंदी को @gabrielclow के GIF के रूप में दिखाया गया है, हालांकि इसे सम्मिलित करने के लिए कभी-कभी 2 सेकंड के लिए अधिक से अधिक सेकंड लग सकते हैं।

जैसा कि मैं बड़े पैकेजों का निर्माण करता हूं, मेरे लिए 30-50 पायथन फ़ाइलों को एक साथ खोलना असामान्य नहीं है, जिनमें से कुछ में कोड की 3k से अधिक लाइनें आसानी से हो सकती हैं (जब मैं बड़े पैमाने पर मंदी को देख रहा था तो मेरे पास ये खुले थे)।
चूंकि मैं ज्यादातर समय अपनी स्क्रिप्ट को संपादित करने के लिए एक साथ 3 मॉनिटर का उपयोग करता हूं, जो कि अधिकतम 8 पैनल पकड़ सकता है, और मुझे अक्सर फाइलों के बीच स्विच करने की आवश्यकता होती है, इनमें से अधिकांश फाइलों को बंद करना मेरे लिए काम नहीं करेगा।

मुझे व्यक्तिगत रूप से यह महसूस होता है कि इस मंदी का मुख्य कारण यह है कि कुछ डेटाबेस और स्क्रिप्ट ऐसे हैं जिन्हें अपडेट करने / चलाने की आवश्यकता होती है जब भी एक खुली फाइल को संशोधित किया जाता है।

क्या किसी भी संयोग से, एक स्क्रिप्ट जो सभी फ़ाइलों में सभी लाइनों पर चलाई जाती है जब भी कोई फ़ाइल संशोधित होती है?
यह बताता है कि मंदी सभी खुली फाइलों में संयुक्त कुल पंक्तियों की संख्या के साथ क्यों लगती है, और ऐसा क्यों लगता है कि फ़ाइल संपादित की जा रही है।

मैं इस बग की पुष्टि कर सकता हूं। मेरे कंप्यूटर पर यह इतना बुरा नहीं है (अब तक वास्तव में नोटिस नहीं किया गया है) लेकिन टेक्स्ट जोड़ने की तुलना में लाइन जोड़ना / हटाना बहुत धीमा है। यदि आप इसे दबाए रखते हैं तो प्रवेश समस्या वास्तव में ध्यान देने योग्य है।

@ कोलकोन , हम इसे कैसे पुन: पेश कर सकते हैं?

लगभग 40 फाइलें खोलें और यह बहुत अच्छा लगता है। ऐसा लगता है कि docdidchange में कुछ ऐसा हो सकता है जो सभी फाइलों को जाँच रहा है न कि केवल सक्रिय को। शायद आउटलाइनर।

@ ccordoba12 जहां तक ​​मैं बता सकता हूं, यह व्यवहार मूल रूप से # 8864 के समान है, और निश्चित रूप से मैं इसे स्पाइडर 4 पर स्वच्छ सेटिंग्स के साथ सिर्फ mainwindow.py इतनी बार फिर से खोल सकता हूं, जब तक इंडेंट गाइड सक्षम है ( स्प्लिट पैन होने से लैग डबल या अधिक हो जाता है)। हटाई गई लाइनों में एक ही प्रमुख अंतराल है (बिल्कुल यहां वर्णित है; ~ 1s विलंबता और ~ 1s के साथ एक मध्यम शक्तिशाली मशीन पर देरी को दोहराते हैं, और तराजू लंबाई और विभाजन पैन की संख्या को आनुपातिक रूप से खोलने के लिए) अन्य चीजों के रूप में मैंने परीक्षण किया। वहाँ (चलती लाइनें, लाइनों को डुप्लिकेट करना, आदि), और मैं पुष्टि कर सकता हूं कि यह अभी भी स्पाइडर 4 फाइनल पर होता है केवल साफ फाइल के साथ और mainwindow.py साफ सेटिंग्स के साथ खुला।

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

क्या किसी भी संयोग से, एक स्क्रिप्ट जो सभी फ़ाइलों में सभी लाइनों पर चलाई जाती है जब भी कोई फ़ाइल संशोधित होती है?

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

@ ccordoba12 जहां तक ​​मैं बता सकता हूं, यह व्यवहार मूल रूप से # 8864 के समान है, और निश्चित रूप से मैं इसे स्पाइडर 4 पर स्वच्छ सेटिंग्स के साथ सिर्फ mainwindow.py इतनी बार फिर से खोल सकता हूं, जब तक इंडेंट गाइड सक्षम है ( स्प्लिट पैन होने से लैग डबल या अधिक हो जाता है)।

अगर मैं अपनी 50 फाइलों को खोलने और 8 स्प्लिट पैन (जो कि आमतौर पर मैं अपनी फाइलों को एडिट करता हूं) के साथ इंडेंट गाइड को भी सक्षम करता हूं, तो लैग 6 से 10 सेकंड प्रति नई लाइन के बीच कहीं भी बढ़ जाता है।
मैं जिस कंप्यूटर का उपयोग कर रहा हूं वह एक हाई-एंड गेमिंग डेस्कटॉप है, इसलिए यह वास्तव में मशीन की शक्ति के कारण नहीं है।

@ बाल्थाविज़ और मैंने असफल रूप से # 8864 को पुन: पेश करने की कोशिश की। तो कहने के लिए खेद है, लेकिन जब तक हम इसे पुन: पेश करने में सक्षम नहीं होते हैं, तब तक इसके बारे में हम कुछ नहीं कर सकते।

लगभग 40 फाइलें खोलें और यह बहुत अच्छा लगता है। ऐसा लगता है कि docdidchange में कुछ ऐसा हो सकता है जो सभी फाइलों को जाँच रहा है न कि केवल सक्रिय को। शायद आउटलाइनर।

ठीक है, यह एक अच्छी शुरुआत है। हम इसे बाहर की जाँच करेंगे।

@ ccordoba12 मैंने इस अंतराल के स्रोत का पता लगा लिया है, जो वास्तव में स्पाइडर 4 बनाम स्पाइडर 3 में महसूस की गई मुख्य "आधार रेखा" प्रतीत होता है कि मैंने थोड़ी देर के लिए बात की है: जैसा कि @bcolsen ने सुझाव दिया था, वास्तव में रूपरेखा फलक है, हालांकि यह वास्तव में कहा जाता है कि क्या फलक खुला या बंद है। कम-अंत वाली मशीन पर, यह वास्तव में केवल temp.py और mainwindow.py खुले होने के साथ ही दिखाई देता है, और कुछ भी सक्षम नहीं है और कोई रूपरेखा फलक खुली नहीं है। यहां साफ-सुथरी सेटिंग्स को रिप्रजेंट करना है:

1. mainwindow.py और एक स्प्लिट एडिटर पैनल खोलें, और मेनप्रेमो दिखाने के लिए दाएं पैनल सेट करें और मेनविंडो दिखाने के लिए बाएं।
2. लेफ्ट पैनल में डिलीट / डुप्लिकेट / मूव लाइन को दबाए रखें (मेनविंडो), अनडू / रिडू, इत्यादि। एक छोटा लेकिन ध्यान देने योग्य अंतराल स्पष्ट है।
3. आउटलाइन फलक खोलें (जो डिफ़ॉल्ट रूप से छिपा हुआ था)। यह (एक मामूली लेकिन उपयोगी स्पष्ट बग के कारण) फ़ाइल को आउटलाइन फलक में दिखाई गई फ़ाइल को एक-ध्यान केंद्रित करता है, जिसके कारण फ़ाइल को खोलने पर सक्रिय विभाजन पैनल के बजाय सही-सबसे विभाजित पैनल में सक्रिय दिखाने के लिए स्विच करना / अनहोनी।
4. मेनविंडो में पुनः हटाने / आदि / लाइनें। बहुत कम अंतराल मौजूद है और दोहराने की दर अधिक है (संभावना कम प्रदर्शन मशीनों के साथ अधिक ध्यान देने योग्य होगी)
5. आउटलाइन एक्सप्लोरर को ठीक से दिखाने के लिए राइट पैनल (temp.py) पर क्लिक करें, और फिर लेफ्ट पैनल (मेनविंडो) पर वापस जाएं।
6. हटाने / आदि का पुनः प्रयास करें, और लैग वापस आ गया है, चरण 2 में भी (जब आउटलाइन एक्सप्लोरर दिखाई नहीं दे रहा था)

कई फाइलों के साथ इसका परीक्षण करने के लिए, मैंने import os spyder डायरेक्टरी में खोजा, पहली 40-50 फाइलें एक स्प्लिट पैनल व्यू में खोलीं (कम बड़ी फाइलें बराबर प्रभाव उत्पन्न करें) और बार-बार चरण 2-6 से ऊपर। एक छोटी फ़ाइल पर भी, लैग की एक बड़ी मात्रा थी (मेनविंडो पर इंडेंट गाइड लेवल के समान) जब दोनों चरण 2 और 6 में लाइनें हटाई जाती हैं (आउटलाइन एक्सप्लोरर छिपा हुआ है, और सक्रिय फ़ाइल पर दिखाया गया है), जबकि अनिवार्य रूप से कोई नहीं था लैग (जैसे कि कोई फाइल खुली नहीं थी, या स्पाइडर 3 लेवल) स्टेप 4 पर (आउटलाइन एक्सप्लोरर खुला और सक्रिय फाइल से डी-सिंक हुआ)।

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

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

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

मुझे आशा है कि आप उत्तर पा सकते हैं और यह जल्द ही ठीक हो जाता है इसलिए मैं 4.0.0 में महान अंधेरे मोड का उपयोग कर सकता हूं

मैं इस बात की पुष्टि कर सकता हूं कि हर बार एक लाइन जोड़ी जाती है या खुली हुई सभी फाइलों के आउटलाइनर अपडेट को हटा दिया जाता है। यह लाइन हटाने / जोड़ के लिए समय में वृद्धि की ओर जाता है जो फाइलों की संख्या के साथ बढ़ता है। मैंने उपरोक्त पीआर में एक सरल "फिक्स" बनाया है जो कई खुली फाइलों के साथ समस्या का समाधान करता है। @ प्रभाव 27 विचार?

एक अलग लेकिन स्पष्ट रूप से जुड़ा मुद्दा यह है कि बड़ी फाइलें (> 2000 लाइनें) भी लाइन में बदलाव के साथ अपडेट करने के लिए धीमी हैं। इन बड़ी फ़ाइलों में से 4 या 5 के पास होने से वर्तमान में अद्यतन के साथ चीजें भी धीमी हो जाती हैं। उपरोक्त पैच के साथ, जो समस्या @ CAM-Gerlach ऊपर बता रही है वह अभी भी बड़ी फ़ाइल पर होगी लेकिन छोटी फ़ाइल हमेशा तेज़ होनी चाहिए।

एक अलग लेकिन स्पष्ट रूप से जुड़ा मुद्दा यह है कि बड़ी फाइलें (> 2000 लाइनें) भी लाइन में बदलाव के साथ अपडेट करने के लिए धीमी हैं। इन बड़ी फ़ाइलों में से 4 या 5 के पास होने से वर्तमान में अद्यतन के साथ चीजें भी धीमी हो जाती हैं। उपरोक्त पैच के साथ, जो समस्या @ CAM-Gerlach ऊपर बता रही है वह अभी भी बड़ी फ़ाइल पर होगी लेकिन छोटी फ़ाइल हमेशा तेज़ होनी चाहिए।

ऐसा लगता है कि हमें UI ब्लॉक करने की प्रक्रिया को एक सूत्र में बदलने की आवश्यकता है।

ऐसा लगता है कि हमें UI ब्लॉक करने की प्रक्रिया को एक सूत्र में बदलने की आवश्यकता है।

यह सबसे अच्छा होगा। मुझे लगता है कि यह उस बिंदु पर वाक्यविन्यास हाइलाइटर के साथ जुड़ा हुआ है।

मुझे लगता है कि यह उस बिंदु पर वाक्यविन्यास हाइलाइटर के साथ जुड़ा हुआ है।

हाँ, क्यूटी के सिंटेक्स हाइलाइटर इन्फ्रास्ट्रक्चर के बाद से एक समस्या है जो मुख्य धागे पर चलती है: - \ _

@bcolsen केवल वर्तमान फ़ाइल को अपडेट करने के अलावा, यह भी अपडेट नहीं होना चाहिए कि क्या आउटलाइन एक्सप्लोरर भी दिखाई नहीं दे रहा है (जैसा कि मेरा परीक्षण अभी पुष्टि करता है)।

मुझे भी वही समस्या हो रही है।
स्पाइडर बेहद धीमा हो गया है।
मुझे आशा है कि अगर कोई पैकेज है जिसे मुझे अपडेट करने की आवश्यकता है।

@NaderNazemi जैसा कि आप इस मुद्दे से देख सकते हैं, हमने व्यापक परीक्षण किया है, मुद्दे के कारणों को अलग किया है और पहले से ही एक हल लागू किया है जो ज्यादातर इसे स्पाइडर 4.0.1 में हल करना चाहिए जो बहुत जल्द जारी किया जाएगा, और अधिक सुधार के साथ। मार्ग। कृपया धैर्य रखें, या यदि आप एक उन्नत उपयोगकर्ता हैं तो आप अपने आप को ठीक करने की कोशिश करने के लिए जीथब से नवीनतम स्पाइडर विकास शाखा का परीक्षण कर सकते हैं। धन्यवाद।

मैं देख रहा हूं कि यह ठीक हो गया है, लेकिन मेरे 4.1.4 संस्करण में (संभवत: वहां नए संस्करण हैं) समस्या तब होती है जब पतंग स्वत: पूर्णता ऐप बंद हो जाती है।

अरे @Duidi , हमें बताने के लिए धन्यवाद। बस FYI करें, स्पाइडर 4.1.5 कुछ हफ्तों पहले कुछ मामूली सुधारों के साथ जारी किया गया था, और वास्तविक समय कोड विश्लेषण / इंडेंट गाइड / आदि को स्क्रॉल करने, टाइप करने और उपयोग करने पर संपादक के प्रदर्शन को बेहतर बनाने के लिए कई बड़े बदलाव किए गए थे। या तो अगले संस्करण के लिए लागू किए गए हैं या अभी परीक्षण में हैं। यदि आप रोमांच महसूस कर रहे हैं, तो यह वास्तव में सहायक होगा यदि आप # 13864 को एक कोशिश दे सकते हैं और देखें कि क्या यह आपके लिए चीजों को बेहतर बनाता है; मैं जल्द ही इसका परीक्षण करूंगा।

पतंग के लिए, मैं इसका और इसके तीसरे पक्ष के मालिकाना प्लगइन का उपयोग नहीं करता हूं, लेकिन ऐसा लगता है कि आपने एक विशिष्ट मामले को अलग कर दिया है, जहां इसका धीमा होना वास्तव में इसे हल करने में सहायक है, इसलिए उम्मीद है कि उनके डेवलपर्स में से एक, या कोई हो। और इतने इच्छुक हैं, यह पता लगाने में सक्षम होंगे कि क्या चल रहा है। शुभकामनाएँ!

@ CAM-Gerlach और सभी, बस कुछ जानकारी जोड़ने के लिए, मैं https://Ppython.github.io/ से WinPython64-3.8.5.0cod का उपयोग कर रहा हूं, इसलिए शायद समस्या इस पैकेज में कुछ कॉन्फ़िगरेशन पर या शायद मेरी खिड़कियों पर निर्भर करती है मशीन।
स्पाईडर संस्करण को अपग्रेड करने के लिए मेरे लिए मुश्किल है, कम से कम जब तक विनपीथॉन अपडेट नहीं किया जाता है: मेरे पास मेरी मशीन में सॉफ़्टवेयर स्थापित करने की क्षमता नहीं है।

पतंग पूरी करने में असमर्थता और कमियां भी पूरी करना मेरे लिए काम नहीं करता है :(

@stonebig किसी भी मौका आप इस बारे में कुछ भी पता हो सकता है?

समय के लिए आप Source मेनू, Preferences > Editor और Preferences > Completion and Introspection तहत किसी भी विकल्प को अक्षम करने का प्रयास कर सकते हैं जिसकी आपको विशेष रूप से आवश्यकता नहीं है, विशेष रूप से इंडेंट गाइड जो महत्वपूर्ण अंतराल का कारण बन सकते हैं। इसके अलावा, हमारे पास स्पाइडर 4.2.0 के लिए तैयार या अंतिम परीक्षण में कई सुधार हैं, जो अगले कुछ हफ्तों में जारी किए जाएंगे, इसका उद्देश्य संपादक के प्रदर्शन में सुधार करना और मंदी के अधिकांश कारणों को हल करना है, विशेष रूप से बड़ी फ़ाइलों पर, लेकिन उन लोगों की पुष्टि करने में सक्षम होने के बिना वे आपके लिए चीजों को बेहतर बनाते हैं, मुझे वास्तव में यकीन नहीं है कि सिफारिश करने के लिए और क्या है, क्षमा करें।

हाय @ CAM-Gerlach, 95% समय विंडोज धीमी गति से मृत है, यह एंटी-वायरस गतिविधि या मेमोरी संतृप्ति से संबंधित है।

इसके अलावा, स्पाइडर वैकल्पिक प्लगइन्स स्थिति में सुधार नहीं कर सकते हैं

ठीक है शुक्रिया। उम्मीद है कि 4.2.0 हल करेगा, या कम से कम @DGuidi के लिए स्थिति में सुधार