.emacs.d の利用

Emacs 22 以上であれば通常 ~/.emacs.d 以下に設定ファイルやライブラリ類を集めるのが良いです。

~/.emacs.d を利用すれば .emacs や .emacs.el を作成しなければ ~/.emacs.d/init.el を利用することができます。

ライブラリ類を集めようとすると、ディレクトリを作成することが多いと思いますが、そのままだと load-path が通りません。

例えば .emacs.d/lisp に load-path を通したい場合は以下のようにすると良いでしょう。

(let ((default-directory (expand-file-name "~/.emacs.d/lisp")))
  (add-to-list 'load-path default-directory)
  (if (fboundp 'normal-top-level-add-subdirs-to-load-path)
      (normal-top-level-add-subdirs-to-load-path)))

normal-top-level-add-subdirs-to-load-path はディレクトリ内のサブディレクトリを load-path に追加します。

ディレクトリ内に置いておきたいが、 load-path に追加したくない場合は以下の制限を利用すれば良いでしょう。

• 英数字以外で始まるディレクトリは読み込まない
• RCS や CVS という名前のディレクトリは読み込まない
• .nosearch というファイルを含むディレクトリは読み込まない

例えば、フォルダの名前の先頭に「_(アンダーバー)」や「.(ピリオード)」を付与すれば良いでしょう。

さて、.emacs.d 内のディレクトリ構成をどうするかは悩みの種のようです。あまり共通化されていない様子。

~/
  .emacs.d/
    init.el

までは定型として、その下にどのようにディレクトリ構成を切るか、ということです。

最低限必要そうなのは以下のディクトリでしょうか。

1. init.el を分割した、初期設定ファイル
2. 他者配布の Emacs Lisp 類
3. 自分作成の Emacs Lisp 類

1 に使えそうな名前は以下な感じでしょうか。

• pref
• prefs
• conf
• site-start.d
• init.d
• rc.d

2、3 に使えそうな名前は以下な感じでしょうか。

• elisp
• lisp
• site-lisp
• vendor
• plugin
• lib
• libs

以下は個人的な選択方法。

init.d だと補完の時に init.el と重なるのであまり便利ではないですね。rc.d も Emacs Lisp を入れるディレクトリ名としては微妙な気がします。

pref や conf は Emacs 関連の文書にほとんど出てこないようです。 pref だと prefix、conf は cond と微妙にぶつかるからかもしれません。

elisp という名前は Elisp というプログラミンング言語が別にあるので避けています。 site-lisp という名前にすると Emacs Lisp を make でインストールする時に prefix 指定するだけでインストールできるので楽だったので、site-lisp が良いかなーと思ったのですけど、 init.el と init.d みたいに site-start.d とぶつかるのですよね。

ということで、今の所以下のような構成にしてみています。.emacs.d だけコピーするとほとんどの環境で同じに動作することを想定しています。

まだ試行錯誤中で整理しおわったら公開しようと思います。

~/
  .emacs.d/
    init.el
    site-start.d
      init-*.el
      … init.el から読みこむ起動設定ファイル
    lisp
     … 他者が配布している Emacs Lisp
    local-lisp
     … 自分で作成した Emacs Lisp やなんらかの理由で公式配布のバージョンから修正してある Emacs Lisp
    private
     … 公開しないファイル類など
    rc.d
     … zshrc 等の rc ファイルがはいっていて ln -s している。結局 Emacs との連携を考えるのでまとめた
    bin
     … Emacs Lisp のみから呼ぶことを想定して作成してあるスクリプト等
    share
      dtd
      rnc
      icons
      skk
      man
      info
      … Emacs Lisp が利用する固定(基本いじくらない)リソース
    etc
     snippets
     rst
     … Emacs Lisp が利用する可変(基本いじる)リソース
    var
     … キャシュファイルやバックアップファイル用

参考サイト

• http://www.emacswiki.org/
• http://www.debian.org/doc/packaging-manuals/debian-emacs-policy
• http://bitbucket.org/
• http://github.com/
• http://coderepos.org/share/

Optional Arguments と Named Arguments

オプション引数(Optional Arguments)と名前付け引数(Named Arguments)は似ているようでまったく違う機能です。

オプション引数は引数を省略可能にする機能で、名前付け引数は引数の名前を指定して値を渡すことができる機能です。

Python では

def info(text, opt=30):
    print "text=%s , opt = %d" %(text, opt,)

のような関数を定義した場合、以下のような関数の呼びだしが可能です。

info('hello')
info('hello', 20)
info(opt=40, text='world')

1番目と2番目がオプション引数の例、3番目が名前付け引数の例になります。

これと同じことができる言語は、Visual Basic や OCaml、Scala( http://www.scala-lang.org/node/2075 ) 等いくつか存在しています。

オプション引数しかできない言語も結構ありますし、オプション引数すら不可能な言語もそれなりにあります。 JavaScript 2.0 なんかは草案時には名前付け引数があったのだけど、見送られた様子。

オプション引数、名前付け引数のいずれに関しても好まない人もいるようですが使い方次第だと思っています。 当然のごとく、この機能がないとしても公開する API の引数の名前や順序は明確に綺麗に書くべきだと思います。

Snow Leopard に GHC 6.10.4 のインストールから cabal-install の動作まで

GHC は以下から取得して普通にインストールする。

http://www.haskell.org/ghc/download_ghc_6_10_4.html#macosxintel

このままだと ghc が完全には 64bit に対応していないため上手く動作しません。以下の変更をします。

/usr/bin/ghc を vi 等で開きます。内容は以下になっています。

#!/bin/sh

exec /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/ghc -B/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/. -dynload wrapped ${1+"$@"}

シェルスクリプトです。

これに -optl-arch\ i386 -optc-m32 -opta-m32 -optl-m32 フラグを追加することで 32bit 固定設定にします。

#!/bin/sh

exec /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/ghc -optl-arch\ i386 -optc-m32 -opta-m32 -optl-m32 -B/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/. -dynload wrapped ${1+"$@"}

また /usr/bin/runhaskell も同様のフラグを付与しておきます。

#!/bin/sh
exec /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/runghc -f /Library/Frameworks/GHC.framework/Versions/610/usr/bin/ghc ${1+"$@"}

#!/bin/sh
exec /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/runghc -f /Library/Frameworks/GHC.framework/Versions/610/usr/bin/ghc -optl-arch\ i386 -optc-m32 -opta-m32 -optl-m32 ${1+"$@"}

基本的にはこれで問題ありませんが このままだと cabal-install tool が動作しません。

cabal-install が使えないと Perl で cpan が使えないのと同じですから GHC の威力がかなりへってしまいます。

cabal-install は HTTP パッケージと zlib パッケージに依存していますのでこの二つをインストールします。

ここでは ユーザディレクトリにインストールします。 $HOME/.cabal 以下にすべてのライブライがインストールされます。

curl -O http://hackage.haskell.org/packages/archive/HTTP/4000.0.8/HTTP-4000.0.8.tar.gz
tar xvfa HTTP-4000.0.8.tar.gz
cd HTTP-4000.0.8
runhaskell Setup.lhs configure --ld-options="-arch i386" --gcc-option=-m32 --user
runhaskell Setup.lhs build
runhaskell Setup.lhs install
cd ../
curl -O http://hackage.haskell.org/packages/archive/zlib/0.5.2.0/zlib-0.5.2.0.tar.gz
tar xvfz zlib-0.5.2.0.tar.gz
cd cd zlib-0.5.2.0
runhaskell Setup.hs configure -p —ld-options="-arch i386" —gcc-option=-m32 --user
runhaskell Setup.hs build
runhaskell Setup.hs install
curl -O http://haskell.org/cabal/release/cabal-install-0.6.2/cabal-install-0.6.2.tar.gz
tar xvfz cabal-install-0.6.2.tar.gz
cd cabal-install-0.6.2
runhaskell Setup.hs configure -p —ld-options="-arch i386" —gcc-option=-m32 --user
runhaskell Setup.hs build
runhaskell Setup.hs install
# cabal のデータベースを更新します
~/.cabal/bin/cabal update

とりあえず動作確認のために pandoc をインストールしてみます。

pandoc を flags=highlighting でインストールします。pcre-light に依存しており、 pcre-light は pcre に依存しています。 ここでは pcre.h は fink の物をとりあえず利用しています。

あと日本語というか UTF-8 等を便利にあつかうために他にもいろいろ入れています。

~/.cabal/bin/cabal install utf8-string
~/.cabal/bin/cabal install zip-archive
~/.cabal/bin/cabal install pcre-light --extra-include-dirs=/sw/include
~/.cabal/bin/cabal install pandoc --flags=highlighting

エラーなくインストールできれば成功です。~/.cabal/bin に PATH を通しておくと便利です。

hg st や hg diff のColor表示

.hgrc 等に以下を記述すると全体的に色がつきます。

[extensions]
color=

これは Color Extension を設定しています。基本的にはこれでほとんどの場合で色が付与されます。

色のカスタマイズをしたければ .hgrc に以下のように色設定を書きます。

[color]
status.added = green bold
diff.deleted = red

細かい設定は Color Extension に記述があります。

これで hg st や hg diff で色が表示されます。

ただ hg diff などは長くなって less をしたくなるでしょうが、less -r しても色は付きません。

Mac OS X 10.6 等の場合は .bash_profile にでも以下のような alias を設定すると良いでしょう。

alias -g V="| /usr/share/vim/vim72/macros/less.sh"

以下のように利用します。

hg diff V

V を付与すると Vim の less.sh マクロの効果で色が付いて表示されます。操作感は less と同じになります。

Mac OS X での Universal Binary で ライブラリ非対応 architecture のバイナリを生成しない方法

例えば Python の easy_install や MacPorts、Fink等の自動インストール系ツールを利用した場合以下のようなエラーが発生することがあります。

ld: warning: in //usr/lib/bundle1.o, missing required architecture ppc64 in file
ld: warning: in //usr/lib/libgcc_s.10.5.dylib, missing required architecture ppc64 in file
ld: warning: in //usr/lib/libSystemStubs.a, missing required architecture ppc64 in file
ld: warning: in //usr/lib/libSystem.dylib, missing required architecture ppc64 in file
ld: symbol dyld_stub_binding_helper not defined (usually in crt1.o/dylib1.o/bundle1.o) for architecture ppc64

これはリンクしようとしているライブラリが ppc64 に対応していないにもかかわらず、ppc64対応バイナリを生成しようとするために発生しています。

この場合は 環境変数に ARCHFLAGS を設定することで回避します。

export ARCHFLAGS='-arch i386 -arch x86_64 -arch ppc'

リンクするライブラリによっては当然 ppc 非対応だったりするため ARCHFLAGS の内容を変更してください。

Mac OS X 10.6 で Goをコンパイルして動作させてみた

Google が 11/10 に新言語 Go を発表したので取り敢えず動作させてみました。

難しいことはなにもない。とりあえず 32bit でコンパイルしたけど、64bitでもコンパイル可能です。テストが一部通過しない物があるみたいですが、後で調べます。

以下の手順でコンパイルと動作確認しました。ソースの取得には Mercurial が必要です。

export GOROOT=/path/to/go
export GOOS=darwin
export GOARCH=386
hg clone -r release https://go.googlecode.com/hg/ $GOROOT
cd $GOROOT/src
./all.bash
cat >hello.go <<EOF
package main
import "fmt"
func main() {
   fmt.Printf("hello, world\n")
}
EOF
8g hello.go
8l hello.8
./8.out

この他にも基本的な物を動作させてみたけど、文法は簡単ですしライブラリもそれなりにあります。

言語的には Limbo とかの影響下にあるように見えるけど、まだちゃんとさわってないので不明です。

RFC の雑学

@nezike が 「メールなどで使う署名なんですけれどまぁよく----------------とか**********が使われますよね。ところで最近--だけとか使っている人がいるんですけれど流行ってるの？」 とつぶやいたので 「署名に -- を利用するのはRFCに記述があります」 と返しました。

@totte が 「RFC‥」 とつぶやき ふぁぼ てくれたりしています。

このやりとりで案外こういうのは知られていなかったりするのだな、と思ったのでメモとして RFC に記述のあるこんな感じの利用者側に影響のありそうな雑学で結構有名な物を書いてみます。

前提として RFC の記述はあくまでお願いの範囲であり、強制ではないことを一言付けくわえておきます。

署名の区切り

メール等の署名に関しては RFC 3676 (RFC 2646 の更新版) 、「4.3.Usenet Signature Convention」に記述があります。

タイトルから分かるようにメールの署名ではなくネットニュースでの署名の区切りに関する記述ですが、メールでも利用されています。

There is a long-standing convention in Usenet news which also commonly appears in Internet mail of using "-- " as the separator line between the body and the signature of a message. When generating a Format=Flowed message containing a Usenet-style separator before the signature, the separator line is sent as-is. This is a special case; an (optionally quoted or quoted and stuffed) line consisting of DASH DASH SP is neither fixed nor flowed.

署名の区切は「ダッシュ2つ+スペース(DASH DASH SP)」にしてほしい旨が記述されています。

ThunderbirdやGmailはこの規定を利用していて、署名に自動的に付与してくれたり、著名を引用しなくしたり等様々な処理をしてくれます。

この文書では他にも「4.2.Generating Format=Flowed」に一行の長さの目安、「4.5.Quoting」に引用記号(「>」)の利用方法等メールで一般的にルールとして適用されている項目が記述されています。

例示に利用を推奨するドメイン名

RFC 2606 に予約されているドメインとして記述があります。

TLD は以下が予約されています。

.test
.example
.invalid
.localhost

.com などの実際のTLDで利用したい場合は以下が予約されています。

example.com
example.net
example.org

予約されているというのは存在しないことを意味しません。よってping等は帰ってきます。

どうしても .jp を利用したい場合はRFCではなく 汎用 JP ドメイン名における予約ドメイン名 に記述があります。

"EXAMPLE","ドメイン名例"
"EXAMPLE"の後に1桁の数字("0"から"9")がつく文字列

メールの送信テスト等で実在するアドレスに送信してしまう事故を防ぐことが可能ですし、blogの記事等で偶然記述したメールアドレスが実在のものであるなんてこともなくなります。

例示に利用を推奨するIPアドレス

IPv4 に関しては RFC 3330 に記述があります。

192.0.2.0/24 - This block is assigned as "TEST-NET" for use in documentation and example code. It is often used in conjunction with domain names example.com or example.net in vendor and protocol documentation. Addresses within this block should not appear on the public Internet.

「192.0.2.0/24」の範囲を利用すれば良いわけです。

IPv6 に関しては RFC 3849 に記述があります。

IANA is to record the allocation of the IPv6 global unicast address prefix 2001:DB8::/32 as a documentation-only prefix in the IPv6 address registry. No end party is to be assigned this address.

「2001:DB8::/32」の範囲を利用すれば良いわけです。

このIPを利用すれば「そのアドレスを利用しているのは私だ事件」のようなトラブルにまきこまれることはありません。

RFC に限らずこの手の記述がある文書が結構あったりします。知っておくと結構役に立つんぢゃないでしょうか。