Ipython: Verhindern Sie, dass Kernel auch nur zu viel Ausgabe an das Notebook-Frontend senden

Erstellt am 22. Okt. 2014  ·  19Kommentare  ·  Quelle: ipython/ipython

Aufgrund von PEBKAC haben wir ein großes Notebook (4,6 MB) mit vielen Ausdrucken erstellt, die in Safari und Firefox nicht mehr geladen werden konnten. Safari meldet sich überhaupt nicht bei mir, Firefox sagt mir nach einer Weile, dass das Skript nicht reagiert. Chrome am Ende könnte es laden, so dass ich die Funktion zum Löschen der Ausgabe verwenden könnte, um die Megabyte Text zu entfernen.
Ich brauche also keine Hilfe mehr, aber ich dachte, dass Sie vielleicht daran interessiert sind, dieses Skript in der kaputten Form zu betrachten, um zu sehen, ob etwas getan werden kann, damit sich das Notebook vor solchen Dummheiten schützt.
Ich habe das kaputte Skript hier hochgeladen: https://gist.github.com/8be664570dd2100310d6

bug notebook

Hilfreichster Kommentar

Es wäre großartig, wenn IPython ein paar Dinge tun könnte, um dabei zu helfen:

  • "Ihr Programm erstellt eine große Menge an Ausgabe. Laufen Sie weiter?"
  • Notebook laden: "Dieses Notebook enthält viel Ausgabe; Ausgabezellen löschen oder normal laden?"

Alle 19 Kommentare

Danke, wir werden uns darum kümmern.

Unter https://github.com/ipython/ipython/issues/6516 für eine anti while True loop -Erweiterung können Sie auch eine klare Ausgabe über die Befehlszeile von nbconvert ausführen und ipynb -> ipynb ausführen, falls dies jemals wieder passieren sollte.

Es wäre großartig, wenn IPython ein paar Dinge tun könnte, um dabei zu helfen:

  • "Ihr Programm erstellt eine große Menge an Ausgabe. Laufen Sie weiter?"
  • Notebook laden: "Dieses Notebook enthält viel Ausgabe; Ausgabezellen löschen oder normal laden?"

@ Carreau Ich denke, das sollte in einer FAQ sein! Mit Pandas ist es extrem einfach, versehentlich ein Diagramm über 200 Spalten mit 130.000 Datenpunkten zu erstellen ... und wenn dieses Diagramm inline ist, wird der Browser "melassiert". ;)

Hm, nbconvert Option --to= wird .ipynb als potenzielle Ausgabe erwähnt, und nur die Verwendung durch --to=ipynb schlägt fehl.

nbconvert --help-all extrahieren:

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

Ich nehme an, du meinst notebook ? Sollten wir Alias ipynb bis notebook ?

Ich sehe das oft bei meinen Schülern (und mir). So brechen Sie Ipython in 13 Zeichen:

def f():
    f()
f()

1000 Stapellisten erstellen ein eingefrorenes Notizbuch in Chrome. Aber dann kann man kein neues Notizbuch öffnen, um diese Konvertierungsbefehle auszuführen, da das Dashboard und das Notizbuch gesperrt sind ... 5 Minuten später ... freigegeben! Jetzt versuche ich, die Ausgabe aus der Zelle zu löschen ... noch 5 Minuten ... selbst das Schließen der Notizbuchregisterkarte hilft nicht.

Welche Version? Ich habe 2.3.1 letzte offizielle Veröffentlichung und es hat diese:

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

Ich benutze ipython nbconvert , gibt es eine zusätzliche Anwendung?

2.x kann ipynb nicht mit ipynb ausführen

Ich denke, das Hauptproblem hier ist die Zeit, die benötigt wird, um große Mengen an Eingaben im Browser zu rendern (obwohl es einige Zeit dauern würde, nur 4,6 MB vom Kernel zum Browser zu übertragen). Ein weiteres Problem hier deutet darauf hin, dass eine vorgeschlagene CSS-Änderung dieses Problem beheben kann.

In einem verwandten Punkt ist es nicht sinnvoll, Tracebacks anzuzeigen, die mehr als beispielsweise 20 Funktionsaufrufe in der Stapelverfolgung enthalten. Erwägen Sie ein hierarchisches Baumobjekt zum Erweitern / Reduzieren, das der Stacktrace verwenden könnte. Oder für jede große Ausgabe sollte ein Link "Mehr anzeigen ..." vorhanden sein, um sicherzustellen, dass Notebooks gerendert werden können. (Große Ausgaben scheinen im statischen nbviewer kein Problem zu sein. Ich habe neulich versehentlich das 500-seitige nbviewer-gerenderte Notizbuch eines Schülers mit Stacktrace gedruckt ...)

Das Problem, dass große Ausgaben ein Notebook entladen, kann in jedem Jupyter-Kernel auftreten und ist daher nicht nur auf IPython beschränkt.

Ich führe den Kernel lokal aus, daher sollte ich hoffen, dass die Übertragung von 4,6 MB Daten nicht so lange dauert.
Meine Vermutung ist, dass das Interpretieren / Rendern einer dieser Standardzeilen einige hohe Fixkosten verursacht. dh was ist die Zeit, um 1 Standardausgang mit K Linien gegen K Standardausgänge mit jeweils 1 Linie zu rendern.

Wir haben bereits darüber gesprochen, einige Sicherheitsvorkehrungen zu treffen, um zu verhindern, dass große Mengen an Ausgabe sogar das Notebook (oder andere) Frontends erreichen. Die Art und Weise, wie wir derzeit mit großen Ausgaben umgehen, ist sehr problematisch. Ein paar Punkte:

  • Der Kernel selbst sollte dies verwalten - er sollte sich weigern, Ausgaben über einen bestimmten Punkt hinaus zu senden.
  • Der Kernel sollte irgendwo eine große Ausgabe speichern (wahrscheinlich auf der Festplatte, aber das kann sogar über einen bestimmten Punkt hinaus ein Problem sein).
  • Der Kernel sollte etwas senden, das angibt, dass eine große Ausgabe generiert wurde, und dem Benutzer eine Möglichkeit bieten, diese anzuzeigen, oder dem Benutzer zumindest mitteilen, wie viel Ausgabe generiert wurde und wo sie abgelegt wurde.
  • All dies sollte auf intelligente Weise in die Ausgabe integriert werden.

Ich habe den Titel dieser Ausgabe geändert, um diese allgemeinere Ausgabe widerzuspiegeln.

Ok, aber anscheinend weiß das Frontend besser, was "zu viel" ist. Wenn der Kernel entscheidet, ist dies für alle Frontends gleich. Was für die Konsole zu viel ist, unterscheidet sich von dem für das Notebook.

Ich stimme dir größtenteils zu. Es ist wahrscheinlich sinnvoll, einen abgestuften Ansatz zu verfolgen
wo dies zunächst vom Frontend erledigt wurde. Aber für wirklich große Datenmengen
Sie wissen, dass es kein Frontend gibt, das damit umgehen kann. Aber am meisten
Wichtig ist, dass über einen bestimmten Punkt hinaus kein Mensch vernünftigerweise kann
Schauen Sie sich die Ausgabe an. Es geht nicht nur um Leistung, es geht um Benutzer
Erfahrung. Ich denke, wir können ziemlich aggressiv sein, wenn wir dem Benutzer "Sie" sagen
Ich habe gerade versucht, mehr Output zu generieren, als Sie möglicherweise sehen könnten. "
unabhängig vom Leistungsproblem.

Am Montag, den 12. Januar 2015 um 10:38 Uhr, Doug Blank [email protected]
schrieb:

Ok, aber anscheinend weiß das Frontend besser, was "zu viel" ist. Wenn die
Kernel entscheidet, dann wäre es für alle Frontends gleich. Was ist auch
Vieles für die Konsole unterscheidet sich von dem für das Notebook.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/ipython/ipython/issues/6771#issuecomment -69620565.

Brian E. Granger
Cal Poly State Universität, San Luis Obispo
@ellisonbg auf Twitter und GitHub
[email protected] und [email protected]

Inspiriert von einem Kommentar von @Carreau habe ich diese Notebook-Erweiterungen vorgenommen:
https://github.com/ipython-contrib/IPython-notebook-extensions/wiki/limit-output

Funktioniert gut für mich, um zu verhindern, dass der Browser in endlosen Druckschleifen abstürzt.

Einverstanden mit @juhasch Die meisten Browser stürzten aufgrund des DOM-Elements ab.
und die 'Grenze' hängt stark von der Art der Ausgabe ab. Die Anzeige der gleichen Datenmenge wie bei PNG oder Text unterscheidet sich grundlegend in Bezug auf die Art und Weise, wie der Browser damit umgehen kann.

@juhasch Ich denke, ich muss möglicherweise Ihre Erweiterung standardmäßig für IPython 3 aktivieren, da sonst Stapelüberläufe das Notebook entladen können.

Übrigens, was ermöglicht es Ihnen, zu / nbextensions / zu gehen und auf Aktivieren für eine Erweiterung zu klicken ... das möchte ich auch!

Die Servererweiterung für / nbextensions / befindet sich in dieser Pull-Anforderung:
https://github.com/ipython-contrib/IPython-notebook-extensions/pull/164

Das Schließen dieses Problems befindet sich nicht in IPython selbst und sollte, falls es immer noch problematisch und relevant ist, im richtigen Repository geöffnet werden. Auf diese Weise können Sie die Anzahl der geöffneten Probleme auf dem IPython-Repo unter Kontrolle halten.

Fühlen Sie sich frei, weiter zu kommentieren oder bei Bedarf erneut zu öffnen.

Vielen Dank.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen