Ipython: Impedir que os kernels enviem até mesmo muita saída para a interface do notebook

Criado em 22 out. 2014  ·  19Comentários  ·  Fonte: ipython/ipython

Devido ao caso do PEBKAC criamos um grande notebook (4,6 MB) com muitas impressões que não carregava mais no Safari e Firefox. O Safari não responde, o Firefox depois de um tempo me diz que o script não responde. No final, o Chrome poderia carregá-lo, para que eu pudesse usar a função de saída clara para me livrar dos megabytes de texto.
Então, eu realmente não preciso mais de ajuda, mas estava pensando que talvez você esteja interessado em dar uma olhada neste script na forma quebrada para ver se há algo que pode ser feito para que o notebook se proteja de tal tolice.
Fiz upload do script quebrado aqui: https://gist.github.com/8be664570dd2100310d6

bug notebook

Comentários muito úteis

Seria ótimo se o IPython pudesse fazer algumas coisas para ajudar com isso:

  • "Seu programa está criando uma grande quantidade de saída; continuar executando?"
  • Carregando notebook: "Este notebook contém muita saída; Limpar células de saída ou Carregar normalmente?"

Todos 19 comentários

Obrigado, vamos analisar isso.

cf https://github.com/ipython/ipython/issues/6516 para uma extensão anti while True loop , você também pode executar a saída clara da linha de comando nbconvert e fazer ipynb -> ipynb se acontecer novamente.

Seria ótimo se o IPython pudesse fazer algumas coisas para ajudar com isso:

  • "Seu programa está criando uma grande quantidade de saída; continuar executando?"
  • Carregando notebook: "Este notebook contém muita saída; Limpar células de saída ou Carregar normalmente?"

@Carreau Acho que deveria estar em um FAQ! Com o pandas, é extremamente fácil criar acidentalmente um gráfico com mais de 200 colunas com 130.000 pontos de dados ... e se esse gráfico estiver embutido, ele 'mela' o navegador. ;)

Hm, nbconvert --to= option não menciona .ipynb como um produto potencial e apenas usá-lo por --to=ipynb falha.

nbconvert --help-all extrato:

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

Suponho que você queira dizer notebook ? Devemos alias ipynb a notebook ?

Eu vejo muito isso com meus alunos (e comigo). Como quebrar o ipython em 13 caracteres:

def f():
    f()
f()

As listagens de 1000 pilhas criam um notebook congelado no Chrome. Mas então não se pode abrir um novo notebook para executar esses comandos de conversão, porque o painel e o notebook estão travados ... 5 minutos depois ... liberados! Agora tento limpar a saída da célula ... mais 5 minutos ... até fechar a guia do notebook não ajuda.

Qual versão? Eu tenho o último lançamento oficial 2.3.1 e tem o seguinte:

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

Estou usando ipython nbconvert . Existe um aplicativo extra ??

2.x não pode fazer ipynb para ipynb

Acho que o principal problema aqui é o tempo gasto para processar grandes quantidades de entrada no navegador (embora leve algum tempo apenas para transferir 4,6 MB do kernel para o navegador). Outro problema aqui sugere que uma alteração proposta de CSS pode ajudar neste problema.

Em um ponto relacionado, mostrar rastreamentos com mais de, digamos, 20 chamadas de função no rastreamento de pilha não é útil. Considere ter um objeto de árvore hierárquica expandir / recolher que o stacktrace possa usar. Ou talvez, para qualquer saída grande, deva haver um link "Mostrar mais ..." para garantir que os notebooks possam renderizar. (Saídas grandes não parecem ser um problema no nbviewer estático. Eu acidentalmente imprimi um bloco de notas renderizado por nbviewer de 500 páginas com stacktrace outro dia ...)

O problema de grandes saídas tornando um notebook descarregável pode acontecer em qualquer kernel do Jupyter, portanto, não se limita apenas ao IPython.

Estou executando o kernel localmente, então espero que a transferência de 4,6 MB de dados não demore tanto.
Meu palpite é que há um grande custo fixo para interpretar / renderizar uma dessas linhas padrão. ou seja, qual é a hora de renderizar 1 saída padrão com K linhas vs K saídas padrão com 1 linha cada.

Já falamos antes sobre colocar algumas proteções seguras para evitar que grandes quantidades de saída cheguem até o notebook (ou outros) front-ends. A maneira como lidamos com grandes saídas agora é muito problemática. Alguns pontos:

  • O próprio kernel deve gerenciar isso - ele deve se recusar até mesmo a enviar a saída além de um certo ponto.
  • O kernel deve salvar uma grande saída em algum lugar (provavelmente no disco, mas isso pode até ser um problema além de um certo ponto).
  • O kernel deve enviar algo que indique que uma grande saída foi gerada e fornecer ao usuário alguma maneira de visualizá-la, ou pelo menos informar ao usuário quanta saída foi gerada e onde foi colocada.
  • Tudo isso deve ser integrado com a rolagem / recolhimento de saída de maneira inteligente.

Mudei o título desta edição para refletir esta questão mais geral.

Ok, mas parece que o frontend sabe melhor o que é "demais". Se o kernel decidir, então seria o mesmo para todos os front-ends. O que é demais para o console é diferente do que para o notebook.

Eu concordo principalmente com você. Provavelmente faz sentido ter uma abordagem em camadas
onde inicialmente isso é tratado pelo frontend. Mas para dados realmente grandes,
você sabe que não há nenhum frontend que possa lidar com isso. Mas o mais
importante é que além de um certo ponto, nenhum ser humano pode razoavelmente
olhe para a saída. Não se trata apenas de desempenho, trata-se do usuário
experiência. Acho que podemos ser bastante agressivos ao dizer ao usuário "você
apenas tentei gerar mais resultados do que você poderia parecer "
independentemente do problema de desempenho.

Na segunda-feira, 12 de janeiro de 2015 às 10:38, Doug Blank [email protected]
escrevi:

Ok, mas parece que o frontend sabe melhor o que é "demais". Se o
o kernel decide, então seria o mesmo para todos os frontends. O que é também
muito para o console é diferente do que para o notebook.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/ipython/ipython/issues/6771#issuecomment -69620565.

Brian E. Granger
Universidade Estadual Cal Poly, San Luis Obispo
@ellisonbg no Twitter e GitHub
[email protected] e [email protected]

Inspirado por um comentário de @Carreau , fiz estas extensões de notebook:
https://github.com/ipython-contrib/IPython-notebook-extensions/wiki/limit-output

Funciona bem para mim para evitar que o navegador trave em ciclos de impressão intermináveis.

De acordo com @juhasch, a maioria dos travamentos do navegador
e o 'limite' depende muito do tipo de saída. Exibir a mesma quantidade de dados como PNG ou texto é completamente diferente em termos do que o navegador pode manipular.

@juhasch Acho que devo habilitar sua extensão por padrão para IPython 3, caso contrário, o estouro de pilha torna o notebook descarregável.

BTW, o que é que permite que você vá para / nbextensions / e clique em Ativar para uma extensão ... Eu também quero isso!

A extensão do servidor para / nbextensions / está nesta solicitação pull:
https://github.com/ipython-contrib/IPython-notebook-extensions/pull/164

Fechando porque este problema não está no próprio IPython e se ainda for problemático e relevante, deve ser aberto no repositório correto. Isso permitirá manter o número de problemas abertos no repositório IPython sob controle.

Fique à vontade para continuar comentando ou reabrir, se necessário.

Obrigado.

Esta página foi útil?
0 / 5 - 0 avaliações