183勝目…、ならず

チラシの裏。

今回の西口は、まあ勝ちが付かなくても仕方ないかな。十分に援護はしてもらったのだし、あと1回くらいは投げてほしかった。厳しいスケジュールの真っ最中なのだから、特にね。
まあ、大勢つぎ込んだ投手が無駄にならなくてよかった。涌井の抑えは怖い。

MacでLaTeX

MacでLaTeXを使いたいと思って適当にググってみたところ、どうやらMacTeXというパッケージが定番らしいので、インストールしてみた。

さすがに定番だけあって、インストールはほとんど道なりに完了。いじった点は、カスタムインストールでTeX Live 2011以外を省いたことのみ。コマンドラインで使えれば十分だから、GUI Applicationsとかはいいや。

日本語は普通に通る。UTF-8が通ってるから、特に日本語に限った話ではなく、多言語対応してるのかな。documentclassで普通にjarticleも使えた。xdviは日本語表示できなかったけど、dvipdfmxで日本語PDFに変換できたので、まあ十分。

Kindleと消費税と私

いよいよ今度こそ本当に、Kindleが日本上陸しそうな雰囲気。
とりあえずTouchだけか。それとも噂の新型Fireとともに襲来するのか。そして何より、色々な業界にどんなインパクトを与えるのか。楽しみだなー。

ところで、既にAmazon.comから購入済みのKindleの扱いはどうなるのだろう。Amazon.co.jp対応ファームにアップデートしてくれたら嬉しいけど、そこまでは期待するのは酷かな？
どこで買っても同じなら、今のレートなら$200くらいまでは非課税だから、10%の消費税よりUSからの送料の方が安かったら、ちょっとした抜け道になったりして。

CMakeことはじめ

投げっぱなしだったCMakeの話を、ちょっとずつ回収して行こう。

まず、CMakeとはどんなものか？ 大雑把に言うとMakefile等を生成してくれる、Automakeのようなツール。Automakeとの大きな違いは、make以外のビルドシステムにも対応している点。CMakeはEclipseのプロジェクトも生成できたりする…、らしい。Makefile以外生成した事無いけど。

具体的なCMakeへの指示はテキストファイルに書き連ねる。ファイル名はCMakeLists.txt固定で、cmakelists.txtのような大文字小文字の違いも許されない(Windows系なら許されるかな？)。

簡単な例を示そう。
以下のような構成のソースファイル群から、fooという名前の実行ファイルを作りたい場合。

test/
 +- CMakeLists.txt
 +- src/
 |   +- main.c
 |   +- sub1.c
 |   +- sub2.c
 +- include/
     +- sub1.h
     +- sub2.h
     +- common.h

最低限のCMakeLists.txtの中身は、以下のようになる。

cmake_minimum_required(VERSION 2.8)
include_directories(include)
add_executable(foo src/main.c src/sub1.c src/sub2.c)

1行目はCMakeのバージョン指定。2.8以上を使えという意味。指定しないとWarningが出る。指定しなくても目の前で動かなくなることはないだろうけど、とりあえず今使ってるバージョンを指定しておいた方が無難。
2行目は、インクルードするヘッダファイルの置き場所指定。上の例だと、includeというディレクトリをヘッダの探索パスに追加する。
3行目は、生成する実行ファイルとそのソースファイルの指定。src/main.c, src/sub1.c, src/sub2.cの3つからfooという実行ファイルを作れという意味。

では、実際にCMakeを起動する…、その前に、ビルド専用のディレクトリを作った方がいい。CMakeLists.txtがあるディレクトリでも動かないことはないのだが、CMakeは非常に多くのファイルを生成するので、バージョン管理しているディレクトリで実行したりすると、とっ散らかって面倒なことになる。
以下は、testの兄弟ディレクトリbuild_testを作って、そこでビルドする実行例。

% pwd
/xx/xx/test
% mkdir ../build_test
% cd ../build_test
% cmake ../test
% make

CMakeの仕事はMakefileを作ったらおしまい。実際のビルドはmakeで行う。

岩山両斬波

チラシの裏。
今週のキン肉マン。毎週毎週、ついついデレてしまうバッファローマンにアフロ萌え。そしてピークア・ブーを生かそうとするスグルに燃え。ピークア・ブーは死亡フラグが半立ちした気がしないでもないが、それより先に魔雲天が逝ったー！？

C/C++の変数宣言とswitch

昔のC/C++言語では関数の頭で変数宣言しなくてはならなかったけど、最近はもうどこでもOKなのかと思ってたら、switch文で分岐した先でやったら怒られた。
まあ考えてみれば、breakせずに上のcaseから降りて来たりする中で、新たに変数を作られるのは嫌だよな〜、とは思う。

ちなみに、{}で括って明示的にブロック化してやれば、その中では変数宣言OKだった。

182勝目

チラシの裏。
おいおい、どうしたんだ？ 西口に勝ちが付いたのはいいとして、今日は救援陣が炎上する事無く、完璧に抑えてるぞ。投げる以前の問題から、一番後ろに涌井が戻って来たのが効いてるのかな。

3DS LL

ようやくDSi LLの後継機が出るのか。

見た感じの丸っこさもLLの後継機らしい。コストの高そうなツヤツヤの塗装はやめたのかな。存在意義が微妙だった3Dランプもオミットされたか。
ACアダプタは確かに余ってるから、安くなるなら削ってくれて結構。だけど、使い回しの効かないクレードルは標準で付けて欲しかった。

3DSは結構ソフトとハードの紐付き具合が強いので、外では従来機、家の中ではLLという使い分けが難しそう。いつの間にかiCloudと同期してるiOSデバイスのようになってくれないかなぁ。

まあ、間違いなく買うけど。

放射線量

ブックマークを整理していて、久々に川崎の放射線量を見た。
1年前は神経をすり減らしながらチェックしていたのに、いつの間にか気にも留めなくなっていた。それどころか、久々に見た値が大きいのか小さいのかピンと来ない始末。
このあたりを参考にすると、まあ失策前くらいには戻ってるのかな。

またいつかテレビ

チラシの裏。

とうとう、いつの間にテレビ最後の日がやって来てしまった。1年間見続けたものが明日から届かなくなると思うと、寂しいな〜。

最後に、思い出きろく帳のログを晒そう。

遊んだ時間

92:23

遊んだ回数

390回

1回に遊んだ時間

0:14

初めて遊んだ日

2011/6/21

最後に遊んだ日

2012/6/20

この1年間では、旧来のテレビより視聴時間が長かったのか。

LarrabeeからXeon Phiへ

http://news.mynavi.jp/news/2012/06/19/054/


とりあえずはコプロというか、コシステムみたいな感じか。
しかし、これだけ特殊な環境だと、性能を絞り出すには結局チューニングが必要なんじゃないのか？ …どうせ手を入れるんだったら、x86互換は別にありがたいとは思わないなー。それとも、これだけコアがたくさんあれば、CISCならではの命令長の短さが効いてきたりするのだろうか？

個人が当たり前のようにメニーコアを使えるような時代が、早く来ないかなぁ。

楽しかったあの頃

チラシの裏。

今週のキン肉マンは、まさかの宇宙旅行と風林火山に大興奮。YouTubeで再放送しているシャリバンでは、ついにガイラー将軍が討死。残り2話も早く見よう。

こうして80年代コンテンツを満喫できるとは、21世紀もまんざら悪いことばかりじゃないな〜。

Valgrind

Valgrindという素敵なツールの存在を知った。
こいつを使えば、CやC++で不正なメモリアクセスをしても、動的に検知してくれる。それも、どの関数がどこを触ったかなんて情報まで出してくれる。
メモリのゴミを読んで動いたり動かなかったりするバグも、これを使えばゴミを読んだことをレポートしてくれるので、非常に助かる。

Apple Wireless Keyboardのバッテリー

購入から5ヶ月弱経過した今日、付属していた単3アルカリ電池x2が切れたので、たんまりストックしてあるエネループに交換。

…というわけで、バッテリーがどの程度持つのか、今日から調査開始。調査と言っても、今まで通りに使うだけなんだけど。

しかし、大まかな電池寿命くらい公式サイトに書いておいてくれればいいのに。

C++のエンディアン判定と定数式最適化

configureとか使わずに、コンパイル時にプラットフォームのエンディアンを判定したい。マルチバイトの1の先頭バイトを見るのは、エンディアン判定の常套手段だが、この1を定数にしたら、静的に判定してくれないだろうかと、以下のコードで試してみた。

#include <iostream>
using namespace std;

static const union {
    int one;
    char isLittle;
} endian = {1};
static constexpr union {    // C++11
    int one;
    char isLittle;
} endian2 = {1};
static const int endian3 = 1;
static constexpr int endian4 = 1;   // C++11
static const int const_array[] = {0, 1, 0, 2};

int main() {
    if (endian.isLittle)
        cout << "little endian" << endl;
    if (endian2.isLittle)
        cout << "little endian2" << endl;
    if (*(reinterpret_cast<const char *>(&endian3)))
        cout << "little endian3" << endl;
    if (*(reinterpret_cast<const char *>(&endian4)))
        cout << "little endian4" << endl;
    if (const_array[0])
        cout << "[0] is not zero" << endl;
    if (const_array[1])
        cout << "[1] is not zero" << endl;
    if (const_array[2])
        cout << "[2] is not zero" << endl;
    if (const_array[3])
        cout << "[3] is not zero" << endl;
    return 0;
}

結果はコンパイラによりけり。
Ubuntu 12.04(x86/AMD64)のGCC 4.6.3だと、-O3を付けても、上記の全てのエンディアン判定で比較と分岐命令を生成してしまった。ただ、エンディアン判定には使えないけれど、const_array[]を使った分岐は最適化によって消滅した。
Mac OS X LionのLLVM GCC 4.2.1とLLVM compiler 3.1だと、-O3を付ければ全ての分岐は消滅してくれた。素晴らしい！

オスプレイ

事実は小説より奇なりとはよく言ったものだ。今日のオスプレイ墜落は、フィクションならご都合主義すぎて作家が非難されるレベル。陰謀論者でなくても思わず勘ぐりたくなる。そんなもの飛ばすなという気持ちも、さすがに分かるわ。

鳥つながりで無理矢理ホークスの話。あれだけボロボロに見えるのに、交流戦最下位でないことにびっくりした。ベイスターズ…。

C++でtypedefのテンプレート化のようなもの

C99のstdint.hを使えばint8_tやuint16_t等のビット幅を指定した型を利用できるが、この8や16等のビット幅をC++のテンプレート引数にしたい。が、typedefはテンプレート化できないし、classはオーバーヘッドが大きくて嫌だ。さて、どうにかならないか考えてみた。

template <size_t width> union uint_u;
template<> union uint_u<8> {uint8_t v;};
template<> union uint_u<16> {uint16_t v;};
template<> union uint_u<32> {uint32_t v;};
template<> union uint_u<64> {uint64_t v;};
template <size_t width> union sint_u;
template<> union sint_u<8> {int8_t v;};
template<> union sint_u<16> {int16_t v;};
template<> union sint_u<32> {int32_t v;};
template<> union sint_u<64> {int64_t v;};

こんなのを定義しておいて

uint_u<16> u16;
sint_u<64> s64 = {-123456};
s64.v = u16.v * -77;

こんな感じで使うのはどうだろう？

…う〜ん、やっぱりダサいから没。これならマクロを使うか、がっつりclassを組んでコンパイラの最適化に期待する方がいいかな。

そしてXCへ…

いつの間にやらSDHCカードが凄いことになっていた。上限ギリギリの32GBですら、GB単価が50円を割っているなんて。

SDカードが規格の上限2GBの壁にぶつかった頃は、あれだけ急速な大容量化と低価格化なら、流れを読み切れなくても仕方ないとは思った。が、それを受けてのSDHCが、こうもあっさりと同じ過ちを繰り返すのはお粗末でないかい？

…と思ってたら、SDHCの上限はアドレスの限界ではなく、ファイルシステムに由来するのか。別にFATにこだわらなければ、SDXCを32GBを超えたSDHCとしても使えるって…、本当？

WWDC 2012

チラシの裏。
マカーになって初のWWDC。2011年モデルのMac miniは問題なくMountain Lionを使えるだろうけど、第4世代iPod touchはiOS6に対応できるのだろうか？
ああ、気になる。気になるけど、E3で夜更かしした次の日があまりにグダグダだったから、今回は大人しく明朝にチェックしよう。

続・Apple Magic Trackpadレビュー

購入してから3週間。概ね快適なんだけれど、ちょっと困って来た。

…いや、分かっていたことだけど、汗ばむと滑りが悪い。
基本的に乾燥肌だから何とかなるだろうと思ってたけど、汗が引くまでの間は使いづらい。これからもっと暑くなるのだが、ちょっと妙案が思いつかない。乾いた布を常備するしか無いかなぁ。

Aterm WR8370Nレビュー

無線ルータAterm WR8370Nを購入したので、軽くレビューしてみる。

まず、この機種を選んだ3つの理由は

1. 802.11n対応であること
2. LAN側のハブがGbE対応であること
3. 簡易NASになること

もちろん、値段もだけど。
これら目当ての機能に関しては、特に不満はないかな。強いて挙げれば、簡易NAS機能でexFATに対応してほしかったくらい。備えていてほしい機能は備わっていて、今のところ特に不満はなし。

カタログには書いてないけれど良かった点は、無線の送信出力を抑えられるところ。選択肢としては100%, 50%, 25%, 12.5%がある。
この機能は、意外と備えていない機種が多い気がする。消費電力的にもセキュリティ的にも、不必要に遠くまで電波を飛ばさないのは重要だと思うんだけどなぁ。

181勝目

チラシの裏。
なんとか西口に勝ちが付いたけど、我らがライオンズの救援陣は相変わらずだなぁ。5点差を付けた時点で安心してしまったのは、ファンとしてまだまだ訓練が足りなかった。
まあ、何はともあれ、あと19勝。

C/C++のポインタやリファレンスに関する悩みどころ

悩ましいのはポインタとリファレンスの使い分けとかではなく、記述の問題。

C/C++のポインタ変数の宣言には、大まかに分けて2つの流儀がある(と思う)。1つは

int *p;

もう1つは

int* p;

違いはスペースの位置。個人的には前者のスタイルなのだが、これは*が変数を修飾するものだから、という理由。後者のスタイルでは、*はintという型を修飾するものだという考え方なのだろう。

int *p, i;

という変数宣言では*は変数pのみを修飾しているので、この点からは前者が正しいように見える。ところが

(int *) xx
reinterpret_cast<int *>(xx)

のようなキャスト演算では、*は明らかにintを修飾している。なので、結局どちらとも言い切れないのが、この悩ましさの元凶なんだよなぁ。

C++リファレンスを表す&も同様なんだけど、こっちは

int& r = i;

のように型に付ける方が主流派な気がして、変数修飾派はなんとなく肩身が狭い。

また又・SVN使いだがGitに乗り換えようと思う

レポジトリ間の連携の話。
今回は分散型ならではの話なので、Subversionとはの比較は無し。

まずは既存のレポジトリをgit cloneで複製して、各々が自分専用のレポジトリを作成する。

複製の複製も可能。

他のレポジトリの変更を自分のレポジトリにマージするにはgit pull。自分のレポジトリの変更を他のレポジトリにマージするにはgit push。

ただ、他のレポジトリを変更するgit pushは、そもそも許可されているとは限らない。そんなときはレポジトリの持ち主にpullしてもらう。
なお、pull/pushで変更するのはレポジトリ全体ではなくブランチ。

他のレポジトリのエイリアスを登録しておくと、操作の度にURLを入力しなくても済む。エイリアスの追加や削除等は、git remoteで管理できる。なお、git cloneで複製したレポジトリには、デフォルトで複製元のレポジトリにoriginという名前が付けられている。

E3 2012

チラシの裏。

さて、いよいよWiiUの発表か。計算能力はまあ、そこそこモダンなCPUとGPUを積めば十分だろうけど、ストレージはちょっと心配。3DSのように標準でSDカードを使ってくれれば、勝手に安く大きくなってくれるだろうけど、HDのコンテンツにはちょっと帯域が心細い気もする。

どこまで発表されるかは分からないけど、お楽しみは2時間後。

続続・SVN使いだがGitに乗り換えようと思う

GitのブランチがSubversionのそれと違うなぁと思った点を3つ。

まず実装。そもそもSubversionのブランチは、運用でブランチとして扱っているだけの単なるサブディレクトリなので、明確にブランチ機能を備えたGitとはまるで違う。

次にブランチ作成の気軽さ。Subversionでブランチを作るということは、共有レポジトリに新たなサブディレクトリを作るということ。運用ルールにもよるけれど、ちょっとした実験用ブランチを作るのは気が引けてしまうことも多い。一方Gitなら、あくまで自分専用のレポジトリなので、実に気軽にブランチを作成できる。

最後にマージの厳格さ。コミットもブランチ作成も気軽なGitだけれど、マージに関してはSubversionよりGitの方が細かい。Subversionの場合、どの変更をマージしたかという情報(mergeinfo)が欠落している場合が結構ある。…というか、mergeコマンドを使わない(人|クライアント)が結構多い気がする。mergeinfo自体が後付けなので仕方ない気もするけれど、理由はどうあれ、何をマージしたのか分からなくなるのは非常に困る。
一方Gitは、マージも含めて適用してきた変更をきちんと把握しているので、mergeコマンドでは未適用の変更のみを正確に適用できる。もちろんGitでも、mergeコマンドを使わずに出所不明の変更としてcommitすることはできるけれど、そこは分散型の良いところ。自分専用のレポジトリなのだから、きちんとマージするというルールを自分だけが守っていれば、他人のいい加減なマージに振り回されることは無い。

他人のレポジトリと同期する話は後ほど。

Macのnmでdemangle

Macに入ってるnmには-Cオプションが無くて、C++のシンボルが分かりづらいなぁ。…と思ってたんだが、c++filtというdemangleするフィルタが入っていた。

% nm xx.o | c++filt

のようにnmの結果を食わせてやれば、demangleされた名前が見える。

c++filtってのもGNUのツールなのか。

180勝目

チラシの裏。
やった！ 西口に勝ちが付いた。6回途中の降板は、ライオンズ的には負けフラグ半立ちなんだけど、今日はよく逃げ切ってくれた。
次の登板は、苦手の東京ドームか？ それでもなんとか勝って欲しいな〜。交流戦の優勝をセリーグに取られたくないし。

codepad

codepadというサイトを知った。
CやらRubyやらのコードを入力すると実行できる。…だけでなく、コードと実行結果へのリンクが生成される。

http://codepad.org/9PeNQ590

このリンク先のテストコードはいつまで残っているのだろうか？

初志貫徹、一気通貫、魔貫光殺砲

最近読んで、なるほどと思った記事。

http://cpplover.blogspot.jp/2012/05/60.html

久しく逸般的な環境から抜け出せていないので、60%という数字にはピンと来ないけれど、確かに思い当たる節がある。そう、過去に出会ってしまった書き手の正気を疑うようなコードのあれやこれに欠けていたのは、一貫性だ。

そもそも一貫した規則性から美を見出さない人なら、そりゃ平気で汚いコードも書けるわな。