pipじゃなくてpacmanを使う。

ArchLinux系ではパッケージマネージャのpacmanを使いますが、Pythonの外部モジュールをインストールするときにはpipを使うのかpacmanを使うのか、どっちがいいのか、という質問がいろいろなフォーラムでたびたび出てきます。 

回答はいつも明確で、システムワイドで使うならpacmanを使え、pipを使うなら'--user' オプションを必ず指定しろ、venvなどの仮想環境で使うならpipを使え、です。

ところがそういう方針でやっていても、ついうっかりpip使っちゃったりすることもあります。  ということで、あるモジュールをインストールしたのがpipなのかpacmanなのかを表示するための1ライナーです。

$ for i in `pip list | tail -n +3 | awk '{print $1}'`; do pacman -Qs $i ; done
local/python-appdirs 1.4.4-3
    A small Python module for determining appropriate platform-specific dirs, e.g. a "user data dir".
local/python-black 21.6b0-3
    Uncompromising Python code formatter
local/python-cachecontrol 0.12.6-3
    httplib2 caching for requests

出力で先頭に'local'が付いてるのは、pacmanでローカルにインストールされてますよ、ということです。 めでたしめでたし。

Neovim+vimtex+TeXLive 2021+SumatraPDFでTeX環境を作ってみる。

NeovimでのPythonの環境をLSPに変更したので、vimtexが使っている補完ソースもLSPにしてみます。

TeX用Language Serverのセットアップ

LSはtexlab/Relaseからバイナリをダウンロードします。
実行形式ファイルが1つだけなので、インストールはこのtexlab.exec:/Apps/languageServerにコピーするだけです。

次にdein.tomlのnvim-lspconfigのところにLSに関する設定を追加します。
[[plugins]]
# A collection of common configurations for Neovim's built-in language server client.
repo = 'neovim/nvim-lspconfig'
hook_add = '''
set runtimepath+=~/.cache/dein/repos/github.com/neovim/nvim-lspconfig/lua
lua << EOF
local nvim_lsp = require('lspconfig')

nvim_lsp.pyls_ms.setup{
    cmd = { "dotnet", "exec", "c:/Apps/languageServer/Microsoft.Python.LanguageServer.dll" },
	init_options = {
	  analysisUpdates = true,
	  asyncStartup = true,
	}
}
nvim_lsp.texlab.setup{
    cmd = { "c:/Apps/languageServer/texlab.exe" },
}
EOF
'''
一応これだけでLSPを利用した補完はできるようになります。 ただし、ALEを使っている場合にはALEとLSPで二重にチェックされたりするらしいので、問題がある場合にはその部分で変更が必要です。ALEの設定部分で let g:ale_disable_lsp = 1と設定するといいらしいです。

vimtexとSumatraPDFの連携

vimtexでコンパイルまでできるんだから、逆順検索もちゃんとできるようにします。

まず、逆順検索(inverse search)はRPCを使ってNeovimとSumatraPDFがやりとりします。具体的には、SumatraPDF側でクリックされた行情報をRPCでNeovimに送ります。Neovim側はRPCで受け取ったコマンドを実行して、PDFでのクリックされた行のソースにジャンプします。

ということでNeovimを外部から、コントロールするためのneovim-remoteが必要になります。
$ pip install neovim-remote
するとnvrというコマンドが利用できるようになります。

nvrでは予めサーバの場所を指定しておく必要があります。NeovimのRPCの場合には、\\.\pipe\nvim-1234-0というようにパイプが作成されるので、それを利用する必要がありますが、パイプ名は毎回異なります。
一方、SumatraPDFでは逆順検索コマンドで利用するためにサーバの場所を知りたいのですが、そのためにはNeovimと通信できないとわかりません。毎回手動で設定するのも大変ですし、現実的ではありません。

そこで、起動時にNeovimが作成するRPCサーバとは別に、SumatraPDF専用のRPCサーバを起動してそこと通信させればうまくいきます。

Neovim側で
if has('win32')
	call serverstart('\\.\pipe\nvim-vimtex-1234')
endif

let g:vimtex_view_general_options
			\ = '-reuse-instance'
			\ . ' -forward-search @tex @line @pdf'
			\ . ' -inverse-search "nvr --servername ' . '\\.\nvim-vimtex-1234'
			\ . ' --remote-send \"\%lG\""'
などとvimtexの設定時にRPCサーバを起動し、このパイプ名をSumatraPDFの逆順検索コマンドに指定してやればよいのです。
nvr --servername \\.\pipe\nvim-vimtex-1234 --remote-send "%lG"
これでPDFで行をクリックするとNeovim側で対応する行にジャンプします。 ・・・でも順方向がちゃんと動かない・・・。

deopleteのソースをJediからLSPに変更する。

ついでにvimtexまわりの変更も行います。

JediからLanguage Serverへ

約2年前にNeovim+vimtex+TeXLive2018でTeX環境を作ってみる。というエントリを書いたのですが、ここへきて Neovim の 0.5.0 がぼちぼち(予定では6月15日)にリリースされるということで、Nightly ビルドを持ってきて使っています。

もともとは Python プログラミングの補完などのためにdeoplete-jediを使っていましたが、jediよりも速いという話もあってLSPを利用した入力サポートへの変更を行いました。

Python用のLanguage Server(LS)はいくつかありますが、VS Codeと併用するならばVS Codeで使用されている Pylance のベースとなっているMicrosoft Python Language Serverが、一番違和感なく使えるのではないかということでこれを候補にしました。
他にもpalantir/python-language-serverhttps://github.com/python-lsp/python-lsp-serverにありますが、こちらはエンジン?にJediを利用するということで、deoplete-jediで使っているのと変わらないためにパスしています。また、NeovimをVS Codeのような感じにするというCoC(Conquer of Completion)というフレームワークがあり、そのプラグインで使うという方法も調べてみましたが、こちらはNode.jsで動くということで、Node.jsを使う予定はないのでこれもパスしました。

結果、構成としては以下のようになります。
  • Neovim + deoplete を利用する
  • deoplete からLSを利用するため、deoplete-lsp プラグインを利用する
  • LSPとしてはMicrosoft Python Language Server(pyls_ms)を使用する
  • pyls_msの設定を簡単に行うため、nvim-lspconfigを使用する

pyls_msをビルドする

Microsoft Python Language ServerはC#で記述されているので、.NETのビルド環境が必要です。うちではVisual Studio 2019がインストールされているので、コマンドプロンプトから以下のコマンドを叩けばビルドできます。
$ git clone https://github.com/Microsoft/python-language-server.git
$ cd python-language-server/src/LanguageServer/Impl
$ dotnet build -c Release
ビルドが正常に終了したらpython-language-server/output/binディレクトリにある全ファイルをc:/Apps/languageServerディレクトリにコピーします。

deoplete-lspを導入する

dein.tomlを編集し、deoplete-jediを削除したあとで以下の記述を追加します。
[[plugins]]
# LSP Completion source for deoplete
repo = 'deoplete-plugins/deoplete-lsp'
hook_add = '''
let g:deoplete#lsp#handler_enabled=1
let g:deoplete#lsp#use_icons_for_candidates=0

'''

nvim-lspconfigを導入する

続けて以下の記述を同じくdein.tomlに追加します。
[[plugins]]
# A collection of common configurations for Neovim's built-in language server client.
repo = 'neovim/nvim-lspconfig'
hook_add = '''
set runtimepath+=~/.cache/dein/repos/github.com/neovim/nvim-lspconfig/lua
lua << EOF
local nvim_lsp = require('lspconfig')

nvim_lsp.pyls_ms.setup{
    cmd = { "dotnet", "exec", "c:/Apps/languageServer/Microsoft.Python.LanguageServer.dll" },
	init_options = {
	  analysisUpdates = true,
	  asyncStartup = true,
	}
}
EOF
'''
一応このとき、dein_lazy.tomlでのdeopleteの設定は以下のようになります。
[[plugins]]
# Dark powered asynchronous completion framework for Neovim / Vim8
# require: python3
repo = 'Shougo/deoplete.nvim'
depends = 'context_filetype.vim'
on_i = 1
hook_post_source = '''
  call deoplete#enable()
  source $XDG_CONFIG_HOME/nvim/rc/deoplete.rc.vim
'''

起動する

設定が終わったらインストールとキャッシュの作り直しをしておきます。
:UpdateRemotePlugins
:call dein#update()
:call dein#recache_runtimepath()
Neovimを再起動してPythonファイルを編集し、補完候補の右側に[LSP]と出てくればちゃんと動いています。

Python 3.9でファイルをオープンしているかどうかを確認する。

ファイルがオープンされているかどうかを確認してから処理を行う Python スクリプトがあるのですが、どうも Windows 10 20H2 (ビルド19042.685)のあたりから API が変わったのかうまく識別できないようになりました。
これまで判定していたのは以下のようなコードで、Google で検索してもこれがあがってきます。
try:
    open(filename, "a+")
Except IOError:
    print("cannot open ", filename)
実際には処理したいファイルをワイルドカードでリストを用いて、
for f in files:
    try:
        open(f, "a+")
    Except IOError:
        print("cannot open ", f)
のような形で使用しますが、オープンされているファイルが上手く処理されなくなりました。

それだと困ったことになるので、その識別部分を以下のように変えて対応しました。

from os import rename

open_check = 'unique filename'
for f in files:
    try:
        rename(f, open_check)
        rename(open_check, f)
    Except OSError:
        print("cannot open ", f)
こちらのほうだときちんと識別してくれるようになりました。

変数 open_check のユニークなファイル名として mkstemp() を使うと、リストの読み込みがなぜか一つおきになってしまいうまくいかなかったので、固定にしてみました。もしかしたら mkstemp() が返すのはフルパス名なので、 os.path.basename() でファイル名部分だけを切り出して使えばいいのかもしれませんが、一応用は足りたのでこれでいくことにします。

録画したD-VHSテープからWindows 10環境で吸い出してみる。

注意: 現在進行中なので、結論はまだありません。

過去にD-VHSを使っていて、今でも機械だけはあるんですが HDMI ではなく D4 出力のため、AV システムとして組み込むには中途半端な状態。Bluray レコーダーも AV アンプも液晶テレビもすべて HDMI 繋がりになっていますし。

一応、手持ちの AVアンプ YAMAHA RX-V773 には D4 入力端子もあるんですが、マニュアルによれば D4 VIDEO 端子にビデオ機器を接続した場合、ビデオ機器の映像出力が 480i 以外だとアンプの MONITOR OUT (COMPONENT VIDEO)端子からのみ映像が出力されるとのことで、アナログ信号で D4 端子に入力された映像を HDMI 出力することはできないようです。

液晶テレビとして東芝 REGZA 37ZP3 を使っているんですが、こちらは D5 入力端子を持っています。D5 端子は D1 から D4 までの規格の映像信号を受け取れるはずなので、こちらに接続すれば見られないことはないはずで、その場合は光デジタル出力を D-VHS テープデッキから AV アンプに接続して音声を再生する、というスタイルになります。

ただ、テープデッキも故障対応期間はとっくに終わっていますし、データを PC に取り込んで、PC から再生したほうがいろいろと便利なので、D-VHS テープデッキである日立 DT-DRX100 の iLink 端子から PC でデータを吸い出してエンコードしてしまえば楽だな、と思った次第。

ところが最近の PC には i.LINK (IEEE1394)のインタフェースがありません。しかも手持ちの IEEE1394 カードは PCI 接続のもので、PCI Express しかない今の PC では使えません。

そこで玄人志向の「IEEE1394-PCIE2 [TI XIO2200搭載 IEEE1394a(OHCI)x2 ロープロファイル対応 インターフェースボード]」というのを購入してみました。このカードを買ったのは、D-VHS との接続と同時に、フィルムスキャナ Nikon Coolscan LS-4000ED を接続して過去のネガフィルムを整理する、という目的もあるので、D-VHS に関してはダメ元的な考えでした。

一応、取り込みソフトとしてはフリーの CapDVHS というのを見つけたので、それを使ってみようかと思っています。

ちなみにフィルムスキャナのほうは、接続した段階ではドライバソフトがない、といっていきなりブルースクリーンになったりしたのですが、VueScan というアプリがドライバまで含めてサポートしているということで、 Professional Edition を購入しました。複合機の Canon MG-7730 プリンタを使っているのですが、そちらからのスキャンもできます。

ところがこの IEEE1394-PCIE2 は XIO2200 というチップを使っていて、こちらが PCIe  1.0a までの対応で、PCIe 1.1 以降には対応していない、というような記事を見かけました。実際に、 Texas Instuments の XIO2200 EVM Guide には、

The card will fit into any standard x1, x2, x4, x8, or x16 add-in connector that is compliant to the PCI Express Card Electromechanical Specification revision 1.0a.

とあります。1.0a は 1.1 の先行規格だということで、基本的に同じものという認識なのですが、玄人志向ではこれとは別に、XIO2213B (PCIe 1.1)のカードも販売していて、こちらのほうは IEEE 1394b に対応している、とのこと。Wikipediaによれば、通信速度は 800 Mbps になり端子形状も異なるということで、テープデッキもフィルムスキャナも古く、当時は 400Mbps といっていたので 1394a に対応してばいいと思いますが、XIO2200(PCIe 1.0a & IEEE1394a)のカードではフィルムスキャナの電源を切ると PC がブルースクリーンになるという不具合もあるため、XIO2213B(PCIe 1.1 & IEEE1394b)もヨドバシのポイントで用意してみました。

ただし、このブルースクリーンの原因もよくわからず、「irql not less or equal (1394ohci.sys)」と表示されるエラーで、ドライバの割り込み要求レベルが異なるというエラーですが、Microsoft の Answer を読んでもよくわかりません。それとは別に、1394 OHCI ホストドライバを "Generic 1394 OHCI compliant host controller (Legacy)" に変更すれば、Windows 10 でも古い 1394 デバイスを利用できるようになるというページもあり、そこのリンクから 64ビット版の 1394_OHCI_LegacyDriver.msi をダウンロードしてインストールすると使えるようになる、という記述もあります。

さすがにメイン PC でやるのは怖いので、検証機を仕立ててやってみようと思います。

うまく動くようなら、ビデオの取り込みを CapDVHS あるいは HDVSplit にてやってみようと思います。

latexmkrcの解説を和訳しておく。

以前に設定して使っていた latexmk がうまく動作しなくなってきていたので latexmkrc とかを見直しながら調査中。つきましては latexmk のドキュメントから "CONFIGURATION/INITIALIZATION (RC) FILES" の肝の部分を和訳しておきます。
---以下和訳
Latexmkは、起動時に以下の順番で読み込まれる初期化ファイルを使ってカスタマイズできます。

  1. システムのRCファイル(もしあれば)
    UNIXシステムでは、latexmkはシステムRCファイルを探すために、以下の場所を以下の順番で探し、最初に見つけたものを読み込みます。
    "/opt/local/share/latexmk/LatexMk",
    "/usr/local/share/latexmk/LatexMk",
    "/usr/local/lib/latexmk/LatexMk"
    MS-Windowsシステムでは、"C:\latexmk\LatexMk"を探します。
    cygwinシステムでは、
    "/cygdrive/c/latexmk/LatexMk",
    "/opt/local/share/latexmk/LatexMk",
    "/usr/local/share/latexmk/LatexMk",
    "/usr/local/lib/latexmk/LatexMk"
    のうち、最初に見つけたものを読み込みます。
    加えて、それでも見つからない場合には"LatexMk"のファイル名を"latexmkrc"に置き換えて同じ場所を探します。
    もし環境変数 LATEXMKRCSYS が設定されていれば、上記の代わりにその値がシステムRCファイル名として使用されます。
  2. ユーザのRCファイル(もしあれば)
    これは2ヶ所のうちのひとつになります。1つは伝統的なものでユーザのホームディレクトリにある ".latexmkrc" です。もうひとつは XDGコンフィギュレーションホームディレクトリにある "latexmk/latexmkrc" です。実際に読み込まれるのは "$XDG_CONFIG_HOME/latexmk/latexmkrc" または "$HOME/.latexmkrc" のうちの最初の方です。
    ここで $HOME はユーザのホームディレクトリです。
    $XDG_CONFIG_HOME は環境変数 XDG_CONFIG_HOMEが設定されている場合にはその値になります。もし環境変数が設定されておらず、$HOME が空でなければ、$XDG_CONFIG_HOME はデフォルト値の $HOME/.config に設定されます。$XDG_CONFIG_HOME が空の場合には、latexmk はそこには RCファイルを探しには行きません。
  3. 現在のワーキングディレクトリのRCファイル
    ファイル名は "latexmkrc" または ".latexmkrc" で、もしあれば最初に見つかったほうが使用されます。
  4. コマンドラインの -r オプションで指定されたRCファイル
RCファイルは Perl コマンドの連なりです。当然ながらユーザはこれを如何様にも利用できます。が、ほとんどの目的は Latexmk に組み込まれた設定を上書きするための代入文の連なりで使用されます。直接的なケースはPerl言語の知識がなくてもこのドキュメントの例をテンプレートとして使うことができます。#のついた行はコメント行です。

(どどーんと省略)
$pdf_mode [0]
ゼロの場合、pdf版の文書を生成しません。1の場合、pdf版の文書をpdflatexを使い、$pdflatex 変数に指定されたコマンドを使って生成します。2の場合、pdf版の文書を$ps2pdf変数で指定されたコマンドを使ってpsファイルから生成します。3の場合、$dvipdf変数で指定されたコマンドを使ってdviファイルから生成します。4の場合、pdf版の文書をlualatexを使い、$lualatex変数で指定されたコマンドを使って生成します。5の場合、pdf版の文書をxelatexを使い、$xelatexとxdvipdfmx変数で指定されたコマンドを使って生成します。
---以上

ArchLinuxのbaseパッケージでインストールされるもの。

https://www.archlinux.org/packages/core/any/base/によれば、base には bash、bzip2、findutils、gawk、grep、pacman、sed、systemd、tarなどでエディタは入っていないようです。

また、https://www.archlinux.org/groups/x86_64/base-devel/によれば、base-devel には autoconf、automake、binutils、bison、gcc、gettext、m4、patch、sudoなどが入っています。

Python や Perl などは入っていないようですね。

一方、ArchLinux の bootstrap に含まれているパッケージは /var/lib/pacman/localに情報があり、bash、curl、glibc、ncurses、pacman、pam、pcre、perl、sqliteなどがあるようです。やっぱりエディタはないようなので、自分の好きなものをインストールしないとダメみたいです。

その他にインストールしたほうがいいパッケージは、

  • mlocate - locate を利用する場合。sudo updatedb が必要。
  • man - man page を利用する場合。パッケージ名は man-db となっている。
  • python - Python3 を利用する場合。
  • zsh - bash から乗り換え。
  • the_silver_searcher - grep の置き換え。

あたりでしょうか。ここらへんは個人の嗜好になりますが。

それから zsh での設定ファイルの読み込み順はホームディレクトリのドットファイルを整理する。にまとめていますが、$ZDOTDIR をどこかで設定しておく必要があり、うちの場合には /etc/zsh/zshenv

XDG_CONFIG_HOME=$HOME/.config
export ZDOTDIR=$XDG_CONFIG_HOME/.config/zsh

などとしています。

SWDなら3線でいいとはいうものの。

 安価で優秀なデバッグプローブはないかしら、と探したら、 Raspberry Pi Debug Probe というのがあったんですが、これは3線がにゅるんと出てるだけです。 もちろんSWDなら3線を繋げばいいのではありますが、汎用的に考えるなら5x2のリボンケーブルコネクタが欲し...