Ipython: funções mágicas relacionadas ao backgroundjobs estão ausentes

Criado em 8 out. 2011  ·  15Comentários  ·  Fonte: ipython/ipython

desculpe pela pergunta idiota, mas onde estão essas mágicas:
% jobs,% bg etc.

ipython solicitou a função Magic 'xxx' não encontrada sempre que eu digito essas frases mágicas no ipython, e parece realmente faltar no "core / magic.py". Eu também descobri que em nenhum lugar do ipython realmente se refere ao lib / backgroundjobs.py onde os trabalhos em segundo plano tratam do processo definido.

bug

Comentários muito úteis

Ainda seria ótimo ter% bg de volta .. não apenas a execução externa em segundo plano do script.
Usamos ipython para Spark e alguns comandos (como coleta de estatísticas), pode ter que ser executado por uma hora,
mas a maioria das células seguintes não depende necessariamente de seu resultado. Então seria bom correr
qualquer célula em segundo plano, não apenas scripts externos. Obrigado.

Todos 15 comentários

Olá, receio que tenha sido vítima de uma grande refatoração que ocorreu por volta de 0,11. Não me lembro agora dos motivos precisos que levaram a este ser eliminado, pode ter sido acidental, mas @bgranger pode ter uma melhor lembrança enquanto fazia o trabalho pesado daquela grande reorganização.

Parte do problema é que essa funcionalidade era toda baseada em threads e, em python, iniciar threads em segundo plano para qualquer coisa com uso intensivo de CPU não é uma ideia muito boa. Mas eu posso ver como isso pode ser útil para certos cenários, e se pudermos trazê-lo de volta sem criar problemas para o novo console ou notebook Qt, podemos dar uma olhada nele.

Você poderia nos dar algum feedback sobre seus cenários de uso e como isso é importante para você? Feedbacks como este nos ajudarão a avaliar o quão crítico isso deve ser em termos de priorização de esforços.

Observe que o código está todo lá, apenas na tag 0.10.2 no repositório git. Portanto, não seria muito difícil revivê-lo se alguém se apresentasse para ajudar e o fizéssemos com documentação e testes adequados.

Muito obrigado pela resposta.
Eu estava apenas experimentando os materiais mencionados no documento online, não
cenário de uso particular. Ficarei feliz em fazer o teste, se algum de
você considera isso nenhum dano e o traz de volta.

Na segunda-feira, 10 de outubro de 2011 às 5h04, Fernando Perez <
[email protected]> escreveu:

Olá, receio que tenha sido uma vítima da grande refatoração que ocorreu
para 0,11. Não me lembro agora das razões precisas que levaram a este
um sendo cortado, pode ter sido acidental, mas @bgranger pode ter um
melhor lembrança enquanto fazia o trabalho pesado daquela grande reorganização.

Parte do problema é que essa funcionalidade era toda baseada em threads e
em python, iniciar threads em segundo plano para qualquer coisa com uso intensivo de CPU não é um
muito boa ideia. Mas posso ver como pode ser útil para certos cenários,
e se pudermos trazê-lo de volta sem criar problemas para o novo console Qt
ou notebook, podemos olhar para ele.

Você poderia nos dar algum feedback sobre seus cenários de uso e quão importante
Isto é para você? Feedbacks como este nos ajudarão a avaliar o quão crítico isso
deve ser em termos de priorização de esforços.

Observe que o código está todo lá, apenas na tag 0.10.2 do git
repositório. Portanto, não seria muito difícil revivê-lo, se alguém se apresentasse
ajudar e nós fazemos isso com documentação e testes adequados.

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

No domingo, 9 de outubro de 2011 às 18:28, digitalsatori
[email protected]
escrevi:

Muito obrigado pela resposta.
Eu estava apenas experimentando os materiais mencionados no documento online, não
cenário de uso particular. Ficarei feliz em fazer o teste, se algum de
você considera isso nenhum dano e o traz de volta.

Bem, há uma quantidade razoável de trabalho envolvida em trazê-lo
de volta, e infelizmente não tenho os recursos para trabalhar nisso
agora. Portanto, seria necessário um usuário interessado que precisa investir
algum tempo no esforço. O código principal está em lib/bacgkroundjobs.py ,
e podemos obter a magia de volta das tags 0.10.x. Seria um
questão de retrabalhar esse código, validando-o nos diversos usuários
ambientes (terminal, console qt, notebook) e adicionar testes adequados
para isso.

Interessante e possivelmente útil, mas neste momento um pouco
baixa prioridade, receio.

Vou deixar isso aberto, para que outros possam encontrar, e se um
usuário interessado (incluindo você) deseja entrar nisso, nós estaremos
feliz em revisar quaisquer solicitações pull relevantes.

Consulte gh-856 para obter mais detalhes. Quando isso for mesclado, _algumas_ dessas funcionalidades realmente voltarão.

fechado por PR # 856

@minrk , reabrindo b / c eu nunca trouxe %bg volta. Portanto, ainda resta um pouquinho de trabalho para alguma alma interessada, mas agora, com o gerenciador de tarefas do bacgkround presente, atualizar a magia deve ser fácil. Eu tinha deixado este aberto para me lembrar desse fato.

Oh, desculpe. Houve uma série de problemas que deveriam ter sido fechados automaticamente por PRs que não foram, e acho que fiquei com excesso de zelo.

Na terça, 18 de outubro de 2011 às 16:33, Min RK
[email protected]
escrevi:

Oh, desculpe. Houve uma série de problemas que deveriam ter sido fechados automaticamente por PRs que não foram, e acho que fiquei com excesso de zelo.

Não se preocupe! Estou feliz em ver você fechando, eu definitivamente tenho um semelhante
desejo de trazer nossa contagem de relações públicas para mais perto de 0 e nossa contagem de edições abertas
sob controle. Idealmente, teríamos por 0,12 apenas um ou dois remanescentes
abrir PRs, e gostaria que nossa contagem de problemas fosse inferior a 100, com a maioria
aqueles de baixa prioridade ou melhoria. No momento, temos cerca de 40
bug de tipo e prio- {med / high / critical}.

E um número desconhecido não triado (sem rótulos).

Felicidades,

f

Na terça, 18 de outubro de 2011 às 16:38, Fernando Perez <
[email protected]> escreveu:

Na terça, 18 de outubro de 2011 às 16:33, Min RK
[email protected]
escrevi:

Oh, desculpe. Houve uma série de problemas que deveriam ter sido fechados automaticamente
por relações públicas que não eram, e acho que fiquei com excesso de zelo.

Não se preocupe! Estou feliz em ver você fechando, eu definitivamente tenho um semelhante
desejo de trazer nossa contagem de relações públicas para mais perto de 0 e nossa contagem de edições abertas
sob controle. Idealmente, teríamos por 0,12 apenas um ou dois remanescentes
abrir PRs, e gostaria que nossa contagem de problemas fosse inferior a 100, com a maioria
aqueles de baixa prioridade ou melhoria. No momento, temos cerca de 40
bug de tipo e prio- {med / high / critical}.

E um número desconhecido não triado (sem rótulos).

Usei meu script de problemas para controlar os problemas não rotulados. Nós temos
apenas alguns que não são:

A) atribuído a um marco
B) marcado como dormente
C) rotulado como status ativo, com prioridade e tipo

Eu rotulei de forma bastante agressiva a maioria das coisas como marco 0,12, então nós
olhe para eles antes de decidir empurrá-los de volta para 0,13.

Felicidades,

f

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

Na terça, 18 de outubro de 2011 às 16:55, RK mínimo
[email protected]
escrevi:

Usei meu script de problemas para controlar os problemas não rotulados. Nós temos
apenas alguns que não são:

A) atribuído a um marco
B) marcado como dormente
C) rotulado como status ativo, com prioridade e tipo

Eu rotulei de forma bastante agressiva a maioria das coisas como marco 0,12, então nós
olhe para eles antes de decidir empurrá-los de volta para 0,13.

Excelente! BTW, se importaria de colocar seu script em ferramentas /? Assim podemos
todos usam e refinam com o tempo. Eu tenho github-stats lá, então
pode valer a pena mesclar parte do código que é provavelmente
duplicar entre os dois ...

Não há necessidade de um RP para isso, apenas vá em frente e faça no seu lazer.

Isso foi resolvido com a nova magia script , que fornece uma bandeira --bg .

Exemplo:

%%script bash --bg --out script_out

sleep 10
echo hi!

Obrigado ! Fechando então!

Ainda seria ótimo ter% bg de volta .. não apenas a execução externa em segundo plano do script.
Usamos ipython para Spark e alguns comandos (como coleta de estatísticas), pode ter que ser executado por uma hora,
mas a maioria das células seguintes não depende necessariamente de seu resultado. Então seria bom correr
qualquer célula em segundo plano, não apenas scripts externos. Obrigado.

Tenho simulações de Monte-Carlo que funcionam por cerca de duas horas, mas podem convergir mais cedo. Conclusões úteis e detecção de convergência anterior podem ser feitas ao executá-los em segundo plano e despejar os resultados intermediários em um arquivo. Um trabalho perfeito para% bg, por favor, reabra

Tenho simulações de Monte-Carlo que funcionam por cerca de duas horas, mas podem convergir mais cedo. Conclusões úteis e detecção de convergência anterior podem ser feitas ao executá-los em segundo plano e despejar os resultados intermediários em um arquivo. Um trabalho perfeito para% bg, por favor, reabra

Magics não precisa fazer parte do IPython para estar disponível, você é livre para publicar um pacote no PyPI que expõe uma magia %bg . Embora no seu caso de uso, pareça ipyparallel e usar o Python Futures pode ser mais apropriado.

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