試しにページングファイルを無効にしてみました。
というのも、タスクマネージャでコミットチャージの最大値を確認すると 600MB 強 (普段通りの使い方で色々と無茶をしても 500MB 前後) であり、実メモリの 768MB 以下ならば不要だろうと思ったからです。
まあ、さすがに大きい画像を激しく編集するのは無理になりましたけど、そういうことは滅多にないですし、そもそもその手のことで HD をガリガリ言わせたことは一度もありませんから多分大丈夫。
さて、今のところは普段通りに動いていますが、これからどうなるやら。これが安定して使えそうならメモリを追加して 1G にし、256MB は RAM ディスクにしたいのですけど。
たまたまとある絵描きさんのサイトに辿り着き、何となくそのプロフィールを読んでみたところ、度肝を抜かれました。
使用している PC のスペックがおかしいのです。メモリ 12288MB (12GB)
とか、HDD 5000GB ぐらい
とか (大半はバックアップ用とのことですが)、桁を読み間違えたのかと何度も確認してしまいましたよ。何かの研究用やサーバーだったら解りますけど、そうでもないのにこれはすごい。スペックに劣らず外観もすごい。メモリの使い方も10GBをRamdiskとして使用
と羨ましい限り。
これもいずれは標準的なスペックになるのだろうけれど、後何年かかるやら。
Opera の M2 のような感じでブックマークを管理できたら楽しそうなのだけど、どうかなぁ。
作成中の Scheme の処理系の話。port 周りの修正をしていたついでに、current-input-port や with-input-from-filie を実装しようと思いつき、さっさと済ませてしまおうとしたのですが、いざ実装するとなるとなかなかややこしいことに気がつきました。
マルチスレッドを考えないとすれば、以下のように Scheme で実装することができます:
(define *unspecified* (if #f #f))
(define current-input-port *unspecified*)
(define with-input-from-file *unspecified*)
(let ((*current-input-port* useful-initial-value))
(set! current-input-port (lambda () *current-input-port*))
(set! with-input-from-file
(lambda (filename thunk)
(let ((old-port (current-input-port)))
(dynamic-wind
(lambda () (set! *current-input-port* (open-input-file filename)))
thunk
(lambda () (set! *current-input-port* old-port)))))))dynamic-wind を使うということは、それを実装言語レベル (C) でちゃんと実装しなければなりません。
しかも Scheme で実装するとなると、port の入出力手続きは全て以下のようにラッパーを作らなければならなくなり、まさに二度手間:
(let ((original-read read))
(set! read
(lambda port
(if (null? port)
(original-read (current-input-port))
(original-read (car port))))))という訳で、継続云々がちゃんと実装できるまでこれらの実装は不可能ということになります。
面倒だなぁ、と思ったのですが、そもそも with-input-from-file は有用なのかという疑問が。別に call-with-input-file で十分だと思うのですけど。それに with-input-from-file 自体、R5RS では optional procedure ですし。
エディタは vi 派なのですが、たまに「Emacs に移行した方がいいかなぁ」と思ったりすることもあります (一時期は Emacs を使っていましたし)。
一度、かなり前に Cygwin の setup.exe 経由で Emacs をインストールしたことがあるのですが、rxvt 上で起動すると何故か表示がぐちゃぐちゃになってしまい、使うことができませんでした (キーを押すたびに混沌具合が高まりますし)。
cmd.exe 上でなら本来期待される表示になるのですが、入力に問題があり、C-C が入力できません。Emacs のキーバインドなんてカーソル移動くらいしか頭に残っていないため、C-X C-C 以外の終了方法が解らずに往生しました。そうでなくとも C-C が使えなければ色々と話になりませんし、そもそも cmd.exe で使う気はないのでどうでもいいのですが。
さて、今日、ふと「表示がおかしい」==「端末周りが怪しい」ということに (今更) 気付き、色々と適当に試していたところ、環境変数 TERM の値を rxvt とすれば正常に表示されることが解りました (問題が起きた値は cygwin)。
ようやく色々と試すことができるようになりましたよ。でも疲れたし他にやりたいこともあるので Emacs を弄るのはまた今度。
数ヶ月前からちまちまと書いている Scheme の処理系ですが、ようやく eval 実装の手前まで来ました。eval は eval で厄介なのですが、取り敢えず一段落といったところ。
書いてて思ったのは、やはりテストは重要だということですね。少し書いて少しテスト。きちんとテストしていれば、コードを変更したことによって今まで動作していた部分に影響が出ているか否かすぐに分かりますから。それにコードが完成に近づいていることが感じられ、妙な自信まで湧いてきます。
ちなみに、現時点で本来のコードの量とテストコードの量の比率が 10:7 くらいになっています。read と write だけに限定すればテストコードの量が倍以上。最終的な割合はどうなるやら。
さー、さっさと eval を実装したいところですが、その前に既存のコードのアレなまま放置しておいた部分を修正しないといけません。放置しても動作に問題はありませんが、腐った部分をそのままにしておくとやる気が殺がれますからね。とはいえ、アレな箇所の多さ (大雑把に数えて 84 箇所以上) に出鼻からごっそりとやる気を殺がれていますが。
SCIP の Exercise 5.30 ですが、
Much worse is the problem of handling errors that are signaled by applying primitive procedures, such as an attempt to divide by zero or an attempt to extract the car of a symbol.
In a professionally written high-quality system, each primitive application is checked for safety as part of the primitive. For example, every call to car could first check that the argument is a pair. If the argument is not a pair, the application would return a distinguished condition code to the evaluator, which would then report the failure.
We could arrange for this in our register-machine simulator by making each primitive procedure check for applicability and returning an appropriate distinguished condition code on failure. Then the primitive-apply code in the evaluator can check for the condition code and go to signal-error if necessary.
Build this structure and make it work. This is a major project.
「百聞は一見にしかず」とはよくいったもので。実際に処理系を作成している過程で、エラー処理をどうしたものかと悩む悩む。上記の方法ではいずれ破綻しそうな臭いがしますし (和訳: 何が a major project
だこの野郎、という愚痴)。
風来の kana、フェイの最終問題を無事解いた。
無限増殖セットは反則だわ。昨日の続きですぐに変化の壺と 3 枚目の吸い出しの巻物を拾い、欲しいアイテムは (運依存で) 何でも手に入る状況になってしまいましたから。やろうと思えばいくらでもやれるのですが、増殖作業の単調さに飽きてしまうため、ある程度のところで切り上げてさっさと終わらせることにしました。
60 か 61 階からアークドラゴンが出てくるため、そこから底無しの壺 + 吸い出しの巻物で落とし穴を作成し続けて終了しました。簡単に進めるとはいえ、落とし穴の作成できない階や開幕モンスターハウスだった場合は色々と危険でした。一度、モンスターハウスから逃げようと落とし穴を作ろうとし、吸い出しの巻物を間違えて分裂の壺に使ったときは凹むと同時に死にかけましたが。
一応、一通り終えたので満足々々。気が向いたらまたプレイしますかね。
うはｗｗｗｗｗｗｗｗｗｗｗｗｗｗ 何かおかしいよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
何がおかしいって、アイテム運が異常なまでに高い。もう阿修羅級の豪運が舞い降りたとしか言いようがない。
この後もすごいことすごいこと。所持アイテムとの兼ね合いから 2 本目の剛剣マンジカブラを捨てるという場面まで起きる始末。吸い出しの巻物が後 1 枚あれば無限増殖セットが揃うというところまできました。
ただ、他のアイテムにいいものがなく、危機的な状況に陥った場合、装備品だけ抱えたまま終了しそうな感じでした。
「モンスターハウスが出たら終わりだよなー」と思いつつ 18 階まで到着。探索中、部屋に足を踏み入れると減速の罠を踏んでしまい、それと同時に一ツ目ハウスに突入。しかしモンスターがシレンから多少離れた位置にいたことと、やまびこの盾を持っていたこと、何より来た道を引き返せばすぐに階段があることが幸いし、戦闘することなく 19 階へ逃げることができました。
何とか切り抜けたか、と思ったら 2 分割フロアで開幕ゴーストハウス。ゴーストハウスのわりには何故か同階層で出現するモンスターも混ざっており、ただでさえ死神で死ねる状況なのに、ちびタンクがイッテツ戦車になってさあ大変。手持ちの無敵草で何とか振り切り、隣の部屋へ。イッテツ戦車が追いつかないうちに次の階へ逃げようかと思ったのですが、部屋が柱でいっぱいの格子状のもので、さらに部屋への通路はエーテルデビルが塞いでいるため、部屋のアイテムを回収してから次の階へ逃げました。
で、回収したのが吸い出しの巻物。ふはははははは! 無限増殖セット揃っちゃったよ! という訳で 20 階へ逃げて現在増殖祭り中。といっても弟切草と天の恵みの巻物しか使えるものがないのですけど。いくら剣が良くても盾がなければ死ぬのは目に見えているため、どうにかして地の恵みの巻物を調達したいところ。後は合成の壺をください。
SFC 版「風来のシレン」、ようやくフェイの最終問題に入れるようになりました。初回プレイでは 1 階から店があり、そしてお約束通りンドゥバにやられました。という訳で気を取り直して挑戦 2 回目。
さー、どこでコケるかな。
Paul Graham 著「ANSI Common Lisp」を読了 (実際に読んだのは日本語訳の方ですが)。丁寧な解説でなかなか解り易かったです。
言語の制約はそれを使う人の世界を制限する
という言葉がありますが、
私が初めてプログラムを書き始めたころ、それは Basic で書いていたのだが、再帰を使いたいなどとは考えなかった。そんなものがあることも知らなかったのだ。私は Basic で考えていたのだ。私は反復アルゴリズムしか知らなかったのだから、再帰を使いたいなんて考えられるわけがない。
うはは、昔の私そのままじゃないか! 誰しもこういう時代があるのだと感動してしまいましたよ。
SFC 版「風来のシレン」、食神のほこらもクリアできました。挑戦回数は 8 回。途中、いいところで落とし穴に引っかかることが 3 回もあって凹んだのですが、運良くモンハウに巡り合わないまま無事終わりました。
そして今更ながら気付いたのですが、中途半端な知識ではテーブルマウンテンよりも難しいことが解りました。他のダンジョンとは違って、フロアに一切アイテムが落ちていないからです。アイテムの取得手段は基本的にモンスターからのドロップ、特殊地形内の埋蔵品、そして店の三つだけです。そりゃ難しいに決まっていますよ。
しかし、肉の活用次第でどうとでもなるので、テーブルマウンテンと比べれば楽かも知れません。ボウヤー系の肉から木の矢と鉄の矢を 99 本回収すれば格段に楽になりますし、セルアーマーの肉で (運にもよりますが) モンスターからほとんどの盾が回収できますし、パコレプキンの肉があれば泥棒は簡単にできます。危険なモンスターはブフーの杖の一振りで解決してしまいます (杖がなければ弱いモンスターの肉で済みますし)。他にも色々。
また、経験値の稼ぎも比較的楽です。6〜7 階辺りで鬼面武者とまわるポリゴンが出現します。部屋の中にいるポリゴンは、シレンが部屋に入ったまま 1 ターン経たなければ絶対に動きません。 つまり、部屋の外から矢が当たる位置にいるまわるポリゴンのレベルを上げた後、外から矢を撃てば無傷で倒せます。今日はポリゴンのレベル上げの最中にさんざん落とし穴に落ちましたけどね。
さあ残りはフェイの最終問題だけ。しかし問題が一つ: フェイの問題をほとんどこなしていません。面倒。
先日買った SFC 版「風来のシレン」ですが、あっさり掛軸裏の洞窟もクリアできてしまいました。挑戦回数は十数回。さすがにテーブルマウンテンよりも上手くはいきませんでした。
そういえば、ワナ師の腕輪という反則なアイテムが初期装備にあるにもかかわらず、テーブルマウンテンよりも難しいのは何故だろうと思っていたのですが、今更ながらその理由に気付きました。出現アイテムの比率が全然違うからです。具体的な値は不明ですけど、明らかに違いますからね。一切出現しないものもありますし。これで嫌らしいモンスターが増えているのですから、テーブルマウンテンと同様に進められる訳がありません。
さて、次は食神のほこらか。今朝はいいところまで行けたのですが、途中で死神に囲まれて詰みました。ろくにアイテムがないのに、通路で壁の中から囲まれたら打つ手なんてありませんよ。
番付を確認したところ、挑戦回数は 9 回でした。
$@The file name of the target of the rule.
$*The stem with which an implicit rule matches. If the target is `dir/a.foo.b' and the target pattern is `a.%.b' then the stem is `dir/foo'.
昔使っていた LSI C-86 (試食版) 同梱の make で「$* は $@ から拡張子を取り除いたもの」となっていたため、ついついその感覚で Makefile を書いてはまりました。
大抵の場合だと $* が拡張子なしの $@ となるような implicit rules しか書きませんから今まで全然気付きませんでした。
タスクバーのアレは「Taskbar Notification Area」であって「Tray」と呼ぶのは誤り、という話。
最近無性にやりたくなってきたので購入。
のんびりやろうと思っていたのですが、7 回目でテーブルマウンテンを制覇できてしまいました。序盤〜中盤で運良く杖が一通り揃ったので、後半は逃げの一手。三つの試練は一時しのぎの杖 + 場所替えの杖で、最後は身代わりの杖 + 金縛りの杖で攻撃手段を封じてから無傷で突破できました。久々に魔蝕虫見たなぁ。萌え。
その後、掛軸裏の洞窟や食神のほこらも行こうと思ったのですが、まだイベントをこなしていなかったため、入ることができませんでした。掛軸裏はともかく食神の方はイベントこなすの大変ですよ。
用を足そうとトイレに行き、ふと便器の奥を見てみると楕円形の物体が……!
……と思ったのですが、よく見てみると妙に先端が尖ってるし厚みもない。正体は飾ってた植物の葉が落ちていただけでした。