haskell-jp / random #68

なんか https://github.com/sdiehl/write-you-a-haskell が GitHub のトレンドに上がってたんですけど、なんでなんですかね?(latest commit が 2017/4 なのに
プロファイリングの結果でHaskellのコードを色づけしてくれるそうです。便利そう
https://github.com/Petrosz007/haskell-profile-highlight
CircleCIでlts 15のpandocがjobs 1でもout of memoryしたので色々終わったかと思いましたがGitHub actionsはメモリ7GBらしいですね(CircleCIは4GB)
Travisから移行して更にまた移行するのは面倒ですがこれが貧者の悲しみですね…
どちらにしても手間はかかりますがDocker Hubに自前でpandocをビルド済みのイメージをpushしておく、という手もありますぜ :smirk:
それも考えていたのですがltsやdependが変わるたびにpushするのも面倒かなぁと
aptで入れるやつとかは変わらないのでpushしてましたが
あーでも手元のマシンの方が速いからそちらの方が良いのですかねえ
とりあえずpandocとか重いやつだけビルドしてうまくいくか試してみてダメだったらGitHub Actions試してみます
ありがとうございます
状況わからないで言うのもアレですが、そもそもそんなに最新のpandocにこだわる必要がありますかね。
hakyllで使うならともかく、pandocでさえそれだけならaptで入るでしょうし
アプリケーションとしてのpandocではなくhakyllみたいに組み込みで使ってるんですよね
なのでltsで自動追従してしまうのです
お仕事を探してます。
実務はHaskellで2年半、あとは趣味でElmとかRustを使ったことはあります。
もし何か知ってるよーって方がいれば教えてくれると大変嬉しいです。
https://hackmd.io/@HirotoShioi/HJbkE6LbU
今週のHaskell Weeklyから。Haskell-jp Blogで以前取り上げた、文字コードの問題の回避をお助けするパッケージらしいです。
確かに毎回コピペしてるような関数がありますね... :sweat:
https://serokell.io/blog/haskell-with-utf8
@myamamura has joined the channel
今週のHaskell Weeklyから。(エディターの定義ジャンプなどで使う)タグを生成するツールを、GHCのコンパイラープラグインとして実装したそうで。他のタグ生成ツールと違ってCPPのマクロも考慮するなど、より正確に収集できるらしい
https://coot.me/posts/ghc-tags-plugin.html
今週のfumieval's Labから。masonのmasterブランチにGrisu3アルゴリズムを利用して浮動小数点数をフォーマットする関数がいくつか追加された。showやNumeric.showFFloatなどの関数に比べて20〜30倍速くなるらしい https://github.com/fumieval/mason/blob/3fe9ab0/src/Mason/Builder.hs#L408
@paulko has joined the channel
久しぶりにHaskellができました…… :sob:
型レベルプログラミングで見てみたい :smirk:
型レベル文字があったらよかったんですが、なかったのでこの形になりました……:sob:
(`x :: 'X'` と x :: "X" を区別したかった……!!)
あ、ちがう。
data Ascii = A | ... | Z | A | ... | Z
をDataKindsすればよかったんだ……うおー……
GHC-8.8 対応の stack のリリースはいつになるんでしょうかねぇ.
ボソッ:disappointed:
例の警告の件ですか... :disappointed:
リンク先の Issue クローズされてるから関係ないか
@Izawa has joined the channel
"The Glasgow Haskell Compiler a contributor's cheatsheet" https://ghc.dev/
@Kuroda has joined the channel
今週のHaskell Weeklyから。 let x = x は無限ループになっちゃうけど x <- pure x はならない、という話。Haskellに let rec を導入するか論争が勃発か
https://neilmitchell.blogspot.com/2020/03/the-pure-pattern.html
With the `let` formulation you get an infinite loop which never terminates, whereas with the `<- pure` pattern you take the previously defined `x` and add `1` to it.
なるほど、困ったら <- pure 使おと思ったけどHLintに怒られるのは嫌ですねw :sweat_smile:
(コンパイラから見て)自明な無限ループは<<loop>>と出るだけで、どこから発生しているか使い手には分からないケースもあるので、letの再帰を防ぐ仕組みは欲しいですね
:sorena: しかもランタイムエラーですしね... :disappointed:
個人的には、既存の let の互換性がなくなってしまうのはつらいので、静的解析で頑張ってほしいなぁという気持ちです。
まあ、ちゃんと移行プランを立てれば互換性は問題ないと思いますけど… MonadFailみたいになりかねない。
どっちかというと let! みたいなキーワードを追加してこっちを非recなletの意味で使わせて欲しい、みたいな気分があります。
shadowing自体良くない、みたいな発想でこうなってる感じがします。
個人的にはshadowing時々使いたくなるんですよね。特にdo文内で「現在値」が変化するようなケースは。
スーパークラスと異なるreturnとmappendに対する警告をデフォルトで有効にする提案を(しばらく前に)出したので、賛同してくれる方はぜひ :+1:を https://github.com/ghc-proposals/ghc-proposals/pull/314
パスワードジェネレータ&チェッカを作りました。指定した条件でランダム文字列を生成or検証するコマンドラインツールです。いろいろ雑ですがひらがな/カタカナにも対応しています。 https://github.com/syocy/genpass
まあparser combinatorとしてやら、ただの関数としてやら……でも使いたかったので、戦略として間違ってはないと思っています :muscle:
良さそうですね!!
:+1: しました!
GHCのソースコードなどをホスティングしている、 haskell.org のGitLabインスタンス gitlab.haskell.org が現在ダウン中だそうです。
https://mail.haskell.org/pipermail/ghc-devs/2020-March/018725.html
ホスティング版のgitlabじゃなかったんですね:open_mouth:
えぇ、それ故かよく落ちたり重くなったりします... :disappointed:
復活したそうです :relieved:
遅延評価ってそこまでデバッグのしやすさに影響を与えているのでしょうか…?
そもそも自分の経験が少なくてデバッグしにくい状況になったことがないだけかもしれませんが、、、
うーん、ぱっと思い出せるところですと、デバッガーでステップ実行したとき、あっちこっちの関数に飛んでどこ実行してるのかわかりづらい、なんてことはありましたね。
遅延評価が原因のやつは結果が違ってるみたいな単純なバグではなく大概パフォーマンス問題として表出するので.
「何か問題があってそれが遅延評価のせいでデバッグしにくい」という状況より,
「遅延評価のせいでデバッグしにくい問題になり易い」というカンジですかね.profile取っても追い難いし.
個人的には、すごく trace がしにくい経験を何度もしたことがあります
詳細気になりますね。それは純粋な関数だから、という話ではないんですよね?