haskell-jp / random #30

kakkun61
2018-11-15 01:31:41 +0900
skip-msys は試したことなかったですね。
なるほど。
とはいえ、やること同じになりそう。
今回は hsexif を使おうとしたら iconv に依存していたのでした
kakkun61
2018-11-15 01:38:28 +0900
今更気づいたんですが、iconv 不依存でビルドするフラグが用意されていた
https://www.stackage.org/haddock/lts-12.18/hsexif-0.6.1.6/Graphics-HsExif.html
sawada
2018-11-16 07:15:47 +0900
@sawada has joined the channel
igrep
2018-11-16 07:57:48 +0900
"This book aims to be the comprehensive manual for type-level programming" https://leanpub.com/thinking-with-types/
kuono
2018-11-16 13:10:40 +0900
@kuono has joined the channel
matsubara0507
2018-11-17 13:19:15 +0900
Dhall 移植作業、だいたいわかったので雑に作った
https://github.com/matsubara0507/yaml-to-dhall
as_capabl
2018-11-19 12:06:12 +0900
DhallのC/C++バインディングって存在してないんですね。 hsc2hs でCとHaskellの型をそれぞれ生成して、C/C++からFFIすれば読めそうなイメージ
as_capabl
2018-11-19 12:06:35 +0900
Dhall布教のために、ちょっと検証してみましょうか
as_capabl
2018-11-19 12:33:56 +0900
…と思ったのですが、Haskellの data で定義した型をCから読めるようにするのは hsc2hs では出来なさそうでした
matsubara0507
2018-11-19 13:55:05 +0900
Dhall のコメントアウトって冒頭しか残らないのか、フォーマッターとかで
syocy
2018-11-19 13:58:25 +0900
dhall format の仕様でそうなっていますね
syocy
2018-11-19 14:00:13 +0900
AST構築の関係でそうなっているっぽい？ https://github.com/dhall-lang/dhall-haskell/issues/145
matsubara0507
2018-11-19 14:06:02 +0900
なるほどコメントアウトを保持して整えるのって大変なのか
Hiroto
2018-11-19 14:41:24 +0900
https://taylor.fausak.me/2018/11/18/2018-state-of-haskell-survey-results/#
グラフとその下にある表のパーセンテージが全然噛み合ってないように見える（多分未回答の人の分もカウントしてるから？）から最初戸惑った。
Hiro
2018-11-20 11:51:12 +0900
@Hiro has joined the channel
matsubara0507
2018-11-21 12:13:34 +0900
Hasパターン使うと、env を共有できるのか（していいのかはわからないけど）
jeedo
2018-11-21 16:36:54 +0900
@jeedo has joined the channel
fumieval
2018-11-21 19:50:16 +0900
Haskell-jpではプロジェクトのビルドといえばstackが定番ですが、最近cabal-installはNix-style local buildという、依存関係をプロジェクト単位で管理する仕組みが充実してきています。そこで、ディスク使用量削減も兼ねて私のstack関係のデータを全消しし、代わりにcabal new-buildでビルドしてみる、名付けて「脱stack計画」の実行を宣言します。このスレッドで経過を報告するのでお楽しみに
matsubara0507
2018-11-21 22:35:24 +0900
ダツスタ
maoe
2018-11-21 22:56:11 +0900
僕もしばらくcabal new-buildをメインに使っています。ライブラリを作る人は複数バージョンのGHCが試しやすいのでおすすめします。/opt/ghcにいろんなバージョンのGHCをインストールしてPATHを通しておき、-w ghc-8.6.2とオプションを渡すだけでバージョンを切り替えられて便利です。
maoe
2018-11-21 23:01:42 +0900
個人的な印象では不可解なビルドエラーに悩まされることがcabalの方が少ない、複数バージョンのGHCを切り替えやすい、backpackやパッケージ内複数ライブラリの対応など最新の機能がcabalから実装されること、プロファイルや最適化オプションの変更時などstackでは適切にリビルドしてくれないことが多かったことなどからnew-buildがメインになりました
2018-11-22 00:16:05 +0900
実はstackしか使わず、cabal hellを伝え聞くだけの身としてcabalをなまで扱うのは恐れがあったりします
りんご姫
2018-11-22 06:05:33 +0900
そうそう意外と、cabalも昔ほど地獄じゃなくなったんですよね。 ただ、stackを使う利点だなと思ってる事は、stack.yaml が与えられらプロジェクトでは安定したビルドが得られる (allow-newer が指定されてる場合を除く)事だと思ってるんですよね。 まぁ、正確にはcabalだけでも同じ事は出来ますが、build-dependsを全部正確に書いてるプロジェクトをそこまで見た事ないですね。
maoe
2018-11-22 06:58:45 +0900
cabalの場合はビルドが成功した時点でcabal new-freezeすると依存バージョンを固定できます
igrep
2018-11-22 07:34:16 +0900
stack build --file-watch 相当のものってあるんですかね。（まぁ、なくても他のアプリで代替できるでしょうけども）
maoe
2018-11-22 07:51:49 +0900
ないと思います
りんご姫
2018-11-22 08:20:23 +0900
ghcid 使えば、それっぽい事は出来るんじゃ？。。。ってあれ？これじゃ、stackの存在意義って。。？
igrep
2018-11-22 08:35:48 +0900
ghcidねぇ、プロジェクトによってはstack build --fastの方が速かったりもしたり、必ずしもイケてるとは思えないんですよねぇ。
igrep
2018-11-22 08:38:37 +0900
いずれにしても、「必ずビルドできるバージョン群」を提供する本来のStackage（と、その簡単なクライアントであるstack）の意義はなくならないと思いますよ。一発でビルドできない場合もあるでしょうから。
そのうち置き換えられる可能性は確かにあると思いますが
syocy
2018-11-22 12:07:03 +0900
たしかstackのモチベーションとしてライブラリ作者は自分で依存マネージができるけどユーザや初心者はそうではないから…というのがあった記憶が
hexirp
2018-11-22 16:03:38 +0900
この辺りですよね？書いてあることを読んだら Stack でやっていることと同じでびっくりでした https://www.haskell.org/cabal/users-guide/nix-local-build-overview.html
hexirp
2018-11-22 16:05:47 +0900
あ、後、githubにホストされているライブラリに依存する機能が代替できるか気になります
fumieval
2018-11-22 20:52:50 +0900
脱スタ1日目: .stackと.stack-workを削除。.stackは19GB、各プロジェクトの.stack-workは合わせると9.6GBで、合計およそ29GBの領域を食っていました。~/.stack/config.yamlを残しておさらば :wastebasket:
2018-11-23 04:32:02 +0900
@ has joined the channel
fumieval
2018-11-23 17:04:06 +0900
脱スタ2日目: ghcup () を使う。ghcupスクリプトを適当な所にダウンロードし、 ghcup install 8.4.4 とかを実行すればインストールしてくれる。そして ghcup install-cabal でcabal-installをインストール
aiya000
2018-11-24 10:09:52 +0900
やはりdep hellに遭遇する頻度と、解決への労力が気になる:eyes:
new-freezeいいな
fumieval
2018-11-24 21:36:32 +0900
脱スタ3日目: 手元にある自分のライブラリはだいたいcabal new-buildでビルドできました。stackと違ってプリコンパイルされたものは使わないので最初はゆっくりですが、resolverごとにビルドする必要はないため、パッケージが揃ってくるとどんどんサクサク感が出てきます
Chris
2018-11-25 17:54:29 +0900
@Chris has joined the channel
umeneri
2018-11-25 20:13:32 +0900
@umeneri has joined the channel
2018-11-26 00:07:52 +0900
@ has joined the channel
syocy
2018-11-26 11:01:15 +0900
Google なんかはオープンにしないコードは single repository で管理しているという話があり、そういう環境では stack で外部の依存合意を使う必要はないので cabal-install で自前依存管理するのが妥当だなあという気がしてきました。
りんご姫
2018-11-26 23:24:20 +0900
そう言えば、思い出したんですけど、 intero ってcabalだけで出来ますかね？ intero に慣れすぎてあれなしでは生きられない(?)んですけど、、、
igrep
2018-11-27 08:11:22 +0900
私が調べた時点ではstack必須だったはずです。だからあれは手出したくないんですよねぇ :disappointed_relieved:
igrep
2018-11-27 08:20:17 +0900
クロスコンパスのHaskeller募集。日本人も募集しているかは定かではないですが共有しておきます。
https://www.reddit.com/r/haskell/comments/a0iq61/job_cross_compass_is_currently_hiring_haskell/
kayhide
2018-11-27 11:16:15 +0900
こんにちは、クロスコンパスの kayhide です。

日本人も募集しています。
チームには外国人もいるのですが、みなさんかなり日本語を喋れますので、英語力に自信がなくても大丈夫です。
“Ideal candidate”のところは高すぎる理想像なので、満たしていない方でも全然大丈夫です。（外国人むけに、そこは強気でだしています）
興味がある、もっと詳しく聞きたい、などありましたら気軽に DM してください。
東京近傍であれば、ランチ食べながらでもお話しましょう！
kayhide
2018-11-27 11:19:36 +0900
応募自体は日本語でも大丈夫です！
GrimssonG
2018-11-27 15:55:11 +0900
@GrimssonG has joined the channel
fumieval
2018-11-28 18:08:32 +0900
まさか国籍で制限するということはないと思います。仮に日本人というだけで採らない企業があったとしたら相当ヤバイですね…