Cygwin 1.7.22 が出ていたので更新したところ、Cygwin の gitk が動かなくなってしまった。Tcl/Tk を、Win32 ネイティブで動く 8.4 と、Cygwin/X で動く 8.5 とで切り替えてみたが、どちらも灰色の小さいウィンドウが表示されるだけで、動かない。
Win32 版の Git にも gitk があることを思いだしてそれを試してみることにした。Cygwin のプロンプトからでも gitk.cmd で起動できる。Cygwin 版とは異なり、ちゃんとビジュアルスタイルに対応しており、見栄えがよい。Cygwin のパーミッションが扱えないため、755 と 644 で差分が出てしまうのは面倒だが、仕方ない。
Windows で gitk を使うと、デフォルトの文字コードが cp932 になってしまい、UTF-8 を使っているリポジトリを見ようとすると、文字化けが起きてしまう。以下のコマンドを実行すれば、現在のリポジトリは UTF-8 として表示されるようになる。（--global を指定すれば、全てのリポジトリ。）
$ git config gui.encoding utf-8
Logicool の M525 マウスで、ホイールのチルトによる水平スクロールが動作しない。SetPoint をインストールして確認したところ、デフォルトの設定が、戻る/進む に割り当てられていた。
Golang をインストールしたら、cmd.exe を起動したときにタスクバーに表示されるアイコンが GoDocServer のものに変わってしまったり、Strawberry Perl をインストールしたら、そのアイコンに変わってしまったりという現象が発生して、気になっていた。
現象が起きるマシンと起きないマシンもあり、不思議に思っていたのだが、OS が 32bit だと発生せず、64bit だと発生することがあるということが判明した。Golang や Strawberry Perl は、32bit 版 cmd.exe に引数を付けたショートカットを作成し、独自のアイコンを設定した上で、スタートメニューに登録する。32bit OS では、32bit 版 cmd.exe に対するショートカットが「コマンド プロンプト」として予めスタートメニューに登録されている。一方、64bit OS では 64bit 版 cmd.exe はスタートメニューに登録されているが、32bit 版 cmd.exe は登録されていない。この状態で 32bit 版 cmd.exe を起動すると、スタートメニューに登録されている Golang や Strawberry Perl のアイコンが使われてしまうらしい。
対処方法としては、32bit 版 cmd.exe に対するショートカットを「コマンド プロンプト (32bit)」などとして、アイコンも cmd.exe のものに設定した上で、スタートメニューに登録しておけばよい。
Haswell マシンの消費電力を測ってみた。アイドル状態で 42W 程度。動画 1本エンコード時で 120W 程度。
i7-920 の時の測定結果によると、アイドル時 98W、動画 1本エンコード時 140W、2本同時エンコード時 180W。（i7-950 では測定していない。） 初代 Core i7 はバカ食いだった。
昨日買ったマシンを組み立て。まずは最小限の構成で組み立てて、不具合等がないか確認したが、特に問題は無さそう。
今使っている PC ケースのフロントパネルに USB 3.0 端子がないのが不便である。3.5inch ベイに、メモリカードリーダ、eSATA コネクタ、USB 2.0 コネクタ、USB 3.0 コネクタを載せる製品 (Ainex | AK-ICR-16) を見つけたので、それを使うことにした。
SSD、HDD、光学ドライブ、フロントパネル用の eSATA、USB 3.0 をつないだら、M/B の SATA コネクタ周りにケーブルが密集して、かなり組み立てづらかった。
動画のエンコード速度が、i7-950 に比べると 1.3〜1.4 倍くらいになった。消費電力も、後で調べよう。
6年前に買った V450 が無線 LAN と干渉するのが以前から気になっていた。無線 LAN で大量のデータを転送していると、マウスの反応が非常に悪くなってしまう。代わりとして M525 を買った。
Core i7-950 マシンが最近不調で、使っている途中に急に再起動が掛かったりする。半年ぐらい前にも同様なことがあり、そのときは、ビデオボードの埃を掃除したら正常動作するようになったのだが、今回はそれほど埃もたまっておらず、掃除しても効果がなかった。最近、Intel の新しい CPU (Haswell) も出たことなので、新しく PC を組み直すことにした。
| 部品 | 詳細 |
|---|---|
| CPU | Core i7-4770 |
| M/B | Gigabyte GA-H87M-D3H |
| Memory | Corsair CMZ16GX3M2A1600C10 (DDR3 PC3-12800 8GB * 2) |
| SSD | CFD CSSD-S6T256NHG5Q (東芝製 THNSNH256GCST) 256GB |
Mercurial の拡張に Patch Branches (pbranch) というものがあるそうだ。Mercurial Queues (MQ) と同様の拡張だが、複数人でのパッチの開発や、より長期的なパッチの開発に向いているらしい。確かに MQ だと、複数人でパッチを開発しようとすると、パッチに対するパッチを pull request することになったりして、訳が分からなくなってしまう。
pbranch のドキュメントを見ると、MQ のようにパッチを別のリポジトリで扱うのではなく、同じリポジトリで扱うらしい。Git に対する StGit と近いのかもしれない。
Vim の日本語 man を用意したところ、レイアウトが崩れるとの報告があった。調べた結果、man ファイルを ja ディレクトリに置いた場合は /usr/share/groff/1.21/tmac/ja.tmac が読み込まれるのだが、ja.UTF-8 ディレクトリに置いた場合は読み込まれないことが判明した。groff 側で、ja.UTF-8 などの場合も ja.tmac を読み込まれるようにしてほしいところだ。
Golang で Hello World を書いて、Win32 用の実行ファイルを作ったところ、1.2MiB ほどの実行ファイルができあがった。ファイルサイズを削減してみようと、Cygwin や MinGW の strip.exe を掛けてみたところ、動かなくなってしまった。
ビルド時に strip 指定を行えばよいようで、以下のコマンドでビルドしたところ、660KiB ほどになった。
> go build -ldflags -s hello.go
ところで、できあがった hello.exe がインポートしているシンボルを調べると、ntdll.dll の NtWaitForSingleObject を参照しているのだが、いったい何のために使っているのだろうか。
Go 言語の Windows 用パッケージは 32bit 版と 64bit 版が分かれているが、両方を同時にインストールすることはできない。32bit 版をインストールしたときに、64bit 向けにビルドしたいときや、その逆をするにはどうするのだろうかと思ったが、Golang では環境変数を設定してちょっと準備をするだけで簡単にクロスコンパイルができるようになっており、Windows 向けバイナリの 32bit/64bit の切り替えもその仕組みを使うとのこと。（参考: Go言語でクロスコンパイルする - memoメモ）
> cd \Go\src\ > set GOARCH=amd64 > set GOOS=windows > make.bat
make.bat を実行して 2分程度でクロスコンパイル環境が整った。後は、GOARCH と GOOS が設定された状態で、go build を実行すれば、指定したターゲット向けにクロスコンパイルできる。
最初は、Windows の 32bit/64bit 版の zip アーカイブを同じディレクトリに解凍したら make.bat を実行しなくても、クロスコンパイル用の環境ができるのではないかと思い、試してみたのだが、うまくいかなかった。make.bat を実行した場合は、go.exe が書き換わっていた。
ijexp32 で、表示をソートできるようにした。実行ファイルによっては、シンボルの順番がバラバラになっていることもあるが、これで、目的のシンボルが含まれているかどうかを簡単に探せるようになった。
検索機能も付けたいところだが、今回は見送り。