haskell-jp / random #36

ドキュメントの修正であれば trac に issue 立てなくても、そのまま PR 出しちゃうのが楽だと思います。
https://github.com/ghc/ghc
一瞬、どこがダメなのかわからなかった…… ラムダ式が Java と同じ書き方に変わっちゃってますね
GitHub のリポジトリーって http://git.haskell.org/ghc.git のミラーですけど、GitHub に PR していいんですか?
そういえば GitLab に移行したとかいう話も最近聞いたような。
Gitlab 移行前はそれで大丈夫でした。PR はクローズされて本家に取り込まれる感じになります。

GitLab 移行後は試したことないので、わかんないです…。どうなんだろう…
必ずしもHaskellのお話... とはいえないですが、2018年のDhallの進化。構文もいろいろ変わりましたなー。
http://www.haskellforall.com/2019/01/dhall-year-in-review-2018-2019.html
@ms_020916 has joined the channel
これ、どうなりました?
最適化の有無でも変わったりもしません?
trace 云々別にして、結局ロジックがおかしかったので、それ以上追求しませんでした
昨年末から、GitLab側についても、Merge Requestを受け付けるようになっています。
GitLabのフローについての、簡単な説明はここにあります。
https://gitlab.haskell.org/ghc/ghc/wikis/home

なお、ドキュメントなどの簡単な修正は、wadoさんの説明のように、GitHubへのPull RequestでもOKです。
ただ、GitLabのフローに慣れる意味でも、ドキュメント修正でも、GitLabでMerge Requestを送るのも良いと思います。

ちなみに、GitLabに慣れるために、ドキュメント修正のMerge Requestを送ってみました:slightly_smiling_face:
https://gitlab.haskell.org/ghc/ghc/merge_requests/70/diffs

(あと、GitLabへの移行については、簡単にQiita関連の記事を修正しようと思っています。)
@takenobu.hsありがとうございます!記事こちらですね 読んでみます! https://qiita.com/takenobu-hs/items/a2eeb327088bb1d2fe77
haddock って stackage の GHC 8.0 までにしかないんですね(そういえばなんか聞いた気がする
@tcokygets has joined the channel
ブログ記事を書いたんですが、分からない部分があるので知ってる人がいたら教えてほしいです。 http://kakkun61.hatenablog.com/entry/2019/01/25/Haskell_%E3%81%A7_Ctrl-C_%E3%82%92%E5%88%B6%E5%BE%A1%E3%81%99%E3%82%8B%EF%BC%88Windows%EF%BC%89
OGP が展開されない……
Haskell で Ctrl-C を制御する(Windows)
という記事です
GHC本体のRTSとなんか食い合ってしまっているのかなぁ、ぐらいしか私はわからないですね。。。 :disappointed:
@satoshi.murakumo has joined the channel
:wakarimasen: ←このリアクションの意義がよくわかっていない…
何も反応が得られないよりはマシだと思ってたんですが...
どこかのスレッドのイベントハンドラが1回目を握りつぶしていて、2回目はそのスレッドがいないので、ランタイムが終了だったような。
UNIXでも同じ振る舞いです。
イベントハンドラは、interruptをスルーするように作らないといけない。
「読みました」くらいでは
この人ですらわからない問題なのかと認識することができますね...
質問していきなりわかりませんって言われたらちょっと萎縮しそうです。私だけかもしれませんが
その点に関しては、みんなカバーできてる分野に違いがあるので「他の知ってる人が答えてよ」みたいなニュアンスもあると受け取っていただければ。現に今日来た質問については私より他の人のほうが詳しかったわけですし。
萎縮は確かにありえますね。。。 :confused:
悩ましい。
会社 PC(Windows 10)だと違う結果になった。cabal ファイルをコピーしてないからそれも合わせて試してみよう。
> stack exec windows-interruption-exe
0, 1, 2, 3, 4, 5, goodbye!
windows-interruption-exe.EXE: thread killed
windows-interruption-exe.EXE: warning: too many hs_exit()s
@ringo1625 has joined the channel
haskellerあるある。
気付けば自身のUtilモジュールには`extra`及び`either`から拝借した関数で埋まっている。 
e.g maybeM , eitherM, whenJust
ビルド時の -rtsopts の有無で動作変わるみたいですね
extraやeither、いつも悩まずに依存させてしまう:female_fairy:
-threaded じゃなくて?
-threaded だと、メインネイティブスレッドは死ぬけど、プロセスは死なないという状況になると思います。
:arrow_left: extraみたいなパッケージはコピペされるためにあると思っているので変に内部で抽象化するよりはベタ書きにしてコピペしやすくしておいてほしいと思う派。
特にライブラリーを作る側としてはね…:sweat:
わかる……けどだるくて……
@shiropenko has joined the channel
@ayanamizuta has joined the channel
@kawasakitk has joined the channel
@spinylobster has joined the channel
興味深い。自分も同じことをしたかった。 https://twitter.com/mod_poppo/status/1089041290203811841
すごい雑な方法なら、ビルドの通らない Haskell コードを別途書いて、そのコードのビルドを Haskell コードから呼びだして、エラーかどうかチェックすれば(笑)
↑の翻訳をやりました。
是非 https://ghcguide.haskell.jp/ に反映して頂きたいですね!
まだまだブラッシュアップしていくので、いい感じになったら反映させていただきたいと思います:muscle:
tomitake.yokosekanemo
@tomitake.yokosekanemo has joined the channel