29-Oct-2023
［VMware Player上のDOS/V(PC-DOS 2000)環境をOpenBSD-7.4/amd64上のDOSBox-0.74-3へ持っていこうとしているけどうまくいってない］

ディスクイメージからファイルを取り出すのは難しくないです…大文字のファイル名を使うのはUNIX的にどうなのという気はしますが、エミュレータ上で大文字小文字の違いに悩まされるのも嫌なのでmount_msdos -l（デフォルト）でマウントしています。※mount_msdos -sもしくは-9の場合、ファイル名は小文字になります。

ディスクイメージの型式変換
qemu-img convert pcdos2000-vm.vmdk pcdos2000-vm.raw
ディスクイメージのマウント
vnconfig vnd0 pcdos2000-vm.raw; mount_msdos -l /dev/vnd0i /mnt
ファイル取り出し
mkdir ~/dos; cp -r /mnt ~/dos/c
ディスクイメージのマウント解除
umount /mnt; vnconfig -u vnd0

あとはDOSBoxの利用と似たような手順になると思っていました。CONFIG.SYS内でCOUNTRY=による設定が行えない問題を回避するためのCHEJ 6.10と、デバイスドライバの組み込みに使うadddev/deldevは、とりあえず~/dos/dに入れておきます。

DOSをインストールした直後ではなく少し手が入っている状態のCONFIG.SYSですが、ここから最低限必要そうなものを組み込んでDOSBox上での動作を確認していきます。

この後にd:\adddev +c:\dos\$disp.sysとすれば日本語表示はできる…はずなのですが、こうなりました。$disp.sysのオプションを<なし>, /hs=off, /hs=on, /hs=lcどれを試しても変わりません。

t20231029a.png

VectorのDOS/V V-TEXT用ユーティリティにあるディスプレイドライバを片っ端から試してみましたが、何を使ってもこんな感じです。

t20231029b.png

他に、以下のようなことを試しているのですが…

CONFIG.SYSではなくadddev.exeでドライバを登録することによる問題というよりは、DOSBox側の問題のようです。どうやらdosbox-0.72-int10con.patchというパッチが存在するようなので、おそらくこれが適用されていないDOSBoxではどう頑張ってもDOS/V化できないということになるのでしょう。DOSBox-Xではエミュレータ自体がDOS/Vの機能を持っているらしいという話があるので、そちらを待つ方が良いのかもしれません。55.2kg(22:15)

28-Oct-2023
［どうしてこうなった］

VMware PlayerにSlackware-3.2をインストールしてみたは良いものの、vlance(pcnet32)用のドライバがないのでSLIP接続しないとTCP/IPが通らないという事態になっています。という訳で、昔作ったsliptunにお仕事をしてもらうことにします。

OpenBSD側はsliptunのREADME.mdに従って操作をすれば良いとして、Slackware側はipなんてコマンドすらない時代のLinuxなので違うコマンドで操作しないといけません。多分、こう。

# slattach ttyS0 38400
# ifconfig sl0 192.168.200.2 pointopoint 192.168.200.1
# route add 192.168.200.1 dev sl0

Slackware-3.2だとシリアルポートの速度を38400bpsよりも高速にできず、またrouteで通信相手のIPアドレスに対応するインタフェースを教える必要があるようです。分かってしまえば大したことではないと思いますが…現代に暮らしていると「そこはifconfigが面倒見てほしいな」という気分になりますね。

で、こんな感じ。

t20231028.png

この時代のLinuxだと/etc/inetd.confはデフォルトでftpとtelnetが有効になっているので、TCP/IPが通れば速度はともかく最低限の操作はできるはずです。これでhttp://ftp.jp.freebsd.org/pub/NetBSD/arch/i386/dosemu/から入手したdosemu-0.63.1.2.tar.gzをOpenBSD機越しにSlackware-3.2仮想マシンに持ってきてビルドができるはず…なのですが、現時点ではできていません。エラーの内容を見ると解決するのが面倒そうなので、ここで諦めることにします。

実はFep bridgeを調べていて、これはDOS仮想マシンとホストマシンとの通信を名前付きパイプ(FIFO)を使用して行っています。FIFOを含むディレクトリをDOS仮想マシンにマウントして操作した場合に、DOSBoxではDOS側/ホスト側ともにFIFOがきちんと動いているのに対し、emu2はFIFOが空だとDOS側は待たずに読み出し処理を終えてしまうことが分かっています。それではFep Bridgeが使っていたDosEmuやpcemuはどうなのかな？と気になったのでこんなことをしていました。証拠は出せていませんが、おそらくDOSBoxのようにきちんと動いていたのではないかと推測します。

今更DOS/V向けのFEPなんて、入手性は悪いし使える場面もそんなに無いでしょう。とはいえ、Fep Bridgeのような他環境向けのかな漢字変換を使う技は昔から気になっていたので、少し時間を使って見てみようかなと考えています。55.4kg(23:00)

22-Oct-2023
［OpenBSD-7.4へ］

思ったより早くOpenBSD-7.4が来たので即アップデートして、辞書も戻して使っています。折角なので頓挫していたalsa-pluginsとalsa-lib, alsa-utilsのportsを仕上げて然るべきところへぶん投げてしまいました。alsa-plugins、原因が分かってしまえばどうということはないのですが、/etc/alsa/conf.d/50-pulseaudio.confが普通のファイルではなく/usr/local/share/alsa-lib/alsa.conf.d/50-pulseaudio.confへのシンボリックリンクになっているのでそれに応じたpkg/PLISTを書かないときちんとしたパッケージにならないというオチでした（この原因が分からず半年以上放置していました…すみませんすみません）。

alsa-lib, alsa-utilsも1.2.10に上げています。これへの対応が地味に面倒で…とりあえずaplay /dev/randomでALSA→PulseAudio→sndioの経路で音が鳴ることは確認したので良しとしてしまっていますが、1.2.10で追加されたUMP(Universal Midi Packet)を含むMIDIの動作確認はできていなかったりします。MSHVを動かすためにはPCMが動けば十分とはいえ、本当はMIDIの動作確認もきちんと行わないといけないんですよねえ。押し入れに放置したKORG NS5Rは動くんだろうかとか、USB-MIDI I/FとMIDIケーブル持ってたっけ？とか、そのレベルから確認しないとダメなんですけど…

昨日発生したJ:COMの通信障害はこちらも見事に食らいましたが、復旧から半日以上経過しても障害の原因については発表がないようです。日経新聞の記事ではコアの通信回線とインターネットサービスをつなぐ通信設備で故障があったとみられるそうですが、よく分かりません。X(Twitter)上ではDNS障害では？という声もあるようなのですが、こちらではGoogle public DNSへのpingはIPv4/IPv6ともに通っていないこと、それ以前にケーブルモデムのOnline LEDが消灯していたため本当にDNSの問題なのだろうかと疑問視しています。pingを打つ時点でモデム側がOfflineになっていたなら判断のしようがないじゃんよ、ではありますけど。

通信障害から復旧したついでに、13-Feb-2022から稼働中のNanoPi R2Cを使ったルータをOpenWrt-23.05.0に上げておきました。OpenWrt-22.03系ではR2Sのみの対応となっていましたが、23.05.0になってからはR2C対応も入っています。ただし、NanoPi R2S向けのバイナリを動かしている状況でfriendlyarm_nanopi-r2c-ext4-sysupgrade.img.gzを使ってR2C対応を行おうとしても、機種が違うためにアップグレードはできないと拒否されます（強引に行うオプションもあるようですが、失敗した後が非常に面倒そうなので試していません）。という訳で、NanoPi R2Cを使っているにも関わらずNanoPi R2S向けのバイナリを使う状況が続きます。どこかの時点で、あるべき状態にしたいところではありますが…

そういえばNanoPi R2Cは販売が終了しており、現在はeMMCを搭載して値段を上げたNanoPi R2C Plusという機種に変わっています。NanoPi R2Sが今でも売られているのを見ると、NanoPi R2Cとは結局なんだったのでしょう？55.0kg(22:20)

15-Oct-2023
［辞書戻しました］

OpenBSD-7.4のリリースも近そうなので、パッケージ更新の巻き添えを喰らう前にlibkkcの辞書を一旦オリジナルのものへ戻すことにしました。

オリジナルのdata.arpa、実はngram 1=118333, ngram 2=775414, ngram 3=1777469と結構単語数が豊富なんです（既に書いていたと思っていたのですが、全く書いていなかったとは…）。なので、戻した感想としては「これでも別に困らんなー」とか、「NWC2010/CC100-ja辞書ってサイズの割に賢さが足りないような…？」だったりします。

賢い辞書を作れたら良いなとは思っていましたが（これは容易ではなさそうです）、まずは辞書の作り方自体を明らかにするという目的がある程度果たせたので良しとしましょう。

CC100-ja辞書な生活はOpenBSDのアップデート後に戻るとして、とりあえずこれからどうしましょうかね…風邪を治すところから始めないといけないんですけど、なんか色々片付けないといけないこともあったような。55.4kg(22:30)

10-Oct-2023
［クランク戻しました・他］

ESCAPE R3(2015)にDriveLine ROMAXを付けたのが3年前。ちょっと乗りにくいなという場面もあったので、元のPROWHEEL SWIFTへ戻すことにしました。とりあえず戻しただけなので細かい調整は今後行っていく必要がありますが…一応は乗れています。

これと併せ、5年前に付けたRANT Shred pedalをMZYRH MX926に換えてしまいました。MX926、靴への食い付きがShred pedalよりも良いのですが（食い付きを良くするための）ネジが飛び出しているので気を付けておかないと要らぬ怪我をしてしまいそうです。取り付け前にネジも締めているとはいえ、緩んでなくしてしまうことへの注意も必要です。

ESCAPE R3、自分は2015モデルを乗っていますが2020, 2022および2024モデルでフレームの変更が入っていると聞いています。フレーム形状の違いで乗り心地がどのように変わったかというレビューがあれば是非見てみたいのですが、なかなか見つけられません（どこかにありますよね…？）。

今の自転車は7年が経過したとはいえまだ乗れますが、老朽化もそれなりに進む以上は次についても多少検討しておく必要があります。面白そうなのと（これ重要）、メンテナンスがしやすいという理由でピストバイクに乗ってみたいです。とはいえ、FUJI FEATHER, DECLARATIONでも結構なお値段なのでSCHWINN CUTTER辺りになるのでしょうか。とはいえ、CUTTERだと多少いじる必要がありそうなので最初からFEATHERという選択肢もあるのかもしれません（いじるにもそれなりにお金がかかります）。ピストは諦めて13-Feb-2022に書いたようにBRIDGESTONE XB1という手も？、ってこれもこれで結構お値段張りますね。

…この件については時間はまだありますし、のんびり考えることにします。

♪

27-Aug-2023で触れていた医療情報技師能力検定試験、合格していました。情報処理技術が96/100、医療情報システムが84/120、医学・医療が80/100と、医療情報システムを落としてまた来年〜と思っていたのですがどうにかなりました。

とはいえ、取ったところで何が変わるんでしょうかね？薬剤師×医療情報技師を要する案件なんてあんまり無さそうに見えますし…56.1kg(22:20)

28-Oct-2023補足：医療情報技師育成部会のページによれば、「2023.10.12 【お詫びと訂正】第21回医療情報技師能力検定試験の合格発表日（2023.10.05）に掲載した解答に誤りがありました（中略）なお、採点は正しい解答で行っていますので、採点結果に変更はありません。」とのことで、05-Oct-2023に公表された解答による自己採点の結果と送られてきた成績表とで得点に違いがあったことに対する疑問は解けたのですが…「2023.10.18 第21回医療情報技師能力検定試験の医療情報システム系の問題に出題ミスがありました。 詳細は、「第21回医療情報技師能力検定試験における出題ミスについて」をご参照ください。 」の件は、ちょっとどうなの？って思っています。

09-Oct-2023
［CC100-jaからlibkkc-data向けのdata.arpaを得ようとして力尽きました(3)］

言語資源を形態素解析するなら、その時点で読みを振ってしまえば良いのではないか…とあれこれ試してみたのですが、ダメでした。ストレージも相応に容量が要るのですが、むしろメモリ。RAM 32GB+swap 32GBでは足りないので、64GB以上のRAMとそれなりのswapが必要そうです。もう説明を書く気力もないので、コードの残骸だけ転がしておきます。

あと、先に読みを振るとnwc-toolkit-ngram-mergerの動作が怪しくなる気がします。nwc-toolkit-ngram-counterで得られた複数のコーパスをうまくマージできなかったり、バイナリのゴミが入るといった現象が発生していました。なので自力で3-gramを作ることも試みてみたものの…こちらもメモリ不足により敗退です。

01-Oct-2023の手法を再掲というか一部改良なのですが、お手軽にやるならこんな感じでいくしかなさそうです。※実行にかかった時間は手元のマシンでの値、ファイルサイズはおおよその目安（ストレージに余裕のある環境で作業してください）

Unicode正規化→一文ごとに切り出し→形態素解析（NEologd辞書を使います） ※5時間、27GB
nwc-toolkit-unicode-normalizer ja.txt.xz | nwc-toolkit-text-filter | mecab -d /usr/lib/x86_64-linux-gnu/mecab/dic/mecab-ipadic-neologd -Owakati | gzip -c > ja.mecab-neologd.txt.gz
コーパス作成 ※3.5時間、12GB
nwc-toolkit-ngram-counter -n 3 -l 24576 -b ja.mecab-neologd.txt.gz
3-gram切り出し ※4分、200MB
zcat ngms-XXXXXXXX-XXXXXX.0000.gz | awk '{if ($4 >= 100) {print $0}}' > 3gm

前回同様、nwc-toolkit-ngram-counterで得られたコーパスのファイルは一つだけ。nwc-toolkit-ngram-mergerで処理したファイルも作成していますが、得られたコーパス/処理後のファイルに相違ないことを確認したため、nwc-toolkit-ngram-counterで得られたコーパスを直接使っています。

頻度を制限しない（頻度1以上の）3gmにおける異なり数は931,642,404、頻度100以上では8,459,250…02-Oct-2023の時から極端に変わってはいないので頻度100以上で進めます。3gmはnwc2010-libkkcで処理しますが、少し手を入れてMeCab/NEologd辞書で読み仮名を付けるようにします。変換後のdata.arpaはngram 1=80317, ngram 2=1198795, ngram 3=5561771、NEologd辞書の効果は出ていそうな気がします。

ここしばらくは手法を確立することばかりやっていたので、生成された辞書がどの程度使えるかについてはあまり調べることができない状況でした。どうにかCC100-ja/MeCab-NEologdで生成したlibkkc用の辞書を作ってインストールするところまでできたので、しばらくこれで生活することにしましょう。56.0kg(07:05)

02-Oct-2023
［CC100-jaからlibkkc-data向けのdata.arpaを得ようとして力尽きました(2)］

01-Oct-2023の続き。日本語ウェブコーパス2010仕様の3-gramファイル(3gm)が得られたので、ここから読み仮名を付けてdata.arpa化するだけなのですが…出現頻度の線引きをどうするか、という問題があります。日本語ウェブコーパス2010の作成には396GBのテキストを使用したのに対し、CC100-jaは75GB。なので日本語ウェブコーパス2010における出現頻度の数字をそのままCC100-jaに適用することはできません。

とりあえずcat 3gm | awk '{if ($4 >= XX){print $1}}' | wc（XXは出現頻度の数）でざっくりと、N-gram(3-gram)の異なり数を出してみることにします。

日本語ウェブコーパス2010の形態素N-gram(3-gram)の異なり数は、頻度10以上が369,685,887、頻度100以上が51,401,622、頻度1000以上が6,395,754。とりあえず一桁減らして考えれば良さそうです。今使っている辞書が日本語ウェブコーパス2010の頻度750以上（異なり数は8,377,628）で作ったものなので、CC100-jaでは頻度100辺りで同じような辞書になるかどうかは何とも言えませんが、これを一つの目安としてやってみることにします。

試しに頻度100でdata.arpaを作ってみると、ngram 1=63525, ngram 2=1175059, ngram 3=6044823となっており、日本語ウェブコーパス2010の頻度750で作成したdata.arpa(ngram 1=80280, ngram 2=1263366, ngram 3=5042232)より語彙数は減っています。

CC100-jaでもとりあえず辞書を作れることは分かりましたので、早速使い始めたのですが…「てんに」を「点２」と変換してしまうのが少し気になっています。中二病ならぬ点２病とでも呼んでみましょうか。これ、頻度100→75(ngram 1=70444, ngram 2=1419241, ngram 3=7942800)に減らしても変わらなくて、辞書の癖と捉えるしかないような気がしています。

何か調整が必要そうな気がしているのですが、どこをいじれば良いのかあまりよく分かっていないので今の辞書を使いながら探していくことになりそうです。55.0kg(21:05)

01-Oct-2023
［CC100-jaからlibkkc-data向けのdata.arpaを得ようとして力尽きました］

nwc-toolkitも動くようになったので、CC100-jaからlibkkc-dataで使うdata.arpaを作ってみます。HTMLの収集及びテキスト抽出が済んだ状態でja.txt.xzが作られているので、nwc-toolkit-unicode-normalizer ja.txt.xz | nwc-toolkit-text-filter | mecab -Owakati > ja.mecab.txtでUnicode正規化→一文ごとに切り出し→形態素解析します。

nwc-toolkit-ngram-counterの使用方法にある「HTML アーカイブの作成に用いたオプションは -n 7 -mbs です．」に対してはmecabを素の状態（オプションなし）で動かす必要があるのですが、ディスク容量を圧迫する＋xz圧縮をかけると異様に遅くなる（20時間経過しても終わりません）ので-Owakatiを指定しました。i7-7700機で処理にかかった時間は4.5時間、出来上がったja.mecab.txtのサイズは84GB…ja.txt.xzを展開すると75GBあるので、多少膨れる程度で済んでいるようです。

形態素解析後は、nwc-toolkit-ngram-counter -n 3 -l 24576 -b ja.mecab.txtでコーパスを作ります。今回は3-gramしか使わないために-n 3を、ソート不要（これはnwc2010-libkkcで行います）かつmecab -Owakatiを使うため-bを指定します。マシンには32GBのメモリが載っているので、なるべく多く…ということで24GBを割り当てました。実行終了時にsentences: 592537732, tokens: 14982701916 (x25.29) (8774sec)というステータスが表示されていましたが、これに加えてファイルの書き出しに時間を要しており、結局3時間はかかっています。無圧縮の出力もできそうなのでその設定をしていればもうちょっと早かったかもしれません。コーパスのファイルサイズは圧縮された状態で9.1GBくらい。

生成されたコーパスのファイルが複数ある場合はnwc-toolkit-ngram-mergerを使って統合するとありますが、今回は一つのファイルだけだったのでこれを直接使います（おそらく分割されていても使わなくて済むのではないでしょうか）。コーパスは1-gram, 2-gram, 3-gramが混在した状態で出力されるため、zcat ngms-*.gz | awk '$4 {printf("%s %s %s\t%s\n",$1,$2,$3,$4)}' > 3gmで、3-gramのみ取り出したところで今日は力尽きました。続きはそのうち。55.9kg(20:55)

07-Oct-2023補足：生成されたコーパスのファイルが一つの場合、nwc-toolkit-ngram-mergerを通す前と通した後の結果は変わらないことを確認しています。また、nwc-toolkit-ngram-counterはgetopt_long()の指定にバグがあり(0.0.2)、-eオプションによる圧縮形式/圧縮offの指定はできません。このバグはmasterブランチ(0.1.0)に関しても同様に存在します。

理由についてはまだよく分かっていないのですが、コーパスのファイルが複数になった場合はnwc-toolkit-ngram-mergerを必ず通す必要があります（分割されたコーパスから3-gramだけ拾うというやり方ではうまくいかない感触があります）。