Mercurial Repository を Git Repository に変換する

Findy という転職サイトが GitHub の public repository からスキル偏差値なるものを算出してくれます。
一度登録してみると、スキル偏差値はプレミアム本会員になるギリギリの60でした。
実際どのくらいなのだろう60。定量的な値になってると良いのだけれど。

さて、 GitHub には大学とは関係ない個人のプロダクトとかを載せていました。
大学での課題やプロダクトは大学の Mercurial Repository に残しています。
ですが、この際 GitHub にも載せることにしました。
単にスキル偏差値を上げたいだけとも言う。
単に bitbucket に上げても良いのだけれどそれだと Findy に拾って貰えないので。

環境構築

Mercurial から Git への変換は fast-export を使います。

• $ git clone https://github.com/frej/fast-export

こいつは python を内部で使ってるのでその調整も必要です。

• $ easy_install mercurial

とかかな。

私は python2 を brew で明示的に入れてるので

• $ vim fast-export/hg-fast-export.sh
• python -> python2
• $ pip2 install mercurial

とか。実行時にエラーが出なければOKだと思います。

自分だけが Author の Mercurial Repository の変換

fast-export のセットアップが終わったら、変換します。

• $ mkdir git_repo
• $ cd git_repo
• $ git init
• $ ../fast-export/hg-fast-export.sh -r /path/to/hg_repo

これで Mercurial の Repository を元に git に commit しまくってくれます。

きちんと時刻とかも残るので便利。

Author Information が気に入らない場合

私は大学時代の時は大学のメールアドレスで commit していたので、GitHub にはアイコンが無い。

これはちょっ悲しいので Author の情報を変更する。

具体的には username と email ですね。変更するには

とかすると良い。長いけれど1コマンドです。

これは他人の commit も変更できちゃうので完全に悪用厳禁ですね。

他の人も commit している repository の変換

最初にやることは変わらずに変換。

• $ ../fast-export/hg-fast-export.sh -r /path/to/hg_repo

んで、 Author を変更する時に発行するコマンドを変えます。

if 文で自分の変えたい username+email を指定してあげています。

これで指定したものだけが変更されます。便利。

こっちも長いけれど1コマンドですね。

これで他人の成果をきちんと残したまま、自分の気に入らないメールアドレスを書き換えられます。

やっぱり悪用厳禁なコマンドなので注意。

fast-export で変換した Repository List

どうせなので公開できる成果物のリストを残しておきます。

• GitHub - atton/agda-proofs: Agda proofs
• GitHub - atton/delta_monad: My Thesis(Notation of Program Modifications)
• GitHub - atton/dockerfiles
• GitHub - atton/FileWrite: Exercise of Operating Systems in University
• GitHub - atton/heroes_and_daemons: Battle Game for exercise in University
• GitHub - atton/similar_monad: prototype of delta monad
• GitHub - atton/slideshow-cr: Slideshow theme for cr-ryukyu
• GitHub - atton/slideshow-s6cr: Slideshow theme for cr-ryukyu(S6)
• GitHub - atton/tapl: Types and Programming Languages
• GitHub - atton/unity-network-sample

思ってたよりありますね。仕事してたなー。

この成果物が誰かの参考になれば幸いです。

オチ

この後 Findy で GitHub 再連携をしたところ、算出方法が変わったようで51に下がりました。かなしい。

環境

• OS: macOS 10.12.6
• fast-export (cc8fefe0083bc38c781341a86a1779dc5941f6e2)
• python: 2.7.10
• pip: 9.0.1
• mercurial: 4.3.3
• Mercurial: 4.3.3
• Git: 2.14.3

参考

• ハイスキルなエンジニアのプレミアム転職Findy（ファインディ）
• GitHub - frej/fast-export: A mercurial to git converter using git-fast-import
• Git の Commit Author と Commiter を変更する - Qiita
• Git - 歴史の書き換え

Implementing a JIT Compiled Language with Haskell and LLVM を chapter 3 までやってみた

Haskell + LLVM で言語を作ってみる Implementing a JIT Compiled Language with Haskell and LLVM というページがあったのでちょっとやってみました。
LLVM-IR を吐くところまでは動いたのでそのメモ。
作成した repository は github の atton-/kaleidoscope にあります。


ページに書かれているコードを写経していたら chapter 3 くらいから問題発生。
Webに書かれていることを写経してもコンパイルが通らない。
本家のコードを chapter 2 で定義した Syntax と chapter 3 で定義された Syntax は違うようです。
他にもWebには書かれていない関数があったりしたので、エラーが出たら本家のコードを見つつ chapter 3 の Code Generation までは書けました。

ここで追加で問題発生。 llvm-general を ghci から使おうとすると

<interactive>: /usr/lib/llvm-3.5/lib/libLLVMSupport.a: unhandled ELF relocation(RelA) type 42

と出て動かない。
OSX 10.10.5 / Ubuntu 16.04 / Fedora 23 / Fedora24  on Docker で動かしたり stack を使ったりしたが解決せず。
ちなみに OSX では

lookupSymbol failed in relocateSection (RELOC_GOT)
/usr/local/Cellar/llvm35/3.5.1/lib/llvm-3.5/lib/libLLVMProfileData.a: unknown symbol `___dso_handle'

と出て動かなかったです。

https://github.com/DanielG/ghc-mod/issues/762 とかを参考にしながら

--ghc-options="-opta-Wa,-mrelax-relocations=no"

を付けて cabal で install したり stack の stack.yaml に書いたりしましたが動かず。

最終的に ghci では動かないけれど ghc では動きました。どうも良く分からない……

Fedora 23 on Docker で動かした時の Dockerfile はこれです。

一応 Ubuntu 16.04 でも ghc でなら動いたはずです。

Haskell の環境構築とかデバッグとかのノウハウの不足を感じる。

環境構築で結構力尽きた感も若干あるけれどどこまで続くかな。

Homebrew で debug symbols を埋め込んだ LLVM の bottle を作る

Homebrew の bottle を使って debug information が埋め込まれた LLVM を配ってみんなで読もう、ということになったのでそのログ。

環境

• OSX Yosemite 10.10.5
• Homebrew 0.9.5
• LLVM 3.8
• あと自分のマシンじゃないのでチェックしてないけれど El Capitan (10.11.1?)

Release Build の LLVM の bottle 化

私が所属している研究室では Continuation Based C (CbC) という言語を開発していて、LLVM implemented 版があるのでまずはそいつで bottle で作れないかをチェック。

formula は github の ie-developers/ie/cbc にあります。

普通に build した LLVM を bottle にするのは結構簡単で、

• brew install --build-bottle ie-developers/ie/cbc
• brew bottle cbc

とか。 これで build された binary を固めたやつが current directory にできます。

ついでにこうやって書いてね、って出力が sha256 と共に出てくるのでそいつを formula に追記して、 bottle を公開用サーバか何かに置けばOK.

LLVM 3.8 の build を bottle 化

いつからか LLVM は build を repository の top でやると怒るようになってます。

具体的には ./configure をすると怒ってくる。

そいつを回避するために Homebrew 公式の llvm は mktemp を使っているようです。

なので mktemp を使ってやれば最近の LLVM も bottle 化することができます。

LLVM 3.8 を debug information 付きで build して bottle 化

ひとまず LLVM 3.8 を debug information 付きで build する手順としては

• git clone http://llvm.org/git/llvm
• mkdir llvm_build
• cd llvm_build
• ../llvm/configure --enable-debug-runtime --enable-debug-symbols --disable-optimized --enable-assertions
• make -j 3

とか。

Debug+Assets って directory に bin と lib ができるのでそいつで追えます。

具体的には

• lldb Debug+Assets/bin/clang

とかできます。

LLVM 3.8 を debug information 付きで build

Homebrew は build する時のディレクトリは build 時に生成して install 後に捨ててしまうっぽいです。

なので build 場所を変えてバイナリを残すように。

formula の prefix ってメソッドがインストール先のディレクトリを返してくれるので、その下で build しちゃいます。(ちなみに prefix の値は "/usr/local/Cellar/llvm_original/llvm3.8/" とか。)

インストール先のディレクトリで直接 build するれば、Debug+Assets が bottle に入るんじゃないかって魂胆。

あと、 Homebrew は make する時に CFLAGS とかを変更しちゃう superenv ってのがあるらしく、そいつは勝手に -g とかを落とすっぽいです。

なので build する時に --env=std とかすると良いらしい。

ってなわけで

• brew install --env=std --build-bottle ie-developers/ie/llvm_original
• brew bottle

とかすると OK。

ちなみに圧縮前は8.9Gで圧縮後は2.1Gほど。

あと LLVM はとりあえず make するとこで止めてます。ファイル多くなっちゃいますし。

bottle を展開して lldb で追う

あとは落として追えば良いです。

が、 brew が build 時に buildpath を /private/tmp に作っちゃうのでそのパスを解決してやれば良い。

• hg clone http://firefly.cr.ie.u-ryukyu.ac.jp/hg/CbC/LLVM_original /Library/Caches/Homebrew/llvm_original--hg
• ln -s /Library/Caches/Homebrew/llvm_original--hg/ /private/tmp/llvm_original20151205-42569-opu2br

とか。

これで

• lldb /usr/local/Cellar/llvm_original/llvm3.8/build/Debug+Asserts/bin/clang
• l main

とかしてソースが表示されます。やったね。

ちなみにこの path は Yosemite の場合なので El Capitan の path はまた別です。

lldb が l main して時にファイルが無いって文句言うはずなのでそれを解決できように symlink 貼れば良いはず。

よもやまばなし

以下適当に本筋と関係無い話。

Cmake で build

Brew 公式の lldb は cmake で make してるっぽいです。

formula の中では std_cmake_args ってものを持ってるらしく、そいつが  -DCMAKE_BUILD_TYPES=Release を突っこむっぽいです。

なので CMAKE_BUILD_TYPES=Debug とか入れても弾かれる。

RelWithDebugInfo とかもあるのでそいつでもいけるかも?

superenv を見つけた話

どうも -g が有効じゃないっぽいのでログを漁ってたら

• superenv removed:  -g -Wcast-qual -m64 -Wall -W -Wwrite-strings

とかあったので調べてみました。ログつよい。

ちなみにログの場所は

• less ~/Library/Logs/Homebrew/llvm_original/02.make.cc

とかです。

superenv は -g を落として -O2 とかを入れてくれるっぽいので brew は Debug Build は基本入れない方針っぽいです。

もちろん --env=std で回避手段があるのは流石ですが。

Mach-O

ちなみに -g が効かないのを探すために Mach-O の仕様とか dSYM とか DWARF とか symbols コマンドとか dsymutil とか調べたりしてました。

その辺の hello.c とかコンパイルすると dSYM が作られて、そいつを消すと追えなかったのでこの辺が問題なのかなー、とか思ってゴニョゴニョしてました。

結果的にはハズレか。

make install してない

どうせ Debug+Assets が残ってないと追えないので make install はしてません。

なので brew link とかは効かないです。

make install した clang も Debug+Assets の debug symbols を見にいくはずなので、二重に clang 作るのは容量的に勿体ないかな、と。

参考文献とか

• LLVM - Game Lab -PukiWiki-
• homebrew/Bottles.md at master · Homebrew/homebrew · GitHub
• homebrew/Formula-Cookbook.md at master · Homebrew/homebrew · GitHub
• Building LLVM with CMake — LLVM 3.8 documentation
• Homebrewのちょっと前のFormulaを使うときにハマった - IwazerReport
• Executing Mach-O Files
• Debug Symbols on Mac OS X
• symbols(1) Mac OS X Manual Page
• osx - where/how does Apples GCC store DWARF inside an executable - Stack Overflow