haskell-jp / random #41

@buddha0818 has joined the channel
@takashi.mtsd has joined the channel
噂のMonadです.
@dyoshikawa1993 has joined the channel
ここまでの内容をまとめました。
https://gist.github.com/waddlaw/b6a14d4dbc94d282a175abe7f9596ae7

ubuntu に環境を整える場合についての質問です。
apt を使って haskell-platform をインストールする方法が使えないとなると、僕は以下の3種類ぐらい方法が思い浮かぶのですが他にありますか?

方法1: ppa で ghc と cabal-install を入れる
方法2: ghcup で ghc と cabal-install を入れる
方法3: stack を使う

また、どの方法が一番良いかという点についても、ご意見ありましたらお願いします。(個人的には方法1が良いんじゃないのかなと思っています)
ライブラリーのバージョンを簡単に固定できそう、という意味で個人的にはstackを支持します。
まあ、cabal.configでバージョンを明示すればいいんでしょうけど
Current Stable Releaseも直ってますね!
シリアライズライブラリwinery 1.0、解説記事(日英)とともに近日公開予定です。お楽しみに
Twitter で Haskell 初心者がハマったと教えてもらったコード
確かにしばらく悩んだ
main = do { let x = 1 ; print x }

https://wandbox.org/permlink/fizUVfdvTZYRUwJ5
let x = 1; y = 2がvalidなんですね。使ったことないですけど
そう。言われてみると let の後インデントでまとめられるのでそうなるんですよね。
ああー、分かりにくいですね。コードの形を保ったまま正しくするならば main = do { let { x = 1 } ; print x } かな?
@trueshot86 has joined the channel
@elkel53930 has joined the channel
shinji.hatayama709
@shinji.hatayama709 has joined the channel
@fuuzetsu has joined the channel
@oswald_boc has joined the channel
stack を使う場合のコマンドってどんな感じを想定してますか?(curl で stack をインストールしてからの流れです)
グローバル環境で使うことがほとんど無いのであんまり具体的なコマンドが想像できなくて・・・:turtle:
これはparse errorにするのが正しいのですかねぇ?
full-bracedじゃないからややこしいのかなぁ
validSyntax = do
  { let x = 1
  ; print x
  }

はvalidなのに...
@viktor.kronvall has joined the channel
@onwarmermusic has joined the channel
そか.
validSyntax = do
  { let x = 1; y = 2
  ; print $ x + y
  }  

はOKだけど,
invalidSyntax = do
  { let x = 1
  ;     y = 2
  ; print $ x + y
  }

はNG
validSyntax = do
  { let x = 1
        y = 2
  ; print $ x + y
  }

はOKってことね.
stack setup --resolver lts-13.10 をして、コンパイルは今までの ghc -o ./a.out -O2 ./Main.hs でできそうに思います。
あ、すみません、 ghc は stack ghc で呼ばないといけないですね…
PATHstack setup して入れたGHCへのパスを追加する必要がありますね。
ちょっと調べてみましたが、 $(stack path --programs)\ghc-<version>\bin\ を追加すればよいかと。
あるいは、 stack exec ghc -- とするのが一番確実でよいかと。
紛らわしいですね。。。その書き方はするな、が正解なんでしょうけども。。。
stack ghcstack exec ghc って同じなんでしょうか? https://docs.haskellstack.org/en/stable/GUIDE/#ghcrunghc を見るとたぶん同じっぽい…?
変に stack が噛まないぶん、 stack exec ghc のほうがいいんですかね…
ああ、この間 https://haskell-jp.slack.com/archives/C4M4TT8JJ/p1550662373045300 あたりで話題になった件ですね...
stack ghc限れば stack exec ghc と何も変わらない(はず)なので、どちらでもいいと思います。
私は他と一貫させるために癖で stack exec ghc を使っていただけです。
@ramin.honary has joined the channel
`PATH` に `stack setup` して入れたGHCへのパスを追加する必要がありますね。
ちょっと調べてみましたが、 `$(stack path --programs)\ghc-<version>\bin\` を追加すればよいかと。
あるいは、 `stack exec ghc --` とするのが一番確実でよいかと。

ありがとうございます。Dockerfile 作って試してみます。

グローバル環境で --package vector のようにパッケージをインストールおよび指定する際は普通に stack install vector してから stack exec ghc --package vector とかで動くんですかね。(一応この手順で上手くいくかどうか確認してみます)
--package オプションは要らないはずです。多分エラーになります。
@okimoto has joined the channel
@jesper has joined the channel
http-clientが「newManagerを使え,使い終えたらGCで自動回収される,closeやwithはDeprecatedだから使うな」って主張してるんですけど,
こういう設計ってメモリに余裕があってもポート番号が死ぬとかが容易に発生しそうなのでwith系のAPIを使っていきたいと思うんですが間違った考え方なんですかね…?
そもそもhttp-client的には1つのManagerを使いまわせって感じで書いてるんですがマルチスレッドプログラムだとどのへんまで使い回せば良いのかよくわからなくなってきます.
https://www.stackage.org/haddock/lts-13.12/http-client-0.5.14/Network-HTTP-Client.html#v:newManager
私の記憶が正しければ、 Manager は別にコネクションとか解放必須なリソースを保持しているわけではなかったような気がします。
プロキシ設定とかその辺のmanagerだったような...
確かによくソースを見てみたら
closeManager _ = return ()

でした…この場合close何の意味もないですね…
ああ、と思ったけどすみません、実際にはconnection poolは保持してますね...
おそらくポート不足などにはならないようにしたり排他処理したりはこのconnection poolがよしなにやってくれているのではないかと...
https://github.com/snoyberg/http-client/blob/c1c6ffa9e7bf3556f8577b12fc2ccb3e92b080a4/http-client/Network/HTTP/Client/Manager.hs#L123
中規模Yesodプロジェクトの古いLTSからLTS 13(Yesod 1.6)への移行やっと終わった
esqueletoが死んだら引き取って自分で新しいGHC向けに治さないと死ぬと思ってヒヤヒヤものだった
これ、自分も気になった記憶がある
JavaとかならThreadPoolExecutorみたいなのがあってもオブジェクトなので不自然ではないですが,
HaskellでIOを使うと言っても単独の関数がプーリングしてるとなんか気味が悪いと思ってしまいますね…
@vqgofndplhjr has joined the channel
HIEでhlintかけるとき勝手に`TypeApplications`拡張が有効になるようです。
https://github.com/haskell/haskell-ide-engine/pull/298
何じゃこりゃ、と思ったけど、別にこれ {-# LANGUAGE TypeApplications #-} を強制的に挿入するわけじゃないですよね... :relieved:
http://www.radicle.xyz/ GitHubのような、ソースコードを共有するコラボレーションツールだけど、すべてP2Pで動くらしい。 :serval:
Haskell製で、まだ開発中。
@igrep そういえばなんですが、 https://wiki.haskell.jp/Haskell-jp%20Logo%20History で紹介されているロゴの歴史にトラビスさん作成の書道ロゴも含めませんか? / "第0回 スタートHaskell : ATND" https://atnd.org/events/17468