Development

Elasticsearchでサイト内検索できるようにしてみた

このサイトは静的サイトジェネレータの Hugo を使って生成していて、これまで検索欄は Google 検索に site: をつけてクエリを投げるという方法で実現されていました (これは使っているテーマのデフォルトだったため)。 それを今回、Google に飛ばずに自前で検索を行うという感じにしました。 モチベーション Google 検索での一番の問題は、「サイト内のすべてのページにタグ一覧が配置されているために、 キーワードがタグ名と一致する場合すべてのページがヒットしてしまう」という点でした。 Google 検索で検索に使う範囲を指定できればよいのですが、そういったこともできそうになく、 自前で検索する必要性を感じていました。 あと、サイト内の情報が知りたいだけなのに

エミュレータについて

遊びで作っているエミュレータについていろいろまとめておこうかなというだけの投稿。 実験で作った CPU のエミュレータです。 最初は実機でデバッグするのが辛いだろうということでアセンブラに簡易的な実行機能を つけようといった程度のモチベーションで始めたんですが、デバッガの実装が意外に面白かったので だんだん機能が増えてきているという感じです。 機能 今の所こんな感じです。 アセンブリで書いたプログラムを実行する 分岐命令の飛び先のアドレスをラベルで指定できる メモリの初期化ファイルに書かれた内容で内部のメモリを初期化 命令のアドレスにブレークポイントを置く 実行した命令をもとに戻す (Undo) 未定義動作を踏みそうになったら例外を飛ば

Emacs内のターミナルでのEmacsの実行をいい感じにした

ちょっと前ですが、「Emacs 内のターミナルで Emacs を開こうとしたら既に開いている Emacs でそのファイルを開く」やつを作りました。 しくみ ざっくり説明すると、DBus を使って Emacs とシェル (で立ち上がるプロセス) が通信して、 Emacs を開く代わりに現在のセッションで開いているように見せるという感じになります。 通信できるなら別に DBus じゃなくてソケットでもいいんですが、DBus だと Emacs Lisp の インターフェースでサーバを作るのが楽なので DBus になりました。 さて、この機能の実現には Emacs 側とシェル側 (厳密には emacs コマンドで立ち上げるプロセス) に細工が必要です。これ以降でそれらをもう少し詳しく説明します。 Emacs 側の細工 DBus インターフェースで待ち受けて

WebAssemblyを触ってみた

めっちゃお久しぶりです。 WebAssembly でハロワ的なサムシングを C++ でやったらすんなり動きすぎて感動したというポストです。 動機としては C++ で書いた SMF (Standard MIDI File) のパーサをブラウザ上で使いたかった ということです。別に速度を求めていたとかそういうわけではないのですが、バイナリを扱うのはやっぱり JavaScript よりも C++ とかの方がぱぱっと書けるかな、という。 で、使ったコードはリンク先に置いてあります。 https://github.com/kofuk/haystack/blob/df5d58caadf1ca640fef80484ac138faa6090c14/smf.cc 一応ビッグエンディアンをリトルエンディアンに変換している部分が wasm での挙動が予想できないため 不安な要素だったんですが、リトルエンディアンと考えていいみたいでした。 (これってコンパイルされた wasm をビッグエンディアンのマシンに持っていったら動かない

VTE で Sixel が使えるようになった

久しぶりに vte のリポジトリを見に行ったら HEAD で Sixel が使えるようになっていたので、 その導入方法を……。 適当に調べた感じだと GNOME 端末 3.37 とかでもサポートされてるっぽいです。 sover 見た感じだと ABI 互換性が崩れたことはなさそうなのでどのバージョンでも問題は起きないかと思います。 バージョン Arch Linux 上で確認をしています。 また、実際に使ったコミットのハッシュは以下です。 c17e6d12da00a94c3768be6671182a6a039ec0c0 方法 まだリリースされていないので HEAD を取ってくる必要があります。 なんかサーバ遅い気がするので --depth 1 をつけて履歴を取ってこないようにした方がいいかもしれません。 $ git clone https://gitlab.gnome.org/GNOME/vte.git ソースのディレクトリに入り、Meson で Ninja などなどを生成 & ビルドします。 sixel はデフォルトだと無効なの

GObjectについて

この記事では C++ とか Java とかを触ってる人が、 それと同等のコードを GObject 上に構築するにはどうしたらいいのかという視点で解説していきたいと思います。 ただし、一部にそれらの内部実装に関する知識を要する部分があるので、 使ったことがあるというだけでは理解が難しい部分があるかもしれません。 GObject 使おうとしても意外と Web 上に情報がなく…… (これは単に調べるのが下手という説もある)。 GObject とは GObject は C で書かれたユーティリティライブラリである GLib の一部で、 主に GTK の構築に使われているオブジェクトシステム (オブジェクト指向ぽくコード書くフレームワーク) です。 オブジェクト関連の言語機能がない C で簡単に OOP できます。 ……ということになってる (

OBS StudioのPipeWireキャプチャが古いリリースでも動くようにしてみた

今リリースされているバージョンの OBS Studio では Wayland 上で画面キャプチャができない。 OBS の master ブランチには PipeWire を使用した画面キャプチャが入っているので、 それを今のリリースされているバージョンに読ませて画面キャプチャできるようにしてみた。 これを /usr/lib/obs-plugins に置けば使えるはず。 (そのままビルドしただけでは動かないので適当に下みたいなパッチを当てた。) ビルドした linux-capture.so (消えてるかも) sha256: 693caf89788be465dfb813fd2c4662280fa2fbe218900dad3ad6111eec2926a6 適当に新しいやつのソース取ってきてビルドすればいいやんという話ではある。

dbus-glib

https://gitlab.freedesktop.org/dbus/dbus-glib 非推奨だったのか………。GDBus を使えって書いてある。 dbus-send の補完がなんかバグってるなと思ったので直していて、 Merge Request 投げる直前くらいに気づいた (でもせっかくなので投げた)。 https://gitlab.freedesktop.org/dbus/dbus-glib/-/merge_requests/5 dbus-send は DBus の一部なのになぜか Bash completion はこれの一部なのはわけが分からないが、 でもこれが死ぬと dbus-send の補完がなくなってしまうというのはマイナスだなと思った。 (まあなんかいろいろ補完がおかしかったりするのでいろいろ修正した方がよさそうではあるけど。) てなわけで 5 個くらいたまっていた TODO が一応 1 個捌けてよかったと思う。

sha256sumを書いてみた

Wikipedia に sha256 の疑似コード載ってるじゃん1ってことで sha256sum を書いてみた。 sha256.c あと出力されたバイト列見てもどこが間違ってるのか分からないので割と苦労した。 一応気づきとしては、coreutils に入ってる sha256sum コマンドは 相当速くて、かなり頑張ってチューニングしたんだろうなと思った。 どのくらい速いかというと、疑似コード真似しただけのコードだと 1 GiB のファイルの ハッシュに 40 秒強かかるところを、coreutils のそれだと 500 ms くらいで終わる。 coreutils 速いのは知ってるけどここまで歴然とした差があるとかなりびっくりする。 一応 coreutils の sha256sum は gnulib から引っ張ってきてるっぽいので そこへのリンクを。 http://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/sha256.c?id=591f00666450e5e70514d457846af2c8d301af9b FIXME: see sha1.c for a better implementation. とか言っててよく意味が分からん。これ

UTF-8メモ

UTF-8 でマルチバイトになる場合について、実装するときいつも調べてる気がするので メモしておこうかなと。 バイト数 1 バイト目 2 バイト目 3 バイト目 4 バイト目 1 0xxxxxxx - - - 2 110xxxxx 10xxxxxx - - 3 1110xxxx 10xxxxxx 10xxxxxx - 4 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx Unicode のコードポイントは 1 バイト目から順番に x の部分を連結したものになる (一応順番的にはビッグエンディアン)。 規格上は 6 バイトまで考慮されてるらしいが、現状で存在するのは 4 バイトまでっぽい。 絵文字とかあからさまにコードポイント節約しに来てる感あるしな (知らんけど)。 文字数 UTF-8 で文字数と言ったときに僕の理解でも指す概念が 3 つくらいあって、 バイト数 コードポイントの数 見た目の文字数 (サロゲートペアとかを考慮した結果の) 下に行