「James Clark 記法」に関するメモ

備考1

備考2

これは「ときに要素間ホワイトスペースの量を最小化するために使われる一般的でないスタイル」などと呼ばれるような手法のことを指している。

<!DOCTYPE Html>
<Html
 ><Head
   ><Title
     >2022年夏季卒業式</Title
   ></Head
 ><Body
   ><H1
     >卒業</H1
   ><Section
     ><……
 …………
 …></Section
   ><Section
     ><H2
       >卒業生</H2
     ><Ul
       ><……
    ………
 ……></Ul
   ></Section
 ></Body
></Html>
http://www.html5.jp/tag/elements/section.html

備考3

なお、「James Clark notation」というフレーズは、James Clark によるXML名前空間に関するメモ「XML Namespaces」（ http://www.jclark.com/xml/xmlns.htm ）などで使われている、「プレフィックス : 」の部分を実際の URI に展開して波括弧で囲んだ、

{http://relaxng.org/ns/structure/1.0}element

というような記法のことを指して使われていることが（英語圏では）ある（ http://dvreeze.github.io/yaidom-and-namespaces.html ）。

X Window System の Meta キーを設定した話

Macのキーボードにはコマンド（Cmd）キーがあり、シフト・コントロール・オルト（Alt）と同様の修飾（モディファイヤ）キーとして使えます。

Linux等ではメタ（Meta）キーが相当するキーとして扱える場合がありますが（たとえば、Mozilla の JavaScript のドキュメントにある表にそうある https://developer.mozilla.org/ja/docs/Web/API/KeyboardEvent/getModifierState#Modifier_keys_on_Gecko ）手元の環境（FreeBSD）の X Window System で単にキーアサインを設定しただけではうまく行かなかったので、その顛末です。

まず X Window System の基本事項を確認します（X Keyboard Extension (XKB) のことは、とりあえず忘れます）。

X Window System のキーボードまわりには、

  • キーコード
  • キーシム
  • 修飾

の3要素があります。それぞれ、

  • キーコードはキーボードの各ボタンに対応した番号で、基本的には直接に機能には対応しない
  • キーコードからキーシムにマップされることで、何らかの機能と結び付けられる
  • シフト状態などの修飾はキーシムからさらにマップされる

といったようになっていて、xev というツールでXのイベントとして確かめてみると、

state 0x4, keycode 37 (keysym 0xffe3, Control_L)

（抜粋）といったように表示されますが、ここで state とあるのが、修飾キーの状態を示すマスクです（なお、state はその修飾キー自身の押下時のイベントでは設定されない）。

失敗篇

手元のキーボード（ユーシーテクノロジ(株)製造・パーソナルメディア(株)販売の「μTRONキーボード」）で手頃なキー（「Menu」キー）のキーコードが 117 だったので、

keycode 117 = Meta_L NoSymbol Meta_L

のように設定してみたのですが、なぜか修飾としてはAltキーと同じ扱いとなってしまい、うまくいきませんでした。

状況確認

（実際にはここであれこれ悩んでいたわけですが）xmodmap コマンドで修飾のマッピングを確認してみると、

$ xmodmap
xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_L (0x25),  Control_R (0x6d)
mod1        Alt_L (0x40),  Alt_R (0x71),  Meta_L (0x9c)
mod2        Num_Lock (0x4d)
mod3
mod4        Super_L (0x73),  Super_R (0x74),  Super_L (0x7f),  Hyper_L (0x80)
mod5        Mode_switch (0x8),  ISO_Level3_Shift (0x7c)

と、なんやら妙なことになっています。これでは同一視されてしまうに決まっています（Meta_Lのコードが0x9cになっているのは、前述の設定より前の状態）。

余談ですが、今までキーコードとキーシムの設定にしか xmodmap コマンドを使ったことがなかったので、なんか変な名前だなと思っていたのですが、引数無しのデフォルトで表示される本来はこちらがこのコマンドの主目的で、そこから派生したとか、多分そんな理由なのですね。

ついでに関係しそうなキーコードとキーシムのほうも調べてみると、

$ xmodmap -pke | grep -e Alt -e Meta
keycode  64 = Alt_L Meta_L Alt_L Meta_L
keycode 113 = Alt_R Meta_R Alt_R Meta_R
keycode 125 = NoSymbol Alt_L NoSymbol Alt_L
keycode 156 = NoSymbol Meta_L NoSymbol Meta_L

となっていました（これも、起動後の初期状態のもの）。

解決篇

状況がわかってしまえば簡単で、今度からは一発で設定できるように次のようなファイルを作っておきます。

$ cat my_modmap.txt
clear mod1
clear mod3
keycode 125 =
keycode 156 =
keycode  64 = Alt_L NoSymbol Alt_L
keycode 113 = Alt_R NoSymbol Alt_R
keycode 117 = Meta_L NoSymbol Meta_L
add mod1 = Alt_L Alt_R
add mod3 = Meta_L

モディファイヤを設定する時に、キーマップの状態からの影響があるので、「モディファイヤをクリア、キーマップを設定、モディファイヤの再設定」という順序になるようにします。mod1がAltキーのモディファイヤ、mod3がMetaキーのモディファイヤです。

謎のマッピングがあったキーコード125と156はマッピングを消しておきます。Altキーがシフト状態ではMeta扱いになるという設定も消して、単純に Alt_L と Alt_R にマッピングします（ここでは示しませんでしたが、左右のShiftとControlは元から同様になっています）。Meta_L も同様に設定します。

最後にモディファイヤの設定をします。Meta_R も、設定だけでもしておきたい気もしますが、ここではそのままLだけを設定しました。

設定した後で、状態を確認すると、以下のようになります。

$ xmodmap my_modmap.txt
$ xmodmap
xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_L (0x25),  Control_R (0x6d)
mod1        Alt_L (0x40),  Alt_R (0x71)
mod2        Num_Lock (0x4d)
mod3        Meta_L (0x75)
mod4        Super_L (0x73),  Super_R (0x74),  Super_L (0x7f),  Hyper_L (0x80)
mod5        Mode_switch (0x8),  ISO_Level3_Shift (0x7c)
$ xmodmap -pke | grep -e Alt -e Meta
keycode  64 = Alt_L NoSymbol Alt_L
keycode 113 = Alt_R NoSymbol Alt_R
keycode 117 = Meta_L NoSymbol Meta_L

Antec P182マシン、大改修・完結篇？

というわけで、その後以下のように手を加えました。

  • 大騒ぎの原因の一つだったグラフィックカードですが、結局ロープロファイルでショートサイズのカードに変更
  • PCIスロットの空きスロットの蓋を、空気穴が無いタイプに総取替
  • 上面排気ファンは、中段前面で補助吸気ファンとしての使用に変更。排気穴は物を置いて塞いでいる
  • 排気ファンは煙突(？)で上段前面側に排気（5インチベイを全部潰して14センチファンを最低回転数で利用）
  • BIOSの設定で最低回転数（PWMのデューティ比20%）まで落とす方法がわからなかったため、PWM制御信号を発生するArduino工作品を追加
  • CPUクーラーをScytheの兜3に変更。手頃な大きめのトップフロータイプなら何でもよかったのですが、日本ブランドのScytheで、ということで
  • ファンレスのグラフィックカードのヒートシンクが「触るとちょっと熱いかな」ぐらいになるので、PCIスロットに付けるタイプのファンステイ（アイネックスブランド。作りは長尾製作所っぽい気もするが、長尾からは販売されていない？　タイプのもの）に無理矢理斜めに付けた、9センチファンで補助冷却（こちらも回転数を下げて利用）

CPUクーラーの空気流の余りで周辺も冷却したい所なので、兜3標準の12センチファンから14センチファンへの装換を実験していたが、ワイヤークリップを自作する必要があり、さらに14センチファン（Scythe製品ではないものを使用）の個体の問題か振動がひどく異音を発生させるために断念。

だいたいこんな所でしょうか。

Antec P182マシン、大改修

前に書いた通り、電源とマザーボードを新調したわけですが、この際ということで大幅な改修を行うことにしました（画像は改修後）。

  • 大型のグラフィックボードとの干渉で難儀していたHDDを下段に移動、中段ケージを撤去
  • 同様に、張り出していて、パラレルATAケーブルが邪魔でもあった光学ディスクドライブも撤去
  • 元々は強制排気・自然吸気の、強い負圧タイプが前提のケースだが、下段前面にファンを追加し強力に吸気を行うことで、HDDの強制冷却と同時に、ケース全体を正圧に近づける
  • 下段と中・上段のエアフローを分離する当て板は撤去し、下段吸気は積極的に上にも流す
  • （下段の中間に元々あったファンは以前に撤去済み）

という方針で、完全な再組立を行いました。サーバ的な管理された環境にあるマシンであれば負圧のケースも良いのかもしれませんが、ホコリを避けられない環境ということもあり、フロントパネル内側など、吸気のせいで、かなりえらいことになっていました（正圧にこだわるなら SilverStone あたりに買い替えたほうが素直かも？）。

まずこのケースで難儀するのが下段前面ファンで、P183など後継機と違い、それっぽい空間があるものの12cm角ファンの設置はかなり無理をともないます（こちら http://day8ge.blog15.fc2.com/blog-entry-503.html の報告にありますように、不可能ではありませんが）。

ひとまわり下のサイズの9cm角（25mm厚）のファンで検討してみたのですが、実際に収めてみると、下段ケージのハードディスクとの間にほとんど間隔が無く、ファンの性能や騒音にも悪影響がありそうで、諦めました。今回の私の選択とは逆に中段にHDDをまとめ、下段がガラ空きであるとか、マウンターを選べばSSD化で前面側に余裕があるとかであれば、（フィルタの爪との干渉の問題もありますが）ここにファンを置くのも悪くないでしょう。

私は思い切って、ケースの前にファンを取り付けてしまうことにしました（写真では側面が写っています）。当然、扉は閉められなくなるので取っ払ってしまい、防音はかなり諦めることになります。通風のため、ケースの金網状の部分は、ファン取付のための角の部分を除いて、ハンドニブラで切除してあります（四隅の角が、ほぼちょうど12cmファンの取付穴の位置にあります）。ホコリ対策は十全にする必要があるので、フィルタを挟み込むタイプの組立式のファンガードを付け、100円ショップにあった使い捨ての、換気口用の15cm角の不織布フィルタを入れています。

（以下、続き）

通風改善のため、電源のATX24線とCPU Power Connector8線は裏配線に回しました（後継のケースでは裏配線の使い勝手はかなり改良されていますが、P182では上下チャンバの分離が優先されていて、あまりたくさんは使えません）。その他、下段にあるので結構長さが余るSATAの電源線などは、中段にのたくらせることで下段および全体の通風の改善を図っています。

また、チップセットとCPU電源部の冷却のための、4cm角で10mm厚のファンがユーザ追加のオプションで取り付けられるマザーボードで、メーカーによる解説では吸気になっているのですが、やはりバックパネル付近がホコリを吸うので（バックパネルの吸入口からダクトを付ける手もありますが）排気の向きで付けました。すると全体のエアフローの設計として、ケース側であるP182の後部排気ファンを付けると排気を奪い合ってしまいますから、上部だけの排気としました。

チップセットのヒートシンク付近の構造物の形状が吹付け前提で、逆にすると効果がだいぶ落ちるんじゃないかという気はしますが（そういえばこれまでどこにもマザーボードについて書いてないですが、Sabertooth 990FX です）、マニュアルにも書いてないギミックですので気休めだと思って気にしないことにします。

この4cmファンには、山洋のものでこのサイズでは回転数が最も高いの（6200RPM, 109P0412H901）を選びました。絶対的な騒音としては他の大径ファンのほうが大きいものの、高音の騒音が出るので取付方法を改造したいと思っている所です（その他にもこの日記を書き始めた後にあれこれ手を加えているのですが、それはまた別の記事とする予定）。

PCの電源を買った

無理な延命等が祟ったようでもあり、PCの電源が、2代目か3代目となるマザーボードと一緒に（原因がどちらの側かは不明瞭）壊れたため、現行のCPUとDIMMとの組合せでは多分最後となるマザーボードと、電源を買った。

というわけで以下検討過程などのメモ。

  • せっかくなのでTitanium認証の高効率型の電源にしてみよう

調べてみると、1000W級と比べ、700W級でTitanium認証の電源は多くない（10%負荷時に90%の効率を要求してるからなー……）。現在、日本で一般的に市販されているものには、基本的には、以下の2系統のものしかない。

Seasonic のほうは、日本国内代理店のオウルテック扱いのものが購入できる。

Enhance のほうは、Enhance ブランドではサイズから以下の2モデルがある。

  • ATX-1850GB (500W)
  • ATX-1870GB (700W)

（いずれもセミプラグイン。 http://www.scythe.co.jp/power/ragepower-titanium-plugin.html ATX-1850GBは販売終了）

他に玄人志向と SilverStone ブランドによるOEMないしODM（ブランド元による設計のカスタマイズがどの程度入っているかは未把握）がある。いずれもプラグイン化や筐体サイズ（奥行）はいろいろ。

玄人志向のラインナップは、

SilverStone のラインナップは、

（いずれもフルプラグイン。日本国内代理店は、マスタードシード・ディラック・CFD販売・他？）

といった感じである。

結局、ST60F-TI を買ったのだが、実物で確認した所、ファンが Silver Stone の SST-AP123（のカスタム版？）になっていた（SST-AP123 http://www.silverstonetek.com/product.php?pid=402 ）。

特徴的な大中小の3種類x3のブレード

「徹甲弾」ファンの特徴的なグリルが確認できる

ブレードの色違いや、単体製品の SST-AP123 には回転数制御は付いていないことから、カスタム版だと思われる。

SICPと、6.001の話

調べていたところ、「弱LisperがMITでSICP(シクピー)を受講した結果」（ http://qiita.com/kaz-yos/items/d1ecd4bfe9989c290e99 ）というQiita記事を見つけたのでリンクしておきます。噂の(？)SICPを懐かしむチューターたちによって実施されている特別授業に潜り込んだ(？)方によるレポートです。

本題の、以前はSICPだった授業である6.001が、どのようになぜ変わったか、という話がこちらのページ（ http://wingolog.org/archives/2009/03/24/international-lisp-conference-day-two ）にあるのですが、その部分だけ訳してみます。

本文のなかほどの「The "debate" had an interlude, in which Costanza asked Sussman why MIT had switched away from Scheme for their introductory programming course, 6.001.」という所から始まっていますが、そのちょっと先、because〜 から。

because engineering in 1980 was not what it was in the mid-90s or in 2000. In 1980, good programmers spent a lot of time thinking, and then produced spare code that they thought should work. Code ran close to the metal, even Scheme -- it was understandable all the way down. Like a resistor, where you could read the bands and know the power rating and the tolerance and the resistance and V=IR and that's all there was to know. 6.001 had been conceived to teach engineers how to take small parts that they understood entirely and use simple techniques to compose them into larger things that do what you want.

なぜなら、1980年代のエンジニアリングは、90年代中頃や2000年代のそれとは違ったものだったからだ。1980年代には、良きプログラマは思考に時間を掛け、そしてそれが働くべきと考えられる簡潔なコードを作った。コードは金物の近く（close to the metal）で走っていた、Scheme でさえ -- それは全て理解可能だった。例えば抵抗器のように。抵抗器はカラーバーを読むことができ、電力と許容差がわかり、抵抗値がわかれば V=IR それが全ての知るべきことだ。6.001 はエンジニアに、全てがわかっている小さいパーツをどのように扱い、シンプルなテクニックを使ってそれをどのように望むことをする大きなものにまとめ上げるか、を教えるためにあった。

But programming now isn't so much like that, said Sussman. Nowadays you muck around with incomprehensible or nonexistent man pages for software you don't know who wrote. You have to do basic science on your libraries to see how they work, trying out different inputs and seeing how the code reacts. This is a fundamentally different job, and it needed a different course.

しかし今のプログラミングは全くそのようなものではなくなっている、とサスマンは言った。こんにちでは、知らない誰かが書いたソフトウェアの、不十分だったり存在しなかったりするman pageと格闘しなければならない（訳注: ここでman pageを悪い例っぽく挙げているのは「The Rise of “Worse is Better”」のMIT/New-Jerseyの対立っぽい感じがある）。使おうとするライブラリに対して、異なった入力に対しコードがいかに反応するかを見て（seeing how the code reacts）確かめて、それがいかに働くかを見る（see how they work）「基礎科学」（basic science）をする必要がある。これはファンダメンタルに違うジョブであり、違うコースが必要なのだ。

So the good thing about the new 6.001 was that it was robot-centered -- you had to program a little robot to move around. And robots are not like resistors, behaving according to ideal functions. Wheels slip, the environment changes, etc -- you have to build in robustness to the system, in a different way than the one SICP discusses.

And why Python, then? Well, said Sussman, it probably just had a library already implemented for the robotics interface, that was all.

新しい 6.001 の良いことは、ロボットを中心に据えたことだ -- 小さなロボットを動き回らせるようプログラムしなければならない。ロボットは、理想的な関数の通りに働く抵抗器のようではない（are not like）。車輪はスリップするし、環境は変化する、など -- システムにロバストネスに構築しなければならず、それは、SICPが議論しているのとは違ったやり方だ。

そして、なぜPythonか。それはたぶん、単に既にロボットのインタフェースのためのライブラリが実装されてあったこと、それが全てだ。

ARMの設計（デザイン）

Oral History of Sophie Wilson（ http://www.computerhistory.org/collections/catalog/102746190 ）から、ARMの設計（デザイン）に関することのメモ

（主に、6502との関係について）

  • ARM以前のほとんどのマシンで6502を使用しており、6502での経験はあった
  • しかし、他のプロセッサを載せるボード（8ビット機時代によくあったもの）で他のプロセッサも使っていた
  • それでも6502が良い、と思っていた。メモリアクセスの帯域を有効に使っている、という所から（他のプロセッサではそこのバランスに問題があった）
  • （ビデオプロセッサが画面表示に間に合ってアクセスするためには、メモリアクセスにある程度の帯域幅が必要であり、その性能をメインプロセッサも生かせるのが、当時の「バランスの良い」デザイン、ということになるのだろう）
  • ARMの設計（デザイン）については、このバスアクセス帯域について以外には、（命令セット等）6502の影響があったというようには読み取れない

ARMの成功要因は何だろうか？（きしもとの私見による分析を含む）

  • 明解で単純な目標の設定、例えば
  • 6502の代替となること
    • (それまでのマシンでは機械語プログラミング等のテクニックの駆使が必要だったことを、高水準言語でできるように）
  • 「IPM PC 互換機の洪水」に対抗すること
  • スローガン「MIPS for the masses」（この「MIPS」は、プロセッサというよりは（それもあるが）性能のことを指している）。当時、他のRISCプロセッサは、ワークステーションを指向していて高価だった
  • 前述の「他のプロセッサを載せるボード」として、まず動くベンチとなるシステムを作ったこと
  • むやみに大きなプロセッサにしなかったこと（最初のプロセッサは25000トランジスタ）もあって、最初からちゃんと動くものを作ったこと。インタビュー中では、ナショセミのNS320xxがいつまでもまともに動かなかったことと比較している