haskell-jp / random #49

これで私はエコシステムの救世主だ…
念の為、早まらず聞いておいてよかったです:slightly_smiling_face: Pull Req後が良さそうですね。
(fumiさんのタイミングで、Redditに貼ってもらうのが、よりbetterですね。:haskell:)
OKです、PRの送信が終わったら私の手で投稿します :+1:
Redditに貼ってないのに、Stephen Diehl さんが、もう見つけてはりますね:+1::slightly_smiling_face:
https://github.com/haskell-jp/blog/pull/160 でも思わず言及してしまいましたので、修正します。 :bow:
やっと書けました... GWにぼっちでモチベーション上げるのはやっぱきついですね...
https://haskell.jp/blog/posts/2019/stack-ghc8.8.html
他所では「ここはサバンナですね」という意味でも使われているようです
@atsushi.main has joined the channel
今のGHCはgdbでスタックトレースが取れるんですね。。。本当に良い時代になったものです。。。 / "dwarf · Wiki · Glasgow Haskell Compiler / GHC · GitLab" https://gitlab.haskell.org/ghc/ghc/wikis/dwarf
私が以前ドキュメント読んだときはまだexperimentalな機能だよと言われてましたけど、今や「While the infrastructure should be perfectly stable and safe to use」なんですね。すばらしい。
今度 https://www.gdbgui.com/ でも使って試してみようかな。
続けて書きました。ご査収ください hask(_ _)eller
@e1b18041 has joined the channel
https://twitter.com/fashionsnap/status/1123066947074179073?s=19 HaskellロゴとHaskell-jpロゴの色遣いに近い!
お、やりたい。
やります!:blush:
@qryxip has joined the channel
https://summerofcode.withgoogle.com/organizations/5556388114202624
GSoC 2019のHaskellのプロジェクトが決まったそうです。
https://summerofcode.withgoogle.com/projects/#5991057626497024
A language server for Dhall

こういうパターンもあるのか
extensibleの核心となる型レベルリスト操作をmembershipパッケージに切り出す作業を進めています。テスター募集中 
人生に迷っています。なにとぞコメントと投票をよろしくお願いいたします。
@takumi.shiratori has joined the channel
最近stackからcabalへ移行しようと色々試してるんだけど、それに関してFAQ及び参考となるリポジトリを公開してくれると嬉しいです。

cabalに移行する利点とは?

cabalを使用する際には、開発環境を整えるためにnixを使ったほうがいいのか、もしその場合にはどのように設定すればいいのでしょうか?
GHCのバージョンを指定してビルド方法がNix以外に見当たらなかった・上手くいかなかった。
色々調べたけど、Nixを使った方法を紹介する記事が一番多かった。
参考にした記事
https://maybevoid.com/posts/2019-01-27-getting-started-haskell-nix.html
https://www.reddit.com/r/haskell/comments/8xh4dk/installing_and_running_multiple_ghc_versions/

stackにあるコマンドをcabalに置き換えると・・・?
stack ide targets: List all available stack targets
stack haddock --open <library name>: Enable opening the local Haddock documentation in the browser
stack ghci <library name>:lib <library name>:test:<library name>-test (ライブラリとテストを同時に読み込む)

cabalファイルに記載されていないパッケージをビルドする方法はありますか?
pretty-printerなどの、cabalファイルには記載されていないがビルドしたいパッケージがある場合、それをcabalにてビルドする方法があるのでしょうか。

.gitignoreに追加するべきファイル/ディレクトリは?

ghcidを実行する際のコマンドは?
現在は`ghcid --command "cabal new-repl"`で実行しているが、他に最適化されたコマンドがあるのであれば是非知りたい。
スレッド違いで恐縮ですが、取り急ぎ...
GHCのバージョンを指定してビルド方法がNix以外に見当たらなかった・上手くいかなかった。
「参考にした記事」でも触れているように、 -w ghc-8.6.5 みたいなオプションを cabal new-build に渡せばとりあえずnix関係なく出来たかと思います。
(`--with-ghc=ghc8.6.5` でもできたはずだし私もそっちなら使ったことがある)
それ試したんですけど、僕のマシンではビルドできませんでした。一度aptを使ってghc-8.6.5をインストールしたけど、それでも動かなかったので諦めました。
[email protected]  ~/haskell/coding/my-app  cabal new-build -w ghc-8.6.5
cabal: Cannot find the program 'ghc'. User-specified path 'ghc-8.6.5' does not
refer to an executable and the program is not on the system path.
which ghc-8.6.5 した結果はどうでした?
[email protected]  ~/haskell/coding/my-app  sudo apt install ghc-8.6.5
Reading package lists... Done
Building dependency tree
Reading state information... Done
ghc-8.6.5 is already the newest version (8.6.5-9~18.04).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[email protected]  ~/haskell/coding/my-app  which ghc-8.6.5
ghc-8.6.5 not found
普通に PATH にさえ登録すればいけそうに見えますね。 :thinking_face:
PATHの通し方がわからないです。。わかったとしても、この記述と一致しないのが気になります。
Using either of the above methods, we will find our GHC versions on the PATH.
https://qfpl.io/posts/multiple-ghcs/
えっ、私が言っていることそのとおりだと思うのですが...
どちらの方法であれ、 PATH に登録しているパスからGHCを見つけるという意味でしょうし。
PATHの通し方については広く知られているので、「PATH 環境変数 ubuntu」などで検索してみてください。
そもそも ghc-8.6.5 がどのパスにあるかわからない、という場合は dpkg -L ghc-8.6.5 と実行すれば、 apt install ghc-8.6.5 がインストールしたファイルの一覧が見えるはずなので、そこから探してください。
通りました!ありがとうー。
cabalとstackとの対応関係は、Bigmoonのブログが詳しいのでおすすめです https://haskell.e-bigmoon.com/stack/tips/cabal.html
Asteriusの作者が作った。AsteriusのFFIにも知見が生かされるのだろうか。
https://www.tweag.io/posts/2019-05-09-inline-js.html
IO モナドに制限した方がよかった
When も関数かとおもたら違った
@fumieval 読ませてもらいます。ありがとうー。
確かにProxyのモナドインスタンスだと _ >>= _ = Proxy だから戻り値Proxyだ
私がextensibleを使っているプロジェクトの中で最も変な使い方をしているであろう、typesafe-precureのsuper-precure-monadブランチで試しました。
AssociateがLookupに変わって型引数の順番が変わったこと以外に特にハマるところはありませんでした!
https://github.com/igrep/typesafe-precure/commit/eb000035176d80057f6ef402af55b83f9cb78fab
かなしい :cry: https://coinpost.jp/?p=83471
例えば、同ブロックチェーンのプライバシー部分はプログラミング言語 Haskellで書かれていたが、それをJavaシステムに置き換えることで、よりビジネスでの利用を容易にしたとしている。
これは、Haskellの問題というよりも、integer-gmp とかの問題な気がする。 だってHaskellの遺産を全部捨ててJavaに切り替えるって話でしょ? 流石に昨日の今日でHaskell使えねーぽぃー ってしたわけじゃなしそれなりにHaskellエンジニアも育ってるとは想像できるわけで、、、敢えてJavaにしなきゃいけない理由がくらいしかなぁ。。。 後何でScalaとかじゃないのかな?とかも不思議 そっちの言語の方が移植性(するかは不明だが)も高まると個人的に思う
普通にあるあるな、人が集まらなかった系なのでは。Haskellわかる人がやめちゃったとか。
そんな不人気な言語なのかなぁ。悲しみ。 大学で使ってましたとかは普通にありそうだと思うんだけどなあ…
私も前職でほぼそういう理由(メンバーの教育に失敗した)で諦めましたし、(おそらくLINE社の) https://twitter.com/dankogai/status/1068376173955039232 という事例もありましたし、やっぱりまだまだなんだと思いますよ... :disappointed_relieved:
John HughesにQuickCheckの極意を教わりました。