Creative Stage SE miniのファームウェアを更新した。リリースノートに Fixed audio will be automatically muted at minimum volume とあるように、USB接続で低音で流しているとミュートになる動作を直したみたい。しばらく使っている限り、確かに良くなっている。
Linuxでそこそこ音が鳴れば良い人にはオススメできる。
unwrap()は変数の所有権を移動させることがある
所有権をわかったつもりだったが、わかってなかった。*1
Rust By ExapmpleのPipesの章で、以下のコメントにあるstdinがdropされると記述が信じられなかった。
match process.stdin.unwrap().write_all(PANGRAM.as_bytes()) { Err(why) => panic!("couldn't write to wc stdin: {}", why), Ok(_) => println!("sent pangram to wc"), } // Because `stdin` does not live after the above calls, it is `drop`ed, // and the pipe is closed. // // This is very important, otherwise `wc` wouldn't start processing the // input we just sent.
drop()されていない筈だと、Rustでビルドすると確かにビルドエラーになる。コンパイラのエラーメッセージが賢くて、馬鹿にも理解できるように教えてくれた。
Copyトレイトが実装されていないことで unrap()を呼ぶと所有権が移動してしまい、dropしていたのだ。
928 | pub const fn unwrap(self) -> T {
| ^^^^
= note: move occurs because `process.stdin` has type `Option<ChildStdin>`, which does not implement the `Copy` trait
help: you could `clone` the value and consume it, if the `ChildStdin: Clone` trait bound could be satisfied
|
27 | match process.stdin.clone().unwrap().write_all(PANGRAM.as_bytes()) {
| ++++++++*1:「完全に理解した」ですね。
US配列 on JP109キーボードの感想
JP109キーボード上でUS配列にしてしばらく使ってみているが、特に問題はない。一部のショートカットキーがUS配列で押しやすいから割り当てられたんだろうなぁと気づくぐらいだった。
Mozcのローマ字テーブルを一部作り直し
JP109キーボードを前提としていた自作ローマ字テーブル(DvorakY改)を変更が必要になった。
- 長音のキーが、":"から"'"にする。コレはキーの位置も変わらないので問題ない。
- 小文字入力時のJIS配列で"@"の場所にあったキーが"["に変わってしまい、"「"が入力されるので使えなくなった。*1
@による小文字入力は殆ど使っていなかったので、少し遠くなるが"\"に割り当てることにした。
JP109キーボード上のUS配列にあわせたキーバインドにする
US配列でEscキーをどうするかを考えることになった。コレまでは、半角/全角をEscとしていたので、Escが遠くなってしまった。((日本語入力切り替えは、無変換/変換キーで行うMac流を使ってます。
で考えた結果、過去にCaps LockをEscとしたこともあるが今回は、"カタカナ/ひらがな"をEscとすることにした。以前と同様に、https://honmushi.com/2019/01/18/ubuntu-xkb/に書かれている方法でキーバインドを変更した。
setxkbmap -print > ~/.xkb/keymap/mykbd とした結果、下記となった。 +myswap(swapkeys) が以前と同様に追記した部分でswapは行為と変更内容が一致しないのだけど、昔の設定が残っているので流用した。
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete+japan" };
xkb_symbols { include "pc+au+inet(evdev)+terminate(ctrl_alt_bksp)+myswap(swapkeys)" };
xkb_geometry { include "pc(pc105)" };
};~/.xkb/symbols/myswapは、以下にした。Escは念の為に全角半角、メニューキーはxmonadのためにSuper_R(Winキー)としておいた。
partial modifier_keys
xkb_symbols "swapkeys" {
replace key <MENU> { [ Super_R ] };
replace key <HKTG> { [ Escape ] };
replace key <ESC> {[ Zenkaku_Hankaku, Kanji ] };
};プログラムを起動させる場所を集約させておきたかったので、xmonadから下記コマンドを実行させるようにした。 $DISPLAY~の環境変数がなぜか引き継がれていないようなので ~:0 と手書きしている。
xkbcomp -I$HOME/.xkb ~/.xkb/keymap/mykbd :0 2> /dev/null
この結果、日本語入力時のテーブルが以下のようになった。日本語入力中はシフト入力で同一キーに複数の機能をもたせることはさせない方針です。
Rust By ExampleのFrom and Intoが分かりにくい
The From and Into traits are inherently linked, and this is actually part of its implementation. If you are able to convert type A from type B, then it should be easy to believe that we should be able to convert type B to type A.
Rust By Exampleに上記が書いてあるので、型Aから型Bへの変換と、型Bから型Aへの変換の両方ができると誤解してしまった。
写経してみると、into()もfrom()もi32をNumberへ変換しているので同じじゃないかとなる。誰かが解説書いているだろと思い、探すとhttps://dackdive.hateblo.jp/entry/2021/04/30/100000が見つかり、やっぱりそうかと納得できた。
use std::convert::From; #[derive(Debug)] struct Number { value: i32, } impl From<i32> for Number { fn from(item: i32) -> Self { Number { value: item } } } fn main() { let num = Number::from(30); println!("My number is {:?}", num); let int: i32 = 5; let num: Number = int.into(); println!("My number is {:?}", num); }
US配列とJIS配列の違い
キー配列に関して、自分の経験ではUS配列とJIS配列の間には特に違いを感じない。
かつて、US配列のマシンとJIS配列のマシンが混在する環境で過ごしていた時期があり、毎日違うマシンを使っていたので、その日にならないとどちらの配列を使っているかわからなかった。最初は混乱したが、すぐに両方に慣れてしまった。
むしろ、QWERTY配列からDvorak配列にすることにこだわった方が有意義だ。昔にDvorak配列を常用していた経験から言うと、ショートカットキーがDvorak配列を使う上での最大の障害だったが、それでも利用価値があると思う。
そこで、久しぶりにUS配列を使ってみることにした。キーボードを買い替えるまでの志はないので、ソフト的に配列を変更することにした。
Manjaro Setting Managerにあるキーボードの設定を眺めてみると、English(Austraria)配列がJISキーボードをUS配列として使ったときに近いことに気づきました。"\|"の位置がUS配列と異なる点がありますが、それほど大きな問題ではないと思います。
設定変更後の/etc/vconsole.confの内容は以下になっていた。
FONT= FONT_MAP= XKBLAYOUT=au XKBMODEL=layouts XKBOPTIONS=terminate:ctrl_alt_bksp
Xの設定は以下になっていた。
Section "InputClass"
Identifier "system-keyboard"
MatchIsKeyboard "on"
Option "XkbLayout" "au"
Option "XkbModel" "layouts"
Option "XkbOptions" "terminate:ctrl_alt_bksp"
EndSectionちなみに、X11のAustraliaはUSの名前を変えただけだった。
// Keyboard layout for Australia.
// The default Australian layout is the same as the American.
default partial alphanumeric_keys
xkb_symbols "basic" {
include "us(basic)"
name[Group1]= "English (Australia)";
};で、調べてみると同じことをしている人が何人もいて、Macを中心にする人がいるみたい。
https://note.com/kamemushi_works/n/n65ab71ca98ec
オーストラリアってこんな変なキーボードを標準で使っているの?と疑問に思い、検索したところ、https://geekscallout.com.au/what-keyboard-layout-does-australia-use/によると、US配列を使っているみたい。
なんでUK配列とUS配列の間の子がEnglish(Australia)と称されているのかは謎のままだ。
設定変更した後日、ログインするとキー配列の変更が反映されなかったので調べた。結論は、Fcitxがキー配列を奪っていた。*1
fcitx5-configtool を起動して、アドオン > XCB 設定と入り
- システムXKB設定のオーバーライドを許可する
- 常にレイアウトをグループレイアウトのみにする
の両方のチェックを外す。コレによりキー配列設定が設定したとおりに出来た。
*1:キーボード入力関連で変なことが起きたら大体、Fcitxを疑っておけば間違いない気がする。
forループでイテレータ into_iter() が所有権を奪う
for x in vec と書くと暗黙的に、into_iter()が呼ばれてvecは所有権を失ってしまう。forで暗黙的に呼ぶのなら、所有権を奪わないiter()の方が良かったんじゃないと思い、AI先生に理由を聞いた。どうも、into_iter()が効率がよく、所有権の管理が明確になるという2点がポイントだそうだ。
AI先生は嘘つきだから、どうせ誰かが検証しているだろうと検索してみた。https://dawn.hateblo.jp/entry/2017/07/24/165933によると、確かに、iter()のほうが誤差程度で遅いらしい。大きなデータ構造ではもう少し差がでるのだろう。
let vec = vec![1, 2, 3]; let vec_iter = vec.iter(); for x in vec_iter { println!("{}", x); } // まだvecは有効 println!("{:?}", vec); let vec = vec![1, 2, 3]; for x in vec { // vec.into_iter()が呼ばれた println!("{}", x); //println!("{:?}", vec); 当然、使えない } // ここでvecは使えなくなる //println!("{:?}", vec);
PRIMERGY TX1310 M1のメモリを16GBへ拡大
メモリが4GBの状態でデスクトップクライアントとして使用していると、油断した際にメモリ不足で固まることがあった。この問題に耐えてきましたが、ついに我慢できなくなり、Non-ECCメモリを追加して16GBに増設しました。価格を見ると、DDR3 PC3-12800 8GB 2枚組が3000円以下で手に入ることも理由の一つでした。
メモリを交換した後、Manjaro Linuxに付属しているMemtest86+で確認を行いました。放っておいて気づいたら4周をPASSしていたので、これで問題ないと判断した。
Firefoxのタブを多数開いても特に問題は発生しないので、普通に使えるようになった。
