Ipython: faltan funciones mágicas relacionadas con backgroundjobs

Hola, me temo que fue víctima de la gran refactorización que tuvo lugar hacia 0.11. No recuerdo en este momento las razones precisas que llevaron a que se eliminara este, podría haber sido accidental, pero @bgranger podría tener un mejor recuerdo ya que hizo el trabajo duro de esa gran reorganización.

Parte del problema es que esta funcionalidad estaba basada en subprocesos, y en Python, iniciar subprocesos en segundo plano para cualquier cosa que requiera un uso intensivo de la CPU no es una muy buena idea. Pero puedo ver cómo podría ser útil para ciertos escenarios, y si podemos traerlo de vuelta sin crear problemas para la nueva consola o portátil Qt, podemos investigarlo.

¿Podría darnos algunos comentarios sobre sus escenarios de uso y lo importante que es esto para usted? Comentarios como este nos ayudarán a evaluar cuán crítico debería ser esto en términos de priorizar el esfuerzo.

Tenga en cuenta que todo el código está allí, solo en la etiqueta 0.10.2 en el repositorio de git. Por lo tanto, no sería demasiado difícil revivirlo, si alguien se acerca para ayudar y lo hacemos con la documentación y las pruebas adecuadas.

Muchas gracias por la respuesta.
Solo estaba probando las cosas mencionadas en el documento en línea, no
escenario de uso particular. Aunque estaré feliz de hacer la prueba si algunos de
no lo consideras perjudicial y lo traes de vuelta.

El lunes 10 de octubre de 2011 a las 5:04 AM, Fernando Perez <
[email protected]> escribió:

Hola, me temo que fue víctima de la gran refactorización que tuvo lugar
hacia 0,11. No recuerdo ahora mismo las razones precisas que llevaron a esto
uno se ha cortado, podría haber sido accidental, pero @bgranger podría tener un
mejor recuerdo como hizo el trabajo pesado de esa gran reorganización.

Parte del problema es que esta funcionalidad estaba basada en subprocesos y
en Python, iniciar subprocesos en segundo plano para cualquier cosa con uso intensivo de CPU no es un
muy buena idea. Pero puedo ver cómo podría ser útil para ciertos escenarios,
y si podemos traerlo de vuelta sin crear problemas para la nueva consola Qt
o cuaderno, podemos mirarlo.

¿Podría darnos algunos comentarios sobre sus escenarios de uso y lo importante
¿Esto es para ti? Comentarios como este nos ayudarán a evaluar cuán crítico es esto
debe ser en términos de priorizar el esfuerzo.

Tenga en cuenta que el código está todo allí, solo en la etiqueta 0.10.2 en el git
repositorio. Así que no sería muy difícil revivirlo, si alguien se acerca a
ayuda y lo hacemos con la documentación y las pruebas adecuadas.

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

El domingo, 9 de octubre de 2011 a las 6:28 p.m., digitalsatori
[email protected]
escribió:

Muchas gracias por la respuesta.
Solo estaba probando las cosas mencionadas en el documento en línea, no
escenario de uso particular. Aunque estaré feliz de hacer la prueba si algunos de
no lo consideras perjudicial y lo traes de vuelta.

Bueno, hay una cantidad razonable de trabajo involucrada en traerlo
y me temo que no tengo los recursos para trabajar en este derecho
ahora. Por lo que requeriría un usuario interesado que lo necesite, para invertir
algo de tiempo en el esfuerzo. El código principal está en lib/bacgkroundjobs.py ,
y podemos recuperar la magia de las etiquetas 0.10.x. Sería un
cuestión de reelaborar ese código, validarlo en los distintos usuarios
entornos (terminal, consola qt, portátil) y agregar las pruebas adecuadas
lo.

Interesante y posiblemente útil, pero en este momento algo
de baja prioridad, me temo.

Sin embargo, dejaré esto abierto para que otros puedan encontrarlo, y si un
el usuario interesado (incluido usted mismo) quiere participar, estaremos
feliz de revisar cualquier solicitud de extracción relevante.

Consulte gh-856 para obtener más detalles. Cuando eso se fusione, _algunas_ de esta funcionalidad volverán.

cerrado por PR # 856

@minrk , %bg vuelta. Así que queda un poquito de trabajo para algún alma interesada, pero ahora con el gerente de trabajos de bacgkround presente, actualizar la magia debería ser fácil. Dejé este abierto para recordarme ese hecho.

Oh, lo siento. Hubo una serie de problemas que deberían haber sido autoenclavados por los RP que no lo fueron, y supongo que me volví demasiado entusiasta.

El martes 18 de octubre de 2011 a las 4:33 p.m., Min RK
[email protected]
escribió:

Oh, lo siento. Hubo una serie de problemas que deberían haber sido autoenclavados por los RP que no lo fueron, y supongo que me volví demasiado entusiasta.

¡No te preocupes! Me alegro de verte cerrar, definitivamente tengo un similar
urgencia de acercar nuestro recuento de relaciones públicas abiertas a 0 y nuestro recuento de problemas abiertos
bajo control. Idealmente tendríamos por 0.12 solo uno o dos persistentes
relaciones públicas abiertas, y me gustaría que nuestro número de problemas sea inferior a 100, con la mayoría de
aquellos que son de baja prioridad o mejora. En este momento tenemos ~ 40 con
type-bug y prio- {mediano / alto / crítico}.

Y un número desconocido no clasificado (sin etiquetas).

Salud,

F

El martes 18 de octubre de 2011 a las 16:38, Fernando Perez <
[email protected]> escribió:

El martes 18 de octubre de 2011 a las 4:33 p.m., Min RK
[email protected]
escribió:

Oh, lo siento. Hubo una serie de problemas que deberían haberse cerrado automáticamente
por relaciones públicas que no lo eran, y supongo que me volví demasiado entusiasta.

¡No te preocupes! Me alegro de verte cerrar, definitivamente tengo un similar
urgencia de acercar nuestro recuento de relaciones públicas abiertas a 0 y nuestro recuento de problemas abiertos
bajo control. Idealmente tendríamos por 0.12 solo uno o dos persistentes
relaciones públicas abiertas, y me gustaría que nuestro número de problemas sea inferior a 100, con la mayoría de
aquellos que son de baja prioridad o mejora. En este momento tenemos ~ 40 con
type-bug y prio- {mediano / alto / crítico}.

Y un número desconocido no clasificado (sin etiquetas).

He utilizado mi secuencia de comandos de problemas para controlar los problemas no etiquetados. Tenemos
solo un par que no son de:

A) asignado a un hito
B) marcado inactivo
C) etiquetado como estado activo, con prioridad y tipo

Etiqueté de manera bastante agresiva la mayoría de las cosas como un hito 0,12, por lo que al menos
mírelos antes de decidir volver a colocarlos en 0,13.

Salud,

F

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

El martes 18 de octubre de 2011 a las 4:55 p.m., Min RK
[email protected]
escribió:

He utilizado mi secuencia de comandos de problemas para controlar los problemas no etiquetados. Tenemos
solo un par que no son de:

A) asignado a un hito
B) marcado inactivo
C) etiquetado como estado activo, con prioridad y tipo

Etiqueté de manera bastante agresiva la mayoría de las cosas como un hito 0,12, por lo que al menos
mírelos antes de decidir volver a colocarlos en 0,13.

¡Excelente! Por cierto, ¿te importaría poner tu script en herramientas /? De esa manera podemos
todos lo usan y lo perfeccionan con el tiempo. Tengo github-stats ahí, así que
podría valer la pena fusionar parte del código que probablemente sea
duplicar entre los dos ...

No hay necesidad de un PR para eso, solo hazlo cuando quieras.

Esto se ha resuelto con la nueva magia script , que proporciona una bandera --bg .

Ejemplo:

%%script bash --bg --out script_out

sleep 10
echo hi!

Gracias ! ¡Cerrando entonces!

Sería genial tener% bg de regreso ... no solo la ejecución de un script externo en segundo plano.
Usamos ipython para Spark y algunos comandos (como la recopilación de estadísticas), pueden tener que ejecutarse durante una hora,
pero la mayoría de las siguientes celdas no dependen necesariamente de su resultado. Entonces sería bueno correr
cualquier celda en segundo plano, no solo secuencias de comandos externas. Gracias.

Tengo simulaciones de Montecarlo que se ejecutan durante unas dos horas, pero pueden converger antes. Se pueden obtener conclusiones útiles y una detección de convergencia más temprana cuando se ejecutan en segundo plano y se vuelcan los resultados intermedios en un archivo. Un trabajo perfecto para% bg, así que vuelva a abrir

Tengo simulaciones de Montecarlo que se ejecutan durante unas dos horas, pero pueden converger antes. Se pueden obtener conclusiones útiles y una detección de convergencia más temprana cuando se ejecutan en segundo plano y se vuelcan los resultados intermedios en un archivo. Un trabajo perfecto para% bg, así que vuelva a abrir

Magics no tiene que ser parte de IPython para estar disponible, eres libre de publicar un paquete en PyPI que exponga una magia %bg . Aunque desde su caso de uso, parece ipyparallel y usar Python Futures podría ser más apropiado.