Emacs標準のスプレッドシートses-modeの使い方メモ

ファイル 拡張子を .ses にすると自動で ses-mode になる。 また、そうじゃないファイルでも一回 ses-mode で保存すれば Local Variables が付けられた状態で保存されるので 次からは自動で ses-mode になる。 ファイル自体は先頭に表示内容が入っていて、その後ろに正式なデータといろいろメタデータが S 式で入っているという感じに見える。 ses-mode 自体のコードは読んでないけど。 セルの追加・削除 適当な表 / C- M- o 行を挿入 列を挿入 k 行を削除 列を削除 ただ、一番右に追加していくみたいな場合は C-i で移動していけば追加されていくし、 下に追加していくみたいな場合には C-j でいけるのであんまり表のキーを使うことはなさそう。 コピペ 普通に M-w とか C-y で。 データの入力 ここが Emacs らしくて面白いと思うのだが

QEMUで雑に作るArch Linux ARMビルド環境

QEMU で起動するのが楽な Alpine Linux で aarch64 な Linux 環境を作り、 その中でブートストラップした Arch Linux ARM に chroot して使ってやろうというもの。 Alpine も Arhc も小さいのでビルドしようとするものによるが、tmpfs だけで戦える可能性が十分ある。 bazel と mozc のビルドをやったが、16 GB メモリのマシンで tmpfs しか使わずに作業が終わった (ビルド後にいらなくなった一時ファイルを消したりはしたが)。 準備 aarch64 の仮想マシンの実行には qemu-arch-extra が必要なので事前に入れておく。 Alpine のイメージを公式サイトから落としておく。 多分どれでもいいが、今回は standard を使った。 UEFI を使うため、edk2-armvirt を入れる。 QEMU のイメージの準備 サイズとかは適当に。後で拡張したりできるので大袈裟に気にす

Chromebook を購入し (て Crostini に Arch Linux を入れ) た話

使ってた iPad のボタンの調子が悪かったので移行先を探していたのですが、 「そういや 2-in-1 の Chromebook とかでいいじゃん」てことで Chromebook 1 を購入しました。 CPU が遅かったり aarch64 だったりで、Linux をちゃんと使おうとすると辛さがあるような気がしているので、 開発環境として使いたかったら x86 系のものを買っておいたほうが良いと思います。 操作感 iPad のかわりにしたくて買ったということもあり、タブレットとして使えるかは割と不安だったんですが、 割といい感じです。キーボードを外すとタッチ用の UI になり、少なくとも最近の Android を使ったことがある人は 操作で迷うということはないと思います。UI 自体もけっこう Android に近い。 Arch Linux を入れる 操作感とかはどうでもよくてこ

Dockerメモいろいろ

コンテナからホストと IP 通信する Linux だとホストは 172.17.0.1 に見える。 Mac や Windows だと host.docker.internal に見えるらしい。試してはないけど。 Compose で特定のサービスだけ recreate する イメージが更新されたときとかに。 # docker compose up -d --force-recreate --no-deps hoge

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

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

エミュレータについて

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

C/C++の単項演算子 + について

C++ で char を std::cout とかで出したいとき、 char hoge = 'a'; std::cout << +hoge; みたいに書くと a じゃなくて 97 が出る。これはなぜなのか。 C11 ではこのように述べられている。 The result of the unary + operator is the value of its (promoted) operand. The integer promotions are performed on the operand, and the result has the promoted type. C++17 ではこのように述べられている。 The operand of the unary + operator shall …(略) Integral promotion is performed on integral or enumeration operands. The type of the result is the type of the promoted operand. というわけで C、C++ 両方で単項演算子 + の結果は汎整数拡張がなされた結果になる。 hoge は char で +hoge は int の型を持つということになり、 operator<< の int オーバーロードが呼ばれ、97 が出力された。 参考にした資料 手元にあった C11 と C++17 の最終ドラフトで確認した。 より新しい規格では仕様が変わっている可能性もある。

EmscriptenでJSとCで相互にデータをやり取りする

Emscripten で JavaScript の世界と C の世界でデータをやり取りする方法をメモ (with ccall/cwrap)。 C や C++ 側で必要なこと Emscripten でコンパイルすると、main から到達できないコードは dead code elimination でサクサク消されちゃうので 関数に EMSCRIPTEN_KEEPALIVE を付けて消されないようにしておく必要がある (EMSCRIPTEN_KEEPALIVE 自体は __attribute__((used)) に展開されるっぽい。環境によるとは思うけど)。 コンパイルは emcc -s WASM=1 -s NO_EXIT_RUNTIME=1 -s EXPORTED_RUNTIME_METHODS="['ccall']" -o index.html main.cc とかで。NO_EXIT_RUNTIME にしておくことで、 main を実行したあとランタイムを止めるというデフォルトの挙動を変更できる。 ExPORTED_RUNTIME_METHODS に cwrap とかを入れておくと cwrap から使えるようになる。 ccall や cwrap で関数を呼び出すときの基本的な方法 Module.cwrap('hoge', 'string', 'number')(5); みたいな感じで C の関数を呼び出せるが、問題は引数と戻り

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 をビッグエンディアンのマシンに持っていったら動かない