数年前から語り本系平家物語を最初から暗誦できるように読み進めています。『新日本古典文学大系 44 平家物語 上』を使っていますが「吾身栄花」の途中まで覚えました。ここは、平清盛だけでなく一門が繁栄したことを語る場面です。そこには、つぎのような一節があります。
すべて一門の公卿十六人、殿上人卅余人、諸国の受領・衛府・諸司都合六十余人なり。
ここで殿上人は「卅余人」（さんじゅうよにん）とあります。「三十四人」ではありません。「30人+α」ということです。公暁は「十六人」と人数をぼかしていないのに、殿上人は実際の人数を明らかにしていません。
『平家物語』には、語り本系と読み本系があり、これは語り本系です。印刷されたものを読むこともあるでしょうけど、本来は琵琶法師とかが語るのを聴くものです。「さんじゅうよにん」と語られたら、聞いている方としては、「三十四人」と理解するのか、「三十余人」と理解するのか、どちらなのでしょうか。
20年ほど前に購入した「dynabook SS SX/15A」には「Windows Vista」がインストールされていましたが、2017年にサポート終了となったので「NetBSD/i386」に入れ替えて使い続けてきました。メモリは4Gなので、32bit CPUとしてはフル実装ですが、HDDが60Gしかないので、窮屈です。換装しようにも、1.8インチHDDが使われているため、代替品を入手するのが困難です。
さらに昨今はソフトウェア側で32bit CPU対応を止めるものが多くなってきています。日常的に使用しているわけではないので、最新版を使いたいわけでもないのですが、利用可能なバージョンが古くて不便な状況に追い込まれてきました。
しかも、電源を入れても素直にOSが起動しない場合があります。そういう場合は、ノートPCごとを揺すってみたり、表面とか裏面から手で押してみるとかを繰り返すと、起動できるようになります。いったん起動してしまえば、動作中に落ちることはありません。大昔の家電製品は故障したら叩けば直ると（嘘か真か）言われていましたが、それに近いものがあります。
このままダマしダマし使い続けるのは可能だと思いますが、そろそろ代替品を探して、移行しようと思います。次もNetBSDにしようと考えています。新品である必要はないので、中古かジャンク品を入手しようと思っています。2万円くらいで入手できないかと思い探しています。通販でもよいのですが、現物を確認して買いたいところです。
ローカルにMH形式で持っているはずのファイルを確認したら、いろいろな意味で問題があることが分かりました。2000年前後のものなのですが、メールヘッダには「iso-2022-jp」とあるのに、本文を「nkf --guess」したら「EUC-JP」と訴えています。これだけなら変換すれば良いのですが、文字化けという意味ではなく、種々雑多な問題が潜んでいそうです。しかも、そのようなメールが9万ファイル弱あって、簡単には修復できそうもありません。
Geminiに相談したら、ファイルごとの情報を整理したCSV形式ファイルを作ってから、対処方法を考えるべきだとのアドバイスをもらいました。それでCSV形式ファイルを作ってみましたが、ここから問題のパターンを整理しなければなりません。
これまでCSV形式ファイルを調査するには、AWKなどのコマンドラインツールを駆使してきました。今回もそれでいこうと思ったのですが、ちょっとGeminiに相談したところ、「Miller」というツールを紹介してもらいました。パッケージから簡単にインストールできましたが、使い勝手が手強そうです。公式サイトから「Miller 6.18.1 Documentation」を見つけました。まずは、これを読んで勉強してみようと思います。
数年前から語り本系の平家物語を暗誦しようと思い、少しずつ覚えています。「祇園精舎」から始まり、「殿上闇討」、「鱸」、「禿髪」と進み、今は「吾身栄花」を覚えているところです。
ここには、「一人は、桜町の中納言重教卿の北の方にておはすべかりしが、八歳の時、約束計にて、平治の乱以後、ひきちがへられ、花山院の左大臣殿の御台盤所にならせ給ひて、君達あまたましましけり。」という一節があります。「花山院の左大臣殿」とは藤原兼雅のことです。二男一女をもうけたようですが、「君達あまたましましけり」というほどでもないかという気がします。
平清盛には18人の子がいたようですので、ここまでいれば「ましまし」という感じはします。現代では「マシマシ」と言うとラーメンの注文のようですが、ニュアンスは同じのように思います。
10年ほど前から、メールを読むのにGNUSを使ってきました。ここ最近になって（それでも今年とか、去年とかではありませんが）、サマリー表示が「[nobody](1970-01-01 09:00)(none)」のようになっているのに気づきました。当初は、これはGNUSのバグだと考えていたので、いずれバグフィックスされるだろうと思っていました。いつまで経っても直らないので、GNUSの利用者が少ないか、開発者が少なくて、問題が発覚しないか修正されないのかと、見当はずれなことを思っていました。いい加減に業を煮やしてGeminiに相談したところ、対策を編み出してくれました。
そもそもメールを読むのに、FreeBSDを使っています。プロバイダからfetchmailでローカルに取り込み、procmailで振り分けてから、GNUSで読んでいます。Geminiに相談した結果、fetchmailやprocmailの設定誤りが発覚しました。その対処を済ませたので、もう大丈夫だろうと思っていたのですが、相変わらず、同様の現象が発生します。Geminiに言わせれば、ヘッダが大きすぎるので、GNUSの解析が途中で打ち切られてしまうのが原因だろうと推測しているようです。そうなのかもしれません。試しにヘッダを加工して、大きすぎるエントリを削除してみると、うまく解析できているようです。そうであれば、ヘッダが悪い可能性は高いと思います。
しかしメールのファイルをWindows11上のThunderbirdで読ませてみると、別に問題が発生しないので、GNUS側でなんとかならないのだろうかという気になります。Geminiに相談を持ち掛けてみたのですが、いろいろと試してみましたが、どうにも解決に至りそうにありません。
GNUSに拘るわけではありません。しかしEmacs上で動くこと、MH形式ファイルを扱えることが必要です。この条件にあうのは、GNUS、Mew、Wanderlustが候補となります。しかし、もともとはWanderlustを使っていたのです。ところが2013年3月頃、emacs24でエラーが多発するようになり、GNUSに移行したのでした。しかしGNUSでのメール送信方法がわからなかったので、メール送信にはMewを利用してきました。
GNUSを諦めるとすると、MewかWanderlustが候補です。Wanderlustの使用を止めようと思った頃にもMewにしようかと考えました。しかしMewは、メールの未読管理ができなかったのです。つまりMewの管理外、すなわちprocmailで振分けられてしまうメールを、Mewは未読か既読か認識できなくなってしまうのです。それでGNUSを選択したのでした。
2013年3月以降GNUSを使ってきて、サマリー表示が変にならなければ、このままGNUSを使い続けていたところです。しかしそういうわけにもいかなくなってきたので、懐かしのWanderlustに復帰しようかと考え始めました。
いきなり移行してしまうのも性急に過ぎると思います。まずは、現状のGNUSを使い続け、その裏ではWanderlustを試行しようと思います。そしてWanderlustでも大丈夫だと確信できたら、その時はGNUSを諦め、Wanderlustに復帰することになります。
NHKのテレビやラジオは、ネット配信が行われています。視聴できるのは、テレビ（またはラジオ）で放送されてから1週間なのです。ただし注意が必要ですが、正確に言えば、視聴できるのは「本放送」から1週間です。「再放送」は関係ありません。
例えば「100分 de 名著」の場合、本放送は「毎週月曜 午後10時25分」で、再放送は「毎週金曜 午後３時５分」です。この場合ですと、本放送が終わってから1週間は見逃し配信がありますが、再放送は見逃し配信の期間に影響しないので、再放送からカウントすると数日間しかありません。
本放送とか再放送とか言う区分は、「放送」における区分に過ぎず、「ネット配信」とは別概念なのです。当たり前かもしれませんし、この違いは著作権の扱いによるものですが、少なからず専門的な概念ともいえるのではないかと思います。テレビやラジオを視聴している人にとって、それが本放送なのか再放送なのか気にしていないと思いますが、内部の放送関係者にすれば大問題なのです。だからこそ「見逃し配信はいつまで見られますか？」という問いに対して「見逃し配信は、放送の終了から1週間視聴できます。」と答えていますが、その真意は伝わっていないかもしれません。
視聴者からすれば、放送もネット配信も同じだと思っているのでしょうけれども、現時点では違うものです。しかしそれが未来永劫そうだとも限りません。未来は変わっていることを願いたいと思います。
SIMHのPDP-11エミュレータを利用し、PDP-11/40上で動作するUNIXv6について学ぼうと考えています。まずは「m40.s」のラベル「start」から起動するプロセスを見ていこうと思います。ここではMMUが無効になっていますが、管理レジスタを設定し、MMUを有効にするための準備をおこないます。
「mov $77406,(r1)+」のような箇所でMMUのレジスタに値を設定しています。ここでR1には「KISD0」が入っており、具体的には「172300」です。これは16bitアドレスとしての表現です。PDP-11/40のメモリ管理装置である「KT11-D」では、マニュアルの「Table 3-1 PAR/PDR Address Assignments」において「772300」のように定義されています。これは18bitアドレスです。ところがSIMHのPDP-11エミュレータでは、「17772300」のような22bitアドレスで参照しなければならないようなのです。
デバッガ機能を利用してメモリを参照した例を以下に示します。このように、16bitや18bitアドレスではMMUレジスタを参照できず、22bitアドレスで参照すると、格納されている値が参照できます。
Step expired, PC: 003370 (MOV #77406,(R1)+)
sim> s
Step expired, PC: 003374 (ADD R4,R2)
sim> e R1
R1: 172302
sim> e 172300
172300: 000000
sim> e 772300
772300: 000000
sim> e 17772300
17772300: 077406
ちなみに、CPUは次のように定義しています。
sim> sh cpu
CPU, 11/40, NOFIS, idle enabled, stability wait = 20s, autoconfiguration enabled, 256KB
エミュレーションするモデルを11/70としているのであれば、22bitアドレスでも納得するところです。しかし11/40として設定しているはずなの、22bitアドレスなのは、ちょっと不可解です。ただしSIMHが、そのような挙動なのは、そうなのですから、それを受け入れるしかありません。
