部屋を片付けてスペースができたので Wi-Fi ルーターを箱から出して窓の近くに置く.
この部屋は電波が入りにくい構造のようで, 窓際に寄らないと通話やラジオの再生が途中で途切れてしまっていた.
ルーターを置くことで, 室内の通信環境が良くなるだろう.
2024年09月18日
2024年08月02日
システム管理: Emacs HEAD のコンパイル・インストール ── 2024 年 8 月
OpenBSD のアップグレードが終わったので, 次に Emacs HEAD のコンパイルとインストールを行う.
問題無く終了した.
emacs_dir /etc/NEWS によれば, find-function, find-library, find-face-defintion で検索する関数, ライブラリー, フェイス定義を過去の入力履歴から選ぶことができるようになっている.
自分にとっては頻繁に使う機能では無いが, 少し便利になる.
$ export AUTOCONF_VERSION="2.71"
$ export AUTOMAKE_VERSION="1.16"
$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib/gcc/x86_64-unknown-openbsd7.5/11.2.0
$ cd emacs_dir
$ git pull
$ gmake bootstrap
$ gmake check
# gmake install
問題無く終了した.
emacs_dir /etc/NEWS によれば, find-function, find-library, find-face-defintion で検索する関数, ライブラリー, フェイス定義を過去の入力履歴から選ぶことができるようになっている.
自分にとっては頻繁に使う機能では無いが, 少し便利になる.
M-x emacs-version
This is GNU Emacs 31.0.50 (build 1, x86_64-unknown-openbsd7.5,
X toolkit, cairo version 1.18.0, Xaw3d scroll bars) of 2024-08-02
システム管理: OpenBSD のアップグレード ── 2024 年 8 月 (2)
昨日から走らせていたベースシステムのコンパイルが終了した.
先月は 14 時間ほどで終わったが, 今回は 17 時間かかった.
ベースシステムをマージし, デバイスを作成する.
次いで X 関連のコンパイル・インストール作業を行う.
先月は途中でコンパイルエラーが発生して, やり直したらうまくいったのだった.
今回は一度の実行で make が終了した.
最後にパッケージのアップデートを行う.
問題無く終了.
今月の OpenBSD のアップグレード作業が終わった.
先月は 14 時間ほどで終わったが, 今回は 17 時間かかった.
ベースシステムをマージし, デバイスを作成する.
# sysmerge
# cd /dev/ && ./MAKEDEV all
次いで X 関連のコンパイル・インストール作業を行う.
# cd /usr/xenocara
# make bootstrap
# make obj
# make build
先月は途中でコンパイルエラーが発生して, やり直したらうまくいったのだった.
今回は一度の実行で make が終了した.
最後にパッケージのアップデートを行う.
# pkg_add -uv
問題無く終了.
今月の OpenBSD のアップグレード作業が終わった.
$ uname -a
OpenBSD mybsd.local 7.5 GENERIC.MP#29 amd64
2024年08月01日
システム管理: OpenBSD のアップグレード ── 2024 年 8 月 (1)
昼間は鬱が辛かったが, 夜になって少し元気が出てきたので月初めの OpenBSD のアップグレード作業を行う.
最初にベースシステム, X 関連, ports をアップデートする.
最新のスナップショットへのアップグレードを行う.
新しいソースでカーネルの再構築とシステムの再起動を行う.
ベースシステムの構築を行う.
これは時間がかかるので, 以降の作業は明日以降にする.
最初にベースシステム, X 関連, ports をアップデートする.
$ cd /usr/src
$ cvs -q up -Pd -A
$ cd /usr/xenocara
$ cvs -q up -Pd -A
$ cd /usr/ports
$ cvs -q up -Pd -A
最新のスナップショットへのアップグレードを行う.
# sysupgrade -s
新しいソースでカーネルの再構築とシステムの再起動を行う.
# cd /sys/arch/$(machine)/compile/GENERIC.MP
# make obj
# make config
# make && make build
# shutdown -r now
ベースシステムの構築を行う.
# cd /usr/src
# make obj && make build
これは時間がかかるので, 以降の作業は明日以降にする.
2024年07月07日
システム管理: システムのパフォーマンスが急に低下する
Emacs で作業をしていたら, 突然入力が異常に遅くなった.
最初はキーボードを押して反応が数秒かかるくらいだったのが, たちまち無反応になった.
ブラウザーにウィンドウを切り換えてみると, 描画に数分かかってやっとブラウザーのウィンドウが前面に来る.
マウスも反応が遅い. 使い物にならない.
システム全体が機能しなくなっている.
幸いキーボードショートカットは動作したので, とりあえずウィンドウマネージャを終了させる.
その後再ログインすると, 一連のパフォーマンスの低下は解消していた.
念のためシステムを再起動する.
再起動した後に気付いたのだが Emacs の core ファイルができている.
心当たりは無いが, 現在使っている Emacs は起動後ある程度の時間が経つとこのような症状を引き起こして異常終了するのだろうか.
調べてみないとわからない.
最初はキーボードを押して反応が数秒かかるくらいだったのが, たちまち無反応になった.
ブラウザーにウィンドウを切り換えてみると, 描画に数分かかってやっとブラウザーのウィンドウが前面に来る.
マウスも反応が遅い. 使い物にならない.
システム全体が機能しなくなっている.
幸いキーボードショートカットは動作したので, とりあえずウィンドウマネージャを終了させる.
その後再ログインすると, 一連のパフォーマンスの低下は解消していた.
念のためシステムを再起動する.
再起動した後に気付いたのだが Emacs の core ファイルができている.
心当たりは無いが, 現在使っている Emacs は起動後ある程度の時間が経つとこのような症状を引き起こして異常終了するのだろうか.
調べてみないとわからない.
2024年07月02日
システム管理: Emacs HEAD のコンパイル・インストール ── 2024 年 7 月
Emacs HEAD のコンパイルとインストールを行う.
問題無く終了した.
Emacs HEAD のコンパイルでは, すでに --with-native-compilation オプションの指定が必要なくなって, デフォルトで Emacs Lisp のネイティブコンパイルが指定されるようになっている. configure スクリプトをそのように実行しておけばよかった.
次回の課題とする.
$ cd $emacs_dir
$ git pull
$ export AUTOCONF_VERSION="2.71"
$ export AUTOMAKE_VERSION="1.16"
$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib/gcc/x86_64-unknown-openbsd7.5/11.2.0
$ git pull
$ gmake bootstrap
$ gmake check
# gmake install
問題無く終了した.
Emacs HEAD のコンパイルでは, すでに --with-native-compilation オプションの指定が必要なくなって, デフォルトで Emacs Lisp のネイティブコンパイルが指定されるようになっている. configure スクリプトをそのように実行しておけばよかった.
次回の課題とする.
M-x emacs-version
This is GNU Emacs 31.0.50 (build 1, x86_64-unknown-openbsd7.5,
X toolkit, cairo version 1.18.0, Xaw3d scroll bars) of 2024-07-02
システム管理: OpenBSD のアップグレード作業 ── 2024 年 7 月 (2)
朝, 昨日から走らせていたベースシステムのコンパイルが終了していたのでマージ作業とデバイスの作成作業を行う.
次いで X 関連のコンパイル・インストール作業に入る.
ところが, 途中でシステムがフリーズする.
各ウィンドウでキーボードとマウスの入力をまったく受け付けない.
仕方が無いので電源を強制的に切って再起動する.
X のコンパイル作業に問題があったのか, それよりも深い問題なのかわからない.
とりあえず問題が再現するかどうか, もう一度同じ手順で X 関連のコンパイルを行ってみた.
すると今回はコンパイル・インストールがうまく行き, システムのフリーズなども発生しない.
問題の原因などもわからないままだが作業を進める.
必ずどこかで発生する問題ならば, また現れるだろう.
パッケージのアップデートを行う.
これで OpenBSD のアップグレード作業が終わった.
# sysmerge
# cd /dev/ && ./MAKEDEV all
次いで X 関連のコンパイル・インストール作業に入る.
# cd /usr/xenocara
# make bootstrap
# make obj
# make build
ところが, 途中でシステムがフリーズする.
各ウィンドウでキーボードとマウスの入力をまったく受け付けない.
仕方が無いので電源を強制的に切って再起動する.
X のコンパイル作業に問題があったのか, それよりも深い問題なのかわからない.
とりあえず問題が再現するかどうか, もう一度同じ手順で X 関連のコンパイルを行ってみた.
すると今回はコンパイル・インストールがうまく行き, システムのフリーズなども発生しない.
問題の原因などもわからないままだが作業を進める.
必ずどこかで発生する問題ならば, また現れるだろう.
パッケージのアップデートを行う.
# pkg_add -uv
これで OpenBSD のアップグレード作業が終わった.
$ uname -a
OpenBSD mybsd.local 7.5 GENERIC.MP#28 amd64
2024年07月01日
システム管理: OpenBSD のアップグレード ── 2024 年 7 月 (1)
月初めなので, OpenBSD のアップグレード作業を行う.
・ ベースシステム, X 関連, ports のアップデート
・ スナップショットへのアップグレード
・ カーネルの再構築とシステムの再起動
・ ベースシステムの構築
このコンパイル終了までに半日以上かかる.
以降の作業, X 関連の構築とパッケージのアップデートは明日, コンパイルが終了してから行う.
・ ベースシステム, X 関連, ports のアップデート
$ cd /usr/src
$ cvs -q up -Pd -A
$ cd /usr/xenocara
$ cvs -q up -Pd -A
$ cd /usr/ports
$ cvs -q up -Pd -A
・ スナップショットへのアップグレード
# sysupgrade -s
・ カーネルの再構築とシステムの再起動
# cd /sys/arch/$(machine)/compile/GENERIC.MP
# make obj
# make config
# make && make build
# shutdown -r now
・ ベースシステムの構築
# cd /usr/src
# make obj && make build
このコンパイル終了までに半日以上かかる.
以降の作業, X 関連の構築とパッケージのアップデートは明日, コンパイルが終了してから行う.
2024年06月13日
Emacs: やてふモードで TeX ファイルが色付きにならない問題
6 月に入って最新の Emacs HEAD をコンパイル・インストールしたが, TeX ファイルをやてふ (YaTeX) モードで開いたときにファイル表示に色が付かないことに気が付いた.
\$HOME/.emacs.d/init.el ファイルを確認すると,
と設定してある.
また, YaTeX-use-font-lock 変数は t になっている.
つまりグローバルでもローカルでも, やてふモードでは font-lock mode は有効になっている筈である.
ところが, Emacs 上からは
となっていて, グローバルの font-lock mode はなぜか有効になっていない.
ただ, やてふモードでの色付けがない Emacs 上で
を実行すると TeX ファイルのバッファーに色付けがされる.
どうして今回の Emacs30 のやてふモードでこのようになってしまうのか.
\$ emacs_dir /etc/NEWS などを読んでみたが原因はわからず.
結局 init.el 内のやてふの設定を
として, Emacs 起動後から TeX ファイルに色が付くようにした.
すっきりしないが, ひとまずこの対応で凌ぐ.
\$HOME/.emacs.d/init.el ファイルを確認すると,
(require 'font-lock)
(global-font-lock-mode t)
. . . .
(setq YaTeX-use-font-lock t)
と設定してある.
また, YaTeX-use-font-lock 変数は t になっている.
つまりグローバルでもローカルでも, やてふモードでは font-lock mode は有効になっている筈である.
ところが, Emacs 上からは
M-x global-font-lock-mode
Global Font-Lock mode disabled
となっていて, グローバルの font-lock mode はなぜか有効になっていない.
ただ, やてふモードでの色付けがない Emacs 上で
Eval: (global-font-lock-mode t)
を実行すると TeX ファイルのバッファーに色付けがされる.
どうして今回の Emacs30 のやてふモードでこのようになってしまうのか.
\$ emacs_dir /etc/NEWS などを読んでみたが原因はわからず.
結局 init.el 内のやてふの設定を
;;; YaTeX
(setq auto-mode-alist
(cons (cons "\\.\\(tex$\\|sty$\\|ltx$\\|cls$\\|clo$\\|bbl$\\)"
'yatex-mode)
auto-mode-alist))
(autoload 'yatex-mode "yatex" "Yet Another LaTeX mode" t)
(add-hook 'yatex-mode-hook ; 新たに追加
'(lambda () (font-lock-mode))) ; 同上
として, Emacs 起動後から TeX ファイルに色が付くようにした.
すっきりしないが, ひとまずこの対応で凌ぐ.
2024年06月05日
システム管理: Emacs HEAD のコンパイル・インストール ── 2024 年 6 月 (2)
Github.com へのコミットを Magit (Emacs から git を呼び出すパッケージ) 経由で行おうとしたら, 次のようなエラーが出た.
● git のログ表示コマンド (git-log) 実行時:
● ローカルブランチの切り換え時 (git-branch) 実行時:
これらの原因については思い当たることがある.
今回の Emacs HEAD のインストール時に Magit パッケージの設定を変更した.
以前: Magit パッケージをソースコードからバイトコンパイルした結果を \$HOME/.emacs.d/site-lisp 以下に置いていた.
それに対応して, init.el 内で load-path 変数の設定に
のような変更を加えた.
今回: \$HOME/.emacs.d/site-lisp ディレクトリー配下内に置いてある Emacs Lisp パッケージを見直して, ほぼ全てが GNU ELPA からインストールしたパッケージで置き換えられることがわかった.
それで site-lisp ディレクトリー以下からの (1) パッケージファイルの削除; (2) そのパッケージの GNU ELPA からのインストールの 2 つを行った.
問題は, この変更に合わせて init.el 内の上記の記述を
のようにコメントアウトすべきだったがそれを行わなかったことである. 忘れてしまった.
この結果, 古い load-path のの設定だけが中途半端に残る.
いくつかの Magit コマンドは, init.el の古い設定にしたがって削除済みの Emacs Lisp ファイル, たとえば \$HOME/.emacs.d/magit/lisp 以下や \$HOME/d.emacs.d/transient/lisp 以下に置かれていた Emacs Lisp ファイルを読みに行ってしまう. それがエラーになっていたのではないだろうか.
あらためて init.el 内の不要になった処理のコメントアウトを行うことにより, Magit が問題無く動くようになった.
● git のログ表示コマンド (git-log) 実行時:
Suffice magit-log:--*-order is not defined or autoloaded as a command
● ローカルブランチの切り換え時 (git-branch) 実行時:
Suffix magit-branch..rebase is not defined as a command
これらの原因については思い当たることがある.
今回の Emacs HEAD のインストール時に Magit パッケージの設定を変更した.
以前: Magit パッケージをソースコードからバイトコンパイルした結果を \$HOME/.emacs.d/site-lisp 以下に置いていた.
それに対応して, init.el 内で load-path 変数の設定に
(add-to-list 'load-path "~/.emacs.d/site-lisp/magit/lisp")
(add-to-list 'load-path "~/.emacs.d/site-lisp/transient/lisp")
のような変更を加えた.
今回: \$HOME/.emacs.d/site-lisp ディレクトリー配下内に置いてある Emacs Lisp パッケージを見直して, ほぼ全てが GNU ELPA からインストールしたパッケージで置き換えられることがわかった.
それで site-lisp ディレクトリー以下からの (1) パッケージファイルの削除; (2) そのパッケージの GNU ELPA からのインストールの 2 つを行った.
問題は, この変更に合わせて init.el 内の上記の記述を
;; (add-to-list 'load-path "~/.emacs.d/site-lisp/magit/lisp")
;; (add-to-list 'load-path "~/.emacs.d/site-lisp/transient/lisp")
のようにコメントアウトすべきだったがそれを行わなかったことである. 忘れてしまった.
この結果, 古い load-path のの設定だけが中途半端に残る.
いくつかの Magit コマンドは, init.el の古い設定にしたがって削除済みの Emacs Lisp ファイル, たとえば \$HOME/.emacs.d/magit/lisp 以下や \$HOME/d.emacs.d/transient/lisp 以下に置かれていた Emacs Lisp ファイルを読みに行ってしまう. それがエラーになっていたのではないだろうか.
あらためて init.el 内の不要になった処理のコメントアウトを行うことにより, Magit が問題無く動くようになった.
