haskell-jp / atcoder-lang-updates #6

@TH has joined the channel
@Kouji Okamoto has joined the channel
@cutsea110 has joined the channel
@Jaeyoung Lee has joined the channel
@a5ob7r has joined the channel
@hiratara has joined the channel
@yFkhr has joined the channel
@toyboot4e has joined the channel
前回の言語アップデートの時のやつはこの辺ですかね https://atcoder.jp/contests/language-test-202001
bitReverse (GHC 8.10), GHC2021 (GHC 9.2), vector-0.13.0.0でunboxed vectorのderivingが楽になる, random-1.2でいろいろ追加された?などが大きいですかね(最近競プロやってないのでよくわかってない)
昨日見たらhaskell-platformになってたしどうにかしないといけないですね。
GHCup recommended(9.2.5 as of Jan 20) + 前回提案パッケージの最新版,を適当に仮想環境上で組んで通ることを確認したのち転記,でいいんでしょうか.atcoder-haskell-resources に再度まとめるとかしようとすると例の repo に write access のある人間が関わる必要が出てくる….
ちなみに私が勝手にやろうとすると exceptions 関係のパッケージ + regex (前回提案されてたけど間に合わなかった)を勝手に追加してあとは最新に更新するだけ,になります.
議論があればしたいので反応ください〜 (特にatcoder library の adaptionとか入ってないので関連する lib の話などあれば)
こんにちは。ライブラリだと線形型を使ってみたいのでlinear-baseをいれたいです
そこら辺全然触ってないのですが,linear-baseだけあれば競プロ用途だと十分でしょうか?
正直なところ自分もあんまり触れてないのでよくわかってないです。配列がboxedなVectorなので不十分な気はするんですがどうすればいいかの知見は持ってないです
実装見てきた感じ, ST 型の操作を runRW# で走らせた後に Unsafe.Linear.toLinear で linear であることを assert しているだけのように見えるので,一般の vector に対する操作を実装するのは難しくはなさそうですが…
とりあえず linear-base に入ってるものは(不十分なりに)かなり重要そうなので,含める方向で検討した方がよさそうですね.
すでに便利なものがあるのであれば使いたいですが,自前で対応できそうならそれでいいのかなと。
コンテナ系は一通りそろっているのでlinear-baseだけでも十分いろんなことはできると思います
そういえば, ghc-9.4 ってもう 9.4.4 になってますけど, recommended になってないということは考えない方がいいのでしょうか.
... Replies ...
bitvec, 面白そうなパッケージですね https://hackage.haskell.org/package/bitvec
現在の提案 (2023/01/22):
• GHC: 9.4.4
• 提案追加パッケージ
regex-tdfa
exception, safe-exception (<@UL1HFJATE>)
linear-base (<@UL5PAB0F9>)
bitvec (<@UL1HFJATE>)
• 提案削除パッケージ
repa
で今日のもくもく会で仮想環境ビルドを試してみたいと思います.
... Replies ...
他にも欲しいパッケージ等あればどんどんください〜
忘れる前にメモ代わりとしてもここに記します. vector-stream は絶対欲しいですね. vector の dependency である vector-stream は絶対にインストールはされますし, 前回のやり方を踏襲するなら(オフライン性を担保しようと思ったらそうするのが一番楽なので) cabal install --lib なんだから hidden 扱いにはならないかもしれませんが,万一 Stream に追加の関数が足せないと絶対困るはず.
未テストですが,今想定しているインストール手順は

# make sure you login from the user runner!
$ sudo apt-get update
$ sudo apt-get install -y build-essential curl libffi-dev libffi8ubuntu1 libgmp-dev libgmp10 libncurses-dev libncurses5 libtinfo5 llvm-13
$ curl --proto '=https' --tlsv1.2 -sSf  | BOOTSTRAP_HASKELL_NONINTERACTIVE=1 BOOTSTRAP_HASKELL_GHC_VERSION=9.4 BOOTSTRAP_HASKELL_CABAL_VERSION=latest BOOTSTRAP_HASKELL_INSTALL_NO_STACK=1 sh
$ source ~/.ghcup/env
$ cabal install --lib <packages>

あたりです.ユーザー名が runner 固定なので user-local install にしてあります.コンパイル手順は:

$ source ~/.ghcup/env
$ ghc -fllvm -O2 Main.hs

ぐらいを考えています (未テストだからうまくいくかは完全に未知数ですが,透明性は高ければ高いだけいいと思いまして).今は の話で`http-client` と Cabal-syntax のライブラリAPI docを読んでます.
@まど has joined the channel
インストールコマンド以外の部分はスプレッドシートを埋めました。
exceptionとsafe-exceptionは末尾にsをつけて,exceptionsとsafe-exceptionsに修正しました。
ライセンスは基本的にBSD-3-Clauseで,以下が例外でした

integer-logarithms: MIT
lens: BSD-2-Clause
linear-base: MIT
mono-traversable: MIT
mutable-containers: MIT
parsec: BSD-2-Clause
safe-exceptions: MIT
text: BSD-2-Clause
取り敢えず cabal が走るところまでしかチェックしていないのですが今日中に追記しようと思ってインストール手順等を書き込んだ瞬間にfreezeされましたね…
ghc-bignum も足しとかなきゃとか考えてたんですが…。
-pgmlo opt-13 -pgmlc llc-13 つけないとビルド通らないかも
あ、そっか、オプションつけないghciしか通してない!! 自前のdockerでも確認してみますね
GHCのbindistはconfigure時に opt-<バージョン番号> , llc-<バージョン番号> のようなコマンド名も探索して記録するので、インストール時にすでにllvm-13が入っていれば大丈夫だと思います。
あ、docker上で、`ghc -fllvm -O2 Test.hs` が main=return() に対して通るのは確認できました。
がんばりました。直接installしていない物も含む、全transitive dependencyのライセンスのリスト: 
parallel が202001から提案パッケージに含まれたままになっていますが,`--with-rtsopts -threaded` したほうがいいのでしょうか?
... Replies ...
こちらに残すのを忘れていました:
追加提案
1. ghc-bignum を追加で明示的に可視にする
2. bitveclibgmp フラグをEnabledにする
他に提案があればよろしくお願いします!
現状のcabal-install 3.8.1.0において, cabal install --lib が GHC-bundled library[1]の*真*部分集合として default global packages ( cabal install --lib する前に最初から可視になっているパッケージ) のリスト[2] を持ってるので, cabal-plan license-report [3] (このSlackの で紹介いただいたものです) を使うにも面倒だな,という感じになっています.将来のlanguage update のことも考えると,こういうツールが使えた方が後々同じ作業をするときにも楽そうなので,このツールを使えるようにどうにかした方がいい気がします.そのために考えられるやり方を以下に列挙してみましたが,ご意見をいただきたいです.

1. Cabal package を一個作っといて cabal v2-build --only-dependencies pkg:exe するまでをインストールとし,コンパイル時は cabal v2-build --offline pkg:exe して,実行時は cabal v2-run する
2. Cabal package を一個作っといて cabal v2-build --only-dependencies pkg:exe するまでをインストールとし,コンパイル時は cabal v2-install --offline pkg:exe して,実行時は $ Main する
3. cabal-env [4]を使う
4. global packages をスプレッドシートの dependencies に加えておく
5. cabal-plan license-report の時だけ dependencies に加えて license-report を作成する.そうすると cabal-plan license-report は直接の依存性と間接依存性を区別するため,依存するパッケージが増えたように見えてしまうので,その理由をスプレッドシートの付記に加える.
ところで,default global packages は色々問題を引き起こしてきたようで, cabal-installのmasterでは cabal install --lib から “global packages”の概念は消えるようです[5].加えて,GHC-bundled package の中で,GHCと完全に結合していて別バージョンをインストールできないパッケージは9つしかなく[6],それ以外のGHC-bundled package は global packages の概念がない環境であればアップデートができるようです.

これらの事情から,取るべき手段として1--3,特に1か2を検討しています.ですがあんまりしっかり考えられていない気がするので,意見をいただけたら非常に助かります.

ちなみに,元々「GHC-bundled libraryは全露出するべきだ」という目的で default global packages ができたっぽいので, default global packages が GHC-bundled library の*真*部分集合になってしまったのは,多分メンテナンス忘れによる偶然だと私は無根拠に推測しています.

参考文献:
1. GHC-bundled library: https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries/version-history
2. default global packages の list: https://hackage.haskell.org/package/cabal-install-3.8.1.0/docs/src/Distribution.Client.CmdInstall.html#globalPackages
3. cabal-plan の Hackage page: https://hackage.haskell.org/package/cabal-plan
4. cabal-env: https://github.com/phadej/cabal-env, development moved to https://github.com/phadej/cabal-extras
5. cabal install --lib から “global packages” の概念を消すPR: https://github.com/haskell/cabal/pull/8607
6. アップデートできないパッケージ群 in cabal-install source: https://github.com/haskell/cabal/blob/42a03ff0892101a0a967d6fbb08fe4f339b9f6da/cabal-install/src/Distribution/Client/Dependency.hs#L409
上の発言に従ったインストール方法を作成してみました.License-report と exposed-modules の全importからなるソースをつけています:

https://gist.github.com/gksato/6f8cf9767a96dd7650cbba88f4cc102c

ビルドは
$ source ~/.ghcup/env && cd ~/submission && cabal v2-install --offline --install-method=copy --installdir=~

実行は ./main です
ちなみにdependencyをnewline-separated list にするとlicense-reportとチェック用のソースファイルが半自動生成できるようにしたので,今からでもパッケージの追加とかは簡単にできます! ご意見お待ちしてます〜
https://github.com/gksato/haskell-atcoder-server-gen
あとこっちのやり方でインストールすることについてのご意見などもあれば。
上で提示した実行方法ですが,cwdが /judge$HOME/home/runner なので見直しが要るかもですね……
... Replies ...
第一弾 Language Test が公開されています!

https://atcoder.jp/contests/language-test-202301

多分コードテストはまだ通らないですね。一度投げると無限に待たされる。
自前のインポートテストコードをちょっと手を加えた上で問題への提出として投げてみましたが、 ghc-bignum の不在はもちろんのこと、`mtl` と transformers でもエラーが起きています。AtCoder側の cabal dependency solverはbroken ListTが消された最新版に依存解決しているのに、手元の擬似環境のソルバは最新版に依存解決しなかったのでアレなことになってますね。

https://atcoder.jp/contests/language-test-202301/submissions/39958271

とりあえず、嫌なトラブルを避けるために、次を追加提案したいと思います:

• バージョンを ( ^>= で) 固定する。モナド変換子系は最新版に
list-t パッケージを追加
(それはそれとして、Haskell ってプログラミングパターンがライブラリになってることが多くて、追加しようと思うと無限に追加できそうで迷っちゃいますね…)
2nd freezeが実行されました! 
• 最終freezeは4/9で、ここまでには追加したいライブラリを全て揃えておく必要があります。
• 今回の変更点は次のとおりです:
cabal v2-install --lib の代わりに Cabal project + package を使用
◦ パッケージバージョンの固定 (`^>=`)
list-t, ghc-bignum の追加
◦ ライブラリを -fllvm でコンパイル
◦ いくつかのライブラリへのフラグ指定
• バージョン指定を意図的に ^>= , マイナーバージョン非固定でやっていますが、最終的には次のコードでコードテストを投げることによりfreezeファイルを取ってくれば、手元環境での再現可能性は担保できるかなという気分でいます。というより、このfreezeファイルがないとtransitive dependencyまで込みの再現可能性は保証できないので、これを投げた上で、結果をどっかのrepoとまとめ記事とかに公開する必要があるかな、と思っています。
import 

main :: IO ()
main = putStr =<< readFile "/judge/submission/cabal.project.freeze"
お知らせ: 最終freezeが 4/9(日)であり,*4/8(土)23:59:59以降のスプレッドシートへのライブラリ追加は反映されない可能性*があります.書き込む前に仮想環境でテストを通す必要があったり,「追加して良いか?」の議論可能性を最低限保証した方が良かったりするので,*追加したいパッケージは遅くとも4/7(金)までにはこちらでご提案*いただけると助かります.ちなみに,私が作ったDocker仮想環境は https://github.com/gksato/haskell-atcoder-server-gen で管理していますが,これを用いて私が最終テストを行うのを 4/8(土)15:00- からにしたいと思っています.
皆様には,4/7(金)までの時点で新たにライブラリの追加提案があった場合に備えて,このチャンネルを時々ご一読いただき,必要があればご意見をいただけると大変助かります.

• スプレッドシートへのパッケージ追加: 4/8(土) 23:59:59まで.
• このSlackでのパッケージ追加提案: 4/7(金) まで. 早ければ早いほど嬉しい!