haskell-jp / atcoder-lang-updates #5

ここまでの内容を issue にしました。補足等あればコメント等で教えてください。
https://github.com/haskell-jp/atcoder-haskell-resources/issues/9
massiv 自体は入っていて、version 0.4.2.0 -> 0.5.1.0 とmajor updateだったのでmoduleが削除されています。
ああ、そういうことですか。ありがとうございます。
それはだいぶ厳しいかもしれません…。deployが来週なので。
https://github.com/haskell-jp/atcoder-haskell-resources/issues/9#issuecomment-607607128
追加されるかわかりませんが、一応ドキュメントには反映させておきますね!
「コンパイラオプション/実行時オプション/ライブラリ」の一覧が出てますね。
https://atcoder.jp/contests/language-test-202001

言語アップデートシートの最終版はこれです。
https://docs.google.com/spreadsheets/d/1PmsqufkF3wjKN6g1L0STS80yP4a6u-VdGiEv5uOHe0M/edit#gid=1059691052
追加されるかわかりませんが、regex-tdfa の件をシートの右側のコメントに追加しておきました。
Judge System Update Test Contest 202004


> コンテスト時間: 2020-04-05(日) 21:00 ~ 2020-04-05(日) 22:00 (60分)
> このコンテストは、ジャッジシステムのアップデートに伴うテストコンテストです。
> 参加対象: All Rated対象: - ペナルティ: なし
時間ある方はよろしくお願いします。
シンタックスハイライトが壊れていますね。`'` がだめなのかな。
https://atcoder.jp/contests/judge-update-202004/submissions/11589259
AtCoderの提出済みコードのシンタックスハイライトが壊れているのは以前からです。ちなみにHaskellに限らずC++等のメジャー言語でもよく見ると不正確な色付けがされているはずです。詳しくはこのスレッドを参照→ https://twitter.com/mod_poppo/status/1112804424865337345
なるほど、対応待ちなんですね。情報ありがとうございます。
次はminor versioningは完全にcabalに任せたほうがいいかもですね・・・。
cabal に任せるって具体的にはどういう感じでしょう?
cabal install --lib vector bytestring とするか、
cabal install --lib vector-0.12 bytestring-0.10 とするか、みたいなことを指しています。
後者にする場合GHCのバージョンを固定できる方法でしたほうがいいかも、とも。
バージョンを明記しない1つめの方法だと

index-state を指定しないと、どのバージョンがインストールされるかわからない。
index-state を指定したとしても、インストールするパッケージが増えるにつれ、制約が満たせなくなる可能性が高くなり、その場合は手動でパッケージのバージョンを指定する必要がある。
という問題がありませんか?
2つ目の方式は今回のインストール方法と同じですね。
https://github.com/haskell-jp/atcoder-haskell-resources/blob/master/spec.md#%E7%92%B0%E5%A2%83%E6%A7%8B%E7%AF%89%E6%89%8B%E9%A0%86

$ cabal install --lib --package-env /opt/.cabal/global.env \
    QuickCheck-2.13.2 \
    array-0.5.4.0 \
    attoparsec-0.13.2.4 \
...
GHCのバージョンを固定できる方法
cabal install -w ghc-8.8.3 のように -w オプションを指定するということですか?
あ、ちょっと違いましたね。
vector-0.12.1.2 と完全にバージョンを指定するのではなく、`vector-0.12` で止めておくってことですか。
基本的には大丈夫だと思いますが、個人的には全部指定しておいた方が安全だと思っています。

例えば、具体的な例でいうと vector パッケージ 0.12.1.00.12.1.1 はミスで breaking change になってしまい、
この影響で rio など mkType を利用しているパッケージがビルドできなくなったりしました。(`vector ^>=0.12` という感じでバージョン指定している場合です)
すぐに 0.12.1.2 が出たので、そこまで気にする話ではないかもしれませんが、環境構築手順としてはできるだけ冪等性を保つようにした方が良いと思います。(そのため、今回の ghcup の件は次回の手順では明示的にバージョンを指定する方針に変更した方が良さそうですね)

0.12.1.1 breaking change w.r.t. 0.12.0.3 #287
https://github.com/haskell/vector/issues/287
うーん・・・。ただ、こんだけアップデートの完了に時間がかかると、bugfixが出ても全く更新されないって言うのはやっぱり痛いと思ったんですよね。何度もインストール自体をやり直すやり方をとっているようだったから、むしろアップデートが完了した時点でインストールしたライブラリのバージョンをAtCoder側に公開してほしいって気分になってしまって・・・。
はい、同じ気持ちです。時間かかるのは良いのですが、情報が一方通行すぎてつらいですね・・・。
Stackageから最新LTSに収載のパッケージのバージョンだけ下ろしてきて、cabalでインストールしてもらって、バージョンを公開してもらう、とか、可能か不可能かわからないけど、妄想してしまいます。
lts-15 など、スナップショットの最新のバージョン制約は取得できるのですが、stackage の lts を利用する時点で最新のパッケージではなくなるので、残念ながら期待する結果にはならない気がします。
https://www.stackage.org/lts-15/cabal.config
バージョンを明示しても、freezeしてからもかなり長い間待たされるわけなので、最新ではないんですよね…さすがにnightly使うのは怖いか…あー…
あと、stackage にあがっていないパッケージについては extra-deps で追加する必要があるので、それはバージョン固定になりますね。
確かに。でも今回、そんなパッケージ追加してましたっけ?
今回の話だと repa とか該当しますね。
https://www.stackage.org/package/repa
ちょっと話がズレますが、あの repa なのに、開発が結構長い間止まってるんですね…
最新性と言うよりはbugfixが入ってる事を保証したいだけという気もしてきました
@ has joined the channel
言語アップデートは無事に完了した感じですね:clap:
みなさんご協力ありがとうございました!

特に @mod_poppo さんと @gksato さんの環境構築時の追試、ghcup への PR、パッケージ選定、AtCoder 側の進捗状況の把握など、1人では見落としていた部分も多々あり、本当に助かりました。ありがとうございます。

今後このチャンネルは
• 現状の AtCoder Haskell 環境についての質問
• 次回の言語アップデートに含めたいパッケージやコンパイルオプション等
• 次回の言語アップデート時の環境構築方法
について提案・議論するためのチャンネルにしたいと思うのですが、問題無いでしょうか?

AtCoder の問題の解き方等についての質問は beginnersquestions を利用しましょう!
@Nagatatz has joined the channel
@niszet has joined the channel
3日前くらいにAtCoderからこんな話がありました。AtCoder STL (仮称)の翻訳を各言語コミュニティに作って欲しいそうです。
https://youtu.be/B-r_ACGV3yc?t=1560
動画時間26:00から47:30まで
このチャンネルを久しぶりに見て「AtCoderのシンタックスハイライトの件は1年半も直ってないんだなあ」という気持ちになったので自前で直すためのUserScriptをでっち上げました: https://qiita.com/mod_poppo/items/af11f07169fa9bdab844
リリースされたようです。(rust-jpの方ではリポジトリだけ作って議論してます)
https://atcoder.jp/posts/517?lang=ja
haskell用のrepositoryって今作成されてないですよね?
ないかな?
非公式でも名前に “AtCoder” って入れてもいいんだろうか
https://github.com/haskell-jp/atcoder-haskell-resources 再利用すればいいんじゃないっすか
あー…んー…? 再利用、と言うのは、ACLのHaskell翻訳がAtCoderとHaskellに関係するプロジェクトだから、同じくAtCoderとHaskellに関係するプロジェクトであるAtCoder Language UpdateにおけるHaskell関係の要望集積のためのプロジェクトである atcoder-haskell-resources に…parentless branchを新しく作って用いる、と言うことですか?
(一番最後の部分が一番自信がない)
個人的にはリポジトリー分けたいかなあ
まあちょっと違うか。失礼。
いえいえ
情報を共有しておくと"AtCoder Library" (ACL)のリポジトリはこれ
https://github.com/atcoder/ac-library
ドキュメントはこれ
https://atcoder.github.io/ac-library/document_ja
テスト用問題集と"ACL Contest"の第一回目(9/20に開催された)は
https://atcoder.jp/contests/practice2
https://atcoder.jp/contests/acl1
コードの規模はこんな感じです
$ tokei ~/src/github.com/atcoder/ac-library/atcoder # 本家
===============================================================================
 Language            Files        Lines         Code     Comments       Blanks
===============================================================================
 C++ Header             17         2141         1762          119          260
===============================================================================
 Total                  17         2141         1762          119          260
===============================================================================
$ tokei ~/src/github.com/rust-lang-ja/ac-library-rs/src # Rustの
===============================================================================
 Language            Files        Lines         Code     Comments       Blanks
===============================================================================
 Rust                   18         4207         3622          151          434
 |- Markdown             8           83            0           74            9
 (Total)                           4290         3622          225          443
===============================================================================
 Total                  18         4290         3622          225          443
===============================================================================
@ has joined the channel