TODO

[kmyk]

• [x] g++ / clang++ 両方対応させる
  • これは必須
• [x] キャッシュさせたい
  • 全部を毎回 verify してると INF 時間かかってつらいので
  • @beet-aizu が https://github.com/beet-aizu/library でやってるやつ
• [x] 誤差ジャッジ
  • https://github.com/kmyk/online-judge-verify-helper/issues/10
• [x] include を展開して提出したい
  • hoge.hpp みたいなファイルを置いて #include "hoge.hpp" としたいが、これをすると提出が面倒
  • #pragma once を見ながら #include "..." を再帰的にすべて展開するコードを書けばよい
• [x] https://judge.yosupo.jp から testlib.h 形式のジャッジプログラムを拾ってきて自動で利用してほしい
  • oj にそれ用の機能が入ってから
  • 内部的には実はすべて special judge 扱いになってて常に checker.cpp が実行されてるぽい？ あとで @yosupo06 に確認
• [x] 名前はこれでいいのか
  • とりあえず内容に即した説明的な感じのを付けてるが「そもそも CI って何ですか？」ってなるので library-verify-helper とかの方がよいかも
  • kmyk/... よりも beet-aizu/... の方がよくないか？
• [ ] (要検討) VS Code 向けの snippet を吐く
  • 望まれていそうだが、本当に用意すべきは include + 展開だったりしないか
  • ついでに Vim と Emacs と Atom と CLion にも対応してください！ って言われて大変になりそう
• [x] (要検討) HTML を吐く
  • こういうかっこいいやつを出力: https://asi1024.github.io/competitive-library/cpp/
  • 望まれていそうだが、GitHub 上で十分だったりしそう
  • https://tsutajiro.github.io/cpp_library/ これ便利そうだし、設定ほぼなしで GitHub Pages の更新まで自動でできるならならかなりあり。@Tsutajiro に言ってマージさせてもらいたい
• [ ] (要検討) C++ 以外も対応
  • いつかすることにはなるだろうけど C++専用 + その他全て向け汎用のもの に留めたい
  • じゃあ Python だけ…… って言って対応すると D と Rust と Java と C# も対応したくなってコードが爆発しそう
• [ ] (要検討) GitHub Actions 以外の CI も対応
  • 自前で .travis.yml とかを書けば動くし、必要ないのでは？
• [ ] (要検討) 有名フレームワークとの協調
  • Google C++ Testing Framework など
  • ちゃんとしたやつの枠組みに乗せておくと後々困らないが、 覚えることが多くなってつらそうだしなしでよさそう？
• [x] GitHub Actions にして Marketplace に公開
  • https://github.com/beet-aizu/library/new/master?filename=.github%2Fworkflows%2Fpythonapp.yml&workflow_template=pythonapp みたいなのが可能なのは強い → 一般には解放されてなさそうでした
• [x] PyPI に登録
  • しばらくは GitHub の URL 指定で十分そう
• [ ] ドキュメントを書く
  • はい
  • 各人のライブラリ repo の URL を入力させて GitHub Actions を追加するやつのページに自動で飛ばすとつよそう → とりあえずこれはやった
• [ ] refactoring
  • 特に test.sh を Python で再実装する

[kmyk]

とりあえず名前を固定しましょう。覚えやすさや分かりやすさは使いやすさや普及しやすさに繋がるので重要です

• online-judge-ci-script
  • 現状
  • pros: 分かっていれば最も正確な名前に見える
  • cons: online-judge-tools および CI が何か理解してないと何なのか分からない
• competitive-programming-ci-script
  • cons: CI という語の意味を理解してないと何なのか分からない
• library-verify-helper
  • pros: verify という語は競プロ界隈では理解されている語である
  • cons: 競プロ界隈に古くからいるわけではない人は「library って何の library ですか？」ってなりそう
• online-judge-verify-helper
  • pros: verify という語は競プロ界隈では理解されている語である
  • pros: online-judge-tools を知ってれば中身の推測もしやすい
  • cons: むしろ online-judge-tools を使っているという情報は実装の詳細を露出してるのと同じで不適切かも？
• 他のやつ (参考用)
  • https://github.com/beet-aizu/VerifyHelper
  • https://github.com/asi1024/red-baron

online-judge-verify-helper が一番ましそうか？

[kmyk]

rename した

[kmyk]

GitHub Actions

• https://github.com/beet-aizu/library/new/master?filename=.github%2Fworkflows%2Fpythonapp.yml&workflow_template=pythonapp みたいな便利なやつは https://github.com/actions/starter-workflows からしかだめぽいので使えなさそう
• 微妙に機能が劣るが https://github.com/beet-aizu/library/new/master?filename=.github%2Fworkflows%2Fverify.yml&value=name%3A%20verify%0A%0Aon%3A%0A%20%20push%3A%0A%20%20%20%20branches%3A%0A%20%20%20%20-%20master%0A%0Ajobs%3A%0A%20%20build%3A%0A%0A%20%20%20%20runs-on%3A%20ubuntu-latest%0A%0A%20%20%20%20steps%3A%0A%20%20%20%20-%20uses%3A%20actions%2Fcheckout%40v1%0A%0A%20%20%20%20-%20name%3A%20Set%20up%20Python%0A%20%20%20%20%20%20uses%3A%20actions%2Fsetup-python%40v1%0A%0A%20%20%20%20-%20name%3A%20Install%20dependencies%0A%20%20%20%20%20%20run%3A%20pip3%20install%20-U%20git%2Bhttps%3A%2F%2Fgithub.com%2Fkmyk%2Fonline-judge-verify-helper%0A%0A%20%20%20%20-%20name%3A%20Run%20tests%0A%20%20%20%20%20%20run%3A%20oj-verify%20run

[kmyk]

workflow template みたいなのが作れない悲しみにつつまれながら、Web 上だけで導入が終了するやつを作りました http://kimiyuki.net/online-judge-verify-helper/

[kmyk]

test.sh 直埋め込みだったのを分離した

[kmyk]

verify.yml を整理した。$GITHUB_TOKEN を仕込んだのでしばらくは「更新があるから verify.yml を書き換えてください」になることはないはず (まあそれでもそのうち書き換えてくださいになるのは見えてるけど)

[kmyk]

何も指定されなかったら g++ と clang++ を両方試すようにした (test.sh 側で対応)

[kmyk]

とりあえず自分で使うのに耐えるぐらいにはなったしそろそろ公開かな

[kmyk]

そこそこ導入が楽である程度の機能はあるものを作るのはいいけど、もしみんながそれを使っちゃうと全部同じになってつまらなくないか 少なくとも HTML 出力に関しては https://tsutajiro.github.io/cpp_library/ とか https://beet-aizu.github.io/library/test/status.html とか https://tjkendev.github.io/procon-library/python/index.html とか https://asi1024.github.io/competitive-library/cpp/ とか https://ei1333.github.io/luzhiled/ とか、いろんなのがたくさんあった方が見てて楽しい (まあやるけど)

[kmyk]

version 固定してないの破壊的変更で死ぬのが見えてるのでしておいた 安心

[kmyk]

きれいな HTML 出力のやつを @Tsutajiro がプルリクしてくれる感じになった。@beet-aizu 版スクリプトがベースぽいので cache commit の作成とかも同時に達成できそう

HTML 出力されることの利点として:

• 見栄えがする。成果物が得られた感があってうれしい
• verify されてない実装に :warning: が付くと「verify しないとなあ」って気持ちが増す
• :warning: を順番に :heavy_check_mark: に変えていくのはたぶん楽しい
• MathJax で数式の表示ができる
• ライブラリのドキュメントを書くことが促されるのはよいこと

仕様について:

• #define DESCRIPTION などを定義させるよりも Doxygen 記法のコメント (例1, 例2) を書かせてそれを解析する方が適切そうに見える。説明を 1 行で書くのはしんどいし、かといって path を指定させて別ファイルに書かせるのはもっと手間なので。もちろん実装はマクロの方が楽なので開発リソース次第ですが……

[yosupo06]

• oj にそれ用の機能が入ってから
• 内部的には実はすべて special judge 扱いになってて常に checker.cpp が実行されてるぽい？ あとで @yosupo06 に確認

はい その通りです

[kmyk]

@yosupo06 ありがとう

[beet-aizu]

今キャッシュしてないんですね（そこをまずやろうと思います） yosupoジャッジみたいにテストケースが強化される場合があるので、timestampを剥がす機能も実装します。

[kmyk]

とりあえず https://github.com/beet-aizu/library/blob/master/test/test.sh をコピペしてくるのがよさそう？

[kmyk]

examples/ を生やして segment tree と union-find tree を置いた。「include ができる」「g++ でだけテストする設定にできる」とかが察せるようになったはず

[kmyk]

examples として抽象化セグ木を置くの、いいのか？

[beet-aizu]

今キャッシュしてないんですね（そこをまずやろうと思います）

GitHub Actions限定でいいならユーザーに情報を入れさせずにCIからpushできそうなので書いてみます

[kmyk]

お願いします :pray: 動作範囲は GitHub Actions 限定で十分です

[beet-aizu]

https://github.com/kmyk/online-judge-verify-helper/blob/f13c8ce33b022301318fa70b43cd98c8d6961010/data/test.sh#L100 $CI ってどっかで設定されてますか？これtravis用に書いた記憶があるんですけど（実際 https://github.com/beet-aizu/library/blob/411c6fe9eb0ac874909e318d34abf90328c3651e/test/test.sh#L101　では弾かれてます

[kmyk]

$CI はどこでも設定されてなさそうです。 Travis CI では自動で $CI が定義されてたはずですが、GitHub Actions ではそうでないっぽい。 困るなあ。 if [[ $GITHUB_ACTION ]] ; then CI=1 ; fi とかして、$GITHUB_ACTION が定義されてたら $CI を定義するとかするしかなさそう。 https://help.github.com/en/actions/automating-your-workflow-with-github-actions/using-environment-variables#default-environment-variables

[beet-aizu]

$GITHUB_ACTIONS 以外からpushすることはないと思っているのでむしろ別れていた方がありがたい気がします（そう実装しました）

[yosupo06]

https://help.github.com/ja/actions/automating-your-workflow-with-github-actions/caching-dependencies-to-speed-up-workflows#using-the-cache-action こういうのをうまく使うとわざわざpushとかしなくてもよくなったりしないでしょうか？(偶然見つけただけなので、全然違うものかもしれないです)

[yosupo06]

cacheの話です

[kmyk]

ところで、いま master branch の他に v1 branch というのが作ってあって、verify.yml は v1 branch を使うように設定されています。

https://github.com/kmyk/online-judge-verify-helper/blob/feb8ab7cb69f07f6a0a9cc29a58ee9db8e54342a/.github/workflows/verify.yml#L16

なぜかというと (1) master をうっかり壊したときに全ユーザの CI が壊れるとつらいのでそうならないようにしたく、かつ (2) 破壊的変更を入れたときに (ユーザが v2 に書き換えない限り) CI が壊れないようにしたいためです

[beet-aizu]

理解しました

[kmyk]

好き放題破壊しながらいろいろ試すための develop branch を用意しました。ご利用ください

https://github.com/kmyk/online-judge-verify-helper/commit/d08716df0447543a25ddb9bde39ccedf42502295

[kmyk]

https://github.com/kmyk/online-judge-verify-helper/pull/5 の push 式 cache 機能はちゃんと動いてました :tada: master 以外でも動く (https://github.com/kmyk/online-judge-verify-helper/commit/621be33b8ab775c48ad00575aa7061c1ffd9e9d9) ようにして develop に投げたら push してくれた (https://github.com/kmyk/online-judge-verify-helper/commits/develop)

[kmyk]

えー、develop 微妙に面倒だな。master で好き勝手にテスト破壊しちゃだめか？

[beet-aizu]

cacheの話です

ローカルに持ってくること考えるとpushしたい気持ちになりますが、そもそもキャッシュがよくわからないためどっちがいいのかすらよくわからない

[beet-aizu]

https://judge.yosupo.jp から testlib.h 形式のジャッジプログラムを拾ってきて自動で利用してほしい

これは結局こっち側で対応するのかoj側で対応するのかどっちですか（URLからyosupo judgeのだと判断できるんだしoj側で対応していた方が嬉しそう）

@yosupo06 ヨスポジャッジにchecker以外の形式の問題の導入予定はありますか（リアクティブとか）

[kmyk]

https://judge.yosupo.jp から testlib.h 形式のジャッジプログラムを拾ってきて自動で利用してほしい

とりあえずは oj のライブラリ部分の機能として対応し (コマンドとしては足すかどうかは後回しにしたいので)、その呼び出しはこっちでやるのがいいかなと思っています

[yosupo06]

https://judge.yosupo.jp から testlib.h 形式のジャッジプログラムを拾ってきて自動で利用してほしい

これは結局こっち側で対応するのかoj側で対応するのかどっちですか（URLからyosupo judgeのだと判断できるんだしoj側で対応していた方が嬉しそう）

@yosupo06 ヨスポジャッジにchecker以外の形式の問題の導入予定はありますか（リアクティブとか）

今のところないです　しかし将来的に実装しないってことは約束できないです(実装も大変だし出来る限りは避けますが、ベリファイに本質的にリアクティブが必要な問題(とその需要)が出てくれば実装すると思います)

[yosupo06]

ベリファイに本質的に(special checker以外の)特殊なジャッジが必要な問題は、私は現時点では知らないですが…

[kmyk]

リアクティブについて言えば、oj はすでにリアクティブに対応していて CI からそれを呼び出すのは比較的楽です

[beet-aizu]

https://judge.yosupo.jp から testlib.h 形式のジャッジプログラムを拾ってきて自動で利用してほしい

とりあえずは oj のライブラリ部分の機能として対応し (コマンドとしては足すかどうかは後回しにしたいので)、その呼び出しはこっちでやるのがいいかなと思っています

これoj t --yosupo "問題名" とかにしてしまいたいです（コード読んだ感じojの中にhttps://github.com/yosupo06/library-checker-problems をgit cloneしてきているんですよね？

[beet-aizu]

「ライブラリ部分の機能として実装」と「コマンドとして足す」の違いはなんですか？

[kmyk]

「ライブラリ部分の機能として実装」は Python のコードから import onlinejudge.service.library_checker とかして使う Python の関数として実装するという意味で、「コマンドとして足す」は shell から使える oj コマンドのオプションなどとして実装するという意味です。

[kmyk]

@tsutaj コミット権限付与していい？ build-pages.py をこっちで保守するのかなりしんどそうなのでまかせたい

[tsutaj]

@kmyk おっけーです！

[kmyk]

@tsutaj :tada: collaborator に設定しました。メールが来るはずなので承認してください

[kmyk]

PyPI に登録しました。主には pip install git+https://github.com/kmyk/online-judge-verify-helper.git でなくて pip install online-judge-verify-helper でよくなるのがうれしい https://pypi.org/project/online-judge-verify-helper/

[kmyk]

GitHub Release を作ったら PyPI に反映されるようにしました バージョン番号は基本的に semantic versioning https://semver.org/lang/ja/ に従う感じです @beet-aizu @tsutaj バージョンを上げたくなったら勝手に上げてもらってかまいません

[kmyk]

ドキュメント生成も整備した きれいに表示されるようになりました: https://kmyk.github.io/online-judge-verify-helper/verify/examples/union_find_tree.yosupo.test.cpp.html

• .md と .html が両方生成されるのでそのまま両方 push しちゃってたけど、push は .md だけにした
• _config.yml を置いて絵文字が表示されるようにした
• 手で作ったファイルを外側から投げ込めるようにした。具体的には .verify-helper/docs/static/hoge/fuga が gh-pages の hoge/fuga に転送されます

[kmyk]

@beet-aizu gh-pages への push は成功してるのだけど、GitHub Actions 内からの push だと GitHub Pages の build が開始されないぽい。原因を知っていたりしませんか？ たすけて https://github.com/kmyk/online-judge-verify-helper/commits/gh-pages

[kmyk]

ミスにより発生した巨大コミット https://github.com/kmyk/online-judge-verify-helper/commit/6c9ff8a797df9dd69fb1e580cf9ff4674a8d5b1c

[beet-aizu]

これは多分仕様でGitHubActionsからのpushは拾えないようになっている気がします　公式サポートに聞くのがよさそう

[kmyk]

そうっぽい GITHUB_TOKEN だと push はできても action の kick はできないらしい https://github.com/marketplace/actions/github-pages-deploy#secrets

[kmyk]

設定すれば GitHub Pages も自動で更新されるようにした https://kmyk.github.io/online-judge-verify-helper/installer.html

[kmyk]

verify 結果のキャッシュとは別に、judge.yosupo.jp の問題の入出力の生成結果をキャッシュしておくとよさそう。2倍速になるはず。入出力を commit すると容量が大きくて面倒なので実装には cache action がよさそう AOJ の問題とかには効かないので実装する価値は小さいけれど、verify に 2 時間かかってる人が 1 時間半で済むようになればうれしいかも？