Ipython: Evite que los kernels envíen demasiados resultados a la interfaz del portátil

Gracias, lo investigaremos.

cf https://github.com/ipython/ipython/issues/6516 para una extensión anti while True loop , también puede ejecutar una salida clara desde la línea de comando nbconvert y hacer ipynb -> ipynb si alguna vez vuelve a suceder.

Sería genial si IPython pudiera hacer un par de cosas para ayudar con esto:

• "Su programa está creando una gran cantidad de resultados; ¿continuar ejecutándose?"
• Cargando el cuaderno: "Este cuaderno contiene una gran cantidad de salida; ¿Borrar celdas de salida o cargar normalmente?

@Carreau ¡Creo que esto debería estar en una

Hm, la opción nbconvert --to= no menciona .ipynb como una salida potencial y solo usarla por --to=ipynb falla.

nbconvert --help-all extracto:

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

¿Supongo que te refieres a notebook ? ¿Deberíamos alias ipynb a notebook ?

Veo esto mucho con mis estudiantes (y conmigo). Cómo dividir ipython en 13 caracteres:

def f():
    f()
f()

1000 listados de pila crean un cuaderno congelado en Chrome. Pero entonces no se puede abrir un nuevo cuaderno para ejecutar esos comandos de conversión, porque el tablero y el cuaderno están bloqueados ... 5 minutos después ... ¡liberados! Ahora trato de borrar la salida de la celda ... 5 minutos más ... incluso cerrar la pestaña del cuaderno no ayuda.

¿Qué versión? Tengo 2.3.1 última versión oficial y tiene esto:

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

Estoy usando ipython nbconvert , ¿hay alguna aplicación adicional?

2.x no puede hacer ipynb a ipynb

Creo que el problema principal aquí es el tiempo que se tarda en renderizar grandes cantidades de entrada en el navegador (aunque llevaría algo de tiempo transferir 4,6 MB del kernel al navegador). Otro problema aquí sugiere que un cambio CSS propuesto puede ayudar con este problema.

En un punto relacionado, no es útil mostrar trazas que tienen más de, digamos 20, llamadas a funciones en la traza de la pila. Considere tener un objeto de árbol jerárquico expandir / contraer que el seguimiento de pila podría usar. O tal vez para cualquier salida grande debería haber un enlace "Mostrar más ..." para asegurarse de que los cuadernos se puedan procesar. (Los resultados grandes no parecen ser un problema en el nbviewer estático. El otro día imprimí accidentalmente el cuaderno de 500 páginas de un estudiante con stacktrace ...)

El problema de las grandes salidas que hacen que un portátil sea descargable puede ocurrir en cualquier kernel de Jupyter, por lo que no se limita solo a IPython.

Estoy ejecutando el kernel localmente, así que espero que la transferencia de 4.6 MB de datos no lleve tanto tiempo.
Mi corazonada es que hay un gran costo fijo para interpretar / renderizar una de esas líneas estándar. es decir, ¿cuál es el tiempo para renderizar 1 salida estándar con K líneas frente a K salidas estándar con 1 línea cada una?

Hemos hablado antes sobre la implementación de algunas medidas de seguridad para evitar que grandes cantidades de salida lleguen incluso a las interfaces del portátil (u otras). La forma en que manejamos grandes resultados en este momento es muy problemática. Algunos puntos:

• El propio kernel debería gestionar esto, debería negarse incluso a enviar la salida más allá de cierto punto.
• El kernel debería guardar una gran cantidad de resultados en algún lugar (probablemente en el disco, pero eso puede ser un problema más allá de cierto punto).
• El kernel debe enviar algo que indique que se generó una salida grande y proporcionar al usuario alguna forma de verla, o al menos decirle al usuario cuánta salida se generó y dónde se colocó.
• Todo esto debe integrarse con el desplazamiento / colapso de salida de una manera inteligente.

He cambiado el título de este número para reflejar este problema más general.

Ok, pero parece que la interfaz sabe mejor qué es "demasiado". Si el kernel decide, será igual para todas las interfaces. Lo que es demasiado para la consola es diferente que para el portátil.

Mayormente concuerdo contigo. Probablemente tenga sentido tener un enfoque escalonado
donde inicialmente esto manejado por la interfaz. Pero para datos realmente grandes,
sabes que no hay ninguna interfaz que pueda manejarlo. Pero la mayoría
Lo importante es que más allá de cierto punto, ningún humano puede razonablemente
mira la salida. No se trata solo de rendimiento, se trata de usuario
experiencia. Creo que podemos ser bastante agresivos al decirle al usuario "usted
Intenté generar más resultados de los que podría parecer "
independientemente del problema de rendimiento.

El lunes 12 de enero de 2015 a las 10:38 a. M., Doug Blank [email protected]
escribió:

Ok, pero parece que la interfaz sabe mejor qué es "demasiado". Si el
kernel decide, entonces sería el mismo para todas las interfaces. Que es demasiado
mucho de la consola es diferente a la del portátil.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/ipython/ipython/issues/6771#issuecomment -69620565.

Brian E. Granger
Universidad Estatal de Cal Poly, San Luis Obispo
@ellisonbg en Twitter y GitHub
[email protected] y [email protected]

Inspirado por un comentario de @Carreau , hice las extensiones de este cuaderno:
https://github.com/ipython-contrib/IPython-notebook-extensions/wiki/limit-output

Me funciona bien para evitar que el navegador se bloquee en bucles de impresión sin fin.

De acuerdo con @juhasch, la mayoría de las
y el "límite" depende en gran medida del tipo de salida. Mostrar la misma cantidad de datos que PNG o texto es completamente diferente en términos de lo que podría manejar el navegador.

@juhasch Creo que es posible que tenga que habilitar su extensión de forma predeterminada para IPython 3; de lo contrario, los desbordamientos de pila hacen que el cuaderno no se pueda descargar.

Por cierto, ¿qué es lo que te permite ir a / nbextensions / y hacer clic en Activar para obtener una extensión? ¡Yo también quiero eso!

La extensión del servidor para / nbextensions / está en esta solicitud de extracción:
https://github.com/ipython-contrib/IPython-notebook-extensions/pull/164

Cerrando ya que este problema no está en IPython en sí y si aún es problemático y relevante, debe abrirse en el repositorio correcto. Esto permitirá mantener bajo control el número de problemas abiertos en el repositorio de IPython.

No dudes en seguir comentando o reabrir si es necesario.

Gracias.