2024-12-21

Windows10の文字変換の反応が悪いが、辞書修復で解決

Windows10の文字変換が数日前から遅くなりました。現象としては、ローマ字入力で変換キーを押すと、変換結果が出るまでに1分ほどかかるようになったのです。Windows11にはアップグレードできないスペックのマシンなので、それほど速いマシンではありませんが、最近まで問題はありませんでした。

 

ネットを検索してみると、重いプロセスが動いているか、メモリ不足に陥っているのだろうという指摘が多いようでした。念のためにタスクマネージャーで確認してみましたが、リソースが不足していることはないし、CPUの利用率は数%程度です。おそらく原因は別のところにあると思いました。


ふと閃いたのは、辞書が壊れた(もしくは不整合状態になっている)ということでした。あらためてネットを検索してみると、IMEのツールバーから「プロパティ」を選択し、「辞書修復」を行えばよいようです。ところがIMEに「プロパティ」がないのです。その代わりに「設定」ならあるのですが、そこからメニューを辿っても「辞書修復」は見当たりません。

 

どうしたものかと、さらにネットを検索してみると、「IMEのプロパティがない!詳細設定がない!最短で元に戻す方法【Windows 10】」という情報がありました。この記事の手順に従うと、無事に「プロパティ」が出現し、「辞書修復」が見つかりました。

 

「辞書修復」を実行した結果、IMEの文字変換が異常に遅い現象は解消しました。何が原因となったのかは不明ですが、やはり辞書が壊れていたのでしょう。

2024-12-12

ε-N論法が腑に落ちない

放送大学教養学部で数年前に「入門微分積分('16)」の単位を取りましたが、ちゃんと理解したという実感が持てずにいたので、印刷教材を読み直すことにしました。第1章の例1.3では、a_n=1/nにおいてn→∞ならば0に収束することをε-N論法で説明しています。あっさり書いてあるのですが、どうもスッキリと腑に落ちません。

 

この問題はε-N論法について学ぶ際にはお馴染みの例題のようなので、Webを検索すれば多くの記事が見つかります。

 

ε-N論法は初学者の多くがつまずくところで、私も同様につまずいている訳です。Web上にある記事を幾つか読んでみましたが、特別に難しいことが書かれているわけではないと感じます。しかしながら、読んでみても、「?」という感じで、「!」と分かった気になりません。

 

この印刷教材に限りませんが、教科書を読み進める際に、分からなければ、とことん拘って、一歩一歩確実に先に進むというスタンスと、分からないところがあっても、とりあえず先に進んで、後でまた戻ってくれば良いというスタンスがあるようです。どちらも大切だと思うのですが、分からなくても先に進んだ結果として、単位は取得できたものの、理解できたという納得感のないままに今日に至っているのを考えると、あくまでも拘ってみようかと思っています。

iCalendar形式ファイルを使ってGoogleカレンダーに一括登録したいが、アラームが設定されてしまう

Windows上でSchedule Watcherというスケジュール管理アプリケーションを利用しています。これで登録してあるスケジュールをGoogleカレンダーにも一括して登録したいと思います。iCalendar形式ファイルを使えば、Schedule Watcher側でエクスポートしたファイルをGoogleカレンダー側でインポートできましたので、これで解決かと思いました。

 

問題なのは、Googleカレンダー側で勝手にアラーム設定されてしまうことです。Googleカレンダーの設定にある「通知設定」で「通知」を「OFF」にしてあるのですが、iCalendarファイルを読み込む際にアラームが設定されてしまうようです。Schedule Watcherが出力したiCalendarファイルには「アラーム」に関する情報は入っていないので、Googleカレンダー側で親切に(?)アラームを設定しているようです。

 

Googleカレンダーのようなアプリケーションを操作するために「Google Apps Script」というものがあるようです。これを使えば、おそらく対処できるのでしょう。これまでGASを利用したことがないので、ちょっと敷居が高いです。


Googleカレンダー側からiCalendarファイルをエクスポートしてみると、「アラーム設定」の情報は「BEGIN:VALARM」から「END:VALARM」の間にあるようです。このような情報は、もちろん、Schedule Watcher側でエクスポートしたiCalendarファイルには入っていません。Googleカレンダーが出力したファイルには「ACTION:DISPLAY」とあり、その他にも「TRIGGER」なども指定されています。もしかすると、Schedule Watcherが出力したiCalendarファイルを加工して、無理矢理「BEGIN:VALARM」~「END:VALARM」を付け加えれば、Googleカレンダーにインポートしても、勝手にアラームが追加されることはないかもしれません。

 

それでは「ACTION」に何を設定すれば良いのでしょうか。参照できる資料がわかりませんが、「ACTION:NONE」とかではどうでしょうか。試しに、Schedule WatcherがエクスポートしたiCalendarファイルをエディタで編集し、次のようなものを付け加えてみました。これをGoogleカレンダーでインポートしてみましたが、エラーが出ることもなく、勝手にアラームが設定されることもないようです。

BEGIN:VALARM

ACTION:NONE

END:VALARM


ワークフローとしては、次のようになると思います。この方法なら、スケジュールをSchedule WatcherとGoogleカレンダーで同期できそうです。GoogleカレンダーからSchedule Watcherへの同期は考えていないのですが、スケジュールを変更した際には再同期が必要になります。ただし以前にGoogleカレンダーに登録したスケジュールが残っていると、再同期することで重複が生じてしまうので、この問題を解決しておかなければなりません。これはGASを使わないと解決できなさそうです。

  1. Schedule Watcher側でエクスポート
  2. iCalendar形式ファイルを加工(WSL2のUbuntu上でsedでも使おうかと思います。)
  3. Googleカレンダー側でインポート

2024-12-10

国会図書館のOCRアプリ

国会図書館が2024年11月26日に「NDL古典籍OCR-Liteの公開について」を発表しました。Microsoft WindowsなどのPC上で古文書などの画像を解析し、崩し字を読み取ってくれます。画像中のどのあたりに崩し字があるのかは自動判別なので、認識対象とならない場合があります。さらに認識されたとしても、必ず正しい判断をするとも限りません。


いろいろと問題が無い訳ではありませんが、古文書を読み取る効率が上がるでしょう。これまでは、崩し字辞典のような参考書を駆使して、経験を積み、古文書を読み取っていました。それに対して、これを使えば、認識結果をもとにして、誤認識された箇所を修正していけばよいので、だいぶ楽になるはずです。

 

読もうとする古文書が有名ならば、このようなツールが無くても、既に史料集などに翻刻が掲載されている可能性があります。しかしマイナーな古文書を相手にする場合であれば、このようなツールが役立ちます。

 

便利な時代になったものだと思います。もし可能ならば、自分のマシンにインストールしなくても、画像をアップロードすれば処理してくれるようなWebサイトが登場すると、よりありがたいところです。

2024-12-09

Geminiアプリを使って外国語会話の練習をしたい

AndroidのスマホにGeminiアプリを入れています。これを使って外国語会話、特に英語の会話の練習をしてみたいのです。

 

Geminiを利用する状況としては、何か解決したいことがある場合が多いとは思います。しかしGeminiは「雑談も歓迎」とのことでした。そういうことであれば、Geminiアプリ相手に英会話の練習ができるかもしれません。こちらの発音が下手でGeminiに通じないとか、Geminiの応答を聴き取れないなどのドタバタがあるかもしれません。しかし現実の人間相手に会話練習をするよりは、発音が下手でも、聴き取れなくても構わないし、同じ発言を何十回繰り返しても相手が呆れないだろうという心理的な安心感もあります。

 

試しに英語で話しかけてみたら、英語で応答しました。しかし、文にならず、単語だけを発音すると、日本語として解釈されるようです。自動判別なのでしょうが、基本は日本語として受け付けるのでしょう。これを英語だけを受け付けるように設定できればよいのですが、方法がわかりません。アプリの「設定」には、それらしい設定項目がありますが、「日本語」以外に切り替えられません。

 

このようにトラブルを抱えていますが、Geminiアプリを使って英語で雑談することは、できそうです。

2024-12-04

『Operating Systems: Three Easy Pieces』という書籍があるらしい

AbeBooksという世界中から古書を購入するためのサイトがあります。時々利用していますので、キャンペーンとかお勧め情報のメールが届きます。最近届いたメールには『Operating Systems: Three Easy Pieces』という書籍が掲載されていました。

 

書名を見て興味がわいたので、どのような書籍なのかWebで調べてみると、なかなか面白そうです。この書籍の公式サイトと思われるところを見つけました。しかも和訳したファイルが「"Operating Systems: Three Easy Pieces"の日本語翻訳」として公開されていました。これから読んでみようと思います。

2024-12-03

2025年春から「のぞみ」の自由席が2両になるとの報道

Webで「東海道・山陽新幹線「のぞみ」指定席を拡大へ!自由席は減少 JR東海とJR西日本が発表」とのニュースが流れました。最近は、超繁忙期には「のぞみ」が全席指定席ですが、基本的には、「のぞみ」の自由席は3両です。これが2025年春から2両に減り、その分を指定席車両とするようです。

 

歴史的には、「のぞみ」が東海道新幹線に登場した当初は全席指定席だったこともあり、「のぞみ」の自由席は全廃して、全席指定席に戻す「べき」との意見もあるようです。事前に予定がはっきりしているなら指定席を取れますが、そうでない場合には自由席を利用することになります。もし「のぞみ」が全席指定席になってしまうと、「ひかり」か「こだま」を使うしかありません。

 

東海道新幹線の運行パターンは、ほとんどが「のぞみ」で、「ひかり」や「こだま」は1時間に1本くらいしかありません。そうなると、「ひかり」の自由席を利用するとなると、運が悪いと1時間くらい待つことになってしまいます。「ひかり」は「のぞみ」よりも停車駅が多いので時間がかかりますし、トータルの移動時間(乗車時間と待ち時間の合計)は、「のぞみ」の自由席を利用する場合よりも大幅に長くなってしまうでしょう。

 

現行の運行パターンよりも「ひかり」の1時間あたりの本数が増えるなら、「のぞみ」を全席指定席にするのも仕方ないと納得します。しかし運行パターンが現行のままなのに、「のぞみ」が全席指定席になるのは困るところです。

2024-12-02

2026年3月をもって「往復乗車券」を廃止との報道

Webで「旅の強い味方? JR「往復乗車券」「連続乗車券」廃止へ 発券数減少に伴い」というニュースが流れました。切符としての「往復乗車券」を発行しないだけではなく、「往復割引」も行わないとの事です。往復割引の割引が適用されてきた利用者だけの問題かもしれませんが、実質的には値上げされたのと同等の影響を受けます。

 

先日発表された青春18きっぷのリニューアルや、何年も前から報道されている地方ローカル線存族などと同根の問題ではないかと思います。JRにとって利用して欲しいのは、新幹線や有料列車などであると考えているのかもしれません。地域に密着した公共交通機関としての役割は、余裕があればやるかもしれない(でも赤字で余裕がない)という程度の認識なのではないかと疑ってしまいます。

2024-11-25

映画『室井慎次 生き続ける者』

2024年11月15日から公開されている映画『室井慎次 生き続ける者』を観てきました。先月公開された『室井慎次 敗れざる者』の後編という位置づけです。物語がどのように展開するのか楽しみでした。観ていて、心が重くなるシーンや、悲しいシーンもありましたが、最後は希望があったと思います。

 

 観た感想は、前回同様、良かった、面白かったです。

 

「踊る大捜査線」というヒット作品と同じタイトルを冠しているので、そのイメージに拘ると、「期待はずれ」と感じるかもしれません。まさに、そのような感想を持つ人もいるようです。どのような感想であっても、それを他人がどうこう言うことはできないでしょう。むしろ、1990年代後半に大人気となった作品が、30年後には、このような作品に繋がり、さらに今後も続いていきそうな気配を感じると、これからの希望が湧いてくる気持ちです。

 

今年春に突然発表された作品は、ひとまず終わります。次の作品が、何時公開になるのかは、何もわかりません。しかしその時を楽しみに待ちたいと思っています。

Windows上の「Schedule Watcher」とAndroid上の「Googleカレンダー」との同期

これまでスケジュール管理は、Windows上で「Schedule Watcher」を使ってきました。Version 5.71.210426を利用していますが、何年も前から更新が出ていません。それでも凝ったことをしていないので、今後も使っていくつもりです。

 

WindowsはデスクトップPCで使っているので、外出時に参照するため、1ヵ月分のスケジュールを印刷し手帳に挟んで持ち歩いています。もしスケジュールが追加されたら、ひとまず紙に追記しておいて、帰宅してからSchedule Watcherに登録するようにしています。さらに旅行に出かける際などには、日程分を紙に印刷して、備忘のために持参するようにしています。


ガラケーからスマホに切り替えて以降も同じような運用をしていますが、若干変わったこととしては、紙に印刷していたものを、PDFに変換するようにして、そのファイルをスマホに入れておくことでしょうか。

 

スマホはAndoroidなので「Googleカレンダー」が入っています。スケジュールを二重管理するのを避けるため、これまで利用していませんでした。ふと考えてみたら、Windows上の「Schedule Watcher」のスケジュールをスマホ上の「Googleカレンダー」に入れることができれば、わざわざ紙に印刷したり、PDFに変換してスマホに置いたりする手間が省ける気がします。

 

調べてみると、Schedule Watcher側でiCal形式でスケジュールをファイルに落とせば、Windows上のGoogleカレンダーで取り込むことができるようです。そしてGoogleレベルで同期を許可しておけば、Windows上のGoogleカレンダーとスマホ上のGoogleカレンダーが同期されます。このようにすることで、若干手間はかかりますが、Windows上のSchedule Watcherで管理しているスケジュールを、スマホ上のGoogleカレンダーで参照できるようになりそうです。

 

これで一件落着と言いたいところですが、もしWindows上でスケジュールを変更した場合、どのようにスマホ上に反映させれば良いのかという問題があります。単純にiCal形式ファイルで同期させると、過去のスケジュールが消えないので、重複してしまいます。同期させる前に以前のスケジュールを一括削除したいところですが、そのような機能がGoogleカレンダーには無いようです。


ネット検索してみたところ、GASでロジックを組めば簡単だという情報を得ました。おそらくこうするしかないと思います。しかし、これまで使ったことのない機能なので、ちょっと敷居が高いところです。慣れの問題かと思うので、練習してみようと思います。

2024-11-23

『氏名の誕生』に続いて『壱人両名』を読む

尾脇秀和著『氏名の誕生』をよみ、その内容といい、語り口といい、とても良かったので、『壱人両名』も読んでみました。とても面白かったと思います。

 

テレビなどの時代劇をみて、脚色はあるだろうけど、江戸時代がわかっている気になっていました。しかし江戸時代の「現実」は、そんな思い込みを打ち破る世界だったようです。

 

歴史を学ぶ際には、今日の視点で見るのではなく、当時の視点で見るようにせよと教わります。これまた、わかっているつもりでしたが、身についていなかった事を思い知りました。

 

今は『お白州から見る江戸時代』を読んでいます。この本からも多くの事を学べそうです。

バックを前に「背負う」

混雑したバスや電車に乗っている場合、 バックを前に抱えるのが望ましいだろうと思います。しかし口が滑って「バックを前に背負う」と言ってしまう人がいるようです。


背中に負うから「背負う」のであって、前に負うのは「背負う」ではないだろうと言うのは正論に過ぎるかもしれません。


言葉は変化していくものです。いつの日か、「背負う」に「背中」に負うと言う含意が消える時がくるのではないでしょうか。

2024-11-20

餃子の無人店舗が少なくなっている気がする

数年前には雨後の筍のように増えていた餃子の無人店舗が減少している気がします。完全に閉店して設備が撤去されたところもありますし、閉店はしていないものの維持されていないように見える店舗もあります。もちろん閉店せずに、従前どおりに営業を続けている店舗だってあります。

 

Webには「「無人餃子」閉店ラッシュの中、なぜスーパーの冷凍餃子は“復権”できたのか」という記事がありました。個人では近所様子を確認する以上のことはできないので、このような記事が出るという事は、薄々感じていた個人的な感覚が裏付けられた気がします。

2024-11-18

Webブラウザに内蔵されたPDF閲覧機能の不具合

WebブラウザにはPDF表示機能が内蔵されていますが、PDFによっては正常に表示されないことがあります。

 

メインで使用しているのはFirefoxで、現在のバージョンは132.0.2です。数年前に、FirefoxだとPDFが正常に表示されないことに気づきました。そのPDFをAcrobatとか、ChromeやEdgeで表示させると問題ありませんでした。少なくともPDF側の問題ではなさそうです。となると、Firefox側の不具合ではないかと思いました。そのうちに修正させるだろうと思ったのですが、今になっても解決していません。


Firefoxをメインで使っているので、PDFもFirefoxで閲覧したいところなのですが、不具合があるなら仕方ありません。そこでPDFを閲覧するときだけはEdgeを使うことにしました。それで問題は解決したのですが、つい最近になってEdgeでもFirefoxと同様の不具合が生じるようになってしまいました。今問題になっているEdgeのバージョンは、131.0.2903.51です。数か月前までは問題なかったので、最近の更新が原因ではないかと想像します。もしかすると、そのうち修正されるのかもしれません。


Firefoxがダメで、Edgeもダメになったので、PDFを閲覧するにはChromeを使うことになりました。現在使っているChromeのバージョンは、131.0.6778.70です。今のところPDFは正常に閲覧できています。


そもそもFirefoxで何故閲覧できないのか原因がわからないのですが、数年経っても修正されていないということは、Firefox開発側では不具合と考えていないのかもしれません。また私以外でFirefoxをPDF閲覧に使用している人(が居るならば)は、困っていないのでしょうか。

2024-11-14

氏名≠姓名≠名前

ちくま新書から出版されている『氏名の誕生』(尾脇秀和)という本を近所の図書館で見かけてので、借りて読んでみました。私たちが普段から「名前」とか「氏名」とか「姓名」とか、別段区別することなく使用している言葉が、歴史的な変遷を経ていることが、本書では詳しく描かれています。これまでは理解が曖昧でしたが、よく分かった気がします。


テレビなどの時代劇を視ていると「大岡越前守」のように人名を表しますが、学問の世界では「越前守」とは「名前」だと考えるそうです。この段階で「?」なのです。つまり現代において「石破総理大臣」と表現しても「総理大臣」というのは「名前」ではないのです。江戸時代は「越前守」が名前なのか?「忠相」が名前ではないのか?と思うのです。

 

このような疑問を解消してくれるのが本書でした。江戸末期の事情が明治維新で如何に変化し、今日に繋がる「氏名」として「誕生」したのかについて、詳しく語られます。

 

図書館で借りて、読み終わったので返却しますが、手元に置いておきたいと思うので、購入しておこうかと考えています。

2024-11-11

タナ・フレンチ『捜索者』を読了

映画「室井慎次 敗れざる者」のパンフレットの中で、亀山プロデューサのコメントで次のようなことが書かれていました。

そこで君塚さんにタナ・フレンチのミステリー小説「探索者」の話をしたんです。警察を辞めた男が山の中の小さな村に移住して廃屋を修繕しつつ暮らす話。あの小説がとても良かったので、あんな感じはどうだろうと君塚さんと話し合ったのが今の形の原形です。

 

この小説に興味を覚えたので近所の書店を探してみたら置いていたので買ってみました。ハヤカワ文庫ですが、700ページ弱もあるし、1,500円以上もするので文庫とはいえ安くはありませんでした。普段は小説をあまり読まないし、ストーリーに馴染めるか確信がなかったので、若干躊躇するところはありました。


読みはじめてみると、物語の波にうまく乗れた気がしました。主人公の感情に共感できるところもできないところもあり、登場人物に感情移入できたわけではありませんが、次はどうなるんだろうという興味が読み進めるエネルギーになっていました。読み終えて、ハッピーエンドではありませんが、心が重く沈んだ気持ちとなる訳ではなく、心地よい読後感となりました。

 

「訳者あとがき」によれば、『初秋』(ロバート・B・パーカー著)という作品があるようです。この本にも興味を持ったので、探して読んでみようかと思います。

2024-11-05

世界史≠Σ各国史

図書館で『東大連続講義 歴史学の思考法』という本を見かけたので、読んでみました。何か特定の歴史的事項について書かれている訳ではなく(例示のために具体例は出てきますが)、 歴史学の「思考方法」を提示するのが目的のようです。本書の「はじめに」で以下のように書かれていますが、その通りだと感じました。

だから本書は、いつ読みはじめても遅いということはないし、一度きりでなく、二度三度とくり返しひもといていただけるだけの不変的価値があると確信している。


第4章の「人びとの「まとまり」をとらえなおす―歴史の中の国家と地域」では、以下のような問いかけが投げかけられています。

 人の「まとまり」の最大単位が、世界である。では、その世界の歴史は、どうやってとらえられるだろうか。

 

日本の学校教育では、日本史と世界史という枠組みになっていますし、その世界史というのが世界各国における自国の歴史を集めたものになっているようです。このような理解を本論では「各国史的理解」と呼んでいます。つまり「一国史」を集めると「地域史」になり、「地域史」を集めると「世界史」になるという理解のことです。しかし本論で「各国史的理解の問題点」で書かれているように、多くの限界や問題が潜んでいます。

 

考えてみると、これは世界史だけではなく、日本史にも言えることだと思います。専門的と言えるかもしれませんが、行政組織がつくる「自治体史」と呼ばれる書籍があります。都道府県だったり市町村だったりしますが、発行時点における行政区域内の歴史を語るのですが、現在の行政区域に合わせて過去の歴史がすすんでいく訳ではありません。「市町村史」を集めると「都道府県史」になり、「都道府県史」を集めると「日本史」になる訳ではありません。


これを数式で表すと、次のようになるのではないかと思いました。

世界史≠Σ各国史

日本史≠Σ自治体史


2024-11-03

復活したブラタモリ

2024年3月に突然のように終わってしまった「ブラタモリ」が、2024年11月に復活しました。これはレギュラー番組ではないので、次回の放映があるのか否か不明です。さらにテーマソングやナレーションも変わったので、これまで慣れ親しんだブラタモリとは違い、違和感を覚える人もいるようです。いっそのことタイトルも替えてしまってもよかったのではないでしょうか。「シン・ブラタモリ」とか、「ブラタモリ シーズン2」とか、いっそのこと「帰ってきたブラタモリ」ではどうでしょうか。


レギュラー番組では、テーマソングは井上陽水の「女神」でしたが、今回は小沢健二の「ぼくらが旅に出る理由」に変わりました。ナレーターは「草彅剛」から「あいみょん」に変わりました。同行するNHKのアナウンサーは、レギュラー番組でも定期的に交替していましたので、今回新人に変わりましたが違和感はありませんでした。

 

レギュラー番組終了後のブラタモリは、不定期番組なので、次が何時なのか全く分かりません。今年度中に次があるのか、一年後なのか、何も決まっていないだろうと思います。そうであったとしても、今回同様、二夜連続とか三夜連続のように、集中して放映されるだろうと思います。

 

もしかすると、次が何時になるかわからないブラタモリのために、NHKとしても同行するアナウンサーを固定的に指定しておくことは出来ないかもしれません。レギュラー番組であれば、毎週のように日本各地に同行することになるので、特定のアナウンサーを指名しておく必要がありますが、不定期番組(しかも次が何時なのかわからない)となると、毎回「(ほぼ)はじめまして」か「お久しぶりです」状態になってしまうでしょう。不定期番組である「ブラタモリ」が放映されるたびに、毎回異なるアナウンサーが登場することになるかもしれません。もっと想像をたくましくするなら、ナレーターも毎回変えても構わないのではないでしょうか。さらにはオープニングテーマを毎回変えても構わない気がします。

 

「ブラタモリ」が「ブラタモリ」である所以は、タモリが日本各地でブラブラと散歩するところにあります。オープニングテーマであったり、ナレーターであったり、レギュラー番組で馴染んだものはありますが、それはブラタモリのコアな部分ではないと思います。しかし「ブラタモリ」の主役が他の芸能人に変わってしまったら、それは「ブラタモリ」ではないでしょう。


不定期ブラタモリの次回作品がいつになるのか分かりませんが、楽しみにして待ちたいと思います。

2024-11-02

「ググる」から「ジェミる」へ

検索エンジンとしてGoogleが搭乗したのは、2000年前後のことです。当時は様々な検索エンジンが群雄割拠していましたが、次第にGoogleの独り勝ちとなってきました。20世紀には、調べ物をする際には、図書館で書籍を探したりするのが一般的でした。しかし21世紀には、Googleのような検索エンジンを使うのが当たり前(良い事かと言えば、必ずしもそうとも言い切れませんが)となっています。そのあげくには「Googleで検索すること」を「ググる」と呼ぶようにさえなっています。

 

ここ数年は、ChatGPTのような「生成AI」と呼ばれる技術が大流行しています。このような新技術が登場すると、その新規性を理解するのは容易とは言えません。まず最初は、過去の技術の延長線上で理解しようとします。具体的には、「ググる」ように利用しようとするのです。

 

ChatGPTを「より新しくなった検索エンジン」と理解するのは、全く間違っているとまでは言えませんが、それでは生成AIの能力を引き出せません。しかも生成AIにはハルシネーションと呼ばれる「もっともらしい嘘」をつく特徴があるので、Google検索のつもりでChatGPTを使うと、「この嘘つきめッ」と怒り心頭となるでしょう。

 

要するに生成AIは「より進化した検索エンジンではない」と思うべきなのです。生成AIは生成AIであって、それ以外ではないのです。生成AIの特徴を生かすにはどうすれば良いのかは、個々人が見出していくしかないのではないかと思います。

 

新しい技術が登場すると、「それは一体何者なのか?」という混乱があります。過去に「オブジェクト指向プログラミング」が一般化しようとした頃、具体的にはC++が一般化してきた1990年前後を思い出すと、「オブジェクト指向でプログラミングするとは、具体的に何をすれば良いのか」ということを問う人たちが少なからず存在しました。オブジェクト指向プログラミングにすぐに馴染む人もいましたが、いつまでも腑に落ちない人も少なくありませんでした。

 

また別の事例として、MS-DOSのような単純なシングルタスクOSから、Windows 95/NTのような本格的なマルチタスクOSに移行しようとした際にも、それほど表に現れなかったかもしれませんが、その趨勢に拒否感を覚えた人が存在しました。彼らは「個人の作業というものは、他人はいざしらず、自分としてはシングルタスクで十分である。よってマルチタスクOSのような複雑なものは、自分には必要ない」と主張していました。それが本心なのか否かは、今となっては不明ですが、少なくとも「本格的なマルチタスクOS」が動作するマシンは、当時としては多くのリソースを必要としたので、高価なマシンが必要となるので、そのような金銭的な負担を負えないという意識が隠れていたのかもしれません。


生成AIは、ChatGPTだけではなく、GoogleにはGeminiがあります。他にも様々なものがあり、Google検索のようなデファクトスタンダードとして何が現れるのかは、わかりません。仮にGeminiが主導権を握ったとして、「Geminiを利用すること」を「ジェミる」と表現する時代が、もうすぐ来るのでしょうか。

ホームベーカリーの過発酵と発酵不足

以前からホームベーカリーでパンを焼いています。基本的には食パンを焼くだけで、凝ったことはしていません。朝食で食べられるように、前夜にセットして、明け方に焼きあがるように設定しています。発酵したり焼き上げるのは、深夜の時間帯ですから、その時の気温によって、過発酵になったり発酵不足になったりします。

 

夏場は過発酵になることがあります。過発酵になると、焼き終わってホームベーカリーの蓋を開けた瞬間に、あまりの大きさに驚きます。大きくなったのは見かけだけです。投入した小麦粉は250gですから、膨らんでいるので大きく見えるにすぎません。

 

気温が下がってくると、過発酵となることはなく、むしろ発酵不足となりがちです。焼き終わってホームベーカリーの蓋を開けると、ほとんど膨らまずに焼きあがった小麦粉のカタマリが底の方に集まっているのが見えて、がっかりします。それでも春期や秋期なら、多少は膨らみますが、厳冬期になると全く膨らまないこともあります。いずれにせよ、投入した小麦粉は250gですから、膨らんでいないとしても、小麦粉が何処かに消えたわけではありません。

 

膨らみすぎず、かと言って膨らみが足りないこともない、適正な食パンを焼き上げるには、何か出来ることがあるのでしょうか。パン工場などであれば、厳密に温度を制御できるのだと思いますが、ホームベーカリーでは、「どうなるかは、焼きあがってからのお楽しみ」となるしか仕方ない気がします。

2024-10-30

福井県立図書館の『100万回死んだねこ』

講談社文庫の巻末にある広告ページを見て『100万回死んだねこ 覚え違いタイトル集』という新刊が出ていることを知りました。簡単な説明しか書かれていませんでしたが、面白そうだったので、購入してみました。早速読んでみましたが、とても面白かったです。私は自宅で読みましたが、電車の中などで読むと、笑いを堪えるのに苦労するだろうと思います。

 

そもそも『100万回生きたねこ』という有名な絵本が存在しています(僕自身は読んだことがないのですが)。それを読もうとして図書館を訪れた利用者が、正確な書名を失念したため、ついうっかりと「『100万回死んだねこ』貸してください」と尋ねてしまったという逸話から、類似した事例を集めた書籍です。

 

いろいろな事例があるもんだと感心します。しかし本書では、次のように書かれています。

私たちはクイズ王ではないので、「ラムネかサイダーみたいな名前の新人作家」→「はい!清涼院流水ですね!」とすぐ正解がだせるわけではないのです。

 

これは全くその通りなのでしょう。図書館の方々のご苦労が偲ばれます。すぐに見つかれば良いでしょうが、実際には、いろいろな質問を重ねながら、探していると思われる書籍を見つけ出していくようです。


直ちに探している書籍にたどりつけるとはかぎりません。例えば、以下のように本書で書かれている事例は、よく目的の書籍にたどりつけたものだと驚きます。

昔からあるハムスターみたいな本を探してるんだけど・・・・・・

 

ここで探していたのが『ハムレット』だった(と思われる)との事ですが、これは相当難しかったんじゃないかと思います。答えがわかってしまえば、「ハムレット」と「ハムスター」は語感が似ているといえば似ている気がしますが、なかなか思いつくものではないと思います。

2024-10-29

蒼天

普段の筆記用具として万年筆を使っています。万年筆といえばブルーブラックだろうと考えていますが、その他にも、赤色とか青色なども使いたいと思っています。赤色としては「色彩雫」の「山葡萄」を使っています。

 

これまでは、青色に特化したインクは使っていませんでした。青色インクを使わずに、どちらかというと「青色っぽい」ブルーブラックを使っていました。万年筆のインクとして「ブルーブラック」は、各社から出ていますが、微妙に「黒色っぽい」ブルーブラックとか、微妙に「青色っぽい」ブルーブラックなど、個性があるように思います。そう考えてきたのですが、「ブルーブラック」は結局のところ「ブルーブラック」であり「青色」ではないので、明確に「青色」をうたうインクを買ってみることにしました。


四季織」には青系のインクは幾つかあります。濃い青色だったり、水色のようだったり、様々なのですが、見本に現れる色と現実に書いてみた色は違うおそれがあります。結局「蒼天」を買ってみました。

2024-10-24

2024年冬からの「青春18きっぷ」

2024年10月24日にJR各社から「2024年冬の青春18きっぷ」に関するアナウンスがありました。いくつかの変更点がありますが、従来と最も異なるのが、「連続した数日間」に限定されたことでしょう。


これまでの青春18きっぷは、使用期間中であれば「連続した」という制限がありませんでした。このため様々な利用方法がありましたが、これが出来なくなります。

  1. 大学生などが夏休みや冬休みなどに実家に戻る際に、1日かけて帰省し、しばらく実家にいて、また1日かけて下宿先に戻るというような、「非連続的」な使い方ができていました。
  2.  1枚の青春18きっぷで、5人まで同時に使用できたので、グループで小旅行をすることができていました。
  3. 学生に限りませんが、移動と滞在を繰り返すような気ままに数週間かけて旅するようなことができていました。

 

2024年冬の青春18きっぷでは、このようなことができなくなります。連続した数日間に限定されることで、移動する手段としての切符という存在にすぎなくなると思います。「5日間連続」の他に「3日間連続」が設定されたのは、悪くないとおもいますが、「青春18きっぷ」の基本ポリシーが大きく変わってしまった事は否めません。

 

どうせなら、さらに「1日間限定」の青春18きっぷも用意してくれると、有り難いところです。値段は、「5日間連続」の20%なら言うことなしです。でも40%とかになってしまうくらいなら、利用する気にはならないでしょう。

2024-10-20

『「線」と「丸」を引くだけで、英語は一気に読めるようになる』を買ってみた

Webの「【毎日書評】英語の仕組み・日本語との違いを知れば、英文はスラスラ読めるようになる」という記事を読みました。英文の構造というと、もっとも基本的なのが中学英語で習った五文型ですが、現実の英文には様々な修飾部分が付け加えられているので、シンプルなSVとかSVOだけで済むことはあまりありません。

 

日本語の文の構造と、英語の文の構造は、対極にあるとまでは言いませんが、大きく違います。日本人が英文を読む時には、どうしても日本語に慣れている日本人の発想を背景にして読もうとするので、英文を読むのは苦行に近い努力が必要となります。本書で書かれているような事柄は、英文に親しんでいる人であれば、意識しているか無意識なのかは人それぞれかもしれませんが、既に身につけているのでしょう。

 

中学校以来の学校教育における英語学習では、五文型とか、時制とか、文法項目を個別に扱っていくことで、最終的には「これで英文が読めるようになったでしょう?」となるのが目標のようです。それが十分に成果をあげているなら、「日本の英語教育は何を間違えているのか」のような議論が、これほど活発になることはないでしょう。


本書が文法事項を軽視することを推奨しているわけではありません。僕自身としても、文法事項を軽視すべきだという意見ではありません。そうであっても、本書で説明されるようなアプローチで英文を理解することは大切だと感じます。近所の書店で早速購入してみたので、このアプローチに習熟してみたいと思っています。

2024-10-15

映画『室井慎次 敗れざる者』

2024年10月11日から上映されている映画『室井慎次 敗れざる者』を観てきました。踊る大捜査線のシリーズとしては、2012年の映画『踊る大捜査線 THE FINAL 新たなる希望』で終わったと思っていたので、今回の作品が発表されたときは驚きました。

 

この作品を観た感想としては、面白かった、良かったという一言(二言?)です。

 

最初にテレビドラマとして作られた時からは30年ほど過ぎていますし、当時出演していた俳優が亡くなってしまっていることもあり、その続編として東京の所轄警察署の若手が活躍するというスタイルは無理でしょう。今回の作品は「室井慎次」を表に出しており、これまで数々のスピンオフ作品に似たスタイルではありますが、正統な「踊る大捜査線」の後継作品だと思いました。

 

この作品は、発表当初から「室井慎次 敗れざる者」と「室井慎次 生き続ける者」の二本公開となっているので、ひとつの作品の前編と後編のような関係になっています。「踊る大捜査線」シリーズが所轄の若手刑事が警察組織の中でもがく姿をコミカルに描いていたのとは対照的に この作品は、同じ出演者を揃えながらも、違う世界を描くことに成功していると思います。

 

来月は後編である『室井慎次 生き続ける者』が公開されます。今から楽しみです。

2024-10-13

PDP-11 Architecture Handbook

PDP-11/40上で動作するUNIX V6のカーネルについて学ぶための資料として、よく言及されているのが『pdp11/40 processor handbook』です。これは1972年に発行されたもので、PDP-11/40について知りたいならば、まずこの資料から始めるのが良いだろうとは、私もそう思います。しかしこの資料だけで十分かと言うと、そうでもないと思います。周辺機器についての資料も必要になので、それらに関する情報を収集しなければなりません。

 

しかしPDP-11について更に理解を深める必要があるのではないかと思います。UNIX V6はPDP-11/40上で動作しているので、PDP-11の他のモデルについて知る必要がある訳ではないかもしれませんが、どうせ学ぶならPDP-11全体について理解しておくのも、面白いのではないでしょうか。

 

そういう目的にピッタリなのが『PDP-11 Architecture Handbook』です。これは1983年に発行されたようです。このような資料が存在したことは最近まで知らなかったので、「Processor Handbook」というキーワードで検索し、PDP-11/40だけではなく、PDP-11/45やPDP-11/70以外にも、PDP-11/35とかPDP-11/04などの資料も見つけました。それはそれで興味深いのですが、このように個別のモデルの資料を集めていても、PDP-11の全体像が見えてこないのです。諺の「木を見て森を見ず」のようになってしまうのが不満でした。

 

そういう意味で『PDP-11 Architecture Handbook』は、PDP-11の全体像を知るのに便利です。これが発行された1983年以降にもPDP-11の新モデルが登場するので、完全な意味での全体像にはなっていませんが、何も無いよりはずっとマシです。

 

「APPENDIX B PDP-11 FAMILY DIFFERENCES TABLE」というものがあり、PDP-11の個々のモデルの相違点が一覧表になっています。その違いを云々するようなところまで理解するのは遠い目標ですが、このように整理されているのは有り難いことです。

2024-10-08

PDP-11のPDRに含まれるEDビットの挙動

PDP-11/40上で動作したUNIX V6のカーネルを学ぶため、PDP-11について調べています。調べることは多岐にわたりますが、メモリ管理について学んでいるところです。メモリ管理はPARとPDRで挙動を制御しています。そこでPDRのビット3にはED(Expansion Direction)が存在し、これは管理されているメモリ領域の割り当てる方向を決めています。


『PDP-11/40 processor handbook』では「CHAPTER 6 MEMORY MANAGEMENT」に説明がありますが、説明は8行しかなく、簡単にしか書かれていません。これだけの説明でも問題ないかと思いますが、理解を深めるには、読み手側に何らかの努力が必要になると思います。


PDP-11/40のメモリ管理モジュールはKT-11Dらしいのですが、『KE-11D MEMORY MANAGEMENT OPTION USER'S MANUAL』という資料を発見しました。この資料の「CHAPTER 3 OPERATION AND PROGRAMMING」を見ると、「3.5.2.2 Expansion Direction(ED)」として詳しく書かれています。しかも「Figure 3-7 Example of an Upward Expandable Page」と「Figure 3-8 Example of a Downward Expandable Page」として図が示されていて、より理解しやすくなっています。


カーネルにおけるメモリ管理は、OSごとに実装がことなると思います。しかしPDP-11/40上で動作させるなら、そのメモリ管理は、PDP-11/40で出来ることに制約を受けることになるはずです。そういう意味でも、PDP-11/40のメモリ管理について理解を深めておくことは、UNIX V6のカーネルを学ぶ上での基礎知識であるはずです。

2024-10-04

タンブラーを再塗装して完成

タンブラーを再塗装する前の下地処理を済ませたので、最終段階として仕上げの塗装をおこないました。使用したのは「ヌーロスプレー」のパールグレーです。

 

今回の塗装に限らず、塗装の際は一気に仕上げようとすると綺麗に仕上がりませんから、何度かに分けて色をのせていくことになります。頭では理解していたのですが、実際にやってみると、気泡がついたり、塗料が垂れてしまった箇所がでてきました。乾燥してから耐水ペーパーで平滑にして、再度塗装します。この手順を何度か繰り返しました。よく見れば気泡の跡があったりするのですが、これもDIYの味わいというところでしょうか。

 

塗装を済ませたことで、綺麗になったことは間違いありませんが、イラストも何も入っていないので殺風景です。数年前に作ったデザインの文字などを流用し、「はがきサイズのプリンタラベル」に印刷したものを貼りつけました。これでオリジナルのタンブラーの完成です。

 

初めての経験なので、いろいろと失敗したところもあります。次に挑戦する時は、今回の経験が活きるでしょう。

2024-10-03

ハルシネーションを許容した生成AIの活用方法とは何なのだろう

以前は何かというとChatGPTをもてはやす風潮があったように思います。それと同時にChatGPTを断固拒否する意思を固めた人もいたようです。ChatGPTを諸手を挙げて歓迎する立場と、強烈に拒否する立場の他に、ChatGPTが良いのか悪いのか分からないけど使ってみたい(または、使ってみた)けど何か嬉しいのか分からないという立場も少なくなかったと思います。


Googleが登場した当時を思い出すと、キーワードを列挙すると知りたい情報(に近いもの)が得られるというのは、それ以前の情報検索では出来なかったことでした。同じことをChatGPTに求めようとすると、肩透かしをくらうことになります。ChatpGPTの場合は、Google検索のようにキーワードを並べるのではなく、プロンプトを与えることになります。それは使い方の問題にすぎませんが、ChatGPTの応答はGoogle検索とは違い、けっこう正直に(またはアッサリと)「わかりません」と返答します。それはプロンプトの与え方に不備があったせいかもしれないので、工夫すれば何かしらの応答が得られるかもしれません。しかし応答があったからと言って喜んでいられないのは、ChatGPTのような生成AIには「ハルシネーション」という「もっともらしい嘘」をつく可能性があるからです。

 

ChatGPT以外にも生成AIが登場しています。GoogleにもGeminiがあります。ちょっと使ってみたところ、やはり「ハルシネーション」に遭遇しました。例えば、「UNIX以外のPDP-11上で動作するOSを5つ教えてください。」とプロンプトを与えたところ、その回答の中に「MINIX」がありました。MINIXは元々IBM PC上で動作し、その後他のアーキテクチャでも動くようになったようですが、何が悲しくてPDP-11上で動かさなければならないんだろうと思います。


このように生成AIを使う上でハルシネーションは避けられません。その上で、応答結果を鵜呑みにせず、別途裏付けをとるようにするのが正しい道だと思います。それはその通りなのですが、もうひとつの可能性があるような気がします。真偽が厳格に定まる場合にハルシネーションが問題になります。しかしハルシネーションは、見方を変えれば、斬新な発想とも、既存の常識を超えた思考ともみなせる場合があると思います。真偽を云々するのではなく、正解とか間違いとかを気にせずブレインストーミングをおこなうような状況を生成AI相手におこなうことを考えてみれば、新しい可能性を得る手段を手に入れた気がします。


Geminiに「雑談の相手をしてくれますか」とプロンプトを与えたら、「喜んで」と応えてくれました。Google検索は、どこまで行っても検索エンジンにすぎず、雑談相手にはなりません。ここに生成AIの可能性を見た気がします。

Dunkin'やStarbucksとミスタードーナツ

the Japan Times alphaの2024年9月27日号のLife&Culture欄には「Campbell wants to say goodby to the 'soup' in its name. It isn't the first to make such a change」という記事が掲載されていました。これはAPが配信した記事のようです。


この記事は、アンディ・ウォーホルの作品でも有名なキャンベル・スープ・カンパニーが社名から「スープ」を外したという内容です。記事では、同様の事例が、ダンキン・ドーナツ、ドミノ・ピザやスターバックス・コーヒーでも、社名から商品名を外しています。この背景には、主力商品だけではなく、商品ラインナップを拡大していく際に、社名に商品名が入っていると障害になりかねないという懸念があるからだと思います。

 

同様の事情は日本でもあると思います。直ちに思いつくのがミスタードーナツです。主力商品はドーナツですが、飲茶なども扱っているので、「ドーナツ」だけではなくなっています。ただし社名から「ドーナツ」を外すと「ミスター」になってしまうので、社名としては成り立たないのではないかと思います。ならば社名を「ミスド」にするのは考えられるかもしれません。例えば「東芝」は、元々「東京芝浦電気」という社名でしたが、その略称を正式に社名としたので、同じことはできそうな気がします。

タンブラー再塗装の前の下地処理

10年ほど前に購入したスターバックスのタンブラーの表面にデザインされている塗装が剥がれたり擦れたしてきて、見た目が悪くなってきたので、塗り直してみることにしました。まず第一段階として、現状の塗装を剥がしました。最終的には再塗装するのですが、そのまえに下地処理をしておくことにしました。

 

正直なところ、本当に下地処理が必要だろうかと思います。塗装を剥がしたら、下地処理をしないで、再塗装しても問題ないんじゃないかとも思います。このタンブラーは個人的に使うものなので、一般に売られている商品のようなクオリティを追及しなくても構わないのではないかという気はします。

 

いろいろ思うところはあるのですが、簡単に下地処理をしておくことにしました。まず最初に1000番の耐水ペーパーをかけておきます。こうすることで、剥がした塗装のカスが残っているところも、全て綺麗に取り去ることができました。次に「メタルプライマー」を吹き付けておきます。念のために、塗装しない箇所はマスキングテープを貼って保護しておきます。どれくらいプライマーを塗れば良いのかよくわかりませんが、ひとまずタンブラー全体に軽く吹き付けておきました。


下地処理をすることで、何か良い事があるのか、何も変わらないのか、確信はありません。いちおうプライマーを拭いて下地処理を済ませたので、次は再塗装をしてみたいと考えています。

2024-09-30

タンブラーの塗装を剥がす

スターバックスで購入したタンブラーを使用していますが、購入してから何年も経たので、塗装が剥がれたり、デザインされているイラストが擦れてきました。みすぼらしいのでシールを貼ったりしていたのですが、そのシールも月日が経つと劣化してきました。劣化したシールに重ねてシールを貼ったりしていたのですが、さすがに行き詰まってきた気がします。ふと思い立ち、塗装を全て剥がして塗り直してみることにしました。

 

Webを検索すると、スターバックスのタンブラーに限りませんが、塗装を剥がして塗り直している事例がみつかります。うまく出来るか覚束ないのですが、もし失敗したら新しくタンブラーを購入すればよいので、挑戦してみます。

 

何はともあれ、貼ってあるシールを剥がし、塗装も全て剥がします。 シールを剥がすのは簡単でした。樹脂製シールは、手で綺麗に剥がせます。紙製シールは、表面は剥がれても、糊面は取れませんでした。しかし塗装を剥がす際に一緒に取れると思うので、剥がせなくても気にしないことにします。

 

塗装を剥がすには、剥離剤が必要です。今回は「水性タイプ塗料はがし剤」を使ってみました。タンブラーの表面に刷毛で塗っていきます。ここで注意するのは、これは仕上げ塗装ではないので、多すぎるくらいに塗り付けていくようにすることです。塗った直後は、これで本当に塗装が剥がれるのだろうか心配になりましたが、10分ほど放置しておくと剥がれてきました。

 

塗りかたにも依るかと思いますが、全体が綺麗に剥がれるわけでもありませんでした。剥がれかけている箇所は、樹脂製のヘラで塗装を落とし、剥がれそうもない箇所は、あらためて剥離剤を塗ります。これを何度も繰り返していきました。塗装を落とす際には、金属製のヘラを使うとタンブラーに傷がつくかもしれないので、樹脂製の方が無難です。タンブラー購入時からシールが貼ってあった箇所が、少しだけ残ってしまいましたが、全体として綺麗に塗料が落ちました。 


塗装を落としただけでも、タンブラーを利用するには問題ないと思いますが、パールホワイトのような色で塗り直してみたいと考えています。

2024-09-29

PDP-11/40のメモリ管理を理解したい

PDP-11/40で動作したUNIX V6のカーネルを理解するには、UNIX云々の理解も必要ですが、PDP-11の理解も必要です。カーネルが(旧いスタイルの)C言語で書かれているから、ソースを読めば何をしているか見当をつけることができるとしても、その前提にはPDP-11を深く理解していることが必要です。


PDP-11について深い理解が必要だとしても、いきなり全てを理解するのは無理ですから、まずはメモリ管理から勉強することにしました。PDP-11のメモリ管理は、11/40、11/45、11/70で違いがあるものの、11/40が基本のようです。『PDP-11/40 processor handbook』の「Chapter 6 Memory Management」を理解できるようにしたいと思います。


2024年現在主流のx86などのメモリ管理に比べれば、PDP-11/40のメモリ管理はシンプルです。わざわざ勉強なんかしなくても、理解できるだろうと言われてしまうかもしれません。それはその通りだとは思います。概念的な理解ならば、別に「勉強する」と意気込むほどのことではありませんが、UNIX V6のカーネルを読んでいく為に必要な理解をするには、それなりの勉強が必要だと思います。

 

PDP-11/40のメモリ空間は、仮想アドレス空間が16ビットなので、64Kバイトです。PDP-11は2バイトをワードとして扱うことを基本としているようなので、64Kバイトは32Kワードです。物理アドレス空間は、PDP-11/40や11/45では18ビットあるので、256Kバイト(128Kワード)あります。PDP-11/40のメモリ管理機構により、仮想アドレスが物理アドレス空間のどこかに対応されることになります。まず上位3ビットにより、8セットあるActive Page Registerの何れかが選択されることになります。64Kバイトが8分割されることになるので、8Kバイト(4Kワード)を単位として管理されています。


Active Page Register(APR)は、Page Address Register(PAR)とPage Description Register(PDR)の組み合わせで構成されています。仮想アドレスの上位3ビットによってAPRが特定され、そのPARによって物理アドレス空間における領域がPARによって指定されます。ここでPARで指定できるのは12ビットなので、18ビットある物理アドレス空間をバイト単位で指定することができません。PDP-11のメモリ管理では、6ビットで表現できる領域として64バイト(32ワード)を最小管理単位としています。これを「ブロック」と呼んでいるようです。PARによって物理アドレス空間上の位置が特定されますが、それは先頭位置であり、そこから確保されている範囲はPDRで指定されています。最小1ブロック(すなわち32ワード)で、最大128ブロック(つまり4Kワード)です。

 

このようにして仮想アドレスが物理アドレスにAPRにより変換されます。『PDP-11/40 processor handbook』の「Figure 6-4 Construction of a Physical Adress」に概念図が掲載されていますが、別に複雑ではありません。UNIX V6としては、カーネルがメモリ管理できるようにするために、ブートストラップ処理の中で初期設定をおこなっています。ブートストラップ処理の最初の段階では、メモリ管理が無効状態なので、仮想アドレスとは言っても現実の物理アドレスと一致しています。しかし初期設定が済めば、直ちにメモリ管理が有効となり、仮想アドレス空間が現実の物理アドレス空間の何処に割り当てられることになるのか、きちんと理解しておかないとカーネルを勉強したことにはならないでしょう。

『ヤンキーと住職』を購入

スマホを使っていると、お勧めのニュースやWeb記事などが配信されてきます。お勧めされたものの、自分の嗜好に合っているとは限らず、できればお勧めして欲しくないものも少なくないのですが、中には興味をもつキッカケになる場合もあります。

 

先日「ヤンキーと住職」という漫画がお勧めされました。仏教の教えと(いかにもな)ヤンキーという組み合わせが興味を引きました。面白かったのですが、Webで読めるのは一部だけです。他も読みたければ書店で『ヤンキーと住職』を買う必要があります。Webで読めないところも興味があったので、書籍を買ってみました。


仏教と言っても、この漫画は浄土真宗の教えを踏まえているようです。私の家は真言宗なので、同じ仏教でも教えが違うとは思います。そうだとしても、仏教の諸宗であっても、仏教に限らずキリスト教などであっても、教えられるところは多いと思います。

第366回TOEICを受験

試験結果を求められている訳でも、どこかに提出する予定がある訳でもありませんが、英語学習の成果を測り、モティベーションを維持するため、毎年TOEICを受験しています。2024年9月29日の午前中に実施された第366回TOEICを受験しました。

 

20年以上前に初めて受験した時には500点くらいでした。その後500点台をフラフラしていて、その後で突然600点台になりました。そしてまた10年以上600点台でしたが、5年ほど前に750点を越えました。嬉しかったのですが、それをピークに700点台前半が続き、昨年は600点台後半に下がってしまいました。

 

英語の勉強を続けている効果がないわけではないと思うのですが、闇雲に力任せな方法で勉強しているせいなのか、時間をかけている割には、成績が伸びません。とは言え、受験テクニックを駆使して点数だけが上がるのは望んでいません。なんとか実力をつける勉強方法をみつけていきたいと思っています。

 

英語の勉強と言うと、単語を覚えたり、文法を理解したり、何かとインプットすることに意識が向きがちですが、アウトプットする方法を見つけていく必要があると感じています。「英語が聞けないのは、自分で話せないからだ」という意見を目にしたことがありますが、尤もだと思います。アウトプットできるようになれば、インプットされる能力も向上するのではないかと期待しているところです。

2024-09-22

自然科学

NEKO PUBLISHINGから「RM Re-Library」というシリーズの出版物があります。これは同社が出版する「RM Library」のバックナンバーから人気のあったものを再編集しているようです。近所の書店に行ったら『昭和30年代の国鉄列車愛称板』(RM Re-Library 28)があったので購入してみました。

 

そもそも日本の鉄道で列車名がついたのは、昭和初期に「富士」や「燕」などが登場した時とされています。それと同時に「愛称板」も登場しました。戦後国鉄になり、昭和30年代になると日本全国に特急、急行、準急が増発され、様々な「愛称板」が取り付けられて運行されるようになったようです。

 

本書を見ていて、最も驚いたのは「自然科学」という名称の列車が運行されたことです。これの愛称板は、43ページに掲載されています。1960年10月23日に新宿駅で撮影されたことしか書かれていないので、これが(特急ではないと思いますが)急行なのか準急なのか、それとも臨時列車だったのか、何もわかりません。

 

愛称板は、一般に丸形が多いですが、この「自然科学」は角形です。上部に横書きで「自然科学」 とあり、中央には縦書きの大きな文字で「新宿」とあります。どちらかと言うと「新宿」と書かれている方が存在感があるので、これが列車名のように見えなくもありませんが、本書では列車名を「自然科学」としています。

 

頭を冷やして考えてみると、「自然科学」なんて名前の列車が存在したのだろうかと疑問に思います。一般に列車名と言うものは、「富士」とか「さくら」のような名前が多いですし、「つばめ」・「はと」・「かもめ」とか、「東海」・「しなの」・「比叡」・「八甲田」など、 乗客に馴染みのある名前がつけられるものです。それに対して「自然科学」なんていうのは不自然ではないでしょうか。

 

鉄道とは関係ない何か別物を撮影したものが紛れ込んでしまったという可能性があるかもしれませんが、写真が掲載されており、その撮影年月日と撮影地が記載されていることは事実です。撮影年月日が分かっているので、その当時の時刻表を参照すれば、何かわかるかもしれません。撮影地として「新宿」とあり、これは東京の新宿のことだと思いますが、中央本線を運行したかどうかは何とも言えないと思います。当時は新宿発着の東北方面行きの列車が存在したようですから、そういう何かの可能性もあります。

 

PDP-11におけるSOB命令の挙動

UNIX V6のカーネルのブートストラップ処理を追いかけています。m40.sの「start」ラベルから始まる処理を調べていますが、Lions本で言うと0628行目に、「sob r3,1b」 という処理が現れます。ここで使われている命令「sob」について確認してみました。


『PDP-11/70 PROCESSOR HANDBOOK』の4-67ページに命令「SOB」について説明があります。

Operation: R ← R -1 if this result = 0 then PC ← PC -(2x offset)
Description: The register is decremented. If it is not equal to 0, twice the offset is subtracted from the PC (now pointing to the following work).


この命令が何をしようとするものなのかは分かりましたが、よく見ると「Operation」と「Description」の挙動が整合していません。前段の、「Operation: R ← R -1」というのが、「Description: The register is decremented.」と説明されているのは、整合がとれています。しかし後段で、「if this result = 0 then PC ← PC -(2x offset)」と「If it is not equal to 0, twice the offset is subtracted from the PC (now pointing to the following work).」とは、意味が逆になっているのではないでしょうか。この命令がどうこうではなく、一般的に考えれば、「ある変数が0になるまでループする」というのが普通かと思います。そして「Description」では「If it is not equal to 0,」とあるので、思っていたとおりなのですが、「Operation」では「If this result = 0」となっていて、これは違うのではないかと思います。


念のために他の資料も確認してみました。

  1. 『PDP-11/40 PROCESSOR HANDBOOK』では、「Description」の記述は同じですが、「Operation」が「If this result ≠ 0」となっています。
  2. 『PDP-11/45 PROCESSOR HANDBOOK』は、11/70と同様です。「Description」の記述も同じで、「Operation」も「If this result = 0」になっています。
  3. 『PDP-11/34 PROCESSOR HANDBOOK』は、11/40と同様です。「Description」の記述も同じで、「Operation」は「If this result ≠ 0」になっています。

 

これらより、命令「SOB」の説明は、11/40が正しく、11/45や11/70は誤植なのでしょう。

2024-09-19

PDP-11の777572番地はMMRなのかSRなのか、それともSSRなのか

PDP-11/40で動作するUNIX V6のカーネルを勉強するため、まず最初にブートストラップ処理を追いかけていこうと思っています。その処理はm40.sのstartラベルから始まります。まず最初に「bit $1,SSR0」という処理が現れますが、SSR0とは何でしょうか。カーネルを読み進めていくには、PDP-11について幅広く理解していることが求められます。カーネルを学んでいる最中には、それほど知識を有しているわけではありませんから、DECが発行していた資料を調べてみたりする必要があります。その最初の課題が「SSR0」を理解することです。

 

1972年に発行された『pdp-11/40 processor handbook』を参照すると、「CHAPTER 6 MEMORY MANAGEMENT」の中に「6.6.1 Status Register #0 (SR0) (status and error indicators)」という項目があります。ここでは「SR0」とあり、「SSR0」ではないのですが、おそらく同じものです。同書の巻末にある「APPENDIX B MEMORY MAP」では、777572番地が「11/45 SSR0」と説明されています。なぜか「11/45」と断っているし、「SSR0」となっているのも気になります。Lions本では、m40.sの1445行で「SSR0 = 177572」とあるので、SR0が正しいのかSSR0が正しいのか不明ですが、UNIX V6ではSSR0としているようなので、あえて意義を唱えることもありません。


これで一件落着かと思うところですが、さらに調べてみると、疑問が拡がりました。1973年に発行された『pdp-11/45 processor handbook』を参照してみると、「CHAPTER 6 MEMORY MANAGEMENT」の中に「6.6.1 Status Register #0 (SR0) (status and error indicator)」という項目があります。これはpdp-11/40と同じなのですが、巻末の「APPENDIX C MEMORY MAP AND RESERVED LOCATIONS」では「777572 through 777577 Memory Management Status Register 0-2」とあり、pdp-11/40とは表現が異なります。

 

さらに1975年に発行された『pdp-11/70 processor handbook』を参照すると、「CHAPTER 6 ADDRESSING」の中に「6.5.6 Fault Recovery Registers」とあり、そこでは「Memory Management Register #0 (MMR0) (status and error indicators)」と名称が変わっており、巻末の「APPENDIX A UNIBUS ADDRESSES」では「777 572 Memory Mgt regs. (MMR0)」となっていて、もはやSSR0とは名乗らず、MMR0で統一されています。

 

777572番地のレジスタの名称が「SSR0」だろうと「MMR0」だろうと、DECが決めた名称なので、どちらでも構わないのですが、PDP11のモデルによって名前が変わるのは、今後資料を参照する際に混乱しそうで、ちょっと心配です。PDP11の後継機種の資料を参照すると、もはや「SSR0」とは呼ばず、「MMR0」となっているので、DECで方針が変わったのではないかと推測します。当初の「Status Register (SR)」というのは、機能として実体に即しているとは思いますが、意味が一般的すぎることを懸念したのかもしれません。最終的に「Memory Management Register (MMR)」とすることで、より限定された意味を持たせることにしたのでしょう。

 

この調査をしていて、いろいろな資料を見つけました。1976年に発行された『KT11-D memory management option user's manual』では「CHAPTER 3 OPERATION AND PROGRAMMING」の中に「3.6.1 Status Register 0 (SR0)」とあるのは、上述した『pdp-11/40 processor handbook』で書かれていたのと、ほぼ同じ内容です。この資料の「CHAPTER 2 INSTALLATION INFORMATION」には以下の記述があり、pdp-11/40と11/35で使われたモジュールであることがわかります。

The installaion procedure for the KT11-D Memory Management Unit option is included as part of the complete PDP-11 system installation procedure described in Chapter 2 of the PDP-11/40, PDP-11/35 System Mnual (21 Inch Chassis).

 

 また1972年に発行された『PDP-11/45 memory management reference manual』では「INTRODUCTION」において以下の記述があります。PDP-11/70もメモリ管理としてはPDP-11/45と同等のようなのですが、PDP-11/70でKT11-Cを使用しているという情報は得られませんでした。

The KT11-C Memory Management Unit is a hardware option designed for use with the PDP-11/45 Programmed Data Processor.

 

2024-09-16

ギリシャ語のスパムメール

日々様々なスパムメールが届くので、いちいち気にしていられないのですが、ギリシャ語で書かれたスパムメールが届いたのは、さすがに驚きました。本文は、こんな感じです。

 Σα   ενημερ  νουμε   τι κατ   τη δε  τερη προσπ  θεια παρ  δοση   του δ  ματο   μα  , δεν   ταν δυνατ   η παρ  δοσ   του στη διε  θυνση πο υ παρε  χατε.

 

ELTA Hellenic Postというのがギリシャの郵便局のようなものらしいのです。なんと驚いたことに(スパムメールだから、驚くことはないのですが)「日本の私の家に郵便を届けられなかった」と言うのです。それで、「アドレスが誤っているかもしれない」と言いつつ、何故か「パスワードと電話番号を入力」するように求めています。典型的なフィッシング手法かと思います。

 

しかも、本文ではギリシャの郵便局から連絡を装いながら、発信者が「ETC利用照会サービス事務局」となっています。不在連絡かと思ったら、ETCだったのかと、本文と発信者がずれていても気にしないのが、スパムメールらしいところです。

 

日本人に宛ててギリシャ語でメールを送っても、読んでもらえないと思います。何処の誰が送信したスパムメールなのか全くわかりませんが、この調子で世界中にギリシャ語でメールを送っているんだろうかと、いらぬ心配をしてしまいました。

2024-09-14

UNIX V6カーネルのlow.sを読む

UNIX V6カーネルを学ぶため、日本語版の『Lions' Commentary on UNIX』を参照し、DECが発行していた各種資料などを参考にしつつ、ロジックを追いかけていこうと思います。カーネルは、システムコールを受け付けたり、メモリやディスクなどのリソースを管理したり、割り込みを処理したり、様々な役割を担います。しかしそれはカーネルが起動し定常状態に達してからの話であって、マシンが起動しカーネルが読み込まれたブートストラップ処理とは違う世界の話です。カーネルを学ぶために、どの切り口から挑んでいくかは人それぞれかと思いますが、私はブートストラップ処理から始めようと考えています。そうであれば、まず最初に見ていくのはlow.sです。

 

Lions本でlow.sは、0500-0599行目に相当します。日本語版では66-67ページにあります。

  1. 0502-0505行では、br4からbr7という識別子に値を割り当てています。PDP-11に親しんでいれば疑問に思うことも無いのかもしれませんが、私はbr4やbr7というのが何なのか分かりませんでした。DECの資料を読んでいくと、brというのは「Bus Request」のことで、PSWのプロセッサ優先度ビットを定義していることが判明しました。
  2. 0507行では、アセンブルされた結果が格納されるアドレスを指定しています。同様の記述が0520行や0529行などにもあります。この記述はPDP-11アセンブラの記述方法なのか、UNIXアセンブラ独時の記法なのかわかりませんが、とても特徴的です。Lions本では266ページで開設されています。ともかく0507行は「. = 0^.」となっていますから、000000番地を指定していることになります。
  3. 0508行では、「br 1f」とあり、0522行目にある「1」というラベルに飛びます。これはそれだけのことだと思いますが、0509行には「4」という数字が突然表れます。これは何なのか、何故「4」なのか、これは誰かが参照しているのか、まったくわかりません。次の0512-0518行目には「トラップベクタ」が並んでおり、これらはアドレス毎に役割が決まっていますから、それとアドレスがずれないようにするための埋め草なのかもしれません。そうならば「4」などという意味の分からない数字ではなく「0」でも良いような気がしますし、または「. = 4^.」を入れても構わないような気がします。
  4. 0512-0518行では、上述したとおり「トラップベクタ」が並んでいます。これらはPDP-11によって構造が定義されており、最初のワードが呼び出すルーチンのアドレスで、次のワードがPSWに格納される値です。それはよいとしても、全て「trap」というルーチンを呼び出すことになっているのは何故かという疑問は残ります。さらに謎なのが、「br7+0.」のように、0505行で定義された「br7」に数字を加えていることです。表記上の注意事項としては、数字にピリオドが付加されており、これはLions本の265ページに書かれているように10進数と解釈されるための工夫です。わざわざ10進数としなくても、8進数で記述しても良かった気もしますが、それはどちらでも構いません。疑問なのは、何故「br7」に数値を加えているのかです。これはPDP-11によってPSWに格納されるワードなので、加算された値はNZVCフラグに何かが入ることになります。それを「trap」ルーチン側で参照しているのかというと、そうでもなさそうです。参照していないような気がしますが、これはm40.sにあるルーチンなので、そこで再度考えてみようと思います。ちなみに「br7」に数値を加算しているのは、0538行とか0547-0549行にもあります。しかも「br7+7.」というのが、0538行と0547行にあり、重複してもよいのだろうかという疑問もあります。
  5. 0522行では、「jmp start」があります。ここは40番地になっており、PDP-11としては「System Software」が利用する領域という扱いになっています。0番地では「br 1f」として40番地に飛び、40番地では「jmp start」として更にstartに飛ぶので、何故こんなに手間をかけるのだろうかとは思いますが、何か歴史的な事情とか、PDP-11の都合とかがあるのかもしれません。
  6. 0523行では、「jmp dump」という命令が置かれています。ここにはラベルも与えられていませんが、どのようにして呼び出されることになっているのでしょうか。おいおいわかってくることを期待しています。
  7. 0525-0544行では、デバイス事の割り込みベクタが定義されています。そもそもlow.sはmkconfによって生成されるものなので、現実のUNIX V6においては利用されるデバイスに相当する割り込みベクタが出現するはずです。Lions本では説明の都合上必要なデバイスだけが現れます。そこではbr4-br7の何れかが記述されていますが、それらはデバイスのデフォルト値として、それぞれのマニュアルに記述されています。マニュアルによって記述箇所は一定していませんが「Address and Priority Assignments」という箇所に書かれていることが多いようです。
  8. 0558-0577行では、0525-0544行の割り込みベクタで指定されているルーチンが定義されています。基本的な構造は同一で、0558行のklinであれば「jsr r0,call; _klrint」となっています。ここに現れる「call」はm40.sにあるので、あとで詳細に見ていくつもりです。ただし現時点で不思議なのは、なぜ「jsr」命令をつかっているんだろうということです。ここには「jsr」命令が並んでいますが、「Jump Sub Routine」という名前から想像されるところでは、サブルーチンから戻ってくるのだろうかと思うところですが、多分片道切符で、戻ってこないのでしょう。それならば「jmp」命令のほうが自然ではないかと思うのです。

 

low.sを見てきて、いろいろと疑問が生まれ、それらが全て解決したわけではありません。疑問が残ったままですが、カーネルのブートストラップ処理を追いかけるため、次は「start」処理を見ていこうと思います。

2024-09-13

PayPayの本人確認手続きで運転免許証の暗証番号を初めて利用した

スマホにはPayPayのアプリをインストールしてありますが、普段使うことは殆どありません。softbankを契約しているので、たまにPayPayポイントを貰えることがあり、それを利用するくらいです。ところが本人確認が必要らしく、あまり利用していないこともあり何も手続きしていませんでしたが、催促のメッセージが送られてきました。

 

本人確認手続きは、強制ではないようです。何もしなくても私の利用形態には影響無さそうですが、別に後ろ暗いところもないのに何もしないでいるのもどうかと思うので、手続きしました。本確認手続きをするには、いくつかの方法があるようですが、運転免許証を使うことにしました。免許更新時に登録した暗証番号を入力しました。今までにも何度か免許更新時に暗証番号を登録してきましたが、実際に利用したのは初めてです。


さらに運転免許証の中に保管されている情報を読み出すために、スマホが利用できることに驚きました。私の所有しているスマホがおサイフケータイに対応しているから読み込めるのかもしれませんが、以前に使用していたスマホはおサイフケータイ非対応だったので、その場合にはどうなったんだろうと思います。

2024-09-08

PDP-11のTRAP命令のバイナリ表現が104400から104777の256個もあるのは何故だろう

PDP-11/40上で動作するUNIX V6のlow.sを解析するため、PDP-11の命令について調べています。low.sの中ではTRAP命令は使われていません。ただし、紛らわしい事に、m40.sの中で定義されている「trap」という番地を参照しているので、うっかりするとTRAP命令が使われていると誤解してしまうかもしれません。


PDP-11 processor handbookでTRAP命令を確認すると、対応するバイナリ表現が104400から104777までの256個もあります。普通なら、BPT命令なら000003とか、IOT命令なら000004などのように、1対1に対応しているはずです。TRAP命令だけではなく、EMT命令も104000から104377までの256個用意されているので、何か意図がありそうな気がします。

 

EMT命令、TRAP命令、BPT命令、IOT命令は、PDP-11においては、それぞれの命令に専用のTRAP VECTORを介して、それぞれのルーチンに飛ぶようになっています。BPT命令なら014番地、IOT命令なら020番地、EMT命令なら030番地、TRAP命令なら034番地です。各命令に1つずつしか用意されていません。と言うことは、EMT命令やTRAP命令のバイナリ表現が256種類あったとしても、全て同じTRAP VECTORが使われる訳ですから、区別できません。しかも、256種類のバイナリ表現があり得るとしても、その値がレジスタに格納される訳でもないので、普通にプログラミングしているだけでは、256種類のバイナリ表現の違いを認識できません。どうして、こんなことになっているのでしょうか。

 

同じような疑問を感じた人は他にもいるようで「Using the TRAP instruction」という記事がありました。ロジックを工夫すれば、256種類あるバイナリ表現の中で何が使われたのかを実行時に識別することは出来るようです。

 

PDP-11の命令体系において何か意図してTRAP命令用のバイナリ表現として256種類を用意したのであれば、その区別がレジスタ参照で取り出せるようになっているべきではないかと思います。そうなっていないということは、命令体系上の方針としては、256種類を使い分ける必要はないと思っていたということでしょうか。

 

PDP-11の命令体系はよくできているという評価を得ているようです。私自身としては、まだPDP-11を学び始めたばかりなので、それほど深く理解している訳ではありませんが、多彩なアドレッシングモードが多くの命令で同じように使えるようなので、よく出来ているCPUだと思わなくもありません。そうであったとしても、TRAP命令とEMT命令については、謎めいているという印象です。

2024-09-07

UNIX V6のmkconfはl.sとc.cを生成する

UNIX V6のカーネルを学ぶため、日本語版の『Lions' Commentary on UNIX』を主な参考書として使おうと考えています。この書籍にはUNIX V6カーネルの全ソースコードと解説が掲載されていますから、これだけあればソースコードとしては十分なのですが、ネット上にはUNIX V6のソースコードが置かれているので、それも併用しようと思います。

 

カーネルを理解するには、闇雲にアプローチしても手に負えません。カーネルは光の当て方によって、様々な姿を見せてくれますから、そのどこかに注力して、カーネルの深淵に迫ろうと思っています。Lions本にはLions本なりのアプローチがあり、BSDの黒本には黒本なりのアプローチがあります。どこからアプローチしても、途中で挫折しなければ、到達点は同じのハズです。

 

PDP-11/40にカーネルがロードされ、実行を開始し、初期設定などが完了してカーネルとして機能する準備が完了した後ならば、ユーザプロセスからシステムコールを受け付けたり、メモリ管理を行なったり、ファイルシステムによりファイル操作をするなど、カーネルとしての役割を淡々と実行していきます。カーネルとしての諸機能を恙なく処理するには、カーネルの実行開始時にリソースの初期設定を済ませておく必要があります。このような視点では、カーネルの初期状態と定常状態という2つの状態としてカーネルを理解するアプローチになります。

 

カーネルが定常状態に入った後は、システムコールとか、メモリやディスクなどのリソース管理とか、デバイスドライバの処理など、様々な観点からカーネルを見ていくことになるでしょう。しかしそれは、カーネルが初期状態を終えた後の話です。まずは、UNIX V6のカーネルが初期状態で何をしているのか理解するところから始めようと思います。

 

Linos本によれば、カーネルの初期状態は、66ページに掲載されているlow.sから始まります。UNIX V6のカーネルをネット上で探して見ると、The Unix Heritage Societyで「Sixth Edition Unix」を見つけました。ここに置いてあるのは、Lions本とは違う点があります。

  1. Lions本では「unix」というディレクトリの下にフラットにソースファイルがあるように見えますが、上述した場所では、kenとかdmrなどのサブディレクトリに分かれています。
  2. Lions本では、説明の都合上だと思いますが、説明対象外のデバイドライバのソースファイルは掲載されていませんが、上述した場所では全て置いてあります。
  3. ここが最も重要かと思いますが、Lions本で掲載されているlow.sとconf.cは、上述した場所には置いてありません。

 

Lions本では、291ページで次のように書かれています。これはlow.sの説明ですが、conf.cも同様の記述があります。

mkconfと呼ばれるユーティリティプログラムによって生成される。

 

確かに上述した場所にはmkconf.cがあるのですが、このユーティリティプログラムが生成するのはl.sとc.cであって、low.sとconf.cではありません。カーネルの生成につかわれるスクリプトを見ても、生成されるのはl.sとc.cとして処理されるようになっています。Lions本が何故low.sとconf.cに変わっているのか、理由は不明です。もしかして初期のV6はl.sやc.cだったけど、いずれかの時点でlow.sやconf.cに変更されたのかもしれないと想像しました。しかしUNIX V7のmkconf.cを参照してみましたが、相変わらずl.sとc.cのままだったので、先の仮定は成り立たないようです。

 

Lions本がlow.sとconf.cに変更されているのは、独自に変更したのか、そういう変更が加えられたものを入手したのか、経緯は不明です。

2024-09-06

PIANISTとDRUMMER

The Japan Times Alphaの2024年8月30日&9月6日合併号に掲載されていた「LUANN」では、次のようなセリフが載っていました。

This band has a pianist, guitarist, bassist, saxophonist, trumpeter and drummer.

 

このセリフを発した理由は、なぜ楽器の奏者に「-ist」がつく場合と「-er」になる場合があるのかという疑問からでした。その答えとして、次のように説明しています。

It's because "trumpet" and "drum" are nouns and verbs, like "bugle." You can trumpet, drum and bugle, but you can't piano, guitar or bass.

要するに、名詞と動詞の両方で使える単語なら「-er」で、そうでないなら「-ist」という事のようです。

 

これは私自身も以前から疑問に思っていました。マラソンなどの選手は「ランナー」と言いますし、ボーリング選手は「ボウラー」ですし、冬季オリンピックでもお馴染みになったカーリングの選手は「カーラー」だそうです。


日本では俗語として現れる「転売ヤー」というのは、「転売」という語が単独で名詞と動詞の両方で使えるわけではない(動詞なら、サ変動詞として「転売する」になる)ので、「転売ニスト」の方が正しいのかもしれません。

 

パソコンの達人のようなひとは、Windows使いなら「Windowsist」とか、Mac使いなら「Macist」と呼ぶのでしょうか。同様にLinuxを極めた人であれば「Linuxist」とか、BSD好きなら「BSDist」で、究極的にUNIXのGURUなら「unixist」かもしれません。

2024-09-05

OSカーネルを勉強してみたい

OSに関する理解を深めるためにカーネルを学んでみようとするのは、ごく普通のアプローチではないかと思います。Linuxであろうと、FreeBSDやNetBSDなどであろうと、カーネルのソースコード自体は公開されていますから、それらを素材としてカーネルを学ぶことは「理論上」としては可能です。しかし「現実問題」としては、困難でしょう。例えるなら、普段からウォーキングをしているからと言って、なんの準備もなく、いきなりエベレスト登山に挑戦できるかと言えば、無理でしょう。

 

書籍として『私はどのようにしてLinuxカーネルを学んだかゆたかさんの技術書』のようなものがいろいろと出版されていますから、Linuxを素材としたいと考えている人は、少なくないのでしょう。2024年時点でLinuxカーネルは3600万行もあるようで、カーネルを初めて勉強しようとする人が取り組むようなものではないと思います。

 

これに対して、古典的なUNIXのカーネルを素材として学ぼうとするアプローチもあります。有名なところでは『Lions’Commentary onUNIX』がありますし、『はじめてのOSコードリーディング ~UNIX V6で学ぶカーネルのしくみ』もあります。これはごく初期のUNIXなので、TCP/IPネットワーク機能は入っていません。しかもCPUはPDP-11/40なので、x86系CPUとはアーキテクチャが異なります。今日のLinuxやBSDと比べると、全然違う訳ではないのですが、基本的な機能しか実装されていないので、戸惑うところがないわけではありません。

 

UNIX V6以外も、V1だろうと2BSDだろうと、インターネット上ではソースコードが公開されています。それらを独力で解析していくことも可能ですが、できれば参考書がある方が、ひとりで頑張るよりも望ましいと思います。これらを勘案し、Lions本を参照して、SIMHでUNIX V6環境を使用して、カーネルの理解を進めていきたいと思います。


昔々ネットニューズが一般的だった頃、fj.os.bsd.freebsdに「Re: How to read FreeBSD2.1.0 source」という記事が流れました。この記事には次のような事が書かれています。

大学院生のソース読み輪講につきあったことがあるのですが、彼らも同じような非効率なアプローチを取りました。システムコールが呼ばれた時の制御の流れや、コンテキストスイッチとは CPU の何をどうすることかなど、超基本的な知識を咀嚼できてない状態で「生の OS」のソースコードに手を出すのは難がある(ひどく遠回りをするという意味)ように思います。

 

この記事の教えを踏まえて、OSカーネルの勉強をしてみたいと思います。

2024-09-04

Student Workbook Introduction to the PDP11

PDP11に関する資料を探していたら「Student Workbook Introduction to the PDP11」というものを見つけました。PDP11に関する入門的な情報に留まりますし、マニュアルの代わりになる訳でもなさそうですが、かなり詳しいところまで記載されているのでマニュアルを補足する情報として役立ちそうな気がします。

 

この資料がどのように使われたのか分からないのですが、何日間かのワークショップのようなものが開催されて、そこで使われたようにも見えます。ところどころに学んだところを確認するための小テストなども含まれています。もしこの資料を使った講習会が開催されたのなら、僕も参加してみたい気がします。

 

「course map」を見ると「SYSTEM OVERVIEW」から始まり「I/O PROGRAMMING」と「PDP-11 FAMILY」で終わるようです。コース中の各項目ごとにPDFファイルがあるのですが、以下の項目はPDFファイルが欠けているのが残念です。

  • USE OF THE CONSOLE
  • UNIBUS CONCEPTS

2024-09-03

液体やゴミは検出されなくなりました

今使っているスマホは「Redmi Note 10T」です。Androidのバージョンは「13 TKQ1.221013.002」で、MIUIのバージョンは「MIUI Global 14.0.15.0(TKNJPSB)」になっています。

 

つい最近になって、USB Type-Cケーブルで充電をしていると、頻繁に接続が切れ、充電が中断してしまうことに気がつきました。もしかして本体が故障しているのか、それともケーブルが不良なのか、心配になったので、Googleで調べてみました。そうすると、USBポートが汚れていたり、埃が詰まっていたりするの原因であることが多いようです。エアダスターでほこりなどを吹き飛ばすと良いようなので、やってみました。それほど埃が溜まっていたようには見えませんでしたが、充電中に中断することは無くなったような気がします。

 

問題が解決して良かったと思っていたのですが、「液体やゴミは検出されなくなりました」というメッセージが出るようになりました。スマホというものは、エアダスターでUSBボートを掃除したことを検出できるようです。まさかこんなメッセージが出るとは思いもしなかったのですが、どうせなら、充電が中断してしまう時点で「USBポートにゴミが溜まっているようです」というようなメッセージを出してくれた方が有り難いのではないかと思いました。

2024-09-02

UNIX V6のブートストラップ

PDP-11で動作したUNIX v6の内部構造に関する資料としては、『Lions' Commentary on UNIX』が有名です。これを用いてカーネルについて学んでみようと思い、いろいろと情報を集めているところです。

 

カーネルと言うものは、UNIX V6に限らず、WindowsでもLinuxでも、マシンの電源が入ってから、ブートストラップ処理を経て、カーネルとしての起動が完了します。カーネル自体はマシンの機種依存性が少なくなるように作られていますが、ブートストラップ処理はマシンに強く依存した処理になっています。

 

上述したLions本では、ブートストラップ処理について次のように書かれています。

これで、プロセッサのROMに永久に記憶されているブートストラッププログラムがスタートする。ブートストラップローダープログラムは(システムディスクのブロック#0から)大きなローダープログラムをロードし、この大きなローダープログラムが/unixと呼ばれるファイルを探し、メモリの低位部分にロードする。

 

これが間違いとは思いませんし、現状のWindowsやLinuxだって同様のブートストラップ処理をおこなっているはずですが、現状のパソコンのブートストラップ処理と同じイメージを持つと、PDP-11当時の状況を見誤ってしまう気がします。


調べてみたら、Web上で「PDP-11のブートストラップ」という記事を見つけました。Lions本ではあっさりと書かれている処理が詳細に書かれているので、細部がよくわかります。


しかもLions本で「プロセッサのROMに永久に記憶」されていると書かれている「ROM」というものが、現状のパソコンのような半導体メモリをイメージしてしまうと、当時の状況を反映していないと思われます。これもWeb上の記事「Diode Matrix」を見ると、具体的にわかります。

 

またYouTubeでも「PiDP-11 - Manually toggling the bootloader for RT-11」や「Booting v6 Unix on a PDP-11/34」などを視れば、PDP-11で起動する手順がどのようなものだったのかが、よくわかります。

2024-08-26

英文法における「完了形」

英語には日本語にはない概念があり、日本人が英語を学ぶときに苦労するところです。よく言われるのが「冠詞」です。英語における「a(an)」と「the」の使い分けは、日本語に相当するものがないので、英語学習で苦労します。また「単数と複数」の扱いも同様です。日本語に複数形が存在しない訳ではありませんが、英語のような厳密性はないので、やはり英語学習で苦労します。

 

「完了形」も英語学習で苦労するポイントです。日本語には「完了形」という概念がないので、テキストの表面上の見え方は、両者とも日本語では過去形になってしまいます。英文を和訳して日本語として理解する場合には、あまり問題にはならないかもしれません。しかし日本語で発想して、言いたいことを英語で表現しようとすると、「過去形」で表現したらよいのか、「現在完了形」で表現したらよいのか、難しいところです。

 

なにか参考となる情報がないかと調べてみたら「とても重要!押さえておきたい過去形と現在完了形の使い分け方」という記事を見つけました。そこに、次のようなアドバイスが書かれています。

それでは、両者をどのように使い分けていけばよいのかと言いますと、副詞などと組み合わせて覚えてしまうことが望ましいでしょう。

 

日本人の発想では、過去形と完了形を区別しないので、単純に英訳してしまうと、なかなか完了形の出番がありません。上述した記事のアドバイスのように、「副詞などと組み合わせて覚え」るとか、例文を暗記して英借文するなどの工夫をするのが、良いのではないかという気がします。

中頃

『平家物語』を暗唱しようと、昨年夏に思い立ちました。まずは有名な「祇園精舎」を覚え、次に「殿上闇討」を覚えました。その次の「鱸」を覚えようとしているところですが、この調子では最後に辿りつくのが何時のことになるのか、もしかすると何百年後になるのか、遠い将来になりそうです。


暗記するつもりで読んでいると、「中頃」という表現が度々現れます。例えば、次のような感じです。

  • 中頃は都のすまゐもうとうとしく
  • 中頃大宰権帥季仲卿といふ人ありけり

 

なんとなく意味は分かるのですが、手元にある辞書『ベネッセ古語辞典』で確認してみました。

なか-ごろ【中頃】〔名〕昔と今との中間の時代。そう遠くない昔。


ふと思うと、今日の我々は「近頃」という表現を使います。これに対して「中頃」は、近くはないが、遠くもない、ちょうど中間という意味なのだと思います。ここで気になるのが、近頃でもなく、中頃でもない、遠くのことを「遠頃」と言うかというと、そういう表現は聞いたことがありません。


こそあど言葉の一種ですが、「こなた」、「そなた」、「あなた」、「どなた」という表現は、古語と現代言葉では使い方が変化しています。これから類推すると、「近頃」、「中頃」とくれば「遠頃」だってありそうな気がするのですが、あまり聞いたことがありません。時代を経て消滅してしまったのか、もともと存在しなかったのかは、わかりません。

2024-08-17

Drive On Metz

ずいぶん前にホビージャパンから出版された『ウォーゲームハンドブック』を購入しました。当時はAHのSLシリーズに関心があったので、雑誌「TACTICS」も買ったりしていました。その後興味が薄れはしたものの、いつかは再開しようと思っていたので、捨てずに残しておきました。


久しぶりに手に取り、読み直してみたところ、ゲームデザインの例として「メッツ進撃作戦」というミニゲームが付いているのに気付きました。気軽にゲームを楽しむには手頃です。しかし何分にも書籍の一部ですから、マップをコピーするにしても綺麗な平面にするのは難しいかもしれません。


何か情報は無いかとWebを検索してみたところ、次のような記事を見つけました。

 

なんと付録のミニゲーム「メッツ進撃作戦」(原題:Drive On Metz)がPDFとしてダウンロードできるようです。また『ウォーゲームハンドブック』の改訂版も、英語ですが、PDFで読めるようです。


「Drive on Metz」のPDFを印刷してプレイしても良いですし、モジュール「Module:The Drive on Metz, 1944」もあるようですから、VASSALでプレイしても良さそうです。

2024-08-16

BISHOPの全ての呪文レベルが9にたどりついた

今年2月頃から、PC98エミュレータを利用してWizardry #1を楽しんできました。6月末頃にはワードナを倒したので、Wizardry #1のミッションは済ませています。途中でPRIESTをBISHOPにクラス変更しました。BISHOPは、魔術師と僧侶の呪文を覚えられるのは良いのですが、レベルが上がるのも遅いので、全ての呪文レベルが9になるのは、かなり時間がかかりました。このレベルに達するまで、何度もB10Fを探検し、何度もワードナを倒しました。パーティを構成するメンバのレベルは50近くになり、H.P.も400くらいになりました。ここまで成長すると、「ほぼ」無敵です。B10Fでワードナの部屋に押し入ったとしても、全く怖くありません。一撃でワードナを倒せてしまいます。

 

しばらくWizardry #1を探検してきましたが、このあたりで一区切りをつけようと思います。ちょっとお休みをして、次はWizardry #2に進もうと思います。

LibreOfficeで日本語変換をおこなうために追加処置は必要なかった

dynabook SS SX/15AにNetBSD/i386 10.0を入れたらLibreOfficeが起動しなくなりました。調べてみても、簡単には解決に至らなそうだったので、NetBSD/i386 9.4に戻すことにしました。このバージョンならLibreOfficeが起動するのを確認しました。

 

2016年末頃、このマシンにNetBSD/i386環境を構築していた時には、LibreOfficeで日本語変換をおこなうには追加処置が必要でした。その手順は「NetBSD/i386でLinuxバイナリ版LibreOfficeの日本語変換に成功 」に書いたとおりです。今回も同様の手順をおこなう必要があるのかと思っていました。

 

この追加処置を行う前に、試しにLibreOfficeで日本語変換をおこなってみたら、なんと普通に日本語変換が可能でした。いつのまにか改善されていたようです。

2024-08-15

NetBSD/i386 9.4にダウングレードしたら、LibreOfficeが動作した

まさかLibreOfficeが動かなくなるとは思わなかったので、dynabook SS SX/15AのNetBSD/i386を9.3から10.0にアップグレードしました。VirtualBOX環境を利用して調べてみたところ、理由は不明ですが、NetBSD/i386 10.0ではLibreOfficeが動かないようです。このままにしておいて、LibreOfficeが動作するまで待つという方法もありますが、何時になるかわかりません。それまで待っていられないので、NetBSD/i386 9.4にダウングレードすることにしました。

 

いままでバージョンアップしたことは何度もありますが、バージョンを下げた経験はありません。慎重に作業しようと思います。

 

バージョンアップの歳は、まず最初にカーネルだけを入れ替えてみて、起動できるか確認していました。その後、問題なさそうなら、ユーザランドをTGZファイルで入れ換えていました。今回はダウングレードなので、カーネルを先に入れ換えてしまうと、ユーザランドが新しいカーネルの機能を利用しようとしている場合に、致命的な問題を引き起こしてしまう可能性があります。そこで最初に9.4用TGZでユーザランドを入れ替えます。この時点ではカーネルは10.0になっています。ここでリブートしてみて、問題なければ、カーネルも9.4に入れ換えます。特に問題がおきることもなく、カーネルもユーザランドも9.4になってくれたようです。そしてetcupdateでファイルを置き換えます。

 

これでNetBSD/i386 9.4環境になったので、pkginでLibreOfficeとSUSEをインストールしました。試しにLibreOfficeを起動してみたところ、スプラッシュ画面が出たあとで、問題なく起動しました。そうなると、やはりNetBSD/i386 10.0には、問題の所在は不明ですが、何か問題が潜んでいるのではないかと思います。 


NetBSD/i386上でLibreOfficeが動くようになりましたが、過去の経験では、日本語を扱うには多少追加作業が必要だったはずです。どのような作業だったのか、当時の記録を確認して、設定を済ませたいと思います。

パッケージ「libreoffice6-bin」で入れたLibreOfficeは、NetBSD/i386 10.0では動かないが、NetBSD/i386 9.3なら動いた

Windows Vistaを使っていたノートPCをNetBSD/i386に入れ換えて使っています。先日NetBSD/i386 9.3から10.0に更新しましたのですが、インストールされていたLibreOfficeが動作しなくなりました。


問題が発覚した場合には、僕のマシン環境に何か原因があるのか、いかなる環境だろうと問題が発生するのか、最初に見極めなければなりません。このためにVirtualBOXを利用して、NetBSD/i386とLibreOfficeだけをインストールしてみて、動作するか否かを確認するのが、まず最初におこなうことです。

 

VirtualBOX上でNetBSD/i386 10.0とLibreOfficeを入れて、動作を確認してみました。LibreOfficeのスプラッシュ画面は出るのですが、いつまで待っても、そこから先に進みません。これは僕のノートPCと同じ挙動なので、まだ断言はできませんが、NetBSD/i386 10.0とパッケージ「libreoffice6-bin」の組み合わせには、何か致命的な問題が潜んでいそうな気がします。

 

念のために別の環境でも試してみました。

 

VirtualBOX上でNetBSD/i386 9.3とLibreOfficeを入れて、動作を確認してみました。LibreOfficeのスプラッシュ画面が出たあと、すぐにLibreOffice本体が起動します。ごく当たり前の動作です。何の問題もありません。

 

以上を踏まえると、NetBSD/i386 10.0でLibreOfficeを利用するのは、当面は難しいのではないかと思われます。何が問題なのか突き止める必要がありますが、全く見当もつかないので、直ちに解決できる気がしません。それならば、NetBSD/i386 10.0にバージョンアップしたノートPCを、NetBSD/i386 9.3に戻すのが良いのかもしれません。

 

NetBSD/i386側なのか、LibreOffice側なのか、問題の原因がどちらにあるのかわかりませんが、問題が解消するまでNetBSD/i386 10.0を利用するのは控えようかと思います。

2024-08-14

NetBSD 10.0のLinuxエミュレーション環境でLibreOfficeが起動するようになったものの、別の問題が生じた

NetBSD/i386を9.3から10.0に更新したら、SUSE13.1を利用しているLinuxエミュレーション環境で動作するLibreOfficeが動かなくなってしまったので、調査してみました。何が問題なのか分からないので、LibreOfficeとSUSEに関するパッケージを全て削除し、関連しそうなディレクトリ「/usr/pkg/emul」 も消してから、再度LibreOfficeのパッケージを入れてみました。SUSE関連パッケージは依存関係にあるので、自動的にインストールされます。

 

そのインストール中に、次のようなメッセージが表示されました。

Do not forget to modload the compat_linux or compat_linux32 modules. Linux binaries require these in order to work. In older NetBSD versions these will be autoloaded. Edit /etc/modules.conf to load the modules automatically on boot.

 

NetBSD 9.3の時には、このような設定をしていませんでしたが、Linuxエミュレーション機能は使えていました。そこで起動した時点からLinuxエミュレーションが有効になるようにしたかったので、ファイル「/etc/modules.conf」でモジュール「compat_linux」を指定しておきました。Webには「NetBSD で Linux binary を実行する方法について」という記事もあるようです。

 

上述した設定を済ませた上でマシンを再起動したところ、LibreOfficeが動き出しました。良かった!と思ったのですが、Calc本体が使えるようになりません。GUIだとエラーが出ても分からないので、コマンドラインから/usr/pkg/opt/libreoffice6.2/program/scalcを直接実行してみました。すると、次のようなメッセージが出ていました。他のメッセージはありません。

javaldx: Could not find a Java Runtime Environment!


一難去ってまた一難というところです。

NetBSD/i386を9.3から10.0に更新したら、LibreOfficeが動かなくなった。

数か月前にNetBSD 10.0がリリースされたので、dynabook SS SX/15AにインストールされているNetBSD/i386を9.3から更新しました。更新自体は問題なく、既にインストールされているアプリケーションも問題なさそうです。ところが、LibreOfficeが起動しないことに気付きました。


NetBSDのパッケージとして提供されているLibreOfficeがインストールしていたのですが、これはSUSEエミュレーション環境上で動作するようになっています。LibreOfficeのパッケージは「libreoffice6-bin-6.2.8」のまま変化していないようだったのですが、念のためにパッケージをインストールし直してみました。すると依存関係にあるSUSEエミュレーション環境のパッケージも更新されました。

 

パッケージを入れ直してから、あらためてLibreOfficeを起動してみましたが、やはり起動しません。coreを吐いている訳ではなさそうです。もしかするとSUSEエミュレーション環境の動的ライブラリが不足しているのかもしれません。

 

NetBSD/i386上でLibreOfficeを動作させないと「とても困る」という状況にはないのですが、今まで動作していたので、動かない筈はないだそうと思います。何が原因なのか追究してみようと思います。このような問題追及は、苦労する割に、解決に至らないで苦しむことも少なくないのですが、そうはならないことを願っています。

2024-08-08

AdGuard内部のVPN通信

Androidのスマホを利用していて、不快な広告が表示されてしまうのを不満に思っていましたが、数か月前にAdGuardを入れてみました。問題ない通信に影響を及ぼすことが偶にありますが、基本的に満足しています。


AdGuardは内部動作の都合上としてVPN通信をしているようです。AdGuardが有効になっている間は、スマホの上部に「VPN」というアイコンが表示されています。ところが不快な広告が表示されてしまうことがあるので、AdGuardは何をしているんだと思ったら、AdGuardのプロセスが落ちていたりするのに気付きます。どういうタイミングでプロセスが落ちるのか分かりませんが、そういうこともあるのでしょう。

 

また「VPN」 のアイコンが表示されており、AdGuardのプロセスが活きている場合に、なぜかWebの読み込みが止まってしまうことがあります。AdGuardを一旦無効にして、再度有効にすると、Webの読み込みができるようになるので、AdGuardが何かをブロックしようとしているのかもしれません。こういうことがあるのは手間と言えば手間ですが、不快な広告が表示されてしまうことに比べたら、個人的にはほとんど気になりません。

2024-08-03

万年筆の使い心地

しばらく前から万年筆を使うようになりました。それ以前はボールペンを常用していたのですが、書き心地や色合いが気に入っている製品を使い続けていたら、何時の間にやら製造中止になってしまいました。せっかく気に入っていたのに、製造中止になってしまうと、次のお気に入りを見つける必要に迫られてしまいます。ボールペンだと、何を使っていても製造中止になってしまう可能性が否定できないので、末永く使える(かもしれない)万年筆に移行することにしました。

 

最初に使ってみたのは「LAMY safari」です。それ以降、何本か買ってみて、使い心地を比べてみました。

 

それぞれに一長一短があり、文句なしに一番のお気に入りは、まだ見つかっていません。LAMY safariは、EFを買ったはずですが、当初はEFだった気がしますが、次第にM相当になっているような気がしてきたので、今は使っていません。#3776 センチュリーは、Mを購入し、使ってみた感じとしてもM相当です。悪くはないのですが、値段相応に良いという感じでもなく、お気に入りかと言えば、そうとも言えません。PILOT カクノは、書き心地は気に入っている方ですが、廉価版の万年筆でもあり、全体としては今一つという感じです。無印良品のアルミ丸軸万年筆は、値段の割には重量感のある作りで、書き心地も悪くない、比較的気に入っている方です。ただし無印良品では、この万年筆用のコンバータを販売していないので、Webの記事を頼りに調べてみて、互換性がある(と思われる)コンバータを別途購入して使っており、特に問題はありませんが、トラブルがあったとしても、自分で解決しなければなりません。

 

万年筆は、値段の安いものから、何十万円もするものまで、いろいろあります。僕の個人的な感覚では、値段が高いから書き心地が優れているという訳ではなさそうです(高級万年筆を所有していると、他人に自慢するアイテムにはなるかもしれませんが、それは本来の目的を逸脱していると思います)。 他の万年筆も買ってみて、僕個人としてのお気に入りを探してみたいと思っています。

2024-08-01

季節予報の理解が難しい

気象庁は「季節予報」というものを定期的に発表しています。これは、「平年並み」か、「平年並み」以下か、「平年並み」以上かという3つのランクに分けて、それぞれの確率として表現されています。気象庁のサイトには「3つの階級について」とか「確率表現の見方」などの解説記事があるので、全く何もわからないという事ではありませんが、それでも腑に落ちないところがあります。

 

例えば今年は猛暑ですから、今後一箇月の気温として、次のように表現されているとしてます。

  1. 平年並みより低くなる確率が10%
  2. 平年並みである確率が10%
  3. 平年並みよりも高い確率が80%

 

ここで「平年並み」というのが、具体的には何度なのかという疑問には、「3つの階級について」で説明されているように、30年分の気象データを使って並べ替えて、中間の10個分を「平年並み」とするようなので、これは理解できます。

 

さて、これから一箇月過ぎたら、その間の気象データが蓄積され、気温の実測値が確定します。おそらくそれは、この猛暑ですから、平年並みよりも高くなるのでしょう。しかし万が一天変地異により、突然冷夏となり、平年並みよりも低い気温になったとします。それは季節予報では「平年並みよりも低くなる確率が10%」の事態に遭遇したということです。その事実が確定すれば、それ以上でも、それ以下でもないのかもしれません。

 

季節予報は、今後の気象変化などの影響を強く受ける事業者に対して情報を提供することを主眼としているという話しを聞いたことがあります。そうかもしれません。一個人にとっては、確率がどうなろうとも、現実の日々の気象変化を受け入れる以外に何もできないのです。このような事を理解しているとしても、季節予報を個人の暮らしに役立てる方法がないものかと、考えているところではあります。

英借文の学び方

英語で文章を書こうとする際、日本語の発想をそのまま直訳しようとすると、文法的に問題ないとしても不自然な英文が出来上がってしまったりしがちです。こうならないようにするため「英借文」が勧められており、それは全くその通りだと思います。では問題なのは、「英借文」を学ぶために何をしていけば良いのかという事です。

 

英借文するには、元ネタとなる英文をストックしておく必要があります。そのような英文は、どこから仕入れてきても構わないと思いますが、よくあるのが『DUO 3.0』や『英作文 基本300選』などです。これらを勉強する事で英文が書けるようになったという記事を見かけることがありますし、素材として決して悪くはないと思います。しかし僕自身の感覚としては、これらの例文を覚えることと、活用して英借文して書きたいと思っていた英文が書けるようになることとは、乖離があるように思うのです。ストックする英文を覚えることを第一にするならば、それなりの時間がかかりますし、そのストックだけで十分なのだろうか?とか、もっと例文を増やした方が良いのだろうか?(しかし覚える時間も増えてしまいます) とか、むしろ例文は減らした方が良いのではないかとか、一歩踏み出そうとしても躊躇してしまいます。

 

英借文するとしても、もっと別なアプローチがないだろうかと調べていたら『「英借文」トレーニング』という記事を見つけました。そこには、以下のような事が書かれていました。

 もっと複雑な事を書きたい場合は、オンライン辞書で単語の手がかりを得て、ネイティブの実際の用例をGoogle.comで検索する、という方法があります。

 

この文に続いて、「たとえば、「テーブルに足の小指をぶつけた」と書きたいとします。」として、具体的に英借文する方法が示されています。この方法なら、例文をストックすることに煩わされずに済む気がしてきました。

 

英借文から始めて自力で英作文ができるようになる方法」に書かれているように、『「英語が書けない人が、英語が書けるようになるためには、英語を書かないといけない」というパラドックス』があります。これを乗り越えれば、最初は大変でも、英文を書くのに慣れていき、そうすることで英文を読むのも楽になり、次第に自分の中で英文のストックが溜まってくるので、更に英文が書けるようになっていく、という循環が生まれるのを願っています。

2024-07-29

麦茶のティーバッグ

毎年夏になると、麦茶のティーバッグをガラス製ポットの水の中に投入して飲んでいます。ポット自体は2リットルくらいだと思いますが、一日で飲み切ってしまうので、夜に準備して、朝には冷たい麦茶が出来るように準備しています。


この方法はお手軽なのですが、「【水出し・煮出し】おいしい麦茶の作り方。保存時の注意と期待できる効果は?」という記事のように、水出し式の他に、煮出し式もあるようです。同じティーバックを使ってみても、水出しと煮出しで風味が違うものなのか、試してみました。

 

煮出し式の場合、ポットで沸かしたお湯にティーバックを入れて煮出すので、冷めないと冷蔵庫に入れられないので、時間も手間もかかります。ティーバックが同じ種類なら、風味も同じような感じがしました。もし煮出し式の場合に、ティーバックではなく、丸粒麦茶を使ったりすれば、もっと風味豊かになるのかもしれません。

2024-07-27

おひとりさま

食堂に入った時、お店の人から「何名様ですか」と尋ねられることがあります。もし「一人」と答えれば、「お一人様ですね。こちらにどうぞ」のように言われて、席に案内されます。


このような対応がされる飲食店は少なくないと思います。来店した方も、「一人」と答えるとか、指を1本出すとかしているようです。もしかすると、既にあるかもしれませんが、今後は、お店の人から「何名様ですか」と尋ねられた際に、「おひとりさまです」と応えるのが、全てとは言わなくても、一般的となる時代がくるような予感がします。

 

何故そう思うかと言えば、すでにそうなっている状況があるからです。マクドナルドのように注文した商品を「店内で食べるか」それとも「持ち帰るか」という選択を求められる場合、お店の人から「お召し上がりですか、(それとも)お持ち帰りですか」と尋ねられるのは、マクドナルドに限らず、よくある状況です。このように尋ねられた際に「お持ち帰りです」と答えているのは、全てとは言いませんが、決して少なくない状況として、既にあるのです。

 

敬語の使用方法として、自らの行為に対して「お持ち帰り」と言うのは、間違っていると思いますが、そういう返答は稀ではありません。このような応答が一般的となりつつある現状を思えば、お店の人から「何名様ですか」と問われて、「おひとりさまです」と答えるのが一般的となる日は、遠からずくると思うのです。

『かなづかいの歴史』(今野真二)を読んで

どういう経緯で知ったのかは忘れてしまいましたが、数年前から読もうと思っていた『かなづかいの歴史』(今野真二)を図書館で借りて読みました。新書なので本格的な専門書よりは著者としても一般向けに書かれているようです。それでも、かなり専門性の強い内容でした。すべてを理解できたとは言えないのですが、とても興味深かったのは間違いありません。


本書の「おわりに」で、次のような記述があります。ここに本書の意図が現れていると思います。

「かなづかいの歴史」というテーマの中に、「かなづかいについて誰かが考えたことの歴史」を含めることはできるが、「かなづかいについて誰かが考えたことの歴史」は「かなづかいの歴史」そのものではない。

 

近世以前に書かれた歴史史料や、明治から終戦までに現れている「かなづかい」は、今一般的に使われている「かなづかい」とは、いろいろと違います。大雑把には「発音した通りに書く」のですが、すべて「発音した通りに書く」わけでもないのです。つまり「これは」と書きますが、「これわ」と発音しているので、全て発音した通りではありません。さすがに「けふは」と書いて、「きょうは」と発音するわけではないのですが。

 

戦後の「かなづかい」には、いろいろな例外事項があり、批判も多いようです。戦前までの「かなづかい」に戻すべきとの主張もあるようですが、それで何が解決されるようになるのか議論が必要でしょう。もしくは完全に発音した通りの「かなづかい」とすべきなのかと言うと、それはそれで、問題をはらんでいるように思います。

 

「かなづかい」が云々されるのは、文字として記録されたものと、現実に発音されたものが、次第に乖離していくところにあると思います。仮に完全に発音したように表記することに決めたとしても、ある時点では「文字」と「発音」が完全一致しているかもしれませんが、、時がたてば乖離していくのは避けられないでしょう。そのときに法律のように長期間にわたり有効であることが求められる文はどうなってしまうのか、また学校教育では世代が異なると教科書の文体も変わっていってしまうのか等々、気掛かりです。


2024-07-21

キー「Pause/Break」が復活

2024年6月中旬にデスクトップPCで使用していたキーボード「FILCO FKBN108ML/NFB2」の特定のキーが入力できず困っていましたが、つい先日、強引な解決方法ですが、使用頻度の低いキーのスイッチと交換することで、修理しました。これで通常の使用には問題なくなりましたが、使用頻度が低いとはいえ、故障したキースイッチが使われているキー「Pause/Break」が使えない状態となりました。


キースイッチ自体はダイアテックオンラインショップで入手できましたので、交換作業をおこないました。キースイッチを交換するだけですので、10分もかからない作業です。これでキー「Pause/Break」自体も使用できるようになりました。


フルキーボードには何に使うのかよくわからないキーが幾つかありますが、キー「Pause/Break」もそのひとつです。Webで検索してみると、Windowsキーと同時に押すことで、Windowsの詳細情報を表示するウィンドウが開くようです。試してみたら、開きました。これはコントロールパネル経由でも開くことができるので、このようなショートカットがあるとは知りませんでした。

 

何はともあれ、これで故障していたキーボードは「完全復活」しました。購入したキースイッチは、あと9個残っています。今後故障しても、これで対処できるでしょう。

2024-07-18

CHERRY MXスイッチ 黒軸 10個セット

Windows10のデスクトップPCで利用しているキーボード「FILCO FKBN108ML/NFB2」が故障し、特定のキーの入力が出来ないという症状が先月発生しました。何が原因なのか特定する暇がなかったので代替キーボードを購入して凌いでいましたが、つい先日修理を試みました。


メーカー保証は既になくなっており、キースイッチ自体が壊れたのだろうと推測したので、強引ですが、あまり使わないキー「Pause/Break」のキースイッチと交換してみたところ、問題は解決しました。しかし、あまり使わないとは言っても、キー「Pause/Break」のキースイッチは壊れたものと交換されてしまいましたし、交換作業中にキースイッチ本体に致命的なダメージを与えてしまいました。ひとつの問題が解決し、別の問題が生じてしまいました。

 

新たな問題が発生しましたが、自分で修理した経験が得られたことは大きな成果です。キースイッチ自体を入手できれば、キー「Pause/Break」のキースイッチを交換する事で、新たな問題も解決できるでしょう。そもそもキースイッチ自体を入手できるか調べてみると、いろいろと分かってきました。

  • amazonでスイッチを購入できるようです。
  • 千石電商でもスイッチを購入できるようです。
  • GATERONという互換スイッチがあるようです。


部品としてスイッチ本体を入手できることは判明しましたが、そもそもキーボードを製造しているダイアテックからは入手できないのだろうかと調べてみると、「【お試しパック】CHERRY MXスイッチ 黒軸 10個セット」として販売されていることがわかりました。オンライン会員にならないくても注文できるようですが、非会員だと送料が高くなるので、会員登録をしてから注文しました。在庫があったようで、注文した翌日には到着しました。


この部品があれば、最大10か所まで壊れても修理できます。壊れても捨てずに、故障を修理して使い続けることが出来るというのは、有り難いことです。

 

 

2024-07-15

FILCO FKBN108ML/NFB2のキースイッチを交換して復旧

先月中旬に、突然「FILCO FKBN108ML/NFB2」の「F」キーが入力できなくなりました。それ以外のキーは入力出来ているので、キーボード本体が壊れたとか、キーボードドライバが変になったとかではないと思います。そうだとしても、「F」キーが打てないのは致命的なので、急遽「ELECOM TK-FCM104BK」を購入して対処しました。

 

あくまでも勘ですが、「F」キーに対応するスイッチ本体が壊れたような気がします。これを交換すれば直るのではないかと思います。そこで、ちょっと乱暴な方法かもしれませんが、滅多に使わないキー、例えば「Pause/Break」キーのスイッチと交換してしまうという方法はどうでしょうか。それで直れば助かりますし、もし駄目なら、スイッチ以外の何かが壊れてしまったということなのでしょう。

 

今日になって、ちょっと空き時間が出来たので、キースイッチの交換を実行してみました。結論から言うと、若干失敗もしましたが、無事に復旧することができました。急遽購入したキーボードはメンブレン方式なので、キータッチが軽い感じですが、復旧したキーボードは、本体自体も重量感がありますし、キータッチは重めです。

 

スイッチの交換作業については、Web上の記事を参考にしました。

 

手持ちの半田ごてと簡易型ハンダ吸い取り器を使いました。電子部品ではないので神経をつかわずに作業できました。ただしスイッチを取り外す方法が良く分からなかったので、ラジオペンチで挟んで外したら、「F」キーのスイッチ本体に引導を渡してしまったようです。交換対象は、「Pause/Break」キーのスイッチを使いました。これら2個のスイッチを入れ替えて、あらためてハンダ付けしておきます。この作業を済ませたキーボードをPC本体に取り付けてマシンを起動させたところ、故障していた「F」キーが復旧したのを確認しました。

 

Web上の記事を参考に作業しました。それらの記事によると、代替品のスイッチを入手することも可能のようです。今回の作業で、スイッチをひとつ壊してしまったので、代替パーツとしてスイッチを買っておこうかと思います。そうすれば、もし今後他のキーも壊れたら、すぐに修理できるようになるでしょう。


このキーボードは、購入価格は安いとは言えない値段でしたが、今回経験したように交換して修理できるのであれば、一生使い続けることができるのではないでしょうか。そう考えれば、決して高い買い物ではなかったと言えそうです。

2024-07-14

Googleマップのタイムラインの謎

スマホのGoogleマップでタイムラインを有効にして、その日の行動を把握するのに活用しています。使ってみると、かなり不思議な移動経路を記録することがあります。タイムラインの内部がどうなっているのかはわかりません。あまり高精度に移動経路を記録してくれるわけではなさそうだということは、すぐに気づきました。真の移動経路との誤差が少しでもあるのは許せないならば、Googleマップのタイムラインは使わない方が良いでしょう。もっと高精度なアプリは、他にもあるはずです。僕自身としては、ちょっとくらい(大幅に?)誤差があっても、あまり気にしないことにしています。


そのようなおおらかな気持ちでGoogleマップのタイムラインに接していても、今日の移動経路の記録は謎でした。徒歩の移動距離が7kmと表示されているのですが、実感としては、もっと長い気がします。気になったので「キョリ測」を使って、移動距離を測定してみたら、12kmくらいありました。移動距離の誤差は大きすぎる気がしますが、移動経路は、だいたい(あくまでも「だいたい」で、細かく見れば「ひどい」のですが)合っています。

 

先月は、2時間で10kmほど歩いたのですが、「移動時間:2時間」で「移動距離:0m」となりました。さすがにそれはないだろうと感じます。移動経路は、それなりに(あくまでも「それなりに」)まともなので、その間の距離が「0m」なわけはないだろうと思うのですが、Googleマップのタイムラインの内部ロジックは、いったいどうなっているんでしょうか。

「平塚らいてう」は「平塚らいてう」?

「元始、女性は太陽であった」で知られている平塚雷鳥は、本名は「平塚 明(ひらつか はる)」だそうです。「雷鳥」を当時の仮名遣で表記すると「らいてう」になりますが、発音として「らいてう」だった訳ではないと思います。文章を発表する際に、「平塚雷鳥」としたり「平塚らいてう」としたりしたそうですが、それは当時に仮名遣に従っていたからではないのでしょうか。

 

『昭和十七年七月国語審議会 新字音仮名遣対照表』には、次のような事が書かれています。

第二十二 オ列拗音の長音に発音される ちやう、てう、てふ は ちよう とする。

二 てう を ちよう とするもの

弔 チヨウ テウ

鳥 チヨウ テウ

朝 チヨウ テウ

兆 チヨウ テウ

超 チヨウ テウ

調 チヨウ テウ

彫 チヨウ テウ


この通りであるなら、「鳥」を「テウ」としていたものを「チヨウ」(今なら「チョウ」でしょう)にするという意味だと思います。これに従えば「雷鳥」は「らいてう」と以前はしたものの、今なら「らいちょう」となります。また「山村暮鳥」だって、当時の仮名遣に従えば「山村ぼてう」だったのではないでしょうか。


ここで「平塚雷鳥」を「平塚らいてう」とするのは、当時の仮名遣の習慣に従っていただけなのか、それ以上の強い意志があるのか、よく分かりません。当時の仮名遣に従っていただけなら、今日であれば「平塚らいちょう」としても構わないと思います。そうではなくて、「平塚らいちょう」ではなく「平塚らいてう」とするのが自己のアイデンティティとして譲れないと考えていたのであれば、それを否定するつもりはなく、尊重したいと思います。

 

京都は「けふと」ではなく「きやうと」

今はほぼ発音した通りに表記しますが、昔はそうではありませんでした。例えば、「蝶々」は「てふてふ」ですし、「今日は」は「けふは」でした。ふと思ったのですが、「今日は」が「けふは」となるなら、「京都」は「けふと」にはならないのでしょうか?確か「京都」は「きやうと」だったはずですが、発音として「きょう」となるものが、「けふ」であったり「きやう」であったりするのは何故なのでしょうか。

 

同じような疑問を持つ人はいるようで、「旧かな使い 「ちょうちょ」は「てふてふ」 「今日」は「けふ」」という質問がWeb上にあるのを見つけました。要するに、発音として「きょう」となるものの書き方は複数あり、「けふ」、「きやう」などがあり、「京都」の場合には「けふと」にはならず「きやうと」とするのだそうです。

 

Webで検索してみたら「昭和十七年七月国語審議会 新字音仮名遣表」という資料が見つかりました。その「新旧字音仮名遣対照表」によると、新仮名遣「きょう」は、発音として「キョー」であり、旧仮名遣では「きやう けう けふ」とあります。

 

旧仮名遣は、古文を読解する際などの、歴史的な存在としてしか認識していないので、細かいところはよくわかっていません。これを自分から使おうとは思いませんが、なかなか難しいものなのだと再認識しました。

2024-07-05

「グローバル時代の英語('22)」の単位認定試験の準備

2024年度第1学期の単位認定試験が2024年7月14日から始まります。今学期は「グローバル時代の英語('22)」を受講しているので、その試験準備のために、通信指導、自習問題、過去問などを勉強しているところです。試験そのものの形式は、印刷教材の各課にある「The Opinions」や「Today's Vocabulary」にあるものが出題されているようです。

 

「Today's Vocabulary」にある単語は、手持ちの辞書をよく読んで、その意味の違いを理解するように勉強しておくことが、 放送授業の中でも強調されていました。一般に「辞書を引く」というと、「和訳するのに都合が良い単語を探すだけ」となりがちです。ある単語について全てを通読してみると、日英の言葉のニュアンスが良く分かってくることが理解できたので、長期的な勉強方法として取り入れようと思いました。

 

とは言え、目前に迫った単位認定試験を突破するためとしては、難しいとも思います。同じ単語を使っていて、使われている意味が異なる文が選択肢に並んでいても、和訳してみても似たような意味になってしまう(→つまり、意味に違いがない)ことがあるので、単位認定試験の解答にはなりません。手元にあるような学習用中辞典ではなく、もっと本格的な大辞典で意味の違いを確実に理解するまで勉強を重ねるというのは「理想的」かもしれませんが、ちょっと「大袈裟」と思わなくもありません。


このような学習上の悩み事に対して、「丁寧に」勉強すれば良いとか、「きちんと」学べば大丈夫とか、具体性に欠ける抽象的なアドバイスがなされるのを散見します。きちんと丁寧に勉強すれば英語は決して難しくはないのかもしれませんが、短期的に役立つ即効薬のような学習方法ではなく、長期的に身につけられる勉強の仕方を常に求めています。

壊れたキーボードを修理できるだろうか

Windows10を利用しているデスクトップPCのキーボードが先日故障しました。特定のキーだけが入力できず、マシンをリブートしても復旧しないので、急遽代替キーボードを購入しました。それで解決したのですが、キータッチが変わってしまいました。当初は違和感がありましたが、慣れてきたので、致命的な問題ではありません。

 

故障したキーボードは「FKBN108ML/NFB2」です。急遽購入したのは「TK-FCM104BK」です。故障したキーボードは10年ほど前に購入したので、正直に言うと、裏蓋を開けたら埃が溜まっていました。それは掃除すれば綺麗になるし、ついでにキートップの汚れも落としたいと思います。 


壊れたキースイッチのハンダを溶かせば、部品自体は外れそうです。ただし、代替となるスイッチを入手するのは難しいでしょう。スイッチを分解して、故障の原因を突き止め、修理できるかという言うと、それも難しそうです。

 

それでは発想を変えて、利用していないキーのスイッチと交換するのはどうでしょうか。フルキーボードですが、「Print Screen」、「Scroll Lock」、「Pause/Break」などは、ほぼ使ったことがありません。これらの部品を外して交換すれば、キーボード全体として見れば復旧とは言えませんが、通常利用としては問題解決と言えそうです。

 

修理の方向性は見えたので、近いうちに時間を捻出して、実行してみようと思います。

2024-07-02

スマホ版Googleマップの妙な動作

スマホのGoogleマップでは外出時の経路を記録してくれるので、便利だとは思って数年前から利用していますが、妙な動作もあります。移動経路を記録してくれるアプリはGoogleマップ以外にもありますが、記録精度が高いアプリはGPS通信の頻度が上がるせいなのか、バッテリー消費が多い印象があります。Googleマップは、率直に言って、精度が良いとは言えないのですが、目安程度に使うには十分だと思っています。


Googleマップに「「Google マップ」のタイムライン、Web版は廃止へ」という仕様変更がありましたが、そのせいなのか無関係なのか不明ですが、とても不思議な挙動があらわれます。先日2時間で10kmほど移動した際には、移動時間は大体正確だったのですが、移動距離が「0m」となっていました。Googleマップが移動距離を計算する内部ロジックがどうなっているかわかりませんが、正確な移動距離を求めることは難しいかもしれませんが、0mは流石に変だろう(しかも2時間ほど移動しているんですから)と思います。


Webには「どんどん重くなるGoogle マップのタイムライン機能」という記事もあり、Googleマップのタイムライン機能は利用されているようです。僕自身の感覚としては、重くなっているとは感じませんが、間違って記録されているルートを手作業で修正しようとするとエラーが出て変更できなかったり、記録されているルートが(ちょっとどころではなく)大幅に間違っている時があるなど、不満がないわけではありません。それでも、そういう挙動であることを承知した上で使う分には、便利ではあると思っています。

2024-06-30

グレーターデーモンの「養殖」はできるけど・・・

ワードナを倒し、ひとまずミッションは達成しましたが、BISHOPをレベルアップするため、もう少しB10Fを冒険しようと思います。BISHOPの成長は遅いので、できれば経験値が多い魔物と闘いたいところです。このような目的にピッタリなのが、俗に言う「グレーターデーモン養殖」です。

 

グレーターデーモンは強敵だし、仲間を呼び出すので、迂闊に戦うと全滅してしまいます。ところが、MONTINOで呪文を封じておくと、呼ばれた仲間も呪文が封じられた状態になってしまうようなのです。呪文が封じられたグレーターデーモンは、それほど強くありません。たまに毒をくらったり、麻痺したりしますが、その程度です。こちらも攻撃の手を緩めて闘えば、トータルでは大きな経験値を稼げます。

 

ただし、グレーターデーモンに対してMONTINOを唱えても、呪文を拒否されてしまう可能性が高いことです。複数のグレーターデーモンがいたとして、MONTINOで呪文を封じられたのが1体だけだったとします。ここで仲間が呼ばれた場合、呪文が封じられた状態なのか、呪文が使える状態なのか、見分けられないと思います。

 

MONTINOを拒否したグレーターデーモンが呼んだ仲間が来てしまったとしたら、経験値稼ぎをするどころか、かえって全滅の危機に瀕してしまいます。このような危険性がないわけではありませんが、グレーターデーモンを養殖するという技は、うまくいけば、経験値を稼ぐ方法として優れていると思います。

2024-06-28

ワードナを倒した

今年2月頃からWizardry #1の冒険をすすめていましたが、ついにワードナを倒しました。まだパーティのレベルに不安が残っていたので(特にBISHOP) 、もうすこしB10Fでレベルを上げてから、万全を期してワードナと対戦しようかと思っていました。しかし、まずは練習がてらにと思い、ワードナの部屋に入ったところ、あっけなく勝負がつき、アミュレットをもって地上に戻ることになりました。

これで一段落したわけですが、ワードナとは何度でも闘えるので、B10Fをウロウロしてレベルを上げるとか、パーティの校正メンバをクラス変更してみるか、それともWizardry #2を始めるか、考えているところです。


ワードナとの闘いに勝利したパーティは、こんな感じです。BISHOPは、結局MAGEもPRIESTも呪文を最後まで覚えませんでした。こういうことになるから「BISHOP不要論」が出るのかもしれませんが、僕としては、宝箱から出てきたアイテムを鑑定するのに役立ったので、BISHOPがいて良かったとは思います。

 

  1. N-FIG DWARF LEV:25、H.P.:212、A.C.:-8
    1. HELM+1
    2. PLATE MAIL+2
    3. GLOVES of SILVER
    4. BLADE CUSINART'
    5. SHIELD+3
  2. N-FIG DWARF LEV:26、H.P.:226、A.C.:-4
    1. HELM+1
    2. SHELD+1
    3. GLOVES of COPPER
    4. PLATE MAIL+2
    5. BLADE of CUSINART'
  3. N-FIG HUMAN LEV::24、H.P.:212、A.C.:-6
    1. GLOVES of COPPER
    2. PLATE MAIL+2
    3. HELM+1
    4. SHIELD+3
    5. BLADE CUSINART'
  4. E-BIS GNOME LEV:20、H.P.:79、A.C.:4
    1. SMALL SHIELD
    2. MACE+2
    3. LEATHER+2
    4. MAGE:9/9/9/8/4/0/0
    5. PRST:9/9/9/5/5/0/0
  5. G-MAG ELF LEV:24、H.P.:137、A.C.:9
    1. ROBES
    2. KEY of BRONZE
    3. KEY of SILVER
    4. KEY of GOLD
    5. STATUE of BEAR
    6. STATUE of FROG
    7. DAGGER+2
    8. BLUE RIBBON
  6. N-THI HOBBIT LEV:27、H.P.:169、A.C.:1
    1. LEATHER+1
    2. SHIELD+1
    3. SHORT SWORD+2
    4. RING of MALOR
    5. STAFF of MONTINO


パーティは、中立+善で組んだのですが、B9FやB10Fを探検中、弱いわりに経験値が多い魔物に遭遇した際に強制的に戦闘に持ち込んでいたら、「悪」に変わってしまいました。職業によって、悪であったり善であることが条件となっていますが、どちらでも構わない場合に善悪どちらで構成すれば良いのか、よくわかりません。

2024-06-26

Will o'Lisp

C言語を学び始めた頃、当時アスキー出版が出していた『Cプログラムブック』を読んで勉強していました。とくにその第3巻は「Will o'Lisp」というLISP言語をC言語を使って実装してみるという内容で、とてもおもしろかったのを覚えています。しかもソースプログラムも掲載されていましたから、それを打ち込んで、実際に動かして見ることで、C言語そのものもLISP言語も勉強になりました。


今となっては書籍を手放してしまいましたが、また読んでみたいと常々思っていました。つい最近になって国会図書館のデジタルコレクションを検索してみると「Cプログラムブック3(Lisp処理系の作成)」として閲覧できる事がわかりました。

 

この処理系の名前もそうですし、バージョン名がMADIとかCALFOのようになっているのを見ても、Wizardryを意識しているのはあきらかです。

 

それはともかく、この書籍が出版された当時は、MS-DOSの時代でしたし、Microsoft CとかLattice Cなどが使われていた時代でした。今はFreeBSDやUbuntuなど、当時から見たら夢のような環境が一般化していますので、これらの上で動作させてみるのも面白い気がします。


2024-06-21

Wizardry #1のB10Fは手強い

Wizardry #1のB10Fを探検しています。ワードナの部屋の直前までは辿りつきましたが、まだ対戦する自信がありません。B10Fでレベルアップに励んでいます。パーティは、最低限のレベルはクリアしているのですが、これでも運が良ければワードナに勝てるかもしれませんが、まだ不安です。

  1. N-FIG(L14,HP139,AC-6) GLOVES of SILVER,BLADE CUSINART'
  2. N-FIG(L18,HP148,AC-4)
  3. N-FIG(L15,HP134,AC-6) SHIELD+3
  4. G-BIS(L15,HP74,AC4) MAGE:9/9/7/3/0/0/0,PRST:9/8/4/4/0/0/0
  5. G-MAG(L17,HP92,AC9) MAGE:9/9/9/9/7/5
  6. N-THI(L18,HP83,AC1) 

 

楽々と勝てる魔物もいますが、強敵を相手にすると、あっという間に死んでしまったり、逃げ遅れるとパーティが全滅してしまったりします。これではワードナに立ち向かうのは、まだ早いと感じます。


冒険の途中で、PRIESTをBISHOPにクラス変更したので、未だに全レベルの呪文を覚えていません。BISHOPはそういうものだということは知っていたうえでクラス変更しているのですが、それでも早く全レベルの呪文を覚えて欲しいと思っています。このような事になりがちなので、Web上にある記事を読むと「BISHOP不要論」が見つかります。それも尤もですが、僕としては宝箱を開けて見つかったアイテムを鑑定できるのは、とても良かったと思います。

 

Windows10上のPC98エミュレータを使っているため、デュプリケートディスクを複数残しておけます。そうすれば、仮にパーティが全滅したり、誰かがレベルをっ下げられてしまっても、以前のデュプリケートディスクを使ってゲームを再開することができるのは、助かっています。

 

ともかくパーティ全員がレベル20を超えるくらいまではB10Fをウロウロして、それからワードナとの闘いに挑もうかと考えています。

2024-06-18

キーボードの特定のキーだけが入力できない

Windows10のデスクトップPCは、キーボードに「FILCO FKBN108ML/NFB2」を使用しています。10年ほど前に購入したもので、埃が溜まっていたり、汚れがついたりはしていますが、昨日までは問題ありませんでした。


今日起動したところ、「f」キーだけが入力できません。それ以外のキーは入力できているので、キーボードが認識されていないとか、キーボード本体が壊れたのではないと思います。特定のキーだけスイッチ機構が壊れているのではないかと思います。

 

まずはキートップを外して、エアジェットで埃を飛ばしてみましたが、元に戻りません。キーボード裏側のビスを外して、基盤を確認してみましたが、特に問題があるようには見えませんでした。故障が疑われるスイッチ自体を取り換えれるという方法も考えられますが、パーツを入手する手間も考えると、敷居が高いと感じます。


IMEパッドにあるソフトキーボードを使うことは可能ですが、使い勝手が良いとは言えません。キー入力ができないのは致命的なので、早急に代替キーボードを購入しようと思います。

2024-06-17

盗賊を忍者にクラス変更した方がよいのだろうか

Wizardry #1は、満を持してB10Fの探検を始めました。手ごわい相手もいますが、少しずつ前進しています。戦いを終えて宝箱から「DAGGER of THIEVES」を見つけました。さらに別の戦いの後には「SHURIKENS」も手に入れました。


パーティーには「HOBBIT」でレベル16の「N-THI」がいます。後列にいるので、先頭には参加していません。もし忍者にクラス変更したら、前列で戦闘に参加させた方が良いのでしょうか。でも、パーティーには戦士が3人いるので別に困っていないし、もし盗賊から忍者にクラス変更したらレベルを上げるのに時間がかかってしまうんじゃないかという懸念もあります。また属性が「N」なので、このままで「SHURIKENS」を利用できるんだろうかという不安もあります。


Webの記事を読んでいると忍者は垂涎の的らしいのです。しかしもっと早い段階で忍者に変わっていたならともかく、B10Fの探検を始めてしまっているので、いまさらという気がしてなりません。

2024-06-14

NotebookLMが凄いらしい

Web上で「NotebookLM(GOOGLE)を試す(仮)」という記事を見かけました。Googleが提供する「NotebookLM」というサービスがあるそうなのですが、それを利用してシミュレーションゲームのルールブックなどを覚えさせて、ゲームをするときに活用しようという内容です。


記事では、ASLにも言及していましたが、僕自身としてはオリジナルのSquad Leaderシリーズで利用してみたいと思います。元々のSquad Leaderは、戦術級シミュレーションゲームとして登場し、最初からルールが細かくて大変でした。それに輪をかけて、COIやCODが出るたびにルールが追加変更されていき、増築に増築を重ねて見通しが悪くなった建物のように、複雑すぎるゲームになってしまいました。その反省を踏まえてASLで仕切り直しをしたはずだと思うのです。ところが、こちらも次々と拡張されていって、時々スターターキットという「基本ルールだけで遊べる」はずのモジュールが発売されています。そのスターターキットすら何種類も登場していて、全くの初心者は何から始めたら良いのか、よくわかりません。


それはともかく、オリジナルのSquad LeaderのルールブックをNotebookLMに与えてみたら、どうなるのか興味があります。ゲーム解析するにも役立ちそうです。


昨今のChatGPTブームには懐疑的でしたが、NotebookLMには可能性を感じます。

G-BISからE-BISへ

Wizardry#1は、B9Fまでの探検を終えて、いつでもB10Fに下りられるところまできています。しかし魔物と戦っている最中にレベルを下げられてしまったので、しばらくはB9Fをウロウロして、全員がレベル13以上になるか、BISHOPが全レベルの呪文を覚えるまでは、B10Fに行くのを待とうと思っています。

 

善と中立でパーティを組んでいるためなのか、「友好的な」魔物と遭遇することがあります。しかしEarth Giantに遭遇したら、あまり強くない割には多くの経験値を貰えるので、闘いたいところです。そうして闘い続けていたら、善のBISHOPが悪のBISHOPに変化してしまいました。そういうことはあるようです。 


パーティは善と中立で組んでいたので、城でパーティを組もうとしても、善悪が混じる構成には出来なくなりました。仕方ないので、悪のBISHOPだけは独りで迷宮に入り、一旦ゲームを中断して城に戻り、善と中立のメンバで組んだパーティが迷宮に入ったところで、合流することになりました。

2024-06-12

其子どもは、諸衛の佐になる

昨年から『平家物語』を暗唱しようと思っていて、ようやく「鱸」に入りました。これは「祇園精舎」と「殿上闇討」の次ですから、巻第一の最初の方です。この調子では、全巻はおろか第一巻すら覚えられない気がしますが、それは別に構わないのです。

 

ところで「鱸」の冒頭は、次のように始まります。

 其子どもは、諸衛の佐になる。

 

つまり忠盛が御所で地位を得たことにより、その子である清盛や忠度なども栄華を極めようとしているのです。


それはともかく、「其子どもは」というのは、使われている文字が古態ですが、現代文でも違和感なく読めるでしょう。しかし古文では「其/子/ども」と区分して理解するのではないかと思います。現代文なら「其/子ども」と理解するでしょう。

 

今日では、「子ども」というのは複数を意味しないので、複数であることを強調したければ「子ども達」となります。しかし古文では「兵ども」のように「ども」は複数を意味する言葉ですから、一人なら「其子」だし、複数なら「其子ども」となるところでしょう。

 

「其子ども」を、古文風と現代文で発音しわけるのは、ちょっと難しいかもしれません。「其子」の後に、僅かに間をいれて「ども」に続ければ古文風に、「其」の後に、僅から間を入れて「子ども」に続ければ現代文風に聞こえるでしょうか。

2024-06-09

「殿上闇討」まで暗唱できるようになった

昨年晩夏より語り本系の『平家物語』を暗唱できるようになろうと、最初から覚えています。暗唱できるようになったから何かあるのかという訳でもありませんが、どこまで出来るのが挑戦しています。最初の「祇園精舎」は、短かったし、有名な「祇園精舎の鐘の声」で始まるので、意外とすぐに覚えられました。

 

次の「殿上闇討」を覚え始めたのは去年11月頃でしたが、かなり苦戦し、最近になってようやく覚えきりました。

 

その次は「鱸」で、さらに次は「禿髪」です。この調子で覚えていっても、『平家物語』は長いので最後までいくとは思えませんが、挑戦し甲斐があるのは確かです。

2024-06-08

NIGHTSTALKERにレベルを下げられた

Wizardry #1でB9Fの探検を済ませ、B10Fに落ちる場所も判っていますが、まだ経験値が足りないし、呪文も覚えきっていません。しばらくB9Fをウロウロして、レベルを上げようと思っています。

 

と、思っていたところが、NIGHTSTALKERに遭遇し、レベルを下げられてしまいました・・・ 

やられた!と思いましたが、さらに別の場所で再び遭遇し、さらにレベルが下がりました。

冒険を重ねてきて、ようやくレベル13まで来たのに・・・

 

Webを探すと「ある意味、死ぬよりもいやなこと」のような悲しい報告が見つかります。

2024-06-07

Wizardry #1 でB9Fまで探検終了

今年初めから、Windows10上のPC98エミュレータを使用してWizardry #1の冒険を続けてきました。各階のマップを作りながら地下に下りてきましたが、ようやくB9Fまで探検を終了しました。B10Fに落ちる場所も判明したので、いよいよ最終局面に向かうことはできるのですが、まだ冒険者たちの準備が整っていない気がします。


冒険中にPRIESTをBISHOPにクラス変更したためかもしれませんが、呪文の覚えが悪く、高いレベルの呪文を覚えきれていません。またパーティ内の冒険者はレベル13に達しようとしており、B10Fに下りるための最低限のレベルではありますが、もう少しレベルを上げておいた方が良さそうな気がしています。

 

レベル13ともなると、次のレベルに上がるための経験値も大きいし、大きな経験値が得られる魔物がなかなか出てきてくれません。そうは言っても、B9Fで時間をかけて、レベルを上げ、満を持してB10Fに下りようと思います。

2024-06-05

「になります」の敬意の度合い

ここ最近と言わず、もう十何年も前から指摘されているのが「~になります」という表現です。食堂な何かを注文し、それがテーブルに届いたときに、「お待たせしました。○○になります」と言われることがあり、とても違和感があります。同様に感じる人は多く、Web上にも「「~になります」?」のような記事があります。

 

このような表現をする本人の意図は、聞いてみないと分かりませんが、敬意を表しているつもりなのではないかと思います。例えば食堂で「日替わり定食」を注文したとしましょう。これがテーブルに届いた際に、どのような表現が(本当にそう表現するかは別にして)考えられるでしょうか。敬意の度合いに応じて示してみると、以下のようになりそうです。

  1. 「日替わり定食。」(あまりにもぶっきらぼうで、もうちょっと何か言えよと思うでしょう。)
  2. 「日替わり定食だ。」または「日替わり定食である。」(上の例よりはマシですが、こんな表現をする店には二度とこないでしょう。)
  3. 「日替わり定食です。」(丁寧で、ごく普通の表現かと思います。)
  4. 「日替わり定食でございます。」(お店によっては、こういう表現もあるでしょう。)


では「日替わり定食になります」という表現をする場合、上述した1~4のどのあたりに相当すると思っているのでしょうか。もしかすると、4番目と同等か、さらに敬意が高いと思っているのかもしれません。つまり、「日替わり定食です」という言い方は、お客「様」に対して失礼だから、「日替わり定食になります」という「べき」だと思っているのかもしれません。


結局のところ、本当の理由は不明なのです。このような話題が掲示板などで盛り上がると、こう表現している側から、「マニュアルでそういうように決まっているんです」と発信されるのを目にする事があります。本当にそういうマニュアルが存在するのかは裏付けがとれる訳ではありませんが、そういう風に言うように指導されていたり、もしくは(仮に間違っているとしても)よく耳にするので、そういうものだと考えていて、自発的に言っている場合もあるのではないかと思います。

カリー化の定義

数年前からHaskellを学んでみようと何度も試みていますが、なかなかハードルが高いと感じています。今までに慣れ親しんでいたC言語とかPythonなどとは大きく異なるので、これまでの経験や勘が働かないことも、困難さの原因のような気がします。いろいろと理解が難しい概念があるのですが、そのひとつが「カリー化」です。

 

関数プログラミング入門 ―Haskellで学ぶ原理と技法―』の「1.4.2 カリー化」で説明されていますが、とても簡潔なので、これだけでは良く分かりません。Webを検索すると、カリー化に苦しんでいる人が多く様々な記事が見つかります。いろいろと読んでみると、「カリー化談義」に次のように書かれており、なるほどと納得しました。

「複数の引数を取る関数」を「一引数を取る関数のチェインに直す」こと。これはkmizuさんの定義。世間でもよく使われる。


カリー化というのは、Haskellに限った話ではなく、Pythonなどにも適用できるようです。しかしカリー化を前面に押し出してくるのは、やはりHaskellならではとは思います。


ともかくHaskellは、関数型プログラミング言語なので、慣れるのに苦労しそうです。前述の書籍を読んでいこうと思っているのですが、図書館で借りているので返却しなければならず、じっくり読むことが出来ません。手元に置こうかと思っていたのですが、放送大学のディスカバリーサービスで検索してみたら電子書籍として参照できることが分かりました。これがあるなら、いつでも読めると思います。

2024-06-03

hreflink

LaTeXで資料を作成する際に、生成されたPDFにおいてセクションに対するリンクを張るために、パッケージ「hyperref – Extensive support for hypertext in LaTeX」を利用しています。このパッケージを使えば、目次から該当するセクションに対してリンクが張られるので、文章を参照する際に便利です。

 

ここで問題になるのが、本文中でセクションにリンクを張るには、どういう方法があるんだろうかという事です。同じような疑問を持つ人はいるようで、StackExchangeに「Making clickable links to sections with hyperref」という質問がありました。そこで勧められているのが「\hyperref{}」を使うことでした。ただし、この方法には前提として「\label{}」で予めラベルを作っておかなければなりません。この方法がLaTeXとしては正しいのだろうと思うのですが、予めラベルを作っておく必要があるというのが、どうもスッキリしません。

 

パッケージ「hyperref」ならば、目次から該当セクションにリンクが張られているので、何らかのラベルが自動的に付与されていると思います。これを参照すれば何とかなるんじゃないかと考えて調べてみました。その結果、拡張子TOCというファイルで使えそうな情報が記録されているようです。


例えば、文章の最初に「1 はじめに」とあったなら、TOCファイルには「section.1」として定義されています。これを利用して、本文では「\hyperlink{section.1}{はじめに}」のように記述しておけば、生成されたPDFにおいてリンクが張られていました。これからは、この方法でいこうと思います。

 

正統なLaTeXとしては、TOCファイル内の「section.1」のような番号は変わる可能性があるので、直接参照するのは間違っていると考えるでしょう。全くそのとおりだと思います。パッケージ「hyperref」か、その他の何かのパッケージで、僕が求めている機能があるなら、それが最も望ましいのですが、正しくない方式であったとしても、当面はこうしようと思います。

2024-05-21

トウモロコシの種まき

数年前から、家庭菜園としてトウモロコシを育てています。庭に雑草が生えるよりも、何か食べられるものが育った方が気分的に悪くないという程度の動機なので、あまり手間をかけているわけではありません。NHKの番組で紹介されるように、土作りをしたり、マルチを張ったりすることもできるのでしょうが、もっとイイカゲンで、雑な感じです。それでも夏になれば収穫できるので、自宅で育った野菜が食べられるというのは嬉しく思います。

 

さて5月も後半になり、気温が上がってきているので、そろそろ種まきをしようと思います。これまでは直播きにしていました。1つの場所に3粒ほど種を播いて、発芽し、成長してきたら、勢いのあるものを残して、他を間引きしていました。しかし何故か分からないのですが、発芽しなかったり、成長が極端に悪い場合があります。所詮は家庭菜園ですので、本格的な農家のように広々とした農地という訳ではないのです。たかが1~2メートル四方くらいなのに、なぜこれほど成長に差が出てしまうのかと、毎年思っていました。

 

今年はポットに撒いて発芽させて、頃合いをみて移植してみようかと思います。この方法なら、発芽したものだけを地面で育てられるでしょう。一つだけ気になるのが、移植するタイミングで、苗にショックを与えることになり、根ずくことなく枯れてしまうことです。ともかく、やってみない事にはなんとも言えないので、これも経験だと思って、試してみようと思います。

2024-05-20

Kuuk Thaayorre

放送大学教養学部で2024年度第1学期は「グローバル時代の英語('22)」を受講しています。TEDトークや独自のインタビューを素材にして、グローバル時代における英語の役割について考える講義です。英語そのものを学ぶわけではなく、英語で表現ざれている内容に焦点がおかれています。そのトークやインタビューについて、先生方が自らの体験や考えを述べることが聴けて、とても刺激を受けます。

 

第7回は、Lera Boroditskyの「How language shapes the way we think」でした。現在本人はスタンフォード大学で教鞭をとっているようですが、元々の出身はベラルーシで、英語は4番目(に学んだ?)言語だそうです。そのトークの中に、クウク・サアヨッレ語について言及があります。この言語は、よくある言語とは大きく発想が異なっていて、話者本人を基準にした相対的な位置表現である「右」や「左」という単語が存在しないそうです。その代わりに、絶対的な方位表現となる「東」や「西」が用いられるようで、それがトークでも言及されるのですが、日本語で聞いたとしても発想の転換を要する内容なので理解に苦労するところなので、それを英語で話されると、直ちに了解できるわけでもありません。


Webを使って参考資料を探してみたら、日経サイエンスの2011年5月号に「言語で変わる思考」という記事が掲載されていることを知りました。この記事をダウンロードは出来るようですが、無料ではなく、税込み509円でした。こういう時に、放送大学に在籍していると放送大学附属図書館にある「電子ブック・電子ジャーナル」が助かります。ここには「日経BP記事検索サービス 」があるので、これを使えば学生なら自由に閲覧できる訳です。


その記事は、元々はSCIENTIFIC AMERICANの2011年2月号に掲載された「How Language Shapes Thought」という記事の翻訳でした。こちらは自由に閲覧できるようです。しかし、当然ですが、英語です。

2024-05-17

Firefox’s Enhanced Tracking Protection (Strict Mode) is known to cause issues on x.com

今日の午後、ツイッター(現X) を閲覧しようとしたら、表記のようなエラーが出るようになりました。確かに僕はFirefoxのセキュリティ設定を厳格にしています。この設定を緩めてみると、閲覧できることは確認しました。


Web上には「「twitter.com」から「x.com」へのリダイレクト開始 ~「Firefox」などではトラブルも」という記事が出ています。どうやらサイト側が原因のようなので、待っていれば修正されるのではないかと期待しています。

2024-05-13

スマイル0円

マクドナルドには「スマイル0円」というメニューがあります。現実の形がある商品というよりも、「裏メニュー」という扱いかと思います。しかし、僕自身は目にしたことがありませんが、店頭のメニューボードにも記載があるようなので、「裏メニュー」という訳ではないのかもしれません。


それに比べると、吉野家などで牛丼を注文したときに「つゆだく」と指定するのは、まさに「裏メニュー」でしょう。餃子の王将には「よく焼き」などの指定もあるそうで、これもまた「裏メニュー」でしょうか。

 

「スマイル0円」にしろ、「つゆだく」にしろ、「よく焼き」にしろ、これらはいずれもレシートにも印刷されるようなので、「裏メニュー」というような隠れた存在ではなく、現実には業務システムで公認された「表メニュー」のひとつではないかとも思います。

santoku,n

The Japan Times WeekendのApril 27-28, 2024号に、「The unexpected ways in which Japanese words 'make it' into English」という記事が載っていました。日本語の単語が英語の辞書に掲載されたようです。記事には「Here is a list of the 23 Japanese words that made it into the Oxford English Dictionary last month.」として、その単語が掲載されていました。

 

 リストを見ると、「donburi」とか「katsu curry」とか、こんな単語が辞書に掲載されるのかと思うものばかりでしたが、ローマ字の並びを見ても直ちにはピンとこないものがありました。それが「santoku, n」です。なんの事かと思いましたが、「三徳」のことのようです。三徳とは、肉・野菜・ 魚をひとつで済ませられる包丁のことです。こだわりのある人ならいざしらず、家庭では、肉用、野菜用、魚用と別々の包丁を用意することはないでしょう。


英米の普通の家庭で、どのような包丁を使っているのか、わかりません。レストランのような専門的な場合であれば、肉用とか野菜用とか、それぞれに専門的な包丁を使っているのかもしれませんが、こだわりのない一般家庭では、1本の包丁で全てこなしてしまうのではないでしょうか。

 

洋の東西を問わず、事情は何処でも同じじゃないかと思います。それなのに、Oxford English Dictionaryに「santoku」が載るようになったとは、やはり驚きです。

2024-05-06

【重なら】

「Amazon」から発信したと見せかけるメールのSubjectが「【重なら】お客様のお支払い方法が承認されません。」となっていました。そもそもメールのFromがアマゾンではないので、どうやらSPAMメールなのでしょう。


本文には「お支払方法に問題があり、プライム特典をご利用いただけない状況です。」とあります。「え~、それは困ったな」と思うところなのかもしれませんが、そもそも僕はAmazonプライムを利用していないのですが。

 

しかもSubjectにある「【重なら】」 って、何でしょう?日々SPAMメールが届きますが、「【重要なお知らせ】」となっているものがあります。もしかして【重要なお知らせ】を省略して「重なら」にしたんでしょうか。日本語には数々の省略語がありますが、こういう風には略さないと思います。

2024-05-05

真空管が使われていた頃の無線機の信頼性はどのくらいだったんだろう

電子機器の部品としてトランジスタが発明されたのは1947年です。それ以前からラジオや(送信もおこなう)無線機は存在していましたが、真空管が使われていたはずです。その頃の無線機の信頼性がどの程度だったのか、何か事情が分かるような資料があるのか知りませんが、あまり良くはなかったのではないかという印象があります。21世紀の今となっては、歴史的なジョークなのかもしれませんが、テレビやラジオが壊れたら「叩けば直る」と言われていました。それは実体験に基づく真理だったのかもしれません。しかし、よく考えてみると、電子部品の接触不良が、叩くことで導通するようになっただけではないかという気がします。

 

さて第二次世界大戦が勃発した際に、ドイツ戦車には無線機が装備されていたそうです。「化学者のためのエレクトロニクス講座」という記事には、次のような記述があります。

すなわち、緒戦におけるドイツ軍の華々しい勝利は必ずしも兵器の性能によるものではなく、無線の発展が可能とした新戦術によってもたらされたものとも言えるのです。


第一次世界大戦で登場した戦車は、第二次世界大戦では主力兵器として使われました。その運用方法がドイツ軍は卓越していて、無線機が搭載されていたことで相互の連携をとることが可能となり、「電撃戦」と呼ばれる成果を上げたとされています。


しかし当時の無線機の信頼性はどうだったのでしょうか。戦車は悪路も走行しますし、森林だろうが家屋だろうが、何でも構わず突っ込んでいきますから、相当振動も激しかっただろうと思います。しかも機関銃や大砲で打たれたりもしますから、無線機が壊れた通信できなくなることがあったのではないかと思います。

 

戦闘中に搭乗員が車外に身を乗り出すのは危険ですし、車中から外を見ようしても良く見えないでしょう。だからこその無線機なのですが、その無線機は真空管を使っていた筈で、信頼性が必ずしも良くなかったと思います。それは戦闘にどのような影響を及ぼしていたのでしょうか。

2024-04-28

Wizardry #1でB5Fの探検を完了

Windows10上でPC98エミュレータを使って、Wizardry #1の冒険を愉しんでいます。B4FでBLUE RIBBONを手に入れ、B5Fの冒険をしていました。Wizardry #1では、B5F~B8Fを探検して時間を費やす必要はないという意見もあるようです。エレベータを使ってB9Fに下り、そこで冒険した方が、経験値を得られるし、効率が良いということです。それはそのとおりなのでしょうが、急いで地下深く下りてミッションをクリアしなければならない理由はない(誰かに早くしろと脅されている訳ではない)ので、のんびりと地下に下りていこうと思います。

 

B5Fがクリアできたので、次はB6Fです。

京都駅のみどりの券売機は混んでいる

京都駅の構内図を確認すると、 2Fにある西口改札の近くに「みどりの券売機」と「みどりの券売機プラス」が設置されています。両方合わせて5台設置されています。それほど広くないので、利用待ちの行列ができたとしても、数人しか入れません。


ところがニュースにもなっているように、京都には観光客が殺到していて、券売機にも長蛇の列が出来ていることがあります。さらに困ったことに、「みどりの券売機」と「みどりの券売機プラス」とでは、出来ることが違うので、並んで待っている人が、どちらを待っているのか判らないのです。

 

「みどりの券売機プラス」のために待っている人が行列の先頭の方に数名いると、その後ろに「みどりの券売機」を使いたくて並んでいる人が、列を抜かしても構わないものか咄嗟の判断がし難いのです。そうならないようにするには、駅員さんが常駐して交通整理をするのが理想的ですが、そもそも券売機を設置する理由として駅員さんの負担を減らすためだと思うので、券売機があるのに駅員さんもいるのは本末転倒なのでしょう。


JR京都駅は混雑が酷いですが、コロナ禍の頃を思えば有り難いことなのかもしれません。それにしても券売機コーナーの混雑を放置していては困ると思います。

2024-04-17

Wizardry #1でBLUE RIBBONを入手した

昔懐かしいPC98版Wizardryを、Windows10上のエミュレータを使ってプレイしています。ようやく地下4階に到達し、ついにBLUE RIBBONを入手しました。冒険を始めるときに、地下迷宮のどこかにあるらしいコントロールセンターを探すようにと言われていたので、中間目標を達成したことになります。

 

最終目標は地下10階ですから、まだまだ冒険の道のりは長いですが、のんびりプレイしていこうと思います。

2024-04-16

FreeBSD上のtexdocが表示しようとしているPDFをWindows上で参照する方法

FreeBSD上にTeXlive 2024をインストールして利用しています。普段使いのマシンはWindows 10なので、LaTeXを組版するためには、ちょっとしたスクリプトを用意して、WindowsからFreeBSDに処理を投げて、その結果のPDFをWindowsに戻しています。これで特に問題は無いのですが、ごく稀にTeXliveにあるPDFを参照したくなる場合があります。


TeXliveには膨大なPDFが同梱されており、「texdoc」というコマンドで参照できるようです。このコマンドは、内部でxpdfを起動してPDFを参照しているようなので、それをWindows上に出力するには何か仕組みを用意する必要があります。もっとも簡単なのは、Windows上でXサーバを起動しておく方法でしょう。うまいぐあいにASTEC-Xを持っているので、その方法は可能ですが、普段はASTEC-Xを起動していないので、もうちょっと別の方法を考えたいところです。

 

調べてみるとtexdocは、 「viewer_pdf」という設定項目があり、これがPDF出力をコントロールしているようです。デフォルトがxpdfになっている訳ですが、独自の設定をおこなうこともできそうです。もし独自の設定をするのであれば、ホームディレクトリに「~/texmf/texdoc/texdoc.cnf」を用意して、そこに記述するのが推奨されています。

 

例えば、「texdoc latex」と実行すると「/usr/local/texlive/2024/texmf-dist/doc/latex/latex-doc-ptr/latex-doc-ptr.pdf」を表示しようとするようです。僕は、FreeBSD側にSambaを入れてあり、/usr/localを参照できるようにしているので、このパスをWindows側で参照すれば、Windows側でPDFを参照する事は出来るのですが、なにしろパスが深いので、あまり簡便ではありません。


FirefoxなどのブラウザでPDF閲覧をおこなうならば、さきほどのパスが「file://///FreeBSD/local/texlive/~」のようになっていてくれれば、その出力結果をカットアンドペーストしてブラウザに貼れば簡単ではないかと思いつきました。そこで「~/texmf/texdoc/texdoc.cnf」に次のような行を入れて実験してみました。

viewer_pdf = (echo %s ) | sed -e 's|/usr/local|file://///FreeBSD/local|'

このようにしておいて「texdoc latex」を実行すると、端末に次のような出力が出てきます。これをクリップボードにコピーして、ブラウザに貼り付ければ、たちどころにPDFが出力されます。この方法で、いけそうです。

file://///FreeBSD/local/texlive/2024/texmf-dist/doc/latex/latex-doc-ptr/latex-doc-ptr.pdf

 

2024-04-12

ICOCAはSuica

Webで「「Suicaでお願いします」と言ってICOCAで決済する理由 交通系ICカードあるあるに共感の声」という記事を見かけました。この記事では、次のような記述があります。

みやこさんがこのような設定にしているのは、「ICOCAを知らない地域の店員さんを困惑させない為」だそうです。

 

ここ数年は、お店で支払いをする際に交通系ICカードを利用できる事があります。SuicaICOCAなどのJR各社のICカードは、昔は各社バラバラでしたが、現在では(サービスに若干違いはあるものの)運賃の支払いなどでは共通的に使えるようになっています。僕自身は、昔は複数のカードを持っていましたが、共通的に使えるようになってからはICOCAに集約することにしています。

 

ここで問題になるのが、Suicaエリアで交通系ICカードを使おうとする場合です。上述した記事にも書かれていますが、僕自身も当初は交通系ICカードが利用できる店舗では、「ICOCAで支払います」と言っていました。そう言うと店員さんは「?」という表情を浮かべるのです。そこで助け舟を出す感覚で「Suicaで払います」と言い換えていました。でも実際に使うのは、Suicaではなくて、ICOCAです。

 

Suicaを使わないのに「Suicaで支払います」と言うのは間違っているんじゃないかと考えたので、次には「交通系ICカードで払います」と言ったこともあります。しかし店員さんは「?」となるので、結局「Suicaでお願いします」と言っておいて、実際にはICOCAを使うのが、最もトラブルを避ける方法だと学習しました。

 

これはJR東日本エリアの場合ですが、JR北海道エリアであれば「Kitakaで支払います」と言いつつICOCAを使い、JR九州エリアなら「SUGOCAで支払います」と言ってICOCAを使うことになるでしょう。