haskell-jp / random #30

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

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