HHKB Studio レビュー — KaoriYa
2023/10/25発売のHHKB Studioを購入し、構成・構造を細部まで検証したのでレビューします。 注意: 詳細レビューは執筆中で、随時追記しています。ひとまず総評まで読んでいってください。 レビューする私の立場 私はHHKB Studioの購入者です。 特にどこからか提供や依頼を受けてのレビューではありません。 またHHKBの従来品の愛用者でした。 初期のHHKB Professionalから始まり、 Pro 2、Type-S、HYBRID Type-Sまで色違いや予備品も含めて 合計7台を所有しています。 加えて2020年末より自作キーボードに傾倒しました。 短期間で大量のキットを組み立てたり、 自ら回路を設計したり、 ファームウェアを書き起こしたり、 あのKeyballシリーズのファームウェアを担当したり と 自作キーボードとポインティングデバイスに関する一定以上の知見を持っ
golangとDockerとOOM — KaoriYa
golangで書いたプログラムをDockerで動かしOOMが発生した際になるべく情報を残して殺される方法を紹介します。 2020/08/16追記: この記事の内容はgolangに関してはやや現実的ではなくなってしまいました。 詳しくは続編を参照してください。 TL;DR golang製のプログラムは仮想メモリ(VSZ)の確保に失敗するとgoroutineのダンプを吐いて死ぬ DockerのOOMはRSSベースで検出時にSIGKILLを投げてくる Docker利用時にVSZで制限をかけるスクリプトを書いた golang製のプログラムはlinux-amd64において最低でも101MBのVSZを要求する VSZの制限がそれより小さいと当然起動できない 実際のRSSは3MB程度で起動する Background コンテナ内で動いているプロダクション上のgolang製のプログラムが時々OOMに殺されて
Vim の DirectX を速くした話 — KaoriYa
先日の記事 に書いたとおり Vim のカラー絵文字パッチにより、 DirectX (正確には DirectWrite) を用いた画面描画がめちゃくちゃ速くなりました。 その記事にはこんなことを書いていましたね。 そして僕は大きな間違いに気がついた。 詳細を説明はしませんが、一言で言えば「Vimは標準的なWin32アプリではない」 このあたりをちょっと詳細に説明してみようと思います。 なので Vim の話でありながらほとんど Windows の話になります。 しかも無駄に長くなりそうです。(実際なった) なおこの記事は Vim Advent Calendar 2017 3日めの参加記事です。 遅かった理由 速くなった理由を知るには、その前の遅かった理由を知る必要があるでしょう。 まずはそれを見ていきましょう。 DirectWrite には大きく分けて2つの描画方法があります。 GPUの性能を
Vim scriptによるゲームの新アーキテクチャの考察 — KaoriYa
従来のVim scriptによるゲーム作成時の問題点を解消する、 新しいアーキテクチャを考察してみました。 この記事は Vim script Advent Calendar 2015 の 13日目の記事です。 まずは以下のデモ画像(別ウィンドウ)を見てください。 かなりスムーズに○リオが動いています。実はこれ、全部Vim scriptでできています。 ソースコードは koron/vim-ario に置いてありますので、チェックアウトして gvim -S game.vim することで試せます。ただし動作確認・保証は Windows版の +kaoriya な gvim でしかしておりません。また解像度も画面幅1920ドット無いとおかしなことになるので、異なる環境の場合は各自で調整してPRなどしてください。 操作は以下のとおりです。 h - 左ボタンのトグル l - 右ボタンのトグル f - ジ
golang でのクロスコンパイルの留意事項 — KaoriYa
golang (for Windows) でクロスコンパイルする際にハマったポイントと、 解決方法を紹介します。 TL;DR golang のクロスコンパイルを準備する場合には、以下の点に留意してください。 (Windows のみ) gccは32ビット版か64ビット版か、使いたい方を正しく選択する 2つ以上の環境へクロスコンパイルする場合には、make.bat/make.bash 実行時に --no-clean を指定する クロスコンパイルの準備をする golang を用いるとクロスコンパイルが容易なことはよく知られています。例えば、Windows上のgolangであっても、OSX向けのバイナリを生成したり、EdisonやRaspberry Pi用のバイナリを生成できたりするのです。ただし、以下に示す、ちょっとした事前準備が必要です。 環境変数 GOOS, GOARCH を設定し %GOR
fmt (Fprintf/Sprintf) の速度向上実験 — KaoriYa
golang の fmt.Fprintf/Sprintf には、 フォーマット文字列の解釈を最適化することで、 速くする余地があると推測されます。 その推測が正しいか、お手軽な実験を行ってみました。 この記事は Go Advent Calendar 2014 の6日目の記事です。 fmt.Fprintf および Sprint は、実行時にフォーマット文字列を毎回解析するという性質上、パフォーマンスに余計なオーバーヘッドが発生すると言えます。よって、その解析処理をコンパイル時に行えば、大幅にパフォーマンスが改善することは、C言語において kazuho さん(h2oプロジェクト)の h2o/qprintf が証明しています。 今回は qprintf にインスパイアされて、同様のことを golang で行ったらどの程度速くできるのかを、簡単な実験(koron/qfmt)で確認してみました。 方式
Vimが変なファイルを作るようになった — KaoriYa
+kaoriya版として配布しているVimでは デフォルトで undofile がオンになった関係で ファイルの保存時に変な名前のファイルが作成されるようになりました。 その解説をします。 うちで配布している Vim は 7.4.227 から、デフォルトで undofile がオンの状態で配布されるようになりました。そのためデフォルトではファイルを保存した時に同時に.{ファイル名}.un~ を undo ファイルを作成します。この undo ファイルにより Vim は undo の情報をセッションを越えて保持できます。 しかしいきなりゴミのような名前のファイルが生成され、普通のユーザは驚くことでしょう。かく言う私も驚きました。っていうかそのまま間違えてレポジトリに commit しちゃいました。それでは困りますので、無効化する設定などを紹介しておきます。 完全に無効化する こう設定してくだ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
