Posts

久々(約４年振り)に眼鏡を新調しました。といっても注文して決済しただけで、まだ受け取っていないのですが。 さて、今回はEmacsの補完をivyから完全に切り替えたのでその話を書こうと思います。とはいえかなりライトなお話ですが。 <!–more–> 補完インターフェースの遍歴 なんだかんだ、Emacs(Meadow含め)を使いつづけて早1x年が経過してますが、その間に補完インターフェースはその時々のトレンドに乗ってきました。 Anything Helm Ivy Ivy + posframeもやったりしました selectrum どちらかというと個人的にはこだわりはないので、そのときどきで一番勢いがあるものに乗っかることで楽をしている感じですね。 今回の変更先 ついこの間まではivyからselectrum + consultとなっていましたが、以下の記事を見て、ご他聞に漏れずverticoに変更することにしました。仕事でもそうですが、標準に乗っかるって大事ですね。 https://blog.tomoya.dev/posts/a-new-wave-has-arrived-at-emacs/ selectrumからverticoへの変更 さて、実際に乗り換えたのはインターフェースだけなので、selectrumからverticoへの移行のみが焦点となりました。 ・・・が、そもそもほとんどカスタマイズが不要な状態で(唯一やっていたのはmini-frameくらい)利用していたので、正直ほとんど変更することもなかったです 実際に設定中でもたったこんだけです。 (leaf vertico :straight t :custom ;; 最大20件まで表示するように (vertico-count . 20) :config (vertico-mode)) 個人的には、Interfaceとかはあんまりいじりすぎないようにしています。よほど色がどぎついとかそういうのは弄りますけど。 mini-frameを利用しないようにした理由 さて、selectrumを利用していたとき、ivy-posframeを利用していたのと同じ感じで利用できれば、ということでemacs-mini-frameを利用していました。 しかし、これはこれで結構難点がありました。 現在の視点に関わらず、常に一定の場所に表示される ivy-posframeとかだと、カーソルのそばとかに表示できたりします 配色の問題だが、borderlessなので一瞬境目を見失う といったものが日々利用する上でだんだんストレスになっていました。固定位置なのであれば、正直minibufferを見るのと変わらんやん・・・ということもあり、verticoへの移行を期に削除しています。 migemoるようにした 今回、orderlessとverticoを導入したことで、emacsの補完システム(実はかなり充実している)を利用する形で、結構お手軽に変更できるようになっています。 https://nyoho.jp/diary/?date=20210615 こちらの記事を参考、というかほぼ丸パクリさせていただいて(多少アレンジはしてます)、無事consultでもmigemoることに成功しました。最近はorg-roamでメモを取るようにしているので、ファイル名とかを日本語検索するのが億劫になっていたところだったので・・・。ちなみにmigemoは自作のmigemocamlを利用しています。 そういえば、単独でdictを生成できるようにしたのに、まったく記事を書いていないので、これについては後程記事にしようと思います。 軽快・快適な補完生活を 現在、Emacsのpgtkブランチを利用することで、 Wayland native + native compileな環境を利用できるようになり、かなりEmacs上が快適になっています。これだけ快適になると、さらにVSCodeとかに移行するモチベーションが無くなるのが困ったところですね。 とはいえ、快適な補完は現代的な生活における必需品だと思います。Spacemacsとかではなく、vanillaのEmacsを利用している方は、是非これらのパッケージを利用してみることをお勧めします。快適ですよ。

大分前に購入していたけど、ほとんどやっていなかったshapez.ioというゲームを久し振りにやったら、ずっと黙々とやってしまいました。これは時間が溶ける系統や・・・。 さて、今回もライトな話題で、Linuxでの音楽鑑賞をどうやっているか、について書いてみようと思います。 <!–more–> GUI or CUI まず、Linuxでのプレイヤーとしては、CUIベースかGUIベースか、に大別されます。 CUIベース mplayer mpv GUIベース smplayer celluloid VLC …など CUIベースであるmplayer/mpvは、他のplayerのバックエンドとして利用されている(smplayerやcelluloidといったものは、mplayer/mpvのフロントエンドです)ので、実際には本当にインターフェースがCUIなのかGUIベースなのか、という違い程度だと思います。 Spotifyとかは？ 私は基本的にオールドタイプなので、ストリーミング(有料会員ならオフラインにダウンロードとかできるらしいですが)で聞く、というのは基本的にやってません。購入した楽曲は手元に置いておきたい、という感じですね・・・。 Youtubeとかで見つけても、その後には楽曲をあらためて別サイトで購入したりするのが私にとっては一般的です。 楽曲の保存 基本的に全ての楽曲はNASに保存しています。ちなみに使っているNASは二代目で、以下を使っています。 https://www.synology.com/ja-jp/products/DS218 これに、WesternDegitalのNASむけHDDを組み合わせて利用しています。 LinuxとはNFSで接続できるので、まー特に問題ありません。Windowsとの相互運用も問題ないので、普通にWindows機とのファイルのやりとりにも利用しています。 何を利用しているのか 私は上記に書いたプレイヤー全部を利用したことがありますが、現状は以下のような形に落ち着いています。 音楽をディレクトリごととかで再生する mpv 動画や、頻繁にシークする音楽ファイルを再生する celluloid プレイリストを見たい celluloid mpvでもシークはできるんですが、どうしても視覚的に直感的ではないため、シークが頻繁におこなわれるものとしてはcelluloidを利用しています。あと、動画とかを一気に見たりする場合は、プレイリストとして常に表示できるGUIの方が便利です。 まぁ、最近は動画についてはストリーミングでしか見ていないので、ほとんどcelluloidは使っていないのですが・・・。 なぜCUIを利用するのか 私が思うCUIの楽さ加減としては、 tmuxとかのターミナルマルチプレクサと併用すれば、裏で流しっ放しにできる ディレクトリ内を一括で入れたりするのが簡単 ファイル数が多すぎると、コマンドラインの最大長を超える可能性もありますが GUIが無いのでとても軽い という点です。私の環境ではWMとしてswayを利用しているので、GUIを起動するとどうしても邪魔になりやすい、というのがあります。 floating windowは、場所をずらしたり調整したり、後邪魔になったときに避けないといけないので、あんまり利用してません。 他の人はどうやってるんだろう 最近はもう基本的にストリーミングサービスを利用している、という方が大半だとは思います。私は今でも専用のメディアプレイヤーにmp3なりを突っ込んで聞いている、という人なので、基本的にはオフラインで聞けることを優先しています。 ストリーミングを利用している人の場合、基本的にはそのサービスのクライアントを利用するんだと思いますが、それって無駄に重いし邪魔じゃない？という思いもあります。機会があれば聞いてみようかなー、と思います。(私の周辺はみんなオールドタイプなので)

気付けば今年ももうそろそろ半分が終わろうとしている、という恐怖の事態。なんか毎年言っている気がしますが。年々早くなっている気がしますな。 今回はライトな話題で、org-roamでjournalを書くようにしてみている話です。 <!–more–> org-roamとは まずパッケージの紹介ですが、 org-roam というパッケージがあります。これは、Roam Researchというサービスをorgに移植したものです。 Roam Researchというサービスは、 Zettelkasten Method というメモの方法論を基に実装されたようで、色々なメモを有機的に結合することで、知識の整理や発想を促す・・・という感じのもののようです。 org-roamはローカルでだけ動作するので、特にサーバーとか不要で、orgファイルさえ共有できれば、どこでも利用できるというのが強みですね。 ただし、検索速度とかを向上させるために、sqlite3を利用しているのと、グラフを作成するのにgraphizを利用しているので、それらが利用できるプラットフォームである必要があります。 最近のメモとかは基本的にすべてorg-roamに書き溜めるようにしています、が、リンクをするのがめんどくさいなど、いくつか課題がありますが・・・ org-roamのjournaling機能 org-roamは、org-modeよろしく非常に多彩な機能が含まれていますが、その中に dailies という機能があります。 https://www.orgroam.com/manual.html#Daily_002dnotes org-journalほどは機能があるわけではないけど、必要最低限の機能はあって、かつroamと統合されている・・・というようなのが特徴です。 今の私の設定はこんな感じになってます。 (leaf org-roam :after org :straight t :if (and (file-exists-p my:org-roam-directory)) :custom ((org-roam-db-update-method . 'immediate) (org-roam-db-location . my:org-roam-db-location) (org-roam-directory . my:org-roam-directory) (org-roam-index-file . my:org-roam-index-file) ;; dailiesを保存するdirectory (org-roam-dailies-directory . my:org-roam-dailies-directory) (org-roam-capture-templates . '(("d" "default" plain (function org-roam--capture-get-point) "%?" :file-name "%(format-time-string \"%Y-%m-%d--%H-%M-%SZ--${slug}\" (current-time) t)" :head "#+title: ${title}\n- tags :: " :unnarrowed t))) ;; dailiesのcapture (org-roam-dailies-capture-templates . '(("d" "default" entry #'org-roam--capture-get-point "* %<%H:%M>\n%?" :file-name "daily/%<%Y-%m-%d>" :head "#+title: %<%Y-%m-%d>\n" :olp ("Journal"))))) :bind ((:org-mode-map :package org ("C-c r" . org-roam-insert))) :hook (after-init-hook . org-roam-mode)) この設定だと、captureを起動すると、 ...

在宅が始まってから、大分コーヒーの量(ただしかなり薄い)が増えてたので、ちょっとカフェインの摂取量を減らしてみました。まだやりはじめなので、効果が出るまではまだまだかなー。 ちょっと仕事が忙しい & 実装がいまいち進んでなくて書くことが無いので、埋め草的に、ちょうど半年が経過した引越しについて振り返ってみようかと思います。 <!–more–> 引越し遍歴 そういえばあんまり気にしてなかったんですが、社会人になってからの引越しを思いだしてみます。私はめんどくさいのが嫌いなので、基本的に引越しにはかなり腰が重い方です。なので件数は少ないですね。 築xx年、は入居時点です 一部屋目 築12年ワンルームでした。約5.5畳で、風呂・トイレがセットになっていましたね。ここはとにかく日当たりが悪く、朝の30分以外は日光が当たらないような場所でした。 学生の時に住んでいたアパートも似たようなもんでしたが。 約4年半ほど住んでいました。 二部屋目 築25年の1Kでした。約6.5畳(ただし0.5畳が中途半端な状態だったので、事実上6畳。ここは風呂・トイレ別になっていて、初のオール電化物件でした。 実家もオール電化ですが、自分の部屋がオール電化になると、やっぱりよい点が色々ありました。ちなみに、私はこの部屋に引っ越すまで自分の冷蔵庫というものがなかったので、引越し直後に慌ててヨドバシに走った記憶があります。 お湯がすぐ出る IHなので火力とかも大体問題なし ただ、その分電気料金が結構いくので、まー最終的にはトントンくらいでした。また、この部屋は大通りに面している場所だったので、一日中車の音がしている、というのは、慣れててもやっぱりうーんと思うときはありました。 この部屋は今迄で一番日当たりがよく(南西向き)、初めて5階という階層を経験しました。周囲に5階建以上の建物がほとんどなく、窓から日光がサンサンと降り注いでくれたので、 もう夏はサウナ でした。後冬でも暖房がいらんときが多々ありましたね。 約8年半住んでいました。途中で管理会社が変わったりと色々ありました。 今の部屋さがし 部屋探しは、約3週間程度かけておこないました。ちょっと特殊な要件があったので、まず前提となる物件が少なく、ネットだと限界があるなー・・・と思ったので、 https://www.heyagime.com/ ここに予約して行ってみることにしました。都合3回行きましたが、3回目は書類の記載をしに行ったので、事実上2回です。色々提案してくれたり、隠れ物件を紹介してくれたりと、かなり満足度が高かったのでオススメです。 ちなみに私はあんまり迷うことが無い質で、大体一回内見に行ったら決めてしまいます。要件が特殊でそもそも選べないんじゃーというのもあるんですが。 なお、実際に部屋を決めてから引越しまでは3週間ほど空いています。これは、その当時マンションのエレベーターが工事中だったためで、さすがに5階から荷物を運び出してもらうのは・・・ということで、伸ばしました。今の部屋が一ヶ月のフリーレントがあったので、お金的にはそれほど痛くなかったのが幸いでした。 2020/10〜11 くらいで話を聞いた感じでは、結構フリーレントは多い、という話でした。まず入居してもらわないと始まらない、ということのようです 荷造り & 手続 ここが一番大変というかめんどくさく、元々居住空間が1畳ちょっとしか無いような状況(ゴミが多いとかではなく、テーブルとベッド + レンジ台 + スチールラックでこうなってました)だったので、まずは不用品を捨てていくところからでした。多分人生で一番物を捨てましたね。十年以上共にしたベットもここで廃棄しています。 3週間もあけておいてよかった・・・と本気で思ったのは言うまでもありません。ただ、実際には引越し日になってもまだ終わりきっておらず、業者がうまく予定をしきれておらず、午前中予定が昼から、となったので、最後に終わらせることができた、というのが実態でした・・・。 この荷造りがあるので、引越しが面倒すぎるというのが本音ですね。手続系統もめんどくさいですが、なんというかコロナのおかげで窓口がえらいガラガラだったので、移動時間の方が長いくらいで終わりました。一番面倒なのはクレカとか銀行とかの住所変更ですね。多分まだ変更しきれてないのがいくつかある。 引越し〜 引越し自体は、業者がテキパキとやってくれたので、搬出と搬入で合計1時間くらいしかかかってなかったんじゃないでしょうか。むしろそこから自分で出したりする方が時間かかった気がする・・・。 引っ越した部屋は今迄で一番築浅なので、色々と見たことがないものがついていました。 24時間換気(初めてみた) 画面つきインターフォン 前の部屋のインターフォンは多分4年くらいずっと壊れていたので、鳴ること自体が新鮮でした 自動湯沸器 風呂を自動で入れてくれるやつとか ただ、24時間換気は考えものだなーとも思いました。今の建物は高断熱高気密になっているので、これがないと循環しない(そしてまた大通り沿いなので窓が開けづらい)のはわかるんですが、冬の超乾燥している空気が遠慮なく入ってくるので、 部屋が乾燥しすぎて寝られない というのを経験しました。 引越してから買ったものリスト 部屋を引っ越してから、なんか色々と古くなっているものを買いかえたり買ったりとしました。リストにしてみましょう。 自作PC 前書きました。完全に新しくしました ダイキンの空気清浄機 加湿機能付を買いました。買った直後に除湿・加湿機能付きが出たので、そっちにしとけばよかったと思う6月直前です スピーカー 元々のスピーカーが8年くらい使っていたので、リファインしました Boseとどっちにしようか悩みましたが、あんまり低音が効きすぎるのもどうかと思ったので、バランスのとれたこっちにしてます 4Kモニター x 2 モニターアーム x 2もセットです 24inch x 2から 27inch x 2にレベルアップしました。机のサイズと部屋のサイズ的にはこれが上限ですね フライパンとか せっかくガスコンロになったので、鉄フライパンを購入してみました。扱いは難しいですが、ちゃんと使えると楽しいです。 PS5 当たりました。 特に空気清浄機は、冬の超乾燥に対抗する手段としてきっちり役に立ってくれました。現状花粉症とかでは無いので、それ以外だとまぁつけておくか・・・くらいですが。 ...

去年のGWに何をやっていたか全く記憶が無いんですが、今年も特に何もないGWになりそうですね。なんだかなぁ、という気分しかありませんが。 そんな状態ですが、最近チマチマと作っているOCamlでのScheme処理系で、Monadic Parserを作ってみたので、その紹介をちょっとできれば。 <!–more–> Monadic parserとは まずMonadic parserとは何か、ですが、あんまり明確な定義は無いというか、名は体を表すというか、そのまんまというか。モナドを利用したparserです。HaskellのParsecが有名ですね。 基本的には、 関数で構成されている モナド則により合成可能である という感じかなー、と。理論的な背景はあんまり理解しきれていないので、あくまで私の理解ではありますが。 OCamlのapplicable let Haskellだと、Monadの記述にとても役立つ、 do記法 というのがあります。OCamlには長らくそういうのがなく、PPXとかで各ライブラリごとに拡張を書いていたり、ppx_letのように汎用的な拡張を利用したり・・・というのが必要でした。 が、OCamlの4.08？くらいで導入された Applicable let というのを利用すると、do記法と同じような記述を、OCamlらしく記述することができます。 module Nanika_monad = ... let ( let* ) v f = Nanika_monad.bind f v let () = let* v = Nanika_monad.return v in ... applicable letと言っても、なんてことのない関数定義です。 let* とかだけではなく、 let+ みたいなものも定義できます(定義の中身は、定義の実装者次第です)。letが定義できるということで、同時に and* のような関数も定義することができます。 これですが、 >>= での結合をほぼそのまま変換することができ、逐次処理のように見せることができます。記号で繋げまくっていくのも楽しいですが、後から見たときに処理が明瞭になるので、最近はMonadとかを利用するときはこれを使ってます。 Applicative ParserではなくMonadic Parserになる理由 Monadic Parserとはよく呼ばれるけど、 Applicative Parser というのが無い理由ですが、これはシンプルで、 Applicableだとパースできないものが沢山ある から、という理由のようです。 具体的な例は、もっとよく説明しているサイトを参考にするのがよいと思います。私の浅い理解だと、 Applicableだと、繰り返しやバックトラックといった挙動を定義することができない 前の値を利用する、というようなことができない ため、そもそもパーサーという目的には機能が足りないのでApplicative Parserというものは事実上作成されない、ということのようです。よりシンプルなパースができればいいのであれば、Applicative Parserとかも作れると思います。 ...

今年は桜を見に行きました。以外と近くの公園が綺麗に咲いていたので、特に留まるとかはせずに歩きながら、ですが。酒を飲んだりする花見、なんてやったことないなぁ・・・。 相変わらず在宅ワークの日々ですが、ディスプレイの配置を6、7年振りに変更しました。その話をさらーっと書いてみます。 <!–more–> まずは現状を 今のディスプレイ配置ですが、こんな感じになりました。手前にあるAlienwareは気にしない方向で。ディスプレイのサイズですが、24.5inchです。いずれ27inchにしたい。 モニターアームとしては、以下を利用しています。エルゴトロンのOEMであるAmazon Basicのやつです。 ただ、デュアルディスプレイ用のものではなく、シングル用のを二つ購入しています。これは後述します。 なぜこの配置か？ 以前は、通常あるデュアルディスプレイの配置にしていました。外部サイトの画像ですがこんな感じ。 デュアルディスプレイ用のアームとかであるような、視線が二つのディスプレイの間にあるような感じでした。実際、初めてデュアルディスプレイにしてからずっとこの形でした。しかし、在宅が始まってから、この配置だとちょっと都合が悪いケースが増えてきました。 MacBook(社から支給されている)と繋げているのは左側だけ メインの作業領域が(広いので)繋げたディスプレイになっている 仕事中、首がずっと左側を向いている状態になっている また、仕事中でなくとも、エディタがあるのは大抵どちらか一方なので、結構な時間そちらの方に首が向いている形になっていました。同じ方向に首を曲げ続ける、というのは結構な負荷になっていたとは思いますが、今までは在宅とかなかったので、そこまで長時間その体勢になっているということはありませんでした。 しかし、在宅で長時間その体勢になるようになったことで、結構体に対する負荷がかかってきていることに気付いたので、ちょっと試行錯誤した結果が前掲した画像のスタイルになったわけです。 配置の制約と検討 メインの作業領域はどうせ一つの画面に集約されるので、そのディスプレイは自分の正面に配置することがほぼ確定します。そうなると、24inchだと約60cmくらいの領域が正面を占めます。そうなると、もう一つのディスプレイをどう配置するのか？という問題になってきます。 配置にあたって、私の机やスタイル上、以下のような制約を設けています。 机の右端にPS5が置いてある 正面のディスプレイは仕事/Alienwareからの出力で使う なのでHDMI端子が埋まってる DisplayPortはデスクトップが全部使ってる 上の制約を満たしつつ、私の机のサイズを勘案すると、配置は概ね以下のいずれかにすることに決めました。 縦に２画面並べる 横に角度を付けて置く ただ、縦に並べる、ということも考察してみたんですが、それを成立させるためのアームがわりと特殊なものになる(=汎用性が無い)ため、早々と検討リストから脱落しました。そうなると横に角度を付けて配置する、という話になります。が、24inchとはいえ、横にしたまま配置するとかなりの威圧感があります。かつ、全体を視線に入れるためには、結局かなり首を曲げなければなりませんでした。もう自分の椅子ごと向いた方が早いくらい。 さてではどうしようか・・・ 縦にするというパターン 情報収集とかで見るwebサイトなどは、縦にした方がサイトとかの情報量は多くなる傾向があります。デザイン上横幅が決まっているサイトだとスペースが空いてしまうし、文字が折り返されたとしても、長すぎると始点を見失うので、横に長すぎても情報の閲覧という意味ではそこまで強みがあるわけでもありません。 そうなると、縦にする、ということが選択肢に上がってきます。特にモニターアームを使うことが前提(机のスペース問題上、スタンドを置くというのはちょっと無理なので)であったので、縦にする分には問題はありません。 また、PS5をやるときは、ディスプレイを横に回してしまえば無問題です。どうせゲームをやるときはそっちに体を向けるので、角度が付いていることも問題ではなくなります。 シングルのモニターアームを二つ使う さて、そうなると今度は、それができるモニターアーム探しですが・・・。これがわりと難しいです。 24inchのディスプレイの幅は約56cmあります、それが正面にあるということは、少なくともアームの長さが60cmはないと、正面にあるディスプレイの横に置けなくなります。が、一般的なデュアルディスプレイ用のアームだと、これを満たしそうなものがありませんでした。あっても、今度はディスプレイがかなり前に来たりして、非常にやりづらい感じになってしまいました。 実際、以前使っていたアームだとその配置にするのが不可能でした。 そこで、配置に関する記事を漁っていたところ、 シングルのアームを二つ使えばいい という、目からウロコのアイデアを頂きました。そりゃそうか、という感じですね。Amazon basicのアームは、ちょうど二個一で注文できたので、それを注文して設置をしました。結果が最初の画像です。 この配置にすることで、 メインは、首を曲げずに正面に設置できる サブは縦にして、情報を表示できる 縦に長いのを利用して、ターミナルとブラウザを縦にしたりして、とかもやりやすいです PS5をやるときはクルッと横向きにできる 油断するとディスプレイ同士がぶつかりそうなサイズ感なので、ちょっと注意は必要ですが という、前述の制約を満たしつつ、配置を改善することができました。やったぜ。 シングルを使う利点 Amazon Basicのアームは、耐荷重が11kgとかあります。また、27inchとかでも普通に利用できます。デュアルディスプレイ用だと、ディスプレイが大きくなると配置上の自由度はかなり小さくなりますが、シングルなら設置場所を調整することも容易です。 下手にデュアルディスプレイ用を使うよりも、シングルを二つ利用するほうがいいな・・・という認識になりました。いいよこれ。 おまけ: Swayで縦ディスプレイを使う 私のメイン環境はSway、つまりWayland nativeに完全移行していますが、Swayだと縦ディスプレイにしても何の問題もなく表示してくれます。表示する場合、swayのconfigで、outputにtransformを指定するだけでできます。 output DP-1 { pos 1920 0 mode 1920x1080@119.982002Hz transform 270 } transformがミソで、デフォルトの状態を0としたときに、右回りに回転する角度を指定する形です。ここを指定したり、 swaymsg を使ったりすれば、ディスプレイのローテートに合わせて自動的に向きを変える・・・なんてこともできそうです。 ...

今年の桜前線は大分早く、今の時点でほぼ満開、となっていますね。この調子だと土日でがっつり散ってしまいそうな感じです。 さて、タイトルにもありますが、ゲーミングノートを更新したので、たまには箸にも棒にもかからない話ではなく、開封の儀とかを載せてみようと思います。 <!–more–> まずは画像を どのブランドのものを購入したか、はこの画像をみたら一発でわかります。 でーん。はい、Alienwareでした。AlienwareのM15 R4フルカスタマイズ、を今回購入しました。 上の箱を開くと、こんな感じです。15inchを表す意匠がありますね。15というか13に見えたりしなくもない・・・。 前まで使っていたノート MSIのGS75になります。実家に持って帰れるサイズと重量、ということで、3kgとかするような重量級は最初からアウトオブ眼中なのはあしからず・・・。 ちなみにこれも別段悪いわけではないです。ただ、後述するようにちょっと問題があり、CPUはBoostをかけられない、という制約がありました。でも17インチ相当の画面ながら、15インチとほぼ変わらないサイズ感は、かなり魅力的でした。 購入した直後にSUPERが発売されて、悲しい思いをしたのは秘密です。 購入したノートのスペック Corei7-10870H 32GB DDR4 1TB PCIe M.2 SSD NVIDIA GeForce RTX 3070 8GB 4K有機EL これ以外のオプションは全部オフってます しめて税込約x0万・・・なんですが、これはクーポンが有効になって16%Offになっているときの値段なので、実際にはもっと高いです。 今回、初めて4K有機ELのディスプレイを購入してみました。個人的に光沢ディスプレイは嫌いなんですが、まぁ最悪半光沢にするフィルムを貼ればいいや・・・、ということで、4Kに挑戦してみました。 まだ届いたばっかで、ブラウザとかしか見ていないんですが、確かにフォントのくっきりさ具合とかが、あんまり気にしない私でもはっきりと違いが感じられる程度には違いました。 何で3080じゃないの？ Alienware M15 R4には、3080のオプションがあります。今回これを選択しなかった理由は、 たけぇ +10万です しかし、ノート用のspecなので、VRAM 8GB 価格帯性能比を考えると、同じVRAMで3070の方が7万くらい安い そもそも3080が必要なほどのゲームをしない 4Kのリフレッシュレートは60Hzです。それでもそもそも厳しい という感じです。特に、価格帯性能比の割合が強いですね。3080にしたところで排熱が追いつかなければ宝の持ち腐れでしかないです。 なぜAlienware？ この4年くらい、ゲーミングノートは大抵MSIにしていました。理由としては、2kg前後の重量で、十分な性能と実績があるのが、MSIだったから、という感じです。Asusとかでもよかったんですが、どうもキワモノの印象が強かったです。 しかし、今回買い替えるにあたって、色々なレビューサイトを巡り巡ったところ、MSI/Asusは、排熱に問題を抱えている・・・という話題が多くありました。確かに、MSIを使っていたときも、特にCPUの熱があまりに大きいので、電源設定を変更してCPUにboostさせないようにしていた、ということがあります。というかそうしないと、CPUファンの音が危険なレベルに達してしまうので・・・。 今回はAsusにしようかなー、とも思っていたのですが、狙っていたモデルのレビューが芳しくない・・・。と思っていたところで、Alienwareのレビューを見たところ、排熱がかなり改善されてきており、R4ではさらに改善されている・・・、という記事を見付けました。 これが決め手になり、初のAlienware、個人では10年振りにDellからPCを購入することと相成りました。 これから とりあえずSteamとDiscordは入れたので、ぼちぼちゲームをやっていこうかな、と思います。後はWSL2を入れたりー、とかもしますが、それはまた後で・・・。 いまどきのゲーミングノートは、Macbookと然程変わらない重量で、30X0系統が載るようになっていますんで、お財布に余裕があれば検討してみちゃーいかがでしょうか。

ふと気づいたら、転職して一年経過していました。一年のほとんどがコロナ影響下にあったのは、まーいい経験になったなーと。 さて、最近Emacsのinit.elをorgで書くようにしてみたのと、ちょっとした工夫をしてみたので、それについて書いてみます。 <!–more–> なぜinit.elをorgファイルにするのか やってみたかったから 身も蓋もない理由ですが、とりあえずは上の理由が一番に挙げられます。しかし、ちゃんとした利点もあります。 org-modeの強力な編集機能を使える コードブロックの周辺にコメントとして残すよりも表現力が高いですし、リンクとかもさっくり貼れます 折り畳みが自然にできる org-modeなので 部分での管理が楽 まぁいくつか理由はありますが、orgファイルにすることで、多少でも見通しがよくなるので。 init.elをinit.orgに変更する方法 org-modeには、babelという、色々な言語のコードブロックを、org-modeの中で実行するための枠組みを提供するlispが含まれています。 こいつを使うと、org-modeに書いたemacs lispを簡単にinit.elにすることができます。というかorg-mode公式で紹介していたりします。 私のデフォルトのinit.elは、今これしか書いてません。 https://github.com/derui/dot.emacs.d/blob/master/init.el (require 'org) ;; Do always overwrite init.el from generated source from init.org (org-babel-tangle-file (expand-file-name "init.org" user-emacs-directory) (expand-file-name "init.el" user-emacs-directory)) (load (expand-file-name "init.el" user-emacs-directory)) (message "Once kill emacs for apply new init.el written from init.org") (kill-emacs) org-babel-tangle-file という関数で、orgファイルにあるコードブロックを、指定したファイルに書き出すことができます。対象のorgファイルにemacs lispしか書いていなければ、吐き出されるのもemacs lispになります。 まー、私が書くよりも、すでに色んなところでこれよりも細かく記述されているので、参考サイトに挙げたサイトを見てみることをオススメします。 orgからinit.elを生成した場合の注意点 さて、これで起動するとinit.orgからinit.elが生成できるわけですが、最初に生成した場合、色々と問題が発生するケースがあります。 straight.elとかで最新のorgを入れていたりする場合、大抵上手く動きません 上が影響して、他のパッケージも上手く動かない場合があります そのため、私のinit.elでは、起動して読み込み終わった直後に死ぬようにしてあります。初回だけすぐ終了してしまいますが、どうせ一回終了しないと正しく起動しないので・・・。 init.elの初期化めんどくさい問題 一度生成されたinit.elは、当然ながらinit.orgを読み込むようには(大抵)なっていません。そうなると、init.orgの内容をちゃんと反映させる場合、以下のような手順を踏む必要があります。 init.orgを編集する init.elの内容を元にもどす git checkout などで Emacsを再起動するか、init.elを読み込む 特に2がめんどくさいです。ぶっちゃけ、init.orgを更新したらinit.elを初期化しておいてもらいたいです。 ということで、以下のような設定を追加しています。(実際は、 after-save-hook ではなく、自作関数を登録する専用のhookを用意しています) ...

ふと気づいたら、転職して一年経過していました。一年のほとんどがコロナ影響下にあったのは、まーいい経験になったなーと。 さて、最近Emacsのinit.elをorgで書くようにしてみたのと、ちょっとした工夫をしてみたので、それについて書いてみます。 <!–more–> なぜinit.elをorgファイルにするのか やってみたかったから 身も蓋もない理由ですが、とりあえずは上の理由が一番に挙げられます。しかし、ちゃんとした利点もあります。 org-modeの強力な編集機能を使える コードブロックの周辺にコメントとして残すよりも表現力が高いですし、リンクとかもさっくり貼れます 折り畳みが自然にできる org-modeなので 部分での管理が楽 まぁいくつか理由はありますが、orgファイルにすることで、多少でも見通しがよくなるので。 init.elをinit.orgに変更する方法 org-modeには、babelという、色々な言語のコードブロックを、org-modeの中で実行するための枠組みを提供するlispが含まれています。 こいつを使うと、org-modeに書いたemacs lispを簡単にinit.elにすることができます。というかorg-mode公式で紹介していたりします。 私のデフォルトのinit.elは、今これしか書いてません。 https://github.com/derui/dot.emacs.d/blob/master/init.el (require 'org) ;; Do always overwrite init.el from generated source from init.org (org-babel-tangle-file (expand-file-name "init.org" user-emacs-directory) (expand-file-name "init.el" user-emacs-directory)) (load (expand-file-name "init.el" user-emacs-directory)) (message "Once kill emacs for apply new init.el written from init.org") (kill-emacs) org-babel-tangle-file という関数で、orgファイルにあるコードブロックを、指定したファイルに書き出すことができます。対象のorgファイルにemacs lispしか書いていなければ、吐き出されるのもemacs lispになります。 まー、私が書くよりも、すでに色んなところでこれよりも細かく記述されているので、参考サイトに挙げたサイトを見てみることをオススメします。 orgからinit.elを生成した場合の注意点 さて、これで起動するとinit.orgからinit.elが生成できるわけですが、最初に生成した場合、色々と問題が発生するケースがあります。 straight.elとかで最新のorgを入れていたりする場合、大抵上手く動きません 上が影響して、他のパッケージも上手く動かない場合があります そのため、私のinit.elでは、起動して読み込み終わった直後に死ぬようにしてあります。初回だけすぐ終了してしまいますが、どうせ一回終了しないと正しく起動しないので・・・。 init.elの初期化めんどくさい問題 一度生成されたinit.elは、当然ながらinit.orgを読み込むようには(大抵)なっていません。そうなると、init.orgの内容をちゃんと反映させる場合、以下のような手順を踏む必要があります。 init.orgを編集する init.elの内容を元にもどす git checkout などで Emacsを再起動するか、init.elを読み込む 特に2がめんどくさいです。ぶっちゃけ、init.orgを更新したらinit.elを初期化しておいてもらいたいです。 ということで、以下のような設定を追加しています。(実際は、 after-save-hook ではなく、自作関数を登録する専用のhookを用意しています) ...

久々に４連休となったので、たまには頻度高めにブログを書いてみることにします。 今回は、前回SKKにしたということを書きましたが、それの辞書サーバーについて書いてみようと思います。 <!–more–> SKKと辞書サーバー SKKを使ったことがない方は、辞書サーバーといってもなんじゃそりゃ？となるでしょう。辞書サーバーとはそのままの意味で、SKKの辞書を提供するためのサーバープログラムを指します。 SKKの実装では、大抵はSKK辞書をインプットメソッド内にメモリとして展開し、それを利用しています。当然ながら、この形式では複数のインプットメソッドがあったら、各々でメモリを消費してしまいますし、管理が煩雑になりがちです。 そのため、SKKのほとんどの実装では、SKKプロトコルというプロトコルにもとづいたサーバーも辞書の一つとして利用できるようになっています。サーバーとして一つにまとめることで、複数のインプットメソッドから同時に利用することもできる、ということです。 ddskkでの辞書サーバーの設定 辞書サーバー、使う？ さて、辞書サーバーを使うといいことあるじゃん・・・と思いたいところですが、実際は中々そうはいきません。なぜかというと、使ってみたり運用してみた限りでは、以下のような問題があります。 SKKプロトコルがEUC-JPを前提としていて、UTF-8全盛の今にそぐわないケースが多い 実際に複数のインプットメソッドから利用すると、以外と面倒くさいケースが多い そもそもメモリが多くなったので、各々で利用しても問題にならないケースが多い 一個ずつ見ていきます。 SKKプロトコルの問題 SKKが開発されたのは1987年、佐藤雅彦氏によって開発されたのが初版とされています。 参考 当然ですが、1987年当時にはUnicode consortiumすらありません。(Wikipedia)なので、日本語を扱える文字コードは、事実上 EUC-JPとShift-JISの2強 でした。Linuxにおいては、EUC-JPがデファクトスタンダードの地位を確立していた(らしい)ので、日本語のかな漢字変換プログラムであるSKKがEUC-JPを前提としていても、何の不思議もありません。 さて、しかし時は経ち、現代ではUTF-8がデファクトスタンダードとなりました。そうなると困るのは、EUC-JPでしか扱えない、というプロトコルの問題です。これはSKKプロトコルの定義を修正しない限りはなんともならないです。事実、macOSで一番使われていると思われるAquaSKKでも、serverとのやりとりはEUC-JPに固定されています(辞書はUTF-8も扱えます)。 なので、辞書がUTF-8だったり、エンコーディングがUTF-8だったりすると、上手く変換できなかったりと、問題が発生しがちです。 複数のインプットメソッドからだとめんどくさい問題 プロトコルの問題でも上げましたが、辞書と辞書サーバーの文字コード、インプットメソッド内での扱いなどが異なる場合がある、などの事情があります。なので、以外とサーバーをそのまま利用できるケース、というのは少なかったりします。 仕事用のmacOSで、AquaSKKとEmacsで共通の辞書サーバーを使おう、と思ったりしましたが、このへんが上手くいかずに挫折したりしています。 そもそもメモリが多くなった 1990年くらいのPCは、メモリがMB単位とかあるとそれだけですげー、ってなった時代でした。今は2桁GBがあたりまえです(個人の感想です)。個人所有しているPCも、32GBとか積んでいます。 片や、SKKの辞書は、他のIMEと比較してもかなり小さいほうだと思います。実際に計測してみたら、SKKが配布している辞書を全部統合した辞書(コンパイル後)で、22MBしかありませんでした。 32 * 1024MB のメモリ空間があるところに、高々数十MBの辞書をメモリに展開したところで、ほとんど影響がないのは明白でしょう・・・。 それでも辞書サーバーを使ってみる 色々問題があるにはある辞書サーバーですが、それでも使ったことがないから使ってみたい、というのは人の性でしょう。ですので使ってみます。 さて、SKKには歴史があるので、当然ながら辞書サーバーも色々な実装があります。ここで挙げるのは蛇足なので、 Wikiへのリンクを貼っておきますので、気になる方はこちらから。 Google IME≒mozcを利用して、候補を取得したりする・・・という変わり種もあったりしますが、そこまで変わり種を使いたいわけでもないので、シンプルな辞書サーバーを選択してみます。 実際、速度の面などを考えると、C/C++で作られたサーバーがいいかな・・・と最初は考えました。 yaskkservは、かなりこなれた実装でもあり、かつGentooでも使えるものです。 が、これもまた歴史のあるツールなので、色々内部構造的な問題がある、ということで、作者の方がRustでリライトした yaskkserv2というのを開発されています。 ちょうどFirefoxとかをビルドしている関係上、Rustがマシンに入っているということもあり、これを使うことにしました。(見切り発車すぎる) yaskkserv2のビルドとか これらは、Emacsの起動時に、対象のプログラムが存在していなければビルドしてインストールするようにしました。ただ、ビルド環境が無い場合は、バイナリを落として展開するようにしています。 (leaf *skk-server :after f :if my:use-skkserver :init (let ((server-program (expand-file-name "yaskkserv2" my:user-local-exec-path)) (dictionary-program (expand-file-name "yaskkserv2_make_dictionary" my:user-local-exec-path))) (cond ((and my:build-skkserver (executable-find "cargo") (not (executable-find server-program)) (not (executable-find dictionary-program))) (let ((base-path "/tmp/yaskkserv2")) (unless (f-exists? base-path) (call-process "git" nil nil t "clone" "https://github.com/wachikun/yaskkserv2" "/tmp/yaskkserv2")) (call-process "cargo" nil nil t "build" "--release" "--manifest-path" (expand-file-name "Cargo.toml" base-path)) (unless (f-exists? server-program) (f-copy (expand-file-name "target/release/yaskkserv2" base-path) server-program)) (unless (f-exists? dictionary-program) (f-copy (expand-file-name "target/release/yaskkserv2_make_dictionary" base-path) dictionary-program)) )) (t (let* ((target (cond ((eq window-system 'ns) "apple-darwin") (t "uknown-linux-gnu"))) (path (format "https://github.com/wachikun/yaskkserv2/releases/download/%s/yaskkserv2-%s-x86_64-%s.tar.gz" my:yaskkserv2-version my:yaskkserv2-version target))) (call-process "curl" nil nil t "-L" path "-o" "/tmp/yaskkserv2.tar.gz") (call-process "tar" nil nil t "-zxvf" "/tmp/yaskkserv2.tar.gz" "-C" my:user-local-exec-path "--strip-components" "1")))))) 辞書のコンパイル時の注意 yaskkserv2は、独自の辞書形式を利用しているため、SKKの辞書はそのまま利用せず、 yaskkserv2_make_dictionary というツールから変換する必要があります。 ...