freezeするほどでもない(ちょっとした作業サーバなど)という時にjupyter_configや.xonshrc等の設定ファイルに自動インストールするように書いておけば良いのではと思って書いたメモです。moduleを使ってインストールしてやる仕組みを作ります。加えて「PyPiに登録されているパッケージのリストを取得し、その中になければ諦めるという仕組み」「xontribの自動インストール」も示します。-python3にはpipモジュールが含まれているため、以下のような形で動的なインストールを実装します。as構文を利用したい場合もあるかと思いますので、globalsに入れるように書いておきます。'0.22.0')print(pd)pandasをアンインストールした状態でもスクリプト実行時にインストールが行われます。試しに、上記スクリプトをpythonが動くshellであるxonshの設定ファイルに書き込んでみます。消してもxonsh起動時になければ新しくインストールされています。jupyterもconfigに書けば同じことができると思います。-上記に記載の仕組みに加え「自身が作成しているオリジナルのモジュールもpipで入れたい」などの要望と入り混じった時、PyPiに登録されているライブラリかどうかを判定する必要が稀に出てきます。PyPiに登録されているライブラリ一覧を取得するスクリプトを加えたものを以下に示します。pypi')また、月更新くらいでpypiにあるパッケージやバージョンを見るようにしておけば、rcファイル等に書く時にも便利になるでしょう。-xonshアドベントカレンダーの記事ですので、xonshに書くためのtipsも示します。loadなるコマンドが用意されています。実装を見ると、xontribs_load関数で読み込めなかった場合、prompt_xontrib_install関数で生成した以下のような文字列を返す実装になっています。GitHub文字列返しても仕方ないので、ロード部分となるupdate_contextをoverrideして自動でpipするようにしてみます。packageをinstallし、他env環境などから切り離すことが出来ます。そちらを利用する事でxonshのアップグレードにも対応できます。そちらはpip._internal.mainからは利用できないため、その場合は以下のように_mainでなくsubprocessなどでインストールしてやれば良いでしょう。loadコマンドを実行すれば、勝手にpipでパッケージを取ってくることが出来ます。Stimulatorなる記事で私が作成したライブラリです。messageが短くキレイに色付けされ表示されています。コマンドをxonshrc内でインストールするコマンドの有無も確認し、なければインストールするようにしておくと便利です。pythonではshutil.whichメソッドがそれらをサポートしてくれているので利用すると良いでしょう。「コマンドが無ければ〜」というサンプルを以下に示します。scriptもほぼ同等に動くわけなので、何も考えず最新版をインストールシェルスクリプトを書くだけです。私がよく使っているpecoなら以下をそのまま書くだけ。-これでxonsh周りの実行環境作成は、xonshrcだけで完結すると思います。load等も組み合わせながら、xonshの起動を高速化しつつ、最低限のラインとして使っています。vaaaaaanquish.hatenablog.comxonshアドベントカレンダーのほうはまだ空きがあるみたいなので、よければ是非。-macOSを使っていると、通知(Notifications)に色んな情報が集約される。メールが来ただのSlackの更新だの、アプリのアップデート等がそれにあたる。barとかに表示してやれば、作業中でも社内チャットやらメールの通知とかを厳選して気付けたりするしサイコーなのでは?」という所を目的にした作業ログを示すものである。Qiitaの7日目の記事。Serriaになった時、ユーザ向けにもAPIが公開されたNotifications。wrapperとなるpyncなどが出てきて、ユーザが通知欄に任意のメッセージを送る事は難しくなくなった。CentermacOSが提供するAPIでは「アプリXから通知を送る」「アプリXから送った通知を消す」「アプリXが送った通知のリストを取得する」が利用できるが、これらを利用しても「全てのアプリから送られた全ての通知を取得する」事はできない(記事執筆時、2018/11/24)。完全な情報を取得する事はできないが、以下のpatreon記事によると、システムデータベースには通知の断片ログが残っているようである。Wardle氏である。www.patreon.comMacのsystemのpythonに含まれるFoundationクラスを利用する事でこのログを読むことができる。*1上記記事内のdumpNotificationDB.pyをベースに、通知毎のタイトルと内容と日付、アプリ名を取得し表示するスクリプトを以下に示す。''macOSのpython2系を利用するため、codecsを利用してunicodeをdecodeしたり、printがアレだったりするが仕方ない。先述の通り、system-pyhtonのFoundationが必要なため、/usr/bin/pythonを利用して実行する。電源コンセントに接続しない場合、お使いのmacは間もなくスリープ状態に入ります。オッケです!あくまで通知時のログなので、既に通知欄から削除した、していないという情報は得られないが、概ね十分そうである。-xonshのアドベントカレンダーなのでxonshを利用してshellに流し込む上記スクリプトの出力部分を一行空白区切りで情報を出力するように修正します。range(128)」みたいになるためさらに酷くなっているが仕方ない。このpython2のスクリプトにおけるprintを標準出力から受け取り、xonshで表示できるような関数にする。python3からsubprocess経由で/usr/bin/pythonを使い、上記ファイルを実行するスクリプトを以下に示す。toolbarに表示してみる。python2と3を経由するかなり気持ち悪い感じだが出来たコマンドは以下のような感じ。get_last_notif(クソ...!よこせストレージを...!!)このままだとUPDATE_COMPLETIONS_ON_KEYPRESSをTrueにしていれば、キー入力毎に評価され、DBを読みに行ってparseしてという処理がキー入力毎に発生してしまいますので、一度どこかにキャッシュして一定時間ごとに更新するなどの処理が必要そうである。目的は達成したので、キャッシュの話はまた別途という事にする。-通知をキャッシュして、直近のものを順繰りで表示しておいたりすると便利そう。書けばxontribみたいにできるかも...?ただMacの通知取得の方法が若干アレなので、アップデートで使えなくなる可能性もあるし、素直にAppleが相応のAPIを公開してくれたほうが良さそうだなと思う。xonshアドベントカレンダーの方がまだまだ後半ガラ空きという状態なので書いてほしいです。Qiitaの5日目の記事です。Qiitaにおいて、私は以下のような2つの記事を投稿しています。(以下、ptk)を利用したものです。今回のアドベントカレンダー2018の1日目の記事にも書いた通り、xonshはptkのwrapperと言っても過言ではないレベルでptkは重要な役割を担っています。ptkを理解する事は、xonshを理解する事に繋がっています。2018年、ptkは1.xから2.xへのメジャーアップデートにおいて多くの破壊的変更を含んでいます。documentation本記事は、前年度の以下のようなコマンドをptkの破壊的変更を逐一確認しながら進めるものです。このコマンドにはptkの多くの要素が含まれており、これらを確認していくとおのずと詳細にふれる事ができます。2.xに対応した今年にぴったりの記事です。-前年度実装したコマンドから変更点を抜き出しながら逐一確認していきます。repositoryにも公開しています。toolkitMouseEventTypeのリネームマウス操作が入った時に落とすためのデコレータ部分です。MouseEventTypeはMouseEventTypesにリネームされていますので変更が必要です。mouse_event)としていた第一引数の変数名をappに変更しています。cliという表記は後方互換性のためにptkの中でもいくつか残っているものの、今後無くなっていくかと思われますので、ここでもそれに習います。KeyBindingManagerとKeybindingsキーバインディング周りは、KeyBindingManagerクラスが廃止され、KeyBindingsクラスによって全て賄う事ができるようになっています。これは、xonshrc等を書く場合でも同様です。加えて、Keysクラスによって管理されていたキー入力周りですが、KeyBindingsでは「c-a」のようなstrを利用する事ができます。その他、KeyBindingsのデコレータを付けた関数の引数に入るevent.cliはset_return_valueメソッドを持たなくなっています。1.xではここにCommandLineInterfaceというクラスが入っていましたが、CommandLineInterfaceはapplication.Applicationクラスに統合されました。上記MouseEventTypeの項でもcliという表記をappに変更したのは、そのためです(詳細は後述)。Applicationクラスにset_return_valueメソッドはないため、exitを利用して同様の動作を実現します。event.app.exit(None)ガラッと変わっているのが目に見えてわかると思います。前回の記事に記載のmove_cursor_down、move_cursor_upについてもKeyBindingsに対応させる事で動作させる事ができます。Styleの設定Style周りの変更は、かなり大きな影響を与えているように思います。2.xでは、Pygmentsのトークンのサポートを残しつつ、CSSのような独自コンポーネントが作成され、自由なクラス名を割り当てて自由なスタイリングを行う事が可能になりました。1.xを利用してstyleを定義する部分です。'bold',})同様の記載方法を利用したい場合はpygmentsのTokenクラスを利用する必要があります。'#5F819D'」のように取り扱われます。classnameに変換して使う必要があります。前述の通りptk2.xではpygemntsを使わない記法も可能です。'bold'})上記の例は大げさですが、他クラスに被らなければ自由なクラス名をつける事が可能です。'piyo')」のようなtupleを作ってprint_formatted_textに投げてあげるとコンソール上にカラースタイルが適応された状態で表示する事ができます。style=inquirer_style)より詳細には以下を参考にすると良いでしょう。classnameの比較表もあります。前回の記事においては、get_prompt_tokens関数を定義して、promptに動的にテキストを渡すようにしています。こちらも上記Styleの変更に対応するため、変更が必要です。ptkのtokenの利用を止め、pygments.tokenを利用する事でほぼ同じ記述で同じ動作が実現できます。最後returnする時にpygments_token_to_classnameで「class:pygments.hoge」な記法に変換してやれば良いです。tokens]tokenとテキストのtupleをリストにして返す関数ですが、returnする時にtuple[0]のtokenを変換する処理を挟んでいます。前述のStyleでも紹介した通り、pygmentsを使わない記法も使えますので、そちらも検討すると良いでしょう。TokenListControlがFormattedTextControlにリネーム前回の記事では、layout.controls.TokenListControlなるクラスを継承し、InquirerControlなる独自のセレクトアイテムを制御するClassを定義していました。2.xではTokenListControlクラスはFormattedTextControlにリネームされています。加えて、前述したStyle出力と同様に、pygments_token_to_classnameを使ってStyleの記法を変更する必要もあります。InquirerControl(choices)Tokenについては前述同様pygments.tokenを利用していますが、tokenを利用しない記法に変えても大丈夫です。LayoutとContainer前述の通り、TokenListControlはリネームされました。その結果、引数のとり方が変わっているため注意が必要です。加えて、ptk2.xでは表示アーキテクチャにContainerという概念が出てきました。RendererオブジェクトはLayoutで定義されたオブジェクトを画面に表示します。2.xにおいて、Layoutを構成する要素はContainerとUIControlの2つです。Containerは水平、垂直分割を利用したContainerを再帰的に定義する事ができます。UIControlはWindowやFormattedTextControl等を含んでおり、表示のサイズ、形式を定義する事ができます。ptk1.xまでHSplitメソッドはContainerではなくLayoutを直接返していましたが、ptk2.xではContainerを再帰的に定義できるようにすることでより複雑なLayoutを実現できるようになったため、HSplitメソッドはContainerを返すようになりました。よって以下のように、Layoutの定義の最後にLayoutクラスにする変更が必要です。Layout(HSContainer)LayoutとContainerの関係については、以下を見ておくと良いでしょう。https://python-prompt-toolkit.readthedocs.io/en/master/pages/advanced_topics/rendering_flow.htmlhttps://python-prompt-toolkit.readthedocs.io/en/master/pages/full_screen_apps.html?highlight=Container#the-layoutまた、アーキテクチャの全体像については(少し古いですが)以下が参考になります。2.xではinterface.CommandLineInterfaceはapplication.Applicationにmergeされています。(後方互換のため、少なからずcliなる記載やメソッドが残っていますが)最後に今までの項で作った設定や関数を利用してptkアプリを実行する部分のコードを以下に示します。style=inquirer_style)app.run()ApplicationはCommandLineInterfaceと違って適切にeventloopを設定してくれるようになっているため、eventloopを明示的に書く必要はありません。1.xと2.xのそれぞれを以下のrepositoryに入れてあります。それぞれのdiffを見る事で違いを確認できます。-ptkの理解はxonshの理解です。他にもptkのリファレンスには様々なApplicationのサンプルがありますので、一読し是非ともxonshに活かして頂ければと思います。Qiitaの1日目の記事です。1日目という事ですので、2018年を振り返ってxonshにどんな動きがあったかの簡単な振り返りです。なるxonshの情報を発信する部屋を運用しています(誰も発言してくれないので私しか発言してないですが)。そこでxonshのアップデート情報及び、xonsh関連の情報をまとめていまして、今回はそちらから引用しつつ2018年の節目とできればと思います。-xonshの2018年の流れを順を追いながらまとめます。重要なワードを節としていくので、気になるところは目次より飛んで頂けると良いかと思います。shellとしての歩み2018年の0.5.2から0.5.82018年のreleaseタグは少々混雑していまして3月に0.5.3から0.5.8までが一気に打たれました。2018年、最初のreleaseは0.5.2で、そこから一気に0.5.8まで流れていきます。0.5.3を軽く振り返ります。GitHub多くのbugfixに加えて、python-prompt-toolkit(以下、ptk)のpygments依存が解消しています。releaseにおいてこのptkとのやり取りは切っても切り離せません。Pythonなツールキットです。REPL、python実装のvimであるpyvimなど、多くの実装がこのptkを利用しています。highlightのためのパッケージに完全に依存していました。textベースなカラーリングもできるようになりました。xontribの追加、subprocessの結果のredirect等、shellとしての強化が多く成されています。0.5.4ではXONSH_HISTORY_BACKENDやHistoryEntryなど、履歴関連周りが良くなりました。GitHubまた、この時bash_completionが別プロジェクトとして切り離されました。xonsh上でbash補完を利用したい場合は、bash_completionを別途導入する形になりました。(bash_completionについてはまたアドベントカレンダー内で書ければと思います)0.5.5では、$UPDATE_COMPLETIONS_ON_KEYPRESSで補完出す出さないの管理が出来たり、configファイルとなるxonshrc関連が多く変更されています。xontribが追加されています。fixなども入っています。GitHubsubprocessのリスト、文字列のリダイレクトは非常に大きな改善だったかと思います。以下がやっと動くように。shellとしても改善が進みました。0.5.8では_TeeStdクラスに変更が入っています。GitHubxonshでは標準入出力を独自のTeeStdクラスによって管理している事は知っておいた方が良いでしょう。GitHub前年度のアドベントカレンダーで、xonshの入出力をイジろうとした時、私もこのクラスでハマっています。vaaaaaanquish.hatenablog.com0.6.0に向けた怒涛のbugfixラッシュ0.6.0に向けた細かなbugfixやrelease.xshの修正が続きます。GitHubxonshにcontributeした時は、以下にあるように/newsディレクトリ配下に更新内容を書いた[branch名].rstを追加します。documentation各プルリクで追加されたrstファイルがmergeされてreleaseタグの内容となる仕組みです。自分出したプルリクで書いたrstがreleaseタグに書かれているとちょっと嬉しいですし、後で記録に残る良い習慣です。開発者向けですが、それらが整備されているのも非常に大切なOSSの要素の一つだと感じます。Python3.6以降もサポート0.6.xが出た!0.6.0ではついにPython3.6のf-stringがサポートされました。shellとしての機能拡張が進みます。xontribも割と使っています。0.6.1ではWindowsにおけるMSYS2のサポートや`~/.config/xonsh/rc.xsh`にあるrcファイルの読み込みが追加されています。GitHub0.6.xでの変更箇所は大きく、同僚とも「Linuxでlsできなくなった」「コメントが効かなくなった」等の会話をした記憶があります。fixが発生しています。ここでは書ききれないので省きますが、この辺りで多くのPython周りのbugが修正されています。0.6.xのどこか辺りでimportも高速化されたんですが、ちょっと思い出せなかったです...config.jsonの死0.6.2より前では、xonshrcの他にconfig.jsonなるファイルを利用して設定できる項目がいくつか存在していました。GitHubここでconfig.jsonは完全にサポートされなくなりました。(xonshrc)!」config.jsonに関する記載がWeb上には幾つかありますが、今はもう亡き存在として扱って大丈夫です。fixとError入出力の変更を経て、0.6.4ではPython3系の革命児であり問題児であるAsync/Awaitをトークナイザーのキーワードに追加する対応をしています。GitHubPython3.7で予約語に追加され、様々なフレームワークで課題になっているAsync/Await。xonsh本体に大きな影響はなかったと捉えていますが、それでもやっぱり対策は大事です。promptゾンビ問題の解消0.6.5で設定ウィザードのI/Oが修正、0.6.7でEnvPathのメソッド拡充が行われた後、0.6.7でゾンビプロセス問題が解消しました。GitHubこれは割と使う側から見て大きな改良かと思います。pythonのサブプロセスが結果を返せなかった時に発生していたissueで「xonsh使うとPCが重い」といった現象の元になっていました。この辺りから、不意にxonshが落ちる現象がほぼ無くなり、安定して常用できるshellになってきたように記憶しています。ptk2.xへの移行ptk2.x対応スタート大きな変更となったのが前述しているコアライブラリであるptkのバージョンアップです。1.xから2.xにおいては、いくつかの破壊的変更が含まれており、それらを利用するjupyter等も順次対応していく形となったのが2018年の後半の動きです。2.x対応必要だよねという流れが出来てきました。GitHubひとまずreadlineが起動する所まで、ここでfixされています。その後小さなサブプロセス周りの拡充0.6.10を経て、ptk2.xに完全対応していく0.7.xが始まりました。GitHub怒涛のptk2.x対応7月には0.7.0が出ました。2018年7月16日ptk2.xの対応は、ひとまず動くという状態でしたが、$SHELL_TYPEで切り替え可能になっていたりしたので一通り使えるようにはなっていました。ユーザ目線では、prompt-toolkitに含まれるメソッドが大きく変更されたため、xonshrcの書き換えが必要になりました。以下にも記載していますが、一番汎用的な例を出すとKeybindの書き方が変わります。vaaaaaanquish.hatenablog.com以下は複数行のコマンド入力中にctrl+vでvim編集できるようにする設定ですが、メソッド構成が変更になったことによって書き方を変える必要が出ました。1.x形式で記載している場合があるため、注意が必要になってきます。0.7.1では、その他ptk2.xで動かなくなった機能などの一斉fixが行われました。GitHub手前味噌ですが、私もここからcontributerになりました。最初は「コンソールが下までスクロールした時ptk2.xが補完出してくれない」というbugをptkのソース読みながら直しました。以降は、bugやドキュメントの整備などをやっています。2018年の冒頭に出てきたpygmentsもptk2.xへの変更で更なる課題となってきました。styleも取り入れながら0.7.3が登場しました。Kernelも上手く動作するようになっていきます。names、補完のバグが修正されています。GitHub0.7.4から数時間後には、ptk2におけるhistoryの順番がfixした0.7.5が出ました。GitHubはじまるptk拡張なんでこんな大きな変更を含んだptk2.xなんじゃいというのもあるんですが、ptk2.xの更新はデカいです。「補完を上下移動で選択」が「左右移動でも選択可能」になったのはptk2.xからです。stackが0.7.6で出ました。メイン開発者のscopatzは個人的に使ってたみたいですが、乗っかる形ですね。補完魔改造時代のスタートです。_f続く0.7.7では、$XONSH_HISTORY_MATCH_ANYWHEREをTrueにする事で上矢印で履歴エントリを検索できるようになりました。https://github.com/xonsh/xonsh/releases/tag/0.7.7これ自体はptk2.xの恩恵という訳ではないですが、shellとしてかなり一般的に使われている機能で、また一つ力強くなったように感じます。Xonsh」なる記事がOpensource.comに投稿されます。opensource.comまた、0.7.8になる手前辺りでクックパッドインターンの体験記事に「インターン生がxonshを使っている」という文言が出てきました。nanabyo.hatenablog.com流石クックパッドさんですね。shell」なるスレッドが立ちました。News内のトップスレッド20に入るなどしました。Newsで話題になる事がどれだけ大きいか。trendにもxonshがランクインします。https://github.motakasoft.com/trending/?d=2018-09-15&l=python話題として今年最も躍進した月でした。jupyterもptk2.xへこの頃、ちょうどjupyter(より正確にはIPython)もptk2.xへの対応が進みました。kernelを動かすと落ちるという課題を抱えており、xonshとjupyterを併用で利用するのが少々複雑な状態でした。等を推奨していました。github.com現在、ptk2.xでの課題はほぼほぼ解消しています。この関係性によって、xonshにコミットしptkにコミットする事でjupyterプロジェクトにも貢献できるという所が非常に楽しいです。2018年後半、そして0.8.xへ増えるpython機能のサポート0.7.8ではcollections.ChainDBがサポートされました。syntaxが書けるようになり、かなり便利になりました。ように環境変数を参照できるようになりました。GitHub徐々にpython本体の便利なメソッドを吸収しつつ、shellとして進化していきます。0.8.xが来た!Archにも来た!いよいよ0.8.0の登場です。ここまで一部変更できず気になっていた色の問題も$PTK_STYLE_OVERRIDESの登場により、ほぼ完全にxonsh上の全ての色を完全に設定できるようになりました。shellsからfishが消えました。repositoriesからxonshが利用できるようになりました。GitHub他にも以下のようにSubprocSpecにpipeline_indexなる属性が付くようになりました。使い所は少々難しいですが、shellの結果をPythonに流すような場合に汎用性が高まったと言えるでしょう。00.8.2ではf-stringsが完全に動作するようになりました。!を利用した構文とカニバるので!を犠牲にするわけですが、pythonの機能を優先するという意味で良い改修だったと思います。z,)がfixするなど、Pythonの書き方をshell上で再現できるようになってきました。あと私は使ってないんですがvirtualenvのサポートが含まれており、これは結構待望されてた感じなのではないでしょうか。加えて、0.8.xから古い書き方に対して警告が出るようになり始めました。徐々に移行していく必要があります。-急ぎ足で、主に追加された機能の多くを振り返っていきました。開発スピードも早く、2018年話題になった事で開発者も増えたxonshの動きをこれからも応援しcontributeしていければと思っております。-近年、VRのブームのおかげもあってモーションキャプチャー分野も発展しつつあります。3.xから利用し、様々な家電やPC上の操作をジェスチャーで行おうという記事です。-前述したように、人体の動きをデータ化するモーションキャプチャー分野は、近年急速に発展しています。2017)が出たりとか、あらゆる方面から進展しています。Motion社が発売しているハンドモーションキャプチャーデバイスです。光センサ、赤外線センサを搭載していて、なかなかの精度で手の骨格の動きを取得する事ができます。Engineへの対応、以下の言語に対応するSDKとライブラリが公開されています。見る近年IT企業に増えつつある「月1万技術向上に使って良いよ〜」みたいな枠にピッタリのガジェットです。(私もその枠組で購入しました)サイズとしてはこれくらいで扱いやすいです。USBケーブルが専用かつ1mしかないのがちょっとだけネックです。Viveに装着できる機器が出ています。デベロッパーギャラリーもあり、世界の開発者が作成したアプリで遊んだり、自身の作ったものを公開できる環境も存在します。手軽にモーションキャプチャーの世界に入り込める、最初に遊ぶに最適な製品です。end_pointにおける空間座標(3次元)と方向ベクトル(3次元)が取得できます。LTスライドの一部:取得可能な情報また、SDKの提供するAPIでは以下のGestureが定義されています。v3を利用した情報が多く存在します。Pythonであれば以下等PythonでLeapMotionのデータを取得する。v3までのReferenceしか参照することができません。documentationこれは、以下のような内容からきています。v4からLeapCxxという名前でGithub上でライブラリが管理されるようになったそれまでのLeapAPIは非推奨となりLeapCなるAPIが提供されはじめた(LeapCxxの一部)v4は未だbeta版であり、Mac、Linuxはv2の利用を推奨されているLeapCxxではswigで多言語対応される事を前提として高速化され、LeapCSharpやUnityModulesなどのBindingを切り離す事にも成功しています。まとめると「Windowsで利用可能な言語であればLeapCxxを使ったほうが良いが、現状使えない場面の方が多い」という事になります。ConceptsWindowsならv4版、Windowsじゃ無くてもv3版使えば良いじゃんとなる訳ですが、私はWindowsが扱えないのと、v3以前の開発環境は以下のようになっています。一目で分かるかと思いますが古いです。行列や機械学習に突っ込む事も考慮して、せめてMacbookのPython3で動くようにしていきます。Python3での利用を想定しますが、今後Windowsでv4を利用した記事もがんばって公開する予定です。Controllerのインストール以下からControllerをダウンロードします。Motionアイコンが追加されます。Motionが認識しているという形です。Visualizerが付属していますので遊んでみます。Homeなるアプリもインストールされており、そのアプリ経由で公式WebStoreに公開されているアプリで遊んだり、自身のアプリを公開する事が可能です。SDKのv2を以下よりダウンロードします。こちらをswigを用いてPython3系でも利用できるように改修していきます。Developerzipを解凍すると、配下にdmgファイルがあるはずなので、そちらを利用してSDKをインストールします。解凍したファイル群の中には「./LeapSDK/samples/Sample.py」なるサンプルが存在します。2.xベースですので今回は使いません。公式がswigでPython3系に対応する方法を公開してくれています。support.leapmotion.com雑に調べた所、以下2つのリポジトリがpython3に対応してそうに見えますが、中身は上記の記事をスクリプトに落とし込んだだけのようですので、自身で作業した方が良さげです。移動して雑なディレクトリを作ります。Leap.iこの時、以下のようなエラーが出るはずです。1試しにLeap.iの991行目を見ると分かりますが、以下のようにpythonコードと言いつつdefの前にインデントが入ってます。self.z)%}}インデントが合うように、%pythoncodeで検索し、全ての行に存在する前空白2個を消していけば良いです。1115行から1123行目のエラー原因も別箇所のpythoncodeにあります。私はvimで雑にやりました...swigによって「LeapPython.cpp」なるファイルが生成出来ていれば成功です。このファイルを利用しているPythonに紐付ける作業を行います。LeapPython.sopyenv等System以外のPythonを利用している場合は、python3.6mへのpathを、それぞれPythonの/include/pythonNNmディレクトリを指すようにします。systemでworkディレクトリではsystemのpython3.6を利用するようにしています。LeapPython.soとLeap.pyが出力されていれば終わりです。SampleはSwig解説記事の最後にある以下リンクからダウンロードしたものを使います。https://leapmotion-assets-production.s3.amazonaws.com/Jsf1V_R5_kbRNHu3QKdenQ/LeapPython33.zip解凍すると、SamplePython33.pyがあるのでそちらをworkディレクトリに移動します。libLeap.dylib*そのままpython3.6でSamplePython33.pyを実行するとLeap.pyのimportエラーが出ます。syntaxLeap.pyを見てみると何箇所か%だけが記載されている行があるので、Leap.pyからその行を削除します。メソッドに手の情報が流れ込んでくるので、それに応じてGesture判定したり動作を書いてやれば良い感じです。-私の家のIoT環境です。Motionを足してみます。実際にテレビの操作をしているGIFです。GIFに収めている関係上めっちゃ反応がよく見えます(実際は30秒くらいの動画です)。Motionにしてみます。家電の操作これ引っ越し直前の家で実験してるのでちょっと汚いんですが、この端末が玄関にあればサッとジェスチャーキメるだけで全て消せるようになりそうではあります。ここまで書いてなんですが、実際他にも「ターミナルやTweetDeckを起動する」とか「じゃんけんアプリを作ってみる」とかやったものの、あんまりウケそうなものができずコレに落ち着きました...実際やってみる中で、モーションキャプチャーで何するかと考えてもどれも微妙で「妻がキレてる時に声出してオーケーグーグルって言えない時」とかに使えるかも知れないなレベルの感想しか得られませんでした。-普通にデバイスとしては面白いですし、多分VR機器買ったらもっと遊べるんだと思います。-ChainerMNがついに本家Chainerにマージされました。分散深層学習への本気度が伺えます。github.com節目という事で、Dockerを利用して複数ノードでChainerMNするために行った事のメモをTips形式で残しておこうという記事です。私は半年くらい前からこの記事の内容を使っているのでアップデートがあるかもしれません。加えて、最近はkubernetesを使うのが流暢で、PFNさんも公式ブログ書いてるし多分k8sが良いと思います。GPUs(私もk8s挑戦してるけどあんまり上手くいってなくて放置中です...)この記事はk8s使えないけどDocker使えるような分散環境はあるみたいなニッチな需要を満たすかもしれないなあというレベル感の記事です。-記事前提として以下を想定しています。docker、nvidia-docker、cuda周りがインストールされており、1ノード1GPUでChainerのtrainを回せる環境がある複数ノード、複数GPU環境があるまた、私が環境構築した際に読んだ参考文献を示します。kumilog.netひとまず、上の5つに目を通せば動くような気がします。加えて、細かなエラーでStackOverflowやOpenMPIの公式リファレンスを読んでいますがそちらは随時記載します。Learning分散の仕組みについては、秋葉さん、鈴木さんの記事とスライドに任せます。gitバックエンドにOpenMPI、NCCLを利用する想定でインストールを進める。~/.bashrcNCCLなるGPU通信ライブラリのインストールは、以下のリンクからダウンロードする。Agree~」をチェックした後、debファイルを以下からダウンロードしてくる。Docker内にダウンロードしてきたファイルを設置する。入っているのでそっちを使うのがいいと思います。2018年9月19日この後一番陥りやすいのが相互にsshする環境の構築である。複数ノードの場合「ノード間はssh-keyでパスワードなしでssh可」「dockerに入るにはパスワードなしで」を実現しなければならず、通信できない場合にOpenMPIが無反応だったりしてわからんってなるのでちゃんとやる。vaaaaanquish鍵はDockerコンテナ内では生成せず、ノードからマウントしてくる形を取る(結局ノード間自体もsshできないと意味ないので)。/etc/ssh/sshd_configを以下のように変更する(なければ作る)ここで指定するPortは、Dockerからもアクセスするので今後統一して選べる所にする。/dev/null最後にcythonとChanierMNをインストールする。python-mnistdockerコンテナからデタッチする前に、以下のファイルをルート配下辺りに「init.sh」のような名前で置いておく。参考:http://tabisurubiker.hatenadiary.jp/entry/2017/10/02/092952Dockerコマンドでrunする際に実行するプログラムとして、このinit.shを実行、sshサーバを立ち上げて、bashで待機させるようにする。待機しているdockerコンテナに対してOpenMPIがプロセス振ってくれるイメージ。これで多分できたのでcommitしてsaveしてDockerコンテナは終了。-前述したようにノード間はsshできないとダメ。実現する方法はいくつかあるがが、私はアホなので全ノードでssh-keygenして全ノードに配ればええやんと思ってスクリプト書きました。これで作ったkeyをマウントする形を取っている。ssh_generator.pyなる名前で以下のファイルを作って実行するだけ。自身をfabricで読んで各サーバに送る動作をpexpectで実行するアホみたいなスクリプトです。breakこれをローカルPCで実行し、鍵配り作業とする。各サーバの~/.ssh/配下に鍵がそれぞれ登録されます。[GATEWAY_SERVER]」のようにする事で解決可能です。-以下ChinerMNのチュートリアルをpython-mnistで試していく。runするがこの際には以下のようにオプションを付ける。/init.shdockerのポートはssh_configに書いたものを指定する。/etc/hostsはマウントしないとdockerから各ノード間で通信できないので必須。前述の通り、配布したsshもノード上の物をマウントして利用する。環境変数はdocker内でbashrcに書いても良いし、個々で-eで指定しても良いですが今回はinit.shを最後に動かすようにしてるのでここで。あとコレはHorovodなるpackageを使った時に起こりがちな症状ですが/tmpにファイル作る場合もあるので、/tmpも大人しくマウントしておくと良いです。2223」等としてdockerに入る。あると便利なのでこれを用意する。host.txtみたいな雑な名前で良い。cpu=2cpu=2って書いてるけど、これ実際はgpuの数っぽい。(プロセス数という意なのかも)各サーバでport=2223とport=2224をそれぞれGPU割り当てて、Dockerマウントして使いたい!みたいなのはhostfileでは書けない。前述example内のtrain.pyの画像path等をちょっと変更して動かしてみる。train.pydockerのrootで走ってもらう必要があるので--allow-run-as-rootが必須。ib0して指定しないと掴んでくれなくて遅いので注意。npの後ろにGPUと同じ数を書いて実行コマンドを叩くだけ。学習が走ってそうだったら終わりです。-結構つまり所なエラーについて書いておきます。OpenMPI、クソデコレーションされたエラー文吐く時もあれば、うんともすんとも言わないときもあるのでイライラせず対応していきましょう。chainerのサンプルでいうとGPU掴むところで止まってるんだと思います。hostfileの書き方が怪しい場合と環境変数が上手く渡せてない場合が多いです。この場合エラーも出ず止まったままになるのでサッサとctrl+cで抜けて確認。/tmpとかファイルシステムに書き込む物を実行した時にそこマウントしてないと起こりがちエラー文を読めばなんとか。-最初にも書きましたが多分k8sとか色んなツールが出てきてるので、こんなコツコツやる必要もなくなって行くと思います。これ貯めといても仕方ないし書いときました。何かしらの参考になれば幸いです。PyTorchのOpenMPIトレーニングのwrapperとして扱えるhorovodも、以上の方法で使えます。PyTorch.github.comhorovodとかdistTF、pytorch.distributedの知見も徐々にアウトプットしていこうと思っています。-スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。