D-7 <altijd in beweging>

Day to day life of a Perl/Go/C/C++/whatever hacker. May include anything from tech, food, and family.

タグ:peco

さきほどちょろっとアップデートが入ったpeco v0.2.2をリリースしましたChangeログ)。

で、ついでに昨日mattnさんがpecoについてツイートしてたので流れてしまう前にまとめておく


続きを読む
    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

pecoのv0.1.0をリリースしてから今日で丸一ヶ月がすぎました。今日という日にちょうどGitHubでのスターも1000を超え、大変うれしい次第です。ちなみに昨日の夜840くらいだったのにそれから200弱ものスターがついた。これぞまさにTJのロックスター効果:



「percolをインストールするのにpythonの事調べるのだるい」というだけのところからmattn氏の悪魔のささやきを真に受けて始まったこのプロジェクトですが、まぁ何がよかったのかこの程度の注目を集められるレベルに到達できて大変うれしいです。自分もこのコードを書いててようやくgo-stf-serverでメタメタだった部分が少しずつ昇華できている気がしているし、クロスコンパイル部分も完全自動化できたりと技術的な学びの意味でもやってよかったと思えるプロジェクトになりました。

v0.2.1では 複数のアクションをまとめて1キーからディスパッチできるようになる機能などが同梱される予定です。

機能的にはだんだん落ち着き始めているので、もし何かあったらイッシューに書いてください(日本語でいいんですよ!)。これからも皆様の意見、PRをお待ちしております! 
    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

先週 @k0kubunさんがpecoで複数キーの入力シーケンスに対してアクションを起こす(例:C-x, C-cで終了する、みたいなの)PRをしてくれたのでそれをマージした。pecoには楽しいお兄さんが色々コントリビュートしてくれているので、そのPRを見た瞬間にこんなコメントが

おお、いいですね、ということで実装してみようとしたところ… うっ… 設定ファイルから読み込んで動的に作る無名関数からレキシカルな変数へのスイッチングしてて、これをプログラム内部から他に作る方法がねぇ!w 設定ファイルからはできるのに!w むきー!

ということでその後、基本的な設計構造を変えないでその辺りを奇麗にできる方法は ないかと一日くらい費やした。が、やはりうまくいかない。薄々気づいていたけどこれFSMとかの出番だよな… 一から実装面倒くせぇなーと、つぶやいたらすぐ返信が:


うほ!goでahocorasickの実装があるwwww ありがとうございます!全部ぱくります!

コードを眺めているとトップレベルではstringに対しての実装で、 中身はruneに対してノードを返すみたいな事になってるので、これまぁ用はstring = []rune として考えられるので、キーシーケンス= []キー で代用できるね、って分かったのでガツガツ変更。といっても検索キーとか、ちょっと再起的に使うためにinterfaceを足した程度で、基本は何も変えていない。

そんなこんなで最初にpecoを書き始めてから一番大きいPRをマージして、キー入力周りがそれまでのコードと一変した。コードを提示してもらったおかげで任意の長さのキーシーケンスを特定のコマンドを高速かつ分かりやすい形で検索+ディスパッチできるようになった。

これも含めて先ほどpeco v0.2.0としてリリースした。このリリースはかなりの数の変更が入っているので、pecoヘビーユーザーには嬉しい機能が結構あると思う。是非お試し有れ!

本日の教訓:この一つ前の記事もパクリの話だったけど、こういう汎用的な方法論についての助言はどんどん受け入れるべきだし、コードもがんがん再利用してやればいいと思う。

プログラムを書く作業は孤独だけど、わからない事は「分からない!どこから始めるか教えて!」って聞けば誰でもヒントをくれるので人に頼る事を恐れないほうが良い(ただし、そこから先は自己責任でちゃんと勉強しましょうね)。そういえばgo-xslate書いた時もgfxに「これ、どこのサイト読むとxslateで使ってるVMのモデルの概要わかるの?」って聞いたな。

年を取れば取るほど経験値はたまっていくけど、それと同時に自分の知らない事が世界にはまだまだあるのがわかる。もちろんそれらを全部吸収できればベストなんだけど、脳にも限界があるので他人に聞く事によって自分の知らない事を素早く正しく補完できるのであればそれを活用できるようにつながりを作ったり、素直に質問できるようにしていくのが老いてゆくエンジニアの進む正しい道な気がする。おすすめです。
    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

pecoでは何個か前のリリースからバイナリビルドをリリースの成果物として登録するようにしている。これのおかげでpecoはそもそもの存在理由である「2014年だしこういうツールはバイナリ一個置いておくだけで動いてほしい!」というをより簡単に実現できている。


で、その実装方法。基本motemenさんのスクリプトにmattnさんがツッコミを入れたりしてるのを見ながら「よし!パクろう!」と思ってパクったんだけど、一つだけpecoでは意図的に変えたところがあって、それはboxの選定のところ。

motemenさんのgolang-goxc box自体に基本何も問題がないのだけど、pecoで色々やっているうちにgo1.3がリリースされたのにこのボックスを使っているといつまでもgo1.2.1だった(今はもう違うかもしれない)。まぁ当たり前ですよね。そこは他人の褌で相撲を取ろうとしている俺が文句言うところではない。

ただやっぱりバイナリのサイズが小さくなったり、多少パフォーマンス改善も見られている1.3系を使いたいと思いが募ったのと「これから先もきっとこういう事があるだろうし、そういうことがあるごとに文句を言わないといけないのか?」という思いがあり、pecoにはpeco専用のビルドボックスを作る事にした。それがこちら。もちろんgo1.3とgoxcを入れているところ以外はたいした事してない。

たいしたことはしてないんだけど、よくよく考えればライブラリとかではなくpecoのようにエンドユーザーに直接届くプログラムに関してはあまり自分が制御できていない環境に依存するのもどうかなーと思ったのでもうボックスから作る事にしてしまった。これなら自分がやりたいタイミングでgo1.4が出たらgo1.4にすることもできるし、goxcの特定のバージョンが欲しい、とかにも対応できる。

あとはmotemenさんの元記事と一緒。タグ打ってgit pushすれば勝手にファイルがあがってくる。おっさんは何もする必要がありません。大変すばらしい。また時間のある時にはhomebrewのレシピも自動的に作成しようとは思ってるけどそこまで至っていない。ともあれ、自動化はすばらしい。





ちなみに、drone.ioも一応登録はしてあって、こっちでもリリースとかできるかやってみたんだけど失敗して、ただただコンパイルして成果物を残しているだけ(基本前のやつは上書き)。あんまり必要じゃないけど、別の環境でコンパイルするとたまにバグが見つかったりもするので悪くはないと思ってる。まぁそのうち消すかも。
    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

tl;dr;
続きを読む
    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

このページのトップヘ