Posts

あれ、１月ってありましたっけ？という勢いで１月が終わりました。あれを何月くらいにやろうかな、とか考えてるとすぐに終わっちゃいますね。 今回はちょっと最小限で欲しいEmacs lispのpackageを作って・・・というか作らせてみました。 できたもの とりあえず画像を見るのが一番早いので貼っときます。 こんな感じに、 置換対象のものだけを、置換後とside by sideで見える ってものです。とってもシンプルで単機能です。 モチベーション できたものは、概ね行数としても150行とかなのです。もともとは単純に 置換前後をみたい というものなのですが、これが地味に対応するものがない・・・というところなので、探してました。 より高機能なものとして visual-replace やanzu.elなどがあるのですが、こちらは 検索処理そのものを置換している という課題があります。なんだかんだ、interactiveな検索・置換というのは恐ろしく複雑な行為なので、自作はしたくない・・・。また、標準へのalignが最近のトレンドと考えると、既存の継続的にメンテナンスが行われているlibraryを利用しない、というのもなかなかもったいないことだなーと。 発見と作成 ふとした発見は、 replace-update-post-hook というhookを見つけたことです。これは置換を行う直前くらいで呼び出されるhookで、今回やりたいやつにぴったりでした。 ちょうどよかったので、完全にLLMでやっていい規模だったので、全面的に生成させてます。 全体のデフォルト構成はCopilot Agentに初期生成 実際の実装はClaude Codeでplanさせてから実装 テストの生成/documentもClaude Code 動作確認は自分 という感じで、大体はClaude Codeに生成させたものになります。やっぱり一発では無理で、存在しないlexical変数を使おうとしたり、エラーハンドリングが足りずに C-g でキャンセル・・・とか気の利いた感じにはやはりなりませんでした。 とはいえ、overlayの作成やdefvarの作成といった、Emacs Lispお決まりの管理などを含めると、実際のロジックはほんの2,30行程度、というのが実態でした。やはり色々言われている、 大体定型的な処理になるもの とかは、生成させるのに向いていますね。 Emacs Lispとの向き合い方 Emacs Lispは、Emacsを触るうえで絶対に避けられないものですし、色々な概念が絡み合って、大変に複雑です。しかし、シンプルなpackageを作るとかは、今だと1時間とかあったら、 ボイラープレート的にやるもの を含め、だいぶ楽に作れます。 作れるからといって何でも作る と、それはそれでメンテナンスが不可能になっていくのですが、Unix wayのように、単機能のものをいじったり作ったりする分には、問題はそこまで露出しないかな〜、とも思っています。 Emacsを触ってみるいいチャンスとして、一個気に食わない部分をpackageにしてみる、とかいかがでしょう？

気が付いたら2025年が終わってました。今年の抱負とか考える前に仕事が始まったので、今年もいきあたりばったりに行きていければと思います。 最近Rustで細々と格闘しているんですが、ちょっとやってみたいことがあってやってみたらできたので、小ネタとして残しておこうかと思います。 やりたいこと 諸事情で、代数式をstructとして管理することをしています。毎度ですが、なんでそういうことをしようとしているのか？は聞いてはなりません。 // こんなtraitを定義しておく trait Equation { // envは変数のhashmap fn evaluate(&self, env: &HashMap<String, f32>) -> f32; } こんなtraitを実装したものを考えたいです。なお実装は自明なので省きます。で、これを普通に実装すると、ちょっと複雑になっただけで大変なことになります。 // 3.2 + 3.4 let e = ArithmeticEquation::new(Add, ConstantEquation::new(3.2), ConstantEquation::new(3.4)) // 掛け算とかがnestすると大変なことになる これをなんとかある程度楽にしたい、というのがモチベーションです。 方法の検討 Rustだと、大きく3通りのやり方があると思います。 procedural macroを実装する lexer/parserを利用してparseを実装する operator overloadとstructを駆使して頑張る macroとoperator overloadはcompile時に、lexer/parserは動的になる感じです。最終的にはlexer/parserが必要になりそうなんですが、一旦は静的にできれば（テストを書いたりするときに）便利です。となると、macroかoperator overloadが選択肢になる感じですね。 lexer/parser自体を生成するmacroとかはあるようですが、そもそもparseするという行為自体が、compileした後の話になるので。 Operator overloadを検討してみる RustのOperator overloadは大変に強力である意味シンプルなのですが、 Scopingが困難 です。 KotlinとかのOperator overloadでは、interfaceの実装元とかで切り分けられたり、scoped functionを利用することで、DSL/operator overloadの利用範囲をscopingすることがるできます。 object Ops { operator fun invoke(f: Ops.() -> Unit) { f() } infix fun String.test(rhs: String): boolean {...} } // こんな感じで使える Ops { "hoge" test "foo" } // 外だと明示的なimportが必要。 翻ってRustのOperator overloadは、標準にある Add や Sub といったTraitを型に対して実装する・・・という形です。 ...

気が付いたら11月も終わって師走になりそうですね？一年が年々早くなっていきますな。 この二ヶ月くらい格闘していたものができました。なんかこないだもこの書き出しをした気がしますが気にしてはいけない。 まずは写真 最近は一体型にしてましたが、roBaとかroRaとか人気ですんで、分割型に戻ってきました。やっぱ楽ですね。 スペックはこんなんです。 いつもの40%/42キー 30%はあんまり興味ないので 16.6mmピッチ Choc v2専用 PMW3610センサーを利用したトラックボール 完全無線 単三電池駆動 エンコーダー対応 ケース、キーキャップ、エンコーダー、トラボケース、スイッチプレートまで全部3Dプリンター製 今回発注したのは基盤類だけです それなりの薄さ キートップまで2.2cmです 名前は、それなりに薄さを追求してみよう、ということで ThingnusBall です。いつもどおりケースやらなんやらは以下のリポジトリで公開してます。 https://github.com/derui/ThingnusBall 今回の物理配列 今回ですが、前作った Orbit One を分割型に持っていったような感じにしてます。やっぱ自分の手をそれなりに測って作っただけあって、しっくりきていたのは強いですね。 挟ピッチにしているのは、もはや一回慣れてしまうと、MacBook（仕事用）ですら広く感じてしまいます。キーキャップも自炊（なにか違う気がする）できるようになったということもあり、自由度が上がっています。 キーキャップ 前回は初めて印刷しましたが、今回もうちょっと頑張ってコンベックスとスフェリカルのキーを印刷しました。こんな感じ。 物理になると分かりづらいんですが、コンベックスはちゃんとコンベックスしてます。なお、前回印刷したスフェリカルは指を置く面がちと狭かったので、全面に広げています。なお、色々めんどうなので、 印刷時にはサポートがいらないように 印刷してます。側面を立てる感じにして印刷しているので、どうしてもこういう形だと、底面になる面の角がヌルくなりますね。とはいえ、これが嫌だとすると、 光造形 か 焼結方式 、または射出形成が必要になってくるんではないかと。FDMで軸を下にしてサポートを追加するのはだいぶリスキーです。 DMM.makeで販売されているキーキャップは、大半が焼結方式・・・のはずです。私もちょっとだけ持ってますが、手触りとかいいですよね。高いんですが。 もしかしたらMXキーであれば余裕が出るのかもしれないですが :thinking: 今回は厚さをメインテーマにしたので、そもそもMXは選択肢に入っていませんでしたね。とはいえ、実際に指を置く面はかなり滑らかで、手元にあるNuphyのキーと比較してもひけをとりません（当社比）。 厚さ 前回がトータル4cmくらいの大作になってしまって、尊師スタイルをやろうとしたら 分厚すぎてほぼできなかった :cry: という悲しい現実がありました。 https://salicylic-acid3.hatenablog.com/entry/sonshi-introduction 尊師スタイルはこちらなどを参考に。尊師＝RMSです。色々批判もある方ですが。 前々回も結構分厚かったので、今回は トラックボールのブレイクアウトボード含めて（できるだけ）薄くしよう！ というのを唯一のデザイン目標にしました。 最小の厚さとは？ さて、一般的なキーボード（ロープロ）で実現できる最小の厚みとはどれくらいなのでしょう？一旦以下の条件を前提にして計算してみましょう。 ホットスワップする スイッチプレートを使う choc v2 構成物 厚さ(mm) ソケット 2 基盤 1.6 スイッチプレート 1.5 choc v2 6.4 キーキャップ 3 合計 14.5 (choc v2は軸の頂点まで、キーキャップはキーの軸の頂点から天面まで、です) ...

たまには超小ネタです。 Bevy触ってます ちょいちょい中断しつつですが、bevyというゲームエンジンを触っています。なんというか現代的なゲームエンジンを触るのは実は初めてなんですが、Direct3Dで・・・みたいな時代とは隔世の感がありますね。そもそも古すぎか。 やりたいことのためにWASMで動作するように作っているのですが、 glTF ファイルを読み込ませようとしたら、 .gltf.meta という謎のファイルが要求されてエラーになって困ったことになりました。ちなみにglTFファイルとは、WebGLの標準フォーマットとのことです。 https://knowledge.shade3d.jp/knowledgebase/gltf%E3%81%A8%E3%81%AF 解決 https://github.com/bevyengine/bevy/issues/10157 困ったときは公式のissue、ということで探したらありました。どうもbevy_assetsの機能で、metadataを確認することでより適した処理にできる、とかそういうもののようです。ちなみに生成するためには 一回起動したらいいよ 、とのことですが、WASMの場合そもそも書き込むっつってもどこに？となってしまいます。 app.add_plugins(( DefaultPlugins .set(AssetPlugin { // これを追加する meta_check: AssetMetaCheck::Never, ..default() }), )) issueにあったやり方とは違いますが、meta_checkを無効化するとOKです。私がやりたい範囲ではglTFはほぼ使わないので、これで特に問題なさそうでした。

前々から書こう書こうって思ってましたが、やっと重い腰を上げました。 結構前からやっていたものの、そもそもglidepointが使えなかったので日の目を見なかったやつです。 html: <!–more–> 元々のfirmware cirque pinnacleについては、元々zmkfirmwareの主要開発者が作成しているものがあります。 https://github.com/petejohanson/cirque-input-module 最初はこれを利用していたのですが、色々と機能を追加したくなってきたため、forkしています。 https://github.com/derui/cirque-input-module 改造したこと まず、absolute modeを有効にしたかったので、このPRを取り込みました。なぜabsolute modeがやりたかったのか・・・？というところなのですが、Glidepointは円形のpadをしているなかで、「どういうふうにスクロールさせたら丁度いいのか」と考えたところ、大きく２つの案が出ました。 トラックパッドよろしく二本指でスクロールする Windowsとかのトラックパッドにある、エッジ部分のスライドでスクロールする この内、前者については、glidepointの基本モードである relative mode において対応できるのですが、二番目をやろうとすると、edge検出が必要なので、絶対座標が必要になります。で、今回はせっかくなのでedgeで指をくるくる回したらスクロールするようにしてみたかったのです。 エッジスクロールの実装 実装としては以下のPRになります。 https://github.com/derui/cirque-input-module/pull/1 いくつか使いづらい点などもあったので、追加で改造していますが、基本的には以下のように動作します。 所定の位置が最初のtouchであるかを確認する touchされているが、所定の位置でない場合は、次にtouchされるまで何もしない 所定の位置である場合、初期化 次にカーソルを動かしたら、 一つ前の位置との角度を取る 該当の角度（ラジアン）に対応する方向にスクロールのイベントを発行 と、結構シンプルな作りにしています。 加速度をベースにしたカーソル移動 Macbook/Appleのトラックパッドなど、現代のトラックパッドは基本的に加速度ベースでカーソルを移動しています。ゆーっくり指を動かしてトラックパッドを横断したときと、シュッと横断したときでは移動量が違うのがわかるかと思います。 オリジナルの実装では、シンプルに移動量がそのままわたっている形になっていましたが、ゆっくり動かそうとしても機敏すぎてつかいづらい・・・というのがありました。 加速度については、relative modeでもわかるのですが、改めて実装しています。なお、実装方針などはClaude Codeで確認しながら実装しました。こういう数式のパターンにハマりやすいのは、調べるより早いですね。 ただ、加速度ベースの移動は、いい塩梅を探すのが大変難しい・・・という難題があります。これについては継続して確認しているところではあります。Xiaoのリセット難易度が大変高いの、なんとかなりまへんかね 🤔 firmwareは怖くない（間違うと怖いけど） 最近のC言語は、古とは違って制約も少なくなり、だいぶ書きやすくなってます。zmkの場合は、複雑になりがちなポインタのポインタ・・・といったものがAPI上に登場することも少なく、だいぶ素直だと思います。zephyrから来ているマクロを把握するほうがよほど大変という・・・。 ちょっとここが・・・というのがあれば、当然オリジナルへの還元も視野に入れつつ、自分でいじってみるのも一興ではないでしょうか。

残暑が残暑というか「普通に夏だね？」って感じですね。もう暑いのはいいです。 この２ヶ月くらい格闘してたものができましたので、それについて書こうかと思います。 ...

今年の夏も明らかに暑いですね。これが撹乱なのか、それとも定常になるのか・・・。 最近いいおもちゃを手に入れたので、それを使ってみたよ、という話です。 ...

なんというか色々と騒がしい世間、いかがお過ごしでしょうか。 さて、ここ数ヶ月かけて作っていたものがやっと完成したので、それについて書いていこうと思います。 ...

すっかり初夏の感じになってきました。半年すぎるのが早すぎます。 すっかり間が空いてしまいましたが、今回は最近のお仕事で使ってるものとかを簡単に書いてみようかと思います。 ...

気づいたら新入社員が入って来てました。3月はどこに行った？ :thinking: 3月はずっとタイトルにあるものを作っていました。やっと形になったので、記事にしてみます。 ...