more vim

Arch Linuxの肥大化防止
ed
nvimの成分分析
- apt (list|show)
vim + gdb
vim on OpenBSD
vim vs emacs
- file viewer
- with gdb
- tag jump
- help
dataset for AI

Arch Linuxの肥大化防止

Archを入れて１月が経過した。dfすると順調に太っている。肥満は体によくないSDDにもよくない。で、ダイエットです。

肥大化の原因は分っている。もしもの為って亊で、pacmanで更新したパッケージがキャッシュされ続けてしまうため。現状を確認。

[sakae@arch pacman]$ du -s pkg/
2712924 pkg/
[sakae@arch pacman]$ ls pkg/*.zst | wc -l
511

キャッシュの内容の一部。ちょっとづつ古いものも、大事に取ってあるんだ。

-rw-r--r-- 1 root root  13630192 Jun 12 01:25 qt5-base-5.15.4+kde+r168-1-x86_64.pkg.tar.zst
-rw-r--r-- 1 root root  13630798 Jun 19 19:50 qt5-base-5.15.5+kde+r163-1-x86_64.pkg.tar.zst
-rw-r--r-- 1 root root  13634191 Jun 30 16:10 qt5-base-5.15.5+kde+r166-1-x86_64.pkg.tar.zst
-rw-r--r-- 1 root root  13633636 Jul  4 19:50 qt5-base-5.15.5+kde+r167-1-x86_64.pkg.tar.zst
-rw-r--r-- 1 root root  13634074 Jul  6 06:50 qt5-base-5.15.5+kde+r170-1-x86_64.pkg.tar.zst

ええい、ダイエット実施

[sakae@arch ~]$ sudo pacman -Sc
Packages to keep:
  All locally installed packages

Cache directory: /var/cache/pacman/pkg/
:: Do you want to remove all other packages from cache? [Y/n] y
removing old packages from cache...

Database directory: /var/lib/pacman/
:: Do you want to remove unused repositories? [Y/n] y
removing unused sync repositories...

これで、どのぐらいになったんだろう。期待の確認。

[sakae@arch pacman]$ du -s pkg/
1005508 pkg/
[sakae@arch pacman]$ ls pkg/*zst | wc -l
414

月に一度ぐらいは、実施せいという亊だな。

ed

前回はOpenBSDのedを紙上？追跡してみた。でも、やっぱり生態解剖したい。要になるのは、ed.hに定義されてる、下記の構造体だ。一行を表す双方向のリンクリストだ。何故、双方向かは、素早く必要な場所に辿りつくため。データとしては、どこかに有るバッファーの先頭からの位置(seek)とその長さだ。

こうしておけば、何処かにあるバッファーは、メモリー上でもいいし、追記出来るファイルでもよい。行が編集されて内容が変っても、それを書き換えず、新しい行の内容を追記し、それを指し示すように、 line_t を変更するだけだ。

インメモリーで管理しなきゃいけないのは、この line_t の連なりだけなんで、メモリーを有効利用出来、より大きなファイルを扱えるようになる。

/* Line node */
typedef struct  line {
        struct line     *q_forw;
        struct line     *q_back;
        off_t           seek;           /* address of line in scratch buffer */
        int             len;            /* length of line */
} line_t;

,n
1       A
2       BC
3       DEF
4       GHIJ

こんなデータを用意しておいて、行の表現を追跡してみた。

Breakpoint 2, display_lines (from=1, to=4, gflag=8) at main.c:1221
1221            if (!from) {
(gdb) n
1225            ep = get_addressed_line_node(INC_MOD(to, addr_last));
(gdb)
1226            bp = get_addressed_line_node(from);
(gdb)
1227            for (; bp != ep; bp = bp->q_forw) {
(gdb) p bp
$8 = (line_t *) 0x6d424f40
(gdb) p *$
$9 = {q_forw = 0x6d43c860, q_back = 0x34a0d278 <buffer_head>, seek = 0, len = 1}
(gdb) p *$.q_forw
$10 = {q_forw = 0x6d43c640, q_back = 0x6d424f40, seek = 1, len = 2}
(gdb)
$11 = {q_forw = 0x6d4566e0, q_back = 0x6d43c860, seek = 3, len = 3}
(gdb)
$12 = {q_forw = 0x34a0d278 <buffer_head>, q_back = 0x6d43c640, seek = 6, len = 4}
(gdb)
$13 = {q_forw = 0x6d424f40, q_back = 0x6d4566e0, seek = 0, len = 0}
(gdb) p *$.q_back
$14 = {q_forw = 0x34a0d278 <buffer_head>, q_back = 0x6d43c640, seek = 6, len = 4}
(gdb)
$15 = {q_forw = 0x6d4566e0, q_back = 0x6d43c860, seek = 3, len = 3}
(gdb)
$16 = {q_forw = 0x6d43c640, q_back = 0x6d424f40, seek = 1, len = 2}
(gdb)
$17 = {q_forw = 0x6d43c860, q_back = 0x34a0d278 <buffer_head>, seek = 0, len = 1}

nvimの成分分析

前回やったneovimことnvimの成分がどうなってるか、調べてみる。成分分析表は、lddで得られる。下記は、arch linuxに入れたやつ。

[sakae@arch ~]$ ldd /usr/bin/nvim
        linux-vdso.so.1 (0x00007fffd6327000)
        libluv.so.1 => /usr/lib/libluv.so.1 (0x00007fadca577000)
        libuv.so.1 => /usr/lib/libuv.so.1 (0x00007fadc91ce000)
        libmsgpackc.so.2 => /usr/lib/libmsgpackc.so.2 (0x00007fadca56d000)
        libvterm.so.0 => /usr/lib/libvterm01/libvterm.so.0 (0x00007fadc91bc000)
        libtermkey.so.1 => /usr/lib/libtermkey.so.1 (0x00007fadca561000)
        libunibilium.so.4 => /usr/lib/libunibilium.so.4 (0x00007fadc91a7000)
        libtree-sitter.so.0 => /usr/lib/libtree-sitter.so.0 (0x00007fadc9178000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007fadc9091000)
        libluajit-5.1.so.2 => /usr/lib/libluajit-5.1.so.2 (0x00007fadc9001000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fadc8fe1000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007fadc8c00000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fadc8fdc000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fadc8fd5000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fadca5b6000)

debianとかだと、libのエリアが64,32bit用に分離されてて煩わしいけど、archはすっきりだ。64bitしか許容しないんで、分る必要が無いんだね。

で、これらのlibがどんな働きをするものか、どうやって調べる？ウーンと唸って辿り付いた方法が、OpenBSDのportsのMakefileを眺める亊。一体、どんなロジックでそんな発想になる？全く関係ないだろう。

この間、NHKで始まった、数学なんちゃらって番組で素数が採り上げられていた。素数が哀られる間隔に数学的な根拠があるのか？数学の学者が頭を悩ましていた問題。考え過ぎて人生をぼうに振ってしまった人がいるらしい。

で、どうやらこうでないかいと言う式が建られた。知の殿堂のある研究所で、たまたま物理学者とその数学者が雑談。素数の間隔は、こんな式で表わせそうって数学者。物理学者は、その式を見て、あれ、この式、原子核のエネルギー順位を表す式と一緒じゃん。別の業界の話も聞いてみるものだ。

で、話を戻して、Makefile内の一節

LIB_DEPENDS =           devel/gettext,-runtime \
                        devel/libtermkey \
                        devel/libuv \
                        devel/libvterm \
                        devel/msgpack \
                        devel/unibilium \
                        textproc/tree-sitter

これの何が嬉しい？例えば、tree-sitterに何様って調べたい。ならば、

ob$ cat /usr/ports/textproc/tree-sitter/pkg/DESCR
Tree-sitter is a parser generator tool and an incremental parsing library. It
can build a concrete syntax tree for a source file and efficiently update the
syntax tree as the source file is edited.

Tree-sitter aims to be:

  General enough to parse any programming language
  Fast enough to parse on every keystroke in a text editor
  Robust enough to provide useful results even in the presence of syntax errors
  Dependency-free so that the runtime library (which is written in pure C) can
  be embedded in any application

editorの癖にパーサーが必要って、オイラー的にはイカレてると思うぞ。典型的な、なんでも症候群のような気がする。まあ、中の人に言わせると、色を付けるとか構文の間違いを簡単に指摘出来るでしょ、って亊になるのかな。

もう一例、msgpackって何者ぞ？

ob$ cat /usr/ports/devel/msgpack/pkg/DESCR
MessagePack is an efficient binary serialization format, which lets you
exchange data among multiple languages like JSON, except that it's
faster and smaller. Small integers are encoded into a single byte while
typical short strings require only one extra byte in addition to the
strings themselves.

多分、外部アプリと通信を素早くやりたい為の部品集なのでしょう。マイクロソフトご提案の、ランゲッジ・サーバーあたりと通信して、補完をしたいなんて場合、速やかにデータ交換が必要。

こんな調子で、異OSと交流すると、良い亊があるよって例でした。こんな亊、debianだけで、簡単に調べる方法って有るのだろうか？多分、難解なパッケージのインフォメーションでも紐解く必要が有るんだろうね。

apt (list|show)

忘れないうちに調べてみた。apt listを使って、パッケージ名を割り出す。apt listの代わりに、apt-file search hogeでもいいのかな。

sakae@pen:~$ apt list --installed|grep libuv

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libuv1/stable,now 1.40.0-2 amd64 [installed,automatic]

次に、そのパッケージの詳細を確認するとな。

sakae@pen:~$ apt show libuv1
  :
Description: asynchronous event notification library - runtime library
 Libuv is the asynchronous library behind Node.js. Very similar to libevent or
 libev, it provides the main elements for event driven systems: watching and
 waiting for availability in a set of sockets, and some other events like timers
 or asynchronous messages. However, libuv also comes with some other extras
 like:

vim + gdb

【Vim8.1.xから標準機能】VimからGDBを起動する方法

6. デバッグ by vim-jp

pdbはどうするんだとか、あるけど、まあ目出度い亊だ。Debianが入ってるThinkPad SL510だと、コンソールで使うと stty -a で48x170 となってた。

これだけ広ければ、左上にgdb、左下にアプリ用のコンソール、右側でソース表示っていう、憧れの環境を楽しめる。

vim on OpenBSD

遂にOpenBSDにもvimを入れる亊にした。今迄emacs一本槍だったけど、利用方法を思い出すと、tagさーチとgdbの利用、それにファイル閲覧ぐらいしか使っていなかったから。このどれもvimで代用出来る亊を知った今、セカンド・オピニオンって亊でね。

vim-8.2.4600-gtk3-lua.tgz                    2022-04-11 8.9M
vim-8.2.4600-gtk3-perl-python3-ruby.tgz      2022-04-11 9.0M
vim-8.2.4600-gtk3-python3.tgz                2022-04-11 8.9M
vim-8.2.4600-gtk3.tgz                        2022-04-11 8.8M
vim-8.2.4600-no_x11-lua.tgz                  2022-04-11 8.7M
vim-8.2.4600-no_x11-perl-python3-ruby.tgz    2022-04-11 8.9M
vim-8.2.4600-no_x11-python3.tgz              2022-04-11 8.7M
vim-8.2.4600-no_x11-ruby.tgz                 2022-04-11 8.9M
vim-8.2.4600-no_x11.tgz                      2022-04-11 8.7M

こんなのが用意されたので、言語無し、x11無しっていう軽いやつを選んだ。知らないライブラリーが使われていた。libsodiumですって。早速調べてみる。

vbox$ cat /usr/ports/security/libsodium/pkg/DESCR
NaCl (pronounced "salt") is a new easy-to-use high-speed software library
for network communication, encryption, decryption, signatures, etc.
NaCl's goal is to provide all of the core operations needed to build
higher-level cryptographic tools.

Sodium is a fork of NaCl with a compatible API. Unlike NaCl, Sodium
performs checks for hardware features at runtime instead of compile time,
making it suitable for packaging.

NaClっていう化学式で表されるやつがあったとな。世間一般には、塩ってやつだ。それが分離したんか、だったらMgClぐらいにしとけと思うのはオイラーだけ。ああ、MgClって、にがりの亊ね。これなしでは豆腐を作れないぞ。日本人にお馴染だ。これなら愛着がわくのに。

vimrc

設定の変更って亊で、vimrcのお手軽設定方法が紹介されてる。けど、オイラーはあえて、自分に必要なものを付け足す亊にした。こうしておけば、不便を感じたら自分で調べるでしょ。そこから、新な知見が得られると思うから。で、下記は、そのスタート台です。

vbox$ cat .vim/vimrc
set background=dark
syntax on

packadd termdebug
let g:termdebug_wide = 126
set mouse=a

gdbの3窓を左右に分るには、上記のwide設定が必要。これが無いと、上中下に窓が出来てしまう。

単純なvimでも、ちゃんとマウスが使えた。そんなものなのか。プチ感激してるぞ。上の窓の横幅は、PuTTYを目一杯拡げた時のサイズ。これでも、何とか使えた。

tag jump

emacsを使ってOpenBSDカーネルの観光をする時に、無理してemacs用のTAGを作った。デフォでは、下記のようにctags用になってるんだけどね。で、出来たサイズが150Mを越えてたんで、emacsから注意を受けたんだ。

vimでやったらどうなる？

vbox$ cd /sys/arch/i386/
vbox$ cat Makefile
 :
tags::
        TDIR=`mktemp -d /tmp/_tagXXXXXXXXXX` || exit 1; \
        eval "S=${S}" && \
        config -s ${S} -b $${TDIR} ${.CURDIR}/conf/${KFILE} && \
        eval "_arch=\"`make -V _arch -f $${TDIR}/Makefile`\"" && \
        eval "_mach=\"`make -V _mach -f $${TDIR}/Makefile`\"" && \
        eval "_machdir=\$S/arch/$${_mach}" && \
        eval "_archdir=\$S/arch/$${_arch}" && \
        eval "HFILES=\"`find $S \( -path $S/'arch' -o -path $S/stand -o -path $S/lib/libsa -o -path $S'/lib/libkern/arch' \) -prune -o -name '*.h'; find $${_machdir} $${_archdir} $S/lib/libkern/arch/$${_mach} \( -name boot -o -name stand \) -prune -o -name '*.h'`\"" && \
        eval "SFILES=\"`make -V SFILES -f $${TDIR}/Makefile`\"" && \
        eval "CFILES=\"`make -V CFILES -f $${TDIR}/Makefile`\"" && \
        eval "AFILES=\"`make -V AFILES -f $${TDIR}/Makefile`\"" && \
        ctags -wd -f ${TAGS} $${CFILES} $${HFILES} && \
        egrep "^[_A-Z]*ENTRY[_A-Z]*\(.*\)" $${SFILES} $${AFILES} | \
            sed "s;\\([^:]*\\):\\([^(]*\\)(\\([^, )]*\\)\\(.*\\);\\3    \\1    /^\\2(\\3\\4$$/;" \
            >> ${TAGS} && \
        sort -o ${TAGS} ${TAGS} && \
        rm -rf $${TDIR}

アーキテクチャそれぞれ用にMakefileが用意される。取り敢えずi386のそれを作ってみた。

vbox$ ls -lh tags
-rw-r--r--  1 root  wheel   206M Jul 21 06:26 tags
vbox$ wc tags
 1263822 5814165 216266929 tags

200Mを越えてる。ctags -d で、#define部分も丁寧に取り込んでいるからだな。

:tags
  # TO tag         FROM line  in file/text
  1  1 sys_open            1  /sys/arch/i386/../../kern/vfs_syscalls.c
  2  1 proc             1048  /sys/arch/i386/../../kern/vfs_syscalls.c
  3  1 TAILQ_EMPTY       308  /sys/arch/i386/../../sys/proc.h

ちょいと使ってみた。tagsを開く時、文句を言われるでなし、さっと開いてくれた。動作もキビキビしてて、気持がよいぞ。

develop with vim

vimを使った開発はどうやれば良い？少し探ってみた。

まずは、manの参照。調べたい所にカーソルを持って行ってKだ。セクションを指定して調べる時は、5Kとか、セクション番号を前置すればよい。

次はヘッダーファイルの参照。やはりカーソルを持って行って、gf だ。終了は、Ctl-O。

素早くカーソルを移動するには、サーチ機能、/hoge する。目的ワードに達していなかったら、nして、次を探せばよい。なお、カーソルのある所を取り込んで、次をさがす時は、* してからnすればよい。一旦取り込んでしまえば、N で、ファイルの頭に向ってさがすのも有り。

更に、:makeと組み合わせて、コンパイル実行。エラーが発生したら、:copenしろ。そして、エラーを修整しろなんてのが指南されてた。詳細は、 Vimをプログラム開発環境にしてしまおう

vim vs emacs

ここまで、emacsな人がvimを使ってきたんで、使い心地の感想を述べておく。勿論、個人の偏見に満ちたものだから、鵜呑みにしないように。

file viewer

結論を言うと、emacsのdired.elの方が便利。ってか、慣れている。特典は、vでファイルを開いた時、画面の移動が、スペースとバックスペースだけで濟んでしまう亊。Ctl-F, Ctl-B みたいな面倒が無いのがよい。正直、この利点は譲れないです。

ああvimの名誉の為に言うね。"$VIMRUNTIME/macros/less.sh" のが用意されてる。適当な所に取出しておいて、./less.sh hoge.txt なんてやると、vim scriptのlessが動く。けど、これのお世話にはならないだろう。

lessからviが呼び出せる。なら、vimから純正のlessを呼び出せていいと思うんだけど、我侭かな。

with gdb

どちらかと言うとvimの方が便利。利点は３つの窓が一望出来る亊。窓間の移動にキー操作だけでなくマウスが使えるのが良い。

emacsでやると、debug対象の画面が増えてしまい鬱陶しい。それを嫌って、対象を別コンソールで起ち上げ、gdbをアタッチしてた。これで、emacs画面は、gdbとソースだけには成る。但しこの方法だと、対象が定常状態になった以降しか観光出来無い。vimだとそれが無い。

但し、カーネル観光の場合は、３つの窓を開いてしまう vim系は逆に不便。今迄通りにemacsからのgdbで良い。

tag jump

甲乙つけがたいけど、vimのそれのTAG補完が出来るのが、何気に嬉しいかな。それに、OpenBSDでは、デフォでctagsを採用してるからね。

help

ぐぐっても、プラグインどーたらが目立つ。それ以前を知りたいのよ。公式のマニュアルもいいけど、こちらがお勧めだ。ヘルプの起動／終了

vimにしろemacsにしろ、存分に使いこなすにはキーバインドが指にしみつくようになるべき、と思っていたら、Emacsのコマンドやキーバンドは別に覚えなくてもいいこういうのもあるのね。

vimだと、:help index が、相当するな。

dataset for AI

とあるサイトを見てたらAI道場用にサンプルデータの事典が掲載されてた。今週は、 Diabetes Dataset：糖尿病（年齢／血圧／血糖値などの10項目）の表形式データセットこんなデータだった。

猫も杓子もpythonって亊で、それ用の扱いが示されていたけど、Rでもいいんでないかい。提供元へ行って、データをみたら、タブ区切のASCIIデータだった。

これなら、どうにでもなるな。年齢、BMI、平均血圧、諸血清データ、血糖値、最後は一年後の糖尿病進行度とかみたい。

オイラーが理解出来るのは血圧ぐらいだな、ってんで見ていくと、やけに値が低いぞ。平均ってのが味噌っぽい。最高血圧と最低血圧を足して２で割ったものでもなさそう。

そうすると、血圧を積分して、それを時間で割ったものなのかなあ。

scikit-learnで糖尿病データの回帰分析をやってみた

scikit-learnの糖尿病のデータセットで機械学習【回帰】

線形回帰モデル：診察データから1年後の糖尿病の進行度を予測する【Python】

scikit-learn 糖尿病患者データセットを使った「重回帰分析」

【scikit-learn】ライブラリ付属のデータセットまとめ – 概要、使い方を解説

AIの理解に必須！基礎から学ぶ機械学習日経さんもやってた

This year's Index

Home