Ipython: شخصية غريبة بعد الاستيراد الأول

همهمة لقد رأيت هذا ولكن مع ^[[43;1R ، لكنني افترضت أن ذلك يرجع إلى أنني أتقن برنامج المحاكاة الطرفية. لست متأكدا من أين يأتي هذا

لقد رأيت أشياء مماثلة في أحدث https://github.com/jonathanslenders/pymux (لم يتم إصداره ، يستخدم مجموعة أدوات سريعة 2). ربما لدى jonathanslenders بعض الأفكار؟

أحصل على نفس الشيء:

$ ipython
Python 3.6.5 (default, Mar 30 2018, 06:41:53) 
Type 'copyright', 'credits' or 'license' for more information
IPython 7.0.1 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import os                                                                                             

^[[19;1RIn [2]:

إذا حاولت بعد ذلك إكمال علامة التبويب:

In [2]: os.p                                                                                                  
os.pardir         os.pathconf       os.pathsep        os.popen          os.putenv         
os.path           os.pathconf_names os.pipe           os.pread          os.pwrite         
^[[19;1RIn [2]: os.p

هذا يجعل إكمال علامة التبويب غير قابل للاستخدام تقريبًا.

هل من الممكن أن يكون قد تم إصلاح ذلك من خلال الالتزام التالي: https://github.com/jonathanslenders/python-prompt-toolkit/commit/e226d640177aa1d2cf293e4de382f171586173a2 ؟
لقد تم دمجه في برنامج quick_toolkit master ، لكنني على وشك إصدار الإصدار 2.0 الفوري الجديد الذي يتضمنه.

لقد قمت بتثبيت prompt-toolkit من السيد وما زالت المشكلة قائمة ، لكنني لست متأكدًا مما إذا كان هناك شيء آخر يجب القيام به على جانب ipython.

لا ، أنا متأكد من أن هذا ليس IPython. سأحاول التكاثر باستخدام iterm2

أنا متأكد من أنني لا أفهم التعقيدات هنا ، ولكن فقط للمعلومات ، هذا يحدث مع IPython 7.0 و 7.1 ، ولا يحدث مع 6.0 أو 6.5 ، الاختبار في نفس Virtualenv.

هل يمكنكم جميعًا نشر أي محطة طرفية رأيتها فيها؟
أنا قادر على إعادة الإنتاج على iTerm2 - 3.2.1beta6 - osx ؛ alacritty v0.2.0-35-ga53cabf OSX ، ولكن ليس على نظام التشغيل MacOS Terminal.app العاري (سييرا 10.12.6)

هل يمكن أن يكون هناك عدم تطابق بين الميزات المعلن عنها للمحطة وما يمكنهم فعله بالفعل؟

كما أنه غير قابل للتكرار (بالنسبة لي) ipython --colors=nocolor

فقط عارية Terminal.app على هاي سييرا 10.13.6. nocolor لا يصلح لي.

كما أنه غير قابل للتكرار (بالنسبة لي) ipython --colors=nocolor

خدش ، يبدو أنه عشوائي ، لكن في الواقع ، لم يصلحه nocolor.

هل يمكنكم محاولة إزالة مدير السياق هذا patch_stdout ؟

إذا قمت بإزالته ، فإنه _ يبدو أنه جيد بالنسبة لي ، وإذا قمت بإزالته بشكل إضافي ستحصل على المشكلة مرتين ..

يبدو أن إزالة مدير السياق يصلح لي.

يحدث هذا لي إما في macOS Terminal.app وفي iTerm2. ومع ذلك ، ظهرت الشخصية بشكل ثابت تمامًا في iTerm2 3.2.1beta. هذا الصباح ، قمت بالترقية إلى 3.2.2beta1 والآن يبدو أن الشخصية تظهر وتختفي على الفور ، وتم استبدالها بموجه iPython العادي. لكن في حالة واحدة على الأقل كانت الشخصية ثابتة ، لست متأكدًا من الفرق.

نعم ، أصلحه لي أيضًا. كان التأثير دائمًا ثابتًا بالنسبة لي.

jonathanslenders هل يمكن أن يكون التصحيح stdout به حالة سباق وأن stdout / err استعادته ، والبدء في الكتابة إليه ، قبل حدوث التدفق؟

يبدو أن المعلمة raw الخاصة بـ patch_stdout لا تذهب إلى أي مكان أيضًا في كود ptk.

لذلك هناك سبب لوجود هذا ، أو بخلاف ذلك ، فإن الطباعة في خيوط الخلفية ستؤدي إلى إفساد العرض ، لكن يبدو (بالنسبة لي) ، هذا هو شرط السباق بين التخلص من stderr / out واستعادة قيمته الأولية.

لست متأكدًا مما إذا كنت قد قمت بترجمة الخطأ أو ما زلت تجري التجربة ولكن لمعلوماتك:

• macOS 10.13.6
• iTerm 3.2.1 - يعرض دائمًا ^[[41;1R بعد الإدخال الأول (استيراد ، تعبير ، حتى سطر فارغ)
• Terminal.app 2.8.2 (404) - يعمل بشكل جيد!

Python 3.7.0 (default, Sep 18 2018, 18:47:22)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.0.1 -- An enhanced Interactive Python. Type '?' for help.

In [1]:

^[[41;1RIn [1]:

أحصل أيضًا على هذا (macOS 10.11.6 ، iTerm 3.2.0beta5) كثيرًا ، ولكن ليس بنسبة 100٪ من الوقت ، وبتسلسل 43;1R .

Python 3.7.0 (default, Jun 29 2018, 20:13:53)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.0.1 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import sqlalchemy

^[[43;1RIn [2]:

نعم ، هذا يقتلني حقًا. كنت سأخفّض ، لكن هذا يكسر دفاتر Jupyter. بالنسبة لي ، فإن إكمال علامة التبويب معطوب تمامًا إلى حد ما ، لأن هذه الأحرف تظهر كثيرًا.

للأسف ، لا يعد readline خيارًا في الوقت الحالي: https://github.com/ipython/rlipython/issues/21

لا يوجد تغيير في تشغيل النسخة الرئيسية الحالية prompt_toolkit (الإصدار 2.0.5).

يمكنني إعادة إنتاجه.

iTerm2 build 3.2.3 (أعتقد أن الأحدث) ، IPython 7.0.1 ، Python 3.6.1.

لقد واجهت الخلل في Python 3.6.3 على Ubuntu ، واختفى مع Python 3.7 ، على الرغم من أنني أستطيع رؤية بعض الأخطاء (مثل طباعة الأحرف ثم إزالتها بسرعة).

لدي إصلاح هنا: https://github.com/jonathanslenders/python-prompt-toolkit/commit/09de545476be985b95ae2690ef8393efdd65b7e5

في الواقع ما تراه في هذا الالتزام هما إصلاحان فرديان من شأنهما حل المشكلة (لما يمكنني إعادة إنتاجه).

• لسبب ما ، يتم التقاط سلسلة فارغة وكتابتها على stdout ، مباشرة قبل قبول الإدخال الأول. أدى هذا إلى تشغيل رمز patch_stdout. في الواقع ، لم تكن هناك حاجة للخوض في جهود محو المطالبة ، ورسمها مرة أخرى ، فقط لطباعة سلسلة فارغة. (لا يزال يتعين علي التحقق من سبب حدوث ذلك بالفعل).

• الإصلاح الحقيقي هو انتظار استجابات CPR قبل تقديم المحتوى الملتقط. يعمل الإنعاش القلبي الرئوي بشكل غير متزامن. نطلب موضع المؤشر من خلال كتابة شيء ما إلى stdout ، ونتلقى الرد من المحطة على stdin. هناك دائما تأخير بسيط. لكن من المهم إبقاء الجهاز في وضع RAW وقراءة هذا الإدخال حتى وصول هذه الاستجابة. لم نفعل ذلك ، وأدى ذلك إلى استجابة الجهاز مع وضع المؤشر.

كان يجب أن يكون التوقيت مختلفًا قليلاً بين المحطات ، لكن أعتقد أن هذا يجب أن يفعل ذلك.

هل يمكن أن تحاول جميعًا باستخدام أحدث برنامج من مجموعة أدوات التنفيذ الفوري؟ إذا نجحت ، سأدفع إصدارًا جديدًا.

هذا يصلح الخلل من جانبي. jonathanslenders شكرا!

نعم ، شكرًا جزيلاً ، أحدث معلم يصلح لي أيضًا.

يعمل هذا التصحيح على إصلاح بعض الأحرف [[39;1R كنت أواجهها أيضًا. شكرا!

تحرير: اخدش ذلك. كنت أختبر الإصدار الخاطئ. نعم ، يبدو أن هذا يصلح لي أيضًا.

لا ، هذا لا يبدو أنه يصلح لي. بدلا من ذلك لدي شخصية مختلفة

AlbireoProˇalbireo: Downloads » ipython                 (3.7.0 2.7.15)

In [1]: from can.interfaces.slcan import slcanBus

^[[21;1RIn [2]:

هل يمكن أن تحاول جميعًا باستخدام أحدث برنامج من مجموعة أدوات التنفيذ الفوري؟ إذا نجحت ، سأدفع إصدارًا جديدًا.

يعمل لدي. يمكنك أيضًا تغيير معالجة الألوان AFAICT ، كنا نعتمد عن غير قصد على تعيين ansi لرمز ansi في بعض الأماكن في IPython ، وسأصلح ذلك أيضًا. شكرا !

Carreau : لقد دفعت للتو إلى الإصدار 2.0.6.
هل يتوقع IPython تعيين تسلسلات RRGGBB معينة لألوان ANSI معينة ، حتى في وضع 256 لون؟

بالمناسبة Carreau ، ميزة واحدة من ميزات مجموعة أدوات الدليل الآن هي القدرة على زيادة / تقليل سطوع الألوان. هذا يجعل من السهل التكيف مع أطراف التوصيل ذات الخلفية الفاتحة أو الداكنة. لقد أضفت هذا إلى قائمة ptpython للاختبار (بشكل تفاعلي) وهو يعمل بشكل جيد.

توقع

لن أقول "أتوقع" ولكن يبدو أن السمات تحتوي على مزيج من #ansixxx و #00ff00 يبدو جيدًا معًا ، ومع 2.0.6 أقوى قليلاً في الاختلافات بينهما.

أعتقد أننا نحتاج فقط إلى مزيد من الاتساق فيما يتعلق بما إذا كنا نستخدم #ansi أو #hex .

سألقي نظرة على خيارات السطوع في مرحلة ما. لقد بدأت للتو منصبًا جديدًا منذ بضعة أسابيع ولدي وقت أقل قليلاً في تطوير IPython / Jupyter نفسه.

مثير للاهتمام ، لكنه منطقي. عندما يتم تعريف اللون على أنه # 00ff00 ، فإنني أنظر إلى أقرب لون من لوحة ألوان 256 ، لكنني أستبعد 16 لونًا من ألوان ansi. مما يعني أنه يأخذ الأقرب من 240 لونًا المتبقية.

والسبب هو أن الأشخاص في هذه الأيام غالبًا ما يكون لديهم أنظمة ألوان مخصصة محددة لألوان ANSI - ولكن ليس للألوان الـ 240 المتبقية. لذلك ، في حين أنه قد يكون قليلاً في وضعك ، إلا أنه في الواقع قد يكون أقرب بكثير إلى اللون الحقيقي للآخرين.

فيما يلي مثال على كيفية عرض ألوان ANSI الأساسية في محطات طرفية مختلفة:
https://en.wikipedia.org/wiki/ANSI_escape_code#Colors

إغلاق كمنبع ثابت