「bashとかでは無理?」記事へのコメント

pythonだけど

[ninestars (5792)]

日記の方 [srad.jp]でさくっと書いてみました。
最近の環境ならばそのまま動くはずです。よろしければどうぞ。

Re:

[okky (2487)]

ありがたいのですが、それは極めれば極めるほど GNU parallel そのものに…
というか是非 GNU parallel そのものに…
# というか オリジナルがもはやどこに行ったのかわからないぐらいライブラリが普及した Expect 同様
# あらゆる言語で GNU parallel を記述していただいて…

--
fjの教祖様

Re:pythonだけど

[ninestars (5792)]

この手の並列処理での懸念の一つとして、必ずしも全てのジョブが成功するとは限らないという点があります。
それをどう表現するかという問題もあり、GNU parallel (とリスペクト元のxargs)はEXIT STATUSでジョブが失敗したことは分かるのですが、どれが失敗したのが分からないのが個人的には不満ですね。
拙作ではベストとは思いませんがそのまま出力してみました。失敗ジョブを抜き出して再実行などの加工がしやすいかと。

実用

[tslashn (37583)]

実用に供されている、つまりそこそこ以上テストされている、
スクリプトを適当なProjectから引っ張る、たとえば

http://trinityrnaseq.svn.sourceforge.net/viewvc/trinityrnaseq/trunk/ut... [sourceforge.net]

なんかどうでしょう。すぐに読める長さ。
ライセンスはご確認ください。
http://trinityrnaseq.svn.sourceforge.net/viewvc/trinityrnaseq/trunk/LICENSE [sourceforge.net]

Re:pythonだけど

[okky (2487)]

ある処理が成功しなかったとして、それ以降の処理を停止するべきか、続行するべきか、というのがポイントでしょう。
GNU parallel のようなソフトは

「いやいや、続行するべきでしょ? どれが失敗したのかは自分で記録してよ。
　つーか、あとで調べて分かるなら、記録する必要すらねーべ?!?」

というスタンスなのではないかと。個人的には
「完全に独立した処理をひたすら並行処理するだけ」
の機構は、そちらのほうがありがたいです。

--
fjの教祖様