Ipython: Empêcher les noyaux d'envoyer même trop de sortie à l'interface du notebook

Merci, nous allons l'examiner.

cf https://github.com/ipython/ipython/issues/6516 pour une extension anti while True loop , vous pouvez également exécuter une sortie claire depuis la ligne de commande nbconvert et faire ipynb -> ipynb si jamais cela se reproduit.

Ce serait formidable si IPython pouvait faire plusieurs choses pour vous aider:

• "Votre programme crée une grande quantité de sortie; continuer à fonctionner?"
• Chargement du notebook: "Ce notebook contient beaucoup de sortie; Effacer les cellules de sortie ou Charger normalement?"

@Carreau Je pense que cela devrait être dans une FAQ! Avec les pandas, il est extrêmement facile de créer accidentellement un graphique de plus de 200 colonnes avec 130000 points de données ... et si ce graphique est en ligne, il `` mélasse '' le navigateur. ;)

Hm, l'option nbconvert --to= ne mentionne pas .ipynb comme sortie potentielle et son utilisation par --to=ipynb échoue.

nbconvert --help-all extrait:

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

Je suppose que vous voulez dire notebook ? Devrions-nous alias ipynb en notebook ?

Je vois beaucoup cela avec mes étudiants (et moi). Comment casser ipython en 13 caractères:

def f():
    f()
f()

1000 listes de pile créent un bloc-notes figé dans Chrome. Mais alors on ne peut pas ouvrir un nouveau bloc-notes pour exécuter ces commandes de conversion, car le tableau de bord et le bloc-notes sont verrouillés ... 5 minutes plus tard ... libérés! J'essaie maintenant d'effacer la sortie de la cellule ... 5 minutes de plus ... même la fermeture de l'onglet du bloc-notes n'aide pas.

Quelle version? J'ai la dernière version officielle de la version 2.3.1 et elle contient ceci:

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

J'utilise ipython nbconvert , y a-t-il une application supplémentaire ??

2.x ne peut pas faire ipynb vers ipynb

Je pense que le principal problème ici est le temps nécessaire pour rendre de grandes quantités d'entrées dans le navigateur (même si cela prendrait un certain temps juste pour transférer 4,6 Mo du noyau vers le navigateur). Un autre problème ici suggère qu'une proposition de modification CSS peut aider ce problème.

Sur un point connexe, montrer les traces qui ont plus de, disons 20, appels de fonction dans la trace de pile n'est pas utile. Envisagez d'avoir un objet d'arborescence hiérarchique développer / réduire que le stacktrace pourrait utiliser. Ou peut-être que pour toute sortie volumineuse, il devrait y avoir un lien "Afficher plus ..." pour s'assurer que les blocs-notes peuvent être rendus. (Les sorties volumineuses ne semblent pas poser de problème dans le nbviewer statique. J'ai accidentellement imprimé le cahier de 500 pages rendu par nbviewer d'un étudiant avec stacktrace l'autre jour ...)

Le problème des sorties volumineuses rendant un notebook déchargeable peut se produire dans n'importe quel noyau Jupyter, il n'est donc pas limité à IPython.

J'exécute le noyau localement donc j'espère que le transfert de 4,6 Mo de données ne prendra pas si longtemps.
Mon intuition est qu'il y a un coût fixe important pour interpréter / rendre une de ces lignes stdout. c'est-à-dire quel est le temps de rendre 1 sortie standard avec K lignes vs K sorties standard avec 1 ligne chacune.

Nous avons déjà parlé de mettre en place des protections pour empêcher de grandes quantités de sortie d'atteindre même les frontaux du notebook (ou d'autres). La façon dont nous traitons actuellement les gros volumes est très problématique. Des points:

• Le noyau lui-même devrait gérer cela - il devrait même refuser d'envoyer la sortie au-delà d'un certain point.
• Le noyau devrait enregistrer une grande sortie quelque part (probablement sur le disque, mais cela peut même être un problème au-delà d'un certain point).
• Le noyau doit envoyer quelque chose qui indique qu'une sortie volumineuse a été générée et fournir à l'utilisateur un moyen de la visualiser, ou au moins lui dire quelle quantité de sortie a été générée et où elle a été placée.
• Tout cela doit être intégré avec le défilement / réduction de sortie de manière intelligente.

J'ai changé le titre de ce numéro pour refléter ce problème plus général.

Ok, mais il semble que le frontend sache mieux ce qui est "trop". Si le noyau le décide, il en sera de même pour tous les frontends. Ce qui est trop pour la console est différent de celui du notebook.

Je suis plutôt d'accord avec vous. Il est probablement logique d'avoir une approche à plusieurs niveaux
où initialement cela géré par le frontend. Mais pour des données très volumineuses,
vous savez qu'aucune interface ne peut le gérer. Mais le plus
la chose importante est qu'au-delà d'un certain point, aucun humain ne peut raisonnablement
regardez la sortie. Ce n'est pas seulement une question de performances, c'est une question d'utilisateur
expérience. Je pense que nous pouvons être assez agressifs en disant à l’utilisateur "vous
juste essayé de générer plus de résultats que ce à quoi vous pourriez ressembler "
quel que soit le problème de performances.

Le lundi 12 janvier 2015 à 10h38, Doug Blank [email protected]
a écrit:

Ok, mais il semble que le frontend sache mieux ce qui est "trop". Si la
le noyau décide, alors ce serait la même chose pour toutes les interfaces. Qu'est-ce que c'est trop
beaucoup pour la console est différent de celui du portable.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/ipython/ipython/issues/6771#issuecomment -69620565.

Brian E. Granger
Université d'État de Cal Poly, San Luis Obispo
@ellisonbg sur Twitter et GitHub
[email protected] et [email protected]

Inspiré d'un commentaire de @Carreau, j'ai réalisé ces extensions de notebook:
https://github.com/ipython-contrib/IPython-notebook-extensions/wiki/limit-output

Fonctionne bien pour moi pour empêcher le navigateur de planter dans des boucles d'impression sans fin.

D'accord avec @juhasch, la plupart des plantages du navigateur se sont produits à cause de l'élément DOM.
et la «limite» dépend fortement du type de sortie. L'affichage de la même quantité de données que PNG ou texte est complètement différent en termes de ce que le navigateur peut gérer.

@juhasch Je pense que je

BTW, qu'est-ce qui vous permet d'aller dans / nbextensions / et de cliquer sur Activer pour une extension ... Je le veux aussi!

L'extension serveur pour / nbextensions / se trouve dans cette pull request:
https://github.com/ipython-contrib/IPython-notebook-extensions/pull/164

Clôture car ce problème n'est pas dans IPython lui-même et s'il est toujours problématique et pertinent, il doit être ouvert sur le bon référentiel. Cela permettra de garder sous contrôle le nombre de problèmes ouverts sur le référentiel IPython.

N'hésitez pas à continuer à commenter ou à rouvrir si nécessaire.

Merci.