Sublime Text 2 と環境変数

アサイド

ゴキゲンなテキストエディタ Sublime Text 2 の超絶便利テクを見つけたので、ここにメモっておく。

Sublime Text 2 の Command + B による Build が猛烈に便利で多用している。Python とか Ruby とか、何でも良いけどスクリプトを書いていて、とりあえず実行したいとき、まずはさくっと Command + B。ウインドウの下側に結果が出る。

Sublime Text 2 で Build

これが非常に便利なんだけれど、例えば Python だと、システムの Python、OS X Lion なら 2.7.1 が使われてしまったりする。本当は Homebrew でインストールした 2.7.3 が使いたいのに……。それで自分で新しく “Build System” というプラグインみたいなのを作ったりするんだけど、あんまり合理的じゃない。その上 Build System の選択を “Automatic” なんかにしていると、たいてい間違ったやつが使われてしまう。

解決するには PATH を通せば良かった。ここで紹介したいのは、そのやり方です。

まずはメニューの “Preferences” か Command + , で、“Preferences.sublime-settings” を開く。

{
    ...
    "build_env":
    {
        "PATH": "/usr/local/bin:/usr/bin"
    },
    ...
}

そこで上記のように書き足せば良い。この build_env は、Build の際に環境変数として渡されることになっていますから、ここで PATH を設定してやれば良いということですね(参考)。実際の値はそれぞれの環境に合わせましょう。ターミナルで echo $PATH とかやれば、ターミナルでの PATH が分かりますね。

ということで、無事に PATH が通って、ますます便利になりました。

MakeExecutable Plugin for Sublime Text 2

ということで書いてみた。

ファイルに拡張子がなく、先頭が shebang (“#!”) のとき、実行権限を付ける。TextMate 2 の挙動の真似をしているつもり。

$ ./executable_file

としたいときの

$ chmod a+x executable_file

を自動でやってくれる感じ。

続きを読む

TextMate 2 Dev Build

注目

TextMate

TextMate は皆さんご存じのように Mac のもっとも名高いテキストエディタです。バージョン2のリリースが遙か数年前から予告され、ヴェイパーウェアと揶揄されながら昨年末ようやく TextMate 2.0 alpha が公開されました。最新の Nightly Build 9090 では Mac OS X 10.5 Leopard のサポートが外され、さらに活発な開発が続くことが期待されます。


(2012/08/11 追記)

オープンソース

昨日突然、TextMate 2 がオープンソースの下で開発されることが発表されました。GitHub のリポジトリで公開されています。

ビルドされたものが GitHub のページからダウンロードできます。

自分でビルドするには、予め Clang の 3.2/4.0 以降 (とりあえず Xcode 4.4+ の Command Line Tools を入れましょう) と Homebrew を用意しておき、Homebrew で以下のパッケージをインストールします。

  • ragel
  • boost
  • multimarkdown
  • hg
  • ninja
  • proctools (OS X Lion)

そして、リポジトリを clone してビルドです。

git clone https://github.com/textmate/textmate.git
cd textmate
git submodule update --init
./configure && ninja

サブモジュールも初期化するのが肝です。

日本語

Issues に上がっています。しかしいまは、hetima さんが日本語入力の問題を解消するプラグインを公開されています。ダウンロードしてインストールしましょう。

Issues はクローズされ、最新のビルドでプラグインと同等のパッチが当たりました。まだ問題も残っているものの、暫定的には日本語を入力することができます。

まとめ

ということで、オープンソース化され、活発にコミットされている様子も見られるようになり、ますます期待できる TextMate 2。しかも無料で使えるのですから、これを使わない手はありません。そして、C++ を学び、開発に貢献しましょう。

みなさま、C++ を学ぼうと思う僕に良本をお教えください!!!


ここから古い情報です……。

ところで、この Nightly Build はまったく Nightly ではありません。短くても数日、長ければ2ヶ月程度更新がないことも。常に最新版を使いたいドッグフードイーターの私たちには、これは不満です。ということで、ドッグフードを食べる方法、もとい、Nightly Build より新しいビルドを使う方法を紹介します。

Software Update

Software Update

TextMate の Preferences から Software Update を開きましょう。そしていつものように Check Now をクリック。Watch for: Nightly Builds に設定されていれば、最新の Nightly Build が Build 9090 であると表示されます。

TextMate

ここで Option キーを押しながら Check Now をクリック してみます。そうすると、最新は Build 9092 だと表示されました。

TextMate

こうすることで、誰よりも早くドッグフードをいただくことができます。

TextMate

TextMate 2.0 では日本語の表示の問題が解決され、入力については今ひとつといったところです。だんだんと修正されていくのを待つしかありませんが、優先順位は高くなさそうです。ほかにもまだ未実装の機能があるようですし、レオナルド・ダ・ヴィンチが晩年まで加筆を続けたモナリザのように、完成を知らないのかもしれません。しかしそれでも間違いのない大傑作ですから、長い目で見守りたいと思います。

POM の圧力傾度力

アサイド

著名な海洋物理モデル Princeton Ocean Model (POM) を使っていて、1ヶ月以上にわたり悩まされた問題について、メモ代わりに残しておきたい。予め書いておくと、自分は初期値として水平に密度勾配があるという条件について数値実験していた。そしてこのことが問題となっていた。

この海洋モデルでは座標系のうち鉛直方向を、一般的な直交座標系ではなくシグマ座標系というのを採用している。シグマ座標についてはほかにいくらでも書かれているので、ここでは詳細に記載しない。メリットもあり、デメリットもある。

デメリットの一つに、Pressure Gradient Error という誤差がある。海洋において圧力とは、主に水の密度である。この密度が水平に異なるとき、高密度の方から低密度の方へ流速が起きるような力が生まれる。これを圧力傾度力と呼ぶ。シグマ座標系において圧力傾度力の計算で起きる密度の打ち切り誤差は、圧力傾度力に対して過大に影響する。これが Pressure Gradient Error で、シグマ座標系の問題として長く議論されている。

POM ではこの誤差を軽減するため、圧力傾度力を計算する前に密度から密度の平均値を一旦減算 (rho = rho - rmean) し、圧力傾度力の計算が終わると再び加算 (rho = rho + rmean) する。こうすることで、密度の絶対値ではなく相対値によって圧力傾度力が計算され、打ち切り誤差が軽減される。ここで密度の変数は rho、密度の平均は rmean である。

問題は、この rmean の初期化にある。初期化する部分のデフォルトのコードは以下のようになっている。

見ての通り、rmean = rho であって、平均でも何でも無い。コメント部分を読むと、『密度の初期値が水深のみの関数であるときはこれで大丈夫。水平に密度勾配があるときは平均するように。』というようなことが書かれている。これを見逃していたために、圧力傾度力が正しく計算されていなかった。これが問題のすべてである。

解決するためには、rmean に適切な平均値を入れるか、またはいっそ 0 を代入しておいても良い。Pressure Gradient Error は大きくなるものの、大した問題ではない。

ということで、POM を使って初期値に水平の密度勾配がある条件の数値実験をする際には、rmean を適切に初期化しなければならない、という教訓です。1ヶ月くらい気付かなかったし、すごく辛い思いをした。普通に、平均という名前の変数には、最初から平均を入れておいてほしい。

インターネット端末に過ぎない

アサイド

自分はインターネット端末に過ぎないのだという妄想をしている。インターネット上に明確な実体の無い何らかの知性があって、自分と話す人間は自分を介してインターネットにインプットし、自分を通してインターネットからのアウトプットを得る。ここで自分は単なる端末に過ぎず、人格を持たない。

これは妄想であって、真実とは程遠い。誰しも人格を持っていて、何かの端末機能だけを持つような存在ではない。これが紛れもない真実であることに疑いの余地はないのだけれど、しかし同時に、我々は人を何かの端末のように認識している場合があるのではないかと思う。

ある政治団体に所属する政治家が何か語ったとき、それは政治団体の言葉として受け止められる。その政治団体を支持するために、選挙でその政治家に票を投じる。その政治家の背景にある政治団体、あるいは政治的思想に、政治家個人を通じてアクセスする。多くの場合、政治家個人のパーソナリティは意識されない。

テレビで、東日本大震災で被災地の子ども達が果たしためざましい活躍を特集していた。そこは東北地方の、未だ地域共同体が根強く生きているような、そういう場所であった。子ども達が、随分と大人びた言葉を発しているように思われた。それは子どもの言葉というより、まるでそのコミュニティそのものが発する言葉に聞こえた。一見頼もしく、しかし不気味だった。

子ども達は地域共同体というコミュニティの端末だと思った。コミュニティというクラスタリングされたサーバーのクライアント端末。テレビカメラが、自分が、子ども達という端末を介して、地域共同体の空気をなぞる。

特定のコンテキストにおいて、人は個人から端末に変わる。まるで端末であるかのように振る舞い、まるで端末あるかのように認識される。ときにこのことで個人の人格が無視され、一個の端末として取り扱われるのだと思う。それはもしかすると便利で、そして邪悪だ。

壁が薄い部屋

アサイド

彼女の住むアパートに遊びに来ていて、ちょっと彼女が出掛けている間にうたた寝をしていた。

気がつくと、どこからか音楽が聴こえる。部屋の中を確かめるが音源が見つからない。少しして、隣室から聞こえていると分かる。

壁が薄いから仕方ないと我慢するが、一向に止む気配がない。壁に目を凝らすと、隣室に住む青年の影が見える。部屋の様子まで見えてくるように感じる。

ふと青年と目が合い、ああ、こんにちは、なんて話しかけてくる。それまで壁と思っていたのは、白いレースの布切れだった。居心地の悪さを感じながらも、青年と世間話を始める。

という夢だった。

パソコンに一礼を。

アサイド

パソコンの調子が悪い、というような言葉が口にされているのを、ごく頻繁に耳にするようになった。偶に気が向いてどうかしたのかと尋ねると、ああだこうだと語り始める。一寸、それを制して、はじめに礼はしたのか、と訊けばきょとんとした顔をする。だからパソコンに一礼はしたのか、と訊いて、ようやくわかり、ハッとして下を向く。

日々の仕事の多くをパソコンに頼るようになって久しく、最早それなしでは立ち行かない毎日を送っている。それだのに、何かあればパソコンが悪いと口々に言う。パソコンを使うな、などと物分かりの悪いことを言うつもりはないが、皆もう少しパソコンに敬意を払って然るべきだろう。早くからコンピューターを使っていた者は必ず、上手く働いてくれるよう日に何度も祈っていた。それが最近では、上手く働いて当たり前のように考える者が多いのだから、開いた口がふさがらないとはこのことだ。

もっとパソコンを労ってはどうか。定期的にメンテナンスし、いつも綺麗であるようにクリーニングクロスで磨く。液晶に埃がついているなど以ての外だ。そうして、毎日パソコンを使用する前には必ず一礼をする。いつも仕事をしてくれて有難う、というその気持ちが、パソコンに伝わるのだ。パソコンの調子が悪いという人間に、必ず一礼をしているという者を見たことがない。

パソコンに一礼を。

Excel 列名変換


Excel列名変換問題で第2回社内プログラミングコンテストを開催してみた

Perl 書けないので Ruby と Python で書いた。あとコマンドラインで引数渡して……という部分は省いて、それぞれ単純な関数にしてある。


Ruby

Ruby 1.9.3 で確認。

Python

Python 2.7.2、Python 3.2.2 で確認。


最初に Ruby の方を大体制限時間内で書いて、あとから友だちの Rubyist、@hidachinoiro に教えてもらったりしてリファクタリング。その後 Python に移植。

Perl で書くともっと難しそう。Ruby 最初からいろいろできて便利。Python は Ruby と同じことするのに3つもモジュールをインポートしてる1けど、やろうと思えばモジュール使わずに同じ機能を実装できる。コードの量は増える。

プログラミングコンテストとしては現実にありそうな良問だと思う。ただ慣れてる人ならもっと簡単に解けそう。


  1. Python 2 だけなら2つで良いけど Python 3 で reduce()functools に移動してた 

Fortran プログラムで変数の型に関するバグ

研究室の同期が Fortran のプログラムを書いていて、数日間解決できずに悩んでいたバグを修正した。LL のスクリプトばかり書いていてメモリの扱いを考慮することを忘れ、修正に時間がかかってしまったので、自戒を込めて概略をまとめる。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
program main
    integer :: var_a = 0
    integer :: var_b = 0

    call foo(var_a, var_b)
end program

subroutine foo(var_a, var_b)
    real(8) var_a
    integer var_b

    var_b = 123
    var_a = 0

    write(*, *) var_b !=> 0
end subroutine

上記はできる限り簡略化した Fortran のコード。このコードの15行目で、標準出力に var_b の値を表示すると、12行目で 123 を代入しているにも関わらず値が 0 となっていた。

最初サブルーチンの中身だけを追っていて、何度も問題が無いことを確認した。あるとき var_a の値を変えると var_b の値まで連動して変わることに気付き、ようやく何が起こっているか理解。サブルーチンを呼び出す方の、サブルーチンに渡される引数の型を見ると、サブルーチンと一致していない。メインプログラムでは var_ainteger で整数型、4 bytes。サブルーチンの var_areal(8) で実数型の 8 bytes。

サブルーチンに変数の先頭アドレスが渡って、そのあとメモリ空間上のどこまでがその変数の長さなのかは、その変数の型によって決まる。従って長さの違う型で変数が再定義されると、先頭アドレスから間違った長さまでをその変数として用いてしまう。

概略図を以下に掲載する。右側はメモリ空間の一部を、左から 4 bytes ずつに区切ったものとして表記した。ただし簡単のため、1 byte を10進数のように書いてある。

原因が分かり、var_areal(8) である必要があったため、以下のように修正。問題が解決した。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
program main
    real(8) :: var_a = 0
    integer :: var_b = 0

    call foo(var_a, var_b)
end program

subroutine foo(var_a, var_b)
    real(8) var_a
    integer var_b

    var_b = 123
    var_a = 0

    write(*, *) var_b !=> 123
end subroutine

コンパイラによってメモリ空間の扱いが変わるため、このようなバグを作った場合に原因の特定が困難。サブルーチンの内外で変数の型が合致しているか要注意。

追記

研究室の先輩 @tk4terui さんに、コンパイラのオプションをちゃんと付けると、コンパイル時に警告してくれる情報を教わりました。GCC の Fortran コンパイラ ‘gfortran’ では -Wall または -Wconversion オプションを付けると

1
2
3
4
5
6
7
$ gfortran -Wconversion test.f90

test.f90:13.12:

    var_a = 0
           1
Warning: Conversion from INTEGER(4) to REAL(8) at (1)

という感じでちゃんと警告されます。便利。

Ruby + Nokogiri で 気象庁スクレイピング

このあいだの連休中に『たのしい Ruby』を読んで、まあまあかっこよく [[wiki:Ruby]] 書けるようになったから書いてみた。Ruby は 1.9.2 使った。

気象庁 | 過去の気象データ検索

ブロック付きでもなしでも何となく使える感じ。

Ruby はじめてちゃんと勉強して、全部オブジェクトなのはかっこいい。ブロック使うのちょっと慣れるまで気持ち悪かったけど、慣れると便利。

TextMate と BBEdit と行き来しながら書いたけど、TextMate の方が便利。