Ipython: les fonctions magiques liées à backgroundjobs sont toutes manquantes

Créé le 8 oct. 2011  ·  15Commentaires  ·  Source: ipython/ipython

désolé pour la question stupide, mais où sont ces magies:
% emplois,% bg etc.

ipython a demandé que la fonction Magic 'xxx' ne soit pas trouvée chaque fois que je tape cette phrase magique dans ipython, et elle semble vraiment absente dans le "core / magic.py". J'ai également trouvé que nulle part dans ipython ne fait référence à la lib / backgroundjobs.py où le processus de gestion des travaux d'arrière-plan est défini.

bug

Commentaire le plus utile

Ce serait toujours génial d'avoir% bg en arrière ... pas seulement l'exécution en arrière-plan de script externe.
Nous utilisons ipython pour Spark et certaines commandes (comme la collecte de statistiques), peuvent devoir s'exécuter pendant une heure,
mais la plupart des cellules suivantes ne dépendent pas nécessairement de son résultat. Donc ce serait bien de courir
n'importe quelle cellule en arrière-plan, pas seulement des scripts externes. Merci.

Tous les 15 commentaires

Salut, j'ai peur que ce soit une victime du grand refactoring qui a eu lieu vers 0.11. Je ne me souviens pas pour le moment des raisons précises qui ont conduit à la suppression de celui-ci, cela aurait pu être accidentel, mais @bgranger pourrait avoir un meilleur souvenir car il a fait le gros travail de cette grande réorganisation.

Une partie du problème est que cette fonctionnalité était entièrement basée sur les threads, et en python, démarrer des threads d'arrière-plan pour tout ce qui nécessite beaucoup de processeur n'est pas une très bonne idée. Mais je peux voir comment cela pourrait être utile pour certains scénarios, et si nous pouvons le ramener sans créer de problèmes pour la nouvelle console ou le nouveau notebook Qt, nous pouvons l'examiner.

Pourriez-vous nous faire part de vos commentaires sur vos scénarios d'utilisation et à quel point cela est important pour vous? Des commentaires comme celui-ci nous aideront à évaluer à quel point cela devrait être critique en termes de hiérarchisation des efforts.

Notez que tout le code est là, c'est juste dans la balise 0.10.2 dans le référentiel git. Il ne serait donc pas trop difficile de le réactiver, si quelqu'un intervient pour aider et que nous le faisons avec une documentation et des tests appropriés.

Merci beaucoup pour votre réponse.
J'essayais juste des choses mentionnées dans le document en ligne, non
scénario d'utilisation particulier. Je serai heureux de faire le test si certains des
vous le considérez comme aucun mal et vous le ramenez.

Le lun.10 octobre 2011 à 05:04, Fernando Perez <
[email protected]> a écrit:

Salut, j'ai peur que ce soit une victime du grand refactoring qui a eu lieu
vers 0,11. Je ne me souviens pas pour le moment des raisons précises qui ont conduit à cela
l'un étant coupé, cela aurait pu être accidentel, mais @bgranger pourrait avoir un
meilleur souvenir comme il a fait le grognement travail de cette grande réorganisation.

Une partie du problème est que cette fonctionnalité était entièrement basée sur les threads, et
en python, démarrer des threads d'arrière-plan pour tout ce qui nécessite un processeur intensif n'est pas un
très bonne idée. Mais je peux voir comment cela pourrait être utile pour certains scénarios,
et si nous pouvons le ramener sans créer de problèmes pour la nouvelle console Qt
ou cahier, nous pouvons l'examiner.

Pourriez-vous nous faire part de vos commentaires sur vos scénarios d'utilisation et leur importance
Ceci est pour vous? Des commentaires comme celui-ci nous aideront à évaluer à quel point cela est critique
devrait être en termes de hiérarchisation des efforts.

Notez que tout le code est là, c'est juste dans la balise 0.10.2 dans le git
dépôt. Donc ce ne serait pas trop difficile de le faire revivre, si quelqu'un intervient
aider et nous le faisons avec une documentation et des tests appropriés.

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

Le dimanche 9 octobre 2011 à 18:28, digitalsatori
[email protected]
a écrit:

Merci beaucoup pour votre réponse.
J'essayais juste des choses mentionnées dans le document en ligne, non
scénario d'utilisation particulier. Je serai heureux de faire le test si certains des
vous le considérez comme aucun mal et vous le ramenez.

Eh bien, il y a un travail raisonnable à faire
de retour, et j'ai peur de ne pas avoir les ressources pour travailler sur ce droit
maintenant. Il faudrait donc qu'un utilisateur intéressé qui en ait besoin, investisse
un peu de temps sur l'effort. Le code principal est en lib/bacgkroundjobs.py ,
et nous pouvons récupérer la magie des balises 0.10.x. Ce serait un
question de retravailler ce code, de le valider chez les différents utilisateurs
environnements (terminal, console qt, notebook) et ajout de tests appropriés
à lui.

Intéressant et peut-être utile, mais à ce stade un peu
faible priorité, j'en ai peur.

Je vais laisser cela ouvert pour que d'autres puissent le trouver, et si un
l'utilisateur intéressé (y compris vous-même) veut sauter dessus, nous serons
heureux d'examiner toutes les demandes de tirage pertinentes.

Veuillez consulter gh-856 pour plus de détails. Lorsque cela sera fusionné, _une_ partie de cette fonctionnalité reviendra effectivement.

fermé par PR # 856

@minrk , le rouvrir %bg . Il reste donc un peu de travail à une âme intéressée, mais maintenant avec le gestionnaire de tâches bacgkround présent, la mise à jour de la magie devrait être facile. J'avais laissé celui-ci ouvert pour me rappeler ce fait.

Oh pardon. Il y avait une série de problèmes qui auraient dû être fermés automatiquement par les PR qui ne l'étaient pas, et je suppose que je suis devenu trop zélé.

Le mar 18 octobre 2011 à 16:33, Min RK
[email protected]
a écrit:

Oh pardon. Il y avait une série de problèmes qui auraient dû être fermés automatiquement par les PR qui ne l'étaient pas, et je suppose que je suis devenu trop zélé.

Pas de soucis! Je suis content de vous voir fermer, j'ai définitivement un similaire
envie de rapprocher notre nombre de relations publiques ouvertes de 0 et notre nombre de problèmes ouverts
sous contrôle. Idéalement, nous aurions de 0,12 juste un ou deux
ouvrir les RP, et j'aimerais que notre nombre de problèmes soit inférieur à 100, la plupart des
ceux qui sont de faible priorité ou d'amélioration. À l'heure actuelle, nous en avons ~ 40 avec
type-bug et prio- {med / high / critical}.

Et un nombre inconnu non trié (sans étiquettes).

À votre santé,

F

Le mar 18 oct 2011 à 16:38, Fernando Perez <
[email protected]> a écrit:

Le mar 18 octobre 2011 à 16:33, Min RK
[email protected]
a écrit:

Oh pardon. Il y avait une série de problèmes qui auraient dû être fermés automatiquement
par des PR qui ne l'étaient pas, et je suppose que je suis devenu trop zélé.

Pas de soucis! Je suis content de vous voir fermer, j'ai définitivement un similaire
envie de rapprocher notre nombre de relations publiques ouvertes de 0 et notre nombre de problèmes ouverts
sous contrôle. Idéalement, nous aurions de 0,12 juste un ou deux
ouvrir les RP, et j'aimerais que notre nombre de problèmes soit inférieur à 100, la plupart des
ceux qui sont de faible priorité ou d'amélioration. À l'heure actuelle, nous en avons ~ 40 avec
type-bug et prio- {med / high / critical}.

Et un nombre inconnu non trié (sans étiquettes).

J'ai utilisé mon script de problèmes pour garder un œil sur les problèmes non étiquetés. Nous avons
seulement un couple qui ne fait pas partie de:

A) affecté à un jalon
B) marqué dormant
C) étiqueté statut-actif, avec priorité et type

J'ai étiqueté de manière assez agressive la plupart des choses comme un jalon de 0,12, donc nous au moins
regardez-les avant de décider de les repousser à 0,13.

À votre santé,

F

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

Le mar 18 octobre 2011 à 16 h 55 min RK
[email protected]
a écrit:

J'ai utilisé mon script de problèmes pour garder un œil sur les problèmes non étiquetés. Nous avons
seulement un couple qui ne fait pas partie de:

A) affecté à un jalon
B) marqué dormant
C) étiqueté statut-actif, avec priorité et type

J'ai étiqueté de manière assez agressive la plupart des choses comme un jalon de 0,12, donc nous au moins
regardez-les avant de décider de les repousser à 0,13.

Excellent! BTW, pensez à mettre votre script dans les outils /? De cette façon nous pouvons
tous l'utilisent et l'affinent au fil du temps. J'ai des statistiques github là-dedans, donc
cela pourrait valoir la peine de fusionner une partie du code qui est probablement
dupliquer entre les deux ...

Pas besoin de PR pour cela, allez-y et faites-le à votre guise.

Cela a été résolu avec la nouvelle magie script , qui fournit un indicateur --bg .

Exemple:

%%script bash --bg --out script_out

sleep 10
echo hi!

Merci ! Fermeture alors!

Ce serait toujours génial d'avoir% bg en arrière ... pas seulement l'exécution en arrière-plan de script externe.
Nous utilisons ipython pour Spark et certaines commandes (comme la collecte de statistiques), peuvent devoir s'exécuter pendant une heure,
mais la plupart des cellules suivantes ne dépendent pas nécessairement de son résultat. Donc ce serait bien de courir
n'importe quelle cellule en arrière-plan, pas seulement des scripts externes. Merci.

J'ai des simulations Monte-Carlo qui durent environ deux heures, mais qui peuvent converger plus tôt. Des conclusions utiles et une détection de convergence plus précoce peuvent être effectuées lors de leur exécution en arrière-plan et lors du vidage des résultats intermédiaires dans un fichier. Un travail parfait pour% bg, alors veuillez rouvrir

J'ai des simulations Monte-Carlo qui durent environ deux heures, mais qui peuvent converger plus tôt. Des conclusions utiles et une détection de convergence plus précoce peuvent être effectuées lors de leur exécution en arrière-plan et lors du vidage des résultats intermédiaires dans un fichier. Un travail parfait pour% bg, alors veuillez rouvrir

La magie n'a pas besoin de faire partie d'IPython pour être disponible, vous êtes libre de publier un package sur PyPI qui expose une magie %bg . Cependant, d'après votre cas d'utilisation, il semble que ipyparallel et l'utilisation de Python Futures pourraient être plus appropriées.

Cette page vous a été utile?
0 / 5 - 0 notes