verification using AtCoder and/or Codeforces

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

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

[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]

頼って大丈夫ですか

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

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

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

   • 省略できるところを省略するのは正しい戦略ですが、必要な token を得る方法が私にも分かりません。このまま実装しても利用できるユーザが存在してなさそう。ドキュメントをもう少し書く必要がありそう
2. 素朴な実装しかされてなさそう
   • AtCoder のテストケースの Dropbox は人間の手によって暖かみのある管理をされているので、それなりに汚ないです (例: takoha-cpp/WrongAnswer が苦しんでいる様子)。そのあたりの対策がなくてまだ枯れてなさそうに見えます

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