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

などとしています。

WSLにインストールしたUbuntuのディストロ名を変える。

WSL 1に Ubuntu-18.04 をインストールして中身を ArchLinux に入れ替えましたが、このままでは wsl -l -v したときに Ubuntu-18.04 と表示されます。でも中身は ArchLinux。ややこしい。

なので、中身に合わせてディストロ名を変更します。

そのまま変更することはできないようなので、ここは wsl の export / import を使います。

$ wsl --export Ubuntu-18.04 archlinux.tar

$ wsl --import ArchLinux C:\Users\chiyo\AppData\Local\Packages\ArchLinux archlinux.tar --version 1

$ wsl -l -v
  NAME                   STATE           VERSION
* Ubuntu-18.04           Stopped         1
  docker-desktop-data    Running         2
  docker-desktop         Running         2
  ArchLinux              Stopped         1

$ wsl --set-default ArchLinux

$ wsl -l -v
  NAME                   STATE           VERSION
* ArchLinux              Stopped         1
  docker-desktop-data    Running         2
  docker-desktop         Running         2
  Ubuntu-18.04           Stopped         1

$ wsl -d ArchLinux

これで一応できたみたいです。

bash で「要素が見つかりません」になる。

Win-R で bash とやったらウィンドウが一瞬開いてすぐに閉じてしまうので、コマンドプロンプトを開いて bash とやってみたら、「要素が見つかりません」というエラーが出てしまいました。

Ubuntu のアイコンから起動しても同様で、これは困ったとぐぐってみると、以下のような内容の記述を見つけました。 

KB4571756をインストールするとWSL 2で「要素が見つかりません」というエラーになります。「更新とセキュリティ」からKB4571756をアンインストールすると正常に戻ります。

 早速 KB4571756 をアンインストールしてみると、ちゃんと動くようになりました。何やらかしてくれちゃってんの…。

ついでにグループポリシーエディタで自動更新を無効にしておきました。

MSYS2がいらなくなると思ったのに…。

WSLにArchLinuxをインストールしてみる。で無事インストールできた ArchLinux ですが、base と base-devel しか入れてないのでエディタはないし zsh はないしであわてて pacman でインストールしたのはいいんですが……。

これで MSYS2 から開放されるな、と思って、削除する前にまず MSYS2 をインストールしたディレクトリ c:\Apps\MSYS2 の名前を変更してパスが通らないようにし、コマンドプロンプトから ls と入力してみると…動きません…。wsl.exe をかませて -e オプションで実行できるんですが、たかが ls コマンドでそれをやるのはアホらしいですし。

根本的になにか勘違いしていて、「相互にコマンドなどを利用できる」と思っていたのですがそうではなく、Linux 用コマンドなどはシェルなどから Linux カーネルを呼び出して実行されるわけなので、Linux カーネルが動いてない状態では動作するわけがないですね。

ということでかなり思惑が外れてしまいました。やっぱり MSYS2 からは開放されないのね。

WSLにArchLinuxをインストールしてみる。

apt よりも慣れ親しんだ pacman を使いたい!という理由で、ArchLinux を WSL にインストールしてみます。WSL 2 までのインストールが終わっているということを前提条件とします。方針としては Ubuntu をインストールしてから ArchLinux に置き換えるという方向です。

Docker on WSL2をやってみる。でちょっと触れたのですが、WSL に Ubuntu をインストールした上で Arch に切り替える、というような方法の中で触れられている lxrun が 2004 ではサポートされなくなっているようです。

ディストリビューションをダウンロードしてインストールする場合には、 Manually download Windows Subsystem for Linux distro packagesにコマンドラインでのインストール方法があるので、そこからダウンロードし、そのページと上記のページ、およびArchLinux Wikiの日本語版にあるWSL にインストールを読み合わせながら行います。

手を抜くためにここでは Store からインストールしてしまいますが、手動でやりたいときには以下のようにします。

まず、ディストリビューションの appx イメージをダウンロードします。ここではUbuntu 18.04 を選びます。20.04 では、/bin などがシンボリックリンクになっていて、後工程での置き換えがうまくいきません。

ダウンローが終わったら PowerShell を起動して、ダウンロードしたディレクトリで次のようにします。このとき、Docker Desktop が起動していると Docker 側にインストールされてしまうので、Docker Desktop は必ず終了しておきます。

Add-AppxPackage .\Ubuntu_1804.2019.522.0_x64.appx

インストールが終わったら bash を起動します。Win+R で bash と入力すると bash が起動するか、スタートメニューにある Ubuntu アイコンをクリックして起動します。

初回起動時には新規ユーザの作成を自動で求められますが、いきなりブレークして一旦シェルに抜けます。再度起動して正常にプロンプトが出るのを確認してから、すべての bash を終了しておきます。

PowerShell またはコマンドプロンプトを開き、wsl -l -v してディストリビューションとして "Ubuntu-18.04" が、バージョンは "2" であることを確認します。WSL 2までインストールされ、WSL のデフォルトバージョンが 2 に設定されているはずなのでこれは当然の動作ですが、ArchLinux に置き換えるためにこの VHDX イメージをプレーンに展開します。

wsl --set-version Ubuntu-18.04 1

すると VHDX からプレーンなディレクトリ構造に展開されます。

展開が終わったら再度 bash を起動して、ArchLinux の bootstrap イメージを https://mirrors.kernel.org/archlinux/iso/latest/あるいはhttps://www.archlinux.jp/download/にあるミラーサイトからダウンロードします。ここでは JAIST からダウンロードさせてもらいます。

wget http://ftp.jaist.ac.jp/pub/Linux/ArchLinux/iso/2020.09.01/archlinux-bootstrap-2020.09.01-x86_64.tar.gz

ダウンロードが終了したら、tar.gz をほどきます。

tar zxvf archlinux-bootstrap-2020.09.01-x86_64.tar.gz

するとこんな感じになっています。

uzi:~# ls -la
total 165680
drwx------    3 root     root          4096 Sep 13 04:48 .
drwxr-xr-x   20 root     root          4096 Sep 12 10:11 ..
-rw-------    1 root     root            11 Sep 13 04:31 .bash_history
-rw-r--r--    1 root     root     169638434 Sep 13 04:47 archlinux-bootstrap-2020.09.01-x86_64.tar.gz
drwxr-xr-x   16 root     root          4096 Sep 13 04:48 root.x86_64
uzi:~#

vi か nano を利用して root.x86_64/etc/pacman.d/mirrorlist のサーバ指定を変更します。ここでは WorldWide と Japan だけ行頭のコメントを外して保存しておきます。

##
## Arch Linux repository mirrorlist
## Generated on 2020-08-01
##

## Worldwide
Server = http://mirrors.evowise.com/archlinux/$repo/os/$arch
Server = http://mirror.rackspace.com/archlinux/$repo/os/$arch
Server = https://mirror.rackspace.com/archlinux/$repo/os/$arch

root.x86_64/etc/resolv.conf を適切に編集するか、自動生成させるようにします。自動生成させるようにするには、

echo "# This file was automatically generated by WSL. To stop automatic generation of this file, remove this line." > ~/root.x86_64/etc/resolv.conf
とするとよいようです。あるいは

nameserver 8.8.8.8
nameserver 8.8.4.4
みたいに決め打ちにしておきます。

ここで bash を(すべて)閉じます。一応ディストリビューションがきちんと停止しているかどうかを確認します。

wsl -l -v
  NAME            STATE           VERSION
* Ubuntu-18.04    Stopped         1

Running になっている場合には、数秒待ってから再度確認すれば Stopped になっていると思います。

次に Explorer を開いて、%localappdata%\PackagesをURIバーにペーストして移動します。そこにある CanonicalGroupLimited.Ubuntu18.04onWindows_* というフォルダを探してそこに移動します。

もう一枚 Explorer を開いて同じ場所に移動します。一枚ではLocalState\rootfsを開き、もう一枚では ArchLinux を展開したLocalState\rootfs\root\root.x86_64を開きます。

Ubuntu 側の bin、etc、lib、lib64、sbin、usr、var を削除し、ArchLinux側から同じディレクトリを移動します。コピーだとシンボリックリンクが壊れるため、コピーではなく必ず移動します。

移動が終わったら、ArchLinux をセットアップします。

# pacman-key --init
# pacman-key --populate archlinux
# pacman -Syyu base base-devel

ついでにいうと、vi や nano といったエディタは削除されてしまっているようなので、お好みのエディタをインストールしたほうがいいでしょう。

最後に root 以外のユーザを作成しておきます。

# useradd -m -G wheel -s /bin/bash chiyo
# passwd root
# passwd chiyo

ここで、bash あるいは Ubuntu アイコンから起動した場合のデフォルトユーザは root のままですが、wsl.exe の引数で指定することができます。適宜ショートカットかバッチファイルなどを作成しておくといいでしょう。

あるいは、コマンドプロンプトから

ubuntu1804 config --default-user chiyo

などとして設定することもできるようです。

WSL 1と2の違い。

今ひとつちゃんと理解していなかったのと、どちらを使えばいいかを決めるのに情報のまとめが必要だったのでメモ。でも勘違いとか正確に理解できてないとか間違ってるとかあるかもしれない。

機能的な比較はWSL 1とWSL 2の比較にまとまっているのでそこを参考にすると、WSL 2側から見た Pros / Cons は、
  • Pros
    • マネージドVM
    • 完全なLinuxカーネル
    • システムコールの完全な互換性
  • Cons
    • OSファイルシステム間でのパフォーマンス
ということのようです。

パフォーマンス的には、WSL 2 は 9P というプロトコル経由で Windows ファイルシステムにアクセスするためにとても遅いとのこと。つまり、Windows ファイルシステムにある大量のファイルを WSL 2 上の Linux に処理させようとするとめちゃくちゃ遅い、ということのようです。そのため、Linux 側のコンパイルツールで Windows 側のソースツリーをコンパイルするというようなシナリオはパフォーマンスが非常に悪いようです。また、うっかり /mnt/c 以下で作業するとファイルアクセスが極端に遅くなるので、Windowsファイルシステム上にある大量のテキストファイルを処理するような作業も向かないのでしょう。

一方、WSL 2 では Hyper-V を仮想マシンプラットフォームとして管理下に置くため、WSL 2 の Hyper-V API を使用するように設定した VirtualBox や Android Emulator を同時に動かすことができるとのことで、WSL 1 が Hyper-V を専有しているために別の仮想マシンを同時利用できなかったのに比べると大きな違いになっています。

また、WSL 2 が管理している Linux 側のファイルシステムへのアクセスは WSL 1 に比べて高速化しているそうで、Linux ファイルシステム上でのコンパイル作業などは高速になるようです。

WSL 2 ではシステムコールについても完全に互換だということなので、Linux バイナリを持ってくればそのまま動くというのも特徴になります。

じゃあどちらを使えばいいのかというとこれがまたややこしくて、
  • WSL 1 は Hyper-V を使ってハイパーバイザを独占するので、Hyper-V プラットフォームに対応していない仮想マシンは同居できないし、対応していてもパフォーマンスが悪かったりする。
  • Docker に関しては、WSL 1 の場合には WSL 上に Linux 版の Docker をインストールして使用することでこの問題は回避できるらしい。
  • WSL 1 と WSL 2 は同居でき、仮想マシンがどちらを使うかを個別に指定できる。たとえば Ubuntu は WSL 1 上で動かし、Docker Desktop for Windows のバックエンドには WSL 2 を使うということができる(らしい)。wsl -l -v などとすると、パッケージがどちらの WSL で動いているかも表示される。また、wsl --set-version <ディストリビューション> <バージョン> などとしてどちらのバージョンで動作するかを指定できる。
ということなので、Ubuntu は WSL 1で、Docker は WSL 2 で、などというのがいいのかもしれません。 ちなみに、WSL 2 までインストールした状態で Docker Desktop for Windows をインストールし、そこに Linux ディストリビューションをインストールするとなぜか Docker の環境で実行されてしまうようでした。なのでインストール順にも注意したほうがいいみたいです。

Docker on WSL2をやってみる。

Windows 10 1909で印刷ができなくなった件。で、Windows 10 2004にしてみたのにはもうふたつ理由があって、WSL2 で MSYS2 からおさらばしたいな、というのと、Docker やってみたいな、というのです。

最終的には自分用サーバの Manjaro Linux にしてみたいのですが、とりあえず軽量で見通しのいいシステムとしたいので Arch Linux を候補にあげておきます。が、Microsoft Store には Arch Linux はないため、それも現状ではペンディングです。

ぐぐってみると、WSL に Ubuntu をインストールした上で Arch に切り替える、というような方法があるようです。また GitHub には ArchWSLArchWSL2 というふたつのプロジェクトがあがっています。WSL2 のほうは ALPHA ですが、とりあえず今は先に進みます。
ちなみに、ArchWiki で WSL を検索すると、ArchWiki は Arch しか対象にしてないので他のシステムことは書いてないよ、的なページに飛ばされます。

それはさておき。

まず Windows 10 で WSL2 を有効にします。
Windows 10 ⽤ Windows Subsystem for Linux のインストール ガイドに従い、
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
して
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
してから再起動。

コントロールパネルの「アプリと機能」→「オプション機能」→「Windowsのその他の機能」を開き、「Linux用Windowsサブシステム」と「仮想マシンプラットフォーム」にチェックを入れて WSL をインストールし、再起動します。

WSL 2 Linux カーネルの更新から「最新のWSL2 Linuxカーネル更新プログラムパッケージをダウンロード」してインストールします。

管理者モードでPowerShell を開き、
wsl --set-default-version 2
して WSL2 のインストールは終了です。ここでは Linux ディストリビューションはインストールしません。

次に Docker のサイトから Docker Desktop for Windows をダウンロードしてインストールすると、どうもそのままで WSL2 を勝手に利用してくれるようです。

Docker のインストールが終わって起動したら、
docker run hello-world
するとなんか出力してくれます。ちゃんと動いていれば "Hello from Docker!" というメッセージが表示されます。

ということで、Linuxディストリビューションをインストールしなくても Docker は動くよ、というだけのお話。

Windows 10 1909で印刷ができなくなった件。

メインPCを Core-i7 4790K から Core-i9 9900K に変更して見たところ、印刷ができなくなりました。
使用しているプリンタは Canon PIXUS MG7730です。

これまで、Insider Previewで使っていた4790Kでは正常に印刷できていたんですが、HDDの不良クラスタのせいなのかディスクの読み書きが異常に遅くなり、ついでだからとこれまでサブで使用していた 9900K をメインに仕立て直してみたところ、印刷ができないことに気づきました。
「プリンターとスキャナー」からプリンタを削除したり、セーフモードでドライバを削除したり、Regedit で Canon と入っているキーを虱潰しに削除したりといろいろやったんですがダメで、ググったところにあった 1909 で印刷ができなくなる不具合という記述を見つけました。

状況を整理すると以下のとおりです。
  • 9900K では 1909 を使っている
  • 印刷できる 4790K では 20H1 を使っていた
  • PDF での印刷はできる
  • Spool サービスは動いている
  • ドライバを再インストールしてもダメ
  • スキャナは使える
  • プリンタのステータスは PC で表示できるので、通信はできている
  • USB 接続でも LAN 接続でもダメ
もしかしたらこれは 2004 にアップデートしたら直るかもしれないと最後の望みをかけて、Windows 10の Update Assistant をダウンロードして手動アップデートしてみました。

光回線なのにダウンロードはとろとろと進み数時間かけてダウンロードが終了。アップデートしてみたらちゃんと印刷できるようになっていました。

原因究明のために無駄な時間を使ってしまいましたが、めでたしめでたし。

接着剤の使い方。

最近DIYで接着剤を使うことが多いので、使い方をまとめてみました。 コニシよりはセメダインのほうが情報量が多いので、セメダインをメインにまとめています。が、参照する情報元によっては記述が違っていることもあるので、正確には使用法説明を見たほうがいいでしょう。
木工用 ゴム用 多用途 エポキシ系
商品名 セメダイン木工用 タイトボンド
Ultimate
エクセルシグマ スーパーX スーパーX2
接着強度 4000psi
耐水性 なし あり あり(水没は不可) あり(水没は不可) あり
作業温度 8℃以上 -40℃~120℃
接着作業 片面に塗布 両面に薄く
均一に塗布
片面、または両面に
薄く均一に塗布
2液混合後、片面に
均一に塗布
作業時間 すぐに貼り合わせ 8~10分以内 15~30秒放置後に
圧着
5~10分放置後に
圧着
クランプ時間 3時間 30分 3時間 1時間
(初期硬化10分)
1時間
(初期硬化5分)
完全硬化時間 24時間 24時間 24時間

PaSoRiでe-Taxしてみる。

実は去年もやったのだけれど、PCの環境をクリーンインストールしてしまったので改めて備忘録。

PaSoRi(RC-S380)を使用してWindows PCからe-Taxするための準備と手順をまとめておきます。

  1. PaSoRiを接続する前に、NFCポートソフトウェアをインストールする。
    現在のバージョンは2019年6月17日のVer.5.6.9.0です。
    NFCポートソフトウェアのインストールガイドによれば、NFCポートドライバ、FeliCa Secure Client Ver.2.0、NECポート自己診断、NFC Proxy Serviceの4つのソフトウェアがインストールされます。
    インストールが終わったら、PaSoRiをPCに接続して正常に認識されていることを確認します。
  2. e-Taxを利用するために、PC/SC アクティベーター for Type Bをインストールする。
    現在のバージョンは2017年12月25日のVer.1.3.0.2です。
    PC/SC アクティベーター for Type Bのインストールガイドに従ってインストールします。

e-Tax(WEB版)はChromeやFirefoxなどは対応しておらず、Internet ExplorerもしくはEdgeのみから利用できます。ここではEdgeを使用して進めます。
  1. e-Taxソフト(WEB版)又は受付システムを利用するに当たって
    のページをEdgeで開きます。
  2. 手順1と2を確認したあとで、手順3の「電子証明書の取得」を行います。電子証明書の取得は、マイナンバーカードを使用する場合には公的個人認証サービスから電子証明書を取得します。
  3. マイナンバーカードをすでに持っているものとして先に進みます。マイナンバーカードは居住地の市区町村で交付されるため、引っ越しした場合には作り直す必要があります。
  4. STEP4の利用者クライアントソフトのダウンロードに進み、Windows版ソフトのダウンロードとインストールを行います。JPKIAppli03-03.exeというファイルがダウンロードされるので、これをインストールします。
  5. 利用者クライアントソフトの利用方法(Windowsをご利用の方)で使い方を確認します。まず、インストールされたJPKI利用者ソフトを起動します。
  6. 上記の画面から「自分の証明書」のボタンを押します。すると次のダイアログが表示されます。
    「署名用電子証明書」を押すとパスワードを求められるので、これを入力します。また、「利用者証明用電子証明書」を押すとこちらもパスワードを求められます。パスワードはそれぞれ異なるため、電子証明書の申請時のものをしっかり管理しておきます。電子証明書自体は地方公共団体情報システム機構より発行されますが、その手続きは市区町村窓口にて行いますので、予め申請して取得しておく必要があります。
  7. ここまでやったら、e-Taxのサイトから「e-Taxをご利用になる場合の流れ」の「5 各種ソフト等のインストール及び設定 申告書・申請書の作成・送信」のところから「確定申告書等作成コーナー」をクリックします。
  8. すると、国税庁 確定申告書等作成コーナーに飛びますので、「作成開始」をクリックします。
  9. 別のEdgeウィンドウがポップアップするので、「e-Taxで提出 マイナンバーカード方式」をクリックします。すると、「e-Taxのご利用のための事前準備を行います」というページに飛び、e-Tax Edge用APが必要なのでインストールしてくださいとの画面が出ます。このソフトはEdgeの機能拡張としてMicrosoft Storeからインストールされます。これをインストールし、ダイアログが出てくるので「有効にする」をクリックします。
  10. e-Tax Edge用APをインストールすると最初のページに戻るので、再度「確定申告書等作成コーナー」をクリックし、続いて「作成開始」をクリックします。別ウィンドウがポップアップするので、「e-Taxで提出 マイナンバーカード方式」を再度クリックします。すると「e-Taxのご利用のための事前準備を行います」というメッセージが出てくるので、その下の「事前準備セットアップファイルのダウンロード」をクリックします。
  11. またまた別ウィンドウが開き、「令和元年分事前準備セットアップ」をクリックすると、jizen_setup.exeをダウンロードして実行するように促されます。インストールが終わったら再々度「e-Taxで提出 マイナンバーカード方式」に進みます。右下に「利用規約に同意して次に」のボタンが出るのでクリックします。
  12. 「マイナンバーカード認証」のページに飛びますので、PaSoRiにマイナンバーカードを載せてから「マイナンバーカードの読み取り」ボタンを押します。すると「利用者証明用パスワード」の入力を求められるので、入力します。
  13. OKボタンを押して次に進むと登録されている情報が表示されるので、間違いないことを確認して次に進みます。「令和元年分の申告書等の作成」を選んで「所得税」の確定申告書を作成していきます。

あっちに行ったりこっちに行ったり大変ですが、こんな感じでようやく確定申告書の作成を開始できるようになりました。

SVT-AV1を使ってみる。

昨年Core-i9 9900Kでシステムをひとつ組んで、Windows10 Proでエンコードなどの処理をメインで行うようにしました。Quick Sync VideoによるハードウェアアクセラレーションでH.264のエンコード速度が非常に早くなり、フィルタのかけ方によっては150fpsを超えるような速度でエンコードできるようになりました。

それはさておき、最近ではSVT-AV1(Scalable Video Technology - AOMedia Video 1)というのが話題になっていたりして、rigaya氏のサイトでもguiExを提供されているので、ちょっと手を出してみました。AOMediaというのはAlliance for Open Mediaの略称のようで、MPEG LAによるライセンスを回避してロイヤリティフリーの技術とすることを目的に設立されているようです。

AviUtlにsvtAV1guiEx 0.00 beta2を組み込むところは省きます。そして "-enc-mode 3" で短いソースをエンコードしてみると、9900Kでもエンコード速度は4fpsとすごい値になってしまいました。実時間の約7.5倍です。さすがに結構辛いものがありますが、それはともかく、ビデオエンコード後の音声マルチプレクスを行うMP4BOXで問題が発生。バージョンが古くてAV1フォーマットに対応していないため、MUXできないようです。

ということで検索すると、最新のMP4BOXはGPAC 0.8.0のようです。バイナリはhttps://gpac.wp.imt.fr/downloads/で提供されているので、ここからWindows 64 bitsをダウンロードします。EXE形式のインストーラファイルですが、7zで展開するとファイルが取り出せますので、ここからmp4box.exe、js.dll、libcryptoMD.dll、libsslMD.dllをパスの通った場所(というかmp4boxと同じ場所)にコピーします。

これで mp4box -add [ソース1] -add [ソース2] -new [出力mp4] などとすればMP4コンテナに出力できます。

Vimの補完プラグインをインストール。その4

Vimの補完プラグインをインストール。その3 で、 ddc-tabnine が使えそうです、などと書いたのですが、早速やってみました。 まず、tabnineのバイナリを用意しないといけません。がどうにもTabNineのサイトがわかりにくいので、 tabnine-nvim にあるダ...