Ipython: Предотвращение отправки ядрами слишком большого объема вывода во внешний интерфейс ноутбука

Созданный на 22 окт. 2014  ·  19Комментарии  ·  Источник: ipython/ipython

Из-за случая с PEBKAC мы создали большую записную книжку (4,6 МБ) с множеством распечаток, которые больше не загружались в Safari и Firefox. Safari вообще не отвечает мне, Firefox через некоторое время сообщает мне, что скрипт не отвечает. Chrome в конце мог загрузить его, чтобы я мог использовать функцию четкого вывода, чтобы избавиться от мегабайт текста.
Так что мне больше не нужна помощь, но я подумал, что вам, возможно, интересно взглянуть на этот скрипт в неработающей форме, чтобы узнать, есть ли что-нибудь, что можно сделать, чтобы защитить ноутбук от такого дурачества.
Я загрузил сломанный скрипт сюда: https://gist.github.com/8be664570dd2100310d6

bug notebook

Самый полезный комментарий

Было бы здорово, если бы IPython мог сделать пару вещей, чтобы помочь в этом:

  • «Ваша программа создает большой объем вывода; продолжить работу?»
  • Загрузка записной книжки: «Эта записная книжка содержит много выходных данных; Очистить выходные ячейки или Загрузить нормально?»

Все 19 Комментарий

Спасибо, мы разберемся.

cf https://github.com/ipython/ipython/issues/6516 для расширения anti while True loop , также вы можете запустить чистый вывод из командной строки nbconvert и выполнить ipynb -> ipynb, если это когда-нибудь снова произойдет.

Было бы здорово, если бы IPython мог сделать пару вещей, чтобы помочь в этом:

  • «Ваша программа создает большой объем вывода; продолжить работу?»
  • Загрузка записной книжки: «Эта записная книжка содержит много выходных данных; Очистить выходные ячейки или Загрузить нормально?»

@Carreau Я думаю, это должно быть в FAQ! С помощью pandas очень легко случайно создать график из 200 столбцов с 130 000 точек данных ... и если этот график встроен, он «патока» браузер. ;)

Хм, опция nbconvert --to= не упоминает .ipynb как потенциальный выход, и просто использовать его --to=ipynb не удается.

nbconvert --help-all экстракт:

--to=<CaselessStrEnum> (NbConvertApp.export_format)
    Default: 'html'
    Choices: ['custom', 'html', 'latex', 'markdown', 'notebook', 'pdf', 'python', 'rst', 'slides']

Я полагаю, вы имеете в виду notebook ? Должны ли мы использовать псевдоним ipynb на notebook ?

Я часто вижу это со своими учениками (и со мной). Как разбить ipython на 13 символов:

def f():
    f()
f()

1000 стеков списков создают замороженный блокнот в Chrome. Но тогда нельзя открыть новую записную книжку для выполнения этих команд преобразования, потому что приборная панель и записная книжка заблокированы ... 5 минут спустя ... выпущены! Теперь пытаюсь очистить вывод из ячейки ... еще 5 минут ... даже закрытие вкладки блокнота не помогает.

Какая версия? У меня последняя официальная версия 2.3.1, и в ней есть следующее:

--to=<CaselessStrEnum> (NbConvertApp.export_format)
    Default: 'html'
    Choices: ['custom', 'html', 'latex', 'markdown', 'python', 'rst', 'slides']
    The export format to be used.

Я использую ipython nbconvert , есть ли дополнительное приложение ??

2.x не может выполнить ipynb для ipynb

Я думаю, что основная проблема здесь - это время, затрачиваемое на рендеринг большого количества вводимых данных в браузере (хотя для передачи 4,6 МБ из ядра в браузер потребуется некоторое время). Другая проблема здесь предполагает, что предлагаемое изменение CSS может решить эту проблему.

В связи с этим, показ обратных трассировок, которые имеют более чем 20 вызовов функций в трассировке стека, бесполезен. Подумайте о наличии объекта иерархического дерева развертывания / свертывания, который может использовать трассировка стека. Или, может быть, для любого большого вывода должна быть ссылка «Показать еще ...», чтобы убедиться, что записные книжки могут отображаться. (Большие выходные данные не кажутся проблемой в статическом nbviewer. На днях я случайно распечатал 500-страничную записную книжку студента, отрисованную nbviewer, со stacktrace ...)

Проблема больших выходных данных, делающих ноутбук незагружаемым, может возникнуть в любом ядре Jupyter, поэтому не ограничивается только IPython.

Я запускаю ядро ​​локально, поэтому надеюсь, что передача данных размером 4,6 МБ не займет так много времени.
Мне кажется, что интерпретация / рендеринг одной из этих строк stdout требует больших фиксированных затрат. т.е. сколько времени нужно для рендеринга 1 стандартного выхода с K строками против K стандартных выходов с 1 строкой в ​​каждом.

Ранее мы уже говорили о некоторых мерах безопасности, чтобы большие объемы вывода не доходили даже до внешних интерфейсов ноутбука (или других). То, как мы обрабатываем большие объемы продукции прямо сейчас, очень проблематично. Некоторые моменты:

  • Само ядро ​​должно управлять этим - оно должно отказываться даже посылать вывод за пределами определенной точки.
  • Ядро должно где-то сохранять большие выходные данные (возможно, на диск, но это может быть проблемой даже после определенного момента).
  • Ядро должно отправить что-то, что указывает на то, что был сгенерирован большой вывод, и предоставить пользователю способ его просмотра или, по крайней мере, сообщить пользователю, сколько вывода было сгенерировано и куда оно было помещено.
  • Все это должно быть разумно интегрировано с прокруткой / сворачиванием вывода.

Я изменил название этого выпуска, чтобы отразить эту более общую проблему.

Хорошо, но похоже, что интерфейс лучше знает, что такое "слишком много". Если ядро ​​решит, то оно будет одинаковым для всех интерфейсов. То, что для консоли слишком много, отличается от ноутбука.

Я в основном с тобой согласен. Вероятно, имеет смысл использовать многоуровневый подход
где изначально этим занимался интерфейс. Но для действительно больших данных
вы знаете, что ни один интерфейс не может с этим справиться. Но самый
важно то, что после определенного момента ни один человек не может разумно
посмотрите на вывод. Дело не только в производительности, это в пользователях
опыт. Я думаю, что мы можем довольно агрессивно сказать пользователю «вы
просто пытался произвести больше результатов, чем вы могли бы выглядеть "
независимо от проблемы с производительностью.

В пн, 12 января 2015 г., в 10:38, Дуг Бланк [email protected]
написал:

Хорошо, но похоже, что интерфейс лучше знает, что такое "слишком много". Если
ядро решает, тогда это будет одинаково для всех интерфейсов. Что тоже
для консоли многое другое, чем для ноутбука.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/ipython/ipython/issues/6771#issuecomment -69620565.

Брайан Э. Грейнджер
Университет штата Калифорния-Поли, Сан-Луис-Обиспо
@ellisonbg в Твиттере и GitHub
[email protected] и [email protected]

Вдохновленный комментарием @Carreau, я сделал эти расширения для записной книжки:
https://github.com/ipython-contrib/IPython-notebook-extensions/wiki/limit-output

У меня хорошо работает, чтобы предотвратить сбои браузера в бесконечных циклах печати.

Согласен с @juhasch, большая часть сбоев браузера происходит из-за элемента DOM.
и «предел» сильно зависят от типа вывода. Отображение того же объема данных, что и PNG или текст, полностью отличается от того, что может обрабатывать браузер.

@juhasch Я думаю, мне, возможно, придется включить ваше расширение по умолчанию для IPython 3, иначе переполнение стека сделает ноутбук разгрузочным.

Кстати, что позволяет вам перейти в / nbextensions / и нажать «Активировать» для расширения ... Я тоже этого хочу!

Расширение сервера для / nbextensions / находится в этом запросе на перенос:
https://github.com/ipython-contrib/IPython-notebook-extensions/pull/164

Закрытие, поскольку эта проблема не связана с самим IPython, и, если она все еще проблематична и актуальна, ее следует открыть в правильном репозитории. Это позволит держать под контролем количество открытых выпусков в репозитории IPython.

Не стесняйтесь оставлять комментарии или открывать снова, если необходимо.

Благодарю.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги