最近、vimshellのtexeをテストするためにCygwin環境を整えているんですが、Cygwinでcursesアプリケーションをコンパイルするときに少しはまったのでここにメモしておきます。
Cygwinにはlibtermcap.aは存在しません。-ltermcapすると失敗するので、-ltisと変更します。それでもエラーが出るときは、cursesライブラリをリンクしていない可能性があります。-lcursesをMakefileに付け加えましょう。
Cygwinのcurses.hは/usr/include/ncursesという変な場所にあります。「curses.hが見つからない」というエラーになるときは、gccの引数に-I/usr/include/ncursesを加えてみましょう。
これでようやくfdcloneとslをコンパイルできました。texeがこれらのアプリケーションを実行できるようにしないといけません。
2010年7月24日土曜日
2010年7月23日金曜日
vimshellの新機能 texeについて
以前のエントリ後、h1mesukeさんはConqueに乗り換えたようでした。
その後h1mesukeさんは、Conqueの設定記事を書いてくれたようです。
Conqueはまだまだマイナーなプラグインで、情報が少ないので大変に参考になります。
上記の記事のトラックバック代わりに、vimshellの新機能であるtexeについて解説をします。
texeとはConqueと同様に、Vimを端末エミュレータとして使うというコマンドです。
vimshellバッファ上で、
のようにして起動しますが、vimshellバッファが欲しくないときには:VimShellTerminal zshとしても起動することができます。
texeと似たvimshellのコマンドとして、iexeというものがあります。こちらは対話的にバッファを生成し通信するのですが、texeとは細かい動作が異なります。
iexeはneocomplcacheと連携して補完ができたり、ヒストリを参照して実行できたりと、Vimの機能をほぼフルに使うことができます。しかし、texeの場合はバッファに対するすべての入力が奪われてしまうので、neocomplcacheは使えません。補完は起動するソフトの機能に依存します。そのあたりはConqueも同じです。加えてtexeはエスケープシーケンスの処理が重いので、私はインタプリタを起動するときにはiexeを使うことをおすすめします。ただし、zshの右プロンプトはiexeでは動作しません。どうしても右プロンプトを使いたいなら、texeを使用する必要があります。
iexeの方が優れているというのに、わざわざtexeを作った理由は、フル機能の端末が必要なニーズは確実に存在するためです。例えば、gdbtuiというものがあります。これは端末上でグラフィカルにデバッグを行うことができるソフトです。こういうものはiexe上では実行ができません。VimではEmacsのようなGDBとの連携がしづらいのですが、gdbtuiのようなソフトを使えば模倣できると考えました。端末エミュレータの機能を実装すれば、muttやw3mといったメールやWebブラウズもVimだけで実行できるということもあります。端末エミュレータの実装はそれなりに大変ですが、端末機能を使うすべてのプログラムとVimが連携できることを考えれば、実装する価値はあります。
・vimshellと連携できる
・Conqueの対応していないエスケープシーケンスに対応
・Windows対応
・+pythonが必要ない
・洗練されたハイライト
・プロセスの後始末
・キーマッピングを自由に設定が可能
Conqueの対応していないエスケープシーケンスとは、例えばタイトルやカーソル形状の変更のエスケープシーケンスや、Line Drawing Character setのエミュレーションです。Conqueのハイライト設定は、実はvimshellのものを流用しています。が、vimshellのハイライトはその後独自に進化したので、当然texeの方が優れています。Windowsに対応するには、Cygwinのインストールとfakecygptyが必要です。動作もかなり重く、zshの自動補完を使うにはかなり無理があります。zshを普通に使う分には問題がありません。
・エスケープシーケンスの実装はまだ不完全
・Conqueより重い？
まだ開発したばかりなので、動作速度やエスケープシーケンスの対応については、なかなか厳しかったりします。ようやく一通りの機能を実装することはできたので、今後改善予定です。
texeはfiletypeをterm-コマンド名として設定するので、
autocmd term-*で設定します。例えばこのように：
vimshell#term_mappings#send_key()という関数は、起動しているプログラムに送るキーシーケンスを制御しています。複数のキーシーケンスを送る場合はvimshell#term_mappings#send_keys()を使います。
ヘルパ関数が用意されているので、キーマッピングも自由自在なのです。
設定さえしてやればスティッキーシフトに対応することもできます。この柔軟性は大きな魅力です。
texeには、まだVT100レベルの端末機能しか実装されていませんが、いずれは$TERMがxterm-256colorになる予定です。今後に期待してください。
その後h1mesukeさんは、Conqueの設定記事を書いてくれたようです。
Conqueはまだまだマイナーなプラグインで、情報が少ないので大変に参考になります。
上記の記事のトラックバック代わりに、vimshellの新機能であるtexeについて解説をします。
texeとはConqueと同様に、Vimを端末エミュレータとして使うというコマンドです。
vimshellバッファ上で、
texe zsh
のようにして起動しますが、vimshellバッファが欲しくないときには:VimShellTerminal zshとしても起動することができます。
texeと似たvimshellのコマンドとして、iexeというものがあります。こちらは対話的にバッファを生成し通信するのですが、texeとは細かい動作が異なります。
iexeはneocomplcacheと連携して補完ができたり、ヒストリを参照して実行できたりと、Vimの機能をほぼフルに使うことができます。しかし、texeの場合はバッファに対するすべての入力が奪われてしまうので、neocomplcacheは使えません。補完は起動するソフトの機能に依存します。そのあたりはConqueも同じです。加えてtexeはエスケープシーケンスの処理が重いので、私はインタプリタを起動するときにはiexeを使うことをおすすめします。ただし、zshの右プロンプトはiexeでは動作しません。どうしても右プロンプトを使いたいなら、texeを使用する必要があります。
iexeの方が優れているというのに、わざわざtexeを作った理由は、フル機能の端末が必要なニーズは確実に存在するためです。例えば、gdbtuiというものがあります。これは端末上でグラフィカルにデバッグを行うことができるソフトです。こういうものはiexe上では実行ができません。VimではEmacsのようなGDBとの連携がしづらいのですが、gdbtuiのようなソフトを使えば模倣できると考えました。端末エミュレータの機能を実装すれば、muttやw3mといったメールやWebブラウズもVimだけで実行できるということもあります。端末エミュレータの実装はそれなりに大変ですが、端末機能を使うすべてのプログラムとVimが連携できることを考えれば、実装する価値はあります。
Conqueとの比較
texeの良いところ
・vimshellと連携できる
・Conqueの対応していないエスケープシーケンスに対応
・Windows対応
・+pythonが必要ない
・洗練されたハイライト
・プロセスの後始末
・キーマッピングを自由に設定が可能
Conqueの対応していないエスケープシーケンスとは、例えばタイトルやカーソル形状の変更のエスケープシーケンスや、Line Drawing Character setのエミュレーションです。Conqueのハイライト設定は、実はvimshellのものを流用しています。が、vimshellのハイライトはその後独自に進化したので、当然texeの方が優れています。Windowsに対応するには、Cygwinのインストールとfakecygptyが必要です。動作もかなり重く、zshの自動補完を使うにはかなり無理があります。zshを普通に使う分には問題がありません。
texeの悪いところ
・エスケープシーケンスの実装はまだ不完全
・Conqueより重い？
まだ開発したばかりなので、動作速度やエスケープシーケンスの対応については、なかなか厳しかったりします。ようやく一通りの機能を実装することはできたので、今後改善予定です。
設定について
texeはfiletypeをterm-コマンド名として設定するので、
autocmd term-*で設定します。例えばこのように：
autocmd MyAutoCmd FileType term-* call s:terminal_settings()
function! s:terminal_settings()
inoremap <buffer><expr> <Plug>(vimshell_term_send_semicolon) vimshell#term_mappings#send_key(';')
inoremap <buffer><expr> j<Space> vimshell#term_mappings#send_key('j')
"inoremap <silent><buffer><expr> <Up> vimshell#term_mappings#send_keys("\<ESC>[A")
" Sticky key.
imap <buffer><expr> ; <SID>texe_sticky_func()
" Escape key.
iunmap <buffer> <ESC><ESC>
imap <buffer> <ESC> <Plug>(vimshell_term_send_escape)
endfunction
vimshell#term_mappings#send_key()という関数は、起動しているプログラムに送るキーシーケンスを制御しています。複数のキーシーケンスを送る場合はvimshell#term_mappings#send_keys()を使います。
ヘルパ関数が用意されているので、キーマッピングも自由自在なのです。
設定さえしてやればスティッキーシフトに対応することもできます。この柔軟性は大きな魅力です。
おわりに
texeには、まだVT100レベルの端末機能しか実装されていませんが、いずれは$TERMがxterm-256colorになる予定です。今後に期待してください。
2010年7月14日水曜日
neocomplcache Ver.5.1開発中
また期間が空いてしまいました……。Vim Hacksもあるので、ブログを続けるのはなかなか難しいですね。
まぁ、こちらにはこちらの良さがあるので、ブログをやめることは多分やりません。
しかしこんな濃いブログを見てる人なんているのだろうか。
本題です。私はvimshellの開発やeskkの修正で忙しかったりするのですが、neocomplcacheのバージョンアップも密かに進めています。それがneocomplcache Ver.5.1です。
http://github.com/Shougo/neocomplcache/tree/master
見ための変化はあまりないですが、プラグインの仕様がかなり変化しています。
ファイル名補完
vimshellとの連携
オムニ補完
Vimオムニ補完
レジスタ補完
クイックマッチ
neocomplcacheでは、「あまりユーザーがプラグインを書いてくれない」ということが大きな障害となっていました。
neocomplcache Ver.5.1はプラグインが書き易くなっているので、今度こそプラグイン製作者が増えるのではないかと期待しています。あとはドキュメントさえあれば完璧です。このあたりはVim Hacksでフォローする予定です。
まぁ、こちらにはこちらの良さがあるので、ブログをやめることは多分やりません。
しかしこんな濃いブログを見てる人なんているのだろうか。
本題です。私はvimshellの開発やeskkの修正で忙しかったりするのですが、neocomplcacheのバージョンアップも密かに進めています。それがneocomplcache Ver.5.1です。
http://github.com/Shougo/neocomplcache/tree/master
見ための変化はあまりないですが、プラグインの仕様がかなり変化しています。
ファイル名補完
vimshellとの連携
オムニ補完
Vimオムニ補完
レジスタ補完
クイックマッチ
neocomplcacheでは、「あまりユーザーがプラグインを書いてくれない」ということが大きな障害となっていました。
neocomplcache Ver.5.1はプラグインが書き易くなっているので、今度こそプラグイン製作者が増えるのではないかと期待しています。あとはドキュメントさえあれば完璧です。このあたりはVim Hacksでフォローする予定です。
2010年6月15日火曜日
Re: :shell vs vimshell
前回より、だいぶブログの更新があいてしまいました。なかなか続けるというのは難しいですね。まぁ、それはいいとして本題です。
h1mesukeさんのvimshellの感想として、「:shell vs vimshell」
http://d.hatena.ne.jp/h1mesuke/20100615/p1というページが公開されていました。本来ならばコメントとしてそちらのページに書き込む予定でしたが、長くなりそうなので、ブログでコメントを述べておきたいと思います。
vimshellはもともと、Windowsの貧弱なコマンドライン環境を何とかするために開発されました。その後、プラグインとの連携性や、インタプリタ実行などの機能が付加され、現在のような姿になります。Linux上で、しかも端末上で使用するなら、それらの利点はあまりないかもしれません。
それで満足できるなら、vimshellを使う意味はあまりないでしょう。vimshellはVimから出たくない、Vim上ですべてのコマンド実行を解決させたい人のためのものですから。
はい。シェルの移行コストというのは高くて、それが新しいシェルがなかなか生まれない原因ではないかと私は考えています。なぜvimshellはzshの構文が使えないのかというと、vimshellはzshやbash, shとの互換性よりも、Vim Scriptとの親和性を考えて設計しているためです。加えて、私自身がシェルスクリプトの難解な構文や落とし穴が好きでない、というせいもあります。ただ、パイプはいずれ使えるようにします。zshの高度なリダイレクションもいずれは実装します。
確かに設定の二重化は避けられないです。ただ、「これを許容できない」とありますが、本当にそうでしょうか。例えば、zshやbash(readline)でviキーバインドを愛用している人がいますが、これはzshとVimの設定の二重化です。あまりにVimに慣れすぎると、外の世界でもVimの設定を使いたくなります。「zshにVimのビジュアルモードを実装した」人がいますが、これこそ典型例だと思います。zsh上でVimの設定を模倣するくらいなら、Vim上でzshの設定を模倣してもいいと思いますが、どうでしょうか。
一元化することは大事だと思います。私は一元化したことによって、zshの代わりにvimshellが標準シェルとなってしまいましたが。「Vimの設定 >>越えられない壁 zshの設定 >> screenの設定」なので、すべてがVimに吸収されてしまうのも容易に想像にできます。
まぁ、その方が幸せなのかもしれません。vimshellをありがたがるということは、もうVim病にかかっているということですから……。
指摘のあったとおり、vimshellはまだ完全ではありません。いつかはほぼzshを置き換えられるようにと考えて開発をしていますが、道はかなり険しいです。もし機会がありましたらまたvimshellを試してもらえるとありがたいです。きっとその頃には欠点も解消しているでしょう。
追記：「mattnさんのコメント」
そんなあなたも大丈夫。bg tail -f もしくはiexe tail -fが使えます。
h1mesukeさんのvimshellの感想として、「:shell vs vimshell」
http://d.hatena.ne.jp/h1mesuke/20100615/p1というページが公開されていました。本来ならばコメントとしてそちらのページに書き込む予定でしたが、長くなりそうなので、ブログでコメントを述べておきたいと思います。
この辺りのことは、Linux上でかつ端末内でのみ vim を使う自分にはそもそも問題になりません。:shell で起ち上がるのは zsh であり、強力です。*1
vimshellはもともと、Windowsの貧弱なコマンドライン環境を何とかするために開発されました。その後、プラグインとの連携性や、インタプリタ実行などの機能が付加され、現在のような姿になります。Linux上で、しかも端末上で使用するなら、それらの利点はあまりないかもしれません。
>実行している間はVimが止まってしまいます。
あまり格好良くはありませんが、別タブで（；^ω^）
>コマンドの出力もバッファにとれない
あまり格好良くはありませんが、xsel とかマウスによるコピペで。
それで満足できるなら、vimshellを使う意味はあまりないでしょう。vimshellはVimから出たくない、Vim上ですべてのコマンド実行を解決させたい人のためのものですから。
vimshell を使ってみてまず出鼻を挫かれるのは、.zshrc で定義している alias やシェル関数が効かないこと。l みたいなものから始まって、その数はかなりの量にのぼるので、それらを vimshell 上でも使えるようにするには、と考えるとちょっと気が遠くなりました。
はい。シェルの移行コストというのは高くて、それが新しいシェルがなかなか生まれない原因ではないかと私は考えています。なぜvimshellはzshの構文が使えないのかというと、vimshellはzshやbash, shとの互換性よりも、Vim Scriptとの親和性を考えて設計しているためです。加えて、私自身がシェルスクリプトの難解な構文や落とし穴が好きでない、というせいもあります。ただ、パイプはいずれ使えるようにします。zshの高度なリダイレクションもいずれは実装します。
使えるようにできたところで、２つのシェルの設定を抱えることになり、管理が二重化することは明白で、これは許容できないところです。
確かに設定の二重化は避けられないです。ただ、「これを許容できない」とありますが、本当にそうでしょうか。例えば、zshやbash(readline)でviキーバインドを愛用している人がいますが、これはzshとVimの設定の二重化です。あまりにVimに慣れすぎると、外の世界でもVimの設定を使いたくなります。「zshにVimのビジュアルモードを実装した」人がいますが、これこそ典型例だと思います。zsh上でVimの設定を模倣するくらいなら、Vim上でzshの設定を模倣してもいいと思いますが、どうでしょうか。
物事を単純にしたいのならシェルは一元化すべきで、:shell から普段使っているシェルを呼び出すのがラク。DRY原則重要。
一元化することは大事だと思います。私は一元化したことによって、zshの代わりにvimshellが標準シェルとなってしまいましたが。「Vimの設定 >>越えられない壁 zshの設定 >> screenの設定」なので、すべてがVimに吸収されてしまうのも容易に想像にできます。
とすると、自分はそもそも vimshell の恩恵を受けにくいところにいる、ということかも知れません。というか、多分そう。もしくは vimmerレベルが低いか（；^ω^）
まぁ、その方が幸せなのかもしれません。vimshellをありがたがるということは、もうVim病にかかっているということですから……。
指摘のあったとおり、vimshellはまだ完全ではありません。いつかはほぼzshを置き換えられるようにと考えて開発をしていますが、道はかなり険しいです。もし機会がありましたらまたvimshellを試してもらえるとありがたいです。きっとその頃には欠点も解消しているでしょう。
追記：「mattnさんのコメント」
mattn 個人的にはtailが動かないとエディタ内のシェルってそれほど意味を成さないと思ってる。
そんなあなたも大丈夫。bg tail -f もしくはiexe tail -fが使えます。
2010年5月9日日曜日
第四回 カーネル／VM探検隊
参加・LTしてきたのでまとめを書いておきます。
会場に到着したのは12:20頃。割とはやめ。会場はなかなか広かった。
１．kozosさんの発表
組み込みOSを作ったよ！ という話。今度本が出るみたい。
ちょっと興味ある。
２．yojiroさんの発表
OpenBSDのYUREXドライバはどのように解析したのか、おまけとして
「かわいくない」温度センサの解析秘話つき。
この人の発表は面白すぎました。あまたの名言が飛び出す。
「ドライバの気持ちは分かってた」
３時間でデバイスドライバをハック、すごい！
３．kobaさんの発表
組み込みの人らしいです。クロスコンパイル環境をqemuでごにょごにょしてたという話。
４．honmaさんの発表
ついにYUREXの話キター！
今日のハイライト。貧乏揺すりを科学したYUREX。CMが放送されたこともあるらしい。
一生のうちに貧乏揺すりをする回数をまじめに計算＝＞10桁あれば大丈夫だろう。
検証する動画がシュール。お値段は￥12,600（これでも採算ギリギリ）でしたが、
時代を先取りしすぎて（売れなかったので）￥980に値下げ。まさかの92% OFF！
YUREXのサイトがある。まじめに解説しすぎてて吹く。
デバイスドライバはPython製。Windows 7専用ドライバもある。
秘密の在庫がまさかのワンコイン。即売会は争奪戦でした。
何が彼らを熱くさせたのか……。どうしてこうなった！
休憩を挟み、ここからLTになった。
５．go_vmさんの発表
Plan9で動くYUREXのドライバを書いた！という話。
各OSでYUREXのドライバを書くというのが前回のカーネル／VM探検隊後にはやったらしい。
3月終わりのHacathonにて実装。Plan9のUSBドライバはユーザー空間で動作する。
USBデバイスはファイルとして見える。おお、確かに動いている。
時間がないので続きはWebで。github上で公開しているらしい。
６．noztosさんの発表
NetBSDとYUREXの話。5秒に一回ポーリング。Twitterに投稿できるらしい。
７．syuu1228さんの発表
OpenBSDにsgi SMPを実装。Theoさん直々にマシンを買わされた。
共有メモリアーキテクチャでクラスタを構成できる、ごく普通のHPC。
いわゆる変形合体ロボ。プロセッサローカルな空間があり、ローカルなIOとリモートのIOがある。
OpenBSDが持っているのは全部で四台らしいので、「もう一台送られてくるかも？」と言っていた。
質問にて、「sgi SMPをどこに送ればいいんですか？」に吹く。
８．xylaoさんの発表
UNIX/32Vをエミュレータで動かす。マイクロコードを修正した話。
すごく……CPUです。いや私は大好物なんですけど。
VAXのマイクロコードを解説。あれ、これは何の勉強会だったっけ。
９．masami256さんの発表
デバイスドライバを作ろう！とInterface別冊で勉強していた。
「使い方を説明するので誰か実装して」に吹く。
１０．siritoriさんの発表
高校生の発表。H8SXマイコン上で動作するOSを作ろうという話。
スライドでまさかのハプニング。卒業研究らしい。
そこにH8SXマイコンがあったから。
OSはまだ書けてないようだ。逆質問を受け付けていた。
１１．oza_x86さんの発表
会場に来れなかったらしく、Skypeで参加。
Dynamick tikcsはお仕事があるときだけタイマー割り込み。
利点は消費電力の低減とゲストOS時にCPU使用率の低下。
社会人になるというイベントがあったので4月はあまり実装できず。26日からやる。
27日にパッチを投げる。実際にテストしてもらえることになり、ToDoが増えた。
FreeBSD 7.Xで試せるようになった。パッチとソースはgithub上にあるらしい。
今後はFreeBSD 8.1めがけてマージしたいとのこと。
１２．yumano・murahueさんの発表
韓国のハッキングコンテストに参加。ハッキングコンテストの話はそこそこに、韓国話。
韓国で見つけたらしい「Kimchi and IT」に吹く。
fizzbuzbizbuz
韓国にはIT女子が多い。彼女たちはみんなバイナリアン。韓国は楽園！
バイナリアンかっこいい。
１３．ucqさんの発表
バイナリエディタで始めるプログラミング入門。タイトルはネタ。
Twitterでつぶやいてたら採用されたらしい。
「とりあえず、実行ファイルをバイナリエディタONLYで書きます」
実行ファイルの形式は、PE, ELF, COM, Mach-O, a.out, ....
そうだ、Plan9でいこう！ 吹いた。
Plan9はフォーマットがシンプル。
ライブコーディングでバイナリエディタを使うプログラミング。これは斬新だ。胸が熱くなるな。
ヘッダの後に実行位置を書く。「ハンドアセンブルは面倒なのでNASMで」ですよねー。
デモは失敗……。残骸のコードが残ってしまっていたらしい。
１４．shudoさんの発表
いまどきのBinary Hacks 後編
Binary Hacksは大好評だったらしい。
Web系バイナリアン。かっこいい。
NerrymoserをデコードするためにLinux用のflv2mp3を利用することに。音声デバイスの出力を横取り。
「Segmentation Faultはお友達」
libX11.soで落ちてる。
バイナリエディタで書き換えたら動いた→さすがにこれはまずい。
GDB使ってブレークポイントを設定。
ioctlを呼んでスタックポインタがずれる。
よくよく眺めるためにlibcを逆アセンブル。
独自のioctlを使っているらしい。
処理を追うと末尾でなぜかジャンプ。この処理が悪さをしているらしい。
実行後にスタックポインタを補正して解決。
「binutilsはお友達」
みんなご愛用のバイナリエディタ。shudoさんはEmacsのhexl-modeを使っていた。
１５．d_kamiさんの発表
Javaでx86エミュレータを作った話。
OS作ったのでいろいろ知っていたが、命令コードのデコード方法は知らなかった。
ブログで宣言、Twitterで自分を追い込む。
アセンブリ言語のコードを実行できるようにする。
知らない命令を少しずつ実装中。現状は手抜きでプロテクトできてません！
１６．takahashiさんの発表
KVMをWindowsに移植した話。エミュレーションの処理が遅いようだ。
もうちょっと詳しく聞きたかった……。
１７．自分の発表 Vim = VM
VimはVMであると主張するいたって真面目なプレゼンだったはずなのに、
どうしてこうなった！ いろいろキワモノあつかいされました。反省はしていない。
詳細は発表資料を見てください。本当ならvimshellのデモをするはずだったのですが、一番最初に若干トラブったのとうまく画面切り替えできなかったので時間切れとなりました。
質問：Plan9でvimshellは動きますか？
答え：誰かが対応してくれれば……。私はLinux/Windows環境しかないので検証できません。
Macに対しても同じスタンス。ちなみに、Plan9にもVimはあるらしい。
質問：Emacs上でVimを動かせばいいのでは？
答え：エミュレーションにはあまり期待していない。それよりも、Emacsの優れた機能をVimに移植したい。
１８，１９：
もっと話を聞きたかったのですが、発表が終わった後で忙しくて話を聞けず……。
ベストオブLT（自分の中で）：
１．shudoさん
２．yojiroさん
３．oza_x86さん
４．ucqさん
５．syuu1228さん
みんなネタが濃い……。
全体に関する感想：
BSDとPlan9が大人気過ぎて吹く。なければ自分で（ドライバを）書くというその姿勢は見習いたい。
BSD系は比較的日本人コミッタが多いよね。なぜだろう？
自分の好きなOSを改造できるっていいな。
Vim = VMはもっと煮詰めれば真面目な研究課題として成り立つような気がする。
Vimからデバイスをいじれれば面白いですよね。真剣に検討しておこう。
ちなみに、力尽きたので懇親会には参加できませんでした。
何か質問があれば直接メール or github Issue or Twitterなどで。
会場に到着したのは12:20頃。割とはやめ。会場はなかなか広かった。
１．kozosさんの発表
組み込みOSを作ったよ！ という話。今度本が出るみたい。
ちょっと興味ある。
２．yojiroさんの発表
OpenBSDのYUREXドライバはどのように解析したのか、おまけとして
「かわいくない」温度センサの解析秘話つき。
この人の発表は面白すぎました。あまたの名言が飛び出す。
「ドライバの気持ちは分かってた」
３時間でデバイスドライバをハック、すごい！
３．kobaさんの発表
組み込みの人らしいです。クロスコンパイル環境をqemuでごにょごにょしてたという話。
４．honmaさんの発表
ついにYUREXの話キター！
今日のハイライト。貧乏揺すりを科学したYUREX。CMが放送されたこともあるらしい。
一生のうちに貧乏揺すりをする回数をまじめに計算＝＞10桁あれば大丈夫だろう。
検証する動画がシュール。お値段は￥12,600（これでも採算ギリギリ）でしたが、
時代を先取りしすぎて（売れなかったので）￥980に値下げ。まさかの92% OFF！
YUREXのサイトがある。まじめに解説しすぎてて吹く。
デバイスドライバはPython製。Windows 7専用ドライバもある。
秘密の在庫がまさかのワンコイン。即売会は争奪戦でした。
何が彼らを熱くさせたのか……。どうしてこうなった！
休憩を挟み、ここからLTになった。
５．go_vmさんの発表
Plan9で動くYUREXのドライバを書いた！という話。
各OSでYUREXのドライバを書くというのが前回のカーネル／VM探検隊後にはやったらしい。
3月終わりのHacathonにて実装。Plan9のUSBドライバはユーザー空間で動作する。
USBデバイスはファイルとして見える。おお、確かに動いている。
時間がないので続きはWebで。github上で公開しているらしい。
６．noztosさんの発表
NetBSDとYUREXの話。5秒に一回ポーリング。Twitterに投稿できるらしい。
７．syuu1228さんの発表
OpenBSDにsgi SMPを実装。Theoさん直々にマシンを買わされた。
共有メモリアーキテクチャでクラスタを構成できる、ごく普通のHPC。
いわゆる変形合体ロボ。プロセッサローカルな空間があり、ローカルなIOとリモートのIOがある。
OpenBSDが持っているのは全部で四台らしいので、「もう一台送られてくるかも？」と言っていた。
質問にて、「sgi SMPをどこに送ればいいんですか？」に吹く。
８．xylaoさんの発表
UNIX/32Vをエミュレータで動かす。マイクロコードを修正した話。
すごく……CPUです。いや私は大好物なんですけど。
VAXのマイクロコードを解説。あれ、これは何の勉強会だったっけ。
９．masami256さんの発表
デバイスドライバを作ろう！とInterface別冊で勉強していた。
「使い方を説明するので誰か実装して」に吹く。
１０．siritoriさんの発表
高校生の発表。H8SXマイコン上で動作するOSを作ろうという話。
スライドでまさかのハプニング。卒業研究らしい。
そこにH8SXマイコンがあったから。
OSはまだ書けてないようだ。逆質問を受け付けていた。
１１．oza_x86さんの発表
会場に来れなかったらしく、Skypeで参加。
Dynamick tikcsはお仕事があるときだけタイマー割り込み。
利点は消費電力の低減とゲストOS時にCPU使用率の低下。
社会人になるというイベントがあったので4月はあまり実装できず。26日からやる。
27日にパッチを投げる。実際にテストしてもらえることになり、ToDoが増えた。
FreeBSD 7.Xで試せるようになった。パッチとソースはgithub上にあるらしい。
今後はFreeBSD 8.1めがけてマージしたいとのこと。
１２．yumano・murahueさんの発表
韓国のハッキングコンテストに参加。ハッキングコンテストの話はそこそこに、韓国話。
韓国で見つけたらしい「Kimchi and IT」に吹く。
韓国にはIT女子が多い。彼女たちはみんなバイナリアン。韓国は楽園！
バイナリアンかっこいい。
１３．ucqさんの発表
バイナリエディタで始めるプログラミング入門。タイトルはネタ。
Twitterでつぶやいてたら採用されたらしい。
「とりあえず、実行ファイルをバイナリエディタONLYで書きます」
実行ファイルの形式は、PE, ELF, COM, Mach-O, a.out, ....
そうだ、Plan9でいこう！ 吹いた。
Plan9はフォーマットがシンプル。
ライブコーディングでバイナリエディタを使うプログラミング。これは斬新だ。胸が熱くなるな。
ヘッダの後に実行位置を書く。「ハンドアセンブルは面倒なのでNASMで」ですよねー。
デモは失敗……。残骸のコードが残ってしまっていたらしい。
１４．shudoさんの発表
いまどきのBinary Hacks 後編
Binary Hacksは大好評だったらしい。
Web系バイナリアン。かっこいい。
NerrymoserをデコードするためにLinux用のflv2mp3を利用することに。音声デバイスの出力を横取り。
「Segmentation Faultはお友達」
libX11.soで落ちてる。
バイナリエディタで書き換えたら動いた→さすがにこれはまずい。
GDB使ってブレークポイントを設定。
ioctlを呼んでスタックポインタがずれる。
よくよく眺めるためにlibcを逆アセンブル。
独自のioctlを使っているらしい。
処理を追うと末尾でなぜかジャンプ。この処理が悪さをしているらしい。
実行後にスタックポインタを補正して解決。
「binutilsはお友達」
みんなご愛用のバイナリエディタ。shudoさんはEmacsのhexl-modeを使っていた。
１５．d_kamiさんの発表
Javaでx86エミュレータを作った話。
OS作ったのでいろいろ知っていたが、命令コードのデコード方法は知らなかった。
ブログで宣言、Twitterで自分を追い込む。
アセンブリ言語のコードを実行できるようにする。
知らない命令を少しずつ実装中。現状は手抜きでプロテクトできてません！
１６．takahashiさんの発表
KVMをWindowsに移植した話。エミュレーションの処理が遅いようだ。
もうちょっと詳しく聞きたかった……。
１７．自分の発表 Vim = VM
VimはVMであると主張するいたって真面目なプレゼンだったはずなのに、
どうしてこうなった！ いろいろキワモノあつかいされました。反省はしていない。
詳細は発表資料を見てください。本当ならvimshellのデモをするはずだったのですが、一番最初に若干トラブったのとうまく画面切り替えできなかったので時間切れとなりました。
質問：Plan9でvimshellは動きますか？
答え：誰かが対応してくれれば……。私はLinux/Windows環境しかないので検証できません。
Macに対しても同じスタンス。ちなみに、Plan9にもVimはあるらしい。
質問：Emacs上でVimを動かせばいいのでは？
答え：エミュレーションにはあまり期待していない。それよりも、Emacsの優れた機能をVimに移植したい。
１８，１９：
もっと話を聞きたかったのですが、発表が終わった後で忙しくて話を聞けず……。
ベストオブLT（自分の中で）：
１．shudoさん
２．yojiroさん
３．oza_x86さん
４．ucqさん
５．syuu1228さん
みんなネタが濃い……。
全体に関する感想：
BSDとPlan9が大人気過ぎて吹く。なければ自分で（ドライバを）書くというその姿勢は見習いたい。
BSD系は比較的日本人コミッタが多いよね。なぜだろう？
自分の好きなOSを改造できるっていいな。
Vim = VMはもっと煮詰めれば真面目な研究課題として成り立つような気がする。
Vimからデバイスをいじれれば面白いですよね。真剣に検討しておこう。
ちなみに、力尽きたので懇親会には参加できませんでした。
何か質問があれば直接メール or github Issue or Twitterなどで。
2010年3月27日土曜日
RSenseをneocomplcacheで使用するには？
m2ymさんが作成したRSenseは、まだ未完成ですが優れた型推論機能で便利です。
しかし、Vimには一応対応しているもののcompletefuncを書き換えてしまうため、
neocomplcacheと併用すると問題が発生します。
私がneocomplcacheと相性が良くなるように書き換えたので、
etc/rsense.vimを置き換えてください。
http://github.com/Shougo/rsense
追記：Ver.0.3で私のパッチが取り込まれ、neocomplcacheに対応しました！
その上で、次のような設定をすれば一応動作します。
g:rsenseHomeはRSenseをインストールしたディレクトリを指定してください。
let g:rsenseHome = 'c:/rsense-0.3'
let g:rsenseUseOmniFunc = 1
if !exists('g:neocomplcache_omni_patterns')
let g:neocomplcache_omni_patterns = {}
endif
let g:neocomplcache_omni_patterns.ruby = '[^. *\t]\.\w*\|\h\w*::'
使用例はこのようになります。RSenseサーバーの応答速度が遅いので、
補完は若干もたつきます。注意してください。
neocomplcacheと併用すると問題が発生します。
私がneocomplcacheと相性が良くなるように書き換えたので、
etc/rsense.vimを置き換えてください。
http://github.com/Shougo/rsense
追記：Ver.0.3で私のパッチが取り込まれ、neocomplcacheに対応しました！
その上で、次のような設定をすれば一応動作します。
g:rsenseHomeはRSenseをインストールしたディレクトリを指定してください。
let g:rsenseHome = 'c:/rsense-0.3'
let g:rsenseUseOmniFunc = 1
if !exists('g:neocomplcache_omni_patterns')
let g:neocomplcache_omni_patterns = {}
endif
let g:neocomplcache_omni_patterns.ruby = '[^. *\t]\.\w*\|\h\w*::'
使用例はこのようになります。RSenseサーバーの応答速度が遅いので、
補完は若干もたつきます。注意してください。
2010年2月24日水曜日
諸君 私は補完が好きだ
諸君 私は補完が好きだ
諸君 私は補完が好きだ
諸君 私は補完が大好きだ
手動補完が好きだ
自動補完が好きだ
インテリセンスが好きだ
スペルチェックが好きだ
シェルが好きだ
予測補完が好きだ
オムニ補完が好きだ
Vimで Emacsで 秀丸で
zshで bashで
ATOKで skkで GoogleIMEで
携帯で スマートフォンで
Visual Studioで Eclipseで
このプログラム上で行われる ありとあらゆる補完作業が大好きだ
Vimがバッファからキーワード補完を行うのが好きだ
zshがコマンドの引数を予想して適切な候補を提示した時など心がおどる
ATOKが間違った日本語を訂正するのが好きだ
複雑なテンプレートを使用したC++のコードを
Visual Studioのインテリセンスで補完したときなど胸がすくような気持ちだった
zshが補完の世界を蹂躙するのが好きだ
補完を知らない初心者がシェルの引数をちまちまと入力している様など感動すら覚える
履歴補完をしらない輩を<C-r>で吊るし上げていく様などはもうたまらない
泣き叫ぶバグ入りのコードが私の這い回る<TAB>の指さばきとともに
補完によってあっというまに正常に書き換えられるのも最高だ
統合開発環境に目茶苦茶にされるのが好きだ
必死に守るはずだったエディタとシェルの牙城が蹂躙され
元祖のキーバインドがWindowsライクに変更されていく様はとても悲しいものだ
anything.elの物量に押し潰されて殲滅されるのが好きだ
VimとEmacsの宗教論争に追い回され、統合開発環境にその主導権を奪われるのは屈辱の極みだ
諸君 私は補完を 最強の補完を望んでいる
諸君 私に付き従うエディタユーザー諸君
君達は一体何を望んでいる？
完全なるオムニ補完を望むか？
情け容赦のない糞の様なスペル訂正を望むか？
肥大化の限りを尽くし数多のエディタを葬る悪魔の様な統合開発環境を望むか？
zsh: <TAB>!!
Emacs: <TAB>!!
Vim: <TAB>!!
よろしい ならば補完だ
我々は渾身の力をこめて今まさに<TAB>キーを押し下げんとする左手小指だ
だがこの黒い画面の上で四半世紀もの間堪え続けて来た我々に
<TAB>の打鍵すらもはや必要ない！！
更なる補完を！！
最強の自動補完を！！
我らはエディタと補完をこよなく愛する一派に過ぎない
だが諸君は一騎当千の古強者だと私は信仰している
ならば我らは諸君と私で究極の自動補完プラグインneocomplcacheとなる
我々を忘却の彼方へと追いやり眠りこけている連中を叩き起こそう
髪の毛をつかんで引きずり降ろし眼を開けさせ思い出させよう
連中にCUIの世界を思い出させてやる
連中に我々の<TAB>キーの打鍵音を思い出させてやる
自動補完には奴らの哲学では思いもよらない世界が広がっている事を知らしめてやる
一千人のVimの戦闘団でソースコードを書き換え尽くしてやる
「neocomplcacheインストール開始」
「:NeoComplCacheEnable!」
「最後のVimユーザーより全エディタユーザーへ」
第二次 自動補完作戦 状況を開始せよ
征くぞ 諸君
ついカッとなってやった。反省はしていない。
※：ご好評にお応えして、追記しました。
諸君 私は補完が好きだ
諸君 私は補完が大好きだ
手動補完が好きだ
自動補完が好きだ
インテリセンスが好きだ
スペルチェックが好きだ
シェルが好きだ
予測補完が好きだ
オムニ補完が好きだ
Vimで Emacsで 秀丸で
zshで bashで
ATOKで skkで GoogleIMEで
携帯で スマートフォンで
Visual Studioで Eclipseで
このプログラム上で行われる ありとあらゆる補完作業が大好きだ
Vimがバッファからキーワード補完を行うのが好きだ
zshがコマンドの引数を予想して適切な候補を提示した時など心がおどる
ATOKが間違った日本語を訂正するのが好きだ
複雑なテンプレートを使用したC++のコードを
Visual Studioのインテリセンスで補完したときなど胸がすくような気持ちだった
zshが補完の世界を蹂躙するのが好きだ
補完を知らない初心者がシェルの引数をちまちまと入力している様など感動すら覚える
履歴補完をしらない輩を<C-r>で吊るし上げていく様などはもうたまらない
泣き叫ぶバグ入りのコードが私の這い回る<TAB>の指さばきとともに
補完によってあっというまに正常に書き換えられるのも最高だ
統合開発環境に目茶苦茶にされるのが好きだ
必死に守るはずだったエディタとシェルの牙城が蹂躙され
元祖のキーバインドがWindowsライクに変更されていく様はとても悲しいものだ
anything.elの物量に押し潰されて殲滅されるのが好きだ
VimとEmacsの宗教論争に追い回され、統合開発環境にその主導権を奪われるのは屈辱の極みだ
諸君 私は補完を 最強の補完を望んでいる
諸君 私に付き従うエディタユーザー諸君
君達は一体何を望んでいる？
完全なるオムニ補完を望むか？
情け容赦のない糞の様なスペル訂正を望むか？
肥大化の限りを尽くし数多のエディタを葬る悪魔の様な統合開発環境を望むか？
zsh: <TAB>!!
Emacs: <TAB>!!
Vim: <TAB>!!
よろしい ならば補完だ
我々は渾身の力をこめて今まさに<TAB>キーを押し下げんとする左手小指だ
だがこの黒い画面の上で四半世紀もの間堪え続けて来た我々に
<TAB>の打鍵すらもはや必要ない！！
更なる補完を！！
最強の自動補完を！！
我らはエディタと補完をこよなく愛する一派に過ぎない
だが諸君は一騎当千の古強者だと私は信仰している
ならば我らは諸君と私で究極の自動補完プラグインneocomplcacheとなる
我々を忘却の彼方へと追いやり眠りこけている連中を叩き起こそう
髪の毛をつかんで引きずり降ろし眼を開けさせ思い出させよう
連中にCUIの世界を思い出させてやる
連中に我々の<TAB>キーの打鍵音を思い出させてやる
自動補完には奴らの哲学では思いもよらない世界が広がっている事を知らしめてやる
一千人のVimの戦闘団でソースコードを書き換え尽くしてやる
「neocomplcacheインストール開始」
「:NeoComplCacheEnable!」
「最後のVimユーザーより全エディタユーザーへ」
第二次 自動補完作戦 状況を開始せよ
征くぞ 諸君
ついカッとなってやった。反省はしていない。
※：ご好評にお応えして、追記しました。
登録:
投稿 (Atom)