haskell-jp / random #35

あ、あと、stack build --ghc-options=-jとすればモジュール単位の並列化までできますが、そういう話ではない?
日本語は悪。はっきりわかんだね。
-j、あったのか!!
プロジェクトのビルド早くしたくて前にそれ追いかけてたんですが現状だとそれやると何故かシングルスレッドより遅くなるみたいなベンチマークが出てきてましたね
https://ghc.haskell.org/trac/ghc/ticket/9221
これですね
8.6で解決されたとか書いてますし試してみるかー(私の本番プロダクションはesqueletoのせいでまだlts 10なんですが)
stackを新しくしてからglobal installしたモジュールがglobal importで読み込めなくなってるな
と思ってghciを素で起動したら読み込まれる
interoがglobal moduleを認識しなくなっている?
あれ起動し直したら認識するようになった
intero-restartでも認識しなかったのに…
esqueleto, countとかsumとか使いたくなった時にクソナガ型注釈が必要になるのやめてほしい
E.orderBy [ E.desc $
            -- 何故かsumには長大な型注釈が必要
            (E.sum_ :: E.Esqueleto query expr backend => expr (E.Value Rational) -> expr (E.Value (Maybe Rational))) $
            foo E.^. Bar
          ]

何故この型注釈が必要になるのか全くわかっていない
@skazufumi.a02525 has joined the channel
@koyama has joined the channel
@zokutyou2 has joined the channel
そーいやHaskellに限らないんですけどマルチスレッドでロギングする(特に一つのファイルに書き込む)ときってどうしてんでしょ。ロギング用のスレッド立ててキューを介してログ出力がベストプラクティス?
ロギングくらいなら完全排他ロックでも良いのでは感
あとは、sqlite使っているプロジェクトなら、ログもsqliteに吐くのもありかなと(ちょうどHaskellにはHRRがあるし)
スレ数によりますけど、一スレ一ファイルみたいなのもありかな? 少量ならばね
あ、一つのファイル前提か、ならロック安定かなー
Haskellならスレッドが軽いので、ログ出力メソッドを呼ぶ度にforkIOでも行けそう。立てたスレッドはファイルロックが取れるまで固まるけど、fork元はそのまま走れる
規模によりけりっぽいですね。大規模なサーバならともかく小さめのやつなんで色々試してメンテなビリティ良さそうなのを考えてみます
ロック機構ついてたんですね。ソースコード斜め読みでついてないと思ってました……
ロック安全かどうかも型で分かったらいいこと、、、あるのかなぁ?
esqueleto全然わからんけど(:mask:)
TypeApplicationsできないかな:thinking_face:
@tatsuhiro.9699 has joined the channel
MVar Handleとして持って、使うときだけmodifyMVarで取り出すというトリックを私はよく使います
知らなかった。こんな本の執筆が始まってたんですね。
https://www.manning.com/books/haskell-in-depth
執筆中の部分読めるんだ(?)
実に今時らしいやり方だと思います! :sunglasses:
@kazy.crazycloud has joined the channel
天文学関係の記事を見てたら、予想外のところで Haskell が出てきて不意打ちされた https://ja.m.wikipedia.org/wiki/%E3%82%A2%E3%83%88%E3%83%91%E3%83%BC%E3%82%BB%E3%82%AF
parsec, megaparsec もそうですよね。
吹き出すような名前の候補を出すGitHubが悪いとおもいまぁす いや、センスは好きだけどね
そうだったのか
parsec系
結構昔のシンタックスじゃないっけ
location
GHC 8.4 で問題ないのに 8.2 で型エラーになるコードができた……(厳密には resolver が違う
@kenta.teruteru has joined the channel
@keikagawadesu.7k has joined the channel
会社 PC で試したら Windows MAX_PATH の問題だったっぽい
帰ったら家のエラーもう一度見てみよう
https://ja.m.wikipedia.org/wiki/ホモロジカルミラー対称性予想 物理関係で圏論の最先端なので興味を持ったやつ
少し前のもくもく会で「ケーラー多様体」という言葉がちょっと聞こえてきたような気がするんですが、気のせいだったかも知れません
なんかちゃんとコンパイルできたぞ
https://www.reddit.com/r/haskell/comments/ae1i6z/reminder_please_submit_gsoc_ideas/
今年の夏に学生が取り組むGoogle Summer of Codeのプロジェクトアイデアを募集しています。現在のアイデアリストは https://summer.haskell.org/ideas.html で見られます。また、リストに無いアイデアを持っている方は https://github.com/haskell-org/summer-of-haskell にPRを送って新しいアイデアを提案できます。

学生の方は取り組みたいプロジェクトがあるかあらかじめ目を通しておくと良いと思います。また、参加者を募集する段階で参加者自身がアイデアを提案することも出来ますが、なるべく早めに自分のアイデアを上記リポジトリで提案したり、mentor or maintainerと相談しておくと採用される可能性が上がると思います。
GSoC関連で何か質問があれば僕が受け付けますのでお知らせください。
@ktchg752 has joined the channel
trace を入れれば終了するけど、それがないと待てども終わらないコードができたような……
きっと疲れてるんだ
@kilo7998 has joined the channel
まだ途中ですけど、少し前から作っていたDhallのCバインディングをgithubに上げてみる https://github.com/as-capabl/clay-dhall
こんな感じでDhallの解釈結果をCに取り込めます https://github.com/as-capabl/clay-dhall/blob/master/ctest/type.c
base パッケージのドキュメント部分にこまかいまちがい見つけたんですが、ghc の trac に issue として上げればいいんですかね?
直接パッチ投げるなりしていい?流れが分かってない。

Haddock のエスケープをしてないので \ が消えてる。( \\ にしないといけないはず。)
       mapM_ (sem -> putMVar sem ()) sems

http://hackage.haskell.org/package/base-4.12.0.0/docs/Control-Concurrent-MVar.html