verification using AtCoder and/or Codeforces

[kmyk]

自動で提出して AC したか自動で確認すればよいので、可能です。

わりと簡単に実装できますが、完全自動化すると AtCoder への負荷でおこられます。 たぶん「ローカルからしか使えない」「1ファイルずつ手動で oj-verify submit hoge.test.cpp を実行しないとだめ」「ところどころ sleep を挟む」ぐらいに制限をかければぎりぎり許されるはず。便利にするとおこられだし不便にするとつらいので難しいが、AtCoder の問題を verify に使いたさはあるのでやってみてもよいかも？

[kmyk]

テストファイルは 300 個とか越えるので手動提出は現実的でない。自動提出も BAN される。無理です

[kmyk]

Many online judges don't distribute their test cases. It's possible to submit directly (like vjudge), but there is the problem about scalability.

---

The number of test files becomes too large. For example, @beet-aizu's library has about 300 test files now (i.e., without support for AtCoder nor Codeforces). It will easily reach 1000 files when AtCoder and Codeforces are supported.

There are some possible methods. Some methods including steps using hands (e.g. submitting via web browsers and reporting the results by hands) are apparently impossible. For automatically submitting, possibilities are following:

1. Submitting from users' local environments
2. Submitting from GitHub Action
3. Using some proxy servers like vjudge

But using any method, automatically submitting has same difficulties:

1. Politeness: We'll be banned if making too many submissions. The online judges like Codeforces don't welcome to such automatically submitting. (vjudge is just tolerated because users request submissions by hands and make only few submissions.)
2. Speed: Adding waits makes verification too slow. If adding waits 1 minute per 1 file for politeness, it takes 10 minutes for 10 files and 5 hours for 300 files. The token of GitHub Actions becomes unstable in 20 minutes (#51), and entirely expires in 1 hour.
3. Cost: The cost about implementation and maintaining. It's possible but very troublesome to implement features to logging in, submitting, and getting results for many online judges. Using vjudge as a proxy (suggested by https://codeforces.com/profile/Devil) may be a good idea to decrease costs.

It one takes care about (1.) Politeness, then we cannot ignore the (2.) Speed. And using any method, the (3.) Cost to implement is relatively large for the benefits. If someone sends a nice implementation, of course I'll merge it.

[kmyk]

要望としてはあるので reopen しておく (解決はしなさそうだけど)

[kjnh10]

AtCoderで一部の問題はテストケースが公開されていますが それらに対してだけでもoj download --systemを動くようにすることはできませんか？

問題のURLとテストケースのURLが機械的には判定出来なそう雰囲気なので、 テストとして使いたい人が辞書にその都度登録していくような運用ならできるのかなという気がします。

[kmyk]

@kjnh10

AtCoderで一部の問題はテストケースが公開されていますが それらに対してだけでもoj download --systemを動くようにすることはできませんか？

はい、@kjnh10 さんの言うようにすればできます。 実際に類似のことをある程度の部分までしている例はあります: https://greasyfork.org/ja/scripts/371832-atcoder-testcase-extension (GitHub: https://github.com/tatsumack/atcoder-testcase-extension)

しかし、しんどいので私は実装もメンテもあまりしたくないです。(ユーザからは望まれてるので、よく書けたプルリクが来てしまった場合はマージせざるをえないみたいなところはありますが……) これは以下のふたつの課題のためです:

1. Dropbox の操作が難しい
   • Dropbox は scraping を歓迎していません。サイトが AtCoder などと違って複雑かつ頻繁に変更が入るので、scraping は開発もメンテもしんどいはずです。ちなみにユーザにとっては楽です
     • 追記: 規約違反の可能性がある (ない可能性もある) ので確認が必要
   • API の利用は推奨されていますが、開発者にとってもユーザにとってもしんどいです。開発者側は OAuth 用のサーバを立てて維持管理をする必要がありますし、ユーザ側は Dropbox のアカウントを作って認証その他をする必要があります (たぶん)
   • 参考: https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/download-file-using-python-API-frpm-another-user/td-p/191824
2. AtCoder はテストケースのダウンロードの自動化を歓迎していない
   • 「望まれているのは分かるけど、機械的にダウンロードできるようにしちゃうと他のオンラインジャッジに問題を丸パクリされるのでつらい」みたいな話があります。実装前に chokudai さんに話を通す必要があります

[kmyk]

AtCoder TestCase Extension を読むとそんなに闇っぽくないし、もしかすると scraping いけるのかも？

[kjnh10]

回答ありがとうございます。 1については少し調べてみてますが出来たとしても（私の技量だと）面倒そうな感じはします。 1がクリアできても２がクリアされないことにはという感じですし。

別の方法としてローカルのテストフォルダはユーザーが自前で用意して下記のような記法を許すようにするのはどうでしょうか？

define PROBLEM "../../local_cases/abc165_e"

第三者がライブラリを眺めた時に本当にその問題でverifyされてるかが怪しくなるのが少し嫌かなという気はしますが。

ちなみにそこまで強い要望ではないです。aoj, yosupo judge, yukicoderで基本的には十分という気 もしていますので。ただやはりAtCoderの問題も扱えると上記のコンテストから探す手間が省けるのでありがたいという気はします。

[kmyk]

テストケースを自前で用意できるようにする方向をやるべきでない理由は特にないですが、やってもあまりうれしさがないと考えています。次のふたつが根拠です。

• テストケースを自分で書くのはしんどい。ランダムケースだけだとたいてい弱いし、丁寧なケースを作り込むのは難しい
  • そういう作業を自分でやるのならいっそ Library Checker に投稿した方がよい
• 現状でも http://judge.u-aizu.ac.jp/onlinejudge/description.jsp?id=ITP1_1_A を指定して hoge.test.cpp の中でランダムケースを生成することでだいたい同じことができ、こちらの方が圧倒的に楽

[kjnh10]

自前で用意する、の表現が良くなかったです。副次的なメリットとしてそれもあるんですが、基本的にはAtCoderのテストケースをDropboxから手でダウンロードしてきてレポジトリ内に置く使い方を想定していました。

[kmyk]

理解しました。そうするとテストケースを書かなくてよくて多少は楽そうですが、すでに指摘してくれているように CI 上でのテストができないのがつらそうです。

[kjnh10]

レポジトリ内にテストケースをおいておいたらCI上でも動く（ように実装できる）と思っていたのですが、そうでもないのですかね？

[kmyk]

「レポジトリ内にテストケースをおいておいたらCI上でも動く」は正しいです。 しかし「AtCoderのテストケースをDropboxから手でダウンロードしてきてレポジトリ内に置く」をやると著作権的な問題が発生します。無断での再配布はまずいので、これも chokudai さんに許可を取る必要があります。

[kmyk]

https://github.com/online-judge-tools/api-client/issues/60 別の issue を作りました。以降、AtCoder に特有の話はできればこちらでしてください

[kmyk]

AtCoder のシステムケースの取得には https://github.com/online-judge-tools/api-client/issues/60#issuecomment-678236565 で紹介された qryxip/snowchains が (規約違反のなさの意味で) わりとよさそう。

snowchains は AtCoder 以外にも対応してるので、もしこれを組み込むなら以下の 2 ステップをやることになるはず:

1. @qryxip に snowchains を修正して API 部分だけを切り出してもらう (jmerle/competitive-companion とだいたい互換の形式の JSON を吐いてくれるとうれしい)
2. おそらく @kmyk が verification helper のテストケース取得機能のバックエンドのひとつとして snowchains を追加する

@qryxip これどうですか？ 興味があるならたのむ

[qryxip]

snowchains を修正して API 部分だけを切り出してもらう

については一応コア部分をRustのライブラリに切り出しています。cargo-competeで使い回すために。

「テストケースの取得」だとこの形式のデータを得ます。

snowchains_core/examples/atcoder-retrieve-test-cases.rs

competitive-companion、というよりoj-apiっぽく吐くのは可能だと思います。(今現在memoryLimitは拾ってないので拾う必要がある)

[qryxip]

ただsnowchains(_core)ではDropboxのAPIを叩くのにそんなに大層なことはしてない(認証部分をすっ飛ばしてる)し、Rust製ツールのビルド時間は先程体験してもらったと思うのですが頼って大丈夫ですか (私はある程度Pythonの読み書きができます) (肥大化を避けたいのは知ってますが)

[kmyk]

頼って大丈夫ですか

これすこし大丈夫でない気がしてきました。申し訳ないですがもうしばらく様子を見たいです。

しばらく調査しての結論として、現状だと結果に対してお互いの手間が大きすぎる気がしてきたためです。具体的には以下の 2 点で、

1. 認証部分をすっ飛ばしてる

   • 省略できるところを省略するのは正しい戦略ですが、必要な token を得る方法が私にも分かりません。このまま実装しても利用できるユーザが存在してなさそう。ドキュメントをもう少し書く必要がありそう

2. 素朴な実装しかされてなさそう
   • AtCoder のテストケースの Dropbox は人間の手によって暖かみのある管理をされているので、それなりに汚ないです (例: takoha-cpp/WrongAnswer が苦しんでいる様子)。そのあたりの対策がなくてまだ枯れてなさそうに見えます

ビルドが遅いのもたしかに注意する必要はある (verification helper の文脈だと CI なので、利用前に毎回ビルドすることになるため) のですが、AtCoder のシステムテストを使わない人には影響しないので、あまり気にしていません。

[qryxip]

よく考えたのですが:

1. どちらにせよDropBox APIを使うならaccess_tokenをGitHub Actionsのsecretsに、という方法しか無いのではないかと思います。ちゃんとアプリ立てて認証するにしろ各自がDropBox Developersでdevelopmentのを発行するにしろ。

   (コンソール開いてみて気づいたのですが)最近になってスコープを細かく絞れるようになったのでフルの権限を渡さずに済むようになったみたいですし、ドキュメントさえ書けば問題にはならないんじゃないかと思います...多分。 #113 を自力でなんとかしている人をこの前見かけましたし信頼しても良いと思います。

   DBX OAuth Guide

   

   

2. 人の手の暖かみですがinとoutが対応しない、というのは公開されていないと同じ扱いにしても良いんじゃないかと。

   ゴミファイルの存在は初めて知りました。ただテストケース 新しいテキスト ドキュメントみたいなのが爆誕したとしても(コンテスト本番中に比べれば)致命傷にならないんじゃないかと思います。

   とりあえずsnowchainsを改善するにしろ他のを探すにしろ再実装するにせよまずはコンテスト名の対応ですね... もうABC-ARC体制はしばらく無さそうだし数を考えれば全部対応表をハードコードするのがまっとうな気がします。

[qryxip]

あとビルド時間ですがGitHub Releasesでの配布でスキップできそう。 GitHub Actions同士なら可搬性はあると見なしてよいはず。

[qryxip]

2. 素朴な実装しかされてなさそう
   • AtCoder のテストケースの Dropbox は人間の手によって暖かみのある管理をされているので、それなりに汚ないです (例: takoha-cpp/WrongAnswer が苦しんでいる様子)。そのあたりの対策がなくてまだ枯れてなさそうに見えます

とりあえずsnowchainsを改善するにしろ他のを探すにしろ再実装するにせよまずはコンテスト名の対応ですね... もうABC-ARC体制はしばらく無さそうだし数を考えれば全部対応表をハードコードするのがまっとうな気がします。

一応コンテスト名の対応はこの3日後にやりました。

https://github.com/qryxip/snowchains/blob/b3f916e1999063d774c312e1fb1af975912e4078/snowchains_core/resources/dropbox-path-prefixes.json

ABC-ARCの対応はもう取らなくていいはず。ただ外部コンテストについては開催されるたびに更新していくしかなさそうではあります。

ゴミファイルについてはまだ調べてませんがwaの該当部分を見るに人の暖かみは数パターンしかないようなのでこっちについてはこれを真似ればなんとかなる?

https://github.com/takoha-cpp/WrongAnswer/blob/5ad8434af14163da3f60e391d7f83c50fd3b7a90/wrong_answer/main.py#L276-L284

[kmyk]

AtCoder is now supported. Codeforces is impossible to support.