[本] ステーションの奥の奥(山口雅也)

子供向けのミステリーランドのシリーズの一つ。
でも、大人顔負けの作品があったりするので油断できないシリーズ。
突拍子もない展開でびっくりしてしまった。
今回は、大人顔負けとはいかなかった。

[Soft] Vim in Cygwin

Cygwin環境のVimの起動がなんか遅いと思ったら、
~/.vim/keymap があるせいだったようだ。
コンパイル時に -keymapにしてるのに。
自宅で、CygwinのVimを使う場面は限られているので、もっと軽くしたいところ。

[Ruby] Win32OLE (1.9 New feature)

1.8 では WIN32OLE::ARGV を使うしかなかったが、
1.9 では WIN32OLE_VARIANT を使うこともできる。

ie = WIN32OLE.new('InternetExporer.Application')

  ...

ie.execWB(19, 0, nil, 1)

puts WIN32OLE::ARGV[3]

を

ie = WIN32OLE.new('InternetExporer.Application')

  ...

obj = WIN32OLE_VARIANT.new(nil, 

  WIN32OLE::VARIANT::VT_VARIANT|WIN32OLE::VARIANT::VT_BYREF)

ie.execWB(19, 0, nil, obj)

puts obj.value

と書くことができる。

ふと思ったのだが、

obj = WIN32OLE_VARIANT.new

は、

obj = WIN32OLE_VARIANT.new(nil,

  WIN32OLE::VARIANT::VT_VARIANT|WIN32OLE::VARIANT::VT_BYREF)

というのはどうだろうか。

[Ruby] Win32OLE

WIN32OLE_VARIANT に関しては、まだまだ、課題がいろいろありそうだと思う今日このごろ。

腕時計

時計が止まった。
電池交換してもらって復活した。1200円なり。
「そろそろ、(時計の)寿命かもしれない。」と言われた。
何となく20年以上使い続けてきた。
この際、使えるだけ使い続けようと思う。

[Ruby] Win32OLE

要望は今までなかったと記憶しているのだが、lcid (locale id)を指定できるようにしようと思った。

試しに EnumSystemLocales でリストアップしたら、

00000411

と8桁の文字列になることがわかった。

Win32OLEでは、数値でlcidを指定できるようにしたい。

WIN32OLE.lcid = 0x0411

WIN32OLE.lcid = 1041

EnumSystemLocalesのリストとの比較は、割り切って、

snprintf(str, sizeof(str), "%08x", 1041);

で変換した str でやっちゃおうと考えている。

[Haskell] YAHT

8.2まで読了。type synonym と newtype は、初めて知った(と思う。)

[Haskell] YAHT

Chapter 7 読了。
foldr は、すんなりとわからない。
じっくり考えて、やっとぼんやり、わかってくるような感じだ。

[Haskell] YAHT

7.10まで読了。
Finite Map のキーのtypeは、Ordのインスタンスでなくてはならない。
Eqのインスタンスじゃ駄目な理由は、"balanced trees"にしたいから。
高速にアクセスアクセスするために、tree構造をしていて、そのためには、
キーのtypeはOrdのインスタンスでないといけない。

ということだろうか。

[Ruby] Win32OLE

すべてのテストをtest/win32oleに移動。
なんかすっきりした。

[Haskell] YAHT

7.8まで読了。List に感するあれこれ。
遅延評価とList、map の数学風の表現など。
遅延評価のおかげで、上(下)限を気にしなくてもいいのがHaskellの特徴。

[Ruby] VT_CY in Win32OLE

いまは、

WIN32OLE_VARIANT.new("\100", WIN32OLE::VARIANT::VT_CY).value 

は、String の "100" になるんだけど、数値の100になるべきか。
Stringになるのは、Perlがそうだったからだと思う。

[Ruby] Win32OLE

trunk の Win32OLEで、WIN32OLE_VARIANT 関連をいじった。
WIN32OLE_VARIANT::Empty、WIN32OLE_VARIANT::Null、WIN32OLE_VARIANT::Nothingを追加した。
WIN32OLE_VARIANT::Emptyは使い道がある。
WIN32OLE_VARIANT::Nothingも使い道があるはず(ruby-list:35445)。
勢いだけで追加したが、WIN32OLE_VARIANT::Nullって使い道があるんだろうか。

[YAHT] Haskell

7.8.1まで読了。mapなどのListを扱う関数の定義。
再帰的な定義がいかにも関数型言語っぽい。

[YAHT] Haskell

7.7まで読了。
いくつかのClassの紹介、Named Field など。

[Haskell] YAHT

7.6.2 まで読了。
折り返し点通過。
Haskell の Class は、抽象クラスみたいな気がした。
RubyでいうModuleに相当する気がしてきた。

[Haskell] YAHT

7.5まで読了。 matching の機能をさらに一歩進めたような guards の話。

[Ruby] Win32OLE Leaks

単純なミスだった。
コミットした。
trunk, ruby_1_8, ruby_1_8_5, ruby_1_8_5(CVS) の4つにコミット。
つかれた。

[Ruby] WIN32OLE Leak

単純なミスのような気がしてきた。

[Soft] メモリーリーク

メモリーリーク関係でGoogleで検索したら、
Visual Leak Detector
と遭遇。これは、Express Editionでも使えるかな。
その前に、_CrtSetDbgFlag と _CrtDumpMemoryLeaks を試すのが先か。

[Haskell] YAHT

7.4読了。
matchingの話。
こういう機能があると、分岐処理を書かなくてすむ。
2つ1つの関数定義は短くなるし、そのケースだけ考えればよいので、わかりやすい。
が、下手に分割するとそれぞれの関数で同じ処理を書かなくてはならなくなる
という危険性もある。

[Ruby] WIN32OLE leaks

WIN32OLEの件を調べてみた。
が、さっぱりわからない。

添付されているjpeg ファイルからすると
ole_invoke で呼んでいる rb_scan_args の中の ruby_xmalloc で確保したメモリが開放されていないということ？
しかし、そんなところがおかしいとは思えない。問題があるとすれば、きっと別のところに違いない。
と考えながら、調べてみたものの、手も足も出ない。

[Haskell]YAHT

7.3まで読了。
curry とか、uncurry とか、flip とか、今まで、よくわからなかった関数がすこしわかった気がする。
こういう関数が用意されているところが、関数型プログラミング言語らしいと言えるのかな。

[Haskell] YAHT

7.2 読了。 where と let の話。

letの方がwhereより読みづらいと感じるのは、何故だろうか。 Cの関数だと変数定義が先なので、letスタイルの方が近いはずなのに。 多分、let の後の in に違和感を感じているのだと思う。

[Haskell] YAHT

7.1まで読了。

map (+ 3) [1, 2, 3]

は、大丈夫で、

map (- 3) [1, 2, 3]

は、なぜ駄目かという話など。

- 3 は、数の「-3」と解釈されるから。

ちなみに、

map (+ (-3)) [1, 2, 3]

は、大丈夫。

[Haskell] YAHT

6.3、6.4を読了。
6.3は、階層的なImportの話。
6.4は、文芸的プログラミングの話。

[Haskell] YAHT

6.2まで読了。Importで関数などの名前衝突をどのように避けるかという話。

[Soft] tcvime

T-Codeとは交ぜ書き変換のキーマップが違うので、かなり戸惑う。
そもそもT-Codeをさくさく使えないので、今の私には実際に使うのは厳しそう。

[Soft] Vimで日本語

skk.vim。
VimでSKKを使うためのスクリプト。
CygwinでコンパイルしたVimでも使えそう。好感触。

tcvime。
Vimでtcodeの交ぜ書き変換ができる。
まだ試してない。

[Haskell] YAHT

6.1 Exports まで読了。

[Ruby] Win32OLE

trunk から ext/win32ole/doc 配下を消した。
win32ole.c の rdocのコメントと二重メンテナンスが面倒だから(放置したままになっていた)。

今後は、win32ole.cのコメント(rdoc)を充実させていくぞと決意を新たにした(←本当か？)。

[Soft] Vim で ChangeLog

cygwinでもSubversionでコミットできるようにしようかと思い、ChangeLog編集のためにemacsをインストールした。
が、ChangeLogファイルを開いてもうんともすんとも言わず、ファイルを開いてくれない。
(極端に遅いだけなのかも知れないが)動きがおかしいので、emacsを使うのはあきらめることにした。

Vimだとどうするのかと思ってGoogleに聞いてみたところ、
VimでChangeLogを編集する方法がちゃんと見つかった。

~/.vimrcファイルに

let g:changelog_timeformat = "%a %b %e %H:%M:%S %Y"

let g:changelog_username = "MyName  <my mail address>"

を追加した。

Ruby の ChangeLogファイルを開いて \o と入力したら、
emacsのときと同じようにChangeLogのエントリが追加された。
素晴らしい。

[Haskell] YAHT

中断していたのを再開。Chapter 5まで読んだ。 問題5.2の回答例だと指定したファイルが存在しないときにreadさせたときの 動作が出題通りにならないと思う。 その辺は10.1まで進まないとわからないということで。

ブランクがあったため、結構忘れてる。

[Comp] ck 2.0.25

バージョンアップ。 いつか画面分割できるようにならないかなあ。 マルチスクリーンバッファの機能があるので重宝している。 一時期使っていたscreenもcygwinでは使わなくなってしまった。 唯一の不満と言えば、screenと違って画面分割できないこと。

バッファの切り替えやバッファの新規作成は ~/.Xdefaults に

Ck*accelKey_newShell: altL,ctrlL,T
Ck*accelKey_nextShell: altL,ctrlL,N
Ck*accelKey_prevShell: altL,ctrlL,P

と書いてキーを割り当てている。

Alt+Ctrl+T でバッファ増やして、Alt+Ctrl+N や Alt+Ctrl+Pでバッファを切り替えて使っている。 結構便利。

[本] 眼を開く (マイクル・Z・リューイン)

マイクル・Z・リューインの新作、しかも久々のアルバート・サムスン復活とくれば、もうこれは読むしかない。

今回は、私立探偵免許を取り戻したアルバート・サムスンが探偵として復活するまでの話。
アルバート・サムスンは、ひらめきで、ある事件を解決し、別の事件では、ひらめきで見当外れの推理をしてしまう。
ヒーローは必ずしも勝利するとは限らないほろ苦い展開だった。

それにしても、この作品のエンディングが気になって仕方がない。
「さあ、新たな冒険の始まりだ。みんなで頑張るぞー。オー!!!」という感じで
エンディングを向かえる少年ジャンプあたりにありがちな漫画と結末が同じなのである。
同じようにこのシリーズもこれで本当に終わってしまうのか、それとも、これまたありがちな漫画の
「次回、新章突入! 新展開にご期待ください!」という感じで続いていく展開を見せてくれるのか気になる。

でも、このまま続けちゃうと、サムスン一家のミステリになっちゃって、
『探偵家族』のルンギ一家と同じになってしまいそうで、それもちょっと嫌だ。

今後このシリーズが続くとすれば、ターニングポイントとなる作品だと思われる。
続かないとすれば、最終作ということになる。
どちらにしても、サムスンのファンにとっては必読の一冊。

今年の目標

3年前は、年間100冊読むという目標を立てた。

2年前は、本を読み過ぎたことを反省して、あまり本を読まないという目標を立てた。

去年は、翻訳物を読めなかったことを反省して、翻訳物を国内の作品より多く読むという目標を立てた。

今年は、まだ目標を決められないでいる。どうしよう。

[Ruby] trunk on Cygwin

久々にCygwinでminiruby.exeができないという現象に遭遇した。
ruby-devに投稿しようかと思っていたら、なかださんからパッチが出てた。
([ruby-dev:30086])

YARVとは全く関係ないのだけど手元でWin32OLEを一部修正しているものがある。
mingw(gcc -mno-cygwin)版でずっと作業してたのでCygwin版では確認してなくて
コミットする前に確認しようとしたらminiruby.exeができなかった。
コミットするのはcygwinでWin32OLEがコンパイルできる状況になるまで待った方がいいのかな。

いくつか変更点はあるんだけど、コミットは一気にやらず、段階的にやりたいと思ってます。

[Book] キングとジョーカー(ピーター・ディキンスン)

評判高い幻のディキンスンの作品がついに復刊。

そうは言っても、『眠りと死は兄弟』とか『ガラス箱の蟻』とか私にはどこが面白いのかわからなかったディキンスン。
しかも元はサンリオSF文庫から出てたということで、もしかしたらまともなミステリじゃないかも知れないと
期待半分で恐る恐る読んだのだった。

舞台は架空の英国王室。
他愛のないジョーク(いたずら)が徐々にエスカレートしてついには殺人へ。

ディキンスンの描く独特の英国王室の世界を楽しめるかどうかによって評価は分かれそう。
元々、「ミステリ文庫」じゃなくてサンリオ「SF」文庫から出てたというのも
何となくわからなくもないというぐらいにミステリとしては楽しめなかった。
というよりは、ミステリの部分が霞むほど、ディキンスンの描く架空の世界や魅力的な登場人物の方が強烈だと言うべきかも知れない。
この作品は、きっと、パラレル・ワールドとでも言うべき世界と
その世界に生きる王女ルイーズや乳母ダーディなど愛すべき登場人物達を楽しめばいいのだ。

SF好きな人やファンタジー好きな人がこの作品をどう評価するのか聞いてみたいところ。
かなり癖のある作品で万人には勧めづらいけれど、架空の英国王室の世界の雰囲気を楽しめる作品ではある。

[Book] 切り裂かれたミンクコート事件 (ジェームズ・アンダーソン)

『血のついたエッグ・コージィ』の続編。(血のついたエッグ・コージィは『血染めのエッグ・コージイ事件』として復刊されているが私が読んでいるのは『血のついたエッグ・コージィ』の方。)
登場人物がみんな怪しくて実はその正体がXXXというのが多過ぎ。
ご都合主義っぽいハッピーエンドの連続もどうかと思う。
この犯人の設定は、別のミステリで読んだことがあるし、
平凡な探偵の設定は、レオ・ブルースには一歩及ばない気がする。
『血のついたエッグ・コージィ』のできが良かったので、期待が高い分、辛口の評価になってしまった。
それでも、本格ミステリのパロディとして読んでいて楽しい作品であることには違いない。