aki.blog

Codex CLIをOpenRouterで使う

Tue, 17 Feb 2026 17:25:08 +0900

OpenRouterとは？

OpenRouterは色々なAIモデルの呼び出しを一つのエンドポイント, API tokenで行えるサービスです。 OpenAIのGTP系のモデルやGoogleのGemini,AnthropicのClaudeといった有名なモデルも、コーディングで高い評価を得ているQwen等の少しマニアックなモデルも使用することが可能です。

中には、無料で使えるモデルも存在するので、とりあえず特定のモデルを試したい！という場合にはピッタリなサービスなのではないでしょうか。無料モデルでは、アクセス制限が少し厳しいのですが、$10 チャージするとアクセス制限が大幅に緩和されます。ですが、今回はとりあえず使ってみることが目的なので、それはまた後にしようかと思います。

なぜCodex CLIを選択したのか？

OpenRouterがOpenAI互換なAPIを採用しているので、OpenAI製のツールなら叩けるのできるのでは？(実際はそうはいかない…) という予測と,実装がRustな点です。

とりあえず openai/gpt-oss-120b:freeを叩いてみる

codexの導入と設定

いつも通りflakeでnix shellを作成します。

{
  description = "Codex by OpenRouter";

  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs?ref=nixos-unstable";
  };

  outputs =
    { self, nixpkgs }:
    let
      platform = "x86_64-linux";
      pkgs = nixpkgs.legacyPackages."${platform}";

    in
    {
      devShells.${platform}.default = pkgs.mkShell {
        packages = with pkgs; [
          codex
        ];

      };

    };
}

わざわざ、flakeを書きましたが、入れたツールが一個だけだったので

`1`	`nix shell nixpkgs#codex`

なり

`1`	`nix shell -p codex`

なりでも十分だったかもしれません…

アカウントの作成とAPI keyの作成

アカウントはGoogle,Github,Metamaskのアカウントで作成するか、メールアドレスで新規作成するかを選択できます。

今回筆者はGithubアカウントで作成しました。

続いて、API TOKENの作成を行います。

トークンの作成ではトークン名、とExpiration(有効期限)が必須の項目なので、適当な名前で期限は1年にしました。このトークンはOPENROUTER_API_KEYとしてCodex CLIを実行するシェルの環境変数に設定として設定しましょう。

筆者はdirenvを使用しているので、.envrcに以下のように設定しました。

`1`	`export OPENROUTER_API_KEY="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"`

また、freeなモデルの実行にはプライバシー設定で以下のように、“Enable free endpoints that may train on inputs”,“Enable free endpoints that may publish prompts"を共に有効化する必要があります。

codexの設定

参考
- OpenAI Codex CLIでOpenRouterのモデルを使用する
- Quickstart

筆者はnix shell内で

`1`	`codex --version`

を実行した時点でディレクトリ$HOME/.codex/が作成れていたのでそこにconfig.tomlを置き設定を記述しました。

$HOME/.codex/config.toml

[model_providers.openrouter]
name = "OpenRouter"
base_url = "https://openrouter.ai/api/v1"
env_key = "OPENROUTER_API_KEY"

実行

以下のコマンでCodex CLIを実行します。ここで、--configはconfig.tomlに書かれた設定を上書きするオプションで、 --modelは名前の通りモデル名を指定するためのオプションです。

`1`	`codex --config model_provider=openrouter --model openai/gpt-oss-120b:free`

MCPサーバーを動かす

ここでは、設定でハマったポイントだけ

MCPサーバーの設定は、プロジェクトごとに.codex/config.tomlを置くか、グローバルに$HOME/.codex/config.tomlに置くかの二通りの方法があります。

stdioで通信するタイプのサーバーの場合は、commandにサーバーの起動コマンドを設定します。

1
2

[mcp_servers.<server name>]
command = "<command>"

一方、httpでやりとりするMCP サーバーではcommandではなくてurlにURLを設定します。

1
2

[mcp_servers.<server name>]
url = "<URL>"

環境変数を参照するMCPサーバーの場合は少しややこしくて、 Codexを呼び出すシェルで設定されていても無視されます(おそらくわざとそうしている)

実行するシェルで環境変数ENV_VARが設定されていてそれを参照したいならば以下のように$で展開するように設定する必要があります。

1
2
3

[mcp_servers.<server name>]
command = "<command>"
env = { ENV_VAR = "$ENV_VAR" }

CodeCompanion.nvim + Gemini CLIで四苦八苦

Sun, 15 Feb 2026 15:30:32 +0900

プロローグ

Neovimでは、olimorris/codecompanion.nvimというプラグインによってAIと連携したコーディングを行うことができます。筆者はこれまでは、直接GoogleのGeminiのAPIを叩くことでAI Chatを開き、指定したバッファの内容を与えてコーディングを行う設定は行っていました。しかし、この設定では、コーディングエージェントとしてソースコードを生成させたりするようなことはできません。

エディタやIDEとコーディングエージェントのようなAIエージェントとはACP(Agent Client Protocol)というプロトコルによってデータのやりとりをすることが可能で、有名どころでは、ZedやJetbrainsの各種IDEが対応しています。 NeovimでもCodeCompanion.nvimとによってACPに対応したAIエージェントと連携することが可能です。

筆者はCodeCompanion.nvimで使うAIのサービスとしては、GoogleのGeminiを使用していたので、 Geminiのエージェントである、Gemini CLIをNeovimから使えるように設定を行うことにしました。

とりあえず設定してみたものの…

CodeCompanionの公式のドキュメントを参考にして、とりあえず設定してみました。今回追加した設定は、acp = {...}の部分です。

参考
- Setup: Gemini CLI

local my_adapter = { name = 'gemini_cli', model = 'gemini-2.5-flash' }
require('codecompanion').setup({
  adapters = {
    http = {
      gemini = function()
        return require('codecompanion.adapters').extend('gemini', {
          env = { api_key = vim.env.GEMINI_API_KEY },
        })
      end,
      azure_openai = function()
        return require('codecompanion.adapters').extend('azure_openai', {
          env = {
            api_key = vim.env.AZURE_OPENAI_API_KEY,
            endpoint = vim.env.AZURE_OPENAI_END_POINT,
          },
        })
      end,
    },
    -- 今回追加した設定はコレ
    acp = {
      gemini_cli = function()
        return require('codecompanion.adapters').extend('gemini_cli', {
          defaults = {
            auth_method = 'gemini-api-key', -- "oauth-personal"|"gemini-api-key"|"vertex-ai"
          },
          env = { GEMINI_API_KEY = vim.env.GEMINI_API_KEY },
        })
      end,
    },
  },
  -- Action Palette
  display = {
    action_palette = {
      width = 95,
      height = 10,
      prompt = 'Prompt ', -- Prompt used for interactive LLM calls
      provider = 'fzf_lua',
      opts = {
        show_preset_actions = true, -- Show the preset actions in the action palette?
        show_preset_prompts = true, -- Show the preset prompts in the action palette?
        title = 'CodeCompanion actions', -- The title of the action palette
      },
    },
  },

  opts = {
    language = 'Japanese',
    log_level = 'DEBUG',
  },
  interactions = {
    chat = {
      adapter = my_adapter,
      slash_commands = {
        ['buffer'] = {
          opts = {
            provider = 'fzf_lua',
          },
        },
        ['file'] = {
          opts = {
            provider = 'fzf_lua',
          },
        },
        ['help'] = {
          opts = {
            provider = 'fzf_lua',
          },
        },
        ['symbols'] = {
          opts = {
            provider = 'fzf_lua',
          },
        },
        ['workspace'] = {
          opts = {
            provider = 'fzf_lua',
          },
        },
      },
    },
    inline = {
      adapter = my_adapter,
    },
    agent = {
      adapter = my_adapter,
    },
  },
})

しかし、この設定下でチャットを開き、対話を初めようとすると以下のエラーが出てチャットができませんでした。

`1`	`[ACP::Handler] Internal error`

CodeCompanionのログである、$HOME/.local/state/nvim/codecompanion.logを見ても同じメッセージしかなくて問題の特定ができませんでした。ログのレベルをopts.log_level = 'TRACE'に設定して、より詳細なデバッグ情報を取得するようにしても結果は同じでした。

コードを手探る

どのへんを見れば原因が特定できそうか？

まず、ソースに対してgrepしてエラーメッセージを出している場所の当りをつけてみます。

1
2
3

grep -rn ACP::Handler .
./lua/codecompanion/interactions/chat/acp/handler.lua:239:    log:debug("[ACP::Handler] Failed to update tool call line for toolCallId %s", tool_call.toolCallId)
./lua/codecompanion/interactions/chat/acp/handler.lua:303:  log:error("[ACP::Handler] %s", error)

lua/codecompanion/interactions/chat/acp/handler.lua:303が怪しく見えますね。そこで、この行に対応する関数ACPHandler:handle_error()にブレークポイントを貼って実行してみると、確かにその関数が呼ばれることでエラーメッセージが出力されることが分かりました。

その関数を呼び出す関数をデバッガやLSPによる定義ジャンプで探索したところ、 lua/codecompanion/acp/init.luaに実装されている関数Connection:handle_rpc_message()が鍵となると考えました。その関数の実装を以下に示します。

---Handle incoming JSON message
---@param line string
function Connection:handle_rpc_message(line)
  if not line or line == "" then
    return
  end

  -- If it doesn't look like JSON-RPC, skip it
  if not line:match("^%s*{") then
    return
  end

  local ok, message = pcall(self.methods.decode, line)
  if not ok then
    return log:error("[acp::handle_rpc_message] Invalid JSON:\n%s", line)
  end

  if message.id and not message.method then
    self:store_rpc_response(message)
    if message.result and message.result ~= vim.NIL and message.result.stopReason then
      if self._active_prompt and self._active_prompt.handle_done then
        self._active_prompt:handle_done(message.result.stopReason)
      end
    end
  elseif message.method then
    self:handle_incoming_request_or_notification(message)
  else
    log:error("[acp::handle_rpc_message] Invalid message format: %s", message)
  end

  if message.error and message.error.code ~= -32603 then
    log:error("[acp::handle_rpc_message] Error: %s", message.error)
  end
end

この関数では、サーバー(ここではAIエージェントであるGemini CLI)からのレスポンスをLuaのテーブルにデシリアライズしてstore_rpc_response()に渡しています。さらにこのstore_rpc_response()はレスポンスのうちエラー部分のみPromptBuilder:handle_error()に渡して結果エラーが出力がされています。

このことから、デシリアライズされたテーブルを全て見ればログに表われないメッセージを見れそうに考えました。

当りは付いたので、ロガーを入れて確かめてみる

ここまでで当りはついたので、ロガーを入れてメッセージを見てみました。

パッチを当てる時はプラグインマネージャーlazy.nvimの設定を

{
  'olimorris/codecompanion.nvim',
  dependencies = {
    'nvim-lua/plenary.nvim',
    'nvim-treesitter/nvim-treesitter',
  },
  opts = {},
  lazy = false,
  dir = '/home/aki/Src/codecompanion.nvim_18.5/codecompanion.nvim_debug_acp',
}

のように適当な場所に置いたパッチを当てる前提のコードへのパスをdir = <path>で与えると作業がしやすいです。

CodeCompanion.nvimのv18.5.0(e0780fa9fda504ffb89307cabcb6cbe1ce8eb60c) に以下のようなパッチを当ててログを見てみました。

diff --git a/lua/codecompanion/acp/init.lua b/lua/codecompanion/acp/init.lua
index 7bd8ce3e..5c2f4bb8 100644
--- a/lua/codecompanion/acp/init.lua
+++ b/lua/codecompanion/acp/init.lua
@@ -467,6 +467,14 @@ function Connection:handle_rpc_message(line)
     return log:error("[acp::handle_rpc_message] Invalid JSON:\n%s", line)
   end
 
+  local log_file = io.open("/home/aki/Src/codecompanion.nvim_18.5/gemini_cli_debug.log", "a")
+  if log_file then
+    log_file:write("--- RAW RESPONSE START ---\n")
+    log_file:write(vim.inspect(message))
+    log_file:write("\n--- RAW RESPONSE END ---\n")
+    log_file:close()
+  end
+
   if message.id and not message.method then
     self:store_rpc_response(message)
     if message.result and message.result ~= vim.NIL and message.result.stopReason then

保存されたログを見てみると、Internal errorと出力される時のレスポンスが以下のようになっていることが分りました。

{
  error = {
    code = -32603,
    data = {
      details = "You have exhausted your daily quota on this model."
    },
    message = "Internal error"
  },
  id = 4,
  jsonrpc = "2.0"
}

このレスポンスからは、レート制限に引っかかったことが原因のように見えますが、 Google AI Studioの画面を見ても、gemini-2.5-flashでレート制限は確認されませんでした。

そのため、原因としてはうまくモデルの選択ができていないことであると考えられます。

`commands.default = {}`で明示的にモデル名を与える => 動く

モデル選択がうまくできないなら、Gemini CLIのコマンドラインオプションのレベルで指定すれば動くのではと考え、以下のように設定しました。

acp = {
  gemini_cli = function()
    return require('codecompanion.adapters').extend('gemini_cli', {
      defaults = {
        auth_method = 'gemini-api-key', -- "oauth-personal"|"gemini-api-key"|"vertex-ai"
      },
      commands = {
        default = {
          'gemini',
          '--experimental-acp',
          '--model',
          'gemini-2.5-flash',
        },
      },

      env = { GEMINI_API_KEY = vim.env.GEMINI_API_KEY },
    })
  end,
},

モデル名をハードコードした柔軟性に欠けるコードですが、無事正常に動作しました。

モデル選択をスマートに

流石にモデル名のハードコードは嫌なので、最終的にチャットを開く時に選択できるように設定しました。

gemini_cli = function()
  return require('codecompanion.adapters').extend('gemini_cli', {
    defaults = {
      auth_method = 'gemini-api-key', -- "oauth-personal"|"gemini-api-key"|"vertex-ai"
    },
    commands = {
      default = {
        'gemini',
        '--experimental-acp',
        '--model',
        model_selector({ 'gemini-2.5-flash', 'gemini-2.5-flash-lite' }, 'gemini-2.5-flash'),
      },
    },

    env = { GEMINI_API_KEY = vim.env.GEMINI_API_KEY },
  })

ここで、model_selector()の実装は以下で、vim.ui.select()によってインタラクティブにモデル選択ができるようにしました。

local model_selector = function(models, default_model)
  local model = default_model

  vim.ui.select(models, {
    prompt = 'Select model:',
    format_item = function(item)
      return item
    end,
  }, function(choice)
    if choice then
      model = choice
    end
  end)

  return model
end

感想

エラーが発生した時に一部しか出力&ロギングされないため、原因が特定できなくて大変でした。ロギングは大切さが身に染みるような気がします。

怪しい箇所の特定には前に行なったデバッガの設定がとても約に立ちました。

Neovim上のLuaのコードをNeovimでデバッグ実行する

Thu, 05 Feb 2026 04:00:31 +0900

やりたいこと

やりたいことは、Neovimのプラグインやプラグインまでとはいかなくても設定した自作のコマンドのデバッグ実行です。

しかし…

普通のLuaのコードの場合であれば、普通のLuaのデバッガーを使えばデバッグが可能です。 mfussenegger/nvim-dapのドキュメントである https://codeberg.org/mfussenegger/nvim-dap/wiki/Debug-Adapter-installationを見てみると、EmmyLua/EmmyLuaDebuggerやtomblind/local-lua-debugger-vscode を使えばNeovimからデバッグ実行ができるようです。(筆者はやったことはありませんが…)

しかし、ここで考えているケースでは、Luaを実行するランタイムがNeovimに組み込まれているため、上記で述べた方法ではデバッグができません。

動機

こんなことをやりたいと思った動機は、プラグインのコードはイベント駆動で次々と実行されるコードが移動するため、LSPによる定義ジャンプだけではコードを読むのが大変だったからです。ある程度大規模なプラグインでは、どこから読めばいいか分らないことも多々あります。

どの手法を使うか？

少しニッチなケースですが、地球上には同じようなことを考える(?)人間が存在するようで何人かの先駆者がいました。

日本語の記事としては以下が見つかりました。

Zenn: Lua製Neovimプラグインのテストをデバッグする

この方法はVsCode向けのデバッガの実装を用いて、デバッグしていますが、個人的に難点だと思うのが、

Node.jsに依存するため環境構築が面倒くさい
git cloneしてから自分でnpm buildでビルドする必要がある
さらにLua on Neovimをインタプリンタとして実行する用のツールも必要

です。

ちなみにこの記事は以下の英語の記事を参考にして書かれています。

Debugging Lua in Neovim

先程のnvim-dapのドキュメントにneovim-luaの項目があったので見てみると、 jbyuki/one-small-step-for-vimkindを使う方法が紹介されていました。

この方法は他に依存するソフトウェアは存在せず、Neovimのプラグインとしてインストールしてnvim-dapの設定に追加するだけで完了します。そのため、筆者にはとても魅力的に感じこの方法を採用しました。

setup

jbyuki/one-small-step-for-vimkind/doc/osv.txtに詳細な設定ガイドがあるので,その通りの設定でokです。

インストール

jbyuki/one-small-step-for-vimkindは、nvim-dapの依存関係としてインストールします。筆者はlazy.nvimを使用しているので、以下のように設定しました。

1
2
3

{ 'mfussenegger/nvim-dap', dependencies = {
  'jbyuki/one-small-step-for-vimkind',
}, lazy = false },

アダプタの設定

nvim-dapに生やす設定は以下です。他の言語のアダブターの設定とほぼ同じなので、経験があれば特に困らないと思います。

dap.configurations = {
--[[
他の言語向けの設定
--]]

  lua = {
    {
      type = 'nlua',
      request = 'attach',
      name = 'Attach to running Neovim instance',
    },
  },
}

dap.adapters.nlua = function(callback, config)
  callback({ type = 'server', host = config.host or '127.0.0.1', port = config.port or 8086 })
end

vim.keymap.set('n', '<leader>yl', function()
  require 'osv'.launch({ port = 8086 })
end, { noremap = true })

相違点としては、

1
2
3

vim.keymap.set('n', '<leader>yl', function()
  require 'osv'.launch({ port = 8086 })
end, { noremap = true })

で、デバッグされる側のNeovimを<leader>ylでサーバーとして起動するキーバインドくらいです(このキーバインドはこの記事の後半で使います！)。

その他解説上必要になりそうな設定

ブレークポイントの設定やデバッグの開始/停止などのnvim-dapの操作ですが、筆者は以下設定でキーバインド/コマンド化したので、参考までに以下に載せておきます。

local dap = require('dap')
-- commands & keymap
-- Setting breakpoints
vim.api.nvim_create_user_command('B', function()
  require('dap').toggle_breakpoint()
end, { nargs = 0 })

-- ref: ':help dap-user-commands', ':help dap-api'
-- clearn all breakpoints
vim.api.nvim_create_user_command('Bc', function()
  require('dap').clear_breakpoints()
end, { nargs = 0 })

-- Luanching debug session and resuming execution
vim.api.nvim_create_user_command('C', function()
  require('dap').continue()
end, { nargs = 0 })

-- relaunch current session
vim.api.nvim_create_user_command('Cr', function()
  require('dap').restart()
end, { nargs = 0 })

-- terminate current session
vim.api.nvim_create_user_command('Ct', function()
  require('dap').terminate()
end, { nargs = 0 })

vim.fn.sign_define('DapBreakpoint', { text = '🛑', texthl = '', linehl = '', numhl = '' })
vim.fn.sign_define('DapStopped', { text = '➡️', texthl = '', linehl = '', numhl = '' })

-- Stepping through code
-- ref: ':help dap-mapping', ':help dap-api'
vim.keymap.set('n', '<M-s>', function()
  require('dap').step_into()
end, { desc = 'Debug: Step Into' })

vim.keymap.set('n', '<M-n>', function()
  require('dap').step_over()
end, { desc = 'Debug: Step Over' })

vim.keymap.set('n', '<M-f>', function()
  require('dap').step_out()
end, { desc = 'Debug: Step Out' })

vim.keymap.set('n', '<M-u>', function()
  require('dap').up()
end, { desc = 'Debug: up' })

vim.keymap.set('n', '<M-d>', function()
  require('dap').down()
end, { desc = 'Debug: down' })

コマンド(キーバインド)と操作の対応は以下の表の通りです。

key	function	操作
:B	require(‘dap’).toggle_breakpoint()	現在のカーソル位置でのブレークポイントのトグル
:Bc	require(‘dap’).clear_breakpoints()	設定したブレークポイントをすべてクリア
:C	require(‘dap’).continue()	継続
:Cr	require(‘dap’).restart()	セッションの再起動
:Ct	require(‘dap’).terminate()	セッションの終了
Alt + n	require(‘dap’).step_over()	次の行の実行で、関数呼び出しは実行するが、中には入らない
Alt + s	require(‘dap’).step_into()	次の行の実行で、関数呼び出しがあったら、その中に入る
Alt + f	require(‘dap’).step_out()	現在いる関数を最後まで実行して、呼び出し元に戻る

デバッグ実行を開始する

Luaのスクリプトをデバッグ実行する

まずはexample.luaを例としてデバッグを行なってみます。

print("start")

for i = 1, 10 do
	print("i " .. i)
end

print("end")

以降の説明では、目的のコードを実行しデバッグされる側をNeovim(A)、ブレークポイントを設定してコードを開いて読む側をNeovim(B)とします。

まず、Neovim (A)を起動して、<leader>ylによってデバッグされる側のサーバーを起動します。

次に、Neovim (B)を起動して、デバッグ実行したいコードを開いてブレークポイントを:Bによって設定し、:Cによってデバッグを開始します。この時ブレークポイントとなる行の左側は’🛑‘に変りますがコードはまだ実行されていません。

最後に、Neovim (A)で:luafile ./example.luaを実行して、デバッグしたいスクリプトの実行を行います。
この時、Neovim (B) でデバッグ実行が開始され、左側の’🛑‘が’➡️’に変化します。

以降は、Alt + n等でデバッグ実行ができるはずです。

自作コマンドや、関数にした処理は？

Neovimの設定中の処理すなわち、$HOME/.config/nvim/init.luaにぶら下がっている設定中のスクリプトですが、筆者は今のところ、Neovimの起動時の読み込み処理のデバッグ実行のやり方は分りません。

しかし、コマンドやグローバルな関数としてアクセス可能な場合では上の例で:luafileでスクリプトを実行するタイミングで,それらの実行を行うことでデバッグ可能です。

プラグインの場合は？

基本的には、自作コマンド等と同じですが、コードを開いてブレークポイントを貼るコードは、実際にプラグインとして読み込まれるディレクトリ(lazy.nvimの場合多くは$HOME/.local/share/nvim/lazy/<plugin>)のものを開くことが必要です。

また、lazy.nvimの場合では、インストールするプラグインで以下のように、dir = <path>としてプラグインを置いたパスを指定できます。

{
  <repo>/<plugin name>,
  opts = {},
  dir = <path to plugin>,
}

そのため、コードの一部にロガーを仕込みたい場合や、プラグイン開発のようにコードの編集とデバッグと編集を繰り返す場合では、この方法が有用です。

感想

このことを調べた時は、一応できるがあまり使わなかな~と思っていました。しかし、最近思い通りに動かないプラグインのコードを調べるのに大活躍しました。今後もちょくちょく出番がありそうな気がします。

Neovimでリモートデバッグの設定をする

Thu, 05 Feb 2026 03:00:57 +0900

この記事について

Neovimではnvim-dap,nvim-dap-ui を使用することで、デバッグを行うことができます。しかし、Neovimからデバッグを開始する方法では引数を与える場合、通常ターミナルで実行する場合とは異なる慣れない入力をする必要があるためなかなか面倒です

デバッグの手法の中には、デバッガ側でプログラムを起動した状態にしておき、そこにエディタ側からアタッチする方法があります。この方法ではデバッガとエディタの間の通信がTCP/IPで行なわれ、別のマシンで実行しているプログラムをデバッグすることができるので、リモートデバッグと呼ばれています。

Python向けには、1年ほど前にリモートデバッグが実行できるように設定していました。しかし、C/C++,Rustの設定は長いこと設定していなかったので、ようやく重い腰を上げて設定をしました。

今回はあくまでも、同一ホストで動かしているプログラムのデバッグに限定しますが、接続先のホスト名(もしくはIPアドレス)を変更すれば本当に"リモート"なデバッグにも応用できます。

前提

今回の記事ではNeovimでのデバッグ実行の設定ですが、以下のことを前提にしています。

デバッガの実行はmfussenegger/nvim-dapを使用する

デバッガ側

Pythonの場合

Pythonのデバッグにはdebugpyを使用し、インストールはプロジェクトごとに以下のように実行します。

1
2
3

uv init
uv add debugpy --dev # dev-dependencyとしてインストール
source .venv/bin/activate # venvの有効化

ここで、uvによるインストールですが、uv add <pkg name>でインストールする際には--devを付けることでdev-dependencyとしてインストールすることができます。この場合、uv buildでwheelをビルドする場合などで、dev-dependencyとしてインストールされたパッケージが除外されます。

C/C++/Rustの場合

gdbをインストールして、gdbserverが実行できるようになっていればOKです。

Neovim側

Python by debugpy

nvim-dapの設定は以下のように行いました。内容としては、IPアドレスlocalhost(127.0.0.1),ポート5678で立てたサーバー(debugpy)に対してクライアント(エディタ)をアタッチするようになっています。

dap.adapters = {
  debugpy_tcp = {
    type = 'server',
    port = assert('5678', '`connect.port` is required for a python `attach` configuration'),
    host = '127.0.0.1',
    options = {
      source_filetype = 'python',
    },
  },
}

dap.configurations = {
  python = {
    {
      name = 'attach to debugpy',
      type = 'debugpy_tcp',
      request = 'attach',
      program = '${file}',
      pythonPath = function()
        local cwd = vim.fn.getcwd()
        if vim.fn.executable(cwd .. '/venv/bin/python') == 1 then
          return cwd .. '/venv/bin/python'
        elseif vim.fn.executable(cwd .. '/.venv/bin/python') == 1 then
          return cwd .. '/.venv/bin/python'
        else
          return '/usr/bin/python'
        end
      end,
    },
  }
}

参考
- GitHub: microsoft/debugpy
- Zenn: VSCode + debugpy でPython CLIをターミナルから快適にデバッグする

C/C++/Rust by gdb

以下を参考に設定しました。Pythonの場合と意味としては同じで、IPアドレスlocalhost(127.0.0.1),ポート5678で立てたサーバー(gdbserver)に対してクライアント(エディタ)をアタッチするようになっています。

local dap = require('dap')

dap.adapters = {
  gdb = {
    type = 'executable',
    command = 'gdb',
    args = { '--interpreter=dap', '--eval-command', 'set print pretty on' },
  },
  --[[
  other settings
  --]]
}

dap.configurations = {
  cpp = {
  --[[
  other settings
  --]]
    {
      name = 'attach to gdbserver',
      type = 'gdb',
      request = 'attach',
      target = string.format('localhost:%d', port_default),
      cwd = '${workspaceFolder}',
    },
  },
  rust = {
  --[[
  other settings
  --]]
    {
      name = 'attach to gdbserver',
      type = 'gdb',
      request = 'attach',
      target = string.format('localhost:%d', port_default),
      cwd = '${workspaceFolder}',
    },
  }

参考
- https://codeberg.org/mfussenegger/nvim-dap/wiki/Debug-Adapter-installation#c-c-rust-via-gdb

デバッグの実行

Pythonの場合は、以下のコマンドでデバッガのサーバーを起動します。

`1`	`python -m debugpy --wait-for-client --listen 5678 <program> <args>`

一方、C/C++,Rustの場合では以下のようにデバッガのサーバーを起動します。

`1`	`gdbserver :5678 ./<program> <args>`

サーバー側が起動した後では以下の手順でデバッグを開始します。

require('dap').continue()を実行してポップアップからattach to gdbserver(C/C++,Rustの場合)もしくは,attach to debugpy(Pythonの場合)となるアダプターを選択する。
require('dap').toggle_breakpoint()で適当な場所にブレークポイントを設定する。
require('dap').continue()でデバッグ開始する。

筆者はこれらの操作を以下のようなキーに割り当てています。

key	function	操作
:B	require(‘dap’).toggle_breakpoint()	現在のカーソル位置でのブレークポイントのトグル
:Bc	require(‘dap’).clear_breakpoints()	設定したブレークポイントをすべてクリア
:C	require(‘dap’).continue()	継続
:Cr	require(‘dap’).restart()	セッションの再起動
:Ct	require(‘dap’).terminate()	セッションの終了
Alt + n	require(‘dap’).step_over()	次の行の実行で、関数呼び出しは実行するが、中には入らない
Alt + s	require(‘dap’).step_into()	次の行の実行で、関数呼び出しがあったら、その中に入る
Alt + f	require(‘dap’).step_out()	現在いる関数を最後まで実行して、呼び出し元に戻る

コンテナの名のプラグラムをデバッグする場合

また、コンテナの中のプログラムをデバッグするには、コンテナの起動時にポートフォワーディング(-p <port>:<port>)して、コンテナ内でのサーバーの起動時のIPアドレスとポートを"0.0.0.0:<port>“に設定するとそのまま使用できます。

参考
- コンテナ上のPythonコードをNeovimでデバッグ(nvim-dap)

感想

C/C++,Rustのgdbによるリモートデバッグの設定は結構ややこしいように感じていましたが、思ったよりも簡単に設定できました。これからのデバッグがより快適になりそうです。

resession.nvimからdirenvを叩けるようにした

Sun, 11 Jan 2026 00:25:21 +0900

direnvとNeovim

direnvとその実行について

direnvは.envrcの置かれたディレクトリで実行すると、記述された環境変数等の設定を適用したシェルに入ることができるツールです。特にnix-direnvと連携させると.envrcに以下のように

`1`	`use flake`

と設定している場合では、flake.nixに設定したnix-shell入ることができるのでとても便利です。

direnvの実行ですが、actionshrimp/direnv.nvim(以下ではdirenv.nvimとする)というプラグインを使用すると、シェルからではなくNeovimから直接実行することができるようになります。

参考
- actionshrimp/direnv.nvim

このプラグインでは、direnvを実行するフックとしてNeovimのカレントディレクトリの移動もしくはバッファ読み込みを使用するので、 Neovimでプロジェクトを開いた時に設定した環境に入ることができます。

ディレクトリ移動で、direnvの実行をフックする場合は以下のように設定します。

-- 以下はlazy.nvimから読み込まれるとする
{
  'actionshrimp/direnv.nvim',
  opts = {
    async = true,
    type = 'dir', -- ディレクトリ移動でフックする場合
    --type = 'buffer', -- バッファの読み込みでフックする場合
    on_direnv_finished = function() -- 実行後に実行される関数
      print('direnv: ok!')
    end,
  },
}

Neovimでどうプロジェクトを開くか？

筆者は一旦プロジェクトのディレクトリに移動して、Neovimを開くのではなく、適当なディレクトリ上で resession.nvimというプラグインを使用して開いています。 resession.nvimでは、前回の起動時に開いたwindow、バッファ等の状態をセッションとして保存しておいて、起動時にロードして同じ状態を作ることができます。なので、一旦ターミナルでプロジェクトのディレクトリまで移動してからNeovimを開くという二段階の作業が不要な点が魅力です。

筆者は以下のようなキーバインドで操作できるように設定しています。

キーバインド	動作
<leader>ss	現在のセッションを保存
<leader>sl	保存したセッションの読み込み
<leader>sd	保存したセッションの削除

その時に必要なLuaのコードは以下です。

-- 別のファイルに記述した以下が`lazy.nvim`によって読み込まれるように設定されているものとする
--[[ 
local ressesion = {
  'stevearc/resession.nvim',
  opts = {},
}
--]]

local resession = require('resession')

resession.setup({
  extensions = {
    actionshrimp_direnv = {},
  },
})

-- Resession does NOTHING automagically, so we have to set up some keymaps
vim.keymap.set('n', '<leader>ss', resession.save)
vim.keymap.set('n', '<leader>sl', resession.load)
vim.keymap.set('n', '<leader>sd', resession.delete)

参考
- resession.nvim

今回のテーマはここまでで登場した三者を組み合せて上手く動かすことです。

resession.nvimとdirenv.nvimを併用することで起る問題について

こういうことを書いているくらいなので、単に両者をそれぞれ設定しただけでは想定した通りには動きません。

特にプロジェクトローカルにLanguage Serverをインストールしてdirenvの実行で有効化するようなケースでは、 direnvの実行されるタイミングがとても重要です。

direnv.nvimをディレクトリ移動でフックする場合

ディレクトリ移動でフックする場合では、resession.nvimでプロジェクトを開いてもdirenvは実行されませんでした。

そのため、保存したセッションでソースコードが開かれている状態だった場合ではLanguage Serverが有効化されず実行できないままでアタッチされてしまうのでエラーが発生してしまいます。

運用としては、セッションを保存する時はLSPが関係のないREADME.md等を開いた状態でセッションを保存して、わざわざ:cd .を実行してディレクトリ移動のイベントを行っていました(面倒くさい!)。

direnv.nvimをバッファの読み込みでフックする場合

バッファ読み込みでフックする場合では、想定通りに動く場合と動かない場合とのランダムな結果となりました。これはバッファが読み込まれた後での、direnv.nvimを通したdirenvの実行とLanguage Serverの初期化が競合するためだと考えられます。

解決策を探る

現状としては、

そもそも,direnv.nvimによる初期化を諦めてプロジェクトのディレクトリでdirenvを実行してからNeovimを開く
先程のdirenv.nvimをディレクトリ移動でフックする場合のように、セッションの保存時にREADME.mdを開いた状態にして、開いてから:cd .でディレクトリ移動のイベントを発生させる

のようにして運用していました。

しかし、やはりresession.nvimからシームレスにプロジェクトを開きdirenvによって環境の初期化を行えるようにしたいものです。そこで、resession.nvimでプロジェクトを開いた場合ではなぜ、direnvが実行されないのか、どのような流れで、保存したセッションを読み込み、バッファ&ウィンドウとして開くのかを調べれば糸口を掴めそうだったので、ソースコードを読んでみました。

resession.nvimの勘所

resession.nvimの保存したセッションをロードする処理を読み挙動を探ってみます。

外部に公開されているload()はプラグインのソースコードの中ではlua/resession/init.lua中のM.load()として実装さています。この関数のコードを全て解説するととても長くなるので勘所をかいつまんで見ていきます。

まず重要なのは、 487 ~ 488行目でイベント駆動で自動実行される処理を全て無効化していることです。そのため、この無効化が解除されるまではLanguage Serverのアタッチのような自動実行される処理は実行されません。当然direnv.nvimも実行されません。

1
2
3

  -- Don't trigger autocmds during session load
  local eventignore = vim.o.eventignore
  vim.o.eventignore = "all"

続いて、517 ~ 545行目ではセッションとして保存しておいたバッファを読み込みます。多くのLanguage Serverは対象とするソースコードのカレントバッファへの読み込みをフックとしてアタッチ処理を行いますが、今回は無効化されているのでバッファの読み込み中には実行されません。

  local last_bufnr
  for _, buf in ipairs(data.buffers) do
    local bufnr = vim.fn.bufadd(buf.name)
    last_bufnr = bufnr

    if buf.loaded then
      vim.fn.bufload(bufnr)
      vim.b[bufnr]._resession_need_edit = true
      vim.b[bufnr].resession_restore_last_pos = true
      vim.api.nvim_create_autocmd("BufEnter", {
        desc = "Resession: complete setup of restored buffer",
        callback = function(args)
          if vim.b[args.buf].resession_restore_last_pos then
            pcall(vim.api.nvim_win_set_cursor, 0, buf.last_pos)
            vim.b[args.buf].resession_restore_last_pos = nil
          end
          -- This triggers the autocmds that set filetype, syntax highlighting, and checks the swapfile
          if vim.b._resession_need_edit then
            vim.b._resession_need_edit = nil
            vim.cmd.edit({ mods = { emsg_silent = true } })
          end
        end,
        buffer = bufnr,
        once = true,
        nested = true,
      })
    end
    util.restore_buf_options(bufnr, buf.options)
  end

547 ~ 550行では、カレントディレクトリを保存されたセッションでの場所に移動しています。上では、ディレクトリ移動でdirenv.nvimをフックした場合、resession.nvimでプロジェクトを読み込むと実行されないとありましたが、このディレクトリ移動中は自動実行される処理が無効化されているためです。

  -- Ensure the cwd is set correctly for each loaded buffer
  if not data.tab_scoped then
    vim.api.nvim_set_current_dir(data.global.cwd)
  end

続く580 ~ 593行には以下のような処理がありました。

  for ext_name in pairs(config.extensions) do
    if data[ext_name] then
      local ext = util.get_extension(ext_name)
      if ext and ext.on_post_load then
        local ok, err = pcall(ext.on_post_load, data[ext_name])
        if not ok then
          vim.notify(
            string.format('[resession] Extension "%s" on_post_load error: %s', ext_name, err),
            vim.log.levels.ERROR
          )
        end
      end
    end
  end

extensionsとon_post_loadというキーワードがあったので、ロードした後で実行が可能な処理をユーザーが定義して、差し込める機能があるように見えたのでREADMEを見てみました。

結果としては予測通りで、以下のような形式で実行したい処理を実装し、

local M = {}

---Restore the extension state
---@param data The value returned from on_save
M.on_post_load = function(data)
  -- This is run after the buffers, windows, and tabs are restored
end

return M

設定ファイル中のlua/resession/extensions/<extension name>.luaに配置して、resession.nvimの設定から

require("resession").setup({
  extensions = {
    <extension name> = {
      -- these args will get passed in to M.config()
    },
  },
})

のように有効化すると実行することが可能です。今回は説明しませんが、on_save(セッションの保存時),on_pre_load(セッションをロードする前)等の他のイベントに対して何かユーザーの定義した処理を行うことも可能です。

最後に、610 ~ 611行で一旦全て無効化した自動実行を元々無効化されていた物のみに戻しています。

1
2

  vim.o.eventignore = eventignore
  vim.o.shortmess = shortmess

on_post_load()にうまいこと処理を実装すれば目的は達成できそうです。

解決策(1: 失敗)

ここまで読めば以下は明らかに失敗することが分ると思いますが、作業していた当時はon_post_load()の実行されるタイミングを良く理解していなかったため以下を考えました。

ロードの後で再びディレクトリ移動を行いdirenvの実行をフックする

設定は以下です

lua/resession/extensions/actionshrimp_direnv.lua

local M = {}

M.on_save = function()
  local project_dir_prev_session = vim.fn.getcwd()
  return { project_dir = project_dir_prev_session }
end

M.on_post_load = function(data)
  print(string.format('move to project dir: %s', data.project_dir))
  require('direnv-nvim').hook()
end

return M

lua/session.lua

resession.setup({
  extensions = {
    actionshrimp_direnv = {},
  },
})

失敗した理由は明かで、on_post_load()が実行されるタイミングでは、自動実行は無効化されているためです。

direnvの勘所

ここで、もう諦めて自分で1からdirenvを叩くコードを書こうと考えたので、参考にするために、actionshrimp/direnv.nvimのコードを読んでみることにしました。

168~197行エントリーポイントは、読み込んだ時に実行されるM.setup()として公開されます。ポイントとなるのは、設定でフックとなるイベントがバッファ読み込みな場合はsetup_buffer()が、ディレクトリ移動な場合はsetup_dir()が実行される点です。

M.setup = function(opts)
	OPTS = vim.tbl_deep_extend("force", OPTS, opts)
	M.OPTS = OPTS
	if OPTS.type == "buffer" then
		setup_buffer()
	end
	if OPTS.type == "dir" then
		setup_dir()
	end
	if OPTS.on_direnv_finished ~= nil then
		local au_opts = OPTS.on_direnv_finished_opts

		vim.api.nvim_create_autocmd("User", {
			pattern = au_opts["pattern"],
			group = "direnv-nvim",
			once = au_opts["once"],
			callback = function(args)
				if
					au_opts["filetype"] == nil
					or (au_opts["filetype"] == vim.bo[args.buf].filetype or _has_filetype(au_opts["filetype"], vim.bo[args.buf].filetype))
				then
					OPTS.on_direnv_finished({
						buffer = args.buf,
						filetype = vim.bo[args.buf].filetype,
					})
				end
			end,
		})
	end
end

それぞれの処理を見てみると、共通してそれぞれのイベントが発生した時にM.hook()という関数を実行するautocmdを登録する処理を実行していることが分ります。つまり、M.hook()にdirenvの処理を実行するコードが実装されているはずです。

setup_buffer()

local setup_buffer = function()
	vim.api.nvim_create_autocmd(OPTS.buffer_setup.autocmd_event, {
		pattern = OPTS.buffer_setup.autocmd_pattern,
		callback = function()
			M.hook()
		end,
	})
end

setup_dir()

local setup_dir = function()
	vim.api.nvim_create_autocmd(OPTS.dir_setup.autocmd_event, {
		pattern = OPTS.dir_setup.autocmd_pattern,
		callback = function()
			M.hook()
		end,
	})
end

さらに、M.hook()の実装を見てみると、rc_found(),rc_allowed()でdirenvの状態確認を行なってからM.hook_()を実行しています。

M.book()

M.hook = function()
	local cwd = get_cwd()
	if cwd ~= nil then
		if rc_found(cwd) and rc_allowed(cwd) then
			M.hook_(cwd)
		elseif rc_found(cwd) then
			vim.notify("direnv environment is blocked, please 'direnv allow' it (:DirenvAllow)", vim.log.levels.WARN)
			vim.api.nvim_exec_autocmds("User", { pattern = "DirenvBlocked", group = augroup })
		else
			vim.api.nvim_exec_autocmds("User", { pattern = "DirenvNotFound", group = augroup })
		end
	end
end

M.hook_()ではdirenvの実行をvim.system()を通じて外部コマンドとして実行しています。続く処理では、非同期実行(async = true)な場合はvim.schedule()を通してM.hook_body()を実行し、同期実行(async = false)な場合は直接M.hook_body()を実行します。

M.hook_()

M.hook_ = function(cwd)
	vim.api.nvim_exec_autocmds("User", { pattern = "DirenvStart", group = augroup })
	if OPTS.async then
		vim.system({ "direnv", "export", "json" }, { text = true, cwd = cwd }, function(export_result)
			vim.schedule(function()
				M.hook_body(export_result)
			end)
		end)
	else
		local res = vim.system({ "direnv", "export", "json" }, { text = true, cwd = cwd })
		local export_result = res:wait()
		M.hook_body(export_result)
	end
end

M.hook_body()はJSONとして返ってきたdirenvの実行結果をデシリアライズしてそれに基づいて処理を実行しています。

M.hook_body()

M.hook_body = function(export_result)
	if export_result.stdout ~= "" then
		for k, v in pairs(vim.json.decode(export_result.stdout)) do
			if v == vim.NIL then
				vim.env[k] = nil
			else
				vim.env[k] = v
			end
		end

		if OPTS.hook.msg == "diff" then
			local display_msg = export_result.stderr
			if display_msg ~= nil then
				local lines = vim.split(display_msg, "\n", { trimempty = true })
				local diff_msg = lines[#lines]
				if string.len(diff_msg) > vim.o.columns then
					diff_msg = string.sub(diff_msg, 1, vim.o.columns - 20) .. "..."
				end
				vim.cmd("redraw")
				vim.notify(diff_msg, vim.log.levels.INFO)
			end
		elseif OPTS.hook.msg == "status" then
			M.status()
		end
		vim.api.nvim_exec_autocmds("User", { pattern = "DirenvUpdated", group = augroup })
	end
	vim.api.nvim_exec_autocmds("User", { pattern = "DirenvReady", group = augroup })
end

ここまで処理を追い掛けてきましたが、M.hook()の実行によるdirenvの外部コマンドとしての実行は問題なくできそうです。しかし、この処理中でnvim_exec_autocmds()によって発生させているイベントはvim.o.eventignore = "all"によって無視されるのでそれによって何か処理を実行することは不可能です。

READMEを読んでみると以下のような記述がありました。

The plugin provides a convenience option, on_direnv_finished, which provides a simple easy way of running a callback when direnv has finished, but you may want a bit more control.

These plugin fires these, all under the ‘User’ event, and the ‘direnv-nvim’ autocmd group:

DirenvNotFound - when no direnv was found for the current context

DirenvBlocked - when a direnv was found, but has not been allowed with direnv allow yet

DirenvAllowed - when the direnv has been allowed via the :DirenvAllow function

DirenvStart - when direnv begins evaluation

DirenvUpdated - when vim’s environment was actually updated by direnv

DirenvReady - when direnv has finished evaluating - either the env was updated or left unchanged

やはり、direnvの実行の前後でイベントを発生させるので、何らかのユーザーの実装した処理を実行することを想定しているようです。さらに、コードの例も用意されていました。

-- This snippet is more or less what `on_direnv_finished` runs under the hood.
vim.api.nvim_create_autocmd("User", {
        group = "direnv-nvim",
        pattern = { "DirenvReady", "DirenvNotFound" },
        callback = function()
        -- your action here
        end,
})

解決策(2: 成功)

ここまで読んできた、actionshrimp/direnv.nvim実装からすると以下のようにon_post_load()でM.hook()を実行すれば目的を達成できそうです。

lua/resession/extensions/actionshrimp_direnv.lua

local M = {}

M.on_post_load = function(data)
  require('direnv-nvim').hook()
end

return M

lua/session.lua

resession.setup({
  extensions = {
    actionshrimp_direnv = {},
  },
})

これを設定してからresession.nvimからプロジェクトを開いてみると想定通りに動作し目的を達成できました。しかし、direnvが発生させる各種イベントによるユーザーが実装した処理の実行と両立できないことには注意が必要です。

ハマりポイント&感想

ハマったポイント

direnv.nvimのソースを読みながら、挙動について色々考えていたら??な点があって調べたところ、direnv.nvimは二つ存在して自分がインストールしているのはactionshrimp/direnv.nvimなのに、 NotAShelf/direnv.nvimのソースを読んでしまいました。

感想

これまで知らなかったイベント制御の方法を学ぶことができた。
コードを読んで、挙動を見抜いた上で必要なコードを書くという経験をすることができた。

追記@ 2026 01/19

最初は想定通りに動作していたのですが、途中からdirenvの実行とLSPの初期化と競合が発生するようになりました。そこで、direnvの非同期実行(async)を無効化して同期的に実行するようにしたところ、想定通りに動作するようになりました。

-- 以下はlazy.nvimから読み込まれるとする
{
  'actionshrimp/direnv.nvim',
  opts = {
    async = false, -- asyncを無効化しないと競合が発生する
    type = 'dir', -- ディレクトリ移動でフックする場合
    --type = 'buffer', -- バッファの読み込みでフックする場合
    on_direnv_finished = function() -- 実行後に実行される関数
      print('direnv: ok!')
    end,
  },
}

"大規模ソフトウェアを手探る"をやる (2: Nixに移行編)

Fri, 09 Jan 2026 19:00:48 +0900

経緯

なぜNixに移行するのか？

part 1になる前回の投稿日は2025年の3月の末だったので、投稿からほぼ1年も経過してしまっています。進捗としては、gnuplotのビルドまでと本当に序盤を触れただけです。さらに、その間に普段一番触っているラップトップマシンをArch LinuxからNixOSに移行したことで、環境がガラリと変りました。

これまで通りにやるならば、システムにグローバルにツール群をインストールしてビルドしてしまうのも一つの手ではあります。しかし、せっかくNixOSをflakeによって運用しているならば、flakeでローカルに環境を作りビルドした方が"Nixらしい"と思ったので移行してみることにしました。

移行作業は？

“地獄"とまではいきませんが、目的のビルド成果物を思い通りに動くようにできるまでは少々大変ではありました。

とりあえずビルドができるところまでは、案外すんなりいったのですがGUIでplotの画面が開かない問題が中々解決できませんでした。

環境構築 by flake.nix

今回構築した環境では、以下のことを要件としました。

再現性のある環境を構築すること
ソースコードを変更&ビルドを手軽に繰り返すことが可能なこと。
gdb(デバッガ)を使ってステップ実行ができるようにすること。
clangd(Language Server)を使ってコードを読む時に定義ジャンプ等が使えるようにすること

以下では、各要件を満す環境をどう構築したかについて説明します。

要件1,2(ビルド環境)について

要件1,2は、一旦nix buildでビルドが可能な環境を作ってから、それに要したパッケージ等の設定をmakeShell関数にも設定することで実現しました。というのも、ビルドが可能なnix-shell環境できたつもりでもグローバルにインストールされているツールに依存していわゆる"暗黙の依存"を作ってしまう可能性があります。暗黙の依存作ってしまうと、せっかくのNixの再現性が台無しです。

まずは、特に依存パッケージ等を考えずに、普通のgccをコンパイラツールチェーンとして指定して以下の環境でnix buildを実行してビルドを行いました。

flake.nix

{
  description = "flake for Seach of LS software";

  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs?ref=nixos-unstable";
  };

  outputs =
    { self, nixpkgs }:
    let
      platform = "x86_64-linux";
      pkgs = nixpkgs.legacyPackages."${platform}";

      nParallels = "11";

      gnuplot_debug = pkgs.stdenv.mkDerivation rec {
        pname = "gnuplot";
        version = "5.0.1";
        src = pkgs.fetchurl {
          url = "https://sourceforge.net/projects/gnuplot/files/gnuplot/${version}/gnuplot-${version}.tar.gz";
          hash = "sha256-fLxVfnHfWB6lIBI/tDnepfBzrcyQEKKIXcgNTtKLPEc=";
        };

        nativeBuildInputs = with pkgs; [
          gcc
          gnumake
        ];
        buildInputs = with pkgs; [ ];

        dontConfigure = true;

        buildPhase = ''
          CFLAGS="-O0 -g" ./configure --prefix=$out
          make -j${nParallels}
        '';

        installPhase = ''
          make install 
        '';

      };
    in
    {
      packages.${platform}.default = gnuplot_debug;
    };
}

しかし、ビルドには失敗して、以下のようなエラーメッセージが表示されました。

どうやら、buildPhaseのmakeの実行でコケているようです。

nix build
error: Cannot build '/nix/store/xy2d25qg4ip4aa7jyssazrr6f2fscdm0-gnuplot-5.0.1.drv'.
       Reason: builder failed with exit code 2.
       Output paths:
         /nix/store/kcizqzm8hmm7fzq1bhch7mfc1dq5isr6-gnuplot-5.0.1
       Last 25 log lines:
       >                  from stdfn.h:49,
       >                  from dynarray.h:41,
       >                  from dynarray.c:43:
       > /nix/store/dj43clc5ff7jjnfmhbaj6q4q0h8kpfpm-glibc-2.40-66-dev/include/features.h: At top level:
       > /nix/store/dj43clc5ff7jjnfmhbaj6q4q0h8kpfpm-glibc-2.40-66-dev/include/features.h:422:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp]
       >   422 | #  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
       >       |    ^~~~~~~
       > make[4]: *** [Makefile:896: breaders.o] Error 1
       > make[4]: *** Waiting for unfinished jobs....
       > make[4]: *** [Makefile:896: eval.o] Error 1
       > make[4]: *** [Makefile:896: alloc.o] Error 1
       > make[4]: *** [Makefile:896: dynarray.o] Error 1
       > make[4]: *** [Makefile:896: command.o] Error 1
       > make[4]: *** [Makefile:896: datafile.o] Error 1
       > make[4]: *** [Makefile:896: color.o] Error 1
       > make[4]: *** [Makefile:896: contour.o] Error 1
       > make[4]: *** [Makefile:896: axis.o] Error 1
       > make[4]: Leaving directory '/build/gnuplot-5.0.1/src'
       > make[3]: *** [Makefile:955: all-recursive] Error 1
       > make[3]: Leaving directory '/build/gnuplot-5.0.1/src'
       > make[2]: *** [Makefile:630: all] Error 2
       > make[2]: Leaving directory '/build/gnuplot-5.0.1/src'
       > make[1]: *** [Makefile:417: all-recursive] Error 1
       > make[1]: Leaving directory '/build/gnuplot-5.0.1'
       > make: *** [Makefile:355: all] Error 2
       For full logs, run:
         nix log /nix/store/xy2d25qg4ip4aa7jyssazrr6f2fscdm0-gnuplot-5.0.1.drv

makeの中ではどの処理でコケているのかを知るために、このエラーメッセージの末尾に表示された

`1`	`nix log /nix/store/xy2d25qg4ip4aa7jyssazrr6f2fscdm0-gnuplot-5.0.1.drv`

を実行することで得られる詳細なエラーメッセージを見てみました(とても長いので、以下にリンクを置いておきます)。

build_error.log

この詳細なエラーメッセージからは、非常に多くのソースコード上で共通して以下の部分でコケていることが分りました。

1
2
3

#ifndef lint
static char *RCSid() { return RCSid("$Id: datafile.c,v 1.290.2.9 2015/04/22 22:25:26 sfeam Exp $"); }
#endif

この時点では、これをCのバージョンの問題だと思いbuildPhaseにてCFLAGSにstd=c11,std=c99等を追加して試しましたがダメでした。そこで、gcc自体のバージョンの問題では？と考えgccの代りに gcc14,gcc13を試したところ、gcc13を指定した場合で正常にビルドができるようになりました。

記事の執筆中に調べて分ったことなのですが、先程のコードスニペットは、最近のC23で廃止されたK&Rスタイルの関数のコードなので、恐らくそれをコンパイルできないコンパイラ&コンパイルオプションでビルドしようとしたことが原因と考えられます。

さて、ここまででビルドに成功したので、以下のような簡単なgnuplotのコマンドを実行してみました。

`1`	`plot sin(x)`

しかし、GUIのplot画面が表示されませんでした。

最初は、GUI関係だろうと考えて、xorg 関係のパッケージ(xorg.libX11など)の追加も試しましたが、ダメでした。そこで、nixpkgsではもちろんgnuplotは提供されているので、nixpkgsでのビルドの設定を見てみました。

参考:
- https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/graphics/gnuplot/default.nix

なんとなく、pangoというパッケージが関係しそうに思えたのでこれをbuildInputsに追加してビルドを実行してみたところ、GUIのplot表示が可能になりました。

要件3,4(コードを読む環境)について

ここまで来れば後は簡単です。 gdbはgdbパッケージを追加すれば良いし、clangdはclang-toolsに含まれるのでそれを追加するだけです。

少しだけややこしいのは、clangdでソースを解析するに必要なcompile_commands.jsonです。 CMakeでビルドされるプロジェクトでは、CMakeの機能で生成が可能なのですが、gnuplotはCMakeではない方法でビルドされるプロジェクトなのでこの方法が使えません。

そこで、bearというツールを使ってビルドを

`1`	`bear -- make`

で実行して、ビルドプロセスを解析することでcompile_commands.jsonを生成しました。

完成したflake.nix

最終的に完成したflake.nixは以下のようになりました

このflakeでは、nix buildによる全行程が自動で実行されるビルドもnix-shellに入って手動で行うビルドも両方とも可能です。

flake.nix

{
  description = "flake for Seach of LS software";

  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs?ref=nixos-unstable";
  };

  outputs =
    { self, nixpkgs }:
    let
      platform = "x86_64-linux";
      pkgs = nixpkgs.legacyPackages."${platform}";

      nParallels = "11";

      gnuplot_debug = pkgs.stdenv.mkDerivation rec {
        pname = "gnuplot";
        version = "5.0.1";
        src = pkgs.fetchurl {
          url = "https://sourceforge.net/projects/gnuplot/files/gnuplot/${version}/gnuplot-${version}.tar.gz";
          hash = "sha256-fLxVfnHfWB6lIBI/tDnepfBzrcyQEKKIXcgNTtKLPEc=";
        };

        nativeBuildInputs = with pkgs; [
          gcc13
          gnumake
          pango
        ];
        buildInputs = with pkgs; [ ];

        dontConfigure = true;

        buildPhase = ''
          CFLAGS="-O0 -g" ./configure --prefix=$out
          make -j${nParallels}
        '';

        installPhase = ''
          make install 
        '';

      };
    in
    {
      packages.${platform}.default = gnuplot_debug;

      devShells.${platform}.default = pkgs.mkShell {
        packages = with pkgs; [
          # for build
          gcc13
          gnumake
          pango

          # for code reading
          bear
          ## for clangd
          clang-tools
          # debugger
          gdb
        ];

      };

    };
}

最後にビルド&実行方法を載せておきます。

nix buildによるビルド&実行

1
2
3

nix build # ビルド

./result/bin/gnuplot # 実行

ソースの変更&ビルドの繰り返しで使用する手動の方法

wget https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0.1/gnuplot-5.0.1.tar.gz
tar -xzvf gnuplot-5.0.1.tar.gz

mkdir build && cd build
# インストール先はお好みで、筆者は `<project root>/build/install`にインストールした.
CFLAGS="-O0 -g" ../gnuplot-5.0.1/configure --prefix="$PWD/install" 
bear -- make -j11 # to generate compile_commands.json
make install

./build/install/bin/gnuplot # 実行

NixOSでセキュアブートを設定する

Sun, 04 Jan 2026 02:16:21 +0900

以前Arch Linuxでは、セキュアブートを設定していたので、NixOSでも設定しました。 NixOSでセキュアブートを構成する方法は、nix-community/lanzabooteを使う方法が一般的なそうなので、それに従って行いました。

参考
- nix-community/lanzaboote

方針としては、基本的には以前Arch Linuxで行なったやり方である、sbctlによる方法です。 lanzabooteの特徴は、カーネル、initrd,カーネルコマンドラインをバンドルした*.efiなファイルであるユニファイドカーネルイメージ(UKI)を作成し、それを署名することでセキュアブートを実現しています。この方法では、単に、カーネル、ブートローダーに署名する方法ではできなかった、initrdの改竄を検出することができるためよりセキュアな環境を実現可能です。

鍵の操作

sbctlによる鍵の作成

まず、sbctlをインストールします。

nix-shellで一時的に導入するのでも良いですが、今後もトラブルシューティングや確認などで使用することが見込まれるため、以下のようにグローバルにインストールしました。

environment.systemPackages = with pkgs; [
  # For debugging and troubleshooting Secure Boot.
  sbctl
];

続いて、sbctl create-keysで鍵を作成します。

`1`	`sudo sbctl creat-keys`

鍵の作成は特に問題なく完了しました。

作成された鍵は/var/lib/sbctlに保存されていました。この鍵の保存先は後ほど必要なので、メモしておきましょう。

作成した鍵のenroll

今回は、前回のArch Linuxで設定した時に作成した鍵は削除して、新たに鍵を作成&登録しました。

まず、マシンのUEFI-BIOSに入って、secure-bootをセットアップモードにします。この時に前回登録した鍵が削除されました。

その後で再起動して、以下のコマンドで鍵をします。

`1`	`sudo sbctl enroll-keys -m # '-m' を絶対に忘れるな！`

ここで、-mオプションはマイクロソフトの鍵を消さずに自分で生成した鍵を追加するようすることを意味します。これを忘れると、マイクロソフトの鍵で署名された一部のデバイスドライバが読めなくなって最悪の場合ではマシンが文鎮化する恐れがあるので絶対に忘れないようにしましょう。

鍵を追加しようとしたところ以下のようなエーラーが出ました。

1
2
3

‼ 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

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

1
2

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 # '-m' を絶対に忘れるな！
Enrolling keys to EFI variables...
With vendor keys from microsoft...✓
Enrolled keys to the EFI variables!
sbctl status
Installed:      ✓ sbctl is installed
Owner GUID:     541a99e4-09dd-4990-99ca-dd8bb4b254ec
Setup Mode:     ✓ Disabled
Secure Boot:    ✗ Disabled
Vendor Keys:    microsoft

`lanzaboote`の設定

とりあえず設定する

以下のlanzabooteのガイドに従って設定しました。flakeを使う方法と使わない方法がありますが、筆者のNixOSの設定はflake化済みなので前者を採用しました。

参考
- nix-community.github.io/lanzaboote

筆者の元の設定aki-ph-chem/nix(まだ、セキュアブートの設定がされていない状態のコミット)に以下のように設定を追加しました。

まず以下の内容で、flakeにlanzabooteを導入して利用できるようにします。

diff --git a/flake.nix b/flake.nix
index 18bf060..221cc50 100644
--- a/flake.nix
+++ b/flake.nix
@@ -9,6 +9,14 @@
       inputs.nixpkgs.follows = "nixpkgs";
     };
     nixgl.url = "github:nix-community/nixGL";
+
+    # for secure-boot
+    lanzaboote = {
+      url = "github:nix-community/lanzaboote/v0.4.3";
+      # Optional but recommended to limit the size of your system closure.
+      inputs.nixpkgs.follows = "nixpkgs";
+    };
+
     # GitHub: aki-ph-chem/dotfiles
     dotfiles = {
       url = "github:aki-ph-chem/dotfiles/main";
@@ -19,6 +27,7 @@
   outputs =
     {
       nixpkgs,
+      lanzaboote,
       home-manager,
       nixgl,
       dotfiles,

続いて以下でlanzabooteの設定をします。

diff --git a/hosts/nixosSwayLaptop/default.nix b/hosts/nixosSwayLaptop/default.nix
index 855f6cb..2b361ac 100644
--- a/hosts/nixosSwayLaptop/default.nix
+++ b/hosts/nixosSwayLaptop/default.nix
@@ -5,6 +5,7 @@
 let
   inherit (inputs)
     nixpkgs
+    lanzaboote
     home-manager
     self
     dotfiles
@@ -20,6 +21,18 @@ nixpkgs.lib.nixosSystem {
   inherit pkgs;

   modules = [
+    lanzaboote.nixosModules.lanzaboote
+    (
+      { pkgs, lib, ... }:
+      {
+        boot.loader.systemd-boot.enable = lib.mkForce false;
+
+        boot.lanzaboote = {
+          enable = true;
+          pkiBundle = "/var/lib/sbctl";
+        };
+      }
+    )
     {
       imports = [
         (import "${flakeRoot}/nixos/fonts" { inherit pkgs; })
@@ -85,7 +98,6 @@ nixpkgs.lib.nixosSystem {
       ];

       # Use the systemd-boot EFI boot loader.
-      boot.loader.systemd-boot.enable = true;
       boot.loader.efi.canTouchEfiVariables = true;
       boot.kernelPackages = pkgs.linuxPackages_latest; # Use latest kernel.

pkiBundleには、sbctlで生成された鍵が保存されたディレクトリである/var/lib/sbctlを指定しています。

また、boot.loader.systemd-boot.enableは以下のように変更しています。この設定はデフォルトのsystemd-bootのモジュールを置き換えること意味します。

`1`	`boot.loader.systemd-boot.enable = lib.mkForce false;`

ここまで設定したものをビルドして適用しました。 Rustのビルドが走るようで結構時間がかかりました。

`1`	`sudo nixos-rebuild switch --flake .#nixosSwayLaptop --impure`

これで、UKIの作成と署名が行われたはずなので、以下で確かめてみます。

`1`	`sudo sbctl verify`

kernel-から初まるものは署名されず、*.efiなファイルが署名されている状態になるはずですというのも、カーネルを署名するのではなく、UKIを作成してそれに署名しているからです。

最後にシャットダウンして、UEFI-BIOからsecure-bootを再度有効化してちゃんと起動したら成功です。

保存しておく世代について

ここまでで、セキュアブートは設定できました。

しかし、構成の変更で生成されたNixOSの世代が全て署名されて/bootが圧迫されてしまいます。しかも、通常のガベージコレクタの操作をしても削除されません。

そこで、lanzabooteのリポジトリのうち以下を見るとboot.lanzaboote.configurationLimitで残しておく世代を設定できることが分りました。

参考
- https://github.com/nix-community/lanzaboote/blob/master/nix/modules/lanzaboote.nix

今回は7世代まで残すことにして以下のように設定しました。

diff --git a/hosts/nixosSwayLaptop/default.nix b/hosts/nixosSwayLaptop/default.nix
index c4a1256..dff34b5 100644
--- a/hosts/nixosSwayLaptop/default.nix
+++ b/hosts/nixosSwayLaptop/default.nix
@@ -54,6 +54,8 @@ nixpkgs.lib.nixosSystem {
         boot.lanzaboote = {
           enable = true;
           pkiBundle = "/var/lib/sbctl";
+          # see https://github.com/nix-community/lanzaboote/blob/master/nix/modules/lanzaboote.nix
+          configurationLimit = 7;
         };
       }
     )

これで/bootを圧迫する問題を解決できました。

同居(別のディスクからデュアルブートしている)windowsの様子は？

このセキュアブートを設定してから同居(dual-boot)しているbitlockerを適用したwindowsを起動したところセキュアブートのポリシーが変ったようで回復キーを求めました。

一旦そのキーを入れたら、何度か windows <-> Linuxと行き来しましたが、以降問題なく起動するようになりました。

最後に

前回のLUKSによるディスク暗号化に続いて、セキュアブートまで設定できました。

1度、sbctlによる方法でセキュアブートを設定したことはありますが、鍵関係の操作は相変わらず緊張しますね。

また、執筆中に発見したのですが、sbctlを使って自分で署名する方法は、ハードウェアによっては使えないケースがあるようです。

参考
- Zenn: NixOSでゆるふわセキュアブート

NixOSでLUKSによるディスク暗号化を設定する

Thu, 01 Jan 2026 02:06:23 +0900

ディスク暗号化を設定する動機は？

ちょうど、Arch LinuxをインストールしていたラップトップマシンをNixOSに移行するタイミングで、それなりに持ち歩くマシンなので、前々から暗号化したいな~と思っていたのでこのタミングでディスク暗号化のされたインストールを行いました。

Arch LinuxからNixOSに移行した事や後から設定したセキュアブートについてはまた別の記事にしようと思います。

ディスクの構成

インストール先のディスク(以降では、/dev/sdaとします)には、以下の表のようにgdiskでパーティションを直接(LVMは使用していない)設定しました。

partition	mounting point	capacity	hexcode
/dev/sda1	/boot	1 GiB	ef00
/dev/sda2	/	残り全て	デフォルト値

このとき、暗号化するパーティションは/すなわち/dev/sda2のみで、 /dev/sda1は暗号化せずに平文のままにします。

暗号化されたインストール

LUKSによる`/`の暗号化

まず以下のコマンドで、/dev/sda2をLUKSによって暗号化します。

`1`	`cryptsetup luksFormat /dev/sda2 # 暗号化`

続いて、暗号化された/dev/sda2を以下でopenします。

`1`	`cryptsetup open --type luks /dev/sda2 cryptsda # open`

この時openされたボリュームは以降では/dev/mapper/cryptsdaとして利用できます。

インストール

ここまでで、ディスクパーティションが用意できたので、インストール作業を進めていきます。

まず/boot,/を以下でそれぞれvfat,ext4にフォーマットします。

1
2

mkfs.vfat -F32 /dev/sda1 # /boot
mkfs.ext4 /dev/mapper/cryptsda # /

ファイルシステムを用意できたので、続いてマウントを以下のように行います。

1
2
3

mount /dev/mapper/cryptsda /mnt # /をマウント
mkdir /mnt/boot
mount /dev/sda1 /mnt/boot # /bootをマウント

ここまで来たらあとは通常のインストールと同じです。まず、/mnt以下にconfigを生成します。

`1`	`nixos-generate-config --root /mnt`

参考にした以下の記事では、起動時にディスクの復号を行う設定を手で追加していました。

参考
- Zenn: NixOSでSecureBoot+LVM on LUKS

しかし、インストールを行なった時には(2025 12/7)、configを生成した段階で、/mnt/etc/nixos/hardware-configuration.nixに以下のような設定が生えて、特にLUKS固有の設定されて特に追加の設定は不必要でした。

fileSystems."/" = {
  device = "/dev/disk/by-uuid/7e224d65-2f57-402f-b4b1-24afd7b2e7a2";
  fsType = "ext4";
};

boot.initrd.luks.devices."cryptsda".device =
  "/dev/disk/by-uuid/dedace0a-cb3a-4994-86db-7ef7af2017ad";

fileSystems."/boot" = {
  device = "/dev/disk/by-uuid/8D75-2067";
  fsType = "vfat";
  options = [
    "fmask=0022"
    "dmask=0022"
  ];
};

最後に、

`1`	`nixos-install`

を実行すればインストールが実行されます。無事インストールに成功するとパスワード設定を促され再起動します。

再起動時に途中でLUKSのパスワードを求められるので、それを入力してから無事起動できれば成功です。

後はお好みに/etc/nixos/configuration.nix を設定するなり、flake化するなりお好みにしてください。

tombiを導入してみる

Thu, 01 Jan 2026 00:16:26 +0900

本題の前に新年のご挨拶を…

あけましておめでとうございます。このブログは2025年の年末に"より続けやすいブログが欲しい"とのことで開設したものです。 2026年はたくさん記事を書いていきたいです。

tombiとは？

tombiとはRustで実装されたTOMLのLanguage Server & Formatter & Linterです。

Zennに投稿された開発者さんの記事によると、TOMLのLanguage Serverは、以前からtaploというものが存在するようですが、メンテナンスの継続が困難になってしまっていて、利用するのが難しくなってしまったことが開発の動機のようです。

筆者は、Rustによる開発の際に、Cargo.toml,Makefile.tomlを書くので、TOMLにも Language Serverがあればな~っと思っていました。そんな時、GitHubをぼんやりと見ていると、たまたま発見したので試してみることにしました。

参考
- GitHub: tombi-toml/tombi
- Zenn: Tombi ｜ New TOML Language Server

インストール by Nix

現在は、マシンにグローバルにインストールはしておらず、プロジェクトごとのnix-shell内で有効化しています。

とりあえず試してみたいならば、

`1`	`nix-shell -p tombi`

でnix-shellを作ってしまうのが一番簡単でしょう。

筆者は、Rustの開発環境をflakeで構築しているので、以下のようにpackagesにtombiを追加して運用しています。

この方法は、Rustでなくても、PythonでPoetry,uvなどでpyproject.tomlを書くような場面でも使えます。

flake.nix

{
  description = "project with tombi";

  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs?ref=nixos-unstable";
  };

  outputs =
    { self, nixpkgs }:
    let
      pkgs = nixpkgs.legacyPackages."x86_64-linux";
    in
    {

      devShells."x86_64-linux".default = pkgs.mkShell {

        packages = with pkgs; [
          # 他のパッケージ 
          tombi
        ];

      };

    };
}

Nixを利用しないで、インストールしたい場合は公式ドキュメントのinstallationの部分を参照してください。

Neovim向けに設定する

tombi自体はインストールできたので、エディタ側も設定してきます。先ほどのドキュメントのに、設定のサンプルへのリンクがあったのでそれを参考にして、以下のように設定しました。

-- Toml
vim.lsp.tombi = {
  cmd = {
    'tombi',
    'lsp',
  },
  filetypes = { 'toml' },
  root_markers = { 'tombi.toml', 'pyproject.toml', '.git' },
}
vim.lsp.enable({ 'tombi' })

この設定では、ビルドインのLSPマネージャーを使う方法で設定しました。ポイントは、root_markers = {}でプロジェクトのルートディレクトリのヒントになるファイルを指定することです。

さらに、保存した時にフォーマットされるようにするために以下のように設定をしました。

-- format via LSP
vim.api.nvim_create_autocmd('BufWritePost', {
  pattern = { '*.toml' },
  callback = function()
    vim.lsp.buf.format({})
  end,
})

tombiはLSP経由でのフォーマット機能が実装さているので、この設定では、*.tomlなファイルが保存された時(BufWritePostイベントが発生した時) に、vim.lsp.buf.format()を実行するようにしています。

使用してみて

インストールは、flakeで環境構築しているRustのプロジェクトがあったので、packages = []に追加するだけでできてお手軽でした。

実際に使用してみたところ、基本的な機能は使えている印象です。きっとTOMLを書く場面で活躍することでしょう。

NixOSにハイバネーションを設定する

Wed, 31 Dec 2025 00:03:20 +0900

ハイバネーションとは？

ハイバネーションとは、サスペンド(スリープ)とシャットダウンとの間のような状態です。

サスペンドでは、基本的には現在のメモリの状態を保持するための電力の供給だけを行い、それ以外の部分は電源をオフにします。そのため、少量とはいえ電力を消費します。

一方ハイバネーションは、現在のメモリの状態をディスク上のスワップ領域に退避させるので、完全に電源をオフにすることができます。そのため、ラップトップのようなモバイルマシンではバッテリーを節約できる点で有利です。

参考
- Arch Wiki: 電源管理/サスペンドとハイバネート

NixOSで設定するには？

参考
- NixOS Wiki: Hibernation
- Official NixOS Wiki: Power Management

ハイバネーションを設定するには退避するためのスワップ領域を作成する必要があります。待避するためのスワップ領域は、ディスク上のスワップパーティション(直接でもLVM上でも)、スワップファイルのどちらでも可能です。

筆者は、スワップファイルによる方法で以下のように設定しました。

# Swap file
swapDevices = [
  {
    device = "/var/lib/swapfile";
    size = 32 * 1024; # 32 GB
  }
];

スワップファイルのオフセットを調べる

スワップ領域がパーティションな場合では、待避先を指定するboot.resumeDeviceにそのパーティションを/dev/disk/by-uuid/<UUID>で指定します。一方、スワップファイルを選択した場合では、boot.resumeDeviceにはあくまでもスワップファイルの存在するディスクパーティションを指定し、そのスワップファイルが物理的なディスク中のどのブロックを指しているのかをオフセットで指定する必要があります。

今回のケースでは、スワップファイルを使用するので、オフセットを以下のコマンドで調べました。

sudo filefrag -v /var/lib/swapfile
Filesystem type is: ef53
File size of /var/lib/swapfile is 34359738368 (8388608 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   45055:     409600..    454655:  45056:
   1:    45056..  110591:     458752..    524287:  65536:     454656:
   2:   110592..  335871:     593920..    819199: 225280:     524288:
...

必要な値は、物理的なディスク上でスワップファイルに対応するブロックの初まりの値なので、この結果からはext:が0でphysical_offsetの頭の値である409600をオフセットとしてメモしておきます。

設定する

元の設定aki-ph-chem/nix(まだ、ハイバネートの設定がされていない状態のコミット)に以下のように設定を追加しました。

diff --git a/hosts/nixosSwayLaptop/hardware-configuration.nix b/hosts/nixosSwayLaptop/hardware-configuration.nix
index b1fbfff..7ceb0e6 100644
--- a/hosts/nixosSwayLaptop/hardware-configuration.nix
+++ b/hosts/nixosSwayLaptop/hardware-configuration.nix
@@ -25,6 +25,11 @@
   boot.kernelModules = [ "kvm-intel" ];
   boot.extraModulePackages = [ ];
 
+  # for Hibernation
+  boot.kernelParams = [ "resume_offset=409600" ]; # スワップファイルの'/'中でのオフセット
+  boot.resumeDevice = "/dev/disk/by-uuid/66a368d1-3b3d-49fe-b6eb-f3c73f35ce22"; # パーティション '/'をUUIDで指定
+  powerManagement.enable = true;
+
   fileSystems."/" = {
     device = "/dev/disk/by-uuid/66a368d1-3b3d-49fe-b6eb-f3c73f35ce22";
     fsType = "ext4";

この設定では、boot.resumeDeviceで待避先のパーティションとして/を指定して、boot.kernelParamsでスワップファイルのオフセットを設定しています。

最後に設定を適用して再起動します。

1
2

sudo nixos-rebuild switch --flake .#nixosSwayLaptop --impure
reboot

suspendを実行して成功すればokです。

`1`	`systemctl hibernate`

使用してみて

基本的にはハイバーネーションには成功して、復帰も正常に行われます。しかし、まあまあな頻度で復帰時にカーネルパニックが起ってフリーズしてしまう問題を解決できていないので、使用は控えています。

Hugo + GitLab + Cloudflare Pagesで新しいblogを初めた(技術編)

Sun, 21 Dec 2025 10:53:37 +0900

今回はじめて作ったHugoサイトで使った技術について軽くまとめました。

Hugo環境の構築

環境構築はNix flakeで行いました。

まず、

`1`	`nix flake init`

を実行して、テンプレートのflake.nixを生成します。これを以下のように編集して、Hugoと今後使いそうな画像処理ツールを導入したnix shellを作るようにします。

flake.nix

{
  description = "Blog by Hugo";

  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs?ref=nixos-unstable";
  };

  outputs =
    { self, nixpkgs }:
    let
      platform = "x86_64-linux";
      pkgs = nixpkgs.legacyPackages.${platform};
    in
    {
      devShells.${platform}.default = pkgs.mkShell {

        packages = with pkgs; [
          hugo
          ## For image processing
          pngquant
          imagemagick
          exiftool
        ];

      };
    };
}

後はシェルから、

`1`	`nix develop`

を実行すればHugoが使えるシェル環境に入れます。

より便利にするために筆者はnix-direnvを導入しています。 nix-direnvでは、.envrcを以下のように用意して

.envrc

`1`	`use flake`

以下を実行して実行を許可すると、ディレクトリの移動でflakeの内容が適用されたシェルに入れるので便利です。

`1`	`direnv allow`

リポジトリのセットアップ

以下のブログ記事とそのリポジトリを参考にしました。特に.gitignore,hugo.yamlはとても参考になりました。

参考
- YAMAMOTO Yuta: Hugo+Stackテーマの導入メモ
- GitHub: yamamoto-yuta/yamamoto-yuta.github.io

まず以下を実行してblogを作成しました。

`1`	`hugo new site . --force`

使用しているテーマStackは以下のようにsubmoduleとして導入しました。

`1`	`git submodule add https://github.com/CaiJimmy/hugo-theme-stack/ themes/hugo-theme-stack`

Stack側のconfigであるhugo.yamlをプロジェクトルートにコピーして、デフォルトのconfigであるhugo.tomlを削除します。

1
2

cp themes/hugo-theme-stack/hugo.yaml .
rm hugo.toml

記事を追加する時は

`1`	`hugo new content post/<post title>/index.md`

を実行してから、index.mdに記事を書きます。

ローカルでの確認

以下を実行して表示されたURL(デフォルトではlocalhost:1313)にブラウザからアクセスすればokです。記事やconfigに変更があると自動で再ビルドを実行して反映してくれます。

`1`	`hugo server -D`

デプロイ

参考
- 点と接線。: Cloudflare Pagesの利点および導入手順

Cloudflare Pagesにデプロイしました。 Cloudflare側から引っ張ってくるリポジトリを指定して、デプロイするブランチ(普通はmain)を指定すればそのリモートブランチへのpushをトリガにデプロイしてくれます。

ドメイン取得

Cloudflareは明朗会計でよくお勧めされていて、サイトをCloudflare Pagesでホスティングすることもあるので、Cloudflare Registrarで取得しました。基本的には、トップページのドメインを購入するから手順通りに操作すれば良いです。日本の住所を英語で入力するのは、慣れずに少し手こずりましたがそれ以外はすんなりと取得手続きできました。

Pagesにドメインを指定するには、Pagesの画面から独自ドメインを設定すればokです。

画像の配信

直接画像もリポジトリにpushしてしまうと、ビルドが重くなってしまうので他の方法で配信する方法を探していました。以下の記事によると、個人ブログならCloudflare R2の無料枠で十分そうなので採用することにしました。

参考
- 高木のブログ: ブログの画像配信サーバーとして Cloudflare R2 を使う
- Zenn: 「CloudflareのR2って何ですか？」な私がR2（カスタムドメイン）とNext.jsを使ってファイルをアップロードする

適当な名前のR2バケットを作成してから、Cloudflareで取得したこのサイトのドメインakiblog.orgのサブドメインimages.akiblog.orgで公開するように設定すれば、自動でDNSに設定されました。

以下はテストとして、筆者のアイコンの画像を配信した例です。

現状は、R2の管理画面から画像をアップロードしていますが、 AWS S3互換なのでAWS CLIを使ったアップロードなども検討しています。

ハマったポイント

最初、Cloudflareの画面からPagesの設定に行くのが分かりませんでした。というのも、右側のコンピューティングとAI -> Workers & Pages -> アプリケーションを作成する、と進むと出てくるのはWorkersの選択画面でPagesが見つからなかったからです。

と思ったら下にLooking to deploy Pages? Get startedと小さくありました！(これは見落しそう)

Hugo + GitLab + Cloudflare Pagesで新しいblogを初めた(Why編)

Sun, 21 Dec 2025 03:01:49 +0900

Why?

これまでは、はてなブログに__aki_nikki__として記事を投稿していました(低頻度ですが…😅)。記事はMarkdownで書きGitLabで管理していたのですが,書いた記事を投稿する時に投稿画面を開いての作業が面倒で執筆の障壁となっていました。そのためか、ブログ記事にできそうなメモやスクラップが放置されたまま蓄積されていました。

実際、はてなブログの記事投稿においてもCI/CDを用いて行うことは可能でしたが、それを導入するよりも静的サイトジェネレーターで構築する方が簡単に見えたこと、そして以前から漠然とブログを自作してみたいと考えていたため、良い機会だと判断したからです。

Why Hugo & Cloudflare Pages?

Hugo & Cloudflare Pagesの構成は、以下の理由で決定しました。

Hugo
- 筆者にWebフロントエンドの知識が乏しい（Astroなどを選ばなかった理由）
- 手軽に記事をMarkdownで書ける
- 豊富なテーマから好きなものを選べる（今回はstackを選択）
Cloudflare Pages
- 個人ブログの範囲であれば無料枠で十分に利用できる
- GitLabとの連携で簡単にデプロイできる

詳細については、別の記事で改めて解説する予定です。

前のblogはどうするのか？

以前投稿した記事は、必要に応じて修正し、こちらに移植する予定です。しかし、ひとまず削除はせず、何か別の用途に活用できないかと考えています。

Hello From My Blog

Fri, 19 Dec 2025 23:34:28 +0900

Hello!

About

Fri, 19 Dec 2025 22:28:14 +0900

About me

私について

Rust製のPythonの型チェッカー& Language Server tyを試す

Fri, 29 Aug 2025 03:49:34 +0900

本記事は以前はてなブログに投稿していた記事の内容を加筆修正して移行したものです。

tyとは？

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

参考
- GitHub: astral-sh/ty
- Astral Docs: ty - Astral Docs

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

検証

tyのインストール

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

1
2
3

$ 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 を利用して

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

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

`1`	[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なファイルを開き、サーバーが起動するかを以下のコマンドでチェックしてみます。

1
2

$ 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()

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

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

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.と出て出来ませんでした。 (追記@2025 12/25 14:00 rename(textDocument/rename)は実装されていました) (その他のfeatureについてはty/Feature referenceを参照してください)

感想

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

追記

tyを試す環境について

現在では、Nixを使用しているので一時的に使用したい場合では以下のようにnix-shellを作るためのflake.nixを作成して

flake.nix

{
  description = "use ty";

  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs?ref=nixos-unstable";
  };

  outputs =
    { self, nixpkgs }:
    let
      pkgs = nixpkgs.legacyPackages."x86_64-linux";
    in
    {
      devShells."x86_64-linux".default = pkgs.mkShell {

        packages = [
          pkgs.ty
          # その他のパッケージ
        ];

      };
    };
}

以下を実行し、その中でuvを動かします(Luaで絶対PATHをの注入するような面倒臭いコードは書く必要はありません！)。

`1`	`nix develop`

もっと簡単にやりたい場合では、

`1`	`nix-shell -p uv`

もしくは

`1`	`nix shell nixpkgs#uv`

でuvの導入したnix-shellを直接作れば良いです。

buildinのLSPマネージャーから呼び出す設定について

執筆した当時では、buildinのLSPマネージャーを使用せずにnvim-lspconfigを使用していました。現在は他のlanguage-serverでもbuildinのLSP構成を使用しています。

tyを使う場合の設定は以下のように設定します。

local ty_config = {
  settings = {},
  on_attach = function(client, bufnr)
    utl.navic.attach(client, bufnr)
  end,
}

vim.lsp.config.ty = ty_config
vim.lsp.enable({ 'ty' })

また普段はpyrightを使用して、使用したい場合のみtyが起動するようにする場合は以下のように環境変数TYが有効化された場合にのみtyを有効化するように設定します。

local pyright_config = {
    -- 略
}

local ty_config = {
  settings = {},
  on_attach = function(client, bufnr)
    utl.navic.attach(client, bufnr)
  end,
}

-- pyright or ty
if os.getenv('TY') then
  vim.lsp.config.ty = ty_config
  vim.lsp.enable({ 'ty' })
else
  vim.lsp.config.pyright = pyright_config
  vim.lsp.enable({ 'pyright' })
end

require('formatter').setup({
  filetype = {
    python = {
      require('formatter.filetypes.python').ruff,
    },
  },
})

Arch Linuxに Secure Bootを設定する

Mon, 30 Jun 2025 03:39:05 +0900

本記事は以前はてなブログに投稿していた記事の内容を加筆修正して移行したものです。

セキュアブートとは？

簡単に説明すると、カーネルとブートローダーに署名をして、起動時にその署名を検証してパスする場合のみブートを許可する機構です。署名の検証を行うことで、カーネルとブートローダーが改竄されていないことを担保できるためセキュリティーが向上します。

自分のマシン(ThinkPad E14 Gen5)では、Windows11とArch Linuxでデュアルブートしています。 Windows11側でディスク暗号化を運用したいと思ったのですが、セキュアブートの有効化が必要だったため、今回セキュアブートを設定行いました。

参考
- Arch Wiki: Unified Extensible Firmware Interface/セキュアブート

セキュアブートの設定

Linuxでセキュアブートを設定する方法には、大きく分けると二通りの方法があります。

一つの方法は、多くのx86-64なマシンには既にMicrosoftによって発行された鍵が封入されているため、その鍵で署名されたブートローダーからチェインロードすることでブートするように設定する方法です。この方法では、鍵を封入する操作が不要なため既存の鍵を飛してしまうようなリスクがないことがメリットですが、操作が少し煩雑です。この方法は実際にProxmox VEでセキュアブートを実現するために使用されています。

参考
- proxmox: Secure Boot Setup

もう一つの方法は、自分で署名用の鍵を作成&封入してカーネル、ブートローダーに署名を行う方法です。この方法では、鍵を封入する作業があるため、操作を間違えるとマシンを文鎮化してしまうリスクがありますが、作業がシンプルです。

今回は後者の方法を、Arch Wikiのガイドを参考に行いました。

sbctlで鍵を生成して封入する

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

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

`1`	`$ sudo pacman -S efitools sbctl`

ここで、efitools,sbctlはそれぞれEFI領域に対する操作、鍵関係の操作に必要なツールです。

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

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

何もしていない場合では、恐らくMicrosoftの鍵が見つかるはずです。

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

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

1
2

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

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

1
2
3

‼ 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

どうやら書き込みしたいファイルがイミューダブルなのでミューダブルになるようにしろとのことなので警告の通りにコマンドを実行してミューダブルにしました。

1
2

$ 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

なので、以下のように署名を行います。

1
2
3

$ 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内のブートローダーも直接署名しました。

1
2

# 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 有効化してから再度起動して、無事起動できれば成功です。

感想

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

SYCLの環境構築

Wed, 16 Apr 2025 15:08:09 +0900

本記事は以前はてなブログに投稿していた記事の内容を加筆修正して移行したものです。

SYCLとは？

CPU,GPU,FPGAのような様々な異るデバイスを扱うための統一規格です。

例えばGPUでは、Nvidia製のGPUで実行するコードを開発するにはCUDAを使うのが一般的ですが、そのコードはAMDやIntelのGPUでは実行できません。しかし、SYCLを用いて開発することで全てのデバイスで実行することができるようになります。

また、デバイスで実行されるコードを別に用意する必要のあるOpenCLとは違い、ホストで実行されるコードと同じC++のソースコードに記述することが可能です。

参考

環境構築

なぜソースからビルドするのか？

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

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

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

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

`1`	`sudo pacman -S hwloc`

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

1
2
3

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のコードの解析ができないためです。

1
2
3

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も必要なのでインストールします。

`1`	`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の設定を行いました。

1
2

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

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

`1`	`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にするコードとしてコメントアウトで切り変えてビルドしまいた。

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

1
2

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のビルドまで)

Mon, 31 Mar 2025 13:06:22 +0900

本記事は以前はてなブログに投稿していた記事の内容を加筆修正して移行したものです。

大規模ソフトウェアを手探るとは？

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

gnuplot 5.0.1 をビルドする

とりあえずビルドしてみるが…

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

1
2
3

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

そのソースツリーの中にbuildディレクトリを作成してビルドを実行するためにconfigureを実行してみます。ここで、デバッグ実行をしてソースコードを探ることが目的なので、ビルドオプションとして最適化なしかつデバッグシンボルを保持する-O0 -gを渡しています。

1
2
3

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

しかし、libcerfが見つからずにコケてしまいました。そこで以下を実行してlibcerfをインストールしました。

`1`	`sudo pacman -S libcerf`

今度は、configureの実行に成功しました。続いてmakeでビルドをしようとすると、以下のメッセージが出てビルドに失敗してしまいました。 luaL_checkint()という関数周りが原因のようです。

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系を要求していました。

`Lua5.2.4`をソースからビルドする

そこで、自分の環境にinstallされているLuaのバージョンを調べてみると5.4.7でした。そこで、Lua5.2.4をソースからビルドしてそのヘッダ、ライブラリを使ってgnuplot-5.0.1をビルドすることを考えました。

Lua5.2.4のビルドは以下のようにソースコードを取得して行います。

wget https://sourceforge.net/projects/luabinaries/files/5.2.4/Docs%20and%20Sources/lua-5.2.4_Sources.tar.gz
tar -xzvf 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

Lua5.2.4のビルドは無事成功しました。

気を取り直して`gnuplot-5.0.1`をビルドする

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

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で実行しました。

`1`	`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を導入した

Sat, 27 Apr 2024 17:40:58 +0900

本記事は以前はてなブログに投稿していた記事の内容を加筆修正して移行したものです。

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

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

インストール

筆者はパッケージマネージャーとしてLazy.nvimを使用しているので以下のように設定します。

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

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

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

:Fern .

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

`1`	`:Fern . -drawer`

と実行します。

いい感じに表示するには

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

とオプションを付けて実行します。

ここで、各オプションの意味は以下の通りです。

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

設定

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

1
2

-- 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よりもサクサク動くように感じました。

参考

追記

現在(@ 2025 12/27)ではファイラーとしてはnvim-tree/nvim-tree.luaを使用しています。

ThinkPadを使ってみて

Sun, 14 Apr 2024 17:48:01 +0900

本記事は以前はてなブログに投稿していた記事の内容を加筆修正して移行したものです。

なぜThink Padを選んだのか?

前まではAsusのラップトップを使ってWinsows11とArch Linuxをデュアルブートしていましたが、11th Core i3 の2コア4スレッドのマシンでは流石に力不足を感じ、もう少しパワーのあるラップトップのマシンが欲しくなったので、新しいマシンとしてThinkPad E14 Gen5を購入しました。スペックですが、CPUは13th Gen Intel(R) Core(TM) i5-13500H (16) @ 4.70 GHzメモリは16GBです。

ThinkPadを選択した理由としてはLinuxを動かすならThinkPad! と言えそうなくらい情報がたくさんインターネット上にあることと、数少ないUS配列のラップトップの候補であることの二点です。(他だとDELLかApple(mac)くらい)

このマシンはnvme SSDを二枚載せることが可能なので、デフォルトで載っている方をWindows11用にしてもう一方にはLinuxを入れてデュアルブート構成で使うことにしました。ちなみにWindowsのライセンスは普通のHome版を選択しました、何回かpro版も考えましたが、やっぱり高いと感じたのでやめました。

Arch Linuxをインストールする

SSDを追加

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

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

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

ディスクの暗号化の解除

Arch Linuxをインストールメディアから起動するためにはセキュアブートを無効化する必要があります。しかし、いざUEFIメニューからセキュアブートを無効化してWindowsが起動しようとするとBitLockerの回復キーを求められました。

最近のWindowsマシンでは、デフォルトでBitLockerによるディスクの暗号化がされているようです。 Pro版だけだと思ってましたが、BitLockerによるディスクの暗号化はHomeでも可能なようです。

このBitLockerですが、セキュアブートが無効化されている場合は回復キーを入力しないと起動できません。ですので、今回は無効化しました。(追記 @ 2025 12/26 現在はLinux(NixOS)側でもLuksによるディスク暗号化とセキュアブートを設定してWindows側のBitLockerは有効化しています。)

いざinstall

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

デスクトップ環境はwaylandのコンポジッターであるSwayを入れてフルスタックなデスクトップ環境は(Gnome,Kde,Xfecなど)入れない構成にしました。

ハマった点

Arch Linuxのインストールもデスクトップ環境の構築も初めてではないのでメモ書きをもとに出来たのですが、オーディオ関係やpolkit周りで少しハマりました。

1: オーディオ

参考:

まず、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

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

polkitは、Dropboxのような権限管理の必要なアプリケーションを運用するために必要です。しかし、Arch WikiのPolkitの記事を読むと、KDE,GNOMEのようなフルスタックなデスクトップ環境をインストールする場合は適切に設定されていることがほとんどですが、Swayの場合は自分で設定することが必要です。具体的には以下のような記述があります。

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

今回は、polkit-gnomeを選択し、自動で起動するように~/.config/sway/configに

1
2

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

を書いて自動で起動するようにする設定しました。

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

まず、以下を実行して調査してみると、polkit,polkit-gnomeは共に確かに起動してることは確認できました。

`1`	`$ ps aux \| grep polkit`

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

`1`	`$ systemctl start docker.service`

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

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

`1`	`$ sudo pacman -S xorg-xhost`

これで解決です。

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をインストールしてデーモンを設定します。

1
2

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

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

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

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

`1`	`$ sudo pacman -S tpacpi-bat # install`

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

1
2

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

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

1
2

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

3: ディスプレイのlock

参考:

arch wiki セッションをロック

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

`1`	`$ 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,インプットメソッド等が見れて便利です。

`1`	`$ sudo pacman -S waybar # intall`

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

`1`	`$ 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を入れることで解決できました。

`1`	`$ 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に変えました。

`1`	`$ yay -S rofi-lbonn-wayland # install`

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

`1`	`$ 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に以下を書き足しました。

`1`	`bindsym $mod+z exec rofi -show drun`

Dropboxとpolkitについて

Wed, 01 Nov 2023 23:41:34 +0900

本記事は以前はてなブログに投稿していた記事の内容を加筆修正して移行したものです。

いつものように、Arch Linux + swayのマシンでDropboxを以下のように、CLIから起動しようとしました。

dropbox

すると、起動できず以下のようなエラーが出力されて起動できませんでした。

dropbox: load fq extension '/opt/dropbox/cryptography.hazmat.bindings._openssl.abi3.so'
dropbox: load fq extension '/opt/dropbox/cryptography.hazmat.bindings._padding.abi3.so'
dropbox: load fq extension '/opt/dropbox/apex._apex.abi3.so'
dropbox: load fq extension '/opt/dropbox/psutil._psutil_linux.cpython-38-x86_64-linux-gnu.so'
dropbox: load fq extension '/opt/dropbox/psutil._psutil_posix.cpython-38-x86_64-linux-gnu.so'
dropbox: load fq extension '/opt/dropbox/tornado.speedups.cpython-38-x86_64-linux-gnu.so'
dropbox: load fq extension '/opt/dropbox/wrapt._wrappers.cpython-38-x86_64-linux-gnu.so'
dropbox: load fq extension '/opt/dropbox/PyQt5.QtCore.so'
dropbox: load fq extension '/opt/dropbox/PyQt5.sip.so'
dropbox: load fq extension '/opt/dropbox/PyQt5.QtGui.so'
dropbox: load fq extension '/opt/dropbox/PyQt5.QtWidgets.so'
dropbox: load fq extension '/opt/dropbox/PyQt5.QtDBus.so'
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ====
Authentication is needed to run `/bin/sh /tmp/tmp4w886vq0' as the super user
Authenticating as: root
Password: 
==== AUTHENTICATION FAILED ====

メッセージの最後の方を読むとpolkitが原因でエラーが出ているようなので、まず、以下のコマンドで自分のシステムにインストールされているpolkit関係のパッケージを調べました。

`1`	`pacman -Q \| grep polkit`

結果としてpolkitとpolkit-gnomeがインストールされていることが分りました。

Arch wikiでpolkitを調べてみると以下のようにGNOME,KDE,Xfceのようなフルスタックなデスクトップ環境でははじめからインストールされていて、自動で起動するようになっていますが、swayのようなウィンドウマネージャーでは自分で起動するように設定する必要があるようです。

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

筆者はpolkitの実装とてしてはpolkit-gnomeを選び、swayが起動する時にpolkit-gnomeが起動するように、~/.config/sway/configに以下のように設定しました。

1
2

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

この後でこのマシンを再起動してdropboxを起動させると前のようにちゃんと起動するようになりました。

waybarを導入した

Sat, 09 Sep 2023 01:30:09 +0900

本記事は以前はてなブログに投稿していた記事の内容を加筆修正して移行したものです。

waybarを導入する理由

Arch Linux のデスクトップ環境としてタイル型ウィンドウマネージャーのswayを使用しているのですが、デフォルトのsway-barでは物足りないのでより高機能なwaybarを導入することにしました。

インストール

pacmanにより公式リポジトリからインストールします。

`1`	`sudo pacman -S waybar`

設定

まずデフォルトの設定、/etc/xdg/waybarを~/.config/以下にコピーします。

`1`	`cp -r /etc/xdg/waybar ~/.config/`

このままではデフォルトのsway-barが表示されたままで、waybarは表示されないので、先ほどコピーしてきた~/.config/sway/configの項目barを以下のように編集して、バーとしてwaybarを指定します。

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を追加することです(waybarを明示的に指定するということ)。

編集が終ったら、Super + Shift + C(デフォルトの設定)でSwayの設定(~/.config/sway/config)を再読込すると上部にbarが表示されるはずです。

しかし、筆者の環境では絵文字が文字化けしてしまいました。これは、以下のようにawesome-fontを入れることで解決できました。

`1`	`sudo pacman -S ttf-font-awesome`

参考
- swayのすゝめ
- gentoo wiki: Waybar

デフォルトではたくさん表示されてごちゃごちゃしているので、設定ファイル~/.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を編集して好みの色になるようにしました。結果として、以下のような見た目になりました。

WezTermを試してみる

Sat, 09 Sep 2023 01:20:12 +0900

本記事は以前はてなブログに投稿していた記事の内容を加筆修正して移行したものです。

きっかけ

筆者はこれまでGNU/Linuxのディスクトップ環境としてXfce4を使用してきて、特にこだわりを持っていなかったためXfce4標準のXfce terminalを使用してきました。

Xfce terminalは動作が軽快で、背景透過機能、タブ機能があり Alt + 数字keyでタブ移動ができたりと機能的には特に不満はありませんでした。

しかし、最近Qiita,Zenn等で"WezTermなるターミナルエミュレーターがいいぞ!“という記事を多く見まして気になったので試してみることにしました。設定ファイルをLuaで書くことができて高機能でカスタマイズ性が高く、Rustで実装されています!

インストール

Arch Linuxでは、普通にpacmanでインストールできます。

`1`	`sudo pacman -S wezterm`

以前にインストールしたときはAURの方の末尾がgitのパッケージしか存在せず、インストール時にソースからビルドに時間するため時間を要していましたが、今回はArch Linxのリポジトリからビルド済みのバイナリのインストールが可能でした。

設定

設定は$HOME/.wezterm.luaに記述するのですが、設定ファイルをGitで管理したいのでローカルリポジトリ内に.wezterm.luaを置き、 HOMEに対してシンボリックリンクを作ることにしました。

まずはじめに

まずはLuaからWezTermのAPIにアクセスしなければならないので以下を先頭に記述します。

.wezterm.lua

-- pull in the wezterm API
local wezterm = require 'wezterm'

-- this table will hold the configuration
local config = {}

if wezterm.config_builder then
    config = wezterm.config_builder()
end

設定は空のテーブルconfigを作成してから、

`1`	`config.<field name> = <filed>`

で設定していきます。

最後に設定を格納したテーブルであるconfigをWezTerm側にから読めるようにするために末尾の行に

`1`	`return config`

としてconfigをreturnしてあげます。

背景色&背景透過

Xfce terminalでは先に述べたように背景透過、タブ移動のショートカットkeyを使っていたので今回は、これを設定をしました。

まずテーブルcolorを設定して色の設定をします。

-- custemize color scheme
config.colors = {
  -- Make the selection text color fully transparent.
  -- When fully transparent, the current text color will be used.
  selection_fg = 'none',
  -- Set the selection background color with alpha.
  -- When selection_bg is transparent, it will be alpha blended over
  -- the current cell background color, rather than replace it
  selection_bg = 'rgba(50% 50% 50% 50%)',
}

背景透過の設定では、透過率は、config.window_background_opacityで設定します。

1
2

-- transparent background
config.window_background_opacity = 0.79

自分の好みの見た目は0.79です。

タブ移動のキーバインド

次にタブ移動のキーバインドを設定します。

公式にタブ移動のkey設定の例があったのでこれを参考にしてAlt + 数字keyで移動できるように設定しました。

-- keybinding

config.keys = {}

-- move to n-1 th Tab: ALT + n  
local function move_nth_tab()
    for i = 1, 8, 1 do
        table.insert(config.keys, {
        key = tostring(i),
        mods = 'ALT',
        action = wezterm.action.ActivateTab(i - 1)
        })
    end
end
move_nth_tab()

カスタムキーを設定するにはまずconfigにテーブルkeyを格納します。このkeyに各keyの設定を以下の書式のテーブルを格納します。

{
    key = <name of key>,
    mods = <name mod key>,
    action = <action> 
}

各フィールドの意味は以下の通りです。

key: 押すキーの名前を指定する文字列型の値
mods: SuperKey(Windowsで言うところのwindows key)やAlt keyを指定する文字列型の値
action: 一番目、二番目で指定したキーが押された時に動作する関数を指定します

二番のフィールドmodsで２つのキーを組み合わせたい場合(例:Shift + Ctrl)では２つの文字列を’SHIFT|CTRL’のように’|‘で区切って書きます。

デスクトップ環境との相性について

x11 + xfce4のデスクトップマシンでは、すぐには、インライン入力ができなかったのでFcitx5: リアルタイム入力（インライン入力）のための設定を参考にしてfcitx5の設定を行ったら問題なくインライン入力ができるようになりました。

一方、swayを使っているサブのASUSのラップトップでは日本語のインライン入力はできるが、IMEの候補がポップアップで表示されませんできました。 (追記@ 2025 12/29 現在では特に問題なくFcitx5による日本語入力ができています)。

実際に使ってみて

X11 + xfce4環境、Sway(Wayland)環境は両方とも日本語入力に多少の難があったので、すぐにWezTermには移行せず、まだ両方とも使うということになりそうです。また、WezTermからneovimで開いてコードを編集しているときにCtrl + '+'でコードのインデントを整理しようとすると画面が拡大してしまう問題も解決できていません。 (追記@ 2025 12/29 現在ではコードフォーマットは mhartington/formatter.nvimで各プログラミング言語ごとに設定して:wでフォーマットされるように設定しているので特に問題ないです)

Search

Mon, 01 Jan 0001 00:00:00 +0000

aki.blog

Codex CLIをOpenRouterで使う

OpenRouterとは？

なぜCodex CLIを選択したのか？

とりあえず openai/gpt-oss-120b:freeを叩いてみる

codexの導入と設定

アカウントの作成とAPI keyの作成

codexの設定

実行

MCPサーバーを動かす

CodeCompanion.nvim + Gemini CLIで四苦八苦

プロローグ

とりあえず設定してみたものの…

コードを手探る

どのへんを見れば原因が特定できそうか？

当りは付いたので、ロガーを入れて確かめてみる

commands.default = {}で明示的にモデル名を与える => 動く

モデル選択をスマートに

感想

Neovim上のLuaのコードをNeovimでデバッグ実行する

やりたいこと

しかし…

動機

どの手法を使うか？

setup

インストール

アダプタの設定

その他解説上必要になりそうな設定

デバッグ実行を開始する

Luaのスクリプトをデバッグ実行する

自作コマンドや、関数にした処理は？

プラグインの場合は？

感想

Neovimでリモートデバッグの設定をする

この記事について

前提

デバッガ側

Pythonの場合

C/C++/Rustの場合

Neovim側

Python by debugpy

C/C++/Rust by gdb

デバッグの実行

コンテナの名のプラグラムをデバッグする場合

感想

resession.nvimからdirenvを叩けるようにした

direnvとNeovim

direnvとその実行について

Neovimでどうプロジェクトを開くか？

resession.nvimとdirenv.nvimを併用することで起る問題について

direnv.nvimをディレクトリ移動でフックする場合

direnv.nvimをバッファの読み込みでフックする場合

解決策を探る

resession.nvimの勘所

解決策(1: 失敗)

direnvの勘所

解決策(2: 成功)

ハマりポイント&感想

ハマったポイント

感想

追記@ 2026 01/19

"大規模ソフトウェアを手探る"をやる (2: Nixに移行編)

経緯

なぜNixに移行するのか？

移行作業は？

環境構築 by flake.nix

要件1,2(ビルド環境)について

要件3,4(コードを読む環境)について

完成したflake.nix

NixOSでセキュアブートを設定する

鍵の操作

sbctlによる鍵の作成

作成した鍵のenroll

lanzabooteの設定

とりあえず設定する

保存しておく世代について

同居(別のディスクからデュアルブートしている)windowsの様子は？

最後に

NixOSでLUKSによるディスク暗号化を設定する

ディスク暗号化を設定する動機は？

`commands.default = {}`で明示的にモデル名を与える => 動く

`lanzaboote`の設定

LUKSによる`/`の暗号化

`Lua5.2.4`をソースからビルドする

気を取り直して`gnuplot-5.0.1`をビルドする