風車の速度。

知人と話をしていて、ちょっと風が強いね、あの風車ものすごい勢いで回ってるね、という話から、江東区若洲あたりの風力発電設備のタービンの話になりました。

若洲風車の施設案内によれば、風車はドイツのノルバデックス社製で、モータの高さは地上 60m、タービンブレードの長さは 40m とのこと。

以前に若洲に行ったときに実測したところ、風速 10m 程度で 1 分間に 17 回転。17rpm です。

すると円周は\(40\times 2\times\pi=251\)m。これが17rpmなので、時速になおすと\(251\times 17\times 60\div 1000=256.35\)km/h。地上20m の位置を、ブレードの先端が 250km/h のスピードで通り過ぎるわけです。

記憶によればこのときはそれほど強い風が吹いているというわけでもなかったので、もうちょっと強い風が吹くと簡単に 300km/h 以上になりそうです。

ちなみに風速 25m/s で回転は停止するそうですが、そのときには 30rpm くらい（2秒で1回転）くらいはしてるんでしょうか。計算すると先端速度は 450km/h を超えます。

至近距離でそれだけの速度のものを見ることができるのはここかもしれません。

VirtualBoxの不具合。

Linuxの現物PCではある程度確認の取れた設定を行いたいので、別途VirtualBoxでサンドボックスを作ってそちらで動作確認や設定のテストなどを行っているのですが、どうもVirtualBoxの拡張パックが5.2.22ではちゃんと動くのに5.2.24以降では動作がおかしくなる不具合があるようです。特定の環境のみで出るのか、それとも一般的なものなのかはわかりませんが、VirtualBox 6.0 guest additions problemで Manjaro での不具合が報告されています。

But the shutdown and startup take much longer time (close to 1 minute) with a message like “A start job is running vboxadd.services” or “A stop job is running vboxadd.services”. I checked under /var/log there seems to be a vboxadd_setup.log on every startup, which perhaps means that the guest additions module is rebuilt on every startup?

The system runs well on VBox 5.22 and earlier.

内容としては、起動時及び終了時に vboxadd.service が異常に時間がかかる、というものです。自分のところでも数分近くかかっていました。
どうもいろいろぐぐってみると、VBoxAddtionsあたりはけっこうトラブルが多いようですね。

VirtualBoxの最新バージョンは5月14日の6.0.8なのですが、そちらでもおかしいから5.2.22に戻しています。ただ、毎回起動するたびに「新しいバージョンがあります」メッセージが出るのが鬱陶しいですね。

\(\rm\LaTeX\)のテーブル環境。

いくつかの項目をわかりやすく並べて比較できるようにするのに、表形式は便利です。

\(\rm\LaTeX\)ではいくつかのテーブル環境が用意されています。CTANでざっと検索しただけでも、lxtable、stabular、ltablex、tabu、supertabular、longtable、tabularxなどがあります。

昔使っていたときには、次のページに続くような長い表になったり、表のレイアウト位置を指定したりするのに supertabular 環境を利用していたのですが、現在は longtable 環境に引き継がれているようです。tabularx はカラム幅を指定したり自動的に拡張できる X オプションを持ったもので、lxtable や ltablex は tabluarx と longtable の機能を組み合わせたものです。

この中でどれか一つを選ぶとしたら、tabu を選べばよいでしょう。tabu は単一ページのテーブル環境の tabu と、マルチページテーブルの longtabu の2つの環境を持ち、色分けや表の入れ子などにも対応できます。tabu は array や xcolor、longtable などを外部参照することで機能を実現しているので、それらは別途明示的に usepackage する必要がありますが、大抵のことはできそうです。

tabu 環境についてはちょっと検索してみてもあまり解説しているページが引っかかりません。ドキュメントは \texlive\2019\texmf-dist\doc\latex\tabuにPDFがあるので、これを参考にすればいいでしょう。

Windows 10 1903の初期不具合。

Windows 10 バージョン1903がリリース。の続報ですが、窓の杜から、「Windows 10 May 2019 Update」には既知の不具合が12件 ～手動更新には十分注意だそうです。

上記ページに不具合のざっくりした説明もありますが、いまのところうちでは無関係かな、という内容です。
ただ、リリース後2日でこれだけ出たのと、うちにはまだ配信されていませんがこれから範囲が広がってくるともっとボロボロと出てきそうですし、バグ曲線（信頼度成長曲線）的に収束するにはひと月くらいは様子見したほうがいいのかな、という感覚です。急がないのであれば7月から8月までは待ったほうがいいかもしれません。

Windows 10 バージョン1903がリリース。

Windows 10 のアップデート May 2019 がリリース開始されたようです。「Windows 10 May 2019 Update」（ビルド1903）一般提供開始に詳細が出ています。記事中では 1903 ではなく 1809 となっている部分がありますが、どうやら 1903 で間違いないようです。
が、あながち間違いというわけでもないようで、「Windows 10 May 2019 Update」が一般公開 ～順次展開へによれば、Windows Update で 「April 2018 Update（バージョン 1803）」と「October 2018 Update（バージョン 1809）」をインストールして、さらに KB4497934 の累積アップデート（2019-05 x64 ベース システム用 Windows 10 Version 1809 の累積更新プログラム (KB4497934)）もインストールしている必要があるようです。現在のバージョンが 1809 の Windows 10 のみでこのアップデートの更新ボタンが出てくるようです。


以前からちょっと話題になっていたようですが、1903 は Insider 向けにすでにリリースされていて、その中でちょっと大きい変更として WSL 2 が含まれています。
WSL 2 は Hyper-V を利用して、Windows 上で Linux kernel を動かすようで、これは Docker なども使っている技術という理解でよいでしょうか。Microsoft、「WSL 2」への質問にブログで回答にいくつかの質疑応答がまとめられています。

Hyper-V を有効にすると VirtualBox は動かなくなるので、これは必要な人のみということになるでしょう。Sandbox として VirtualBox を使う必要がある人は Hyper-V はおあずけですね。

ちなみに自分の PC にはまだアップデート通知が来ていません。

BloggerのSyntaxHighlighterにLaTeXのbrushを入れてみる。

主観情報処理研究所さんのSyntaxhighlighter関連TipsにSyntaxHighlighterのLaTeX用Brushがあるよという情報があったので、うちでもBloggerに適用してみました。

\documentclass[uplatex,dvipdfmx,ja=standard,a4paper]{bxjsarticle}

\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[dvipdfmx]{graphicx}
\usepackage{hyperref}
\usepackage[dvipdfmx]{pxjahyper}
\usepackage{comment}

\setlength{\parindent}{0pt}
\setlength{\parskip}{2ex plus 0.5ex minus 0.2ex}

\begin{document}
こんにちは、世界。
\end{document}

ほほう。

やったことは、以下の通り。

LaTeX for SyntaxHighligther 3のページから、jsへのリンクへ飛んで、ソースをクリップボードにコピーします。

BloggerのテーマでHTML編集を開いて、"/head" の前に <script>（コピーした内容を貼り付け）</script> を入れて保存。

class指定で "brush:latex" する。

です。

listingsとfancyvrb。

\(\rm\LaTeX\)でソースコードや設定を記述するときに、listings パッケージ + jlisting パッケージを使って貼り付けていましたが、"//"コメントを使うとイタリック体になってしまって都合が悪いことに気づきました。まあ気にしない人は気にしない程度のことかも知れませんが。

追記: listingsのドキュメントを見ていたら、commentstyle という key のデフォルトが itshape になっているのを見つけました。
lstset の中で書体を指定すればイタリック体以外も使えます。

実は description 環境を使ったときに、段落間をもうすこし開けたい、と調べているときに fancyvrb パッケージを発見して、これを見てみたらすごくいい感じだったのでメモです。

fancyvrbパッケージでは、通常の verbatim 環境を拡張して、文字の色付け、枠囲い、フォントの指定、空白文字の表示などなど、いやそれ verbatim じゃないだろうと思ってしまうような指定がいろいろできます。さらには verbatim 内で \fboc{}や \textcolor{}などが使え、なんだそりゃ的にすごいので、verbatim なんだけどこの行だけ特に強調したい、みたいな場合にはすごく助かります。詳細は上記リンク参照。

追記: Verbatim環境で、UTF-8で「対応」の文字が "Invalid code (24540), should be in the range of 0..255." というエラーになりました。up-\(\rm\LaTeX\)なので中身はe-up\(\rm\TeX\)なんですが、日本語で listings+plistings(jlisting) のほうがいいかもしれません。

ちなみに description 環境で \item 内の記述の段落間をもう少し開けたい場合には、enumitem パッケージを使います。enumitem パッケージはリスト系の環境の書式を、topsep、partopsep、parsep、itemsepで調整できます。

\begin{description}[topsep=0pt,partopsep=0pt,parsep=15pt,itemsep=0pt]
    \item [first item]~\\
        1行目。

        2行目。
    \item [second item]~\\
        なんとかかんとか。
\end{description}

みたいな感じで使うと、1行目と2行目の間を15pt分開けてくれます。

それから余談ですが、listings パッケージの日本語対応で jlisting を使うというのはよく見るのですが、plistingというのもあるようです。
よくよく見てみると、jlisting.sty を使うという記述のページでは、jlisting.sty の入手先を SourceForge の My\(\rm\TeX\)part の奥の方から URL 直で指定しているようですが、My\(\rm\TeX\)part の wiki では Listingsのページで plistings を推してるじゃありませんか。
plistings は GitHubの方には、e-\(\rm\TeX\) 拡張必須、と記載がありますが、TeXLive はすでに up\(\rm\LaTeX\)などはe-\(\rm\TeX\)なので、問題ナッシングです。

もうひとつ、listing の lstset で language を指定するときに、サポートしている言語のリストってどこー、とか探してもなかなか見つからないので列挙しておきます。

ABAP (R/2 4.3, R/2 5.0, R/3 3.1, R/3 4.6C, R/3 6.10)、ACM、ACMscript、ACSL、Ada (2005, 83, 95)、Algol (60, 68)、Ant、Assembler (Motorola68k, x86masm)、Awk (gnu, POSIX)、bash、Basic (Visual)、C (ANSI, Handel, Objective, Sharp)、C++ (11, ANSI, GNU, ISO, Visual)、Caml (light, Objective)、CIL、Clean、Cobol (1974, 1985, ibm)、Comal 80、command.com (WinXP)、Comsol、csh、Delphi、Eiffel、Elan、erlang、Euphoria、Fortran (03, 08, 77, 90, 95)、GAP、GCL、Gnuplot、hansl、Haskell、HTML、IDL (empty, CORBA)、inform、Java (empty, AspectJ)、JVMIS、ksh、Lingo、Lisp (empty, Auto)、LLVM Logo、Lua (5.0, 5.1, 5.2, 5.3)、make (empty, gnu)、Mathematica (1.0, 3.0, 5.2)、Matlab、Mercury、MetaPost、Miranda、Mizar、ML、Modula-2、MuPAD、NASTRAN、Oberon-2、OCL (decorative, OMG)、Octave、Oz、Pascal (Borland6, Standard, XSC)、Perl、PHP、PL/I、Plasm、PostScript、POV、Prolog、Promela、PSTricks、Python、R、Reduce、Rexx、RSL、Ruby、S (empty, PLUS)、SAS、Scala、Scilab、sh、SHELXL、Simula (67, CII, DEC, IBM)、SPARQL、SQL、tcl (empty, tk)、TeX (AlLaTeX, common, LaTeX, plain, primitive)、VBScript、Verilog、VHDL (empty, AMS)、VRML (97)、XML、XSLT

自分が使いそうなのだけ色を変えてみました。ふと気づけば Windows PowerShell がないですね。

それから listings のドキュメントを眺めたら、Interface to fancyvrb というのがありました。

The fancyvrb package—fancy verbatims—from Timothy van Zandt provides macros for reading, writing and typesetting verbatim code. It has some remarkable features the listings package doesn’t have. (Some are possible, but you mustfind somebody who will implement them ;-).

fancyvrb=[true|false]
activates or deactivates the interface. If active, verbatim code is read by fancyvrb but typeset by listings, i.e. with emphasized keywords, strings, comments, and so on. Internally we use a very special definition of \FancyVerbFormatLine.
This interface works with Verbatim, BVerbatim and LVerbatim. But you shouldn’t use fancyvrb's defineactive. (As far as I can see it doesn’t matter since it does nothing at all, but for safety ....) If fancyvrb and listings provide similar functionality, you should use fancyvrb's.

listings のオプションで fancyvrb=true すると、verbatim 自体は facyvrb が行うけどタイプセットは listings が行う、と。つまり、fancyvrb の Verbatim 環境の中でキーワードや構文強調などが使えるということのようです。

また、listings でサポートされていない言語を追加する場合には（たぶんいろいろと解説してくれているサイトもあるでしょうが）、

\lstdefinelanguage{rock}
{
  morekeywords={one,two,three,four,five,six,seven,eight,
      nine,ten,eleven,twelve,o,clock,rock,around,the,tonight},
  sensitive=false,
  morecomment=[l]{//},
  morecomment=[s]{/*}{*/},
  morestring=[b]",
}

みたいな形でプリアンブルに追加できるようです。

VSCodeのLaTeX WorkshopとVscodeVim。

ちょっと不思議というか。

Visual Studio Code で LaTeX ファイルを編集して、LaTeX Workshop の設定では、

• Latex > Auto Build: Run = ofFileChange
• Latex > Auto Build: Interval = 1000

などとしているんですが、Vim（VscodeVim）を有効にしていると、":w" で保存したときにトリガーがかからず、自動ビルドが始まってくれません。

LaTeX Workshop のドキュメントを見ると、

"onFileChange": Build the project upon detecting a file change in any of the dependencies. The file can even be modified outside vscode. See here for explanations on what dependencies are and how some of them can be ignored.

とあるので、依存関係にあるファイルが「vscode の外部で」変更されても検出してコンパイルするよ、ということらしいのですが…。

ちなみに "Build LaTeX project" のキーバインドは C-A-b のようですが、ちょっと使いづらい感じ。VimTeX と共通で '\ll' としたいところですが、

  "vim.normalModeKeyBindingsNonRecursive": [
    {
      "before": ["\\", "l", "l"],
      "commands": [
        "latex-workshop.latex.recipe.default",
      ]
    }
  ],

としてもうまく動きません。まあ、C-A-b でもいいんですけど…。

NetBSDでlibuvがコンパイルできない件。

自分用メモです。

NetBSD-8 で Neovim の master ブランチをビルドしようとしたら、libuv で

~/build/neovim/.deps/build/src/libuv/src/unix/thread.c:222:22: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function)
     if (stack_size < PTHREAD_STACK_MIN)
                      ^

というエラーが出て、コンパイルできませんでした。 ちょっと調べてみると、/usr/include/limits.hで

/*
 * These are the correct names, defined in terms of the above
 * except for PTHREAD_KEYS_MAX which is bigger than standard
 * mandated minimum value _POSIX_THREAD_KEYS_MAX.
 */
#define PTHREAD_DESTRUCTOR_ITERATIONS   _POSIX_THREAD_DESTRUCTOR_ITERATIONS
#define PTHREAD_KEYS_MAX                256
/* Not yet: PTHREAD_STACK_MIN */
#define PTHREAD_THREADS_MAX             _POSIX_THREAD_THREADS_MAX

という部分があり、確かに定義されていません。 さらに調べてみると、NetBSD の tech-userlevel メーリングリストで2014年にPTHREAD_STACK_MINというメールが投げられていました。そこでの結論は、 PTHREAD_STACK_MINの代わりにsysconf(_SC_THREAD_STACK_MIN)を使ったほうが安全、ということのようです。 一方 libuv のほうでは、今年の4月に Do not use PTHREAD_STACK_MIN unconditionally for the unix target #2252というのが出ており、結果として「定義されていれば使用する」という形に落ち着いたようです。途中、GNU じゃない FreeBSD とか NetBSD は libuv はサポートせんよ、みたいな投稿もありましたが。

ともあれ、現状では Neovim の CMake では libuv-1.26.0（2019年2月11日リリース）を使用しているようで、1.29.0 では上記の変更が反映されているようなので、そのうち修正なしでコンパイルできるようになるでしょう。

Neovim でのコンパイルにおいては、最初にある thread.c に #2252 のパッチを当てればいいかと思います。

BIND 9のdnssec-lookasideの設定。

BIND 9（9.14.1）の named.conf をいじってるんですが、named-checkconf をかけると次のメッセージが出てきます。

# named-checkconf
/etc/named.conf:10: dnssec-lookaside 'auto' is no longer supported

え、どういうこと？と思って調べてるんですが…。

9.12.0 のリリースノートに以下の記述がありました。

The ISC DNSSEC Lookaside Validation (DLV) service has been shut down; all DLV records in the dlv.isc.org zone have been removed. References to the service have been removed from BIND documentation. Lookaside validation is no longer used by default by delv. The DLV key has been removed from bind.keys. Setting dnssec-lookaside to auto or to use dlv.isc.org as a trust anchor results in a warning being issued.

ISC.org の DNSSEC Lookaside Validation（DLV）サービスが停止されて、dlv.isc.org にあるすべての DLV レコードが削除されたので、dnssec-lookaside autoしたり dlv.isc.org を trust anchor に指定すると、警告が出ますよ、と。

BIND 9.12.0 は 2018年1月にリリースされています。それに先駆けて、上記のサービスが2017年9月30日に停止されています。ISC's DNSSEC Look-aside Validation Registry。

要するに、trust anchor を別のところに設定すればいいということだと思うのですが、一応参考までに最新のトラストアンカーによるDNS検証リゾルバの更新。

NeovimをVisual Studio 2019でコンパイルする。

以前にNeovimをVisual Studio 2017でコンパイルする。を書いていますが、ちょうど1年経ったことでもあるので、アップデートしてみます。
前提条件ですが、うちでは c:/Apps/Neovim 以下にインストールしていますので、新規ビルドは c:/Apps/Neovim-new にインストールしてから最後にディレクトリ名を変更する形にします。

Neovimをコンパイルする

CMakeのおかげもあって、ものすごく楽になっています。
以前にあった C4819 警告（データの損失を防ぐために、ファイルを Unicode 形式で保存してください。）は出ますが、これは 「ベータ: ワールドワイド言語サポートでUnicode UTF-8を使用(U)」をセットしておくか、Windowsのシステムロケールを「英語(米国)」に変更しておくことで回避できます。お勧めは後者のシステムロケールの変更です。

$ git clone https://github.com/neovim/neovim
$ cd neovim
neovim$ make CMAKE_BUILD_TYPE=Release CMAKE_INSTALL_PREFIX=c:/Apps/Neovim-new

で依存ライブラリまで含めてすべてビルドしてくれます。
ビルドが終わったら

neovim$ make install

です。

Neovim-Qtをコンパイルする

equalsraf/neovim-qtは活発な開発という段階は終わって、API への対応があるくらいでほぼ安定ということなのでしょう、最後のコミットも3ヶ月以上前です。
ただ、Neovim の Windows バイナリに同梱されている Neovim-Qt は 32bit 版なので、好みの問題でしょうが 64bit 版をコンパイルします。

README.mdには

$ mkdir build
$ cd build
$ cmake -G "Visual Studio 14" -DCMAKE_BUILD_TYPE=Release ..
$ cmake --build . --config Release --target install

とありますが、自分の環境ではこれだけではコンパイルできないのでまとめです。

Qt5 は c:\Apps\Qt\ 以下にインストールしています。バージョンは 5.12.2 で、C:\Apps\Qt\5.12.2\msvc2017_64\binをパスに追加しています。これがないと WinDeployQt.exe を見つけられなくてエラーになります。

また CMake は 3.14.4 でパスを通しています。

$ git clone https://github.com/equalsraf/neovim-qt
$ cd neovim-qt
neovim-qt$ mkdir build
$ cd build
build$ set CMAKE_PREFIX_PATH=C:/Apps/Qt/5.12.2/msvc2017_64/lib/cmake/Qt5Core;C:/Apps/Qt/5.12.2/msvc2017_64/lib/cmake/Qt5Gui;C:/Apps/Qt/5.12.2/msvc2017_64/lib/cmake/Qt5Svg;C:/Apps/Qt/5.12.2/msvc2017_64/lib/cmake/Qt5Network;C:/Apps/Qt/5.12.2/msvc2017_64/lib/cmake/Qt5Widgets;C:/Apps/Qt/5.12.2/msvc2017_64/lib/cmake/Qt5Test
build$ cmake -G "Visual Studio 16" -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=c:/Apps/Neovim-new ..
build$ cmake --build . --config Release

ここで msgpack-cpp-3.0.1 が C2220 エラーを出してビルドがエラー終了します。なので CMakeLists.txt にパッチを当てます。

neovim-qt$ diff -rub third-party/CMakeLists.txt.orig third-party/CMakeLists.txt
--- third-party/CMakeLists.txt.orig     Sat May 18 09:56:59 2019
+++ third-party/CMakeLists.txt  Sat May 18 09:53:11 2019
@@ -13,17 +13,17 @@
 set(MSGPACK_URL https://github.com/msgpack/msgpack-c/archive/cpp-${MSGPACK_VERSION}.tar.gz)
 set(MSGPACK_SHA256 1b834ab0b5b41da1dbfb96dd4a673f6de7e79dbd7f212f45a553ff9cc54abf3b)

-message(STATUS "Downloading Msgpack...")
-set(MSGPACK_TARBALL msgpack-${MSGPACK_VERSION}.tar.gz)
-file(DOWNLOAD ${MSGPACK_URL} ${CMAKE_CURRENT_SOURCE_DIR}/${MSGPACK_TARBALL}
-       INACTIVITY_TIMEOUT 30
-       EXPECTED_HASH SHA256=${MSGPACK_SHA256})
-execute_process(COMMAND ${CMAKE_COMMAND} -E tar xfz ${MSGPACK_TARBALL}
-       WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
-       RESULT_VARIABLE rv)
-if(NOT rv EQUAL 0)
-  message(FATAL_ERROR "Failed to extract ${MSGPACK_TARBALL}")
-endif()
+#message(STATUS "Downloading Msgpack...")
+#set(MSGPACK_TARBALL msgpack-${MSGPACK_VERSION}.tar.gz)
+#file(DOWNLOAD ${MSGPACK_URL} ${CMAKE_CURRENT_SOURCE_DIR}/${MSGPACK_TARBALL}
+#      INACTIVITY_TIMEOUT 30
+#      EXPECTED_HASH SHA256=${MSGPACK_SHA256})
+#execute_process(COMMAND ${CMAKE_COMMAND} -E tar xfz ${MSGPACK_TARBALL}
+#      WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
+#      RESULT_VARIABLE rv)
+#if(NOT rv EQUAL 0)
+#  message(FATAL_ERROR "Failed to extract ${MSGPACK_TARBALL}")
+#endif()

 set(LIBRARY_OUTPUT_PATH ${PROJECT_BINARY_DIR})
 set(MSGPACK_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/msgpack-c-cpp-${MSGPACK_VERSION}/)

上のパッチを当てておかないと、修正しても上書きされてしまいます。

neovim-qt$ diff -rub third-party/msgpack-c-cpp-3.0.1/CMakeLists.txt.orig third-party/msgpack-c-cpp-3.0.1/CMakeLists.txt
--- third-party/msgpack-c-cpp-3.0.1/CMakeLists.txt.orig Sat May 18 09:57:13 2019
+++ third-party/msgpack-c-cpp-3.0.1/CMakeLists.txt      Sat May 18 09:53:42 2019
@@ -251,9 +251,9 @@

 IF ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "MSVC")
     IF (CMAKE_CXX_FLAGS MATCHES "/W[0-4]")
-        STRING(REGEX REPLACE "/W[0-4]" "/W3 /WX" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
+        STRING(REGEX REPLACE "/W[0-4]" "/W3" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
     ELSE ()
-        SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W3 /WX")
+        SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W3")
     ENDIF ()
 ENDIF ()

また、ソースの方では test/tst_neovimconnector.cpp が文字コードの関係でエラーになります。

neovim-qt$ diff -rub test/tst_neovimconnector.cpp.orig test/tst_neovimconnector.cpp
--- test/tst_neovimconnector.cpp.orig   Sat May 18 10:40:47 2019
+++ test/tst_neovimconnector.cpp        Sat May 18 12:00:12 2019
@@ -40,7 +40,7 @@
                NeovimConnector *c = NeovimConnector::spawn({"-u", "NONE"});

                // This will print a warning, but should succeed
-               QString s = "ç日本語";
+               QString s = "nihongo";
                QByteArray bytes = c->encode(s);
                QCOMPARE(c->decode(bytes), s);

そうしたらビルド＆インストールします。Neovimよりもあとにインストールすることで、32bit バイナリも上書きしてくれます。

build$ cmake --build . --config Release --target install

実際には本来不要なものまでインストールされますが、気になる場合には本家のビルドとファイルを比べて削除すればよいでしょう。

電気シェーバーの手入れ用オイル。

手入れ用のオイルやグリースはいろんな種類があります。

一般の家庭では、たぶんいちばん身近なものはミシン油でしょうか。あとは潤滑油という分野では CRC 5-56 あたりかも。5-56 は自転車乗り界隈では「緊急時以外は使ってはいけない」潤滑油として有名です。チェーンルブやベアリングのグリースを溶かして落としてしまうので、うちでは一切使っていません。固着したネジやナット部分にスプレーしてしばらく置くと浸透して緩めやすくなるので、そういう用途ではいいでしょう。ただ、揮発しやすいので長期的な潤滑はまったく期待できません。

それはいいとして、電気シェーバー用のオイルです。オイルなのにひげそりのような敏感な用途に使ってもいいんだろうかと思って成分を見てみたら、流動パラフィンと書いてありました。

最も身近な物がベビーオイルである。常温では無色の液体で非揮発性。水には不溶。化学的に安定な物質で、通常の条件では酸化を受けない。成分については固形のパラフィンよりオレフィン系炭化水素に富む。乳化しやすくのびや浸透性に優れる。純度は紫外光の吸光度により計測される。

たしかに、ベビーオイルも「オイル」という名前です。なるほど。それならカミソリ負けしやすい敏感肌でも大丈夫そうです。となると、パナソニック純正のシェーバー用オイルが 50ml で数百円しているのですが、ジョンソンベビーオイルでも兼用できるということですね。

Mercurial 5.0リリース。

Git というかおそらくは Github に圧倒されてる Mercurial ですが、当初のアナウンス（5月1日リリース）から1日遅れの5月2日に 5.0 がリリースされたようです。PyPi のほうは最新版が 5.0 になっています。

ただ、Mercurial Wiki の Python3を読むと、

Mercurial's setup.py file refuses to run with Python 3 by default. This means that pip install Mercurial or python setup.py install will not work with Python 3 by default.

Setting the HGPYTHON3 environment variable will suppress this error and allow execution with Python 3. e.g. HGPYTHON3=1 pip3.7 install Mercurial or HGPYTHON3=1 python3.7 setup.py install.

No run-time environment variable or config option is required to use Python 3 with Mercurial: only the installation step / setup.py requires special action to override the Python version check.

Python3 はデフォルトでは拒絶されるようになってるので、HGPYTHON3=1 してインストールすると有効になるよ、とのことです。

一方、TortoiseHG はまだ 4.9.1 が最新のようですが、5.0 に向けての作業は進んでいるようです。

ただ、Windows で使用するにはファイルシステムのエンコーディングあたり（PEP 529）でまだ難があるのか、あとは lazy importer のあたりでパフォーマンスに影響がないかなどをよく見る必要がある、みたいなことが書いてあります。

とりあえず現在進行中のプロジェクトでは 5.0 にあげないほうが無難でしょうね。
ただ、Mercurial が Python 3 で動くなら Python 2.x はもう排除できてありがたいので、ここは考えどころですね。

WindowsロケールをUTF-8にして不具合のあるアプリ。

Windowsの設定で UTF-8 をデフォルトにすることができるようになって 1 年以上が経ちますが、ここらへんでどういうアプリに影響があるかを自分の使ってる範囲でまとめてみます。

地域と言語の設定で「システムロケールの変更」をクリックすると、「地域の設定」ダイアログが出ますが、そこに「ベータ: ワールドワイド言語サポートでUnicode UTF-8を使用(U)」という項目があります。これは昨年の11月14日のInsider Previewで出てきたようです。/.Jより、Windows 10のInsider PreviewでシステムロケールをUTF-8にするオプションが追加されるによれば、

• 圧縮 （zip形式） フォルダーにファイル名がUTF-8で保存されるようになった。これに伴い、シフトJISに含まれない文字を使ったファイル名も普通に保存できるようになった。
• コマンドプロンプトのコードページが既定で65001（UTF-8）になった。このときのWindows標準コマンドのメッセージは英語になる。
• メモ帳のテキストエンコーディングがUTF-8になった。なお「ANSI」を選んでもUTF-8で保存されるので、シフトJISでの保存はできなくなる模様。
• GetACP()の戻り値も65001になる。WideCharToMultiByteなどでCP_ACPを指定したときも、UTF-8に変換される。

だそうです。

影響のあるアプリ

明らかにメニューやダイアログが文字化けして正常に使用できないものです。

• TeraTerm: ダイアログ、メニューバーなどほぼすべての日本語部分が文字化けする。ソースレベルでリソースファイルが ShiftJIS となっている。
  追記(2019/5/14): teraterm\lang\Japanese.lng を UTF-8 に変換してやればGUIの文字化けは解消される。
• Python 2.7: コンソールでの文字の扱いでおかしなことになる。例: print "あ" で止まる。
• Python 3.6: Python 2.7 と同様におかしなことになる。例 print("あ")
• Python 3.7: Python 2.7 と同様におかしなことになる。例 print("あ")
• cmd.exe: フォントがデフォルトの Consolas だと文字化けする場合がある。現在は修正されている？ただし、dir /?などのヘルプ関連はすべて英語になる。これは PowerShell も同様。
• Becky! 2: 表示はできるが、自動振り分けで失敗する。
  
  
• 筆王 Ver.23: スプラッシュスクリーンは表示するが起動しない。インストールも失敗する。

Python については、PYTHONIOENCODING=utf-8 を環境変数に設定してやればよいという記述も見たのですが、どうもうまくいきませんでした。どちらも IDLE が起動しません。コマンドラインから起動してみると、

UnicodeDecodeError: 'CP_UTF8' codec can't decode byte 0x8c in position 23: No mapping for the Unicode character exists in the target code page.

というエラーが出るので、ダメ文字関連（ShiftJISの2バイト目が '0x5c' の文字 - 'ー ソ 十 表'など）でしょうね。特にメニューに「表示」などが使われるとてきめんです。

影響のないアプリ

外見上は影響がないように思えるのは以下のものです。

• 秀丸エディタ
• Visual Studio Code
• Notepad++
• Neovim: ロケールを ja_JP.UTF-8 と設定してやれば GuiFont に日本語フォント名が使える。
• Sylpheed
• TortoiseHG: 以前はPythonでの不具合があった（LookupError: unknown encoding: cp65001）が、修正されているように見える。
• FreeCAD
• LibreCAD
• Blender
• Inkscape
• Krita
• Canon Digital Photo Professional
• Adobe Reader XI
• SumatraPDF
• CubePDF
• AviUtl: 以前はメニュー類、プラグインのダイアログなどが文字化けしていたが、（おそらくシステム側で？）修正されている模様。
• MuseScore 2

NetBSDとBIND 9。

ふと、インターリンクで IPv6 に対応しているから、じゃあやってみるためにちょっと調べようと思いまして。

うちは 光ルーターとして RS-500KI を使っています。この場合、インターリンクに接続するとここで示唆されている通り、.hgw6 が付加されて接続できません。そしてこの設定はユーザがいじることができません。

であれば、光ルーターはただのブリッジにして、内側には Aterm WG1900HP があるのでそれを使って IPv6 PPPoE してやればできるんじゃないかと思ったわけです。いずれにしてもインターリンクは IPoE はやっていないので、だれかが PPPoE してやればいいわけです。当然ながらフレッツ・v6オプションは有効になっています。

と、周囲の状況を確認した上で、さてネームサーバはどうしましょう、と。
NetBSD は 1.3 の頃にいじり始めて、サーバとしてドメインをとって BIND とかをいじり始めたのは 2003年以降だったと思いますが、当初は ADSL 回線でした。当時は DNS サーバは WAKWAK 側で用意していたので、こちらでは権威サーバではなくローカルの名前解決用として使うくらいでした。
その後、インターリンクにプロバイダを切り替えたのは独自ドメインが安く取得できるからという理由です。最近はさくらインターネットなどでも安価に運用できるようになっていますが、おうちサーバを立てるなら全部自分でやってね、プライマリネームサーバもね、というスタンスのインターリンクはやる気になればいろいろできるので便利です。サブドメインや仮想ホスト（CNAME）も作り放題ですし。

ということでネームサーバですが、BINDの設定を見ていて、そういえば /usr/share/example に IPv6 の設定例みたいなのがあるのでは、と探してみたところ、bind のサンプルが収録されていません。変だな、と思って他のサンプルを見てみると、nsd と unbound があります。おや？と不審に思って検索してみたら、2016年8月に bind -> unbound/nsd というメールが christos 氏から投げられていて、ISC が BIND のライセンスを変更したから、NetBSD に収録する DNS サーバの変更を検討したほうがいいんじゃね？と提起されていました。その結果、おそらく BIND は積極的には使わない方向にいっているのかもしれません。

ともあれ BIND の設定サンプルはないようだし、BIND の設定は面倒だし、もうちょっと楽にできないかしらというのもあって、NSD と UNBOUND が採用されたようだし、みてみることにしました。

NSD も UNBOUND もどちらも NLnet Labs の製品で、NSD は権威サーバ、UNBOUND はキャッシュ＆リゾルバです。それ以外には packages に PowerDNSもあります。

とりあえず、本家の流れに従って、BIND から NSD/UNBOUND に移行してみましょうか。

From Bind to nsd and unbound on OpenBSD 5.6を参考にすると、NSD では BIND の ZONE ファイルをそのまま使えるようです。であれば権威サーバの移行はスムーズです。
ArchLinux の Wiki にも NSD と UNBOUND のページがあります。また、日本 Unbound ユーザ会が日本語ドキュメントを用意してくれています。ちなみに NetBSD-8 の base.tgz には nsd は含まれていませんが、ソースツリーには /usr/src/external/bsd/nsd にあるので make install すれ使えるようになります。バイナリが含まれていないのは権威サーバが必要な人は make くらいできるでしょ、という感じでしょうか。
ちなみに NetBSD-8 の nsd は 4.1.14（2016/12）、unbound は 1.6.8（2018/1） です。新しいバージョンは pkgsrc/net にありますので、必要な人は各自インストールでしょう。

php-fpmの動作確認。

Apache 2.4 の構成をいろいろといじっています。

Apacheのmod_cgiとmod_cgidとpreforkとevent。でも触れていますが、PHP と Perl と Python をそれぞれ別のアプリケーションで使いたいということなのですが、歴史的な経緯もあり、Perl は太古の CGI（ゆいちゃっと）、PHP は WordPress、Python は GNU Mailman 2 となります。それぞれの API は、ゆいちゃっとと Mailman が CGI で、WordPress が FastCGI を使おうと考えています。実際には CGI と FastCGI はアプリケーションから見ると同じなので、結局すべてを CGI または FastCGI でやる、という感じです。

NetBSD の pkgsrc では、www/fcgi に cgi-fcgi という実行形式が含まれていて、CGI 形式でリクエストを送ると、FastCGI として FastCGI デーモンに投げ、応答を再度 CGI 形式にして返してくれます。php-fpm で使ってみるとこんな感じ。

$SCRIPT_NAME=info.php SCRIPT_FILENAME=/srv/www/Test/info.php REQUEST_METHOD=GET cgi-fcgi -bind -connect /var/run/php_fpm.sock

Apache の mod_cgid は、ちょっと勘違いしていたんですが、Apache 2.4 の説明をよく読むと、

Unix オペレーティングシステムの中には、マルチスレッドのサーバから プロセスを fork するのが非常にコストの高い動作になっているものがあります。 理由は、新しいプロセスが親プロセスのスレッドすべてを複製するからです。 各 CGI 起動時にこのコストがかかるのを防ぐために、mod_cgid は子プロセスを fork して CGI スクリプトを実行するための 外部デーモンを実行します。 主サーバは unix ドメインソケットを使ってこのデーモンと通信します。

となっていて、mod_cgid 自体が子プロセスを fork して外部デーモンを起動する、ということは、別途外部デーモンを用意する必要はなく、そのあたりは mod_cgid で面倒を見てくれる、ということのようです。prefork で使われる mod_cgi は自分自身で面倒を見るけれど、worker/event で使われる mod_cgid は自分でデーモンを起動してそちらに任せる、ということで、アプリケーションから見ると何も変わらないことになります。

ということであれば、上記の Perl / PHP / Python のアプリケーションは全部 mod_cgid で引き受けることができそうです。外部に CGI サーバを別途用意するなら uWSGI の CGI plugin を使って、とか考えていましたが、特に必要はなさそうです。

一方、php-fpm などの FastCGI サーバが動かせるタイプのものは mod_proxy_fcgi を使ってやれば、Apache からプロセスを切り離すことができます。

ところで PHP 7.3.4 で preg_match() あたりで JIT 警告（正確には、"Warning: preg_match(): JIT compilation failed: no more memory in xxx"）が出てるんですが、5月2日にリリースされた 7.3.5 では修正されているようですね。

TeXLive 2019 のインストール。

やっとミラーサーバにも TeXLive 2019 が回ってきたようで、ようやくインストールできるようになりました。
が、GUI のインストーラが立ち上がってもエラーで先に進みません。うちだけかもしれませんが。

インストーラを起動して、"unpack only" をしてから、そのディレクトリに移動して
%USERPROFILE%\install-tl-20190502\install-tl-windows.bat -no-gui でテキストモードでインストールするとちゃんとインストールできるみたいです。

ユーザローカルにインストールしたければ通常モードで、システムワイド（今までどおり c:\texlive）にインストールしたければ管理者モードでコマンドプロンプトを起動すればいいです。

bozohttpd。

NetBSD で Apache のオプションでモジュール一覧をするのがあったよな、と思い、詳細を確認しようとして man page を見ようとしたら、man apache はなくて、man httpd したらオプションの説明が期待したものと違っていて、ふとタイトルを見ると "BOZOHTTPD(8)" となっていました。なにそれと思ったら、

bozohttpd ? hyper text transfer protocol version 1.1 daemon

ということで、なんと NetBSD に標準で組み込まれている http daemon のようです。
今まで知らなかったのは最初から Apache を使ってたからでしょうけど、調べてみると 1999年5月19日に加えられたようです。歴史的には NetBSD-1.4 なので、たしか自分が NetBSD に手を出したのは Sparc のピザボックスでそのときは 1.3 だった気がするので、もうほとんど最初からそこにあったのに気づかなかったのですね。

pkgsrc の DESCR を見ると、

bozohttpd is a small and secure HTTP version 1.1 server. Its main
feature is the lack of features, reducing the code size and improving
verifiability.

It supports CGI/1.1, HTTP/1.1, HTTP/1.0, HTTP/0.9, ~user translations,
virtual hosting support, as well as multiple IP-based servers on a
single machine. It is capable of servicing pages via the IPv6 protocol.
It has SSL support. It has no configuration file by design.

とあって、CGI も IPv6 も SSL も仮想ホストもサポートしているようです。IPv6 については2000年に itojun 氏が追加しているようです。

ドキュメントはあまりないようで、pkgsrc のほうを見ても man page しかないようです。