haskell-jp / random #60

ghcup 的な PowerShell 用なにがしをざっくり作ってみた
https://github.com/kakkun61/ghcups
そもそも PowerShell で GHC 使ってる人は何人いるのか
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
TExpQとOverloadedStringsをうまく利用して、特定の形式に沿った文字列リテラルかを静的にチェックする
https://gist.github.com/chrisdone/809296b769ee36d352ae4f8dbe89a364
ソースプラグインの出番な気もする
ByteString の文字列リテラルで 8 bit 超えてたらエラーにするの誰か書いてなかったっけ
https://mizunashi-mana.github.io/blog/posts/2019/10/lint-bslit-by-ghc-plugin/#lint-bslit-by-ghc-plugin ね。
ぱっと見TExpQの方がお手軽な手段だし、これから IsString のインスタンスを作る場合はいいんじゃないっすか
いい感じになったので試してみてほしい
memory パッケージの Bytes は pinned だった。ByteString と変わらない。。。
やはり、syscall とのやりとりは ByteString で、内部的には pinned じゃないShortByteString で持つのが安全かなぁ。
ByteString を使いたくないのは fragmentation とかですか?
意図せずに共有してしまうとリークします。そして、そのうち断片化しますね。
なるほど。大きな ByteString の一部を thunk が保持していて GC されないみたいなのもよくあります。retainer profilerがpinned objectを検出できるようになればいいのですが今はそうなってないので、デバッグが少し難しいタイプのリークですね。
僕は、遅延評価も ByteString も捨てる方向です。
遅延評価はともかくByteString はブートライブラリの一つでほとんどのライブラリが前提としてるので捨てるのは難しくないですか?
FFI には使いますよ! 内部データとして ByteString は使わないということです。
内部ではShortByteStringで持っておいて、APIの境界部分でByteStringにcopyしなおす感じですか?
そうです!
75 GB ぐらい空いた
LOCALAPPPATH環境変数を変えようとしてなぜか中途半端に変わってしまった経験を持つ身なので助かる
@nmjr31 has joined the channel
実装がHaskell製では無いのかもしれませんが、ghc-proposal の securetary をしてる Joachim さんが居る会社、DFINITY社による新言語"motoko"です。 (まだ alpha版のようです。)

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

発音が "motoko" と、日本語由来的な感じですが詳細は不明です:slightly_smiling_face:(まさかの、Ghost in the shell ?)
Haskell の Qiita AdC が埋まった :tada:
@las has joined the channel
@amderbar has joined the channel
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
すごくわかりやすい!
Cabal v1 の話が最初にあってもいいのかなってとも思ったけど
やった~
@matsubara0507 cabal v1 の話ってどういうの期待してますか?
Haskell Platform や stack の時点で cabal (v1)話が当たり前のように出てくるので、そもそもパッケージマネージャの cabal があってな、でもこれらはこういうのができないってのがあってもいいかなって
(僕自身は知ってるのですらすら読めたし、v2のところに書いてあったのでいいんですけど、どれを使えば?ってひとはこんがらがるのかもって少し感じた)
まぁ今のでも最後まで読めば十分分かるので強いて言えばぐらいっす :bow:
確かに GHC や Cabal が何かは知っている前提でしたね
結局どれ使えばいいのかは自分で読んでて足りないなと思ったので足そうかな
正直なところほとんどの部分は ghcups の前振りなんですけどね:yum:
「結局どれを選べばよいのか」の節を追加した
@imamura.suuri has joined the channel
cabal-devよりcabal sandboxの方が公式機能である分一般的だった気がするんですがいかがでしょうか?
cabal sandbox 忘れてました
cabal sandbox できる前の cabal-dev しかない時期しか覚えてなかった
Rust で作ったライブラリーを静的リンクして Haskell(GHC)から使う例と説明書いた。
https://github.com/kakkun61/haskell-invokes-rust
@ikngtty has joined the channel
急にRustとは、どういう動機なんすか
え、話聞いたしちょっと触ってみるかと思って
一応2012年から2013年にかけて書いていたんですよ
ちょっとしたアンケートなんですが、`ghc` と実行すると `stack ghc --` を実行してくれるような実行ファイルがあったときに、それは……
:one: 本来 `stack ghc --` と書かないと_けないところを_ `ghc`と書けるのだから stack を*はがして*くれている
:two: `ghc` と書いても `stack ghc --` に変換してくれるのだから stack で*くるんで*くれている
どっちでしょう?
深く考えず直感で答えていただければ
よけいな適用ががが
とりあえず僕の感覚は今の回答者に対して少数派であることが分かった
https://twitter.com/kakkun61/status/1197729627709460480
これ wrap-stack とかに名前変えるか
https://github.com/kakkun61/unveil-stack
@yozoranotakaku has joined the channel