Capistrano3 でリモート側の環境変数設定されてないなって思ったら
どうでも良いことで 2時間くらい食って悔しかったのと日本語記事がなかったように思えたので書きなぐりました。
症状
Capistrano でデプロイ先で、.bashrc
に書いた環境変数が設定されないまま処理が行われてしまう。
対処
以下の Stackoverflow に答えがありました。
デプロイ先の .bashrc
なりシェルの設定ファイルの先頭に
# If not running interactively, don't do anything
みたいなコメントと、その直後に return
してそうな箇所はありませんか?
Ubuntu など一部のディストリビューションのシェル設定ファイルの先頭には「インタラクティブシェルじゃないならこの後の設定は読み込まない」ような記述がされていることがあるため、その記述をコメントアウトするなりその記述の前に設定を書くなりの対策をとれば良い感じになると思います。
AmazonLinux だとそのような記述がなかったから完全に見逃してた・・・。
flycheck で走らせるプログラムを探すのに direnv に手伝わせる時の注意点
挨拶
またしても前回の投稿から間が空いてしまいましたが、なんと就活が終わっていたり 大学院を中退していたりと色んなことが起こりました。ひと段落したので VJや動画制作やWebデザインなど、もっと取り組んでいきたいと思います。
flycheck が使う文法チェック系プログラム
Emacs でリアルタイムに文法チェックを行うのに便利なのが flycheck
ですが、
flycheck
自体がコードを調査しているのではなく、rubocop
やら eslint
やらを
実行しているのはご存知かと思います。
それらのプログラムはどのように探されているかというと、シェルが $PATH
から
プログラムを探すように、Flycheck は Emacs 上の変数 exec-path
から探しています。
公式ドキュメントにその記述があります。
また、exec-path
の中身は
M-x describe-variable RET exec-path
で見ることができます。
direnv を使ってプロジェクト毎の文法チェックプログラムを探させる
少し話が逸れますが、eslint
だったり rubocop
と言った文法チェック系のプログラムは、
なるべくグローバルにではなくプロジェクトのディレクトリ内に置いときたい派です。
なんとなくなのでちゃんとした理由があるわけではないです。
なので、例えばNode.js 系のプロジェクトなら npm
で eslint
を導入すると、
node_modules/.bin
ディレクトリに実行ファイルが置かれるような状態です。
普通はそのようなディレクトリには $PATH
が通ってませんが、direnv
を使えば
プロジェクトのディレクトリ下に入った時だけ $PATH
にそれらを含めることができます。
.envrc
というテキストファイルをプロジェクトのルートディレクトリに置き
export PATH="node_modules/.bin:$PATH"
と記載してやると良い感じになります。細かい話などは割愛しますので調べてみてください。
そして、普通シェルから立ち上げた Emacs は $PATH
から exec-path
に値が丸写しされますし
(GUI の場合は exec-path-from-shell
というパッケージが要るそうです)、
direnv
管理下のファイルを Emacs で開けば .envrc
に書かれた内容も
もちろん exec-path
に反映されています。
.envrc での $PATH の追加の仕方に注意
ただし、上記の export PATH="bin:$PATH"
のように相対パスで指定すると、実はうまく動かない時が出てきます。
例えばファイル構成が以下の場合を想定します。
- /your/great/project/.envrc
- /your/great/project/node_modules/.bin/eslint
- /your/great/project/code1.js
- /your/great/project/nested/code2.js
.envrc
には
export PATH="node_modules/.bin:$PATH"
が記載されています。
このとき、Emacs で /code1.js
を編集しているときは $PATH
に従って /node_modules/.bin/eslint
を見つけにいきますが、/nested/code2.js
を編集しようとすると /nested/node_modules/.bin/eslint
を探しに行こうとして見つからずに失敗します(多分そうだと思います)。
なのでEmacs の flycheck を利用する場合は $PATH
は必ず絶対パスである必要があります。
PATH_add で楽して絶対パスを指定する
では .envrc
には必ず絶対パスを書く面倒なことをしなくちゃいけないのかというとそうではなく、
PATH_add
という便利機能が備わって要るので、それを使いましょう。
PATH_add node_modules/.bin
これによって $PATH
には /your/great/project/node_modules/.bin
のように
絶対パスで追加されます。
結論
プロジェクトディレクトリ以下に文法チェック系のプログラムがあり、
かつ flycheck
にそれを見つけさせるために direnv
を使う場合は、
PATH_add
を使った方が良いと思います。
告知
5月中に 2件VJやります。
初めて学外でVJやった 武蔵小杉アルファクロス 様でまたVJできるのとても楽しみです。 エイジアも2回目になります。前よりゴリゴリ視力削っていきたいです。
お時間あれば何卒よろしくお願いいたします。
MacBook Pro Late-2016の画面出力について
そろそろ収まってきた頃だと思いますが、MacBook Pro Late-2016、すごいTwitterとかで話題になりましたよね。 そんな TouchBar 付き MBP ですが、直前の記事に書いた通り先月購入し、VJ用に整えている最中です。
ですが、最近 USB-C → HDMI アダプタを使っての画面出力がどうにもうまくいかないので、 原因の特定には至ってませんが気になる英語の記事を見かけたので、軽くまとめます。
画面出力の不具合
僕が使っているのはこの ELECOM の製品なんですが、初めの頃は問題なかったのですが、 現在以下のような現象が起きています。
- プロジェクターに直接 HDMI を接続しても、Mac 側はプロジェクターを認識しているものの、プロジェクター側は「映像が来ていない」と思っている。
- HDMIを Blackmagic design Intensity Shuttle (HDMIキャプチャ) に接続させると、キャプチャ側で映像のサイズやフレームレートは認識できるのに青い画面しか見れない。
- 分かる人には分かる魔法 (Kanaan の HDMI スプリッター) を経由するとなぜかキャプチャ側で映像が映るようになる。
まさか常時 HDMI 出力に HDCP かかるようになりましたとか、そんなことはないですよね・・・。ていうかプロジェクター HDCP 対応してるでしょ(してた)。 そもそも、初めの頃普通に表示できていた理由もわかりません。
「Late-2016で USB-C to HDMI はやめとけ」という英語の記事
情報を探していましたが、直接の解決策となる情報は見つからず。 ただ、
こちらの記事に興味深い情報が書いてありました。要点をまとめると、
- サードパーティーの USB-C to HDMI はまともに動かない (ただし Mac はディスプレイを認識できている)
- そもそも Apple 純正の USB-C to HDMI すら動かない
- USB-C to DisplayPort はしっかり動くので、今は DisplayPort の方をつかうべき
ただ、この方は Radeon 入り 15インチ MacBook Pro なので、僕の13インチ内蔵フラフィックスとは状況が違うかもしれません。
結論
VJするには非常に面倒なマシン買っちゃったかも・・・。 原因がわからないのが辛いですが、前述の通りなぜか魔法を使うと映るので、しばらくはそれで対処しようと思います。
追記
この記事を書いた直後にこんな追記するものアレなのですが、以下の構成でふっつーに出力できました。まじなんなん・・・。
MacBook Pro → Elecom の USB-C to HDMI → HDMI to DVI ケーブル → BenQのディスプレイ (GL2250)
今後のVJ機器の構成を妄想
賀正
2017年
またしても前回の記事から時間が経ってしまい、気づいたら年が変わりました。 明けましておめでとうございます。 今後とも何卒よろしくお願いいたします。
大学院の方は相変わらずの進捗の悪さに定評がありますが、そろそろ覆したい気持ちです。
そしてVJですが、環境とか手元にあるリソースが大きく変わったので、 自分のやり方を維持しつつ構成をアップグレードしたいなという妄想をしたかっただけです。
ちなみにこの記事を書こうと思った発端は以下の通りです。
プロジェクター ← Resolume Arena (ThinkPad, Intensity Shuttle) ← V-1HD ← VDMX (MacBook) + VirtualDJ (ポンコツPC)
— Yadex205 (@yadex205_vj) 2017年1月5日
っていう頭悪い構成思いついてしまった
構成の妄想
実は1月2日にVJ新年会というとても楽しい会があって、その時にVDMXを買ってしまったのですが、 パッと見自分のやり方に実は合ってる気がしたので、極めようと思っています。
その上で、今まで VVVV + V-4 でやってきたのに近いプレイを MacBook Pro + VDMX でやろうと考えています。
ThinkPad の方では VirtualDJ をメインで動かそうと思います。 そしてVDMXとVirtualDJの出力をミキシングし、最終的なエフェクトをかけ、プロジェクションマッピングするソフトとして Resolume Arena は使っていきたいです。
ちなみに、MacBook Proの方でVDMXとArenaを両方起動したところVDMXがかなり怪しくなったので、 できることなら同時起動させたくないなと思いました。
自分のVJ環境の変化
一応参考程度に、覚えている範囲で。
大学サークルでVJ (2014年9月ごろ~)
軽音楽系のサークルで、先輩がDJしている隣でVJをはじめました。
PCは ThinkPad E430、完璧にエントリーモデルなノートパソコンです。 ソフトは Resolume Avenue をしばらく体験版状態で使い、 途中からちゃんと購入して使っていました。
コントローラーも途中からド定番 nanoKontroller2 と nanoPad2 を買って、今でも使っています。
学外でVJ活動開始当初 (2015年10月ごろ~)
ライセンスBANされた Resolume Avenue を1回だけ使い、 そのあとは VVVV を使ってでっち上げたVJソフトもどきで何とかしのいでいました。
結局ここから1年間くらい VVVV だけでVJしていました。(何回かElectronで作ったソフトも使いました)
なお、コントローラーも AKAI APC mini を新しく買いました。
V-4 入手 (2016年4月ごろ)
諸事情あって、夢の Roland V-4 を入手しました。
例のVJソフトもどきはエフェクトをかけられるように実装していなかったので、 V-4を使ってチカチカするようなVJができるようになってかなり楽しくなりました。
自分がプロフィールに書いてる「目に悪いVJをしています」感じのスタイルはこのあたりで出来てきたのだと思います。
Pioneer DDJ-RB, GoVJ 購入 (2016年8月ごろ)
ニコル君と話していたら気づいたら買っていました。
同時に、VirtualDJ と GrandVJ を組み合わせたようなソフトを作ってみたいと思うようになって、 Electron(Node.js)でVJソフトもどきを作り、DDJ-RB, nanoKontroller2に対応させました。
ちなみにソフトの完成度はファッキンと言ったレベルです。
また、GoVJという iOS 向けVJアプリを購入し、 ThinkPadで動いてるVJソフトが死んだときの応急処置として用意するようになりました。
Resolume Arena, VirtualDJ 購入 (2016年11月)
ブラックフライデーに合わせて、再び Resolume 製品を買ってしまいました、しかも Arena です。 買ってしまったというか、某VJさんにそそのかされて買いました。
また、それとは別に VirtualDJ を購入し、いわゆるアニソンVJのようなスタイルもできる準備はしました。
VVVVでやってた頃とは違ってスタイルがある程度制限されるようにはなりましたが、 やはり有償ソフトならではの安定さと、特に Resolume のエフェクトの豊富さは使っていて気持ちいいです。
MacBook Pro 購入 (2016年12月)
念願のMacBook Pro を購入しました。 ThinkPadを使っていた時よりは確実に性能が良くなりましたし、Syphonが使える強みもあります。
最後に
VJ新年会本当に面白くて、「V-4EXのなる木を育てたい」とか「粉チーズを肥料にしたらV-1HDが成る」みたいな話をしていました。
— Yadex205 (@yadex205_vj) 2017年1月3日
本年も、何卒よろしくお願いいたします。V-1HD欲しい。
Flycheck の In file included from 警告を消す
備忘録です。
謎警告
最近 emacs で Node.js のネイティブモジュールを書いてみたり、
Qtアプリケーションを作ろうと頑張っているのですが、
#include
文のところで Flycheck に こんな警告をよく吐かれていました。
In file included from In file included from In file included from In include /usr/local/opt/qt5/include/QtWidgets/QApplication
・・・そもそもこれエラーなのか何なのか。
原因
どうやら flycheck のバグだとか何だとか言われていて(某所だとパースエラーだとか)、 flycheck の警告文からでは何が問題なのかがわかりませんでした。 なので、flycheckがどのようなコマンドを叩いて、どのような結果を得ているのかを どうにか見れないか調べてみました。
色々調べてみたところ、
に書いてある通り、C-c ! C-c
を叩くことで、実際に実行されているコマンドと
実行結果(解析結果)の全文を見ることができます。
結果
で、やってみたところ
1*- mode: compilation; default-directory: "(省略)" -*- 2Compilation started at Tue Nov 8 15:04:30 3 4clang -fsyntax-only -fno-color-diagnostics -fno-caret-diagnostics -fno-diagnostics-show-option -iquote (省略) -Wall -Wextra -I (省略) 5In file included from <stdin>:1: 6In file included from /usr/local/opt/qt5/include/QtWidgets/QApplication:1: 7In file included from /usr/local/opt/qt5/include/QtWidgets/qapplication.h:43: 8In file included from /usr/local/opt/qt5/include/QtCore/qcoreapplication.h:43: 9/usr/local/opt/qt5/include/QtCore/qglobal.h:1133:23: warning: rvalue references are a C++11 extension 10In file included from <stdin>:1: 11In file included from /usr/local/opt/qt5/include/QtWidgets/QApplication:1: 12In file included from /usr/local/opt/qt5/include/QtWidgets/qapplication.h:43: 13In file included from /usr/local/opt/qt5/include/QtCore/qcoreapplication.h:43: 14In file included from /usr/local/opt/qt5/include/QtCore/qglobal.h:1145: 15In file included from /usr/local/opt/qt5/include/QtCore/qatomic.h:46: 16/usr/local/opt/qt5/include/QtCore/qbasicatomic.h:61:4: error: "Qt requires C++11 support" 17/usr/local/opt/qt5/include/QtCore/qbasicatomic.h:90:13: error: unknown type name 'QAtomicOps' 18/usr/local/opt/qt5/include/QtCore/qbasicatomic.h:90:23: error: expected member name or ';' after declaration specifiers 19/usr/local/opt/qt5/include/QtCore/qbasicatomic.h:93:23: error: use of undeclared identifier 'QAtomicOpsSupport' 20/usr/local/opt/qt5/include/QtCore/qbasicatomic.h:93:53: error: no member named 'IsSupported' in the global namespace 21/usr/local/opt/qt5/include/QtCore/qglobal.h:761:63: note: expanded from macro 'Q_STATIC_ASSERT_X' 22/usr/local/opt/qt5/include/QtCore/qglobal.h:756:110: note: expanded from macro 'Q_STATIC_ASSERT' (以下略)
なるほど、原因はC++11
絡みのところにあったらしいです。
何が原因かというと、C++11
に対応していない状態で flycheck を動かしていたということでした。
上記によると、emacs の設定ファイルに
(add-hook 'c++-mode-hook (lambda () (setq flycheck-gcc-language-standard "c++11")))
を追加することで、flycheckが C++11
に対応してくれるようです。
私の環境でもこれで治りました。
結論
Flycheck の謎警告に困ったら、 C-c ! C-c
を見てみましょう。
#アジアニ に出演しました! & JavaScriptでVJソフト自作しました
台風3つが同時に日本に攻めてきてますが、 昨日、渋谷clubasiaで3フロア同時にアニソンがかかる #アジアニ というパーティーがあり、 メインフロアのVJとして参加させていただきました!!
#アジアニ
シンガポールからのゲスト、ほとんどDJブースにいない方、お笑い芸人、そしてアニソン歌手まで、 多彩な方々がDJ、ライブをされて会場が死ぬほど盛り上がってる中VJさせていただけたのは本当に光栄と言いますか。。。
たくさんのお客さんを前に少し高いブースでVJできたことが本当にたのしかったです。
自分のVJですが、結局モーショングラフィックス系しか流さず、 OP等の映像は一緒にメインフロアでVJされたあっちんさんやちゃーさんに押し付ける形になってしまいました。 が、あくまでこれが自分の得意分野であるし、結果として得意分野を分担し合った連携VJができて良かったです。(個人的にはですが。。)
一点だけ、HOT LIMITが流れた時に
これを出しました、ありがとうデリケア。なお、お客さんの反応は見ることができず。。
結果として、今までやってきたVJの中で一番楽しかったし満足することができました。 出演されたDJ、VJさん、asiaのスタッフさん、#アジアニ の主催者さん、お越しいただいたお客さん、本当にありがとうございました!
自作VJソフト
以前より金欠を理由にVJソフトは買わずに作ってきましたが、今回も例に漏れず自作VJソフトを実戦投入しました。 ただし、以前のようにvvvvでパッチングするのではなく、JavaScriptでゴリゴリコードを書きました。
JSと言っても、要するにNode.js + Electronなのですが、本当にJSしか書いてないです(強いて言えばWebGLのシェーダーが別言語なくらい)。 なおGitリポジトリ https://github.com/yadex205/berkut で公開しています。随時更新していきます。
ということで、まだまだ未完成なのですが、今回VJソフトを作るのに使った主な技術などを紹介してみます。
WebChimera
Node.jsにlibvlcをバインディングしたnpmパッケージ。 つまりNode.js上でVLCメディアプレーヤーが再生できるメディアを再生することができる魔法のようなライブラリです。 再生と言ってもピンとこないかもしれませんが、要するに1フレームのピクセルごとの色情報を配列として取得することができます。
[13,34,62,35,74,215 ...]
みたいな感じです(どんな感じだ)。
なお実際に使う場合は、すでにビルド済みの wcjs-prebuilt
パッケージを使うのが無難です。
また、Electronで使う場合には(こちらがメインですが)、
wcjs-renderer
パッケージを使うことで HTMLのCanvas
に動画を描画することができます。
WebGL
最新のウェブブラウザでは、Canvas
タグ上でその場で3Dモデルをレンダーすることができちゃうんですが、それを実現するのがWebGL
という仕組みです。OpenGLをそのままブラウザに移植したイメージ、かもです。
前述のwcjs-renderer
はWebGLを使って動画のフレームを描画しています。
今回の自作VJソフトはwcjs-renderer
を改造し、複数の動画のフレームを任意の合成方法(加算、乗算など)で重ねられるようにしました。
node-ffi
だそうです。今回はこれのNode.js版である node-ffi
を使って、Windows限定ですが kernel32
の関数を呼び出しています。
VJソフトってコントローラーや動画リストとかが表示されているウィンドウと、ミキシングされた動画を出力するウィンドウが2つ普通ありますよね。 もちろん今回もそのようにしたのですが、Electronではウィンドウ同士は別プロセスになります。 つまり、コントローラーウィンドウの方でミキシングしたフレームを出力ウィンドウに渡そうとする場合、プロセス間通信が必要になり、フレーム情報がシリアライズされるのですが、これがとても無駄に重たい処理になります。
願わくば、コントローラーウィンドウが保持しているフレーム情報が格納されているメモリのアドレス(ポインタ)を出力ウィンドウに教えることが出来れば。でも原則、プロセスごとに割り当てられるメモリのアドレスは仮装的なもので、他のプロセスが保持するポインタを直接見ることはできません。
ところが、WindowsのAPIでReadProcessMemory
という関数があり、他のプロセスのポインタが示す内容を見ることができます。これを呼び出すためにnode-ffi
が必要でした。
他にもNeDBというドキュメント型データベースを使ってサムネイルの管理をしたり、ビューとデータのバインディングにVue.jsを使ったり、UIにはBootstrapを使ったり、さらにメディアファイルのインクリメンタルサーチを便利にするためにJS版migemoを使ったり、、色々使ってます。
眠たくなったのでこの辺にします、おやすみなさい。。。
NTEmacs 24.5 で Cask を使えるようにする
最近趣味のプログラミングがそこまで捗ってないというか環境構築楽しいで止まってる気がする。。。
で、その環境構築で、Windowsのプログラミング環境どうしようって結局Emacsを入れようとしていて沼にはまった話です。 備忘録程度なので雑に書いています。
Cask
Cask
だけで調べるとHomebrew
の方のCaskがヒットしちゃったりするのですが、そんなことはどうでも良く。
Cask
は、emacs向けの依存マネージャー(?)といった機能を担当します。Node.jsのnpm
だったり、
Rubyの'bundle'のような感じです。
ここでCask
の使用方法ですが、~/.emacs.d/
以下にCask
という名前のファイルを生成し、
そこに自分のEmacs環境で使いたいパッケージを書き、そのディレクトリで
$ cask install
することで、一連のパッケージを一斉にダウンロードすることができます。
あとはinit.el
でCask関係のEmacs lisp達をロードすることで、ダウンロードしたパッケージが使えるようになります。
なお、CaskにはPython 2.7
が必要です。3.xには対応してないらしいので注意してください。
Caskがパッケージを拾いに行けない
さて本題ですが、これは今のところWindowsだけに起こっているのですが、GNU公式から拾ってきたEmacs (24.5)だと
Caskの通信が成功しません。Windows版Emacs (NTEmacs)だけSSL/TLS通信に必要な GnuTls
というライブラリが
インクルードされずにビルドされているらしいです。
と言うことでいろいろ検索した結果、以下のページに方法が書いてありました。
how to enable GnuTLS for Emacs 24 on Windows
要約すると、「Win向けにGnuTlsをインクルードしたDLLがここにあるから拾って、 Emacsのディレクトリにぶちこんで」との事でした。
一応自分の環境ではこれでcaskが正常に動作しています。