Skip to content

Instantly share code, notes, and snippets.

@sys9kdr
Last active January 24, 2018 01:32
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save sys9kdr/2484ed09f5cb7ea86beae8f5222d9a3c to your computer and use it in GitHub Desktop.
Haskell入門しようとして環境構築で失敗。

この記事はHaskell (その3) Advent Calendar 2017の5日目の記事です。Haskellの環境構築につまずいた経験をシェアーします。

2017年、Haskell入門元年

関数型プログラミング言語の親玉Haskell。昨今の関数型ブームで学びたいと思ってる人も多いんじゃないでしょうか。 今年は『Haskellによる関数プログラミングの思考法』『Haskell 教養としての関数型プログラミング』に『Haskell入門 関数型プログラミング言語の基礎と実践』と入門書がバンバン出ています。 まさしくHaskell入門元年ですね。

というわけでこのビッグウェーブに乗じて入門しようと思ったのですが、環境構築で失敗しました。

利用環境と構築しようとした環境

Haskell入門 関数型プログラミング言語の基礎と実践を参考に、Stackを用いた環境構築を試みました。

StackはHaskellのビルドツール兼パッケージマネージャーのわりとなんでもいりのオールインワンツールです。2017年末現在、Haskellを開発するうえでのデファクトになっています。GHC(Haskellのコンパイラ)とcabal(パッケージマネージャー)のラッパーのような役割を果たしています。おまけにコンパイラの取得までやってくれます。

環境構築失敗 on Windows 10

tl:dr; 日本語ユーザー名だと動かない。

まずWindowsに入れようとしたところ動作しませんでした。

  1. https://www.stackage.org/stack/windows-x86_64-installer からファイルをダウンロード
  2. インストーラーを実行、成功。
  3. stack new my-projectでプロジェクト立ち上げる。 ←ここまで順調。
  4. stack ghciでプロジェクトを動作させようとしたところ動作しない。

ここでだいぶつまずいて調査したところ日本語ユーザー名(ユーザー名にnon-ascii文字が含まれる)だと動かないようです。ありがちですね。 この点、上述の書籍にはユーザー名によっては動かない旨書いてあります。

回避策

日本語じゃないユーザー名作ってそっちでやる。

環境構築失敗 on Bash on Ubuntu on Windows(正式名称Windows Subsystem for Linux)

tl:dr; Bash on Ubuntu on Windows、遅い。

ユーザーを新規作成するのも面倒だったので、Windowsで動かないツールを動かす大本命、WSLを使うことにしました。 WSLはWindows上にLinuxのCLI環境を構築しようというBash on Linux-Distro on Windowsなサブシステムです。 Ubuntu(Linux)なのでStackのインストールもwget -qO- https://get.haskellstack.org/ | shで一発です。

気を取り直してWSLでStackを動作させます。はじめはstack setupでGHCの実行形式ファイルを取ってきたり等々で若干立ち上がりが遅いですが、 これらのインストールさえ済めば、素早く動作するはずです。 stack ghciでインタープリター起動してWelcome to Haskell World...と思ったところでが問題が起きます。

必要なファイルの準備は済んでいるのに遅い!

必要なファイルのネットワーク越しの取得はすべて済んでいるのに、ghci(Haskellの対話実行環境)やビルドが異常に遅いのです。下記の簡単なワンライナー実行するだけで6秒もかかります。

$ time stack ghc -- -e 'print "Java + You"'
"Java + You"

real    0m6.592s
user    0m0.172s
sys     0m10.938s

仮にHaskellのコンパイラが遅かったとしても(実際はほどほどに速いです)、この速度は遅すぎるということで問題がなぜ発生するのか調べてみました。

結論

WSLのディスクアクセスが遅い。WSLはディスクアクセスが遅いために一部のプログラムの動作が異常に遅いらしいです。

今回取り上げたstackの他にはtarnpmyarnあたりもがっつり遅いっぽいです。面倒なので試していません。

回避策

stackを利用していてWSLが遅い問題を回避するには、ghcを--disable-large-address-spaceでビルドするという回避方法があります。

これはGHCのアドレス空間を1TB(巨大ですね)とる設定を無効にするビルドオプションです。ディスクアクセスが遅いならデカすぎるアドレス空間を制限すればなんとかなるだろうということでしょう。

これで問題は解決しますが、せっかくコンパイラまで持ってきてくれるオールインワンツールを使っているのに、わざわざ自前で再度コンパイラをコンパイルするのはちょっとダルいです。今回はこの回避方法は見送り、WSLでStackを動作させるのはあきらめて新しくユーザーを作成してWindows上で試しました。

まとめ

  • Haskellのビルドツール的なStackが今最高にナウい
  • 日本語ユーザー名だとStack使えない
  • WSLだとStackが遅くて使い物にならない
    • 回避策はあるけどダルい

試行錯誤の末、無事にStackを使えるようになってからは楽しくHaskell入門しました。型の読み方がわかるとグッと面白くなりますね。

上級者向けの内容ではありませんが、Haskellの環境構築でコケてる人の参考になれば幸いです。


参考文献

@igrep
Copy link

igrep commented Dec 4, 2017

手前味噌ですがこちらの記事で触れているように、バッチファイルでstack.exeをラップするという方法はいかがでしょうか?

(ちなみに、このセクションが書けたのはHaskell入門のレビューをしているときに問題のIssueを目にしていたおかげです!ありがとうございます! 😏 )

@sys9kdr
Copy link
Author

sys9kdr commented Dec 12, 2017

ありがとうございます。現実的な解決法ですね 🙆‍♂️

ただ、個人的には環境変数をいじってこけるケースがでてくるのではないかと不安になってしまう(問題の切り分けの何度が上がる)ので、新規ユーザー作成が安心な気はしています。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment