haskell-jp / random #60

kakkun61
2019-11-12 17:18:12 +0900
ghcup 的な PowerShell 用なにがしをざっくり作ってみた
https://github.com/kakkun61/ghcups
kakkun61
2019-11-12 20:29:49 +0900
そもそも PowerShell で GHC 使ってる人は何人いるのか
kakkun61
2019-11-13 00:48:25 +0900
cabal が ghc-pkg.ps1 を使ってくれない
λ  cabal init
cabal.exe: The program 'ghc-pkg' is required but it could not be found.

C:\Users\kazuki\temp
λ  Get-Command ghc-pkg

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
ExternalScript  ghc-pkg.ps1                                                   C:\ProgramData\ghcups\ghc-pkg.ps1
igrep
2019-11-14 08:08:51 +0900
TExpQとOverloadedStringsをうまく利用して、特定の形式に沿った文字列リテラルかを静的にチェックする
https://gist.github.com/chrisdone/809296b769ee36d352ae4f8dbe89a364
kakkun61
2019-11-14 11:08:07 +0900
ソースプラグインの出番な気もする
ByteString の文字列リテラルで 8 bit 超えてたらエラーにするの誰か書いてなかったっけ
igrep
2019-11-14 11:11:33 +0900
https://mizunashi-mana.github.io/blog/posts/2019/10/lint-bslit-by-ghc-plugin/#lint-bslit-by-ghc-plugin ね。
ぱっと見TExpQの方がお手軽な手段だし、これから IsString のインスタンスを作る場合はいいんじゃないっすか
kakkun61
2019-11-14 23:15:13 +0900
いい感じになったので試してみてほしい
kazu
2019-11-15 10:49:02 +0900
memory パッケージの Bytes は pinned だった。ByteString と変わらない。。。
kazu
2019-11-15 10:49:47 +0900
やはり、syscall とのやりとりは ByteString で、内部的には pinned じゃないShortByteString で持つのが安全かなぁ。
maoe
2019-11-15 11:39:10 +0900
ByteString を使いたくないのは fragmentation とかですか？
kazu
2019-11-15 11:45:55 +0900
意図せずに共有してしまうとリークします。そして、そのうち断片化しますね。
maoe
2019-11-15 11:55:36 +0900
なるほど。大きな ByteString の一部を thunk が保持していて GC されないみたいなのもよくあります。retainer profilerがpinned objectを検出できるようになればいいのですが今はそうなってないので、デバッグが少し難しいタイプのリークですね。
kazu
2019-11-15 11:59:35 +0900
僕は、遅延評価も ByteString も捨てる方向です。
maoe
2019-11-15 12:24:32 +0900
遅延評価はともかくByteString はブートライブラリの一つでほとんどのライブラリが前提としてるので捨てるのは難しくないですか？
kazu
2019-11-15 12:25:46 +0900
FFI には使いますよ！ 内部データとして ByteString は使わないということです。
maoe
2019-11-15 12:30:08 +0900
内部ではShortByteStringで持っておいて、APIの境界部分でByteStringにcopyしなおす感じですか？
kazu
2019-11-15 12:30:28 +0900
そうです！
kakkun61
2019-11-15 20:46:11 +0900
stack が C ドライブを圧迫してもうムリだったので他のドライブに移したメモ https://kakkun61.hatenablog.com/entry/2019/11/15/C_%E3%83%89%E3%83%A9%E3%82%A4%E3%83%96%E4%BE%9D%E5%AD%98%E3%82%92%E6%B8%9B%E3%82%89%E3%81%99
kakkun61
2019-11-15 20:47:10 +0900
75 GB ぐらい空いた
igrep
2019-11-17 13:52:11 +0900
LOCALAPPPATH環境変数を変えようとしてなぜか中途半端に変わってしまった経験を持つ身なので助かる
nmjr31
2019-11-17 16:59:30 +0900
@nmjr31 has joined the channel
takenobu.hs
2019-11-17 21:21:35 +0900
実装がHaskell製では無いのかもしれませんが、ghc-proposal の securetary をしてる Joachim さんが居る会社、DFINITY社による新言語"motoko"です。 (まだ alpha版のようです。)

https://sdk.dfinity.org/
https://dfinity.org/

発音が "motoko" と、日本語由来的な感じですが詳細は不明です:slightly_smiling_face:（まさかの、Ghost in the shell ?）
matsubara0507
2019-11-18 16:04:34 +0900
Haskell の Qiita AdC が埋まった :tada:
Las
2019-11-18 19:36:50 +0900
@Las has joined the channel
igrep
2019-11-20 08:24:34 +0900
Cross CompassでHaskellやPureScriptを書く人の募集だそうです https://www.reddit.com/r/haskell/comments/dyh4rz/job_purescript_and_haskell_tokyo_or_remote/
2019-11-20 12:28:53 +0900
@ has joined the channel
kakkun61
2019-11-20 22:25:28 +0900
Haskell Platform・Stack・Ghcup なんでいろいろあるの？というところを書きました
Cabal v2 使ったことないのでまちがってないか心配
https://kakkun61.hatenablog.com/entry/2019/11/20/GHC_%E7%92%B0%E5%A2%83%E6%A7%8B%E7%AF%89_%E6%A6%82%E8%A6%B3_%E3%81%A8_PowerShell
matsubara0507
2019-11-20 23:01:49 +0900
すごくわかりやすい！
Cabal v1 の話が最初にあってもいいのかなってとも思ったけど
kakkun61
2019-11-20 23:18:06 +0900
やった～
@matsubara0507 cabal v1 の話ってどういうの期待してますか？
matsubara0507
2019-11-20 23:27:15 +0900
Haskell Platform や stack の時点で cabal (v1)話が当たり前のように出てくるので、そもそもパッケージマネージャの cabal があってな、でもこれらはこういうのができないってのがあってもいいかなって
（僕自身は知ってるのですらすら読めたし、v2のところに書いてあったのでいいんですけど、どれを使えば？ってひとはこんがらがるのかもって少し感じた）
matsubara0507
2019-11-20 23:27:54 +0900
まぁ今のでも最後まで読めば十分分かるので強いて言えばぐらいっす :bow:
kakkun61
2019-11-20 23:45:41 +0900
確かに GHC や Cabal が何かは知っている前提でしたね
結局どれ使えばいいのかは自分で読んでて足りないなと思ったので足そうかな
kakkun61
2019-11-20 23:46:27 +0900
正直なところほとんどの部分は ghcups の前振りなんですけどね:yum:
kakkun61
2019-11-21 01:38:48 +0900
「結局どれを選べばよいのか」の節を追加した
PotassiumIodide
2019-11-21 02:03:50 +0900
@PotassiumIodide has joined the channel
igrep
2019-11-21 11:51:06 +0900
cabal-devよりcabal sandboxの方が公式機能である分一般的だった気がするんですがいかがでしょうか？
kakkun61
2019-11-21 12:14:57 +0900
cabal sandbox 忘れてました
cabal sandbox できる前の cabal-dev しかない時期しか覚えてなかった
kakkun61
2019-11-21 23:38:53 +0900
Rust で作ったライブラリーを静的リンクして Haskell（GHC）から使う例と説明書いた。
https://github.com/kakkun61/haskell-invokes-rust
池永
2019-11-21 23:50:09 +0900
@池永 has joined the channel
igrep
2019-11-22 08:25:38 +0900
急にRustとは、どういう動機なんすか
kakkun61
2019-11-22 08:55:09 +0900
え、話聞いたしちょっと触ってみるかと思って
一応2012年から2013年にかけて書いていたんですよ
kakkun61
2019-11-22 09:02:52 +0900
昔は Ruby っぽさもあったんじゃよ https://github.com/kakkun61/Rust-Exercise/blob/master/range.rs
kakkun61
2019-11-22 13:00:03 +0900
ちょっとしたアンケートなんですが、`ghc` と実行すると `stack ghc --` を実行してくれるような実行ファイルがあったときに、それは……
:one: 本来 `stack ghc --` と書かないと_けないところを_ `ghc`と書けるのだから stack を*はがして*くれている
:two: `ghc` と書いても `stack ghc --` に変換してくれるのだから stack で*くるんで*くれている
どっちでしょう？
kakkun61
2019-11-22 13:01:30 +0900
深く考えず直感で答えていただければ
kakkun61
2019-11-22 13:15:29 +0900
よけいな適用ががが
kakkun61
2019-11-22 13:16:08 +0900
4 div` 2`
kakkun61
2019-11-22 20:16:16 +0900
とりあえず僕の感覚は今の回答者に対して少数派であることが分かった
https://twitter.com/kakkun61/status/1197729627709460480
これ wrap-stack とかに名前変えるか
https://github.com/kakkun61/unveil-stack
2019-11-25 00:17:00 +0900
@ has joined the channel