__aki_nikki__

分子分光学の研究をしている大学院生の日記です

tyをNeovimから使ってみる

tyをNeovimから使ってみる

tyとはuvやRuffの開発で有名なAstralの開発しているRust製の型チェッカー&Language Serverです。 Pythonの型チェッカーとしてはmypy,pyrightが、Language Serverとしてはpls,pyright(pyrightは型チェッカーとしても)が良く使われています。

CLIで型チェッカーとして試しているブログ記事には以下のようなものがありますが、 コードエディタから使用している例はざっと探したところなかったので実際に試してみました。

tyのinstall

今回は$HOME/try_tyディレクトリの中にuvで仮想環境を構築して、その環境中にinstallしtyへのfull pathを使用してNeovim側から呼び出すことにします。

$ uv init # 環境を用意

$ uv add ty # install

uv run tyを実行して以下のようなメッセージが表示されればinstallはOKです。

$ uv run ty # installされたことをチェック
An extremely fast Python type checker.

Usage: ty <COMMAND>

Commands:
  check    Check a project for type errors
  server   Start the language server
  version  Display ty's version
  help     Print this message or the help of the given subcommand(s)

Options:
  -h, --help     Print help
  -V, --version  Print version

Neovim側の設定

NeovimビルドインのLSPクライアントを利用する場合では、 neovim/nvim-lspconfig を利用して

require('lspconfig').ty.setup({})

とするのが一般的ですが、(nvim-lspconfig/lsp/)、にはty.luaがあるものの、nvim-lspconfig/lua/lspconfig/configs/には、存在しないため、

[lspconfig] config "ty" not found. Ensure it is listed in `configs.md` or added as a custom server.

とエラーが出てLanguage Serverを起動できません。 Neovim 0.11.1以降では、ビルドインのlspのconfigが存在しますが、書き方に慣れていないので今回はvim.api.nvim_create_autocmd()で呼び出す方法で設定を書きました。

local home_dir = vim.env.HOME
local path_to_ty = home_dir .. '/try_ty/.venv/bin/ty'

-- ty
vim.api.nvim_create_autocmd('FileType', {
  pattern = { 'python' },
  callback = function()
    vim.lsp.start({
      name = 'ty',
      cmd = {
        path_to_ty,
        'server',
      },
      capabilities = vim.lsp.protocol.make_client_capabilities(),
    })
  end,
})

-- 普段使用しているpyrightは一旦無効化
-- require('lspconfig').pyright.setup(pyright_config)

検証

サーバーの起動チェック

まず、Neovimで適当な*.pyなファイルを開き、サーバーが起動するかを以下のコマンドでチェックしてみます。

$ ps aux | grep 'ty server'
aki       295362  0.3  0.1 3410496 38304 ?       Ssl  00:03   0:00 /home/aki/try_ty/.venv/bin/ty server

無事起動しているようですね！。

補完が効くかチェック

Language Serverと言えばコード補完ということで、適当なコードを書いてコード補完が効くが見てみます。 今回は以下のような簡単な関数を書いて呼び出すコードを書いてみます。

def sum_to_n(n: int) -> int:
    sum = 0
    for i in range(n + 1):
        sum += i

    return sum


def main() -> None:
    print(f"sum_to_10 = {sum_to_n(10)}")


if __name__ == "__main__":
    main()

コーディング中では以下のように補完が表示されました。

コード補完その1
コード補完その2

コーディング中の型チェック

Pythonでは型ヒントの書かれたコードを対応した型チェッカーで静的にチェックすることができます。

ここでは、以下のような明らかにシグニチャと実際に返している値の型が違う場合に、警告が出るか試してみます。

def greet(name: str) -> str:
    res = f"Hello {name}"

    return 123


def main() -> None:
    greet("Ema")


if __name__ == "__main__":
    main()

結果として以下のように赤色で型の間違いを指摘してくれました。

静的な型チェック

その他

補完と型チェック以外では以下の操作が可能でした。

  • 定義元へのジャンプ
  • カーソルのあるオブジェクトを参照しているコードの列挙
  • コード中のシンボルの列挙
  • カーソルのある変数の情報を表示

一方、変数名の一括変更は[LSP] Rename, no matching language server with rename capability.と出て出来ませんでした。

感想

とりあえず、tyをNeovimから使用し、LSPによるコーディング支援機能はほぼ使用することができました。 GitHubをのプロジェクトページを見るとまだ発展途上とのことですので、今後に期待ですね。

Arch Linuxでsecure bootを設定した

Arch Linuxでsecure boot

Arch Linuxをセキュアブートに対応させました。 主な理由は別ディスクにinstallしたWindows11のディスク暗号化をまともに運用するのに必要だったからです。

手順は基本的にArch Wikiのガイドの通りでちゃんとできました!。

sbctlで鍵を生成して自分で署名をする

作業をする行う前にUEFI BIOSに入りsecure bootをsetup modeに設定します。

起動してから、必要なツールをinstallします。

$ sudo pacman -S efitools sbctl

まず、すでに存在するefi鍵の確認を行います。

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

続いて、sbctl create-keysで鍵を生成して,enroll-keysで鍵を追加します。 ここで、-mオプションはマイクロソフトの鍵を消さずに自分で生成した鍵を追加するようすることを意味します。

これを忘れると、マイクロソフトの鍵で署名された一部のデバイスドライバが読めなくなって最悪の場合ではマシンが文鎮化する恐れがあります。

$ sudo sbctl create-keys
$ sudo sbctl enroll-keys -m # -mオプションを忘れないようにすること

今回鍵を登録しようとしたところ以下のようなエーラーが出ました。

‼ File is immutable: /sys/firmware/efi/efivars/KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c
‼ File is immutable: /sys/firmware/efi/efivars/db-d719b2cb-3d3a-4596-a3bc-dad00e67656f
You need to chattr -i files in efivarfs

どうやら書き込みしたいファイルがイミューダブルなのでミューダブルになるようにしろとのことなので以下のようにしてミューダブルにしました。

$ sudo chattr -i /sys/firmware/efi/efivars/KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c
$ sudo chattr -i /sys/firmware/efi/efivars/db-d719b2cb-3d3a-4596-a3bc-dad00e67656f

この後で再び鍵の登録を行うとちゃんと成功しました。

$ sudo sbctl enroll-keys -m
Enrolling keys to EFI variables...
With vendor keys from microsoft...✓
Enrolled keys to the EFI variables!

続いてsbctl verifyで署名が必要なファイルを調べます。

チェック

$ sudo sbctl verify
Verifying file database and EFI images in /boot...
✗ /boot/EFI/BOOT/BOOTX64.EFI is not signed
✗ /boot/EFI/systemd/systemd-bootx64.efi is not signed
failed to verify file /boot/initramfs-linux-fallback.img: /boot/initramfs-linux-fallback.img: invalid pe header
failed to verify file /boot/initramfs-linux.img: /boot/initramfs-linux.img: invalid pe header
failed to verify file /boot/intel-ucode.img: /boot/intel-ucode.img: invalid pe header
failed to verify file /boot/loader/entries/arch.conf: /boot/loader/entries/arch.conf: invalid pe header
failed to verify file /boot/loader/entries.srel: /boot/loader/entries.srel: invalid pe header
failed to verify file /boot/loader/loader.conf: /boot/loader/loader.conf: invalid pe header
failed to verify file /boot/loader/random-seed: /boot/loader/random-seed: invalid pe header
✗ /boot/vmlinuz-linux is not signed

結果としては以下の3個のファイルに対しての署名が必要だったので

  • /boot/EFI/BOOT/BOOTX64.EFI is not signed
  • /boot/EFI/systemd/systemd-bootx64.efi is not signed
  • /boot/vmlinuz-linux is not signed
$ sudo sbctl sign -s /boot/vmlinuz-linux
$ sudo sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI
$ sudo sbctl sign -s /boot/EFI/systemd/systemd-bootx64.efi

によって行いました。

今回をこの作業を行なったマシンはsystemd-bootでかつその更新をsystemd-boot-update.serviceで行なっているので以下のコマンドで/usr/lib内のブートローダーを直接署名しました。

# for systemd-boot
$ sudo sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

この後でUEFI BIOSに入りsecure boot enableにしてから無事起動できたらOKです。

感想

途中の鍵の登録では-mオプションを忘れると最悪マシンを文鎮化する可能性があるということでビビリながら作業していました。 しかしsbctlで鍵の作成&登録&署名は思っていたよりも簡単にできました。

SYCLの環境構築

SYCLの環境構築

去年の年内まではArch Linuxのpacmanで intel-one-api-dpcpp-cpp さえinstallしていればうまく動いていたのですが、年度末くらいに久しく触ろうとしたらOpenCLを認識できない等のトラブルが発生してビルドまではできるけど、実行ができないという状況になってしまいました。

色々とトラブルシューティングを試みたのでが、結局解決できなかったのでコンパイラ等のSDKをソースから自分でビルドする方法でやってみたところうまくできたのでblogに残しておこうと思います。

コンパイラ、SDKをソースからビルドする

intelのリポジトリのガイドを見るととりあえずGit,CMake,Python,Ninja,hwloc,C++のコンパイラが必要だそうなのでinstall されていなかったhwlocをinstallしました。

$ sudo pacman -S hwloc

まず適当なディレクトリを作成してそこにソースをクローンします。

$ mkdir sycl_workspace
$ cd sycl_workspace
$ git clone https://github.com/intel/llvm -b sycl # 結構時間がかかる!

続いてconfigureしてからビルドを実行します(お決まりのコース!)。ここで注意が必要なのは--native_cpuがないとCPUで実行できるコードをコンパイルできなくなります。

またLanguage Serverとしてclangdを使いたいので--ci-defaultも必要です。 というのも普通のC++用のclangdではSYCLのコードの解析ができないためです。

$ python llvm/buildbot/configure.py --ci-default --native_cpu
$ python llvm/buildbot/compile.py -j 11 # 40分くらいはかかる
$ python llvm/buildbot/compile.py -t clangd -j 11 # 15分くらいはかかる

ビルドが終了するとllvm/build/install内にbin,lib,includeが作られ必要なファイル類が置かれるのでinstallの中身を適当な場所に置いて使うときにPATH,LD_LIBRARY_PATHを設定すれば良いです。 clangdはllvm/build/bin内にのみ置かれますが、適当なディレクトリに置いたbinにでもcopyしておけば良いです。

実際にビルド&実行できるかのチェック

実行にはlevel-zero-loaderが必要で、更にintel CPU内蔵のGPUでも実行したければintel-compute-runtimeも必要です。

$ sudo pacman -S intel-compute-runtime level-zero-loader

確認用にまずデバイスが認識されているかを見る以下のコードをビルド & 実行してみました。

check_devices.cpp

#include <sycl/sycl.hpp>

auto main() -> int {
  std::vector<sycl::device> devices = sycl::device::get_devices();

  for (const auto &device : devices) {
    std::cout << "Device: " << device.get_info<sycl::info::device::name>()
              << "\n";
    std::cout << "Vendor: " << device.get_info<sycl::info::device::vendor>()
              << "\n";
    std::cout << "Max Compute Units: "
              << device.get_info<sycl::info::device::max_compute_units>()
              << "\n";
    std::cout << "----------------------------------\n";
  }

  return 0;
}

今回は$HOME/sycl_localにツールチェーンとライブラリ、ヘッダを置いたので、まず以下のようにしたPATH,LD_LIBRARY_PATHの設定を行ないました。

$ export PATH="$HOME/sycl_local/bin:$PATH"
$ export LD_LIBRARY_PATH="$HOME/sycl_local/lib:${LD_LIBRARY_PATH:-}"

ビルドは以下のように行ないました。

$ clang -fsysl -fsysl-targets=native_cpu check_devices.cpp -o check_devices

これを実行してデバイス名が表示されればOKです。私の環境では以下のようになりました。 CPU,GPUが認識されていますね。

Device: Intel(R) UHD Graphics 770
Vendor: Intel(R) Corporation
Max Compute Units: 32
----------------------------------
Device: SYCL Native CPU
Vendor: Intel(R) Corporation
Max Compute Units: 24
----------------------------------
Device: Intel(R) UHD Graphics 770
Vendor: Intel(R) Corporation
Max Compute Units: 32
----------------------------------

最後にGPGPUの入門で良く見るベクトル加算c[i] = a[i] + b[i]の例の以下をCPU/GPUで実行して動作確認しました。

vector_add.cpp

#include <iostream>
#include <sycl/buffer.hpp>
#include <sycl/sycl.hpp>
#include <vector>

template <class T> auto show_vec_1d(const std::vector<T> &array) -> void {
  for (const auto &v : array) {
    std::cout << v << " ";
  }
  std::cout << "\n";
}

auto check_devices(const sycl::device &dev) -> void {
  std::cout << "vendor: " << dev.get_info<sycl::info::device::vendor>() << "\n";
  std::cout << "device: " << dev.get_info<sycl::info::device::name>() << "\n";
  std::cout << "device version: " << dev.get_info<sycl::info::device::version>()
            << "\n";
  std::cout << "driver version: "
            << dev.get_info<sycl::info::device::driver_version>() << "\n";
  std::cout << "mx compute units: "
            << dev.get_info<sycl::info::device::max_compute_units>() << "\n";
  std::cout << "local mem size: "
            << dev.get_info<sycl::info::device::local_mem_size>() << "\n";
  std::cout << "has fp64 :" << dev.has(sycl::aspect::fp64) << "\n";
  std::cout << "has fp16 :" << dev.has(sycl::aspect::fp16) << "\n";
}

auto main(void) -> int {
  std::vector<int> vec_a{1, 2, 3, 4, 5}, vec_b{10, 20, 30, 40, 50};
  auto vec_size = (std::size_t)vec_a.size();

  // impl naive
  std::vector<int> vec_c_naive(vec_size, 0);
  for (auto j = 0; j < vec_size; ++j) {
    vec_c_naive[j] = vec_a[j] + vec_b[j];
  }
  show_vec_1d(vec_c_naive);

  // impl SYCL
  std::vector<int> vec_c_sycl(vec_size, 0);

  // Queue
  // auto q = sycl::queue{sycl::cpu_selector_v, sycl::async_handler{}};
  // use gpu !
  auto q = sycl::queue{sycl::gpu_selector_v, sycl::async_handler{}};
  auto dev = q.get_device();
  std::cout << "information of device now running: \n";
  check_devices(dev);

  {
    sycl::buffer<int, 1> device_a(vec_a.data(), sycl::range<1>(vec_size));
    sycl::buffer<int, 1> device_b(vec_b.data(), sycl::range<1>(vec_size));
    sycl::buffer<int, 1> device_c(vec_c_sycl.data(), sycl::range<1>(vec_size));
    q.submit([&](sycl::handler &cgh) {
      sycl::accessor acc_a(device_a, cgh, sycl::read_only);
      sycl::accessor acc_b(device_b, cgh, sycl::read_only);
      sycl::accessor acc_c(device_c, cgh, sycl::write_only);

      cgh.parallel_for(sycl::range<1>(vec_size), [=](sycl::item<1> id) {
        acc_c[id] = acc_a[id] + acc_b[id];
      });
    });
  }
  show_vec_1d(vec_c_sycl);

  return 0;
}

ここではCPU/GPUの切り替えは簡易的にsycl::queueの構築の際にsycl::cpu_selector_vにするコード、sycl::gpu_selector_vにするコードとしてコメントアウトで切り変えてビルドしまいた。

ビルドはそれぞれ以下のように行いました。

$ clang -fsycl -fsycl-targets=native_cpu vector_add.cpp -o vector_add_cpu # CPU向けにビルド
$ clang -fsycl vector_add.cpp -o vector_add_gpu # GPU向けにビルド

それぞれを実行すると以下のような結果が得られました。 それぞれ正しい結果が得られていますね。

$ ./vector_add_cpu # CPUで実行
11 22 33 44 55
information of device now running:
vendor: Intel(R) Corporation
device: SYCL Native CPU
device version: 0.1
driver version: 0.0.0
mx compute units: 24
local mem size: 32768
has fp64 :1
has fp16 :1
11 22 33 44 55

$ ./vector_add_gpu # GPUで実行
11 22 33 44 55
information of device now running:
vendor: Intel(R) Corporation
device: Intel(R) UHD Graphics 770
device version: 12.2.0
driver version: 1.6.32961
mx compute units: 32
local mem size: 65536
has fp64 :0
has fp16 :1
11 22 33 44 55

感想

ソースからビルドする時に--native_cpuが必要だったりとハマったポイントはありましたが何とかSYCLの環境構築ができました。 syclacademyというチュートリアルを一応一周してはいるのでraytracingなんかをSYCLで書いてみたいと思います。

大規模ソフトウェアを手探るをやる (1: gnuplot 5.0.1のビルドまで)

東京大学工学部電子情報学科の学生実験の資料の大規模ソフトウェアを手探るというgnuplotのコードをいじることを通してある程度大きなソフトウェアソースコードを探るというのが数年前に話題になっていたのを思い出したので、取り組んでみました。

gnuplot 5.0.1 をビルドする

まずSOURCEFORGE: gnuplot Filesから5.0.1のソースを取得して解凍する。

$ wget https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0.1/gnuplot-5.0.1.tar.gz
$ tar -xvf gnuplot-5.0.1.tar.gz
$ cd gnuplot-5.0.1

そのソースツリーの中にbuildディレクトリを作成してビルドを実行しようとすると...

$ mkdir build
$ cd build
$ CFLAGS="-O0 -g" ../configure --prefix=$HOME/gnuplot_5.0.1_install

configure中にlibcerfがnotfoundと言われたので

$ sudo pacman -S libcerf

にしてから普通にmakeでビルドをしようとすると、以下のメッセージが出てビルドに失敗した。

In file included from ../../src/term.h:414,
                 from ../../src/term.c:1194:
../../term/lua.trm: In function ‘LUA_GP_int_error’:
../../term/lua.trm:254:15: error: implicit declaration of function ‘luaL_checkint’; did you mean ‘luaL_checkany’? [-Wimplicit-function-declaration]
  254 |       t_num = luaL_checkint(L, 1);
      |               ^~~~~~~~~~~~~
      |               luaL_checkany

そこでソースツリーのINSTALLを読んでみると、gnuplot-5.0.1ではLua5.2系を要求しているようである。 一方、 自分の環境ではssystemにinstallされているLuaが5.4.7であった。 そこで、Lua5.2.4をソースからビルドしてそのヘッダ、ライブラリを使ってgnuplot-5.0.1をビルドすることを考えた。

$ wget https://sourceforge.net/projects/luabinaries/files/5.2.4/Docs%20and%20Sources/lua-5.2.4_Sources.tar.gz
$ cd lua52
$ make linux -j11
$ make INSTALL_TOP=$HOME/Learn/search_large_scale_software/lua5.2.4/ install

$HOME上にinstallしたlua5.2.4をgnuplot-5.0.1に教えてあげるため以下ように環境変数設定用スクリプトを書いてsourceで実行した。

set_var.sh

PROJECT_DIR="$HOME/Learn/search_large_scale_software"

export LUA_CFLAGS="-I$PROJECT_DIR/lua5.2.4/include"
export LUA_LIBS="-L$PROJECT_DIR/lua5.2.4/lib -llua"
export PATH="$PROJECT_DIR/lua5.2.4/bin:$PATH"
export LD_LIBRARY_PATH="$PROJECT_DIR/lua5.2.4/lib:$LD_LIBRARY_PATH"
$ source set_var.sh

以上を行なった後で、気を取り直してビルド。

$ cd gnuplot-5.0.1
$ mkdir build
$ cd build
$ CFLAGS="-O0 -g" ../configure --prefix=$HOME/gnuplot_5.0.1_install
$ make -j11 # OK!
$ make install

無事ビルドに成功しました。

NovimにファイラーFernを導入した

NeovimにファイラーFernを導入した

筆者はnvimでファイラーとして古くから使われているNERDTreeを使っていました。 しかし、XやZennなどでFernがおすすめされていて気になったため使ってみることにしました。

実装はVimScriptですのでVim,Neovim両方で使うことが可能です!

インストール

筆者はパッケージマネージャーとしてLazy.nvimを使用しているので、まず~/.config/nvim/lua/plugins.luaに以下を書き込みます。

-- filer
filer = {
    "lambdalisue/fern.vim",
}

return {
    --- 他のプラグイン 
    filer
}

ここまで設定すればとりあえず使えるようになります。とりあえず今いるディレクトリの内容を表示するにはコマンド

:Fern .

を実行し、左側に表示するにはオプション-drawerを付けて

:Fern . -drawer

と実行します。

いい感じに表示するには

:Fern . -reveal=% -drawer -toggle -width=25

とオプションをたくさん付けて実行する。

ここで、-reveal=%は現在focusしているバッファの内容と共に現在のディレクトリを開くという意味で、 -toggleはもう一回同じコマンドを実行することでフィアラーを閉じることを意味で -width=<width>は左側に表示されるwindowの幅を<width>に設定するという意味です。

設定

.gitignoreのような'.'から始まる隠しファイルが見えないのは困るので、まず

-- show hidden file
vim.cmd[[let g:fern#default_hidden=1]]

を設定して隠しファイルがファイラーから見えるようにします。

長いコマンド:Fern . -reveal=% -drawer -toggle -width=25<CR>を毎回入力するのは流石に面倒なので何かショートカットのコマンドを定義することを考えます。

最初はvim.cmd[["<vim command>"]]でコマンドを定義していましたが、せっかくLuaで設定ファイルを書いているのでLuaでコマンドを定義することにしました。

筆者はNERDTreeを使用していた時に:Ntで現在いるディレクトリについて左側にファイラーが開くように設定していたので、それをついで以下のようにコマンドを実装しました。

-- toggle Fern by :Nt 
vim.api.nvim_create_user_command(
'Nt',
function ()
    vim.cmd(":Fern . -reveal=% -drawer -toggle -width=25<CR>")
end,
{nargs = 0}
)

また現在のディレクトリではなく特定のディレクトリを指定して開くコマンドも欲しいため別にNttコマンドして実装しました。 このコマンドでは:Ntt <dir>で\<dir>の内容を左側に開くことができます。

-- open directory <dir> by :Ntt <dir> 
vim.api.nvim_create_user_command(
'Ntt',
function (opts)
    local  dir = opts.args
    vim.cmd(":Fern " .. dir .. " -reveal=% -drawer -toggle -width=25<CR>")
end,
{nargs = 1}
)

ここで、コマンドを実装に使っているNeovimのAPIの関数vim.api.nvim_create_user_command()ですが、第一引数はコマンド名を意味する文字列で必ず大文字から始める必要があります、第二引数はコマンド実行時に実行される関数で、処理はこの関数内に実装します。第三引数は第二引数の関数に渡される引数の数を渡します。

使ってみての感想

半年ほどNERDTreeを、それより前は標準のファイラーを使っていたいためディレクトリ階層の移動やファイルを開くなどのキーバインドが違って最初は慣れませんでしたが、すぐに慣れました。 使用した感覚ではNERDTreeよりもサクサク動くように感じました。

ThinkPadを使ってみて

なぜThink Padを選んだのか?

前まではAsusのラップトップを使ってWinsows11とArch Linuxをデュアルブートしていましたが、Corei3 の2コア4スレッドのマシンでは流石に力不足を感じたのでもう少しパワーのあるマシンが欲しくなったので、

新しいラップトップのマシンとしてThinkPad E14 Gen5を買いました。

理由としてはLinuxを動かすならThink Pad! と言えそうなくらいArch Wiki 等に情報がたくさんあることや、数少ないUS配列のラップトップの候補だからです。(他だとDELLかApple(mac)くらい)

このマシンはm.2 ssdを二枚載せることができるので、デフォルトで載っている方をWindows11用にして、もう一方にはLinuxを入れてデュアルブート構成で使うことにしました。

ちなみにWindowsのライセンスは普通のHomeです、一瞬Proライセンスも考えたけどやっぱり高いな〜とおもってやめました。

Arch Linuxをインストールする

SSDを追加

まずこのマシンでややこしいのがM.2(NVme)の規格が通常の2280ではなく一回り小さな2242サイズであることと、スペースの問題から片面実装であるものが必要であった点です。

それっぽいのをamazonで調べるとThinkPadユーザーの方々がTransend製のものを使ってらっしゃるようなので、自分もそちらの512GBのものを購入しました。

ThinkPadは公式から保守マニュアルが用意されているので裏蓋を開けてssdを追加すること自体は特に問題なく行うことができました。

あと、前のAsusのマシンのUEFIの画面はアメリカンメガトレンド丸出しのFキーと矢印キーで操作するなものでしたけど、今回のものはかなり高機能でGUIでマウスも使えるものでした。最近は多いのかな?

ディスクの暗号化

別のpcでArch Linux のインストールメディアから起動するためにはセキュアブートを無効化する必要があります。

しかし、いざUEFIメニューからセキュアブートを無効化するとWindowsが起動できなくなってしまいました。

前使っていたAsusのマシンではこんなことなかったのですけどね...

色々調べてWindows側から暗号化を無効化しました。 Pro版ではBitLockerがあることは知っていたのですが、Homeでも暗号化があるのですね...

いざinstall

最近は全部自分で作業しなければならないこれまでのスタイルに加えてTUIのインストラーであるArch installがあるみたいですが、今回もこれまで通り手動でインストールしました。

DEはwaylandのコンポジッターであるSwayを入れてフルスタックなDE(Gnome,Kde,Xfecなど)は入れないことにしました。

ハマった点

Arch LinuxのインストールもDEの構成も初めてではないのでメモ書きをもとに出来たのですが、オーディオ関係がややこしかったですね...

1: オーディオ

参考: - pipewire: Arch Wiki - pipewire: Gentoo Wiki - UbuntuにPipeWireを入れて見る - Fedora34 「音がならない!」で困ったら - arch wiki alsa

alsa-utilを入れた。これまではpulsaudioを入れていたが、今回はpipewireを入れました。pulseaudioとの互換性からpipewire-pluseも追加でインストールしました。

しかし、音が出ませんでした!(出力先がダミーになってしまう!) alsamixerを起動しようとすると、サウンドカードが見つからない!と出てしまいました。

そこで症状でググると以下のフォーラムを発見しました。 Archlinux cannot find my sound card.

ここでは

We're gonna need some more info to go on, have you explicitly installed PulseAudio? If not you're using ALSA. How do you know it can't find your sound card, are you saying this just because there's no audio playing or some other reason? What's the output of lspci | grep -i audio? It maybe possible you need either (or both of) alsa-firmware or sof-firmware via this link

とあったのでalsa-firmwareとsof-firmwareを一個づつインストールして試したら、sof-firmwareを入れたことでサウンドカードが認識されてちゃんと音が出ました。

無事音が出るようになったので以下を~/.config/sway/configに以下を書き込んでF1でミュート/ミュート解除,F2で音量downF3で音量upできるようにしました。

# vluem control by F1(mute/unmute ) F2(down) ,f3(up) ,alt + f1(mute)
bindsym F1 exec pactl -- set-sink-mute @DEFAULT_SINK@ toggle 
bindsym F2 exec pactl -- set-sink-volume @DEFAULT_SINK@ -5% 
bindsym F3 exec pactl -- set-sink-volume @DEFAULT_SINK@ +5%

2: Polkit

インストール中というよりもしばらく使ってからですが...

Arch WikiのPolkitの記事を読むと、KDE,GNOMEのようなフルスタックなDEをインストールする場合は勝手に設定されていることがほとんどですが、Swayの場合は自分で設定することが必要です。

グラフィカル環境を使っている場合、グラフィカルな認証エージェントをインストールし、(xinitrc を使うなどして) ログイン時に自動で実行されるようにしてください。 Cinnamon、Deepin、GNOME、GNOME Flashback、KDE、LXDE、LXQt、MATE、theShell、Xfce には初めから認証エージェントが入っています。 他のデスクトップ環境を使っているときは、以下の実装からどれか一つを選ぶ必要があります:

polkitとしてpolkit-gnomeを自動で起動するようにするには~/.config/sway/configに

# polkit
exec /usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1

を書いて自動で起動するようにする必要がある。 この設定でDropboxのクライアントは普通に動いたのですが、root権が必要なGUIアプリの場合、polkit-gnomeを入れてSwayのコンフィグから自動起動するようにしてもpasswordを入力するwindowは出ても起動には失敗して起動できませんでした。

$ ps aux | grep polkit

を調べるとpolkit,polkit-gnome共にちゃんと起動してることは確認できました。

CLIでpasswordを要するコマンド例えばdockerのデーモンを起動する

$ systemctl start docker.service

はpasswd用のwindowが出てパスワード入力 -> 無事デーモンが起動するのに...

症状でググった結果同じような症状を発見しました。 結論としてはxorg-xhostが必要とのことです。というのもpolkitが入っていてもwayland自体は対応しないためです。

$ sudo pacman -S xorg-xhost

これでok!

3: ポインティングデバイスの設定

特にハマったりはしませんでしたが、毎回似たような設定のやり方を忘れたので備忘録として書いて置きます。

デフォルトでは~/.config/sway/configに以下のように設定すればトラックパッドでクリックができます。

# tap to click for lap tocp touch pad
input type:touchpad {
    tap enabled
    natural_scroll enabled
}

またThinkPad特有の赤色のトラックポイントはデフォルトでは加速度が考慮されて使いにくく感じたので

# for thinkpad track point
input type:pointer {
    accel_profile flat
    pointer_accel 0.3
    scroll_factor 0.5
}

と設定して加速度が考慮されないようにしました。

まあトラックポイントはあんま使っていないのですが...

インストールしたツール

ここではインストールしているツールについて軽く紹介します。

1: ログインマネージャー

これまではコンソールから手動でSwayを起動していましたが、現在はRust製のTUIのログインマネージャlemursを使っています。 シンプルかつ軽量で気に入っています。

2: バッテリー管理

まずtlpをインストールしてデーモンを設定します。

$ sudo pacman -S tlp
$ sudo systemctl enable tlp.service

電源に繋がっていない場合にCPUのクロックの制限をかけたりすれば、バッテリー持ちを良くすることが可能です。 一時期前のAsusのラップトップでは設定していましたが今は設定してないです。

ThinkPad E14 Gen5の場合ではtpacpi-batをインストールすることでバッテリーの充電のしきい値を設定できます。

設定はArch Wikiの記事を参考にしました。

$ sudo pacman -S tpacpi-bat # install

以下のコマンドで現在のしきい値を見ることができます。

$ sudo tpacpi-bat -g ST 1 # 充電を開始するパーセンテージ
$ sudo tpacpi-bat -g SP 1 # 充電を終了するパーセンテージ

ここでは充電を80%で終了し、70%以下にまで減った場合に充電を開始するように設定しました。

$ sudo tpacpi-bat -s ST 70 # 充電を開始するパーセンテージ
$ sudo tpacpi-bat -s SP 80 # 充電を終了するパーセンテージ

3: ディスプレイのlock

参考: - arch wiki セッションをロック

swaylockのフォークのswaylock-effectsを使っています。

$ sudo pacman -S swaylock-effects # install

インストールをしたあとで.bashrcに適当なエイリアスを設定すればok!

# for lock screen
alias lock='swaylock \
    --screenshots \
    --clock \
    --indicator \
    --indicator-radius 100 \
    --indicator-thickness 7 \
    --effect-blur 7x5 \
    --effect-vignette 0.5:0.5 \
    --ring-color bb00cc \
    --key-hl-color 880033 \
    --line-color 00000000 \
    --inside-color 00000088 \
    --separator-color 00000000 \
    --grace 2 \
    --fade-in 1'

4: WiFi接続

これまでは、netctlを使っていたのですが、iwctlを試しに使ってみたらこっちの方が便利に感じたのでこっちに変えました。

5: ファイルマネージャ

thunarを使っています。というのもXfce環境を長いことを使っていて使い慣れているからです。

シンプルかつ必要十分という印象です。

6: 日本語入力

自分は設定言語は英語にして、そこに日本語入力を追加する形で運用しています。

日本語入力にはfcitx5-mozcを使っています。 特に強いこだわりがあるわけではないので初めてArch Linuxをインストールしたときと同じものを使っています。

7: ターミナルエミュレータ

Xfce terminalを使っています。これもXfceデスクトップを長いこと使って使い慣れているためです。

一回Weztermも試したのですが、設定をLuaで書いていくスタイルは気に入ったのですが、日本語入力関係の設定の不具合を直せず結局Xfce terminalに戻ってきました。

8: エディタ

普段はエディタはNeovimを使っています。LSPやファイラーも設定して快適な環境です 。 しかし、Gitのブランチの様子を見るのにはVsCodeの拡張が便利だったりするのでVsCodeも入れていいます。

9: バー

waybarを使っていいます。バッテリー残量、Wifi,インプットメソッド等が見れて便利です。

$ sudo pacman -S waybar # intall

まずデフォルトの設定は/etc/xdg/waybarにあるので~/.config/にコピーします。

$ cp -r /etc/xdg/waybar  ~/.config/

このままではデフォルトのsway-barが表示されたままで、waybarは表示されないので~/.config/sway/configの項目barを以下のように編集しました。

bar {
    #position top

    # When the status_command prints a new line to stdout, swaybar updates.
    # The default just shows the current date and time.
    #status_command while date +'%Y-%m-%d %I:%M:%S %p'; do sleep 1; done
    swaybar_command waybar   

    colors {
        #statusline #ffffff
        #background #323232
        #inactive_workspace #32323200 #32323200 #5c5c5c
    }
}

ここで重要なのはstatud_command,position topをコメントアウトして、swaybar_command waybarを追加することです。

この設定を終えた後で,Super + Shift + C(デフォルトの設定)で~/.config/sway/configを再読込すると上部にbarが表示される。

しかし、私の環境では絵文字が文字化けしてしまいました。 これは、awesome-fontを入れることで解決できました[2]。

$ sudo pacman -S ttf-font-awesome

デフォルトではたくさん表示されてごちゃごちゃしているので、設定ファイル~/.config/waybar/configのを編集して必要なものみを表示するように変更しました。

今回は"height","width","modules-left","modules-center","modules-right"のみを以下のように編集しました。

    "height": 10, // Waybar height (to be removed for auto height)
    "width": 1912, // Waybar width
    "spacing": 2, // Gaps between modules (4px)
    "modules-left": ["sway/workspaces", "sway/mode", "sway/scratchpad"],
    "modules-center": ["sway/window"],
    "modules-right": ["idle_inhibitor", "pulseaudio", "network", "backlight", "sway/language", "battery", "clock", "tray"],

デフォルトの配色は自分好みではないので~/.config/waybar/style.cssを編集して好みの色になるようにしました。

10: ランチャー

rofi-lbon-wayland-onlyを使っています。

これはrofiのwayland対応版です。

元々はXfceのランチャーを使っていて、流石に変えたいなと思っていたので rofi-lbon-waylandを使っていたのですが途中で挙動がおかしくなったので rofi-lbon-wayland-onlyに変えました。

$ yay -S rofi-lbonn-wayland # install

まず、デフォルトの設定ファイルを生成するために以下のコマンドを実行します。

$ rofi -dump-config > ~/.config/rofi/config.rasi

設定箇所はたくさんありますが、今回はconfiguration {}のうち以下の部分を設定しました。

configuration {
    modes: "window,drun,run,ssh";
    font: "hack 20";
    icon-theme: "Papirus";
    combi-modes: "window,drun,run";
}

また、ショートカットキーで起動するようにするため~/.config/sway/configに以下を書き足しました。

bindsym $mod+z exec rofi -show drun

RustでWebAssemblyに入門する(1)

RustでWebAssemblyに入門するチュートリアルRust 🦀 and WebAssemblyをやってみました。

WebAssemblyには以前から興味があったのですが、JavaScriptの知識が必要でそこがハードルになってしまっていましたが、とある事情でJavaScriptを勉強することがあったため、"今だ"と思ってやってみることにしました。

Setup

ここでは必要なツールのインストールを行う。

  • 現在の自分の環境
    • OS: Arch Linux x86_64
    • rustc: 1.70.0
    • cargo: 1.70.0
    • Node: 20.8.0
    • npm: 10.2.0

基本的なRustの環境とNode.jsの環境はすでに入っていたので、wasm-pack,cargo-generateを導入した。導入はcargo installより行います。ソースコードをダウンロードしてビルドするので、ちょっと時間がかかりました。

Hello,World!

ここでは、とりあえずプロジェクトを作成して、かんたんなWebAssemblyのプログラムを動かします。今回用いるのはwasm-packで、これは、RustからWebAssemblyにコンパイルするとともにJavaScriptもしくはTypeScriptのグルーコードも生成してくれます。

ここまでは、基本的には問題なく進めることができましたが、最後のnpm run startでサーバーを建てようとしたときにOpenSSLのエラーが出てサーバーを建てられませんでした。

これを調べると、とりあえずでよければOpenSSLのレガシーモードで実行すれば良いらしいのでpackage.jsonの"script"の"start"のところにNODE_OPTIONS='--openssl-legacy-provider'を追加しました。

"scripts": {
    "build": "webpack --config webpack.config.js",
    "start": "NODE_OPTIONS='--openssl-legacy-provider' webpack-dev-server"
  },

これでnpm run start でサーバーが建つようになって無事表示ができました。

Rules of Conway's Game of Life

ここではライフゲームのルールが述べられていました。

ここまで全体の感想

慣れないJavaScriptが大変でした。特にNode.js周りがしんどかったです。