はてなブックマーク

H(uman-friendly) な grep コマンド hgrep をつくりました． github.com '\w+ で検索した時の出力 ファイルを特定のパターンで検索し，マッチした箇所を構文ハイライトしたコード片で表示します．超ざっくり言うと，ripgrep で検索して bat でマッチ箇所付近を表示するような感じです． grep -C によるコンテキスト表示に似ていますが，マッチ行が近い時は1つのコード片にまとめる，周囲何行を表示するかをヒューリスティックに少し賢く決めているなど，ちょっと出力は工夫しています． 動機 手元のリポジトリでコードを検索する時は 単純に grep で検索してマッチ結果を眺める grep | fzf のように検索結果を fzf で絞り込んだりプレビューする vim $(grep -l ...) のように検索結果をエディタで開く あたりを使い分けているのですが

前回の actionlint の記事 GitHub Actions のワークフローをチェックする actionlint をつくった からちょうど1ヶ月経ち，今日 v1.6.0 をリリースしました．前回時点では v1.4.0 で，そこから v1.4.1, v1.4.2, v1.4.3, v1.5.0, v1.5.1, v1.5.2, v1.5.3, v1.6.0 とリリースを重ねています．git diff によると v1.4.0 〜 v1.6.0 で 155 files changed, 14816 insertions(+), 2981 deletions(-) のコード変更を行ったようです． github.com この記事では大きめの機能追加や改善をいくつか紹介します． 有名アクションの input/output チェック スクリプトインジェクション脆弱性のチェック -format オプ

GitHub Actions のワークフローを静的にチェックする actionlint というコマンドラインツールを最近つくっていて，概ね欲しい機能が揃って実装も安定してきたので紹介します． github.com なぜワークフローファイルの lint をすべきなのか GitHub Actions が正式リリースされてからだいぶ経ち，GitHub 上での CI は GitHub Actions が第一候補となってきているように感じます．僕も新規にリポジトリを作成して CI をセットアップする場合はほぼ GitHub Actions を使っています． ですが，GitHub Actions には下記のような問題があり，actionlint でそれらを解決・緩和したいというのが理由です． ワークフローを実装する時は，GitHub に push して CI が実行されるのを待って結果を確認するという

Go でコマンドラインツールを実装した時に $ some-tool -version のようにバージョンを出力するフラグを実装することが多いと思います．本記事はこれをどう実装するかのメモです． 手動でバージョン情報を管理 素朴にはバージョン情報を定数で持って手動で管理する方法があります． package main import ( "flag" "fmt" ) const version = "1.2.3" func main() { var v bool flag.BoolVar(&v, "version", false, "Show version") flag.Parse() if v { fmt.Println(version) } } 新しいリリースを行うときは version 定数の値を手で書き換えてコミットしてからリリース用のタグを打つという方法でやっていたのですが，間をおい

TLDR Rust で実装した Wasm インタープリタで PGO 試したら 0〜10% ぐらい速くなった Profile-Guided Optimization (PGO) とは PGO はコンパイラの最適化の手法のうちの1つですが，プログラムを実行した後に行うという点で少し他と異なります． まずは普段どおりの最適化オプションでプログラムをビルドする プログラムを実環境で動かし，profile data を取る 再度プログラムをビルドしなおす．ただし，ここの最適化では 2. で収集した profile data に基づいてインライン化やレジスタ割り当てなどを行う より最適化されたプログラムが出来上がる このように，実世界でどう実行されるかをフィードバックした最適化をかけて再ビルドすることで，プログラムのビルド時で完結していた従来の最適化よりも進んだ最適化をかけられるようにするというもので

今週ちまちまと git-messenger.vim や clever-f.vim の CI を GitHub Actions に移行していました．毎回 Vim プラグインの CI のために Vim や Neovim のセットアップを書くのが面倒なのと，Windows 上で Vim や Neovim を入れるのが（Powershell に不慣れなこともあり）大変だったので，GitHub Action として切り出すことにしました． github.com 1ステップで Vim や Neovim を簡単にインストールできます． Vim と Neovim 両対応 Linux, macOS, Windows すべてで動作 'stable' と 'nightly' の両方に対応 追記: 特定バージョンにも対応（v1.1.0） 使い方 下記のようにステップを書けば Vim または Neovim をインス

GitHub Action を TypeScript で作成したので，覚え書きがてらどうやって作ったかについて書きます． github-action-benchmark という Action をつくりました． 紹介記事：継続的にベンチマークを取るための GitHub Action をつくった Action とは 今年9月に GitHub Action v2 がリリースされました．GitHub Action は GitHub が提供する CI/CD サービスです． 既存のサービスと大きく違う点は，処理を汎用的に Action として切り出して再利用できることです． 例えば，GitHub からのリポジトリのクローン actions/fetch や Node.js のセットアップ actions/setup-node などの基本的な実行ステップも Action として実装されています． Acti

今年9月に GitHub Action v2 がリリースされました．GitHub Action は GitHub が提供する CI/CD サービスです． 既存のサービスと大きく違う点は，処理を汎用的に Action として切り出して再利用できることです． 例えば，GitHub からのリポジトリのクローン actions/fetch や Node.js のセットアップ actions/setup-node などの基本的な実行ステップも Action として実装されています． 今回はこの GitHub Action を利用して，前々からあると良いなと思っていたベンチマークを継続的に取るための Action をつくりました． github.com github-action-benchmark はベンチマークの実行の出力からベンチマーク結果を抽出し，GitHub pages のブランチに JSO

言語処理系やテキストエディタなどのプログラミングツールが好きなので，その周辺を趣味で触ってます．Vim を Wasm にポートするために Vim の実装を読んだりはしているのですが，フルスクラッチでテキストエディタをつくったことはありませんでした． 今年のお盆はめちゃ暑かったので，引きこもって夏休みの自由工作的に Rust でテキストエディタをつくっていたという話です．普段ターミナルで作業しているので，つくるのもターミナル向けテキストエディタです．最近 vim.wasm で C と TypeScript ばかりだったので，そろそろまた Rust か Go を書きたかったのですが，Go はすでに micro という良さそうなテキストエディタ実装があったので，Rust で書いてみることにしました． まずは Build Your Own Text Editor というガイドを利用して，1000行

あいにくの雨でしたが，Meguro.vim #16 に参加しました． 「この雨の中 Vim のもくもく会に来た者たちだ．面構えが違う」 #megurovim— ドッグ (@Linda_pp) June 15, 2019 目黒.vim は Vim に関したり関しなかったりする作業をするもくもく会で，今回は Vim に :const を追加するパッチを書きました． github.com :const コマンドの機能 Vim script では変数を :let で定義・代入します．ですが， 新しい変数定義時も代入時も同じ :let を使う if などで新しいスコープが作成されない（動的スコープ） により，意図せず既存の変数を上書きしてしまうケースがあります． " Define variable let i = 0 if some_condition " In heavily nested or

この記事は以前の rhysd.hatenablog.com の続編で，WebAssembly (Wasm) にポーティングした Vim の話です． github.com TLDR Wasm にコンパイルした Vim のコードを Web Worker（ワーカスレッド）の中で動かすことで，メインスレッドで行われるユーザのインタラクションをエディタがブロックしなくなりました． また，イベントループのポーリングを Atomics.wait() でやってキー入力を共有メモリバッファで受け取ることで Emterpreter を捨て，実行速度・安定性・バイナリサイズ・ビルド時間・メンテ性が向上しました． 実装: Run Vim in Web Worker and say goodbye to Emterpreter by rhysd · Pull Request #30 · rhysd/vim.wasm

git-messenger.vim は，カーソル下の行のコミット情報を表示する Vim プラグインです． github.com 他所のプロジェクトのコードや OSS のコードを読んでいると，なぜこうなってるんだろう？と思うことがよくあります．コミットメッセージをまともに書いているプロジェクトでは，その部分の変更を加えたコミットメッセージに答えがあることがあるのですが，毎回 git blame で対象のコミットを引っ張ってきて git show で読むのは結構大変です． git-messenger.vim では，その負担を軽減するために，(1) カーソルがいる行にコミット情報を git から引っ張ってきて (2) 良い感じに表示する という機能を提供します． もう6年も前につくったプラグインなのですが，Vim の制約上いくつかの問題があり，syohex さんの Emacs port に比べて

Rust 公式の linter，clippy に新しいルールを足すプルリクを出してマージされた時のメモです． github.com dbg! マクロ Rust 1.32 で dbg! というマクロが追加されました． これは値を1つ引数にとってその値を返すマクロで，受け取った値とソースコード上での位置を print します． fn factorial(n: u32) -> u32 { if dbg!(n <= 1) { dbg!(1) } else { dbg!(n * factorial(n - 1)) } } dbg!(factorial(4)); 名前の通り，いわゆる print debug 用途のマクロなので，デバッグが終わってリポジトリに commit する前にはコードから dbg! マクロを削除しておくのがベストプラクティスです． 公式ドキュメントにも Note that the

Vim Advent Calendar 2018 の24日目の記事です．昨日は Kaoriya さんのVim に VOICEROID で喋らせたでした． もうすぐクリスマスなので，クリスマスツリーを飾りたいと思います．ただ飾るだけだと Vim のネタにならないので，Crystal や Wast，vim-gfm-sytnax, vim-github-actions といったファイルタイププラグインをつくった経験を活かし，構文ハイライトを使って Vim の中でクリスマスツリーを飾っていきたいと思います． Vim の構文ハイライトについての情報は下記の help ドキュメントを読んでいただければ，ある程度網羅的な情報が手に入るので，実際に何かのファイルタイプを追加するプラグイン（ファイルタイププラグイン）を実装する時は，まずざっと一通りドキュメントを眺めることをおすすめします． :help sy

GitHub Actions Open Beta に申し込んで1ヶ月以上経ち，ようやく使えるようになったみたいなので実際にどう使うのか調査してみたメモ． Beta 版は GitHub のプライベートリポジトリにしか使えないため，公開リポジトリに使うにはもう少し待つ必要がありそう． GitHub Actions とは GitHub Universe 2018 で発表されたときにメディアが記事にしているので，そちらを読んでください． https://www.publickey1.jp/blog/18/github_actionsdockergithub_universe_2018.html https://cloud.watch.impress.co.jp/docs/event/1148428.html https://codezine.jp/article/detail/11170 公式ドキ

npm でよく使っている husky というツールがあります．これは npm install などを hook して Git hook を自動でセットしてくれるツールで，リモートにプッシュする前のチェックを強制してくれます．もちろん CI でもテストを回しているのですが，プッシュ前にもチェックすることによりケアレスミスに早く気付くことができます． Rust でもこの仕組みを使いたかったのですが，そういうツールが無かった＆つくれそうだったので cargo-husky というツールをつくりました． github.com 基本的な使い方 cargo-husky パッケージを Cargo.toml の dev-dependencies に追加して cargo test を実行するだけです． [dev-dependencies] cargo-husky = "1" $ cargo test carg

Vim に WebAssembly のテキストフォーマット (wast) の対応を入れ，同時に filetype=wast で使われるファイルのメンテナになりました． Wasm のテキストフォーマットとは WebAssembly にはバイナリ形式とテキスト形式の2つのフォーマットがあります．Wasm はネットワークを介して配布される前提のため，サイズの小さいバイナリ形式のほうが良いですが，デバッグなどで処理を追いたい人間にとってはテキストフォーマットも必要になるためです． emscripten はデバッグオプションをつけてコンパイルすると，生成物 .wasm のほかにテキストフォーマットの .wast およびそのソースマップを生成してくれます． こんな感じのS式です contribution の流れ 0. Vim プラグインとして実装 まだブラウザが Wasm を初めてサポートし始めた頃，

久々のブログです． 6月ぐらいにWebAssembly の仕様をざっくり読んだので，なんか WebAssembly でやりたいなと思って，Vim を WebAssembly に移植してブラウザで動くようにしてみました，という話です． github.com 多分実物を見ていただくのが一番早いので，下記のリンクにアクセスしてみてください． デモページはこちら（下記の注意事項を先にお読みください） 注意 デスクトップ版の Chrome か Firefox か Safari か Edge を使ってください．どうやら macOS では Safari が一番動きが良いです． デモページは全部で1MBほどのリソースを fetch します．モバイルネットワークなどからアクセスする場合はお気をつけください． keydown でキー入力を取っているので，キー入力を横取りするブラウザ拡張などが有効になっていると

先日 kazuho さんが git blame でプルリクを表示するスクリプトをつくってらっしゃって，便利そうだったので Vim プラグインをつくってみました． ファイルの各行がどのプルリクで変更されたかを確認し，気になるプルリクはその場で詳細を確認することもできます． github.com 使い方 インストールはお好みの Vim プラグインマネージャを使うなどしてください． 1. ファイルを開いて :GHPRBlame を実行 :GHPRBlame を実行すると裏で git-blame が走り，カレントバッファのファイルの各行のプルリク情報を git blame --line-porcelain で引っ張ってきます． 引っ張ってきた情報を元にカレントバッファの左に細長い一時バッファが開き，そこに各行に紐付いたプルリク番号が表示されます（プルリクに紐付いていない行は何も表示されません）．

Vim Advent Calendar 2017 の19日目の記事です．Vim script で ES6 の Promise を実装した話を書きます． もし Vim script が分からなくても，最後の章「Promise の実装の詳細」は Vim script とは独立した内容になっているので，Promise の実装に興味があれば読んでみてください． TL;DR 実装はこちら Promise とは ES6 (ES2015) で ECMAScript に標準に導入された非同期処理を扱うためのライブラリです． これを使うことにより，「未来のある時点でいずれ値を持つ」値を扱うことができ，ES5 まではコールバックで扱う必要があった非同期処理を逐次処理的な書き方で書きつつ，エラーも一貫した方法で扱えます． 例えば，ネットワークのどこかから取ってきたデータをファイルに保存する処理は，ネットワークか

言語実装 Advent Calendar 2017 の16日目の記事です． GoCaml という OCaml のサブセットな言語を実装していて，多相型の型推論を実装するために論文を読んだり OCaml の実装をちょっと追ったりしていたので，その知識を整理する意味でこのエントリを書いています． この記事では OCaml の型推論器のベースになっている「レベルベースの多相型型推論アルゴリズム」について概略を直感的に説明しようと思います． 理論的になぜこのアルゴリズムで正しく動作するのかについてはこの記事で概要を把握した上で論文 のほうを読んでいただければ理解が速いと思います． また，この記事では最もシンプルな単相型のHM型推論については知っている前提で書きます． ご存知でない場合は， 住井先生の MinCaml の型推論実装の解説 五十嵐先生の型推論の解説 20日目の@uint256_t さん

木曜日午後〜日曜日午前中の4日間，Vim コミュニティつながりの知人と旅館に泊まり込んでもくもく作業する合宿的な旅行に行ってきました． 当日の様子や旅館の便利情報についてはすでにブログ記事にまとめられているのでそちらを読んでいただいて，この記事内では僕がやった作業内容を備忘録的に書いておきます． 土善旅館で最高の開発合宿をしような - darui.io 中年週末旅行 - チューリング不完全 今回やったこと neovim-component と NyaoVim の Polymer v2 対応 clever-f.vim のテストを themis.vim に移行 clever-f.vim のテストカバレッジを covimerage を使って取る Vim プラグインの試作（まだ途中） neovim-component と NyaoVim の Polymer v2 対応 今回の一番でかい成果はウェブ

LLVM IR の alloca 命令の使い方について，リファレンスマニュアルに載ってない注意点があったのでメモがてら書きます． alloca 命令とは スタック上にメモリを確保し，確保した領域の先頭へのポインタを返します．スタック上にメモリを割り付けることでアドレスが必要なメモリ領域を得ることができ，自動変数などの実装に使うことができます． http://llvm.org/docs/LangRef.html#alloca-instruction %ptr = alloca i32 ; yields i32*:ptr %ptr = alloca i32, i32 4 ; yields i32*:ptr %ptr = alloca i32, i32 4, align 1024 ; yields i32*:ptr %ptr = alloca i32, align 1024 ; yields i

個人的に気になっていた Electron のタッチバーサポートがついに master にマージされました． 実装は下記の PR で行われ，@MarshallOfSound さんの初期実装と @kevinsawicki さんのブラッシュアップで実装されました． https://github.com/electron/electron/issues/8095 まだリリースされていないですが，待てなかったので master ブランチの実装を試してみました． 追記（2017/3/8）: v1.6.3 beta としてリリースされました． Electron の master ブランチをビルドする ビルドの仕方はドキュメントにまとめられています． 再配布せず手元で試すだけであれば面倒そうな「macOS SDK」のセクションは無視してしまって大丈夫です． # リポジトリを取得 $ git clone h

GitHub でコードを見ていると，ハイライトがおかしいのを見つけることがたまにあります．ここではその直し方を紹介します． 次の2パターンを想定しています． 自分のリポジトリのあるファイルのハイライト言語がおかしい 構文ハイライトが間違えている，言語の新機能に対応していない 自分のリポジトリのあるファイルのハイライト言語がおかしい コードをどの言語でハイライトするかは自動判別されますが，実はある程度ユーザ側で制御する方法があります． Vim や Emacs のモードラインを書く ファイル単位で Vim や Emacs の設定をマジックコメントとして書けるモードラインですが，実は GitHub もそれを参照しています // C++ だけど拡張子は .h … C じゃなくて C++ でハイライトしてほしい // vim: set ft=cpp // // または // // -*- mode:

git-brws のリリース で微妙に Travis CI 上の rust 環境でハマったのでメモ． 前提として，cargo build でビルドできるものとします．Travis の環境はツールチェーンが古いと困るので Ubuntu 14.04 を使ってます．今回は下記の環境向けのバイナリをビルドしてリリースしました． x86_64-unknown-linux-gnu x86_64-apple-darwin i686-unknown-linux-gnu aarch64-unknown-linux-gnu Linux は musl libc を使う選択肢もありますが，使い慣れた glibc にしました． 3行で この .travis.yml を パクれ https://github.com/rhysd/git-brws/blob/master/.travis.yml ビルド環境 まずは　ma

GitHub contributions グラフを続けるのも4年目に入っていて，来年も無理しない程度に続けて行こうかなぁと思ってます．今年は中盤あたりイマイチだったけど後半結構時間ができたので例年通りぐらいになりました． 今年もぼちぼち使っているツールのためのプラグインとか，ほしいアプリとかで新しく色々つくった気がするのでまとめてみました． crdoc: Crystal のドキュメントをコマンドラインから引けるコマンドラインツール ask-on-exception: 例外が出た時に自動的に例外のメッセージで StackOverflow を検索してくれるネタモジュール devdocs.vim: devdocs.io を Vim から直接引ける Vim プラグイン vim-wasm: WebAssembly のテキスト形式 wasm の Vim ファイルタイププラグイン subvim: Vim