haskell-jp / random #34

これは機械的導出じゃないから機械的に保障は出来無いんだけど、パッケージ作成者がしっかり SemVar のルールを守ってバージョン付けしてくれてる(という仮定)なら、 allow-newer 無しでも勝手に上のバージョンを選んでも良いと思うのだけれど
allow-newerはとりあえず上のバージョンみたいなのだったと思うので、 rely-on-version みたいなフラグを作ってさ、 それがtrueの時は同一メジャーバージョンなら上のバージョンを代用(って言葉が正しいのかは不明だけど)してインストールしても みたいな?
依存が == A.B.* みたいになってれば SemVar ルール上インターフェース互換なバージョンのうちは許されるので,
その案の必要性がわからないのですが何か違うものを意図してるんでしょうか?
あれ?んじゃ私が知らないだけなのかな? いや、ライブラリをインストールする時に、 base-4.8 とかって依存が書かれてて 結局 cabal getして依存のところを書きかえるか、 allow-newerしないとインストール出来なかった気がしたので、その状態でもallow-newerする事なく、インストールしたいなぁと。
あ、いや私の勘違いだった ようです お騒せしました:broken_heart:
allow-newerのザ・ビースト感
この手の技はリミッター解除、トランザム、野生解放など作品によって呼び方がまちまちなので、どう言えばいいかちょっと迷いました
30代前後には界王拳が一番しっくり来る気がします!
出遅れたAdvent Calendarのネタです。ご査収ください。
https://haskell.jp/blog/posts/2018/super-precure-monad.html
@murakami has joined the channel
今週のHaskell Weekly入りおめでとうございます! :tada:
http://haskell.1045720.n5.nabble.com/Happy-Haskell-Programming-for-GHC-8-x-td5888460.html
http://fumieval.hatenablog.com/entry/2018/12/27/213853 Haskellに関係のない話も半分くらい混じっていますが今年を振り返る記事を書きました。みなさんもHaskell-jpの一年を振り返ってみませんか
これについて思った事があるので少々、パッケージ間のシグネチャの同一性で解決できないかな?と、 あるパッケージには、A, B, C, Dのバージョンがあるとして、 どうにかして Aの全てのシグネチャはBに含まれる、Bの全てのシグネチャはCに含まれる、けど、DはCの全てのシグネチャを含まない みたいなとき Aが要求されるなら 勝手にCをインストールしても安全だよなぁ と。 ただ、TemplateHaskell とかでビルド状況に依存するような場合は全てのシグネチャを追うのが不可能だよなぁ。。。とも この辺どうにかならないかなぁ
今年の年末の大掃除のメインは「自分のパッケージに-Wall -Wcompat -Werrorをつけてビルドを通す」になりそうです
いいっすねw
compact いれないと気づかない問題
-Weverything にして 要らないのを、-WnoXXXX にするって方が好きかな?
-Wcompat ?
-Wcompat は細かい警告を有効にするって認識です-Wall とかと併せて使うようかなと。
:point_up: は https://haskell-jp.slack.com/archives/C4M4TT8JJ/p1546074734041400 に対する突っ込みでした :sweat_smile:
lol
あっという間に大晦日でした。それでは皆様、良いお年を:bamboo:
Thanks Haskell and Happy New Haskell:haskell:
@863 has joined the channel
Happy Haskell New Year!
import Control.Arrow ((>>>))
foo & bar >>> baz

ってやりたいんだけど、&と>>>がどっちもinfix[lr] 1なのでできない。
なんかいい感じのイディオムな気がするので、なんだか残念
foo & bar & baz

はだめですか?
@madai has joined the channel
@kita127 has joined the channel
Stackage, 依存パッケージが登録されてない場合は暗黙に登録してたんだ。。。多分ダメなんだろうと思って追加するのを控えてた。。。 :cold_sweat:
https://github.com/commercialhaskell/stackage/pull/4203/files
ltsメジャーバージョンが上がったりで依存パッケージがビルドできなくなるとstackage落ちするので,
どっちにしろ依存パッケージのメンテナには少なからず「はたらきかける」必要はでてきたりしますけどね.
そそそそそれです!!
ありがとうございます
@ has joined the channel
どうやって入力するのかが気になっています。
ここに各種エディタ向けのがありますね!
https://wiki.haskell.org/Unicode-symbols#Input_methods
自分の場合vimの<C-v>も<C-k>もほかのマッピングで潰しちゃってるのが悩ましい。。。 :sob:
見た目変えるだけならリガチャ(合字)付きのフォント使っていい感じにできるやつとかもありますよ。 https://github.com/tonsky/FiraCode
同じく見た目変えるだけならVimだとconcealで!
(新しく入りそうなtext propertyっていう機能でもできそう?)
@ has joined the channel
@fumi has joined the channel
@shugo has joined the channel
openssl 1.1.0jが降ってきた影響でstackのコンパイル済みライブラリが壊れてしまいました
どのライブラリが壊れているのかどれを消せば良いのか徴するのが面倒なのでコンパイル済みのやつ全部消すことにしました
そんなに再ビルドには時間かからないしね
入力は大学の時論理学のレポート書きまくった影響で基本的な文字は自分のnlodかな配列に入っていて今でもGoogle日本語入力/mozcで入力できるようになってますね
https://github.com/ncaq/nlod/blob/300209d7039935e2cff084006ca0c4de16c46a75/src/Main.hs#L43
後インターネットに読み方から変換できる辞書は沢山転がってますね
http://anta2.hatenablog.com/entry/2013/09/26/213621
こういう時我々CJKの民は既存のかな漢字変換に載せられるから便利でもあり,エディタが提供する機能が要らなくてキレそうになったりするのでどっちが良いかは不明
たとえATOKがLinux向けにサポートを再開したとしても今のATOKではローマ字テーブル編集機能が貧弱なので移る気にはなれないんですよねえ
こういう再ビルド時にいつも思うけどpandocだけが異常にビルド時間かかる
パッケージをシンタックスハイライト部分ぐらいしか分けてないから並列ビルドできないのも理由の1つ
GHCの並列ビルド機能が開発中だからそれがうまく行けば16倍速ぐらいにはなってくれるのかな
pandoc-reader-markdown, pandoc-reader-htmlみたいにパッケージ分けていけば今でも並列ビルド効きそうではありますね
うまく分割できるかはよくわかりませんが…
そうそう、vimといえばvim2hsがまさにconcealを使ってやってくれるんですが、日本語環境だとカーソルがずれちゃうことがあってやむなく無効にしてるんですよね。。。
https://qiita.com/laiso/items/22139ebc3f1d94a0ea23
壊れたのは十中八九HsOpenSSLなんでしょうけども、孫依存してるパッケージとかもリビルドしないといけないのかな。。。 :thinking_face: