Ipython: Hintergrundjobs verwandte magische Funktionen fehlen alle

Hallo, ich fürchte, es war ein Opfer des großen Refactorings, das gegen 0.11 stattfand. Ich erinnere mich im Moment nicht an die genauen Gründe, die dazu geführt haben, dass dieser herausgeschnitten wurde. Es könnte ein Zufall gewesen sein, aber Grunzarbeit dieser großen Reorganisation erledigte.

Ein Teil des Problems besteht darin, dass diese Funktionalität ausschließlich auf Threads basiert. In Python ist es keine sehr gute Idee, Hintergrundthreads für CPU-intensive Inhalte zu starten. Aber ich kann sehen, wie nützlich es für bestimmte Szenarien sein kann, und wenn wir es zurückbringen können, ohne Probleme für die neue Qt-Konsole oder das neue Notebook zu verursachen, können wir es untersuchen.

Können Sie uns Feedback zu Ihren Nutzungsszenarien geben und wie wichtig dies für Sie ist? Ein solches Feedback hilft uns zu beurteilen, wie wichtig dies für die Priorisierung des Aufwands sein sollte.

Beachten Sie, dass der Code nur vorhanden ist. Er befindet sich nur im 0.10.2-Tag im Git-Repository. Es wäre also nicht allzu schwer, es wiederzubeleben, wenn jemand auftaucht, um zu helfen, und wir dies mit der richtigen Dokumentation und Prüfung tun.

Vielen Dank für die Antwort.
Ich habe gerade Sachen ausprobiert, die im Online-Dokument erwähnt wurden, nein
besonderes Anwendungsszenario. Ich werde den Test aber gerne machen, wenn einige von
Sie halten es für keinen Schaden und bringen es zurück.

Am Montag, den 10. Oktober 2011 um 05:04 Uhr, Fernando Perez <
[email protected]> schrieb:

Hallo, ich fürchte, es war ein Opfer des großen Refactorings, das stattgefunden hat
in Richtung 0,11. Ich erinnere mich momentan nicht an die genauen Gründe, die dazu geführt haben
Wenn einer herausgeschnitten wird, könnte es ein Unfall gewesen sein, aber
Bessere Erinnerung, als er das Grunzen dieser großen Umstrukturierung erledigte.

Ein Teil des Problems ist, dass diese Funktionalität alle thread-basiert war und
In Python ist das Starten von Hintergrund-Threads für alles, was CPU-intensiv ist, kein Problem
sehr gute Idee. Aber ich kann sehen, wie nützlich es für bestimmte Szenarien sein könnte,
und ob wir es zurückbringen können, ohne Probleme für die neue Qt-Konsole zu verursachen
oder Notebook, wir können es untersuchen.

Können Sie uns ein Feedback zu Ihren Anwendungsszenarien geben und wie wichtig diese sind?
Das ist für dich? Ein solches Feedback hilft uns zu beurteilen, wie kritisch dies ist
sollte in Bezug auf die Priorisierung der Bemühungen sein.

Beachten Sie, dass der Code nur vorhanden ist. Er befindet sich nur im 0.10.2-Tag im Git
Repository. Es wäre also nicht allzu schwer, es wiederzubeleben, wenn jemand auf ihn zukommt
helfen Sie aus und wir tun dies mit der richtigen Dokumentation und Prüfung.

Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an:
https://github.com/ipython/ipython/issues/844#issuecomment -2341138

Am Sonntag, 9. Oktober 2011, um 18:28 Uhr, digitalsatori
[email protected]
schrieb:

Vielen Dank für die Antwort.
Ich habe gerade Sachen ausprobiert, die im Online-Dokument erwähnt wurden, nein
besonderes Anwendungsszenario. Ich werde den Test aber gerne machen, wenn einige von
Sie halten es für keinen Schaden und bringen es zurück.

Nun, es ist ein angemessener Arbeitsaufwand erforderlich, um es zu bringen
zurück, und ich fürchte, ich habe nicht die Ressourcen, um an diesem Recht zu arbeiten
jetzt. Es würde also einen interessierten Benutzer erfordern, der es braucht, um zu investieren
einige Zeit auf der Anstrengung. Der Hauptcode ist in lib/bacgkroundjobs.py ,
und wir können die Magie von den 0.10.x-Tags zurückbekommen. Es wäre ein
Angelegenheit, diesen Code zu überarbeiten und ihn in den verschiedenen Benutzern zu validieren
Umgebungen (Terminal, QT-Konsole, Notebook) und Hinzufügen geeigneter Tests
dazu.

Interessant und möglicherweise nützlich, aber zu diesem Zeitpunkt etwas
Ich fürchte, niedrige Priorität.

Ich werde dies jedoch offen lassen, damit andere es finden können, und wenn eine
interessierter Benutzer (einschließlich Sie selbst) möchte darauf springen, wir werden es sein
Gerne prüfen wir alle relevanten Pull-Anfragen.

Weitere Informationen finden Sie unter gh-856. Wenn das zusammengeführt wird, werden einige dieser Funktionen tatsächlich wieder verfügbar sein.

geschlossen durch PR # 856

@minrk , wieder öffnen b / c Ich habe nie %bg zurückgebracht. Es bleibt also ein wenig Arbeit für eine interessierte Seele übrig, aber jetzt, da der Bacgkround-Jobmanager anwesend ist, sollte es einfach sein, die Magie zu aktualisieren. Ich hatte diesen offen gelassen, um mich an diese Tatsache zu erinnern.

Oh, das tut mir leid. Es gab eine Reihe von Problemen, die von PRs, die es nicht waren, automatisch geschlossen werden sollten, und ich glaube, ich wurde übereifrig.

Am Dienstag, 18. Oktober 2011, um 16:33 Uhr, Min RK
[email protected]
schrieb:

Oh, das tut mir leid. Es gab eine Reihe von Problemen, die von PRs, die es nicht waren, automatisch geschlossen werden sollten, und ich glaube, ich wurde übereifrig.

Keine Sorge! Ich bin froh, dich schließen zu sehen, ich habe definitiv eine ähnliche
Drängen Sie darauf, unsere Anzahl offener PRs näher an 0 und unsere Anzahl offener Probleme zu bringen
unter Kontrolle. Idealerweise hätten wir um 0,12 nur noch ein oder zwei verweilt
Öffnen Sie PRs, und ich möchte, dass unsere Ausgabe mit den meisten unter 100 liegt
diese haben niedrige Priorität oder Verbesserung. Im Moment haben wir ~ 40 mit
Typ-Bug und Prio- {med / high / kritisch}.

Und eine unbekannte Nummer ohne Triag (ohne Etiketten).

Prost,

f

Am Di, 18. Oktober 2011 um 16:38 Uhr, Fernando Perez <
[email protected]> schrieb:

Am Dienstag, 18. Oktober 2011, um 16:33 Uhr, Min RK
[email protected]
schrieb:

Oh, das tut mir leid. Es gab eine Reihe von Problemen, die automatisch geschlossen werden sollten
von PRs, die es nicht waren, und ich glaube, ich wurde übereifrig.

Keine Sorge! Ich bin froh, dich schließen zu sehen, ich habe definitiv eine ähnliche
Drängen Sie darauf, unsere Anzahl offener PRs näher an 0 und unsere Anzahl offener Probleme zu bringen
unter Kontrolle. Idealerweise hätten wir um 0,12 nur noch ein oder zwei verweilt
Öffnen Sie PRs, und ich möchte, dass unsere Ausgabe mit den meisten unter 100 liegt
diese haben niedrige Priorität oder Verbesserung. Im Moment haben wir ~ 40 mit
Typ-Bug und Prio- {med / high / kritisch}.

Und eine unbekannte Nummer ohne Triag (ohne Etiketten).

Ich habe mein Issues-Skript verwendet, um unbeschriftete Issues im Griff zu behalten. Wir haben
nur ein paar, von denen keines ist:

A) einem Meilenstein zugeordnet
B) als ruhend markiert
C) als statusaktiv mit Priorität und Typ gekennzeichnet

Ich habe die meisten Dinge ziemlich aggressiv als Meilenstein von 0,12 bezeichnet, also zumindest wir
Schauen Sie sie sich an, bevor Sie sie auf 0,13 zurückschieben.

Prost,

f

Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an:
https://github.com/ipython/ipython/issues/844#issuecomment -2449351

Am Dienstag, 18. Oktober 2011, um 16:55 Uhr, Min RK
[email protected]
schrieb:

Ich habe mein Issues-Skript verwendet, um unbeschriftete Issues im Griff zu behalten. Wir haben
nur ein paar, von denen keines ist:

A) einem Meilenstein zugeordnet
B) als ruhend markiert
C) als statusaktiv mit Priorität und Typ gekennzeichnet

Ich habe die meisten Dinge ziemlich aggressiv als Meilenstein von 0,12 bezeichnet, also zumindest wir
Schauen Sie sie sich an, bevor Sie sie auf 0,13 zurückschieben.

Ausgezeichnet! Übrigens, möchten Sie Ihr Skript in Tools /? So können wir
Alle benutzen es und verfeinern es im Laufe der Zeit. Ich habe dort Github-Statistiken
Es könnte sich lohnen, einen Teil des Codes zusammenzuführen, der wahrscheinlich ist
Duplikat zwischen den beiden ...

Dafür ist keine PR erforderlich. Machen Sie es einfach nach Belieben.

Dies wurde mit der neuen Magie script behoben, die ein Flag --bg bereitstellt.

Beispiel:

%%script bash --bg --out script_out

sleep 10
echo hi!

Vielen Dank ! Dann schließen!

Es wäre immer noch großartig,% bg zurück zu haben. Nicht nur die Ausführung des externen Skripthintergrunds.
Wir verwenden ipython für Spark und einige Befehle (wie die Statistiksammlung) müssen möglicherweise eine Stunde lang ausgeführt werden.
Die meisten der folgenden Zellen hängen jedoch nicht unbedingt von ihrem Ergebnis ab. Es wäre also gut zu rennen
Jede Zelle im Hintergrund, nicht nur externe Skripte. Dankeschön.

Ich habe Monte-Carlo-Simulationen, die ungefähr zwei Stunden dauern, aber möglicherweise früher konvergieren. Nützliche Schlussfolgerungen und eine frühere Konvergenzerkennung können durchgeführt werden, wenn sie im Hintergrund ausgeführt werden und Zwischenergebnisse in einer Datei gespeichert werden. Ein perfekter Job für% bg, also bitte wieder öffnen

Ich habe Monte-Carlo-Simulationen, die ungefähr zwei Stunden dauern, aber möglicherweise früher konvergieren. Nützliche Schlussfolgerungen und eine frühere Konvergenzerkennung können durchgeführt werden, wenn sie im Hintergrund ausgeführt werden und Zwischenergebnisse in einer Datei gespeichert werden. Ein perfekter Job für% bg, also bitte wieder öffnen

Magics müssen nicht Teil von IPython sein, um verfügbar zu sein. Sie können ein Paket auf PyPI veröffentlichen, das eine %bg Magie enthüllt. Aus Ihrem Anwendungsfall scheint es jedoch ipyparallel zu sein, und die Verwendung von Python-Futures ist möglicherweise besser geeignet.