Posts
pyspa Advent Calendar 2023 の17日目です。17日目は ○○棒を振り回す torufurukawaでした。
ミス・マープル アガサ・クリスティの探偵といえばエルキュール・ポワロが一番有名だろうがミス・マープルもBBCでドラマになってたりして負けず劣らず有名である。
2023に読んだマープルもの そういえばマープルものってそんなに読んだことなかったなということで今年はマープルものを意識的に選んで読んだ。
火曜クラブ 牧師館の殺人 予告殺人 パディントン発4時50分 スリーピングマーダー 短編1本と長編4本。まあクイーンとかディクスン・カーとかの読み直しもしてたしね。
安楽椅子探偵 マープルはお婆さんだし田舎住まいだし、安楽椅子探偵のイメージがある。実際「火曜クラブ」はほとんどそういう形式で火曜クラブの参加者がいろんな謎の話を持ち込んでみんなで真相を考える中でマープルが最後に謎を解き明かす。もちこまれた話は過去の事件とかなので正解も用意されているという親切設計。とはいえ「牧師館の殺人」とか「予告殺人」とかはセント・メアリ・ミードで発生してて持ち前の情報網を活用したり聞き込みみたいなこともしたりと、意外と活動的。
推理手法 推理というか、やたらと感の鋭い婆さんである。近所のお婆さんとかで、なんでそんなことわかるの？というののすごいバージョン。アリバイ崩しとかトリックとかそういうことしない。証拠品も物的証拠を探すのは警察の仕事で、それの意味に気づくのがマープル。警察もマープルの推理を聞いて証拠を集めて逮捕なりなんなりする。きちんと手順を踏んで捜査してくれるわけで警察は優秀なのです。（探偵を持ち上げるために警察をことさらアホに描く探偵漫画ってよくありますよね。）
作品ごとの主人公たち 長編だと主人公がだいたいマープルじゃないのだけど、そこが小説として魅力をましている部分なのかと思う。「パディントン発4時50分」のルーシーを射止めたのは誰だったんでしょうね？
マープル 今年はマープルものを制覇しようと思ってましたがまだ半分程度しか読めてないです。というかクリスティってストーリーのほうがおもしろいのでマープルじゃなくても全然問題ないぜ。次読むものはすでに買って来ていて「魔術の殺人」です。ついでにトミーとタペンスの「秘密機関」も買ってきた。
pyspa Advent Calendar 2023、明日はtaichi satoが宇宙船の話。
年末なので emacsの設定棚卸ししておこうと思います。
ビルド emacs29.1が最新です。debian unstableでパッケージあるんでそれでもいいんですが、最近若干話題な気がするnixで管理することにします。
emacs-overlayが用意されてるのでそちらを使ってunstable-pgtk版をビルド。(waylandなのでpgtk版がうれしい)
nix home-managerのprograms.emacsで設定ごと管理します。
programs.emacs = { enable = true; package = pkgs.emacsWithPackagesFromUsePackage { package = pkgs.emacs-unstable-pgtk; config = ./config/emacs/config.org; alwaysTangle = true; }; extraConfig = ''(org-babel-load-file "${./config/emacs/config.org}")''; }; orgで設定ファイルを書く orgのコードブロックを使って文芸的プログラミングみたいな感じで書きます。
文芸的プログラミングって複数ファイルを取り扱ったりとかLSPとどう折り合いつけるかとか現代的にはなかなかうまい使い方がなさそうですが、設定ファイルを扱う分には結構あり。
emacs lispのコードブロックならorg-babel-load-fileで一発なので上記のnix設定でもorgファイル読み込むだけの設定追加(extraConfig)してあります。
パッケージ管理 nixのemacsWithPackagesFromUsePackageではなんとemacs lispをパースしてuse-packageで管理しているモジュールをnixパッケージで読み込んでくれます。
しかもorgファイルのコードブロックもパース対象。 ,(´_>∀<)_バカじゃないの
退役モジュールとか projectileはそれほど多くの機能を使いこなしてるわけでもないし標準のproject.elを使うことにしました。
ivy/councel/swiperは後述のvertico/consultに変えます。ついでにmarginaliaとかも追加設定。
eglotを試していましたがflymakeとエラー情報が同期してくれない(解消してるのにずっとエラーが表示され続ける)ことが多く、lsp-modeに戻します。
treemacsはまあなんかすごいなぁと思いつつも手に馴染むことはなかったのでもういいかなと。dired-toggleに変えてみることにします。
company-modeはcorfuに変更してみることに。まあどっちがいいかそれほど吟味したわけでもないですが。
コマンド補完 anything/helmには手を出さなかったもののidoからivyという感じでとりあえず入れとくといった使い方をしていましたが、今回vertico/consultにしてみます。どっちかというとmarginaliaとembark使いたかったのでついでに変えたというところ。
embarkのアクションはもっと使いこなせるようにしたい。今の所はwdiredとかlinesの結果を一括編集するとかそういったわかりやすい使い方をしている。
プログラミング eglotは軽いし既存の仕組みとうまくやりとりする作りってのが好みではあるのですがflymakeとの同期がうまくいかないことが何度も発生してしまい断念。 lsp-modeに戻しています。
lsp-modeの補完はcompany-modeが標準っぽいけど補完方法をcapfではなくnoneにするとcorfuでも問題なく動くという不思議。
あとはdockerでコンテナ起動するとかcontainer-trampが標準で使えるのでdevcontainerで開発できないかと考えましたがlsp-modeだとリモート設定がなかなか面倒そうです。来年はここらへん強化したい。
メール それほど出番ないけどemacsからさっと見るくらいする分のことはできると便利なので設定。今はmu4eが有名っぽいので、mbsyncと一緒に設定する。
なんかメール送信については標準のメール関連設定でやるとか、メールごとの表示設定がgnusと共通だったりして、構成がよくわからないのでとりあえず入れただけという状況。
org roam 1ファイルでがんばるつもりでしたがなんとなくorg-roamを入れてみることにしました。まだそれほど使ってないのでひとまずというところ。
org-roam-uiでグラフを見ているだけでもそれなりに楽しめます。
試そうと思ってるもの shackle, popper ウィンドウ管理するやつ。popwinよりもわかりやすいとか特化してるとかで使いやすそう。 elfeed RSSリーダーだが、feedlyと既読管理してくれるなら使いたいところだった。検討中。 emms mpdクライアントとして使いたい。id3タグが文字化け状態だとemacs閉じるときにバッファの文字コードが不明みたいに言われてうっとおしいのでそこらへん解消できたら常用したい。 まとめ あんまり大きな変化はない
emacs29.1がリリースされたしdebian sidもemacs29となったので設定見直しつつ乗り換え。
use-packageが標準入り 最初から入ってるのでブートストラップするとこは削除する。が、straight使ってる場合はそれほど変わらなかったりする。
docker-tramp -> tramp-container docker-tramp でコンテナ内に入っていたが標準でtramp-containerが使えるようになったのでこちらも削除。
csharp-mode これも標準で入ってくる。
pgtk 真にgtk3ネイティブなpgtkコンパイルでwaylandに対応した。透過背景とかちゃんと効くようになった
eglot emacsのlspクライアントでlsp-modeと両翼をなすeglotが標準に。 eglotのほうが仕組みが簡素なイメージなのだが、そのせいかtramp下で使うのはなんかeglotのほうがうまく動いてる気がする。ただエラー情報がflymakeと同期してくれないのか修正済みのエラーが表示され続けることが度々。
hugo-embed-pdf-shortcode を使って PDF.js を埋め込んでみた pycon jp 2022 資料 PDFダウンロード
#the-canvas { border: 1px solid black; direction: ltr; width: 100%; height: auto; display: none; } #paginator { display: none; text-align: center; margin-bottom: 10px; } #loadingWrapper { display: none; justify-content: center; align-items: center; width: 100%; height: 350px; } #loading { display: inline-block; width: 50px; height: 50px; border: 3px solid #d2d0d0;; border-radius: 50%; border-top-color: #383838; animation: spin 1s ease-in-out infinite; -webkit-animation: spin 1s ease-in-out infinite; } @keyframes spin { to { -webkit-transform: rotate(360deg); } } @-webkit-keyframes spin { to { -webkit-transform: rotate(360deg); } } Previous Next Page: / window.
Linuxデスクトップを常用してイキっているので現在の状況をまとめておく。
コンポジターとか ここらへんの話は去年の swayでwayland で設定した内容からほとんど変わっていない。 waylandを使うことにして、コンポジターとしては sway を採用している。タイル型にも慣れてきた。
ランチャーには wofi を使っているのはそのままで、デスクトップ通知も mako で続投。タスクバーはi3blockを使ってみたかったのでwaybarからsway標準のswaybarに戻している。
swayを使っていて不便というかwaylandかwlroots、desktop-portal-wlr あたりがまだ機能足りないのがミラーリング。普段使っているときは気にならないのだが登壇のタイミングでミラーリングできないことに気づいた。あと地味に面倒なのは画面共有でウィンドウ選択ができないところ。
greetd ディスプレイマネージャーには greetd を使うことにしている。 sidにgreetdのdebianパッケージが入ってきたので移行してみたが、wlgreeterとかgtkgreeterはまだパッケージにきていないので、そちらは自前でビルド。 wlgreeterはwlrootsを使っているようなのだが、以前ビルドしていたのがabi互換性で動かなくなっていた。ふとしたアップグレードでgreeterが立ち上がらないのはいやなんで、gtkgreeterに変更。なんとなくgtkのほうがabi互換性に強そうな気がする。
pam設定はdebianパッケージに入っていないが、デフォルトで greetd, login をみて存在する方を使うらしい。 /etc/pam.d/login をコピーして /etc/pam.d/greetd を作成。gnome-keyringを有効にする設定を追加してある。
ブラウザ waylandで困っているのはブラウザである。どうもxwaylandだとどのウィンドウもアクティブになっている扱いらしく、chromeをxwaylandで動かすとウィンドウが複数になったときにとても重い。 ozone platformでwaylandを指定するとchromeもwaylandネイティブで動くのだが、今度は日本語入力ができない。 waylandの日本語入力はまだなんか色々やってるみたいだけど、基本的には text-input-unstable-v3 をみんな実装している流れみたいだけど chromeは話進めている途中 のようだ。
以外にもfirefoxはwaylandネイティブにしても日本語入力可能だった。多分 gtk im module がそのまま有効になっているっぽい。環境変数で GTK_IM_MODULE=fcitx5 と設定するだけで良かった。またgtkとfcitxどちらも text-input-unstable-v3 に対応しているようで GTK_IM_MODULE の設定なくても日本語変換自体は可能。でもこの場合は変換候補ウィンドウのポップアップの処理はコンポジターがやることになっていて、swayはまだ対応していないので変換候補を見れない。 gtk im module を使った方法に寄せておくのが良さそう。
ターミナルエミュレーター wezterm が機能豊富でなんかいけてるから最近導入してみた。 kittyの画像表示プロトコルにも対応しているので、後述の ranger で画像プレビューできてしまうのもポイント高い。まだdebianのパッケージがないけどflatpakにあったのでお試し利用中。
気になる点というかあとあと対処しないといけないと思ってるのがいくつか。
flatpakで入れたことで環境変数やネットワークアクセスで制限がかかってる weztermは text-input-unstable-v3 を実装しているようで日本語変換できるけどswayの変換候補ポップアップの対応待ちということでもある OSC133とか便利なものを設定しておきたい ファイラー ranger がターミナル上で結構使いやすい。ターミナルもrangerの画像プレビューが安定していた rxvt から wezterm に変えたが、それなりに安定している。でも偶にボーダーラインとかの描画が変。すぐに直るけど。 rangerから起動するアプリケーションは軽いものにしたいので sxiv とか mpv とか mupdf とかで設定している。
pyspa Advent Calendar 2022 9日目です。8日目は分散処理に詳しいオタク kumagi でした。
去年のエントリでswayをコンポジターにしてwayland生活をするようにしたわけだが、軽量なデスクトップにしていくのでも音楽を聴く余裕は欲しいものである。 mpd (Music Player Daemon) は名前の通りデーモンで動くミュージックプレイヤーである。もちろんヘッドレスでGUIどころかクライアントは別途選ぶもので、軽量デスクトップ野郎どもの友と言えるミュージックプレイヤーだ。
Linuxで音楽を聴く ところでLinuxで音楽を快適に聴くにはある程度仕組みを知っていないと設定がおぼつかない。一応mpdを設定する上で調べてみたところを書いておく
alsa, pulseaudio,pipewire まずはdacなりHDMIなりのデジタルオーディオデバイスを操作する部分が必要だが、これはALSA(Advanced Linux Sound Architecture) というカーネルコンポーネントの仕組みとなっている。とりあえずALSAが設定されてないとそもそも音を出せないが、まあ最近のディストロはデバイスを認識して設定してくれるのでそれほど問題ないだろう。ここでつまずいた場合はなんかがんばってください。そしてアプリケーションがどう音を出すかだが、直接alsa APIを扱うアプリケーションもあるがデスクトップ環境ではソフトウェアミキサーがあって多くのアプリケーションはそこを経由して効果音や音楽など音を出す。過去にはGNOMEがesound、KDEがartsだったが、どちらもpulseaudioに移行した。 pulseaudioは音質が抑えめでjackという高音質な代替もある。さらにpulseaudioからpipewireに移行しつつある。色々あるがwaylandでは画面共有などの都合もあるのでpipewireを使うのが普通な気がする。
pipewireとwireplumber, spa ということでwaylandにした環境でさらにpulseaudioを捨ててpipewireに移行。 debianを使っているので PireWire - Debian Wiki を参考にpipewireやspa(pipewireのプラグインみたいなやつ？)をインストールしてpulseaudioのインターフェイスも動くようにした。
mpdのインストールと設定 mpdをインストールしてサービス起動を設定 さて、本題のmpdである。aptで入れたので、他のディストロ使っている人やソースから入れる人は Download the Music Player Daemon のページなどを参照のこと。
mpdはデーモンなのでsystemdのservice unitで管理したい。 debianでインストールするとsystemd service unitの定義も一緒に入ってるのでこれを利用する。デフォルトでsystem sessionで起動するようになっているが、音楽ファイルのディレクトリはユーザー以下にしたいのでuser sessionのサービスとして扱いたい。
さらにservice unitだけでなくsocket activationも用意されているのでこれらをuser sessionで有効にする。 socket activateは直接サービス起動するのではなくポートへのアクセスで初めて本体が起動するやつ。まあどうせすぐ使うからログインしたらすぐ起動しちゃってもいいんだけど。
$ sudo systemctl --now disable mpd.socket $ systemctl --now --user enable mpd.socket mpdの設定 システム的なmpd自体の設定は /etc/mpd.conf にあるが、ディレクトリの指定やoutputなどだいたい変更するのであんまり気にしない。ユーザーとして実行する場合の設定ファイルはXDGを尊重して /.
ox-hugoとは emacsのorg-modeで書いた文章をhugoで扱えるmarkdownにexportするもの。
なんでox-hugo org-modeから離れられないとかそういう人向け。 orgファイルにすべてを集約しているのでそこからブログに切り出すというワークフローを使いたい。 org-modeのよさ emacsの標準ドキュメンテーション なんでも書ける なんにでも出せる emacs lisp以外でもプログラミングを埋め込むなどできる 表計算まで可能 TODOリストにもなる 大元はアウトラインプロセッサのはず org-modeのよくなさ 多分emacsなしではやってけない 普通はmarkdownでしょ？ なんでもできすぎて移行が難しい ひとまず これでやっていく
pyspa Advent Calendar 2021 の16日目のエントリです。 15日目は@ymotongpooのGoのリリースプロセスとブランチ戦略でした。
waylandにしよう ある日X serverの調子が悪いのかディスプレイマネージャーからログイン後すぐにログアウトしてしまうようになった。 bspwmを使っていて発生したがopenboxに変えたりしても状況変わらず。 コンソールから立ち上げたりしてもエラーが出てるわけでもなく、原因がわからないままにふと試しに入れていたswayを起動したらちゃんと動いた。なぜかwaylandは動くのである。 そういうことならもうwaylandに移行してみるかと新たなヤックの群れに立ち向かうことにした。 （※debian sidにて作業した記録です。）
sway お試しでいれてみたswayだがこれはwaylandコンポジターの1種でi3wmのようなタイル型のレイアウトでウィンドウを扱うもの。 というか設定ファイルはほとんどi3と同じでwayland向けの設定が追加されているくらいのものである。
キーボード設定とか ひとまずディスプレイマネージャーを切って、コンソールからの立ち上げでいろいろ設定していくことにする。 waylandはx serverの役割とウィンドウマネージャーの役割をコンポジターが受け持っているので、そこらへんの設定も必要になる。 システムの設定は /etc/sway/config にあった。 ユーザーの設定ファイルは ~/.config/sway/confing になるのでこっちにコピーして修正していくことにしよう。
$ mkdir ~/.config/sway $ cp /etc/sway/config ~/.config/sway ひとまずキーボードをjp106に設定しよう。あとCAPSをCTRLにしておく。
input * { xkb_layout "jp" xkb_options "ctrl:swapcaps" } あとトラックパッドでタップ設定とナチュラルスクロールの設定とかもしておく。
input type:touchpad { tap enabled natural_scroll enabled } タスクバーとかランチャーとか swayにはswaybarというタスクバーが標準でついてくるが、まあいろいろ追加できるwaybarというものがあるのでそっちに交換する。 waybarはwlrootsを使っているコンポジターと相性がいいらしいので採用。 ランチャーについてはbspwmにrofiを使っていたがwaylandにポーティングかなんかしたwofiというのがあったので採用。 通知についてはdunstからmakoに変更。 まとめるとこんな感じ
タスクバー: waybar ランチャー: wofi デスクトップ通知: mako waybarについてはexecするのではなくbarの設定でコマンド指定する。
bar { swaybar_command waybar } wofiはキーバインドで実行できるようにしておく。
setuptoolsはPythonにおけるライブラリ配布のためのツールとして長らく利用されています。 配布物の作成方法はPEP 517で標準化されpoetryやflitのようなツールが作成されています。 これらのツールはPEP 517に対して開発されてきたためpyproject.tomlでプロジェクトメタデータを記述しています。 しかしsetuptoolsはプロジェクトメタデータをsetup.py, setup.cfgに記述する方法をとっており、これらのファイルがまだ必要となっています。 これらのファイルが必要となる理由といつまで必要となるのか整理しました。
setup.cfg setuptoolsもPEP517に対応しているため以下のようなpyrproject.tomlを記述してwheelを作成できます。 (https://setuptools.readthedocs.io/en/latest/build_meta.html)
[build-system] requires = ["wheel", "setuptools"] build-backend = "setuptools.build_meta" このときプロジェクトメタデータはsetup.cfgに記述することになるため、 setup.cfgとpyproject.tomlと設定ファイルが2つ必要になります。
しかしpoetryやflitといったパッケージングツールはpyproject.tomlにプロジェクトメタデータを記述するようになっています。 これらのツールもメタデータの記述方法はそれぞれ独自に決めているため細かな才があります。 とはいえ最終的には同じメタデータを生成するための情報なのでメタデータをpyroject.tomlに書くためのスキーマを定義するPEPが提案されています。
pyproject.tomlにプロジェクトメタデータを記述するためのPEP PEP 621 – Storing project metadata in pyproject.toml PEP 631 – Dependency specification in pyproject.toml based on PEP 508 setup.py wheelを作成するにはsetup.pyは必要ありません。 しかし、setuptoolsの単体で依存ライブラリをインストールする機能である develop コマンドや editable install には setup.py が必要になります。 この場合、ただ setup 関数を呼ぶだけの setup.py を作成することになります。
from setuptools import setup setup() pipのinstallコマンドで --editable (-e) オプションをつけるとeditableインストールとなります。